Tesis MarcoAgilTrabajo

UNIVERSIDAD POLITECNICA DE MADRID FACULTAD DE INFORMATICA
TESIS DE MASTER EN INGENIERIA DEL SOFTWARE
USABILIDAD EN METODOLOGAS GILES
Autor: JOSE GERMN NEZ MORI Dirigida por: ANA MORENO
Noviembre, 2010
Agradecimiento
Agradezco a mis padres por apoyarme a seguir mis estudios
Contenido
I. II. 1. 3. 4. Introduccin Metodologas giles Introduccin Manifiesto gil Principales metodologas giles 4.1 Programacin Extrema (XP) 4.1.1 4.1.2 4.2 2 1 14 15 16 16
Principios bsicos .................................................................................. 17 Proceso de desarrollo ............................................................................ 18 20
Proceso Unificado gil (AUP) 4.2.1 4.2.2 4.2.3
Descripcin............................................................................................ 20 Principio bsicos ................................................................................... 20 Proceso de desarrollo ............................................................................ 22 23
4.3
Agile model driven development (AMDD) 4.3.1 4.3.2 4.3.3
Descripcin............................................................................................ 23 Principio bsicos ................................................................................... 23 Proceso de desarrollo ............................................................................ 24 25 Descripcin............................................................................................ 25 Principio bsicos ................................................................................... 26 Proceso de desarrollo ............................................................................ 27 27
4.4
Scrum 4.4.1 4.4.2 4.4.3
4.5
Dynamic Systems Development Method (DSDM) 4.5.1 4.5.2 4.5.3
Descripcin............................................................................................ 28 Principios bsicos .................................................................................. 28 Proceso de desarrollo ............................................................................ 29 31
4.6
Feature Driven Development (FDD) 4.6.1 4.6.2 4.6.3
Descripcin............................................................................................ 31 Principios bsicos .................................................................................. 31 Proceso de desarrollo ............................................................................ 33 34 35
Comparativa entre metodologas giles 5.1 Criterios de comparacin 5.1.1 5.1.2 5.1.3 5.1.4 5.2
Ciclo de vida del proyecto ..................................................................... 35 Estado Actual ........................................................................................ 37 Calidad .................................................................................................. 37 Herramientas ......................................................................................... 38 40
Conclusiones de la comparativa
5.3 III. 1. 2. 3.
Adopcin de metodologas
40 42 44 44 45 47
Marco gil de trabajo Introduccin Planteamiento metodolgico Estructura Metodolgica 3.1 Fases del marco gil de trabajo 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7
Inicio (Inception) ................................................................................... 47 Historias de Usuarios ............................................................................ 48 Pruebas de Aceptacin .......................................................................... 49 Product Backlog .................................................................................... 50 Elaboracin............................................................................................ 51 Prototipo de la arquitectura del sistema ................................................ 52 Estndar MDA (Model Driven Architecture)........................................ 54
3.1.7.1.1.1Usando MDA .................................................................................... 56 3.1.7.1.1.2Mapas de Transformacin MDA....................................................... 57 3.1.7.1.1.3Transformaciones de modelos MDA ................................................ 59 3.1.7.1.2AndroMDA .......................................................................................... 61 3.1.7.1.2.1MDA en la generacin de cdigo de AndroMDA ............................ 61 3.1.7.1.2.2Arquitectura del marco gil de trabajo segn AndroMDA ............... 63 3.1.7.1.2.3Modelado de AndroMDA y el prototipo de Arquitectura del marco gil de trabajo ..................................................................................................... 65 3.1.7.1.2.4Herramientas y tecnologas en el ciclo de generacin AndroMDA .. 69 3.1.7.2 Plan de ejecucin de la primera iteracin de construccin.................... 70 3.1.8 IV. 1. 2. Fase de Desarrollo ................................................................................. 73 74 76 77 77 77 87 95 97 97 97 101
Fase de Inicio del Marco gil de Trabajo Introduccin Desarrollo de la fase de Inicio 2.1 2.2 2.3 Product Backlog Historias de usuarios Pruebas de aceptacin
V. 1. 2.
Fase de Elaboracin del Marco gil de Trabajo Introduccin Desarrollo de la fase de Elaboracin 2.1 2.2 Planificacin de la Primera Iteracin Prototipo de Arquitectura 2.2.1
Tarea de Implementacin de la Funcionalidad.................................... 101
2.2.1.1 Diseo de la capa de datos .................................................................. 102
2.2.1.2 Diseo de la capa de negocio .............................................................. 103 2.2.1.3 Diseo de la capa de presentacin....................................................... 104 2.2.1.4 Resultado de Tarea .............................................................................. 106 2.2.2 Integracin del patrn de usabilidad Warning..................................... 109
2.2.2.1 Integracin del patrn de usabilidad Warning en la capa de presentacin y capa de negocio ............................................................................................. 111 2.2.2.2 Flujo de trabajo segn el patrn de usabilidad Warning ..................... 112 2.2.2.3 Resultados de la Integracin del patrn de usabilidad Warning ......... 113 2.2.3 Integracin del patrn de usabilidad System Status Feedback ............ 115
2.2.3.1 Integracin del patrn de usabilidad SSF a la capa de presentacin y capa de negocio ................................................................................................ 117 2.2.3.2 Flujo de trabajo segn el patrn de usabilidad SSF ............................ 118 2.2.3.3 Resultados de la integracin del patrn de usabilidad SSF ................. 119 2.2.4 Integracin del patrn de usabilidad Global Undo .............................. 121
2.2.4.1 Integracin del patrn de usabilidad GU a la capa de presentacin y capa de negocio122 2.2.4.2 Flujo de trabajo segn el patrn de usabilidad GU ............................. 125 2.2.4.3 Resultados de la integracin del patrn de usabilidad GU .................. 126 2.2.5 Integracin del patrn de usabilidad Abort Operation ........................ 127
2.2.5.1 Integracin del patrn de usabilidad AO a la capa de presentacin y capa de negocio129 2.2.5.2 Flujo de trabajo segn el patrn de usabilidad AO ............................. 132 2.2.5.3 Resultados de la integracin del patrn de usabilidad AO .................. 133 2.2.6 Integracin del patrn de usabilidad System Progress Feedback ........ 135
2.2.6.1 Integracin del patrn de usabilidad SPF a la capa de presentacin y capa de negocio ................................................................................................ 136 2.2.6.2 Flujo de trabajo segn el patrn de usabilidad SPF ............................ 139 2.2.6.3 Resultados de la integracin del patrn de usabilidad SPF ................. 141 2.2.7 Integracin del patrn de usabilidad Abort Command........................ 143
2.2.7.1 Integracin del patrn de usabilidad AC a la capa de presentacin y capa de negocio. ....................................................................................................... 145 2.2.7.2 Flujo de trabajo segn el patrn de usabilidad AC.............................. 147 2.2.7.3 Resultados de la integracin del patrn de usabilidad SPF ................. 148 2.3 VI. Planificacin tras la primera iteracin 151 152 153 155
Conclusiones
VII. Referencias Bibliogrficas VIII. Anexos
Anexo 01: Especificacin Patrn de Usabilidad Warning Anexo 02: Especificacin Patrn de Usabilidad System Status Feedback Anexo 03: Especificacin Patrn de Usabilidad Global Undo Anexo 04: Especificacin Patrn de Usabilidad Abort Anexo 05: Especificacin Patrn de Usabilidad System Progress Feedback Anexo 06: Patrones de Usabilidad en la Elicitacin
156 166 177 190 204 213
ndice de Figuras
Figura 1: Iteraciones AUP .....................................................................................................................23 Figura 2: Ciclo de vida de un proyecto AMDD .....................................................................................24 Figura 3: Ciclo de vida de un proyecto AMDD .....................................................................................29 Figura 4: Ciclo de vida de un proyecto FDD. .......................................................................................33 Figura 5: Ciclo de vida AUP .................................................................................................................45 Figura 6: Ciclo de vida del marco gil de trabajo ................................................................................46 Figura 7: Hito de la fase de Inicio. ........................................................................................................48 Figura 8: Formato de Historias de usuarios segn XP .........................................................................48 Figura 9: Formato de Historias de usuarios segn el marco gil. ........................................................49 Figura 10: Formato de Pruebas de Aceptacin. ....................................................................................50 Figura 11: Formato del Product Backlog ..............................................................................................51 Figura 12 : Hito de la fase de Elaboracin ...........................................................................................52 Figura 13: Trazabilidad de Modelos MDA ............................................................................................57 Figura 14: Transformacin de metamodelos bajo MDA. ......................................................................58 Figura 15: Marcado de un modelo bajo MDA .......................................................................................58 Figura 16: Patrones de transformacin en los modelos MDA...............................................................59 Figura 17: Ciclo AndroMDA de generacin de cdigo .........................................................................62 Figura 18: Arquitectura de Aplicacin base del marco gil de trabajo ................................................63 Figura 19: Estructura de Aplicacin empresarial AndroMDA..............................................................64 Figura 20: Diagrama de Actividad en AndroMDA ................................................................................66 Figura 21: Componente controlador en AndroMDA .............................................................................67 Figura 22: Casos de Uso AndroMDA ....................................................................................................67 Figura 23: Modelado de servicios en AndroMDA .................................................................................68 Figura 24: Modelado de entidades de datos en AndroMDA..................................................................68 Figura 25: Dependencia entre componentes de capa en AndroMDA ....................................................69 Figura 26: Herramienta de gestin Sprintometer ..................................................................................71 Figura 27: Seccin de registro de Sprint en Sprintometer .....................................................................72 Figura 28. Seccin de control de avance de tareas en el Sprint bajo Sprintometer ..............................72 Figura 29: Vista de la planificacin en das ..........................................................................................98 Figura 30: Sprint y tareas de la primera Iteracin en Spritometer ......................................................99 Figura 31: Modelo de entidades de la capa de datos ..........................................................................103 Figura 32: Modelado de la capa de negocio .......................................................................................103 Figura 33: Dependencias de servicios con las entidades de datos ......................................................104 Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas ...................................104 Figura 35: Modelado de la clase controladora ...................................................................................105 Figura 36: Diagrama de actividad asociado a la capa de presentacin .............................................106 Figura 37: Bsqueda de personas Pgina principal de la aplicacin ..............................................107 Figura 38: Relacionar Personas Criterio de seleccin de personas a relacionar ............................107 Figura 39: Relacionar Personas Adicin de relaciones a la persona seleccionada.........................108 Figura 40 Diagrama de clases de la especificacin del patrn de usabilidad Warning...................110 Figura 41: Diagrama de secuencia de la especificacin del patrn de usabilidad Warning ..............110 Figura 42: Modelado de la clase controladora con el Patrn de usabilidad Warning .......................111 Figura 43: Confirmacin de adicin de nueva relacin segn el patrn de usabilidad Warning ......114 Figura 44: Resultados tras la confirmacin de la adicin de una nueva relacin ..............................114 Figura 45: Diagrama de clases de la especificacin del patrn de usabilidad SSF............................116 Figura 46: Diagrama de secuencia de la especificacin del patrn de usabilidad SSF ......................116 Figura 47: Integracin del patrn de usabilidad SSF en el diseo de la funcionalidad Relacionar Personas .......................................................................................................................................117 Figura 48: Resultados tras la adicin satisfactoria de una nueva relacin ........................................120 Figura 49: Resultados de error tras la adicin de una nueva relacin ...............................................120 Figura 50: Diagrama de clases de la especificacin del patrn de usabilidad GU ............................122 Figura 51: Diagrama de secuencias de la especificacin del patrn de usabilidad GU .....................122 Figura 52: Integracin del patrn de usabilidad GU en la capa de negocio y capa de diseo ...........123 Figura 53: Integracin del patrn de usabilidad GU en el diagrama de actividades de la pgina de Adicin de relaciones ...................................................................................................................124
Figura 54: Adicin de nuevas relaciones considerando el patrn GU ................................................126 Figura 55: La adicin de relaciones tras en el evento de deshacer (Undo) ........................................127 Figura 56: Diagrama de clases de la especificacin del patrn de usabilidad AO .............................128 Figura 57: Diagrama de secuencia de la especificacin del patrn de usabilidad AO .......................129 Figura 58: Integracin del patrn de usabilidad AO en la capa de negocio y capa de presentacin .130 Figura 59: Integracin del patrn de usabilidad AO en el diagrama de actividades de la pgina de Adicin de relaciones ...................................................................................................................131 Figura 60: Adicin de nuevas relaciones considerando el patrn AO ................................................133 Figura 61: Home de la aplicacin tras el evento Cancelar .................................................................134 Figura 62: Consulta de relaciones tras el evento de cancelar .............................................................134 Figura 63: Diagrama de clases de la especificacin del patrn de usabilidad SPF ...........................135 Figura 64: Diagrama de secuencia de la especificacin del patrn de usabilidad SPF .....................136 Figura 65: Integracin del patrn de usabilidad SPF en la capa de negocio y capa de diseo..........137 Figura 66: Integracin del patrn de usabilidad SPF en el diagrama de actividades de la pgina Web de Adicin de relaciones ..............................................................................................................138 Figura 67: Esquema de trabajo del objeto XMLHttpRequest ..............................................................140 Figura 68: Adicin de distintas relaciones a la persona seleccionada................................................142 Figura 69: Barra de progreso mientras se aplica la operacin de Undo a las relaciones adicionadas ......................................................................................................................................................142 Figura 70: Diagrama de secuencia de la especificacin del patrn de usabilidad AC .......................144 Figura 71: Integracin del patrn de usabilidad AC en la capa de negocio y capa de diseo ...........145 Figura 72: Integracin del patrn de usabilidad AC en el diagrama de actividades de la pgina Web de Adicin de relaciones ..............................................................................................................146 Figura 73: Adicin de distintas relaciones a la persona seleccionada................................................149 Figura 74: Barra de progreso con opcin de cancelar, ante la operativa de Undo de las relaciones adicionadas ..................................................................................................................................149 Figura 75: Tras el evento de cancelar el comando de Undo de relaciones .........................................150 Figura 76: Carga de trabajo a lo largo de la planificacin ................................................................151
ndice de Tablas
Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologas giles. .....................36 Tabla 2: Estado actual de las metodologas giles ...............................................................................37 Tabla 3: Comparativa de calidad en las metodologas giles ..............................................................38 Tabla 4: Herramientas de libre distribucin para metodologas giles. ...............................................39 Tabla 5 : Detalle de secciones del Sprintometer ....................................................................................72 Tabla 6: Product backlog.......................................................................................................................77 Tabla 7: Historia de usuario Relacionar personas .............................................................................79 Tabla 8: Historia de usuario Gestionar fusin de personas ...............................................................81 Tabla 9: Historia de usuario Buscar personas fusionadas .................................................................84 Tabla 10: Historia de usuario Recuperar datos entidad financiera ...................................................85 Tabla 11: Historia de usuario Gestionar Situacin familiar de la persona........................................87 Tabla 12 : Prueba de aceptacin Relacionar personas ......................................................................88 Tabla 13: Prueba de aceptacin Gestionar fusin de personas..........................................................90 Tabla 14: Prueba de aceptacin Buscar personas fusionadas ...........................................................91 Tabla 15: Prueba de aceptacin Recuperar datos entidad financiera................................................93 Tabla 16: Prueba de aceptacin Gestionar situacin familiar ...........................................................94 Tabla 17: Product backlog.....................................................................................................................98 Tabla 18: Planificacin del Sprint Relacionar Personas ..................................................................100 Tabla 19: Planificacin inicial de la tarea de implementacin de la funcionalidad ...........................102 Tabla 20: Actualizacin de la planificacin de la tarea de implementacin de la funcionalidad .......108 Tabla 21: Planificacin inicial de la tarea de integracin del patrn de usabilidad Warning ...........109 Tabla 22: Correspondencia de componentes del patrn de usabilidad Warning y los componentes de la funcionalidad................................................................................................................................112 Tabla 23- Planificacin actualizada de la tarea de integracin del patrn de usabilidad Warning ...115 Tabla 24: Planificacin inicial de la tarea de integracin del patrn de usabilidad SSF ...................115 Tabla 25: Correspondencia de componentes del patrn de usabilidad SSF y los componentes de la funcionalidad................................................................................................................................118 Tabla 26: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SSF...........121 Tabla 27: Planificacin inicial de la tarea de integracin del patrn de usabilidad GU....................121 Tabla 28: Correspondencia de componentes del patrn de usabilidad GU y los componentes de la funcionalidad................................................................................................................................124 Tabla 29: Planificacin actualizada de la tarea de integracin del patrn de usabilidad GU ..........127 Tabla 30: Planificacin inicial de la tarea de integracin del patrn de usabilidad AO ....................129 Tabla 31: Correspondencia de componentes del patrn de usabilidad AO y los componentes de la integracin ...................................................................................................................................131 Tabla 32: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AO ............135 Tabla 33: Planificacin inicial de la tarea de integracin del patrn de usabilidad SPF...................136 Tabla 34: Correspondencia de componentes del patrn de usabilidad SPF y los componentes de la Integracin ...................................................................................................................................139 Tabla 35: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SPF ..........143 Tabla 36: Planificacin inicial de tarea de integracin del patrn de usabilidad AC ........................144 Tabla 37: Correspondencia de componentes del patrn de usabilidad AC y los componentes de la integracin ...................................................................................................................................147 Tabla 38: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AC ............150
I. Introduccin
La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones especficas de uso.
Es considerada la usabilidad tambin, como la medida en que un producto puede ser usado por usuarios especficos, para lograr los objetivos especificados con efectividad, eficiencia y satisfaccin en un contexto especfico de uso.
En el campo de la Ingeniera de software, hablar de usabilidad hoy en da, es relacionar con la interfaz de usuario, por lo tanto, la usabilidad afectara a la UI y no a la funcionalidad bsica del sistema. De acuerdo a esto, la usabilidad debe ser tratada al final del desarrollo del sistema, como un atributo ms de calidad y que no necesita demasiadas pruebas (Hiptesis de la separacin).
En contraposicin, a la idea que se tiene hoy en da de la usabilidad, existen investigaciones en el campo de la ingeniera de Software, donde, se describe que las Isuues de usabilidad son limitaciones estticas y dinmicas a los componentes de software y que la separacin de la interfaz de usuario de la funcionalidad bsica, no garantiza que se entregue un producto usable al cliente final.
Confirmada la relacin entre diseo de software y usabilidad, la revisin del costo para alcanzar un nivel aceptable de usabilidad debera ser mayor que lo planteado por la hiptesis de separacin, 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 diseo 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, tcnicas para hacer frente a estos atributos en tiempo de diseo arquitectnico.
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 categoras de impacto:
Usabilidad con impacto en la UI, esto afecta a la presentacin del sistema, como puede ser botones, color de fondo, etc. Para dar solucin a esto, solo se realizan cambios en el diseo detallado de la UI y no en el Funcionalidad bsica del sistema.
Usabilidad con impacto en el proceso desarrollo, esto afecta al proceso de desarrollo, donde, estas recomendaciones proponen directrices para alentar la interaccin 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 tcnicas mas potentes para la obtencin de requisitos, que probablemente se tenga que apoyar en otras disciplinas como HCI, con el objetivo de poder hacer participe al usuario en la construccin del software
Usabilidad con impacto en el diseo, estas son recomendaciones que implican actividades de construccin de funcionalidades en el Software, para mejorar la actividad usuario sistema, por ejemplo funcionalidades como: Cancelar una tarea en curso.
Segn las recomendaciones dadas por la literatura HCI, hoy en da se han realizado estudios enfocados, ms que todo en el impacto de la usabilidad en el diseo (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 da, se vienen utilizando en proyecto de desarrollo de software tradicional, es decir, proyectos que siguen lineamientos de metodologas de desarrollo tradicional.
Es de acuerdo a esta premisa, que el presente trabajo tiene como objetivo principal, la inclusin de los principios de usabilidad, en proyectos Software, que se desarrollen en base a metodologas 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 diseo (ver anexos).
Estos mecanismos, debern de ser tomados en cuenta, en los planteamientos de la metodologa o metodologas 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
mismo: Captulo I (Metodologas giles), se detallar los planteamientos de las metodologas giles mas conocidas hoy en da, buscando con esto, seleccionar la metodologa o metodologas, que nos permitan incluir los principios de usabilidad. Capitulo II (Marco gil de trabajo), en base a la metodologa o metodologas seleccionadas, se crear un marco de trabajo gil, donde se detalle los lineamientos para el ciclo de vida del software a desarrollar, donde tambin, 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 elaboracin del marco gil de trabajo), es donde, se describir el desarrollo del sistema, siguiendo los lineamientos del marco gil de trabajo.
La Usabilidad en Metodologas giles
II. Metodologas giles
Versin 3.0
La Usabilidad en Metodologas giles Metodologas giles
Junio 2009 Version 3.0
Historia del documento

FECHA 08/05/2009 25/05/2009 15/06/2009 VERSION 1.0 2.0 3.0 DESCRIPCIN Metodologas giles Metodologas giles Metodologas giles AUTOR Jos Germn Nez Mori Jos Germn Nez Mori Jos Germn Nez Mori
Jos Germn Nez Mori
Pgina 13 de 237
Metodologas giles
1. Introduccin
A principios de las dcada 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 consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo de forma automtica 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 despus 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 metodologas giles, poco despus formando la Alianza gil, que es una organizacin sin fines de lucro, que promueve el desarrollo gil de aplicaciones [CLEP09].
Las metodologas giles nacen como una reaccin contra los mtodos de peso pesado, muy estructurados y estrictos, extrados del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrtico, lento degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente [WDAS09].
2.
Descripcin
Las metodologas giles son un marco conceptual de la Ingeniera de Software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto, considerando una iteracin como una unidad de tiempo que dura de uno a cuatro semanas. Donde cada iteracin del ciclo de vida incluye planificacin anlisis, diseo, codificacin, revisin y documentacin [WDAS09]. Una iteracin 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 iteracin.
Las metodologas giles buscan lo siguiente [WDAS09]: Evitar los tortuosos y burocrticos caminos de las metodologas tradicionales, enfocndose en la gente y los resultados. Jos Germn Nez Mori Pgina 14 de 237
Minimizar los riesgos, desarrollando software en cortos lapsos de tiempo (iteraciones). Enfatizar las comunicaciones cara a cara en vez de la documentacin. Enfatizar que el software funcional es la primera medida del progreso. Las metodologas giles platean centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software, siendo esto su principal filosofa. Dando mayor valor al individuo, a la colaboracin 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 drsticamente los tiempos de desarrollo pero manteniendo una alta calidad.
3.
Manifiesto gil
En esta seccin se detalla los principios bsicos del Manifiesto gil, inspirando en base a lo expuesto en: Manifiesto for Agile Software Development [MFAS01]. Como consecuencia de la reunin donde se acuo el trmino Metodologas giles (febrero 2001), se establecieron los principios de estas metodologas agrupndoles en cuatro postulados, quedando esta agrupacin denominada como Manifiesto gil. A continuacin se mencionan los cuatro postulados de este manifiesto:
Valorar ms a los individuos y su interaccin que a los procesos y las herramientas, es decir, la gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno.
Valorar ms el software que funciona que la documentacin exhaustiva, donde la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar decisiones importantes.
Valorar ms la colaboracin con el cliente que la negociacin contractual, es decir, se propone que exista una interaccin 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 caractersticas que diferencian un proceso gil de uno tradicional A continuacin se detallarn los doce principios del manifiesto, donde, los dos primeros principios son generales y resumen gran parte del espritu gil, el resto tienen que ver con el proceso a seguir y Jos Germn Nez Mori Pgina 15 de 237
con el equipo de desarrollo, en cuanto a metas y organizacin del mismo [CLEP09]:
Nuestra principal prioridad es satisfacer al cliente a travs 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 travs del proyecto.
Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el respaldo que necesitan y procurndoles confianza para que realicen la tarea.
La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin 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 atencin continua a la excelencia tcnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se auto-organizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su conducta en consecuencia.
4.
Principales metodologas giles
En esta seccin se describirn las principales metodologas giles destacadas hasta el momento.
4.1 Programacin Extrema (XP)

La definicin de esta metodologa, se ha realizado tomando como base las siguientes referencias: [RJEF99], [RMAT6], [SMHR04], [CLEP09].Definicin La programacin Extrema (en adelante XP) es una metodologa de desarrollo ligera (o gil) basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.
Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en Jos Germn Nez Mori Pgina 16 de 237
la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programacin
Los ingredientes utilizados en esta metodologa son conocidos desde el principio de la informtica, donde, los autores de la metodologa 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 seleccin ha sido esta metodologa 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.
4.1.1 Principios bsicos

La metodologa XP se basa en 12 principios bsicos, agrupados en 4 categoras, las cuales se detallan a continuacin:
Principio 1 - Retroalimentacin en escala fina:
a) El principio de pruebas, se tiene que establecer un periodo de pruebas de aceptacin (periodo de caja negra), donde se definirn las entradas al sistema y los resultados esperados en cada una de las pruebas definidas. b) Proceso de planificacin, 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 Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin. 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 interaccin cara a cara entre el programador y el cliente, con el objetivo de disminuir el tiempo de comunicacin y la cantidad de documentos, junto con sus altos costes de creacin y mantenimiento. Este representante del cliente, deber formar parte del equipo de trabajo durante toda la realizacin del proyecto, teniendo la potestad para determinar requerimientos definir funcionalidades, sealar prioridades y responder preguntas de los programadores. d) Programacin en pareja, la metodologa plantea que los programadores XP escriban su cdigo en parejas, compartiendo una sola maquina con el objetivo de producir aplicaciones mejores, de manera consistente a iguales o menores costes.
Jos Germn Nez Mori
Pgina 17 de 237
Principio 2 - Proceso continuo en lugar de por lotes:
a) Integracin contina, permite al equipo de programadores hacer un rpido progreso implementando las nuevas caractersticas del software. b) Refactorizacin, permite a los equipos de programadores XP mejorar el diseo del sistema, donde a lo largo de todo el proceso de desarrollo, los programadores evalan continuamente el diseo y recodifican lo necesario. c) Entregas pequeas, consiste en colocar un sistema sencillo en entono de produccin rpidamente, que se actualice de manera continua, permitiendo que el verdadero valor del negocio sea evaluado en un ambiente real.
Principio 3 - Entendimiento compartido:
a) Diseo simple, se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente. b) Metfora, 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 metfora expresa la visin evolutiva del proyecto que define el alcance y propsito del sistema c) Propiedad colectiva del cdigo, la metodologa XP promueve la filosofa de un cdigo con propiedad compartida, donde, nadie es propietario de nada y que todos son propietarios de todo d) Estndar de codificacin, define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el cdigo 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 programacin extrema sostiene que los programadores cansados escriben cdigo de menor calidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad.
4.1.2 Proceso de desarrollo

XP, parte del caso habitual de una compaa que desarrolla software, normalmente a medida, en Jos Germn Nez Mori Pgina 18 de 237
la que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes finales. El proceso conlleva las siguientes actividades:
a) Interaccin con el cliente En este tipo de programacin, el cliente pasa a formar parte implicada en el equipo de desarrollo, donde, su importancia es mxima en el momento de tratar con los usuarios y efectuar las planificaciones respectivas. Al tener al cliente mucho ms cerca del equipo de desarrollo, se elimina la fase inicial de recopilacin 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 tcnicas 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 tcnico ser el 'encargado de catalogar las historias del cliente y asignarles una duracin. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programacin.
b) Planificacin del proyecto En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn diferentes iteraciones, y por cada iteracin el cliente ha de recibir una versin nueva. Se ha de tener asumido que en el proceso de planificacin habr errores, ante lo cual la metodologa establece mecanismos de revisin, donde cada tres o cinco iteraciones es normal revisar las historias de los usuarios y renegociar la planificacin. Adems la metodologa establece que por cada iteracin se realizar un planificacin, que es lo que se llama Planificacin iterativa, en la que se anotar las historia de los usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptacin realizadas por el cliente.
c) Diseo desarrollo y pruebas El desarrollo es la parte ms importante en el proceso de la programacin extrema. Todos los trabajos tienen como objetivo que se programen lo ms rpidamente posible, sin interrupciones y en direccin correcta Para el diseo, la metodologa establece mecanismos, para que este sea revisado y mejorado de manera continua, segn se vaya aadiendo funcionalidad al sistema. Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir una prueba sencilla, y despus escribir el cdigo para que la pase. Una vez pasada se ampla y se contina. Jos Germn Nez Mori Pgina 19 de 237
Con estas normas se obtiene un cdigo simple y funcional de manera bastante rpida. 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 integracin diaria.
4.2
Proceso Unificado gil (AUP)
La definicin de esta metodologa, se ha realizado tomando como base las siguientes referencias: [CRLA02], [SABL06]. [KINT07], [WAUP09].
4.2.1 Descripcin
El Proceso Unificado gil (en adelante, AUP), se describe como una metodologa fcil de entender para el desarrollo de aplicaciones software de negocio, utilizando tcnicas giles y conceptos aun fieles a las de RUP, por lo tanto, es una versin simplificada del Rational Unified Process (RUP).
AUP, incluye o hace uso de las siguientes tcnicas giles: Test driven development (TDD). Agile model driven development (AMDD). Agile change management. Data base refactoring.
AUP, es una metodologa que tiene la adopcin de muchas de las tcnicas giles de la metodologa XP (Extreme Programming) y de las formalidades de RUP, teniendo como filosofa adaptarse a las necesidades del proyecto y no al contrario como lo planteado en las metodologas tradicionales. Esta metodologa, plantea un ciclo de vida iterativo, que se basa en la ampliacin y refinamiento sucesivo del sistema, mediante mltiples iteraciones con retroalimentacin cclica y adaptacin como elementos principales que dirigen para converger hacia un sistema adecuado.
4.2.2
Principio bsicos
Como parte de esta metodologa, en la presente seccin se detalla, tanto las fases y disciplinas de su planteamiento: Jos Germn Nez Mori Pgina 20 de 237
a) Fases Al igual que RUP, AUP tiene las 4 fases clsicas consecutivas y que acaban cada uno de estas, con hitos claros alcanzados: Inception (Concepcin): El objetivo de esta fase es obtener una comprensin comn clienteequipo de desarrollo, del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo. Elaboracin: El objetivo es que el equipo de desarrollo profundice en la comprensin de los requisitos del sistema y en validar la arquitectura. Construccin: Durante la fase de construccin el sistema es desarrollado y probado al completo en el ambiente de desarrollo. Transicin: el sistema se lleva a los entornos de preproduccin donde se somete a pruebas de validacin y aceptacin y finalmente se despliega en los sistemas de produccin.
b) Disciplinas El proceso AUP, establece un modelo ms simple que el planteado en RUP, por lo que rene en una nica disciplina: el modelado de negocio, requisitos y anlisis y diseo. El resto de disciplinas coinciden con las restantes de RUP, a continuacin se describe las disciplinas consideradas por AUP: Modelado: Se busca entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable. Implementacin: Consiste en transformar los modelos o modelo en cdigo ejecutable y realizar un nivel bsico de las pruebas, en particular Unit testing. Pruebas: Se busca realizar una evaluacin objetiva para garantizar la calidad. Esto incluye la bsqueda de defectos, validar que el sistema funciona tal como est establecido, y verificando que se cumplan los requisitos. Despliegue: Consiste en la elaboracin de un plan para la entrega del sistema y ejecutar el plan para que el sistema este a disposicin de los usuarios finales. Gestin de Configuracin: Consiste en administrar el acceso a los artefactos del proyecto. Esto incluye no slo el seguimiento de las versiones de los artefactos en el tiempo, sino tambin el control y la gestin de los cambios de estos. Administracin del Proyecto: Consiste en dirigir las actividades que se llevan a cabo dentro del proyecto. Esto incluye la gestin de riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos, etc), y de coordinacin con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que el software final sea Jos Germn Nez Mori Pgina 21 de 237
La Usabilidad en Metodologas giles Metodologas giles entregado a tiempo y dentro del presupuesto.
Entorno: Es un soporte para el resto de los esfuerzos para garantizar un proceso adecuado, orientacin (normas y directrices), y herramientas (hardware, software, etc) estn disponibles para el equipo segn sea necesario.

