CURSO

Instituto Tecnológico de Culiacán
Ingeniería en Sistemas Computacionales.

Ingeniería WEB.
(Web Engineering)
Semestre 99
Agosto – diciembre 2017
Dr. Clemente García Gerardo

Ingeniería WEB
¿Qué se requiere para ejecutar una aplicación Web típica?
HTML Java Script
VB asp T-SQL
Ajax PHP
Angular Java Script Object Notation (JSON)
Google chrome
Mozilla Firefox
Konqueror Internet Information Services Postgres

Safari Apache MySQL
Opera EBaby SQL Server
Navegador Servidores WEB SGBD

Ingeniería WEB
Arquitectura de las aplicaciones WEB (WebApp)
Entorno de ejecución
SEGUNDO
Navegador Petición Servidor Programa o Script

NIVEL
PRIMER NIVEL
WEB
Cliente Respuesta
HTML
Tercer
SGBD
nivel
Servidores
Una aplicación Web típica recogerá datos del usuario (primer nivel), los
enviará al servidor, que ejecutará un programa (segundo y tercer nivel)
y cuyo resultado será formateado y presentado al usuario en el
navegador (primer nivel otra vez).

Ingeniería WEB

Ingeniería WEB
Componentes de una arquitectura para una aplicación Web
Firewall Proxy Web-Server La comunicación entre

CGI estos componentes es
generalmente basada
Cliente Servlet
en el principio de
(browser) SSI pregunta-respuesta. El
Web Browser envía
una pregunta al Web
DB- Server y la respuesta a
Server esta pregunta se envía
Aplication por el mismo canal
Server comunicación
(comunicación
sincrona)
Media Content Legacy-
Server Management Applications
Server
CGI . Common Gateway Interface

SSI. Server Side Includes
Ingeniería WEB
• Cliente
Generalmente un navegador es controlado por un usuario para operar la
aplicación Web.
• Firewall
Software controlando la comunicación entre redes seguras (LANs) y redes
inseguras (internet). La comunicación es filtrada por reglas de acceso.
• Proxy
Típicamente es usado para almacenar páginas Web temporales en el cache, sin
embargo los proxy pueden asumir otras funcionalidades tales como
personalizar el contenido a los usuario o dar seguimiento a los usuarios.
• Web Server
Software que maneja varios protocolos Web tales como HTTP, HTTPS para
procesar peticiones de los clientes.

Ingeniería WEB
• DB-Server
Este server permite tener una producción de datos organizadas de forma
estructurada.
• Media Server
Este componente es principalmente usado para contener flujos de datos
masivos de datos no estructurales tales como audio o video)
• Content Management Server
Similar al DB-Server, un servidor de gestión de contenidos tiene el contenido
para el Aplication Server. Los contenidos están normalmente disponibles en la
forma de datos semiestructurados (documentos XML).
• Application Server
Maneja la funcionalidad requerida por varias aplicaciones.
• Legacy Aplplication
Sistema de información antiguo, que debe ser integrado.
Ingeniería WEB
Historia de la Web
•1969: ARPA (Advanced Research Projects Agency)
• First small network: Stanford Research Institute, UCLA, UC Santa Barbara,
Univ. of Utah
• TCP (Transmission Control Protocol)
• IP (Internet Protocol)
• 1972: Telnet protocol
• 1973: SMTP (Simple Mail Transfer Protocol)
• 1973: FTP (File Transfer Protocol)
• 1989: T. Berners-Lee et al.: Word Wide Web (WWW)
• 1994: W3C (World Wide Web Consortium)
• 1996: HTTP (HyperText Transfer Protocol)

Ingeniería WEB
El internet y la WEB
¿ Nosotros estaremos viviendo la era de INTERNET ?
¿La WEB es muy grande?
Sentido típico :
• Número de páginas Web y sitios
• Número de usuarios
• Cantidad de información contenida en la Web
Otro sentido :
• Social
• Cultural

Ingeniería WEB
Aplicaciones Web (WebApp)
• A Web Application is a software system based on technologies and standards of
the World Wide Web Consortium (W3C) that provides Web specific resources such
as content and services through a user interface, the Web browser. [Kappel et al.
2004].
• En la ingeniería software se denomina aplicación web a aquellas aplicaciones que
los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de
una intranet mediante un navegador. En otras palabras, es una aplicación software
que se codifica en un lenguaje soportado por los navegadores web, y en la que se
confía la ejecución de la aplicación al navegador.

Ingeniería WEB
¿Son los atributos de las WebApp diferentes a los atributos de los sistemas
convencionales?
Existe debate acerca de la respuesta correcta a esta pregunta.
Algunas personas argumentan que una WebApp no es mas que una aplicación
cliente-servidor con un énfasis fuerte en presentación estética y funcionalidad y
que ambas (WebApp y convencional) tienen los mismos atributos.
Pero otras personas piensan que cuando se considera en su totalidad un conjunto
completo de características de WebApps, las hace diferente a los sistemas
convencionales.
Atributos que son encontrados en la mayoría de las WebApp
• Red intensiva
• Concurrencia
• Uso (cargado) impredecible
• Desempeño
• Disponibilidad Dr. Clemente García Gerardo
Ingeniería WEB
• Evolución continua
• Inmediatez
• Seguridad
• Estética

Ingeniería WEB
Categorías de las WebApp
• Informativas
• Descarga
• Personalizable
• Interacción
• Orientadas a transacción
• Orientadas a servicios
• Portal
• Acceso a bases de datos
• Data warehousing

Ingeniería WEB
Sistemas Basados en WEB
Durante la década de 1950 y 1960 poca gente apreciaba la importancia de los
sistemas basados en computadoras y prácticamente nadie previó el impacto global
que el software y hardware de la computadora tendría en cada aspecto de la
sociedad a finales del siglo XX e inicio del siglo XXI.
La mayoría de las personas que trabajaban con computadoras durante los
primeros días tardaron al desarrollar programas de computadora, debido a que
usaban una combinación de informalidad, urgencia, intuición y arte. Cuando
las cosas salieron bien, este enfoque conduce a importantes avances en la
computación, pero las cosas no siempre salen bien.
Los sistemas basado en computadoras frecuentemente fallan:
• En lo que supuestamente deben hacer
• En tiempos de entregada tarde o incompletos
• En algunas ocasiones son difícil (imposible) corregir, adaptar o enriquecer.
El enfoque de la vieja escuela era, lamentablemente, una propuesta de éxito o no
éxito. Dr. Clemente García Gerardo
Ingeniería WEB
Pero el pensamiento de la vieja escuela estableció una cultura que rápidamente se

convirtió en algo aceptado: la informalidad, la urgencia, la intuición y el arte fueron
las fuerzas motrices detrás de las actividades de la mayoría de los sistemas
basados en computadoras.
• La informalidad, lleva a un ambiente de trabajo fácil (puedes hacer tus propias
cosas).
• La urgencia conduce a la acción y toma de decisiones rápida.
• La intuición es una cualidad intangible que le permite encontrar soluciones en
situaciones complejas
• El arte conduce a la forma estética.

Ingeniería WEB
Desarrollo de WebApp: el enfoque de hoy

Desarrollo ad-hoc
• Basado en el conocimiento, las experiencias y prácticas de desarrolladores
individuales
• Reutilización de las aplicaciones existentes por "copiar y pegar"
Enfoque
• Insuficiente documentación de las decisiones de diseño
• Actividad aislada: no “se diseño para el cambio"
• Falta enfoque metódico

Ingeniería WEB
Una encuesta sobre el desarrollo de WebApp, realizada por el Consorcio Cutter

[Epner2000], resalta los siguientes problemas en los proyectos Web:
• En el 84% de los casos los sistemas no satisficieron las necesidades del negocio.
• El 79% de las veces no se cumplió con los tiempos programados.
• El 63% de los proyectos excedieron sus presupuestos.
• En el 53% de las veces los sistemas entregados no poseían la funcionalidad
requerida.
• En el 52% de los casos el software entregado fue de pobre calidad.

Ingeniería WEB
Las razones de las deficiencias de calidad:

1. La vista de documento centrado en
• El desarrollo de WebApp visto como la actividad editorial: páginas web
(texto), enlaces y gráficos"
• La idea errónea de que las WebApp son simples
2. Debido a la disponibilidad de herramientas como editores de HTML y forma
generadores
3. La no utilización de los conocimientos técnicos de las disciplinas pertinentes
• Sin el uso de la ingeniería de software
• Sin el uso de hipermedia o HCI (Human Computer Interacción)

Ingeniería WEB
¿Será la forma correcta que debemos utilizar para el desarrollo de WebApp?

NO.
Crisis del WEB
Comparable con la crisis del software a finales de los años 60´s que dio origen a
la disciplina de la ingeniería del software.
Es necesario la Ingeniería Web.

Ingeniería WEB
If you want do
something new, you
have to stop doing
something old.
Peter Drucker

Ingeniería WEB
¿Pueden usarse las mismas técnicas para el desarrollo de WebApp que son usadas
para el desarrollo de sistemas en general?
?
Ingeniería Web = Ingeniería del Software
La Ingeniería Web es una especialización

de la Ingeniería del Software

Ingeniería WEB
El escenario descrito en [Epner2000] motiva, a San Murugesan, Athula Ginige,

Yogesh, Deshpande y Steve Hansen a establecer una nueva disciplina : la
Ingeniería Web [Ginige2001], definiéndola de la siguiente manera:
La Ingeniería Web trata con el establecimiento y uso de principios
sensatos científicos, de ingeniería y gestión, así como con enfoques
disciplinados y sistemáticos, para el desarrollo, instalación y
mantenimiento exitoso, de aplicaciones y sistemas de alta calidad,
basados en el Web.
Roger Pressman, en su libro Web Engineering define ingeniería Web como:
The web engineering proposes an agile, yet disciplined framework for
building industry-quality webapps.
¿Qué se entiende por ágil? Leer [Jacaobson02]
Agilidad hoy en día, se ha convertido en palabra de moda cuando se describe un
proceso de software moderno.
Todo el mundo dice ser ágil en estos días. Un equipo ágil es capaz de responder de
manera adecuada a los cambios.Dr. Clemente García Gerardo
Ingeniería WEB
El dinamismo del cambio es el principal impulsor de la agilidad. La Ingeniería Web
debe ser rápida para que puedan acomodar los cambios que describe JACOBSON.
¿Qué es un maco de trabajo (framework) para Ingeniería Web?
Un framework establece las bases para un proceso completo de Ingeniería Web, a
través de la identificación de un pequeño número de actividades del framework
que son aplicados a todos los proyectos de WebApp, sin importar el tamaño o
complejidad. Adicionalmente, el framework abarca un conjunto de umbrella
activities (actividades protectoras ) que son aplicables a través del proceso
completo de la Ingeniería Web.
Cada una de las actividades del framework es descrita por un conjunto de acciones
de la Ingeniería Web (por ejemplo, el diseño es una acción). Cada una de las
acciones es descrita con tareas de trabajo individual que completan alguna parte
del trabajo implementado por la acción.
Ingeniería WEB
Proceso de la Ingeniería Web

Proceso del framework
Umbrella actividades
Framework actividad #1
WebE acción 1.1 Tareas de trabajo
conjunto de tareas Productos de trabajo
. Puntos de garantía de calidad
Hitos del proyecto
.
.
Tareas de trabajo
WebE acción 1.k
Productos de trabajo
conjunto de tareas Puntos de garantía de calidad
.
Hitos del proyecto
.
.
Framework actividad #n
WebE acción n.1 Tareas de trabajo
conjunto de tareas Productos de trabajo
. Puntos de garantía de calidad
Hitos del proyecto
.
.
Tareas de trabajo
WebE acción n.m
Productos de trabajo
conjunto de tareas Puntos de garantía de calidad
Hitos del proyecto

Ingeniería WEB
Actividades de la Ingeniería Web que son parte de un framework genérico y son
aplicables a la mayoría de proyectos de WebApp.
• Comunicación
Implica la interacción y la colaboración con los clientes (y otros actores) y
abarca la recolección de requisitos y otras actividades relacionadas.
• Planeación
Establece un plan incremental de trabajo para la WebE. Este plan describe;
las acciones de la WebE que pueden suceder, Las tareas técnicas que se
realizarán, los probables riesgos, los recursos requeridos, los productos de
trabajo que de elaborarán y plan de trabajo.
• Modelado
Abarca la creación de modelos que ayudan al desarrollador y cliente a
entender mejor los requisitos para la WebApp y el diseño que permitirá
alcanzar esos requisitos.
Ingeniería WEB
Construcción
Combina la generación de código (HTML, XML, Java, Angular, …) y la
aplicación de pruebas.
• Despliegue
Se entrega al cliente una WebApp (incrementada) para su evaluación y
retroalimentación
Ingeniería WEB
Mejores prácticas
1. Toma el tiempo para entender las necesidades del negocio y objetivos del
producto, incluso si los detalles de la aplicación Web son vagos.
2. Describe como los usuarios podrán interactuar con la aplicación Web utilizando
el enfoque basado en escenarios.
3. Desarrolla un plan del proyecto, incluso si este es muy pequeño.
4. Dedica tiempo a modelar lo que vas a construir.
5. Revisa los modelos para tener consistencia y calidad.
6. Usa herramientas y tecnología que permitan construir el sistema con
componentes reusables como sea posible.
7. No reinventes cuando puedas reusar.
8. No te fíes de los primeros usuarios para depurar la aplicación Web. Diseña
pruebas exhaustivas y aplícalas antes de liberar el sistema.

Ingeniería WEB
Proceso de Ingeniería Web

Antes de definir el proceso para ingeniería Web, reiteramos en algunas realidades
que son encontradas en muchos proyectos WebApp.
1. Los requerimientos evolucionan sobre el tiempo
Cuando se inicia un proyecto WebApp, puede existir incertidumbre acerca de
algunos elementos de la estrategia del negocio, el contenido y funcionalidad a
ser entregado, características de interoperabilidad , etc.
2. Los cambios se presentan con frecuencia
Debido a que la incertidumbre es un parte inherente de muchos proyectos
WebApp, los cambios de requerimientos son común.
3. La línea del tiempo es corta
Esto aminora la creación de voluminosa documentación. Pero no impide la
realidad que el problema de análisis, diseño y pruebas deben ser
documentados.

Ingeniería WEB
Debido a esas realidades, las WebApps son frecuentemente entrergadas
incrementalmente, lo que provoca que las actividades del framework se realicen
en cada incremento.
WebApp completo entregado en 4 incrementos
Adicionalmente los principios de García

Dr. Clemente agilidad deben ser aplicados
Gerardo
Ingeniería WEB
Expandiendo el framework de proceso de Ingeniería Web

Ingeniería WEB
Comunicación: dentro del proceso de Ingeniería Web, la actividad de

