Ingeniería Web

Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Ingeniería Web
Objetivo:
1. Como llevar técnicamente un proyecto de Ingeniería Web
2. Como formular y planificar proyectos Web
3. Que se debe tomar en cuenta para el análisis de aplicaciones Web
4. Que se debe tomar en cuenta para el diseño de aplicaciones Web
5. Como aplicar pruebas en aplicaciones Web.
INGENIERIA WEB
6. Atributos de las aplicaciones basados en Web (WebApp)
7. Proceso de Ingeniería Web
8. Buenas prácticas en Ingeniería Web
FORMULACION Y PLANEACION PARA INGENIERIA WEB
Preguntas para la formulación
Recopilación de requisitos para WebApps
Planeación de proyectos de Ingeniería Web
MODELADO DE ANALISIS PARA APLICACIONES WEB
Requisitos para el análisis de las WebApps
Modelo de Análisis para las WebApps
El Modelo de Contenido
El Modelo de Interacción
El Modelo Funcional
El Modelo de Configuración
Análisis relación-navegación
MODELADO DE DISEÑO PARA APLICACIONES WEB
Introducción de diseño
Diseño de la interfaz de la WebApp
Diseño Estético
Diseño de Contenido
1
Diseño Arquitectónico
Diseño Navegación
Diseño a nivel de Componentes
Métricas de diseño para WebApp
PRUEBAS EN APLICACIONES WEB
Estrategias de pruebas
Prueba de Contenido
Prueba de Interfaz del Usuario
Prueba al nivel de Componentes
Pruebas de Navegación
Pruebas de Configuración
Pruebas de Seguridad
Pruebas de Desempeño.
INGENIERIA WEB
Ingeniería Web trata con enfoques disciplinados y sistemáticos el desarrollo,

despliegue y mantenimiento de los sistemas y aplicaciones basados en Web.
Por lo que antes de comenzar a construir es mejor que se entienda el problema,

analice y diseñe una solución factible, se la implemente en una forma sólida y con
pruebas amplias.
Para este objetivo se debe:
1. Formular el problema
2. Planificar
3. Modelar los requisitos
4. Diseñar la solución
5. Construir con tecnología y herramientas especializadas
6. Evaluación por parte de los usuarios (técnicos, como empresariales).
2
Atributos de las aplicaciones basados en Web (WebApp)
Los sistemas basados en Web involucran una mezcla entre publicación impresa y
desarrollo de software, entre marketing e informática, entre comunicaciones internas y
relaciones externas y entre arte y tecnología. Por lo que la gran mayoría de WebApp
tiene las siguientes características:
1. Intensidad de red (Internet, intranet, extranet)
2. Concurrencia (gran número de usuarios tienen acceso al mismo tiempo)
3. Carga impredecible (el número de usuarios puede variar de un día a otro)

ejemplo: web del SRI, CNE
4. Desempeño (tiempo en ingreso y navegación)
5. Disponibilidad (24x7)
6. Gobernada por los datos (proveen gran cantidad y formatos de información)
7. Evolución continua / Inmediatez (la agilidad para poner productos/servicios)

time-to-market
8. Seguridad (para el manejo transaccional)
9. Sensibilidad al contenido / Estética / Temporalizable: calidad y naturaleza

estética de su contenido
10. Personalizable (ya sea la propia WebApp o el usuario personaliza su

navegación, contenido de acuerdo a sus necesidades específicas)
11. Soporte (ATC) (ayuda en línea, grupos de discusión, redes sociales y vínculos
relacionados).
Proceso de Ingeniería Web
Debido a que la Internet cambio la prioridad principal de desarrollo de que a cuando;

el proceso debe ser realizado bajo una filosofía de desarrollo ágil, en el cual se
incorpora rápidos ciclos de desarrollo.
Principios de métodos agiles:
3
Principio Descripción
Entrega La prioridad más alta es satisfacer al cliente a

temprana través de la entrega pronta y continua de software
valioso.
Participación de Los clientes deberían participar activamente en

los Clientes todo el proceso de desarrollo. Su función es
proporcionar y dar prioridad a los nuevos requisitos del
sistema y evaluar las iteraciones del sistema
Entrega Entrega con frecuencia software que funcione (de

Incremental dos semanas a un par de meses)
El software se desarrolla en incrementos con el cliente

especificando los requisitos que deben incluirse en cada
incremento
La medida principal de avance es el software que

funcione.
Equipo motivado Equipo motivado, en un ambiente de buena

comunicación, y apoyo
El equipo reflexiona a intervalos para ser más eficaz.
Competencia
Enfoque común
Colaboración
Habilidad para tomar decisiones
Capacidad para resolver problemas difusos
Confianza y respeto mutuo
Organización propia
Aceptar el Bienvenido los requerimientos cambiantes.

cambio
Espere los requerimientos del sistema para cambiar y así
diseñar el sistema para adaptarse a estos cambios
Mantenga la Enfóquese en la simplicidad tanto del software

simplicidad siendo desarrollado como el proceso de software.
Siempre que sea posible, trabajar en actividades para
eliminar la complejidad del sistema
Apoyado de una excelencia técnica y código seguro
4
Escalado Planificación flexible, versiones frecuentes del

sistema, integración continua, desarrollo basado en
pruebas y las buena comunicación del equipo.
El Marco de trabajo de IWeb debe considerar: adoptar el cambio, aliente la creatividad,

