UNIVERSIDAD POLITECNICA DE MADRID FACULTAD DE INFORMATICA TESIS DE MASTER EN INGENIERIA DEL SOFTWARE USABILIDAD EN METODOLOGÍAS ÁGILES

Transcripción

1 UNIVERSIDAD POLITECNICA DE MADRID FACULTAD DE INFORMATICA TESIS DE MASTER EN INGENIERIA DEL SOFTWARE USABILIDAD EN METODOLOGÍAS ÁGILES Autor: JOSE GERMÁN NÚÑEZ MORI Dirigida por: ANA MORENO Noviembre, 2010

2 Agradecimiento Agradezco a mis padres por apoyarme a seguir mis estudios

3 Contenido I. Introducción 2 II. Metodologías Ágiles 1 1. Introducción Manifiesto Ágil Principales metodologías ágiles Programación Extrema (XP) Principios básicos Proceso de desarrollo Proceso Unificado Ágil (AUP) Descripción Principio básicos Proceso de desarrollo Agile model driven development (AMDD) Descripción Principio básicos Proceso de desarrollo Scrum Descripción Principio básicos Proceso de desarrollo Dynamic Systems Development Method (DSDM) Descripción Principios básicos Proceso de desarrollo Feature Driven Development (FDD) Descripción Principios básicos Proceso de desarrollo Comparativa entre metodologías ágiles Criterios de comparación Ciclo de vida del proyecto Estado Actual Calidad Herramientas Conclusiones de la comparativa 40

4 5.3 Adopción de metodologías 40 III. Marco Ágil de trabajo Introducción Planteamiento metodológico Estructura Metodológica Fases del marco ágil de trabajo Inicio (Inception) Historias de Usuarios Pruebas de Aceptación Product Backlog Elaboración Prototipo de la arquitectura del sistema Estándar MDA (Model Driven Architecture) Usando MDA Mapas de Transformación MDA Transformaciones de modelos MDA AndroMDA MDA en la generación de código de AndroMDA Arquitectura del marco ágil de trabajo según AndroMDA Modelado de AndroMDA y el prototipo de Arquitectura del marco ágil de trabajo Herramientas y tecnologías en el ciclo de generación AndroMDA Plan de ejecución de la primera iteración de construcción Fase de Desarrollo IV. Fase de Inicio del Marco Ágil de Trabajo Introducción Desarrollo de la fase de Inicio Product Backlog Historias de usuarios Pruebas de aceptación 87 V. Fase de Elaboración del Marco Ágil de Trabajo Introducción Desarrollo de la fase de Elaboración Planificación de la Primera Iteración Prototipo de Arquitectura Tarea de Implementación de la Funcionalidad Diseño de la capa de datos

5 Diseño de la capa de negocio Diseño de la capa de presentación Resultado de Tarea Integración del patrón de usabilidad Warning Integración del patrón de usabilidad Warning en la capa de presentación y capa de negocio Flujo de trabajo según el patrón de usabilidad Warning Resultados de la Integración del patrón de usabilidad Warning Integración del patrón de usabilidad System Status Feedback Integración del patrón de usabilidad SSF a la capa de presentación y capa de negocio Flujo de trabajo según el patrón de usabilidad SSF Resultados de la integración del patrón de usabilidad SSF Integración del patrón de usabilidad Global Undo Integración del patrón de usabilidad GU a la capa de presentación y capa de negocio Flujo de trabajo según el patrón de usabilidad GU Resultados de la integración del patrón de usabilidad GU Integración del patrón de usabilidad Abort Operation Integración del patrón de usabilidad AO a la capa de presentación y capa de negocio Flujo de trabajo según el patrón de usabilidad AO Resultados de la integración del patrón de usabilidad AO Integración del patrón de usabilidad System Progress Feedback Integración del patrón de usabilidad SPF a la capa de presentación y capa de negocio Flujo de trabajo según el patrón de usabilidad SPF Resultados de la integración del patrón de usabilidad SPF Integración del patrón de usabilidad Abort Command Integración del patrón de usabilidad AC a la capa de presentación y capa de negocio Flujo de trabajo según el patrón de usabilidad AC Resultados de la integración del patrón de usabilidad SPF Planificación tras la primera iteración 151 VI. Conclusiones 152 VII. Referencias Bibliográficas 153 VIII. Anexos 155

6 Anexo 01: Especificación Patrón de Usabilidad Warning 156 Anexo 02: Especificación Patrón de Usabilidad System Status Feedback 166 Anexo 03: Especificación Patrón de Usabilidad Global Undo 177 Anexo 04: Especificación Patrón de Usabilidad Abort 190 Anexo 05: Especificación Patrón de Usabilidad System Progress Feedback 204 Anexo 06: Patrones de Usabilidad en la Elicitación 213

7 Índice de Figuras Figura 1: Iteraciones AUP Figura 2: Ciclo de vida de un proyecto AMDD Figura 3: Ciclo de vida de un proyecto AMDD Figura 4: Ciclo de vida de un proyecto FDD Figura 5: Ciclo de vida AUP Figura 6: Ciclo de vida del marco ágil de trabajo Figura 7: Hito de la fase de Inicio Figura 8: Formato de Historias de usuarios según XP Figura 9: Formato de Historias de usuarios según el marco ágil Figura 10: Formato de Pruebas de Aceptación Figura 11: Formato del Product Backlog Figura 12 : Hito de la fase de Elaboración Figura 13: Trazabilidad de Modelos MDA Figura 14: Transformación de metamodelos bajo MDA Figura 15: Marcado de un modelo bajo MDA Figura 16: Patrones de transformación en los modelos MDA Figura 17: Ciclo AndroMDA de generación de código Figura 18: Arquitectura de Aplicación base del marco ágil de trabajo Figura 19: Estructura de Aplicación empresarial AndroMDA Figura 20: Diagrama de Actividad en AndroMDA Figura 21: Componente controlador en AndroMDA Figura 22: Casos de Uso AndroMDA Figura 23: Modelado de servicios en AndroMDA Figura 24: Modelado de entidades de datos en AndroMDA Figura 25: Dependencia entre componentes de capa en AndroMDA Figura 26: Herramienta de gestión Sprintometer Figura 27: Sección de registro de Sprint en Sprintometer Figura 28. Sección de control de avance de tareas en el Sprint bajo Sprintometer Figura 29: Vista de la planificación en días Figura 30: Sprint y tareas de la primera Iteración en Spritometer Figura 31: Modelo de entidades de la capa de datos Figura 32: Modelado de la capa de negocio Figura 33: Dependencias de servicios con las entidades de datos Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas Figura 35: Modelado de la clase controladora Figura 36: Diagrama de actividad asociado a la capa de presentación Figura 37: Búsqueda de personas Página principal de la aplicación Figura 38: Relacionar Personas Criterio de selección de personas a relacionar Figura 39: Relacionar Personas Adición de relaciones a la persona seleccionada Figura 40 Diagrama de clases de la especificación del patrón de usabilidad Warning Figura 41: Diagrama de secuencia de la especificación del patrón de usabilidad Warning Figura 42: Modelado de la clase controladora con el Patrón de usabilidad Warning Figura 43: Confirmación de adición de nueva relación según el patrón de usabilidad Warning Figura 44: Resultados tras la confirmación de la adición de una nueva relación Figura 45: Diagrama de clases de la especificación del patrón de usabilidad SSF Figura 46: Diagrama de secuencia de la especificación del patrón de usabilidad SSF Figura 47: Integración del patrón de usabilidad SSF en el diseño de la funcionalidad Relacionar Personas Figura 48: Resultados tras la adición satisfactoria de una nueva relación Figura 49: Resultados de error tras la adición de una nueva relación Figura 50: Diagrama de clases de la especificación del patrón de usabilidad GU Figura 51: Diagrama de secuencias de la especificación del patrón de usabilidad GU Figura 52: Integración del patrón de usabilidad GU en la capa de negocio y capa de diseño Figura 53: Integración del patrón de usabilidad GU en el diagrama de actividades de la página de Adición de relaciones

8 Figura 54: Adición de nuevas relaciones considerando el patrón GU Figura 55: La adición de relaciones tras en el evento de deshacer (Undo) Figura 56: Diagrama de clases de la especificación del patrón de usabilidad AO Figura 57: Diagrama de secuencia de la especificación del patrón de usabilidad AO Figura 58: Integración del patrón de usabilidad AO en la capa de negocio y capa de presentación. 130 Figura 59: Integración del patrón de usabilidad AO en el diagrama de actividades de la página de Adición de relaciones Figura 60: Adición de nuevas relaciones considerando el patrón AO Figura 61: Home de la aplicación tras el evento Cancelar Figura 62: Consulta de relaciones tras el evento de cancelar Figura 63: Diagrama de clases de la especificación del patrón de usabilidad SPF Figura 64: Diagrama de secuencia de la especificación del patrón de usabilidad SPF Figura 65: Integración del patrón de usabilidad SPF en la capa de negocio y capa de diseño Figura 66: Integración del patrón de usabilidad SPF en el diagrama de actividades de la página Web de Adición de relaciones Figura 67: Esquema de trabajo del objeto XMLHttpRequest Figura 68: Adición de distintas relaciones a la persona seleccionada Figura 69: Barra de progreso mientras se aplica la operación de Undo a las relaciones adicionadas Figura 70: Diagrama de secuencia de la especificación del patrón de usabilidad AC Figura 71: Integración del patrón de usabilidad AC en la capa de negocio y capa de diseño Figura 72: Integración del patrón de usabilidad AC en el diagrama de actividades de la página Web de Adición de relaciones Figura 73: Adición de distintas relaciones a la persona seleccionada Figura 74: Barra de progreso con opción de cancelar, ante la operativa de Undo de las relaciones adicionadas Figura 75: Tras el evento de cancelar el comando de Undo de relaciones Figura 76: Carga de trabajo a lo largo de la planificación

9 Índice de Tablas Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologías ágiles Tabla 2: Estado actual de las metodologías ágiles Tabla 3: Comparativa de calidad en las metodologías ágiles Tabla 4: Herramientas de libre distribución para metodologías ágiles Tabla 5 : Detalle de secciones del Sprintometer Tabla 6: Product backlog Tabla 7: Historia de usuario Relacionar personas Tabla 8: Historia de usuario Gestionar fusión de personas Tabla 9: Historia de usuario Buscar personas fusionadas Tabla 10: Historia de usuario Recuperar datos entidad financiera Tabla 11: Historia de usuario Gestionar Situación familiar de la persona Tabla 12 : Prueba de aceptación Relacionar personas Tabla 13: Prueba de aceptación Gestionar fusión de personas Tabla 14: Prueba de aceptación Buscar personas fusionadas Tabla 15: Prueba de aceptación Recuperar datos entidad financiera Tabla 16: Prueba de aceptación Gestionar situación familiar Tabla 17: Product backlog Tabla 18: Planificación del Sprint Relacionar Personas Tabla 19: Planificación inicial de la tarea de implementación de la funcionalidad Tabla 20: Actualización de la planificación de la tarea de implementación de la funcionalidad Tabla 21: Planificación inicial de la tarea de integración del patrón de usabilidad Warning Tabla 22: Correspondencia de componentes del patrón de usabilidad Warning y los componentes de la funcionalidad Tabla 23- Planificación actualizada de la tarea de integración del patrón de usabilidad Warning Tabla 24: Planificación inicial de la tarea de integración del patrón de usabilidad SSF Tabla 25: Correspondencia de componentes del patrón de usabilidad SSF y los componentes de la funcionalidad Tabla 26: Planificación actualizada de la tarea de integración del patrón de usabilidad SSF Tabla 27: Planificación inicial de la tarea de integración del patrón de usabilidad GU Tabla 28: Correspondencia de componentes del patrón de usabilidad GU y los componentes de la funcionalidad Tabla 29: Planificación actualizada de la tarea de integración del patrón de usabilidad GU Tabla 30: Planificación inicial de la tarea de integración del patrón de usabilidad AO Tabla 31: Correspondencia de componentes del patrón de usabilidad AO y los componentes de la integración Tabla 32: Planificación actualizada de la tarea de integración del patrón de usabilidad AO Tabla 33: Planificación inicial de la tarea de integración del patrón de usabilidad SPF Tabla 34: Correspondencia de componentes del patrón de usabilidad SPF y los componentes de la Integración Tabla 35: Planificación actualizada de la tarea de integración del patrón de usabilidad SPF Tabla 36: Planificación inicial de tarea de integración del patrón de usabilidad AC Tabla 37: Correspondencia de componentes del patrón de usabilidad AC y los componentes de la integración Tabla 38: Planificación actualizada de la tarea de integración del patrón de usabilidad AC

10 I. Introducción La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso. Es considerada la usabilidad también, como la medida en que un producto puede ser usado por usuarios específicos, para lograr los objetivos especificados con efectividad, eficiencia y satisfacción en un contexto específico de uso. En el campo de la Ingeniería de software, hablar de usabilidad hoy en día, es relacionar con la interfaz de usuario, por lo tanto, la usabilidad afectaría a la UI y no a la funcionalidad básica del sistema. De acuerdo a esto, la usabilidad debe ser tratada al final del desarrollo del sistema, como un atributo más de calidad y que no necesita demasiadas pruebas (Hipótesis de la separación). En contraposición, a la idea que se tiene hoy en día de la usabilidad, existen investigaciones en el campo de la ingeniería de Software, donde, se describe que las Isuues de usabilidad son limitaciones estáticas y dinámicas a los componentes de software y que la separación de la interfaz de usuario de la funcionalidad básica, no garantiza que se entregue un producto usable al cliente final. Confirmada la relación entre diseño de software y usabilidad, la revisión del costo para alcanzar un nivel aceptable de usabilidad debería ser mayor que lo planteado por la hipótesis de separación, por lo tanto, la facilidad de uso debe ser tratada con anterioridad al proceso de desarrollo, con el fin de evaluar su impacto en el diseño tan pronto como sea posible. Esto es una estrategia ya aplicada con anterioridad a algunos de los atributos de calidad como por ejemplo: fiabilidad, disponibilidad y mantenibilidad, donde, algunos autores propusieron en su momentos, técnicas para hacer frente a estos atributos en tiempo de diseño arquitectónico. La literatura HCI (Human Computer Interaction), analiza el impacto que tiene la usabilidad en el desarrollo del Software, con lo cual, presenta recomendaciones, considerando tres diferentes categorías de impacto:

11 Usabilidad con impacto en la UI, esto afecta a la presentación del sistema, como puede ser botones, color de fondo, etc. Para dar solución a esto, solo se realizan cambios en el diseño detallado de la UI y no en el Funcionalidad básica del sistema. Usabilidad con impacto en el proceso desarrollo, esto afecta al proceso de desarrollo, donde, estas recomendaciones proponen directrices para alentar la interacción usuariosistema, el cual debe tener un sitio natural e intuitivo para el usuario. Si se desea hacer uso de estas recomendaciones, es necesario modificar el proceso de desarrollo, ya que debe ser centrado en el usuario, implicando de esta manera, tener técnicas mas potentes para la obtención de requisitos, que probablemente se tenga que apoyar en otras disciplinas como HCI, con el objetivo de poder hacer participe al usuario en la construcción del software Usabilidad con impacto en el diseño, estas son recomendaciones que implican actividades de construcción de funcionalidades en el Software, para mejorar la actividad usuario sistema, por ejemplo funcionalidades como: Cancelar una tarea en curso. Según las recomendaciones dadas por la literatura HCI, hoy en día se han realizado estudios enfocados, más que todo en el impacto de la usabilidad en el diseño (Ver anexos), buscando así, mecanismos para tratar la usabilidad en esta etapa. Todas estas recomendaciones y estudios, que asocian la usabilidad en el proceso de desarrollo de software, hoy en día, se vienen utilizando en proyecto de desarrollo de software tradicional, es decir, proyectos que siguen lineamientos de metodologías de desarrollo tradicional. Es de acuerdo a esta premisa, que el presente trabajo tiene como objetivo principal, la inclusión de los principios de usabilidad, en proyectos Software, que se desarrollen en base a metodologías ágiles. Para cumplir con este objetivo, el presente trabajo de fin de Master, se basará en estudios previos, donde se detallan mecanismo para considerar la usabilidad antes del proceso de desarrollo, es decir, en las etapas, de toma de requisitos y de diseño (ver anexos). Estos mecanismos, deberán de ser tomados en cuenta, en los planteamientos de la metodología o metodologías ágiles seleccionadas, para que así, el ciclo del vida del software a desarrollar en base a estos lineamientos ágiles, tome en cuenta los principios de usabilidad. El presente trabajo, tendrá la siguiente estructura, para abordar el objetivo principal del

12 mismo: Capítulo I (Metodologías ágiles), se detallará los planteamientos de las metodologías ágiles mas conocidas hoy en día, buscando con esto, seleccionar la metodología o metodologías, que nos permitan incluir los principios de usabilidad. Capitulo II (Marco ágil de trabajo), en base a la metodología o metodologías seleccionadas, se creará un marco de trabajo ágil, donde se detalle los lineamientos para el ciclo de vida del software a desarrollar, donde también, estos lineamientos tengan en cuenta los principios de usabilidad. Ya en capitulo III (Fase de inicio del marco ágil de trabajo) y IV (Fase de elaboración del marco ágil de trabajo), es donde, se describirá el desarrollo del sistema, siguiendo los lineamientos del marco ágil de trabajo..

13 La Usabilidad en Metodologías Ágiles II. Metodologías Ágiles Versión 3.0

14 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Historia del documento FECHA VERSION DESCRIPCIÓN AUTOR 08/05/ Metodologías Ágiles José Germán Núñez Mori 25/05/ Metodologías Ágiles José Germán Núñez Mori 15/06/ Metodologías Ágiles José Germán Núñez Mori José Germán Núñez Mori Página 13 de 237

15 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Metodologías Ágiles 1. Introducción A principios de las década del 90 surgió un enfoque que era revolucionario para su momento ya que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr obtener software de alta calidad en un tiempo y costo determinado. El enfoque fue planteado por primera vez en 1991 por James Martin [MART91], que consistía en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeños de programadores utilizando herramientas que generaban código de forma automática tomando como entrada sintaxis de alto nivel. En general se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo [SMHR04]. Tras pasar cierto tiempo después de este primer enfoque de agilidad en los procesos de desarrollo, en febrero del 2001 se reunieron miembros prominentes de la comunidad Software y adoptaron el nombre de metodologías ágiles, poco después formando la Alianza Ágil, que es una organización sin fines de lucro, que promueve el desarrollo ágil de aplicaciones [CLEP09]. Las metodologías ágiles nacen como una reacción contra los métodos de peso pesado, muy estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente [WDAS09]. 2. Descripción Las metodologías ágiles son un marco conceptual de la Ingeniería de Software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto, considerando una iteración como una unidad de tiempo que dura de uno a cuatro semanas. Donde cada iteración del ciclo de vida incluye planificación análisis, diseño, codificación, revisión y documentación [WDAS09]. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un producto parcial o una parte del todo al final de cada iteración. Las metodologías ágiles buscan lo siguiente [WDAS09]: Evitar los tortuosos y burocráticos caminos de las metodologías tradicionales, enfocándose en la gente y los resultados. José Germán Núñez Mori Página 14 de 237

16 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Minimizar los riesgos, desarrollando software en cortos lapsos de tiempo (iteraciones). Enfatizar las comunicaciones cara a cara en vez de la documentación. Enfatizar que el software funcional es la primera medida del progreso. Las metodologías ágiles platean centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software, siendo esto su principal filosofía. Dando mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque esta mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. 3. Manifiesto Ágil En esta sección se detalla los principios básicos del Manifiesto Ágil, inspirando en base a lo expuesto en: Manifiesto for Agile Software Development [MFAS01]. Como consecuencia de la reunión donde se acuño el término Metodologías Ágiles (febrero 2001), se establecieron los principios de estas metodologías agrupándoles en cuatro postulados, quedando esta agrupación denominada como Manifiesto Ágil. A continuación se mencionan los cuatro postulados de este manifiesto: Valorar más a los individuos y su interacción que a los procesos y las herramientas, es decir, la gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Valorar más el software que funciona que la documentación exhaustiva, donde la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar decisiones importantes. Valorar más la colaboración con el cliente que la negociación contractual, es decir, se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Valorar la respuesta al cambio que el seguimiento de un plan, es decir, la habilidad de responder a los cambios que puedan surgir a lo largo del proyecto Los postulados anteriores inspiran los doce principios del manifiesto, donde estos principios representan las características que diferencian un proceso ágil de uno tradicional A continuación se detallarán los doce principios del manifiesto, donde, los dos primeros principios son generales y resumen gran parte del espíritu ágil, el resto tienen que ver con el proceso a seguir y José Germán Núñez Mori Página 15 de 237

17 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 con el equipo de desarrollo, en cuanto a metas y organización del mismo [CLEP09]: Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia. 4. Principales metodologías ágiles En esta sección se describirán las principales metodologías ágiles destacadas hasta el momento. 4.1 Programación Extrema (XP) La definición de esta metodología, se ha realizado tomando como base las siguientes referencias: [RJEF99], [RMAT6], [SMHR04], [CLEP09].Definición La programación Extrema (en adelante XP) es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en José Germán Núñez Mori Página 16 de 237

18 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación Los ingredientes utilizados en esta metodología son conocidos desde el principio de la informática, donde, los autores de la metodología XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software Principios básicos La metodología XP se basa en 12 principios básicos, agrupados en 4 categorías, las cuales se detallan a continuación: Principio 1 - Retroalimentación en escala fina: a) El principio de pruebas, se tiene que establecer un periodo de pruebas de aceptación (periodo de caja negra), donde se definirán las entradas al sistema y los resultados esperados en cada una de las pruebas definidas. b) Proceso de planificación, es la fase en la que se crea un documento llamado Historias de los usuarios (User stories), en donde el usuario escribe sus necesidades, definiendo así las actividades que realizará el sistema. El usuario escribirá entre 20 y 80 historias (dependiendo de la complejidad del problema) que se considera suficientes para formar el llamado: Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación. Por regla general cada uno de las historias de los usuarios suelen necesitar de una a tres semanas de desarrollo. c) El cliente en el sitio, se promueve la fuerte interacción cara a cara entre el programador y el cliente, con el objetivo de disminuir el tiempo de comunicación y la cantidad de documentos, junto con sus altos costes de creación y mantenimiento. Este representante del cliente, deberá formar parte del equipo de trabajo durante toda la realización del proyecto, teniendo la potestad para determinar requerimientos definir funcionalidades, señalar prioridades y responder preguntas de los programadores. d) Programación en pareja, la metodología plantea que los programadores XP escriban su código en parejas, compartiendo una sola maquina con el objetivo de producir aplicaciones mejores, de manera consistente a iguales o menores costes. José Germán Núñez Mori Página 17 de 237

19 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Principio 2 - Proceso continuo en lugar de por lotes: a) Integración continúa, permite al equipo de programadores hacer un rápido progreso implementando las nuevas características del software. b) Refactorización, permite a los equipos de programadores XP mejorar el diseño del sistema, donde a lo largo de todo el proceso de desarrollo, los programadores evalúan continuamente el diseño y recodifican lo necesario. c) Entregas pequeñas, consiste en colocar un sistema sencillo en entono de producción rápidamente, que se actualice de manera continua, permitiendo que el verdadero valor del negocio sea evaluado en un ambiente real. Principio 3 - Entendimiento compartido: a) Diseño simple, se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente. b) Metáfora, desarrollada por los programadores al inicio del proyecto, define una historia de como funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema c) Propiedad colectiva del código, la metodología XP promueve la filosofía de un código con propiedad compartida, donde, nadie es propietario de nada y que todos son propietarios de todo d) Estándar de codificación, define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Principio 4 - Bienestar del programador: a) La semana de 40 horas, la programación extrema sostiene que los programadores cansados escriben código de menor calidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad Proceso de desarrollo XP, parte del caso habitual de una compañía que desarrolla software, normalmente a medida, en José Germán Núñez Mori Página 18 de 237

