Guia para TAller de Ingenieria de Softwa

INSTITUTO TECNOLÓGICO DE CIUDAD VALLES
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN
INGENIERÍA EN SISTEMAS COMPUTACIONALES
ELABORADO POR
ISC. Rosa Imelda García Chi, MTI

Ingeniero en Sistemas Computacionales
Máster en Tecnologías de la Información
Taller de Ingeniería de Software- Guía Técnica 2014
Contenido
INTRODUCCIÓN .................................................................................................... 1
Datos de la Asignatura ............................................................................................ 3
Nombre de la Asignatura: Taller de Ingeniería de Software ................................. 3
Objetivos Generales del Curso de Taller de Ingeniería de Software ....................... 5
Competencias específicas a desarrollar por unidad ............................................. 5
PRÁCTICAS DE LA UNIDAD 1 ............................................................................... 7
Unidad 1. Estándares y modelos de calidad aplicados al software ........................ 8
Práctica no. 1 ........................................................................................................ 10
Nombre de la práctica: Foro ¿Qué es la calidad del software? ........................ 10
Práctica no. 2 ........................................................................................................ 12
Nombre de la práctica: Modelos de Calidad del Software ................................ 12
Práctica no. 3 ........................................................................................................ 15
Nombre de la práctica: SQA............................................................................. 15
Práctica no. 4 ........................................................................................................ 17
Nombre de la práctica: Estándares de calidad del software............................. 17
Práctica no. 5 ........................................................................................................ 20
Nombre de la práctica: Moprosoft .................................................................... 20
PRÁCTICAS DE LA UNIDAD 2 ............................................................................. 22
Unidad 2. ............................................................................................................... 23
Práctica no. 6 ........................................................................................................ 26
Nombre de la práctica: Ejercicio de Introducción Internet Web ........................ 26
Práctica no. 7 ........................................................................................................ 28
Nombre de la práctica: Ejercicio E_Commerce en hotpotatoes ....................... 28
ING. ROSA IMELDA GARCIA CHI, MTI i

Práctica no. 8 ........................................................................................................ 30
Nombre de la práctica: Fundamentos del Mercadeo ........................................ 30
Unidad 3. ............................................................................................................... 32
Práctica no. 9 ........................................................................................................ 33
Nombre de la práctica: Fase 1 Plan de Negocios para Proyecto IWeb ............ 33
Unidad 4. ............................................................................................................... 36
Práctica no. 10 ...................................................................................................... 43
Nombre de la práctica: Fase 2 Análisis de Aplicaciones Web.......................... 43
Unidad 5. ............................................................................................................... 48
Temas de diseño para ingeniería Web .............................................................. 48
Pirámide del diseño IWEB ................................................................................. 49
Diseño de la interfaz de la WebApp ................................................................... 50
Práctica no. 11 ...................................................................................................... 51
Nombre de la práctica: Fase 3 Diseño para aplicaciones Web ........................ 51
Unidad 6. ............................................................................................................... 55
Pruebas de conceptos para WebApp................................................................. 55
Las pruebas que se aplican a una aplicación web ............................................. 56
Práctica no. 12 ...................................................................................................... 58
Nombre de la práctica: Evento Académico #IWEB .......................................... 58
FORMATO DE REPORTE DE PRÁCTICAS ......................................................... 60
Formato de Reporte de Prácticas .......................................................................... 61
ING. ROSA IMELDA GARCIA CHI, MTI ii

Reporte por práctica.......................................................................................... 61
Reporte final de todas las prácticas ................................................................... 62
Bibliografía ............................................................................................................ 63
ING. ROSA IMELDA GARCIA CHI, MTI iii

INTRODUCCIÓN
La Guía Técnica de Taller de Ingeniería de Software integra un conjunto de

prácticas sugeridas correspondientes a las seis unidades que integran el
programa. Iniciando la unidad 1 con prácticas relacionadas Se aborda el tema de
estándares y modelos de calidad aplicados al software, con la finalidad de que el
estudiante realice software de calidad. En la segunda unidad, se trata el tema de
ingeniería del software para comercio electrónico, que permite el desarrollo de
software para realizar la comercialización usando las TIC´S.
En la tercera unidad, se aborda el tema de ingeniería web para el desarrollo

de software tipo cliente-servidor, de toma de decisiones y en particular para
ejecutivos, identificando los atributos. En la unidad cuatro, se tratan temas
relacionados con el modelado del software, para que el estudiante elabore el
análisis de aplicaciones web.
En la quinta unidad, se abordan temas que permitan al estudiante el

diseño y construcción de las aplicaciones web.
El objetivo es elaborar un Manual de Prácticas para la asignatura de Taller

de Ingeniería de Software de la Carrera de Ingeniería en Tecnologías de la
información y comunicaciones, que proporcione al alumno la habilidad y destreza
para Identificar la importancia de la aplicación de estándares de calidad y
productividad en el desarrollo de un software. Aplicar métodos y herramientas de
la ingeniería del software en el desarrollo de software e Identificar las
características de los métodos ágiles.
La Guía Técnica presenta una serie de prácticas que cubre cada uno de los
objetivos de las unidades del programa de estudios. Las prácticas son sólo una
sugerencia didáctica para que el docente guie al alumno a aplicar los
conocimientos adquiridos en cada una de las unidades.
ING. ROSA IMELDA GARCIA CHI,MTI 1

Se incorpora al presente Manual sugerencia de formatos para elaborar los
reportes de las prácticas realizadas para que el estudiante integre al final un
documento con la aplicación y resultado de cada una de las prácticas
seleccionadas para su realización. Esta Guía es resultado de un proyecto docente
y podrá adquirirse en el Departamento de Sistemas y Computación, así como en
Internet en las siguientes direcciones: www.issuu.com, www.slideshare.net,
www.scribd.com, www.googledocs.com y www.tecvalles.mx/moodleitv.

Datos de la Asignatura
Nombre de la Asignatura: Taller de Ingeniería de Software
Ingeniería en Tecnologías de la Información y

Carrera
Comunicación
SCD-1015
Clave de la Asignatura
HT- HP- Créditos SATCA 2–3–5
UNIDAD 1. Estándares y modelos de calidad

Temario General
aplicados al software
UNIDAD 2. Ingeniería del software para comercio

electrónico
UNIDAD 3. Ingeniería web
UNIDAD 4. Análisis de aplicaciones Web
UNIDAD 5. Diseño para aplicaciones web
UNIDAD 6. Verificación y validación de aplicaciones

web
Temas Unidad 1 1.1. ISO.

1.2. Spice.
1.3. CMMI.
1.4. Boostrap.
1.5. Moprosoft.
Temas Unidad 2 2.1. Introducción.
2.2. Sistemas distribuidos.
2.3. Comercio electrónico: concepto de comercio
electrónico y tipos, sistemas de comercio electrónico.
2.4. Tecnologías utilizadas para el comercio
electrónico: socket, objetos distribuidos, CGI,
espacios, contenidos ejecutables, entre otros.
2.5. Ingeniería de seguridad: encriptación, firmas
digitales, certificaciones digitales, entre otros.
3.1. Atributos de los sistemas y aplicaciones basados
Temas Unidad 3 en web.
3.2. Estratos de la ingeniería de webapp.
3.3. El proceso de ingeniería web.
3.4. Mejores prácticas de ingeniería web.
3.5. Formulación de sistemas basados en web.
3.6. Planeación de proyectos de ingeniería web.
3.7. El equipo de ingeniería web.
3.8. Conflictos de gestión de proyecto para ingeniería
web.
3.9. Medición para ingeniería web y webapps.
4.1. Requisitos para el análisis de las webapps.
Temas Unidad 4 4.2. El modelado de análisis para webapps.
4.3. Modelo de contenido.
4.4. Modelo de interacción.
4.5. Modelo funcional.
4.6. Modelo de configuración.
4.7. Análisis relación-navegación.
5.1. Temas de diseño para ingeniería web.5.2.
Temas Unidad 5 Pirámide del diseño ingeniería web.
5.3. Diseño de la interfaz de la webapp.
5.4. Diseño estético.
5.5. Diseño del contenido.
5.6. Diseño arquitectónico.
5.7. Diseño de navegación.
5.8. Métricas de diseño para webapps.
6.1. Planificación de la verificación y validación de
Temas Unidad 6 aplicaciones web.
6.2. Inspección de software basado en web.
6.3. Pruebas de las aplicaciones web.
6.4. Ejemplos de pruebas para webapps.
6.5. Implementación de las aplicaciones web.
6.6. Evaluación de las aplicaciones web.
6.7. Mantenimiento de las aplicaciones web.

