OpenUP/MMU ISO

OpenUP/MMU-ISO
Soporte para un proceso de desarrollo de software conforme al Modelo ISO de Madurez en Usabilidad
Andrs Rodr e guez
Director: Dr. Gustavo Rossi
Tesis presentada a la Facultad de Informtica a de la Universidad Nacional de La Plata como parte de los requerimientos para obtener el grado de Magister en Ingenier de Software a
La Plata 11 de octubre de 2010
c 2010 by Andrs Santiago Rodr e guez
iv
A la memoria de mi viejo
vi
Agradecimientos
Este trabajo llev ms tiempo del que deber y no hubiera sido posible sin el apoyo de o a a todos los que me acompaaron durante el trayecto. Impulsando, ayudando, aconsejando, n sosteniendo, muchos me ayudaron para que nalmente llegara a la meta. En primer lugar quiero agradecer a Nico, Fede, Mateo y Gaby. Fueron quienes ms a aguantaron el largo camino hasta este documento y a quienes ms priv por llegar hasta a e ac. a Luego al viejo que lo mira desde el cielo, a mam y a Juan. Siempre impulsaron y a apoyaron las ganas de seguir creciendo y aprendiendo. Finalmente al Lia, que me brind un ambiente propicio para desarrollar esta faceta. o Son muchas las personas de Lia que me ayudaron. Gustavo, Silvia, Gabriel y Alicia, que siguen conando en mi trabajo ms all de toda lgica. Casco, que nunca dej que perdiera a a o o las esperanzas. Y todos los lianos de transferencia, especialmente mis compaeros de n Medif, que me dieron material de sobra para comprobar la necesidad de tareas de diseo e n centrado en usuario en el desarrollo de software. Cada uno de ellos sabe cunto esfuerzo cost terminar esta tesis, cunto dej en el a o a e camino y cunto les debo a cada uno. Simplemente gracias! a
vii
viii
Indice general
Indice de guras Indice de tablas 1. Introduccin o
XIII XVII
I Ingenier de software, Usabilidad y Dise o Centrado en el a n Usuario 5

2. Deniciones preliminares 2.1. Usabilidad . . . . . . . . . . 2.2. Diseo de interaccin . . . . n o 2.3. Diseo Centrado en Usuario n 2.4. Capacidad y madurez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 9 9 11 13 13 14 14 15 15 17 17 18 20 20 21 22 24 25
3. Los procesos de desarrollo de software y el DCU 3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.2. Aproximaciones desde el campo HCI . . . . . . . . . . . . . . 3.2.1. La ingenier de usabilidad segn Nielsen . . . . . . . a u 3.2.2. El ciclo de vida en estrella de Hix y Hartson . . . . . 3.2.3. Diseo Centrado en el Uso de Constantine . . . . . . . n 3.2.4. Ciclo de vida de Ingenier de Usabilidad por Mayhew a 3.2.5. Los escenarios de Carroll y Rosson . . . . . . . . . . . 3.2.6. El proceso DCU de ISO . . . . . . . . . . . . . . . . . 3.3. Aproximaciones desde la Ingenier de Software . . . . . . . . a 3.3.1. La propuesta de Costabile . . . . . . . . . . . . . . . . 3.3.2. El Proceso Unicado . . . . . . . . . . . . . . . . . . . 3.3.3. DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Wisdom . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Oportunidad de intervencin . . . . . . . . . . . . . . . . . . o
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
II Capacidad y Madurez en Usabilidad con el Proceso Unicado 27

4. Proceso Unicado open source: OpenUP 4.1. Introduccin . . . . . . . . . . . . . . . . . o 4.2. El Eclipse Process Framework . . . . . . 4.3. La biblioteca de prcticas para el EPF . . a 4.4. OpenUP . . . . . . . . . . . . . . . . . . . ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 29 29 37 49
INDICE GENERAL
4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5.
Conguracin OpenUP/Basic o Fase de Inicio . . . . . . . . . Fase de Elaboracin . . . . . o Fase de Construccin . . . . . o Fase de Transicin . . . . . . o
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
51 52 53 54 54 57 57 58 58 59 59 59 61 61 61 62 62 64 64 65
5. Capacidad y madurez en usabilidad 5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . o 5.2. Modelos de madurez en usabilidad . . . . . . . . . . . 5.2.1. Madurez en Usabilidad Corporativa de Nielsen 5.2.2. Ehrlich y Rohn . . . . . . . . . . . . . . . . . . 5.2.3. Lundmark y Toresson . . . . . . . . . . . . . . 5.2.4. Trillium . . . . . . . . . . . . . . . . . . . . . . 5.2.5. IBM, Evaluacin de liderazgo en usabilidad . . o 5.2.6. El mtodo de Schaer . . . . . . . . . . . . . . e 5.2.7. INUSE HCS . . . . . . . . . . . . . . . . . . . 5.2.8. INUSE Procesos . . . . . . . . . . . . . . . . . 5.2.9. KESSU . . . . . . . . . . . . . . . . . . . . . . 5.3. El Modelo de Madurez en Usabilidad de ISO . . . . . 5.3.1. Modelo de referencia . . . . . . . . . . . . . . . 5.3.2. El contenido de MMU-ISO . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
6. Conformidad de OpenUP/Basic al MMU-ISO 71 6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 71 6.2. Metodolog de assesment . . . . . . . . . . . . . . . . . . . . . . . . . . . a 71 6.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.3.1. Capacidad en DCU1 (Asegurar el contenido de DCU en la estrategia de sistemas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.3.2. Capacidad en DCU2 (Planicar y gestionar el proceso DCU) . . . 75 6.3.3. Capacidad en DCU3 (Especicar los requerimientos de stakeholders y organizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 77 6.3.4. Capacidad en DCU4 (Entender y especicar el contexto de uso) . 78 6.3.5. Capacidad en DCU5 (Producir soluciones de diseo) . . . . . . . . n 79 6.3.6. Capacidad en DCU6 (Evaluar los diseos contra los requerimientos) 80 n 6.3.7. Capacidad en DCU7 (Presentar y operar el sistema) . . . . . . . . 81 6.4. Perles de capacidad y posibilidades de extensin . . . . . . . . . . . . . . o 81
III Soporte para obtener Capacidad y Madurez en Usabilidad con OpenUP 85

7. Extensin OpenUP/MMU-ISO o 7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.1.1. La creacin de Mtodos para la Biblioteca de Prcticas del EPF . o e a 7.1.2. La contribucin de esta Tesis: una Prctica y tres Conguraciones o a de mtodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 7.1.3. Trabajos relacionados y antecedentes . . . . . . . . . . . . . . . . . 7.2. Prctica: DesCU - Desarrollo Centrado en el Usuario . . . . . . . . . . . . a 7.2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2. Productos de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4. Orientaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Conguraciones de Mtodo: OpenUP/MMU-ISO . . . . . . . . . . . . . . e 87 87 87 89 89 93 94 102 121 139 139
INDICE GENERAL
xi 139 154 157 161 161 164 167 170 170 178 184 184 187 191
7.3.1. OpenUP/MMU-ISO N1 . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2. OpenUP/MMU-ISO N2 . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3. OpenUP/MMU-ISO N3 . . . . . . . . . . . . . . . . . . . . . . . . 8. Plugins del EPF Composer 8.1. El EPF Composer . . . . . . . . . . . . . . . . . . . . . . . 8.2. El uso del Composer . . . . . . . . . . . . . . . . . . . . . . 8.3. Plugins lgicos y f o sicos en la EPL . . . . . . . . . . . . . . 8.4. La familia de plugins OpenUP/MMU-ISO . . . . . . . . . . 8.4.1. El plugin de la Prctica DesCU . . . . . . . . . . . . a 8.4.2. El plugin de Conguracin OpenUP/MMU-ISO N1 o 8.4.3. El plugin de Conguracin OpenUP/MMU-ISO N2 o 8.4.4. El plugin de Conguracin OpenUP/MMU-ISO N3 o 9. Conclusiones Bibliograf a
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
IV
Apndices e
197
199 209 213 221
A. MMU-ISO: Procesos DCU B. MMU-ISO: Niveles de capacidad C. Assessment de OpenUP/Basic D. Software adjunto
xii
INDICE GENERAL
Indice de guras
2.1. Componentes de usabilidad segun Norma ISO 9241 . . . . . . . . . . . . . 3.1. 3.2. 3.3. 3.4. Modelo en Estrella, de [Hix and Hartson 1993] . . . . . . . . . . . . . . . Procesos lgicos en el Diseo Centrado en Uso . . . . . . . . . . . . . . . o n Ciclo de ingenier de Usabilidad segn [Mayhew 1999] . . . . . . . . . . . a u Ingenier de usabilidad basada en escenarios, segun [Rosson and Carroll a 2002] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. El proceso DCU en ISO 13407, [ISO/IEC 1999] . . . . . . . . . . . . . . 3.6. Inclusin de usabilidad en ciclo de vida de software segn Costabile . . . . o u 3.7. Arquitectura de procesos en RUP, segn [IBM 2005a] . . . . . . . . . . . u 3.8. Ejemplo de Mapa de Navegacin en el Plugin UX de RUP, segn [IBM 2005b] o u 3.9. Ciclo de vida DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10. Fases del proceso en WISDOM . . . . . . . . . . . . . . . . . . . . . . . . 3.11. Flujos de tareas, actividades, modelos y diagramas en WISDOM . . . . . 4.1. Esquema de un Framework de Prcticas . . . . . . . . . . . . . . . . . . . a 4.2. Marco conceptual para uso de SPEM 2.0 . . . . . . . . . . . . . . . . . . 4.3. Elementos de Metamodelo SPEM 2.0 . . . . . . . . . . . . . . . . . . . . . 4.4. Perles UML denidos en SPEM 2.0 para el paquete Contenido de Mtodo e 4.5. Perles UML denidos para el paquete Estructura de Procesos en SPEM 2.0 4.6. Relaciones entre deniciones de Rol, Tarea y Producto de trabajo . . . . . 4.7. WBS de Fases de Ciclo de vida riesgo-valor . . . . . . . . . . . . . . . . . 4.8. Diagrama de Flujo de Trabajo en SPEM 2.0 . . . . . . . . . . . . . . . . . 4.9. Diagrama de detalle de actividad en SPEM 2.0 . . . . . . . . . . . . . . . 4.10. Diagrama de Dependencias de Producto de Trabajo en SPEM 2.0 . . . . . 4.11. Bloques de Prcticas EPL . . . . . . . . . . . . . . . . . . . . . . . . . . . a 4.12. Ciclo de vida de la iteracin en OpenUP . . . . . . . . . . . . . . . . . . . o 4.13. Ciclo de vida Riesgo-Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14. Curvas de reduccin de riesgo y entrega de valor . . . . . . . . . . . . . . o 4.15. TDD en contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16. Ubicacin de OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.17. Actividades de una iteracin en la Fase de Inicio . . . . . . . . . . . . . . o 4.18. Actividades de una iteracin en la Fase de Elaboracin . . . . . . . . . . . o o 4.19. Actividades de una iteracin en la Fase de Construccin . . . . . . . . . . o o 4.20. Actividades de una iteracin en la Fase de Transicin . . . . . . . . . . . . o o 5.1. Procesos de Diseo en Usabilidad de KESSU . . . . . . . . . . . . . . . . n 5.2. Ciclo de vida de procesos DCU en MMU-ISO . . . . . . . . . . . . . . . . 6.1. Perl de Capacidad para un Nivel . . . . . . . . . . . . . . . . . . . . . . 6.2. Resultados para el Proceso DCU 1 . . . . . . . . . . . . . . . . . . . . . . xiii 8 15 16 18 19 20 21 22 23 23 24 25 30 30 31 31 32 32 34 35 36 36 38 43 45 46 48 50 52 53 54 55 64 67 72 74
xiv 6.3. 6.4. 6.5. 6.6.
INDICE DE FIGURAS
Cantidad de atributos por logro alcanzado para el Nivel 1 . . . . . . . Cantidad de atributos por logro alcanzado para el Nivel 2 . . . . . . . Cantidad de atributos por logro alcanzado para el Nivel 3 . . . . . . . El perl de capacidad por proceso DCU en niveles 1 a 3 de MMU-ISO
. . . .
. . . .
82 82 83 83 91 93 96 97 98 99 100 101 102 106 107 107 108 112 113 115 117 117 119 119 121 123 126 128 131 132 134 136 137 138 140 141 143 144 145 147 147 149 151 152 153 153 158 162 163
7.1. Patrn de entrega de plugin WEUCD, de [ATG 2010] . . . . . . . . . . . o 7.2. Flujo de actividades de Diseo de Usabilidad, segn [Goransson et al. 2003] n u 7.3. Asignaciones del Rol Patrocinador . . . . . . . . . . . . . . . . . . . . . . 7.4. Asignaciones del Rol L der Tcnico de Dominio . . . . . . . . . . . . . . . e 7.5. Asignaciones del Rol Representante de Usuarios . . . . . . . . . . . . . . . 7.6. Rol de Usuario nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7. Rol de Especialista en Experiencia de Usuario . . . . . . . . . . . . . . . . 7.8. Asignaciones del Rol Diseador de Experiencia de Usuario . . . . . . . . . n 7.9. Asignaciones del Rol Tester de Experiencia de Usuario . . . . . . . . . . . 7.10. Perl de Usuario segn Hackos para un agente de viajes . . . . . . . . . . u 7.11. Ejemplo de Personaje, de [Pruitt and Adlin 2006] . . . . . . . . . . . . . . 7.12. Ejemplo de Personaje, de [Pruitt and Adlin 2006] . . . . . . . . . . . . . 7.13. Lista de control para denir las tres Cs del Rol de Uso de [Constantine and Lockwood 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.14. Notacin en HTA, de [Lors 2001] . . . . . . . . . . . . . . . . . . . . . . o e 7.15. Ejemplo de HTA, de [Lors 2001] . . . . . . . . . . . . . . . . . . . . . . . e 7.16. Uso de CTT en la elaboracin de un Modelo de Tareas . . . . . . . . . . . o 7.17. Prototipo de IU de baja delidad . . . . . . . . . . . . . . . . . . . . . . . 7.18. Prototipo de IU de alta delidad . . . . . . . . . . . . . . . . . . . . . . . 7.19. Ejemplo de Storyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.20. Ejemplo de storyboard de UX con prototipos de pantallas de baja delidad 7.21. Mapa de navegacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.22. Mapa de relaciones entre Prctica DesCU y procesos MMU-ISO . . . . . . a 7.23. Ciclo de Vida de MMU-ISO . . . . . . . . . . . . . . . . . . . . . . . . . . 7.24. Denicin de la Tarea Identicar y Especicar el contexto de uso . . . . . o 7.25. Denicin de la Tarea Disear la UX . . . . . . . . . . . . . . . . . . . . . o n 7.26. Denicin de la Tarea Revisar el Diseo de la Experiencia de usuario . . . o n 7.27. Denicin de la Tarea Ejecutar pruebas de usabilidad . . . . . . . . . . . o 7.28. Denicin de la Tarea Ejecutar pruebas de usabilidad . . . . . . . . . . . o 7.29. Denicin de la Tarea Producir material de entrenamiento y soporte al o usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.30. Denicin de la Tarea Guiar y dar soporte al usuario en implementacin . o o 7.31. Iteracin t o pica de Fase de Inicio con DesCU . . . . . . . . . . . . . . . . 7.32. Actividad Iniciar el Proyecto en OpenUP/MMU-ISO N1 . . . . . . . . . . 7.33. Actividad: Identicar y renar requerimientos con la Prctica DCU . . . . a 7.34. Actividad: Acordar el abordaje tcnico con la Prctica DCU . . . . . . . . e a 7.35. Actividad: Planicar y gestionar la iteracin en OpenUP/MMU-ISO N1 . o 7.36. Iteracin t o pica de Fase de Elaboracin con DCU . . . . . . . . . . . . . . o 7.37. Actividad: Desarrollar la arquitectura y la UX en OpenUP/MMU-ISO N1 7.38. Actividad: Desarrollar un incremento de solucin . . . . . . . . . . . . . . o 7.39. Actividad: Testear la Solucin . . . . . . . . . . . . . . . . . . . . . . . . . o 7.40. Iteracin tipo de la Fase Construccin . . . . . . . . . . . . . . . . . . . . o o 7.41. Iteracin tipo de la Fase Transicin . . . . . . . . . . . . . . . . . . . . . . o o 7.42. Actividad: Guiar y dar soporte al usuario en implementacin . . . . . . . o 7.43. Detalle de la Actividad: Iniciar el Proyecto en OpenUP/MMU-ISO N3 . . 8.1. Pantalla de edicin de una Tarea en el Composer . . . . . . . . . . . . . . o 8.2. Estructura de organizacin del repositorio en el Composer . . . . . . . . . o
INDICE DE FIGURAS
xv 165 165 167 168 169 171 171 173 173 174 174 175 176 176 177 177 179 179 179 180 180 181 183 183 185 214 215 216 217 218 219
8.3. Creacin de un Rol dentro del Paquete de Contenido de Mtodo . . . . . o e 8.4. WBS del Ciclo de Vida OpenUP/MMU-ISO Nivel 1 . . . . . . . . . . . . 8.5. Ejemplo de sitio web generado con Composer . . . . . . . . . . . . . . . . 8.6. Tipos de plugins en EPL y relaciones entre ellos . . . . . . . . . . . . . . 8.7. Partes de un plugin y sus relaciones . . . . . . . . . . . . . . . . . . . . . 8.8. Ubicacin del Plugin Prctica DCU en Composer . . . . . . . . . . . . . . o a 8.9. Plugines f sicos de la Prctica DCU en Composer . . . . . . . . . . . . . . a 8.10. Estructura interna del plugin Base en la Prctica DCU . . . . . . . . . . . a 8.11. Relacin entre roles bsicos de EPL y roles de DCU . . . . . . . . . . . . o a 8.12. Descripcin de Diseador de UX . . . . . . . . . . . . . . . . . . . . . . . o n 8.13. Descripcin de Tester de UX . . . . . . . . . . . . . . . . . . . . . . . . . o 8.14. Deniciones de Tarea incluidas en el Plugin Base de la Prctica DCU . . a 8.15. Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Deo scripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 8.16. Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Pasos o 8.17. Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Proo ductos de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.18. Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Preo visualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 8.19. Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Preo visualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 8.20. Responsabilidad de Productos de Trabajo del Diseador de UX . . . . . . n 8.21. Responsabilidad de Productos de Trabajo del Especialista de UX . . . . . 8.22. Tareas denidas para contribuir asignaciones a las bsicas . . . . . . . . . a 8.23. Asignacin de roles a Entender y especicar Contexto de Uso mediante o contribucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 8.24. Asignacin de roles a Entender y especicar Contexto de Uso mediante o contribucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 8.25. Ubicacin de plugins f o sicos para conguraciones OpenUP/MMU-ISO Nx 8.26. Iteracin tipo en fase de Transicin de OpenUP/MMU-ISO N1 . . . . . . o o 8.27. WBS del Proceso de Entrega OpenUP/MMU-ISO N3 . . . . . . . . . . . C.1. C.2. C.3. C.4. C.5. C.6. Resultados para el Proceso DCU 1 . . . . . . . Evidencia para determinar Capacidad en DCU2 Resultados del assessment de DCU 3 . . . . . . Evidencia de capacidades OpenUP en DCU 4 . Evidencia de capacidad OpenUP en DCU 5 . . Resultados del assessment para DCU 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xvi
INDICE DE FIGURAS
Indice de tablas
3.1. DCU vs Diseo Centrado en Uso . . . . . . . . . . . . . . . . . . . . . . . n 4.1. Mapeo entre principios de OpenUP y valores del Maniesto Agil [Kent Beck 2001] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Modelo de Madurez en Usabilidad de Proyecto . . . . . . . . . . . . . . . 5.2. Modelo de Madurez en Usabilidad de Schaer . . . . . . . . . . . . . . . . 5.3. Prcticas de gestin en INUSE HCS . . . . . . . . . . . . . . . . . . . . . a o 6.1. Esquema de hoja de assessment . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Atributos a mejorar para dar conformidad a MMU-ISO en Nivel 1 . . . . 7.1. 7.2. 7.3. 7.4. Productos de Trabajo a incorporar . . . . Criterios generales de usabilidad . . . . . Medidas para objetivos de usabilidad . . . Mtodos para elaborar Modelos de Tareas e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
51 60 62 63 73 84 103 110 111 112 175 178 182
8.1. Relacin entre Productos de Trabajo y Slots . . . . . . . . . . . . . . . . . o 8.2. Relacin de las Tareas en Prctica DCU y las Disciplinas de la EPL . . . o a 8.3. Asignaciones de Roles a Tareas de DCU . . . . . . . . . . . . . . . . . . .
xvii
xviii
INDICE DE TABLAS
Cap tulo 1
Introduccin o
Motivacin y alcance o
La usabilidad es un atributo de calidad cuya importancia ha sido reconocida plenamente por la comunidad de ingenier de software. Ya no se discute la necesidad de que a cualquier producto pensado para interactuar con personas resulte fcil de utilizar, aproa piado a las tareas y usuarios para las que fue concebido y cuyo uso brinde diferentes grados de satisfaccin al usuario. La literatura da cuenta de fracasos de productos de software o o proyectos de desarrollo que nunca llegaron a instancias productivas por fallas asociables con usabilidad, como ha mostrado [Landauer 1996], por ejemplo. La expansin de las GUIs aument las posibilidades de interaccin de usuarios y ha o o o impulsado esa toma de conciencia. Lamentablemente, tambin ha servido para asociar casi e en forma exclusiva la usabilidad de una aplicacin con el diseo visual de sus pantallas. o n Es comn que los ingenieros de software, cuyas prcticas dominan los procesos y tcnicas u a e de construccin de software consideren la usabilidad como un tema de interfaz de usuario, o que hay que abordar al nal del desarrollo, luego de que la parte funcional del sistema ya ha sido especicada, diseada y, en algunos casos, construida. n Desde el campo de estudios sobre la Interaccin Humano Computadora (HCI) se han o desarrollado un conjunto de teor mtodos, tcnicas y herramientas para construir sisas, e e temas ms usables. Se ha mostrado que para conseguir usabilidad hace falta abordar el a diseo de la interaccin deseada de manera integral, enfocando no slo en las pantallas, n o o sino en todos los aspectos del software que impactarn nalmente sobre la calidad del a producto durante su uso [Sharp et al. 2007]. Tambin desde la ingenier de software se ha mostrado la relacin entre la usabilidad e a o de un sistema y aspectos de su desarrollo que tienen poco o nada que ver con sus interfaces grcas. Por ejemplo, las decisiones tempranas sobre la arquitectura del software pueden a afectar de manera signicativa el nivel de usabilidad alcanzable por un sistema ([Bass and John 2001a],[Folmer and Bosch 2005]). Para hacer frente al desaf de incorporar prcticas de desarrollo que promuevan el o a logro de mejores niveles de usabilidad, tanto desde la HCI como desde la IS se han realizado propuestas de cambios en procesos y mtodos de trabajo. e Desde el campo de la Interaccin Humano Computadora (HCI) se sostiene que la forma o de desarrollo denominada Diseo centrado en el usuario es necesaria para garantizar n el logro de los objetivos de usabilidad en el producto nal. Esta estrategia implica el involucramiento activo a lo largo de todo el ciclo de vida del producto de los diferentes afectados por el sistema nal, desde su usuario directo hasta quienes pagan por el software (que suelen no ser las mismas personas). Por su parte, la IS ha planteado la necesidad de establecer una Ingenier de Software a 1
Introduccin o
1.0
Centrada en Personas (HCSE) para resumir la idea de la necesidad de compatibilizar el enfoque proveniente de HCI y el tradicional de la IS [Seah et al. 2005], [Seah et al. 2009]. Sin embargo, an los mtodos de IS no incorporan masivamente las prcticas, tcnicas, u e a e herramientas y mtodos de interaccin y usabilidad. Seah ha indicado que la estruce o tura y tcnicas de HCI son todav relativamente desconocidas, subutilizadas, dif e a ciles de dominar y con poca integracin esencial en equipos de desarrollo de software[Seah and o Metzker 2004]. Los mtodos de usabilidad y HCI en general pueden ser dif e ciles de aplicar a la ingenier de software debido a las diferencias conceptuales y superposiciones entre ambos a campos. Estas superposiciones no estn formuladas claramente desde el punto de vista a de la IS forzando a las organizaciones que desarrollan software a realizar costosas investigaciones para introducir las tcnicas de usabilidad en tales prcticas. Por ejemplo, las e a actividades de ingenier de requerimientos que son abordadas tanto por HCI como por a la IS. La importancia del esfuerzo de integracin es a menudo errneamente minimizada. o o Para los desarrolladores promedio, la usabilidad slo afecta a la interfaz de usuario y o sta slo consiste en los elementos concretos con los cuales el usuario interacta y su e o u comportamiento de respuesta, por lo tanto se considera slo un asunto de diseadores o n grcos. Tales errores simplican el problema de integracin en la mente del ingeniero de a o procesos: como es un tema de diseadores grcos, slo requiere el agregado de actividades n a o de usabilidad en las reas de proceso en las cuales estos temas son considerados, con lo a cual se termina la superposicin. Si consideramos la usabilidad como un tema de proceso o de desarrollo, esto implica que hay que incluir actividades de usabilidad a lo largo de todo el proceso, con el desaf de integrar diferentes culturas de desarrollo en el mismo tipo de o actividad. Se sostiene que existe una relacin directa entre el nivel de usabilidad que alcanza un o producto y la utilizacin de un proceso de diseo centrado en usuario para desarrollarlo. o n Sin embargo, no todos los procesos se pueden convertir en centrados en usuario simplemente haciendo unas pocas modicaciones. Por ejemplo, la transformacin requerida para o un proceso o cultura organizacional basados en especicaciones detalladas que son producidas antes que cualquier diseo e implementacion ser muy drstica e impracticable. n a a La complejidad del lado humano en HCI hace casi imposible crear un diseo correcto en n la primera intencin. Aspectos cognitivos, sociolgicos, educativos, f o o sicos y emocionales pueden jugar un rol importante en cualquier interaccin entre el usuario y el sistema y o no se pueden predecir completamente. De las caracter sticas de un proceso centrado en usuario, la iteratividad es la unica que es intr nsecamente inherente al proceso de software. Otra de las dicultades se relaciona con la mejora controlada de los procesos, que permita acompaar desde la usabilidad el crecimiento de un equipo u organizacin en sus n o capacidades de ingenier de software. Para ello se han propuesto diferentes modelos de a capacidad y madurez (por ejemplo CMMI y SPICE/ISO 15504[ISO/IEC 2006]). En el campo de la usabilidad tambin se han desarrollado algunos de estos modelos que pueden e ser empleados como hojas de ruta para crecer en capacidad y madurez de usabilidad de manera previsible. El Modelo de Capacidad y Madurez en Usabilidad de la Organizacin o Internacional de Estndares (ISO) que fue desarrollado de manera iterativa y con revisin a o de expertos, intenta proveer una base para que quienes planican sepan qu actividades e centradas en los usuarios incluir en un proyecto en particular, as como asistir a quienes desean mejorar la manera en que sus equipos realizan tales actividades. El MMU-ISO est contenido en el reporte ISO TR 18529 que tiene como modelo de a referencia a SPICE y utiliza su misma estructura: una dimensin de procesos versus una o de capacidades. MMU-ISO dene siete reas de proceso para el Desarrollo Centrado en a el Usuario: Asegurar contenido DCU en la estrategia de sistemas, Planicar y gestionar el proceso DCU, Especicar los requerimientos de stakeholders y organizacin, Entender o
1.0
y especicar el contexto de uso, Producir soluciones de diseo, Evaluar los diseos contra n n los requerimientos, Presentar y operar el sistema. La capacidad en uno de estos procesos se mide en la escala de seis grados propuesta por ISO 15504: Incompleto, Realizado, Gestionado, Establecido, Predecible, Optimizado. En este contexto, la tesis se plantea dos objetivos. Por un lado, extender uno de los procesos de desarrollo ms adoptados en la comunidad de IS (el Proceso Unicado) para a facilitar su instanciacin como centrado en usuario y mejorar las promesas de usabilidad o al aplicarlo. Por otro, proveer con esa extensin una especie de hoja de ruta que permita o a las organizaciones de software crecer en la capacidad y madurez con la que emplean las prcticas de usabilidad. a Para ello ser necesario revisar las propuestas de incorporacin al desarrollo de software a o de actividades de usabilidad, describir el MMU-ISO y analizar el Proceso Unicado a la luz del MMU de ISO. Esta evaluacin permitir determinar que el nivel de Capacidad y o a Madurez en Usabilidad alcanzable con ese proceso. Luego se propondrn las adaptaciones necesarias al Proceso Unicado que permitan a satisfacer la necesidad de incluir actividades de usabilidad y hacerlo de una manera que permita conformar al MMU-ISO como hoja de ruta. Utilizaremos para este trabajo la versin open source del Proceso Unicado, liberada por IBM a la Fundacin Eclipse y o o conocida como OpenUP.
Estructura de la tesis
La tesis est organizada en tres partes. La primera (Cap a tulos 2 y 3) plantea las deniciones bsicas que utilizaremos en el resto del trabajo (usabilidad, diseo de interaccin, a n o capacidad en usabilidad, etc.) y revisa los mtodos de desarrollo de software que proponen e la inclusin del diseo centrado en usuario generadas desde el campo de HCI y desde la o n Ingenier del Software. a La segunda parte se compone de tres cap tulos. En el primero, presentamos la versin o open source del Proceso Unicado, denominada OpenUP, que es una instanciacin del o framework de buenas prcticas conocido como EPL (Eclipse Practice Library). En el a segundo, presentamos el MMU-ISO. Cerramos esta segunda parte con un assessment de la conformidad al MMU-ISO de OpenUP con el objetivo de determinar las oportunidades de integracin de usabilidad en el Proceso Unicado. o Finalmente, en la tercera parte presentamos la contribucin de la tesis: una nueva o Prctica para agregar a la EPL, el Desarrollo Centrado en Usuario (DesCU), y tres ina stanciaciones del framework basadas en OpenUP que permitirn alcanzar los niveles 1, 2 o a 3 de Capacidad en Usabilidad en el marco del MMU-ISO. En el ultimo cap tulo mostramos la implementacin de la Prctica DesCU y de las tres conguraciones como extensiones o o a plugins para el Eclipse Process Framework Composer.
Introduccin o
1.0
Parte I
Ingenier de software, a Usabilidad y Dise o Centrado n en el Usuario
Cap tulo 2
Deniciones preliminares
Introduccin o
Esta tesis entrelaza la nocin de usabilidad con procesos de desarrollo de software y o modelos de capacidad y madurez. Para facilitar la unicacin del lenguaje en el resto del o trabajo, en este cap tulo simplemente presentamos las deniciones bsicas de los cuatro a conceptos que utilizaremos: usabilidad, diseo de interacciones, diseo centrado en usuario n n y capacidad en usabilidad.
2.1.
Usabilidad
Nacida en el marco de los estudios sobre la interaccin entre las personas y los sistemas o de software, conocido como HCI (por las iniciales de Human Computer Interaction), la usabilidad ha recorrido un camino largo hasta comenzar a ser reconocida en las ultimas dos dcadas como una contribucin importante a la calidad de un producto. e o Desde las aplicaciones que se ejecutan en mquinas de escritorio, pasando por las que a corren en dispositivos mviles de comunicaciones hasta aquellas que estn embebidas en o a artefactos de uso tan espec como un medidor de nivel de glucosa en sangre, todas deben fico gran parte de su xito a la mayor o menor posibildad de que quienes deben interactuar e con ellas puedan hacerlo con algn grado de eciencia, ecacia y satisfaccin. u o Existen diferentes deniciones de usabilidad. Algunas provienen de los pioneros del campo, otras de los intentos por sistematizar y encuadrar a la disciplina en el contexto de los procesos de construccin de software. o Uno de los profesionales ms respetados del campo y gestor de gran difusin alcanzada a o por la disciplina, Jakob Nielsen, la present en Usability engineering vinculada a cinco o atributos esenciales que debe mostrar un sistema: facilidad de aprendizaje, eciencia, recordabilidad, gestin de errores, satisfaccin de usuario [Nielsen 1993]. o o La norma ISO 9126 sigui de alguna manera este enfoque al denir la usabilidad o con cuatro atributos del sistema: facilidad para aprender, capacidad de comprensin, o operabilidad y atractivo [ISO/IEC 2000b]. La denicin que aplicaremos en esta tesis es la que luego ISO estableci en la Norma o o 9241-11 ISO/IEC [1998]: La medida en la que un producto se puede usar por los usuarios especicados para alcanzar sus metas con efectividad, eciencia y satisfaccin en un o contexto de uso especicado Esta denicin representa un contexto ms amplio de usabilidad, enfatizando la relacin o a o entre la usabilidad de un producto y el contexto de uso para el cual fue pensado. La gura 7
2.2
2.1 muestra grcamente los componentes de usabilidad planteados en ISO 9241-11 y la a relacin entre ellos. o
Figura 2.1: Componentes de usabilidad segun Norma ISO 9241 La denicin de ISO 9241-11 ha comenzado a convertirse en el estandar de facto, utio lizada entre otros para la elaboracin del CIF (Common Industry Format) para las pruebas o de usabilidad, acordado entre las principales corporaciones y organizaciones involucradas en el desarrollo de software [ANSI 2001]. Es interesante observar que esta denicin indica que la usabilidad no es una propiedad o absoluta de un producto sino que existe en relacin con los usuarios especicados de ese o producto (lo que es lo mismo que decir que un sistema puede ser muy usable para algunos, pero inusable para otros). Incluso, para cada usuario la usabilidad estar relacionada con a el logro de las metas en un entorno de uso denido. Finalmente, la usabilidad es una caracter stica mensurable denida con tres atributos: efectividad, eciencia y satisfaccin. o Por ejemplo, un objetivo de usabilidad para un sistema para gestin de nanciadoras o de salud podr establecerse de la siguiente manera: a
El 85 % [efectividad ] de 10 liquidadores con experiencia [usuario especicado] pueden liquidar la facturacn de una internacin por una apendisectom o o a [meta especicad a] en menos de una hora [eciencia] con una tasa de satisfaccin de 7 puntos sobre una escala de 1 a 10 [satisfaccin] en cualquier estacin o o o de trabajo de la empresa [entorno de uso] Cualquier producto tiene normalmente diferentes grupos de usuarios. Algunas de las metas sern compartidas por ms de un grupo y habr otras metas exclusivas de algn a a a u grupo. Esta diferencia entre los usuarios, sus metas y sus entornos de uso se extiende a la usabilidad y por lo tanto las medidas esperables de la misma sern diferentes para cada a grupo. La usabilidad no es, entonces, una medida unica, sino un conjunto de mediciones de efectividad, eciencia y satisfaccin que a su vez son funciones de los usuarios, sus metas o y sus entornos de uso.
2.3
Diseo de interaccin n o
2.2.
Dise o de interaccin n o
Las deniciones de usabilidad indican como hemos visto que el logro de niveles adecuados de usabilidad est a ntimamente relacionado con las interacciones que el producto o sistema permite y soporta en su relacin con los usuarios. o Esa interaccin no es un producto natural o algo que viene dado simplemente por la o aplicacin correcta de tcnicas de Diseo de software o de Diseo grco para las pantallas. o e n n a Debe ser diseada expl n citamente. Se trata de plantear el Diseo del software en un marco ms amplio, el de crear n a experiencias de usuario que mejoren y aumenten el modo en que la gente trabaja, se comunica e intercata. Como ha senalado Winograd, se trata de disear espacios para u n la comunicacin e interaccin humana [Winograd 1997]. o o Cmo se integra el Diseo de interacciones con las otras disciplinas que participan o n en el Diseo de sistemas basados en software como la ingenier del software? Sharp y n a sus colegas [Sharp et al. 2007] plantean la misma analog con la construccin de edicios a o que alguna vez utilizara Terry Winograd. Se trata de observar los diferentes aspectos de un mismo edicio que abordan los arquitectos y los ingenieros civiles. Los primeros estn preocupados con la gente y sus interacciones entre s y con los espacios construidos a (es correcto el balance entre espacios pblicos y privados? estn sucientemente cerca los u a lugares para cocinar y para comer? el lugar se puede usar para vivir de otra manera?). Los ingenieros, en cambio se interesan en aspectos vinculados con la realizacin del proyecto o (costo, duracin, estructura, regulaciones, mtodos constructivos, etc). o e El Diseo de interaccin entonces tiene que ver con el Diseo para la experiencia del n o n usuario. Como plantea Jesse Garret: todos los productos que son utilizados por alguien tienen una experiencia de usuario: diarios, botellas de ketchup, sillones, sweaters [Garrett 2002]. Y lo mismo vale para los productos y sistemas basados en software. Se trata de disear para una relacin entre la gente y el producto. Es obvio que uno no puede n o disear la experiencia del usuario, sino disear para esa experiencia. No se puede disear n n n una situacin de satisfaccin o de efectividad, pero se pueden incluir en el sistema caraco o ter sticas que generen o evoquen satisfaccin y que permitan alcanzar las metas deseadas o con el compromiso optimo entre las habilidades y capacidades del usuario y los desaf os de la tarea. En este contexto, el diseo de la interaccin es la parte del proceso donde las metas de n o usabilidad deber ser tenidas en cuenta para establecer las acciones de diseo necesarias an n para que el producto nal provea una experiencia de usuario que permita alcanzar tales metas.
2.3.
Dise o Centrado en Usuario n
Para obtener productos usables, prevalece como paradigma del proceso de ideacin, o construccin e implementacin lo que se conoce como Diseo Centrado en el Usuario o o n (DCU), tambin denominado ingenier de usabilidad o diseo centrado en las personas. e a n El Diseo Centrado en Usuario ha sido descripto por ejemplo por [Hix and Hartson n 1993], [Beyer and Holtzblatt 1998], [Mayhew 1999] o [Sharp et al. 2007]. La organizacin o ISO tambin ha planteado el DCU como forma de obtener productos usables en las Normas e 13407 [ISO/IEC 1999] y el Reporte 18529 [ISO/IEC 2000a]. En [Sharp et al. 2007], uno de los libros de texto ms completos sobre el Diseo de a n interaccin, Sharp y sus colegas citan el seminal trabajo de Gould y Lewis [Gould and o Lewis 1985], que propugna tres principios claves de un proceso DCU: 1. Poner foco en usuarios y sus tareas desde el comienzo. Esta deber ser la fuerza cona ductora del desarrollo. Conocer a los usuarios implica estudiar su comportamiento y
10
2.4
el contexto de uso para disear un sistema que les d soporte. Adems los usuarios n e a deben ser consultados durante todo el proceso de desarrollo y sus opiniones, tenidas en cuenta seriamente. 2. Establecer metas claras de usabilidad y experiencia que permitan realizar mediciones emp ricas para saber si se avanza en su obtencin durante el proyecto o 3. Disear de manera iterativa, caracter n stica esencial de un proceso que permita a usuarios y diseadores comprender a fondo el dominio a medida que se encuentran n soluciones y se descubren nuevos problemas. Otros autores respetados en la formacin de profesionales de HCI, Ben Schneidero man [Shneiderman et al. 2009] y John Carroll [Carroll 1995], caracterizan un proceso de desarrollo para la usabilidad con cuatro atributos en la misma l nea: El diseo es un proceso, no es un estado ni puede ser representado adecuadamente n en forma esttica. a El proceso de diseo es esencialmente no jerrquico, ni top-down ni bottom-up. n a El proceso es radicalmente transformador, involucra el desarrollo de soluciones parciales y provisionales que incluso pueden ser descartadas para el diseo nal n El diseo involucra intr n nsecamente descubrir nuevas metas Como vemos un proceso de desarrollo para la usabilidad tiene dos caracter sticas esenciales: focaliza desde el comienzo en usuarios reales y los involucra en el proyecto para conocer sus requerimientos cabalmente y es intr nsecamente iterativo, un devenir de aproximaciones sucesivas e incrementales hacia la solucin de un problema que slo o o ser plenamente descubierto al llegar al punto nal. a En esta tesis utilizaremos como referencias principales los estndares y reportes de a ISO. Ms adelante describiremos en detalle el proceso DCU denido en las mismas. a Aqu planteamos slo las principales actividades que ISO establece para un proceso DCU o [ISO/IEC 1999]: Entender y especicar el contexto de uso: quin es el usuario, su entorno de uso y e las tareas para las que el producto ser utilizado. a Especicar los requerimientos del usuario y la organizacin: determinar los criterios o de xito de usabilidad del producto en trminos de las tareas del usuario. Establecer e e gu y restricciones de diseo. as n Producir soluciones de diseo: incorporar en las soluciones todo el conocimiento n disponible sobre interaccin hombre-computadora o Evaluar los diseos contra los requerimientos: testear los diseos contra las tareas n n del usuario. Estas actividades lamentablemente todav no forman parte de todos los procesos a de desarrollo de software. En algunos casos, aunque estn presentes, su impacto en el e proceso de desarrollo es casi imperceptible. Varios trabajos han sealado el desaf de n o mejorar la insercin del DCU en las organizaciones de desarrollo de software, por ejemplo o el conjunto de trabajos presentados en la serie de Conferencias para una Ingenier de a Software Centrada en las Personas (Human Centered Software Engineering), recogidas en [Seah et al. 2005] y [Seah et al. 2009]
2.4
Capacidad y madurez
11
2.4.
Capacidad y madurez
En el dominio de los modelos de mejoras de procesos de software, un nivel de capacidad (capability level ) se dene por el logro alcanzado en el manejo de un conjunto apropiado de prcticas espec a cas y genricas para un rea de proceso. En cambio, un nivel de e a madurez (maturity level ) se dene como una mejora de procesos transversal a un conjunto predenido de reas en las cuales todas las metas en el conjunto son obtenidas [SEI 2006]. a Por lo tanto, podemos decir que la capacidad en usabilidad mide el nivel con que una organizacin lleva adelante alguna de las reas o aspectos de un proceso de diseo centrado o a n en usuario. La madurez en usabilidad es una evaluacin de qu tan avanzada est una o e a organizacin respecto de las diferentes vistas del proceso de desarrollo. o Ambas, capacidad y madurez en usabilidad, denen la caracter stica de una organizacin que determina su habilidad para desarrollar en forma consistente productos con un o nivel de usabilidad alto y competitivo [Jokela 2001a]. Cuando una organizacin de desarrollo alcanza alto nivel de capacidad en usabilidad, el o proceso DCU que utiliza es lo sucientemente efectivo y eciente para generar productos y sistemas usables. Del mismo modo, un bajo nivel de capacidad en usabilidad suele revelar la inexistencia (o falta de efectividad) de un proceso DCU. Cmo conseguir o mejorar el nivel de capacidad en usabilidad de una organizacin? o o En el mundo de la ingenier de software se han desarrollado modelos de evaluacin de a o procesos para guiar los esfuerzos de mejora, por ejemplo [ISO/IEC 2006], [Kuvaja 1995], [Paulk 1995]. Mediante la evaluacin de los procesos se puede identicar las fortalezas y o debilidades de una organizacin de software y usar esta informacin para encarar acciones o o de mejora. De la misma manera, en el campo del diseo centrado en usuario, existen n modelos de capacidad en usabilidad. Siguiendo la misma lgica, se desarrollaron modelos de capacidad y madurez en usabilo idad. Mediante la evaluacin de la capacidad en usabilidad se pueden desarrollar acciones o de mejora que aumenten la capacidad en usabilidad de una organizacin. o Este trabajo utilizar el modelo de capacidad en usabilidad presentado por la ISO en a ISO TR 18529 [ISO/IEC 2000a] para proponer una extensin de la versin open source o o del Proceso Unicado cuya instanciacin brinde un proceso con conformidad a ese modelo o de capacidad y madurez.
12
2.4
Cap tulo 3
Los procesos de desarrollo de software y el DCU

3.1. Introduccin o
Los mtodos de usabilidad y HCI en general pueden ser dif e ciles de aplicar a la ingenier de software debido a las diferencias conceptuales y superposiciones entre ambos a campos. Algunas actividades relacionadas con la ingenier de requerimientos y el testing a son abordadas tanto por usabilidad como por la ingenier de software. Estas superposia ciones no estn formuladas claramente desde el punto de vista de la IS forzando a las a organizaciones que desarrollan software a realizar costosas investigaciones para introducir las tcnicas de usabilidad en tales prcticas. e a La importancia del esfuerzo de integracin es a menudo errneamente minimizada o o debido a una percepcin equivocada de la usabilidad: se la considera slo vinculada con la o o interfaz de usuario. Para los desarrolladores promedio, la interfaz de usuario consiste en los elementos concretos con los cuales el usuario interacta y su comportamiento de respuesta, u por lo tanto se considera slo un asunto de diseadores grcos. Tales errores simplican o n a el problema de integracin en la mente del ingeniero de procesos: como es un tema de o diseadores grcos, slo requiere el agregado de actividades de usabilidad en las reas de n a o a proceso en las cuales estos temas son considerados, con lo cual se termina la superposicin. o Si consideramos la usabilidad como un tema de todo el proceso de desarrollo, esto implica que hay que incluir actividades de usabilidad a lo largo del ciclo de vida completo, con el desaf de integrar diferentes culturas de desarrollo en el mismo tipo de actividad. o Varios autores han sealado por ejemplo, la relacin entre las decisiones tempranas sobre n o la arquitectura de software y la usabilidad que es posible alcanzar luego [Bass and John 2001b],[Bass and John 2001a],[Folmer and Bosch 2005]. En el cap tulo anterior mostramos la relacin entre el nivel de usabilidad de un proo ducto y un proceso de diseo centrado en usuario. Sin embargo, no todos los procesos n se pueden convertir en centrados en usuario simplemente haciendo unas pocas modicaciones. La transformacin requerida para que un proceso o la cultura de una organizacin o o basada en un ciclo de vida en cascada se convierta en centrada en usuario seria muy drstica. Esta aproximacin implica que especicaciones detalladas son producidas antes a o que cualquier diseo e implementacion. La complejidad del lado humano en HCI hace n casi imposible crear un diseo correcto en la primera intencin. Aspectos cognitivos, son o ciolgicos, educativos, f o sicos y emocionales pueden jugar un rol importante en cualquier interaccin entre el usuario y el sistema y no se pueden predecir complemtamente. De o las caracter sticas de un proceso centrado en usuario, la iteratividad es la unica que es intr nsecamente inherente al proceso de software. 13
14
3.2
A continuacin mostramos algunas de las propuestas de integracin de actividades de o o usabilidad y diseo de interaccin en los procesos de desarrollo de software. Comenzamos n o con las que surgieron del campo de HCI y luego completamos con las originadas en la Ingenier de Software. Cerramos el cap a tulo describiendo la oportunidad de intervencin o que detectamos y que motiva gran parte de este trabajo.
3.2.
Aproximaciones desde el campo HCI
En la literatura de HCI existen varios reportes de modelos para procesos de desarrollo de software que buscan integrar las tcnicas de diseo de interaccin para la usabilidad e n o con las actividades propias de los ingenieros de software. En esta parte del cap tulo vamos a presentar algunos de ellos. Hacemos una breve referencia al tipo de proceso propuesto por Nielsen y despus describimos los procesos propuestos por Hix y Hartson (conocido e como Ciclo de Vida en Estrella), Constantine y Lockwood (Diseo Centrado en el Uso), n el Ciclo de Vida de la ingenier en usabilidad de Mayhew, el Ingenier de Usabilidad a a Basada en Escenarios de Carroll y Rosson y la propuesta del Proceso del Diseo Centrado n en el Usuario de las Normas ISO.
3.2.1.
La ingenier de usabilidad seg n Nielsen a u
Aunque ha sido superado por intentos posteriores, incluimos aqu una brev sima descripcin del ciclo de vida para la ingenier de usabilidad propuesto por Nielsen en Usabilo a ity Engineering [Nielsen 1993], porque contiene las semillas de procesos que luego vieron la luz a ra de la difusin de este trabajo. z o Nielsen enfatiza que la ingenier de usabilidad no es algo que se consiga en un solo a intento, sino un conjunto de actividades que tienen lugar a lo largo de todo el ciclo de vida de un producto, con actividades importante que tienen lugar en las etapas tempranas del diseo, mucho antes de que la interfaz de usuario sea siquiera imaginada ([Nielsen 1993], n pg. 71). Las principales etapas de un modelo de ciclo de vida para la ingenier de a a usabilidad sealadas en esa obra son: n 1. Conocer al usuario (caracter sticas de los usuarios individuales, tareas actuales y deseadas de los usuarios, anlisis de funciones, evolucin del usuario y su trabajo, a o anlisis de la competencia) a 2. Establecer metas de usabilidad. 3. Diseo en paralelo. n 4. Diseo participativo. n 5. Diseo coordinado de la interfaz completa. n 6. Aplicar gu y heur as sticas para anlisis. a 7. Prototipar. 8. Pruebas emp ricas. 9. Diseo iterativo, capturar el rationale del diseo. n n 10. Reunir feedback del uso real.
3.2
15
3.2.2.
El ciclo de vida en estrella de Hix y Hartson
El Ciclo de vida en Estrella [Hix and Hartson 1993] es un proceso centrado en usuario que establece las principales actividades de usabilidad. No prescribe un orden particular para estas actividades, pero reserva un rol prominente a la evaluacin de usabilidad, colocada en el centro de la estrella como puede observarse o en la Figura 3.1. Hix y Hartson describen los caminos de comunicacin que deber seguir entre activio a dades de usabilidad y diseo de software. Separan estrictamente el desarrollo de la IU n del desarrollo del resto del software, con dos actividades que las conectan: el anlisis del a sistema y el testing o evaluacin. Constituye una aproximacin simplista a la integracin o o o entre SE y HCI, pero los autores reconocen que la investigacin es necesaria para entender o mejor y dar soporte a las necesidades reales de comunicacion en procesos complejos.
Figura 3.1: Modelo en Estrella, de [Hix and Hartson 1993]
3.2.3.
Dise o Centrado en el Uso de Constantine n
[Constantine and Lockwood 1999] proponen el Mtodo de Diseo Centrado en el Uso e n como una coleccin de actividades coordinadas que contribuyen a la usabilidad. El modo elo de estas actividades incluye algunas que corresponden con un proceso de desarrollo de software ms ampllio, junto con actividades exclusivamente de usabilidad. El modelo a que Constantine y Lockwood proponen es atractivo para los ingenieros de software porque estn ms cercanos que otros a la clase de modelizacin usada en su disciplina. En para a o ticular, los casos de uso esenciales, que son la piedra angular de esta aproximacin, son o una reinterpretacin de la tcnica de los casos de uso, muy popular en la orientacin a o e o objetos. Sostienen que ms all de todos los debates sobre terminolog y responsabilidades a a as respecto de las interfaces entre las personas y el software, nalmente se requiere la solucin o de problemas de diseo en tres reas n a ntimamente relacionadas: arquitectura, presentacin o e interaccin. Estos tres aspectos del diseo de interfaces interactan fuertemente entre o n u s y son nalmente inseparables. Cualquier eleccin en uno de los aspectos condiciona las o posibilidades en los restantes.
16
3.2
Como su nombre lo indica, el centro de atencin no est puesto en el usuario sino o a en el USO, es decir en las tareas que los usuarios desean realizar y cmo lo hacen. Esta o diferencia de nfasis se traduce en diferentes prcticas con impactos signicativo en el e a ciclo de desarrollo. La Tabla 3.1 resume las diferencias del Diseo Centrado en el Uso con n el DCU segn los autores [Constantine and Lockwood 2002]. u Dise o centrado en el usuario n Foco en el usuario: experiencia del usuario, satisfaccin del usuario o Guiado por el input del usuario Involucramiento sustancial del usuario: estudios de usuarios, diseo n participativo, retroalimentacin de o usuario, testeo de usuario Descripcin de usuarios, caraco ter sticas de usuario Modelos de diseo realistas n Diseo por prototipado iterativo n Procesos variados, a menudo informales o no especicados Dise o centrado en el uso n Foco en el uso: herramientas mejoradas para soportar el logro de tareas Guiado por modelos Involucramiento selectivo del usuario: modelizacin exploratoria, o validacin de modelos, inspecciones o de usabilidad estructuradas Modelos de relaciones de usuarios con el sistema Modelos de diseo abstractos n Diseo a travs de modelos n e Procesos sistemticos, completaa mente especicados
Tabla 3.1: DCU vs Diseo Centrado en Uso n El Diseo Centrado en el Uso est dirigido por tres modelos abstractos, estrechamente n a relacionados: el modelo del rol, el modelo de la tarea y el modelo del contenido. El primero captura las caracter sticas destacables del usuario que participan en su relacin con el o sistema. El segundo, la estructura de la tarea que el usuario debe realizar con el sistema. El modelo del contenido, representa los elementos y organizacin de la interfaz de usuario o necesaria para dar soporte a las tareas identicadas [Constantine and Lockwood 2002]. La Figura 3.2 de [Constantine and Lockwood 2002] muestra el proceso lgico del o mtodo. Los tres modelos centrales al mtodo se desarrollan en forma paralela y muy e e relacionada con otros tres: un modelo del dominio (en la forma de glosario, por ejemplo), un modelo de las reglas del negocio que da forma a la lgica subyacente y restricciones o de la aplicacin y un modelo operacional que captura las caracter o sticas importantes del entorno de trabajo o el contexto operativo.
Figura 3.2: Procesos lgicos en el Diseo Centrado en Uso o n
3.2
17
3.2.4.
Ciclo de vida de Ingenier de Usabilidad por Mayhew a
Deborah Mayhew propone el Ciclo de vida de la ingenieria de usabilidad para el desarrollo de interfaces de usuario usables [Mayhew 1999]. El proceso estructura actividades en tres fases: anlisis de requerimientos, diseo-test-desarrollo e instalacin. Extraamente, a n o n esta aproximacin se apoya en un ciclo de vida general muy similar al de cascada, aunque o dentro de cada fase prevalezca el enfoque iterativo. Aunque Mayhew sostiene que el mtodo est dirigido slo al desarrollo de la interfaz de e a o usuario, las actividades incluidas en el ciclo de vida abrazan una parte importante de las tareas relacionadas con requerimientos. Se pueden identicar v nculos con la Ingenier a de Software orientada a objetos y con los mtodos de prototipado rpido. La autora e a reconoce que la integracin de ingenier de usabilidad con ingenier de software debe ser o a a personalizada en cada organizacin o proyecto y que las superposiciones entre ambas no o estn completamente claras. a El mtodo de Mayhew se desarrolla como muestra la Figura 3.3: e Anlisis de requerimientos: con la construccin del perl del usuario, anlisis en a o a contexto de las tareas, establecimiento de las metas de usabilidad hasta elaborar una Gu de Principios de diseo para el proyecto. a n Diseo, testing y desarrollo estructurado en tres niveles con nivel de abstraccin n o decreciente. En el primer nivel incluye la reingenier del trabajo, un diseo del a n modelo conceptual, elaboracin de maquetas y prototipos, evaluacin iterativa. En o o el segundo, se establecen los estndares y gu diseo, prototipado y evaluacin de a as: n o pantallas y gu de estilo. Finalmente, en el tercer nivel se realiza el diseo detallado as n de la IU y su evaluacin en un proceso iterativo. o Instalacin, permite obtener el feedback del usuario sobre el producto ya instalado o para poder mejorarlo. Algunos puntos que Mayhew plantea como la losof detrs del Ciclo de vida de la a a ingenier de usabilidad permiten comprender mejor los alcances de esta disciplina: a 1. El diseo de la IU es la clave n 2. La integracin de la Ingenier de Usabilidad con la ingenier de software tiene que o a a ser personalizada y adaptada a los requerimientos del desarrollo y a los recursos disponibles. Por ejemplo el anlisis de sistemas tradicional y el Anlisis de Tareas a a en Contexto son actividades altamente relacionadas pero no son la misma cosa y requieren muy diferentes clases de expertise. La forma de integrarlas para evitar duplicacin de esfuerzos y producir los resultados deseados es algo que est pendiente o a de resolucin. Mientras tanto, la forma de integrar la Ingenier de Usabilidad en la o a metodolog del proyecto requiere una adaptacin en cada proyecto. a o 3. El anlisis de requerimientos se compensa, es preferible un cuidadoso (y a menudo a colaborativo) diseo y una evaluacin informal, que un diseo casual y una evalun o n acin formal. o
3.2.5.
Los escenarios de Carroll y Rosson
John Carroll y Mary Beth Rosson propusieron como elemento nucleador para el diseo n de sistemas usables el trabajo con escenarios. En [Rosson and Carroll 2002] presentan el mtodo, cuyo proceso general se muestra en la Figura 3.4. e Los autores denen un escenario se como una historia o relato sobre la manera en que la gente realiza una actividad, mientras que un escenario-problema es una historia sobre el dominio del problema tal como existe antes de introducir la nueva tecnolog a.
18
3.2
Figura 3.3: Ciclo de ingenier de Usabilidad segn [Mayhew 1999] a u A partir de la idea de considerar que los escenarios constituyen una manera adecuada de administrar los compromisos existentes en la ingenier de usabilidad (tomar decisiones a al mismo tiempo que se deja el diseo abierto, balancear accin y reexin, analizar el n o o uso actual pero permitir que evolucione, etc.), Rosson y Carroll plantean un framework de proceso de tres etapas: anlisis, diseo, evaluacin de prototipos. a n o
3.2.6.
El proceso DCU de ISO
La ISO estableci en su estandar ISO 13407 [ISO/IEC 1999] una gu de referencia o a sobre actividades de diseo a lo largo de todo el ciclo de vida de sistemas interactivos n basados en software, enfoque claramente centrado en usuarios. La Norma ISO 13407 que fue establecida en 1999, est dirigida a quienes conducen a los procesos de diseo y aunque no brinda ningn detalle respecto de mtodos o tcnicas n u e e espec cas a utilizar propone un ciclo de vida completo para el desarrollo de sistemas con un enfoque centrado en usuarios. ISO 13407 identica cuatro principios centrales que caracterizan el diseo centrado en el usuario y que no estn ligados a ninguna fase n a espec ca del ciclo de desarrollo: inclusin activa de los usuarios y una clara comprensin de los mismos y de los o o requerimientos de las tareas distribucin adecuada de funciones entre el usuario y la tecnolog o a iteracin de soluciones de diseo o n diseo multidisciplinar n
3.2
19
Figura 3.4: Ingenier de usabilidad basada en escenarios, segun [Rosson and Carroll 2002] a La estructura del proceso DCU, con su naturaleza fuertemente iterativa se ilustra en la gura 3.5, extraida de la propia ISO 13407. La norma comienza sealando que en todas las actividades de desarrollo de sistemas n (anlisis, diseo, testing, etc) debe planicarse la inclusin de tareas centradas en las a n o personas. Este requerimiento, que claramente excede la mera integracin de actividades de o usabilidad al disear la interfaz de usuario, est reclamando una hoja de ruta para adaptar n a las tcnicas de usabilidad en el proceso general de desarrollo de software. Retomaremos e este requerimiento al momento de plantear la contribucin de esta tesis. o Luego, ISO 13407 establece el contenido de los cuatro bloques principales de actividades: Entender y especicar el contexto de uso Se trata de comprender las caracter sticas de los usuarios, las tareas y el entorno f sico y de organizacin denen el contexto o en el que se utilizar el sistema. Es importante entender e identicar los detalles de a este contexto para guiar las primeras decisiones de diseo y proveer una base para n la evaluacin. o Especicar los requerimientos de usuarios y la organizacin Esta actividad deber o a crear un planteo expl cito de los requerimientos de los usuarios y la organizacin o relacionados con la descripcin del contexto de uso. Los siguientes aspectos que o deben considerarse incluyen por ejemplo la performance requerida del sistema nuevo versus objetivos nancieros y operativos; requerimientos legislativos y normativos relevantes, incluyendo cuestiones de seguridad y salud; cooperacin y comunicacin o o entre usuarios y otras partes relevantes; la performance deseada de las tareas; interfaz hombre-computadora y diseo de puesto de trabajo, etc. n Producir soluciones de dise o El corazn de todo proceso DCU es la generacin en n o o forma iterativa e incremental de soluciones de diseo a las situaciones problemticas n a planteadas, utilizando las prcticas del estado del arte, experiencia y el conocimiento a de los participantes. ISO 13407 adhiere al enfoque de diseo de interaccion que parte n desde cero, proponiendo la mejor divisin de tareas entre tecnolog y personas, sin o a dar por sentada ninguna solucin previa y se apoya como actividad por antonomasia o en el prototipado. Evaluar las soluciones de dise o contra los requerimientos de usuario y la organizacin n o
20
3.3
Figura 3.5: El proceso DCU en ISO 13407, [ISO/IEC 1999] Se trata de reunir el mejor feedback posible sobre el diseo, a partir de los usuarios n y representantes de todas las partes involucradas en la relacin con el sistema nal. o
3.3.
Aproximaciones desde la Ingenier de Software a
En esta seccin repasaremos algunos de los intentos provenientes desde la Ingenier o a de software por integrar usabilidad y diseo centrado en usuarios en mtodos y procesos n e de desarrollo. Comenzamos con la propuesta de Maria Francesca Costabile, basada en un ciclo de cascada con retornos [Costabile 2001], luego revisamos el Proceso Unicado y su principal extensin para DCU, El plugin de la experiencia de usuario para RUP[IBM o 2005b]. Este repaso contina con el Dynamic Systems Development Method, conocido cou mo DSDM [DSDM-Consortium 2010] y naliza con Wisdom de Nunes y Cunha, inspirado en el Proceso Unicado [Nunes and Cunha 2001].
3.3.1.
La propuesta de Costabile
En [Costabile 2001] se ofrece una integracin de prcticas centradas en usuario en el o a proceso de desarrollo de software con el objetivo de aumentar la usabilidad del producto nal. Se concentra en tres principios del DCU: analizar los usuarios y las tareas, disear n e implementar en forma iterativa e incremental a travs de prototipos de complejidad e creciente y evaluar los diseos con usuarios. n La propuesta de Costabile implica tomar un ciclo de vida de software y modicarlo para incluir actividades de usabilidad. Extraamente se basa en el ciclo en cascada, al que n agrega dos actividades exclusivas de usabilidad (analizar los usuarios y las tareas, realizar escenarios y especicaciones de interfaces de usuario) y extiende con dos momentos de prototipado y testing, como se muestra en la Figura 3.6. Como propone la posibilidad de retornar desde cualquier actividad a una fase previa sostiene que esto da soporte a la iteratividad que requiere un proceso centrado en usuarios. La eleccin del ciclo de vida en cascada es la principal debilidad de esta propuesta. o Aunque se puedan hacer retornos a fases previas, stos estn planteados como correcciones e a
3.3
21
Figura 3.6: Inclusin de usabilidad en ciclo de vida de software segn Costabile o u de errores. La idea de iteracin en DCU est ms relacionada con el hecho de que no es o a a posible congelar alguna versin de requerimientos o an de solucin parcial de diseo, o u o n sino que ambas especicacin y resolucin de problema avanzan juntas en el proceso. o o Larman ha mostrado claramente las fallas de este ciclo, que terminan conspirando contra el aprovechamiento de las ventajas de la iteracin incremental: dicultad para mitigar o riesgos, especulacin en la elicitacin de requerimientos y rigidez en su especicacin, o o o aumento de la complejidad por falta de adaptabilidad del proceso Larman [2003].
3.3.2.
El Proceso Unicado
El Proceso Unicado [Jacobson et al. 1999] ha recibido una gran atencin de parte de o la comunidad de desarrolladores de software. Entre otras razones, porque sus principales autores y sponsors se cuentan entre los principales metodologistas de la orientacin a o objetos: James Rumbaugh, Ivar Jacobson y Grady Booch. Este mtodo organiza el desarrollo en cuatro fases dentro de las cuales se realizan iterae ciones que generan valor en forma incremental. Se identican algunos elementos bsicos del a mtodo (roles, artefactos, tareas) que se organizan en disciplinas (requerimientos, anlisis, e a diseo, testing, etc.). n La versin ms difundida del Proceso Unicado y que se convirti en el estndar o a o a de desarrollo iterativo es la conocida como RUP o Rational Unied Process [Krutchen 2000] (actualmente distribuida por IBM, antes por Rational Software Co.). La Figura
22
3.3
3.7 muestra la arquitectura general de RUP en los dos ejes: en el horizontal, el ciclo de vida en cuatro fases; en el vertical, las disciplinas que organizan las actividades por su naturaleza(en trminos de RUP). e
Figura 3.7: Arquitectura de procesos en RUP, segn [IBM 2005a] u RUP tiene algunas de las caracter sticas que son propias de un proceso centrado en usuario y utiliza productos de trabajo similares. Por ejemplo, es iterativo e incremental y los casos de uso modelan los requerimentos de forma similar al anlisis de tareas para la a comprensin del contexto de uso que propone ISO 13407. Sin embargo, es esencialmente o un proceso centrado en la arquitectura y en la versin original no incluye ningn elemento o u espec co para el desarrollo de la interaccin de usuario. o El plugin de la Experiencia de Usuario para RUP (UX-RUP) [IBM 2005b] intenta integrar en RUP el trabajo realizado en el dominio del desarrollo web relacionado con los contenidos y concepto de sitio. Est basado en el trabajo de Jim Conallen sobre a modelizacin de aplicaciones web [Conallen 2002]. De acuerdo con Conallen, el trmino o e Experiencia de Usuario se utiliza para describir el equipo y las actividades de los especialistas responsables por mantener la interfaz de usuario consistente con los paradigmas actuales y apropiada al contexto en el cual se espera que se utilice el sistema. Incorpora como producto de trabajo bsico el Modelo de la UX, que intenta describir a los elementos de la experiencia del usuario con el sistema (las pantallas y formularios), el contenido dinmico y los caminos de navegacin entre los elementos para ejecutar la a o funcionalidad del sistema. Este modelo est constituido por tres productos: un conjunto a de Elementos de UX (pantallas y formularios de ingreso), un conjunto de Storyboards de UX (que representan la implementacin, en trminos de interaccin de usuario, de los o e o Casos de Uso) y un Mapa de navegacin entre todos los elementos de UX del sistema. La o Figura 7.21 muestra un ejemplo de Mapa de Navegacin. o Este plugin es claramente un avance en la inclusin de DCU y usabilidad en RUP. Sin o embargo, est acotado a algunas partes del proceso y unos pocos modelos de trabajo. a
3.3.3.
DSDM
El DSDM (Dynamic Systems Development Method) es un framework de mtodos para e el desarrollo de software de manera gil. Se basa en el involucramiento activo del usuario, a un desarrollo iterativo e incremental y sensible a los cambios de requerimientos [DSDMConsortium 2010].
3.3
23
Figura 3.8: Ejemplo de Mapa de Navegacin en el Plugin UX de RUP, segn [IBM 2005b] o u
Fue desarrollado y es mantenido por el Consorcio DSDM, una alianza entre proveedores y expertos de desarrollo de sistemas de informacin del Reino Unido. La versin actual, o o la 4.2, fue lanzada en 2003. El ciclo de vida de DSDM consiste en tres fases: fase del pre-proyecto, fase del ciclo de vida del proyecto, y fase del post-proyecto. La fase del ciclo de vida del proyecto se subdivide en 5 etapas: estudio de viabilidad, estudio de la empresa, iteracin del modelo o funcional, diseo e iteracin de la estructura, e implementacin. La gura 3.9 muestra el n o ciclo de vida en la fase Proyecto.
Figura 3.9: Ciclo de vida DSDM DSDM est sustentado en nueve principios, varios de ellos compartidos con el diseo a n centrado en usuario tales como involucrar al usuario, dar poder al equipo para tomar decisiones, entrega frecuente de productos, desarrollo iterativo e incremental, priorizar el
24
3.3
valor entregado como criterio de aceptacin. o
3.3.4.
Wisdom
Desarrollado por Nunes y Cunha, WISDOM (Whitewater Interactive System development with Object Models) [Nunes and Cunha 2001] se plantea como un mtodo liviano e alrededor de tres componentes principales: un framework de procesos de desarrollo, un conjunto de modelos UML y una extensin de la notacin UML para permitir la repreo o sentacin y modelizacin de los componentes interactivos. o o El ciclo de vida del proceso de WISDOM es similar al Proceso Unicado (utiliza las mismas cuatro fases evolutivas) y organiza las actividades en cuatro ujos de trabajo: requerimietnos, anlisis, diseo y evaluacin. En el corazn del proceso Nunes y Cunha a n o o ubican al prototipado evolutivo que avanza en sucesivas renaciones hacia el sistema nal. Al igual que el PU, WISDOM utiliza los Casos de Uso como herramienta de requerimientos. Las Figuras 3.10 y 3.11 muestran el ciclo de vida propuesto y algunas de las extensiones a UML que se introducen para generar los modelos de la interaccin de usuario. o
Figura 3.10: Fases del proceso en WISDOM
3.4
Oportunidad de intervencin o
25
Figura 3.11: Flujos de tareas, actividades, modelos y diagramas en WISDOM
3.4.
Oportunidad de intervencin o
En este cap tulo, se han presentado diferentes propuestas de integrar en procesos de diseo y construccin de software tareas vinculadas con la obtencin de usabilidad en el n o o producto nal, provenientes tanto desde el campo de la HCI como de la Ingenier de a Software. Antes hab amos mostrado que el logro de buenos niveles de usabilidad guarda una relacin estrecha con procesos centrados en usuario, que a su vez se caracterizan por ser o esencialmente iterativos. Tambin mencionamos la importancia de un abordaje que no se e concentre slo en la interfaz de usuario, sino en todas las interacciones que el producto o habilita o restringe. Finalmente, sealamos que la efectividad y eciencia de los procesos n de desarrollo centrados en usuario se pueden aumentar mejorando la capacidad y madurez en usabilidad de una organizacin. o Todas las propuestas que presentamos incluyen en alguna medida el carcter iterativo a en el ciclo de vida y la participacin ms o menos comprometida de los usuarios nales o a (ya comentamos la falencia de Costabile al presentar como iterativo un ciclo en cascada con retornos). Ms despareja resulta la extensin de aspectos del sistema que estn cubiertos por a o a tareas de usabilidad. Slo DSDM, Constantine y el Proceso ISO plantean claramente la o necesidad de abarcar todo el sistema o producto. El resto restringe en algn punto la tarea u a los aspectos vinculados expl citamente con las IUs. Pero el punto que a nuestro juicio compromete ms la posibilidad de mejorar de manera a previsible la obtencin de niveles de usabilidad en los productos de software es la escasa o o nula gu que estas propuestas brindan para integrarlas con la ingenier del software en a a las actividades de mejoras de procesos. En efecto, es clara la carencia en esas propuestas de alguna forma de hoja de ruta que adems de incluir actividades de usabilidad en un a ciclo de vida de desarrollo, gu al equipo en la forma de incrementar la capacidad en e usabilidad.
26
3.4
Creemos que una forma de contribuir a superar esta carencia es dar soporte a la integracin de diseo y desarrollo centrado en usuario en procesos de ingenier de software o n a de manera tal que se puedan mejorar los niveles de capacidad y madurez en usabilidad de una organizacin. o Vamos a tomar como base uno de las metodolog de desarrollo que alcanz mayor as o difusin en la construccin de software, como es el Proceso Unicado. En particular, o o utilizaremos la versin liberada como OpenUP por la Fundacin Eclipse. Nos proponemos o o analizarla para encontrar los huecos que deben ser cubiertos para mejorar las actividades de DCU en ese proceso y desarrollar las extensiones que sean necesarias. Como gu para esos cambios emplearemos el Modelo de Capacidad y Madurez en a Usabilidad propuesto por la ISO en los tres primeros niveles de Capacidad (El proceso realizad, El proceso gestionado y el Proceso establecido). Intentaremos extender la Liber a de Procesos de Eclipse para permitir instanciaciones de OpenUP que puedan satisfacer a los niveles 1 a 3 del MMU-ISO.
Parte II
Capacidad y Madurez en Usabilidad con el Proceso Unicado
27
Cap tulo 4
Proceso Unicado open source: OpenUP

4.1. Introduccin o
Para nuestra propuesta de inclusin de DCU en un proceso de desarrollo de software o tomamos como base la versin open source del Proceso Unicado, que fuera liberada por o la Fundacin Eclipse a partir de una contribucin por parte de IBM de los elementos o o bsicos de RUP, en el marco del proyecto Eclipse Process Framework (EPF) [ECLIPSE a 2006]. El proyecto EPF tiene dos objetivos: a) proveer un framework extensible y herramientas de ejemplo para la ingenier de procesos de software (autor de mtodos y procesos, a a e gestin de bibliotecas, conguracin y publicacin de procesos) y b) proveer contenido de o o o ejemplo para procesos de desarrollo y gestin de softwar que sea extensible y soporte el deo sarrollo iterativo, gil e incremental y que se sirva para un conjunto amplio de plataformas a y aplicaciones. El framework, que describiremos en detalle en la seccin siguiente, se compone de o un meta-modelo basado en la versin 2.0 del SPEM de la OMG [OMG 2008] (que a su o vez reconoce entre las fuentes a la Unied Method Architecture de IBM) y un ncleo u extensible de herramientas (funcionalidad bsica y una API que permita la autor de a a mtodos y procesos). OpenUP/Basic, como veremos, es una conguracin de procesos e o basada en el Proceso Unicado y que utiliza los elementos core provistos por el EPF. Una de las herramientas de ejemplo liberadas, el EPF Composer ser utilizado para la a elaboracin de las conguraciones del proceso que integren el DCU. o En las secciones siguientes de este cap tulo presentamos el EPF y la versin bsica de o a OpenUP.
4.2.
El Eclipse Process Framework
El corazn del EPF se denomina Framework Unicado de Mtodos (UMF). Se o e trata de un framework que se basa en un conjunto de prcticas provenientes de diferentes a contextos y desarrolladas por diferentes organizaciones que comparten una infraestructura comn. En cierto sentido, puede considerarse como un lenguaje comn que permite la u u interoperacin de prcticas. Un framework de prcticas organiza una biblioteca de o a a mtodos como un conjunto de prcticas con alta cohesin y bajo acoplamiento. El cone a o tenido se comparte entre las prcticas, se captura en elementos core, categorizados en Slots a de Productos de Trabajo (WPS). Las conguraciones de prcticas (incluyendo procesos a 29
30
4.2
transversales a varias de ellas) se ensamblan seleccionando un subconjunto especico de esas prcticas. La Figura 4.1 muestra grcamente esta descripcin. a a o
Figura 4.1: Esquema de un Framework de Prcticas a Ya sealamos que el metamodelo empleado en EPF y EPL el propuesto por el Obn ject Management Group en la Versin 2.0 de su Software & Systems Process Engineering o Meta-Model Specication [OMG 2008]. La concepcin y el marco de uso del SPEM 2.0, o adoptada por el EPF, se muestra en la Figura 4.2. Se trata de proveer una representacin o estandarizada y bibliotecas de contenido de mtodo que sea reutilizable, dar soporte para e una actividad sistemtica de desarrollo, gestin y crecimiento de procesos de desarrollo a o de software, facilitar el despliegue de un subconjunto de contenidos y procesos necesarios mediante la conguracin de procesos espec o ficos y dar un respaldo adecuado a la implementacin concreta de los procesos congurados. o
Figura 4.2: Marco conceptual para uso de SPEM 2.0 Este meta-modelo, que provee el lenguaje para describir los contenidos y procesos del mtodo, separa las deniciones de Contenido del Mtodo de su aplicacin en Procesos de e e o entrega, tal como muestra la Figura 4.3. El Contenido se maniesta en principio mediante deniciones de productos de trabajo, de roles, de tareas y orientaciones. Estas ultimas
4.2
31
(que pueden ser gu listas de control, ejemplos, hojas de ruta, etc) estn en la interas, a seccin de Contenido y Procesos porque pueden considerarse como un background para o un contenido tanto como para un proceso espec fico. A la derecha del diagrama estn los a procesos denidos en SPEM 2.0. El elemento principal es la Actividad, que puede anidarse para denir estructuras de desglose de tareas (WBS) o relacionarse con otras actividades para denir un ujo de trabajo. Las Actividades tambin tienen referencias a los Cone tenidos de Mtodo, representadas con el concepto usa. Las Actividades se utilizan para e denir Procesos.
Figura 4.3: Elementos de Metamodelo SPEM 2.0 La referencia completa al SPEM 2.0 se puede encontrar en [OMG 2008], transcribimos aqu slo las deniciones breves de los elementos de contenido y proceso que describiremos o ms adelante dentro de las Prcticas de la EPL. Como contexto de estas deniciones, a a mostramos con las Figuras 4.5 y 4.4 los estereotipos UML que emplea SPEM 2.0 en el diseo de los Paquetes Estructura de Procesos y Estructura de Contenido de Mtodo. n e
Figura 4.4: Perles UML denidos en SPEM 2.0 para el paquete Contenido de Mtodo e
32
4.2
Figura 4.5: Perles UML denidos para el paquete Estructura de Procesos en SPEM 2.0
Los elementos de contenido

Denicin de Rol o Un rol se dene como un conjunto de habilidades, competencias y responsabilidades relacionadas. Las personas o las herramientas que desempean un rol realizan tareas y n generan productos de trabajo. Para algunas tareas y productos de trabajo los que desempean roles son directamente responsables de realizar las tareas y generar los producn tos. Para otras, simplemente colaboran para alcanzar la meta. Un rol puede ser desempeado por una persona o un conjunto de personas y a su n vez una misma persona o conjunto puede desempear varios roles. Por ejemplo, hay dos n roles en las diferentes versiones del Proceso Unicado, Gerente de Proyecto e Ingeniero de Procesos que en proyectos pequeos pueden ser desempeados por la misma persona, n n mientras que en proyectos de gran magnitud es muy probable que existan varias personas desempeando cada uno de esos roles. n La Figura 4.6 muestra las relaciones entre los Rol, Tarea y Productos de trabajo.
Figura 4.6: Relaciones entre deniciones de Rol, Tarea y Producto de trabajo
4.2 Denicin de Producto de trabajo o
33
Un Producto de trabajo es un elemento del contenido del mtodo que es usado, moe dicado y producido por una Denicin de Tarea. Slo un rol es responsable por cada o o producto de trabajo. SPEM 2.0 distingue tres clases de productos de trabajo: artefacto, resultado y entregable. Los artefactos son tangibles y pueden estar incluidos en otros artefactos. Por ejemplo, un plan de desarrollo es un artefacto que pude contener una lista de riesgos, entre otros artefactos. Un resultado habitualmente es intangible y no reusable. Por ejemplo, podr ser la mejora en performance o la instalacin de una herramienta. Un entregable a o es el valor provisto a los involucrados internos o externos y se compone de otros dos productos de trabajo: artefactos y resultados. Denicin de Tarea o Una Denicin de Tarea describe el trabajo realizado por instancias de Denicin de o o Rol. Est asociada con Productos de Trabajo de entrada y salida y dirigida por una meta. a Puede considerarse como la unidad de trabajo asignable. La tarea describe el trabajo a ser realizado y comnmente un conjunto opcional de pasos. Las tareas usualmente duran u entre unas pocas horas y unos d y afectan solametne un nmero pequeo de Productos as u n de trabajo. Debido a su granularidad, las tareas a menudo se repiten en iteraciones y pueden ser muy pequeas para la planicacin. Si son muy grandes, es conveniente den o glosarlas en Pasos (una Denicin de Paso representa la unidad ms pequea de trabajo o a n a realizar). Por ejemplo, la Denicin de Tarea Desarrollar el Modelo de Casos de Uso describe el o trabajo necesario para completar ese modelo: identicar y nombrar casos de uso y actores, escribir descripciones breves, modelar los CU y sus relaciones, completar las descripciones detalladas del ujo bsico y los ujos alternativos, etc. Todas estas partes (Pasos) cona tribuyen a la meta de desarrollar el modelo de casos de uso, pero pueden realizarse en diferentes puntos de un proceso. Al comienzo se pueden identicar y nombrar los CU. Mucho ms tarde en el proceso se completarn las descripciones detalladas de todos los a a ujos. El conjunto de los Pasos describe el mtodo para desarrollar un Modelo de Casos e de Uso. Aplicarlo en un proceso consiste en denir cules pasos se completan antes de a pasar de una iteracin a la siguiente. o
Los elementos de proceso

Los elementos de proceso estn organizados a partir de la denicin de un Elemento a o de desglose (Breakdown element). Se trata de una generalizacin abstracta de cualquier o tipo de elemento que aparece en un proceso. Tiene tres propiedades importantes: a) admiten repeticiones en un mismo proceso, b) son opcionales y c) es planicado (se incluye al generar un plan de proyecto). Dentro de los Elementos de Desglose, se cuentan los Elementos de Desglose de Trabajo (Actividades e Hitos). A la posibilidad de repeticin que heredan de los Elementos o de Desglose (y que permiten, por ejemplo, la realizacin de iteraciones), le suman una nao turaleza continua (sin duracin ja o estado nal) y que estn condicionados por sucesos, o a es decir que inicia porque un evento especial ha sucedido, no porque estaba programado en un cronograma. Una Actividad constituye la unidad bsica de trabajo dentro de un Proceso. Est asoa a ciada con Productos de Trabajo y con Roles. El meta-modelo soporta el anidamiento de Actividades, de modo que forman una WBS. Como una actividad puede contener otras actividades, el ingeniero de de proceso puede crear una jeraqu tan compleja como necea site.
34
4.2
El Flujo entre los Elementos de desglose de Trabajo se representa mediante Secuencias de trabajo. Cada secuencia conecta dos Elementos de Desglose de trabajo: un predecesor y un sucesor. La Figura 4.7 ejemplica una WBS asociada a un Elemento de Desglose de Trabajo (el Patrn de entrega de Fases para el ciclo de vida riesgo-valor). o
Figura 4.7: WBS de Fases de Ciclo de vida riesgo-valor Una Fase agrupa elementos en un per odo signicativo del proyecto. Una Fase naliza con un punto de control de gestin importante, con un Hito o con un conjunto de o entregables concluidos. En trminos de SPEM una Fase es una Actividad que cumple e esRepetible = False. La Iteracin representa un conjunto de actividades anidadas que se repiten ms de o a una vez. Permite al ingeniero de procesos organizar ciclos repetitivos de trabajo. Para SPEM, una Iteracin es una Actividad con esRepetible = True o Un Hito representa un evento signicativo para el desarrollo de un proyecto, por ejemplo una decisin importante, la conclusin de un entregable, la nalizacin de una o o o fase. Se trata de un Elemento de desglose de trabajo, de manera que tiene que aparecer en una WBS y puede tener relaciones de precedencia. Un Patrn de proceso (Capability pattern) es un fragmento de proceso que puede o contener Actividades e Hitos y que es reutilizable como solucin a algn tipo de problema o u o situacin habitual. Agrupar elementos de Proceso en Patrones de Capacidad permite a o los ingenieros de proceso reusar estos fragmentos y componer Procesos de Entrega a partir de ellos. Si un patrn comn, como el plan de una iteracin, es necesario en diferentes o u o partes del proceso de entrega, se puede reutilizar generando un Patrn de proceso. o Un Proceso de despliegue es un ciclo de vida del proyecto de punta a punta ensamblados a partir de un conjunto de Actividades, Fases, Iteraciones, Patrones de Proceso e Hitos. Por ejemplo, RUP se distribuye con tres procesos de Entrega: clsico (proyectos a grandes), pequeo (proyectos pequeos), medium (proyectos medianos). n n
Diagramas de proceso
Existen tres diagramas que son relevantes en el contexto de nuestra tesis: el ujo de trabajo, el detalle de actividades y las dependencias de productos de trabajo. Diagrama de ujo de trabajo Se trata de una versin adaptada de los Diagramas de Actividad UML que puede o contener un punto de inicio y uno de n, nodos de decisin, links, actividades, barras de o sincronizacin, fases de descriptores de tareas e hitos. Provee una visin de alto nivel de las o o actividades y su secuencia. La Figura 4.8 muestra un ejemplo Las barras de sincronizacin o muestran un posible paralelismo entre actividades. Las echas en los links muestran orden de ejecucin entre los elementos de proceso. o
4.2
35
Figura 4.8: Diagrama de Flujo de Trabajo en SPEM 2.0 Diagrama de detalle de actividades Brinda una visin general de los descriptores de las tareas dentro de una actividad, o los descriptores de los roles asociados con las tareas y los descriptores de productos de trabajo de entrada y salida. Los dos diagramas en la Figura 4.9 muestran para cada rol responsable en la dimensin horizontal la lista de tareas en la actividad y en la vertical el o ujo de productos de trabajo. Un descriptor es bsicamente un objeto de referencia dentro a de un proceso que representa la ocurrencia de un elemento de contenido del metodo. Tiene sus propias relaciones y documentacin que dene la diferencia entre la implementacin o o por defecto y esta particular ocurrencia del elemento en el proceso. Diagrama de dependencia de Producto de Trabajo Ilustra las relaciones y dependencias entre varios productos de trabajo. Se utilizan para mostrar trazabilidad de productos de una actividad. La Figura 4.10 muestra un diagrama de este tipo utilizando los iconos de SPEM 2.0 para los elementos de proceso.
36
4.2
Figura 4.9: Diagrama de detalle de actividad en SPEM 2.0
Figura 4.10: Diagrama de Dependencias de Producto de Trabajo en SPEM 2.0
4.3
La biblioteca de prcticas para el EPF a
37
4.3.
La Biblioteca de Prcticas del Framework de Procesos Eclipse (EPL) es una a biblioteca que conforma al UMF, liberada junto con la versin 1.5.0.1 del Eclipse Process o Framework Composer [Eclipse 2008a]. En el contexto del Eclipse Process Framework, una prctica es una aproximacin a o a resolver uno o ms problemas que se producen comunmente. Estas prcticas estn a a a destinadas a ser adoptadas, habilitadas y conguradas como cadenas de procesos . Estas prcticas ofrecen las siguientes ventajas: a Adaptabilidad y escalabilidad El conjunto de prcticas incluidas soporta un amplio a rango de soluciones. Adopcin incremental Cada prctica se describe como una capacidad autocontenida o a que puede ser adoptada por una organizacin o un proyecto. o Facilidad de congurar y usar Crear un mtodo es tan simple como seleccionar las e prcticas a adoptar y publicar los resultados. Cada prctica se agrega a s misma a a al framework de modo que el contenido pueda ser visto ya sea por prctica o por a productos, roles, etc. Desarrollo comunitario El desarrollo de la Biblioteca Open Source de Prcticas se a desarrolla por la comunidad del Eclipse Process Framework Por otro lado, se sostiene que las buenas prcticas incluidas en el framework han a surgido del anlisis de un gran nmero de proyectos exitosos [Kroll and MacIsaac 2006]. a u Finalmente, sealemos que el Mtodo de Autor de Mtodos (MAM) es una n e a e aproximacin a la creacin de mtodos centrada en arquitectura, orientada a la calidad y o o e basada en prcticas. MAM provee gu para crear mtodos que sern incluidos dentro de a as e a la Biblioteca de Prcticas EPF [Eclipse 2008b]. Ms adelante retomaremos las indicaciones a a del MAM para generar una de las contribuciones de esta tesis.
Los bloques para construir prcticas a

A continuacin describimos brevemente las deniciones de los Roles, Tareas y Produco tos de trabajo incluidos en EPF como elementos de Contenidos de Mtodo sobre los que e se construyen las Prcticas de la EPL y que se muestran en la Figura 4.11. a Roles La EPL presenta siete roles bsicos, necesarios para equipos pequeos y sin distribucin a n o geogrca: a Analista representa los concerns del cliente y los usuarios nales mediante la obtencin o de input directo de los involucrados para comprender el problema a resolver y la captura o planteo de prioridades para los requerimientos. Arquitecto es responsable de denir la arquitectura del software, lo que incluye tomar las decisiones tcnicas claves que restringirn el diseo en l e a n neas generales. Desarrollador es responsable de desarrollar una parte del sistema, incluyendo el diseo n para adecuarla a la arquitectura, posiblemente el prototipado de la interfaz de usuario y la implementacin, test de unidad e integracin de los componentes que o o son parte de la solucin. o
38
4.3
Figura 4.11: Bloques de Prcticas EPL a
4.3
39
Stakeholder representa los grupos de inters cuyas necesidades pueden ser satisfechas e por el proyecto. es un rol que puede ser desempeado por cualquiera que ser, real n a o potencialmente, afectado por el resultado del proyecto. Tester es responsable de las actividades centrales del esfuerzo de prueba, incluyendo la identicacin, denicin, implementacin y conduccin de las pruebas necesarias, o o o o tanto como de registrar y analizar los resultados. Gerente de proyecto lidera la planicacin del proyecto, coordina las interacciones con o los involucrados y mantiene el equipo focalizado en alcanzar los objetivos del proyecto Rol genrico cualquier interesado en el proyecto o integrante del equipo que no est come a prendido en los roles anteriores Tareas La EPL se construye sobre 18 tareas que los diferentes Roles pueden realizar como actores principales (y por lo tanto son responsables de que se ejecuten) o secundarios (proveyendo informacin o soporte para ejecutar la tarea). Las tareas estn asociadas con o a conceptos, orientaciones y listas de control. Bocetar la arquitectura Consiste en delinear las primeras decisiones de arquitectura que guiarn el desarrollo y las pruebas. Se comunica a todo el equipo para que se a tenga suciente informacin sobre el tipo de aproximacin tcnica que se adopta. o o e Evaluar resultados determinar el xito o fracaso de una iteracin y aplicar las lecciones e o aprendidas para modicar el proyecto o mejorar el proceso. Crear Casos de prueba Desarrollar casos y datos de prueba para cada requerimiento a testear. Denir la visin del sistema, describiendo los problemas y caracter o sticas sobre la base de los requerimientos de stakeholders. Detallar escenarios de Casos de Uso Describir los ujos de los casos de uso en suciente detalle para poder validar la comprensin de los requerimientos, asegurar la o satisfaccin de expectativas de stakeholders y permitir que comience el desarrollo o del software. Encontrar y bocetar requerimientos identicar y capturar los requerimientos funcionales y no funcionales del sistema en un nivel de abstraccin alto que permita o obtener una aproximacin inicial del alcance del trabajo por delante o Implementar tests de desarrollador implementar una o ms pruebas que permitan a la validacin de una implementacin del desarrollador o o Implementar scripts de tests implementar los scripts para las pruebas que permitan validar una solucin o Implementar la solucin escribir el cdigo fuente para proveer nueva funcionalidad o o o corregir defectos Integrar y crear un build integrar todos los cambios introducidos por los desarrolladores en la base de cdigo o
40
4.3
Gestionar una iteracin monitorear el estado del proyecto, identicar cualquier bloo queo u oportunidad de avance. Identicar y manejar las excepciones, problemas y riesgos. Comunicar el estado del proyecto. Planicar una iteracin planicar el alcance y las responsabilidades para una iteracin, o o identicando el prximo incremento de las capacidades del sistema. o Planicar el proyecto elaborar un plan del proyecto que resuma las actividades principales y provea un acuerdo entre todos los involucrados sobre las metas y forma de lograrlas. Obtener el acuerdo de stakeholders para iniciar el proyecto y el compromiso del equipo para avanzar. Renar la arquitectura a partir de la arquitectura bocetada, esta tarea implica tomar decisiones para concretarla en los detalles y proveer el soporte al desarrollo del sistema Requerir cambios capturar y registrar los pedidos de cambio Ejecutar tests de desarrollador ejecutar pruebas contra la implemetnacin individual o del desarrollador Ejecutar tests ejecutar los scripts de pruebas adecuados, analizar los resultados y comunicarlos al resto del equipo Disenar la solucin identicar los necesarios para resolver alguna funcionalidad en paro ticular y disponer las interacciones, comportamientos, relaciones y datos necesarios para ello Detallar requerimientos de sistema describir los requerimientos suplementarios de alcance de todo el sistema en suciente detalle para permitir su validacin y el inicio o de su desarrollo Productos de trabajo Mediante la realizacin de las diferentes tareas, los roles producen, modican o utilizan o 17 artefactos incluidos en EPL. La mayor de los artefactos se asocia con plantillas y listas a de control. La plantilla o template provee orientacin adicional para completar el artefacto o y la lista de contorl ayuda a vericar la calidad del resultado. Cuaderno de arquitectura Describe el ratiionale, los supuestos, explicaciones e implicancias de las decisiones que se toman para constituir la arquitectura Build versin operativa del sistema o una parte que demuestra un subconjunto de las o capacidades a proveer por el producto nal Dise o decribe la realizacin de una funcionalidad requerida y sirve como abstraccin n o o del cdigo fuente o Test de desarrollador valida un aspecto espec co de un elemento de implementacin o Glosario dene los trminos importantes utilizados en el proyecto e Implementacin archivos de cdigo y datos, archivos de soporte como ayuda online, o o que representan las partes en crudo del sistema en construcci n o Plan de iteracin plan de bajo nivel que describe objetivos, asignaciones y criterios de o evaluacin para una iteracin o o
4.3
41
Plan de proyecto plan de alto nivel que incluye la informacin para gestionar el proyeco to, describiendo las iteraciones y sus metas Lista de riesgos lista ordenada de riesgos abiertos y conocidos del proyecto Especicacin de requerimiento de sistema captura los atributos de calidad y reo stricciones que tienen alcance en todo el sistema Caso de prueba especicacin de un conjunto de inputs, condiciones de ejecucin y reo o sultados esperados de una prueba para evaluar un aspecto particular de un escenario Log de prueba rene la salida en bruto capturada durante una corrida de pruebas u Script de prueba contiene las instrucciones paso a paso para ejecutar una prueba, puede ser un documento para hacer pruebas manuales o cdigo para su ejecucin auo o tomtica a Modelo de Casos de Uso captura el modelo de las funcionalidades y entorno requerido del sistema y sirve como contrato entre el cliente y el equipo Caso de Uso captura el comportamiento del sistema que permite mostrar un resultado observable y de valor para los que interactan con el sistema u Visin dene la vista que los stakeholders tienen de la solucin tcnica a desarrollar, o o e especicada en trminos de necesidades y caracter e sticas de los stakeholders Lista de tems de trabajo contiene la lista de todo el trabajo programado para realizarse dentro del proyecto. Cada item de trabajo puede contener referencias a informacin relevante necesaria para realizarlo o
Las prcticas de la EPL a

Ya hemos mencionado que en el marco de la EPL una prctica dene una manera a de resolver uno o ms problemas que se producen habitualmente. La EPL organiza doce a buenas prcticas de ingenier de softwre en dos grupos: a a Prcticas del Kernel Agil, que incluyen todas las buenas prcticas de mtodos a a e a giles: Desarrollo iterativo Planicacin en dos niveles o Equipo integrado Testing concurrente Integracin continua o Prcticas de EPF para escalar la agilidad, que permiten extender el corazn a o de agilidad a procesos de mayor envergadura: Arquitectura evolutiva Diseo evolutivo n Ciclo de vida riesgo-valor Visin compartida o Gestin grupal de cambios o Desarrollo condudido por testing Desarrollo conducido por casos de uso
42
4.3
Prctica: Desarrollo iterativo a Esta prctica se basa en la idea de que el software se construye en una serie de increa mentos a lo largo de una secuencia de iteraciones. Cada incremento agrega un subconjunto de la funcionalidad nal del sistema. De esta forma, el sistema crece y deviene ms coma pleto en el transcurrir de las iteraciones. Se incluyen tres tareas, que producen otros tantos artefactos: Planicar la iteracin consiste en priorizar los items de trabajo, denir los objetivos o de la iteracin, comprometer el trabajo para los items priorizados, identicar y o actualizar la lista de riesgos, denir los criterios de evaluacin y renar la denicin o o y alcance del proyecto. El resultado princial de esta tarea es el Plan de Iteracin, o pero tambin resultan actualizados la Lista de items y la Lista de riesgos. e Gestionar la iteracin Esta tarea es responsabilidad central del Gerente de Proyecto, o que debe evaluar permanentemente el estado del trabajo, identicar elementos de bloqueo y oportunidades, manejar las excepciones, los problemas y los riesgos y comunicar cuando corresponda el estado del proyecto. El output de esta tarea es la versin actualizada de los mismos artefactos de la tarea anterior. o Evaluar resultados El propsito de esta tarea es demostrar el valor entregado por el o incremento de solucin desarrollado en la iteracin y aplicar las lecciones aprendidas o o para modicar o mejorar el proyecto. Si bien el principal responsable es tambin el e Gerente del Proyecto, todos los actores del equipo contribuyen a esta tarea que se efecta a modo de revisin al nalizar cada iteracin. El resultado es la versin u o o o actualizada del Plan de iteracin (especialmente en los aspectos a ser tenidos en o cuenta en la prxima iteracin) y la Lista de Items. o o Es central incluir en esta descripcin tres conceptos claves que se introducen en la o EPL respecto de otros mtodos basados en el Proceso Unicado: el ciclo de vida de cada e iteracin, los micro-incrementos y las retrospectivas o El ciclo de vida de las iteraciones En EPL cada iteracin tiene su propio ciclo o de vida, comenzando con una planicacin y nalizando con un incremento estable del o sistema, una Revisin de Iteracin (logramos lo que nos propusimos?) y una Retrospectiva o o (hay mejor forma de hacerlo?). La planicacin de la iteracin, la estimacin y el monitoreo de avance est centrado o o o a en los items de trabajo que constituyen la base de los micro-incrmentos. Una iteracin comienza con una reunin de planicacin de un par de horas. Los dos o o o primeros d t as picamente se focalizan en mejorar la planicacin y la arquitectura base o para entender las dependencias y el ordenamiento lgico de los o tems de trabajo. La mayor parte del tiempo de una iteracin se enfoca en ejecutar los micro-incrementos. Cada uno de o estos deber entregar un cdigo testeado para integrar y otros artefactos validados. EPL a o incorpora un poco ms de disciplina al establecer que los builds stables deben producirse al a nal de cada semana. La ultima semana de la iteracin tiene un nfasis ms fuerte en pulir o e a y corregir bugs. La iteracin naliza con una evaluacin (que incluye a los stakeholders) o o de lo que se construy y una retrospectiva que permita entender cmo mejorar el proceso o o para la prxima iteracin. o o Los micro-incrementos representa el resultado de unas pocas horas hasta unos pocos d de trabajo realizado por una o pocas personas colaborando para alcanzar una meta. as Algunos ejemplos de micro-incrementos ser an: identicar un involucrado (un paso dentro de una tarea), determinar la forma de abordaje tcnico para la persistencia (una tarea e
4.3
43
Figura 4.12: Ciclo de vida de la iteracin en OpenUP o con un foco espec co), desarrollar un incremento de solucin para el Flujo Principal del o Caso de Uso 1 (una tarea con un foco espec co) El desarrollo evoluciona en micro-incrementos a traves de la ejecucin simultnea de o a varios tems de trabajo. Al compartir el avance de todos los mi mediante las reuniones diarias y las herramientas de colaboracin, se alcanza la transparencia y comprensin o o del trabajo de otros requerido para un efectivo trabajo de equipo. Al mismo tiempo se demuestra el progreso continuo con la evolucin de un mi a la vez. o Las retrospectivas realizadas no slo al nalizar el proyecto, sino tras cada iteracin y o o release, proveen una forma efectiva de monitorear la salud del proyecto y ayudar al equipo a aprender de las lecciones. Preguntas del estilo de Qu funcion bien para nosotros en la iteracin anterior?, e o o Qu cosas no funcionaron bien?, Qu deber e e amos hacer de manera diferente o qu mejoe ra deber amos intentar en la prxima iteracin?, junto con las acciones propuestas en o o consecuencia ayudan a priorizar mejoras y mantener bajo control el pulso del proyecto. Prctica: Planicacin del Proyecto en dos niveles a o Incorpora el concepto de una planicacin de alto nivel o macro para el alcance como pleto del proyecto y una de bajo nivel o micro para los prximos incrementos e iteraciones. o La prctica de Planicar en dos niveles enfatiza la necesidad de planicar en detalle a slo la prxima iteracin y mantener un nivel ms alto de abstraccin para el conjuno o o a o to del proyecto. Por otra parte, alienta a los gerentes a sentirse confortables con la replanicacin como una forma necesaria de asegurar precisin en las fechas y costos de o o entrega, considerando los eventos que impactan en el proyecto. En consecuencia, la prctica incluye una sola tarea para el nivel macro: Planicar el a proyecto, que consiste en consensuar un plan sobre la forma en que el proyecto alcanzar sus metas. Esta tarea es la oportunidad para que el equipo acuerde sobre algunas a variables importantes del proyecto: alcance,objetivos, calendario inicial, entregables. Focalizando en una forma auto-organizativa caracter stica de procesos giles, permite al a equipo denir criterios de xito y formas de trabajo a ser empleadas. Si bien la colabe oracin y el consenso constituyen metas de esta tarea, el Gerente del Proyecto, como o responsable de la misma, debe asegurar el compromiso de todos con el plan. El producto de la tarea (Plan del proyecto) quedar sujeto a la actualizacin de acuerdo con el feedback a o y cambios en el contexto durante el resto del proyecto. Para la EPL una planicacin incluye establecer un equipo cohesivo, estimar el tamao o n del proyecto, evaluar los riesgos, prever la velocidad y duracin del proyecto, esbozar el o ciclo de vida del proyecto, establecer costos y articular el valor, planicar el despliegue.
44
4.3
Para el nivel micro, la tarea Planicar la iteracin quedar vinculada con la prcica o a a Desarrollo iterativo, en las planicaciones de cada iteracin o Prctica: Equipo integrado a Describe cmo un equipo de desarrollo se autoorganiza para trabajar efectivamente. o Esta prctica se funda sobre el hecho de que el factor ms importante para la productividad a a son los recursos humanos y el modo en que interactan. Propone estrategias para aumentar u la productividad grupal mediante coordinacin tanto en el nivel de la estructura del equipo o como dentro del equipo mismo. La prctica caracteriza al equipo integrado como autoorganizado, transversal, uido y a altamente colaborativo. Esta prctica no incluye productos de trabajo espec a cos (obviamente, tampoco tareas propias), sino que propone tres gu o directrices para la accin: as o Encuentros diarios ala Scrum [Schwaber 2004]. Breves reuniones de todo el equipo para mantener el pulso del proyecto. Mantener un ritmo sostenible, evolucin de la semana de 40 horas de Exo treme Programming. Con esta estrategia se busca evitar el burnout del equipo que se produce cuando el ritmo al que se aspira esta fuera de toda posibilidad de sostenimiento. Autoorganizar la asignacion de tareas, tambin tomado de Scrum, con el e propsito de que sea el propio equipo (y cada uno de sus integrantes) los que decidan o en cada momento las asignaciones que se toman, promovienod de esta manera un mayor compromiso con cada tarea. Queda espacio, sin embargo, para el liderazgo del Gerente de Proyecto en la resolucin de conictos y la vigilancia de que las tareas o son abordadas dentro de las habilidades disponibles. Prctica: Testing concurrente a Describe la incorporacin del testing en un proceso gil de desarrollo. El trmino o a e concurrente pretende indicar que el testing debe abordarse a lo largo de toda la iteracin o de manera paralela al desarrollo, evitando que se separen las pruebas en una actividad al nal de la iteracin o la release. Obviamente, esto require una gran integracin de los o o diferentes roles del equipo, en particular desarrolladores y testers. La prctica comprende tres tareas: Crear casos de prueba, Implementar pruebas y a Ejecutar las pruebas. De ellas surgirn tres artefactos: el Caso de Prueba, el Log de la a prueba y el Script de la prueba. Crear casos de prueba Los casos de prueba se originan en los requerimientos del sistema y son desarrollados en paralelo con su especicacin. Si bien el rol responsable o de esta tarea es el Tester, tambin intervienen los Analistas, Desarrolladores y Stakee holders para asegurar consenso sobre las condiciones de satisfaccin de las pruebas o ya que estas funcionarn en algun momento como los criterios de aceptacin. a o Implementar las pruebas Consiste en implementar los Scripts de prueba, que contienen las instrucciones paso a paso para la ejecucion de la prueba. En esta tarea, adems de disear e implementar el ejecutable del Script, se denen los datos necea n sarios y se organiza los Scripts en suites o grupos relacionados. Ejecutar las pruebas Esta tarea ejecuta los Scripts, analiza los resultados y los comunica al equipo.
4.3
45
La denicin de la prctica se completa con cuatro orientaciones: Mantener suites de o a pruebas automatizadas, Programar pruebas automatizadas, Ideas de prueba y Suites de Pruebas. Prctica: Integracin continua a o Esta prctica plantea que cada miembro del equipo integra su trabajo en forma frea cuente (al menos diariamente). La idea que sustenta esta prctica es que el esfuerzo rea querido para integrar un sistema crece exponencialmente con el tiempo. Integrando el sistema frecuentemente, los aspectos problemticos de la integracin son detectados en a o forma precoz, cuando resultan ms fciles de corregir y por lo tanto el esfuerzo global a a de integracin se reduce. Lo que a su vez se traduce en productos de mayor calidad y o cronogramas de entrega ms previsibles. a La tarea es Integrar y crear un build, que consiste en integrar los cambios hechos por un desarrollador en el cdigo base del sisetma (normalmente en el workspace del o desarrollador), crear el build, ejecutar pruebas sobre los elementos integrados y liberar los cambios probados (cuya forma concreta depende del sistema de gestin de la conguracin o o utilizado). El artefacto involucrado es el Build y la prctica se completa con dos orientaciones a sobre la manera de efectuar la Integracin continua y de Promover (liberar) los o cambios realizados. Prctica: Ciclo de vida riesgo-valor a Provee el Ciclo de Vida del Proceso Unicado. Este ciclo de vida identica cuatro fases: Inicio, Elaboracin, Construccin y Transicin (ver Figura 4.3), cada una de las cuales o o o intenta balancear el valor provisto contra la mitigacin de riesgo apropiada a la fase. o
Figura 4.13: Ciclo de vida Riesgo-Valor Disponer de un ciclo de vida para el proyecto provee a todos los involucrados de puntos de sincronizacin a lo largo de todo el proyecto, facilitando la supervisin y decisiones o o de avanzar-detener en momentos oportunos. Cada fase tendr un conjunto denido de a metas, una o ms iteraciones, tareas y productos espec a cos para satisfacer las necesidades puntuales del proyecto en ese momento. El ciclo de vida en fases tiene por objetivo focalizar en dos drivers bsicos para todos impulsores de un proyecto: reducir el riesgo y crear a valor. Con la presencia de hitos de nalizacin de fase, traducidos en preguntas sencillas, o el equipo de trabajo se mantiene enfocado en minimizar los riesgos y aumentar el valor entregado, tal como sugiere el diagrama de la gura 4.14 Bastar con plantearse en el hito nal de cada fase: a Inicio: Estamos de acuerdo en el alcance y objetivos del proyecto? Creemos que el proyecto deber continuar? a Elaboracin: Estamos de acuerdo en la arquitectura a utilizar? El valor entregado o hasta ahora y los riesgos restantes son aceptables?
46
4.3
Figura 4.14: Curvas de reduccin de riesgo y entrega de valor o Construccin: Tenemos una aplicacin suentemente avanzada como para enfoo o carnos en el ajuste y asegurarnos de un despliegue exitoso? Transicin: La aplicacin est lista para ser liberada? o o a Si la respuesta es armativa, el proyecto estar en condiciones de pasar a la siguiente a fase. De lo contrario, se agrega una nueva iteracin a la fase o el cliente puede decidir o cancelar el proyecto. Prctica: Gestin grupal de Cambios a o Esta prctica intenta capturar los pedidos de cambio que pasan a ser gestionados como a items de trabajo. Se describe el mecanismo de gestin de cambios ms simple: cualquiera o a del equipo puede pedir un cambio al sistema (o a los artefactos de soporte) en cualquier momento, ya sea para corregir un defecto como para agregar una mejora. El pedido es capturado en el backlog de pendientes. En cada planicacin (recordemos la prctica de o a Planicar en dos niveles, el proyecto y cada iteracin), el equipo revisa el backlog, prioriza o el trabajo y decide los cambios que sern implementados a continuacin. a o La prctica incluye slo la tarea Pedir un cambio, que deriva en una actualizacin de a o o la Lista de items de trabajo. La orientacin Presentar pedidos de cambio incluye gu o as concretas sobre el tipo de informacin que debe capturarse en cada pedido con el objetivo o de facilitar su priorizacin y determinar el trabajo involucrado en su satisfaccin. o o Prctica: Arquitectura evolutiva a Describe la forma de construir y mejorar en incrementos la arquitectura del software, al mismo tiempo que se descubren y enfrentan las cuestiones arquitectnicas durante el o desarrollo. El objetivo es reducir el riesgo tcnico sin un esfuerzo muy importante de e arquitectura al comienzo del trabajo. Se plantean tres principios claves: Realizar arquitectura just in time para el resto del proyecto, diriendo para otras fases los aspectos que no son indispensables en la actual o la prxima. o Documentar las decisiones arquitectnicas, utilizando el unico Producto de Trabajo o de la prctica: el Cuaderno de Arquitectura. a Implementar y probar funcionalidad clave como una forma de enfrentar aspectos arquitectnicos, utilizando los prototipos rpidos para validar las asunciones que se o a hacen desde la arquitectura.
4.3 La prctica incluye dos tareas: a
47
Bocetar la arquitectura , que busca capturar las ideas centrales, metas, requerimientos y restricciones de la arquitectura del sistema, sus principales particiones, los mecanismos de arqutiectura a emplear, las interfaces con otros sistemas, etc. Todas las decisiones son documentadas en el Cuaderno de arquitectura. Renar la arquitectura , que construye sobre la arquitectura esbozada y transformndola a en decisiones e implementaciones concretas que dan soporte al desarrollo. Toma en cuenta no slo los antecedentes arquitectnicos, sino cualquier producto desarrollado o o hasta el momento, de forma de evolucionar capturando las decisiones y cambios hechos en el desarrollo. Esta parte es fundamental, ya que la implementacin real es la o unica prueba de que la arquitectura es viable. Todas las decisiones que se tomen en esta tarea sobre actualizaciones de metas, requerimientos, restricciones, mecanismos de arquitectura, etc. son documentadas y comunicadas al resto del equipo. Prctica: Dise o evolutivo a n Describe un abordaje al diseo que asume que evolucionar a travs del tiempo, minn a e imizando la documentacin, pero proveyendo gu para tomar las decisiones de diseo o a n y comunicarlas. En la esencia de esta prctica, cada pasada de diseo agrega, rena y a n refactoriza una solucin mediante una mejor comprensin de los requerimientos, la identio o cacin de los elementos de diseo y su colaboracin, el perfeccionamiento de las opciones o n o de diseo,su comunicacin, el feedback sobre la arquitectura, etc. n o La prctica incluye una tarea, un producto de trabajo y tres orientaciones para disear: a n Dise ar la solucin , que consiste en identicar los elementos y sus interacciones, comn o portamiento y relaciones necesarios para implementar alguna funcionalidad. Se completa con la exposicin visual del diseo para comunicarlo. o n Dise o , que describe la realizacin de la funcionalidad requerida y sirve como abstraccin n o o para el cdigo fuente. o Analizar el dise o, Evolucionar el dise o y Refactorizar el dise o , gu para lln n n as evar a cabo los pasos de Dise ar la solucin en diferentes contextos de proyecto. n o Prctica: Visin compartida a o Esta prctica da soporte a la denicin y comunicacin de la visin global del proyecto. a o o o Se funda en la idea que establecer y mantener una visin compartida del problema a ser o resuelto y de las propiedades de alto nivel de la solucin propuesta mantiene alineadas las o expectativas y reduce el riesgo asociado con la aceptacin del usuario. o Para lograrlo, se centra en el Producto de trabajo Visin, que no slo debe identio o car claramente los diferentes stakeholders, sino proveer una comprensin unicada del o problema, capturar sus necesidades, las restricciones del proyecto y dar background y contexto para los requerimientos que luego sern detallados. Tanto como establecer una a Visin compartida al comienzo, lo es mantenerla durante todo el proyecto. El producto o Visin establece una perspectiva de largo plazo y que provee informacin para anlisis o o a costo-benecio y priorizaciones de trabajo. Los componentes de la prctica son: a Desarrollar la visin tcnica que documenta en el producto Visin la comprensin del o e o o problema a resolver y las caracter sticas de la solucin que se propone. El respono sable es el Analista, pero deben participar activamente tambin los Stakeholders e identicados, el Gerente de Proyecto y el Arquitecto.
48
4.3
Visin es el producto resultado de tarea anterior, sirve para comunicar los qu y por o e qu del proyecto y es el documento contra el que deben ser validadas las decisiones e de alto nivel tomadas en el desarrollo. Glosario es el artefacto que dene los trminos importantes empleados en el proyecto y e que contribuye a la consistencia del trabajo, unicando el vocabulario de todos los involucrados. item[Orientacin: Tcnicas de obtencin de requerimientos y o e o Revisiones efectivas de requerimientos] son dos orientaciones que se incluyen para mejorar la comprensin de las necesidades de los stakeholders. o Prctica: Desarrollo conducido por pruebas (TDD) a Describe una aproximacin al desarrollo en el cual los casos de prueba son denidos o primero y el codigo se desarrolla para superar esas pruebas. La idea es que mediante ciclos muy cortos, se incorpore al sistema slo el cdigo necesario para superar las pruebas, que o o a su tiempo han sido denidas con base en los requerimientos. El TDD ha sido descripto y analizado en varios textos, por ejemplo [Beck 2002], [Astels 2003]. Algunas de las ventajas de esta prctica consisten en que es ms fcil determinar en a a a qu consiste un comportamiento correcto ya que es necesario denirlo para poder hacer la e prueba, los errores se descubren antes, es imprescindible una estrecha colaboracin entre o los desarrolladores, diseadores y arquitectos, es ms fcil saber cundo el cdigo esta n a a a o terminado (cuando la prueba pasa exitosamente) y se produce una natural separacin o de concerns entre quienes desarrollan cdigo nuevo y quienes mejora el cdigo existente. o o En EPL se intenta hacer compatible la utilizacin de TDD con las otras prcticas o a (arquitectura y diseo evolutivo, por ejemplo) mediante las orientaciones incluidas en la n Gu Usar TDD en contexto, que presenta, por ejemplo, la combinacin de TDD con a: o diseo evolutivo, segun muestra la gura 4.15 n
Figura 4.15: TDD en contexto
4.4 Adems, la prctica incluye: a a
OpenUP
49
Implementar test de desarrollador que permita la validacin del cdigo a implemeno o tar por el desarrollador (normalmente en unidades menores a la especicacin funo cional) Implementar solucin mediante cdigo que agregue funcionalidad al sistema o corrija o o errores. Tarea: Ejecutar test de desarrollador contra el cdigo propio, para validar las imo plementaciones realizadas en la iteracin. o Test de desarrollador Implementacin cdigo, archivos de datos u otros archivos que representan las partes o o con las que se elabora el Build del sistema. Prctica: Desarrollo conducido por Casos de Uso a Describe cmo capturar requerimientos con una combinacin de casos de uso y reo o querimentos generales y conducir el desarrollo y las pruebas a partir de esos casos de uso. Al igual que la anterior, esta prctica ha sido extensamente documentada en numerosas a fuentes, por ejemplo [Jacobson et al. 1992] y [Cockburn 2000]. Slo reiteramos aqu que o los tres conceptos claves de esta prctica son el Actor (persona o sistema que interacta a u con el sistema en desarrollo), Caso de uso (la interaccin entre el sistema y uno o ms o a actores y que produce un resultado observable y de valor para los actores involucrados) y Modelo de Caso de uso (el conjunto de Casos de Uso que representa las funcionalides requeridas del sistema). EPL organiza esta prctica con tres tareas, tres artefactos y cuatro orientaciones: a Identicar y esbozar requerimientos capturando los requisitos funcionales y no funcionales que permitan estimar el alcance del trabajo. Detallar escenarios de Casos de Uso con el suciente detalle para permitir su validacin con los stakeholders. o Detallar requerimientos comunes a todo el sistema entendiendo por tales a los que no pueden ser restringidos a un caso de uso en particular. Caso de uso, Artefacto: Modelo de Casos de Uso ya descriptos. Requerimiento com n a todo el sistema captura atributos de calidad y restricciones u con alcance en todo el sistema. Detallar escenarios de casos de uso Identicar y esbozar actores y casos de uso, Desarrollar la especicacin de requerimientos comunes al sistema, Realizacin de caso o o de uso
4.4.
OpenUP
OpenUP es una conguracin de procesos elaborada a partir del EPF y la EPL, como o la versin open source del Proceso Unicado. OpenUP adopta una losof pragmtica y o a a a gil que focaliza en la naturaleza colaborativa del desarrollo de software. Es un proceso agnstico respecto de las herramientas y de bajo nivel de ceremonial. Utilizando el esquema o de Cockburn [Cockburn 2002], podemos ubicarlo en el cuadrante inferior izquierdo, tal
50
4.4
Figura 4.16: Ubicacin de OpenUP o como muestra la Figura 4.16, con un bajo nivel de ceremonial y un rango de medio a alto en el nmero de ciclos o iteraciones durante el proyecto. u La versin bsica de OpenUP se presenta como un proceso m o a nimo, completo y extensible, orientado fundamentalmente a trabajos en proyectos de magnitud pequea y n mediana por equipos concentrados geogrcamente. Es m a nimo porque contiene slo los o roles, tareas y orientaciones considerados imprescindibles para la realizacin del proyecto; o completo, porque cubre las disciplinas esenciales del ciclo de vida del desarrollo de software; extensible, porque sirve como una base que puede ser adaptada o extendida segn u las necesidades. Son cuatro los principios bsicos sobre los que se sustenta la losof de OpenUP[Kroll a a and MacIsaac 2006]: Colaborar Este es el principio central y abarcador que tiene relacin principalmente o con el comportamiento humano. Este principio es el que motiv la mayor parte o de las orientaciones incluidas en OpenUP, principalmente en el Area de la Gestin o del Proyecto, tales como Estimacin gil, Priorizacin de Items de trabajo, Asigo a o nacin de trabajos auto organizada. Tambin inuy al elegir los roles que deber o e o an participar en las tareas y qu productos ser incluidos. e an Balancear Este principio tiene que ver con maximizar el valor entregado por el proyecto dentro del tiempo y presupuesto disponible. intenta capturar algunas prcticas de a gestin de requerimientos que son claves para entender y priorizar las necesidades y o requerimientos para su implementacin. o Focalizar Este principio promueve una comprensin comn de la arquitectura de la soluo u cin y asegura que todos entienden la big picture para saber de qu forma su o e trabajo encaja con el resto y provee input para la optimizacin. o Evolucionar La meta es entregar valor y minimizar el riesgo tan pronto como sea posible produciendo software funcional en cada iteracin que pueda ser demostrado a los o interesados para obtener su feedback. Se basa en el reconocimiento de que uno no puede saber todo desde el comienzo y, aunque ello ocurra, las cosas pueden cambiar. Las iteraciones acomodadas en el contexto de las fases aseguran que uno no itera para siempre.
4.4
OpenUP
51
Aprovechando las caracter sticas de la EPL, OpenUP intenta obtener el mejor compromiso entre el enfoque ordenado por disciplinas del Proceso Unicado y las ventajas propuestas por las mejores prcticas del Movimiento Agil. Como puede verse en el Cuadro a 4.1, que presenta un mapeo entre los Principios bsicos de OpenUP y el Maniesto Agil, los a valores centrales del Maniesto encuentran correspondiencia en los principios de OpenUp. Principios clave de OpenUP Colaborar para alinear intereses y compartir entendimiento Evolucionar para obtener continuamente feedback y mejorar Balancear las prioridades en competencia para maximizar el valor para los involucrados Focalizar en la arquitectura temprano para minimizar los riesgos y organizar el desarrollo Valores del Maniesto Agil Individuos e interacciones sobre los procesos y las herramientas Responder al cambio antes que seguir los planes Colaboracin con el cliente sobre la o negociacin del contrato o Software funcionando antes que una documentacin extensa o
Tabla 4.1: Mapeo entre principios de OpenUP y valores del Maniesto Agil [Kent Beck 2001]
4.4.1.
Conguracin OpenUP/Basic o
La conguracin OpenUP/Basic[Eclipse 2008c] organiza el contenido y los procesos del o mtodo a partir de la Prctica Ciclo de Vida riesgo-valor, con las cuatro fases corresponden e a al ncleo del Proceso Unicado. u Antes de describir los principales patrones de entrega de cada fase, digamos que en OpenUP/Basic, se emplean todas las prcticas denidas en la EPL, pero estn organizadas a a en dos categor ad hoc: Gestin y Tcnicas, que no mapean directamente a mencionadas as o e para la EPL (Kernel gil y Escalabilidad): a Prcticas de Gestin a o Desarrollo iterativo Ciclo de vida riesgo-valor Planicacin en dos niveles o Equipo integrado Gestin grupal del cambio o Prcticas Tcnicas a e Testing concurrente Integracin continua o Arquitectura evolutiva Diseo evolutivo n Visin compartida o Desarrollo conducido por Testing Desarrollo conducido por Casos de Uso
52
4.4
4.4.2.
Fase de Inicio
El propsito es entender el alcance del problema y la factibilidad de una solucin, o o mediante el logro de objetivos tales como: entender lo que hay que construir, identicar la funcionalidad clave del sistema, determinar al menos una solucin posible, entender o el costo, tiempos y riesgos asociados con el proyecto. La gura 4.17 muestra el ujo de trabajo asociado a una iteracin tipo en esta fase. o
Figura 4.17: Actividades de una iteracin en la Fase de Inicio o Las cuatro Actividades incluidas en este Patrn de Proceso consisten en: o Actividad: Iniciar el proyecto , lanzamiento del proyecto, acuerdo con Stakeholders sobre alcance y planes iniciales. Incluye dos tareas: Desarrollar la visin tcnica (a o e cargo del Analista) y Planicar el proyecto (a cargo del Gerente de Proyecto). Actividad: Identicar y renar requerimientos , para detallar un conjunto de Casos de Uso y requerimientos de sistema. El WBS de la Actividad incluye: Identicar y bocetar requerimientos, Detallar Escenarios de Casos de Uso y Detallar Requerimientos comunes al Sistema (todas a cargo del Analista) y Crear casos de Prueba (bajo responsabilidad del Tester). Actividad: Acordar el enfoque tcnico , mediante la tarea Bocetar la arquitectura, e con el Arquitecto como responsable principal, pero con la participacin adicional o del Gerente de Proyecto, el Analista, el Desarrollador y el Stakeholder. Actividad: Planicar y gestionar la iteracin , que consiste en iniciar la iteracin y o o permitir a los miembros del equipo tomar tareas de desarrollo y luego monitorear y comunicar el estado del proyecto a los Stakeholders externos, identicando y manejando las excepciones y problemas. Esta Actividad se desarrollar en cada una de a las iteraciones a lo largo de las cuatro fases del ciclo de vida. En el Hito Objetivo de Ciclo de Vida, se evala el avance hacia el logro de los u objetivos de la Fase y se toma una decisin para desplegar la solucin el entorno operativo. o o
4.4
OpenUP
53
4.4.3.
Fase de Elaboracin o
En esta fase el propsito es validar la arquitectura propuesta para la solucin, espeo o cialmente en lo referido a su factibilidad y los compromisos que supone. Los principales objetivos de la fase son: obtener una comprensin ms detallada de o a los requerimientos; disear, implementar, validar y establecer la base de la arquitectura; mitigar los riesgos esenciales y producir estimaciones adecuadas de cronograma y costos. En la gura 4.18 se pueden ver las actividades que constituyen el ujo de trabajo de una iteracin en esta fase. o
Figura 4.18: Actividades de una iteracin en la Fase de Elaboracin o o El ujo de trabajo de esta Fase incluye: Actividad: Planicar y gestionar la iteracin incluida en la Fase anterior. o Actividad: Identicar y renar requerimientos abordando otro conjunto de requisitos. Actividad: Desarrollar la arquitectura consiste bsicamente en la tarea Renar la a arquitectura, desarrollando en cada iteracin un conjunto de requisitos de arquiteco tura para dar soporte a las actividades de desarrollo priorizadas. Actividad: Desarrollar un incremento de solucin, incluye el diseo, implementacin, o n o prueba e integracin de la solucin para los requisitos dentro del contexto de la ito o eracin. En consecuencia, el WBS de este Patrn de Proceso se compone de: Disear o o n la solucin, Implementar las pruebas de desarrollador, Implementar la solucin, Ejeo o cutar pruebas de desarrollador, Integrar y construir, todas bajo la responsabilidad del Desarrollador. Actividad: Probar la solucin, desde una perspectiva del sistema, vericando la sato isfaccin de requerimientos. Incluye las Tareas Implementar las pruebas y Ejecutar o las Pruebas, a cargo del Tester. Actividad: Actividades continuas, todas las iteraciones poseen desde la fase de Elaboracin una actividad que permite realizar tareas continuas fuera del cronograma, o fundamentalmente efectuar Pedidos de Cambio por cualquiera de los roles del proyecto.
54
4.4
En el Hito de Arquitectura del Ciclo de Vida, se evala el avance hacia el logro u de los objetivos de la Fase y se toma una decisin sobre mantener el alcance original, o cambiarlo o termnar el proyecto.
4.4.4.
Fase de Construccin o
El objetivo principal es desarrollar y vericar la solucin de manera incremental. Las o metas para lograrlo son: desarrollar iterativamente un producto completo que est listo e para ser transferido a la comunidad de usuarios; minimizar los costos de desarrollo y alcanzar algn grado de paralelismo. u
Figura 4.19: Actividades de una iteracin en la Fase de Construccin o o Como se observa en la gura 4.19 las actividades del WBS del Patrn de Proceso o son las mismas que en una iteracin de la Fase Elaboracin excepto el trabajo sobre o o la arquitectura. Esto obedece a que en esta parte del proceso se sigue construyendo el sistema, pero ya ha sido superado el Hito de Arquitectura y por lo tanto consideramos que la solucin de la misma debe quedar estable para el resto del trabajo. o El Hito de la Fase, Capapacidad Operativa Inicial, se evala el avance hacia los u objetivos y se decide desplegar la solucin en el entorno operativo. o
4.4.5.
Fase de Transicin o
El objetivo es desplegar la solucin al entorno operativo y validarla, con: pruebas o beta para validar que se satisfacen las expectativas de usuarios; lograr el acuerdo con interesados que el despliegue ha sido completo. Las actividades de una iteracin de Fase o de Transicin se muestran en la gura 4.20 o Las actividades de una iteracin t o pica de esta Fase deben conducir a la convergencia hacia el despliegue del sistema, mediante dos activiades centrales: Desarrollar un incremento de solucin y Probar la solucin, acompaadas como en otras iteraciones por Planicar o o n y gestionar la iteracin y Realizar tareas continuas. o En el Hito de la Release del Producto se evala el logro de los objetivos y se u decide liberar el producto.
4.4
OpenUP
55
Figura 4.20: Actividades de una iteracin en la Fase de Transicin o o
56
4.4
Cap tulo 5
Capacidad y madurez en usabilidad

5.1. Introduccin o
En el Cap tulo 2 presentamos la nocin de capacidad y madurez en usabilidad. Vamos o a renar un poco ms este concepto y qu herramientas existen para que una organizacin a e o que desarrolla software puede lograr un incremento de estos indicadores. Ya mostramos que existe una relacin entre un proceso de desarrollo centrado en el o usuario y el nivel de usabilidad del producto resultante. Vimos tambin que la efectivie dad y eciencia del proceso DCU est determinada por la capacidad en usabilidad de a la organizacin. Sealamos adems que en el mundo de la ingenier de software, se han o n a a introducido los modelos para la evaluacin de procesos como herramientas para identicar o las debilidades y fortalezas de una organizacin que desarrolla software y luego utilizar o esa informacin para impulsar acciones de mejora. o De manera similar, desde el campo de la usabilidad se han planteado modelos de capacidad en usabilidad que permitan realizar evaluaciones o assessments y obtener gu a para acciones de mejora que levanten el nivel de la capacidad de una organizacin. o La revisin de la literatura, tanto en el campo de usabilidad como de ingenier de softo a ware, muestra una diversidad interesante de aproximaciones a la evaluacin o assessment o de usabilidad: Nielsen: Modelo de madurez en usabilidad corporativa, descripto en [Nielsen 2006a;b] Ehrlich y Rohn: Etapas de aceptacin de Diseo Centrado en Usuario [Ehrlich and o n Rohn 1994] Lundmark y Toresson: Modelo de Madurez en Usabilidad de Proyecto, en [Lundmark and Toresson 2007] Trillium, por Bell Canada [April and Coallier 1995] IBM: Evaluacin de liderazgo en usabilidad, [Flanagan and Rauch 1995] o Schaer: Institucionalizacin de usabilidad, presentado en [Schaer 2004] o INUSE HCS: Modelo de madurez en usabilidad: escala de centralidad en lo humano, en [Earthy 1998] INUSE Processes: Modelo de madurez en usabilidad: procesos, en [Earthy 2000] 57
58
5.2
ISO 18529: Modelo de madurez en usabilidad, [ISO/IEC 2000a] KESSU, de Timo Jokela Jokela [2001b]
5.2.
Modelos de madurez en usabilidad
A continuacin describimos las principales caracter o sticas de estas aproximaciones en el orden en que han sido mencionadas.
5.2.1.
Madurez en Usabilidad Corporativa de Nielsen
Jakob Nielsen ha presentado un esquema de madurez evolutiva de usabilidad que atraviesa ocho etapas ([Nielsen 2006a;b]). No se trata de un verdadero modelo de evaluacin, pero lo incluimos por tratarse de una de las personalidades ms que ms ha o a a contribuido a la difusin y aceptacin de usabilidad y DCU en los mbitos corporativos o o a en las ultimas tres dcadas. Las ocho etapas se describen brevemente a continuacin: e o Etapa 1. Hostilidad hacia la usabilidad La primera etapa es caracterizada por el eslogan un buen usuario es un usuario muerto. El equipo de desarrollo no quiere oir sobre los usuarios o sus necesidades. Su unico inters radica en construir features y e hacerlas funcionar en la computadora. Etapa 2. Usabilidad centrada en los desarrolladores En esta etapa, el abordaje del equipo de diseo consiste en basarse en sus propias intuiciones sobre lo que es bueno n para los usuarios. Despus de todo, los desarrolladores tambin son usuarios y saben e e cundo un sitio es fcil de usar. Adems estos usuarios estn disponibles para toa a a a das las reuniones de trabajo. En esta etapa no existen expl cito aporte de recursos para el trabajo de usabilidad. Etapa 3. Usabilidad de skunkworks La empresa comprende que no puede descansar exclusivamente en el buen juicio de sus diseadores y desarrolladores sobre lo que n es fcil de usar. Sin embargo la mayor de las decisiones todav se basan en ese a a a juicio, se realizan algunos test de usuario parciales y adhoc. La etapa se caracteriza por la falta de un presupuesto asignado a esta actividad. Etapa 4. Presupuesto dedicado a usabilidad Varios escenarios pueden casusar que una compa pueda invertir ms en usabilidad. Un escensario habitual es que algn na a u proyecto pequeo pero de gran impacto en la empresa y con una actividad imporn tante de usabilidad, provoca la creacin de un presupuesto dedicado a usabilidad. o Etapa 5. Usabilidad gestionada Existe un grupo ocial de usabilidad. El l der del grupo tiene control completo sobre todo el trabajo de usabilidad dentro de la organizacin. o Etapa 6. Procesos sistemticos de usabilidad En este punto se reemplaza la idea a de que la usabilidad es algo as como una pocin mgica que se despliega sobre el o a proyecto por el reconocimiento de un proceso de diseo centrado en usuarios con n actividades e hitos a alcanzar. Etapa 7. Dise o centrado en usuario integrado Existen investigaciones de usuario n formales, los proyectos se someten a revisiones en todo el ciclo de vida y no se emplean solo estimaciones de usabilidad, sino que existen mtricas de usabilidad e cuantitativas. Cada proyecto plantea las metas de usbilidad que deben alcanzarse.
5.2
59
Etapa 8. Corporacin conducida por usuarios En este nivel mximo de madurez o a en la usabilidad, los datos de ususario no slo denen proyectos individuales, sino o que determinan los proyectos que la compa debe o no comenzar y apoyar. En la na experiencia el usuario se incluyen no solo el software sino toda la interaccin con el o cliente, tales como soporte y ventas.
5.2.2.
Ehrlich y Rohn
El trabajo de Ehrlich y Rohn (Ehrlich and Rohn [1994]), al igual que el de Nielsen, no se puede considerar un modelo de evaluacin de procesos. Las cuatro etapas que presenta o son descriptas muy brevemente por los autores. Sin embargo, tambin al igual que Nielsen, e es necesario rescatar el esfuerzo para denir la capacidad en usabilidad. Las etapas que propone esta aproximacin son: o Escepticismo organizaciones que nunca estuvieron involucradas con DCU. No tienen claro qu benecios podr obtener. Si existe algn experto en usabilidad, se lo e an u incopora tarde en los proyectos o no tiene inuencia real. Curiosidad existe apertura hacia los beneciois del DCU, pero sin una formacin adeo cuada en la disciplina. Un experto en DCU inuye en algunos aspectos superciales del sistema Aceptacin La gente de DCU es parte del equipo desde el comienzo. Su rol y expertise o se aprecian como una parte importante del desarrollo. Asociacin el equipo es una entidad unicada. Los sistemas no slo son ms usables sino o o a ms utiles. Algunos proyectos o parte de ellos son conducidos por la gente de DCU a
5.2.3.
Lundmark y Toresson
Mattias Lundmark y Johan Toresson presentaron un Modelo de Madurez en Usabilidad para proyectos desarrollado en Suecia y a partir de experiencias en Volvo IT [Lundmark and Toresson 2007]. El nivel de madurez se establece en una escala de 8 etapas. Cada etapa tiene asociados algunos atributos que deben ser reejados por el proceso en anlisis, a tal como muestra la Tabla 5.1.
5.2.4.
Trillium
Trillim [April and Coallier 1995] es un modelo de evaluacin de dominio pblico para o u el desarrollo de productos de telecomunicaciones, desarrollado por Bell Canad. Cubre a varios procesos de desarrollo, incluyendo uno que denomina Ingenier de usabilidad y a que identica varias prcticas. a Los autores sostienen que Trillium est basado en el Capability Maturity Model a (CMM) del Software Engineering Institute [Paulk 1995]. El modelo de Trillium es jerrquico. En el nivel superior, dene ocho reas de capacidad a a para el desarrollo de producto, cada una de las cuales est compuesta de hojas de ruta. a Una de esas reas es Soporte del cliente donde el Ingeniero de usabilidad es una de esas a hojas de ruta y contiene varias prcticas de usabilidad asociadas. a Trillium dene cinco niveles de capacidad, desde el 1 (el ms bajo, desestructurado) a hasta el 5 (el superior, completamente integrado). Diferentes prcticas de ingenier de usa a abilidad sse categorizan en diferentes niveles de capacidad. La categorizacin signica que o las prcticas en el nivel 2 son consideradas ms fundamentales mientras que las ubicadas a a en el nivel 4 son relevantes slo despus que las de los niveles 2 y 3 se llevaron a cabo. o e Algunas de las prcticas indicadas para cada nivel son: a
60
5.2
Atributos (se desconoce la existencia de problemas de usabilidad) Reconocimiento de problemas de usabilidad en el producto desarrollado Actitudes positivas hacia la usabilidad Experto o entusiasta en usabilidad Proyecto inuido por un ejecutivo campen de usabilidad o Presupuesto para usabilidad Mtricas de usabilidad e Metas de usabilidad Estndares de diseo de interfaces a n Participacin de un miembro del grupo o ocial de usabilidad Testing de usabilidad Involucramiento de usuarios antes de que el desarrollo comience Involucramiento real de usuarios nales Presupuesto suciente para un trabajo satisfactorio en usabilidad Seguimiento de la calidad de la experiencia del usuario Integracin de usabilidad con otros proo cesos Gestin de proyecto centrada en o usuario Proyecto integrante de una organizacin centrada en usuarios o Uso de datos de experiencia de usuario recolectados Los datos de usuario son determinantes al denir el nanciamiento del proyecto
Etapa Etapa 0. Desconocimiento Etapa 1. Conciencia de usabilidad
Etapa 2. Usabilidad considerada
Etapa 3. Usabilidad estructurada
Etapa 4. Involucramiento de usuarios
Etapa 5. Usabilidad integrada
Etapa 6. Proyectos centrados en usuarios
Etapa 7. Proyectos conducidos por usabilidad
Tabla 5.1: Modelo de Madurez en Usabilidad de Proyecto Nivel 1. Desestructurado No se indican prcticas en este nivel a Nivel 2. Repetible Se evalan productos competidores. Se visitan puestos de usuario u antes de comenzar el desarrollo. Los usuarios se involucran en el proceso de diseno Nivel 3. Denido Anlisis comparado de productos competidores, en diferentes etapas a del ciclo de vida. Se visita a los usuarios para conocer cmo usan sus sistemas. Se o especican metas de usabilidad con objetivos mensurables. Se utilizan prototipos para desarrollar todas las interfaces de usuario. Se desarrolla formalmente la documentacin de usuario. El material de entrenamiento se verica y valida antes de o entregarlo. Nivel 4. Gestionado Se proyecta la evolucin de necesidades y habilidades de usuario. o Se documenta en forma expl el rationale para el diseno de las interfaces de usuario ta Nivel 5. Completamente integrado No hay prcticas de usabilidad indicadas en este a nivel En un assessment con Trillium, se evala la capacidad analizando en qu medida se u e realizan las prcticas de usabilidad denidas en el modelo. a
5.2
61
5.2.5.
IBM, Evaluacin de liderazgo en usabilidad o
El modelo de IBM, presentado por Flanagan y Rauch en CHI95 ([Flanagan and Rauch 1995],[Rauch and Flanagan 1995]), cubre tanto los aspectos de habilidades y procesos como organizacionales. Dene nueve atributos de madurez en la gestin de usabilidad o clasicados en tres categor as: Organizacin o 1. Conciencia de la organizacin en todos los niveles donde la usabilidad desemo pena un rol para el desarrollo de productos 2. Actividades de la organizacin en todos sus niveles para asegurar un foco imo portante en usabilidad 3. Acciones de mejora por parte de los gerentes para impulsar el foco en usabilidad Habilidades 1. Habilidades de HCI del sta responsable de la usabilidad 2. Recursos de HCI disponibles para las tareas de usabilidad Procesos 1. Foco temprano y continuo en usuarios durante todo el desarrollo 2. Diseno integrado de todos los elementos externos por equipos multidisciplinares 3. Testing de usuario temprano y continuo durante todo el desarrollo 4. Diseo iterativo, con la habilidad de modicar el diseno sobre la base del feedn back recibido de las actividades de usabilidad Todos estos atributos se evalan con referencia a un planteo de referencia (benchu marks). Por ejemplo para el atributo Conciencia de organizacin, podr ser: la organio a zacin entiende el valor de las mediciones de la productividad y satisfaccin del usuario o o o la organizacin valora las habilidades de HCI en el equipo de desarrollo. o El modelo dene cinco niveles de capacidad y benchmarks para cada atributo. La capacidad se evala separadamente para cada atributo en una escala de 1 a 5. Lamentableu mente la unica informacin pblicamente disponible son los trabajos citados y no men o u cionan las bases tericas u otros modelos que sirvieron de referencia. o
5.2.6.
El mtodo de Schaer e
Eric Schaer plantea modelo de madurez en usabilidad como parte de su proceso de institucionalizacin de la usabilidad ([Schaer 2004]). Utiliza una escala de cinco niveles, o donde 1 indica baja madurez y 5 la mxima. a Tal como se muestra en la Tabla 5.2, cada nivel est asociado con una cantidad de a Actividades de Usabilidad, cuya realizacin es la que se toma como parmetro para indicar o a si el nivel de usabilidad fue alcanzado.
5.2.7.
INUSE HCS
El Modelo de Madurez en Usabilidad INUSE: Escala de Centralidad en lo humano, [Earthy 1998] est basado principarmente en el Modelo de Madurez de sistemas Sherwooda Jones Sherwood-Jones [1995], en el Modelo IBM Flanagan and Rauch [1995], ISO 13407 ISO/IEC [1999] y las etapas de calidad de Crosby Crosby [1979]. Una de las dimensiones del modelo est dirigida a evaluar la centralidad de los aspectos humanos en la a
62
5.2
Nivel 2 Nivel 3 Campen Infraestructura o Estrategia Completa Completa Infraestructura Parcial Completa Completa Nivel 4 Stang Completa Nivel 5 Rutinario Completa
Actividad
Nivel 1 Usab. inicial
Estrategia escrita Proceso de revisin o de productos y sitios Metodolog DCU a Procesos de desarrollo integrados Estndares a corporativos de diseo n Proyectos de muestra Entrenamiento continuo Sta en usabilidad Desarrolladores Gestin o Campen ejecutivo o Equipo de usabilidad Expertos en Sta Porc del sta en usabilidad
Parcial
Completa Completa
Completa Completa Completa
Completa Completa Educacin y entrenamiento o
Completa Completa
Completa Completa
Parcial
Parcial
Completa
Completa Completa Completa Completa Completa Completa
Completa Completa Completa Completa Completa Completa Completa Completa
Parcial
Stang Completa Parcial
Completa Completa
Tabla 5.2: Modelo de Madurez en Usabilidad de Schaer organizacin. Dene cinco niveles crecientes de madurez de los procesos cnetrados en las o personas, desde No reconocida hasta Insitucionalizada. El modelo dene adems un conjunto de prcticas de gestin que la organizacin a a o o debe implementar en cada nivel. De la misma forma que en Trillium, hay prcticas de a ingenier de usabilidad categorizadas en los niveles de capacidad. La Tabla 5.3 muestra los a niveles de capacidad y las prcticas de gestin asociadas.El modelo contiene adems varias a o a deniciones de los trminos empleados, gu de uso y algunos templates de documentos e as para instanciarlo.
5.2.8.
INUSE Procesos
El proyecto INUSE dearroll un modelo de evaluacin de procesos basado en el formato o o de assesment denido por ISO 15504-2 ISO15504. El modelo dene una nueva categor a de procesos: el Diseno Centrado en lo Humano (HCD por Human Centered Design, en ingls) que incluye siete procesos [Earthy 2000]. Este modelo es la base del ISO 18529 que e utilizaremos como base para nuestro trabajo. Los detalles comunes entre INUSE Procesos e ISO 18529 sern descriptos ms adelante en este mismo cap a a tulo.
5.2.9.
KESSU
Desde la Universidad de Oulu y con el desarrollo de anlisis emp a ricos de grandes empresas nesas, Timo Jokela propuso en el 2001 el Modelo para procesos de diseno de usabilidad, llamado KESSU [Jokela 2001b]. El modelo se presenta como una interpretacin de los modelos de ISO 13407 e ISO o 18529, incluyendo segn su autor deniciones ms expl u a citas de los procesos de usabilidad y DCU. KESSU dene los procesos a partir de sus resultados, habitualmente entregables, Identica siete procesos, seis corresponden a la ingenier de usabilidad y uno al diseno de a
5.2
63
Nivel de capacidad Nivel X: No reconocido Nivel A: Reconocido
Prcticas de gestin a o Reconocimiento de problemas. La gerencia y el sta son concientes de la necesidad de mejorar los aspectos del sistema en desarrollo vinculados con su uso Calidad en entrenamiento de usuarios. Mtodos de entrenamiento centrados en e usuario Involucramiento activo de usuarios Mtodos centrados en usuarios e Tcnicas de calidad en uso e Integrar procesos de factores humanos con la calidad del sistema Gestionar la iteracin de soluciones de o diseno Mejora sistemtica de la calidad en uso a Aceptacin de habilidades centradas en o usuario
Nivel B: Considerado
Nivel C: Implementado
Nivel D: Integrado
Nivel E: Institucionalizado
Tabla 5.3: Prcticas de gestin en INUSE HCS a o interaccin. Como se observa en la Figura 5.1, KESSU divide el proceso Producir la soluo cin de diseo de ISO 13407 en dos partes: Disenar la Tarea del usuario y Disenar la o n interaccin. o Para el assessment, KESSU evala los resultados de cada proceso a la luz de atributos u de performance. Cantidad. Cuanto ms extensamente se produce un entregable, mayor es su score. a Calidad. Examina la calidad y validez de los entregables Integracin. Brinda un score proporcional al impacto del resultado de un proceso en o el diseno y en otros procesos de usabilidad Cada uno de estos atributos es valorado en una escala de cuatro niveles: No logrado, Logro parcial, Logro amplio y Logro completo.
64
5.3
Figura 5.1: Procesos de Diseo en Usabilidad de KESSU n
5.3.
El Modelo de Madurez en Usabilidad de ISO
El Modelo de Madurez en Usabilidad propuesto por la Organizacin Internacional de o Estandarizacin (MMU-ISO) est contenido en el reporte ISO TR 18529 Descripciones o a de Procesos de Ciclo de Vida centrado en las Personas, que reconoce como base a la Norma ISO 9241:2101 y al trabajo del Proyecto INUSE[Earthy 2000]. El MMU-ISO, que fue desarrollado de manera iterativa y con revisin de expertos, o intenta proveer una base para que quienes planican sepan qu actividades centradas en e los usuarios incluir en un proyecto en particular, as como asistir a quienes desean mejorar la manera en que sus equipos realizan tales actividades.
5.3.1.
Modelo de referencia
El MMU-ISO tiene como modelo de referencia al conocido como SPICE (Software Process Improvement and Capability dEtermination contenido en la Norma ISO 15504 [ISO/IEC 2006], que puede ser visto como la contraparte europea del CMMI-SEI [SEI 1995]. A su vez, ISO 15504 se deriv del ciclo de vida propuesto en ISO 12207 [ISO/IEC o 1995] y algunos modelos de Madurez como Trillium [April and Coallier 1995] y el CMMSEI. El modelo ISO 15504 tiene dos dimensiones: procesos y capacidades. La dimensin o de procesos dene cinco categor Cliente-proveedor, Ingenier Soporte, Gestin y Oras: a, o ganizacin. Dentro de cada una de estas categor cada proceso puede identicarse con o as, un nivel de capacidad en una escala de seis grados: Incompleto, Realizado, Gestionado, Establecido, Predecible, Optimizado. La forma de determinar el nivel de capacidad alcanzado en un proceso consiste en analizar cules atributos de dicho proceso se verican segn la evidencia recogida sobre:: a u Nivel 1 1.1 Performance del proceso Nivel 2 2.1 Gestin de la performance o
1 En el momento de elaboracin de esta Tesis, fue liberada la Norma 9241:210 que consiste bsicamente o a en la incorporacin al cuerpo de la 9241 del contenido de la anterior Norma ISO 13407 o
5.3
65
2.2 Gestin de los productos de trabajo o Nivel 3 3.1 Denicin del proceso o 3.2 Despliegue del proceso Nivel 4 4.1 Medicin del proceso o 4.2 Control del proceso Nivel 5 5.1 Innovacin del proceso o 5.2 Optimizacin del proceso o Cada atributo del proceso implica una o ms prcticas genricas que permiten alcana a e zarlo. Cada prctica produce sus indicadores para asistir en la realizacin del assessment. a o Cada atributo es evaluado en una escala de 4 rangos: No alcanzado (0 - 15 %), Alcanzado parcialmente (16 - 50 %), Alcanzado ampliamente (51 - 85 %), Alcanzado completamente (86 - 100 %).
5.3.2.
El contenido de MMU-ISO
Con la referencia como estructura del modelo de ISO 15504, MMU-ISO dene siete a reas de proceso para el Desarrollo Centrado en el Usuario, de las cuales cinco estn a tomadas directamente de ISO 13407 (que ahora es ISO 9241-210, como ya se indic). Las o otras dos extienden la incumbencia del DCU del mbito estricto del proyecto de desarrollo a a la organizacin (DCU1.Asegurar el contenido de DCU en la estrategia de sistemas) y o a la implantacin en campo de los productos (DCU7.Introducir y operar el sistema). La o capacidad en uno de estos procesos se mide en la escala de seis grados propuesta por ISO15504. Dimensin de los Procesos DCU o Los procesos estn descriptos como prcticas que es necesario implementar para repa a resentar e incluir a los usuarios del sistema durante su ciclo de vida. Cada una est prea sentado como un Proceso con sus propsitos, actividades a realizar e indicadores de xito. o e Presentamos aqu un resumen de cada proceso, ver el detalle completo en el Apndice A. e El primer proceso, DCU1.Asegurar el contenido DCU en la estrategia de sistemas, intenta establecer y mantener el foco de la organizacin sobre los temas relacionao dos con los todos los interesados en el sistema nal (no slo los usuarios nales) en cada o uno de los sectores de la organizacin que tenga inuencia sobre el concepto, desarrollo, o mantenimiento y soporte del software a desarrollar. Incluye actividades tales como: representar al usuario nal, reunir informacin del mercado, denir y planicar las estrategias o de sistemas considerando a los usuarios nales. El proceso DCU2.Planicar y gestionar el proceso (DCU2), persigue el propsito o de especicar la forma en que las actividades centradas en la persona se adaptan al ciclo de vida completo de procesos y la empresa. Busca asegurar que la planicacin de un proyecto o concreto ponga en el centro de las actividades a los usuarios nales, con actividades como: consultar a todos los involucrados, planicar la incorporacin de usuarios en el desarrollo, o identicar, seleccionar y gestionar tcnicas de desarrollo centrado en usuarios y proveer e todo el soporte posible al proceso DCU.
66
5.3
Los procesos DCU3 y DCU4 constituyen el corazn de una ingenier de requerimentos o Ia centrada en usuarios. DCU3.Especicar los requerimientos de los involucrados y la organizacin, se propone establecer los requerimientos del sistema desde la organio zacin y otros interesados, tomando en cuenta las necesidades, competencias y entorno o de trabajo de cada involucrado relevante al sistema, mientras que DCU4.Entender y especicar el contexto de uso, tiene por objetivo identicar, claricar y registrar las caracter sticas de los involucrados, sus tareas y el entorno f sico y organizacional en el que operar el sistema. Entre los dos procesos comprenden el conjunto de prcticas de a a ingenier de requerimientos establecidas en la comunidad de HCI, tales como: identicar a y denir involucrados, establecer objetivos de calidad de uso, evaluar riesgos de HW y SW para los usuarios, identicar las tareas de los usuarios nales, establecer los atributos de usuario, identicar el entorno tcnico, f e sico y organizacional en que ser utilizado el a producto a desarrollar. El ciclo de diseo y evaluacin continua, que constituye un rasgo caracter n o stico de los procesos centrados en usuario, estn corporizados en los procesos DCU5 y DCU6. a DCU5.Producir soluciones de dise o, busca que el equipo de proyecto sea capaz de n crear soluciones potenciales de diseo mediante el uso de prcticas del estado del arte, n a la experiencia y conocimiento de los participantes y los resultados del anlisis del cona texto de uso, tal como fueron obtenidos de DCU3 Y DCU4. Todas las buenas prcticas a de diseo encuentran cabida en las actividades de este proceso: generar un modelo de n tareas, distribuir concientemente las funciones entre usuarios y sistemas, explorar alternativas de diseo, seleccionar y renar alternativas, desarrollar prototipos, trabajar para n la capacitacin y entrenamiento de usuarios, etc. o En forma iterativa, las soluciones propuestas por DCU5, son revisadas en DCU6.Evaluar dise os contra los requerimientos. La intencin es reunir feedback sobre el diseo en n o n desarrollo proveniente de los usuarios y otras fuentes representativas, sin agotar la evaluacin en aspectos puramente tcnicos de performance. Para ello ser necesario especicar o e a el contexto de evaluacin, evaluar todas la alternativas de diseo pertinentes tanto desde o n el punto de vista de sistemas como desde las condiciones de uso. Finalmente, DCU7.Introducir y operar el sistema, se incluye para establecer los aspectos centrados en la persona para el soporte e implementacin del sistema o producto o desarrollado. Para ello ser importante, adems de gestionar el proceso de cambio, dea a terminar el impacto en las actividades de usuarios, realizar las adaptaciones adecuadas, proveer capacitacin, entrenamiento y soporte a los usuarios. o Como vemos, los procesos de ISO 18529 cubren el ciclo completo de la ingenier de a software y pueden analizarse en tres niveles: el de la organizacin (DCU1 y DCU7), el o del desarrollo tcnico del proyecto (DCU3, DCU4, DCU5 Y DCU6) y el de la gestin y e o control del mismo (DCU2), tal como intenta mostrar la Figura 5.2. El diagrama muestra cmo los procesos DCU3 a 6 constituyen un ciclo tcnico slido o e o en el corazn de todo desarrollo y que se repite varias veces durante un proyecto t o pico. DCU 2 cubre la gestin y control. Utiliza la informacin generada por el ciclo DCU 3-6 o o y conecta el ciclo de vida de los procesos DCU con los otros procesos en el desarrollo de sistemas. DCU 1 acta como conexin del ciclo de vida DCU con los procesos de gestin u o o y direccin y tiene en cuenta el futuro de los sistemas, al mismo tiempo que establece los o l mites y metas para los proyectos que ingresan al ciclo DCU 3-6 cuya implementacin o se realiza en el marco de DCU 7. Este ultimo proceso est relacionado con el uso del a sistema, estableciendo una conexin entre los procesos de soporte desde DCU con las o otras actividades de soporte en el proyecto. Dimensin de los Niveles de Capacidad y Madurez o Ya mencionamos que MMU-ISO utiliza los seis niveles de capacidad de SPICE:
5.3
67
Figura 5.2: Ciclo de vida de procesos DCU en MMU-ISO Nivel 0. Incompleto. En este nivel la organizacin no es capaz de realizar el proceso. o Nivel 1. Realizado. Los individuos llevan a cabo las actividades y el proceso alcanza los propsitos denidos. o Nivel 2. Gestionado. Se conocen y controlan los requerimientos de calidad, tiempo y recursos para el proceso. El proceso gestionado entrega productos de trabajo de calidad aceptable dentro de los tiempos denidos y las necesidades de recursos. Nivel 3. Establecido. El proceso se desarrolla en una forma especicada por la organizacin y los recursos estn denidos. El proceso establecido asegura el despliegue o a de un proceso denido, basado en buenos principios de ingenier de sistemas. a Nivel 4. Predecible. La performance del proceso est dentro de los l a mites preestablecidos de recursos y calidad. El proceso predecible se realiza en forma consistente dentro de l mites de control para alcanzar sus metas. Nivel 5. En optimizacin. La organizacin puede ajustar en forma conable los proo o cesos a requerimientos particulares. El proceso optimizado adapta su performance para satisfacer necesidades actuales y futuras del negocio y cumplir sus metas de negocio conablemente. Para ubicar cada uno de los procesos de DCU en uno de los niveles de capacidad, se realiza un anlisis que permita caracterizarlos de acuerdo con una serie pre establecida de a atributos deseables. Estos atributos de denicin de procesos son acumulativos, es decir o que en cada nivel de capacidad se espera que se alcancen todos los atributos deseables de los niveles inferiores. ISO 15504 propone adems que en cada uno de los niveles de capacidad, el proceso a se acompae de prcticas de gestin generales. Estas prcticas dan al equipo y a la organ a o a
68
5.3
nizacin el grado de control necesario sobre todo el proceso de desarrollo. Los elementos o que permiten construir los atributos en este mbito: a Las caracter sticas de la performance de una prctica de gestin que brindan evia o dencia de su implementacin o Los recursos y elementos de infraestructura que dan soporte a la gestin del proceso o Los procesos asociados que dan soporte a las prcticas de gestin a o Estos atributos intentan establecer una evidencia objetiva de que las prcticas de gestin a o asociadas con un atributo de proceso se estn llevando a cabo. a El detalle completo de atributos de producto y de gestin para cada nivel de capacidad o se incluye en el Apndice B. Planteamos aqu los atributos de los Niveles 1, 2 y 3, que e constituyen el foco de esta tesis. En el Nivel 0-Incompleto, obviamente no existen atributos a identicar, mientras que los niveles 4 y 5 requieren un assessment sobre aspectos de la organizacin que exceden y no pueden ser cubiertos slo con la conguracin de un o o o determinado mtodo de desarrollo. e Nivel 1: Proceso realizado El logro de este nivel se demuestra con la identicacin del o siguiente atributo de performance del proceso: el grado en el cual los productos de trabajo resultantes son producidos a partir de los productos de input mediante la realizacin de o las prcticas que comprende este proceso. La prctica de gestin para lograr este atributo a a o del proceso es Asegurar que las prcticas bsicas son realizadas para satisfacer el propsito a a o del proceso. Nivel 2: El proceso gestionado En este nivel debemos identicar tanto atributos de la gestin de la performance como de la gestin de productos de trabajo. o o En cuanto a la gestin del proceso, se valora el grado con el cual el proceso se gestiona o para producir productos de trabajo dentro del tiempo establecido y los requerimientos de recursos. Las prcticas de gestin relacionadas son: a o Identicar requerimientos de recursos para permitir la planicacin y el control del o proceso Planicar la performance del proceso identicando las actividades y los recursos alocados de acuerdo con los requerimientos Implementar las actividades denidas para lograr el propsito del proceso o Gestionar la ejecucin de las actividades para producir los productos dentro del o tiempo establecido y los requerimientos de recursos. Respecto de los productos de trabajo, la evaluacin se enfoca en el grado con el cual los o productos de trabajo son documentados y controlados para satisfacer sus requerimientos funcionales y no funcionales. Para ello ser importante identicar la ejecucin de las a o siguientes prcticas de gestin: a o Identicar requerimientos para la integridad y calidad de los productos de trabajo Identicar las actividades necesarias para alcanzar los requerimientos de integridad y calidad de los productos de trabajo. Gestionar la conguracin de los productos de trabajo para asegurar la integridad. o Gestionar la calidad de los productos de trabajo para asegurar que satisfacen sus requermientos funcionales y no funcionales.
5.3
69
Nivel 3: El proceso establecido El proceso establecido asegura el despliegue de un proceso denido basado en buenos principios de ingenier de sistemas. a En cuanto a la denicin de los procesos, la evaluacin analizar el grado con el cual o o a un proceso dado se dene con un estandar adecuado para contribuir a las metas de la organizacin. Las prcticas de gestin relacionadas son: o a o Identicar entre las disponibles en la organizacin la denicin de proceso estndar o o a que es apropiada al propsito del proceso y las metas de negocio de la organizacin o o Adaptar el proceso estndar para obtener un proceso denido apropiado al contexto a Implementar el proceso denido para lograr su propsito consistente y repetidamente o y soportar la meta de negocio denida para la organizacin o Proveer feedback en el proceso estndar desde la experiencia de usar el proceso a denido Se deber analiza tambin el proceso utiliza recursos humanos calicados e infraestruca e tura adecuada para contribuir a las metas denidas para la organizacin. Las prcticas o a de gestin relacionadas son: o Denir las competencias de recursos humanos reueridas para soportar la implementacin del proceso denido o Denir los requerimentos de infraestructura del proceso para soportar la implementacin del proceso denido o Proveer recursos humanos calicados adecuadamente para satisfacer las competencias denidas Proveer infraestructura adecuada para el proceso de acuerdo con las necesidades denidas. En resumen para evaluar el logro del Nivel 1, deberemos asegurar que las prcticas a bsicas planteadas en cada uno de los siete procesos DCU de MMU-ISO encuentran algn a u grado de realizacin tal que permita la obtencin del propsito del proceso respectivo. o o o Para evaluar el logro del Nivel 2, no alcanzar con que la conguracin del mtodo a o e de desarrollo proponga las prcticas bsicas y alguna gestin que asegure su realizacin. a a o o Tambin debern vericarse los atributos de gestin del proceso que permiten obtener los e a o resultados esperados con los tiempos y recursos previstos, asi como la gestin de calidad o de los productos de trabajo para asegurar que satisfacen los requerimientos acordados para el proyecto. Para calicar un logro de Nivel 3, ser necesario asegurar que el proceso resulta adea cuado a las necesidades de cada proyecto, dentro de la organizacin. Esta adaptacin se o o consigue mediante actividades de tailoring que consistirn en instanciaciones de la conga uracin del proceso en cada proyecto que lo amerite. o
70
5.3
Cap tulo 6
Conformidad de OpenUP/Basic al MMU-ISO

6.1. Introduccin o
Tal como se ha manifestado en cap tulos anteriores, la contribucin que esta tesis se o propone es dar soporte para un proceso de desarrollo de software basado en OpenUP que logre conformidad con el MMU-ISO. Ya hemos visto la descripcin de OpenUP y tambin hemos analizado los objetivos, o e contenido y niveles del MMU-ISO. Es necesario establecer ahora el grado de conformidad que la versin actualmente disponible denominada OpenUP/Basic alcanza para los o procesos y actividades MMU-ISO. Para conseguirlo hemos diseado y puesto en prctica un assessment informal de n a OpenUP/Basic que presentamos en este cap tulo. El carcter de informal del assessment no est dado por la relajacin de los criterios a a o de evaluacin o el recorte del universo de atributos evaluables, sino por la simplicacin o o de los componentes burocrtico-administrativos de un proceso formal de avaluacin y a o certicacin. o Asumimos para esta tarea un escenario ideal en el que una organizacin o equipo de o proyecto congura e instancia un proceso consistente en la implementacin completa de o OpenUP/Basic, con todas las prcticas y contenido tanto de Mtodo como de Proceso. a e Ciertamente se trata de una situacin idealizada que dif o cimente se lleve a cabo en la prctica, pero nos permite realizar un assessment que reeje el mayor grado de capacidad a en MMU-ISO alcanzable con OpenUP en su versin Basic. o En las secciones que siguen describimos el mtodo de assessment utilizado, los resultae dos obtenidos y las conclusiones sobre el nivel de conformidad MMU-ISO que entendemos es posible alcanzar con OpenUP/Basic. Para cerrar el cap tulo incluimos las necesidades de ampliacin y modicacin que detectamos y que servirn de insumo para la propo o a uesta de extensin que permita obtener un proceso basado en OpenUP que conforme al o MMU-ISO en los niveles de Capacidad 1, 2 y 3.
6.2.
Metodolog de assesment a
Un proceso t pico de assesment comienza por denir los objetivos o el alcance del assessment, que proveen la base para la planicacin del proceso de evaluacin. o o El escenario del assessment comienza con la informacin a los involucrados en la oro ganizacin sobre los objetivos y propsitos del assessment. Luego se obtienen datos sobre o o 71
72
6.2
los temas relacionados, en nuestro caso con el diseo centrado en usuario, mediante la n lectura de documentos y reportes y se realizan entrevistas. De las entrevistas habitualmente se obtiene el status de las caracter sticas de una organizacin que pueden impactar o en los proceos DCU. Para determinar qu datos son relevantes y qu caracter e e sticas de la organizacin investigar se utiliza la estructura del modelo de assessment elegido. Luego o se analizan los datos obtenidos y se interpretan a la luz de los criterios planteados por el modelo de assessment. Finalmente se elaboran perles de capacidad (como el que muestra la Figura 6.1) y se informa los resultados a la organizacin. o
Figura 6.1: Perl de Capacidad para un Nivel El mtodo de anlisis consistir entonces en identicar para cada uno de los atribue a a tos de Capacidad que se denen en los procesos de MMU-ISO el nivel de logro con el que OpenUP/Basic permite satisfacerlos, dado el supuesto anterior de una instanciacin o completa de la conguracin. o Como input para recolectar evidencia de logro de cada atributo utilizamos la especicacin completa de OpenUP/Basic Release 1.5.0.1 [Eclipse 2008c]. Al decir completa o indicamos que cualquier contenido, ya sea de mtodo o proceso, que permita interpretar e que de ser empleado en un proyecto concreto indicar la satisfaccin de algn atributo a o u de MMU-ISO, ser considerado evidencia suciente de tal capacidad. a Estamos intentando determinar la Capacidad de OpenUP/Basic en los Niveles 1 a 3 del MMU-ISO, eso implica: Para el Nivel 1, analizar si cada prctica base est cubierta a a Para el Nivel 2, analizar el grado de capacidad que alcanza OpenUP para los atributos de gestin de la performance del proceso y de los productos o Para el Nivel 3, analizar el grado de capacidad mostrado respecto de los atributos de denicin de procesos y recursos. o En consecuencia, el ciclo de evaluacin es el siguiente: o 1. Tomamos un proceso DCU del MMU-ISO 2. Tomamos un nivel a evaluar
6.2
Metodolog de assesment a
73
3. Para cada atributo del Proceso en el Nivel elegido analizamos la especicacin de o OpenUP/Basic y buscamos Contenidos o Procesos que permitan satisfacer el atributo. Determinamos el grado de logro del atributo MMU-ISO en un ranking de 4 niveles: N: No hay evidencia del logro de la prctica denida (Score numrico: 0) a e P: El desarrollo de las actividades incluidas en OpenUP permite alcanzar un logro parcial del atributo (Score numrico mayor que 0 y menor o igual que e 0.3) A: El desarrollo de las actividades incluidas en OpenUP permite alcanzar un logro amplio del atributo (Score numrico mayor que 0.3 y menor o igual que e 0.7) C: El desarrollo de las actividades incluidas en OpenUP permite alcanzar un logro completo del atributo (Score numrico mayor que 0.7) e 4. En los casos de duda sobre el logro entre dos niveles para una determinada prctica, a aplicamos el benecio de la duda y calicamos en el nivel superior 5. El proceso se repite para el prximo atributo del nivel. o 6. El proceso se repite para el prximo nivel, hasta que no se encuentra evidencia de la o realizacin de ninguna prctica en este nivel o hasta que se alcanza el l o a mite superior establecido para la evaluacin. o 7. El ciclo 2-6 se repite para el siguiente proceso DCU de MMU-ISO El formato de la hoja de evaluacin empleada (basada en [Earthy 2000]) se muestra o en la tabla 6.1. Se utiliza una hoja para cada Proceso DCU de MMU-ISO.
MMU-ISO Atributo a medir Atributo 1.1 Atributo 1.n Score combinado de atributos 1.1 a 1.n Atributo 2.1 Atributo 2.n Score combinado atributos 2.1 a 2.n Score combinado de Nivel 1 siguiente nivel ... Evidencia OpenUP Prctica EPF a Evidencia OpenUP Contenido de Proceso Nivel 1 Evidencia OpenUP Contenido de Mtodo e
Score
...
...
...
...
Tabla 6.1: Esquema de hoja de assessment En las celdas correspondientes a la columnas Evidencia de OpenUP indicamos los elementos identicados como evidencia del logro del atributo MMU-ISO a medir. La columna Prctica EPF, nos sirve para identicar cul o cules de las Prcticas a a a a de la Librer del Eclipse Proces Framework contiene suciente evidencia para alcanzar a algun nivel de logro del atributo. La correspondiente a Contenido de Proceso nos sirve para precisar las Actividades, Patrones de proceso o Procesos para despliegue implicados en tal logro, mientras que en la correspondiente a Contenido de Mtodo cargamos e para cada uno de los Procesos sealados los Roles, Artefactos o Tareas particularmente n involucrados en ese logro. Para cada uno de los atributos de MMU-ISO se indica el grado de logro en la escala mencionada (traducida a valores numricos para facilitar los clculos e a de promedios). Luego realizamos un promedio del logro de todos los atributos para una
74
6.3
clase (Performance, Gestin de performance, Gestin de Producto, Denicin de Proceso, o o o Denicin de Recursos de Proceso) y con estos promedios se establece la medicin de logro o o del nivel de capacidad para el proceso en cuestin. o En el Apndice B se incluye la hoja de evaluacin completa con todos los atributos e o utilizados para los niveles 1, 2 y 3 evaluados y los resultados para OpenUP/Basic. Como ejemplo, la gura C.1 muestra el sector correspondiente a la evaluacin del Proceso DCU1. o
Figura 6.2: Resultados para el Proceso DCU 1
6.3.
Resultados
A continuacin, mostramos con mayor detalle el tipo y grado de logro alcanzado por o cada Proceso DCU en cada uno de los Niveles. El listado completo de elementos de proceso y mtodo de OpenUP/Basic involucrados se incluye en el Apndice C. e e
6.3
Resultados
75
6.3.1.
Capacidad en DCU1 (Asegurar el contenido de DCU en la estrategia de sistemas)
En este proceso debemos encontrar evidencia de que OpenUP/Basic asegura el foco en temas relacionados con usuarios (y stakeholders en general) en cada una de las reas a relacionadas con la idea, desarrollo, mantenimiento y soporte del sistema. Nivel 1 - Proceso realizado En este nivel slo encontramos evidencia del primer atributo Representar a los stakeo holders. Las tareas de Denir la visin, Planicar el proyecto y Encontrar y bocetar reo querimientos incluyen entre los roles participantes al Stakeholder. Sin embargo, la especicacin no da pautas concretas sobre la manera de identicar a todos los stakholders o pertinentes del proyecto. Por otra parte, es importante marcar que estas tareas estn ina cluidas en Patrones de Proceso slo para las Fases de Inicio y Elaboracin, lo que podr o o a dicultar el trabajo de abogado de los usuarios a lo largo de todo el proyecto. Por esa razn es que consideramos que el atributo est slo parcialmente cubierto. o a o No existe evidencia de que la sola aplicacin de OpenUP/Basic permita el logro de o los otros cuatro atributos de este nivel, ni la realizacin o utilizacin de los productos de o o trabajo que normalmente estn asociados a las prcticas requeridas por ellos, tales como a a informes del mercado, anlisis de tendencias y planteo de estrategias DCU. a En consecuencia, la capacidad manifestada por OpenUP/Basic para el Proceso DCU1 en el Nivel 1 es Parcial. Nivel 2 - Proceso gestionado Los mismos elementos de mtodo que permiten satisfacer el atributo DCU1.1, brindan e evidencia de logro de las prcticas de gestin tanto de la performance del proceso como del a o producto. Sin embargo, al estar restringido a las tareas relacionadas con la identicacin o de los stakeholders no podemos considerar que la capacidad sea siquiera amplia. El contexto de las prcticas OpenUP Equipo integrado, Visin compartida, Plania o cacin en dos niveles y Desarrollo conducido por Casos de uso permite abordar de mano era adecuada la planicacin, gestin y control de los productos de trabajo vinculados a o o la participacin de los stakeholders. o La capacidad manifestada en este Nivel es Parcial. Nivel 3 - Proceso establecido No hay evidencia de ningun tipo Prcticas de Gestin vinculadas a la denicin de a o o procesos o de recursos a incluir en lo concerniente con el Diseo Centrado en el Usuario. n La capacidad manifestada en este Nivel es Nula.
6.3.2.
Capacidad en DCU2 (Planicar y gestionar el proceso DCU)
Buscamos aqu evidencia sobre la forma en que las actividades centradas en usuario estn incluidas en todos los planes del proyecto y en las actividades de gestin. a o Nivel 1 - Proceso realizado Encontramos evidencias de logro de todos los atributos de este nivel, aunque con un grado dispar. Los dos primeros (Consultar a los involucrados e Identicar y planicar la participacin de usuarios) alcanzan un logro amplio, fundamentalmente gracias a la inclusin o o
76
6.3
de Prcticas tales como Equipo integrado, Visin compartida, Planicacin en dos nivea o o les y Desarrollo iterativo. Las tareas que incluyen estas prcticas (por ejemplo Planicar a el proyecto, Planicar la iteracin, Denir la visin tcnica) permiten mantener a los o o e involucrados en el loop de consultas y decisiones. Sin embargo, a la hora de profundizar el enfoque DCU con la seleccin de mtodos o e y tcnicas adecuadas, la planicacin de actividades DCU espec e o cas y el soporte a tales procesos, OpenUP no dice nada expl cito y a menos que en el equipo existan especialistas vinculados con estas reas el logro por parte de la especicacin del mtodo slo puede a o e o considerarse como parcial. Por ejemplo, la unica referencia de OpenUP respecto de la incorporacin de usuarios o y stakeholders en el equipo es un prrafo dentro de la Orientacin Designar recursos para a o un proyecto (traduccin propia): o Incluya stakeholders. Los stakeholders, incluyendo los orientados al negocio como los usuarios nales y los tcnicos como el sta de operaciones, pueden e agregar valor signicativo al equipo. En lugar de slo entrevistarlos para obteno er informacin o pedirles que revisen su trabajo, por qu no incluirlos como o e participantes activos del equipo? Y lo mismo para la posible inclusin de especialistas en interaccin y factores humanos o o Incluya especialistas para tareas de corto alcance y espec cas. Los especialistas pueden agregar valor an en un equipo de desarrollo gil, particularmente u a cuando tienen habilidades y experiencia muy espec ca que los miembros del equipo carecen. A menudo puede ser muy efectivo traer un especialista al equipo por un per odo breve para ayudar con una tarea espec ca (como la instalacin o y el setup de un servidor de aplicaciones o para tomar parte en una revisin o simplemente Con una especicacin tan somera, es dif garantizar que dadas ciertas condiciones de o cil proyecto, el equipo se asegurar que todas las instancias del proyecto sern adecuadamente a a planicadas y gestionadas desde un punto de vista centrado en los involucrados, que en todas las fases se abogue por el DCU y se provea el soporte adecuado a los restantes integrantes del equipo. Algunos de los productos de trabajo que dar cuenta de estas tareas y que no estn an a apropiadamente incluidos en OpenUP/Basic son los procedimientos para establecer actividades espec cas de DCU e integrarlas con otras actividades de diseo, cmo garantizar n o que el conocimiento del contexto de uso (ver DCU4) y los requerimientos de usuarios y organizaciones conducen el proceso de diseo, que se emplea el prototipado para mejon rar y renar el diseo, que un nmero adecuado de usuarios y sus representantes son n u consultados para identicar contexto de uso. En consecuencia, en el anlisis global del Nivel encontramos que la capacidad alcanza able es de Amplia. Nivel 2 - Proceso gestionado Algo similar ocurre con el Nivel 2. Existe evidencia de todas las prcticas de gestin a o requeridas para el nivel, pero concentradas en las actividades relacionadas con algn tipo u de inclusin de involucrados en la planicacin del proyecto y de cada iteracin. Esto o o o no implica necesariamente la evaluacin de diferentes tcnicas y la seleccin de la ms o e o a apropiada para alguna fase del proyecto, asi como tampoco el control necesario para asegurar que un nmero y calicacin adecuada de usuarios y otros involucrados prestan u o el feedback necesario en cada etapa del proceso (y que ese feedback es convenientemente utilizado para guiar el diseo). n
6.3
Resultados
77
Por estas razones encontramos que la capacidad alcanzable para Nivel 2 en el Proceso DCU2 es Parcial. Nivel 3 - Proceso establecido Otorgando el benecio de la duda, podr amos considerar que las prcticas de gestin a o del nivel vinculadas con la identicacin y denicin de recursos tienen algn grado de o o u logro (en particular en lo referido a identicar las necesidades de recursos humanos para involucrar a usuarios en el proyecto). Lamentablemente no hay evidencia de requisitos de OpenUP referidos a los diferentes tipos de usuarios o stakeholders a incluir en el proyecto. La capacidad en este Nivel es Nula.
6.3.3.
Capacidad en DCU3 (Especicar los requerimientos de stakeholders y organizacin o
Se trata en este proceso de determinar la capacidad de OpenUP/Basic para alcanzar una identicacin y especicacin apropiadas de los requerimientos para el sistema, tanto o o de la organizacin como de los usuarios nales. o Nivel 1 - Proceso realizado Todos los atributos del Nivel 1 estn cubiertos en OpenUP. Tres de ellos alcanzan a un logro amplio: Claricar y documentar las metas del sistema, Evaluar los riesgos para los stakeholders, Generar requerimentos de stakeholders y organizacin. Las actividades o vinculadas con la denicin de una Visin compartida y la Identicacin iterativa de o o o requerimientos y soluciones contribuyen a ese logro. En cambio, los restantes atributos son cubiertos en una medida medida mucho menor. No hay evidencia en OpenUP/Basic que asegure una Denicin completa y detallada de o los stakeholders. Tampoco encontramos evidencia sobre una denicin integral del sistema, que cono sidere el contexto completo de la situacin, no slo del software involucrado. o o Finalmente, respecto de la jacin de objetivos de calidad de uso, OpenUP es demasio ado escueto, apenas en la Orientacin Desarrollo de especicacin de requerimientos de o o sistema se indica como todo mtodo para la identicacin y especicacin de requisitos e o o de usabilidad, lo siguiente (traduccin propia): o
1. Identique los temas claves de usabilidad observando las tareas cricas, t los perles de usuario, las metas de sistema y los problemas de usabilidad anteriores. 2. Elija el estilo adecuado para expresar los requerimientos: Estilo de performance: especique con qu rapidez los usuarios pueden e aprender varias tareas y cmo pueden ralizarla despus del entreo e namiento. Estilo de defectos: m,s que medir los tiempos de tareas, identique a los defectos de usabilidad y especique con qu frecuencia pueden e ocurrir. Estilo de gu especique la apariencia general y el tiempo de rea: spuesta de la interfaz de usuario con referencia a algn estndar u a bien denido. 3. Escriba los requerimientos reales,
78
6.3
La ponderacin de los diferentes grados de logro y utilizando el benecio de la duda, o consideramos que el logro de Capacidad DCU3 en nivel es Amplio. Nivel 2 - Proceso gestionado Los cuatro atributos de gestin vinculados con la performance del proceso estn cuo a biertos parcialmente por mtodos de OpenUP. En particular, la administracin de las e o prcticas que evidencian logro amplio en el Nivel 1. Lo mismo ocurre con otros tantos a atributos de gestin de productos de trabajo. o Lamentablemente, no hay evidencia de que un proceso OpenUP/Basic incluya prctia cas de gestin de performance y producto con la misma amplitud para el resto de los o atributos. La evaluacin global del Nivel 2 para este proceso es Parcial. o Nivel 3 - Proceso establecido En este nivel slo podemos advertir cierta evidencia de logro para los atributos vinculao dos con los recursos del proceso, pero no con la denicin misma de procesos (consideracin o o de alternativas, adaptaciones al proyecto, etc.). En consecuencia OpenUP/Basic resulta de capacidad Nula para DCU3 en el Nivel 3.
6.3.4.
Capacidad en DCU4 (Entender y especicar el contexto de uso)
Pretendemos encontrar aqu evidencia de que OpenUp asegura una buena especi cacin de contexto de uso del sistema, incluyendo los involucrados, sus tareas, el entorno o f sico y el organizacional. Nivel 1 - Proceso realizado Este proceso complementa a DCU3 en la visin centrada en usuarios de la ingenier o a de requerimientos. Por tanto, es lgico que al menos en el Nivel 1 todos los atributos o encuentren algn grado de logro. u Lamentablemente, sin embargo, slo es posible hallar buena evidencia de capacidad o OpenUP/Basic respecto de la identicacin y documentacin de las tareas del usuario, o o particularmente gracias al enfoque de Desarrollo conducido por Casos de Uso. La consideracin de aspectos signicativos de los usuarios (caracter o sticas f sicas, culturales, educativas, etc. no relacionadas exclusivamente con su rol respecto del sistema) o las condiciones del contexto de la organizacin, el ambiente f o sico y tcnico, apenas e requieren alguna descripcion en el documento de Vision tecnica. En resumen, la capacidad manifestada respecto de Nivel 1 en DCU4 por OpenUP/Basic es Parcialmente cubierta. Nivel 2 - Proceso gestionado Los defectos de logro en el Nivel 1 se propagan al 2. La especicacin de OpenUP o muestra evidencia de prcticas de gestin de performance y producto en lo relacionado a o con las tareas del usuario vinculadas directamente al sistema. Es obvio que aquellas especicaciones que apenas son descriptas en su versin bsica, no tendrn asociadas prctias o a a a para gestionar la performance del proceso que permita obtenerlas en tiempo y con la calidad necesaria, como tampoco habr indicacin de tareas para validar la calidad de los a o artefactos de trabajo. En este sentido, es notable la carencia de indicaciones para gestionar actividades y productos de trabajo que especiquen de manera adecuada los elementos del entorno de
6.3
Resultados
79
organizacin, tcnico y f o e sico donde ser empleado el sistema y que pueden derivar en a requerimientos no identicados directamente por los usuarios. La capacidad demostrada en este Nivel es Parcial. Nivel 3 - Proceso establecido Como hemos visto para procesos anteriores, la evidencia para cubrir este Nivel deber a asegurar que la organizacin o el grupo de desarrollo se plantea un paso previo a la o planicacin del proyecto y de cada iteracin, decidiendo las mejores implementaciones o o de tareas y artefactos para cubrir las necesidades del proyecto. En este sentido, slo encontramos evidencia parcial en las prcticas OpenUP Visin o a o integradora y Desarrollo conducido por Casos de uso para las fases de Inicio y elaboracin respecto, lo cual en cierto modo es lgico (el pase a la Fase de Construccin ocurre o o o cuando el Hito de Arquitectura es alcanzado). Sin embargo, el proceso de entrega de la Fase de Construccin admite iteraciones sobre la identicacin y renamiento de requero o imeintos, lo cual deber requerir el tailoring del proceso antes de asumir cualquier versin a o estandarizada como correcta. La capacidad de este Nivel es Nula.
6.3.5.
Capacidad en DCU5 (Producir soluciones de dise o) n
En este proceso buscamos evidencia de que OpenUP/Basic garantiza la creacin de o soluciones de diseo mediante el uso de las prcticas que son estado del arte en DCU, n a aprovechando la experiencia y conocimiento de todos los participantes e involucrados y tomando en cuenta los resultados del anlisis de contexto de uso realizado en DCU4. a Nivel 1 - Proceso realizado Encontramos evidencia de logro en cuatro de los ocho atributos del nivel. OpenUP/Basic contiene elementos de proceso y mtodo que aseguran el enfoque sobre la distribucin adee o cuada de funciones entre usuarios y sistemas y la generacin iterativa e incremental de o propuestas de diseo. Por ejemplo en las tareas Bocetar la arquitectura o Disear una n n solucin. o Lamentablemente, no ocurre lo mismo respecto de un abordaje integral del diseo n del sistema, incluyendo las tareas y puestos de trabajo del usuario. Tampoco brinda OpenUP/Basic evidencia sucente de un enfoque de diseo basado en prototipos, modelos n o maquetas, caracter stica distintiva de los procesos centrados en usuario. Finalmente no existe ningn tipo de evidencia respecto de los atributos vinculados con u la produccin de elementos de entrenamiento y soporte a los usuarios. o Por lo tanto, a pesar de tener un logro razonable de los primeros atributos mencionados, la carencia respecto del resto lleva la capacidad de este proceso en el Nivel 1 a Parcial. Nivel 2 - Proceso gestionado Al igual que en procesos anteriores, para este nivel se puede encontrar evidencia de prcticas de gestin para la performance y los items de trabajo mencionados en el Nivel a o 1. En particular, para la creacin y evolucin incremental de la arquitectura y el diseo o o n de soluciones de sistema (Prcticas OpenUP Arquitectura evolutiva y Dise no evolutivo). a La capacidad demostrada es de logro parcial. Nivel 3 - Proceso establecido No encontramos evidencia de logro para este nivel. La capacidad es Nula.
80
6.3
6.3.6.
Capacidad en DCU6 (Evaluar los dise os contra los requern imientos)
Buscamos evidencia de que OpenUP asegure la prueba y recoleccin de feedback de o los usuarios e involucrados en general sobre el diseo en desarrollo. n Nivel 1 - Proceso realizado Como es lgico, la evidencia recogida para este proceso se concentra en la prctica o a OpenUP Testing concurrente. All aparece el tipo de prueba que puede estar vinculada con usuarios (a diferencia de la Prueba de desarrollador, incluida en la Prctica Desarrollo a conducido por pruebas o TDD). Los productos de trabajo involucrados son el Caso de Prueba, el Log de Prueba y el Guin de la Prueba. o Los elementos de Proceso y Mtodo relacionados con ellos permiten cubrir de alguna e forma tres de los seis atributos del Nivel. En efecto, podemos reconocer evidencia para satisfacer parcialmente: Especicar y validar el contexto de evaluacin, particularmente con las tareas de o Crear casos de Prueba e Implementar guiones de prueba. Evaluar prototipos para mejorar el diseo, en la Actividad Testear la solucin (que n o subsume las Tareas Implementar pruebas y Ejecutar pruebas). Aunque las especicaciones OpenUP no hablan espec camente de prototipos, podemos considerar que la realizacin de esta actividad durante todas las iteraciones, en particular de la Fase o elaboracin, tienen el mismo efecto y, como seala la descripcin de esa Actividad o n o Stakeholders and end-users also may also be involved in performing tests to accept the release. Evaluar el sistema para chequear que se satisfacen los requerimientos, la evidencia del item anterior aplica tambin en este. e Lamentablemente, OpenUP/Basic no proporciona evidencia respecto de: Evaluar prototipos iniciales para denir requerimientos de sistema, por cuanto esta forma de elicitacin no constituye parte mandatoria en la prctica Desarrollo o a conducido por Casos de uso Evaluar el sistema para vericar que se siguieron las prcticas requeridas, debido a a que como vimos en los procesos DCU1 y DCU2, OpenUP no asegura la adhesin o del proyecto a estndares y sugerencias de usabilidad y calidad de uso en general a Evaluar el sistema para asegurar que continuamente se cumplen metas organizacionales y necesidades de usuario, por cuanto, como veremos en DCU7, OpenUP no aborda tareas de proyecto concernientes a la implantacin del sistema en la Fase de o Transicin. o Algunos de los productos de trabajo que un proceso de evaluacin centrado en usuario o generar y de los cuales no se encuentra evidencia en OpenUP son: listado de defectos de a calidad de uso, Mtricas de ergonom empleadas, Registro en audio y video de pruebas, e a Logs de observacin de usuario, Transcripcin de entrevistas. o o Por lo expuesto, consideramos que la capacidad demostrada por OpenUP en este Nivel es Parcial.
6.4 Nivel 2 - Proceso gestionado
Perles de capacidad y posibilidades de extensin o
81
Enconcontramos aqu evidencia de Prcticas de gestin, tanto para el proceso como a o para los productos, respecto de los artefactos y tareas que mencionamos en el Nivel 1 y que permitieron cubrir la mitad de los atributos. En las cuatro fases se llevan adelante las Tareas mencionadas para el Nivel 1, aunque ubicadas lgicamente en diferentes patrones de proceso. En Inicio, Crear pruebas constio tuye el mtodo de aproximacin al testing dentro de la Actividad Identicar y Renar e o requerimientos, para pasar en las Fases de Elaboracin y Construccin a constituir casi o o con entidad propia la Actividad Testear la solucin. o Como resulta lgico no hay ningn tipo de prctica de gestin prescripta para aquellos o u a o atributos que no han sido cubiertos en el nivel 1. Por lo tanto, al igual que en el anterior, asociamos una logro Parcial al actual Nivel 2. Nivel 3 - Proceso establecido No encontramos evidencia de logro en este Nivel.
6.3.7.
Capacidad en DCU7 (Presentar y operar el sistema)
El propsito del proceso es garantizar que los aspectos centrados en usuario son consido erados al implantar el sistema desarrollado y dar soporte posterior a todos los involucrados. Hemos visto al describir OpenUP/Basic que todos los aspectos posteriores a la construccin y testing del sistema no son abordados por el mtodo, asumiendo que el resto o e de la organizacin donde se desarrolla el proyecto tiene establecidos actividades, tareas y o artefactos que garanticen una buena transicin del producto. o Nivel 1 - Proceso realizado Con este planteo inicial es obvio que no encontraremos evidencia de logro en ninguno de los niveles de MMU-ISO. La capacidad de OpenUP/Basic para este proceso es Nula en el Nivel 1 y, en funcin del mecanismo de assessment no es procedente continuar con o los restantes niveles. Nivel 2 - Proceso gestionado No aplica por falta de logro de Nivel anterior. Nivel 3 - Proceso establecido No aplica por falta de logro de Nivel anterior.
6.4.
El anlisis cuantitativo de los resultados globales del assessment muestra que OpenUP/Basic a no alcanza un logro completo de ninguno de los atributos que MMU-ISO establece para los niveles 1 a 3. Incluso son muy pocos los que pueden mostrar un logro amplio (apenas en 11 atributos sobre un total de 156 revisados). Las Figuras 6.3, 6.4 y 6.5 muestran la distribucin de atributos para cada proceso o DCU el tipo de logro alcanzado por los atributos del proceso en cada nivel de capacidad. Al comenzar a analizar los resultados por cada uno de los Niveles, podemos sealar n que OpenUP/Basic alcanza un aceptable grado de conformidad MMU-ISO para el Nivel 1 (Proceso realizado) en las actividades centrales del desarrollo centrado en usuario: requerimientos, diseo, construccin y evaluacin. En el Nivel 2 (Proceso gestionado), solo n o o
82
6.4
Figura 6.3: Cantidad de atributos por logro alcanzado para el Nivel 1
DCU4 (Comprender el contexto de uso) alcanza un logro aceptable, es algo menor para los DCU 1,2,3,5 y 6 y nula para DCU7. En el Nivel 3 prcticamente no existe logro por a parte de OpenUP/Basic. En la Figura 6.6 mostramos el perl de capacidad de cada uno de los procesos DCU en los tres niveles del MMU-ISO que nos interesan. Surge claramente que las unicas reas que logran algun grado de conformidad son las a del ncleo central indicado por la gura 5.2 (pgina 67): DCU3 a DCU6 ms el proceso u a a de planicar y gestionar el desarrollo. Es razonable que en virtud de los objetivos de OpenUP, los procesos relacionados con la implantacin en la empresa u organizacin de o o un desarrollo centrado en usuario alcancen una logro m nima cuando se trata de pensar estrategias (DCU1) nula, a la hora de efectuar transiciones e instalaciones de sistemas (DCU7). Todas las prcticas de gestin (Planicacin en dos niveles, Equipo integrado, Dea o o sarrollo iterativo, Ciclo de vida riesg-valor, Gestin grupal del cambio) muestran alguna o evidencia de logro DCU, aunque ninguna alcanza para poder calicar con una C (completa) o A (amplia). En todos los casos, como detallaremos ms adelante, se trata de algunos a elementos de mtodo (o partes de los mismos) que, de ser llevados a cabo por recursos e con background en HCI y diseo de interaccin alcanzar un logro parcial de procesos n o an
6.4
83
Figura 6.6: El perl de capacidad por proceso DCU en niveles 1 a 3 de MMU-ISO DCU MMU-ISO. Las prcticas tcnicas, con excepcin de Integracin continua y Desarrollo conducido a e o o por pruebas (TDD), tambin exhiben un logro parcial, particularmente los objetivos de e Visin compartida y Arquitectura y diseo evolutivos. En el caso del Desarrollo conducido o n por Casos de Uso, se da la misma situacin respecto de la necesidad de contar con recursos o experimentados en HCI y DCU (lo cual no constituye un requerimiento en OpenUP/Basic) ya que, por ejemplo, la identicacin y especicacin de stakeholders podr resultar o o a incompleta o parcial para la elaboracin posterior de especicaciones de tareas y contextos o de uso. El planteo de esta tesis es proveer un proceso de desarrollo basado en OpenUP que permita alcanzar una conformidad con MMU-ISO en los Niveles de capacidad 1, 2 y 3. Para ello consideramos necesario alcanzar una especicacin que cubra completamente o el Nivel 1 (al menos en los procesos DCU2 a DCU6) y alcance al menos una Capacidad Amplia en los Niveles 2 y 3, para todos los procesos. Para alcanzar un perl de capacidad de cobertura completa para el nivel 1, dependiendo del resultado que mostramos en el assessment necesitaremos tres tipos de acciones para cubrir las brechas identicadas: Completar: agregar o modicar contenidos de mtodo y proceso para pasar de la e
84
6.4
cobertura amplia a la completa. Ampliar: extender OpenUP/Basic para que los procesos en los que se evalu cobero tura parcial se alcance al menos el nivel siguiente Incluir: generar el contenido de mtodo y los procesos necesarios para que los procee sos que no estn cubiertos en OpenUP/Basic segn el assessment realizado, puedan a u alcanzar un nivel Amplio de logro en un nuevo assessment. La Tabla 6.2 lista los atributos MMU-ISO cuya capacidad debe ser mejorada por OpenUP para alcanzar una Capacidad Completa en el Nivel 1, indicando qu tipo de e accin es necesaria en cada uno de ellos. o
Procesos DCU y actividades incluidas DCU.1 Asegurar el contenido DCU en la estrategia de sistemas DCU.1.1 Representar los stakeholders DCU.1.2 Analizar el mercado DCU.1.3 Denir y planicar la estrategia de sistemas DCU.1.4 Reunir respuesta de mercado DCU.1.5 Analizar tendencias de usuarios DCU.2 Planicar y Gestionar el proceso DCU DCU.2.1 Consultar a los stakeholders DCU.2.2 Planicar la participacion de usuarios DCU.2.3 Seleccionar metodos y tecnicas centradas en usuarios DCU.2.4 Asegurar el enfoque centrado en usuario en el equipo DCU.2.5 Planicar el proceso de diseo centrado en usuario DCU.2.6 Gestionar el proceso centrado en usuario DCU.2.7 Abogar por las actividades centradas en usuario DCU.2.8 Proveer soporte para el diseo centrado en usuario DCU.3 Especicar los requerimientos de usuario y de organizacion DCU.3.1 Claricar y documentar las metas del sistema DCU.3.2 Denir los stakeholders DCU.3.3 Evaluar los riesgos para stakeholders DCU.3.4 Denir el sistema DCU.3.5 Generar requerimientos de stakeholders y de la organizacion DCU.3.6 Establecer la calidad en objetivos de uso DCU.4 Entender y especicar el contexto de uso DCU.4.1 Identicar y documentar tareas de usuario DCU.4.2 Identicar y documentar atributos signicativos de usuario DCU.4.3 Identicar y documentar entorno organizacional DCU.4.4 Identicar y documentar el entorno tcnico e DCU.4.5 Identicar y documentar entorno sico DCU.5 Producir solucines de diseo o DCU.5.1 Alocar funciones DCU.5.2 Producir modelo de tareas compuesto DCU.5.3 Explorar el diseo del sistema n DCU.5.4 Desarrollar solucines de diseo o DCU.5.5 Especicar el sistema DCU.5.6 Desarrollar prototipos DCU.5.7 Desarrollar entrenamiento de usuarios DCU.5.8 Desarrollar soporte de usuarios DCU.6 Evaluar el diseo contra los requerimientos DCU.6.1 Especicar y validar el contexto de evaluacion DCU.6.2 Evaluar prototipos tempranos para denir los requerimientos de diseo DCU.6.3 Evaluar prototipos para mejorar el diseo DCU.6.4 Evaluar el sistema para chequear que se satisfacen los requerimientos DCU.6.5 Evaluar el sistema para chequear que se siguieron las practicas requeridas DCU.6.6 Evaluar el sistema en uso ... DCU.7 Introducir y operar el sistema DCU.7.1 Gestionar el cambio DCU.7.2 Determinar el impacto sobre la organizacion y los stakeholders DCU.7.3 Customisacion y diseo local DCU.7.4 Proveer entrenamiento a usuarios DCU.7.5 Dar soporte a usuarios en las actividades planicadas DCU.7.6 Asegurar la conformidad del lugar de trabajo a la legislacin de ergonom o a Evaluado 0,3 Completar Ampliar X X X X X 0,7 0,7 0,3 0,3 0,3 0,3 0,3 0,3 0,7 0,3 0,7 0,3 0,7 0,3 0,7 0,3 0,3 0,3 0,3 0,3 0,7 0,3 0,3 X X X X X X 0,3 0,3 0,3 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Incluir
Tabla 6.2: Atributos a mejorar para dar conformidad a MMU-ISO en Nivel 1 Para generar un proceso que pueda ser congurado para dar cumplimiento a MMUISO en niveles de Capacidad y Madurez 2 y 3, ser necesario que todos los atributos de a esos niveles puedan mostrar evidencia de logro con cobertura amplia. En los cap tulos siguientes presentamos la propuesta de extensin de OpenUP para o alcanzar estos objetivos.
Parte III
Soporte para obtener Capacidad y Madurez en Usabilidad con OpenUP
85
Cap tulo 7
Una extensin de EPL y o OpenUP para conformar al MMU-ISO

7.1. Introduccin o
En el Cap tulo 6 hemos visto que el gap entre OpenUP/Basic y MMU-ISO puede ser caracterizado en tres aspectos: Los procesos DCU 1 (Estrategia de sistemas) y DCU 7 (Implantacin) casi no estn o a cubiertos El proceso DCU 2 (Gestin) tiene una cobertura supercial o En los restantes procesos, que constituyen el ncleo duro de un desarrollo centrado u en usuarios, tienen una cobertura dispar, extendida en varios de sus atributos, pero incompleta. Cuando presentamos el MMU-ISO en el Cap tulo 5 vimos que el Nivel 1 de capacidad consiste en la cobertura de todas las prcticas de base de los siete procesos DCU y que a los Niveles 2 y 3 de Capacidad se alcanzan con la incorporacin de atributos de gestin de o o procesos y gestin de productos de trabajo. Por tanto, para poder obtener un proceso con o base en OpenUP que pueda alcanzar la conformidad MMU-ISO al menos en los Niveles mencionados, ser necesario realizar una tarea en dos etapas: a 1. Para lograr el Nivel 1 de Capacidad en todos los Procesos DCU, deberemos rellenar con Contenido de Mtodos todos los huecos detectados en las prcticas de base. e a 2. Para alcanzar la Capacidad de los Niveles 2 y 3, deberemos incorporar los Contenidos de Procesos que cubran los atributos de gestin de la performance de procesos y o productos sobre las prcticas de base. a
7.1.1.
La creacin de Mtodos para la Biblioteca de Prcticas del o e a EPF
El Mtodo de Autor de Mtodos (MAM) para la EPL [Eclipse 2008b] es una aproxie a e macin a la creacin de mtodos centrada en arquitectura, orientada a la calidad y basada o o e en prcticas. Provee las gu necesarias para generar mtodos dentro de la Biblioteca de a as e Prcticas del EPF (EPL) y documentarlos adecuadamente. a 87
88
Extensin OpenUP/MMU-ISO o
7.1
El MAM est compuesto de varias Orientaciones del tipo Hoja de Ruta y del tipo Gu a a que, a partir de la denominada La autor en la EPL, conducen al ingeniero de procesos a a travs del EPF para generar los cambios, extensiones, conguraciones, etc que sean e necesarias para obtener un proceso de desarrollo adecuado al contexto de un proyecto u organizacin espec o cos. La primera tarea es establecer el entorno de autor adecuado, que implica tanto el a proceso de autor como las herramientas necesarias para ejecutarlo. El propio MAM es a el proceso que utilizaremos en este trabajo. Respecto de las herramientas, emplearemos las versiones publicadas de la EPL, OpenUP/Basic y MMU-ISO (que hemos descripto extensamente en cap tulos anteriores) con su metamodelo y lenguaje de modelado, SPEM 2.0 y UML, respectivamente. Para la implementacin de los procesos resultantes de esta o autor y su distribucin a un equipo de desarrollo nos valdremos del EPF Composer, a o herramienta de software desarrollada por la Fundacin Eclipse para la autor en la EPL o a (esta parte de la tarea constituye el objeto del siguiente cap tulo). Una vez establecido el entorno de autor existen tres reas de concern: la arquitectura a a del Framework de prcticas (el EPF), la autor (o personalizacin) de una prctica y la a a o a autor (o personalizacin) de conguraciones de prcticas. a o a La primera implica tareas tales como agregar un nuevo Slot de Producto de Trabajo, incorporar una nueva disciplina, insertar nuevos elementos en el Framework. etc. Las gu del MAM en este concern nos servirn de referencia en el prximo cap as a o tulo cuando mostremos las extensiones desarrolladas como plugins elaborados con el EPF Composer y su insercin en la arquitectura del EPF. o Para decidir cmo se vern involucradas en este trabajo de autor las otras dos, o a a MAM propone una gu de preguntas que conducen al escenario de trabajo que permite a satisfacer el objetivo planteado. Reproducimos a continuacin la parte de esta gu que o a resulta signicativa para nuestro trabajo (la versin completa se puede consutar en Eclipse o [2008d]). Se quiere agregar un nuevo rol, tarea o producto de trabajo? S Esos elementos reejan una nueva tcnica o aproximacin al . e o trabajo? S Crear una nueva prctica que incluya los nuevos elementos . a y procesos espec cos que los articulen. Seguir Hoja de Ruta: Autor de nueva prctica. a a
Se quiere personalizar un proceso existente agregando elementos de una prctica disponible? a S La conguracin por defecto del proceso ya incluye la prctica . o a de la que se agregan elementos? No. Personalizar los procesos transversales a varias prcticas usa ando los elementos que no estn en la actual conguracin. Seguir a o Hoja de Ruta: Personalizar una conguracin de prcticas exiso a tente. La Autor de una nueva prctica incluye las tareas de denir cmo se integra a a o en el framework, cules son sus elementos y cmo se estructura, tanto como proveer a o descripciones para cada uno de los componentes incluidos. La sugerencia del MAM para la EPL es crear prcticas en forma iterativa e incremental, comenzando por un boceto a que identifque los inputs y outputs y una organizacin general, pasando luego a una o
7.1
Introduccin o
89
estructuracin ms formal, para nalizar con el detalle de todos los componentes de la o a prctica. El cierre del proceso de creacin de una prctica es su publicacin dentro de a o a o EPL. El otro escenario que nos interesa es el de la Personalizacin de una conguo racin de prcticas existente. Una conguracin de prcticas consiste en un conjunto o a o a de prcticas vinculadas pero reconocibles individualmente que aborda una necesidad esa pecica e incluye contenido de soporte para describir la forma en que las prcticas de a ensamblan. OpenUP/Basic es una conguracin que utiliza todas las prcticas de la EPL o a para presentar un proceso liviano y completo, como vimos antes. En general, la customizacin de una conguracin de prcticas involucra la creacin o o a o de nuevas conguraciones que incluyan los elementos deseados de la original ms las a adaptaciones.
7.1.2.
La contribucin de esta Tesis: una Prctica y tres Conguo a raciones de mtodo e
Para cumplir con el objetivo de conseguir instanciaciones de procesos basados en OpenUP que puedan satisfacer los requerimientos del MMU-ISO, utilizando el MAM para la EPL como gu abordamos los dos escenarios descriptos en los prrafos anteriores a, a mediante las siguientes tareas: Agregar nuevos elementos a la EPL. Todos los componentes espec cos del desarrollo centrado en usuario identicados en el MMU-ISO debern ser incorporados en la a EPL. Agregar y modicar los procesos transversales a varias prcticas. En el Nivel 1 de a capacidad del MMU-ISO, para garantizar la convergencia de la arquitectura evolutiva, el diseo evolutivo y el desarrollo centrado en el usuario. En los niveles 2 y 3, n para incluir gestin de procesos y productos de DCU. o El uso de un conjunto alternativo de asignaciones de roles, para pasar la responsabildiad de algunos procesos a los roles que requiere un proceso DCU. Como resultado de estas tareas, nuestra propuesta consiste en el agregado a la EPL de la Prctica: Desarrollo Centrado en el Usuario (DesCU) y la personalizacin de a o la conguracin OpenUP/Basic mediante su extensin para generar tres conguraciones o o nuevas. La nueva Prctica: Desarrollo Centrado en el Usuario, contiene y articula los a elementos de Contenido de Mtodo que componen el ncleo duro y espec e u co de un proceso DCU en l nea con lo establecido por MMU-ISO. Las tres conguraciones, que llamaremos OpenUP/MMU-ISO Nx, implementan los Niveles de Capacidad 1, 2 y 3 de MMU-ISO. El Nivel 1 se podr alcanzar instanciando a un proceso basado en OpenUP/Basic con el agregado de la Prctica DCU y la asignacin a o correcta de los nuevos roles en tareas de otras prcticas. La capacidad en los siguientes a niveles se lograr con extensiones de tareas de gestin y nuevas asignaciones, de las que a o se ofrecen Patrones de Capacidad en las conguraciones propuestas. En lo que resta de esta Tesis describiremos estos nuevos elementos de mtodo (resto e del presente cap tulo) y su implementacin como plugings en el EPF (Cap o tulo 8).
7.1.3.
Trabajos relacionados y antecedentes
Antes de describir en forma detallada el contenido de las contribuciones mencionadas, describimos aspectos pertinentes de algunos de los trabajos relacionados con la incorporacin de elementos de diseo centrado en usuario en el Proceso Unicado (algunos fueron o n
90
7.1
presentados en el Cap tulo 3 que pueden senalarse como antecedentes para la concepcin o de la Prctica DesCU y las conguraciones OpenUP/MMU-ISO. a El plugin: OpenUP/DSDM En el Cap tulo 3 presentamos al framework DSDM como uno de los intentos desde la ingenier de software de incluir actividades de DCU y usabilidad. Cuando la Fundacin a o Eclipse liber OpenUP como la versin open source del Proceso Unicado, el consorcio DSo o DM contribuy con un plugin [DSDM-Consortium 2007] que extiende el rol de Stakeholder o incluido en OpenUP, agregando cuatro roles de negocio y asignndolos a responsabilidades a espec ficas para aspectos claves del proyecto. Los roles son: Sponsor ejecutivo. Representa a los grupos de inters cuyas necesidades deben sate isfacerse con el proyecto. Este rol puede ser desempeado por cualquiera que es n afectado materialmente por el resultado del proyecto. Visionario. Tiene la visin del cambio de negocio que se necesita y es responsable o para iniciar y conducir el proyecto a travs de la entrega de los objetivos del negocio. e Usuario embajador. Habitualmente proviene del rea de negocios afectada y se cona vierte en una parte integral del equipo de desarrollo. Usuario consultor. Este rol tiene el conocimiento directo del trabajo diario que se automatiza con el sistema. Se trata de un potencial usuario nal del sistema en desarrollo. El Pluging OpenUP/DSDM no agrega ningn otro elemento nuevo de mtodo. Los u e nuevos roles son asignados a las Tareas y Productos existentes. La intencin es promover o un abordaje expl cito de colaboracin entre las comunidades de negocios y tcnica, ambas o e responsables del desarrollo de software. Se sostiene que es la experiencia de los practicantes de DSDM y la comunidad Agile en general la que mejora signicativamente el potencial para un proyecto exitoso[DSDM-Consortium 2007]. El plugin: Icon Web enabled UCD (WEUCD Consiste en una mejora al Proceso Unicado para el desarrollo centrado en usuario de proyectos de sitios web. Ha sido liberada como plugin para el EPF para poder incorporarlo en una conguracin de OpenUP [ATG 2010], aunque tambin puede ser utilizado con el o e Rational Method Composer de IBM. Basado en el ciclo de vida del Proceso Unicado, con foco en las disciplinas Requerimientos, Anlisis y Diseo, Implementacion y Test, agrega varios elementos al mtodo: 11 a n e nuevos roles, 12 nuevos productos de trabajo, 6 nuevas Actividades que agrupan a tareas nuevas y existentes en UP. La gura 7.1 muestra el proceso de despliegue bsico del plugin a WEUCD. Dado el foco en el desarrollo de aplicaciones web, los roles agregados se vinculan con el manejo de contenidos (Content Editor, Content Manager y Content Organizer) y la creacin conceptual del sitio (Creative Concept Director, Information architect). Pero o tambin se agregan otros propios de un proceso que tiene en cuenta la usabilidad y la e interaccin de usuarios, como el diseo de pantallas y de navegacin (Graphic Designer, o n o User Interface Prototyper, Interaction designer), las evaluacioones de usabilidad (Usability Evaluator, Usability Specialist) y la investigacin de mercado (User Researcher). o Los productos que se incorporan y las tareas que los manejan pueden agruparse en manejo de conceptos y especicaciones (Content Inventory, Information Architecture, User Experience Concept, Interaction Specication, User Research Report, Writing Style
7.1
Introduccin o
91
Figura 7.1: Patrn de entrega de plugin WEUCD, de [ATG 2010] o
Guide), prototipado y diseo de interfaces y navegacin (Site Map, User Interface Pron o totype, Wireframes) y evaluaciones de usabilidad (Usability Benchmarks, Usability Test Plan, Usability Test Results). Aunque el proceso de despliegue presenta el ciclo completo de requerimientos, diseo, n construccion y prueba desde el punto de vista de usuario, el plugin no muestra ni sugiere la forma de incorporar las actividades agregadas en el ciclo de vida del Proceso Unicado. El plugin de la experiencia de usuario para RUP En el Cap tulo 3 hablamos de RUP y la extensin publicada por IBM como Plugin de o la Experiencia del Usuario [IBM 2005b]. El plugin presenta el abordaje de la UX en tres a reas: En la arquitectura, agrega al Documento de Arquitectura una vista de la experiencia de usuario. Esta vista es opcional y contiene los elementos del Modelo de la UX que tienen impacto en la arquitectura del sistema. En la capa de presentacin, incorpora todos los elementos de mtodo y proceso o e vinculados con el diseo y desarrollo de la interfaz de usuario. Toma preemimencia n en esta vista el Modelo de la UX y, en consecuencia, los roles encargados de su realizacin (el Diseador de Interfaz de Usuario) y las tareas de las que es output o n (Disear la Interfaz de Usuario) o para las que es input (Analizar los Casos de Uso, n Prototipar la IU, Revisar el diseo, Identicar elementos de diseo). El plugin UXn n RUP establece que el Modelo de UX se represente como un modelo UML con el estereotipo ((user-experience model)). En la capa de negocio, se intenta que exista consistencia entre el Modelo de la UX y los elementos del mtodo que soportan la representacin de los aspectos del negocio. e o
92
7.1
La disciplina Usabilidad de Gransson o Bengt Gransson ha propuesto la extensin de RUP con la integracin de una disciplina o o o de usabilidad [Goransson et al. 2003]. El trabajo identica obstculos en RUP para la a aplicacin de diseo centrado en usuario (la centralidad de la arquitectura, el predominio o n de los casos de uso, la concentracin de actividades de usabilidad slo en la disciplina o o de Requerimientos y en la fase de Elaboracin). Para sortear estos obstculos propone o a crear una nueva disciplina, el Diseo de Usabilidad que, si bien tiene un mayor nivel de n actividad en las fases de Inicio y Elaboracin, aporta al ciclo de vida en todas las fases. o La disciplina de Diseo de Usabilidad introduce cinco nuevos roles y un ujo de tareas n con diez actividades. Los roles introducidos por DU son: Diseador de usabilidad, como el campen y lider de usabilidad n o Especialista de estudios de campo, que planica y realiza estudios de usuarios y analiza los resultados. Diseador de interaccion, que se ocupa de la creacion y renamiento de todo el n esquema de interaccion de usuario. Diseador grco, responsable de dar forma visual a la interfaz de usuario. n a Especialista en evaluaciones de usabilidad, responsable de planicar, preparar, ejecutar y reportar las pruebas de usabilidad. La gura 7.2 muestra el ujo bsico de actividades para la disciplina Diseo de Usa n abilidad. Se puede advertir que el ujo incorpora tres actividades propias slo de las fases o Inicio y Elaboracin tales como Crear/Modicar el Plan de Diseo de Usabilidad, Realizar o n analisis de competidores y Conducir estudios de usuario. El resto de las actividades, que se describen brevemente a continuacin se pueden efectuar en cualquiera de las fases del o ciclo de vida del UP. Lamentablemente, en las publicaciones de Grensson y sus colegas, o no indican referencias exhaustivas sobre la integracin de este ujo en los Patrones de o Entrega del Proceso Unicado en general. Planicar el Diseo de Usabilidad, al comienzo del proyecto y renarlo antes de cada n iteracin. o Realizar estudios de usuario, para comprender a los potenciales usuarios, sus necesidades y el contexto de uso. Estudiar productos competidores, para comprender el estado del arte en el dominio del problema. Diseo conceptual, se plantea como la estructura general de la interfaz de usuario, n apoyado por escenarios. Diseo de interaccion, que consiste en desarrollar e ilustrar la forma en que el usuario n realizar la interaccin con el sistema, navegacin, uso de funcionalidad,etc. a o o Diseo detallado, con el renamiento en detalle de las partes individuales de la n interfaz de usuario. Desarrollar asistencia de usuario, focaliza en desarrollar material y actividades para dar soporte al usuario en el uso del sistema. Monitorear el trabajo de usabilidad, que focaliza en mantener el control sobre las decisiones de usabilidad que se tomen .al vuelo.en la fase de Construccin, cuando o habitualmente ya todas las decisiones de diseo se han tomado. n
7.2
Prctica: DesCU - Desarrollo Centrado en el Usuario a
93
Figura 7.2: Flujo de actividades de Diseo de Usabilidad, segn [Goransson et al. 2003] n u Realizar evaluaciones de usabilidad, que consiste en probar el sistema (en su etapa de prototipos iniciales o en sus versiones para liberar) contra los objetivos y metas de usabilidad planteadas en el plan inicial.
7.2.
La prctica que proponemos incorporar a la EPL articula los elementos metodolgicos a o necesarios para constituir un proceso de desarrollo de sistemas basados en software que involucre activamente a todas las partes afectadas por el sistema nal, particularmente a los usuarios. A continuacin listamos los elementos de contenido de mtodo que son articulados o e por la prctica que llamamos DesCU o Desarrollo Centrado en el Usuario. Este a listado slo pretende ser ilustrativo de la diversidad de aspectos que se ponen en juego y o la magnitud de esfuerzo que puede demandar la implementacin de la prctica. Como se o a ver ms adelante en las conguraciones OpenUP/MMU-ISO cada proyecto podr requerir a a a la implementacin completa o parcial de la Prctica o incluso su extensin. o a o Roles Stakeholder: Patrocinador Stakeholder: L der tcnico del dominio e Stakeholder: Representante de Usuarios Stakeholder: Usuario nal Analista: Especialista en Experiencia de Usuario Desarrollador: Diseador de Experiencia de Usuario n
94
7.2
Tester: Tester de Experiencia de Usuario
Productos de trabajo Tareas Adaptar el proceso de Desarrollo Centrado en Usuario Establecer objetivos de la Experiencia de Usuario Entender y especicar el contexto de uso Disear la Experiencia de Usuario n Disear componentes de interaccin n o Revisar el diseo para la experiencia de usuario n Preparar pruebas de usabilidad Ejecutar pruebas de usabilidad Producir material de entrenamiento y soporte al usuario Proveer entrenamiento y soporte al usuario Modelo de usuario Modelo de tareas Meta de usabilidad Concepto de Experiencia de Usuario Prototipo de Experiencia de Usuario Storyboard de Experiencia de Usuario Mapa de navegacin o Documento de usuario y entrenamiento
Orientaciones Deniciones de procesos DCU Modelo ISO de Madurez en Usabilidad
7.2.1.
Roles
OpenUP/Basic, como conguracin de las prcticas base de la EPL ofrece tres denio a ciones genricas que podr ser asignadas a procesos DCU: Stakeholder, Analista y Dee an sarrollador. En la presentacin del MMU-ISO (Cap o tulo 4) y en el Assessment de OpenUP (Cap tulo 6) vimos con claridad que las diferentes prcticas que componen los procesos DCU a requieren de un conjunto de habilidades espec cas, en el caso de los miembros tcnicos e del equipo, y de conocimientos del dominio y capacidades de decisin apropiadas, en lo o que hace a los Stakeholders involucrados. Por esta razn, consideramos que las deniciones genricas de roles no siempre aseguran o e que luego se puedan identicar claramente los perles necesarios y, sobre todo, encontrar profesionales que posean el suciente conjunto de habilidades necesarias para satisfacer los requerimientos del proceso.
7.2
95
Hemos visto que algunas extensiones de UP y OpenUP ya han identicado esta situacin proponiendo diversidad de roles a incluir para asegurar la consideracin de la o o experiencia de usuario en el desarrollo. OpenUP/DDSM propone la inclusin de cuatro o roles nuevos, dos con responsabilidades de tareas y otros dos de consulta y apoyo [DSDMConsortium 2007]. El plugin denominado Web-enabled UCD (DCU para la web) [ATG 2010] propone once nuevos roles, sin embargo extraamente no hay ningun rol nuevo de n usuarios o clientes en este plugin. El plugin de Experiencia de Usuario para RUP [IBM 2005b] propone la inclusin de un Diseador de Interfaz de Usuario diferenciado de los o n diseadores de software. n Para nuestra propuesta, tomamos los roles habitualmente denidos en la literatura sobre Usabilidad y Diseo de interaccin adems de los casos mencionados antes, pero n o a priorizamos el compromiso por mantener OpenUP como un conjunto de prcticas que a permitan congurar procesos giles y de bajo nivel de burocracia y ceremonia. Hemos a identicado la necesidad de contar con seis roles que no estn incluidos en OpenUP: a cuatro son Actores de Negocio (pueden denirse como extensiones de Stakeholder), los otros dos corresponden a extensiones de roles de Analista y Desarrollador. Actor de negocio Stakeholder: Patrocinador Stakeholder: L der tcnico del dominio e Stakeholder: Representante de usuarios Stakeholder: Usuario nal Analista Analista: Especialista en Experiencia de usuario Desarrollador Desarrollador: Diseador de la Experiencia de usuario n Tester Tester: Tester de la Experiencia de usuario Con estos nuevos roles buscamos asegurar por un lado que se identica claramente el tipo de participacin que los stakeholders deben tener en un proceso DCU y por otro que o existe una adecuada disponibilidad de las habilidades y conocimentos necesarios para la viabilidad y factibilidad de las prcticas bsicas que prescribe MMU-ISO. a a A continuacin presentamos en conjunto las Deniciones de los Roles y sus Asignao ciones en el marco de la Prctica DesCU1 . a Stakeholder: Patrocinador Este rol es el representante del grupo de interesados en que el desarrollo se lleve adelante con xito. Es quien impulsa su realizacin internamente en la organizacin afectada. e o o Corresponde en parte con el rol denominado Sponsor en OpenUP/DSDM [DSDMConsortium 2007], aunque en la propuesta OpenUP/MMU-ISO este rol opera en conjunto con el Gerente del Proyecto. Deber formar parte de un grupo o comit de avance que a e vele por el buen desarrollo del proyecto, adoptando todas las decisiones necesarias sobre recursos y riesgos.
1 Dado que se trata de roles espec cos para la Prctica DesCU, haremos uso de la opcin que brinda a o EPL para evitar LA asignacin diferida. La asignacin diferida es el mecanismo que propone EPL para o o facilitar el reuso de roles en otras prcticas (ver Concept: Delayed assignment en [Eclipse 2008b]) a
96
7.2
Este rol ser desempeado por alguien con cargo alto en el negocio, ya que sus funciones a n de cara al proyecto muchas veces consisten en resolver temas que implican abrir puertas y tomar decisiones nancieras. Es un rol crucial para asegurar y permitir el avance del proyecto sin interrupciones, evitando los obstculos que suelen imponer las burocracias o a niveles pol ticos.
Figura 7.3: Asignaciones del Rol Patrocinador Las habilidades de este rol comprenden la capacidad de comprometer fondos y recursos apropiados, tener pensamiento cr tico, capacidad de decisin, conciencia de la situacin o o pol tica y conocimiento de negocio. A lo largo de todo el proyecto, las responsabilidades del Patrocinador consisten en: Monitorear la governancia del proyecto Responder a los temas que puedan exceder en las capacidades de decisin del equipo o del proyecto Revisar y aprobar la Lista de Riesgos Revisar y acordar el Plan de Proyecto Comprometer los recursos necesarios para la siguiente fase del proyecto. Adems, debe hacerse cargo de las siguientes responsabilidades en algunos momentos a espec cos del proceso: En Fase de Inicio: Revisar y aceptar el Plan de Proyecto o detener el proyecto si no hay una solucin viable o En Fase de Elaboracin: Aprobar el Caso de Negocio para el proyecto se extienda o ms all de la fase de Elaboracin para obtener los recursos necesarios. a a o En Fase de Transicin: Aprobar el sistema entregado y Determinar si es necesario o un nuevo incremento del sistema o se detiene el proyecto. Para cumplir estas responsabilidades, en lo referido a la Experiencia del Usuario participa en forma adicional de la Tarea Adaptar el proceso de Desarrollo Centrado en Usuario. Stakeholder: L der tcnico de dominio e El Lider tcnico de dominio es la persona responsable de conseguir que el proyecto se e inicie focalizado en las metas del negocio y se mantenga alineado con ellas. Permanece involucrado a lo largo de todo el proceso de diseo y desarrollo para asegurar que se n alcanzan los objetivos originales. Se convierte en el nexo con los altos niveles de direccin o cuando surgen aspectos de negocio que requieren de decisiones sobre metas del proyecto, recursos nancieros, etc. Debe asegurar que el proyecto transcurra en senderos de excelencia desde el punto de vista del negocio (el Gerente del Proyecto har lo propio desde el punto de vista de la a ingenier del software). Su vinculacin con el Patrocinador en estos aspectos es de vital a o importancia. Sus principales responsabilidades son:
7.2
97
Figura 7.4: Asignaciones del Rol L der Tcnico de Dominio e Facilitar la implementacin prctica y operativa del contenido de la Visin o a o Aportar un punto de vista comprehensivo sobre el proceso de negocio completo Participar y contribuir a las sesiones claves de bsqueda de requerimientos u Participar y contribuir en las sesiones claves de diseo n Resolver conictos entre las reas de negocio a Asegurar la disponibilidad de recursos de usuario Monitorear el progreso en relacin con la Visin original o o Aportar compromiso y disponibilidad durante todo el ciclo de desarrollo Para cumplir estas responsabilidades, bsicamente participa en forma adicional de las a siguientes Tareas: Adaptar el proceso de Desarrollo Centrado en Usuario Entender y especicar el contexto de uso Establecer objetivos de la experiencia del usuario Disear y producir material de entrenamiento y soporte al usuario n Guiar y dar soporte al usuario Stakeholder: Representante de Usuarios El Representante de usuarios es parte fundamental del equipo de trabajo, conoce el dominio y la tarea diaria, compartiendo con el equipo ideas y generando requerimientos al tiempo que mantiene a otros usuarios (fundamentalmente usuarios nales) informados del estado de situacin. o Quien desempee este rol debe tener adems de inters y deseos de participar, algn n a e u nivel de autoridad, responsabilidad y conocimiento que asegure que los requerimientos e ideas obtenidas sobre el dominio resultan correctas. Por ejemplo, en los casos de sistemas
98
7.2
de gestin este rol lo desempean Jefes de Sector o de Area Usuaria. Aunque no se trata o n necesariamente de que sea alguien con poder formal, sino con habilitacin durante el o proyecto.
Figura 7.5: Asignaciones del Rol Representante de Usuarios Es importante que la persona asignada al rol tenga el tiempo y los recursos necesarios para participar en el proyecto activamente. Entre sus responsabilidades se pueden mencionar: Proveer input de requerimentos de negocio y decisiones de diseo n Comunicar con otros usuarios y obtener su acuerdo Proveer input en las sesiones de prototipado Revisar documentacin o Revisar y aceptar el software entregado Proveer documentacin de usuario o Asegurar entrenamiento adecuado Organizar y controla el test de usuario Para cubrir estas responsabilidades, debe participar en forma primaria o adicional de: Entender y especicar el contexto de uso Especicar metas y requerimientos de UX Disear y producir material de soporte n Preparar pruebas de usabilidad, Ejecutar pruebas de usabilidad Stakeholder: Usuario nal Es el que operar diariamente con el sistema a construir. Posee un conocimiento esena cialmente prctico del tema o rea de negocio y habilidad para comunicarlo. a a Habitualmente no est integrado en los equipos de proyecto, sino que participa en a algunos procesos de revisin y pruebas de usabilidad. Sin embargo es imprescindible su o participacin en el ciclo de vida del proyecto, ya que es la persona que se ver directamente o a
7.2
99
afectada en su quehacer cotidiano con el sistema y quien puede aportar detalles de la tarea que muchas veces quedan escondidos o relegados en relevamientos de requerimientos. Todas las tareas que requieran la voz del usuario nal (elaboracin de modelos mentales o de usuario, pruebas de usabilidad, aceptacin de usuarios, etc) deber ser conguradas o an con la participacin de este rol. o Su nexo natural con los miembros tcnicos del equipo de proyecto es el Representante e de usuarios.
Figura 7.6: Rol de Usuario nal Sus responsabilidades consisten en: Proveer el conocimiento de la tarea diaria involucrada en el sistema. Participar en las actividades de prototipado y revisin, especialmente en lo referido o a los aspectos prcticos de las tareas que el sistema intenta automatizar. a Aprobar los diseos prototipados desde el punto de vista de su uso prctico. n a Colaborar en las pruebas de usabilidad y aceptacin. o Para cubrir estas responsabilidades, debe participar como part cipe secundario de: Especicar requerimientos de UX Ejecutar pruebas de usabilidad Proveer entrenamiento y soporte al usuario Analista: Especialista en UX Este Analista participa activamente como principal responsable de la extraccin, denio cin y especicacin de requerimientos de interaccin y experiencia del usuario. Adicionalo o o mente colabora en las mismas actiivdades que el resto de los analistas. Este rol debe funcionar como el campen y responsable general de la UX. En algunos o contextos de desarrollo, por ejemplo para las aplicaciones web, este rol se asocia con el arquitecto de la informacin. Por una parte, realiza tareas de Analista para identicar o y especicar requerimientos para la UX del sistema, por otra, colabora en el planteo del
100
7.2
Figura 7.7: Rol de Especialista en Experiencia de Usuario
diseo de la interaccin. En cualquier caso, debe ser el encargado de planicar y gestionar n o las actividades relacionadas con la UX y ejecutar algunas. Es de esperar que los recursos cumpliendo este rol dispongan de un buen background tanto en HCI y procesos DCU como en los recursos tecnolgicos adecuados. La experiencia o en la utilizacin de diferentes mtodos y tcnicas de usabilidad les permitir categorizar o e e a usuarios y entender sus necesidades. Debe ser capaz tambin de planicar, realizar y e analizar estudios de usuarios. Ser responsable de: a Elicitar y especicar los requerimientos de UX Categorizar usuarios, entender sus necesidades y especicar el contexto de uso Proponer y colaborar en la denicin de objetivos de UX o Para cubrir sus responsabilidades, el Especialista de UX participar de las siguientes a tareas: Establecer objetivos de la UX Entender y especicar el Contexto de Uso Disear la UX n Revisar el diseo de la UX n Preparar pruebas de usabilidad Disear y producir material de soporte y entrenamiento al usuario n
7.2
101
Desarrollador: Dise ador de UX n Es necesario incorporar una especializacin del Rol Desarrollador: el Diseador de o n Experiencia de Usuario, que se encargar de plasmar los requerimientos de UX en el a sistema en desarrollo. Este rol no es responsable de la implementacin de la IU, sino que su trabajo se orienta o hacia el diseo y organizacin visual de la IU. Debe participar activamente en la captura n o de requerimientos que impacten en la IU, construir los prototipos necesarios tanto para la elicitacin de requerimientos como para la presentacin de ideas de diseo, involucrar a o o n los roles Representante de usuario, Usuario nal en las revisiones de usabilidad y pruebas de aceptacin, revisar las implementaciones llevadas adelante por los desarrolladores. o
Figura 7.8: Asignaciones del Rol Diseador de Experiencia de Usuario n Habitualmente, este rol es desempeado por profesionales creativos con background en n artes visuales, ms que en temas de negocio o tecnolog Entre las razones que justican a a. la asignacin de este rol (y no asignar el trabajo de IU simplemente a los desarrolladores o ms anes a aspectos visuales) se encuentra la necesidad de disponer de un conjunto de a habilidades orientadas a la usabilidad que puedan ser incrementadas y optimizadas en el proyecto, lo que obliga entre otras cosas a que quien/es estn a cargo de la UX se vean ms e a inuidos por consideraciones vinculadas a la experiencia del usuario que a los aspectos de implementacin. o El rol Diseador de la UX ser responsable de: n a Realizar propuestas de diseo de todos los elementos del sistema que proveen la n experiencia del usuario: mapa de navegacin, interfaces de usuario, etc. asegurando o que satisfacen los requerimientos de calidad de uso especicados. Realizar los prototipos de elementos de UX para facilitar las pruebas de usabilidad y aceptacin con usuarios o Participa elo, participa activamente de: Disear la experiencia del usuario n Revisar el diseo de la experiencia del usuario n Disear componentes de interaccin n o
102
7.2
Tester: Tester de Experiencia de Usuario (TUX) El Tester de UX es el responsable de evaluar la usabilidad del sistema, sea mediante pruebas con usuarios o mediante inspecciones. Las pruebas de usabilidad se basan en la exposicin del sistema ante muestras representativas de los usuarios. Por otra parte, o un experto en usabilidad puede efectuar evaluaciones heur sticas sobre la base de criterios aceptados en la comunidad de usabilidad, sin contar neceasriamente con inputs de usuarios. La tarea del Tester de UX consistir por tanto en determinar los mtodos de evaluacin a e o apropiados, disear las pruebas, recluatar participantes, conducir las evaluaciones, analizar n los datos y presentar los reportes que muestran los resultados y recomendaciones.
Figura 7.9: Asignaciones del Rol Tester de Experiencia de Usuario La persona que cumpla el rol de Tester de UX debe estar entrenado en los mtodos para e realizar pruebas de usabilidad e inspecciones. Deber poseer hablidades en la evaluacin a o de software sobre la base de criterios de usabilidad y en el diseo, ejecucin y evaluacin n o o de pruebas empricas. Es probable que la misma persona pueda cubrir los roles de Tester de UX y Especialista en UX, pero es importante notar que el enfoque de la tarea es diferente. En el caso del Tester buscar encontrar los defectos de usabilidad del software ya construido (aunque a sea en estado de prototipo), mientras el Especialista deber encontrar y especicar los a requerimientos de la aplicacin a ser construida. o Ser responsable primario de las tareas Revisar el diseo de la UX, Preparar pruebas a n de usabilidad y Ejecutar pruebas de usabilidad.
7.2.2.
Productos de trabajo
Con el Assessment de OpenUP descripto en el Cap tulo 6 identicamos las carencias de este mtodo, entre otras cosas, en trminos de Productos de Trabajo segn el MMUe e u ISO. Para cubrir esa carencia slo ser necesario incluir los artefactos mencionados en el o a MMU-ISO que no guran en OpenUP (una lista de estos puede verse en la Tabla 7.1). Sin embargo, hemos planteado la conveniencia de mantener el bajo nivel de burocracia y ceremonial que propugna OpenUP, lo que nos obliga a incoporar slo aquellos productos o que no pueden ser cubiertos por los ya existentes en la conguracin bsica del mtodo, o a e ya sea mediante extensiones o adaptaciones ad-hoc.
7.2
Procesos DCU
103
PT a incluir en OpenUP DCU.1 Asegurar el contenido DCU en la estrategia de sistemas DCU.1.1 Representar los stakeholders. DCU.1.2 Analizar el mercado Usability benchmarking Anlisis de mercado - Anlisis de a a DCU.1.3 Denir y planicar la estratePlan de UX tendencias gia de sistemas DCU.1.4 Reunir respuesta de mercado DCU.1.5 Analizar tendencias de usuarios DCU.2 Planicar y Gestionar el proceso DCU DCU.2.1 Consultar a los stakeholders Planes de integracin HCI en otras o DCU.2.2 Planicar la participacin de actividades de desarrollo - Planes de o usuarios comunicacin entre desarrollo y hci o DCU.2.3 Seleccionar mtodos y tcni- Hitos de diseo y desarrollo de hci e e n cas centradas en usuarios Pol tica de hci - Reportes de auditor a DCU.2.4 Asegurar el enfoque centrado en usuario en el equipo DCU.2.5 Planicar el proceso de diseo centrado en usuario DCU.2.6 Gestionar el proceso centrado en usuario DCU.2.7 Abogar por las actividades centradas en usuario DCU.2.8 Proveer soporte para el diseo centrado en usuario DCU.3 Especicar los requerimientos de usuario y de organizacin o DCU.3.1 Claricar y documentar las Rango y relevancia de usuarios Requerimiento de usuario metas del sistema Especicacin detallada de reqs de o DCU.3.2 Denir los stakeholders Modelo de anlisis a usuario y stakeholder - Especicac on DCU.3.3 Evaluar los riesgos para stake- de reqs de organizacin - Metas de o holders usabilidad espec cas y medibles DCU.3.4 Denir el sistema Lista de legislacin y normas o DCU.3.5 Generar requerimientos de aplicables - Fuentes de reqs usability benchmarking stakeholders y de la organizacin o DCU.3.6 Establecer la calidad en objetivos de uso DCU.4 Entender y especicar el contexto de uso DCU.4.1 Identicar y documentar tar- Especicacin de rango de usuarios o Modelo de tareas eas de usuario objetivo, de tareas y entorno o DCU.4.2 Identicar y documentar Informacin de usuario y de Modelo de anlisis a stakeholder - Informacin de tareas o atributos signicativos de usuario a DCU.4.3 Identicar y documentar en- Anlisis de organizacion Reporte de investigacin o torno organizacional de usuarios DCU.4.4 Identicar y documentar el entorno tcnico e DCU.4.5 Identicar y documentar entorno f sico DCU.5 Producir soluciones de dise o n DCU.5.1 Alocar funciones Especicacin de interaccin de o o DCU.5.2 Producir modelo de tareas usuario - Detalle de dilogos- Look a Prototipo compuesto and feel - Layout y detalles de UI DCU.5.3 Explorar el diseo del sistema Modelos de tares - Prototipos n Storyboard DCU.5.4 Desarrollar solucines de Evidencia de revisin de acuerdo con o Mapa de navegacin o o resultados de evaluaciones - Lista de diseo n normas usadas y cmo se aplicaron o DCU.5.5 Especicar el sistema DCU.5.6 Desarrollar prototipos Rational DCU.5.7 Desarrollar entrenamiento de Documentacin o de usuarios usuario y mantenimiento DCU.5.8 Desarrollar soporte de usuarDocumentacin o de ios usuario y mantenimiento DCU.6 Evaluar el dise o contra los requerimientos n DCU.6.1 Especicar y validar el contex- Contexto de evaluacin - Desripcin de o o to de evaluacin o sistema testeado y estado - Eleccin de o DCU.6.2 Evaluar prototipos tempra- mtodos y datos para testing e Prototipo nos para denir los requerimientos de Defectos de usabilidad y ergonom a diseo n Registro audiovisual de pruebas - Logs DCU.6.3 Evaluar prototipos para mejo- de observacin de usuario o Storyboard rar el diseo n DCU.6.4 Evaluar el sistema para Mapa de navegacin o chequear que se satisfacen los requerimientos DCU.6.5 Evaluar el sistema para Test de UX chequear que se siguieron las practicas requeridas DCU.6.6 Evaluar el sistema en uso Plan de test de UX DCU.7 Introducir y operar el sistema DCU.7.1 Gestionar el cambio Plan de implantacin - Estructura o DCU.7.2 Determinar el impacto sobre afectada de la organizacin o Test de aceptacin o la organizacin y los stakeholders o Instructivos de trabajo - Plan de DCU.7.3 Customisacin y diseo local o n entrenamiento - Material de Documentacin o de entrenamiento - Monitoreo de uso usuario y mantenimiento DCU.7.4 Proveer entrenamiento a Reportes de impacto usuarios Recomendaciones de mejoras para DCU.7.5 Dar soporte a usuarios en las futuros desarrollo actividades planicadas DCU.7.6 Asegurar la conformidad del lugar de trabajo a la legislacin de ero gonom a
PT de MMU-ISO
PT de OpenUP a extender
Plan de proyecto Plan de iteracin o
Visin o Modelo casos de uso
Modelo casos de uso
Requerimiento de apoyo
Cuaderno arquitectura
Tabla 7.1: Productos de Trabajo a incorporar
104
7.2
El primer elemento que debe ser incluido expl citamente es central en cualquier proceso iterativo, particularmente uno centrado en usuarios: el Prototipo de Experiencia de Usuario en cualquiera de sus versiones, que facilita la intervencin activa de los usuaro ios en el diseo y la evaluacin del sistema [Sharp et al. 2007],[Gulliksen et al. 2003]. n o Tambin incluimos otros dos artefactos que tendrn una fuerte relacin con los prototie a o pos: el Storyboard de UX y el Mapa de Navegacin. El Storyboard permitir analizar la o a versin dinmica de una parte del prototipo de UX del sistema, mientras que el Mapa o a de navegacin dejar claramente estable la relacin entre todos los Storyboards. En esta o a o parte de la seleccin de productos de trabajo puede reconocerse una inuencia imporo tante del Plugin RUP para la UX. Sin embargo, vale destacar que haremos foco en el uso de estas herramientas como lugar compartido de elaboracin entre los roles de analista, o desarrollador y las diferentes versiones de usuarios. La lista completa de las nuevas deniciones de productos de trabajo que incluimos en la Prctica DesCU es la siguiente: a Modelo de usuario Meta de usabilidad Modelo de Tareas Concepto de la Experiencia de Usuario Prototipo de Experiencia de Usuario Storyboard de Experiencia de usuario Mapa de navegacin o Documento de usuario y entrenamiento A continuacin mostramos las deniciones de estos productos utilizando una estructura o basada en la sugerida en la Orientacin: Detallando una Tarea de la versin 1.5.0.1 de o o OpenUP [Eclipse 2008c]: Propsito: porqu hay que incluir este producto? Cul es su meta en el proceso? o e a Descripcin y relaciones: en qu consiste?, cules roles se vinculan con l (quin es o e a e e responsable de realizarlo, quin puede modicarlo, quienes colaboran), de qu tareas e e es input y de cules es output? a Ejemplos: incluir muestras completas o parciales que ejempliquen el producto. Personalizacin posible: detallar las posibilidades de adaptar el proceso para tener o o no el Producto y cmo adaptarlo al contexto espec o co. Enumerar las posibles razones para no incluirlo y el impacto de esa decisin. Diferentes formas de repreo sentacin que el Producto permite. o Otra informacin: puede consistir en Orientaciones o Gu para brindar detalles o as sobre la realizacin del producto, Conceptos involucrados, etc. o El orden de presentacin est relacionado con una secuencia posiblede su aparicin o a o a lo largo del ciclo de vida de un proceso t pico que tal como sugiere ISO 13407 segn u ya hemos visto avanza en iteraciones de valor creciente por la identicacin del contexto o de uso, la especicacin de los requerimientos de usuario, las propuestas de diseo y su o n evaluacin. o
7.2 Modelo de usuario Propsito o
105
Para poder optimizar el diseo de la interaccin y la experiencia del usuario es necesario n o conocer y especicar las caracter sticas relevantes de las personas que utilizarn el produca to o sistema en desarrollo. Una interaccin que es apropiada para el usuario infrecuente o o casual que necesita interfaces fciles de aprender y de recordar, puede resultar desmotia vadora y hasta improductiva para un usuario experto, que demandar interfaces altamente a ecientes, poderosas y exibles. Como lo plantea MMU-ISO es necesario identicar y documentar atributos del usuario como conocimientos previos, capacidades, experiencia, etc. que exceden la denicin de del Actor en un Caso de Uso. o Descripcin y relaciones o Descripcin Contiene la coleccin de atributos para un usuario t o o pico. Un sistema o producto puede necesitar la especicacin de ms de un modelo o perl de usuario. o a Los atributos que pueden resultar relevantes de un usuario son sus habilidades y destrezas, capacidades y limitaciones f sicas y mentales, experiencia en la tarea, frecuencia de uso prevista, formacin o educacin previa, nacionalidad, identidad o o cultural, etc. Para realizar un Perl de usuario se pueden utilizar diferentes tcnicas. En todos los e casos ser importante priorizar aquellos mtodos y tcnicas que permitan comprena e e der y especicar el mejor conocimiento posible de los usuarios futuros del sistema o producto en desarrollo. En [Hackos and Redish 1998] se presenta el mtodo para construir Perles de e usuario. Utilizan tanto un formato basado en listas como uno ms personalizado que a incluye naracciones e ilustraciones. La construccin de un Perl de Usuario segn o u estos autores sigue tres pasos: reunir informacin relevante, comprender y categoo rizar los tipos de usuarios, construir los perles. Para la recoleccin de informacin o o se utilizan tcnicas etnogrcas, entrevistas, cuestionarios, etc. Las caracter e a sticas a incluir en los perles incluyen: demogrcas (edad, gnero, nivel socio econmico), a e o experiencia en la tarea, educacin, experiencia con computadoras, conocimiento de o dominio, etc. En la Figura 7.10 se muestra un ejemplo de Perl generado con esta tcnica. e La tcnica denominada Personajes[Cooper 2004, Pruitt and Adlin 2006] consiste e en elaborar una descripcin rica de usuarios t o picos del sistema en desarrollo. No describen gente real, sino que son sintetizadas de usuarios reales involucrados en ejercicios de recoleccin de datos. Los personajes se describen con rigor y detalle y o quedan denidas por un conjunto de metas. El mtodo asume que basar la descripe cin en el cargo o trabajo no es apropiado, ya que personas con roles o cargos muy o diferentes pueden tener las mismas metas para el uso de un producto o sistema. Adems de las metas, el Personaje incluye la descripcin de habilidades, actitudes, a o tareas y entorno del usuario representado. Cada Personaje tiene un nombre, una foto y algunos detalles personales. Ver las Figuras 7.11 y 7.12. Los Roles de Usuario de [Constantine and Lockwood 1999] son parientes cercanos de los Personajes y los Actores de los Casos de Uso. Un Rol de Usuario no intenta representar una persona real sino que modela en forma abstracta una relacin eno tre un usuario y el sistema. Contiene el conjunto de necesidades, comportamientos y expectativas de un usuario. En su forma ms compacta se dene por tres Cs: a Contexto (las responsabilidades que el rol asume en el contexto dentro del cual se desempea), Caracter n sticas (patrones de interaccin, comportamientos y actitudes o
106
7.2
que se esperan del rol) y Criterios (objetivos de diseo relacionados con el soporte n efectivo del rol). Constantine y Lockwood indican que los roles, actores y personajes estn fuertemente interrelacionados y promueven la construccin de los tres. Segn a o u estos autores, un sistema tendr varios actores; para cada actor se podrn encontrar a a uno o ms roles; para algunos roles clave ser conveniente crear personajes detallaa a dos. La Figura 7.13 muestra una hoja de control con los criterios a seleccionar para las tres Cs. Slot que completa [Especicacin tcnica] o e Rol responsable Especialista de UX Roles que pueden modicarlo Diseador de UX, Analista n Es input para las tareas Entender y especicar el contexto de uso, Disear la experin encia de usuario, Revisar el diseo de la experiencia de usuario, Preparar pruebas n de usabilidad, Es output de las tareas Especicar requerimientos y objetivos de experiencia de usuario, entender y especicar el contexto de uso Ejemplo Las Figuras 7.10, 7.11, 7.12 y 7.13 muestran algunos ejemplos las tcnicas indicadas e para la construccin del Perl de Usuario. o
Figura 7.10: Perl de Usuario segn Hackos para un agente de viajes u
Meta de usabilidad Propsito o Establecer metas de usabilidad persigue dos propsitos. En primer lugar, un conjunto o articulado de metas de usabilidad ayuda a los diseadores a focalizar los esfuerzos durante n el proceso con un objetivo claro y algun tipo de parmetro contra el cual evaluar sus logros. a Si los diseadores y usuarios acuerdan que la facilidad de uso para usuarios expertos es n ms importante que la facilidad de aprendizaje para novatos, los esfuerzos de diseo se a n enfocarn sobre las alternativas que provean velocidad y eciencia en el uso. a En segundo lugar, las metas de usabilidad servirn como criterios de aceptacin dua o rante las pruebas de usabilidad. El ciclo de diseo y pruebas de usabilidad se itera hasta n que las evaluaciones indican que los criterios de usabilidad han sido satisfechos. Estos criterios responden a las metas de usabilidad planteadas para el proyecto. Adems estas a
7.2
107
Figura 7.11: Ejemplo de Personaje, de [Pruitt and Adlin 2006]
Figura 7.12: Ejemplo de Personaje, de [Pruitt and Adlin 2006]
108
7.2
Figura 7.13: Lista de control para denir las tres Cs del Rol de Uso de [Constantine and Lockwood 1999]
7.2
109
metas ayudan a priorizar los esfuerzos para reparar los problemas de usabilidad revelados por las pruebas. Cuando los recursos son limitados, los problemas que se vinculan directamente con las metas identicadas pra el proyecto deben tener la mxima prioridad de a resolucin. o De esta manera, se puede decir que las metas de usabilidad conducen el proceso de diseo y de evaluacin de la interaccin y la experiencia del usuario[Mayhew 1999]. n o o Descripcin y relaciones o Descripcin Las metas de usabilidad se basan en la elaboracin de los Modelos/perles o o de usuario y en el Anlisis de Tareas (que genera el Modelo de Tareas) y en las metas a y reglas del negocio espec co. Las metas de usabilidad pueden ser cualitativas o cuantitativas y pueden ser categorizadas empleando la denicin de usabilidad como o vimos en el Cap tulo 2: efectividad: relaciona las metas o sub-metas del usuario con la precisin y como pletitud con la cual pueden ser alcanzadas utilizando el sistema. Por ejemplo, si la meta deseada es reproducir un documento de dos pginas en un formato a especicado, entonces la precisin podr especicarse y medirse por el nmero o a u de errores de ortograf y el nmero de desviaciones del formato especicado y a u la completitud por el nmero de palabras del documento transcripto didivido u el nmero de palabras del documento original. u eciencia: relaciona el nivel de efectividad alcanzado en funcin de los recuro sos utilizados. Recursos relevantes pueden incluir el esfuerzo mental o f sico, tiempo, materiales, dinero. Si la meta es imprimir copias de un reporte, la eciencia podr especicarse y medirse por el nmero de copias impresas usables a u del reporte divido por recursos empleados como las horas de trabajo, costo del proceso o materiales consumidos. satisfaccin: describe el confort y aceptabilidad en el uso. Se puede especicar o y medir con escalas de medicin de actitudes o proporciones de comentarios o negativos y positivos en el uso. Las medidas de satisfaccin pueden evaluar o actitudes en el uso del producto o percepciones del usuario en temas de utilidad, facilidad de aprendizaje. Slot que completa [Especicacin tcnica] o e Rol responsable Especialista en experiencia de usuario Roles que pueden modicarlo Analista, Diseador de experiencia de usuario n Es input para las tareas Disear la experiencia de usuario, Revisar el diseo de expen n riencia de usuario, Preparar pruebas de usabilidad Es output de las tareas Especicar requerimientos y metas de experiencia de usuario, Entender y especicar el Contexto de Uso Ejemplo Las tablas 7.2 y 7.3, tomadas de ISO 9241-11 [ISO/IEC 1998] muestran ejemplos de las metas de usabilidad organizadas en las tres categor bsica. as a
110
7.2 Medidas de satisfaccin o Escala de satisfaccin o Tasa de uso en el tiempo Frecuencia de quejas
Medidas de efectividad Porcentaje de metas logradas Porcentaje de usuarios que completan una tarea Precisin promedio de las o tareas completadas
Medidas de eciencia Tiempo para completar una tarea Tareas completadas por unidad de tiempo Costo monetario de realizar una tarea
Tabla 7.2: Criterios generales de usabilidad Modelo de tareas Propsito o El propsito bsico de un Modelo de Tareas es el especicar el Contexto de Uso de la o a aplicacin, particularmente en los aspectos operativos y facilitar que el diseo de la ino n teraccin pueda mantener una postura de diseo desde cero utilizando ese contexto y o n los conocimientos de las condiciones cognitivas y sociales del usuario para establecer la mejor alocacin de responsabilidades entre el sistema y las personas que lo utilizarn. Se o a trata de no dar por sentada la distribucin actual de responsabilidades, sino de al menos o validarla como paso del proyecto. Descripcin y relaciones o Descripcin Un modelo de tareas (resultado del Paso:Identicar y documentar las taro eas del usuario, Tarea:Identicar y especicar el Contexto de Uso) se dene como una descripcin de una tarea interactiva a realizar por el usuario de una aplicacin o o utilizando su interfaz de usuario [Limbourg and Vanderdonckt 2004]. Los elementos individuales de un modelo de tareas representan acciones espec cas que el usuario puede realizar. Tambin debe incluirse en el modelo la informacin en el ordenamiene o to de subtareas y las condiciones para la ejecucin de tareas. o Para obtener un Modelo de Tareas se pueden usar diferentes mtodos que se difee rencian en el grado de formalismo de su notacin, poder de expresividad y nalidad. o Si bien todos ellos representan las tareas del usuario con el sistema, la nalidad del modelo puede ser diferente [Lors 2001] y ello se ve reejado en las formas de e representacin y la profundidad del anlisis: o a Modelos cognitivos: identican secuencias de comportamiento correctas, representan el conocimiento que debe poseer un usuario sobre el uso del sistema; parten de la descripcin de las tareas para especicar el conocimiento del o usuario Modelos predictivos: para la evaluacin del rendimiento humano; describen o secuencias de comportamiento y el conoicmiento que necesita el usuario para su ejecucin; el anlisis se enfoca en las rutinas del comportamiento. o a Modelos descriptivos: permiten olbtener una descripcin ms o menos como a pleta del sistema a partir de la informacin obtenida de las tareas o La Tabla 7.4 muestra algunos mtodos para realizar los tipos de modelos que se e mencionaron. Slot que completa [Especicacin tcnica] o e Rol responsable Especialista en UX
7.2
111
Criterios Uso de expertos
Efectividad Nmero de tareas u realizadas Porcentaje de funciones relevantes usadas Porcentaje de tareas completamente exitosas en el primer intento
Eciencia Eciencia relativa a un usuario experto
Satisfaccin o Escala de satisfaccin en funciones o avanzadas
Uso de novatos
Tiempo insumido en el primer intento
Tasa de uso voluntario
Uso infrecuente o intermitente
Disminuir requerimientos de soporte
Facilidad aprendizaje
de
Nmero de referu encias a la documentacin o Nmero de llau madas a soporte Nmero de accesos u a ayuda online Nmero de funu ciones aprendidas Porcentaje de usuarios capaces de aprender a criterio
Eciencia relativa del primer intento Tiempo insumido en aprender nuevamente una funcin o Nmero de errores u persistentes Tiempo productivo
Frecuencia de reuso
Tiempo para aprender
Tiempo para aprender Tiempo para reaprender Eciencia relativa mientras se aprende Tiempo insumido en corregir errores
Escala de facilidad de uso
Tolerancia a errores
Legibilidad
Porcentaje de errores corregidos Nmero de errores u de usuario tolerados Porcentaje de palabras leidas correctamente a una distancia dada
Escala de manejo de errores
Tabla 7.3: Medidas para objetivos de usabilidad
112
7.2
Comentarios Modelo de descomposicin del conocimiento o Familia de lenguajes para describir el conocimiento Notacion para el estilo de manipulacin directa o Medicin del rendimiento humano o Medida de la consistencia Herramientas de soporte al anlisis y vericacin a o
Mtodo e HTA GOMS UAN KLM TAG CTT
Tipo Cognitivo Cognitivo Cognitivo Predictivo Predictivo Descriptivo
Notacin o Graco Textual Graco Textual Textual Graco
Tabla 7.4: Mtodos para elaborar Modelos de Tareas e Roles que pueden modicarlo Diseador de UX, Analista, Representante de Usuarios n Es input para las tareas Disear la UX n Es output de las tareas Entender y especicar el Contexto de uso Ejemplos El Anlisis Jerrquico de Tareas (HTA) fue desarrollado por Annet y Duncan a a [Annet and Duncan 1967]. Realiza una descripcin de tareas en trminos de operaciones o e y planes. Las operaciones (descomposicin en subtareas) son actividades que realizan o las personas para lograr un objetivo y los planes sonuna descripcin de las condiciones o que se tienen que dar cuando se realiza cada una de las actividades. Las operaciones se pueden descompoener de forma jerrquica y se adigna un plan a cada una de las a subtareas que aparecen. Se dene un objetivo como un estado determinado del sistema que desea alcanzar un usuario. HTA implica tres etapas: recopilar informacin (revisin de o o documentos, entrevistas, cuestionarios, etc.), diagramar y analizar proveyendo sugerencias y gu para la tarea de diseo. as n
Figura 7.14: Notacin en HTA, de [Lors 2001] o e El formato grco se parece a un rbol con ramas y subramas en funciona de las a a necesidades (ver Figura 7.14). La Figura 7.15 muestra un ejemplo de HTA representado por un diagrama de rbol y una tabla (tomado de [Lors 2001]). a e GOMS, propuesto por Card, Moran y Newell [Card et al. 2000] es una familia de lenguajes que se basan en la visin de un usuario como un sistema procesador de informao cin. Para cada tarea se describe el objetivo a satisfacer (Goal ), el conjunto de operaciones o (Operations) que el sistema pone a disposicin del usuario para la interaccin, los mtoo o e dos disponibles para llevar a cabo esas operaciones (Methods) y un conjunto de reglas de seleccin (Selection)para determinar la alternativa ms conveniente para cada caso. o a Los objetivos son las metas que se propone conseguir el usuario. Un objetivo contiene informacin de la intencin del usuario. Para ello, debe realizar una serie de operaciones o o
7.2
113
Figura 7.15: Ejemplo de HTA, de [Lors 2001] e
114
7.2
bsicas, que GOMS toma como las unidades elementales de percepcin, motoras o actos a o cognitivos cuya ejecucin es necesaria para cambiar algn aspecto del modelo mental del o u usuario, o bien, para modicar el entorno. Este tipo de acciones puede afectar al sistema (pulsar una tecla) o bien, slo al estado mental del usuario (leer el cuadro de dilogo). o a Existe un grado de exibilidad acerca de la granularidad de las operaciones (amplitud de cada operacin). Para llevar a cabo estas operaciones, existen varias posibilidades de o descomposicin de una tarea en subtareas. Por ejemplo, en un gestor de ventanas, se o puede cerrar la ventana mediante ratn en un men o teclado (atajo). Cada una de estas o u posibilidades ser un mtodo. a e GOAL: CERRAR-VENTANA [select GOAL: USAR-METODO-RATON MOVER-RATON-A-MENU-VENTANA ABRIR- MENU CLICK-SOBRE-OPCION-CERRAR GOAL: USAR-METODO-TECLADO PULSAR-TECLAS-ALT-F4] Cuando hay ms de una alternativa, podemos indicar una serie de condiciones y reglas a para tomar la mejor alternativa (mtodo): e METHODS: IF (USUARIO-EXPERTO)USAR-METODO-TECLADO ELSE USAR-METODO-RATON] Podemos descomponer los objetivos en subobjetivos. GOAL: EDITAR-DOCUMENTO GOAL: ABRIR-DOCUMENTO La descomposicin de tareas permite comprender las estrategias para resolver probo lemas del dominio de la aplicacin. El objetivo del anlisis jerrquico de tareas es la de o a a producir una descomposicin de tareas, de modo que se pueda seguir paso a paso el mtoo e do de resolucin. GOMS puede servir tambin para medir rendimientos. La profundidad o e de subtareas se puede usar para estimar los requerimientos de la memoria de corto plazo e incluso para estimar tiempo de respuesta. KLM o Keystroke Level Mode, es una de las variantes de GOMS, que reduce el conjunto de operaciones disponibles a la pulsacin de teclas y movimiento del mouse. ESta o simpliacin permite obtener predicciones del tiempo que una persona emplear para la o a realizacin de una tarea. Estas mediciones parten de valores experimentales que indican la o duracin de actividades elementales. Por ejemplo, el tiempo de planicacin de una tarea o o se puede estimar en 2 a 3 segundos si ya est denida y de 5 a 30 seg. si hay que pensarla, a la pulsacin de teclado para un usuario normal es de 0.28 seg, apuntar con el mouse dura o 1,10 seg. etc. CTT o ConcurTaskTrees es una notacin desarrollada por Fabio Patern [Patern o o o 1999, Patern` et al. 1997] cuyo principal nalidad es la de poder representar las relaciones o temporales existentes entre las actividades y usuarios que son necesarios para llevar a cabo en las tareas. Esta notacin es especialmente util para aplicaciones CSCW. Una o de las principales ventajas de esta notacin es su facilidad de uso, lo que hace que sea o aplicable a proyectos reales con aplicaciones de un tamano mediolargo y que con llevan especicaciones de cierta complejidad. La notacin genera una representacin grca en o o a forma de rbol de la descomposicin jerrquica de las tareas existentes en el sistema. Se a o a permite la utilizacin de un conjunto de operadores, sacados de la notacin de LOTOS, o o para describir las relaciones temporales entre tareas (secuencialidad, concurrencia, recursin, iteracin...). La Figura 7.16 muestra un ejemplo de modelo de tareas construido con o o CTT.
7.2
115
Figura 7.16: Uso de CTT en la elaboracin de un Modelo de Tareas o En su metodolog Dise o Centrado en el Uso, Larry Constantine [Constantine a n and Lockwood 1999]presenta un Modelo de Tareas basado en Casos de Tareas, una adaptacin de Casos de Uso. La modelizacin de tareas est en el corazn del mtodo con o o a o e foco en la performance del usuario. Un Caso de Tarea representa una intencin singular o llevada a cabo por un usuario en algn rol. Constantine los llama tambin Casos de uso u e esenciales, porque intentan describir la esencia de una tarea. Cada uno es expresado como un dilogo en el cual la intencin del usuario y las responsabilidades del sistema son a o abstractas, simplicadas y desprovistas de cualquier asuncin sobre la tecnolog o su o a implementacin. ESta forma de descripcin intenta aproximarse mejor a la esencia de la o o tarea desde la perspectiva del usuario en un rol y evitar la consolidacin prematura sobre o el diseo de la interfaz de usuario. n Concepto de la Experiencia de Usuario El Concepto o Modelo Conceptual de la UX es una descripcin de alto nivel del modo o en que el sistema est organizado y opera de cara a usuario. a Propsito o Una vez formulado y consensuado, el concepto de la interaccin se convierte en una o hoja de ruta compartida por todo el equipo de proyecto sobre el camino a recorrer para brindar la experiencia de usuario deseada. Este concepto se utiliza por todo el equipo de diseo como la base sobre la cual n desarrollar en forma detallada y concreta cada componente de interaccin que se necesite o sin perder de vista el panorama general de la UX. Descripcin y relaciones o Descripcin Se trata de una abstraccin que esquematiza lo que la gente puede hacer o o con un producto y los conceptos necesarios para entender cmo interactuar con o l [Johnson and Henderson 2002]. No es una descripcin de la interfaz de usuario e o sino una estructura que esboza los conceptos y las relaciones entre ellos que forman la base del producto o sistema y su relacin con los usuarios. De acuerdo con el o tipo de sistema o producto en desarrollo, el Concepto de UX puede contener las principales metforas y analog a utilizar en el sistema, los conceptos del dominio a as que el sistema expone al usuario, la relacin entre tales conceptos y el mapeo entre o
116
7.2
ellos y las tareas que el usuario realiza. La importancia de contar con un concetpo de la UX previo al diseo de la IU se basa en el hecho de que durante el uso de un n sistema interactivo los usuarios construyen en sus mentes un modelo del sistema y su forma de funcionamiento. Esto les permite predecir su comportamiento y generalizar a otras tareas a partir de lo aprendido. Contar con un concepto bien diseado de n la UX facilitar esa accin de descifrado por parte del usuario y en consecuencia a o aumentar la usabilidad en trminos de facilidad de aprendizaje. a e Slot que completa [Diseo tcnico] n e Rol responsable El Diseador de la UX n Roles que pueden modicarlo Tambin puede intervenir en su desarrollo el Especiale ista de UX Es input para las tareas El Concepto de UX es el input principal de la tarea Disear n componentes de interaccin o Es output de las tareas Constituye el resultado de la tarea Disear la UX. n Prototipo de Experiencia de Usuario El prototipo es un modelo restringido de la interaccin de usuario, que se utiliza tanto o para extraer requerimientos como para las tareas de diseo (para explorar y para validar n ideas). Propsito o El principal propsito para la utilizacin de este producto de trabajo consiste en reducir el o o riesgo de avanzar en una direccin para el desarrollo hasta un momento en que cualquier o cambio resulte tanto o ms costoso que devolver el proyecto a su estado inicial. a Una de las ventajas ms importantes de un prototipo es la de poder testear una a propuesta de UX mucho tiempo antes de que el desarrollo real del sistema comience, lo que permite asegurar en alguna medida que el sistema a construir ser el adecuado. a Descripcin y relaciones o Descripcin Un prototipo puede ser tan formal o informal como sea necesario. Existe o abundante literatura en el campo de HCI, Diseo de interaccin y usabilidad sobre n o las posibilidades y caracter sticas de los prototipos (ejecutable o no ejecutable, alta o baja delidad, profundo o extenso, etc.), por ejemplo [Arnowitz et al. 2006], [Sharp et al. 2007], Buxton [2007]. Slot que completa [Diseo tcnico] n e Rol responsable El diseador de UX lo emplea para explorar y/o validar ideas de diseo n n antes consolidar decisiones que luego resulte muy caro modicar. Los analistas y especialistas de UX para entender los requerimientos de usuarios y luego planicar las actividades de testing Roles que pueden modicarlo Cualquiera de los Stakeholder, Tester de UX Es input para las tareas Revisar el diseo de la UX, Preparar pruebas de usabilidad n Es output de las tareas Entender y especicar el contexto de uso, disear la UX, Ejen cutar pruebas de usabilidad Ejemplo
7.2
117
Figura 7.17: Prototipo de IU de baja delidad
Figura 7.18: Prototipo de IU de alta delidad
118
7.2
En las guras 7.17 y 7.18 se muestran dos ejemplos de prototipos de interfaz de usuario de baja y alta delidad, respectivamente. Adaptaciones El formato y tcnica empleada para la realizacin de prototipos no constituye un e o aspecto relevante en s mismo. Deber elegirse el que resulte adecuado al proyecto y el a propsito buscado. El mismo criterio se aplicar respecto de la extensin de la porcin del o a o o sistema a prototipar (alguna interaccin espec o ca o todo el conjunto). Lo importante es comprender que para lograr el objetivo de probar tempranamente las interfaces de usuario, el prototipo debe ser ms econmico de construir que el sistema a o real, pero tener las sucientes capacidades para permitir una prueba con usuarios que resulte signicativa. Storyboard de Experiencia de Usuario Un Storyboard de UX consiste en la descripcin de la interaccin del usuario con el o o sistema para un escenario espec co. Propsito o Puede considerarse como lo plantean [Sharp et al. 2007] que un storyboard es una clase de prototipo. Especialmente, uno de baja delidad. Sin embargo, el rol decisivo que desempea para describir la dinmica de una interaccin nos inclina a ubicarlo entre la n a o lista de productos de trabajo que OpenUP/MMU-ISO debe proveer. Este producto de trabajo es uno de los componentes de diseo indicado en el MMUn ISO cuya carencia detectamos en el assessment. Para la propuesta nos basamos, adems a de los artefactos asociados a procesos DCU que sugiere el MMU-ISO, en las prcticas rea conocidas por la comunidad de Experiencia de usuario, por ejemplo [Mayhew 1999],[Beyer and Holtzblatt 1998]. Tambin reconocemos como antecedente al artefacto:Storyboard del e plugin UX de RUP [IBM 2005b] Descripcin y relaciones o Descripcin Un Storyboard de UX puede contener tres elementos: o Una descripcin del ujo de eventos entre el usuario y el sistema o Diagramas y grcos que muestran la interaccin del usuario. Pueden ser tan a o formales como los diagramas UML de colaboracin y secuencia, que sugiere o el Plugin UX de RUP o simples bocetos a la manera utilizada en la programacin de pel o culas para describir la serie de pasos que se dan para utilizar la funcionalidad del sistema durante un escenario espec co. Referencias expl citas a las metas de usabilidad vinculadas con el escenario (tiempos de ejecucin previstos, mxima tasa de error aceptable, etc.) o a Es habitual que en la medida que se han construido Prototipos de UX un Stortyboard haga referencia a ellos. Debe construirse un Storyboard por cada escenario de utilizacin del sistema preo visto, cualquiera sea el mtodo de modelizacin adoptado para las situaciones de e o uso (Casos de Uso, User stories, etc.). Slot que completa [Diseo tcnico] n e Rol responsable Los Storyboards de UX deben construirse y ser mantenidos por el Diseador de UX. n
7.2
119
Roles que pueden modicarlo Pueden participar en su redenicin y mantenimiento o el Analista de UX, cualquier otro Analista y cualquiera de los roles de Usuario. Es input para las tareas Disear la UX, Revisar el diseo de la UX, Preparar pruebas n n de usabilidad Es output de las tareas Disear la UX n Ejemplo La Figura 7.19 muestra un ejemplo de Storyboard con diagramas UML a mano alzada, de Scott Ambler [Ambler 2004], mientras en la Figura 7.20 se observa un Storyboard construido como navegacin entre prototipos de pantallas de baja delidad. o
Figura 7.19: Ejemplo de Storyboard
Figura 7.20: Ejemplo de storyboard de UX con prototipos de pantallas de baja delidad
Mapa de navegacin o Propsito o
120
7.2
El propsito de este artefacto es representar la navegacin del usuario por el sistema y o o contribuir a conformar el Modelo de la UX. El alcance de este mapa es obviamente todo el sistema (esto lo distingue de los storyboards, que focalizan en un escenario en particular). El Mapa de Navegacin ayuda a unicar la relacin entre los diferentes storyboards o o de la aplicacin y trasmite la estructura de un Modelo de la UX. o Los mapas de navegacin son habituales en proyectos de aplicaciones web, sin embargo o resultan de utilidad en el diseo de cualquier tipo sistema interactivo. En particular, n dentro de la familia de procesos basados en UP podemos reconocer su presencia en las orientaciones Usability engineering en RUP y Modeling user experience (UX Plugin) [IBM 2005b]. Descripcin y relaciones o Descripcin Muestra los componentes de interaccin y los caminos de navegacin entre o o o ellos. Puede representarse con diagramas UML de clase, como muestra la gura 7.21, ya sea en un unico diagrama o en varios, ajustando el nivel de detalle incluido. Slot que completa [Diseo tcnico] n e Rol responsable El Diseador de UX n Roles que pueden modicarlo Pueden participar en su redenicin y mantenimiento o el Analista de UX, cualquier otro Analista y cualquiera de los roles de Usuario. Es input para las tareas Disear la UX, Revisar el diseo de la UX, Preparar pruebas n n de usabilidad Es output de las tareas Disear la UX n Ejemplo La Figura 7.21 muestra un mapa de navegacin presentado por el Plugin para la UX o de RUP. Documento de usuario y entrenamiento Propsito o Este producto intenta proveer gu y soporte al usuario para el uso del producto. a Descripcin y relaciones o Descripcin Este producto comprende todos los materiales que brinden asistencia al o usuario nal para el aprendizaje, utilizacin, operacin y mantenimiento del sistema. o o Algunos de los formatos que puede adoptar este producto son: Manual de usuario Gu de operacin as o Gu de mantenimiento as Ayudas en l nea Notas de release
7.2
121
Figura 7.21: Mapa de navegacin o Estos productos pueden ser generados a partir de otros productos de trabajo. Por ejemplo, es comn realizar los Manuales de usuario o Ayudas en l u nea a partir de las especicaciones como Casos de uso. En trminos de la posibilidad de satisfacer e al MMU-ISO, nos interesa dar soporte al Proceso DCU 7 Presentar y operar el sistemadando cumplimiento a indicadores sobre el manejo de requerimientos de soporte a usuarios, encargados de mantenimiento y otros interesados. Este producto puede empezar a construirse en etapas tempranas del proceso, dependiendo del tipo de sistema. Slot que completa [Especicacin tcnica] o e Rol responsable Especialista de UX Roles que pueden modicarlo Analista Es input para las tareas Proveer entrenamiento y soporte al usuario Es output de las tareas Disear y producir material de entrenamiento y soporte al n usuario
7.2.3.
Tareas
En este apartado incorporamos las Deniciones de Tareas que utilizarn, modicarn a a y producirn los Productos de Trabajo denidos en el anterior. a Al igual que para los Roles y los Productos de Trabajo, aprovecharemos como antecedentes no slo las especicaciones del MMU-ISO y la bibliograf de Diseo Ceno a n trado en Usuario, sino tambin las Deniciones de Tareas presentes en diversas conge uraciones de la familia del Proceso Unicado (RUP[Krutchen 2000], Enterprise Unied Process[Ambler et al. 2005], Agile Unied Process[Ambler 2006]), por ejemplo las provenientes de la disciplina Modelizacin del Negocio que promueven la adaptacin del proceso, o o la comprensin del contexto organizacional donde se dar la insercin del sistema, etc. o a o Hemos incorporado en la Prctica DesCU las siguientes deniciones de Tareas: a
122
7.2
Adaptar el proceso de Desarrollo Centrado en Usuario (tailoring del proceso) Especicar requerimientos y objetivos de Experiencia de usuario Entender y especicar el contexto de uso Disear la experiencia de usuario n Disear componentes de interaccin n o Revisar el diseo de la experiencia de usuario n Preparar pruebas de usabilidad Ejecutar pruebas de usabilidad Disear y producir material de entrenamiento y soporte al usuario n Proveer entrenamiento y soporte al usuario Podemos plantear un mapa de tareas de la Prctica DesCU donde se vean las relaciones a con los procesos MMU-ISO, tal como reeja la gura 7.22. A continuacin detallamos la denicin de las tareas. Vamos a utilizar como base el o o template incluido en la Orientacin: Detallando una Tarea de la versin 1.5 del MAM o o [Eclipse 2008b]. Propsito: porqu hay que incluir la tarea? Cul es su meta? o e a Descripcin y relaciones: explica la ejecucin de la tarea, menciona los productos de o o trabajo que sirven de input y outputs que se generan y los roles involucrados en su realizacin. o Pasos: instrucciones para el ejecutante de la tarea. Un Paso se describe utilizando: Nombre descriptivo del paso Descripcin para brindar ms detalles del paso espec o a co Orientacin: gu para brindar detalles sobre la realizacin de la tarea o de algn o as o u paso espec co. Este tpico lo incluimos en los casos que resulta conveniente asociar o la tarea con una gu u orientacin que explique la forma de llevar adelante un paso a o concreto o la tarea en general. Tarea: Adaptar el proceso de Desarrollo Centrado en Usuario En esta Tarea se realiza la adaptacin y personalizacin de la conguracin OpenUP o o o para adaptarla a las necesidades espec cas del proyecto. Propsito o Por una parte esta tarea persigue el propsito de asegurar la cobertura de los proo cesos DCU1.Asegurar el enfoque DCU en la estrategia de sistemas y DCU2.Planicar y gestionar el proceso DCU del Nivel 1 del MMU-ISO. Pero, por otra parte, la inclusin de una Tarea que se enfoque en adaptacin del proceso o o de desarrollo en funcin del proyecto concreto es un requisito esencial para permitir la o obtencin del Nivel de Capacidad 3 (Proceso establecido) en lo referido a la consideracin o o de los usuarios e involucrados en el proceso. Por ejemplo en los atributos de denicin o de proceso (PA3.1) tales como identicar la denicion adecuada del proceso, adaptarlo al proyecto e implementarlo.
7.2
123
Figura 7.22: Mapa de relaciones entre Prctica DesCU y procesos MMU-ISO a
124
7.2
Relaciones Roles Entre los roles denidos para esta Prctica, tanto el Patrocinador como el L a der tcnico del dominio debern colaborar en forma secundaria. Pero la responsabilidad e a de llevar adelante la tarea, recae en el Gerente del Proyecto. Input Esta tarea se alimenta en forma mandatoria del proceso de desarrollo denido en la conguracin OpenUP/MMU-ISO N[x], donde [x] indica el nivel de capacidad o que se pretende alcanzar. En forma adicional se utilizar como input la Orientacin: a o Denirciones de Procesos DCU y Orientacin: Modelo ISO de Madurez en usabilidad o Output El resultado de la tarea es la instancian adaptada y publicada de la conguo racin elegida o Pasos Analizar el proyecto Es de vital importancia analizar la naturaleza, alcance y caracter sticas espec cas del proyecto para proveer un proceso que tenga el nivel de ceremonial y burocracia adecuado y relevante. En particular, en lo referido a la centralidad en el usuario, es de fundamental importancia conocer por ejemplo la disponibilidad real de todos los roles involucrados, el grado de innovacin que se o espera como resultado, el nivel de evangelizacin previa que puede requerirse para o implementar todos los elementos de la conguracin elegida, etc. Un proceso muy o burocrtico puede entorpecer el ujo normal del trabajo, un proceso demasiado lia vianopuede dar lugar a un entorno catico donde no es posible asegurar ninguna o calidad de resultados. Determinar el esfuerzo de adaptacin adecuado A partir del conocimiento previo o de la naturaleza y especicidad del proyecto entre manos, en este paso se trata de acotar el esfuerzo de adaptacin a lo estrictamente necesario. Puede ser que o un proyecto no requiera de todos elementos de contenidos y proceso incluidos enla conguracin de base. Este es el momento de denir por ejemplo las reas o temas en o a las que los miembros del equipo disponen de suciente experiencia previa y modos de trabajo que permitan evitar la introduccin de nuevas herramientas y procesos. o Por el contrario, pueden existir reas donde el equipo no posee ninguna experiencia a y que por lo tanto obliga a incluir procesos y gu que mantengan el proceso bajo as control. En cualquiera de los casos, las mejoras al proceso se pueden realizar en forma incremental durante las sucesivas iteraciones, de modo que la determinacin o del esfuerzo debe incluir no slo qu cambios realizar, sino tambin el cundo. o e e a Desarrollar contenido espec co DCU y congurar el proceso OpenUP, en cualquiera de las conguraciones ofrecidas, es un framework de procesos que puede, y debe, ser congurado para las necesidades espec cas. El Gerente del Proyecto (en cooperacin o estrecha con otros roles, fundamentalmente conocedores de buenas prcticas de ingea nier de software como el Especialista en UX) deber determinar los contenidos del a a mtodo que se incluirn, cules hay que desarrollar como nuevos, cules se podrn e a a a a reutilizar de los activos de proceso del equipo, etc. Con todos esos elementos (roles, actores, tareas, artefactos) se proceder a instanciar una conguracin espec a o ca para el proyecto. Denir el ciclo de vida DCU dentro del proceso Es muy importante, dentro del proceso de adaptacion, denir cual sera el cilo de vida general del proyecto (que hitos deniran los cambios de fases, cuantas iteraciones se desarrollaran para cada fase, etc). Esto es valido para cualquiera de las disciplinas involucradas en OpenUP, pero en el caso de los aspectos vinculados con usuarios, resulta crucial ya que entre
7.2
125
otras cosas deber denirse cundo involucrar a todos los roles espec a a cos, cmo y o cuando dar por cerrado un ciclo de diseo y pasar a construccion, como y cuando n realizar pruebas de usuario en lugar de inspecciones de experto, etc. Publicar el proceso para todos los integrantes del equipo Este paso pone a disposicion de todo el equipo la conguracion instanciada. Una forma practica de realizar este paso es publicar la conguracion como un sitio web accesible a todos, para que cada integrante sepa donde se espera que participe, que tareas y artefactos constituyen su responsabilidad (principal o secundaria) y cuales son las orientaciones o guias que pueden ayudarlo en ese trabajo. Mantener el proceso Para poder alcanzar realmente un nivel 3 de Capacidad en MMUISO no es suciente con los pasos anteriores. Es necesario monitorear continuamente el estado del proceso y realizar todos los ajustes que haga falta durante el proyecto. La naturaleza iterativa de OpenUp facilita este monitoreo, ya que en cada comienzo de iteracion se podra evaluar los resultados de la anterior e incluir en la nueva planicacion los cambios al proceso que resulten apropiados. Orientacin o Para asegurar la conformidad en el nivel macro el MMU-ISO, puede usarse como gu a el ciclo de vida bsico del desarrollo centrado en usuarios segn se indica en el diagrama a u de actividades de la Figura 7.23 que incluye los siete procesos DCU de MMU-ISO. Tarea: Especicar requerimientos y objetivos de experiencia de usuario Propsito o Esta tarea tiene dos propsitos principales. En primer lugar, ayudar a enfocar los eso fuerzos relacionados con la UX durante todo el desarrollo brindando a los desarrolladores elementos concretos de gu y evaluacin de las ideas de diseo. Tambin sirve para esa o n e tablecer criterios de aceptacin para las pruebas de usabilidad. o Relaciones Roles El rol responsable de esta Tarea es el Especialista de UX, sin embargo es necesaria la participacin tambin del Representante de usuarios, el L o e der tcnico de dominio e y otros Analistas. Input La Tarea se alimenta del Modelo de Usuario, el Modelo de Tareas y las metas de proyecto (de negocio y tcnicas) disponibles. e Output El resultado de la tarea es el conjunto de Metas de usabilidad del proyecto Pasos La tarea consta de cuatro pasos: Obtener informacin de Modelos disponibles Tanto el Modelo de Usuario como el o de Tareas contienen informacin que contribuye a generar metas de usabilidad. Por o ejemplo permiten identicar la importancia relativa de metas sobre facilidad de aprendizaje versus facilidad de uso o la preeminencia de la performance sobre la satisfaccin. El Modelo de Tareas revela las tareas claves del usuario sobre las cuales o ser conveniente establecer metas cuantitativas. Las metas de negocio, contenidas a en documento de visin y requerimientos funcionales tambin aportan informacin o e o para identicar y denir metas de usabilidad.
126
7.2
Figura 7.23: Ciclo de Vida de MMU-ISO
7.2
127
Identicar y bocetar metas de usabilidad La informacin del paso anterior revela o metas de usabilidad candidatas, tanto de tipo cualitativo como cuantitativo. Estas deben ser identicadas y enunciadas en borrador a medida que son descubiertas. En un paso posterior se realizar una descripcin precisa. a o Priorizar metas de usabilidad Es fcil construir una larga lista de metas de usabilia dad, tanto genricas como espec e cas para un proyecto, aunque no todas sean alcanzables simultneamente. Se hace necesario por tanto, establecer algn orden de a u prioridades para el equipo de desarrollo. Las metas identicadas deben clasicarse al menos en: a) requeridas, b) importantes pero no cr ticas, c) deseables. Documentar las metas de usabilidad Todas las metas priorizadas deben ser documentadas con el producto de trabajo respectivo y conocidas por todo el equipo de trabajo. Revisar y consensuar metas de usabilidad Aunque la participacin adicional de stakeo holders y analistas supone un acuerdo sobre las metas identicadas y priorizadas, es necesario realizar una revisin nal que asegure el compromiso de la gestin del o o proyecto con los requerimientos de usabilidad especicados. Tarea: Entender y especicar el contexto de uso La comprensin adecuada del contexto en el que utilizar el sistema y la especicacin o a o de los requerimientos que se derivan del mismo es imprescindible en un proceso centrado en usuarios. Propsito o Todo sistema en desarrollo se utilizar en un contexto determinado. Ser utilizado por a a una poblacin de usuarios con ciertas caracter o sticas, tendrn ciertas metas y desearn a a realizar algunas tareas espec cas. El sistema podr emplearse dentro de un rango de a condiciones tcnicas, f e sicas, sociales y organizacionales que a su vez podrn afectar su a utilizacin. La calidad de uso del sistema, incluyendo la usabilidad, salud y seguridad del o usuario depender entre otras cosas de haber comprendido bien este contexto de uso. a La extensin de esta Tarea podr depender del conocimiento que se tenga del tipo o a de sistema en desarrollo. Para sistemas bien comprendidos, ser suciente identicar los a involucrados y acordar reuniones para revisar el contexto de uso. En otros casos, ser necea sario complementar estas reuniones con un anlisis de las tareas y un estudio ms riguroso a a de los usuarios. Relaciones Roles El rol responsable de la tarea es el Especialista en UX, aunque tanto el Representante de Usuarios como el L der tcnico del dominio pueden tener una participacin e o secundaria. Input El input para esta tarea lo constituyen todos los artefactos que proveen alguna informacin sobre los diferentes contextos de uso del sistema (las tareas del usuario, o el entorno organizacional y f sico, los atributos del usuario) como el documento Visin y Reporte de investigacin de usuarios. o o Output El resultado principal de esta tarea es el Modelo de tareas, un producto de trabajo que contiene la descripcin de los diferentes contextos de uso. Opcionalmente, la o tarea de comprender cabalmente el contexto de uso puede derivar en modicaciones de artefactos de otras prcticas tales como la Visin y el Glosario. a o
128
7.2
Figura 7.24: Denicin de la Tarea Identicar y Especicar el contexto de uso o Pasos La tarea consta de cinco pasos bsicos: a Identicar y documentar las tareas del usuario Describir las actividades que los usuarios realizan para alcanzar sus metas. Las descripciones de tareas no incluyen solamente las funciones o caracter sticas del equipamiento. Las tareas pueden cambiar o evolucionar durante el ciclo de vida del sistema. Identicar y documentar los atributos de todos los involucrados Identicar y analizar los roles de cada grupo de usuarios e involucrados que sern afectados por el sistema. a Valorar la signicacin y relevancia del sistema para cada grupo. Describir las caro acter sticas relevantes de los usuarios nales del sistema, incluyendo conocimientos, lenguaje, capacidades f sicas, nivel de experiencia, etc. Identicar y documentar el entorno organizacional Describir el marco social y organizacional, la estructura y prcticas de gestin, etc. a o Identicar y documentar el entorno tcnico Describir las caracter e sticas relevantes de cualquier equipo que sea utilizado. Para sistemas nuevos las caracter sticas del equipo dependen de las soluciones a proponer, por lo que es posible que no sean conocidas hasta bastante avanzado el proyecto. Identicar y documentar el entorno f sico Describir la ubicacin, equipamiento del o puesto de trabajo y condiciones ambientales. Orientaciones Algunas de las tcnicas y mtodos que pueden emplearse para realizar esta Tarea se e e describen brevemente a continuacin. o Identicar y documentar los atributos de todos los involucrados Es importante identicar todos los usuarios y otros involcurados que se vern impactados por el sisa tema. Estos grupos pueden incluir desde usuarios nales, supervisores, instaladores, mantenedores hasta quienes slo reciban los outputs del sistema, la gente de maro keting, compradores, gente de soporte, etc. Usualmente, este paso puede resolverse mediante reuniones entre el Gerente del Proyecto, el Especialista en Experiencia de Usuario, el Lider tcnico y el Representante de usuarios. e
7.2
129
Anlisis de contexto de uso Mtodo estructurado para elicitar informacin detallada a e o del contexto de uso como base para actividades de usabilidad posteriores. Los roles de Stakeholders participan en una reunin de Contexto para contribuir a completar o un cuestionario detallado. Es una tcnica simple para utilizar cuando la informacin e o relevante del contexto es conocida por los Stakeholders. Mayor informacin se puede o encontrar en [Holtzblatt et al. 2005]. Encuesta de usuarios Las encuestas pueden ayudar a determinar las necesidades de usuarios, sus prcticas y actitudes hacia las nuevas ideas de un sistema. Permiten a obtener tanto datos cualitativos como cuantitativos de una cantidad importante de usuarios. Consultar por ejemplo [Kuniavsky 2003]. Estudios y observaciones de campo Los mtodos observacionales involucran un ine vestigador mirando los usuarios mientras trabajan y tomando notas de la actividad mientras sta tiene lugar. Algunos ejemplos de estos mtodos se encuentran en e e [Shepherd 2001] y [Stanton 2004] Anlisis de tareas Puede denirse como el estudio de lo que se requiere que un usuario a haga en trminos de acciones y/o procesos cognitivos para realizar una tarea. El e anlisis detallado de las tareas, sobre todo en los casos de actividades muy complejas a o no soportadas hasta el momento por sistemas de software es importante para determinar entre otras cosas una correcta distribucin de responsabilidades entre o las personas y la tecnolog Existen muchas variaciones de mtodos para realizar a. e anlisis de tarea como el Anlisis Jerrquico [Stanton 2006]. Un buen compendio de a a a tcnicas y mtodos se encuentra en [Stanton 2004] e e Tarea: Dise ar la Experiencia del Usuario n Esta tarea consiste en realizar las acciones necesarias para proponer y crear soluciones a las situaciones problemticas planteadas por los requerimientos del sistema para la futura a experiencia de usuario empleando prcticas de diseo del estado del arte. Se trata de a n crear y desarrollar el Concepto de Experiencia de Usuario que se propone para el sistema o producto. Debe adoptar una visin general del producto y proponer las principales o ideas que estructuran la interaccin del usuario con el sistema, los conceptos del dominio o involucrados, las restricciones que se plantean sobre la arquitectura del software para facilitar la usabilidad nal, la arquitectura de la informacin, etc. o Relaciones Roles El encargado responsable de la tarea es el Diseador de la Experiencia de usuario, n con aportes adicionales del Especialista en UX y todos los roles de usuarios. Input Para desarrollar esta tarea es necesario contar con todas las [Especicaciones tcnie cas] y conocer las propuestas de arquitectura de software planteadas en el Cuaderno de Arquitectura Output El producto principal de la tarea es el Concepto de la UX, pero en sucesivas iteraciones tambin produce o modica cualquier otro [Diseo de Interaccin] e n o Pasos Una tarea de diseo no puede prescribirse en una serie ja, lineal y ordenada de pasos. n Lo que indicamos a continuacin es el conjunto de acciones que el proceso DCU de Diseo o n de la experiencia de usuario debe contener. El orden, extensin e intensidad de cada paso o estar relacionado con la fase e iteracin del proceso de desarrollo y la experiencia de los a o diseadores con el dominio del problema. n
130
7.2
Alocar funciones Consiste en distribuir de manera conciente y expl cita las responsabilidades de acciones entre los usuarios y la tecnolog de soporte (el software y las a condiciones organizacionales). Esta alocacin debe tener en cuenta las capacidades o y limitaciones de cada uno de ellos para obtener la performance apropiada. Este paso busca optimizar la performance del sistema en su conjunto para el logro de las metas. Producir el modelo de tareas compuesto Desarrollar un modelo factible para nuevas tareas del usuario a partir delconocimiento delas mejores prcticas, los requerimiena tos, el contexto de uso, la alocacin de funciones y lsa restricciones al diseo del o n sistema. Explorar el dise o y generar alternativas Generar y estudiar varias opciones de diseo n n para cada aspecto del sistema relacionado con su utilizacin y su efecto en todos los o Stakeholders. Tarea: Dise ar componentes de interaccin n o Esta tarea es consiste realizar las acciones necesarias para proponer y crear soluciones a las situaciones problemticas planteadas por los requerimientos del sistema para la futura a experiencia de usuario empleando prcticas de diseo del estado del arte. a n Relaciones Roles Como es de suponer, el Diseador de la Experiencia de Usuario es el responsable n de la tarea. Sin embargo, respondiendo a la naturaleza del proceso que estamos deniendo, tambin los roles de Stakeholders podrn tener alguna participacin en e a o el diseo. Finalmente, el Diseador de UX podr dar participacin al Desarrollador n n a o para asegurar que sus propuestas sean implementables. Input Todos los elementos que han sido construidos para especicar requerimientos constituirn el input de esta tarea: Visin, Glosario, Modelo de tareas, Modelo de Casos a o de uso y el Concepto de UX. Output El resultado por antonomasia de esta tarea ser el Prototipo de UX, extendido a por el Storyboard y el Mapa de navegacin. No debe descartarse que esta tarea haga o propuestas de modicaciones a alguno de los artefactos que sirvieron de inpunt, especialmente al Modelo de Tareas y Modelo de Casos de uso. Estas modicaciones podrn quedar sujetas a la ejecucin de la Tarea Revisar el diseo de la UX. a o n La gura 7.25 presenta las relaciones de la tarea con otros elementos de la Prctica. a Pasos Explorar el dise o y generar alternativas generar y estudiar varias opciones de diseo n n para cada parte del sistema que estar en contacto con los usuarios . a Desarrollar la solucin de dise o Este paso es el ncleo de la Tarea. Se trata aqu de o n u aplicar todo el conocimiento relevante sobre la gente y la tecnolog y los diferentes a requerimientos especicados para el proyecto y generar soluciones espec cas para la interaccin de usuario con cada uno de los componentes del sistema. Cada solucin se o o concretar en simulaciones, modelos, maquetas o cualquier otra forma de Prototipo a que resulte apropiada al proyecto.
7.2
131
Figura 7.25: Denicin de la Tarea Disear la UX o n Especicar el sistema Las soluciones que se modelen y resulten adecuadas para someterlas a evaluacin debern ser especicadas de modo que las ideas y propueso a tas incluidas puedan ser implementadas en el resto del proyecto. La especicacin o ser diferente dependiendo de la Fase e Iteracin del proyecto. En las primeras ita o eraciones de Inicio o de Elaboracin es probable que la especicacin necesaria sea o o solamente aquella que permita al Tester de la UX realizar inspecciones heur sticas. Sin embargo, a medida que las soluciones se detallan, ser necesario incluir especia caciones orientadas a los desarrolladores. Tarea: Revisar el dise o de la Experiencia del usuario n En esta tarea se analiza las soluciones de diseo propuestas con para dar feedback n temprano sobre aspectos de usabilidad, en particular, y experiencia de usuario, en general. Sobre la base del conocimiento de capacidades y limitaciones humanas, el Tester de UX analiza los prototipos, storyboards y cualquier otro artefacto realizado y devuelve feedback en las etapas iniciales para evitar que se avance en el desarrollo de soluciones errneas. o Relaciones Roles La tarea es responsabilidad directa del Tester de UX que se basar en sus conocimiena tos de HCI, usabilidad, accesibilidad, interaccin, etc para analizar las soluciones y o proveer feedback. Para aumentar la riqueza de la revisin se podr requerir la coo a laboracin del Especialista en UX, del L o der tcnico de dominio y el Representante e de usuarios. Input Esta tarea se alimenta en forma obligatoria de las soluciones de diseo entren gadas por el Diseador de UX en cualesquiera de los formatos disponibles (Concepn to de UX, Prototipo, Storyboard, Mapa de navegacin). Adicionalmente es conveo niente que se consulten las especicaciones de requerimientos tales como la Visin, o el Glosario, el Modelo de Casos de Uso y el Modelo de Tareas.
132
7.2
Output El resultado esperable son las sugerencias de modicaciones a los productos de trabajo que se tomaron como input: Prototipo de UX, Storyboard, Mapa de navegacin. o La gura 7.26 muestra que la Tarea se constituye en uno de los nodos centrales del Proceso DCU (junto con Disear la Experiencia del usuario), por cuanto permite la parn ticipacin de los diferentes roles representantes de usuarios y aborda la revisin de la o o mayor de los Productos de Trabajo incorporados en el proceso de diseo. a n
Figura 7.26: Denicin de la Tarea Revisar el Diseo de la Experiencia de usuario o n
Pasos Especicar y validar el contexto de evaluacin Es muy importante tener claras las o diferencias entre las condiciones del contexto de evaluacin y el contexto de uso o especicado por el producto de trabajo correspondiente. Este paso asegura una buena gestin de la evaluacion. o Evaluar prototipos iniciales para mejorar el dise o Utilizando la experiencia y conocimienn tos previso de tester, realizar pruebas de inspeccin sobre los Prototipos, Storyboard o y Mapa de navegacin. Se deber revisar que en el diseo se han seguido las buenas o a n prcticas de diseo de interaccin, se han empleado adecuadamente los conocimiena n o tos de HCI disponibles, se utilizaron los activos del proyecto o la organizacin tales o como gu de estilo, estndares de referencia, legislacin vigente, etc. as a o Evaluar el sistema para vericar que los requerimietnos se cumplan Testear las versiones en desarrollo o nal del sistema para asegurar que cumple los requerimientos de los usuarios, las tareas y el entorno como fueron denidos. Presentar los resultados Luego de realizadas las inspecciones y las pruebas contra requerimientos y prcticas, deber presentarse al equipo de diseo los resultados de la a a n manera ms apropiada. Esta presentacin incluir adems de los errores y falencias a o a a encontrados, las sugerencias de cambios para superarlos. Orientaciones
7.2
133
En la literatura de diseo de interaccin existen tres abordajes principales para la evaln o uacin de propuestas: a) pruebas de usabilidad, b) estudios de campo y c) evaluaciones o anal ticas. Cada uno de estos enfoques puede implementarse con diferentes mtodos como e observar usuarios, encuestar usuarios, encuestar expertos, probar con usuarios, inspeccionar el sistema, modelar la performance del usuario, etc. Los dos primeros abordajes son utilizados dentro de la Prctica DCU en las tareas a Preparar pruebas de usabilidad y Ejecutar pruebas de usabilidad. En esta Tarea utilizamos el enfoque de evaluaciones anal ticas. Las evaluaciones anal ticas emplean bsicamente dos categor de mtodos: las insa as e pecciones y los modelos basados en teor Ambos tienen como caracter as. stica central que no es necesario contar con la presencia de usuarios en las pruebas. Las inspecciones pueden consistir en el chequeo de reglas heur sticas donde se aplica conocimiento previo de usuarios t picos para identicar problemas de usabilidad [Nielsen 1993] o recorridos, donde un experto pasea a travs de escenarios con prototipos del e sistema. Las heur sticas se basan en conocimiento de sentido comun y guias de usabilidad (tales como proveer un lenguaje familiar al usuario). Se desarrollaron originalmente para sistemas de pantallas, pero luego han sido adaptadas a diferentes sistemas basados en software. Los recorridos cognitivos consisten en simular el proceso de resolucion de problemas del usuario para cada paso del dilogo propuesto con el sistema y chequear el progreso a paso a paso en las interacciones. Se suelen emplear para evaluar la facilidad de aprendizaje de un sistema. [Rieman et al. 1995] Los modelos tericos se han empleado principalmente para comparar la ecacia de o diferentes interfaces de la misma aplicacin y la disposicin ptima de controles. Algunos o o o de los principales modelos que se pueden mencionar son la Ley de Fitts, modelos de tecleo como GOMS, etc. Tarea: Preparar pruebas de usabilidad Consiste en preparar los casos y datos necesarios para realizar pruebas que involucren activamente a usuarios para evaluar la satisfaccin de requerimientos y objetivos de o usabilidad planteados para el proyecto. Propsito o El principal propsito de las pruebas de usabilidad consiste en obtener feedback de usuarios o nales (o una muestra representativa de ellos) sobre el logro de los objetivos planteados para la experiencia del usuario. Relaciones Roles El responsable de la Tarea es el Tester de la experiencia de usuario. En la creacin o de las pruebas pueden colaborar como participantes secundarios el Especialista de UX (aportando su experiencia y conocimientos en interaccin y usabilidad) y el o Representante de usuarios (indicando tareas y datos que resulten signicativos para los usuarios). Input Como datos de entrada para la preparacin de las pruebas se emplearn todas las o a especicaciones de requerimientos disponibles tanto como las propuestas de diseo n que pueda haber. Output El resultado de esta tarea ser uno o ms Casos de prueba orientados a los a a aspectos de usabilidad.
134
7.2
Figura 7.27: Denicin de la Tarea Ejecutar pruebas de usabilidad o Pasos Decidir los objetivos de UX a probar El primer paso consiste en priorizar y elegir entre los requerimientos y objetivos de UX planteados para el proyecto,cules sern a a incluidos en las pruebas. Por ejemplo, si en un proyecto es ms importante asegurar a la facilidad de uso que la eciencia o performance, las pruebas debern focalizarse a en aquellas tareas y caracter sticas del sistema que permitan dar feedback a los desarrolladores sobre ese objetivo. Identicar tipo y rango de usuarios a incluir Este paso es necesario cuando existen diferentes tipos de Stakeholder: Usuario nal. En este caso habr que decidir cules a a debern participar en cada una de las pruebas que se prepare. a Dise ar la tarea a probar Las tareas que servirn de base a la prueba podrn ser n a a extra das (y adaptadas en la medida que resulte necesario) de las diferentes especicaciones de requerimientos: Modelo de Tareas, Modelo de Casos de Uso, Escenarios. Los roles Representante de usuarios y Usuario nal son aliados claves en este paso para conseguir una adaptacin signicativa de las tareas. o Dise ar la prueba y desarrollar los materiales necesarios Es importante planicar n cuidadosamente la secuencia de eventos para la prueba y la elaboracin de todos o los materiales necesarios. Dependiendo del alcance de la tarea y la rigurosidad de la prueba los elementos a considerar son: Brief del observador Guin de prueba incluyendo bienvenida e introduccin o o Encuesta previa a la prueba Entrenamiento previo en el uso del material (por ejemplo, los prototipos) Formularios de consentimiento para grabaciones de audio y/o video Enunciados de tareas de prueba Planillas para la recopilacin de datos o
7.2
135
Encuesta posterior a la prueba Plantillas para la presentacin de resultados del anlisis o a Dise ar y ensamblar el entorno de prueba Si no se dispone de un laboratorio de n usabilidad para hacer las pruebas (o la naturaleza de la tarea requiere una prueba en otro tipo de entorno), ser necesario denir todos el equipamiento a utilizar a as como el diseo del ambiente sico. En las orientaciones se sugieren fuentes de n consulta sobre el diseo de este ambiente. n Reclutar usuarios Este paso consiste en el acuerdo de participacin de los usuarios o nales en las pruebas, asi como el armado de un cronograma estimado durante el cual ellos estarn disponibles para realizarlas. a Orientaciones Las pruebas de usabilidad constituyen uno de los ejercicios clsicos en cualquier proceso a de desarrollo centrado en usuario. Existe en la literatura un gran nmero de obras que u describen sus fundamentos y el modo de realizarlas. Como ejemplo, a la hora de congurar un proceso DCU se podr tomar como referencia las siguientes obras: a The usability engineering lifecycle por Deborah Mayhew, pgs 342-346 [Mayhew a 1999] Interaction design por Sharp, Rogers y Preece, Cap tulo 14 [Sharp et al. 2007] Observing the user experience por Mike Kuniavsky, Cap tulo 10 [Kuniavsky 2003] Tarea: Ejecutar pruebas de usabilidad Consiste en la realizacin completa de las pruebas preparadas, el anlisis de los resulo a tados y su comunicacin al equipo de trabajo o Propsito o Proveer feedback al equipo sobre el nivel de logro de los requerimientos y objetivos planteados para el proyecto en aspectos vinculados con la experiencia del usuario, particularmente con la usabilidad del sistema. Relaciones Roles El responsable es el Tester de la experiencia de usuario, pero debe participar activamente tanto el Usuario nal como el Representante de Usuarios. Adicionalmente podrn colaborar el Especialista de la UX para cubrir los roles de moderacin prea o vistos en las pruebas y para contribuir al anlisis de los datos obtenidos. a Input Esta tarea se alimenta de los Casos de Prueba de Usabilidad generados en la Tarea: Preparar pruebas de usabilidad Output El resultado es un registro de la prueba y los anlisis efectuados sobre los datos a obtenidos. Normalmente consistir en versiones modicadas y comentadas de las a propuestas de diseo empleadas al preparar la prueba: Prototipo, Storyboard, Mapa n de Navegacin o La gura 7.28 muestra las relaciones entre la Denicin de la Tarea Ejecutar pruebas o de usabilidad y los otros elementos de Mtodo. e Pasos
136
7.2
Figura 7.28: Denicin de la Tarea Ejecutar pruebas de usabilidad o Setear el entorno y condiciones de prueba Establecer las condiciones para ejecucin de la prueba tal como fue planicada en la Tarea: Preparar pruebas de uso abilidad. Este paso no solo implica el entorno f sico de pruebas, sino tambin asee gurar que estn disponibles tanto los usuarios como los colaboradores y el material a requerido segn el guin de la prueba. u o Ejecutar la prueba y recopilar los datos Correr el procedimiento de prueba tal como fue planicado. El ciclo habitual ser: dar la bienvenida al usuario, realizar las a encuestas previas, conseguir las autorizaciones de registro pertinentes, presentar la tarea al usuario (con un pequeo entrenamiento en el manejo de los prototipos si n la tarea lo requiere), dejar que el usuario complete la tarea sin inuirlo ni guiarlo con los registros adecuados, reunir todos los datos obtenidos, recolectar los datos post-prueba que sean necesarios y volver a comenzar con otro usuario. Analizar e interpretar los datos obtenidos Concentrarse en las reas donde los datos a mostraron que los objetivos o requerimietnos de aceptacin no se alcanzan. Tratar o de intepretar estas fallas en trminos de cambios de interaccin, diseo de pantallas e o n y tambin en el modelo de las tareas propuesto por los Casos de Uso. e Sacar conclusiones y formular recomendaciones de cambio Utilizar los datos para extraer conclusiones respecto de cada uno de los problemas identicados y proponer cambios para eliminarlos. Documentar y presentar resultados Siempre que sea posible (sobre todo si los otros miembros del equipo no estn presentes durante la prueba) es conveniente realizar a una presentacin de resultados y recomendaciones en forma oral apoyada por alo gun tipo de prsentacin de las grabaciones obtenidas. Adjuntar un reporte con los o problemas identicados y los cambios que se recomiendan. Tarea: Dise ar y producir material de entrenamiento y soporte al usuario n Un proceso de desarrollo que se enfoque en el usuario debe incluir una tarea que consista en el diseo y produccin de materiales para el soporte y entrenamiento de los n o usuarios durante la implantacin, puesta en produccin o liberacin del sistema. o o o
7.2 Propsito o
137
Esta tarea tiene por objetivo asegurar que se brinda apoyo a los diferentes tipos de usuarios involucrados en la etapa de implementacin (usuarios nales, encargados de mano tenimiento, instaladores, etc). Relaciones Roles El responsable de la tarea es el Especialista en UX aunque deber contar con la a colaboracin directa del L o der tcnico de dominio y del Representante de usuarios, e especialmente en el material de entrenamiento. Input Los materiales que esta tarea utiliza como insumos son todos los productos que describen los requerimientos del sistema y los planes de la iteracin. o Output El resultado ser uno o ms Documento para soporte y entrenamiento de usuario. a a La gura 7.29 muestra las relaciones entre esta tarea y otros elementos de la Prctica a DCU.
Figura 7.29: Denicin de la Tarea Producir material de entrenamiento y soporte al usuario o
Pasos El materia de soporte y entrenamiento para usuarios nales pueden llegar a constituir proyectos o aplicaciones en s mismos. Sin llegar a ese punto, un proceso DCU debe contemplar clara y expl citamente tanto el entrenamiento y capacitacin de usuarios a n o de facilitar la apropiacin del nuevo sistema, como el soporte para la personalizacin del o o sistema all donde las necesidades espec cas de algun grupo de usuarios lo requiera. Esta tarea deber contemplar al menos: a Denir los objetivos del entrenamiento y soporte Considerar la audiencia a capacitar y decidir las mejores estrategias (manuales y tutoriales en l nea, cursos de capacitacin, prcticas y ejemplos guiados, etc.) y los objetivos para cada grupo de o a usuarios involucrado
138
7.2
Dise ar material de entrenamiento y soporte Realizar el diseo de todo el material n n necesario para que cada grupo identicado pueda alcanzar los objetivos planteados de entrenamiento y disponga del soporte adecuado para el uso y conguracin del o sistema. Realizar material de entrenamiento Producir el material diseado y liberarlo de acuern do con el plan de despliegue del proyecto. Tarea: Guiar y dar soporte al usuario en implementacin o Brindar entrenamiento y soporte a los usuarios, transferir el conocimiento del funcionamiento del sistema y nuevo diseo de tareas donde sea necesario. n Relaciones Roles El encargado de esta tarea es el Especialista en UX, con la colaboracin de todos o los Stakeholders incorporados al equipo. En las conguraciones posteriores veremos que otros miembros del equipo (Gerente de Proyecto y Analista pueden ser asignados a esta tarea) Input La tarea se nutre de los materiales de capacitacin y conguracin (Documento o o para soporte y entrenamiento de usuario) generados en la tarea anterior. Output La tarea no produce resultados entregables, sino la capacitacin y capacidad de o conguraciones y adaptaciones por parte de los usuarios.
Figura 7.30: Denicin de la Tarea Guiar y dar soporte al usuario en implementacin o o
Pasos La secuencia de pasos a ejecutar depender del esquema de capacitacin y entrenamiena o to que se haya elaborado.
7.3
Conguraciones de Mtodo: OpenUP/MMU-ISO e
139
7.2.4.
Orientaciones
La Prctica DesCU debe estar integrada por Orientaciones que contribuyan al ingea niero de procesos y los miembros del equipo a comprender y mantener el foco en las posibilidades y limitaciones de la prctica. a En particular proponemos la integracin de dos orientaciones bsicas. La primera cono a tiene las deniciones de los Procesos DCU y la segunda, los niveles del MMU-ISO. A modo de hoja de ruta, ambas dan gu al ingeniero de proceso para la adopcin total o parcial a o de la Prctica y su inclusin en los procesos de desarrollo. a o El contenido de la primera Orientacin:Deniciones de Procesos DCU corresponde al o Apndice A, mientras que el Apndice B incluye la descripcin completa de los atributos e e o de Niveles de Capacidad para todo el MMU-ISO.
7.3.
La implementacin de la Prctica Desarrollo Centrado en Usuario en un proceso basado o a en OpenUP asegura la inclusin bsica de todos los procesos DCU de MMU-ISO. En o a consecuencia, una extensin de la conguracin OpenUP/Basic que incluya esta nueva o o Prctica alcanzar para dar cobertura al Nivel 1 del MMU-ISO. a a Sin embargo, esto no asegura que se logren los otros dos niveles que aspiramos a soportar. Para saldar esta necesidad proponemos completar un esquema de tres conguraciones de prcticas que puedan ser instanciadas para alcanzar cada uno de los niveles a de capacidad en Nivel 1, 2 o 3 del MMU-ISO. En l neas generales, entonces, podemos sealar que el Nivel 1 se alcanzar con una conn a guracin que incluya la Prctica Desarrollo Centrado en Usuario tal como fue presentada o a en la seccin anterior. Para los Niveles 2 (gestionado) y 3 (establecido) utilizaremos la vario abilidad extiende sobre el Nivel 1 y 2, respectivamente con el objetivo de incorporar las actividades de gestin de proceso y producto y de adaptacin de los mtodos requeridas, o o e tal como hemos visto en el cap tulo anterior. En los tres casos, se trata de adaptaciones a conguraciones existentes. Partimos de la conguracin publicada como OpenUP/Basic en su release 1.5.0.1. Sobre sta elaboramos o e OpenUP/MMU-ISO N1. OpenUP/MMU-ISO N2 se construye como extensin de N1 y lo o mismo ocurre con N3 respecto de N2. A continuacin presentamos el contenido de estas adaptaciones, tomando como vista de o navegacin los Procesos de Despliegue de OpenUP/Basic que responden al ciclo de vida o basado en la Prctica de Ciclo Riesgo-Valor con las cuatro fases iterativas del Proceso a Unicado: Inicio, Elaboracin, Construccin y Transicin. o o o
7.3.1.
OpenUP/MMU-ISO N1
En esta conguracin incluimos los cambios y extensiones necesarias para dar cobero tura amplia al Nivel 1 del Modelo de Madurez de Usabilidad ISO. En cada una de las Fases (Inicio, Elaboracin, Construccin, Transicin) describimos o o o el ujo de actividades base, destacando aquellas que sufren alguna alteracin y detallando o las extensiones o cambios que proponemos. FASE DE INICIO El objetivo de esta fase es entender el alcance del problema y la factibilidad de una solucin. El proceso de despliegue para una iteracin t o o pica de esta Fase en nuestra conguracin contiene las mismas cuatro actividades base: Iniciar el proyecto, Identicar y o
140
7.3
Renar requerimientos, Acordar sobre el enfoque tcnico y Planicar y Gestionar la Itee racin, tal como se muestra en la gura 7.31, aunque, como veremos a continuacin, con o o varios cambios al interior de cada actividad.
Figura 7.31: Iteracin t o pica de Fase de Inicio con DesCU
Actividad: Iniciar el proyecto Esta actividad tiene lugar al comienzo de la primera iteracin, cuando comienza el proyecto y su meta es establecer una visin de alto nivel o o tanto del proyecto como del plan. Incluye dos tareas como se muestra en la Figura 7.32: Desarrollar la visin tcnica (donde el Analista y el Stakeholder trabajan juntos para o e obtener una visin del proyecto) y Planicar el proyecto (en la que el Gerente de o Proyecto propone un plan de alto nivel con los hitos de cada una de las cuatro fases y un primer cronograma de iteraciones). Para este Nivel de Capacidad, los cambios en la Actividad Iniciar el Proyecto buscan tres objetivos: a) dar lugar a los Roles espec cos de DCU, b)poner nfasis en la e consideracin de usuarios en cada uno de los pasos para garantizar su centralidad desde o el comienzo en concepcin del sistema y esbozo de plan y c) sembrar adecuadamente el o terreno para el trabajo posterior (por ejemplo, en la Tarea Desarrollar Visin Tcnica o e agregaremos el paso Identicar y bocetar el contexto de uso para permitir que haya desde el comienzo material adecuado para la Tarea posterior Entender y especicar contexto de uso, que incluiremos en las actividades de requerimientos). A continuacin detallamos los cambios incluidos en esta Actividad. o Tarea: Desarrollar Visin Tcnica Se incluyen dos roles DCU, se agrega un o e paso relacionado al contexto de uso y se rena el Template del documento Visin: o debe contar con la participacin activa del L o der tcnico del dominio y del Repree sentante de usuarios, como especicacin del Stakeholder que involucra la versin o o bsica. a
7.3
141
Figura 7.32: Actividad Iniciar el Proyecto en OpenUP/MMU-ISO N1
se agrega el paso Identicar y Bocetar Contexto de uso con el objetivo de asegurar que se obtiene informacin pertinente para el Proceso ISO DCU4. Consiste en o identicar, claricar y registrar las caracter sticas de todos los involucrados (usuarios nales e intermedios), sus tareas y el entorno f sico y de organizacin en que se o operar el sistema. a se modica el Template del Documento Visin, con el objetivo de ampliar la inforo macion contenida en la descripcion de Stakeholders y en el Contexto de usuario. Se busca que estas secciones sirvan de input adecuado a las tareas posteriores de Identicar y especicar stakeholers y Entender y especicar Contexto de Usuario. Tarea: Planicar el Proyecto Debe incluir la participacion activa del Patrocinador y del L der tcnico del dominio para validar las ideas del Gerente del Proyecto. e Opcionalmente, en el segundo nivel de Planicacin (ver Prctica: Planicacin en dos o a o niveles) se puede solicitar la participacin del Representante de usuarios. o Por otra parte, la Prctica de Gestin:Planicar el Proyecto en dos niveles incluir en a o a el nivel 1 la participacin de los usuarios mediante su inclusin con roles concretos dentro o o del equipo y en el nivel 2 denir los criterios de performance y productos de trabajo a incluir en cada una de las tareas de DCU. Actividad: Identicar y renar requerimientos Esta actividad describe las tareas para obtener, especicar, analizar y validar un subconjunto de requerimientos. En virtud del carcter iterativo e incremental de OpenUP, es lgico que esta actividad a o est incorporada en los procesos de despliegue de las fases Inicio, Elaboracin y Cone o struccin, aunque con enfoques diferentes. En la Fase de Inicio, el foco se coloca sobre la o comprensin del problema a resolver, la identicacin de las necesidades de stakeholders o o y el planteo de las caracter sticas de alto nivel del sistema. Ms adelante veremos que en a las fases de Elaboracin y Construccin el foco vira signicativamente de la comprensin o o o del problema a la denicin y renamiento de la solucin. o o La denicin bsica de la Actividad incluye cuatro tareas. Tres estn a cargo del o a a Analista: Encontrar y bocetar requerimientos, Detallar escenarios de Casos de Uso y Detallar requirimientos globales; el Tester ser responsable de la cuarta: Crear a casos de prueba.
142
7.3
En nuestra conguracin proponemos un cambio importante en la composicin de la o o actividad, espec camente en lo relacionado a determinar y especicar claramente todas las partes involucradas, el contexto de uso del sistema y la formulacin de requerimientos o y metas deseadas para la experiencia de usuario. Desagregamos estos contenidos de las tareas Encontrar y bocetar requerimientos y Detallar requirimientos globales para dar lugar al Especialista en UX a identicar, especicar y detallar tanto las deniciones de cada una de las partes involucradas (stakeholders) y del contexto de uso (con la extensin y formalidad que el proyecto requiera) o como los objetivos que se pretenden alcanzar para la experiencia del usuario con el sistema. El Analista concentrar en la Tarea: Encontrar y bocetar requerimientos el trabajo con a los requisitos funcionales del sistema, mientras el Especialista en UX (tambin Analista) e se enfocar en los temas que impactan directamente la interaccin de usuario. El trabajo a o de ambos ser incorporado en los modelos que contengan las [Especicaciones tcnicas], a e como el Modelo de Casos de Uso y la Especicacin de Requerimientos Globales. o Entonces, la conguracin OpenUP/MMU-ISO N1 propone la Actividad: Identicar o y renar requerimientos con las siguientes tareas que se representan en la Figura 7.33: Tarea: Encontrar y bocetar requerimientos Denida en OpenUP/Basic, la modicacin que incluimos consiste en desagregar todos los requerimientos vinculados con la o experiencia de usuario (usabilidad, navegacin, interaccin, etc.), sean o no funcionales. o o Esto afecta fundamentalmente a los pasos 3 (Identicar los tipos de requerimientos relevantes al sistema), 6 (Identicar y capturar requerimientos globales) y 7 (Lograr concurrencia) de la Tarea. Tarea: Entender y especicar el contexto de uso sido descripto en prrafos anteriores. a El contenido de la Tarea ha
Tarea: Especicar metas de la experiencia de usuario La Tarea fue descripta en prrafos anteriores y se incluye en esta conguracin en su versin completa. a o o Tarea: Detallar escenarios de casos de uso OpenUP/Basic. Sin modicaciones respecto de
Tarea: Detallar requerimientos globales Los requerimientos relacionados con usabilidad dejan de ser incumbencia de esta tarea y pasan al mbito de Especicar metas a de UX. El resto de la tarea se realiza de la forma denida en OpenUP/Basic. Tarea: Crear casos de prueba Sin modicaciones respecto de OpenUP/Basic.
Actividad: Acordar el abordaje tcnico En esta Actividad se produce la primera e aproximacin a una solucin de diseo en OpenUP. La meta es denir una aproximacin o o n o tcnica al sistema consistente con los requerimientos del proyecto y las restricciones conoe cidas. No se busca producir una especicacin tcnica completa y comprehensiva, sino o e algo de alto nivel que brinde las sucientes garant de factibilidad al equipo (de heas cho, habitualmente esta aproximacin consiste en soluciones que ya han sido probadas en o otros proyectos o dominios) y que pueda ser corroborada de alguna forma con todos los involucrados. Es importante que desde estas primeras decisiones que determinarn las posibilidades y a restricciones del sistema a la experiencia del usuario, se de participacin a los especialistas o en tales temas. Diversos autores han mostrado claramente la relacin que existe entre las o decisiones tempranas sobre la arquitectura del software y las posibilidades de alcanzar
7.3
143
Figura 7.33: Actividad: Identicar y renar requerimientos con la Prctica DCU a
144
7.3
buenos niveles de usabilidad, por ejemplo [Bass and John 2001a] y [Folmer and Bosch 2005]. Se propone la realizacin en simultnea de dos tareas: Bocetar la arquitectura y o a Dise ar la Experiencia de usuario. Entre ambas, proveern al equipo con las primeras n a decisiones gruesas sobre la arquitectura del sistema y el concepto de experiencia de usuario que se busca implementar. Tarea: Bocetar la arquitectura En esta tarea los aspectos arquitectnicamente o relevantes de la Visin comienzan a tomar forma con la identicacin restricciones, toma o o de decisiones y formulacin de objetivos. No sufre cambios respecto de la especicacin o o de OpenUP/Basic. Tarea: Disear la experiencia de usuario Deber incluir una s n a ntesis entre la arquitectura tcnica y la UX propuesta. Esta tarea contiene el diseo en el nivel macro e n de la UX, con las propuestas de estilo de interaccin, modelo conceptual del sistema, o arquitectura de la informacin, etc. o
Figura 7.34: Actividad: Acordar el abordaje tcnico con la Prctica DCU e a
Actividad: Planicar y gestionar la iteracin En la Actividad: Planicar y geso tionar la iteracin no se incluyen nuevas tareas o modicacin sustantivas de los ujos de o o informacin. Se enfatiza en la necesidad de la participacin activa y constante de los repo o resentantes de usuarios y se agregan algunos pasos que permitan alcanzar la satisfaccin o de los niveles 3 y 4 del MMU-ISO. En particular, toma gran relevancia la participacin o de usuarios en la Tarea:Evaluar resultados. Tarea: Planicar la iteracin En esta tarea se planica el alcance de la iteracin o o con el aumento incremental de las capacidades del sistema y se construye un plan de bajo nivel que permita lograr esa capacidad. El responsable de la tarea es el Gerente de Proyecto, sin embargo es importante incluir entre los participantes adicionales al L der tcnico del dominio, para asegurar que la e priorizacin de items se mantiene en sinton con las expectativas de los usuarios. o a Tarea: Gestionar la iteracin La tarea se concentra en monitorear el estado o del proyecto e identicar tanto los conictos como oportunidades, manejar excepciones y riesgos.
7.3
145
Figura 7.35: Actividad: Planicar y gestionar la iteracin en OpenUP/MMU-ISO N1 o
146
7.3
Un aspecto importante de la tarea consiste en mantener comunicado el estado del proyecto a todos los involucrados. Este punto abre la puerta a la participacin del Pao trocinador y del L der tcnico del dominio. El primero, fundamentalmente porque el Hito e de esta Fase determinar la conveniencia y factibilidad de seguir adelante con el proyecto a y en consecuencia todos los aspectos que resulten en algn tipo de bloqueo o interferenu cia deber ser resueltos rpidamente en esta etapa. El L an a der tcnico del dominio debe e participar de la gestin de cada iteracin para asegurar que la priorizacin de probleo o o mas a resolver se mantiene acorde con las expectativas de usuarios sobre todo cuando es necesario modicar las prioridades iniciales. Tarea: Evaluar resultados Esta tarea consiste en la revisin de la iteracin para o o determinar el xito o fracaso de la misma, demostrando el valor agregado por el incremento e de solucin y registrando las lecciones aprendidas para poder mejorar el proceso en las o prximas iteraciones. o Como tiene lugar al nal de cada iteracin, esta tarea puede coincidir tambin con el o e cierre de la Fase. En este caso deber analizarse el cumplimiento o no del Hito correspona diente. En todos los casos, es importante que participen el Patrocinador, el L der tcnico de e dominio y el Representante de Usuarios de forma de garantizar que una conclusin de o xito o fracaso cuenta con el acuerdo expl e cito de la parte usuaria, garantizando que se avanza sobre terreno rme hacia la resolucin de necesidades y expectativas identicadas. o FASE DE ELABORACION En esta segunda Fase se busca comprender mejor los requerimientos del sistema, crear y establecer una l nea base de la arquitectura del sistema y mitigar los riesgos de mayor prioridad. Cada una de estas metas se vincula con alguna de las tareas incluidas en la Fase: Aumentar la comprensin de los requerimientos: Identicar y renar requerimientos o Disear, implementar y validar una l n nea base de arquitectura: Desarrollar la arquitectura, Desarrollar un incremento de solucin y Testear la solucin. o o Mitigar riesgos importantes: Planicar y gestionar la iteracin o En OpenUP/MMU-ISO N1 el Proceso de Despliegue de la Fase Elaboracin conserva la o conguracin bsica con varias actividades uyendo en paralelo, como muestra la iteracin o a o tipo representada en la Figura 7.36. Actividad: Identicar y renar requerimientos Es similar a la misma actividad en Fase de Inicio. Se modica el foco en esta fase, pero no se agregan ni cambian tareas u otros elementos de mtodo. e Dijimos antes que en esta Fase la Actividad cambia su foco desde el problema hacia la solucin. Se trata ahora de encontrar los requerimientos con mayor valor para los o involucrados, inclusive los que presentan mayor riesgo o compromiso hacia la arquitectura. Estos son los que deben ser priorizados e incluidos en las listas de Items de Trabajo para su implementacin en la fase. Para cada uno de estos requerimientos se deben denir los o Casos de Prueba asociados que permitirn validar las implementaciones. a La participacipacin del L o der tcnico del dominio y del Representante de usuarios e contribuye a aumentar el nivel de comprensin de los requerimientos y priorizar su ino clusin en la Lista de Items de Trabajo en sinton con las expectativas y reconocimiento o a de valor de los interesados. El diagrama de la Actividad se corresponde con el mostrado en la Figura 7.33.
7.3
147
Figura 7.36: Iteracin t o pica de Fase de Elaboracin con DCU o
Actividad: Desarrollar la arquitectura y experiencia de usuario Esta actividad intenta desarrollar y convertir en software funcional los requerimientos arquitectnicos que o se priorizaron para la iteracin y renar el modelo conceptual de la experiencia del usuario. o Se construye como una extensin de la Actividad:Desarrollar la arquitectura incluida en o OpenUP/Basic. Como muestra la Figura 7.37 la Actividad queda conformada por dos tareas: Renar la arquitectura y Dise ar la UX. n
Figura 7.37: Actividad: Desarrollar la arquitectura y la UX en OpenUP/MMU-ISO N1
Tarea: Renar la arquitectura La tarea que tiene por objetivo llevar el renamiento de la arquitectura al nivel suciente para dar soporte al desarrollo no tiene modicaciones en esta conguracin. En esta conguracin no hay cambios sobre la vero sin original. o
148
7.3
Tarea: Disear la UX en el contexto de esta actividad, sirve como complemento n de Renar la arquitectura para poner foco en la Experiencia de Usuario de manera global y mantener la visin de conjunto de alto nivel, extendida a todo el sistema. Mientras se o desarrolla a fondo un conjunto de pantallas y componentes, en el nivel general del sistema se continua renando los prototipos de diseo de Interaccion (prototipo, storyboard, mapa n de navegacion). Actividad: Desarrollar un incremento de solucin Esta actividad comprende las o tareas para disear, implementar, probar e integrar la solucin para el conjunto de ren o querimientos seleccionados para la iteracin. o La versin bsica de esta Actividad comprende cinco tareas realizadas en forma seo a cuencial por el Desarrollador: disear la solucin, Implementar test de desarrollador, Imn o plementar la solucin, Ejecutar test de desarrollador, Integrar y crear un build. o Todo incremento de solucin debe contener aspectos vinculados con la experiencia del o usuario, por lo tanto esta conguracin extiende esta Actividad con la inclusin de dos o o tareas de la Prctica Desarrollo Centrado en Usuario: a Tarea: disear componentes de interaccin Como vimos antes, esta tarea conn o siste en realizar las acciones necesarias para proponer y crear soluciones a los desaf os planteados por las diferentes especicaciones tcnicas vinculadas conla interaccin de e o usuario. Los productos de esta tarea (prototipos, storyboards o mapas de navegacin) o sirven a su vez como input para las tareas Disear la solucin e Implementar la solucin. n o o Por ejemplo, en puede ser que en una iteracin se diseen las soluciones a un conjunto o n de requerimietnos de interaccin, que en la prxima iteracin sern sujetos de las tareas o o o a vinculadas con el cdigo de software (disear/implementar la solucin) o n o Tarea: revisar el diseo de la experiencia del usuario Esta tarea busca dar n feedback rpido sobre los diseos de interaccin utilizando mtodos de inspeccin. Puede a n o e o combinarse con la tarea anterior, generando un conjunto slido de diseos para que emo n pleen como input los desarrolladores en la iteracin siguiente. o Con estas dos tareas, el detalle de la Actividad se muestra en la Figura 7.38 Actividad: Testear la solucin Esta actividad tiene el objetivo de evaluar la impleo mentacin de los requerimientos seleccionados para la iteracin, con dos tareas bsicas: o o a Implementar pruebas de software y Ejecutar pruebas de software. La extendemos para incluir las tareas espec cas de la Prctica Desarrollo Centrado en Usuario: Preparar a pruebas de usabilidad y Ejecutar pruebas de usabilidad, con la meta de obtener en forma inmediata a la implementacin de un conjunto de requerimientos el feedback de o usuarios nales sobre la experiencia de uso que puede obtenerse. Tarea: preparar pruebas de usabilidad A cargo del Tester de la Experiencia de Usuario, consiste en preparar los casos y datos necesarios para realizar las pruebas que involucren activamente a usuarios nales con el n de evaluar la satisfaccin de requerimo ientos y objetivos de usabilidad planteados para el proyecto. Esta tarea debe desarrollarse en sinton con la Tarea: disear la interaccin del a n o usuario. Es decir que una iteracin deber incluir para un mismo conjunto de requero a imientos, tanto el diseo de la interaccin que luego deber ser implementado por los n o a desarrolladores en una iteracin posterior, como el conjunto de pruebas de usabilidad a o ejecutar sobre tal implementacin. o
7.3
149
Figura 7.38: Actividad: Desarrollar un incremento de solucin o
150
7.3
Tarea: ejecutar pruebas de usabilidad Con el mismo responsable, el Tester de la UX, la tarea busca realizar en forma completa las pruebas preparadas en una iteracin o previa, analizar los datos obtendios y comunicarlos al equipo de trabajo. De esta forma, el nuevo detalle de la Actividad se muestra en la Figura 7.39 Actividad: Tareas continuas Esta actividad que habilita la realizacin de tareas que o no estn incluidas necesariamente en el cronograma o la planicacin del proyecto, pero e o que son necesarias para la buena marcha del mismo, no sufre modicaciones en cuanto a su conguracin bsica. o a Slo sealamos que si bien tarea que la compone (Tarea: Pedir cambios) puede ser o n llevada adelante por cualquiera de los roles intervinientes, es frecuente que lo haga alguno de los Stakeholders. Es habitual que desde este grupo de roles se generen pedidos de cambios y nuevos requerimientos (o modicaciones en la priorizacin de los mismos), o sobre todo a partir de los resultados de las pruebas de usabilidad y evaluaciones de tareas. Por esta razn es sumamente importante que todos los roles de Stakeholders (Patrocio nador, L der tcnico de dominio, Representante de usuarios, Usuario nal) tengan alguna e forma concreta de plantear estos pedidos para que sean formalmente considerados en el proceso. FASE DE CONSTRUCCION Esta fase se inicia luego de lograr el Hito de Elaboracin que indica que la arquitectura o ha alcanzado un nivel de estabilidad suciente para mantenerse sin cambios signicativos en el resto del proyecto, dando soporte slido a la implementacin de los requerimientos o o restantes. Este enfoque facilita sobre todo que el Gerente del Proyecto pueda enfocarse en optimizar la eciencia del equipo y reducir los costos del desarrollo, gracias a la limitacin de o los riesgos que implica una arquitectura estable. A lo largo de las iteraciones de esta fase la funcionalidad continuar siendo implemena tada, testeada e integrada. La fase puede incluir hacia el nal una o ms versiones beta. a El despliegue de versiones nales es el foco de la Fase siguiente, Transicin. o Una iteracin tipo en la Fase de Construccin incluye tres actividades espec o o camente orientadas a satisfacer el objetivo de completar la funcionalidad (Identicar y renar requerimientos, Desarrollar un incremento de solucin y Testear la solucin), mientras o o que las de gestin (Planicar y Gestionar la iteracin y Tareas continuas) se enfocan en o o mejorar la ecuacin de costos y aumentar el paralelismo en la medida de lo posible . o La Figura 7.40 muestra el ciclo de vida de una iteracin tipo de esta fase. o En la Conguracin de Nivel 1 para el MMU-ISO, las actividades que conforman esta o fase no requieren modicaciones respecto de las versiones que se han descripto para la Fase Elaboracin. Por esta razn no incluimos aqu mayores comentarios. En el Cap o o tulo 8 mostraremos la implementacin publicable de esta conguracin con el detalle de estas o o actividades en el plugin, de modo que pueda ser instanciado en un proyecto espec co haciendo uso de la variabilidad de extensin si eso fuera necesario. o FASE DE TRANSICION De acuerdo con la Prctica del Ciclo de vida riesgo-valor, la fase de Transicin se enfoca a o en desplegar el software a los usuarios y asegurar que sus expectativas son satisfechas. Sin embargo, en la versin bsica de OpenUP, el objetivo principal de la fase se reduce o a al ajute no de la funcionalidad, performance y calidad de la versin beta del sistema o generada al nalizar la fase de Construccin, sin incluir actividades espec o cas que son propias de la preparacin del despliegue tales como el test nal de aceptacin o el soporte o o del usuario (ver Cap tulo 4). La iteracin tipo propuesta por la conguracin bsica posee o o a
7.3
151
Figura 7.39: Actividad: Testear la Solucin o
152
7.3
Figura 7.40: Iteracin tipo de la Fase Construccin o o cuatro actividades: Desarrollar el incremento de solucin, Testear la solucin, Planicar o o y gestionar la iteracin y Tareas continuas. o Para superar esta carencia y dar cumplimiento al nivel inicial de capacidad del proceso ISO DCU 7, en la conguracin que estamos presentando, incluimos la tarea de la Prctica o a Desarrollo Centrado en Usuario Guiar y dar soporte al usuario en implementacin o dentro de la Actividad: Guiar implementacin y dar soporte al usuario. Tambin renamos o e la extensin de la Actividad: Testear solucin (realizada para las fases elaboracin y o o o construccin) incorporando el formato de Prueba de Aceptacin de Usuario como variante o o de las pruebas de usabilidad. El ciclo de vida de una iteracin tipo de la Fase Transicin para esta conguracin se o o o muestra en la Figura 7.41 Las actividades Desarrollar un incremento de solucin, Planicar y gestionar la ito eracin y Tareas continuas no sufren cambios respecto de lo comentado en las fases anteo riores. Actividad: Testear la solucin Esta actividad debe incluir en la Fase Transicin o o las pruebas de Aceptacin de usuario, indispensables para garantizar el acuerdo de los o usuarios con el producto a liberar. Las pruebas de aceptacin de usuario, cuya formalidad puede variar, implican coordio nar el trabajo de los testers de sistema y de la experiencia del usuario. Actividad: Guiar implementacin y dar soporte al usuario Esta actividad pero sigue la meta de desarrollar todo el material de soporte necesario (tutoriales, documentacin, ejemplos, etc.) sobre los requerimientos que representan el alcance la iteracin, o o para facilitar la apropiacin por parte de los usuarios nales del producto a entregar. o La Figura 7.42 muestra la composicin de la actividad. o Tarea: Producir material de entrenamiento y soporte al usuario El producido de esta tarea puede consistir en las versiones nales de los Documentos de Usuario,
7.3
153
Figura 7.41: Iteracin tipo de la Fase Transicin o o
Figura 7.42: Actividad: Guiar y dar soporte al usuario en implementacin o
154
7.3
en organizaciones pequeas o puede ser la base para que otros sectores de la organizacin n o realicen las tareas de edicin y produccin necesarias para entregar a usuarios. o o Tarea: Guiar y dar soporte al usuario en implementacin Esta Tarea se o llevar adelante en desarrollos de sistemas a medida, en organizaciones donde el equipo a de proyecto sea el encargado de la puesta en produccin e implementacin del producto. o o
7.3.2.
OpenUP/MMU-ISO N2
Para este Nivel 2 (Proceso gestionado) es necesario identicar atributos tanto de gestin de proceso como de gestin de producto respecto del DCU. En el primer cao o so, es importante generar los productos de trabajo dentro del tiempo establecido y los requerimientos de recursos. Respecto de los productos, interesa encontrar prcticas de a documentacin y control sobre los productos de trabajo para satisfacer los requerimientos o funcionales y no funcionales. Para el detalle completo de los atributos a identicar, ver el Apndice B e Estos atributos de gestin de proceso y de producto implican asegurar en el mtodo o e la presencia de contenido de Gestin de Cambios y Conguraciones y de Control de Calo idad. Como vimos antes, OpenUP/Basic ayuda a encontrar calidad mediante la Prctica a Desarrollo Iterativo (provee un feedback frecuente sobre la calidad), la incorporacin de o Templates y Checklists a modo de criterios de calidad para casi todos los productos de trabajo, la especicacin de tcnicas que contribuyen a la calidad en las Orientaciones y o e algunos elementos de QA en la Prctica Testing Concurrente. Sin embargo es necesario a extender estas ayudas espec camente con mtricas y evaluaciones sobre la calidad de los e procesos y productos DCU. Por otra parte, la Prctica Gestin Grupal de Cambios en la EPL describe el abordaje a o ms simple posible, que convierte a la gestin de cambios en parte de la Gestin de Proyeca o o to. Cualquier miembro del equipo puede requerir un cambio, que se registra en el backlog de pendientes. En la planicacin correspondiente el equipo revisa ese backlog, prioriza el o trabajo y decide qu cambios implementar. Sin distorsionar el carcter de bajo ceremonial e a y burocracia que exhibe OpenUP y a los efectos de conseguir una conformidad m nima con el MMU-ISO es necesario incluir algunas prcticas de Gestin de la Conguracin sobre a o o los productos y procesos DCU. Ya ha sido sealado en la Segunda ley de la evolucin del n o software que la entrop de un sistema de software crece continamente a menos que existan a pasos para controlarla [Humphrey 1989]. Si el diseo de las interacciones no se mantiene n bajo algn proceso de control, todos los cambios que se van generando durante el ciclo de u vida, aumentando la entrop del sistema van desviando progresivamente el producto de a las intenciones de los diseadores originales, provocando la progresiva degradacin de la n o experiencia de usuario. La conguracin que mostraremos aqu corresponde a una extensin de OpenUP/MMUo o ISO N1 que incorpora los elementos de mtodo y contenido necesarios para satisfacer e estos requerimiento, superando las carencias que identicamos en el Cap tulo 6 para que OpenUP/Basic pueda dar satisfaccin al Nivel 2 del MMU-ISO. o FASE DE INICIO Se modican dos Actividades sobre la conguracin anterior: Iniciar el proyecto y o Planicar y gestionar la iteracin. El resto del proceso se mantiene de acuerdo con o lo indicado para OpenUP/MMU-ISO N1 en las cuatro fases. Actividad: Iniciar el proyecto En esta actividad se ve afectada fundamentalmente la Tarea: Planicar el proyecto para establecer criterios de gestin sobre los elementos de o UX que sern utilizados en el proyecto. a
7.3
155
Tarea: Planicar el proyecto Deben denirse los criterios de performance y los productos de trabajo espec cos de DCU que se utilizarn en el proyecto, as como la a gestin de su calidad e integridad. Para mantener los lineamientos indicados en prrafos o a anteriores extendemos esta Tarea agregando dos pasos que aseguren la planicacion de la Gestin de Cambios, de la Conguracin y el Control de Calidad de todos los productos o o y tareas de DCU. Los pasos de la tarea en su versin base son: o Establecer un equipo cohesionado Estimar el tamao del proyecto n Evaluar los riesgos Estimar velocidad y duracin de proyecto o Diagramar el ciclo de vida del proyecto Establecer costo y articular valor Planicar el despliegue En esta conguracin agregamos dos pasos que nos aseguren la planicacin de la o o gestin DCU como lo pide MMU-ISO: o Planicar la calidad de la UX Consiste en denir un m nimo plan que haga previsible el aseguramiento de un m nimo de calidad en tareas y productos vinculados con la UX. Ser necesario denir los objetivos de calidad, los roles y las a responsabilidades, las tareas y cronograma. Las tcnicas espec e cas de evaluacin o de productos de trabajo, tales como Revisiones o Auditor Inspecciones y Recoras, ridas constituyen una forma poderosa de mejorar la calidad y productividad del proceso de desarrollo. Un Plan de Aseguramiento de Calidad es un un documento que contiene toda la informacin necesaria para realizar las tareas de aseguramiento o de calidad en el proyecto. Este plan deber contener el tipo de esfuerzo de evaluacin a o de calidad de productos que se utilizar en el proyecto: Revisiones, Inspecciones o a Recorridas. Tambin deben incluirse las mtricas de calidad que se emplearn, utie a lizando los parmetros habituales como cantidad de defectos, cobertura de pruebas, a performance, conformidad con estndares, aceptabilidad y satisfaccin. a o Planicar la Gestin de Conguracin y Cambios de la UX El propsito o o o de este paso es establecer las pol ticas de gestin de la conguracin a emplear en o o el proyecto para monitorear y salvaguardar los activos y para reforzar las buenas prcticas de desarrollo de software. Estas pol a ticas deber mejorar la comunicacin an o entre los miembros del equipo y minimizar los problemas encontrados cuando se integra su trabajo. Este Plan de la Gestin de Conguracin de UX deber contener al o o a menos la denicin de los elementos a mantener, las prcticas para establecer l o a neas base, las prcticas de archivado de activos y el ritmo de los reportes de conguracin. a o Actividad: Planicar y gestionar la iteracin Hemos visto que la gestin de proyeco o to en OpenUP se apoya entre otras en la Prctica de Planicacin en dos niveles. En el a o nivel macro, la extensin de la Tarea: Planicar el proyecto incluye los contenidos necesaro ios para este nivel de Capacidad del MMU-ISO. Debemos asegurar la consistencia con el nivel micro (la iteracin), por lo que vamos a proponer una extensin en el mismo sentido o o para la Actividad: Planicar y gestionar la iteracin. o
156
7.3
Tarea: Planicar la iteracin Necesitamos asegurar que las planicaciones en o este nivel micro acompaa las deniciones planteadas en el Plan de Proyecto, en particular n las relacionadas con la calidad de la UX y la conguracin y los cambios de los productos o que la proveen. Los pasos de la Tarea son: Priorizar la Lista de items de trabajo Denir los objetivos de la iteracin o Comprometer el trabajo para la iteracin o Identicar y revisar riesgos Denir criterios de evaluacin o Renar la denicin y alcance de proyecto o La extensin que se propone no agrega nuevos pasos, sino que redene algunos para o asegurar que el nivel micro de planicacin se mantiene en l o nea con lo establecido para el nivel macro. Todos los pasos que toman como insumo la Lista de items de trabajo y la reordenan o comprometen trabajo para la iteracin deben tener en cuenta los criterios de gestin del o o cambio de la UX que se establecieron en el Plan de Proyecto. Esto nos obliga a modicar las deniciones de los pasos: Priorizar la Lista de Items de Trabajo, Denir objetivos de iteracin, Comprometer trabajo para la iteracin y Renar la denicin y alcance de o o o proyecto. En la denicin de los criterios de evaluacin (paso 5), deben jarse las pautas de o o calidad esperables de los productos relacionados con la experiencia de usuario. Este paso debe asegurar la referencia de cualquier criterio y actividad vinculada con la calidad que se estableza para la iteracin presente con el Plan de Calidad denido en el Plan de Proyecto. o Tarea: Gestionar iteracin Es el mbito para monitorear las mtricas de usabilo a e idad, el nivel de calidad de prototipos y los otros productos DCU que se haya decidido incluir en el proyecto, tanto en tiempos de realizacin como en calidad y cantidad de o revisiones con usuarios Los pasos de la tarea son: Rastrear el progreso de la iteracin o Capturar y comunicar el estado del proyecto Manejar excepciones y problemas Identicar y administrar riesgos Administrar objetivos No se proponen cambios en los pasos de la Tarea, pero se modica la Orientacin o Asignar Cambios a una Iteracin para incluir expl o citamente la consideracin del Plan o de Gestin de Cambios y Conguracin de UX en el proceso de revisin, priorizacin de o o o o cambios en la iteracin actual y su asignacin en una futura. o o Se modican las Consideraciones Claves de la Tarea para incluir en la recoleccin de o mtricas a monitorear las que se hayan denido en el Plan de Proyecto para la Gestin e o de Calidad de la UX.
7.3
157
Tarea: Evaluar resultados Esta tarea es clave del ciclo DCU y para asegurar la gestin tanto de sus procesos como de sus productos. En el Nivel 1 ya incorporamos la o participacin del rol Representante de usuarios, en este segundo nivel no modicamos. o La tarea se compone de los siguientes pasos: Preparar la evaluacin de la iteracin o o Demostrar valor y obtener feedback Realizar una retrospectiva de n de iteracin, n de fase o n de proyecto o No es necesario modicar esta denicin. Slo deben respetarse en cada paso las prctio o a cas sobre gestin de procesos y productos de DCU denidas en los Planes de Proyecto y o de Iteracin. o FASES DE ELABORACION, CONSTRUCCION, TRANSICION En las Fases posteriores al Inicio, las prcticas de gestin de procesos y productos DCU a o se completa respetando en la Tarea Pedir un Cambio el proceso de gestin de cambios o denido en los planes. Esta tarea forma parte de la Actividad: Tareas continuas y cualquiera de los roles puede disparar un pedido de cambio en OpenUP, como vimos en el Cap tulo 4. La denicin o base de la Tarea consta de dos pasos: Obtener la informacin del pedido y Actualizar la o lista de items de trabajo. El resto de la gestin del cambio queda incorporado en las tareas de Gestin de Ito o eracin con las modicaciones que incorporamos en la Fase de Inicio. o
7.3.3.
OpenUP/MMU-ISO N3
Para el Nivel 3 del MMU-ISO (Proceso establecido) es necesario asegurar el despliegue de un proceso que est denido no slo en las prcticas bsicas de DCU y una gestin e o a a o ordenada de su proceso y sus productos, sino en los buenos principios de ingenier de a software en general. Entonces debemos poder reconocer atributos del proceso que estn e relacionados con su misma denicin (adaptar los procesos estndar a las situaciones o a espec cas del proyecto) y con la determinacin de los recursos que sern necesarios para o a llevarlo adelante. Es decir, no se trata de gestionar bien un proceso y unos recursos dados. Se trata de denir en forma adecuada y basada en buenos principios, la mejor estructura para el proceso y los recursos que sern necesarios para ejecutarlo. a Al igual que en la conguracin anterior, OpenUP/MMU-ISO N3 se construye de o manera incremental sobre N2, agregando todos los elementos del mtodo que puedan dar e lugar a instanciaciones que cumplan con lo expresado en el prrafo anterior. a Para el detalle de los atributos de denicin del proceso y de los recursos ver el o Apndice B. e Las carencias a suplir, segn el assessment realizado (ver Cap u tulo 6) son la falta de prcticas para denir el mejor proceso para el proyecto y establecer los recursos necesarios a en todos los procesos DCU del MMU-ISO. Esto se ver reejado fundamentalmente en la a presencia de extensiones en actividades como la Preparacin del Proyecto y la Planicacin o o y Gestin de cada iteracin. o o FASE DE INICIO Actividad: Iniciar el Proyecto En esta Actividad agregamos la Tarea: Adaptar el proceso DCU, para realizar al inicio del proyecto la adaptacin y conguracin de todo el o o proceso de acuerdo con las necesidades espec cas del proyecto. El resto de la Actividad
158
7.3
es igual a la Conguracin N2, con las Tareas de Desarrollar la Visin y Planicar el o o Proyecto. Tarea: Adaptar el proceso DCU Esta tarea se alimenta de la Conguracin que o aqu mostramos y, de existir, podr tener en cuenta los reportes de la organizacin respecto a o del estado actual de sus procesos de desarrollo, herramientas, recursos, etc. Ya describimos en este mismo Cap tulo el alcance de la tarea que consiste bsicamente en analizar el a proyecto, determinar el esfuerzo de adaptacin que se justica para el proyecto, congurar o el proceso adecuado incluyendo el ciclo de vida DCU dentro del mismo y publicarlo para que todos los integrantes del equipo lo conozcan. Durante el proyecto, en las tareas de la Actividad: Planicacin y Gestin de la Iteracin se llevar a cabo el mantenimiento o o o a del proceso denido, con las correcciones que sean necesarias en funcin del devenir del o proyecto. En consecuencia, el detalle de esta Actividad queda como se muestra en la Figura 7.43
Figura 7.43: Detalle de la Actividad: Iniciar el Proyecto en OpenUP/MMU-ISO N3
Actividad: Planicar y gestionar la iteracin Adems del nivel macro de Proyecto, o a en el nivel micro de cada Iteracin tambin debe haber una gestin de la adaptacin o e o o realizada al proceso de desarrollo.
7.3
159
Tarea: Planicar la iteracin Se extiende con un paso para incorporar las moo dicaciones de proceso que puedan ser sugeridas por la tarea de Evaluar resultados. Paso: Actualizar el proceso Incorporar las modicaciones de proceso sugeridas por la ultima retrospectiva. Tarea: Gestionar la iteracin o Sin cambios respecto de OpenUP/MMU-ISO N2.
Tarea: Evaluar resultados En esta tarea se incorpora un cuarto paso denominado Monitorear el proceso cuando se realiza esta tarea coincide con la retrospectiva: Paso: Monitorear el proceso Analizar el impacto (positivo o negativo) que las adaptaciones incoporadas en el proceso han tenido en el desarrollo de la iteracin y proponer cambios en caso de ser necesario. o FASES DE ELABORACION, CONSTRUCCION, TRANSICION Los procesos y mtodos de estas Fase no sufren otros cambios en el Nivel 3. Las e actividades de planicacin y gestin que se detallaron para la Fase Inicio se realizan con o o la misma denicin. o
160
7.3
Cap tulo 8
OpenUP/MMU-ISO como plugins del EPF Composer

8.1. El EPF Composer
El Eclipse Process Framework Composer (EPF Composer o simplemente Composer, en el resto del Cap tulo) es una plataforma de herramientas para ingenieros de procesos, l deres y gerentes de proyecto responsables de mantener e implementar procesos para organizaciones que desarrollan software. Durante la implantacin de un proceso de desarrollo es necesario resolver dos cueso tiones. Por un lado, que todos los desarrolladores conozcan y entiendan las prcticas a claves del proceso de desarrollo y fundamentalmente de qu manera un equipo de trabajo e las adapta a sus particularidades (aunque los mtodos giles se basen en grupos autoe a organizados, esto no habilita a asumir que todos conocen cmo encara una organizacin o o concreta las tareas de elicitacin de requerimientos, diseo, construccin, testing, etc.). El o n o otro tema se relaciona con la inclusin de esas prcticas en el ciclo de vida completo del o a proyecto. El Composer intenta satisfacer ambas necesidades proveyendo el contenido completo de la Librer de Prcticas del EPF (la EPL que ya describimos en cap a a tulos anteriores) y una herramienta para seleccionar, customizar, ensamblar y publicar partes de esa Librer a como un proceso espec co adecuado a las particularidades de un equipo. El Composer provee catlogos de procesos predenidos para situaciones t a picas de proyectos y los procesos de despliegue (bloques de construccin de procesos que representan las mejores o prcticas de desarrollo para una disciplina, tecnolog o estilo de desarrollo espec a a cos). Estos bloques forman una caja de herramientas para ensamblar rpidamente los procesos a para un proyecto en particular. El Composer tambin permite establecer procesos de dee spliegue propios de una organizacin y publicar todo como sitios web, para dar acceso al o equipo de trabajo. El escenario de uso ms simple del Composer consiste en utilizar las prcticas de la EPL a a y los procesos de despliegue del EPF tal como vienen dados. Sin embargo, habitualmente una organizacin necesita slo un subconjunto de esos elementos. Probablemente, adems, o o a ser necesario incluir elementos propios y vincularlos con los existentes. Esto da lugar a a diferentes escenarios de autor y conguracin con el Composer, que describimos a a o continuacin. o El Composer es una herramienta gratuita, desarrollada dentro del entorno ECLIPSE. No slo permite editar fragmentos de mtodo, procesos o metodologas, sino tambin genero e ar automticamente la documentacin adecuada en formato para la web. La Figura 8.1 o muestra la pantalla de edicin de una Tarea dentro del Composer. Dichos fragmentos o 161
162
Plugins del EPF Composer
8.1
se almacenan en formato XMI y, al estar basados en la UMA (cuyo metamodelo es el estndar SPEM 2), pueden ser reutilizados por otras herramientas CASE. El Composer a resulta entonces un editor de procesos SPEM 2, que incluye opciones adicionales para publicar de forma automticamente sitios web.
Figura 8.1: Pantalla de edicin de una Tarea en el Composer o
Organizacin del repositorio de mtodos y procesos en Composer o e

El repositorio o biblioteca de mtodos y procesos es una coleccin de uno o ms e o a plugins y una o varias conguraciones. Cada plugin se almacena en un directorio de disco diferente e incluye contenido de mtodo y de procesos. A su vez, el Contenido de Mtodo e e est formado por paquetes de contenido, categor estndar y categor personalizadas. a as a as La rama de Procesos contiene patrones de proceso o entrega y procesos para despliegue. La Figura 8.2 muestra la estructura mencionada. En el Cap tulo 4 describimos en detalle los diferentes elementos que pueden poblar el Contenido de Mtodo (Tareas, Roles, Productos de trabajo, Orientaciones) y los Procesos e (Elementos de desglose, Actividades) y las relaciones de asociacin entre ellos. o
Reuso y variabilidad
La organizacin en plugins facilita la reutilizacin de los elementos de contenido y o o proceso denidos en la biblioteca, mediante la referencia de un plugin nuevo a otros existentes. Para permitir esta reutilizacin el Composer ofrece el mecanismo de variabilidad que o permite modicar elementos de mtodo o de proceso sin tocar el original, deniendo las e diferencias (agregados, cambios, omisiones). Describimos a continuacin las opciones de o variabilidad que brinda el Composer y que utilizamos luego en la construccin de nuestros o plugins.
8.1
El EPF Composer
163
Figura 8.2: Estructura de organizacin del repositorio en el Composer o Variabilidad de Elementos de Contenido El Composer incluye los cinco tipos previstos para elementos de contenido en SPEM 2.0: No aplicable, Contribuye, Extiende, Reemplaza y Extiende y reemplaza: No aplicable Es el valor por defecto. No hay relacin de variabilidad entre el elemento o en cuestin y otros. o Contribuye Un elemento E que contribuye a un elemento base EB aade sus valores de n atributos e instancias de asociacin a EB sin modicar directamente las propiedades o que ya tiene EB (es un agregado). Al generar una vista el elemento base EB se muestra combinado con los atributos y relaciones de E, mientras que E queda oculto. Reemplaza Un elemento E puede reemplazar los atributos y asociaciones de salida de un elemento base EB sin modicar directamente ninguna propiedad de EB. El elemento E que reemplaza se inluir en las vistas generadas mientras que el reemplazado EB a no aparecer. a Extiende El elemento E hereda las propiedades del elemento base EB que extiende, dejando EB totalmente intacto. El elemento E incluye las propiedades heredades de EB ms las propias. Tanto EB como E aparecen en las vistas generadas. a Extiende y reemplaza esta variabilidad combina los efectos de Extiende y de Reemplaza. El resultado es que las propiedades que no se han denido en E que extiende y reemplaza se heredan del elemento base EB. En cambio, las propiedades denidas en E sustituyen a las de EB. E aparece en las vistas que se generan, pero EB no. Este tipo de variabilidad se utiliza al generar plugins que renombran elementos, reemplazan descripciones, etc. sin remodelar completamente todas las relaciones y atributos del plugin base. Variabilidad de Elementos de Proceso Los elementos de proceso de tipo actividad (fase, iteracin, actividad, patrn de proo o ceso) se pueden reutilizar en otros elementos de proceso ms grandes. En este caso reciben a el nombre genrico de Actividad en uso. Una Actividad en uso dene la habilidad para e
164
8.2
reutilizar las estructuras denidas en los elementos de desglose de una actividad en una segunda actividad, sin necesidad de copiar f sicamente dichas estructuras. Los mecanismos de variabilidad previstos en Composer para los procesos son: No aplicable Cuando una actividad no tiene asociaciones de Actividad en uso. Extensin Una actividad extendida A hereda la estructura interna (subestructuras e o instancias de asociacin) de una actividad base AB. Se pueden anuevos elementos de o desglose a A, pero no se pueden modicar los elementos de desglose heredados desde AB. Los cambios realizados en A no afectan a AB. Las modicaciones realizadas en AB con posterioridad se reejan automticamente en A y en las dems actividades a a en uso que extienden AB. Contribucin local Sirva para denir adiciones locales espec o cas (contribuciones) a los elementos de desglose heredados v la extensin del tipo anterior. a o Reemplazo local de forma similar al anterior sirve para denir sustituciones locales espec fcias (reemplazos) a los elementos de desglose heredados v la extensin. a o Adems los elementos de proceso de tipo actividad (fase, iteracin, patrn de proceso) a o o permiten variabilidad de los tipos con las mismas caracter sticas explicadas para elementos de contenido: Extiende, Contribuye, Reemplaza.
8.2.
El uso del Composer
Crear contenido de mtodo e

Tal como vimos en el Cap tulo 7 el primer paso es crear los elementos de contenido que luego se utilizarn en la creacin de procesos. En el Composer, los elementos de contenido a o se pueden organizar y jerarquizar mediante la creacin de paquetes de contenido, dentro o de los cuales pueden denirse las tareas, roles, productos de trabajo y orientaciones. La especicacin de los atributos de estos elementos se realiza en la solapa Descripcin del o o editor del elemento. Para cada tipo de elemento, Composer ofrece un conjunto de solapas que permite denir adems las relaciones de ese elemento con otros y previsualizar el a contenido nal a exhibir (ver gura 8.3).
Crear Procesos
Despus de denir los elementos de contenido de mtodo, stos se pueden reutilizar e e e para crear procesos. El Composer habilita la creacin de dos tipos de procesos SPEM 2: los o Patrones de proceso o capacidad (capability patterns) que desriben una agrupacin o reutilizable de tareas o actividades y los Procesos de despliegue (Delivery process) que describen un enfoque completo e integrado para una metodolog completa, un tipo de a ciclo de vida, tipo espec co de proyecto, etc. Al igual que los elementos de contenido, los patrones de proceso y los procesos de despliegue se pueden organizar y jerarquizar mediante paquetes de proceso. La Figura 8.4 muestra a la izquierda, en la ventana de Librer la organizacin de Patrones de Capacidad a o y Procesos de Despliegue para el plugin OpenUP/MMU-ISO Nivel 1 (que presentamos en detalle ms adelante) y a la derecha la WBS o Estructura de Desglose del Ciclo de Vida a de dicho proceso. Para representar estos procesos se emplean estructuras de descomposicin o desglose, o mediante las cuales se representa la jerarqu de actividades e hitos y se ordena el ujo a de trabajo indicando relaciones de precedencia entre los elementos de la estructura. Para ver y editar desde diferentes puntos de vista la estructura de desglose de un proceso/metodologa completo o de un fragmento, el Composer incluye las siguientes solapas:
8.2
El uso del Composer
165
Figura 8.3: Creacin de un Rol dentro del Paquete de Contenido de Mtodo o e
Figura 8.4: WBS del Ciclo de Vida OpenUP/MMU-ISO Nivel 1
166
8.2
Estructura de Desglose de Trabajo (Work Breakdown Structure): Corresponde al conocido WBS de gestin de proyectos. En el Composer es una tabla que contiene o la descomposicin jerrquica de los elementos que denen el trabajo a realizar: aco a tividades (patrones de proceso, fases, iteraciones), hitos, tareas, etc. Un ejemplo se muestra en la parte derecha de la Figura 8.4 Asignacin de Equipos (Team Allocation): Muestra una jerarqu similar a la anterio a or, pero mostrando para cada actividad (cada nivel) la lista de roles que participan. Utilizacin de Productos de Trabajo (Work Product Usage): Esta perspectiva se o centra en los productos de trabajo de forma similar a como la anterior se centra en los roles. Vista Consolidada (Consolidated View ): Combina las informaciones que se muestran en las tres vistas anteriores. Solo existe con nes informativos, es decir, no permite edicin. Es similar a la Previsualizacin para los elementos de contenido. o
Crear conguraciones
Una conguracin de mtodo es una seleccin de contenidos de los plugins de una o e o librer de forma que se limita la vista de la librer al subconjunto seleccionado. a, a En una conguracin se seleccionan los paquetes y procesos que queremos incluir. La o seleccin de elementos incluidos se puede renar aadiendo o sustrayendo de la conguo racin todos los elementos categorizados en una misma categor o a. Las conguraciones de mtodo permiten denir qu elementos aparecern en la web e e a publicada y cules no. Tambin permiten seleccionar los elementos que son visibles para a e los procesos creados. Ofrecen una alternativa en la creacin de procesos, ya que puede o denirse un proceso general que incluya contenidos para varios tipos de procesos ms a espec cos. Mediante el uso de conguraciones se seleccionan los contenidos de cada uno de esos tipos de procesos ms espec a cos. Crear los diversos tipos de proyecto es sencillo seleccionando la conguracin adecuada para el proceso. o La creacin de conguraciones se hace desde la vista Biblioteca. Para especicar el o contenido de una conguracin y renar dicha seleccin se siguen los siguientes pasos en o o la solapa Seleccin de paquete y plug-in del editor de la conguacin: o o 1. Seleccionar los plug-ins que nos interesen para la conguracin. o 2. Seleccionar los paquetes de contenido y los procesos de los plug-ins seleccionados que nos interesen en la conguracin. o 3. Renar la seleccin utilizando las categor que se incluirn y las categor que se o as a as sustraern de la conguracin. De esta forma se pueden incluir o no conjuntos de a o elementos relacionados de forma lgica en vez de por estar relacionados de forma o f sica (estar incluidos en el mismo paquete). En una conguracin de mtodo, adems de seleccionar los contenidos de la conguo e a racin, podemos seleccionar las vistas de la conguracin. Las vistas son, bsicamente, cao o a tegor que agrupan los contenidos de la conguracin. Estas vistas son utiles al publicar as o la conguracin, ya que se generarn rboles de navegacin con los elementos denidos o a a o en la vista mediante los que explorar el contenido de la conguracin. Este concepto no o aparece en el estndar SPEM, es un aadido del Composer. a n
8.3
Plugins lgicos y f o sicos en la EPL
167
Publicar contenidos
La publicacin de una conguracin consiste en la generacin de un sitio web que o o o contiene los elementos de la conguracin. El Composer ofrece opciones para personalizar o el sitio a publicar, modicando los elementos a publicar (t tulo, glosario, ndice, diagramas, etc.) y para validar automticamente los enlaces y pginas generados. a a El sitio a generar puede ser esttico, como un conjunto de pginas HTML organizadas a a en carpetas, o como una aplicacin web EE de Java empaquetada en un archivo tipo .war, o para desplegar en un servidor que soporte Servlets. La Figura 8.5 muestra un ejemplo de un sitio web generado con el Composer.
Figura 8.5: Ejemplo de sitio web generado con Composer
8.3.
Para asegurar que los plugins dentro de la EPL se comportan adecuadamente juntos y maximizar el reuso de elementos, el EPF describe algunos tipo espec cos de plugins. La intencin es facilitar la distribucin en la generacin de contenidos de mtodos y o o o e aumentar la capacidad de plug-and-play de los mismos. Para ello, los plugins separan a reas de concern siguiendo una estructura de empaquetado consistente. La Figura 8.6 resume los tipos de plugins lgicos que se denen en la EPL y las o dependencias permitidas entre ellos. Como veremos ms adelante y muestra la Figura 8.7 a cada uno de ellos puede ser representado por varias partes f sicas de plugin.
Tipos principales de plugin

Los plugins Core, contienen elementos dirigidos a ser compartidos entre otros plugins en el framework. Brindan la base del framework y permiten su reutilizacin mediante o otros elementos como prcticas y procesos. Incluyen elementos que sirven de interfaz entre a prcticas (Slots de Productos de Trabajo) y elementos reusables claves como productos a de trabajo u orientaciones que deben ser compartidas por varias prcticas. a Los plugins de Prctica contienen los elementos de una prctica en particular. Existe a a un plugin por prctica. Slo dependen de los plugins Core. a o
168
8.3
Figura 8.6: Tipos de plugins en EPL y relaciones entre ellos Los plugins de Proceso contienen los elementos que denen procesos transversales a varias prcticas y que deben compartirse entre las conguraciones (los procesos que a son espec cos de una prctica son contenidos en los plugins de Prctica y los que son a a espec cos de una conguracin en plugins de Publicacin). Los procesos cross-prctica o o a se ensamblan con elementos contenidos en plugin de Prctica (tareas o procesos). Puede a haber varios plugins de proceso. Pueden depender de plugins Core (para los elementos compartidos), de Prctica (para elementos espec a ficos de una prctica) y de Proceso (para a procesos compartidos). Los plugins de Publicacin contienen elementos de mtodo que son unicos a una o e conguracin espec o fca que ser publicada. Por ejemplo, vistas de navegacin, hojas de a o ruta, etctera. e
Subtipos de plugin Core

Existen varios elementos que son compartidos por todo el framework y por lo tanto se incluyen en los plugins Core. Sin embargo, algunos de ellos necesitan ser reutilizados en forma independiente. Por ejemplo, cuando se comparten las deniciones de herramientas, pero se necesita crear nuevas deniciones de categor Para ello se agregan los subtipos as. de plugin Core Los plugins Slot contienen deniciones de Slot de Productos de Trabajo y las orientaciones asociadas. Los plugins Comunes contienen los elementos reutilizables como productos de trabajo u orientaciones para compartir entre plugins. Los plugins de Deniciones de Rol contienen los roles o conjunto de ellos para compartir entre prcticas. No contiene asignaciones de esos roles a productos de a trabajo o tareas ya que el framework utiliza el concepto de Asignacin diferida. o
8.3
169
Los plugins de Denicin de categor contienen denciones de disciplina, doo a minio, clase de producto de trabajo y conjunto de roles. Los plugins de Denicin de herramientas denen las herramientas y mentores o para su uso. Los plugins de Denicin de vistas y navegacin presentan las deniciones de o o vistas para publicar conguraciones. Los plugins de Derecho de copia de release presentan los elementos sobre derechos de copia para la release. Cada plugin deber tener un plugin de este tipo a asociado.
Partes de plugins
Para aumentar la congurabilidad y navegabilidad de la EPL, este concepto de partes permite que cada tipo de plugin se implemente en la prctica como uno o ms plugins a a f sicos. La Figura 8.7 muestra las partes de plugin y sus relaciones. En este diagrama [Plugin X], [Plugin Y] y [Plugin Z] representan plugins lgicos. o
Figura 8.7: Partes de un plugin y sus relaciones Los plugins Base contienen las deniciones bsicas de los elementos de mtodo del a e plugin lgico. Un plugin lgico tiene slo uno Base. Estos pueden depender de otro Base o o o (estas dependencias representan las dependencias entre los plugins lgicos). o Los plugins De extensin contienen elementos que extienden o ampl los elemeno an tos del Base. Un plugin lgico puede carecer de plugins Extiende o tener varios. Estos o dependen de los Base que contienen los elementos a extender. Los plugins De asignacin contienen las asignaciones de los elementos de mtodo en o e un plugin Base o Extiende cuando es soportada la asignacin diferida. Un plugin lgico o o
170
8.4
puede carecer o tener varios de los plugins Asigna. Estos dependen del Base o Extiende que contiene las dencionesde los elementos asignados. Al igual que con los plugins lgicos, los principales benecios de esta organizacin o o f sica son la separacin de concerns entre lsa deniciones de los elementos base del mtoo e do, lsa extensiones de esas deniciones y su asignacin diferida, la facilidad para denir o asignaciones alternativas y la facilidad para generar conguraciones mediante seleccin de o elementos.
8.4.
La familia de plugins OpenUP/MMU-ISO
En el Cap tulo anterior presentamos la propuesta de extensin de la EPL y de la o conguracin OpenUP/Basic para dar soporte a procesos de desarrollo que se basen en el o Proceso Unicado y que resulten conformes al Modelo de Madurez de usabilidad ISO. Organizamos estas extensiones en cuatro plugins lgicos que corresponden a cada una o de esas extensiones: Un plugin del tipo Prctica que contiene las deniciones del contenido de mtodo a e de la prctica (tareas, productos de trabajo y roles) DCU detallados en el cap a tulo 7. Un plugin del tipo Publicacin para la Conguracin OpenUP/MMU-ISO N1: o o extiende la conguracin OpenUp/Basic para incorporar los elementos de la Prctica o a DCU de manera de poder instanciar un proceso que resulte conforme al MMU-ISO en el Nivel 1 de capacidad o madurez. Un plugin del tipo Publicacin para la Conguracin OpenUP/MMU-ISO N2: o o extiende la conguracin OpenUP/MMU-ISO N1 para llevar el proceso al Nivel 2 o de capacidad o madurez en el MMU-ISO. Un plugin del tipo Publicacin para la Conguracin OpenUP/MMU-ISO N3: o o de forma similar al anterior, extiende la conguracin OpenUP/MMU-ISO N2 para o permitir la implementacin de un proceso de Nivel 3 en el MMU-ISO. o Cada uno de estos plugins lgicos es implementado en el Composer como un conjunto o de partes o plugins f sicos, siguiendo las gu sealadas en la seccin anterior. A contias n o nuacin describimos la composicin de las partes f o o sicas que componen cada uno de estos plugins lgicos. o
8.4.1.
El plugin de la Prctica DesCU a
El plugin de la Prctica DesCU se agrega en el rbol de plugins del Composer como a a muestra la Figura 8.8 dentro de las prcticas tcnicas, junto otras como testing concura e rente, desarrollo centrado en casos de uso, integracin continua, etc. o Este plugin lgico est implementado como dos plugins f o a sicos uno de Base y otro de Asignacin, como se indica en la Figura 8.9. El primero contiene las deniciones bsicas o a de Tareas, Productos de Trabajo, Roles y Orientaciones. Tambin se incluirn en l las e a e Orientaciones relacionadas con derechos de copia y la categorizacin de los elementos o denidos. Las asignaciones de los Roles a las Tareas y los Productos de trabajo se ubican en el segundo plugin f sco. La denicin de la Prctica DesCU en el Cap o a tulo 7 no incluye procesos propios (ni patrones de capacidad, ni procesos de entrega) de modo que slo aparecen en estos plugins o elementos de contenido de mtodo. e
8.4
171
Figura 8.8: Ubicacin del Plugin Prctica DCU en Composer o a
Figura 8.9: Plugines f sicos de la Prctica DCU en Composer a
172
8.4
El plugin Base En la Figura 8.10 se muestra la organizacin interna del plugin Base (practice.tech.deo sarrollo centrado usuario.base) El plugin Base se apoya en las deniciones compartidas para todas las prcticas de la a EPL, en particular en los siguientes plugins y sus elementos que se indican: core.default.cat def.base: provee las deniciones de Dominios y Disciplinas (arquitectura, desarrollo, gestin de proyecto, testing, requerimientos). o core.default.role def.base: provee las deniciones de los Roles bsicos de la a EPL (analista, arquitecto, desarrollador, gerente de proyecto, stakeholder, tester, rol genrico). core.default.tool def.base: provee el conjunto de herramientas bsicas para las a prcticas, que consiste en tres orientaciones sobre el uso del Composer y la persona alizacin de mtodos. o e core.default.uma concept.base: contiene las deniciones bsicas para comprena der la estructura de un proceso y navegarlo de acuerdo con la Unied Method Architecture. core.gen.common.base: dene productos de trabajo y orientaciones genricos para e ser utilizados por todas las prcticas (como el glosario). a core.mgmt.slot.base: donde se ubican las deniciones de Slots de Productos de Trabajo (denicin y alcance de proyecto, riesgo de proyecto, trabajo de proyecto, o estado de proyecto) y Orientaciones de gestin (orientacin para la planicacin, o o o orientacin para la asignacin y orientacin para la colaboracin). o o o o core.tech.common.base: contiene deniciones tcnicas provistas por IBM que exe tienden el contenido open source de la EPL. core.tech.slot.base:dene los Slots de Procutos de Trabajo (arquitectura, diseo, n implementacin, especicacin y resultados de prueba) y Orientaciones tcnicas (orio o e entacin para diseo, orientacin para pruebas). o n o La organizacin de los componentes en el Plugin Base, tal como se muestra en la o Figura 8.10, consiste en dos paquetes de Contenido de Mtodo, denominados Common y e Release info siguiendo las gu de estilo de la EPL. En el primer paquete se agrupan las as deniciones de Tareas, Productos de Trabajo, Roles y Orientaciones. En el segundo, los contenidos sobre versiones de la Prctica. a En el paquete Common, organizados en el conjunto de Roles DCU, se incluye la denicin de los siete roles de la Prctica: Diseador de la UX, Especialista de UX, Tester de o a n UX, Patrocinador, L der tcnico de dominio, Representante de Usuarios y Usuario nal. e En el Cap tulo 7 todos se denen como subtipos de alguno de los roles bsicos. Para a implementarlo, utilizamos las opciones de variabilidad de contenido que ofrece la EPL. Los seis primeros utilizan la variabilidad Extiende, en el caso del Usuario Final el plugin hace uso de la variabilidad Extiende y reemplaza tal como se muestra en el diagrama de la Figura 8.11. Para las deniciones de cada rol utilizamos las descripciones, habilidades y detalles incluidos en el cap tulo 7 tal como se muestra en las guras 8.12 y 8.13 para el Diseador n de la UX y el Tester de la UX. En la Prctica DesCU se denen estos productos de trabajo propios: Modelo de usuario, a Meta de usabilidad, Modelo de tareas, Concepto de UX, Prototipo de Experiencia de Usuario, Storyboard de Experiencia de Usuario, Mapa de Navegacin, Documento de o
8.4
173
Figura 8.10: Estructura interna del plugin Base en la Prctica DCU a
Figura 8.11: Relacin entre roles bsicos de EPL y roles de DCU o a
174
8.4
Figura 8.12: Descripcin de Diseador de UX o n
Figura 8.13: Descripcin de Tester de UX o
8.4
175
Usuario. Los ocho estn incluidos en el Plugin Base, cada uno identicado con un Slot de a Producto Tcnico (ver Tabla 8.1) e Producto de trabajo Slot Meta de usabilidad Especicacin tcnica o e Modelo de usuario Especicacin tcnica o e Modelo de tareas Especicacin tcnica o e Concepto de UX Diseo tcnico n e Prototipo de UX Diseo tcnico n e Storyboard de UX Diseo tcnico n e Mapa de navegacin o Diseo tcnico n e Documento de usuario y entrenamiento Documentacin de usuario o Tabla 8.1: Relacin entre Productos de Trabajo y Slots o A partir de estos Productos de Trabajo es necesario incluir las Tareas que los manipularn ya sea en condicin de input o output. En la Figura 8.14 se muestra el listado a o completo en el rbol de Contenido de Mtodo del plugin y la Tabla 8.2 su distribucin por a e o Disciplina. Como se observa en esta tabla, es necesario incorporar una disciplina ms al a conjunto bsico provisto por la EPL. Se trata de la Disciplina Despliegue que contiene las a actividades necesarias para hacer disponible al sistema para los usuarios (instalaciones, material de entrenamiento, capacitaciones, etc.).
Figura 8.14: Deniciones de Tarea incluidas en el Plugin Base de la Prctica DCU a Todas las deniciones utilizan los contenidos incluidos en el Cap tulo 7. Como ejemplo, en las Figuras 8.15, 8.16, 8.17, 8.18 y 8.19 se presentan las solapas de Descripcin, Pasos, o Productos de Trabajo, Categor y Previsualizacin para la Tarea Entender y especicar as o el contexto de uso. El Plugin Base se completa con la Orientacin que presenta la Prctica, con su deo a scripcin completa (Propsito, Metas, Background, Niveles de Adopcin) y los elementos o o o articulados por la misma.
176
8.4
Figura 8.15: Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Descripo cin o
Figura 8.16: Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Pasos o
8.4
177
Figura 8.17: Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Produco tos de Trabajo
Figura 8.18: Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Previo sualizacin o
178
8.4 Disciplina Gestin de proyecto o Arquitectura Desarrollo Despliegue Testing Requerimientos Requerimientos Despliegue Testing Arquitectura Desarrollo
Tarea Adaptar el Proceso DCU Disear la UX n Disear componentes de interaccin n o Disear y producir material de entrenamiento y soporte de usuario n Ejecutar pruebas de usabilidad Entender y especicar el Contexto de Uso Especicar requerimientos y objetivos de UX Guiar y dar soporte al usuario en implementacin o Preparar pruebas de usabilidad Renar el modelo de UX Revisar el diseo de UX
Tabla 8.2: Relacin de las Tareas en Prctica DCU y las Disciplinas de la EPL o a El plugin Assign Como dijimos ms arriba, el plugin de la Prctica se completa con la parte de Asiga a nacin (denominado practice.tech.desarrollo centrado usuario.assign) que obvio amente contiene las relaciones entre los Roles y las Tareas denidos por la Prctica DCU. a La organizacin del plugin es similar al Base. Un paquete de contenido (denominado o asignacion roles) incluye las deniciones de los tipos de elementos a vincular. Para realizar la asociacin se utiliza la variabilidad de contenido Contribuye, que ya o describimos. Se incluyen dos contribuciones a los roles denidos, indicando en cada contribucin la responsabilidad sobre productos de trabajo de la Prctica: o a disenador ux.asigna.wp contribuye a disenador ux y es responsable de Mapa de navegacin, Prototipo de UX y Storyboard de UX. o especialista ux.asigna.wp contribuye a especialista ux y es responsable de Meta de Usabilidad, Modelo de Tareas y Modelo de Usuario. La previsualizacin permite conrmar las relaciones establecidas, tal como se presenta o en la Figura 8.20 y 8.21 Del mismo modo que para establecer las relaciones entre Roles y Productos de Trabajo, a asignacin de Tareas a los Roles se realiza mediante la denicin de nuevas tareas que o o contribuyen a las bsicas de la prctica y que aportan fundamentalmente la relacin de una a a o Tarea con quienes la realizan tanto en su carcter de guras primarias como adicionales. La a Figura 8.22 presenta las tareas agregadas, por el nombre es fcil describir a cul contribuye a a cada una. Como cada una de estas nuevas tareas slo persigue el objetivo de contribuir una o relacin de asignacin con uno o ms roles, ste es el unico dato que completamos en su o o a e denicin, como muestra la Figura 8.23 y 8.24 o
8.4.2.
El plugin de Conguracin OpenUP/MMU-ISO N1 o
Este plugin extiende la conguracin OpenUP/Basic y le incorpora los elementos de o la Prctica Desarrollo Centrado en Usuario para permitir la instanciacin de procesos a o conformes al Modelo de Madurez en Usabilidad ISO con un nivel 1 de Capacidad. Este Plugin lgico est organizado en tres elementos f o a sicos: Un plugin de Proceso: process.openup.mmu-iso n1 Un plugin de Publicacin: publish.openup-mmuiso.n1.base o
8.4
179
Figura 8.19: Denicin de Tarea Entender y Especicar Contexto de Uso. Solapa Previo sualizacin o
Figura 8.20: Responsabilidad de Productos de Trabajo del Diseador de UX n
Figura 8.21: Responsabilidad de Productos de Trabajo del Especialista de UX
180
8.4
Figura 8.22: Tareas denidas para contribuir asignaciones a las bsicas a
Figura 8.23: Asignacin de roles a Entender y especicar Contexto de Uso mediante cono tribucin o
8.4
181
Figura 8.24: Asignacin de roles a Entender y especicar Contexto de Uso mediante cono tribucin o Una Conguracin de mtodo: publish.openup-mmu iso n1 o e La Figura 8.25 muestra la ubicacin de estos componentes en la estructura de plugins o de la EPL. El plugin Base de proceso, hace referencia a la base de OpenUP y a las dos partes f sicas de la Prctica DCU. a En el paquete de contenidos propio del plugin, se agregan cinco deniciones de tareas necesarias para extender las de OpenUP base y permitir la conformacin de un proceso o conforme a MMU-ISO. Las modicaciones que se incluyen, en todos los casos utilizando la variabilidad Contribuye, son las siguientes: Desarrollar Visin Tcnica: se agrega el paso Identicar y bocetar el contexto de o e uso. Evaluar resultados: agrega como realizadores adicionales al L der tcnico de dominio, e Patrocinador y Representante de usuarios. Gestionar iteracin: agrega como realizadores adicionales al L o der tcnico de dominio e y al Patrocinador. Planicar iteracin: agrega como realizador adicional al L o der tcnico de dominio e Planicar el proyecto: agrega como realizadores adicionales al L der tcnico de doe minio y al Patrocinador. En el paquete de procesos del plugin se modican varios de los patrones de capacidad para reejar estas incorporaciones y otros cambios necesarios en el Proceso de entrega general, tal como se indic en la descripcin de la Conguracin en el Cap o o o tulo 7.
182
8.4 Realizador primario Gerente de proyecto Diseador de UX n Diseador de UX n Especialista de UX Tester de UX Realizador adicional Lider tcnico de dominio, e Patrocinador Especialista de UX Desarrollador, Representante de Usuarios Lider tcnico de dominio, e Representante de usuarios Usuario nal, Representante de usuarios, Especialista de UX Lider tcnico de dominio, e Representante de usuarios Lider tcnico de dominio, e Representante de usuarios, Usuario nal Lider tcnico de dominio, e Representante de usuarios, Usuario nal Especialista de UX, Representante de usuarios Diseador de UX, Espen cialista de UX
Tarea Adaptar el proceso DCU Disear la UX n Disear componentes de n la UX Disear y producir maten rial de entrenamiento Ejecutar pruebas de usabilidad Entender y especicar Contexto de Uso Especicar requerimientos y objetivos de UX Guiar y dar soporte a usuario en implementacin o Preparar pruebas de usabilidad Renar modelo de UX Revisar diseo de UX n
Especialista de UX Especialista de UX
Especialista de UX
Tester de UX Diseador de UX n Tester de UX
Tabla 8.3: Asignaciones de Roles a Tareas de DCU En la Actividad Identicar y Bocetar requerimientos se incluyen las Tareas espec cas de los procesos DCU: Entender y especicar contexto de uso y Especicar requerimientos y metas de la UX. La Tarea Disear la Experiencia de Usuario se incorpora en el patrn de capacidad n o Acordar el abordaje tcnico (que contribuye a Agree on technical approach). De esta e manera, esta actividad concentra las actividades de diseo de alto nivel tanto respecto de n la funcionalidad del sistema como de la experiencia de usuario requerida. De la misma forma, la Actividad Desarrollar la arquitectura, incorpora la tarea Disear n el Modelo de la UX, para mantener durante las primeras fases el foco tanto en el nivel micro del diseo de componentes UX como en el macro del modelo general de la misma. n Ya vimos en el los cap tulos previos la estrecha relacin que existe entre las deniciones en o el nivel de la arquitectura del software y los requerimientos y posibilidades de usabilidad del producto nal. La Actividad Desarrollar un Incremento de solucin incluye las tareas del diseno de o componentes de UX y su revisin. o En el patrn de capacidad Testear la solucin se incorporan las Tareas Preparar prueo o bas de usabilidad y Ejecutar pruebas de usabilidad. Finalmente, ser necesario incluir un nuevo patrn de capacidad para dar soporte a la a o Actividad incluida en la descripcin del Cap o tulo 7, Guiar y dar soporte al usuario, que se compone de las dos tareas previstas para las fases de implementacin del sistema o o producto: Producir material de entrenamiento y soporte al usuario y Guiar y dar soporte al usuario en implementacin. o A partir de estos cambios, se utiliza el Patrn de Entrega de OpenUP/Basic como base o para proponer el proceso OpenUP/MMU-ISO N1 que incluye las mismas cuatro fases del original (Inicio, Elaboracin, Construccin y Transicin). La estructura e hitos de cada o o o
8.4
183
Figura 8.25: Ubicacin de plugins f o sicos para conguraciones OpenUP/MMU-ISO Nx fase siguen siendo los mismos, salvo para la fase de Transicin donde se agrega el patrn o o de capacidad mencionado en el prrafo anterior, tal como muestra la Figura 8.26. a
Figura 8.26: Iteracin tipo en fase de Transicin de OpenUP/MMU-ISO N1 o o La Conguracin toma como referencia los siguientes elementos: o Los plugins Core con los elementos bsicos para constituir la EPL a Todas las prcticas incluidas en la EPL, con la unica excepcin de Agile Business a o Rule Development (ABRD). Es particularmente importante la inclusin de Desaro rollo Centrado en Usuario del grupo de prcticas tcnicas. a e Los plugins de procesos OpenUP, particularmente el mmu-iso n1. Del plugin OpenUP se excluye el proceso de entrega con su ciclo de vida, ya que ser redenido como el a
184
8.4
ciclo OpenUP/MMU-ISO N1. Los plugins de publicacin que contienen los elementos y vistas a presentar en web: o OpenUP y OpenUP-MMUISO.N1. Utilizamos las mismas vistas de navegacin para el sitio web a publicar, incorporando o en algunas de ellas informacin espec o ca del Modelo de Madurez de Usabilidad ISO o de la adaptacin OpenUP/MMU-ISO para ayudar al ingeniero de procesos en la adopcin del o o proceso. En particular, se incluyen las orientaciones denidas en la Prctica DCU como a Presentacin y Conceptos de la Prctica DCU, Presentacin del MMMU-ISO y la Hoja o a o de Ruta para adopcin. o
8.4.3.
Este plugin extiende la conguracin OpenUP/MMU-ISO N1 y le incorpora los eleo mentos de la Prctica Desarrollo Centrado en Usuario para permitir la instanciacin de a o procesos conformes al Modelo de Madurez en Usabilidad ISO con un nivel 2 de Capacidad. Este Plugin lgico est organizado en tres elementos f o a sicos: Un plugin de Proceso: process.openup.mmu-iso n2 Un plugin de Publicacin: publish.openup-mmuiso.n2.base o Una Conguracin de mtodo: publish.openup-mmu iso n2 o e Hemos visto que en este nivel de capacidad interesa demostrar que los procesos se gestionan para producir los productos en tiempo establecido y dentro de los requerimientos especicados y que los productos de trabajo son documentados y controlados para satisfacer requerimientos funcionales y no funcionales. En el Apndice B se detallan las e prcticas asociadas a estos dos objetivos. a En el plugin de la conguracin incorporamos modicaciones en dos Actividades: Inio ciar el Proyecto y Planicar y gestionar la iteracin tal como se propuso en el Cap o tulo 7. En el plugin de proceso se agregan cuatro tareas que contribuyen respectivamente a otras tantas del proceso OpenUP/MMU-ISO N1 con pasos adicionales que generen evidencia de la gestin DCU necesaria. o Planificar proyecto mmuiso n2, contribuye a Planicar el proyecto, con el paso Denir productos DCU a utilizar en proyecto. Planificar iteracion mmuiso n2, contribuye a Planicar la iteracin con dos pao sos: Establecer los recursos necesarios para las actividades DCU y Establecer requerimientos de calidad de productos de trabajo DCU. Gestionar iteracion mmuiso n2, contribuye a Gestionar la iteracin con el paso o Monitorear mtricas de calidad y usabilidad de productos de trabajo DCU. e Evaluar resultados mmuiso n2, contribuye a la tarea Evaluar resultados con el paso Ponderar resultados de pruebas de usabilidad.
8.4.4.
De manera similar al anterior, este plugin extiende la conguracin OpenUP/MMUo ISO N2 y le incorpora los elementos de la Prctica Desarrollo Centrado en Usuario para a permitir la instanciacin de procesos conformes al Modelo de Madurez en Usabilidad ISO o con un nivel 3 de Capacidad. Este Plugin lgico est organizado en tres elementos f o a sicos:
8.4
185
Un plugin de Proceso: process.openup.mmu-iso n3 Un plugin de Publicacin: publish.openup-mmuiso.n3.base o Una Conguracin de mtodo: publish.openup-mmu iso n3 o e El plugin de proceso contiene la incorporacin de la Tarea Adaptar el proceso DCU en o la Actividad Iniciar el Proyecto, tal como se muestra en el WBS del Proceso de Entrega OpenUP/MMU-ISO N3 en la Figura 8.27.
Figura 8.27: WBS del Proceso de Entrega OpenUP/MMU-ISO N3 La inclusin de esta tarea como parte de la actividad de lanzamiento del proyecto o asegura la revisin y ajuste del proceso y genera evidencia de las prcticas de gestin o a o de denicin del proceso y sus recursos tal como se exige en este nivel de capacidadl del o MMU-ISO. Esa tarea se complementa con pasos extras en las actividades de planicacin y gestin o o de las iteraciones. En Evaluar resultados se incorpora el paso de revistar el proceso y proponer ajustes si es necesario y en Planicar la iteracin se agrega el consecuente paso o de incorporar los cambios al proceso que se sugieran en las evaluaciones.
186
8.4
Cap tulo 9
Conclusiones
Resumen
En esta Tesis hemos presentado una propuesta para un proceso de desarrollo de software que incorpore prcticas de diseo centrado en usuario y d conformidad al Modelo a n e de Madurez en Usabilidad de la ISO en los niveles de Capacidad 1, 2 o 3. Hemos sealado la importancia que la usabilidad ha adquirido como atributo de calidad n en los productos de software. Tambin mostramos que tanto desde la Human Computer e Interaction como desde la Ingenier de Software se reconoce que es necesario involucrar a activamente a los usuarios en el proceso de desarrollo para aumentar los atributos de usabilidad del producto nal. Pasamos revista a diferentes propuestas que provienen de ambos campos y que buscan implementar procesos de Diseo Centrados en Usuario. Sin embargo, encontramos que n existen dicultades de integracin entre IS y HCI, debidas a la falta de conocimiento o mutuo entre ellas, la diferencia de enfoques sobre el mismo objeto de estudio, la dispar madurez de las disciplinas, etc. Una de las principales dicultades est planteada por el a hecho de que el diseo y construccin de software est regido fundamentalmente por las n o a prcticas y conceptos de la ingenier del software al tiempo que los mtodos, tcnicas a a e e y herramientas de la HCI son poco conocidas o incomprendidas por los ingenieros de software. Esta situacin deriva en una falta de comprensin adecuada de las implicancias o o de la usabilidad en todo el proceso y termina connada a los aspectos relacionados con la organizacin visual de pantallas y la formulacin del esquema de navegacin. o o o En aquellos casos donde nalmente se instauran las prcticas bsicas de diseo de a a n interaccin y usabilidad, con poco o nulo poder de decisin de sus actores, no existen o o gu para impulsar una mejora ordenada y previsible de los procesos que promueva logros as de usabilidad ms altos. Una de las formas de disponer de hojas de ruta para la mejora a sistemtica y previsible de procesos est dada por los Modelos de Capacidad y Madurez. a a Planteamos entonces la utilizacin de modelos de madurez y capacidad en usabilidad para o conformar nuevos procesos de trabajo y modicar los existentes. En particular, describimos el Modelo de Madurez en Usabilidad contenido en las Normas ISO, que identica siete procesos de Diseo Centrado en Usuario y una escala de Capacidad que comprende seis n niveles (desde 0 o Incompleto hasta 5 u Optimizado). Tomamos el Proceso Unicado como uno de los mtodos de desarrollo que ha conseguie do mayor adhesin en la comunidad de ingenier de software. Analizamos su versin open o a o source, conocida como OpenUP para evaluar su conformidad con el Modelo de Madurez en Usabilidad de ISO. Identicamos algunas caracter sticas que estn en la base del Proceso a Unicado y que resultan indispensables para procesos Centrados en Usuario, pero tambin e encontramos varias falencias que no pueden ser cubiertas simplemente con la modicacin o 187
188
Conclusiones
9.0
adhoc de algunas de sus prcticas. a En consecuencia, la propuesta de esta Tesis es extender OpenUP para que pueda ser instanciado como un proceso centrado en usuario. Se proponen dos contribuciones. Por un lado, se agrega una nueva prctica a la EPL (el framework de buenas prcticas del a a que OpenUP es instanciacin), el Desarrollo Centrado en Usuario o DesCU. Esta Prctica o a articula los elementos de contenido de mtodo espec e ficos del DCU, sus roles, tareas y productos de trabajo, tomando como referencia el ciclo de vida propuesto por el modelo de ISO 13407 sobre el que se cimenta el MMU-ISO. La segunda contribucin consiste en extender la instanciacin de OpenUP con tres o o conguraciones de mtodos que permitirn alcanzar los niveles 1, 2 o 3 de Capacidad e a en Usabilidad en el marco del MMU-ISO. En estas conguraciones se articula la prctica a DesCU con las restantes del framework para permitir instanciaciones del Proceso Unicado que puedan conformar al MMU-ISO. Finalmente, mostramos una implementacin de estas extensiones como plugins para el o Eclipse Process Framework Composer. Estos plugins podrn ser utilizados por un equipo a de trabajo simplemente publicando sus contenidos tal como son provistos para el nivel de capacidad deseado, pero tambin podrn ser customizados a las necesidades de un e a proyecto u organizacin particular. o
Discusin y lecciones aprendidas o

Hemos sealado en varias oportunidades que un proceso centrado en usuarios es la n mejor manera identicada hasta el momento para garantizar buenas condiciones de usabilidad del producto. Sin embargo, no todos los procesos de desarrollo de software pueden ser transformados en DCU de manera simple. Es necesario que dispongan al menos de dos caracter sticas bsicas: incrementalidad e iteratividad. Ambas se encuentran en la a naturaleza del Proceso Unicado y por tanto fue posible desarrollar una adaptacin de o OpenUP orientada a lograr mayor centralidad en el usuario. La extensin que se presenta apunta a las dos carencias ms signicativas que eno a contramos en todos los procesos de desarrollo y en las alternativas de incorporacin de o usabilidad que revisamos. Por un lado, es necesario incorporar nuevos roles habitualmente no tenidos en cuenta en el proceso de desarrollo para transformarlo en un proceso centrado en usuario. Esto implica no slo comprometer a los stakeholders y usarios nales, o sino agregar una nueva bater de habilidades y destrezas en el proyecto. Esto debe ser a incorporado desde el mismo momento de la concepcin del proyecto y los diseadores de o n experiencia de usuario deben trabajar continuamente acoplados con los analistas, arquitectos y diseadores de software. n Por otra parte, la manera de convertir a todo el proceso en centrado en usuario es atravesar el ciclo de vida completo con actividades vinculadas a la experiencia del usuario. No hay forma de garantizar buenos niveles de usabilidad en un producto si todas los aspectos de la calidad en el uso se reducen al diseo de la interfaz de usuario. n Poner al DCU al mismo nivel de otras buenas prcticas de la ingenier de software a a como el Desarrollo guiado por Casos de Uso, la Planicacin en dos niveles, etc. le brinda o un espacio necesario en la mesa de las decisiones. La organizacin de la EPL como un o framework de buenas prcticas facilita la organizacin de todos los elementos de mtodo a o e propios de un proceso centrado en usuarios como un conjunto de alta cohesin y fcilmente o a acoplable a otras prcticas. Manteniendo el bajo nivel de ceremonial y burocracia que a sustenta a la EPL y OpenUP es posible realizar conguraciones centradas en usuarios como hemos podido demostrar. Se agregan ocho productos de trabajo y diez deniciones de tareas que los crean, usan y modican. La gu del MMU-ISO como hoja de ruta facilita la incorporacin gradual, pero sisa o temtica de mayores niveles de capacidad en usabilidad por parte de un equipo de trabajo a
9.0
189
u organizacin. Las conguraciones de base que se proponen como OpenUP/MMU-ISO Nx o pueden ser instanciadas fcilmente con las modicaciones apropiadas a cada organizacin a o gracias al EPF Composer.
Trabajos futuros
Los siguientes trabajos aparecen como continuidad de lo presentado en esta tesis: Realizar trabajos de anlisis en campo con implementacin de procesos que instana o cien las conguraciones OpenUP/MMU-ISO Nx para evaluar los ajustes que resulten necesarios. Evaluar la posibilidad de realizar extensiones de OpenUP que permitan alcanzar los otros niveles de Capacidad y Madurez del MMU-ISO. Los niveles 4 y 5 del MMU-ISO corresponden a aspectos vinculados con la organizacin, ms que con un proyecto o a o equipo determinado. Sin embargo, deber ser posible determinar qu partes del a e mtodo debern ser adaptadas para dar el soporte adecaudo a una conformidad con e a esos niveles de capacidad y madurez.
190
Conclusiones
9.0
Bibliograf a
Ambler, S. 2006. The Agile Unied Process (AUP). http://www.ambysoft.com/ unifiedprocess/agileUP.html. Ultimo acceso: marzo 2010. Ambler, S., Nalbone, J., and Vizdos, M. 2005. The Enterprise Unied Process: extending the Rational Unied Process. Prentice Hall Press, Upper Saddle River, NJ, USA. Ambler, S. W. 2004. The Object Primer : Agile Model-Driven Development with UML 2.0. Cambridge University Press. Annet, J. and Duncan, K. 1967. Task analysis and training in design. Occupational psychology 41. ANSI. 2001. Common Industry Format for Usability Test Reports. April, A. and Coallier, F. 1995. Trillium: a model for the assessment of telecom software system development and maintenance capability. Software Engineering Standards, International Symposium on 0, 175. Arnowitz, J., Arent, M., and Berger, N. 2006. Eective Prototyping for Software Makers (The Morgan Kaufmann Series in Interactive Technologies). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Astels, D. 2003. Test Driven development: A Practical Guide. Prentice Hall Professional Technical Reference. ATG, I. 2010. Web Enabled UCD v1.0. http://www.iconatg.com/iconprocess/ plugins/web_enabled_ucd. Ultimo acceso: marzo 2010. Bass, L. and John, B. E. 2001a. Achieving usability through software architecture. In ICSE 01: Proceedings of the 23rd International Conference on Software Engineering. IEEE Computer Society, Washington, DC, USA, 684. Bass, L. and John, B. E. 2001b. Supporting Usability Through Software Architecture. Computer @ 10, 113115. Beck. 2002. Test Driven Development: By Example. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Beyer, H. and Holtzblatt, K. 1998. Contextual design: dening customer centered systems. Morgan Kaufmann, San Francisco USA. Buxton, B. 2007. Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Card, S. K., Newell, A., and Moran, T. P. 2000. The Psychology of HumanComputer Interaction. L. Erlbaum Associates Inc., Hillsdale, NJ, USA. 191
192
BIBLIOGRAF IA
9.0
Carroll, J. M., Ed. 1995. Scenario-based design: envisioning work and technology in system development. John Wiley & Sons, Inc., New York, NY, USA. Cockburn, A. 2000. Writing eective use cases. Addison Wesley. Cockburn, A. 2002. Agile software development. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Conallen, J. 2002. Building Web Applications with UML. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Constantine, L. and Lockwood, L. 1999. Software for use: a practical guide to the models and methods of usage-centered design. Addison Wesley, Reading, MA. Constantine, L. L. and Lockwood, L. A. D. 2002. Usage-Centered Engineering for Web Applications. IEEE Softw.@ 2, 4250. Cooper, A. 2004. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition). Pearson Higher Education. Costabile, M. F. 2001. Usability in the software lifecycle. Vol. 1. World Scientic Publishing Company, 179192. Crosby, P. B. 1979. Quality Is Free. The Art of Making Quality Certain. McGraw-Hill, New York. DSDM-Consortium. 2007. OpenUP/DSDM Plugin. website. http://www.eclipse. org/epf/downloads/openup/openup_downloads.php. Ulitmo acceso: marzo 2010. DSDM-Consortium. 2010. DSDM Public Version 4.2. http://dev.dsdm.org/ version4/2/public/default.asp. Ultimo acceso: marzo 2010. Earthy, J. 1998. Usability Maturity Model: human-centeredness scale. Tech. rep., Lloyds Register of Shipping. Earthy, J. 2000. Usability Maturity Model: Processes. Tech. rep., Lloyds Register. January. ECLIPSE. 2006. Eclipse Process Framework Project. http://www.eclipse.org/ projects/project_summary.php?projectid=technology.epf. Ultimo acceso: marzo 2010. Eclipse. 2008a. Eclipse Process Framework Practice Library. http://epf.eclipse. org/wikis/epfpraclib/. Ultimo acceso: marzo 2010. Eclipse. 2008b. Method Authoring Method for the EPF Practices Library. http://epf. eclipse.org/wikis/mam/index.htm. Ultimo acceso: marzo 2010. Eclipse. 2008c. OpenUP version 1.5.0.1. Eclipse. 2008d. Roadmap: Authoring in the Eclipse Practice Library (EPL). Ultimo acceso: marzo 2010. Ehrlich, K. and Rohn, J. A. 1994. Cost justication of usability engineering: a vendorss perspective. Cost-justifying usability, 73110. Flanagan, G. A. and Rauch, T. L. 1995. Usability management maturity, part 1 (abstract): self assessmenthow do you stack up? In CHI 95: Conference companion on Human factors in computing systems. ACM, New York, NY, USA, 336.
9.0
BIBLIOGRAF IA
193
Folmer, E. and Bosch, J. 2005. Case studies on Analyzing Software Architectures for Usability. In EUROMICRO 05: Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications. IEEE Computer Society, Washington, DC, USA, 206213. Garrett, J. J. 2002. The Elements of User Experience: User-Centered Design for the Web. New Riders Publishing, Thousand Oaks, CA, USA. Goransson, B., Lif, M., and Gulliksen, J. 2003. Usability design - Exteding Rational Unied Process with a new discipline. In Interactive systems: design, specication and verication. 10th International Workshop, J. Nunes and J. Cunha, Eds. Springer Verlag, Funchal, Madeira Island, Portugal. Gould, J. and Lewis, C. 1985. Designing for usability: key principles and what designers think. Communications of ACM @ 3, 300311. Gulliksen, J., G, B., Boivie, I., Blomkvist, S., Persson, J., and Cajander, A. 2003. Key principes for user-centred systems design. Behaviour and Information Technology@ 6, 397409. Hackos, J. T. and Redish, J. C. 1998. User and task analysis for interface design. John Wiley & Sons, Inc., New York, NY, USA. Hix, D. and Hartson, H. R. 1993. Developing user interfaces: ensuring usability through product & process. John Wiley & Sons, Inc., New York, NY, USA. Holtzblatt, K., Wendell, J. B., and Wood, S. 2005. Rapid Contextual Design. A how to guide to key techniques for user centered design. Morgan Kaufmann, San Francisco, USA. Humphrey, W. S. 1989. Managing the software process. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. IBM. 2005a. Rational Unied Process for Large Projects 7.0.1.E. IBM. 2005b. RUP for user experience modeling. http://www.ibm.com/developerworks/ rational/library/05/1206_rup_plugins/rup_ue.html. Ultimo acceso: marzo 2010. ISO/IEC. 1995. 12207 Information TechnologySoftware Life Cycle Processes. Tech. rep., International Organization for Standardization and International Electrotechnical Commission. ISO/IEC. 1998. 9241-11 Ergonomic requirements for oce work with visual display terminals (VDT)s - Part 11 Guidance on usability. ISO/IEC. 1999. 13407 Human-centred design processes for interactive systems. ISO/IEC. 2000a. 18529 Ergonomics of human system interaction. Human-centred lifecycle process descriptions. Tech. rep. ISO/IEC. 2000b. 9126 Software product quality - Quality model. ISO/IEC. 2006. 15504 Information TechnologySoftware Process Assessment Part 1: Concepts and Vocabulary, Part 2: Performing an Assessment, Part 3: Guidance on Performing an Assessment, Part 4: Guidance on Use for Process Improvement and Process Capability Determination, Part 5: An Exemplar Process Assessment Model, 2003-2006. Tech. rep., International Organization for Standardization and International Electrotechnical Commission.
194
BIBLIOGRAF IA
9.0
Jacobson, I., Booch, G., and Rumbaugh, J. 1999. The unied software development process. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Jacobson, I., Christerson, M., Jonsson, P., and vergaard, G. 1992. Objectoriented software engineering: a use case driven approach. Addison Wesley, Reading MA. Johnson, J. and Henderson, A. 2002. Conceptual models: begin by designing what to design. interactions@ 1, 2532. Jokela, T. 2001a. Assessment of user centred design processes as a basis for improvement action. Ph.D. thesis, University of Oulu. Jokela, T. 2001b. The KESSU Usability Design Process Model. Version 2.1. Tech. rep., University of Oulu, Finland. Kent Beck, Mike Beedle, A. v. B. A. C. W. C. M. F. 2001. Manifesto for Agile Software Development. http://agilemanifesto.org/. Ultimo acceso: marzo 2010. Kroll, P. and MacIsaac, B. 2006. Agility and Discipline Made Easy: Practices from OpenUP and RUP (Addison-Wesley Object Technology (Paperback)). Addison-Wesley Professional. Krutchen, P. 2000. The Rational Unied Process: an introduction, 2nd ed. Addison Wesley. Kuniavsky, M. 2003. Observing the User Experience: A Practitioners Guide to User Research (Morgan Kaufmann Series in Interactive Technologies) (The Morgan Kaufmann Series in Interactive Technologies). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Kuvaja, P. 1995. BOOTSTRAP: A Software Process Assessment and Improvement Methodology. In Proceedings of the Second Symposium on Software Quality Techniques and Acquisition Criteria on Software Quality Techniques and Acquisition Criteria. Springer-Verlag, London, UK, 3148. Landauer, T. K. 1996. Trouble with Computers: Usefulness, Usability, and Productivity. MIT Press, Cambridge, MA, USA. Larman, C. 2003. Agile and Iterative Development: A Managers Guide. Pearson Education. Limbourg, Q. and Vanderdonckt, J. 2004. Comparing task models for user interface design. In The Handbook of Task Analysis for Human Computer Interaction, D. Diaper and N. Stanton, Eds. Lawrence Erlbaum Associates, 135154. Lores, J., Ed. 2001. La interaccin persona ordenador. AIPO, Asociacin Interaccin o o o Persona Ordenador, Espana. Lundmark, M. and Toresson, J. 2007. Assessing usabiliy. Eective estrategies for enhancing usability in projects. Ph.D. thesis, University of Chalmers. Mayhew, D. J. 1999. The usability engineering lifecycle: a practitioners handbook for user interface design. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Nielsen, J. 1993. Usability engineering. Academic Press, San Diego. Nielsen, J. 2006a. Corporate usability maturity: stages 1-4. http://www.useit.com/ alertbox/maturity.html. Ultimo acceso: marzo 2010.
9.0
BIBLIOGRAF IA
195
Nielsen, J. 2006b. Corporate usability maturity: stages 5-8. http://www.useit.com/ alertbox/process_maturity.html. Ultimo acceso: marzo 2010. Nunes, N. J. and Cunha, J. F. 2001. WISDOMWhitewater interactive system development with object models. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 197243. OMG. 2008. Software & Systems Process Engineering Meta-Model Specication Version 2.0. Tech. rep., OMG. Paterno, F. 1999. Model-Based Design and Evaluation of Interactive Applications. Springer-Verlag, London, UK. ` Paterno, F., Mancini, C., and Meniconi, S. 1997. ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models. In INTERACT 97: Proceedings of the IFIP TC13 Interantional Conference on Human-Computer Interaction. Chapman & Hall, Ltd., London, UK, UK, 362369. Paulk, M. C. 1995. The capability maturity model : guidelines for improving the software process. Addison-Wesley Pub. Co, Reading, Mass. Pruitt, J. and Adlin, T. 2006. The Persona Lifecycle: Keeping People in Mind Throughout Product Design (Interactive Technologies), 1 ed. Morgan Kaufmann. Rauch, T. L. and Flanagan, G. A. 1995. Usability management maturity, part 2 (abstract): usability techniqueswhat can you do? In CHI 95: Conference companion on Human factors in computing systems. ACM, New York, NY, USA, 338. Rieman, J., Franzke, M., and Redmiles, D. 1995. Usability evaluation with the cognitive walkthrough. In CHI 95: Conference companion on Human factors in computing systems. ACM, New York, NY, USA, 387388. Rosson, M. B. and Carroll, J. M. 2002. Usability engineering: scenario-based development of human-computer interaction. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Schaffer, E. 2004. Institutionalization of Usability: A Step-by-Step Guide. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA. Schwaber, K. 2004. Agile Project Management With Scrum. Microsoft Press, Redmond, WA, USA. Seffah, A., Gulliksen, J., and Desmarais, M. C. 2005. Human-Centered Software Engineering - Integrating Usability in the Development Process (Human-Computer Interaction Series). Springer-Verlag New York, Inc., Secaucus, NJ, USA. Seffah, A. and Metzker, E. 2004. The obstacles and myths of usability and software engineering. Commun. ACM @ 12, 7176. Seffah, A., Vanderdonckt, J., and Desmarais, M. C. 2009. Human-Centered Software Engineering: Software Engineering Models, Patterns and Architectures for HCI. Springer Publishing Company, Incorporated. SEI. 1995. The Capability Maturity Model: Guidelines for Improving the Software Process. Tech. rep., Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA. Sharp, H., Rogers, Y., and Preece, J. 2007. Interaction Design: Beyond Human Computer Interaction. John Wiley & Sons.
196
BIBLIOGRAF IA
9.0
Shepherd, A. 2001. Hierarchical task analysis. CRC Press. Sherwood-Jones, B. 1995. Total Systems Maturity. Internal report, version 2. Tech. rep., BAeSEMA, Glasgow. Shneiderman, B., Plaisant, C., Cohen, M., and Jacobs, S. 2009. Designing the User Interface: Strategies for Eective Human-Computer Interaction. Addison-Wesley Publishing Company, USA. Stanton, D. D. N., Ed. 2004. The handbook of task analysis for human-computer interaction. Lawrence Erlbaum Associates. Stanton, N. A. 2006. Hierarchical Task Analysis: Developments, Applications and Extensions. Applied Ergonomics 37, 5579. Winograd, T. 1997. The design of interaction. In Beyond calculation: the next fty years, P. D. R. Metcalfe, Ed. Springer Publishing Company, Incorporated, New York, NY, USA, 149161.
Parte IV
Apndices e
197
Apndice A e
MMU-ISO: Procesos DCU

A continuacin se transcribe cada uno de los procesos DCU contenidos en el MMUo ISO en trminos de su objetivo o propsito, los indicadores que permiten medir el xito e o e alcanzado y las prcticas de base a llevar a cabo. a
DCU 1. Asegurar el contenido DCU en la estrategia de sistemas

Propsito o
Establecer y mantener un foco en temas relacionados con los involucrados y los usuarios en cada parte de la organizacin que aporte al concepto, desarrollo, mantenimiento y o soporte del sistema
Indicadores de xito e
El marketing tiene en cuenta temas de usabilidad, ergonom y socio-tcnicos. a e Los sistemas se dirigen a satisfacer necesidades y expectativas de usuarios. Los planicadores tienen en cuenta los requerimientos de involucrados y organizaciones durante el planteo de la estrategia de sistema. Los sistemas dan mejor respuesta a los cambios provenientes de los usuarios (tareas, expectativas, contexto, necesidades, etc.) La empresa responde mejor a los cambios de usuarios. El sistema tiene menos probabilidades de ser rechazado por el mercado.
Actividades
Representar a los involucrados Actuar como el abogado de los usuarios y todos los interesados en el desarrollo del sistema. El abogado del usuario recuerda al sta que el sistema ser usado por gente real a y tiene que alcanzar determinados niveles de calidad en el uso. Este rol incluye aproximaciones de logro en diseo centrado en usuario, lograr la participacin de usuarios en n o estudios conceptuales, investigar y divulgar temas de contexto de uso. 199
200
APENDICE A
Analizar el mercado Realizar investigaciones de anticipacin en grupos de usuarios potenciales para identio car necesidades futuras de sistemas, nuevos grupos de usuarios u organizaciones. Identicar el contexto de uso esperado para los sistemas futuros. Plantear procedimientos para extraer informacin de usuarios sobre los sistemas futuros. o Denir y planicar la estrategia de sistemas Presentar la informacin del mercado como una visin (por ejemplo para la aprobacin o o o de la direccin de la empresa o el proyecto). Operacionalizar la visin en una estrategia o o de implementacin. Establecer el costo de sistemas en trminos de su ciclo de vida, para o e poder valorar el costo de un abordaje centrado en el usuario. Reunir feedback del mercado Realizar investigaciones para renar y consolidar la estrategia de sistemas basada en feedback de usuarios y no usuarios en el mercado al que se dirigir el sistema a desarrollar. a Analizar las tendencias de los usuarios Buscar cambios en usuarios (sus habilidades y entrenamiento, sus necesidades y deseos), las tareas (cambios en el tipo o volumen de trabajo), contexto (cambios en los entornos de vida o de trabajo, nuevas tecnolog expectativas sociales o pol as, ticas). El anlisis de esta informacin permitir predecir necesidades futuras. a o a
DCU 2. Planicar y gestionar el proceso DCU

Propsito o
Especicar la forma en que las actividades centradas en la persona se adaptan al ciclo de vida completo de procesos y la empresa
El plan de proyecto permite iteraciones e incorporaciones de feedback de usuario. Se asignan recursos para la efectiva comunicacin entre los participantes del equipo o de diseo. n Se concilian potenciales conictos y compromisos entre temas de HCI y otros aspectos del desarrollo. Procesos centrados en la persona se incorporan en los sistemas, procedimientos y estndares de calidad. a Los temas de HCI y DCU son soportados y promovidos en la organizacin o
Actividades
Consultar a los involucrados Establecer las estructuras, mecanismos y procedimientos para asegurar que todos los involucrados relevantes sean consultados de manera efectiva en cada aspecto signicativo para el desarrollo e implementacin del sistema o
MMU-ISO: PROCESOS DCU
201
Identicar y planicar la participacin de los usuarios o Decidir los modos ms efectivos para extraer el input del usuario en cada etapa del a proyecto, tomando las mayores ventajas de las buenas prcticas sobre trabajo de equipo a y la participacin de usuario. o Seleccionar los mtodos y tcnicas centrados en humanos e e Decidir qu mtodos sern incluidos y cmo se relacionarn entre ellos en el proceso e e a o a de desarrollo. Denir cmo ser la interfaz de estos mtodos con la metodolog particular o a e a del ciclo de vida que se usa para el desarrollo de sistema. Asegurar la aproximacin centrada en la persona o Establecer una cultura multidisciplinar del equipo de proyecto. Mantener el foco del sta en una aproximacin centrada en usuarios. Identicar las habilidades de requeridas o para los especialistas y planicar cmo proveerlas. o Planicar actividades de DCU y conducirlas Desarrollar un plan especicando cmo las actividades centradas en el usuario se inteo grarn en el proceso general de desarrollo. Realizar un abordaje espec a co de los temas de usuario en la gestin de proyectos y departamentos de desarrollo. Asegura que el proceso o de desarrollo de sistemas tome en cuenta el input del usuario. Tomar en cuenta los temas de usuario e involucrados en las actividades de soporte (por ejemplo, en la gestin de o contratos y compras). Liderar una aproximacin centrada en usuario o Promover un abordaje centrado en el usuario dentro de la empresa o el equipo de proyecto. Establecer y comunicar una pol tica sobre el tema. Soportar DCU Incluir elementos centrados en el usuario en los procedimientos de soporte (aseguramiento de calidad, control de cambios, procesos y mtodos de mantenimiento, gestin e o de recursos). Asegurar que estos se realizan como parte integral de la gestin de infraestruco tura de la empresa o del equipo.
DCU 3. Especicar los requerimientos de los involucrados y de la organizacin o

Propsito o
Establecer los requerimientos del sistema desde la organizacin y otros interesados, o tomando en cuenta las necesidades, competencias y entorno de trabajo de cada involucrado relevante al sistema.
Se dene la performance requerida del sistema contra objetivos operativos y funcionales. Se identican requerimientos normativos y legislativos.
202
APENDICE A
Se dene la cooperacin y comunicacin entre usuarios y otras partes relevantes. o o Se dene el trabajo de los usuarios (alocacin de tareas, confort, seguridad, salud, o motivacin) o Se establece la performance de tareas de los usuarios con el sistema Se dene el diseo de trabajo, las prcticas de la organizacin y la estructura. n a o Se identican la factibilidad de operaciones y mantenimiento. Se jan objetivos para la operacin y/o uso de los componentes de software y hardo ware
Actividades
Claricar y documentar las metas del sistema Describir los objetivos que los usuarios y la organizacin desean alcanzar con el uso o del sistema. Denir a los involucrados Identicar y analizar los roles de cada grupo de usuarios e involucrados que sern a afectados por el sistema. Valorar la signicacin y relevancia del sistema para cada grupo o de involucrados. Evaluar los riesgos de las personas y el sistema Revisar los riesgos para la seguridad, salud y bienestar de los involucrados en el sistema. Relacionarlos con la gestin de riesgo del sistema. o Denir el sistema Establecer y acordar las funciones y performance requerida para el sistema en trmie nos de la experiencia total para los involucrados con el sistema (metas para adecuacin, o aceptabilidad y eciencia del usuario nal). La experiencia total cubre cada aspecto de la relacin con el sistema por parte de los involucrados relevantes, desde el encargo del o trabajo hasta la nalizacin completa. o Generar los requerimientos de los involucrados y la organizacin o Desarrollar un planteo expl cito de los requerimientos de los involucrados y la organizacin sobre el sistema. Este proceso es iterativo. Los requerimientos pueden ser orgao nizados en orden de importancia. Los requerimientos normativos sobre el entorno y la carga de trabajo deben ser tenidos en cuenta. Los requerimientos de los involucrados y la organizacin denen una gran parte de los requerimientos operativos y de performance o del sistema. Establecer los objetivos de calidad en el uso Generar y acordar criterios mensurables para la calidad de uso requerida al sistema. La calidad de uso se establece como los niveles solicitados de efectividad, productividad y satisfaccin del usuario hacia el sistema o sus componentes, en un contexto particular o de tareas y sobre la base de requerimientos de performance.
203
DCU 4. Entender y especicar el contexto de uso

Propsito o
Identicar, claricar y registrar las caracter sticas de los involucrados, sus tareas y el entorno f sico y organizacional en el que operar el sistema. a
Se han denido las caracter sticas de los usuarios Se han denido las tareas que los usuarios debern realizar a Se han denido la organizacin y el entorno en el que se utilizar el sistema. o a
Actividades
Identicar y documentar las tareas del usuario Describir las actividades que los usuarios realizan para alcanzar las metas del sistema. Las descripciones de tareas no incluyen solamente las funciones o caracter sticas del equipamiento. Las tareas pueden cambiar o evolucionar durante el ciclo de vida del sistema. Identicar y documentar los atributos del usuario Describir las caracter sticas relevantes de los usuarios nales del sistema, incluyendo conocimientos, lenguaje, capacidades f sicas, nivel de experiencia, etc. Identicar y documentar el entorno organizacional Describir el marco social y organizacional, la estructura y prcticas de gestin, etc. a o Identicar y documentar el entorno tcnico e Describir las caracter sticas relevantes de cualquier equipo que sea utilizado. Para sistemas nuevos las caracter sticas del equipo dependen de las soluciones a proponer, por lo que es posible que no sean conocidas hasta bastante avanzado el proyecto. Identicar y documentar el entorno f sico Describir la ubicacin, equipamiento del puesto de trabajo y condiciones ambientales. o
DCU 5. Producir soluciones de dise o n

Propsito o
Crear soluciones potenciales de diseo mediante el uso de prcticas del estado del arte, n a la experiencia y conocimiento de los participantes y los resultados del anlisis del contexto a de uso.
204
APENDICE A
Se considera en el diseo el sistema socio-tcnico completo en que se inserta el n e sistema Se tienen en cuenta las caracter sticas y necesidades del usuario en la compra de componentes del sistema y en el diseo n Se integran en el sistema los conocimientos existentes y buenas prcticas de ingea nier de sistemas socio-tcnicos, ergonom psicolog ciencias cognitivas, etc. a e a, a, Se mejora la comunicacin entre los involucrados en el sistema haciendo expl o citas las decisiones de diseo. n El equipo de desarrollo es capaz de explorar varios conceptos de diseo antes de n conrmar alguno. Se incorpora feedback de todos los involucrados y usuarios desde las primeras fases del proceso de desarrollo Es posible evaluar varias iteraciones de un diseo y sus alternativas. n Se disea la interfaz de usuario n Se desarrolla el entrenamiento y soporte para el usuario
Actividades
Alocar funciones Analizar el contexto de uso y las funciones y performance requerida del sistema para distribuir las funciones entre las personas, las mquinas y los componentes organizacionales a del sistema que mejor puedan cumplimentar cada una de ellas. La alocacin de funciones o puede ser dinmica. El objetivo es optimizar la perfomance del sistema completo para el a logro de las metas. En los niveles superiores de la jerarqu del sistema puede ocurrir que a las funciones no se puedan asignar a algn componente en particular (persona, equipo, u software, organizacin, etc.), sino a subsistemas constituidos por ms de uno de ellos. o a Producir el modelo de tareas compuesto Desarrollar un modelo factible de las nuevas tareas del usuario a partir del conocimiento de las mejores prcticas, los requerimientos, el contexto de uso, la alocacin de funciones a o y las restricciones de diseo del sistema. Los procesos DCU 5.1 a 5.3 se llevan a cabo en n cada nivel de la jerarqu de sistemas., mientras que DCU5.4 a 5.8 se realizan donde se a denen y desarrollas componenetes de sistema. Explorar el dise o del sistema n Generar y analizar un rango de opciones de diseo para cada aspecto del sistema n relacionado con su utilizacin y su efecto en los involucrados. o Desarrollar soluciones de dise o n Aplicar la informacin relevante del conocimiento sobre la gente al diseo de sistemas. o n Incluir en el diseo los requerimientos de involucrados y organizacin, contexto de uso, n o estndares internacionales, leyes, patentes, buenas prcticas, gu de estilo, etc. a a as
205
Especicar el sistema Producir un diseo para cada componente relacionado con el uso. Cambiar el diseo n n a la luz del feedback surgido de las evaluaciones. Dependiendo del tipo de sistema, la especicacin puede incluir: disear el trabajo del usuario, sus tareas, el entorno de trabajo, o n equipamiento, software, documentacin, diseo de envases, funcionalidad de interfaces, o n etc. Desarrollar prototipos Concretar las soluciones de diseo mediante simulaciones, modelos, maquetas, etc. n Desarrollar simulaciones o ensayos de aspectos clave del sistema a los efectos de testearlas con usuarios o sus representantes. Desarrollar el entrenamiento para el usuario Identicar, especicar y producir el entrenamiento requerido para permitir a los involucrados realizar las tareas en forma efectiva con el sistema nuevo. Cubrir o incluir cualquier cambio propuesto en los procesos de negocio, diseo de trabajo o tareas. n Desarrollar el soporte para el usuario Identicar, especicar y producir los servicios de soporte para el usuario del sistema. Tomar en cuenta los cambios propuestos en los procesos de negocio o diseo de trabajo. n
DCU 6. Evaluar los dise os contra los requerimientos n

Propsito o
Reunir feedback sobre el diseo en desarrollo proveniente de los usuarios y otras fuentes n representativas.
Se ha provisto feedback para mejorar el diseo. n Existe una forma de medir si los objetivos de la organizacin y los involucrados se o alcanzaron o no. Existe un monitoreo continuo sobre el uso en el largo plazo
Actividades
Especicar y validar el contexto de evaluacin o Describir y vericar las condiciones bajo las cuales el sistema ser testeado o evaluaa do de cualquier forma. Describir las relaciones, especialmente las discrepancias, entre el contexto de evaluacin y el contexto de uso. Esto deber realizarse antes de cada uno de o a DCU 6.2 a 6.6 Evaluar prototipos iniciales para denir los requerimientos del sistema Calicar sistemas apropiados usando criterios relevantes. Testear la usabilidad de sistemas competitivos o alternativos. Utilizar prototipos para estimular el input de involucrados a los sistemas de usuarios. Testear la estabilidad de los requerimientos.
206
APENDICE A
Evaluar prototipos para mejorar el dise o n Recolectar input de usuario sobre la calidad de uso del sistema en desarrollo. Presentar los resultados al equipo de diseo de la manera ms apropiada. n a Evaluar el sistema para vericar que los requerimientos se cumplen Testear las versiones en desarrollo o nal del sistema para asegurar que cumple los requerimientos de los usuarios, las tareas y el entorno como fueron denidos. Evaluar el sistema para vericar que se siguieron las prcticas requeridas a Chequear los sistemas sobre la adherencia al conocimiento aplicable sobre las ciencias humanas, gu de estilo, estndares, legislacin. as a o Evaluar el sistema para asegurar que continuamente cumple las metas organizacionales y las necesidades de los usuarios Chequear el sistema en uso contra los cambios en las necesidades organizacionales, del usuario u otros involucrados y de usabilidad para asegurar que contina cumpliendo u las mismas. Esto incluye el contacto rutinario con un nmero representativo de usuarios u utilizando algn procedimiento denido para extraer la informacin necesaria. Incluye u o tambin el feedback a todos los involucrados. La evaluacin del sistema en uso puede ser e o empleada tambin para evaluar si los requerimientos y la especicacin resultante fueron e o correctos.
DCU 7. Presentar y operar el sistema

Propsito o
Establecer los aspectos centrados en la persona para el soporte e implementacin del o sistema.
Se comunican al proyecto las necesidades de los interesados en el sistema. Se especican los procesos de gestin de cambios, incluyendo las responsabilidades o de usuarios y desarrolladores. Se manejan los requerimientos de soporte para usuarios, encargados de mantenimiento y otros interesados. Existe cumplimiento de normas y procedimientos de seguridad e higiene. Se soportan adaptaciones locales del sistema Se renen las reacciones de los usuarios y los cambios resultantes en el sistema son u reportados a los interesados.
Actividades
Gestionar el cambio Facilitar, supervisar y asegurar que los aspectos de DCU en la implementacin del siso tema. Esto incluye reorganizar el diseo de trabajo y las prcticas, equipos, entrenamiento, n a etc.
207
Determinar el impacto sobre la organizacin e involucrados o Evaluar el impacto del sistema a introducir sobre la gente y la organizacin. o Personalizacin y dise o local o n Proveer soporte para la customizacin del sistema que permita cubrir las necesidades o culturales u operacionales en algn lugar. Proveer soporte para la customizacin y conu o guracin del sistema para satisfacer necesidades de usuarios espec o cos. Proveer detalles de customizacin a la gestin de conguracin. o o o Proveer entrenamiento al usuario Brindar entrenamiento y talleres a los usuarios para cubrir las necesidades identicadas y facilitar la transmisin al nuevo diseo del trabajo o las nuevas disposiciones de equipos. o n Soportar a los usuarios en las actividades planicadas Mantener contacto con los usuarios y la organizacin de clientes durante la denicin, o o desarrollo e introduccin de sistema. o Asegurar la conformidad con la legislacin de ergonom de puestos de trabajo o a Informe de lugares de trabajo, usuarios y programas de entrenamiento para asegurar que el software, hardware y puesto de trabajo cubre los requerimientos de legislacin o nacional.
208
APENDICE A
Apndice B e
MMU-ISO: Niveles de Capacidad y Madurez

En este apndice detallamos todos los atributos a identicar en un assessment para e cada uno de los seis niveles de capacidad que presenta el MMU-ISO.
Nivel 0. Proceso incompleto

El proceso no est implementado o falla al tratar de alcanzar su propsito. Sin atributos a o a medir en este nivel.
Nivel 1: Proceso realizado

El proceso implementado alcanza el propsito denido. Los siguientes atributos del o proceso demuestran el logro de este nivel:
Atributos de la performance del proceso (AP1.1)

El grado en el cual los productos de trabajo resultantes son producidos a partir de los productos de input mediante la realizacin de las prcticas que comprende este proceso. o a Las prcticas de gestin para lograr este atributo del proceso es: a o MP1.1.1 Asegurar que las prcticas bsicas son realizadas para satisfacer el propsito a a o del proceso.
Nivel 2: El proceso gestionado

El proceso gestionado entrega productos de trabajo de calidad aceptable dentro de los tiempos denidos y las necesidades de recursos. Los siguientes atributos del proceso demuestran el logro de este nivel:
Atributos de la gestin de la performance(PA2.1) o

El grado con el cual el proceso se gestiona para producir productos de trabajo dentro del tiempo establecido y los requerimientos de recursos. Las prcticas de gestin relaa o cionadas son: 209
210
APENDICE B
MP2.1.1 Identicar requerimientos de recursos para permitir la planicacin y el o control del proceso MP2.1.2 Planicar la performance del proceso identicando las actividades y los recursos alocados de acuerdo con los requerimientos MP2.1.3 Implementar las actividades denidas para lograr el propsito del proceso o MP2.1.4 gestionar la ejecucin de las actividades para producir los productos dentro o del tiempo establecido y los requerimientos de recursos.
Atributos de la gestin de productos de trabajo(PA2.2) o

El grado con el cual los productos de trabajo son documentados y controlados para satisfacer sus requerimientos funcionales y no funcionales. Las prcticas de gestin relaa o cionadas son: MP2.2.1 Identicar requerimientos para la integridad y calidad de los productos de trabajo MP2.2.2 Identicar las actividades necesarias para alcanzar los requerimientos de integridad y calidad de los productos de trabajo. MP2.2.3 Gestionar la conguracin de los productos de trabajo para asegurar la o integridad. MP2.2.4 Gestionar la calidad de los productos de trabajo para asegurar que satisfacen sus requermientos funcionales y no funcionales.
Nivel 3: El proceso establecido

El proceso establecido asegura el despliegue de un proceso denido basado en buenos principios de ingenier de sistemas. Los siguientes atributos del proceso demuestran el a logro de este nivel:
Atributos de denicin de proceso (PA3.1) o

El grado con el cual el proceso contribuye a las metas denidas para el negocio de la organizacin a travs de la denicin de un proceso estndar. Las prcticas de gestin o e o a a o relacionadas son: MP3.1.1 Identicar entre las disponibles en la organizacin la denicin de proceso o o estndar que es apropiada al propsito del proceso y las metas de negocio de la a o organizacin o MP3.1.2 Adaptar el proceso estndar para obtener un proceso denido apropiado a al contexto MP3.1.3 Implementar el proceso denido para lograr su propsito consistente y o repetidamente y soportar la meta de negocio denida para la organizacin o MP3.1.4 Proveer feedback en el proceso estndar desde la experiencia de usar el a proceso denido
MMU-ISO: NIVELES DE CAPACIDAD
211
Atributos de recursos de proceso (PA3.2)

El grado con el cual el proceso contribuye efectivamente a las metas denidas del negocio de la organizacin mediante el uso de recursos humanos calicados e infraestructura o del proceso. Las prcticas de gestin relacionadas son: a o MP3.2.1 denir las competencias de recursos humanos reueridas para soportar la implementacin del proceso denido o MP3.2.2 Denir los requerimentos de infraestructura del proceso para soportar la implementacin del proceso denido o MP3.2.3 Proveer recursos humanos calicados adecuadamente para satisfacer las competencias denidas MP3.2.4 Proveer infraestructura adecuada para el proceso de acuerdo con las necesidades denidas.
Nivel 4: El proceso predecible

El proceso predecible se realiza en forma consistente dentro de l mites de control para alcanzar sus metas. Los siguientes atributos del proceso demuestran el logro de este nivel:
Atributos de la medicin del proceso (PA4.1) o

El grado al cual las metas y mtricas se usan para asegurar que la implementacin del e o proceso contribuye al logro de los objetivos. Las prcticas de gestin relacionadas son: a o MP4.1.1 Denir las metas de proceso y mtricas asociadas que soporten los objetivos e del negocio de la organizacin. o MP4.1.2 Proveer recursos e infraestructura adecuados para la recoleccin de datos. o MP4.1.3 Recolectar los datos de medicin especicados en la implementacin del o o proceso denido. MP4.1.4 Evaluar el logro de metas de proceso por comparacin con las medidas o registradas.
Atributos del control del proceso (PA4.2)

El grado en el cual se alcanza el logro conable de las metas del proceso denido mediante la recoleccin y anlisis de las medidas para controlar y corregir la performance o a del proceso. Las prcticas de gestin relacionadas son: a o MP4.2.1 Identicar tcnicas de anlisis y control apropiadas al contexto del proceso. e a MP4.2.2 Proveer recursos e infraestructura adecuados para el anlisis y control del a proceso. MP4.2.3 Analizar las mtricas disponibles para identicar parmetros de control del e a proceso. MP4.2.4 Identicar desviaciones y tomar las acciones de control requeridas para mantener el control del proceso.
212
APENDICE B
Nivel 5: El proceso optimizado

El proceso optimizado adapta su performance para satisfacer necesidades actuales y futuras del negocio y cumplir sus metas de negocio conablemente. Los siguientes atributos del proceso demuestran el logro de este nivel:
Atributos de cambio del proceso (PA5.1)

El grado en el cual las metas de negocio de la organizacin se alcanzan mediante o cmabios en la dencin, gestin y performance del proceso. o o Las prcticas de gestin relacionadas son: a o MP5.1.1 Identicar y aprobar cambios a la denicin estandar del proceso sobre la o base de una comprensin cuantitativa del mismo. o MP5.1.2 Proveer recursos adecuados para implementar de manera efectiva los cambios aprobados en el proceso. MP5.1.3 Implementar los cambios aprobados al proceso customizado para lograr los resultados esperados. PM5.1.4 Validar la efectividad del cambio de proceso sobre la base de la performance real versus la metas del proceso y del negocio.
Atributos de mejora continua (PA5.2)

El grado al cual la mejora continua en el logro de las metas de negocio denidas para la organizacin se asegura mediante cambios al proceso. o Las prcticas de gestin relacionadas son: a o MP5.2.1 Identicar oportunidades de mejora de forma sistemtica y proactiva para a enriquecer continuamente el proceso. MP5.2.2 Establecer una estrategia de implementacin basada en las oportunidades o de mejora de performance del proceso identicadas de acuerdo con las metas del negocio . MP5.2.3 Implementar cambios a las areas seleccionadas del proceso adaptado de acuerdo con la estratgia de implementacin. o MP5.2.4 Validar la efectividad del cambio del proceso sobre la base de la performance real del proceso versus las metas del negocio y el retroalimentar al proceso estandard.
Apndice C e
Assessment de OpenUP/Basic
Evidencia encontrada
En este Apndice se exhiben las planillas que recogen la evidencia de capacidad de e OpenUP/Basic en cada uno de los niveles de MMU-ISO y el grado de logro para cada atributo.
213
214
APENDICE C
Figura C.1: Resultados para el Proceso DCU 1
ASSESSMENT DE OPENUP/BASIC
215
Figura C.2: Evidencia para determinar Capacidad en DCU2
216
APENDICE C
Figura C.3: Resultados del assessment de DCU 3
217
Figura C.4: Evidencia de capacidades OpenUP en DCU 4
218
APENDICE C
Figura C.5: Evidencia de capacidad OpenUP en DCU 5
219
Figura C.6: Resultados del assessment para DCU 6
220
APENDICE C
Apndice D e
Software adjunto
Se adjunta al documento de la Tesis un CD que contiene los siguientes productos: El documento PDF con el texto de la Tesis Tres sitios web publicando el despliegue de las Conguraciones OpenUP/MMU-ISO Nx Un sitio web con el despliegue de todas las Prcticas de la EPL incluyendo DesCU a El EPF Composer y los plugins descriptos en el Cap tulo 8 Nota: Para facilitar la identicacin del contenido que representa la extensin desaro o rollada en la Tesis el mismo se redact en espaol y se inserta en la versin original en o n o ingls de la EPL y OpenUP. e
221
222
APENDICE D

OpenUP/MMU ISO

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

OpenUP/MMU ISO

Diunggah oleh

Hak Cipta:

Format Tersedia

OpenUP/MMU-ISO

Andrs Rodr e guez

Director: Dr. Gustavo Rossi

La Plata 11 de octubre de 2010

c 2010 by Andrs Santiago Rodr e guez

I Ingenier de software, Usabilidad y Dise o Centrado en el a n Usuario 5

II Capacidad y Madurez en Usabilidad con el Proceso Unicado 27

4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5.

III Soporte para obtener Capacidad y Madurez en Usabilidad con OpenUP 85

xiv 6.3. 6.4. 6.5. 6.6.

51 60 62 63 73 84 103 110 111 112 175 178 182

Ingenier de software, a Usabilidad y Dise o Centrado n en el Usuario

Dise o Centrado en Usuario n

Los procesos de desarrollo de software y el DCU

Los procesos de desarrollo de software y el DCU

Aproximaciones desde el campo HCI

La ingenier de usabilidad seg n Nielsen a u

Aproximaciones desde el campo HCI

El ciclo de vida en estrella de Hix y Hartson

Figura 3.1: Modelo en Estrella, de [Hix and Hartson 1993]

Dise o Centrado en el Uso de Constantine n

Los procesos de desarrollo de software y el DCU

Figura 3.2: Procesos lgicos en el Diseo Centrado en Uso o n

Aproximaciones desde el campo HCI

Ciclo de vida de Ingenier de Usabilidad por Mayhew a

Los escenarios de Carroll y Rosson

Los procesos de desarrollo de software y el DCU

El proceso DCU de ISO

Aproximaciones desde el campo HCI

Los procesos de desarrollo de software y el DCU

Aproximaciones desde la Ingenier de Software a

Aproximaciones desde la Ingenier de Software a

Los procesos de desarrollo de software y el DCU

Aproximaciones desde la Ingenier de Software a

Los procesos de desarrollo de software y el DCU

valor entregado como criterio de aceptacin. o

Figura 3.10: Fases del proceso en WISDOM

Figura 3.11: Flujos de tareas, actividades, modelos y diagramas en WISDOM

Los procesos de desarrollo de software y el DCU

Capacidad y Madurez en Usabilidad con el Proceso Unicado

Proceso Unicado open source: OpenUP

El Eclipse Process Framework

Proceso Unicado open source: OpenUP

El Eclipse Process Framework

Proceso Unicado open source: OpenUP

Los elementos de contenido

Figura 4.6: Relaciones entre deniciones de Rol, Tarea y Producto de trabajo

4.2 Denicin de Producto de trabajo o

El Eclipse Process Framework

Los elementos de proceso

Proceso Unicado open source: OpenUP

El Eclipse Process Framework

Proceso Unicado open source: OpenUP

Figura 4.9: Diagrama de detalle de actividad en SPEM 2.0

Figura 4.10: Diagrama de Dependencias de Producto de Trabajo en SPEM 2.0

La biblioteca de prcticas para el EPF a

La biblioteca de prcticas para el EPF a

Los bloques para construir prcticas a

Proceso Unicado open source: OpenUP

Figura 4.11: Bloques de Prcticas EPL a

La biblioteca de prcticas para el EPF a

Proceso Unicado open source: OpenUP

La biblioteca de prcticas para el EPF a