construyendo sistemas con pequeños equipos desarrollo, con un desarrollo
evolutivo/incremental, administrar el riesgo y usar cortos ciclos de desarrollo.
Se pueden utilizar varios tipos de procesos como XP (programación extrema, MSF

(Microsoft solution Framework) personalizado, ágil IWeb o Scrum.
Proceso XP (Programación extrema)
MSF personalizado
5
(Más información en el anexo MSF - MARCO REFERENCIAL PERSONALIZADO.doc)
Proceso IWeb
6
Comunicación con el cliente
12. Análisis del negocio (análisis del contexto empresarial-organizativo para la

WebApp)
1. Identifican a los participantes
2. Predicen potenciales cambios en el ambiente y requisitos
3. Se define integración entre la WebApp y otras aplicaciones del negocio,

bases de datos
13. Formulación
1. Recopilación de requisitos.
Planeación
Se definen tareas y un calendario de plazos, asignando responsables y/o ejecutores y

entregables tempranos. Se define la línea base para efectos de control de cambios (en
procesos agiles el “cambio” es una característica primordial).
Modelado
Se mezclan las funciones de análisis y diseño para crear el modelado IWeb.
1. Análisis de requisitos
1. Definir el contenido que tendrá la WebApp
7
2. Funcionalidad que se presentará al usuario
3. Modos de interacción de cada clase de usuario al momento de navegar
2. Diseño
1. Diseño de contenido/aplicación
2. Diseño de arquitectura de la información
3. Diseño de interface
4. Diseño de la navegación.
Construcción
3. Programación de acuerdo al modelado
4. Pruebas rápidas (contenido, arquitectura, interface, navegación)
5. En procesos agiles el modelado y construcción se hacen en paralelo.
Despliegue (entrega y retroalimentación)
6. configuración para su ambiente operativo
7. evaluación por parte del usuario
8. retroalimentación y ajustes.
Unido a estos cinco pasos para un proceso incremental debe ir acompañado de los
puntos básicos de administración de cambios y riesgos.
SCRUM
El enfoque de Scrum es un proceso empírico de tres pilares (transparencia, inspección

y adaptación), método ágil general, su atención se centra en la gestión del desarrollo
iterativo incremental, trabajo en equipo, es ligero, de fácil comprensión y complejo
dominar
Hay tres fases en Scrum.
1. La fase inicial, es una fase de anteproyecto, donde se establecen los objetivos

generales del proyecto y se diseña la arquitectura de software
2. Esto es seguido por una serie de ciclos de velocidad (SPRINT), donde cada ciclo
desarrolla un incremento del sistema
8
3. La fase de cierre del proyecto, concluye el proyecto, completa documentación

requerida, tales como marcos de ayuda del sistema y manuales de usuario y
evalúa las lecciones aprendidas del proyecto.
SPRINT (2 a 4 semanas)
9
Buenas prácticas en Ingeniería Web
9. tomar el tiempo necesario para entender las necesidades del negocio y los
objetivos del producto
10. describir cómo interactúan los usuarios con la WebApp basado en escenarios
11. desarrollar un plan de proyecto, así sea muy pequeño, con entregables
tempranos
12. utilizar algún tiempo para modelar lo que se construirá
13. tener presente el “cambio”
14. Manejo adecuado de seguridad
15. revisar la consistencia y calidad de los modelos
10
16. utilizar herramientas y tecnología que permitan construir WebApp con la mayor
reutilización de componentes y portabilidad
17. Diseñar pruebas amplias y probarse antes de liberar el WebApp.
FORMULACION Y PLANEACION PARA INGENIERIA WEB
Dentro del Marco de trabajo de Ingeniería Web se inicia con la formulación y

planificación.
La Formulación
Inicia con la identificación de las necesidades del negocio, exponiendo los objetivos de
la WebApp, definiendo grandes características y funciones, recopilando los requisitos
para conducen al desarrollo del modelo de análisis.
También identifica el ámbito de esfuerzo de desarrollo así como la forma de cómo

determinar un resultado exitoso.
Si bien en la formulación se deben exponer las grandes necesidades, sin embargo por
lo general también se exponen detalles o especificaciones que el cliente y el Ingeniero
Web desean hacerlo.
Preguntas para la formulación
¿Cuál es la principal motivación (necesidades del negocio) para la WebApp?
¿Cuáles son los objetivos que debe satisfacer la WebApps?
¿Quién usará la WebApp?
La idea es tener inicialmente un enunciado global y no detallado, como por ejemplo:
“HogaSeguro.com permitirá vender directamente a los consumidores, lo que eliminara

costos de intermediación. También permitirá aumentar las ventas en un 25% a las
ventas actuales anuales y penetrar en regiones geográficas que actualmente no
tenemos puntos de venta.”
De esto se podrá ahora especificar metas informativas y aplicativas como:
Informativa: “el sitio proporcionara a los usuarios especificaciones de producto

detalladas que incluyan descripciones técnicas, instrucciones de instalación y precios.”
Aplicativa: “el sitio consultara al usuario acerca de la instalación (casa, oficina) que
será protegida y realizara recomendaciones personalizadas acerca del producto y la
configuración que se utilizara”.
De estas especificaciones se podrán definir perfiles de usuario. Con esto se definirá el
ámbito para la WebApp.
11
Recopilación de requisitos para Web
Se puede recopilar por medio de una Ingeniería de requisitos común, y si adaptamos a

WebApp los objetivos serán:
9. identificar requisitos de contenido
10. identificar requisitos funcionales
11. definir escenarios de interacción para diferentes clases de usuarios.
Los pasos para esta recopilación de requisitos:
1. Pedir a los clientes que definan las categorías de usuario y describan cada
categoría
1. Cual es objetivo global del usuario cuando usa la WebApp?
2. Cuáles son los antecedentes y la pericia del usuario en relación al

contenido y la funcionalidad de la WebApp?
3. Qué características genéricas de la WebApp le gustan y/o disgustan al

usuario?
En varias ocasiones las categorías de los usuarios son relativamente limitadas

por lo que no se necesita representar en UML; sin embargo existen ocasiones
que amerita inclusive hacer una jerarquía de usuarios
2. comunicarse con los clientes para definir los requisitos básicos de la WebApp.
Para esta comunicación se usan varios mecanismos como:
1. grupo muestral tradicional (presencial con un grupo de personas)
12
2. entrevistas interactivas (electrónicos, exploración) (desde sitio web o

correo electrónico)
3. construcción de escenarios, a usuarios seleccionados se les pide que

describan interacciones específicas con la WebApp.
3. Analizar la información recopilada y utilizar la información para realizar un

seguimiento con los clientes
1. Se debe categorizar en clase de usuario y tipos de transacción
2. Se debe desarrollar lista de objetos de contenido y las operaciones que

se aplican a estos contenidos dentro de una transacción de usuario
especifico
3. Se pide a los usuarios que ordenen como gustaría que se les organizará
el contenido y su funcionalidad (straight through process – directo al
proceso)
4. Así como también listar las etiquetas que utilizaremos para enlazar a
estos contenidos y funciones
4. Definir casos de uso que describan escenarios de interacción para cada clase de
usuario (de la jerarquía de usuarios). Se describe como interactúa cada
categoría de usuario (actor) con la WebApp para lograr una acción específica.
Esto servirá para el análisis y pruebas.
Acompañado a la gráfica del caso de uso se debe describir la narrativa de los

requisitos asociados a los casos de uso. Esto se lo debe plasmar en un
13
documento formal, existen varios tipos, la IEEE sugiere el manejo de SRS o ERS
(Especificación de Requisitos de Software).
(Más información en el anexo ERS.doc).
En prácticas agiles en este punto se “dibuja” la arquitectura inicialmente para luego

concretar en la etapa de diseño.
Planeación
En un proyecto IWeb, el equipo de trabajo es multidisciplinario, es decir no solo están

los Ingenieros de Software, por lo contrario, existen los expertos en administración,
diseño y negocios; Dentro de este equipo de trabajo de Ingeniería Web están:
Desarrolladores/proveedores de contenido (no técnico), editores Web, Ingeniero Web,
Experto en dominios empresariales (metas, objetivos, requisitos), Especialista soporte
(para actualizaciones continuas), Administrador (web master).
La Ingeniería Web necesita un enfoque ágil para el manejo de proyectos que variará
dependiendo de la magnitud del proyecto, así como de cómo enfrentará su desarrollo.
Planeación de WebApp:
1. Entender el ámbito, (identificar el target para la WebApp, metas globales,

información y servicios que proporcionará la WebApp, Web competidores,
formas de medir cualitativa y cuantitativa si la web es exitosa), las dimensiones
de cambio, restricciones del proyecto, riesgos
2. Definir la estrategia del proyecto incremental (entregables tempranos), se

puede seleccionar estrategias con el concepto incremental, control de cambio,
manejo de riesgos, aseguramiento de calidad, comunicación efectiva, ágil como
lo es programación extrema (xp), IWeb o Scrum
3. Diseñar de forma general la WebApp, identificando contenido, servicios a

proveer y su arquitectura en su primera visión
4. Elaborar un plan aproximado que incluya fechas de entregables (hitos)
5. Evaluar el proyecto (dosificado de acuerdo al tamaño del proyecto).
Las peores prácticas de proyectos WebApp
Muchos proyectos WebApp fracasan por:
1. Descuido del proyecto
2. No control de cambios (informalidad de cambios se vuelve interminable el

proyecto)
3. Un enfoque desdeñoso en la recopilación de datos causa fracaso en producir un

sistema que satisfaga las necesidades del usuario
4. Un enfoque equivocado de pruebas puede producir un fracaso al producir un

sistema que se lo ponga en producción sin las pruebas acordes a sus exigencias
14
5. Se tiene una gran idea, así que se puede comenzar a construir la WebApp
ahora
6. Las cosas cambiaran constantemente, así que no tiene caso tratar de

comprender los requisitos de la WebApp
7. Se desarrolla con ingenieros de experiencia dominante de software tradicional

que no se entrenan y desarrollan WebApp inmediatamente
8. Burocratizarse.
MODELADO DE ANALISIS PARA APLICACIONES WEB
El análisis se enfoca en la respuesta de tres importantes preguntas:
9. ¿Qué información o contenido se presentará o manipulará?
10. ¿Qué funciones realizará el usuario final?
11. ¿Qué comportamientos exhibirá la WebApp conforme contenido y funciones?
Requisitos para el análisis de las WebApps
El análisis de requisitos abarca tres grandes tareas:
1. Formulación, como se mencionó anteriormente se identifica la motivación

(metas) y objetivos básicos para la WebApp, así como la definición de categoría
de usuarios. (tratado anteriormente en la formulación)
2. Recopilación de requisitos, aquí se intensifica la comunicación entre el

Ingeniero de Software y los expertos del negocio. Se listan los requisitos de
contenido y funcionales; se desarrollan escenarios de iteración (casos de uso).
La intención es el resolver el por qué se construirá la WebApp, quien la usará, y
que problema resolverá a sus usuarios. (tratado anteriormente en la
formulación)
3. Modelado de análisis, luego de la formulación y recopilación de requisitos, se
procede con el modelado de contenido, interacción, funcional, configuración y
navegación.
Modelo de Análisis para las WebApps
Como se mencionó anteriormente, luego de la recopilación de requisitos, son

analizados gramaticalmente la descripción de los casos de uso para identificar
potenciales clases de análisis con sus atributos y métodos (operaciones).
El análisis contempla las cuatro actividades siguientes.
4. modelado de Contenido
15
5. modelado de Interacción (como interactúa el usuario con la WebApp)
6. modelado funcional (operaciones de contenido y de procesamiento)
7. modelado de Configuración (ambiente e infraestructura)
8. análisis relación-navegación
Este modelo de análisis tendrá elementos estructurales (clases y objetos) mientras

que los elementos dinámicos son los que describen como interactúan los elementos
estructurales entre sí y con los usuarios finales.
El Modelo de Contenido
Este modelo contiene los elementos estructurales que son necesarios para satisfacer
los requisitos de contenido de la WebApp, como son las clases de contenido por
ejemplo texto, imágenes gráficas, fotografías, imágenes video, audio, etc. Así como
todas las clases de análisis visibles para el usuario que se crean para la interacción con
la WebApp. Estas se derivan del análisis gramatical de los casos de uso.
Un objeto de contenido es cualquier artículo de información cohesivo que se

presentará a un usuario final. Estos se incorporan por las referencias de navegación en
la WebApp.
En algunas ocasiones los objetos se los define individualmente, pero existe en otros
casos que debe hacerse un árbol de datos (jerarquía) que bosquejen las relaciones
entre los objetos de contenido según su jerarquía.
Las clases de análisis son las entidades visibles por el usuario como por ejemplo
FacturadeMateriales, ComponentedeProducto, etc.
16
Existen varias formas de representar, ya sea con el modelo CRC (Clase-

Responsabilidad-Colaborador) o con el diagrama de Clases + diagrama de colaboración
de UML.
17
Tarjeta Índice del Modelo CRC
Diagrama de Clases UML
18
Motor Piloto Vendedor de billetes
1..4 1..2 1
1 n
n
1 n 1 n
Avión Vuelo Reserva
n
{ disjunta, completa }
Avión militar Avión comercial Línea aérea
{ disjunta, completa }
Avión de carga Avión de pasajeros
Diagrama de Colaboración UML
19
:Socio
:Video
2: verificar situación socio
1: prestar(video, socio) 3: verificar situación video

:WInPréstamos
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo
El Modelo de Interacción
Las WebApp que proveen “conversación” con el usuario final deben ser modelado su
interacción por medio de cuatro elementos:
9. casos de uso (proporcionan una visión unidimensional de la interacción)
10. diagramas de secuencia: (maneja dos dimensiones) representación abreviada

de la forma como interactúa las acciones del usuario con las clases de
contenido y análisis
(*) Indica que la acción es interactiva
11. diagramas de estado (tres dimensiones), muestra a más del comportamiento

una información acerca de los patrones de navegación potenciales que no
proporciona los casos de uso y diagramas de secuencia. Estos diagramas de
estado pueden ser elaborados en diferentes niveles de abstracción.
20
12. prototipo de interfaz de usuario . Si bien la creación del prototipo de interfaz de

usuario es una actividad de diseño, se recomienda hacerlo ya en el análisis
(mientras más pronto mejor) porque se pueden obtener requerimientos
adicionales al momento que el usuario vea el prototipo. Hay que dar gran
importancia a esta definición porque es uno de los factores más importantes
para la satisfacción y aceptación global de la WebApp. Este prototipo debe
implementar los principales vínculos de navegación y representar la plantilla de
pantalla global en gran parte como será construida.
El Modelo Funcional
En el modelo funcional se aborda dos elementos:
13. funcionalidad observable respecto al usuario . Por ejemplo una calculadora para
el momento de añadir artículos al carrito de compras y para hacer cálculos de
impuestos y valores de entrega
21
14. las operaciones dentro de las clases de análisis que representan

comportamientos asociados con la clase. Una abstracción de más bajo nivel
para modelar las operaciones de las clases de análisis y sus colaboradores.
Para estos dos elementos se ocupa el diagrama de actividad de UML.
22
El Modelo de Configuración
Las WebApps deben ser construidas para que funcionen en una diversidad de
ambientes (clientes y servidores), por lo que se deben especificar las características de
hardware y software soportados, así como también especificar las interfaces bien
23
definidas y seguras para la interacción con las bases de datos y el resto de aplicaciones
de la empresa y asociadas.
Por esta razón debe someter a la WebApp a una serie de pruebas de estas
configuraciones.
Para definir este modelo de configuración en algunas ocasiones basta con solo listar los
atributos que debe tener tanto el cliente como los servidores, mientras que en otros
casos amerita modelar por medio de diagramas de despliegue UML.
24
Análisis relación-navegación
Hasta ahora se ha definido los elementos de contenido y de funcionalidad, estos

elementos interactúan frente al usuario. Conforme aumenta el número de vínculos, la
complejidad de navegación a través de la WebApp también crece. Entonces se deben
establecer los vínculos apropiados entre los objetos de contenido y las funciones.
“la navegación no solo es la acción de moverse de una página a otra, sino la idea de
moverse a través de un espacio de información”.
El ARN (análisis relación navegación) sirve para determinar la estructura de relación
de la aplicación (relaciones potenciales en los dominios que pueden implementarse
como vínculos más adelante), así como las estructuras de navegación apropiadas
sobre estos vínculos, meta-información y navegaciones adicionales .
El ARN se organiza en cinco pasos:
15. análisis de los participantes: identifica las diversas categorías de usuario. (ya se
vio en formulación anteriormente)
16. análisis de elementos: se identifica los objetos de contenido y los elementos

funcionales. (ya se vio en el modelo de contenido y en el modelo funcional)
17. análisis de relaciones: se describe las relaciones entre elementos WebApp
18. análisis de navegación: examina como los usuarios pueden acceder a

elementos individuales o grupos de elementos
19. análisis de evaluación: considera temas pragmáticos como por ejemplo:

costo/beneficio asociados con la implementación de las relaciones definidas en
los dos pasos anteriores.
Análisis de relaciones. Para valorar los elementos (objeto de contenido o función)

del modelo de análisis y comprender sus relaciones entre ellos se sugiere las siguientes
preguntas:
20. ¿El elemento es miembro de una categoría más amplia?
21. ¿Qué atributos se han identificado para el elemento?
22. ¿Ya existe información descriptiva acerca del elemento? Si es así, ¿dónde está?
23. ¿El elemento aparece en diferentes ubicaciones dentro de la WebApp? Si es así,

¿dónde?
24. ¿El elemento lo componen otros pequeños elementos? Si es así, ¿cuáles son?
25. ¿Otros elementos son similares al elemento considerado? Si es así, es posible

que puedan combinarse en un solo elemento?
26. ¿El elemento se usa en un ordenamiento específico de otros elementos? Su

aparición depende de otros elementos?
27. ¿Qué elemento siempre sigue a la aparición del elemento considerado?
28. ¿Qué condiciones previas y posteriores se deben satisfacer para utilizar el

elemento?
25
29. ¿Este elemento siempre aparece al mismo tiempo con otros elementos? Si es
así, cuales son los otros elementos?
30. ¿Las diferentes categorías de usuario emplean de manera diferente al

elemento? Si es así, ¿cómo?
31. ¿El elemento puede ser asociado con una meta u objetivo de formulación
especifico? Con un requisito WebApp especifico?.
Análisis de navegación. Para definir los requisitos de navegación siempre el usuario

debe saber dónde está y a donde va . Se debe considerar los requisitos que dictan
como navegará cada categoría de usuario de un elemento a otro. Esto se lo hace al
detalle a nivel del diseño, sin embargo, en esta etapa se consideran los requisitos de
navegación globales mediante las siguientes preguntas:
1. ¿Ciertos elementos deben ser más fáciles de alcanzar que otros (requieren
menos navegación)?
2. ¿Ciertos elementos deben resaltarse para forzar a los usuarios a navegar en su

dirección?
3. ¿Cómo se manejarán los errores de navegación?
4. ¿En cada punto de la interacción del usuario debe estar disponible un mapa o
menú de navegación completo (en oposición a solo un simple vínculo de
retroceso o punto dirigido)?
5. ¿Debe presentarse a los usuarios ciertos elementos con base en el contexto de

acciones de navegación previas?
6. ¿El diseño de la navegación debe nutrirse del comportamiento de usuario más

comúnmente esperados o mediante la importancia percibida de los elementos
WebApp definidos (navegación personalizada)?
7. ¿Un usuario puede “almacenar” su navegación para un uso futuro?
8. ¿Para qué categoría de usuario se debe diseñar una navegación optima?
9. ¿Cómo se manejarán los vínculos externos a la WebApp? Superponiendo la

ventana de navegador existente? Como una nueva ventana de navegador?
Como un marco separado?
1. ¿El usuario puede realizar un “recorrido” que subraye los elementos más
importantes (objetos de contenido y funciones) disponibles?
MODELADO DE DISEÑO PARA APLICACIONES WEB

Introducción de diseño
En pequeños WebApp deben invertirse poco tiempo en el diseño porque se asume que
los WebApp tienen la característica de inmediatez y volatilidad. Sin embargo en
26
WebApp más grandes (más de 100 objetos) deben invertirse más tiempo porque debe
aplicarse la calidad al software.
Esta calidad de software WebApp cuenta con varios requisitos que deben cumplirse
como son: facilidad de uso, funcionalidad, confiabilidad, eficiencia, facilidad de
mantenimiento.
Métricas de interfaz
Métricas estéticas (diseño gráfico)
Métricas de contenido (complejidad de contenido)
Métricas de navegación (complejidad del flujo de navegación).
A estos requisitos les podemos adicionar otros (estos los vimos en calidad de software
en sitios Web en Negocios Electrónicos) como: seguridad, disponibilidad, escalabilidad,
código seguro y time-to-market (tiempo para llegar al mercado).
Metas del diseño. Estas son aplicables a toda WepApp sin importar el tamaño o
complejidad:
1. Simplicidad: contenido moderado y simple
2. Consistencia: contenido debe guardar la misma apariencia y funcionalidad en

todas las partes de la WebApp, es decir, el diseño de la interfaz debe definir los
modos consistentes de interacción, navegación y despliegue
3. Identidad: se deberá trabajar para establecer una identidad para la WebApp,

por ejemplo la Web de usuarios hip-hop será diferente a una web financiera.
4. Robustez: el usuario espera un contenido y funcionalidad robusta (que no se

rompa)
5. Navegabilidad: a más de simple y consistente, debe ser intuitiva y predecible
6. Apariencia Visual: es básico que tenga una estética y apariencia visual

agradable.
27
7. Compatibilidad: que sea compatible para una variedad de equipos y software

de clientes.
Pirámide del Diseño IWeb. El diseño para Ingeniería Web es una mezcla adecuada
de estética, contenido y tecnología que descansa en una pirámide de 6 niveles que son
los pasos a seguir en el Diseño.
Diseño de la interfaz de la WebApp
Toda interfaz de usuario debe tener las características: fácil de usar, fácil de aprender
(en Web no debería haber capacitación), fácil navegar, intuitiva, consistente, eficiente,
libre de errores y funcional; ofreciendo al usuario final una experiencia satisfactoria y
gratificante. (directo al proceso).
Los objetivos de una interfaz WebApp son:
8. establecer una ventana consistente con el contenido y funcionalidad
9. guiar al usuario a través de una serie de interacciones con la WebApp
10. organizar las opciones de navegación y el contenido disponible para el usuario.
El diseño de la interfaz inicia con el desarrollo de las jerarquías de usuario (visto en

análisis).
El Ingeniero Web debe diseñar la interfaz de modo que conteste a las siguientes
preguntas (conforme navegue el usuario en la Web):
1. ¿Dónde estoy?
1. A que se ha tenido acceso
2. Informar la ubicación en la jerarquía de contenido
2. ¿Qué puedo hacer ahora?
28
1. Indicar sus opciones actuales (funciones disponibles, vínculos vivos,

contenido relevante)
3. ¿Dónde he estado, a donde voy?
1. Facilitar la navegación
2. Facilitar un mapa (implementado de forma fácil de entender).
Principios del diseño de la interfaz. Las interfaces efectivas son comprensibles y

ofrecen al usuario una sensación de control. No preocupa al usuario final de trabajos
internos (le es transparente), así como realizan el máximo trabajo mientras demandan
un mínimo de información a los usuarios. Con la finalidad de cumplir con esto se
plantean los siguientes principios:
4. Anticipación (diseñado de modo que anticipe el siguiente movimiento del

usuario)
5. Comunicación (debe comunicar el estado de cualquier actividad que haya

iniciado el usuario)
6. Consistencia (el uso de controles de navegación, estética deben ser

consistentes a través de toda la WebApp)
7. Autonomía controlada (debe facilitar al usuario el movimiento a través de toda

la Web pero con los controles establecidos para la aplicación)
8. Eficiencia (debe optimizar la eficiencia del usuario y no la del Ingeniero Web)
9. Flexibilidad (permita al usuario realice sus tareas directamente, mientras que a

otros exploren la Web en una forma hasta cierto punto aleatoria)
10. Enfoque (enfocarse en las tareas importantes del usuario)
11. Ley de Fitt (el tiempo para adquirir un objetivo es una función de la distancia a
la que se halla y de su tamaño. Método efectivo para modelar rápidos
movimientos dirigidos - 1950). Como por ejemplo la localización de los atributos
dentro de la página para seleccionar o ingresar información usando el ratón o
teclas debe ser de lo más cercano, fácil y obvio posible
12. Reducción de latencia (no hacer esperar al usuario hasta el final de la

operación, sino más bien continuar con el trabajo como si ya hubiese
terminado, esto por medio de multitarea). Esto debe hacerse sin descuidar que
el usuario debe saber que está ocurriendo, esto se lo puede conseguir con
varios trucos como: sonidos, reloj animado, barra en progreso o alguna
animación/presentación mientras está procesando.
13. Facilidad de aprendizaje (debe minimizar el tiempo de aprendizaje, pues en

WebApp no debería haber fase de aprendizaje por qué deber ser de loa más
intuitivo posible)
14. Metáforas (utilizar una metáfora de interacción hace más fácil el aprendizaje y
uso). Al usar una metáfora (llamando imágenes, conceptos) de experiencia
humana, es decir, como el usuario hace comúnmente esta operación fuera del
29
computador. Se puede hacer pequeñas variaciones a la metáfora para ayudarle

al usuario en su proceder (usar combos de selección)
15. Mantener la integridad del producto de trabajo (almacenar el producto de su

trabajo, de tal forma que si pasa al momento del llenado de una forma (error o
interrupción) esta información no se pierda y vuelva a utilizarse por el usuario)
16. Legibilidad (toda la información presentada debe ser legible por jóvenes y
ancianos con estilos de letras legibles, tamaños y colores adecuados)
17. Estado de rastro (cuando sea necesario, se debe guardar el rastro del estado
de la interacción del usuario, con el objetivo que, si el usuario sale y luego
desea regresar más tarde, pueda hacerlo al punto donde se quedó) esto con la
ayuda de cookies
18. Navegación visible (dar la sensación del usuario están en el mismo lugar y que
se les lleva el trabajo a sus lugares)
19. Rapidez de lectura (leer en computadora es un 25% más lento que hacerlo en
papel, por lo que NO se debe forzar al usuario a leer voluminosas cantidades de
texto)
20. Evitar signos de construcción (crean expectativas que de seguro dará

decepción)
21. Los usuarios prefieren no desplazarse (se puede mover hacia abajo, sin
embargo que no se mueva hacia la derecha)
22. Menús de navegación y los encabezados deben estar diseñados de manera

consistente y deben estar disponibles en todas las paginas disponibles para el
usuario
23. La estética no debe sustituir la funcionalidad
24. Opciones de navegación deben ser obvias (debe estar siempre bien
estructuradas y ergonómicamente saludable).
Flujo de trabajo para el diseño de la interfaz:
1. revisar la información contenida en el modelo de análisis y refinarla conforme

se requiera
2. desarrollar el bosquejo de la plantilla de la interfaz de la WebApp (en el análisis

ya se hizo un prototipo ahora ya se lo refina)
30
3. correlacionar los objetivos del usuario con acciones específicas de la interfaz

(como se observa en la figura 19.3)
4. Definir un conjunto de tareas de usuario que estén asociadas con cada acción.
(cada acción del usuario por ejemplo comprar un producto está relacionado con
un conjunto de tareas que fueron identificadas en el análisis y ahora en el
diseño se las correlaciona su interacción para identificar asuntos de navegación,
objetos de contenido y funciones)
5. Elaborar bosquejos con imágenes de la pantalla para cada acción de la interfaz
6. Refinar la plantilla de la interfaz y los bosquejos con el uso de diseño estético

(con la ayuda del diseñador gráfico)
7. Identificar los objetos de la interfaz del usuario que se requieran para

implementarla
8. Desarrollar una representación de procedimiento (comportamiento) de la

interacción del usuario con la interfaz (es opcional, se puede representar con
UML: diagramas de secuencia, actividad y de estado)
9. Describir la plantilla de la interfaz para cada estado (es opcional, si realizo el

paso 8, en función del paso 2 y 5 se debe especificar las plantillas para cada
estado)
10. Refinar y revisar el modelo de diseño de la interfaz (revisar toda la interfaz para
confirmar que exista consistencia y por sobre todo facilidad de uso).
Diseño Estético (gráfico)
También conocido como diseño gráfico, debe ser hecho por un “artista” o especialista
en diseño gráfico. Para realizar esta fase se debe regresar a la jerarquía de usuarios
desarrollado en el análisis, preguntando quienes son los usuarios de la WebApp y que
“apariencia” desean.
No existen reglas absolutas para el diseño de plantillas, sin embargo se enumeran los
siguientes lineamientos generales:
31
25. no temerle al espacio vació
26. resaltar el contenido, (el 80% debe ser contenido y el resto para la navegación
y otras características)
27. Organizar los elementos de plantilla de arriba a la izquierda hacia abajo a la

derecha (la mayor prioridad se la coloca a arriba a la izquierda)
28. Agrupar navegación, contenido y función geográficamente dentro la página (los

humanos buscamos patrones virtualmente en todas las cosas, por lo que se
debe conservarse un orden, porque caso contrario el usuario tendrá una
frustración en la búsqueda de información)
29. Preferible no permitir el uso de la barra de desplazamiento de izquierda a

derecha
30. Considerar ajustable a dispositivo “Responsive”
31. Los medios audiovisuales (imágenes, video, sonido) utilizados deben ser de lo
más liviano posible para evitar paginas lentas (considerar la realidad del
servicio de Internet de la región del usuario).
32. Agregar efectos como, por ejemplo: efecto Parallax scrolling: donde la
imagen/fondo o la textura que se encuentra como fondo de pantalla se
desplaza más lento que el resto del sitio. Si los elementos que se encuentran
más superficiales, como botones y menús, se mueven más rápido que aquellos
que se encuentran en el fondo, se crea un efecto de profundidad en la pantalla,
similar al 3D. Una recomendación, no es bueno poner todo en esta modalidad,
tiene que sobresalir lo importante, y eso se consigue gracias a un buen balance
de elementos.
Puede iniciar con colores, estampas y formas.
https://es.wix.com/blog/2015/10/que-es-el-efecto-parallax-y-como-puedes-
usarlo/
32
1. sitios web tienen largas páginas de inicio, como por ejemplo

Pinterest, Flickr y hasta tus noticias Facebook, Esto es por la cantidad de
usuarios que ingresa a las páginas web desde un dispositivo móvil aumenta,
pues prefieren desplazar su dedo y encontrar toda la información en un solo
lugar.
http://www.awwwards.com/50-examples-of-responsive-web-design.html
http://www.dtelepathy.com/blog/design/responsive-design-great-ux
http://www.graphic-design.com/
Principales tendencias de diseño gráfico 2017: El diseño web se convierte en

el diseño móvil, web progresiva (PWA).
2.
http://gtechdesign.net/es/blog/tendencias-en-diseno-grafico-2017
33
Diseño de Contenido
Se enfoca desde dos puntos de vista:
33. del Ingeniero Web que diseña los objetos de contenido y sus relaciones
34. del diseñador gráfico o publicista que se ocupa de la representación de la

información del objeto de contenido.
34
“los buenos diseñadores pueden crear normalidad a partir del caos, pueden comunicar
las ideas con claridad por medio de la organización y el manejo de las palabras y los
dibujos”
Luego del modelo de contenido en el análisis que se especificaron ciertos atributos de
las clases de contenido, se procede con la inserción de atributos específicos de
implementación propios del diseño.
Como se pudo observar en la figura 13.3 de análisis la clase ComponenteDeProducto

se puso como atributo descripción del componente. Y se crea una clase para este
atributo que tiene a su vez 5 objetos de contenido, es decir, se detalla más para estar
listo para la implementación.
Una vez que se detallan todos los objetos de contenido se deben diseñar la parte
estética (apariencia y percepción adecuada), así como se debe estructurar el número
de objetos que se insertaran en una página web conforme las necesidades del usuario
y las restricciones impuestas por el dispositivo, por rapidez en descarga y conexiones
de Internet.
Diseño Arquitectónico
El diseñador arquitectónico debe identificar la arquitectura de contenido (como se

estructura los objetos de contenido para su presentación y navegación) y arquitectura
de WebApp (la estructuración de la aplicación para gestionar la interacción con el
usuario, manejo de tareas internas, efectuar navegación y presentar el contenido).
Arquitectura de Contenido
Se centra en la definición de la estructura hipermedia global de la WebApp. A

continuación cuatro posibles estructuras de contenido:
1. Estructura lineal. Cuando existe una secuencia predecible de interacciones

(con alguna variación o desviación). Por ejemplo en presentaciones de
tutoriales, o en procesos simples de compra donde se tiene un flujo secuencial
para comprar.
35
2. Estructura en retícula (malla). Cuando el contenido está organizado

categóricamente en dos o más dimensiones. Por ejemplo la venta de palos de
golf, donde la dimensión horizontal de la retícula representa los tipos de palos
de golf, mientras que la dimensión vertical representa los diferentes fabricantes
con sus ofertas. Con esto el usuario navegara de horizontalmente para elegir el
tipo de palo y luego vertical para ver marca y/o precio.
3. Estructura jerárquica. Son las más comunes, en donde su flujo de control es

vertical por medio de las ramificaciones verticales, pero adicionalmente pueden
tener control (flujo) horizontal por medio de ramificaciones de hipertexto
pudiendo pasarse de una rama a otra directamente, sin embargo hay que tener
cuidado con esta funcional adicional porque pueden causar confusión al
usuario.
36
4. Estructura en red. Denominada “Web pura”, está diseñado para poder

navegar por medio de vínculos de hipertexto virtualmente a cualquier página
del sistema, este enfoque es el más flexible, pero al mismo tiempo puede ser el
más confuso.
De las estructuras antes mencionadas también se pueden mezclar y armar estructuras

compuestas.
Arquitectura de WebApp
Aquí se describe la infraestructura que va a tener la solución WebApp. Existe una

variedad formas de diseñar esta arquitectura/infraestructura, sin embargo todas llevan
el concepto de “multicapa”, que separan el manejo de la interfaz usuario,
navegación, comportamiento de la aplicación y de los datos.
La arquitectura MVC Modelo-Vista-Controlador es usada por varias soluciones

WebApp, que desacopla la interfaz del usuario de la funcionalidad WebApp y del
contenido de la información.
5. Modelo: el contenido de la aplicación y la lógica de procesamiento, desde aquí

se acceden a los datos
6. Vista: contiene las funciones específicas de la interfaz usuario
7. Controlador: gestiona el acceso al modelo y vista y coordina el flujo entre ellos.
37
38
Otra de las alternativas de arquitectura es basada en el concepto de

“multicanal/omnicanal” llamada Arquitectura Middleware, en donde igualmente
está separado el interfaz usuario, de las reglas del negocio y datos, pero aquí ya no
solo se diseña pensando en un único front-end Web sino más bien en varios canales
que pueda proveer el servicio (Web, App, ATM, Celular, Kiosco, Red Social, etc.). La
capa Middleware contiene manejo de interfaces, las reglas de negocio, el control de
flujo, acceso a datos y otros sistemas; bajo el concepto de reutilización por todos los
canales.
39
Integración de aplicaciones empresariales: SOA/ESB
Can
Portal Internet ales Aplicaciones
Intr ESB Perso

an nas y
et dispo
sitivo
s
So
cio
s
ProcesosAfiliados
de Core Soportes Socios de Internet
negocio negocio
Diseño Navegación
40
Una vez establecido la arquitectura de la WebApp, se diseña las rutas de navegación

que utilizaran los usuarios al acceder al contenido y las funciones WebApp. Para esto
se debe tomar en cuenta la semántica y sintaxis de la navegación.
Semántica de Navegación: identificar la semántica “sentido” de navegación para los

diferentes tipos de usuarios, esto se lo toma de las categorías de usuario y se
desarrolla un USN (Unidades Semánticas de Navegación) para cada caso de uso, en
estos USN se describen los requisitos de navegación, aquí se muestra como el actor se
mueve entre los objetos de contenido y la funcionalidad WebApp.
Sintaxis de Navegación: se define la “mecánica” de navegación, teniendo varias

opciones como:
8. vinculo de navegación individual: que son vínculos basados en texto, iconos,

botones y metáforas graficas
9. Barra de navegación horizontal: la lista de principales categorías de contenido o

funcionales en una barra (de cuatro a siete categorías)
10. Columna de navegación vertical: similar a la horizontal con la particularidad que

al momento de seleccionar una puede expandir a subcontenidos en forma de
árbol
11. Pestañas: es una variación de la de barra o columna pero que dan la sensación
de marca
12. Mapas de sitio: proporciona una tabla de contenido incluyente para la

navegación hacia todos los contenidos y funcionalidad de la WebApp.
En la mayoría de casos se elige navegaciones horizontales o verticales pero no ambas

a la vez.
Diseño a nivel de Componentes
El diseño de componentes para WebApp se los hace de manera similar que para los
sistemas convencionales orientados a objetos (sensibles al cambio y reducen la
propagación de efectos secundarios cuando ocurren cambios), pues estos varían más
bien por su ambiente de implementación y marcos de trabajo.
41
Estos componentes deben ser diseñados bajo los principios:
13. Procesamiento localizado para generar contenido y capacidad de navegación de

forma dinámica
14. Capacidad de procesamiento de datos que resultan apropiados para el dominio

del negocio
15. Consulta y acceso a base de datos
16. Establecen interfaces de datos con sistemas externos.
No está por demás recordar que los componentes al igual que las clases deben estar
bajo los conceptos de:
17. cohesión (hagan una función única) encapsulando atributos y operaciones

relacionadas estrechamente entre sí. Esta cohesión debe ser del más alto nivel
18. acoplamiento (medida cualitativa del grado en el que las clases/componentes

se conectan entre sí), este debe tratarse de mantener al más bajo nivel.
Métricas de diseño para WebApp
Las métricas de diseño deben ser creadas para facilitar al Ingeniero Web para medir la
calidad de una forma cuantitativa/cualitativa, debiendo responder a las siguientes
preguntas:
19. La interfaz del usuario promueve la facilidad de uso?
20. La estética de la WebApp es apropiada para el dominio de la aplicación y

confortable para el usuario?
42
21. El contenido está diseñado en una forma que proporciona la mayor información
con el menor esfuerzo?
22. La navegación es eficiente y directa?
23. La arquitectura de la WebApp se ha diseñado para acomodar las metas y

objetivos de los usuarios, la estructura de contenido y funcionalidad y flujo de
navegación requerido para usar el sistema de manera efectiva?
24. Los componentes están diseñados en una forma que reduce la complejidad de
procedimientos y aumenta la confiabilidad y el desempeño?.
PRUEBAS EN APLICACIONES WEB

Modelo V
Como en todo software desarrollado, debe aplicarse un plan de pruebas desde el inicio
y no esperar al final del proyecto para detectar errores. Es así que metodologías de
proyectos como MSF tienen dentro de su planificación general del proyecto un punto
dedicado a la planeación de pruebas para poder preparar los ambientes y personal
adecuado para las pruebas que por cierto son de diferentes tipos.
43
A parte de las estrategias de pruebas para software convencional orientado a objetos

que parte de la unidad hasta las pruebas de instalación, para el caso de WebApp
existen estrategias específicas que nos ayudaran a descubrir errores en:
25. el contenido: evaluación sintáctica (ortografía y gramática de contenido) y

semántica (exactitud de la información presentada y consistencia entre objetos
de contenido y objetos relacionados)
26. la función: comprobar la concordancia con los requisitos del cliente
27. estructura: se comprueba que se entregue adecuadamente el contenido y la

funcionalidad de la WebApp.
28. facilidad de uso: para cada categoría de usuario, que va relacionado con la
sintaxis y semántica de la navegación
29. navegabilidad: comprobar la sintaxis y semántica de navegación así como

comprobar que esté controlado todo flujo, por ejemplo: vínculos rotos, vínculos
inadecuados, etc.)
30. desempeño: se prueba en una diversidad de condiciones operativas,