Objetivos Generales del Curso de Taller de Ingeniería de Software
Identificar la importancia de la aplicación de estándares de calidad y productividad

en el desarrollo de un software.
Aplicar métodos y herramientas de la ingeniería del software en el desarrollo de

software.
Identificar las características de los métodos ágiles.
Competencias específicas a desarrollar por unidad
Competencia Específica de la unidad 1
 Identificar la importancia de la aplicación de estándares de calidad y

productividad en el desarrollo de un software.
 Analizar las estrategias para negocios electrónicos, que incluyan

transacciones y transferencias financieras en la web.
 Analizar e identificar los diferentes modelos de sitios web.
 Identificar las características de una aplicación web y conocer los

elementos que interactúan con ella.

 Sintetizar los resultados del análisis de aplicaciones web.
 Identificar y aplicar modelos para la elaboración del análisis de aplicaciones
web.

 Identificar y aplicar los diagramas que muestren el comportamiento de la

aplicación web acorde a los requerimientos del usuario.

 Identificar técnicas para la implantación y mantenimiento del software.

PRÁCTICAS DE LA UNIDAD 1

Unidad 1. Estándares y modelos de calidad aplicados al software
La Organización Internacional de Normalización o ISO (del griego, ἴσος (isos),

'igual'), nacida tras la Segunda Guerra Mundial (23 de febrero de 1947), es el
organismo encargado de promover el desarrollo de normas internacionales de
fabricación (tanto de productos como de servicios), comercio y comunicación para
todas las ramas industriales a excepción de la eléctrica y la electrónica.
Su función principal es la de buscar la estandarización de normas de productos y

seguridad para las empresas u organizaciones (públicas o privadas) a nivel
internacional.
La ISO es una red de los institutos de normas nacionales de 163 países, sobre la
base de un miembro por país, con una Secretaría Central enGinebra (Suiza) que
coordina el sistema. La Organización Internacional de Normalización (ISO), con
sede en Ginebra, está compuesta por delegaciones gubernamentales y no
gubernamentales subdivididos en una serie de subcomités encargados de
desarrollar las guías que contribuirán al mejoramiento.
Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un
organismo no gubernamental y no depende de ningún otro organismo
internacional, por lo tanto, no tiene autoridad para imponer sus normas a ningún
país. El contenido de los estándares está protegido por derechos de copyright y
para acceder ellos el público corriente debe comprar cada documento.
El proyecto SPICE es el proyecto 07.29 del subcomité SC7. Es un documento

compuesto de 9 partes que al momento de publicar el libro estaba en su primera
revisión formal como Proposed Draft Technical Report (PDRT). El siguiente estado
del proceso de estandarización es llegar al Draft Technical Report (DTR) y
finalmente publicar Technical Report type 2 (TR-2). El tipo 2 significa que todavía
existen dudas en la comunidad sobre la aceptación del documento. Después de
dos años se realiza la última votación para que se vuelva el estándar internacional.

El Software Process Assessment (SPA) y el proyecto SPICE tienen sus orígenes
en el creciente uso y dependencia de la Tecnología de Información que en
consecuencia dió el incremento de frustración e incumplimiento de expectativas
por parte de los desarrolladores y los usuarios de software.
Capability Maturity Model Integration (CMMI) es un modelo de aseguramiento de

la calidad que busca la mejora continua de las organizaciones mediante el análisis
y re-diseño de los procesos que subyacen en la organización. Fue creado por el
SEI (Software Engineering Institute) de laUniversidad de CarnegieMellon y
patrocinado por el Ministerio de Defensa de los Estados.
MOPROSOFT, Modelo de Procesos para la Industria del Software. Modelo para la

mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y
productos de software. Desarrollado por la Asociación Mexicana para la Calidad
en Ingeniería de Software ([1]) a través de la Facultad de Ciencias de la
Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría
de Economía para obtener una norma mexicana que resulte apropiada a las
características de tamaño de la gran mayoría de empresas mexicanas de
desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la
comunidad universitaria y profesional, y la norma técnica a la que da contenido es
la NMX-059/01-NYCE2005 que fue declarada Norma Mexicana el 15 de agosto de
2005 con la publicación de su declaratoria en el Diario oficial de la Federación.

Práctica no. 1
Nombre de la práctica: Foro ¿Qué es la calidad del software?
Participar con el concepto de calidad de software

Objetivo
La calidad del software es una preocupación a la que
Introducción
se dedican muchos esfuerzos. Sin embargo, el
software casi nunca es perfecto. Todo proyecto tiene
como objetivo producir software de la mejor calidad
posible, que cumpla, y si puede supere las
expectativas de los usuarios.
En el software lo que se mide son atributos propios

del mismo, se descompone un atributo general en
otros más simples de medir, a veces se mide bien o
mal ya que la descomposición del atributo genérico de
calidad en otros sub-atributos se torna irreal, se mide
con datos estadísticos no avalados, es imposible decir
que la medición se hace en forma correcta.
El concepto de medida va de más a menos, va de lo

general a lo concreto y lo concreto es asociado a la
métrica, cuya combinación te daría el nivel de calidad
o seguridad de tu producto. Las ciencias bien
estructuradas se basan en medidas bien hechas, se
basan en la matemática.
 Libreta u hojas blancas de papel bond

Material y Equipo
 Lápiz, Sacapuntas y Borrador
 Computadora con Acceso a Internet
 Dispositivo de almacenamiento

 Plataforma Moodle del IT Valles

 Procesador de Textos p.e. Word
1. Realiza búsqueda sobre el concepto

Metodología
2. Estructura tu propio concepto
3. Ingresa a la plataforma Moodle y deja escrita
tu participación.
Realiza consultas y lectura antes de participar en este

Sugerencias
foro.

Práctica no. 2
Nombre de la práctica: Modelos de Calidad del Software
Elaborar una presentación en prezi.com

Objetivo
La calidad del Software es un conjunto de cualidades
Introducción
medibles y específicas que varía de un sistema a otro,
dependiendo de tipo de software que se va a
desarrollar, para determinar su utilidad y existencia.
El desarrollo de software se ha convertido en uno de

los principales problemas que tiene que afrontar la
Ingeniería de Software.
Tanto las comercializadoras de software y los

investigadores, por esto se hace indispensables
realizar una análisis de los modelos de calidad como
son: Norma ISO/IEC, integración del modelo de
maduración de la capacidad (CMMI) y (IT MARK )
modelo de calidad para PYMES, para determinar los
beneficios y sus inconvenientes que presenta para el
desarrollo de Software con calidad.

Material y Equipo
1. Realiza investigación en distintas fuentes

Metodología
electrónicas.

2. Regístrate en prezi.com o instala prezi de
escritorio
3. Elabora una presentación en prezi con la
información referente a los modelos de calidad
de software
4. Sube la presentación al Moodle o envía el
enlace
Sugerencias Revisa todos los modelos de software que se te

proporcionan:
Modelos de Calidad del Software a Nivel Proceso
• Capability Maturity Model Integration (CMMi) –