20 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales. El proceso conlleva las siguientes actividades: a) Interacción con el cliente En este tipo de programación, el cliente pasa a formar parte implicada en el equipo de desarrollo, donde, su importancia es máxima en el momento de tratar con los usuarios y efectuar las planificaciones respectivas. Al tener al cliente mucho más cerca del equipo de desarrollo, se elimina la fase inicial de recopilación de requerimientos y se permite que estos se vayan cogiendo a lo largo del proyecto de manera ordenada en las llamadas Historia de usuario. A diferencias de otras técnicas como puede ser UML, el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere. En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y asignarles una duración. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programación. b) Planificación del proyecto En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes iteraciones, y por cada iteración el cliente ha de recibir una versión nueva. Se ha de tener asumido que en el proceso de planificación habrá errores, ante lo cual la metodología establece mecanismos de revisión, donde cada tres o cinco iteraciones es normal revisar las historias de los usuarios y renegociar la planificación. Además la metodología establece que por cada iteración se realizará un planificación, que es lo que se llama Planificación iterativa, en la que se anotará las historia de los usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptación realizadas por el cliente. c) Diseño desarrollo y pruebas El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones y en dirección correcta Para el diseño, la metodología establece mecanismos, para que este sea revisado y mejorado de manera continua, según se vaya añadiendo funcionalidad al sistema. Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y se continúa. José Germán Núñez Mori Página 19 de 237

21 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por esto es importante pasar las pruebas al 100%. Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integración diaria. 4.2 Proceso Unificado Ágil (AUP) La definición de esta metodología, se ha realizado tomando como base las siguientes referencias: [CRLA02], [SABL06]. [KINT07], [WAUP09] Descripción El Proceso Unificado Ágil (en adelante, AUP), se describe como una metodología fácil de entender para el desarrollo de aplicaciones software de negocio, utilizando técnicas ágiles y conceptos aun fieles a las de RUP, por lo tanto, es una versión simplificada del Rational Unified Process (RUP). AUP, incluye o hace uso de las siguientes técnicas ágiles: Test driven development (TDD). Agile model driven development (AMDD). Agile change management. Data base refactoring. AUP, es una metodología que tiene la adopción de muchas de las técnicas ágiles de la metodología XP (Extreme Programming) y de las formalidades de RUP, teniendo como filosofía adaptarse a las necesidades del proyecto y no al contrario como lo planteado en las metodologías tradicionales. Esta metodología, plantea un ciclo de vida iterativo, que se basa en la ampliación y refinamiento sucesivo del sistema, mediante múltiples iteraciones con retroalimentación cíclica y adaptación como elementos principales que dirigen para converger hacia un sistema adecuado Principio básicos Como parte de esta metodología, en la presente sección se detalla, tanto las fases y disciplinas de su planteamiento: José Germán Núñez Mori Página 20 de 237

22 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 a) Fases Al igual que RUP, AUP tiene las 4 fases clásicas consecutivas y que acaban cada uno de estas, con hitos claros alcanzados: Inception (Concepción): El objetivo de esta fase es obtener una comprensión común clienteequipo de desarrollo, del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo. Elaboración: El objetivo es que el equipo de desarrollo profundice en la comprensión de los requisitos del sistema y en validar la arquitectura. Construcción: Durante la fase de construcción el sistema es desarrollado y probado al completo en el ambiente de desarrollo. Transición: el sistema se lleva a los entornos de preproducción donde se somete a pruebas de validación y aceptación y finalmente se despliega en los sistemas de producción. b) Disciplinas El proceso AUP, establece un modelo más simple que el planteado en RUP, por lo que reúne en una única disciplina: el modelado de negocio, requisitos y análisis y diseño. El resto de disciplinas coinciden con las restantes de RUP, a continuación se describe las disciplinas consideradas por AUP: Modelado: Se busca entender el negocio de la organización, el problema de dominio que se abordan en el proyecto, y determinar una solución viable. Implementación: Consiste en transformar los modelos o modelo en código ejecutable y realizar un nivel básico de las pruebas, en particular Unit testing. Pruebas: Se busca realizar una evaluación objetiva para garantizar la calidad. Esto incluye la búsqueda de defectos, validar que el sistema funciona tal como está establecido, y verificando que se cumplan los requisitos. Despliegue: Consiste en la elaboración de un plan para la entrega del sistema y ejecutar el plan para que el sistema este a disposición de los usuarios finales. Gestión de Configuración: Consiste en administrar el acceso a los artefactos del proyecto. Esto incluye no sólo el seguimiento de las versiones de los artefactos en el tiempo, sino también el control y la gestión de los cambios de estos. Administración del Proyecto: Consiste en dirigir las actividades que se llevan a cabo dentro del proyecto. Esto incluye la gestión de riesgos, la dirección de personas (la asignación de tareas, el seguimiento de los progresos, etc), y de coordinación con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que el software final sea José Germán Núñez Mori Página 21 de 237

23 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 entregado a tiempo y dentro del presupuesto. Entorno: Es un soporte para el resto de los esfuerzos para garantizar un proceso adecuado, orientación (normas y directrices), y herramientas (hardware, software, etc) estén disponibles para el equipo según sea necesario Proceso de desarrollo En esta metodología las disciplinas se llevan acabo de manera iterativa, con la definición de las actividades de los miembros del equipo de desarrollo, con el fin de desarrollar, validar y entregar el software que responda a las necesidades de los stakeholders. En cada disciplina la metodología plantea las diferentes actividades y artefactos a producir, lo cual no implica que se realicen o se produzcan todo lo planteado si no más bien lo que se necesita en el proyecto. Las fases que platea la metodología no constituye el antiguo ciclo de vida secuencial o en cascada, si no más bien, es planteado de la siguiente manera: La fase de Inicio (Inception), no es una fase de requisitos, si no mas bien una especia de fase de viabilidad, donde se lleva acabo el estudio suficiente, para decidir si continuar o no el proyecto. La fase de Elaboración no es una fase de requisitos o diseño, si no que es una fase donde se implementa de manera iterativa la arquitectura que constituye el núcleo central del sistema, y es donde se mitiga las cuestiones de alto riesgo. En la fase de construcción, se implementa de manera iterativa el resto de requisitos (de menor riesgo), se realiza pruebas y se prepara para el despliegue. Por cada una de las fases e iteraciones planteadas en las mismas, se puede hacer uso de la totalidad de las disciplinas o solo de algunas, esto dependerá de la iteración en la que se encuentre, debido a que el esfuerzo relativo en las disciplinas disminuye de iteración en iteración. AUP, plantea que en lugar del big bang en la entrega del software, una liberación del producto en partes, por ejemplo versión 1, luego versión 2 del software en producción y así sucesivamente hasta tener el producto completado. De acuerdo a este planteamiento AUP distingue dos tipos de iteraciones: Versión de desarrollo, cuyo resultado esta un despliegue en entorno QA (Aseguramiento de la calidad) o Demo área, estas versiones deben ser rápidas, de ser posible de una a tres semanas de desarrollo. José Germán Núñez Mori Página 22 de 237

24 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Versión producto, cuyo resultado es un despliegue en producción, donde la primera entrega estable tardará en promedio 12 meses, la siguiente 9 meses y las siguientes cada 6 meses. Figura 1: Iteraciones AUP AUP, se preocupa principalmente de la gestión de riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables durante la fase de elaboración del producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que determinan los riesgos técnicos. 4.3 Agile model driven development (AMDD) La definición de esta metodología, se ha realizado tomando como base la siguiente referencia: [SABL08] Descripción Agile model driven development (en adelante, AMDD), es una versión ágil del Model driven development (MDD), donde MDD es un enfoque amplio de desarrollo de software donde se crean modelos antes del código fuente. Un ejemplo de MDD es el estándar MDA (Arquitectura dirigida por modelos) La diferencia entre MDD y AMDD, es que este último en lugar de crear una amplia gama de modelos antes de escribir código fuente, crea modelos ágiles que son solo apenas los suficientemente buenos. AMDD es una estrategia fundamental en la escalabilidad de los desarrollos ágiles del software Principio básicos AMDD, plantea las siguientes dos etapas como parte de su ciclo de vida del proyecto: Previsión (Envisioning), etapa que pertenece a la iteración 0, consta de dos sub-actividades: o Previsión inicial de requerimientos (Initial Requirements Envisioning). José Germán Núñez Mori Página 23 de 237

25 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 o Previsión inicial de la arquitectura (Initial Architectural Envisioning). Ambas sub actividades, son recomendadas por la metodología que se realicen en periodos diarios, durante el tiempo que dure la iteración 0. Desarrollo (Development), iteración que será repetida hasta alcanzar un producto de calidad, consta de sub actividades a mencionar: o Iteración de modelado (Iteration Modeling). o Modelo de asalto (Model Storming). o Evaluación en base a TDD (Test driven development) Figura 2: Ciclo de vida de un proyecto AMDD Proceso de desarrollo A continuación, se detalla el proceso de desarrollo del ciclo de vida de un proyecto que hace uso de la metodología AMDD: Modelo inicial de requerimientos (Initial Requirements Envisioning), es necesario tomar varios días para identificar algunos de los requisitos de alto nivel y el alcance del software, todo esto como una primera versión del sistema. Lo que se busca con esto es conseguir un buen entendimiento del proyecto, haciendo uso de modelos que exploren como el usuario trabaja en su entorno, obteniendo de esto un modelo inicial del dominio, donde se identifique los tipos fundamentales de entidades de negocio y José Germán Núñez Mori Página 24 de 237

26 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 las relaciones entre ellas, y un modelo de interfaz de usuario que explore UI y cuestiones de usabilidad. Modelo inicial de la arquitectura (Initial Architectural Envisioning), se centran los esfuerzos en tratar de identificar una arquitectura que encaje a la forma en que trabajará el nuevo sistema. Con esta arquitectura, se permitirá fijar la dirección técnica para el proyecto y proporcionar información suficiente para la organización del equipo alrededor de esta arquitectura (importante para proyectos de gran escala). De este modelado inicial, perteneciente a la iteración de Previsión (Envisioning), se obtendrá: diagramas de forma libre que exploren la infraestructura técnica y los primeros modelos de dominio que permitan explorar las principales entidades empresariales y sus relaciones. Con esto se busca tener lo suficiente como para que el equipo pueda ponerse en marcha A continuación se detalla la etapa de Desarrollo (Development) de un proyecto basado en AMDD: Iteración de modelado (Iteration Modeling), donde al comienzo de cada iteración de desarrollo, el equipo debe planificar el trabajo que hará en la iteración en base a un modelo de actividades, basado principalmente en la prioridad de los requisitos. Modelo de asalto (Model Storming), consiste en reuniones improvisadas de cinco a diez minutos, donde integrantes del equipo se reúnen alrededor de una herramienta de modelado o una pizarra, con el objetivo de analizar una serie de dudas o cuestiones de uno o varios modelos y darles respuestas a cada una de estas, una vez terminada esta reunión los integrantes del equipo siguen su labor de construcción. AMDD, plantea que a final de cada construcción se realice pruebas unitarias del código desarrollado y la refactorización si fuese necesario, todo esto basado en el Test Driven Development (TDD). 4.4 Scrum La definición de esta metodología, se ha realizado tomando como base las siguientes referencias: [KSXHB09], [JSUT09]. [JPAL02], [SMHR04] Descripción Scrum, plantea un proceso de desarrollo de software iterativo y creciente, utilizado José Germán Núñez Mori Página 25 de 237

27 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 comúnmente en entornos basados en el desarrollo ágil de software. Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums. Scrum, por sus características no es válido para cualquier proyecto persona o equipos de personas, es optimo para equipos de trabajo de hasta 8 personas, auque existen empresas que han utilizado con éxito scrum con equipos mas grandes Principio básicos Existen dos aspectos fundamentales a diferenciar en Scrum que son: los actores y las acciones, donde los actores son los que ejecutan las acciones. Los actores contemplados en esta metodología son los siguientes: Product Owner, conoce y marca las prioridades del proyecto o producto. Scrum Master, es la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas. Scrum Team, son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner. Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades. Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar que a continuación se indica, tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo: Product backlog, corresponde con todas las tareas, funcionalidades o requerimientos a realizar que son marcadas por el Product owner. Sprint backlog, corresponde con una o mas tareas que provienen de la lista de tareas (Product backlog), donde estas tareas se deben acometer en unas 2 semanas o 4 semanas. Existe una norma fundamental que mientras un Sprint backlog se inicia no debe ser alterado o modificado, hay que esperar a que concluya para hacerlo. Dayli scrum meeting, es una tarea iterativa que se realiza todos los días que dure el Sprint backlog con el equipo de desarrollo, con lo cual se busca identificar obstáculos o riesgos que impidan el normal avance, verificar el avance de las tareas y la planificaciones de las mimas para el día. José Germán Núñez Mori Página 26 de 237

28 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Sprint planning meeting, son reuniones cuyo objetivo es planificar el Sprint Backlog a partir del Product Backlog, suelen participar el Scrum master, Scrum team y el Product owner. Sprint review, una vez finalizado un Sprint backlog, se revisa en aproximadamente dos horas si se ha obtenido un producto que pueda ver y tocar el Cliente o usuario, donde un Scrum team es quien muestra los avances. Sprint retrospective, el Product owner revisará con el equipo los objetivos marcados inicialmente en el Sprint backlog concluido, se aplicarán los cambios y ajustes si son necesarios, y se marcarán los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint backlog Proceso de desarrollo El proceso parte de la lista de tareas (Product backlog), que no son otra cosa que los requisitos del producto y que actúa como un plan del proyecto. De esta lista el cliente prioriza los requisitos basándose en objetivos, balanceando el valor que le aportan a su coste y quedando repartidos en iteraciones y entregas (Sprint backlog), De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla mediante la replanificación de objetivos que se puede realizar al inicio de cada iteración. Cada día de una iteración debe realizarse una reunión con los integrantes del equipo con el objetivo de obtener de primera mano los avances de las tareas y los obstáculos que se van presentando a lo largo del desarrollo de la iteración Una vez finalizado un Sprint backlog, se revisan con el usuario o cliente los productos obtenidos (Sprint review) y si cumplen con las necesidades plasmadas por el usuario al inicio de la iteración. Cada fin de un Sprint Backlog, se debe revisar los aspectos positivos y negativos del mismo con el objetivo de poder utilizar estos para una mejor planificación de la siguiente iteración a realizar. 4.5 Dynamic Systems Development Method (DSDM) La definición de esta metodología, se ha realizado tomando como base las siguientes referencias: [DSDM09], [MART91], [SMHR04], [WDSDM09], [JCCA08]. José Germán Núñez Mori Página 27 de 237

29 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version Descripción La metodología Dynamic system development Method (en adelante DSDM), es una metodología que surgió de un consorcio formado por 17 miembros fundadores en enero del El objetivo de este consorcio era producir una metodología de dominio público que fuera independiente de las herramientas y que pudiera ser utilizada en proyectos de tipo RAD (desarrollo de aplicaciones rápidas) Principios básicos La estructura de esta metodología fue guiada por 9 principios: El involucramiento del usuario es imperativo. Los equipos de DSDM deben tener el poder de tomar decisiones. El foco está puesto en la entrega frecuente de productos. La conformidad con los propósitos del negocio es el criterio esencial para la aceptación de los entregables. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución del negocio. Todos los cambios durante el desarrollo son reversibles. Los requerimientos están especificados a un alto nivel. El testing es integrado a través del ciclo de vida. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. DSDM tiene las bases sentadas para el análisis sobre su aplicabilidad a un grupo bien definido de proyectos software, los cuales deberán tener las siguientes características: Son proyectos interactivos con la funcionalidad visible en la interfase de usuario. De baja o media complejidad computacional. Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran tamaño. Acotados en el tiempo. Con flexibilidad en los requerimientos. Con un grupo de usuarios bien definidos y comprometidos al proyecto. Esta metodología planeta 5 fases en la construcción de un sistema, las cuales son: Estudio de factibilidad. José Germán Núñez Mori Página 28 de 237

30 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Estudio del negocio. Iteración del modelo funcional. Iteración del diseño y construcción. Implementación. Figura 3: Ciclo de vida de un proyecto AMDD Proceso de desarrollo La metodología plantea que en la fase de estudio de la factibilidad, se permita determinar si la metodología se ajusta al proyecto en cuestión, es decir, si las pautas dadas por DSDM pueden utilizarse de manera optima para llevar acabo el sistema. José Germán Núñez Mori Página 29 de 237

31 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Durante el estudio del negocio, se involucra al cliente de forma temprana, para tratar de entender la operativa que el sistema deberá automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las características de alto nivel que deberá contener el software y las prioridades de las mismas. Cabe destacar que tanto la fase de estudio de factibilidad, como de estudio del negocio, son tareas secuenciales y se realizan una única vez al principio del proyecto y las demás fases siguen el modelo iterativo incremental integrado con la retroalimentación (feedback) del cliente y las entregas frecuentes del producto. En la iteración de modelo funcional, se realizan tanto tareas de análisis como desarrollo de prototipos. Los prototipos no se descartan por completo, sino que a medida que su calidad va aumentando, se va incluyendo en el sistema final. Esta iteración genera un modelo funcional, el cual contiene el código del prototipo y los modelos de análisis. En la iteración de diseño y construcción, es donde se construye el sistema, dando como resultado final, un sistema probado, que satisface los mínimos requisitos establecidos. La iteración de implementación, consiste en pasar del entorno de desarrollo al entorno de producción. Se da formación a los usuarios y finalmente se abre el sistema para que sea utilizado. En esta fase, además de la liberación del sistema, se debe entregar manuales de usuario e informes de revisión del proyecto. En este punto, la metodología DSDM, define cuatro posibles situaciones: No se necesita realizar mayor desarrollo. Se han dejado de realizar un conjunto de requisitos importantes, y en este caso se tiene reiniciar el proceso desde el principio. Se han dejado sin implementar funcionalidades críticas, por lo tanto se vuelve a la fase de modelo funcional. Existen problemas técnicos que no se han podido resolver debido a la falta de tiempo, por lo tanto, se corregirán realizando las iteraciones que hagan falta desde la fase de diseño y construcción. DSDM, no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto, ni José Germán Núñez Mori Página 30 de 237

32 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 siquiera impone el desarrollo bajo un paradigma específico, funciona tanto para el modelo orientado a objetos como para el modelo estructurado. En la metodología DSDM, se incluye un nuevo término llamado timebox, que no es más que las iteraciones a lo largo del ciclo de vida del proyecto. Debido a que cada timebox esta relacionado con entregables al final de los mismos y de los feedback por parte de los clientes, constan de tres fases: Investigación, donde se verifica que las actividades del timebox coincidan con la arquitectura del sistema. Refinamiento, donde se realiza la producción de los artefactos planificados en la iteración. Consolidación, donde se completan los entregables verificando la calidad de los mismos. 4.6 Feature Driven Development (FDD) La definición de esta metodología, se ha realizado tomando como base las siguientes referencias: [CLEP09], [COAD98], [WFDD09] Descripción La metodología Feature driven development (en adelante FDD), se estructura alrededor de la definición de features que representan las funcionalidades que debe contener el sistema a desarrollar y tiene un alcance lo suficientemente corto como para ser implementado en un par de semanas. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente, que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio Principios básicos FDD, posee una jerarquía de features, siendo el del eslabón superior el feature set, que agrupa un conjunto de features relacionados con aspectos en común del negocio. Por último se establece el major feature set que contribuye a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Esta jerarquía utiliza los siguientes formatos Para features: <acción> el <resultado> <de para sobre por> un <objeto> José Germán Núñez Mori Página 31 de 237

33 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Para feature sets: <acción><-endo> un <objeto> Para major feature sets: administración de <acción> Ejemplos de esto: Calcular el total de la facturación de Noviembre (feature) Modificar el estado de las facturas de producción (feature) Administrar el perfil de los proveedores (feature) Haciendo una venta a un cliente (feature set) Cargando la facturación de los proveedores (feature set) Administración de Bancos (major feature set) FDD, propone un ciclo de vida del software que consta de cinco procesos: Development an overall model. Build a features list. Plan by feature. Design by feature. Build by feature. Donde las dos últimas fases se realizan tantas veces como iteraciones se planifiquen en el desarrollo. José Germán Núñez Mori Página 32 de 237

34 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Figura 4: Ciclo de vida de un proyecto FDD Proceso de desarrollo La primera actividad plateada por FDD es: Development an overall model, la cual, consiste en desarrollar un modelo global, que sugiere un cierto paralelismo con la construcción de la arquitectura del software. Para la construcción de este modelo participan tanto los expertos en el dominio como los desarrolladores. Con esto se intenta lograr: Un conocimiento global de la aplicación a construir, el entendimiento del negocio en que esta embebido, un primer bosquejo de los features del software y la definición de las restricciones y cuestiones no funcionales. José Germán Núñez Mori Página 33 de 237

35 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 La segunda actividad (Build a features list), comienza tomando el bosquejo de features formulado durante la actividad anterior para refinar las funcionalidades incluidas. Una vez que se han identificado las mismas se las agrupa jerárquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorización de las mismas basándose en la satisfacción al cliente. La tercera actividad (Plan by features), toma como input la lista priorizada de la fase anterior y establece los tiempos de las futuras iteraciones. En esta actividad participan el líder de proyecto, el líder de desarrollo y el programador jefe. A medida que se realiza la planificación se delinean los hitos de finalización de las iteraciones, dejando asentado cuales son los features y features sets que estarán construidos en dichos hitos, en esta etapa también se incluye la delegación de responsabilidades. Las dos últimas actividades, Diseñar por features y construir por features, están relacionadas con la parte productiva del proceso en que se construye la aplicación de manera incremental. Para la iteración del diseño, el Jefe de programadores junto con un grupo de Programadores expertos identifica las clases, atributos y métodos que necesita la funcionalidad requerida en un feature. Mediante la utilización de diagramas UML se verifica que el diseño pueda ser implementado. Posteriormente en la etapa de construcción por feature, se proceden a desarrollar las clases definidas en la anterior actividad con sus respectivas pruebas unitarias. Una vez que se pasa estas pruebas es inspeccionado el código por equipos asignados a la revisión del feature en desarrollo, una vez finalizado esta revisión se promueve el código a BUILD, siendo entregado a Gestión de la configuración. La metodología recomienda reuniones semanales entre el Líder del proyecto y el Jefe de los programadores, donde, se permita revisar el estado de los features que se están desarrollando. 5 Comparativa entre metodologías ágiles En esta sección se realizará una comparativa entre cada unas de las metodologías mencionadas en la sección cuatro, tomando como base la referencia: [JCCA08]. Esta comparativa se basa en una serie de criterios relevantes, con los cuales se busca obtener las José Germán Núñez Mori Página 34 de 237

