SlideShare ist ein Scribd-Unternehmen logo
1 von 231
Ingeniería web
Ing. Aldo Hernan Zanabria Galvez
 Ingeniero de Sistemas – M.Sc. (e) Ingenieria de
Sistemas: Ingenieria de Software
Ing. Aldo Hernan Zanabria Galvez 1
/aldozpuno
@aldozpuno
www.zanabria.org/eva
Que es?
 Planeación de un proyecto web.
 Creación de una lluvia de ideas para mejorar nuestro proyecto.
 Diseño de la Base de Datos de nuestro proyecto.
 Diagrama esquemático del proyecto.
 Creación del Diseño Gráfico: Adobe Photoshop.
 Maquetación del proyecto utilizando XHTML y CSS.
 Programación Web: Ajax, PHP/MySQL, Javascript y XML.
 Optimización.
 Publicando el proyecto en internet.
 Rentabilizar tu proyecto web.
Ing. Aldo Hernan Zanabria Galvez 2
Que es?
 Diseño de procesos de negocio para aplicaciones web
 Generación de código para aplicaciones web
 Desarrollo web colaborativo
 Ingeniería web empírica
 Entornos de desarrollo de aplicaciones web integrados
 Pruebas de rendimiento de aplicaciones basadas en web
 Personalización y adaptación de aplicaciones web
 Modelado de procesos para aplicaciones web
 Herramientas y métodos de prototipado
 Control de calidad y pruebas de sistemas
 Aplicaciones web móviles
 Usabilidad de aplicaciones web
 Accesibilidad para la web
 Metodologías de diseño web
 Diseño de interfaces de usuario
Ing. Aldo Hernan Zanabria Galvez 3
Fundamentos de la Ingeniería Web.
 Se aportan los conocimientos necesarios para que el alumno tenga
una visión global del mercado y la situación del máster en el mismo,
y permite nivelar los diferentes perfiles para conseguir un grupo
homogéneo en conocimientos de ingeniería del software.
Ing. Aldo Hernan Zanabria Galvez 4
Tecnologías Web
 Clientes Multimedia
 Desarrollo de Aplicaciones para Sistemas Móviles
 Desarrollo de Aplicaciones Web de Libre Distribución
 Desarrollo de Aplicaciones Web Propietarias
 Desarrollo de aplicaciones Web Distribuidas de Código Abierto
 Diseño Gráfico
 Sistemas Gestores de Contenido
 Técnologías de Desarrollo para Clientes Ligeros
Ing. Aldo Hernan Zanabria Galvez 5
METODOLOGÍAS DE DESARROLLO Y GESTIÓN PARA
LA WEB
 Metodologías Pesadas para Desarrollo Web
 Metodologías Web Ligeras
 Modelo de Negocio y Comercio Electrónico en la Web
Ing. Aldo Hernan Zanabria Galvez 6
SERVICIOS DE INTERNET
 Servicios y Protocolos de Aplicaciones en Internet
 Seguridad en la Programación Web
Ing. Aldo Hernan Zanabria Galvez 7
FUNDAMENTOS DE LA
INGENIERÍA WEB
Visión general en la Ingeniería Web
Patrones de Diseño
Ing. Aldo Hernan Zanabria Galvez 8
Objetivos
 Introducir al alumno en el desarrollo sistemático de aplicaciones
Web
 Ofrecer los fundamentos básicos de métodos de ingeniería
aplicados al desarrollo de sistemas Web complejos
 Profundizar en el lenguaje de modelado UML para posibilitar el
modelado de aspectos propios de las aplicaciones Web como es el
caso de la navegabilidad
 Incidir en el concepto de calidad en los sistemas Web
 Presentar características avanzadas propias de los sistemas Web
actuales (adaptabilidad, adaptatividad, usabilidad, cooperación...)
 Presentar las líneas de investigación actuales en el campo de la
Ingeniería Web
Ing. Aldo Hernan Zanabria Galvez 9
Ingeniería web
 Cualquier producto o sistema importante es
merecedor de recibir una ingeniería.
 Antes de comenzar a construir lo mejor es :
 Entender el problema
 Diseñar una solución viable
 Implementar la solución de una manera sólida
 Comprobarla en profundidad
 Controlar los cambios
 Mecanismos para asegurar la calidad
Ing. Aldo Hernan Zanabria Galvez 10
Ingeniería web
La ingeniería web no es un clon de la ingeniería
de software, pero toma de ella mucho de los
conceptos y principios básicos de ésta, dando
importancia a las mismas actividades técnicas y
de gestión.
Al igual que cualquier disciplina de ingeniería, la
ingeniería web aplica un enfoque genérico que
se suaviza con estrategias, tácticas y métodos
especializados.
Ing. Aldo Hernan Zanabria Galvez 11
Ingeniería Web
 Con la ausencia de un proceso disciplinado para
sistemas basados en web, cada vez es mas
preocupante la manera de poder enfrentarse con
problemas serios para tener éxito en el
desarrollo, empleo y mantenimiento de los
sistemas
 La forma de crecimiento actual puede dirigirse a
tener una “web enmarañada”
Ing. Aldo Hernan Zanabria Galvez 12
Antes-después
Ing. Aldo Hernan Zanabria Galvez 13
Atributos de aplicaciones web
 Intensivas de red.
 Reside en una red y debe dar servicio a las necesidades de una
comunidad diversa de clientes.
 Controlada por el contenido
 La función primaria de una aplicación web es utilizar hipermedia
para presentar al usuario el contenido de textos, gráficos, sonidos y
video.
Ing. Aldo Hernan Zanabria Galvez 14
Atributos de aplicaciones web
 Evolución continua
 A diferencia de aplicaciones convencionales que evolucionan con
versiones planificadas y cronológicas, las aplicaciones web están en
constante evolución
 Inmediatez
 Tiene una inmediatez de comercialización que no tienen otros tipos de
software. Tiempos de desarrollo apresurados
Ing. Aldo Hernan Zanabria Galvez 15
Atributos de aplicaciones web
 Seguridad
 Debe implementar fuertes medidas de seguridad en toda la
infraestructura dentro y fuera de la aplicación, ya que por su naturaleza
es difícil limitar la población de usuarios que pueden acceder a ella.
 Estética
 Una parte innegable: su apariencia e interacción. Tiene mucho que ver
con el éxito del diseño técnico.
Ing. Aldo Hernan Zanabria Galvez 16
Servicios de Internet.
 Se aportan los conocimientos para comprender los diferentes
servicios existentes y las soluciones tecnológicas.
Ing. Aldo Hernan Zanabria Galvez 17
Tecnologías Web
 Se aportan los conocimientos de las diferentes plataformas y
tecnologías presentes en el mercado actual en todo el proceso que
conlleva el desarrollo de aplicaciones Web..
Ing. Aldo Hernan Zanabria Galvez 18
Metodologías de desarrollo y gestión para la
Web
 Se aportan los conocimientos en las metodologías existentes para
el desarrollo de aplicaciones Web y en la gestión de negocios
virtuales asociados.
Ing. Aldo Hernan Zanabria Galvez 19
Trabajo de Fin de CURSO.
 Ejercicio original, a realizar individualmente y presentar y defender
ante el Docente, en el ámbito de la Ingeniería Web de naturaleza
académica y profesional en el que se sinteticen e integren las
competencias adquiridas en las enseñanzas o durante prácticas en
empresas.
Ing. Aldo Hernan Zanabria Galvez 20
FUNDAMENTOS
Ing. Aldo Hernan Zanabria Galvez 21
Contenidos
 Introducción
 Diferencias entre los sistemas web y el software tradicional
 Ingeniería Web
 Usabilidad
Ing. Aldo Hernan Zanabria Galvez 22
Dependencia social de la red
Ing. Aldo Hernan Zanabria Galvez 23
Usuarios de Internet
Ing. Aldo Hernan Zanabria Galvez 24
Usuarios de Internet
ESTADISTICAS MUNDIALES DEL INTERNET Y DE LA POBLACION
Regiones
Poblacion
( 2011 Est.)
Usuarios
Dic. 31, 2000
Usuarios
Dic. 31, 2011
% Población
(Penetración)
Usuarios
% Mundial
Facebook
Dic. 31, 2011
Africa 1,037,524,058 4,514,400 139,875,242 13.5 % 6.2 % 37,739,380
Asia 3,879,740,877 114,304,000 1,016,799,076 26.2 % 44.8 % 183,963,780
Europa 816,426,346 105,096,093 500,723,686 61.3 % 22.1 % 223,376,640
Oriente Medio 216,258,843 3,284,800 77,020,995 35.6 % 3.4 % 18,241,080
Norte America 347,394,870 108,096,800 273,096,800 78.6 % 12.0 % 174,586,680
Latinoamerica / Caribe 597,283,165 18,068,919 235,819,740 39.5 % 10.4 % 147,831,180
Oceania / Australia 35,426,995 7,620,480 23,927,457 67.5 % 1.1 % 13,353,420
TOTAL MUNDIAL 6,930,055,154 360,985,492 2,267,233,742 32.7 % 100.0 % 799,092,160
NOTAS: (1) Las Estadisticas de Usuarios Mundiales del Internet fueron actualizadas a Diciembre 31, 2011. (2) Para ver información detallada, de un clic
sobre la región o el país correspondiente. (3) Los datos de población se basan en cifras para 2011 del US Census Bureau. (4) Los datos de usuarios
provienen de información publicada por Nielsen Online , ITU y de Internet World Stats. (6) Estas estadísticas son propiedad intelectual de Miniwatts
Marketing Group, se pueden citar, siempre manifestando el debido credito y estableciendo un enlace activo a www.exitoexportador.com . Copyright © 2001-
2012, Miniwatts Marketing Group. Todos los derechos reservados.
Ing. Aldo Hernan Zanabria Galvez 25
¿Cómo afrontar esta demanda?
 Es necesario contar con un conjunto consolidado de procesos,
técnicas y herramientas que ayuden al ingeniero en su labor
 Ingeniería del Software es la disciplina que aplica los principios
de ingeniería al contexto del software
 Creación de soluciones rentables a problemas prácticos
 Mediante la aplicación del conocimiento científico
 Para la construcción de cosas al servicio de la humanidad
(Shaw, 1990)
¿Y esto también para las aplicaciones Web?
Ing. Aldo Hernan Zanabria Galvez 26
¿Y esto también para las aplicaciones Web?
 El desarrollo de aplicaciones web en general no es una excepción
 Presiones para acelerar la salida de las aplicaciones web
 A semejanza de los primeros tiempos del software tradicional, se está
convirtiendo en un crecimiento caótico y sin control de la Web
 ¿Qué se debería haber aprendido?
 Por mucha prisa que exista, es necesario un proceso software que guíe
el devenir del desarrollo, facilitando su futuro mantenimiento y evolución
 Debe elegirse el proceso adecuado
 Que se ajuste a las necesidades del proyecto software y de las
organizaciones involucradas en su ciclo de vida
Ing. Aldo Hernan Zanabria Galvez 27
¿Y esto también para las aplicaciones Web?
“Me parece que cualquier producto o sistema importante es merecedor
de recibir una ingeniería. Antes de comenzar a construir, lo mejor es
entender el problema, diseñar una solución viable, implementarla de
una manera sólida y comprobarla en profundidad. Probablemente
también se debería controlar los cambios a medida que el trabajo vaya
avanzando, y disponer de mecanismos para asegurar la calidad del
resultado final. Muchos de los que desarrollan Webs no dicen lo
mismo; ellos piensan que su mundo es realmente diferente, y que
simplemente no se van a aplicar los enfoques de Ingeniería del
Software convencionales
Roger S. Pressman
Ing. Aldo Hernan Zanabria Galvez 28
Planteamiento del problema
 Crecimiento y desarrollo de Internet en general y de la Web en
particular
 El crecimiento de la Web, como medio de aplicación, ha sido exponencial y muy
rápido
 Gran impacto en muchos ámbitos de la sociedad (banca, comercio,
negocios, industria, educación…)
 Muchas de las aplicaciones tradicionales están siendo migradas
total o parcialmente para tener acceso a la Web
 Avances de las tecnologías wireless y su conexión con Internet
están dando lugar a una nueva generación de aplicaciones Web
móviles
 Mayor dependencia de las aplicaciones Web cada vez más
complejas y críticas
Ing. Aldo Hernan Zanabria Galvez 29
Planteamiento del problema
 Tiempo que ha llevado llegar a los 50 millones de usuarios
 40 años a la telefonía
 35 años a la radio
 20 años al vídeo
 26 años a la televisión
 19 años a los ordenadores
 Sólo 4 años a Internet
Ing. Aldo Hernan Zanabria Galvez 30
Planteamiento del problema
 Este aumento en la importancia de las aplicaciones web no se ha
visto refrendado con una mejora en el proceso de desarrollo de las
mismas
 Existe prisa y presión competitiva en el desarrollo de los sistemas
web
 Prisa por estar en la Web e intentar dominar este espacio en cada área
de aplicación imaginable
 Se sigue un proceso ad-hoc, falto de rigor y sistematización
 Influencias del desarrollo de los primeros sitios web estáticos y de
pequeño tamaño
 Abundan las aplicaciones web desarrolladas sin rigor alguno
 Alta probabilidad de fallo
 Bajo rendimiento
Ing. Aldo Hernan Zanabria Galvez 31
Planteamiento del problema
 No prestan atención a
 La obtención de los requisitos y su análisis
 Las metodologías de desarrollo y los procesos software
 La capacidad de mantenimiento
 La escalabilidad
 La accesibilidad La usabilidad
 La seguridad
 …
 Frecuentemente estos desarrollos recaen en individuos o grupos
pequeños que hacen uso de sus prácticas en absoluto
estandarizadas, por no mencionar la falta de pruebas y
documentación
Ing. Aldo Hernan Zanabria Galvez 32
Planteamiento del problema
 Muchos desarrolladores piensan que el desarrollo de las
aplicaciones web se reduce a la creación de una página web
 Ya sea empleando HTML o un compositor de páginas como Front Page
o Dreaweaver
 Desgraciadamente diversos libros y revistas potencian esta idea
 Hay ciertos tipos de aplicaciones web sumamente simples que pueden
catalogarse dentro de esta clasificación simplista
 Páginas personales, folletos…
 Se trata como un problema de autoría en lugar de como un
problema de desarrollo
 ¿Qué sucede con las aplicaciones que van mucho más allá de la
presentación de contenidos?
 Un aplicación web es más que un diseño visual y una interfaz de usuario
 Planificación, requisitos, diseño del sistema, pruebas, mantenimiento…
Ing. Aldo Hernan Zanabria Galvez 33
Planteamiento del problema
 Las necesidades de estos tipos de aplicaciones incluyen, entre
otras, cómo gestionar
 La presentación de información
 La navegación dentro de la aplicación
 Mecanismos de búsqueda de información
 Interfaces complejas (texto + multimedia)
Ing. Aldo Hernan Zanabria Galvez 34
Planteamiento del problema
 ¿Quién controla los sitios web?
 Lucha entre
 El departamento de informática
 El departamento de marketing y relaciones públicas
 Unidades organizacionales individuales
Ing. Aldo Hernan Zanabria Galvez 35
Planteamiento del problema
 El desarrollo de una aplicación web no es exactamente lo mismo
que el desarrollo de otro tipo de aplicación software
 No se pueden seguir exactamente las mismas prácticas
 Hay varios puntos en común, pero existen diferencias significativas
 Las aplicaciones web requieren un mantenimiento continuo
 La complejidad de las grandes aplicaciones web es, con frecuencia,
engañosa
Ing. Aldo Hernan Zanabria Galvez 36
Planteamiento del problema
 Problemas derivados con una aproximación ad-hoc en el desarrollo
de aplicaciones web
 El sistema completo no es lo qué el usuario quiere
 El sistema no se desarrolla a tiempo y el coste se dispara
 Falta de escalabilidad y capacidad de mantenimiento
 Limitado tiempo de vida útil
 No se cumplen los requisitos de rendimiento
 Derroche de recursos
Ing. Aldo Hernan Zanabria Galvez 37
Ing. Aldo Hernan Zanabria Galvez 38
INTRODUCCIÓN
Ing. Aldo Hernan Zanabria Galvez 39
Crisis de la Web
 Las aplicaciones web pobremente desarrolladas tienen una
probabilidad muy alta de fallar
 Un fallo en una aplicación web puede propagarse causando
problemas en muchas otras
 Potencial para una crisis de la Web: Los desastres de la
Web
 La confianza en la Web puede verse afectada de forma irreparable
 Puede ser más importante y extendida que la crisis del software
 Los proyectos fallan
 Objetivos equivocados
 Carencias en la gestión del proyecto
 Falta de proceso
Ing. Aldo Hernan Zanabria Galvez 40
Evitar los desastres en la Web
 Se necesitan aproximaciones disciplinadas para el desarrollo,
explotación y evaluación de sistemas basados en la Web
 Estas aproximaciones deben tener en cuenta
 Las características propias del nuevo medio que supone la Web
 Los entornos de operación
 Escenarios y multiplicidad de perfiles de usuarios
 El tipo, características y conocimiento de los involucrados en el
desarrollo de un sistema web
 Crecimiento y cambio potencial
Ing. Aldo Hernan Zanabria Galvez 41
Una nueva disciplina
 Se identifican nuevos elementos propios de las aplicaciones web
que no se cubren en las Ciencias de la Computación, en la
Ingeniería del Software o en los Sistemas de Información
 Existe una acuciante necesidad de aproximaciones sistemáticas y
estrategias de desarrollo orientadas a las aplicaciones web
 Debe alejarse de las aproximaciones ad-hoc
 De una aproximación personal y ad-hoc a una aproximación disciplinada
basada en un proceso
 Se necesita engendrar una conciencia sobre la necesidad de una
aproximación sistemática
 En 1998 surge una nueva disciplina interesada en abordar esta
problemática y que recibe el nombre de Ingeniería Web
 Grupo de profesores de la Universidad de Western Sydney
Ing. Aldo Hernan Zanabria Galvez 42
CRISIS DE LA WEB
Diferencias entre los sistemas web y el software tradicional
Ing. Aldo Hernan Zanabria Galvez 43
Sistemas web vs software tradicional
 Los sistemas web tienen una naturaleza y unos requisitos que
difieren del software tradicional
 Los sistemas web
 Están orientados a documentos que contienen páginas web estáticas o
dinámicas
 Se centran en el look & feel y enfatizan la creatividad visual y la
presentación en la interfaz Son conducidos por el contenido, incluyendo
el desarrollo del contenido
 Necesitan ofrecer servicios a usuarios con diversidad de características
y capacidades
 Ejemplifican los vínculos entre el arte y la ciencia que generalmente
aparecen en el desarrollo del software
Ing. Aldo Hernan Zanabria Galvez 44
Sistemas web vs software tradicional
 Los sistemas Web
 Requieren acortar el tiempo de desarrollo, dificultando aplicar el mismo
nivel de formalidad en la planificación y prueba que se aplica en el
software tradicional
 Presentan un formato de distribución y explotación diferente al software
tradicional
 Los desarrolladores de los sistemas web
 Difieren en gran medida en su formación, características, conocimiento y
comprensión del sistema
 Diferencias en su percepción de la Web y de la calidad del sistema web
Ing. Aldo Hernan Zanabria Galvez 45
¿Qué es especial en los sistemas web?
 Evolución del sitio web
 La organización completa es una disposición de celdas
interdependientes
 Gestión del contenido
 El contenido y la funcionalidad cambia en el tiempo
 Gestión del rápido y gran cambio requerido, por ejemplo, en los
sistemas de e-business
 Son como sistemas orgánicos que continuamente se adaptan a su entorno
 Desarrollo abierto
 Los desarrollos y correcciones no tienen que hacerse necesariamente
por ingenieros de software
 Departamentos o personas individuales pueden tener privilegios para
hacer cambios
 Herramientas de autor
Ing. Aldo Hernan Zanabria Galvez 46
¿Qué es especial en los sistemas web?
 El sistema es la organización
 No es un papel soportado, sino que se convierte en el sistema
 Organizaciones virtuales y empresas virtuales
 Diversidad de involucrados
 Internos y externos a la organización
 Consideraciones sobre diferencias regionales, culturales, lingüísticas…
 Responsabilidad ambigua sobre el sitio web
 La gestión global de la estrategia web recibe poca atención
Ing. Aldo Hernan Zanabria Galvez 47
INGENIERÍA WEB
Ing. Aldo Hernan Zanabria Galvez 48
Presentación
 La Ingeniería Web se ocupa del desarrollo y gestión de sistemas
web grandes y complejos
 Tiene como objetivos (Murugesan, 2000)
 Gestionar y controlar la complejidad en todo el ciclo de vida
 Soportar efectivamente los diferentes tipos de usuario de una aplicación
Web
 Hacer de los sistemas basados en la Web menos una aspiración y más
una profesión
 Los sistemas web evolucionan
 Compatibilidad
 Flexibilidad
 Escalabilidad
Ing. Aldo Hernan Zanabria Galvez 49
Presentación
 La Ingeniería Web intenta evitar el caos existente en el desarrollo
de sistemas basados en la Web
 Controlar el proceso
 Minimizar riesgos
 Potenciar la calidad y la capacidad de mantenimiento
 La Ingeniería Web no es un clon de la Ingeniería del Software
 La Ingeniería Web adopta muchos de los principios de la Ingeniería
del Software
 Incorpora muchos de los principios y muchas de las prácticas de la
Ingeniería del Software
 Son sumamente conocidos y están satisfactoriamente probados
 Adapta estos principios a la naturaleza más abierta y flexible de la Web
 Así como también al tipo de aplicación web
 Combina estos principios con elementos que son específicos de la Web
Ing. Aldo Hernan Zanabria Galvez 50
Presentación
 La Ingeniería Web incorpora nuevas aproximaciones, metodologías,
técnicas y guías para cumplir los requisitos de los sistemas web
 Desarrollar aplicaciones web difiere sustancialmente de los
desarrollos tradicionales
 Diferencias en la naturaleza y en el ciclo de vida de las aplicaciones web
 El desarrollo web es una mezcla entre la publicación y el desarrollo
de software, entre la mercadotecnia y la computación, entre las
comunicaciones internas y las relaciones externas, y entre el arte y
la tecnología (Powell, 1998)
Ing. Aldo Hernan Zanabria Galvez 51
Principios de ingeniería aplicados a la Web
 Objetivos y requisitos bien definidos
 Desarrollo de un producto en fases
 Planificación cuidadosa de dichas fases
 Diseño y desarrollo sistemático
 Auditoría continua de todo el proceso
Ing. Aldo Hernan Zanabria Galvez 52
Jardinería web
 Metáfora ampliamente utilizada en el desarrollo de sistemas web
(Murugesan et al., 2001)
 Como los jardines, las aplicaciones web evolucionan, cambian y crecen
de forma continua
 Los sistemas basados en la Web son sistemas que crecen
 Se necesita una buena infraestructura inicial para permitir el
crecimiento de una forma controlada y flexible, a la vez que se fomenta
la creatividad, el refinamiento y el cambio
 Esta metáfora relaciona la necesidad de unos principios de ingeniería
para las aplicaciones web con las capacidades creativas que se pueden
plasmar en muchos de estos sistemas
Ing. Aldo Hernan Zanabria Galvez 53
La Ingeniería Web es un campo multidisciplinar
Ing. Aldo Hernan Zanabria Galvez 54
Definición
 La aplicación de una aproximación sistemática, disciplinada y
cuantificable al desarrollo, operación y mantenimiento de
aplicaciones basadas en la Web o la aplicación de la ingeniería al
software basado en la Web (Murugesan et al., 2001)
 „ La aplicación de principios científicos para diseñar y crear
sistemas de información basados en la Web efectivos de una
manera eficiente (Ginige, 2000)
Ing. Aldo Hernan Zanabria Galvez 55
Categorías de las aplicaciones web
Ing. Aldo Hernan Zanabria Galvez 56
Sistemas web simples vs avanzados
Ing. Aldo Hernan Zanabria Galvez 57
Atributos de las aplicaciones web
 Atributos de las aplicaciones web (Pressman, 2000)
 Intensivas de red
 Controladas por el contenido
 Evolución continua
 Inmediatez
 Seguridad
 Estética
Ing. Aldo Hernan Zanabria Galvez 58
Atributos de las aplicaciones web
 Atributos de las aplicaciones web (Murugesan, 2000)
 En línea (disponibles las 24 horas del día)
 Ubicuidad
 Locales y globales
 Digitalización
 Multimedia Interactividad
 Integración
 Diversidad de accesos
 Intranet
 Extranet
 Público
Ing. Aldo Hernan Zanabria Galvez 59
Calidad de las aplicaciones web
 Las características generales de la calidad del software se aplican a
las aplicaciones web
 Las características más relevantes (usabilidad, eficiencia y capacidad de
mantenimiento) proporcionan una base útil para evaluar la calidad de los
sistemas web
 Olsina et al. (2001) han desarrollado un árbol de requisitos de
calidad que identifica un conjunto de atributos que conducen a
aplicaciones web de alta calidad
Ing. Aldo Hernan Zanabria Galvez 60
Calidad de las aplicaciones Web
Ing. Aldo Hernan Zanabria Galvez 61
USABILIDAD
Ing. Aldo Hernan Zanabria Galvez 62
Ing. Aldo Hernan Zanabria Galvez 63
¿Qué es la usabilidad?
 Diseñar para la forma de ser de las personas, en contraposición de
diseñar para la tecnología o para la organización
 Facilidad de aprendizaje
 Facilidad de uso
 Reducir el número de errores de usuario Mejorar el placer de usar el
sistema
 Potenciar el uso del sistema frente a la complejidad artística
 Tendencia KISS (Keep It Simple, Stupid!)
 El sitio debe ser claro y limpio
 En Internet sobreviven lo más sencillo
 Técnicamente el sitio debe ser compatible con los diversos navegadores