configuraciones, y cargas para saber que el software responde adecuadamente
a cargas extremas
31. compatibilidad: se comprueba que la WebApp funciona en varias

configuraciones huésped tanto del lado del cliente como del servidor e
infraestructura de seguridad
32. interoperabilidad: se prueba para asegurar que la WebApp realiza interfaces

adecuadas con otras aplicaciones y/o bases de datos, y que estas sean con un
buen desempeño
33. seguridad: se prueba la vulnerabilidad potencial.
Estrategias de Pruebas
44
Como se menciona anteriormente, a parte las estrategias propias de orientados a

objetos se mencionan los siguientes pasos propios para una WebApp que no
necesariamente se lo hacen en secuencia:
1. revisar el modelo de contenido (sintáctica y semántica)
2. revisar el modelo de interfaz para confirmar que todos los casos de uso se
pueden acomodar
3. revisar el modelo de diseño para descubrir errores de navegación
4. revisar la interfaz del usuario para descubrir errores en la presentación o en los

mecanismos de navegación
5. se prueban los componentes funcionales de forma individual (se cambia el

concepto de unidad que en orientado a objetos era la clase ahora es la pagina
Web que tiene encapsulado contenido, vínculos, procesamiento, etc. Así como
también la unidad pueda ser un componente funcional. Es importante de igual
manera se debe hacer pruebas de integración entre componentes).
6. se prueba la navegación a través de toda la arquitectura, para esto se aplica los