36 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 características fundamentales de las metodologías en estudio. Dentro de los criterios a considerar tenemos Ciclo de vida del proyecto, donde tomaremos como base el ciclo de vida estándar de un proyecto. Soporte a la gestión en cada unas de las etapas del ciclo de vida del proyecto. Buenas prácticas, actividades y artefactos producidos en las distintas etapas planteadas por la metodología. Estado actual de la metodología. Soporte a la calidad en el planteamiento de la metodología. Herramientas específicas que pueden dar soporte a la metodología en cuestión. 5.1 Criterios de comparación En esta sección se detallará cada uno de los criterios necesarios para la comparativa entre las metodologías ágiles en estudio Ciclo de vida del proyecto Para este criterio se va a considerar las siguientes etapas como parte del ciclo de vida de un proyecto estándar: Principio del proyecto. Especificación de requisitos. Análisis y Diseño. Codificación Pruebas unitarias. Pruebas de integración. Pruebas de sistemas. Pruebas de aceptación. Sistema en uso o mantenimiento. En base a las etapas mencionadas anteriormente, se analizará si cada una de las metodologías en estudio contempla estas etapas, si describe buenas prácticas y/o actividades y si sugiere artefactos de salida por etapa, de acuerdo a esto, el resultado se muestra en la siguiente tabla (ver tabla 1 Ciclo de vida tradicional de un proyecto software en las metodologías ágiles): José Germán Núñez Mori Página 35 de 237

37 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Principio del Espec. Anális y Pruebas Pruebas de Pruebas de Pruebas de Codificación Proyecto Requisitos Diseño Unitarias Integración Sistemas Aceptación Mantenimiento Metodología SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA Programación Extrema (XP) X X X X X X X X X X X X X X X X Scrum X X X X X X X X X X X X Dynamic Systems Development Method (DSDM) X X X X X X X X X X X X X X X X X X Proceso Unificado ágil (AUP) X X X X X X X X X X X X X X X X X X X X X X X X X X X Agile Model Driven (AMDD) X X X X X X X X Feature Driven Development (FDD) X X X X X X X X X X X X SG: Soporte a la gestión. PD: Se describe un proceso en el método que incluye esta etapa. BA: Buenas prácticas, actividades y artefactos considerados en la etapa. Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologías ágiles. José Germán Núñez Mori Página 36 de 237

38 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version Estado Actual Para este criterio se tomará en cuenta, los siguientes estados en los cuales se podría encontrar las metodologías en estudio: Recién nacida, metodologías que tiene un año o menos y de la cual no tenemos evidencias ni estudios. En construcción, metodologías con más de un año de existencia, pero que no dispone de evidencia documentada. Activa, metodologías que llevan muchos años en el desarrollo del software y de las cuales podemos encontrar evidencias y estudios que corroboren su efectividad. Olvidada, metodologías que llevan tiempo sin ser utilizadas y de las cuales no se encuentra evidencia. A continuación una tabla (ver tabla 2 Estado actual de las metodologías ágiles), que informan el estado actual de cada una de las metodologías en estudio: Metodología Programación Extrema (XP) Scrum Dynamic Systems Development Method (DSDM) Proceso Unificado Ägil (AUP) Agile Model Driven (AMDD) Feature Driven Development (FDD) Estado a la fecha Activa Activa Activa Actica Activa Activa Tabla 2: Estado actual de las metodologías ágiles Calidad Con este criterio se busca analizar si las metodologías en estudio contemplan ciertos parámetros de calidad en su enunciado metodológico. Dentro de los parámetros a considerar en el análisis tenemos: Fiabilidad, la cual viene determinada por los siguientes atributos: Simplicidad, simplicidad de los diseños, en la implementación y en el desarrollo del José Germán Núñez Mori Página 37 de 237

39 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 software en general. Trazabilidad, entre los artefactos producidos en las distintas etapas del ciclo de vida del software. Usabilidad, esta parámetro viene determinado por los siguientes atributos: Claridad y precisión de la documentación. Habilidades que mejoren las pruebas del software. Mantenibilidad, este parámetro viene determinado por los siguientes atributos: Modularidad, esto ayuda a crear una documentación mas fácil de entender. Simplicidad, si la metodología promueve que los sistemas desarrollados bajo su enfoque sean simples al momento de mantenerse. Adaptabilidad. Portabilidad, si bajo su enfoque promueve que el software producido pueda operar en distintos entornos. A continuación una tabla (ver tabla 3 Comparativa de calidad en las metodologías ágiles), que informan, los criterios de calidad asociados a cada unas de las metodologías en estudio: Metodología Fiabilidad Usabilidad Mantenibilidad Adaptabilidad Programación Extrema (XP) X X X Scrum X X Dynamic Systems Development Method (DSDM) X X X Proceso Unificado Ágil (AUP) X X X Agile Model Driven (AMDD) X X X Feature Driven Development (FDD) X X Tabla 3: Comparativa de calidad en las metodologías ágiles Herramientas Con este criterio se busca dar a conocer las distintas herramientas que las metodologías en estudio requieren para cumplir cada unas de las tareas que especifica su enunciado. Para esto se enfatizó la búsqueda de herramientas de libre distribución. José Germán Núñez Mori Página 38 de 237

40 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 A continuación, se presenta una tabla (ver tabla 4 Herramientas de libre distribución para metodologías ágiles), donde se detalla alguna de las herramientas de libre distribución, con las cuales se puede ejecutar cada una de las metodologías en estudio: Metodología Herramientas Programación Extrema (XP) o Herramientas para la realización de refactorización, IDEs como Eclipse y NetBeans. o Herramienta de integración continua: Cruise Control. o Herramientas de administración de proyectos y compilaciones automáticas: Maven y Ant. o Repositorio de códigos: CVS y Subversión. o Herramientas para pruebas unitarias: JUnit. o Herramientas para la medición de rendimiento de aplicaciones : JMeter Scrum Agile Model Driven (AMDD) Proceso Unificado Ägil (AUP) Dynamic Systems Development Method (DSDM) Desarroollo rápido de aplicaciones (RAD) Feature Driven Development (FDD) A pesar de no ser necesaria ninguna herramienta especial, están surgiendo aplicaciones Web que facilitan el seguimiento del proyecto y la generación de los distintos artefactos de la metodología, que frecuentemente se realizan con paquetes ofimáticas. o Herramienta de diagramación de modelos: Visual Paradigm, eclipse (con plugins respectivos) o Herramienta que te permite generar código en base a diagramas: AndroMDA encapsulado con funcionalidad de MAVEN. Para esta metodología son necesarias las herramientas mencionadas tanto para le metodología XP como para AMDD, además de estas herramientas se podría mencionar: o Herramientas de cobertura y evaluación de complejidad ciclomática: MAVEN.: No especifica ninguna práctica concreta que necesite de una herramienta específica. o Herramientas que en base a prototipos genere código: IDEs como NetBeans y eclipse. o Herramientas de modelado como Visual Paradigm. o Herramientas ofimáticas. o Herramientas de refactorización: IDEs como eclipse y NetBeans. Tabla 4: Herramientas de libre distribución para metodologías ágiles. José Germán Núñez Mori Página 39 de 237

41 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version Conclusiones de la comparativa De acuerdo a los criterios utilizados para la comparativa, se ha llegado a las siguientes conclusiones a mencionar: No todas las metodologías ágiles contemplan todo el ciclo de vida tal y como lo hemos visto tradicionalmente, como se puede apreciar en la Tabla 1, presentada en la comparativa de ciclo de vida de un proyecto, la metodología que contempla todas las etapas es la metodología AUP, esto debido a que es una metodología que se basa en RUP, pero a la vez esta metodología sugiere que solo se utilice las etapas que sean necesarias para el proyecto, con lo cual pude que se cumpla con toda o parte de las etapas tradicionales. El estado actual de las metodologías ágiles es activo y va ganando cada vez más adeptos. Las metodologías ágiles están orientadas a la productividad, es por este motivo que en la comparativa de calidad solo algunas de las metodologías cumple con la gran parte de los parámetros de calidad. Con relación a las herramientas de distribución libre, como se ha podido apreciar hoy en día existen muchas herramientas que ayudan ya en el proceso de las metodologías ágiles (ver Tabla 4). 5.3 Adopción de metodologías Los criterios de comparación utilizados en esta sección son solo algunos de los criterios por los cuales se puede llevar a cabo una comparativa entre metodologías ágiles y nos da una idea de cual es el enfoque de la metodología en cuestión que nos permitirá decidir por una de las metodologías presentadas. La adopción de una o varias metodologías, en vez de otras, tan solo tiene sentido si establecemos un caso lo suficientemente concreto, invalidando cualquier tipo de generalización y por ende una metodología se hace necesaria para cada solución. En base a lo expuesto a lo largo de esta sección, concluimos que las metodologías ágiles son un conjunto de prácticas y métodos que surgen de la experiencia y el estudio de muchos proyectos software, de acuerdo a esto, la elección de una u otra metodología será en base a las necesidades que tenga un proyecto por ejemplo: Si el proyecto necesita pautas claras de gestión, se debería seleccionar Scrum y AUP. José Germán Núñez Mori Página 40 de 237

42 La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0 Si se ve que el proyecto presentará ratios de error elevados, se debe utilizar XP o AUP, debido a que ambas metodologías hace uso del Test Driven Development (TDD). O quizás si es un proyecto interactivo con la funcionalidad visible en la interfase de usuario, se debería optar por DSDM. Para el caso de estudio que se llevará a cabo, y tomando como premisa que es un caso concreto de investigación, donde se busca adaptar en la metodología o metodologías seleccionadas el principio de Usabilidad, se ha visto conveniente combinar tres de las metodologías, con el objetivo de dar una cobertura ágil a un ámbito más amplio del ciclo de vida del software. Las metodologías seleccionadas son: Scrum, para la parte de gestión del proyecto. XP, por ser una metodología que cubre las actividades que desde el plano completo de la ISO 12207, perteneciente al desarrollo de software. AUP, por ser una metodología que contiene a XP y tiene las formalidades de RUP. José Germán Núñez Mori Página 41 de 237

43 La Usabilidad en Metodologías Ágiles III. Marco Ágil de trabajo Versión 1.2

44 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Historia del documento Fecha Version Descripción Autor 10/11/ Marco ágil de trabajo José Germán Núñez Mori 06/06/ Marco ágil de trabajo José Germán Núñez Mori 12/10/ Marco ágil de trabajo José Germán Núñez Mori José Germán Núñez Mori Página 43 de 237

45 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version Introducción De acuerdo a lo expuesto en el capítulo de Metodologías ágiles, se llego a la conclusión, de seleccionar tres de las metodologías ágiles planteadas a lo largo del capítulo. Esta selección, se realiza después de analizar que las metodologías ágiles son prácticas focalizadas sobre un área de conocimiento, más o menos delimitada, de la Ingeniería del Software [JPAL02]. Con las metodologías ágiles seleccionadas, se busca combinar varias de las prácticas de cada una de estas metodologías, para dar una mayor cobertura ágil a un ámbito más amplio del ciclo de vida del software [JPAL02]. En el presente capítulo, se planteara un marco ágil de trabajo, que contenga ciertas prácticas y actividades de cada unas de las metodología seleccionadas en el capitulo anterior (AUP, XP y Scrum), todo esto, con el objetivo de obtener lineamientos a seguir a lo largo de los siguientes capítulos, y en los cuales se pueda añadir los principios de Usabilidad. 2. Planteamiento metodológico En la presente sección, se dará a conocer el planteamiento de este marco de trabajo ágil, que busca combinar, practicas y actividades, de cada una la metodologías seleccionadas, que en conjunto, se adapten a los requerimientos o necesidades del presente trabajo. Las metodologías seleccionadas, como ya se ha descrito en el capitulo anterior (Metodologías Ágiles) son: SCRUM, AUP y XP. De estas metodologías se ha analizado, tanto sus principios básicos como su planteamiento metodológico, donde en base a este análisis, se ha llegado a la conclusión, de utilizar ciertas actividades y prácticas de cada una de estas metodologías y así obtener un marco ágil que se ajuste a lo requerido. Las actividades y prácticas seleccionadas, tanto de las metodologías Scrum como AUP, formarán la carrocería del marco ágil de trabajo. Esto debido, al enfoque que tienen estas metodologías, consiguiendo de esta manera, los lineamientos para la gestión (plateada por Scrum) y las formalidades del Proceso Unificado (planteada por AUP) en la ejecución del ciclo de vida del software, con lo cual, se dejará a la metodología XP enfocada directamente en el plano de desarrollo. La metodología AUP, sugiere optar por un conjunto pequeño de actividades y artefactos del José Germán Núñez Mori Página 44 de 237

46 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Proceso Unificado [CRLA02] [JOKR05]. Siguiendo esta idea, se ha optado por utilizar ciertas fases y actividades que plantea AUP, las cuales serán gestionadas por los lineamientos de SCRUM. Consiguiendo de esta manera también incluir prácticas de XP en este marco ágil de trabajo [SABL06] [KEBE02]. Bajo los lineamientos de este marco de trabajo ágil, se ira incluyendo los principios de usabilidad, es decir, se buscará en todo momento mejorar la usabilidad como un atributo de calidad, tomando en cuenta así, estos patrones desde la etapa inicial del marco ágil (requisitos), luego trasmitiéndose a las etapas siguientes como son diseño e implementación. 3. Estructura Metodológica En la presente sección, se describirá cual es la estructura que tendrá el marco ágil de trabajo y en base al cual, se desarrollarán los siguientes capítulos. El marco ágil de trabajo, se basará en el ciclo de vida del software plateando por AUP, a la cual se le añadirá actividades y prácticas, tanto de la metodología Scrum como XP, es decir, se tendrá como base el siguiente modelo [SABL06]: Figura 5: Ciclo de vida AUP Como se muestra en la figura 5, a simple vista es el modelo clásico planteado por el Proceso Unificado. Sin embargo, este modelo es mas simple, debido a que reúne, en una única disciplina como es la de Modelo: el modelado de negocio, requisitos y análisis y Diseño. El resto de disciplinas como se pude apreciar coinciden con las planteadas por el Proceso Unificado José Germán Núñez Mori Página 45 de 237

47 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 [KINT07]. El marco ágil de trabajo, tal cual se describe en líneas anteriores, seguirá la estructura planteada por AUP, con la salvedad, de solo incluir ciertas disciplinas, como son: Modelo, Implementación, Prueba, Despliegue y gestión de proyecto. De esta manera, el ciclo de vida que plantea el marco ágil de trabajo, se muestra en la siguiente figura 6: Figura 6: Ciclo de vida del marco ágil de trabajo El modelo presentado en la figura 6 (Ciclo de vida del marco ágil de trabajo), es un modelo más reducido que el plateado por AUP, esto debido, a que es un ciclo de vida que se adapta a las necesidades, que el marco ágil, solventará a lo largo del presente trabajo. Además esta formalidad que se asume, permitirá que en cada una de las fases y disciplinas, de este ciclo de vida planteado, se pueda realizar el estudio de la viabilidad de incluir los principios de usabilidad. En la figura 6, se aprecia además, que en cada fase se manejan iteraciones, esto debido, a que el marco ágil de trabajo, tendrá un enfoque de desarrollo iterativo, el cual se organizará en una serie de mini proyectos de duración fija, llamado iteraciones. Donde el resultado de cada iteración será una parte del sistema que pueda ser probada, integrada y ejecutada. Estas fases plateadas por el marco ágil, no constituyen el antiguo ciclo de vida secuencial, si no mas bien, la fase de inicio no es solo una fase de requisitos si una especia de fase de viabilidad, donde se lleva a cabo solo el estudio suficiente para decidir si continuar. La fase de elaboración no es la fase de requisitos o de diseño, si no que es una fase donde se implementa de manera iterativa la arquitectura que constituye el núcleo central donde se mitigan las cuestiones de alto riesgo y en la fase de construcción se implementan de manera iterativa el resto de requisitos de José Germán Núñez Mori Página 46 de 237

48 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 menor riesgo y se prepara para el despliegue [SABL06] [CRLA02]. De acuerdo a esta estructura, a lo largo de esta sección se detallará, el planteamiento del marco ágil de trabajo sobre cada una de las fases y disciplinas mencionadas anteriormente. Adicionalmente al planteamiento, el marco ágil describirá el mecanismo a seguir para cumplir con lo planteando, sugiriendo así, herramientas y formatos que ayudarán a cumplir este objetivo. 3.1 Fases del marco ágil de trabajo En esta sección se detallara cada una de las fases planteadas por el marco ágil de trabajo ver figura 2 (Ciclo de vida del marco ágil de trabajo) Inicio (Inception) Para esta fase de inicio el marco ágil de trabajo, plantea lo siguiente: Obtención de los requisitos funcionales y no funcionales de alto nivel, siguiendo el planteamiento XP y tomando en cuenta los principios de usabilidad. Proceso de aceptación de los principios de usabilidad incluidos, considerando el planteamiento AUP. Gestión de requisitos funcionales y no funcionales, siguiendo el planteamiento Scrum. En base a estos puntos, se tendrá un hito de fase, el cual representará los artefactos que esta fase producirá al final de la misma. De acuerdo a esto, los artefactos considerados como hito de fase son los siguientes: Historias de Usuarios Pruebas de Aceptación de los requerimientos de usabilidad. Product Backlog (Cartera de productos). Esta primera fase se resume en el siguiente diagrama (figura 7), donde se muestra tanto el planteamiento como los hitos de la misma [SABL06]: José Germán Núñez Mori Página 47 de 237

49 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Figura 7: Hito de la fase de Inicio Historias de Usuarios Los requisitos tanto funcionales como no funcionales, serán obtenidos en base a lo sugerido por la metodología XP, que son las llamadas Historias de usuarios, que es donde los usuarios, dan a conocer las funcionalidades que esperan del producto. Cada historia de usuario a considerarse como parte del producto final, será registrada siguiendo el siguiente formato [SALECA05] [KEBE02]: Historia de Usuario Nº : <<Descripción abreviada>> Nombre: Prioridad: Descripción Usuario de Creación Estimación. Fecha Alta: Dependencia: Figura 8: Formato de Historias de usuarios según XP Sobre este formato (ver figura 8), el marco ágil de trabajo, incluirá la manera para elicitar los requisitos de usabilidad, buscando así, incluir los principios de usabilidad desde la fase de toma de requerimientos, con el objetivo de obtener los mismos beneficios que teniendo en cuenta otros atributos de calidad en los inicios de los procesos de desarrollo. De acuerdo a esto, el marco ágil plantea, un nuevo formato para recoger las historias de usuarios y a su vez los requisitos de usabilidad: José Germán Núñez Mori Página 48 de 237

50 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Historia de Usuario Nº : <<Descripción abreviada>> Nombre: Prioridad: Descripción Usuario de Creación Estimación. Requisito System Status Feedback Interaction feddback Progress feedback Warning Globall Undo Object Specific undo Fecha Alta: Dependencia: Requisitos de Usabibilidad Asociados Apicación Comentarios Figura 9: Formato de Historias de usuarios según el marco ágil. Como se puede apreciar en la figura 9, el marco ágil de trabajo, adiciona al formato de historias de usuario una sección para recoger los requisitos de usabilidad relacionados a una historia en particular. Es por este motivo, que en la sección de requisitos de usabilidad, se listarán todos los requisitos contemplados, dando así la opción al usuario que hace uso de este formato de seleccionar el requisito asociado y describir la manera en que se debe plasmar en una historia. El marco ágil de trabajo, sugiere que este formato se debe plasmar o en cartillas o en un documento electrónico, el cual debe entregarse al usuario para ser rellenado con la información de las funcionalidades a contemplarse y sus respectivos principios de usabilidad asociados, no siendo estrictamente, un documento a ser rellenado por los usuarios, si no también por los encargados de la elicitación de requisitos Pruebas de Aceptación Como un artefacto de salida de esta fase inicial, se debe contemplar procesos de aceptación, que garanticen la calidad del producto final. De acuerdo a esto, la metodología AUP, plantea una serie de procesos de aceptación, de donde, solo se tomará uno de ellos que ayude a garantizar la calidad de los principios de usabilidad a incluir en el ciclo de vida del software plateado. El proceso de aceptación seleccionado es el llamado pruebas de aceptación, que son básicamente pruebas funcionales sobre el sistema completo y que buscan una cobertura de la especificación de requisitos. En nuestro caso de estudio, estas pruebas de aceptación buscarán la José Germán Núñez Mori Página 49 de 237

51 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 cobertura de la especificación de los requisitos de usabilidad elicitados. En esta fase de Inicio, las pruebas de aceptación, según el marco ágil de trabajo, consistirán en la redacción de pruebas mínimas para la validación de los requisitos de usabilidad, las cuales se basarán estrictamente en las historias de usuarios asociados. De acuerdo a esto, el proceso de aceptación tendrá el siguiente formato, mostrado en la figura 10: Id Historia Criterio de validación de los Requisitos de Usabilidad Figura 10: Formato de Pruebas de Aceptación. Para este formato (ver figura 10) de pruebas de aceptación, el marco ágil, sugiere se plasme en un documento electrónico y se rellene por cada historia de usuario las pruebas mínimas que garanticen el funcionamiento esperado de los requisitos de usabilidad asociados. Siendo este documento redactado por los encargado del análisis de las historias de usuarios. Este artefacto una vez culminado, deberá de ser entregado al equipo de pruebas, con el objetivo, de tomar futuras previsiones en las pruebas generales del sistema Product Backlog Cada historia registrada por los usuarios, será gestionada para su resolución, por medio del Product Backlog, que es el inventario de funcionalidades, mejoras, tecnologías y corrección de errores, que deben incorporarse al producto a lo largo de sucesivas iteraciones [JPAL02]. El Product Backlog, es un documento vivo, que evoluciona de forma continua, mientras el producto va creciendo, este artefacto es planteado por la metodología Scrum y será un artefacto utilizado por el marco ágil. Esta manera de llevar el control de cada historia de usuario es simplemente, con el objetivo de tener a primera vista y de manera muy resumida, las funcionalidades que se espera del producto. Además a este artefacto tendrán acceso todos los integrantes del equipo. Por lo tanto, el Product Backlog seguirá el siguiente formato [JPAL02]: José Germán Núñez Mori Página 50 de 237

52 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Id. Historia Descripción Prioridad Estimación Observaciones Responsable Figura 11: Formato del Product Backlog Como se puede apreciar en la figura 11, el Producto Backlog, es un listado en donde se tendrá el control de todas las historias de usuarios registradas, de una manera mucho mas resumida, y que permitirá de una manera más ágil tener una visión global de todas las funcionalidades del producto. El marco ágil de trabajo, sugiere que este formato sea plasmado en un documento electrónico y sea rellenado y gestionado por el encargado de llevar a cabo el producto, garantizando de esta manera que este accesible a todas las personas que participan en el desarrollo del sistema Elaboración En esta fase el marco ágil de trabajo, basará su enfoque en lo que plantea la metodología AUP (Agile Unified Process), tomando en cuenta así las disciplinas y prácticas sugeridas. El objetivo principal de la fase de elaboración es probar la arquitectura del sistema a desarrollar. El punto es asegurar que el equipo realmente puede desarrollar un sistema que satisfaga los requisitos, y la mejor manera de hacerlo es construir un esqueleto del sistema, llamado un "prototipo de la arquitectura" [SABL06]. Es importante señalar que los requisitos no se especifican por completo en este punto. Se detallan sólo lo suficiente para entender los riesgos de la arquitectura a plantear y para asegurar que hay un entendimiento del alcance de cada requisito, todo esto, con el objetivo de la futura planificación a llevarse a cabo y de identificar y priorizar los riesgos de la arquitectura, donde, los mas significativos serán tratados en esta fase de elaboración [SABL06]. Como se muestra en la figura 6 (Ciclo de vida del marco ágil de trabajo), la disciplina de modelo (Model) que se ejecuta tanto en la fase de inicio como la de elaboración, sugiere que, para esta última, se inicie con el diseño, específicamente como se describe en líneas anteriores, José Germán Núñez Mori Página 51 de 237