En esta metodologa las disciplinas se llevan acabo de manera iterativa, con la definicin 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 metodologa plantea las diferentes actividades y artefactos a producir, lo cual no implica que se realicen o se produzcan todo lo planteado si no ms bien lo que se necesita en el proyecto.
Las fases que platea la metodologa no constituye el antiguo ciclo de vida secuencial o en cascada, si no ms 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 Elaboracin no es una fase de requisitos o diseo, si no que es una fase donde se implementa de manera iterativa la arquitectura que constituye el ncleo central del sistema, y es donde se mitiga las cuestiones de alto riesgo. En la fase de construccin, 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 iteracin en la que se encuentre, debido a que el esfuerzo relativo en las disciplinas disminuye de iteracin en iteracin.
AUP, plantea que en lugar del big bang en la entrega del software, una liberacin del producto en partes, por ejemplo versin 1, luego versin 2 del software en produccin y as sucesivamente hasta tener el producto completado. De acuerdo a este planteamiento AUP distingue dos tipos de iteraciones: Versin de desarrollo, cuyo resultado esta un despliegue en entorno QA (Aseguramiento de la calidad) o Demo rea, estas versiones deben ser rpidas, de ser posible de una a tres semanas de desarrollo. Jos Germn Nez Mori Pgina 22 de 237
Versin producto, cuyo resultado es un despliegue en produccin, 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 gestin 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 elaboracin del producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que determinan los riesgos tcnicos.
4.3
Agile model driven development (AMDD)
La definicin de esta metodologa, se ha realizado tomando como base la siguiente referencia: [SABL08].
4.3.1 Descripcin
Agile model driven development (en adelante, AMDD), es una versin gil del Model driven development (MDD), donde MDD es un enfoque amplio de desarrollo de software donde se crean modelos antes del cdigo fuente. Un ejemplo de MDD es el estndar 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 cdigo 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.
4.3.2 Principio bsicos

AMDD, plantea las siguientes dos etapas como parte de su ciclo de vida del proyecto: Previsin (Envisioning), etapa que pertenece a la iteracin 0, consta de dos sub-actividades: o Previsin inicial de requerimientos (Initial Requirements Envisioning). Pgina 23 de 237
Jos Germn Nez Mori
La Usabilidad en Metodologas giles Metodologas giles Previsin inicial de la arquitectura (Initial Architectural Envisioning).
Ambas sub actividades, son recomendadas por la metodologa que se realicen en periodos diarios, durante el tiempo que dure la iteracin 0. Desarrollo (Development), iteracin que ser repetida hasta alcanzar un producto de calidad, consta de sub actividades a mencionar: o o o Iteracin de modelado (Iteration Modeling). Modelo de asalto (Model Storming). Evaluacin en base a TDD (Test driven development)
Figura 2: Ciclo de vida de un proyecto AMDD

A continuacin, se detalla el proceso de desarrollo del ciclo de vida de un proyecto que hace uso de la metodologa AMDD: Modelo inicial de requerimientos (Initial Requirements Envisioning), es necesario tomar varios das para identificar algunos de los requisitos de alto nivel y el alcance del software, todo esto como una primera versin 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 Germn Nez Mori Pgina 24 de 237
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 direccin tcnica para el proyecto y proporcionar informacin suficiente para la organizacin del equipo alrededor de esta arquitectura (importante para proyectos de gran escala).
De este modelado inicial, perteneciente a la iteracin de Previsin (Envisioning), se obtendr: diagramas de forma libre que exploren la infraestructura tcnica 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 continuacin se detalla la etapa de Desarrollo (Development) de un proyecto basado en AMDD:
Iteracin de modelado (Iteration Modeling), donde al comienzo de cada iteracin de desarrollo, el equipo debe planificar el trabajo que har en la iteracin 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 renen 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 reunin los integrantes del equipo siguen su labor de construccin.
AMDD, plantea que a final de cada construccin se realice pruebas unitarias del cdigo desarrollado y la refactorizacin si fuese necesario, todo esto basado en el Test Driven Development (TDD).
4.4
Scrum
La definicin de esta metodologa, se ha realizado tomando como base las siguientes referencias: [KSXHB09], [JSUT09]. [JPAL02], [SMHR04].
4.4.1 Descripcin
Scrum, plantea un proceso de desarrollo de software iterativo y creciente, utilizado
Jos Germn Nez Mori
Pgina 25 de 237
La Usabilidad en Metodologas giles Metodologas giles comnmente en entornos basados en el desarrollo gil de software.
Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de programas: Scrum de Scrums. Scrum, por sus caractersticas no es vlido 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.
4.4.2 Principio bsicos

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 metodologa 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 metodologa 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 continuacin 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 das que dure el Sprint backlog con el equipo de desarrollo, con lo cual se busca identificar obstculos o riesgos que impidan el normal avance, verificar el avance de las tareas y la planificaciones de las mimas para el da. Jos Germn Nez Mori Pgina 26 de 237
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 aplicarn los cambios y ajustes si son necesarios, y se marcarn los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint backlog.

El proceso parte de la lista de tareas (Product backlog), que no son otra cosa que los requisitos del producto y que acta como un plan del proyecto. De esta lista el cliente prioriza los requisitos basndose 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 replanificacin de objetivos que se puede realizar al inicio de cada iteracin.
Cada da de una iteracin debe realizarse una reunin con los integrantes del equipo con el objetivo de obtener de primera mano los avances de las tareas y los obstculos que se van presentando a lo largo del desarrollo de la iteracin
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 iteracin. 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 planificacin de la siguiente iteracin a realizar.
4.5
Dynamic Systems Development Method (DSDM)
La definicin de esta metodologa, se ha realizado tomando como base las siguientes referencias: [DSDM09], [MART91], [SMHR04], [WDSDM09], [JCCA08].
Jos Germn Nez Mori
Pgina 27 de 237
4.5.1 Descripcin
La metodologa Dynamic system development Method (en adelante DSDM), es una metodologa que surgi de un consorcio formado por 17 miembros fundadores en enero del 1994. El objetivo de este consorcio era producir una metodologa de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizada en proyectos de tipo RAD (desarrollo de aplicaciones rpidas).

La estructura de esta metodologa 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 propsitos del negocio es el criterio esencial para la aceptacin de los entregables. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. Todos los cambios durante el desarrollo son reversibles. Los requerimientos estn especificados a un alto nivel. El testing es integrado a travs del ciclo de vida. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.
DSDM tiene las bases sentadas para el anlisis sobre su aplicabilidad a un grupo bien definido de proyectos software, los cuales debern tener las siguientes caractersticas: Son proyectos interactivos con la funcionalidad visible en la interfase de usuario. De baja o media complejidad computacional. Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran tamao. Acotados en el tiempo. Con flexibilidad en los requerimientos. Con un grupo de usuarios bien definidos y comprometidos al proyecto.
Esta metodologa planeta 5 fases en la construccin de un sistema, las cuales son: Estudio de factibilidad. Pgina 28 de 237
Jos Germn Nez Mori
Estudio del negocio. Iteracin del modelo funcional. Iteracin del diseo y construccin. Implementacin.
Figura 3: Ciclo de vida de un proyecto AMDD

La metodologa plantea que en la fase de estudio de la factibilidad, se permita determinar si la metodologa se ajusta al proyecto en cuestin, es decir, si las pautas dadas por DSDM pueden utilizarse de manera optima para llevar acabo el sistema. Jos Germn Nez Mori Pgina 29 de 237
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 caractersticas 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 dems fases siguen el modelo iterativo incremental integrado con la retroalimentacin (feedback) del cliente y las entregas frecuentes del producto.
En la iteracin de modelo funcional, se realizan tanto tareas de anlisis 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 iteracin genera un modelo funcional, el cual contiene el cdigo del prototipo y los modelos de anlisis.
En la iteracin de diseo y construccin, es donde se construye el sistema, dando como resultado final, un sistema probado, que satisface los mnimos requisitos establecidos.
La iteracin de implementacin, consiste en pasar del entorno de desarrollo al entorno de produccin. Se da formacin a los usuarios y finalmente se abre el sistema para que sea utilizado. En esta fase, adems de la liberacin del sistema, se debe entregar manuales de usuario e informes de revisin del proyecto.
En este punto, la metodologa 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 crticas, por lo tanto se vuelve a la fase de modelo funcional. Existen problemas tcnicos que no se han podido resolver debido a la falta de tiempo, por lo tanto, se corregirn realizando las iteraciones que hagan falta desde la fase de diseo y construccin.
DSDM, no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni Jos Germn Nez Mori Pgina 30 de 237
siquiera impone el desarrollo bajo un paradigma especfico, funciona tanto para el modelo orientado a objetos como para el modelo estructurado.
En la metodologa DSDM, se incluye un nuevo trmino llamado timebox, que no es ms 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: Investigacin, donde se verifica que las actividades del timebox coincidan con la arquitectura del sistema. Refinamiento, donde se realiza la produccin de los artefactos planificados en la iteracin. Consolidacin, donde se completan los entregables verificando la calidad de los mismos.
4.6
Feature Driven Development (FDD)
La definicin de esta metodologa, se ha realizado tomando como base las siguientes referencias: [CLEP09], [COAD98], [WFDD09].
4.6.1 Descripcin
La metodologa Feature driven development (en adelante FDD), se estructura alrededor de la definicin 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 comn que fomente, que los desarrolladores tengan un dilogo fluido con los clientes,
desarrollando entre ambos un modelo comn del negocio.

FDD, posee una jerarqua de features, siendo el del eslabn superior el feature set, que agrupa un conjunto de features relacionados con aspectos en comn del negocio. Por ltimo se establece el major feature set que contribuye a proveer valor al cliente en relacin a un subdominio dentro del dominio completo de la aplicacin. Esta jerarqua utiliza los siguientes formatos Para features: <accin> el <resultado> <de | para | sobre | por> un <objeto> Pgina 31 de 237
Jos Germn Nez Mori
Para feature sets: <accin><-endo> un <objeto> Para major feature sets: administracin de <accin>
Ejemplos de esto: Calcular el total de la facturacin de Noviembre (feature) Modificar el estado de las facturas de produccin (feature) Administrar el perfil de los proveedores (feature) Haciendo una venta a un cliente (feature set) Cargando la facturacin de los proveedores (feature set) Administracin 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 Germn Nez Mori
Pgina 32 de 237
Figura 4: Ciclo de vida de un proyecto FDD.

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 construccin de la arquitectura del software. Para la construccin de este modelo participan tanto los expertos en el dominio como los desarrolladores. Con esto se intenta lograr:
Un conocimiento global de la aplicacin a construir, el entendimiento del negocio en que esta embebido, un primer bosquejo de los features del software y la definicin de las restricciones y cuestiones no funcionales. Pgina 33 de 237
Jos Germn Nez Mori
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 jerrquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorizacin de las mismas basndose en la satisfaccin 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 lder de proyecto, el lder de desarrollo y el programador jefe. A medida que se realiza la planificacin se delinean los hitos de finalizacin de las iteraciones, dejando asentado cuales son los features y features sets que estarn construidos en dichos hitos, en esta etapa tambin se incluye la delegacin de responsabilidades.
Las dos ltimas actividades, Disear por features y construir por features, estn relacionadas con la parte productiva del proceso en que se construye la aplicacin de manera incremental. Para la iteracin del diseo, el Jefe de programadores junto con un grupo de Programadores expertos identifica las clases, atributos y mtodos que necesita la funcionalidad requerida en un feature. Mediante la utilizacin de diagramas UML se verifica que el diseo pueda ser implementado.
Posteriormente en la etapa de construccin 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 cdigo por equipos asignados a la revisin del feature en desarrollo, una vez finalizado esta revisin se promueve el cdigo a BUILD, siendo entregado a Gestin de la configuracin.
La metodologa recomienda reuniones semanales entre el Lder del proyecto y el Jefe de los programadores, donde, se permita revisar el estado de los features que se estn desarrollando.
Comparativa entre metodologas giles
En esta seccin se realizar una comparativa entre cada unas de las metodologas mencionadas en la seccin 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 Germn Nez Mori
Pgina 34 de 237
caractersticas fundamentales de las metodologas en estudio. Dentro de los criterios a considerar tenemos Ciclo de vida del proyecto, donde tomaremos como base el ciclo de vida estndar de un proyecto. Soporte a la gestin en cada unas de las etapas del ciclo de vida del proyecto. Buenas prcticas, actividades y artefactos producidos en las distintas etapas planteadas por la metodologa. Estado actual de la metodologa. Soporte a la calidad en el planteamiento de la metodologa. Herramientas especficas que pueden dar soporte a la metodologa en cuestin.
5.1
Criterios de comparacin
En esta seccin se detallar cada uno de los criterios necesarios para la comparativa entre las metodologas giles en estudio.
5.1.1 Ciclo de vida del proyecto

Para este criterio se va a considerar las siguientes etapas como parte del ciclo de vida de un proyecto estndar: Principio del proyecto. Especificacin de requisitos. Anlisis y Diseo. Codificacin Pruebas unitarias. Pruebas de integracin. Pruebas de sistemas. Pruebas de aceptacin. Sistema en uso o mantenimiento.
En base a las etapas mencionadas anteriormente, se analizar si cada una de las metodologas en estudio contempla estas etapas, si describe buenas prcticas 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 metodologas giles):
Jos Germn Nez Mori
Pgina 35 de 237
Metodologa Programacin Extrema (XP) Scrum Dynamic Systems Development Method (DSDM) X Proceso Unificado gil (AUP) X Agile Model Driven (AMDD) Feature Driven Development (FDD)
Principio del Espec. Anlis y Pruebas Pruebas de Pruebas de Pruebas de Codificacin Mantenimiento Proyecto Requisitos Diseo Unitarias Integracin Sistemas Aceptacin 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 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
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 X X X X
X X
X X X
X X
X X X
X X
X X X
X X
X X X
SG: Soporte a la gestin. PD: Se describe un proceso en el mtodo que incluye esta etapa. BA: Buenas prcticas, actividades y artefactos considerados en la etapa.
Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologas giles.
Jos Germn Nez Mori
Pgina 36 de 237
5.1.2 Estado Actual

Para este criterio se tomar en cuenta, los siguientes estados en los cuales se podra encontrar las metodologas en estudio:
Recin nacida, metodologas que tiene un ao o menos y de la cual no tenemos evidencias ni estudios. En construccin, metodologas con ms de un ao de existencia, pero que no dispone de evidencia documentada. Activa, metodologas que llevan muchos aos en el desarrollo del software y de las cuales podemos encontrar evidencias y estudios que corroboren su efectividad. Olvidada, metodologas que llevan tiempo sin ser utilizadas y de las cuales no se encuentra evidencia.
A continuacin una tabla (ver tabla 2 Estado actual de las metodologas giles), que informan el estado actual de cada una de las metodologas en estudio:
Metodologa Programacin 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 metodologas giles
5.1.3 Calidad
Con este criterio se busca analizar si las metodologas en estudio contemplan ciertos parmetros de calidad en su enunciado metodolgico. Dentro de los parmetros a considerar en el anlisis tenemos: Fiabilidad, la cual viene determinada por los siguientes atributos: Simplicidad, simplicidad de los diseos, en la implementacin y en el desarrollo del
Jos Germn Nez Mori
Pgina 37 de 237
La Usabilidad en Metodologas giles Metodologas giles software en general.
Trazabilidad, entre los artefactos producidos en las distintas etapas del ciclo de vida del software. Usabilidad, esta parmetro viene determinado por los siguientes atributos: Claridad y precisin de la documentacin. Habilidades que mejoren las pruebas del software. Mantenibilidad, este parmetro viene determinado por los siguientes atributos: Modularidad, esto ayuda a crear una documentacin mas fcil de entender. Simplicidad, si la metodologa 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 continuacin una tabla (ver tabla 3 Comparativa de calidad en las metodologas giles), que informan, los criterios de calidad asociados a cada unas de las metodologas en estudio:
Metodologa Programacin Extrema (XP) Scrum Dynamic Systems Development Method (DSDM) Proceso Unificado gil (AUP) Agile Model Driven (AMDD) Feature Driven Development (FDD)
Fiabilidad Usabilidad Mantenibilidad Adaptabilidad X X X X X
X X X X
X X X X
X X X
Tabla 3: Comparativa de calidad en las metodologas giles
5.1.4 Herramientas
Con este criterio se busca dar a conocer las distintas herramientas que las metodologas en estudio requieren para cumplir cada unas de las tareas que especifica su enunciado. Para esto se enfatiz la bsqueda de herramientas de libre distribucin.
Jos Germn Nez Mori
Pgina 38 de 237
A continuacin, se presenta una tabla (ver tabla 4 Herramientas de libre distribucin para metodologas giles), donde se detalla alguna de las herramientas de libre distribucin, con las cuales se puede ejecutar cada una de las metodologas en estudio:
Metodologa
Herramientas
o o Programacin Extrema (XP) o o o o
Herramientas para la realizacin de refactorizacin, IDEs como Eclipse y NetBeans. Herramienta de integracin continua: Cruise Control. Herramientas de administracin de proyectos y compilaciones automticas: Maven y Ant. Repositorio de cdigos: CVS y Subversin. Herramientas para pruebas unitarias: JUnit. Herramientas para la medicin de rendimiento de aplicaciones : JMeter
Scrum
Agile Model Driven (AMDD)
A pesar de no ser necesaria ninguna herramienta especial, estn surgiendo aplicaciones Web que facilitan el seguimiento del proyecto y la generacin de los distintos artefactos de la metodologa, que frecuentemente se realizan con paquetes ofimticas. o Herramienta de diagramacin de modelos: Visual Paradigm, eclipse (con plugins respectivos) o Herramienta que te permite generar cdigo en base a diagramas: AndroMDA encapsulado con funcionalidad de MAVEN. Para esta metodologa son necesarias las herramientas mencionadas tanto para le metodologa XP como para AMDD, adems de estas herramientas se podra mencionar: o Herramientas de cobertura y evaluacin de complejidad ciclomtica: MAVEN.:
Proceso Unificado gil (AUP) Dynamic Systems Development Method No especifica ninguna prctica concreta que necesite de (DSDM) una herramienta especfica. Desarroollo rpido de o Herramientas que en base a prototipos genere aplicaciones (RAD) cdigo: IDEs como NetBeans y eclipse. o Herramientas de modelado como Visual Paradigm. o Herramientas ofimticas. Feature Driven o Herramientas de refactorizacin: IDEs como Development (FDD) eclipse y NetBeans.
Tabla 4: Herramientas de libre distribucin para metodologas giles.
Jos Germn Nez Mori
Pgina 39 de 237
5.2
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 metodologas 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 metodologa que contempla todas las etapas es la metodologa AUP, esto debido a que es una metodologa que se basa en RUP, pero a la vez esta metodologa 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 metodologas giles es activo y va ganando cada vez ms adeptos. Las metodologas giles estn orientadas a la productividad, es por este motivo que en la comparativa de calidad solo algunas de las metodologas cumple con la gran parte de los parmetros de calidad. Con relacin a las herramientas de distribucin libre, como se ha podido apreciar hoy en da existen muchas herramientas que ayudan ya en el proceso de las metodologas giles (ver Tabla 4).
5.3
Adopcin de metodologas
Los criterios de comparacin utilizados en esta seccin son solo algunos de los criterios por los cuales se puede llevar a cabo una comparativa entre metodologas giles y nos da una idea de cual es el enfoque de la metodologa en cuestin que nos permitir decidir por una de las metodologas presentadas.
La adopcin de una o varias metodologas, en vez de otras, tan solo tiene sentido si establecemos un caso lo suficientemente concreto, invalidando cualquier tipo de generalizacin y por ende una metodologa se hace necesaria para cada solucin.
En base a lo expuesto a lo largo de esta seccin, concluimos que las metodologas giles son un conjunto de prcticas y mtodos que surgen de la experiencia y el estudio de muchos proyectos software, de acuerdo a esto, la eleccin de una u otra metodologa ser en base a las necesidades que tenga un proyecto por ejemplo:
Si el proyecto necesita pautas claras de gestin, se debera seleccionar Scrum y AUP.
Jos Germn Nez Mori
Pgina 40 de 237
Si se ve que el proyecto presentar ratios de error elevados, se debe utilizar XP o AUP, debido a que ambas metodologas hace uso del Test Driven Development (TDD).
O quizs si es un proyecto interactivo con la funcionalidad visible en la interfase de usuario, se debera optar por DSDM.
Para el caso de estudio que se llevar a cabo, y tomando como premisa que es un caso concreto de investigacin, donde se busca adaptar en la metodologa o metodologas seleccionadas el principio de Usabilidad, se ha visto conveniente combinar tres de las metodologas, con el objetivo de dar una cobertura gil a un mbito ms amplio del ciclo de vida del software. Las metodologas seleccionadas son:
Scrum, para la parte de gestin del proyecto. XP, por ser una metodologa que cubre las actividades que desde el plano completo de la ISO 12207, perteneciente al desarrollo de software.
AUP, por ser una metodologa que contiene a XP y tiene las formalidades de RUP.
Jos Germn Nez Mori
Pgina 41 de 237
III. Marco gil de trabajo
Versin 1.2
La Usabilidad en Metodologas giles Marco gil de trabajo
Mayo 2010 Version 1.2

Fecha 10/11/2009 Version 1.0 Descripcin Marco gil de trabajo Autor Jos Germn Nez Mori 06/06/2010 1.1 Marco gil de trabajo Jos Germn Nez Mori 12/10/2010 1.2 Marco gil de trabajo Jos Germn Nez Mori
Jos Germn Nez Mori
Pgina 43 de 237
1. Introduccin
De acuerdo a lo expuesto en el captulo de Metodologas giles, se llego a la conclusin, de seleccionar tres de las metodologas giles planteadas a lo largo del captulo. Esta seleccin, se realiza despus de analizar que las metodologas giles son prcticas focalizadas sobre un rea de conocimiento, ms o menos delimitada, de la Ingeniera del Software [JPAL02].
Con las metodologas giles seleccionadas, se busca combinar varias de las prcticas de cada una de estas metodologas, para dar una mayor cobertura gil a un mbito ms amplio del ciclo de vida del software [JPAL02].
En el presente captulo, se planteara un marco gil de trabajo, que contenga ciertas prcticas y actividades de cada unas de las metodologa 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 captulos, y en los cuales se pueda aadir los principios de Usabilidad.
2. Planteamiento metodolgico
En la presente seccin, se dar a conocer el planteamiento de este marco de trabajo gil, que busca combinar, practicas y actividades, de cada una la metodologas seleccionadas, que en conjunto, se adapten a los requerimientos o necesidades del presente trabajo.
Las metodologas seleccionadas, como ya se ha descrito en el capitulo anterior (Metodologas giles) son: SCRUM, AUP y XP. De estas metodologas se ha analizado, tanto sus principios bsicos como su planteamiento metodolgico, donde en base a este anlisis, se ha llegado a la conclusin, de utilizar ciertas actividades y prcticas de cada una de estas metodologas y as obtener un marco gil que se ajuste a lo requerido.
Las actividades y prcticas seleccionadas, tanto de las metodologas Scrum como AUP, formarn la carrocera del marco gil de trabajo. Esto debido, al enfoque que tienen estas metodologas, consiguiendo de esta manera, los lineamientos para la gestin (plateada por Scrum) y las formalidades del Proceso Unificado (planteada por AUP) en la ejecucin del ciclo de vida del software, con lo cual, se dejar a la metodologa XP enfocada directamente en el plano de desarrollo.
La metodologa AUP, sugiere optar por un conjunto pequeo de actividades y artefactos del Jos Germn Nez Mori Pgina 44 de 237
Proceso Unificado [CRLA02] [JOKR05]. Siguiendo esta idea, se ha optado por utilizar ciertas fases y actividades que plantea AUP, las cuales sern gestionadas por los lineamientos de SCRUM. Consiguiendo de esta manera tambin incluir prcticas 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 trasmitindose a las etapas siguientes como son diseo e implementacin.
3. Estructura Metodolgica
En la presente seccin, se describir cual es la estructura que tendr el marco gil de trabajo y en base al cual, se desarrollarn los siguientes captulos.
El marco gil de trabajo, se basar en el ciclo de vida del software plateando por AUP, a la cual se le aadir actividades y prcticas, tanto de la metodologa 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 clsico planteado por el Proceso Unificado. Sin embargo, este modelo es mas simple, debido a que rene, en una nica disciplina como es la de Modelo: el modelado de negocio, requisitos y anlisis y Diseo. El resto de disciplinas como se pude apreciar coinciden con las planteadas por el Proceso Unificado
Jos Germn Nez Mori
Pgina 45 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo [KINT07].
El marco gil de trabajo, tal cual se describe en lneas anteriores, seguir la estructura planteada por AUP, con la salvedad, de solo incluir ciertas disciplinas, como son: Modelo, Implementacin, Prueba, Despliegue y gestin 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 ms 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. Adems 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 adems, 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 duracin fija, llamado iteraciones. Donde el resultado de cada iteracin 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 elaboracin no es la fase de requisitos o de diseo, si no que es una fase donde se implementa de manera iterativa la arquitectura que constituye el ncleo central donde se mitigan las cuestiones de alto riesgo y en la fase de construccin se implementan de manera iterativa el resto de requisitos de
Jos Germn Nez Mori
Pgina 46 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo menor riesgo y se prepara para el despliegue [SABL06] [CRLA02].
De acuerdo a esta estructura, a lo largo de esta seccin 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 ayudarn a cumplir este objetivo.
3.1 Fases del marco gil de trabajo

En esta seccin 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).
3.1.1 Inicio (Inception)

Para esta fase de inicio el marco gil de trabajo, plantea lo siguiente: Obtencin de los requisitos funcionales y no funcionales de alto nivel, siguiendo el planteamiento XP y tomando en cuenta los principios de usabilidad. Proceso de aceptacin de los principios de usabilidad incluidos, considerando el planteamiento AUP. Gestin 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 Aceptacin 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 Germn Nez Mori
Pgina 47 de 237
Figura 7: Hito de la fase de Inicio.
3.1.2 Historias de Usuarios

Los requisitos tanto funcionales como no funcionales, sern obtenidos en base a lo sugerido por la metodologa 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 Nombre: Descripcin : <<Descripcin abreviada>> Prioridad:
Usuario de Creacin Estimacin.
Fecha Alta: Dependencia:
Figura 8: Formato de Historias de usuarios segn 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 Germn Nez Mori
Pgina 48 de 237

Historia de Usuario N Nombre: Descripcin : <<Descripcin abreviada>> Prioridad:
Usuario de Creacin Estimacin.
Fecha Alta: Dependencia: Requisitos de Usabibilidad Asociados Apicacin Comentarios
Requisito System Status Feedback Interaction feddback Progress feedback Warning Globall Undo Object Specific undo
Figura 9: Formato de Historias de usuarios segn el marco gil. Como se puede apreciar en la figura 9, el marco gil de trabajo, adiciona al formato de historias de usuario una seccin para recoger los requisitos de usabilidad relacionados a una historia en particular. Es por este motivo, que en la seccin de requisitos de usabilidad, se listarn todos los requisitos contemplados, dando as la opcin 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 electrnico, el cual debe entregarse al usuario para ser rellenado con la informacin 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 tambin por los encargados de la elicitacin de requisitos.
3.1.3 Pruebas de Aceptacin

Como un artefacto de salida de esta fase inicial, se debe contemplar procesos de aceptacin, que garanticen la calidad del producto final. De acuerdo a esto, la metodologa AUP, plantea una serie de procesos de aceptacin, 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 aceptacin seleccionado es el llamado pruebas de aceptacin, que son bsicamente pruebas funcionales sobre el sistema completo y que buscan una cobertura de la especificacin de requisitos. En nuestro caso de estudio, estas pruebas de aceptacin buscarn la
Jos Germn Nez Mori
Pgina 49 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo cobertura de la especificacin de los requisitos de usabilidad elicitados.
En esta fase de Inicio, las pruebas de aceptacin, segn el marco gil de trabajo, consistirn en la redaccin de pruebas mnimas para la validacin de los requisitos de usabilidad, las cuales se basarn estrictamente en las historias de usuarios asociados. De acuerdo a esto, el proceso de aceptacin tendr el siguiente formato, mostrado en la figura 10:
Id
Historia
Criterio de validacin de los Requisitos de Usabilidad
Figura 10: Formato de Pruebas de Aceptacin. Para este formato (ver figura 10) de pruebas de aceptacin, el marco gil, sugiere se plasme en un documento electrnico y se rellene por cada historia de usuario las pruebas mnimas que garanticen el funcionamiento esperado de los requisitos de usabilidad asociados. Siendo este documento redactado por los encargado del anlisis 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.
3.1.4 Product Backlog

