Usabilidad en Metodologías Ágiles

237
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

Transcript of Usabilidad en Metodologías Ágiles

Page 1: 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

Page 2: Usabilidad en Metodologías Ágiles

Agradecimiento Agradezco a mis padres por apoyarme a seguir mis estudios

Page 3: Usabilidad en Metodologías Ágiles

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

Page 4: Usabilidad en Metodologías Ágiles

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

Page 5: Usabilidad en Metodologías Ágiles

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

Page 6: Usabilidad en Metodologías Ágiles

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

Page 7: Usabilidad en Metodologías Ágiles

Í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

Page 8: Usabilidad en Metodologías Ágiles

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

Page 9: Usabilidad en Metodologías Ágiles

Í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

Page 10: Usabilidad en Metodologías Ágiles

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:

Page 11: Usabilidad en Metodologías Ágiles

• 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

Page 12: Usabilidad en Metodologías Ágiles

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.

.

Page 13: Usabilidad en Metodologías Ágiles

La Usabilidad en Metodologías Ágiles

II. Metodologías Ágiles

Versión 3.0

Page 14: Usabilidad en 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 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

Page 15: Usabilidad en 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 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.

Page 16: Usabilidad en 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 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

Page 17: Usabilidad en 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 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

Page 18: Usabilidad en 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 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.

Page 19: Usabilidad en 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 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

Page 20: Usabilidad en 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 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.

Page 21: Usabilidad en 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 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:

Page 22: Usabilidad en 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 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

Page 23: Usabilidad en 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 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.

Page 24: Usabilidad en 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 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).

Page 25: Usabilidad en 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 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

Page 26: Usabilidad en 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 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

Page 27: Usabilidad en 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 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.

Page 28: Usabilidad en 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 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].

Page 29: Usabilidad en 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 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.

Page 30: Usabilidad en 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 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.

Page 31: Usabilidad en 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 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

Page 32: Usabilidad en 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 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>

Page 33: Usabilidad en 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 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.

Page 34: Usabilidad en 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 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.

Page 35: Usabilidad en 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 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

Page 36: Usabilidad en 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 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):

Page 37: Usabilidad en 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.

Page 38: Usabilidad en 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

Page 39: Usabilidad en 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 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.

Page 40: Usabilidad en 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 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.

Page 41: Usabilidad en 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.

Page 42: Usabilidad en 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 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.

Page 43: Usabilidad en Metodologías Ágiles

La Usabilidad en Metodologías Ágiles

III. Marco Ágil de trabajo

Versión 1.2

Page 44: Usabilidad en Metodologías Ágiles

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

Page 45: Usabilidad en Metodologías Ágiles

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

Page 46: Usabilidad en Metodologías Ágiles

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

Page 47: Usabilidad en Metodologías Ágiles

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

Page 48: Usabilidad en Metodologías Ágiles

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

Page 49: Usabilidad en Metodologías Ágiles

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:

Page 50: Usabilidad en Metodologías Ágiles

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

Page 51: Usabilidad en Metodologías Ágiles

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

Page 52: Usabilidad en Metodologías Ágiles

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,

Page 53: Usabilidad en Metodologías Ágiles

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

Page 54: Usabilidad en Metodologías Ágiles

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.

Page 55: Usabilidad en Metodologías Ágiles

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

Page 56: Usabilidad en Metodologías Ágiles

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

Page 57: Usabilidad en Metodologías Ágiles

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:

Page 58: Usabilidad en Metodologías Ágiles

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:

Page 59: Usabilidad en Metodologías Ágiles

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

Page 60: Usabilidad en Metodologías Ágiles

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.

Page 61: Usabilidad en Metodologías Ágiles

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.

Page 62: Usabilidad en Metodologías Ágiles

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

Page 63: Usabilidad en Metodologías Ágiles

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.

Page 64: Usabilidad en Metodologías Ágiles

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

Page 65: Usabilidad en Metodologías Ágiles

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

Page 66: Usabilidad en Metodologías Ágiles

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.