53 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 con el modelado de la arquitectura del sistema. Todo esto basado en que la arquitectura es un aspecto importante de los esfuerzos de desarrollo del software ágil. Para esta fase el marco ágil de trabajo plantea lo siguiente: Identificación de la arquitectura, basada en la metodología MDA. Realizar el plan de ejecución de las primeras iteraciones de construcción. De acuerdo a estos puntos la fase de elaboración cuenta con un hito de fase, que representa los artefactos que esta fase producirá al final de la misma. Estos son los siguientes: Prototipo de la arquitectura del sistema. Plan de ejecución de la primera iteración de construcción. Esta fase se resume en el siguiente diagrama (ver figura 12), donde se muestra tanto el planteamiento como los hitos de la misma [SABL06]: Figura 12 : Hito de la fase de Elaboración Como paso siguiente de esta sección, se detallará cada uno de los puntos planteados como hito, describiendo de esta manera los mecanismos para obtener los artefactos de salida de esta fase de elaboración Prototipo de la arquitectura del sistema Cuando el marco ágil de trabajo, emplea el término de prototipo de arquitectura, hace referencia a que en esta fase de elaboración, se debe obtener un primer modelo de la arquitectura del sistema, donde se reúna las partes, las conexiones y las normas de interacción entre los José Germán Núñez Mori Página 52 de 237

54 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 componentes de este sistema, haciendo uso de conexiones especificas y sobre los que se basarán las posteriores modificaciones en implementaciones a realizar. En base a esta premisa, el marco ágil de trabajo, basado en las distintas metodologías de su planteamiento, buscará un enfoque de metodología, que permita obtener este primer modelo de arquitectura y que esta sirva como estructura principal para las futuras iteraciones de desarrollo. AUP (Agile Unified Process) incluye en su planteamiento una metodología que ayudará en las tareas de modelado de la arquitectura. Esta metodología es conocida como Agile model driven development (AMDD), que en su enfoque principal sugiere que el desarrollo de un sistema sea dirigido por modelos lo suficientemente necesarios para obtener el producto final [SABL06]. Para tener mayor detalle de la metodología AMDD, se puede revisar el capitulo de Metodologías Ágiles. El marco ágil de trabajo, basado en AUP, hará uso del planteamiento de AMDD para desarrollar su enfoque de prototipo de Arquitectura y sus futuras iteraciones de desarrollo, específicamente utilizando el estándar sugerido por esta metodlogía, siendo este, el estándar MDA (Model Driven Architecture). MDA es un estándar, que potencia el uso de modelos en el desarrollo, debido a que usa los modelos para dirigir el ámbito de desarrollo, el de diseño, el de despliegue, el de la operación, el de mantenimiento y el de la modificación de los sistemas. En el marco ágil de trabajo, MDA pretende ser utilizado para dirigir tanto el ámbito desarrollo como el de diseño. Bajo este estándar el marco ágil, en esta fase de elaboración, tendrá como objetivo realizar una primera iteración que permita obtener una parte del sistema que pueda ser probada, integrada y ejecutada. Esta primera iteración, contemplará la ejecución del prototipo de arquitectura, que consistirá en obtener tanto el diseño de este prototipo como el desarrollo del mismo. De esta manera se cumplirá con el objetivo de esta fase, que es la implementación de la arquitectura que constituye el núcleo central donde se mitigan las cuestiones de alto riesgo y cuyo propósito será ayudado por el estándar MDA. Para este prototipo de arquitectura, el marco ágil, sugiere que se selecciona un requisito donde se pueda evaluar los riesgos de la arquitectura y a su vez tenga asociado los requisitos de usabilidad de mayor complejidad, como por ejemplo: Progress Bar. José Germán Núñez Mori Página 53 de 237

55 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 A continuación, se detallara la especificación del estándar MDA, buscando así entender, el desarrollo dirigido por modelos y cómo se hará uso del mismo para lograr obtener uno de los hitos de esta fase (Prototipo de la Arquitectura) Estándar MDA (Model Driven Architecture) En esta sección se detallará la especificación del estándar MDA, basado en la siguientes referencias: [LECCO09], [MDAWI10], [OMGWB10]. La arquitectura dirigida por modelos (Model Driven Arquitectura) es una especificación detallada por el OMG (Object Management Group) que integra diferentes especificaciones y estándares definidos por la misma organización, con la finalidad de ofrecer una solución a los problemas relacionados con los cambios en los modelos de negocio, la tecnología y la adaptación de los sistemas de información a los mismos. MDA nos permite el despliegue de aplicaciones empresariales, diseñadas sin dependencias de la plataforma de despliegue y expresando su diseño mediante el uso de UML y otros estándares. Donde estos estándares, pueden ejecutarse en cualquier plataforma existente, abierta o propietaria, como servicios web,.net, Corba, J2EE, u otras. La especificación de las aplicaciones y la funcionalidad de las mismas se expresan en un modelo independiente de la plataforma que permite una abstracción de las características técnicas específicas de las plataformas de despliegue. Mediante transformaciones y trazas aplicadas sobre el modelo independiente de la plataforma se consigue la generación automática de código específico para la plataforma de despliegue elegida. Todo esto proporciona finalmente una independencia entre la capa de negocio, y la tecnología empleada. De esta manera es mucho más simple la incorporación de nuevas funcionalidades, o cambios en los procedimientos de negocio sin tener que llevar a cabo los cambios en todos los niveles del sistema. Bajo este enfoque el marco ágil de trabajo buscará incluir en tiempo de diseño los patrones de usabilidad. Siguiendo este planteamiento, se desarrollan los cambios en el modelo independiente de la plataforma, y éstos se propagarán a la aplicación, consiguiendo por tanto, una considerable reducción del esfuerzo en el equipo de desarrollo. De esta manera también, se disminuye los errores que tienden a producirse en los cambios introducidos en las aplicaciones mediante otros José Germán Núñez Mori Página 54 de 237

56 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 métodos de desarrollo, y por consiguiente, la reducción de costes y aumento de productividad. MDA se apoya sobre los siguientes estándares para llevar a cabo su función: UML (Unified Modeling Language): empleado para la definición de los modelos independientes de la plataforma y los modelos específicos de las plataformas de destino. Es un estándar para el modelado introducido por el OMG. MOF (MetaObjet Facility): establece un marco común de trabajo para las especificaciones del OMG, a la vez que provee de un repositorio de modelos y metamodelos [OMGWB10]. XMI (XML Metada Interchange): define una traza que permite transformar modelos UML en XML para poder ser tratados automáticamente por otras aplicaciones. CWM (Common Warehouse Metamodel): define la transformación de los modelos de datos en el modelo de negocio a los esquemas de base de datos [OMGWB10]. El estándar MDA, establece tres puntos de vista que se emplearán a lo largo de su proceso de ingeniería: Punto de vista independiente de la computación, el cual se centra en el entorno del sistema y los requisitos para el mismo. Los detalles de la estructura y procesamiento del sistema no se muestran, o aún no están especificados. Punto de vista independiente de la plataforma: se centra en las operaciones del sistema, mientras oculta los detalles necesarios para una determinada plataforma. Muestra aquellas partes de la especificación del sistema que no cambian de una plataforma a otra. En este punto de vista debe emplearse lenguaje de modelado de propósito general, o bien algún lenguaje específico del área en que se empleará el sistema, pero en ningún caso se emplearán lenguajes específicos de plataformas. Punto de vista de plataforma específica: combina el punto de vista independiente de la plataforma con un enfoque específico para su uso en una plataforma específica de un sistema. En base a estos puntos de vista, MDA plantea diferentes estados de modelado para lograr obtener el producto final. Estos modelos son los siguientes: Modelo independiente de la computación (CIM), es una vista del un sistema desde el punto de vista independiente de la computación. En algunos casos, nos referimos a este modelo como el modelo de dominio y se usa vocabulario propio de los expertos en el dominio para la especificación. Modelo independiente de la plataforma (PIM), es una vista del sistema del punto de vista independiente de la plataforma, exponiendo así un carácter independiente de la plataforma José Germán Núñez Mori Página 55 de 237

57 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 sobre la que se desplegará. Con esto se logra un modelo que puede ser empleado en diferentes plataformas de carácter similar. Modelo específico de la plataforma (PSM), es una vista del sistema (producto final) desde el punto de vista específico de la plataforma, combinando así el modelo independiente de la plataforma con los detalles específicos de la plataforma del sistema Usando MDA Expuestos los conceptos básicos de MDA, a continuación, se dará a conocer como se relacionan los modelos, su modo de uso y las transformaciones entres ellos. El modelo de origen es el CIM (Modelo independiente de la computación), con el que se modelan los requisitos del sistema, describiendo la situación en que será usado en el sistema y que aplicaciones se espera que el sistema lleve a cabo, sirviendo tanto como ayuda para entender el problema o como una base de vocabulario para usar en los demás modelos. Los requisitos recogidos en el CIM (Modelo independiente de la computación) han de ser trazables a lo largo de los modelos PIM (Modelo independiente de la plataforma) y PSM (Modelo especifico de la plataforma) que los implementan. El CIM, puede consistir en un par de modelos UML que muestren tanto la distribución de los procesos (ODP, Open Distributed Processing) como la información a tratar. También puede contener algunos modelos UML más que especifiquen en mayor detalle los anteriores. A partir del CIM, se construye un PIM, que muestra una descripción del sistema, sin hacer referencia a ningún detalle de la plataforma. Debe presentar especificaciones desde el punto de vista de la empresa, información y ODP. Un PIM se puede ajustar a un determinado estilo de arquitectura, o a varios. Después de la elaboración del PIM, el arquitecto debe escoger una plataforma (o varias) que satisfagan los requisitos de calidad y en base a la trazabilidad obtener el PSM. La figura 13, resume el planteamiento de estos modelos: José Germán Núñez Mori Página 56 de 237

58 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Figura 13: Trazabilidad de Modelos MDA Mapas de Transformación MDA Mediante mapas, MDA especifica las reglas de transformación de un PIM (Modelo independiente de la plataforma) a un PSM (Modelo específico de la plataforma) para una plataforma en concreto. Estos mapas incluyen la transformación de tipos de valores, así como los metamodelos y sus reglas para la transformación en tipos de valores existentes en las plataformas específicas. Cuando se prepara un modelo haciendo uso de un leguaje independiente de la plataforma especificada en un metamodelo y posteriormente se elige una plataforma para el despliegue, debe existir una especificación de transformación entre el metamodelo independiente de la plataforma y el metamodelo que describe la plataforma. La figura 14, ilustra este requisito: José Germán Núñez Mori Página 57 de 237

59 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Figura 14: Transformación de metamodelos bajo MDA. Una forma de facilitar la transformación de modelos es la identificación de elementos en el PIM que deben transformarse de una manera concreta para la plataforma de destino, y marcarlos como tal. Una marca expresa un concepto del PSM en el PIM; las marcas alejan el PIM de la independencia de la plataforma, por lo que un arquitecto debe mantener un PIM limpio, donde las marcas deben concebirse como una capa transparente que se pone sobre el modelo. Figura 15: Marcado de un modelo bajo MDA En la Figura 15, se ilustra el uso de marcas como ayuda para la transformación, y su situación intermedia entre la independencia y la dependencia de la plataforma. Una vez es elegida la plataforma, existe un mapa para la transformación de modelos. Este mapa incluye un conjunto de marcas, que usamos para marcar los elementos del PIM como guía para la transformación del José Germán Núñez Mori Página 58 de 237

60 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 modelo. Las marcas pueden definir tipos del modelo, especificación de clases, asociaciones, roles, estereotipos, etc. Las marcas también pueden especificar características cualitativas que después en la transformación se convertirá en el objetivo apropiado para el cumplimiento de los requisitos. Los mapas de transformación pueden mantener también plantillas, que son modelos parametrizados que especifican tipos concretos de transformaciones. Podemos asociar un conjunto de marcas a una plantilla para identificar instancias en un modelo que deben ser transformados de acuerdo a las indicaciones de la plantilla. Existe la posibilidad de incluir información relativa a patrones que extienda las características y tipos de los metamodelos y el lenguaje de la plataforma específica elegida para el despliegue. Como muestra la figura 16, el uso de información adicional para la transformación implica la necesidad de información de los patrones para la transformación, que serán específicos para la plataforma de destino. Figura 16: Patrones de transformación en los modelos MDA Transformaciones de modelos MDA El siguiente paso al establecimiento de las marcas en los modelos y la selección de mapas de transformación es aplicar la transformación desde el PIM (Modelo independiente de la plataforma) marcado al PSM (Modelo especifico de la plataforma). Este proceso puede ser manual, asistido por computador, o automático. José Germán Núñez Mori Página 59 de 237

61 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 La transformación, es el proceso que toma como entrada el PIM marcado y da como resultado el PSM del sistema y el registro de transformación. Algunas herramientas, pueden hacer una transformación del PIM directamente a código desplegable en la plataforma de destino o incluso, conceptos como MDR (Model-Driven Runtime Environment), que propone el uso de un entorno de ejecución para los PIM, directamente, sin generación de PSM ni código para la plataforma. En cualquier caso el OMG sostiene que la transformación debe emitir un PSM para ayudar al entendimiento del código y la depuración del mismo. El registro de transformación incluye una traza desde cada elemento del PIM a los elementos correspondientes en el PSM, especificando que parte de los mapas de transformación fueron empleados para derivar los elementos del PSM desde los elementos del PIM. Una herramienta que mantenga los registros de transformación debe ser capaz de sincronizar de forma automática los cambios producidos en un modelo al otro. El PSM producido por una transformación es un modelo del mismo sistema que ha sido especificado en el PIM. También especifica como el sistema hace uso de una determinada plataforma. Un PSM, será una implementación del sistema si proporciona toda la información necesaria para construir el sistema y ponerlo en marcha. Una vez descrita y explicada la estrategia del estándar MDA, el marco de ágil de trabajo, siguiendo lo descrito por este estándar, sugiere que todo este mecanismo de planteamiento MDA, sea dirigido de manera automática y asistida por algún Framework (marco de trabajo), que permita contemplar gran parte de este especificación y cuya curva de aprendizaje sea minima para los desarrolladores. El Framework que se ajusta a las necesidades del presente trabajo, al planteamiento del estándar MDA y lo que requiere el marco ágil de trabajo es el Framework AndroMDA. Como paso siguiente en el planteamiento del prototipo de arquitectura del sistema, se describirá el Framework seleccionado (AndroMDA), que permitirá realizar las labores de modelado que se ajusten a lo planteado por el estándar MDA y a su vez ayuden al marco ágil de trabajo a cumplir con el hito de esta fase de elaboración. José Germán Núñez Mori Página 60 de 237

62 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version AndroMDA En esta sección se detallará en que consiste este Framework y de cómo será utilizado por el marco ágil de trabajo, detallando así, las distintas utilidades de este Framework y de cómo estas ayudarán a cumplir con el objetivo de este trabajo. La explicación de esta sección se ha basado en la siguiente referencia: [AMDA10]. Esta herramienta, es un marco de generación extensible que se adhiere al paradigma MDA y que toma cualquier número de modelos (usualmente modelos UML guardados en formato XMI producidos por alguna herramienta case), que en combinación con plugins de la propia herramienta (Plantillas y bibliotecas de traducción), produce componentes personalizados, es decir, se puede generar componentes en un gran número de lenguajes entre los que se encuentra: Java,.Net, HTML, PHP, etc. El código generado por AndroMDA, es automáticamente integrado al proceso de construcción, siendo esta generación muy eficiente para la aplicación a partir de un modelo independiente de la plataforma, lo que produce así, la columna vertebral del proyecto, permitiendo de esta manera que los desarrolladores se mantengan enfocados en la lógica del negocio. De acuerdo a lo que AndroMDA proporciona, el presente trabajo pretenderá que el desarrollo de este proyecto se realice sobre una plataforma java, específicamente bajo J2EE. Según esto, el marco ágil de trabajo, a lo largo de esta sección ira detallando la manera de configurar un proyecto J2EE utilizando AndroMDA MDA en la generación de código de AndroMDA En el sentido clásico de la Ingeniería de Software, uno de los primeros elementos es determinar qué es lo que el sistema tiene que hacer (fase de análisis). En esta fase el arquitecto o desarrollador tiene algo en la mente que será traducido hacia un documento específico (modelo o texto). Luego, necesitará implementar ese entregable, para lo cual requerirá una persona o un grupo de personas que implementen esa transformación en un lenguaje como C, JAVA, C++, etc. Con el estándar MDA, lo que se intenta es simplificar el trabajo del desarrollador/arquitecto, a través de la digitalización de ideas que él/ella tengan en mente (Mental Model MM o CIM). Por esta razón, el desarrollador/arquitecto debe crear un modelo independiente de la plataforma (PIM), es decir, transformar del lenguaje mental a uno formal como por ejemplo UML. Este José Germán Núñez Mori Página 61 de 237

63 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 enfoque tiene muchas ventajas algunas de ellas se listan a continuación: Es un proceso de transformación muy sencillo y directo El desarrollador/arquitecto mantiene el enfoque en la lógica del negocio. PIM (Modelo independiente de la plataforma), puede ser re-utilizado luego. No está acotado a la plataforma actual. PIM es un excelente medio para comunicar ideas a otras personas. El próximo paso es encontrar la manera para transformar el PIM hacia el código. La forma MDA de lograr esto es, ir individualmente refinando el modelo hasta llegar al modelo especifico de la plataforma a utilizar (PSM) y pasar de este modelo a código escrito manualmente Este es el punto en el cual AndroMDA actúa, pues posee diferentes cartuchos o Cartridges (plugins), que analizaran el PIM dado y construirán el PSM. Luego, de construido éste se usaran plantillas para producir el código, donde, el código generado es un lenguaje que nunca necesitará ser modificado manualmente, sin embargo de ocurrir el caso, existen formas elegantes para resolver este tipo de problemas. Figura 17: Ciclo AndroMDA de generación de código Como se puede apreciar en la figura 17, una vez interpretado el modelo UML, para generar el código de un lenguaje determinado, se hace uso de los Cartridges o cartuchos, que son elementos que interpretan determinadas marcas en el modelado como por ejemplo los estereotipos de UML (entidad, numeración, etc) o en su defecto, condiciones inferidas del modelo, como la dependencia de los actores hacia un componente marcado como servicio. Una vez interpretado tanto las condiciones o marcas en el modelado, estos cartuchos, cuentan con diferentes plantillas de los recursos necesarios para la generación de código de un lenguaje o tecnología determinada. José Germán Núñez Mori Página 62 de 237

64 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Estos Cartridges o cartuchos, son importantes en el proceso de transformación de código de AndroMDA y cada uno ellos pueden ser personalizados de acuerdo a las necesidades requeridas. Por otro lado, es muy importante tomar en cuenta que AndroMDA, ayuda a eliminar las tareas repetitivas de desarrollo, mientras que al mismo tiempo permite que tu modelo pueda asemejarse con lo que realmente el sistema hace. Esto no significa que la computadora hará todo el trabajo por el desarrollador y esté deje de pensar Arquitectura del marco ágil de trabajo según AndroMDA Según se describe en líneas anteriores, el proyecto se pretende realizar bajo la plataforma J2EE, siguiendo así una arquitectura de N niveles o capas distribuidas, basándose ampliamente en componentes de software modulares y que serán ejecutados en un servidor de aplicaciones. Bajo esta premisa, el marco ágil de trabajo se basara en la siguiente estructura: Figura 18: Arquitectura de Aplicación base del marco ágil de trabajo Como se puede apreciar en la figura 18, se presenta una estructura de capas populares de una aplicación empresarial, donde se cuenta con los siguientes niveles: Capa de presentación (Presentation layer), que contiene los elementos necesarios para interactuar con el usuario de la aplicación Capa de negocio (Business layer), encapsula la funcionalidad del negocio principal de la aplicación, accediendo a esta capa por medio de una fachada de servicios, que oculta la complejidad que alberga la misma. Capa de acceso a datos (Data Access layer), contiene los elementos necesarios para acceder José Germán Núñez Mori Página 63 de 237

65 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 a los datos subyacentes de la aplicación, abstrayendo de esta manera la semántica de la tecnología de acceso a estos y permitiendo de esta manera que la capa de negocio se centre en la lógica del sistema. Almacén de datos (Data Store), base de datos o sistema de archivos. Ahora que se ha mostrado la estructura de las aplicaciones de empresas modernas en la que se basará el marco ágil de trabajo (ver figura 18), se detallara como AndroMDA ayuda a implementar estos conceptos. AndroMDA, toma como entrada un modelo de negocio especificado en UML y generará una parte significativa de las capas o niveles necesarios para construir una aplicación Java, esto debido a que este Framework, tiene la capacidad de traducir de manera automática especificaciones de alto nivel empresarial, en código de calidad ahorrando así un tiempo significativo para el desarrollo de aplicaciones. A continuación, se presenta la estructura de aplicación empresarial que plantea AndroMDA y cada una de las tecnologías que soporta la misma en cada uno de los niveles o capas contempladas: Figura 19: Estructura de Aplicación empresarial AndroMDA José Germán Núñez Mori Página 64 de 237

66 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Como se pude apreciar en la figura 19, por cada nivel que presenta la arquitectura se muestran las tecnologías Java soportadas por este Framework. A continuación se describe la selección de las tecnologías por capa que ha optado utilizar el marco ágil de trabajo, en base a la estructura presentada por AndroMDA: Capa de presentación (Presentation layer), se ha optado por utilizar la tecnología Struts, que ayudara a generar componentes Web. Capa de negocio (Business layer), en esta capa se utilizará una tecnología que siga el modelo POJO (Plain Old Java Object) y que sea del tipo no intrusivo. Ante esto, se ha optado por utilizar el Framework Spring. Capa de acceso a datos (Data Access layer), se utilizará una tecnología de mapeo relacional de objetos llamada Hibernate. Almacén de datos (Data Store), se puede utilizar cualquiera base de datos, para este trabajo se utilizará la base de datos Hypersonic Modelado de AndroMDA y el prototipo de Arquitectura del marco ágil de trabajo A lo largo de todo este gran apartado, que tiene como objetivo obtener el prototipo de arquitectura, se ha ido explicando, tanto la metodología (AMDD), el estándar (MDA) como el Framework (AndroMDA), que ayudarán en conjunto, en base a sus planteamientos al marco ágil de trabajo, a conseguir este hito de salida de la fase de elaboración. En secciones de este apartado, se ha ido detallando el planteamiento del marco ágil de trabajo para conseguir este hito de fase (Prototipo de Arquitectura), que en resumen, es un planteamiento basado en el diseño de modelos para conseguir los componentes necesarios de una funcionalidad determinada. Ya en esta sección, es donde, se detallará cada uno de los tipos de modelos y sus componentes, que AndroMDA sugiere utilizar para el diseño y que permitirán obtener los recursos necesarios, para el prototipo de arquitectura. Siguiendo la estructura de aplicación de AndroMDA (ver figura 15 - Estructura de Aplicación empresarial AndroMDA), se explicará por cada nivel de esta estructura, los modelos implicados que permitan, obtener la codificación básica de los componentes de este prototipo de arquitectura. José Germán Núñez Mori Página 65 de 237

67 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Modelado en la capa de presentación: Este nivel como se comenta en secciones anteriores permite la interacción con el usuario, es por esta razón que AndroMDA por medio de ciertos modelos UML llegará a obtener los recursos necesarios para el funcionamiento de esta capa. Con el objetivo de plasmar los diferentes eventos y cambios de estado que se generan en esta capa de presentación, AndroMDA, plantea modelar este comportamiento en base a diagramas de actividad y estereotipos UML Figura 20: Diagrama de Actividad en AndroMDA Como se pude apreciar en la figura 20, se muestra el diseño de una determinada funcionalidad en la capa de presentación, plasmando así, sus estados de inicio y fin, sus eventos por ejemplo cancelar, sus cambios de estado, sus decisiones, etc, lo cual representa las interacciones del usuario con el sistema. El proyecto será ejecutado en base a servicios Web (bajo plataforma J2EE), lo cual implica que la interacción del usuario con el sistema, será llevada por medio de páginas JSP (basadas en tecnología Struts). El diseño mostrado en la figura 20, representa las transiciones (flechas) y estados (cajas) que tendrá una página JSP, para procesar una determinada petición de usuario y su respectiva respuesta. José Germán Núñez Mori Página 66 de 237

