Tesis MarcoAgilTrabajo

UNIVERSIDAD POLITECNICA DE MADRID
FACULTAD DE INFORMATICA
TESIS DE MASTER EN
INGENIERIA DEL SOFTWARE
USABILIDAD EN METODOLOGAS GILES
Autor: JOSE GERMN NEZ MORI

Dirigida por: ANA MORENO
Noviembre, 2010
Agradecimiento
Agradezco a mis padres por
apoyarme a seguir mis estudios
Contenido
I.
Introduccin
II.
Metodologas giles
1.
Introduccin
14
3.
Manifiesto gil
15
4.
Principales metodologas giles
16
4.1
16
4.2
4.3
4.4
4.5
4.6
Programacin Extrema (XP)

4.1.1
Principios bsicos .................................................................................. 17
4.1.2
Proceso de desarrollo ............................................................................ 18
Proceso Unificado gil (AUP)
20
4.2.1
Descripcin............................................................................................ 20
4.2.2
Principio bsicos ................................................................................... 20
4.2.3
Agile model driven development (AMDD)
23
4.3.1
Descripcin............................................................................................ 23
4.3.2
4.3.3
Scrum
25
4.4.1
Descripcin............................................................................................ 25
4.4.2
4.4.3
Dynamic Systems Development Method (DSDM)
27
4.5.1
Descripcin............................................................................................ 28
4.5.2
4.5.3
Feature Driven Development (FDD)
31
4.6.1
Descripcin............................................................................................ 31
4.6.2
4.6.3
Comparativa entre metodologas giles
34
5.1
35
5.2
Criterios de comparacin
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
Conclusiones de la comparativa
40
5.3
Adopcin de metodologas
40
III.
Marco gil de trabajo
42
1.
Introduccin
44
2.
Planteamiento metodolgico
44
3.
Estructura Metodolgica
45
3.1
47
Fases del marco gil de trabajo

3.1.1
Inicio (Inception) ................................................................................... 47
3.1.2
Historias de Usuarios ............................................................................ 48
3.1.3
Pruebas de Aceptacin .......................................................................... 49
3.1.4
Product Backlog .................................................................................... 50
3.1.5
Elaboracin............................................................................................ 51
3.1.6
Prototipo de la arquitectura del sistema ................................................ 52
3.1.7
Estndar MDA (Model Driven Architecture)........................................ 54
3.1.7.1.1.1Usando MDA .................................................................................... 56

3.1.7.1.1.2Mapas de Transformacin MDA....................................................... 57
3.1.7.1.1.3Transformaciones de modelos MDA ................................................ 59
3.1.7.1.2AndroMDA .......................................................................................... 61
3.1.7.1.2.1MDA en la generacin de cdigo de AndroMDA ............................ 61
3.1.7.1.2.2Arquitectura del marco gil de trabajo segn AndroMDA ............... 63
3.1.7.1.2.3Modelado de AndroMDA y el prototipo de Arquitectura del marco
gil de trabajo ..................................................................................................... 65
3.1.7.1.2.4Herramientas y tecnologas en el ciclo de generacin AndroMDA .. 69
3.1.7.2 Plan de ejecucin de la primera iteracin de construccin.................... 70
3.1.8
Fase de Desarrollo ................................................................................. 73
IV.
Fase de Inicio del Marco gil de Trabajo
74
1.
Introduccin
76
2.
Desarrollo de la fase de Inicio
77
2.1
Product Backlog
77
2.2
Historias de usuarios
77
2.3
Pruebas de aceptacin
87
V.
Fase de Elaboracin del Marco gil de Trabajo
95
1.
Introduccin
97
2.
Desarrollo de la fase de Elaboracin
97
2.1
Planificacin de la Primera Iteracin
97
2.2
Prototipo de Arquitectura
2.2.1
101
Tarea de Implementacin de la Funcionalidad.................................... 101
2.2.1.1 Diseo de la capa de datos .................................................................. 102
2.2.1.2 Diseo de la capa de negocio .............................................................. 103

2.2.1.3 Diseo de la capa de presentacin....................................................... 104
2.2.1.4 Resultado de Tarea .............................................................................. 106
2.2.2
Integracin del patrn de usabilidad Warning..................................... 109
2.2.2.1 Integracin del patrn de usabilidad Warning en la capa de presentacin

y capa de negocio ............................................................................................. 111
2.2.2.2 Flujo de trabajo segn el patrn de usabilidad Warning ..................... 112
2.2.2.3 Resultados de la Integracin del patrn de usabilidad Warning ......... 113
2.2.3
Integracin del patrn de usabilidad System Status Feedback ............ 115
2.2.3.1 Integracin del patrn de usabilidad SSF a la capa de presentacin y

capa de negocio ................................................................................................ 117
2.2.3.2 Flujo de trabajo segn el patrn de usabilidad SSF ............................ 118
2.2.3.3 Resultados de la integracin del patrn de usabilidad SSF ................. 119
2.2.4
Integracin del patrn de usabilidad Global Undo .............................. 121
2.2.4.1 Integracin del patrn de usabilidad GU a la capa de presentacin y capa

de negocio122
2.2.4.2 Flujo de trabajo segn el patrn de usabilidad GU ............................. 125
2.2.4.3 Resultados de la integracin del patrn de usabilidad GU .................. 126
2.2.5
Integracin del patrn de usabilidad Abort Operation ........................ 127
2.2.5.1 Integracin del patrn de usabilidad AO a la capa de presentacin y capa

de negocio129
2.2.5.2 Flujo de trabajo segn el patrn de usabilidad AO ............................. 132
2.2.5.3 Resultados de la integracin del patrn de usabilidad AO .................. 133
2.2.6
Integracin del patrn de usabilidad System Progress Feedback ........ 135
2.2.6.1 Integracin del patrn de usabilidad SPF a la capa de presentacin y

capa de negocio ................................................................................................ 136
2.2.6.2 Flujo de trabajo segn el patrn de usabilidad SPF ............................ 139
2.2.6.3 Resultados de la integracin del patrn de usabilidad SPF ................. 141
2.2.7
Integracin del patrn de usabilidad Abort Command........................ 143
2.2.7.1 Integracin del patrn de usabilidad AC a la capa de presentacin y capa

de negocio. ....................................................................................................... 145
2.2.7.2 Flujo de trabajo segn el patrn de usabilidad AC.............................. 147
2.2.7.3 Resultados de la integracin del patrn de usabilidad SPF ................. 148
2.3
VI.
Planificacin tras la primera iteracin
Conclusiones
151
152
VII. Referencias Bibliogrficas
153
VIII. Anexos
155
Anexo 01: Especificacin Patrn de Usabilidad Warning
156
Anexo 02: Especificacin Patrn de Usabilidad System Status Feedback
166
Anexo 03: Especificacin Patrn de Usabilidad Global Undo
177
Anexo 04: Especificacin Patrn de Usabilidad Abort
190
Anexo 05: Especificacin Patrn de Usabilidad System Progress Feedback
204
Anexo 06: Patrones de Usabilidad en la Elicitacin
213
ndice de Figuras
Figura 1: Iteraciones AUP .....................................................................................................................23
Figura 2: Ciclo de vida de un proyecto AMDD .....................................................................................24
Figura 3: Ciclo de vida de un proyecto AMDD .....................................................................................29
Figura 4: Ciclo de vida de un proyecto FDD. .......................................................................................33
Figura 5: Ciclo de vida AUP .................................................................................................................45
Figura 6: Ciclo de vida del marco gil de trabajo ................................................................................46
Figura 7: Hito de la fase de Inicio. ........................................................................................................48
Figura 8: Formato de Historias de usuarios segn XP .........................................................................48
Figura 9: Formato de Historias de usuarios segn el marco gil. ........................................................49
Figura 10: Formato de Pruebas de Aceptacin. ....................................................................................50
Figura 11: Formato del Product Backlog ..............................................................................................51
Figura 12 : Hito de la fase de Elaboracin ...........................................................................................52
Figura 13: Trazabilidad de Modelos MDA ............................................................................................57
Figura 14: Transformacin de metamodelos bajo MDA. ......................................................................58
Figura 15: Marcado de un modelo bajo MDA .......................................................................................58
Figura 16: Patrones de transformacin en los modelos MDA...............................................................59
Figura 17: Ciclo AndroMDA de generacin de cdigo .........................................................................62
Figura 18: Arquitectura de Aplicacin base del marco gil de trabajo ................................................63
Figura 19: Estructura de Aplicacin empresarial AndroMDA..............................................................64
Figura 20: Diagrama de Actividad en AndroMDA ................................................................................66
Figura 21: Componente controlador en AndroMDA .............................................................................67
Figura 22: Casos de Uso AndroMDA ....................................................................................................67
Figura 23: Modelado de servicios en AndroMDA .................................................................................68
Figura 24: Modelado de entidades de datos en AndroMDA..................................................................68
Figura 25: Dependencia entre componentes de capa en AndroMDA ....................................................69
Figura 26: Herramienta de gestin Sprintometer ..................................................................................71
Figura 27: Seccin de registro de Sprint en Sprintometer .....................................................................72
Figura 28. Seccin de control de avance de tareas en el Sprint bajo Sprintometer ..............................72
Figura 29: Vista de la planificacin en das ..........................................................................................98
Figura 30: Sprint y tareas de la primera Iteracin en Spritometer ......................................................99
Figura 31: Modelo de entidades de la capa de datos ..........................................................................103
Figura 32: Modelado de la capa de negocio .......................................................................................103
Figura 33: Dependencias de servicios con las entidades de datos ......................................................104
Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas ...................................104
Figura 35: Modelado de la clase controladora ...................................................................................105
Figura 36: Diagrama de actividad asociado a la capa de presentacin .............................................106
Figura 37: Bsqueda de personas Pgina principal de la aplicacin ..............................................107
Figura 38: Relacionar Personas Criterio de seleccin de personas a relacionar ............................107
Figura 39: Relacionar Personas Adicin de relaciones a la persona seleccionada.........................108
Figura 40 Diagrama de clases de la especificacin del patrn de usabilidad Warning...................110
Figura 41: Diagrama de secuencia de la especificacin del patrn de usabilidad Warning ..............110
Figura 42: Modelado de la clase controladora con el Patrn de usabilidad Warning .......................111
Figura 43: Confirmacin de adicin de nueva relacin segn el patrn de usabilidad Warning ......114
Figura 44: Resultados tras la confirmacin de la adicin de una nueva relacin ..............................114
Figura 45: Diagrama de clases de la especificacin del patrn de usabilidad SSF............................116
Figura 46: Diagrama de secuencia de la especificacin del patrn de usabilidad SSF ......................116
Figura 47: Integracin del patrn de usabilidad SSF en el diseo de la funcionalidad Relacionar
Personas .......................................................................................................................................117
Figura 48: Resultados tras la adicin satisfactoria de una nueva relacin ........................................120
Figura 49: Resultados de error tras la adicin de una nueva relacin ...............................................120
Figura 50: Diagrama de clases de la especificacin del patrn de usabilidad GU ............................122
Figura 51: Diagrama de secuencias de la especificacin del patrn de usabilidad GU .....................122
Figura 52: Integracin del patrn de usabilidad GU en la capa de negocio y capa de diseo ...........123
Figura 53: Integracin del patrn de usabilidad GU en el diagrama de actividades de la pgina de
Adicin de relaciones ...................................................................................................................124
Figura 54: Adicin de nuevas relaciones considerando el patrn GU ................................................126

Figura 55: La adicin de relaciones tras en el evento de deshacer (Undo) ........................................127
Figura 56: Diagrama de clases de la especificacin del patrn de usabilidad AO .............................128
Figura 57: Diagrama de secuencia de la especificacin del patrn de usabilidad AO .......................129
Figura 58: Integracin del patrn de usabilidad AO en la capa de negocio y capa de presentacin .130
Figura 59: Integracin del patrn de usabilidad AO en el diagrama de actividades de la pgina de
Adicin de relaciones ...................................................................................................................131
Figura 60: Adicin de nuevas relaciones considerando el patrn AO ................................................133
Figura 61: Home de la aplicacin tras el evento Cancelar .................................................................134
Figura 62: Consulta de relaciones tras el evento de cancelar .............................................................134
Figura 63: Diagrama de clases de la especificacin del patrn de usabilidad SPF ...........................135
Figura 64: Diagrama de secuencia de la especificacin del patrn de usabilidad SPF .....................136
Figura 65: Integracin del patrn de usabilidad SPF en la capa de negocio y capa de diseo..........137
Figura 66: Integracin del patrn de usabilidad SPF en el diagrama de actividades de la pgina Web
de Adicin de relaciones ..............................................................................................................138
Figura 67: Esquema de trabajo del objeto XMLHttpRequest ..............................................................140
Figura 68: Adicin de distintas relaciones a la persona seleccionada................................................142
Figura 69: Barra de progreso mientras se aplica la operacin de Undo a las relaciones adicionadas
......................................................................................................................................................142
Figura 70: Diagrama de secuencia de la especificacin del patrn de usabilidad AC .......................144
Figura 71: Integracin del patrn de usabilidad AC en la capa de negocio y capa de diseo ...........145
Figura 72: Integracin del patrn de usabilidad AC en el diagrama de actividades de la pgina Web
de Adicin de relaciones ..............................................................................................................146
Figura 73: Adicin de distintas relaciones a la persona seleccionada................................................149
Figura 74: Barra de progreso con opcin de cancelar, ante la operativa de Undo de las relaciones
adicionadas ..................................................................................................................................149
Figura 75: Tras el evento de cancelar el comando de Undo de relaciones .........................................150
Figura 76: Carga de trabajo a lo largo de la planificacin ................................................................151
ndice de Tablas
Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologas giles. .....................36
Tabla 2: Estado actual de las metodologas giles ...............................................................................37
Tabla 3: Comparativa de calidad en las metodologas giles ..............................................................38
Tabla 4: Herramientas de libre distribucin para metodologas giles. ...............................................39
Tabla 5 : Detalle de secciones del Sprintometer ....................................................................................72
Tabla 6: Product backlog.......................................................................................................................77
Tabla 7: Historia de usuario Relacionar personas .............................................................................79
Tabla 8: Historia de usuario Gestionar fusin de personas ...............................................................81
Tabla 9: Historia de usuario Buscar personas fusionadas .................................................................84
Tabla 10: Historia de usuario Recuperar datos entidad financiera ...................................................85
Tabla 11: Historia de usuario Gestionar Situacin familiar de la persona........................................87
Tabla 12 : Prueba de aceptacin Relacionar personas ......................................................................88
Tabla 13: Prueba de aceptacin Gestionar fusin de personas..........................................................90
Tabla 14: Prueba de aceptacin Buscar personas fusionadas ...........................................................91
Tabla 15: Prueba de aceptacin Recuperar datos entidad financiera................................................93
Tabla 16: Prueba de aceptacin Gestionar situacin familiar ...........................................................94
Tabla 17: Product backlog.....................................................................................................................98
Tabla 18: Planificacin del Sprint Relacionar Personas ..................................................................100
Tabla 19: Planificacin inicial de la tarea de implementacin de la funcionalidad ...........................102
Tabla 20: Actualizacin de la planificacin de la tarea de implementacin de la funcionalidad .......108
Tabla 21: Planificacin inicial de la tarea de integracin del patrn de usabilidad Warning ...........109
Tabla 22: Correspondencia de componentes del patrn de usabilidad Warning y los componentes de la
funcionalidad................................................................................................................................112
Tabla 23- Planificacin actualizada de la tarea de integracin del patrn de usabilidad Warning ...115
Tabla 24: Planificacin inicial de la tarea de integracin del patrn de usabilidad SSF ...................115
Tabla 25: Correspondencia de componentes del patrn de usabilidad SSF y los componentes de la
funcionalidad................................................................................................................................118
Tabla 26: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SSF...........121
Tabla 27: Planificacin inicial de la tarea de integracin del patrn de usabilidad GU....................121
Tabla 28: Correspondencia de componentes del patrn de usabilidad GU y los componentes de la
funcionalidad................................................................................................................................124
Tabla 29: Planificacin actualizada de la tarea de integracin del patrn de usabilidad GU ..........127
Tabla 30: Planificacin inicial de la tarea de integracin del patrn de usabilidad AO ....................129
Tabla 31: Correspondencia de componentes del patrn de usabilidad AO y los componentes de la
integracin ...................................................................................................................................131
Tabla 32: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AO ............135
Tabla 33: Planificacin inicial de la tarea de integracin del patrn de usabilidad SPF...................136
Tabla 34: Correspondencia de componentes del patrn de usabilidad SPF y los componentes de la
Integracin ...................................................................................................................................139
Tabla 35: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SPF ..........143
Tabla 36: Planificacin inicial de tarea de integracin del patrn de usabilidad AC ........................144
Tabla 37: Correspondencia de componentes del patrn de usabilidad AC y los componentes de la
integracin ...................................................................................................................................147
Tabla 38: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AC ............150
I. Introduccin
La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y
ser atractivo para el usuario, en condiciones especficas de uso.
Es considerada la usabilidad tambin, como la medida en que un producto puede ser usado
por usuarios especficos, para lograr los objetivos especificados con efectividad, eficiencia y
satisfaccin en un contexto especfico de uso.
En el campo de la Ingeniera de software, hablar de usabilidad hoy en da, es relacionar con

la interfaz de usuario, por lo tanto, la usabilidad afectara a la UI y no a la funcionalidad
bsica del sistema. De acuerdo a esto, la usabilidad debe ser tratada al final del desarrollo del
sistema, como un atributo ms de calidad y que no necesita demasiadas pruebas (Hiptesis de
la separacin).
En contraposicin, a la idea que se tiene hoy en da de la usabilidad, existen investigaciones

en el campo de la ingeniera de Software, donde, se describe que las Isuues de usabilidad son
limitaciones estticas y dinmicas a los componentes de software y que la separacin de la
interfaz de usuario de la funcionalidad bsica, no garantiza que se entregue un producto
usable al cliente final.
Confirmada la relacin entre diseo de software y usabilidad, la revisin del costo para
alcanzar un nivel aceptable de usabilidad debera ser mayor que lo planteado por la hiptesis
de separacin, por lo tanto, la facilidad de uso debe ser tratada con anterioridad al proceso de
desarrollo, con el fin de evaluar su impacto en el diseo tan pronto como sea posible.
Esto es una estrategia ya aplicada con anterioridad a algunos de los atributos de calidad como
por ejemplo: fiabilidad, disponibilidad y mantenibilidad, donde, algunos autores propusieron
en su momentos, tcnicas para hacer frente a estos atributos en tiempo de diseo
arquitectnico.
La literatura HCI (Human Computer Interaction), analiza el impacto que tiene la usabilidad
en el desarrollo del Software, con lo cual, presenta recomendaciones, considerando tres
diferentes categoras de impacto:
Usabilidad con impacto en la UI, esto afecta a la presentacin del sistema, como puede
ser botones, color de fondo, etc. Para dar solucin a esto, solo se realizan cambios en el
diseo detallado de la UI y no en el Funcionalidad bsica del sistema.
Usabilidad con impacto en el proceso desarrollo, esto afecta al proceso de desarrollo,

donde, estas recomendaciones proponen directrices para alentar la interaccin usuariosistema, el cual debe tener un sitio natural e intuitivo para el usuario.
Si se desea hacer uso de estas recomendaciones, es necesario modificar el proceso de
desarrollo, ya que debe ser centrado en el usuario, implicando de esta manera, tener
tcnicas mas potentes para la obtencin de requisitos, que probablemente se tenga que
apoyar en otras disciplinas como HCI, con el objetivo de poder hacer participe al usuario
en la construccin del software
Usabilidad con impacto en el diseo, estas son recomendaciones que implican actividades
de construccin de funcionalidades en el Software, para mejorar la actividad usuario
sistema, por ejemplo funcionalidades como: Cancelar una tarea en curso.
Segn las recomendaciones dadas por la literatura HCI, hoy en da se han realizado estudios
enfocados, ms que todo en el impacto de la usabilidad en el diseo (Ver anexos), buscando
as, mecanismos para tratar la usabilidad en esta etapa.
Todas estas recomendaciones y estudios, que asocian la usabilidad en el proceso de desarrollo

de software, hoy en da, se vienen utilizando en proyecto de desarrollo de software
tradicional, es decir, proyectos que siguen lineamientos de metodologas de desarrollo
tradicional.
Es de acuerdo a esta premisa, que el presente trabajo tiene como objetivo principal, la
inclusin de los principios de usabilidad, en proyectos Software, que se desarrollen en base a
metodologas giles.
Para cumplir con este objetivo, el presente trabajo de fin de Master, se basar en estudios
previos, donde se detallan mecanismo para considerar la usabilidad antes del proceso de
desarrollo, es decir, en las etapas, de toma de requisitos y de diseo (ver anexos).
Estos mecanismos, debern de ser tomados en cuenta, en los planteamientos de la

metodologa o metodologas giles seleccionadas, para que as, el ciclo del vida del software
a desarrollar en base a estos lineamientos giles, tome en cuenta los principios de usabilidad.
El presente trabajo, tendr la siguiente estructura, para abordar el objetivo principal del
mismo:
Captulo I (Metodologas giles), se detallar los planteamientos de las metodologas

giles mas conocidas hoy en da, buscando con esto, seleccionar la metodologa o
metodologas, que nos permitan incluir los principios de usabilidad.
Capitulo II (Marco gil de trabajo), en base a la metodologa o metodologas

seleccionadas, se crear un marco de trabajo gil, donde se detalle los lineamientos para
el ciclo de vida del software a desarrollar, donde tambin, estos lineamientos tengan en
cuenta los principios de usabilidad.
Ya en capitulo III (Fase de inicio del marco gil de trabajo) y IV (Fase de elaboracin
del marco gil de trabajo), es donde, se describir el desarrollo del sistema, siguiendo los
lineamientos del marco gil de trabajo.
La Usabilidad en Metodologas giles
II. Metodologas giles
Versin 3.0

Metodologas giles
Junio 2009
Version 3.0
Historia del documento

FECHA
VERSION
DESCRIPCIN
AUTOR
08/05/2009
1.0
Metodologas giles
Jos Germn Nez Mori
25/05/2009
2.0
Metodologas giles
Jos Germn Nez Mori
15/06/2009
3.0
Metodologas giles
Jos Germn Nez Mori
Jos Germn Nez Mori
Pgina 13 de 237

Metodologas giles
Junio 2009
Version 3.0
Metodologas giles
1.
Introduccin
A principios de las dcada del 90 surgi un enfoque que era revolucionario para su momento ya
que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr
obtener software de alta calidad en un tiempo y costo determinado. El enfoque fue planteado por
primera vez en 1991 por James Martin [MART91], que consista en un entorno de desarrollo
altamente productivo, en el que participaban grupos pequeos de programadores utilizando
herramientas que generaban cdigo de forma automtica tomando como entrada sintaxis de alto
nivel. En general se considera que este fue uno de los primeros hitos en pos de la agilidad en
los procesos de desarrollo [SMHR04].
Tras pasar cierto tiempo despus de este primer enfoque de agilidad en los procesos de
desarrollo, en febrero del 2001 se reunieron miembros prominentes de la comunidad Software y
adoptaron el nombre de metodologas giles, poco despus formando la Alianza gil, que es
una organizacin sin fines de lucro, que promueve el desarrollo gil de aplicaciones [CLEP09].
Las metodologas giles nacen como una reaccin contra los mtodos de peso pesado, muy
estructurados y estrictos, extrados del modelo de desarrollo en cascada. El proceso originado
del uso del modelo en cascada era visto como burocrtico, lento degradante e inconsistente con
las formas de desarrollo de software que realmente realizaban un trabajo eficiente [WDAS09].
2.
Descripcin
Las metodologas giles son un marco conceptual de la Ingeniera de Software que promueve
iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto, considerando una
iteracin como una unidad de tiempo que dura de uno a cuatro semanas. Donde cada iteracin
del ciclo de vida incluye planificacin anlisis, diseo, codificacin, revisin y documentacin
[WDAS09]. Una iteracin no debe agregar demasiada funcionalidad para justificar el
lanzamiento del producto al mercado, pero la meta es tener un producto parcial o una parte del
todo al final de cada iteracin.
Las metodologas giles buscan lo siguiente [WDAS09]:

Evitar los tortuosos y burocrticos caminos de las metodologas tradicionales, enfocndose
en la gente y los resultados.
Jos Germn Nez Mori
Pgina 14 de 237

Metodologas giles
Junio 2009
Version 3.0
Minimizar los riesgos, desarrollando software en cortos lapsos de tiempo (iteraciones).

Enfatizar las comunicaciones cara a cara en vez de la documentacin.
Enfatizar que el software funcional es la primera medida del progreso.
Las metodologas giles platean centrarse en otras dimensiones, como por ejemplo el factor
humano o el producto software, siendo esto su principal filosofa. Dando mayor valor al
individuo, a la colaboracin con el cliente y al desarrollo incremental del software con
iteraciones muy cortas. Este enfoque esta mostrando su efectividad en proyectos con requisitos
muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero
manteniendo una alta calidad.
3.
Manifiesto gil
En esta seccin se detalla los principios bsicos del Manifiesto gil, inspirando en base a lo
expuesto en: Manifiesto for Agile Software Development [MFAS01].
Como consecuencia de la reunin donde se acuo el trmino Metodologas giles (febrero
2001), se establecieron los principios de estas metodologas agrupndoles en cuatro postulados,
quedando esta agrupacin denominada como Manifiesto gil. A continuacin se mencionan los
cuatro postulados de este manifiesto:
Valorar ms a los individuos y su interaccin que a los procesos y las herramientas, es decir,
la gente es el principal factor de xito de un proyecto software. Es ms importante construir
un buen equipo que construir el entorno.
Valorar ms el software que funciona que la documentacin exhaustiva, donde la regla a

seguir es no producir documentos a menos que sean necesarios de forma inmediata para
tomar decisiones importantes.
Valorar ms la colaboracin con el cliente que la negociacin contractual, es decir, se

propone que exista una interaccin constante entre el cliente y el equipo de desarrollo.
Valorar la respuesta al cambio que el seguimiento de un plan, es decir, la habilidad de

responder a los cambios que puedan surgir a lo largo del proyecto
Los postulados anteriores inspiran los doce principios del manifiesto, donde estos principios
representan las caractersticas que diferencian un proceso gil de uno tradicional A continuacin
se detallarn los doce principios del manifiesto, donde, los dos primeros principios son
generales y resumen gran parte del espritu gil, el resto tienen que ver con el proceso a seguir y
Jos Germn Nez Mori
Pgina 15 de 237

Metodologas giles
Junio 2009
Version 3.0
con el equipo de desarrollo, en cuanto a metas y organizacin del mismo [CLEP09]:
Nuestra principal prioridad es satisfacer al cliente a travs de la entrega temprana y continua

de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos giles se doblegan al cambio como ventaja competitiva para el cliente.
Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un
par de meses, con preferencia en los periodos breves.
Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a
travs del proyecto.
Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el

respaldo que necesitan y procurndoles confianza para que realicen la tarea.
La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un

equipo de desarrollo es mediante la conversacin cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos giles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores

y usuarios deben mantener un ritmo constante de forma indefinida.
La atencin continua a la excelencia tcnica enaltece la agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
Las mejores arquitecturas, requisitos y diseos emergen de equipos que se auto-organizan.
En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su

conducta en consecuencia.
4.
Principales metodologas giles
En esta seccin se describirn las principales metodologas giles destacadas hasta el momento.
4.1 Programacin Extrema (XP)

La definicin de esta metodologa, se ha realizado tomando como base las siguientes
referencias: [RJEF99], [RMAT6], [SMHR04], [CLEP09].Definicin
La programacin Extrema (en adelante XP) es una metodologa de desarrollo ligera (o gil)
basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de
aumentar la productividad a la hora de desarrollar programas.
Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en

Jos Germn Nez Mori
Pgina 16 de 237

Metodologas giles
Junio 2009
Version 3.0
la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia
que hay alrededor de la programacin
Los ingredientes utilizados en esta metodologa son conocidos desde el principio de la

informtica, donde, los autores de la metodologa XP han seleccionado aquellos que han
considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con
los otros. El resultado de esta seleccin ha sido esta metodologa nica y compacta. Por esto,
aunque no est basada en principios nuevos, s que el resultado es una nueva manera de ver el
desarrollo de software.
4.1.1 Principios bsicos

La metodologa XP se basa en 12 principios bsicos, agrupados en 4 categoras, las cuales se
detallan a continuacin:
Principio 1 - Retroalimentacin en escala fina:
a) El principio de pruebas, se tiene que establecer un periodo de pruebas de aceptacin

(periodo de caja negra), donde se definirn las entradas al sistema y los resultados esperados
en cada una de las pruebas definidas.
b) Proceso de planificacin, es la fase en la que se crea un documento llamado Historias de los
usuarios (User stories), en donde el usuario escribe sus necesidades, definiendo as las
actividades que realizar el sistema.
El usuario escribir entre 20 y 80 historias (dependiendo de la complejidad del problema)
que se considera suficientes para formar el llamado: Plan de Liberacin, el cual define de
forma especfica los tiempos de entrega de la aplicacin. Por regla general cada uno de las
historias de los usuarios suelen necesitar de una a tres semanas de desarrollo.
c) El cliente en el sitio, se promueve la fuerte interaccin cara a cara entre el programador y el
cliente, con el objetivo de disminuir el tiempo de comunicacin y la cantidad de
documentos, junto con sus altos costes de creacin y mantenimiento. Este representante del
cliente, deber formar parte del equipo de trabajo durante toda la realizacin del proyecto,
teniendo la potestad para determinar requerimientos definir funcionalidades, sealar
prioridades y responder preguntas de los programadores.
d) Programacin en pareja, la metodologa plantea que los programadores XP escriban su
cdigo en parejas, compartiendo una sola maquina con el objetivo de producir aplicaciones
mejores, de manera consistente a iguales o menores costes.
Jos Germn Nez Mori
Pgina 17 de 237

Metodologas giles
Junio 2009
Version 3.0
Principio 2 - Proceso continuo en lugar de por lotes:
a) Integracin contina, permite al equipo de programadores hacer un rpido progreso

implementando las nuevas caractersticas del software.
b) Refactorizacin, permite a los equipos de programadores XP mejorar el diseo del sistema,
donde a lo largo de todo el proceso de desarrollo, los programadores evalan continuamente
el diseo y recodifican lo necesario.
c) Entregas pequeas, consiste en colocar un sistema sencillo en entono de produccin
rpidamente, que se actualice de manera continua, permitiendo que el verdadero valor del
negocio sea evaluado en un ambiente real.
Principio 3 - Entendimiento compartido:
a) Diseo simple, se basa en la filosofa de que el mayor valor de negocio es entregado por el
programa ms sencillo que cumpla los requerimientos. Se enfoca en proporcionar un
sistema que cubra las necesidades inmediatas del cliente.
b) Metfora, desarrollada por los programadores al inicio del proyecto, define una historia de
como funciona el sistema completo. XP estimula historias, que son breves descripciones de
un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified
Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el
alcance y propsito del sistema
c) Propiedad colectiva del cdigo, la metodologa XP promueve la filosofa de un cdigo con
propiedad compartida, donde, nadie es propietario de nada y que todos son propietarios de
todo
d) Estndar de codificacin, define la propiedad del cdigo compartido as como las reglas
para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo
desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que
el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona.
Principio 4 - Bienestar del programador:
a) La semana de 40 horas, la programacin extrema sostiene que los programadores cansados

escriben cdigo de menor calidad. Minimizar las horas extras y mantener los programadores
frescos, generar cdigo de mayor calidad.
4.1.2 Proceso de desarrollo

XP, parte del caso habitual de una compaa que desarrolla software, normalmente a medida, en
Jos Germn Nez Mori
Pgina 18 de 237

Metodologas giles
Junio 2009
Version 3.0
la que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes
finales. El proceso conlleva las siguientes actividades:
a) Interaccin con el cliente

En este tipo de programacin, el cliente pasa a formar parte implicada en el equipo de
desarrollo, donde, su importancia es mxima en el momento de tratar con los usuarios y efectuar
las planificaciones respectivas.
Al tener al cliente mucho ms cerca del equipo de desarrollo, se elimina la fase inicial de
recopilacin de requerimientos y se permite que estos se vayan cogiendo a lo largo del proyecto
de manera ordenada en las llamadas Historia de usuario. A diferencias de otras tcnicas como
puede ser UML, el caso de XP, se exige que sea el cliente el encargado de escribir los
documentos con las especificaciones de lo que realmente quiere.
En esta fase, el equipo tcnico ser el 'encargado de catalogar las historias del cliente y
asignarles una duracin. La norma es que cada historia de usuario tiene que poder ser realizable
en un espacio entre una y tres semanas de programacin.
b) Planificacin del proyecto

En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn diferentes
iteraciones, y por cada iteracin el cliente ha de recibir una versin nueva.
Se ha de tener asumido que en el proceso de planificacin habr errores, ante lo cual la
metodologa establece mecanismos de revisin, donde cada tres o cinco iteraciones es normal
revisar las historias de los usuarios y renegociar la planificacin.
Adems la metodologa establece que por cada iteracin se realizar un planificacin, que es lo
que se llama Planificacin iterativa, en la que se anotar las historia de los usuarios que se
consideren esenciales y las que no han pasado las pruebas de aceptacin realizadas por el
cliente.
c) Diseo desarrollo y pruebas

El desarrollo es la parte ms importante en el proceso de la programacin extrema. Todos los
trabajos tienen como objetivo que se programen lo ms rpidamente posible, sin interrupciones
y en direccin correcta
Para el diseo, la metodologa establece mecanismos, para que este sea revisado y mejorado de
manera continua, segn se vaya aadiendo funcionalidad al sistema.
Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir una
prueba sencilla, y despus escribir el cdigo para que la pase. Una vez pasada se ampla y se
contina.
Jos Germn Nez Mori
Pgina 19 de 237

Metodologas giles
Junio 2009
Version 3.0
Con estas normas se obtiene un cdigo simple y funcional de manera bastante rpida. Por esto
es importante pasar las pruebas al 100%.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del
programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto
es tan importante la integracin diaria.
4.2

referencias: [CRLA02], [SABL06]. [KINT07], [WAUP09].
4.2.1 Descripcin
El Proceso Unificado gil (en adelante, AUP), se describe como una metodologa fcil de
entender para el desarrollo de aplicaciones software de negocio, utilizando tcnicas giles y
conceptos aun fieles a las de RUP, por lo tanto, es una versin simplificada del Rational Unified
Process (RUP).
AUP, incluye o hace uso de las siguientes tcnicas giles:
Test driven development (TDD).
Agile model driven development (AMDD).
Agile change management.
Data base refactoring.
AUP, es una metodologa que tiene la adopcin de muchas de las tcnicas giles de la
metodologa XP (Extreme Programming) y de las formalidades de RUP, teniendo como
filosofa adaptarse a las necesidades del proyecto y no al contrario como lo planteado en las
metodologas tradicionales. Esta metodologa, plantea un ciclo de vida iterativo, que se basa en
la ampliacin y refinamiento sucesivo del sistema, mediante mltiples iteraciones con
retroalimentacin cclica y adaptacin como elementos principales que dirigen para converger
hacia un sistema adecuado.
4.2.2
Principio bsicos
Como parte de esta metodologa, en la presente seccin se detalla, tanto las fases y disciplinas
de su planteamiento:
Jos Germn Nez Mori
Pgina 20 de 237