Cada historia registrada por los usuarios, ser gestionada para su resolucin, por medio del Product Backlog, que es el inventario de funcionalidades, mejoras, tecnologas y correccin 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 metodologa 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. Adems a este artefacto tendrn acceso todos los integrantes del equipo. Por lo tanto, el Product Backlog seguir el siguiente formato [JPAL02]: Jos Germn Nez Mori Pgina 50 de 237
Id. Historia
Descripcin
Prioridad
Estimacin
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 ms gil tener una visin global de todas las funcionalidades del producto.
El marco gil de trabajo, sugiere que este formato sea plasmado en un documento electrnico 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.
3.1.5 Elaboracin
En esta fase el marco gil de trabajo, basar su enfoque en lo que plantea la metodologa AUP (Agile Unified Process), tomando en cuenta as las disciplinas y prcticas sugeridas.
El objetivo principal de la fase de elaboracin 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 sealar que los requisitos no se especifican por completo en este punto. Se detallan slo 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 planificacin a llevarse a cabo y de identificar y priorizar los riesgos de la arquitectura, donde, los mas significativos sern tratados en esta fase de elaboracin [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 elaboracin, sugiere que, para esta ltima, se inicie con el diseo, especficamente como se describe en lneas anteriores, Jos Germn Nez Mori Pgina 51 de 237
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: Identificacin de la arquitectura, basada en la metodologa MDA. Realizar el plan de ejecucin de las primeras iteraciones de construccin.
De acuerdo a estos puntos la fase de elaboracin 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 ejecucin de la primera iteracin de construccin.
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 Elaboracin Como paso siguiente de esta seccin, 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 elaboracin.
3.1.6 Prototipo de la arquitectura del sistema

Cuando el marco gil de trabajo, emplea el trmino de prototipo de arquitectura, hace referencia a que en esta fase de elaboracin, se debe obtener un primer modelo de la arquitectura del sistema, donde se rena las partes, las conexiones y las normas de interaccin entre los Jos Germn Nez Mori Pgina 52 de 237
componentes de este sistema, haciendo uso de conexiones especificas y sobre los que se basarn las posteriores modificaciones en implementaciones a realizar.
En base a esta premisa, el marco gil de trabajo, basado en las distintas metodologas de su planteamiento, buscar un enfoque de metodologa, 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 metodologa que ayudar en las tareas de modelado de la arquitectura. Esta metodologa 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 metodologa AMDD, se puede revisar el capitulo de Metodologas 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, especficamente utilizando el estndar sugerido por esta metodloga, siendo este, el estndar MDA (Model Driven Architecture).
MDA es un estndar, que potencia el uso de modelos en el desarrollo, debido a que usa los modelos para dirigir el mbito de desarrollo, el de diseo, el de despliegue, el de la operacin, el de mantenimiento y el de la modificacin de los sistemas.
En el marco gil de trabajo, MDA pretende ser utilizado para dirigir tanto el mbito desarrollo como el de diseo. Bajo este estndar el marco gil, en esta fase de elaboracin, tendr como objetivo realizar una primera iteracin que permita obtener una parte del sistema que pueda ser probada, integrada y ejecutada.
Esta primera iteracin, contemplar la ejecucin del prototipo de arquitectura, que consistir en obtener tanto el diseo de este prototipo como el desarrollo del mismo. De esta manera se cumplir con el objetivo de esta fase, que es la implementacin de la arquitectura que constituye el ncleo central donde se mitigan las cuestiones de alto riesgo y cuyo propsito ser ayudado por el estndar 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 Germn Nez Mori Pgina 53 de 237
A continuacin, se detallara la especificacin del estndar MDA, buscando as entender, el desarrollo dirigido por modelos y cmo se har uso del mismo para lograr obtener uno de los hitos de esta fase (Prototipo de la Arquitectura)
3.1.7 Estndar MDA (Model Driven Architecture)

En esta seccin se detallar la especificacin del estndar MDA, basado en la siguientes referencias: [LECCO09], [MDAWI10], [OMGWB10]. La arquitectura dirigida por modelos (Model Driven Arquitectura) es una especificacin detallada por el OMG (Object Management Group) que integra diferentes especificaciones y estndares definidos por la misma organizacin, con la finalidad de ofrecer una solucin a los problemas relacionados con los cambios en los modelos de negocio, la tecnologa y la adaptacin de los sistemas de informacin a los mismos. MDA nos permite el despliegue de aplicaciones empresariales, diseadas sin dependencias de la plataforma de despliegue y expresando su diseo mediante el uso de UML y otros estndares. Donde estos estndares, pueden ejecutarse en cualquier plataforma existente, abierta o propietaria, como servicios web, .Net, Corba, J2EE, u otras.
La especificacin de las aplicaciones y la funcionalidad de las mismas se expresan en un modelo independiente de la plataforma que permite una abstraccin de las caractersticas tcnicas especficas de las plataformas de despliegue. Mediante transformaciones y trazas aplicadas sobre el modelo independiente de la plataforma se consigue la generacin automtica de cdigo especfico para la plataforma de despliegue elegida.
Todo esto proporciona finalmente una independencia entre la capa de negocio, y la tecnologa empleada. De esta manera es mucho ms simple la incorporacin 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 diseo los patrones de usabilidad.
Siguiendo este planteamiento, se desarrollan los cambios en el modelo independiente de la plataforma, y stos se propagarn a la aplicacin, consiguiendo por tanto, una considerable reduccin del esfuerzo en el equipo de desarrollo. De esta manera tambin, se disminuye los errores que tienden a producirse en los cambios introducidos en las aplicaciones mediante otros Jos Germn Nez Mori Pgina 54 de 237
mtodos de desarrollo, y por consiguiente, la reduccin de costes y aumento de productividad.
MDA se apoya sobre los siguientes estndares para llevar a cabo su funcin: UML (Unified Modeling Language): empleado para la definicin de los modelos independientes de la plataforma y los modelos especficos de las plataformas de destino. Es un estndar para el modelado introducido por el OMG. MOF (MetaObjet Facility): establece un marco comn 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 automticamente por otras aplicaciones. CWM (Common Warehouse Metamodel): define la transformacin de los modelos de datos en el modelo de negocio a los esquemas de base de datos [OMGWB10].
El estndar MDA, establece tres puntos de vista que se emplearn a lo largo de su proceso de ingeniera: Punto de vista independiente de la computacin, 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 an no estn 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 especificacin del sistema que no cambian de una plataforma a otra. En este punto de vista debe emplearse lenguaje de modelado de propsito general, o bien algn lenguaje especfico del rea en que se emplear el sistema, pero en ningn caso se emplearn lenguajes especficos de plataformas. Punto de vista de plataforma especfica: combina el punto de vista independiente de la plataforma con un enfoque especfico para su uso en una plataforma especfica 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 computacin (CIM), es una vista del un sistema desde el punto de vista independiente de la computacin. 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 especificacin. Modelo independiente de la plataforma (PIM), es una vista del sistema del punto de vista independiente de la plataforma, exponiendo as un carcter independiente de la plataforma Jos Germn Nez Mori Pgina 55 de 237
sobre la que se desplegar. Con esto se logra un modelo que puede ser empleado en diferentes plataformas de carcter similar. Modelo especfico de la plataforma (PSM), es una vista del sistema (producto final) desde el punto de vista especfico de la plataforma, combinando as el modelo independiente de la plataforma con los detalles especficos de la plataforma del sistema.
3.1.7.1.1.1 Usando MDA

Expuestos los conceptos bsicos de MDA, a continuacin, 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 computacin), con el que se modelan los requisitos del sistema, describiendo la situacin 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 dems modelos.
Los requisitos recogidos en el CIM (Modelo independiente de la computacin) 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 distribucin de los procesos (ODP, Open Distributed Processing) como la informacin a tratar. Tambin puede contener algunos modelos UML ms que especifiquen en mayor detalle los anteriores.
A partir del CIM, se construye un PIM, que muestra una descripcin del sistema, sin hacer referencia a ningn detalle de la plataforma. Debe presentar especificaciones desde el punto de vista de la empresa, informacin y ODP. Un PIM se puede ajustar a un determinado estilo de arquitectura, o a varios.
Despus de la elaboracin 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 Germn Nez Mori
Pgina 56 de 237
Figura 13: Trazabilidad de Modelos MDA
3.1.7.1.1.2 Mapas de Transformacin MDA

Mediante mapas, MDA especifica las reglas de transformacin de un PIM (Modelo independiente de la plataforma) a un PSM (Modelo especfico de la plataforma) para una plataforma en concreto. Estos mapas incluyen la transformacin de tipos de valores, as como los metamodelos y sus reglas para la transformacin en tipos de valores existentes en las plataformas especficas.
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 especificacin de transformacin entre el metamodelo independiente de la plataforma y el metamodelo que describe la plataforma. La figura 14, ilustra este requisito:
Jos Germn Nez Mori
Pgina 57 de 237
Figura 14: Transformacin de metamodelos bajo MDA. Una forma de facilitar la transformacin de modelos es la identificacin 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 transformacin, y su situacin intermedia entre la independencia y la dependencia de la plataforma. Una vez es elegida la plataforma, existe un mapa para la transformacin de modelos. Este mapa incluye un conjunto de marcas, que usamos para marcar los elementos del PIM como gua para la transformacin del Jos Germn Nez Mori Pgina 58 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo modelo.
Las marcas pueden definir tipos del modelo, especificacin de clases, asociaciones, roles, estereotipos, etc. Las marcas tambin pueden especificar caractersticas cualitativas que despus en la transformacin se convertir en el objetivo apropiado para el cumplimiento de los requisitos.
Los mapas de transformacin pueden mantener tambin 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 informacin relativa a patrones que extienda las caractersticas y tipos de los metamodelos y el lenguaje de la plataforma especfica elegida para el despliegue. Como muestra la figura 16, el uso de informacin adicional para la transformacin implica la necesidad de informacin de los patrones para la transformacin, que sern especficos para la plataforma de destino.
Figura 16: Patrones de transformacin en los modelos MDA
3.1.7.1.1.3 Transformaciones de modelos MDA

El siguiente paso al establecimiento de las marcas en los modelos y la seleccin de mapas de transformacin es aplicar la transformacin 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 automtico.
Jos Germn Nez Mori
Pgina 59 de 237
La transformacin, es el proceso que toma como entrada el PIM marcado y da como resultado el PSM del sistema y el registro de transformacin.
Algunas herramientas, pueden hacer una transformacin del PIM directamente a cdigo desplegable en la plataforma de destino o incluso, conceptos como MDR (Model-Driven Runtime Environment), que propone el uso de un entorno de ejecucin para los PIM, directamente, sin generacin de PSM ni cdigo para la plataforma. En cualquier caso el OMG sostiene que la transformacin debe emitir un PSM para ayudar al entendimiento del cdigo y la depuracin del mismo.
El registro de transformacin incluye una traza desde cada elemento del PIM a los elementos correspondientes en el PSM, especificando que parte de los mapas de transformacin fueron empleados para derivar los elementos del PSM desde los elementos del PIM. Una herramienta que mantenga los registros de transformacin debe ser capaz de sincronizar de forma automtica los cambios producidos en un modelo al otro.
El PSM producido por una transformacin es un modelo del mismo sistema que ha sido especificado en el PIM. Tambin especifica como el sistema hace uso de una determinada plataforma.
Un PSM, ser una implementacin del sistema si proporciona toda la informacin necesaria para construir el sistema y ponerlo en marcha.
Una vez descrita y explicada la estrategia del estndar MDA, el marco de gil de trabajo, siguiendo lo descrito por este estndar, sugiere que todo este mecanismo de planteamiento MDA, sea dirigido de manera automtica y asistida por algn Framework (marco de trabajo), que permita contemplar gran parte de este especificacin y cuya curva de aprendizaje sea minima para los desarrolladores.
El Framework que se ajusta a las necesidades del presente trabajo, al planteamiento del estndar 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 estndar MDA y a su vez ayuden al marco gil de trabajo a cumplir con el hito de esta fase de elaboracin.
Jos Germn Nez Mori
Pgina 60 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo 3.1.7.1.2 AndroMDA
En esta seccin se detallar en que consiste este Framework y de cmo ser utilizado por el marco gil de trabajo, detallando as, las distintas utilidades de este Framework y de cmo estas ayudarn a cumplir con el objetivo de este trabajo. La explicacin de esta seccin se ha basado en la siguiente referencia: [AMDA10].
Esta herramienta, es un marco de generacin extensible que se adhiere al paradigma MDA y que toma cualquier nmero de modelos (usualmente modelos UML guardados en formato XMI producidos por alguna herramienta case), que en combinacin con plugins de la propia herramienta (Plantillas y bibliotecas de traduccin), produce componentes personalizados, es decir, se puede generar componentes en un gran nmero de lenguajes entre los que se encuentra: Java, .Net, HTML, PHP, etc.
El cdigo generado por AndroMDA, es automticamente integrado al proceso de construccin, siendo esta generacin muy eficiente para la aplicacin 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 lgica 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, especficamente bajo J2EE. Segn esto, el marco gil de trabajo, a lo largo de esta seccin ira detallando la manera de configurar un proyecto J2EE utilizando AndroMDA.
3.1.7.1.2.1 MDA en la generacin de cdigo de AndroMDA

En el sentido clsico de la Ingeniera de Software, uno de los primeros elementos es determinar qu es lo que el sistema tiene que hacer (fase de anlisis). En esta fase el arquitecto o desarrollador tiene algo en la mente que ser traducido hacia un documento especfico (modelo o texto). Luego, necesitar implementar ese entregable, para lo cual requerir una persona o un grupo de personas que implementen esa transformacin en un lenguaje como C, JAVA, C++, etc.
Con el estndar MDA, lo que se intenta es simplificar el trabajo del desarrollador/arquitecto, a travs de la digitalizacin de ideas que l/ella tengan en mente (Mental Model MM o CIM). Por esta razn, 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 Germn Nez Mori Pgina 61 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo enfoque tiene muchas ventajas algunas de ellas se listan a continuacin: Es un proceso de transformacin muy sencillo y directo El desarrollador/arquitecto mantiene el enfoque en la lgica 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 prximo paso es encontrar la manera para transformar el PIM hacia el cdigo. 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 cdigo escrito manualmente
Este es el punto en el cual AndroMDA acta, pues posee diferentes cartuchos o Cartridges (plugins), que analizaran el PIM dado y construirn el PSM. Luego, de construido ste se usaran plantillas para producir el cdigo, donde, el cdigo 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 generacin de cdigo Como se puede apreciar en la figura 17, una vez interpretado el modelo UML, para generar el cdigo 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, numeracin, 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 generacin de cdigo de un lenguaje o tecnologa determinada.
Jos Germn Nez Mori
Pgina 62 de 237
Estos Cartridges o cartuchos, son importantes en el proceso de transformacin de cdigo 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.
3.1.7.1.2.2 Arquitectura del marco gil de trabajo segn AndroMDA

Segn se describe en lneas anteriores, el proyecto se pretende realizar bajo la plataforma J2EE, siguiendo as una arquitectura de N niveles o capas distribuidas, basndose ampliamente en componentes de software modulares y que sern ejecutados en un servidor de aplicaciones. Bajo esta premisa, el marco gil de trabajo se basara en la siguiente estructura:
Figura 18: Arquitectura de Aplicacin base del marco gil de trabajo Como se puede apreciar en la figura 18, se presenta una estructura de capas populares de una aplicacin empresarial, donde se cuenta con los siguientes niveles:
Capa de presentacin (Presentation layer), que contiene los elementos necesarios para interactuar con el usuario de la aplicacin
Capa de negocio (Business layer), encapsula la funcionalidad del negocio principal de la aplicacin, 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 Pgina 63 de 237
Jos Germn Nez Mori
a los datos subyacentes de la aplicacin, abstrayendo de esta manera la semntica de la tecnologa de acceso a estos y permitiendo de esta manera que la capa de negocio se centre en la lgica del sistema. Almacn 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 aplicacin Java, esto debido a que este Framework, tiene la capacidad de traducir de manera automtica especificaciones de alto nivel empresarial, en cdigo de calidad ahorrando as un tiempo significativo para el desarrollo de aplicaciones.
A continuacin, se presenta la estructura de aplicacin empresarial que plantea AndroMDA y cada una de las tecnologas que soporta la misma en cada uno de los niveles o capas contempladas:
Figura 19: Estructura de Aplicacin empresarial AndroMDA Jos Germn Nez Mori Pgina 64 de 237
Como se pude apreciar en la figura 19, por cada nivel que presenta la arquitectura se muestran las tecnologas Java soportadas por este Framework. A continuacin se describe la seleccin de las tecnologas por capa que ha optado utilizar el marco gil de trabajo, en base a la estructura presentada por AndroMDA: Capa de presentacin (Presentation layer), se ha optado por utilizar la tecnologa Struts, que ayudara a generar componentes Web. Capa de negocio (Business layer), en esta capa se utilizar una tecnologa 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 tecnologa de mapeo relacional de objetos llamada Hibernate. Almacn de datos (Data Store), se puede utilizar cualquiera base de datos, para este trabajo se utilizar la base de datos Hypersonic.
3.1.7.1.2.3 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 metodologa (AMDD), el estndar (MDA) como el Framework (AndroMDA), que ayudarn en conjunto, en base a sus planteamientos al marco gil de trabajo, a conseguir este hito de salida de la fase de elaboracin.
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 diseo de modelos para conseguir los componentes necesarios de una funcionalidad determinada.
Ya en esta seccin, es donde, se detallar cada uno de los tipos de modelos y sus componentes, que AndroMDA sugiere utilizar para el diseo y que permitirn obtener los recursos necesarios, para el prototipo de arquitectura.
Siguiendo la estructura de aplicacin de AndroMDA (ver figura 15 - Estructura de Aplicacin empresarial AndroMDA), se explicar por cada nivel de esta estructura, los modelos implicados que permitan, obtener la codificacin bsica de los componentes de este prototipo de arquitectura.
Jos Germn Nez Mori
Pgina 65 de 237
La Usabilidad en Metodologas giles Marco gil de trabajo Modelado en la capa de presentacin:
Este nivel como se comenta en secciones anteriores permite la interaccin con el usuario, es por esta razn 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 presentacin, 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 diseo de una determinada funcionalidad en la capa de presentacin, 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 interaccin del usuario con el sistema, ser llevada por medio de pginas JSP (basadas en tecnologa Struts). El diseo mostrado en la figura 20, representa las transiciones (flechas) y estados (cajas) que tendr una pgina JSP, para procesar una determinada peticin de usuario y su respectiva respuesta. Jos Germn Nez Mori Pgina 66 de 237
Para poder indicar, en un diagrama de actividad AndroMDA, que un de estos estados representar una pgina JSP, se deber marcar por medio del estereotipo <<FrontEndView>>, de no ser as, representarn estados que sern procesados por el sistema, en esta caso y siguiendo la tecnologa Struts, deber ser procesado por una clase controladora.
Para modelar las clases controladoras asociados a las pginas 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 diseo de una clase controladora:
Figura 21: Componente controlador en AndroMDA Los diagramas de actividad, como sus respectivos controladores, representarn 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 funcin de diagramas de casos de uso (ver figura 22).
Figura 22: Casos de Uso AndroMDA Cada caso de uso diseado (ver figura 22), tendr que relacionarse con un diagrama de actividad y estos a su vez a una clase controladora respectiva, que en conjunto representarn, la operativa necesaria para atender las peticiones de los usuarios, asociadas a una funcionalidad determinada.
Modelado en la capa de Negocio: Pgina 67 de 237
Jos Germn Nez Mori
En este nivel, como se ha ido detallando en secciones anteriores, se pretende modelar el ncleo de una aplicacin. 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, representarn fachadas que ocultan la lgica de negocio que se pretende plasmar a este nivel, permitiendo as de esta manera menos acoplamiento tanto con la capa de presentacin, como con la capa de Datos. La figura 23 muestra este diseo:
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 codificacin 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 tecnologa usada en este nivel (Hibernate). La figura 24 muestra este diseo:
Figura 24: Modelado de entidades de datos en AndroMDA
Jos Germn Nez Mori
Pgina 68 de 237
En la figura 24, se presenta el diseo de un diagrama de entidad relacin, 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 recuperacin de datos.
Una vez mostrado todos los componentes a modelar en cada una de las capas, nos preguntamos, como se representa la interaccin 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
3.1.7.1.2.4 Herramientas y tecnologas en el ciclo de generacin AndroMDA

En esta seccin detallamos cada una las herramientas y versiones de las tecnologas, que utilizar el marco gil de trabajo, en el ciclo de generacin AndroMDA:
Para el modelado se utilizar la herramienta MagicDraw UML 9.5, que permitir plasmar los diseos en formato XMI [MGDU10].
Para transformar los modeles en formato XMI, hacia cdigo, se utilizar la herramienta Apache Maven en su versin 2.2.1 [AMVN10]
La herramienta Apache Maven en conjunto con las libreras de AndroMDA, interpretarn el modelo y generarn los componentes necesarios a implementar. La versin de AndroMDA a utilizar es la 3.2 [AMDA10].
Se utilizar el Framework Apache Struts en su versin 1.2.7 [ASTS10]. El Framework Spring en su versin 1.2.7 [SPIG10]. El Framework Hibernate en su versin 3.1.3 [HBNT10].
En base a todos estos modelos, tecnologas y herramientas que se ha ido detallando a lo largo de Jos Germn Nez Mori Pgina 69 de 237
este apartado, se obtendr el prototipo de arquitectura tanto a nivel de modelado como de implementacin. Adems cabe recalcar, que bajo este enfoque de modelado es que se pretende incluir cada uno los patrones de diseo relacionados con la Usabilidad.
3.1.7.2 Plan de ejecucin de la primera iteracin de construccin

Scrum, es una de las metodologas de gestin en la que se basa el marco gil de trabajo. As, en esta seccin se detallar la manera en que Scrum, plantea desagregar una funcionalidad especifica en diferente tareas, que en conjunto formen una iteracin.
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. Adems 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 informacin del tiempo que falta para terminarla.
Este enfoque, es til porque permite descomponer el proyecto en tareas de tamao adecuado para determinar el avance diario e identificar riesgos y problemas sin necesidad de procesos complejos de gestin [JPAL02]. Adems tomar en cuenta que en Scrum un Sprint es equivalente a una iteracin 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 tamao 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 fsico 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 fsica. Pgina 70 de 237
Jos Germn Nez Mori
La Usabilidad en Metodologas giles Marco gil de trabajo Herramienta colaborativa o de gestin 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 gestin 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 continuacin se describir brevemente, algunos detalles importantes para el uso de esta herramienta, que permitan en el momento de la ejecucin de la fase, el uso adecuado de la misma [SPTOUG08]. En las figuras 26, 27 y 28, se muestran detalles de esta herramienta:
Figura 26: Herramienta de gestin Sprintometer
Jos Germn Nez Mori
Pgina 71 de 237

a b c
Figura 27: Seccin de registro de Sprint en Sprintometer
Figura 28. Seccin de control de avance de tareas en el Sprint bajo Sprintometer De acuerdo a la figura 26 [SPTOUG08]: tem 1 Comentarios En esta seccin 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 seccin 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 seccin, 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 Germn Nez Mori Pgina 72 de 237
De acuerdo a lo planteado en esta seccin, en base a la herramienta Sprintometer, se deber de realizar la planificacin de la primera iteracin (Sprint), que contemple las tareas necesarias para llevar a cabo el prototipo de arquitectura.
Esta forma de gestionar el proyecto deber de ser aplicada tambin en futuras iteraciones, es decir, que se deber de seguir esta estructura de planificacin para las iteraciones de la fase de desarrollo.
3.1.8 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 seguirn la misma estructura planteada en la primera iteracin de desarrollo de la fase de elaboracin, 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 elaboracin para la implementacin de cada una de las funcionalidades del sistema.
Jos Germn Nez Mori
Pgina 73 de 237
IV. Fase de Inicio del Marco gil de Trabajo
Versin 1.1
La Usabilidad en Metodologas giles Fase de inicio del marco gil de trabajo

FECHA 13/06/2010 VERSION 1.0 DESCRIPCIN Fase de Inicio del marco gil de trabajo. 120/10/2010 1.1 Fase de Inicio del marco gil de trabajo. Jos Germn Nez Mori AUTOR Jos Germn Nez Mori
Jos Germn Nez Mori
Page 75 of 237
Fase de Inicio del marco gil de trabajo

1. Introduccin
El marco gil de trabajo, plantea ciertas fases que comprenden la estructura de su metodologa. En este captulo, se abordar el desarrollo de la primera de sus fases, que hace referencia a la fase inicial de este marco de trabajo.
La metodologa AUP (Agile Unified Process), que es una de las metodologas referentes del presente trabajo, plantea una serie de actividades a realizar en la fase de inicio, como por ejemplo: definicin de riesgos del proyecto, estimacin 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 metodologa AUP, las cuales son: Definicin del alcance y la planificacin del proyecto.
Esta primera fase, tal cual se describe en el capitulo anterior, es una fase de inicio de la metodologa 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 lmites dentro de los cuales el equipo de desarrollo ira a operar, es decir, se determinar el alcance del proyecto [SABL06].
En cuanto a la planificacin del proyecto, el marco gil de trabajo, plantea la gestin de las funcionalidades del sistema en base a lo descrito en la metodologa Scrum, que es bsicamente, un inventario de caractersticas que el propietario del producto desea obtener. Donde, por ser una metodologa 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 anlisis 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 Germn Nez Mori
Page 76 of 237
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 gestin de las personas aseguradas y sus vnculos referentes.
De acuerdo a estas premisas, el presente trabajo, opta por ejecutar su planteamiento, sobre las funcionalidades mnimas referentes a la gestin de personas aseguradas. Es as, que estas funcionalidades sern 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 seccin se desarrollar cada uno de los artefactos necesarios para cumplir con el hito de esta primera fase.
2.1 Product Backlog

A continuacin, se detalla cada unas las funcionalidades, seleccionadas de la gestin 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 PER001 PER002 PER003 PER005
Descripcin Relacionar Personas Gestionar Fusin de Personas Buscar Personas Fusionadas Gestionar Situacin Familiar de la Persona (alta)
Prioridad Estimacin 10 9 9 8
Observaciones
Responsable JGNuez JGNuez JGNuez
PER004
Recuperar Datos Entidad Finaciera
JGNuez Esta funcionalidad deber de empezar a desarrollarse una vez publicado los servicios de la JGNuez Entidaed Financiera
Tabla 6: Product backlog
2.2 Historias de usuarios

En esta seccin, se desarrolla, la elicitacin de cada una de las funcionalidades antes descritas (ver tabla 6), siguiendo, el formato de historias de usuario.
Jos Germn Nez Mori
Page 77 of 237

Historia de Usuario N Nombre: Descripcin: : PER0001
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 parmetros de entrada, tanto el cdigo 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, cdigo de la persona, tipo de persona, sin identificacin, fiscalmente aplicable. Una vez ubicada la persona, se dar de alta en la relacin y se adicionar a las relaciones existentes de la persona gestionada.
Usuario de Creacin: Estimacin:
Jos Nez Mori
Fecha Alta: 01/04/2010 Dependencia:
Requisitos de Usabibilidad Asociados

Requisito Aplicacin Comentarios
System Status Feedback
Si el alta de la relacin, no se realiza correctamente, se mostrar el siguiente mensaje en formato de error: "La operacin no se ha realizado con xito, debido a ..." Tras el evento de adicin de una nueva relacin, esta se aadirn al final de la tabla de relaciones de la persona gestionada y se remarcarn con un color apropiado.
Interaction Feedback Progress feedback
Jos Germn Nez Mori
Page 78 of 237

Progress feedback
Warning
Tras el evento de confirmacin de las nuevas relaciones asociadas a la persona gestionada, el sistema presentar el siguiente mensaje en formato de confirmacin.: "Se va a guradar los cambios en las relaciones de la persona gestionada, Esta seguro de re Esta funcionalidad debe permitir la opcin de deshacer, lo cual consitir, en eliminar las diez ltimas relaciones dadas de alta con esta operacin. Adems se presentar estas diez ltimas relaciones en formato de lista.
Global Undo
Object Specific Undo Esta funcionalidad presentar la opcin de cancelar, que ser a nivel de operacin, y que permitir abortar, ya sea la bsqueda o la adicin de relaciones en curso. Retonando el control a la funcioanlidad previa o al home de la aplicacin.
Para los campos del criterio de bsqueda se tendr en cuenta lo siguiente: Tipo Vnculo, lista desplegable (obligatorio) Vinculo, lista desplegable. (obligatorio) Cdigo de la persona alfanumrico de 6 caracteres (obligatorio). Sin identificacin, campo de verificacin. Fiscalmente aplicable, campo de verificacin.
Abort Operation Go back
El sistema validar el formato de los campos del criterio de bsqueda y presentar los siguientes mensajes en formato de notificacin ante el incumplimiento de los mismos: Si existen campos del criterio de bsqueda 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.
Structured Text Entry, Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation
Tabla 7: Historia de usuario Relacionar personas
Jos Germn Nez Mori
Page 79 of 237

His toria de Us uario N Nombre : : PER0002
Prioridad: Gestionar Fusin de Personas De s cripcin: Esta funcionalidad permitir la fusin o no fusin de personas candidatas a fusionarse, donde la persona principal de la fusin, tendr la referencia a los contratos, direcciones de correo electrnico del grupo de personas fusionadas y ser la persona visible ante cualquier bsqueda 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 fusin. Una vez hecho esta seleccin, se debe mostrar un listado con la persona seleccionada anteriormente y las personas candidatas a la fusin, esta lista debe tener la siguiente informacin:
Principal (Columna de seleccin) Fusionar (Columna de seleccin) No Fusionar (Columna de seleccin) Cdigo de Persona Tipo de Identificacin Nmero de Identificacin Nombre (Concatenacin del primer y segundo nombre). Slo en caso de personas fsicas. Apellido. Slo en caso de personas fsicas. Fecha Nacimiento. Slo en caso de personas fsicas. Sexo. Slo en caso de personas fsicas. Razn social. Slo en caso de personas jurdicas
De este listado, el usuario selecciona las personas a fusionar o no fusionar, adems esta funcionalidad debe permitir adicionalmente, adicionar al listado de candidatos a fusionar, cualquier persona del sistema (fusin manual)
Us uario de Cre acin: Es timacin:
Jos Nez Mori
Fe cha Alta: 01/04/2010 De pe nde ncia:
Re quis itos de Us abibilidad As ociados

Requisito A plicacin Com entarios
System Status Feedback Interaction Feedback
Si el alta de una fusin, no se realiza correctamente, se mostrar el siguiente mensaje en formato de error: "La operacin 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 operacin. Tras el evento de guardado de la fusin asociada a la persona principal, el sistema mostrar el siguiente mensaje en formato de confirmacin: "Se va a gurdar la fusin en curso, Esta seguro de realizar esta operacin?"
Progress feedback
W arning
Jos Germn Nez Mori
Page 80 of 237

Global Undo Object Specific Undo
Esta funcionalidad proveer niveles para abortar las operaciones en curso: A nivel de operacin, que lo que permitir es cancelar, las fusiones en curso y regresar a la funcionalidad anterior o al home de la aplicacin. A nivel de comando, que lo que permitir es cancelar, la operacin de alta de una nueva fusin, 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, ms de un persona principal, el sistema deber mostrar el mensaje: Seleccin Incorrecta, en la fusin 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: Seleccin 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.
Structured Text Entry, Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation
Tabla 8: Historia de usuario Gestionar fusin de personas
Jos Germn Nez Mori
Page 81 of 237

Historia de Usuario N Nombre: Buscar Personas Fusionadas : PER0003 Prioridad:
El sistema permitir la bsqueda de personas que han pasado por un proceso de fusin (tanto de las personas principales o fusionadas). Se debe permitir, tanto la bsqueda de personas fsicas como jurdicas, cada bsqueda con criterios particulares Bsqueda de personas fsicas: El sistema muestra los siguientes criterios de bsqueda: Cdigo de persona, Tipo Identificacin, Nmero de Identificacin, Sin Identificacin, Cdigo externo de la persona (proporcionado por la red), Primer apellido, Segundo apellido, Primer nombre, Segundo nombre, Fecha de Nacimiento, Red comercial, Nmero de tarjeta Sanitaria.
Descripcin:
Una vez ingresado los datos necesarios, se mostrar el listado con las personas fusionadas coincidentes. Esta lista mostrar la siguiente informacin: Cdigo de persona, Fecha de fusin, Tipo de Indetificacin, Sin Identificacin, Estado de la persona en el sistema, Cdigo externo de la persona, Primer apellido, Segundo apellidos, Nombre, Fecha de nacimiento, Nmero de tarjeta sanitaria.
Bsqueda de personas jurdicas: El sistema muestra los siguientes criterios de bsqueda: Cdigo de persona, Fecha de fusin, Tipo de Indetificacin, Sin Identificacin, Estado de la persona en el sistema, Cdigo externo de la persona, Razn 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 informacin: Cdigo de Persona, Fecha de fusin, Tipo de identificacin, Nmero de identificacin, Sin identificacin, Estado de la persona en el sistema, Cdigo externo de persona, Red comercial, Razn social, Fecha de constitucin.
Jos Nez Mori

System Status Feedback Interaction Feedback Progress feedback

Warning
Global Undo
Jos Germn Nez Mori
Page 82 of 237

Object Specific Undo
Esta funcionalidad presentar la opcin de cancelar, que ser a nivel de operacin, y que permitir abortar, la bsqueda en curso, retonando el control a la funcioanlidad previa o al home de la aplicacin.
Tanto para la bsqueda de personas fsicas y jurdicas se debe tener en cuenta lo siguiente: Cdigo de persona, alfanumrico de 6 caracteres (Campo obligatorio). Tipo identificacin, alfanumrico, siendo este un listado a seleccionar (Campo obligatorio). Nmero de identificacin, alfanumrico de 6 caracteres. Sin identificacin, listado de seleccin ( Si / No). Estado de la persona en el sistema, listado de seleccin (Habilitada / Inhabilitada). Cdigo externo de la persona, alfanumrico de 8 caracteres (Campo obligatorio) Red comercial, listado a seleccionar Bsqueda de personas fsicas: Primer y segundo apellido, primer y segundo nombre, alfanumricos de 50 caracteres. Fecha de nacimiento, con el formato DD/MM/AAAA Nmero de tarjeta sanitaria, alfanumrico de caracteres.
Campos obligatorios: Primer y segundo apellido, tarjeta sanitaria. Bsqueda de personas jurdica: Razn social, alfanumrica de 50 caracteres. Nombre comercial, alfanumrico de 50 caracteres. Actividad comercial, listado a seleccionar, de las actividades parametrizadas en el sistema.
Campos obligatorios: Razn social, nombre comercial. El sistema validar el formato de los campos del criterio de bsqueda y presentar los siguientes mensajes en formato de notificacin ante el incumplimiento de los mismos: : Si existen campos del criterio de bsqueda 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.
Structured Text Entry
Jos Germn Nez Mori
Page 83 of 237