68 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Para poder indicar, en un diagrama de actividad AndroMDA, que un de estos estados representará una página JSP, se deberá marcar por medio del estereotipo <<FrontEndView>>, de no ser así, representarán estados que serán procesados por el sistema, en esta caso y siguiendo la tecnología Struts, deberá ser procesado por una clase controladora. Para modelar las clases controladoras asociados a las páginas JSP, será necesario modelar un diagrama de clase, en donde, la clase que haga de controlador, tenga referencia al diagrama de actividad y las operaciones necesarias para resolver cada uno de los estados asociados al sistema. La figura 21 muestra el diseño de una clase controladora: Figura 21: Componente controlador en AndroMDA Los diagramas de actividad, como sus respectivos controladores, representarán tanto las acciones como las operaciones que resuelven las peticiones del usuario. AndroMDA, con el objetivo de modelar las funcionalidades que tendrá el sistema, sugiere modelar estas en función de diagramas de casos de uso (ver figura 22). Figura 22: Casos de Uso AndroMDA Cada caso de uso diseñado (ver figura 22), tendrá que relacionarse con un diagrama de actividad y estos a su vez a una clase controladora respectiva, que en conjunto representarán, la operativa necesaria para atender las peticiones de los usuarios, asociadas a una funcionalidad determinada. Modelado en la capa de Negocio: José Germán Núñez Mori Página 67 de 237

69 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 En este nivel, como se ha ido detallando en secciones anteriores, se pretende modelar el núcleo de una aplicación. AndroMDA, sugiere para esta capa modelar componentes de tipo servicio, que representen cada una de las clases necesarias para resolver las funcionalidades del sistema Estos tipos de servicio, representarán fachadas que ocultan la lógica de negocio que se pretende plasmar a este nivel, permitiendo así de esta manera menos acoplamiento tanto con la capa de presentación, como con la capa de Datos. La figura 23 muestra este diseño: Figura 23: Modelado de servicios en AndroMDA En la figura 23, se muestran componentes de un diagrama de clase, con la particularidad, de estar marcado por el estereotipo <<Service>>, el cual como se ha descrito, en la codificación representaran fachadas de la capa de negocio. Capa de acceso a datos: En esta capa se modelará las distintas entidades de datos, con las que contará el sistema. Todo esto siguiendo lo sugerido por AndroMDA, que plantea plasmar un mapeo relacional de objetos, que se ajuste a la tecnología usada en este nivel (Hibernate). La figura 24 muestra este diseño: Figura 24: Modelado de entidades de datos en AndroMDA José Germán Núñez Mori Página 68 de 237

70 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 En la figura 24, se presenta el diseño de un diagrama de entidad relación, con la particularidad que cada componente, viene marcado con el estereotipo <<Entity>>, el cual al momento de resolverse, representará una tabla de base de datos y sus respectivas clases de mapeos Java en el proyecto, ayudando así de esta manera en la labor de recuperación de datos. Una vez mostrado todos los componentes a modelar en cada una de las capas, nos preguntamos, como se representa la interacción de estos componentes entre un nivel y otro? Para esto AndroMDA, sugiere utilizar flechas de dependencias entre componentes, ver la figura 25: Figura 25: Dependencia entre componentes de capa en AndroMDA Herramientas y tecnologías en el ciclo de generación AndroMDA En esta sección detallamos cada una las herramientas y versiones de las tecnologías, que utilizará el marco ágil de trabajo, en el ciclo de generación AndroMDA: Para el modelado se utilizará la herramienta MagicDraw UML 9.5, que permitirá plasmar los diseños en formato XMI [MGDU10]. Para transformar los modeles en formato XMI, hacia código, se utilizará la herramienta Apache Maven en su versión [AMVN10] La herramienta Apache Maven en conjunto con las librerías de AndroMDA, interpretarán el modelo y generarán los componentes necesarios a implementar. La versión de AndroMDA a utilizar es la 3.2 [AMDA10]. Se utilizará el Framework Apache Struts en su versión [ASTS10]. El Framework Spring en su versión [SPIG10]. El Framework Hibernate en su versión [HBNT10]. En base a todos estos modelos, tecnologías y herramientas que se ha ido detallando a lo largo de José Germán Núñez Mori Página 69 de 237

71 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 este apartado, se obtendrá el prototipo de arquitectura tanto a nivel de modelado como de implementación. Además cabe recalcar, que bajo este enfoque de modelado es que se pretende incluir cada uno los patrones de diseño relacionados con la Usabilidad Plan de ejecución de la primera iteración de construcción Scrum, es una de las metodologías de gestión en la que se basa el marco ágil de trabajo. Así, en esta sección se detallará la manera en que Scrum, plantea desagregar una funcionalidad especifica en diferente tareas, que en conjunto formen una iteración. Scrum, cuenta con un elemento llamado Sprint backlog, que consiste en descomponer las funcionalidades del Product backlog, en tareas necesarias para construir un incremento (una parte completa y operativa del sistema) [JPAL02]. En el Sprint se asigna a cada tarea, la persona responsable de su desarrollo y se indica el tiempo de trabajo que se estima. Además en este elemento, cada persona responsable de cada tarea deberá de registrar el avance de la misma y de esta manera tener de primera mano información del tiempo que falta para terminarla. Este enfoque, es útil porque permite descomponer el proyecto en tareas de tamaño adecuado para determinar el avance diario e identificar riesgos y problemas sin necesidad de procesos complejos de gestión [JPAL02]. Además tomar en cuenta que en Scrum un Sprint es equivalente a una iteración del marco ágil de trabajo. Para realizar un Sprint backlog, Scrum sugiere se tenga en cuenta lo siguiente: Deberá de realizarse de forma conjunta con todos los miembros del equipo. Deberá de tomarse en cuenta todas las tareas identificadas por el equipo para conseguir el objetivo del Sprint. El tamaño de cada tarea está en un rango 4 a 16 horas de trabajo. Tiene que ser visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio físico donde trabaja el equipo. Para el Sprint backlog, Scrum sugiere los siguientes formatos en los que se puede realizar esta tarea: Hoja de Calculo. Pizarra o pared física. José Germán Núñez Mori Página 70 de 237

72 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 Herramienta colaborativa o de gestión de proyectos. El marco ágil de trabajo, opta por realizar esta labor en base a una herramienta colaborativa, que permita registrar los Sprint y que este a la vez accesible para todo el equipo de trabajo. La herramienta sugerida por el marco ágil de trabajo es Sprintometer, la cual es una herramienta ágil y a su vez simple para la gestión y el seguimiento de proyectos basados en SCRUM y XP [SPTOME09]. Sprintomer, fue creado originalmente por la gente que trabaja en proyectos ágiles para sus propios fines y ahora esta disponible como producto Freeware. A continuación se describirá brevemente, algunos detalles importantes para el uso de esta herramienta, que permitan en el momento de la ejecución de la fase, el uso adecuado de la misma [SPTOUG08]. En las figuras 26, 27 y 28, se muestran detalles de esta herramienta: 1 2 Figura 26: Herramienta de gestión Sprintometer José Germán Núñez Mori Página 71 de 237

73 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 a b c Figura 27: Sección de registro de Sprint en Sprintometer Figura 28. Sección de control de avance de tareas en el Sprint bajo Sprintometer De acuerdo a la figura 26 [SPTOUG08]: Ítem Comentarios 1 En esta sección es donde se realiza el registro de los Sprint que gestionara el proyecto. Como se puede ver en la figura 23, donde se desglosa la sección del registro de los Sprint, existen niveles de registro: a. Nivel Sprint, a este nivel es donde se registra los Sprint (iteraciones) que contendrá el proyecto. b. Nivel de Historias de usuario o funcionalidades, a ese nivel se registrará las funcionalidades que se pretende gestionar en un Sprint. c. Nivel de tarea, a este nivel ya se habla de una mayor granularidad de un Sprint, debido a que en este nivel se registra las tareas a realizar por cada funcionalidad registrada. 2 En esta sección, es donde ya se lleva el control de las tareas registradas, mostrando así el avance de las mismas tanto a nivel de Sprint, de funcionalidades como de tareas (ver figura 15) Tabla 5 : Detalle de secciones del Sprintometer José Germán Núñez Mori Página 72 de 237

74 La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2 De acuerdo a lo planteado en esta sección, en base a la herramienta Sprintometer, se deberá de realizar la planificación de la primera iteración (Sprint), que contemple las tareas necesarias para llevar a cabo el prototipo de arquitectura. Esta forma de gestionar el proyecto deberá de ser aplicada también en futuras iteraciones, es decir, que se deberá de seguir esta estructura de planificación para las iteraciones de la fase de desarrollo Fase de Desarrollo En esta fase, como ya se ha descrito en el planteamiento de fases del marco ágil de trabajo, se inicia con las iteraciones de desarrollo de cada una de las funcionalidades del sistema. Todas las iteraciones de desarrollo, que se hagan en esta fase seguirán la misma estructura planteada en la primera iteración de desarrollo de la fase de elaboración, que como ya se ha comentado, tiene como objetivo el prototipo de la Arquitectura. De acuerdo a esta premisa, esta fase de desarrollo seguirá el planteamiento dado en la fase de elaboración para la implementación de cada una de las funcionalidades del sistema. José Germán Núñez Mori Página 73 de 237

75 La Usabilidad en Metodologías Ágiles IV. Fase de Inicio del Marco Ágil de Trabajo Versión 1.1

76 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Historia del documento FECHA VERSION DESCRIPCIÓN AUTOR 13/06/ Fase de Inicio del marco ágil de trabajo. 120/10/ Fase de Inicio del marco ágil de trabajo. José Germán Núñez Mori José Germán Núñez Mori José Germán Núñez Mori Page 75 of 237

77 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Fase de Inicio del marco ágil de trabajo 1. Introducción El marco ágil de trabajo, plantea ciertas fases que comprenden la estructura de su metodología. En este capítulo, se abordará el desarrollo de la primera de sus fases, que hace referencia a la fase inicial de este marco de trabajo. La metodología AUP (Agile Unified Process), que es una de las metodologías referentes del presente trabajo, plantea una serie de actividades a realizar en la fase de inicio, como por ejemplo: definición de riesgos del proyecto, estimación de costes, etc. En esta primera fase, el marco ágil, realiza su planteamiento basado en dos de las actividades que sugiere realizar en esta fase la metodología AUP, las cuales son: Definición del alcance y la planificación del proyecto. Esta primera fase, tal cual se describe en el capitulo anterior, es una fase de inicio de la metodología que plantea este marco ágil de trabajo, donde, se definirá a un nivel alto lo que el sistema va hacer y lo que no es suficiente a realizar, estableciendo así, los límites dentro de los cuales el equipo de desarrollo ira a operar, es decir, se determinará el alcance del proyecto [SABL06]. En cuanto a la planificación del proyecto, el marco ágil de trabajo, plantea la gestión de las funcionalidades del sistema en base a lo descrito en la metodología Scrum, que es básicamente, un inventario de características que el propietario del producto desea obtener. Donde, por ser una metodología ágil, no debe interpretarse en el sentido de que todo el proyecto esta previsto en este punto [JPAL02]. Tal cual define el marco ágil de trabajo, esta fase tiene un objetivo de fase llamado hito, que consiste, en producir al final de la misma una serie de artefactos, que corresponde con cada una de las actividades consideradas en esta fase. Por lo tanto, el presente capitulo, se basará en el desarrollo de cada uno de estos artefactos planteados. Cabe comentar, que el presente trabajo basará su análisis en las funcionalidades de un sistema relacionado con el mercado de seguros de vida, es decir, un sistema que gestiona, productos que incluyen seguros de vida, riesgo, rentas, planes individuales de ahorro y asegurados en general. José Germán Núñez Mori Page 76 of 237

78 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 En esta rama de seguros de vida, uno de los activos importantes, son las personas a las cuales se brindan los productos de vida, es por este motivo que un sistema asociado a este negocio debe contemplar una gestión de las personas aseguradas y sus vínculos referentes. De acuerdo a estas premisas, el presente trabajo, opta por ejecutar su planteamiento, sobre las funcionalidades mínimas referentes a la gestión de personas aseguradas. Es así, que estas funcionalidades serán desarrolladas a lo largo de este capitulo, en base al ciclo de vida del software planteado por el marco ágil de trabajo 2. Desarrollo de la fase de Inicio En esta sección se desarrollará cada uno de los artefactos necesarios para cumplir con el hito de esta primera fase. 2.1 Product Backlog A continuación, se detalla cada unas las funcionalidades, seleccionadas de la gestión de personas aseguradas. Estas funcionalidades, se presentan en una tabla (ver tabla 6) que sigue el formato del Product Backlog planteado por Scrum: Id. Historia Descripción Prioridad Estimación Observaciones Responsable PER001 Relacionar Personas 10 JGNuñez PER002 Gestionar Fusión de Personas 9 JGNuñez PER003 Buscar Personas Fusionadas 9 JGNuñez PER005 Gestionar Situación Familiar de la Persona (alta) 8 JGNuñez PER004 Recuperar Datos Entidad Finaciera 5 Esta funcionalidad deberá de empezar a desarrollarse una vez publicado los servicios de la Entidaed Financiera JGNuñez Tabla 6: Product backlog 2.2 Historias de usuarios En esta sección, se desarrolla, la elicitación de cada una de las funcionalidades antes descritas (ver tabla 6), siguiendo, el formato de historias de usuario. José Germán Núñez Mori Page 77 of 237

79 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Historia de Usuario Nº : PER0001 Nombre: Descripción: Prioridad: Relacionar Personas Esta funcionalidad permitirá crear relaciones entre las personas dadas de alta en el sistema y que sean de la misma red comercial, para lo cual, es necesario que se tenga como parámetros de entrada, tanto el código de la persona gestionada, como la red comercial a la que pertenece. Para generar las relaciones de la persona gestionada, esta funcionalidad debe permitir buscar las personas a relacionar por los siguientes criterios: Tipo Vinculo, Vinculo, código de la persona, tipo de persona, sin identificación, fiscalmente aplicable. Una vez ubicada la persona, se dará de alta en la relación y se adicionará a las relaciones existentes de la persona gestionada. Usuario de Creación: Josë Núñez Mori Fecha Alta: 01/04/2010 Estimación: Dependencia: Requisito System Status Feedback Interaction Feedback Progress feedback Requisitos de Usabibilidad Asociados Aplicación Comentarios X X Si el alta de la relación, no se realiza correctamente, se mostrará el siguiente mensaje en formato de error: "La operación no se ha realizado con éxito, debido a..." Tras el evento de adición de una nueva relación, esta se añadirán al final de la tabla de relaciones de la persona gestionada y se remarcarán con un color apropiado. José Germán Núñez Mori Page 78 of 237

80 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Progress feedback Warning Global Undo X X Tras el evento de confirmación de las nuevas relaciones asociadas a la persona gestionada, el sistema presentará el siguiente mensaje en formato de confirmación.: "Se va a guradar los cambios en las relaciones de la persona gestionada, Esta seguro de re Esta funcionalidad debe permitir la opción de deshacer, lo cual consitirá, en eliminar las diez últimas relaciones dadas de alta con esta operación. Además se presentará estas diez últimas relaciones en formato de lista. Object Specific Undo Abort Operation Go back Structured Text Entry, Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation X X Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, y que permitirá abortar, ya sea la búsqueda o la adición de relaciones en curso. Retonando el control a la funcioanlidad previa o al home de la aplicación. Para los campos del criterio de búsqueda se tendrá en cuenta lo siguiente: Tipo Vínculo, lista desplegable (obligatorio) Vinculo, lista desplegable. (obligatorio) Código de la persona alfanumérico de 6 caracteres (obligatorio). Sin identificación, campo de verificación. Fiscalmente aplicable, campo de verificación. El sistema validará el formato de los campos del criterio de búsqueda y presentará los siguientes mensajes en formato de notificación ante el incumplimiento de los mismos: Si existen campos del criterio de búsqueda que no se ajusten al formato adecuado, se mostrará el siguiente mensaje: El campo XXXX, debe ser tipo XXXX (ejemplo de formato). Si existen campos obligatorios, que no hayan sido cumplimentados, se mostrará el siguiente mensaje: El campo XXXX, es obligatorio. Tabla 7: Historia de usuario Relacionar personas José Germán Núñez Mori Page 79 of 237

81 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Historia de Usuario Nº : PER0002 Nombre : Prioridad: Gestionar Fusión de Personas De s cripción: Esta funcionalidad permitirá la fusión o no fusión de personas candidatas a fusionarse, donde la persona principal de la fusión, tendrá la referencia a los contratos, direcciones de correo electrónico del grupo de personas fusionadas y será la persona visible ante cualquier búsqueda en el sistema. Para esta funcionalidad, previamente se tiene que haber seleccionado de la lista de personas candidatas a fusionarse, la personas que será la principal de la fusión. Una vez hecho esta selección, se debe mostrar un listado con la persona seleccionada anteriormente y las personas candidatas a la fusión, esta lista debe tener la siguiente información: Principal (Columna de selección) Fusionar (Columna de selección) No Fusionar (Columna de selección) Código de Persona Tipo de Identificación Número de Identificación Nombre (Concatenación del primer y segundo nombre). Sólo en caso de personas físicas. Apellido. Sólo en caso de personas físicas. Fecha Nacimiento. Sólo en caso de personas físicas. Sexo. Sólo en caso de personas físicas. Razón social. Sólo en caso de personas jurídicas De este listado, el usuario selecciona las personas a fusionar o no fusionar, además esta funcionalidad debe permitir adicionalmente, adicionar al listado de candidatos a fusionar, cualquier persona del sistema (fusión manual) Usuario de Cre ación: Josë Núñez Mori Fe cha Alta: 01/04/2010 Es timación: De pe nde ncia: Requisito System Status Feedback Interaction Feedback Progress feedback Warning Re quis itos de Usabibilidad As ociados Aplicación Comentarios X X X Si el alta de una fusión, no se realiza correctamente, se mostrará el siguiente mensaje en formato de error: "La operación no se ha realizado con éxito, debido a..." Esta funcionlaidad por actualizaciones de datos tardará de 1 a 4 segundos, ante lo cual, el sistema deberá mostrar un barra de progreso de la operación. Tras el evento de guardado de la fusión asociada a la persona principal, el sistema mostrará el siguiente mensaje en formato de confirmación: "Se va a gurdar la fusión en curso, Esta seguro de realizar esta operación?" José Germán Núñez Mori Page 80 of 237

82 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Global Undo Object Specific Undo Abort Operation Go back Structured Text Entry, Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation X X Esta funcionalidad proveerá niveles para abortar las operaciones en curso: A nivel de operación, que lo que permitirá es cancelar, las fusiones en curso y regresar a la funcionalidad anterior o al home de la aplicación. A nivel de comando, que lo que permitirá es cancelar, la operación de alta de una nueva fusión, lo cual estará controlado con una barra de progreso. El sistema deberá mostrar en formato de notificaciones, el incumplimiento de las siguientes validaciones, ante el evento de guardado: En caso de seleccionar, de la lista de personas a fusionar, más de un persona principal, el sistema deberá mostrar el mensaje: Selección Incorrecta, en la fusión solo se debe tener una persona principal. Si para una persona de la lista, se selecciona mas de una de la siguientes columnas Principal, Fusionar, No Fusionar, se deberá mostrar el siguiente mensaje: Selección incorrecta, solo se debe de seleccionar una de las tres columnas Si de la lista de personas a fusionar no se seleccionan alguna de las tres columnas (Principal, Fusionar, No Fusionar), el sistema debe mostrar el siguiente mensaje: Existen personas en la lista que falta seleccionar. Tabla 8: Historia de usuario Gestionar fusión de personas José Germán Núñez Mori Page 81 of 237

83 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Historia de Usuario Nº : PER0003 Nombre: Buscar Personas Fusionadas Prioridad: El sistema permitirá la búsqueda de personas que han pasado por un proceso de fusión (tanto de las personas principales o fusionadas). Se debe permitir, tanto la búsqueda de personas físicas como jurídicas, cada búsqueda con criterios particulares Búsqueda de personas físicas: El sistema muestra los siguientes criterios de búsqueda: Descripción: Código de persona, Tipo Identificación, Número de Identificación, Sin Identificación, Código externo de la persona (proporcionado por la red), Primer apellido, Segundo apellido, Primer nombre, Segundo nombre, Fecha de Nacimiento, Red comercial, Número de tarjeta Sanitaria. Una vez ingresado los datos necesarios, se mostrará el listado con las personas fusionadas coincidentes. Esta lista mostrará la siguiente información: Código de persona, Fecha de fusión, Tipo de Indetificación, Sin Identificación, Estado de la persona en el sistema, Código externo de la persona, Primer apellido, Segundo apellidos, Nombre, Fecha de nacimiento, Número de tarjeta sanitaria. Búsqueda de personas jurídicas: El sistema muestra los siguientes criterios de búsqueda: Código de persona, Fecha de fusión, Tipo de Indetificación, Sin Identificación, Estado de la persona en el sistema, Código externo de la persona, Razón social, Nombre comercial, Actividad comercial, Red comercial. Una vez ingresado los datos necesarios se mostrará el listado con las personas fusionadas coincidentes. Esta lista mostrará la siguiente información: Código de Persona, Fecha de fusión, Tipo de identificación, Número de identificación, Sin identificación, Estado de la persona en el sistema, Código externo de persona, Red comercial, Razón social, Fecha de constitución. Usuario de Creación: Josë Núñez Mori Fecha Alta: 01/04/2010 Estimación: Dependencia: Requisito System Status Feedback Interaction Feedback Progress feedback Warning Global Undo Requisitos de Usabibilidad Asociados Aplicación Comentarios José Germán Núñez Mori Page 82 of 237

84 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Object Specific Undo Abort Operation Go back X Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, y que permitirá abortar, la búsqueda en curso, retonando el control a la funcioanlidad previa o al home de la aplicación. Tanto para la búsqueda de personas físicas y jurídicas se debe tener en cuenta lo siguiente: Código de persona, alfanumérico de 6 caracteres (Campo obligatorio). Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio). Número de identificación, alfanumérico de 6 caracteres. Sin identificación, listado de selección ( Si / No). Estado de la persona en el sistema, listado de selección (Habilitada / Inhabilitada). Código externo de la persona, alfanumérico de 8 caracteres (Campo obligatorio) Red comercial, listado a seleccionar Structured Text Entry X Búsqueda de personas físicas: Primer y segundo apellido, primer y segundo nombre, alfanuméricos de 50 caracteres. Fecha de nacimiento, con el formato DD/MM/AAAA Número de tarjeta sanitaria, alfanumérico de caracteres. Campos obligatorios: Primer y segundo apellido, tarjeta sanitaria. Búsqueda de personas jurídica: Razón social, alfanumérica de 50 caracteres. Nombre comercial, alfanumérico de 50 caracteres. Actividad comercial, listado a seleccionar, de las actividades parametrizadas en el sistema. Campos obligatorios: Razón social, nombre comercial. El sistema validará el formato de los campos del criterio de búsqueda y presentará los siguientes mensajes en formato de notificación ante el incumplimiento de los mismos: : Si existen campos del criterio de búsqueda que no se ajusten al formato adecuado, se mostrará el siguiente mensaje: El campo XXXX, debe ser tipo XXXX (ejemplo de formato). Si existen campos obligatorios, que no hayan sido cumplimentados, se mostrará el siguiente mensaje: El campo XXXX, es obligatorio. José Germán Núñez Mori Page 83 of 237