comunicación esta representada por tres acciones.
1. Formulación,
define el contexto del negocio y organización para la WebApp, adicionalmente
identifica al personal involucrado; cambios potenciales en el ambiente del
negocio o requerimientos son predichos y la integración entre la WebApp y
otras aplicaciones del negocio, bases de datos y funciones son definidas.
2. Negociación,
Es frecuentemente requerida para reconciliar diferencias entre personal
involucrado en el proyecto
3. Elicitación,
Es una actividad de recopilación de requisitos que involucra a todo personal
interesado. La intención es describir el problema que la WebApp va a resolver
junto con los requerimientos básicos usando la mejor información disponible,
adicionalmente intenta identificar áreas de incertidumbre donde potenciales
cambios pueden presentarse.Dr. Clemente García Gerardo
Ingeniería WEB
Planeación:
El número total de incrementos de la WebApp es identificado y un breve plan de
proyecto es creado para el siguiente incremento de la WebApp. Los recursos son
estimados para el incremento, los riesgos son considerados, las tareas son
seleccionadas y programadas. En muchos casos, el producto del trabajo de
planificación consiste de una definición de tareas y una programación de línea del
tiempo para un periodo (usualmente medido en días) proyectado para el desarrollo
del incremento.
Modelado:
Tareas de análisis y diseño de ingeniería de software convencional son adaptadas
para el desarrollo de WebApp. La intención es desarrollar modelos de análisis y
diseño ágiles que definas requerimientos y al mismo tiempo que represente una
WebApp que los satisfaga.
Ingeniería WEB
Construcción:
Herramientas y tecnología de Ingeniería Web son aplicadas para construir las
WebApp que han sido modeladas. Una vez que el incremento ha sido construido,
una serie de pruebas rápidas son realizadas para encontrar errores en el diseño
(errores en contenido, arquitectura, interface y navegación).
Despliegue:
La WebApp es configurada para su ambiente operacional y después es entregada al
usuario final y el periodo de evaluación inicia. La retroalimentación de la evaluación
es presentado al equipo de Ingeniería Web y el incremento es modificado como se
requiera.
Las cinco actividades del framework de la Ingeniería Web son aplicadas usando el
flujo de proceso incremental.
Ingeniería WEB
Flujo de proceso incremental (gradual).

Suponga que esta siendo contratado para conformar un equipo de Ingeniería Web,
capaz de desarrollar WebApps. La necesidad es inmediata y la presencia Web debe
estar ejecutándose tan pronto como sea posible.
Es obvio que tienes que ser ágil. También es obvio que las cosas pueden
cambiar (probablemente drásticamente) cuando empieces a diseñar la
WebApp.
Decides usar las actividades definidas por el framework de proceso genérico de la
Ingeniería Web y la única manera razonable de entregar las WebApps es en
incrementos.
¿Cómo se realizan las actividades de framework?
El flujo de proceso iterativo será aplicado en cada incremento. La primera iteración
se enfoca principalmente en la definición completa de los requerimientos de la
WebApp e identificando los incrementos a ser desarrollados en iteraciones
subsecuentes.
Ingeniería WEB
Primera iteración.
La primera actividad es inicializada: COMINICACIÓN.
La intención es definir el contexto del negocio, establecer el total de requerimientos,
crear un conjunto de escenarios de uso, negociar necesidades en conflicto entre las
partes interesadas y en base a esta información determinar el número de iteraciones
que serán entregadas.
Segunda iteración.
Aunque el tiempo es corto, se comprometió a utilizar el framework proceso de la
Ingeniería Web. La mañana siguiente inicia la actividades de comunicación para el
primer incremento dirigiendo una reunión de una hora con el personal involucrado.
Obtienes todo el contenido necesario para el incremento.
Las notas después de la reunión:
• Logotipo y gráficos necesitan diseño
• Uno o dos párrafos de introducción (misión, palabras de bienvenida a los clientes)
• Barra de navegación básica Dr. Clemente García Gerardo
• Otros temas
Ingeniería WEB
Planeación
El plan para el primer incremento
Desarrolla una línea del tiempo
de la WebApp está completo.
Día 1: Crea un prototipo del WebApp.
Durante los siguientes días se
Recoge y revisa toda la información y gráficas que existan
modela, construye y despliega.
Si es posible, obten retroalimentación del prototipo.
Día 2: Usando el prototipo como guia, inicia la construcción del incremento
Construye la barra de navegación
Diseñar área de contenido
Tan pronto que se realice el despliegue para este
Integrar gráficas, ligas, etc.
incremento, se esta listo para iniciar la siguiente iteración
Validar todas las ligas del framework proceso Web. La actividad de comunicación
durante
Revisar el contenido (completo la segunda iteración identificará requerimientos de
y correcto)
Día 3: Enviar todos los archivos contenido
a un dominioyexistente
funcionalidad
Realizar pruebas de navegación
Despliegue: informar al personal seleccionado que el incremento esta disponible
Día 4: Encuesta al personal involucrado para retroalimentación
Realizar modificaciones basdas en la retroalimentación del personal.
Ingeniería WEB
¿ Cómo es refinado el Framework ?

Las acciones y tareas requeridas por la Ingeniería Web para refinar cada actividad del
Framework, se dejan a consideración del equipo Web. En algunos casos, una
actividad del framework es conducida informalmente. En otros casos, un distinto
conjunto de acciones pueden ser definidos y conducidos por los miembros del equipo.
Cuando una acción es compleja (ejemplo diseño), ésta puede ser refinada en un
conjunto de tareas de Ingeniería Web:
• Diseño estético
• Diseño de contenido
• Diseño de arquitectura
• Diseño de navegación
• Diseño de componentes

Ingeniería WEB
¿ Cómo debe ser refinada la actividad Comunicación ?

Si no conoces tu destino, entonces es extremadamente difícil llegar a donde tu
necesitas ir y saber cuando es posible que haya llegado.
Muchos desarrolladores Web inician su trabajo en el desarrollo de WebApp, con
poca o ninguna idea de a donde ellos quieren ir. Ellos pueden alcanzar un destino
aceptable, pero ellos tomaran machas vueltas de manera errónea y llegar a
numerosos callejones sin salida a medida que viajan. Como resultado llegarán
tarde, algunas veces nunca llegarán. En otras ocasiones llegarán, perro no saben
cuando parar.
Comunicación es la actividad que establece el “destino” para un proyecto
WebApp.
Para un destino sencillo, existe un número pequeño de acciones y tareas
informales requeridas para estar seguro a donde se quiere ir. Si el destino es mas
difícil de describir, tendrá que afinar la actividad de comunicación con mas
cuidado. Las siguientes tareas y preguntas servirán para iniciar:

Ingeniería WEB
• Identificar los actores empresariales
¿ Exactamente quién es el cliente para la WebApp ?
¿ Qué empresario puede servir como experto y representante del usuario final?
¿ Cuál es el grado de consenso entre el personal involucrado?
¿ Quién es el árbitro final cuando surjan pugnas entre el personal involucrado?
• Identificar categorías de usuarios
¿ Cuántos diferentes tipos de usuarios podrán interactuar con la WebApp ?
¿ Cuál es la experiencia de cada usuario de la categoría y cuáles de ellos se
necesitan?
¿ Qué contenido y funcionalidad especial son requeridos para cada categoría
de usuarios ?
• Formular el contexto empresarial
¿ Cómo la WebApp encaja en una estrategia empresarial más amplia?
Esta la estrategia bien establecida y son las reglas del negocio bien entendidas?
Ingeniería WEB
• Definir las metas claves del negocio y objetivos para la WebApp
¿ Cómo se el éxito de la WebApp para medir tanto enterminos cualitativos
como cuantitativos ?
¿ Si existen múltiples objetivos , cuál es su prioridad ?
¿ El personal involucrado tiene diferentes metas y objetivos ?
¿ Son todas las metas y objetivos coherentes entre si ?
• Identificar el problema
¿ Cuál es el problema especifico que la WebApp debe resolver?
¿ Qué información es producida para el usuario final ?
¿ Qué información será introducida por el usuario final ?
¿ Qué funcionalidad es requerida para manipular datos ?
¿ Qué información almacenada usa la WebApp?
¿Cuáles sistemas existentes podrán interoperar con la WebApp ?
Ingeniería WEB
• Definir objetivos informativos y aplicativos
¿ Qué clase de contenido será al usuario final ?
¿ Cuál es el estatus de ese contenido ?
¿ Qué tan frecuente debe cambiar el contenido?
¿ Que funciones y tareas de usuarios se cumplirán cuando use la WebApp?
• Reunir los requisitos
¿ Qué tareas de usuario serán apoyadas por la WebApp?
¿ Qué contenido se va a desarrollar ?
¿ Qué esquema de navegación es deseada?
¿ Qué restricciones existen para los incrementos ?
• Desarrollo de escenario de uso
¿Tiene todas las categorías de usuarios con quién interactuará con el
incremento que ha sido considerado ?
¿Esta usando escenarios Dr.
completos y consistentes
Clemente García Gerardo con los requisitos del
incremento?
Ingeniería WEB
¿ Qué tareas se requieren para desarrollar un plan incremental?

La actividad de comunicación ha proporcionado un destino y ahora estás listo para
planear el viaje. La ruta puede ser razonablemente compleja. Por lo tanto, se
decide planear la ruta en etapas, definiendo puntos de paso que garanticen que
estás en la dirección correcta y haciendo progreso paso a paso hacia el último
objetivo.
La primera iteración de la actividad de comunicación establece los puntos de paso
(incrementos de la WebApp), pero es la actividad de planeación la que define los
recursos que serán requeridos para alcanzar cada punto de paso y estimar el
tiempo que se requerirá para llegar.
Las siguientes tareas y preguntas relacionadas deben ayudar a desarrollar un plan
incremental.

Ingeniería WEB
• Afinar la descripción del incremento de la WebApp que se entregará

¿Los cambios solicitados por el personal involucrado, requiere modificación del
número o definición de incrementos que aún no se han entregado?
¿ Si las modificaciones son requeridas, que cambios en contenido y
funcionalidad son necesarios ?
¿ Cuánto esfuerzo es probable que se gaste en cada incremento que aún no se
ha entregado?
¿ Cuánto tiempo calendario se gastarán en cada incremento ?
¿ Cuál es la fecha de entrega estimada para cada incremento ?
• Seleccione el incremento de la WebApp a ser entregado ahora
¿ Hay suficiente información acerca del incremento para iniciar otra actividad
del framework?
¿ Tienes entendido el contenido y funcionalidad a ser entregado por el
incremento ?
¿ Están todos los escenarios de uso disponibles y completos?
Ingeniería WEB
• Estima el esfuerzo y tiempo requerido para desarrollar el incremento

¿ Cuánto esfuerzo (persona-dias) y tiempo serán requeridos paras modelar,
construir y desplegar el incremento?
¿ Qué recursos (personas, hardware, foftware) serán requeridos para hacer el
trabajo?
• Evaluar los riesgos asociados a la entrega del incremento
¿ Qué riesgos deben ser obordados durante el desarrollo del incremento ?
¿ Lo que los riesgos a largo plazo deben ser considerados?
• Define el programa de desarrollo para el incremento
¿ la forma en que las tareas se asignarán a lo largo de la línea de tiempo para
el incremento?
• Establecen los productos de trabajo que se produzcan como consecuencia de la
actividad de cada marco.
¿ Qué productos de trabajo (escenarios escritos, modelos, documentos) serán
desarrollados como trabajo del incremento?
Ingeniería WEB
• Define el método de control de cambios

¿ Cómo los cambios de contenido y funcionalidad serán solicitados, evaluados
y ejecutados dentro del contexto de otra actividad de desarrollo?
• Establece el método para garantizar la calidad
¿ Cómo el equipo garantiza calidad cuando el incremento es modelado,
construido y desplegado ?
Aunque los incrementos son frecuentemente desarrollados en semanas, no en

meses, es razonable preguntarse si la planeación es justificada para la Ingeniería
Web. Siempre es buena idea establecer la ruta hacia a tu destino

Ingeniería WEB
¿ Qué es el modelado ?
En el contexto del fremawork del proceso de Ingeniería Web, el modelado es un
actividad que crea una (o más) representación conceptual de algún aspecto de
la WebApp que se contruye.
Una representación conceptual engloba una o mas de las siguientes formas:
• Documentos escritos
• Diagramas gráficos
• Escenarios escritos
• etc.
Durante la actividad del modelado, se realizan dos acciones de Ingeniería Web:
• Análisis
• Diseño

Ingeniería WEB
¿Qué tareas de modelado de análisis pueden ser aplicadas?
El análisis examina los requerimientos usando la información obtenida en la
actividad de comunicación.
En general el análisis se enfoca sobre el contenido de la WebApp, modos de
interacción (incluyendo navegación), funcionalidad y configuración técnica de la
WebApp (ambiente del hardware y software en el que la WebApp residirá ). Las
siguientes tareas y preguntas relacionadas deben ayudarte a desarrollar el modelo
de análisis:
• Dicidir si un modelo de requisitos es necesario
¿La información existente proporciona suficiente detalle acerca de
(1)contenido de la WebApp, (2)modelos necesarios de interacción, (3)
funcionalidad requerida ?
¿Se han desarrollado escenarios de uso con suficiente detalle como para
orientar las actividades de diseño y construcción?
Si esta información existe y es completa, no hay necesidad del modelado de
análisis para el incremento. Si la información es incompleta o implica un grado
de complejidad que demande examen mas cuidadoso, proceder a las tareas de
modelado de análisis.
Ingeniería WEB
• Representar contenido de la WebApp
¿ Qué contenido se va a presentar?
¿ Cuál es su origen ?
¿ Quién es el responsable de adquirirlo y desarrollarlo?
¿ Es aconsejable organizar el contenido en una colección de clases ?
¿ Son las relaciones complejas entre contenido de clases?
• Identifica relaciones de contenido
• Refina y extiende escenarios de usuarios
• Revisar los escenarios de uso
• Crear un modelo de interacción para escenarios complejos
• Refinar los requisitos de interfaz
• Identificar funciones
• Definir restricciones y requisitos de desempeño
• Identificar requisitos de bases de datos
Ingeniería WEB
¿ Cuáles son los elementos de un modelo de diseño ?

Design is a core Web Engineering.
¿Qué es el diseño?
[Kap91], es donde tu te paras con un pie en dos mundos -el mundo de la tecnología y
el mundo de las personas y los propósitos humanos- e intentas traer a los dos juntos.
La meta del diseño para Ingeniería Web es producir un modelo o representación que
exhiba:
1. Firmeza
Una WebApp no debe tener errores que inhiben su función.
2. Comodidad
Una WebApp debe ser adecuada para el propósito para la cual fue destinada
3. Placer
La experiencia de usar la WebApp debe ser placentera.
Ingeniería WEB
¿Siempre creamos un modelos de diseño, cuándo diseñamos un incremento de

WebApp ?
La respuesta es SI, pero el modelo puede ser diferente para cada incremento. Si el
incremento esta bien entendido y muy fácil de construir, el modelo de diseño puede
ser un simple boceto. Por otro lado, si el incremento es complejo, un modelo de
diseño mas detallado puede ser creado.
El modelo puede considerar los siguientes (alguno o todos) aspectos de diseño de
la WebApp.
• Diseño de interface
Describe la estructura y organización de la interface de usuario. Incluye una
representación de diseño de pantallas, una definición de los modos de
interacción y una descripción de los mecanismos de navegación.
• Diseño de estética (también llamado diseño gráfico)
Describe el “verse y sentirse” de la WebApp. Incluye diseño geométrico,
tamaño del texto, uso de gráficas y decisiones de estética.
Ingeniería WEB
• Diseño de contenido
Define el diseño para el contenido que es presentado como parte de la WebApp
• Diseño de navegación
Representa el flujo de navegación
• Diseño de arquitectura
Identifica la estructura global para la WebApp
• Diseño de componentes
Desarrolla la lógica de procesamiento detallado necesario para implementar los
componentes funcionales que implementan una función de WebApp completa