Ing. Aldo Hernan Zanabria Galvez 64
¿Qué es la usabilidad?
 ¿Por qué las personas tienen que adaptarse a la tecnología?
 ¿Por qué no hacer que la tecnología se adapte a las personas?
(Jacob Nielsen)
 Los usuarios pasan horas navegando por un sito web en búsqueda de
una información
 La navegación web es mucho más difícil de lo que se puede pensar
 El personal de la organización no es siempre la audiencia a la que
se destina la aplicación web
 Se debe crear la aplicación web para quién la usa
 Prestar atención a la usabilidad puede incrementar el porcentaje de
visitantes
 Importante en los comercios electrónicos
Ing. Aldo Hernan Zanabria Galvez 65
Comportamiento de los usuarios en la Web
 Baja tolerancia para diseños difíciles o sitios lentos
 A los usuarios no les gusta esperar
 A los usuarios no les gusta aprender cómo utilizar un sitio
 Web
 No existen clases de entrenamiento ni manuales para un sitio web
 A los usuarios desean capturar la funcionalidad del sitio web de
forma inmediata tras echar un vistazo a la página principal durante
unos segundos
 Puede haber casos donde puede ser útil gastar un poco de tiempo en
aprender a manejar el sitio web
Ing. Aldo Hernan Zanabria Galvez 66
Diseño centrado en el usuario
 Ofrecer una arquitectura de navegación centrada en el usuario es
importante
 Diversos departamentos de una misma organización deberían colaborar
en el desarrollo de la arquitectura de la aplicación Web
 Los usuarios no desean conocer cómo se organiza la entidad que
soporta la Web que visita
 Los usuarios quieren llegar a la información que buscan en el menor
tiempo posible
Ing. Aldo Hernan Zanabria Galvez 67
Usabilidad universal
 Internacionalización
 Accesibilidad para usuarios con discapacidades
 Discapacidades visuales
 Discapacidades cognitivas
 Discapacidades auditivas
 Discapacidades motoras
Ing. Aldo Hernan Zanabria Galvez 68
Usabilidad de la homepage
 Las homepages son un activo real para las organizaciones
 Cada año las organizaciones se gastan millones de euros en ellas
 La homepage es la carta de presentación de las organización al mundo
 La homepage es la página más importante en la mayoría de los sitios
 Web Claves
 El propósito de la organización debe explicitarse en la homepage
 Hay que explicar quién eres y qué haces (Nielsen, 2002a)
 Hay que ayudar a los usuarios a encontrar lo que necesitan
 Revelar los contenidos del sitio
 Utilizar el diseño visual para mejorar el diseño de la interacción (no para
definirlo)
Ing. Aldo Hernan Zanabria Galvez 69
Criterios de usabilidad en la homepage
 Incluir un párrafo de presentación
 Contar con un título de ventana con buena visibilidad en los motores de
búsqueda y en las listas de favoritos
 Agrupar toda la información corporativa en una localización concreta y
separada
 Enfatizar las tareas prioritarias del sitio Web
 Incluir un buscador
 Mostrar ejemplos reales de los contenidos del sitio
 Comenzar los nombres de los enlaces con las palabras clave más
representativas
 Ofrecer acceso fácil a las nuevas características del sitio
 No sobrecargar de formato los contenidos críticos, tales como las áreas de
navegación
 Utilizar gráficos e ilustraciones significativas (Nielsen, 2002a)
Ing. Aldo Hernan Zanabria Galvez 70
¿Es la Web usable?
 La mayoría de los sitios web son correosos de usar
 El 90% de los sitios web está pobremente diseñado (Murugesan,
2000)
 Cuando los usuarios descubren que el sitio está repleto de gráficos
inútiles y presenta poca información útil, se van a otro sitio y
difícilmente volverán
 Si el sitio hace que el navegador se interrumpa bruscamente, no
volverán
 Si los usuarios no encuentran el producto o la información que buscan,
lo buscarán en otro sitio
Ing. Aldo Hernan Zanabria Galvez 71
Errores más frecuentes contra la usabilidad
 Uso (abuso) de los marcos
 Uso gratuito de la última tecnología
 Uso de texto que se desplaza y animaciones continuas
 URLs complejas
 Páginas huérfanas
 Minimizar el uso del scrolling
 Falta de soporte a la navegación
 No utilizar colores estándares para los enlaces
 Información desfasada
 Tiempos de bajada excesivamente grandes
(Nielsen, 1996)
Ing. Aldo Hernan Zanabria Galvez 72
Errores más frecuentes contra la usabilidad
 Dejar sin efecto el botón atrás
 Abrir nuevas ventanas del navegador
 Utilizar controles no estándares en la interfaz de usuario
 Falta de biografías
 Falta de información histórica
 Mover páginas a nuevas URLs
 Cabeceras que no tienen sentido fuera del contexto
 Incorporar inmediatamente el último término de moda en Internet
 Tiempos bajos de respuesta de los servidores
 Evitar aquello que se asemeje a un anuncio
(Nielsen, 1999)
Ing. Aldo Hernan Zanabria Galvez 73
Errores más frecuentes contra la usabilidad
 Falta de precios en sitios de comercio electrónico
 Motores de búsqueda inflexibles
 Desplazamiento (scrolling) horizontal
 Tamaños de fuentes fijos
 Bloques de textos Uso de Javascript en los enlaces
 Preguntas infrecuentes en los FAQ
 Recoger direcciones de correo electrónico sin una política de
privacidad
 URLs de más de 75 caracteres
 Enlaces mailto en sitios inesperados
(Nielsen, 2002b)
Ing. Aldo Hernan Zanabria Galvez 74
Errores más frecuentes contra la usabilidad
 Malas búsquedas
 Ficheros PDF para su lectura en línea
 No cambiar el color de los enlaces visitados
 Texto no escalable
 Tamaño de fuente fijo
 Títulos de página con poco visibilidad para los buscadores
 Todo cuya apariencia parece un anuncio
 Violaciones de las convenciones de diseño
 Apertura de nuevas ventanas en el navegador
 No responder a las preguntas de los usuarios
(Nielsen, 2004)
Ing. Aldo Hernan Zanabria Galvez 75
Referencias.
 Ginige, A. (2000) Engineering a Better Web Site. Keynote Address,
Asia Pacific
 Web Conference, APWeb2000, Xian, China, October 2000
 Ginige, A. y Murugesan, S. (2001) Web Engineering-An
Introduction. IEEE Multimedia, 8(1):14-18
 Murugesan, S. (2000) Web Engineering for Successful Software
Development.
 Tutorial Notes, Asia Pacific Web Conference, APWeb2000, Xian,
China, October 2000
Ing. Aldo Hernan Zanabria Galvez 76
MÉTODOS DE DESARROLLO
PARA APLICACIONES WEB
Ing. Aldo Hernán Zanabria Gálvez
Ing. Aldo Hernan Zanabria Galvez 77
Ing. Aldo Hernan Zanabria Galvez 78
Contenidos
 Introducción
 Métodos para el desarrollo de aplicaciones web
 OOWS: Un método de Ingeniería Web
Ing. Aldo Hernan Zanabria Galvez 79
Introducción
 Un enfoque de ingeniería pone un fuerte énfasis en el modelado de productos y
procesos
 Se ha puesto de manifiesto la necesidad de métodos de desarrollo para aplicaciones
web
 Cada vez es mayor la tendencia de las organizaciones a tener soluciones software
funcionales en el contexto de la Web
 La funcionalidad es un hecho clave en la definición de la Ingeniería Web
 Se tiene asumido que un sitio web ya no es un mero recurso estético para presentar información
 Se requiere una funcionalidad correcta, enlazando el problema de desarrollar soluciones web con la
correcta práctica de la Ingeniería del Software
 Se debe hacer un esfuerzo porque las aplicaciones web se aborden desde sus
inicios con una aproximación de ingeniería
 Modelado conceptual de aplicaciones web
 Conlleva tener presentes todas las características propias de una aplicación web en el propio
modelado conceptual
 En consecuencia se requiere un proceso preciso para la construcción de software
funcional en la Web
Ing. Aldo Hernan Zanabria Galvez 80
Consideraciones previas
 Las aplicaciones web han sido tradicionalmente desarrolladas ad-
hoc
 Normalmente como evolución de pequeñas aplicaciones que
rápidamente se volvieron inmanejables e inmantenibles
 Muchas de las prácticas utilizadas fallaron al desarrollar
aplicaciones no triviales
 Falta de planificación
 Técnicas, procesos y métodos no apropiados
Ing. Aldo Hernan Zanabria Galvez 81
Diferencias en el desarrollo de aplicaciones
web
 El proceso involucra personas de diversa índole
 Autores, programadores, expertos en multimedia…
 El rol de los usuarios es más amplio y hace que se difícil capturar la
estructura del dominio
 La complejidad aumenta debido a la no linealidad de los
hiperdocumentos y la facilidad de conectar aplicaciones web entre
sí
 Aumenta el riesgo de “perderse en la Web”
 Las aplicaciones web tienen en cuenta aspectos estéticos y
cognitivos que las aproximaciones de Ingeniería del Software
tradicionales no soportan (Nanard y Nanard, 1995)
 El proceso tiende a ser más incremental e iterativo, y el
mantenimiento pasa a ser una parte significativa del ciclo de vida de
las aplicaciones web
Ing. Aldo Hernan Zanabria Galvez 82
Métodos para la Ingeniería Web
 Se han definido diversos métodos para la construcción de
aplicaciones web
 Proponen diferentes pasos y actividades
 Algunos se centran sólo en el diseño o en la representación visual,
mientras que otros cubren todo el proceso de desarrollo de una
aplicación web
 Todos prescriben diferentes técnicas y notaciones Algunos están
soportados por herramientas
Ing. Aldo Hernan Zanabria Galvez 83
MÉTODOS PARA EL
DESARROLLO DE
APLICACIONES WEB
Ing. Aldo Hernan Zanabria Galvez 84
Introducción
Una metodología es una aproximación organizada y sistemática para
el ciclo de vida del sistema o sus partes. Especifica las tareas
individuales y sus secuencias
(Palvia y Nosek, 1993)
Un método para el desarrollo de un sistema es un conjunto de fases
que guían a los desarrolladores en sus elecciones de las técnicas que
pueden ser apropiadas en cada fase del proyecto
(Avison y Fitzgerald, 1995)
Ing. Aldo Hernan Zanabria Galvez 85
Introducción
 Una metodología debe cubrir (Henderson-Sellers y Firesmith, 1999)
 Un proceso de ciclo de vida completo, que comprenda aspectos tantos del
negocio como técnicos
 Un conjunto completo de conceptos y modelos que sean internamente
consistentes
 Una colección de reglas y guías
 Una descripción completa de artefactos a desarrollar
 Una notación con la que trabajar, idealmente soportada por diversas
herramientas CASE y diseñada para una usabilidad óptima
 Un conjunto de técnicas probadas
 Un conjunto de métricas, junto con asesoramiento sobre calidad, estándares y
estrategias de prueba
 Identificación de los roles organizacionales
 Guías para la gestión de proyectos y aseguramiento de la calidad
 Asesoramiento para la gestión de bibliotecas y reutilización
Ing. Aldo Hernan Zanabria Galvez 86
HDM
 HDM (Hypermedia Design Model) (Garzotto et al., 1993)
 Uno de los primeros métodos desarrollados para la definición de la
estructura y la interacción de las aplicaciones hipermediales
 Se basa en la técnica de modelado conceptual Entidad/Relación
 Extiende el concepto de entidad e introduce nuevas primitivas
 Unidades (que se corresponden con el concepto de nodo) Enlaces
 Las entidades HDM tienen una estructura interna y semántica de
navegación asociada
 Especificación de cómo se puede llevar a cabo la navegación y de cómo
se visualiza la información
 Una entidad es una jerarquía de componentes
 Los componentes están formados por unidades
Ing. Aldo Hernan Zanabria Galvez 87
HDM
 HDM (Hypermedia Design Model) (Garzotto et al., 1993)
 Existen tres tipos de enlaces
 Estructurales
 Conectan componentes
 De perspectiva
 Conectan unidades
 De aplicación
 Conectan componentes y entidades
 Existe otro tipo de entidades que dan acceso a las entidades de
aplicación
 Ofrecen puntos de entrada para comenzar la navegación
 Para soportar el diseño de la presentación se definen
 Ranuras (slots) – Una pieza atómica de información. Están compuestos de
marcos
 Marcos (frames) – Una unidad de presentación que se muestra al usuario

Ing. Aldo Hernan Zanabria Galvez 88
RMM
 RMM (Relationship Management Methodology) (Isakowitz et al.,
1995)
 Se ocupa del diseño y construcción de aplicaciones hipermedia
definiendo un proceso formado por siete pasos
 Diseño entidad/relación
 Diseño de vistas de información (slices) Diseño de la navegación
 Diseño de la interfaz de usuario
 Diseño del protocolo de conversión
 Diseño del comportamiento en ejecución
 Construcción y prueba

Ing. Aldo Hernan Zanabria Galvez 89
RMM
Ing. Aldo Hernan Zanabria Galvez 90
EORM
 EORM (Enhanced Object Relationship Methodology) (Lange,1996)
 Presenta un proceso iterativo que se basa en la riqueza del modelo
objeto para representar relaciones entre objetos (enlaces) como objetos
 Utiliza para ello notación OMT (Rumbaugh et al., 1991)
 Este método se basa en tres frameworks
 Clase
 Consiste en definiciones reutilizables de clases
 Composición
 Consiste en definiciones reutilizables de clases de enlaces
 Interfaz gráfica de usuario
Ing. Aldo Hernan Zanabria Galvez 91
OOHDM
 OOHDM (Object-Oriented Hypermedia Design Method) (Schwabe y
Rossi, 1995; Rossi, 1996)
 Conlleva cinco actividades
 Obtención de requisitos
 Modelado conceptual
 Diseño navegacional
 Diseño de la interfaz abstracta
 Implementación
 Las actividades se llevan a cabo mediante un proceso incremental e
iterativo, que hace uso de prototipos
 Los modelos objetos se construyen en cada paso mejorando los de las
iteraciones anteriores
Ing. Aldo Hernan Zanabria Galvez 92
OOHDM
 OOHDM (Object-Oriented Hypermedia Design Method) (Schwabe y
Rossi, 1995; Rossi, 1996)
 El modelado conceptual se lleva a cabo con un diagrama de clases
 Primero utilizando notación OMT (Rumbaugh et al., 1991) y posteriormente
notación UML (OMG, 2004)
 Este método ve a una aplicación web como una vista del modelo conceptual
Las clases que definen las vistas son las clases navegacionales
 Así, el modelo conceptual incluye dos tipos de objetos
 Los que se perciben como nodos en el modelo navegacional
 Los que ofrecen un soporte computacional a la aplicación web
 Encapsulan comportamiento como algoritmos, acceso a bases de datos…
 Este modelo puede servir como base a muchas aplicaciones y no incluye
ninguna información específica de navegación
 Esto es una clara diferencia con EORM (Lange, 1996)
Ing. Aldo Hernan Zanabria Galvez 93
OOHDM
 OOHDM (Object-Oriented Hypermedia Design Method) (Schwabe y
Rossi, 1995; Rossi, 1996)
 El concepto de contexto navegacional se introduce para describir la
estructura de navegación
 Permite diferentes agrupaciones de objetos navegacionales con el propósito
de navegar por ellos en diferentes contextos
 El acceso a estos elementos navegacionales se modela mediante
estructuras de acceso, como índices por ejemplo
 Se utiliza una notación propia para la representación del esquema del
contexto navegacional
 El modelo de interfaz abstracta es el resultado de especificar los objetos
de interfaz que el usuario percibe
 OOHDM utiliza ADVs (Abstract Data Views) para modelar los aspectos