85 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation Tabla 9: Historia de usuario Buscar personas fusionadas Historia de Usuario Nº : PER0004 Nombre: Prioridad: Recuperar Datos Entidad Finaciera Descripción: Este funcionalidad permitirá recuperar los datos de una persona de la Entidad Financiera y actualizar los datos de la persona en el sistema. Para realizar esta búsqueda se debe ingresar los siguientes criterios: Tipo de identificación. Número de identificación. Una vez ingresado estos criterios, el sistema recuperará un listado con las personas coincidentes de la entidad financiera. Este listado tendrá la siguiente información: Código de cliente. Código de cliente de la EEFF, Tipo de identificación, Número de identificación, Nombre y apellidos del cliente De este listado, se deberán poder seleccionar una de las personas, para poder obtener sus datos, los cuales serán recuperados de la Entidad financiera, siendo estos: Tipo de identificación, Número de identificación, Nombre, Primer Apellido, Segundo Apellido, Fecha de nacimiento, Profesión, Estado civil, Lista de cuentas corrientes de la persona, Lista de domicilios de la persona, Teléfono (prefijo y número). Una vez obtenido estos datos, se actualizará los datos en la persona del sistema. Usuario de Creación: Josë Núñez Mori Fecha Alta: 01/04/2010 Estimación: Dependencia: Requisito Requisitos de Usabibilidad Asociados Aplicación Comentarios System Status Feedback Interaction Feedback Progress feedback X X Al momento de recuperar tanto los datos de las persona, como el listado de personas coincidentes en la entidad financiera, si se produce algún error en este proceso, el sistema deberá mostrar un mensaje en formato de Error: "Se ha producido el / los si Tanto la recuperación de los datos, como el listado de personas coincidentes tardarán de 3 a 5 segundos, por lo cual el sistema mostrará un icono animado que indique el porcentaje de tiempo de la espera. José Germán Núñez Mori Page 84 of 237

86 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Warning Global Undo Object Specific Undo X Tras el evento de actualización con los datos obtenidos de la entidad financiera, el sistema mostrará un mensaje en fomato de confirmación: "Se va actualizar la persona con los datos de la EEFF, Esta seguro de esta operación?" Abort Operation Go back Structured Text Entry Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation X X X Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, tanto en la busqueda como en la recuperación de datos de la entidad financiera, tras el evento de cancelar se rotornará el control a la funcioanlidad anterior o al home d Esta funcionalidad permitirá, que una vez obtenido los datos de la persona de la entidad financiera,se cuente con la opción de "ir Atrás", lo cual permitira regresar al listado de personas. Para los campos de criterio se tendrá en cuenta lo siguiente: Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio). Número de identificación, alfanumérico de 6 caracteres.. El sistema validará el formato de los campos del criterio de búsqueda y presentará los siguientes mensajes en formato de notificación ante el incumplimiento de los mismos: Si existen campos del criterio de búsqueda que no se ajusten al formato adecuado, se mostrará el siguiente mensaje: El campo XXXX, debe ser tipo XXXX (ejemplo de formato). Si existen campos obligatorios, que no hayan sido cumplimentados, se mostrará el siguiente mensaje: El campo XXXX, es obligatorio. Tabla 10: Historia de usuario Recuperar datos entidad financiera José Germán Núñez Mori Page 85 of 237

87 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Historia de Usuario Nº : PER0005 Nombre : Gestionar Situación Familiar de la Prioridad: Persona (alta) De s cripción: Esta funcionalidad permitirá la gestión (Alta) de la situación familiar asociada a un persona física. Esta funcionalidad, deberá presentar la siguiente información a cumplimentar: Datos Asegurado: Situación familiar, NIF del cónyuge, % de retención del IRPF, fecha de movilidad geográfica, prolongación de la actividad laboral (valor SI /NO), pensión compensatoria a favor de cónyuge (importe anual), anualidades por alimentos a favor de los hijos. Datos Hijos, descendientes menores de 25 años o discapacitados: Año de nacimiento, año de adopción, grado de minusvalía, necesita ayuda terceros (valor SI / NO), Esta sección, permitirá adicionar o eliminar los datos de hijos o descendiente de un listado mostrado en la parte inferior de esta sección. Datos de Ascendientes mayores de 65 años o discapacitados que viven con el perceptor: Año de nacimiento, grado de minusvalía, necesita ayuda de terceros (valor SI/NO). Esta sección, permitirá adicionar o eliminar los datos de los ascendientes de un listado mostrado en la parte inferior de esta sección. Usuario de Cre ación: Josë Núñez Mori Fe cha Alta: 01/04/2010 Es timación: De pe nde ncia: Requisito System Status Feedback Interaction Feedback Progress feedback Warning Global Undo Object Specific Undo Re quis itos de Usabibilidad As ociados Aplicación Comentarios X Tras cumplimentar los tres pasos de la funcionalidad y ejecutar el evento de guardado el sistema mostrara un mensajes en formato de confirmación: "Se va a guardar los datos de la situación familiar de la persona, Esta seguro de realizar esta operación?" José Germán Núñez Mori Page 86 of 237

88 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Abort Operation Go back Structured Text Entry, Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation X X X X X Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, en cada uno de sus pasos,donde, tras el evento de cancelar se retornará el control a la funcioanlidad anterior o al home de la aplicación, abortando así, las operaciones r Tanto los pasos: Datos de los hijos y datos de los descendientes, contarán con la opción de "Ir Atrás", lo que permitirá regresar al paso inmediatamente anterior. Esta funcionalidad contará con tres pasos a cumplimentar, los cuales serían cada una de las secciones detallas en la descripción. Cada uno de estos pasos se presentarán en el orden de la descripción, indicando en cada paso, el paso en el que esta y el paso que le falta para finalizar la funcionalidad. Cada paso de esta funcionalidad presentará un icóno de ayuda el cual al pulsar mostrará un pop-up con la ayuda de cada paso. Se mostrará la ayuda de cada tarea al pular las teclas ctrl+a Tabla 11: Historia de usuario Gestionar Situación familiar de la persona 2.3 Pruebas de aceptación En esta sección, se presenta las pruebas de aceptación mínimas, asociadas a los requisitos de usabilidad contemplados en cada una de las historias de usuario desarrolladas. Id PER0001 Historia Relacionar Personas Criterio de validación de los Requisitos de Usabilidad Se deberá dar de alta una relación ya existente en la lista de relaciones de la persona gestionada, ante esto el sistema deberá mostrar un mensaje del tipo notificación: La operación no se ha realizado con éxito, debido a que la persona ya existe en las relaciones de la persona gestionada. Se debe dar de alta una relación, cuando el recurso de Base de datos se encuentra caído, ante esto el sistema deberá mostrar un mensaje del tipo notificación: La operación no se ha realizado con éxito, debido a que el manejador de Base de System Status Feedback datos no se encuentra disponible (BD001). Dar de alta nuevas relaciones y verificar, que estas se añaden al final de la lista de relaciones de la persona gestionada. Además validar que cada una de estas nuevas relaciones esten remarcadas con un color Interaction Feedback determinado José Germán Núñez Mori Page 87 of 237

89 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Warning Dar de alta nuevas relaciones asociadas a la persona gestionada y luego confirmar esta operación. Ante esto el sistema deberá mostrar el siguiente mensaje en formato de notificación: "Se va a gurdar los cambios en las relaciones de la persona gestionada, Adicionar 10 nuevas relaciones a las relaciones de la persona gestionada. Una vez realizado esto, ejecutar el evento deshacer, ante lo cual el sistema deberá presentar un popup con un listado, donde muestre estas diez últimas relaciones. Una vez aceptado Global Undo Abort Operation Durante el alta de relaciónes de la persona gestionada, ejecutar el evento cancelar. Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o al home de la aplicación. Confirmar además, que los datos de la relación en curso no s Verificar los formatos de los siguientes campos: Tipo Vínculo, lista desplegable (obligatorio) Vinculo, lista desplegable. (obligatorio) Código de la persona alfanumérico de 6 caracteres (obligatorio). Sin identificación, campo de verificación. Fiscalmente aplicable, campo de verificación. Structured Text Entry, Luego realizar la búsqueda de personas a relacionar, sin cumplimentar el campo: "Código de la persona". Ante esto el sistema deberá mostrar un mensaje del tipo notificación: "El campo Código de la persona, es obligatorio Tabla 12 : Prueba de aceptación Relacionar personas José Germán Núñez Mori Page 88 of 237

90 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Id PER0002 Historia Gestionar Fusión de Personas Criterio de validación de los Requisitos de Usabilidad Se debe dar de alta una fusión, cuando el recurso de Base de datos se encuentra caído, ante esto el sistema deberá mostrar un mensaje del tipo notificación: La operación no se ha realizado con éxito, debido a que el manejador de Base de datos no se encuentra disponible (BD001). System Status Feedback Realizar una fusión y una vez aceptada la misma, verificar que se muestra una barra de progreso, donde se informe el estado de la Progress feedback fusión. Warning Guardar la fusión asociada a una persona principal y luego verificar que el sistema muestre el siguiente mensaje en formato de confirmación: "Se va a gurdar la fusión en curso, Esta seguro de realizar esta operación?" Durante el proceso de alta de una fusión validar lo siguiente: Abort Operation Ejecutar el evento cancelar, y verificar, que el sistema redirige al usuario a la funcionalidad anterior o al home de la aplicación. Confirmar además, que los datos de la fusión no se han registrado en el sistema. Aceptar o confirmar la fusión en curso y una vez se muestre la barra de progreso, ejecutar el evento cancelar de la misma: Tras esto, validar que los datos de la fusión no se han registrado en el sistema. José Germán Núñez Mori Page 89 of 237

91 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Realizar una fusión, y validar las siguientes casuísticas tras el evento de aceptar la fusión: Structured Text Entry, Seleccionar, de la lista de personas a fusionar, más de un persona principal, donde, tras el evento de aceptar la fusión, verificar que el sistema muestra el siguiente mensaje: Selección Incorrecta, en la fusión solo se debe tener una persona principal. Para una persona de la lista a fusionar se debe de seleccionar mas de una de la siguientes columnas Principal, Fusionar, No Fusionar, donde, tras el evento de aceptar la fusión, se debe validar que el sistema muestra el siguiente mensaje: Selección incorrecta, solo se debe de seleccionar una de las tres columnas. De la lista de personas a fusionar no seleccionan alguna de las tres columnas (Principal, Fusionar, No Fusionar), donde, tras el evento decapitar la fusión, verificar que el sistema muestra el siguiente mensaje: Existen personas en la lista que falta seleccionar. Tabla 13: Prueba de aceptación Gestionar fusión de personas Id PER0003 Historia Buscar personas fusionadas Abort Operation Criterio de validación de los Requisitos de Usabilidad Durante el cumplimentado de datos para la búsqueda, ejecutar el evento cancelar: Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o la home de la aplicación, dejando la operación en curso sin efecto. Validar los formatos de los campos de la José Germán Núñez Mori Page 90 of 237

92 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Validar los formatos de los campos de la búsqueda: Código de persona, alfanumérico de 6 caracteres (Campo obligatorio), Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio), Número de identificación, alfanumérico de 6 caracteres, Sin identificación, listado de selección ( Si / No). Estado de la persona en el sistema, listado de selección (Habilitada / Inhabilitada), Código externo de la persona, alfanumérico de 8 caracteres (Campo obligatorio), Red comercial, listado a seleccionar Búsqueda de personas físicas: Primer y segundo apellido, primer y segundo nombre, alfanuméricos de 50 caracteres, Fecha de nacimiento, con el formato DD/MM/AAAA, Número de tarjeta sanitaria, alfanumérico de caracteres. Structured Text Entry Campos obligatorios: Primer y segundo apellido, tarjeta sanitaria. Búsqueda de personas jurídica: Razón social, alfanumérica de 50 caracteres., Nombre comercial, alfanumérico de 50 caracteres, Actividad comercial, listado a seleccionar, de las actividades parametrizadas en el sistema. Campos obligatorios: Razón social, nombre comercial. Realizar búsquedas con lo siguientes criterios: : Campos del criterio de búsqueda que no se ajusten al formato adecuado, donde, el sistema deberá mostrar el siguiente mensaje en formato de notificación: El campo XXXX, debe ser tipo XXXX (ejemplo de formato). Campos obligatorios, que no hayan sido cumplimentados, donde, el sistema deberá mostrar el siguiente mensaje en formato de notificación: El campo XXXX, es obligatorio. Tabla 14: Prueba de aceptación Buscar personas fusionadas José Germán Núñez Mori Page 91 of 237

93 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Id Historia Criterio de validación de los Requisitos de Usabilidad PER0004 Recuperar Datos Entidad Finaciera System Status Feedback Progress feedback Warning Abort Operation Go back Recuperar tanto los datos de la persona, como el listado de personas coincidentes de la entidad financiera, cuando no se tiene conexión al servicio de entidad financiera. Ante esto el sistema deberá mostrar un mensaje en formato de error: "Se ha producid Validar que ante la recuperación de datos como el listado de personas coincidentes de la entidad financiera, el sistema muestre en la espera un icono animado que indique el pocentaje de tiempo consumido de la operación Obtenido los datos de la persona de la entidad financiera, actualizar los mismos en el sistema, donde, al aceptar dicha actulización el sistema deberá mostar un mensaje en formato de notificación: "Se va actualizar la persona con los datos de la EEFF, Durante la recuperación tanto de los datos de la persona como el listado de personas coincidentes de la Entidad Financiera, ejecutar el evento cancelar. Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o al home de la apli Validar que en la operación de obtener los datos de la persona de la entidad financiera, al ejecutar el evento "ir atrá", el sistema redirija al usuario a la operación listado de personas coincidentes de la búsqueda en la entidad financiera José Germán Núñez Mori Page 92 of 237

94 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Validar los formatos de los campos del criterio: Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio). Número de identificación, alfanumérico de 6 caracteres. Realizar siguiente una búsqueda considerando lo Structured Text Entry Campos obligatorio del criterio, que no hayan sido seleccionado, se mostrará el siguiente mensaje: El campo XXXX, es obligatorio. Tabla 15: Prueba de aceptación Recuperar datos entidad financiera Id PER0005 Historia Gestionar Situación Familiar de la Persona (alta) Warning Abort Operation Go back Criterio de validación de los Requisitos de Usabilidad Tras cumplimentar los tres pasos de la funcionalidad y ejecutar el evento de guardado, validar, que el sistema muestre un mensajes en formato de confirmación: "Se va a guardar los datos de la situación familiar de la persona, Esta seguro de realizar esta operación?". Durante el cumplimentado de datos de cada unas de los pasos de la funcionalidad, ejecutar el evento cancelar: Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o la home de la aplicación, dejando la operación en curso sin efecto. Durante el cumplimentado de los pasos: Datos de los hijos y datos de los descendientes, ejecutar el evento "Ir Atrás", Tras esto, validar que el sistema redirige al usuario al paso anterior cumplimentado. José Germán Núñez Mori Page 93 of 237

95 La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1 Step by Step Multilevel Help Commands Aggregation Verificar que la funcionalidad se encuentra dividida en tres pasos a cuplimentar, claramente informados al usuario del sistema Verificar que en cada uno de los pasos a cumplimentar, existe un icono de ayuda donde tras ejecutar el mismo se muestre una ventana informativa del paso en el que se encuentre Validar que tras ejecutar las teclas ctrl+z, en el paso en que se encuentre, se muestre la respectiva ventana de ayuda del paso. Tabla 16: Prueba de aceptación Gestionar situación familiar José Germán Núñez Mori Page 94 of 237

96 La Usabilidad en Metodologías Ágiles V. Fase de Elaboración del Marco Ágil de Trabajo Versión 1.0

97 Historia del documento FECHA VERSION DESCRIPCIÓN AUTOR 25/10/ Fase de Elaboración del marco ágil de trabajo. José Germán Núñez Mori José Germán Núñez Mori Página 96 de 237

98 Fase de Elaboración del marco ágil de trabajo 1. Introducción Como siguiente paso planteado por el marco ágil de trabajo es la ejecución de la fase de elaboración. Es en este capitulo en el que se abordará el desarrollo de la misma. El marco ágil de trabajo, de acuerdo a su planteamiento metodológico, escrito en el capitulo Marco ágil de trabajo,plantea que se realice para esta fase dos actividades, para cumplir con el hito de esta fase, que son tanto el prototipo de la arquitectura inicial del sistema, como la planificación de esta primera iteración de fase. Estas actividades han de ser ejecutadas sobre alguna de las historias de usuarios antes expuestas (ver capitulo Fase de inicio del marco ágil de trabajo), que según sugiere la metodología AUP (Agile Unified Process), deberá ser alguna historia o historias que permitan implementar de manera iterativa la arquitectura del sistema que constituirá el núcleo central, donde se mitigan las cuestiones de alto riesgo [SABL06]. De acuerdo a este enfoque y siguiendo el objetivo del presente trabajo se seleccionará una de las historias de usuario de las antes expuestas, que represente el núcleo central del sistema, es decir, una historia de usuario que contemple la gran mayoría de requisitos de usabilidad. Donde, la funcionalidad seleccionada, sirva como estructura base a la implementaciones de las demás historias de usuario. Cabe mencionar, que la manera de trabajo ejecutada en esta fase servirá como guía para las iteraciones de desarrollo de la fase de construcción. 2. Desarrollo de la fase de Elaboración En esta sección se desarrollará, cada uno de los artefactos necesarios para cumplir con los hitos de esta fase de elaboración, tal cual el planteamiento escrito en el capitulo Marco ágil de trabajo. 2.1 Planificación de la Primera Iteración En esta sección, se presentará la planificación de esta primera iteración de desarrollo, la cual seguirá los lineamientos planteados por la metodología Scrum [JPAL02]. José Germán Núñez Mori Página 97 de 237

99 De acuerdo al Product backlog: Id. Historia Descripción Prioridad Estimación Observaciones Responsable PER001 Relacionar Personas 10 JGNuñez PER002 Gestionar Fusión de Personas 9 JGNuñez PER003 Buscar Personas Fusionadas 9 JGNuñez PER005 Gestionar Situación Familiar de la Persona (alta) 8 JGNuñez PER004 Recuperar Datos Entidad Finaciera 5 Esta funcionalidad deberá de empezar a desarrollarse una vez publicado los servicios de la Entidaed Financiera JGNuñez Tabla 17: Product backlog Podemos apreciar que la tarea de mayor prioridad es la historia: PER001 Relacionar Personas. Esta historia, por ser de mayor prioridad y por contemplar la gran mayoría de requisitos de usabilidad (ver capitulo Fase de Inicio del marco ágil de trabajo), es seleccionada para su desarrollo en esta primera iteración. La herramienta a utilizar, como se comenta, en el capitulo del Planteamiento del marco ágil de trabajo, es la herramienta Sprintometer, donde se registrará como Sprint principal la historia de usuario seleccionada y como sub-tareas, cada uno de los patrones de usabilidad asociados al diseño. Figura 29: Vista de la planificación en días En la figura 29, se puede apreciar, el tiempo que durará este Sprint y los días que se consideran laborables para esta tarea. José Germán Núñez Mori Página 98 de 237

100 Figura 30: Sprint y tareas de la primera Iteración en Spritometer En la figura 30, se muestra la planificación de esta primera iteración en la herramienta Sprintometer, donde se ha registrado cada una de las tareas que contemplará este Sprint, las horas de duración de las mismas y el responsable de su ejecución. A continuación se muestra a más detalle esta planificación (tabla 18), obtenida como reporte de Sprintometer. José Germán Núñez Mori Página 99 de 237

101 Tabla 18: Planificación del Sprint Relacionar Personas Como se puede apreciar en la tabla 18, se muestra ya en detalle cada una de las tareas y subtareas necesarias, para cumplir con el objetivo de esta primera iteración. También se puede José Germán Núñez Mori Página 100 de 237

102 apreciar en esta planificación, que cada uno los patrones de usabilidad han sido considerados como tareas, los cuales a su vez se han dividido en tareas pequeñas, que en conjunto permitirán la integración de un patrón de usabilidad determinado al diseño de la funcionalidad en curso. Con la planificación presentada, se pretende cumplir con el desarrollo del hito de Prototipo de Arquitectura. De acuerdo a esto, en la siguiente sección, se seguirá con lo planificado, desarrollando así, cada una de las tareas pactadas en este Sprint. 2.2 Prototipo de Arquitectura En la presente sección, se presentará el desarrollo de cada unas de las tareas necesarias para el desarrollo del prototipo de la arquitectura, haciendo uso del Framework AndroMDA. Como se puede apreciar en la tabla 18, como primera tarea de planificación se encuentra la implementación de la funcionalidad en si (Relacionar Personas), esto debido, a que es una estrategia a seguir para el desarrollo de este prototipo de arquitectura. La estrategia, consiste en implementar todo lo necesario a la funcionalidad en si misma y luego ir integrando cada uno de los patrones de usabilidad asociados. A continuación se describe, el desarrollo de cada una de las tareas especificadas en la planificación del Sprint (ver tabla 18 - Planificación del Sprint Relacionar personas) Tarea de Implementación de la Funcionalidad Esta tarea tiene como objetivo la implementación de la funcionalidad Relacionar Personas, por tal motivo, a continuación se muestra cada uno de los modelos involucrados en la misma. Para esta tarea se ha contemplado las siguientes sub-tareas, registradas en la planificación del Sprint, ver la siguiente tabla 19: José Germán Núñez Mori Página 101 de 237

103 Tabla 19: Planificación inicial de la tarea de implementación de la funcionalidad Diseño de la capa de datos A continuación se presenta el modelado de las entidades de datos necesarias en esta funcionalidad. José Germán Núñez Mori Página 102 de 237

104 Figura 31: Modelo de entidades de la capa de datos Este diseño, representa el modelo entidad relación, que deberá ser persistido en la base de datos seleccionada a modo de tablas de la misma Diseño de la capa de negocio En esta sección se presenta el diseño correspondiente a la capa de negocio, que consiste, en una serie de componentes del tipo servicio, que contendrán las operaciones necesarias del núcleo de esta funcionalidad. Figura 32: Modelado de la capa de negocio José Germán Núñez Mori Página 103 de 237

105 Todos estos servicios, contienen la lógica necesaria de la operativa asociada a la funcionalidad de Relacionar Personas. Esta capa de negocio, deberá de reflejar también que entidades de datos son involucradas en las operaciones de cada uno de estos servicios, por tal motivo, a continuación se muestra este diseño: Figura 33: Dependencias de servicios con las entidades de datos Diseño de la capa de presentación En esta sección se presenta, los diseños asociados a la capa de presentación, mostrando así, las transiciones y estados de acción en esta capa, ante una petición de usuario y su respectiva respuesta. Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas José Germán Núñez Mori Página 104 de 237

106 En el modelado planteado por AndroMDA (ver capitulo Marco ágil de trabajo), un caso de uso representará una funcionalidad especifica del sistema y para dar a entender esto en el momento de la generación de código se estereotipa al caso de uso con: FrontEndUseCase. Figura 35: Modelado de la clase controladora Como se puede apreciar en la figura 35, se muestra el componente controlador con las operaciones que darán soporte a las peticiones de los usuarios. También, se aprecia en esta figura, las dependencias de la clase controladora con los componentes de la capa de negocio, reflejando de esta manera que las operaciones de esta clase harán uso del núcleo de esta funcionalidad para procesar las peticiones. José Germán Núñez Mori Página 105 de 237