Ingeniería WEB
¿ Qué tareas de modelado de diseño pueden ser aplicadas?
Dependiendo de la complejidad del incremento de la WebApp que va a ser
construido. Las siguientes tareas y preguntas relacionadas deben ayudar a
desarrollar un modelo de diseño.
• Diseño de interfaz
¿cómo están las tareas de interacción y subtareas a ser representados como
parte de la interfaz ?
¿ Qué mecanismos de control de interfaz (ligas, botones, menús) son
requeridos ?
¿ Cómo están los mecanismos de control situados en una página web?
• Diseño de la estética para la WebApp
¿ Cómo se implementará el diseño de la página ?
¿ El color y la forma varían según el contexto ?
¿ Cómo será posicionado y representado el mecanismo de navegación ?
Ingeniería WEB
¿ Están los logos, gráficas, imágenes y fondos implementados y disponibles ?

¿ Es el diseño estético consistente a través de los incrementos ?
• Diseño del esquema de navegación
¿ Qué ligas de navegación son requeridas ?
¿ Qué convención de navegación y ayuda serán utilizados ?
¿ Se define el flujo de navegación completo ?
¿ Qué mecanismos de navegación corresponden a los requisitos de la interfaz
y el diseño? ?
¿ La navegación ha sido optimizada para las diferentes categorías de usuarios?
¿ La navegación esta acorde a los escenarios de uso ?
• Diseño de la arquitectura de la WebApp
¿ Qué estilo arquitectónico se utilizará para el contenido y la función?
• Diseño del contenido y la estructura que lo soporte
¿Qué contenido debe ser diseñado como parte del incremento de la WebApp?
¿Qué estructuras de datos y bases de datos son requeridas para implementar
funcionalidad o desplegar contenido?
¿son interfaces a la base de datos existente definido a nivel de diseño?

Ingeniería WEB
• Diseñar componentes funcionales

¿ Qué componentes deben ser desarrollados ?
¿ Todos los algoritmos han sido definidos ?
• Seleccionar patrones de diseño apropiados
¿ Cuáles patrones de arquitectura son apropiadas para el espacio de la
información?
¿ Pueden los problemas de diseño de navegación utilizar patrones existentes?
interface¿ Pueden los patrones de interacción ser usados como parte del
diseño?
• Diseñar mecanismos de seguridad y privacidad
¿ Qué nivel de seguridad es requerido para el acceso de los usuarios al
sistema?
¿ Qué nivel de protección de seguridad y privacidad es requerido para proteger
del lado del cliente y servidor la funcionalidad y contenido de accesos no
autorizados?
• Revisar el diseño
¿ El diseño se ajusta a los requisitos del cliente?
¿ El diseño puede ser implementado de acuerdo al calendario de despliegue?
Ingeniería WEB
¿Qué tareas de construcción deben ser aplicadas?
Si todas las actividades del framework han ido bien, se tiene identificado que
requiere el personal involucrado para el incremento de la WebApp. También se
tiene un diseño que sirve como base para realizar la actividad de construcción. A
medida que avanza la construcción de la WebApp se realizarán dos acciones:
generación de código y pruebas. Las siguientes tareas y preguntas relacionadas
deben ayudarte a planear la actividad de construcción.
• Construir y adquirir todo el contenido e integra el contenido en la arquitectura
WebApp.
¿ Qué tecnología de Ingeniería Web y herramientas serán aplicadas para
construir contenido y componentes funcionales ?
¿ Qué formas, plantillas y patrones existentes pueden ser usados durante la
construcción ?
• Seleccione la herramienta adecuada para la generación de código HTML
¿ Puede la herramienta ser usada exclusivamente ?
¿ La función especifica deben implementada a mano ?
• Implementar los diseños de página, funciones y capacidad de navegación
¿Esta todo el contenido disponible para la integración de las páginas?
¿ Se han implementado los enlaces a todas las funciones?
Ingeniería WEB
Una vez que la WebApp ha sido construida, ésta debe probarse. Las siguientes
tareas y preguntas relacionadas deben ayudarte a planear la acción de prueba.
• Prueba todos los componentes de la WebApp

¿ Qué componentes han de ser probados dentro del contexto de tareas de
usuario?
¿ Las pruebas han sido diseñadas para ejercer plenamente la funcionalidad ?
• Prueba de navegación
¿ Que ligas va a ser probadas dentro del contexto de tareas de usuario?
¿ Cuáles escenarios de usuario son aplicables al incremento de la webapp para
desarrollar pruebas de navegación adecuadas?
¿ Las pruebas han sido diseñadas para ejercer plenamente la estructura
navegacional?
• Prueba de usabilidad
¿ Cuáles mecanismos interactivos deben de ser probados para facilidad su
uso?
¿ Cuáles escenarios de usuario son aplicables al incremento de la webapp para
desarrollar pruebas de usabilidad adecuadas?
Ingeniería WEB
• Prueba de seguridad y desempeño

¿cómo nos ejercitamos todos los filtros de seguridad y probar el rendimiento
global del incremento?
¿Las pruebas han sido diseñadas para garantizar que las capacidades del lado
del cliente y lado del servidor son seguras?
• Pruebe el incremento de la WebApp para diferentes configuraciones
¿ Se ha elaborado una lista de todas las configuraciones técnicas ?
¿ Las pruebas han sido diseñadas para ejercer el incremento de la WebApp
dentro de toda la configuración operacional ?
Cómo es desplegado el incremento de la WebApp?
Una vez que se ha completado el incremento de la WebApp, se debe entregar al
usuario final. La intención es: (1) proporcionar funcionalidad a una o mas categorías
de usuarios, (2) obtener retroalimentación del usuario final para determinar si los
requisitos para el incremento se han cumplido, (3) establecer una base para la
modificación de que invariablemente se producirá como consecuencia de
despliegue. Las siguientes tareas y preguntas relacionadas deben ayudarte a
desplegar el incremento de la WebApp.

Ingeniería WEB
• Entregar el incremento de la WebApp a un servidor en un dominio predefinido

¿ Tiene todos los archivos y nombres de directorios y enlaces han seguido las
convenciones de referencia?
¿ Los usuarios han sido habilitados para acceder a la información?
¿ Son adecuados los elementos de seguridad?
• Establecer un mecanismo de retroalimentación en línea para el usuario final
¿Tiene implementada una forma de retroalimentación en línea desde el primer
incremento?
• Evaluar la interacción con el usuario final
¿Cómo interactúa el usuario con el sistema?
¿Qué problemas son encontrados?
¿Qué partes de la interacción no son claras, ambiguas u omitidas?
¿Qué contenido o funcionalidad es incorrecto u omitido?
• Evaluar la lección aprendida y considera toda la retroalimentación del usuario
final.
¿Qué cambios son requeridos basados en retroalimentación del usuario?
¿Deben implementarse los cambios inmediatamente o como parte del
siguiente incremento de ingeniería?
Ingeniería WEB
• Realizar modificaciones en el incremento de la WebApp como sea requerido

¿Qué modificaciones deben ser hechas en este incremento?
¿Qué cambios deben ser hechos para los subsecuentes incrementos?
Actividades soporte (umbrella).

Estas actividades son de suma importancia para el éxito de un proyecto, un equipo
Web debe considerarlas explícitamente. Pueden definirse muchas actividades
soporte, solamente 4 son cruciales :
1. Manejo de cambios
gestiona los efectos del cambio como cada incremento se ha diseñado,
integrando herramientas que ayudan en la gestión de todos los contenidos
webapp.
2. Garantizando calidad
Define y conduce las tareas que ayudan a garantizar que producto de trabajo y
el incremento entregado contengan calidad.
3. Gestión de riesgos
Considera los riesgos (proyecto y técnicos) cuando un incremento se ha
diseñado.
4. Gestión de proyectos Dr. Clemente García Gerardo
Monitorea el progreso cuando un incremento se ha diseñado
Ingeniería WEB
Unidad 3. Comunicación.
El principio fundamental de la Ingeniería del Software es:
Entender el problema planteado antes de que inicies a resolverlo y estar
seguro que la solución concebida es la que la gente realmente quiere.
Es razonable sugerir que este principio debe ser la piedra angular de la Ingeniería
Web.

Ingeniería WEB
El proceso de la Ingeniería Web inicia con la actividad de comunicación, la que
sirve como punto de entrada para el flujo de proceso. En este lugar es donde los
ingenieros Web y el personal involucrado participan en una serie de acciones de la
Ingeniería Web:
1. Preguntas y respuestas a un conjunto de preguntas fundamentales acerca de la
WebApp y su contexto del negocio. Formulación
2. Obtener los requisitos que servirán como base para todas las actividades que
siguen. Elicitación
3. Negociar necesidades contra las realidades de tiempo, recursos y tecnología
Negociación

Ingeniería WEB
En [Fuc98] se establece que la actividad de comunicación se puede lograr usando

una o mas de los siguientes mecanismos:
Grupo de enfoque tradicional Grupo de enfoque electrónico

Un moderador entrenado se reúne con un Un debate conducido por un moderador
grupo representativo de usuarios finales electrónico con un grupo representativo de
(menos de 10 personas). La intención es usuarios finales y personal involucrado
discutir la WebApp a desarrollar (entender (puede ser grande). Todos los usuarios
Grupo de enfoque
mejor los requisitos para el sistema). tradicional
pueden participar al mismo tiempo. Toda el
debate es basado en texto.
Encuesta iterativa Grupo de enfoque electrónico
Encuesta iterativa Construcción de escenarios
Construcción de escenarios Encuesta exploratoria
Una serie de encuestas breves, dirigida a Seleccione usuarios a quienes se les pedirá
usuarios representativos, solicitando que creen escenarios de uso que describa la
respuestas a preguntas específicas acerca de interacción específica con la WebApp.
la WebApp, es conducida vía sitio Web o
correo electrónico. Las respuestas son
analizadas para finar la siguiente encuesta.
Una encuesta basada en la web está vinculado a uno o más

WebApp que tiene usuarios que son similares a los que van a
Encuesta exploratoria utilizar la WebApp a desarrollar. Los usuarios acceden a la
encuesta y responder a una serie de las preguntas
Ingeniería WEB
Adaptando métodos de Ingeniería de Requisitos (IR) al desarrollo de WebApp.
Hoy en día numerosos métodos, notaciones, guias, listas de chequeo están

disponible para todas las actividades en la IR. Sin embargo, con el fin de tener
éxito los desarrolladores de WebApp deben evitar un enfoque de "talla única para
todos". Los métodos de IR tienen que ser adaptados a la Ingeniería Web y a la
situación específica del proyecto.
Los desarrolladores tienen que aclarar lo siguiente aspecto durante el proceso de
adaptación:
• ¿Qué tipos de requisitos son importantes para la WebApp ?
• ¿Los requisitos para la WebApp como deberán ser descritos y documentados?
• ¿El uso de herramientas deberá ser considerado? ¿Qué herramientas son
adecuadas para las necesidades del proyecto?
Tipos de requisitos
Organismos de normalización y organizaciones comerciales han desarrollado gran
número de taxonomías para definir y clasificar varios tipos de requisitos. Ejemplos
son Volere (Robertson and Robertson 1999) o IEEE 830-1998. Muchas taxonomías
distinguen entre requerimientos funcional y requerimientos no funcionales.
Ingeniería WEB
Los requisitos funcionales especifica una función que un sistema o un

componente de un sistema debe ser capaz de llevar a cabo.
Ejemplo, los clientes pueden seleccionar un icono para ver los artículos en el
carrito de compra.
Los requisitos funcionales se suelen clasificar como:
• Casos de uso. Procesar las ventas, gestionar las devoluciones, administrar los
usuarios, abrir y cerrar caja.
• Reglas de negocio. Las devoluciones de los pagos a crédito sólo pueden
efectuarse como abono a la cuenta de crédito de los compradores, no en efectivo.
• Requisitos de conducta. El sistema deberá, detectar fallos de forma
automática, cambiando a procesamiento local sin conexión cuando los servicios no
estén disponibles.
Los requisitos funcionales son frecuentemente descritos usando escenarios de

casos de uso.
Ingeniería WEB
Los requisitos no funcionales son aquellos que especifican aspectos técnicos

que debe incluir el sistema y que pueden clasificarse en restricciones y calidades.
Restricciones: cualquier limitación a que se enfrentan los desarrolladores del
sistema, por ejemplo, sistema operativo, plataforma hardware, perfil de los
desarrolladores, etc.
Calidades: todas aquellas características de un sistema que importan a clientes
y usuarios del mismo y que serán relevantes a la hora de establecer el grado
de satisfacción con el sistema final, por ejemplo, rendimiento, fiabilidad,
facilidad de mantenimiento, usabilidad, etc.
Ejemplo:
• La WebApp podrá soportar por lo menos 2500 usuarios de manera
concurrente.
• El cliente será capaz de ver la información en un gran monitor, por lo que el
texto se debe ver fácilmente a una distancia de 1 metro y evitar colores
asociados con formas comunes de daltonismo.

Ingeniería WEB
Caso de uso (CU)
Según Cockburn, un CU describe el comportamiento del sistema en

diferentes condiciones mientras éste responde a las peticiones de
uno de sus usuarios.
En esencia, un CU cuenta una historia estilizada de la manera en que

un usuario final interactúa con el sistema en un conjunto específico
de circunstancias.
Sin importar su forma, un CU muestra el sistema desde el punto de

vista del usuario final.

Ingeniería WEB
El primer paso al escribir un caso de uso consiste en definir el

conjunto de “actores” que estarán involucrados en la
historia.
Los actores puede ser alguien o algo que se comunica con el
sistema y que es externo al sistema en sí mismo. Cada actor
tiene una o más metas cuando utiliza el sistema.
La obtención de requisitos es una actividad evolutiva, por lo
que no todos los actores podrán ser identificados en la
primera iteración.
Hay dos tipos de actores:
Primarios: interactúan para lograr la función requerida del
sistema y obtienen el beneficio que se espera de éste.
Secundarios: dan soporte al sistema de manera que los
actores primarios puedan hacer su trabajo.

Ingeniería WEB
Una vez identificados los actores, se pueden desarrollar los casos de uso.
Jacobson sugiere varias preguntas que deben contestarse mediante un
caso de uso.
• ¿Quién es el actor primario (o quienes)?
• ¿Cuáles son las metas del actor?
• ¿Cuáles son las condiciones que deben existir antes de comenzar la
historia?
• ¿Cuáles son las tareas o funciones principales que realiza el actor?
• ¿Cuáles excepciones podrían considerarse mientras se describe la
historia?
• ¿Cuáles son las variaciones posibles en la interacción del actor?
• ¿Cuál es la información del sistema que el actor adquirirá, producirá o
cambiará?
• ¿Cuál es la información que el actor desea del sistema?

Ingeniería WEB
Las secciones de la plantilla de caso de uso
Actor principal: el que recurre a los servicios del sistema para cumplir un objetivo.
Personal involucrado y lista de intereses: esta lista sugiere y delimita que es lo

que debe hacer el sistema, el punto de vista del personal involucrado proporciona
un procedimiento metódico y completo para el descubrimiento y registro de todos
los comportamientos requeridos.
Precondiciones: establecen lo que siempre debe cumplirse antes de comenzar el

caso de uso. Las precondiciones no se prueban en el CU, sino que son condiciones
que se asume son verdad, una precondición implica un escenario de otro CU que se
ha completado con éxito.
Postcondiciones (garantía de éxito): establecen qué debe cumplirse cuando el

CU se completa con éxito. La garantía debe satisfacer las necesidades de todo el
personal involucrado.

Ingeniería WEB
Escenario principal de éxito (flujo básico, happy path): describe el camino