Versión 1.1, CMMi - Versión 1.2
• TICKIT
• Modelo Bootstrap
• Personal Software Process (PSP)
• Team Software Process (TSP)
• Practical Software Measurement (PSM)
• Six Sigma For Software
Modelos de Calidad del Software a Nivel Producto
• Modelo de Gilb
• Modelo GQM (Goal – Question – Metric)
• Modelo de McCall
• Modelo FURPS
• Modelo de BOEHM
• Modelo SATC (Software Assurance Technology

Center)
• Modelo de Dromey

• Modelo C-QM
• Metodología SQAE (Software Quality Assessment

Exercise)
• WebQEM (Web Quality Evaluation Method)

Práctica no. 3
Nombre de la práctica: SQA
Elaborar un plan de Aseguramiento de Calidad del

Objetivo
Software (SQA)
El propósito de Aseguramiento de la Calidad de Software

Introducción
(SQA) es proveer una administración adecuada con una
visión en el proceso que está siendo usado por el proyecto
de software, y los productos que están siendo construidos.
El Aseguramiento de la Calidad de Software (SQA) implica

revisión y auditorias de los productos de software, y
actividades para verificar que se cumplan con los
procedimientos y estándares; con tal de que el proyecto
de software y el líder del proyecto estén con estas
revisiones e auditorias.
El encargado de Aseguramiento de la Calidad de Software

(SQA) trabaja con el proyecto de software durante sus
etapas iniciales para establecer planes, estándares y
procedimientos que agregaran estimaciones al proyecto
de software; y satisfacer las restricciones del proyecto y
las políticas de la organización. Por la participación para el
establecimiento de los planes, estándares y
procedimientos; el encargado del Aseguramiento de la
Calidad de Software (SQA) ayuda a garantizar de que se
ajusten a las necesidades del proyecto y verifica que
serán usados para llevar a cabo las revisiones y auditorias
en todo el ciclo de vida de software.

El encargado de Aseguramiento de la Calidad de Software
revisa las actividades del proyecto y audita los productos
de software que se elaboran en todo el ciclo de vida y
provee en la administración, una visión acerca de que, si
el proyecto de software se está adhiriendo a sus planes
establecidos, estándares y procedimientos.

Material y Equipo
1. Planificar las actividades de SQA.

Metodología
2. Verificar la adherencia de los productos de trabajo y
de las actividades a los estándares, procedimientos
y requerimientos establecidos.
3. Informar a los grupos e individuos afectados sobre
las actividades de SQA y sus resultados.
4. Comunicar a la administración superior sobre
desviaciones no resueltas dentro del proyecto.
5. Elabora el plan de SQA
6. Subirlo a la plataforma moodle
Realizar el plan SQA en un documento de word

Sugerencias

Práctica no. 4
Nombre de la práctica: Estándares de calidad del software
Elaborar un mapa conceptual de los estándares de

Objetivo
calidad de software
Los primeros años de la era informática se vieron

Introducción
marcados por el desafío del desarrollo del hardware
de los ordenadores. Este desafío se ha visto superado
por los vertiginosos avances de la microelectrónica.
Hoy en día el principal problema al que nos
enfrentamos es la llamada “crisis del software”.
La causa principal de esta crisis es el aumento de la

complejidad de las aplicaciones sin la adopción de los
procesos adecuados de desarrollo que contribuirían a
obtener un producto de mayor calidad y menor coste.
Surgen varias preguntas por las cuales han de ser

contestadas:
¿Estándar de Calidad?
¿Por qué implementar estándares de calidad?
• Satisfacción del cliente
• Competencia
• Defectos
Calidad del Software: “Concordancia con los

requisitos funcionales explícitamente establecidos con

los estándares de desarrollo explícitamente
documentados y con las características implícitas que
se espera de todo software desarrollado
profesionalmente” R. S. Presman
La calidad del software: “Es una preocupación a la

que se dedican muchos esfuerzos. Sin embargo, el
software casi nunca es perfecto. Todo proyecto tiene
como objetivo producir software de la mejor calidad
posible, que cumpla, y si puede supere las
expectativas de los usuarios.”

Material y Equipo
1. Realizar búsqueda de los diversos estándares

Metodología
de calidad de software
2. Elige elaborar el mapa conceptual en
mindmanager, conceptdraw, cmaptools,
examtime u otro.
3. El mapa debe contener nombre del estándar,
de donde surgió, en que se aplica o que
evalúa.
4. Enviar el mapa a la plataforma moodle
Estos son algunos de los estándares:

Sugerencias
Estándares de Calidad del Software a Nivel
Proceso

• ISO 90003:2004
• ISO/IEC 9001:2000
• ISO/IEC 12207:1995
• ISO/IEC 12207:2002 AMD 1
• ISO/IEC 12207:2004 AMD 2
• ISO / IEC TR 15504 - SPICE
• IEEE/EIA 12207.0-1996
• IEEE Std 12207.1-1997
• IEEE/EIA 12207.2-1997
• COBIT 4.0
• ITIL – Information Technology Infrastructure Library
• ISO/IEC 20000:2005
Estándares de Calidad del Software a Nivel Producto
• ISO/IEC 9126-1:2001 – Quality Model
• ISO/IEC 25000:2005 – SquaRE
• IEEE-Std 1061-1998: Standard for a Software

Quality Metrics Methodology

Práctica no. 5
Nombre de la práctica: Moprosoft
Identificar y conocer los elementos de la Norma de

Objetivo
Calidad de software Mexicana
Moprosoft: Modelo de Procesos para la Industria del

Introducción
Software. Modelo para la mejora y evaluación de los
procesos de desarrollo y mantenimiento de sistemas y
productos de software.
Desarrollado por la Asociación Mexicana para la

Calidad en Ingeniería de Software a través de la
Facultad de Ciencias de la Universidad Nacional
Autónoma de México (UNAM) y a solicitud de la
Secretaría de Economía para obtener una norma
mexicana que resulte apropiada a las características
de tamaño de la gran mayoría de empresas
mexicanas de desarrollo y mantenimiento de software.
Moprosoft es el nombre del modelo en la comunidad
universitaria y profesional, y la norma técnica a la que
da contenido es la NMX-059/02-NYCE-2005 que fue
declarada Norma Mexicana el 15 de agosto de 2005
con la publicación de su declaratoria en el Diario
oficial de la Federación.
Moprosoft considera que los modelos de evaluación y

mejora CMMI e ISO/IEC 15504 no resultan
apropiados para empresas pequeñas y medianas de
desarrollo y mantenimiento de software. Sobre las
áreas de procesos de los niveles 2 y 3 del modelo

SW-CMM e inspirándose en el marco de ISO/IEC
15504 se ha desarrollado este modelo.

Material y Equipo
1. Realiza investigación referente al proyecto

Metodología
PROSOFT
2. Revisa los documentos de la norma NMX-
059/02-NYCE-2005 que te proporcionará la
profesora
3. Elabora un cuadro sinóptico sobre los
elementos que contiene cada documento
4. Sube el cuadro a la plataforma Moodle.
Sugerencias


Unidad 2.
¿Comercio electrónico Qué es? Es la realización de cualquier transacción

comercial de bienes o servicios a través del uso de herramientas facilitadas por
Internet o el Intercambio de bienes y servicios realizado a través de redes
teleinformáticas, soportados en plataformas y protocolos de comunicación
estandarizados a nivel global. Agentes del e-commerce Existen tres elementos o
categorías principales que soportan el comercio electrónico: Administración (A),
Empresa (B) y Consumidor (C), que pueden generar diferentes tipos de
transacciones comerciales que benefician de manera global a cualquiera de ellos:
Tipos Business toBusiness Se trata de la transacción que se realiza entre
empresas.
En ocasiones estas empresas clientes se agrupan o asocian creando