Step by Step P referentes P ersonal Object Space Favourite Multilevel Help Commands Aggregation
Tabla 9: Historia de usuario Buscar personas fusionadas
Historia de Usuario N Nombre:
: PER0004 Prioridad:
Recuperar Datos Entidad Finaciera Descripcin: 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 bsqueda se debe ingresar los siguientes criterios: Tipo de identificacin. Nmero de identificacin. Una vez ingresado estos criterios, el sistema recuperar un listado con las personas coincidentes de la entidad financiera. Este listado tendr la siguiente informacin: Cdigo de cliente. Cdigo de cliente de la EEFF, Tipo de identificacin, Nmero de identificacin, Nombre y apellidos del cliente De este listado, se debern poder seleccionar una de las personas, para poder obtener sus datos, los cuales sern recuperados de la Entidad financiera, siendo estos: Tipo de identificacin, Nmero de identificacin, Nombre, Primer Apellido, Segundo Apellido, Fecha de nacimiento, Profesin, Estado civil, Lista de cuentas corrientes de la persona, Lista de domicilios de la persona, Telfono (prefijo y nmero). Una vez obtenido estos datos, se actualizar los datos en la persona del sistema.
Jos Nez Mori

System Status Feedback Interaction Feedback
Al momento de recuperar tanto los datos de las persona, como el listado de personas coincidentes en la entidad financiera, si se produce algn error en este proceso, el sistema deber mostrar un mensaje en formato de Error: "Se ha producido el / los si Tanto la recuperacin de los datos, como el listado de personas coincidentes tardarn de 3 a 5 segundos, por lo cual el sistema mostrar un icono animado que indique el porcentaje de tiempo de la espera.
Progress feedback
Jos Germn Nez Mori
Page 84 of 237
Warning
Tras el evento de actualizacin con los datos obtenidos de la entidad financiera, el sistema mostrar un mensaje en fomato de confirmacin: "Se va actualizar la persona con los datos de la EEFF, Esta seguro de esta operacin?"
Global Undo Object Specific Undo Esta funcionalidad presentar la opcin de cancelar, que ser a nivel de operacin, tanto en la busqueda como en la recuperacin 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 opcin de "ir Atrs", lo cual permitira regresar al listado de personas. Para los campos de criterio se tendr en cuenta lo siguiente:
Tipo identificacin, alfanumrico, siendo este un listado a seleccionar (Campo obligatorio). Nmero de identificacin, alfanumrico de 6 caracteres..
Abort Operation
Go back
El sistema validar el formato de los campos del criterio de bsqueda y presentar los siguientes mensajes en formato de notificacin ante el incumplimiento de los mismos: Si existen campos del criterio de bsqueda 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.
Structured Text Entry Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation
Tabla 10: Historia de usuario Recuperar datos entidad financiera
Jos Germn Nez Mori
Page 85 of 237

His toria de Us uario N Nombre : : PER0005
Prioridad: Gestionar Situacin Familiar de la Persona (alta) De s cripcin: Esta funcionalidad permitir la gestin (Alta) de la situacin familiar asociada a un persona fsica.
Esta funcionalidad, deber presentar la siguiente informacin a cumplimentar: Datos Asegurado: Situacin familiar, NIF del cnyuge, % de retencin del IRPF, fecha de movilidad geogrfica, prolongacin de la actividad laboral (valor SI /NO), pensin compensatoria a favor de cnyuge (importe anual), anualidades por alimentos a favor de los hijos.
Datos Hijos, descendientes menores de 25 aos o discapacitados: Ao de nacimiento, ao de adopcin, grado de minusvala, necesita ayuda terceros (valor SI / NO),
Esta seccin, permitir adicionar o eliminar los datos de hijos o descendiente de un listado mostrado en la parte inferior de esta seccin. Datos de Ascendientes mayores de 65 aos o discapacitados que viven con el perceptor: Ao de nacimiento, grado de minusvala, necesita ayuda de terceros (valor SI/NO).
Esta seccin, permitir adicionar o eliminar los datos de los ascendientes de un listado mostrado en la parte inferior de esta seccin.
Us uario de Cre acin: Es timacin:
Jos Nez Mori
Fe cha Alta: 01/04/2010 De pe nde ncia:
Re quis itos de Us abibilidad As ociados

Requisito A plicacin Com entarios
System Status Feedback Interaction Feedback Progress feedback

Tras cumplimentar los tres pasos de la funcionalidad y ejecutar el evento de guardado el sistema mostrara un mensajes en formato de confirmacin: "Se va a guardar los datos de la situacin familiar de la persona, Esta seguro de realizar esta operacin?"
W arning
Global Undo Object Specific Undo
Jos Germn Nez Mori
Page 86 of 237
Abort Operation
Esta funcionalidad presentar la opcin de cancelar, que ser a nivel de operacin, 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 aplicacin, abortando as, las operaciones r Tanto los pasos: Datos de los hijos y datos de los descendientes, contarn con la opcin de "Ir Atrs", lo que permitir regresar al paso inmediatamente anterior.
Go back Structured Text Entry,
Step by Step Preferentes Personal Object Space Favourite Multilevel Help Commands Aggregation
Esta funcionalidad contar con tres pasos a cumplimentar, los cuales seran cada una de las secciones detallas en la descripcin. Cada uno de estos pasos se presentarn en el orden de la descripcin, indicando en cada paso, el paso en el que esta y el paso que le falta para finalizar la funcionalidad.
X X
Cada paso de esta funcionalidad presentar un icno 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 Situacin familiar de la persona
2.3 Pruebas de aceptacin En esta seccin, se presenta las pruebas de aceptacin mnimas, asociadas a los requisitos de usabilidad contemplados en cada una de las historias de usuario desarrolladas.
Criterio de validacin de los Requisitos de Usabilidad
Id
Historia
PER0001
Relacionar Personas
Se deber dar de alta una relacin ya existente en la lista de relaciones de la persona gestionada, ante esto el sistema deber mostrar un mensaje del tipo notificacin: La operacin 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 relacin, cuando el recurso de Base de datos se encuentra cado, ante esto el sistema deber mostrar un mensaje del tipo notificacin: La operacin no se ha realizado con xito, debido a que el manejador de Base de datos no se encuentra disponible (BD001). System Status Feedback Dar de alta nuevas relaciones y verificar, que estas se aaden al final de la lista de relaciones de la persona gestionada. Adems validar que cada una de estas nuevas relaciones esten remarcadas con un color Interaction Feedback determinado
Jos Germn Nez Mori
Page 87 of 237

Dar de alta nuevas relaciones asociadas a la persona gestionada y luego confirmar esta operacin. Ante esto el sistema deber mostrar el siguiente mensaje en formato de notificacin: "Se va a gurdar los cambios en las relaciones de la persona gestionada,
Warning
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 Durante el alta de relacines 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 aplicacin. Confirmar adems, que los datos de la relacin en curso no s Abort Operation
Verificar los formatos de los siguientes campos: Tipo Vnculo, lista desplegable (obligatorio) Vinculo, lista desplegable. (obligatorio) Cdigo de la persona alfanumrico de 6 caracteres (obligatorio). Sin identificacin, campo de verificacin. Fiscalmente aplicable, campo de verificacin.
Structured Text Entry,
Luego realizar la bsqueda de personas a relacionar, sin cumplimentar el campo: "Cdigo de la persona". Ante esto el sistema deber mostrar un mensaje del tipo notificacin: "El campo Cdigo de la persona, es obligatorio
Tabla 12 : Prueba de aceptacin Relacionar personas
Jos Germn Nez Mori
Page 88 of 237

Id Historia Criterio de validacin de los Requisitos de Usabilidad
P ER0002
Gestionar Fusin de Personas System Status Feedback
Se debe dar de alta una fusin, cuando el recurso de Base de datos se encuentra cado, ante esto el sistema deber mostrar un mensaje del tipo notificacin: La operacin no se ha realizado con xito, debido a que el manejador de Base de datos no se encuentra disponible (BD001).
Progress feedback
Realizar una fusin y una vez aceptada la misma, verificar que se muestra una barra de progreso, donde se informe el estado de la fusin. Guardar la fusin asociada a una persona principal y luego verificar que el sistema muestre el siguiente mensaje en formato de confirmacin: "Se va a gurdar la fusin en curso, Esta seguro de realizar esta operacin?"
Durante el proceso de alta de una fusin validar lo siguiente: Ejecutar el evento cancelar, y verificar, que el sistema redirige al usuario a la funcionalidad anterior o al home de la aplicacin. Confirmar adems, que los datos de la fusin no se han registrado en el sistema. Aceptar o confirmar la fusin 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 fusin no se han registrado en el sistema.
W arning
Abort Operation
Jos Germn Nez Mori
Page 89 of 237

Realizar una fusin, y validar las siguientes casusticas tras el evento de aceptar la fusin: Seleccionar, de la lista de personas a fusionar, ms de un persona principal, donde, tras el evento de aceptar la fusin, verificar que el sistema muestra el siguiente mensaje:Seleccin Incorrecta, en la fusin 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 fusin, se debe validar que el sistema muestra el siguiente mensaje: Seleccin 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 fusin, verificar que el sistema muestra el siguiente mensaje: Existen personas en la lista que falta seleccionar.
Structured Text Entry,
Tabla 13: Prueba de aceptacin Gestionar fusin de personas

PER0003
Buscar personas fusionadas Abort Operation
Durante el cumplimentado de datos para la bsqueda, ejecutar el evento cancelar: Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o la home de la aplicacin, dejando la operacin en curso sin efecto. Validar los formatos de los campos de la
Jos Germn Nez Mori
Page 90 of 237

Validar los formatos de los campos de la bsqueda: Cdigo de persona, alfanumrico de 6 caracteres (Campo obligatorio), Tipo identificacin, alfanumrico, siendo este un listado a seleccionar (Campo obligatorio), Nmero de identificacin, alfanumrico de 6 caracteres, Sin identificacin, listado de seleccin ( Si / No). Estado de la persona en el sistema, listado de seleccin (Habilitada / Inhabilitada), Cdigo externo de la persona, alfanumrico de 8 caracteres (Campo obligatorio), Red comercial, listado a seleccionar Bsqueda de personas fsicas: Primer y segundo apellido, primer y segundo nombre, alfanumricos de 50 caracteres, Fecha de nacimiento, con el formato DD/MM/AAAA, Nmero de tarjeta sanitaria, alfanumrico de caracteres.
Campos obligatorios: Primer apellido, tarjeta sanitaria. Bsqueda de personas jurdica:
segundo
Razn social, alfanumrica de 50 caracteres., Nombre comercial, alfanumrico de 50 caracteres, Actividad comercial, listado a seleccionar, de las actividades parametrizadas en el sistema. Campos obligatorios: Razn social, nombre comercial.
Realizar bsquedas con criterios:

:
lo siguientes
Campos del criterio de bsqueda que no se ajusten al formato adecuado, donde, el sistema deber mostrar el siguiente mensaje en formato de notificacin: 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 notificacin: El campo XXXX, es obligatorio.
Tabla 14: Prueba de aceptacin Buscar personas fusionadas
Jos Germn Nez Mori
Page 91 of 237

PER0004
System Status Feedback
Recuperar tanto los datos de la persona, como el listado de personas coincidentes de la entidad financiera, cuando no se tiene conexin al servicio de entidad financiera. Ante esto el sistema deber mostrar un mensaje en formato de error: "Se ha producid Validar que ante la recuperacin 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 operacin Obtenido los datos de la persona de la entidad financiera, actualizar los mismos en el sistema, donde, al aceptar dicha actulizacin el sistema deber mostar un mensaje en formato de notificacin: "Se va actualizar la persona con los datos de la EEFF, Durante la recuperacin 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 operacin de obtener los datos de la persona de la entidad financiera, al ejecutar el evento "ir atr", el sistema redirija al usuario a la operacin listado de personas coincidentes de la bsqueda en la entidad financiera
Progress feedback
Warning
Abort Operation
Go back
Jos Germn Nez Mori
Page 92 of 237

Validar los formatos de los campos del criterio: Tipo identificacin, alfanumrico, siendo este un listado a seleccionar (Campo obligatorio). Nmero de identificacin, alfanumrico de 6 caracteres. una bsqueda considerando lo
Realizar siguiente
Campos obligatorio del criterio , que no hayan sido seleccionado, se mostrar el siguiente mensaje: El campo XXXX, es obligatorio.
Tabla 15: Prueba de aceptacin Recuperar datos entidad financiera

PER0005
Gestionar Situacin Familiar de la Persona (alta) Warning
Tras cumplimentar los tres pasos de la funcionalidad y ejecutar el evento de guardado, validar, que el sistema muestre un mensajes en formato de confirmacin: "Se va a guardar los datos de la situacin familiar de la persona, Esta seguro de realizar esta operacin?". 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 aplicacin, dejando la operacin en curso sin efecto. Durante el cumplimentado de los pasos: Datos de los hijos y datos de los descendientes, ejecutar el evento "Ir Atrs", Tras esto, validar que el sistema redirige al usuario al paso anterior cumplimentado.
Abort Operation
Go back
Jos Germn Nez Mori
Page 93 of 237

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.
Step by Step
Multilevel Help
Commands Aggregation
Tabla 16: Prueba de aceptacin Gestionar situacin familiar
Jos Germn Nez Mori
Page 94 of 237
V. Fase de Elaboracin del Marco gil de Trabajo
Versin 1.0

FECHA 25/10/2010 VERSION 1.0 DESCRIPCIN Fase de Elaboracin del marco gil de trabajo. AUTOR Jos Germn Nez Mori
Jos Germn Nez Mori
Pgina 96 de 237
Fase de Elaboracin del marco gil de trabajo 1. Introduccin

Como siguiente paso planteado por el marco gil de trabajo es la ejecucin de la fase de elaboracin. Es en este capitulo en el que se abordar el desarrollo de la misma.
El marco gil de trabajo, de acuerdo a su planteamiento metodolgico, 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 planificacin de esta primera iteracin 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 segn sugiere la metodologa AUP (Agile Unified Process), deber ser alguna historia o historias que permitan implementar de manera iterativa la arquitectura del sistema que constituir el ncleo 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 ncleo central del sistema, es decir, una historia de usuario que contemple la gran mayora de requisitos de usabilidad. Donde, la funcionalidad seleccionada, sirva como estructura base a la implementaciones de las dems historias de usuario.
Cabe mencionar, que la manera de trabajo ejecutada en esta fase servir como gua para las iteraciones de desarrollo de la fase de construccin.
2. Desarrollo de la fase de Elaboracin

En esta seccin se desarrollar, cada uno de los artefactos necesarios para cumplir con los hitos de esta fase de elaboracin, tal cual el planteamiento escrito en el capitulo Marco gil de trabajo.
2.1 Planificacin de la Primera Iteracin

En esta seccin, se presentar la planificacin de esta primera iteracin de desarrollo, la cual seguir los lineamientos planteados por la metodologa Scrum [JPAL02]. Jos Germn Nez Mori Pgina 97 de 237
De acuerdo al Product backlog:

Id. Historia PER001 PER002 PER003 PER005 Descripcin Relacionar Personas Gestionar Fusin de Personas Buscar Personas Fusionadas Gestionar Situacin Familiar de la Persona (alta) Prioridad Estimacin 10 9 9 8 Observaciones Responsable JGNuez JGNuez JGNuez
PER004
JGNuez Esta funcionalidad deber de empezar a desarrollarse una vez publicado los servicios de la JGNuez Entidaed Financiera
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 mayora de requisitos de usabilidad (ver capitulo Fase de Inicio del marco gil de trabajo), es seleccionada para su desarrollo en esta primera iteracin.
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 diseo.
Figura 29: Vista de la planificacin en das En la figura 29, se puede apreciar, el tiempo que durar este Sprint y los das que se consideran laborables para esta tarea.
Jos Germn Nez Mori
Pgina 98 de 237
Figura 30: Sprint y tareas de la primera Iteracin en Spritometer En la figura 30, se muestra la planificacin de esta primera iteracin en la herramienta Sprintometer, donde se ha registrado cada una de las tareas que contemplar este Sprint, las horas de duracin de las mismas y el responsable de su ejecucin. A continuacin se muestra a ms detalle esta planificacin (tabla 18), obtenida como reporte de Sprintometer.
Jos Germn Nez Mori
Pgina 99 de 237
Tabla 18: Planificacin 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 iteracin. Tambin se puede Jos Germn Nez Mori Pgina 100 de 237
apreciar en esta planificacin, que cada uno los patrones de usabilidad han sido considerados como tareas, los cuales a su vez se han dividido en tareas pequeas, que en conjunto permitirn la integracin de un patrn de usabilidad determinado al diseo de la funcionalidad en curso. Con la planificacin presentada, se pretende cumplir con el desarrollo del hito de Prototipo de Arquitectura. De acuerdo a esto, en la siguiente seccin, se seguir con lo planificado, desarrollando as, cada una de las tareas pactadas en este Sprint.
2.2 Prototipo de Arquitectura

En la presente seccin, 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 planificacin se encuentra la implementacin 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 continuacin se describe, el desarrollo de cada una de las tareas especificadas en la planificacin del Sprint (ver tabla 18 - Planificacin del Sprint Relacionar personas).
2.2.1 Tarea de Implementacin de la Funcionalidad

Esta tarea tiene como objetivo la implementacin de la funcionalidad Relacionar Personas, por tal motivo, a continuacin se muestra cada uno de los modelos involucrados en la misma.
Para esta tarea se ha contemplado las siguientes sub-tareas, registradas en la planificacin del Sprint, ver la siguiente tabla 19:
Jos Germn Nez Mori
Pgina 101 de 237
Tabla 19: Planificacin inicial de la tarea de implementacin de la funcionalidad
2.2.1.1 Diseo de la capa de datos

A continuacin se presenta el modelado de las entidades de datos necesarias en esta funcionalidad.
Jos Germn Nez Mori
Pgina 102 de 237
Figura 31: Modelo de entidades de la capa de datos Este diseo, representa el modelo entidad relacin, que deber ser persistido en la base de datos seleccionada a modo de tablas de la misma.
2.2.1.2 Diseo de la capa de negocio

En esta seccin se presenta el diseo correspondiente a la capa de negocio, que consiste, en una serie de componentes del tipo servicio, que contendrn las operaciones necesarias del ncleo de esta funcionalidad.
Figura 32: Modelado de la capa de negocio
Jos Germn Nez Mori
Pgina 103 de 237
Todos estos servicios, contienen la lgica necesaria de la operativa asociada a la funcionalidad de Relacionar Personas. Esta capa de negocio, deber de reflejar tambin que entidades de datos son involucradas en las operaciones de cada uno de estos servicios, por tal motivo, a continuacin se muestra este diseo:
Figura 33: Dependencias de servicios con las entidades de datos
2.2.1.3 Diseo de la capa de presentacin

En esta seccin se presenta, los diseos asociados a la capa de presentacin, mostrando as, las transiciones y estados de accin en esta capa, ante una peticin de usuario y su respectiva respuesta.
Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas Jos Germn Nez Mori Pgina 104 de 237
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 generacin de cdigo 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 darn soporte a las peticiones de los usuarios. Tambin, 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 harn uso del ncleo de esta funcionalidad para procesar las peticiones.
Jos Germn Nez Mori
Pgina 105 de 237
Figura 36: Diagrama de actividad asociado a la capa de presentacin En la figura 36, se presenta las transiciones y cambios de estado que tendr la pgina Web asociada a esta funcionalidad. Adems como se puede apreciar en la columna de sistema se encuentran estados de accin relacionados con las operaciones de la clase controladora (ver figura 9 Modelado de la clase controladora).
2.2.1.4 Resultado de Tarea

A continuacin, se presenta los resultados tras la implementacin de cada uno de los diseos, asociados a la funcionalidad de Relacionar Personas.
Estos resultados, consisten en presentar cada una de las pantallas de la aplicacin, generadas en base a AndroMDA y detallar brevemente el funcionamiento de las mismas.
Jos Germn Nez Mori
Pgina 106 de 237
Figura 37: Bsqueda de personas Pgina principal de la aplicacin En la figura 37, se muestra la pantalla principal de la aplicacin, 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 Bsqueda de personas, se resume, en que permite la bsqueda de una persona por medio de su cdigo de persona o en todo caso listar todas las personas registradas en el sistema (ver figura 37 Bsqueda de personas Pgina principal de la aplicacin).
Figura 38: Relacionar Personas Criterio de seleccin de personas a relacionar
Jos Germn Nez Mori
Pgina 107 de 237
Figura 39: Relacionar Personas Adicin 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 relacin a la persona seleccionada. Es de acuerdo a esta seleccin, que se adicionar relaciones a una persona determinada.
Ya en la figura 39, se puede apreciar, la adicin 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: Actualizacin de la planificacin de la tarea de implementacin de la funcionalidad
Jos Germn Nez Mori
Pgina 108 de 237
2.2.2 Integracin del patrn de usabilidad Warning

Es esta seccin, se presenta la integracin del patrn de usabilidad Warning, a la funcionalidad de Relacionar Personas. Para mas detalle de este patrn ver anexo 01 (Especificacin Patrn de usabilidad Warning).
Como se ha comentado en captulos anteriores, los patrones de usabilidad, se tomarn en cuenta desde el tiempo de diseo, por tal motivo, en esta seccin, se detalla cada uno de los niveles o capas, en las cuales ser necesario adicionar nuevos componentes u operaciones que harn posible la integracin de este patrn de usabilidad.
Siguiendo lo planteado por el presente Sprint, la tarea de integracin del patrn de usabilidad Warning, presenta la siguiente planificacin, mostrada en la tabla 21:
Tabla 21: Planificacin inicial de la tarea de integracin del patrn de usabilidad Warning Como se pude apreciar en la tabla 21, se presentan las sub-tareas asociadas a esta integracin, las cuales son la continuacin de la tarea de implementacin de la funcionalidad (ver tabla 20Actualizacin de la planificacin de la tarea de implementacin de la funcionalidad). Para la integracin de este patrn de usabilidad, al diseo de la funcionalidad de Relacionar Personas, el presente trabajo, tomara como base lo especificado en la gua del patrn de usabilidad Warning (ver anexo 01 Especificacin Patrn de usabilidad Warning). De esta gua, se toma los siguientes diagramas base para la integracin:
Jos Germn Nez Mori
Pgina 109 de 237
Figura 40 Diagrama de clases de la especificacin del patrn de usabilidad Warning
Figura 41: Diagrama de secuencia de la especificacin del patrn 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 diseo de las capas, como en la implementacin del sistema.
Jos Germn Nez Mori
Pgina 110 de 237
A continuacin, se detallan las modificaciones en las capas o niveles implicados y los resultados de la misma.
2.2.2.1 Integracin del patrn de usabilidad Warning en la capa de presentacin y capa de negocio
Para la integracin del patrn de usabilidad Warning en estas capas (presentacin y negocio), se ha adicionado dos nuevos componentes de tipo servicio (RelacionSession y
RelacionesWrapperService), quedando el diseo de la siguiente manera:
Figura 42: Modelado de la clase controladora con el Patrn de usabilidad Warning
Estos dos nuevos componentes (RelacionSession y RelacionesWrapperService), harn de componentes intermedios entre la capa de presentacin y la capa de negocio (ver figura 42), buscando de esta manera, seguir con la especificacin del patrn de usabilidad Warning, especficamente, en lo planteado en su diagrama de clases (ver figura 40 Diagrama de clases de la especificacin del patrn de usabilidad Warning).
Con el objetivo, de presentar mayor claridad en la integracin de este patrn de usabilidad, al diseo de estas capas, a continuacin, se detalla la correspondencia de cada uno de los componentes nuevos (ver figura 42), contra la especificacin del patrn de usabilidad Warning (ver figura 40):
Jos Germn Nez Mori
Pgina 111 de 237
Componentes del P.U. Warning View Controller DomainClassWrapper DomainClass -
Componentes de diseo en la funcionalidad RelacionarPerController RelacionarPerController RelacionesWrapperService RelacionesService RelacionSession
Tabla 22: Correspondencia de componentes del patrn de usabilidad Warning y los componentes de la funcionalidad Como se aprecia en la figura 42 (Modelado de la clase controladora con el Patrn 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 presentacin, permitiendo de esta manera, validar aquellas operaciones que necesitan de confirmacin del usuario antes de persistir los datos.
2.2.2.2 Flujo de trabajo segn el patrn de usabilidad Warning

En esta seccin, se explicar brevemente, la interaccin de los componentes diseados, para la integracin del patrn de usabilidad Warning a la funcionalidad de Relacionar Personas, y cuya secuencia, dar a entender el flujo de trabajo de este patrn, tanto a nivel de diseo como de implementacin. Todo esto, tomando como base el diagrama de secuencias de la especificacin del patrn (ver Figura 41- Diagrama de secuencia de la especificacin del patrn de usabilidad Warning)
A continuacin, el detalle de este flujo de trabajo, donde para tener relacin de los componentes que se describen, se podr revisar la figura 42 (Modelado de la clase controladora con el Patrn de usabilidad Warning):
Una vez realizada la peticin de adicionar una nueva relacin, la clase controladora (RelacionarPerController), recibe los datos necesarios para el procesamiento y verifica si el flujo de trabajo necesita de una confirmacin del usuario.
La validacin, si el flujo necesita de una confirmacin de usuario, se hace contra el componente RelacionesWrapperService, y su operacin checkOK, donde a esta operacin, se pasa como parmetro el nombre del mtodo u operacin, que se necesita validar. En este caso en concreto, se pasa como parmetro el mtodo nuevaRelacion.
La operacin checkOK, del componente RelacionesWrapperService, valida si el Pgina 112 de 237
Jos Germn Nez Mori
mtodo nuevaRelacion, necesita de confirmacin del usuario, de ser as, responde a la peticin con el valor del flag de control de este mtodo. En la clase controladora (RelacionarPerController), si la operacin chekOK del componente RelacionesWrapperService, retorna un valor falso, significa que se necesita de confirmacin del usuario y se debe pedir esto a la vista. Con el objetivo de mostrar un alerta de confirmacin en la pginas Web, la clase controladora (RelacionarPerController) setea valores necesarios para este comportamiento en el objeto de sesin RelacionSession. Una vez confirmado esta operacin, por medio del usuario, esta peticin es enviada a la clase controladora (RelacionarPerController), la cual, solicita al componente
RelacionesWrapperService, que actualice el estado de confirmacin, para el mtodo nuevaRelacion. Actualizado el estado de confirmacin del mtodo nuevaRelacion, la clase controladora enva los datos recogidos de la vista, para su procesamiento por medio de la operacin nuevaRelacion del componente RelacionesWrapperService, el cual, verifica nuevamente si el flag de confirmacin de la operacin nuevaRelacion, esta a verdadero, de ser as, enva los datos para su persistencia por medio del componente RelacionesService.
2.2.2.3 Resultados de la Integracin del patrn de usabilidad Warning

En la presente seccin se presenta los resultados, tras la integracin del patrn de usabilidad Warning. Estos resultados consistirn, en presentar las pginas Web, generadas en base a AndroMDA y la actualizacin de la planificacin de la tarea de integracin de este patrn
Jos Germn Nez Mori
Pgina 113 de 237
Figura 43: Confirmacin de adicin de nueva relacin segn el patrn de usabilidad Warning Como se puede apreciar en la figura 44, ante el evento de adicin de una nueva relacin a la persona seleccionada, se muestra una alerta del tipo confirmacin, donde se advierte al usuario que los datos que ha seleccionado estn a punto de persistirse, de confirmarse esta alerta, se enviar la peticin al sistema, el cual se encargar de guardar la informacin en la base de datos y actualizar la pantalla con la nueva adicin.
Figura 44: Resultados tras la confirmacin de la adicin de una nueva relacin
Jos Germn Nez Mori
Pgina 114 de 237
Una vez presentado los resultados de la aplicacin, a continuacin se presenta la actualizacin de la planificacin respectiva a esta tarea de integracin del patrn de usabilidad Warning:
Tabla 23- Planificacin actualizada de la tarea de integracin del patrn de usabilidad Warning
2.2.3 Integracin del patrn de usabilidad System Status Feedback

En la presente seccin, se detallar cada uno de los pasos seguidos para la integracin del patrn de usabilidad System Status Feedback. En adelante haremos referencia a este patrn como SSF. Para mas detalle de este patrn ver anexo 02 (Especificacin del Patrn de Usabilidad System Status feedback).
Esta Integracin del patrn de usabilidad SSF, se realizar tanto en el diseo como en la implementacin de la funcionalidad Relacionar Personas.
A continuacin, se presenta la planificacin inicial de esta tarea de integracin del patrn de usabilidad SSF:
Tabla 24: Planificacin inicial de la tarea de integracin del patrn de usabilidad SSF Siguiendo lo especificacin del patrn de usabilidad SSF (ver anexo 02 - Especificacin Patrn Jos Germn Nez Mori Pgina 115 de 237
de Usabilidad System Status feedback), la integracin de este patrn a la funcionalidad de Relacionar Personas, tomara en cuenta como diseos base lo siguiente:
Figura 45: Diagrama de clases de la especificacin del patrn de usabilidad SSF
Figura 46: Diagrama de secuencia de la especificacin del patrn de usabilidad SSF
Jos Germn Nez Mori
Pgina 116 de 237
2.2.3.1 Integracin del patrn de usabilidad SSF a la capa de presentacin y capa de negocio
La integracin de este patrn de usabilidad, en la capa de presentacin, 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 integracin se adicionan 4 nuevos componente que interactuarn entre la capa de negocio y la capa de presentacin, estos componentes son: AdministradorEstados, EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService. De acuerdo a esto el diseo de la funcionalidad de Relacionar Personas, queda de la siguiente manera:
Figura 47: Integracin del patrn de usabilidad SSF en el diseo de la funcionalidad Relacionar Personas Como se describe al inicio de esta seccin, la integracin de este patrn de usabilidad SSF a la funcionalidad de Relacionar Personas, se basa en ciertos diseos de la especificacin de este patrn (ver anexo 02 - Especificacin Patrn de Usabilidad System Status feedback).
De acuerdo esto, y buscando entender los detalles de esta integracin, se presenta una tabla (tabla 25) de correspondencias entre componentes de diseo de la especificacin de este patrn (ver figura 46) y el diseo de la integracin a la funcionalidad en curso (ver figura 48):
Jos Germn Nez Mori
Pgina 117 de 237
Componentes del P.U. SSF View Controller StatusManager ConcreteStatus ConcreteStatus ConcreteStatus DomainClass
Componentes de diseo en la funcionalidad RelacionarPerController RelacionarPerController AdministradorEstados EstadoErrorService EstadoExitoService EstadoAdvertenciaService RelacionesService
Tabla 25: Correspondencia de componentes del patrn de usabilidad SSF y los componentes de la funcionalidad Estos nuevos componentes de la integracin de este patrn de usabilidad (ver figura 19), gestionarn los estados, ante la operativa de Adicin de una nueva Relacin, permitiendo de esta manera, mantener informado al usuario ante cualquier cambio de estado, relacionado con la operativa en curso.
2.2.3.2 Flujo de trabajo segn el patrn de usabilidad SSF

Con el objetivo de dar un mayor detalle de la integracin del patrn de usabilidad SSF, en la presente seccin, se describir brevemente el flujo de trabajo, de la operativa de Adicin de una nueva relacin, tomando en cuenta que en esta operativa ya se encuentra integrado este patrn de usabilidad.
El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la especificacin de este patrn (ver figura 47).
A continuacin, el detalle de este flujo de trabajo, donde para tener relacin de los componentes que se describen, se podr revisar la figura 48 (Integracin del patrn de usabilidad SSF en el diseo de la funcionalidad Relacionar Personas):
Ante la peticin de adicionar una nueva relacin a la persona seleccionada, la clase controladora recibe los datos de la vista, los cuales los procesa y enva estos para su persistencia a la capa de negocio, pasando respectivamente, por los componentes del patrn de usabilidad Warning (ver seccin 2.2.2 del presente capitulo).
En la capa de negocio, el componente responsable de ejecutar esta operativa, es el componente RelacionesService, con su operacin nuevaRelacion.
Jos Germn Nez Mori
Pgina 118 de 237
La operacin 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 operacin de persistir los datos, se realiza de manera satisfactoria, con error u otros estados.
Esta operacin 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 notificacin de que se ha producido un cambio de estado. Esta notificacin, vendr acompaada de los datos necesarios de este cambio de estado, que permitirn a este componente por medio de su operacin 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 informacin 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 enva los datos para su persistencia a la capa de negocio, consultar a cada uno de los componentes de gestin de estados (EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService), si se ha producido algn cambio de estado en la operativa en curso (Adicin de una relacin).
De haberse producido algn cambio de estado, la clase controladora, recoger los datos necesarios del componente de gestin de estados respectivo y proceder a informar de esto a la vista, por medio de mecanismos del Framework Struts utilizado en la capa de presentacin.
2.2.3.3 Resultados de la integracin del patrn de usabilidad SSF

En esta seccin, se presentar los resultados tras la integracin del patrn de usabilidad SSF a la funcionalidad de Relacionar Personas. Estos resultados permitirn ilustrar lo que se menciona en la seccin de flujo de trabajo. Adems se presentar la planificacin actualizada de esta tarea.
Ante el evento de adicin de una nueva relacin, si la adicin se realiza satisfactoriamente el sistema informar al usuario de esto, en la zona de estados, ver la siguiente figura:
Jos Germn Nez Mori
Pgina 119 de 237
Figura 48: Resultados tras la adicin satisfactoria de una nueva relacin Si, ante el evento de adicin de una nueva relacin, se produce algn 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 pgina Wb), ver la siguiente figura:
Figura 49: Resultados de error tras la adicin de una nueva relacin A continuacin se muestra la planificacin actualizada de la tarea de integracin del patrn de Jos Germn Nez Mori Pgina 120 de 237
usabilidad SSF:
Tabla 26: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SSF
2.2.4 Integracin del patrn de usabilidad Global Undo