Metodologas giles
Junio 2009
Version 3.0
a) Fases
Al igual que RUP, AUP tiene las 4 fases clsicas consecutivas y que acaban cada uno de estas,
con hitos claros alcanzados:
Inception (Concepcin): El objetivo de esta fase es obtener una comprensin comn clienteequipo de desarrollo, del alcance del nuevo sistema y definir una o varias arquitecturas
candidatas para el mismo.
Elaboracin: El objetivo es que el equipo de desarrollo profundice en la comprensin de los

requisitos del sistema y en validar la arquitectura.
Construccin: Durante la fase de construccin el sistema es desarrollado y probado al

completo en el ambiente de desarrollo.
Transicin: el sistema se lleva a los entornos de preproduccin donde se somete a pruebas

de validacin y aceptacin y finalmente se despliega en los sistemas de produccin.
b) Disciplinas
El proceso AUP, establece un modelo ms simple que el planteado en RUP, por lo que rene en
una nica disciplina: el modelado de negocio, requisitos y anlisis y diseo. El resto de
disciplinas coinciden con las restantes de RUP, a continuacin se describe las disciplinas
consideradas por AUP:
Modelado: Se busca entender el negocio de la organizacin, el problema de dominio que se

abordan en el proyecto, y determinar una solucin viable.
Implementacin: Consiste en transformar los modelos o modelo en cdigo ejecutable y

realizar un nivel bsico de las pruebas, en particular Unit testing.
Pruebas: Se busca realizar una evaluacin objetiva para garantizar la calidad. Esto incluye la
bsqueda de defectos, validar que el sistema funciona tal como est establecido, y
verificando que se cumplan los requisitos.
Despliegue: Consiste en la elaboracin de un plan para la entrega del sistema y ejecutar el

plan para que el sistema este a disposicin de los usuarios finales.
Gestin de Configuracin: Consiste en administrar el acceso a los artefactos del proyecto.

Esto incluye no slo el seguimiento de las versiones de los artefactos en el tiempo, sino
tambin el control y la gestin de los cambios de estos.
Administracin del Proyecto: Consiste en dirigir las actividades que se llevan a cabo dentro
del proyecto. Esto incluye la gestin de riesgos, la direccin de personas (la asignacin de
tareas, el seguimiento de los progresos, etc), y de coordinacin con el personal y los
sistemas fuera del alcance del proyecto para asegurarse de que el software final sea
Jos Germn Nez Mori
Pgina 21 de 237

Metodologas giles
Junio 2009
Version 3.0
entregado a tiempo y dentro del presupuesto.
Entorno: Es un soporte para el resto de los esfuerzos para garantizar un proceso adecuado,
orientacin (normas y directrices), y herramientas (hardware, software, etc) estn
disponibles para el equipo segn sea necesario.

En esta metodologa las disciplinas se llevan acabo de manera iterativa, con la definicin de las
actividades de los miembros del equipo de desarrollo, con el fin de desarrollar, validar y
entregar el software que responda a las necesidades de los stakeholders.
En cada disciplina la metodologa plantea las diferentes actividades y artefactos a producir, lo
cual no implica que se realicen o se produzcan todo lo planteado si no ms bien lo que se
necesita en el proyecto.
Las fases que platea la metodologa no constituye el antiguo ciclo de vida secuencial o en
cascada, si no ms bien, es planteado de la siguiente manera:
La fase de Inicio (Inception), no es una fase de requisitos, si no mas bien una especia de
fase de viabilidad, donde se lleva acabo el estudio suficiente, para decidir si continuar o
no el proyecto.
La fase de Elaboracin no es una fase de requisitos o diseo, si no que es una fase

donde se implementa de manera iterativa la arquitectura que constituye el ncleo central
del sistema, y es donde se mitiga las cuestiones de alto riesgo.
En la fase de construccin, se implementa de manera iterativa el resto de requisitos (de

menor riesgo), se realiza pruebas y se prepara para el despliegue.
Por cada una de las fases e iteraciones planteadas en las mismas, se puede hacer uso de la
totalidad de las disciplinas o solo de algunas, esto depender de la iteracin en la que se
encuentre, debido a que el esfuerzo relativo en las disciplinas disminuye de iteracin en
iteracin.
AUP, plantea que en lugar del big bang en la entrega del software, una liberacin del
producto en partes, por ejemplo versin 1, luego versin 2 del software en produccin y as
sucesivamente hasta tener el producto completado. De acuerdo a este planteamiento AUP
distingue dos tipos de iteraciones:
Versin de desarrollo, cuyo resultado esta un despliegue en entorno QA (Aseguramiento de

la calidad) o Demo rea, estas versiones deben ser rpidas, de ser posible de una a tres
semanas de desarrollo.
Jos Germn Nez Mori
Pgina 22 de 237

Metodologas giles
Junio 2009
Version 3.0
Versin producto, cuyo resultado es un despliegue en produccin, donde la primera entrega

estable tardar en promedio 12 meses, la siguiente 9 meses y las siguientes cada 6 meses.
Figura 1: Iteraciones AUP
AUP, se preocupa principalmente de la gestin de riesgos. Propone que aquellos elementos con
alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas
del mismo. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables
durante la fase de elaboracin del producto, donde se demuestre la validez de la arquitectura
para los requisitos clave del producto y que determinan los riesgos tcnicos.
4.3
Agile model driven development (AMDD)
La definicin de esta metodologa, se ha realizado tomando como base la siguiente referencia:

[SABL08].
4.3.1 Descripcin
Agile model driven development (en adelante, AMDD), es una versin gil del Model driven
development (MDD), donde MDD es un enfoque amplio de desarrollo de software donde se
crean modelos antes del cdigo fuente. Un ejemplo de MDD es el estndar MDA (Arquitectura
dirigida por modelos)
La diferencia entre MDD y AMDD, es que este ltimo en lugar de crear una amplia gama de
modelos antes de escribir cdigo fuente, crea modelos giles que son solo apenas los
suficientemente buenos. AMDD es una estrategia fundamental en la escalabilidad de los
desarrollos giles del software.
4.3.2 Principio bsicos

AMDD, plantea las siguientes dos etapas como parte de su ciclo de vida del proyecto:
Previsin (Envisioning), etapa que pertenece a la iteracin 0, consta de dos sub-actividades:

o
Previsin inicial de requerimientos (Initial Requirements Envisioning).
Jos Germn Nez Mori
Pgina 23 de 237

Metodologas giles
Junio 2009
Version 3.0
Previsin inicial de la arquitectura (Initial Architectural Envisioning).
Ambas sub actividades, son recomendadas por la metodologa que se realicen en periodos
diarios, durante el tiempo que dure la iteracin 0.
Desarrollo (Development), iteracin que ser repetida hasta alcanzar un producto de calidad,
consta de sub actividades a mencionar:
o
Iteracin de modelado (Iteration Modeling).
Modelo de asalto (Model Storming).
Evaluacin en base a TDD (Test driven development)
Figura 2: Ciclo de vida de un proyecto AMDD

A continuacin, se detalla el proceso de desarrollo del ciclo de vida de un proyecto que hace uso
de la metodologa AMDD:
Modelo inicial de requerimientos (Initial Requirements Envisioning), es necesario tomar

varios das para identificar algunos de los requisitos de alto nivel y el alcance del software,
todo esto como una primera versin del sistema.
Lo que se busca con esto es conseguir un buen entendimiento del proyecto, haciendo uso de
modelos que exploren como el usuario trabaja en su entorno, obteniendo de esto un modelo
inicial del dominio, donde se identifique los tipos fundamentales de entidades de negocio y
Jos Germn Nez Mori
Pgina 24 de 237

Metodologas giles
Junio 2009
Version 3.0
las relaciones entre ellas, y un modelo de interfaz de usuario que explore UI y cuestiones de
usabilidad.
Modelo inicial de la arquitectura (Initial Architectural Envisioning), se centran los esfuerzos

en tratar de identificar una arquitectura que encaje a la forma en que trabajar el nuevo
sistema. Con esta arquitectura, se permitir fijar la direccin tcnica para el proyecto y
proporcionar informacin suficiente para la organizacin del equipo alrededor de esta
arquitectura (importante para proyectos de gran escala).
De este modelado inicial, perteneciente a la iteracin de Previsin (Envisioning), se obtendr:

diagramas de forma libre que exploren la infraestructura tcnica y los primeros modelos de
dominio que permitan explorar las principales entidades empresariales y sus relaciones. Con
esto se busca tener lo suficiente como para que el equipo pueda ponerse en marcha
A continuacin se detalla la etapa de Desarrollo (Development) de un proyecto basado en

AMDD:
Iteracin de modelado (Iteration Modeling), donde al comienzo de cada iteracin de

desarrollo, el equipo debe planificar el trabajo que har en la iteracin en base a un modelo
de actividades, basado principalmente en la prioridad de los requisitos.
Modelo de asalto (Model Storming), consiste en reuniones improvisadas de cinco a diez

minutos, donde integrantes del equipo se renen alrededor de una herramienta de modelado
o una pizarra, con el objetivo de analizar una serie de dudas o cuestiones de uno o varios
modelos y darles respuestas a cada una de estas, una vez terminada esta reunin los
integrantes del equipo siguen su labor de construccin.
AMDD, plantea que a final de cada construccin se realice pruebas unitarias del cdigo
desarrollado y la refactorizacin si fuese necesario, todo esto basado en el Test Driven
Development (TDD).
4.4
Scrum

referencias: [KSXHB09], [JSUT09]. [JPAL02], [SMHR04].
4.4.1 Descripcin
Scrum, plantea un proceso de desarrollo de software iterativo y creciente, utilizado
Jos Germn Nez Mori
Pgina 25 de 237

Metodologas giles
Junio 2009
Version 3.0
comnmente en entornos basados en el desarrollo gil de software.
Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser
utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de
programas: Scrum de Scrums.
Scrum, por sus caractersticas no es vlido para cualquier proyecto persona o equipos de
personas, es optimo para equipos de trabajo de hasta 8 personas, auque existen empresas que
han utilizado con xito scrum con equipos mas grandes.
4.4.2 Principio bsicos

Existen dos aspectos fundamentales a diferenciar en Scrum que son: los actores y las acciones,
donde los actores son los que ejecutan las acciones.
Los actores contemplados en esta metodologa son los siguientes:
Product Owner, conoce y marca las prioridades del proyecto o producto.
Scrum Master, es la persona que asegura el seguimiento de la metodologa guiando las

reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su
responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
Scrum Team, son las personas responsables de implementar la funcionalidad o

funcionalidades elegidas por el Product Owner.
Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los
progresos, pueden aportar ideas, sugerencias o necesidades.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y
forma de trabajar que a continuacin se indica, tiene como objetivo minimizar el esfuerzo y
maximizar el rendimiento en el desarrollo:
Product backlog, corresponde con todas las tareas, funcionalidades o requerimientos a

realizar que son marcadas por el Product owner.
Sprint backlog, corresponde con una o mas tareas que provienen de la lista de tareas
(Product backlog), donde estas tareas se deben acometer en unas 2 semanas o 4 semanas.
Existe una norma fundamental que mientras un Sprint backlog se inicia no debe ser alterado
o modificado, hay que esperar a que concluya para hacerlo.
Dayli scrum meeting, es una tarea iterativa que se realiza todos los das que dure el Sprint
backlog con el equipo de desarrollo, con lo cual se busca identificar obstculos o riesgos
que impidan el normal avance, verificar el avance de las tareas y la planificaciones de las
mimas para el da.
Jos Germn Nez Mori
Pgina 26 de 237

Metodologas giles
Junio 2009
Version 3.0
Sprint planning meeting, son reuniones cuyo objetivo es planificar el Sprint Backlog a partir
del Product Backlog, suelen participar el Scrum master, Scrum team y el Product owner.
Sprint review, una vez finalizado un Sprint backlog, se revisa en aproximadamente dos
horas si se ha obtenido un producto que pueda ver y tocar el Cliente o usuario, donde un
Scrum team es quien muestra los avances.
Sprint retrospective, el Product owner revisar con el equipo los objetivos marcados
inicialmente en el Sprint backlog concluido, se aplicarn los cambios y ajustes si son
necesarios, y se marcarn los aspectos positivos (para repetirlos) y los aspectos negativos
(para evitar que se repitan) del Sprint backlog.

El proceso parte de la lista de tareas (Product backlog), que no son otra cosa que los requisitos
del producto y que acta como un plan del proyecto. De esta lista el cliente prioriza los
requisitos basndose en objetivos, balanceando el valor que le aportan a su coste y quedando
repartidos en iteraciones y entregas (Sprint backlog),
De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla mediante la

replanificacin de objetivos que se puede realizar al inicio de cada iteracin.
Cada da de una iteracin debe realizarse una reunin con los integrantes del equipo con el
objetivo de obtener de primera mano los avances de las tareas y los obstculos que se van
presentando a lo largo del desarrollo de la iteracin
Una vez finalizado un Sprint backlog, se revisan con el usuario o cliente los productos
obtenidos (Sprint review) y si cumplen con las necesidades plasmadas por el usuario al inicio de
la iteracin. Cada fin de un Sprint Backlog, se debe revisar los aspectos positivos y negativos
del mismo con el objetivo de poder utilizar estos para una mejor planificacin de la siguiente
iteracin a realizar.
4.5

referencias: [DSDM09], [MART91], [SMHR04], [WDSDM09], [JCCA08].
Jos Germn Nez Mori
Pgina 27 de 237

Metodologas giles
Junio 2009
Version 3.0
4.5.1 Descripcin
La metodologa Dynamic system development Method (en adelante DSDM), es una metodologa
que surgi de un consorcio formado por 17 miembros fundadores en enero del 1994. El objetivo
de este consorcio era producir una metodologa de dominio pblico que fuera independiente de
las herramientas y que pudiera ser utilizada en proyectos de tipo RAD (desarrollo de
aplicaciones rpidas).

La estructura de esta metodologa fue guiada por 9 principios:
El involucramiento del usuario es imperativo.
Los equipos de DSDM deben tener el poder de tomar decisiones.
El foco est puesto en la entrega frecuente de productos.
La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de
los entregables.
El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin
del negocio.
Todos los cambios durante el desarrollo son reversibles.
Los requerimientos estn especificados a un alto nivel.
El testing es integrado a travs del ciclo de vida.
Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.
DSDM tiene las bases sentadas para el anlisis sobre su aplicabilidad a un grupo bien definido
de proyectos software, los cuales debern tener las siguientes caractersticas:
Son proyectos interactivos con la funcionalidad visible en la interfase de usuario.
De baja o media complejidad computacional.
Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran

tamao.
Acotados en el tiempo.
Con flexibilidad en los requerimientos.
Con un grupo de usuarios bien definidos y comprometidos al proyecto.
Esta metodologa planeta 5 fases en la construccin de un sistema, las cuales son:
Estudio de factibilidad.
Jos Germn Nez Mori
Pgina 28 de 237

Metodologas giles
Estudio del negocio.
Iteracin del modelo funcional.
Iteracin del diseo y construccin.
Implementacin.
Junio 2009
Version 3.0
Figura 3: Ciclo de vida de un proyecto AMDD

La metodologa plantea que en la fase de estudio de la factibilidad, se permita determinar si la
metodologa se ajusta al proyecto en cuestin, es decir, si las pautas dadas por DSDM pueden
utilizarse de manera optima para llevar acabo el sistema.
Jos Germn Nez Mori
Pgina 29 de 237

Metodologas giles
Junio 2009
Version 3.0
Durante el estudio del negocio, se involucra al cliente de forma temprana, para tratar de
entender la operativa que el sistema deber automatizar. Este estudio sienta las bases para
iniciar el desarrollo, definiendo las caractersticas de alto nivel que deber contener el software
y las prioridades de las mismas.
Cabe destacar que tanto la fase de estudio de factibilidad, como de estudio del negocio, son
tareas secuenciales y se realizan una nica vez al principio del proyecto y las dems fases siguen
el modelo iterativo incremental integrado con la retroalimentacin (feedback) del cliente y las
entregas frecuentes del producto.
En la iteracin de modelo funcional, se realizan tanto tareas de anlisis como desarrollo de

prototipos. Los prototipos no se descartan por completo, sino que a medida que su calidad va
aumentando, se va incluyendo en el sistema final.
Esta iteracin genera un modelo funcional, el cual contiene el cdigo del prototipo y los
modelos de anlisis.
En la iteracin de diseo y construccin, es donde se construye el sistema, dando como

resultado final, un sistema probado, que satisface los mnimos requisitos establecidos.
La iteracin de implementacin, consiste en pasar del entorno de desarrollo al entorno de

produccin. Se da formacin a los usuarios y finalmente se abre el sistema para que sea
utilizado. En esta fase, adems de la liberacin del sistema, se debe entregar manuales de
usuario e informes de revisin del proyecto.
En este punto, la metodologa DSDM, define cuatro posibles situaciones:
No se necesita realizar mayor desarrollo.
Se han dejado de realizar un conjunto de requisitos importantes, y en este caso se tiene

reiniciar el proceso desde el principio.
Se han dejado sin implementar funcionalidades crticas, por lo tanto se vuelve a la fase de
modelo funcional.
Existen problemas tcnicos que no se han podido resolver debido a la falta de tiempo, por lo
tanto, se corregirn realizando las iteraciones que hagan falta desde la fase de diseo y
construccin.
DSDM, no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni
Jos Germn Nez Mori
Pgina 30 de 237

Metodologas giles
Junio 2009
Version 3.0
siquiera impone el desarrollo bajo un paradigma especfico, funciona tanto para el modelo
orientado a objetos como para el modelo estructurado.
En la metodologa DSDM, se incluye un nuevo trmino llamado timebox, que no es ms que las
iteraciones a lo largo del ciclo de vida del proyecto. Debido a que cada timebox esta relacionado
con entregables al final de los mismos y de los feedback por parte de los clientes, constan de
tres fases:
Investigacin, donde se verifica que las actividades del timebox coincidan con la
arquitectura del sistema.
Refinamiento, donde se realiza la produccin de los artefactos planificados en la iteracin.
Consolidacin, donde se completan los entregables verificando la calidad de los mismos.
4.6

referencias: [CLEP09], [COAD98], [WFDD09].
4.6.1 Descripcin
La metodologa Feature driven development (en adelante FDD), se estructura alrededor de la
definicin de features que representan las funcionalidades que debe contener el sistema a
desarrollar y tiene un alcance lo suficientemente corto como para ser implementado en un par de
semanas.
Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario
comn que fomente,
que los desarrolladores tengan un dilogo fluido con los clientes,
desarrollando entre ambos un modelo comn del negocio.

FDD, posee una jerarqua de features, siendo el del eslabn superior el feature set, que agrupa
un conjunto de features relacionados con aspectos en comn del negocio. Por ltimo se
establece el major feature set que contribuye a proveer valor al cliente en relacin a un
subdominio dentro del dominio completo de la aplicacin. Esta jerarqua utiliza los siguientes
formatos
Para features: <accin> el <resultado> <de | para | sobre | por> un <objeto>
Jos Germn Nez Mori
Pgina 31 de 237

Metodologas giles
Para feature sets: <accin><-endo> un <objeto>
Para major feature sets: administracin de <accin>
Junio 2009
Version 3.0
Ejemplos de esto:
Calcular el total de la facturacin de Noviembre (feature)
Modificar el estado de las facturas de produccin (feature)
Administrar el perfil de los proveedores (feature)
Haciendo una venta a un cliente (feature set)
Cargando la facturacin de los proveedores (feature set)
Administracin de Bancos (major feature set)
FDD, propone un ciclo de vida del software que consta de cinco procesos:
Development an overall model.
Build a features list.
Plan by feature.
Design by feature.
Build by feature.
Donde las dos ltimas fases se realizan tantas veces como iteraciones se planifiquen en el
desarrollo.
Jos Germn Nez Mori
Pgina 32 de 237

Metodologas giles
Junio 2009
Version 3.0
Figura 4: Ciclo de vida de un proyecto FDD.

La primera actividad plateada por FDD es: Development an overall model, la cual, consiste en
desarrollar un modelo global, que sugiere un cierto paralelismo con la construccin de la
arquitectura del software. Para la construccin de este modelo participan tanto los expertos en el
dominio como los desarrolladores. Con esto se intenta lograr:
Un conocimiento global de la aplicacin a construir,
el entendimiento del negocio en que esta embebido,
un primer bosquejo de los features del software y
la definicin de las restricciones y cuestiones no funcionales.
Jos Germn Nez Mori
Pgina 33 de 237

Metodologas giles
Junio 2009
Version 3.0
La segunda actividad (Build a features list), comienza tomando el bosquejo de features

formulado durante la actividad anterior para refinar las funcionalidades incluidas. Una vez que
se han identificado las mismas se las agrupa jerrquicamente para poder estructurar el trabajo de
desarrollo; se realiza la priorizacin de las mismas basndose en la satisfaccin al cliente.
La tercera actividad (Plan by features), toma como input la lista priorizada de la fase anterior y
establece los tiempos de las futuras iteraciones. En esta actividad participan el lder de proyecto,
el lder de desarrollo y el programador jefe. A medida que se realiza la planificacin se delinean
los hitos de finalizacin de las iteraciones, dejando asentado cuales son los features y features
sets que estarn construidos en dichos hitos, en esta etapa tambin se incluye la delegacin de
responsabilidades.
Las dos ltimas actividades, Disear por features y construir por features, estn relacionadas
con la parte productiva del proceso en que se construye la aplicacin de manera incremental.
Para la iteracin del diseo, el Jefe de programadores junto con un grupo de Programadores
expertos identifica las clases, atributos y mtodos que necesita la funcionalidad requerida en un
feature. Mediante la utilizacin de diagramas UML se verifica que el diseo pueda ser
implementado.
Posteriormente en la etapa de construccin por feature, se proceden a desarrollar las clases

definidas en la anterior actividad con sus respectivas pruebas unitarias. Una vez que se pasa
estas pruebas es inspeccionado el cdigo por equipos asignados a la revisin del feature en
desarrollo, una vez finalizado esta revisin se promueve el cdigo a BUILD, siendo entregado a
Gestin de la configuracin.
La metodologa recomienda reuniones semanales entre el Lder del proyecto y el Jefe de los
programadores, donde, se permita revisar el estado de los features que se estn desarrollando.
Comparativa entre metodologas giles
En esta seccin se realizar una comparativa entre cada unas de las metodologas mencionadas
en la seccin cuatro, tomando como base la referencia: [JCCA08].
Esta comparativa se basa en una serie de criterios relevantes, con los cuales se busca obtener las
Jos Germn Nez Mori
Pgina 34 de 237

Metodologas giles
Junio 2009
Version 3.0
caractersticas fundamentales de las metodologas en estudio. Dentro de los criterios a

considerar tenemos
Ciclo de vida del proyecto, donde tomaremos como base el ciclo de vida estndar de un
proyecto.
Soporte a la gestin en cada unas de las etapas del ciclo de vida del proyecto.
Buenas prcticas, actividades y artefactos producidos en las distintas etapas planteadas por
la metodologa.
Estado actual de la metodologa.
Soporte a la calidad en el planteamiento de la metodologa.
Herramientas especficas que pueden dar soporte a la metodologa en cuestin.
5.1
Criterios de comparacin
En esta seccin se detallar cada uno de los criterios necesarios para la comparativa entre las
metodologas giles en estudio.
5.1.1 Ciclo de vida del proyecto

Para este criterio se va a considerar las siguientes etapas como parte del ciclo de vida de un
proyecto estndar:
Principio del proyecto.
Especificacin de requisitos.
Anlisis y Diseo.
Codificacin
Pruebas unitarias.
Pruebas de integracin.
Pruebas de sistemas.
Pruebas de aceptacin.
Sistema en uso o mantenimiento.
En base a las etapas mencionadas anteriormente, se analizar si cada una de las metodologas en
estudio contempla estas etapas, si describe buenas prcticas y/o actividades y si sugiere
artefactos de salida por etapa, de acuerdo a esto, el resultado se muestra en la siguiente tabla
(ver tabla 1 Ciclo de vida tradicional de un proyecto software en las metodologas giles):
Jos Germn Nez Mori
Pgina 35 de 237

Metodologas giles
Junio 2009
Version 3.0
Principio del
Espec.
Anlis y
Pruebas
Pruebas de Pruebas de Pruebas de
Codificacin
Mantenimiento
Proyecto
Requisitos
Diseo
Unitarias Integracin
Sistemas
Aceptacin
SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA SG PD BA
Metodologa
Programacin
Extrema (XP)
Scrum
Dynamic Systems
Development
Method (DSDM)
X
Proceso Unificado
gil (AUP)
X
Agile Model Driven
(AMDD)
Feature
Driven
Development
(FDD)
X
X
X
X
X
X
X
X
X
X
SG: Soporte a la gestin.

PD: Se describe un proceso en el mtodo que incluye esta etapa.
BA: Buenas prcticas, actividades y artefactos considerados en la etapa.
Tabla 1: Ciclo de vida tradicional de un proyecto software en las metodologas giles.
Jos Germn Nez Mori
Pgina 36 de 237
X
X

Metodologas giles
Junio 2009
Version 3.0
5.1.2 Estado Actual

Para este criterio se tomar en cuenta, los siguientes estados en los cuales se podra encontrar las
metodologas en estudio:
Recin nacida, metodologas que tiene un ao o menos y de la cual no tenemos evidencias ni

estudios.
En construccin, metodologas con ms de un ao de existencia, pero que no dispone de
evidencia documentada.
Activa, metodologas que llevan muchos aos en el desarrollo del software y de las cuales
podemos encontrar evidencias y estudios que corroboren su efectividad.
Olvidada, metodologas que llevan tiempo sin ser utilizadas y de las cuales no se encuentra
evidencia.
A continuacin una tabla (ver tabla 2 Estado actual de las metodologas giles), que informan
el estado actual de cada una de las metodologas en estudio:
Metodologa
Estado a la fecha
Programacin Extrema (XP)
Activa
Scrum
Activa
Activa
Actica
Agile Model Driven (AMDD)
Activa
Activa
Tabla 2: Estado actual de las metodologas giles
5.1.3 Calidad
Con este criterio se busca analizar si las metodologas en estudio contemplan ciertos parmetros
de calidad en su enunciado metodolgico.
Dentro de los parmetros a considerar en el anlisis tenemos:
Fiabilidad, la cual viene determinada por los siguientes atributos:
Simplicidad, simplicidad de los diseos, en la implementacin y en el desarrollo del
Jos Germn Nez Mori
Pgina 37 de 237

Metodologas giles
Junio 2009
Version 3.0
software en general.
Trazabilidad, entre los artefactos producidos en las distintas etapas del ciclo de vida del
software.
Usabilidad, esta parmetro viene determinado por los siguientes atributos:
Claridad y precisin de la documentacin.
Habilidades que mejoren las pruebas del software.
Mantenibilidad, este parmetro viene determinado por los siguientes atributos:

Modularidad, esto ayuda a crear una documentacin mas fcil de entender.
Simplicidad, si la metodologa promueve que los sistemas desarrollados bajo su enfoque
sean simples al momento de mantenerse.
Adaptabilidad.
Portabilidad, si bajo su enfoque promueve que el software producido pueda operar en

distintos entornos.
A continuacin una tabla (ver tabla 3 Comparativa de calidad en las metodologas giles), que
informan, los criterios de calidad asociados a cada unas de las metodologas en estudio:
Metodologa
Programacin
Extrema (XP)
Scrum
Dynamic Systems
Development Method
(DSDM)
Proceso Unificado
gil (AUP)
Agile Model Driven
(AMDD)
Feature Driven
Development (FDD)
Fiabilidad Usabilidad Mantenibilidad Adaptabilidad

X
X
X
X
Tabla 3: Comparativa de calidad en las metodologas giles
5.1.4 Herramientas
Con este criterio se busca dar a conocer las distintas herramientas que las metodologas en
estudio requieren para cumplir cada unas de las tareas que especifica su enunciado. Para esto se
enfatiz la bsqueda de herramientas de libre distribucin.
Jos Germn Nez Mori
Pgina 38 de 237

Metodologas giles
Junio 2009
Version 3.0
A continuacin, se presenta una tabla (ver tabla 4 Herramientas de libre distribucin para
metodologas giles), donde se detalla alguna de las herramientas de libre distribucin, con las
cuales se puede ejecutar cada una de las metodologas en estudio:
Metodologa
Herramientas
o
o
Programacin
Extrema (XP)
o
o
o
o
Scrum
Agile Model Driven

(AMDD)
Herramientas para la realizacin de refactorizacin,

IDEs como Eclipse y NetBeans.
Herramienta de integracin continua: Cruise
Control.
Herramientas de administracin de proyectos y
compilaciones automticas: Maven y Ant.
Repositorio de cdigos: CVS y Subversin.
Herramientas para pruebas unitarias: JUnit.
Herramientas para la medicin de rendimiento de
aplicaciones : JMeter
A pesar de no ser necesaria ninguna herramienta especial,

estn surgiendo aplicaciones Web que facilitan el
seguimiento del proyecto y la generacin de los distintos
artefactos de la metodologa, que frecuentemente se
realizan con paquetes ofimticas.
o Herramienta de diagramacin de modelos: Visual
Paradigm, eclipse (con plugins respectivos)
o Herramienta que te permite generar cdigo en base
a diagramas: AndroMDA encapsulado con
funcionalidad de MAVEN.
Para esta metodologa son necesarias las herramientas
mencionadas tanto para le metodologa XP como para
AMDD, adems de estas herramientas se podra mencionar:
o Herramientas de cobertura y evaluacin de
complejidad ciclomtica: MAVEN.:
Proceso Unificado
gil (AUP)
Dynamic Systems
Development Method No especifica ninguna prctica concreta que necesite de
(DSDM)
una herramienta especfica.
Desarroollo rpido de
o Herramientas que en base a prototipos genere
aplicaciones (RAD)
cdigo: IDEs como NetBeans y eclipse.
o Herramientas de modelado como Visual Paradigm.
o Herramientas ofimticas.
Feature Driven
o Herramientas de refactorizacin: IDEs como
Development (FDD)
eclipse y NetBeans.
Tabla 4: Herramientas de libre distribucin para metodologas giles.
Jos Germn Nez Mori
Pgina 39 de 237

Metodologas giles
5.2
Junio 2009
Version 3.0
Conclusiones de la comparativa
De acuerdo a los criterios utilizados para la comparativa, se ha llegado a las siguientes

conclusiones a mencionar:
No todas las metodologas giles contemplan todo el ciclo de vida tal y como lo hemos visto
tradicionalmente, como se puede apreciar en la Tabla 1, presentada en la comparativa de
ciclo de vida de un proyecto, la metodologa que contempla todas las etapas es la
metodologa AUP, esto debido a que es una metodologa que se basa en RUP, pero a la vez
esta metodologa sugiere que solo se utilice las etapas que sean necesarias para el proyecto,
con lo cual pude que se cumpla con toda o parte de las etapas tradicionales.
El estado actual de las metodologas giles es activo y va ganando cada vez ms adeptos.
Las metodologas giles estn orientadas a la productividad, es por este motivo que en la
comparativa de calidad solo algunas de las metodologas cumple con la gran parte de los
parmetros de calidad.
Con relacin a las herramientas de distribucin libre, como se ha podido apreciar hoy en da
existen muchas herramientas que ayudan ya en el proceso de las metodologas giles (ver
Tabla 4).
5.3
Adopcin de metodologas
Los criterios de comparacin utilizados en esta seccin son solo algunos de los criterios por los
cuales se puede llevar a cabo una comparativa entre metodologas giles y nos da una idea de
cual es el enfoque de la metodologa en cuestin que nos permitir decidir por una de las
metodologas presentadas.
La adopcin de una o varias metodologas, en vez de otras, tan solo tiene sentido si
establecemos un caso lo suficientemente concreto, invalidando cualquier tipo de generalizacin
y por ende una metodologa se hace necesaria para cada solucin.
En base a lo expuesto a lo largo de esta seccin, concluimos que las metodologas giles son un
conjunto de prcticas y mtodos que surgen de la experiencia y el estudio de muchos proyectos
software, de acuerdo a esto, la eleccin de una u otra metodologa ser en base a las necesidades
que tenga un proyecto por ejemplo:
Si el proyecto necesita pautas claras de gestin, se debera seleccionar Scrum y AUP.
Jos Germn Nez Mori
Pgina 40 de 237

Metodologas giles
Junio 2009
Version 3.0
Si se ve que el proyecto presentar ratios de error elevados, se debe utilizar XP o AUP,

debido a que ambas metodologas hace uso del Test Driven Development (TDD).
O quizs si es un proyecto interactivo con la funcionalidad visible en la interfase de usuario,

se debera optar por DSDM.
Para el caso de estudio que se llevar a cabo, y tomando como premisa que es un caso concreto
de investigacin, donde se busca adaptar en la metodologa o metodologas seleccionadas el
principio de Usabilidad, se ha visto conveniente combinar tres de las metodologas, con el
objetivo de dar una cobertura gil a un mbito ms amplio del ciclo de vida del software. Las
metodologas seleccionadas son:
Scrum, para la parte de gestin del proyecto.
XP, por ser una metodologa que cubre las actividades que desde el plano completo de la
ISO 12207, perteneciente al desarrollo de software.
AUP, por ser una metodologa que contiene a XP y tiene las formalidades de RUP.
Jos Germn Nez Mori
Pgina 41 de 237
III. Marco gil de trabajo
Versin 1.2

Mayo 2010
Version 1.2

Fecha
10/11/2009
Version
1.0
Descripcin
Autor
Jos Germn Nez
Mori
06/06/2010
1.1
Jos Germn Nez

Mori
12/10/2010
1.2
Jos Germn Nez

Mori
Jos Germn Nez Mori
Pgina 43 de 237

