Usabilidad en Metodologías Ágiles
Transcript of Usabilidad en Metodologías Ágiles
UNIVERSIDAD POLITECNICA DE MADRID FACULTAD DE INFORMATICA
TESIS DE MASTER EN INGENIERIA DEL SOFTWARE
USABILIDAD EN METODOLOGÍAS ÁGILES
Autor: JOSE GERMÁN NÚÑEZ MORI Dirigida por: ANA MORENO
Noviembre, 2010
Agradecimiento Agradezco a mis padres por apoyarme a seguir mis estudios
Contenido
I. Introducción 2
II. Metodologías Ágiles 1
1. Introducción 14
3. Manifiesto Ágil 15
4. Principales metodologías ágiles 16
4.1 Programación Extrema (XP) 16
4.1.1 Principios básicos .................................................................................. 17
4.1.2 Proceso de desarrollo ............................................................................ 18
4.2 Proceso Unificado Ágil (AUP) 20
4.2.1 Descripción............................................................................................ 20
4.2.2 Principio básicos ................................................................................... 20
4.2.3 Proceso de desarrollo ............................................................................ 22
4.3 Agile model driven development (AMDD) 23
4.3.1 Descripción............................................................................................ 23
4.3.2 Principio básicos ................................................................................... 23
4.3.3 Proceso de desarrollo ............................................................................ 24
4.4 Scrum 25
4.4.1 Descripción............................................................................................ 25
4.4.2 Principio básicos ................................................................................... 26
4.4.3 Proceso de desarrollo ............................................................................ 27
4.5 Dynamic Systems Development Method (DSDM) 27
4.5.1 Descripción............................................................................................ 28
4.5.2 Principios básicos .................................................................................. 28
4.5.3 Proceso de desarrollo ............................................................................ 29
4.6 Feature Driven Development (FDD) 31
4.6.1 Descripción............................................................................................ 31
4.6.2 Principios básicos .................................................................................. 31
4.6.3 Proceso de desarrollo ............................................................................ 33
5 Comparativa entre metodologías ágiles 34
5.1 Criterios de comparación 35
5.1.1 Ciclo de vida del proyecto ..................................................................... 35
5.1.2 Estado Actual ........................................................................................ 37
5.1.3 Calidad .................................................................................................. 37
5.1.4 Herramientas ......................................................................................... 38
5.2 Conclusiones de la comparativa 40
5.3 Adopción de metodologías 40
III. Marco Ágil de trabajo 42
1. Introducción 44
2. Planteamiento metodológico 44
3. Estructura Metodológica 45
3.1 Fases del marco ágil de trabajo 47
3.1.1 Inicio (Inception) ................................................................................... 47
3.1.2 Historias de Usuarios ............................................................................ 48
3.1.3 Pruebas de Aceptación .......................................................................... 49
3.1.4 Product Backlog .................................................................................... 50
3.1.5 Elaboración............................................................................................ 51
3.1.6 Prototipo de la arquitectura del sistema ................................................ 52
3.1.7 Estándar MDA (Model Driven Architecture)........................................ 54
3.1.7.1.1.1Usando MDA .................................................................................... 56
3.1.7.1.1.2Mapas de Transformación 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 generación de código de AndroMDA ............................ 61
3.1.7.1.2.2Arquitectura del marco ágil de trabajo según 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 tecnologías en el ciclo de generación AndroMDA .. 69
3.1.7.2 Plan de ejecución de la primera iteración de construcción .................... 70
3.1.8 Fase de Desarrollo ................................................................................. 73
IV. Fase de Inicio del Marco Ágil de Trabajo 74
1. Introducción 76
2. Desarrollo de la fase de Inicio 77
2.1 Product Backlog 77
2.2 Historias de usuarios 77
2.3 Pruebas de aceptación 87
V. Fase de Elaboración del Marco Ágil de Trabajo 95
1. Introducción 97
2. Desarrollo de la fase de Elaboración 97
2.1 Planificación de la Primera Iteración 97
2.2 Prototipo de Arquitectura 101
2.2.1 Tarea de Implementación de la Funcionalidad .................................... 101
2.2.1.1 Diseño de la capa de datos .................................................................. 102
2.2.1.2 Diseño de la capa de negocio .............................................................. 103
2.2.1.3 Diseño de la capa de presentación ....................................................... 104
2.2.1.4 Resultado de Tarea .............................................................................. 106
2.2.2 Integración del patrón de usabilidad Warning..................................... 109
2.2.2.1 Integración del patrón de usabilidad Warning en la capa de presentación
y capa de negocio ............................................................................................. 111
2.2.2.2 Flujo de trabajo según el patrón de usabilidad Warning ..................... 112
2.2.2.3 Resultados de la Integración del patrón de usabilidad Warning ......... 113
2.2.3 Integración del patrón de usabilidad System Status Feedback ............ 115
2.2.3.1 Integración del patrón de usabilidad SSF a la capa de presentación y
capa de negocio ................................................................................................ 117
2.2.3.2 Flujo de trabajo según el patrón de usabilidad SSF ............................ 118
2.2.3.3 Resultados de la integración del patrón de usabilidad SSF ................. 119
2.2.4 Integración del patrón de usabilidad Global Undo .............................. 121
2.2.4.1 Integración del patrón de usabilidad GU a la capa de presentación y capa
de negocio122
2.2.4.2 Flujo de trabajo según el patrón de usabilidad GU ............................. 125
2.2.4.3 Resultados de la integración del patrón de usabilidad GU .................. 126
2.2.5 Integración del patrón de usabilidad Abort Operation ........................ 127
2.2.5.1 Integración del patrón de usabilidad AO a la capa de presentación y capa
de negocio129
2.2.5.2 Flujo de trabajo según el patrón de usabilidad AO ............................. 132
2.2.5.3 Resultados de la integración del patrón de usabilidad AO .................. 133
2.2.6 Integración del patrón de usabilidad System Progress Feedback ........ 135
2.2.6.1 Integración del patrón de usabilidad SPF a la capa de presentación y
capa de negocio ................................................................................................ 136
2.2.6.2 Flujo de trabajo según el patrón de usabilidad SPF ............................ 139
2.2.6.3 Resultados de la integración del patrón de usabilidad SPF ................. 141
2.2.7 Integración del patrón de usabilidad Abort Command ........................ 143
2.2.7.1 Integración del patrón de usabilidad AC a la capa de presentación y capa
de negocio. ....................................................................................................... 145
2.2.7.2 Flujo de trabajo según el patrón de usabilidad AC.............................. 147
2.2.7.3 Resultados de la integración del patrón de usabilidad SPF ................. 148
2.3 Planificación tras la primera iteración 151
VI. Conclusiones 152
VII. Referencias Bibliográficas 153
VIII. Anexos 155
Anexo 01: Especificación Patrón de Usabilidad Warning 156
Anexo 02: Especificación Patrón de Usabilidad System Status Feedback 166
Anexo 03: Especificación Patrón de Usabilidad Global Undo 177
Anexo 04: Especificación Patrón de Usabilidad Abort 190
Anexo 05: Especificación Patrón de Usabilidad System Progress Feedback 204
Anexo 06: Patrones de Usabilidad en la Elicitación 213
Í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 según XP ......................................................................... 48 Figura 9: Formato de Historias de usuarios según el marco ágil. ........................................................ 49 Figura 10: Formato de Pruebas de Aceptación. .................................................................................... 50 Figura 11: Formato del Product Backlog .............................................................................................. 51 Figura 12 : Hito de la fase de Elaboración ........................................................................................... 52 Figura 13: Trazabilidad de Modelos MDA ............................................................................................ 57 Figura 14: Transformación de metamodelos bajo MDA. ...................................................................... 58 Figura 15: Marcado de un modelo bajo MDA ....................................................................................... 58 Figura 16: Patrones de transformación en los modelos MDA............................................................... 59 Figura 17: Ciclo AndroMDA de generación de código ......................................................................... 62 Figura 18: Arquitectura de Aplicación base del marco ágil de trabajo ................................................ 63 Figura 19: Estructura de Aplicación 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 gestión Sprintometer .................................................................................. 71 Figura 27: Sección de registro de Sprint en Sprintometer ..................................................................... 72 Figura 28. Sección de control de avance de tareas en el Sprint bajo Sprintometer .............................. 72 Figura 29: Vista de la planificación en días .......................................................................................... 98 Figura 30: Sprint y tareas de la primera Iteración 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 presentación ............................................. 106 Figura 37: Búsqueda de personas – Página principal de la aplicación .............................................. 107 Figura 38: Relacionar Personas – Criterio de selección de personas a relacionar ............................ 107 Figura 39: Relacionar Personas – Adición de relaciones a la persona seleccionada ......................... 108 Figura 40 – Diagrama de clases de la especificación del patrón de usabilidad Warning................... 110 Figura 41: Diagrama de secuencia de la especificación del patrón de usabilidad Warning .............. 110 Figura 42: Modelado de la clase controladora con el Patrón de usabilidad Warning ....................... 111 Figura 43: Confirmación de adición de nueva relación según el patrón de usabilidad Warning ...... 114 Figura 44: Resultados tras la confirmación de la adición de una nueva relación .............................. 114 Figura 45: Diagrama de clases de la especificación del patrón de usabilidad SSF ............................ 116 Figura 46: Diagrama de secuencia de la especificación del patrón de usabilidad SSF ...................... 116 Figura 47: Integración del patrón de usabilidad SSF en el diseño de la funcionalidad Relacionar
Personas ....................................................................................................................................... 117 Figura 48: Resultados tras la adición satisfactoria de una nueva relación ........................................ 120 Figura 49: Resultados de error tras la adición de una nueva relación ............................................... 120 Figura 50: Diagrama de clases de la especificación del patrón de usabilidad GU ............................ 122 Figura 51: Diagrama de secuencias de la especificación del patrón de usabilidad GU ..................... 122 Figura 52: Integración del patrón de usabilidad GU en la capa de negocio y capa de diseño ........... 123 Figura 53: Integración del patrón de usabilidad GU en el diagrama de actividades de la página de
Adición de relaciones ................................................................................................................... 124
Figura 54: Adición de nuevas relaciones considerando el patrón GU ................................................ 126 Figura 55: La adición de relaciones tras en el evento de deshacer (Undo) ........................................ 127 Figura 56: Diagrama de clases de la especificación del patrón de usabilidad AO ............................. 128 Figura 57: Diagrama de secuencia de la especificación del patrón de usabilidad AO ....................... 129 Figura 58: Integración del patrón de usabilidad AO en la capa de negocio y capa de presentación . 130 Figura 59: Integración del patrón de usabilidad AO en el diagrama de actividades de la página de
Adición de relaciones ................................................................................................................... 131 Figura 60: Adición de nuevas relaciones considerando el patrón AO ................................................ 133 Figura 61: Home de la aplicación tras el evento Cancelar ................................................................. 134 Figura 62: Consulta de relaciones tras el evento de cancelar ............................................................. 134 Figura 63: Diagrama de clases de la especificación del patrón de usabilidad SPF ........................... 135 Figura 64: Diagrama de secuencia de la especificación del patrón de usabilidad SPF ..................... 136 Figura 65: Integración del patrón de usabilidad SPF en la capa de negocio y capa de diseño .......... 137 Figura 66: Integración del patrón de usabilidad SPF en el diagrama de actividades de la página Web
de Adición de relaciones .............................................................................................................. 138 Figura 67: Esquema de trabajo del objeto XMLHttpRequest .............................................................. 140 Figura 68: Adición de distintas relaciones a la persona seleccionada ................................................ 142 Figura 69: Barra de progreso mientras se aplica la operación de Undo a las relaciones adicionadas
...................................................................................................................................................... 142 Figura 70: Diagrama de secuencia de la especificación del patrón de usabilidad AC ....................... 144 Figura 71: Integración del patrón de usabilidad AC en la capa de negocio y capa de diseño ........... 145 Figura 72: Integración del patrón de usabilidad AC en el diagrama de actividades de la página Web
de Adición de relaciones .............................................................................................................. 146 Figura 73: Adición de distintas relaciones a la persona seleccionada ................................................ 149 Figura 74: Barra de progreso con opción 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 planificación ................................................................ 151
Índice de Tablas
Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologías ágiles. ..................... 36 Tabla 2: Estado actual de las metodologías ágiles ............................................................................... 37 Tabla 3: Comparativa de calidad en las metodologías ágiles .............................................................. 38 Tabla 4: Herramientas de libre distribución para metodologías á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 fusión 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 Situación familiar de la persona ........................................ 87 Tabla 12 : Prueba de aceptación – Relacionar personas ...................................................................... 88 Tabla 13: Prueba de aceptación – Gestionar fusión de personas .......................................................... 90 Tabla 14: Prueba de aceptación – Buscar personas fusionadas ........................................................... 91 Tabla 15: Prueba de aceptación – Recuperar datos entidad financiera ................................................ 93 Tabla 16: Prueba de aceptación – Gestionar situación familiar ........................................................... 94 Tabla 17: Product backlog ..................................................................................................................... 98 Tabla 18: Planificación del Sprint – Relacionar Personas .................................................................. 100 Tabla 19: Planificación inicial de la tarea de implementación de la funcionalidad ........................... 102 Tabla 20: Actualización de la planificación de la tarea de implementación de la funcionalidad ....... 108 Tabla 21: Planificación inicial de la tarea de integración del patrón de usabilidad Warning ........... 109 Tabla 22: Correspondencia de componentes del patrón de usabilidad Warning y los componentes de la
funcionalidad................................................................................................................................ 112 Tabla 23- Planificación actualizada de la tarea de integración del patrón de usabilidad Warning ... 115 Tabla 24: Planificación inicial de la tarea de integración del patrón de usabilidad SSF ................... 115 Tabla 25: Correspondencia de componentes del patrón de usabilidad SSF y los componentes de la
funcionalidad................................................................................................................................ 118 Tabla 26: Planificación actualizada de la tarea de integración del patrón de usabilidad SSF ........... 121 Tabla 27: Planificación inicial de la tarea de integración del patrón de usabilidad GU .................... 121 Tabla 28: Correspondencia de componentes del patrón de usabilidad GU y los componentes de la
funcionalidad................................................................................................................................ 124 Tabla 29: Planificación actualizada de la tarea de integración del patrón de usabilidad GU .......... 127 Tabla 30: Planificación inicial de la tarea de integración del patrón de usabilidad AO .................... 129 Tabla 31: Correspondencia de componentes del patrón de usabilidad AO y los componentes de la
integración ................................................................................................................................... 131 Tabla 32: Planificación actualizada de la tarea de integración del patrón de usabilidad AO ............ 135 Tabla 33: Planificación inicial de la tarea de integración del patrón de usabilidad SPF................... 136 Tabla 34: Correspondencia de componentes del patrón de usabilidad SPF y los componentes de la
Integración ................................................................................................................................... 139 Tabla 35: Planificación actualizada de la tarea de integración del patrón de usabilidad SPF .......... 143 Tabla 36: Planificación inicial de tarea de integración del patrón de usabilidad AC ........................ 144 Tabla 37: Correspondencia de componentes del patrón de usabilidad AC y los componentes de la
integración ................................................................................................................................... 147 Tabla 38: Planificación actualizada de la tarea de integración del patrón de usabilidad AC ............ 150
I. Introducción La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y
ser atractivo para el usuario, en condiciones específicas de uso.
Es considerada la usabilidad también, como la medida en que un producto puede ser usado
por usuarios específicos, para lograr los objetivos especificados con efectividad, eficiencia y
satisfacción en un contexto específico de uso.
En el campo de la Ingeniería de software, hablar de usabilidad hoy en día, es relacionar con
la interfaz de usuario, por lo tanto, la usabilidad afectaría a la UI y no a la funcionalidad
básica del sistema. De acuerdo a esto, la usabilidad debe ser tratada al final del desarrollo del
sistema, como un atributo más de calidad y que no necesita demasiadas pruebas (Hipótesis de
la separación).
En contraposición, a la idea que se tiene hoy en día de la usabilidad, existen investigaciones
en el campo de la ingeniería de Software, donde, se describe que las Isuues de usabilidad son
limitaciones estáticas y dinámicas a los componentes de software y que la separación de la
interfaz de usuario de la funcionalidad básica, no garantiza que se entregue un producto
usable al cliente final.
Confirmada la relación entre diseño de software y usabilidad, la revisión del costo para
alcanzar un nivel aceptable de usabilidad debería ser mayor que lo planteado por la hipótesis
de separación, por lo tanto, la facilidad de uso debe ser tratada con anterioridad al proceso de
desarrollo, con el fin de evaluar su impacto en el diseño tan pronto como sea posible.
Esto es una estrategia ya aplicada con anterioridad a algunos de los atributos de calidad como
por ejemplo: fiabilidad, disponibilidad y mantenibilidad, donde, algunos autores propusieron
en su momentos, técnicas para hacer frente a estos atributos en tiempo de diseño
arquitectónico.
La literatura HCI (Human Computer Interaction), analiza el impacto que tiene la usabilidad
en el desarrollo del Software, con lo cual, presenta recomendaciones, considerando tres
diferentes categorías de impacto:
• Usabilidad con impacto en la UI, esto afecta a la presentación del sistema, como puede
ser botones, color de fondo, etc. Para dar solución a esto, solo se realizan cambios en el
diseño detallado de la UI y no en el Funcionalidad básica del sistema.
• Usabilidad con impacto en el proceso desarrollo, esto afecta al proceso de desarrollo,
donde, estas recomendaciones proponen directrices para alentar la interacción usuario-
sistema, el cual debe tener un sitio natural e intuitivo para el usuario.
Si se desea hacer uso de estas recomendaciones, es necesario modificar el proceso de
desarrollo, ya que debe ser centrado en el usuario, implicando de esta manera, tener
técnicas mas potentes para la obtención de requisitos, que probablemente se tenga que
apoyar en otras disciplinas como HCI, con el objetivo de poder hacer participe al usuario
en la construcción del software
• Usabilidad con impacto en el diseño, estas son recomendaciones que implican actividades
de construcción de funcionalidades en el Software, para mejorar la actividad usuario
sistema, por ejemplo funcionalidades como: Cancelar una tarea en curso.
Según las recomendaciones dadas por la literatura HCI, hoy en día se han realizado estudios
enfocados, más que todo en el impacto de la usabilidad en el diseño (Ver anexos), buscando
así, mecanismos para tratar la usabilidad en esta etapa.
Todas estas recomendaciones y estudios, que asocian la usabilidad en el proceso de desarrollo
de software, hoy en día, se vienen utilizando en proyecto de desarrollo de software
tradicional, es decir, proyectos que siguen lineamientos de metodologías de desarrollo
tradicional.
Es de acuerdo a esta premisa, que el presente trabajo tiene como objetivo principal, la
inclusión de los principios de usabilidad, en proyectos Software, que se desarrollen en base a
metodologías ágiles.
Para cumplir con este objetivo, el presente trabajo de fin de Master, se basará en estudios
previos, donde se detallan mecanismo para considerar la usabilidad antes del proceso de
desarrollo, es decir, en las etapas, de toma de requisitos y de diseño (ver anexos).
Estos mecanismos, deberán de ser tomados en cuenta, en los planteamientos de la
metodología o metodologías ágiles seleccionadas, para que así, el ciclo del vida del software
a desarrollar en base a estos lineamientos ágiles, tome en cuenta los principios de usabilidad.
El presente trabajo, tendrá la siguiente estructura, para abordar el objetivo principal del
mismo:
• Capítulo I (Metodologías ágiles), se detallará los planteamientos de las metodologías
ágiles mas conocidas hoy en día, buscando con esto, seleccionar la metodología o
metodologías, que nos permitan incluir los principios de usabilidad.
• Capitulo II (Marco ágil de trabajo), en base a la metodología o metodologías
seleccionadas, se creará un marco de trabajo ágil, donde se detalle los lineamientos para
el ciclo de vida del software a desarrollar, donde también, estos lineamientos tengan en
cuenta los principios de usabilidad.
• Ya en capitulo III (Fase de inicio del marco ágil de trabajo) y IV (Fase de elaboración
del marco ágil de trabajo), es donde, se describirá el desarrollo del sistema, siguiendo los
lineamientos del marco ágil de trabajo.
.
La Usabilidad en Metodologías Ágiles
II. Metodologías Ágiles
Versión 3.0
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 13 de 237
Historia del documento
FECHA VERSION DESCRIPCIÓN AUTOR
08/05/2009 1.0 Metodologías Ágiles José Germán Núñez Mori
25/05/2009 2.0 Metodologías Ágiles José Germán Núñez Mori
15/06/2009 3.0 Metodologías Ágiles José Germán Núñez Mori
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 14 de 237
Metodologías Ágiles
1. Introducción A principios de las década del 90 surgió un enfoque que era revolucionario para su momento ya
que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr
obtener software de alta calidad en un tiempo y costo determinado. El enfoque fue planteado por
primera vez en 1991 por James Martin [MART91], que consistía en un entorno de desarrollo
altamente productivo, en el que participaban grupos pequeños de programadores utilizando
herramientas que generaban código de forma automática tomando como entrada sintaxis de alto
nivel. En general se considera que este fue uno de los primeros hitos en pos de la agilidad en
los procesos de desarrollo [SMHR04].
Tras pasar cierto tiempo después de este primer enfoque de agilidad en los procesos de
desarrollo, en febrero del 2001 se reunieron miembros prominentes de la comunidad Software y
adoptaron el nombre de metodologías ágiles, poco después formando la “Alianza Ágil”, que es
una organización sin fines de lucro, que promueve el desarrollo ágil de aplicaciones [CLEP09].
Las metodologías ágiles nacen como una reacción contra los métodos de “peso pesado”, muy
estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El proceso originado
del uso del modelo en cascada era visto como burocrático, lento degradante e inconsistente con
las formas de desarrollo de software que realmente realizaban un trabajo eficiente [WDAS09].
2. Descripción
Las metodologías ágiles son un marco conceptual de la Ingeniería de Software que promueve
iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto, considerando una
iteración como una unidad de tiempo que dura de uno a cuatro semanas. Donde cada iteración
del ciclo de vida incluye planificación análisis, diseño, codificación, revisión y documentación
[WDAS09]. Una iteración no debe agregar demasiada funcionalidad para justificar el
lanzamiento del producto al mercado, pero la meta es tener un producto parcial o una parte del
todo al final de cada iteración.
Las metodologías ágiles buscan lo siguiente [WDAS09]:
• Evitar los tortuosos y burocráticos caminos de las metodologías tradicionales, enfocándose
en la gente y los resultados.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 15 de 237
• Minimizar los riesgos, desarrollando software en cortos lapsos de tiempo (iteraciones).
• Enfatizar las comunicaciones cara a cara en vez de la documentación.
• Enfatizar que el software funcional es la primera medida del progreso.
Las metodologías ágiles platean centrarse en otras dimensiones, como por ejemplo el factor
humano o el producto software, siendo esto su principal filosofía. Dando mayor valor al
individuo, a la colaboración con el cliente y al desarrollo incremental del software con
iteraciones muy cortas. Este enfoque esta mostrando su efectividad en proyectos con requisitos
muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero
manteniendo una alta calidad.
3. Manifiesto Ágil
En esta sección se detalla los principios básicos del Manifiesto Ágil, inspirando en base a lo
expuesto en: “Manifiesto for Agile Software Development” [MFAS01].
Como consecuencia de la reunión donde se acuño el término “Metodologías Ágiles” (febrero
2001), se establecieron los principios de estas metodologías agrupándoles en cuatro postulados,
quedando esta agrupación denominada como Manifiesto Ágil. A continuación se mencionan los
cuatro postulados de este manifiesto:
• Valorar más a los individuos y su interacción que a los procesos y las herramientas, es decir,
la gente es el principal factor de éxito de un proyecto software. Es más importante construir
un buen equipo que construir el entorno.
• Valorar más el software que funciona que la documentación exhaustiva, donde la regla a
seguir es “no producir documentos a menos que sean necesarios de forma inmediata para
tomar decisiones importantes”.
• Valorar más la colaboración con el cliente que la negociación contractual, es decir, se
propone que exista una interacción constante entre el cliente y el equipo de desarrollo.
• Valorar la respuesta al cambio que el seguimiento de un plan, es decir, la habilidad de
responder a los cambios que puedan surgir a lo largo del proyecto
Los postulados anteriores inspiran los doce principios del manifiesto, donde estos principios
representan las características que diferencian un proceso ágil de uno tradicional A continuación
se detallarán los doce principios del manifiesto, donde, los dos primeros principios son
generales y resumen gran parte del espíritu ágil, el resto tienen que ver con el proceso a seguir y
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 16 de 237
con el equipo de desarrollo, en cuanto a metas y organización del mismo [CLEP09]:
• Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua
de software de valor.
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
• Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un
par de meses, con preferencia en los periodos breves.
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a
través del proyecto.
• Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el
respaldo que necesitan y procurándoles confianza para que realicen la tarea.
• La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un
equipo de desarrollo es mediante la conversación cara a cara.
• El software que funciona es la principal medida del progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores
y usuarios deben mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica enaltece la agilidad.
• La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
• En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su
conducta en consecuencia.
4. Principales metodologías ágiles
En esta sección se describirán las principales metodologías ágiles destacadas hasta el momento.
4.1 Programación Extrema (XP)
La definición de esta metodología, se ha realizado tomando como base las siguientes
referencias: [RJEF99], [RMAT6], [SMHR04], [CLEP09].Definición
La programación Extrema (en adelante XP) es una metodología de desarrollo ligera (o ágil)
basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de
aumentar la productividad a la hora de desarrollar programas.
Este modelo de programación se basa en una serie de metodologías de desarrollo de software en
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 17 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 programación
Los ingredientes utilizados en esta metodología son conocidos desde el principio de la
informática, donde, los autores de la metodología XP han seleccionado aquellos que han
considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con
los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto,
aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el
desarrollo de software.
4.1.1 Principios básicos
La metodología XP se basa en 12 principios básicos, agrupados en 4 categorías, las cuales se
detallan a continuación:
• Principio 1 - Retroalimentación en escala fina: a) El principio de pruebas, se tiene que establecer un periodo de pruebas de aceptación
(periodo de caja negra), donde se definirán las entradas al sistema y los resultados esperados
en cada una de las pruebas definidas.
b) Proceso de planificación, es la fase en la que se crea un documento llamado Historias de los
usuarios (User stories), en donde el usuario escribe sus necesidades, definiendo así las
actividades que realizará el sistema.
El usuario escribirá entre 20 y 80 historias (dependiendo de la complejidad del problema)
que se considera suficientes para formar el llamado: Plan de Liberación, el cual define de
forma específica los tiempos de entrega de la aplicación. Por regla general cada uno de las
historias de los usuarios suelen necesitar de una a tres semanas de desarrollo.
c) El cliente en el sitio, se promueve la fuerte interacción cara a cara entre el programador y el
cliente, con el objetivo de disminuir el tiempo de comunicación y la cantidad de
documentos, junto con sus altos costes de creación y mantenimiento. Este representante del
cliente, deberá formar parte del equipo de trabajo durante toda la realización del proyecto,
teniendo la potestad para determinar requerimientos definir funcionalidades, señalar
prioridades y responder preguntas de los programadores.
d) Programación en pareja, la metodología plantea que los programadores XP escriban su
código en parejas, compartiendo una sola maquina con el objetivo de producir aplicaciones
mejores, de manera consistente a iguales o menores costes.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 18 de 237
• Principio 2 - Proceso continuo en lugar de por lotes: a) Integración continúa, permite al equipo de programadores hacer un rápido progreso
implementando las nuevas características del software.
b) Refactorización, permite a los equipos de programadores XP mejorar el diseño del sistema,
donde a lo largo de todo el proceso de desarrollo, los programadores evalúan continuamente
el diseño y recodifican lo necesario.
c) Entregas pequeñas, consiste en colocar un sistema sencillo en entono de producción
rápidamente, que se actualice de manera continua, permitiendo que el verdadero valor del
negocio sea evaluado en un ambiente real.
• Principio 3 - Entendimiento compartido:
a) Diseño simple, se basa en la filosofía de que el mayor valor de negocio es entregado por el
programa más sencillo que cumpla los requerimientos. Se enfoca en proporcionar un
sistema que cubra las necesidades inmediatas del cliente.
b) Metáfora, desarrollada por los programadores al inicio del proyecto, define una historia de
como funciona el sistema completo. XP estimula historias, que son breves descripciones de
un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified
Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el
alcance y propósito del sistema
c) Propiedad colectiva del código, la metodología XP promueve la filosofía de un código con
propiedad compartida, donde, nadie es propietario de nada y que todos son propietarios de
todo
d) Estándar de codificación, define la propiedad del código compartido así como las reglas
para escribir y documentar el código y la comunicación entre diferentes piezas de código
desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que
el código en el sistema se vea como si hubiera estado escrito por una sola persona.
• Principio 4 - Bienestar del programador: a) La semana de 40 horas, la programación extrema sostiene que los programadores cansados
escriben código de menor calidad. Minimizar las horas extras y mantener los programadores
frescos, generará código de mayor calidad.
4.1.2 Proceso de desarrollo
XP, parte del caso habitual de una compañía que desarrolla software, normalmente a medida, en
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 19 de 237
la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes
finales. El proceso conlleva las siguientes actividades:
a) Interacción con el cliente
En este tipo de programación, el cliente pasa a formar parte implicada en el equipo de
desarrollo, donde, su importancia es máxima en el momento de tratar con los usuarios y efectuar
las planificaciones respectivas.
Al tener al cliente mucho más cerca del equipo de desarrollo, se elimina la fase inicial de
recopilación de requerimientos y se permite que estos se vayan cogiendo a lo largo del proyecto
de manera ordenada en las llamadas “Historia de usuario”. A diferencias de otras técnicas como
puede ser UML, el caso de XP, se exige que sea el cliente el encargado de escribir los
documentos con las especificaciones de lo que realmente quiere.
En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y
asignarles una duración. La norma es que cada historia de usuario tiene que poder ser realizable
en un espacio entre una y tres semanas de programación.
b) Planificación del proyecto En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes
iteraciones, y por cada iteración el cliente ha de recibir una versión nueva.
Se ha de tener asumido que en el proceso de planificación habrá errores, ante lo cual la
metodología establece mecanismos de revisión, donde cada tres o cinco iteraciones es normal
revisar las historias de los usuarios y renegociar la planificación.
Además la metodología establece que por cada iteración se realizará un planificación, que es lo
que se llama “Planificación iterativa”, en la que se anotará las historia de los usuarios que se
consideren esenciales y las que no han pasado las pruebas de aceptación realizadas por el
cliente.
c) Diseño desarrollo y pruebas El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los
trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones
y en dirección correcta
Para el diseño, la metodología establece mecanismos, para que este sea revisado y mejorado de
manera continua, según se vaya añadiendo funcionalidad al sistema.
Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una
prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y se
continúa.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 20 de 237
Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por esto
es importante pasar las pruebas al 100%.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del
programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto
es tan importante la integración diaria.
4.2 Proceso Unificado Ágil (AUP)
La definición de esta metodología, se ha realizado tomando como base las siguientes
referencias: [CRLA02], [SABL06]. [KINT07], [WAUP09].
4.2.1 Descripción
El Proceso Unificado Ágil (en adelante, AUP), se describe como una metodología fácil de
entender para el desarrollo de aplicaciones software de negocio, utilizando técnicas ágiles y
conceptos aun fieles a las de RUP, por lo tanto, es una versión simplificada del Rational Unified
Process (RUP).
AUP, incluye o hace uso de las siguientes técnicas ágiles:
• Test driven development (TDD).
• Agile model driven development (AMDD).
• Agile change management.
• Data base refactoring.
AUP, es una metodología que tiene la adopción de muchas de las técnicas ágiles de la
metodología XP (Extreme Programming) y de las formalidades de RUP, teniendo como
filosofía adaptarse a las necesidades del proyecto y no al contrario como lo planteado en las
metodologías tradicionales. Esta metodología, plantea un ciclo de vida iterativo, que se basa en
la ampliación y refinamiento sucesivo del sistema, mediante múltiples iteraciones con
retroalimentación cíclica y adaptación como elementos principales que dirigen para converger
hacia un sistema adecuado.
4.2.2 Principio básicos
Como parte de esta metodología, en la presente sección se detalla, tanto las fases y disciplinas de su planteamiento:
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 21 de 237
a) Fases
Al igual que RUP, AUP tiene las 4 fases clásicas consecutivas y que acaban cada uno de estas,
con hitos claros alcanzados:
• Inception (Concepción): El objetivo de esta fase es obtener una comprensión común cliente-
equipo de desarrollo, del alcance del nuevo sistema y definir una o varias arquitecturas
candidatas para el mismo.
• Elaboración: El objetivo es que el equipo de desarrollo profundice en la comprensión de los
requisitos del sistema y en validar la arquitectura.
• Construcción: Durante la fase de construcción el sistema es desarrollado y probado al
completo en el ambiente de desarrollo.
• Transición: el sistema se lleva a los entornos de preproducción donde se somete a pruebas
de validación y aceptación y finalmente se despliega en los sistemas de producción.
b) Disciplinas El proceso AUP, establece un modelo más simple que el planteado en RUP, por lo que reúne en
una única disciplina: el modelado de negocio, requisitos y análisis y diseño. El resto de
disciplinas coinciden con las restantes de RUP, a continuación se describe las disciplinas
consideradas por AUP:
• Modelado: Se busca entender el negocio de la organización, el problema de dominio que se
abordan en el proyecto, y determinar una solución viable.
• Implementación: Consiste en transformar los modelos o modelo en código ejecutable y
realizar un nivel básico de las pruebas, en particular Unit testing.
• Pruebas: Se busca realizar una evaluación objetiva para garantizar la calidad. Esto incluye la
búsqueda de defectos, validar que el sistema funciona tal como está establecido, y
verificando que se cumplan los requisitos.
• Despliegue: Consiste en la elaboración de un plan para la entrega del sistema y ejecutar el
plan para que el sistema este a disposición de los usuarios finales.
• Gestión de Configuración: Consiste en administrar el acceso a los artefactos del proyecto.
Esto incluye no sólo el seguimiento de las versiones de los artefactos en el tiempo, sino
también el control y la gestión de los cambios de estos.
• Administración del Proyecto: Consiste en dirigir las actividades que se llevan a cabo dentro
del proyecto. Esto incluye la gestión de riesgos, la dirección de personas (la asignación de
tareas, el seguimiento de los progresos, etc), y de coordinación con el personal y los
sistemas fuera del alcance del proyecto para asegurarse de que el software final sea
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 22 de 237
entregado a tiempo y dentro del presupuesto.
• Entorno: Es un soporte para el resto de los esfuerzos para garantizar un proceso adecuado,
orientación (normas y directrices), y herramientas (hardware, software, etc) estén
disponibles para el equipo según sea necesario.
4.2.3 Proceso de desarrollo
En esta metodología las disciplinas se llevan acabo de manera iterativa, con la definición de las
actividades de los miembros del equipo de desarrollo, con el fin de desarrollar, validar y
entregar el software que responda a las necesidades de los stakeholders.
En cada disciplina la metodología plantea las diferentes actividades y artefactos a producir, lo
cual no implica que se realicen o se produzcan todo lo planteado si no más bien lo que se
necesita en el proyecto.
Las fases que platea la metodología no constituye el antiguo ciclo de vida secuencial o en
cascada, si no más bien, es planteado de la siguiente manera:
• La fase de Inicio (Inception), no es una fase de requisitos, si no mas bien una especia de
fase de viabilidad, donde se lleva acabo el estudio suficiente, para decidir si continuar o
no el proyecto.
• La fase de Elaboración no es una fase de requisitos o diseño, si no que es una fase
donde se implementa de manera iterativa la arquitectura que constituye el núcleo central
del sistema, y es donde se mitiga las cuestiones de alto riesgo.
• En la fase de construcción, se implementa de manera iterativa el resto de requisitos (de
menor riesgo), se realiza pruebas y se prepara para el despliegue.
Por cada una de las fases e iteraciones planteadas en las mismas, se puede hacer uso de la
totalidad de las disciplinas o solo de algunas, esto dependerá de la iteración en la que se
encuentre, debido a que el esfuerzo relativo en las disciplinas disminuye de iteración en
iteración.
AUP, plantea que en lugar del “big bang” en la entrega del software, una liberación del
producto en partes, por ejemplo versión 1, luego versión 2 del software en producción y así
sucesivamente hasta tener el producto completado. De acuerdo a este planteamiento AUP
distingue dos tipos de iteraciones:
• Versión de desarrollo, cuyo resultado esta un despliegue en entorno QA (Aseguramiento de
la calidad) o Demo área, estas versiones deben ser rápidas, de ser posible de una a tres
semanas de desarrollo.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 23 de 237
• Versión producto, cuyo resultado es un despliegue en producción, donde la primera entrega
estable tardará en promedio 12 meses, la siguiente 9 meses y las siguientes cada 6 meses.
Figura 1: Iteraciones AUP
AUP, se preocupa principalmente de la gestión de riesgos. Propone que aquellos elementos con
alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas
del mismo. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables
durante la fase de elaboración del producto, donde se demuestre la validez de la arquitectura
para los requisitos clave del producto y que determinan los riesgos técnicos.
4.3 Agile model driven development (AMDD)
La definición de esta metodología, se ha realizado tomando como base la siguiente referencia: [SABL08].
4.3.1 Descripción
Agile model driven development (en adelante, AMDD), es una versión ágil del Model driven
development (MDD), donde MDD es un enfoque amplio de desarrollo de software donde se
crean modelos antes del código fuente. Un ejemplo de MDD es el estándar MDA (Arquitectura
dirigida por modelos)
La diferencia entre MDD y AMDD, es que este último en lugar de crear una amplia gama de
modelos antes de escribir código fuente, crea modelos ágiles que son solo apenas los
suficientemente buenos. AMDD es una estrategia fundamental en la escalabilidad de los
desarrollos ágiles del software.
4.3.2 Principio básicos
AMDD, plantea las siguientes dos etapas como parte de su ciclo de vida del proyecto:
� Previsión (Envisioning), etapa que pertenece a la iteración 0, consta de dos sub-actividades:
o Previsión inicial de requerimientos (Initial Requirements Envisioning).
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 24 de 237
o Previsión inicial de la arquitectura (Initial Architectural Envisioning).
Ambas sub actividades, son recomendadas por la metodología que se realicen en periodos
diarios, durante el tiempo que dure la iteración 0.
� Desarrollo (Development), iteración que será repetida hasta alcanzar un producto de calidad,
consta de sub actividades a mencionar:
o Iteración de modelado (Iteration Modeling).
o Modelo de asalto (Model Storming).
o Evaluación en base a TDD (Test driven development)
Figura 2: Ciclo de vida de un proyecto AMDD
4.3.3 Proceso de desarrollo
A continuación, se detalla el proceso de desarrollo del ciclo de vida de un proyecto que hace uso de la metodología AMDD: • Modelo inicial de requerimientos (Initial Requirements Envisioning), es necesario tomar
varios días para identificar algunos de los requisitos de alto nivel y el alcance del software,
todo esto como una primera versión del sistema.
Lo que se busca con esto es conseguir un buen entendimiento del proyecto, haciendo uso de
modelos que exploren como el usuario trabaja en su entorno, obteniendo de esto un modelo
inicial del dominio, donde se identifique los tipos fundamentales de entidades de negocio y
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 25 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 dirección técnica para el proyecto y
proporcionar información suficiente para la organización del equipo alrededor de esta
arquitectura (importante para proyectos de gran escala).
De este modelado inicial, perteneciente a la iteración de Previsión (Envisioning), se obtendrá:
diagramas de forma libre que exploren la infraestructura técnica y los primeros modelos de
dominio que permitan explorar las principales entidades empresariales y sus relaciones. Con
esto se busca tener lo suficiente como para que el equipo pueda ponerse en marcha
A continuación se detalla la etapa de Desarrollo (Development) de un proyecto basado en
AMDD:
• Iteración de modelado (Iteration Modeling), donde al comienzo de cada iteración de
desarrollo, el equipo debe planificar el trabajo que hará en la iteración en base a un modelo
de actividades, basado principalmente en la prioridad de los requisitos.
• Modelo de asalto (Model Storming), consiste en reuniones improvisadas de cinco a diez
minutos, donde integrantes del equipo se reúnen alrededor de una herramienta de modelado
o una pizarra, con el objetivo de analizar una serie de dudas o cuestiones de uno o varios
modelos y darles respuestas a cada una de estas, una vez terminada esta reunión los
integrantes del equipo siguen su labor de construcción.
• AMDD, plantea que a final de cada construcción se realice pruebas unitarias del código
desarrollado y la refactorización si fuese necesario, todo esto basado en el Test Driven
Development (TDD).
4.4 Scrum
La definición de esta metodología, se ha realizado tomando como base las siguientes
referencias: [KSXHB09], [JSUT09]. [JPAL02], [SMHR04].
4.4.1 Descripción
Scrum, plantea un proceso de desarrollo de software iterativo y creciente, utilizado
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 26 de 237
comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser
utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de
programas: Scrum de Scrums.
Scrum, por sus características no es válido para cualquier proyecto persona o equipos de
personas, es optimo para equipos de trabajo de hasta 8 personas, auque existen empresas que
han utilizado con éxito scrum con equipos mas grandes.
4.4.2 Principio básicos
Existen dos aspectos fundamentales a diferenciar en Scrum que son: los actores y las acciones,
donde los actores son los que ejecutan las acciones.
Los actores contemplados en esta metodología son los siguientes:
• Product Owner, conoce y marca las prioridades del proyecto o producto.
• Scrum Master, es la persona que asegura el seguimiento de la metodología guiando las
reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su
responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
• Scrum Team, son las personas responsables de implementar la funcionalidad o
funcionalidades elegidas por el Product Owner.
• Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los
progresos, pueden aportar ideas, sugerencias o necesidades.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y
forma de trabajar que a continuación se indica, tiene como objetivo minimizar el esfuerzo y
maximizar el rendimiento en el desarrollo:
• Product backlog, corresponde con todas las tareas, funcionalidades o requerimientos a
realizar que son marcadas por el Product owner.
• Sprint backlog, corresponde con una o mas tareas que provienen de la lista de tareas
(Product backlog), donde estas tareas se deben acometer en unas 2 semanas o 4 semanas.
Existe una norma fundamental que mientras un Sprint backlog se inicia no debe ser alterado
o modificado, hay que esperar a que concluya para hacerlo.
• Dayli scrum meeting, es una tarea iterativa que se realiza todos los días que dure el Sprint
backlog con el equipo de desarrollo, con lo cual se busca identificar obstáculos o riesgos
que impidan el normal avance, verificar el avance de las tareas y la planificaciones de las
mimas para el día.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 27 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 aplicarán los cambios y ajustes si son
necesarios, y se marcarán los aspectos positivos (para repetirlos) y los aspectos negativos
(para evitar que se repitan) del Sprint backlog.
4.4.3 Proceso de desarrollo
El proceso parte de la lista de tareas (Product backlog), que no son otra cosa que los requisitos
del producto y que actúa como un plan del proyecto. De esta lista el cliente prioriza los
requisitos basándose en objetivos, balanceando el valor que le aportan a su coste y quedando
repartidos en iteraciones y entregas (Sprint backlog),
De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla mediante la
replanificación de objetivos que se puede realizar al inicio de cada iteración.
Cada día de una iteración debe realizarse una reunión con los integrantes del equipo con el
objetivo de obtener de primera mano los avances de las tareas y los obstáculos que se van
presentando a lo largo del desarrollo de la iteración
Una vez finalizado un Sprint backlog, se revisan con el usuario o cliente los productos
obtenidos (Sprint review) y si cumplen con las necesidades plasmadas por el usuario al inicio de
la iteración. Cada fin de un Sprint Backlog, se debe revisar los aspectos positivos y negativos
del mismo con el objetivo de poder utilizar estos para una mejor planificación de la siguiente
iteración a realizar.
4.5 Dynamic Systems Development Method (DSDM)
La definición de esta metodología, se ha realizado tomando como base las siguientes
referencias: [DSDM09], [MART91], [SMHR04], [WDSDM09], [JCCA08].
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 28 de 237
4.5.1 Descripción
La metodología Dynamic system development Method (en adelante DSDM), es una metodología
que surgió de un consorcio formado por 17 miembros fundadores en enero del 1994. El objetivo
de este consorcio era producir una metodología de dominio público que fuera independiente de
las herramientas y que pudiera ser utilizada en proyectos de tipo RAD (desarrollo de
aplicaciones rápidas).
4.5.2 Principios básicos
La estructura de esta metodología fue guiada por 9 principios: • El involucramiento del usuario es imperativo.
• Los equipos de DSDM deben tener el poder de tomar decisiones.
• El foco está puesto en la entrega frecuente de productos.
• La conformidad con los propósitos del negocio es el criterio esencial para la aceptación de
los entregables.
• El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución
del negocio.
• Todos los cambios durante el desarrollo son reversibles.
• Los requerimientos están especificados a un alto nivel.
• El testing es integrado a través del ciclo de vida.
• Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.
DSDM tiene las bases sentadas para el análisis sobre su aplicabilidad a un grupo bien definido
de proyectos software, los cuales deberán tener las siguientes características:
• Son proyectos interactivos con la funcionalidad visible en la interfase de usuario.
• De baja o media complejidad computacional.
• Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran
tamaño.
• Acotados en el tiempo.
• Con flexibilidad en los requerimientos.
• Con un grupo de usuarios bien definidos y comprometidos al proyecto.
Esta metodología planeta 5 fases en la construcción de un sistema, las cuales son:
• Estudio de factibilidad.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 29 de 237
• Estudio del negocio.
• Iteración del modelo funcional.
• Iteración del diseño y construcción.
• Implementación.
Figura 3: Ciclo de vida de un proyecto AMDD
4.5.3 Proceso de desarrollo
La metodología plantea que en la fase de estudio de la factibilidad, se permita determinar si la
metodología se ajusta al proyecto en cuestión, es decir, si las pautas dadas por DSDM pueden
utilizarse de manera optima para llevar acabo el sistema.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 30 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 características de alto nivel que deberá contener el software
y las prioridades de las mismas.
Cabe destacar que tanto la fase de estudio de factibilidad, como de estudio del negocio, son
tareas secuenciales y se realizan una única vez al principio del proyecto y las demás fases siguen
el modelo iterativo incremental integrado con la retroalimentación (feedback) del cliente y las
entregas frecuentes del producto.
En la iteración de modelo funcional, se realizan tanto tareas de análisis como desarrollo de
prototipos. Los prototipos no se descartan por completo, sino que a medida que su calidad va
aumentando, se va incluyendo en el sistema final.
Esta iteración genera un modelo funcional, el cual contiene el código del prototipo y los
modelos de análisis.
En la iteración de diseño y construcción, es donde se construye el sistema, dando como
resultado final, un sistema probado, que satisface los mínimos requisitos establecidos.
La iteración de implementación, consiste en pasar del entorno de desarrollo al entorno de
producción. Se da formación a los usuarios y finalmente se abre el sistema para que sea
utilizado. En esta fase, además de la liberación del sistema, se debe entregar manuales de
usuario e informes de revisión del proyecto.
En este punto, la metodología DSDM, define cuatro posibles situaciones:
• No se necesita realizar mayor desarrollo.
• Se han dejado de realizar un conjunto de requisitos importantes, y en este caso se tiene
reiniciar el proceso desde el principio.
• Se han dejado sin implementar funcionalidades críticas, por lo tanto se vuelve a la fase de
modelo funcional.
• Existen problemas técnicos que no se han podido resolver debido a la falta de tiempo, por lo
tanto, se corregirán realizando las iteraciones que hagan falta desde la fase de diseño y
construcción.
DSDM, no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto, ni
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 31 de 237
siquiera impone el desarrollo bajo un paradigma específico, funciona tanto para el modelo
orientado a objetos como para el modelo estructurado.
En la metodología DSDM, se incluye un nuevo término llamado timebox, que no es más que las
iteraciones a lo largo del ciclo de vida del proyecto. Debido a que cada timebox esta relacionado
con entregables al final de los mismos y de los feedback por parte de los clientes, constan de
tres fases:
• Investigación, donde se verifica que las actividades del timebox coincidan con la
arquitectura del sistema.
• Refinamiento, donde se realiza la producción de los artefactos planificados en la iteración.
• Consolidación, donde se completan los entregables verificando la calidad de los mismos.
4.6 Feature Driven Development (FDD)
La definición de esta metodología, se ha realizado tomando como base las siguientes
referencias: [CLEP09], [COAD98], [WFDD09].
4.6.1 Descripción
La metodología Feature driven development (en adelante FDD), se estructura alrededor de la
definición de features que representan las funcionalidades que debe contener el sistema a
desarrollar y tiene un alcance lo suficientemente corto como para ser implementado en un par de
semanas.
Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario
común que fomente, que los desarrolladores tengan un diálogo fluido con los clientes,
desarrollando entre ambos un modelo común del negocio.
4.6.2 Principios básicos
FDD, posee una jerarquía de features, siendo el del eslabón superior el “feature set”, que agrupa
un conjunto de features relacionados con aspectos en común del negocio. Por último se
establece el “major feature set” que contribuye a proveer valor al cliente en relación a un
subdominio dentro del dominio completo de la aplicación. Esta jerarquía utiliza los siguientes
formatos
• Para features: <acción> el <resultado> <de | para | sobre | por> un <objeto>
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 32 de 237
• Para feature sets: <acción><-endo> un <objeto>
• Para major feature sets: administración de <acción>
Ejemplos de esto:
• Calcular el total de la facturación de Noviembre (feature)
• Modificar el estado de las facturas de producción (feature)
• Administrar el perfil de los proveedores (feature)
• Haciendo una venta a un cliente (feature set)
• Cargando la facturación de los proveedores (feature set)
• Administración de Bancos (major feature set)
FDD, propone un ciclo de vida del software que consta de cinco procesos:
• Development an overall model.
• Build a features list.
• Plan by feature.
• Design by feature.
• Build by feature.
Donde las dos últimas fases se realizan tantas veces como iteraciones se planifiquen en el
desarrollo.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 33 de 237
Figura 4: Ciclo de vida de un proyecto FDD.
4.6.3 Proceso de desarrollo
La primera actividad plateada por FDD es: Development an overall model, la cual, consiste en
desarrollar un modelo global, que sugiere un cierto paralelismo con la construcción de la
arquitectura del software. Para la construcción de este modelo participan tanto los expertos en el
dominio como los desarrolladores. Con esto se intenta lograr:
• Un conocimiento global de la aplicación a construir,
• el entendimiento del negocio en que esta embebido,
• un primer bosquejo de los features del software y
• la definición de las restricciones y cuestiones no funcionales.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 34 de 237
La segunda actividad (Build a features list), comienza tomando el bosquejo de features
formulado durante la actividad anterior para refinar las funcionalidades incluidas. Una vez que
se han identificado las mismas se las agrupa jerárquicamente para poder estructurar el trabajo de
desarrollo; se realiza la priorización de las mismas basándose en la satisfacción al cliente.
La tercera actividad (Plan by features), toma como input la lista priorizada de la fase anterior y
establece los tiempos de las futuras iteraciones. En esta actividad participan el líder de proyecto,
el líder de desarrollo y el programador jefe. A medida que se realiza la planificación se delinean
los hitos de finalización de las iteraciones, dejando asentado cuales son los features y features
sets que estarán construidos en dichos hitos, en esta etapa también se incluye la delegación de
responsabilidades.
Las dos últimas actividades, Diseñar por features y construir por features, están relacionadas
con la parte productiva del proceso en que se construye la aplicación de manera incremental.
Para la iteración del diseño, el Jefe de programadores junto con un grupo de Programadores
expertos identifica las clases, atributos y métodos que necesita la funcionalidad requerida en un
feature. Mediante la utilización de diagramas UML se verifica que el diseño pueda ser
implementado.
Posteriormente en la etapa de construcción por feature, se proceden a desarrollar las clases
definidas en la anterior actividad con sus respectivas pruebas unitarias. Una vez que se pasa
estas pruebas es inspeccionado el código por equipos asignados a la revisión del feature en
desarrollo, una vez finalizado esta revisión se promueve el código a BUILD, siendo entregado a
Gestión de la configuración.
La metodología recomienda reuniones semanales entre el Líder del proyecto y el Jefe de los
programadores, donde, se permita revisar el estado de los features que se están desarrollando.
5 Comparativa entre metodologías ágiles
En esta sección se realizará una comparativa entre cada unas de las metodologías mencionadas
en la sección cuatro, tomando como base la referencia: [JCCA08].
Esta comparativa se basa en una serie de criterios relevantes, con los cuales se busca obtener las
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 35 de 237
características fundamentales de las metodologías en estudio. Dentro de los criterios a
considerar tenemos
• Ciclo de vida del proyecto, donde tomaremos como base el ciclo de vida estándar de un
proyecto.
• Soporte a la gestión en cada unas de las etapas del ciclo de vida del proyecto.
• Buenas prácticas, actividades y artefactos producidos en las distintas etapas planteadas por
la metodología.
• Estado actual de la metodología.
• Soporte a la calidad en el planteamiento de la metodología.
• Herramientas específicas que pueden dar soporte a la metodología en cuestión.
5.1 Criterios de comparación
En esta sección se detallará cada uno de los criterios necesarios para la comparativa entre las
metodologías ágiles en estudio.
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 estándar:
• Principio del proyecto.
• Especificación de requisitos.
• Análisis y Diseño.
• Codificación
• Pruebas unitarias.
• Pruebas de integración.
• Pruebas de sistemas.
• Pruebas de aceptación.
• Sistema en uso o mantenimiento.
En base a las etapas mencionadas anteriormente, se analizará si cada una de las metodologías en
estudio contempla estas etapas, si describe buenas prácticas y/o actividades y si sugiere
artefactos de salida por etapa, de acuerdo a esto, el resultado se muestra en la siguiente tabla
(ver tabla 1 – Ciclo de vida tradicional de un proyecto software en las metodologías ágiles):
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 36 de 237
Principio del
Proyecto Espec.
Requisitos Anális y Diseño
Codificación Pruebas Unitarias
Pruebas de Integración
Pruebas de Sistemas
Pruebas de Aceptación
Mantenimiento
Metodología SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA Programación Extrema (XP) X X X X X X X X X X X X X X X X Scrum X X X X X X X X X X X X Dynamic Systems Development Method (DSDM) X X X X X X X X X X X X X X X X X X Proceso Unificado ágil (AUP) X X X X X X X X X X X X X X X X X X X X X X X X X X X Agile Model Driven (AMDD) X X X X X X X X Feature Driven Development (FDD) X X X X X X X X X X X X
SG: Soporte a la gestión.
PD: Se describe un proceso en el método que incluye esta etapa.
BA: Buenas prácticas, actividades y artefactos considerados en la etapa.
Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologías ágiles.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 37 de 237
5.1.2 Estado Actual
Para este criterio se tomará en cuenta, los siguientes estados en los cuales se podría encontrar las
metodologías en estudio:
• Recién nacida, metodologías que tiene un año o menos y de la cual no tenemos evidencias ni
estudios.
• En construcción, metodologías con más de un año de existencia, pero que no dispone de
evidencia documentada.
• Activa, metodologías que llevan muchos años en el desarrollo del software y de las cuales
podemos encontrar evidencias y estudios que corroboren su efectividad.
• Olvidada, metodologías que llevan tiempo sin ser utilizadas y de las cuales no se encuentra
evidencia.
A continuación una tabla (ver tabla 2 – Estado actual de las metodologías ágiles), que informan
el estado actual de cada una de las metodologías en estudio:
Metodología Estado a la fecha
Programación Extrema (XP) Activa
Scrum Activa
Dynamic Systems Development Method (DSDM) Activa
Proceso Unificado Ägil (AUP) Actica
Agile Model Driven (AMDD) Activa
Feature Driven Development (FDD) Activa
Tabla 2: Estado actual de las metodologías ágiles
5.1.3 Calidad
Con este criterio se busca analizar si las metodologías en estudio contemplan ciertos parámetros
de calidad en su enunciado metodológico.
Dentro de los parámetros a considerar en el análisis tenemos:
• Fiabilidad, la cual viene determinada por los siguientes atributos:
� Simplicidad, simplicidad de los diseños, en la implementación y en el desarrollo del
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 38 de 237
software en general.
� Trazabilidad, entre los artefactos producidos en las distintas etapas del ciclo de vida del
software.
• Usabilidad, esta parámetro viene determinado por los siguientes atributos:
� Claridad y precisión de la documentación.
� Habilidades que mejoren las pruebas del software.
• Mantenibilidad, este parámetro viene determinado por los siguientes atributos:
� Modularidad, esto ayuda a crear una documentación mas fácil de entender.
� Simplicidad, si la metodología promueve que los sistemas desarrollados bajo su enfoque
sean simples al momento de mantenerse.
• Adaptabilidad.
� Portabilidad, si bajo su enfoque promueve que el software producido pueda operar en
distintos entornos.
A continuación una tabla (ver tabla 3 – Comparativa de calidad en las metodologías ágiles), que
informan, los criterios de calidad asociados a cada unas de las metodologías en estudio:
Metodología Fiabilidad Usabilidad Mantenibilidad Adaptabilidad Programación Extrema (XP) X X X Scrum X X
Dynamic Systems Development Method (DSDM) X X X Proceso Unificado Ágil (AUP) X X X Agile Model Driven (AMDD) X X X Feature Driven Development (FDD) X X
Tabla 3: Comparativa de calidad en las metodologías ágiles
5.1.4 Herramientas
Con este criterio se busca dar a conocer las distintas herramientas que las metodologías en
estudio requieren para cumplir cada unas de las tareas que especifica su enunciado. Para esto se
enfatizó la búsqueda de herramientas de libre distribución.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 39 de 237
A continuación, se presenta una tabla (ver tabla 4 – Herramientas de libre distribución para
metodologías ágiles), donde se detalla alguna de las herramientas de libre distribución, con las
cuales se puede ejecutar cada una de las metodologías en estudio:
Metodología Herramientas
Programación Extrema (XP)
o Herramientas para la realización de refactorización, IDEs como Eclipse y NetBeans.
o Herramienta de integración continua: Cruise Control.
o Herramientas de administración de proyectos y compilaciones automáticas: Maven y Ant.
o Repositorio de códigos: CVS y Subversión. o Herramientas para pruebas unitarias: JUnit. o Herramientas para la medición de rendimiento de
aplicaciones : JMeter
Scrum
A pesar de no ser necesaria ninguna herramienta especial, están surgiendo aplicaciones Web que facilitan el seguimiento del proyecto y la generación de los distintos artefactos de la metodología, que frecuentemente se realizan con paquetes ofimáticas.
Agile Model Driven (AMDD)
o Herramienta de diagramación de modelos: Visual Paradigm, eclipse (con plugins respectivos)
o Herramienta que te permite generar código en base a diagramas: AndroMDA encapsulado con funcionalidad de MAVEN.
Proceso Unificado Ägil (AUP)
Para esta metodología son necesarias las herramientas mencionadas tanto para le metodología XP como para AMDD, además de estas herramientas se podría mencionar:
o Herramientas de cobertura y evaluación de complejidad ciclomática: MAVEN.:
Dynamic Systems Development Method (DSDM)
No especifica ninguna práctica concreta que necesite de una herramienta específica.
Desarroollo rápido de aplicaciones (RAD)
o Herramientas que en base a prototipos genere código: IDEs como NetBeans y eclipse.
Feature Driven Development (FDD)
o Herramientas de modelado como Visual Paradigm. o Herramientas ofimáticas. o Herramientas de refactorización: IDEs como
eclipse y NetBeans.
Tabla 4: Herramientas de libre distribución para metodologías ágiles.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 40 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 metodologías ágiles contemplan todo el ciclo de vida tal y como lo hemos visto
tradicionalmente, como se puede apreciar en la Tabla 1, presentada en la comparativa de
ciclo de vida de un proyecto, la metodología que contempla todas las etapas es la
metodología AUP, esto debido a que es una metodología que se basa en RUP, pero a la vez
esta metodología sugiere que solo se utilice las etapas que sean necesarias para el proyecto,
con lo cual pude que se cumpla con toda o parte de las etapas tradicionales.
• El estado actual de las metodologías ágiles es activo y va ganando cada vez más adeptos.
• Las metodologías ágiles están orientadas a la productividad, es por este motivo que en la
comparativa de calidad solo algunas de las metodologías cumple con la gran parte de los
parámetros de calidad.
• Con relación a las herramientas de distribución libre, como se ha podido apreciar hoy en día
existen muchas herramientas que ayudan ya en el proceso de las metodologías ágiles (ver
Tabla 4).
5.3 Adopción de metodologías
Los criterios de comparación utilizados en esta sección son solo algunos de los criterios por los
cuales se puede llevar a cabo una comparativa entre metodologías ágiles y nos da una idea de
cual es el enfoque de la metodología en cuestión que nos permitirá decidir por una de las
metodologías presentadas.
La adopción de una o varias metodologías, en vez de otras, tan solo tiene sentido si
establecemos un caso lo suficientemente concreto, invalidando cualquier tipo de generalización
y por ende una metodología se hace necesaria para cada solución.
En base a lo expuesto a lo largo de esta sección, concluimos que las metodologías ágiles son un
conjunto de prácticas y métodos que surgen de la experiencia y el estudio de muchos proyectos
software, de acuerdo a esto, la elección de una u otra metodología será en base a las necesidades
que tenga un proyecto por ejemplo:
• Si el proyecto necesita pautas claras de gestión, se debería seleccionar Scrum y AUP.
La Usabilidad en Metodologías Ágiles Junio 2009 Metodologías Ágiles Version 3.0
José Germán Núñez Mori Página 41 de 237
• Si se ve que el proyecto presentará ratios de error elevados, se debe utilizar XP o AUP,
debido a que ambas metodologías hace uso del Test Driven Development (TDD).
• O quizás si es un proyecto interactivo con la funcionalidad visible en la interfase de usuario,
se debería optar por DSDM.
Para el caso de estudio que se llevará a cabo, y tomando como premisa que es un caso concreto
de investigación, donde se busca adaptar en la metodología o metodologías seleccionadas el
principio de Usabilidad, se ha visto conveniente combinar tres de las metodologías, con el
objetivo de dar una cobertura ágil a un ámbito más amplio del ciclo de vida del software. Las
metodologías seleccionadas son:
• Scrum, para la parte de gestión del proyecto.
• XP, por ser una metodología que cubre las actividades que desde el plano completo de la
ISO 12207, perteneciente al desarrollo de software.
• AUP, por ser una metodología que contiene a XP y tiene las formalidades de RUP.
La Usabilidad en Metodologías Ágiles
III. Marco Ágil de trabajo
Versión 1.2
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 43 de 237
Historia del documento
Fecha Version Descripción Autor
10/11/2009 1.0 Marco ágil de trabajo José Germán Núñez
Mori
06/06/2010 1.1 Marco ágil de trabajo José Germán Núñez
Mori
12/10/2010 1.2 Marco ágil de trabajo José Germán Núñez
Mori
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 44 de 237
1. Introducción De acuerdo a lo expuesto en el capítulo de “Metodologías ágiles”, se llego a la conclusión, de
seleccionar tres de las metodologías ágiles planteadas a lo largo del capítulo. Esta selección, se
realiza después de analizar que las metodologías ágiles son prácticas focalizadas sobre un área
de conocimiento, más o menos delimitada, de la Ingeniería del Software [JPAL02].
Con las metodologías ágiles seleccionadas, se busca combinar varias de las prácticas de cada
una de estas metodologías, para dar una mayor cobertura ágil a un ámbito más amplio del ciclo
de vida del software [JPAL02].
En el presente capítulo, se planteara un marco ágil de trabajo, que contenga ciertas prácticas y
actividades de cada unas de las metodología seleccionadas en el capitulo anterior (AUP, XP y
Scrum), todo esto, con el objetivo de obtener lineamientos a seguir a lo largo de los siguientes
capítulos, y en los cuales se pueda añadir los principios de Usabilidad.
2. Planteamiento metodológico
En la presente sección, se dará a conocer el planteamiento de este marco de trabajo ágil, que
busca combinar, practicas y actividades, de cada una la metodologías seleccionadas, que en
conjunto, se adapten a los requerimientos o necesidades del presente trabajo.
Las metodologías seleccionadas, como ya se ha descrito en el capitulo anterior (Metodologías
Ágiles) son: SCRUM, AUP y XP. De estas metodologías se ha analizado, tanto sus principios
básicos como su planteamiento metodológico, donde en base a este análisis, se ha llegado a la
conclusión, de utilizar ciertas actividades y prácticas de cada una de estas metodologías y así
obtener un marco ágil que se ajuste a lo requerido.
Las actividades y prácticas seleccionadas, tanto de las metodologías Scrum como AUP,
formarán la carrocería del marco ágil de trabajo. Esto debido, al enfoque que tienen estas
metodologías, consiguiendo de esta manera, los lineamientos para la gestión (plateada por
Scrum) y las formalidades del Proceso Unificado (planteada por AUP) en la ejecución del ciclo
de vida del software, con lo cual, se dejará a la metodología XP enfocada directamente en el
plano de desarrollo.
La metodología AUP, sugiere optar por un conjunto pequeño de actividades y artefactos del
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 45 de 237
Proceso Unificado [CRLA02] [JOKR05]. Siguiendo esta idea, se ha optado por utilizar ciertas
fases y actividades que plantea AUP, las cuales serán gestionadas por los lineamientos de
SCRUM. Consiguiendo de esta manera también incluir prácticas de XP en este marco ágil de
trabajo [SABL06] [KEBE02].
Bajo los lineamientos de este marco de trabajo ágil, se ira incluyendo los principios de
usabilidad, es decir, se buscará en todo momento mejorar la usabilidad como un atributo de
calidad, tomando en cuenta así, estos patrones desde la etapa inicial del marco ágil (requisitos),
luego trasmitiéndose a las etapas siguientes como son diseño e implementación.
3. Estructura Metodológica
En la presente sección, se describirá cual es la estructura que tendrá el marco ágil de trabajo y
en base al cual, se desarrollarán los siguientes capítulos.
El marco ágil de trabajo, se basará en el ciclo de vida del software plateando por AUP, a la cual
se le añadirá actividades y prácticas, tanto de la metodología Scrum como XP, es decir, se
tendrá como base el siguiente modelo [SABL06]:
Figura 5: Ciclo de vida AUP
Como se muestra en la figura 5, a simple vista es el modelo clásico planteado por el Proceso
Unificado. Sin embargo, este modelo es mas simple, debido a que reúne, en una única disciplina
como es la de Modelo: el modelado de negocio, requisitos y análisis y Diseño. El resto de
disciplinas como se pude apreciar coinciden con las planteadas por el Proceso Unificado
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 46 de 237
[KINT07].
El marco ágil de trabajo, tal cual se describe en líneas anteriores, seguirá la estructura planteada
por AUP, con la salvedad, de solo incluir ciertas disciplinas, como son: Modelo,
Implementación, Prueba, Despliegue y gestión de proyecto. De esta manera, el ciclo de vida que
plantea el marco ágil de trabajo, se muestra en la siguiente figura 6:
Figura 6: Ciclo de vida del marco ágil de trabajo
El modelo presentado en la figura 6 (Ciclo de vida del marco ágil de trabajo), es un modelo más
reducido que el plateado por AUP, esto debido, a que es un ciclo de vida que se adapta a las
necesidades, que el marco ágil, solventará a lo largo del presente trabajo. Además esta
formalidad que se asume, permitirá que en cada una de las fases y disciplinas, de este ciclo de
vida planteado, se pueda realizar el estudio de la viabilidad de incluir los principios de
usabilidad.
En la figura 6, se aprecia además, que en cada fase se manejan iteraciones, esto debido, a que el
marco ágil de trabajo, tendrá un enfoque de desarrollo iterativo, el cual se organizará en una
serie de mini proyectos de duración fija, llamado iteraciones. Donde el resultado de cada
iteración será una parte del sistema que pueda ser probada, integrada y ejecutada.
Estas fases plateadas por el marco ágil, no constituyen el antiguo ciclo de vida secuencial, si no
mas bien, la fase de inicio no es solo una fase de requisitos si una especia de fase de viabilidad,
donde se lleva a cabo solo el estudio suficiente para decidir si continuar. La fase de elaboración
no es la fase de requisitos o de diseño, si no que es una fase donde se implementa de manera
iterativa la arquitectura que constituye el núcleo central donde se mitigan las cuestiones de alto
riesgo y en la fase de construcción se implementan de manera iterativa el resto de requisitos de
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 47 de 237
menor riesgo y se prepara para el despliegue [SABL06] [CRLA02].
De acuerdo a esta estructura, a lo largo de esta sección se detallará, el planteamiento del marco
ágil de trabajo sobre cada una de las fases y disciplinas mencionadas anteriormente.
Adicionalmente al planteamiento, el marco ágil describirá el mecanismo a seguir para cumplir
con lo planteando, sugiriendo así, herramientas y formatos que ayudarán a cumplir este
objetivo.
3.1 Fases del marco ágil de trabajo
En esta sección se detallara cada una de las fases planteadas por el marco ágil de trabajo ver figura 2 (Ciclo de vida del marco ágil de trabajo). 3.1.1 Inicio (Inception)
Para esta fase de inicio el marco ágil de trabajo, plantea lo siguiente:
• Obtención de los requisitos funcionales y no funcionales de alto nivel, siguiendo el
planteamiento XP y tomando en cuenta los principios de usabilidad.
• Proceso de aceptación de los principios de usabilidad incluidos, considerando el
planteamiento AUP.
• Gestión de requisitos funcionales y no funcionales, siguiendo el planteamiento Scrum.
En base a estos puntos, se tendrá un hito de fase, el cual representará los artefactos que esta fase
producirá al final de la misma. De acuerdo a esto, los artefactos considerados como hito de fase
son los siguientes:
• Historias de Usuarios
• Pruebas de Aceptación de los requerimientos de usabilidad.
• Product Backlog (Cartera de productos).
Esta primera fase se resume en el siguiente diagrama (figura 7), donde se muestra tanto el
planteamiento como los hitos de la misma [SABL06]:
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 48 de 237
Figura 7: Hito de la fase de Inicio.
3.1.2 Historias de Usuarios
Los requisitos tanto funcionales como no funcionales, serán obtenidos en base a lo sugerido por
la metodología XP, que son las llamadas Historias de usuarios, que es donde los usuarios, dan a
conocer las funcionalidades que esperan del producto. Cada historia de usuario a considerarse
como parte del producto final, será registrada siguiendo el siguiente formato [SALECA05]
[KEBE02]:
Nombre: Prioridad:
Descripción
Usuario de Creación Fecha Alta:Estimación. Dependencia:
Historia de Usuario Nº : <<Descripción abreviada>>
Figura 8: Formato de Historias de usuarios según XP
Sobre este formato (ver figura 8), el marco ágil de trabajo, incluirá la manera para elicitar los
requisitos de usabilidad, buscando así, incluir los principios de usabilidad desde la fase de toma
de requerimientos, con el objetivo de obtener los mismos beneficios que teniendo en cuenta
otros atributos de calidad en los inicios de los procesos de desarrollo. De acuerdo a esto, el
marco ágil plantea, un nuevo formato para recoger las historias de usuarios y a su vez los
requisitos de usabilidad:
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 49 de 237
Nombre: Prioridad:
Descripción
Usuario de Creación Fecha Alta:Estimación. Dependencia:
Apicación
Historia de Usuario Nº : <<Descripción abreviada>>
Globall Undo
Requisitos de Usabibilidad AsociadosRequisito Comentarios
System Status Feedback
Interaction feddback
Progress feedback
Warning
Object Specific undo
Figura 9: Formato de Historias de usuarios según el marco ágil.
Como se puede apreciar en la figura 9, el marco ágil de trabajo, adiciona al formato de historias
de usuario una sección para recoger los requisitos de usabilidad relacionados a una historia en
particular. Es por este motivo, que en la sección de requisitos de usabilidad, se listarán todos los
requisitos contemplados, dando así la opción al usuario que hace uso de este formato de
seleccionar el requisito asociado y describir la manera en que se debe plasmar en una historia.
El marco ágil de trabajo, sugiere que este formato se debe plasmar o en cartillas o en un
documento electrónico, el cual debe entregarse al usuario para ser rellenado con la información
de las funcionalidades a contemplarse y sus respectivos principios de usabilidad asociados, no
siendo estrictamente, un documento a ser rellenado por los usuarios, si no también por los
encargados de la elicitación de requisitos.
3.1.3 Pruebas de Aceptación
Como un artefacto de salida de esta fase inicial, se debe contemplar procesos de aceptación, que
garanticen la calidad del producto final. De acuerdo a esto, la metodología AUP, plantea una
serie de procesos de aceptación, de donde, solo se tomará uno de ellos que ayude a garantizar la
calidad de los principios de usabilidad a incluir en el ciclo de vida del software plateado.
El proceso de aceptación seleccionado es el llamado pruebas de aceptación, que son
básicamente pruebas funcionales sobre el sistema completo y que buscan una cobertura de la
especificación de requisitos. En nuestro caso de estudio, estas pruebas de aceptación buscarán la
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 50 de 237
cobertura de la especificación de los requisitos de usabilidad elicitados.
En esta fase de Inicio, las pruebas de aceptación, según el marco ágil de trabajo, consistirán en
la redacción de pruebas mínimas para la validación de los requisitos de usabilidad, las cuales se
basarán estrictamente en las historias de usuarios asociados. De acuerdo a esto, el proceso de
aceptación tendrá el siguiente formato, mostrado en la figura 10:
Id HistoriaCriterio de validación
de los Requisitos de Usabilidad
Figura 10: Formato de Pruebas de Aceptación.
Para este formato (ver figura 10) de pruebas de aceptación, el marco ágil, sugiere se plasme en
un documento electrónico y se rellene por cada historia de usuario las pruebas mínimas que
garanticen el funcionamiento esperado de los requisitos de usabilidad asociados. Siendo este
documento redactado por los encargado del análisis de las historias de usuarios.
Este artefacto una vez culminado, deberá de ser entregado al equipo de pruebas, con el objetivo,
de tomar futuras previsiones en las pruebas generales del sistema.
3.1.4 Product Backlog
Cada historia registrada por los usuarios, será gestionada para su resolución, por medio del
Product Backlog, que es el inventario de funcionalidades, mejoras, tecnologías y corrección de
errores, que deben incorporarse al producto a lo largo de sucesivas iteraciones [JPAL02].
El Product Backlog, es un documento vivo, que evoluciona de forma continua, mientras el
producto va creciendo, este artefacto es planteado por la metodología Scrum y será un artefacto
utilizado por el marco ágil.
Esta manera de llevar el control de cada historia de usuario es simplemente, con el objetivo de
tener a primera vista y de manera muy resumida, las funcionalidades que se espera del producto.
Además a este artefacto tendrán acceso todos los integrantes del equipo. Por lo tanto, el Product
Backlog seguirá el siguiente formato [JPAL02]:
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 51 de 237
Id. Historia Descripción Prioridad Estimación Observaciones Responsable
Figura 11: Formato del Product Backlog
Como se puede apreciar en la figura 11, el Producto Backlog, es un listado en donde se tendrá el
control de todas las historias de usuarios registradas, de una manera mucho mas resumida, y que
permitirá de una manera más ágil tener una visión global de todas las funcionalidades del
producto.
El marco ágil de trabajo, sugiere que este formato sea plasmado en un documento electrónico y
sea rellenado y gestionado por el encargado de llevar a cabo el producto, garantizando de esta
manera que este accesible a todas las personas que participan en el desarrollo del sistema.
3.1.5 Elaboración
En esta fase el marco ágil de trabajo, basará su enfoque en lo que plantea la metodología AUP
(Agile Unified Process), tomando en cuenta así las disciplinas y prácticas sugeridas.
El objetivo principal de la fase de elaboración es probar la arquitectura del sistema a
desarrollar. El punto es asegurar que el equipo realmente puede desarrollar un sistema que
satisfaga los requisitos, y la mejor manera de hacerlo es construir un esqueleto del sistema,
llamado un "prototipo de la arquitectura" [SABL06].
Es importante señalar que los requisitos no se especifican por completo en este punto. Se
detallan sólo lo suficiente para entender los riesgos de la arquitectura a plantear y para asegurar
que hay un entendimiento del alcance de cada requisito, todo esto, con el objetivo de la futura
planificación a llevarse a cabo y de identificar y priorizar los riesgos de la arquitectura, donde,
los mas significativos serán tratados en esta fase de elaboración [SABL06].
Como se muestra en la figura 6 (Ciclo de vida del marco ágil de trabajo), la disciplina de
modelo (Model) que se ejecuta tanto en la fase de inicio como la de elaboración, sugiere que,
para esta última, se inicie con el diseño, específicamente como se describe en líneas anteriores,
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 52 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:
• Identificación de la arquitectura, basada en la metodología MDA.
• Realizar el plan de ejecución de las primeras iteraciones de construcción.
De acuerdo a estos puntos la fase de elaboración cuenta con un hito de fase, que representa los
artefactos que esta fase producirá al final de la misma. Estos son los siguientes:
• Prototipo de la arquitectura del sistema.
• Plan de ejecución de la primera iteración de construcción.
Esta fase se resume en el siguiente diagrama (ver figura 12), donde se muestra tanto el
planteamiento como los hitos de la misma [SABL06]:
Figura 12 : Hito de la fase de Elaboración
Como paso siguiente de esta sección, se detallará cada uno de los puntos planteados como hito,
describiendo de esta manera los mecanismos para obtener los artefactos de salida de esta fase de
elaboración.
3.1.6 Prototipo de la arquitectura del sistema
Cuando el marco ágil de trabajo, emplea el término de prototipo de arquitectura, hace referencia
a que en esta fase de elaboración, se debe obtener un primer modelo de la arquitectura del
sistema, donde se reúna las partes, las conexiones y las normas de interacción entre los
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 53 de 237
componentes de este sistema, haciendo uso de conexiones especificas y sobre los que se basarán
las posteriores modificaciones en implementaciones a realizar.
En base a esta premisa, el marco ágil de trabajo, basado en las distintas metodologías de su
planteamiento, buscará un enfoque de metodología, que permita obtener este primer modelo de
arquitectura y que esta sirva como estructura principal para las futuras iteraciones de desarrollo.
AUP (Agile Unified Process) incluye en su planteamiento una metodología que ayudará en las
tareas de modelado de la arquitectura. Esta metodología es conocida como Agile model driven
development (AMDD), que en su enfoque principal sugiere que el desarrollo de un sistema sea
dirigido por modelos lo suficientemente necesarios para obtener el producto final [SABL06].
Para tener mayor detalle de la metodología AMDD, se puede revisar el capitulo de
“Metodologías Ágiles”.
El marco ágil de trabajo, basado en AUP, hará uso del planteamiento de AMDD para desarrollar
su enfoque de prototipo de Arquitectura y sus futuras iteraciones de desarrollo, específicamente
utilizando el estándar sugerido por esta metodlogía, siendo este, el estándar MDA (Model
Driven Architecture).
MDA es un estándar, que potencia el uso de modelos en el desarrollo, debido a que usa los
modelos para dirigir el ámbito de desarrollo, el de diseño, el de despliegue, el de la operación, el
de mantenimiento y el de la modificación de los sistemas.
En el marco ágil de trabajo, MDA pretende ser utilizado para dirigir tanto el ámbito desarrollo
como el de diseño. Bajo este estándar el marco ágil, en esta fase de elaboración, tendrá como
objetivo realizar una primera iteración que permita obtener una parte del sistema que pueda ser
probada, integrada y ejecutada.
Esta primera iteración, contemplará la ejecución del prototipo de arquitectura, que consistirá en
obtener tanto el diseño de este prototipo como el desarrollo del mismo. De esta manera se
cumplirá con el objetivo de esta fase, que es la implementación de la arquitectura que constituye
el núcleo central donde se mitigan las cuestiones de alto riesgo y cuyo propósito será ayudado
por el estándar MDA.
Para este prototipo de arquitectura, el marco ágil, sugiere que se selecciona un requisito donde
se pueda evaluar los riesgos de la arquitectura y a su vez tenga asociado los requisitos de
usabilidad de mayor complejidad, como por ejemplo: Progress Bar.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 54 de 237
A continuación, se detallara la especificación del estándar MDA, buscando así entender, el
desarrollo dirigido por modelos y cómo se hará uso del mismo para lograr obtener uno de los
hitos de esta fase (Prototipo de la Arquitectura)
3.1.7 Estándar MDA (Model Driven Architecture)
En esta sección se detallará la especificación del estándar MDA, basado en la siguientes
referencias: [LECCO09], [MDAWI10], [OMGWB10].
La arquitectura dirigida por modelos (Model Driven Arquitectura) es una especificación
detallada por el OMG (Object Management Group) que integra diferentes especificaciones y
estándares definidos por la misma organización, con la finalidad de ofrecer una solución a los
problemas relacionados con los cambios en los modelos de negocio, la tecnología y la
adaptación de los sistemas de información a los mismos.
MDA nos permite el despliegue de aplicaciones empresariales, diseñadas sin dependencias de la
plataforma de despliegue y expresando su diseño mediante el uso de UML y otros estándares.
Donde estos estándares, pueden ejecutarse en cualquier plataforma existente, abierta o
propietaria, como servicios web, .Net, Corba, J2EE, u otras.
La especificación de las aplicaciones y la funcionalidad de las mismas se expresan en un
modelo independiente de la plataforma que permite una abstracción de las características
técnicas específicas de las plataformas de despliegue. Mediante transformaciones y trazas
aplicadas sobre el modelo independiente de la plataforma se consigue la generación automática
de código específico para la plataforma de despliegue elegida.
Todo esto proporciona finalmente una independencia entre la capa de negocio, y la tecnología
empleada. De esta manera es mucho más simple la incorporación de nuevas funcionalidades, o
cambios en los procedimientos de negocio sin tener que llevar a cabo los cambios en todos los
niveles del sistema. Bajo este enfoque el marco ágil de trabajo buscará incluir en tiempo de
diseño los patrones de usabilidad.
Siguiendo este planteamiento, se desarrollan los cambios en el modelo independiente de la
plataforma, y éstos se propagarán a la aplicación, consiguiendo por tanto, una considerable
reducción del esfuerzo en el equipo de desarrollo. De esta manera también, se disminuye los
errores que tienden a producirse en los cambios introducidos en las aplicaciones mediante otros
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 55 de 237
métodos de desarrollo, y por consiguiente, la reducción de costes y aumento de productividad.
MDA se apoya sobre los siguientes estándares para llevar a cabo su función:
• UML (Unified Modeling Language): empleado para la definición de los modelos
independientes de la plataforma y los modelos específicos de las plataformas de destino. Es
un estándar para el modelado introducido por el OMG.
• MOF (MetaObjet Facility): establece un marco común de trabajo para las especificaciones
del OMG, a la vez que provee de un repositorio de modelos y metamodelos [OMGWB10].
• XMI (XML Metada Interchange): define una traza que permite transformar modelos UML
en XML para poder ser tratados automáticamente por otras aplicaciones.
• CWM (Common Warehouse Metamodel): define la transformación de los modelos de datos
en el modelo de negocio a los esquemas de base de datos [OMGWB10].
El estándar MDA, establece tres puntos de vista que se emplearán a lo largo de su proceso de
ingeniería:
• Punto de vista independiente de la computación, el cual se centra en el entorno del sistema y
los requisitos para el mismo. Los detalles de la estructura y procesamiento del sistema no se
muestran, o aún no están especificados.
• Punto de vista independiente de la plataforma: se centra en las operaciones del sistema,
mientras oculta los detalles necesarios para una determinada plataforma. Muestra aquellas
partes de la especificación del sistema que no cambian de una plataforma a otra. En este
punto de vista debe emplearse lenguaje de modelado de propósito general, o bien algún
lenguaje específico del área en que se empleará el sistema, pero en ningún caso se
emplearán lenguajes específicos de plataformas.
• Punto de vista de plataforma específica: combina el punto de vista independiente de la
plataforma con un enfoque específico para su uso en una plataforma específica de un
sistema.
En base a estos puntos de vista, MDA plantea diferentes estados de modelado para lograr
obtener el producto final. Estos modelos son los siguientes:
• Modelo independiente de la computación (CIM), es una vista del un sistema desde el punto
de vista independiente de la computación. En algunos casos, nos referimos a este modelo
como el modelo de dominio y se usa vocabulario propio de los expertos en el dominio para
la especificación.
• Modelo independiente de la plataforma (PIM), es una vista del sistema del punto de vista
independiente de la plataforma, exponiendo así un carácter independiente de la plataforma
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 56 de 237
sobre la que se desplegará. Con esto se logra un modelo que puede ser empleado en
diferentes plataformas de carácter similar.
• Modelo específico de la plataforma (PSM), es una vista del sistema (producto final) desde el
punto de vista específico de la plataforma, combinando así el modelo independiente de la
plataforma con los detalles específicos de la plataforma del sistema.
3.1.7.1.1.1 Usando MDA
Expuestos los conceptos básicos de MDA, a continuación, se dará a conocer como se relacionan
los modelos, su modo de uso y las transformaciones entres ellos.
El modelo de origen es el CIM (Modelo independiente de la computación), con el que se
modelan los requisitos del sistema, describiendo la situación en que será usado en el sistema y
que aplicaciones se espera que el sistema lleve a cabo, sirviendo tanto como ayuda para
entender el problema o como una base de vocabulario para usar en los demás modelos.
Los requisitos recogidos en el CIM (Modelo independiente de la computación) han de ser
trazables a lo largo de los modelos PIM (Modelo independiente de la plataforma) y PSM
(Modelo especifico de la plataforma) que los implementan.
El CIM, puede consistir en un par de modelos UML que muestren tanto la distribución de los
procesos (ODP, Open Distributed Processing) como la información a tratar. También puede
contener algunos modelos UML más que especifiquen en mayor detalle los anteriores.
A partir del CIM, se construye un PIM, que muestra una descripción del sistema, sin hacer
referencia a ningún detalle de la plataforma. Debe presentar especificaciones desde el punto de
vista de la empresa, información y ODP. Un PIM se puede ajustar a un determinado estilo de
arquitectura, o a varios.
Después de la elaboración del PIM, el arquitecto debe escoger una plataforma (o varias) que
satisfagan los requisitos de calidad y en base a la trazabilidad obtener el PSM. La figura 13,
resume el planteamiento de estos modelos:
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 57 de 237
Figura 13: Trazabilidad de Modelos MDA
3.1.7.1.1.2 Mapas de Transformación MDA
Mediante mapas, MDA especifica las reglas de transformación de un PIM (Modelo
independiente de la plataforma) a un PSM (Modelo específico de la plataforma) para una
plataforma en concreto. Estos mapas incluyen la transformación de tipos de valores, así como
los metamodelos y sus reglas para la transformación en tipos de valores existentes en las
plataformas específicas.
Cuando se prepara un modelo haciendo uso de un leguaje independiente de la plataforma
especificada en un metamodelo y posteriormente se elige una plataforma para el despliegue,
debe existir una especificación de transformación entre el metamodelo independiente de la
plataforma y el metamodelo que describe la plataforma. La figura 14, ilustra este requisito:
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 58 de 237
Figura 14: Transformación de metamodelos bajo MDA.
Una forma de facilitar la transformación de modelos es la identificación de elementos en el PIM
que deben transformarse de una manera concreta para la plataforma de destino, y marcarlos
como tal. Una marca expresa un concepto del PSM en el PIM; las marcas alejan el PIM de la
independencia de la plataforma, por lo que un arquitecto debe mantener un PIM limpio, donde
las marcas deben concebirse como una capa transparente que se pone sobre el modelo.
Figura 15: Marcado de un modelo bajo MDA
En la Figura 15, se ilustra el uso de marcas como ayuda para la transformación, y su situación
intermedia entre la independencia y la dependencia de la plataforma. Una vez es elegida la
plataforma, existe un mapa para la transformación de modelos. Este mapa incluye un conjunto
de marcas, que usamos para marcar los elementos del PIM como guía para la transformación del
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 59 de 237
modelo.
Las marcas pueden definir tipos del modelo, especificación de clases, asociaciones, roles,
estereotipos, etc. Las marcas también pueden especificar características cualitativas que después
en la transformación se convertirá en el objetivo apropiado para el cumplimiento de los
requisitos.
Los mapas de transformación pueden mantener también plantillas, que son modelos
parametrizados que especifican tipos concretos de transformaciones. Podemos asociar un
conjunto de marcas a una plantilla para identificar instancias en un modelo que deben ser
transformados de acuerdo a las indicaciones de la plantilla.
Existe la posibilidad de incluir información relativa a patrones que extienda las características y
tipos de los metamodelos y el lenguaje de la plataforma específica elegida para el despliegue.
Como muestra la figura 16, el uso de información adicional para la transformación implica la
necesidad de información de los patrones para la transformación, que serán específicos para la
plataforma de destino.
Figura 16: Patrones de transformación en los modelos MDA
3.1.7.1.1.3 Transformaciones de modelos MDA
El siguiente paso al establecimiento de las marcas en los modelos y la selección de mapas de
transformación es aplicar la transformación desde el PIM (Modelo independiente de la
plataforma) marcado al PSM (Modelo especifico de la plataforma). Este proceso puede ser
manual, asistido por computador, o automático.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 60 de 237
La transformación, es el proceso que toma como entrada el PIM marcado y da como resultado el
PSM del sistema y el registro de transformación.
Algunas herramientas, pueden hacer una transformación del PIM directamente a código
desplegable en la plataforma de destino o incluso, conceptos como MDR (Model-Driven
Runtime Environment), que propone el uso de un entorno de ejecución para los PIM,
directamente, sin generación de PSM ni código para la plataforma. En cualquier caso el OMG
sostiene que la transformación debe emitir un PSM para ayudar al entendimiento del código y la
depuración del mismo.
El registro de transformación incluye una traza desde cada elemento del PIM a los elementos
correspondientes en el PSM, especificando que parte de los mapas de transformación fueron
empleados para derivar los elementos del PSM desde los elementos del PIM. Una herramienta
que mantenga los registros de transformación debe ser capaz de sincronizar de forma automática
los cambios producidos en un modelo al otro.
El PSM producido por una transformación es un modelo del mismo sistema que ha sido
especificado en el PIM. También especifica como el sistema hace uso de una determinada
plataforma.
Un PSM, será una implementación del sistema si proporciona toda la información necesaria
para construir el sistema y ponerlo en marcha.
Una vez descrita y explicada la estrategia del estándar MDA, el marco de ágil de trabajo,
siguiendo lo descrito por este estándar, sugiere que todo este mecanismo de planteamiento
MDA, sea dirigido de manera automática y asistida por algún Framework (marco de trabajo),
que permita contemplar gran parte de este especificación y cuya curva de aprendizaje sea
minima para los desarrolladores.
El Framework que se ajusta a las necesidades del presente trabajo, al planteamiento del estándar
MDA y lo que requiere el marco ágil de trabajo es el Framework AndroMDA.
Como paso siguiente en el planteamiento del prototipo de arquitectura del sistema, se describirá
el Framework seleccionado (AndroMDA), que permitirá realizar las labores de modelado que se
ajusten a lo planteado por el estándar MDA y a su vez ayuden al marco ágil de trabajo a cumplir
con el hito de esta fase de elaboración.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 61 de 237
3.1.7.1.2 AndroMDA
En esta sección se detallará en que consiste este Framework y de cómo será utilizado por el
marco ágil de trabajo, detallando así, las distintas utilidades de este Framework y de cómo estas
ayudarán a cumplir con el objetivo de este trabajo. La explicación de esta sección se ha basado
en la siguiente referencia: [AMDA10].
Esta herramienta, es un marco de generación extensible que se adhiere al paradigma MDA y que
toma cualquier número de modelos (usualmente modelos UML guardados en formato XMI
producidos por alguna herramienta case), que en combinación con plugins de la propia
herramienta (Plantillas y bibliotecas de traducción), produce componentes personalizados, es
decir, se puede generar componentes en un gran número de lenguajes entre los que se encuentra:
Java, .Net, HTML, PHP, etc.
El código generado por AndroMDA, es automáticamente integrado al proceso de construcción,
siendo esta generación muy eficiente para la aplicación a partir de un modelo independiente de
la plataforma, lo que produce así, la columna vertebral del proyecto, permitiendo de esta manera
que los desarrolladores se mantengan enfocados en la lógica del negocio.
De acuerdo a lo que AndroMDA proporciona, el presente trabajo pretenderá que el desarrollo de
este proyecto se realice sobre una plataforma java, específicamente bajo J2EE. Según esto, el
marco ágil de trabajo, a lo largo de esta sección ira detallando la manera de configurar un
proyecto J2EE utilizando AndroMDA.
3.1.7.1.2.1 MDA en la generación de código de AndroMDA
En el sentido clásico de la Ingeniería de Software, uno de los primeros elementos es determinar
qué es lo que el sistema tiene que hacer (fase de análisis). En esta fase el arquitecto o
desarrollador tiene algo en la mente que será traducido hacia un documento específico (modelo
o texto). Luego, necesitará implementar ese entregable, para lo cual requerirá una persona o un
grupo de personas que implementen esa transformación en un lenguaje como C, JAVA, C++,
etc.
Con el estándar MDA, lo que se intenta es simplificar el trabajo del desarrollador/arquitecto, a
través de la digitalización de ideas que él/ella tengan en mente (Mental Model MM o CIM). Por
esta razón, el desarrollador/arquitecto debe crear un modelo independiente de la plataforma
(PIM), es decir, transformar del lenguaje mental a uno formal como por ejemplo UML. Este
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 62 de 237
enfoque tiene muchas ventajas algunas de ellas se listan a continuación:
• Es un proceso de transformación muy sencillo y directo
• El desarrollador/arquitecto mantiene el enfoque en la lógica del negocio.
• PIM (Modelo independiente de la plataforma), puede ser re-utilizado luego. No está acotado
a la plataforma actual.
• PIM es un excelente medio para comunicar ideas a otras personas.
El próximo paso es encontrar la manera para transformar el PIM hacia el código. La forma
MDA de lograr esto es, ir individualmente refinando el modelo hasta llegar al modelo especifico
de la plataforma a utilizar (PSM) y pasar de este modelo a código escrito manualmente
Este es el punto en el cual AndroMDA actúa, pues posee diferentes cartuchos o Cartridges
(plugins), que analizaran el PIM dado y construirán el PSM. Luego, de construido éste se usaran
plantillas para producir el código, donde, el código generado es un lenguaje que nunca
necesitará ser modificado manualmente, sin embargo de ocurrir el caso, existen formas
elegantes para resolver este tipo de problemas.
Figura 17: Ciclo AndroMDA de generación de código
Como se puede apreciar en la figura 17, una vez interpretado el modelo UML, para generar el
código de un lenguaje determinado, se hace uso de los Cartridges o cartuchos, que son
elementos que interpretan determinadas marcas en el modelado como por ejemplo los
estereotipos de UML (entidad, numeración, etc) o en su defecto, condiciones inferidas del
modelo, como la dependencia de los actores hacia un componente marcado como servicio.
Una vez interpretado tanto las condiciones o marcas en el modelado, estos cartuchos, cuentan
con diferentes plantillas de los recursos necesarios para la generación de código de un lenguaje
o tecnología determinada.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 63 de 237
Estos Cartridges o cartuchos, son importantes en el proceso de transformación de código de
AndroMDA y cada uno ellos pueden ser personalizados de acuerdo a las necesidades requeridas.
Por otro lado, es muy importante tomar en cuenta que AndroMDA, ayuda a eliminar las tareas
repetitivas de desarrollo, mientras que al mismo tiempo permite que tu modelo pueda
asemejarse con lo que realmente el sistema hace. Esto no significa que la computadora hará todo
el trabajo por el desarrollador y esté deje de pensar.
3.1.7.1.2.2 Arquitectura del marco ágil de trabajo según AndroMDA
Según se describe en líneas anteriores, el proyecto se pretende realizar bajo la plataforma J2EE,
siguiendo así una arquitectura de N niveles o capas distribuidas, basándose ampliamente en
componentes de software modulares y que serán ejecutados en un servidor de aplicaciones.
Bajo esta premisa, el marco ágil de trabajo se basara en la siguiente estructura:
Figura 18: Arquitectura de Aplicación base del marco ágil de trabajo
Como se puede apreciar en la figura 18, se presenta una estructura de capas populares de una
aplicación empresarial, donde se cuenta con los siguientes niveles:
• Capa de presentación (Presentation layer), que contiene los elementos necesarios para
interactuar con el usuario de la aplicación
• Capa de negocio (Business layer), encapsula la funcionalidad del negocio principal de la
aplicación, accediendo a esta capa por medio de una fachada de servicios, que oculta la
complejidad que alberga la misma.
• Capa de acceso a datos (Data Access layer), contiene los elementos necesarios para acceder
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 64 de 237
a los datos subyacentes de la aplicación, abstrayendo de esta manera la semántica de la
tecnología de acceso a estos y permitiendo de esta manera que la capa de negocio se centre
en la lógica del sistema.
• Almacén de datos (Data Store), base de datos o sistema de archivos.
Ahora que se ha mostrado la estructura de las aplicaciones de empresas modernas en la que se
basará el marco ágil de trabajo (ver figura 18), se detallara como AndroMDA ayuda a
implementar estos conceptos.
AndroMDA, toma como entrada un modelo de negocio especificado en UML y generará una
parte significativa de las capas o niveles necesarios para construir una aplicación Java, esto
debido a que este Framework, tiene la capacidad de traducir de manera automática
especificaciones de alto nivel empresarial, en código de calidad ahorrando así un tiempo
significativo para el desarrollo de aplicaciones.
A continuación, se presenta la estructura de aplicación empresarial que plantea AndroMDA y
cada una de las tecnologías que soporta la misma en cada uno de los niveles o capas
contempladas:
Figura 19: Estructura de Aplicación empresarial AndroMDA
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 65 de 237
Como se pude apreciar en la figura 19, por cada nivel que presenta la arquitectura se muestran
las tecnologías Java soportadas por este Framework. A continuación se describe la selección de
las tecnologías por capa que ha optado utilizar el marco ágil de trabajo, en base a la estructura
presentada por AndroMDA:
• Capa de presentación (Presentation layer), se ha optado por utilizar la tecnología Struts, que
ayudara a generar componentes Web.
• Capa de negocio (Business layer), en esta capa se utilizará una tecnología que siga el
modelo POJO (Plain Old Java Object) y que sea del tipo no intrusivo. Ante esto, se ha
optado por utilizar el Framework Spring.
• Capa de acceso a datos (Data Access layer), se utilizará una tecnología de mapeo relacional
de objetos llamada Hibernate.
• Almacén de datos (Data Store), se puede utilizar cualquiera base de datos, para este trabajo
se utilizará la base de datos Hypersonic.
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 metodología (AMDD), el estándar (MDA) como el
Framework (AndroMDA), que ayudarán en conjunto, en base a sus planteamientos al marco
ágil de trabajo, a conseguir este hito de salida de la fase de elaboración.
En secciones de este apartado, se ha ido detallando el planteamiento del marco ágil de trabajo
para conseguir este hito de fase (Prototipo de Arquitectura), que en resumen, es un
planteamiento basado en el diseño de modelos para conseguir los componentes necesarios de
una funcionalidad determinada.
Ya en esta sección, es donde, se detallará cada uno de los tipos de modelos y sus componentes,
que AndroMDA sugiere utilizar para el diseño y que permitirán obtener los recursos necesarios,
para el prototipo de arquitectura.
Siguiendo la estructura de aplicación de AndroMDA (ver figura 15 - Estructura de Aplicación
empresarial AndroMDA), se explicará por cada nivel de esta estructura, los modelos implicados
que permitan, obtener la codificación básica de los componentes de este prototipo de
arquitectura.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 66 de 237
• Modelado en la capa de presentación: Este nivel como se comenta en secciones anteriores permite la interacción con el usuario, es por
esta razón que AndroMDA por medio de ciertos modelos UML llegará a obtener los recursos
necesarios para el funcionamiento de esta capa.
Con el objetivo de plasmar los diferentes eventos y cambios de estado que se generan en esta
capa de presentación, AndroMDA, plantea modelar este comportamiento en base a diagramas
de actividad y estereotipos UML
Figura 20: Diagrama de Actividad en AndroMDA
Como se pude apreciar en la figura 20, se muestra el diseño de una determinada funcionalidad
en la capa de presentación, plasmando así, sus estados de inicio y fin, sus eventos por ejemplo
“cancelar”, sus cambios de estado, sus decisiones, etc, lo cual representa las interacciones del
usuario con el sistema.
El proyecto será ejecutado en base a servicios Web (bajo plataforma J2EE), lo cual implica que
la interacción del usuario con el sistema, será llevada por medio de páginas JSP (basadas en
tecnología Struts).
El diseño mostrado en la figura 20, representa las transiciones (flechas) y estados (cajas) que
tendrá una página JSP, para procesar una determinada petición de usuario y su respectiva
respuesta.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 67 de 237
Para poder indicar, en un diagrama de actividad AndroMDA, que un de estos estados
representará una página JSP, se deberá marcar por medio del estereotipo <<FrontEndView>>,
de no ser así, representarán estados que serán procesados por el sistema, en esta caso y
siguiendo la tecnología Struts, deberá ser procesado por una clase controladora.
Para modelar las clases controladoras asociados a las páginas JSP, será necesario modelar un
diagrama de clase, en donde, la clase que haga de controlador, tenga referencia al diagrama de
actividad y las operaciones necesarias para resolver cada uno de los estados asociados al sistema.
La figura 21 muestra el diseño de una clase controladora:
Figura 21: Componente controlador en AndroMDA
Los diagramas de actividad, como sus respectivos controladores, representarán tanto las
acciones como las operaciones que resuelven las peticiones del usuario.
AndroMDA, con el objetivo de modelar las funcionalidades que tendrá el sistema, sugiere
modelar estas en función de diagramas de casos de uso (ver figura 22).
Figura 22: Casos de Uso AndroMDA
Cada caso de uso diseñado (ver figura 22), tendrá que relacionarse con un diagrama de actividad
y estos a su vez a una clase controladora respectiva, que en conjunto representarán, la operativa
necesaria para atender las peticiones de los usuarios, asociadas a una funcionalidad determinada.
• Modelado en la capa de Negocio:
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 68 de 237
En este nivel, como se ha ido detallando en secciones anteriores, se pretende modelar el núcleo
de una aplicación. AndroMDA, sugiere para esta capa modelar componentes de tipo servicio,
que representen cada una de las clases necesarias para resolver las funcionalidades del sistema
Estos tipos de servicio, representarán fachadas que ocultan la lógica de negocio que se pretende
plasmar a este nivel, permitiendo así de esta manera menos acoplamiento tanto con la capa de
presentación, como con la capa de Datos. La figura 23 muestra este diseño:
Figura 23: Modelado de servicios en AndroMDA
En la figura 23, se muestran componentes de un diagrama de clase, con la particularidad, de
estar marcado por el estereotipo <<Service>>, el cual como se ha descrito, en la codificación
representaran fachadas de la capa de negocio.
• Capa de acceso a datos: En esta capa se modelará las distintas entidades de datos, con las que contará el sistema. Todo
esto siguiendo lo sugerido por AndroMDA, que plantea plasmar un mapeo relacional de objetos,
que se ajuste a la tecnología usada en este nivel (Hibernate). La figura 24 muestra este diseño:
Figura 24: Modelado de entidades de datos en AndroMDA
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 69 de 237
En la figura 24, se presenta el diseño de un diagrama de entidad relación, con la particularidad
que cada componente, viene marcado con el estereotipo <<Entity>>, el cual al momento de
resolverse, representará una tabla de base de datos y sus respectivas clases de mapeos Java en el
proyecto, ayudando así de esta manera en la labor de recuperación de datos.
Una vez mostrado todos los componentes a modelar en cada una de las capas, nos preguntamos,
¿como se representa la interacción de estos componentes entre un nivel y otro? Para esto
AndroMDA, sugiere utilizar flechas de dependencias entre componentes, ver la figura 25:
Figura 25: Dependencia entre componentes de capa en AndroMDA
3.1.7.1.2.4 Herramientas y tecnologías en el ciclo de generación AndroMDA
En esta sección detallamos cada una las herramientas y versiones de las tecnologías, que
utilizará el marco ágil de trabajo, en el ciclo de generación AndroMDA:
• Para el modelado se utilizará la herramienta MagicDraw UML 9.5, que permitirá plasmar
los diseños en formato XMI [MGDU10].
• Para transformar los modeles en formato XMI, hacia código, se utilizará la herramienta
Apache Maven en su versión 2.2.1 [AMVN10]
• La herramienta Apache Maven en conjunto con las librerías de AndroMDA, interpretarán
el modelo y generarán los componentes necesarios a implementar. La versión de
AndroMDA a utilizar es la 3.2 [AMDA10].
• Se utilizará el Framework Apache Struts en su versión 1.2.7 [ASTS10].
• El Framework Spring en su versión 1.2.7 [SPIG10].
• El Framework Hibernate en su versión 3.1.3 [HBNT10].
En base a todos estos modelos, tecnologías y herramientas que se ha ido detallando a lo largo de
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 70 de 237
este apartado, se obtendrá el prototipo de arquitectura tanto a nivel de modelado como de
implementación. Además cabe recalcar, que bajo este enfoque de modelado es que se pretende
incluir cada uno los patrones de diseño relacionados con la Usabilidad.
3.1.7.2 Plan de ejecución de la primera iteración de construcción
Scrum, es una de las metodologías de gestión en la que se basa el marco ágil de trabajo. Así, en
esta sección se detallará la manera en que Scrum, plantea desagregar una funcionalidad
especifica en diferente tareas, que en conjunto formen una iteración.
Scrum, cuenta con un elemento llamado Sprint backlog, que consiste en descomponer las
funcionalidades del Product backlog, en tareas necesarias para construir un incremento (una
parte completa y operativa del sistema) [JPAL02].
En el Sprint se asigna a cada tarea, la persona responsable de su desarrollo y se indica el tiempo
de trabajo que se estima. Además en este elemento, cada persona responsable de cada tarea
deberá de registrar el avance de la misma y de esta manera tener de primera mano información
del tiempo que falta para terminarla.
Este enfoque, es útil porque permite descomponer el proyecto en tareas de tamaño adecuado
para determinar el avance diario e identificar riesgos y problemas sin necesidad de procesos
complejos de gestión [JPAL02]. Además tomar en cuenta que en Scrum un Sprint es
equivalente a una iteración del marco ágil de trabajo.
Para realizar un Sprint backlog, Scrum sugiere se tenga en cuenta lo siguiente:
• Deberá de realizarse de forma conjunta con todos los miembros del equipo.
• Deberá de tomarse en cuenta todas las tareas identificadas por el equipo para conseguir el
objetivo del Sprint.
• El tamaño de cada tarea está en un rango 4 a 16 horas de trabajo.
• Tiene que ser visible para todo el equipo. Idealmente en una pizarra o pared en el mismo
espacio físico donde trabaja el equipo.
Para el Sprint backlog, Scrum sugiere los siguientes formatos en los que se puede realizar esta
tarea:
• Hoja de Calculo.
• Pizarra o pared física.
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 71 de 237
• Herramienta colaborativa o de gestión de proyectos.
El marco ágil de trabajo, opta por realizar esta labor en base a una herramienta colaborativa, que
permita registrar los Sprint y que este a la vez accesible para todo el equipo de trabajo.
La herramienta sugerida por el marco ágil de trabajo es “Sprintometer”, la cual es una
herramienta ágil y a su vez simple para la gestión y el seguimiento de proyectos basados en
SCRUM y XP [SPTOME09].
Sprintomer, fue creado originalmente por la gente que trabaja en proyectos ágiles para sus
propios fines y ahora esta disponible como producto Freeware.
A continuación se describirá brevemente, algunos detalles importantes para el uso de esta
herramienta, que permitan en el momento de la ejecución de la fase, el uso adecuado de la
misma [SPTOUG08]. En las figuras 26, 27 y 28, se muestran detalles de esta herramienta:
Figura 26: Herramienta de gestión Sprintometer
1 2
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 72 de 237
Figura 27: Sección de registro de Sprint en Sprintometer
Figura 28. Sección de control de avance de tareas en el Sprint bajo Sprintometer
De acuerdo a la figura 26 [SPTOUG08]:
Ítem Comentarios
1 En esta sección es donde se realiza el registro de los Sprint que gestionara el proyecto.
Como se puede ver en la figura 23, donde se desglosa la sección del registro de los
Sprint, existen niveles de registro:
a. Nivel Sprint, a este nivel es donde se registra los Sprint (iteraciones) que contendrá el proyecto.
b. Nivel de Historias de usuario o funcionalidades, a ese nivel se registrará las funcionalidades que se pretende gestionar en un Sprint.
c. Nivel de tarea, a este nivel ya se habla de una mayor granularidad de un Sprint, debido a que en este nivel se registra las tareas a realizar por cada funcionalidad registrada.
2 En esta sección, es donde ya se lleva el control de las tareas registradas, mostrando así el
avance de las mismas tanto a nivel de Sprint, de funcionalidades como de tareas (ver
figura 15)
Tabla 5 : Detalle de secciones del Sprintometer
a
b
c
La Usabilidad en Metodologías Ágiles Mayo 2010 Marco ágil de trabajo Version 1.2
José Germán Núñez Mori Página 73 de 237
De acuerdo a lo planteado en esta sección, en base a la herramienta Sprintometer, se deberá de
realizar la planificación de la primera iteración (Sprint), que contemple las tareas necesarias
para llevar a cabo el prototipo de arquitectura.
Esta forma de gestionar el proyecto deberá de ser aplicada también en futuras iteraciones, es
decir, que se deberá de seguir esta estructura de planificación para las iteraciones de la fase de
desarrollo.
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 seguirán la misma estructura planteada en la
primera iteración de desarrollo de la fase de elaboración, que como ya se ha comentado, tiene
como objetivo el prototipo de la Arquitectura.
De acuerdo a esta premisa, esta fase de desarrollo seguirá el planteamiento dado en la fase de
elaboración para la implementación de cada una de las funcionalidades del sistema.
La Usabilidad en Metodologías Ágiles
IV. Fase de Inicio del Marco Ágil de Trabajo
Versión 1.1
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 75 of 237
Historia del documento
FECHA VERSION DESCRIPCIÓN AUTOR
13/06/2010 1.0 Fase de Inicio del marco ágil de
trabajo.
José Germán Núñez Mori
120/10/2010 1.1 Fase de Inicio del marco ágil de
trabajo.
José Germán Núñez Mori
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 76 of 237
Fase de Inicio del marco ágil de trabajo
1. Introducción El marco ágil de trabajo, plantea ciertas fases que comprenden la estructura de su metodología.
En este capítulo, se abordará el desarrollo de la primera de sus fases, que hace referencia a la
fase inicial de este marco de trabajo.
La metodología AUP (Agile Unified Process), que es una de las metodologías referentes del
presente trabajo, plantea una serie de actividades a realizar en la fase de inicio, como por
ejemplo: definición de riesgos del proyecto, estimación de costes, etc. En esta primera fase, el
marco ágil, realiza su planteamiento basado en dos de las actividades que sugiere realizar en
esta fase la metodología AUP, las cuales son: Definición del alcance y la planificación del
proyecto.
Esta primera fase, tal cual se describe en el capitulo anterior, es una fase de inicio de la
metodología que plantea este marco ágil de trabajo, donde, se definirá a un nivel alto lo que el
sistema va hacer y lo que no es suficiente a realizar, estableciendo así, los límites dentro de los
cuales el equipo de desarrollo ira a operar, es decir, se determinará el alcance del proyecto
[SABL06].
En cuanto a la planificación del proyecto, el marco ágil de trabajo, plantea la gestión de las
funcionalidades del sistema en base a lo descrito en la metodología Scrum, que es básicamente,
un inventario de características que el propietario del producto desea obtener. Donde, por ser
una metodología ágil, no debe interpretarse en el sentido de que todo el proyecto esta previsto
en este punto [JPAL02].
Tal cual define el marco ágil de trabajo, esta fase tiene un objetivo de fase llamado hito, que
consiste, en producir al final de la misma una serie de artefactos, que corresponde con cada una
de las actividades consideradas en esta fase. Por lo tanto, el presente capitulo, se basará en el
desarrollo de cada uno de estos artefactos planteados.
Cabe comentar, que el presente trabajo basará su análisis en las funcionalidades de un sistema
relacionado con el mercado de seguros de vida, es decir, un sistema que gestiona, productos que
incluyen seguros de vida, riesgo, rentas, planes individuales de ahorro y asegurados en general.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 77 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 gestión de las personas aseguradas y sus vínculos referentes.
De acuerdo a estas premisas, el presente trabajo, opta por ejecutar su planteamiento, sobre las
funcionalidades mínimas referentes a la gestión de personas aseguradas. Es así, que estas
funcionalidades serán desarrolladas a lo largo de este capitulo, en base al ciclo de vida del
software planteado por el marco ágil de trabajo
2. Desarrollo de la fase de Inicio En esta sección se desarrollará cada uno de los artefactos necesarios para cumplir con el hito de
esta primera fase.
2.1 Product Backlog
A continuación, se detalla cada unas las funcionalidades, seleccionadas de la gestión de
personas aseguradas. Estas funcionalidades, se presentan en una tabla (ver tabla 6) que sigue el
formato del Product Backlog planteado por Scrum:
Id. Historia Descripción Prioridad Estimación Observaciones ResponsablePER001 Relacionar Personas 10 JGNuñez
PER002 Gestionar Fusión de Personas 9 JGNuñez
PER003 Buscar Personas Fusionadas 9 JGNuñez
PER005
Gestionar Situación Familiar de la
Persona (alta) 8 JGNuñez
PER004 Recuperar Datos Entidad Finaciera 5
Esta funcionalidad deberá de
empezar a desarrollarse una vez
publicado los servicios de la
Entidaed Financiera JGNuñez
Tabla 6: Product backlog
2.2 Historias de usuarios
En esta sección, se desarrolla, la elicitación de cada una de las funcionalidades antes descritas
(ver tabla 6), siguiendo, el formato de historias de usuario.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 78 of 237
Nombre: Prioridad:
Descripción:
Usuario de Creación: Fecha Alta: 01/04/2010Estimación: Dependencia:
Aplicación
X
X
Josë Núñez Mori
Requisitos de Usabibilidad AsociadosRequisito Comentarios
System Status Feedback
Interaction FeedbackProgress feedback
Historia de Usuario Nº : PER0001
Relacionar Personas
Si el alta de la relación, no se realiza correctamente, se mostrará el siguiente mensaje en formato de error: "La operación no se ha realizado con éxito, debido a ……..."
Tras el evento de adición de una nueva relación, esta se añadirán al final de la tabla de relaciones de la persona gestionada y se remarcarán con un color apropiado.
Esta funcionalidad permitirá crear relaciones entre las personas dadas de alta en el sistema y que sean de la misma red comercial, para lo cual, es necesario que se tenga como parámetros de entrada, tanto el código de la persona gestionada, como la red comercial a la que pertenece. Para generar las relaciones de la persona gestionada, esta funcionalidad debe permitir buscar las personas a relacionar por los siguientes criterios:
• Tipo Vinculo, Vinculo, código de la persona, tipo de persona, sinidentificación, fiscalmente aplicable.
Una vez ubicada la persona, se dará de alta en la relación y se adicionará a lasrelaciones existentes de la persona gestionada.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 79 of 237
X
X
X
X
Personal Object Space
Abort OperationGo back
Structured Text Entry,
Step by StepPreferentes
FavouriteMultilevel HelpCommands Aggregation
Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, y que permitirá abortar, ya sea la búsqueda o la adición de relaciones en curso. Retonando el control a la funcioanlidad previa o al home de la aplicación.
Progress feedback
Warning
Object Specific Undo
Global Undo
Tras el evento de confirmación de las nuevas relaciones asociadas a la persona gestionada, el sistema presentará el siguiente mensaje en formato de confirmación.: "Se va a guradar los cambios en las relaciones de la persona gestionada, ¿Esta seguro de re
Esta funcionalidad debe permitir la opción de deshacer, lo cual consitirá, en eliminar las diez últimas relaciones dadas de alta con esta operación. Además se presentará estas diez últimas relaciones en formato de lista.
Para los campos del criterio de búsqueda se tendrá en cuenta lo siguiente:
• Tipo Vínculo, lista desplegable (obligatorio) • Vinculo, lista desplegable. (obligatorio) • Código de la persona alfanumérico de 6 caracteres
(obligatorio). • Sin identificación, campo de verificación. • Fiscalmente aplicable, campo de verificación.
El sistema validará el formato de los campos del criterio de búsqueda y presentará los siguientes mensajes en formato de notificación ante el incumplimiento de los mismos:
• Si existen campos del criterio de búsqueda que no se ajusten al formato adecuado, se mostrará el siguiente mensaje: “El campo XXXX, debe ser tipo XXXX (ejemplo de formato)”.
• Si existen campos obligatorios, que no hayan sido cumplimentados, se mostrará el siguiente mensaje: “El campo XXXX, es obligatorio”.
Tabla 7: Historia de usuario – Relacionar personas
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 80 of 237
Nombre : Prioridad:
Descripción:
Usuario de Creación: Fe cha Alta: 01/04/2010Estimación: Dependencia:
Aplicación
X
X
XWarning
Tras el evento de guardado de la fusión asociada a la persona principal, el sistema mostrará el siguiente mensaje en formato de confirmación: "Se va a gurdar la fusión en curso, ¿Esta seguro de realizar esta operación?"
Interaction Feedback
Si el alta de una fusión, no se realiza correctamente, se mostrará el siguiente mensaje en formato de error: "La operación no se ha realizado con éxito, debido a ……..."
Progress feedback
Esta funcionlaidad por actualizaciones de datos tardará de 1 a 4 segundos, ante lo cual, el sistema deberá mostrar un barra de progreso de la operación.
Requis itos de Usabibilidad AsociadosRequisito Comentarios
System Status Feedback
Gestionar Fusión de Personas
Josë Núñez Mori
Historia de Usuario Nº : PER0002
Esta funcionalidad permitirá la fusión o no fusión de personas candidatas a fusionarse, donde la persona principal de la fusión, tendrá la referencia a los contratos, direcciones de correo electrónico del grupo de personas fusionadas y será la persona visible ante cualquier búsqueda en el sistema. Para esta funcionalidad, previamente se tiene que haber seleccionado de la lista de personas candidatas a fusionarse, la personas que será la principal de la fusión. Una vez hecho esta selección, se debe mostrar un listado con la persona seleccionada anteriormente y las personas candidatas a la fusión, esta lista debe tener la siguiente información:
• Principal (Columna de selección) • Fusionar (Columna de selección) • No Fusionar (Columna de selección) • Código de Persona • Tipo de Identificación • Número de Identificación • Nombre (Concatenación del primer y segundo nombre). Sólo en caso de personas
físicas. • Apellido. Sólo en caso de personas físicas. • Fecha Nacimiento. Sólo en caso de personas físicas. • Sexo. Sólo en caso de personas físicas. • Razón social. Sólo en caso de personas jurídicas
De este listado, el usuario selecciona las personas a fusionar o no fusionar, además esta funcionalidad debe permitir adicionalmente, adicionar al listado de candidatos a fusionar, cualquier persona del sistema (fusión manual)
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 81 of 237
X
X
Personal Object Space
Go back
Structured Text Entry,
Object Specific Undo
Abort Operation
Global Undo
Step by StepPreferentes
FavouriteMultilevel HelpCommands Aggregation
El sistema deberá mostrar en formato de notificaciones, el incumplimiento de las siguientes validaciones, ante el evento de guardado:
• En caso de seleccionar, de la lista de personas a fusionar, más de un persona principal, el sistema deberá mostrar el mensaje: ”Selección Incorrecta, en la fusión solo se debe tener una persona principal”.
• Si para una persona de la lista, se selecciona mas de una de la siguientes columnas Principal, Fusionar, No Fusionar, se deberá mostrar el siguiente mensaje: Selección incorrecta, solo se debe de seleccionar una de las tres columnas
• Si de la lista de personas a fusionar no se seleccionan alguna de las tres columnas (Principal, Fusionar, No Fusionar), el sistema debe mostrar el siguiente mensaje: Existen personas en la lista que falta seleccionar.
Esta funcionalidad proveerá niveles para abortar las operaciones en curso:
• A nivel de operación, que lo que permitirá es cancelar, las fusiones en curso y regresar a la funcionalidad anterior o al home de la aplicación.
• A nivel de comando, que lo que permitirá es cancelar, la operación de alta de una nueva fusión, lo cual estará controlado con una barra de progreso.
Tabla 8: Historia de usuario – Gestionar fusión de personas
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 82 of 237
Nombre: Prioridad:
Descripción:
Usuario de Creación: Fecha Alta: 01/04/2010Estimación: Dependencia:
Aplicación
Historia de Usuario Nº : PER0003
Buscar Personas Fusionadas
Josë Núñez Mori
Requisitos de Usabibilidad AsociadosRequisito Comentarios
System Status FeedbackInteraction FeedbackProgress feedback
Warning
Global Undo
El sistema permitirá la búsqueda de personas que han pasado por un proceso de fusión (tanto de las personas principales o fusionadas).
Se debe permitir, tanto la búsqueda de personas físicas como jurídicas, cada búsqueda con criterios particulares
Búsqueda de personas físicas:
El sistema muestra los siguientes criterios de búsqueda:
• Código de persona, Tipo Identificación, Número de Identificación, Sin Identificación, Código externo de la persona (proporcionado por la red), Primer apellido, Segundo apellido, Primer nombre, Segundo nombre, Fecha de Nacimiento, Red comercial, Número de tarjeta Sanitaria.
Una vez ingresado los datos necesarios, se mostrará el listado con las personas fusionadas coincidentes. Esta lista mostrará la siguiente información:
• Código de persona, Fecha de fusión, Tipo de Indetificación, Sin Identificación, Estado de la persona en el sistema, Código externo de la persona, Primer apellido, Segundo apellidos, Nombre, Fecha de nacimiento, Número de tarjeta sanitaria.
Búsqueda de personas jurídicas:
El sistema muestra los siguientes criterios de búsqueda:
• Código de persona, Fecha de fusión, Tipo de Indetificación, Sin Identificación, Estado de la persona en el sistema, Código externo de la persona, Razón social, Nombre comercial, Actividad comercial, Red comercial.
Una vez ingresado los datos necesarios se mostrará el listado con las personas fusionadas coincidentes. Esta lista mostrará la siguiente información:
• Código de Persona, Fecha de fusión, Tipo de identificación, Número de identificación, Sin identificación, Estado de la persona en el sistema, Código externo de persona, Red comercial, Razón social, Fecha de constitución.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 83 of 237
X
Object Specific Undo
Abort Operation
Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, y que permitirá abortar, la búsqueda en curso, retonando el control a la funcioanlidad previa o al home de la aplicación.
Go back
Structured Text Entry X
Tanto para la búsqueda de personas físicas y jurídicas se debe tener en cuenta lo siguiente:
• Código de persona, alfanumérico de 6 caracteres (Campo obligatorio).
• Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio).
• Número de identificación, alfanumérico de 6 caracteres. • Sin identificación, listado de selección ( Si / No). • Estado de la persona en el sistema, listado de selección
(Habilitada / Inhabilitada). • Código externo de la persona, alfanumérico de 8 caracteres
(Campo obligatorio) • Red comercial, listado a seleccionar
Búsqueda de personas físicas:
• Primer y segundo apellido, primer y segundo nombre, alfanuméricos de 50 caracteres.
• Fecha de nacimiento, con el formato DD/MM/AAAA • Número de tarjeta sanitaria, alfanumérico de caracteres.
Campos obligatorios: Primer y segundo apellido, tarjeta sanitaria. Búsqueda de personas jurídica:
• Razón social, alfanumérica de 50 caracteres. • Nombre comercial, alfanumérico de 50 caracteres. • Actividad comercial, listado a seleccionar, de las actividades
parametrizadas en el sistema.
Campos obligatorios: Razón social, nombre comercial. El sistema validará el formato de los campos del criterio de búsqueda y presentará los siguientes mensajes en formato de notificación ante el incumplimiento de los mismos: :
• Si existen campos del criterio de búsqueda que no se ajusten al formato adecuado, se mostrará el siguiente mensaje: “El campo XXXX, debe ser tipo XXXX (ejemplo de formato)”.
• Si existen campos obligatorios, que no hayan sido cumplimentados, se mostrará el siguiente mensaje: “El campo XXXX, es obligatorio”.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 84 of 237
Personal Object SpacePreferentesStep by Step
FavouriteMultilevel HelpCommands Aggregation
Tabla 9: Historia de usuario – Buscar personas fusionadas
Nombre: Prioridad:
Descripción:
Usuario de Creación: Fecha Alta: 01/04/2010Estimación: Dependencia:
Aplicación
X
X
Historia de Usuario Nº : PER0004
Recuperar Datos Entidad Finaciera
Josë Núñez Mori
Requisitos de Usabibilidad AsociadosRequisito Comentarios
System Status FeedbackInteraction Feedback
Progress feedback
Tanto la recuperación de los datos, como el listado de personas coincidentes tardarán de 3 a 5 segundos, por lo cual el sistema mostrará un icono animado que indique el porcentaje de tiempo de la espera.
Al momento de recuperar tanto los datos de las persona, como el listado de personas coincidentes en la entidad financiera, si se produce algún error en este proceso, el sistema deberá mostrar un mensaje en formato de Error: "Se ha producido el / los si
Este funcionalidad permitirá recuperar los datos de una persona de la Entidad Financiera y actualizar los datos de la persona en el sistema. Para realizar esta búsqueda se debe ingresar los siguientes criterios:
• Tipo de identificación. • Número de identificación.
Una vez ingresado estos criterios, el sistema recuperará un listado con las personas coincidentes de la entidad financiera. Este listado tendrá la siguiente información:
• Código de cliente. Código de cliente de la EEFF, Tipo de identificación, Número de identificación, Nombre y apellidos del cliente
De este listado, se deberán poder seleccionar una de las personas, para poder obtener sus datos, los cuales serán recuperados de la Entidad financiera, siendo estos:
• Tipo de identificación, Número de identificación, Nombre, Primer Apellido, Segundo Apellido, Fecha de nacimiento, Profesión, Estado civil, Lista de cuentas corrientes de la persona, Lista de domicilios de la persona, Teléfono (prefijo y número).
Una vez obtenido estos datos, se actualizará los datos en la persona del sistema.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 85 of 237
X
X
X
X
Personal Object Space
Tras el evento de actualización con los datos obtenidos de la entidad financiera, el sistema mostrará un mensaje en fomato de confirmación: "Se va actualizar la persona con los datos de la EEFF, ¿Esta seguro de esta operación?"Warning
Global UndoObject Specific Undo
Abort Operation
Esta funcionalidad presentará la opción de cancelar, que será a nivel de operación, tanto en la busqueda como en la recuperación de datos de la entidad financiera, tras el evento de cancelar se rotornará el control a la funcioanlidad anterior o al home d
Go back
Esta funcionalidad permitirá, que una vez obtenido los datos de la persona de la entidad financiera,se cuente con la opción de "ir Atrás", lo cual permitira regresar al listado de personas.
Structured Text EntryStep by StepPreferentes
Commands Aggregation
FavouriteMultilevel Help
Para los campos de criterio se tendrá en cuenta lo siguiente:
• Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio).
• Número de identificación, alfanumérico de 6 caracteres.. El sistema validará el formato de los campos del criterio de búsqueda y presentará los siguientes mensajes en formato de notificación ante el incumplimiento de los mismos:
• Si existen campos del criterio de búsqueda que no se ajusten al formato adecuado, se mostrará el siguiente mensaje: “El campo XXXX, debe ser tipo XXXX (ejemplo de formato)”.
• Si existen campos obligatorios, que no hayan sido cumplimentados, se mostrará el siguiente mensaje: “El campo XXXX, es obligatorio”.
Tabla 10: Historia de usuario – Recuperar datos entidad financiera
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 86 of 237
Nombre : Prioridad:
Descripción:
Usuario de Creación: Fe cha Alta: 01/04/2010Estimación: Dependencia:
Aplicación
X
Historia de Usuario Nº : PER0005
Gestionar Situación Familiar de la Persona (alta)
Josë Núñez Mori
Requis itos de Usabibilidad AsociadosRequisito Comentarios
System Status FeedbackInteraction FeedbackProgress feedback
Warning
Tras cumplimentar los tres pasos de la funcionalidad y ejecutar el
evento de guardado el sistema mostrara un mensajes en formato de
confirmación: "Se va a guardar los datos de la situación familiar de la
persona, ¿Esta seguro de realizar esta operación?"
Global UndoObject Specific Undo
Esta funcionalidad permitirá la gestión (Alta) de la situación familiar asociada a un persona física. Esta funcionalidad, deberá presentar la siguiente información a cumplimentar: Datos Asegurado: • Situación familiar, NIF del cónyuge, % de retención del IRPF, fecha de movilidad
geográfica, prolongación de la actividad laboral (valor SI /NO), pensión compensatoria a favor de cónyuge (importe anual), anualidades por alimentos a favor de los hijos.
Datos Hijos, descendientes menores de 25 años o discapacitados: • Año de nacimiento, año de adopción, grado de minusvalía, necesita ayuda terceros (valor
SI / NO), Esta sección, permitirá adicionar o eliminar los datos de hijos o descendiente de un listado mostrado en la parte inferior de esta sección. Datos de Ascendientes mayores de 65 años o discapacitados que viven con el perceptor: • Año de nacimiento, grado de minusvalía, necesita ayuda de terceros (valor SI/NO). Esta sección, permitirá adicionar o eliminar los datos de los ascendientes de un listado mostrado en la parte inferior de esta sección.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 87 of 237
X
X
X
Personal Object Space
X
X
Abort Operation
Esta funcionalidad presentará la opción de cancelar, que será a nivel
de operación, en cada uno de sus pasos,donde, tras el evento de
cancelar se retornará el control a la funcioanlidad anterior o al home de
la aplicación, abortando así, las operaciones r
Go back
Tanto los pasos: Datos de los hijos y datos de los descendientes,
contarán con la opción de "Ir Atrás", lo que permitirá regresar al paso
inmediatamente anterior.
Structured Text Entry,
Step by StepPreferentes
Favourite
Multilevel HelpCada paso de esta funcionalidad presentará un icóno de ayuda el cual
al pulsar mostrará un pop-up con la ayuda de cada paso.
Commands Aggregation Se mostrará la ayuda de cada tarea al pular las teclas ctrl+A
Esta funcionalidad contará con tres pasos a cumplimentar, los cuales serían cada una de las secciones detallas en la descripción. Cada uno de estos pasos se presentarán en el orden de la descripción, indicando en cada paso, el paso en el que esta y el paso que le falta para finalizar la funcionalidad.
Tabla 11: Historia de usuario – Gestionar Situación familiar de la persona
2.3 Pruebas de aceptación
En esta sección, se presenta las pruebas de aceptación mínimas, asociadas a los requisitos de
usabilidad contemplados en cada una de las historias de usuario desarrolladas.
PER0001Relacionar Personas
System Status Feedback
Interaction Feedback
Dar de alta nuevas relaciones y verificar, que estas se añaden al final de la lista de relaciones de la persona gestionada. Además validar que cada una de estas nuevas relaciones esten remarcadas con un color determinado
Criterio de validación
de los Requisitos de UsabilidadId Historia
• Se deberá dar de alta una relación ya existente en la lista de relaciones de la persona gestionada, ante esto el sistema deberá mostrar un mensaje del tipo notificación: “La operación no se ha realizado con éxito, debido a que la persona ya existe en las relaciones de la persona gestionada”.
• Se debe dar de alta una relación, cuando el recurso de Base de datos se encuentra caído, ante esto el sistema deberá mostrar un mensaje del tipo notificación: “La operación no se ha realizado con éxito, debido a que el manejador de Base de datos no se encuentra disponible (BD001)”.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 88 of 237
Warning
Dar de alta nuevas relaciones asociadas a la persona gestionada y luego confirmar esta operación. Ante esto el sistema deberá mostrar el siguiente mensaje en formato de notificación: "Se va a gurdar los cambios en las relaciones de la persona gestionada,
Global Undo
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 pop-up con un listado, donde muestre estas diez últimas relaciones. Una vez aceptado
Abort Operation
Durante el alta de relaciónes de la persona gestionada, ejecutar el evento cancelar. Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o al home de la aplicación. Confirmar además, que los datos de la relación en curso no s
Structured Text Entry,
Verificar los formatos de los siguientes campos:
• Tipo Vínculo, lista desplegable (obligatorio)
• Vinculo, lista desplegable. (obligatorio)• Código de la persona alfanumérico de
6 caracteres (obligatorio). • Sin identificación, campo de
verificación. • Fiscalmente aplicable, campo de
verificación.
Luego realizar la búsqueda de personas a relacionar, sin cumplimentar el campo: "Código de la persona". Ante esto el sistema deberá mostrar un mensaje del tipo notificación: "El campo Código de la persona, es obligatorio”
Tabla 12 : Prueba de aceptación – Relacionar personas
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 89 of 237
PER0002Gestionar Fusión de Personas
System Status Feedback
Progress feedback
Realizar una fusión y una vez aceptada la misma, verificar que se muestra una barra de progreso, donde se informe el estado de la fusión.
Warning
Guardar la fusión asociada a una persona principal y luego verificar que el sistema muestre el siguiente mensaje en formato de confirmación: "Se va a gurdar la fusión en curso, ¿Esta seguro de realizar esta operación?"
Abort Operation
Criterio de validación
de los Requisitos de UsabilidadId Historia
• Se debe dar de alta una fusión, cuando el recurso de Base de datos se encuentra caído, ante esto el sistema deberá mostrar un mensaje del tipo notificación: “La operación no se ha realizado con éxito, debido a que el manejador de Base de datos no se encuentra disponible (BD001)”.
Durante el proceso de alta de una fusión validar lo siguiente: • Ejecutar el evento cancelar, y verificar,
que el sistema redirige al usuario a la funcionalidad anterior o al home de la aplicación. Confirmar además, que los datos de la fusión no se han registrado en el sistema.
• Aceptar o confirmar la fusión en curso y una vez se muestre la barra de progreso, ejecutar el evento cancelar de la misma: Tras esto, validar que los datos de la fusión no se han registrado en el sistema.
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 90 of 237
Structured Text Entry,
Realizar una fusión, y validar las siguientes casuísticas tras el evento de aceptar la fusión:
• Seleccionar, de la lista de personas a fusionar, más de un persona principal,donde, tras el evento de aceptar la fusión, verificar que el sistema muestra el siguiente mensaje:”Selección Incorrecta, en la fusión solo se debe tener una persona principal”.
• Para una persona de la lista a fusionarse debe de seleccionar mas de una de la siguientes columnas Principal, Fusionar, No Fusionar, donde, tras el evento de aceptar la fusión, se debe validar que el sistema muestra el siguiente mensaje: ”Selección incorrecta, solo se debe de seleccionar una de las tres columnas”.
• De la lista de personas a fusionar no seleccionan alguna de las tres columnas (Principal, Fusionar, No Fusionar), donde, tras el evento decapitar la fusión, verificar que el sistema muestra el siguiente mensaje: Existen personas en la lista que falta seleccionar.
Tabla 13: Prueba de aceptación – Gestionar fusión de personas
PER0003Buscar personas fusionadas
Abort Operation
Durante el cumplimentado de datos para la búsqueda, ejecutar el evento cancelar: Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o la home de la aplicación, dejando la operación en curso sin efecto.
Id HistoriaCriterio de validación
de los Requisitos de Usabilidad
Validar los formatos de los campos de la
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 91 of 237
Structured Text Entry
Validar los formatos de los campos de la búsqueda:
� Código de persona, alfanumérico de 6caracteres (Campo obligatorio), Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio), Número de identificación, alfanumérico de 6 caracteres, Sin identificación, listado de selección ( Si / No). Estado de la persona en el sistema, listado de selección (Habilitada / Inhabilitada), Código externo de la persona, alfanumérico de 8 caracteres (Campo obligatorio), Red comercial, listado a seleccionar
Búsqueda de personas físicas:
� Primer y segundo apellido, primer y segundo nombre, alfanuméricos de 50 caracteres, Fecha de nacimiento, con el formato DD/MM/AAAA, Número de tarjeta sanitaria, alfanumérico de caracteres.
Campos obligatorios: Primer y segundo apellido, tarjeta sanitaria. Búsqueda de personas jurídica: � Razón social, alfanumérica de 50
caracteres., Nombre comercial, alfanumérico de 50 caracteres, Actividad comercial, listado a seleccionar, de las actividades parametrizadas en el sistema.
Campos obligatorios: Razón social, nombre comercial. Realizar búsquedas con lo siguientes criterios: :
• Campos del criterio de búsqueda que no se ajusten al formato adecuado, donde, el sistema deberá mostrar el siguiente mensaje en formato de notificación: “El campo XXXX, debe ser tipo XXXX (ejemplo de formato)”.
• Campos obligatorios, que no hayan sido cumplimentados, donde, el sistema deberá mostrar el siguiente mensaje en formato de notificación: “El campo XXXX, es obligatorio”.
Tabla 14: Prueba de aceptación – Buscar personas fusionadas
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 92 of 237
PER0004Recuperar Datos
Entidad Finaciera
System Status Feedback
Recuperar tanto los datos de la persona, como el listado de personas coincidentes de la entidad financiera, cuando no se tiene conexión al servicio de entidad financiera. Ante esto el sistema deberá mostrar un mensaje en formato de error: "Se ha producid
Progress feedback
Validar que ante la recuperación de datos como el listado de personas coincidentes de la entidad financiera, el sistema muestre en la espera un icono animado que indique el pocentaje de tiempo consumido de la operación
Warning
Obtenido los datos de la persona de la entidad financiera, actualizar los mismos en el sistema, donde, al aceptar dicha actulización el sistema deberá mostar un mensaje en formato de notificación: "Se va actualizar la persona con los datos de la EEFF,
Abort Operation
Durante la recuperación tanto de los datos de la persona como el listado de personas coincidentes de la Entidad Financiera, ejecutar el evento cancelar. Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o al home de la apli
Go back
Validar que en la operación de obtener los datos de la persona de la entidad financiera, al ejecutar el evento "ir atrá", el sistema redirija al usuario a la operación listado de personas coincidentes de la búsqueda en la entidad financiera
Criterio de validación
de los Requisitos de UsabilidadId Historia
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 93 of 237
Structured Text Entry
Validar los formatos de los campos del criterio:
• Tipo identificación, alfanumérico, siendo este un listado a seleccionar (Campo obligatorio).
• Número de identificación, alfanumérico de 6 caracteres.
Realizar una búsqueda considerando lo siguiente
• Campos obligatorio del criterio , que no hayan sido seleccionado, se mostrará el siguiente mensaje: “El campo XXXX, es obligatorio”.
Tabla 15: Prueba de aceptación – Recuperar datos entidad financiera
PER0005
Gestionar
Situación 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 confirmación: "Se va a guardar los datos de la situación familiar de la persona, ¿Esta seguro de realizar esta operación?".
Abort Operation
Durante el cumplimentado de datos de cada unas de los pasos de la funcionalidad, ejecutar el evento cancelar: Tras esto, validar que el sistema redirige al usuario a la funcionalidad anterior o la home de la aplicación, dejando la operación en curso sin efecto.
Go back
Durante el cumplimentado de los pasos: Datos de los hijos y datos de los descendientes, ejecutar el evento "Ir Atrás", Tras esto, validar que el sistema redirige al usuario al paso anterior cumplimentado.
Id Historiade los Requisitos de Usabilidad
Criterio de validación
La Usabilidad en Metodologías Ágiles Junio 2009 Fase de inicio del marco ágil de trabajo Version 1.1
José Germán Núñez Mori Page 94 of 237
Step by Step
Verificar que la funcionalidad se encuentra dividida en tres pasos a cuplimentar, claramente informados al usuario del sistema
Multilevel Help
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
Commands Aggregation
Validar que tras ejecutar las teclas ctrl+z, en el paso en que se encuentre, se muestre la respectiva ventana de ayuda del paso.
Tabla 16: Prueba de aceptación – Gestionar situación familiar
La Usabilidad en Metodologías Ágiles
V. Fase de Elaboración del Marco Ágil de Trabajo
Versión 1.0
José Germán Núñez Mori Página 96 de 237
Historia del documento
FECHA VERSION DESCRIPCIÓN AUTOR
25/10/2010 1.0 Fase de Elaboración del marco ágil
de trabajo.
José Germán Núñez Mori
José Germán Núñez Mori Página 97 de 237
Fase de Elaboración del marco ágil de trabajo
1. Introducción Como siguiente paso planteado por el marco ágil de trabajo es la ejecución de la fase de
elaboración. Es en este capitulo en el que se abordará el desarrollo de la misma.
El marco ágil de trabajo, de acuerdo a su planteamiento metodológico, escrito en el capitulo
“Marco ágil de trabajo”,plantea que se realice para esta fase dos actividades, para cumplir con el
hito de esta fase, que son tanto el prototipo de la arquitectura inicial del sistema, como la
planificación de esta primera iteración de fase.
Estas actividades han de ser ejecutadas sobre alguna de las historias de usuarios antes expuestas
(ver capitulo Fase de inicio del marco ágil de trabajo), que según sugiere la metodología AUP
(Agile Unified Process), deberá ser alguna historia o historias que permitan implementar de
manera iterativa la arquitectura del sistema que constituirá el núcleo central, donde se mitigan
las cuestiones de alto riesgo [SABL06].
De acuerdo a este enfoque y siguiendo el objetivo del presente trabajo se seleccionará una de las
historias de usuario de las antes expuestas, que represente el núcleo central del sistema, es decir,
una historia de usuario que contemple la gran mayoría de requisitos de usabilidad. Donde, la
funcionalidad seleccionada, sirva como estructura base a la implementaciones de las demás
historias de usuario.
Cabe mencionar, que la manera de trabajo ejecutada en esta fase servirá como guía para las
iteraciones de desarrollo de la fase de construcción.
2. Desarrollo de la fase de Elaboración En esta sección se desarrollará, cada uno de los artefactos necesarios para cumplir con los hitos
de esta fase de elaboración, tal cual el planteamiento escrito en el capitulo “Marco ágil de
trabajo”.
2.1 Planificación de la Primera Iteración
En esta sección, se presentará la planificación de esta primera iteración de desarrollo, la cual
seguirá los lineamientos planteados por la metodología Scrum [JPAL02].
José Germán Núñez Mori Página 98 de 237
De acuerdo al Product backlog:
Id. Historia Descripción Prioridad Estimación Observaciones ResponsablePER001 Relacionar Personas 10 JGNuñez
PER002 Gestionar Fusión de Personas 9 JGNuñez
PER003 Buscar Personas Fusionadas 9 JGNuñez
PER005
Gestionar Situación Familiar de la
Persona (alta) 8 JGNuñez
PER004 Recuperar Datos Entidad Finaciera 5
Esta funcionalidad deberá de
empezar a desarrollarse una vez
publicado los servicios de la
Entidaed Financiera JGNuñez
Tabla 17: Product backlog
Podemos apreciar que la tarea de mayor prioridad es la historia: PER001 – Relacionar Personas.
Esta historia, por ser de mayor prioridad y por contemplar la gran mayoría de requisitos de
usabilidad (ver capitulo Fase de Inicio del marco ágil de trabajo), es seleccionada para su
desarrollo en esta primera iteración.
La herramienta a utilizar, como se comenta, en el capitulo del Planteamiento del marco ágil de
trabajo, es la herramienta Sprintometer, donde se registrará como Sprint principal la historia de
usuario seleccionada y como sub-tareas, cada uno de los patrones de usabilidad asociados al
diseño.
Figura 29: Vista de la planificación en días
En la figura 29, se puede apreciar, el tiempo que durará este Sprint y los días que se consideran
laborables para esta tarea.
José Germán Núñez Mori Página 99 de 237
Figura 30: Sprint y tareas de la primera Iteración en Spritometer
En la figura 30, se muestra la planificación de esta primera iteración en la herramienta
Sprintometer, donde se ha registrado cada una de las tareas que contemplará este Sprint, las
horas de duración de las mismas y el responsable de su ejecución. A continuación se muestra a
más detalle esta planificación (tabla 18), obtenida como reporte de Sprintometer.
José Germán Núñez Mori Página 100 de 237
Tabla 18: Planificación del Sprint – Relacionar Personas
Como se puede apreciar en la tabla 18, se muestra ya en detalle cada una de las tareas y sub-
tareas necesarias, para cumplir con el objetivo de esta primera iteración. También se puede
José Germán Núñez Mori Página 101 de 237
apreciar en esta planificación, que cada uno los patrones de usabilidad han sido considerados
como tareas, los cuales a su vez se han dividido en tareas pequeñas, que en conjunto permitirán
la integración de un patrón de usabilidad determinado al diseño de la funcionalidad en curso.
Con la planificación presentada, se pretende cumplir con el desarrollo del hito de Prototipo de
Arquitectura. De acuerdo a esto, en la siguiente sección, se seguirá con lo planificado,
desarrollando así, cada una de las tareas pactadas en este Sprint.
2.2 Prototipo de Arquitectura
En la presente sección, se presentará el desarrollo de cada unas de las tareas necesarias para el
desarrollo del prototipo de la arquitectura, haciendo uso del Framework AndroMDA.
Como se puede apreciar en la tabla 18, como primera tarea de planificación se encuentra la
implementación de la funcionalidad en si (Relacionar Personas), esto debido, a que es una
estrategia a seguir para el desarrollo de este prototipo de arquitectura.
La estrategia, consiste en implementar todo lo necesario a la funcionalidad en si misma y luego
ir integrando cada uno de los patrones de usabilidad asociados.
A continuación se describe, el desarrollo de cada una de las tareas especificadas en la
planificación del Sprint (ver tabla 18 - Planificación del Sprint – Relacionar personas).
2.2.1 Tarea de Implementación de la Funcionalidad
Esta tarea tiene como objetivo la implementación de la funcionalidad “Relacionar Personas”,
por tal motivo, a continuación se muestra cada uno de los modelos involucrados en la misma.
Para esta tarea se ha contemplado las siguientes sub-tareas, registradas en la planificación del
Sprint, ver la siguiente tabla 19:
José Germán Núñez Mori Página 102 de 237
Tabla 19: Planificación inicial de la tarea de implementación de la funcionalidad
2.2.1.1 Diseño de la capa de datos
A continuación se presenta el modelado de las entidades de datos necesarias en esta
funcionalidad.
José Germán Núñez Mori Página 103 de 237
Figura 31: Modelo de entidades de la capa de datos
Este diseño, representa el modelo entidad relación, que deberá ser persistido en la base de datos
seleccionada a modo de tablas de la misma.
2.2.1.2 Diseño de la capa de negocio
En esta sección se presenta el diseño correspondiente a la capa de negocio, que consiste, en una
serie de componentes del tipo servicio, que contendrán las operaciones necesarias del núcleo de
esta funcionalidad.
Figura 32: Modelado de la capa de negocio
José Germán Núñez Mori Página 104 de 237
Todos estos servicios, contienen la lógica necesaria de la operativa asociada a la funcionalidad
de Relacionar Personas. Esta capa de negocio, deberá de reflejar también que entidades de datos
son involucradas en las operaciones de cada uno de estos servicios, por tal motivo, a
continuación se muestra este diseño:
Figura 33: Dependencias de servicios con las entidades de datos
2.2.1.3 Diseño de la capa de presentación
En esta sección se presenta, los diseños asociados a la capa de presentación, mostrando así, las
transiciones y estados de acción en esta capa, ante una petición de usuario y su respectiva
respuesta.
Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas
José Germán Núñez Mori Página 105 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 generación de código se estereotipa al caso de uso con: “FrontEndUseCase”.
Figura 35: Modelado de la clase controladora
Como se puede apreciar en la figura 35, se muestra el componente controlador con las
operaciones que darán soporte a las peticiones de los usuarios. También, se aprecia en esta
figura, las dependencias de la clase controladora con los componentes de la capa de negocio,
reflejando de esta manera que las operaciones de esta clase harán uso del núcleo de esta
funcionalidad para procesar las peticiones.
José Germán Núñez Mori Página 106 de 237
Figura 36: Diagrama de actividad asociado a la capa de presentación
En la figura 36, se presenta las transiciones y cambios de estado que tendrá la página Web
asociada a esta funcionalidad. Además como se puede apreciar en la columna de sistema se
encuentran estados de acción relacionados con las operaciones de la clase controladora (ver
figura 9 – Modelado de la clase controladora).
2.2.1.4 Resultado de Tarea
A continuación, se presenta los resultados tras la implementación de cada uno de los diseños,
asociados a la funcionalidad de “Relacionar Personas”.
Estos resultados, consisten en presentar cada una de las pantallas de la aplicación, generadas en
base a AndroMDA y detallar brevemente el funcionamiento de las mismas.
José Germán Núñez Mori Página 107 de 237
Figura 37: Búsqueda de personas – Página principal de la aplicación
En la figura 37, se muestra la pantalla principal de la aplicación, que si bien es cierto no es la
funcionalidad que se esta tratando, es necesario presentarla, por ser una pantalla que permite el
acceso a la funcionalidad de “Relacionar Personas”.
La funcionalidad de “Búsqueda de personas”, se resume, en que permite la búsqueda de una
persona por medio de su código de persona o en todo caso listar todas las personas registradas
en el sistema (ver figura 37 – Búsqueda de personas – Página principal de la aplicación).
Figura 38: Relacionar Personas – Criterio de selección de personas a relacionar
José Germán Núñez Mori Página 108 de 237
Figura 39: Relacionar Personas – Adición de relaciones a la persona seleccionada
En la figura 38, se presenta la pantalla relacionada a la funcionalidad de “Relacionar Personas”,
mostrando en esta figura, los criterios necesarios para adicionar una relación a la persona
seleccionada. Es de acuerdo a esta selección, que se adicionará relaciones a una persona
determinada.
Ya en la figura 39, se puede apreciar, la adición de una persona al listado de relaciones de la
persona seleccionada.
Una vez presentado los resultados de esta primera tarea, se actualizará el Sprint con los avances
realizados en esta tarea:
Tabla 20: Actualización de la planificación de la tarea de implementación de la funcionalidad
José Germán Núñez Mori Página 109 de 237
2.2.2 Integración del patrón de usabilidad Warning
Es esta sección, se presenta la integración del patrón de usabilidad Warning, a la funcionalidad
de “Relacionar Personas”. Para mas detalle de este patrón ver anexo 01 (Especificación Patrón
de usabilidad Warning).
Como se ha comentado en capítulos anteriores, los patrones de usabilidad, se tomarán en cuenta
desde el tiempo de diseño, por tal motivo, en esta sección, se detalla cada uno de los niveles o
capas, en las cuales será necesario adicionar nuevos componentes u operaciones que harán
posible la integración de este patrón de usabilidad.
Siguiendo lo planteado por el presente Sprint, la tarea de integración del patrón de usabilidad
Warning, presenta la siguiente planificación, mostrada en la tabla 21:
Tabla 21: Planificación inicial de la tarea de integración del patrón de usabilidad Warning
Como se pude apreciar en la tabla 21, se presentan las sub-tareas asociadas a esta integración,
las cuales son la continuación de la tarea de implementación de la funcionalidad (ver tabla 20-
Actualización de la planificación de la tarea de implementación de la funcionalidad).
Para la integración de este patrón de usabilidad, al diseño de la funcionalidad de “Relacionar
Personas”, el presente trabajo, tomara como base lo especificado en la guía del patrón de
usabilidad Warning (ver anexo 01 – Especificación Patrón de usabilidad Warning). De esta guía,
se toma los siguientes diagramas base para la integración:
José Germán Núñez Mori Página 110 de 237
Figura 40 – Diagrama de clases de la especificación del patrón de usabilidad Warning
Figura 41: Diagrama de secuencia de la especificación del patrón de usabilidad Warning
Es en base a estos diagramas, tanto de clases como de secuencia (ver figura 40 y 41), se
realizará modificaciones tanto en el diseño de las capas, como en la implementación del sistema.
José Germán Núñez Mori Página 111 de 237
A continuación, se detallan las modificaciones en las capas o niveles implicados y los
resultados de la misma.
2.2.2.1 Integración del patrón de usabilidad Warning en la capa de
presentación y capa de negocio
Para la integración del patrón de usabilidad Warning en estas capas (presentación y negocio), se
ha adicionado dos nuevos componentes de tipo servicio (RelacionSession y
RelacionesWrapperService), quedando el diseño de la siguiente manera:
Figura 42: Modelado de la clase controladora con el Patrón de usabilidad Warning
Estos dos nuevos componentes (RelacionSession y RelacionesWrapperService), harán de
componentes intermedios entre la capa de presentación y la capa de negocio (ver figura 42),
buscando de esta manera, seguir con la especificación del patrón de usabilidad Warning,
específicamente, en lo planteado en su diagrama de clases (ver figura 40 – Diagrama de clases
de la especificación del patrón de usabilidad Warning).
Con el objetivo, de presentar mayor claridad en la integración de este patrón de usabilidad, al
diseño de estas capas, a continuación, se detalla la correspondencia de cada uno de los
componentes nuevos (ver figura 42), contra la especificación del patrón de usabilidad Warning
(ver figura 40):
José Germán Núñez Mori Página 112 de 237
Componentes del P.U. Warning Componentes de diseño en la funcionalidad
View RelacionarPerController
Controller RelacionarPerController
DomainClassWrapper RelacionesWrapperService
DomainClass RelacionesService
- RelacionSession
Tabla 22: Correspondencia de componentes del patrón de usabilidad Warning y los
componentes de la funcionalidad
Como se aprecia en la figura 42 (Modelado de la clase controladora con el Patrón de usabilidad
Warning), el componente RelacionesWrapperService, es una componente imagen, del
componente RelacionesService, es decir, que tiene las mismas operaciones que este componente.
Esta imagen de operaciones, hará la labor de capa intermedia entre la capa de negocio y la de
presentación, permitiendo de esta manera, validar aquellas operaciones que necesitan de
confirmación del usuario antes de persistir los datos.
2.2.2.2 Flujo de trabajo según el patrón de usabilidad Warning
En esta sección, se explicará brevemente, la interacción de los componentes diseñados, para la
integración del patrón de usabilidad Warning a la funcionalidad de “Relacionar Personas”, y
cuya secuencia, dará a entender el flujo de trabajo de este patrón, tanto a nivel de diseño como
de implementación. Todo esto, tomando como base el diagrama de secuencias de la
especificación del patrón (ver Figura 41- Diagrama de secuencia de la especificación del patrón
de usabilidad Warning)
A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes
que se describen, se podrá revisar la figura 42 (Modelado de la clase controladora con el Patrón
de usabilidad Warning):
• Una vez realizada la petición de adicionar una nueva relación, la clase controladora
(RelacionarPerController), recibe los datos necesarios para el procesamiento y verifica si el
flujo de trabajo necesita de una confirmación del usuario.
• La validación, si el flujo necesita de una confirmación de usuario, se hace contra el
componente “RelacionesWrapperService”, y su operación “checkOK”, donde a esta
operación, se pasa como parámetro el nombre del método u operación, que se necesita
validar. En este caso en concreto, se pasa como parámetro el método “nuevaRelacion”.
• La operación “checkOK”, del componente “RelacionesWrapperService”, valida si el
José Germán Núñez Mori Página 113 de 237
método “nuevaRelacion”, necesita de confirmación del usuario, de ser así, responde a la
petición con el valor del flag de control de este método.
• En la clase controladora (RelacionarPerController), si la operación “chekOK” del
componente “RelacionesWrapperService”, retorna un valor falso, significa que se necesita
de confirmación del usuario y se debe pedir esto a la vista.
• Con el objetivo de mostrar un alerta de confirmación en la páginas Web, la clase
controladora (RelacionarPerController) setea valores necesarios para este comportamiento
en el objeto de sesión “RelacionSession”.
• Una vez confirmado esta operación, por medio del usuario, esta petición es enviada a la
clase controladora (RelacionarPerController), la cual, solicita al componente
RelacionesWrapperService, que actualice el estado de confirmación, para el método
“nuevaRelacion”.
• Actualizado el estado de confirmación del método “nuevaRelacion”, la clase controladora
envía los datos recogidos de la vista, para su procesamiento por medio de la operación
“nuevaRelacion” del componente RelacionesWrapperService, el cual, verifica nuevamente
si el flag de confirmación de la operación “nuevaRelacion”, esta a verdadero, de ser así,
envía los datos para su persistencia por medio del componente “RelacionesService”.
2.2.2.3 Resultados de la Integración del patrón de usabilidad Warning
En la presente sección se presenta los resultados, tras la integración del patrón de usabilidad
Warning. Estos resultados consistirán, en presentar las páginas Web, generadas en base a
AndroMDA y la actualización de la planificación de la tarea de integración de este patrón
José Germán Núñez Mori Página 114 de 237
Figura 43: Confirmación de adición de nueva relación según el patrón de usabilidad Warning
Como se puede apreciar en la figura 44, ante el evento de adición de una nueva relación a la
persona seleccionada, se muestra una alerta del tipo confirmación, donde se advierte al usuario
que los datos que ha seleccionado están a punto de persistirse, de confirmarse esta alerta, se
enviará la petición al sistema, el cual se encargará de guardar la información en la base de datos
y actualizará la pantalla con la nueva adición.
Figura 44: Resultados tras la confirmación de la adición de una nueva relación
José Germán Núñez Mori Página 115 de 237
Una vez presentado los resultados de la aplicación, a continuación se presenta la actualización
de la planificación respectiva a esta tarea de integración del patrón de usabilidad Warning:
Tabla 23- Planificación actualizada de la tarea de integración del patrón de usabilidad
Warning
2.2.3 Integración del patrón de usabilidad System Status Feedback
En la presente sección, se detallará cada uno de los pasos seguidos para la integración del patrón
de usabilidad System Status Feedback. En adelante haremos referencia a este patrón como SSF.
Para mas detalle de este patrón ver anexo 02 (Especificación del Patrón de Usabilidad System
Status feedback).
Esta Integración del patrón de usabilidad SSF, se realizará tanto en el diseño como en la
implementación de la funcionalidad “Relacionar Personas”.
A continuación, se presenta la planificación inicial de esta tarea de integración del patrón de
usabilidad SSF:
Tabla 24: Planificación inicial de la tarea de integración del patrón de usabilidad SSF
Siguiendo lo especificación del patrón de usabilidad SSF (ver anexo 02 - Especificación Patrón
José Germán Núñez Mori Página 116 de 237
de Usabilidad System Status feedback), la integración de este patrón a la funcionalidad de
“Relacionar Personas”, tomara en cuenta como diseños base lo siguiente:
Figura 45: Diagrama de clases de la especificación del patrón de usabilidad SSF
Figura 46: Diagrama de secuencia de la especificación del patrón de usabilidad SSF
José Germán Núñez Mori Página 117 de 237
2.2.3.1 Integración del patrón de usabilidad SSF a la capa de
presentación y capa de negocio
La integración de este patrón de usabilidad, en la capa de presentación, solo presenta cambios a
nivel de la clase controladora de la funcionalidad (RelacionarPerController) y de su dependencia
hacia el componente de tipo servicio de la capa de negocio (RelacionesService).
Para esta integración se adicionan 4 nuevos componente que interactuarán entre la capa de
negocio y la capa de presentación, estos componentes son: AdministradorEstados,
EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService. De acuerdo a esto el
diseño de la funcionalidad de “Relacionar Personas”, queda de la siguiente manera:
Figura 47: Integración del patrón de usabilidad SSF en el diseño de la funcionalidad
Relacionar Personas
Como se describe al inicio de esta sección, la integración de este patrón de usabilidad SSF a la
funcionalidad de “Relacionar Personas”, se basa en ciertos diseños de la especificación de este
patrón (ver anexo 02 - Especificación Patrón de Usabilidad System Status feedback).
De acuerdo esto, y buscando entender los detalles de esta integración, se presenta una tabla
(tabla 25) de correspondencias entre componentes de diseño de la especificación de este patrón
(ver figura 46) y el diseño de la integración a la funcionalidad en curso (ver figura 48):
José Germán Núñez Mori Página 118 de 237
Componentes del P.U. SSF Componentes de diseño en la funcionalidad
View RelacionarPerController
Controller RelacionarPerController
StatusManager AdministradorEstados
ConcreteStatus EstadoErrorService
ConcreteStatus EstadoExitoService
ConcreteStatus EstadoAdvertenciaService
DomainClass RelacionesService
Tabla 25: Correspondencia de componentes del patrón de usabilidad SSF y los componentes de
la funcionalidad
Estos nuevos componentes de la integración de este patrón de usabilidad (ver figura 19),
gestionarán los estados, ante la operativa de “Adición de una nueva Relación”, permitiendo de
esta manera, mantener informado al usuario ante cualquier cambio de estado, relacionado con la
operativa en curso.
2.2.3.2 Flujo de trabajo según el patrón de usabilidad SSF
Con el objetivo de dar un mayor detalle de la integración del patrón de usabilidad SSF, en la
presente sección, se describirá brevemente el flujo de trabajo, de la operativa de “Adición de
una nueva relación”, tomando en cuenta que en esta operativa ya se encuentra integrado este
patrón de usabilidad.
El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la
especificación de este patrón (ver figura 47).
A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes
que se describen, se podrá revisar la figura 48 (Integración del patrón de usabilidad SSF en el
diseño de la funcionalidad Relacionar Personas):
• Ante la petición de adicionar una nueva relación a la persona seleccionada, la clase
controladora recibe los datos de la vista, los cuales los procesa y envía estos para su
persistencia a la capa de negocio, pasando respectivamente, por los componentes del patrón
de usabilidad Warning (ver sección 2.2.2 del presente capitulo).
• En la capa de negocio, el componente responsable de ejecutar esta operativa, es el
componente “RelacionesService”, con su operación “nuevaRelacion”.
José Germán Núñez Mori Página 119 de 237
• La operación “nuevaRelacion”, recibirá los datos necesarios y procederá a persistirlos por
medio de la capa de datos. Es en esta operativa, que se implementa controles de estado, es
decir, se validará, si la operación de persistir los datos, se realiza de manera satisfactoria,
con error u otros estados.
• Esta operación de “nuevaRelacion”, ante cualquiera de estas validaciones, informará de las
mismas a su observador, que en este caso, es el componente “AdministradorEstados”.
• El componente “AdministradorEstados”, recibirá del componente “RelacionesService”, la
notificación de que se ha producido un cambio de estado. Esta notificación, vendrá
acompañada de los datos necesarios de este cambio de estado, que permitirán a este
componente por medio de su operación “determinarEstado”, discernir el cambio de estado
que se ha producido en la capa de negocio.
• Una vez determinado, el tipo de estado que se ha producido en la capa de negocio, este
componente administrador (AdministradorEstados), enviará la información para su
tratamiento al componente respectivo, es decir, si se ha producido un error se enviará los
datos necesarios al componente “EstadoErrorService”.
• La clase controladora “RelacionarPerController”, una vez que envía los datos para su
persistencia a la capa de negocio, consultará a cada uno de los componentes de gestión de
estados (EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService), si se ha
producido algún cambio de estado en la operativa en curso (Adición de una relación).
• De haberse producido algún cambio de estado, la clase controladora, recogerá los datos
necesarios del componente de gestión de estados respectivo y procederá a informar de esto a
la vista, por medio de mecanismos del Framework Struts utilizado en la capa de
presentación.
2.2.3.3 Resultados de la integración del patrón de usabilidad SSF
En esta sección, se presentará los resultados tras la integración del patrón de usabilidad SSF a la
funcionalidad de “Relacionar Personas”. Estos resultados permitirán ilustrar lo que se menciona
en la sección de flujo de trabajo. Además se presentará la planificación actualizada de esta tarea.
Ante el evento de adición de una nueva relación, si la adición se realiza satisfactoriamente el
sistema informará al usuario de esto, en la zona de estados, ver la siguiente figura:
José Germán Núñez Mori Página 120 de 237
Figura 48: Resultados tras la adición satisfactoria de una nueva relación
Si, ante el evento de adición de una nueva relación, se produce algún error, como por ejemplo:
falta de recursos para realizar la operativa, error acceso a base datos, etc. El sistema notificará al
usuario de este error en la zona de estados (Final de la página Wb), ver la siguiente figura:
Figura 49: Resultados de error tras la adición de una nueva relación
A continuación se muestra la planificación actualizada de la tarea de integración del patrón de
José Germán Núñez Mori Página 121 de 237
usabilidad SSF:
Tabla 26: Planificación actualizada de la tarea de integración del patrón de usabilidad SSF
2.2.4 Integración del patrón de usabilidad Global Undo
En la presente sección, se detalla cada uno de los pasos seguidos para la integración del patrón
Global Undo (en adelante GU), a la funcionalidad de “Relacionar Personas”. Para mas detalle
de este patrón ver el anexo 03 (Especificación del Patrón de Usabilidad Global Undo).
Siguiendo la dinámica de las anteriores integraciones, a continuación se presenta la
planificación inicial de la tarea de integración del patrón de usabilidad GU:
Tabla 27: Planificación inicial de la tarea de integración del patrón de usabilidad GU
Esta sección, tomara como base para esta integración, la especificación de este patrón de
usabilidad (ver anexo 03 - Especificación del Patrón de Usabilidad Global Undo), usando
ciertos diseños como punto de partida para esta labor. A continuación se presenta los diseños
base de este patrón de usabilidad:
José Germán Núñez Mori Página 122 de 237
Figura 50: Diagrama de clases de la especificación del patrón de usabilidad GU
Figura 51: Diagrama de secuencias de la especificación del patrón de usabilidad GU
2.2.4.1 Integración del patrón de usabilidad GU a la capa de
presentación y capa de negocio
José Germán Núñez Mori Página 123 de 237
La integración de este patrón de usabilidad, ha implicado la creación de un nuevo componente
de tipo servicio (RelacionesHistorySessión), que dará soporte a las tareas que requiere este
patrón de usabilidad. Además, se adiciona una nueva operación “undoRelaciones”, tanto, en la
clase controladora (RelacionesPerController), como en el componente de servicio de la capa de
negocio (RelacionesService). Estas modificaciones, permitirán atenderá a las peticiones de los
usuarios, ante el evento de deshacer (Undo) de la operación en curso.
Según esta premisa, el diseño queda la siguiente manera:
Figura 52: Integración del patrón de usabilidad GU en la capa de negocio y capa de diseño
Adicional a estos cambios, se modifica también el flujo de actividades de la página Web, de la
funcionalidad en curso. Con estos modificaciones en el flujo de actividad, se busca adicionar un
nuevo evento a la misma, que haga referencia a la operativa de deshacer (Undo) y que esta tenga
su operación de soporte en el lado del sistema, es decir, una operación en su clase controladora
relacionada (ver figura 53). De acuerdo a esto el diagrama de actividades de la página Web
queda de la siguiente manera:
José Germán Núñez Mori Página 124 de 237
Figura 53: Integración del patrón de usabilidad GU en el diagrama de actividades de la página
de Adición de relaciones
Cada una de estas modificaciones siguen lo especificado por este patrón (Ve Figura 52). Por tal
motivo, a continuación se presenta un cuadro con las correspondencias de componentes
especificados y lo diseñado en la integración (ver Figura 54):
Componentes del P.U. GU Componentes de diseño en la funcionalidad
View RelacionarPerController
Controller RelacionarPerController
HistoryList RelacionesHistorySessión
Command RelacionesServiceBase
ConcreteCommand RelacionesService
DomainClass Relacion
HistoryException -
Tabla 28: Correspondencia de componentes del patrón de usabilidad GU y los componentes de
la funcionalidad
Como se pude ver en tabla 28, existe un componente de la especificación (HistoryException),
que no tiene correspondencia en el diseño de la integración, esto se debe a que este componente
ya se encuentra gestionado por uno de los Framework que utiliza el marco ágil de trabajo
(Spring).
José Germán Núñez Mori Página 125 de 237
2.2.4.2 Flujo de trabajo según el patrón de usabilidad GU
Con el objetivo de dar un mayor detalle de la integración del patrón de usabilidad GU, en la
presente sección, se describirá brevemente el flujo de trabajo, de la operativa de “Adición de
una nueva relación”, tomando en cuenta que en esta operativa ya se encuentra integrado este
patrón de usabilidad.
El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la
especificación de este patrón (ver figura 53).
De acuerdo a esto, a continuación, se presenta el detalle de este flujo de trabajo, donde para
tener relación de los componentes que se describen, se podrá revisar la figura 54 (Integración
del patrón de usabilidad GU en la capa de negocio y capa de diseño):
Detalle del flujo ante el evento de adición de una nueva relación:
• Cuando la petición de adición de una nueva relación, llega a la clase controladora
(RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda
esta información para ser enviado para su persistencia a la capa de negocio.
• De este objeto que se envía a la capa de negocio, su referencia será guardada por el
componente: “RelacionesHistorySessión”, con lo cual se estaría clonando el comando que
se esta ejecutando (Adición de una nueva relación).
Detalle del flujo ante el evento de deshacer (Undo), las nuevas relaciones:
• Cuando la petición de deshacer, llega a la clase controladora (RelacionarPerController), esta
recupera todos los objetos clonados en el componente “RelacionesHistorySessión”, que han
sido guardados en el transcurso de la operativa de adición de nuevas relaciones.
• Con este listado de objetos clonados, la clase controladora realiza una petición de deshacer
las relaciones asociadas a estos objetos. Esta petición se ejecuta contra la operación
“undoRelaciones” del componente de la capa de negocio “RelacionesService”.
• La operación “undoRelaciones”, recibe como parámetro, un listado de objetos del tipo
Relación, y solicita por cada objeto a la capa de datos, que elimine el registro persistido en
Base de datos.
José Germán Núñez Mori Página 126 de 237
2.2.4.3 Resultados de la integración del patrón de usabilidad GU
Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los
resultados a nivel de páginas Web.
Se adiciona dos nuevas relaciones a la persona seleccionada (PER005, PER006), ver la
siguiente figura:
Figura 54: Adición de nuevas relaciones considerando el patrón GU
Como se describe en la anterior sección, por cada adición de una nueva relación se realiza una
clonación del objeto que se esta adicionando, de tal manera que cuando el usuario realice la
petición de deshacer esta operativa, se recupere estos objetos clonados y se solicite de que se
elimine de Base de datos. De acuerdo a esto, esta pantalla quedaría de la siguiente manera tras el
evento de deshacer (Undo):
José Germán Núñez Mori Página 127 de 237
Figura 55: La adición de relaciones tras en el evento de deshacer (Undo)
A continuación, se presenta la actualización de la planificación asociada a la integración de este
patrón de usabilidad:
Tabla 29: Planificación actualizada de la tarea de integración del patrón de usabilidad GU
2.2.5 Integración del patrón de usabilidad Abort Operation
En esta sección, se detallará los pasos seguidos para la integración del patrón de usabilidad
Abort Operation a la funcionalidad de “Relacionar personas”. Para esta integración, el presente
trabajo se ha basado en la especificación del patrón Abort (ver anexo 04 – Especificación del
patrón de usabilidad Abort).
José Germán Núñez Mori Página 128 de 237
El patrón Abort Operation, en adelante AO, pertenece a la familia del patrón de usabilidad
Abort, siendo este patrón AO, una rama especifica, es decir, una especificación concreta para
ciertas tareas de usabilidad, que en este caso puntual, es aplicar este patrón para cancelar una
operación en curso.
Este patrón de usabilidad AO, basa mucho su planteamiento en el patrón de usabilidad Global
Undo (detallado en la anterior sección 2.2.4 del presente capitulo), es por este motivo, que la
integración de este patrón tomará como base el diseño y la implementación del patrón Global
Undo.
Siguiendo la especificación del patrón de usabilidad AO (ver anexo 04 – Especificación del
patrón de usabilidad Abort), se tomará como referencia para la integración, los siguientes
modelos base:
Figura 56: Diagrama de clases de la especificación del patrón de usabilidad AO
José Germán Núñez Mori Página 129 de 237
Figura 57: Diagrama de secuencia de la especificación del patrón de usabilidad AO
Como se puede apreciar en las anteriores figuras (figura 59 y 60), la estructura del
planteamiento de este patrón es casi similar a lo planteado por el patrón de usabilidad Global
Undo (ver figuras 52 y 33), variando específicamente en el flujo de actividades tras el evento de
cancelar una operación.
A continuación, se presenta la planificación inicial de la tarea de integración del patrón de
usabilidad AO a la funcionalidad en curso:
Tabla 30: Planificación inicial de la tarea de integración del patrón de usabilidad AO
2.2.5.1 Integración del patrón de usabilidad AO a la capa de
presentación y capa de negocio
La integración de esta patrón, ha implicado la creación de una nueva operación en la clase
controladora (RelacionesPerController), esta operación es: “cancelarRelaciones”, la cual
José Germán Núñez Mori Página 130 de 237
permitirá atender las peticiones de los usuarios ante el evento de cancelar la operación en curso
(adicionar una nueva relación).
Esta integración, utiliza un componente ya creado en la integración del patrón de usabilidad
Global Undo, llamado “RelacionesHistorySession”, que tendrá la misma utilidad que en este
patrón, es decir, clonará objetos de la operativa de adicionar nuevas relaciones.
De acuerdo esto el diseño queda de la siguiente manera:
Figura 58: Integración del patrón de usabilidad AO en la capa de negocio y capa de
presentación
Adicional a la operación nueva en la clase controladora, se modifica las actividades asociadas a
la pagina Web, que soporta la funcionalidad de “Relacionar Personas”. Estas modificaciones,
consisten en adicionar el nuevo evento de “Cancelar” y su respectivo estado de acción en el lado
del sistema, es decir, la referencia a la nueva operación (cancelarRelaciones) de la clase
controladora.
Este nuevo flujo, que hace referencia al evento de “Cancelar”, deberá indicar, que una vez
ejecutado esta operativa, se debe de regresar al home de la aplicación, es decir, a la página de
búsqueda de personas. Por tal motivo, este flujo deberá de tener un estado de fin, que haga
referencia a la funcionalidad de “Búsqueda de Personas”.
Según estas premisas el diseño de actividades asociadas a la página de “Adición de una nueva
relación”, queda de la siguiente manera:
José Germán Núñez Mori Página 131 de 237
Figura 59: Integración del patrón de usabilidad AO en el diagrama de actividades de la página
de Adición de relaciones
La modificaciones necesarias para esta integración, han seguido lo planteado por el patrón AO
(ver figura 59), por tal motivo, se presenta a continuación una tabla de correspondencias de
componentes, tanto de la especificación, como de la integración (ver figura 61):
Componentes del P.U. AO Componentes de diseño en la funcionalidad
View RelacionarPerController
Controller RelacionarPerController
HistoryList RelacionesHistorySessión
Command RelacionesServiceBase
ConcreteCommand RelacionesService
DomainClass Relacion
HistoryException -
ProgressIndicator -
Tabla 31: Correspondencia de componentes del patrón de usabilidad AO y los componentes de
la integración
José Germán Núñez Mori Página 132 de 237
Como se pude ver en tabla 31 (Correspondencia de componentes del patrón de usabilidad AO y
los componentes de la funcionalidad), existe dos componentes que no tienen correspondencia en
la integración, esto se debe, a que uno de ellos (HistoryException) es gestionado por el unos de
los Framework utilizados por el marco ágil de trabajo y el otro (ProgressIndicator), será tratado
mas adelante como una integración adicional
2.2.5.2 Flujo de trabajo según el patrón de usabilidad AO
A continuación, se explicará brevemente, la interacción de los componentes diseñados, para la
integración del patrón de usabilidad AO a la funcionalidad de “Relacionar Personas”, y cuya
secuencia, dará a entender el flujo de trabajo de este patrón, tanto a nivel de diseño como de
implementación. Todo esto, tomando como base el diagrama de secuencia de la especificación
del patrón (ver Figura 60).
A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes
que se describen, se podrá revisar la figura 61 (Integración del patrón de usabilidad AO en la
capa de negocio y capa de presentación):
Detalle del flujo ante el evento de adición de una nueva relación:
• Cuando la petición de adición de una nueva relación, llega a la clase controladora
(RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda
esta información para ser enviado para su persistencia a la capa de negocio.
• De este objeto que se envía a la capa de negocio, su referencia será guardada por el
componente: “RelacionesHistorySessión”, con lo cual se estaría clonando el comando que
se esta ejecutando (Adición de una nueva relación).
Detalle del flujo ante el evento de “Cancelar” la operativa de nuevas relaciones:
• Cuando la petición de cancelar, llega a la clase controladora (RelacionarPerController), esta
recupera todos los objetos clonados en el componente “RelacionesHistorySessión”, que han
sido guardados en el transcurso de la operativa de adición de nuevas relaciones.
• Con este listado de objetos clonados, la clase controladora realiza una petición de deshacer
las relaciones asociadas a estos objetos. Esta petición, se ejecuta sobre la operación
“undoRelaciones” del componente de la capa de negocio “RelacionesService”.
• La operación “undoRelaciones”, recibe como parámetro, un listado de objetos del tipo
José Germán Núñez Mori Página 133 de 237
Relación, y solicita por cada una de ellos, se elimine su registro persistido en Base de datos.
• Una vez terminada, la operativa de eliminar los registros asociados a la clonación, la clase
controladora (RelacionarPerController), redirecciona la response hacia la funcionalidad de
“Búsqueda de Personas”, que es para esta aplicación el home de la misma.
2.2.5.3 Resultados de la integración del patrón de usabilidad AO
Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los
resultados a nivel de pantallas Web.
Se adiciona una nueva relación a la persona seleccionada (PER003), ver la siguiente figura:
Figura 60: Adición de nuevas relaciones considerando el patrón AO
Tras el evento de “Cancelar”, el sistema, elimina los registros asociados a las últimas adiciones,
es decir, aquellos que han sido clonados y luego redirige el flujo hacia el home de la aplicación
(funcionalidad de búsqueda de personas).
José Germán Núñez Mori Página 134 de 237
Figura 61: Home de la aplicación tras el evento Cancelar
Si volvemos a consultar las relaciones de la persona, en la cuál se ejecuto el evento de
“Cancelar”, podemos apreciar que la relación que se adiciono no se encuentra.
Figura 62: Consulta de relaciones tras el evento de cancelar
A continuación, se presenta la planificación actualizada de la tarea de integración del patrón de
usabilidad AO.
José Germán Núñez Mori Página 135 de 237
Tabla 32: Planificación actualizada de la tarea de integración del patrón de usabilidad AO
2.2.6 Integración del patrón de usabilidad System Progress Feedback
En la siguiente sección, se detallará la integración del patrón System Progress Feedback, en
adelante SPF, a la funcionalidad de “Relacionar Personas”. Para esta integración, el presente
trabajo se ha basado en la especificación de este patrón de usabilidad (ver anexo 05 –
Especificación del patrón de usabilidad System Progress Feedback).
De acuerdo, a la especificación de este patrón de usabilidad, se tomará como punto de partida
para esta integración, los siguientes modelos:
Figura 63: Diagrama de clases de la especificación del patrón de usabilidad SPF
José Germán Núñez Mori Página 136 de 237
Figura 64: Diagrama de secuencia de la especificación del patrón de usabilidad SPF
Siguiendo la dinámica de las demás patrones ya integrados a la funcionalidad de “Relacionar
Personas”, a continuación se presenta la planificación inicial de las tareas asociadas a la
integración de este patrón de usabilidad:
Tabla 33: Planificación inicial de la tarea de integración del patrón de usabilidad SPF
2.2.6.1 Integración del patrón de usabilidad SPF a la capa de
presentación y capa de negocio
Cabe mencionar, antes de iniciar con el detalle de esta integración, que este patrón de usabilidad
SPF, no fue considerado como parte de los requisitos de usabilidad asociados a la historia de
José Germán Núñez Mori Página 137 de 237
usuario “Relacionar Personas” (ver capitulo de Fase de inicio del marco ágil de trabajo). Debido,
a que estamos en una iteración que tiene como objetivo, construir el prototipo de la arquitectura
que mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrón en
la arquitectura inicial.
Esta patrón de usabilidad SPF, será aplicado, sobre la funcionalidad dada por el patrón de
usabilidad Global Undo (ver sección 2.2.4 – Integración del patrón de usabilidad Global Undo),
es decir, que ira informando el progreso de la operación de deshacer (Undo) las adiciones de
nuevas relaciones.
En la integración de este patrón, se ha diseñado un nuevo componente del tipo servicio
(IndicadorProgresoService), que permitirá, dar soporte a las tareas requeridas por este patrón de
usabilidad, siendo una de las principales, la de un componente observador, que ira informando
del progreso de determinadas operaciones.
Adicional al nuevo componente diseñado para la integración de este patrón de usabilidad, se
adiciona una nueva operación en la clase controladora (RelacionarPerController), esta operación
es: “verificarProgreso”, que permitirá, dar soporte a las peticiones de aquellas funcionalidades,
que requieran que se muestre al usuario algo informativo del progreso de su operativa en curso.
De acuerdo a las modificaciones comentadas líneas arriba, se muestra el diseño tanto de la capa
de negocio como la de presentación:
Figura 65: Integración del patrón de usabilidad SPF en la capa de negocio y capa de diseño
José Germán Núñez Mori Página 138 de 237
Adicional a los cambios en componentes de la capa de negocio y presentación, se modifica
también el flujo de actividades de la página Web, de adición de nuevas relaciones. Con estas
modificaciones en el flujo de actividades, se busca adicionar un nuevo evento a la misma, que
haga referencia a la operativa de “Verificar el progreso” de un determinado evento y que esta
tenga su operación de soporte en el lado del sistema, es decir, una operación en su clase
controladora (ver figura 68).
Este nuevo evento, que se adiciona al flujo de actividades de la página Web, no representara un
evento implícito como tal, sino, más que todo una referencia a una operación en el lado del
sistema (soportada por la clase controladora), que permitirá, ir informando del progreso de un
evento especifico al usuario, que en este caso en concreto, es el evento de deshacer (Undo) de
las nuevas relaciones adicionadas.
De acuerdo a esto, el diagrama de actividades de la página Web queda de la siguiente manera:
Figura 66: Integración del patrón de usabilidad SPF en el diagrama de actividades de la
página Web de Adición de relaciones
Como se describe al inicio de esta sección, esta integración se basa en ciertos diseños obtenidos
José Germán Núñez Mori Página 139 de 237
de la especificación de este patrón de usabilidad SPF, es así, que la adición de un nuevo
componente y la creación de una nueva operación en la clase controladora (ver figura 68), se
basan en el diseño de clases de esta especificación (ver figura 66). Según esto, se presenta a
continuación una tabla de correspondencias entre componentes, tanto de la especificación como
de la integración en si:
Componentes del P.U. SPF Componentes de diseño en la funcionalidad
View RelacionarPerController
Controller RelacionarPerController
DomainClass RelacionesService
DomainClass Relacion
ProgressIndicator IndicadorProgresoService
Monitor SetInterval (Función javaScript asociada a las
página JSP)
Tabla 34: Correspondencia de componentes del patrón de usabilidad SPF y los componentes de
la Integración
Como se puede apreciar en la tabla 34, existe un componente de la especificación, llamado
Monitor, que tiene su correspondencia en una función javaScript en la integración, esto se debe,
a que en la implementación se hará uso de este lenguaje y que una de las funciones propias de
este lenguaje, como es el “setInterval”, simulará las tareas asociadas a este componente Monitor.
2.2.6.2 Flujo de trabajo según el patrón de usabilidad SPF
En esta sección, se detalla las actividades asociadas a la funcionalidad de “Adicionar relaciones”,
teniendo en cuenta que para esta operativa, se tiene integrado el patrón de usabilidad SPF.
Este flujo de trabajo, es una secuencia de actividades que se expone en esta sección, con el
objetivo, de proporcionar un mayor detalle del funcionamiento de este patrón de usabilidad SPF,
integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la
especificación de este patrón de usabilidad, específicamente, en su diagrama de secuencia (ver
figura 67).
A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes
que se describen, se podrá revisar la figura 68 (Integración del patrón de usabilidad SPF en la
capa de negocio y capa de diseño):
José Germán Núñez Mori Página 140 de 237
• Solicitada la petición de deshacer las nuevas relaciones adicionadas (Undo), la vista enviará
dicha petición para ser resuelta en su controlador relacionado (RelacionarPerController) y a
su vez, esta petición activará un timer en el objeto de monitorización, que pasado un
determinado tiempo, ejecutará determinadas acciones.
• Este objeto de monitorización es simulado por la función JavaScript "setInterval", la cual
residirá en la página Web asociada a la funcionalidad en curso, es decir, en lado del cliente.
• Una vez sobrepasado, el tiempo mínimo de 2 segundos en el timer del objeto de
monitorización, este verificará si la petición, de deshacer las nuevas relaciones adicionadas,
ha culminado, de ser así, mostrara los resultados respectivos en pantalla.
• En el caso de que no se haya culminado la petición, de deshacer las nuevas relaciones
adicionadas, el objeto de monitorización, lanzará una petición paralela (simulación de hilo
paralelo al principal), para verificar el progreso de esta operación de deshacer (Undo).
• El objeto encargado de simular este hilo paralelo, es el objeto XMLHttpRequest, el cual es
un objeto, de la tecnología asíncrona Ajax. Este objeto, presenta un esquema de trabajo que
se asemeja a lo especificado en el diagrama de secuencia, de la especificación del patrón de
usabilidad SPF (ver figura 67), por tal motivo a continuación se muestra el esquema de
trabajo de este objeto [SUNPB05]:
Figura 67: Esquema de trabajo del objeto XMLHttpRequest
• El objeto XMLHttpRequest, enviará una petición cada un segundo al controlador asociado
(RelacionarPerController), en su operación "verificarProgreso". Esta operación, solicitará la
José Germán Núñez Mori Página 141 de 237
información del progreso de la operativa de deshacer (Undo) al componente
“IndicadorProgresoService” y su operación “verificarProgreso”.
• Bien sabemos, que el servicio “RelacionesService”, es el encargado de deshacer las
relaciones adicionadas por medio de su operación “undoRelaciones”.
• Esta operación “undoRelaciones”, recibirá como parámetro un listado de las relaciones que
deberá de solicitar a la capa de datos que se elimine de base de datos, donde, por cada
relación eliminada deberá de contabilizarse el progreso que lleva respecto al total de
relaciones a eliminar, he informar de esto a los escuchadores suscritos.
• La manera de contabilizar el progreso de la relaciones a eliminar, consiste en que, por cada
relación eliminada, se contabilice todas la relaciones eliminadas y se divida entre el total de
relaciones a eliminar y para obtener el porcentaje de progreso se multiplique por cien. Es
este porcentaje que se informa a los escuchadores.
• El escuchador de progreso, suscrito al componente “RelacionesService”, es el componente
“IndicadorProgresoService y cada vez que el componente escuchado, envíe información de
progreso, este escuchador, guarde esta información como parte de sus atributos.
• Cada vez que la operación “verificarProgreso” del controlador (RelacionarPerController),
solicite esta información al componente “IndicadorProgresoService”, este tendrá el progreso
actualizado de la operativa en curso.
• Una vez obtenido, el progreso de la operativa de Undo en curso, la clase controladora
(RelacionarPerController), en su operación “verificarProgreso”, enviara esta respuesta al
objeto XMLHttpRequest, que será el encargado, junto a funciones javaScript propias de la
página Web, de informar esto en pantalla y además de verificar, que si se ha llegado a la
totalidad del progreso, que en este caso el cien por ciento, se anulen las peticiones al
controlador que se viene realizando por medio del hilo paralelo.
2.2.6.3 Resultados de la integración del patrón de usabilidad SPF
Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los
resultados a nivel de pantallas Web.
Se adicionan nuevas relaciones a la persona seleccionada:
José Germán Núñez Mori Página 142 de 237
Figura 68: Adición de distintas relaciones a la persona seleccionada
Adicionado numerosas relaciones, a la persona seleccionada (PER003), se procede a deshacer
(Undo) esta relaciones adicionadas, donde por cada relación eliminada se irá informando del
progreso de la operación en la página Web.
Figura 69: Barra de progreso mientras se aplica la operación de Undo a las relaciones
adicionadas
Una vez finalizada la operación, de deshacer las adiciones de relaciones, la barra de progreso
desaparecerá actualizando la página Web y mostrará las relaciones iniciales que tenía antes de
estas adiciones.
José Germán Núñez Mori Página 143 de 237
Siguiendo la dinámica de anteriores integraciones de patrones de usabilidad, a continuación, se
presenta la planificación actualizada asociada a las tareas de integración de este patrón de
usabilidad.
Tabla 35: Planificación actualizada de la tarea de integración del patrón de usabilidad SPF
2.2.7 Integración del patrón de usabilidad Abort Command
Este patrón de usabilidad Abort Command, en adelante AC, pertenece a la familia del patrón de
usabilidad Abort, al igual que el patrón Abort Operation (ver sección 2.2.5 – Integración del
patrón de usabilidad Abort Operation ), este también, es una rama especifica de este patrón
Abort (ver anexo 04 – Especificación del patrón de usabilidad Abort).
De acuerdo a esta premisa, en la presente sección se abordará, la integración de este patrón de
usabilidad AC a la funcionalidad de “Relacionar Personas”, específicamente aplicado, sobre el
comando asociado al patrón de usabilidad System Progress Feedback, es decir, se buscará
integrar el patrón, para lograr cancelar el comando, que muestra la barra de progreso asociada a
cierta operativa.
Al igual, que el patrón de usabilidad System Progress Feedback, el patrón AC, no fue
considerado como parte de los requisitos de usabilidad asociados a la historia de usuario
“Relacionar Personas” (ver capitulo de Fase de inicio del marco ágil de trabajo). Debido, a que
estamos en una iteración que tiene como objetivo construir el prototipo de la arquitectura, que
mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrón en la
arquitectura inicial.
Mencionar, que esta integración del patrón de usabilidad AC, basará su diseño en los modelos
base de la especificación del patrón Abort, teniendo ciertos matices propios del patrón de
José Germán Núñez Mori Página 144 de 237
usabilidad AC, por tal motivo, se utilizará el mismo diagrama de clases base utilizado por el
patrón Abort Operation (ver Figura 59).
La diferencia en los enfoques de integración entre el patrón Abort Operation y el AC, reside en
el diseño base de la interacción de los componentes que intervienen en el planteamiento de uno
u otro patrón. Por tal motivo la integración del patrón de usabilidad AC, utilizará como base el
siguiente diagrama de secuencias:
Figura 70: Diagrama de secuencia de la especificación del patrón de usabilidad AC
Como parte inicial de esta integración, se presenta la planificación de las tareas necesarias en la
labor de integración del patrón de usabilidad AC a la funcionalidad de “Relacionar Personas”:
Tabla 36: Planificación inicial de tarea de integración del patrón de usabilidad AC
José Germán Núñez Mori Página 145 de 237
2.2.7.1 Integración del patrón de usabilidad AC a la capa de
presentación y capa de negocio.
Como se describe al inicio de esta sección, esta integración, será aplicada sobre el comando de
información de progreso de ciertas funcionalidades, por tal motivo esta integración, basará su
modelado en el diseño de nuevos componentes, realizados en la integración del patrón de
usabilidad System Progress Feedback:
Figura 71: Integración del patrón de usabilidad AC en la capa de negocio y capa de diseño
Como se puede ver en la figura 74, se adiciona nuevas operaciones al componente de servicio
“IndicadorProgresoService” y a la clase controladora, las cuales permitirán, que se ejecuten las
tareas necesarias de este patrón de usabilidad AC, sobre el comando del patrón System Progress
Feedback.
Adicional a estos cambios, se modifica también el flujo de actividades asociadas la página Web,
de adición de nuevas relaciones. Esta modificación, consiste en adicionar un nuevo evento
llamado “cancelarComando” y su respectivo estado de acción en el lado del sistema (operación
en la clase controladora), que permite las peticiones de cancelar un comando determinado, en
este caso en concreto, el comando de información de progreso de la operativa de deshacer
(Undo).
De acuerdo a esto, el flujo de actividades asociado a la página Web, de adicionar nuevas
relaciones, queda de la siguiente manera:
José Germán Núñez Mori Página 146 de 237
Figura 72: Integración del patrón de usabilidad AC en el diagrama de actividades de la página
Web de Adición de relaciones
Con el propósito de entender cada uno de los cambios, realizados en los componentes de diseño
tanto de la capa de presentación, como la de negocio, se presentará un cuadro de
correspondencia entre componentes de la especificación del patrón de usabilidad Abort (ver
Figura 59) y la integración del patrón AC (ver figura 74):
José Germán Núñez Mori Página 147 de 237
Componentes del P.U. AO Componentes de diseño en la funcionalidad
View RelacionarPerController
Controller RelacionarPerController
HistoryList -
Command RelacionesServiceBase
ConcreteCommand RelacionesService
DomainClass Relacion
HistoryException -
ProgressIndicator IndicadorProgresoService
Tabla 37: Correspondencia de componentes del patrón de usabilidad AC y los componentes de
la integración
Como se puede apreciar en la tabla 37, existen ciertos componentes de la especificación que no
tiene su correspondencia en la parte de integración, esto se debe a dos motivos:
• Que alguno de ellos, no son requeridos por esta patrón AC, si no mas bien, por el patrón de
usabilidad Abort Operation, siendo este el componente “HistoryList”.
• Que el resto de componentes, es administrado por el Framework de integración Spring
utilizado por el marco ágil de trabajo
2.2.7.2 Flujo de trabajo según el patrón de usabilidad AC
Este flujo de trabajo, es una secuencia de actividades que se expone en esta sección, con el
objetivo, de proporcionar un mayor detalle del funcionamiento de este patrón de usabilidad AC,
integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la
especificación del patrón de usabilidad Abort, específicamente, en su diagrama de secuencia
(ver figura 73).
A continuación, el detalle de este flujo de trabajo, donde para tener relación de los componentes
que se describen, se podrá revisar la figura 74 (Integración del patrón de usabilidad AC en la
capa de negocio y capa de diseño):
• En la página Web, de adición de nuevas relaciones, cuando se ejecuta el comando “Undo”
de las relaciones recién adicionadas, se muestra al usuario un barra informativa del progreso
de la operación en curso.
• Esta barra de progreso informativa, contará con la opción de cancelar, la cual permitirá
José Germán Núñez Mori Página 148 de 237
abortar el progreso del comando en curso. Esta cancelación del comando en curso, implicará
abortar la barra de progreso y cancelar las acciones respectivas de la operación Undo.
• Una vez realizada la petición de cancelar el comando, la clase controladora, recibirá esta
petición para su tratamiento en la operación “cancelarComando”.
• La operación “cancelarComando”, solicitará al componente “IndicadorProgresoService”,
que actualice el estado de su atributo, que hace referencia a cancelar la operativa de
progreso, esto se hará por medio de la operación “actualizarEstadoCancelar”.
• Sabemos que la operación “undoRelaciones”, del componente “RelacionesService”, se
encarga de solicitar a la capa de datos la eliminación de relaciones ya persistidas y además
de informar de este progreso a su escuchador “IndicadorProgresoService”, donde, por cada
vez que informa a su escuchador con el progreso de esta operación, verificará si el estado de
cancelación de este comando esta activo.
• Si el estado de cancelación no esta activo, el componente “RelacionesService”, seguirá con
la operativa en curso, caso contrario, abortará su operación de eliminación de relaciones, lo
cual implicará, que las relaciones eliminadas antes que el estado de cancelación este activo,
persistirá su eliminación en bases de datos y de las restantes quedará su registro.
• En la operación “cancelarComando”, de la clase controladora, una vez solicitado la
actualización del estado de cancelación de comando al componente
“IndicadorProgresoService”, volverá consultar, las relaciones asociadas a las persona de la
operativa y retorna estos resultados a pantalla.
2.2.7.3 Resultados de la integración del patrón de usabilidad SPF
Con el objetivo de ilustrar lo descrito en la anterior sección, a continuación se presenta los
resultados a nivel de pantallas Web.
Se adicionan nuevas relaciones a la persona seleccionada:
José Germán Núñez Mori Página 149 de 237
Figura 73: Adición de distintas relaciones a la persona seleccionada
Adicionado numerosas relaciones, a la persona seleccionada (PER003), se procede a deshacer
(Undo) esta relaciones adicionadas, donde por cada relación eliminada se irá informando del
progreso de la operación en la página Web.
Figura 74: Barra de progreso con opción de cancelar, ante la operativa de Undo de las
relaciones adicionadas
Mientras se va informando del progreso de la operativa de Undo de las relaciones adicionadas,
se pude cancelar este progreso, implicando esto, que se aborta la operación hasta el punto de
José Germán Núñez Mori Página 150 de 237
progreso que se tenía, es decir, que eliminan aquellas relaciones antes de abortar la operación.
Para el caso presentado en la figura 51 (Barra de progreso con opción de cancelar, ante la
operativa de Undo de las relaciones adicionadas), si se cancela la operativa en curso al 20 por
ciento de su avance, implicará que solo elimine una relación de las adicionas, esta relación sería
la asociada a la persona “PER001”.
Figura 75: Tras el evento de cancelar el comando de Undo de relaciones
Como parte final de los resultados de la integración del patrón de usabilidad AC, se presenta la
planificación actualizada, asociada a esta tarea:
Tabla 38: Planificación actualizada de la tarea de integración del patrón de usabilidad AC
José Germán Núñez Mori Página 151 de 237
2.3 Planificación tras la primera iteración
Una vez realizada cada una de las integraciones planificadas, a continuación se presentan un
reporte genérico, que informarán el como se ha llevado a cabo cada una de las tareas planteadas
a lo largo del tiempo.
Figura 76: Carga de trabajo a lo largo de la planificación
Como se puede apreciar en la figura 76, se muestra la carga de trabajo a lo largo de tiempo de la
planificación. Se puede observar como esta carga va disminuyendo mientras mas cerca estamos
de la fecha fin de la planificación.
Cada una de las integraciones a la funcionalidad de “Relacionar Personas”, que se ha descrito a
lo largo de este capítulo, conforma en su conjunto, el prototipo de la arquitectura propuesta en
esta fase de elaboración. Es en base a esta estructura de trabajo, que se enfocará las futuras
iteraciones de la fase de desarrollo, que en el presente trabajo ya no serán contempladas.
José Germán Núñez Mori Página 152 de 237
VI. Conclusiones En el presente capitulo, se presenta las conclusiones obtenidas tras la realización de esta Tesis
de fin de Master.
Este trabajo fue desarrollado siguiendo los lineamientos de las metodologías á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 guía para la inclusión de los principios de usabilidad en el desarrollo
del sistema.
Desde el punto de vista metodológico, el marco ágil de trabajo planteado, fue utilizado como
base para la aplicación del paradigma orientado a objetos, demostrando de esta manera su
amplia adecuación y alto grado de utilidad en el desarrollo de sistemas que sigan esta estructura.
El entorno tecnológico seleccionado para la construcción del sistema, resulto apropiado y no
fueron detectados inconvenientes importantes durante el desarrollo del mismo, que pudiera
afectar o contradecir la elección realizada, si no mas bien contribuyeron, en la inclusión de los
principios de usabilidad antes del desarrollo.
El alto grado de disponibilidad de bibliotecas de uso variadas y de herramientas de libres
distribución de la tecnología Java, constituyen otro de los motivos que justifican la selección de
la plataforma sobre la que se ha desarrollado en sistema, alentando así, el uso de las mima tanto
para fines académicos 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 diseño
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 metodologías á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 también afecta al
núcleo del sistema”
José Germán Núñez Mori Página 153 de 237
VII. Referencias Bibliográficas
� [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 Arquitectónico, 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. Canós, Patricio Letelier y Mª Carmen Penadés, Metodologías ágiles
en el desarrollo de software, 2009 � [CRLA02] Craig Larman, UML y Patrones 2º Edición, 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, Metodologías ágiles, 2008.
� [JOKR05] Joe Krebs, RUP in the dialogue with Scrum, 2005.
� [KEBE02] Kent Beck , Una explicación de la programación 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é Germán Núñez Mori Página 154 de 237
� Development, http://www.agilemanifesto.org/, 2001.
� [MDAWI10] Model Driven Architecture, http://en.wikipedia.org/wiki/Model-driven_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. Sánchez, Patricio Letelier y José H. Canos, Mejorando la
gestión 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 Hernán, Diseño de una metodología ágil de desarrollo de
software, [email protected], 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é Germán Núñez Mori Página 155 de 237
VIII. Anexos
José Germán Núñez Mori Página 156 de 237
Anexo 01: Especificación Patrón de Usabilidad Warning
José Germán Núñez Mori Página 157 de 237
USABILITY-ENABLING GUIDELINE
Identification
Name Warning Family Feedback
Aliases Status Display; Modeling Feedback Area
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
José Germán Núñez Mori Página 158 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
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
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 vice-
versa). 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).
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?
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é Germán Núñez Mori Página 159 de 237
Figure 1: Warning. Use Case Model
José Germán Núñez Mori Página 160 de 237
Figure 2: Warning. System Responsibility Clusters
José Germán Núñez Mori Página 161 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES
System Responsibility Generic Component Responsibilities
W_SR-1 Be aware of damaging actions 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 transparency’s sake (an invoking class need not know if it’s 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 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.
W_SR-3 Request confirmation 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.
W_SR-4 Request authorization 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.
W_SR-5 Display warning 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)
José Germán Núñez Mori Página 162 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller DomainClassWrap DomainClass Warning
W_SR-1 Be aware of damaging actions
1. View listens for user calls to actions,
doAction(), and passes them on to
the 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)
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
6a. DomainClass
executes the
invoked method,
doAction().
3,
4
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.
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
3,
4
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
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.
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
Confirmation)
is forwarded
onto the View
3,
4
José Germán Núñez Mori Página 163 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller DomainClassWrap DomainClass Warning
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
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.
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 an
Authentication)
is forwarded
onto the View
3,
4
W_SR-5 Display warning
As detailed in W_SR-2, W_SR-3 and
W_SR-4, it is the View’s responsibility
to display Warnings. To do so
appropriately, it uses all the information
available in the Warning object.
3,
4
José Germán Núñez Mori Página 164 de 237
Figure 3: Warning. Usability-enabling design pattern. Class diagram
José Germán Núñez Mori Página 165 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é Germán Núñez Mori Página 166 de 237
Anexo 02: Especificación Patrón de Usabilidad System Status Feedback
José Germán Núñez Mori Página 167 de 237
USABILITY-ENABLING GUIDELINE
Identification
Name System Status Feedback (SSF) Family Feedback
Aliases Status Display; Modeling Feedback Area
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.
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é Germán Núñez Mori Página 168 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
Status change notification
HCI experts argue that the user wants to be
notified when a change of status occurs.
W_ELAB-2: Source of status changing events
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
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_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).
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, de-
emphasizes the trivial, doesn’t 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.
W_Q-7 For each system status, which type of notification should be shown to the user?
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.
José Germán Núñez Mori Página 169 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
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-to-bottom, and that something in the upper left corner will be looked at most often[].
W_ELAB-4: Status placement and writing directions
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.
W_Q-8 How and where will each type of notification be shown to the user?
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)
Table 2: System Status Feedback. Usability Elicitation Guideline
José Germán Núñez Mori Página 170 de 237
Figure 5: System Status Feedback. Use Case Model
José Germán Núñez Mori Página 171 de 237
Figure 6: System Status Feedback. System Responsibility Clusters
José Germán Núñez Mori Página 172 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES
System Responsibility Generic Component Responsibilities
W_SR-6 Be aware of system statuses (and their changes)
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é Germán Núñez Mori Página 173 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller StatusManager Status DomainClass
W_SR-10 Be aware of system statuses (and their changes)
1. Upon system
initialization, the
StateManager subscribes to
each DomainClass which it
knows can execute status-
changing actions.
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.
3,
5
1. The View must subscribe to each
Status object upon system
initialization.
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.
3,
5
W_SR-11 Handle user-initiated status changes
1. The View listens user’s requests
for execution actions action, and
forwards it to the Controller.
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
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 DomainClass executes the (status-altering) action and for notifies the StatusManager
3,
4
W_SR-12 Handle system-initiated status changes
2. The StatusManager
determines the
corresponding Status object
to update and does so with
the information sent forth
by the DomainClasses
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)
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
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.
3,
4
José Germán Núñez Mori Página 174 de 237
Figure 7: System Status Feedback. Usability-enabling design pattern. Class diagram
José Germán Núñez Mori Página 175 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é Germán Núñez Mori Página 176 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é Germán Núñez Mori Página 177 de 237
Anexo 03: Especificación Patrón de Usabilidad Global Undo
José Germán Núñez Mori Página 178 de 237
USABILITY-ENABLING GUIDELINE
Identification
Name Undo Family Undo/Cancel
Aliases Multi-Level Undo [Tidwell, 2002]; Undo [Welie, 2003]; Global Undo / Object-Specific Undo [Laasko, 2003]; Allow Undo [Brighton, 1998]
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.
José Germán Núñez Mori Página 179 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
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 aren’t 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.
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.
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?
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.
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]
W_ELAB-6: Warnings: Authorization
Most likely a warning of the type Autorization will
be required. See warning pattern for the warning
process.
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.
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-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-13 Will a redo functionality be
provided?
W_Q-14 How will the user be provided
access to the redo functionality?
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)
José Germán Núñez Mori Página 180 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
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
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.
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?
W_EX-10: MS Word’s 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.
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, it’s 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?
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”
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 Specific Undo & Global Undo
Redo will only be available at object level if it is
available globally. Same with 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-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.
Table 3: Undo. Usability Elicitation Guideline
José Germán Núñez Mori Página 181 de 237
Figure 10: Undo. Use Case Model
José Germán Núñez Mori Página 182 de 237
Figure 11: Undo. System Responsibility Clusters
José Germán Núñez Mori Página 183 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES
System Responsibility Generic Component Responsibilities
W_SR-14 Support Undo functionality (storing, undoing)
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 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
W_SR-16 Support Redo functionality 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 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.
W_SR-18 Support Multi-Level Undo and History
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
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.
W_SR-20 Allow Object-Specific Undo/Redo
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é Germán Núñez Mori Página 184 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller ConcreteCommand HistoryList DomainClass
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
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.
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.
3,
4
1. The View must listen
for invocation of the
Undo action. Upon
reception, it must
notify the Controller.
2. The Controller orders the
HistoryList to undo the last action. 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
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.)
3,
5
W_SR-23 Support Redo functionality
1. The View must listen
for invocation of the
Redo action. Upon
reception, it must
notify the Controller.
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.
3,
6
W_SR-24 Provide user access to Redo
1. The View must
present the user with
the mean(s) to call the
Undo action (i.e. dit
menu, Ctrl-Z, etc.)
3,
6
José Germán Núñez Mori Página 185 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller ConcreteCommand HistoryList DomainClass
W_SR-25 Support Multi-Level Undo and History
3. When the View is
notified of changes in
the HistoryList it
updates its History
Displays accordingly.
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
3,
4,
5,
6
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. 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,
5,
6
W_SR-27 Allow Object-Specific Undo/Redo
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.
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
José Germán Núñez Mori Página 186 de 237
Figure 12: Undo. Usability-enabling design pattern. Class diagram
José Germán Núñez Mori Página 187 de 237
Figure 13: Undo. Usability-enabling design pattern. Sequence Diagram “Execute Action” (W_SR-1)
José Germán Núñez Mori Página 188 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é Germán Núñez Mori Página 189 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é Germán Núñez Mori Página 190 de 237
Anexo 04: Especificación Patrón de Usabilidad Abort
José Germán Núñez Mori Página 191 de 237
USABILITY-ENABLING GUIDELINE
Identification
Name Abort Family Undo/Cancel
Aliases Emergency Exit [Brighton, 1998]; Go Back to a Safe Place [Tidwell, 1999]; Go Back [Tidwell, 1999]; Prominent Cancel [Tidwell, 02]
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.
José Germán Núñez Mori Página 192 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
Cancelling Commands
Si un comando tarda más 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
opción de Cancelar (además de la
información sugerida por el
mecanismo Progress Feedback) para
permitir la interrupción de su
procesamiento y el regreso al estado
anterior [Nielsen, 93].
W_ELAB-11: Identificación/Selección
Se entiende por “comando” una tarea indivisible invocada
por el usuario.
Es necesario identificar los comandos potencialmente largos
(>10s). Solo estos serán cancelables por el usuario.
Comandos más cortos no serán 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 atención especial y
para el resto definir un comportamiento estándar (por
defecto) de cancelación
Una vez identificados los comandos potencialmente largos
deberá consultársele al usuario si existe alguno excepcional
para el cual no deba darse la opción de cancelar. Es
importante destacar en esta discusión que la recomendación
HCI indica que todos estos comandos deberían ser
cancelables, pero es necesario permitirle al usuario hacer
excepciones en casos puntuales que así lo requieran
¿Qué comandos requerirán la opción de cancelar?
Para los comandos listados en 0 ¿Cómo debe presentarse al
usuario la opción de cancelar?
Para cada una de los comandos listados en 0 ¿A qué estado
pasará el sistema luego de que el usuario elija la
opción de cancelar?
W_EX-13:
W_ELAB-12: Presentación
Existen maneras éstandar y simples de cancelar comandos
(i.e. botón X, ctrl-c, etc.) Discutir con el usuario solamente si
tiene alguna necesidad específica para alguno de los
comandos.
AO_E4: Control de Regreso a Estado Al cancelar un comando es necesario deshacer
(automáticamente) los efectos que éste pueda haber tenido
hasta el momento.
José Germán Núñez Mori Página 193 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
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. Además,
hacer backgracking a lo largo de
múltiples estados consecutivos puede
resultar tedioso [Tidwell, 99]. Por
esta razón, en aplicaciones basadas
en ventanas (GUI), es estándar tener
un botón de Cancel que cierre la
ventana de diálogo actual y descarte
cualquier cambio hecho por el
usuario dentro de la misma.
W_ELAB-13: Identificación/Selección
Se entiende por “operación” cualquier interacción realizada
en sub-ventanas (generalmente de múltiples pasos )
Toda operación 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
algún motivo excepcional no deba serlo.
En caso de que no resulte viable listar todas las operaciones
cancelables, listar solo aquellas que requieran atención
especial y para el resto definir un comportamiento estándar
(por defecto) de cancelación
¿Qué operaciones requieren la opción de cancelar?
W_EX-14:
W_ELAB-14: Presentación
Discutir con el usuario si tiene alguna necesidad especifica en
cuanto a la presentación de la opción de cancelar
operaciones ejecutadas desde sub-ventanas. De lo contrario
utilizar el botón de Cancelar estándar.
Para las operaciones listadas en 0 ¿Cómo debe presentarse
al usuario la opción de cancelar?
W_EX-15:
AO_E4: Control de Regreso a Estado Al cancelar una operación se presentan dos posibles
escenarios:
La operación a cancelar ha consistido (al momento de la
cancelación) únicamente de navegación entre pasos. La
cancelación de este tipo de operaciones consistirá
únicamente en salir de la sub-ventana correspondiente.
La operación a cancelar ha provocado cambios en el estado
del sistema. En este caso, la cancelación deberá, además de
salir de la sub-ventana, deshacer dichos cambios,
regresando al sistema al estado previo a la invocación de la
operación (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 opción de cancelar?
W_EX-16:
Exiting the application
Aquellos usuarios que utilizan un
gran número de aplicaciones
simultáneamente pueden necesitar
W_ELAB-15: Presentación de opción de ‘salir’
Discutir con el usuario si tiene alguna necesidad especifica en
cuanto a la presentación de la opción de Salir de la aplicación.
De lo contrario utilizar estándar del OS/lenguaje
¿Dónde y cómo se presentará al usuario la opción de Salir? (i.e. botón rojo X arriba-derecha en
windows)
José Germán Núñez Mori Página 194 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
salir de un programa rápidamente
cuando alguna tarea de mayor
prioridad necesite los recursos del
sistema, o cuando se haya iniciado el
programa por error [Brighton, 98].
Por esta razón, a nivel de aplicación,
es necesario garantizar que la opción
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 opción de Salir luego de
haber manipulado datos, se debe
presentar la opción de “Guardar
Cambios”
W_ELAB-16: Manejo de Cambios
Generalmente la opción de ‘guardar cambios’ es relevante en
aplicaciones que modifican archivos o registros durante su
ejecución.
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)
Se desea presentar al usuario la opción de Guardar
Cambios?
W_EX-17:
W_ELAB-17: Presentación de opción “Guardar Cambios”
Discutir con el usuario si tiene alguna necesidad especifica en
cuanto a la presentación de la opción de Guardar Cambios.
De lo contrario utilizar estándar del OS/lenguaje
Si la respuesta a 0 es afirmativa: ¿Dónde y cómo se
presentará la opción de Guardar Cambios?
W_EX-18:
W_ELAB-18: Culminación de operaciones y
comandos
En cuanto a detener los comandos/operaciones en ejecución al momento de salir existen varias alternativas:
Salida Inmediata: Abortar todas las tareas (descartando sus
resultados) y cerrar la aplicación sin consultar al usuario.
Delegación de Control: Cediendo el control a los comandos
u operaciones activos en ese momento antes de cerrar
definitivamente la aplicación.
Espera: Preguntar al usuario si está seguro de que desea
salir, abortando todas las tareas en ejecución. Si responde
que sí, se cancelarán inmediatamente todas las tareas de la
manera estándar establecida.
Consulta: Dar al usuario la opción de elegir entre los modos
de salida a, b y c
Si al seleccionar la opción de ‘salir’ existen
operaciones/comandos en ejecución ¿Como se
manejará la culminación de los mismos (a,b,c o
d)?
W_EX-19:
Table 4: Abort. Usability Elicitation Guideline
José Germán Núñez Mori Página 195 de 237
Figure 16: Abort. Use Case Model
José Germán Núñez Mori Página 196 de 237
Figure 17: Abort. System Responsibility Clusters
José Germán Núñez Mori Página 197 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES
System Responsibility Generic Component Responsibilities
W_SR-28 Identify cancellable commands
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.
W_SR-29 Cancel commands and handle application state
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
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.
W_SR-31 Cancel operations and handle application state
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)
W_SR-32 Exit application handling potential on-going commands/operations
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/he’d 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 UI’s responsibility to know whether or not to prompt the user for an exit type. If no prompt is made, it is also the UI’s 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é Germán Núñez Mori Página 198 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller ConcreteCommand HistoryList DomainClass
W_SR-34 Identify
cancellable commands
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.
3,
4
W_SR-35 Cancel
commands and handle application state
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.
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.
3,
4,
5
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).
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.
3,
sbs
José Germán Núñez Mori Página 199 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View Controller ConcreteCommand HistoryList DomainClass
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.
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).
3,
sbs
W_SR-38 Exit
application handling
potential on-going commands/ operations
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.
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
3,
6
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()
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
José Germán Núñez Mori Página 200 de 237
Figure 18: Abort. Usability-enabling design pattern. Class diagram
José Germán Núñez Mori Página 201 de 237
Figure 19: Abort. Usability-enabling design pattern. Sequence Diagram “Execute command” (W_SR-34)
José Germán Núñez Mori Página 202 de 237
Figure 20: Abort. Usability-enabling design pattern. Sequence Diagrams “Cancel command” (W_SR-32)
José Germán Núñez Mori Página 203 de 237
Figure 21: Abort. Usability-enabling design pattern. Sequence Diagrams “Cancel operation” (W_SR-38 and W_SR-39)
José Germán Núñez Mori Página 204 de 237
Anexo 05: Especificación Patrón de Usabilidad System Progress Feedback
José Germán Núñez Mori Página 205 de 237
205
USABILITY-ENABLING GUIDELINE
Identification
Name System Progress Feedback (SPF) Family Feedback
Aliases 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]
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]
José Germán Núñez Mori Página 206 de 237
206
TABLE 1. USABILITY ELICITATION GUIDELINE
HCI Recommendation Elaboration Discussions with Stakeholders Usage Examples (optional)
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]:
What’s 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
it’s 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]
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 Which tasks are likely to take more
than a few seconds (2 to 5) to
complete, needing progress
information to be displayed?
W_Q-23 For which of these can actual
progress be calculated?
W_Q-24 For those whose progress can be
calculated, which can provide the
following information?
W_Q-25 Identifiable phases completed
W_Q-26 Time remaining for completion
W_Q-27 Units processed
W_Q-28 Percentage completed
W_Q-29 For any remaining tasks (whose
progress cannot be calculated) what
kind of indeterminate progress
indicator will be shown to the user?
W_Q-30 For which tasks will a cancel option
be provided to the user?
W_Q-31 For the tasks listed above, how will
the cancel option be provided?
W_Q-32 For every task, what textual
information (if any) will be shown to
the user, together with the progress
indicator?
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.
Table 5: System Progress Feedback. Usability Elicitation Guideline
José Germán Núñez Mori Página 207 de 237
207
Figure 22: System Progress Feedback. Use Case Model
José Germán Núñez Mori Página 208 de 237
208
Figure 23: System Progress Feedback. System Responsibility Clusters
José Germán Núñez Mori Página 209 de 237
209
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES
System Responsibility Generic Component Responsibilities
W_SR-40 Calculate and provide progress information
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 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)
W_SR-42 Provide textual information The component responsible for displaying progress must also know of and display any needed textual information along with the progress details.
W_SR-43 Provide indeterminate progress information
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.
José Germán Núñez Mori Página 210 de 237
210
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)
System Responsibility Objects Fig
View ProgressIndicator Monitor Controller DomainClass
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)
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.
3a. The Monitor class
starts up a clock and
notifies the view
after the time (2s)
has elapsed.
3b. The
Controller
invokes the
action, calling the
appropriate
class.
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
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
2. Depending on the parameter
passed, the ProgressIndicator will
enable a ‘cancel’ button or not.
3,
4
W_SR-46 Provide textual information
1. When the View creates the ProgressIndicator it
must pass it the textual information to display
2. The ProgressIndicator holds this text and displays it alongside the progress information
3,
4
W_SR-47 Provide indeterminate progress information
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.
3,
4
José Germán Núñez Mori Página 211 de 237
211
Figure 24: System Progress Feedback. Usability-enabling design pattern. Class diagram
José Germán Núñez Mori Página 212 de 237
212
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)
José Germán Núñez Mori Página 213 de 237
213
Anexo 06: Patrones de Usabilidad en la Elicitación
José Germán Núñez Mori Página 214 de 237
214
Usability Elicitation Patterns (USEPs)
Natalia Juristo1, Ana Moreno1, Maria-Isabel Sanchez-Segura2 1School of Computing - Universidad Politécnica de Madrid, Spain
[email protected]; [email protected] 2Department of Computing - Universidad Carlos III de Madrid, Spain
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
Usability Mechanism
Goal
Feedback System Status To inform users about the internal status of the system Interaction To inform users that the system has registered a user interaction,
i.e., that the system has heard users Warning To inform users of any action with important consequences
Long Action Feedback
To inform users that the system is processing an action that will take some time to complete
Undo Cancel
Global Undo To undo system actions at several levels
Object-Specific Undo
To undo several actions on an object
Abort Operation
To cancel the execution of an action or the whole application
Go Back To go back to a particular state in a command execution sequence User Input Errors Prevention/ Correction
Structured Text Entry
To help prevent the user from making data input errors
Wizard Step-by-Step Execution
To help do tasks that require different steps with user input and correct such input
User Profile Preferences To record each user's options for using system functions Personal
Object Space To record each user's options for using the systems interface.
Favourites To record certain places of interest for the user
José Germán Núñez Mori Página 215 de 237
215
Help Multilevel Help
To provide different help levels for different users
Commands Aggregation
Commands Aggregation
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 aplicación 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 Issues to be discussed with stakeholders
1. HCI experts argue that the user wants to be notified when a change of status occurs [7]
Changes in the system status can be triggered by user-
requested 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?
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
For each situation identified above under item 1,
discuss with the user:
2.1. Which information will be shown to the
José Germán Núñez Mori Página 216 de 237
216
happens. Displays should be put together in a way that emphasizes the important things, de-emphasizes the trivial, doesn’t 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 user’s culture). So, ask
about the user’s 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
José Germán Núñez Mori Página 217 de 237
217
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 What’s 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 Issues to be discussed with stakeholders
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]
1.1. For each action requested by the user, it should be discussed which kina of acknowledge the
system will provide (indenting a button, back-
lighting 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.
José Germán Núñez Mori Página 218 de 237
218
USEP for the Long Action Feedback mechanism
IDENTIFCATION
Name: Long Action Feedback
Family: Feedback
Alias: Progress Indicator [7] [8] Progress [10]
Let User Know What’s 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 Issues to be discussed with stakeholders
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].
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. Show an animated indicator of how much progress has been made. Either verbally or graphically (or both). Tell the user [7] [8]:
o what’s currently going on,
o what proportion of the operation is done so far,
o how much time remains, and
o how to stop it (or cancell 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 it’s still going on [7] [8], use an Indeterminate Progress Indicator [11].
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].
Usability Mechanism Specification Guide
José Germán Núñez Mori Página 219 de 237
219
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
José Germán Núñez Mori Página 220 de 237
220
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 Issues to be discussed with stakeholders
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.
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. 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.
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
José Germán Núñez Mori Página 221 de 237
221
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
José Germán Núñez Mori Página 222 de 237
222
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 aren’t 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?
José Germán Núñez Mori Página 223 de 237
223
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.
José Germán Núñez Mori Página 224 de 237
224
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 Issues to be discussed with stakeholders
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].
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.
José Germán Núñez Mori Página 225 de 237
225
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 Issues to be discussed with stakeholders
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.
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. At operation level, if the user gets into a space or state that they don’t 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.
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 información
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. 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].
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.
José Germán Núñez Mori Página 226 de 237
226
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.
José Germán Núñez Mori Página 227 de 237
227
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 Issues to be discussed with stakeholders
1. If the user gets into a space or state that they don’t 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 user’s 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].
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.
José Germán Núñez Mori Página 228 de 237
228
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 Issues to be discussed with stakeholders
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].
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.
José Germán Núñez Mori Página 229 de 237
229
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 Issues to be discussed with stakeholders
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 user’s sense of flow through the whole step-by-step process [7].
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. The task may branch like a flow chart, depending upon what information the user inputs, but the user doesn’t 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 doesn’t 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.
2.1. How many steps does each task require?
2.2. Which is the best way to present these steps to
the user?
3. 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).
3.1. Which serán las opciones de navegación hacia
atrás 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
José Germán Núñez Mori Página 230 de 237
230
Abort Operation: In such actions were a Go back option is provided a Cancel option may also be needed.
José Germán Núñez Mori Página 231 de 237
231
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:
- The application is very complex and many of its functions can be tuned to the user’s preference, and;
- the system will be used by people with different abilities, cultures and tastes, and
- not enough is known about the user’s preferences in order to assume defaults that will suit all users.
SOLUTION
Usability Configuration Guide
HCI Recommendation Issues to be discussed with stakeholders
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].
1.1. Will the application give the user the
opportunity to set up particular preferences (colors,
fonts, format, views, modos de selección 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. Devise a set of alternative “canned settings” that users can choose between, if they don’t like the default and don’t 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].
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?
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.
José Germán Núñez Mori Página 232 de 237
232
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 Issues to be discussed with stakeholders
1. The user should be able to arrange things in a way that works best for him, since he knows more about how he works than the artefact’s designer does. This way he can better remember 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 user’s space, only do automatic layout if the user specifically requests it. The artefact should maintain the user’s layout between users.
1.3 Will users be able to arrange their own layout?
1.2 Will the system allow this to be done for each user?
1.3. Which elements should users be able to arrange?
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.
José Germán Núñez Mori Página 233 de 237
233
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 artefact’s structure
SOLUTION
Usability Mechanism Configuration Guide
HCI Recommendation Issues to be discussed with stakeholders
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].
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?
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].
How will these actions be recorded?
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.
José Germán Núñez Mori Página 234 de 237
234
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 won’t take the time to use it; so, developers want to support both impatient and/or occasional users.
PROBLEM
Usability Mechanism Configuration Guide
HCI Recommendation Issues to be discussed with stakeholders
1. Create help on several levels including some (but not all) of the following list. Think of it as a continuum; each of these requires more effort from the user than the previous one [8]: o Captions and instructions directly on the page,
including patterns like Input Hints and Input Prompt. Be careful not to go overboard with these. If done with brevity, frequent users won’t mind them, but don’t use entire paragraphs of text – few users will read them.
o Tooltips. Use these to show brief, one-line descriptions of interface features that aren’t 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 whatever’s 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.
o 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.
o Longer help texts contained inside Closable Panels.
o 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.
o “Live” technical support, usually by email, web or telephone.
How complex are the tasks to be done by the
system?
1.2 .Will expert users or novice users use the system?
1.3. Which kind of tasks will probably require help to be
done?
1.4. Which kind of help procedure is best suited for such
tasks?
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.
José Germán Núñez Mori Página 235 de 237
235
• 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 Issues to be discussed with stakeholders
1. Provide a way for the user to “record” a sequence of actions [8]. The parts and syntax rules should be easy to learn, and should generate concise commands whose meaning is obvious [7]. The user should be able to give the macro the name of her choice. Let also her to review the action sequence somehow [8].
1.1 Which actions will be able to be aggregated?
Which will be the syntax used for such aggregation?
Remember to use a clear syntax easy to learn.
How will the aggregated be referred to?
How the macro content will be edited?
2. Provide a way to the user to “play back” the sequence at 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].
2.1. How the aggregated command will be play backed?
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.
José Germán Núñez Mori Página 236 de 237
236
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. O´Reilly, 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