casos de uso que se prueban contra el diseño de la navegación (USN) y luego
con la aplicación en si
7. se prueba en diversas configuraciones ambientales para comprobar su

compatibilidad. Se crea una matriz de referencia cruzada que define todos los
probables sistemas operativos, navegador, plataformas de hardware y
protocolos de comunicación.
8. se realizan pruebas de seguridad con el objetivo de encontrar vulnerabilidades
9. se hacen pruebas de desempeño para valorar como afecta el aumento del

tráfico, que características de uso provocan degradación, cuales son los
componentes responsables de la degradación y como esta degradación afecta a
los objetivos y requisitos globales de la WebApp
10. se prueba la WebApp en una porción de población controlada y monitoreada de

usuarios finales. Los resultados de esta prueba servirán para mejorar la
interacción, errores de contenido, navegación, facilidad de uso, compatibilidad,
confiabilidad y desempeño de la WebApp.
45
Se debe hacer un plan de pruebas que por lo general se definen en el planeamiento

general del proyecto, en este plan se identifican:
34. tipo y objetivo de pruebas aplicar,
35. tareas que se aplicaran en la prueba,
36. la forma en la que se evaluará los resultados de las pruebas (métricas,

valoración, niveles o puntuación).
Prueba de Contenido
La prueba de contenido abarca tres objetivos:
37. sintáctica (ortografía y gramática de contenido)
38. semántica (exactitud de la información presentada y consistencia entre

objetos de contenido y objetos relacionados). Esta evaluación que se hace para
cada objeto de contenido debe el examinador responder a las siguiente
preguntas:
1. la información realmente es precisa (concisa y exacta)?
2. la plantilla del objeto de contenido es fácil de entender para el usuario?
3. La información anidada en un objeto de contenido se encuentra con