Mayo 2010
Version 1.2
1. Introduccin
De acuerdo a lo expuesto en el captulo de Metodologas giles, se llego a la conclusin, de
seleccionar tres de las metodologas giles planteadas a lo largo del captulo. Esta seleccin, se
realiza despus de analizar que las metodologas giles son prcticas focalizadas sobre un rea
de conocimiento, ms o menos delimitada, de la Ingeniera del Software [JPAL02].
Con las metodologas giles seleccionadas, se busca combinar varias de las prcticas de cada
una de estas metodologas, para dar una mayor cobertura gil a un mbito ms amplio del ciclo
de vida del software [JPAL02].
En el presente captulo, se planteara un marco gil de trabajo, que contenga ciertas prcticas y
actividades de cada unas de las metodologa seleccionadas en el capitulo anterior (AUP, XP y
Scrum), todo esto, con el objetivo de obtener lineamientos a seguir a lo largo de los siguientes
captulos, y en los cuales se pueda aadir los principios de Usabilidad.
2. Planteamiento metodolgico
En la presente seccin, se dar a conocer el planteamiento de este marco de trabajo gil, que
busca combinar, practicas y actividades, de cada una la metodologas seleccionadas, que en
conjunto, se adapten a los requerimientos o necesidades del presente trabajo.
Las metodologas seleccionadas, como ya se ha descrito en el capitulo anterior (Metodologas

giles) son: SCRUM, AUP y XP. De estas metodologas se ha analizado, tanto sus principios
bsicos como su planteamiento metodolgico, donde en base a este anlisis, se ha llegado a la
conclusin, de utilizar ciertas actividades y prcticas de cada una de estas metodologas y as
obtener un marco gil que se ajuste a lo requerido.
Las actividades y prcticas seleccionadas, tanto de las metodologas Scrum como AUP,
formarn la carrocera del marco gil de trabajo. Esto debido, al enfoque que tienen estas
metodologas, consiguiendo de esta manera, los lineamientos para la gestin (plateada por
Scrum) y las formalidades del Proceso Unificado (planteada por AUP) en la ejecucin del ciclo
de vida del software, con lo cual, se dejar a la metodologa XP enfocada directamente en el
plano de desarrollo.
La metodologa AUP, sugiere optar por un conjunto pequeo de actividades y artefactos del
Jos Germn Nez Mori
Pgina 44 de 237

Mayo 2010
Version 1.2
Proceso Unificado [CRLA02] [JOKR05]. Siguiendo esta idea, se ha optado por utilizar ciertas
fases y actividades que plantea AUP, las cuales sern gestionadas por los lineamientos de
SCRUM. Consiguiendo de esta manera tambin incluir prcticas de XP en este marco gil de
trabajo [SABL06] [KEBE02].
Bajo los lineamientos de este marco de trabajo gil, se ira incluyendo los principios de
usabilidad, es decir, se buscar en todo momento mejorar la usabilidad como un atributo de
calidad, tomando en cuenta as, estos patrones desde la etapa inicial del marco gil (requisitos),
luego trasmitindose a las etapas siguientes como son diseo e implementacin.
3. Estructura Metodolgica
En la presente seccin, se describir cual es la estructura que tendr el marco gil de trabajo y
en base al cual, se desarrollarn los siguientes captulos.
El marco gil de trabajo, se basar en el ciclo de vida del software plateando por AUP, a la cual
se le aadir actividades y prcticas, tanto de la metodologa Scrum como XP, es decir, se
tendr como base el siguiente modelo [SABL06]:
Figura 5: Ciclo de vida AUP

Como se muestra en la figura 5, a simple vista es el modelo clsico planteado por el Proceso
Unificado. Sin embargo, este modelo es mas simple, debido a que rene, en una nica disciplina
como es la de Modelo: el modelado de negocio, requisitos y anlisis y Diseo. El resto de
disciplinas como se pude apreciar coinciden con las planteadas por el Proceso Unificado
Jos Germn Nez Mori
Pgina 45 de 237

Mayo 2010
Version 1.2
[KINT07].
El marco gil de trabajo, tal cual se describe en lneas anteriores, seguir la estructura planteada
por AUP, con la salvedad, de solo incluir ciertas disciplinas, como son: Modelo,
Implementacin, Prueba, Despliegue y gestin de proyecto. De esta manera, el ciclo de vida que
plantea el marco gil de trabajo, se muestra en la siguiente figura 6:
Figura 6: Ciclo de vida del marco gil de trabajo
El modelo presentado en la figura 6 (Ciclo de vida del marco gil de trabajo), es un modelo ms
reducido que el plateado por AUP, esto debido, a que es un ciclo de vida que se adapta a las
necesidades, que el marco gil, solventar a lo largo del presente trabajo. Adems esta
formalidad que se asume, permitir que en cada una de las fases y disciplinas, de este ciclo de
vida planteado, se pueda realizar el estudio de la viabilidad de incluir los principios de
usabilidad.
En la figura 6, se aprecia adems, que en cada fase se manejan iteraciones, esto debido, a que el
marco gil de trabajo, tendr un enfoque de desarrollo iterativo, el cual se organizar en una
serie de mini proyectos de duracin fija, llamado iteraciones. Donde el resultado de cada
iteracin ser una parte del sistema que pueda ser probada, integrada y ejecutada.
Estas fases plateadas por el marco gil, no constituyen el antiguo ciclo de vida secuencial, si no
mas bien, la fase de inicio no es solo una fase de requisitos si una especia de fase de viabilidad,
donde se lleva a cabo solo el estudio suficiente para decidir si continuar. La fase de elaboracin
no es la fase de requisitos o de diseo, si no que es una fase donde se implementa de manera
iterativa la arquitectura que constituye el ncleo central donde se mitigan las cuestiones de alto
riesgo y en la fase de construccin se implementan de manera iterativa el resto de requisitos de
Jos Germn Nez Mori
Pgina 46 de 237

Mayo 2010
Version 1.2
menor riesgo y se prepara para el despliegue [SABL06] [CRLA02].
De acuerdo a esta estructura, a lo largo de esta seccin se detallar, el planteamiento del marco
gil de trabajo sobre cada una de las fases y disciplinas mencionadas anteriormente.
Adicionalmente al planteamiento, el marco gil describir el mecanismo a seguir para cumplir
con lo planteando, sugiriendo as, herramientas y formatos que ayudarn a cumplir este
objetivo.
3.1 Fases del marco gil de trabajo

En esta seccin se detallara cada una de las fases planteadas por el marco gil de trabajo ver
figura 2 (Ciclo de vida del marco gil de trabajo).
3.1.1 Inicio (Inception)

Para esta fase de inicio el marco gil de trabajo, plantea lo siguiente:
Obtencin de los requisitos funcionales y no funcionales de alto nivel, siguiendo el

planteamiento XP y tomando en cuenta los principios de usabilidad.
Proceso de aceptacin de los principios de usabilidad incluidos, considerando el

planteamiento AUP.
Gestin de requisitos funcionales y no funcionales, siguiendo el planteamiento Scrum.
En base a estos puntos, se tendr un hito de fase, el cual representar los artefactos que esta fase
producir al final de la misma. De acuerdo a esto, los artefactos considerados como hito de fase
son los siguientes:
Historias de Usuarios
Pruebas de Aceptacin de los requerimientos de usabilidad.
Product Backlog (Cartera de productos).
Esta primera fase se resume en el siguiente diagrama (figura 7), donde se muestra tanto el
planteamiento como los hitos de la misma [SABL06]:
Jos Germn Nez Mori
Pgina 47 de 237

Mayo 2010
Version 1.2
Figura 7: Hito de la fase de Inicio.
3.1.2 Historias de Usuarios

Los requisitos tanto funcionales como no funcionales, sern obtenidos en base a lo sugerido por
la metodologa XP, que son las llamadas Historias de usuarios, que es donde los usuarios, dan a
conocer las funcionalidades que esperan del producto. Cada historia de usuario a considerarse
como parte del producto final, ser registrada siguiendo el siguiente formato [SALECA05]
[KEBE02]:
Historia de Usuario N
: <<Descripcin abreviada>>
Nombre:
Prioridad:
Descripcin
Usuario de Creacin
Estimacin.
Fecha Alta:
Dependencia:
Figura 8: Formato de Historias de usuarios segn XP

Sobre este formato (ver figura 8), el marco gil de trabajo, incluir la manera para elicitar los
requisitos de usabilidad, buscando as, incluir los principios de usabilidad desde la fase de toma
de requerimientos, con el objetivo de obtener los mismos beneficios que teniendo en cuenta
otros atributos de calidad en los inicios de los procesos de desarrollo. De acuerdo a esto, el
marco gil plantea, un nuevo formato para recoger las historias de usuarios y a su vez los
requisitos de usabilidad:
Jos Germn Nez Mori
Pgina 48 de 237

Mayo 2010
Version 1.2
: <<Descripcin abreviada>>
Nombre:
Prioridad:
Descripcin
Usuario de Creacin
Estimacin.
Requisito
System Status Feedback
Interaction feddback
Progress feedback
Warning
Globall Undo
Object Specific undo
Fecha Alta:
Dependencia:
Requisitos de Usabibilidad Asociados
Apicacin
Comentarios
Figura 9: Formato de Historias de usuarios segn el marco gil.

Como se puede apreciar en la figura 9, el marco gil de trabajo, adiciona al formato de historias
de usuario una seccin para recoger los requisitos de usabilidad relacionados a una historia en
particular. Es por este motivo, que en la seccin de requisitos de usabilidad, se listarn todos los
requisitos contemplados, dando as la opcin al usuario que hace uso de este formato de
seleccionar el requisito asociado y describir la manera en que se debe plasmar en una historia.
El marco gil de trabajo, sugiere que este formato se debe plasmar o en cartillas o en un
documento electrnico, el cual debe entregarse al usuario para ser rellenado con la informacin
de las funcionalidades a contemplarse y sus respectivos principios de usabilidad asociados, no
siendo estrictamente, un documento a ser rellenado por los usuarios, si no tambin por los
encargados de la elicitacin de requisitos.
3.1.3 Pruebas de Aceptacin

Como un artefacto de salida de esta fase inicial, se debe contemplar procesos de aceptacin, que
garanticen la calidad del producto final. De acuerdo a esto, la metodologa AUP, plantea una
serie de procesos de aceptacin, de donde, solo se tomar uno de ellos que ayude a garantizar la
calidad de los principios de usabilidad a incluir en el ciclo de vida del software plateado.
El proceso de aceptacin seleccionado es el llamado pruebas de aceptacin, que son

bsicamente pruebas funcionales sobre el sistema completo y que buscan una cobertura de la
especificacin de requisitos. En nuestro caso de estudio, estas pruebas de aceptacin buscarn la
Jos Germn Nez Mori
Pgina 49 de 237

Mayo 2010
Version 1.2
cobertura de la especificacin de los requisitos de usabilidad elicitados.
En esta fase de Inicio, las pruebas de aceptacin, segn el marco gil de trabajo, consistirn en
la redaccin de pruebas mnimas para la validacin de los requisitos de usabilidad, las cuales se
basarn estrictamente en las historias de usuarios asociados. De acuerdo a esto, el proceso de
aceptacin tendr el siguiente formato, mostrado en la figura 10:
Id
Historia
Criterio de validacin
de los Requisitos de Usabilidad
Figura 10: Formato de Pruebas de Aceptacin.

Para este formato (ver figura 10) de pruebas de aceptacin, el marco gil, sugiere se plasme en
un documento electrnico y se rellene por cada historia de usuario las pruebas mnimas que
garanticen el funcionamiento esperado de los requisitos de usabilidad asociados. Siendo este
documento redactado por los encargado del anlisis de las historias de usuarios.
Este artefacto una vez culminado, deber de ser entregado al equipo de pruebas, con el objetivo,
de tomar futuras previsiones en las pruebas generales del sistema.
3.1.4 Product Backlog

Cada historia registrada por los usuarios, ser gestionada para su resolucin, por medio del
Product Backlog, que es el inventario de funcionalidades, mejoras, tecnologas y correccin de
errores, que deben incorporarse al producto a lo largo de sucesivas iteraciones [JPAL02].
El Product Backlog, es un documento vivo, que evoluciona de forma continua, mientras el

producto va creciendo, este artefacto es planteado por la metodologa Scrum y ser un artefacto
utilizado por el marco gil.
Esta manera de llevar el control de cada historia de usuario es simplemente, con el objetivo de
tener a primera vista y de manera muy resumida, las funcionalidades que se espera del producto.
Adems a este artefacto tendrn acceso todos los integrantes del equipo. Por lo tanto, el Product
Backlog seguir el siguiente formato [JPAL02]:
Jos Germn Nez Mori
Pgina 50 de 237

Id. Historia
Descripcin
Mayo 2010
Version 1.2
Prioridad
Estimacin
Observaciones
Responsable
Figura 11: Formato del Product Backlog

Como se puede apreciar en la figura 11, el Producto Backlog, es un listado en donde se tendr el
control de todas las historias de usuarios registradas, de una manera mucho mas resumida, y que
permitir de una manera ms gil tener una visin global de todas las funcionalidades del
producto.
El marco gil de trabajo, sugiere que este formato sea plasmado en un documento electrnico y
sea rellenado y gestionado por el encargado de llevar a cabo el producto, garantizando de esta
manera que este accesible a todas las personas que participan en el desarrollo del sistema.
3.1.5 Elaboracin
En esta fase el marco gil de trabajo, basar su enfoque en lo que plantea la metodologa AUP
(Agile Unified Process), tomando en cuenta as las disciplinas y prcticas sugeridas.
El objetivo principal de la fase de elaboracin es probar la arquitectura del sistema a

desarrollar. El punto es asegurar que el equipo realmente puede desarrollar un sistema que
satisfaga los requisitos, y la mejor manera de hacerlo es construir un esqueleto del sistema,
llamado un "prototipo de la arquitectura" [SABL06].
Es importante sealar que los requisitos no se especifican por completo en este punto. Se
detallan slo lo suficiente para entender los riesgos de la arquitectura a plantear y para asegurar
que hay un entendimiento del alcance de cada requisito, todo esto, con el objetivo de la futura
planificacin a llevarse a cabo y de identificar y priorizar los riesgos de la arquitectura, donde,
los mas significativos sern tratados en esta fase de elaboracin [SABL06].
Como se muestra en la figura 6 (Ciclo de vida del marco gil de trabajo), la disciplina de
modelo (Model) que se ejecuta tanto en la fase de inicio como la de elaboracin, sugiere que,
para esta ltima, se inicie con el diseo, especficamente como se describe en lneas anteriores,
Jos Germn Nez Mori
Pgina 51 de 237

Mayo 2010
Version 1.2
con el modelado de la arquitectura del sistema. Todo esto basado en que la arquitectura es un
aspecto importante de los esfuerzos de desarrollo del software gil.
Para esta fase el marco gil de trabajo plantea lo siguiente:
Identificacin de la arquitectura, basada en la metodologa MDA.
Realizar el plan de ejecucin de las primeras iteraciones de construccin.
De acuerdo a estos puntos la fase de elaboracin cuenta con un hito de fase, que representa los
artefactos que esta fase producir al final de la misma. Estos son los siguientes:
Prototipo de la arquitectura del sistema.
Plan de ejecucin de la primera iteracin de construccin.
Esta fase se resume en el siguiente diagrama (ver figura 12), donde se muestra tanto el
planteamiento como los hitos de la misma [SABL06]:
Figura 12 : Hito de la fase de Elaboracin

Como paso siguiente de esta seccin, se detallar cada uno de los puntos planteados como hito,
describiendo de esta manera los mecanismos para obtener los artefactos de salida de esta fase de
elaboracin.
3.1.6 Prototipo de la arquitectura del sistema

Cuando el marco gil de trabajo, emplea el trmino de prototipo de arquitectura, hace referencia
a que en esta fase de elaboracin, se debe obtener un primer modelo de la arquitectura del
sistema, donde se rena las partes, las conexiones y las normas de interaccin entre los
Jos Germn Nez Mori
Pgina 52 de 237

Mayo 2010
Version 1.2
componentes de este sistema, haciendo uso de conexiones especificas y sobre los que se basarn
las posteriores modificaciones en implementaciones a realizar.
En base a esta premisa, el marco gil de trabajo, basado en las distintas metodologas de su
planteamiento, buscar un enfoque de metodologa, que permita obtener este primer modelo de
arquitectura y que esta sirva como estructura principal para las futuras iteraciones de desarrollo.
AUP (Agile Unified Process) incluye en su planteamiento una metodologa que ayudar en las
tareas de modelado de la arquitectura. Esta metodologa es conocida como Agile model driven
development (AMDD), que en su enfoque principal sugiere que el desarrollo de un sistema sea
dirigido por modelos lo suficientemente necesarios para obtener el producto final [SABL06].
Para tener mayor detalle de la metodologa AMDD, se puede revisar el capitulo de
Metodologas giles.
El marco gil de trabajo, basado en AUP, har uso del planteamiento de AMDD para desarrollar
su enfoque de prototipo de Arquitectura y sus futuras iteraciones de desarrollo, especficamente
utilizando el estndar sugerido por esta metodloga, siendo este, el estndar MDA (Model
Driven Architecture).
MDA es un estndar, que potencia el uso de modelos en el desarrollo, debido a que usa los
modelos para dirigir el mbito de desarrollo, el de diseo, el de despliegue, el de la operacin, el
de mantenimiento y el de la modificacin de los sistemas.
En el marco gil de trabajo, MDA pretende ser utilizado para dirigir tanto el mbito desarrollo
como el de diseo. Bajo este estndar el marco gil, en esta fase de elaboracin, tendr como
objetivo realizar una primera iteracin que permita obtener una parte del sistema que pueda ser
probada, integrada y ejecutada.
Esta primera iteracin, contemplar la ejecucin del prototipo de arquitectura, que consistir en
obtener tanto el diseo de este prototipo como el desarrollo del mismo. De esta manera se
cumplir con el objetivo de esta fase, que es la implementacin de la arquitectura que constituye
el ncleo central donde se mitigan las cuestiones de alto riesgo y cuyo propsito ser ayudado
por el estndar MDA.
Para este prototipo de arquitectura, el marco gil, sugiere que se selecciona un requisito donde
se pueda evaluar los riesgos de la arquitectura y a su vez tenga asociado los requisitos de
usabilidad de mayor complejidad, como por ejemplo: Progress Bar.
Jos Germn Nez Mori
Pgina 53 de 237

Mayo 2010
Version 1.2
A continuacin, se detallara la especificacin del estndar MDA, buscando as entender, el

desarrollo dirigido por modelos y cmo se har uso del mismo para lograr obtener uno de los
hitos de esta fase (Prototipo de la Arquitectura)
3.1.7 Estndar MDA (Model Driven Architecture)

En esta seccin se detallar la especificacin del estndar MDA, basado en la siguientes
referencias: [LECCO09], [MDAWI10], [OMGWB10].
La arquitectura dirigida por modelos (Model Driven Arquitectura) es una especificacin
detallada por el OMG (Object Management Group) que integra diferentes especificaciones y
estndares definidos por la misma organizacin, con la finalidad de ofrecer una solucin a los
problemas relacionados con los cambios en los modelos de negocio, la tecnologa y la
adaptacin de los sistemas de informacin a los mismos.
MDA nos permite el despliegue de aplicaciones empresariales, diseadas sin dependencias de la
plataforma de despliegue y expresando su diseo mediante el uso de UML y otros estndares.
Donde estos estndares, pueden ejecutarse en cualquier plataforma existente, abierta o
propietaria, como servicios web, .Net, Corba, J2EE, u otras.
La especificacin de las aplicaciones y la funcionalidad de las mismas se expresan en un

modelo independiente de la plataforma que permite una abstraccin de las caractersticas
tcnicas especficas de las plataformas de despliegue. Mediante transformaciones y trazas
aplicadas sobre el modelo independiente de la plataforma se consigue la generacin automtica
de cdigo especfico para la plataforma de despliegue elegida.
Todo esto proporciona finalmente una independencia entre la capa de negocio, y la tecnologa
empleada. De esta manera es mucho ms simple la incorporacin de nuevas funcionalidades, o
cambios en los procedimientos de negocio sin tener que llevar a cabo los cambios en todos los
niveles del sistema. Bajo este enfoque el marco gil de trabajo buscar incluir en tiempo de
diseo los patrones de usabilidad.
Siguiendo este planteamiento, se desarrollan los cambios en el modelo independiente de la

plataforma, y stos se propagarn a la aplicacin, consiguiendo por tanto, una considerable
reduccin del esfuerzo en el equipo de desarrollo. De esta manera tambin, se disminuye los
errores que tienden a producirse en los cambios introducidos en las aplicaciones mediante otros
Jos Germn Nez Mori
Pgina 54 de 237

Mayo 2010
Version 1.2
mtodos de desarrollo, y por consiguiente, la reduccin de costes y aumento de productividad.
MDA se apoya sobre los siguientes estndares para llevar a cabo su funcin:
UML (Unified Modeling Language): empleado para la definicin de los modelos

independientes de la plataforma y los modelos especficos de las plataformas de destino. Es
un estndar para el modelado introducido por el OMG.
MOF (MetaObjet Facility): establece un marco comn de trabajo para las especificaciones
del OMG, a la vez que provee de un repositorio de modelos y metamodelos [OMGWB10].
XMI (XML Metada Interchange): define una traza que permite transformar modelos UML
en XML para poder ser tratados automticamente por otras aplicaciones.
CWM (Common Warehouse Metamodel): define la transformacin de los modelos de datos

en el modelo de negocio a los esquemas de base de datos [OMGWB10].
El estndar MDA, establece tres puntos de vista que se emplearn a lo largo de su proceso de
ingeniera:
Punto de vista independiente de la computacin, el cual se centra en el entorno del sistema y

los requisitos para el mismo. Los detalles de la estructura y procesamiento del sistema no se
muestran, o an no estn especificados.
Punto de vista independiente de la plataforma: se centra en las operaciones del sistema,

mientras oculta los detalles necesarios para una determinada plataforma. Muestra aquellas
partes de la especificacin del sistema que no cambian de una plataforma a otra. En este
punto de vista debe emplearse lenguaje de modelado de propsito general, o bien algn
lenguaje especfico del rea en que se emplear el sistema, pero en ningn caso se
emplearn lenguajes especficos de plataformas.
Punto de vista de plataforma especfica: combina el punto de vista independiente de la

plataforma con un enfoque especfico para su uso en una plataforma especfica de un
sistema.
En base a estos puntos de vista, MDA plantea diferentes estados de modelado para lograr
obtener el producto final. Estos modelos son los siguientes:
Modelo independiente de la computacin (CIM), es una vista del un sistema desde el punto
de vista independiente de la computacin. En algunos casos, nos referimos a este modelo
como el modelo de dominio y se usa vocabulario propio de los expertos en el dominio para
la especificacin.
Modelo independiente de la plataforma (PIM), es una vista del sistema del punto de vista
independiente de la plataforma, exponiendo as un carcter independiente de la plataforma
Jos Germn Nez Mori
Pgina 55 de 237

Mayo 2010
Version 1.2
sobre la que se desplegar. Con esto se logra un modelo que puede ser empleado en
diferentes plataformas de carcter similar.
Modelo especfico de la plataforma (PSM), es una vista del sistema (producto final) desde el
punto de vista especfico de la plataforma, combinando as el modelo independiente de la
plataforma con los detalles especficos de la plataforma del sistema.
3.1.7.1.1.1 Usando MDA

Expuestos los conceptos bsicos de MDA, a continuacin, se dar a conocer como se relacionan
los modelos, su modo de uso y las transformaciones entres ellos.
El modelo de origen es el CIM (Modelo independiente de la computacin), con el que se

modelan los requisitos del sistema, describiendo la situacin en que ser usado en el sistema y
que aplicaciones se espera que el sistema lleve a cabo, sirviendo tanto como ayuda para
entender el problema o como una base de vocabulario para usar en los dems modelos.
Los requisitos recogidos en el CIM (Modelo independiente de la computacin) han de ser

trazables a lo largo de los modelos PIM (Modelo independiente de la plataforma) y PSM
(Modelo especifico de la plataforma) que los implementan.
El CIM, puede consistir en un par de modelos UML que muestren tanto la distribucin de los
procesos (ODP, Open Distributed Processing) como la informacin a tratar. Tambin puede
contener algunos modelos UML ms que especifiquen en mayor detalle los anteriores.
A partir del CIM, se construye un PIM, que muestra una descripcin del sistema, sin hacer
referencia a ningn detalle de la plataforma. Debe presentar especificaciones desde el punto de
vista de la empresa, informacin y ODP. Un PIM se puede ajustar a un determinado estilo de
arquitectura, o a varios.
Despus de la elaboracin del PIM, el arquitecto debe escoger una plataforma (o varias) que
satisfagan los requisitos de calidad y en base a la trazabilidad obtener el PSM. La figura 13,
resume el planteamiento de estos modelos:
Jos Germn Nez Mori
Pgina 56 de 237

Mayo 2010
Version 1.2
Figura 13: Trazabilidad de Modelos MDA
3.1.7.1.1.2 Mapas de Transformacin MDA

Mediante mapas, MDA especifica las reglas de transformacin de un PIM (Modelo
independiente de la plataforma) a un PSM (Modelo especfico de la plataforma) para una
plataforma en concreto. Estos mapas incluyen la transformacin de tipos de valores, as como
los metamodelos y sus reglas para la transformacin en tipos de valores existentes en las
plataformas especficas.
Cuando se prepara un modelo haciendo uso de un leguaje independiente de la plataforma

especificada en un metamodelo y posteriormente se elige una plataforma para el despliegue,
debe existir una especificacin de transformacin entre el metamodelo independiente de la
plataforma y el metamodelo que describe la plataforma. La figura 14, ilustra este requisito:
Jos Germn Nez Mori
Pgina 57 de 237

Mayo 2010
Version 1.2
Figura 14: Transformacin de metamodelos bajo MDA.

Una forma de facilitar la transformacin de modelos es la identificacin de elementos en el PIM
que deben transformarse de una manera concreta para la plataforma de destino, y marcarlos
como tal. Una marca expresa un concepto del PSM en el PIM; las marcas alejan el PIM de la
independencia de la plataforma, por lo que un arquitecto debe mantener un PIM limpio, donde
las marcas deben concebirse como una capa transparente que se pone sobre el modelo.
Figura 15: Marcado de un modelo bajo MDA

En la Figura 15, se ilustra el uso de marcas como ayuda para la transformacin, y su situacin
intermedia entre la independencia y la dependencia de la plataforma. Una vez es elegida la
plataforma, existe un mapa para la transformacin de modelos. Este mapa incluye un conjunto
de marcas, que usamos para marcar los elementos del PIM como gua para la transformacin del
Jos Germn Nez Mori
Pgina 58 de 237

Mayo 2010
Version 1.2
modelo.
Las marcas pueden definir tipos del modelo, especificacin de clases, asociaciones, roles,
estereotipos, etc. Las marcas tambin pueden especificar caractersticas cualitativas que despus
en la transformacin se convertir en el objetivo apropiado para el cumplimiento de los
requisitos.
Los mapas de transformacin pueden mantener tambin plantillas, que son modelos
parametrizados que especifican tipos concretos de transformaciones. Podemos asociar un
conjunto de marcas a una plantilla para identificar instancias en un modelo que deben ser
transformados de acuerdo a las indicaciones de la plantilla.
Existe la posibilidad de incluir informacin relativa a patrones que extienda las caractersticas y
tipos de los metamodelos y el lenguaje de la plataforma especfica elegida para el despliegue.
Como muestra la figura 16, el uso de informacin adicional para la transformacin implica la
necesidad de informacin de los patrones para la transformacin, que sern especficos para la
plataforma de destino.
Figura 16: Patrones de transformacin en los modelos MDA
3.1.7.1.1.3 Transformaciones de modelos MDA

El siguiente paso al establecimiento de las marcas en los modelos y la seleccin de mapas de
transformacin es aplicar la transformacin desde el PIM (Modelo independiente de la
plataforma) marcado al PSM (Modelo especifico de la plataforma). Este proceso puede ser
manual, asistido por computador, o automtico.
Jos Germn Nez Mori
Pgina 59 de 237

Mayo 2010
Version 1.2
La transformacin, es el proceso que toma como entrada el PIM marcado y da como resultado el
PSM del sistema y el registro de transformacin.
Algunas herramientas, pueden hacer una transformacin del PIM directamente a cdigo
desplegable en la plataforma de destino o incluso, conceptos como MDR (Model-Driven
Runtime Environment), que propone el uso de un entorno de ejecucin para los PIM,
directamente, sin generacin de PSM ni cdigo para la plataforma. En cualquier caso el OMG
sostiene que la transformacin debe emitir un PSM para ayudar al entendimiento del cdigo y la
depuracin del mismo.
El registro de transformacin incluye una traza desde cada elemento del PIM a los elementos
correspondientes en el PSM, especificando que parte de los mapas de transformacin fueron
empleados para derivar los elementos del PSM desde los elementos del PIM. Una herramienta
que mantenga los registros de transformacin debe ser capaz de sincronizar de forma automtica
los cambios producidos en un modelo al otro.
El PSM producido por una transformacin es un modelo del mismo sistema que ha sido
especificado en el PIM. Tambin especifica como el sistema hace uso de una determinada
plataforma.
Un PSM, ser una implementacin del sistema si proporciona toda la informacin necesaria
para construir el sistema y ponerlo en marcha.
Una vez descrita y explicada la estrategia del estndar MDA, el marco de gil de trabajo,
siguiendo lo descrito por este estndar, sugiere que todo este mecanismo de planteamiento
MDA, sea dirigido de manera automtica y asistida por algn Framework (marco de trabajo),
que permita contemplar gran parte de este especificacin y cuya curva de aprendizaje sea
minima para los desarrolladores.
El Framework que se ajusta a las necesidades del presente trabajo, al planteamiento del estndar
MDA y lo que requiere el marco gil de trabajo es el Framework AndroMDA.
Como paso siguiente en el planteamiento del prototipo de arquitectura del sistema, se describir
el Framework seleccionado (AndroMDA), que permitir realizar las labores de modelado que se
ajusten a lo planteado por el estndar MDA y a su vez ayuden al marco gil de trabajo a cumplir
con el hito de esta fase de elaboracin.
Jos Germn Nez Mori
Pgina 60 de 237

Mayo 2010
Version 1.2
3.1.7.1.2 AndroMDA
En esta seccin se detallar en que consiste este Framework y de cmo ser utilizado por el
marco gil de trabajo, detallando as, las distintas utilidades de este Framework y de cmo estas
ayudarn a cumplir con el objetivo de este trabajo. La explicacin de esta seccin se ha basado
en la siguiente referencia: [AMDA10].
Esta herramienta, es un marco de generacin extensible que se adhiere al paradigma MDA y que
toma cualquier nmero de modelos (usualmente modelos UML guardados en formato XMI
producidos por alguna herramienta case), que en combinacin con plugins de la propia
herramienta (Plantillas y bibliotecas de traduccin), produce componentes personalizados, es
decir, se puede generar componentes en un gran nmero de lenguajes entre los que se encuentra:
Java, .Net, HTML, PHP, etc.
El cdigo generado por AndroMDA, es automticamente integrado al proceso de construccin,

siendo esta generacin muy eficiente para la aplicacin a partir de un modelo independiente de
la plataforma, lo que produce as, la columna vertebral del proyecto, permitiendo de esta manera
que los desarrolladores se mantengan enfocados en la lgica del negocio.
De acuerdo a lo que AndroMDA proporciona, el presente trabajo pretender que el desarrollo de

este proyecto se realice sobre una plataforma java, especficamente bajo J2EE. Segn esto, el
marco gil de trabajo, a lo largo de esta seccin ira detallando la manera de configurar un
proyecto J2EE utilizando AndroMDA.
3.1.7.1.2.1 MDA en la generacin de cdigo de AndroMDA

En el sentido clsico de la Ingeniera de Software, uno de los primeros elementos es determinar
qu es lo que el sistema tiene que hacer (fase de anlisis). En esta fase el arquitecto o
desarrollador tiene algo en la mente que ser traducido hacia un documento especfico (modelo
o texto). Luego, necesitar implementar ese entregable, para lo cual requerir una persona o un
grupo de personas que implementen esa transformacin en un lenguaje como C, JAVA, C++,
etc.
Con el estndar MDA, lo que se intenta es simplificar el trabajo del desarrollador/arquitecto, a

travs de la digitalizacin de ideas que l/ella tengan en mente (Mental Model MM o CIM). Por
esta razn, el desarrollador/arquitecto debe crear un modelo independiente de la plataforma
(PIM), es decir, transformar del lenguaje mental a uno formal como por ejemplo UML. Este
Jos Germn Nez Mori
Pgina 61 de 237

Mayo 2010
Version 1.2
enfoque tiene muchas ventajas algunas de ellas se listan a continuacin:
Es un proceso de transformacin muy sencillo y directo
El desarrollador/arquitecto mantiene el enfoque en la lgica del negocio.
PIM (Modelo independiente de la plataforma), puede ser re-utilizado luego. No est acotado
a la plataforma actual.
PIM es un excelente medio para comunicar ideas a otras personas.
El prximo paso es encontrar la manera para transformar el PIM hacia el cdigo. La forma
MDA de lograr esto es, ir individualmente refinando el modelo hasta llegar al modelo especifico
de la plataforma a utilizar (PSM) y pasar de este modelo a cdigo escrito manualmente
Este es el punto en el cual AndroMDA acta, pues posee diferentes cartuchos o Cartridges
(plugins), que analizaran el PIM dado y construirn el PSM. Luego, de construido ste se usaran
plantillas para producir el cdigo, donde, el cdigo generado es un lenguaje que nunca
necesitar ser modificado manualmente, sin embargo de ocurrir el caso, existen formas
elegantes para resolver este tipo de problemas.
Figura 17: Ciclo AndroMDA de generacin de cdigo

Como se puede apreciar en la figura 17, una vez interpretado el modelo UML, para generar el
cdigo de un lenguaje determinado, se hace uso de los Cartridges o cartuchos, que son
elementos que interpretan determinadas marcas en el modelado como por ejemplo los
estereotipos de UML (entidad, numeracin, etc) o en su defecto, condiciones inferidas del
modelo, como la dependencia de los actores hacia un componente marcado como servicio.
Una vez interpretado tanto las condiciones o marcas en el modelado, estos cartuchos, cuentan
con diferentes plantillas de los recursos necesarios para la generacin de cdigo de un lenguaje
o tecnologa determinada.
Jos Germn Nez Mori
Pgina 62 de 237

Mayo 2010
Version 1.2
Estos Cartridges o cartuchos, son importantes en el proceso de transformacin de cdigo de

AndroMDA y cada uno ellos pueden ser personalizados de acuerdo a las necesidades requeridas.
Por otro lado, es muy importante tomar en cuenta que AndroMDA, ayuda a eliminar las tareas
repetitivas de desarrollo, mientras que al mismo tiempo permite que tu modelo pueda
asemejarse con lo que realmente el sistema hace. Esto no significa que la computadora har todo
el trabajo por el desarrollador y est deje de pensar.
3.1.7.1.2.2 Arquitectura del marco gil de trabajo segn AndroMDA

Segn se describe en lneas anteriores, el proyecto se pretende realizar bajo la plataforma J2EE,
siguiendo as una arquitectura de N niveles o capas distribuidas, basndose ampliamente en
componentes de software modulares y que sern ejecutados en un servidor de aplicaciones.
Bajo esta premisa, el marco gil de trabajo se basara en la siguiente estructura:
Figura 18: Arquitectura de Aplicacin base del marco gil de trabajo