En la presente seccin, se detalla cada uno de los pasos seguidos para la integracin del patrn Global Undo (en adelante GU), a la funcionalidad de Relacionar Personas. Para mas detalle de este patrn ver el anexo 03 (Especificacin del Patrn de Usabilidad Global Undo).
Siguiendo la dinmica de las anteriores integraciones, a continuacin se presenta la planificacin inicial de la tarea de integracin del patrn de usabilidad GU:
Tabla 27: Planificacin inicial de la tarea de integracin del patrn de usabilidad GU Esta seccin, tomara como base para esta integracin, la especificacin de este patrn de usabilidad (ver anexo 03 - Especificacin del Patrn de Usabilidad Global Undo), usando ciertos diseos como punto de partida para esta labor. A continuacin se presenta los diseos base de este patrn de usabilidad:
Jos Germn Nez Mori
Pgina 121 de 237
Figura 50: Diagrama de clases de la especificacin del patrn de usabilidad GU
Figura 51: Diagrama de secuencias de la especificacin del patrn de usabilidad GU
2.2.4.1 Integracin del patrn de usabilidad GU a la capa de presentacin y capa de negocio
Jos Germn Nez Mori
Pgina 122 de 237
La integracin de este patrn de usabilidad, ha implicado la creacin de un nuevo componente de tipo servicio (RelacionesHistorySessin), que dar soporte a las tareas que requiere este patrn de usabilidad. Adems, se adiciona una nueva operacin undoRelaciones, tanto, en la clase controladora (RelacionesPerController), como en el componente de servicio de la capa de negocio (RelacionesService). Estas modificaciones, permitirn atender a las peticiones de los usuarios, ante el evento de deshacer (Undo) de la operacin en curso.
Segn esta premisa, el diseo queda la siguiente manera:
Figura 52: Integracin del patrn de usabilidad GU en la capa de negocio y capa de diseo Adicional a estos cambios, se modifica tambin el flujo de actividades de la pgina 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 operacin de soporte en el lado del sistema, es decir, una operacin en su clase controladora relacionada (ver figura 53). De acuerdo a esto el diagrama de actividades de la pgina Web queda de la siguiente manera:
Jos Germn Nez Mori
Pgina 123 de 237
Figura 53: Integracin del patrn de usabilidad GU en el diagrama de actividades de la pgina de Adicin de relaciones Cada una de estas modificaciones siguen lo especificado por este patrn (Ve Figura 52). Por tal motivo, a continuacin se presenta un cuadro con las correspondencias de componentes especificados y lo diseado en la integracin (ver Figura 54):
Componentes del P.U. GU View Controller HistoryList Command ConcreteCommand DomainClass HistoryException
Componentes de diseo en la funcionalidad RelacionarPerController RelacionarPerController RelacionesHistorySessin RelacionesServiceBase RelacionesService Relacion -
Tabla 28: Correspondencia de componentes del patrn de usabilidad GU y los componentes de la funcionalidad Como se pude ver en tabla 28, existe un componente de la especificacin (HistoryException), que no tiene correspondencia en el diseo de la integracin, 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 Germn Nez Mori Pgina 124 de 237
2.2.4.2 Flujo de trabajo segn el patrn de usabilidad GU