facilidad?
4. La información presentada internamente es consistente con la

información de otros objetos de contenido?
5. El contenido es ofensivo, engañoso o abre la puerta a pleitos?
46
6. El contenido infringe derechos de autor o marcas registradas?
7. El estilo estético del contenido entra en conflicto con el estilo estético de

la interfaz global?
Un grupo de pruebas adicionales en cuanto a la semántica es para los WebApp

que construyen objetos de contenido dinámicos que se crean en tiempo real en
base a una base de datos. Para esto se deben observar varios factores:
8. Pruebas que descubran errores cometidos al traducir la solicitud del

usuario en una forma que pueda procesar la DBMS
9. Pruebas para comprobar errores en la comunicación con la base de

datos
10. Validar que los datos brutos provenientes de la DBMS hacia el servidor y
este hacia el cliente estén correctamente formateados para crear los
objetos de contenido
11. Probar el formato y compatibilidad de presentación de los objetos de

contenido dinámico al usuario con diferentes configuraciones de
ambiente del cliente
39. Estructurales/arquitectura (que se entregue adecuadamente el contenido y

la función de la WebApp. Que pueda ser extensible en contenido y
funcionalidad) CMS.
Prueba de Interfaz del Usuario
La verificación y validación de la interfaz del usuario se lo hace en tres puntos del

