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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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