de éxito típico que satisface los intereses del personal involucrado. No incluye
ninguna condición o bifurcación. Se recomienda postergar todo el manejo de
caminos condicionales a la sección de Extensiones.
Extensiones o flujos alternativos: Son bifurcaciones del escenario principal de
éxito, y por tanto, pueden ser etiquetados de acuerdo con él. El escenario de
éxito y las extensiones deben satisfacer “casi” todos los intereses del personal
involucrado.
Requisitos especiales: aquí se deben incluir requisitos no funcionales, atributos
de calidad o restricciones que se relacionan de manera específica con el CU. Esto
incluye cualidades tales como rendimiento, fiabilidad, facilidad de uso, y
restricciones de diseño que son obligados o se consideran probables.
Lista de tecnología y variaciones de datos: Aquí se indican las diversas
formas que serán permitidas para la introducción de datos o las variaciones que
pudiera haber en los mismos, ejemplo: “el sistema debe soporta la entrada de la
cuenta de crédito utilizando un lector de tarjetas y el teclado” o “el identificador
del artículo podría ser cualquier esquema de código UPC, EAN, JAN o SKU.
Ingeniería WEB
Identificando incrementos
Un método [Fuc98] es crear una pila de tarjetas que contenga un caso de uso por
tarjeta . Se muestra ejemplo en la siguiente figura.
No.Tarjeta Nombre tarjeta Indicador esfuerzo

El equipo
1
Web Aprender
tiene establecido un esfuerzo máximo de1 4, lo
acerca la compañía
que significa que un incremento solamente puede ser definido si
2 Obtener especificaciones de prod 1
un grupo de tarjetas tiene un esfuerzo combinado de 4 o menos.
3 Proceso engorda 3
4 Proceso venta de ganado 2
5
Las tarjetas también deben ser aborda de
Proceso de toma de decisiones 4
una manera funcionalmente coherente.
El equipo web asigna el indicador en base al grado de esfuerzo requerido para
construir la funcionalidad de aplicación web necesaria para implementar el caso de
uso.
Las cartas se barajan en orden aleatorio y luego son distribuidos entre el personal
involucrado seleccionados, se les pide organizar las cartas en grupos que reflejen
cómo les gustaría que el contenido y la funcionalidad se entregarán.

Ingeniería WEB
Modelado
Introducción
Para construir una casa para una mascota (perro) solo necesitas dos manos hábiles,
materiales necesarios y herramientas que permitan comenzar a cortar y martillar
para lograr un resultado atractivo, dependiendo de la creatividad personal.
Nadie, sin embargo (Booch et al 1999), haría la construcción de un rascacielos con

la misma ingenua despreocupación (el resultado seguramente sería fatal! ). Lo que
está claro para todo el mundo cuando se trata de construir un rascacielos
(complejidad) a menudo se pasa por alto cuando se trata de la creación de
aplicaciones Web complejas. Un enfoque sistemático y una especificación de la
aplicación web que se construirá en la forma de modelos visuales son
recomendables si necesitamos desarrollar aplicaciones Web complejas.

Ingeniería WEB
Fundamentos
Las disciplinas de la ingeniería han utilizado con éxito los modelos para reducir:
• La complejidad.
• Las decisiones de diseño de documentos.
• Facilitar la comunicación dentro de los equipos del proyecto.
El modelado está dirigido a proporcionar una especificación de un sistema que se

construirá a un grado de detalle suficiente para la implementación del mismo. El
resultado de un proceso de modelado, son modelos que representan los aspectos
relevantes del sistema en un modo simplificado e idealmente de forma
comprensible.
En las Ciencias de la Computación desde hace algún tiempo se han usado métodos
de modelado para el desarrollo del software, en este campo, el objeto del
modelado es la aplicación que se desarrollará.

Ingeniería WEB
La siguiente figura muestra que el alcance de la modelización se extiende a lo largo

de tres dimensiones .
Niveles
Interface de usuario
Lógica de la aplicación
Fases
Análisis
Diseño
Implementación
Aspectos

Ingeniería WEB
Modelado en Ingeniería Web
Las herramientas de trabajo en el modelado de aplicaciones Web, básicamente, no
son nuevos, sin embargo, los métodos para modelar aplicaciones tradicionales no
son lo suficientemente expresivo para las características específicas de las WebApp.
Por ejemplo, lenguajes de modelado tradicionales (UML) no proporcionan conceptos
apropiados para la especificación de los hipervínculos. Esta fue la razón por la que
los enfoques de modelado para aplicaciones web se han desarrollado durante los
últimos años, que permiten hacer frente a una WebApp en las tres dimensiones
mostradas en la siguiente figura.
Niveles
Presentación
Hipertexto
Contenido
Fases
Análisis
Diseño
Implementación
Aspectos
Ingeniería WEB
Niveles
Para modelar WebApps, tiene que ser tomado en cuenta características de su
contenido así como su navegación hipertexto no lineal. Los niveles son:
• Presentación, es decir, el diseño de la interfaz de usuario o la página.
Al modelar el nivel de presentación, la atención se centra en una estructura de
presentación uniforme de las páginas para lograr un efecto de reconocimiento
para la aplicación web entre sus usuarios. Aunque el aspecto visual de una
aplicación web es de importancia, los aspectos estéticos no están dentro del
foco principal de modelado.
• Hipertexto, es decir, la estructuración del contenido en nodos y enlaces entre
estos nodos.
• Contenido, es decir, la lógica de la información y las aplicaciones por debajo de la
WebApp.
El objetivo de un modelo de contenido es la definición explícita de la estructura
de información. Comparable a un esquema de base de datos en el modelado
de datos, esto elimina las redundancias.

Ingeniería WEB
Aspectos
Siguiendo los principios orientados a objetos, la estructura y el comportamiento se

modelan en cada uno de los tres niveles, es decir, el contenido, hipertexto y
presentación. La relevancia de los modelos de estructura y comportamiento
depende del tipo de aplicación Web a implementar.
Las WebApp que hacen uso de información principalmente estática, requieren

menos modelado de comportamiento en comparación con WebApp interactivas,
como por ejemplo aplicaciones de comercio electrónico, funciones de orden de
compra, etc.

Ingeniería WEB
Fases
No hay consenso en la literatura sobre un enfoque general de modelado para el

desarrollo de WebApp. En cualquier caso, la secuencia de pasos para modelar los
niveles debe ser decidido por el modelador. Dependiendo del tipo de WebApp,
debería ser posible llevar a cabo un enfoque basado en la información, es decir,
comenzando con el modelado de contenido, o un enfoque de presentación,
iniciando con el modelado de aspectos de la presentación de la aplicación.

Ingeniería WEB
Modelado de requisitos
Se ha establecido que diversas técnicas se pueden utilizar para identificar, analizar,

describir, evaluar y gestionar los requisitos de las WebApp. Los casos de uso son la
técnica de modelado preferido para los requisitos funcionales, no menos
importante, ya que se pueden representar gráficamente. La funcionalidad global
de una aplicación web se modela como un conjunto de casos de uso, que
describen los requisitos de las aplicaciones Web de los actores perspectivas
(personas y otros sistemas). Además, los casos de uso pueden complementarse
con diagramas de actividad UML para describir los requisitos funcionales en más
detalle.
Una peculiaridad de los requisitos de aplicación Web es la funcionalidad de

navegación, que permite al usuario navegar a través del hipertexto y de encontrar
nodos. (Baresi et al., 2001) sugiere la creación de dos modelos para los casos de
uso : funcionalidad y nevegación. Otro enfoque, es la creación de un modelo de
caso de uso sencillo, que utiliza la navegación estereotipo UML para denotar la
diferencia entre casos de uso funcionales e hipertexto específico.
Ingeniería WEB
UWE es un enfoque de ingeniería de software para el dominio Web, con el objetivo

de cubrir todo el ciclo de vida de desarrollo de aplicaciones Web. El aspecto clave
que distinguen UWE es la dependencia de los estándares.

Ingeniería WEB
Modelado de requisitos
En UWE el modelado de requisitos consiste de dos partes:

• Casos de uso de la aplicación y sus relaciones
• Actividades describiendo los casos de uso en detalle
Un ejemplo.
El usuario debe poder realizar búsquedas en la libreta de direcciones y borrar
contactos. Adicionalmente, contactos pueden ser creados y actualizados, cambios
deben ser archivados o pueden ser cancelados.
En UWE se distinguen casos de uso estereotipados con:

«browsing» los datos son solamente leídos y presentados al usuario.
«processing» para ilustrar si los datos persistentes de la aplicación son
modificados o no.

Ingeniería WEB
Nombres de los esterotipos y sus iconos
"SearchContact" por ejemplo, modela la búsqueda de contactos y por ello

lleva el esterotipo «browsing»
Los otros casos de uso por el contrario modelan cambios, lo que se
especifica con el estereotipo «processing».
Ingeniería WEB
Modelo de contenido
Este es un diagrama UML normal de clases, por ello debemos pensar en las clases que son
necesarias para la agenda de direcciones. Primero queremos disponer de una clase agenda
("AddressBook") conteniendo un conjunto de contactos. Cada contacto debe contener un
nombre, y puede contener una dirección de correo, dos números de teléfono y dos direcciones
postales. El nombre y la dirección de correo son Strings, el teléfono y la dirección postal son
clases que representan más información, como se ilustra en la siguiente figura:
Por qué necesitamos el

atributo "introducción" en
la clase AddressBook?
Porque se desea
almacenar allí el texto
introductorio de la página
principal de la aplicación
web.

Ingeniería WEB
Modelo de navegación
En un sistema para la web es útil saber como están enlazadas las páginas. Ello
significa que necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links).
Qué es un nodo?
Los nodos son unidades de navegación y están conectados por medio de enlaces.
Los nodos pueden ser presentados en diferentes páginas o en una misma página.
UWE provee diferentes estereotipos, para los nodos «navigationClass» y enlaces
«navigationLink». A partir de la inclusión de los procesos en el modelo
navegacional, se agregan dos elementos más <<processClass>> y enlaces
<<processLink>>.
La <<processClass>>: cuyas instancias se utilizan por el usuario durante la
ejecución del proceso. Cada clase de proceso tiene su correspondencia con un caso
de uso NO estereotipado con la palabra reservada navigation.
El <<processLink>>: que modela la asociación entre una clase navegacional y una
clase de proceso. Indica puntos de inicio de un proceso dentro de la estructura
navegacional. Pueden ser unidireccionales o bidireccionales.
Ingeniería WEB
AddressBook será nuestra página
principal del sitio web. Lo cuál se indica
con el valor de etiqueta {isHome}.
¿Se desea modelar el enlace desde el

contacto a la dirección o el teléfono o a
la foto ?
No, porque no son relevantes para la
navegación. Borrar los tres del árbol de
contenido del modelo.
¿Es deseado un sitio web para una agenda de

direcciones con la información de todos los
contactos en la misma página web?
No es eso lo que queremos.

Ingeniería WEB
El objetivo es una aplicación en la que se puede acceder a las operaciones de
nuestro diagrama de casos uso. Por este motivo necesitamos un sitio que
provee conexiones a diferentes nodos:
• ContactList. Cada contacto debe ser alcanzable usando un enlace desde la página
principal del sitio web
• (contact)Search. Buscar un contacto
• ContactCreation. Crear un nuevo contacto y visualizarlo
En UWE, puede usarse un «menu», para navegar a diferentes clases.

Ingeniería WEB
Podemos insertar la lista de contactos (ContactList). El estereotipo «index» es

usado para listar una cantidad de objetos del mismo tipo.

Ingeniería WEB
ContactCreation es un proceso, pero no uno predefinido, por ello usamos el

estereotipo «processClass»
Asociaciones salientes y
dirigidas para prohibir la
navegación hacia atrás
Cuando un nuevo
contacto se crea es útil
Dr. Clemente García Gerardo visualizarlo.
Ingeniería WEB
La clase para la búsqueda debe tener un estereotipo «query». Una búsqueda

implica ejecución de código, por ello conectamos esta clase con una asociación
«processLink» .

Ingeniería WEB
Hace falta agregar la funcionalidad de borrar contactos (ContactDeletion ) y

actualizar contactos(ContactUpdate). Estas dos clases son accedidas desde el
contacto concreto, por ello necesitamos nuevamente un menú ( y lo nombramos
ContactMenu indicando que está ubicado en la página de cada contacto).

Ingeniería WEB

El diseño navegacional comprende la construcción del modelo de navegación en
dos pasos:
• Modelo de espacio de navegación: su objetivo es especificar qué objetos
pueden ser pueden ser visitados a través de la aplicación.
• Modelo de estructura de navegación: amplia el modelo con un conjunto de
estructuras de acceso necesarias para la navegación como índices, visitas
guiadas y consultas.

Ingeniería WEB
Diagrama de presentación
Este modelo nos indica cuales son las clases de navegación y de proceso que
pertenecen a una página Web.
Agrega una <<presentationPage>> class y agrega las propiedades con estereotipo

UWE para expresar que el elemento esta ubicado en la página Web.
Las propiedades pueden anidarse, por ejemplo cada contacto

(«presentationGroup»-property) cubre diferentes textos y botones. Ello significa,
que para cada contacto la correspondiente dirección de correo y los
correspondientes campos de teléfonos y direcciones serán visualizados en la
página.
El atributo "introduction" se agrega a la página principal del sitio web AddressBook

para mostrar el texto introductorio (estereotipo «text»). Es necesarios un formulario
con un campo para entrada de datos (textInput) para el criterio de búsqueda y un
botón para lanzar la búsqueda. Una cantidad arbitraria de contactos pueden ser
presentados, lo que es modelado con la multiplicidad "*“.
Ingeniería WEB

Ingeniería WEB
Arquitectura software y patrones

“Una arquitectura orientada a objetos bien estructurada
está llena de patrones. La calidad de un sistema
orientado a objetos se mide por la atención que los
diseñadores han prestado a las colaboraciones entre sus
objetos.”
“Los patrones conducen a arquitecturas más pequeñas,

más simples y más comprensibles”
G. Booch
Ingeniería WEB
Diseño orientado a objetos

• “Diseñar software orientado a objetos es difícil pero
diseñar software orientado a objetos reutilizable es más
difícil todavía. Diseños generales y flexibles son muy
difíciles de encontrar la primera vez”
• ¿Qué conoce un programador experto que desconoce

uno inexperto?
Reutilizar soluciones que funcionaron en el pasado:

Aprovechar la experiencia
Ingeniería WEB
Un patrón es una solución a un problema de diseño no trivial que es:

Efectiva: ha servido para resolver el problema en diseños pasados
Reusable: la solución es la misma para problemas similares
Eric Gamma, Richard Helm, Ralph Johnson y John Vlissides, publicaron el

primer catálogo de patrones en el ámbito del software en 1994.
 Design Patterns: Elements of Reusable Object-Oriented Software,
También conocido como GoF (“Gang of Four”).
 Desde entonces, se han publicado muchos otros catálogos.
 Fue la primera vez que se documentó el conocimiento que usaban los
expertos para resolver problemas de diseño.
 Se inspiraron en el trabajo de Christopher Alexander, que había
documentado patrones en el ámbito de la arquitectura.

Ingeniería WEB
Ventajas del diseño con patrones:

 Permiten reusar soluciones probadas.
 Facilitan la comunicación entre diseñadores.
 Los patrones tienen nombres estándar.
 Facilitan el aprendizaje al diseñador inexperto.

Ingeniería WEB
Existen patrones para las distintas actividades que hay que realizar en un
proyecto (análisis, diseño, implementación, etc.)
 Existen patrones independientes del dominio y otros específicos a un
dominio concreto
• Los patrones del GoF son independientes del dominio

• Los patrones publicados en
http://java.sun.com/blueprints/patterns/index.html
son aplicables al desarrollo de aplicaciones empresariales
(persistencia, tecnologías Web, etc.) con J2EE (la plataforma
empresarial de Java)