107 Figura 36: Diagrama de actividad asociado a la capa de presentación En la figura 36, se presenta las transiciones y cambios de estado que tendrá la página Web asociada a esta funcionalidad. Además como se puede apreciar en la columna de sistema se encuentran estados de acción relacionados con las operaciones de la clase controladora (ver figura 9 Modelado de la clase controladora) Resultado de Tarea A continuación, se presenta los resultados tras la implementación de cada uno de los diseños, asociados a la funcionalidad de Relacionar Personas. Estos resultados, consisten en presentar cada una de las pantallas de la aplicación, generadas en base a AndroMDA y detallar brevemente el funcionamiento de las mismas. José Germán Núñez Mori Página 106 de 237

108 Figura 37: Búsqueda de personas Página principal de la aplicación En la figura 37, se muestra la pantalla principal de la aplicación, que si bien es cierto no es la funcionalidad que se esta tratando, es necesario presentarla, por ser una pantalla que permite el acceso a la funcionalidad de Relacionar Personas. La funcionalidad de Búsqueda de personas, se resume, en que permite la búsqueda de una persona por medio de su código de persona o en todo caso listar todas las personas registradas en el sistema (ver figura 37 Búsqueda de personas Página principal de la aplicación). Figura 38: Relacionar Personas Criterio de selección de personas a relacionar José Germán Núñez Mori Página 107 de 237

109 Figura 39: Relacionar Personas Adición de relaciones a la persona seleccionada En la figura 38, se presenta la pantalla relacionada a la funcionalidad de Relacionar Personas, mostrando en esta figura, los criterios necesarios para adicionar una relación a la persona seleccionada. Es de acuerdo a esta selección, que se adicionará relaciones a una persona determinada. Ya en la figura 39, se puede apreciar, la adición de una persona al listado de relaciones de la persona seleccionada. Una vez presentado los resultados de esta primera tarea, se actualizará el Sprint con los avances realizados en esta tarea: Tabla 20: Actualización de la planificación de la tarea de implementación de la funcionalidad José Germán Núñez Mori Página 108 de 237

110 2.2.2 Integración del patrón de usabilidad Warning Es esta sección, se presenta la integración del patrón de usabilidad Warning, a la funcionalidad de Relacionar Personas. Para mas detalle de este patrón ver anexo 01 (Especificación Patrón de usabilidad Warning). Como se ha comentado en capítulos anteriores, los patrones de usabilidad, se tomarán en cuenta desde el tiempo de diseño, por tal motivo, en esta sección, se detalla cada uno de los niveles o capas, en las cuales será necesario adicionar nuevos componentes u operaciones que harán posible la integración de este patrón de usabilidad. Siguiendo lo planteado por el presente Sprint, la tarea de integración del patrón de usabilidad Warning, presenta la siguiente planificación, mostrada en la tabla 21: Tabla 21: Planificación inicial de la tarea de integración del patrón de usabilidad Warning Como se pude apreciar en la tabla 21, se presentan las sub-tareas asociadas a esta integración, las cuales son la continuación de la tarea de implementación de la funcionalidad (ver tabla 20- Actualización de la planificación de la tarea de implementación de la funcionalidad). Para la integración de este patrón de usabilidad, al diseño de la funcionalidad de Relacionar Personas, el presente trabajo, tomara como base lo especificado en la guía del patrón de usabilidad Warning (ver anexo 01 Especificación Patrón de usabilidad Warning). De esta guía, se toma los siguientes diagramas base para la integración: José Germán Núñez Mori Página 109 de 237

111 Figura 40 Diagrama de clases de la especificación del patrón de usabilidad Warning Figura 41: Diagrama de secuencia de la especificación del patrón de usabilidad Warning Es en base a estos diagramas, tanto de clases como de secuencia (ver figura 40 y 41), se realizará modificaciones tanto en el diseño de las capas, como en la implementación del sistema. José Germán Núñez Mori Página 110 de 237

112 A continuación, se detallan las modificaciones en las capas o niveles implicados y los resultados de la misma Integración del patrón de usabilidad Warning en la capa de presentación y capa de negocio Para la integración del patrón de usabilidad Warning en estas capas (presentación y negocio), se ha adicionado dos nuevos componentes de tipo servicio (RelacionSession y RelacionesWrapperService), quedando el diseño de la siguiente manera: Figura 42: Modelado de la clase controladora con el Patrón de usabilidad Warning Estos dos nuevos componentes (RelacionSession y RelacionesWrapperService), harán de componentes intermedios entre la capa de presentación y la capa de negocio (ver figura 42), buscando de esta manera, seguir con la especificación del patrón de usabilidad Warning, específicamente, en lo planteado en su diagrama de clases (ver figura 40 Diagrama de clases de la especificación del patrón de usabilidad Warning). Con el objetivo, de presentar mayor claridad en la integración de este patrón de usabilidad, al diseño de estas capas, a continuación, se detalla la correspondencia de cada uno de los componentes nuevos (ver figura 42), contra la especificación del patrón de usabilidad Warning (ver figura 40): José Germán Núñez Mori Página 111 de 237

113 View Controller Componentes del P.U. Warning DomainClassWrapper DomainClass Componentes de diseño en la funcionalidad RelacionarPerController RelacionarPerController RelacionesWrapperService RelacionesService - RelacionSession Tabla 22: Correspondencia de componentes del patrón de usabilidad Warning y los componentes de la funcionalidad Como se aprecia en la figura 42 (Modelado de la clase controladora con el Patrón de usabilidad Warning), el componente RelacionesWrapperService, es una componente imagen, del componente RelacionesService, es decir, que tiene las mismas operaciones que este componente. Esta imagen de operaciones, hará la labor de capa intermedia entre la capa de negocio y la de presentación, permitiendo de esta manera, validar aquellas operaciones que necesitan de confirmación del usuario antes de persistir los datos Flujo de trabajo según el patrón de usabilidad Warning En esta sección, se explicará brevemente, la interacción de los componentes diseñados, para la integración del patrón de usabilidad Warning a la funcionalidad de Relacionar Personas, y cuya secuencia, dará a entender el flujo de trabajo de este patrón, tanto a nivel de diseño como de implementación. Todo esto, tomando como base el diagrama de secuencias de la especificación del patrón (ver Figura 41- Diagrama de secuencia de la especificación del patrón de usabilidad Warning) A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes que se describen, se podrá revisar la figura 42 (Modelado de la clase controladora con el Patrón de usabilidad Warning): Una vez realizada la petición de adicionar una nueva relación, la clase controladora (RelacionarPerController), recibe los datos necesarios para el procesamiento y verifica si el flujo de trabajo necesita de una confirmación del usuario. La validación, si el flujo necesita de una confirmación de usuario, se hace contra el componente RelacionesWrapperService, y su operación checkok, donde a esta operación, se pasa como parámetro el nombre del método u operación, que se necesita validar. En este caso en concreto, se pasa como parámetro el método nuevarelacion. La operación checkok, del componente RelacionesWrapperService, valida si el José Germán Núñez Mori Página 112 de 237

114 método nuevarelacion, necesita de confirmación del usuario, de ser así, responde a la petición con el valor del flag de control de este método. En la clase controladora (RelacionarPerController), si la operación chekok del componente RelacionesWrapperService, retorna un valor falso, significa que se necesita de confirmación del usuario y se debe pedir esto a la vista. Con el objetivo de mostrar un alerta de confirmación en la páginas Web, la clase controladora (RelacionarPerController) setea valores necesarios para este comportamiento en el objeto de sesión RelacionSession. Una vez confirmado esta operación, por medio del usuario, esta petición es enviada a la clase controladora (RelacionarPerController), la cual, solicita al componente RelacionesWrapperService, que actualice el estado de confirmación, para el método nuevarelacion. Actualizado el estado de confirmación del método nuevarelacion, la clase controladora envía los datos recogidos de la vista, para su procesamiento por medio de la operación nuevarelacion del componente RelacionesWrapperService, el cual, verifica nuevamente si el flag de confirmación de la operación nuevarelacion, esta a verdadero, de ser así, envía los datos para su persistencia por medio del componente RelacionesService Resultados de la Integración del patrón de usabilidad Warning En la presente sección se presenta los resultados, tras la integración del patrón de usabilidad Warning. Estos resultados consistirán, en presentar las páginas Web, generadas en base a AndroMDA y la actualización de la planificación de la tarea de integración de este patrón José Germán Núñez Mori Página 113 de 237

115 Figura 43: Confirmación de adición de nueva relación según el patrón de usabilidad Warning Como se puede apreciar en la figura 44, ante el evento de adición de una nueva relación a la persona seleccionada, se muestra una alerta del tipo confirmación, donde se advierte al usuario que los datos que ha seleccionado están a punto de persistirse, de confirmarse esta alerta, se enviará la petición al sistema, el cual se encargará de guardar la información en la base de datos y actualizará la pantalla con la nueva adición. Figura 44: Resultados tras la confirmación de la adición de una nueva relación José Germán Núñez Mori Página 114 de 237

116 Una vez presentado los resultados de la aplicación, a continuación se presenta la actualización de la planificación respectiva a esta tarea de integración del patrón de usabilidad Warning: Tabla 23- Planificación actualizada de la tarea de integración del patrón de usabilidad Warning Integración del patrón de usabilidad System Status Feedback En la presente sección, se detallará cada uno de los pasos seguidos para la integración del patrón de usabilidad System Status Feedback. En adelante haremos referencia a este patrón como SSF. Para mas detalle de este patrón ver anexo 02 (Especificación del Patrón de Usabilidad System Status feedback). Esta Integración del patrón de usabilidad SSF, se realizará tanto en el diseño como en la implementación de la funcionalidad Relacionar Personas. A continuación, se presenta la planificación inicial de esta tarea de integración del patrón de usabilidad SSF: Tabla 24: Planificación inicial de la tarea de integración del patrón de usabilidad SSF Siguiendo lo especificación del patrón de usabilidad SSF (ver anexo 02 - Especificación Patrón José Germán Núñez Mori Página 115 de 237

117 de Usabilidad System Status feedback), la integración de este patrón a la funcionalidad de Relacionar Personas, tomara en cuenta como diseños base lo siguiente: Figura 45: Diagrama de clases de la especificación del patrón de usabilidad SSF Figura 46: Diagrama de secuencia de la especificación del patrón de usabilidad SSF José Germán Núñez Mori Página 116 de 237

118 Integración del patrón de usabilidad SSF a la capa de presentación y capa de negocio La integración de este patrón de usabilidad, en la capa de presentación, solo presenta cambios a nivel de la clase controladora de la funcionalidad (RelacionarPerController) y de su dependencia hacia el componente de tipo servicio de la capa de negocio (RelacionesService). Para esta integración se adicionan 4 nuevos componente que interactuarán entre la capa de negocio y la capa de presentación, estos componentes son: AdministradorEstados, EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService. De acuerdo a esto el diseño de la funcionalidad de Relacionar Personas, queda de la siguiente manera: Figura 47: Integración del patrón de usabilidad SSF en el diseño de la funcionalidad Relacionar Personas Como se describe al inicio de esta sección, la integración de este patrón de usabilidad SSF a la funcionalidad de Relacionar Personas, se basa en ciertos diseños de la especificación de este patrón (ver anexo 02 - Especificación Patrón de Usabilidad System Status feedback). De acuerdo esto, y buscando entender los detalles de esta integración, se presenta una tabla (tabla 25) de correspondencias entre componentes de diseño de la especificación de este patrón (ver figura 46) y el diseño de la integración a la funcionalidad en curso (ver figura 48): José Germán Núñez Mori Página 117 de 237

119 Componentes del P.U. SSF View Controller StatusManager ConcreteStatus ConcreteStatus ConcreteStatus DomainClass Componentes de diseño en la funcionalidad RelacionarPerController RelacionarPerController AdministradorEstados EstadoErrorService EstadoExitoService EstadoAdvertenciaService RelacionesService Tabla 25: Correspondencia de componentes del patrón de usabilidad SSF y los componentes de la funcionalidad Estos nuevos componentes de la integración de este patrón de usabilidad (ver figura 19), gestionarán los estados, ante la operativa de Adición de una nueva Relación, permitiendo de esta manera, mantener informado al usuario ante cualquier cambio de estado, relacionado con la operativa en curso Flujo de trabajo según el patrón de usabilidad SSF Con el objetivo de dar un mayor detalle de la integración del patrón de usabilidad SSF, en la presente sección, se describirá brevemente el flujo de trabajo, de la operativa de Adición de una nueva relación, tomando en cuenta que en esta operativa ya se encuentra integrado este patrón de usabilidad. El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la especificación de este patrón (ver figura 47). A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes que se describen, se podrá revisar la figura 48 (Integración del patrón de usabilidad SSF en el diseño de la funcionalidad Relacionar Personas): Ante la petición de adicionar una nueva relación a la persona seleccionada, la clase controladora recibe los datos de la vista, los cuales los procesa y envía estos para su persistencia a la capa de negocio, pasando respectivamente, por los componentes del patrón de usabilidad Warning (ver sección del presente capitulo). En la capa de negocio, el componente responsable de ejecutar esta operativa, es el componente RelacionesService, con su operación nuevarelacion. José Germán Núñez Mori Página 118 de 237

120 La operación nuevarelacion, recibirá los datos necesarios y procederá a persistirlos por medio de la capa de datos. Es en esta operativa, que se implementa controles de estado, es decir, se validará, si la operación de persistir los datos, se realiza de manera satisfactoria, con error u otros estados. Esta operación de nuevarelacion, ante cualquiera de estas validaciones, informará de las mismas a su observador, que en este caso, es el componente AdministradorEstados. El componente AdministradorEstados, recibirá del componente RelacionesService, la notificación de que se ha producido un cambio de estado. Esta notificación, vendrá acompañada de los datos necesarios de este cambio de estado, que permitirán a este componente por medio de su operación determinarestado, discernir el cambio de estado que se ha producido en la capa de negocio. Una vez determinado, el tipo de estado que se ha producido en la capa de negocio, este componente administrador (AdministradorEstados), enviará la información para su tratamiento al componente respectivo, es decir, si se ha producido un error se enviará los datos necesarios al componente EstadoErrorService. La clase controladora RelacionarPerController, una vez que envía los datos para su persistencia a la capa de negocio, consultará a cada uno de los componentes de gestión de estados (EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService), si se ha producido algún cambio de estado en la operativa en curso (Adición de una relación). De haberse producido algún cambio de estado, la clase controladora, recogerá los datos necesarios del componente de gestión de estados respectivo y procederá a informar de esto a la vista, por medio de mecanismos del Framework Struts utilizado en la capa de presentación Resultados de la integración del patrón de usabilidad SSF En esta sección, se presentará los resultados tras la integración del patrón de usabilidad SSF a la funcionalidad de Relacionar Personas. Estos resultados permitirán ilustrar lo que se menciona en la sección de flujo de trabajo. Además se presentará la planificación actualizada de esta tarea. Ante el evento de adición de una nueva relación, si la adición se realiza satisfactoriamente el sistema informará al usuario de esto, en la zona de estados, ver la siguiente figura: José Germán Núñez Mori Página 119 de 237

121 Figura 48: Resultados tras la adición satisfactoria de una nueva relación Si, ante el evento de adición de una nueva relación, se produce algún error, como por ejemplo: falta de recursos para realizar la operativa, error acceso a base datos, etc. El sistema notificará al usuario de este error en la zona de estados (Final de la página Wb), ver la siguiente figura: Figura 49: Resultados de error tras la adición de una nueva relación A continuación se muestra la planificación actualizada de la tarea de integración del patrón de José Germán Núñez Mori Página 120 de 237

122 usabilidad SSF: Tabla 26: Planificación actualizada de la tarea de integración del patrón de usabilidad SSF Integración del patrón de usabilidad Global Undo En la presente sección, se detalla cada uno de los pasos seguidos para la integración del patrón Global Undo (en adelante GU), a la funcionalidad de Relacionar Personas. Para mas detalle de este patrón ver el anexo 03 (Especificación del Patrón de Usabilidad Global Undo). Siguiendo la dinámica de las anteriores integraciones, a continuación se presenta la planificación inicial de la tarea de integración del patrón de usabilidad GU: Tabla 27: Planificación inicial de la tarea de integración del patrón de usabilidad GU Esta sección, tomara como base para esta integración, la especificación de este patrón de usabilidad (ver anexo 03 - Especificación del Patrón de Usabilidad Global Undo), usando ciertos diseños como punto de partida para esta labor. A continuación se presenta los diseños base de este patrón de usabilidad: José Germán Núñez Mori Página 121 de 237

123 Figura 50: Diagrama de clases de la especificación del patrón de usabilidad GU Figura 51: Diagrama de secuencias de la especificación del patrón de usabilidad GU Integración del patrón de usabilidad GU a la capa de presentación y capa de negocio José Germán Núñez Mori Página 122 de 237

124 La integración de este patrón de usabilidad, ha implicado la creación de un nuevo componente de tipo servicio (RelacionesHistorySessión), que dará soporte a las tareas que requiere este patrón de usabilidad. Además, se adiciona una nueva operación undorelaciones, tanto, en la clase controladora (RelacionesPerController), como en el componente de servicio de la capa de negocio (RelacionesService). Estas modificaciones, permitirán atenderá a las peticiones de los usuarios, ante el evento de deshacer (Undo) de la operación en curso. Según esta premisa, el diseño queda la siguiente manera: Figura 52: Integración del patrón de usabilidad GU en la capa de negocio y capa de diseño Adicional a estos cambios, se modifica también el flujo de actividades de la página Web, de la funcionalidad en curso. Con estos modificaciones en el flujo de actividad, se busca adicionar un nuevo evento a la misma, que haga referencia a la operativa de deshacer (Undo) y que esta tenga su operación de soporte en el lado del sistema, es decir, una operación en su clase controladora relacionada (ver figura 53). De acuerdo a esto el diagrama de actividades de la página Web queda de la siguiente manera: José Germán Núñez Mori Página 123 de 237

125 Figura 53: Integración del patrón de usabilidad GU en el diagrama de actividades de la página de Adición de relaciones Cada una de estas modificaciones siguen lo especificado por este patrón (Ve Figura 52). Por tal motivo, a continuación se presenta un cuadro con las correspondencias de componentes especificados y lo diseñado en la integración (ver Figura 54): View Controller HistoryList Command Componentes del P.U. GU ConcreteCommand DomainClass HistoryException - Componentes de diseño en la funcionalidad RelacionarPerController RelacionarPerController RelacionesHistorySessión RelacionesServiceBase RelacionesService Relacion Tabla 28: Correspondencia de componentes del patrón de usabilidad GU y los componentes de la funcionalidad Como se pude ver en tabla 28, existe un componente de la especificación (HistoryException), que no tiene correspondencia en el diseño de la integración, esto se debe a que este componente ya se encuentra gestionado por uno de los Framework que utiliza el marco ágil de trabajo (Spring). José Germán Núñez Mori Página 124 de 237