Con el objetivo de dar un mayor detalle de la integracin del patrn de usabilidad GU, en la presente seccin, se describir brevemente el flujo de trabajo, de la operativa de Adicin de una nueva relacin, tomando en cuenta que en esta operativa ya se encuentra integrado este patrn de usabilidad.
El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la especificacin de este patrn (ver figura 53).
De acuerdo a esto, a continuacin, se presenta el detalle de este flujo de trabajo, donde para tener relacin de los componentes que se describen, se podr revisar la figura 54 (Integracin del patrn de usabilidad GU en la capa de negocio y capa de diseo):
Detalle del flujo ante el evento de adicin de una nueva relacin:
Cuando la peticin de adicin de una nueva relacin, llega a la clase controladora (RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda esta informacin para ser enviado para su persistencia a la capa de negocio.
De este objeto que se enva a la capa de negocio, su referencia ser guardada por el componente: RelacionesHistorySessin, con lo cual se estara clonando el comando que se esta ejecutando (Adicin de una nueva relacin).
Detalle del flujo ante el evento de deshacer (Undo), las nuevas relaciones:
Cuando la peticin de deshacer, llega a la clase controladora (RelacionarPerController), esta recupera todos los objetos clonados en el componente RelacionesHistorySessin, que han sido guardados en el transcurso de la operativa de adicin de nuevas relaciones.
Con este listado de objetos clonados, la clase controladora realiza una peticin de deshacer las relaciones asociadas a estos objetos. Esta peticin se ejecuta contra la operacin undoRelaciones del componente de la capa de negocio RelacionesService.
La operacin undoRelaciones, recibe como parmetro, un listado de objetos del tipo Relacin, y solicita por cada objeto a la capa de datos, que elimine el registro persistido en Base de datos.
Jos Germn Nez Mori
Pgina 125 de 237
2.2.4.3 Resultados de la integracin del patrn de usabilidad GU

Con el objetivo de ilustrar lo descrito en la anterior seccin, a continuacin se presenta los resultados a nivel de pginas Web.
Se adiciona dos nuevas relaciones a la persona seleccionada (PER005, PER006), ver la siguiente figura:
Figura 54: Adicin de nuevas relaciones considerando el patrn GU Como se describe en la anterior seccin, por cada adicin de una nueva relacin se realiza una clonacin del objeto que se esta adicionando, de tal manera que cuando el usuario realice la peticin 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 quedara de la siguiente manera tras el evento de deshacer (Undo):
Jos Germn Nez Mori
Pgina 126 de 237
Figura 55: La adicin de relaciones tras en el evento de deshacer (Undo) A continuacin, se presenta la actualizacin de la planificacin asociada a la integracin de este patrn de usabilidad:
Tabla 29: Planificacin actualizada de la tarea de integracin del patrn de usabilidad GU
2.2.5 Integracin del patrn de usabilidad Abort Operation

En esta seccin, se detallar los pasos seguidos para la integracin del patrn de usabilidad Abort Operation a la funcionalidad de Relacionar personas. Para esta integracin, el presente trabajo se ha basado en la especificacin del patrn Abort (ver anexo 04 Especificacin del patrn de usabilidad Abort). Jos Germn Nez Mori Pgina 127 de 237
El patrn Abort Operation, en adelante AO, pertenece a la familia del patrn de usabilidad Abort, siendo este patrn AO, una rama especifica, es decir, una especificacin concreta para ciertas tareas de usabilidad, que en este caso puntual, es aplicar este patrn para cancelar una operacin en curso.
Este patrn de usabilidad AO, basa mucho su planteamiento en el patrn de usabilidad Global Undo (detallado en la anterior seccin 2.2.4 del presente capitulo), es por este motivo, que la integracin de este patrn tomar como base el diseo y la implementacin del patrn Global Undo.
Siguiendo la especificacin del patrn de usabilidad AO (ver anexo 04 Especificacin del patrn de usabilidad Abort), se tomar como referencia para la integracin, los siguientes modelos base:
Figura 56: Diagrama de clases de la especificacin del patrn de usabilidad AO
Jos Germn Nez Mori
Pgina 128 de 237
Figura 57: Diagrama de secuencia de la especificacin del patrn de usabilidad AO Como se puede apreciar en las anteriores figuras (figura 59 y 60), la estructura del planteamiento de este patrn es casi similar a lo planteado por el patrn de usabilidad Global Undo (ver figuras 52 y 33), variando especficamente en el flujo de actividades tras el evento de cancelar una operacin.
A continuacin, se presenta la planificacin inicial de la tarea de integracin del patrn de usabilidad AO a la funcionalidad en curso:
Tabla 30: Planificacin inicial de la tarea de integracin del patrn de usabilidad AO
2.2.5.1 Integracin del patrn de usabilidad AO a la capa de presentacin y capa de negocio

La integracin de esta patrn, ha implicado la creacin de una nueva operacin en la clase controladora (RelacionesPerController), esta operacin es: cancelarRelaciones, la cual Jos Germn Nez Mori Pgina 129 de 237
permitir atender las peticiones de los usuarios ante el evento de cancelar la operacin en curso (adicionar una nueva relacin).
Esta integracin, utiliza un componente ya creado en la integracin del patrn de usabilidad Global Undo, llamado RelacionesHistorySession, que tendr la misma utilidad que en este patrn, es decir, clonar objetos de la operativa de adicionar nuevas relaciones.
De acuerdo esto el diseo queda de la siguiente manera:
Figura 58: Integracin del patrn de usabilidad AO en la capa de negocio y capa de presentacin Adicional a la operacin 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 accin en el lado del sistema, es decir, la referencia a la nueva operacin (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 aplicacin, es decir, a la pgina de bsqueda de personas. Por tal motivo, este flujo deber de tener un estado de fin, que haga referencia a la funcionalidad de Bsqueda de Personas.
Segn estas premisas el diseo de actividades asociadas a la pgina de Adicin de una nueva relacin, queda de la siguiente manera:
Jos Germn Nez Mori
Pgina 130 de 237
Figura 59: Integracin del patrn de usabilidad AO en el diagrama de actividades de la pgina de Adicin de relaciones
La modificaciones necesarias para esta integracin, han seguido lo planteado por el patrn AO (ver figura 59), por tal motivo, se presenta a continuacin una tabla de correspondencias de componentes, tanto de la especificacin, como de la integracin (ver figura 61):
Componentes del P.U. AO View Controller HistoryList Command ConcreteCommand DomainClass HistoryException ProgressIndicator
Componentes de diseo en la funcionalidad RelacionarPerController RelacionarPerController RelacionesHistorySessin RelacionesServiceBase RelacionesService Relacion -
Tabla 31: Correspondencia de componentes del patrn de usabilidad AO y los componentes de la integracin
Jos Germn Nez Mori
Pgina 131 de 237
Como se pude ver en tabla 31 (Correspondencia de componentes del patrn de usabilidad AO y los componentes de la funcionalidad), existe dos componentes que no tienen correspondencia en la integracin, 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 integracin adicional
2.2.5.2 Flujo de trabajo segn el patrn de usabilidad AO

A continuacin, se explicar brevemente, la interaccin de los componentes diseados, para la integracin del patrn de usabilidad AO a la funcionalidad de Relacionar Personas, y cuya secuencia, dar a entender el flujo de trabajo de este patrn, tanto a nivel de diseo como de implementacin. Todo esto, tomando como base el diagrama de secuencia de la especificacin del patrn (ver Figura 60).
A continuacin, el detalle de este flujo de trabajo, donde para tener relacin de los componentes que se describen, se podr revisar la figura 61 (Integracin del patrn de usabilidad AO en la capa de negocio y capa de presentacin):
Detalle del flujo ante el evento de adicin de una nueva relacin:
Cuando la peticin de adicin de una nueva relacin, llega a la clase controladora (RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda esta informacin para ser enviado para su persistencia a la capa de negocio.
De este objeto que se enva a la capa de negocio, su referencia ser guardada por el componente: RelacionesHistorySessin, con lo cual se estara clonando el comando que se esta ejecutando (Adicin de una nueva relacin).
Detalle del flujo ante el evento de Cancelar la operativa de nuevas relaciones:
Cuando la peticin de cancelar, llega a la clase controladora (RelacionarPerController), esta recupera todos los objetos clonados en el componente RelacionesHistorySessin, que han sido guardados en el transcurso de la operativa de adicin de nuevas relaciones.
Con este listado de objetos clonados, la clase controladora realiza una peticin de deshacer las relaciones asociadas a estos objetos. Esta peticin, se ejecuta sobre la operacin undoRelaciones del componente de la capa de negocio RelacionesService.
La operacin undoRelaciones, recibe como parmetro, un listado de objetos del tipo
Jos Germn Nez Mori
Pgina 132 de 237
Relacin, 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 clonacin, la clase controladora (RelacionarPerController), redirecciona la response hacia la funcionalidad de Bsqueda de Personas, que es para esta aplicacin el home de la misma.
2.2.5.3 Resultados de la integracin del patrn de usabilidad AO

Con el objetivo de ilustrar lo descrito en la anterior seccin, a continuacin se presenta los resultados a nivel de pantallas Web.
Se adiciona una nueva relacin a la persona seleccionada (PER003), ver la siguiente figura:
Figura 60: Adicin de nuevas relaciones considerando el patrn 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 aplicacin (funcionalidad de bsqueda de personas).
Jos Germn Nez Mori
Pgina 133 de 237
Figura 61: Home de la aplicacin tras el evento Cancelar Si volvemos a consultar las relaciones de la persona, en la cul se ejecuto el evento de Cancelar, podemos apreciar que la relacin que se adiciono no se encuentra.
Figura 62: Consulta de relaciones tras el evento de cancelar
A continuacin, se presenta la planificacin actualizada de la tarea de integracin del patrn de usabilidad AO.
Jos Germn Nez Mori
Pgina 134 de 237
Tabla 32: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AO
2.2.6 Integracin del patrn de usabilidad System Progress Feedback

En la siguiente seccin, se detallar la integracin del patrn System Progress Feedback, en adelante SPF, a la funcionalidad de Relacionar Personas. Para esta integracin, el presente trabajo se ha basado en la especificacin de este patrn de usabilidad (ver anexo 05 Especificacin del patrn de usabilidad System Progress Feedback).
De acuerdo, a la especificacin de este patrn de usabilidad, se tomar como punto de partida para esta integracin, los siguientes modelos:
Figura 63: Diagrama de clases de la especificacin del patrn de usabilidad SPF
Jos Germn Nez Mori
Pgina 135 de 237
Figura 64: Diagrama de secuencia de la especificacin del patrn de usabilidad SPF Siguiendo la dinmica de las dems patrones ya integrados a la funcionalidad de Relacionar Personas, a continuacin se presenta la planificacin inicial de las tareas asociadas a la integracin de este patrn de usabilidad:
Tabla 33: Planificacin inicial de la tarea de integracin del patrn de usabilidad SPF
2.2.6.1 Integracin del patrn de usabilidad SPF a la capa de presentacin y capa de negocio
Cabe mencionar, antes de iniciar con el detalle de esta integracin, que este patrn de usabilidad SPF, no fue considerado como parte de los requisitos de usabilidad asociados a la historia de Jos Germn Nez Mori Pgina 136 de 237
usuario Relacionar Personas (ver capitulo de Fase de inicio del marco gil de trabajo). Debido, a que estamos en una iteracin que tiene como objetivo, construir el prototipo de la arquitectura que mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrn en la arquitectura inicial.
Esta patrn de usabilidad SPF, ser aplicado, sobre la funcionalidad dada por el patrn de usabilidad Global Undo (ver seccin 2.2.4 Integracin del patrn de usabilidad Global Undo), es decir, que ira informando el progreso de la operacin de deshacer (Undo) las adiciones de nuevas relaciones.
En la integracin de este patrn, se ha diseado un nuevo componente del tipo servicio (IndicadorProgresoService), que permitir, dar soporte a las tareas requeridas por este patrn de usabilidad, siendo una de las principales, la de un componente observador, que ira informando del progreso de determinadas operaciones.
Adicional al nuevo componente diseado para la integracin de este patrn de usabilidad, se adiciona una nueva operacin en la clase controladora (RelacionarPerController), esta operacin 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 lneas arriba, se muestra el diseo tanto de la capa de negocio como la de presentacin:
Figura 65: Integracin del patrn de usabilidad SPF en la capa de negocio y capa de diseo
Jos Germn Nez Mori
Pgina 137 de 237
Adicional a los cambios en componentes de la capa de negocio y presentacin, se modifica tambin el flujo de actividades de la pgina Web, de adicin 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 operacin de soporte en el lado del sistema, es decir, una operacin en su clase controladora (ver figura 68). Este nuevo evento, que se adiciona al flujo de actividades de la pgina Web, no representara un evento implcito como tal, sino, ms que todo una referencia a una operacin 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 pgina Web queda de la siguiente manera:
Figura 66: Integracin del patrn de usabilidad SPF en el diagrama de actividades de la pgina Web de Adicin de relaciones Como se describe al inicio de esta seccin, esta integracin se basa en ciertos diseos obtenidos Jos Germn Nez Mori Pgina 138 de 237
de la especificacin de este patrn de usabilidad SPF, es as, que la adicin de un nuevo componente y la creacin de una nueva operacin en la clase controladora (ver figura 68), se basan en el diseo de clases de esta especificacin (ver figura 66). Segn esto, se presenta a continuacin una tabla de correspondencias entre componentes, tanto de la especificacin como de la integracin en si:
Componentes del P.U. SPF View Controller DomainClass DomainClass ProgressIndicator Monitor
Componentes de diseo en la funcionalidad RelacionarPerController RelacionarPerController RelacionesService Relacion IndicadorProgresoService SetInterval (Funcin javaScript asociada a las pgina JSP)
Tabla 34: Correspondencia de componentes del patrn de usabilidad SPF y los componentes de la Integracin
Como se puede apreciar en la tabla 34, existe un componente de la especificacin, llamado Monitor, que tiene su correspondencia en una funcin javaScript en la integracin, esto se debe, a que en la implementacin 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.
2.2.6.2 Flujo de trabajo segn el patrn de usabilidad SPF
En esta seccin, se detalla las actividades asociadas a la funcionalidad de Adicionar relaciones, teniendo en cuenta que para esta operativa, se tiene integrado el patrn de usabilidad SPF. Este flujo de trabajo, es una secuencia de actividades que se expone en esta seccin, con el objetivo, de proporcionar un mayor detalle del funcionamiento de este patrn de usabilidad SPF, integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la especificacin de este patrn de usabilidad, especficamente, en su diagrama de secuencia (ver figura 67).
A continuacin, el detalle de este flujo de trabajo, donde para tener relacin de los componentes que se describen, se podr revisar la figura 68 (Integracin del patrn de usabilidad SPF en la capa de negocio y capa de diseo):
Jos Germn Nez Mori
Pgina 139 de 237
Solicitada la peticin de deshacer las nuevas relaciones adicionadas (Undo), la vista enviar dicha peticin para ser resuelta en su controlador relacionado (RelacionarPerController) y a su vez, esta peticin activar un timer en el objeto de monitorizacin, que pasado un determinado tiempo, ejecutar determinadas acciones.
Este objeto de monitorizacin es simulado por la funcin JavaScript "setInterval", la cual residir en la pgina Web asociada a la funcionalidad en curso, es decir, en lado del cliente.
Una vez sobrepasado, el tiempo mnimo de 2 segundos en el timer del objeto de monitorizacin, este verificar si la peticin, 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 peticin, de deshacer las nuevas relaciones adicionadas, el objeto de monitorizacin, lanzar una peticin paralela (simulacin de hilo paralelo al principal), para verificar el progreso de esta operacin de deshacer (Undo).
El objeto encargado de simular este hilo paralelo, es el objeto XMLHttpRequest, el cual es un objeto, de la tecnologa asncrona Ajax. Este objeto, presenta un esquema de trabajo que se asemeja a lo especificado en el diagrama de secuencia, de la especificacin del patrn de usabilidad SPF (ver figura 67), por tal motivo a continuacin se muestra el esquema de trabajo de este objeto [SUNPB05]:
Figura 67: Esquema de trabajo del objeto XMLHttpRequest El objeto XMLHttpRequest, enviar una peticin cada un segundo al controlador asociado (RelacionarPerController), en su operacin "verificarProgreso". Esta operacin, solicitar la Jos Germn Nez Mori Pgina 140 de 237
informacin del progreso de la operativa de deshacer (Undo) al componente IndicadorProgresoService y su operacin verificarProgreso. Bien sabemos, que el servicio RelacionesService, es el encargado de deshacer las relaciones adicionadas por medio de su operacin undoRelaciones. Esta operacin undoRelaciones, recibir como parmetro un listado de las relaciones que deber de solicitar a la capa de datos que se elimine de base de datos, donde, por cada relacin 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 relacin 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, enve informacin de progreso, este escuchador, guarde esta informacin como parte de sus atributos. Cada vez que la operacin verificarProgreso del controlador (RelacionarPerController), solicite esta informacin 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 operacin verificarProgreso, enviara esta respuesta al objeto XMLHttpRequest, que ser el encargado, junto a funciones javaScript propias de la pgina Web, de informar esto en pantalla y adems 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.
2.2.6.3 Resultados de la integracin del patrn de usabilidad SPF

Se adicionan nuevas relaciones a la persona seleccionada:
Jos Germn Nez Mori
Pgina 141 de 237
Figura 68: Adicin 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 relacin eliminada se ir informando del progreso de la operacin en la pgina Web.
Figura 69: Barra de progreso mientras se aplica la operacin de Undo a las relaciones adicionadas Una vez finalizada la operacin, de deshacer las adiciones de relaciones, la barra de progreso desaparecer actualizando la pgina Web y mostrar las relaciones iniciales que tena antes de estas adiciones. Jos Germn Nez Mori Pgina 142 de 237
Siguiendo la dinmica de anteriores integraciones de patrones de usabilidad, a continuacin, se presenta la planificacin actualizada asociada a las tareas de integracin de este patrn de usabilidad.
Tabla 35: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SPF
2.2.7 Integracin del patrn de usabilidad Abort Command

Este patrn de usabilidad Abort Command, en adelante AC, pertenece a la familia del patrn de usabilidad Abort, al igual que el patrn Abort Operation (ver seccin 2.2.5 Integracin del patrn de usabilidad Abort Operation ), este tambin, es una rama especifica de este patrn Abort (ver anexo 04 Especificacin del patrn de usabilidad Abort). De acuerdo a esta premisa, en la presente seccin se abordar, la integracin de este patrn de usabilidad AC a la funcionalidad de Relacionar Personas, especficamente aplicado, sobre el comando asociado al patrn de usabilidad System Progress Feedback, es decir, se buscar integrar el patrn, para lograr cancelar el comando, que muestra la barra de progreso asociada a cierta operativa.
Al igual, que el patrn de usabilidad System Progress Feedback, el patrn 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 iteracin que tiene como objetivo construir el prototipo de la arquitectura, que mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrn en la arquitectura inicial.
Mencionar, que esta integracin del patrn de usabilidad AC, basar su diseo en los modelos base de la especificacin del patrn Abort, teniendo ciertos matices propios del patrn de Jos Germn Nez Mori Pgina 143 de 237
usabilidad AC, por tal motivo, se utilizar el mismo diagrama de clases base utilizado por el patrn Abort Operation (ver Figura 59).
La diferencia en los enfoques de integracin entre el patrn Abort Operation y el AC, reside en el diseo base de la interaccin de los componentes que intervienen en el planteamiento de uno u otro patrn. Por tal motivo la integracin del patrn de usabilidad AC, utilizar como base el siguiente diagrama de secuencias:
Figura 70: Diagrama de secuencia de la especificacin del patrn de usabilidad AC Como parte inicial de esta integracin, se presenta la planificacin de las tareas necesarias en la labor de integracin del patrn de usabilidad AC a la funcionalidad de Relacionar Personas:
Tabla 36: Planificacin inicial de tarea de integracin del patrn de usabilidad AC
Jos Germn Nez Mori
Pgina 144 de 237
2.2.7.1 Integracin del patrn de usabilidad AC a la capa de presentacin y capa de negocio.

Como se describe al inicio de esta seccin, esta integracin, ser aplicada sobre el comando de informacin de progreso de ciertas funcionalidades, por tal motivo esta integracin, basar su modelado en el diseo de nuevos componentes, realizados en la integracin del patrn de usabilidad System Progress Feedback:
Figura 71: Integracin del patrn de usabilidad AC en la capa de negocio y capa de diseo Como se puede ver en la figura 74, se adiciona nuevas operaciones al componente de servicio IndicadorProgresoService y a la clase controladora, las cuales permitirn, que se ejecuten las tareas necesarias de este patrn de usabilidad AC, sobre el comando del patrn System Progress Feedback.
Adicional a estos cambios, se modifica tambin el flujo de actividades asociadas la pgina Web, de adicin de nuevas relaciones. Esta modificacin, consiste en adicionar un nuevo evento llamado cancelarComando y su respectivo estado de accin en el lado del sistema (operacin en la clase controladora), que permite las peticiones de cancelar un comando determinado, en este caso en concreto, el comando de informacin de progreso de la operativa de deshacer (Undo).
De acuerdo a esto, el flujo de actividades asociado a la pgina Web, de adicionar nuevas relaciones, queda de la siguiente manera:
Jos Germn Nez Mori
Pgina 145 de 237
Figura 72: Integracin del patrn de usabilidad AC en el diagrama de actividades de la pgina Web de Adicin de relaciones Con el propsito de entender cada uno de los cambios, realizados en los componentes de diseo tanto de la capa de presentacin, como la de negocio, se presentar un cuadro de correspondencia entre componentes de la especificacin del patrn de usabilidad Abort (ver Figura 59) y la integracin del patrn AC (ver figura 74):
Jos Germn Nez Mori
Pgina 146 de 237
Componentes del P.U. AO View Controller HistoryList Command ConcreteCommand DomainClass HistoryException ProgressIndicator
Componentes de diseo en la funcionalidad RelacionarPerController RelacionarPerController RelacionesServiceBase RelacionesService Relacion IndicadorProgresoService
Tabla 37: Correspondencia de componentes del patrn de usabilidad AC y los componentes de la integracin Como se puede apreciar en la tabla 37, existen ciertos componentes de la especificacin que no tiene su correspondencia en la parte de integracin, esto se debe a dos motivos: Que alguno de ellos, no son requeridos por esta patrn AC, si no mas bien, por el patrn de usabilidad Abort Operation, siendo este el componente HistoryList. Que el resto de componentes, es administrado por el Framework de integracin Spring utilizado por el marco gil de trabajo
2.2.7.2 Flujo de trabajo segn el patrn de usabilidad AC
Este flujo de trabajo, es una secuencia de actividades que se expone en esta seccin, con el objetivo, de proporcionar un mayor detalle del funcionamiento de este patrn de usabilidad AC, integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la especificacin del patrn de usabilidad Abort, especficamente, en su diagrama de secuencia (ver figura 73).
A continuacin, el detalle de este flujo de trabajo, donde para tener relacin de los componentes que se describen, se podr revisar la figura 74 (Integracin del patrn de usabilidad AC en la capa de negocio y capa de diseo): En la pgina Web, de adicin de nuevas relaciones, cuando se ejecuta el comando Undo de las relaciones recin adicionadas, se muestra al usuario un barra informativa del progreso de la operacin en curso. Esta barra de progreso informativa, contar con la opcin de cancelar, la cual permitir
Jos Germn Nez Mori
Pgina 147 de 237
abortar el progreso del comando en curso. Esta cancelacin del comando en curso, implicar abortar la barra de progreso y cancelar las acciones respectivas de la operacin Undo. Una vez realizada la peticin de cancelar el comando, la clase controladora, recibir esta peticin para su tratamiento en la operacin cancelarComando. La operacin 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 operacin actualizarEstadoCancelar. Sabemos que la operacin undoRelaciones, del componente RelacionesService, se encarga de solicitar a la capa de datos la eliminacin de relaciones ya persistidas y adems de informar de este progreso a su escuchador IndicadorProgresoService, donde, por cada vez que informa a su escuchador con el progreso de esta operacin, verificar si el estado de cancelacin de este comando esta activo. Si el estado de cancelacin no esta activo, el componente RelacionesService, seguir con la operativa en curso, caso contrario, abortar su operacin de eliminacin de relaciones, lo cual implicar, que las relaciones eliminadas antes que el estado de cancelacin este activo, persistir su eliminacin en bases de datos y de las restantes quedar su registro. En la operacin cancelarComando, de la clase controladora, una vez solicitado la actualizacin del estado de cancelacin de comando al componente
IndicadorProgresoService, volver consultar, las relaciones asociadas a las persona de la operativa y retorna estos resultados a pantalla.
2.2.7.3 Resultados de la integracin del patrn de usabilidad SPF

Se adicionan nuevas relaciones a la persona seleccionada:
Jos Germn Nez Mori
Pgina 148 de 237
Figura 73: Adicin 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 relacin eliminada se ir informando del progreso de la operacin en la pgina Web.
Figura 74: Barra de progreso con opcin 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 operacin hasta el punto de Jos Germn Nez Mori Pgina 149 de 237
progreso que se tena, es decir, que eliminan aquellas relaciones antes de abortar la operacin.
Para el caso presentado en la figura 51 (Barra de progreso con opcin 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 relacin de las adicionas, esta relacin sera 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 integracin del patrn de usabilidad AC, se presenta la planificacin actualizada, asociada a esta tarea:
Tabla 38: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AC
Jos Germn Nez Mori
Pgina 150 de 237
2.3 Planificacin tras la primera iteracin

Una vez realizada cada una de las integraciones planificadas, a continuacin se presentan un reporte genrico, que informarn 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 planificacin Como se puede apreciar en la figura 76, se muestra la carga de trabajo a lo largo de tiempo de la planificacin. Se puede observar como esta carga va disminuyendo mientras mas cerca estamos de la fecha fin de la planificacin. Cada una de las integraciones a la funcionalidad de Relacionar Personas, que se ha descrito a lo largo de este captulo, conforma en su conjunto, el prototipo de la arquitectura propuesta en esta fase de elaboracin. 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 sern contempladas.
Jos Germn Nez Mori
Pgina 151 de 237
VI. Conclusiones
En el presente capitulo, se presenta las conclusiones obtenidas tras la realizacin de esta Tesis de fin de Master.
Este trabajo fue desarrollado siguiendo los lineamientos de las metodologas giles: Scrum, Agile Unified Process (AUP) y Extreme Programming (XP), que en conjunto con los principios y patrones de usabilidad, conformaron el marco gil de trabajo y tal cual se esperaba, contribuyeron como una gua para la inclusin de los principios de usabilidad en el desarrollo del sistema.
Desde el punto de vista metodolgico, el marco gil de trabajo planteado, fue utilizado como base para la aplicacin del paradigma orientado a objetos, demostrando de esta manera su amplia adecuacin y alto grado de utilidad en el desarrollo de sistemas que sigan esta estructura.
El entorno tecnolgico seleccionado para la construccin del sistema, resulto apropiado y no fueron detectados inconvenientes importantes durante el desarrollo del mismo, que pudiera afectar o contradecir la eleccin realizada, si no mas bien contribuyeron, en la inclusin de los principios de usabilidad antes del desarrollo.
El alto grado de disponibilidad de bibliotecas de uso variadas y de herramientas de libres distribucin de la tecnologa Java, constituyen otro de los motivos que justifican la seleccin de la plataforma sobre la que se ha desarrollado en sistema, alentando as, el uso de las mima tanto para fines acadmicos como comerciales.
El sistema desarrollado, como un prototipo de arquitectura, deja en evidencias, que el ciclo de vida del software que sugiere el marco gil de trabajo, cumple con el objetivo de dar lineamientos, en los que los principios de usabilidad son tomados en cuenta tanto en la etapa de requerimientos como de diseo
De acuerdo a todo lo que se describe a lo largo de este trabajo de Tesis de fin Master, queda demostrado, la compatibilidad de la usabilidad con las metodologas giles, debido a que, cada uno de sus patrones y principios de usabilidad han sido engranados apropiadamente al planteamiento del marco gil de trabajo y todo esto justifica: Que no solo la usabilidad se limita a la interfaz del sistema, si no, que tambin afecta al ncleo del sistema Jos Germn Nez Mori Pgina 152 de 237
VII. Referencias Bibliogrficas

[AMDAWI10], AndroMDA, http://es.wikipedia.org/wiki/AndroMDA, 2010 [AMDA10] AndroMDA, http://www.andromda.org/index.php, 2010 [AMSPUA09] Ana M. Moreno, Maribel Sanchez Segura, Patrones de Usabilidad: Mejora de la Usabilidad del Software desde el momento Arquitectnico, 2009 [AMVN10] Apache Maven, http://maven.apache.org/, 2010 [ASTS10] Apache Struts, http://struts.apache.org/, 2010 [COAD98] Peter Coad, Eric Lefebvre, Jeff De Luca, Feature-Driven Development, http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users Guide/Feature_Driven_Development.htm, 1998 [CLEP09] Jos H. Cans, Patricio Letelier y M Carmen Penads, Metodologas giles en el desarrollo de software, 2009 [CRLA02] Craig Larman, UML y Patrones 2 Edicin, 2002. [DSDM09] DSDM Consortium, http://www.dsdm.org/, 2009 [HBNT10] Hibernate, http://www.hibernate.org/, 2010 [JSUT09] Jeff Sutherland, Scrum Log Jeff Sutherland, http://jeffsutherland.com/scrum/, 2009. [JPAL02] Juan Palacios, Flexibilidad con Scrum, http://www.lulu.com/content/1338172, 2002. [JCCA08] Jos Carlos carvajal Riola, Metodologas giles, 2008. [JOKR05] Joe Krebs, RUP in the dialogue with Scrum, 2005. [KEBE02] Kent Beck , Una explicacin de la programacin extrema: Aceptar el cambio, 2002. [KSXHB09] Ken Schwaber, Scrum, http://www.controlchaos.com/, 2009. [KINT07] Kinetia, Agile UP, http://www.kynetia.es/calidad/agile-up.html, 2007 [MFTO09] Manifesto for Agile Software Development, http://www.agilealliance.com/, 2009 [MART91] Martin, J., Rapid Application Development, Macmillan Inc., New York, 1991. [MFAS01] Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, Ron Jeffries, Brian Marick, Robert C. Martin, Ken Schwaber, Jeff Sutherland, Dave Thomas, Manifiesto for Agile Software Jos Germn Nez Mori Pgina 153 de 237
Development, http://www.agilemanifesto.org/, 2001. [MDAWI10] Model Driven Architecture, http://en.wikipedia.org/wiki/Modeldriven_architecture, 2010 [MGDU10] MagicDraw UML, http://www.magicdraw.com/show_patch1/download_demo/download_patch, 2010 [OMGWB10] OMG, http://www.omg.org/, 2010 [LECCO09] Luis Enrique Corredera de Colsa, Arquitectura dirigida por modelos para J2ME, 2009 [RJEF99] Ron Jeffries, Xprogramming, http://www.xprogramming.com/, 1999-
[RMAT6] Robert Martin, Agile and XP, http://www.objectmentor.com/, 2006 [SABL06] Scott Ambler, The Agile Unified Procees V1.1, 2006. [SALECA05] Emilio A. Snchez, Patricio Letelier y Jos H. Canos, Mejorando la gestin de historias de usuarios en XP, 2005. [SABL08] Scott Ambler, Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development, http://www.agilemodeling.com/essays/amdd.htm, 2008. [SMHR04] Schenone Marcelo Hernn, Diseo de una metodologa gil de desarrollo de software, mscheno@fi.uba.ar, 2004. [SPTOME09] Sprintometer, http://sprintometer.com/, 2009 [SPTOUG08] Sprintomer user guide, http://sprintometer.com/help, 2008 [SPIG10] Spring, http://www.springsource.org/, 2010 [SUNPB05] SUN Mycrosystems, Progress Bar Usin Ajax,https://bpcatalog.dev.java.net/nonav/ajax/progress-bar/design.html, 2005 [WDSDM09] Wikipedia, Dynamic System Development, http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method, 2009 [WAUP09] Wikipedia, Agile Unified Process, http://en.wikipedia.org/wiki/Agile_Unified_Process, 2009. [WDAS09] Wikipedia, Desarrollo gil de software, http://es.wikipedia.org/wiki/Procesos_%C3%A1giles, 2009. [WFDD09] Wikipedia, Feature Driven Development, http://en.wikipedia.org/wiki/Feature_Driven_Development, 2009
Jos Germn Nez Mori
Pgina 154 de 237
VIII. Anexos
Jos Germn Nez Mori
Pgina 155 de 237
Anexo 01: Especificacin Patrn de Usabilidad Warning
Jos Germn Nez Mori
Pgina 156 de 237
USABILITY-ENABLING GUIDELINE Identification Name Family Aliases Intent Providing different alert types upon execution of potentially damaging actions Problem Certain application tasks have potential serious consequences (that, for example, may not be undoable) so the application might need to verify with the user one last time before actually executing the task, to prevent them from calling said tasks by mistake, or to allow them to reconsider if needed. Context Applications where user tasks may have potentially damaging effects, including permanent changes or loss of data Required Mechanisms Abort: Certain types of warnings require a cancel button. See cancel operation section in Abort Mechanism
Warning
Feedback Status Display; Modeling Feedback Area
Jos Germn Nez Mori
Pgina 157 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Status change notification For each action that a user may take, consider the following aspects: the reversibility of the action the proportion of reversible actions that the system supports the frequency with which the action is taken the degree of damage that may be caused the immediacy of feedback to determine which of the following types of warning needs to be given to the user: Notification Confirmation Authorization Elaboration W_ELAB-1: Choosing undoable actions The Warnings addressed herein pertain to Notifications, Confirmations or Authorizations presented to the user during or before execution of an action Stakeholder should know that the more damaging the action (for irreversible actions) the higher the level of warning. (and viceversa). Be careful not to over-do. Actions of little damage can be left open as to not overload the user with notifications. Use notifications only when actually useful (the user will do something with the information provided) Warnings are considered preemptive, so notification that an error has occurred falls outside of the scope of this pattern (See Status Feedback). Discussions with Stakeholders W_Q-1 Which user actions are considered damaging? W_Q-2 Of these, which can't start execution until some sort of approval takes place? W_Q-3 Of those that need approval, which are highly damaging/sensitive, therefore needing credential approval? W_Q-4 For every action mentioned, which information will be shown to the user? Usage Examples (optional) W_EX-1: Notification Remember that during or before execution of an action. It does not interrupt nor does it expect user feedback W_EX-2: Confirmation: Are you sure you want to? right before execution of damaging action. User needs to OK for execution to proceed W_EX-3: Authorization You need to provide login and password before you can delete this file right before execution of highly damaging action. User needs to provide credentials or otherwise be authorized before excecution can proceed
Table 1: Warning. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 158 de 237
Figure 1: Warning. Use Case Model
Jos Germn Nez Mori
Pgina 159 de 237
Figure 2: Warning. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 160 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES System Responsibility W_SR-1 Be aware of damaging actions Generic Component Responsibilities For each Domain Component that includes at least one damaging method (one that needs to incur in a warning of some kind), a Wrapping Component must exist. This Wrapping Component mimics the structure of the Domain Component (it must have the same number of methods and the same method names as Domain Component), and it will sit between any invoking class and said DomainComponent. All methods in a Wrapping Component consist of a) a flag check, to determine if it is safe to invoke the method of the same name in the DomainComponent, and, b) a call to said method in Domain Component. For example, if a component called SalesItem is determined to have a damaging method, the component will be renamed to, for example, SalesItemDomain, to allow for the creation of its Wrapping Component, which must be called SalesItem for transparencys sake (an invoking class need not know if its dealing with a Wrapper or a Domain Component). When invoked, methods in the Wrapping Component can respond (to their invokers) that it is not yet safe to invoke the requested method, and an appropriate Warning is be issued. It is the Wrapping Component who is responsible for knowing which method call triggers which kind of warning (Notification, Confirmation, Authorization) and for determining whether or not the invocation of the method is safe. W_SR-2 Notify W_SR-3 Request confirmation W_SR-4 Request authorization Once the Warning is issued, if it is of the kind Notification, it must reach the UI Component, after which the invocation automatically returns to the Wrapping Component for execution. Since it is now safe to invoke the action in the DomainClass, the Wrapping Component does so. If the issued Warning is a Confirmation, it must also reach the UI Component but in this case it must wait for the user to OK. Once s/he does so, the invocation returns to the Wrapping Component for execution. Since it is now safe to invoke the action in the DomainClass, the Wrapping Component does so. Finally, if the issued Warning is an Authentication, it must reach the UI Component, which will then go through all the necesary steps (outside of the scope of this pattern) to perform the necessary credential cross-checking. Once the user has been authenticated in this manner, the invokation will return to the Wrapping Component for execution. Since it is now safe to invoke the action in the DomainClass, the Wrapping Component does so. The UI Component is responsible for displaying the Warning information and for receiving and processing the necessary user input to satisfy the given Warning (if applicable)
W_SR-5 Display warning
Jos Germn Nez Mori
Pgina 161 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-1 Be aware of damaging actions 1. View listens for user calls to actions, doAction(), and passes them on to the Controller Controller 2. The Controller forwards the call to doAction() to the appropriate class. Controller is not aware of the existance of DomainClassWraps, it simply forwards the call to the clase it know to be responsible for handling the method (DomainClassWraps take on the original name of the DomainClass) Objects DomainClassWrap 3. If a DomainClassWrap exists for the DomainClass the Controller is trying to reach, it will be the one receive the method call, which will invoke its own implementation of doAction(), 4. In it, it will then check if the called method is OK to execute with checkOK(doAction). 5. If it is, it will call onto DomainClass to execute the method 6b. Otherwise it will create a Warning of the appropriate type (Notification, Authentication or Confirmation) with the information pertaining to the invoked method 5. Since the flag is now set to OK, the DomainClassWrap immediately forwards the method call to DomainClass 6. DomainClass executes the invoked method, doAction(). 1. The new Warning issued in W_SR-1 (in this case a Notification) is forwarded onto the View 1. The new Warning issued in W_SR-1 (in this case a Confirmation) is forwarded onto the View 3, 4 DomainClass 6a. DomainClass executes the invoked method, doAction(). Warning 3, 4 Fig
W_SR-2 Notify
2. When the View receives a Notification, it displays a message to the user with the info contained within the Notification object. No user feedback is expected, as the control is returned to the DomainClassWrap via the Controller
3. The Controller requests DomainClassWrap to set the flag for doAction to OK. 4. It then calls the doAction() method on DomainClassWrap again, prompting a re-check of the flag for the current method. 3. The Controller requests DomainClassWrap to set the flag for doAction to OK. 4. It then calls the doAction() method on DomainClassWrap again, prompting a re-check of the flag for the current method.
W_SR-3 Request confirmation
2. When the View receives a Confirmation, it displays a dialogue to the user with the info contained within the Notification object and the option to OK or Cancel. If the user chooses to OK, the control is returned to the DomainClassWrap via the Controller
5. Since the flag is now set to OK, the DomainClassWrap immediately forwards the method call to DomainClass
6. DomainClass executes the invoked method, doAction().
3, 4
Jos Germn Nez Mori
Pgina 162 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-4 Request authorization 2. When the View receives an Authentication, it engages in the appropriate actions to identify the current user (perhaps involving other relevant domain classes) Once the user has been properly identified by the system, the control is returned to the DomainClassWrap via the Controller W_SR-5 Display warning As detailed in W_SR-2, W_SR-3 and W_SR-4, it is the Views responsibility to display Warnings. To do so appropriately, it uses all the information available in the Warning object. Controller 3. The Controller requests DomainClassWrap to set the flag for doAction to OK. 4. It then calls the doAction() method on DomainClassWrap again, prompting a re-check of the flag for the current method. Objects DomainClassWrap 5. Since the flag is now set to OK, the DomainClassWrap immediately forwards the method call to DomainClass DomainClass 6. DomainClass executes the invoked method, doAction(). Warning 1. The new Warning issued in W_SR-1 (in this case an Authentication) is forwarded onto the View 3, 4 Fig
3, 4
Jos Germn Nez Mori
Pgina 163 de 237
Figure 3: Warning. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 164 de 237
Figure 4: Warning. Usability-enabling design pattern. Sequence Diagram Warn (W_SR-1, W_SR-2, W_SR-3, W_SR-4 and W_SR-5)
Jos Germn Nez Mori
Pgina 165 de 237
Anexo 02: Especificacin Patrn de Usabilidad System Status Feedback
Jos Germn Nez Mori
Pgina 166 de 237
USABILITY-ENABLING GUIDELINE Identification Name Family Aliases Intent Providing the user with information on the different statuses the system might be in at any given time Problem An application can be in one or more statuses at once, so the user needs to be visually aware of all of them continuously. Context When changes that are important to the user occur or When failures that are important to the user occur: During task execution Because there are not enough system resources Because external resources are not working properly.
System Status Feedback (SSF)

Feedback Status Display; Modeling Feedback Area
Examples of status feedback can be found in status bars on windows applications; train, bus or airline schedule systems; VCR displays; etc. Required Mechanisms Abort: Certain types of status feedbacks may need a cancel option
Jos Germn Nez Mori
Pgina 167 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Status change notification HCI experts argue that the user wants to be notified when a change of status occurs. W_ELAB-2: Elaboration Source of status changing events Discussions with Stakeholders W_Q-5 Of which system statuses (and status changes) will the user be notified? W_Q-6 Which status changes are initiated by the user and which are initiated by the system or other resources (whether internal or external)? W_Q-7 For each system status, which type of notification should be shown to the user? Usage Examples (optional) W_EX-4: Browser online status Without proper status notification the user may lose track of which actions s/he is allowed to perform within the system at a given time. For example, the Online Status in a browser determines if the user is allowed to navigate only through cached pages (offline mode) or also through live web pages (online mode). W_EX-5: Status messages in Firefox Critical: When attempting to open a website without a live internet connection, Firefox will display an obtrusive message informing the user of this fact. Non-critical: When the browser is set to a site that has been marked as a favorite by the user, a small star will appear next to its URL. Less important: When the browser has finished loading a page, the word Done will appear in the lower-left corner of the status bar.
Changes in the system status can be triggered by any of the following: User-initiated events Internal actions realizadas por el propio sistema System failures Problems with external and internal resources
Status types Well-designed displays of the information to be shown should be chosen. They need to be unobtrusive if the information is not critically important, but obtrusive if something important happens. Displays should be put together in a way that emphasizes the important things, deemphasizes the trivial, doesnt hide or obscure anything, and prevents one piece of information from being confused with another. They should never be re-arranged, unless users do so themselves. Attention should be called to important information with bright colours, blinking or motion, sound or all three but a technique appropriate to the actual importance of the situation to the user should be used.
W_ELAB-3:
Status types: Levels of importance
For each piece of status information to be displayed, discuss with the user what type of information it is according to the following criteria: Critical information needs to be displayed obtrusively Important yet non-critical information needs to be highlighted in some way (with different colours, sound, motion or sizes Less important information should be displayed in the status area Note that during the requirements elicitation process, the discussion of the exact response type can be left until interface design time, but the importance of the different situations about which status information is to be provided and, therefore, the general type of salience (obtrusive, highlighted or standard) that will be provided does need to be discussed at this stage. Overloading the user with too many obtrusive status notifications can be counterproductive, as can be undermining critical status changes by relegating them to the status area.
Jos Germn Nez Mori
Pgina 168 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Status placement As regards the location of the feedback indicator, HCI literature mentions that users want one place where they know they can easily find this status information []. On the other hand, aside from the spot on the screen where users work, users are most likely to see feedback in the centre or at the top of the screen, and are least likely to notice it at the bottom edge. The standard practice of putting information about changes in state on a status line at the bottom of a window is particularly unfortunate, especially if the style guide calls for lightweight type on a grey background[]. The positioning of an item within the status display should be used to good effect. Remember that people born into a European or American culture tend to read left-to-right, top-tobottom, and that something in the upper left corner will be looked at most often[]. W_ELAB-4: Elaboration Status placement and writing directions Discussions with Stakeholders W_Q-8 How and where will each type of notification be shown to the user? Usage Examples (optional) W_EX-6: Facebook in Hebrew When the Facebook application is set to the Hebrew language (and other languages with right-to-left script), every status area is mirrored horizontally. (i.e. the small red balloon that indicates new messages will be displayed in the bottom-left corner of the page instead of to the bottom-right)
Ask about the users reading direction and whether or not the system will need to accommodate more than one direction. Display areas that are prominent in one culture will be less so in others of different writing direction.
Table 2: System Status Feedback. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 169 de 237
Figure 5: System Status Feedback. Use Case Model
Jos Germn Nez Mori
Pgina 170 de 237
Figure 6: System Status Feedback. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 171 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES System Responsibility W_SR-6 Be aware of system statuses (and their changes) Generic Component Responsibilities Certain Domain Components can execute actions that will change one or more application statuses. A StatusManager Component is responsible for monitoring said Domain Components and listen for their status-altering actions. A Status Component is responsible for holding all the information relating to a particular status and for modifying it according to StatusManager orders (see W_SR-7 and W_SR-8 for details on how this happens). All Status Components can have one active status value at any given time (i.e. online status can be online, idle, busy, offline, etc.). The component responsible for handling user events (UI) must monitor all Status Components and notify the user of any changes. W_SR-7 Handle user-initiated status changes The component responsible for handling user events (UI) listen for user actions and order their execution The component in charge of delegating actions (if any) is responsible for ordering the appropriate Domain Component to execute said action. Upon execution of actions that are status-changing, each Domain Component is responsible for notifying any interested parties (specifically the Status Manager Component, in this case) The StatusManager component then forwards the updated information onto the appropriate Status Component. Said Status Component is then responsible for determining the effect, if any, that the received information will have on its current active status value. It will, when applicable, change said value and notify any interested parties (specifically the UI Component in this case) The UI Component will update the status display for every notification of status change received. W_SR-8 Handle system-initiated status changes Upon execution of actions that are status-changing--invoked by any other class in the system or an external source--each Domain Component is responsible for notifying any interested parties (specifically the Status Manager Component, in this case), as is the case when such an action is invoked by the user through the UI (See W_SR-7) The StatusManager component then forwards the updated information onto the appropriate Status Component. Said Status Component is then responsible for determining the effect, if any, that the received information will have on its current active status value. It will, when applicable, change said value and notify any interested parties (specifically the UI Component in this case) The UI Component will update the status display for every notification of status change received. W_SR-9 Present system status notifications to users The UI Component is responsible for knowing how and where each status (and its possible values) are displayed within the interface, and thus update it accordingly upon reception of notifications of status value change.
Jos Germn Nez Mori
Pgina 172 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-10 Be aware of system statuses (and their changes) Controller Objects StatusManager 1. Upon system initialization, the StateManager subscribes to each DomainClass which it knows can execute statuschanging actions. Status DomainClass 2. The DomainClass represents the domain object(s) responsible for executing actions that lead to system state changes. It must notify all subscribers (StatusManager) of any changes. 2. The Status object holds all the information related to one system status and the means to change and query this information. It must notify all subscribers (View) of any changes. 2. The Controller orders the appropriate DomainClass to execute said actions 4. The StatusManager determines the corresponding Status object to update and does so with the information sent forth by the DomainClasses 2. The StatusManager determines the corresponding Status object to update and does so with the information sent forth by the DomainClasses The View knows which type of status notification to give for each status change. It also knows how and where to display each type of status notification and does so upon notification of Status objects. 5. The Status calculates the effect, if any, that the received information has on its current active status value, change it, if applicable, and notify its subscribers (View) 3. The Status calculates the effect, if any, that the received information has on its current active status value, change it, if applicable, and notify its subscribers (View) 3. The DomainClass executes the (status-altering) action and for notifies the StatusManager 3, 5 Fig
1. The View must subscribe to each Status object upon system initialization.
3, 5
W_SR-11 Handle user-initiated status changes
1. The View listens users requests for execution actions action, and forwards it to the Controller.
3, 4
W_SR-12 Handle system-initiated status changes
1. The DomainClass executes the (status-altering) action-triggered by a foraneous resource or other parts of the system--and for notifies the StatusManager
3, 4
W_SR-13 Present system status notifications to users
3, 4
Jos Germn Nez Mori
Pgina 173 de 237
Figure 7: System Status Feedback. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 174 de 237
Figure 8: System Status Feedback. Usability-enabling design pattern. Sequence Diagram Change Status (W_SR-11, W_SR-12 and W_SR-13)
Jos Germn Nez Mori
Pgina 175 de 237
Figure 9: System Status Feedback. Usability-enabling design pattern. Sequence Diagrams Be aware of system statuses (and their changes) (W_SR-6)
Jos Germn Nez Mori
Pgina 176 de 237
Anexo 03: Especificacin Patrn de Usabilidad Global Undo
Jos Germn Nez Mori
Pgina 177 de 237
USABILITY-ENABLING GUIDELINE Identification Name Family Aliases Intent Undo provides a way for the user to revert the effects of a previously executed action or series of actions within an application. Problem Users may need to undo certain actions they perform for a variety of reasons: They could have been exploring new functionality, have made a mistake or simply have changed their minds about what they have just done. Context Undo should be considered when developing highly interactive applications where users may perform sequences of steps, or execute actions that have tangible consequences.
Undo
Undo/Cancel Multi-Level Undo [Tidwell, 2002]; Undo [Welie, 2003]; Global Undo / Object-Specific Undo [Laasko, 2003]; Allow Undo [Brighton, 1998]
Jos Germn Nez Mori
Pgina 178 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Undo Users typically explore functionality of an application but do not want to be punished when selecting unwanted functions [Welie, 03]. The ability to undo a long sequence of operations lets users feel that the interface is safe to explore. While they learn the interface, they can experiment with it, confident that they arent making irrevocable changes even if they accidentally do something bad. So, first decide which operations need to be undoable [Tidwell, 02]: Any action that might change a file (i.e. anything that could be permanent) should be undoable, while transient or view-related states often are not. In any case, make sure the undoable operations make sense to the user. They can be specific functions or a meaningful group of actions (for example, changing the printer settings) [Welie, 03]. Be sure to define and name them in terms of how the user thinks about the operations, not how the computer thinks about them. Warnings If a command has side effects that cannot be undone, warn the user before executing the command and do not queue it [Welie, 03] Redo Users tend to explore a navigable artefact in a tree-like fashion, going down paths that look interesting, then back up out of them, then down another path [Tidwell, 99]. So, an undo stack will need to be created. Each operation goes on the top of the stack as it is performed; each Undo reverses the operation at the top, then the next,... The undo concept must also include the concept of redo needed in case the user backs up too many steps [Laasko, 03]. Redo works its way back up the stack in a similar manner. The best undo should preserve the tree structure of the command execution sequence. W_ELAB-6: Warnings: Authorization Most likely a warning of the type Autorization will be required. See warning pattern for the warning process. W_ELAB-7: Redo: Availability Redo should only revert the effects of the latest applied Undo. Some existing software currently use the Redo feature as a way to repeat the execution of any command. In the way in which we refer to it here, we strictly mean Redo as a way to revert a previously executed Undo. In this context, when no Undo command has been executed, Redo should not be available W_Q-12 Of the damaging actions that cannot be undone, which will require a warning to be displayed to the user? W_EX-8: File deletion w/warning If deleting a file from a hard drive is an undoable operation, the user will need to be warned (OK - Cancel style authorization) before the deletion is carried out. W_EX-9: Redoing in MS Word When undoing the changing of the font of a paragraph in MS Word, executing Redo will revert the text to its original font (before executing undo) Elaboration W_ELAB-5: Choosing undoable actions All actions with important consequences should provide the undo feature, save for those for which there are greater impeding factors present. For actions which are expensive to revert, The cost/benefit ratio of providing it with an undo feature should be evaluated. The term important consequences must be clearly defined before deciding which actions will be undoable. Discussions with Stakeholders W_Q-9 Which user actions are considered to have important consequences? W_Q-10 Of these actions, which will support undo? W_Q-11 How will the user be provided access to the undo functionality? Usage Examples (optional) W_EX-7: Costly vs. undoable actions Deleting a file from a system will most likely have important consequences and should be undoable Sending an email has important consequences (the email reaches the other party), but it is not directly undoable. Only such a limitation should keep a system from providing the undo feature. Deleting files from a hard drive, though undoable, tends to be an expensive operation to revert.
W_Q-13 Will a redo functionality be provided? W_Q-14 How will the user be provided access to the redo functionality?
Jos Germn Nez Mori
Pgina 179 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation History Often users want to reverse several actions instead of just the last action [Welie, 03]. So, the stack should be at least 10 to 12 items long to be useful, and longer if you can manage it. Long-term observation or usability testing may tell you what your usable limit is (Constantine and Lockwood assert that more than a dozen items is usually unnecessary, since users are seldom able to make effective use of more levels. Expert users of high-powered software might tell you differently. As always, know your users. Most desktop applications put Undo/Redo items on the Edit menu. Show the history of commands so that users know what they have done [Wellie, 03]. Undo is usually hooked up to Ctrl-Z or its equivalent Smart Menus The most well-behaved applications use Smart Menu Items to tell the user exactly which operation is next up on the undo stack. W_ELAB-9: Smart Menus and History Smart menus are tightly related to the command history (stack). If one is kept, its relatively simple to offer smart menus different functionalities. W_Q-18 Will the user have information about the expected outcome of performing undo at any given time (smart menu)? W_Q-19 If so, how will this information be provided to the user? Object Specific Undo The software system must provide the possibility for the user to easily access (for example, through the right button) the specific commands that affect such an object. One should be the undo/redo function. In this case, the system should filter the global undo stack and show only the operations that affected the state of the selected object [Laasko, 03]. W_ELAB-10: Object Global Undo Specific Undo & W_Q-20 Which system elements will require object-specific undo/redo? W_Q-21 How will this feature be accessed by the user? W_EX-11: Smart Menus in drawing program When the last performed operation in a drawing program was paint red, the undo menu, or equivalent, should display undo paint red as opposed to the more generic undo W_EX-12: UML Design Program In a UML design program, selecting the graphic representation of a cCass within a diagram whould should provide the option to undo the operations performed on (and only on) this particular Class. Elaboration W_ELAB-8: History: Stack size and type Ideally undo/redo should use a tree structure instead of a stack structure to keep record of the actions, however the tree structure requires an important coding effort, so have this in mind when determining which kind of structure will be needed to keep record of the actions to be undone/redone. Notice that the system may have a global stack with a concrete size, or depending on the system, the size of the stack may be different for different functionalities. Discussions with Stakeholders W_Q-15 How many levels of undo and/or redo will be provided? W_Q-16 Will the user have access to the undo stack (history)? W_Q-17 If so, how will the user be presented with the undo stack? Usage Examples (optional) W_EX-10: MS Words undo Stack MS Word and others provide users with a visual list (stack) of the latest opperations executed within the application. Within this stack, users can not only view the operations in the order in which they would be undone, but they can select an operation deep within the stack and undo it, along with every operation that was executed after it.
Redo will only be available at object level if it is available globally. Same with undo.
Table 3: Undo. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 180 de 237
Figure 10: Undo. Use Case Model
Jos Germn Nez Mori
Pgina 181 de 237
Figure 11: Undo. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 182 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES System Responsibility W_SR-14 Support Undo functionality (storing, undoing) Generic Component Responsibilities The component responsible for handling user events (UI) must listen for calls to actions and order their execution Execution of actions is always the responsibility of the pertinent Domain Component in the application The component in charge of delegating actions (if any) should determine whether the action is undoable or not, from a pre-established list. If the action to execute is undoable, it must first be encapsulated as an instance of a Command Component, together with any pertinent state information and the necessary actions needed to revert its effects. Such an instance is then stored in a History Component, responsible for keeping a single (ordered) collection of all executed undoable actions. After encapsulation, the Domain Component is then free to execute the invoked action The UI Component must listen for calls to the Undo action (if available) and order its execution The History Component must then retrieve the last* Command, without discarding it, and order it to undo itself. The Command, in turn, executes the necessary actions, using the stored state information, to return the system to the state preceding its execution W_SR-15 Provide user access to Undo W_SR-16 Support Redo functionality The UI Component is responsible for providing the mean(s) through which a user can invoke the undo feature. The Undo action should only be available when at least one undoable action has been executed during application up-time The UI Component must listen for calls to the Redo action (if available) and order its execution The History Component must then retrieve the current** Command, without discarding it, and order it to redo itself. The Command, in turn, executes the necessary actions, using the stored state information, to return the system to the state that follows its execution W_SR-17 Provide user access to Redo W_SR-18 Support Multi-Level Undo and History The UI Component is responsible for providing the mean(s) through which a user can invoke the redo feature. The Redo action should only be available when the Undo action has been executed at least once before during application up-time. When only one-level undo is supported, the History component holds only the last-executed action. However, when multi-level undo is supported, History supports an ordered collection of said actions in the form of Commands, as described in W_SR-14 The History Component is also responsible for updating (or ordering the update of) the UI every time a new Command is added to the collection or whenever the next undoable/re-doable action changes, as described in W_SR-19 W_SR-19 Provide expected results of Undo/Redo W_SR-20 Allow Object-Specific Undo/Redo Whenever the Undo and/or Redo actions are available, the UI Component is responsible for showing the actions expected results (smart menus) The UI gets this information from the History Component, which must notify it of the current undoable/re-doable action upon every change. The UI Component must listen for calls to the Undo/Redo action over a particular object (if available) and order its execution. The History Component must then retrieve the last*/current** Command executed over that object, without discarding it, and order it to Undo/Redo itself. The Command, in turn, executes the necessary actions, using the stored state information, to return the object to the state preceding/following its execution.
Jos Germn Nez Mori
Pgina 183 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-21 Provide Undo functionality (storing/undoing) 1. The View must listen for invocation of actions. Upon reception, it must notify the Controller of said action Controller 2. The Controller must determine if the invoked action is undoable. In such case it must call the execute() method of the corresponding ConcreteCommand object (otherwise invocation goes directly to the DomainClass). 3. The Controller must then clone() said ConcreteCommand and add() it to the HistoryList. 1. The View must listen for invocation of the Undo action. Upon reception, it must notify the Controller. W_SR-22 Provide user access to Undo 1. The View must present the user with the mean(s) to call the Undo action (i.e. within the Edit menu, through Ctrl-Z, etc.) 1. The View must listen for invocation of the Redo action. Upon reception, it must notify the Controller. 1. The View must present the user with the mean(s) to call the Undo action (i.e. dit menu, Ctrl-Z, etc.) 2. The Controller orders the HistoryList to redo the current action. 4. Upon call to its redo() method, the ConcreteCommand calls the necessary methods in DomainClass (with any needed state information, stored upon execution) to reinstate its effects. 3. The HistoryList determines the ConcreteCommand to redo and calls its redo() method. 5. The DomainClass executes the methods invoked by ConcreteCommand. 2. The Controller orders the HistoryList to undo the last action. Objects ConcreteCommand 4a. Upon call to its execute() method, the ConcreteCommand first stores the necessary state information in its local variables. It then calls the appropriate method in the corresponding DomainClass (what was originally invoked) HistoryList 4b. The HistoryList saves the cloned ConcreteCommand atop its collection (so it can later be available to undo) DomainClass 5a. The DomainClass executes the appropriate method to carry out what was originally invoked by the user through the View. 3, 4 Fig
4. Upon call to its undo() method, the ConcreteCommand calls the necessary methods in DomainClass (with any needed state information, stored upon execution) to revert its effects.
3. The HistoryList determines the ConcreteCommand to undo and calls its undo() method.
5. The DomainClass executes the methods invoked by ConcreteCommand.
3, 5
3, 5
W_SR-23 Support Redo functionality
3, 6
W_SR-24 Provide user access to Redo
3, 6
Jos Germn Nez Mori
Pgina 184 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-25 Support MultiLevel Undo and History 3. When the View is notified of changes in the HistoryList it updates its History Displays accordingly. Controller Objects ConcreteCommand HistoryList 1. The HistoryList stores (clones of) ConcreteCommands in a FILO-ordered collection. It keeps a pointer of the last action that was invoked, and moves it back every time an Undo is invoked until no more ConcreteCommands exist. Invoking Redo moves the pointer forward in a similar fashion. ConcreteCommands are never removed from the HistoryList, except when its maximum allowed size is reached (in which case the older elements will be removed in order). 2. Every time a ConcreteCommand is added to the HistoryList or the pointer changes position (i.e. the next undoable/re-doable action is updated), the HistoryList notifies the View W_SR-26 Provide expected results of Undo/Redo 2. When the View is notified of changes in the HistoryList it updates its next undoable/redoable 1. The View must listen for invocation of the Undo/Redo action over a specific object. Upon reception, it must notify the Controller. 2. The Controller orders the HistoryList to undo/redo the last action invoked over said object. 4. Upon call to its undo()/redo() method, the ConcreteCommand calls the necessary methods in DomainClass (with any needed state information) to revert/reinstate its effects. 1. Every time a ConcreteCommand is added to the HistoryList or the pointer changes position (i.e. the next undoable/redoable action is updated), the HistoryList notifies the View 3. The HistoryList determines the ConcreteCommand to undo/redo by scanning the collection for the latest/current one invoked over the object and calls its undo() method. 5. The DomainClass executes the methods invoked by ConcreteCommand. 3, 5, 6 DomainClass 3, 4, 5, 6 Fig
W_SR-27 Allow ObjectSpecific Undo/Redo
3, 5, 6
Jos Germn Nez Mori
Pgina 185 de 237
Figure 12: Undo. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 186 de 237
Figure 13: Undo. Usability-enabling design pattern. Sequence Diagram Execute Action (W_SR-1)
Jos Germn Nez Mori
Pgina 187 de 237
Figure 14: Undo. Usability-enabling design pattern. Sequence Diagram Undo Action (W_SR-1, W_SR-22, W_SR-24, W_SR-26 and W_SR-27)
Jos Germn Nez Mori
Pgina 188 de 237
Figure 15: Undo. Usability-enabling design pattern. Sequence Diagram Redo Action (W_SR-23, W_SR-24, W_SR-25, W_SR-26 and W_SR-27)
Jos Germn Nez Mori
Pgina 189 de 237
Anexo 04: Especificacin Patrn de Usabilidad Abort
Jos Germn Nez Mori
Pgina 190 de 237
USABILITY-ENABLING GUIDELINE Identification Name Family Aliases Intent Providing the means to cancel an on-going command or operation, or to allow for exiting the application altogether Problem Certain commands or operations might take a long time to execute. In such cases, the user will need to be at the liberty to cancel them. S/he must also be allowed to exit an application at all times, regardless of any tasks that may be being executed. Context When the user needs to exit an application or a command quickly.
Abort
Undo/Cancel Emergency Exit [Brighton, 1998]; Go Back to a Safe Place [Tidwell, 1999]; Go Back [Tidwell, 1999]; Prominent Cancel [Tidwell, 02]
Jos Germn Nez Mori
Pgina 191 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Cancelling Commands Si un comando tarda ms de 10 segundos (**Ha desaparecido de la referencia y contradice referencias nuevas del progress (gnome) donde ponen opcion de cancel para todos los progress.**) en ejecutarse, proveer opcin de Cancelar (adems de la informacin sugerida por el mecanismo Progress Feedback) para permitir la interrupcin de su procesamiento y el regreso al estado anterior [Nielsen, 93]. W_ELAB-11: Elaboration Identificacin/Seleccin Discussions with Stakeholders Qu comandos requerirn la opcin de cancelar? Para los comandos listados en 0 Cmo debe presentarse al usuario la opcin de cancelar? Para cada una de los comandos listados en 0 A qu estado pasar el sistema luego de que el usuario elija la opcin de cancelar? Usage Examples (optional) W_EX-13:
Se entiende por comando una tarea indivisible invocada por el usuario. Es necesario identificar los comandos potencialmente largos (>10s). Solo estos sern cancelables por el usuario. Comandos ms cortos no sern cancelables, aunque para los >2s se muestre su progreso (ver Progres Feedback) En caso de que no resulte viable listar todos los comandos >10s, listar solo aquellos que requieran atencin especial y para el resto definir un comportamiento estndar (por defecto) de cancelacin Una vez identificados los comandos potencialmente largos deber consultrsele al usuario si existe alguno excepcional para el cual no deba darse la opcin de cancelar. Es importante destacar en esta discusin que la recomendacin HCI indica que todos estos comandos deberan ser cancelables, pero es necesario permitirle al usuario hacer excepciones en casos puntuales que as lo requieran W_ELAB-12: Presentacin
Existen maneras standar y simples de cancelar comandos (i.e. botn X, ctrl-c, etc.) Discutir con el usuario solamente si tiene alguna necesidad especfica para alguno de los comandos. AO_E4: Control de Regreso a Estado Al cancelar un comando es necesario deshacer (automticamente) los efectos que ste pueda haber tenido hasta el momento.
Jos Germn Nez Mori
Pgina 192 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Cancelling Operations Si el usuario entra en un espacio o estado en el cual no quiere estar, necesitar poder salir de el de manera segura y predecible. Adems, hacer backgracking a lo largo de mltiples estados consecutivos puede resultar tedioso [Tidwell, 99]. Por esta razn, en aplicaciones basadas en ventanas (GUI), es estndar tener un botn de Cancel que cierre la ventana de dilogo actual y descarte cualquier cambio hecho por el usuario dentro de la misma. W_ELAB-13: Elaboration Identificacin/Seleccin Discussions with Stakeholders Qu operaciones requieren la opcin de cancelar? Usage Examples (optional) W_EX-14:
Se entiende por operacin cualquier interaccin realizada en sub-ventanas (generalmente de mltiples pasos ) Toda operacin deber ser cancelable, permitiendo al usuario salir de la sub-ventana desechando los cambios (si los hubiese). Discutir con el usuario si existe alguna que por algn motivo excepcional no deba serlo. En caso de que no resulte viable listar todas las operaciones cancelables, listar solo aquellas que requieran atencin especial y para el resto definir un comportamiento estndar (por defecto) de cancelacin W_ELAB-14: Presentacin Para las operaciones listadas en 0 Cmo debe presentarse al usuario la opcin de cancelar? W_EX-15:
Discutir con el usuario si tiene alguna necesidad especifica en cuanto a la presentacin de la opcin de cancelar operaciones ejecutadas desde sub-ventanas. De lo contrario utilizar el botn de Cancelar estndar. AO_E4: Control de Regreso a Estado Al cancelar una operacin se presentan dos posibles escenarios: La operacin a cancelar ha consistido (al momento de la cancelacin) nicamente de navegacin entre pasos. La cancelacin de este tipo de operaciones consistir nicamente en salir de la sub-ventana correspondiente. La operacin a cancelar ha provocado cambios en el estado del sistema. En este caso, la cancelacin deber, adems de salir de la sub-ventana, deshacer dichos cambios, regresando al sistema al estado previo a la invocacin de la operacin (ver Step-by-step)
Para cada una de las operaciones listadas en 0 A qu estado pasar el sistema luego de que el usuario elija la opcin de cancelar?
W_EX-16:
Exiting the application Aquellos usuarios que utilizan un gran nmero de aplicaciones simultneamente pueden necesitar
W_ELAB-15:
Presentacin de opcin de salir
Dnde y cmo se presentar al usuario la opcin de Salir?
Discutir con el usuario si tiene alguna necesidad especifica en cuanto a la presentacin de la opcin de Salir de la aplicacin. De lo contrario utilizar estndar del OS/lenguaje
(i.e. botn rojo X arriba-derecha en windows)
Jos Germn Nez Mori
Pgina 193 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation salir de un programa rpidamente cuando alguna tarea de mayor prioridad necesite los recursos del sistema, o cuando se haya iniciado el programa por error [Brighton, 98]. Por esta razn, a nivel de aplicacin, es necesario garantizar que la opcin de salir del programa est siempre claramente disponible (incluso durante el inicio del programa) y que sta nunca sea bloqueada por ventanas de dialogo. Si se elige la opcin de Salir luego de haber manipulado datos, se debe presentar la opcin de Guardar Cambios W_ELAB-16: Elaboration Manejo de Cambios Discussions with Stakeholders Se desea presentar al usuario la opcin de Guardar Cambios? Usage Examples (optional) W_EX-17:
Generalmente la opcin de guardar cambios es relevante en aplicaciones que modifican archivos o registros durante su ejecucin. El mensaje de alerta que indica al usuario que existen cambios por guardar generalmente se muestra como un warning de tipo confirmation al usuario (Ver Warning) W_ELAB-17: Presentacin de opcin Guardar Cambios Discutir con el usuario si tiene alguna necesidad especifica en cuanto a la presentacin de la opcin de Guardar Cambios. De lo contrario utilizar estndar del OS/lenguaje W_ELAB-18: Culminacin de operaciones y comandos En cuanto a detener los comandos/operaciones en ejecucin al momento de salir existen varias alternativas: Salida Inmediata: Abortar todas las tareas (descartando sus resultados) y cerrar la aplicacin sin consultar al usuario. Delegacin de Control: Cediendo el control a los comandos u operaciones activos en ese momento antes de cerrar definitivamente la aplicacin. Espera: Preguntar al usuario si est seguro de que desea salir, abortando todas las tareas en ejecucin. Si responde que s, se cancelarn inmediatamente todas las tareas de la manera estndar establecida. Consulta: Dar al usuario la opcin de elegir entre los modos de salida a, b y c
Si la respuesta a 0 es afirmativa: Dnde y cmo se presentar la opcin de Guardar Cambios?
W_EX-18:
Si al seleccionar la opcin de salir existen operaciones/comandos en ejecucin Como se manejar la culminacin de los mismos (a,b,c o d)?
W_EX-19:
Table 4: Abort. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 194 de 237
Figure 16: Abort. Use Case Model
Jos Germn Nez Mori
Pgina 195 de 237
Figure 17: Abort. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 196 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES System Responsibility W_SR-28 Identify cancellable commands W_SR-29 Cancel commands and handle application state Generic Component Responsibilities A software component, preferably that responsible for handling user events (UI), must know of all the commands that are cancellable. By being in charge of this responsibility, it will be able to display the necessary interface components to provide the user with the means to cancel said command. The UI must listen for user calls to cancel ongoing commands The component in charge of delegating actions (if any) is responsible for knowing which thread is running the command being cancelled and to order it to stop, as well as ordering the History Component (see Undo) to undo any effects caused by said command, returning the application to its original state. The History Component must then retrieve the last* Command, without discarding it, and order it to undo itself. The Command, in turn, executes the necessary actions, using the stored state information, to return the system to the state preceding its execution W_SR-30 Identify cancellable operations W_SR-31 Cancel operations and handle application state W_SR-32 Exit application handling potential on-going commands/operations A software component, preferably that responsible for handling user events (UI), must know of all the operations that are cancellable. By being in charge of this responsibility, it will be able to display the necessary interface components to provide the user with the means to cancel said command. At any point during operation execution, the user must be allowed to cancel (exit it). When doing so, any actions saved to History (if applicable) during operation execution, must be undone by the same component regularly in charge of saving/undoing operations--the delegating component (if any)--and the UI components for the wizard discarded. (See Step-by-Step Cancel Wizard) When exiting the application, any on-going commands and/or operations must be dealt with. The UI must listen for calls to exit the application If there are no on-going commands or operations, the application will exit immediately If there are on-going commands and/or operations, but the UI does not need to prompt the user for the type of exit s/hed like to make, the UI must order all commands and/or operations to be dealt with in one of three ways (through an invoking component, if any): A) All on-going commands and/or operations will be cancelled immediately in the same manner (re: state retrieval) in which they are cancelled by users B) All on-going commands and/or operations will be allowed to finish execution, in which case the UI will wait until the last one notifies it has finished C) All on-going commands and/or operations will be terminated immediately (disregarding state) and the application closed. It is the UIs responsibility to know whether or not to prompt the user for an exit type. If no prompt is made, it is also the UIs responsibility to be aware of which type of exit it needs to make (i.e. the way in which commands and operations will be dealt with upon exiting). W_SR-33 Handle potential changes to be saved When the UI receives a call to exit the application, the component in charge of delegating actions (if any) should first ask a SaveComponent (see below) if there exist any pending changes before exiting A SaveComponent is responsible for determining whether there are changes to be saved and to order such saves. If there are changes pending to be saved, the delegating component will inform the UI, which in turn should prompt the user to save said changes These changes will be saved by the SaveComponent if requested
Jos Germn Nez Mori
Pgina 197 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-34 Identify cancellable commands W_SR-35 Cancel commands and handle application state 1. The View must listen for calls to commands. It must be aware of which of these are cancellable and provide the appropriate GUI components to enable cancellation. 1. The View must listen for invocation of actions, doAction(). Upon reception, it must notify the Controller of said action 2. The Controller must determine if the invoked action is cancellable. In such case it must call the execute() method of the corresponding ConcreteCommand object (otherwise invocation goes directly to the DomainClass), keeping a record of the thread_id in which doAction() is being executed. 3. The Controller must then clone() said ConcreteCommand and add() it to the HistoryList. 1. The View must listen for invocation of cancel() for a given thread. Upon reception, it must order the Controller to terminate said thread. 7. The View must discard any ProgressIndicators upon notification, and also update any Smart Menus or History Displays (See Undo) 2. The Controller orders the thread in which doAction() is being executed and orders it to stop(). It then orders the HistoryList to undo the last action for the corresponding DomainObject o. 4. Upon call to its undo() method, the ConcreteCommand calls the necessary methods in DomainClass (with any needed state information, stored upon execution) to revert its effects. 3. The HistoryList determines the ConcreteCommand to undo and calls its undo() method. 5. The DomainClass executes the methods invoked by ConcreteCommand. 6. The thread in which the DomainClass resides will then notify this to any existing ProgressIndicators (see Progress Feedback). 3, sbs 4a. Upon call to its execute() method, the ConcreteCommand first stores the necessary state information in its local variables. It then calls the appropriate method in the corresponding DomainClass (what was originally invoked) 4b. The HistoryList saves the cloned ConcreteCommand atop its collection (so it can later be available to undo) 5a. The DomainClass executes the appropriate method to carry out what was originally invoked by the user through the View. Controller Objects ConcreteCommand HistoryList DomainClass 3, 4 Fig
3, 4, 5
W_SR-36 Identify cancellable operations
1. The View must listen for calls to operations (See Step-by-step). It must be aware of which of these are cancellable and provide the appropriate GUI components to enable cancellation.
Jos Germn Nez Mori
Pgina 198 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-37 Cancel operations and handle application state 1. At any point during operation execution, the user must be allowed to cancel(), exiting the operation. The View will pass this order to the Controller. 3. Once cancelled the window(s) in which the operation was being carried out must be discarded by the View. 1. The View must listen for calls to exit()the application and determine if the user must be prompted for the type of exit to make. 2a. If so, the View prompts the user, whom responds with one of three possibilities (cancel all, wait to finish or immediate exit) 2b. If not, the View must simply forward said call to the Controller, along with what it knows to be the appropriate exit type . 3. Upon Controller notification, the View will kill the GUI and exit. W_SR-39 Handle potential changes to be saved 1. The View must listen for calls to exit() and forward the call to the Controller 3. If there are changes to be saved, the View prompts the user. Upon okaying, the View orders the Controller to saveChangesAndExit() Controller 2. Whenever a call to cancel() is received, the Controller must order to undo every action in the HistoryList related to the current operation (See Step-by-step). Objects ConcreteCommand HistoryList DomainClass 3, sbs Fig
W_SR-38 Exit application handling potential on-going commands/ operations
3. The Controller then procedes to handle commands and operations according to the exit type. The Controller will a) order all commands and operations to be cancelled as described in (W_SR-35 and W_SR-37), and notify the View b) wait until all ongoing commands/operations notify it they have finished and then notify the View, or, c) simply notify the View 2. The Controller asks the SaveManager if there are pendingChanges(). If so, the Controller notifies the View. Otherwise, execution of continues as described in W_SR-38 4. The Controller, in turn, asks the SaveManager to saveChanges() (due to space constraints, the SaveManager class is implied in this table)
3, 6
3, 6
Jos Germn Nez Mori
Pgina 199 de 237
Figure 18: Abort. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 200 de 237
Figure 19: Abort. Usability-enabling design pattern. Sequence Diagram Execute command (W_SR-34)
Jos Germn Nez Mori
Pgina 201 de 237
Figure 20: Abort. Usability-enabling design pattern. Sequence Diagrams Cancel command (W_SR-32)
Jos Germn Nez Mori
Pgina 202 de 237
Figure 21: Abort. Usability-enabling design pattern. Sequence Diagrams Cancel operation (W_SR-38 and W_SR-39)
Jos Germn Nez Mori
Pgina 203 de 237
Anexo 05: Especificacin Patrn de Usabilidad System Progress Feedback
Jos Germn Nez Mori
Pgina 204 de 237
USABILITY-ENABLING GUIDELINE Identification Name Family Aliases Intent Provide the user with accurate visual feedback on the progress of the current task Problem Certain system tasks will take a long time to execute. The user needs to be informed of how much time remains in said tasks to s/he can make informed decisions in terms of whether to wait for the task to finish, cancel it, etc. Context When a time-consuming process interrupts the UI for longer than two seconds or so: [Tidwell, 02]
System Progress Feedback (SPF)