proceso, en el análisis (formulación y análisis de requisitos), en el diseño (al diseñar la
interfaz que garantice la calidad) y durante las pruebas donde básicamente se prueban
ejecutando la aplicación.
Los objetivos que se obtienen con las pruebas de interfaz son:
40. las características de la interfaz se prueban para asegurar que las reglas del
diseño, la estética y el contenido visual relacionado están a disposición del
usuario sin error alguno
41. los mecanismos individuales de la interfaz se prueban en forma unitaria (por

ejemplo se prueba html dinámico, cgi, carrito de compras, etc.)
42. la interfaz se prueba frente cada caso de uso (USN) para descubrir errores de
semántica, y facilidad de uso
43. la interfaz se prueba dentro de una diversidad de ambientes para asegurar su

compatibilidad.
Pruebas de mecanismos de la interfaz. Probar los mecanismos de interfaz que son

usados por el usuario en la interacción con el sistema, como por ejemplo: vínculos,
formato (de páginas, campos (tipos, validaciones)), html dinámico, ventanas pop-up,
47
cgi, cookies, mecanismos de interfaz especificas (como por ejemplo la validaciones que
debe tener un carrito de compras).
Pruebas de semántica de la interfaz. Una vez que se ha probado de forma unitaria

cada mecanismo de interfaz, se procede con la prueba semántica que evalúa cuan bien
el diseño se ocupa de los usuarios, ofreciendo una dirección clara, manteniendo
consistencia de lenguaje y enfoque.
Para esto se sugiere probar cada caso de uso (categorías de usuario) versus el diseño
de la interfaz para confirmar que no hay errores y si los hubiere como los maneja y su
recuperación.
Pruebas de facilidad de uso. Es parecido a las pruebas semánticas, donde se

