Presentacion curso ingenieria web ing. aldo zanabria

1,200 views
1,064 views

Published on

www.zanabria.org

Published in: Education
1 Comment
1 Like
Statistics
Notes
  • Agradeceria muchisimo si me ayudarias con el documento respetando la propiedad Intelectual
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,200
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Presentacion curso ingenieria web ing. aldo zanabria

  1. 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. 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. 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. 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. 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. 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. 7. SERVICIOS DE INTERNET  Servicios y Protocolos de Aplicaciones en Internet  Seguridad en la Programación Web Ing. Aldo Hernan Zanabria Galvez 7
  8. 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. 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. 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. 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. 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. 13. Antes-después Ing. Aldo Hernan Zanabria Galvez 13
  14. 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. 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. 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. 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. 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. 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. 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. 21. FUNDAMENTOS Ing. Aldo Hernan Zanabria Galvez 21
  22. 22. Contenidos  Introducción  Diferencias entre los sistemas web y el software tradicional  Ingeniería Web  Usabilidad Ing. Aldo Hernan Zanabria Galvez 22
  23. 23. Dependencia social de la red Ing. Aldo Hernan Zanabria Galvez 23
  24. 24. Usuarios de Internet Ing. Aldo Hernan Zanabria Galvez 24
  25. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Ing. Aldo Hernan Zanabria Galvez 38
  39. 39. INTRODUCCIÓN Ing. Aldo Hernan Zanabria Galvez 39
  40. 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. 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. 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. 43. CRISIS DE LA WEB Diferencias entre los sistemas web y el software tradicional Ing. Aldo Hernan Zanabria Galvez 43
  44. 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. 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. 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. 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. 48. INGENIERÍA WEB Ing. Aldo Hernan Zanabria Galvez 48
  49. 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. 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. 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. 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. 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. 54. La Ingeniería Web es un campo multidisciplinar Ing. Aldo Hernan Zanabria Galvez 54
  55. 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. 56. Categorías de las aplicaciones web Ing. Aldo Hernan Zanabria Galvez 56
  57. 57. Sistemas web simples vs avanzados Ing. Aldo Hernan Zanabria Galvez 57
  58. 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. 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. 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. 61. Calidad de las aplicaciones Web Ing. Aldo Hernan Zanabria Galvez 61
  62. 62. USABILIDAD Ing. Aldo Hernan Zanabria Galvez 62
  63. 63. Ing. Aldo Hernan Zanabria Galvez 63
  64. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 77. MÉTODOS DE DESARROLLO PARA APLICACIONES WEB Ing. Aldo Hernán Zanabria Gálvez Ing. Aldo Hernan Zanabria Galvez 77
  78. 78. Ing. Aldo Hernan Zanabria Galvez 78
  79. 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. 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. 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. 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. 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. 84. MÉTODOS PARA EL DESARROLLO DE APLICACIONES WEB Ing. Aldo Hernan Zanabria Galvez 84
  85. 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. 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. 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. 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. 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. 90. RMM Ing. Aldo Hernan Zanabria Galvez 90
  91. 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. 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. 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. 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. 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. 96. OOHDM Modelo conceptual de una revista en línea (Schwabe y Rossi, 1998 Ing. Aldo Hernan Zanabria Galvez 96
  97. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 112. OOWS: UN MÉTODO DE INGENIERÍA WEB Ing. Aldo Hernan Zanabria Galvez 112
  113. 113. Objetivos Ing. Aldo Hernan Zanabria Galvez 113
  114. 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. 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. 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. 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. 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. 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. 120. OOWS. Proceso de desarrollo Ing. Aldo Hernan Zanabria Galvez 120
  121. 121. Propuesta Metodológica Ing. Aldo Hernan Zanabria Galvez 121
  122. 122. Esquema conceptual Ing. Aldo Hernan Zanabria Galvez 122
  123. 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. 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. 125. Modelado de navegación Ing. Aldo Hernan Zanabria Galvez 125
  126. 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. 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. 128. Mapa de navegación Ing. Aldo Hernan Zanabria Galvez 128
  129. 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. 130. Primitivas de abstracción. Contexto Navegacional Ing. Aldo Hernan Zanabria Galvez 130
  131. 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. 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. 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. 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. 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. 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. 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. 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. 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. 140. Modelo de Navegación. Ejemplo de relación de contexto Ing. Aldo Hernan Zanabria Galvez 140
  141. 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. 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. 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. 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. 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. 146. Construcción del Modelo de Navegación 2. Construcción de los Mapas Ing. Aldo Hernan Zanabria Galvez 146
  147. 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. 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. 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. 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. 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. 152. Caso de estudio OOWS  Tienda virtual de venta de discos DiscoWeb (Fons et al., 2002) Ing. Aldo Hernan Zanabria Galvez 152
  153. 153. Caso de estudio OOWS Ing. Aldo Hernan Zanabria Galvez 153
  154. 154. Caso de estudio OOWS Ing. Aldo Hernan Zanabria Galvez 154
  155. 155. Caso de estudio OOWS Ing. Aldo Hernan Zanabria Galvez 155
  156. 156. 1. INTRODUCCIÓN Proceso Software en la Ingeniería Web 156
  157. 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. 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. 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. 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. 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. 162. 2. Proceso iterativo e incremental para la Ingeniería Web 162
  163. 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. 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
  165. 165. 3. Proceso Unificado 165
  166. 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. 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. 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. 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. 170. UML en el Proceso Unificado 170 Proceso de desarrollo que incluye las actividades del ciclo de vida que producen modelos UML
  171. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 200. Flujos de trabajo. Captura de requisitos 200  Identificar actores y casos de uso
  201. 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. 202. Flujos de trabajo. Captura de requisitos 202 Diagrama de colaboración (interacción) para el caso de uso “Sacar Dinero”
  203. 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. 204. Flujos de trabajo. Captura de requisitos 204 Estructuración de casos de uso con relaciones de generalización y extensión
  205. 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. 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. 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. 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. 209. Flujos de trabajo. Análisis 209 Diagrama de clases del análisis (derecha) utilizadas para realizar los casos de uso (izquierda)
  210. 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. 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. 212. Flujos de trabajo. Diseño 212 Subsistemas del modelo de diseño
  213. 213. Flujos de trabajo. Diseño 213 Clases de diseño utilizadas en la realización del caso de uso “Sacar Dinero”
  214. 214. Flujos de trabajo. Diseño 214 Modelo de despliegue del sistema
  215. 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. 216. Flujos de trabajo. Implementación 216
  217. 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. 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. 219. Proceso Unificado y aplicaciones Web  Integración del proceso de diseño creativo en el proceso unificado 219
  220. 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. 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. 222. Proceso Unificado y aplicaciones Web 222

×