Como se puede apreciar en la figura 18, se presenta una estructura de capas populares de una
aplicacin empresarial, donde se cuenta con los siguientes niveles:
Capa de presentacin (Presentation layer), que contiene los elementos necesarios para
interactuar con el usuario de la aplicacin
Capa de negocio (Business layer), encapsula la funcionalidad del negocio principal de la

aplicacin, accediendo a esta capa por medio de una fachada de servicios, que oculta la
complejidad que alberga la misma.
Capa de acceso a datos (Data Access layer), contiene los elementos necesarios para acceder
Jos Germn Nez Mori
Pgina 63 de 237

Mayo 2010
Version 1.2
a los datos subyacentes de la aplicacin, abstrayendo de esta manera la semntica de la

tecnologa de acceso a estos y permitiendo de esta manera que la capa de negocio se centre
en la lgica del sistema.
Almacn de datos (Data Store), base de datos o sistema de archivos.
Ahora que se ha mostrado la estructura de las aplicaciones de empresas modernas en la que se

basar el marco gil de trabajo (ver figura 18), se detallara como AndroMDA ayuda a
implementar estos conceptos.
AndroMDA, toma como entrada un modelo de negocio especificado en UML y generar una
parte significativa de las capas o niveles necesarios para construir una aplicacin Java, esto
debido a que este Framework, tiene la capacidad de traducir de manera automtica
especificaciones de alto nivel empresarial, en cdigo de calidad ahorrando as un tiempo
significativo para el desarrollo de aplicaciones.
A continuacin, se presenta la estructura de aplicacin empresarial que plantea AndroMDA y

cada una de las tecnologas que soporta la misma en cada uno de los niveles o capas
contempladas:
Figura 19: Estructura de Aplicacin empresarial AndroMDA

Jos Germn Nez Mori
Pgina 64 de 237

Mayo 2010
Version 1.2
Como se pude apreciar en la figura 19, por cada nivel que presenta la arquitectura se muestran
las tecnologas Java soportadas por este Framework. A continuacin se describe la seleccin de
las tecnologas por capa que ha optado utilizar el marco gil de trabajo, en base a la estructura
presentada por AndroMDA:
Capa de presentacin (Presentation layer), se ha optado por utilizar la tecnologa Struts, que
ayudara a generar componentes Web.
Capa de negocio (Business layer), en esta capa se utilizar una tecnologa que siga el
modelo POJO (Plain Old Java Object) y que sea del tipo no intrusivo. Ante esto, se ha
optado por utilizar el Framework Spring.
Capa de acceso a datos (Data Access layer), se utilizar una tecnologa de mapeo relacional
de objetos llamada Hibernate.
Almacn de datos (Data Store), se puede utilizar cualquiera base de datos, para este trabajo
se utilizar la base de datos Hypersonic.
3.1.7.1.2.3 Modelado de AndroMDA y el prototipo de Arquitectura del marco gil

de trabajo
A lo largo de todo este gran apartado, que tiene como objetivo obtener el prototipo de
arquitectura, se ha ido explicando, tanto la metodologa (AMDD), el estndar (MDA) como el
Framework (AndroMDA), que ayudarn en conjunto, en base a sus planteamientos al marco
gil de trabajo, a conseguir este hito de salida de la fase de elaboracin.
En secciones de este apartado, se ha ido detallando el planteamiento del marco gil de trabajo
para conseguir este hito de fase (Prototipo de Arquitectura), que en resumen, es un
planteamiento basado en el diseo de modelos para conseguir los componentes necesarios de
una funcionalidad determinada.
Ya en esta seccin, es donde, se detallar cada uno de los tipos de modelos y sus componentes,
que AndroMDA sugiere utilizar para el diseo y que permitirn obtener los recursos necesarios,
para el prototipo de arquitectura.
Siguiendo la estructura de aplicacin de AndroMDA (ver figura 15 - Estructura de Aplicacin

empresarial AndroMDA), se explicar por cada nivel de esta estructura, los modelos implicados
que permitan, obtener la codificacin bsica de los componentes de este prototipo de
arquitectura.
Jos Germn Nez Mori
Pgina 65 de 237

Mayo 2010
Version 1.2
Modelado en la capa de presentacin:
Este nivel como se comenta en secciones anteriores permite la interaccin con el usuario, es por
esta razn que AndroMDA por medio de ciertos modelos UML llegar a obtener los recursos
necesarios para el funcionamiento de esta capa.
Con el objetivo de plasmar los diferentes eventos y cambios de estado que se generan en esta
capa de presentacin, AndroMDA, plantea modelar este comportamiento en base a diagramas
de actividad y estereotipos UML
Figura 20: Diagrama de Actividad en AndroMDA

Como se pude apreciar en la figura 20, se muestra el diseo de una determinada funcionalidad
en la capa de presentacin, plasmando as, sus estados de inicio y fin, sus eventos por ejemplo
cancelar, sus cambios de estado, sus decisiones, etc, lo cual representa las interacciones del
usuario con el sistema.
El proyecto ser ejecutado en base a servicios Web (bajo plataforma J2EE), lo cual implica que
la interaccin del usuario con el sistema, ser llevada por medio de pginas JSP (basadas en
tecnologa Struts).
El diseo mostrado en la figura 20, representa las transiciones (flechas) y estados (cajas) que
tendr una pgina JSP, para procesar una determinada peticin de usuario y su respectiva
respuesta.
Jos Germn Nez Mori
Pgina 66 de 237

Mayo 2010
Version 1.2
Para poder indicar, en un diagrama de actividad AndroMDA, que un de estos estados

representar una pgina JSP, se deber marcar por medio del estereotipo <<FrontEndView>>,
de no ser as, representarn estados que sern procesados por el sistema, en esta caso y
siguiendo la tecnologa Struts, deber ser procesado por una clase controladora.
Para modelar las clases controladoras asociados a las pginas JSP, ser necesario modelar un
diagrama de clase, en donde, la clase que haga de controlador, tenga referencia al diagrama de
actividad y las operaciones necesarias para resolver cada uno de los estados asociados al sistema.
La figura 21 muestra el diseo de una clase controladora:
Figura 21: Componente controlador en AndroMDA

Los diagramas de actividad, como sus respectivos controladores, representarn tanto las
acciones como las operaciones que resuelven las peticiones del usuario.
AndroMDA, con el objetivo de modelar las funcionalidades que tendr el sistema, sugiere
modelar estas en funcin de diagramas de casos de uso (ver figura 22).
Figura 22: Casos de Uso AndroMDA

Cada caso de uso diseado (ver figura 22), tendr que relacionarse con un diagrama de actividad
y estos a su vez a una clase controladora respectiva, que en conjunto representarn, la operativa
necesaria para atender las peticiones de los usuarios, asociadas a una funcionalidad determinada.
Modelado en la capa de Negocio:
Jos Germn Nez Mori
Pgina 67 de 237

Mayo 2010
Version 1.2
En este nivel, como se ha ido detallando en secciones anteriores, se pretende modelar el ncleo
de una aplicacin. AndroMDA, sugiere para esta capa modelar componentes de tipo servicio,
que representen cada una de las clases necesarias para resolver las funcionalidades del sistema
Estos tipos de servicio, representarn fachadas que ocultan la lgica de negocio que se pretende
plasmar a este nivel, permitiendo as de esta manera menos acoplamiento tanto con la capa de
presentacin, como con la capa de Datos. La figura 23 muestra este diseo:
Figura 23: Modelado de servicios en AndroMDA

En la figura 23, se muestran componentes de un diagrama de clase, con la particularidad, de
estar marcado por el estereotipo <<Service>>, el cual como se ha descrito, en la codificacin
representaran fachadas de la capa de negocio.
Capa de acceso a datos:
En esta capa se modelar las distintas entidades de datos, con las que contar el sistema. Todo
esto siguiendo lo sugerido por AndroMDA, que plantea plasmar un mapeo relacional de objetos,
que se ajuste a la tecnologa usada en este nivel (Hibernate). La figura 24 muestra este diseo:
Figura 24: Modelado de entidades de datos en AndroMDA
Jos Germn Nez Mori
Pgina 68 de 237

Mayo 2010
Version 1.2
En la figura 24, se presenta el diseo de un diagrama de entidad relacin, con la particularidad

que cada componente, viene marcado con el estereotipo <<Entity>>, el cual al momento de
resolverse, representar una tabla de base de datos y sus respectivas clases de mapeos Java en el
proyecto, ayudando as de esta manera en la labor de recuperacin de datos.
Una vez mostrado todos los componentes a modelar en cada una de las capas, nos preguntamos,
como se representa la interaccin de estos componentes entre un nivel y otro? Para esto
AndroMDA, sugiere utilizar flechas de dependencias entre componentes, ver la figura 25:
Figura 25: Dependencia entre componentes de capa en AndroMDA
3.1.7.1.2.4 Herramientas y tecnologas en el ciclo de generacin AndroMDA

En esta seccin detallamos cada una las herramientas y versiones de las tecnologas, que
utilizar el marco gil de trabajo, en el ciclo de generacin AndroMDA:
Para el modelado se utilizar la herramienta MagicDraw UML 9.5, que permitir plasmar
los diseos en formato XMI [MGDU10].
Para transformar los modeles en formato XMI, hacia cdigo, se utilizar la herramienta
Apache Maven en su versin 2.2.1 [AMVN10]
La herramienta Apache Maven en conjunto con las libreras de AndroMDA, interpretarn

el modelo y generarn los componentes necesarios a implementar. La versin de
AndroMDA a utilizar es la 3.2 [AMDA10].
Se utilizar el Framework Apache Struts en su versin 1.2.7 [ASTS10].
El Framework Spring en su versin 1.2.7 [SPIG10].
El Framework Hibernate en su versin 3.1.3 [HBNT10].
En base a todos estos modelos, tecnologas y herramientas que se ha ido detallando a lo largo de
Jos Germn Nez Mori
Pgina 69 de 237

Mayo 2010
Version 1.2
este apartado, se obtendr el prototipo de arquitectura tanto a nivel de modelado como de

implementacin. Adems cabe recalcar, que bajo este enfoque de modelado es que se pretende
incluir cada uno los patrones de diseo relacionados con la Usabilidad.
3.1.7.2 Plan de ejecucin de la primera iteracin de construccin

Scrum, es una de las metodologas de gestin en la que se basa el marco gil de trabajo. As, en
esta seccin se detallar la manera en que Scrum, plantea desagregar una funcionalidad
especifica en diferente tareas, que en conjunto formen una iteracin.
Scrum, cuenta con un elemento llamado Sprint backlog, que consiste en descomponer las
funcionalidades del Product backlog, en tareas necesarias para construir un incremento (una
parte completa y operativa del sistema) [JPAL02].
En el Sprint se asigna a cada tarea, la persona responsable de su desarrollo y se indica el tiempo

de trabajo que se estima. Adems en este elemento, cada persona responsable de cada tarea
deber de registrar el avance de la misma y de esta manera tener de primera mano informacin
del tiempo que falta para terminarla.
Este enfoque, es til porque permite descomponer el proyecto en tareas de tamao adecuado
para determinar el avance diario e identificar riesgos y problemas sin necesidad de procesos
complejos de gestin [JPAL02]. Adems tomar en cuenta que en Scrum un Sprint es
equivalente a una iteracin del marco gil de trabajo.
Para realizar un Sprint backlog, Scrum sugiere se tenga en cuenta lo siguiente:
Deber de realizarse de forma conjunta con todos los miembros del equipo.
Deber de tomarse en cuenta todas las tareas identificadas por el equipo para conseguir el
objetivo del Sprint.
El tamao de cada tarea est en un rango 4 a 16 horas de trabajo.
Tiene que ser visible para todo el equipo. Idealmente en una pizarra o pared en el mismo
espacio fsico donde trabaja el equipo.
Para el Sprint backlog, Scrum sugiere los siguientes formatos en los que se puede realizar esta
tarea:
Hoja de Calculo.
Pizarra o pared fsica.
Jos Germn Nez Mori
Pgina 70 de 237

Mayo 2010
Version 1.2
Herramienta colaborativa o de gestin de proyectos.
El marco gil de trabajo, opta por realizar esta labor en base a una herramienta colaborativa, que
permita registrar los Sprint y que este a la vez accesible para todo el equipo de trabajo.
La herramienta sugerida por el marco gil de trabajo es Sprintometer, la cual es una

herramienta gil y a su vez simple para la gestin y el seguimiento de proyectos basados en
SCRUM y XP [SPTOME09].
Sprintomer, fue creado originalmente por la gente que trabaja en proyectos giles para sus
propios fines y ahora esta disponible como producto Freeware.
A continuacin se describir brevemente, algunos detalles importantes para el uso de esta

herramienta, que permitan en el momento de la ejecucin de la fase, el uso adecuado de la
misma [SPTOUG08]. En las figuras 26, 27 y 28, se muestran detalles de esta herramienta:
Figura 26: Herramienta de gestin Sprintometer
Jos Germn Nez Mori
Pgina 71 de 237

Mayo 2010
Version 1.2
a
b
c
Figura 27: Seccin de registro de Sprint en Sprintometer
Figura 28. Seccin de control de avance de tareas en el Sprint bajo Sprintometer

De acuerdo a la figura 26 [SPTOUG08]:
tem
1
Comentarios
En esta seccin es donde se realiza el registro de los Sprint que gestionara el proyecto.
Como se puede ver en la figura 23, donde se desglosa la seccin del registro de los
Sprint, existen niveles de registro:
a. Nivel Sprint, a este nivel es donde se registra los Sprint (iteraciones) que
contendr el proyecto.
b. Nivel de Historias de usuario o funcionalidades, a ese nivel se registrar las
funcionalidades que se pretende gestionar en un Sprint.
c. Nivel de tarea, a este nivel ya se habla de una mayor granularidad de un
Sprint, debido a que en este nivel se registra las tareas a realizar por cada
funcionalidad registrada.
En esta seccin, es donde ya se lleva el control de las tareas registradas, mostrando as el

avance de las mismas tanto a nivel de Sprint, de funcionalidades como de tareas (ver
figura 15)
Tabla 5 : Detalle de secciones del Sprintometer

Jos Germn Nez Mori
Pgina 72 de 237

Mayo 2010
Version 1.2
De acuerdo a lo planteado en esta seccin, en base a la herramienta Sprintometer, se deber de

realizar la planificacin de la primera iteracin (Sprint), que contemple las tareas necesarias
para llevar a cabo el prototipo de arquitectura.
Esta forma de gestionar el proyecto deber de ser aplicada tambin en futuras iteraciones, es
decir, que se deber de seguir esta estructura de planificacin para las iteraciones de la fase de
desarrollo.
3.1.8 Fase de Desarrollo

En esta fase, como ya se ha descrito en el planteamiento de fases del marco gil de trabajo, se
inicia con las iteraciones de desarrollo de cada una de las funcionalidades del sistema. Todas las
iteraciones de desarrollo, que se hagan en esta fase seguirn la misma estructura planteada en la
primera iteracin de desarrollo de la fase de elaboracin, que como ya se ha comentado, tiene
como objetivo el prototipo de la Arquitectura.
De acuerdo a esta premisa, esta fase de desarrollo seguir el planteamiento dado en la fase de
elaboracin para la implementacin de cada una de las funcionalidades del sistema.
Jos Germn Nez Mori
Pgina 73 de 237
IV. Fase de Inicio del Marco gil de Trabajo
Versin 1.1

Fase de inicio del marco gil de trabajo
Junio 2009
Version 1.1

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

Junio 2009
Version 1.1
Fase de Inicio del marco gil de trabajo

1. Introduccin
El marco gil de trabajo, plantea ciertas fases que comprenden la estructura de su metodologa.
En este captulo, se abordar el desarrollo de la primera de sus fases, que hace referencia a la
fase inicial de este marco de trabajo.
La metodologa AUP (Agile Unified Process), que es una de las metodologas referentes del
presente trabajo, plantea una serie de actividades a realizar en la fase de inicio, como por
ejemplo: definicin de riesgos del proyecto, estimacin de costes, etc. En esta primera fase, el
marco gil, realiza su planteamiento basado en dos de las actividades que sugiere realizar en
esta fase la metodologa AUP, las cuales son: Definicin del alcance y la planificacin del
proyecto.
Esta primera fase, tal cual se describe en el capitulo anterior, es una fase de inicio de la
metodologa que plantea este marco gil de trabajo, donde, se definir a un nivel alto lo que el
sistema va hacer y lo que no es suficiente a realizar, estableciendo as, los lmites dentro de los
cuales el equipo de desarrollo ira a operar, es decir, se determinar el alcance del proyecto
[SABL06].
En cuanto a la planificacin del proyecto, el marco gil de trabajo, plantea la gestin de las
funcionalidades del sistema en base a lo descrito en la metodologa Scrum, que es bsicamente,
un inventario de caractersticas que el propietario del producto desea obtener. Donde, por ser
una metodologa gil, no debe interpretarse en el sentido de que todo el proyecto esta previsto
en este punto [JPAL02].
Tal cual define el marco gil de trabajo, esta fase tiene un objetivo de fase llamado hito, que
consiste, en producir al final de la misma una serie de artefactos, que corresponde con cada una
de las actividades consideradas en esta fase. Por lo tanto, el presente capitulo, se basar en el
desarrollo de cada uno de estos artefactos planteados.
Cabe comentar, que el presente trabajo basar su anlisis en las funcionalidades de un sistema
relacionado con el mercado de seguros de vida, es decir, un sistema que gestiona, productos que
incluyen seguros de vida, riesgo, rentas, planes individuales de ahorro y asegurados en general.
Jos Germn Nez Mori
Page 76 of 237

Junio 2009
Version 1.1
En esta rama de seguros de vida, uno de los activos importantes, son las personas a las cuales se
brindan los productos de vida, es por este motivo que un sistema asociado a este negocio debe
contemplar una gestin de las personas aseguradas y sus vnculos referentes.
De acuerdo a estas premisas, el presente trabajo, opta por ejecutar su planteamiento, sobre las
funcionalidades mnimas referentes a la gestin de personas aseguradas. Es as, que estas
funcionalidades sern desarrolladas a lo largo de este capitulo, en base al ciclo de vida del
software planteado por el marco gil de trabajo
2. Desarrollo de la fase de Inicio

En esta seccin se desarrollar cada uno de los artefactos necesarios para cumplir con el hito de
esta primera fase.
2.1 Product Backlog

A continuacin, se detalla cada unas las funcionalidades, seleccionadas de la gestin de
personas aseguradas. Estas funcionalidades, se presentan en una tabla (ver tabla 6) que sigue el
formato del Product Backlog planteado por Scrum:
Id. Historia
PER001
PER002
PER003
PER005
Descripcin
Relacionar Personas
Gestionar Fusin de Personas
Buscar Personas Fusionadas
Gestionar Situacin Familiar de la
Persona (alta)
PER004
Recuperar Datos Entidad Finaciera
Prioridad Estimacin
10
9
9
8
Observaciones
JGNuez
Esta funcionalidad deber de
empezar a desarrollarse una vez
publicado los servicios de la
JGNuez
Entidaed Financiera
Tabla 6: Product backlog
2.2 Historias de usuarios

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

Nombre:
Descripcin:
Junio 2009
Version 1.1
: PER0001
Prioridad:
Relacionar Personas
Esta funcionalidad permitir crear relaciones entre las personas dadas de alta en el sistema y
que sean de la misma red comercial, para lo cual, es necesario que se tenga como parmetros
de entrada, tanto el cdigo de la persona gestionada, como la red comercial a la que pertenece.
Para generar las relaciones de la persona gestionada, esta funcionalidad debe permitir
buscar las personas a relacionar por los siguientes criterios:
Tipo Vinculo, Vinculo, cdigo de la persona, tipo de persona, sin
identificacin, fiscalmente aplicable.
Una vez ubicada la persona, se dar de alta en la relacin y se adicionar a las
relaciones existentes de la persona gestionada.
Usuario de Creacin:
Estimacin:
Jos Nez Mori
Fecha Alta:
01/04/2010
Dependencia:

Requisito
Aplicacin
Comentarios
Si el alta de la relacin, no se realiza correctamente, se mostrar el

siguiente mensaje en formato de error: "La operacin no se ha realizado
con xito, debido a ..."
Tras el evento de adicin de una nueva relacin, esta se aadirn al final

de la tabla de relaciones de la persona gestionada y se remarcarn con
un color apropiado.
Interaction Feedback
Progress feedback
Jos Germn Nez Mori
Page 78 of 237

Junio 2009
Version 1.1
Progress feedback
Warning
Global Undo
Tras el evento de confirmacin de las nuevas relaciones asociadas a

la persona gestionada, el sistema presentar el siguiente mensaje en
formato de confirmacin.: "Se va a guradar los cambios en las
relaciones de la persona gestionada, Esta seguro de re
Esta funcionalidad debe permitir la opcin de deshacer, lo cual
consitir, en eliminar las diez ltimas relaciones dadas de alta con esta
operacin. Adems se presentar estas diez ltimas relaciones en
formato de lista.
Object Specific Undo
Abort Operation
Go back
Esta funcionalidad presentar la opcin de cancelar, que ser a nivel

de operacin, y que permitir abortar, ya sea la bsqueda o la adicin
de relaciones en curso. Retonando el control a la funcioanlidad previa
o al home de la aplicacin.
Para los campos del criterio de bsqueda se tendr en cuenta lo
siguiente:
Tipo Vnculo, lista desplegable (obligatorio)

Vinculo, lista desplegable. (obligatorio)
Cdigo de la persona alfanumrico de 6 caracteres
(obligatorio).
Sin identificacin, campo de verificacin.
Fiscalmente aplicable, campo de verificacin.
El sistema validar el formato de los campos del criterio de bsqueda

y presentar los siguientes mensajes en formato de notificacin ante
el incumplimiento de los mismos:
Structured Text Entry,

Step by Step
Preferentes
Personal Object Space
Favourite
Multilevel Help
Commands Aggregation
Si existen campos del criterio de bsqueda que no se ajusten

al formato adecuado, se mostrar el siguiente mensaje: El
campo XXXX, debe ser tipo XXXX (ejemplo de formato).
Si existen campos obligatorios, que no hayan sido
cumplimentados, se mostrar el siguiente mensaje: El campo
XXXX, es obligatorio.
Tabla 7: Historia de usuario Relacionar personas
Jos Germn Nez Mori
Page 79 of 237

His toria de Us uario N
Junio 2009
Version 1.1
: PER0002
Nombre :
Prioridad:
De s cripcin: Esta funcionalidad permitir la fusin o no fusin de personas candidatas a fusionarse, donde
la persona principal de la fusin, tendr la referencia a los contratos, direcciones de correo
electrnico del grupo de personas fusionadas y ser la persona visible ante cualquier bsqueda
en el sistema.
Para esta funcionalidad, previamente se tiene que haber seleccionado de la lista de personas
candidatas a fusionarse, la personas que ser la principal de la fusin. Una vez hecho esta
seleccin, se debe mostrar un listado con la persona seleccionada anteriormente y las personas
candidatas a la fusin, esta lista debe tener la siguiente informacin:
Principal (Columna de seleccin)

Fusionar (Columna de seleccin)
No Fusionar (Columna de seleccin)
Cdigo de Persona
Tipo de Identificacin
Nmero de Identificacin
Nombre (Concatenacin del primer y segundo nombre). Slo en caso de personas
fsicas.
Apellido. Slo en caso de personas fsicas.
Fecha Nacimiento. Slo en caso de personas fsicas.
Sexo. Slo en caso de personas fsicas.
Razn social. Slo en caso de personas jurdicas
De este listado, el usuario selecciona las personas a fusionar o no fusionar, adems esta
funcionalidad debe permitir adicionalmente, adicionar al listado de candidatos a fusionar,
cualquier persona del sistema (fusin manual)
Us uario de Cre acin:

Es timacin:
Jos Nez Mori
Fe cha Alta: 01/04/2010

De pe nde ncia:
Re quis itos de Us abibilidad As ociados

Requisito
A plicacin

Progress feedback
W arning
Jos Germn Nez Mori
Com entarios
Si el alta de una fusin, no se realiza correctamente, se mostrar el

siguiente mensaje en formato de error: "La operacin no se ha
realizado con xito, debido a ..."
Esta funcionlaidad por actualizaciones de datos tardar de 1 a 4
segundos, ante lo cual, el sistema deber mostrar un barra de
progreso de la operacin.
Tras el evento de guardado de la fusin asociada a la persona
principal, el sistema mostrar el siguiente mensaje en formato de
confirmacin: "Se va a gurdar la fusin en curso, Esta seguro de
realizar esta operacin?"
Page 80 of 237

Junio 2009
Version 1.1
Global Undo
Abort Operation
Go back
Esta funcionalidad proveer niveles para abortar las operaciones en

curso:
A nivel de operacin, que lo que permitir es cancelar, las
fusiones en curso y regresar a la funcionalidad anterior o al
home de la aplicacin.
A nivel de comando, que lo que permitir es cancelar, la
operacin de alta de una nueva fusin, lo cual estar
controlado con una barra de progreso.
El sistema deber mostrar en formato de notificaciones, el

incumplimiento de las siguientes validaciones, ante el evento de
guardado:

Step by Step
Preferentes
Favourite
Multilevel Help
En caso de seleccionar, de la lista de personas a fusionar, ms

de un persona principal, el sistema deber mostrar el
mensaje: Seleccin Incorrecta, en la fusin solo se debe
tener una persona principal.
Si para una persona de la lista, se selecciona mas de una de
la siguientes columnas Principal, Fusionar, No Fusionar, se
deber mostrar el siguiente mensaje: Seleccin incorrecta,
solo se debe de seleccionar una de las tres columnas
Si de la lista de personas a fusionar no se seleccionan alguna
de las tres columnas (Principal, Fusionar, No Fusionar), el
sistema debe mostrar el siguiente mensaje: Existen personas
en la lista que falta seleccionar.
Tabla 8: Historia de usuario Gestionar fusin de personas
Jos Germn Nez Mori
Page 81 of 237

Junio 2009
Version 1.1
: PER0003
Nombre:
Prioridad:
El sistema permitir la bsqueda de personas que han pasado por un proceso de fusin
(tanto de las personas principales o fusionadas).
Se debe permitir, tanto la bsqueda de personas fsicas como jurdicas, cada bsqueda con
criterios particulares
Bsqueda de personas fsicas:
El sistema muestra los siguientes criterios de bsqueda:
Cdigo de persona, Tipo Identificacin, Nmero de Identificacin, Sin

Identificacin, Cdigo externo de la persona (proporcionado por la red), Primer
apellido, Segundo apellido, Primer nombre, Segundo nombre, Fecha de
Nacimiento, Red comercial, Nmero de tarjeta Sanitaria.
Descripcin:
Una vez ingresado los datos necesarios, se mostrar el listado con las personas fusionadas
coincidentes. Esta lista mostrar la siguiente informacin:
Cdigo de persona, Fecha de fusin, Tipo de Indetificacin, Sin Identificacin,

Estado de la persona en el sistema, Cdigo externo de la persona, Primer apellido,
Segundo apellidos, Nombre, Fecha de nacimiento, Nmero de tarjeta sanitaria.
Bsqueda de personas jurdicas:

El sistema muestra los siguientes criterios de bsqueda:
Cdigo de persona, Fecha de fusin, Tipo de Indetificacin, Sin Identificacin,

Estado de la persona en el sistema, Cdigo externo de la persona, Razn social,
Nombre comercial, Actividad comercial, Red comercial.
Una vez ingresado los datos necesarios se mostrar el listado con las personas fusionadas
coincidentes. Esta lista mostrar la siguiente informacin:
Usuario de Creacin:
Estimacin:
Cdigo de Persona, Fecha de fusin, Tipo de identificacin, Nmero de

identificacin, Sin identificacin, Estado de la persona en el sistema, Cdigo
externo de persona, Red comercial, Razn social, Fecha de constitucin.
Jos Nez Mori
Fecha Alta: 01/04/2010

Dependencia:

Requisito
Aplicacin
Comentarios

Progress feedback
Warning
Global Undo
Jos Germn Nez Mori
Page 82 of 237

Junio 2009
Version 1.1
Abort Operation
Go back

de operacin, y que permitir abortar, la bsqueda en curso,
retonando el control a la funcioanlidad previa o al home de la
aplicacin.
Tanto para la bsqueda de personas fsicas y jurdicas se debe tener
en cuenta lo siguiente:
Cdigo de persona, alfanumrico de 6 caracteres (Campo
obligatorio).
Tipo identificacin, alfanumrico, siendo este un listado a
seleccionar (Campo obligatorio).
Nmero de identificacin, alfanumrico de 6 caracteres.
Sin identificacin, listado de seleccin ( Si / No).
Estado de la persona en el sistema, listado de seleccin
(Habilitada / Inhabilitada).
Cdigo externo de la persona, alfanumrico de 8 caracteres
(Campo obligatorio)
Red comercial, listado a seleccionar
Primer y segundo apellido, primer y segundo nombre,

alfanumricos de 50 caracteres.
Fecha de nacimiento, con el formato DD/MM/AAAA
Nmero de tarjeta sanitaria, alfanumrico de caracteres.
Campos obligatorios: Primer y segundo apellido, tarjeta sanitaria.

Bsqueda de personas jurdica:
Razn social, alfanumrica de 50 caracteres.

Nombre comercial, alfanumrico de 50 caracteres.
Actividad comercial, listado a seleccionar, de las actividades
parametrizadas en el sistema.
Campos obligatorios: Razn social, nombre comercial.

y presentar los siguientes mensajes en formato de notificacin ante
el incumplimiento de los mismos:
:
Structured Text Entry
Jos Germn Nez Mori
Page 83 of 237

Junio 2009
Version 1.1
Step by Step
P referentes
P ersonal Object Space
Favourite
Multilevel Help
Tabla 9: Historia de usuario Buscar personas fusionadas
: PER0004
Nombre:
Prioridad:

Descripcin: Este funcionalidad permitir recuperar los datos de una persona de la Entidad Financiera y
actualizar los datos de la persona en el sistema.
Para realizar esta bsqueda se debe ingresar los siguientes criterios:
Tipo de identificacin.
Nmero de identificacin.
Una vez ingresado estos criterios, el sistema recuperar un listado con las personas
coincidentes de la entidad financiera. Este listado tendr la siguiente informacin:
Cdigo de cliente. Cdigo de cliente de la EEFF, Tipo de identificacin, Nmero de
identificacin, Nombre y apellidos del cliente
De este listado, se debern poder seleccionar una de las personas, para poder obtener sus datos,
los cuales sern recuperados de la Entidad financiera, siendo estos:
Tipo de identificacin, Nmero de identificacin, Nombre, Primer Apellido, Segundo
Apellido, Fecha de nacimiento, Profesin, Estado civil, Lista de cuentas corrientes de
la persona, Lista de domicilios de la persona, Telfono (prefijo y nmero).
Una vez obtenido estos datos, se actualizar los datos en la persona del sistema.
Usuario de Creacin:
Estimacin:
Jos Nez Mori
Fecha Alta: 01/04/2010

Dependencia:

Requisito
Aplicacin
Comentarios
Al momento de recuperar tanto los datos de las persona, como el

listado de personas coincidentes en la entidad financiera, si se produce
algn error en este proceso, el sistema deber mostrar un mensaje en
formato de Error: "Se ha producido el / los si
Tanto la recuperacin de los datos, como el listado de personas

coincidentes tardarn de 3 a 5 segundos, por lo cual el sistema
mostrar un icono animado que indique el porcentaje de tiempo de la
espera.

Progress feedback
Jos Germn Nez Mori
Page 84 of 237

Warning
Junio 2009
Version 1.1
Tras el evento de actualizacin con los datos obtenidos de la entidad

financiera, el sistema mostrar un mensaje en fomato de
confirmacin: "Se va actualizar la persona con los datos de la EEFF,
Esta seguro de esta operacin?"
Global Undo
Abort Operation
Go back

de operacin, tanto en la busqueda como en la recuperacin de datos
de la entidad financiera, tras el evento de cancelar se rotornar el
control a la funcioanlidad anterior o al home d
Esta funcionalidad permitir, que una vez obtenido los datos de la
persona de la entidad financiera,se cuente con la opcin de "ir Atrs",
lo cual permitira regresar al listado de personas.
Para los campos de criterio se tendr en cuenta lo siguiente:
Tipo identificacin, alfanumrico, siendo este un listado a

seleccionar (Campo obligatorio).
Nmero de identificacin, alfanumrico de 6 caracteres..

y presentar los siguientes mensajes en formato de notificacin ante el
incumplimiento de los mismos:

Step by Step
Preferentes
Favourite
Multilevel Help

Tabla 10: Historia de usuario Recuperar datos entidad financiera
Jos Germn Nez Mori
Page 85 of 237

His toria de Us uario N
Junio 2009
Version 1.1
: PER0005
Nombre :
Prioridad:
Persona (alta)
De s cripcin: Esta funcionalidad permitir la gestin (Alta) de la situacin familiar asociada a un persona
fsica.
Esta funcionalidad, deber presentar la siguiente informacin a cumplimentar:
Datos Asegurado:
Situacin familiar, NIF del cnyuge, % de retencin del IRPF, fecha de movilidad
geogrfica, prolongacin de la actividad laboral (valor SI /NO), pensin compensatoria a
favor de cnyuge (importe anual), anualidades por alimentos a favor de los hijos.
Datos Hijos, descendientes menores de 25 aos o discapacitados:
Ao de nacimiento, ao de adopcin, grado de minusvala, necesita ayuda terceros (valor

SI / NO),
Esta seccin, permitir adicionar o eliminar los datos de hijos o descendiente de un listado
mostrado en la parte inferior de esta seccin.
Datos de Ascendientes mayores de 65 aos o discapacitados que viven con el perceptor:
Ao de nacimiento, grado de minusvala, necesita ayuda de terceros (valor SI/NO).
Esta seccin, permitir adicionar o eliminar los datos de los ascendientes de un listado
mostrado en la parte inferior de esta seccin.
Us uario de Cre acin:

Es timacin:
Jos Nez Mori
Fe cha Alta: 01/04/2010

De pe nde ncia:
Re quis itos de Us abibilidad As ociados

Requisito
A plicacin
Com entarios

Progress feedback
W arning
Tras cumplimentar los tres pasos de la funcionalidad y ejecutar el

evento de guardado el sistema mostrara un mensajes en formato de
confirmacin: "Se va a guardar los datos de la situacin familiar de la
persona, Esta seguro de realizar esta operacin?"
Global Undo
Jos Germn Nez Mori
Page 86 of 237

Junio 2009
Version 1.1

de operacin, en cada uno de sus pasos,donde, tras el evento de
cancelar se retornar el control a la funcioanlidad anterior o al home de
la aplicacin, abortando as, las operaciones r
Tanto los pasos: Datos de los hijos y datos de los descendientes,