portales de empresas (por ejemplo de alimentación , vestido, industrias químicas,
restauración, etc.).
Sistemas Distribuidos
Definición: "Sistemas cuyos componentes hardware y software, que están en

ordenadores conectados en red, se comunican y coordinan sus acciones mediante
el paso de mensajes, para el logro de un objetivo. Se establece la comunicación
mediante un protocolo prefijado por un esquema cliente-servidor".
Características: Concurrencia.- Esta característica de los sistemas distribuidos

permite que los recursos disponibles en la red puedan ser utilizados
simultáneamente por los usuarios y/o agentes que interactúan en la red.
Carencia de reloj global.- Las coordinaciones para la transferencia de

mensajes entre los diferentes componentes para la realización de una tarea, no
tienen una temporización general, esta más bien distribuida a los componentes.

Fallos independientes de los componentes.- Cada componente del sistema
puede fallar independientemente, con lo cual los demás pueden continuar
ejecutando sus acciones. Esto permite el logro de las tareas con mayor
efectividad, pues el sistema en su conjunto continua trabajando.
Evolución: Procesamiento central (Host).- Uno de los primeros modelos de

ordenadores interconectados, llamados centralizados, donde todo el
procesamiento de la organización se llevaba a cabo en una sola computadora,
normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores
personales.
Los problemas de este modelo son:
Cuando la carga de procesamiento aumentaba se tenía que cambiar el

hardware del Mainframe, lo cual es más costoso que añadir más computadores
personales clientes o servidores que aumenten las capacidades.
El otro problema que surgió son las modernas interfases gráficas de

usuario, las cuales podían conllevar a un gran aumento de tráfico en los medios de
comunicación y por consiguiente podían colapsar.
Grupo de Servidores.- Otro modelo que entró a competir con el anterior,

también un tanto centralizado, son un grupo de ordenadores actuando como
servidores, normalmente de archivos o de impresión, poco inteligentes para un
número de Minicomputadores que hacen el procesamiento conectados a una red
de área local.
Los problemas de este modelo son:
Podría generarse una saturación de los medios de comunicación entre los

servidores poco inteligentes y los minicomputadores, por ejemplo cuando se
solicitan archivos grades por varios clientes a la vez, podían disminuir en gran
medida la velocidad de transmisión de información.

La Computación Cliente Servidor.- Este modelo, que predomina en la
actualidad, permite descentralizar el procesamiento y recursos, sobre todo, de
cada uno de los servicios y de la visualización de la Interfaz Gráfica de Usuario.
Esto hace que ciertos servidores estén dedicados solo a una aplicación
determinada y por lo tanto ejecutarla en forma eficiente.
Comercio Electrónico
Definido de una forma muy amplia e ideal, comercio electrónico o e-

commerce es una moderna metodología que da respuesta a varias necesidades
de empresas y consumidores, como reducir costes, mejorar la calidad de
productos y servicios, acortar el tiempo de entrega o mejorar la comunicación con
el cliente. Más típicamente se suele aplicar a la compra y venta de información,
productos y servicios a través de redes de ordenadores. En los últimos tiempos el
termino se presenta siempre como invariablemente ligado al desarrollo de Internet,
se dice que la mensajería electrónica o e-mail fue el primer incentivo para que
Internet se convirtiese en una herramienta habitual en la vida de mucha gente, y
que el comercio electrónico podría ser ese segundo gran empujón que la red
necesita para que su uso se convierta de verdad en algo general y cotidiano.
Características: Para la empresa, los mercados electrónicos suponen una difusión

de la información -y a veces del propio producto- sin prácticamente coste marginal
alguno, es decir, no supone coste diferencial el hecho de que mi periódico en
Internet lo lea yo sólo o lo lean cien millones de personas, porque no tengo que
pagar un soporte físico -el papel- para mi información, me limito a ponerla ahí al
alcance del público.

Práctica no. 6
Nombre de la práctica: Ejercicio de Introducción Internet Web
Identificar los conceptos básicos de la Internet y la

Objetivo
Web.
En informática, la World Wide Web (WWW) o Red

Introducción
informática mundial1 comúnmente conocida como la
Web, es un sistema de distribución de documentos de
hipertexto o hipermedios interconectados y accesibles
vía Internet. Con un navegador web, un usuario
visualiza sitios web compuestos de páginas web que
pueden contener texto, imágenes, vídeos u otros
contenidos multimedia, y navega a través de esas
páginas usando hiperenlaces.
La Web se desarrolló entre marzo de 1989 y

diciembre de 19902 3 por el inglés Tim Berners-Lee
con la ayuda del belga Robert Cailliau mientras
trabajaban en el CERN en Ginebra, Suiza, y publicado
en 1992. Desde entonces, Berners-Lee ha jugado un
papel activo guiando el desarrollo de estándares Web
(como los lenguajes de marcado con los que se crean
las páginas web), y en los últimos años ha abogado
por su visión de una Web semántica.
Utilizando los conceptos de sus anteriores sistemas

de hipertexto como ENQUIRE, el ingeniero británico
Tim Berners-Lee, un científico de la computación y en
ese tiempo de los empleados del CERN, ahora
director del World Wide Web Consortium (W3C),

escribió una propuesta en marzo de 1989 con lo que
se convertiría en la World Wide Web.4 la propuesta de
1989 fue destinada a un sistema de comunicación
CERN pero Berners-Lee finalmente se dio cuenta que
el concepto podría aplicarse en todo el mundo.5 En la
CERN, la organización europea de investigación cerca
de Ginebra, en la frontera entre Francia y Suiza,6
Berners-Lee y el científico de la computación belga
Robert Cailliau propusieron en 1990 utilizar el
hipertexto "para vincular y acceder a información de
diversos tipos como una red de nodos en los que el
usuario puede navegar a voluntad",7 y Berners-Lee
terminó el primer sitio web en diciembre de ese año.8
Berners-Lee publicó el proyecto en el grupo de
noticias alt.hypertext el 7 de agosto de 1991.9

Material y Equipo
1. Realiza lectura de los artículos relacionados

Metodología
con la Internet y de la web que se proporcionan
en la plataforma Moodle
2. Contesta el ejercicio automatizado de la
plataforma moodle
Revisa los materiales antes de contestar el ejercicio.

Sugerencias

Práctica no. 7
Nombre de la práctica: Ejercicio E_Commerce en hotpotatoes
Resolver el ejercicio de comercio electrónico para

Objetivo
comprender los conceptos referentes al tema.
La incorporación de este nuevo método de ventas

Introducción
permite que los clientes accedan de manera simple y
desde cualquier parte del mundo a los productos y
servicios que una empresa ofrece.
E-commerce o Comercio Electrónico consiste en la

distribución, venta, compra, marketing y suministro de
información de productos o servicios a través de
Internet. Conscientes de estar a la vanguardia, las
Pymes no se han quedado atrás en este nuevo
mercado, por lo que han hecho de los servicios de la
red un lugar que permite acceder a sus productos y
servicios durante las 24 horas del día.
Tipos de comercio electrónico:
 B2C (Business-to-Consumer): Empresas que

venden al público en general.
 B2B (Business-to-Business): Empresas
haciendo negocios entre ellas.
 B2G (Business-to-Government): Empresas que
venden a instituciones de gobierno.
 C2C (Consumer-to-Consumer): Plataforma a
partir de la cual los consumidores compran y
venden entre ellos.

Ventajas del comercio electrónico en las empresas
 Expandir la base de clientes al entrar a un

mercado más amplio.
 Extender el horario de venta las 24 horas del
día, los siete días de la semana, 365 días al
año.
 Crear una ventaja competitiva.
 Reducir costos de producción, capital,
administración, entre otros.
 Mejorar la comunicación con los clientes y
efectividad de campañas publicitarias.

Material y Equipo

Metodología
plataforma moodle
Sugerencias