estáticos de la interfaz de usuario, utilizando diagramas de transición de
estados para modelar los aspectos dinámicos
Ing. Aldo Hernan Zanabria Galvez 94
OOHDM
Relación entre los objetos
conceptuales, navegacionales y de
interfaz propios de OOHDM. Las
clases navegacionales son vistas
sobre las clases conceptuales. Los
objetos de interfaz median la
interacción de los objetos
navegacionales con el mundo
exterior, incluyendo a los usuarios
Ing. Aldo Hernan Zanabria Galvez 95
OOHDM
Modelo conceptual de una revista en línea
(Schwabe y Rossi, 1998
Ing. Aldo Hernan Zanabria Galvez 96
OOHDM
 Llamar la atención de que la
clase Person no aparece; los
Atributos del autor son parte
de Story. Lo mismo sucede
con la persona que ofrece una
entrevista
Modelo navegacional de una revista en
línea (Schwabe y Rossi, 1998)
Ing. Aldo Hernan Zanabria Galvez 97
 Un número de la revista está
formado por historias que
están agrupadas de acuerdo a
diferentes criterios
Esquema del contexto navegacional de
una revista en línea (Schwabe y Rossi,
1998)
Indices
Contexto de grupo
Contexto simple
Ing. Aldo Hernan Zanabria Galvez 98
OOWS
 OOWS (Object-Oriented Approach for Web Solutions
 Modeling) (Pastor et al., 2001a)
 Método de desarrollo de aplicaciones web que extiende OO-Method
(Pastor et al., 2001b)
 Se introducen nuevas características navegacionales
 Notación basada en UML (OMG, 2004) Dos grandes fases
 Especificación Conceptual
 Generación Automática
Ing. Aldo Hernan Zanabria Galvez 99
OO-HMethod
 OO-HMethod (Gómez et al., 2000; Cachero et al., 2000)
 Método genérico para el desarrollo de la estructura semántica de las aplicaciones
web
 Se centra en las actividades globales (authoring in the large), esto es, en las clases y
estructuras
 Se despreocupa del contenido de los nodos de información (authoring in the small)
 Extiende OO-Method (Pastor et al., 2001b)
 Extiende la notación para expresar un modelo abstracto de interfaz de usuario
 Se captura la información a que cada tipo de usuario (agente) puede acceder, así como
los caminos de navegación entre vistas de información
 El desarrollo de una aplicación web se aborda tanto a nivel conceptual como a
nivel de ejecución
 El modelo de navegación se captura en el NAD (Navigation Access Diagram)
 La estructura y visualización de la interfaz se expresan en el APD (Abstract
Presentation Diagram)
Ing. Aldo Hernan Zanabria Galvez 100
OO-HMethod
 OO-HMethod (Gómez et al., 2000; Cachero et al., 2000)
 Tanto el NAD como el APD capturan la información relevante gracias a
un conjunto de patrones definidos en el Catálogo de patrones de OO-
HMethod (Cachero et al., 2000)
 La diferencia principal entre OO-HMethod y OOWS es que este último
es un extensión plena de OO-Method
 OOWS incluye completamente la especificación funcional, mientras que
 OO-HMethod sólo especifica la interfaz Otra diferencia aparece en el modelo
de navegación, concretamente en el concepto de nodo
 OO-HMethod asocia diferentes diagramas de acceso a cada tipo de usuario, pero los
nodos (clases de navegación) se limitan a presentar información de una sola clase
 Los nodos en OOWS (contextos navegacionales) pueden trabajar con vistas de
varias clases, mostrando la información apropiada para el usuario en cada momento
Ing. Aldo Hernan Zanabria Galvez 101
SOHDM
 SOHDM (Scenario-based Object-oriented Hypermedia Design
Methodology) (Lee et al., 1998)
 Comprende seis fases
 Análisis de dominio
 Modelado de objetos
 Diseño de vistas
 Diseño de navegación Diseño de la implementación
 Construcción
 Tiene similitudes con RMM (Isakowitz et al., 1995), EORM (Lange,
1996) y con OOHDM (Schwabe y Rossi, 1998)
 Difiere en que usa escenarios
 Los escenarios se definen en el análisis de dominio y se utilizan para el
modelado de objetos
Ing. Aldo Hernan Zanabria Galvez 102
SOHDM
 SOHDM (Scenario-based Object-oriented Hypermedia Design
Methodology) (Lee et al., 1998)
 El diseño de vistas consiste en determinar vistas que vienen generadas de un
única clase o de asociaciones entre clases
 Las vistas son similares a los contextos de OOHDM
 Hay tres clases de vistas
 Vistas base
 Se genera de una única clase
 Vistas de asociación
 Se extrae de una relación de asociación
 Vistas de colaboración
 Proviene de una relación de colaboración
 El diseño de la navegación emplea escenarios para determinar la estructura de los
nodos
 Las estructuras de acceso a los nodos (ASN – Access Structure Nodes), junto
con las vistas, se denominan unidades de navegación
 Las ASNs son similares a las primitivas de acceso de RMM
 Este método define su propia notación gráfica
Ing. Aldo Hernan Zanabria Galvez 103
WSDM
 WSDN (Web Site Design Method) (De Troyer y Leune, 1997)
 Aproximación centrada en el usuario que define objetos de información
basándose en los requisitos de información de los usuarios de una
aplicación web
 Conlleva tres fases principales
 Modelado de usuario
 Diseño conceptual
 Diseño de la implementación
 Modelado de usuario
 Los usuarios de la aplicación web se identifican y se clasifican de acuerdo a
sus intereses y preferencias de navegación
 El punto de comienzo es la descripción del dominio, teniendo en cuenta las
actividades de usuario
 Cada perfil de usuario potencial es descubierto y se plasma en una clase
Ing. Aldo Hernan Zanabria Galvez 104
WSDM
 WSDN (Web Site Design Method) (De Troyer y Leune, 1997)
 Diseño conceptual
 Dos fases
 Modelado de objetos
 El modelado de objetos conlleva tres pasos: modelado de objetos de negocio, modelado de
objetos de usuario y modelado de objetos de perspectivas
 Diseño navegacional
 El modelo navegacional consiste en un número de caminos de navegación, una por cada
perspectiva, expresando cómo los usuarios de un perspectiva particular pueden navegar a
través de la información disponible
 Se describe en término de componentes y enlaces Se distinguen tres tipos de componentes:
navegación, información y externos
 Cada camino de navegación tienes tres capas: contexto, navegación e información
 Este tipo de diseño de navegación provoca aplicaciones con una estructura muy jerárquica
 Diseño de la implementación
 Crea un look&feel eficiente y consistente con el modelo conceptual
 Se dan pocas recomendaciones en este apartado
 Combina una notación propia con OMT (Rumbaugh et al., 1991)
Ing. Aldo Hernan Zanabria Galvez 105
HFPM
 HFPM (Hypermedia Flexible Process Modeling) (Olsina, 1998)
 Abarca las siguientes vistas o perspectivas del proceso de desarrollo de una
aplicación web
 Vista funcional
 Conjunto de fases y actividades para desarrollar tareas (encontrar usuarios, clases, casos de
usos…)
 Vista metodológica
 Define un conjunto de constructores de proceso para aplicarlos a diferentes actividades (análisis
conducido por casos de uso, diseño conceptual y de navegación basado en OOHDM…)
 Vista de información
 Para producir un conjunto de artefactos (modelo de navegación, modelo físico…) que se requieren
en diversas tareas
 Vista de comportamiento
 Representa la parte dinámica del modelo de proceso, tomando decisiones sobre la secuencia y la
sincronización de tareas, iteraciones, incrementos…
 Vista organizacional
 Define aspectos tales como roles, organización de equipos, mecanismos de Comunicación…
Ing. Aldo Hernan Zanabria Galvez 106
HFPM
 HFPM (Hypermedia Flexible Process Modeling) (Olsina, 1998)
 La lista de tareas que prescribe esta metodología para el desarrollo de una aplicación web
son
 Modelado de requisitos del software
 Planificación del proyecto
 Modelado conceptual
 Modelado de la navegación
 Modelado de la interfaz abstracta
 Empleo de patrones de diseño
 Captura y edición de los datos multimedia
 Modelado físico
 Validación y verificación
 Empleo de criterios cognitivos
 Aseguramiento de la calidad
 Gestión y coordinación del proyecto
 Documentación
 Cubre todas las fases y actividades esenciales de un proyecto hipermedia
 La notación se basa en OOHDM
Ing. Aldo Hernan Zanabria Galvez 107
OO/Pattern
 OO/Pattern (Thomson et al., 1998)
 Similar a HFPM (Olsina, 1998)
 Propone utilizar diseño OO y patrones para el diseño de la navegación y
de la presentación
 Difiere de HFPM en que no cubre todo el ciclo de vida de una
aplicación web
 No se incluyen aspectos de gestión de proyectos, prueba y mantenimiento
 La utilización de patrones presenta interesantes ventajas
 Proceso bien definido
 La documentación puede ser reutilizada
 Se facilita el mantenimiento
Ing. Aldo Hernan Zanabria Galvez 108
OO/Pattern
 OO/Pattern (Thomson et al., 1998)
 Presenta los siguientes pasos
 Casos de uso
 Diseño conceptual
 Diseño de colaboraciones
 Definición de clases Diseño de la navegación
 Implementación
 Elementos innovadores
 Análisis de casos de uso para diferentes tipos de usuarios
 Diseño de colaboraciones basándose en los casos de uso definidos y en el
diseño conceptual
 Diseño de la navegación basada en patrones
Ing. Aldo Hernan Zanabria Galvez 109
WAE
 WAE (Web Application Extension for UML) (Conallen, 1999)
 Incluye estereotipos UML para el modelado de elementos
arquitectónicos específicos de la Web
 El proceso propuesto está basado en RUP (Rational Unified Process)
(Kruchten, 2000)
 Proceso centrado en la arquitectura y la implementación (incluye
ingeniería inversa), pero ofrece poco soporte sistemático a la
construcción de la estructura de navegación de la aplicación web, así
como a sus aspectos de presentación
Ing. Aldo Hernan Zanabria Galvez 110
UWE
 UWE (UML-based Web Engineering) (Koch, 2000; Hennicker y
Koch, 2000)
 Soporta desarrollo de aplicaciones web prestando especial atención en
sistematización y personalización (sistemas adaptativos)
 Consiste en una notación y en un método
 La notación se basa en UML (OMG, 2004)
 Para aplicaciones web en general y para aplicaciones adaptativas en particular
 El método consta de seis modelos
 Modelo de casos de uso para capturar los requisitos del sistema
 Modelo conceptual para el contenido (modelo del dominio)
 Modelo de usuario
 Modelo de navegación que incluye modelos estáticos y dinámicos
 Modelo de estructura de presentación, modelo de flujo de presentación, modelo
abstracto de interfaz de usuario y modelo de ciclo de vida del objeto
 Modelo de adaptación
Ing. Aldo Hernan Zanabria Galvez 111
OOWS: UN MÉTODO DE
INGENIERÍA WEB
Ing. Aldo Hernan Zanabria Galvez 112
Objetivos
Ing. Aldo Hernan Zanabria Galvez 113
Objetivos
 Técnicas de Modelado Conceptual proporcionan un enfoque
metodológico y sistemático a la especificación de aplicaciones
tradicionales
 Los métodos de diseño orientados a objetos que utilizan técnicas
de modelado conceptual no proporcionan primitivas para
especificación de la navegación, presentación...
 ¿Cómo elicitar y representar la semántica navegacional en
modelos conceptuales?
 Ampliar la etapa de Modelado Conceptual introduciendo los
 Modelos de Navegación y de Presentación
Ing. Aldo Hernan Zanabria Galvez 114
Objetivo: Un método para la construcción
aplicaciones web
... y la ejecución de servicios
Permita capturar la navegación ...
... tratar la visualización de información ...
... especificar búsquedas
Ing. Aldo Hernan Zanabria Galvez 115
¿Qué es OOWS?
 OOWS (Object-Oriented Approach for Web Solutions Modeling)
(Pastor et al., 2001a)
 Una aproximación para definir semántica de navegación en
modelos Orientados a Objeto
 Ampliación de un Método OO de producción de software
“tradicional”, llamado OO-Method Utiliza la notación UML
(adaptada)
 Extiende el proceso de desarrollo de sistemas software propuesto
por OO-Method (Pastor et al., 2001b)
 Define primitivas navegacionales y de presentación de
información integradas en el Modelado Conceptual OO-Method
Ing. Aldo Hernan Zanabria Galvez 116
OOWS. Proceso de desarrollo
 El método OOWS extiende el proceso de desarrollo definido por
OO-Method
 Incluye nuevas etapas donde se captan los requisitos de
navegación y presentación de información
 Dos grandes fases
1. Especificación Conceptual, se construye una especificación completa
del sistema, Esquema Conceptual
2. Generación Automática, a partir de la especificación se construye una
solución software funcionalmente equivalente basada en patrones de
traducción
Ing. Aldo Hernan Zanabria Galvez 117
OOWS. Proceso de desarrollo
Modelado Conceptual
 La fase de Modelado Conceptual abarca
 1. Especificación de Requisitos
 Usa notación UML (Casos de Uso)
 Recoge
 La funcionalidad que debe proporcionar el sistema
 Los diferentes tipos de usuarios que pueden interactuar con el sistema
 La asociación de usuarios-funcionalidad
 Sirve como base para la construcción del Esquema Conceptual
Ing. Aldo Hernan Zanabria Galvez 118
OOWS. Proceso de desarrollo
Modelado Conceptual
Modelado Conceptual
 Se construyen a partir de la especificación de requisitos los
modelos
Ing. Aldo Hernan Zanabria Galvez 119
OOWS. Proceso de desarrollo
Ing. Aldo Hernan Zanabria Galvez 120
Propuesta Metodológica
Ing. Aldo Hernan Zanabria Galvez 121
Esquema conceptual
Ing. Aldo Hernan Zanabria Galvez 122
Modelo de navegación
 Especificación de las características navegacionales de una aplicación
web
 En base a un Modelo de Objetos y a los requisitos de navegación
 Utiliza una notación basada en UML
 Se construye a partir de las primitivas de abstracción navegacionales
 Representación de la Navegación
 Especificación de Búsquedas
 Tratamiento de la visualización de la información (presentación)
 Ejecución de Servicios
 Personalización de información de los distintos usuarios
 Integrado con las restantes vistas del esquema conceptual
 Define y estructura el acceso de los diferentes usuarios con el sistema,
en función de su objetivo
 Considera el punto de vista de cada perfil de usuario identificado previamente
en el Modelo de Objetos
Ing. Aldo Hernan Zanabria Galvez 123
Modelo de navegación
 Construye un grafo navegacional asociado a cada usuario
formado por
 Nodos
 Unidades de interacción que proporcionan acceso a datos y
funcionalidad relevante para el usuario
 Enlaces
 Relación de alcance entre nodos para conseguir cierto objetivo
Navegación es el cambio de nodo
conceptual al activar un enlace
navegacional
Ing. Aldo Hernan Zanabria Galvez 124
Modelado de navegación
Ing. Aldo Hernan Zanabria Galvez 125
Modelo de Navegación
 Primitivas de Abstracción Básicas
 Mapa Navegacional
 “Visión Global de una aplicación web según un perfil de usuario”
 Contexto de Navegación
 “Conjuntos de objetos que el usuario irá navegar”
 Vínculo de Navegación
 “Indica la navegación entre contextos de navegación”
 Clase Navegacional
 “Contenido de la información por el cual los usuarios navegarán”
 Relaciones
 “Maneras de navegar para acceder al contenido de la información”
Ing. Aldo Hernan Zanabria Galvez 126
Primitivas de abstracción. Mapa de
navegación
 El Modelo de Navegación está compuesto por un conjunto de mapas de
navegación
 Define el sitio web
 Asociado a un agente del Modelo Conceptual
 Visión global del sistema para cada tipo de usuario
 Grafo Navegacional formado por
 Contextos de Navegación (nodos)
 Vínculos Navegacionales (arcos)
Ing. Aldo Hernan Zanabria Galvez 127
Mapa de navegación
Ing. Aldo Hernan Zanabria Galvez 128
Primitivas de abstracción. Contexto
Navegacional
 Unidad de Interacción Abstracta básica con el usuario
 Representa una vista parcial del sistema adecuada para una
determinada actividad
 Es el punto de vista que un usuario tiene de un subconjunto del
modelo de objetos
 Proporciona acceso a datos y funcionalidad asociados con el
usuario propietario del mapa
 Está compuesto por
 Clases navegacionales: Recuperan información del sistema
 Relaciones navegacionales: Complementan la información de las
clases navegacionales
 Gráficamente es un paquete UML estereotipado con la palabra
reservada «context»
Ing. Aldo Hernan Zanabria Galvez 129
Primitivas de abstracción. Contexto
Navegacional
Ing. Aldo Hernan Zanabria Galvez 130
Primitivas de abstracción. Contexto
Navegacional
 Los contextos tienen un carácter navegacional que permite
estructurar la navegación por el sistema
 El carácter de los contextos pueden ser
 Secuencia: Sólo son accesibles siguiendo uno de los caminos de
navegación especificados
 Exploración: Son accesibles desde cualquier ubicación en la aplicación
Ing. Aldo Hernan Zanabria Galvez 131
Primitivas de abstracción. Vínculo
Navegacional
 Define una relación de alcance (navegación) entre
 Contextos de Navegación
 Definido implícitamente a partir de las relaciones navegacionales
definidas dentro de los contextos y por el carácter de los
contextos (de exploración o de secuencia)
Ing. Aldo Hernan Zanabria Galvez 132
Modelo de Navegación. Ejemplo de mapa
navegacional
Contextos de
Navegación
Vínculos de Navegación
Ing. Aldo Hernan Zanabria Galvez 133
Primitivas de abstracción. Clase Navegacional
 Proyecciones de visibilidad sobre clases existentes en el Modelo
de Objetos con respecto a
 Atributos: Datos del sistema visibles que por el usuario
 Servicios: Funcionalidad ejecutable por el usuario
 Gráficamente son clases UML estereotipadas con la palabra
reservada « view »
Ing. Aldo Hernan Zanabria Galvez 134
Primitivas de abstracción. Clase Navegacional
 Existen de dos tipos
 Clase Directora: Es la clase principal de un contexto. Existe una única
por contexto (obligatoria). El contexto se centra en presentar
información y funcionalidad de esta clase
 Clases Complementarias: Su utilidad es complementar la información
de la clase directora. Pueden aparecer varias por contexto (no son
obligatorias)
Ing. Aldo Hernan Zanabria Galvez 135
Primitivas de abstracción. Relación
Navegacional
 Es una relación binaria unidireccional existente entre dos clases
de un contexto
 Se define sobre una relación agregación o herencia entre dos
clases del Modelo de Objetos
 Complementa la información sobre la clase de la cual parte la
relación, recuperando la población relacionada
 Dos tipos
 Relaciones de Dependencia Contextual
 Relaciones de Contexto
Ing. Aldo Hernan Zanabria Galvez 136
Primitivas de abstracción. Relación
Navegacional
 Relación de Dependencia Contextual
 Indica la existencia de una relación entre dos clases de un contexto,
pero no define una semántica navegacional entre ellas
 Complementa la clase navegacional origen con su población
relacionada
 Indica una recuperación de información relacionada de las instancias de la
clase complementaria
 Gráficamente se representa mediante una línea discontinua
Ing. Aldo Hernan Zanabria Galvez 137
Primitivas de abstracción. Relación
Navegacional
 Relación de Contexto
 Complementa la clase navegacional origen con su población
relacionada
 Define un vínculo navegacional entre contextos, indicando la dirección
de navegación
 Implica necesariamente la existencia de un contexto navegacional
 (destino) en el que la clase directora es la clase destino de la relación
 Gráficamente se representa mediante una línea continua
Ing. Aldo Hernan Zanabria Galvez 138
Primitivas de abstracción. Relación
Navegacional
 Las relaciones navegacionales poseen atributos adicionales
 Atributo de contexto: Contexto de navegación destino del enlace
 Atributo de enlace: Atributo que se usará en la conexión con la clase
destino. Es opcional
 Atributo de rol: Nombre de la relación estructural en el Modelo de
Objetos a la que se refiere la relación. Sólo es necesario en caso de
ambigüedad -- Cuando exista más de una relación entre dos clases en
el Modelo de Objetos
Ing. Aldo Hernan Zanabria Galvez 139
Modelo de Navegación. Ejemplo de relación
de contexto
Ing. Aldo Hernan Zanabria Galvez 140
Construcción del Modelo de Navegación
INPUT: Modelo Conceptual + Requisitos Navegación
OUTPUT: Modelo de Navegación
 1. Identificación de los agentes del Sistema y sus
relaciones (herencia) entre sí, en base al Modelo de Objetos
definido
 2. Construcción de los mapas navegacionales para cada agente
detectado, según los requisitos de navegación. Se pueden
reutilizar contextos por relaciones entre agentes
Ing. Aldo Hernan Zanabria Galvez 141
Construcción del Modelo de Navegación
1. Identificación de Agentes
 Buscar en el Modelo de Objetos los agentes del sistema
 Detectar las relaciones entre los agentes (reutilización
navegacional)
 Construir los árboles de agentes, donde aparece cada agente y sus
relaciones con los demás
 Estos árboles están compuestos de
 Agentes/Clases Base
 Agentes/SubClases
Ing. Aldo Hernan Zanabria Galvez 142
Construcción del Modelo de Navegación
2. Construcción de los Mapas
 El Modelo de Navegación está compuesto por los Mapas
Navegacionales definidos
 Se pueden seguir dos estrategias para la construcción del
Modelo de Navegación
 Top-Down: Para cada agente, se da un boceto del mapa navegacional
y siguiendo su estructura se refina cada contexto declarado
 Bottom-Up: Para cada agente, se construyen las piezas básicas
(contextos) y a partir de éstas se obtiene su mapa navegacional
Ing. Aldo Hernan Zanabria Galvez 143
Construcción del Modelo de Navegación
2. Construcción de los Mapas
 Estrategia Top-Down
 Para cada Agente
 Se define un mapa de navegación abstracto
 Se declaran los contextos navegacionales que existirán y las relaciones de alcance
entre ellos
 Se hereda el Mapa de Navegación del agente/Clase Base si el actual es un
agente/SubClase, se modifica y extiende
 Se refina cada contexto en base al mapa de navegación propuesto
 El Mapa de Navegación se construye de manera explícita y se va
refinando a medida que se construyen los contextos
Ing. Aldo Hernan Zanabria Galvez 144
Construcción del Modelo de Navegación
2. Construcción de los Mapas
 Estrategia Bottom-Up
 Para cada Agente
 Construir los contextos de navegación que capturen los requisitos de
navegación detectados (en la especificación de requisitos del sistema)
 Para los Agente/SubClase
 Se hereda el Mapa Navegacional de su clase base y se modifica y extiende
 El Mapa de Navegación para cada agente se construye
automáticamente a partir de los contextos especificados
Ing. Aldo Hernan Zanabria Galvez 145
Construcción del Modelo de Navegación
2. Construcción de los Mapas
Ing. Aldo Hernan Zanabria Galvez 146
Modelo de Presentación
 Tras la especificación del Modelo de Navegación se construye el
Modelo de Presentación
 Este modelo recoge la semántica de presentación de
 información del sistema
 Se basa en definir el modo de presentación asociado a cada UIA
(Unidad de Interacción Abstracta) definida por el Modelo de
Navegación
 Asocia patrones de presentación a los elementos que aparecen
en estos nodos navegacionales
Ing. Aldo Hernan Zanabria Galvez 147
Modelo de Presentación. Patrones de
presentación
 Patrón de Presentación
 Define la estructura lógica de presentación de información a la población a que se aplica
 Se puede aplicar a
 Clase Directora
 Relaciones Navegacionales
 Cuatro tipos, en función de las cardinalidades y el tipo de las relaciones interobjetuales
Ing. Aldo Hernan Zanabria Galvez 148
Modelo de Presentación. Patrones de
presentación
 Patrón de Criterio de Ordenación
 Permite definir una ordenación de la población de una clase
atendiendo a un criterio
 Este criterio deberá estar en función de propiedades (atributos) de
alguna clase del contexto
 Se puede aplicar a
 Clases Navegacionales, indicando cómo se recuperarán las instancias de
estas clases
 Estructuras de Acceso y Mecanismos de Búsqueda, para ordenar los
resultados obtenidos
 Existen de dos tipos: Ascendente y Descendente
 En caso de especificación de varios atributos, la ordenación es
jerárquica
Ing. Aldo Hernan Zanabria Galvez 149
Modelo de Presentación. Patrones de presentación
 Patrón de Paginación
 Define un scrolling de información, creando bloques lógicos en los que las instancias son
“troceadas”
 Se especifica una cardinalidad, o número de instancias a recuperar
 Puede ser estática o dinámica, en función de si el usuario puede o no modificar la
cardinalidad
 Existen dos tipos
 De acceso secuencial, cuando desde un bloque lógico sólo se puede ir al siguiente, al anterior, al
primero o al último
 De acceso aleatorio, cuando desde un bloque lógico se puede acceder directamente a cualquier otro
 Se puede definir como circular, indicando que el siguiente bloque lógico al último es el
primero y viceversa
 Se aplica a
 A la clase directora: Permite restringir el número de instancias de la clase principal que se recuperarán
 A las relaciones navegacionales: Restringiendo el número de instancias de objetos relacionados que
se recuperarán
Ing. Aldo Hernan Zanabria Galvez 150
Modelo de Presentación. Patrones de
presentación
Ing. Aldo Hernan Zanabria Galvez 151
Criterio de Ordenación Ascendente
Paginación aplicada a una relación
navegacional. Se recuperan objetos
secuencialmente en grupos de 5
Caso de estudio OOWS
 Tienda virtual de venta de discos DiscoWeb (Fons et al., 2002)
Ing. Aldo Hernan Zanabria Galvez 152
Caso de estudio OOWS
Ing. Aldo Hernan Zanabria Galvez 153
Caso de estudio OOWS
Ing. Aldo Hernan Zanabria Galvez 154
Caso de estudio OOWS
Ing. Aldo Hernan Zanabria Galvez 155
1. INTRODUCCIÓN
Proceso Software en la Ingeniería Web
156
Ideas generales
 Para una mejor gestión de la construcción de un sistema Web, y
buscando que se haga de una forma sistemática, se necesita contar
con un proceso que conste de varias fases, pasos y actividades
para el desarrollo de aplicaciones Web
 El proceso software separa el desarrollo de una aplicación Web en
partes manejables, ofreciendo técnicas que facilitan la gestión de un
proyecto Web completo
 Algunas de las características de los sistemas Web dificultan su
desarrollo
 Interacción en tiempo real, información personalizada, complejidad, alta
capacidad de cambio
 A lo que hay que añadir la dificultad de estimar el tiempo y el esfuerzo
con un error razonable
157
Ideas generales
 Un proceso ayuda a
 Abordar las dificultades
 Minimizar los riesgos del desarrollo
 Facilitar la evolución y el cambio
 Implantar y explotar las aplicaciones Web
 Proporcionar una realimentación imprescindible para continuar con el
proyecto
158
Pasos clave para el desarrollo de una
aplicación Web
 Comprender la función global del sistema y el contexto de operación, incluyendo los objetivos de
negocio y los requisitos
 Identificar claramente a las personas involucradas, esto es, a sus usuarios principales, a la
organización que necesita el sistema, y aquellos que financian el desarrollo del sistema
 Especificar los requisitos técnicos y no técnicos de los involucrados y del sistema en general
 Desarrollar una arquitectura global del sistema Web que cumpla con los requisitos técnicos y no
técnicos
 Identificar los subproyectos y los subprocesos para implementar la arquitectura. Si los
subproyectos son complejos de gestionar, se deben subdividir a su vez hasta conseguir un
conjunto de tareas manejables
 Desarrollar e implementar los subproyectos
 Incorporar mecanismos efectivos para gestionar la evolución, el cambio y el mantenimiento del
sistema Web. Cuando el sistema evolucione, repetir el proceso global o aquellas partes que se
requieran
 Abordar los problemas no técnicos tales como la revisión de los procesos de negocio, las
políticas de gestión u organización, recursos humanos, y los aspectos legales, culturales y
sociales
 Medir el rendimiento del sistema
 Refinar y actualizar el sistema
159
(Ginige y Murugesan, 2001)
Fases del ciclo de desarrollo en la Ingeniería
Web
 Una aplicación Web, con sus características intrínsecas, tiene un
ciclo de desarrollo, como cualquier otro producto software, en el que
se van a encontrar las fases de ingeniería típicas
 Definición y análisis de los sistemas Web
 Diseño de los sistemas Web
 Diseño arquitectónico
 Diseño de la navegación
 Diseño de la interfaz
 Pruebas de las aplicaciones Web
160
Fases del ciclo de desarrollo en la Ingeniería
Web
 Diseño de la navegación
 Identifica la semántica de la navegación para los diferentes usuarios del
sitio, además de definir la mecánica para lograr la navegación
(Pressman, 2000)
 Una aplicación puede tener un conjunto de roles que representan a los
usuarios del sistema
 Cada rol puede asociarse a diferentes niveles de acceso tanto al contenido
como a los servicios de forma que la semántica de cada rol será diferente
 Se definen Unidades Semánticas de Navegación (USN) para cada
meta asociada a un rol
 Cada USN tiene un conjunto de Formas de Navegación (FdN)
 Una FdN representa la mejor manera de navegación o ruta para que los
usuarios con ciertos perfiles logren su meta
 Cada FdN se compone de Nodos de Navegación (NN) conectados a
través de enlaces de navegación, entre los que puede haber USNs
161
2. Proceso iterativo e incremental para la
Ingeniería Web
162
Proceso iterativo e incremental para la
Ingeniería Web
 R. S. Pressman (2000) propone un proceso para la Ingeniería Web
basado en el modelo en espiral de Boehm (1986)
163
Planificación
Análisis
Ingeniería
Generación de
páginas y
pruebas
Evaluación
del cliente
Formulación
Diseño del
contenido
Diseño
arquitectónico
Producción
Diseño de
la navegación
Diseño de la
interfaz
Proceso iterativo e incremental para la
Ingeniería Web
 Formulación: identificación de metas y objetivos
 Planificación: estimación de costes, evaluación de riesgos y
planificación temporal del proyecto
 Análisis: establecimiento de requisitos
 Ingeniería: dos grupos de tareas paralelas,
 Técnicas (diseño arquitectónico, de navegación y de interfaz)
 No técnicas (diseño del contenido y producción)
 Generación de páginas y pruebas
 El contenido se fusiona con los diseños arquitectónico, de navegación y
de interfaz para elaborar páginas web ejecutables en HTML, JSP...
 Integración con el software intermedio (middleware) de componentes
 Evaluación con el cliente: revisión de cada incremento y solicitud
de cambios
164
3. Proceso Unificado
165
Orígenes del Proceso Unificado
166
Enfoque
de Rational
Otras fuentes
Proceso Unificado de Rational 5.0
1998
Proceso Objectory de Rational 4.1
1996-1997
Proceso Objectory 1.0-3.8
1987-1995
Enfoque de Ericsson
UML
Enfoque
de Rational
Otras fuentes
Proceso Unificado de Rational 5.0
1998
Proceso Objectory de Rational 4.1
1996-1997
Proceso Objectory 1.0-3.8
1987-1995
Enfoque de Ericsson
UML
Jacobson et al.
Jacobson, Booch y Rumbaugh
Introducción
 Características generales
 Está basado en componentes
 Utiliza UML
 Características principales
 Es un proceso conducido por casos de uso
 Está centrado en la arquitectura
 Es iterativo e incremental
167
El Proceso Unificado es más que un simple proceso
(Jacobson et al., 1999), es un marco de trabajo genérico
que puede especializarse para una gran variedad de
sistemas software, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes niveles de
aptitud y diferentes tamaños de proyectos
Introducción
 Un proceso de desarrollo de software: conjunto de actividades
necesarias para transformar los requisitos de usuario en un sistema
de software
 Un marco de trabajo genérico que puede extenderse y
especializarse para una gran variedad de sistemas de software
 Está basado en componentes
 Permite gran variedad de estrategias de ciclo de vida
168
Introducción
 Selecciona qué artefactos producir
 Define actividades y trabajadores
 Modela conceptos
169
Describe un
caso de uso
Paquete de casos de uso
Caso de uso
Responsable de
Analista
Artefacto
Actividad
UML en el Proceso Unificado
170
Proceso de desarrollo que incluye las actividades
del ciclo de vida que producen modelos UML
UML en el Proceso Unificado
171
¿Por qué UML no es suficiente?
 UML es sólo un lenguaje y, por tanto, no es ni una metodología
ni un método, sino que está pensado para ser parte de un
método de desarrollo de software, siendo independiente del
proceso
Características principales
 Conducido por casos de uso
 Centrado en la arquitectura
 Iterativo e Incremental
172
Los casos de uso especifican la función, la arquitectura especifica la forma
La arquitectura y los casos de uso deben estar equilibrados
Casos de uso Arquitectura
Características principales
 Conducido por casos de uso: Los casos de usos guían el
desarrollo del sistema. Como los casos de uso contienen las
descripciones de las funciones, afectan a todas las fases y vistas
 Centrado en la arquitectura: La arquitectura se representa
mediante vistas del modelo. Se puede tomar como arquitectura de
referencia el denominado modelo de arquitectura de 4+1 vistas
propuesto por Philippe Kruchten
 Iterativo e Incremental: En cada iteración se identifican y
especifican los casos de uso relevantes, se crea un diseño basado
en la arquitectura seleccionada, se implementa el diseño mediante
componentes y se verifica que los componentes satisfacen los
casos de uso. Si una iteración cumple con sus objetivos se pasa a
la siguiente. Encada iteración se va desarrollando el sistema de
forma incremental
173
La vida del Proceso Unificado
 El Proceso Unificado se repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema
 Cada ciclo concluye con una versión del producto
 Cada ciclo consta de cuatro fases
 Inicio: se define el alcance del proyecto y se desarrollan los casos de
negocio
 Elaboración: se planifica el proyecto, se especifican en detalle la
mayoría de los casos de uso y se diseña la arquitectura del sistema
 Construcción: se construye el producto
 Transición: el producto se convierte en versión beta. Se corrigen
problemas y se incorporan mejoras sugeridas en la revisión
174
La vida del Proceso Unificado
175
Etapa de Ingeniería Etapa de Producción
Visión Arquitectura Versiones Beta Productos
Inicio Elaboración Construcción Transición
Iteratividad
La vida del Proceso Unificado
176
tiempotiempo
VistaVista Línea base
de arquitectura
Línea base
de arquitectura
Capacidad
inicial
Capacidad
inicial
Versión del
producto
Versión del
producto
Inicio Elaboración Construcción Transición
VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión
Arqu.
Iteración
... Des.
Iteración
Des.
Iteración
... Trans.
Iteración
...Prelim
Iteración
...
Inicio Elaboración Construcción Transición
Arqu.
Iteración
... Des.
Iteración
Des.
Iteración
... Trans.
Iteración
...Prelim
Iteración
...
Inicio Elaboración Construcción Transición
La vida del Proceso Unificado
Inicio Elaboración Construcción Transición
Etapa de Ingeniería Etapa de producción
Requisitos
Diseño
Implementación
Instalación
Gestión
Requisitos
Diseño
Implementación
Instalación
Gestión
Requisitos
Diseño
Implementación
Instalación
Gestión
Requisitos
Diseño
Implementación
Instalación
Gestión
Visión Arquitectura Versiones Beta ProductosVisión Arquitectura Versiones Beta Productos
177
Incremental
La vida del Proceso Unificado
 Iteraciones y flujo de trabajo
 Dentro de cada fase se puede, a su vez,
descomponer el trabajo en iteraciones con sus
incrementos resultantes
 Cada fase termina con un hito, cada uno de los
cuales se caracteriza por la disponibilidad de un
conjunto de componentes de software
 Objetivos de los hitos
 Toma de decisiones para continuar con la siguiente fase
 Controlar el progreso del proyecto
 Proporcionar información para la estimación de tiempo y
recursos de proyectos sucesivos
 Las iteraciones discurren a lo largo de los flujos de
trabajo
178
Ciclo de vida del Proceso Unificado
179
iter.
#1
iter.
#2
iter.
#n
iter.
#n+1
iter.
#n+2
iter.
#m
iter.
#m+1
Fases
Requisitos
Diseño
Implementación
Pruebas
Análisis
Flujos de trabajo
Iteraciones
Iteraciones
preliminares
Inicio Elaboración Construcción Transición
El producto
 El producto que se obtiene es un sistema de software
 El sistema lo componen todos los “artefactos” necesarios para
representarlo de forma comprensible
 Artefactos: Término general para cualquier tipo de información
creada, producida, cambiada o utilizada por los trabajadores en el
desarrollo del sistema. Pueden ser
 De ingeniería
 De gestión
 El artefacto más importante del Proceso Unificado es el modelo
 Un sistema posee una colección de modelos y las relaciones entre
ellos
180
El producto
 Los modelos recogen diferentes perspectivas del sistema
(perspectivas de todos los trabajadores)
181
Un modelo es una abstracción semánticamente cerrada del
sistema
Sistema
Arquitecto
Usuarios
Analistas
Jefe de
proyecto
Ingenieros
de pruebas
Diseñadores
El producto
 Existen dependencias entre el modelo de casos de uso y los demás
modelos
182
Modelo de
casos de uso
Modelo de
diseño
Modelo de
despliegue
Modelo de
pruebas
Modelo de
implementation
Modelo de
Análisis
Especificado por
Realizado por
Distribuido por
Implementado por
Verificado por
El producto
 Modelos
 Modelo de casos de uso: diagramas de casos de uso, secuencia,
colaboración y actividad
 Modelos de análisis y diseño: diagramas de clases, objetos,
secuencia, colaboración y actividad
 Modelo de despliegue: diagramas despliegue, secuencia y
colaboración
 Modelo de implementación: diagramas de componentes, secuencia y
colaboración
 Modelo de pruebas: todos los diagramas
183
El proceso
 El proceso hace referencia a un contexto que sirve como plantilla
que pueda reutilizarse para crear instancias de ella (proyectos)
 Las actividades relacionadas conforman flujos de trabajo
 Su identificación parte de la identificación de los trabajadores y de los
artefactos para cada tipo de trabajador
 Describen como fluye el proceso a través de los trabajadores
184
El proceso de desarrollo de software es una definición de un
conjunto completo de actividades necesarias para convertir los
requisitos de usuario en un conjunto consistente de artefactos que
conforman un producto software, y para convertir los cambios
sobre esos requisitos en un nuevo conjunto consistente de
artefactos
El proceso
 Representación de flujos de trabajo mediante calles
185
Analista de
sistemas
Identificar actores y
casos de uso
Estructurar el modelo
de casos de uso
Arquitecto Priorizar casos de uso
Especificador
de casos de uso
Detallar casos de uso
Diseñador de
interfaz de usuario
Esbozar interfaz de usuario
Flujo de trabajo del modelado de casos de uso
Actividades
Calles
El proceso
 Un flujo de trabajo es un estereotipo de colaboración en el que los
artefactos y los trabajadores son los participantes
 Ejemplo
 Flujo de trabajo de requisitos
 Trabajadores: analista de sistemas, arquitecto...
 Artefactos: modelo de casos de uso, casos de uso...
 La notación “en forma de pez” es la abreviatura de un flujo de
trabajo
186
Requisitos
Una colaboración de
trabajadores y artefactos
utilizada para describir el flujo
de Requisitos del proceso
El proceso
Procesos especializados
 El Proceso unificado se puede especializar para cumplir diferentes
necesidades de aplicación o de organización
 Los factores que influyen en la forma de especialización
 Organizativos: estructura y cultura de la empresa, organización del
proyecto, aptitudes y habilidades disponibles, experiencia...
 Del dominio: procesos de negocio que se deben soportar, comunidad
de usuarios, ofertas de la competencia
 Del ciclo de vida: tiempo de salida al mercado, tiempo de vida
esperado, tecnología y experiencia en el desarrollo, versiones...
 Factores técnicos: lenguaje de programación, herramientas de
desarrollo, base de datos, comunicaciones, distribución...
187
Proceso dirigido por casos de uso
 Dirigen las actividades de desarrollo
 Creación y validación de la arquitectura del sistema
 Definición de casos de prueba y procedimientos
 Planificación de iteraciones
 Creación de documentación de usuario
 Despliegue del sistema
 Sincronizan el contenido de los diferentes modelos
188
Requisitos Implemen-
tación
Prueba
Los casos de uso enlazan los flujos de trabajo
Análisis Diseño
Proceso dirigido por casos de uso
 Inicialmente los casos de uso se utilizan para la captura de
requisitos funcionales
 Durante el análisis y el diseño, transformamos el modelo de casos
de uso mediante un modelo de análisis en una estructura de
clasificadores y realizaciones de casos de uso
 En cada iteración, los casos de uso sirven de guía a través del
conjunto completo de flujos de trabajo
189
Modelo de casos
de uso
Modelo de
análisis
Modelo de diseño
<<trace>> <<trace>>
Proceso dirigido por casos de uso
190
Requisitos
Diseño
Implementación
Prueba
Análisis
Modelo de
casos de uso
Modelo de
análisis
Modelo de
diseño
Modelo de
despliegue
Modelo de
implementación
Modelo de
puebas
Requisitos
Diseño
Implementación
Prueba
Análisis
Modelo de
casos de uso
Modelo de
análisis
Modelo de
diseño
Modelo de
despliegue
Modelo de
implementación
Modelo de
puebas
El Proceso Unificado está centrado en la
arquitectura
 Se puede tomar como arquitectura de referencia el denominado
modelo de arquitectura de 4+1 vistas, propuesto por Philippe
Kruchten (1995)
 Los modelos son instrumentos para visualizar, especificar, construir y
documentar la arquitectura del sistema
191
Vista lógica Vista de implementación
Vista de procesos
ComponentesComponentes
Clases, interfaces,
colaboraciones
Clases, interfaces,
colaboraciones
Clases activasClases activas
Vista de despliegue
NodosNodos
Vista de Casos
de uso
Vista de Casos
de uso
Casos de usoCasos de uso
Proceso centrado en la arquitectura
 Los modelos son los vehículos para visualizar, especificar,
construir y documentar la arquitectura
 El Proceso Unificado prescribe los sucesivos refinamientos de una
arquitectura ejecutable
192
tiempo
Arquitectura
Inicio Elaboración Construcción Transición
Proceso centrado en la arquitectura
 La arquitectura representa una colección de vistas de los modelos
193
Casos
de uso
Diseño Despl. Implem. PruebaAnálisis
Proceso centrado en la arquitectura
 Diseño de la arquitectura
 Seleccionar escenarios: aspectos críticos y riesgos
 Identificar las clases principales y sus responsabilidades
 Distribuir el comportamiento en clases
 Estructurar en subsistemas, capas y definir interfaces
 Definir distribución y concurrencia
 Implementar prototipos de arquitectura
 Derivar casos de prueba a partir de los casos de uso
 Evaluar la arquitectura
Iterar
 La arquitectura se desarrolla mediante iteraciones
 Comienza con una línea base de arquitectura (primera versión de los
modelos
 La línea base evoluciona hasta convertirse en un sistema estable
194
Proceso centrado en la arquitectura
195
Estructura estática de la arquitectura en el modelo de diseño
<<subsystem>>
Interfaz del CA
Entrega
<<subsystem>>
Gestión de
transacciones Transferencias
<<subsystem>>
Gestión de
cuentas
Retirada efectivo
Cliente
HistoriaDepósito
Vista arquitectónica del modelo de despliegue
Proceso centrado en la arquitectura
 Estructuración de la arquitectura en capas
196
Capa específica de la aplicación
Capa general de la aplicación
Capa intermedia
Capa de software del sistema
Patrón de capas de la arquitectura del sistema
Proceso centrado en la arquitectura
197
Capa específica de la aplicación
Capa general de la aplicación
Capa intermedia
Capa de software del sistema
Gestión de
facturas de
comprador
Gestión de
planificación de
pagos
Gestión de
cuentas
Java.applet Java.awt Java.rmi
Máquina virtual
Java
Navegador de
Internet
TCP/IP
Flujos de trabajo. Captura de requisitos
 Incluye los siguientes pasos
 Enumerar requisitos candidatos: lista de características del sistema
que llevan asociado un nombre, una descripción y aspectos de
planificación (estado, coste estimado, prioridad y riesgo)
 Comprender el contexto del sistema
 Modelado del dominio (conceptos)
 Modelado del negocio (procesos)
 Capturar requisitos funcionales: a partir de los casos de uso que
reflejan las necesidades de los usuarios
 Capturar requisitos no funcionales: identificar restricciones del
entorno o de la implementación, rendimiento, dependencias de la
plataforma, fiabilidad...
198
Flujos de trabajo. Captura de requisitos
 Captura de requisitos en forma de casos de uso
199
Analista de
sistemas
Identificar actores y
casos de uso
Estructurar el modelo
de casos de uso
Arquitecto Priorizar casos de uso
Especificador
de casos de uso
Detallar casos de uso
Diseñador de
interfaz de usuario
Esbozar interfaz de usuario
Flujos de trabajo. Captura de requisitos
200
 Identificar actores y casos de uso
Flujos de trabajo. Captura de requisitos
 Descripción de casos de uso
 Estado inicial
 Caminos de ejecución
 Básico
 Alternativos
 Formalización de la descripción de casos de uso mediante técnicas
de modelado visual
 Diagramas de estado de UML: para describir los estados y las
transiciones de estado de los casos de uso
 Diagramas de actividad: para describir las transiciones entre estados
como secuencia de acciones
 Diagramas de interacción: para ver como interactúan una instancia de
un caso de uso con una instancia de un actor
201
Flujos de trabajo. Captura de requisitos
202
Diagrama de colaboración (interacción) para el caso de uso “Sacar Dinero”
Flujos de trabajo. Captura de requisitos
 Estructurar el modelo de casos de uso
 Después de la descripción detallada de casos de uso, se pueden
reestructurar para que el sistema sea más fácil de entender y de trabajar
con él
 Se deben buscar comportamientos compartidos y extensiones
 Extraer descripciones de funcionalidad generales y compartidas que pueden
ser utilizadas por descripciones más específicas.
 Extraer descripciones de funcionalidad adicionales u opcionales que pueden
extender descripciones más específicas
203
Flujos de trabajo. Captura de requisitos
204
Estructuración de casos de uso con relaciones de generalización y extensión
Flujos de trabajo. Análisis
 El resultado es el modelo de análisis, que incluye
 Paquetes del análisis y de servicio, y sus dependencias y contenidos
 Clases del análisis, sus responsabilidades, atributos, relaciones y
requisitos especiales. Las clases son de tres tipos
 De interfaz: modelan la interacción del sistema con sus actores
 De entidad: modelan información persistente
 De control: representan aspectos dinámicos y de coordinación
 Realizaciones de casos de uso-análisis
 Vista de arquitectura del modelo de análisis
205
Clase de interfaz Clase de entidad Clase de control
Flujos de trabajo. Análisis
 Los paquetes de análisis se utilizan para organizar los artefactos del
modelo de análisis en piezas manejables. Pueden contener clases de
análisis, de realización de casos de uso y otros paquetes (recursivamente)
206
Dependencias entre paquetes del análisis
Gestión de
cuentas
Gestión de
facturas comprador
Gestión de
facturas vendedor Capa específica
de la aplicación
Capa general
de la
aplicación
Identificación de paquetes del análisis
Cuenta
Gestión de
cuentas
<<trace>>
Modelo del
dominio
Paquete del
análisis
Flujos de trabajo. Análisis
 Los paquetes de servicio se utilizan en un nivel más bajo de la jerarquía de
agregación que los paquetes de análisis. Estructuran el sistema de acuerdo
a los servicios que proporciona. Contienen clases relacionadas
funcionalmente
207
Paquetes de servicio incluidos en un paquete de análisis
Gestión de
cuentas
<<service package>>
Cuentas
Transferencia
s
Historia de cuenta
cuenta
<<service package>>
Riesgos
Estimación
de Riesgo
Riesgo
Flujos de trabajo. Análisis
 El modelo de análisis crece incrementalmente
 En cada iteración se seleccionan un conjunto de casos de uso
 A partir de la descripción de los casos de uso se seleccionan los
clasificadores y relaciones necesarios para la implementación
208
Modelo de casos
de uso
Modelo de
análisis
<<trace>>
Sacar dinero Sacar dinero
salida Interfaz
cajero
Retirada
efectivo
cuenta
Flujos de trabajo. Análisis
209
Diagrama de clases del análisis (derecha) utilizadas para realizar los casos de uso (izquierda)
Flujos de trabajo. Diseño
 El resultado es el modelo de diseño, que incluye
 Subsistemas de diseño y de servicio y sus dependencias, interfaces y
contenidos
 Clases del diseño con sus operaciones, atributos y requisitos de
implementación. Se decide qué clases son activas (hilos o procesos) y
como deben comunicarse y sincronizarse
 Realizaciones de casos de uso-diseño en términos de colaboraciones
 Vista arquitectónica del modelo de diseño
 También se obtiene el modelo de despliegue que describe todas
las configuraciones de red sobre las cuales debería implantarse el
sistema
210
Flujos de trabajo. Diseño
211
Relaciones de trazabilidad entre las clases del modelo de análisis y las del modelo de diseño
Flujos de trabajo. Diseño
212
Subsistemas del modelo de diseño
Flujos de trabajo. Diseño
213
Clases de diseño utilizadas en la realización del caso de uso “Sacar
Dinero”
Flujos de trabajo. Diseño
214
Modelo de despliegue del sistema
Flujos de trabajo. Implementación
 El resultado es el modelo de implementación, que incluye
 Subsistemas de implementación y sus dependencias, interfaces y
contenidos
 Componentes (fichero y ejecutables) y las dependencias entre ellos. Los
componentes se someten a las pruebas de unidad
 Vista arquitectónica del modelo de implementación, incluyendo sus
elementos arquitectónicamente significativos
 También produce como resultado un refinamiento de la vista de
despliegue donde los componentes ejecutables son asignados a
nodos
215
Flujos de trabajo. Implementación
216
Flujos de trabajo. Prueba
 El resultado es el modelo de prueba, que incluye
 Casos de prueba
 De integración
 Del sistema
 De regresión
 Procedimientos de prueba
 Deben especificar como probar clases para cada subsistema
 Cada caso de prueba requerirá varios procedimientos
 Debe favorecerse la reutilización de los procedimientos
 Componentes de prueba, que automatizan los casos de prueba
 La prueba también da como resultado un plan de prueba,
evaluaciones de las pruebas realizadas y defectos que se pasan
como entrada a los flujos de trabajo anteriores
217
Proceso Unificado y aplicaciones Web
 La clave para utilizar el Proceso Unificado en el desarrollo de
aplicaciones Web la dan los casos de uso (Ward y Kroll, 1999)
 Integran el marco de ingeniería, que ofrece el Proceso Unificado, con el
proceso de diseño creativo que caracteriza a las aplicaciones Web
 Ofrecen una forma de expresar en términos comunes un entendimiento
compartido del comportamiento esperado de la aplicación Web
 Juegan el papel de lengua franca en los proyectos software, es decir,
son el lenguaje hablado por todos los implicados en la definición y el
desarrollo del sistema Web
218
Proceso Unificado y aplicaciones Web
 Integración del proceso de diseño creativo en el proceso unificado
219
Proceso Unificado y aplicaciones Web
 Requisitos
 Visión
 Acuerdo sobre los problemas que deben resolverse
 Definición de los límites del sistema
 Descripción de las características más importantes del
sistema
 Modelo de casos de uso: documentación de los
requisitos que permite a los usuarios articular sus
necesidades (servicios del sistema)
 Los actores representan a los usuarios
 Los casos de uso representan los servicios
 Especificación suplementaria: contiene los requisitos
no funcionales. Conviene desarrollar un glosario con
la terminología común del proyecto
220
Proceso Unificado y aplicaciones Web
 Diseño creativo: guías iniciales de la interfaz de usuario
 El “humor del sitio”
 Cómo accederán los usuarios al sitio, qué navegadores usarán
 Si el sitio tendrá marcos
 Limitaciones de color del sitio
 Aspectos relativos a gráficos, animaciones...
 Mapa de navegación: representación jerárquica de la navegación
de los usuarios en el sitio (site map)
 El número de niveles representa el número de clicks necesarios para
llegar a una página
 Toma como referencia el modelo de casos de uso
 Se identifican “páginas lógicas” candidatas para la interfaz de usuario.
Se representan en el análisis con el constructor UML boundary class
221
Proceso Unificado y aplicaciones Web
222
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria
Presentacion curso ingenieria web   ing. aldo zanabria

Weitere ähnliche Inhalte

Was ist angesagt?

Introducción a la ingeniería web
Introducción a la ingeniería webIntroducción a la ingeniería web
Introducción a la ingeniería webCarlos Van de Velde
 
Metodologia web
Metodologia webMetodologia web
Metodologia webAnel Sosa
 
Metodologías de ingeniería Web dirigida por modelos
Metodologías de ingeniería Web dirigida por modelosMetodologías de ingeniería Web dirigida por modelos
Metodologías de ingeniería Web dirigida por modelosJose R. Hilera
 
Exp. Ingenieria Web
Exp. Ingenieria WebExp. Ingenieria Web
Exp. Ingenieria WebDiego Celi
 
Fase 1 formulacion y planeación i web
Fase 1 formulacion y planeación i webFase 1 formulacion y planeación i web
Fase 1 formulacion y planeación i webROSA IMELDA GARCIA CHI
 
Desarrollo web final
Desarrollo web finalDesarrollo web final
Desarrollo web finalproo
 
Metodología para creación de sitios web
Metodología para creación de sitios webMetodología para creación de sitios web
Metodología para creación de sitios webAlfredo Anotha Diego
 
Evaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones Web
Evaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones WebEvaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones Web
Evaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones WebSoftware Guru
 
Pressman capitulo 15
Pressman capitulo 15Pressman capitulo 15
Pressman capitulo 15supito01
 

Was ist angesagt? (17)

Ingeniería Web
Ingeniería WebIngeniería Web
Ingeniería Web
 
Introducción a la ingeniería web
Introducción a la ingeniería webIntroducción a la ingeniería web
Introducción a la ingeniería web
 
Metodología IWeb
Metodología IWebMetodología IWeb
Metodología IWeb
 
Metodologia web
Metodologia webMetodologia web
Metodologia web
 
Metodologías de ingeniería Web dirigida por modelos
Metodologías de ingeniería Web dirigida por modelosMetodologías de ingeniería Web dirigida por modelos
Metodologías de ingeniería Web dirigida por modelos
 
Modelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones webModelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones web
 
Exp. Ingenieria Web
Exp. Ingenieria WebExp. Ingenieria Web
Exp. Ingenieria Web
 
Ingeniería web
Ingeniería webIngeniería web
Ingeniería web
 
Sesion 1
Sesion 1Sesion 1
Sesion 1
 
Fase 1 formulacion y planeación i web
Fase 1 formulacion y planeación i webFase 1 formulacion y planeación i web
Fase 1 formulacion y planeación i web
 
Desarrollo web final
Desarrollo web finalDesarrollo web final
Desarrollo web final
 
Modelado web
Modelado webModelado web
Modelado web
 
Metodologias para el desarrollo de aplicaciones web
Metodologias para el desarrollo de aplicaciones webMetodologias para el desarrollo de aplicaciones web
Metodologias para el desarrollo de aplicaciones web
 
Ingeniería web
Ingeniería webIngeniería web
Ingeniería web
 
Metodología para creación de sitios web
Metodología para creación de sitios webMetodología para creación de sitios web
Metodología para creación de sitios web
 
Evaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones Web
Evaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones WebEvaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones Web
Evaluación de Propuestas Metodológicas para el Desarrollo de Aplicaciones Web
 
Pressman capitulo 15
Pressman capitulo 15Pressman capitulo 15
Pressman capitulo 15
 

Andere mochten auch (20)

Ingenieria web
Ingenieria webIngenieria web
Ingenieria web
 
Qué es la ingeniería web
Qué es la ingeniería webQué es la ingeniería web
Qué es la ingeniería web
 
Ingenieria web
Ingenieria webIngenieria web
Ingenieria web
 
marketing digital
marketing digitalmarketing digital
marketing digital
 
Ingeniería Web
Ingeniería WebIngeniería Web
Ingeniería Web
 
Analisis e Ingenieria de Procesos
Analisis e Ingenieria de ProcesosAnalisis e Ingenieria de Procesos
Analisis e Ingenieria de Procesos
 
0102 introducción-e_ingeniería_web
0102  introducción-e_ingeniería_web0102  introducción-e_ingeniería_web
0102 introducción-e_ingeniería_web
 
Las aportaciones de mi ejercicio como profesor para el desarrollo de la calid...
Las aportaciones de mi ejercicio como profesor para el desarrollo de la calid...Las aportaciones de mi ejercicio como profesor para el desarrollo de la calid...
Las aportaciones de mi ejercicio como profesor para el desarrollo de la calid...
 
Exposicion de marketing UNA Puno
Exposicion de marketing UNA PunoExposicion de marketing UNA Puno
Exposicion de marketing UNA Puno
 
Conferencia magistral Pablo Latapí Sarre
Conferencia magistral Pablo Latapí SarreConferencia magistral Pablo Latapí Sarre
Conferencia magistral Pablo Latapí Sarre
 
Oracle
OracleOracle
Oracle
 
Poss0502 slides
Poss0502 slidesPoss0502 slides
Poss0502 slides
 
prenatal unapuno
prenatal unapunoprenatal unapuno
prenatal unapuno
 
Poo4
Poo4Poo4
Poo4
 
Lto tema1
Lto tema1Lto tema1
Lto tema1
 
Tema2 programacion i_ib
Tema2 programacion i_ibTema2 programacion i_ib
Tema2 programacion i_ib
 
Lp13
Lp13Lp13
Lp13
 
Transp objetos
Transp objetosTransp objetos
Transp objetos
 
Met2 07 01-introduccion_poo
Met2 07 01-introduccion_pooMet2 07 01-introduccion_poo
Met2 07 01-introduccion_poo
 
Diablada Bellavista Revista Pdf
Diablada Bellavista Revista PdfDiablada Bellavista Revista Pdf
Diablada Bellavista Revista Pdf
 

Ähnlich wie Presentacion curso ingenieria web ing. aldo zanabria

Modulo taller progwebaa2
Modulo   taller progwebaa2Modulo   taller progwebaa2
Modulo taller progwebaa2Pabel Lopez
 
Promocionando mi Carrera Por Elvin Gabriel de Jesús
Promocionando mi Carrera Por Elvin Gabriel de JesúsPromocionando mi Carrera Por Elvin Gabriel de Jesús
Promocionando mi Carrera Por Elvin Gabriel de JesúsElvin Gabriel de Jesús
 
Presentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en InternetPresentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en InternetFacultad de Ciencias y Sistemas
 
Qué es la ingeniería web
Qué es la ingeniería webQué es la ingeniería web
Qué es la ingeniería webVictor Barraza
 
Qué es la ingeniería web
Qué es la ingeniería webQué es la ingeniería web
Qué es la ingeniería webVictor Barraza
 
Aplicaciones de diseño de internet
Aplicaciones de diseño de internetAplicaciones de diseño de internet
Aplicaciones de diseño de internetarianys2308
 
La ingeniería del software en España: retos y oportunidades
La ingeniería del software en España: retos y oportunidadesLa ingeniería del software en España: retos y oportunidades
La ingeniería del software en España: retos y oportunidadesAntonio Vallecillo
 
Presentación Sesión 1 Ingeniería del Software.pptx
Presentación Sesión 1 Ingeniería del Software.pptxPresentación Sesión 1 Ingeniería del Software.pptx
Presentación Sesión 1 Ingeniería del Software.pptxAderMogollonLuna
 
Tecnologiaweb 101114145311-phpapp02
Tecnologiaweb 101114145311-phpapp02Tecnologiaweb 101114145311-phpapp02
Tecnologiaweb 101114145311-phpapp02zaritarodriguez02
 
Requerimientos, Ventajas y Desventajas de las aplicaciones web
Requerimientos, Ventajas y Desventajas de las aplicaciones webRequerimientos, Ventajas y Desventajas de las aplicaciones web
Requerimientos, Ventajas y Desventajas de las aplicaciones webAlonzer Acid Nox
 
Presentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en InternetPresentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en InternetFacultad de Ciencias y Sistemas
 
SeccióN De TéCnicas De IngenieríA De Software(2007)
SeccióN De TéCnicas  De IngenieríA De Software(2007)SeccióN De TéCnicas  De IngenieríA De Software(2007)
SeccióN De TéCnicas De IngenieríA De Software(2007)denny osael lopez medina
 
Diseño de Páginas Web.pptx
Diseño de Páginas Web.pptxDiseño de Páginas Web.pptx
Diseño de Páginas Web.pptxtomy496136
 
Principios de Diseño de Componentes Web
Principios de Diseño de Componentes WebPrincipios de Diseño de Componentes Web
Principios de Diseño de Componentes WebJavier Vélez Reyes
 
Tecnologia web
Tecnologia webTecnologia web
Tecnologia webMeli Vidal
 

Ähnlich wie Presentacion curso ingenieria web ing. aldo zanabria (20)

Modulo taller progwebaa2
Modulo   taller progwebaa2Modulo   taller progwebaa2
Modulo taller progwebaa2
 
Anteproyecto Liliana cujar
Anteproyecto Liliana cujarAnteproyecto Liliana cujar
Anteproyecto Liliana cujar
 
Promocionando mi Carrera Por Elvin Gabriel de Jesús
Promocionando mi Carrera Por Elvin Gabriel de JesúsPromocionando mi Carrera Por Elvin Gabriel de Jesús
Promocionando mi Carrera Por Elvin Gabriel de Jesús
 
Ingeniería web_Unidad 3
Ingeniería web_Unidad 3Ingeniería web_Unidad 3
Ingeniería web_Unidad 3
 
Presentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en InternetPresentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en Internet
 
Qué es la ingeniería web
Qué es la ingeniería webQué es la ingeniería web
Qué es la ingeniería web
 
Qué es la ingeniería web
Qué es la ingeniería webQué es la ingeniería web
Qué es la ingeniería web
 
Aplicaciones de diseño de internet
Aplicaciones de diseño de internetAplicaciones de diseño de internet
Aplicaciones de diseño de internet
 
La ingeniería del software en España: retos y oportunidades
La ingeniería del software en España: retos y oportunidadesLa ingeniería del software en España: retos y oportunidades
La ingeniería del software en España: retos y oportunidades
 
Presentación Sesión 1 Ingeniería del Software.pptx
Presentación Sesión 1 Ingeniería del Software.pptxPresentación Sesión 1 Ingeniería del Software.pptx
Presentación Sesión 1 Ingeniería del Software.pptx
 
Ingenieria web
Ingenieria webIngenieria web
Ingenieria web
 
Tecnologiaweb 101114145311-phpapp02
Tecnologiaweb 101114145311-phpapp02Tecnologiaweb 101114145311-phpapp02
Tecnologiaweb 101114145311-phpapp02
 
ingenieria de software
ingenieria de softwareingenieria de software
ingenieria de software
 
Requerimientos, Ventajas y Desventajas de las aplicaciones web
Requerimientos, Ventajas y Desventajas de las aplicaciones webRequerimientos, Ventajas y Desventajas de las aplicaciones web
Requerimientos, Ventajas y Desventajas de las aplicaciones web
 
Presentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en InternetPresentación de Asignatura::Diseño de Sistemas en Internet
Presentación de Asignatura::Diseño de Sistemas en Internet
 
SeccióN De TéCnicas De IngenieríA De Software(2007)
SeccióN De TéCnicas  De IngenieríA De Software(2007)SeccióN De TéCnicas  De IngenieríA De Software(2007)
SeccióN De TéCnicas De IngenieríA De Software(2007)
 
Diseño de Páginas Web.pptx
Diseño de Páginas Web.pptxDiseño de Páginas Web.pptx
Diseño de Páginas Web.pptx
 
Las Mediciones de Software y sus Aplicaciomes
Las Mediciones de Software y sus AplicaciomesLas Mediciones de Software y sus Aplicaciomes
Las Mediciones de Software y sus Aplicaciomes
 
Principios de Diseño de Componentes Web
Principios de Diseño de Componentes WebPrincipios de Diseño de Componentes Web
Principios de Diseño de Componentes Web
 
Tecnologia web
Tecnologia webTecnologia web
Tecnologia web
 

Mehr von Aldo Hernán Zanabria Gálvez

“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...
“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...
“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...Aldo Hernán Zanabria Gálvez
 
Organizadores visuales sobre las corrientes contemporaneas aldo zanabria ga...
Organizadores visuales sobre las corrientes contemporaneas   aldo zanabria ga...Organizadores visuales sobre las corrientes contemporaneas   aldo zanabria ga...
Organizadores visuales sobre las corrientes contemporaneas aldo zanabria ga...Aldo Hernán Zanabria Gálvez
 
Resumen final - Seminario Taller TIC Emprede Turismo
Resumen final - Seminario Taller TIC Emprede TurismoResumen final - Seminario Taller TIC Emprede Turismo
Resumen final - Seminario Taller TIC Emprede TurismoAldo Hernán Zanabria Gálvez
 
Clase de Tecnologías de la Información y Comunicaciones
Clase de Tecnologías de la Información y ComunicacionesClase de Tecnologías de la Información y Comunicaciones
Clase de Tecnologías de la Información y ComunicacionesAldo Hernán Zanabria Gálvez
 

Mehr von Aldo Hernán Zanabria Gálvez (20)

“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...
“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...
“PERSPECTIVAS DEL DESARROLLO ECONÓMICO REGIONAL EN EL CONTEXTO DEL CAMBIO CLI...
 
mejorando la web guia de html 5
mejorando la web guia de html 5mejorando la web guia de html 5
mejorando la web guia de html 5
 
Guía de Prácticas word beta.pdf
Guía de Prácticas word beta.pdfGuía de Prácticas word beta.pdf
Guía de Prácticas word beta.pdf
 
emprendimiento en la era del conocimiento.pptx
emprendimiento en la era del conocimiento.pptxemprendimiento en la era del conocimiento.pptx
emprendimiento en la era del conocimiento.pptx
 
Fundamentos de Programación
Fundamentos de ProgramaciónFundamentos de Programación
Fundamentos de Programación
 
Organizadores visuales sobre las corrientes contemporaneas aldo zanabria ga...
Organizadores visuales sobre las corrientes contemporaneas   aldo zanabria ga...Organizadores visuales sobre las corrientes contemporaneas   aldo zanabria ga...
Organizadores visuales sobre las corrientes contemporaneas aldo zanabria ga...
 
didactica
didacticadidactica
didactica
 
Tarea1 aldo zanabria
Tarea1 aldo zanabriaTarea1 aldo zanabria
Tarea1 aldo zanabria
 
Tarea 2 aldo zanabria
Tarea 2 aldo zanabriaTarea 2 aldo zanabria
Tarea 2 aldo zanabria
 
Carolinos del milenio pasado - Puno
Carolinos del milenio pasado - PunoCarolinos del milenio pasado - Puno
Carolinos del milenio pasado - Puno
 
ingenieria de sistemas
ingenieria de sistemasingenieria de sistemas
ingenieria de sistemas
 
Electricidad con recursos renovables
Electricidad con recursos renovablesElectricidad con recursos renovables
Electricidad con recursos renovables
 
Variables
VariablesVariables
Variables
 
Estructura y modelo organizacional estatal
Estructura y modelo organizacional estatal Estructura y modelo organizacional estatal
Estructura y modelo organizacional estatal
 
Calidad de Agua
Calidad de AguaCalidad de Agua
Calidad de Agua
 
Resumen final - Seminario Taller TIC Emprede Turismo
Resumen final - Seminario Taller TIC Emprede TurismoResumen final - Seminario Taller TIC Emprede Turismo
Resumen final - Seminario Taller TIC Emprede Turismo
 
Clase de Tecnologías de la Información y Comunicaciones
Clase de Tecnologías de la Información y ComunicacionesClase de Tecnologías de la Información y Comunicaciones
Clase de Tecnologías de la Información y Comunicaciones
 
Plan de Trabajo Integración de la Mujer
Plan de Trabajo Integración de la MujerPlan de Trabajo Integración de la Mujer
Plan de Trabajo Integración de la Mujer
 
peritaciones y tasación puno
peritaciones y tasación punoperitaciones y tasación puno
peritaciones y tasación puno
 
producción en la empresa turística
producción en la empresa turísticaproducción en la empresa turística
producción en la empresa turística
 

Kürzlich hochgeladen

ficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primariaficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primariamichel carlos Capillo Dominguez
 
Anuncio de Remitido Colegio SEK a la comunidad pública
Anuncio de Remitido Colegio SEK a la comunidad públicaAnuncio de Remitido Colegio SEK a la comunidad pública
Anuncio de Remitido Colegio SEK a la comunidad públicaIvannaMaciasAlvarez
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCEROCIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCEROCEIP TIERRA DE PINARES
 
explicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.pptexplicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.pptjosemanuelcremades
 
U2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfU2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfJavier Correa
 
Escrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesEscrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesmelanieteresacontrer
 
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdfceeabarcia
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxJulioSantin2
 
Recursos Tecnológicos, página AIP-CRT 2 0 2 4.pdf
Recursos Tecnológicos, página  AIP-CRT 2 0 2 4.pdfRecursos Tecnológicos, página  AIP-CRT 2 0 2 4.pdf
Recursos Tecnológicos, página AIP-CRT 2 0 2 4.pdfNELLYKATTY
 
Programación Anual 2024 - CIENCIAS SOCIALES.docx
Programación Anual 2024  - CIENCIAS SOCIALES.docxProgramación Anual 2024  - CIENCIAS SOCIALES.docx
Programación Anual 2024 - CIENCIAS SOCIALES.docxJhordanBenitesSanche1
 
Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Ivie
 
CARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCarolVigo1
 
la forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolarla forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolarCa Ut
 
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfGUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfNELLYKATTY
 
Presentación del tema: tecnología educativa
Presentación del tema: tecnología educativaPresentación del tema: tecnología educativa
Presentación del tema: tecnología educativaricardoruizaleman
 
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdfdiana593621
 

Kürzlich hochgeladen (20)

ficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primariaficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primaria
 
Anuncio de Remitido Colegio SEK a la comunidad pública
Anuncio de Remitido Colegio SEK a la comunidad públicaAnuncio de Remitido Colegio SEK a la comunidad pública
Anuncio de Remitido Colegio SEK a la comunidad pública
 
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdfTema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
 
Sesión de clase ES: Adoración sin fin...
Sesión de clase ES: Adoración sin fin...Sesión de clase ES: Adoración sin fin...
Sesión de clase ES: Adoración sin fin...
 
Conducta ética en investigación científica.pdf
Conducta ética en investigación científica.pdfConducta ética en investigación científica.pdf
Conducta ética en investigación científica.pdf
 
Tema 6.- La identidad visual corporativa y el naming.pdf
Tema 6.- La identidad visual corporativa y el naming.pdfTema 6.- La identidad visual corporativa y el naming.pdf
Tema 6.- La identidad visual corporativa y el naming.pdf
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCEROCIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
 
explicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.pptexplicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.ppt
 
U2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfU2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdf
 
Escrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesEscrito administrativo técnico y comerciales
Escrito administrativo técnico y comerciales
 
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptx
 
Recursos Tecnológicos, página AIP-CRT 2 0 2 4.pdf
Recursos Tecnológicos, página  AIP-CRT 2 0 2 4.pdfRecursos Tecnológicos, página  AIP-CRT 2 0 2 4.pdf
Recursos Tecnológicos, página AIP-CRT 2 0 2 4.pdf
 
Programación Anual 2024 - CIENCIAS SOCIALES.docx
Programación Anual 2024  - CIENCIAS SOCIALES.docxProgramación Anual 2024  - CIENCIAS SOCIALES.docx
Programación Anual 2024 - CIENCIAS SOCIALES.docx
 
Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023
 
CARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacion
 
la forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolarla forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolar
 
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfGUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
 
Presentación del tema: tecnología educativa
Presentación del tema: tecnología educativaPresentación del tema: tecnología educativa
Presentación del tema: tecnología educativa
 
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
 

Presentacion curso ingenieria web ing. aldo zanabria

  • 1. Ingeniería web Ing. Aldo Hernan Zanabria Galvez  Ingeniero de Sistemas – M.Sc. (e) Ingenieria de Sistemas: Ingenieria de Software Ing. Aldo Hernan Zanabria Galvez 1 /aldozpuno @aldozpuno www.zanabria.org/eva
  • 2. Que es?  Planeación de un proyecto web.  Creación de una lluvia de ideas para mejorar nuestro proyecto.  Diseño de la Base de Datos de nuestro proyecto.  Diagrama esquemático del proyecto.  Creación del Diseño Gráfico: Adobe Photoshop.  Maquetación del proyecto utilizando XHTML y CSS.  Programación Web: Ajax, PHP/MySQL, Javascript y XML.  Optimización.  Publicando el proyecto en internet.  Rentabilizar tu proyecto web. Ing. Aldo Hernan Zanabria Galvez 2
  • 3. Que es?  Diseño de procesos de negocio para aplicaciones web  Generación de código para aplicaciones web  Desarrollo web colaborativo  Ingeniería web empírica  Entornos de desarrollo de aplicaciones web integrados  Pruebas de rendimiento de aplicaciones basadas en web  Personalización y adaptación de aplicaciones web  Modelado de procesos para aplicaciones web  Herramientas y métodos de prototipado  Control de calidad y pruebas de sistemas  Aplicaciones web móviles  Usabilidad de aplicaciones web  Accesibilidad para la web  Metodologías de diseño web  Diseño de interfaces de usuario Ing. Aldo Hernan Zanabria Galvez 3
  • 4. Fundamentos de la Ingeniería Web.  Se aportan los conocimientos necesarios para que el alumno tenga una visión global del mercado y la situación del máster en el mismo, y permite nivelar los diferentes perfiles para conseguir un grupo homogéneo en conocimientos de ingeniería del software. Ing. Aldo Hernan Zanabria Galvez 4
  • 5. Tecnologías Web  Clientes Multimedia  Desarrollo de Aplicaciones para Sistemas Móviles  Desarrollo de Aplicaciones Web de Libre Distribución  Desarrollo de Aplicaciones Web Propietarias  Desarrollo de aplicaciones Web Distribuidas de Código Abierto  Diseño Gráfico  Sistemas Gestores de Contenido  Técnologías de Desarrollo para Clientes Ligeros Ing. Aldo Hernan Zanabria Galvez 5
  • 6. METODOLOGÍAS DE DESARROLLO Y GESTIÓN PARA LA WEB  Metodologías Pesadas para Desarrollo Web  Metodologías Web Ligeras  Modelo de Negocio y Comercio Electrónico en la Web Ing. Aldo Hernan Zanabria Galvez 6
  • 7. SERVICIOS DE INTERNET  Servicios y Protocolos de Aplicaciones en Internet  Seguridad en la Programación Web Ing. Aldo Hernan Zanabria Galvez 7
  • 8. FUNDAMENTOS DE LA INGENIERÍA WEB Visión general en la Ingeniería Web Patrones de Diseño Ing. Aldo Hernan Zanabria Galvez 8
  • 9. Objetivos  Introducir al alumno en el desarrollo sistemático de aplicaciones Web  Ofrecer los fundamentos básicos de métodos de ingeniería aplicados al desarrollo de sistemas Web complejos  Profundizar en el lenguaje de modelado UML para posibilitar el modelado de aspectos propios de las aplicaciones Web como es el caso de la navegabilidad  Incidir en el concepto de calidad en los sistemas Web  Presentar características avanzadas propias de los sistemas Web actuales (adaptabilidad, adaptatividad, usabilidad, cooperación...)  Presentar las líneas de investigación actuales en el campo de la Ingeniería Web Ing. Aldo Hernan Zanabria Galvez 9
  • 10. Ingeniería web  Cualquier producto o sistema importante es merecedor de recibir una ingeniería.  Antes de comenzar a construir lo mejor es :  Entender el problema  Diseñar una solución viable  Implementar la solución de una manera sólida  Comprobarla en profundidad  Controlar los cambios  Mecanismos para asegurar la calidad Ing. Aldo Hernan Zanabria Galvez 10
  • 11. Ingeniería web La ingeniería web no es un clon de la ingeniería de software, pero toma de ella mucho de los conceptos y principios básicos de ésta, dando importancia a las mismas actividades técnicas y de gestión. Al igual que cualquier disciplina de ingeniería, la ingeniería web aplica un enfoque genérico que se suaviza con estrategias, tácticas y métodos especializados. Ing. Aldo Hernan Zanabria Galvez 11
  • 12. Ingeniería Web  Con la ausencia de un proceso disciplinado para sistemas basados en web, cada vez es mas preocupante la manera de poder enfrentarse con problemas serios para tener éxito en el desarrollo, empleo y mantenimiento de los sistemas  La forma de crecimiento actual puede dirigirse a tener una “web enmarañada” Ing. Aldo Hernan Zanabria Galvez 12
  • 13. Antes-después Ing. Aldo Hernan Zanabria Galvez 13
  • 14. Atributos de aplicaciones web  Intensivas de red.  Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes.  Controlada por el contenido  La función primaria de una aplicación web es utilizar hipermedia para presentar al usuario el contenido de textos, gráficos, sonidos y video. Ing. Aldo Hernan Zanabria Galvez 14
  • 15. Atributos de aplicaciones web  Evolución continua  A diferencia de aplicaciones convencionales que evolucionan con versiones planificadas y cronológicas, las aplicaciones web están en constante evolución  Inmediatez  Tiene una inmediatez de comercialización que no tienen otros tipos de software. Tiempos de desarrollo apresurados Ing. Aldo Hernan Zanabria Galvez 15
  • 16. Atributos de aplicaciones web  Seguridad  Debe implementar fuertes medidas de seguridad en toda la infraestructura dentro y fuera de la aplicación, ya que por su naturaleza es difícil limitar la población de usuarios que pueden acceder a ella.  Estética  Una parte innegable: su apariencia e interacción. Tiene mucho que ver con el éxito del diseño técnico. Ing. Aldo Hernan Zanabria Galvez 16
  • 17. Servicios de Internet.  Se aportan los conocimientos para comprender los diferentes servicios existentes y las soluciones tecnológicas. Ing. Aldo Hernan Zanabria Galvez 17
  • 18. Tecnologías Web  Se aportan los conocimientos de las diferentes plataformas y tecnologías presentes en el mercado actual en todo el proceso que conlleva el desarrollo de aplicaciones Web.. Ing. Aldo Hernan Zanabria Galvez 18
  • 19. Metodologías de desarrollo y gestión para la Web  Se aportan los conocimientos en las metodologías existentes para el desarrollo de aplicaciones Web y en la gestión de negocios virtuales asociados. Ing. Aldo Hernan Zanabria Galvez 19
  • 20. Trabajo de Fin de CURSO.  Ejercicio original, a realizar individualmente y presentar y defender ante el Docente, en el ámbito de la Ingeniería Web de naturaleza académica y profesional en el que se sinteticen e integren las competencias adquiridas en las enseñanzas o durante prácticas en empresas. Ing. Aldo Hernan Zanabria Galvez 20
  • 21. FUNDAMENTOS Ing. Aldo Hernan Zanabria Galvez 21
  • 22. Contenidos  Introducción  Diferencias entre los sistemas web y el software tradicional  Ingeniería Web  Usabilidad Ing. Aldo Hernan Zanabria Galvez 22
  • 23. Dependencia social de la red Ing. Aldo Hernan Zanabria Galvez 23
  • 24. Usuarios de Internet Ing. Aldo Hernan Zanabria Galvez 24
  • 25. Usuarios de Internet ESTADISTICAS MUNDIALES DEL INTERNET Y DE LA POBLACION Regiones Poblacion ( 2011 Est.) Usuarios Dic. 31, 2000 Usuarios Dic. 31, 2011 % Población (Penetración) Usuarios % Mundial Facebook Dic. 31, 2011 Africa 1,037,524,058 4,514,400 139,875,242 13.5 % 6.2 % 37,739,380 Asia 3,879,740,877 114,304,000 1,016,799,076 26.2 % 44.8 % 183,963,780 Europa 816,426,346 105,096,093 500,723,686 61.3 % 22.1 % 223,376,640 Oriente Medio 216,258,843 3,284,800 77,020,995 35.6 % 3.4 % 18,241,080 Norte America 347,394,870 108,096,800 273,096,800 78.6 % 12.0 % 174,586,680 Latinoamerica / Caribe 597,283,165 18,068,919 235,819,740 39.5 % 10.4 % 147,831,180 Oceania / Australia 35,426,995 7,620,480 23,927,457 67.5 % 1.1 % 13,353,420 TOTAL MUNDIAL 6,930,055,154 360,985,492 2,267,233,742 32.7 % 100.0 % 799,092,160 NOTAS: (1) Las Estadisticas de Usuarios Mundiales del Internet fueron actualizadas a Diciembre 31, 2011. (2) Para ver información detallada, de un clic sobre la región o el país correspondiente. (3) Los datos de población se basan en cifras para 2011 del US Census Bureau. (4) Los datos de usuarios provienen de información publicada por Nielsen Online , ITU y de Internet World Stats. (6) Estas estadísticas son propiedad intelectual de Miniwatts Marketing Group, se pueden citar, siempre manifestando el debido credito y estableciendo un enlace activo a www.exitoexportador.com . Copyright © 2001- 2012, Miniwatts Marketing Group. Todos los derechos reservados. Ing. Aldo Hernan Zanabria Galvez 25
  • 26. ¿Cómo afrontar esta demanda?  Es necesario contar con un conjunto consolidado de procesos, técnicas y herramientas que ayuden al ingeniero en su labor  Ingeniería del Software es la disciplina que aplica los principios de ingeniería al contexto del software  Creación de soluciones rentables a problemas prácticos  Mediante la aplicación del conocimiento científico  Para la construcción de cosas al servicio de la humanidad (Shaw, 1990) ¿Y esto también para las aplicaciones Web? Ing. Aldo Hernan Zanabria Galvez 26
  • 27. ¿Y esto también para las aplicaciones Web?  El desarrollo de aplicaciones web en general no es una excepción  Presiones para acelerar la salida de las aplicaciones web  A semejanza de los primeros tiempos del software tradicional, se está convirtiendo en un crecimiento caótico y sin control de la Web  ¿Qué se debería haber aprendido?  Por mucha prisa que exista, es necesario un proceso software que guíe el devenir del desarrollo, facilitando su futuro mantenimiento y evolución  Debe elegirse el proceso adecuado  Que se ajuste a las necesidades del proyecto software y de las organizaciones involucradas en su ciclo de vida Ing. Aldo Hernan Zanabria Galvez 27
  • 28. ¿Y esto también para las aplicaciones Web? “Me parece que cualquier producto o sistema importante es merecedor de recibir una ingeniería. Antes de comenzar a construir, lo mejor es entender el problema, diseñar una solución viable, implementarla de una manera sólida y comprobarla en profundidad. Probablemente también se debería controlar los cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos para asegurar la calidad del resultado final. Muchos de los que desarrollan Webs no dicen lo mismo; ellos piensan que su mundo es realmente diferente, y que simplemente no se van a aplicar los enfoques de Ingeniería del Software convencionales Roger S. Pressman Ing. Aldo Hernan Zanabria Galvez 28
  • 29. Planteamiento del problema  Crecimiento y desarrollo de Internet en general y de la Web en particular  El crecimiento de la Web, como medio de aplicación, ha sido exponencial y muy rápido  Gran impacto en muchos ámbitos de la sociedad (banca, comercio, negocios, industria, educación…)  Muchas de las aplicaciones tradicionales están siendo migradas total o parcialmente para tener acceso a la Web  Avances de las tecnologías wireless y su conexión con Internet están dando lugar a una nueva generación de aplicaciones Web móviles  Mayor dependencia de las aplicaciones Web cada vez más complejas y críticas Ing. Aldo Hernan Zanabria Galvez 29
  • 30. Planteamiento del problema  Tiempo que ha llevado llegar a los 50 millones de usuarios  40 años a la telefonía  35 años a la radio  20 años al vídeo  26 años a la televisión  19 años a los ordenadores  Sólo 4 años a Internet Ing. Aldo Hernan Zanabria Galvez 30
  • 31. Planteamiento del problema  Este aumento en la importancia de las aplicaciones web no se ha visto refrendado con una mejora en el proceso de desarrollo de las mismas  Existe prisa y presión competitiva en el desarrollo de los sistemas web  Prisa por estar en la Web e intentar dominar este espacio en cada área de aplicación imaginable  Se sigue un proceso ad-hoc, falto de rigor y sistematización  Influencias del desarrollo de los primeros sitios web estáticos y de pequeño tamaño  Abundan las aplicaciones web desarrolladas sin rigor alguno  Alta probabilidad de fallo  Bajo rendimiento Ing. Aldo Hernan Zanabria Galvez 31
  • 32. Planteamiento del problema  No prestan atención a  La obtención de los requisitos y su análisis  Las metodologías de desarrollo y los procesos software  La capacidad de mantenimiento  La escalabilidad  La accesibilidad La usabilidad  La seguridad  …  Frecuentemente estos desarrollos recaen en individuos o grupos pequeños que hacen uso de sus prácticas en absoluto estandarizadas, por no mencionar la falta de pruebas y documentación Ing. Aldo Hernan Zanabria Galvez 32
  • 33. Planteamiento del problema  Muchos desarrolladores piensan que el desarrollo de las aplicaciones web se reduce a la creación de una página web  Ya sea empleando HTML o un compositor de páginas como Front Page o Dreaweaver  Desgraciadamente diversos libros y revistas potencian esta idea  Hay ciertos tipos de aplicaciones web sumamente simples que pueden catalogarse dentro de esta clasificación simplista  Páginas personales, folletos…  Se trata como un problema de autoría en lugar de como un problema de desarrollo  ¿Qué sucede con las aplicaciones que van mucho más allá de la presentación de contenidos?  Un aplicación web es más que un diseño visual y una interfaz de usuario  Planificación, requisitos, diseño del sistema, pruebas, mantenimiento… Ing. Aldo Hernan Zanabria Galvez 33
  • 34. Planteamiento del problema  Las necesidades de estos tipos de aplicaciones incluyen, entre otras, cómo gestionar  La presentación de información  La navegación dentro de la aplicación  Mecanismos de búsqueda de información  Interfaces complejas (texto + multimedia) Ing. Aldo Hernan Zanabria Galvez 34
  • 35. Planteamiento del problema  ¿Quién controla los sitios web?  Lucha entre  El departamento de informática  El departamento de marketing y relaciones públicas  Unidades organizacionales individuales Ing. Aldo Hernan Zanabria Galvez 35
  • 36. Planteamiento del problema  El desarrollo de una aplicación web no es exactamente lo mismo que el desarrollo de otro tipo de aplicación software  No se pueden seguir exactamente las mismas prácticas  Hay varios puntos en común, pero existen diferencias significativas  Las aplicaciones web requieren un mantenimiento continuo  La complejidad de las grandes aplicaciones web es, con frecuencia, engañosa Ing. Aldo Hernan Zanabria Galvez 36
  • 37. Planteamiento del problema  Problemas derivados con una aproximación ad-hoc en el desarrollo de aplicaciones web  El sistema completo no es lo qué el usuario quiere  El sistema no se desarrolla a tiempo y el coste se dispara  Falta de escalabilidad y capacidad de mantenimiento  Limitado tiempo de vida útil  No se cumplen los requisitos de rendimiento  Derroche de recursos Ing. Aldo Hernan Zanabria Galvez 37
  • 38. Ing. Aldo Hernan Zanabria Galvez 38
  • 39. INTRODUCCIÓN Ing. Aldo Hernan Zanabria Galvez 39
  • 40. Crisis de la Web  Las aplicaciones web pobremente desarrolladas tienen una probabilidad muy alta de fallar  Un fallo en una aplicación web puede propagarse causando problemas en muchas otras  Potencial para una crisis de la Web: Los desastres de la Web  La confianza en la Web puede verse afectada de forma irreparable  Puede ser más importante y extendida que la crisis del software  Los proyectos fallan  Objetivos equivocados  Carencias en la gestión del proyecto  Falta de proceso Ing. Aldo Hernan Zanabria Galvez 40
  • 41. Evitar los desastres en la Web  Se necesitan aproximaciones disciplinadas para el desarrollo, explotación y evaluación de sistemas basados en la Web  Estas aproximaciones deben tener en cuenta  Las características propias del nuevo medio que supone la Web  Los entornos de operación  Escenarios y multiplicidad de perfiles de usuarios  El tipo, características y conocimiento de los involucrados en el desarrollo de un sistema web  Crecimiento y cambio potencial Ing. Aldo Hernan Zanabria Galvez 41
  • 42. Una nueva disciplina  Se identifican nuevos elementos propios de las aplicaciones web que no se cubren en las Ciencias de la Computación, en la Ingeniería del Software o en los Sistemas de Información  Existe una acuciante necesidad de aproximaciones sistemáticas y estrategias de desarrollo orientadas a las aplicaciones web  Debe alejarse de las aproximaciones ad-hoc  De una aproximación personal y ad-hoc a una aproximación disciplinada basada en un proceso  Se necesita engendrar una conciencia sobre la necesidad de una aproximación sistemática  En 1998 surge una nueva disciplina interesada en abordar esta problemática y que recibe el nombre de Ingeniería Web  Grupo de profesores de la Universidad de Western Sydney Ing. Aldo Hernan Zanabria Galvez 42
  • 43. CRISIS DE LA WEB Diferencias entre los sistemas web y el software tradicional Ing. Aldo Hernan Zanabria Galvez 43
  • 44. Sistemas web vs software tradicional  Los sistemas web tienen una naturaleza y unos requisitos que difieren del software tradicional  Los sistemas web  Están orientados a documentos que contienen páginas web estáticas o dinámicas  Se centran en el look & feel y enfatizan la creatividad visual y la presentación en la interfaz Son conducidos por el contenido, incluyendo el desarrollo del contenido  Necesitan ofrecer servicios a usuarios con diversidad de características y capacidades  Ejemplifican los vínculos entre el arte y la ciencia que generalmente aparecen en el desarrollo del software Ing. Aldo Hernan Zanabria Galvez 44
  • 45. Sistemas web vs software tradicional  Los sistemas Web  Requieren acortar el tiempo de desarrollo, dificultando aplicar el mismo nivel de formalidad en la planificación y prueba que se aplica en el software tradicional  Presentan un formato de distribución y explotación diferente al software tradicional  Los desarrolladores de los sistemas web  Difieren en gran medida en su formación, características, conocimiento y comprensión del sistema  Diferencias en su percepción de la Web y de la calidad del sistema web Ing. Aldo Hernan Zanabria Galvez 45
  • 46. ¿Qué es especial en los sistemas web?  Evolución del sitio web  La organización completa es una disposición de celdas interdependientes  Gestión del contenido  El contenido y la funcionalidad cambia en el tiempo  Gestión del rápido y gran cambio requerido, por ejemplo, en los sistemas de e-business  Son como sistemas orgánicos que continuamente se adaptan a su entorno  Desarrollo abierto  Los desarrollos y correcciones no tienen que hacerse necesariamente por ingenieros de software  Departamentos o personas individuales pueden tener privilegios para hacer cambios  Herramientas de autor Ing. Aldo Hernan Zanabria Galvez 46
  • 47. ¿Qué es especial en los sistemas web?  El sistema es la organización  No es un papel soportado, sino que se convierte en el sistema  Organizaciones virtuales y empresas virtuales  Diversidad de involucrados  Internos y externos a la organización  Consideraciones sobre diferencias regionales, culturales, lingüísticas…  Responsabilidad ambigua sobre el sitio web  La gestión global de la estrategia web recibe poca atención Ing. Aldo Hernan Zanabria Galvez 47
  • 48. INGENIERÍA WEB Ing. Aldo Hernan Zanabria Galvez 48
  • 49. Presentación  La Ingeniería Web se ocupa del desarrollo y gestión de sistemas web grandes y complejos  Tiene como objetivos (Murugesan, 2000)  Gestionar y controlar la complejidad en todo el ciclo de vida  Soportar efectivamente los diferentes tipos de usuario de una aplicación Web  Hacer de los sistemas basados en la Web menos una aspiración y más una profesión  Los sistemas web evolucionan  Compatibilidad  Flexibilidad  Escalabilidad Ing. Aldo Hernan Zanabria Galvez 49
  • 50. Presentación  La Ingeniería Web intenta evitar el caos existente en el desarrollo de sistemas basados en la Web  Controlar el proceso  Minimizar riesgos  Potenciar la calidad y la capacidad de mantenimiento  La Ingeniería Web no es un clon de la Ingeniería del Software  La Ingeniería Web adopta muchos de los principios de la Ingeniería del Software  Incorpora muchos de los principios y muchas de las prácticas de la Ingeniería del Software  Son sumamente conocidos y están satisfactoriamente probados  Adapta estos principios a la naturaleza más abierta y flexible de la Web  Así como también al tipo de aplicación web  Combina estos principios con elementos que son específicos de la Web Ing. Aldo Hernan Zanabria Galvez 50
  • 51. Presentación  La Ingeniería Web incorpora nuevas aproximaciones, metodologías, técnicas y guías para cumplir los requisitos de los sistemas web  Desarrollar aplicaciones web difiere sustancialmente de los desarrollos tradicionales  Diferencias en la naturaleza y en el ciclo de vida de las aplicaciones web  El desarrollo web es una mezcla entre la publicación y el desarrollo de software, entre la mercadotecnia y la computación, entre las comunicaciones internas y las relaciones externas, y entre el arte y la tecnología (Powell, 1998) Ing. Aldo Hernan Zanabria Galvez 51
  • 52. Principios de ingeniería aplicados a la Web  Objetivos y requisitos bien definidos  Desarrollo de un producto en fases  Planificación cuidadosa de dichas fases  Diseño y desarrollo sistemático  Auditoría continua de todo el proceso Ing. Aldo Hernan Zanabria Galvez 52
  • 53. Jardinería web  Metáfora ampliamente utilizada en el desarrollo de sistemas web (Murugesan et al., 2001)  Como los jardines, las aplicaciones web evolucionan, cambian y crecen de forma continua  Los sistemas basados en la Web son sistemas que crecen  Se necesita una buena infraestructura inicial para permitir el crecimiento de una forma controlada y flexible, a la vez que se fomenta la creatividad, el refinamiento y el cambio  Esta metáfora relaciona la necesidad de unos principios de ingeniería para las aplicaciones web con las capacidades creativas que se pueden plasmar en muchos de estos sistemas Ing. Aldo Hernan Zanabria Galvez 53
  • 54. La Ingeniería Web es un campo multidisciplinar Ing. Aldo Hernan Zanabria Galvez 54
  • 55. Definición  La aplicación de una aproximación sistemática, disciplinada y cuantificable al desarrollo, operación y mantenimiento de aplicaciones basadas en la Web o la aplicación de la ingeniería al software basado en la Web (Murugesan et al., 2001)  „ La aplicación de principios científicos para diseñar y crear sistemas de información basados en la Web efectivos de una manera eficiente (Ginige, 2000) Ing. Aldo Hernan Zanabria Galvez 55
  • 56. Categorías de las aplicaciones web Ing. Aldo Hernan Zanabria Galvez 56
  • 57. Sistemas web simples vs avanzados Ing. Aldo Hernan Zanabria Galvez 57
  • 58. Atributos de las aplicaciones web  Atributos de las aplicaciones web (Pressman, 2000)  Intensivas de red  Controladas por el contenido  Evolución continua  Inmediatez  Seguridad  Estética Ing. Aldo Hernan Zanabria Galvez 58
  • 59. Atributos de las aplicaciones web  Atributos de las aplicaciones web (Murugesan, 2000)  En línea (disponibles las 24 horas del día)  Ubicuidad  Locales y globales  Digitalización  Multimedia Interactividad  Integración  Diversidad de accesos  Intranet  Extranet  Público Ing. Aldo Hernan Zanabria Galvez 59
  • 60. Calidad de las aplicaciones web  Las características generales de la calidad del software se aplican a las aplicaciones web  Las características más relevantes (usabilidad, eficiencia y capacidad de mantenimiento) proporcionan una base útil para evaluar la calidad de los sistemas web  Olsina et al. (2001) han desarrollado un árbol de requisitos de calidad que identifica un conjunto de atributos que conducen a aplicaciones web de alta calidad Ing. Aldo Hernan Zanabria Galvez 60
  • 61. Calidad de las aplicaciones Web Ing. Aldo Hernan Zanabria Galvez 61
  • 62. USABILIDAD Ing. Aldo Hernan Zanabria Galvez 62
  • 63. Ing. Aldo Hernan Zanabria Galvez 63
  • 64. ¿Qué es la usabilidad?  Diseñar para la forma de ser de las personas, en contraposición de diseñar para la tecnología o para la organización  Facilidad de aprendizaje  Facilidad de uso  Reducir el número de errores de usuario Mejorar el placer de usar el sistema  Potenciar el uso del sistema frente a la complejidad artística  Tendencia KISS (Keep It Simple, Stupid!)  El sitio debe ser claro y limpio  En Internet sobreviven lo más sencillo  Técnicamente el sitio debe ser compatible con los diversos navegadores Ing. Aldo Hernan Zanabria Galvez 64
  • 65. ¿Qué es la usabilidad?  ¿Por qué las personas tienen que adaptarse a la tecnología?  ¿Por qué no hacer que la tecnología se adapte a las personas? (Jacob Nielsen)  Los usuarios pasan horas navegando por un sito web en búsqueda de una información  La navegación web es mucho más difícil de lo que se puede pensar  El personal de la organización no es siempre la audiencia a la que se destina la aplicación web  Se debe crear la aplicación web para quién la usa  Prestar atención a la usabilidad puede incrementar el porcentaje de visitantes  Importante en los comercios electrónicos Ing. Aldo Hernan Zanabria Galvez 65
  • 66. Comportamiento de los usuarios en la Web  Baja tolerancia para diseños difíciles o sitios lentos  A los usuarios no les gusta esperar  A los usuarios no les gusta aprender cómo utilizar un sitio  Web  No existen clases de entrenamiento ni manuales para un sitio web  A los usuarios desean capturar la funcionalidad del sitio web de forma inmediata tras echar un vistazo a la página principal durante unos segundos  Puede haber casos donde puede ser útil gastar un poco de tiempo en aprender a manejar el sitio web Ing. Aldo Hernan Zanabria Galvez 66
  • 67. Diseño centrado en el usuario  Ofrecer una arquitectura de navegación centrada en el usuario es importante  Diversos departamentos de una misma organización deberían colaborar en el desarrollo de la arquitectura de la aplicación Web  Los usuarios no desean conocer cómo se organiza la entidad que soporta la Web que visita  Los usuarios quieren llegar a la información que buscan en el menor tiempo posible Ing. Aldo Hernan Zanabria Galvez 67
  • 68. Usabilidad universal  Internacionalización  Accesibilidad para usuarios con discapacidades  Discapacidades visuales  Discapacidades cognitivas  Discapacidades auditivas  Discapacidades motoras Ing. Aldo Hernan Zanabria Galvez 68
  • 69. Usabilidad de la homepage  Las homepages son un activo real para las organizaciones  Cada año las organizaciones se gastan millones de euros en ellas  La homepage es la carta de presentación de las organización al mundo  La homepage es la página más importante en la mayoría de los sitios  Web Claves  El propósito de la organización debe explicitarse en la homepage  Hay que explicar quién eres y qué haces (Nielsen, 2002a)  Hay que ayudar a los usuarios a encontrar lo que necesitan  Revelar los contenidos del sitio  Utilizar el diseño visual para mejorar el diseño de la interacción (no para definirlo) Ing. Aldo Hernan Zanabria Galvez 69
  • 70. Criterios de usabilidad en la homepage  Incluir un párrafo de presentación  Contar con un título de ventana con buena visibilidad en los motores de búsqueda y en las listas de favoritos  Agrupar toda la información corporativa en una localización concreta y separada  Enfatizar las tareas prioritarias del sitio Web  Incluir un buscador  Mostrar ejemplos reales de los contenidos del sitio  Comenzar los nombres de los enlaces con las palabras clave más representativas  Ofrecer acceso fácil a las nuevas características del sitio  No sobrecargar de formato los contenidos críticos, tales como las áreas de navegación  Utilizar gráficos e ilustraciones significativas (Nielsen, 2002a) Ing. Aldo Hernan Zanabria Galvez 70
  • 71. ¿Es la Web usable?  La mayoría de los sitios web son correosos de usar  El 90% de los sitios web está pobremente diseñado (Murugesan, 2000)  Cuando los usuarios descubren que el sitio está repleto de gráficos inútiles y presenta poca información útil, se van a otro sitio y difícilmente volverán  Si el sitio hace que el navegador se interrumpa bruscamente, no volverán  Si los usuarios no encuentran el producto o la información que buscan, lo buscarán en otro sitio Ing. Aldo Hernan Zanabria Galvez 71
  • 72. Errores más frecuentes contra la usabilidad  Uso (abuso) de los marcos  Uso gratuito de la última tecnología  Uso de texto que se desplaza y animaciones continuas  URLs complejas  Páginas huérfanas  Minimizar el uso del scrolling  Falta de soporte a la navegación  No utilizar colores estándares para los enlaces  Información desfasada  Tiempos de bajada excesivamente grandes (Nielsen, 1996) Ing. Aldo Hernan Zanabria Galvez 72
  • 73. Errores más frecuentes contra la usabilidad  Dejar sin efecto el botón atrás  Abrir nuevas ventanas del navegador  Utilizar controles no estándares en la interfaz de usuario  Falta de biografías  Falta de información histórica  Mover páginas a nuevas URLs  Cabeceras que no tienen sentido fuera del contexto  Incorporar inmediatamente el último término de moda en Internet  Tiempos bajos de respuesta de los servidores  Evitar aquello que se asemeje a un anuncio (Nielsen, 1999) Ing. Aldo Hernan Zanabria Galvez 73
  • 74. Errores más frecuentes contra la usabilidad  Falta de precios en sitios de comercio electrónico  Motores de búsqueda inflexibles  Desplazamiento (scrolling) horizontal  Tamaños de fuentes fijos  Bloques de textos Uso de Javascript en los enlaces  Preguntas infrecuentes en los FAQ  Recoger direcciones de correo electrónico sin una política de privacidad  URLs de más de 75 caracteres  Enlaces mailto en sitios inesperados (Nielsen, 2002b) Ing. Aldo Hernan Zanabria Galvez 74
  • 75. Errores más frecuentes contra la usabilidad  Malas búsquedas  Ficheros PDF para su lectura en línea  No cambiar el color de los enlaces visitados  Texto no escalable  Tamaño de fuente fijo  Títulos de página con poco visibilidad para los buscadores  Todo cuya apariencia parece un anuncio  Violaciones de las convenciones de diseño  Apertura de nuevas ventanas en el navegador  No responder a las preguntas de los usuarios (Nielsen, 2004) Ing. Aldo Hernan Zanabria Galvez 75
  • 76. Referencias.  Ginige, A. (2000) Engineering a Better Web Site. Keynote Address, Asia Pacific  Web Conference, APWeb2000, Xian, China, October 2000  Ginige, A. y Murugesan, S. (2001) Web Engineering-An Introduction. IEEE Multimedia, 8(1):14-18  Murugesan, S. (2000) Web Engineering for Successful Software Development.  Tutorial Notes, Asia Pacific Web Conference, APWeb2000, Xian, China, October 2000 Ing. Aldo Hernan Zanabria Galvez 76
  • 77. MÉTODOS DE DESARROLLO PARA APLICACIONES WEB Ing. Aldo Hernán Zanabria Gálvez Ing. Aldo Hernan Zanabria Galvez 77
  • 78. Ing. Aldo Hernan Zanabria Galvez 78
  • 79. Contenidos  Introducción  Métodos para el desarrollo de aplicaciones web  OOWS: Un método de Ingeniería Web Ing. Aldo Hernan Zanabria Galvez 79
  • 80. Introducción  Un enfoque de ingeniería pone un fuerte énfasis en el modelado de productos y procesos  Se ha puesto de manifiesto la necesidad de métodos de desarrollo para aplicaciones web  Cada vez es mayor la tendencia de las organizaciones a tener soluciones software funcionales en el contexto de la Web  La funcionalidad es un hecho clave en la definición de la Ingeniería Web  Se tiene asumido que un sitio web ya no es un mero recurso estético para presentar información  Se requiere una funcionalidad correcta, enlazando el problema de desarrollar soluciones web con la correcta práctica de la Ingeniería del Software  Se debe hacer un esfuerzo porque las aplicaciones web se aborden desde sus inicios con una aproximación de ingeniería  Modelado conceptual de aplicaciones web  Conlleva tener presentes todas las características propias de una aplicación web en el propio modelado conceptual  En consecuencia se requiere un proceso preciso para la construcción de software funcional en la Web Ing. Aldo Hernan Zanabria Galvez 80
  • 81. Consideraciones previas  Las aplicaciones web han sido tradicionalmente desarrolladas ad- hoc  Normalmente como evolución de pequeñas aplicaciones que rápidamente se volvieron inmanejables e inmantenibles  Muchas de las prácticas utilizadas fallaron al desarrollar aplicaciones no triviales  Falta de planificación  Técnicas, procesos y métodos no apropiados Ing. Aldo Hernan Zanabria Galvez 81
  • 82. Diferencias en el desarrollo de aplicaciones web  El proceso involucra personas de diversa índole  Autores, programadores, expertos en multimedia…  El rol de los usuarios es más amplio y hace que se difícil capturar la estructura del dominio  La complejidad aumenta debido a la no linealidad de los hiperdocumentos y la facilidad de conectar aplicaciones web entre sí  Aumenta el riesgo de “perderse en la Web”  Las aplicaciones web tienen en cuenta aspectos estéticos y cognitivos que las aproximaciones de Ingeniería del Software tradicionales no soportan (Nanard y Nanard, 1995)  El proceso tiende a ser más incremental e iterativo, y el mantenimiento pasa a ser una parte significativa del ciclo de vida de las aplicaciones web Ing. Aldo Hernan Zanabria Galvez 82
  • 83. Métodos para la Ingeniería Web  Se han definido diversos métodos para la construcción de aplicaciones web  Proponen diferentes pasos y actividades  Algunos se centran sólo en el diseño o en la representación visual, mientras que otros cubren todo el proceso de desarrollo de una aplicación web  Todos prescriben diferentes técnicas y notaciones Algunos están soportados por herramientas Ing. Aldo Hernan Zanabria Galvez 83
  • 84. MÉTODOS PARA EL DESARROLLO DE APLICACIONES WEB Ing. Aldo Hernan Zanabria Galvez 84
  • 85. Introducción Una metodología es una aproximación organizada y sistemática para el ciclo de vida del sistema o sus partes. Especifica las tareas individuales y sus secuencias (Palvia y Nosek, 1993) Un método para el desarrollo de un sistema es un conjunto de fases que guían a los desarrolladores en sus elecciones de las técnicas que pueden ser apropiadas en cada fase del proyecto (Avison y Fitzgerald, 1995) Ing. Aldo Hernan Zanabria Galvez 85
  • 86. Introducción  Una metodología debe cubrir (Henderson-Sellers y Firesmith, 1999)  Un proceso de ciclo de vida completo, que comprenda aspectos tantos del negocio como técnicos  Un conjunto completo de conceptos y modelos que sean internamente consistentes  Una colección de reglas y guías  Una descripción completa de artefactos a desarrollar  Una notación con la que trabajar, idealmente soportada por diversas herramientas CASE y diseñada para una usabilidad óptima  Un conjunto de técnicas probadas  Un conjunto de métricas, junto con asesoramiento sobre calidad, estándares y estrategias de prueba  Identificación de los roles organizacionales  Guías para la gestión de proyectos y aseguramiento de la calidad  Asesoramiento para la gestión de bibliotecas y reutilización Ing. Aldo Hernan Zanabria Galvez 86
  • 87. HDM  HDM (Hypermedia Design Model) (Garzotto et al., 1993)  Uno de los primeros métodos desarrollados para la definición de la estructura y la interacción de las aplicaciones hipermediales  Se basa en la técnica de modelado conceptual Entidad/Relación  Extiende el concepto de entidad e introduce nuevas primitivas  Unidades (que se corresponden con el concepto de nodo) Enlaces  Las entidades HDM tienen una estructura interna y semántica de navegación asociada  Especificación de cómo se puede llevar a cabo la navegación y de cómo se visualiza la información  Una entidad es una jerarquía de componentes  Los componentes están formados por unidades Ing. Aldo Hernan Zanabria Galvez 87
  • 88. HDM  HDM (Hypermedia Design Model) (Garzotto et al., 1993)  Existen tres tipos de enlaces  Estructurales  Conectan componentes  De perspectiva  Conectan unidades  De aplicación  Conectan componentes y entidades  Existe otro tipo de entidades que dan acceso a las entidades de aplicación  Ofrecen puntos de entrada para comenzar la navegación  Para soportar el diseño de la presentación se definen  Ranuras (slots) – Una pieza atómica de información. Están compuestos de marcos  Marcos (frames) – Una unidad de presentación que se muestra al usuario  Ing. Aldo Hernan Zanabria Galvez 88
  • 89. RMM  RMM (Relationship Management Methodology) (Isakowitz et al., 1995)  Se ocupa del diseño y construcción de aplicaciones hipermedia definiendo un proceso formado por siete pasos  Diseño entidad/relación  Diseño de vistas de información (slices) Diseño de la navegación  Diseño de la interfaz de usuario  Diseño del protocolo de conversión  Diseño del comportamiento en ejecución  Construcción y prueba  Ing. Aldo Hernan Zanabria Galvez 89
  • 90. RMM Ing. Aldo Hernan Zanabria Galvez 90
  • 91. EORM  EORM (Enhanced Object Relationship Methodology) (Lange,1996)  Presenta un proceso iterativo que se basa en la riqueza del modelo objeto para representar relaciones entre objetos (enlaces) como objetos  Utiliza para ello notación OMT (Rumbaugh et al., 1991)  Este método se basa en tres frameworks  Clase  Consiste en definiciones reutilizables de clases  Composición  Consiste en definiciones reutilizables de clases de enlaces  Interfaz gráfica de usuario Ing. Aldo Hernan Zanabria Galvez 91
  • 92. OOHDM  OOHDM (Object-Oriented Hypermedia Design Method) (Schwabe y Rossi, 1995; Rossi, 1996)  Conlleva cinco actividades  Obtención de requisitos  Modelado conceptual  Diseño navegacional  Diseño de la interfaz abstracta  Implementación  Las actividades se llevan a cabo mediante un proceso incremental e iterativo, que hace uso de prototipos  Los modelos objetos se construyen en cada paso mejorando los de las iteraciones anteriores Ing. Aldo Hernan Zanabria Galvez 92
  • 93. OOHDM  OOHDM (Object-Oriented Hypermedia Design Method) (Schwabe y Rossi, 1995; Rossi, 1996)  El modelado conceptual se lleva a cabo con un diagrama de clases  Primero utilizando notación OMT (Rumbaugh et al., 1991) y posteriormente notación UML (OMG, 2004)  Este método ve a una aplicación web como una vista del modelo conceptual Las clases que definen las vistas son las clases navegacionales  Así, el modelo conceptual incluye dos tipos de objetos  Los que se perciben como nodos en el modelo navegacional  Los que ofrecen un soporte computacional a la aplicación web  Encapsulan comportamiento como algoritmos, acceso a bases de datos…  Este modelo puede servir como base a muchas aplicaciones y no incluye ninguna información específica de navegación  Esto es una clara diferencia con EORM (Lange, 1996) Ing. Aldo Hernan Zanabria Galvez 93
  • 94. OOHDM  OOHDM (Object-Oriented Hypermedia Design Method) (Schwabe y Rossi, 1995; Rossi, 1996)  El concepto de contexto navegacional se introduce para describir la estructura de navegación  Permite diferentes agrupaciones de objetos navegacionales con el propósito de navegar por ellos en diferentes contextos  El acceso a estos elementos navegacionales se modela mediante estructuras de acceso, como índices por ejemplo  Se utiliza una notación propia para la representación del esquema del contexto navegacional  El modelo de interfaz abstracta es el resultado de especificar los objetos de interfaz que el usuario percibe  OOHDM utiliza ADVs (Abstract Data Views) para modelar los aspectos estáticos de la interfaz de usuario, utilizando diagramas de transición de estados para modelar los aspectos dinámicos Ing. Aldo Hernan Zanabria Galvez 94
  • 95. OOHDM Relación entre los objetos conceptuales, navegacionales y de interfaz propios de OOHDM. Las clases navegacionales son vistas sobre las clases conceptuales. Los objetos de interfaz median la interacción de los objetos navegacionales con el mundo exterior, incluyendo a los usuarios Ing. Aldo Hernan Zanabria Galvez 95
  • 96. OOHDM Modelo conceptual de una revista en línea (Schwabe y Rossi, 1998 Ing. Aldo Hernan Zanabria Galvez 96
  • 97. OOHDM  Llamar la atención de que la clase Person no aparece; los Atributos del autor son parte de Story. Lo mismo sucede con la persona que ofrece una entrevista Modelo navegacional de una revista en línea (Schwabe y Rossi, 1998) Ing. Aldo Hernan Zanabria Galvez 97
  • 98.  Un número de la revista está formado por historias que están agrupadas de acuerdo a diferentes criterios Esquema del contexto navegacional de una revista en línea (Schwabe y Rossi, 1998) Indices Contexto de grupo Contexto simple Ing. Aldo Hernan Zanabria Galvez 98
  • 99. OOWS  OOWS (Object-Oriented Approach for Web Solutions  Modeling) (Pastor et al., 2001a)  Método de desarrollo de aplicaciones web que extiende OO-Method (Pastor et al., 2001b)  Se introducen nuevas características navegacionales  Notación basada en UML (OMG, 2004) Dos grandes fases  Especificación Conceptual  Generación Automática Ing. Aldo Hernan Zanabria Galvez 99
  • 100. OO-HMethod  OO-HMethod (Gómez et al., 2000; Cachero et al., 2000)  Método genérico para el desarrollo de la estructura semántica de las aplicaciones web  Se centra en las actividades globales (authoring in the large), esto es, en las clases y estructuras  Se despreocupa del contenido de los nodos de información (authoring in the small)  Extiende OO-Method (Pastor et al., 2001b)  Extiende la notación para expresar un modelo abstracto de interfaz de usuario  Se captura la información a que cada tipo de usuario (agente) puede acceder, así como los caminos de navegación entre vistas de información  El desarrollo de una aplicación web se aborda tanto a nivel conceptual como a nivel de ejecución  El modelo de navegación se captura en el NAD (Navigation Access Diagram)  La estructura y visualización de la interfaz se expresan en el APD (Abstract Presentation Diagram) Ing. Aldo Hernan Zanabria Galvez 100
  • 101. OO-HMethod  OO-HMethod (Gómez et al., 2000; Cachero et al., 2000)  Tanto el NAD como el APD capturan la información relevante gracias a un conjunto de patrones definidos en el Catálogo de patrones de OO- HMethod (Cachero et al., 2000)  La diferencia principal entre OO-HMethod y OOWS es que este último es un extensión plena de OO-Method  OOWS incluye completamente la especificación funcional, mientras que  OO-HMethod sólo especifica la interfaz Otra diferencia aparece en el modelo de navegación, concretamente en el concepto de nodo  OO-HMethod asocia diferentes diagramas de acceso a cada tipo de usuario, pero los nodos (clases de navegación) se limitan a presentar información de una sola clase  Los nodos en OOWS (contextos navegacionales) pueden trabajar con vistas de varias clases, mostrando la información apropiada para el usuario en cada momento Ing. Aldo Hernan Zanabria Galvez 101
  • 102. SOHDM  SOHDM (Scenario-based Object-oriented Hypermedia Design Methodology) (Lee et al., 1998)  Comprende seis fases  Análisis de dominio  Modelado de objetos  Diseño de vistas  Diseño de navegación Diseño de la implementación  Construcción  Tiene similitudes con RMM (Isakowitz et al., 1995), EORM (Lange, 1996) y con OOHDM (Schwabe y Rossi, 1998)  Difiere en que usa escenarios  Los escenarios se definen en el análisis de dominio y se utilizan para el modelado de objetos Ing. Aldo Hernan Zanabria Galvez 102
  • 103. SOHDM  SOHDM (Scenario-based Object-oriented Hypermedia Design Methodology) (Lee et al., 1998)  El diseño de vistas consiste en determinar vistas que vienen generadas de un única clase o de asociaciones entre clases  Las vistas son similares a los contextos de OOHDM  Hay tres clases de vistas  Vistas base  Se genera de una única clase  Vistas de asociación  Se extrae de una relación de asociación  Vistas de colaboración  Proviene de una relación de colaboración  El diseño de la navegación emplea escenarios para determinar la estructura de los nodos  Las estructuras de acceso a los nodos (ASN – Access Structure Nodes), junto con las vistas, se denominan unidades de navegación  Las ASNs son similares a las primitivas de acceso de RMM  Este método define su propia notación gráfica Ing. Aldo Hernan Zanabria Galvez 103
  • 104. WSDM  WSDN (Web Site Design Method) (De Troyer y Leune, 1997)  Aproximación centrada en el usuario que define objetos de información basándose en los requisitos de información de los usuarios de una aplicación web  Conlleva tres fases principales  Modelado de usuario  Diseño conceptual  Diseño de la implementación  Modelado de usuario  Los usuarios de la aplicación web se identifican y se clasifican de acuerdo a sus intereses y preferencias de navegación  El punto de comienzo es la descripción del dominio, teniendo en cuenta las actividades de usuario  Cada perfil de usuario potencial es descubierto y se plasma en una clase Ing. Aldo Hernan Zanabria Galvez 104
  • 105. WSDM  WSDN (Web Site Design Method) (De Troyer y Leune, 1997)  Diseño conceptual  Dos fases  Modelado de objetos  El modelado de objetos conlleva tres pasos: modelado de objetos de negocio, modelado de objetos de usuario y modelado de objetos de perspectivas  Diseño navegacional  El modelo navegacional consiste en un número de caminos de navegación, una por cada perspectiva, expresando cómo los usuarios de un perspectiva particular pueden navegar a través de la información disponible  Se describe en término de componentes y enlaces Se distinguen tres tipos de componentes: navegación, información y externos  Cada camino de navegación tienes tres capas: contexto, navegación e información  Este tipo de diseño de navegación provoca aplicaciones con una estructura muy jerárquica  Diseño de la implementación  Crea un look&feel eficiente y consistente con el modelo conceptual  Se dan pocas recomendaciones en este apartado  Combina una notación propia con OMT (Rumbaugh et al., 1991) Ing. Aldo Hernan Zanabria Galvez 105
  • 106. HFPM  HFPM (Hypermedia Flexible Process Modeling) (Olsina, 1998)  Abarca las siguientes vistas o perspectivas del proceso de desarrollo de una aplicación web  Vista funcional  Conjunto de fases y actividades para desarrollar tareas (encontrar usuarios, clases, casos de usos…)  Vista metodológica  Define un conjunto de constructores de proceso para aplicarlos a diferentes actividades (análisis conducido por casos de uso, diseño conceptual y de navegación basado en OOHDM…)  Vista de información  Para producir un conjunto de artefactos (modelo de navegación, modelo físico…) que se requieren en diversas tareas  Vista de comportamiento  Representa la parte dinámica del modelo de proceso, tomando decisiones sobre la secuencia y la sincronización de tareas, iteraciones, incrementos…  Vista organizacional  Define aspectos tales como roles, organización de equipos, mecanismos de Comunicación… Ing. Aldo Hernan Zanabria Galvez 106
  • 107. HFPM  HFPM (Hypermedia Flexible Process Modeling) (Olsina, 1998)  La lista de tareas que prescribe esta metodología para el desarrollo de una aplicación web son  Modelado de requisitos del software  Planificación del proyecto  Modelado conceptual  Modelado de la navegación  Modelado de la interfaz abstracta  Empleo de patrones de diseño  Captura y edición de los datos multimedia  Modelado físico  Validación y verificación  Empleo de criterios cognitivos  Aseguramiento de la calidad  Gestión y coordinación del proyecto  Documentación  Cubre todas las fases y actividades esenciales de un proyecto hipermedia  La notación se basa en OOHDM Ing. Aldo Hernan Zanabria Galvez 107
  • 108. OO/Pattern  OO/Pattern (Thomson et al., 1998)  Similar a HFPM (Olsina, 1998)  Propone utilizar diseño OO y patrones para el diseño de la navegación y de la presentación  Difiere de HFPM en que no cubre todo el ciclo de vida de una aplicación web  No se incluyen aspectos de gestión de proyectos, prueba y mantenimiento  La utilización de patrones presenta interesantes ventajas  Proceso bien definido  La documentación puede ser reutilizada  Se facilita el mantenimiento Ing. Aldo Hernan Zanabria Galvez 108
  • 109. OO/Pattern  OO/Pattern (Thomson et al., 1998)  Presenta los siguientes pasos  Casos de uso  Diseño conceptual  Diseño de colaboraciones  Definición de clases Diseño de la navegación  Implementación  Elementos innovadores  Análisis de casos de uso para diferentes tipos de usuarios  Diseño de colaboraciones basándose en los casos de uso definidos y en el diseño conceptual  Diseño de la navegación basada en patrones Ing. Aldo Hernan Zanabria Galvez 109
  • 110. WAE  WAE (Web Application Extension for UML) (Conallen, 1999)  Incluye estereotipos UML para el modelado de elementos arquitectónicos específicos de la Web  El proceso propuesto está basado en RUP (Rational Unified Process) (Kruchten, 2000)  Proceso centrado en la arquitectura y la implementación (incluye ingeniería inversa), pero ofrece poco soporte sistemático a la construcción de la estructura de navegación de la aplicación web, así como a sus aspectos de presentación Ing. Aldo Hernan Zanabria Galvez 110
  • 111. UWE  UWE (UML-based Web Engineering) (Koch, 2000; Hennicker y Koch, 2000)  Soporta desarrollo de aplicaciones web prestando especial atención en sistematización y personalización (sistemas adaptativos)  Consiste en una notación y en un método  La notación se basa en UML (OMG, 2004)  Para aplicaciones web en general y para aplicaciones adaptativas en particular  El método consta de seis modelos  Modelo de casos de uso para capturar los requisitos del sistema  Modelo conceptual para el contenido (modelo del dominio)  Modelo de usuario  Modelo de navegación que incluye modelos estáticos y dinámicos  Modelo de estructura de presentación, modelo de flujo de presentación, modelo abstracto de interfaz de usuario y modelo de ciclo de vida del objeto  Modelo de adaptación Ing. Aldo Hernan Zanabria Galvez 111
  • 112. OOWS: UN MÉTODO DE INGENIERÍA WEB Ing. Aldo Hernan Zanabria Galvez 112
  • 113. Objetivos Ing. Aldo Hernan Zanabria Galvez 113
  • 114. Objetivos  Técnicas de Modelado Conceptual proporcionan un enfoque metodológico y sistemático a la especificación de aplicaciones tradicionales  Los métodos de diseño orientados a objetos que utilizan técnicas de modelado conceptual no proporcionan primitivas para especificación de la navegación, presentación...  ¿Cómo elicitar y representar la semántica navegacional en modelos conceptuales?  Ampliar la etapa de Modelado Conceptual introduciendo los  Modelos de Navegación y de Presentación Ing. Aldo Hernan Zanabria Galvez 114
  • 115. Objetivo: Un método para la construcción aplicaciones web ... y la ejecución de servicios Permita capturar la navegación ... ... tratar la visualización de información ... ... especificar búsquedas Ing. Aldo Hernan Zanabria Galvez 115
  • 116. ¿Qué es OOWS?  OOWS (Object-Oriented Approach for Web Solutions Modeling) (Pastor et al., 2001a)  Una aproximación para definir semántica de navegación en modelos Orientados a Objeto  Ampliación de un Método OO de producción de software “tradicional”, llamado OO-Method Utiliza la notación UML (adaptada)  Extiende el proceso de desarrollo de sistemas software propuesto por OO-Method (Pastor et al., 2001b)  Define primitivas navegacionales y de presentación de información integradas en el Modelado Conceptual OO-Method Ing. Aldo Hernan Zanabria Galvez 116
  • 117. OOWS. Proceso de desarrollo  El método OOWS extiende el proceso de desarrollo definido por OO-Method  Incluye nuevas etapas donde se captan los requisitos de navegación y presentación de información  Dos grandes fases 1. Especificación Conceptual, se construye una especificación completa del sistema, Esquema Conceptual 2. Generación Automática, a partir de la especificación se construye una solución software funcionalmente equivalente basada en patrones de traducción Ing. Aldo Hernan Zanabria Galvez 117
  • 118. OOWS. Proceso de desarrollo Modelado Conceptual  La fase de Modelado Conceptual abarca  1. Especificación de Requisitos  Usa notación UML (Casos de Uso)  Recoge  La funcionalidad que debe proporcionar el sistema  Los diferentes tipos de usuarios que pueden interactuar con el sistema  La asociación de usuarios-funcionalidad  Sirve como base para la construcción del Esquema Conceptual Ing. Aldo Hernan Zanabria Galvez 118
  • 119. OOWS. Proceso de desarrollo Modelado Conceptual Modelado Conceptual  Se construyen a partir de la especificación de requisitos los modelos Ing. Aldo Hernan Zanabria Galvez 119
  • 120. OOWS. Proceso de desarrollo Ing. Aldo Hernan Zanabria Galvez 120
  • 121. Propuesta Metodológica Ing. Aldo Hernan Zanabria Galvez 121
  • 122. Esquema conceptual Ing. Aldo Hernan Zanabria Galvez 122
  • 123. Modelo de navegación  Especificación de las características navegacionales de una aplicación web  En base a un Modelo de Objetos y a los requisitos de navegación  Utiliza una notación basada en UML  Se construye a partir de las primitivas de abstracción navegacionales  Representación de la Navegación  Especificación de Búsquedas  Tratamiento de la visualización de la información (presentación)  Ejecución de Servicios  Personalización de información de los distintos usuarios  Integrado con las restantes vistas del esquema conceptual  Define y estructura el acceso de los diferentes usuarios con el sistema, en función de su objetivo  Considera el punto de vista de cada perfil de usuario identificado previamente en el Modelo de Objetos Ing. Aldo Hernan Zanabria Galvez 123
  • 124. Modelo de navegación  Construye un grafo navegacional asociado a cada usuario formado por  Nodos  Unidades de interacción que proporcionan acceso a datos y funcionalidad relevante para el usuario  Enlaces  Relación de alcance entre nodos para conseguir cierto objetivo Navegación es el cambio de nodo conceptual al activar un enlace navegacional Ing. Aldo Hernan Zanabria Galvez 124
  • 125. Modelado de navegación Ing. Aldo Hernan Zanabria Galvez 125
  • 126. Modelo de Navegación  Primitivas de Abstracción Básicas  Mapa Navegacional  “Visión Global de una aplicación web según un perfil de usuario”  Contexto de Navegación  “Conjuntos de objetos que el usuario irá navegar”  Vínculo de Navegación  “Indica la navegación entre contextos de navegación”  Clase Navegacional  “Contenido de la información por el cual los usuarios navegarán”  Relaciones  “Maneras de navegar para acceder al contenido de la información” Ing. Aldo Hernan Zanabria Galvez 126
  • 127. Primitivas de abstracción. Mapa de navegación  El Modelo de Navegación está compuesto por un conjunto de mapas de navegación  Define el sitio web  Asociado a un agente del Modelo Conceptual  Visión global del sistema para cada tipo de usuario  Grafo Navegacional formado por  Contextos de Navegación (nodos)  Vínculos Navegacionales (arcos) Ing. Aldo Hernan Zanabria Galvez 127
  • 128. Mapa de navegación Ing. Aldo Hernan Zanabria Galvez 128
  • 129. Primitivas de abstracción. Contexto Navegacional  Unidad de Interacción Abstracta básica con el usuario  Representa una vista parcial del sistema adecuada para una determinada actividad  Es el punto de vista que un usuario tiene de un subconjunto del modelo de objetos  Proporciona acceso a datos y funcionalidad asociados con el usuario propietario del mapa  Está compuesto por  Clases navegacionales: Recuperan información del sistema  Relaciones navegacionales: Complementan la información de las clases navegacionales  Gráficamente es un paquete UML estereotipado con la palabra reservada «context» Ing. Aldo Hernan Zanabria Galvez 129
  • 130. Primitivas de abstracción. Contexto Navegacional Ing. Aldo Hernan Zanabria Galvez 130
  • 131. Primitivas de abstracción. Contexto Navegacional  Los contextos tienen un carácter navegacional que permite estructurar la navegación por el sistema  El carácter de los contextos pueden ser  Secuencia: Sólo son accesibles siguiendo uno de los caminos de navegación especificados  Exploración: Son accesibles desde cualquier ubicación en la aplicación Ing. Aldo Hernan Zanabria Galvez 131
  • 132. Primitivas de abstracción. Vínculo Navegacional  Define una relación de alcance (navegación) entre  Contextos de Navegación  Definido implícitamente a partir de las relaciones navegacionales definidas dentro de los contextos y por el carácter de los contextos (de exploración o de secuencia) Ing. Aldo Hernan Zanabria Galvez 132
  • 133. Modelo de Navegación. Ejemplo de mapa navegacional Contextos de Navegación Vínculos de Navegación Ing. Aldo Hernan Zanabria Galvez 133
  • 134. Primitivas de abstracción. Clase Navegacional  Proyecciones de visibilidad sobre clases existentes en el Modelo de Objetos con respecto a  Atributos: Datos del sistema visibles que por el usuario  Servicios: Funcionalidad ejecutable por el usuario  Gráficamente son clases UML estereotipadas con la palabra reservada « view » Ing. Aldo Hernan Zanabria Galvez 134
  • 135. Primitivas de abstracción. Clase Navegacional  Existen de dos tipos  Clase Directora: Es la clase principal de un contexto. Existe una única por contexto (obligatoria). El contexto se centra en presentar información y funcionalidad de esta clase  Clases Complementarias: Su utilidad es complementar la información de la clase directora. Pueden aparecer varias por contexto (no son obligatorias) Ing. Aldo Hernan Zanabria Galvez 135
  • 136. Primitivas de abstracción. Relación Navegacional  Es una relación binaria unidireccional existente entre dos clases de un contexto  Se define sobre una relación agregación o herencia entre dos clases del Modelo de Objetos  Complementa la información sobre la clase de la cual parte la relación, recuperando la población relacionada  Dos tipos  Relaciones de Dependencia Contextual  Relaciones de Contexto Ing. Aldo Hernan Zanabria Galvez 136
  • 137. Primitivas de abstracción. Relación Navegacional  Relación de Dependencia Contextual  Indica la existencia de una relación entre dos clases de un contexto, pero no define una semántica navegacional entre ellas  Complementa la clase navegacional origen con su población relacionada  Indica una recuperación de información relacionada de las instancias de la clase complementaria  Gráficamente se representa mediante una línea discontinua Ing. Aldo Hernan Zanabria Galvez 137
  • 138. Primitivas de abstracción. Relación Navegacional  Relación de Contexto  Complementa la clase navegacional origen con su población relacionada  Define un vínculo navegacional entre contextos, indicando la dirección de navegación  Implica necesariamente la existencia de un contexto navegacional  (destino) en el que la clase directora es la clase destino de la relación  Gráficamente se representa mediante una línea continua Ing. Aldo Hernan Zanabria Galvez 138
  • 139. Primitivas de abstracción. Relación Navegacional  Las relaciones navegacionales poseen atributos adicionales  Atributo de contexto: Contexto de navegación destino del enlace  Atributo de enlace: Atributo que se usará en la conexión con la clase destino. Es opcional  Atributo de rol: Nombre de la relación estructural en el Modelo de Objetos a la que se refiere la relación. Sólo es necesario en caso de ambigüedad -- Cuando exista más de una relación entre dos clases en el Modelo de Objetos Ing. Aldo Hernan Zanabria Galvez 139
  • 140. Modelo de Navegación. Ejemplo de relación de contexto Ing. Aldo Hernan Zanabria Galvez 140
  • 141. Construcción del Modelo de Navegación INPUT: Modelo Conceptual + Requisitos Navegación OUTPUT: Modelo de Navegación  1. Identificación de los agentes del Sistema y sus relaciones (herencia) entre sí, en base al Modelo de Objetos definido  2. Construcción de los mapas navegacionales para cada agente detectado, según los requisitos de navegación. Se pueden reutilizar contextos por relaciones entre agentes Ing. Aldo Hernan Zanabria Galvez 141
  • 142. Construcción del Modelo de Navegación 1. Identificación de Agentes  Buscar en el Modelo de Objetos los agentes del sistema  Detectar las relaciones entre los agentes (reutilización navegacional)  Construir los árboles de agentes, donde aparece cada agente y sus relaciones con los demás  Estos árboles están compuestos de  Agentes/Clases Base  Agentes/SubClases Ing. Aldo Hernan Zanabria Galvez 142
  • 143. Construcción del Modelo de Navegación 2. Construcción de los Mapas  El Modelo de Navegación está compuesto por los Mapas Navegacionales definidos  Se pueden seguir dos estrategias para la construcción del Modelo de Navegación  Top-Down: Para cada agente, se da un boceto del mapa navegacional y siguiendo su estructura se refina cada contexto declarado  Bottom-Up: Para cada agente, se construyen las piezas básicas (contextos) y a partir de éstas se obtiene su mapa navegacional Ing. Aldo Hernan Zanabria Galvez 143
  • 144. Construcción del Modelo de Navegación 2. Construcción de los Mapas  Estrategia Top-Down  Para cada Agente  Se define un mapa de navegación abstracto  Se declaran los contextos navegacionales que existirán y las relaciones de alcance entre ellos  Se hereda el Mapa de Navegación del agente/Clase Base si el actual es un agente/SubClase, se modifica y extiende  Se refina cada contexto en base al mapa de navegación propuesto  El Mapa de Navegación se construye de manera explícita y se va refinando a medida que se construyen los contextos Ing. Aldo Hernan Zanabria Galvez 144
  • 145. Construcción del Modelo de Navegación 2. Construcción de los Mapas  Estrategia Bottom-Up  Para cada Agente  Construir los contextos de navegación que capturen los requisitos de navegación detectados (en la especificación de requisitos del sistema)  Para los Agente/SubClase  Se hereda el Mapa Navegacional de su clase base y se modifica y extiende  El Mapa de Navegación para cada agente se construye automáticamente a partir de los contextos especificados Ing. Aldo Hernan Zanabria Galvez 145
  • 146. Construcción del Modelo de Navegación 2. Construcción de los Mapas Ing. Aldo Hernan Zanabria Galvez 146
  • 147. Modelo de Presentación  Tras la especificación del Modelo de Navegación se construye el Modelo de Presentación  Este modelo recoge la semántica de presentación de  información del sistema  Se basa en definir el modo de presentación asociado a cada UIA (Unidad de Interacción Abstracta) definida por el Modelo de Navegación  Asocia patrones de presentación a los elementos que aparecen en estos nodos navegacionales Ing. Aldo Hernan Zanabria Galvez 147
  • 148. Modelo de Presentación. Patrones de presentación  Patrón de Presentación  Define la estructura lógica de presentación de información a la población a que se aplica  Se puede aplicar a  Clase Directora  Relaciones Navegacionales  Cuatro tipos, en función de las cardinalidades y el tipo de las relaciones interobjetuales Ing. Aldo Hernan Zanabria Galvez 148
  • 149. Modelo de Presentación. Patrones de presentación  Patrón de Criterio de Ordenación  Permite definir una ordenación de la población de una clase atendiendo a un criterio  Este criterio deberá estar en función de propiedades (atributos) de alguna clase del contexto  Se puede aplicar a  Clases Navegacionales, indicando cómo se recuperarán las instancias de estas clases  Estructuras de Acceso y Mecanismos de Búsqueda, para ordenar los resultados obtenidos  Existen de dos tipos: Ascendente y Descendente  En caso de especificación de varios atributos, la ordenación es jerárquica Ing. Aldo Hernan Zanabria Galvez 149
  • 150. Modelo de Presentación. Patrones de presentación  Patrón de Paginación  Define un scrolling de información, creando bloques lógicos en los que las instancias son “troceadas”  Se especifica una cardinalidad, o número de instancias a recuperar  Puede ser estática o dinámica, en función de si el usuario puede o no modificar la cardinalidad  Existen dos tipos  De acceso secuencial, cuando desde un bloque lógico sólo se puede ir al siguiente, al anterior, al primero o al último  De acceso aleatorio, cuando desde un bloque lógico se puede acceder directamente a cualquier otro  Se puede definir como circular, indicando que el siguiente bloque lógico al último es el primero y viceversa  Se aplica a  A la clase directora: Permite restringir el número de instancias de la clase principal que se recuperarán  A las relaciones navegacionales: Restringiendo el número de instancias de objetos relacionados que se recuperarán Ing. Aldo Hernan Zanabria Galvez 150
  • 151. Modelo de Presentación. Patrones de presentación Ing. Aldo Hernan Zanabria Galvez 151 Criterio de Ordenación Ascendente Paginación aplicada a una relación navegacional. Se recuperan objetos secuencialmente en grupos de 5
  • 152. Caso de estudio OOWS  Tienda virtual de venta de discos DiscoWeb (Fons et al., 2002) Ing. Aldo Hernan Zanabria Galvez 152
  • 153. Caso de estudio OOWS Ing. Aldo Hernan Zanabria Galvez 153
  • 154. Caso de estudio OOWS Ing. Aldo Hernan Zanabria Galvez 154
  • 155. Caso de estudio OOWS Ing. Aldo Hernan Zanabria Galvez 155
  • 156. 1. INTRODUCCIÓN Proceso Software en la Ingeniería Web 156
  • 157. Ideas generales  Para una mejor gestión de la construcción de un sistema Web, y buscando que se haga de una forma sistemática, se necesita contar con un proceso que conste de varias fases, pasos y actividades para el desarrollo de aplicaciones Web  El proceso software separa el desarrollo de una aplicación Web en partes manejables, ofreciendo técnicas que facilitan la gestión de un proyecto Web completo  Algunas de las características de los sistemas Web dificultan su desarrollo  Interacción en tiempo real, información personalizada, complejidad, alta capacidad de cambio  A lo que hay que añadir la dificultad de estimar el tiempo y el esfuerzo con un error razonable 157
  • 158. Ideas generales  Un proceso ayuda a  Abordar las dificultades  Minimizar los riesgos del desarrollo  Facilitar la evolución y el cambio  Implantar y explotar las aplicaciones Web  Proporcionar una realimentación imprescindible para continuar con el proyecto 158
  • 159. Pasos clave para el desarrollo de una aplicación Web  Comprender la función global del sistema y el contexto de operación, incluyendo los objetivos de negocio y los requisitos  Identificar claramente a las personas involucradas, esto es, a sus usuarios principales, a la organización que necesita el sistema, y aquellos que financian el desarrollo del sistema  Especificar los requisitos técnicos y no técnicos de los involucrados y del sistema en general  Desarrollar una arquitectura global del sistema Web que cumpla con los requisitos técnicos y no técnicos  Identificar los subproyectos y los subprocesos para implementar la arquitectura. Si los subproyectos son complejos de gestionar, se deben subdividir a su vez hasta conseguir un conjunto de tareas manejables  Desarrollar e implementar los subproyectos  Incorporar mecanismos efectivos para gestionar la evolución, el cambio y el mantenimiento del sistema Web. Cuando el sistema evolucione, repetir el proceso global o aquellas partes que se requieran  Abordar los problemas no técnicos tales como la revisión de los procesos de negocio, las políticas de gestión u organización, recursos humanos, y los aspectos legales, culturales y sociales  Medir el rendimiento del sistema  Refinar y actualizar el sistema 159 (Ginige y Murugesan, 2001)
  • 160. Fases del ciclo de desarrollo en la Ingeniería Web  Una aplicación Web, con sus características intrínsecas, tiene un ciclo de desarrollo, como cualquier otro producto software, en el que se van a encontrar las fases de ingeniería típicas  Definición y análisis de los sistemas Web  Diseño de los sistemas Web  Diseño arquitectónico  Diseño de la navegación  Diseño de la interfaz  Pruebas de las aplicaciones Web 160
  • 161. Fases del ciclo de desarrollo en la Ingeniería Web  Diseño de la navegación  Identifica la semántica de la navegación para los diferentes usuarios del sitio, además de definir la mecánica para lograr la navegación (Pressman, 2000)  Una aplicación puede tener un conjunto de roles que representan a los usuarios del sistema  Cada rol puede asociarse a diferentes niveles de acceso tanto al contenido como a los servicios de forma que la semántica de cada rol será diferente  Se definen Unidades Semánticas de Navegación (USN) para cada meta asociada a un rol  Cada USN tiene un conjunto de Formas de Navegación (FdN)  Una FdN representa la mejor manera de navegación o ruta para que los usuarios con ciertos perfiles logren su meta  Cada FdN se compone de Nodos de Navegación (NN) conectados a través de enlaces de navegación, entre los que puede haber USNs 161
  • 162. 2. Proceso iterativo e incremental para la Ingeniería Web 162
  • 163. Proceso iterativo e incremental para la Ingeniería Web  R. S. Pressman (2000) propone un proceso para la Ingeniería Web basado en el modelo en espiral de Boehm (1986) 163 Planificación Análisis Ingeniería Generación de páginas y pruebas Evaluación del cliente Formulación Diseño del contenido Diseño arquitectónico Producción Diseño de la navegación Diseño de la interfaz
  • 164. Proceso iterativo e incremental para la Ingeniería Web  Formulación: identificación de metas y objetivos  Planificación: estimación de costes, evaluación de riesgos y planificación temporal del proyecto  Análisis: establecimiento de requisitos  Ingeniería: dos grupos de tareas paralelas,  Técnicas (diseño arquitectónico, de navegación y de interfaz)  No técnicas (diseño del contenido y producción)  Generación de páginas y pruebas  El contenido se fusiona con los diseños arquitectónico, de navegación y de interfaz para elaborar páginas web ejecutables en HTML, JSP...  Integración con el software intermedio (middleware) de componentes  Evaluación con el cliente: revisión de cada incremento y solicitud de cambios 164
  • 166. Orígenes del Proceso Unificado 166 Enfoque de Rational Otras fuentes Proceso Unificado de Rational 5.0 1998 Proceso Objectory de Rational 4.1 1996-1997 Proceso Objectory 1.0-3.8 1987-1995 Enfoque de Ericsson UML Enfoque de Rational Otras fuentes Proceso Unificado de Rational 5.0 1998 Proceso Objectory de Rational 4.1 1996-1997 Proceso Objectory 1.0-3.8 1987-1995 Enfoque de Ericsson UML Jacobson et al. Jacobson, Booch y Rumbaugh
  • 167. Introducción  Características generales  Está basado en componentes  Utiliza UML  Características principales  Es un proceso conducido por casos de uso  Está centrado en la arquitectura  Es iterativo e incremental 167 El Proceso Unificado es más que un simple proceso (Jacobson et al., 1999), es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos
  • 168. Introducción  Un proceso de desarrollo de software: conjunto de actividades necesarias para transformar los requisitos de usuario en un sistema de software  Un marco de trabajo genérico que puede extenderse y especializarse para una gran variedad de sistemas de software  Está basado en componentes  Permite gran variedad de estrategias de ciclo de vida 168
  • 169. Introducción  Selecciona qué artefactos producir  Define actividades y trabajadores  Modela conceptos 169 Describe un caso de uso Paquete de casos de uso Caso de uso Responsable de Analista Artefacto Actividad
  • 170. UML en el Proceso Unificado 170 Proceso de desarrollo que incluye las actividades del ciclo de vida que producen modelos UML
  • 171. UML en el Proceso Unificado 171 ¿Por qué UML no es suficiente?  UML es sólo un lenguaje y, por tanto, no es ni una metodología ni un método, sino que está pensado para ser parte de un método de desarrollo de software, siendo independiente del proceso
  • 172. Características principales  Conducido por casos de uso  Centrado en la arquitectura  Iterativo e Incremental 172 Los casos de uso especifican la función, la arquitectura especifica la forma La arquitectura y los casos de uso deben estar equilibrados Casos de uso Arquitectura
  • 173. Características principales  Conducido por casos de uso: Los casos de usos guían el desarrollo del sistema. Como los casos de uso contienen las descripciones de las funciones, afectan a todas las fases y vistas  Centrado en la arquitectura: La arquitectura se representa mediante vistas del modelo. Se puede tomar como arquitectura de referencia el denominado modelo de arquitectura de 4+1 vistas propuesto por Philippe Kruchten  Iterativo e Incremental: En cada iteración se identifican y especifican los casos de uso relevantes, se crea un diseño basado en la arquitectura seleccionada, se implementa el diseño mediante componentes y se verifica que los componentes satisfacen los casos de uso. Si una iteración cumple con sus objetivos se pasa a la siguiente. Encada iteración se va desarrollando el sistema de forma incremental 173
  • 174. La vida del Proceso Unificado  El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema  Cada ciclo concluye con una versión del producto  Cada ciclo consta de cuatro fases  Inicio: se define el alcance del proyecto y se desarrollan los casos de negocio  Elaboración: se planifica el proyecto, se especifican en detalle la mayoría de los casos de uso y se diseña la arquitectura del sistema  Construcción: se construye el producto  Transición: el producto se convierte en versión beta. Se corrigen problemas y se incorporan mejoras sugeridas en la revisión 174
  • 175. La vida del Proceso Unificado 175 Etapa de Ingeniería Etapa de Producción Visión Arquitectura Versiones Beta Productos Inicio Elaboración Construcción Transición Iteratividad
  • 176. La vida del Proceso Unificado 176 tiempotiempo VistaVista Línea base de arquitectura Línea base de arquitectura Capacidad inicial Capacidad inicial Versión del producto Versión del producto Inicio Elaboración Construcción Transición VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión VersiónVersión Arqu. Iteración ... Des. Iteración Des. Iteración ... Trans. Iteración ...Prelim Iteración ... Inicio Elaboración Construcción Transición Arqu. Iteración ... Des. Iteración Des. Iteración ... Trans. Iteración ...Prelim Iteración ... Inicio Elaboración Construcción Transición
  • 177. La vida del Proceso Unificado Inicio Elaboración Construcción Transición Etapa de Ingeniería Etapa de producción Requisitos Diseño Implementación Instalación Gestión Requisitos Diseño Implementación Instalación Gestión Requisitos Diseño Implementación Instalación Gestión Requisitos Diseño Implementación Instalación Gestión Visión Arquitectura Versiones Beta ProductosVisión Arquitectura Versiones Beta Productos 177 Incremental
  • 178. La vida del Proceso Unificado  Iteraciones y flujo de trabajo  Dentro de cada fase se puede, a su vez, descomponer el trabajo en iteraciones con sus incrementos resultantes  Cada fase termina con un hito, cada uno de los cuales se caracteriza por la disponibilidad de un conjunto de componentes de software  Objetivos de los hitos  Toma de decisiones para continuar con la siguiente fase  Controlar el progreso del proyecto  Proporcionar información para la estimación de tiempo y recursos de proyectos sucesivos  Las iteraciones discurren a lo largo de los flujos de trabajo 178
  • 179. Ciclo de vida del Proceso Unificado 179 iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 Fases Requisitos Diseño Implementación Pruebas Análisis Flujos de trabajo Iteraciones Iteraciones preliminares Inicio Elaboración Construcción Transición
  • 180. El producto  El producto que se obtiene es un sistema de software  El sistema lo componen todos los “artefactos” necesarios para representarlo de forma comprensible  Artefactos: Término general para cualquier tipo de información creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Pueden ser  De ingeniería  De gestión  El artefacto más importante del Proceso Unificado es el modelo  Un sistema posee una colección de modelos y las relaciones entre ellos 180
  • 181. El producto  Los modelos recogen diferentes perspectivas del sistema (perspectivas de todos los trabajadores) 181 Un modelo es una abstracción semánticamente cerrada del sistema Sistema Arquitecto Usuarios Analistas Jefe de proyecto Ingenieros de pruebas Diseñadores
  • 182. El producto  Existen dependencias entre el modelo de casos de uso y los demás modelos 182 Modelo de casos de uso Modelo de diseño Modelo de despliegue Modelo de pruebas Modelo de implementation Modelo de Análisis Especificado por Realizado por Distribuido por Implementado por Verificado por
  • 183. El producto  Modelos  Modelo de casos de uso: diagramas de casos de uso, secuencia, colaboración y actividad  Modelos de análisis y diseño: diagramas de clases, objetos, secuencia, colaboración y actividad  Modelo de despliegue: diagramas despliegue, secuencia y colaboración  Modelo de implementación: diagramas de componentes, secuencia y colaboración  Modelo de pruebas: todos los diagramas 183
  • 184. El proceso  El proceso hace referencia a un contexto que sirve como plantilla que pueda reutilizarse para crear instancias de ella (proyectos)  Las actividades relacionadas conforman flujos de trabajo  Su identificación parte de la identificación de los trabajadores y de los artefactos para cada tipo de trabajador  Describen como fluye el proceso a través de los trabajadores 184 El proceso de desarrollo de software es una definición de un conjunto completo de actividades necesarias para convertir los requisitos de usuario en un conjunto consistente de artefactos que conforman un producto software, y para convertir los cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos
  • 185. El proceso  Representación de flujos de trabajo mediante calles 185 Analista de sistemas Identificar actores y casos de uso Estructurar el modelo de casos de uso Arquitecto Priorizar casos de uso Especificador de casos de uso Detallar casos de uso Diseñador de interfaz de usuario Esbozar interfaz de usuario Flujo de trabajo del modelado de casos de uso Actividades Calles
  • 186. El proceso  Un flujo de trabajo es un estereotipo de colaboración en el que los artefactos y los trabajadores son los participantes  Ejemplo  Flujo de trabajo de requisitos  Trabajadores: analista de sistemas, arquitecto...  Artefactos: modelo de casos de uso, casos de uso...  La notación “en forma de pez” es la abreviatura de un flujo de trabajo 186 Requisitos Una colaboración de trabajadores y artefactos utilizada para describir el flujo de Requisitos del proceso
  • 187. El proceso Procesos especializados  El Proceso unificado se puede especializar para cumplir diferentes necesidades de aplicación o de organización  Los factores que influyen en la forma de especialización  Organizativos: estructura y cultura de la empresa, organización del proyecto, aptitudes y habilidades disponibles, experiencia...  Del dominio: procesos de negocio que se deben soportar, comunidad de usuarios, ofertas de la competencia  Del ciclo de vida: tiempo de salida al mercado, tiempo de vida esperado, tecnología y experiencia en el desarrollo, versiones...  Factores técnicos: lenguaje de programación, herramientas de desarrollo, base de datos, comunicaciones, distribución... 187
  • 188. Proceso dirigido por casos de uso  Dirigen las actividades de desarrollo  Creación y validación de la arquitectura del sistema  Definición de casos de prueba y procedimientos  Planificación de iteraciones  Creación de documentación de usuario  Despliegue del sistema  Sincronizan el contenido de los diferentes modelos 188 Requisitos Implemen- tación Prueba Los casos de uso enlazan los flujos de trabajo Análisis Diseño
  • 189. Proceso dirigido por casos de uso  Inicialmente los casos de uso se utilizan para la captura de requisitos funcionales  Durante el análisis y el diseño, transformamos el modelo de casos de uso mediante un modelo de análisis en una estructura de clasificadores y realizaciones de casos de uso  En cada iteración, los casos de uso sirven de guía a través del conjunto completo de flujos de trabajo 189 Modelo de casos de uso Modelo de análisis Modelo de diseño <<trace>> <<trace>>
  • 190. Proceso dirigido por casos de uso 190 Requisitos Diseño Implementación Prueba Análisis Modelo de casos de uso Modelo de análisis Modelo de diseño Modelo de despliegue Modelo de implementación Modelo de puebas Requisitos Diseño Implementación Prueba Análisis Modelo de casos de uso Modelo de análisis Modelo de diseño Modelo de despliegue Modelo de implementación Modelo de puebas
  • 191. El Proceso Unificado está centrado en la arquitectura  Se puede tomar como arquitectura de referencia el denominado modelo de arquitectura de 4+1 vistas, propuesto por Philippe Kruchten (1995)  Los modelos son instrumentos para visualizar, especificar, construir y documentar la arquitectura del sistema 191 Vista lógica Vista de implementación Vista de procesos ComponentesComponentes Clases, interfaces, colaboraciones Clases, interfaces, colaboraciones Clases activasClases activas Vista de despliegue NodosNodos Vista de Casos de uso Vista de Casos de uso Casos de usoCasos de uso
  • 192. Proceso centrado en la arquitectura  Los modelos son los vehículos para visualizar, especificar, construir y documentar la arquitectura  El Proceso Unificado prescribe los sucesivos refinamientos de una arquitectura ejecutable 192 tiempo Arquitectura Inicio Elaboración Construcción Transición
  • 193. Proceso centrado en la arquitectura  La arquitectura representa una colección de vistas de los modelos 193 Casos de uso Diseño Despl. Implem. PruebaAnálisis
  • 194. Proceso centrado en la arquitectura  Diseño de la arquitectura  Seleccionar escenarios: aspectos críticos y riesgos  Identificar las clases principales y sus responsabilidades  Distribuir el comportamiento en clases  Estructurar en subsistemas, capas y definir interfaces  Definir distribución y concurrencia  Implementar prototipos de arquitectura  Derivar casos de prueba a partir de los casos de uso  Evaluar la arquitectura Iterar  La arquitectura se desarrolla mediante iteraciones  Comienza con una línea base de arquitectura (primera versión de los modelos  La línea base evoluciona hasta convertirse en un sistema estable 194
  • 195. Proceso centrado en la arquitectura 195 Estructura estática de la arquitectura en el modelo de diseño <<subsystem>> Interfaz del CA Entrega <<subsystem>> Gestión de transacciones Transferencias <<subsystem>> Gestión de cuentas Retirada efectivo Cliente HistoriaDepósito Vista arquitectónica del modelo de despliegue
  • 196. Proceso centrado en la arquitectura  Estructuración de la arquitectura en capas 196 Capa específica de la aplicación Capa general de la aplicación Capa intermedia Capa de software del sistema Patrón de capas de la arquitectura del sistema
  • 197. Proceso centrado en la arquitectura 197 Capa específica de la aplicación Capa general de la aplicación Capa intermedia Capa de software del sistema Gestión de facturas de comprador Gestión de planificación de pagos Gestión de cuentas Java.applet Java.awt Java.rmi Máquina virtual Java Navegador de Internet TCP/IP
  • 198. Flujos de trabajo. Captura de requisitos  Incluye los siguientes pasos  Enumerar requisitos candidatos: lista de características del sistema que llevan asociado un nombre, una descripción y aspectos de planificación (estado, coste estimado, prioridad y riesgo)  Comprender el contexto del sistema  Modelado del dominio (conceptos)  Modelado del negocio (procesos)  Capturar requisitos funcionales: a partir de los casos de uso que reflejan las necesidades de los usuarios  Capturar requisitos no funcionales: identificar restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma, fiabilidad... 198
  • 199. Flujos de trabajo. Captura de requisitos  Captura de requisitos en forma de casos de uso 199 Analista de sistemas Identificar actores y casos de uso Estructurar el modelo de casos de uso Arquitecto Priorizar casos de uso Especificador de casos de uso Detallar casos de uso Diseñador de interfaz de usuario Esbozar interfaz de usuario
  • 200. Flujos de trabajo. Captura de requisitos 200  Identificar actores y casos de uso
  • 201. Flujos de trabajo. Captura de requisitos  Descripción de casos de uso  Estado inicial  Caminos de ejecución  Básico  Alternativos  Formalización de la descripción de casos de uso mediante técnicas de modelado visual  Diagramas de estado de UML: para describir los estados y las transiciones de estado de los casos de uso  Diagramas de actividad: para describir las transiciones entre estados como secuencia de acciones  Diagramas de interacción: para ver como interactúan una instancia de un caso de uso con una instancia de un actor 201
  • 202. Flujos de trabajo. Captura de requisitos 202 Diagrama de colaboración (interacción) para el caso de uso “Sacar Dinero”
  • 203. Flujos de trabajo. Captura de requisitos  Estructurar el modelo de casos de uso  Después de la descripción detallada de casos de uso, se pueden reestructurar para que el sistema sea más fácil de entender y de trabajar con él  Se deben buscar comportamientos compartidos y extensiones  Extraer descripciones de funcionalidad generales y compartidas que pueden ser utilizadas por descripciones más específicas.  Extraer descripciones de funcionalidad adicionales u opcionales que pueden extender descripciones más específicas 203
  • 204. Flujos de trabajo. Captura de requisitos 204 Estructuración de casos de uso con relaciones de generalización y extensión
  • 205. Flujos de trabajo. Análisis  El resultado es el modelo de análisis, que incluye  Paquetes del análisis y de servicio, y sus dependencias y contenidos  Clases del análisis, sus responsabilidades, atributos, relaciones y requisitos especiales. Las clases son de tres tipos  De interfaz: modelan la interacción del sistema con sus actores  De entidad: modelan información persistente  De control: representan aspectos dinámicos y de coordinación  Realizaciones de casos de uso-análisis  Vista de arquitectura del modelo de análisis 205 Clase de interfaz Clase de entidad Clase de control
  • 206. Flujos de trabajo. Análisis  Los paquetes de análisis se utilizan para organizar los artefactos del modelo de análisis en piezas manejables. Pueden contener clases de análisis, de realización de casos de uso y otros paquetes (recursivamente) 206 Dependencias entre paquetes del análisis Gestión de cuentas Gestión de facturas comprador Gestión de facturas vendedor Capa específica de la aplicación Capa general de la aplicación Identificación de paquetes del análisis Cuenta Gestión de cuentas <<trace>> Modelo del dominio Paquete del análisis
  • 207. Flujos de trabajo. Análisis  Los paquetes de servicio se utilizan en un nivel más bajo de la jerarquía de agregación que los paquetes de análisis. Estructuran el sistema de acuerdo a los servicios que proporciona. Contienen clases relacionadas funcionalmente 207 Paquetes de servicio incluidos en un paquete de análisis Gestión de cuentas <<service package>> Cuentas Transferencia s Historia de cuenta cuenta <<service package>> Riesgos Estimación de Riesgo Riesgo
  • 208. Flujos de trabajo. Análisis  El modelo de análisis crece incrementalmente  En cada iteración se seleccionan un conjunto de casos de uso  A partir de la descripción de los casos de uso se seleccionan los clasificadores y relaciones necesarios para la implementación 208 Modelo de casos de uso Modelo de análisis <<trace>> Sacar dinero Sacar dinero salida Interfaz cajero Retirada efectivo cuenta
  • 209. Flujos de trabajo. Análisis 209 Diagrama de clases del análisis (derecha) utilizadas para realizar los casos de uso (izquierda)
  • 210. Flujos de trabajo. Diseño  El resultado es el modelo de diseño, que incluye  Subsistemas de diseño y de servicio y sus dependencias, interfaces y contenidos  Clases del diseño con sus operaciones, atributos y requisitos de implementación. Se decide qué clases son activas (hilos o procesos) y como deben comunicarse y sincronizarse  Realizaciones de casos de uso-diseño en términos de colaboraciones  Vista arquitectónica del modelo de diseño  También se obtiene el modelo de despliegue que describe todas las configuraciones de red sobre las cuales debería implantarse el sistema 210
  • 211. Flujos de trabajo. Diseño 211 Relaciones de trazabilidad entre las clases del modelo de análisis y las del modelo de diseño
  • 212. Flujos de trabajo. Diseño 212 Subsistemas del modelo de diseño
  • 213. Flujos de trabajo. Diseño 213 Clases de diseño utilizadas en la realización del caso de uso “Sacar Dinero”
  • 214. Flujos de trabajo. Diseño 214 Modelo de despliegue del sistema
  • 215. Flujos de trabajo. Implementación  El resultado es el modelo de implementación, que incluye  Subsistemas de implementación y sus dependencias, interfaces y contenidos  Componentes (fichero y ejecutables) y las dependencias entre ellos. Los componentes se someten a las pruebas de unidad  Vista arquitectónica del modelo de implementación, incluyendo sus elementos arquitectónicamente significativos  También produce como resultado un refinamiento de la vista de despliegue donde los componentes ejecutables son asignados a nodos 215
  • 216. Flujos de trabajo. Implementación 216
  • 217. Flujos de trabajo. Prueba  El resultado es el modelo de prueba, que incluye  Casos de prueba  De integración  Del sistema  De regresión  Procedimientos de prueba  Deben especificar como probar clases para cada subsistema  Cada caso de prueba requerirá varios procedimientos  Debe favorecerse la reutilización de los procedimientos  Componentes de prueba, que automatizan los casos de prueba  La prueba también da como resultado un plan de prueba, evaluaciones de las pruebas realizadas y defectos que se pasan como entrada a los flujos de trabajo anteriores 217
  • 218. Proceso Unificado y aplicaciones Web  La clave para utilizar el Proceso Unificado en el desarrollo de aplicaciones Web la dan los casos de uso (Ward y Kroll, 1999)  Integran el marco de ingeniería, que ofrece el Proceso Unificado, con el proceso de diseño creativo que caracteriza a las aplicaciones Web  Ofrecen una forma de expresar en términos comunes un entendimiento compartido del comportamiento esperado de la aplicación Web  Juegan el papel de lengua franca en los proyectos software, es decir, son el lenguaje hablado por todos los implicados en la definición y el desarrollo del sistema Web 218
  • 219. Proceso Unificado y aplicaciones Web  Integración del proceso de diseño creativo en el proceso unificado 219
  • 220. Proceso Unificado y aplicaciones Web  Requisitos  Visión  Acuerdo sobre los problemas que deben resolverse  Definición de los límites del sistema  Descripción de las características más importantes del sistema  Modelo de casos de uso: documentación de los requisitos que permite a los usuarios articular sus necesidades (servicios del sistema)  Los actores representan a los usuarios  Los casos de uso representan los servicios  Especificación suplementaria: contiene los requisitos no funcionales. Conviene desarrollar un glosario con la terminología común del proyecto 220
  • 221. Proceso Unificado y aplicaciones Web  Diseño creativo: guías iniciales de la interfaz de usuario  El “humor del sitio”  Cómo accederán los usuarios al sitio, qué navegadores usarán  Si el sitio tendrá marcos  Limitaciones de color del sitio  Aspectos relativos a gráficos, animaciones...  Mapa de navegación: representación jerárquica de la navegación de los usuarios en el sitio (site map)  El número de niveles representa el número de clicks necesarios para llegar a una página  Toma como referencia el modelo de casos de uso  Se identifican “páginas lógicas” candidatas para la interfaz de usuario. Se representan en el análisis con el constructor UML boundary class 221
  • 222. Proceso Unificado y aplicaciones Web 222