Feedback Alias: Progress Indicator [Tidwell, 99] [Tidwell, 02]; Progress [Welie, 03]; Show Computer is Thinking,;Time to Do Something Else [Brighton, 98]; Modelling Feedback Area [Coram, 96]
205
Jos Germn Nez Mori
Pgina 205 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE HCI Recommendation Progress Information Types Show an animated indicator of how much progress has been made. Either verbally or graphically (or both). For tasks that take a long time (typically more than a few seconds) [wellie article PLoP2k-Welie.pdf][gnome 2.2], tell the user [7] [8]: Whats currently going on, What proportion of the operation is done so far, How much time remains, and How to stop it (or cancel it) if the time remaining is longer than 10 seconds [11]. About the remaining time [9]: If the timing can be calculated, give an indication of the time remaining, either as a figure, or graphically, use either a Time-remaining Progress Indicator or a Proportion-completed Progress Indicator [11]; if timing can not be estimated, but the process has identificable phases, give an indication of the phases completed, and of the pahses remaining. Use a Progress Checklist [11]; if neither of these possibilities exist, then at least indicate the number of units processed (records, vectors ....); if no quantities are known just that the process may take a while- then simply show some indicator that its still going on [7] [8], use an Indeterminate Progress Indicator [11]. Verify that the application takes no longer than 1 second to display the progress indicator [11]; and update the feedback at a rate that gives the user the impression that the operation is still being performed, e.g. every 2 seconds [10] Elaboration W_ELAB-19: Indeterminate progress When a progress bar is first displayed the progress information might not be immediately available. If this is the case, and indeterminate progress indicator should be shown (in place of the determinate indicator) until accurate progress information can be calculated and displayed If progress cannot be refreshed every 2 seconds, an alternate (indeterminate) progress indicator should be visible to reassure the user that the task is still executing W_Q-22 Discussions with Stakeholders Which tasks are likely to take more than a few seconds (2 to 5) to complete, needing progress information to be displayed? For which of these can actual progress be calculated? For those whose progress can be calculated, which can provide the following information? Identifiable phases completed Time remaining for completion Units processed Percentage completed For any remaining tasks (whose progress cannot be calculated) what kind of indeterminate progress indicator will be shown to the user? For which tasks will a cancel option be provided to the user? For the tasks listed above, how will the cancel option be provided? For every task, what textual information (if any) will be shown to the user, together with the progress indicator? Usage Examples (optional) W_EX-20: Feedback Examples As part of operating system behavior, progress bars are shown when copying large amounts of data within the hard drive or out to an external device. A cancel button (or the option to cancel through command-. for shorter processes) is also provided. The Mac OS progress bar will initially display a dialogue window with an indeterminate bar and a calculating message. Once the remaining time is calculated it is displayed together with a determinate progress bar and the number of files remaining to be copied (SPF_3 parts 2, 3 and 4). Most software installers, particularly those that entail a long process like OS installers, provide the phases completed (SPF_3 1) information, together with multiple other forms of feedback. A checklist where completed phases are ticked off is most common when providing this type of feedback.
W_Q-23 W_Q-24
W_Q-25 W_Q-26 W_Q-27 W_Q-28 W_Q-29
W_Q-30 W_Q-31 W_Q-32
Table 5: System Progress Feedback. Usability Elicitation Guideline
206
Jos Germn Nez Mori
Pgina 206 de 237
Figure 22: System Progress Feedback. Use Case Model
207
Jos Germn Nez Mori
Pgina 207 de 237
Figure 23: System Progress Feedback. System Responsibility Clusters 208
Jos Germn Nez Mori
Pgina 208 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES System Responsibility W_SR-40 Calculate and provide progress information Generic Component Responsibilities The UI Component is responsible for knowing (from a pre-established list) whether an invoked action is among those that could potentially be long (>2s) and order their execution. If the action is among the potentially long, the UI must call unto an alternate Monitoring Component (preferably residing in a different thread) to determine when the allowed time (2s) has elapsed. When/if it does, the UI must start to display progress information (through a separate Progress Component, if needed) The component in charge of delegating actions (if any) is responsible for determining the Domain Component responsible for executing the invoked action and ordering it to do so. The Domain Component executing the action is responsible for continually notifying interested parties (namely the UI and/or Progress Components) of the progress achieved and, eventually, its end. The UI and/or Progress Components are responsible for keeping the user up to date on the progress, based on notifications from the Domain Component. W_SR-41 Provide cancel option W_SR-42 Provide textual information W_SR-43 Provide indeterminate progress information The component responsible for displaying the progress (be it the UI or an alternate Progress Component) must provide a cancel option for the actions it knows to require one (> 10s) The component responsible for displaying progress must also know of and display any needed textual information along with the progress details. When the UI component (or alternate Progress Component) first displays the progress, it must do so indeterminately until it receives the first real progress update from the Domain Component.
209
Jos Germn Nez Mori
Pgina 209 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC) System Responsibility View W_SR-44 Calculate and provide progress information 1. The View must listen for invocation of actions and must determine (from a preexisting list) if the action being called could be potentially long. 2. If so, aside from notifying the Controller of said action, it must ask the Monitor class to wait a specified amount of time (2s) 5. If the view is still waiting for the invoked action to return after Monitor responds, it starts up a ProgressIndicator (thread). 9. Whenever the ProgressIndicator notifies the View of new progress, the View will update the GUI 12. When the ProgressIndicator notifies the View that the progress has ended, it updates the GUI accordingly (no longer displaying the indicator) W_SR-45 Provide cancel option 1. When the View creates the ProgressIndicator it does so indicating via a boolean parameter whether the indicator will be cancellable or not 1. When the View creates the ProgressIndicator it must pass it the textual information to display 1. Whenever a ProgressIndicator (that is not undetermined) is created, the view will initially paint it as indeterminate until the first progress update is received. Objects ProgressIndicator 6. The ProgressIndicator suscribes to the corresponding DomainClass for progress information. 8. Upon reception of progress information, the ProgressIndicator updates the progress, performing any needed calculations to do so. It notifies the View. 11. When ProgressIndicator receives a notification that the action being executed has ended it sets the progress to competed and notifies the View. Monitor 3a. The Monitor class starts up a clock and notifies the view after the time (2s) has elapsed. Controller 3b. The Controller invokes the action, calling the appropriate class. DomainClass 4. The DomainClass starts executing the invoked action 7. The DomainClass notifies its subscribers (namely the ProgressIndicator) of its progress 10. When the action is completed, DomainClass sends out a notification 3, 4 Fig
2. Depending on the parameter passed, the ProgressIndicator will enable a cancel button or not. 2. The ProgressIndicator holds this text and displays it alongside the progress information
3, 4 3, 4 3, 4
W_SR-46 Provide textual information W_SR-47 Provide indeterminate progress information
210
Jos Germn Nez Mori
Pgina 210 de 237
Figure 24: System Progress Feedback. Usability-enabling design pattern. Class diagram
211
Jos Germn Nez Mori
Pgina 211 de 237
Figure 25: System Progress Feedback. Usability-enabling design pattern. Sequence Diagram Display progress (W_SR-40, W_SR-41, W_SR-42, W_SR-43) 212
Jos Germn Nez Mori
Pgina 212 de 237
Anexo 06: Patrones de Usabilidad en la Elicitacin
213
Jos Germn Nez Mori
Pgina 213 de 237
Usability Elicitation Patterns (USEPs)

Natalia Juristo1, Ana Moreno1, Maria-Isabel Sanchez-Segura2 School of Computing - Universidad Politcnica de Madrid, Spain natalia@fi.upm.es; ammoreno@fi.upm.es 2 Department of Computing - Universidad Carlos III de Madrid, Spain misanche@inf.uc3m.es
1
August 2006
USEPs capitalize upon the know-how in elicitation so that requirements engineers can reuse key usability issues intervening recurrently in different projects. We have developed one USEP for each usability mechanisms in the following table. USEPs support developers to extract all the necessary information to completely specify a functional usability feature.
Usability Feature Feedback
Usability Mechanism
Goal To inform users about the internal status of the system To inform users that the system has registered a user interaction, i.e., that the system has heard users To inform users of any action with important consequences To inform users that the system is processing an action that will take some time to complete To undo system actions at several levels To undo several actions on an object To cancel the execution of an action or the whole application To go back to a particular state in a command execution sequence To help prevent the user from making data input errors
System Status Interaction Warning Long Action Feedback Global Undo ObjectSpecific Undo Abort Operation Go Back Structured Text Entry Step-by-Step Execution Preferences Personal Object Space Favourites
Undo Cancel
User Input Errors Prevention/ Correction Wizard
To help do tasks that require different steps with user input and correct such input To record each user's options for using system functions To record each user's options for using the systems interface. To record certain places of interest for the user 214
User Profile
Jos Germn Nez Mori
Pgina 214 de 237
Help Commands Aggregation
Multilevel Help Commands Aggregation
To provide different help levels for different users To express possible actions to be taken with the software through commands that can be built from smaller parts.
We have used HCI literature as a source of information. Then we have analysed the information provided from a development perspective. Finally, we have elaborated this information to get a set of issues to be discussed with stakeholders. USEP for the System Status Feedback mechanism
IDENTIFICATION: Name: System Status Feedback Family: Feedback Alias: Status Display [7] Modelling Feedback Area [2] PROBLEM Which information needs to be elicited and specified para que la aplicacin provide users with system status information. CONTEXT When changes that are important to the user occur or When failures that are important to the user occur: During task execution Because there are not enough system resources Because external resources are not working properly. Examples of status feedback can be found in status bars on windows applications; train, bus or airline schedule systems; VCR displays; etc. SOLUTION Usability Mechanism Elicitation Guide: HCI Recommendation 1. HCI experts argue that the user wants to be notified when a change of status occurs [7] Issues to be discussed with stakeholders Changes in the system status can be triggered by userrequested or other actions or when there is a problem with an external resource or another system resource. 1.1 Does the user want the system to provide notification of system statuses?. If so, which ones? 1.2 Does the user want the system to provide notification of system failures (they represent any operation that the system is unable to complete, but they are not failures caused by incorrect entries by the user)? If so, which ones? 1.3 Does the user want the system to provide notification if there are not enough resources to execute the ongoing commands? If so, which resources? 1.4 Does the user want the system to provide notification if there is a problem with an external resource or device with which the system interacts? If so, which ones? For each situation identified above under item 1, discuss with the user: 2.1. Which information will be shown to the
2. Well-designed displays of the information to be shown should be chosen. They need to be unobtrusive if the information is not critically important, but obtrusive if something important
215
Jos Germn Nez Mori
Pgina 215 de 237
happens. Displays should be put together in a way that emphasizes the important things, deemphasizes the trivial, doesnt hide or obscure anything, and prevents one piece of information from being confused with another. They should never be re-arranged, unless users do so themselves. Attention should be called to important information with bright colours, blinking or motion, sound or all three but a technique appropriate to the actual importance of the situation to the user should be used [7].
user? 2.2. Which of this information will have to be displayed obtrusively because it is related to a critical situation? Represented by a salience in the main display area that prevents the user from continuing until the salient information is closed. 2.3. Which of this information will have to be highlighted because it is related to an important but not critical situation? Using different colours and sound or motion, sizes, etc. 2.4. Which of this information will be simply displayed in the status area? Locating some kind of salience in the system status area. For each piece of system status information to be displayed according to its importance, the range will be from obtrusive things (for example, a window in the main display area which prevents the user from continuing until it has been closed), through highlighting (with different colours, sound, motion or sizes) to the least eye-catching things (like a status-identifying icon placed in the system status area). Note that during the requirements elicitation process, the discussion of the exact response type can be left until interface design time, but the importance of the different situations about which status information is to be provided and, therefore, the general type of salience (obtrusive, highlighted or standard) that will be provided does need to be discussed at this stage.
As regards the location of the feedback indicator, HCI literature mentions that users want one place where they know they can easily find this status information [2]. On the other hand, aside from the spot on the screen where users work, users are most likely to see feedback in the centre or at the top of the screen, and are least likely to notice it at the bottom edge. The standard practice of putting information about changes in state on a status line at the bottom of a window is particularly unfortunate, especially if the style guide calls for lightweight type on a grey background References 3. [1]. The positioning of an item within the status display should be used to good effect. Remember that people born into a European or American culture tend to read left-to-right, top-to-bottom, and that something in the upper left corner will be looked at most often [7].
3.1. Do people from different cultures use the system? If so, the system needs to present the system status information in the proper way (according to the users culture). So, ask about the users reading culture and customs. 3.2. Which is the best place to locate the feedback information for each situation?
Usability Mechanism Specification Guide: The following information will need to be instantiated in the requirements document. The system statuses that should be reported are X, XI, XII. The information to be shown in the status area is..... The highlighted information is The obtrusive information is. The software system will need to provide feedback about failures I, II, III occurring in tasks A, B, C, respectively. The information related to failures I, II, etc. must be shown in status area. The information
216
Jos Germn Nez Mori
Pgina 216 de 237
related to failures III, IV, etc , must be shown in highlighted format. The information related to failures V, VI, etc , must be shown in obtrusive format. The software system provides feedback about resources D, E, F when failures IV, I and VI, respectively, occur. The information to be presented about those resources is O, P, Q. The information related to failures I, II, etc.must be shown in the status area..... The information related to failures III, IV, etc , must be shown in highlighted format. The information related to failures V, VI, etc , must be shown in obtrusive format. The software system will need to provide feedback about the external resources G, J, K, when failures VII, VIII and IX, respectively, occur. The information to be presented about those resources is R, S, T. The information related to failures I, II, etc.must be shown in the status area..... The information related to failures III, IV, etc , must be shown in highlighted format. The information related to failures V, VI, etc , must be shown in obtrusive format.
USEP for the Interaction Feedback mechanism
IDENTIFICATION Name: Interaction Feedback Family: Feedback Alias: Interaction Feedback [9] Modelling Feedback [2] Let User Know Whats Going On [11]
PROBLEM Which information needs to be elicited and specified in order to acknowledge the user that the system heard his/her request CONTEXT When the user perform an interaction event, such us mouse click, mouse movement, arrow movement, keyboard press, etc. the system must inform the user that the interaction has been accepted [2] SOLUTION Usability Mechanism Elicitation Guide HCI Recommendation 1. Give visual feedback proportional to the scale of the interaction event and its significance, just to confirm to the user that the system has registered the event. Possibilities include, indenting a button, back-lighting a word, changing the shape of the cursor or the objects involed [9]. Give always visual feedback and allow the user to enalble audio feedback for every interaction event [9] [11] Issues to be discussed with stakeholders 1.1. For each action requested by the user, it should be discussed which kina of acknowledge the system will provide (indenting a button, backlighting a word, changing the shape of the cursor or the objects involed, any other visual or audio signal, etc). This topic can be discussed in Interface Design task. Verify that the application provides the feedback withing 0.1 milliseconds after each key press, movement of the mouse, or other physical input from the user [11]. Usability Mechanism Specification Guide The following information will need to be instantiated in the requirements document: El sistema ha de responder a los interactions events A, B, C. C has high significance. The system response will be done in 0,1 miliseconds after the interaction from the user.
217
Jos Germn Nez Mori
Pgina 217 de 237
USEP for the Long Action Feedback mechanism