contarn con la opcin de "Ir Atrs", lo que permitir regresar al paso
inmediatamente anterior.
Step by Step
Preferentes
Favourite
Esta funcionalidad contar con tres pasos a cumplimentar, los cuales

seran cada una de las secciones detallas en la descripcin. Cada uno
de estos pasos se presentarn en el orden de la descripcin, indicando
en cada paso, el paso en el que esta y el paso que le falta para finalizar
la funcionalidad.
Multilevel Help
Cada paso de esta funcionalidad presentar un icno de ayuda el cual

al pulsar mostrar un pop-up con la ayuda de cada paso.
Se mostrar la ayuda de cada tarea al pular las teclas ctrl+A
Abort Operation
Go back
Tabla 11: Historia de usuario Gestionar Situacin familiar de la persona
2.3 Pruebas de aceptacin

En esta seccin, se presenta las pruebas de aceptacin mnimas, asociadas a los requisitos de
usabilidad contemplados en cada una de las historias de usuario desarrolladas.
Id
Historia
Se deber dar de alta una relacin ya

existente en la lista de relaciones de la
persona gestionada, ante esto el sistema
deber mostrar un mensaje del tipo
notificacin: La operacin no se ha
realizado con xito, debido a que la
persona ya existe en las relaciones de la
persona gestionada.
Se debe dar de alta una relacin, cuando el
recurso de Base de datos se encuentra
cado, ante esto el sistema deber mostrar
un mensaje del tipo notificacin: La
operacin no se ha realizado con xito,
debido a que el manejador de Base de
datos no se encuentra disponible (BD001).
Dar de alta nuevas relaciones y verificar, que
estas se aaden al final de la lista de
relaciones de la persona gestionada. Adems
validar que cada una de estas nuevas
relaciones esten remarcadas con un color
determinado
PER0001
Relacionar
Personas
Jos Germn Nez Mori
Page 87 of 237

Junio 2009
Version 1.1
Dar de alta nuevas relaciones asociadas a la
persona gestionada y luego confirmar esta
operacin. Ante esto el sistema deber
mostrar el siguiente mensaje en formato de
notificacin: "Se va a gurdar los cambios en
las relaciones de la persona gestionada,
Warning
Adicionar 10 nuevas relaciones a las

relaciones de la persona gestionada. Una vez
realizado esto, ejecutar el evento deshacer,
ante lo cual el sistema deber presentar un popup con un listado, donde muestre estas diez
ltimas relaciones. Una vez aceptado
Global Undo
Durante el alta de relacines de la persona
gestionada, ejecutar el evento cancelar. Tras
esto, validar que el sistema redirige al usuario a
la funcionalidad anterior o al home de la
aplicacin. Confirmar adems, que los datos de
la relacin en curso no s
Abort Operation
Verificar los formatos de los siguientes campos:
Tipo Vnculo, lista desplegable

(obligatorio)
Vinculo, lista desplegable. (obligatorio)
Cdigo de la persona alfanumrico de
6 caracteres (obligatorio).
Sin identificacin, campo de
verificacin.
Fiscalmente aplicable, campo de
verificacin.
Luego realizar la bsqueda de personas a

relacionar, sin cumplimentar el campo:
"Cdigo de la persona". Ante esto el sistema
deber mostrar un mensaje del tipo notificacin:
"El campo Cdigo de la persona, es
obligatorio
Tabla 12 : Prueba de aceptacin Relacionar personas
Jos Germn Nez Mori
Page 88 of 237

Id
Junio 2009
Version 1.1
Historia
P ER0002
Gestionar Fusin
de Personas
Se debe dar de alta una fusin, cuando el

recurso de Base de datos se encuentra
cado, ante esto el sistema deber mostrar
un mensaje del tipo notificacin: La
operacin no se ha realizado con xito,
debido a que el manejador de Base de
datos no se encuentra disponible (BD001).
Progress feedback
Realizar una fusin y una vez aceptada la

misma, verificar que se muestra una barra de
progreso, donde se informe el estado de la
fusin.
W arning
Guardar la fusin asociada a una persona

principal y luego verificar que el sistema
muestre el siguiente mensaje en formato de
confirmacin: "Se va a gurdar la fusin en
curso, Esta seguro de realizar esta
operacin?"
Durante el proceso de alta de una fusin
validar lo siguiente:
Abort Operation
Jos Germn Nez Mori
Ejecutar el evento cancelar, y verificar,

que el sistema redirige al usuario a la
funcionalidad anterior o al home de la
aplicacin. Confirmar adems, que los
datos de la fusin no se han registrado en
el sistema.
Aceptar o confirmar la fusin en curso y
una vez se muestre la barra de progreso,
ejecutar el evento cancelar de la misma:
Tras esto, validar que los datos de la fusin
no se han registrado en el sistema.
Page 89 of 237

Junio 2009
Version 1.1
Realizar una fusin, y validar las siguientes
casusticas tras el evento de aceptar la fusin:
Seleccionar, de la lista de personas a

fusionar, ms de un persona principal,
donde, tras el evento de aceptar la
fusin, verificar que el sistema muestra
el
siguiente
mensaje:Seleccin
Incorrecta, en la fusin solo se debe
tener una persona principal.
Para una persona de la lista a fusionar
se debe de seleccionar mas de una de
la siguientes columnas
Principal,
Fusionar, No Fusionar, donde, tras el
evento de aceptar la fusin, se debe
validar que el sistema muestra el
siguiente
mensaje:
Seleccin
incorrecta, solo se debe de seleccionar
una de las tres columnas.
De la lista de personas a fusionar no
seleccionan alguna de las tres
columnas (Principal, Fusionar, No
Fusionar), donde, tras el evento
decapitar la fusin, verificar que el
sistema muestra el siguiente mensaje:
Existen personas en la lista que falta
seleccionar.
Tabla 13: Prueba de aceptacin Gestionar fusin de personas

Id
PER0003
Historia
Buscar personas
fusionadas
Abort Operation
Jos Germn Nez Mori
Durante el cumplimentado de datos para la

bsqueda, ejecutar el evento cancelar: Tras esto,
validar que el sistema redirige al usuario a la
funcionalidad anterior o la home de la
aplicacin, dejando la operacin en curso sin
efecto.
Validar los formatos de los campos de la
Page 90 of 237

Junio 2009
Version 1.1
Validar los formatos de los campos de la
bsqueda:
Cdigo de persona, alfanumrico de 6
caracteres (Campo obligatorio), Tipo
identificacin, alfanumrico, siendo
este un listado a seleccionar (Campo
obligatorio), Nmero de identificacin,
alfanumrico de 6 caracteres, Sin
identificacin, listado de seleccin ( Si
/ No). Estado de la persona en el
sistema,
listado
de
seleccin
(Habilitada / Inhabilitada), Cdigo
externo de la persona, alfanumrico de
8 caracteres (Campo obligatorio), Red
comercial, listado a seleccionar
Primer y segundo apellido, primer y
segundo nombre, alfanumricos de 50
caracteres, Fecha de nacimiento, con el
formato DD/MM/AAAA, Nmero de
tarjeta sanitaria, alfanumrico de
caracteres.
Campos obligatorios: Primer

apellido, tarjeta sanitaria.
segundo
Bsqueda de personas jurdica:

Razn social, alfanumrica de 50
caracteres.,
Nombre
comercial,
alfanumrico de 50 caracteres, Actividad
comercial, listado a seleccionar, de las
actividades parametrizadas en el sistema.
Campos obligatorios: Razn social, nombre
comercial.
Realizar bsquedas con

criterios:
lo siguientes
Campos del criterio de bsqueda que

no se ajusten al formato adecuado,
donde, el sistema deber mostrar el
siguiente mensaje en formato de
notificacin: El campo XXXX, debe
ser tipo XXXX (ejemplo de formato).
Campos obligatorios, que no hayan
sido cumplimentados, donde, el
sistema deber mostrar el siguiente
mensaje en formato de notificacin:
El campo XXXX, es obligatorio.
Tabla 14: Prueba de aceptacin Buscar personas fusionadas
Jos Germn Nez Mori
Page 91 of 237

Id
PER0004
Junio 2009
Version 1.1
Historia
Recuperar Datos
Entidad Finaciera
Progress feedback
Validar que ante la recuperacin de datos como

el listado de personas coincidentes de la entidad
financiera, el sistema muestre en la espera un
icono animado que indique el pocentaje de
tiempo consumido de la operacin
Warning
Obtenido los datos de la persona de la entidad

financiera, actualizar los mismos en el sistema,
donde, al aceptar dicha actulizacin el sistema
deber mostar un mensaje en formato de
notificacin: "Se va actualizar la persona con
los datos de la EEFF,
Abort Operation
Durante la recuperacin tanto de los datos de la

persona como el listado de personas coincidentes
de la Entidad Financiera, ejecutar el evento
cancelar. Tras esto, validar que el sistema
redirige al usuario a la funcionalidad anterior o
al home de la apli
Go back
Jos Germn Nez Mori
Recuperar tanto los datos de la persona, como el

listado de personas coincidentes de la entidad
financiera, cuando no se tiene conexin al
servicio de entidad financiera. Ante esto el
sistema deber mostrar un mensaje en formato
de error: "Se ha producid
Validar que en la operacin de obtener los datos

de la persona de la entidad financiera, al ejecutar
el evento "ir atr", el sistema redirija al usuario a
la operacin listado de personas coincidentes de
la bsqueda en la entidad financiera
Page 92 of 237

Junio 2009
Version 1.1
Validar los formatos de los campos del criterio:
Tipo identificacin, alfanumrico,

siendo este un listado a seleccionar
(Campo obligatorio).
Nmero de identificacin,
alfanumrico de 6 caracteres.
Realizar
siguiente
una bsqueda considerando lo
Campos obligatorio del criterio , que

no hayan sido seleccionado, se
mostrar el siguiente mensaje: El
campo XXXX, es obligatorio.
Tabla 15: Prueba de aceptacin Recuperar datos entidad financiera

Id
PER0005
Historia
Tras cumplimentar los tres pasos de la

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

Step by Step
Multilevel Help
Junio 2009
Version 1.1
Verificar que la funcionalidad se encuentra
dividida en tres pasos a cuplimentar, claramente
informados al usuario del sistema
Verificar que en cada uno de los pasos a
cumplimentar, existe un icono de ayuda donde
tras ejecutar el mismo se muestre una ventana
informativa del paso en el que se encuentre
Validar que tras ejecutar las teclas ctrl+z, en el
paso en que se encuentre, se muestre la
respectiva ventana de ayuda del paso.
Tabla 16: Prueba de aceptacin Gestionar situacin familiar
Jos Germn Nez Mori
Page 94 of 237
V. Fase de Elaboracin del Marco gil de Trabajo
Versin 1.0

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

1. Introduccin
Como siguiente paso planteado por el marco gil de trabajo es la ejecucin de la fase de
elaboracin. Es en este capitulo en el que se abordar el desarrollo de la misma.
El marco gil de trabajo, de acuerdo a su planteamiento metodolgico, escrito en el capitulo

Marco gil de trabajo,plantea que se realice para esta fase dos actividades, para cumplir con el
hito de esta fase, que son tanto el prototipo de la arquitectura inicial del sistema, como la
planificacin de esta primera iteracin de fase.
Estas actividades han de ser ejecutadas sobre alguna de las historias de usuarios antes expuestas
(ver capitulo Fase de inicio del marco gil de trabajo), que segn sugiere la metodologa AUP
(Agile Unified Process), deber ser alguna historia o historias que permitan implementar de
manera iterativa la arquitectura del sistema que constituir el ncleo central, donde se mitigan
las cuestiones de alto riesgo [SABL06].
De acuerdo a este enfoque y siguiendo el objetivo del presente trabajo se seleccionar una de las
historias de usuario de las antes expuestas, que represente el ncleo central del sistema, es decir,
una historia de usuario que contemple la gran mayora de requisitos de usabilidad. Donde, la
funcionalidad seleccionada, sirva como estructura base a la implementaciones de las dems
historias de usuario.
Cabe mencionar, que la manera de trabajo ejecutada en esta fase servir como gua para las
iteraciones de desarrollo de la fase de construccin.
2. Desarrollo de la fase de Elaboracin

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

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

Id. Historia
PER001
PER002
PER003
PER005
Descripcin
Relacionar Personas
Persona (alta)
PER004
Prioridad Estimacin
10
9
9
8
Observaciones
Responsable
JGNuez
JGNuez
JGNuez
JGNuez
Esta funcionalidad deber de
empezar a desarrollarse una vez
publicado los servicios de la
JGNuez
Entidaed Financiera
Tabla 17: Product backlog

Podemos apreciar que la tarea de mayor prioridad es la historia: PER001 Relacionar Personas.
Esta historia, por ser de mayor prioridad y por contemplar la gran mayora de requisitos de
usabilidad (ver capitulo Fase de Inicio del marco gil de trabajo), es seleccionada para su
desarrollo en esta primera iteracin.
La herramienta a utilizar, como se comenta, en el capitulo del Planteamiento del marco gil de
trabajo, es la herramienta Sprintometer, donde se registrar como Sprint principal la historia de
usuario seleccionada y como sub-tareas, cada uno de los patrones de usabilidad asociados al
diseo.
Figura 29: Vista de la planificacin en das

En la figura 29, se puede apreciar, el tiempo que durar este Sprint y los das que se consideran
laborables para esta tarea.
Jos Germn Nez Mori
Pgina 98 de 237
Figura 30: Sprint y tareas de la primera Iteracin en Spritometer

En la figura 30, se muestra la planificacin de esta primera iteracin en la herramienta
Sprintometer, donde se ha registrado cada una de las tareas que contemplar este Sprint, las
horas de duracin de las mismas y el responsable de su ejecucin. A continuacin se muestra a
ms detalle esta planificacin (tabla 18), obtenida como reporte de Sprintometer.
Jos Germn Nez Mori
Pgina 99 de 237
Tabla 18: Planificacin del Sprint Relacionar Personas

Como se puede apreciar en la tabla 18, se muestra ya en detalle cada una de las tareas y subtareas necesarias, para cumplir con el objetivo de esta primera iteracin. Tambin se puede
Jos Germn Nez Mori
Pgina 100 de 237
apreciar en esta planificacin, que cada uno los patrones de usabilidad han sido considerados
como tareas, los cuales a su vez se han dividido en tareas pequeas, que en conjunto permitirn
la integracin de un patrn de usabilidad determinado al diseo de la funcionalidad en curso.
Con la planificacin presentada, se pretende cumplir con el desarrollo del hito de Prototipo de
Arquitectura. De acuerdo a esto, en la siguiente seccin, se seguir con lo planificado,
desarrollando as, cada una de las tareas pactadas en este Sprint.
2.2 Prototipo de Arquitectura

En la presente seccin, se presentar el desarrollo de cada unas de las tareas necesarias para el
desarrollo del prototipo de la arquitectura, haciendo uso del Framework AndroMDA.
Como se puede apreciar en la tabla 18, como primera tarea de planificacin se encuentra la
implementacin de la funcionalidad en si (Relacionar Personas), esto debido, a que es una
estrategia a seguir para el desarrollo de este prototipo de arquitectura.
La estrategia, consiste en implementar todo lo necesario a la funcionalidad en si misma y luego

ir integrando cada uno de los patrones de usabilidad asociados.
A continuacin se describe, el desarrollo de cada una de las tareas especificadas en la

planificacin del Sprint (ver tabla 18 - Planificacin del Sprint Relacionar personas).
2.2.1 Tarea de Implementacin de la Funcionalidad

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

A continuacin se presenta el modelado de las entidades de datos necesarias en esta
funcionalidad.
Jos Germn Nez Mori
Pgina 102 de 237
Figura 31: Modelo de entidades de la capa de datos

Este diseo, representa el modelo entidad relacin, que deber ser persistido en la base de datos
seleccionada a modo de tablas de la misma.
2.2.1.2 Diseo de la capa de negocio

En esta seccin se presenta el diseo correspondiente a la capa de negocio, que consiste, en una
serie de componentes del tipo servicio, que contendrn las operaciones necesarias del ncleo de
esta funcionalidad.
Figura 32: Modelado de la capa de negocio
Jos Germn Nez Mori
Pgina 103 de 237
Todos estos servicios, contienen la lgica necesaria de la operativa asociada a la funcionalidad

de Relacionar Personas. Esta capa de negocio, deber de reflejar tambin que entidades de datos
son involucradas en las operaciones de cada uno de estos servicios, por tal motivo, a
continuacin se muestra este diseo:
Figura 33: Dependencias de servicios con las entidades de datos
2.2.1.3 Diseo de la capa de presentacin

En esta seccin se presenta, los diseos asociados a la capa de presentacin, mostrando as, las
transiciones y estados de accin en esta capa, ante una peticin de usuario y su respectiva
respuesta.
Figura 34: Caso de uso asociado a la funcionalidad de Relacionar Personas

Jos Germn Nez Mori
Pgina 104 de 237
En el modelado planteado por AndroMDA (ver capitulo Marco gil de trabajo), un caso de uso
representar una funcionalidad especifica del sistema y para dar a entender esto en el momento
de la generacin de cdigo se estereotipa al caso de uso con: FrontEndUseCase.
Figura 35: Modelado de la clase controladora

Como se puede apreciar en la figura 35, se muestra el componente controlador con las
operaciones que darn soporte a las peticiones de los usuarios. Tambin, se aprecia en esta
figura, las dependencias de la clase controladora con los componentes de la capa de negocio,
reflejando de esta manera que las operaciones de esta clase harn uso del ncleo de esta
funcionalidad para procesar las peticiones.
Jos Germn Nez Mori
Pgina 105 de 237
Figura 36: Diagrama de actividad asociado a la capa de presentacin

En la figura 36, se presenta las transiciones y cambios de estado que tendr la pgina Web
asociada a esta funcionalidad. Adems como se puede apreciar en la columna de sistema se
encuentran estados de accin relacionados con las operaciones de la clase controladora (ver
figura 9 Modelado de la clase controladora).
2.2.1.4 Resultado de Tarea

A continuacin, se presenta los resultados tras la implementacin de cada uno de los diseos,
asociados a la funcionalidad de Relacionar Personas.
Estos resultados, consisten en presentar cada una de las pantallas de la aplicacin, generadas en
base a AndroMDA y detallar brevemente el funcionamiento de las mismas.
Jos Germn Nez Mori
Pgina 106 de 237
Figura 37: Bsqueda de personas Pgina principal de la aplicacin

En la figura 37, se muestra la pantalla principal de la aplicacin, que si bien es cierto no es la
funcionalidad que se esta tratando, es necesario presentarla, por ser una pantalla que permite el
acceso a la funcionalidad de Relacionar Personas.
La funcionalidad de Bsqueda de personas, se resume, en que permite la bsqueda de una

persona por medio de su cdigo de persona o en todo caso listar todas las personas registradas
en el sistema (ver figura 37 Bsqueda de personas Pgina principal de la aplicacin).
Figura 38: Relacionar Personas Criterio de seleccin de personas a relacionar
Jos Germn Nez Mori
Pgina 107 de 237
Figura 39: Relacionar Personas Adicin de relaciones a la persona seleccionada

En la figura 38, se presenta la pantalla relacionada a la funcionalidad de Relacionar Personas,
mostrando en esta figura, los criterios necesarios para adicionar una relacin a la persona
seleccionada. Es de acuerdo a esta seleccin, que se adicionar relaciones a una persona
determinada.
Ya en la figura 39, se puede apreciar, la adicin de una persona al listado de relaciones de la

persona seleccionada.
Una vez presentado los resultados de esta primera tarea, se actualizar el Sprint con los avances
realizados en esta tarea:
Tabla 20: Actualizacin de la planificacin de la tarea de implementacin de la funcionalidad
Jos Germn Nez Mori
Pgina 108 de 237
2.2.2 Integracin del patrn de usabilidad Warning

Es esta seccin, se presenta la integracin del patrn de usabilidad Warning, a la funcionalidad
de Relacionar Personas. Para mas detalle de este patrn ver anexo 01 (Especificacin Patrn
de usabilidad Warning).
Como se ha comentado en captulos anteriores, los patrones de usabilidad, se tomarn en cuenta

desde el tiempo de diseo, por tal motivo, en esta seccin, se detalla cada uno de los niveles o
capas, en las cuales ser necesario adicionar nuevos componentes u operaciones que harn
posible la integracin de este patrn de usabilidad.
Siguiendo lo planteado por el presente Sprint, la tarea de integracin del patrn de usabilidad
Warning, presenta la siguiente planificacin, mostrada en la tabla 21:
Tabla 21: Planificacin inicial de la tarea de integracin del patrn de usabilidad Warning
Como se pude apreciar en la tabla 21, se presentan las sub-tareas asociadas a esta integracin,
las cuales son la continuacin de la tarea de implementacin de la funcionalidad (ver tabla 20Actualizacin de la planificacin de la tarea de implementacin de la funcionalidad).
Para la integracin de este patrn de usabilidad, al diseo de la funcionalidad de Relacionar
Personas, el presente trabajo, tomara como base lo especificado en la gua del patrn de
usabilidad Warning (ver anexo 01 Especificacin Patrn de usabilidad Warning). De esta gua,
se toma los siguientes diagramas base para la integracin:
Jos Germn Nez Mori
Pgina 109 de 237
Figura 40 Diagrama de clases de la especificacin del patrn de usabilidad Warning
Figura 41: Diagrama de secuencia de la especificacin del patrn de usabilidad Warning

Es en base a estos diagramas, tanto de clases como de secuencia (ver figura 40 y 41), se
realizar modificaciones tanto en el diseo de las capas, como en la implementacin del sistema.
Jos Germn Nez Mori
Pgina 110 de 237
A continuacin, se detallan las modificaciones en las capas o niveles implicados y los

resultados de la misma.
2.2.2.1 Integracin del patrn de usabilidad Warning en la capa de

presentacin y capa de negocio
Para la integracin del patrn de usabilidad Warning en estas capas (presentacin y negocio), se
ha
adicionado
dos
nuevos
componentes
de
tipo
servicio
(RelacionSession
RelacionesWrapperService), quedando el diseo de la siguiente manera:
Figura 42: Modelado de la clase controladora con el Patrn de usabilidad Warning
Estos dos nuevos componentes (RelacionSession y RelacionesWrapperService), harn de

componentes intermedios entre la capa de presentacin y la capa de negocio (ver figura 42),
buscando de esta manera, seguir con la especificacin del patrn de usabilidad Warning,
especficamente, en lo planteado en su diagrama de clases (ver figura 40 Diagrama de clases
de la especificacin del patrn de usabilidad Warning).
Con el objetivo, de presentar mayor claridad en la integracin de este patrn de usabilidad, al

diseo de estas capas, a continuacin, se detalla la correspondencia de cada uno de los
componentes nuevos (ver figura 42), contra la especificacin del patrn de usabilidad Warning
(ver figura 40):
Jos Germn Nez Mori
Pgina 111 de 237
Componentes del P.U. Warning
Componentes de diseo en la funcionalidad
View
RelacionarPerController
Controller
DomainClassWrapper
RelacionesWrapperService
DomainClass
RelacionesService
RelacionSession
Tabla 22: Correspondencia de componentes del patrn de usabilidad Warning y los
componentes de la funcionalidad
Como se aprecia en la figura 42 (Modelado de la clase controladora con el Patrn de usabilidad

Warning), el componente RelacionesWrapperService, es una componente imagen, del
componente RelacionesService, es decir, que tiene las mismas operaciones que este componente.
Esta imagen de operaciones, har la labor de capa intermedia entre la capa de negocio y la de
presentacin, permitiendo de esta manera, validar aquellas operaciones que necesitan de
confirmacin del usuario antes de persistir los datos.
2.2.2.2 Flujo de trabajo segn el patrn de usabilidad Warning

En esta seccin, se explicar brevemente, la interaccin de los componentes diseados, para la
integracin del patrn de usabilidad Warning a la funcionalidad de Relacionar Personas, y
cuya secuencia, dar a entender el flujo de trabajo de este patrn, tanto a nivel de diseo como
de implementacin. Todo esto, tomando como base el diagrama de secuencias de la
especificacin del patrn (ver Figura 41- Diagrama de secuencia de la especificacin del patrn
de usabilidad Warning)
A continuacin, el detalle de este flujo de trabajo, donde para tener relacin de los componentes
que se describen, se podr revisar la figura 42 (Modelado de la clase controladora con el Patrn
de usabilidad Warning):
Una vez realizada la peticin de adicionar una nueva relacin, la clase controladora
(RelacionarPerController), recibe los datos necesarios para el procesamiento y verifica si el
flujo de trabajo necesita de una confirmacin del usuario.
La validacin, si el flujo necesita de una confirmacin de usuario, se hace contra el

componente RelacionesWrapperService, y su operacin checkOK, donde a esta
operacin, se pasa como parmetro el nombre del mtodo u operacin, que se necesita
validar. En este caso en concreto, se pasa como parmetro el mtodo nuevaRelacion.
La operacin checkOK, del componente RelacionesWrapperService, valida si el
Jos Germn Nez Mori
Pgina 112 de 237
mtodo nuevaRelacion, necesita de confirmacin del usuario, de ser as, responde a la

peticin con el valor del flag de control de este mtodo.
En la clase controladora (RelacionarPerController), si la operacin chekOK del

componente RelacionesWrapperService, retorna un valor falso, significa que se necesita
de confirmacin del usuario y se debe pedir esto a la vista.
Con el objetivo de mostrar un alerta de confirmacin en la pginas Web, la clase

controladora (RelacionarPerController) setea valores necesarios para este comportamiento
en el objeto de sesin RelacionSession.
Una vez confirmado esta operacin, por medio del usuario, esta peticin es enviada a la
clase
controladora
(RelacionarPerController),
la
cual,
solicita
al
componente
RelacionesWrapperService, que actualice el estado de confirmacin, para el mtodo

nuevaRelacion.
Actualizado el estado de confirmacin del mtodo nuevaRelacion, la clase controladora

enva los datos recogidos de la vista, para su procesamiento por medio de la operacin
nuevaRelacion del componente RelacionesWrapperService, el cual, verifica nuevamente
si el flag de confirmacin de la operacin nuevaRelacion, esta a verdadero, de ser as,
enva los datos para su persistencia por medio del componente RelacionesService.
2.2.2.3 Resultados de la Integracin del patrn de usabilidad Warning

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

de la planificacin respectiva a esta tarea de integracin del patrn de usabilidad Warning:
Tabla 23- Planificacin actualizada de la tarea de integracin del patrn de usabilidad

Warning
2.2.3 Integracin del patrn de usabilidad System Status Feedback

En la presente seccin, se detallar cada uno de los pasos seguidos para la integracin del patrn
de usabilidad System Status Feedback. En adelante haremos referencia a este patrn como SSF.
Para mas detalle de este patrn ver anexo 02 (Especificacin del Patrn de Usabilidad System
Status feedback).
Esta Integracin del patrn de usabilidad SSF, se realizar tanto en el diseo como en la
implementacin de la funcionalidad Relacionar Personas.
A continuacin, se presenta la planificacin inicial de esta tarea de integracin del patrn de

usabilidad SSF:
Tabla 24: Planificacin inicial de la tarea de integracin del patrn de usabilidad SSF
Siguiendo lo especificacin del patrn de usabilidad SSF (ver anexo 02 - Especificacin Patrn
Jos Germn Nez Mori
Pgina 115 de 237
de Usabilidad System Status feedback), la integracin de este patrn a la funcionalidad de

Relacionar Personas, tomara en cuenta como diseos base lo siguiente:
Figura 45: Diagrama de clases de la especificacin del patrn de usabilidad SSF
Figura 46: Diagrama de secuencia de la especificacin del patrn de usabilidad SSF
Jos Germn Nez Mori
Pgina 116 de 237
2.2.3.1 Integracin del patrn de usabilidad SSF a la capa de

La integracin de este patrn de usabilidad, en la capa de presentacin, solo presenta cambios a
nivel de la clase controladora de la funcionalidad (RelacionarPerController) y de su dependencia
hacia el componente de tipo servicio de la capa de negocio (RelacionesService).
Para esta integracin se adicionan 4 nuevos componente que interactuarn entre la capa de
negocio y la capa de presentacin, estos componentes son: AdministradorEstados,
EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService. De acuerdo a esto el
diseo de la funcionalidad de Relacionar Personas, queda de la siguiente manera:
Figura 47: Integracin del patrn de usabilidad SSF en el diseo de la funcionalidad

Relacionar Personas
Como se describe al inicio de esta seccin, la integracin de este patrn de usabilidad SSF a la
funcionalidad de Relacionar Personas, se basa en ciertos diseos de la especificacin de este
patrn (ver anexo 02 - Especificacin Patrn de Usabilidad System Status feedback).
De acuerdo esto, y buscando entender los detalles de esta integracin, se presenta una tabla
(tabla 25) de correspondencias entre componentes de diseo de la especificacin de este patrn
(ver figura 46) y el diseo de la integracin a la funcionalidad en curso (ver figura 48):
Jos Germn Nez Mori
Pgina 117 de 237
Componentes del P.U. SSF
View
Controller
StatusManager
AdministradorEstados
ConcreteStatus
EstadoErrorService
ConcreteStatus
EstadoExitoService
ConcreteStatus
EstadoAdvertenciaService
DomainClass
RelacionesService
Tabla 25: Correspondencia de componentes del patrn de usabilidad SSF y los componentes de
la funcionalidad
Estos nuevos componentes de la integracin de este patrn de usabilidad (ver figura 19),
gestionarn los estados, ante la operativa de Adicin de una nueva Relacin, permitiendo de
esta manera, mantener informado al usuario ante cualquier cambio de estado, relacionado con la
operativa en curso.
2.2.3.2 Flujo de trabajo segn el patrn de usabilidad SSF

Con el objetivo de dar un mayor detalle de la integracin del patrn de usabilidad SSF, en la
presente seccin, se describir brevemente el flujo de trabajo, de la operativa de Adicin de
una nueva relacin, tomando en cuenta que en esta operativa ya se encuentra integrado este
patrn de usabilidad.
El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la
especificacin de este patrn (ver figura 47).
que se describen, se podr revisar la figura 48 (Integracin del patrn de usabilidad SSF en el
diseo de la funcionalidad Relacionar Personas):
Ante la peticin de adicionar una nueva relacin a la persona seleccionada, la clase

controladora recibe los datos de la vista, los cuales los procesa y enva estos para su
persistencia a la capa de negocio, pasando respectivamente, por los componentes del patrn
de usabilidad Warning (ver seccin 2.2.2 del presente capitulo).
En la capa de negocio, el componente responsable de ejecutar esta operativa, es el

componente RelacionesService, con su operacin nuevaRelacion.
Jos Germn Nez Mori
Pgina 118 de 237
La operacin nuevaRelacion, recibir los datos necesarios y proceder a persistirlos por

medio de la capa de datos. Es en esta operativa, que se implementa controles de estado, es
decir, se validar, si la operacin de persistir los datos, se realiza de manera satisfactoria,
con error u otros estados.
Esta operacin de nuevaRelacion, ante cualquiera de estas validaciones, informar de las

mismas a su observador, que en este caso, es el componente AdministradorEstados.
El componente AdministradorEstados, recibir del componente RelacionesService, la

notificacin de que se ha producido un cambio de estado. Esta notificacin, vendr
acompaada de los datos necesarios de este cambio de estado, que permitirn a este
componente por medio de su operacin determinarEstado, discernir el cambio de estado
que se ha producido en la capa de negocio.
Una vez determinado, el tipo de estado que se ha producido en la capa de negocio, este
componente administrador (AdministradorEstados), enviar la informacin para su
tratamiento al componente respectivo, es decir, si se ha producido un error se enviar los
datos necesarios al componente EstadoErrorService.
La clase controladora RelacionarPerController, una vez que enva los datos para su
persistencia a la capa de negocio, consultar a cada uno de los componentes de gestin de
estados (EstadoErrorService, EstadoExitoService, EstadoAdvertenciaService), si se ha
producido algn cambio de estado en la operativa en curso (Adicin de una relacin).
De haberse producido algn cambio de estado, la clase controladora, recoger los datos
necesarios del componente de gestin de estados respectivo y proceder a informar de esto a
la vista, por medio de mecanismos del Framework Struts utilizado en la capa de
presentacin.
2.2.3.3 Resultados de la integracin del patrn de usabilidad SSF

En esta seccin, se presentar los resultados tras la integracin del patrn de usabilidad SSF a la
funcionalidad de Relacionar Personas. Estos resultados permitirn ilustrar lo que se menciona
en la seccin de flujo de trabajo. Adems se presentar la planificacin actualizada de esta tarea.
Ante el evento de adicin de una nueva relacin, si la adicin se realiza satisfactoriamente el

sistema informar al usuario de esto, en la zona de estados, ver la siguiente figura:
Jos Germn Nez Mori
Pgina 119 de 237
Figura 48: Resultados tras la adicin satisfactoria de una nueva relacin

Si, ante el evento de adicin de una nueva relacin, se produce algn error, como por ejemplo:
falta de recursos para realizar la operativa, error acceso a base datos, etc. El sistema notificar al
usuario de este error en la zona de estados (Final de la pgina Wb), ver la siguiente figura:
Figura 49: Resultados de error tras la adicin de una nueva relacin

A continuacin se muestra la planificacin actualizada de la tarea de integracin del patrn de
Jos Germn Nez Mori
Pgina 120 de 237
usabilidad SSF:
Tabla 26: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SSF
2.2.4 Integracin del patrn de usabilidad Global Undo

En la presente seccin, se detalla cada uno de los pasos seguidos para la integracin del patrn
Global Undo (en adelante GU), a la funcionalidad de Relacionar Personas. Para mas detalle
de este patrn ver el anexo 03 (Especificacin del Patrn de Usabilidad Global Undo).
Siguiendo la dinmica de las anteriores integraciones, a continuacin se presenta la

planificacin inicial de la tarea de integracin del patrn de usabilidad GU:
Tabla 27: Planificacin inicial de la tarea de integracin del patrn de usabilidad GU

Esta seccin, tomara como base para esta integracin, la especificacin de este patrn de
usabilidad (ver anexo 03 - Especificacin del Patrn de Usabilidad Global Undo), usando
ciertos diseos como punto de partida para esta labor. A continuacin se presenta los diseos
base de este patrn de usabilidad:
Jos Germn Nez Mori
Pgina 121 de 237
Figura 50: Diagrama de clases de la especificacin del patrn de usabilidad GU
Figura 51: Diagrama de secuencias de la especificacin del patrn de usabilidad GU
2.2.4.1 Integracin del patrn de usabilidad GU a la capa de

Jos Germn Nez Mori
Pgina 122 de 237
La integracin de este patrn de usabilidad, ha implicado la creacin de un nuevo componente