Page 67: Usabilidad en Metodologías Ágiles

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.

Page 68: Usabilidad en Metodologías Ágiles

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:

Page 69: Usabilidad en Metodologías Ágiles

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

Page 70: Usabilidad en Metodologías Ágiles

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

Page 71: Usabilidad en Metodologías Ágiles

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.

Page 72: Usabilidad en Metodologías Ágiles

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

Page 73: Usabilidad en Metodologías Ágiles

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

Page 74: Usabilidad en Metodologías Ágiles

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.

Page 75: Usabilidad en Metodologías Ágiles

La Usabilidad en Metodologías Ágiles

IV. Fase de Inicio del Marco Ágil de Trabajo

Versión 1.1

Page 76: Usabilidad en Metodologías Ágiles

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

Page 77: Usabilidad en Metodologías Ágiles

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.

Page 78: Usabilidad en Metodologías Ágiles

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.

Page 79: Usabilidad en Metodologías Ágiles

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.

Page 80: Usabilidad en Metodologías Ágiles

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

Page 81: Usabilidad en Metodologías Ágiles

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)

Page 82: Usabilidad en Metodologías Ágiles

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

Page 83: Usabilidad en Metodologías Ágiles

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.

Page 84: Usabilidad en Metodologías Ágiles

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

Page 85: Usabilidad en Metodologías Ágiles

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.

Page 86: Usabilidad en Metodologías Ágiles

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

Page 87: Usabilidad en Metodologías Ágiles

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.

Page 88: Usabilidad en Metodologías Ágiles

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)”.

Page 89: Usabilidad en Metodologías Ágiles

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

Page 90: Usabilidad en Metodologías Ágiles

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.

Page 91: Usabilidad en Metodologías Ágiles

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

Page 92: Usabilidad en Metodologías Ágiles

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

Page 93: Usabilidad en Metodologías Ágiles

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

Page 94: Usabilidad en Metodologías Ágiles

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

Page 95: Usabilidad en Metodologías Ágiles

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

Page 96: Usabilidad en Metodologías Ágiles

La Usabilidad en Metodologías Ágiles

V. Fase de Elaboración del Marco Ágil de Trabajo

Versión 1.0

Page 97: Usabilidad en Metodologías Ágiles

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

Page 98: Usabilidad en Metodologías Ágiles

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

Page 99: Usabilidad en Metodologías Ágiles

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.

Page 100: Usabilidad en Metodologías Ágiles

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.

Page 101: Usabilidad en Metodologías Ágiles

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

Page 102: Usabilidad en Metodologías Ágiles

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:

Page 103: Usabilidad en Metodologías Ágiles

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.

Page 104: Usabilidad en Metodologías Ágiles

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

Page 105: Usabilidad en Metodologías Ágiles

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

Page 106: Usabilidad en Metodologías Ágiles

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.

Page 107: Usabilidad en Metodologías Ágiles

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.

Page 108: Usabilidad en Metodologías Ágiles

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

Page 109: Usabilidad en Metodologías Ágiles

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

Page 110: Usabilidad en Metodologías Ágiles

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:

Page 111: Usabilidad en Metodologías Ágiles

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.

Page 112: Usabilidad en Metodologías Ágiles

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

Page 113: Usabilidad en Metodologías Ágiles

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

Page 114: Usabilidad en Metodologías Ágiles

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

Page 115: Usabilidad en Metodologías Ágiles

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

Page 116: Usabilidad en Metodologías Ágiles

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

Page 117: Usabilidad en Metodologías Ágiles

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

Page 118: Usabilidad en Metodologías Ágiles

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

Page 119: Usabilidad en Metodologías Ágiles

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

Page 120: Usabilidad en Metodologías Ágiles

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:

Page 121: Usabilidad en Metodologías Ágiles

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

Page 122: Usabilidad en Metodologías Ágiles

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:

Page 123: Usabilidad en Metodologías Ágiles

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

Page 124: Usabilidad en Metodologías Ágiles

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:

Page 125: Usabilidad en Metodologías Ágiles

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

Page 126: Usabilidad en Metodologías Ágiles

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.

Page 127: Usabilidad en Metodologías Ágiles

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

Page 128: Usabilidad en Metodologías Ágiles

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

Page 129: Usabilidad en Metodologías Ágiles

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

Page 130: Usabilidad en Metodologías Ágiles

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

Page 131: Usabilidad en Metodologías Ágiles

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:

Page 132: Usabilidad en Metodologías Ágiles

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

Page 133: Usabilidad en Metodologías Ágiles

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

Page 134: Usabilidad en Metodologías Ágiles

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

Page 135: Usabilidad en Metodologías Ágiles

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.

Page 136: Usabilidad en Metodologías Ágiles

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

Page 137: Usabilidad en Metodologías Ágiles

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

Page 138: Usabilidad en Metodologías Ágiles

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

Page 139: Usabilidad en Metodologías Ágiles

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

Page 140: Usabilidad en Metodologías Ágiles

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

Page 141: Usabilidad en Metodologías Ágiles

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

Page 142: Usabilidad en Metodologías Ágiles

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:

Page 143: Usabilidad en Metodologías Ágiles

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.

Page 144: Usabilidad en Metodologías Ágiles

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

Page 145: Usabilidad en Metodologías Ágiles

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

Page 146: Usabilidad en Metodologías Ágiles

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:

Page 147: Usabilidad en Metodologías Ágiles

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

Page 148: Usabilidad en Metodologías Ágiles

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á

Page 149: Usabilidad en Metodologías Ágiles

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:

Page 150: Usabilidad en Metodologías Ágiles

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

Page 151: Usabilidad en Metodologías Ágiles

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

Page 152: Usabilidad en Metodologías Ágiles

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.

Page 153: Usabilidad en Metodologías Ágiles

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”

Page 154: Usabilidad en Metodologías Ágiles

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

Page 155: Usabilidad en Metodologías Ágiles

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

Page 156: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 155 de 237

VIII. Anexos

Page 157: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 156 de 237

Anexo 01: Especificación Patrón de Usabilidad Warning

Page 158: Usabilidad en Metodologías Ágiles

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

Page 159: Usabilidad en Metodologías Ágiles

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

Page 160: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 159 de 237

Figure 1: Warning. Use Case Model

Page 161: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 160 de 237

Figure 2: Warning. System Responsibility Clusters

Page 162: Usabilidad en Metodologías Ágiles

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)

Page 163: Usabilidad en Metodologías Ágiles

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

Page 164: Usabilidad en Metodologías Ágiles

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

Page 165: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 164 de 237

Figure 3: Warning. Usability-enabling design pattern. Class diagram

Page 166: Usabilidad en Metodologías Ágiles

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)

Page 167: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 166 de 237

Anexo 02: Especificación Patrón de Usabilidad System Status Feedback

Page 168: Usabilidad en Metodologías Ágiles

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

Page 169: Usabilidad en Metodologías Ágiles

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.

Page 170: Usabilidad en Metodologías Ágiles

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

Page 171: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 170 de 237

Figure 5: System Status Feedback. Use Case Model

Page 172: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 171 de 237

Figure 6: System Status Feedback. System Responsibility Clusters

Page 173: Usabilidad en Metodologías Ágiles

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.

Page 174: Usabilidad en Metodologías Ágiles

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

Page 175: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 174 de 237

Figure 7: System Status Feedback. Usability-enabling design pattern. Class diagram

Page 176: Usabilidad en Metodologías Ágiles

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)

Page 177: Usabilidad en Metodologías Ágiles

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)

Page 178: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 177 de 237

Anexo 03: Especificación Patrón de Usabilidad Global Undo

Page 179: Usabilidad en Metodologías Ágiles

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.

Page 180: Usabilidad en Metodologías Ágiles

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)

Page 181: Usabilidad en Metodologías Ágiles

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

Page 182: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 181 de 237

Figure 10: Undo. Use Case Model

Page 183: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 182 de 237