prueban cuán fácil es el uso de la interfaz por parte del usuario, estas pruebas las
realiza el usuario. Los pasos para diseñar estas pruebas son:
44. definir un conjunto de categorías de prueba de facilidad de uso ( explicado

algunas más adelante), identificando las metas de cada una
45. diseñar las pruebas para que se evalúen cada meta
46. seleccionar los participantes que harán las pruebas
47. instrumentar la interacción que tendrá el usuario con la WebApp
48. desarrollar un mecanismo para valorar la facilidad de uso.
Para identificar las categorías de facilidad de uso se expone a continuación las

siguientes características de facilidad de uso:
49. interactividad. Los mecanismos de interacción (menús, botones) son fáciles de

entender y usar?
50. Plantilla. Los mecanismos de navegación, contenido y funciones están

colocados en una forma que permiten al usuario encontrarlos fácilmente?
51. Legibilidad. Los textos y gráficos son comprensibles?
52. Estética. La apariencia de las paginas hacen sentir cómodo al usuario
53. Características de despliegue (sensitive). La WebApp utiliza de forma óptima el

tamaño y la resolución de la pantalla?
54. Sensibilidad del tiempo. Las características funcionales y contenido son

presentadas de manera oportuna?
55. Personalización. ¿La WebApp se ajusta por si sola a las necesidades

importantes de diferentes categorías de usuario?
56. Cookies
48
Pruebas de compatibilidad. Como sabemos, el usuario puede tener diferentes

ambientes (sistemas operativos, navegador, plataformas de hardware), por lo que se
debe hacer pruebas de compatibilidad para descubrir errores asociados con un
ambiente específico. Para esto se debe definir un conjunto de configuraciones de
computadoras cliente más comunes y en función de estas armar las pruebas.
Prueba al nivel de Componentes
Conocidas como pruebas de función, que intentan descubrir errores en la funcionalidad

de la WebApp. Para esto existen algunos métodos de prueba:
57. Partición de equivalencia. Cuyo dominio de entrada se divide en categorías o

clases de entrada y a partir de estos se derivan los casos de prueba. Se hacen
pruebas con cada categoría mientras las otras permanecen constantes, por
ejemplo en una página que importe el código postal, aquí se hace pruebas
posibles con el código postal mientras los otros valores permanecen constantes
58. Análisis de valores límite. Probar los valores máximos o mínimos de campos o
atributos que maneja el componente o la función
59. Pruebas de ruta. Para comprobar y garantizar que se ha ejercitado toda ruta
posible en su funcionamiento.
Para cada caso se debe especificar la entrada y salida esperada.
Existen circunstancias en las que la funcionalidad es tan extensa que complica probar
todas las posibles situaciones, por lo que una sugerencia sería acudir a un análisis de
riesgo para obtener los casos de prueba de mayor riesgo, como por ejemplo:
60. ¿Cuál funcionalidad es la más importante para el propósito?
61. ¿Cuáles áreas del sitio amerita más dura interacción con la DB?
62. ¿Cuáles mecanismos específicos (cgi, applets, activex) son los más complejos?
63. ¿Qué tipos de problemas causará la mayoría de las quejas o la peor publicidad?
49
64. ¿Qué áreas del sitio serán las más populares?
65. ¿Qué partes del sitio tendrán mayores riesgos de seguridad? .
Pruebas de Navegación
Las pruebas de navegación garantizan que todos los mecanismos que permiten al
usuario de la WebApp viajar a través de ella sean funcionales y validar que cada USN
pueda ser alcanzado por la categoría de usuario adecuada.
La primera prueba de navegación inicia con la prueba de interfaz. Estas pruebas

inicialmente son probadas por los Ingenieros Web para luego pasar las pruebas a los
usuarios.
Prueba de sintaxis de navegación. Con cada mecanismo de navegación se prueba:

vínculos navegación, redirigir (destinos removidos), mapas de sitio, motores de
búsqueda.
Prueba de semántica de navegación. Se deben probar los USN (unidad semántica

de navegación). Se toma los casos de uso para armar casos de prueba de navegación
respondiendo a las siguientes preguntas:
66. el USN se logra en su totalidad sin error?
67. Todo nodo de navegación del USN es accesible dentro del contexto de rutas
definidas en el USN?
68. Si la interfaz del usuario proporciona una guía para ayudar en la navegación, es
comprensible?
69. Existe un mecanismo distinto al proporcionado por el navegador para regresar

al nodo de navegación predecesor o al inicio?
70. Si una función se ejecuta en un nodo y ocurre un error en el procesamiento de

la función, se puede completar la USN?
71. Existe una forma para descontinuar la navegación antes de haber alcanzado
todos los nodos, y se puede regresar a punto donde se descontinuó para
proceder desde ahí?
72. Todo nodo se alcanza desde el mapa de sitio? Los nombres son significativos
para el usuario?
73. Si un nodo dentro de una USN es accedido desde alguna fuente externa, es
posible proceder hacia el siguiente nodo de la ruta? Es posible regresar al nodo
previo en la ruta?
74. El usuario comprende su ubicación dentro de la arquitectura de contenido

conforme se ejecuta la USN?.
Pruebas de Configuración
50
En las pruebas de compatibilidad en pruebas de interfaz usuario se probaron solo

del lado del cliente, mientras que en estas pruebas de configuración se prueban un
conjunto de probables configuraciones de cliente y servidores.
Del lado del servidor:
75. la WebApp es totalmente compatible con el sistema operativo del servidor?
76. ¿Los archivos de sistema, directorios y datos de sistema relacionados se crean

correctamente cuando la WebApp está operativa?
77. Las medidas de seguridad del sistema permiten a la WebApp ejecutarse y dar el
servicio a los usuarios sin interferencia y a un buen desempeño?
78. La WebApp se ha probado con la configuración de servidor distribuido (cluster

o balanceo de carga)?
79. La WebApp está integrada adecuadamente con la base de datos (incluyendo

diferentes versiones de DB)?
80. Si se usan proxys, las diferencias en configuraciones se han abordado?.
Del lado del cliente:
81. hardware: cpu, memoria, dispositivos de impresión, monitor
82. sistemas operativos: normales y especiales para equipos móviles
83. software de navegación
84. componentes de interfaz del usuario: activex, applets java, otros
85. Plug in: quicktime, realplayer, adobe, otros
86. Conectividad: cable, dsl, Modem, proxys, otros
87. Aplicaciones que corren al mismo tiempo.
Pruebas de Seguridad
Este tema es de gran alcance, porque las pruebas de seguridad están diseñadas
para probar la vulnerabilidad en el ambiente cliente, las comunicaciones de red y el
ambiente del lado del servidor. Al punto que si la WebApp es crucial para el
manejo del negocio de la empresa, es aconsejable que se haga una certificación de
la seguridad con empresas especializadas en esta labor.
Confidencial - PRUEBAS DE SEGURIDAD EXTERNAS WEB.doc