Práctica no. 8
Nombre de la práctica: Fundamentos del Mercadeo
Conocer todo lo referente al mercadeo electrónico

Objetivo
usando como base el ebook de comercio electrónico.
El Mercadeo Electrónico consiste en todas aquellas

Introducción
actividades de mercadeo que involucran el uso de
Internet, E-Mail o Web, para transmitir un mensaje
comercial a un grupo objetivo.
El mercadeo electrónico no debe contemplarse como

una tecnología, sino que es el uso de la tecnología
para mejorar la forma de llevar a cabo las actividades
de mercadeo.

Material y Equipo

Metodología
plataforma moodle
Sugerencias


Unidad 3.
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y

cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta
calidad en la World Wide Web.1
La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web

está ocasionando un impacto en la sociedad y el nuevo manejo que se le está
dando a la información en las diferentes áreas en que se presenta ha hecho que
las personas tiendan a realizar todas sus actividades por esta vía.
Desde que esto empezó a suceder el Internet se volvió más que una diversión y
empezó a ser tomado más en serio, ya que el aumento de publicaciones y de
informaciones hizo que la Web se volviera como un desafío para los (Ingeniería
del software) ingenieros del software, a raíz de esto se crearon enfoques
disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos
específicos de este nuevo medio.

Práctica no. 9
Nombre de la práctica: Fase 1 Plan de Negocios para Proyecto IWeb
Definir el Plan de Negocios como propuesta de

Objetivo
desarrollo de un Proyecto de Ingeniería Web.
Los puntos a considerar en un Plan de Negocios son:

Introducción
1. Resumen ejecutivo
2. Descripción del producto y valor distintivo
3. Mercado potencial
4. Competencia
5. Modelo de negocio y plan financiero
6. Equipo directivo y organización
7. Estado de desarrollo y plan de implantación
8. Alianzas estratégicas
9. Estrategia de marketing y ventas
10.Principales riesgos y estrategias de salida
Material y Equipo
4. Conformar equipo de trabajo con diversos

Metodología
roles
5. Descargar el formato para elaborar la fase 11).
Se encuentra disponible en la plataforma virtual
de aprendizaje del Instituto, también en
plataformas como www.slideshare.net,
www.issuu.com, www.googledocs.com,
www.scribd.com.

6. Resolver cada uno de los puntos propuestos en
la fase del proyecto
7. Elaborarlo en formato digital
8. Subirlo a la Plataforma Virtual de Aprendizaje
Puedes revisar diversos materiales referentes a la

Sugerencias
elaboración de Planes de Negocios.
En Ingeniería de Software se aprendió sobre el

Modelado de Negocios, el cuál puede ser aplicado en
esta fase del proyecto.
De la misma manera la materia de Administración de

Proyectos aporta elementos para generar un Plan de
Negocios bajo el esquema del PMBook, que se puede
aplicar a la fase inicial del proyecto.
Figura 1 Formato Fase 1 proyecto IWeb


Unidad 4.
Requisitos para el análisis de las WebApp
El análisis de requisitos para las WebApp abarca tres grandes tareas:
• Formulación
• Recopilación de requisitos
• Modelado de análisis
La jerarquía de usuario
Las categorías de los usuarios finales se identifican como parte de las tareas de
formulación y de recopilación de requisitos. Las categorías de usuarios son
relativamente limitados y no necesitan una representación UML. Sin embargo,
cuando crece el número de categorías de usuario, a veces es aconsejable
desarrollar una jerarquía de usuarios.
Desarrollo de casos de uso
Los casos de uso se desarrollan para cada categoría de usuario descrita en la

jerarquía de usuario. En el contexto de la ingeniería Web, el caso de uso en sí
mismo es relativamente informal: un párrafo narrativo que describe una interacción
especifica entre el usuario y la WebApp.
Afinación del modelo de caso de uso
A la par que se crean los diagramas de casos de uso para cada categoría de
usuario, se desarrolla una vista superior de los requisitos de la WebApp
observables de manera externa.
Cada paquete se valora para garantizar que es:
 Comprensible.
 Cohesivo
 Libremente acoplados
 Jerárquicamente superficial.
El modelado de análisis para WebApps
Se basa en la información que contienen los casos de uso desarrollados para l

aplicación. Se identifican el contenido que presentará la WebApp y se extraen las
funciones que se desarrollarán a partir de las descripciones de caso de uso.
Finalmente los requisitos específicos de la implementación se deben desarrollar
de modo que el ambiente y la infraestructura que apoyan la WebApps puedan
construirse.
Cuatro actividades de análisis, cada una con su aporte a la creación de un modelo

de análisis completo son:
 Análisis de contenido
 Análisis de interacción
 Análisis de funciones
 Análisis de configuración
El modelo es si mismo contiene elementos estructurales y dinámicos. Los

elementos estructurales identifican las clases de análisis y los objetivos de
contenido que se requieren para crear una WebApp que satisfaga las necesidades
del cliente.
Los elementos dinámicos del modelo de análisis describen como interactúan los
elementos estructurales, entre ellos y con los usuarios finales.

El modelo de contenido
El modelo de contenido contiene elementos estructurales que proporcionan una

importante visión de los requisitos de contenido para una WebApp. Además
incluye todas las clases de análisis: entidades visibles para el usuario que se
crean o manipulan conforme éste interactúa con la WebApp.
Al igual que otros elementos del modelo de análisis, el modelo de contenido se

deriva a partir de un examen cuidadoso de los casos de uso desarrollados para la
WebApp.
Definición de objetos de contenido
Un objeto de contenido puede ser una descripción textual de un producto, un

artículo que describa un evento noticioso.
Los objetos de contenido se extraen en los casos de uso al examinar la

descripción del escenario para referencias directas e indirectas al contenido.
Relaciones de jerarquía de contenido
El modelo de contenido puede contener diagramas de relación de entidades o

árboles de datos que bosquejan las relaciones entre los objetos de contenido o la
jerarquía de éste que mantiene una WebApp.
El modelo de interacción
Este modelo de interacción lo comprenden cuatro elementos:
 Casos de uso
 Diagramas de secuencia
 Diagramas de estado
 Prototipo de interfaz de usuario

Casos de Uso
Un caso de uso se modela para todos los procesos que la WebApp debe llevar a
cabo. Los procesos se describen dentro del caso de uso por una descripción
textual o una secuencia de pasos ejecutados.
Los Diagramas de Actividad se pueden usar también para modelar escenarios

gráficamente. Una vez que el comportamiento de la aplicación está captado de
esta manera, los casos de uso se examinan y amplían para mostrar qué objetos
se interrelacionan para que ocurra este comportamiento.
Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia

temporal de eventos. En particular, muestra los objetos participantes en la
interacción y los mensajes que intercambian ordenados según su secuencia en el
tiempo.
El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y

actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor
tiene una línea vertical, y los mensajes se representan mediante flechas entre los
distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas
(como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen
izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
Diagramas de Estado
El comportamiento en tiempo real de cada clase que tiene comportamiento

dinámico y significativo, se modela usando un Diagrama de Estado. El diagrama
de actividad puede ser usado también aquí, esta vez como una extensión del
diagrama de estado, para mostrar los detalles de las acciones llevadas a cabo por
los objetos en respuesta a eventos internos. El diagrama de actividad se puede
usar también para representar gráficamente las acciones de métodos de clases.

Prototipo de interfaz de usuario
Algunas propuestas se basan en obtener de la definición de requisitos prototipos

que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario
hacerse una idea de la estructura de la interfaz del sistema con el usuario. Esta
técnica tiene el problema de que el usuario debe entender que lo que está viendo
es un prototipo y no el sistema final.
Puesto que las herramientas de desarrollo de la WebApp son abundantes y

funcionalmente poderosas, es mejor crear prototipos de la interfaz mediante tales
herramientas.
El modelo funcional
Este modelo funcional aborda dos elementos de procesamiento de la WebApp y

cada uno representa un gráfico diferente de la abstracción de procedimiento:
 Funcionalidad observable respecto al usuario y que entrega al usuario

final de WebApp.
 Las operaciones dentro de las clases de análisis que implementan
comportamientos asociados con la clase.
La funcionalidad observable para el usuario comprende cualesquiera funciones de

procesamiento que éste indicia directamente. Por ejemplo, un sitio Web financiero
puede implementar una variedad de funciones financieras.
El modelo de configuración
Las WebApps se deben diseñar e implementar de forma que se acomoden a una

diversidad de ambientes, tanto del lado del servidor como del cliente. Se deben
especificar el hardware del servidor y el ambiente del sistema operativo. Si las
WebApp deben tener acceso a una gran base de datos o ínter operar con las
aplicaciones corporativas existentes en el lado del servidor, se deben especificar
las interfaces apropiadas, los protocolos de comunicación y la información.

Las WebApp deben someterse a una amplia prueba de cada configuración de
navegador que se especifique como parte del modelo de configuración.
Análisis relación – navegación (ARN)
El análisis relación-navegación proporciona una serie de pasos de análisis que

luchan por identificar relaciones entre los elementos descubiertos como parte de la
creación del modelo de análisis.
El enfoque de ARN se organiza en cinco pasos:
 Análisis de los participantes

 Análisis de los elementos
 Análisis de relaciones
 Análisis de navegación
 Análisis de evaluación.
Análisis de relaciones: preguntas claves
En este análisis se formulan una serie de preguntas que nos ayudará a

comprender más la relación.
Análisis de navegación
Uno de los aspectos más importantes en los sistemas de información en las

WebApp es el de la navegación. La gran mayoría de las propuestas metodológicas
para sistemas WebApp resaltan este aspecto ofreciendo modelos que permitan
diseñarlo e implementarlo asegurando la calidad del resultado.
Sin embargo, analizando dichos modelos y técnicas y viendo los resultados de

diferentes estudios comparativos, se puede observar que este aspecto, en la
mayoría de las propuestas, se trata solamente en las últimas fases del ciclo de
vida, principalmente en diseño e implementación.

Los mecanismos de navegación se definen como parte del diseño. En esta etapa,
los desarrolladores deben considerar requisitos de navegación globales.

Práctica no. 10
Nombre de la práctica: Fase 2 Análisis de Aplicaciones Web
Elaborar la Fase 2 de Análisis de Aplicaciones Web

Objetivo
de la Ingeniería Web utilizando el Lenguaje de
Modelado Unificado con ayuda de Herramientas de
Software.
El Análisis de aplicaciones web se centra en tres

Introducción
áreas:
 la información o contenido que se presenta

 las funciones del usuario final a ejecutar
 los comportamientos de aplicación web que se
presenta en respuesta a acciones del usuario.
Los ingenieros de red, especialistas en contenido, y

las partes interesadas desarrollan el modelo de
análisis. Los análisis de modelos permiten que el
equipo de ingeniería Web para crear una
representación concreta de los requisitos de
aplicación web.
El Análisis de una aplicación web se centra en cuatro

aspectos fundamentales del problema:
 contenidos
 interacción
 función
 configuración

El producto del trabajo de análisis de modelos IWeb

es un conjunto de diagramas UML y un texto
descriptivo que describe los resultados de los cuatro
análisis realizados. Los Productos de trabajo de
análisis son revisados para la corrección, integridad y
consistencia.
Condiciones que favorecen el análisis de modelos
 Grandes o complejos WebApp ser construidos

 Gran número de interesados
 Un gran número de ingenieros Web y otros
colaboradores
 Las metas y los objetivos de aplicación web
afectará a la línea de negocios inferior
 Éxito aplicación web tendrá gran influencia en
el éxito de la empresa
Requisitos de tareas de análisis de aplicación web
Formulación
 Identificar las metas y objetivos para la

aplicación web
 Definir las categorías de usuarios y crear la
jerarquía de usuario
La recopilación de requisitos
 La comunicación entre el equipo Web y las

partes interesadas intensifica

 Contenido y requisitos funcionales se

enumeran
 Los escenarios de interacción (casos de uso)
son desarrollados

Material y Equipo
 Microsoft Visio o Concept Draw o DIA
1. Conformar equipo de trabajo con diversos roles

Metodología
2. Descargar el formato para elaborar la fase 2.
www.scribd.com.
Para esta fase de proyecto es importante haber

Sugerencias
cumplido y acreditado la fase 1 del proyecto. Para
Modelar el Análisis se requiere de los diagramas de
caso de uso y los diagramas de clase del UML
generados en la fase 1 del proyecto.
En esta fase también se requiere el uso de

herramientas de elaboración de diagramas UML.

Figura 2 Formato Fase 2 de proyecto IWeb


Unidad 5.
Temas de diseño para ingeniería Web

Cuando se aplica el diseño dentro del contexto de la ingeniería Web, se deben
considerar cuestiones tanto genéricas como específicas. El diseño debe ser muy
específico.
Diseño de calidad de una WebApp

En la práctica, la calidad de los sitios web se ha evaluado de una manera “ad hoc”,
basada en el sentido común y en la experiencia de los desarrolladores. El estudio
de la calidad de productos y procesos de desarrollo para la Web es muy reciente y
todavía no se dispone de métodos de evaluación ampliamente difundidos para
este tipo de entorno.
Por lo tanto, existe la gran necesidad de metodologías efectivas para la obtención

de aplicaciones Web de calidad. Actualmente, hay dos vertientes de metodologías
de desarrollo para la Web: la comunidad de Ingeniería de Software y la comunidad
de Hipermedia. Estas metodologías carecen sin embargo de métricas que puedan
ser aplicadas a los modelos intermedios (Ej. Modelo de Objetos, Modelo
Navegacional) utilizados en el proceso de desarrollo orientado a la Web.
Otras características de diseño de calidad Web son:
 Seguridad
 Disponibilidad
 Escalabilidad
 Tiempo en el mercado

Metas de diseño
Una de las metas de diseño de una WebApp es abarcar lo siguiente:
 Simplicidad
 Consistencia
 Identidad
 Robustez
 Navegabilidad
 Apariencia visual
 Compatibilidad
Pirámide del diseño IWEB

El diseño conduce a un modelo que contiene una mezcla adecuada de estética,
contenido y tecnología.
En la figura 3 se muestra la pirámide de diseño de ingeniería Web.
Figura 3 Modelado del Diseño IWeb. Fuente: (PRESSMAN, 2006)

Diseño de la interfaz de la WebApp

Toda interfaz de usuario debe presentar las siguientes características:
 Fácil de usar
 Fácil de aprender
 Fácil de navegar
 Intuitiva
 Consistente
 Eficiente
 Libre de errores
 Funcional
Debe ofrecer al usuario final una experiencia satisfactoria y gratificante.
Los principios y directrices esenciales del diseño de una WebApp se pueden

mencionar:
 Uso equitativo
 Flexibilidad en el uso
 Uso sencillo e intuitivo
 Información perceptible
 Tolerancia al error
 Esfuerzo físico reducido
 Tamaño y espacio para acercarse y usar
En un momento de nuestra vida, cualquiera de nosotros puede llegar a

experimentar una transición física. Ya sea una minusvalía temporal, como un
hueso roto, o una discapacidad permanente, nos veremos enfrentados al cambio.
El simple proceso de envejecimiento nos lleva a ser dependientes de otros. El

diseño universal nos permite transitar por esos cambios y seguir disfrutando de
igualdad de oportunidades, autodeterminación y calidad de vida.

Práctica no. 11
Nombre de la práctica: Fase 3 Diseño para aplicaciones Web
Desarrollar el Modelado del Diseño de la aplicación

Objetivo
Web que ha estado resolviendo desde la Fase 1.
Cuando se aplica el diseño dentro del contexto de la

Introducción
ingeniería Web, se deben considerar cuestiones tanto
genéricas como específicas. El diseño debe ser muy
específico.
Diseño de calidad de una WebApp
En la práctica, la calidad de los sitios web se ha

evaluado de una manera “ad hoc”, basada en el
sentido común y en la experiencia de los
desarrolladores. El estudio de la calidad de productos
y procesos de desarrollo para la Web es muy reciente
y todavía no se dispone de métodos de evaluación
ampliamente difundidos para este tipo de entorno.
Por lo tanto, existe la gran necesidad de metodologías

efectivas para la obtención de aplicaciones Web de
calidad. Actualmente, hay dos vertientes de
metodologías de desarrollo para la Web: la comunidad
de Ingeniería de Software y la comunidad de
Hipermedia. Estas metodologías carecen sin embargo
de métricas que puedan ser aplicadas a los modelos
intermedios (Ej. Modelo de Objetos, Modelo
Navegacional) utilizados en el proceso de desarrollo
orientado a la Web.


Material y Equipo
 Microsoft Visio o Concept Draw o DIA
 www.mex.tl , www.1&1.mx ,
www.mipaginawebgratis.es, entre otras páginas
que permitan el diseño de la página web.
 Herramientas de diseño de páginas web
1. Conformar equipo de trabajo con diversos roles

Metodología
2. Descargar el formato para elaborar la fase 3.
www.scribd.com.
5. Generar la página Web en algunas de las
herramientas de la web o herramientas de
desarrollo de páginas web
Es recomendable que utilices las herramientas de

Sugerencias
desarrollo de páginas web que están disponibles en la
Web de manera gratuita, ya que podrás ver tu
creación en internet.

Figura 4 Fase 3 Proyecto IWeb


Unidad 6.
Pruebas de conceptos para WebApp

Se consideran las dimensiones de calidad que son particularmente relevantes en
cualquier debate de las pruebas para el trabajo de ingeniería Web. Se considera
también la naturaleza de los errores que se encuentran como consecuencia de las
pruebas y la estrategia de poner a prueba aplicable para descubrir dichos errores.
Dimensiones de calidad
La calidad se incorpora en una aplicación Web como consecuencia de un buen
diseño. Se evalúa al aplicar una serie de revisiones técnicas que valoran varios
elementos del modelo de diseño y al aplicar una serie de revisiones técnicas que
valoran varios elementos del modelo de diseño y al aplicar un proceso de pruebas.
Tanto las revisiones como las pruebas examinan una o más de las siguientes
dimensiones de calidad:
El contenido se evalúa tanto en el ámbito sintáctico y semántica
La función de prueba para descubrir errores que indiquen que no hay

concordancia con los requisitos del cliente.
La estructura se valora para asegurarse de que entrega adecuadamente contenido

y función de la WebApp.
La facilidad de uso se prueba para garantizar que a cada categoría de usuario la

soporta la interfaz.
*La navegabilidad se pone a prueba para garantizar que toda la sintaxis y

semántica de navegación se ejercen para descubrir cualquier error de navegación.

*El desempeño se prueba en una diversidad de condiciones operativas,
configuraciones y cargas para asegurar que el sistema responde a la interacción
del usuario.
La compatibilidad se prueba al ejecutar las WebApp en varias configuraciones

huésped.
La interoperabilidad se prueba para asegurar que la WebApp realiza interfaces

adecuadas.
La seguridad se prueba al valorar las vulnerabilidades potenciales e intentar

explotar cada una de ellas.
Estratégicas de prueba
Las estrategias para probar una WebApp adoptan los principios básicos para
todas las pruebas de software.
1. Se revisa el modelado de contenido de la WebApp para descubrir errores.
2. Se revisa el modelo de la interfaz para asegurarse que todos los casos
Las pruebas que se aplican a una aplicación web
El proceso de someter a prueba la WebApp es una suma de actividades

relacionadas con una sola meta: descubrir errores en el contenido, la función, la
facilidad de uso, la navegabilidad, el desempeño, la capacidad y la seguridad de la
WebApp.
Esto se logra a lo largo de todo el proceso de ingeniería Web, mediante la

aplicación de una estrategia de prueba que abarca tanto revisiones como pruebas
ejecutables.
Los ingenieros Web y otros participantes del proyecto (gerentes, clientes, usuarios
finales) toman parte en el proceso de probar WebApp.

Si los usuarios finales encuentran errores que afecten su confianza en la
WebApp, se irán a cualquier otra parte por el contenido y la función que necesitan,
y la WebApp fracasará.
Por esta razón, los ingenieros de la Web deben trabajar para eliminar tantos
errores como sea posible antes que la WebApp esté en línea.
El proceso de prueba comienza en enfocarse sobre aquellos aspectos de ésta

que son visibles para el usuario y procede a probar dicha tecnología e
infraestructura.
La prueba consta de siete etapas: contenido, interfaz, navegación, componente,

configuración, desempeño y prueba de seguridad.
En algunos casos se produce un plan de prueba de la WebApp.
En todos los casos se desarrolla un conjunto de casos de prueba para cada etapa
de la prueba y se observa un archivo de resultados de pruebas para uso futuro.
Aunque nunca se puede estar seguro de que han llevado a cabo todas las
pruebas que se necesitan, puede tenerse la seguridad de que la puesta en prueba
ha descubierto errores ( y que éstos se han corregido).
Además, si se ha establecido un plan de prueba, puede verificarse para asegurar

que se han realizado todas las pruebas planeadas.
Puesto que muchas WebApps evolucionan continuamente, la prueba de la

WebApp es una actividad de seguimiento que dirige el equipo de soporte Web,
que utiliza pruebas de regresión derivadas de las pruebas desarrolladas cuando la
WebApp se sometió a ingeniería por primera ocasión.

Práctica no. 12
Nombre de la práctica: Evento Académico #IWEB
Aplicar todo el proceso de pruebas a la Página Web

Objetivo
desarrollada mostrando evidencia de la aplicación en
un documento digital.
La estrategia para probar una WebApp, adopta los

Introducción
principios básicos para todas las pruebas de software
y aplica una estrategia y las tácticas que se
recomendaron respecto de los sistemas orientados a
objetos como se indica a continuación:
Revisión del modelo de contenido de la WebApp en

busca de errores
Revisión del modelo de la interfaz asegurándose que

todos los casos de uso pueden acomodarse
Revisión del modelo de diseño de la WebApp en

busca de errores de navegación
Se prueba la interfaz de usuario para descubrir

errores en la presentación o los mecanismos de
navegación.
Componentes funcionales seleccionados se prueban

en forma individual.
Se llevan a cabo pruebas de desempeño.
Se prueba la WebApp en una población controlada y

monitoreada de usuarios finales buscando errores

relacionados con la facilidad de uso, con la
compatibilidad, confiabilidad y desempeño de la
WebApp.

Material y Equipo
1. Conformar equipo de trabajo

Metodología
2. Tener diversos dispositivos con acceso a
internet
3. Cargar la página Web que desarrollaron
4. Aplicar cada una de las pruebas de IWeb
5. Documentar y agregar evidencia de las
pruebas aplicadas
6. Entregar en la plataforma virtual el documento
de pruebas.
Es necesario que todo el equipo participe en la

Sugerencias
prueba de la página web.
Las pruebas no se pueden aplicar si no está

terminada la página Web.

FORMATO DE REPORTE DE PRÁCTICAS

Formato de Reporte de Prácticas
Reporte por práctica
Nombre del
Alumno
Práctica No. Nombre de la

práctica
Unidad No. Fecha de realización
1. ¿En qué consistió la práctica?
2. ¿Cómo la vinculó con sus conocimientos?
3. ¿Cómo la desarrolló?
4. ¿A qué resultados llegó?
5. ¿Qué problemas se le presentaron?
6. ¿Qué dudas no pudo resolver?

Reporte final de todas las prácticas
Los elementos que debe contener el reporte final de las prácticas realizadas en la
asignatura de Lenguajes y Autómatas son:
 Portada
 Índice
 1. Introducción
 2. Marco Teórico
 3. Desarrollo de la práctica (la descripción de la práctica del manual)
 4. Resultados (cada uno de los reportes por práctica)
 5. Conclusiones y Recomendaciones (de todas las prácticas)
 6. Bibliografía (utilizar formato APA o ISO 690 b)
 7. Anexos (opcional)
o Tales como:
 Finalidad de la práctica
 Síntesis del contenido.
 Definiciones, conceptos, fórmulas, etc.
 Descripción del método utilizado
 Materiales y equipo
 La ejecución del trabajo, aplicación de fórmulas, duración de
la práctica.
 Explicación de los resultados que se obtuvieron en el
desarrollo de la práctica.
 Respecto a la práctica, al desempeño del maestro,
consideraciones respecto a la experiencia obtenida al realizar
la práctica.
 La experiencia que el estudiante utilizó para planear y
desarrollar su práctica.
 Tablas, formatos, dibujos, planos, diagramas, fotografías, etc.

Bibliografía
1. Cuevas, I., Ingeniería de la Web y Patrones de Diseño. 2005.
2. Arlow, J. and I. Neustad, UML 2. Programación. Anaya Multimedia-Anaya

Interactiva, 2006.
3. Booch, G., et al., El lenguaje unificado de modelado. 1999: Addison Wesley

Madrid.
4. Cuevas Agustín, G., Gestión del proceso software. 2002.
5. Fowler, M., R. SCOTT, and K. Scott, UML gota a gota. 1999: Pearson
Educación.
6. Fuente, A.A.J., et al., El libro Azul de la Ingeniería en Informática: una

alternativa al Libro Blanco. I Jornadas de Innovación Docente de la EUITIO,
2005: p. 67.
7. García Molina, J.J., G. Rossi, and A. Moreira, UML: el lenguaje estándar

para el modelado de software. Novática: Revista de la Asociación de
Técnicos de Informática, 2004(168): p. 4-5.
8. Génova, G., J.M. Fuentes, and J. Llorens, Evaluación de herramientas

CASE para UML.
9. Grady, R.B., Successful software process improvement. 1997: Prentice Hall

PTR.
10. Guevera, A., Ingeniería Web: E-learning. Cultura Científica, 2011(5): p. 16-
20.
11. Hernández González, A., Identificación de Procesos de Negocio. Ingeniería

Industrial, 2010. 25(3): p. 6 pág.

12. Humphrey, W.S., Introducción al Proceso Software Personal (PSP). 2001:
Addison–Wesley.
13. Pastor, O. OOWS: Una aproximación para el Modelado Conceptual de

Aplicaciones Web. 2002.
14. Pressman, R.S. and J.M. Troya, Ingeniería del software: Un enfoque
práctico. 6ta edicion. 2006: McGraw Hill.
15. Rumbaugh, J. and I. Jacobson, Grady Booch. The Unified Modeling

Language Reference Manual (The Addison-Wesley Object Technology
Series), 2001.
16. Senn, J.A. and D. Mercer, Análisis y diseño de sistemas. 1992: México:
McGraw Hill.
17. Sommerville, I., Ingeniería del software. 2005: Pearson Educación.
18. Thomas, D., et al., Agile web development with rails. 2005: Pragmatic
bookshelf New York.

Guia para TAller de Ingenieria de Softwa

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia para TAller de Ingenieria de Softwa

Cargado por

Copyright:

Formatos disponibles

INSTITUTO TECNOLÓGICO DE CIUDAD VALLES

DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

INGENIERÍA EN SISTEMAS COMPUTACIONALES

ISC. Rosa Imelda García Chi, MTI

Datos de la Asignatura ............................................................................................ 3

Nombre de la Asignatura: Taller de Ingeniería de Software ................................. 3

Objetivos Generales del Curso de Taller de Ingeniería de Software ....................... 5

Competencias específicas a desarrollar por unidad ............................................. 5

PRÁCTICAS DE LA UNIDAD 1 ............................................................................... 7

Unidad 1. Estándares y modelos de calidad aplicados al software ........................ 8

Práctica no. 1 ........................................................................................................ 10

Nombre de la práctica: Foro ¿Qué es la calidad del software? ........................ 10

Práctica no. 2 ........................................................................................................ 12

Nombre de la práctica: Modelos de Calidad del Software ................................ 12

Práctica no. 3 ........................................................................................................ 15

Nombre de la práctica: SQA............................................................................. 15

Práctica no. 4 ........................................................................................................ 17

Nombre de la práctica: Estándares de calidad del software............................. 17

Práctica no. 5 ........................................................................................................ 20

Nombre de la práctica: Moprosoft .................................................................... 20

PRÁCTICAS DE LA UNIDAD 2 ............................................................................. 22

Práctica no. 6 ........................................................................................................ 26

Nombre de la práctica: Ejercicio de Introducción Internet Web ........................ 26

Práctica no. 7 ........................................................................................................ 28

Nombre de la práctica: Ejercicio E_Commerce en hotpotatoes ....................... 28

ING. ROSA IMELDA GARCIA CHI, MTI i

Nombre de la práctica: Fundamentos del Mercadeo ........................................ 30

PRÁCTICAS DE LA UNIDAD 3 ............................................................................. 31

Práctica no. 9 ........................................................................................................ 33

Nombre de la práctica: Fase 1 Plan de Negocios para Proyecto IWeb ............ 33

PRÁCTICAS DE LA UNIDAD 4 ............................................................................. 35

Práctica no. 10 ...................................................................................................... 43

Nombre de la práctica: Fase 2 Análisis de Aplicaciones Web.......................... 43

PRÁCTICAS DE LA UNIDAD 5 ............................................................................. 47

Temas de diseño para ingeniería Web .............................................................. 48

Pirámide del diseño IWEB ................................................................................. 49

Diseño de la interfaz de la WebApp ................................................................... 50

Práctica no. 11 ...................................................................................................... 51

Nombre de la práctica: Fase 3 Diseño para aplicaciones Web ........................ 51

PRÁCTICAS DE LA UNIDAD 6 ............................................................................. 54

Pruebas de conceptos para WebApp................................................................. 55

Las pruebas que se aplican a una aplicación web ............................................. 56

Práctica no. 12 ...................................................................................................... 58

Nombre de la práctica: Evento Académico #IWEB .......................................... 58

FORMATO DE REPORTE DE PRÁCTICAS ......................................................... 60

Formato de Reporte de Prácticas .......................................................................... 61

ING. ROSA IMELDA GARCIA CHI, MTI ii

Reporte final de todas las prácticas ................................................................... 62

ING. ROSA IMELDA GARCIA CHI, MTI iii

La Guía Técnica de Taller de Ingeniería de Software integra un conjunto de

En la tercera unidad, se aborda el tema de ingeniería web para el desarrollo

En la quinta unidad, se abordan temas que permitan al estudiante el

El objetivo es elaborar un Manual de Prácticas para la asignatura de Taller

ING. ROSA IMELDA GARCIA CHI,MTI 1

ING. ROSA IMELDA GARCIA CHI,MTI 2

Nombre de la Asignatura: Taller de Ingeniería de Software

Ingeniería en Tecnologías de la Información y

HT- HP- Créditos SATCA 2–3–5

UNIDAD 1. Estándares y modelos de calidad

UNIDAD 2. Ingeniería del software para comercio

UNIDAD 3. Ingeniería web

UNIDAD 4. Análisis de aplicaciones Web

UNIDAD 5. Diseño para aplicaciones web