126 Flujo de trabajo según el patrón de usabilidad GU Con el objetivo de dar un mayor detalle de la integración del patrón de usabilidad GU, en la presente sección, se describirá brevemente el flujo de trabajo, de la operativa de Adición de una nueva relación, tomando en cuenta que en esta operativa ya se encuentra integrado este patrón de usabilidad. El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la especificación de este patrón (ver figura 53). De acuerdo a esto, a continuación, se presenta el detalle de este flujo de trabajo, donde para tener relación de los componentes que se describen, se podrá revisar la figura 54 (Integración del patrón de usabilidad GU en la capa de negocio y capa de diseño): Detalle del flujo ante el evento de adición de una nueva relación: Cuando la petición de adición de una nueva relación, llega a la clase controladora (RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda esta información para ser enviado para su persistencia a la capa de negocio. De este objeto que se envía a la capa de negocio, su referencia será guardada por el componente: RelacionesHistorySessión, con lo cual se estaría clonando el comando que se esta ejecutando (Adición de una nueva relación). Detalle del flujo ante el evento de deshacer (Undo), las nuevas relaciones: Cuando la petición de deshacer, llega a la clase controladora (RelacionarPerController), esta recupera todos los objetos clonados en el componente RelacionesHistorySessión, que han sido guardados en el transcurso de la operativa de adición de nuevas relaciones. Con este listado de objetos clonados, la clase controladora realiza una petición de deshacer las relaciones asociadas a estos objetos. Esta petición se ejecuta contra la operación undorelaciones del componente de la capa de negocio RelacionesService. La operación undorelaciones, recibe como parámetro, un listado de objetos del tipo Relación, y solicita por cada objeto a la capa de datos, que elimine el registro persistido en Base de datos. José Germán Núñez Mori Página 125 de 237

127 Resultados de la integración del patrón de usabilidad GU Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los resultados a nivel de páginas Web. Se adiciona dos nuevas relaciones a la persona seleccionada (PER005, PER006), ver la siguiente figura: Figura 54: Adición de nuevas relaciones considerando el patrón GU Como se describe en la anterior sección, por cada adición de una nueva relación se realiza una clonación del objeto que se esta adicionando, de tal manera que cuando el usuario realice la petición de deshacer esta operativa, se recupere estos objetos clonados y se solicite de que se elimine de Base de datos. De acuerdo a esto, esta pantalla quedaría de la siguiente manera tras el evento de deshacer (Undo): José Germán Núñez Mori Página 126 de 237

128 Figura 55: La adición de relaciones tras en el evento de deshacer (Undo) A continuación, se presenta la actualización de la planificación asociada a la integración de este patrón de usabilidad: Tabla 29: Planificación actualizada de la tarea de integración del patrón de usabilidad GU Integración del patrón de usabilidad Abort Operation En esta sección, se detallará los pasos seguidos para la integración del patrón de usabilidad Abort Operation a la funcionalidad de Relacionar personas. Para esta integración, el presente trabajo se ha basado en la especificación del patrón Abort (ver anexo 04 Especificación del patrón de usabilidad Abort). José Germán Núñez Mori Página 127 de 237

129 El patrón Abort Operation, en adelante AO, pertenece a la familia del patrón de usabilidad Abort, siendo este patrón AO, una rama especifica, es decir, una especificación concreta para ciertas tareas de usabilidad, que en este caso puntual, es aplicar este patrón para cancelar una operación en curso. Este patrón de usabilidad AO, basa mucho su planteamiento en el patrón de usabilidad Global Undo (detallado en la anterior sección del presente capitulo), es por este motivo, que la integración de este patrón tomará como base el diseño y la implementación del patrón Global Undo. Siguiendo la especificación del patrón de usabilidad AO (ver anexo 04 Especificación del patrón de usabilidad Abort), se tomará como referencia para la integración, los siguientes modelos base: Figura 56: Diagrama de clases de la especificación del patrón de usabilidad AO José Germán Núñez Mori Página 128 de 237

130 Figura 57: Diagrama de secuencia de la especificación del patrón de usabilidad AO Como se puede apreciar en las anteriores figuras (figura 59 y 60), la estructura del planteamiento de este patrón es casi similar a lo planteado por el patrón de usabilidad Global Undo (ver figuras 52 y 33), variando específicamente en el flujo de actividades tras el evento de cancelar una operación. A continuación, se presenta la planificación inicial de la tarea de integración del patrón de usabilidad AO a la funcionalidad en curso: Tabla 30: Planificación inicial de la tarea de integración del patrón de usabilidad AO Integración del patrón de usabilidad AO a la capa de presentación y capa de negocio La integración de esta patrón, ha implicado la creación de una nueva operación en la clase controladora (RelacionesPerController), esta operación es: cancelarrelaciones, la cual José Germán Núñez Mori Página 129 de 237

131 permitirá atender las peticiones de los usuarios ante el evento de cancelar la operación en curso (adicionar una nueva relación). Esta integración, utiliza un componente ya creado en la integración del patrón de usabilidad Global Undo, llamado RelacionesHistorySession, que tendrá la misma utilidad que en este patrón, es decir, clonará objetos de la operativa de adicionar nuevas relaciones. De acuerdo esto el diseño queda de la siguiente manera: Figura 58: Integración del patrón de usabilidad AO en la capa de negocio y capa de presentación Adicional a la operación nueva en la clase controladora, se modifica las actividades asociadas a la pagina Web, que soporta la funcionalidad de Relacionar Personas. Estas modificaciones, consisten en adicionar el nuevo evento de Cancelar y su respectivo estado de acción en el lado del sistema, es decir, la referencia a la nueva operación (cancelarrelaciones) de la clase controladora. Este nuevo flujo, que hace referencia al evento de Cancelar, deberá indicar, que una vez ejecutado esta operativa, se debe de regresar al home de la aplicación, es decir, a la página de búsqueda de personas. Por tal motivo, este flujo deberá de tener un estado de fin, que haga referencia a la funcionalidad de Búsqueda de Personas. Según estas premisas el diseño de actividades asociadas a la página de Adición de una nueva relación, queda de la siguiente manera: José Germán Núñez Mori Página 130 de 237

132 Figura 59: Integración del patrón de usabilidad AO en el diagrama de actividades de la página de Adición de relaciones La modificaciones necesarias para esta integración, han seguido lo planteado por el patrón AO (ver figura 59), por tal motivo, se presenta a continuación una tabla de correspondencias de componentes, tanto de la especificación, como de la integración (ver figura 61): View Controller HistoryList Command Componentes del P.U. AO ConcreteCommand DomainClass HistoryException - ProgressIndicator - Componentes de diseño en la funcionalidad RelacionarPerController RelacionarPerController RelacionesHistorySessión RelacionesServiceBase RelacionesService Relacion Tabla 31: Correspondencia de componentes del patrón de usabilidad AO y los componentes de la integración José Germán Núñez Mori Página 131 de 237

133 Como se pude ver en tabla 31 (Correspondencia de componentes del patrón de usabilidad AO y los componentes de la funcionalidad), existe dos componentes que no tienen correspondencia en la integración, esto se debe, a que uno de ellos (HistoryException) es gestionado por el unos de los Framework utilizados por el marco ágil de trabajo y el otro (ProgressIndicator), será tratado mas adelante como una integración adicional Flujo de trabajo según el patrón de usabilidad AO A continuación, se explicará brevemente, la interacción de los componentes diseñados, para la integración del patrón de usabilidad AO a la funcionalidad de Relacionar Personas, y cuya secuencia, dará a entender el flujo de trabajo de este patrón, tanto a nivel de diseño como de implementación. Todo esto, tomando como base el diagrama de secuencia de la especificación del patrón (ver Figura 60). A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes que se describen, se podrá revisar la figura 61 (Integración del patrón de usabilidad AO en la capa de negocio y capa de presentación): Detalle del flujo ante el evento de adición de una nueva relación: Cuando la petición de adición de una nueva relación, llega a la clase controladora (RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda esta información para ser enviado para su persistencia a la capa de negocio. De este objeto que se envía a la capa de negocio, su referencia será guardada por el componente: RelacionesHistorySessión, con lo cual se estaría clonando el comando que se esta ejecutando (Adición de una nueva relación). Detalle del flujo ante el evento de Cancelar la operativa de nuevas relaciones: Cuando la petición de cancelar, llega a la clase controladora (RelacionarPerController), esta recupera todos los objetos clonados en el componente RelacionesHistorySessión, que han sido guardados en el transcurso de la operativa de adición de nuevas relaciones. Con este listado de objetos clonados, la clase controladora realiza una petición de deshacer las relaciones asociadas a estos objetos. Esta petición, se ejecuta sobre la operación undorelaciones del componente de la capa de negocio RelacionesService. La operación undorelaciones, recibe como parámetro, un listado de objetos del tipo José Germán Núñez Mori Página 132 de 237

134 Relación, y solicita por cada una de ellos, se elimine su registro persistido en Base de datos. Una vez terminada, la operativa de eliminar los registros asociados a la clonación, la clase controladora (RelacionarPerController), redirecciona la response hacia la funcionalidad de Búsqueda de Personas, que es para esta aplicación el home de la misma Resultados de la integración del patrón de usabilidad AO Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los resultados a nivel de pantallas Web. Se adiciona una nueva relación a la persona seleccionada (PER003), ver la siguiente figura: Figura 60: Adición de nuevas relaciones considerando el patrón AO Tras el evento de Cancelar, el sistema, elimina los registros asociados a las últimas adiciones, es decir, aquellos que han sido clonados y luego redirige el flujo hacia el home de la aplicación (funcionalidad de búsqueda de personas). José Germán Núñez Mori Página 133 de 237

135 Figura 61: Home de la aplicación tras el evento Cancelar Si volvemos a consultar las relaciones de la persona, en la cuál se ejecuto el evento de Cancelar, podemos apreciar que la relación que se adiciono no se encuentra. Figura 62: Consulta de relaciones tras el evento de cancelar A continuación, se presenta la planificación actualizada de la tarea de integración del patrón de usabilidad AO. José Germán Núñez Mori Página 134 de 237

136 Tabla 32: Planificación actualizada de la tarea de integración del patrón de usabilidad AO Integración del patrón de usabilidad System Progress Feedback En la siguiente sección, se detallará la integración del patrón System Progress Feedback, en adelante SPF, a la funcionalidad de Relacionar Personas. Para esta integración, el presente trabajo se ha basado en la especificación de este patrón de usabilidad (ver anexo 05 Especificación del patrón de usabilidad System Progress Feedback). De acuerdo, a la especificación de este patrón de usabilidad, se tomará como punto de partida para esta integración, los siguientes modelos: Figura 63: Diagrama de clases de la especificación del patrón de usabilidad SPF José Germán Núñez Mori Página 135 de 237

137 Figura 64: Diagrama de secuencia de la especificación del patrón de usabilidad SPF Siguiendo la dinámica de las demás patrones ya integrados a la funcionalidad de Relacionar Personas, a continuación se presenta la planificación inicial de las tareas asociadas a la integración de este patrón de usabilidad: Tabla 33: Planificación inicial de la tarea de integración del patrón de usabilidad SPF Integración del patrón de usabilidad SPF a la capa de presentación y capa de negocio Cabe mencionar, antes de iniciar con el detalle de esta integración, que este patrón de usabilidad SPF, no fue considerado como parte de los requisitos de usabilidad asociados a la historia de José Germán Núñez Mori Página 136 de 237

138 usuario Relacionar Personas (ver capitulo de Fase de inicio del marco ágil de trabajo). Debido, a que estamos en una iteración que tiene como objetivo, construir el prototipo de la arquitectura que mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrón en la arquitectura inicial. Esta patrón de usabilidad SPF, será aplicado, sobre la funcionalidad dada por el patrón de usabilidad Global Undo (ver sección Integración del patrón de usabilidad Global Undo), es decir, que ira informando el progreso de la operación de deshacer (Undo) las adiciones de nuevas relaciones. En la integración de este patrón, se ha diseñado un nuevo componente del tipo servicio (IndicadorProgresoService), que permitirá, dar soporte a las tareas requeridas por este patrón de usabilidad, siendo una de las principales, la de un componente observador, que ira informando del progreso de determinadas operaciones. Adicional al nuevo componente diseñado para la integración de este patrón de usabilidad, se adiciona una nueva operación en la clase controladora (RelacionarPerController), esta operación es: verificarprogreso, que permitirá, dar soporte a las peticiones de aquellas funcionalidades, que requieran que se muestre al usuario algo informativo del progreso de su operativa en curso. De acuerdo a las modificaciones comentadas líneas arriba, se muestra el diseño tanto de la capa de negocio como la de presentación: Figura 65: Integración del patrón de usabilidad SPF en la capa de negocio y capa de diseño José Germán Núñez Mori Página 137 de 237

139 Adicional a los cambios en componentes de la capa de negocio y presentación, se modifica también el flujo de actividades de la página Web, de adición de nuevas relaciones. Con estas modificaciones en el flujo de actividades, se busca adicionar un nuevo evento a la misma, que haga referencia a la operativa de Verificar el progreso de un determinado evento y que esta tenga su operación de soporte en el lado del sistema, es decir, una operación en su clase controladora (ver figura 68). Este nuevo evento, que se adiciona al flujo de actividades de la página Web, no representara un evento implícito como tal, sino, más que todo una referencia a una operación en el lado del sistema (soportada por la clase controladora), que permitirá, ir informando del progreso de un evento especifico al usuario, que en este caso en concreto, es el evento de deshacer (Undo) de las nuevas relaciones adicionadas. De acuerdo a esto, el diagrama de actividades de la página Web queda de la siguiente manera: Figura 66: Integración del patrón de usabilidad SPF en el diagrama de actividades de la página Web de Adición de relaciones Como se describe al inicio de esta sección, esta integración se basa en ciertos diseños obtenidos José Germán Núñez Mori Página 138 de 237

140 de la especificación de este patrón de usabilidad SPF, es así, que la adición de un nuevo componente y la creación de una nueva operación en la clase controladora (ver figura 68), se basan en el diseño de clases de esta especificación (ver figura 66). Según esto, se presenta a continuación una tabla de correspondencias entre componentes, tanto de la especificación como de la integración en si: Componentes del P.U. SPF View Controller DomainClass DomainClass ProgressIndicator Monitor Componentes de diseño en la funcionalidad RelacionarPerController RelacionarPerController RelacionesService Relacion IndicadorProgresoService SetInterval (Función javascript asociada a las página JSP) Tabla 34: Correspondencia de componentes del patrón de usabilidad SPF y los componentes de la Integración Como se puede apreciar en la tabla 34, existe un componente de la especificación, llamado Monitor, que tiene su correspondencia en una función javascript en la integración, esto se debe, a que en la implementación se hará uso de este lenguaje y que una de las funciones propias de este lenguaje, como es el setinterval, simulará las tareas asociadas a este componente Monitor Flujo de trabajo según el patrón de usabilidad SPF En esta sección, se detalla las actividades asociadas a la funcionalidad de Adicionar relaciones, teniendo en cuenta que para esta operativa, se tiene integrado el patrón de usabilidad SPF. Este flujo de trabajo, es una secuencia de actividades que se expone en esta sección, con el objetivo, de proporcionar un mayor detalle del funcionamiento de este patrón de usabilidad SPF, integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la especificación de este patrón de usabilidad, específicamente, en su diagrama de secuencia (ver figura 67). A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes que se describen, se podrá revisar la figura 68 (Integración del patrón de usabilidad SPF en la capa de negocio y capa de diseño): José Germán Núñez Mori Página 139 de 237

141 Solicitada la petición de deshacer las nuevas relaciones adicionadas (Undo), la vista enviará dicha petición para ser resuelta en su controlador relacionado (RelacionarPerController) y a su vez, esta petición activará un timer en el objeto de monitorización, que pasado un determinado tiempo, ejecutará determinadas acciones. Este objeto de monitorización es simulado por la función JavaScript "setinterval", la cual residirá en la página Web asociada a la funcionalidad en curso, es decir, en lado del cliente. Una vez sobrepasado, el tiempo mínimo de 2 segundos en el timer del objeto de monitorización, este verificará si la petición, de deshacer las nuevas relaciones adicionadas, ha culminado, de ser así, mostrara los resultados respectivos en pantalla. En el caso de que no se haya culminado la petición, de deshacer las nuevas relaciones adicionadas, el objeto de monitorización, lanzará una petición paralela (simulación de hilo paralelo al principal), para verificar el progreso de esta operación de deshacer (Undo). El objeto encargado de simular este hilo paralelo, es el objeto XMLHttpRequest, el cual es un objeto, de la tecnología asíncrona Ajax. Este objeto, presenta un esquema de trabajo que se asemeja a lo especificado en el diagrama de secuencia, de la especificación del patrón de usabilidad SPF (ver figura 67), por tal motivo a continuación se muestra el esquema de trabajo de este objeto [SUNPB05]: Figura 67: Esquema de trabajo del objeto XMLHttpRequest El objeto XMLHttpRequest, enviará una petición cada un segundo al controlador asociado (RelacionarPerController), en su operación "verificarprogreso". Esta operación, solicitará la José Germán Núñez Mori Página 140 de 237

142 información del progreso de la operativa de deshacer (Undo) al componente IndicadorProgresoService y su operación verificarprogreso. Bien sabemos, que el servicio RelacionesService, es el encargado de deshacer las relaciones adicionadas por medio de su operación undorelaciones. Esta operación undorelaciones, recibirá como parámetro un listado de las relaciones que deberá de solicitar a la capa de datos que se elimine de base de datos, donde, por cada relación eliminada deberá de contabilizarse el progreso que lleva respecto al total de relaciones a eliminar, he informar de esto a los escuchadores suscritos. La manera de contabilizar el progreso de la relaciones a eliminar, consiste en que, por cada relación eliminada, se contabilice todas la relaciones eliminadas y se divida entre el total de relaciones a eliminar y para obtener el porcentaje de progreso se multiplique por cien. Es este porcentaje que se informa a los escuchadores. El escuchador de progreso, suscrito al componente RelacionesService, es el componente IndicadorProgresoService y cada vez que el componente escuchado, envíe información de progreso, este escuchador, guarde esta información como parte de sus atributos. Cada vez que la operación verificarprogreso del controlador (RelacionarPerController), solicite esta información al componente IndicadorProgresoService, este tendrá el progreso actualizado de la operativa en curso. Una vez obtenido, el progreso de la operativa de Undo en curso, la clase controladora (RelacionarPerController), en su operación verificarprogreso, enviara esta respuesta al objeto XMLHttpRequest, que será el encargado, junto a funciones javascript propias de la página Web, de informar esto en pantalla y además de verificar, que si se ha llegado a la totalidad del progreso, que en este caso el cien por ciento, se anulen las peticiones al controlador que se viene realizando por medio del hilo paralelo Resultados de la integración del patrón de usabilidad SPF Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los resultados a nivel de pantallas Web. Se adicionan nuevas relaciones a la persona seleccionada: José Germán Núñez Mori Página 141 de 237

143 Figura 68: Adición de distintas relaciones a la persona seleccionada Adicionado numerosas relaciones, a la persona seleccionada (PER003), se procede a deshacer (Undo) esta relaciones adicionadas, donde por cada relación eliminada se irá informando del progreso de la operación en la página Web. Figura 69: Barra de progreso mientras se aplica la operación de Undo a las relaciones adicionadas Una vez finalizada la operación, de deshacer las adiciones de relaciones, la barra de progreso desaparecerá actualizando la página Web y mostrará las relaciones iniciales que tenía antes de estas adiciones. José Germán Núñez Mori Página 142 de 237

144 Siguiendo la dinámica de anteriores integraciones de patrones de usabilidad, a continuación, se presenta la planificación actualizada asociada a las tareas de integración de este patrón de usabilidad. Tabla 35: Planificación actualizada de la tarea de integración del patrón de usabilidad SPF Integración del patrón de usabilidad Abort Command Este patrón de usabilidad Abort Command, en adelante AC, pertenece a la familia del patrón de usabilidad Abort, al igual que el patrón Abort Operation (ver sección Integración del patrón de usabilidad Abort Operation ), este también, es una rama especifica de este patrón Abort (ver anexo 04 Especificación del patrón de usabilidad Abort). De acuerdo a esta premisa, en la presente sección se abordará, la integración de este patrón de usabilidad AC a la funcionalidad de Relacionar Personas, específicamente aplicado, sobre el comando asociado al patrón de usabilidad System Progress Feedback, es decir, se buscará integrar el patrón, para lograr cancelar el comando, que muestra la barra de progreso asociada a cierta operativa. Al igual, que el patrón de usabilidad System Progress Feedback, el patrón AC, no fue considerado como parte de los requisitos de usabilidad asociados a la historia de usuario Relacionar Personas (ver capitulo de Fase de inicio del marco ágil de trabajo). Debido, a que estamos en una iteración que tiene como objetivo construir el prototipo de la arquitectura, que mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrón en la arquitectura inicial. Mencionar, que esta integración del patrón de usabilidad AC, basará su diseño en los modelos base de la especificación del patrón Abort, teniendo ciertos matices propios del patrón de José Germán Núñez Mori Página 143 de 237

145 usabilidad AC, por tal motivo, se utilizará el mismo diagrama de clases base utilizado por el patrón Abort Operation (ver Figura 59). La diferencia en los enfoques de integración entre el patrón Abort Operation y el AC, reside en el diseño base de la interacción de los componentes que intervienen en el planteamiento de uno u otro patrón. Por tal motivo la integración del patrón de usabilidad AC, utilizará como base el siguiente diagrama de secuencias: Figura 70: Diagrama de secuencia de la especificación del patrón de usabilidad AC Como parte inicial de esta integración, se presenta la planificación de las tareas necesarias en la labor de integración del patrón de usabilidad AC a la funcionalidad de Relacionar Personas : Tabla 36: Planificación inicial de tarea de integración del patrón de usabilidad AC José Germán Núñez Mori Página 144 de 237

146 Integración del patrón de usabilidad AC a la capa de presentación y capa de negocio. Como se describe al inicio de esta sección, esta integración, será aplicada sobre el comando de información de progreso de ciertas funcionalidades, por tal motivo esta integración, basará su modelado en el diseño de nuevos componentes, realizados en la integración del patrón de usabilidad System Progress Feedback: Figura 71: Integración del patrón de usabilidad AC en la capa de negocio y capa de diseño Como se puede ver en la figura 74, se adiciona nuevas operaciones al componente de servicio IndicadorProgresoService y a la clase controladora, las cuales permitirán, que se ejecuten las tareas necesarias de este patrón de usabilidad AC, sobre el comando del patrón System Progress Feedback. Adicional a estos cambios, se modifica también el flujo de actividades asociadas la página Web, de adición de nuevas relaciones. Esta modificación, consiste en adicionar un nuevo evento llamado cancelarcomando y su respectivo estado de acción en el lado del sistema (operación en la clase controladora), que permite las peticiones de cancelar un comando determinado, en este caso en concreto, el comando de información de progreso de la operativa de deshacer (Undo). De acuerdo a esto, el flujo de actividades asociado a la página Web, de adicionar nuevas relaciones, queda de la siguiente manera: José Germán Núñez Mori Página 145 de 237

147 Figura 72: Integración del patrón de usabilidad AC en el diagrama de actividades de la página Web de Adición de relaciones Con el propósito de entender cada uno de los cambios, realizados en los componentes de diseño tanto de la capa de presentación, como la de negocio, se presentará un cuadro de correspondencia entre componentes de la especificación del patrón de usabilidad Abort (ver Figura 59) y la integración del patrón AC (ver figura 74): José Germán Núñez Mori Página 146 de 237

148 View Controller Componentes del P.U. AO HistoryList - Command ConcreteCommand DomainClass HistoryException - ProgressIndicator Componentes de diseño en la funcionalidad RelacionarPerController RelacionarPerController RelacionesServiceBase RelacionesService Relacion IndicadorProgresoService Tabla 37: Correspondencia de componentes del patrón de usabilidad AC y los componentes de la integración Como se puede apreciar en la tabla 37, existen ciertos componentes de la especificación que no tiene su correspondencia en la parte de integración, esto se debe a dos motivos: Que alguno de ellos, no son requeridos por esta patrón AC, si no mas bien, por el patrón de usabilidad Abort Operation, siendo este el componente HistoryList. Que el resto de componentes, es administrado por el Framework de integración Spring utilizado por el marco ágil de trabajo Flujo de trabajo según el patrón de usabilidad AC Este flujo de trabajo, es una secuencia de actividades que se expone en esta sección, con el objetivo, de proporcionar un mayor detalle del funcionamiento de este patrón de usabilidad AC, integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la especificación del patrón de usabilidad Abort, específicamente, en su diagrama de secuencia (ver figura 73). A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes que se describen, se podrá revisar la figura 74 (Integración del patrón de usabilidad AC en la capa de negocio y capa de diseño): En la página Web, de adición de nuevas relaciones, cuando se ejecuta el comando Undo de las relaciones recién adicionadas, se muestra al usuario un barra informativa del progreso de la operación en curso. Esta barra de progreso informativa, contará con la opción de cancelar, la cual permitirá José Germán Núñez Mori Página 147 de 237

149 abortar el progreso del comando en curso. Esta cancelación del comando en curso, implicará abortar la barra de progreso y cancelar las acciones respectivas de la operación Undo. Una vez realizada la petición de cancelar el comando, la clase controladora, recibirá esta petición para su tratamiento en la operación cancelarcomando. La operación cancelarcomando, solicitará al componente IndicadorProgresoService, que actualice el estado de su atributo, que hace referencia a cancelar la operativa de progreso, esto se hará por medio de la operación actualizarestadocancelar. Sabemos que la operación undorelaciones, del componente RelacionesService, se encarga de solicitar a la capa de datos la eliminación de relaciones ya persistidas y además de informar de este progreso a su escuchador IndicadorProgresoService, donde, por cada vez que informa a su escuchador con el progreso de esta operación, verificará si el estado de cancelación de este comando esta activo. Si el estado de cancelación no esta activo, el componente RelacionesService, seguirá con la operativa en curso, caso contrario, abortará su operación de eliminación de relaciones, lo cual implicará, que las relaciones eliminadas antes que el estado de cancelación este activo, persistirá su eliminación en bases de datos y de las restantes quedará su registro. En la operación cancelarcomando, de la clase controladora, una vez solicitado la actualización del estado de cancelación de comando al componente IndicadorProgresoService, volverá consultar, las relaciones asociadas a las persona de la operativa y retorna estos resultados a pantalla Resultados de la integración del patrón de usabilidad SPF Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los resultados a nivel de pantallas Web. Se adicionan nuevas relaciones a la persona seleccionada: José Germán Núñez Mori Página 148 de 237

150 Figura 73: Adición de distintas relaciones a la persona seleccionada Adicionado numerosas relaciones, a la persona seleccionada (PER003), se procede a deshacer (Undo) esta relaciones adicionadas, donde por cada relación eliminada se irá informando del progreso de la operación en la página Web. Figura 74: Barra de progreso con opción de cancelar, ante la operativa de Undo de las relaciones adicionadas Mientras se va informando del progreso de la operativa de Undo de las relaciones adicionadas, se pude cancelar este progreso, implicando esto, que se aborta la operación hasta el punto de José Germán Núñez Mori Página 149 de 237

151 progreso que se tenía, es decir, que eliminan aquellas relaciones antes de abortar la operación. Para el caso presentado en la figura 51 (Barra de progreso con opción de cancelar, ante la operativa de Undo de las relaciones adicionadas), si se cancela la operativa en curso al 20 por ciento de su avance, implicará que solo elimine una relación de las adicionas, esta relación sería la asociada a la persona PER001. Figura 75: Tras el evento de cancelar el comando de Undo de relaciones Como parte final de los resultados de la integración del patrón de usabilidad AC, se presenta la planificación actualizada, asociada a esta tarea: Tabla 38: Planificación actualizada de la tarea de integración del patrón de usabilidad AC José Germán Núñez Mori Página 150 de 237

152 2.3 Planificación tras la primera iteración Una vez realizada cada una de las integraciones planificadas, a continuación se presentan un reporte genérico, que informarán el como se ha llevado a cabo cada una de las tareas planteadas a lo largo del tiempo. Figura 76: Carga de trabajo a lo largo de la planificación Como se puede apreciar en la figura 76, se muestra la carga de trabajo a lo largo de tiempo de la planificación. Se puede observar como esta carga va disminuyendo mientras mas cerca estamos de la fecha fin de la planificación. Cada una de las integraciones a la funcionalidad de Relacionar Personas, que se ha descrito a lo largo de este capítulo, conforma en su conjunto, el prototipo de la arquitectura propuesta en esta fase de elaboración. Es en base a esta estructura de trabajo, que se enfocará las futuras iteraciones de la fase de desarrollo, que en el presente trabajo ya no serán contempladas. José Germán Núñez Mori Página 151 de 237