de tipo servicio (RelacionesHistorySessin), que dar soporte a las tareas que requiere este
patrn de usabilidad. Adems, se adiciona una nueva operacin undoRelaciones, tanto, en la
clase controladora (RelacionesPerController), como en el componente de servicio de la capa de
negocio (RelacionesService). Estas modificaciones, permitirn atender a las peticiones de los
usuarios, ante el evento de deshacer (Undo) de la operacin en curso.
Segn esta premisa, el diseo queda la siguiente manera:
Figura 52: Integracin del patrn de usabilidad GU en la capa de negocio y capa de diseo
Adicional a estos cambios, se modifica tambin el flujo de actividades de la pgina Web, de la
funcionalidad en curso. Con estos modificaciones en el flujo de actividad, se busca adicionar un
nuevo evento a la misma, que haga referencia a la operativa de deshacer (Undo) y que esta tenga
su operacin de soporte en el lado del sistema, es decir, una operacin en su clase controladora
relacionada (ver figura 53). De acuerdo a esto el diagrama de actividades de la pgina Web
queda de la siguiente manera:
Jos Germn Nez Mori
Pgina 123 de 237
Figura 53: Integracin del patrn de usabilidad GU en el diagrama de actividades de la pgina

de Adicin de relaciones
Cada una de estas modificaciones siguen lo especificado por este patrn (Ve Figura 52). Por tal
motivo, a continuacin se presenta un cuadro con las correspondencias de componentes
especificados y lo diseado en la integracin (ver Figura 54):
Componentes del P.U. GU
View
Controller
HistoryList
RelacionesHistorySessin
Command
RelacionesServiceBase
ConcreteCommand
RelacionesService
DomainClass
Relacion
HistoryException
Tabla 28: Correspondencia de componentes del patrn de usabilidad GU y los componentes de

la funcionalidad
Como se pude ver en tabla 28, existe un componente de la especificacin (HistoryException),
que no tiene correspondencia en el diseo de la integracin, esto se debe a que este componente
ya se encuentra gestionado por uno de los Framework que utiliza el marco gil de trabajo
(Spring).
Jos Germn Nez Mori
Pgina 124 de 237
2.2.4.2 Flujo de trabajo segn el patrn de usabilidad GU

Con el objetivo de dar un mayor detalle de la integracin del patrn de usabilidad GU, en la
presente seccin, se describir brevemente el flujo de trabajo, de la operativa de Adicin de
una nueva relacin, tomando en cuenta que en esta operativa ya se encuentra integrado este
patrn de usabilidad.
El detalle de este flujo, tiene como base el diagrama de secuencias planteado por la
especificacin de este patrn (ver figura 53).
De acuerdo a esto, a continuacin, se presenta el detalle de este flujo de trabajo, donde para
tener relacin de los componentes que se describen, se podr revisar la figura 54 (Integracin
del patrn de usabilidad GU en la capa de negocio y capa de diseo):
Detalle del flujo ante el evento de adicin de una nueva relacin:
Cuando la peticin de adicin de una nueva relacin, llega a la clase controladora

(RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda
esta informacin para ser enviado para su persistencia a la capa de negocio.
De este objeto que se enva a la capa de negocio, su referencia ser guardada por el
componente: RelacionesHistorySessin, con lo cual se estara clonando el comando que
se esta ejecutando (Adicin de una nueva relacin).
Detalle del flujo ante el evento de deshacer (Undo), las nuevas relaciones:
Cuando la peticin de deshacer, llega a la clase controladora (RelacionarPerController), esta

recupera todos los objetos clonados en el componente RelacionesHistorySessin, que han
sido guardados en el transcurso de la operativa de adicin de nuevas relaciones.
Con este listado de objetos clonados, la clase controladora realiza una peticin de deshacer
las relaciones asociadas a estos objetos. Esta peticin se ejecuta contra la operacin
undoRelaciones del componente de la capa de negocio RelacionesService.
La operacin undoRelaciones, recibe como parmetro, un listado de objetos del tipo

Relacin, y solicita por cada objeto a la capa de datos, que elimine el registro persistido en
Base de datos.
Jos Germn Nez Mori
Pgina 125 de 237
2.2.4.3 Resultados de la integracin del patrn de usabilidad GU

Con el objetivo de ilustrar lo descrito en la anterior seccin, a continuacin se presenta los
resultados a nivel de pginas Web.
Se adiciona dos nuevas relaciones a la persona seleccionada (PER005, PER006), ver la

siguiente figura:
Figura 54: Adicin de nuevas relaciones considerando el patrn GU

Como se describe en la anterior seccin, por cada adicin de una nueva relacin se realiza una
clonacin del objeto que se esta adicionando, de tal manera que cuando el usuario realice la
peticin de deshacer esta operativa, se recupere estos objetos clonados y se solicite de que se
elimine de Base de datos. De acuerdo a esto, esta pantalla quedara de la siguiente manera tras el
evento de deshacer (Undo):
Jos Germn Nez Mori
Pgina 126 de 237
Figura 55: La adicin de relaciones tras en el evento de deshacer (Undo)

A continuacin, se presenta la actualizacin de la planificacin asociada a la integracin de este
patrn de usabilidad:
Tabla 29: Planificacin actualizada de la tarea de integracin del patrn de usabilidad GU
2.2.5 Integracin del patrn de usabilidad Abort Operation

En esta seccin, se detallar los pasos seguidos para la integracin del patrn de usabilidad
Abort Operation a la funcionalidad de Relacionar personas. Para esta integracin, el presente
trabajo se ha basado en la especificacin del patrn Abort (ver anexo 04 Especificacin del
patrn de usabilidad Abort).
Jos Germn Nez Mori
Pgina 127 de 237
El patrn Abort Operation, en adelante AO, pertenece a la familia del patrn de usabilidad
Abort, siendo este patrn AO, una rama especifica, es decir, una especificacin concreta para
ciertas tareas de usabilidad, que en este caso puntual, es aplicar este patrn para cancelar una
operacin en curso.
Este patrn de usabilidad AO, basa mucho su planteamiento en el patrn de usabilidad Global
Undo (detallado en la anterior seccin 2.2.4 del presente capitulo), es por este motivo, que la
integracin de este patrn tomar como base el diseo y la implementacin del patrn Global
Undo.
Siguiendo la especificacin del patrn de usabilidad AO (ver anexo 04 Especificacin del

patrn de usabilidad Abort), se tomar como referencia para la integracin, los siguientes
modelos base:
Figura 56: Diagrama de clases de la especificacin del patrn de usabilidad AO
Jos Germn Nez Mori
Pgina 128 de 237
Figura 57: Diagrama de secuencia de la especificacin del patrn de usabilidad AO

Como se puede apreciar en las anteriores figuras (figura 59 y 60), la estructura del
planteamiento de este patrn es casi similar a lo planteado por el patrn de usabilidad Global
Undo (ver figuras 52 y 33), variando especficamente en el flujo de actividades tras el evento de
cancelar una operacin.
A continuacin, se presenta la planificacin inicial de la tarea de integracin del patrn de

usabilidad AO a la funcionalidad en curso:
Tabla 30: Planificacin inicial de la tarea de integracin del patrn de usabilidad AO
2.2.5.1 Integracin del patrn de usabilidad AO a la capa de

La integracin de esta patrn, ha implicado la creacin de una nueva operacin en la clase
controladora (RelacionesPerController), esta operacin es: cancelarRelaciones, la cual
Jos Germn Nez Mori
Pgina 129 de 237
permitir atender las peticiones de los usuarios ante el evento de cancelar la operacin en curso
(adicionar una nueva relacin).
Esta integracin, utiliza un componente ya creado en la integracin del patrn de usabilidad

Global Undo, llamado RelacionesHistorySession, que tendr la misma utilidad que en este
patrn, es decir, clonar objetos de la operativa de adicionar nuevas relaciones.
De acuerdo esto el diseo queda de la siguiente manera:
Figura 58: Integracin del patrn de usabilidad AO en la capa de negocio y capa de

presentacin
Adicional a la operacin nueva en la clase controladora, se modifica las actividades asociadas a
la pagina Web, que soporta la funcionalidad de Relacionar Personas. Estas modificaciones,
consisten en adicionar el nuevo evento de Cancelar y su respectivo estado de accin en el lado
del sistema, es decir, la referencia a la nueva operacin (cancelarRelaciones) de la clase
controladora.
Este nuevo flujo, que hace referencia al evento de Cancelar, deber indicar, que una vez
ejecutado esta operativa, se debe de regresar al home de la aplicacin, es decir, a la pgina de
bsqueda de personas. Por tal motivo, este flujo deber de tener un estado de fin, que haga
referencia a la funcionalidad de Bsqueda de Personas.
Segn estas premisas el diseo de actividades asociadas a la pgina de Adicin de una nueva
relacin, queda de la siguiente manera:
Jos Germn Nez Mori
Pgina 130 de 237
Figura 59: Integracin del patrn de usabilidad AO en el diagrama de actividades de la pgina

de Adicin de relaciones
La modificaciones necesarias para esta integracin, han seguido lo planteado por el patrn AO
(ver figura 59), por tal motivo, se presenta a continuacin una tabla de correspondencias de
componentes, tanto de la especificacin, como de la integracin (ver figura 61):
Componentes del P.U. AO
View
Controller
HistoryList
RelacionesHistorySessin
Command
ConcreteCommand
RelacionesService
DomainClass
Relacion
HistoryException
ProgressIndicator
Tabla 31: Correspondencia de componentes del patrn de usabilidad AO y los componentes de

la integracin
Jos Germn Nez Mori
Pgina 131 de 237
Como se pude ver en tabla 31 (Correspondencia de componentes del patrn de usabilidad AO y

los componentes de la funcionalidad), existe dos componentes que no tienen correspondencia en
la integracin, esto se debe, a que uno de ellos (HistoryException) es gestionado por el unos de
los Framework utilizados por el marco gil de trabajo y el otro (ProgressIndicator), ser tratado
mas adelante como una integracin adicional
2.2.5.2 Flujo de trabajo segn el patrn de usabilidad AO

A continuacin, se explicar brevemente, la interaccin de los componentes diseados, para la
integracin del patrn de usabilidad AO a la funcionalidad de Relacionar Personas, y cuya
secuencia, dar a entender el flujo de trabajo de este patrn, tanto a nivel de diseo como de
implementacin. Todo esto, tomando como base el diagrama de secuencia de la especificacin
del patrn (ver Figura 60).
que se describen, se podr revisar la figura 61 (Integracin del patrn de usabilidad AO en la
capa de negocio y capa de presentacin):
Detalle del flujo ante el evento de adicin de una nueva relacin:
Cuando la peticin de adicin de una nueva relacin, llega a la clase controladora

(RelacionarPerController), esta recibe los datos necesarios y prepara un objeto, con toda
esta informacin para ser enviado para su persistencia a la capa de negocio.
De este objeto que se enva a la capa de negocio, su referencia ser guardada por el
componente: RelacionesHistorySessin, con lo cual se estara clonando el comando que
se esta ejecutando (Adicin de una nueva relacin).
Detalle del flujo ante el evento de Cancelar la operativa de nuevas relaciones:
Cuando la peticin de cancelar, llega a la clase controladora (RelacionarPerController), esta

recupera todos los objetos clonados en el componente RelacionesHistorySessin, que han
sido guardados en el transcurso de la operativa de adicin de nuevas relaciones.
Con este listado de objetos clonados, la clase controladora realiza una peticin de deshacer
las relaciones asociadas a estos objetos. Esta peticin, se ejecuta sobre la operacin
undoRelaciones del componente de la capa de negocio RelacionesService.
La operacin undoRelaciones, recibe como parmetro, un listado de objetos del tipo
Jos Germn Nez Mori
Pgina 132 de 237
Relacin, y solicita por cada una de ellos, se elimine su registro persistido en Base de datos.
Una vez terminada, la operativa de eliminar los registros asociados a la clonacin, la clase
controladora (RelacionarPerController), redirecciona la response hacia la funcionalidad de
Bsqueda de Personas, que es para esta aplicacin el home de la misma.
2.2.5.3 Resultados de la integracin del patrn de usabilidad AO

resultados a nivel de pantallas Web.
Se adiciona una nueva relacin a la persona seleccionada (PER003), ver la siguiente figura:
Figura 60: Adicin de nuevas relaciones considerando el patrn AO
Tras el evento de Cancelar, el sistema, elimina los registros asociados a las ltimas adiciones,
es decir, aquellos que han sido clonados y luego redirige el flujo hacia el home de la aplicacin
(funcionalidad de bsqueda de personas).
Jos Germn Nez Mori
Pgina 133 de 237
Figura 61: Home de la aplicacin tras el evento Cancelar

Si volvemos a consultar las relaciones de la persona, en la cul se ejecuto el evento de
Cancelar, podemos apreciar que la relacin que se adiciono no se encuentra.
Figura 62: Consulta de relaciones tras el evento de cancelar
A continuacin, se presenta la planificacin actualizada de la tarea de integracin del patrn de

usabilidad AO.
Jos Germn Nez Mori
Pgina 134 de 237
Tabla 32: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AO
2.2.6 Integracin del patrn de usabilidad System Progress Feedback

En la siguiente seccin, se detallar la integracin del patrn System Progress Feedback, en
adelante SPF, a la funcionalidad de Relacionar Personas. Para esta integracin, el presente
trabajo se ha basado en la especificacin de este patrn de usabilidad (ver anexo 05
Especificacin del patrn de usabilidad System Progress Feedback).
De acuerdo, a la especificacin de este patrn de usabilidad, se tomar como punto de partida

para esta integracin, los siguientes modelos:
Figura 63: Diagrama de clases de la especificacin del patrn de usabilidad SPF
Jos Germn Nez Mori
Pgina 135 de 237
Figura 64: Diagrama de secuencia de la especificacin del patrn de usabilidad SPF

Siguiendo la dinmica de las dems patrones ya integrados a la funcionalidad de Relacionar
Personas, a continuacin se presenta la planificacin inicial de las tareas asociadas a la
integracin de este patrn de usabilidad:
Tabla 33: Planificacin inicial de la tarea de integracin del patrn de usabilidad SPF
2.2.6.1 Integracin del patrn de usabilidad SPF a la capa de

Cabe mencionar, antes de iniciar con el detalle de esta integracin, que este patrn de usabilidad
SPF, no fue considerado como parte de los requisitos de usabilidad asociados a la historia de
Jos Germn Nez Mori
Pgina 136 de 237
usuario Relacionar Personas (ver capitulo de Fase de inicio del marco gil de trabajo). Debido,
a que estamos en una iteracin que tiene como objetivo, construir el prototipo de la arquitectura
que mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrn en
la arquitectura inicial.
Esta patrn de usabilidad SPF, ser aplicado, sobre la funcionalidad dada por el patrn de
usabilidad Global Undo (ver seccin 2.2.4 Integracin del patrn de usabilidad Global Undo),
es decir, que ira informando el progreso de la operacin de deshacer (Undo) las adiciones de
nuevas relaciones.
En la integracin de este patrn, se ha diseado un nuevo componente del tipo servicio

(IndicadorProgresoService), que permitir, dar soporte a las tareas requeridas por este patrn de
usabilidad, siendo una de las principales, la de un componente observador, que ira informando
del progreso de determinadas operaciones.
Adicional al nuevo componente diseado para la integracin de este patrn de usabilidad, se

adiciona una nueva operacin en la clase controladora (RelacionarPerController), esta operacin
es: verificarProgreso, que permitir, dar soporte a las peticiones de aquellas funcionalidades,
que requieran que se muestre al usuario algo informativo del progreso de su operativa en curso.
De acuerdo a las modificaciones comentadas lneas arriba, se muestra el diseo tanto de la capa
de negocio como la de presentacin:
Figura 65: Integracin del patrn de usabilidad SPF en la capa de negocio y capa de diseo
Jos Germn Nez Mori
Pgina 137 de 237
Adicional a los cambios en componentes de la capa de negocio y presentacin, se modifica

tambin el flujo de actividades de la pgina Web, de adicin de nuevas relaciones. Con estas
modificaciones en el flujo de actividades, se busca adicionar un nuevo evento a la misma, que
haga referencia a la operativa de Verificar el progreso de un determinado evento y que esta
tenga su operacin de soporte en el lado del sistema, es decir, una operacin en su clase
controladora (ver figura 68).
Este nuevo evento, que se adiciona al flujo de actividades de la pgina Web, no representara un
evento implcito como tal, sino, ms que todo una referencia a una operacin en el lado del
sistema (soportada por la clase controladora), que permitir, ir informando del progreso de un
evento especifico al usuario, que en este caso en concreto, es el evento de deshacer (Undo) de
las nuevas relaciones adicionadas.
De acuerdo a esto, el diagrama de actividades de la pgina Web queda de la siguiente manera:
Figura 66: Integracin del patrn de usabilidad SPF en el diagrama de actividades de la

pgina Web de Adicin de relaciones
Como se describe al inicio de esta seccin, esta integracin se basa en ciertos diseos obtenidos
Jos Germn Nez Mori
Pgina 138 de 237
de la especificacin de este patrn de usabilidad SPF, es as, que la adicin de un nuevo

componente y la creacin de una nueva operacin en la clase controladora (ver figura 68), se
basan en el diseo de clases de esta especificacin (ver figura 66). Segn esto, se presenta a
continuacin una tabla de correspondencias entre componentes, tanto de la especificacin como
de la integracin en si:
Componentes del P.U. SPF
View
Controller
DomainClass
RelacionesService
DomainClass
Relacion
ProgressIndicator
IndicadorProgresoService
Monitor
SetInterval (Funcin javaScript asociada a las

pgina JSP)
Tabla 34: Correspondencia de componentes del patrn de usabilidad SPF y los componentes de
la Integracin
Como se puede apreciar en la tabla 34, existe un componente de la especificacin, llamado

Monitor, que tiene su correspondencia en una funcin javaScript en la integracin, esto se debe,
a que en la implementacin se har uso de este lenguaje y que una de las funciones propias de
este lenguaje, como es el setInterval, simular las tareas asociadas a este componente Monitor.
2.2.6.2 Flujo de trabajo segn el patrn de usabilidad SPF
En esta seccin, se detalla las actividades asociadas a la funcionalidad de Adicionar relaciones,

teniendo en cuenta que para esta operativa, se tiene integrado el patrn de usabilidad SPF.
Este flujo de trabajo, es una secuencia de actividades que se expone en esta seccin, con el
objetivo, de proporcionar un mayor detalle del funcionamiento de este patrn de usabilidad SPF,
integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la
especificacin de este patrn de usabilidad, especficamente, en su diagrama de secuencia (ver
figura 67).
que se describen, se podr revisar la figura 68 (Integracin del patrn de usabilidad SPF en la
capa de negocio y capa de diseo):
Jos Germn Nez Mori
Pgina 139 de 237
Solicitada la peticin de deshacer las nuevas relaciones adicionadas (Undo), la vista enviar
dicha peticin para ser resuelta en su controlador relacionado (RelacionarPerController) y a
su vez, esta peticin activar un timer en el objeto de monitorizacin, que pasado un
determinado tiempo, ejecutar determinadas acciones.
Este objeto de monitorizacin es simulado por la funcin JavaScript "setInterval", la cual

residir en la pgina Web asociada a la funcionalidad en curso, es decir, en lado del cliente.
Una vez sobrepasado, el tiempo mnimo de 2 segundos en el timer del objeto de

monitorizacin, este verificar si la peticin, de deshacer las nuevas relaciones adicionadas,
ha culminado, de ser as, mostrara los resultados respectivos en pantalla.
En el caso de que no se haya culminado la peticin, de deshacer las nuevas relaciones

adicionadas, el objeto de monitorizacin, lanzar una peticin paralela (simulacin de hilo
paralelo al principal), para verificar el progreso de esta operacin de deshacer (Undo).
El objeto encargado de simular este hilo paralelo, es el objeto XMLHttpRequest, el cual es

un objeto, de la tecnologa asncrona Ajax. Este objeto, presenta un esquema de trabajo que
se asemeja a lo especificado en el diagrama de secuencia, de la especificacin del patrn de
usabilidad SPF (ver figura 67), por tal motivo a continuacin se muestra el esquema de
trabajo de este objeto [SUNPB05]:
Figura 67: Esquema de trabajo del objeto XMLHttpRequest
El objeto XMLHttpRequest, enviar una peticin cada un segundo al controlador asociado

(RelacionarPerController), en su operacin "verificarProgreso". Esta operacin, solicitar la
Jos Germn Nez Mori
Pgina 140 de 237
informacin del progreso de la operativa de deshacer (Undo) al componente

IndicadorProgresoService y su operacin verificarProgreso.
Bien sabemos, que el servicio RelacionesService, es el encargado de deshacer las

relaciones adicionadas por medio de su operacin undoRelaciones.
Esta operacin undoRelaciones, recibir como parmetro un listado de las relaciones que
deber de solicitar a la capa de datos que se elimine de base de datos, donde, por cada
relacin eliminada deber de contabilizarse el progreso que lleva respecto al total de
relaciones a eliminar, he informar de esto a los escuchadores suscritos.
La manera de contabilizar el progreso de la relaciones a eliminar, consiste en que, por cada

relacin eliminada, se contabilice todas la relaciones eliminadas y se divida entre el total de
relaciones a eliminar y para obtener el porcentaje de progreso se multiplique por cien. Es
este porcentaje que se informa a los escuchadores.
El escuchador de progreso, suscrito al componente RelacionesService, es el componente

IndicadorProgresoService y cada vez que el componente escuchado, enve informacin de
progreso, este escuchador, guarde esta informacin como parte de sus atributos.
Cada vez que la operacin verificarProgreso del controlador (RelacionarPerController),

solicite esta informacin al componente IndicadorProgresoService, este tendr el progreso
actualizado de la operativa en curso.
Una vez obtenido, el progreso de la operativa de Undo en curso, la clase controladora

(RelacionarPerController), en su operacin verificarProgreso, enviara esta respuesta al
objeto XMLHttpRequest, que ser el encargado, junto a funciones javaScript propias de la
pgina Web, de informar esto en pantalla y adems de verificar, que si se ha llegado a la
totalidad del progreso, que en este caso el cien por ciento, se anulen las peticiones al
controlador que se viene realizando por medio del hilo paralelo.
2.2.6.3 Resultados de la integracin del patrn de usabilidad SPF

Se adicionan nuevas relaciones a la persona seleccionada:
Jos Germn Nez Mori
Pgina 141 de 237
Figura 68: Adicin de distintas relaciones a la persona seleccionada

Adicionado numerosas relaciones, a la persona seleccionada (PER003), se procede a deshacer
(Undo) esta relaciones adicionadas, donde por cada relacin eliminada se ir informando del
progreso de la operacin en la pgina Web.
Figura 69: Barra de progreso mientras se aplica la operacin de Undo a las relaciones
adicionadas
Una vez finalizada la operacin, de deshacer las adiciones de relaciones, la barra de progreso
desaparecer actualizando la pgina Web y mostrar las relaciones iniciales que tena antes de
estas adiciones.
Jos Germn Nez Mori
Pgina 142 de 237
Siguiendo la dinmica de anteriores integraciones de patrones de usabilidad, a continuacin, se

presenta la planificacin actualizada asociada a las tareas de integracin de este patrn de
usabilidad.
Tabla 35: Planificacin actualizada de la tarea de integracin del patrn de usabilidad SPF
2.2.7 Integracin del patrn de usabilidad Abort Command

Este patrn de usabilidad Abort Command, en adelante AC, pertenece a la familia del patrn de
usabilidad Abort, al igual que el patrn Abort Operation (ver seccin 2.2.5 Integracin del
patrn de usabilidad Abort Operation ), este tambin, es una rama especifica de este patrn
Abort (ver anexo 04 Especificacin del patrn de usabilidad Abort).
De acuerdo a esta premisa, en la presente seccin se abordar, la integracin de este patrn de
usabilidad AC a la funcionalidad de Relacionar Personas, especficamente aplicado, sobre el
comando asociado al patrn de usabilidad System Progress Feedback, es decir, se buscar
integrar el patrn, para lograr cancelar el comando, que muestra la barra de progreso asociada a
cierta operativa.
Al igual, que el patrn de usabilidad System Progress Feedback, el patrn AC, no fue
considerado como parte de los requisitos de usabilidad asociados a la historia de usuario
Relacionar Personas (ver capitulo de Fase de inicio del marco gil de trabajo). Debido, a que
estamos en una iteracin que tiene como objetivo construir el prototipo de la arquitectura, que
mitigue las cuestiones de alto riesgo, el presente trabajo ha decidido incluirlo este patrn en la
arquitectura inicial.
Mencionar, que esta integracin del patrn de usabilidad AC, basar su diseo en los modelos
base de la especificacin del patrn Abort, teniendo ciertos matices propios del patrn de
Jos Germn Nez Mori
Pgina 143 de 237
usabilidad AC, por tal motivo, se utilizar el mismo diagrama de clases base utilizado por el
patrn Abort Operation (ver Figura 59).
La diferencia en los enfoques de integracin entre el patrn Abort Operation y el AC, reside en
el diseo base de la interaccin de los componentes que intervienen en el planteamiento de uno
u otro patrn. Por tal motivo la integracin del patrn de usabilidad AC, utilizar como base el
siguiente diagrama de secuencias:
Figura 70: Diagrama de secuencia de la especificacin del patrn de usabilidad AC

Como parte inicial de esta integracin, se presenta la planificacin de las tareas necesarias en la
labor de integracin del patrn de usabilidad AC a la funcionalidad de Relacionar Personas:
Tabla 36: Planificacin inicial de tarea de integracin del patrn de usabilidad AC
Jos Germn Nez Mori
Pgina 144 de 237
2.2.7.1 Integracin del patrn de usabilidad AC a la capa de

presentacin y capa de negocio.
Como se describe al inicio de esta seccin, esta integracin, ser aplicada sobre el comando de
informacin de progreso de ciertas funcionalidades, por tal motivo esta integracin, basar su
modelado en el diseo de nuevos componentes, realizados en la integracin del patrn de
usabilidad System Progress Feedback:
Figura 71: Integracin del patrn de usabilidad AC en la capa de negocio y capa de diseo
Como se puede ver en la figura 74, se adiciona nuevas operaciones al componente de servicio
IndicadorProgresoService y a la clase controladora, las cuales permitirn, que se ejecuten las
tareas necesarias de este patrn de usabilidad AC, sobre el comando del patrn System Progress
Feedback.
Adicional a estos cambios, se modifica tambin el flujo de actividades asociadas la pgina Web,
de adicin de nuevas relaciones. Esta modificacin, consiste en adicionar un nuevo evento
llamado cancelarComando y su respectivo estado de accin en el lado del sistema (operacin
en la clase controladora), que permite las peticiones de cancelar un comando determinado, en
este caso en concreto, el comando de informacin de progreso de la operativa de deshacer
(Undo).
De acuerdo a esto, el flujo de actividades asociado a la pgina Web, de adicionar nuevas

relaciones, queda de la siguiente manera:
Jos Germn Nez Mori
Pgina 145 de 237
Figura 72: Integracin del patrn de usabilidad AC en el diagrama de actividades de la pgina

Web de Adicin de relaciones
Con el propsito de entender cada uno de los cambios, realizados en los componentes de diseo
tanto de la capa de presentacin, como la de negocio, se presentar un cuadro de
correspondencia entre componentes de la especificacin del patrn de usabilidad Abort (ver
Figura 59) y la integracin del patrn AC (ver figura 74):
Jos Germn Nez Mori
Pgina 146 de 237
Componentes del P.U. AO
View
Controller
HistoryList
Command
ConcreteCommand
RelacionesService
DomainClass
Relacion
HistoryException
ProgressIndicator
IndicadorProgresoService
Tabla 37: Correspondencia de componentes del patrn de usabilidad AC y los componentes de

la integracin
Como se puede apreciar en la tabla 37, existen ciertos componentes de la especificacin que no
tiene su correspondencia en la parte de integracin, esto se debe a dos motivos:
Que alguno de ellos, no son requeridos por esta patrn AC, si no mas bien, por el patrn de
usabilidad Abort Operation, siendo este el componente HistoryList.
Que el resto de componentes, es administrado por el Framework de integracin Spring

utilizado por el marco gil de trabajo
2.2.7.2 Flujo de trabajo segn el patrn de usabilidad AC
Este flujo de trabajo, es una secuencia de actividades que se expone en esta seccin, con el
objetivo, de proporcionar un mayor detalle del funcionamiento de este patrn de usabilidad AC,
integrado a la funcionalidad respectiva. Esta secuencia de actividades, se basa en la
especificacin del patrn de usabilidad Abort, especficamente, en su diagrama de secuencia
(ver figura 73).
que se describen, se podr revisar la figura 74 (Integracin del patrn de usabilidad AC en la
capa de negocio y capa de diseo):
En la pgina Web, de adicin de nuevas relaciones, cuando se ejecuta el comando Undo

de las relaciones recin adicionadas, se muestra al usuario un barra informativa del progreso
de la operacin en curso.
Esta barra de progreso informativa, contar con la opcin de cancelar, la cual permitir
Jos Germn Nez Mori
Pgina 147 de 237
abortar el progreso del comando en curso. Esta cancelacin del comando en curso, implicar
abortar la barra de progreso y cancelar las acciones respectivas de la operacin Undo.
Una vez realizada la peticin de cancelar el comando, la clase controladora, recibir esta
peticin para su tratamiento en la operacin cancelarComando.
La operacin cancelarComando, solicitar al componente IndicadorProgresoService,

que actualice el estado de su atributo, que hace referencia a cancelar la operativa de
progreso, esto se har por medio de la operacin actualizarEstadoCancelar.
Sabemos que la operacin undoRelaciones, del componente RelacionesService, se

encarga de solicitar a la capa de datos la eliminacin de relaciones ya persistidas y adems
de informar de este progreso a su escuchador IndicadorProgresoService, donde, por cada
vez que informa a su escuchador con el progreso de esta operacin, verificar si el estado de
cancelacin de este comando esta activo.
Si el estado de cancelacin no esta activo, el componente RelacionesService, seguir con

la operativa en curso, caso contrario, abortar su operacin de eliminacin de relaciones, lo
cual implicar, que las relaciones eliminadas antes que el estado de cancelacin este activo,
persistir su eliminacin en bases de datos y de las restantes quedar su registro.
En la operacin cancelarComando, de la clase controladora, una vez solicitado la

actualizacin
del
estado
de
cancelacin
de
comando
al
componente
IndicadorProgresoService, volver consultar, las relaciones asociadas a las persona de la

operativa y retorna estos resultados a pantalla.
2.2.7.3 Resultados de la integracin del patrn de usabilidad SPF

Se adicionan nuevas relaciones a la persona seleccionada:
Jos Germn Nez Mori
Pgina 148 de 237
Figura 73: Adicin de distintas relaciones a la persona seleccionada

Adicionado numerosas relaciones, a la persona seleccionada (PER003), se procede a deshacer
(Undo) esta relaciones adicionadas, donde por cada relacin eliminada se ir informando del
progreso de la operacin en la pgina Web.
Figura 74: Barra de progreso con opcin de cancelar, ante la operativa de Undo de las
relaciones adicionadas
Mientras se va informando del progreso de la operativa de Undo de las relaciones adicionadas,
se pude cancelar este progreso, implicando esto, que se aborta la operacin hasta el punto de
Jos Germn Nez Mori
Pgina 149 de 237
progreso que se tena, es decir, que eliminan aquellas relaciones antes de abortar la operacin.
Para el caso presentado en la figura 51 (Barra de progreso con opcin de cancelar, ante la
operativa de Undo de las relaciones adicionadas), si se cancela la operativa en curso al 20 por
ciento de su avance, implicar que solo elimine una relacin de las adicionas, esta relacin sera
la asociada a la persona PER001.
Figura 75: Tras el evento de cancelar el comando de Undo de relaciones

Como parte final de los resultados de la integracin del patrn de usabilidad AC, se presenta la
planificacin actualizada, asociada a esta tarea:
Tabla 38: Planificacin actualizada de la tarea de integracin del patrn de usabilidad AC
Jos Germn Nez Mori
Pgina 150 de 237
2.3 Planificacin tras la primera iteracin

Una vez realizada cada una de las integraciones planificadas, a continuacin se presentan un
reporte genrico, que informarn el como se ha llevado a cabo cada una de las tareas planteadas
a lo largo del tiempo.
Figura 76: Carga de trabajo a lo largo de la planificacin

Como se puede apreciar en la figura 76, se muestra la carga de trabajo a lo largo de tiempo de la
planificacin. Se puede observar como esta carga va disminuyendo mientras mas cerca estamos
de la fecha fin de la planificacin.
Cada una de las integraciones a la funcionalidad de Relacionar Personas, que se ha descrito a
lo largo de este captulo, conforma en su conjunto, el prototipo de la arquitectura propuesta en
esta fase de elaboracin. Es en base a esta estructura de trabajo, que se enfocar las futuras
iteraciones de la fase de desarrollo, que en el presente trabajo ya no sern contempladas.
Jos Germn Nez Mori
Pgina 151 de 237
VI. Conclusiones
En el presente capitulo, se presenta las conclusiones obtenidas tras la realizacin de esta Tesis
de fin de Master.
Este trabajo fue desarrollado siguiendo los lineamientos de las metodologas giles: Scrum,
Agile Unified Process (AUP) y Extreme Programming (XP), que en conjunto con los principios
y patrones de usabilidad, conformaron el marco gil de trabajo y tal cual se esperaba,
contribuyeron como una gua para la inclusin de los principios de usabilidad en el desarrollo
del sistema.
Desde el punto de vista metodolgico, el marco gil de trabajo planteado, fue utilizado como
base para la aplicacin del paradigma orientado a objetos, demostrando de esta manera su
amplia adecuacin y alto grado de utilidad en el desarrollo de sistemas que sigan esta estructura.
El entorno tecnolgico seleccionado para la construccin del sistema, resulto apropiado y no

fueron detectados inconvenientes importantes durante el desarrollo del mismo, que pudiera
afectar o contradecir la eleccin realizada, si no mas bien contribuyeron, en la inclusin de los
principios de usabilidad antes del desarrollo.
El alto grado de disponibilidad de bibliotecas de uso variadas y de herramientas de libres

distribucin de la tecnologa Java, constituyen otro de los motivos que justifican la seleccin de
la plataforma sobre la que se ha desarrollado en sistema, alentando as, el uso de las mima tanto
para fines acadmicos como comerciales.
El sistema desarrollado, como un prototipo de arquitectura, deja en evidencias, que el ciclo de

vida del software que sugiere el marco gil de trabajo, cumple con el objetivo de dar
lineamientos, en los que los principios de usabilidad son tomados en cuenta tanto en la etapa de
requerimientos como de diseo
De acuerdo a todo lo que se describe a lo largo de este trabajo de Tesis de fin Master, queda
demostrado, la compatibilidad de la usabilidad con las metodologas giles, debido a que, cada
uno de sus patrones y principios de usabilidad han sido engranados apropiadamente al
planteamiento del marco gil de trabajo y todo esto justifica:
Que no solo la usabilidad se limita a la interfaz del sistema, si no, que tambin afecta al
ncleo del sistema
Jos Germn Nez Mori
Pgina 152 de 237
VII. Referencias Bibliogrficas

[AMDAWI10], AndroMDA, http://es.wikipedia.org/wiki/AndroMDA, 2010
[AMDA10] AndroMDA, http://www.andromda.org/index.php, 2010
[AMSPUA09] Ana M. Moreno, Maribel Sanchez Segura, Patrones de Usabilidad:

Mejora de la Usabilidad del Software desde el momento Arquitectnico, 2009
[AMVN10] Apache Maven, http://maven.apache.org/, 2010
[ASTS10] Apache Struts, http://struts.apache.org/, 2010
[COAD98] Peter Coad, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,

http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users
Guide/Feature_Driven_Development.htm, 1998
[CLEP09] Jos H. Cans, Patricio Letelier y M Carmen Penads, Metodologas giles

en el desarrollo de software, 2009
[CRLA02] Craig Larman, UML y Patrones 2 Edicin, 2002.
[DSDM09] DSDM Consortium, http://www.dsdm.org/, 2009
[HBNT10] Hibernate, http://www.hibernate.org/, 2010
[JSUT09] Jeff Sutherland, Scrum Log Jeff Sutherland,

http://jeffsutherland.com/scrum/, 2009.
[JPAL02] Juan Palacios, Flexibilidad con Scrum,

http://www.lulu.com/content/1338172, 2002.
[JCCA08] Jos Carlos carvajal Riola, Metodologas giles, 2008.
[JOKR05] Joe Krebs, RUP in the dialogue with Scrum, 2005.
[KEBE02] Kent Beck , Una explicacin de la programacin extrema: Aceptar el

cambio, 2002.
[KSXHB09] Ken Schwaber, Scrum, http://www.controlchaos.com/, 2009.
[KINT07] Kinetia, Agile UP, http://www.kynetia.es/calidad/agile-up.html, 2007
[MFTO09] Manifesto for Agile Software Development, http://www.agilealliance.com/,

2009
[MART91] Martin, J., Rapid Application Development, Macmillan Inc., New York,
1991.
[MFAS01] Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, Jim Highsmith, Andrew Hunt, Ron Jeffries, Brian Marick, Robert C.
Martin, Ken Schwaber, Jeff Sutherland, Dave Thomas, Manifiesto for Agile Software
Jos Germn Nez Mori
Pgina 153 de 237
Development, http://www.agilemanifesto.org/, 2001.
[MDAWI10] Model Driven Architecture, http://en.wikipedia.org/wiki/Modeldriven_architecture, 2010
[MGDU10] MagicDraw UML,

http://www.magicdraw.com/show_patch1/download_demo/download_patch, 2010
[OMGWB10] OMG, http://www.omg.org/, 2010
[LECCO09] Luis Enrique Corredera de Colsa, Arquitectura dirigida por modelos para
J2ME, 2009
[RJEF99] Ron Jeffries, Xprogramming, http://www.xprogramming.com/, 1999-
[RMAT6] Robert Martin, Agile and XP, http://www.objectmentor.com/, 2006
[SABL06] Scott Ambler, The Agile Unified Procees V1.1, 2006.
[SALECA05] Emilio A. Snchez, Patricio Letelier y Jos H. Canos, Mejorando la

gestin de historias de usuarios en XP, 2005.
[SABL08] Scott Ambler, Agile Model Driven Development (AMDD): The Key to
Scaling Agile Software Development,
http://www.agilemodeling.com/essays/amdd.htm, 2008.
[SMHR04] Schenone Marcelo Hernn, Diseo de una metodologa gil de desarrollo de

software, mscheno@fi.uba.ar, 2004.
[SPTOME09] Sprintometer, http://sprintometer.com/, 2009
[SPTOUG08] Sprintomer user guide, http://sprintometer.com/help, 2008
[SPIG10] Spring, http://www.springsource.org/, 2010
[SUNPB05] SUN Mycrosystems, Progress Bar Usin

Ajax,https://bpcatalog.dev.java.net/nonav/ajax/progress-bar/design.html, 2005
[WDSDM09] Wikipedia, Dynamic System Development,

http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method, 2009
[WAUP09] Wikipedia, Agile Unified Process,

http://en.wikipedia.org/wiki/Agile_Unified_Process, 2009.
[WDAS09] Wikipedia, Desarrollo gil de software,

http://es.wikipedia.org/wiki/Procesos_%C3%A1giles, 2009.
[WFDD09] Wikipedia, Feature Driven Development,

http://en.wikipedia.org/wiki/Feature_Driven_Development, 2009
Jos Germn Nez Mori
Pgina 154 de 237
VIII. Anexos
Jos Germn Nez Mori
Pgina 155 de 237
Anexo 01: Especificacin Patrn de Usabilidad Warning
Jos Germn Nez Mori
Pgina 156 de 237
USABILITY-ENABLING GUIDELINE
Identification
Name
Warning
Family
Feedback
Aliases
Status Display; Modeling Feedback Area
Intent
Providing different alert types upon execution of potentially damaging actions
Problem
Certain application tasks have potential serious consequences (that, for example, may not be undoable) so the application might need to verify with the user one last time before actually executing the task,
to prevent them from calling said tasks by mistake, or to allow them to reconsider if needed.
Context
Applications where user tasks may have potentially damaging effects, including permanent changes or loss of data
Required Mechanisms
Abort: Certain types of warnings require a cancel button. See cancel operation section in Abort Mechanism
Jos Germn Nez Mori
Pgina 157 de 237
TABLE 1. USABILITY ELICITATION GUIDELINE

HCI Recommendation
Elaboration
Discussions with Stakeholders
Status change notification
W_ELAB-1: Choosing undoable actions
For each action that a user may take, consider

the following aspects:
The Warnings addressed herein pertain to Notifications,

Confirmations or Authorizations presented to the user during or
before execution of an action
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
Stakeholder should know that the more damaging the action (for
irreversible actions) the higher the level of warning. (and viceversa). Be careful not to over-do.
Actions of little damage can be left open as to not overload the
user with notifications.
Use notifications only when actually useful (the user will do
something with the information provided)
Warnings are considered preemptive, so notification that an
error has occurred falls outside of the scope of this pattern (See
Status Feedback).
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_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:
W_Q-3 Of those that need approval,

which are highly
damaging/sensitive,
therefore needing credential
approval?
Are you sure you want to? right before

execution of damaging action. User needs
to OK for execution to proceed
W_Q-4 For every action mentioned,

which information will be
shown to the user?
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
Authorization
Table 1: Warning. Usability Elicitation Guideline
Jos Germn Nez Mori
Usage Examples (optional)
Pgina 158 de 237
W_EX-3: Authorization
Figure 1: Warning. Use Case Model
Jos Germn Nez Mori
Pgina 159 de 237
Figure 2: Warning. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 160 de 237
TABLE 2. USABILITY-ENABLING DESIGN GUIDELINE: GENERIC COMPONENT RESPONSIBILITIES

System Responsibility
W_SR-1 Be aware of damaging actions
Generic Component Responsibilities

For each Domain Component that includes at least one damaging method (one that needs to incur in a warning of some kind), a Wrapping Component must
exist. This Wrapping Component mimics the structure of the Domain Component (it must have the same number of methods and the same method names as
Domain Component), and it will sit between any invoking class and said DomainComponent. All methods in a Wrapping Component consist of a) a flag check,
to determine if it is safe to invoke the method of the same name in the DomainComponent, and, b) a call to said method in Domain Component.
For example, if a component called SalesItem is determined to have a damaging method, the component will be renamed to, for example, SalesItemDomain,
to allow for the creation of its Wrapping Component, which must be called SalesItem for transparencys sake (an invoking class need not know if its dealing
with a Wrapper or a Domain Component).
When invoked, methods in the Wrapping Component can respond (to their invokers) that it is not yet safe to invoke the requested method, and an appropriate
Warning is be issued. It is the Wrapping Component who is responsible for knowing which method call triggers which kind of warning (Notification,
Confirmation, Authorization) and for determining whether or not the invocation of the method is safe.
W_SR-2 Notify
Once the Warning is issued, if it is of the kind Notification, it must reach the UI Component, after which the invocation automatically returns to the Wrapping
Component for execution. Since it is now safe to invoke the action in the DomainClass, the Wrapping Component does so.
W_SR-3 Request confirmation
If the issued Warning is a Confirmation, it must also reach the UI Component but in this case it must wait for the user to OK. Once s/he does so, the invocation
returns to the Wrapping Component for execution. Since it is now safe to invoke the action in the DomainClass, the Wrapping Component does so.
W_SR-4 Request authorization
Finally, if the issued Warning is an Authentication, it must reach the UI Component, which will then go through all the necesary steps (outside of the scope of this
pattern) to perform the necessary credential cross-checking. Once the user has been authenticated in this manner, the invokation will return to the Wrapping
Component for execution. Since it is now safe to invoke the action in the DomainClass, the Wrapping Component does so.
W_SR-5 Display warning
The UI Component is responsible for displaying the Warning information and for receiving and processing the necessary user input to satisfy the given Warning
(if applicable)
Jos Germn Nez Mori
Pgina 161 de 237
TABLE 3. USABILITY-ENABLING DESIGN GUIDELINE: CONCRETE OBJECT RESPONSIBILITIES (MVC)