IDENTIFCATION Name: Long Action Feedback Family: Feedback Alias: Progress Indicator [7] [8] Progress [10] Let User Know Whats Going On [11] Show Computer is Thinking, Time to Do Something Else [9] Modelling Feedback Area [2] PROBLEM Which information needs to be elicited and specified in order to provide users with information related with the evolution of the requested tasks CONTEXT
When a time-consuming process interrups the UI for longer than two seconds or so. SOLUTION Usability Mechanism Elicitation Guide
HCI Recommendation 1. For on-going processes that take more than 2 seconds: If the process is critical, users should not be allowed to do anything else until this task is completed [10]. If the task is not critical and takes over 5 seconds, users should be allowed to run another operation if they so wish. Users should be informed when the on-going operation finishes [9]. Show an animated indicator of how much progress has been made. Either verbally or graphically (or both). Tell the user [7] [8]: o o o o whats currently going on, what proportion of the operation is done so far, how much time remains, and how to stop it (or cancell it) if the time remaining is longer than 10 seconds [11]. Issues to be discussed with stakeholders
1.1. Which tasks are probably to take more than 2 seconds, and which of them are critical.
1.2. How will the user be informed when the process has finished.
2.
2.1. How the user will be informed about the progress of the different tasks, which information would be desired for each one. Verify that the application takes no longer than 1 second to display the progress indicator [11]; and update the feedback at a rate that gives the user the impression that the operation is still being performed, e.g. every 2 seconds [10].
About the remaining time [9]: If the timing can be calculated, give an indication of the time remaining, either as a figure, or graphically, use either a Timeremaining Progress Indicator or a Proportioncompleted Progress Indicator [11]; if timing can not be estimated, but the process has identificable phases, give an indication of the phases completed, and of the pahses remaining. Use a Progress Checklist [11]; if neither of these possibilities exist, then at least indicate the number of units processed (records, vectors ....); if no quantities are known just that the process may take a while- then simply show some indicator that its still going on [7] [8], use an Indeterminate Progress Indicator [11].
Usability Mechanism Specification Guide
218
Jos Germn Nez Mori
Pgina 218 de 237
The following information will need to be instantiated in the requirements document: Tasks U, V, Z, takes more than 2 seconds so will require long action feedback. For them the information to be shown will be R, S, T in part A, B, C, respectively. Information must appear in less than 1 second and needs to be refreshed every 2 seconds.
RELATED PATTERNS
Abort Operation: for actions that take time to complete a Cancel option should be provided with the feedback information
219
Jos Germn Nez Mori
Pgina 219 de 237
USEP for the Warning Feedback mechanism

IDENTIFICATION Name: Warning Family: Feedback Alias: Warning [10] Think Twice [9] PROBLEM Which information needs to be elicited and specified in order to ask for user confirmation in case the action requested has irreversible consequences. CONTEXT
When an action that has serious consequences has been required by the user [10] [9].
SOLUTION Usability Mechanism Elicitation Guide HCI Recommendation 1. For each action that a user may take, having regard for: the reversibility of the action, the proportion of reversible actions that the system supports, the frequency with which the action is taken, the degree of damage that may be caused, and the immediacy of feedback, consider whether a warning, confirmation or authorization may be appropriate. Users may not understand the consequences of their actions neither other options to perform. So, the warning should contain the following elements [10]: A summary of the problem and the condition that has triggered the warning. A question asking the users if continuing with the action or take on other actions. Two main choices for the user, an affirmative and a choice to abort. It might also include a more detailed description of the situation to help the user make the appropiate decision. The choices should state including a verb that refers to the action wanted. In some cases there may be more than two choices. Increasing the number of choices may be acceptable in some cases but struve to minimize the number of choices. Issues to be discussed with stakeholders 1.1. Discuss with the user all task to be performed and their consequences (consider the frequency of such actions and its damage) and which do require confirmation (be careful not to overload the user with warnings)
2.
2.1. Which information will be provided for each of the tasks to confirm? Remember to provide the consequences of each action and the alternatives to the user.
Usability Mechanism Specification Guide The following information will need to be instantiated in the requirements document: Tasks U, V, Z, will require warning. For them the information to be shown will be R, S, T, respectively
RELATED PATTERNS Abort Operation: One of the alternatives of the warning message should be to Cancel the action
220
Jos Germn Nez Mori
Pgina 220 de 237
USEP for the Global Undo mechanism

IDENTIFICATION
Name: Global Undo

Family: Undo/Cancel Alias: Multi-Level Undo [7] [8]; Undo [10]; Global Undo [3]; Allow Undo [9] PROBLEM Which information needs to be elicited and specified in order to provide users with global undo information. USABILITY CONTEXT When building a highly interactive system with multiple and complex functionalities SOLUTION Usability Feature Configuration Guide HCI Recommendation Issues to be discussed with stakeholders
221
Jos Germn Nez Mori
Pgina 221 de 237
1.
Users typically explore functionality of an application but do not want to be punished when selecting unwanted functions [10]. The ability to undo a long sequence of operations lets users feed that the interface is safe to explore. While they learn the interface, they can experiment with it, confident that they arent making irrevocable changes even if they accidentally do something bad. So, first decide which operations need to be undoable [7][8]: - Any action that might change a file or similar thing anything that could be permanent should be undoable, while transient or view-related states often are not. To be more specific, these kind of changes are expected to be undoable in most applications: o text entry for documents or spreadsheets o database transactions, o modifications to images or painting canvases o layout changes position, size, stacking order, grouping. .. o file operations o creation, deletion or rearrangement of objects such as email messages or spreadsheet columns o any cut, cut or paste operations - The following kinds of changes are generally not undoable. Even if you think it would be going above and beyond the call of duty to make them undoable, consider that you might thoroughly irritate users by cluttering up the undo stack with useless undos: o text or object selection, o navigation between windows or pages, o mouse cursor and text cursor locations, o scrollbar position o window or panel positions and sizes o changes made in an uncommitted or modal dialog - If a command has side effects that cannot be undone, warn the user before executing the command and do not queue it [10] (see feedback pattern for the warning process). - In any case, make sure the undoable operations make sense to the user. They can be specific functions or a meaningful group of actions (for example, changing the printer settings) [10]. Be sure to define and name them in terms of how the user thinks about the operations, not how the computer thinks about them. Undoing a bunch of typed text for instance, should be done in chunks of words, not letter-by-letter.
1.1. Which particular actions will be permanent, and from those ones which ones will have sense to make them undoables?
222
Jos Germn Nez Mori
Pgina 222 de 237
2.
Users tend to explore a navigable artefact in a tree-like fashion, going down paths that look interesting, then back up out of them, then down another path [7][8]. So, an undo stack will need to be created. Each operation goes on the top of the stack as it is performed; each Undo reverses the operation at the top, then the next,... The undo concept must also include the concept of redo needed in case the user backs up too many steps [3]. Redo works its way back up the stack in a similar manner. The best undo should preserve the tree structure of the command execution sequence. Often users want to reverse several actions instead of just the last action [10]. So, the stack should be at least 10 to 12 items long to be useful, and longer if you can manage it. Long-term observation or usability testing may tell you what your usable limit is (Constantine and Lockwood assert that more than a dozen items is usually unnecessary, since users are seldom able to make effective use of more levels. Expert users of high-powered software might tell you differently. As always, know your users)
2.1. Will the system require different combinations of undo/redo, or only the undo function will be needed? 2.2. Ideally undo/redo should use a tree structure instead of a stack structure to keep record of the actions, however the tree structure requires important implementation effort, so have this in mind when determining which kind of structure will be needed to keep record of the actions to be undone/redone. Notice that the system may have a global stack with a concrete size, or depending on the system, the size of the stack may be different for different functionalities. 2.3. How many levels of undo/redo are required, that is, how many items will be stored in the stack/tree of actions to be undone/redone?
3.
Most desktop applications put Undo/Redo items on the Edit menu. Show the history of commands so that users know what they have done [10]. Undo is usually hooked up to Ctrl-Z or its equivalent. The most well-behaved applications use Smart Menu Items to tell the user exactly which operation is next up on the undo stack.
3.1. Which is the best way to present the undo/redo option and stack to the user?
Usability Feature Specification The following information will need to be instantiated in the requirements document: Tasks U, V, Z will be able to be undone. The information to be shown in the stack for them is A, B, C. The undo / redo stack will be able to record X tasks, and the information on this task will be presented in format T. RELATED PATTERNS Object Specific Undo: Some of the actions to be included in the general undo stack might be related to specific objects for which to provide Object Specific Undo.
223
Jos Germn Nez Mori
Pgina 223 de 237
USEP for the Object-Specific Undo mechanism
IDENTIFICATION Name. Object Specific Undo Family: Undo/Cancel Alias: Object-specific undo [3] PROBLEM Which information needs to be elicited and specified in order to provide users with object specific undo information. USABILITY CONTEXT When building a highly interactive system with multiple and complex functionalities on specific objects of the system SOLUTION Usability Feature Configuration Guide HCI Recommendation 1. The software system must provide the possibility for the user to easily access (for example, through the right button) the specific commands that affect such an object. One should be the undo/redo function. In this case, the system should filter the global undo stack and show only the operations that affected the state of the selected object [3]. Issues to be discussed with stakeholders 1.1.For which objects will the specific undo be provided? 1.2 Which actions will be undone for each of the previous objects? Notice that such actions will be also considered in the Global Undo 1.3 How will this option be presented to the user?
Usability Feature Specification The following information will need to be instantiated in the requirements document: Tasks U, V, Z will need to be able to be undone on objects A, B and C. The undo option for these objects will be presented in format T. RELATED PATTERNS Global Undo: Actions for object specific undo must also appear in the Global Undo stack.
224
Jos Germn Nez Mori
Pgina 224 de 237
USEP for the Abort Operation mechanism

IDENTIFICATION Name: Abort Operation Family: UNDO/CANCEL Alias: Emergency Exit [9] Go Back to a Safe Place [7] Go Back [7] Cancellability [8] PROBLEM Which information needs to be elicited and specified in order to provide users with Abort Operation information. USABILITY CONTEXT When the user needs to exit an application or a command quickly. SOLUTION Usability Configuration Guide HCI Recommendation 1. Users who use a number of applications in the course of their work may need rapidly to exit a program when a higher priority task demands the system resources, or when the program has been launched by mistake [9]. So, at application level, at all times ensure that the option to quit a program is immediately and obviously available (if possible even during the initial loading of the program) and modal dialogues do not mask the access to the option. If the option to quit is exercised after work on data manipulated by the program has been completed, the option to save the work done so far should be presented. At operation level, if the user gets into a space or state that they dont want to be in, they will want to get out of it in a safe and predictable way. Also, backtracking out of a long navigation path can be very tedious [7]. So, in window-based GUI applications, it is standard to have a Cancel buttom that closes any dialog box and discards any change the user may have made within the dialog box. Issues to be discussed with stakeholders Will the user need an exit option for the application to be built? If so, where and how should this option be presented to the user?
2.
2.1. Which actions may require a cancel option? Pay special attention to actions that may require several steps. Notice also that all actions en las que el usuario es preguntado o se le solicita informacin deben ser potencialmente cancelables. 2.2. For the previous actions, how should this cancel option be presented to the user (remember that in dialog boxes it is standard to have a cancel buttom), and which will be the state where the system will go when the cancel option is chosen? 3.1.Which actions will take more than 10 seconds to finish? 3.2.Refer to the Long Feedback Pattern for details about information to provide for them.
3.
At command level, if it takes longer than 10 seconds to finish the processing of the command, provide a Cancel option, along with the feedback information (see Feedback pattern), to interrupt the processing and go back to the previous state [5]. Label it with the word Stop or Cancel. Tell the user that the Cancel worled and show a status message on the interface [8].
225
Jos Germn Nez Mori
Pgina 225 de 237
Usability Feature Specification Guide The following information will need to be instantiated in the requirements document: The application will need an exit button that Actions A, B, C require several steps to be taken and a cancel mechanisms will be needed to abort them. Action W will take more than 10 seconds to finish so be sure that a cancel button is provided to abort it.
RELATED PATTERN Long Action Feedback: for actions that take time to complete a Cancel option should be provided with the feedback information Go Back: If an action has a Cancel option, it might also have a Go Back option. Step by Step Execution: In each step from a step by step execution action a Cancel option should be provided.
226
Jos Germn Nez Mori
Pgina 226 de 237
USEP for the Go Back mechanism
IDENTIFICATION Name: Go back Family: UNDO/CANCEL Alias: Go back to a safe place [7] Go Back One Step [7];
PROBLEM Which information needs to be elicited and specified in order to provide users with Go Back information. USABILITY CONTEXT When there are interactive applications with multiple steps SOLUTION Usability Configuration Guide HCI Recommendation 1. If the user gets into a space or state that they dont want to be in, they will want to get out of it in a safe and predictable way. Users may also forget where they were, if they stop using the artefact while they are in the middle of something and do not get back to it for a while [7]. So, Provide a way to step backwards to the previous space or state. If possible, let the user step backwards multiple times in a row, thus allowing him to backtrack as far as he wants. [7]. Sometimes backtracking out of a long navigation path can be very tedious [7]. So, provide a way to go back to a checkpoint of the users choice. That checkpoint may be a home page, a saved file or state, the logical beginning of a section of narrative or a set of steps. Ideally, it could be whatever state or space a user chose to declare as a checkpoint [7]. Issues to be discussed with stakeholders Which actions may require a back option? Pay special attention to actions that may require several steps. For each of the previous actions, will the user have the possibility to go back in each step (notice that for all kind of actions a cancel option may be needed (see Abort Operation pattern)) 1.3. Will an option for going to an original place be provided? If so, what will this original or safe place be?
Usability Feature Specification Guide The following information will need to be instantiated in the requirements document: Actions A, B, C require several steps to be taken, so provide an option to go back to states U, V, W respectively.
RELATED PATTERNS Step by Step Execution: Go back (to a safe place and one step) are usually incorporated in the wizard mechanism Abort Operation: In such actions were a Go back option is provided a Cancel option may also be needed.
227
Jos Germn Nez Mori
Pgina 227 de 237
USEP for the Structured Text Entry mechanism

IDENTIFICATION Name: Structured Text Entry Family: User input errors prevention/correction Alias: Structured Text Entry [7] [9] Structured Format [8] PROBLEM Which information needs to be elicited and specified in order to provide users with structured text entry. CONTEXT When the system can only accept inputs from the user in a very specific format SOLUTION Usability Mechanism Configuration Guide HCI Recommendation 1. Rather than letting a user enter information into a blank and featureless text field, put structure into that text field. Divide it into multiple fields with different relative sizes, for instance, or superimpose a faint visual design on it (like dividers or decimal points). Be careful not to constrict the input so much that it makes things too complicated, or so that it no longer fits the possible input values that users may need to give it! Do user testing as needed to judge whether or not it is too annoying [7]. Once the user has typed all the digits or characters in the first text field, confirm it to him by automatically moving the input focus to the next field [8]. Provide also examples and default values so the user can have information about the required format [9]. Issues to be discussed with stakeholders Where will input from the user be required, and in which format? 1.2 How to guide the user in introducing such input in the required format (defaults, restrict user input for example using check lists or combo lists, etc. If the option chosen allows the user to choose from a list, discuss with the user whether or not such list has a fixed number of items or not this will impact on the final desing )
Usability Mechanism Specification Guide The following information will need to be instantiated in the requirements document: Data M and N will be entered by the user in format P and Q, respectively, so the software system will provide the user with guidance for presenting this format in A and B ways, respectively.
228
Jos Germn Nez Mori
Pgina 228 de 237
USEP for the Step by Step mechanism
IDENTIFICATION Name: Step by Step Family: Wizard Alias: Wizard [10] [8] Step by step [7] PROBLEM Which information needs to be elicited and specified in order to provide users with the step by step mechanism CONTEXT When a non-expert user needs to perform an infrequent complex task consisting of several subtasks where decisions need to be made in each subtask. SOLUTION Usability Mechanism Configuration Guide HCI Recommendation 1. Break up the operations constituting the task into a series of chunks of groups of operations [8]. Take the user through the entire task one step at a time [10] [7]. When the task is started, the user is informed about the goal that will be achieved and the fact that several decisions are needed. If information is needed from the user, ask for it in simple terms and with brevity; by keeping it short, you can better maintain the users sense of flow through the whole step-by-step process [7]. The task may branch like a flow chart, depending upon what information the user inputs, but the user doesnt necessarily need to know about all the available paths through the task [10]. However the users must be able to see where they are in the sequence and which steps are to be done, especially if there are more than 7 steps [7]. If there are more than 10 steps, try to break the task up into manageable sub-sequences, so it doesnt get too tedious for the user [7]. These groups may be thematic or alternatively, you may decide to split up based on decision points [7][8]. Note that the harder part is to balance the size and the number of the sub-sequences. The user must also be able to revise a decision by navigating back to a previous task [10]. Even to go back to the first step if needed [7][8] (see Cancel/Undo pattern). Issues to be discussed with stakeholders 1.1 Which tasks may require several steps to be taken? And what are those steps? 1.2 Which information is required from the user in each task? And which is the best way to ask for it?
2.
2.1. How many steps does each task require? 2.2. Which is the best way to present these steps to the user?
3.
3.1. Which sern las opciones de navegacin hacia atrs en cada uno de los pasos, ya sea al paso anterior o al comienzo de todas las tareas.
Usability Specification Guide The following information will need to be instantiated in the requirements document: Actions A, B, C require several steps to be taken. The steps for A are U, V, R and information to be provided in each step is R, S, T respectively. These steps will be represented in format J. The procedure is similar for actions B and C.
RELATED PATTERNS Go Back: Go back (to a safe place and one step) are usually incorporated in the wizard mechanism
229
Jos Germn Nez Mori
Pgina 229 de 237
Abort Operation: In such actions were a Go back option is provided a Cancel option may also be needed.
230
Jos Germn Nez Mori
Pgina 230 de 237
USEP for the Preferences mechanism

IDENTIFICATION Name: Preferences Family: User Profile Alias: Preferences [10] User preferences [7] `PROBLEM Which information needs to be elicited and specified in order to provide users with the preferences mechanism. CONTEXT When: SOLUTION Usability Configuration Guide HCI Recommendation 1. Provide a place or working surface where users can pick their own settings for things like language, fonts, icons, colour schemes, and use of sound. Allow users to save those preferences, so that they do not have to spend time setting them again, but do this per user if multiple people will use it [7]. Let those preferences become the default for each user on further use [10]. Issues to be discussed with stakeholders 1.1. Will the application give the user the opportunity to set up particular preferences (colors, fonts, format, views, modos de seleccin de funcionalidad, etc.? If so, which ones? 1.2. Will such preferences be different for each user? 1.3. Which is the best way to show and let the users choose such preferences? 2.1. Is it worth for the application to have grouped preferences? 2.2. Which preferences must be grouped in each set (ej, for visually impaired, large fonts and high contrasts) 2.3. Which is the best way to show and let the users choose such preferences? The application is very complex and many of its functions can be tuned to the users preference, and; the system will be used by people with different abilities, cultures and tastes, and not enough is known about the users preferences in order to assume defaults that will suit all users.
2.
Devise a set of alternative canned settings that users can choose between, if they dont like the default and dont want to spend hours picking out good combinations [7].
Consider users who deal with these common issues: - Primary languages other than English - Colour-blind - Visually impaired (most are not 100% blind; large fonts and high contrast help) - Hearing impaired - RSI (repetitive stress injuries), many people cannot easily use their hands If the number of groups is small, property pages can be used for each group but when the number of groups is high, use a tree [10].
Usability Specification Guide The following information will need to be instantiated in the requirements document: Options A, B, C will be able to be arranged for each user. These options will be presented in format F.
231
Jos Germn Nez Mori
Pgina 231 de 237
USEP for the Personal Object Space mechanism
IDENTIFICATION Name: Personal Object Space Family: User Profile Alias: Personal Object Space [7] PROBLEM Which information needs to be elicited and specified in order to provide users with the personal object space mechanism. CONTEXT When the application interface is complex and has many icons that can be organized in different ways SOLUTION Usability Configuration Guide HCI Recommendation 1. Issues to be discussed with stakeholders The user should be able to arrange things in a 1.3 Will users be able to arrange their own layout? way that works best for him, since he knows 1.2 Will the system allow this to be done for each user? more about how he works than the artefacts designer does. This way he can better remember 1.3. Which elements should users be able to arrange? where things are than if the items are arranged for him [7]. Allow users to place things where they want, at least in one dimension but preferably in two. It is tedious for the user to do all the item placement themselves, especially if they want precision or a sorting order. So, start out with a reasonable default layout. However, permit stacking, moving, grouping, aligning, neatness adjustments, sorting and other layout operations. Do not capriciously rearrange the users space, only do automatic layout if the user specifically requests it. The artefact should maintain the users layout between users.
Usability Specification Guide The following information will need to be instantiated in the requirements document: Options A, B, C will be able to be arranged for each user. These options will be presented in format F.
232
Jos Germn Nez Mori
Pgina 232 de 237
USEP for the Favourites mechanism

IDENTIFICATION Name: Favourites Family: User Profile Alias: Bookmarks [7] Favourites [10] PROBLEM Which information needs to be elicited and specified in order to provide users with the favourites mechanism CONTEXT In a navigable software system, when the system is possibly large and complex and allows the user to move freely through it in ways not directly supported by the artefacts structure SOLUTION Usability Mechanism Configuration Guide HCI Recommendation 1. Let the user make a record of their points of interest, so that they can easily go back to them later. The user should be able to label them, since users are in a better position to choose labels that are memorable to them. Save the list for later use [7]. Issues to be discussed with stakeholders Will the application allow users to record the different actions (depending on the kind of application action means a specific functionality performed by the user, a place visited, etc.) they perform? If so, how many actions can be recorded? How will these actions be recorded?
2.
If the list becomes long, allow users to structure it [10]. Support at least an ordered linear organization, so that a user can rank them according to whatever criteria they choose; if possible, support a grouping structure of some kind [7].
Usability Mechanism Specification Guide The following information will need to be instantiated in the requirements document: The system will allow each user to record X places he or she has visited. They will be presented in format F to the user.
233
Jos Germn Nez Mori
Pgina 233 de 237
USEP for the Multilevel Help mechanism

IDENTIFICATION Name: Multilevel Help Family: Help Alias: Multilevel Help [8] PROBLEM Which information needs to be elicited and specified in order to provide users with the multilevel help mechanism. CONTEXT When the application to be developed is complex and a few users are likely to need a fully-fledged help system, but most users wont take the time to use it; so, developers want to support both impatient and/or occasional users. PROBLEM Usability Mechanism Configuration Guide HCI Recommendation 1. Issues to be discussed with stakeholders Create help on several levels including some (but not How complex are the tasks to be done by the all) of the following list. Think of it as a continuum; system? each of these requires more effort from the user than 1.2 .Will expert users or novice users use the system? the previous one [8]: 1.3. Which kind of tasks will probably require help to be o Captions and instructions directly on the page, done? including patterns like Input Hints and Input Prompt. Be careful not to go overboard with 1.4. Which kind of help procedure is best suited for such these. If done with brevity, frequent users wont tasks? mind them, but dont use entire paragraphs of text few users will read them. Tooltips. Use these to show brief, one-line descriptions of interface features that arent self-evident. For icon-only features, these are critical; even nonsensical icons will be taken in stride if the user can tell what it does by rolling over it! Their disadvantages are that they obscure whatevers under them, and that some users find them irritating. A short time delay for the mouse hover e.g. one or two seconds, removes the irritation factor for most people. Slightly longer descriptions that are shown dynamically as users select or roll over certain interface elements. Set aside an area of the page itself for this, rather than using a tiny tooltip popup. Longer help texts contained inside Closable Panels. Help shown in a separate window, often done in HTML via browsers, but sometimes in WinHelp or MacHelp. These are often online manuals, entire books, and are reached via menu items on a Help menu, or from Hlp buttons on dialogs and HTML pages. Live technical support, usually by email, web or telephone.
o o
Usability Mechanism Specification Guide The following information will need to be instantiated in the requirements document: The system will provide help to the user. For tasks A, B, C, . the help provided will be tooltips with . Information.
234
Jos Germn Nez Mori
Pgina 234 de 237
For tasks U, V the help will be captions with information ..
USEP for the Command Aggregation mechanism
IDENTIFICATION
Name: Commands Aggregation

Family: Commands Aggregation Alias: Composed Command [7] Macros [8]; PROBLEM Which information needs to be elicited and specified in order to provide users with Commands Aggregation information. USABILITY CONTEXT When users needs to repeat long sequences of actions and when the possible actions to be taken with the artefact can be expressed through commands, which can be composed from smaller parts, in a language-like syntax with precise and learnable rules, and the users are willing and able to learn that syntax. SOLUTION Usability Mechanism Configuration Guide HCI Recommendation 1. Issues to be discussed with stakeholders Provide a way for the user to record a sequence of 1.1 Which actions will be able to be aggregated? actions [8]. The parts and syntax rules should be easy to Which will be the syntax used for such aggregation? learn, and should generate concise commands whose Remember to use a clear syntax easy to learn. meaning is obvious [7]. The user should be able to How will the aggregated be referred to? give the macro the name of her choice. Let also How the macro content will be edited?
her to review the action sequence somehow [8].

2.
Provide a way to the user to play back the sequence at 2.1. How the aggregated command will be play backed? any time. The play back should be as easy as giving a single command, pressing a single button, or dragging and dropping an object [8] even by speech it [7]. Feedback on the validity of the command or its result should be as immediate as is practical [7][8].
Usability Mechanism Specification The following information will need to be instantiated in the requirements document: Actions U, V, Z will be able to be expressed by aggregated commands. For actions U and V such aggregated command will be typed expressed while for action Z it will be speeached. The syntax used for the aggregation will be . RELATED PATTERNS All Feedback Family patterns: Users need to be informed about the system response to such aggregated commands in similar way to usual commands.
235
Jos Germn Nez Mori
Pgina 235 de 237
References
[1] L. Constantine, L. Lockwood. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley, 1999. [2] T. Coram, L. Lee. Experiences: A Pattern Language for User Interface Design. 1996. http://www.maplefish.com/todd/papers/experiences/Experiences.html [3] S.A. Laasko. User Interface Designing Patterns, 2003. http://www.cs.helsinki.fi/u/salaakso/patterns/index_tree.html [4] T. Jokela. Guiding Designers to the World of Usability: Determining Usability Requirements through Teamwork. In Human-Centered Software Engineering. A.Seffah, J. Gulliksen and M. Desmarais, Kluwer 2005 [5] J. Nielsen. Usability Engineering. John Wiley & Sons, 1993. [6] J. Nielsen. Heuristic Evaluation. In Usability Inspection Methods J. Nielsen and R.L. Mack (eds.). J. Wiley & Sons, 1994. [7] J. Tidwell. The Case for HCI Design Patterns. Http://www.mit.edu/jdidwell/common_ground_onefile.htm. [8] J. Tidwell. Designing Interfaces. Patterns for Effective Interaction Design. OReilly, 2005. [9] Usability Pattern Collection. http://www.cmis.brighton.ac.uk/research/patterns/home.html. [10] M. van Welie. The Amsterdam Collection of Patterns in User Interface Design.. http://www.welie.com [11] C. Benson, A. Elman, S. Nickell, C. Robertson. GNOME Human Interface Guidelines. http://developer.gnome.org/projects/gup/hig/1.0/index.html
236
Jos Germn Nez Mori
Pgina 236 de 237

Tesis MarcoAgilTrabajo

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis MarcoAgilTrabajo

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD POLITECNICA DE MADRID FACULTAD DE INFORMATICA

TESIS DE MASTER EN INGENIERIA DEL SOFTWARE

USABILIDAD EN METODOLOGAS GILES

Autor: JOSE GERMN NEZ MORI Dirigida por: ANA MORENO

Principios bsicos .................................................................................. 17 Proceso de desarrollo ............................................................................ 18 20

Proceso Unificado gil (AUP) 4.2.1 4.2.2 4.2.3

Agile model driven development (AMDD) 4.3.1 4.3.2 4.3.3

Scrum 4.4.1 4.4.2 4.4.3

Dynamic Systems Development Method (DSDM) 4.5.1 4.5.2 4.5.3

Feature Driven Development (FDD) 4.6.1 4.6.2 4.6.3

Tarea de Implementacin de la Funcionalidad.................................... 101

2.2.1.1 Diseo de la capa de datos .................................................................. 102

VII. Referencias Bibliogrficas VIII. Anexos

156 166 177 190 204 213

La Usabilidad en Metodologas giles

II. Metodologas giles

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

Historia del documento

Jos Germn Nez Mori

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

con el equipo de desarrollo, en cuanto a metas y organizacin del mismo [CLEP09]:

Principales metodologas giles

4.1 Programacin Extrema (XP)

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

4.1.1 Principios bsicos

Principio 1 - Retroalimentacin en escala fina:

Jos Germn Nez Mori

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

Principio 2 - Proceso continuo en lugar de por lotes:

Principio 3 - Entendimiento compartido:

Principio 4 - Bienestar del programador:

4.1.2 Proceso de desarrollo

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

Proceso Unificado gil (AUP)

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

Junio 2009 Version 3.0

4.2.3 Proceso de desarrollo

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

Figura 1: Iteraciones AUP

Agile model driven development (AMDD)

4.3.2 Principio bsicos

Jos Germn Nez Mori

Junio 2009 Version 3.0

Figura 2: Ciclo de vida de un proyecto AMDD

4.3.3 Proceso de desarrollo

La Usabilidad en Metodologas giles Metodologas giles

Junio 2009 Version 3.0

A continuacin se detalla la etapa de Desarrollo (Development) de un proyecto basado en AMDD:

Jos Germn Nez Mori

Junio 2009 Version 3.0