Ingeniería WEB
En el libro Pattern-Oriented Software Architecture: A System of Patterns (también

conocido como POSA Book) se presentó la primer clasificación de patrones:
 Patrones arquitectónicos [Diseño]

Aconsejan la arquitectura global que debe seguir una aplicación
 Ejemplo: el patrón Model-View-Controller (MVC) aconseja la arquitectura
global que debe tener una aplicación interactiva.
 Patrones de diseño [Diseño]
Explican cómo resolver un problema concreto de diseño
 El patrón “Data Access Object” (DAO) permite abstraer y encapsular los
accesos a un repositorio de datos (ej.: BD relacional, BD orientada a objetos,
ficheros planos, etc.)

Ingeniería WEB
El patrón Modelo Vista Controlador (MVC)
Es un patrón de arquitectura de las aplicaciones software

Separa la lógica de negocio de la interfaz de usuario
• Facilita la evolución por separado de ambos aspectos
• Incrementa reutilización y flexibilidad
 Un modelo
 Varias vistas
 Varios controladores
Las vistas y los controladores suelen estar muy relacionados

Los controladores tratan los eventos que se producen en la interfaz gráfica (vista)
Esta separación de aspectos de una aplicación da mucha flexibilidad al
desarrollador

Ingeniería WEB
Flujo de control
1. El usuario realiza una acción en la interfaz

2. El controlador trata el evento de entrada (previamente se ha registrado).
3. El controlador notifica al modelo la acción del usuario, lo que
puede implicar un cambio del estado del modelo (si no es una mera consulta)
4. Se genera una nueva vista. La vista toma los datos del modelo(El modelo
no tiene conocimiento directo de la vista).
5. La interfaz de usuario espera otra interacción del usuario, que
comenzará otro nuevo ciclo

Ingeniería WEB
MVC en aplicaciones Web
• Vista: la página HTML.

• Controlador: código que obtiene datos dinámicamente y genera el contenido
HTML.
• Modelo: la información almacenada en una base de datos o en XML, junto con
las reglas de negocio que transforman esa información (teniendo en cuenta las
acciones de los usuarios).
Vista
Navegador Controlador
• Modelo: lógica de negocio

• Vista (interfaz de usuario): las
Modelo BD
clases y/o artefactos que generan
las repuestas visuales Servidor de aplicaciones Web J2EE
• Controlador (interfaz de usuario): (ej.: Jakarta Tomcat)
las clases que reciben los eventos
del usuario, invocan al modelo, y
finalmente a la vista Dr. Clemente García Gerardo
Ingeniería WEB
Ejemplo en Java con el patrón MVC
Desarrollar una aplicación OO que permita realzar conversiones de:

• Cantidad de Pesetas a su correspondiente en Euros.
• Cantidad de Euros a su correspondiente en Pesetas.
Modelo Controlador Vista

Ingeniería WEB

Ingeniería WEB

Ingeniería WEB

Ingeniería WEB

Ingeniería WEB
Contolador
class ControlConversor implements ActionListener {
private InterfazVista vista;
private ConversorEurosPesetas modelo;
public ControlConversor(InterfazVista vista, ConversorEurosPesetas modelo){
this.vista = vista;
this.modelo = modelo;
}
public void actionPerformed(ActionEvent evento) {
double cantidad = vista.getCantidad();
//Checa el titulo del boton pulsado con la constante defibida
if ( evento.getActionCommand().equals(InterfazVista.AEUROS) ) {
vista.escribeCambio( cantidad + " pesetas son: "+ modelo.pesetasAeuros(cantidad) + " euros" );
}
else if ( evento.getActionCommand().equals(InterfazVista.APESETAS)) {
vista.escribeCambio( cantidad + " euros son: "+ modelo.eurosApesetas(cantidad) + " pesetas" );
}
else
vista.escribeCambio( "ERROR" );
}
}
Ingeniería WEB
Comentarios
• El modelo
¿ tiene algo de código que dependa de la vista o del controlador?
• El control
manipula el modelo y gestiona la vista
• La vista
• Tiene que implementar una interfaz predefinida para la aplicación
• Tiene que configurar a quién le llegan los eventos que se produzcan sobre
sus elementos

Ingeniería WEB
Agregando otra interfaz Vista textual

Indica la operación que quiere realizar:
1: convertir euros a euros
2: convertir pesetas a pesetas
0: salir
1
Cantidad a convertir (formato 99.99): 2
2.0 pesetas son: 0.0120 euros
0: salir
2
Cantidad a convertir (formato 99.99): 3
3.0 euros son: 499.158 pesetas
0: salir
0
Adiós.

Ingeniería WEB
• ¿Qué hay que cambiar en el modelo y el control para utilizar la vista textual en
vez de la gráfica?
¿Qué hay que cambiar en el programa principal?

Ingeniería WEB

Ingeniería WEB
¿Qué patrones de navegación están disponibles ?
El éxito de las WebApps frecuentemente se basan en la facilidad con la que un

usuario puede moverse dentro del espacio de la información. Cuando un equipo de
ingeniería web comienza el diseño, puede surgir una amplia gama de problemas de
navegación. El problema puede ser tan simple como el ordenamiento de contenido
o tan complejo como el diseño de una estructura de navegación integral.
Los patrones de navegación dirigen esos y otros problemas que se relacionan con
la organización del contenido tal como se expresa en la estructura de navegación
de la webapp.
Ejemplos de patrones de navegación

1. Patrones de navegación
Hay patrones generales que describen la disposición del contenido que sea
apropiado dentro de un contexto diferente. por ejemplo, el patrón noticia describe
una estructura en la que el contenido de las noticias más reciente está vinculado
desde la página principal y el contenido más antiguo se encuentra disponible a
través de un archivo estructurado
Ingeniería WEB
2. Navegación
En lugar de describir la navegación específica, los patrones describen mecanismos
para el acceso y la comprensión de la estructura. A modo de ejemplo, el "patrón
minesweeping " implica presentación dinámica de los resúmenes de contenido.
Este patrón no es adecuado cuando el usuario busca información específica.
3. Estructura de navegación
4. Moverse (getting around)

Ingeniería WEB
Patrones de navegación
News
Intención:
Dada una aplicación hipermedia grande y dinámica (por ejemplo, un sitio Web) proporcionar a los
usuarios información sobre los nuevos elementos que se han agregado.
El problema:
La mayoría de los grandes sitios web son de estructura de árbol; esta forma de organizar la
información ofrece una simple metáfora de navegación, sin embargo, estos espacios de información
tienden a ser grandes, y casi nunca están navegado por un solo usuario.
Supongamos que estamos construyendo un sitio que ofrece una gran variedad de productos de
hardware (impresoras, escáneres, etc). En este contexto, la nueva información se puede añadir con
frecuencia. Como la mayoría de los usuarios a navegar un sitio web no lo hacen a fondo ni con
regularidad, esto se convierte en un problema a tener en cuenta, debido a que el éxito de un nuevo
producto puede estar estrechamente relacionado con el conocimiento del cliente de su existencia. Es
evidente que la información comercial de vital importancia como este no puede dejarse al azar que se
descubra.
solución:
Estructurar la página principal de tal manera que un espacio está dedicado a las más recientes
adiciones, presentando "titulares" descriptivos respecto a ellos. Utilice esos titulares como anclas para
vincularlos con sus páginas relacionadas. Este enfoque permite al diseñador para preservar una buena
organización de la información, mientras que ofrece a los usuarios información de los cambios que
tienen lugar en el sitio web.

Ingeniería WEB
Fuentes de patrones disponibles para Ingenieros Web

A Web Design pattern by Martjin Van Welie
www.welie.com
B Patterns for personal Web Sities
www.128.ibm.com/developerworks/patterns/
C
Página 332 pressman

Ingeniería WEB
Usos conocidos:
News se utiliza en cientos de sitios web y aplicaciones como
http://www.nga.gov donde se utiliza para anunciar las nuevas colecciones y las
giras actuales disponibles, otros ejemplos son: www.ibm.com,
www.inprise.com , www.sun.com

Ingeniería WEB
Shopping Basket
Intención:
Lleve un registro de las selecciones del usuario durante la navegación, por lo que estas selecciones
persistentes para procesarlos cuando el usuario lo decida.
El problema
El comercio electrónico es una realidad en la Web. Sin embargo, los usuarios a menudo quieren
navegar a través del mercado electrónico para decidir lo que van a comprar y en qué momento. En
www.amazon.com por ejemplo, un usuario puede navegar a través de cientos de libros o CDs y elegir
un subconjunto de ellos para ser comprado. La solución sería ingenuo si se le pregunta si va a
comprar el producto en el momento en que lo encuentre o forzarlo a enviar a favorito todos los
productos que le gustan y comprarlos en otra sesión de navegación.
Está claro que estos enfoques no son adecuados para los casos en los que queremos comprar
docenas de diferentes productos ya que es bastante incómodo para el usuario (e incluso para la
tienda) para exigir una transacción para cada producto. Esta alternativa tiene otro inconveniente, ya
que tenemos que navegar a la "salida" página muchas veces perdiendo así el tiempo de conexión.
Mientras tanto, debemos ser conscientes de que estas restricciones de comercio electrónico no deben
interferir con la estructura de navegación global del sitio Web.
Solución:
Proporcionar a los usuarios con una metáfora similar a los marcadores, por lo que le permite
seleccionar los productos que desea comprar, ya que se recorren. Proporcionar una tienda de
"persistente" para esos artículos (una cesta de la compra) que se puede acceder como otros objetos
de navegación y procesamiento asociado a las operaciones de la canasta, como eliminar un
elemento, cambiar las cantidades, check-out, etc