W_SR-1 Be aware of
damaging
actions
Objects
View
Controller
DomainClassWrap
DomainClass
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.
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(),
6a. DomainClass
executes the
invoked method,
doAction().
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)
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
W_SR-3 Request
confirmation
Fig
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
Jos Germn Nez Mori
3. The Controller requests

DomainClassWrap to set the flag
for doAction to OK.
3,
4
4. In it, it will then check if the called method is

OK to execute with checkOK(doAction).
5. If it is, it will call onto DomainClass to execute
the method
6b. Otherwise it will create a Warning of the
appropriate type (Notification, Authentication or
Confirmation) with the information pertaining to
the invoked method
5. Since the flag is now set to OK, the
DomainClassWrap immediately forwards the
method call to DomainClass
6. DomainClass
executes the
invoked method,
doAction().
1. The new
Warning issued
in W_SR-1 (in
this case a
Notification) is
forwarded
onto the View
3,
4

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
4. It then calls the doAction()

method on DomainClassWrap
again, prompting a re-check of the
flag for the current method.
for doAction to OK.
Warning

Pgina 162 de 237

Objects
View
W_SR-4 Request
authorization
2. When the View receives an

Authentication, it engages in the
appropriate actions to identify the
current user (perhaps involving other
relevant domain classes)
Once the user has been properly
identified by the system, the control is
returned to the DomainClassWrap via
the Controller
W_SR-5 Display
warning
Controller
Fig
DomainClassWrap

for doAction to OK.


Warning
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
3,
4
As detailed in W_SR-2, W_SR-3 and

W_SR-4, it is the Views responsibility
to display Warnings. To do so
appropriately, it uses all the information
available in the Warning object.
Jos Germn Nez Mori
DomainClass
Pgina 163 de 237
Figure 3: Warning. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 164 de 237
Figure 4: Warning. Usability-enabling design pattern. Sequence Diagram Warn (W_SR-1, W_SR-2, W_SR-3, W_SR-4 and W_SR-5)
Jos Germn Nez Mori
Pgina 165 de 237
Anexo 02: Especificacin Patrn de Usabilidad System Status

Feedback
Jos Germn Nez Mori
Pgina 166 de 237
Identification
Name
System Status Feedback (SSF)
Family
Feedback
Aliases
Status Display; Modeling Feedback Area
Intent
Providing the user with information on the different statuses the system might be in at any given time
Problem
An application can be in one or more statuses at once, so the user needs to be visually aware of all of them continuously.
Context
When changes that are important to the user occur or
When failures that are important to the user occur:
-
During task execution
Because there are not enough system resources
Because external resources are not working properly.
Examples of status feedback can be found in status bars on windows applications; train, bus or airline schedule systems; VCR displays; etc.
Required Mechanisms
Abort: Certain types of status feedbacks may need a cancel option
Jos Germn Nez Mori
Pgina 167 de 237

HCI Recommendation
Elaboration
Source of status changing events
W_Q-5 Of which system statuses

(and status changes) will the
user be notified?
Status change notification
W_ELAB-2:
HCI experts argue that the user wants to be

notified when a change of status occurs.
Changes in the system status can be triggered by any of the

following:
User-initiated events
Internal actions realizadas por el propio sistema
System failures
Problems with external and internal resources
Status types
W_ELAB-3:
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.
For each piece of status information to be displayed, discuss with

the user what type of information it is according to the following
criteria:
Displays should be put together in a way that

emphasizes the important things, deemphasizes the trivial, doesnt hide or obscure
anything, and prevents one piece of information
from being confused with another. They should
never be re-arranged, unless users do so
themselves. Attention should be called to
important information with bright colours,
blinking or motion, sound or all three but a
technique appropriate to the actual importance
of the situation to the user should be used.
Jos Germn Nez Mori
Status types: Levels of importance
W_Q-6 Which status changes are

initiated by the user and
which are initiated by the
system or other resources
(whether internal or
external)?
W_Q-7 For each system status, which
type of notification should be
shown to the user?
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.
Pgina 168 de 237

W_EX-4: Browser online status
Without proper status notification the user
may lose track of which actions s/he is
allowed to perform within the system at a
given time. For example, the Online Status
in a browser determines if the user is
allowed to navigate only through cached
pages (offline mode) or also through live
web pages (online mode).
W_EX-5: Status messages in Firefox
Critical: When attempting to open a
website without a live internet connection,
Firefox will display an obtrusive message
informing the user of this fact.
Non-critical: When the browser is set to a
site that has been marked as a favorite by
the user, a small star will appear next to its
URL.
Less important: When the browser has
finished loading a page, the word Done
will appear in the lower-left corner of the
status bar.

HCI Recommendation
Elaboration
Status placement
W_ELAB-4:
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.
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.
Status placement and writing directions
W_Q-8 How and where will each type

of notification be shown to the
user?
The standard practice of putting information about

changes in state on a status line at the bottom of a
window is particularly unfortunate, especially if
the style guide calls for lightweight type on a grey
background[]. The positioning of an item within
the status display should be used to good effect.
Remember that people born into a European or
American culture tend to read left-to-right, top-tobottom, and that something in the upper left corner
will be looked at most often[].
Table 2: System Status Feedback. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 169 de 237

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)
Figure 5: System Status Feedback. Use Case Model
Jos Germn Nez Mori
Pgina 170 de 237
Figure 6: System Status Feedback. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 171 de 237

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
Jos Germn Nez Mori
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.
Pgina 172 de 237

Objects
View
Controller
W_SR-10 Be aware of system

statuses (and their
changes)
StatusManager
1. The View listens users requests

for execution actions action, and
forwards it to the Controller.
W_SR-12 Handle system-initiated

status changes
W_SR-13 Present system status

notifications to users
Jos Germn Nez Mori
Status
DomainClass
2. The DomainClass
represents the domain
object(s) responsible for
executing actions that lead to
system state changes. It must
notify all subscribers
(StatusManager) of any
changes.
1. Upon system
initialization, the
StateManager subscribes to
each DomainClass which it
knows can execute statuschanging actions.
1. The View must subscribe to each

Status object upon system
initialization.
W_SR-11 Handle user-initiated

status changes
Fig
2. The Status object holds all the

information related to one system
status and the means to change
and query this information. It
must notify all subscribers (View)
of any changes.
2. The Controller
orders the
appropriate
DomainClass to
execute said actions
3,
5
3,
5
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
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
3,
4
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.
Pgina 173 de 237
Figure 7: System Status Feedback. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 174 de 237
Figure 8: System Status Feedback. Usability-enabling design pattern. Sequence Diagram Change Status (W_SR-11, W_SR-12 and W_SR-13)
Jos Germn Nez Mori
Pgina 175 de 237
Figure 9: System Status Feedback. Usability-enabling design pattern. Sequence Diagrams Be aware of system statuses (and their changes) (W_SR-6)
Jos Germn Nez Mori
Pgina 176 de 237
Anexo 03: Especificacin Patrn de Usabilidad Global Undo
Jos Germn Nez Mori
Pgina 177 de 237
Identification
Name
Undo
Family
Undo/Cancel
Aliases
Multi-Level Undo [Tidwell, 2002]; Undo [Welie, 2003]; Global Undo / Object-Specific Undo [Laasko, 2003]; Allow Undo [Brighton, 1998]
Intent
Undo provides a way for the user to revert the effects of a previously executed action or series of actions within an application.
Problem
Users may need to undo certain actions they perform for a variety of reasons: They could have been exploring new functionality, have made a mistake or simply have changed their minds about what they
have just done.
Context
Undo should be considered when developing highly interactive applications where users may perform sequences of steps, or execute actions that have tangible consequences.
Jos Germn Nez Mori
Pgina 178 de 237

HCI Recommendation
Elaboration
Undo
W_ELAB-5: Choosing undoable actions
Users typically explore functionality of an application

but do not want to be punished when selecting
unwanted functions [Welie, 03]. The ability to undo a
long sequence of operations lets users feel that the
interface is safe to explore. While they learn the
interface, they can experiment with it, confident that
they arent making irrevocable changes even if they
accidentally do something bad.
All actions with important consequences should

provide the undo feature, save for those for which
there are greater impeding factors present.
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.
For actions which are expensive to revert, The

cost/benefit ratio of providing it with an undo
feature should be evaluated.
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?
The term important consequences must be

clearly defined before deciding which actions will
be undoable.

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.
In any case, make sure the undoable operations make

sense to the user. They can be specific functions or a
meaningful group of actions (for example, changing the
printer settings) [Welie, 03]. Be sure to define and name
them in terms of how the user thinks about the
operations, not how the computer thinks about them.
Warnings
W_ELAB-6: Warnings: Authorization
If a command has side effects that cannot be undone,

warn the user before executing the command and do not
queue it [Welie, 03]
Most likely a warning of the type Autorization will

be required. See warning pattern for the warning
process.
Redo
W_ELAB-7: Redo: Availability
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.
Redo should only revert the effects of the latest

applied Undo.
Jos Germn Nez Mori
Some existing software currently use the Redo

feature as a way to repeat the execution of any
command.
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
W_Q-13 Will a redo functionality be

provided?
W_EX-9: Redoing in MS Word
W_Q-14 How will the user be provided

access to the redo functionality?
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
Pgina 179 de 237
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.
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)

HCI Recommendation
Elaboration
History
W_ELAB-8: History: Stack size and type
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.
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 Words undo Stack
MS Word and others provide users with a
visual list (stack) of the latest opperations
executed within the application. Within this
stack, users can not only view the operations
in the order in which they would be undone,
but they can select an operation deep within
the stack and undo it, along with every
operation that was executed after it.
Most desktop applications put Undo/Redo items on the

Edit menu. Show the history of commands so that users
know what they have done [Wellie, 03]. Undo is usually
hooked up to Ctrl-Z or its equivalent
Smart Menus
W_ELAB-9: Smart Menus and History
The most well-behaved applications use Smart Menu

Items to tell the user exactly which operation is next up
on the undo stack.
Smart menus are tightly related to the command

history (stack). If one is kept, its relatively simple
to offer smart menus different functionalities.
W_Q-18 Will the user have information

about the expected outcome of
performing undo at any given
time (smart menu)?
W_Q-19 If so, how will this information
be provided to the user?

The software system must provide the possibility for the
user to easily access (for example, through the right
button) the specific commands that affect such an object.
One should be the undo/redo function. In this case, the
system should filter the global undo stack and show only
the operations that affected the state of the selected
object [Laasko, 03].
W_ELAB-10:
Object
Global Undo
Specific
Undo
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?
Table 3: Undo. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 180 de 237
W_EX-11: Smart Menus in drawing program

When the last performed operation in a
drawing program was paint red, the undo
menu, or equivalent, should display undo
paint red as opposed to the more generic
undo
W_EX-12: UML Design Program
In a UML design program, selecting the
graphic representation of a cCass within a
diagram whould should provide the option
to undo the operations performed on (and
only on) this particular Class.
Figure 10: Undo. Use Case Model
Jos Germn Nez Mori
Pgina 181 de 237
Figure 11: Undo. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 182 de 237

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)
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 UI gets this information from the History Component, which must notify it of the current undoable/re-doable action upon every change.
The History Component must then retrieve the last*/current** Command executed over that object, without discarding it, and order it to Undo/Redo itself.
The Command, in turn, executes the necessary actions, using the stored state information, to return the object to the state preceding/following its execution.
Jos Germn Nez Mori
Pgina 183 de 237

Objects
View
W_SR-21 Provide Undo

functionality
(storing/undoing)
1. The View must listen

for invocation of
actions. Upon
reception, it must
notify the Controller of
said action
Controller
2. The Controller must determine if
the invoked action is undoable. In
such case it must call the
execute() method of the
corresponding ConcreteCommand
object (otherwise invocation goes
directly to the DomainClass).
3. The Controller must then
clone() said ConcreteCommand
and add() it to the HistoryList.

for invocation of the
Undo action. Upon
reception, it must
notify the Controller.
W_SR-22 Provide user
access to Undo
1. The View must

present the user with
the mean(s) to call the
Undo action (i.e. within
the Edit menu, through
Ctrl-Z, etc.)
W_SR-23 Support Redo

functionality

Redo action. Upon
reception, it must
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.)
Jos Germn Nez Mori
2. The Controller orders the

HistoryList to undo the last action.
Fig
ConcreteCommand
HistoryList
DomainClass
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
4. Upon call to its undo()

calls the necessary methods in
DomainClass (with any needed
state information, stored upon
execution) to revert its effects.
3. The HistoryList determines the

ConcreteCommand to undo and calls its
undo() method.
5. The DomainClass
executes the
methods invoked
by
ConcreteCommand.
3,
5
3,
5

HistoryList to redo the current
action.
4. Upon call to its redo()

calls the necessary methods in
state information, stored upon
execution) to reinstate its effects.

ConcreteCommand to redo and calls its
redo() method.
5. The DomainClass
executes the
methods invoked
by
ConcreteCommand.
3,
6
3,
6
Pgina 184 de 237

Objects
View
W_SR-25 Support MultiLevel Undo and

History
Controller
ConcreteCommand
Fig
HistoryList
DomainClass
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).
3. When the View is

notified of changes in
the HistoryList it
updates its History
Displays accordingly.
3,
4,
5,
6
2. Every time a ConcreteCommand is

added to the HistoryList or the pointer
changes position (i.e. the next
undoable/re-doable action is updated),
the HistoryList notifies the View
W_SR-26 Provide expected
results of
Undo/Redo
2. When the View is

notified of changes in
the HistoryList it
updates its next
undoable/redoable
W_SR-27 Allow ObjectSpecific

Undo/Redo

Undo/Redo action over
a specific object. Upon
reception, it must
Jos Germn Nez Mori
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
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
state information) to
revert/reinstate its effects.
Pgina 185 de 237

ConcreteCommand to undo/redo by
scanning the collection for the
latest/current one invoked over the
object and calls its undo() method.
3,
5,
6
5. The DomainClass
executes the
methods invoked
by
ConcreteCommand.
3,
5,
6
Figure 12: Undo. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 186 de 237
Figure 13: Undo. Usability-enabling design pattern. Sequence Diagram Execute Action (W_SR-1)
Jos Germn Nez Mori
Pgina 187 de 237
Figure 14: Undo. Usability-enabling design pattern. Sequence Diagram Undo Action (W_SR-1, W_SR-22, W_SR-24, W_SR-26 and W_SR-27)
Jos Germn Nez Mori
Pgina 188 de 237
Figure 15: Undo. Usability-enabling design pattern. Sequence Diagram Redo Action (W_SR-23, W_SR-24, W_SR-25, W_SR-26 and W_SR-27)
Jos Germn Nez Mori
Pgina 189 de 237
Anexo 04: Especificacin Patrn de Usabilidad Abort
Jos Germn Nez Mori
Pgina 190 de 237
Identification
Name
Abort
Family
Undo/Cancel
Aliases
Emergency Exit [Brighton, 1998]; Go Back to a Safe Place [Tidwell, 1999]; Go Back [Tidwell, 1999]; Prominent Cancel [Tidwell, 02]
Intent
Providing the means to cancel an on-going command or operation, or to allow for exiting the application altogether
Problem
Certain commands or operations might take a long time to execute. In such cases, the user will need to be at the liberty to cancel them. S/he must also be allowed to exit an application at all times, regardless
of any tasks that may be being executed.
Context
When the user needs to exit an application or a command quickly.
Jos Germn Nez Mori
Pgina 191 de 237

HCI Recommendation
Elaboration
Cancelling Commands
W_ELAB-11:
Si un comando tarda ms de 10
segundos (**Ha desaparecido de la
referencia y contradice referencias
nuevas del progress (gnome) donde
ponen opcion de cancel para todos los
progress.**) en ejecutarse, proveer
opcin de Cancelar (adems de la
informacin sugerida por el
mecanismo Progress Feedback) para
permitir la interrupcin de su
procesamiento y el regreso al estado
anterior [Nielsen, 93].
Se entiende por comando una tarea indivisible invocada

por el usuario.
Identificacin/Seleccin
Para los comandos listados en 0 Cmo debe presentarse al

usuario la opcin de cancelar?
Es necesario identificar los comandos potencialmente largos

(>10s). Solo estos sern cancelables por el usuario.
Comandos ms cortos no sern cancelables, aunque para los
>2s se muestre su progreso (ver Progres Feedback)
Para cada una de los comandos listados en 0 A qu estado

pasar el sistema luego de que el usuario elija la
opcin de cancelar?
Qu comandos requerirn la opcin de cancelar?
En caso de que no resulte viable listar todos los comandos

>10s, listar solo aquellos que requieran atencin especial y
para el resto definir un comportamiento estndar (por
defecto) de cancelacin
Una vez identificados los comandos potencialmente largos
deber consultrsele al usuario si existe alguno excepcional
para el cual no deba darse la opcin de cancelar. Es
importante destacar en esta discusin que la recomendacin
HCI indica que todos estos comandos deberan ser
cancelables, pero es necesario permitirle al usuario hacer
excepciones en casos puntuales que as lo requieran
W_ELAB-12:
Presentacin
Existen maneras standar y simples de cancelar comandos

(i.e. botn X, ctrl-c, etc.) Discutir con el usuario solamente si
tiene alguna necesidad especfica para alguno de los
comandos.
AO_E4: Control de Regreso a Estado
Al cancelar un comando es necesario deshacer
(automticamente) los efectos que ste pueda haber tenido
hasta el momento.
Jos Germn Nez Mori
Pgina 192 de 237

W_EX-13:

HCI Recommendation
Elaboration
Cancelling Operations
W_ELAB-13:
Si el usuario entra en un espacio o

estado en el cual no quiere estar,
necesitar poder salir de el de
manera segura y predecible. Adems,
hacer backgracking a lo largo de
mltiples estados consecutivos puede
resultar tedioso [Tidwell, 99]. Por
esta razn, en aplicaciones basadas
en ventanas (GUI), es estndar tener
un botn de Cancel que cierre la
ventana de dilogo actual y descarte
cualquier cambio hecho por el
usuario dentro de la misma.
Se entiende por operacin cualquier interaccin realizada

en sub-ventanas (generalmente de mltiples pasos )
Identificacin/Seleccin
Qu operaciones requieren la opcin de cancelar?
W_EX-14:
Para las operaciones listadas en 0 Cmo debe presentarse

al usuario la opcin de cancelar?
W_EX-15:
Para cada una de las operaciones listadas en 0 A qu

estado pasar el sistema luego de que el usuario
elija la opcin de cancelar?
W_EX-16:
Dnde y cmo se presentar al usuario la opcin de Salir?
(i.e. botn rojo X arriba-derecha en

windows)
Toda operacin deber ser cancelable, permitiendo al

usuario salir de la sub-ventana desechando los cambios (si
los hubiese). Discutir con el usuario si existe alguna que por
algn motivo excepcional no deba serlo.
En caso de que no resulte viable listar todas las operaciones
cancelables, listar solo aquellas que requieran atencin
especial y para el resto definir un comportamiento estndar
(por defecto) de cancelacin
W_ELAB-14:
Presentacin
Discutir con el usuario si tiene alguna necesidad especifica en

cuanto a la presentacin de la opcin de cancelar
operaciones ejecutadas desde sub-ventanas. De lo contrario
utilizar el botn de Cancelar estndar.
AO_E4: Control de Regreso a Estado
Al cancelar una operacin se presentan dos posibles
escenarios:
La operacin a cancelar ha consistido (al momento de la
cancelacin) nicamente de navegacin entre pasos. La
cancelacin de este tipo de operaciones consistir
nicamente en salir de la sub-ventana correspondiente.
La operacin a cancelar ha provocado cambios en el estado
del sistema. En este caso, la cancelacin deber, adems de
salir de la sub-ventana, deshacer dichos cambios,
regresando al sistema al estado previo a la invocacin de la
operacin (ver Step-by-step)
Exiting the application
W_ELAB-15:
Aquellos usuarios que utilizan un

gran nmero de aplicaciones
simultneamente pueden necesitar

cuanto a la presentacin de la opcin de Salir de la aplicacin.
De lo contrario utilizar estndar del OS/lenguaje
Jos Germn Nez Mori
Presentacin de opcin de salir
Pgina 193 de 237

HCI Recommendation
salir de un programa rpidamente
cuando alguna tarea de mayor
prioridad necesite los recursos del
sistema, o cuando se haya iniciado el
programa por error [Brighton, 98].
Por esta razn, a nivel de aplicacin,
es necesario garantizar que la opcin
de salir del programa est siempre
claramente disponible (incluso
durante el inicio del programa) y que
sta nunca sea bloqueada por
ventanas de dialogo.
Si se elige la opcin de Salir luego de
haber manipulado datos, se debe
presentar la opcin de Guardar
Cambios
Elaboration
W_ELAB-16:
Manejo de Cambios
Generalmente la opcin de guardar cambios es relevante en

aplicaciones que modifican archivos o registros durante su
ejecucin.
Se desea presentar al usuario la opcin de Guardar

Cambios?
W_EX-17:
Si la respuesta a 0 es afirmativa: Dnde y cmo se

presentar la opcin de Guardar Cambios?
W_EX-18:
Si al seleccionar la opcin de salir existen

operaciones/comandos en ejecucin Como se
manejar la culminacin de los mismos (a,b,c o
d)?
W_EX-19:
El mensaje de alerta que indica al usuario que existen

cambios por guardar generalmente se muestra como un
warning de tipo confirmation al usuario (Ver Warning)
W_ELAB-17:
Presentacin de opcin Guardar
Cambios
cuanto a la presentacin de la opcin de Guardar Cambios.
De lo contrario utilizar estndar del OS/lenguaje
W_ELAB-18:
Culminacin de operaciones y
comandos
En cuanto a detener los comandos/operaciones en ejecucin al
momento de salir existen varias alternativas:
Salida Inmediata: Abortar todas las tareas (descartando sus
resultados) y cerrar la aplicacin sin consultar al usuario.
Delegacin de Control: Cediendo el control a los comandos
u operaciones activos en ese momento antes de cerrar
definitivamente la aplicacin.
Espera: Preguntar al usuario si est seguro de que desea
salir, abortando todas las tareas en ejecucin. Si responde
que s, se cancelarn inmediatamente todas las tareas de la
manera estndar establecida.
Consulta: Dar al usuario la opcin de elegir entre los modos
de salida a, b y c
Table 4: Abort. Usability Elicitation Guideline
Jos Germn Nez Mori
Pgina 194 de 237
Figure 16: Abort. Use Case Model
Jos Germn Nez Mori
Pgina 195 de 237
Figure 17: Abort. System Responsibility Clusters
Jos Germn Nez Mori
Pgina 196 de 237

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/hed like to make, the UI must order all
commands and/or operations to be dealt with in one of three ways (through an invoking component, if any):
A) All on-going commands and/or operations will be cancelled immediately in the same manner (re: state retrieval) in which they are cancelled by users
B) All on-going commands and/or operations will be allowed to finish execution, in which case the UI will wait until the last one notifies it has finished
C) All on-going commands and/or operations will be terminated immediately (disregarding state) and the application closed.
It is the UIs responsibility to know whether or not to prompt the user for an exit type. If no prompt is made, it is also the UIs responsibility to be aware of
which type of exit it needs to make (i.e. the way in which commands and operations will be dealt with upon exiting).
W_SR-33 Handle potential changes to

be saved
When the UI receives a call to exit the application, the component in charge of delegating actions (if any) should first ask a SaveComponent (see below) if there
exist any pending changes before exiting
A SaveComponent is responsible for determining whether there are changes to be saved and to order such saves.
If there are changes pending to be saved, the delegating component will inform the UI, which in turn should prompt the user to save said changes
These changes will be saved by the SaveComponent if requested
Jos Germn Nez Mori
Pgina 197 de 237

Objects
View
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.
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
Controller
Fig
ConcreteCommand
HistoryList
DomainClass
3,
4
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.
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.
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,
4,
5
3. The Controller must then

clone() said ConcreteCommand
and add() it to the HistoryList.
1. The View must listen for invocation of
cancel() for a given thread. Upon reception,
it must order the Controller to terminate said
thread.
7. The View must discard any ProgressIndicators
upon notification, and also update any Smart
Menus or History Displays (See Undo)
W_SR-36 Identify
cancellable
operations
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.
1. The View must listen for calls to operations

(See Step-by-step). It must be aware of which of
these are cancellable and provide the
appropriate GUI components to enable
cancellation.
Jos Germn Nez Mori
6. The thread in which the

DomainClass resides will
then notify this to any
existing ProgressIndicators
(see Progress Feedback).
3,
sbs
Pgina 198 de 237

Objects
View
W_SR-37 Cancel
operations
and handle
application
state
1. At any point during operation execution, the

user must be allowed to cancel(), exiting the
operation. The View will pass this order to the
Controller.
W_SR-38 Exit
application
handling
potential
on-going
commands/
operations
ConcreteCommand
HistoryList
DomainClass
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
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.
3. The Controller then procedes to

handle commands and operations
according to the exit type.
3,
6
2a. If so, the View prompts the user, whom

responds with one of three possibilities (cancel
all, wait to finish or immediate exit)
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. Once cancelled the window(s) in which the

operation was being carried out must be
discarded by the View.
2b. If not, the View must simply forward said call