Figure 11: Undo. System Responsibility Clusters

Page 184: Usabilidad en Metodologías Ágiles

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.

Page 185: Usabilidad en Metodologías Ágiles

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

Page 186: Usabilidad en Metodologías Ágiles

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

Page 187: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 186 de 237

Figure 12: Undo. Usability-enabling design pattern. Class diagram

Page 188: Usabilidad en Metodologías Ágiles

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)

Page 189: Usabilidad en Metodologías Ágiles

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)

Page 190: Usabilidad en Metodologías Ágiles

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)

Page 191: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 190 de 237

Anexo 04: Especificación Patrón de Usabilidad Abort

Page 192: Usabilidad en Metodologías Ágiles

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.

Page 193: Usabilidad en Metodologías Ágiles

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.

Page 194: Usabilidad en Metodologías Ágiles

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)

Page 195: Usabilidad en Metodologías Ágiles

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

Page 196: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 195 de 237

Figure 16: Abort. Use Case Model

Page 197: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 196 de 237

Figure 17: Abort. System Responsibility Clusters

Page 198: Usabilidad en Metodologías Ágiles

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

Page 199: Usabilidad en Metodologías Ágiles

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

Page 200: Usabilidad en Metodologías Ágiles

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

Page 201: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 200 de 237

Figure 18: Abort. Usability-enabling design pattern. Class diagram

Page 202: Usabilidad en Metodologías Ágiles

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)

Page 203: Usabilidad en Metodologías Ágiles

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)

Page 204: Usabilidad en Metodologías Ágiles

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)

Page 205: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 204 de 237

Anexo 05: Especificación Patrón de Usabilidad System Progress Feedback

Page 206: Usabilidad en Metodologías Ágiles

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]

Page 207: Usabilidad en Metodologías Ágiles

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

Page 208: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 207 de 237

207

Figure 22: System Progress Feedback. Use Case Model

Page 209: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 208 de 237

208

Figure 23: System Progress Feedback. System Responsibility Clusters

Page 210: Usabilidad en Metodologías Ágiles

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.

Page 211: Usabilidad en Metodologías Ágiles

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

Page 212: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 211 de 237

211

Figure 24: System Progress Feedback. Usability-enabling design pattern. Class diagram

Page 213: Usabilidad en Metodologías Ágiles

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)

Page 214: Usabilidad en Metodologías Ágiles

José Germán Núñez Mori Página 213 de 237

213

Anexo 06: Patrones de Usabilidad en la Elicitación

Page 215: Usabilidad en Metodologías Ágiles

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

[email protected]

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

Page 216: Usabilidad en Metodologías Ágiles

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

Page 217: Usabilidad en Metodologías Ágiles

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

Page 218: Usabilidad en Metodologías Ágiles

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.

Page 219: Usabilidad en Metodologías Ágiles

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

Page 220: Usabilidad en Metodologías Ágiles

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

Page 221: Usabilidad en Metodologías Ágiles

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

Page 222: Usabilidad en Metodologías Ágiles

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

Page 223: Usabilidad en Metodologías Ágiles

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?

Page 224: Usabilidad en Metodologías Ágiles

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.

Page 225: Usabilidad en Metodologías Ágiles

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.

Page 226: Usabilidad en Metodologías Ágiles

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.

Page 227: Usabilidad en Metodologías Ágiles

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.

Page 228: Usabilidad en Metodologías Ágiles

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.

Page 229: Usabilidad en Metodologías Ágiles

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.

Page 230: Usabilidad en Metodologías Ágiles

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

Page 231: Usabilidad en Metodologías Ágiles

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.

Page 232: Usabilidad en Metodologías Ágiles

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.

Page 233: Usabilidad en Metodologías Ágiles

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.

Page 234: Usabilidad en Metodologías Ágiles

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.

Page 235: Usabilidad en Metodologías Ágiles

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.

Page 236: Usabilidad en Metodologías Ágiles

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.

Page 237: Usabilidad en Metodologías Ágiles

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