Entre las principales vulnerabilidades está el desbordamiento de buffer, instalación
de cookies no legítimos, spoofing, ataques de negación de servicio, acceso no
autorizado a bases de datos. Para evitar estas vulnerabilidades se pueden
implementar elementos de seguridad como: firewall, autenticación, encriptación,
autorización, IPS.
51
En negocios electrónicos se vio algunas formas de seguridad: Usuario/contraseña,

firmas digitales, SSL, RSA, 3DES, gateway de seguridad, etc., que deben ser
probados.
Por ejemplo:
1. Claves de acceso débiles
2. Mala administración de servidores y componentes de red
3. Personal mal entrenado
4. Software desactualizado
5. "Trucos de vendedores de tecnología" cuyos productos en realidad no
cumplen las especificaciones de seguridad
6. Problemas de protocolos
7. Servicios críticos sobre redes inseguras
8. Problemas de seguridad en aplicaciones
9. Pruebas de detección, validación y explotación de problemas de

seguridad en servidores (Unix, Windows), mecanismos de seguridad
(Firewalls, IDS, IPS, VPN), elementos de comunicación (enrutadores),
servicios comunes (web, correo, DNS, POP3, etc).
10. Ataques comunes enfocados a protocolos (TCP Hijacking, IP Spoofing,
ARP Spoofing, Sniffing, DoS – de común acuerdo, SNMP Testing, etc),
acceso remoto (Wardialing, PBX Testing, RAS Server Testing)
11. Ataques enfocados a servicios comunes, tales como WEB (Cross Site
Scripting, CGI/ASP/PHP scanning, command execution), CORREO
(SMTP Mail relay, Information Disclosure, etc), DNS (DNS Poisoning,
DNS Spoofing, etc.), entre otros.
12. Verificación de problemas comunes en aplicaciones y bases de datos.
Adicionalmente se deben hacer pruebas de código seguro:
1. Análisis estático de software es el análisis de software que se realiza sin

ejecutar el programa
2. Análisis dinámico de software se lo realiza sobre los programas en

ejecución.
Pruebas de Desempeño
Se aplican para descubrir problemas de desempeño que se presentan debido a la falta

de recursos en el lado del servidor, ancho de banda de red inapropiada, capacidades
inadecuadas de bases de datos, capacidades/defectuosos de sistemas operativos,
funcionalidad mal diseñada, u otros conflictos de hardware o software (seguridad) que
impidan un buen desempeño.
52
Esto conducirá a comprender como el sistema responde a cierta carga (número de

usuarios activos, número de transacciones, volumen de datos, etc.) y a poder
recolectar métricas para poder modificar el diseño o acoplar soluciones
(hardware/software apropiadas) para mejorar el rendimiento.
Las pruebas deben responder a las siguientes preguntas:
1. en qué punto (usuarios, transacciones, carga de datos) el desempeño se vuelve

inaceptable?
2. Que componentes del sistema son responsables de la reducción del

desempeño?
3. Cuál es el tiempo de respuesta promedio para los usuarios en una variedad de

condiciones de carga?
4. Que ocurre cuando se aplican cargas que rebasan la capacidad máxima del
servidor?.
Para contestar a estas preguntas se hacen las pruebas de desempeño comunes (carga
y tensión).
Pruebas de carga. Para esta prueba se consideran variables:
5. N: número de usuarios concurrentes
6. T: número de transacciones en línea por usuario por unidad de tiempo
7. D: la carga de datos procesada por el servidor por transacción.
De estas variables el Ingeniero Web obtiene valores promedios aceptables y si en el

momento de la prueba encuentra una disminución precipitada de desempeño se debe
revisar el porqué.
Pruebas de tensión. Es una continuación de la prueba de carga, en donde las

variables N, T y D se fuerzan para poder superar los límites operativos. Con esta
prueba se responden a las siguientes preguntas:
8. el sistema se degrada o el servidor se desconecta cuando se rebasa su

capacidad?
9. El software emite mensajes al cliente y al soporte técnico del sitio que se no

puede alcanzar el servidor?
10. El servidor pone en cola las peticiones que no alcanza a resolverlas para ir
atendiendo poco a poco como su capacidad lo permita?
11. Las transacciones se pierden conforme se rebasa los límites?
12. La integridad de datos se pierde cuando se rebasa los límites?
13. Si el sistema falla, cuánto tarda en estar en línea de nuevo?
14. Ciertas funciones del WebApp se descontinúan cuando el servidor llega a sus
umbrales (memoria, procesador, disco)?.
53
Una variación de pruebas de tensión son las llamadas pruebas pico, que son las
mismas pruebas de tensión pero se lo hace muy repentino llegar o sobrepasar el límite
volviendo a la normalidad y luego nuevamente sobrepasando el límite para efectos de
poder comprobar cuan bien que el sistema/servidor se recupera regresando a su
normalidad.
54

Ingeniería Web

Cargado por

Copyright:

Formatos disponibles

Ingeniería Web

Cargado por

Información del documento

Descripción 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

Ingeniería Web

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA

1. Como llevar técnicamente un proyecto de Ingeniería Web

2. Como formular y planificar proyectos Web

3. Que se debe tomar en cuenta para el análisis de aplicaciones Web

4. Que se debe tomar en cuenta para el diseño de aplicaciones Web

5. Como aplicar pruebas en aplicaciones Web.

6. Atributos de las aplicaciones basados en Web (WebApp)

7. Proceso de Ingeniería Web

8. Buenas prácticas en Ingeniería Web

FORMULACION Y PLANEACION PARA INGENIERIA WEB

Preguntas para la formulación

Recopilación de requisitos para WebApps

Planeación de proyectos de Ingeniería Web

MODELADO DE ANALISIS PARA APLICACIONES WEB

Requisitos para el análisis de las WebApps

Modelo de Análisis para las WebApps

MODELADO DE DISEÑO PARA APLICACIONES WEB

Diseño de la interfaz de la WebApp

Diseño a nivel de Componentes

Métricas de diseño para WebApp

PRUEBAS EN APLICACIONES WEB

Prueba de Interfaz del Usuario

Prueba al nivel de Componentes

Ingeniería Web trata con enfoques disciplinados y sistemáticos el desarrollo,

Por lo que antes de comenzar a construir es mejor que se entienda el problema,

Para este objetivo se debe:

3. Modelar los requisitos

5. Construir con tecnología y herramientas especializadas

6. Evaluación por parte de los usuarios (técnicos, como empresariales).

Atributos de las aplicaciones basados en Web (WebApp)

1. Intensidad de red (Internet, intranet, extranet)

2. Concurrencia (gran número de usuarios tienen acceso al mismo tiempo)

3. Carga impredecible (el número de usuarios puede variar de un día a otro)

4. Desempeño (tiempo en ingreso y navegación)

6. Gobernada por los datos (proveen gran cantidad y formatos de información)

7. Evolución continua / Inmediatez (la agilidad para poner productos/servicios)

8. Seguridad (para el manejo transaccional)

9. Sensibilidad al contenido / Estética / Temporalizable: calidad y naturaleza

10. Personalizable (ya sea la propia WebApp o el usuario personaliza su

Proceso de Ingeniería Web

Debido a que la Internet cambio la prioridad principal de desarrollo de que a cuando;

Principios de métodos agiles:

Entrega La prioridad más alta es satisfacer al cliente a

Participación de Los clientes deberían participar activamente en

Entrega Entrega con frecuencia software que funcione (de

El software se desarrolla en incrementos con el cliente

La medida principal de avance es el software que

Equipo motivado Equipo motivado, en un ambiente de buena

El equipo reflexiona a intervalos para ser más eficaz.

Habilidad para tomar decisiones

Capacidad para resolver problemas difusos

Confianza y respeto mutuo

Aceptar el Bienvenido los requerimientos cambiantes.

Mantenga la Enfóquese en la simplicidad tanto del software

Apoyado de una excelencia técnica y código seguro

Escalado Planificación flexible, versiones frecuentes del

El Marco de trabajo de IWeb debe considerar: adoptar el cambio, aliente la creatividad,

Se pueden utilizar varios tipos de procesos como XP (programación extrema, MSF

Proceso XP (Programación extrema)