Ingeniería WEB
Esta solución es fácil de implementar mediante la adición de un objeto de interfaz (usualmente un
botón) para cada producto disponible en un sitio de compras. Cuando el usuario selecciona este
producto, que se agrega a su lista de compras. Más tarde, el usuario puede navegar a la cesta de la
compra en la que se encontrará, una descripción detallada de cada producto o un ser resumido más un
ancla a la página del producto.
Usos conocidos:
Hay muchos ejemplos de este patrón disponibles en la web. Uno de ellos es la Amazon Bookstore
(http://www.amazon.com) como se muestra en la Figura.

Ingeniería WEB
Landmark
Intención:
Proveer fácil acceso a los diferentes subsistemas, aunque no relacionados en una aplicación
hipermedia.
El problema:
Supongamos que estamos construyendo un sistema Web para realizar compras electrónica, como
www.amazon.com. Al entrar en el sitio, podemos encontrar muchos productos diferentes, tales como
videos, libros o CDs. Podemos explorar los productos y además ofrecemos enlaces a las
recomendaciones, comentarios sobre los productos, noticias, etc. Cuando describir el esquema de
navegación (es decir, la red de nodos y enlaces), tratamos de seguir de cerca esas relaciones
existentes en el modelo de objetos subyacente; por ejemplo podemos navegar de un autor a sus
libros, desde un CD a la lista de canciones que incluye. Podemos ir de un libro a los comentarios que
algunos lectores anteriores hicieron, leer libros relacionados, etc.
Sin embargo, es posible que queramos que en cualquier momento el lector puede saltar a la música o
libros (sub) tiendas o a su cesta de la compra. Si construimos el esquema de navegación que une
todas las clases de navegación (como el libro, comentario, noticias, canciones, etc) a la tienda de
música, la tienda de libros o la cesta, terminaremos con un esquema difícil de entender; esos enlaces
están claramente fuera del modelo.
solución:
Definir un conjunto de puntos de referencia y hacerlas accesibles desde cualquier nodo de la red.
Hacer la interfaz de enlaces a los puntos de referencia deben tener aspecto uniforme. De esta manera,
los usuarios tendrán una señal visual sobre la marca.

Ingeniería WEB
Usos conocidos
Landmark se pueden encontrar en diferentes aplicaciones web tales como www.inprise.com. En
Macaulay de "La forma en que las cosas funcionen", el lector puede saltar de forma permanente a las
invenciones, los Principios de la Ciencia y mundo de las máquinas.

Ingeniería WEB
Active reference
Intención:
Proporcionar una referencia perceptible y permanente sobre el estado actual de la navegación, la
combinación de una herramienta de orientación con una manera fácil de navegar a un conjunto de
nodos relacionados, al mismo o mayor nivel de abstracción.
El problema:
En muchas aplicaciones hipermedia, tenemos que proporcionar al usuario una manera de entender
dónde está y ayudarle a decidir a dónde ir después. Por ejemplo en un museo digital, nos gustaría
que el usuario pueda ver las obras de arte y al mismo tiempo debemos saber en que lugar del museo
es. La solución ingenua habitual incluiría un índice (u otra estructura de acceso) a los elementos que
se pretenda navegar.
Sin embargo, esta solución requerirá al usuario dar marcha atrás desde el nodo actual en el índice
para ver dónde está o moverse a otro nodo, al tiempo que garantiza que su posición actual se resalta
en el índice. Estas operaciones de navegación: mover hacia atrás con el índice y el avance hacia el
objetivo pueden desorientar al usuario.
Solución:
Una buena solución es mantener un objeto de navegación activa y perceptible como un índice para
otros objetos de navegación (ya sean nodos o sub-índices). Este objeto permanece perceptible junto
con objetos de destino, dejando que el usuario pueda explorar los objetos o seleccionar otro objetivo
vinculados. De esta manera, seremos capaces de interactuar tanto con el índice y los nodos de
destino.

Ingeniería WEB
Un ejemplo de aplicar esta solución se puede encontrar en el sitio web City.Net (http://www.city.net).
Como podemos ver en la Figura 4, el lector tiene una referencia permanente acerca de dónde se encuentra
mientras él explora las ciudades en el mundo (ver "Ubicación: América del Sur -> Argentina -> Buenos
Aires 'a la izquierda).

Ingeniería WEB

Ingeniería WEB
Set-based navegation
Intención:
Proporcionar al usuario una navegación subespacios cerrados que se puedan navegar fácilmente.
El problema:
Aplicaciones hipermedia por lo general implican tratar con colecciones de nodos (pinturas, ciudades,
personas, etc). Estas colecciones pueden ser explorados en diferentes maneras, de acuerdo con la
tarea que el usuario está realizando. Por ejemplo, podemos querer explorar Pinturas de pintor, Pinturas
sobre un tema determinado, etc, y es deseable que el usuario pueda moverse fácilmente de un nodo a
otro. Dado que los vínculos entre los miembros del conjunto no suelen reflejar las relaciones
semánticas que rara vez son implementado en aplicaciones hipermedia. La estrategia habitual seguida
por los diseñadores consiste en proporcionar un índice para establecer miembros (véase los resultados
de una búsqueda en un navegador); los usuarios deben entonces volver al índice para navegar al
siguiente miembro del conjunto. Por lo tanto, se pierde la sencillez habitual de navegación de
hipertexto.
solución:
Considere la posibilidad de la navegación basada en la configuración de una estrategia de navegación
"de primera clase". Grupos de nodos en conjuntos significativos y proporcionar facilidades de
navegación entre los conjuntos , tales como índices y enlaces para permitir que el usuario navegue
desde el elemento actual a los elementos; "próximos" y "anteriores“.
WWW.9gag.com, roberto

Ingeniería WEB
Usos conocidos
Se ha utilizado en muchas aplicaciones hipermedia exitosas. Por ejemplo, en la Galería de Arte de
Microsoft, pinturas de la National Gallery de Londres se presentan en diferentes categorías: por lugar,
época y tema. Pinturas en estas categorías se pueden examinar de forma secuencial, como se muestra
en la Figura.

Ingeniería WEB
Nodes in Context
Intención:
Permita que el mismo nodo aparecer en diferentes contextos de navegación modificando su aspecto y
conexiones con otros nodos de acuerdo con el contexto actual.
El problema
Supongamos que estamos usando navegación basada en el contexto de una galería con pinturas.
Cuando llegamos a "Van Gogh" elegimos navegar a sus pinturas, y luego llegar a "Sun Flowers". Sin
embargo, también podemos llegar "Sun Flowers", mientras que la exploración de Pinturas sobre la
naturaleza. Está claro que vamos a explorar el mismo objeto bajo dos perspectivas diferentes. Por
ejemplo, mientras que el acceso a ella como una obra de Van Gogh nos gustaría leer algunos
comentarios sobre sus relaciones con otras pinturas de Van Gogh; también nos gustaría tener un fácil
acceso a otros cuadros que pintó. Mientras tanto, como una pintura en la naturaleza, que estaría bien
para leer (o ver) algo sobre ese tema y ser capaz de acceder a otras pinturas sobre el mismo tema
(tal vez no de Van Gogh). Esto significa que vamos a necesitar no sólo para presentar la información
de una manera diferente en ambos casos, sino también para proporcionar diferentes enlaces o
índices.
Nótese que necesitamos para acceder a los mismos nodos hipermedia en diferentes contextos; los
nodos deben estar conectados con (contextuales) enlaces, por ejemplo es deseable que se puede
pasar a la pintura "Siguiente" en las mismas colecciones. Sin embargo, aunque el contexto en el que
se está accediendo a un nodo no es una preocupación del nodo, no es práctico y puede proteger a
inconsistencias tener diferentes objetos para representar el mismo componente pero en cada
contexto diferente.

Ingeniería WEB
solución:
Disociar los objetos de navegación desde el contexto en el que no se han explorado, y definir
peculiaridades objetos 'como Decoradores [Gamma95], que enriquecen la interfaz de navegación
cuando el objeto es visitado en ese contexto. De esta manera nodos en contexto lo permite que el
mismo objeto puede proporcionar diferente información, incluyendo enlaces, según el contexto en el
que se está accediendo.
En la galería de arte, por ejemplo, los anclajes que se muestran en la figura 2 permiten navegar a
través de la contexto actual; por ejemplo, si accedimos Sun Flowers como una pintura de la naturaleza
en el botón "siguiente" permite que veamos otra pintura en la naturaleza. Mientras tanto, si llegamos a
Sun Flowers como Van Gogh pintura, el significado de los cambios "próximos" que nos permita
navegar a otro de sus cuadros. La información contextual se presenta al lector en el panel inferior
central.
Patrones de navegación Contextos muestran una forma de organizar la estructura de navegación de la
aplicación. Contextos de navegación se componen de un conjunto de nodos (como Pinturas) y enlaces
(links contextuales que conectan los objetos en un contexto). Los nodos están decoradas con más
información sobre un contexto particular y anclajes adicionales para los enlaces de contexto (utilizando
Nodos en Contexto). Un nodo de índice puede proporcionar enlaces a todos los nodos en el contexto o
un enlace a la primera one.ader en el panel inferior central.
Volviendo al ejemplo de "Van Gogh", podemos pensar en 'pintura' y 'Autor' como tipos de nodos de
aplicación. Tendremos dos posibles contextos de navegación: 'contexto relacionado el tema de "y"
contexto relacionado Autor-'. En consecuencia, vamos a definir el tema de decoradores relacionada al
contexto y decoradores de contexto relacionados con el autor que definen la información relacionada
que una pintura se mostrará en cada contexto, y anclajes para la 'próxima' pintura 'anterior' y en el
mismo contexto. Un diagrama de los elementos que interactúan se muestra en la siguiente Figura, en
el que el nodo de contexto tiene un índice de los nodos y cada decorador proporciona un ancla a la
'siguiente' nodo del contexto.
Ingeniería WEB
Construcción y Despliegue
Sin importar el tipo de WebApp que tiene que ser construido o el proceso (o la falta
de proceso) que se utiliza para su construcción, un equipo WebE debe construir una
aplicación utilizando el diseño como una guía y tecnologías disponibles como un
conjunto de herramientas.
El WebE también debe desplegar la WebApp a través de la mayor cantidad de
ambientes que sean necesarios.
En el contexto del proceso de WebE, una WebApp está diseñado como una serie de
incrementos. Las dos últimas actividades en el proceso de WebE son:
• Construcción
Las Herramientas y tecnologías Web son utilizadas en la construcción de las
WebApps que han sido modeladas. Una vez que el incremento de la WebApp se
ha construido, una serie de pruebas de diagnóstico rápido se llevan a cabo para
asegurar que los errores en el diseño (es decir, el contenido, la arquitectura,
interfaz, navegación) están al descubierto. Las pruebas adicionales aborda otras
características de aplicación web.

Ingeniería WEB
La actividad de construcción abarca un conjunto de acciones de codificación,
creación, integración, refactorización, pruebas.
Refactorización (Refactoring) es:

• El proceso de cambio de un sistema de software de tal manera que no altera el
comportamiento externo del código y mejora su estructura interna.
• Es una manera disciplinada para limpiar el código que minimiza las posibilidades de
introducir errores.
• En esencia cuando se refactoriza está mejorando el diseño del código después de
que haya sido escrito.
¿Cuándo no sería conveniente esta refactorización?
¿Es correcto el modelo?
Cuando los métodos varían en su
implementación.
¿Cómo se puede mejorar? Se debe solucionar subiendo el

método pero sin implementarlo en la
clase padre y sobreescribiéndolo en
las clases hijas.
La refactorización es parte importante

del proceso de reingeniería y puede
Subiendo el método Dr. Clemente García Gerardo enfocarse a la reestructuración de
códigos.
Ingeniería WEB
Refactorización en código
El siguiente programa realiza cálculos utilizando el porcentaje de impuestos que se
maneja en cada estado.

Ingeniería WEB
El siguiente programa obtiene un dato utilizando dos métodos

Ingeniería WEB
Principios y conceptos de construcción

Un conjunto de principios y conceptos fundamentales permite a un equipo de
WebE desarrollar AppWebs mantenibles y verificiable (testable).
Los principios y conceptos que guían la tarea de la construcción están
estrechamente alineados con el estilo de programación, lenguajes de programación
y métodos de programación. Sin embargo, hay una serie de principios
fundamentales específicos para Web que son útiles tener en cuenta durante la
actividad de la construcción.
1. Principio de preparación. Antes de que crees una página web sencilla o
escribas una línea de código, debes estar seguro de:
 Entender el problema que estás tratando de resolver.
 Comprender los principios básicos de diseño de aplicación web y los conceptos.
 Seleccione el lenguaje que satisface las necesidades del componente que se
construirá y el entorno en el que va a operar.
 Seleccione un entorno que ofrece herramientas que harán el trabajo más fácil.
 Crear un conjunto de pruebas unitarias, que se aplicarán una vez que el componente
se ha completado.
Ingeniería WEB
2. Principio de selección. A medida que seleccione componentes y objetos

existentes (reutilizables ), estar seguro de:
 Tener en cuenta las limitaciones del entorno técnico.
 Tener en cuenta las habilidades y el conocimiento de los desarrolladores (usar y dar
mantenimiento).
 Considere la posibilidad de problemas de propiedad intelectual, la naturaleza
propietaria de los componentes, y si son portátiles.
3. Principio de codificación. Al comenzar la escritura de código, asegúrese de:
 Escribir código que es auto-documentado.
 Seleccionar las estructuras de datos que satisfagan las necesidades del diseño.
 Entender la arquitectura funcional y crear interfaces que sean compatibles con ella.
 Mantenga la lógica condicional tan simple como sea posible y asegurarse de que es
comprobable.
 Adoptar estilos de codificación que ayudan en la lectura (seguir estándares de
codificación).
Una amplia variedad de enlaces a los estándares de codificación se puede encontrar
en el sitio web de la lecto-escritura Programador,
www.literateprogramming.com/fpstyle.html.
Ingeniería WEB
4. Principio de integración. Al integrar sus componentes y objetos, estar seguro

de que:
 Mantenga copias de seguridad de preferencia en algún tipo de sistema de control de
versiones.
 Aproveche la oportunidad de identificar los componentes que necesitan
refactorización.
 Busque desajustes o inconsistencias de los componentes de la Interfaz
5. Principio de refactorización. A medida que refactorizar su aplicación web,
asegúrese de que:
 Comprender refactorizaciones comunes (ejemplos de refactorizaciones en la
www.refactoring.com/catalog/index.html).
 Refactorizar a menudo y en pequeños pasos, cuando se presente la oportunidad.
6. Principio de pruebas. Después de haber completado sus primeros
componentes, asegúrese de:
 Realizar pruebas de unidad y corregir los errores que has descubierto.
 Seleccionar las pruebas que tienen más probabilidades de localizar los errores en
lugar de una para ocultarlos.

Ingeniería WEB
Principios de despliegue que deben guiar a un WebE
Principio #1. Las expectativas del cliente con respecto a un incremento de la
WebApp debe ser controlada.
Con demasiada frecuencia, el cliente espera más de lo que el WebE ha prometido
entregar, y la decepción se produce inmediatamente. Esto da lugar a que la
retroalimentación no sea productiva y arruina la moral del equipo.
En [Kar94] se sugiere que un desarrollador debe tener cuidado con el envío de
mensajes contradictorios al cliente, por ejemplo, prometiendo más de lo que
razonablemente puede entregar en el plazo previsto o entregar más de lo que
promete para un incremento de software y luego menos de lo prometido para la
próxima.
Principio #2: Un régimen de apoyo debe ser establecido antes de que la WebApp
sea entregada.
Los usuarios finales esperan información precisa cuando una pregunta o problema
surja. Si el apoyo no satisface al cliente, o peor aún, no existiese, los clientes se
sentirán rápidamente insatisfechos.
.

Ingeniería WEB
Principio #3. Los errores de las WebApp deben arreglarse primero, entregarse
más tarde.
Bajo la presión del tiempo, algunos desarrolladores de WebApp ofrecen
incrementos de baja calidad con avisos “proceso de construcción“ y advertencias
para el cliente que los errores "se arreglarán en la próxima versión”.
Esto es un error. Hay un dicho en el negocio del software: "Los clientes olvidarán
que usted entregó un producto de alta calidad con días de retraso, pero nunca
olvidarán los problemas que les causó un producto de baja calidad . La WebApp les
recuerda todos los días ".

Ingeniería WEB
Despliegue
La WebApp está configurada para su entorno operativo al que se entrega , a los
usuarios finales, y un período de evaluación comienza. La retroalimentación de
la evaluación se presenta al equipo de WebE, y el incremento se modifica según
sea necesario.

Ingeniería WEB
La figura muestra el proceso WebE con la iteración entre las actividades de

construcción y el despliegue.
¿Cuál es el proceso de interacción entre la actividad de

construcción y despliegue?
Planeación
Comunicación Aunque el ciclo del proceso general se repite para cada
incremento de la aplicación
Modelado web, también hay iteración
WebE
significativa entre las actividades de construcción y
process
despliegue de un incremento particular.
Framework
En algunos casos, una cuestión menor es identificado
como consecuencia de la construcción, y esto requiere un
pase rápido a través de otras actividades WebE (por
Despliegue
ejemplo, de modelado).
AConstrucción
veces el camino iterativo interior (que se muestra en la
Entrega Evaluación figura) será intencional y planificada, y en otras ocasiones
puede serPruebas
Codificación casual o simplemente una consecuencia de la
secuencia de desarrollo.

Ingeniería WEB
¿Qué papel juegan los ambientes de despliegue?
En WebApps muy sencillas, puede ser aceptable un solo desarrollador para crear
contenidos locales (por ejemplo, editado en un equipo local sin que el contenido se
aloja en un servidor). El contenido se publica a en el servidor de producción para
un acceso inmediato por parte de los usuarios.
Publica

Ingeniería WEB
Para los WebApp complejas (en los que es fundamental que se garantice la calidad
de la aplicación web antes de su liberación), un entorno de desarrollo más
complejo se vuelve apropiada.
Integrar
Publicar
Liberar
Ingeniería WEB
Probando WebApp
Las pruebas de WebApps va más allá de las pruebas de los sistemas de software
tradicionales.
Las WebApp tiene factores que lleva a utilizar requisitos especiales de prueba:
• Los usuarios son grupos heterogéneos (es difícil predecir el número de usuarios).
• La cantidad de plataformas diferentes donde se usa.
Los tiempos de respuesta son algunos de los factores de éxito decisivos en la

Internet, y tienen que ser probado al principio, a pesar del hecho de que el
hardware de nivel de producción está generalmente disponible sólo mucho más
tarde.
Otros factores importantes para el éxito de una aplicación web, por ejemplo:
• Facilidad de uso
• Disponibilidad
• Compatibilidad con los navegadores
• Seguridad
• Actualidad y la eficiencia, también tienen que ser tomadas en cuenta en las
primeras pruebas.
Ingeniería WEB
Terminología
La prueba es una actividad llevada a cabo para evaluar la calidad de un producto y
mejorarlo mediante la identificación de defectos y problemas. Si ejecutamos un
programa con la intención de encontrar errores, entonces hablamos de pruebas
(Myers 1979). La Figura muestra que la prueba es parte de las medidas de
aseguramiento de la calidad analítica (Bourque y Dupuis 2005). Al descubrir los
errores existentes, se determina el estado de la calidad del programa bajo prueba,
la creación de una base para la mejora de la calidad (eliminación de los errores
encontrados). Un error se presenta si el
Aseguramiento de la resultado real de una prueba de
calidad del software funcionamiento no cumple con
el resultado esperado.
Cada desviación de la definición

Medidas Medidas Medidas
de requisitos es un error.
organizacional constructivas analíticas
La definición implica que los requisitos utilizado como base para la prueba
están completos y disponibles antes de la implementación y prueba. Un
Técnicas de WebApp
fenómeno común en el desarrollo Técnicas
es que los requisitos son a
dinámicas estáticas
menudo incompletos, confusos, y están sujetos a cambios frecuentes.
Típicamente, hay una visiónPruebas
inicial de la funcionalidad
Revisión básica. Esta visión se
implementa para el García
lanzamiento inicial. ComoInspección
resultado, el ciclo de vida de
Dr. Clemente Simulación
Gerardo
desarrollo inicial es seguido …por ciclos para agregar funcionalidad.
Ingeniería WEB
IEEE standard 610.12-1990

error. (1) The difference between a computed, observed, or measured value or
condition and the true, specified, or theoretically correct value or condition. For
example, a difference of 30 meters between a computed result and the correct
result.
(2) An incorrect step, process, or data definition. For example, an incorrect
instruction in a computer program.
(3) An incorrect result. For example, a computed result of 12 when the correct
result is 10.
(4) A human action that produces an incorrect result. For example, an incorrect
action on the part of a programmer or operator.
N o t e : While all four definitions are commonly used, one distinction assigns
definition 1 to the word “error,” definition 2 to the word “fault,” definition 3 to
the word “failure,” and definition 4 t o the word “mistake.”

Ingeniería WEB
Los usaurios no sólo esperan que la WebApp se comporte de una determinada

manera; él o ella esperan que ciertas funciones estén disponibles 7x24 (7 días y 24
horas al día). Por otra parte, los usuarios esperan que la aplicación sea fácil de
usar, fiable, rápido, compatible con otros sistemas y versiones futuras.
Una taxonomía general de las características de calidad de los productos de

software se especifica en la norma ISO / IEC 9126-1 estándar. Esta norma
menciona seis categorías principales de características - la funcionalidad, fiabilidad,
facilidad de uso, eficiencia, mantenibilidad y portabilidad.

Ingeniería WEB
Niveles de pruebas
De acuerdo con las distintas fases de desarrollo en las que se puede producir
resultados verificables, se identificaron niveles de prueba para facilitar la validación
de los resultados.
• Las pruebas unitarias: probar las unidades más pequeñas verificables (clases,
páginas web, etc.), independientemente uno de otro. Las pruebas unitarias se
realiza por el desarrollador durante la implementación.
• Pruebas de integración: Una vez ESPECIFICACIÓN TÉCNICA distintas unidades
que se han integrado
(fueron probadas por separado) evaluar la interacción entre ellas. Las pruebas de
integración se realizan por un probador, un desarrollador, o ambos conjuntamente.
• Pruebas del sistema. probar el sistema completo e integrado. Pruebas del
sistema se realizan normalmente por un equipo de prueba especializado.
• Pruebas de aceptación: evaluar el sistema en cooperación con (bajo el apoyo)
el cliente en un entorno que más se acerca al entorno de producción. Pruebas de
ESPECTATIVAS DEL USUARIO
aceptación usan condiciones reales y los datos reales.
• Pruebas beta: permiten a los usuarios trabajar con las primeras versiones de un
producto con el objetivo de proporcionar retroalimentación temprana.

Ingeniería WEB
Un riesgo inherente al realizar los niveles de prueba de forma secuencial según las
fases del proyecto es que los errores debidos a las expectativas del usuario
incomprendidos pueden encontrarse sólo en una etapa tardía, lo que hace que su
eliminación sea muy costosa.
Un proceso de desarrollo iterativo y evolutivo reduce este riesgo, ya que las partes
del sistema más pequeños se ponen a prueba con frecuencia en todos los niveles
de prueba (incluidos los que tienen validación frente a las expectativas de los
usuarios), por lo que los errores se pueden encontrar antes de que puedan tener
un impacto en otras partes del sistema. Esto significa que la secuencia de niveles
de ensayo descrito anteriormente no siempre dictan la secuencia temporal para las
pruebas de proyecto Web, pero se puede realizar varias veces, por ejemplo, una
vez para cada incrementación de funcionalidad.

Ingeniería WEB
¿Qué hace diferente las pruebas de WebApp de las pruebas de aplicaciones

convencionales?
1. Al probar la estructura de hipertexto, tenemos que asegurarnos que las páginas
se enlazan correctamente, por ejemplo, cada página debe ser accesible a través
de un enlace y a su vez, debe tener un enlace de vuelta a la estructura de
hipertexto. Además, todos los enlaces tienen que apuntar a páginas existentes
(no deben ser roto).
Los enlaces rotos representan errores frecuentes cuando:
 Se hace referencia a una página web externa, que ha sido eliminada.
 La navegación a través de las funciones del navegador Web ("atrás en la
historia“), en combinación con el estado en que se encuentra una
aplicación web.
Ejemplo típico: un usuario al realizar compras en línea coloca un artículo en
el carrito de compra virtual, entonces este artículo se mantendrá en la
cesta de la compra, incluso si el usuario da un paso atrás en el historial del
navegador, que muestra la página anterior sin ese artículo.

Ingeniería WEB
2. Los requisitos suaves y subjetivos en el nivel de presentación de las WebApps,

por ejemplo, la "estética", son difíciles de especificar. Sin embargo, este es un
requisito previo esencial para el probador para poder distinguir de forma clara y
objetiva el comportamiento aceptable (y deseable) de un comportamiento
defectuoso. Además, sólo unos pocos métodos convencionales y técnicas para
las pruebas de software son adecuados para las pruebas de presentación.
3. El gran número de dispositivos posibles y sus diferentes características de
rendimiento (entrega multiplataforma) representan otro desafío. Incluso si un
probador tenía todos los dispositivos posibles a disposición, él o ella tendría que
ejecutar casos de prueba para cada dispositivo. Aunque los simuladores para los
dispositivos pueden ser útiles, a menudo son defectuosas ya que son incapaces
de trazar exactamente las propiedades de un dispositivo, o que estén
disponibles sólo después de la introducción de un dispositivo.

Ingeniería WEB
4. Debido a la disponibilidad y uso de las WebApps a nivel mundial, hay muchos desafíos en
materia de multilingüismo y la facilidad de uso en las pruebas de WebApp. El principal
desafío es reconocer las interdependencias culturales y considerarlas adecuadamente en
las pruebas. Por ejemplo, las órdenes de lectura en diferentes culturas (por ejemplo,
árabe, chino).
5. Las WebApps se componen de diferentes componentes de software (servidores web,
bases de datos, middleware) y sistemas integrados (sistemas ERP, sistemas de gestión de
contenidos), que se suministran con frecuencia por diferentes proveedores, y aplicadas
con diferentes tecnologías. Estos componentes forman la infraestructura técnica de la
WebApp. La calidad de una WebApp se determina esencialmente por la calidad de todos
los componentes de software individuales y la calidad de las interfaces entre ellas.
Esto significa que, además de los componentes desarrollados en un proyecto, vamos a
tener que probar los componentes de software proporcionados por terceros, así como la
integración y la configuración de estos componentes. Muchos errores en las WebApps son
el resultado de la "inmadurez" de componentes de software individuales,
"incompatibilidad" entre los componentes de software, o defectuosa configuración de los
componentes de software adecuados.
Sneed 2004 informa sobre un proyecto industrial, donde la estrategia de prueba fue poner
a prueba la compatibilidad de la aplicación Web con el entorno técnico, además de probar
la funcionalidad de la aplicación web.

Ingeniería WEB
6. El “predominio al cambio" hace que las pruebas de WebApp sean más

complejas que las pruebas de software convencional. Los requisitos,
plataformas, sistemas operativos, tecnologías de Internet y configuraciones,
modelos de negocio y las expectativas de los clientes, el desarrollo y los
presupuestos de prueba están sujetas a los cambios frecuentes a lo largo del
ciclo de vida de una aplicación web.

Ingeniería WEB
Métodos y técnicas de prueba

1. Link Testing (pruebas de enlace).
Los enlaces dentro de una estructura de navegación hipertextual que apuntan a
un nodo no existente (páginas, imágenes, etc.) se llaman enlaces rotos y
representan los errores que ocurren con frecuencia en las aplicaciones web.
Para probar la correcta vinculación de páginas (la comprobación de vínculos),
todos los enlaces se siguen de forma sistemática a partir de una página de
inicio.
Cuando se ejecuta una rutina de comprobación de enlace, por lo general se
encuentran no sólo los enlaces que apuntan a páginas que no existen, sino
también las páginas que no están vinculados entre sí con las demás o los
llamados páginas huérfanas.
Una página huérfano puede ser alcanzado a través de un vínculo, pero no tiene
un enlace de vuelta a la estructura de hipertexto. Además, cuando se prueban
enlaces, se pueden encontrar datos adicionales que suministran indicios de
posibles errores, por ejemplo, la profundidad y amplitud de la estructura de
navegación, la distancia entre dos páginas relacionadas, medido por el número
de enlaces, o los tiempos de carga de páginas.
Ingeniería WEB
2. Browser Testing (Prueba navegador).

Un gran número de diferentes navegadores web se puede utilizar como el
cliente para las aplicaciones Web.
Dependiendo del:
• Fabricante (Microsoft, Mozilla, Netscape, Opera, Google),
• Versión (Internet Explorer 5.0, 5.01, 5.5, 6.0, 9, 11),
• Sistema operativo (Internet Explorer para Windows XP / 2000, Windows
98 / ME / NT o Macintosh, IE 11 está disponible para Windows 7, 8 y 8.1,
los sistemas operativos Windows Vista, XP, Server 2003 y anteriores no
están soportados ),
• Equipo de hardware (la resolución de pantalla y profundidad de color),
• Configuración (la activación de las cookies, lenguajes de script, hojas de
estilo)
Cada navegador web muestra un comportamiento diferente. Normas como las
especificadas por el W3C a menudo no se aplican plenamente y se introducen
"mejoras" incompatibles específicas del proveedor.
Estadísticas y la configuración del navegador Web están disponibles en línea
(http://www.webreference.com/stats/browser.html).
Ingeniería WEB
La prueba navegador intenta descubrir errores en WebApp causados por
incompatibilidades entre los diferentes navegadores web. Con este fin, uno
normalmente define las funciones básicas de una WebApp, diseños de casos de
prueba adecuados, y ejecuta las pruebas sobre diferentes sistemas con diferentes
versiones de navegadores. Durante estas pruebas, hay que hacer las siguientes
preguntas:
• ¿Es el estado de la WebApp gestionado adecuadamente, o podría producirse
estados inconsistentes al navegar directamente a una página, por ejemplo,
utilizando el botón "Atrás" del navegador?.
• ¿Pueden los usuarios utilizar la aplicación web para abrirla en varias ventanas del
navegador (una o varias instancias del navegador Web) simultáneamente?
• ¿Cómo reacciona la aplicación Web cuando el navegador tiene las cookies o
lenguajes de script desactivado?
Para limitar el número de combinaciones posibles de los navegadores, plataformas,

escenarios y otros varios factores de influencia a un conjunto manejable de casos
de prueba, las características de los usuarios actuales o potenciales deben ser
analizados, por ejemplo, mediante la evaluación de los archivos de registro y
estadísticas del navegador, para encontrar combinaciones populares.
Ingeniería WEB
3. Usability Testing (pruebas de usabilidad).

• La prueba de usabilidad evalúa la característica de facilidad de uso (por un
conjunto representativo de usuarios) y navegabilidad de las aplicaciones
web.
• Una prueba de usabilidad formal, por lo general se lleva a cabo en un
entorno de laboratorio, el uso de salas de trabajo equipado con el vidrio de
una sola vía, cámaras de vídeo, y una estación de registro. Tanto los datos
cuantitativos y cualitativos se reunieron.
• El segundo tipo de evaluación de la usabilidad es una revisión heurística.
Una revisión heurística implica que uno o más especialistas de interfaz
humana aplican un conjunto de directrices para:
 Medir la usabilidad de la solución,
 Identificar áreas para la remediación, y
 Proporcionar recomendaciones para el cambio de diseño. provisión de
retroalimentación y la consistencia, etc.

Ingeniería WEB
• En el contexto de las pruebas de usabilidad el tema de hacer la Web

accesible para los usuarios con discapacidad tiene que ser tratado.
Accesibilidad significa que las personas con discapacidad (por ejemplo,
visuales, auditivas, cognitivas o) pueden percibir, entender, navegar e
interactuar con la Web. La Iniciativa de Accesibilidad Web (WAI) del W3C ha
desarrollado enfoques para la evaluación de sitios Web para la accesibilidad,
que también son relevantes para las aplicaciones de pruebas Web. Además
de las directrices de evaluación de la W3C proporciona una
http://validator.w3.org/ servicio de validación) para ser utilizado en
combinación con las pruebas manuales de usuario y de funciones de
accesibilidad.

Ingeniería WEB
4. Pruebas de carga, estrés y continuas.
Estas pruebas se basan en procedimientos similares. Varias solicitudes se envían al

mismo tiempo (por los usuarios simulados) a la aplicación web bajo prueba para
medir los tiempos de respuesta y el rendimiento.
generadores
Las solicitudes utilizadas en estas pruebas son generados por uno o varios "de
carga". Una aplicación de control distribuye los scripts de prueba a través de los
generadores de carga; también sincroniza la ejecución de prueba, y recoge los
resultados de las pruebas.
Sin embargo, las pruebas de carga, pruebas de estrés y pruebas continuas tienen
diferentes objetivos de la prueba:

Ingeniería WEB
• Una prueba de carga, verifica si el WebApp cumple con los tiempos de

respuesta y rendimiento requerido.
En primer lugar determinar los perfiles de la carga (tipos de acceso, cantidad
de visitas por día, horario pico, número de visitas por sesión, número de
transacciones por sesión, etc.) y la transacciones que serán ejecutadas.
A continuación, determinar los valores objetivo para los tiempos de respuesta y
el rendimiento (en operación normal y en las horas punta, por simple o
complejo accesos, con mínimo, máximo, y valores medios). Posteriormente, se
ejecutan las pruebas, la generación de la carga de trabajo con la mezcla de
transacción definido en el perfil de carga, y medir los tiempos de respuesta y el
rendimiento. Los resultados son evaluados, y los cuellos de botella potenciales
se identifican.

Ingeniería WEB
• Una prueba de estrés, verifica si el sistema reacciona de forma controlada en

"situaciones de estrés".
Situaciones de estrés son simuladas mediante la aplicación de condiciones
extremas, tales como la sobrecarga poco realista, o la carga fuertemente
fluctuante. La prueba está dirigida a investigar si (o no) el sistema alcanza los
tiempos de respuesta requeridos y el rendimiento requerido bajo estrés en un
momento dado, y si responde apropiadamente mediante la generación de un
mensaje de error (por ejemplo, rechazando todas las solicitudes adicionales tan
pronto como una predefinido "umbral de inundación" se alcanza). La aplicación
no debe fallar bajo estrés debido a las peticiones adicionales. Una vez que una
situación de estrés ha terminado, el sistema debe recuperar lo más rápido
posible y volver a asumir un comportamiento normal.

Ingeniería WEB
• Prueba continua, significa que el sistema se ejerce durante un largo período de

tiempo para descubrir errores "insidiosas".
Los problemas en la gestión de recursos, tales como conexiones de base de datos o
"pérdidas de memoria" son un ejemplo típico. Se producen cuando una operación
asigna los recursos (por ejemplo, la memoria principal, identificadores de archivo, o
conexiones de base de datos), pero no los dejen en libertad cuando termina. Si
llamamos a la operación defectuosa en una prueba un par de veces "normales", no
vamos a detectar el error. Sólo prueba continua puede garantizar que la operación
se ejecuta repetidamente durante largos períodos de tiempo para reproducirse,
finalmente, el cuello de botella de recursos causada por este error, por ejemplo,
quedarse sin memoria.

Ingeniería WEB
Pruebas de seguridad
Probablemente el criterio más importante

para una aplicación web es el de la
seguridad. La necesidad de regular el
acceso a la información, para verificar las
identidades de los usuarios, y para cifrar
la información confidencial es de suma
importancia.
Ingeniería WEB
• El concepto de la seguridad en los sistemas de software es un área de

investigación que ha pasado a ser vital dentro de la Ingeniería de Software.
• Con el crecimiento de Internet, y otras aplicaciones sobre redes, como el
comercio electrónico, correo electrónico, etc., la posibilidad de ataques se
ha incrementado notablemente, como también lo han hecho las
consecuencias negativas de estos ataques.
• En la actualidad, prácticamente todo sistema debe incorporar cuestiones de
seguridad para defenderse de ataques maliciosos. El desarrollador ya no
sólo debe concentrarse únicamente en los usuarios y sus
requerimientos, sino también en los posibles atacantes.

Ingeniería WEB
Los desarrolladores de software deben conocer tanto las amenazas como las
formas en las que es posible neutralizarlas.
Al considerar los conflictos de seguridad debe contemplarse:
• El software de aplicación
• La infraestructura sobre la que se construye el sistema, que incluye:
• Una plataforma de SO como Windows o Linux.
• Otras aplicaciones genéricas como navegadores web y clientes de
correo electrónico.
• Un sistema de gestión de BD
• Middlewere
• Librerías de componentes reutilizables que utiliza el software de
aplicación.
Diferencia entre seguridad de aplicación y seguridad de infraestructura:
1. La seguridad de aplicación es un problema de ingeniería de software, los
ingenieros deben asegurarse de que el sistema se diseñó para soportar
ataques.
2. La seguridad de infraestructura es un problema de gestión en la que los
administradores del sistema configuran la infraestructura para resistir
ataques.
Ingeniería WEB
Ataques
conocidos
• Enero 2011: Sony
demanda a modders por
hacer jailbreaking e
ingeniería inversa de la
PS3.
• Abril 2011: PSN recibe
ataques DDoS
(denegación de servicio
distribuido) y SQL
injection los cuales roban
información de tarjetas de
crédito de sus usuarios.
Sony cierra PSN por 24
días. Dr. Clemente García Gerardo
Ingeniería WEB
• Mayo 2011: aparece

un sitio phishing en
un servidor Sony.
• Junio 2011: se
filtran bases de
datos y cupones de
Sony Rusia, Sony
Portugal, Sony
Francia y Sony
Europa.

Ingeniería WEB
¿ Cómo ocurrió el ataque ?

Sony ha explicado cómo se llevó a cabo el ataque contra su plataforma. El ataque a
la base de datos de clientes se realizó desde un servidor de aplicaciones conectado
con ella, y que está tras un servidor web y dos cortafuegos o firewalls. Según los
responsables de la compañía, el modo en que se realizó el hackeo "es un técnica
muy sofisticada".
Los autores del ataque lo encubrieron como una compra en la plataforma online de
Sony, por lo que los sistemas de seguridad no detectaron nada raro, y tras pasar del
servidor web, lograron explotar una vulnerabilidad del servidor de aplicaciones para
instalar software que más tarde fue usado para acceder al servidor de la base de
datos, protegido por un tercer firewall.
La vulnerabilidad del servidor de aplicaciones donde se instaló el software para

acceder a la base de datos era desconocida por Sony, que ya se ha apresurado a
crear un puesto de jefe de seguridad de la información para supervisar la seguridad
de los datos de ahora en adelante, además de haber rehecho la seguridad de la
plataforma PlayStation Network para evitar que esto vuelva a pasar.
Ingeniería WEB

Ingeniería WEB
Costo de los ataques para Sony
24000,000,000 dólares
Costo de prevención
Menos de 10,000 dólares

Ingeniería WEB
Terminología asociada a la seguridad

Activo: algo de valor que debe protegerse. El sistema de software en sí o los datos
usados por dicho sistema.
Exposición: posible pérdida o daño a un sistema de computo. Podría ser pérdida o
daño de los datos, o bien, una pérdida de tiempo y esfuerzo si fuera necesaria la
recuperación después de una violación a la seguridad.
Vulnerabilidad: debilidad que tiene un sistema y que puede aprovecharse para
causar pérdida o daño.
Ataque: aprovechamiento de una vulnerabilidad del sistema. Puede ser desde
afuera del sistema y es un intento deliberado por causar daño o pérdida.
Amenaza: circunstancias que tienen potencial para causar pérdida o daño. Una
vulnerabilidad del sistema que está sujeta a un ataque.
Control: medida de protección que reduce la vulnerabilidad de un sistema. Por
ejemplo la encriptación.

Ingeniería WEB
Tipos de amenazas
En cualquier sistema en red, existen tres tipos de amenazas a la seguridad:
1. Amenazas a la confidencialidad del sistema y sus datos: pueden difundir
información a individuos o programas que no están autorizados a tener acceso
a dicha información.
2. Amenazas a la integridad del sistema y sus datos: tales amenazas pueden
dañar o corromper el software o sus datos.
3. Amenazas a la disponibilidad del sistema y sus datos: dichas amenazas pueden
restringir el acceso al software o sus datos a usuarios autorizados.

Ingeniería WEB
Controles a implementar para mejorar la seguridad del sistema

Evitar la vulnerabilidad: controles para garantizar que los ataques no tengan éxito.
Por ejemplo, los sistemas militares sensibles no están conectados a redes públicas,
así que es imposible el acceso externo. La encriptación es una buena medida de
control ya que en la práctica es muy costoso y consume mucho tiempo romper una
encriptación fuerte.
Detectar y neutralizar ataques: controles para detectar y repeler ataques, esto
implica la inclusión de funcionalidad en un sistema que monitorea su operación y
verifica patrones de actividad inusuales. Si se detectan, entonces se toman
acciones, como desactivar partes del sistema, restringir el acceso a ciertos usuarios,
etc.
Limitar la exposición y recuperación: controles que soportan la recuperación de los
problemas, que van desde estrategias de respaldo automatizadas y réplica de la
información, hasta pólizas de seguro que cubran costos asociados con un ataque
exitoso al sistema.
Sin un nivel razonable de seguridad, no se puede confiar en la disponibilidad,
fiabilidad y seguridad de un sistema.
Los errores en el desarrollo de un sistema pueden conducir a lagunas de seguridad,
si un sistema no responde a entradas inesperadas.
Ingeniería WEB
Seguridad en el ciclo de vida del desarrollo del software
• La mayor parte de las organizaciones desarrolla o contrata el desarrollo de

aplicaciones propias para su gestión de negocio.
• Como todo software, estas aplicaciones pueden contener fallas de seguridad y a
diferencia del software comercial, no se dispone de actualizaciones o parches
liberados en forma periódica por el fabricante.
• El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de
la organización que las desarrolla.
¿Qué está pasando en las organizaciones con respecto a la seguridad?
Lamentablemente es una práctica habitual en muchas organizaciones la “puesta en
producción” de sistemas sin la participación del sector de Seguridad de la
Información.
Muchas otras veces, el sector de Seguridad se entera demasiado tarde, y no tiene
suficiente margen de acción para el análisis de seguridad de la aplicación
desarrollada.
En el mejor de los casos, se coordina un testeo de seguridad una vez que la
aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que
requieren el rediseño de parte de la aplicación, lo que implica un costo adicional en
tiempo y esfuerzo. Dr. Clemente García Gerardo
Ingeniería WEB
Costo de errores en el ciclo de vida de desarrollo de software .
Está comprobado que cuánto más temprano se encuentre una falla de

seguridad en el ciclo de vida del desarrollo de software, más rápida y
económica será su mitigación.

Ingeniería WEB
¿ Cuál es el rumbo a seguir ?

Las buenas prácticas indican la conveniencia de
incluir seguridad de la información desde el principio
y a lo largo de todas las etapas del ciclo de vida de
desarrollo.
¿Cómo implementar seguridad a lo largo del Ciclo de
vida del software?
Es importante que el personal de seguridad de la
información participe en las distintas etapas de
desarrollo, supervisando la realización de las mismas.

Ingeniería WEB
Seguridad en el análisis de requerimientos
La confiabilidad de un sistema no sólo depende de buena ingeniería sino también

requiere la atención a los detalles cuando se identifican los requisitos del sistema y
la inclusión de requerimientos especiales de software para garantizar la seguridad
de un sistema.
Los requisitos de confiabilidad y seguridad son de dos tipos:
1. Requisitos funcionales, definen mecanismos de comprobación y

recuperación que deben incluirse en el sistema y en las características que
ofrecen protección contra fallas del sistema y ataques externos.
2. Requerimientos no funcionales, definen la confiabilidad y disponibilidad
requeridas del sistema.
Para generar requerimientos de confiabilidad y seguridad se parte de reglas,
políticas o regulaciones empresariales o de dominio de alto nivel.

Ingeniería WEB
Requerimientos “NO DEBE”
Se trata de requerimientos de alto nivel, descritos mejor como requerimientos “no

debe”.
En contraste con los requerimientos funcionales normales que delimitan la conducta
del sistema , los requerimientos “no debe” definen el comportamiento del sistema
que es inaceptable. Ejemplos:
1. El sistema no debe permitir que los usuarios modifiquen los permisos de acceso
sobre algún archivo que no hayan creado (seguridad).
2. El sistema no debe permitir la selección del modo de empuje inverso cuando la
aeronave está en vuelo (protección).
3. El sistema no debe permitir la activación simultánea de más de tres señales de
alarma (protección).

Ingeniería WEB
Los requerimientos “no debe” no pueden implementarse directamente, sino que

tienen que descomponerse en requerimientos funcionales de software más
específicos o bien, aplicarse a través de decisiones de diseño de sistema, por
ejemplo una decisión para usar tipos particulares de equipo en el sistema.
En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrán

impacto en los aspectos de seguridad de la aplicación. Algunos de ellos son:
1. Requerimientos de compliance (cumplir las leyes y regulaciones de una

compañía) con normativas locales o internacionales (ej: PCI, SOX, “A” 4609,
etc.),
2. Tipo de información que se transmitirá o procesará (ej: Información pública o
confidencial, datos personales, datos financieros, contraseñas, datos de pago
electrónico, etc.) y
3. Requerimientos de registros de auditoría (ej: Qué debe registrar la aplicación en
sus logs o bitácora).

Ingeniería WEB
Seguridad en el diseño
Antes de comenzar a escribir líneas de código, hay numerosos aspectos de
seguridad que deben ser tomados en cuenta durante el diseño de la aplicación.
Algunos de ellos son:
1. Diseño de autorización: Definir los roles, permisos y privilegios de la
aplicación.
2. Diseño de autenticación: aquí se debe diseñar el modo en el que los
usuarios se van a autenticar, contemplando aspectos tales como los
mecanismos o factores de autenticación con contraseñas, tokens, certificados,
etc. posibilidades de integrar la autenticación con servicios externos como
LDAP (Protocolo Ligero de Acceso a Directorios), Radius o Active Directory y
los mecanismos que tendrá la aplicación para evitar ataques de diccionario o
de fuerza bruta por ejemplo, bloqueo de cuentas, implementación de
“captchas”, etc.

Ingeniería WEB
3. Diseño de los mensajes de error y advertencia, para evitar que los mismos
brinden demasiada información y que ésta sea utilizada por atacantes.
4. Diseño de los mecanismos de protección de datos, aquí se debe contemplar el
modo en el que se protegerá la información sensible, ya sea en tránsito o
almacenada; según el caso, se puede definir la implementación de encriptación,
hashes o truncamiento de la información.
Una vez que se cuenta con el diseño detallado de la aplicación, una práctica
interesante es la de realizar sobre el mismo un análisis de riesgo orientado a
software. Existen técnicas documentadas al respecto, tales como Threat Modeling
(modelado de amenazas).
Estas técnicas permiten definir un marco para identificar debilidades de seguridad
en el software, antes de la etapa de codificación.
Como valor agregado, del análisis de riesgo orientado a software se pueden
obtener casos de prueba para ser utilizados en la etapa de Testing/QA.

Ingeniería WEB
Seguridad en la codificación
Una vez concluido el diseño, le toca a los desarrolladores el turno de codificar los
distintos componentes de la aplicación.
Es en este punto en donde suelen incorporarse, por error u omisión, distintos tipos
de vulnerabilidades.
Estas vulnerabilidades podríamos dividirlas en dos grandes grupos a saber:
1. vulnerabilidades clásicas .
2. vulnerabilidades funcionales.
Las primeras son bien conocidas y categorizadas. Ejemplo de estas vulnerabilidades
son las presentes en el “OWASP Top 10”, acrónimo de Open Web Application
Security Proyect (proyecto abierto de seguridad de aplicaciones web).
OWASP Top 10 es un documento de alto nivel que se centra sobre las
vulnerabilidades más críticas de las aplicaciones web.
Por ejemplo vulnerabilidades de inyección, Cross Site Scripting (secuencia de
comandos en sitios cruzados), errores en manejo de sesiones, etc., así como
también otras vulnerabilidades no ligadas directamente con las aplicaciones WEB,
como desbordamiento de buffer, denegación de servicio, etc.

Ingeniería WEB
Vulnerabilidades funcionales son aquellas ligadas específicamente a la

funcionalidad de negocio que posee la aplicación, por lo que no están previamente
categorizadas.
Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los siguientes:
1. Una aplicación de banca electrónica que permite realizar transferencias con
valores negativos,
2. Un sistema de subastas que permite ver los valores de otros oferentes,
3. Un sistema de venta de entradas para espectáculos que no impone límites
adecuados a la cantidad de reservas que un usuario puede hacer.
En la etapa de codificación, una de las reglas de oro es ‘verificar todos los

valores de entrada y de salida’. Esto es, asumir siempre que el valor pudo
haber sido manipulado o ingresado maliciosamente antes de ser procesado.

Ingeniería WEB
[Epner2000] Epner M. Poor Project Management Number-One Problem of

Outsourced EProjects. Research Briefs. Cutter Consortium. 7 November 2000.
[Kap91] Kapor, M. “A Software Disegn Manifesto”. Dr Dobbs’ Journal.
[Kar94] Karten, N., Managing Expectations, Dorset House, 1994.
[Fuc98] Fucella J., and J.Pizzolato, “Creating Web Site Designs Based on User
Expectations and Feedback”. ITG Newsletter.
[Sneed04] Sneed, H. M., Testing a Web Application, Proc. of the 6th nternational
Workshop on Web Site Evolution (WSE 2004), Chicago, IL, September, 2004.

CURSO

Cargado por

Copyright:

Formatos disponibles

CURSO

Cargado por

Información del documento

Descripción original:

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

CURSO

Cargado por

Copyright:

Formatos disponibles

Instituto Tecnológico de Culiacán

Ingeniería en Sistemas Computacionales.

Dr. Clemente García Gerardo

¿Qué se requiere para ejecutar una aplicación Web típica?

HTML Java Script

Angular Java Script Object Notation (JSON)

Konqueror Internet Information Services Postgres

Navegador Servidores WEB SGBD

Dr. Clemente García Gerardo

Arquitectura de las aplicaciones WEB (WebApp)

Navegador Petición Servidor Programa o Script

navegador (primer nivel otra vez).

Dr. Clemente García Gerardo

Componentes de una arquitectura para una aplicación Web

Firewall Proxy Web-Server La comunicación entre

CGI . Common Gateway Interface

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

Pero el pensamiento de la vieja escuela estableció una cultura que rápidamente se

Dr. Clemente García Gerardo

Desarrollo de WebApp: el enfoque de hoy

Dr. Clemente García Gerardo

Una encuesta sobre el desarrollo de WebApp, realizada por el Consorcio Cutter

Dr. Clemente García Gerardo

Las razones de las deficiencias de calidad:

Dr. Clemente García Gerardo

¿Será la forma correcta que debemos utilizar para el desarrollo de WebApp?

Crisis del WEB

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

La Ingeniería Web es una especialización

Dr. Clemente García Gerardo

El escenario descrito en [Epner2000] motiva, a San Murugesan, Athula Ginige,

Proceso de la Ingeniería Web

Dr. Clemente García Gerardo

Dr. Clemente García Gerardo

Proceso de Ingeniería Web

Dr. Clemente García Gerardo

Adicionalmente los principios de García

Expandiendo el framework de proceso de Ingeniería Web

Dr. Clemente García Gerardo

Comunicación: dentro del proceso de Ingeniería Web, la actividad de

Flujo de proceso incremental (gradual).

¿ Cómo es refinado el Framework ?

Dr. Clemente García Gerardo

¿ Cómo debe ser refinada la actividad Comunicación ?

Dr. Clemente García Gerardo

¿ Qué tareas se requieren para desarrollar un plan incremental?

Dr. Clemente García Gerardo

• Afinar la descripción del incremento de la WebApp que se entregará

• Estima el esfuerzo y tiempo requerido para desarrollar el incremento

• Define el método de control de cambios

Aunque los incrementos son frecuentemente desarrollados en semanas, no en

Dr. Clemente García Gerardo