to the Controller, along with what it knows to be
the appropriate exit type .
3. Upon Controller notification, the View will kill
the GUI and exit.
W_SR-39 Handle
potential
changes to
be saved
Controller
Fig
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)
Jos Germn Nez Mori
Pgina 199 de 237
3,
6
Figure 18: Abort. Usability-enabling design pattern. Class diagram
Jos Germn Nez Mori
Pgina 200 de 237
Figure 19: Abort. Usability-enabling design pattern. Sequence Diagram Execute command (W_SR-34)
Jos Germn Nez Mori
Pgina 201 de 237
Figure 20: Abort. Usability-enabling design pattern. Sequence Diagrams Cancel command (W_SR-32)
Jos Germn Nez Mori
Pgina 202 de 237
Figure 21: Abort. Usability-enabling design pattern. Sequence Diagrams Cancel operation (W_SR-38 and W_SR-39)
Jos Germn Nez Mori
Pgina 203 de 237
Anexo 05: Especificacin Patrn de Usabilidad System Progress

Feedback
Jos Germn Nez Mori
Pgina 204 de 237
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]
205
Jos Germn Nez Mori
Pgina 205 de 237

HCI Recommendation
Elaboration
Progress Information Types
W_ELAB-19: Indeterminate progress
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]:
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
Whats currently going on,

What proportion of the operation is done so far,
How much time remains, and
How to stop it (or cancel it) if the time remaining is longer than
10 seconds [11].
About the remaining time [9]: If the timing can be calculated,
give an indication of the time remaining, either as a figure, or
graphically, use either a Time-remaining Progress Indicator or a
Proportion-completed Progress Indicator [11]; if timing can not
be estimated, but the process has identificable phases, give an
indication of the phases completed, and of the pahses remaining.
Use a Progress Checklist [11]; if neither of these possibilities
exist, then at least indicate the number of units processed
(records, vectors ....); if no quantities are known just that the
process may take a while- then simply show some indicator that
its still going on [7] [8], use an Indeterminate Progress Indicator
[11].
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
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_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_EX-20: Feedback Examples
W_Q-23
For which of these can actual

progress be calculated?
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.
W_Q-24
For those whose progress can be

calculated, which can provide the
following information?
A cancel button (or the option to

cancel through command-. for
shorter processes) is also provided.
W_Q-25
Identifiable phases completed
W_Q-26
Time remaining for completion
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).
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?
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
206
Jos Germn Nez Mori
Pgina 206 de 237
Figure 22: System Progress Feedback. Use Case Model
207
Jos Germn Nez Mori
Pgina 207 de 237
Figure 23: System Progress Feedback. System Responsibility Clusters

208
Jos Germn Nez Mori
Pgina 208 de 237

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

When the UI component (or alternate Progress Component) first displays the progress, it must do so indeterminately until it receives the first real progress update
from the Domain Component.
209
Jos Germn Nez Mori
Pgina 209 de 237

Objects
View
W_SR-44 Calculate and provide

ProgressIndicator
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.
6. The ProgressIndicator suscribes

to the corresponding DomainClass
for progress information.
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)
8. Upon reception of progress

information, the ProgressIndicator
updates the progress, performing
any needed calculations to do so. It
notifies the View.
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)
11. When ProgressIndicator

receives a notification that the
action being executed has ended it
sets the progress to competed and
notifies the View.
Fig
Monitor
Controller
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.
DomainClass
4. The DomainClass
starts executing the
invoked action
3,
4
7. The DomainClass
notifies its
subscribers (namely
the
ProgressIndicator) of
its progress
10. When the action
is completed,
DomainClass sends
out a notification
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
3,
4
W_SR-47 Provide indeterminate

1. Whenever a ProgressIndicator (that is not
3,
4
undetermined) is created, the view will initially paint it

as indeterminate until the first progress update is
received.
210
Jos Germn Nez Mori
Pgina 210 de 237
Figure 24: System Progress Feedback. Usability-enabling design pattern. Class diagram
211
Jos Germn Nez Mori
Pgina 211 de 237
Figure 25: System Progress Feedback. Usability-enabling design pattern. Sequence Diagram Display progress (W_SR-40, W_SR-41, W_SR-42, W_SR-43)
212
Jos Germn Nez Mori
Pgina 212 de 237
Anexo 06: Patrones de Usabilidad en la Elicitacin
213
Jos Germn Nez Mori
Pgina 213 de 237
Usability Elicitation Patterns (USEPs)

Natalia Juristo1, Ana Moreno1, Maria-Isabel Sanchez-Segura2
School of Computing - Universidad Politcnica de Madrid, Spain
natalia@fi.upm.es; ammoreno@fi.upm.es
2
Department of Computing - Universidad Carlos III de Madrid, Spain
misanche@inf.uc3m.es
1
August 2006
USEPs capitalize upon the know-how in elicitation so that requirements engineers

can reuse key usability issues intervening recurrently in different projects. We have
developed one USEP for each usability mechanisms in the following table. USEPs
support developers to extract all the necessary information to completely specify a
functional usability feature.
Usability
Feature
Feedback
Undo
Cancel
User Input
Errors
Prevention/
Correction
Wizard
User Profile
Usability
Mechanism
System Status
Interaction
Warning
Long Action
Feedback
Global Undo
ObjectSpecific Undo
Abort
Operation
Go Back
Structured
Text Entry
Goal
To inform users about the internal status of the system
To inform users that the system has registered a user interaction,
i.e., that the system has heard users
To inform users of any action with important consequences
To inform users that the system is processing an action that will
take some time to complete
To undo system actions at several levels
To undo several actions on an object
To cancel the execution of an action or the whole application
To go back to a particular state in a command execution sequence
To help prevent the user from making data input errors
Step-by-Step
Execution
To help do tasks that require different steps with user input and
correct such input
Preferences
Personal
Object Space
Favourites
To record each user's options for using system functions

To record each user's options for using the systems interface.
To record certain places of interest for the user
214
Jos Germn Nez Mori
Pgina 214 de 237
Help
Commands
Aggregation
Multilevel
Help
Commands
Aggregation
To provide different help levels for different users

To express possible actions to be taken with the software through
commands that can be built from smaller parts.
We have used HCI literature as a source of information. Then we have analysed the information provided
from a development perspective. Finally, we have elaborated this information to get a set of issues to be
discussed with stakeholders.
USEP for the System Status Feedback mechanism
IDENTIFICATION:
Name: System Status Feedback
Family: Feedback
Alias: Status Display [7]
Modelling Feedback Area [2]
PROBLEM
Which information needs to be elicited and specified para que la aplicacin provide users with system status
information.
CONTEXT
When changes that are important to the user occur or
When failures that are important to the user occur:
During task execution
Because there are not enough system resources
Because external resources are not working properly.
Examples of status feedback can be found in status bars on windows applications; train, bus or airline
schedule systems; VCR displays; etc.
SOLUTION
Usability Mechanism Elicitation Guide:
HCI Recommendation
1. HCI experts argue that the user wants to be notified
when a change of status occurs [7]
Issues to be discussed with stakeholders

Changes in the system status can be triggered by userrequested or other actions or when there is a problem
with an external resource or another system resource.
1.1 Does the user want the system to provide
notification of system statuses?. If so, which ones?
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?
notification if there are not enough resources to
execute the ongoing commands? If so, which
resources?
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
215
Jos Germn Nez Mori
Pgina 215 de 237
happens. Displays should be put together in a way

that emphasizes the important things, deemphasizes the trivial, doesnt hide or obscure
anything, and prevents one piece of information
from being confused with another. They should
never be re-arranged, unless users do so
themselves. Attention should be called to
important information with bright colours,
blinking or motion, sound or all three but a
technique appropriate to the actual importance of
the situation to the user should be used [7].
user?
2.2. Which of this information will have to be
displayed obtrusively because it is related to
a critical situation? Represented by a
salience in the main display area that
prevents the user from continuing until the
salient information is closed.
2.3. Which of this information will have to be
highlighted because it is related to an
important but not critical situation? Using
different colours and sound or motion, sizes,
etc.
2.4. Which of this information will be simply
displayed in the status area? Locating some
kind of salience in the system status area.
For each piece of system status information to be
displayed according to its importance, the range
will be from obtrusive things (for example, a
window in the main display area which prevents
the user from continuing until it has been closed),
through highlighting (with different colours,
sound, motion or sizes) to the least eye-catching
things (like a status-identifying icon placed in the
system status area). Note that during the
requirements elicitation process, the discussion of
the exact response type can be left until interface
design time, but the importance of the different
situations about which status information is to be
provided and, therefore, the general type of
salience (obtrusive, highlighted or standard) that
will be provided does need to be discussed at this
stage.
As regards the location of the feedback indicator, HCI

literature mentions that users want one place where they
know they can easily find this status information [2]. On
the other hand, aside from the spot on the screen where
users work, users are most likely to see feedback in the
centre or at the top of the screen, and are least likely to
notice it at the bottom edge. The standard practice of
putting information about changes in state on a status
line at the bottom of a window is particularly
unfortunate, especially if the style guide calls for
lightweight type on a grey background References
3.
3.1. Do people from different cultures use the

system? If so, the system needs to present the
system status information in the proper way
(according to the users culture). So, ask
about the users reading culture and
customs.
3.2. Which is the best place to locate the
feedback information for each situation?
[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].
Usability Mechanism Specification Guide:

The following information will need to be instantiated in the requirements document.
The system statuses that should be reported are X, XI, XII. The information to be shown in the status area
is..... The highlighted information is The obtrusive information is.
The software system will need to provide feedback about failures I, II, III occurring in tasks A, B, C,
respectively. The information related to failures I, II, etc. must be shown in status area. The information
216
Jos Germn Nez Mori
Pgina 216 de 237
related to failures III, IV, etc , must be shown in highlighted format. The information related to failures V, VI,
etc , must be shown in obtrusive format.
The software system provides feedback about resources D, E, F when failures IV, I and VI, respectively,
occur. The information to be presented about those resources is O, P, Q. The information related to failures I,
II, etc.must be shown in the status area..... The information related to failures III, IV, etc , must be shown in
highlighted format. The information related to failures V, VI, etc , must be shown in obtrusive format.
The software system will need to provide feedback about the external resources G, J, K, when failures VII,
VIII and IX, respectively, occur. The information to be presented about those resources is R, S, T. The
information related to failures I, II, etc.must be shown in the status area..... The information related to
failures III, IV, etc , must be shown in highlighted format. The information related to failures V, VI, etc ,
must be shown in obtrusive format.
USEP for the Interaction Feedback mechanism
IDENTIFICATION
Name: Interaction Feedback
Family: Feedback
Alias:
Interaction Feedback [9]

Modelling Feedback [2]
Let User Know Whats Going On [11]
PROBLEM
Which information needs to be elicited and specified in order to acknowledge the user that the system heard his/her
request
CONTEXT
When the user perform an interaction event, such us mouse click, mouse movement, arrow movement, keyboard press,
etc. the system must inform the user that the interaction has been accepted [2]
SOLUTION
Usability Mechanism Elicitation Guide
HCI Recommendation
1.
Give visual feedback proportional to the scale of the

interaction event and its significance, just to confirm to
the user that the system has registered the event.
Possibilities include, indenting a button, back-lighting a
word, changing the shape of the cursor or the objects
involed [9]. Give always visual feedback and allow the
user to enalble audio feedback for every interaction
event [9] [11]

1.1. For each action requested by the user, it should
be discussed which kina of acknowledge the
system will provide (indenting a button, backlighting a word, changing the shape of the
cursor or the objects involed, any other visual
or audio signal, etc). This topic can be discussed
in Interface Design task.
Verify that the application provides the feedback withing
0.1 milliseconds after each key press, movement of the
mouse, or other physical input from the user [11].
Usability Mechanism Specification Guide

The following information will need to be instantiated in the requirements document:
El sistema ha de responder a los interactions events A, B, C. C has high significance. The system response will be done in
0,1 miliseconds after the interaction from the user.
217
Jos Germn Nez Mori
Pgina 217 de 237
USEP for the Long Action Feedback mechanism

IDENTIFCATION
Name: Long Action Feedback
Family: Feedback
Alias: Progress Indicator [7] [8]
Progress [10]
Let User Know Whats Going On [11]
Show Computer is Thinking, Time to Do Something Else [9]
Modelling Feedback Area [2]
PROBLEM
Which information needs to be elicited and specified in order to provide users with information related with the
evolution of the requested tasks
CONTEXT
When a time-consuming process interrups the UI for longer than two seconds or so.
SOLUTION
HCI Recommendation
1.
2.
For on-going processes that take more than 2

seconds: If the process is critical, users should not be
allowed to do anything else until this task is
completed [10]. If the task is not critical and takes
over 5 seconds, users should be allowed to run
another operation if they so wish. Users should be
informed when the on-going operation finishes [9].
Show an animated indicator of how much progress
has been made. Either verbally or graphically (or
both). Tell the user [7] [8]:
o
o
o
o
whats currently going on,

what proportion of the operation is done so
far,
how much time remains, and
how to stop it (or cancell it) if the time
remaining is longer than 10 seconds [11].
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.1. How the user will be informed about the

progress of the different tasks, which information
would be desired for each one.
Verify that the application takes no longer than
1 second to display the progress indicator [11]; and
update the feedback at a rate that gives the user the
impression that the operation is still being performed,
e.g. every 2 seconds [10].
About the remaining time [9]: If the timing can be

calculated, give an indication of the time remaining,
either as a figure, or graphically, use either a Timeremaining Progress Indicator or a Proportioncompleted Progress Indicator [11]; if timing can not
be estimated, but the process has identificable phases,
give an indication of the phases completed, and of the
pahses remaining. Use a Progress Checklist [11]; if
neither of these possibilities exist, then at least
indicate the number of units processed (records,
vectors ....); if no quantities are known just that the
process may take a while- then simply show some
indicator that its still going on [7] [8], use an
Indeterminate Progress Indicator [11].
218
Jos Germn Nez Mori
Pgina 218 de 237

Tasks U, V, Z, takes more than 2 seconds so will require long action feedback. For them the information to be
shown will be R, S, T in part A, B, C, respectively.
Information must appear in less than 1 second and needs to be refreshed every 2 seconds.
RELATED PATTERNS
Abort Operation: for actions that take time to complete a Cancel option should be provided with the feedback
information
219
Jos Germn Nez Mori
Pgina 219 de 237
USEP for the Warning Feedback mechanism

IDENTIFICATION
Name: Warning
Family: Feedback
Alias: Warning [10]
Think Twice [9]
PROBLEM
Which information needs to be elicited and specified in order to ask for user confirmation in case the action requested
has irreversible consequences.
CONTEXT
When an action that has serious consequences has been required by the user [10] [9].
SOLUTION
HCI Recommendation
1.
For each action that a user may take, having regard

for: the reversibility of the action, the proportion of
reversible actions that the system supports, the
frequency with which the action is taken, the degree
of damage that may be caused, and the immediacy of
feedback, consider whether a warning, confirmation
or authorization may be appropriate.
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]:
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.
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.

Tasks U, V, Z, will require warning. For them the information to be shown will be R, S, T, respectively
RELATED PATTERNS
Abort Operation: One of the alternatives of the warning message should be to Cancel the action
220
Jos Germn Nez Mori
Pgina 220 de 237
USEP for the Global Undo mechanism

IDENTIFICATION
Name: Global Undo

Family: Undo/Cancel
Alias: Multi-Level Undo [7] [8];
Undo [10];
Global Undo [3];
Allow Undo [9]
PROBLEM
Which information needs to be elicited and specified in order to provide users with global undo information.
USABILITY CONTEXT
When building a highly interactive system with multiple and complex functionalities
SOLUTION
Usability Feature Configuration Guide
HCI Recommendation
221
Jos Germn Nez Mori
Pgina 221 de 237
1.
Users typically explore functionality of an application but

do not want to be punished when selecting unwanted
functions [10]. The ability to undo a long sequence of
operations lets users feed that the interface is safe to
explore. While they learn the interface, they can
experiment with it, confident that they arent making
irrevocable changes even if they accidentally do
something bad. So, first decide which operations need to
be undoable [7][8]:
- Any action that might change a file or similar thing
anything that could be permanent should be undoable,
while transient or view-related states often are not. To
be more specific, these kind of changes are expected to
be undoable in most applications:
o text entry for documents or spreadsheets
o database transactions,
o modifications to images or painting canvases
o layout changes position, size, stacking order,
grouping. ..
o file operations
o creation, deletion or rearrangement of objects such as
email messages or spreadsheet columns
o any cut, cut or paste operations
- The following kinds of changes are generally not
undoable. Even if you think it would be going above
and beyond the call of duty to make them undoable,
consider that you might thoroughly irritate users by
cluttering up the undo stack with useless undos:
o text or object selection,
o navigation between windows or pages,
o mouse cursor and text cursor locations,
o scrollbar position
o window or panel positions and sizes
o changes made in an uncommitted or modal dialog
- If a command has side effects that cannot be undone,
warn the user before executing the command and do not
queue it [10] (see feedback pattern for the warning
process).
- In any case, make sure the undoable operations make
sense to the user. They can be specific functions or a
meaningful group of actions (for example, changing the
printer settings) [10]. Be sure to define and name them
in terms of how the user thinks about the operations, not
how the computer thinks about them. Undoing a bunch
of typed text for instance, should be done in chunks of
words, not letter-by-letter.
1.1. Which particular actions will be permanent, and from

those ones which ones will have sense to make them
undoables?
222
Jos Germn Nez Mori
Pgina 222 de 237
2.
Users tend to explore a navigable artefact in a tree-like

fashion, going down paths that look interesting, then back
up out of them, then down another path [7][8]. So, an undo
stack will need to be created. Each operation goes on the
top of the stack as it is performed; each Undo reverses the
operation at the top, then the next,... The undo concept
must also include the concept of redo needed in case the
user backs up too many steps [3]. Redo works its way
back up the stack in a similar manner. The best undo
should preserve the tree structure of the command
execution sequence.
Often users want to reverse several actions instead of just
the last action [10]. So, the stack should be at least 10 to
12 items long to be useful, and longer if you can manage
it. Long-term observation or usability testing may tell you
what your usable limit is (Constantine and Lockwood
assert that more than a dozen items is usually unnecessary,
since users are seldom able to make effective use of more
levels. Expert users of high-powered software might tell
you differently. As always, know your users)
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.
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.1. Which is the best way to present the undo/redo

option and stack to the user?
Usability Feature Specification

Tasks U, V, Z will be able to be undone. The information to be shown in the stack for them is A, B, C.
The undo / redo stack will be able to record X tasks, and the information on this task will be presented in format T.
RELATED PATTERNS
Object Specific Undo: Some of the actions to be included in the general undo stack might be related to specific objects for
which to provide Object Specific Undo.
223
Jos Germn Nez Mori
Pgina 223 de 237
USEP for the Object-Specific Undo mechanism
IDENTIFICATION
Name. Object Specific Undo
Family: Undo/Cancel
Alias: Object-specific undo [3]
PROBLEM
Which information needs to be elicited and specified in order to provide users with object specific undo
information.
USABILITY CONTEXT
When building a highly interactive system with multiple and complex functionalities on specific objects of the
system
SOLUTION
Usability Feature Configuration Guide
HCI Recommendation
1.
The software system must provide the possibility for

the user to easily access (for example, through the
right button) the specific commands that affect such
an object. One should be the undo/redo function. In
this case, the system should filter the global undo
stack and show only the operations that affected the
state of the selected object [3].

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

Tasks U, V, Z will need to be able to be undone on objects A, B and C.
The undo option for these objects will be presented in format T.
RELATED PATTERNS
Global Undo: Actions for object specific undo must also appear in the Global Undo stack.
224
Jos Germn Nez Mori
Pgina 224 de 237
USEP for the Abort Operation mechanism

IDENTIFICATION
Name: Abort Operation
Family: UNDO/CANCEL
Alias: Emergency Exit [9]
Go Back to a Safe Place [7]
Go Back [7]
Cancellability [8]
PROBLEM
Which information needs to be elicited and specified in order to provide users with Abort Operation information.
USABILITY CONTEXT
When the user needs to exit an application or a command quickly.
SOLUTION
Usability Configuration Guide
HCI Recommendation
1.
Users who use a number of applications in the

course of their work may need rapidly to exit a
program when a higher priority task demands
the system resources, or when the program has
been launched by mistake [9]. So, at
application level, at all times ensure that the
option to quit a program is immediately and
obviously available (if possible even during the
initial loading of the program) and modal
dialogues do not mask the access to the option.
If the option to quit is exercised after work on
data manipulated by the program has been
completed, the option to save the work done
so far should be presented.
2.
At operation level, if the user gets into a space

or state that they dont want to be in, they will
want to get out of it in a safe and predictable
way. Also, backtracking out of a long
navigation path can be very tedious [7]. So, in
window-based GUI applications, it is standard
to have a Cancel buttom that closes any dialog
box and discards any change the user may have
made within the dialog box.
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].

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.1. Which actions may require a cancel option? Pay

special attention to actions that may require several
steps. Notice also that all actions en las que el
usuario es preguntado o se le solicita informacin
deben ser potencialmente cancelables.
2.2. For the previous actions, how should this cancel
option be presented to the user (remember that in
dialog boxes it is standard to have a cancel buttom),
and which will be the state where the system will go
when the cancel option is chosen?
3.1.Which actions will take more than 10 seconds to
finish?
3.2.Refer to the Long Feedback Pattern for details about
information to provide for them.
225
Jos Germn Nez Mori
Pgina 225 de 237
Usability Feature Specification Guide

The application will need an exit button that
Actions A, B, C require several steps to be taken and a cancel mechanisms will be needed to abort them.
Action W will take more than 10 seconds to finish so be sure that a cancel button is provided to abort it.
RELATED PATTERN
Long Action Feedback: for actions that take time to complete a Cancel option should be provided with the feedback
information
Go Back: If an action has a Cancel option, it might also have a Go Back option.
Step by Step Execution: In each step from a step by step execution action a Cancel option should be provided.
226
Jos Germn Nez Mori
Pgina 226 de 237
USEP for the Go Back mechanism
IDENTIFICATION
Name: Go back
Family: UNDO/CANCEL
Alias: Go back to a safe place [7]
Go Back One Step [7];
PROBLEM
Which information needs to be elicited and specified in order to provide users with Go Back information.
USABILITY CONTEXT
When there are interactive applications with multiple steps
SOLUTION
HCI Recommendation
1.
If the user gets into a space or state that they dont

want to be in, they will want to get out of it in a
safe and predictable way. Users may also forget
where they were, if they stop using the artefact
while they are in the middle of something and do
not get back to it for a while [7]. So,
Provide a way to step backwards to the

previous space or state. If possible, let the user
step backwards multiple times in a row, thus
allowing him to backtrack as far as he wants.
[7].

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?
Sometimes backtracking out of a long

navigation path can be very tedious [7]. So,
provide a way to go back to a checkpoint of the
users choice. That checkpoint may be a home
page, a saved file or state, the logical beginning
of a section of narrative or a set of steps.
Ideally, it could be whatever state or space a
user chose to declare as a checkpoint [7].
Usability Feature Specification Guide

Actions A, B, C require several steps to be taken, so provide an option to go back to states U, V, W

respectively.
RELATED PATTERNS
Step by Step Execution: Go back (to a safe place and one step) are usually incorporated in the wizard mechanism
Abort Operation: In such actions were a Go back option is provided a Cancel option may also be needed.
227
Jos Germn Nez Mori
Pgina 227 de 237
USEP for the Structured Text Entry mechanism

IDENTIFICATION
Name: Structured Text Entry
Family: User input errors prevention/correction
Alias: Structured Text Entry [7] [9]
Structured Format [8]
PROBLEM
Which information needs to be elicited and specified in order to provide users with structured text entry.
CONTEXT
When the system can only accept inputs from the user in a very specific format
SOLUTION
Usability Mechanism Configuration Guide
HCI Recommendation
1.
Rather than letting a user enter information into a

blank and featureless text field, put structure into
that text field. Divide it into multiple fields with
different relative sizes, for instance, or
superimpose a faint visual design on it (like
dividers or decimal points). Be careful not to
constrict the input so much that it makes things too
complicated, or so that it no longer fits the possible
input values that users may need to give it! Do
user testing as needed to judge whether or not it is
too annoying [7]. Once the user has typed all the
digits or characters in the first text field, confirm it
to him by automatically moving the input focus to
the next field [8]. Provide also examples and
default values so the user can have information
about the required format [9].

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 )

Data M and N will be entered by the user in format P and Q, respectively, so the software system will provide
the user with guidance for presenting this format in A and B ways, respectively.
228
Jos Germn Nez Mori
Pgina 228 de 237
USEP for the Step by Step mechanism
IDENTIFICATION
Name: Step by Step
Family: Wizard
Alias: Wizard [10] [8]
Step by step [7]
PROBLEM
Which information needs to be elicited and specified in order to provide users with the step by step mechanism
CONTEXT
When a non-expert user needs to perform an infrequent complex task consisting of several subtasks where
decisions need to be made in each subtask.
SOLUTION
HCI Recommendation
1.
Break up the operations constituting the task into a

series of chunks of groups of operations [8]. Take
the user through the entire task one step at a time
[10] [7]. When the task is started, the user is
informed about the goal that will be achieved and
the fact that several decisions are needed. If
information is needed from the user, ask for it in
simple terms and with brevity; by keeping it short,
you can better maintain the users sense of flow
through the whole step-by-step process [7].
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
doesnt necessarily need to know about all the
available paths through the task [10]. However the
users must be able to see where they are in the
sequence and which steps are to be done,
especially if there are more than 7 steps [7]. If
there are more than 10 steps, try to break the task
up into manageable sub-sequences, so it doesnt
get too tedious for the user [7]. These groups may
be thematic or alternatively, you may decide to
split up based on decision points [7][8]. Note that
the harder part is to balance the size and the
number of the sub-sequences.
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 sern las opciones de navegacin hacia

atrs en cada uno de los pasos, ya sea al paso
anterior o al comienzo de todas las tareas.
Usability Specification Guide

Actions A, B, C require several steps to be taken. The steps for A are U, V, R and information to be provided in
each step is R, S, T respectively. These steps will be represented in format J. The procedure is similar for
actions B and C.
RELATED PATTERNS
Go Back: Go back (to a safe place and one step) are usually incorporated in the wizard mechanism
229
Jos Germn Nez Mori
Pgina 229 de 237
Abort Operation: In such actions were a Go back option is provided a Cancel option may also be needed.
230
Jos Germn Nez Mori
Pgina 230 de 237
USEP for the Preferences mechanism

IDENTIFICATION
Name: Preferences
Family: User Profile
Alias: Preferences [10]
User preferences [7]
`PROBLEM
Which information needs to be elicited and specified in order to provide users with the preferences mechanism.
CONTEXT
When:
-
The application is very complex and many of its functions can be tuned to the users preference, and;
the system will be used by people with different abilities, cultures and tastes, and
not enough is known about the users preferences in order to assume defaults that will suit all users.
SOLUTION
HCI Recommendation
1.
Provide a place or working surface where users

can pick their own settings for things like
language, fonts, icons, colour schemes, and use of
sound. Allow users to save those preferences, so
that they do not have to spend time setting them
again, but do this per user if multiple people will
use it [7]. Let those preferences become the
default for each user on further use [10].
1.1. Will the application give the user the

opportunity to set up particular preferences (colors,
fonts, format, views, modos de seleccin de
funcionalidad, etc.? If so, which ones?
1.2. Will such preferences be different for each
user?
1.3. Which is the best way to show and let the users
choose such preferences?
2.
Devise a set of alternative canned settings that

users can choose between, if they dont like the
default and dont want to spend hours picking out
good combinations [7].
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?
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].

Options A, B, C will be able to be arranged for each user. These options will be presented in format F.
231
Jos Germn Nez Mori
Pgina 231 de 237
USEP for the Personal Object Space mechanism
IDENTIFICATION
Name: Personal Object Space
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
HCI Recommendation
1.
The user should be able to arrange things in a

1.3 Will users be able to arrange their own layout?
way that works best for him, since he knows
1.2 Will the system allow this to be done for each user?
more about how he works than the artefacts
designer does. This way he can better remember 1.3. Which elements should users be able to arrange?
where things are than if the items are arranged
for him [7]. Allow users to place things where
they want, at least in one dimension but
preferably in two. It is tedious for the user to do
all the item placement themselves, especially if
they want precision or a sorting order. So, start
out with a reasonable default layout. However,
permit stacking, moving, grouping, aligning,
neatness adjustments, sorting and other
layout operations. Do not capriciously rearrange
the users space, only do automatic layout if the
user specifically requests it. The artefact should
maintain the users layout between users.

Options A, B, C will be able to be arranged for each user. These options will be presented in format F.
232
Jos Germn Nez Mori
Pgina 232 de 237
USEP for the Favourites mechanism

IDENTIFICATION
Name: Favourites
Alias: Bookmarks [7]
Favourites [10]
PROBLEM
Which information needs to be elicited and specified in order to provide users with the favourites mechanism
CONTEXT
In a navigable software system, when the system is possibly large and complex and allows the user to move freely
through it in ways not directly supported by the artefacts structure
SOLUTION
HCI Recommendation
1.
Let the user make a record of their points of

interest, so that they can easily go back to them
later. The user should be able to label them, since
users are in a better position to choose labels that
are memorable to them. Save the list for later use
[7].
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?

The system will allow each user to record X places he or she has visited. They will be presented in format F to
the user.
233
Jos Germn Nez Mori
Pgina 233 de 237
USEP for the Multilevel Help mechanism

IDENTIFICATION
Name: Multilevel Help
Family: Help
Alias: Multilevel Help [8]
PROBLEM
Which information needs to be elicited and specified in order to provide users with the multilevel help mechanism.
CONTEXT
When the application to be developed is complex and a few users are likely to need a fully-fledged help system, but
most users wont take the time to use it; so, developers want to support both impatient and/or occasional users.
PROBLEM
HCI Recommendation
1.
Create help on several levels including some (but not

How complex are the tasks to be done by the
all) of the following list. Think of it as a continuum;
system?
each of these requires more effort from the user than
1.2 .Will expert users or novice users use the system?
the previous one [8]:
1.3. Which kind of tasks will probably require help to be
o Captions and instructions directly on the page,
done?
including patterns like Input Hints and Input
o
o
Prompt. Be careful not to go overboard with

1.4. Which kind of help procedure is best suited for such
these. If done with brevity, frequent users wont tasks?
mind them, but dont use entire paragraphs of
text few users will read them.
Tooltips. Use these to show brief, one-line
descriptions of interface features that arent
self-evident. For icon-only features, these are
critical; even nonsensical icons will be taken in
stride if the user can tell what it does by rolling
over it! Their disadvantages are that they
obscure whatevers under them, and that some
users find them irritating. A short time delay for
the mouse hover e.g. one or two seconds,
removes the irritation factor for most people.
Slightly longer descriptions that are shown
dynamically as users select or roll over certain
interface elements. Set aside an area of the page
itself for this, rather than using a tiny tooltip
popup.
Longer help texts contained inside Closable
Panels.
Help shown in a separate window, often done in
HTML via browsers, but sometimes in
WinHelp or MacHelp. These are often online
manuals, entire books, and are reached via
menu items on a Help menu, or from Hlp
buttons on dialogs and HTML pages.
Live technical support, usually by email, web
or telephone.

The system will provide help to the user.
For tasks A, B, C, . the help provided will be tooltips with . Information.
234
Jos Germn Nez Mori
Pgina 234 de 237
For tasks U, V the help will be captions with information
..
USEP for the Command Aggregation mechanism
IDENTIFICATION
Name: Commands Aggregation

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

2.
Provide a way to the user to play back the sequence at 2.1. How the aggregated command will be play backed?
any time. The play back should be as easy as giving a
single command, pressing a single button, or dragging
and dropping an object [8] even by speech it [7].
Feedback on the validity of the command or its result
should be as immediate as is practical [7][8].
Usability Mechanism Specification

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

Tesis MarcoAgilTrabajo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis MarcoAgilTrabajo

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD POLITECNICA DE MADRID

USABILIDAD EN METODOLOGAS GILES

Autor: JOSE GERMN NEZ MORI

Principales metodologas giles

Programacin Extrema (XP)

Principios bsicos .................................................................................. 17

Proceso de desarrollo ............................................................................ 18

Proceso Unificado gil (AUP)

Principio bsicos ................................................................................... 20

Proceso de desarrollo ............................................................................ 22

Agile model driven development (AMDD)

Principio bsicos ................................................................................... 23

Proceso de desarrollo ............................................................................ 24

Principio bsicos ................................................................................... 26

Proceso de desarrollo ............................................................................ 27

Dynamic Systems Development Method (DSDM)

Principios bsicos .................................................................................. 28

Proceso de desarrollo ............................................................................ 29

Feature Driven Development (FDD)

Principios bsicos .................................................................................. 31

Proceso de desarrollo ............................................................................ 33

Comparativa entre metodologas giles

Ciclo de vida del proyecto ..................................................................... 35

Estado Actual ........................................................................................ 37

Marco gil de trabajo

Fases del marco gil de trabajo

Inicio (Inception) ................................................................................... 47

Historias de Usuarios ............................................................................ 48

Pruebas de Aceptacin .......................................................................... 49

Product Backlog .................................................................................... 50

Prototipo de la arquitectura del sistema ................................................ 52

Estndar MDA (Model Driven Architecture)........................................ 54

3.1.7.1.1.1Usando MDA .................................................................................... 56

Fase de Desarrollo ................................................................................. 73

Fase de Inicio del Marco gil de Trabajo

Desarrollo de la fase de Inicio

Fase de Elaboracin del Marco gil de Trabajo

Desarrollo de la fase de Elaboracin

Planificacin de la Primera Iteracin

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

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

2.2.1.2 Diseo de la capa de negocio .............................................................. 103

Integracin del patrn de usabilidad Warning..................................... 109

2.2.2.1 Integracin del patrn de usabilidad Warning en la capa de presentacin

Integracin del patrn de usabilidad System Status Feedback ............ 115

2.2.3.1 Integracin del patrn de usabilidad SSF a la capa de presentacin y

Integracin del patrn de usabilidad Global Undo .............................. 121

2.2.4.1 Integracin del patrn de usabilidad GU a la capa de presentacin y capa

Integracin del patrn de usabilidad Abort Operation ........................ 127

2.2.5.1 Integracin del patrn de usabilidad AO a la capa de presentacin y capa

Integracin del patrn de usabilidad System Progress Feedback ........ 135

2.2.6.1 Integracin del patrn de usabilidad SPF a la capa de presentacin y

Integracin del patrn de usabilidad Abort Command........................ 143

2.2.7.1 Integracin del patrn de usabilidad AC a la capa de presentacin y capa

Planificacin tras la primera iteracin

VII. Referencias Bibliogrficas

Anexo 01: Especificacin Patrn de Usabilidad Warning

Anexo 02: Especificacin Patrn de Usabilidad System Status Feedback

Anexo 03: Especificacin Patrn de Usabilidad Global Undo

Anexo 04: Especificacin Patrn de Usabilidad Abort

Anexo 05: Especificacin Patrn de Usabilidad System Progress Feedback

Anexo 06: Patrones de Usabilidad en la Elicitacin

Figura 54: Adicin de nuevas relaciones considerando el patrn GU ................................................126