Post on 25-Jul-2022
Departamento de Tecnologías y Sistemas de la Información
Universidad de Castilla-La Mancha
Tesis Doctoral
Construcción y Evolución del Software
Basados en Valor
Doctorando: D. Daniel Cabrero Moreno
Directores: Dr. D. Mario G. Piattini Velthuis
Dr. D. Javier Garzás Parra
Resumen
La Ingeniería del Software Basada en Valor (ISBV) es una rama de investigación muy
joven, bautizada con ese nombre en el año 2000 por Barry Boehm, que trata de predecir en
qué tareas de Ingeniería del Software (IS) debe ser invertido el esfuerzo para que el software
aporte más valor a las organizaciones.
La presente Tesis Doctoral proporciona una revisión de todos los trabajos relacionados
con la ISBV presentados en los foros de investigación desde el año 1997, cuando fue
presentada la primera propuesta en este sentido. La revisión efectuada desvela una falta de
consenso en el significado del término “valor”, y una serie de oportunidades de mejora muy
importantes en esta rama de investigación.
La alineación de las tareas de IS con los objetivos y prioridades de las compañías es un
problema de plena actualidad en las organizaciones grandes y pequeñas, ya que sus objetivos
son altamente dependientes del software, que constituye cada vez más una herramienta básica
en cualquier actividad económica. Paradogicamente, la ISBV e s al mismo tiempo un área poco
madura, donde se necesita todavía mucho trabajo de investigación
Las aportaciones más relevantes realizadas a lo largo de este trabajo de investigación
son la definición y ordenación de los conceptos de ISBV, la propuesta de una técnica genérica
basada en dichos conceptos que permite combinar todas las propuestas de valor y aplicar
metodológicamente el concepto de valor, y la introducción del concepto de valor en
mantenimiento, diseño y desarrollo.
Las propuestas realizadas están apoyadas en una serie de herramientas desarrolladas a
medida para la validación y prueba de conceptos en la Dirección General de Tráfico.
Índices
Índice de Contenido
CAPÍTULO 1 - INTRODUCCIÓN .................................................................................................. 15
1.1 JUSTIFICACIÓN Y PLANTEAMIENTO DE ESTE TRABAJO ................................................................ 15
1.2 HIPÓTESIS Y OBJETIVO ................................................................................................................ 18 1.3 ÁREAS DE CONOCIMIENTO IMPLICADAS ...................................................................................... 20
1.4 ENTORNO DE DESARROLLO DE ESTE TRABAJO ............................................................................ 23
1.4.1 El proyecto coordinado META (proyecto ESFINGE) ........................................................ 23 1.4.2 El proyecto IDONEO .......................................................................................................... 24 1.4.3 Colaboración con la Dirección General de Tráfico ........................................................... 25
1.5 MÉTODO DE INVESTIGACIÓN ....................................................................................................... 26 1.5.1 Descripción ......................................................................................................................... 26 1.5.2 Aplicación a este trabajo del método de Investigación-Acción .......................................... 27
1.6 ESTRUCTURA DE ESTE TRABAJO .................................................................................................. 29
CAPÍTULO 2 - ESTADO DEL ARTE ............................................................................................ 31
2.1 ESTRUCTURA Y CLASIFICACIÓN DE LAS REVISIONES EFECTUADAS ............................................ 31 2.2 LA INGENIERÍA DEL SOFTWARE BASADA EN VALOR ................................................................... 33
2.2.1 Introducción al Concepto de Valor .................................................................................... 33
2.2.2 Áreas de la Ingeniería del Software Basada en Valor ........................................................ 35
2.3 TRABAJOS MÁS RELEVANTES ...................................................................................................... 37 2.3.1 Trabajos genéricos sobre la definición de un marco de Valor ........................................... 38
2.3.1.1 Cartera de proyectos IT .................................................................................................. 38 2.3.1.2 Evaluación del uso de Metodologías Ágiles en la cartera de proyectos ......................... 39
2.3.1.3 Definición de Fundamentos de la Ingeniería del Software Basada en Valor .................. 40 2.3.1.4 Evaluación de coste de mantenimiento ........................................................................... 42
2.3.2 Ingeniería de requisitos basados en valor .......................................................................... 43 2.3.2.1 Primeros pasos en priorización coste-valor de requisitos ............................................... 44 2.3.2.2 Agrupación de requisitos ................................................................................................ 47
2.3.2.3 Otras técnicas de priorización ......................................................................................... 48 2.3.3 Control y Monitorización basados en valor ....................................................................... 50 2.3.4 Validación, verificación y gestión de riesgos basados en valor ......................................... 52
2.3.4.1 Pruebas ........................................................................................................................... 52 2.3.4.2 Seguridad ........................................................................................................................ 53
2.3.5 Calidad basada en valor .................................................................................................... 54 2.3.5.1 Trazabilidad .................................................................................................................... 54
2.3.5.2 Fiabilidad y priorización de defectos .............................................................................. 57 2.3.5.3 Revisiones e inspecciones ............................................................................................... 58
2.3.6 Arquitectura basada en valor ............................................................................................. 60 2.3.7 Diseño y desarrollo basados en valor ............................................................................... 62
2.4 ANÁLISIS DE TRABAJOS BASADOS EN VALOR ............................................................................... 65
2.4.1 Relación entre las distintas áreas de la ISBV ..................................................................... 67
2.5 NUEVAS LÍNEAS DE INVESTIGACIÓN IDENTIFICADAS ................................................................... 69
2.5.1 Definición y Ordenación de la ISBV................................................................................... 69 2.5.2 Combinación de Técnicas de Valor .................................................................................... 69 2.5.3 Diseño y Desarrollo Basado en Valor ................................................................................ 70 2.5.4 Mantenimiento Basado en Valor ........................................................................................ 71 2.5.5 Planificación y Gestión de Riesgos Basados en Valor ....................................................... 71
CAPÍTULO 3 – GVAL: UN MÉTODO GENÉRICO DE APLICACIÓN DE VALOR ............. 73
3.1 INTRODUCCIÓN ........................................................................................................................... 73 3.2 ANÁLISIS DE LOS ASPECTOS EN COMÚN DE LAS TÉCNICAS BASADAS EN VALOR .......................... 75
3.2.1 Ejemplo 1: Requisitos y Planificación basados en Valor ................................................... 75 3.2.2 Ejemplo 2: Requisitos y Validación basados en Valor ....................................................... 76
3.2.3 Ejemplo 3: Requisitos y Calidad basada en Valor ............................................................. 76
3.3 DEFINICIÓN DE LAS PARTES QUE COMPONEN EL VALOR ............................................................. 78 3.3.1 Indicadores de Valor .......................................................................................................... 78
3.3.2 Tareas Priorizables ............................................................................................................ 83 3.3.3 Valores límite ...................................................................................................................... 89
3.4 MÉTODO GVAL .......................................................................................................................... 90 3.4.1 Definición de fases y pasos ................................................................................................. 90
3.4.2 Ejemplo de Aplicación: Fase de adaptación al tipo de proyecto ....................................... 93 3.4.2.1 Elicitación de los indicadores y tareas (paso 1) .............................................................. 93
3.4.2.2 Asignación de indicadores a las tareas priorizables (paso 2) .......................................... 94 3.4.3 Ejemplo de Aplicación: Fase de aplicación al proyecto .................................................... 96
3.4.3.1 Evaluación de Indicadores y Definición de Tareas (paso 3) ........................................... 96
3.4.3.2 Ajustar recursos y valores (Paso 4) ................................................................................. 98 3.4.3.3 Inicio de Proyecto (Paso 5) ........................................................................................... 102
3.5 CLASIFICACIÓN DE LOS TRABAJOS SEGÚN GVAL ..................................................................... 103
3.6 APORTACIONES REALIZADAS EN ESTE CAPÍTULO ....................................................................... 105
CAPÍTULO 4 – DISEÑO SOFTWARE BASADO EN VALOR ................................................ 107
4.1 INTRODUCCIÓN ......................................................................................................................... 108 4.2 EL CONCEPTO DE VALOR EN DISEÑO ........................................................................................ 110
4.2.1 Ejemplo de aplicación de mejoras de diseño .................................................................... 110
4.2.2 El problema de la utilización de patrones de diseño ........................................................ 113 4.2.2.1 El valor de la utilización de un patrón .......................................................................... 114
4.2.3 Aproximación sistemática al problema ............................................................................ 115 4.3 GENERALIZACIÓN DEL PROBLEMA: APLICANDO GVAL ............................................................ 117
4.3.1 Indicadores de valor en diseño ......................................................................................... 118
4.3.1.1 Obtención del valor de artefactos de diseño utilizando trazabilidad ............................. 118 4.3.1.2 Influencia de los indicadores en la introducción de indirecciones ................................ 120
4.3.2 Tareas priorizables en diseño ........................................................................................... 121
4.3.2.1 Corrección de violaciones de diseño ............................................................................ 122 4.3.2.2 Aplicación de patrones de diseño ................................................................................. 125
4.4 EJEMPLO DE UTILIZACIÓN ......................................................................................................... 126 4.4.1 Fase I: Adaptación al tipo de proyecto ............................................................................ 126
4.4.2 Fase II: Aplicación al proyecto ........................................................................................ 126 4.4.3 Fase III: Aplicación de Tareas Priorizables .................................................................... 128
4.5 APORTACIONES REALIZADAS EN ESTE CAPÍTULO ..................................................................... 135
CAPÍTULO 5 – MANTENIMIENTO SOFTWARE BASADO EN VALOR ............................ 137
5.1 INTRODUCCIÓN ......................................................................................................................... 137
5.2 EL CONCEPTO DE VALOR EN MANTENIMIENTO ......................................................................... 139 5.2.1 Priorización de las actuaciones de mantenimiento .......................................................... 140 5.2.2 Priorización de dentro de cada actuación de mantenimiento .......................................... 140
5.3 LA REDUCCIÓN DE SOFTWARE (RS) COMO TAREA PRIORIZABLE ............................................. 142 5.3.1 Introducción ..................................................................................................................... 142
5.3.2 El problema del tamaño y la complejidad del software.................................................... 143 5.3.3 Un Primer Ejemplo de RS................................................................................................. 144 5.3.4 Aspectos de Implementación de RS .................................................................................. 148
5.4 GENERALIZACIÓN DEL PROBLEMA: APLICANDO GVAL ............................................................ 151 5.4.1 Indicadores de Valor ........................................................................................................ 151
5.4.1.1 Indicadores objetivos .................................................................................................... 151 5.4.1.2 Indicadores subjetivos .................................................................................................. 155
5.4.2 Tareas priorizables ........................................................................................................... 156
5.5 EJEMPLOS DE APLICACIÓN DE MSBV ........................................................................................ 158 5.5.1 Ejemplo de mantenimiento correctivo .............................................................................. 158 5.5.2 Ejemplo de mantenimiento perfectivo............................................................................... 160
5.6 APORTACIONES REALIZADAS EN ESTE CAPÍTULO ..................................................................... 165
CAPÍTULO 6 – AUTOMATIZACIÓN ......................................................................................... 167
6.1 INTRODUCCIÓN ......................................................................................................................... 167
6.2 GVAL-EX: PRIMEROS PASOS EN GVAL CON EXCEL................................................................ 168 6.3 CONTROL DE LA PRIORIZACIÓN DE TAREAS Y LA RECOGIDA DE DATOS ..................................... 174
6.3.1 Control y priorización de entregables .............................................................................. 174
6.3.2 Conectores de importación de datos ................................................................................ 176 6.3.3 Almacenamiento de los datos de cara a su explotación ................................................... 176
6.4 EXTRACCIÓN DEL INDICADOR DE FRECUENCIA DE USO ............................................................ 180
6.4.1 Herramientas .................................................................................................................... 180
6.4.2 Pruebas de automatización realizadas en la DGT ........................................................... 181 6.5 APORTACIONES REALIZADAS EN ESTE CAPÍTULO ...................................................................... 185
CAPÍTULO 7 – VALIDACIÓN DE PROPUESTAS ................................................................... 187
7.1 SOBRE LA VALIDACIÓN DE TÉCNICAS BASADAS EN VALOR ........................................................ 187
7.1.1 Clasificación de validaciones en trabajos previos ........................................................... 187 7.1.2 Carencias del planteamiento previo ................................................................................. 188
7.2 PLANTEAMIENTO DE VALIDACIÓN EN LA DGT ......................................................................... 190 7.2.1 El desarrollo y mantenimiento de software en la DGT .................................................... 190 7.2.2 El Departamento de Calidad ............................................................................................ 192
7.2.3 Infraestructura de medición y plan de recogida de datos ................................................ 194 7.2.4 Análisis de los datos ......................................................................................................... 196
7.2.4.1 Correlación entre las tareas priorizables y los indicadores ........................................... 196 7.2.4.2 Creación de modelos de predicción de indicadores ...................................................... 198 7.2.4.3 Horizonte temporal de la recogida de datos .................................................................. 199
7.3 MSBV: ANÁLISIS DE VIABILIDAD DE RS ................................................................................... 200 7.3.1 Viabilidad de RS sin datos históricos ............................................................................... 200
7.3.2 Evolución de las métricas de producto con RS ................................................................. 201 7.3.3 Análisis de resultados ....................................................................................................... 203
7.4 APORTACIONES REALIZADAS EN ESTE CAPÍTULO ...................................................................... 204
CAPÍTULO 8 - CONCLUSIONES Y TRABAJO FUTURO ...................................................... 205
8.1 CONCLUSIONES GENERALES ...................................................................................................... 205 8.2 ANÁLISIS DE LA CONSECUCIÓN DE OBJETIVOS .......................................................................... 206 8.3 CONTRASTE DE RESULTADOS .................................................................................................... 208
8.3.1 Capítulos de Libro ............................................................................................................ 208 8.3.2 Conferencias Nacionales .................................................................................................. 208
8.3.3 Conferencias Internacionales ........................................................................................... 208 8.3.4 Revistas Nacionales .......................................................................................................... 209 8.3.5 Revistas Internacionales (pendientes de evaluación) ....................................................... 209 8.3.6 Evolución de la propuesta a lo largo del proceso de investigación ................................. 210
8.3.6.1 Concepto de valor y estado del arte .............................................................................. 210
8.3.6.2 Diseño Software Basado en Valor ................................................................................ 211
8.3.6.3 Mantenimiento Software Basado en Valor ................................................................... 214 8.3.6.4 GVAL: Generalización de la aplicación de valor ......................................................... 214
8.4 LÍNEAS FUTURAS DEL TRABAJO DE INVESTIGACIÓN ................................................................. 215 8.4.1 Aspectos genéricos relacionados con el valor .................................................................. 215 8.4.2 Planificaciones de tareas priorizables ............................................................................. 216 8.4.3 Identificación de automatizaciones futuras ...................................................................... 217
8.4.3.1 Ampliación de GVAL-EX ............................................................................................ 217 8.4.3.2 Propuesta de Herramienta de RS: JMERES ................................................................. 217
8.4.3.3 Automatización de extracción de indicadores objetivos ............................................... 218
ANEXO I - TÉCNICAS AUXILIARES DE SOPORTE AL CÁLCULO DEL VALOR ........... 219
I.I. TÉCNICAS AUXILIARES DE SOPORTE AL CÁLCULO DEL VALOR ................................................... 219
I.II. REGLAS DE DISEÑO Y CODIFICACIÓN ORIENTADAS A OBJETOS ................................................ 220 I.ii.i. Reglas de Diseño versus Reglas de Codificación ............................................................. 220 I.ii.ii. Fuentes de reglas de diseño y código ............................................................................... 221 I.ii.iii. Categorización de las aproximaciones a la detección de reglas ...................................... 224
I.ii.iii.i. Herramientas basadas en AST .................................................................................. 224 I.ii.iii.ii. Herramientas basadas en modelos ............................................................................ 225 I.ii.iii.iii. Herramientas basadas en lenguajes ........................................................................... 226
I.III. PREDICCIÓN DE LA PROBABILIDAD DE CAMBIO ........................................................................ 226
I.iii.i. Métodos Basados en Información Histórica..................................................................... 227 I.iii.i.i. Revisión de la vida completa del proyecto ................................................................... 227 I.iii.i.ii. Revisión de cambios por versión .............................................................................. 228 I.iii.i.iii. Priorización temporal de los cambios ....................................................................... 229 I.i.i.i. Ventajas e inconvenientes ............................................................................................. 230
I.iii.ii. Métodos Basados en Análisis Estático del Diseño ........................................................... 230 I.iii.ii.i. Métodos basados en estructuras estáticas ................................................................. 230 I.iii.ii.ii. Métodos basados en métricas de acoplamiento ........................................................ 232
I.iii.ii.iii. Métodos basados en el tamaño de los artefactos....................................................... 233 I.IV. ESTIMACIÓN DE LA PROBABILIDAD DE USO .............................................................................. 233
I.iv.i. El análisis estático de código ........................................................................................... 234 I.iv.ii. El análisis dinámico de código ......................................................................................... 234
I.V. PREDICCIÓN DE LA PROPENSIÓN AL FALLO ............................................................................... 235 I.VI. TÉCNICAS DE TRAZABILIDAD DE REQUISITOS A DISEÑO ........................................................... 237
ANEXO II - TÉCNICAS AUXILIARES DE SOPORTE AL CÁLCULO DEL VALOR ........... 239
II.I. INTRODUCCIÓN ......................................................................................................................... 239
II.II. TÉCNICAS Y MÉTODOS MÁS HABITUALES DE ELICITACIÓN DE VALOR EN IS .............................. 240 II.ii.i. Analytic Hierarchy Process (AHP)................................................................................... 241
II.III. TEORÍA WIN-WIN ................................................................................................................. 244
ACRÓNIMOS ......................................................................................................................................... 247
REFERENCIAS ..................................................................................................................................... 249
Índice de Ilustraciones
ILUSTRACIÓN 1-1. CORRESPONDENCIA ENTRE ÁREAS DE CONOCIMIENTO DE SWEBOK E ISBV................ 21 ILUSTRACIÓN 1-2. MÉTODO DE INVESTIGACIÓN. FASES. ............................................................................. 28
ILUSTRACIÓN 2-1. CLASIFICACIÓN DE LOS PROYECTOS SEGÚN SU COMPLEJIDAD E INCERTIDUMBRE (LITTLE,
2005) ................................................................................................................................................... 39 ILUSTRACIÓN 2-2. CLASIFICACIÓN DE PROYECTOS SEGÚN COMPLEJIDAD E INCERTIDUMBRE (LITTLE, 2005)
............................................................................................................................................................ 40 ILUSTRACIÓN 2-3. ESQUEMA DE BENEFITS REALIZATION APPROACH-BRA (THORP, 1998) ....................... 41
ILUSTRACIÓN 2-4. ELICITACIÓN DEL VALOR DE CADA REQUISITO (KARLSSON & RYAN, 1997) .................. 44 ILUSTRACIÓN 2-5. ELICITACIÓN DEL COSTE DE CADA REQUISITO (KARLSSON & RYAN, 1997) .................. 45 ILUSTRACIÓN 2-6. DIAGRAMA COSTE-VALOR (KARLSSON & RYAN, 1997) ................................................. 45
ILUSTRACIÓN 2-7. INVERSIÓN NECESARIA PARA LA EJECUCIÓN DE LOS PROYECTOS (CLELAND-HUANG &
DENNE, 2005) ..................................................................................................................................... 48 ILUSTRACIÓN 2-8. MONITORIZACIÓN DE LA PLANIFICACIÓN CON EVA (LI ET AL., 2008) ........................... 51 ILUSTRACIÓN 2-9. ÁRBOL DE UTILIDAD DE REQUISITOS NO FUNCIONALES (LEE & BOEHM, 2005).............. 60
ILUSTRACIÓN 2-10. DIAGRAMA DE CICLO CAUSAL (MUTSCHLER ET AL., 2006) .......................................... 62 ILUSTRACIÓN 2-11. RELACIÓN ENTRE LAS DISTINTAS ÁREAS DE ISBV ....................................................... 67
ILUSTRACIÓN 3-1. ÁRBOL DE INDICADORES DE VALOR .............................................................................. 81 ILUSTRACIÓN 3-2. PRIMER NIVEL DEL ÁRBOL DE TAREAS PRIORIZABLES .................................................. 84 ILUSTRACIÓN 3-3. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE GESTIÓN DE PROYECTOS ............................ 84
ILUSTRACIÓN 3-4. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE DESARROLLO.............................................. 85 ILUSTRACIÓN 3-5. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE REQUISITOS ................................................ 85
ILUSTRACIÓN 3-6. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE CALIDAD .................................................... 86 ILUSTRACIÓN 3-7. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE PRUEBAS .................................................... 86
ILUSTRACIÓN 3-8. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE DISEÑO ....................................................... 87 ILUSTRACIÓN 3-9. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE CODIFICACIÓN ............................................ 87
ILUSTRACIÓN 3-10. SUB-ÁRBOL DE TAREAS PRIORIZABLES DE MANTENIMIENTO ..................................... 88 ILUSTRACIÓN 3-11. FASES Y PASOS DEL MÉTODO GVAL ........................................................................... 92
ILUSTRACIÓN 3-12. EJEMPLO DE DISTRIBUCIÓN DEL PESO DE INDICADORES ............................................... 94 ILUSTRACIÓN 3-13. EJEMPLO DE DISTRIBUCIÓN DE PESOS DE INDICADORES POR TAREA ............................. 95 ILUSTRACIÓN 3-14. EJEMPLO DE EVALUACIÓN DE INDICADORES POR REQUISITO ........................................ 96 ILUSTRACIÓN 3-15. EJEMPLO DE COSTE POR REQUISITO .............................................................................. 98 ILUSTRACIÓN 3-16. ESFUERZO RELATIVO DE LAS TAREAS DE TRAZABILIDAD Y PRUEBAS FUNCIONALES .. 99
ILUSTRACIÓN 3-17. ADAPTACIÓN DE LOS LÍMITES DE VALOR ................................................................... 100 ILUSTRACIÓN 3-18. EVOLUCIÓN DEL COSTE CON LAS VARIACIONES DE LÍMITE ........................................ 102 ILUSTRACIÓN 4-1. VARIAS SOLUCIONES DE DISEÑO DAN RESPUESTA LOS MISMOS REQUISITOS ................ 108 ILUSTRACIÓN 4-2. DISEÑO ALTERNATIVO 1 .............................................................................................. 110 ILUSTRACIÓN 4-3. DISEÑO ALTERNATIVO 2 .............................................................................................. 111
ILUSTRACIÓN 4-4. DISEÑO ALTERNATIVO 3 .............................................................................................. 112 ILUSTRACIÓN 4-5. IMPACTO DE LOS PATRONES EN UN DISEÑO .................................................................. 114
ILUSTRACIÓN 4-6. PRIORIZACIÓN DE MEJORAS DE DISEÑO ........................................................................ 116 ILUSTRACIÓN 4-7. INDICADORES DE VALOR CON INFLUENCIA EN LOS DISEÑOS ......................................... 120 ILUSTRACIÓN 4-8. IDENTIFICACIÓN DE MEJORAS EN UN DISEÑO................................................................ 122 ILUSTRACIÓN 4-9. ELECCIÓN DE INDICADORES Y REQUISITOS PARA APLICAR TRAZABILIDAD .................. 127 ILUSTRACIÓN 4-10. DISEÑO ANTES DE LA APLICACIÓN DE DSBV ............................................................. 129
ILUSTRACIÓN 4-11. DISTRIBUCIÓN DE PESOS DE INDICADORES POR TAREA DE DISEÑO ............................ 130
ILUSTRACIÓN 4-12. VIOLACIONES ENCONTRADAS EN EL DISEÑO ANTES DE LA APLICACIÓN DE DSBV..... 130
ILUSTRACIÓN 4-13. DISTRIBUCIÓN DE INDICADORES POR CLASE DE DISEÑO ............................................ 131 ILUSTRACIÓN 4-14. ESCENARIOS DE LÍMITE DE VALOR PARA LA APLICACIÓN DE TAREAS DE DISEÑO ...... 132 ILUSTRACIÓN 4-15. DISEÑO TRAS LA APLICACIÓN DE DSBV .................................................................... 133 ILUSTRACIÓN 4-16. EVOLUCIÓN DEL COSTE CON LAS VARIACIONES DE LÍMITE EN DSBV ........................ 134 ILUSTRACIÓN 5-1. MODELO CLÁSICO (IZQUIERDA) VS MODELO PROPUESTO (DERECHA) EN LA EVOLUCIÓN
DEL TAMAÑO ..................................................................................................................................... 144 ILUSTRACIÓN 5-2. EJEMPLO SIMPLE DE MODELO DE CLASES A OPTIMIZAR ................................................ 145 ILUSTRACIÓN 5-3. EJEMPLO SIMPLE DE MODELO DE CLASES OPTIMIZADO ................................................ 146 ILUSTRACIÓN 5-4. VUELTA ATRÁS EN UNA SIMPLIFICACIÓN DE DISEÑO .................................................... 147 ILUSTRACIÓN 5-5. ARTEFACTOS NO USADOS ............................................................................................. 148
ILUSTRACIÓN 5-6. PROCESO DE BORRADO LÓGICO ................................................................................... 149 ILUSTRACIÓN 5-7. SUB-ÁRBOL DE INDICADORES OBJETIVOS ................................................................... 152
ILUSTRACIÓN 5-8. PESOS DE INDICADORES PARA LA EJECUCIÓN DE PETICIONES DE MANTENIMIENTO ...... 159
ILUSTRACIÓN 5-9. EVALUACIÓN DE INDICADORES POR PETICIÓN DE MANTENIMIENTO ............................. 159 ILUSTRACIÓN 5-10. PESOS DE INDICADORES PARA MANTENIMIENTO PERFECTIVO .................................... 161 ILUSTRACIÓN 5-11. EVALUACIÓN DE INDICADORES POR MANTENIMIENTO PERFECTIVO ........................... 162 ILUSTRACIÓN 5-12. ADAPTACIÓN DE LOS LÍMITES DE VALOR PARA EL MANTENIMIENTO PERFECTIVO ...... 163
ILUSTRACIÓN 5-13. EVOLUCIÓN DEL COSTE CON LAS VARIACIONES DE LÍMITE EN MANTENIMIENTO
PERFECTIVO ....................................................................................................................................... 164
ILUSTRACIÓN 6-1. PASOS A AUTOMATIZAR EN GVAL .............................................................................. 168 ILUSTRACIÓN 6-2. ELECCIÓN DE TAREAS PRIORIZABLES CON GVAL-EX .................................................. 169 ILUSTRACIÓN 6-3. ELECCIÓN DE INDICADORES CON GVAL-EX ................................................................ 170
ILUSTRACIÓN 6-4. RELACIÓN INDICADOR-TAREA CON GVAL-EX ............................................................ 170 ILUSTRACIÓN 6-5. RELACIÓN INDICADOR-TAREA NORMALIZADO CON GVAL-EX .................................... 171 ILUSTRACIÓN 6-6. ASIGNACIÓN DE VALOR A LOS ARTEFACTOS CON GVAL-EX ...................................... 171 ILUSTRACIÓN 6-7. VALOR NORMALIZADO DE LOS ARTEFACTOS CON GVAL-EX ...................................... 172
ILUSTRACIÓN 6-8. VALOR DE CADA TAREA CON GVAL-EX ..................................................................... 172 ILUSTRACIÓN 6-9. CREACIÓN DE ESCENARIOS CON GVAL-EX ................................................................. 173 ILUSTRACIÓN 6-10. INTERFAZ DE ADMINISTRACIÓN DE LA APLICACIÓN DE SOPORTE A AUDITORÍAS ........ 175 ILUSTRACIÓN 6-11. INTERFAZ DE EJECUCIÓN DE CHEQUEOS DE LA APLICACIÓN DE SOPORTE A AUDITORÍAS
.......................................................................................................................................................... 175 ILUSTRACIÓN 6-12. ESCENARIO INICIAL DE INFRAESTRUCTURA DE LA DGT ............................................ 182 ILUSTRACIÓN 6-13. ESCENARIO FINAL DE INFRAESTRUCTURA DE LA DGT ............................................... 183 ILUSTRACIÓN 7-1. INFRAESTRUCTURA DE VALIDACIÓN DEL DEPARTAMENTO DE CALIDAD DE LA DGT .. 195 ILUSTRACIÓN 7-2. CÓDIGO NO USADO POR PROYECTO DGT ANALIZADO .................................................. 201
ILUSTRACIÓN 8-1. DISTINTOS TIPOS DE REGLAS Y SU MOMENTO DE APLICACIÓN (CABRERO ET AL., 2008B)
.......................................................................................................................................................... 212 ILUSTRACIÓN 8-2. REGLAS DE DISEÑO SEGÚN PROBABILIDAD DE CAMBIO E IMPORTANCIA (CABRERO ET
AL., 2007A) ....................................................................................................................................... 212 ILUSTRACIÓN 8-3. ADAPTACIÓN DE LOS LÍMITES DE VALOR PARA EL MANTENIMIENTO PERFECTIVO ........ 218
ILUSTRACIÓN 8-4. COMPARATIVA DE MÉTODOS DE PREDICCIÓN DE CAMBIO (TSANTALIS ET AL., 2005) .. 232 ILUSTRACIÓN 8-5. TEORÍA WIN-WIN ........................................................................................................ 245
Índice de Tablas
TABLA 1-1. DATOS MÁS RELEVANTES DEL PROYECTO COORDINADO META .............................................. 23 TABLA 1-2. DATOS MÁS RELEVANTES DEL PROYECTO IDONEO ................................................................ 24 TABLA 1-3. ROLES IDENTIFICADOS EN LA INVESTIGACIÓN / ACCIÓN .......................................................... 28 TABLA 2-1. EL MÉTODO DE LA MOCHILA (JUNG, 1998) ............................................................................... 46 TABLA 2-2. MATRIZ DE CONEXIÓN PARA LA TOMA DE DECISIONES (OMASREITER, 2007) ........................... 49
TABLA 2-3. VARIACIÓN DEL NIVEL DE TRAZABILIDAD SEGÚN EL VALOR (EGYED ET AL., 2005) ................. 55 TABLA 2-4. EVALUACIÓN DEL VALOR DE LOS REQUISITOS (HEINDL & BIFFL, 2005) .................................. 55 TABLA 2-5. MATRIZ DE PRIORIZACIÓN DE REVISIONES MANUALES (LEE & BOEHM, 2005) ......................... 58 TABLA 2-6. ANÁLISIS DE MODULARIDAD CON NOV. PASO 1 (MUTSCHLER ET AL., 2006) .......................... 63 TABLA 2-7. ANÁLISIS DE MODULARIDAD CON NOV. PASO 2 (MUTSCHLER ET AL., 2006) .......................... 63
TABLA 2-8. ANÁLISIS POR ÁREAS DE LOS TRABAJOS BASADOS EN VALOR ENCONTRADOS .......................... 65 TABLA 3-1. EJEMPLO DE ASIGNACIÓN DE INDICADORES A LAS TAREAS PRIORIZABLES ............................... 94 TABLA 3-2. VALOR OBTENIDO POR REQUISITO Y TAREA ............................................................................. 97
TABLA 3-3. ESCENARIOS DE APLICACIÓN DE GVAL ................................................................................. 101
TABLA 3-4. CLASIFICACIÓN DE TRABAJOS SEGÚN GVAL ......................................................................... 103 TABLA 4-1. CATÁLOGO DE REGLAS (GARZÁS & PIATTINI, 2005) QUE CORRESPONDEN A TAREAS
PRIORIZABLES ................................................................................................................................... 124
TABLA 4-2. RESUMEN DE LOS REQUISITOS A TRAZAR ............................................................................... 127 TABLA 4-3. TRAZADO DE LA PROBABILIDAD DE CAMBIO A LAS CLASES DE DISEÑO .................................. 128
TABLA 4-4. VALOR DE LAS TAREAS PRIORIZABLES PARA CADA CLASE ..................................................... 131 TABLA 4-5. APLICACIÓN DE LOS ESCENARIOS A LAS MEJORAS DE DISEÑO ................................................ 132 TABLA 5-1. NÚMERO DE INVOCACIONES POR ARTEFACTOS. ...................................................................... 145
TABLA 5-2. VALOR OBTENIDO POR PETICIÓN DE MANTENIMIENTO Y TAREA ............................................. 160
TABLA 5-3. VALOR OBTENIDO POR MANTENIMIENTO PERFECTIVO Y TAREA ............................................. 162 TABLA 5-4. VALOR Y COSTE OBTENIDO EN MANTENIMIENTO PERFECTIVO................................................ 163 TABLA 7-1. DATOS HISTÓRICOS DE INDICADORES Y EJECUCIÓN DE TAREAS ............................................. 197
TABLA 7-2. DATOS DE CORRELACIÓN ENTRE TAREAS PRIORIZABLES E INDICADORES ............................... 197 TABLA 7-3. MÉTRICAS DE PRODUCTO A APLICAR EN LA EVALUACIÓN DE RS ........................................... 202
TABLA 7-4. MÉTRICAS DE PRODUCTO ANTES Y DESPUÉS DE RS ................................................................ 202 TABLA 8-1. CONSECUCIÓN DE OBJETIVOS. ............................................................................................... 207
TABLA 8-2. SELECTORES DE CAMBIO DE AHCP (CABRERO ET AL., 2008A) .............................................. 213 TABLA 8-3. EJEMPLO DE APLICACIÓN DE AHCP (CABRERO ET AL., 2008A) ............................................. 214 TABLA 8-4. CATÁLOGO DE REGLAS DE DISEÑO Y SU EFECTO .................................................................... 222 TABLA 8-5. HISTÓRICO DE CAMBIOS DE LA VIDA COMPLETA DE UN PROYECTO ........................................ 227 TABLA 8-6. HISTÓRICO DE CAMBIOS DE UN PROYECTO POR VERSIÓN ........................................................ 228
TABLA 8-7. NÚMERO DE CAMBIOS ESTIMADOS PARA LA PRÓXIMA VERSIÓN ............................................. 228 TABLA 8-8. PASO 2 DE AHP ...................................................................................................................... 241
TABLA 8-9. PASO 3 DE AHP ...................................................................................................................... 242 TABLA 8-10. DIVISORES POR NÚMERO DE FILAS DE LA MATRIZ PARA CALCULAR RC ............................... 243 TABLA 8-11. ACRÓNIMOS ......................................................................................................................... 248
Índice de Definiciones DEFINICIÓN 1. INDICADOR DE VALOR ......................................................................................................... 79 DEFINICIÓN 2. INDICADORES SUBJETIVOS Y OBJETIVOS .............................................................................. 79 DEFINICIÓN 3. TAREA PRIORIZABLE............................................................................................................ 83 DEFINICIÓN 4. VALOR LÍMITE ..................................................................................................................... 89
Índice de Ecuaciones ECUACIÓN 1. CÁLCULO DE COMPLEJIDAD E INCERTIDUMBRE AGREGANDO ATRIBUTOS (LITTLE, 2005) ..... 39 ECUACIÓN 2. RETORNO DE INVERSIÓN ........................................................................................................ 42 ECUACIÓN 3. CÁLCULO DEL RIESGO ASOCIADO A CADA REQUISITO (CLELAND-HUANG ET AL., 2004) ....... 56
ECUACIÓN 4. ECUACIÓN GENERAL DE VALOR CON NOV ............................................................................ 63 ECUACIÓN 5. ESTIMACIÓN DE CADA MIEMBRO DE LA ECUACIÓN GENERAL CON NOV ................................ 64
ECUACIÓN 6. OBTENCIÓN DEL VALOR ASOCIADO A UNA TAREA ................................................................. 97 ECUACIÓN 8-1. PROBABILIDAD DE CAMBIO DE LA PRÓXIMA VERSIÓN ...................................................... 228 ECUACIÓN 8-2. MÉTRICA ENOM ENTRE DOS SUBVERSIONES CONSECUTIVAS .......................................... 229
ECUACIÓN 8-3. MÉTRICA ENOM ENTRE DOS SUBVERSIONES (ENOM J...K) ............................................... 229 ECUACIÓN 8-4. MÉTRICA LENOM ENTRE DOS SUBVERSIONES (LENOM J...K) .......................................... 229
ECUACIÓN 8-5. MÉTRICA EENOM ENTRE DOS SUBVERSIONES (EENOM J...K) .......................................... 230
ECUACIÓN 8-6. ÍNDICE DE CONSISTENCIA EN AHP ................................................................................... 242
ECUACIÓN 8-7. CÁLCULO DE MAX. PASO 1. ............................................................................................... 242
ECUACIÓN 8-8. CÁLCULO DE MAX. PASO 2. ............................................................................................... 243
ECUACIÓN 8-9. CÁLCULO DE MAX. PASO 3. ............................................................................................... 243
Tesis Doctoral Daniel Cabrero Moreno
15
Capítulo 1 - Introducción
1.1 Justificación y Planteamiento de este Trabajo
“Los sistemas de información son únicamente facilitadores, que deben ser
aplicados adecuadamente para obtener valor real de negocio” (Chikofsky et al., 2007). Así
comenzaba la presentación inaugural de la conferencia internacional IEEE EQUITY 2007, que
ponía especial énfasis en cómo lograr que los sistemas software aporten un valor real a los
intereses de los usuarios.
Todas las organizaciones asumen que los sistemas de información no son un fin sino un
medio. Las Tecnologías de Información son una forma de incrementar la relación coste-
beneficio de una tarea, o posibilitar la realización de tareas inviables de otro modo. De todos los
aspectos que propician la implantación de un sistema de información, que típicamente son las
comunicaciones, hardware y software, es el software el que tiene mayor capacidad y
flexibilidad para orientar la solución tecnológica al valor real de negocio (Boehm &
Sullivan, 2000).
Indudablemente, el hardware y las comunicaciones son un requisito imprescindible para
el correcto funcionamiento de los sistemas de información, pero ofrecen un servicio homogéneo
sobre el que el software se encarga de ofrecer la variedad de funcionalidades que las
organizaciones necesitan. El software es el que aporta más o menos valor al negocio
dependiendo de cómo se oriente su desarrollo, mantenimiento, y puesta a disposición de los
usuarios.
Paradójicamente, siendo el software el mayor facilitador tecnológico, existen muy pocas
propuestas orientadas a analizar y maximizar el valor que el software aporta a las
organizaciones. Se puede afirmar incluso, que la aplicación en la industria del software
del concepto de valor es prácticamente inexistente.
El desarrollo de software es, a día de hoy, esencialmente visto desde un enfoque de
valor neutro, donde las distintas partes que lo componen suelen tener la misma importancia
para el equipo de desarrollo. La metodología de desarrollo, el tipo de diseño, el tipo de
arquitectura, o la metodología de gestión de riesgos, raramente dependen de la importancia
que los distintos implicados en el sistema asignen a cada artefacto software. Y en los pocos
casos en que sí sucede (como por ejemplo, excepcionalmente en la priorización de pruebas), no
existe un enfoque sistemático que soporte la aplicación de la variabilidad de manera
determinista, quedando ésta a criterio de la experiencia de los responsables del desarrollo.
Tesis Doctoral Daniel Cabrero Moreno
16
Con el objetivo de cubrir todas las necesidades relacionadas expuestas, Boehm
estableció recientemente una nueva reaproximación a la ingeniería del software, que recibe el
nombre de Ingeniería del Software Basada en Valor (ISBV) 1 (Boehm, 2003). Esta nueva
orientación se basa en que no todos los elementos del desarrollo software tienen el mismo valor
relativo, sino que existen partes que aportan más valor que otras. La ISBV pretende elaborar
técnicas y prácticas que formalicen y cuantifiquen cuánto valor aporta cada una de ellas para
cada uno de los afectados por los sistemas.
El campo de investigación que se abre en la adaptación de cada una de las técnicas de
Ingeniería del Software a las consideraciones de valor aportado a los implicados es enorme. Por
este motivo, Boehm estableció posteriormente una hoja de ruta (Boehm, 2005b), que
pretendía ordenar las distintas aportaciones realizadas en este sentido en diversas sub-áreas de
investigación (requisitos, diseño, arquitectura, validación y verificación, gestión de riesgos,
gestión de la calidad, planificación y control, y gestión de personal).
En el año 2009, pocos años después de la definición de la hoja de ruta, varios trabajos
pertenecientes a las áreas mencionadas han sido ya presentados. Probablemente, debido al
poco tiempo transcurrido, existen carencias muy importantes en la aplicación de este tipo de
ingeniería, que sugieren diversas oportunidades de mejora en el área de la ISBV:
No existe una visión global de todos los trabajos presentados en el ámbito de la
ISBV. Existen revisiones de literatura aisladas realizadas para aspectos concretos de
la IS, donde en algunos casos se hace referencia al valor. Sin embargo, se echa en
falta una revisión de literatura que resuma los trabajos realizados hasta la fecha en
el ámbito de la ISBV, que permita identificar oportunidades de mejora.
No existe una definición de los elementos mínimos de orientación a valor que
deben tener las técnicas de IS basadas en valor, para que puedan ser consideradas
como tal. ¿Debe involucrarse a los implicados? ¿Debe prever varias formas de
aplicación dependiendo de sus percepciones? ¿Cómo llevar a cabo de manera
determinista dichas variaciones en las tareas de IS? No existe a día de hoy
respuestas claras a estas preguntas.
No existe una manera sistemática de aplicar los conceptos de valor en los
distintos ámbitos. Cada autor tiene conceptos distintos de cómo aplicar el valor, y
no existe ningún nexo de unión que relacione las distintas técnicas.
Como consecuencia de lo anterior, no es posible combinar las distintas
técnicas encontradas en la literatura. Esto dificulta la aplicación industrial de las
técnicas, ya que un jefe de proyecto normalmente necesitará orientar el valor a
varios aspectos del desarrollo a la vez, no únicamente a un solo aspecto como la
trazabilidad o las pruebas.
1 Conocida también por sus siglas en inglés VBSE (Value-Based Software Engineering)
Tesis Doctoral Daniel Cabrero Moreno
17
No existe el concepto de Mantenimiento Basado en Valor.
Aunque existe un área definida por Boehm para el diseño y desarrollo software, no
se ha definido claramente el concepto de Diseño Basado en Valor. Tampoco se
ha presentado ninguna propuesta de técnica que aborde este aspecto, y mucho
menos, se ha ejemplificado sobre diseños reales su aplicación.
No se han presentado trabajos basados en valor en varias de las áreas, en concreto
en las de planificación y control, y gestión de riesgos. Se echa en falta una
unificación de la aplicación del valor que permita variar la aplicación de cualquier
técnica de IS en función del valor que los implicados asignen.
Con estas carencias en mente, se pretende realizar una revisión del estado del arte en
las materias expuestas, estudiar sus carencias, y proponer métodos sistemáticos de
construcción y evolución de aplicaciones que tengan en cuenta consideraciones de valor, y que
aborden las mejoras potenciales de investigación descritas.
Tesis Doctoral Daniel Cabrero Moreno
18
1.2 Hipótesis y Objetivo
Teniendo en cuenta lo expuesto anteriormente, nuestra hipótesis es que:
Así, de forma resumida, el principal objetivo de este trabajo de investigación es:
Lo que plantea los siguientes sub-objetivos para este trabajo:
Objetivo 1. Estudiar el estado del arte y propuestas de la Ingeniería del Software
Basada en Valor. Identificar nichos de investigación potenciales.
Objetivo 2. Definir el concepto de “técnica basada en valor”, y proponer una serie
de requisitos mínimos que una técnica debe tener para considerarse basada en
valor.
Objetivo 3. Proponer un método sistemático de aplicación de valor que permita la
combinación de las distintas técnicas.
Objetivo 4. Proponer técnicas para la aplicación práctica del Diseño Software
Basado en Valor.
Objetivo 5. Proponer técnicas para la aplicación práctica del Mantenimiento
Software Basado en Valor.
Es factible realizar de forma sistemática la aplicación de los
principios de la Ingeniería del Software Basada en Valor para
construir y evolucionar sistemas
Proponer un conjunto de técnicas sistemáticas para llevar
a cabo la construcción y evolución del software teniendo
en cuenta el valor que las decisiones aportan a los
distintos stakeholders
Tesis Doctoral Daniel Cabrero Moreno
19
Objetivo 6. Desarrollar herramientas que faciliten la aplicación de las técnicas y
principios basados en valor.
Objetivo 7. Validar los conceptos y técnicas presentados.
Tesis Doctoral Daniel Cabrero Moreno
20
1.3 Áreas de conocimiento implicadas
Para acotar más, y con el objetivo de evitar ambigüedades, se tomará como marco de
referencia el proyecto SWEBOK (Bourque et al., 1999), que ordena todo el conocimiento de
ingeniería del software en una ontología acordada en el seno del IEEE, y cuya versión actual
fue liberada en 2004 (la nueva versión de SWEBOK prevé publicarse a lo largo de 2009). Según
este proyecto, el conocimiento en Ingeniería del Software está organizado en 10 Áreas de
Conocimiento: Requisitos, Diseño, Construcción, Pruebas, Mantenimiento, Gestión de la
Configuración, Gestión de proyectos, Ingeniería de Procesos, Herramientas y Métodos, y
Calidad.
Es interesante resaltar la similitud entre las áreas de conocimiento de SWEBOK, y las
áreas de conocimiento basado en valor definidas por Boehm que se han comentado
anteriormente, y que son presentadas en detalle en la página 35. Seis son comunes a ambas
clasificaciones (de las 10 y 8 áreas definidas, respectivamente). Se puede decir que se trata de
dos visiones distintas de clasificación de todo el conocimiento que afecta a la Ingeniería del
Software, lo que implica que la ISBV es un área de conocimiento transversal, que no
puede ser encajada en ninguna sub-área concreta.
Como se ha comentado anteriormente, este trabajo tiene diversas aportaciones, cada
una de ellas, situada en un área de conocimiento diferente. Los conceptos y técnicas globales
de orientación al valor aplican a todas las áreas de conocimiento de SWEBOK. No obstante,
cada una de las distintas partes que compone la ISBV, sí pueden ser mapeadas a áreas
concretas de conocimiento definidas en SWEBOK. El Diseño Basado en Valor, aplicaría a área de
diseño, el Mantenimiento Basado en Valor, al área de mantenimiento, y así sucesivamente.
La Ilustración 1-1 muestra la correspondencia entre áreas de conocimiento. En la parte
izquierda se sitúan las áreas de conocimiento de ISBV definidas por Boehm, y en la parte
derecha, las definidas en SWEBOK por el IEEE. La arquitectura es definida por ejemplo por
Boehm como un área diferenciada, mientras que en SWEBOK forma parte del área de diseño.
Por el contrario, el diseño y la construcción definidas como áreas diferenciadas, son vistas como
una sola área por Boehm.
Todas las áreas de ISBV, salvo la de “personal”, están relacionadas con algún área de
SWEBOK. Tampoco se ha encontrado ningún trabajo de ISBV de personal. Probablemente se
deba a que, aun siendo un elemento previsto por Boehm para la clasificación de trabajos, es un
aspecto más encuadrado en el área de recursos humanos que en el de Ingeniería.
Tesis Doctoral Daniel Cabrero Moreno
21
Ilustración 1-1. Correspondencia entre áreas de conocimiento de SWEBOK e ISBV
Se pueden encontrar 4 áreas de SWEBOK no identificadas por Boehm.
El área de mantenimiento (que más adelante en este trabajo se propondrá
como nueva área de ISBV),
El área de herramientas, que es demasiado genérica para identificar técnicas de
aplicación de valor. Se puede plantear que, más bien, las técnicas basadas en valor
de todas las áreas podrán ser automatizadas mediante herramientas.
El área de Gestión de la Configuración, donde las aproximaciones centradas
en valor no han sido planteadas, y tienen dudosa aplicabilidad.
El área de Ingeniería de Procesos, donde únicamente se ha encontrado un
trabajo (Mutschler et al., 2006), que se describirá en detalle en el estado del arte.
El resto de las áreas tienen equivalencia entre las dos clasificaciones.
Como puede verse, se trata de una rama de conocimiento muy amplia, que abarca
distintas áreas. En las conclusiones de la revisión del estado del arte, se verá que no todas las
áreas de conocimiento han sido abordadas. Una vez más, esto revela carencias muy
importantes en el estado de madurez de las propuestas basadas en valor, ya que no existen
propuestas para muchas de las áreas definidas en ambas clasificaciones de conocimiento,
como por ejemplo, el diseño o el mantenimiento.
Nótese que este trabajo se centra en la construcción y evolución de software, y que la
aplicación del valor en las áreas de herramientas, gestión de configuración e ingeniería
de procesos, ha sido considerara fuera del alcance de esta investigación. Estas áreas
Tesis Doctoral Daniel Cabrero Moreno
22
son transversales a la gran mayoría de prácticas de ingeniería de software, que típicamente se
realizarán apoyándose en herramientas, utilizando una gestión de configuración sobre sus
productos, e implementando procesos. Por este motivo no se incluirán en posteriores análisis de
áreas de conocimiento ni clasificaciones de trabajos.
Tesis Doctoral Daniel Cabrero Moreno
23
1.4 Entorno de desarrollo de este Trabajo
Las aportaciones presentadas en este trabajo se han desarrollado en al marco de los
proyectos coordinados META e IDONEO, que se describen a continuación.
1.4.1 El proyecto coordinado META (proyecto ESFINGE)
El proyecto META del que forma parte ESFINGE, tiene como objetivo global definir y
realizar un marco tecnológico industrial, formal y de desarrollo de software complejo (desde
requisitos hasta código) de alta calidad, aplicarlo usando distintos paradigmas de modelado y
proceso y sobre distintos dominios de aplicación. En dicho marco las transformaciones y
equivalencias entre artefactos software estarán formalmente soportadas (QVT+OCL), con
métricas de calidad asociadas y trazabilidad bidireccional que permita definir procesos de
desarrollo de software bien fundados.
El proyecto conjuga los estándares industriales (OMG: MOF, QVT, OCL,…) con métodos
formales consolidados (sistemas de reescritura condicional de términos: MAUDE u otros) que
permitan validar y verificar propiedades de artefactos y transformaciones (procesos) y se hará
público sobre plataformas de interoperación (por ejemplo, ECLIPSE) o tecnologías propietarias
(Microsoft DSL tools, IBM Rational Software Architect). En este entorno de trabajo, se han
estudiado además las nuevas tendencias de construcción y mantenimiento de sistemas, entre
los que se encuentra la Ingeniería del Software Basada en Valor.
El objetivo pragmático es aumentar la productividad en el desarrollo de software, así
como incrementar la calidad del código generado de forma automática a partir de los modelos y
facilitar su evolución, además, mejorar la portabilidad de los productos software a nuevas
plataformas tecnológicas, y aumentar la interoperabilidad de las aplicaciones a través de
estándares de intercambio de datos. Los datos más relevantes del proyecto se muestran a
continuación.
Proyecto ESFINGE
Proyecto coordinado META
Participantes Universidad Politécnica de Valencia, Universidad de Murcia,
Universidad de Cartagena, European Software Institute,
Universidad de Castilla-La Mancha
Investigador Principal Dr. D. Mario Piattini
Investigador principal
proyecto coordinado
Dr. D. Isidro Ramos
Duración diciembre 2006 - diciembre 2008
Programa TIN (Ref. : TIN 2006-15175-C05-05)
Financiación Ministerio de Educación y Ciencia
Tabla 1-1. Datos más relevantes del proyecto coordinado META
Tesis Doctoral Daniel Cabrero Moreno
24
1.4.2 El proyecto IDONEO
El proyecto IDONEO tiene por objeto estudiar la influencia que la ISBV puede tener
sobre las Líneas de Producto Software (LPS). Las tareas que son parte del alcance del mismo,
se definen a continuación:
Definir una metodología para evaluar la calidad de las LPS, partiendo de la definición de
un modelo de calidad y refinándolo hasta la definición de medidas que permitan medir
cada una de las características de dicho modelo de manera objetiva.
Evaluar el valor que proporciona el incorporar el paradigma de LPS en el desarrollo de
software a través de la Ingeniería de Software basada en Valor (ISBV).
Evaluar las diferentes metodologías propuestas para la producción de software basada
en LPS.
Los contenidos de esta Tesis Doctoral contribuyen a apuntar la aplicación metodológica
de la ISBV en contextos de LPS. La contribución más importante al proyecto de investigación es
la revisión del estado del arte en ISBV, así como la aplicación del método “GVAL” descrito en
este trabajo, para el que se propondrán aplicaciones concretas a las LPS.
Los datos más relevantes del proyecto se muestran a continuación.
Proyecto IDONEO (Ingeniería de Software basada en Valor y Calidad
en Líneas de Producto)
Participantes Universidad de Castilla-La Mancha, Universidad del País
Vasco, Universidad Rey Juan Carlos
Investigador Principal Dra. Marcela Genero Bocco
Duración mayo 2006 - diciembre 2008
Programa Plan Regional de Investigación Científica, Desarrollo
Tecnológico e Innovación de Castilla-La Mancha
Financiación Conserjería de Educación, Junta de Comunidades de Castilla-
La Mancha
Tabla 1-2. Datos más relevantes del proyecto IDONEO
Tesis Doctoral Daniel Cabrero Moreno
25
1.4.3 Colaboración con la Dirección General de Tráfico
La propuesta de necesidades y el contraste de la utilidad de las propuestas han sido
realizados en el ámbito del desarrollo de software, en la Gerencia de Informática de la
Dirección General de Tráfico (DGT), responsable en España del tratamiento de toda la
información de vehículos, conductores, sanciones y pagos de multas y tasas. El software
desarrollado y mantenido en la DGT comprende unos 100 proyectos software, desarrollados por
más de 200 personas, repartidas en 20 proveedores distintos de servicios de desarrollo
software.
La DGT cuenta además con un departamento de Calidad software, que audita los
trabajos presentados por todos los proveedores, y los certifica. En el marco de dichas
comprobaciones, el Departamento de Calidad establece las prácticas de obligada
implementación por todos los adjudicatarios. Como es lógico, en este contexto, según se
incrementa el número de prácticas de obligado cumplimiento para los adjudicatarios, mayor es
el coste de los proyectos de desarrollo software.
Por ese motivo, se planteó la necesidad de establecer una colaboración entre la
Universidad de Castilla-la-Mancha y la DGT en la aplicación de métodos que guiasen el valor
aportado por las prácticas exigidas a los distintos adjudicatarios. El objetivo de dicha
colaboración era, por tanto, cubrir una necesidad real identificada en la factoría software de la
DGT.
La validación de las distintas propuestas presentadas en el Capítulo 7 ha sido también
realizada en colaboración con la DGT. En el caso de la verificación de la técnica de Reducción
de Software (página 200), la DGT ha proporcionado datos pertenecientes a proyectos reales.
Como se ha comentado, tanto la elicitación de la necesidad, como las validaciones de
propuestas, han sido elaboradas en colaboración con la DGT, en el marco de la Investigación-
Acción presentada en la siguiente sección.
Tesis Doctoral Daniel Cabrero Moreno
26
1.5 Método de investigación
1.5.1 Descripción
Actualmente, existen diferentes métodos de investigación cualitativa, entre los que
destaca el método Investigación-Acción. El término “Investigación-Acción” proviene del autor
Kart Lewin (Lewin, 1947) que lo utilizaba para describir una forma de investigación que podía
enlazar el enfoque experimental de las ciencias sociales con programas de acción social que
respondieran a los problemas sociales principales de entonces. Mediante la Investigación-
Acción, Lewin argumentaba que se podían lograr en forma simultánea avances teóricos y
cambios sociales. A pesar de que la primera propuesta de Investigación-Acción fue introducida
en 1985 (Wood-Harper, 1985), en los últimos años ha obtenido una gran atención y aceptación
por parte de la comunidad investigadora en Sistemas de Información (Avison et al., 1999,
Seaman, 1999).
En realidad, Investigación-Acción no se refiere a un método de investigación concreto,
sino a una clase de métodos que tienen en común las siguientes características (Baskerville,
1999):
1) Orientación a la acción y al cambio;
2) Focalización en un problema;
3) Un modelo de proceso “orgánico” que engloba etapas sistemáticas y algunas veces
iterativas; y
4) Colaboración entre los participantes.
Se define este método de investigación como “la forma que tienen los grupos de
personas de preparar las condiciones necesarias para aprender de sus propias experiencias, y
hacer estas experiencias accesibles a otros” (McTaggart, 1991).
La Investigación-Acción tiene una doble finalidad: generar un beneficio al “cliente” de
la investigación y, al mismo tiempo, generar “conocimiento de investigación” relevante (Kock &
Lau, 2001). Por tanto, Investigación-Acción es una forma de investigar de carácter colaborativo,
que busca unir teoría y práctica entre investigadores y profesionales mediante un proceso de
naturaleza cíclica.
La Investigación-Acción está orientado a la producción de nuevo conocimiento útil en la
práctica, que se obtiene mediante el cambio y/o búsqueda de soluciones a situaciones reales
que le ocurren a un grupo de profesionales (Avison et al., 1999). Esto se consigue gracias a la
intervención de un investigador en la realidad del mencionado grupo. Los resultados de esta
experiencia deben ser beneficiosos tanto para el investigador como para los profesionales. Una
premisa fundamental en esta forma de investigar es que los procesos sociales complejos
Tesis Doctoral Daniel Cabrero Moreno
27
pueden ser estudiados mejor, introduciendo cambios en dichos procesos y observando los
efectos de dichos cambios (Baskerville, 1999).
En el campo de los Sistemas de Información, el cliente de una investigación es
normalmente una organización a la cual el investigador suministra servicios tales como
consultoría, ayuda para cambiar o desarrollo de software, a cambio de tener acceso a datos de
interés para la investigación y, en muchos casos, de recibir financiación (Kock & Lau, 2001). En
cualquier caso, el investigador que utiliza Investigación-Acción en Sistemas de Información (IA-
SI) sirve a dos entidades diferentes: el cliente de la investigación y la comunidad científica de
Sistemas de Información. Las necesidades de ambos suelen ser muy diferentes y, a veces,
opuestas entre sí. Intentar satisfacer ambas demandas es el principal desafío que todos los
investigadores de IA-SI tienen que enfrentar. Sirviendo tanto las necesidades de los
profesionales como las del conocimiento científico, se añaden nuevos elementos a la
investigación que hace que ésta sea más beneficiosa.
1.5.2 Aplicación a este trabajo del método de Investigación-
Acción
El objetivo final de este trabajo de investigación es el “desarrollo de técnicas de
construcción y evolución de software, aplicando los principios de la Ingeniería del Software
Basada en Valor”. En este caso se aplicará el método de Investigación-Acción como resultado
de la colaboración entre la actividad investigadora de la Universidad de Castilla la
Mancha, y su aplicación en el sector público, en el marco de la Gerencia de Informática de
la Dirección General de Tráfico.
Los roles identificados en la Investigación-Acción (Wadsworth, 1998), son el
investigador, el objeto investigado, el grupo crítico de referencia (GCR) y los beneficiarios. La
Tabla 1-3 muestra los roles asociados a nuestro caso concreto.
Nombre del Rol Descripción Rol identificado en nuestro trabajo
Investigador El individuo o grupo que lleva a cabo de
forma activa el proceso investigador
El doctorando, el centro de I+D de Alarcos.
Objeto Investigado El problema a resolver Obtener técnicas sistemáticas de construcción y
mantenimiento basado en valor.
Grupo Crítico de
Referencia (GCR)
Aquel para quien se investiga en el sentido
de que tiene un problema que necesita ser
resuelto y que también participa en el
proceso de investigación (aunque menos
activamente que el investigador)
El conjunto de los ingenieros de software, así como
los gestores de proyectos de tecnologías de la
información de la Gerencia de Informática de la
Dirección General de Tráfico.
Tesis Doctoral Daniel Cabrero Moreno
28
Beneficiarios Aquel para quien se investiga en el sentido
de que puede beneficiarse del resultado de la
investigación, aunque no participa
directamente en el proceso
Cualquier cliente potencial de un sistema de
información, en especial los usuarios finales de la
Dirección General de Tráfico, formada por unos
5.000 usuarios repartidos en Jefaturas de Tráfico y
Servicios Centrales. El ciudadano también es un
beneficiario, ya que muchos de estos sistemas están
destinados a su uso por el público a través de
Internet.
Tabla 1-3. Roles identificados en la Investigación / Acción
La Ilustración 1-2 muestra el flujo de propuesta, validación y refinamiento de
propuestas, involucrando al grupo investigador, el grupo crítico de referencia y los beneficiarios.
El proceso consta de una fase de propuesta de técnicas, que será llevada a cabo por el grupo
investigador (Universidad) en conjunción con la Gerencia de Informática de la DGT.
Posteriormente, se contrastan las técnicas a través de las validaciones realizadas por la
universidad, con los datos de proyectos reales suministrados por la Dirección General de
Tráfico. Finalmente, se refinan las propuestas iniciales utilizando las mediciones obtenidas de
las fases anteriores.
Ilustración 1-2. Método de investigación. Fases.
Tesis Doctoral Daniel Cabrero Moreno
29
1.6 Estructura de este Trabajo
El trabajo que se presenta se ha estructurado de la siguiente manera:
El 0 ofrece una visión detallada del estado del arte de la Ingeniería del Software
Basada en Valor. Se estudian las relaciones existentes entre las distintas
orientaciones. Se identifican carencias en las propuestas presentadas hasta el
momento, y se proponen líneas de investigación abordadas en el resto del trabajo.
El Capítulo 3 presenta el método “GVAL” de aplicación sistemática de valor. Para
ello, identifica los aspectos en común de todas las técnicas basadas en valor y define
las partes que componen el valor. Se introduce por primera vez, además, un ejemplo
de combinación de varias técnicas basadas en valor a través del método genérico.
El 0 introduce el concepto de Diseño Software Basado en Valor (DSBV). Para su
aplicación metodológica, se propone la aplicación del método genérico presentado en
el Capítulo 3.
El Capítulo 3 introduce el concepto de Mantenimiento Software Basado en Valor
(MSBV). Del mismo modo que sucedía con el diseño, propone una aplicación basada
en el método genérico. En este Capítulo se introduce además el concepto de
Reducción de Software (RS), como una alternativa más de priorización de esfuerzos
basados en valor.
El Capítulo 6 discute las opciones de automatización de los conceptos introducidos
anteriormente. Se presenta además una primera aproximación de automatización de
los pasos sobre Excel llamada GVAL-Ex. Se introduce también la automatización en la
Reducción de Software. Finalmente, se discuten posibilidades futuras de
automatización.
El Capítulo 7 presenta diversas validaciones relacionadas con GVAL, DSBV, y RS.
El 0 presenta las conclusiones del trabajo, analizando la consecución de objetivos, el
contraste de resultados y las líneas de trabajo futuras.
Tesis Doctoral Daniel Cabrero Moreno
30
Adicionalmente a esta estructura, se presentan una serie de anexos que han sido
separados de la disertación principal con objeto de mejorar la comprensión de la exposición, y
cuyo contenido se detalla a continuación:
El ANEXO I presenta una serie revisiones sobre aspectos de de Ingeniería del
Software que, aún no tratándose de propuestas catalogadas como basadas en valor,
son de obligada consulta para una correcta comprensión de propuestas que se basan
en ellas, como el Diseño y Mantenimiento Software Basados en Valor. Entre ellas,
podemos destacar técnicas de detección de violaciones de diseño, predicción de la
probabilidad de cambio, predicción de la frecuencia de uso, trazabilidad entre
artefactos, y predicción de la propensión al fallo.
El ANEXO II expone técnicas fuera del alcance de la Ingeniería del Software, pero
que se relacionan con la orientación a valor a lo largo de la literatura. Se trata de
técnicas de soporte a la reconciliación (principalmente la teoría Win-Win de Boehm) y
asignación de importancia con grupos de usuarios (provenientes del área de la
psicología y las matemáticas)
Tesis Doctoral Daniel Cabrero Moreno
31
Capítulo 2 - Estado del
Arte
2.1 Estructura y Clasificación de las Revisiones
Efectuadas
El presente capítulo muestra el estado de los avances realizados en el área de la
Ingeniería del Software Basada en Valor (en adelante ISBV). Para ello, se han clasificado los
trabajos que componen el estado del arte en varias partes diferenciadas:
El grueso del análisis del estado del arte se presentará a lo largo de este
capítulo, donde se introduce brevemente el concepto de ISBV, se presenta una
revisión de todos los trabajos relacionados con el tema, se resumen los
resultados, y se identifican las carencias de investigación actuales en ese sentido.
En el ANEXO I se aporta una revisión de una serie de técnicas de Ingeniería
del Software auxiliares, que pueden ser útiles en la aplicación de la ISBV, y
cuya combinación determinará a la postre la solución a algunas carencias de
investigación identificadas en el primer bloque. Dichas áreas de conocimiento,
como por ejemplo la predicción del cambio o de la frecuencia de uso, tienen
entidad propia y pueden ser aplicadas a muchos campos de la ingeniería, por lo
que se han situado en un anexo independiente.
En el ANEXO II se describen técnicas de estimación y reconciliación de valor.
Los conceptos y trabajos revisados en el ANEXO II serán referenciados a lo largo
de la tesis, y su entendimiento es fundamental para comprender algunas
propuestas de ISBV, pero se separa su presentación y análisis con objeto de
ordenar la exposición y mejorar su comprensión.
Las distintas partes mencionadas persiguen además objetivos independientes. El objetivo
de la revisión llevada a cabo a lo largo de este capítulo es analizar el estado del arte actual con
objeto de identificar potenciales áreas de mejora. Sin embargo, el objetivo del análisis
correspondiente a los anexos, no es el de identificar mejoras en las áreas que lo componen,
sino el de conocer en detalle una serie de técnicas auxiliares imprescindibles para
Tesis Doctoral Daniel Cabrero Moreno
32
comprender las aportaciones de otros autores y las propuestas planteadas en esta Tesis
Doctoral.
Tesis Doctoral Daniel Cabrero Moreno
33
2.2 La Ingeniería del Software Basada en Valor
2.2.1 Introducción al Concepto de Valor
La Ingeniería del Software convencional (IS) estudia la relación entre lo que debe hacer
un sistema y lo que efectivamente hace. Dicho de otra manera, estudia cómo transformar los
requisitos de un sistema en código verificado a través de distintas técnicas y procesos, la
mayoría de ellos ya de uso común en la industria.
En la actualidad la mayoría de las prácticas convencionales de IS se basan en un
enfoque de “valor neutro”, es decir, cada requisito, caso de uso, objeto, o prueba, se
trata con igual importancia, y si bien en los proyectos se suele hacer un seguimiento de
muy alto nivel de los costes, no sucede de igual manera con el valor que aporta al negocio cada
uno de los elementos del desarrollo software. “Tiempo atrás, cuando las decisiones que
afectaban al software tenían relativamente poca influencia en costes, planificación y valor de las
compañías, una aproximación neutral en valor podía ser razonable, pero en la actualidad estas
decisiones tienen gran repercusión” (Boehm, 2005b).
Para cubrir las carencias que el enfoque tradicional plantea, una nueva rama de la
ingeniería está emergiendo en oposición a la ingeniería del software convencional. Se trata de
la Ingeniería del Software Basada en Valor (ISBV), o Value-Based Software Engineering
(VBSE) en terminología anglosajona.
La ISBV establece que no todas las funcionalidades (y por extensión, requisitos,
componentes o casos prueba, entre otros) son igualmente importantes, ya que algunas de ellas
aportan más “valor” que otras. Por lo tanto, es necesario proveer de mecanismos que gestionen
esta diferenciación de los distintos artefactos software. El “valor” es la cuantificación de la
importancia que un determinado artefacto o tarea tiene para todos los implicados (o
stakeholders2) en ese sistema.
La ISBV trata de completar la visión tradicional. Para ello sugiere la priorización de las
tareas y artefactos que proporcionen valor a los distintos implicados, a través de distintas
técnicas y métodos. Se trata en definitiva de orientar los recursos hacia donde más puedan
aportar a los implicados. En palabras de Rick Kazman, “la ISBV trata de predecir dónde deben
ser invertidos el tiempo y los recursos”.
A modo de ejemplo, supongamos que un sistema tiene dos funcionalidades principales.
Llamemos a estas funcionalidades A y B. Una aproximación tradicional sugeriría aplicar el
2 Un stakeholder o implicado es un afectado por el sistema de información, ya sea a causa
de su uso, su desarrollo, su financiación, o incluso si ve su actividad económica o personal indirectamente
afectada de algún modo. A lo largo de este trabajo se utilizará indistintamente ambos términos.
Tesis Doctoral Daniel Cabrero Moreno
34
mismo ciclo de desarrollo, a través de las mismas técnicas para todo el sistema. Centrándonos
por ejemplo en la fase de pruebas, para cada funcionalidad se realizaría un juego de pruebas
con una cobertura del 50% ya que, en este caso hipotético, los recursos del proyecto no son
suficientes para cubrir el 100%.
Sin embargo, una aproximación basada en valor se centraría en primer lugar en
establecer la importancia o valor que cada una de las funcionalidades aporta. En el caso en el
que A fuese una funcionalidad crucial y B un proceso nocturno de bajo impacto, establecería
por ejemplo que las pruebas de la funcionalidad A deben realizarse para una cobertura del
90%, y las pruebas de la funcionalidad B pueden realizarse únicamente para un 10% de su
cobertura. En el caso de fallo de un proceso nocturno, siempre se podrían llevar a cabo labores
de contingencia, en general transparentes para la mayoría de los afectados. De esta forma,
consumiríamos la misma cantidad de recursos, pero maximizaríamos el valor que nuestra
solución está aportando a los implicados.
El ejemplo anterior muestra una práctica que probablemente sea intuitivamente
aplicada con frecuencia en la industria del software. El reto de la ISVB radica en sistematizar y
ordenar las técnicas de asignación de valor, dándole un enfoque de ingeniería, y ordenando las
técnicas que nos ayuden a aplicar el esfuerzo en las tareas más importantes para el éxito global
del software, siempre teniendo en cuenta que el éxito depende de la percepción que todos los
implicados tengan del sistema. En el ejemplo anterior, el reto consiste en desarrollar una
sistematización adecuada que permita obtener una cuantificación del valor, y un método de
cálculo de los valores de cobertura de pruebas, de forma que no dependan de la intuición o
experiencia de quien lo aplica.
Los ingenieros del software tienden a entender las técnicas y métodos de su disciplina
como fórmulas “objetivamente” buenas. En general, la historia de la ingeniería del software
está repleta de ejemplos en los cuales una vez aparecida una técnica o buena práctica, ésta ha
sido un fracaso al aplicarla, pero un éxito a la hora de ser venerada en el sector (Boehm, 2006),
y que han actuado como verdaderos “lemmings” (Davis, 2004). Así por ejemplo, en el particular
tema de los patrones de diseño, (Wendorff, 2001) comenta los fracasos producidos por su uso
excesivo, revisando su experiencia en la que el “abuso” de patrones implicaba mayor dificultad
para entender los diseños.
Un ejemplo de esta tendencia puede ser observada en la actualidad en la mayoría de
las factorías software y demás entidades dedicadas al desarrollo de software. Existen prácticas
que son universalmente aceptadas, y que muchos consideran temerario no utilizar, como puede
ser la separación de las aplicaciones en capas de Presentación, Negocio y Acceso a Datos. Es
indudable que se trata de una práctica recomendable en la mayoría de los casos, sobre todo en
aquellos donde exista la posibilidad de querer cambiar la presentación o el sistema de acceso a
datos preservando el negocio (este último caso es probablemente el más común). Es además
una manera útil de dividir la complejidad de los sistemas. Sin embargo, existen también casos
donde el esfuerzo que supone la elaboración de una arquitectura más compleja no es
recompensado a posteriori, debido por ejemplo a la corta vida del sistema o al pequeño tamaño
del mismo.
Tesis Doctoral Daniel Cabrero Moreno
35
Un modo de evitar este escenario es evaluar a priori las necesidades del sistema de
cara a todos los implicados. Puede darse el caso de que alguno de ellos (p.ej. un gestor)
conozca la circunstancia de la caducidad del sistema, y otros implicados (p.ej. el equipo de
desarrollo) sepan que se trata de un desarrollo muy simple. Una aproximación centrada en el
valor se preguntaría, en función de las necesidades de los implicados y el coste que supone,
qué opción aporta más valor al sistema. El resultado sería, en este caso, que no se aconseja
separar el desarrollo en varias capas. En su lugar se podrían aplicar dichos recursos a mejorar
otros sistemas más críticos, es decir, se podría maximizar el valor de cara a otros implicados.
2.2.2 Áreas de la Ingeniería del Software Basada en Valor
Con el objetivo de agrupar los trabajos propuestos en el marco de la ISBV, se ha
introducido una agenda que pretende integrar las consideraciones de valor dentro del conjunto
de principios y prácticas existentes (Boehm, 2005b), para organizar todas las aportaciones y
procurar que sean compatibles, de manera que se potencien entre ellas.
En ese sentido, se definieron distintas áreas de trabajo que agrupasen todas las
aportaciones:
Ingeniería de requisitos basada en valor, para la identificación de principios y
prácticas que identifican el valor de los requisitos.
Arquitectura basada en valor, para reconciliar los objetivos de negocio con la
arquitectura establecida en los sistemas para apoyar la construcción de software.
Diseño y desarrollo basados en valor, para alinear el diseño y construcción del
software con los objetivos de los distintos stakeholders.
Validación y verificación basadas en valor, para desarrollar técnicas de
verificación y validación del software que prioricen esfuerzos respecto a objetivos de
valor.
Control y planificación basados en valor, para evolucionar las técnicas más
tradicionales sobre planificación, coste y control y que incluyan el concepto del valor
que aportan.
Gestión de riesgos basada en valor, para priorizar, mitigar, identificar, y analizar
riesgos desde la perspectiva del impacto que pueden tener en el valor.
Gestión de la calidad basada en valor, para la priorización de los factores de
calidad deseables con respecto al valor que aportan.
Tesis Doctoral Daniel Cabrero Moreno
36
Gestión de personal basada en valor, para la gestión del equipo y recursos
humanos en pro de valor.
Como se verá más adelante, las distintas áreas no son necesariamente excluyentes. En la
literatura es habitual encontrar propuestas que cubren más de un área.
La ISBV es una rama de investigación joven, y a la que aún le queda un largo camino
por recorrer para llegar a un nivel de madurez similar al de otras ramas de la ingeniería del
software. Sin embargo, esta clasificación define una hoja de ruta, y varias propuestas van
ampliando poco a poco esta nueva perspectiva de la ingeniería del software.
El detalle del avance de dichas propuestas se analizará en el resumen de trabajos más
relevantes presentado a continuación.
Tesis Doctoral Daniel Cabrero Moreno
37
2.3 Trabajos más relevantes
Si existe un término confuso en la literatura de IS, ese es el término “valor”. Chikofsky
aseguraba en la presentación inaugural de la primera conferencia de Ingeniería del Software
Basada en Valor que “el primer objetivo que tenía por delante este campo de la investigación
era que todos los allí presentes tuvieran una idea común de definición de valor” (Chikofsky,
2007). Tras la revisión efectuada en este capítulo, coincidimos plenamente con dicha
afirmación.
Bajo el término ISBV se han encontrado trabajos referidos al valor con sentidos
completamente opuestos. Existen trabajos puramente económicos que cuantifican valores de
inversión de cartera de proyectos (que nada tienen que ver con prácticas de ingeniería del
software), técnicas de cuantificación de esfuerzos, e incluso propuestas de técnicas
supuestamente basadas en valor que ignoraban por completo a los stakeholders. Sin embargo,
todos ellos se clasifican a sí mismos como trabajos de ISBV.
Por otro lado, también se han encontrado técnicas de priorización de esfuerzos
claramente orientados a maximizar el valor de cara a los usuarios, que no nombran en ningún
momento la ISBV ni el concepto de valor, aunque claramente alineen prácticas de IS con la
percepción de los implicados.
De este modo, al ser los trabajos identificados tan heterogéneos, para poder
agruparlos se ha dividido su presentación en varias partes.
En primer lugar (sección 2.3.1) se resumen los trabajos que tienen por objeto
definir el marco de los trabajos centrados en valor, y anticipar unos primeros pasos
pioneros en dicha área. Nótese, que el valor ha sido aplicado hasta hace poco
fundamentalmente a la priorización de proyectos en el marco de la gestión
económica de inversiones, y únicamente se ha comenzado a aplicar en los últimos
años a la IS propiamente dicha. Por tanto, algunos trabajos de priorización de
proyectos son presentados en esta sección.
El principal precursor de una definición común de las técnicas basadas en valor es
Barry Boehm. Sus aportaciones más importantes en este sentido son también
presentadas.
Posteriormente, se han clasificado los trabajos según las áreas de ISBV que
identifica Boehm (de la sección 2.3.2 hasta la sección 2.3.7, ambas inclusive). En
algunos casos, para facilitar la comprensión de los trabajos expuestos se han
subdividido a su vez dichas áreas de conocimiento en sub-áreas más acotadas.
Finalmente, en la sección 2.4 se presenta un resumen de todas las técnicas, y se
elabora un cuadrante de trabajos donde se especifica de forma visual las distintas
áreas que cada propuesta toca. Dicha información tiene por objeto facilitar la
Tesis Doctoral Daniel Cabrero Moreno
38
localización de potenciales áreas de mejora y de nichos de investigación no
abordados todavía.
En la sección 2.4.1 se complementa dicha visión con un análisis de la relación que
las distintas técnicas tienen entre sí. Dicho análisis deja también entrever algunos
de los nichos de investigación donde se requiere una mayor profundización.
Según la organización expuesta, se comenzará por los trabajos más genéricos,
siguiendo por los trabajos encuadrados en las distintas áreas.
2.3.1 Trabajos genéricos sobre la definición de un marco de Valor
2.3.1.1 Cartera de proyectos IT
La noción de “valor” ha sido tradicionalmente utilizada por el área de economía
financiera o “Management” para cuantificar las decisiones de inversión a tomar en una
compañía. En economía, existen diversos modelos para cuantificar el valor de tangibles e
intangibles que una entidad posee. En ocasiones, dicho valor no es únicamente económico, sino
que puede describirse en otros términos, como pueden ser la apertura de mercados o la mejora
del conocimiento técnico del personal interno.
Algunos autores defienden que las compañías más duraderas y mejor posicionadas del
mercado consideran como primeros objetivos aspectos no económicos. Más bien tratan el factor
económico como un facilitador de creación de valor en otras dimensiones (Collins & Porras,
1997).
Los proyectos de tecnologías de la información (Information Technology - IT) tienen
cada vez una mayor importancia sobre las compañías y entidades. “Los posibles fallos en los
sistemas, o las ventajas competitivas que ofrecen los mismos pueden hoy en día tener
consecuencias devastadoras en los mercados” (Boehm & Sullivan, 2000). Como consecuencia
lógica, surge la necesidad de calcular el valor que un determinado proyecto de IT
aporta, de forma que pueda justificarse la inversión que conlleva. Hasta este punto, los
trabajos han sido presentados más bien por economistas que por ingenieros, pues se estudiaba
la utilización y adaptación de técnicas de estimación económica utilizadas para muchos otros
nichos de mercado.
En la mayoría de los casos, las propuestas están orientadas a valorar la opción de
invertir en un proyecto de IT o abandonarlo, o lo que es lo mismo, de priorizar entre la
cartera de proyectos IT. La literatura en ese sentido, y de la que únicamente se han tenido en
cuenta algunos ejemplos, es muy amplia (Freeman, 1984, Clemons, 1991, Benaroch &
Kauffman, 1999, Kogut & Kulatilaka, 2001, Bardhan et al., 2004, Messerschmitt & Szyperski,
Tesis Doctoral Daniel Cabrero Moreno
39
2004, Costa et al., 2005). Sin embargo, en general poco tienen que ver estas propuestas con la
Ingeniería del Software, ni las prácticas y técnicas habitualmente usadas para mejorar el
desarrollo y mantenimiento de software.
2.3.1.2 Evaluación del uso de Metodologías Ágiles en la cartera de proyectos
Relacionando ya los aspectos económicos con las prácticas de IS, una aproximación
recientemente propuesta es la clasificación de la cartera de proyectos con arreglo a las
características de incertidumbre y complejidad que éstos presentan (Little, 2005). El
autor propone dividir la cartera de proyectos en cuatro tipos diferenciados, que nombra como
“perros”, “caballos”, “vacas” y “toros”. La Ilustración 2-1 muestra el cuadrante utilizado para
segmentar la cartera de proyectos.
Ilustración 2-1. Clasificación de los proyectos según su complejidad e incertidumbre (Little, 2005)
Cada tipo de proyecto está caracterizado por un nivel de incertidumbre, definido por
una serie de atributos (incertidumbre de mercado, incertidumbre técnica, duración del proyecto,
y dependencias con otros proyectos), y una complejidad técnica definido por otro conjunto de
atributos (tamaño del equipo, criticidad, localización del equipo, madurez del equipo,
conocimiento del dominio del proyecto y dependencias técnicas de otras partes de la
compañía).
La complejidad técnica y la criticidad son cuantificadas con arreglo a las fórmulas
mostradas en la Ecuación 1, por medio de la agregación de cada uno de los atributos de
complejidad e incertidumbre. En la fórmula se agregan mediante una ecuación logarítmica los
distintos valores de los atributos i y j.
Ecuación 1. Cálculo de complejidad e incertidumbre agregando atributos (Little, 2005)
Tesis Doctoral Daniel Cabrero Moreno
40
Little aplica el método a los proyectos software de tres divisiones en Landmark
Graphics, y los divide según los distintos tipos de proyectos. Los resultados se muestran en la
Ilustración 2-2.
Para cada conjunto de proyectos propone aplicar una metodología de desarrollo
diferente, que varía desde metodologías más ágiles (Cockburn, 2001), hasta tradicionales
procesos planificados.
Ilustración 2-2. Clasificación de proyectos según complejidad e incertidumbre (Little, 2005)
En otra propuesta, Barry Boehm también se refiere ampliamente al balanceo entre
métodos ágiles y planificados en (Boehm & Turner, 2003), donde al igual que Little, defiende la
aplicación de ambas corrientes dependiendo de las características del proyecto.
En ambas propuestas, el nivel de granularidad es el proyecto, no entrando en ningún
caso a diferenciar a nivel de requisito, y mucho menos a nivel de cualquier otro artefacto
software. Únicamente se evalúa el riesgo global de cada proyecto y se aplica un tipo de ciclo de
desarrollo más o menos orientado a controlar el riesgo.
2.3.1.3 Definición de Fundamentos de la Ingeniería del Software Basada en
Valor
La primera iniciativa de agrupación y ordenación de todos los métodos basados en
valor, que ayudasen a alinear los objetivos de negocio con la IS, fue llevada a cabo por Barry
Boehm. En sus trabajos iniciales (Boehm, 2003, Boehm, 2005b) se propone una agrupación y
clasificación de todas las prácticas centradas en valor en distintas áreas (véase sección 2.2.2).
Tesis Doctoral Daniel Cabrero Moreno
41
Desde luego, no es el primer trabajo que maneja el concepto de “valor” y “priorización” para
llevar a cabo alguna tarea de ingeniería, pero sí es el primero que identifica una línea de
investigación global, y que propone dividir todos estos métodos en distintas áreas.
Adicionalmente, Boehm propone definir los “fundamentos” de la ISBV en torno a
siete elementos críticos, que define como el “punto de partida” para avanzar en la “Agenda
de la ISBV”, que ayuden a las organizaciones a implantar esta nueva aproximación:
Benefits Realization Approach (BRA): Se trata de una técnica introducida por
Thorp en DMR (Thorp, 1998) que tiene por objetivo coordinar las actividades del
departamento de IT con los objetivos del resto de la organización, en lo que llama
la “Cadena de Resultados”. Se trata de elaborar una cadena que conecte
gráficamente las iniciativas de trabajos de IT y sus contribuciones de cara a la
compañía. El planteamiento genérico se muestra en la Ilustración 2-3, donde las
iniciativas (“Initiative”) en los sistemas deben ser conectadas con los beneficios
(“Outcome”) que éstas aportan, y con las asunciones (“Assumption”) que permiten
la consecución de los objetivos.
Ilustración 2-3. Esquema de Benefits Realization Approach-BRA (Thorp, 1998)
Esta técnica se propone como entorno de trabajo, que se usará para relacionar
todas las iniciativas, encontrar dependencias con otros implicados en la
organización, y controlar la cadena de dependencias entre las distintas iniciativas y
asunciones. También puede ser usada para monitorizar a lo largo del tiempo la
consecución de los objetivos, y la reevaluación de las asunciones que puedan poner
en riesgo el éxito del proyecto.
Reconciliar objetivos de distintos implicados mediante técnicas de grupo y de
gestión de expectativas. En este sentido, Boehm presenta la “Teoría Win-Win”,
descrita más en detalle en el ANEXO II.
Análisis de Casos de Negocio. Propone utilizar un modelo de Retorno de
Inversión para cuantificar los costes y beneficios de las distintas iniciativas.
Tesis Doctoral Daniel Cabrero Moreno
42
Ecuación 2. Retorno de Inversión
Referencias más detalladas al análisis de los casos de negocio software pueden ser
encontrados en “Making The Software Business Case” (Reifer, 2002).
Gestión del riesgo y de oportunidades de negocio. Desde el punto de vista de
los sistemas software, cuanto antes se identifiquen los riesgos, mayor será el valor
aportado por los sistemas. Boehm propone hacerlo usando técnicas como el
prototipado, encuestas, etc. Para algunos casos concretos propone incluso
identificar a una persona para monitorizar el nicho de mercado tecnológico en el
que se trabaja.
Desarrollo concurrente (en lugar de secuencia) de los distintos elementos y
proyectos, monitorización del valor aportado usando la técnica BRA, y uso de
metodologías ágiles para algunos proyectos para tener resultados antes y
mejorar la competitividad.
Como puede observarse, dichos fundamentos se centran en su mayor parte en la
gestión de proyectos, y en su valoración económica. Se trata de una propuesta de alto nivel
que analiza los proyectos de IT dentro de las organizaciones. Es un primer paso para sentar las
bases de la aplicación del valor a la IS, pero no entra en detalle más allá de hacer una revisión
de trabajos relacionados.
Boehm presenta además en un caso de de estudio (Boehm & Huang, 2003) la
aplicación de la técnica BRA de Thorp, la estimación coste-beneficio, y la monitorización y
control de los beneficios sobre un ejemplo ficticio de encargos on-line.
2.3.1.4 Evaluación de coste de mantenimiento
Tratándose de sistemas software, muy pocas líneas de código pueden aportar increíbles
beneficios, del mismo modo que millones de líneas de código pueden aportar muy pocos. La
estimación del valor del software es una tarea muy compleja para los economistas, ya que debe
de tener en cuenta no sólo que se trata de un intangible, más difícil de cuantificar que un
tangible como un coche o una vivienda, sino también que su modelo de mantenimiento (que
debe ser considerado para estimar el coste de una opción) es especialmente complejo, ya que
el software tiende a crecer y a deteriorarse con el tiempo.
Por un lado, es necesario cuantificar el valor que el software aportará, y por otro el
coste que tendrá construirlo y mantenerlo. Para tener en cuenta el esfuerzo en mantenimiento
ROI = Beneficios-Costes/Costes
Tesis Doctoral Daniel Cabrero Moreno
43
que será requerido a lo largo del tiempo, se han desarrollado modelos de crecimiento del
software (Wiederhold, 2006), que analizan modelos de mantenimiento correctivo, adaptativo y
perfectivo. Utiliza datos recogidos de diversos estudios para estimar qué porcentaje del código
será necesario modificar y qué porcentaje de código nuevo aparecerá en cada versión sucesiva.
Wiederhold señala que los modelos de crecimiento son un factor indispensable a tener
en cuenta en el cálculo de valor de los proyectos, ya que el mantenimiento consume la mayor
parte de los recursos del ciclo de vida de los proyectos de éxito.
2.3.2 Ingeniería de requisitos basados en valor
La ingeniería de requisitos es, junto a la validación y verificación, una de las partes de
la IS donde más directamente podemos aplicar los principios de valor. Esto es debido a que en
la fase de requisitos todavía se maneja un lenguaje que los implicados no técnicos pueden
comprender (qué deben hacer los sistemas), y por tanto es sencillo establecer con ellos qué
condiciones harían el sistema exitoso para cada uno de ellos.
Al igual que en el resto de las áreas, en el fondo de este área subyace el concepto de
que no todos los requisitos tienen la misma importancia, por lo que es necesario priorizar y
organizar los esfuerzos, tanto en la implementación de los mismos como en la comprobación de
consistencias entre requisitos. En la valoración de la importancia de cada requisito es donde los
distintos implicados deben aportar sus opiniones, que posteriormente serán utilizadas para
tomar decisiones.
La priorización de requisitos no es un terreno inexplorado. Independientemente de la
ISBV, existe toda una rama de la ingeniería de requisitos consistente en alinear los requisitos a
objetivos del sistema. Su nombre es Ingeniería de Requisitos Orientada a Objetivos. De hecho,
la mayoría de metodologías de desarrollo comienzan por definir los objetivos del sistema, que
luego relacionan con requisitos. Los objetivos suelen ser evaluados en términos absolutos (es
necesario que…), aunque existen propuestas que añaden un modelo probabilístico para
definirlos en términos relativos de probabilidad (Letier & Lamsweerde, 2004). La mayoría de las
metodologías además permiten asignar una prioridad relativa a cada objetivo y requisito.
Los trabajos presentados en el ámbito de la ingeniería de requisitos basados en valor
no aportan mucho en ese sentido, dado que la elaboración de requisitos lleva implícito el
contacto con los usuarios. La ISBV se centra más bien en definir las consecuencias que el
valor de los requisitos tendrá a nivel de desarrollo, y la consideración de aspectos de
valor normalmente ignorados por los autores, en la mayoría de los casos teniendo además en
cuenta costes y beneficios.
Tesis Doctoral Daniel Cabrero Moreno
44
2.3.2.1 Primeros pasos en priorización coste-valor de requisitos
La priorización de los requisitos de manera sistemática teniendo en cuenta el
valor relativo y coste de cada uno de ellos fue propuesto por primera vez hace más de una
década (Karlsson & Ryan, 1997). Este trabajo presenta una línea de acción pionera en lo que a
la postre pasaría a ser una referencia fundamental en el área de ingeniería de requisitos basada
en valor.
La primera aportación de este trabajo es la introducción de una técnica de priorización,
descrita en detalle en el ANEXO II, llamada AHP (Analytic Hierachical Process), en el área de
ingeniería de requisitos.
El método propuesto por Karlson y Ryan define 5 pasos necesarios para su
implementación.
1. Los requisitos son revisados por los responsables del desarrollo para asegurarse de
que no existen inconsistencias ni ambigüedades. Los requisitos deben estar
descritos de manera correcta y completa.
2. Se utiliza AHP para obtener un valor numérico relativo (con relativo se refiere a que
la suma de todos es 100) de cada requisito. Los usuarios y clientes del software a
construir determinan el valor relativo de cada requisito. La Ilustración 2-4 muestra
los datos extraídos de un ejemplo de aplicación en un caso práctico.
Ilustración 2-4. Elicitación del valor de cada requisito (Karlsson & Ryan, 1997)
3. Se utiliza nuevamente AHP para que los ingenieros de software estimen del mismo
modo el coste relativo de la implementación de cada requisito candidato. La
Ilustración 2-5 muestra el resultado de esta fase.
Tesis Doctoral Daniel Cabrero Moreno
45
Ilustración 2-5. Elicitación del Coste de cada requisito (Karlsson & Ryan, 1997)
4. Un ingeniero de software utiliza los datos extraídos para crear una gráfica, que
represente el valor y coste de cada uno de los requisitos, dividiendo el gráfico en
tres zonas, según la relación valor-coste.
Ilustración 2-6. Diagrama coste-valor (Karlsson & Ryan, 1997)
5. Los distintos implicados utilizan dicha gráfica como base de discusión para analizar
los requisitos. Basándose en la argumentación de cada implicado, los responsables
del proyecto priorizan de manera informal los requisitos y deciden cuáles deben ser
implementados.
Karlsson y Ryan presentan además dos casos prácticos donde se aplica dicha técnica.
Los datos mostrados en las figuras anteriores proceden de uno de ellos. Nótese que la
sistematización de la propuesta es considerable. En primer lugar se utiliza la técnica de AHP
para obtener valores lo menos sesgados posibles, posteriormente se muestra gráficamente
todos los valores divididos por sectores para fomentar la discusión. La técnica deja de ser
sistemática únicamente en la discusión y la toma de decisiones.
Tesis Doctoral Daniel Cabrero Moreno
46
Precisamente en ese punto es donde otro trabajo posterior detectó un punto de mejora
(Jung, 1998), mediante una técnica bautizada como el “método de la mochila” o “knapsack
method”. El objetivo del método de la mochila es asistir a los desarrolladores en la última fase
del método de Karlsson y Ryan (la priorización informal de los responsables del proyecto), de
forma que se proceda de manera más sistemática.
Jung señala acertadamente que la forma de proceder propuesta por Karlsson es válida
cuando se evalúa un número pequeño de requisitos, tal y como sucedía en sus casos prácticos.
Sin embargo, cuando el número de requisitos crece, es muy complejo llevar a cabo dicha tarea
y los datos comienzan a ser demasiado numerosos para poder ser procesados por las personas.
Jung propone afrontar el problema definiendo un número de recursos finito, que asocia
a lo que llama la “capacidad de la mochila”. Se estima el valor y el coste relativo de cada
requisito. Dado que en la mochila no cabe más que un subconjunto de requisitos, propone
sistematizar la toma de decisión para seleccionar los candidatos que más valor aporten que a la
vez quepan en la mochila. En la Tabla 2-1 se ejecuta la técnica descrita para el mismo caso
práctico de Karlsson y Ryan presentado más arriba.
Tabla 2-1. El método de la mochila (Jung, 1998)
En la tabla, el valor b es el porcentaje de coste asumible por la dirección. Por ejemplo,
en la primera fila, b es el rango de gasto válido. La segunda columna (Z0) es el número de
puntos porcentuales de valor al que se da respuesta con el desarrollo propuesto en cada fila. La
tercera columna (Y0) es el número de puntos porcentuales de coste que se invierte. La cuarta
columna muestra los requisitos excluidos del desarrollo.
Tesis Doctoral Daniel Cabrero Moreno
47
Como se puede observar, el método proporciona requisitos excluidos para cada margen
de inversión. Es una información mucho más objetiva y más valiosa para los responsables de
cara a la toma de decisiones, proporcionado a través de un método automatizado.
Adicionalmente, Jung consigue mediante esta propuesta resolver el problema de la
aplicación de dicha técnica para un número alto de requisitos expuesto anteriormente.
2.3.2.2 Agrupación de requisitos
En (Cleland-Huang & Denne, 2005) se propone un método para obtener un mayor
beneficio y mayor rentabilidad a través de las especificaciones de requisitos. Se consigue este
objetivo agrupando los requisitos relacionados entre sí en grupos llamados Minimal Marketable
Features (MMFs), y que representan funcionalidades “vendibles” en el ámbito del marketing. La
aproximación al problema, conocida como Incremental Funding Method (IFM), ordena dichos
grupos de requisitos para maximizar el valor global del proyecto o reducir la inversión inicial.
El valor se calcula en función de la importancia que tengan dichos requisitos para los
gestores del proyecto. Dichos requisitos se agrupan en grupos de funcionalidad en función de
los siguientes parámetros:
Retorno de Inversión esperado (ROI)
Reducción de costes que implica su puesta en producción
Diferenciación con los competidores
Influencia en la lealtad de los clientes
La norma establece la priorización en el tiempo del desarrollo de los distintos grupos de
funcionalidades para evitar que la inversión supere un cierto umbral de deuda. La imagen
describe el flujo de dinero (cash) necesario para acometer los desarrollos. La técnica trata de
ordenarlos para que la deuda que la compañía tiene en todo momento no supere un umbral
dado. Se trata, por tanto, de una técnica de priorización de requisitos. Sin embargo también
toca las áreas de gestión de riesgos y de planificación.
Como en este caso, la gestión de la planificación es un aspecto que suele ir unido a la
ingeniería de requisitos basada en valor. Una vez estimado el valor de cada requisito, una
práctica habitual consiste en priorizar en el tiempo los desarrollos asociados a los requisitos que
más valor aportan.
La Ilustración 2-7 muestra la deuda de inversión o Cash Flow del desarrollo de una
funcionalidad en un proyecto dado.
Tesis Doctoral Daniel Cabrero Moreno
48
Ilustración 2-7. Inversión necesaria para la ejecución de los proyectos (Cleland-Huang & Denne, 2005)
Lo que proponen los autores es ordenar por orden de importancia el desarrollo los
distintos MMF, y planificarlos de manera que no se supere un máximo de deuda durante el
periodo de inversión, señalado en la Ilustración 2-7 como “Maximum cash injection needed”.
Los autores proporcionan además dos herramientas (Una hoja de cálculo, y una
herramienta basada en algoritmos genéticos) que soportan la ejecución de la técnica.
2.3.2.3 Otras técnicas de priorización
Value-Oriented Prioritization (VOP) es otra aproximación de priorización de
requisitos que se basa en definir los valores centrales de la organización (“core values”)
independientemente de los proyectos y requisitos individuales, para luego analizar los requisitos
en función de dichos valores (Azar et al., 2007a, Azar et al., 2007b). Un ejemplo de dichos
valores podría ser “atraer nuevos clientes”, o “ser líder en ventas del sector”. Los valores deben
ser definidos y puntuados de 0 a 10 por la Dirección.
Posteriormente, se construye una matriz con los valores centrales y los requisitos, y se
estima un peso relativo para cada pareja valor-requisito. Dichos pesos deben ser ajustados con
todos los implicados y con la Dirección. Azar et al. Presentan un caso de estudio donde la
aplicación de dicha técnica sirvió para priorizar los requisitos de forma que todos los implicados
aceptasen los valores propuestos. La idea fundamental es realizar técnicas de grupo y discusión
sobre una primera versión de la matriz, para negociar junto con todos los implicados la
importancia relativa de cada requisito.
Esta técnica, sin embargo, no establece qué debe realizarse con la priorización de
requisitos obtenida. Es decir, se centra sólo en un aspecto de la aplicación de valor: la
Tesis Doctoral Daniel Cabrero Moreno
49
obtención de un valor numérico que representa la importancia, pero no establece qué debe
hacerse a partir de ahí, por lo que es una técnica de difícil aplicación práctica por sí sola.
“Balanced Decision Making in Software Engineering” es otra propuesta
recientemente formulada para reconciliar los procesos inherentes a la ingeniería del software
con los objetivos de valor de los usuarios (Omasreiter, 2007). El método es similar a las
aproximaciones presentadas. En este caso se utiliza para ordenar las mejoras que deben
ser implementadas sobre los sistemas. Omasreiter propone realizar un proceso en tres
fases.
En la primera fase se pregunta a los implicados sobre sus objetivos y
prioridades. Aunque no establece qué mecanismo de reconciliación o ponderación
de las visiones de los distintos implicados debe llevarse a cabo, si se define una
lista de mejoras asociadas a una prioridad desde el punto de vista de los usuarios.
El segundo paso es establecer una lista de procesos o acciones que podrían
llevarse a cabo para conseguir dichos objetivos. Los procesos a aplicar se obtienen
de entre una lista de procesos candidatos. Este paso del método debe ser realizado
por los expertos. El resultado es una lista de posibles procesos de mejora en los
requisitos asociados a una puntuación.
Hasta entonces, los procesos y acciones se definen globalmente para toda la
organización. En el tercer paso se adaptan los procesos elegidos al proyecto
concreto.
Finalmente se elabora una matriz de conexión entre los objetivos y los procesos.
En el ejemplo provisto, Omasreiter se refiere únicamente a los requisitos. La Tabla 2-2 muestra
un ejemplo de matriz de conexión, donde cada objetivo (G-1, G-2…) se relaciona con cada
proceso (A-1, A-2...), asignando a dicha relación un valor entre 0 y 1.
Actions Standard
Structure for
requirements
documents
Abstraction
levels
A-1 A-2
Goals: A-Effort:
B-Benefit:
1 3
Higher quality of single
requirements
G-1 4 0 0,2
Better overall view in
requirements document
G-2 3 0,5 0,8
Tabla 2-2. Matriz de conexión para la toma de decisiones (Omasreiter, 2007)
Tesis Doctoral Daniel Cabrero Moreno
50
Como punto de mejora a esta propuesta, se señala que Omasreiter no define el detalle
de cómo asignar dichos valores, ni las prioridades de objetivos y procesos. Tampoco especifica
distintos aspectos de la prioridad asignada, limitándose a pedir una puntuación, bien a los
expertos, bien a los usuarios.
También es importante señalar que no se especifica cuáles son los valores límite en la
aplicación de cada una de los procesos. Es decir, se echa en falta un mayor grado de
sistematización, que permita replicar de manera inequívoca la técnica.
2.3.3 Control y Monitorización basados en valor
Earned Value Analysis (EVA) es una técnica de gestión de proyectos internacionalmente
reconocida y usada para controlar y predecir el coste de los proyectos (Fleming & Koppelman,
2006). EVA tiene por objetivo estimar el grado de avance de los proyectos en comparación con
su planificación, y predecir el comportamiento en el futuro a través de dichos datos.
Sin embargo, su aplicación a proyectos de ingeniería del software no es trivial porque
se basa en estructurar en un árbol todas las partes que componen el proyecto, y en software la
estructura de los componentes y su índice de avance no es necesariamente un fiel reflejo del
avance real del proyecto. Por ese motivo, el análisis del valor generado hasta el momento en un
proyecto software debe ser realizado combinándolo con otras alternativas. La monitorización
por medio de Puntos de Función de Casos de uso (PFCU) ha sido recientemente propuesta (Li
et al., 2008). En dicha propuesta se genera un árbol de tareas a controlar en forma de PFCU,
organizados por procesos de software para absorber mejor los cambios a los que un desarrollo
software está expuesto.
La propuesta de Li et al. es una técnica de monitorización que cuantifica el avance del
proyecto en términos de tareas terminadas, pero no prioriza el valor en ningún caso
dependiendo de las necesidades de los implicados. No se trata por tanto de una técnica
basada en valor en el sentido que Boehm introdujo, sino una estimación del avance del
proyecto basándose en la técnica EVA.
En una línea similar, Lombardi y Massaki proponen una serie de pasos para el control y
monitorización de proyectos utilizando EVA, PMBoK y métricas funcionales (Lombardi &
Massaki, 2008):
1. Identificar la funcionalidad a monitorizar utilizando casos de uso o funcionalidad.
2. Contar el tamaño del software utilizando Puntos de Función de Casos de Uso, o
Puntos de Función.
3. Estimar el esfuerzo utilizando COCOMO II.
4. Controlar el avance del proyecto utilizando EVA.
Tesis Doctoral Daniel Cabrero Moreno
51
Para controlar el avance de los proyectos propone también calcular el avance del
proyecto utilizando Puntos de Casos de Uso, hacer algo similar a lo propuesto por Li et al., es
decir, divide el trabajo a realizar en funcionalidades expresadas en forma de casos de uso.
Ilustración 2-8. Monitorización de la planificación con EVA (Li et al., 2008)
Tal y como se muestra en la figura, EVA realiza el control de proyectos periódicamente
utilizando principalmente el coste actual, el trabajo realizado o “Earned Value” y el trabajo
planificado. Cuando la variación entre el trabajo planeado y los demás valores es grande, es
necesario realizar tareas correctivas en la planificación.
Las propuestas tanto de Li, como de Lombardi y Massaki utilizan el término “valor” en el
marco de la medición del trabajo realizado, comúnmente llamado “Earned Value”. Sin embargo,
las propuestas presentadas en el ámbito de la planificación y control basadas en valor evalúan
el valor aportado en función únicamente del tamaño de la funcionalidad. Ninguna consideración
de importancia, valor de negocio, o similar es tenido en cuenta.
Desde nuestro punto de vista, no puede considerarse que estas técnicas estén
en el ámbito de la ISBV, ya que aunque la palabra “valor” sea utilizada con frecuencia, no se
extrae dicho valor de los distintos implicados, ni se realizan diferentes acciones en función de
dicho valor.
Tesis Doctoral Daniel Cabrero Moreno
52
2.3.4 Validación, verificación y gestión de riesgos basados en
valor
2.3.4.1 Pruebas
Al igual que sucedía con la ingeniería de requisitos, son muchos los trabajos
presentados en torno a la priorización de casos de prueba, especialmente en el caso de las
pruebas de regresión. Esto es debido a que las pruebas de regresión son un subconjunto de
pruebas funcionales consideradas más importantes, destinadas a ser ejecutadas para asegurar
la consistencia de los cambios. Dado que es inviable tener recursos y tiempo para ejecutar
pruebas de regresión que abarquen todos los posibles casos, es necesario priorizar de algún
modo.
Adicionalmente, otros tipos de pruebas (como funcionales o de rendimiento) suelen ser
muy costosos, y esto motiva que generalmente se plantee la necesidad de construir o ejecutar
determinados juegos de pruebas. En general, la priorización de las pruebas está muy
relacionada con la priorización de los requisitos que prueban, por este motivo muchos
de los autores que trabajan en esta línea utilizan también técnicas de priorización de requisitos.
Tradicionalmente la priorización de juegos de pruebas se ha hecho teniendo en cuenta
la probabilidad de fallo, riesgo de fallo y cobertura. Su efectividad además es normalmente
medida en función de número de fallos detectados, cobertura de las prueba, o métricas
similares (Rothermel et al., 2001, Elbaum et al., 2002). Todos los factores de priorización
enumerados tienen una aproximación de valor neutro, es decir, cada prueba es igualmente
importante en lo que respecta al usuario. En este punto es donde la ISBV aporta una visión
diferente.
La Validación y Verificación basada en valor tiene por objeto tener en cuenta el
impacto que cada práctica tiene sobre el valor. Por tanto, las propuestas de priorización
de pruebas centradas en valor deben tomar otros factores de priorización distintos.
(Srikanth & Williams, 2005) presenta un sistema de priorización de pruebas basado en
cuatro variables:
Prioridad asignada por el usuario
Complejidad del requisito
Volatilidad del requisito
Propensión al fallo
A diferencia de las propuestas tradicionales, las variables a tener en cuenta están más
orientadas al valor y coste de cara a los usuarios. La prioridad está orientada a recoger el valor
relativo, la complejidad está orientada a recoger un indicador de coste y la volatilidad pretende
tener en cuenta la efectividad que tendrán las pruebas a largo plazo. Únicamente la propensión
al fallo puede ser considerada de valor neutro.
Tesis Doctoral Daniel Cabrero Moreno
53
Según esta propuesta las variables son puntuadas de 1 a 10. La primera variable es
asignada por el usuario, las dos siguientes por el equipo de proyecto, y la última es extraída de
las estadísticas de fallo detectadas anteriormente. El equipo de desarrollo asigna un peso
relativo a cada una de las variables para asignar un número al “riesgo de negocio”, que
debe ser mitigado a través de las pruebas.
Se definen además cuatro niveles de severidad en lo que respecta a la calidad
esperada, y se buscan únicamente los componentes que tienen más riesgo de fallar para
establecer las pruebas sobre los mismos. La técnica bautizada como PORT (Priorization of
Requirement for Testing), planifica la ejecución de las pruebas en un orden
específico. Se pretende obtener una calidad óptima con un mínimo esfuerzo en la fase de
pruebas.
2.3.4.2 Seguridad
Considerando los aspectos de seguridad como una parte de la gestión de riesgos y de
validación y verificación de un sistema, situamos las propuestas de valor centradas en la
seguridad entre estas dos áreas. A este respecto, la técnica de evaluación de seguridad llamada
“IT-Security Valuation Framework” (Neubauer et al., 2005) ha sido propuesta por
Neubauer et al. En dicha aportación se propone utilizar una evaluación de coste-beneficio para
cuantificar los riesgos y las pérdidas que una adecuada inversión en seguridad puede
evitar. Al contrario que los modelos de seguridad propuestos hasta la fecha, propone considerar
los procesos de negocio, y la evaluación coste-beneficio en su propuesta.
Neubauer et al. inciden en la poderosa influencia que la seguridad puede tener para el
valor de un sistema de información. Ataques, virus o robo de información puede tener efectos
muy negativos en los beneficios, precio de los productos, y reputación de las compañías. Sin
embargo, al igual que pasa con el resto de las áreas de desarrollo, es necesario ajustarse a un
presupuesto.
Los costes son considerados en función de tres factores:
Coste de inversión para implementar un nivel de seguridad determinado.
Coste de operación para mantener dicho nivel
Costes de recuperación de las posibles brechas de seguridad.
Las posibles pérdidas para los procesos de negocio claves de la organización son
consideradas en función de tres factores:
Pérdida de beneficios derivada de la indisponibilidad de un proceso.
Costes de personal
Otros costes indirectos, como por ejemplo la pérdida de reputación.
Tesis Doctoral Daniel Cabrero Moreno
54
No se proporciona un método de aplicación de la técnica propuesta, pero sí un caso de
estudio donde se definen tres niveles de seguridad, se estiman los costes asociados a cada nivel
y la frecuencia estimada de fallo, y se define un nivel de seguridad e inversión para la
compañía.
Un aspecto de mejora a resaltar es que no se prioriza por proyecto, por sistema o por
requisito, sino que se proporciona un marco de decisión para justificar el gasto en seguridad de
la compañía. Tampoco se establece claramente qué acciones hay que llevar a cabo
dependiendo del valor obtenido, por lo que es posible profundizar más en la sistematización de
la propuesta.
2.3.5 Calidad basada en valor
2.3.5.1 Trazabilidad
La trazabilidad entre artefactos es un aspecto transversal de la calidad, que mejora la
mantenibilidad y permite realizar análisis de impacto ante cambios, así como guiar los planes de
pruebas. Se dice que dos artefactos están “trazados” si existe una relación de unión
documentada entre ellos, que permite navegar de uno a otro. Por ejemplo, un requisito está
trazado con una clase de diseño si de algún modo se guarda la relación entre ambos que
permita saber que un cambio en un artefacto podrá tener influencia sobre el otro, así como
evaluar los conjuntos de pruebas sobre los artefactos en base a los requisitos. Los beneficios de
la trazabilidad son asumidos por la mayoría de los estándares de desarrollo. Sin embargo, se
trata de una práctica que generalmente consume muchos recursos, y que por tanto, no suele
realizarse.
Egyed et al. proponen tener en cuenta consideraciones de coste-beneficio
basándose en el nivel de detalle de la trazabilidad a documentar (Egyed et al., 2005).
En su propuesta, argumentan que el valor económico que puede proporcionar la construcción y
mantenimiento de las trazas es limitado más allá de un determinado nivel de detalle, debido
entre otras cosas a la disminución de su calidad (relaciones erróneas) según aumenta su
número y detalle. Además, se propone una clasificación de los artefactos según el valor que
aportan, utilizando una matriz similar a la mostrada en la Tabla 2-3.
Tesis Doctoral Daniel Cabrero Moreno
55
Tabla 2-3. Variación del nivel de trazabilidad según el valor (Egyed et al., 2005)
Sin embargo, la propuesta no especifica cómo calcular dicho valor, ni el nivel de trazado
que se debería asignar a cada artefacto dependiendo de valor. Como se puede observar en la
figura únicamente se limita a señalar de forma genérica la conveniencia de usar más nivel de
detalle en los artefactos que aporten más valor.
En este sentido, (Heindl & Biffl, 2005) sí establece el nivel de precisión del trazado
basándose en el valor, riesgo, y coste de los requisitos percibido por los distintos
implicados en el proyecto en una técnica bautizada como Value-Based Requirement
Tracing (BVRT). Basándose en esos tres indicadores, se utiliza una técnica propuesta a su vez
por (Ngo-The & Ruhe, 2003) para establecer un nivel de detalle de trazabilidad dependiente del
valor. La solución propuesta consiste básicamente en preguntar a los distintos implicados en el
proyecto la importancia relativa que subjetivamente perciben de cada requisito, y preguntar al
responsable técnico del proyecto qué coste y riesgo asociaría a dichos requisitos.
Tabla 2-4. Evaluación del valor de los requisitos (Heindl & Biffl, 2005)
La Tabla 2-4 proporciona un extracto de dichos datos. Para cada requisito se estima el
Valor (Value), dividido en tres columnas, el número de implicados que han estimado alto el
valor (columna +), los que la estimaron media (columna 0), y los que la estimaron alta
(columna -). La columna SV proporciona la estimación ponderada de las opiniones de todos los
implicados. El riesgo (R), el esfuerzo (E), y la combinación de riesgo y esfuerzo (RE) también
son evaluados. Conforme a dichos datos se establece uno de los tres niveles (1, 2 o 3) de
detalle de trazabilidad (columna L).
El nivel 1 exige una trazabilidad de cada requisito con cada método invocado durante
su ejecución, el nivel 2 traza a nivel de clase invocada, y el nivel 3 a nivel de paquete. De esta
forma, dependiendo de la importancia, riesgo y coste de cada requisito, se realizará una
trazabilidad más o menos exhaustiva. En este caso de estudio demuestra cómo la priorización
de requisitos reduce el esfuerzo de trazabilidad de los mismos en un 35%.
En un trabajo posterior, los mismos autores desarrollan una herramienta que soporta la
propuesta.
Tesis Doctoral Daniel Cabrero Moreno
56
En otro trabajo (Cleland-Huang et al., 2004), se propone también la priorización de la
trazabilidad de requisitos como medio para aumentar el retorno de inversión. Para ello, estudia
las distintas técnicas de trazabilidad existentes, compara los costes y riesgos de las distintas
técnicas de trazado y las combina en una solución heterogénea, de forma que el retorno
de inversión pueda ser maximizado. La solución dada recibe el nombre de TraCS
(Traceability for Complex Systems).
La técnica asigna una puntuación a cada requisito en función de la probabilidad de
cambio de cada requisito en 4 niveles:
Crítico (recibe una puntuación de 10).
Sustancial (puntuación de 8).
Moderado (puntuación de 6).
Limitado (puntuación de 4).
El impacto de dichos cambios se calcula estimando un valor de 0 a 1 con arreglo a tres
niveles:
Volátil (recibe una puntuación de 0,9).
Cambiable (puntuación de 0,6).
Estable (puntuación de 0,3).
No se establece claramente la forma de estimar esos datos, con lo que se
sobreentiende que será el jefe de proyecto el que los asigne directamente. Tampoco se realizan
sesiones con los implicados en el proyecto como sucedía en otras propuestas.
Utilizando la probabilidad de cambio e impacto, se calcula un valor numérico con
arreglo a la Ecuación 3 que representa al riesgo, y que categoriza los requisitos en uno de los 3
tipos posibles: sustancial, significante y nominal. El autor señala que la asignación del tipo de
requisito varía en función de cada tipo de proyecto, pero no describe el proceso de asignación
del cálculo de la correspondencia entre los tipos y los valores numéricos.
Riesgo = | (PC * 2) + 1 | * I
Donde:
PC es la probabilidad de cambio.
I es el impacto.
Ecuación 3. Cálculo del riesgo asociado a cada requisito (Cleland-Huang et al., 2004)
Tesis Doctoral Daniel Cabrero Moreno
57
Para cada tipo aplica un porcentaje de requisitos que deben ser trazados manualmente:
50%, 5% y 0% respectivamente. El resto de los requisitos se trazan usando técnicas
automatizadas.
2.3.5.2 Fiabilidad y priorización de defectos
En 2006 se presentó un trabajo que pretendía estimar el esfuerzo destinado a asegurar
la calidad dependiendo del riesgo y la importancia de cada proyecto (Huang & Boehm,
2006). El proceso de cuantificación llevado a cabo fue la evaluación del grupo de 161 proyectos
anteriormente utilizados para fijar los factores de COCOMO II (Boehm et al., 2000), y se usaron
dichos datos para estimar qué incremento de coste supone asegurar la Calidad de un
desarrollo. En este caso, el autor se centra en un aspecto en concreto de la Calidad: la
fiabilidad expresada por los usuarios a través de la variable “RELY” (Required Reliability)
especificada en COCOMO II. Los datos de los proyectos establecían desde un factor de esfuerzo
adicional de 1,26 para los proyectos de alta fiabilidad (un fallo puede suponer una pérdida de
vida humana) hasta de 0,82 para los proyectos de baja fiabilidad (un fallo supone un
inconveniente de poco coste).
A partir de ahí, se propone la utilización de distintas prácticas de corrección de defectos
introducidos en otro trabajo (Chulani et al., 2002), en función de la fiabilidad requerida.
Finalmente se combinan los costes de los distintos aspectos de la Calidad con las pérdidas de
Valor asociadas a la erosión de mercado y al momento de introducción del producto en el
mismo. Se diferencian tres tipos de mercados: competencia (por ejemplo en el sector de
telecomunicaciones), orientado a un evento (por ejemplo el caso de unas olimpiadas), o de
proceso de datos (donde el tiempo de liberación de producto no es muy importante). El
resultado de la combinación de todos los factores es la determinación del mínimo de la
combinación entre fiabilidad requerida, calidad del software, y erosión de mercado.
En otra propuesta (Ling et al., 2005) se propone priorizar la corrección de defectos
teniendo en cuenta el riesgo de escalado. El riesgo de escalado es la probabilidad de que
un defecto sea encontrado por los usuarios, y escalado para su rectificación. El coste asociado a
un defecto que ha sido escalado es un indicador de optimización del Retorno de Inversión en
las labores de corrección de defectos.
La predicción de la gravedad de un defecto y el coste asociado es todavía un nicho de
investigación en constante evolución. La utilización de técnicas de minería de datos sobre
las bases de datos de defectos es una posible aproximación ya propuesta y evaluada por
Ling et al., que permite priorizar la corrección de los defectos para maximizar el retorno de
inversión.
Tesis Doctoral Daniel Cabrero Moreno
58
2.3.5.3 Revisiones e inspecciones
Otro aspecto fundamental en la calidad del software son las revisiones, que permiten
detectar defectos desde las fases más tempranas del desarrollo y corregirlos. La aproximación
basada en valor también ha sido aplicada a los procesos de revisión (Boehm, 2005a, Lee &
Boehm, 2005), en lo que se ha llamado Value-Based Review (VBR), en oposición a las
revisiones tradicionales basadas en listas de chequeos. VBR propone priorizar las revisiones
sobre las distintas funcionalidades del sistema en función de la “prioridad”
determinada por los clientes, y la “criticidad” determinada por los expertos. Las distintas
funcionalidades son ordenadas en función de dichos conceptos como muestra la Tabla 2-5.
Tabla 2-5. Matriz de priorización de revisiones manuales (Lee & Boehm, 2005)
VBR establece que primero se revisen las fuentes de prioridad alta, es decir, las de la
primera columna, de mayor a menor criticidad (de arriba a abajo). Posteriormente, se sigue con
la segunda columna, también de arriba abajo, y así sucesivamente. Las casillas sombreadas
representan las funcionalidades que pueden ser revisadas de manera opcional. Adicionalmente,
en lugar de seguir una única lista de comprobaciones o checklist, en el caso de la VBR también
se efectúan comprobaciones distintas dependiendo de la criticidad.
Los resultados de un experimento realizado en una plataforma de educación a distancia
revelan que los individuos que utilizan la aproximación basada en valor encuentran más
defectos, y lo hacen en menos tiempo. El experimento concluye que se aumenta la efectividad
entre el 65% y el 89%, y se mejoran los costes entre el 105% y 108%.
Otra forma de guiar las revisiones de calidad es la llamada Usage-Based Reading-
UBR (Thelin et al., 2003). Se trata de otro método que puede ser considerado como basado en
valor. Básicamente se propone priorizar los casos de uso. Partiendo de dichos casos de uso
se revisan los documentos realizados posteriormente en el ciclo de desarrollo. Se centran los
esfuerzos en verificar los escenarios de los casos de uso más importantes.
Los autores muestran un experimento simple con 11 estudiantes utilizando UBR, y 12
estudiantes utilizando la aproximación tradicional. Se les proporcionó un documento con fallos,
y se midió la efectividad (% de fallos localizados) y la eficiencia (número de fallos localizados
por unidad de tiempo). Los errores se dividieron en muy graves, graves y leves.
Tesis Doctoral Daniel Cabrero Moreno
59
Los resultados revelan que el grupo de estudiantes guiados por UBR tuvieron una
efectividad mayor, localizando casi el doble de errores muy graves, un 50% más de errores
graves. Respecto a la eficiencia, UBR reveló ser un 75% más eficiente en errores muy graves, y
un 21% más eficiente de manera global.
Tesis Doctoral Daniel Cabrero Moreno
60
2.3.6 Arquitectura basada en valor
Las propuestas más relevantes que relacionan las decisiones arquitectónicas con
aspectos de valor o económicos provienen principalmente del SEI (Software Engineering
Institute). Existen dos metodologías principales propuestas: ATAM y CBAM.
ATAM (Architecture Tradeoff Analysis Method) es un método de evaluación de
arquitecturas basado en escenarios. Utiliza los distintos escenarios a los que la arquitectura
deberá dar respuesta, y que son definidos utilizando dos técnicas: Sesiones de
Brainstorming, y Árboles de Utilidad. Los escenarios son priorizados utilizando técnicas de
grupo (por ejemplo, votaciones).
En las sesiones de brainstorming deben estar involucrados todos los implicados técnicos
del sistema. Se suele realizar para validar y completar el árbol de utilidad generado
anteriormente. Por su parte, un árbol de utilidad es realizado generalmente por un número más
reducido de personas, y tiene por objetivo categorizar y ordenar todas características que se le
requiere a la arquitectura evaluada. Un ejemplo de árbol de utilidad extraído del informe del SEI
(Kazman et al., 2000), donde se explica el proceso de evaluación en detalle, es mostrado en la
Ilustración 2-9.
Ilustración 2-9. Árbol de utilidad de requisitos no funcionales (Lee & Boehm, 2005)
Posteriormente, el arquitecto analiza la información de los escenarios y los árboles de
utilidad y presenta los resultados. ATAM no define cómo debe analizarse dicha información,
dejando dicha labor en manos del criterio del arquitecto. ATAM es una metodología de
elicitación de necesidades de arquitectura. La utilización de sesiones de grupo y de árboles de
utilidad sí es una práctica asociada a la definición de valor, pero en este caso no hay ninguna
Tesis Doctoral Daniel Cabrero Moreno
61
priorización de esfuerzos, sino únicamente evaluación de alternativas, e implementación de una
u otra arquitectura.
CBAM (Cost-Benefit Analysis Method) fue concebido para retomarlo donde ATAM
no llega, teniendo en cuenta costes, beneficios y planificaciones en la elección de los
sistemas (Kazman et al., 2001). Calcula el Retorno de Inversión de cada opción de arquitectura
en función de los escenarios, y elige el retorno de inversión mayor que cumpla las condiciones
de presupuesto dadas.
La combinación de ATAM y CBAM ha sido también propuesta por el SEI (Nord et al.,
2003) y probada en un caso de estudio donde se evaluaba la implantación de J2EE y .NET (Lee
& Choi, 2005), donde se muestran experiencias positivas en la utilización de la salida de ATAM
como entrada de la evaluación CBAM.
Podemos concluir que tanto ATAM como CBAM son métodos de análisis de alternativas
y elicitación de escenarios e importancias relativas de los atributos de calidad de una
arquitectura dada, donde se plantean varias alternativas arquitecturales, y mediante la
extracción de los requisitos que se deben implementar (ATAM), en conjunción con los aspectos
económicos y de planificación que debe cubrir (CBAM), se elige entre una de ellas.
En otra línea arquitectural distinta, la toma de decisiones sobre utilización de
componentes COTS (Commercial-Of-The-Shelf), es decir, componentes software
comprados e incluidos en los desarrollos para mejorar los costes, ha sido también objeto del
análisis basado en valor (Yang et al., 2005). Los autores argumentan una decisión de utilización
de unos componentes u otros basándose en el valor que estos aportan a la solución global,
básicamente a través de una serie de consejos y pasos a seguir en la evaluación y
personalización de dichos componentes. Aunque introduce el concepto de valor para guiar la
aplicación de COTS, se echa de menos una sistematización mucho mayor más allá de
recomendaciones y consejos, que proponga de un modo repetible de aplicación.
Kim y Kang presentan otro enfoque que pretende integrar la noción de valor en las
decisiones de arquitectura (Kim & Kang, 2008), del mismo modo que ATAM y CBAM. En este
caso, una aproximación mucho más simple tiene por objeto dividir los criterios de selección en
obligatorios y opcionales, y asignar un peso a cada criterio. Presenta el concepto a través de un
ejemplo relativamente simple, que no va más allá de una toma de decisión multivariable
con pesos. No determina cómo se asigna el valor de cada opción.
EcoPOST (Economic-driven Evaluations of Process-oriented Software
Technologies) es un entorno de evaluación del valor de aplicación de tecnologías de modelado
y gestión de procesos de negocio (Mutschler et al., 2006). Su objetivo es predecir el coste y
beneficio de la aplicación de tecnologías de BPM (Business Processing Management) a un
entorno dado.
Para llevar a cabo la evaluación se apoya en el formalismo de “System Dynamics” o
SD (Ogata, 2003), que modela el comportamiento de sistemas complejos mediante la
observación de flujos entre sus partes. En el caso de EcoPOST, los indicadores se dividen en
Tesis Doctoral Daniel Cabrero Moreno
62
dos tipos; Organizacionales (fragmentación de procesos, madurez de procesos, conocimiento de
procesos, transparencia de procesos, o evolución de procesos) o tecnológicos (tecnología de
procesos utilizada, agilidad tecnológica para el cambio… etc.).
Un ejemplo de un modelado mediante diagramas de ciclos causales (causal loop
diagrams) mediante SD de la parte organizacional se muestra en la Ilustración 2-10. Diagrama
de ciclo causal (Mutschler et al., 2006):
Ilustración 2-10. Diagrama de ciclo causal (Mutschler et al., 2006)
El diagrama muestra que el indicador de fragmentación de procesos incide
negativamente sobre la madurez de los procesos, del mismo modo que la madurez de los
procesos incide positivamente sobre el conocimiento y la transparencia de los procesos.
Posteriormente se procede a evaluar en términos de coste todas las variables
analizadas. Mutschler et al. presentan un pequeño ejemplo de ilustración, pero no describen en
detalle cómo es el cálculo que lleva desde los diagramas hasta las decisiones concretas de
implantar o no BPM. La aplicación del método a modelos más complejos, y el detalle de dicho
cálculo se posponen para un trabajo futuro.
Existe también en la propuesta un margen de mejora considerable en cuestión de
sistematización y evaluación de alternativas.
2.3.7 Diseño y desarrollo basados en valor
Los campos en los que más se ha avanzado en ISBV son aquellos en los que el valor
aportado por un sistema tiene sentido para los implicados, principalmente los requisitos. Se
trata pues de técnicas donde la filosofía basada en valor es más fácilmente aplicable al requerir
su participación en el proceso. Sin embargo, cuando hablamos de diseño, nos enfrentamos a
una combinatoria muy grande de soluciones igualmente validas para los usuarios a
nivel funcional, y cuyo contenido técnico impide su evaluación por los implicados no
cualificados.
Tesis Doctoral Daniel Cabrero Moreno
63
Como trabajos relevantes, se puede resaltar Net Options Value (NOV), un modelo
para evaluar estructuras modulares. Se basa en la teoría económica llamada “Real Options”
introducida por Baldwin and Clark (Baldwin & Clark, 2000) en el ámbito de la IS. Utilizan NOV
para evaluar una distribución de modularidad entre artefactos a partir de la definición entre sus
relaciones. Las opciones de modularización se representan como una matriz llamada Design
Structure Matrix (SDM), donde las filas y columnas son parámetros de diseño, y se marca
con una “X” en la matriz las dependencias entre parámetros.
En el ejemplo que se muestra en la Tabla 2-6 los parámetros de diseño B y C están
interrelacionados, mientras que B es dependiente de A.
Tabla 2-6. Análisis de modularidad con NOV. Paso 1 (Mutschler et al., 2006)
La división en módulos se realiza marcando divisiones, que reciben el nombre de
diseños “proto-modulares”, como muestra la siguiente figura,
Tabla 2-7. Análisis de modularidad con NOV. Paso 2 (Mutschler et al., 2006)
A partir de ahí, se definen seis operaciones que facilitan todas las acciones relacionadas
con la modularización, y se utiliza NOV para evaluar las distintas alternativas que en un ejemplo
más complejo pueden darse. Posteriormente, se calcula el valor proporcionado como la suma
del valor que proporciona cada módulo, según la siguiente ecuación:
Ecuación 4. Ecuación general de valor con NOV
El valor total se calcula como un valor base (S0) al que se suma el valor de cada
módulo. El valor de cada módulo no siempre es positivo, sino que se calcula como el valor del
beneficio para cada módulo i ( ), menos el valor de la creación de dicho módulo (
), menos el coste de reemplazar un módulo que depende del número de otros módulos
( ). Es decir NOV=Beneficio esperado – Coste de Rediseño – Coste de visibilidad. La fórmula
completa se presenta en la siguiente ecuación:
Tesis Doctoral Daniel Cabrero Moreno
64
Ecuación 5. Estimación de cada miembro de la ecuación general con NOV
Donde ni es la complejidad del módulo i, σi es un coeficiente de desviación estándar,
Q(ki) modela el valor de los k mejores diseños, y Ci es el coste de rediseño. El cálculo sobre un
ejemplo dado asignará un número k óptimo de módulos.
La aproximación ha sido probada satisfactoriamente por Sullivan et al. sobre un ejemplo
simple (Sullivan et al., 2001). NOV además ha sido recientemente revisitado por otros autores
(Bajracharya et al., 2005) para cubrir un aspecto que Sullivan et al. dejaban abierto a la
investigación, el valor de σi, hasta entonces usado como distribución normal.
La extrema ambigüedad que tiene el término “valor”, hace que se utilice en este caso
como piedra angular para evaluar la encapsulación de diseños, que nada tiene que ver con el
valor que los distintos implicados perciben del software, ni de priorizar esfuerzos con arreglo a
las necesidades de negocio. Se trata únicamente de una técnica de evaluación de módulos
basado en un método matemático habitual en economía. No consideramos este trabajo en
el ámbito de la ISBV, ya que no nombra en ningún momento la influencia de las decisiones
sobre los implicados ni la organización, de hecho, ni siquiera nombra a los implicados.
Se concluye que es complicado inferir el valor para un usuario de algo que desconoce, y
que no entiende debido a su naturaleza técnica. Estos son los motivos de que no se haya
encontrado ninguna técnica que relacione los artefactos de diseño y construcción con el
valor en términos de utilidad qué estas aportan a los implicados.
Tesis Doctoral Daniel Cabrero Moreno
65
2.4 Análisis de trabajos basados en valor
La Tabla 2-8 muestra todos los trabajos encontrados relacionados con la ISBV,
indicando con la marca “ ” en cuál de las siete áreas definidas por Boehm se encuadran los
mismos. El resto de las marcas “X” señalan otras áreas que también son tocadas parcialmente
por dichos trabajos, aunque mayoritariamente se sitúe el trabajo en otra área.
Requisitos Diseño Validación Planificación
y Control
Riesgos Calidad Arquitectura
(Karlsson & Ryan, 1997)
(Jung, 1998)
(Kazman et al., 2000,
Kazman et al., 2002) X
(Nord et al., 2003, Lee &
Choi, 2005) X
(Thelin et al., 2003) X
(Cleland-Huang et al.,
2004) X X
(Egyed et al., 2005) X
(Little, 2005)
X
(Cleland-Huang & Denne,
2005) X
(Lee & Boehm, 2005) X
(Srikanth & Williams,
2005) X
X X
(Ling et al., 2005)
(Neubauer et al., 2005)
X
(Heindl & Biffl, 2005) X
(Yang et al., 2005)
(Huang & Bohem, 2006) X
(Mutschler et al., 2006)
(Azar et al., 2007a, Azar
et al., 2007b)
(Omasreiter, 2007)
(Li et al., 2008)
(Lombardi & Massaki,
2008)
(Kim & Kang, 2008) X
Tabla 2-8. Análisis por áreas de los trabajos basados en valor encontrados
Tesis Doctoral Daniel Cabrero Moreno
66
Un vistazo rápido revela que no hay ningún trabajo basado en valor en el área de
“Diseño”. Este es el primer gran nicho de investigación identificado, el desarrollo de
prácticas de diseño que tengan en cuenta las consideraciones de valor.
También es ilustrativo resaltar la gran cantidad de trabajos ubicados en todas las
áreas que tienen relación con los requisitos. Esto es debido a que todos los trabajos
(exceptuando aquellos centrados en arquitectura, y un trabajo que recoge la información de
defectos a través de un DataWarehouse (Ling et al., 2005)) extraen la importancia relativa de
sus tareas a través de los requisitos. La priorización de requisitos parece ser un elemento
común a la mayoría de las propuestas, que posteriormente trasladan dicha importancia a
alguna práctica concreta.
Otro aspecto que conviene resaltar es que no hay propuestas de mantenimiento
basadas en valor. Más aún, ni siquiera hay un área de conocimiento planteada (no existe el
concepto de “Mantenimiento Basado en Valor”), aún teniendo el mantenimiento una gran
influencia sobre la evaluación del coste de los sistemas (Wiederhold, 2006), y que es una de las
áreas de conocimiento de ingeniería del software identificadas por el proyecto SWEBOK.
Cuando se trata de la priorización de recursos y costes, muy ligados al valor global de
las propuestas, el mantenimiento es un elemento que puede ser fundamental, dado que
consume la mayor parte del ciclo de vida de los sistemas (Pigosky, 1997, Bennet & Rajlich,
2000), especialmente en el caso de los sistemas de éxito, que son los que más valor aportan.
Nótese que no todos los trabajos encontrados a lo largo de la revisión han sido
incluidos en la tabla resumen. Esto es debido a que entendemos que muchos de ellos no deben
ser considerados como técnicas basadas en valor, aún en muchos casos incluyendo la palabra
“valor” en su argumentación. Como se comentaba anteriormente, “valor” es un término con
muchas acepciones, pero se consideran prácticamente de manera unánime técnicas basadas en
valor aquellas que alinean las prácticas de la ingeniería con los objetivos de los distintos
implicados en los sistemas, teniendo en muchos casos consideraciones de costes y beneficios,
imprescindibles para estimar el valor que dichas prácticas aportan.
La técnica de elección de tipo de desarrollo en función de una serie de indicadores de
riesgos (Little, 2005) sí ha sido incluida en el cuadro resumen, al tratar esta técnica de
relacionar prácticas de ingeniería (metodologías ágiles) con la percepción de los usuarios. Se ha
encuadrado dentro del área de planificación y riesgos por definir la evolución temporal y el tipo
de tareas a aplicar en función de su riesgo asociado. Sin embargo, esta práctica bien podría
estar ubicada en la gestión de proyectos, si Boehm hubiera establecido un área para ello.
Tesis Doctoral Daniel Cabrero Moreno
67
2.4.1 Relación entre las distintas áreas de la ISBV
En general, la mayoría de las técnicas presentadas comienzan por extraer el valor
relativo de cada requisito a desarrollar. Posteriormente se utiliza dicha priorización para
trasladar la importancia relativa de los requisitos a técnicas y artefactos de otras áreas.
En la Ilustración 2-11 se representan las distintas áreas de conocimiento basado en
valor y la relación existente entre dichas áreas. Las flechas entre las distintas áreas
representan el flujo de valor. Por ejemplo, una flecha desde los requisitos a pruebas
simboliza la posibilidad de aprovechar el valor relativo de los requisitos para priorizar las
pruebas relacionadas con ellos.
Ilustración 2-11. Relación entre las distintas áreas de ISBV3
Las flechas más gruesas representan los flujos de valor que se han implementado
en los trabajos identificados durante la revisión. La información del valor de los
requisitos se utiliza en trabajos de calidad basada en valor (Thelin et al., 2003, Cleland-Huang
et al., 2004, Boehm, 2005a, Egyed et al., 2005, Heindl & Biffl, 2005, Lee & Boehm, 2005,
Huang & Boehm, 2006), validación y verificación (Srikanth & Williams, 2005), arquitectura
3 Leyenda:
- Flujos de valor entre áreas :
- Flujos de valor no identificados:
- Áreas no tratadas:
- Áreas no tratadas ni identificadas:
Arquitec-
tura
Validación
y
Verificación
Diseño y
Desarrollo
Calidad
Planificación y Control
Gestión de Riesgos
Mantenimiento
Cartera de
proyectos
IT
Requisitos
Tesis Doctoral Daniel Cabrero Moreno
68
(Kazman et al., 2000, Kazman et al., 2002, Kim & Kang, 2008), y gestión de proyectos (Little,
2005). Como puede observarse en la Ilustración 2-11, se han realizado trabajos de aplicación
del valor de los requisitos a la priorización de cartera de proyectos, arquitectura, calidad, y
validación y verificación.
Las flechas de línea discontinua representan los flujos de valor que podrían
investigarse, pero sobre los que no se ha encontrado ninguna propuesta hasta la fecha. Dicho
de otro modo, representan las oportunidades de investigación detectadas a lo largo de en esta
revisión. Se han detectado posibilidades de mejora en la relación entre los requisitos y la
gestión de riesgos, diseño y desarrollo, y planificación (además del área de mantenimiento que
no estaba definida4)
Respetando la terminología definida por Boehm, el área de diseño y desarrollo (área
representada en rojo sobre fondo blanco) comprende el análisis, diseño de microarquitectura, y
programación de los sistemas. Hasta la fecha no existe ningún trabajo sobre dicha área, por ese
motivo se representa en rojo con línea discontinua. Tampoco existen referencias al área de
mantenimiento basado en valor (representada en línea discontinua según la leyenda definida en
la página anterior), que no sólo no ha sido abordada por ningún trabajo, sino que tampoco no
ha sido identificada como área de conocimiento.
4 Tampoco han sido reflejadas en la figura las áreas de IS definidas en SWEBOK que fueron
analizadas y descartadas en la sección 1.3 (herramientas y métodos, ingeniería de procesos y
gestión de la configuración).
Tesis Doctoral Daniel Cabrero Moreno
69
2.5 Nuevas líneas de investigación identificadas
2.5.1 Definición y Ordenación de la ISBV
La revisión muestra un conjunto de trabajos muy heterogéneos, centrados en distintos
aspectos del software donde la definición de valor varía dependiendo del autor. La idea común
en la mayoría de ellos es la de priorizar esfuerzos, teniendo en cuenta factores como el coste o
las preferencias de los implicados. No obstante, el concepto de valor es difuso e incluso
inexistente en muchos ellos.
Se han detectado carencias a nivel de investigación a nivel de definición y ordenación
de los trabajos de valor. Parece existir una línea común en muchos de los trabajos, no se ha
definido de manera clara los siguientes puntos:
Los elementos mínimos que una técnica o propuesta debe tener para ser
considerada basada en valor.
Si debe o no obligatoriamente evaluarse los aspectos económicos para poder inferir
el valor que aporta una solución.
La necesidad de recoger mediante técnicas de grupo la opinión de los stakeholders.
Es frecuente encontrar también trabajos que no hacen ninguna referencia al “valor”,
pero cuyo objetivo es claramente la alineación de las prácticas con la importancia relativa que
cada técnica puede aportar de cara a los stakeholders. Un análisis de las propuestas existentes
en la literatura muestra una falta de consenso sobre lo que puede o no ser considerado como
propuesta basada en valor.
El problema de fondo radica en que no existe una definición inequívoca que
permita clasificar las técnicas, y decir de forma clara si son o no orientadas al valor. Se
hace necesario por tanto una generalización que agrupe todas las propuestas basadas
en valor, que posteriormente sea particularizada por caso concreto.
2.5.2 Combinación de Técnicas de Valor
Como conclusión lógica del resultado anterior, al no haber un marco común de
definición ni un lenguaje común para la aplicación de las distintas técnicas basadas en valor, no
es posible combinarlas fácilmente.
Tesis Doctoral Daniel Cabrero Moreno
70
Una analogía representativa podría hacerse con las distintas técnicas de la IS tradicional
que se aplican a lo largo del desarrollo software. Existen diversas técnicas de ingeniería de
requisitos, diseño, codificación, pruebas… etcétera. Sin embargo, adicionalmente es
conveniente utilizar metodologías de ordenación de la aplicación de las mismas (como puede
ser RUP o METRICA), que definen hasta dónde debe llegar una técnica, y desde donde debe
continuar otra. Esto nos permite además intercambiar una técnica por otra o incluso
combinarlas, ya que la metodología define claramente el alcance de cada una de ellas.
Sin duda, Boehm dio un primer paso fundamental hacia la ordenación y compatibilidad
entre las distintas propuestas dividiéndolas en áreas, pero se sigue echando en falta una
aproximación común que permita sustituir una técnica por otra, y combinar a través de
una aplicación común las distintas técnicas propuestas.
Muchas técnicas revisadas en el estado del arte tienen elementos en común, pero,
¿Pueden ser utilizadas conjuntamente? Otras técnicas se basan en indicadores de valor, como
por ejemplo la gravedad de un posible fallo, el coste de implementar una funcionalidad, el coste
de mantenimiento, el posicionamiento de mercado… ¿Puede utilizarse los indicadores de
valor definidos en una técnica para otra técnica?
En la Ilustración 2-11 se representaban las distintas áreas, y los flujos de valor entre
ellas. Tal y como proponía la figura, es necesario estudiar cómo combinar las técnicas de
requisitos basados en valor con las de gestión de riesgos, control y planificación, diseño y
desarrollo, y mantenimiento. Por cada una de las flechas de línea discontinua, existe una
oportunidad de mejora en la comprensión de la ISBV.
Más importante aún es la aplicación práctica de todas las técnicas aquí presentadas.
Dudosamente el jefe de proyecto de un desarrollo software podría aplicar el conjunto de
técnicas que aquí se presentan a su proyecto, y menos personalizarlas para la aplicación a su
caso concreto. Este punto es fundamental cuando se trata de la aplicación práctica, ya que no
es posible, dado el estado del arte actual, aplicar de manera sistemática el concepto de
valor a todos los niveles del desarrollo de software.
Para que sí fuera posible la aplicación del subconjunto de técnicas más apropiadas para
un proyecto concreto, sería necesario definir un marco que permita combinar todas las
propuestas de valor.
2.5.3 Diseño y Desarrollo Basado en Valor
No se ha encontrado ningún trabajo o propuesta que describa alguna
aproximación de valor en la rama del diseño y desarrollo. Como se ha sugerido anteriormente,
esto es debido a que no es trivial estimar la importancia relativa de un artefacto de diseño
como una clase o un paquete, que son incomprensibles por el usuario.
Tesis Doctoral Daniel Cabrero Moreno
71
2.5.4 Mantenimiento Basado en Valor
Aunque el mantenimiento es ampliamente considerada la tarea que más recursos del
ciclo de vida consume, y es indudable que tiene influencia en el valor que un sistema aporta de
cara a los distintos implicados, se trata de un área que no ha sido identificada como basada
en valor.
Tampoco se ha encontrado ningún trabajo al respecto en la revisión.
2.5.5 Planificación y Gestión de Riesgos Basados en Valor
Aunque Boehm sí definió un área de ISBV para la planificación y control, y la gestión de
riesgos, únicamente se han encontrado propuestas que tratan el concepto de valor de forma
superflua. No se ha encontrado ningún trabajo que permita aplicar la planificación o la gestión
de riesgos de forma diferente dependiendo de la opinión de los implicados.
Una excepción a esta afirmación podría ser la aplicación de un tipo de metodología u
otra dependiendo del riesgo (Little, 2005). Sin embargo, la gestión de riesgos comprende
muchas otras tareas inexploradas en el campo de la ISBV, que podrían ser aplicadas
más o menos exhaustivamente dependiendo del valor percibido desde los distintos implicados.
Tesis Doctoral Daniel Cabrero Moreno
72
Tesis Doctoral Daniel Cabrero Moreno
73
Capítulo 3 – GVAL: Un
Método Genérico de
Aplicación de Valor
3.1 Introducción
Disponer de recursos insuficientes dedicados a la construcción o mantenimiento de un
producto es muy habitual en la industria del software. De hecho, se trata de una circunstancia
que se da en todo tipo de actividad económica. Cuando además se trata de elementos
intangibles como es el caso del software, dicho riesgo de invertir recursos erróneamente es
mayor, debido a que el número de posibles mejoras y funcionalidades adicionales está menos
acotado en comparación con los productos tangibles.
Los recursos disponibles a la hora de desarrollar software suelen ser el factor que
marca la calidad y el número de funcionalidades que se pone a disposición de los usuarios.
Tradicionalmente, el ajuste del software a los recursos disponibles se ha venido
llevando a cabo de dos maneras: Bien reduciendo el número de funcionalidades,
bien eliminando fases del desarrollo y buenas prácticas.
La reducción de funcionalidad impacta directamente en las expectativas de los usuarios
(y otros afectados por el sistema, como por ejemplo la Dirección de la compañía), por lo que en
muchos casos no se ofrece dicha opción al equipo de desarrollo. Esto provoca que los gestores
sean poco propensos a reducir funcionalidad. Adicionalmente, debido a que la funcionalidad es
directamente observable por parte de los financiadores del desarrollo, suele ser el único
elemento a tener en cuenta para evaluar el coste del software. Por este motivo, una reducción
de funcionalidad suele ir asociada a una disminución de recursos.
El equipo de desarrollo suele encontrarse entonces en la tesitura de desarrollar un
aplicativo de la misma funcionalidad con menos medios. El resultado es que en la mayoría de
los casos se eliminan entregables, buenas prácticas, e incluso fases completas del desarrollo
para ajustar el coste. Habitualmente, lo primero que se suprime son recursos y tiempo para la
Tesis Doctoral Daniel Cabrero Moreno
74
fase de pruebas (al encontrarse típicamente al final del desarrollo), seguido de una correcta
documentación de los requisitos, un diseño detallado, la trazabilidad entre los artefactos… etc.
La conclusión es que se eliminan todas las tareas que permiten asegurar la fiabilidad y
mantenibilidad, es decir, se rebaja la calidad del desarrollo permitiendo en lo posible una
primera puesta en producción aún a riesgo de carencias graves en el futuro.
Este descenso de la calidad de los desarrollos podría ser aceptable en determinado tipo
de proyectos. Por ejemplo, en aquellos en los que no se requiera una fiabilidad alta, o sea más
importante cubrir rápidamente un nicho de mercado que desarrollar un software mantenible.
Sin embargo, en muchos otros casos esta manera de actuar puede ser muy perjudicial para la
organización. En esa línea, uno de los objetivos de la ISBV es alinear el modo de construir los
sistemas con las prioridades de todos los implicados.
La ordenación de los recursos de forma que se aporte un mayor valor a los
usuarios e implicados es un problema de gran impacto y plenamente vigente. Sin embargo,
como se ha visto en la revisión del estado del arte, actualmente únicamente se ha conseguido
proponer una serie de técnicas separadas, cada una aplicable a un nicho concreto del desarrollo
software, y difícilmente combinables.
No se ha llevado a cabo ninguna propuesta que permita a un ingeniero
aplicar el concepto de Valor para controlar el problema de la bajada de calidad del
software a todos los niveles.
A lo largo de este capítulo se describe un método de aplicación de Valor Genérico
(en adelante GVAL) que tiene por objetivo definir sistemáticamente la aplicación del concepto
de valor, y ordenar y clasificar la aplicación de las técnicas propuestas hasta el momento.
La técnica presentada pretende a la postre ofrecer una solución global al
problema de aplicación de valor, que dé respuesta a la problemática de priorización de
recursos en un entorno industrial similar al descrito. Se hace necesario sistematizar la
priorización del valor de cada artefacto, práctica, o fase del desarrollo de manera global a todo
el proyecto en lugar de a través de técnicas aisladas.
Tesis Doctoral Daniel Cabrero Moreno
75
3.2 Análisis de los aspectos en común de las
técnicas basadas en Valor
A continuación se procede a analizar el nivel de sistematización de algunos ejemplos de
aplicación de valor que fueron presentados en el estado del arte. No se trata de una
clasificación exhaustiva de los trabajos, que será proporciona como aportación en la sección
3.5, sino una introducción a las carencias de sistematización existentes en las propuestas
actuales que pretenden justificar la introducción de los nuevos conceptos y métodos llevada a
cabo en este Capítulo.
El análisis de los ejemplos mostrados a continuación no pretende tampoco describir el
detalle de las aportaciones, ya proporcionado en el estado del arte del 0, sino identificar
elementos comunes que serán discutidos en las siguientes secciones.
Como se verá a lo largo de la exposición, no todas las propuestas centradas en Valor
son igualmente exhaustivas, ni están sistematizadas al mismo nivel, ni cubren todos los
aspectos necesarios para su aplicación repetible sobre proyectos reales.
3.2.1 Ejemplo 1: Requisitos y Planificación basados en Valor
En (Karlsson & Ryan, 1997) se presenta una técnica de priorización temporal de
implementación de los requisitos. La técnica, descrita más en detalle en la sección 2.3.2.1,
decide si implementar o no los requisitos en función del valor que aportan.
Se trata de un ejemplo que asigna una cantidad numérica al coste e importancia de
cada requisito, en este caso inferida respectivamente por los ingenieros de software y por los
implicados. En base a ello, se aplica una tarea de un modo (implementar requisito) para
aquellos requisitos con valor alto, o en caso contrario de otro (no implementarlo). Por tanto, la
tarea que se quiere priorizar en este caso es el desarrollo mismo de los requisitos.
Respecto al ejemplo, la parte específica de aplicación de valor se desarrolla en dos
pasos claramente diferenciados. Por un lado, los implicados (en este caso, usuarios y
desarrolladores) expresan su opinión sobre la importancia relativa de una serie de
artefactos. Por otro lado, se aplica una técnica de IS (en este caso, la implementación
misma de esa parte del sistema) con arreglo al valor asignado.
Tesis Doctoral Daniel Cabrero Moreno
76
3.2.2 Ejemplo 2: Requisitos y Validación basados en Valor
En (Srikanth & Williams, 2005) se define una técnica de priorización de casos de prueba
basada en cuatro factores (prioridad de los usuarios, complejidad de los requisitos, volatilidad
de los requisitos, y propensión al fallo). Se definen fórmulas capaces de obtener una prioridad
numérica para cada requisito. En base a ello se propone priorizar la ejecución de las pruebas.
Para mayor detalle, ver la sección 2.3.4.1.
En esta propuesta podemos encontrar los mismos elementos señalados anteriormente.,
Por un lado proporciona también un método de asignación numérica de importancia o
valor a los distintos artefactos, en este caso, también a los requisitos.
Por otro lado, la ejecución de una técnica de IS es condicionada por el valor que ha
sido asignado a los artefactos. En este caso, la tarea de ejecución de pruebas se
ejecutará con un mayor o menor nivel de detalle dependiendo de la percepción de los
implicados.
3.2.3 Ejemplo 3: Requisitos y Calidad basada en Valor
(Egyed et al., 2005) proponen utilizar el concepto de valor para priorizar los esfuerzos
que se llevan a cabo en definición y mantenimiento de la trazabilidad entre artefactos. Ver
sección 2.3.5.1 para más información.
Se propone dividir los requisitos en dos grupos; Los que tienen un valor alto, y los que
tienen un valor bajo. No especifica cómo se calcula el valor de los mismos. Tampoco especifica
claramente el nivel de detalle a aplicar a los artefactos considerados de alto o bajo valor.
Se trata de un trabajo claramente enfocado desde el punto de vista del valor, dado que
trata de alinear una práctica de ingeniería con los objetivos de los implicados en el sistema. Aún
así, el estudio no proporciona todos los elementos necesarios para aplicar con garantías su
propuesta a un proyecto real. Básicamente existen tres carencias a la hora de aplicar su
propuesta:
No establece cómo se calcula el valor numérico asociado a cada requisito que a la
postre definirá el nivel de trazado.
No indica claramente qué norma o regla hay que aplicar en el caso de haber
calculado el valor. Un ejemplo podría ser, en el caso de valor “alto” es necesario
“trazar el requisito con sus clases de análisis, éstas con los casos de diseño, pero
no con el código”.
Tesis Doctoral Daniel Cabrero Moreno
77
No indica el límite entre valor “bajo” y “alto”.
Por lo tanto, aún tratándose de una técnica de ISBV, faltan algunos elementos
indispensables para poder afirmar que la técnica es repetible. Se echa de menos un método
para estimar el indicador de valor, que en este caso se ha definido a alto nivel como “la
importancia del requisito”. Es necesario también definir de manera inequívoca un conjunto de
posibles tareas a aplicar para cada nivel de valor.
En un trabajo del mismo área de investigación publicado ese mismo año (Heindl & Biffl,
2005), se plantea la misma idea expuesta por Eyged et al. En este caso, se define claramente
cómo se calcula el valor. Se hace mediante sesiones con los usuarios, donde se les pide que
puntúen, de 1 a -1, la importancia subjetiva de cada requisito. Adicionalmente, el responsable
técnico del proyecto puntúa del mismo modo para cada requisito tres aspectos: La importancia
subjetiva del requisito, el riesgo de un posible fallo, y el esfuerzo que llevará a cabo su
implementación. Se suman todas las puntuaciones, y se extrae un nivel de prioridad de entre
tres posibles niveles (1, 2 y 3).
Los requisitos con nivel de prioridad 1, el más detallado, son relacionados con cada
método que los implementan, utilizando una matriz de trazabilidad. Los requisitos de nivel 2
son trazados con las clases, y los requisitos de nivel 3 con los paquetes.
Al contrario que en el caso de la propuesta de Eyged et al., Heindl y Biffl definen los
indicadores de valor, las tareas a llevar a cabo (en este caso, la documentación de la
trazabilidad a cada nivel), y los límites de aplicación de cada tarea a través del
procedimiento de cálculo de Ngo-The y Ruhe.
Tesis Doctoral Daniel Cabrero Moreno
78
3.3 Definición de las Partes que Componen el
Valor
El análisis de los casos de ejemplo analizados en la sección anterior sugiere que, para
poder ser aplicables, las técnicas tienen que tener un modo de asignar un número al
valor de cada artefacto, así como especificar claramente cómo dicho valor influye en
la realización de las tareas.
Existen propuestas en la literatura que ejecutan o no tareas en función del valor que
estas aportan, pero no se describe cómo se calcula el valor, ni de qué indicadores o variables
depende. Por otro lado, existen también propuestas que se centran en calcular el valor que un
requisito o artefacto puede proporcionar, pero no especifican qué consecuencias tiene un valor
alto o bajo en el desarrollo. Por último, existen propuestas que no especifican cuál es el límite
exacto entre valor alto y bajo.
La consecuencia de estas carencias es que, como se ha señalado, las técnicas son
inaplicables a proyectos reales. Se hace necesario una mayor profundización y sistematización
en las técnicas basadas en valor, de modo que puedan ser aplicados en la industria del
software.
A continuación se expondrá cómo el método GVAL, introducido en esta Tesis Doctoral,
propone definir y ordenar cada uno de los aspectos considerados necesarios para
construir una técnica basada en valor: indicadores de valor (que recogerán la
percepción de los implicados), tareas priorizables (que variarán su aplicación con respecto a
dicha percepción) y valores límite (que establecerán el modo de aplicación de las tareas
priorizables).
3.3.1 Indicadores de Valor
Como se ha comentado, para la aplicación de una técnica basada en valor se debe
asignar una prioridad a los artefactos. Dicha prioridad suele estar calculada en función de
uno o varios indicadores, bien a través de una fórmula, bien a través de valores tabulados
mediante tablas.
A continuación se aporta una definición de “Indicador de Valor”.
Tesis Doctoral Daniel Cabrero Moreno
79
Definición 1. Indicador de Valor
En el primer ejemplo, se utilizaban estimaciones del Retorno de Inversión, reducción de
costes, diferenciación con los competidores y fidelización de clientes. En el segundo ejemplo se
utilizan los indicadores de prioridad o importancia según los implicados, complejidad de los
requisitos, volatilidad de los requisitos y propensión al fallo. En la última técnica se utilizan
indicadores de importancia según los implicados, riesgo de fallo y esfuerzo necesario para su
implementación. Todos ellos son indicadores de valor, que aplican sobre los requisitos.
De todos los indicadores de valor analizados en los ejemplos, existe uno que se extrae
de manera objetiva y automatizada a través de históricos de incidencias. Se trata del indicador
de propensión al fallo. Todos los demás indicadores se infieren de las opiniones de los distintos
implicados (usuarios, gestores y equipo de desarrollo). Tenemos por tanto un elemento nuevo
de discriminación de valor: la subjetividad de la fuente. Esto nos lleva a distinguir entre
indicadores objetivos y subjetivos.
Definición 2. Indicadores subjetivos y objetivos
Nótese que únicamente se ha encontrado una propuesta en la literatura destinada a
predecir la escalabilidad de los defectos a partir de la base de datos estadística de errores (Ling
et al., 2005). En esa misma línea, es posible introducir diversos indicadores automatizados o
estadísticos que objetiven el valor calculado. Algunos ejemplos podrían ser: número de
defectos, número de incidencias, frecuencia de utilización de artefactos de código y diseño,
violaciones de calidad detectadas en un diseño… etc.
Para ordenar todos los indicadores que pueden servir para priorizar algún aspecto de
las tareas de ISBV, proponemos utilizar un árbol de indicadores inspirado en el árbol de
utilidad propuesto en la técnica ATAM (Kazman et al., 2000) para los requisitos no funcionales.
Los Indicadores de Valor son estimaciones o evaluaciones de atributos que capturan
algún aspecto que puede tener influencia en la percepción de los implicados de un
proyecto software.
Son Indicadores de Valor Subjetivos aquellos indicadores que han sido estimados
en función de las opiniones de los implicados.
Son Indicadores de Valor Objetivos aquellos indicadores que han extraídos
mediante técnicas automatizadas o estadísticas del proyecto.
Tesis Doctoral Daniel Cabrero Moreno
80
La Ilustración 3-1 muestra una primera propuesta de árbol de indicadores. Marcados
con círculos en rojo se señalan los indicadores que no se han encontrado en ninguna
técnica. El árbol se divide en dos ramas. La rama izquierda aglutina los indicadores
establecidos por los stakeholders no técnicos, que especificarán de manera subjetiva el valor
relativo de cada requisito. La rama derecha contiene indicadores aportados por los
desarrolladores e ingenieros del software.
El árbol presenta una primera propuesta, que podrá ir completándose con más ramas y
hojas, según la aplicación de los conceptos de valor se vuelva más generalizada y cubra más
aspectos. La ventaja de la aproximación es que cada nuevo indicador propuesto puede ser
aplicado para priorizar cualquier aspecto ya contemplado en otras técnicas. Teniendo como
resultado un crecimiento exponencial de las combinaciones posibles.
Entre los indicadores inéditos hasta ahora, se destaca la introducción de indicadores de
probabilidad de cambio, dividido en varios aspectos inspirados en “La ingeniería de Líneas de
Producto Software” (Software Product Lines - SPL). Las SPL agrupan el análisis, diseño e
implementación de una familia de sistemas con el objetivo de mejorar la reutilización de las
partes comunes de sus miembros” (Clements & Northrop, 2001). Por tanto, una Línea de
Producto es un grupo de sistemas “similares”.
En el campo de las SPL, existe una experiencia ya importante en la definición de
modelos de variabilidad. Las diferencias entre sistemas similares, llamadas “discriminantes”,
han sido agrupada en tres grupos: “mutuamente exclusivas”, “opcionales” y “múltiples”
(Keepence & Mannion, 1999).
Trasladado a términos de predicción del cambio, proponemos establecer tres tipos
de cambio: la “extensión” (discriminante múltiple), la “variación” (discriminante opcional), y
la “supresión” (discriminante mutuamente exclusivo) de requisitos. Esto generará tres valores
con una “variabilidad estimada” de cada requisito desde el punto de vista de cada stakeholder.
El tipo de probabilidad de cambio puede definir el modo de realización de diversas tareas
priorizables. Por ejemplo, una tarea de reingeniería sobre una funcionalidad que tiene una alta
probabilidad de ser suprimida no es tan prioritaria como sobre otra funcionalidad que
probablemente será extendida.
Tesis Doctoral Daniel Cabrero Moreno
81
Ilustración 3-1. Árbol de Indicadores de Valor
La importancia del aseguramiento de requisitos no funcionales, como puede ser el
rendimiento o la fiabilidad, puede ser otro aspecto que influya en la forma en que se
aplican algunas tareas de IS, como por ejemplo las pruebas.
Otros indicadores inéditos hasta ahora son aquellos que se han denominado
“objetivos”, y que pueden ser extraídos de las estadísticas de funcionamiento, como por
ejemplo la frecuencia de uso, probabilidad de cambio o número de incidencias, y que
se sitúan en la parte derecha del árbol de indicadores. Las técnicas a través de las que estos
indicadores pueden ser calculados son analizadas en el ANEXO I. Sí ha sido encontrado en la
Tesis Doctoral Daniel Cabrero Moreno
82
literatura el uso de los indicadores de escalado de incidencias, que en (Ling et al., 2005) se
propone llevar a cabo mediante técnicas de datamining sobre las bases de datos de incidencias.
La propensión al fallo es otro predictor, también analizado en el ANEXO I,
ampliamente discutido en la literatura. Básicamente existen tres predictores de propensión al
fallo: las propiedades estructurales, los históricos de cambios, y los históricos de cambios
realizados como producto de la corrección de defectos. Las propiedades estructurales son
tenidas en cuenta en GVAL en forma de reglas de código y violaciones de las mismas, por tanto
no se tendrán en cuenta en el cálculo del indicador de predicción de cambios utilizado en el
marco de este trabajo. Algo parecido sucede también con el historial de cambios, que está
modelado como otro indicador: la propensión al cambio. Por este motivo, el indicador llamado
“propensión al fallo” estará basado en el ámbito de este trabajo únicamente en históricos de
cambios realizados en acciones de corrección de defectos, y será utilizado en
combinación con los otros factores en el ámbito de la aplicación de los correspondientes
indicadores de valor.
Los equipos de desarrollo también aportan indicadores subjetivos. En la literatura se
han recogido la volatilidad, riesgo técnico y complejidad. Sin embargo, se añade en el
árbol una estimación de tamaño utilizando Puntos de Función o Puntos de Casos de uso
un indicador muy útil a la hora de priorizar tareas de desarrollo en base a su esfuerzo no
utilizado hasta ahora.
Tesis Doctoral Daniel Cabrero Moreno
83
3.3.2 Tareas Priorizables
Otro aspecto común a todas las propuestas centradas en valor es la decisión sobre el
grado de ejecución de una tarea en función del valor de un artefacto concreto. El grado de
definición de las tareas varía entre propuestas, al igual que sucedía en el caso de los
indicadores de valor.
Existen propuestas muy parecidas a nivel de evaluación del valor, como pueden ser los
ejemplos 2 y 3 expuestos en el punto 3.2. Sin embargo, el valor estimado de cada artefacto
desemboca en la priorización de un tipo de tarea distinta, en este caso, la ejecución de pruebas
y la documentación de la trazabilidad.
Un ejemplo de tarea priorizable que típicamente se realiza en los desarrollos software
es la ejecución de las pruebas de regresión. Las pruebas de regresión abarcan únicamente un
subconjunto de la funcionalidad, y son realizadas antes de liberar una versión que ha sufrido
cambios para asegurar un mínimo de funcionamiento. La no ejecución de este tipo de prueba
para la mayoría de los requisitos implica una priorización en función de algún criterio. En el
marco de esta Tesis Doctoral se propone considerar priorizable la aplicación de cualquier tarea,
buena práctica, o incluso la construcción misma de un subsistema.
Por todo ello, se introduce en este punto la definición de “Tarea Priorizable”:
Definición 3. Tarea Priorizable
Una tarea priorizable es, en definitiva una tarea “prescindible” en algún grado bajo
determinadas condiciones.
Del mismo modo que sucedía con los indicadores, proponemos ordenar las tareas
priorizables en un árbol, que se muestra en diversas ilustraciones por motivos de legibilidad. La
Ilustración 3-2 muestra el primer nivel de tareas priorizables, que ha sido subdividido en tres
sub-árboles que se muestran en detalle en las ilustraciones presentadas posteriormente.
Se entiende por Tarea Priorizable aquella que puede ser ejecutada de diferentes
modos (o no ser ejecutada) en función del valor relativo de los artefactos involucrados
en su ejecución
Tesis Doctoral Daniel Cabrero Moreno
84
Ilustración 3-2. Primer nivel del Árbol de Tareas Priorizables
Al igual que en el caso del árbol de indicadores, se señalan con círculos en rojo las
tareas que no han sido priorizadas en ningún trabajo encontrado en la literatura. En el
caso de la Ilustración 3-2 se han señalado en rojo los sub-árboles de Gestión de Proyectos y
Mantenimiento, dado que ningún tipo de priorización de tareas basada en valor ha sido
considerada en dichas categorías.
La Ilustración 3-3 muestra las tareas priorizables que se proponen para el sub-árbol de
gestión de proyectos, donde se introducen priorizaciones en las tareas como control de
planificación, gestión de riesgos… etc. Las hojas del árbol, no marcadas con círculos, muestran
los distintos grados de cumplimiento de cada una de las tareas priorizables.
Ilustración 3-3. Sub-Árbol de Tareas Priorizables de Gestión de Proyectos
Tesis Doctoral Daniel Cabrero Moreno
85
La Ilustración 3-4 muestra el sub-árbol de tareas de desarrollo, donde se han definido
tareas priorizables que afectan a artefactos de requisitos, diseño, pruebas, y codificación,
además de a tareas relacionadas con el aseguramiento de la calidad. Nótese que los trabajos
encontrados únicamente se han centrado en priorizar la realización o no de proyectos, la
realización o no de requisitos, el detalle de la trazabilidad (sub-árbol de Calidad), el detalle de
las revisiones (sub-árbol de Calidad) y las pruebas (sub-árbol de Pruebas). El resto de tareas no
han sido nunca priorizadas desde una óptica de valor.
Ilustración 3-4. Sub-Árbol de Tareas Priorizables de Desarrollo
Una vez más, por motivos de legibilidad, se presenta el desarrollo de las tareas
priorizables de desarrollo en varios sub-árboles.
La Ilustración 3-5 muestra el conjunto de tareas que han sido definidas como
priorizables. Se han identificado tres niveles de priorización: Implementar o no los requisitos,
definirlos más o menos exhaustivamente, y obtención de una aceptación más o menos fiable
por parte de los usuarios.
Ilustración 3-5. Sub-Árbol de Tareas Priorizables de Requisitos
Respecto a las tareas relacionadas con la Calidad, se han identificado tareas
relacionadas con la trazabilidad (de la que sólo una parte ha sido abordada en la literatura), con
Tesis Doctoral Daniel Cabrero Moreno
86
las revisiones de los entregables (ya estudiada previamente), y del cumplimiento de reglas de
coherencia entre los distintos entregables producto de los desarrollos.
Ilustración 3-6. Sub-Árbol de Tareas Priorizables de Calidad
Respecto a la fase de pruebas, actualmente se han realizado propuestas de priorización
sobre las pruebas funcionales. Se propone realizar la priorización de más tipos de pruebas,
detalladas en la Ilustración 3-7.
Ilustración 3-7. Sub-Árbol de Tareas Priorizables de Pruebas
Tesis Doctoral Daniel Cabrero Moreno
87
Las tareas priorizables de diseño se han reflejado en el árbol con arreglo a dos criterios.
El nivel de definición del diseño y el cumplimiento de las reglas de diseño discutidas en la
página 121. La Ilustración 3-8 muestra las opciones definidas.
Ilustración 3-8. Sub-Árbol de Tareas Priorizables de Diseño
La codificación ha sido desglosada en una serie de tareas priorizables, mostradas en la
Ilustración 3-9, que incluyen la realización o no de la fase de codificación, el nivel de
documentación exigida, el cumplimiento de reglas de codificación, etcétera.
Ilustración 3-9. Sub-Árbol de Tareas Priorizables de Codificación
Las tareas realizables en fase de mantenimiento es otro conjunto de actividades que no
han sido contempladas anteriormente desde la óptica de la ISBV. La Ilustración 3-10 presenta
una propuesta de tareas priorizables, que serán discutidas en detalle en el Capítulo 5, donde se
introduce el concepto de Mantenimiento Basado en Valor.
Tesis Doctoral Daniel Cabrero Moreno
88
Ilustración 3-10. Sub-Árbol de Tareas Priorizables de Mantenimiento
Es importante señalar que pueden definirse tareas priorizables para la mayoría de las
actividades a realizar en la gestión, desarrollo o mantenimiento de software. El árbol propuesto
en este capítulo es una primera propuesta que deberá ser extendido en el futuro con
nuevas tareas priorizables, y nuevas opciones de priorización por tarea.
La extensión de tareas priorizables es especialmente importante si tenemos en cuenta
que se puede abarcar casi cualquier actividad dentro del ámbito de la IS.
Tesis Doctoral Daniel Cabrero Moreno
89
3.3.3 Valores límite
Hasta ahora, se ha definido un conjunto de indicadores de valor y una serie de tareas
que se realizarán o no dependiendo de ese valor. Sin embargo, en los ejemplos de aplicación de
valor se vio que para que sea posible la aplicación práctica de las técnicas, es necesario definir
inequívocamente cuándo una variable se considera alta (será necesario aplicar las
tareas), o baja (no se aplicarán las tareas priorizables o se realizarán de forma menos
exhaustiva).
Introducimos ahora el concepto de “Valores Límite”, definido como sigue:
Definición 4. Valor límite
A modo de ejemplo, imagínese que se prioriza la aplicación de la tarea “pruebas
funcionales” en tres niveles: no se hacen, se cubre el 50% de los posibles escenarios, o se
cubren todos los casos. El valor de cada requisito se calcula con el indicador subjetivo de
implicado “impacto de posible fallo”. Una vez cuantificado el valor resultante, es necesario
establecer por debajo de qué valor no se hacen pruebas, y por debajo de qué valor se hacen
pruebas al 50% de los casos. Dichos valores son los “valores límites” que en este caso guían la
aplicación de la tarea priorizable de pruebas funcionales.
Se entiende por Valor Límite aquel número por encima del cual los indicadores de
valor modifican el modo de aplicación de una tarea priorizable
Tesis Doctoral Daniel Cabrero Moreno
90
3.4 Método GVAL
Siendo aplicables los elementos definidos a diversos tipos de proyectos, y teniendo la
capacidad de combinar decenas de indicadores y decenas de tareas priorizables, estimamos
necesario suministrar una metodología que aplique de forma sistemática los principios y valores
definidos hasta ahora.
Para ordenar la aplicación de los elementos introducidos anteriormente, se propone la
aplicación de un nuevo método llamado GVAL, cuyos pasos se describen a continuación.
3.4.1 Definición de fases y pasos
El número de posibilidades de combinación de indicadores y tareas es potencialmente
inmanejable de forma intuitiva. Por ese motivo en GVAL se propone realizar una primera
fase de adaptación, donde se elegirán las tareas que son priorizables para el tipo de proyecto
concreto que se desea aplicar, y un conjunto de indicadores considerados relevantes para dicho
tipo de proyecto.
El resultado de la fase de adaptación será una lista de indicadores para cada tarea
priorizable. El grupo de indicadores es aplicable a cuantos proyectos de dicho tipo se
identifiquen.
Posteriormente se propone realizar una segunda fase de cálculo de valores límite
y estimación del valor de los artefactos para cada proyecto concreto.
La Ilustración 3-11 muestra gráficamente los pasos a dar, que se detallan a
continuación:
Fase de Adaptación al tipo de proyecto: Se establecen las condiciones generales
por las que se calcula el valor que un proyecto tiene, y la forma en que se priorizarán
los esfuerzos (qué tareas son priorizables).
o Paso 1: Elección de un subconjunto de tareas e indicadores de entre todas las
posibles (de entre las definidas en los árboles de tareas e indicadores).
o Paso 2: Definición de la relación de cada tarea con una lista de indicadores, que
determinen los términos en que debe ser aplicada. Extracción y normalización
de la importancia relativa de cada indicador desde el punto de vista de los
distintos implicados. El peso que los indicadores tienen sobre cada tarea se
calcula normalizando la importancia relativa de cada indicador asociado a cada
tarea.
Tesis Doctoral Daniel Cabrero Moreno
91
Fase de Aplicación al proyecto.
o Paso 3: Cuantificar indicadores. Para cada uno de los indicadores establecidos
en la fase de adaptación, los distintos implicados establecer un valor numérico
para cada requisito del sistema. A partir de los indicadores, se establece el
valor de cada tarea priorizable, en función de la combinación de los primeros.
El resultado de este paso es la importancia relativa de cada tarea a realizar en
el desarrollo. En caso de ser necesario, en esta fase se realizará la trazabilidad
de artefactos de requisitos a otro tipo de artefactos, como artefactos de diseño
o código, con el fin de estimar el valor de las tareas que implican a dichos
artefactos. (En la sección 4.4, referente a tareas de diseño, se presenta un
ejemplo que contempla dicha posibilidad).
o Paso 4: Se elabora una estimación del coste en base a dicha información. La
técnica especificará qué requisitos se implementan, y qué tareas deben ser
ejecutadas en su implementación. La técnica aportará además varios
escenarios, donde se aplican más o menos técnicas dependiendo del coste que
los usuarios estén dispuestos a invertir.
Si los usuarios no están de acuerdo con la relación funcionalidad-coste,
deberán rebajar sus exigencias de valor y estimar el nuevo coste bajo las
nuevas condiciones.
o Paso 5: Si el valor y el coste encajan con las expectativas de los implicados, se
inicia el proyecto bajo las condiciones de valor establecidas.
Como se ha comentado, la primera fase se realiza una vez para los proyectos del
mismo tipo. Para considerar a dos proyectos del mismo tipo, es decir, para poder aplicar
únicamente los pasos 3,4 y 5 partiendo de la misma información, es necesario que todos estos
proyectos “similares” cumplan los siguientes requisitos:
Las tareas a priorizar deben ser las mimas.
Los indicadores de valor relevantes para los implicados deben ser las mismas, y su
importancia relativa (peso asignado por los implicados) debe también ser el mismo.
Si todos los proyectos de una organización, o de un departamento tienen estas
premisas en común, tendrán en común también los pasos 1 y 2, por lo que no deberán ser
repetidos cada vez.
Tesis Doctoral Daniel Cabrero Moreno
92
Ilustración 3-11. Fases y pasos del Método GVAL
Elección de
Indicadores
Elección de
Tareas
Asignación de lista de
Indicadores a cada Tarea:
Tarea1{Ind1-1,…Ind1-i}
Tarea2{Ind2-1,…Ind2-j}
…….
Tareaj{Indj-1,…Indj-k}
Cuantificar Indicadores
Definir Tareas y Estimar
Estimación de
Recursos vs Valor
Ajustar
Indicadores
Fase de
adaptación al
tipo de proyecto
Fase de
aplicación al
proyecto
[No hay recursos o
insuficiente valor]
[Recursos y valor
adecuados: Se elige
un escenario]
1 2
3
4
5 Inicio de
Proyecto
Tesis Doctoral Daniel Cabrero Moreno
93
3.4.2 Ejemplo de Aplicación: Fase de adaptación al tipo de
proyecto
La fase de adaptación debe ser realizada una vez por tipo de proyecto, o incluso
una vez por organización. Su objeto es seleccionar los indicadores y tareas, así como especificar
su importancia relativa. Por tanto, la definición será válida para todos los proyectos regidos por
ese mismo baremo.
3.4.2.1 Elicitación de los indicadores y tareas (paso 1)
Durante el paso 1 se establece el conjunto de indicadores que componen el valor
aportado por el sistema, y el conjunto de tareas consideradas priorizables en un tipo de
desarrollo concreto. Dado un árbol genérico de tareas (Ilustración 3-2) e indicadores
(Ilustración 3-1), los distintos implicados deben seleccionar un subconjunto de indicadores, y
los ingenieros de software deben hacer lo propio con un grupo de tareas priorizables, aplicables
a dicho caso concreto.
No es necesario que las tareas ni los indicadores tengan en esta primera parte pesos
relativos, por lo que cualquier técnica de priorización descrita en el ANEXO II puede ser válida,
por ejemplo la aproximación “Planning Game”. El resultado de la aplicación de dicha técnica
podría ser, por ejemplo, un conjunto de cuatro indicadores {I1, I2, I3, I4}, y un conjunto de tres
tareas priorizables {T1, T2, T3}.
Los indicadores podrían ser por ejemplo:
o I1: Importancia relativa.
o I2: Urgencia en la implementación.
o I3: Flexibilidad requerida por cambio.
o I4: Importancia de un fallo.
Y las tareas definidas son las siguientes. Entre paréntesis se especifica las
opciones de priorización de dichas tareas.
o T1: La implementación de un requisito (2 niveles: No implementación,
implementación)
o T2: La realización de las pruebas funcionales de un requisito (3 niveles:
No se ejecuta prueba funcional, realización de un 50% de los
escenarios, realización de pruebas en un 100 de los escenarios)
Tesis Doctoral Daniel Cabrero Moreno
94
o T3: La trazabilidad de requisitos a código (4 niveles: No trazar, trazar
por paquete, trazar por clase, trazar por método)
3.4.2.2 Asignación de indicadores a las tareas priorizables (paso 2)
La asignación de indicadores a las distintas tareas priorizables debe ser realizada
necesariamente por un ingeniero de software, ya que los implicados no técnicos no conocen el
conjunto de tareas. El resultado de dicha asignación podría ser por ejemplo la siguiente
agrupación tarea-indicadores: T1={I1, I2}, T2={I1, I3, I4} y T3={I1, I3}. La Tabla 3-1 resume las
relaciones gráficamente.
Importancia
Relativa (I1)
Urgencia de
Implem. (I2)
Flexibilidad (I3) Importancia de
fallo (I4)
(T1) Implementación X X
(T2) Pruebas Funcionales X X X
(T3) Trazabilidad X X
Tabla 3-1. Ejemplo de asignación de indicadores a las tareas priorizables
Es necesario también establecer qué indicadores son o no importantes. Para ello, es
posible utilizar cualquier técnica de priorización, pero esta vez es necesario que cuantifique
numéricamente las asignaciones. Usaremos por ejemplo AHP para asignar los pesos a los
distintos indicadores. En el ANEXO II se describe en detalle los pasos a seguir para su
aplicación.
Como resultado de aplicar AHP, obtenemos una importancia relativa de los distintos
indicadores, por ejemplo: PI1=0,21, PI2=0,05, PI3=0,51, PI4=0,23. Nótese que la suma de
todos los pesos debe ser 1. Como puede apreciarse, en este caso tenemos un proyecto cuyo
factor más importante, desde el punto de vista del valor percibido por los usuarios, es que
pueda adaptarse fácilmente a los cambios. La fiabilidad también es un factor muy importante.
Ilustración 3-12. Ejemplo de distribución del peso de indicadores
21%5%
51%
23%
Ejemplo de distribución del peso de indicadores (PI)
PI1 :Importancia Relativa
PI2 :Urgencia
PI3: Flexibilidad
PI4: Importancia fallo
Tesis Doctoral Daniel Cabrero Moreno
95
Como último paso, es necesario normalizar los pesos de los indicadores asociados a
cada tarea, para que también sumen 1. Por lo tanto, la asignación, con pesos incluidos
quedaría: T1={0,21*I1, 0,05*I2}, T2={0,21*I1, 0,51*I3} y T3={0,21*I1, 0,51*I3, 0,23*I4}.
Después de normalizar, los pesos definitivos quedarían como sigue: T1={0,81*I1, 0,19*I2},
T2={0,29*I2, 0,71*I3} y T3={0,22*I1, 0,54*I3, 0,24*I4}.
Ilustración 3-13. Ejemplo de distribución de pesos de indicadores por tarea
Con este paso, finaliza la parte genérica de establecimiento de indicadores y pesos
relativos para todos los proyectos de este tipo.
Nótese que, con objeto de mejorar la comprensión, en el ejemplo únicamente se
priorizan tres tareas, pero en un proyecto real pueden priorizarse todas las tareas contenidas en
el árbol de tareas priorizables. En todo caso, es interesante que puedan priorizarse las más
costosas, para mejorar la relación coste-valor.
El número de indicadores, por el contrario, no es recomendable que sea muy alto,
porque deben ser estimados por los distintos implicados de forma manual.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
T1 :Implem. Req. T2 :Pruebas Funcionales T3 :Trazabilidad
Distribución de pesos de indicadores (PI) por tarea (T)
PI1 :Importancia Relativa PI2 :Urgencia PI3: Flexibilidad PI4: Importancia fallo
Tesis Doctoral Daniel Cabrero Moreno
96
3.4.3 Ejemplo de Aplicación: Fase de aplicación al proyecto
Una vez definidas las tareas priorizables, los pesos de los indicadores, y las tuplas
tarea-indicadores, es necesario poner número a los indicadores. La fase de aplicación se
realiza una vez por proyecto.
3.4.3.1 Evaluación de Indicadores y Definición de Tareas (paso 3)
En este paso se asigna un valor a cada uno de los cuatro indicadores establecidos en la
fase de adaptación para cada requisito del sistema a implementar. De nuevo, cualquier técnica
de extracción de puntuaciones numéricas puede ser válida. En este caso, se usará nuevamente
la técnica AHP.
Supongamos que el sistema tiene 10 requisitos principales. Como resultado de la
aplicación de AHP, obtenemos los siguientes indicadores por requisito:
Ilustración 3-14. Ejemplo de evaluación de indicadores por requisito
Los valores de cada indicador son normalizados, de forma que oscilen en un rango de 0 a
100. Cada indicador es evaluado por requisito. Por ejemplo, para el Requisito 1, los valores de
los indicadores son (I1=50, I2=52, I3=3, I4=13). El valor relativo de cada tarea priorizable se
calcula a partir de los indicadores y los pesos, del siguiente modo:
0% 20% 40% 60% 80% 100%
I1 :Importancia Relativa
I2 :Urgencia
I3: Flexibilidad
I4: Importancia falloReq 1
Req 2
Req 3
Req 4
Req 5
Req 6
Req 7
Req 8
Req 9
Req 10
Tesis Doctoral Daniel Cabrero Moreno
97
Vt=
Donde:
Vt es el valor asociado a la tarea t.
n es el número de indicadores por tarea
es el valor asignado al indicador i.
es el peso relativo del indicador i.
Ecuación 6. Obtención del valor asociado a una tarea
Aplicado por ejemplo al primer requisito, obtendríamos los siguientes valores relativos de
las tareas:
Tarea Implementación: (50*0,81 + 52*0,2) = 50,42.
Tarea Pruebas Funcionales: (50*0,29 + 3*0,71) = 16,76.
Tarea Trazabilidad de requisitos: (50*0,22 + 52*0,54 + 13*0,24) = 15,86.
En el cálculo del valor de las tareas priorizables se tienen en cuenta los valores asignados
anteriormente: la relación entre indicadores y tareas, el valor de cada indicador asignado a
cada artefacto, y el peso relativo de los distintos indicadores.
La Tabla 3 muestra el resto de valores del ejemplo obtenidos utilizando el mismo
método.
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10
T1 : Implementación Req. 50,42 9,24 16,81 27,74 83,28 22,60 77,36 25,96 12,60 26,84
T2 : Pruebas Funcionales 16,76 6,79 9,22 68,44 32,44 4,48 34,24 73,26 5,83 51,72
T3 : Trazabilidad 15,86 7,25 11,20 76,08 28,79 5,50 29,11 58,68 11,78 42,36
Tabla 3-2. Valor obtenido por requisito y tarea
Tesis Doctoral Daniel Cabrero Moreno
98
3.4.3.2 Ajustar recursos y valores (Paso 4)
Para poder evaluar el valor global aportado en un sistema, es imprescindible tener en
cuenta la cantidad de recursos invertidos. La gran mayoría de las técnicas basadas en valor
estiman de algún modo el coste de cada artefacto a evaluar.
Supongamos que obtenemos el coste relativo de implementación por requisito, esta vez
aportado por el equipo de proyecto, presentado en la Ilustración 3-15.
Ilustración 3-15. Ejemplo de coste por requisito
El coste por requisito se calcula suponiendo que todas las tareas priorizables son
ejecutadas con un nivel de exigencia máximo. En este caso, se hace suponiendo que se hacen
todas las pruebas funcionales, y se mantiene toda la trazabilidad por método ejecutado.
A partir de dicho coste, es posible calcular el coste de cada requisito en el caso en que
las tareas priorizables no se ejecuten. La Ilustración 3-16 muestra el detalle de un subconjunto
del árbol de tareas priorizables presentada en la Ilustración 3-2. Según el árbol, se establece un
esfuerzo del 0% (no se realizan pruebas), 7,5% (se realizan pruebas al 50%), o 15% (Se
realizan todas las pruebas). Respecto a la trazabilidad, la establece un esfuerzo del 0% (no se
traza), 1% (traza a nivel de paquete), 3% (traza a nivel de clase) o 7,5% (traza a nivel de
método).
14%
7%
7%
14%
2%3%
14%
18%
20%
1%
Coste por requisito
R1
R2
R3
R4
R5
R6
R7
R8
Tesis Doctoral Daniel Cabrero Moreno
99
Ilustración 3-16. Esfuerzo relativo de las tareas de Trazabilidad y Pruebas Funcionales
Del mismo modo que proponía (Jung, 1998) en la sección 2.3.2.1, para poder evaluar el
escenario coste-valor más adecuado en cada caso, los impulsores del proyecto deben disponer
de un conjunto de escenarios para poder tomar decisiones sobre el valor que aporta el capital
invertido. Para ello, se propone variar los límites de valor de cada tarea, de manera que
puedan contemplarse diversas alternativas de coste y tareas a realizar, siempre
manteniendo constante el valor relativo de cada indicador y tarea.
La Ilustración 3-17 muestra cómo varían los límites de aplicación de los distintos tipos
de tareas priorizables. Los primeros escenarios dividen en partes iguales los límites asignados a
las tareas (Ej: 33%, 66%, 100%), mientras que según se incrementa el número de escenario,
se incrementa el porcentaje de tareas requeridas, y se disminuye el porcentaje de tareas no
implementadas (Ej: 65%,85%,100%). Por ejemplo, un requisito con un valor asociado a la
tarea T1=46 no sería implementado en el escenario 1, pero sí lo sería a partir del escenario 2.
Tesis Doctoral Daniel Cabrero Moreno
100
Ilustración 3-17. Adaptación de los límites de valor
De este modo, según se avanza a lo largo de los distintos escenarios, se irán aplicando
todas las tareas priorizables, de menos a más nivel de exigencia, y siempre de manera
proporcional al valor asignado para cada una de ellas.
Si se aumenta de número de escenario y se calcula el coste para cada uno de ellos, se
obtienen los valores presentados en la Tabla 3-2. Según se ejecutan más tareas priorizables,
aumentan los costes. De esta forma, paulatinamente se implementarán más requisitos, y los
requisitos que se implementen irán siendo mejor probados y mejor trazados. La aplicación de
los diversos escenarios al proyecto planteará una serie de posibles escenarios, todos ellos
cumpliendo las directrices de valor.
020406080
100120
Esce
nar
io 1
Esce
nar
io 2
Esce
nar
io 3
Esce
nar
io 4
Esce
nar
io 5
Esce
nar
io 6
Esce
nar
io 7
Esce
nar
io 8
Esce
nar
io 9
Esce
nar
io 1
0
T1: Impl. Req.
No se implementa Se implementa
020406080
100120
Esce
nar
io 1
Esce
nar
io 2
Esce
nar
io 3
Esce
nar
io 4
Esce
nar
io 5
Esce
nar
io 6
Esce
nar
io 7
Esce
nar
io 8
Esce
nar
io 9
Esce
nar
io 1
0
T2: Pruebas Func.
No se prueba Prueba 50% Prueba todo
020406080
100120
T3:Trazabilidad
No se traza Traza por paquete
Traza por clase Traza por método
Tesis Doctoral Daniel Cabrero Moreno
101
La columna “Requisitos Implementados” expone el conjunto de requisitos que son
implementados. De ellos, “Req. Probados” presenta los requisitos que son probados o al 50%, o
de manera global. La columna “Req. Trazados” los requisitos que se trazan por paquete, clase y
método, y la última columna el coste.
Por ejemplo, si se elige el escenario 5, se implementarán los requisitos 1,4,5,7 y 10, de
los que se probarán el 5 y el 7 al 50%, y el 4 y el 10 al 100%, y se trazará a nivel de paquete el
1, a nivel de clase el 5, y a nivel de método el 4 y el 10.
Requisitos
Implementados
Req. Probados Req. Trazados Coste
Al 50% Todo Paq. Clas. Método
Escenario 1 1,5,7 7
24.367,09 €
Escenario 2 1,5,7 5,7
24.485,76 €
Escenario 3 1,5,7 5,7
24.485,76 €
Escenario 4 1,5,7 5,7
1 24.628,16 €
Escenario 5 1,4,5,7,10 5,7
4,10 5 4.10 40.799,05 €
Escenario 6 1,6,7,8,10 1
4,5,7,8,10 1 7,5 4,8,10 58.235,76 €
Escenario 7 1,4, 5,6,7,8,10 1
4,5,7,8,10 1 4,5,7,8,10 58.947,78 €
Escenario 8 1,4,3,5,6,7,8,10 1
4,5,7,8,10 1,3 4,5,7,8,10 64.661,39 €
Escenario 9 1,4,3,5,6,7,8,10 1,3
4,5,7,8,10 1,3 4,5,7,8,10 65.207,28 €
Escenario 10 1,4,3,5,6,7,8,9,10 3
1,4,5,7,8,10 3 1,9 4,5,7,8,10 82.863,92 €
Tabla 3-3. Escenarios de aplicación de GVAL
La evolución a través de los escenarios coincide en todo momento con las prioridades
de valor que se asignaron en un principio. El requisito 4 por ejemplo no aparece hasta el
escenario 4, al no ser importante, pero cuando aparece lo hace con las pruebas al 100%, y con
las trazas realizadas, dado que tenía unos indicadores de importancia de fallo y una flexibilidad
altas, que al estar relacionados con las tareas de pruebas y trazabilidad, exigen un nivel de
exigencia alto.
Uno de los puntos fundamentales de esta técnica es la visibilidad que los
implicados tienen de la calidad de los sistemas. Se hablaba en la introducción de este
capítulo de que al no tener visibilidad los usuarios sobre el valor que las técnicas de ingeniería
aportan, normalmente según se reducen los recursos, se reduce también la aplicación de dichas
técnicas. Con GVAL, es posible reducir coste del proyecto, pero un modelo establece
inequívocamente los requisitos que se desarrollarán para el nivel de valor definido. De manera
que para que funcionalidades adicionales sean incorporadas, es necesario que los
usuarios rebajen el nivel de valor de los indicadores (y que todos los implicados sean
conscientes de ello), o ser más exigente en las tareas que se aplican al desarrollo.
Tesis Doctoral Daniel Cabrero Moreno
102
La Ilustración 3-18 muestra cómo el coste se va incrementando según se añaden
requisitos en los distintos escenarios. Los 4 primeros escenarios tienen un coste similar,
únicamente incrementado por la ejecución de algunas tareas priorizables, posteriormente se
van incorporando requisitos a la implementación.
En algunas ocasiones, como entre el escenario 8 y 9, se incrementa el coste sin añadir
requisitos. Esto es porque GVAL obliga a incrementar las tareas priorizables de los requisitos
que ya están implementados.
Ilustración 3-18. Evolución del coste con las variaciones de límite
Es fundamental resaltar que la técnica es totalmente automatizable. Del
mismo modo que se ha mostrado un ejemplo con 3 tareas y 4 indicadores, puede aplicarse para
todas las tareas priorizables y para todos los indicadores definidos en la Ilustración 3-1 y la
Ilustración 3-2, respectivamente. En el Capítulo 6 se discute la automatización del método
propuesto.
Según se añadan tareas priorizables, la gráfica del coste de escenario será menos
escalonada y la curva más suave, ya que el coste de las tareas priorizables será mayor en
proporción al coste de inserción de requisitos.
3.4.3.3 Inicio de Proyecto (Paso 5)
Una vez definido el nivel de exigencia y el presupuesto de cada tarea del desarrollo, se
inicia el proyecto.
0,00 €
20.000,00 €
40.000,00 €
60.000,00 €
80.000,00 €
100.000,00 €
120.000,00 €
0 2 4 6 8 10 12
Co
ste
Escenarios
Req. 1,5,7
Req. 4,10
Req. 8 Req. 3
Req. 9 Req. 2
Mismos Req. pero
más tareas
Tesis Doctoral Daniel Cabrero Moreno
103
3.5 Clasificación de los trabajos según GVAL
En el ejemplo de aplicación mostrado, se implementan 3 tareas en función de 4
indicadores. Sin embargo, se han definido muchas más tareas priorizables e indicadores a lo
largo de este capítulo. Esta sección tiene por objeto presentar los indicadores y tareas por los
que se rigen los trabajos encontrados en el 0.
A continuación se describen las partes que define GVAL de los trabajos encontrados en
las revisiones.
Tareas Priorizables Indicadores
(Karlsson & Ryan, 1997) Implementación de requisitos Coste, importancia
(Jung, 1998) Implementación de requisitos Coste, importancia
(Kazman et al., 2000) Elección de arquitectura Seguridad requerida, fiabilidad requerida,
probabilidad de cambio, aseguramiento de
rendimiento.
(Kazman et al., 2002) Elección de arquitectura Idem, pero añadiendo coste
(Nord et al., 2003, Lee &
Choi, 2005)
Elección de arquitectura Coste, importancia relativa
(Thelin et al., 2003) Inspecciones de Software Importancia relativa
(Cleland-Huang et al.,
2004)
Trazabilidad Probabilidad de cambio, seguimiento de riesgos,
trazabilidad
(Egyed et al., 2005) Trazabilidad Importancia
(Cleland-Huang & Denne,
2005)
Implementación requisitos Coste
(Lee & Boehm, 2005) Revisiones Coste de fallo, importancia
(Srikanth & Williams,
2005)
Pruebas funcionales Prioridad, complejidad del requisito, volatilidad
del requisito, propensión al fallo
(Ling et al., 2005) No prioriza tareas Escalado de defectos
(Neubauer et al., 2005) No prioriza tareas Indicadores a nivel de organización : Coste, coste
de fallo
(Heindl & Biffl, 2005) Trazabilidad Importancia, riesgo, coste (Yang et al., 2005) No prioriza tareas Importancia de fallo
(Huang & Bohem, 2006) Revisiones, pruebas, y definición
de requisitos y diseño
Importancia de fallo, fiabilidad
(Mutschler et al., 2006) No prioriza tareas Indicadores a nivel de organización: Madurez,
conocimiento, transparencia. de procesos
(Azar et al., 2007a, Azar
et al., 2007b)
Implementar requisitos Número extensible de indicadores
(Omasreiter, 2007) Actualización y modificación de
entregables existentes
No usa indicadores a nivel de implicados
(Li et al., 2008) No prioriza tareas No usa indicadores
(Lombardi & Massaki,
2008)
No prioriza tareas No usa indicadores
(Kim & Kang, 2008) No prioriza tareas No usa indicadores
Tabla 3-4. Clasificación de trabajos según GVAL
Como puede observarse, hay técnicas que no priorizan ninguna tarea. Algunas de ellas
son de evaluación de alternativas. Otras asignan valor a los requisitos, pero no especifica qué
Tesis Doctoral Daniel Cabrero Moreno
104
hacer después, con lo que la técnica es difícilmente aplicable a nivel práctico. Otro conjunto de
técnicas define indicadores a nivel de organización, o a nivel interno de desarrollo de proyecto.
Como conclusión, es importante resaltar que el conjunto de indicadores que ha sido
utilizado en la literatura es más reducido que el propuesto en este trabajo, en
comparación con los indicadores ordenados en el árbol de indicadores presentada en este
capítulo. El número de tareas priorizables encontradas en la literatura es más
reducido aún, en comparación con el árbol de tareas ideado para GVAL.
Otro aspecto fundamental es que cada técnica se rige por unos indicadores y tareas
priorizables. Con GVAL se propone por primera vez aplicar una visión de valor integral, es
decir, se propone poder combinar todos los indicadores y tareas priorizables identificados en los
trabajos.
Tesis Doctoral Daniel Cabrero Moreno
105
3.6 Aportaciones realizadas en este capítulo
En este Capítulo se han realizado cuatro aportaciones básicas.
En primer lugar, se ofrece una primera definición de técnica basada en valor.
Dado que la revisión muestra la utilización de este término de manera muy variada. Se define
técnica basada en valor como aquella que recoge algún aspecto de importancia desde el punto
de vista de los implicados (“indicadores de valor”), y orienta las actividades de ingeniería del
software en función de dichos aspectos (“tareas priorizables”), teniendo en cuenta los límites
que hacen variar la aplicación de las tareas (“límites de valor”).
Como segundo gran punto, se formula por primera vez un método de aplicación del
valor de manera sistemática llamado GVAL, presentado en detalle a través de un caso
práctico de ejemplo. Esto se consigue definiendo un conjunto de indicadores y tareas
priorizables, y asignando un conjunto de indicadores ponderados por pesos a cada tarea, que
se ejecutará más o menos exhaustivamente dependiendo del valor que se le asigne. El método
presentado es completamente automatizable, abriendo así la puerta a una utilización
sencilla en el marco del desarrollo de software industrial.
Tercero, se sientan las bases para la combinación de distintas técnicas. Todas
las técnicas que puedan definirse en función de los elementos comentados (indicadores y
tareas), pueden ser aplicados bajo el método GVAL, siendo posible además seleccionar un
subconjunto de indicadores de valor determinado en base a su experiencia. Por ejemplo, es
posible añadir un indicador cualquiera a nuestro modelo de valor sin esfuerzo adicional.
Las posibilidades de definición y combinación de los distintos indicadores y tareas son
muy amplias, y lo que es más importante, se abre la posibilidad de unificar varias técnicas, y
aplicar el concepto de valor de manera global. Esto permitirá tener una visión integral de la
aplicación de costes de un proyecto real en la industria del software. La clasificación de las
distintas técnicas en función de indicadores de valor permitirá además proponer nuevas
técnicas mediante la simple combinación de los distintos indicadores.
Finalmente, se presenta una clasificación de las técnicas encontradas en la
literatura en función de sus indicadores y sus tareas a priorizar. Esta recopilación de
información es inédita, y útil a la hora de encontrar nuevos nichos de investigación.
Tesis Doctoral Daniel Cabrero Moreno
106
Tesis Doctoral Daniel Cabrero Moreno
107
Capítulo 4 – Diseño
Software Basado en
Valor
Tesis Doctoral Daniel Cabrero Moreno
108
4.1 Introducción
Tal y como muestra la Ilustración 4-1, diversas opciones de diseño pueden dar
respuesta al mismo conjunto de requisitos, de forma que el usuario tenga una percepción
inicial similar de sistemas diseñados de forma diferente. Sin embargo, la experiencia ha
demostrado que algunos diseños tienen un mejor comportamiento que otros con
respecto al valor que aportan al negocio. El motivo puede ser por ejemplo que unos sean más
caros o más flexibles frente al cambio que otros.
Ilustración 4-1. Varias soluciones de diseño dan respuesta los mismos requisitos
El valor de un diseño no suele estar definido por el tamaño de éste, sino por otros
factores. Indudablemente, uno de esos factores es la flexibilidad ante cambios del diseño,
que permite que las aplicaciones sean mantenibles. La incapacidad para actualizar
rápida y fiablemente los sistemas software tiene un coste económico alto, además de hacer
perder muchas oportunidades de negocio a las organizaciones. Pero, ¿Hay otros factores que
influyen en el valor de los diseños? ¿Es posible alinear las tareas de diseño con el valor que
éste aporta a los implicados?
Mary Shaw señalaba recientemente en este sentido que “Necesitamos mejores
maneras de analizar un diseño software y predecir el valor que su implementación ofrecerá a
los clientes y desarrolladores” (Shaw et al., 2007). En ese sentido, la revisión realizada señala
que no existe ninguna técnica sistemática que permita identificar el valor de una
decisión de diseño, y mucho menos cuantificarla.
Para paliar esta carencia, en esta Tesis Doctoral introducimos el concepto y aplicación
práctica de Diseño Software Basado en Valor (en adelante DSBV), que gira en torno a la
definición de qué es un diseño que aporta valor, y cómo puede medirse dicho valor.
Tesis Doctoral Daniel Cabrero Moreno
109
Proponemos además la creación de técnicas que persigan una mejor adaptación del diseño de
las aplicaciones al contexto de negocio y a los stakeholders implicados en el sistema. El
objetivo final de un diseño correctamente orientado es la optimización de los costes asociados
al mantenimiento y la evolución de las aplicaciones.
Para presentar el DSBV, se comenzará por analizar qué aspectos del diseño pueden
llegar a aportar valor a los stakeholders. Para ello, se presentará un ejemplo de diseños
alternativos, y se analizarán las distintas soluciones para definir dónde está el valor de cada
uno de ellos.
Tesis Doctoral Daniel Cabrero Moreno
110
4.2 El Concepto de Valor en Diseño
4.2.1 Ejemplo de aplicación de mejoras de diseño
Con el fin de ilustrar nuestra propuesta, se procederá a realizar el diseño de una parte
del modelo de objetos de una compañía aseguradora. En este sentido, se presentarán tres
alternativas de diseño distintas sobre los mismos requisitos, con el objetivo de observar la
problemática que hay detrás del diseño que aporta valor.
Se trata de modelar la venta de seguros de automóvil. Una opción que podría ser
correcta es por ejemplo modelar los conceptos principales de análisis como objetos. Según eso,
se modelaría un objeto “Vendedor”, que conocería a otro objeto “SeguroCoche”. Este primer
diseño es mostrado en la Ilustración 4-2.
Ilustración 4-2. Diseño alternativo 1
Tras contrastarlo con el usuario, el diseñador tiene la constancia de que el modelo
satisface los requisitos actuales. Sin embargo, en la línea que se comentaba anteriormente de
creación de diseños flexibles, se podría intentar añadir valor al diseño. El diseñador puede
pensar que, seguramente, en un futuro se necesite tratar varios tipos de póliza. Entonces, para
mejorar el mantenimiento de la aplicación, decide añadir una clase genérica “Seguro” al diseño,
de manera que mediante herencia se puedan añadir más tipos de póliza, como podrían ser de
salud o de vida. Adicionalmente, se piensa en que el vendedor pueda vender otro tipo de
productos, y se decide añadir otra superclase, en este caso una interfaz “IProducto” para aislar
al resto del sistema de los cambios en caso de que se quieran añadir más tipos de productos.
El diseño resultante tras la mejora propuesta es el que se muestra en la Ilustración
4-3, en el segundo modelo alternativo. El diseñador ha planteado un diseño algo más
complejo, pero indudablemente es más potente, al permitir mejoras y extensiones más
fácilmente. Al mismo tiempo es más estable, ya que un cambio en una parte del diseño, no
afectará al resto del sistema.
A primera vista es difícil decir cuál de los dos diseños es mejor. Probablemente
dependa de si el usuario finalmente decide aprovechar estas opciones de flexibilidad.
En azul se representan las clases que han sido añadidas, y que no están directamente
relacionadas con el problema planteado por el usuario. Se trata de “mecanismos más o menos
artificiales” (Nordberg, 2001), que permiten añadir flexibilidad y estabilidad frente a cambios.
SeguroCocheVendedor
Tesis Doctoral Daniel Cabrero Moreno
111
Ilustración 4-3. Diseño alternativo 2
Como tercera alternativa, el diseñador podría pensar en añadir aún más estabilidad y
flexibilidad a su diseño. Para ello, podría pensar en partir el diseño en diferentes componentes.
Véase la Ilustración 4-4 para observar el detalle del diseño.
Para separar en componentes el sistema, se opta por un patrón DAO (Data Access
Object), que aísle al consumidor de datos, en este caso el objeto “Vendedor”, de la fuente de
datos, en este caso el objeto “SeguroCoche”.
El diseñador optará por utilizar un objeto “Componente”, aislado a su vez por un
Interfaz “IComponente”. Los datos que viajen entre componentes serán encapsulados en
objetos de transferencia “ObjetoTransfer” (“Transfer Objects”, según la especificación). El
resultado es que se han añadido aún más clases de “servicio” para la misma cantidad de clases
de dominio.
SeguroCoche
Seguro
IProducto
Vendedor
Tesis Doctoral Daniel Cabrero Moreno
112
Ilustración 4-4. Diseño alternativo 3
La separación en componentes añade más flexibilidad al sistema, ya que permite aislar
completamente a los otros componentes del sistema de cambios, a la vez que posibilita añadir
nuevos componentes dinámicamente al sistema. Una posible razón que lo justificara podría ser
la posible distribución en un futuro de los distintos componentes en máquinas o tecnologías
distintas.
A medida que evoluciona el diseño, hemos añadido nuevas clases de “servicio”
representadas en azul. Esto nos ha dado sin duda una mayor flexibilidad y estabilidad ante
el cambio que no tiene el primer diseño. Sin embargo, cada vez que añadimos una clase de
servicio es más complejo comprender el diseño, esto es, se ha perdido analizabilidad. En
detrimento del último diseño, es necesario señalar además que el coste de implementación
inicial es muy superior al del primer diseño (sólo 2 de las 7 clases que lo componen hacen
referencia a objetos del modelo de dominio).
Por tanto, según lo analizado en este pequeño ejemplo, concluimos que añadir puntos
de flexibilidad y estabilidad no es gratis. Ya que tiene un coste que debe ser balanceado en
cada situación concreta. O dicho de otro modo, es necesario estimar el “valor” que aporta al
conjunto del sistema introducir puntos de flexibilidad, o en terminología de Nordberg, el valor
que aporta “añadir indirecciones”. En palabras de Boehm, “el valor de un diseño se maximiza
si el esfuerzo adicional de introducción de flexibilidad es utilizado en un futuro. Si el cambio no
ocurre, el valor de dicho diseño disminuye, porque la flexibilidad no justifica el sobreesfuezo”
(Boehm & Sullivan, 2000).
SeguroCoche
Seguro
ConectorCo
mponente
IProducto
Vendedor ObjetoTransfer
IComponente
Tesis Doctoral Daniel Cabrero Moreno
113
4.2.2 El problema de la utilización de patrones de diseño
De acuerdo con la especificación ISO/IEC 9126 2001 – “Calidad de Productos
Software” (ISO, 2001), la mantenibilidad está subdividida en cinco sub-características:
Analizabilidad, Cambiabilidad, Estabilidad, Testabilidad y Conformidad. Observando el ejemplo
anterior, vemos que las tres primeras son las que han ido variando con mayor claridad según
introducíamos clases de servicio. A continuación se describen más en detalle:
o Analizabilidad, “atributos del software que se refieren al esfuerzo necesario
para diagnosticar deficiencias o causas de fallos o para identificar las partes a
modificar”. Posibilita entender el diseño, requisito imprescindible para poder
ampliar o modificar el diseño en un tiempo realista, comprendiendo dónde y
cómo deben realizarse los cambios.
o Cambiabilidad, “atributos del software que refieren al esfuerzo necesario para
modificar, eliminar fallos o cambios de entorno”. Permite que un diseño software
sea fácil de modificar, requisito importante a la hora de ampliar o modificar la
funcionalidad de un código existente.
o Estabilidad, “atributos del software que refieren al riesgo del efecto inesperado
de las modificaciones”. Permite que el impacto de un cambio en el software sea
el mínimo, y esté controlado.
La introducción de indirecciones tiene un gran impacto en la relación entre
analizabilidad, cambiabilidad y estabilidad. Gracias al hecho de que ingenieros del
software experimentados desarrollan patrones, la comunidad de desarrolladores puede utilizar
este conocimiento disponible a través de las librerías de patrones. Un patrón de diseño es una
manera de optimizar la relación entre analizabilidad, cambiabilidad y estabilidad, comprobado
con anterioridad en otros sistemas.
Esta nueva aproximación basada en patrones fue un hito importante para el diseño
software. Sin embargo, desde entonces se han implementado muchas aplicaciones que no
utilizan patrones, y otras sobrecargan el diseño con cantidad de ellos. Si un diseño implementa
muchos patrones, tendrá una gran cambiabilidad y estabilidad, pero perderá en analizabilidad y
además el coste inicial de construcción será mayor. Si no se implementa ningún patrón, la
situación será justo la contraria (Garzás & Piattini, 2002). La Ilustración 4-5 muestra el
concepto.
Tesis Doctoral Daniel Cabrero Moreno
114
Ilustración 4-5. Impacto de los patrones en un diseño
Entonces, ¿Cuándo introducir un patrón de diseño (o eliminación de
antipatrón) o una indirección? Los ingenieros del software se enfrentan a este problema
cada vez que deciden añadir nuevos niveles de abstracción a sus diseños. Hasta ahora, el
hecho que determinaba si una indirección añadía valor al sistema era la experiencia o la astucia
del desarrollador. Términos como “astucia” o “experiencia” señalan de por sí una carencia de
sistematización y aproximación metodológica al problema.
Sin embargo, las mejoras en la estabilidad y la flexibilidad no se limitan únicamente a
añadir indirecciones. En este contexto, también puede considerarse mejora la modificación de
un diseño, desplazando responsabilidad de una sola clase en varias clases más pequeñas y
cohesionadas. Este tipo de casos, aun no tratándose de indirecciones, sacrifican la
analizabilidad de un sistema en beneficio de una mayor flexibilidad y estabilidad. Esta mejora
de diseño en concreto entraría dentro del grupo de aplicación de patrones y eliminación de
antipatrones.
Es importante aclarar que las mejoras de diseño pueden materializarse mediante la
introducción de indirecciones, la aplicación de patrones de diseño (que suele llevar asociada la
introducción de indirecciones, aunque no siempre es así), o la eliminación de antipatrones o
bad smells.
4.2.2.1 El valor de la utilización de un patrón
Algunas métricas se han propuesto para encontrar el número óptimo de indirecciones
en un diseño basándose en la relación entre el número de clases de servicio y número de
clases de análisis. El problema es que estas aproximaciones se han hecho siempre sin tener en
cuenta las consideraciones de valor, basándose simplemente en el número de patrones. Las
propuestas encontradas hasta ahora tienen un enfoque de valor neutro.
El valor que aporta una indirección depende de dónde (sobre qué concepto) y cómo
(solucionando qué problema) sea aplicada dicha indirección, y de las características del
Tesis Doctoral Daniel Cabrero Moreno
115
proyecto específico (si los implicados harán uso o no del aumento de flexibilidad y
estabilidad). Llevado a la práctica, se puede decir que el diseñador experimentado asigna
instintivamente valor a las indirecciones cuando decide si aplicarlas o no a su diseño. Los
argumentos más comunes a favor de introducir una indirección son:
“Esta parte del diseño es crítica, y debemos aislarla de los efectos en cambios del
resto del sistema” (muy relacionado con la estabilidad).
“Es muy posible que esta clase pueda cambiar o ser extendida en el futuro, de forma
que debemos potenciar su flexibilidad ante cambios” (relacionado con la
cambiabilidad).
En esos casos, el experto evalúa si la perdida de analizabilidad y el incremento del
coste inicial vale la pena, porque hay un requerimiento específico de estabilidad (en el primer
caso), o de cambiabilidad (en el segundo) que lo justifica.
La carencia que este razonamiento informal plantea es la falta de sistematización de la
misma, que en última instancia hace depender la decisión de la experiencia o intuición
del ingeniero. Una aproximación de ingeniería debería evitar dicha dependencia, en beneficio
de una aplicación sistemática de los criterios de diseño.
Otra carencia fundamental, es que el experto suele aplicar sus propios criterios de
importancia y flexibilidad, es decir, suele aplicar su visión del valor al diseño. La orientación
basada en valor sugiere que sean los distintos implicados los que aporten su visión de
valor (qué cambiará, qué es importante, qué debe ser estable…), y que el experto oriente el
diseño a partir de dicho valor.
4.2.3 Aproximación sistemática al problema
Con el objetivo de formalizar el problema del proceso descrito en el apartado anterior,
donde el diseñador evalúa la validez de cada decisión de diseño, eligiendo entre complicar o
mantener simple el sistema, proponemos modelar las decisiones entre dos opciones de diseño
como la diferencia entre el diseño existente y el diseño con una mejora incluida.
La Ilustración 4-6 muestra el proceso mediante un gráfico en el que las “X”
representan posibilidades de mejora de diseño. Una mejora en el diseño puede ser por
ejemplo, la introducción de un patrón de diseño, o la reestructuración de una parte del diseño
que viola una determinada regla de diseño (Ver capítulo de reglas de diseño del ANEXO I para
más detalle sobre las reglas de diseño).
En el eje de las abcisas representaremos la importancia relativa del artefacto sobre el
que se ejerce la mejora. En el eje de las ordenadas, se situará la probabilidad de cambio
asociada con dicho artefacto.
Tesis Doctoral Daniel Cabrero Moreno
116
Ilustración 4-6. Priorización de mejoras de diseño
De esta manera se trata de representar gráficamente el razonamiento
anteriormente expuesto, donde a mayor probabilidad de cambio y mayor importancia, mayor
será la prioridad de añadir una mejora de diseño en ese punto. Si dividimos todo el cuadrante
de la gráfica en sectores, concluiremos que debemos descartar los que tengan menor prioridad
de cambio y menor importancia para priorizar las mejoras sobre los artefactos más cambiantes
e importantes.
Tesis Doctoral Daniel Cabrero Moreno
117
4.3 Generalización del problema: Aplicando GVAL
La aproximación al problema de la definición de valor en diseño mostrada en la
Ilustración 4-6 supone una primera aportación importante en la comprensión del problema a
abordar. Es evidente que, tal y como señalaba Boehm, los diseños orientados a predecir los
cambios aportan más valor, siempre que esos cambios se lleven a cabo. Por tanto, la
probabilidad de cambio de los distintos requisitos es un factor muy importante en lo referente a
la definición de valor.
Según el ejemplo anterior, la importancia relativa de los artefactos es otro aspecto
importante de cara a diseñar sistemas que aporten valor a los implicados. El objetivo de una
indirección no es únicamente proporcionar un punto de flexibilidad, sino también añadir
estabilidad ante propagaciones de cambios.
Sin embargo cualquier otro indicador de valor establecido en el árbol de
indicadores de la Ilustración 3-1 puede ser susceptible de ser aplicado para guiar los diseños.
La flexibilidad requerida por los requisitos, la fiabilidad, o incluso la urgencia y los costes a
ahorrar una vez en producción, son elementos que también podrían ser tenidos en cuenta a la
hora de introducir indirecciones en un diseño.
Las tareas a priorizar utilizando dichos indicadores son también un aspecto novedoso a
tener en cuenta, que no ha sido abordado con anterioridad. Por primera vez hemos
proporcionado una primera aproximación en el ejemplo a través de “mejoras de diseño”, pero
es necesario definir más en detalle qué debe ser priorizado en el ámbito del DSBV.
Finalmente, como se señalaba anteriormente, es importante que las indicaciones de
valor (en el caso del ejemplo, la importancia y la probabilidad de cambio), provengan de los
implicados en el sistema, en lugar de ser asignados directamente por el diseñador.
Por lo tanto, muchas otras combinaciones de indicadores y tareas son posibles
gracias al marco genérico de aplicación de valor propuesto por GVAL. En las
siguientes secciones se analizará en detalle los elementos que pueden ser utilizados para guiar
el valor de las decisiones de diseño.
Tesis Doctoral Daniel Cabrero Moreno
118
4.3.1 Indicadores de valor en diseño
4.3.1.1 Obtención del valor de artefactos de diseño utilizando trazabilidad
En el Capítulo 3 se presentaba un método genérico de aplicación de valor llamado GVAL,
basado en establecer una serie de indicadores de valor de los distintos artefactos software.
Estos indicadores guían a la postre la aplicación de las distintas técnicas de IS, denominadas
tareas priorizables en el ámbito de GVAL. Si se observa el árbol de indicadores de la Ilustración
3-1, se concluye que la mayoría de los indicadores de valor (los que están en la parte izquierda
y central del árbol) aplican únicamente a los requisitos de un sistema software.
A lo largo de toda la literatura se puede observar además que, salvo contadas
excepciones, el valor que proporciona un sistema se cuantifica en función de los requisitos. Es
completamente lógico dado que, como se ha comentado anteriormente, el valor percibido por
los implicados debe extraerse utilizando los únicos artefactos entendibles por estos: los
requisitos.
Sin embargo, el objetivo del DSBV es evaluar la importancia de los artefactos de diseño,
para tomar decisiones de diseño en base a ello. Es por tanto necesario estimar el valor relativo,
no sólo de los requisitos, sino también de otros artefactos software. Pero, ¿cómo saber qué
importancia tiene para el usuario una determinada clase, método o paquete?
Pensamos que este es el principal motivo de que no sea común utilizar técnicas basadas en
valor en el ámbito del diseño.
Pongamos por ejemplo que queremos saber qué importancia relativa tiene un artefacto
de diseño para el conjunto de los implicados. No es posible preguntárselo a los implicados,
dado que no conocen el significado de “clase” o “método”, y aunque lo conocieran, no es
sencillo saber la influencia que cada uno de ellos tiene en las operaciones de negocio. Tampoco
es posible preguntarle a este respecto al equipo de desarrollo, dado que en muchos casos no
sabe qué método influye en qué operación de negocio, y mucho menos qué importancia
relativa tiene dicha operación de negocio para los implicados. Para unir el mundo del diseño
y el valor relativo de los sistemas, proponemos utilizar la relación existente entre
ambos, es decir, la trazabilidad.
Esta relación nos permitirá analizar qué artefactos de diseño están relacionados con los
requisitos catalogados como “importantes”, trasladando dicha “importancia” desde los
requisitos a las clases, objetos, paquetes o subsistemas. Por ejemplo, si un requisito tiene un
33% de importancia relativa según los usuarios, y sabemos que este requisito está relacionado
con las clases A y B, deduciremos que dichas clases tienen también un 33% importancia
relativa. Por tanto, una modificación en ellos puede afectar negativamente a partes del sistema
“importantes” para el usuario. El mismo razonamiento puede ser aplicado a cualquier indicador
de valor que aplique sobre los requisitos.
Tesis Doctoral Daniel Cabrero Moreno
119
Nótese, sin embargo, que la definición y mantenimiento de la trazabilidad de todos los
artefactos de diseño y código supone un coste enorme para el equipo de desarrollo. Teniendo
en cuenta que solamente son relevantes los requisitos que tienen mayores indicadores de
valor, se opta por invertir esfuerzos en trazar sólo en los requisitos catalogados como más
importantes.
Por este motivo, y dado que vamos a seleccionar para su trazado los requisitos que
tengan unos indicadores de valor más claros, se recomienda descartar técnicas automáticas
(basadas en Recuperación de la Información) o restringidas (trazado de RNF a través de
patrones, y enlaces ejecutables), recomendando el trazado de enlaces simples. (Véase el
resumen de técnicas de trazabilidad del ANEXO I para más información sobre cada técnica de
trazado).
Como principal ventaja de la trazabilidad aplicada a indicadores, cabe señalar que
permitiría aprovechar toda la información sobre los distintos aspectos de valor de los
implicados para guiar el diseño de los sistemas. Este punto es especialmente importante,
ya que actualmente existe una desconexión considerable, llamada “separation of concerns” por
Boehm, entre las labores de diseño y el valor que aportan dichos diseños a los usuarios. La
técnica, como se verá en la siguiente sección, es extensible a cualquier indicador de valor. El
campo de investigación que se abre en la aplicación de dichos conceptos a la aplicación de
patrones de diseño, modularidad, y muchos otros conceptos, es muy amplio.
Sin embargo, también existen inconvenientes. Es necesario que exista una
especificación de requisitos, y tener acceso directo a los stakeholders, lo cual en los sistemas
reales no es siempre posible. También es necesario disponer de la información de trazabilidad,
cuya información detallada está raramente disponible en los sistemas legados. La definición y
mantenimiento de la información de trazabilidad es una actividad que consume tiempo y
esfuerzos, por lo que no siempre será aconsejada su utilización. No obstante, para mitigar este
inconveniente, se plantea realizar esta labor sólo para los requisitos que a priori
apuntan indicadores de valor más elevados.
Esto implica que esta técnica sólo será aplicada en la práctica en alineación del valor
con el desarrollo de nuevos sistemas, no en refactorizaciones de sistemas legados, donde
la trazabilidad no suele existir.
Por último, es importante resaltar la diferencia entre la trazabilidad necesaria para
relacionar las indicaciones de valor con los artefactos software y la trazabilidad orientada a
mejorar la mantenibilidad. La primera tiene por objetivo trasladar las directrices de valor desde
los requisitos a las demás fases del desarrollo, sólo se realizará sobre algunos requisitos, y se
realizará o no en función de todos los indicadores de valor. La segunda es considerada una
tarea priorizable (figura en el árbol de tareas priorizables), y únicamente se implementará si los
indicadores de valor asociados a esta tarea priorizable así lo sugieren. Según lo anterior, una
vez obtenidas las directrices de valor, la trazabilidad entre artefactos se realizará si cualquiera
de las dos necesidades es detectada.
Tesis Doctoral Daniel Cabrero Moreno
120
4.3.1.2 Influencia de los indicadores en la introducción de indirecciones
No todos los indicadores tienen una influencia positiva sobre la introducción de
patrones e indirecciones en los diseños. La Ilustración 4-7 muestra los indicadores subjetivos
del árbol de indicadores definidos en el Capítulo 3, consistente en los requisitos subjetivos
proporcionados por los implicados no técnicos (rama izquierda), y los requisitos subjetivos
proporcionados por los ingenieros de software (rama derecha). Cada requisito tiene una
influencia, bien positiva (marcada con el icono ), bien negativa (icono ), bien
dependiente de la situación concreta (icono ), en la introducción de indirecciones en los
diseños.
Ilustración 4-7. Indicadores de valor con influencia en los diseños
Los indicadores de “reducción de costes una vez en producción” y “urgencia en
implementación” son marcados como de influencia negativa ( ) en la introducción de
indirecciones, debido a que éstas incrementan el coste inicial. En proyectos donde sea
necesario tener muy rápidamente el sistema en producción, puede aportar más valor primar la
simplicidad del diseño, aunque el esfuerzo de mantenimiento sea mayor.
Tesis Doctoral Daniel Cabrero Moreno
121
Valores altos de los indicadores de “complejidad técnica” y “riesgo técnico”, también
tienen influencia negativa ( ) en la introducción de indirecciones, dado que complican los
diseños (ya de por sí complejos y arriesgados) y reducen su analizabilidad.
El valor para la sociedad, fidelización de cliente, o retorno de inversión ( ) no
aportan información relevante a nivel de estabilidad, urgencia o flexibilidad requerida por los
sistemas. En general no tendrán influencia en el diseño. Para saber si alguno de estos valores
tiene incidencia en la introducción de indirecciones es necesario evaluar cada caso particular.
El resto de los indicadores, relacionados con conceptos como la importancia,
flexibilidad, probabilidad de cambio… etcétera, está relacionado positivamente ( ) con la
introducción de patrones.
Un mismo artefacto de diseño puede estar asociado a varios indicadores, algunos de
influencia negativa, y otros de influencia positiva. En este caso, es necesario aplicar el método
genérico propuesto por GVAL. Los valores asignados a los distintos indicadores serán
sumados (indicadores de influencia positiva) o restados (indicadores de influencia negativa).
Otro factor que limitará la aplicación de indirecciones es el incremento del coste, que
será mostrado a través de los escenarios de coste previstos en el paso 4 de GVAL.
El siguiente epígrafe define cuáles son las tareas priorizables en función de los factores
comentados, que hasta ahora han sido referidas de manera genérica como “mejoras de
diseño”.
4.3.2 Tareas priorizables en diseño
Según lo expuesto anteriormente, los puntos de flexibilidad o estabilidad de un sistema
son introducidos principalmente a través de indirecciones y clases de servicio, insertadas en las
clases del modelo de dominio. Por ejemplo, en el ejemplo de la sección 4.2.1, la diferencia
entre los dos primeros diseños alternativos es la introducción de una clase abstracta, y una
interfaz, de manera que nuevas clases concretas no afectasen al resto del diseño y fuese
extensible.
Lo que se propone al aplicar GVAL, es considerar como tareas priorizables la
introducción de mejoras de diseño, de manera que dependiendo de los indicadores de
valor asociados a dichas clases, se invirtiera o no esfuerzo en complicar (a la vez que se
flexibiliza y estabiliza) la relación entre dichas clases.
En ese sentido se proponen dos tipos fundamentales de tareas priorizables: La
corrección de violaciones de reglas de diseño, y la aplicación de patrones. Ambas serán
examinadas en los siguientes epígrafes.
Tesis Doctoral Daniel Cabrero Moreno
122
4.3.2.1 Corrección de violaciones de diseño
Una regla de diseño es una propiedad que los sistemas deben cumplir. La diferencia
entre los dos primeros diseños alternativos del ejemplo de la sección 4.2.1 se podría evaluar en
función del cumplimiento de una regla de diseño. En ese caso, si una regla especificase la
prohibición de que existan referencias a clases concretas, se evaluaría el cumplimiento de dicha
regla sobre el primer diseño, y se obtendría una violación de dicha regla. Una vez identificada
la violación, la solución establece que se cree una abstracción de la clase concreta, o un
interfaz. Corrigiendo dicha violación, se pasaría al segundo diseño.
Tal y como se lleva a cabo en el primer diseño alternativo del ejemplo, la idea principal
es realizar un diseño basado en un modelo que utilice un número mínimo de indirecciones y
clases de servicio, y aplicar las reglas de diseño para marcar las clases o artefactos
sujetos a una posible mejora.
Uno de los problemas de las herramientas existentes, analizadas en el epígrafe de
reglas de diseño del ANEXO I, es que localizan una cantidad inmanejable de mejoras de diseño.
El problema es que los desarrolladores no disponen del conocimiento necesario para guiar
mediante valor las mejoras de diseño del sistema. Como consecuencia, las indirecciones son
introducidas únicamente en algunos puntos, según el criterio subjetivo del diseñador en
cuestión, sin tener en cuenta el valor relativo desde el punto de vista del resto de implicados.
La Ilustración 4-8 muestra una generalización del problema para un diseño cualquiera.
Los puntos del diseño señalados en la ilustración con una “X” son aquellos en los que una regla
de diseño es violada. Es por tanto donde se deberían implementar nuevas indirecciones o
mejoras análogas.
Por tanto, inicialmente se partirá del modelo de dominio, compuesto por conceptos
pertenecientes al universo del discurso, y un número lo más reducido posible de clases de
dominio y de servicio. Posteriormente se añadirán clases en función de las reglas violadas, y el
valor que los artefactos involucrados tengan.
Ilustración 4-8. Identificación de mejoras en un diseño
Se distingue entre las reglas que son tareas priorizables de cara a los diseños
nuevos, y a las refactorizaciones. En lo referente a los diseños nuevos, existen algunas
Tesis Doctoral Daniel Cabrero Moreno
123
reglas donde no tiene sentido la aplicación de valor. Se trata de aquellas reglas cuyo
cumplimiento no incrementa el esfuerzo de desarrollo, dado que supone elegir una alternativa
de diseño de coste más o menos equivalente. Para las refactorizaciones, la situación es
diferente dado que cualquier refactorización supone esfuerzo, y transformar un diseño en otro
siempre supone recursos que es necesario que sean priorizados.
En el anexo I se describe en detalle las distintas fuentes de reglas de diseño
encontradas. Se tomará como referencia el trabajo de agrupación de conocimiento de
microarquitecturas orientadas a objetos (Garzás & Piattini, 2005). De las distintas normas
planteadas, se presentan las reglas de diseño que cumplen las condiciones necesarias para ser
tareas priorizables, y que son señaladas en la Tabla 4-1 con la marca “ ”.
Tesis Doctoral Daniel Cabrero Moreno
124
Regla Diseño nuevo Refactorización
SI Hay dependencias de clases concretas
ENTONCES Hacer que estas dependencias sean de abstracciones.
SI En ejecución un objeto tiene diferente comportamiento según su estado
ENTONCES Colocar cada uno de estos comportamientos en una clase
separada.
SI Existe una dependencia cíclica de clases
ENTONCES Romper dicha dependencia añadiendo una clase que contenga el
contenido referenciado en algún eslabón del ciclo.
SI Una Súper Clase Conoce a Alguna de sus Subclases
ENTONCES Eliminar ese conocimiento.
SI Una subclase implementa una interfaz ya implementada por su superclase
ENTONCES Eliminar la redundancia.
SI Un Cambio en una Interfaz Impacta en Muchos Clientes
ENTONCES Crear interfaces específicas para cada cliente.
SI Entre una Interfaz y su Implementación no hay una Abstracción
ENTONCES Crear una clase abstracta con una implementación por defecto
entre la interfaz y la clase que la implementa.
SI Una Súper-clase es Concreta
ENTONCES Reestructurar para eliminarla.
SI Un Servicio Tiene Muchos Parámetros
ENTONCES Crear varios métodos, reduciendo la lista o pasar un objeto.
SI Una clase tiene muchos métodos
ENTONCES Reducir su tamaño repartiendo funcionalidad en otras clases.
SI Una clase tiene muchos atributos
ENTONCES Reducir su tamaño repartiendo atributos en otras clases.
SI Una clase tiene muchas dependencias con otras clases
ENTONCES Reestructurar el modelo para reducir el número de
dependencias.
SI Una Clase Rechaza algo de lo que hereda
ENTONCES Evitarlo, generalmente cambiando la herencia por delegación.
SI Los datos de una clase son públicos o protegidos
ENTONCES Hacer estos privados y acceder a ellos a través de servicios.
Tabla 4-1. Catálogo de reglas (Garzás & Piattini, 2005) que corresponden a tareas priorizables
Tesis Doctoral Daniel Cabrero Moreno
125
4.3.2.2 Aplicación de patrones de diseño
Nordberg comenta como “el corazón de muchos patrones de diseño es una indirección
entre un servicio proveedor y un servicio consumidor. Con objetos las indirecciones se
implementan generalmente vía interfaces abstractas” (Nordberg, 2001). Así, se observa lo
siguiente: Cada vez que introducimos un patrón de diseño se introduce en la mayoría de los
casos, al menos, una indirección (Garzás & Piattini, 2002).
Arreglar una violación de una regla de diseño implica en la mayoría de los casos la
aplicación de un patrón de diseño. De hecho, la ontología introducida por Garzás y Piattini
postula que “Aplicar una regla implica utilizar un patrón” (aunque no es condición necesaria), y
que “un patrón cumple reglas” (Garzás & Piattini, 2005). Por ejemplo, la tarea de arreglar una
violación de la primera regla de diseño “No debe haber dependencias de clases concretas”,
conlleva crear una clase abstracta, y hacer que todas las referencias sean a través de dicha
abstracción. También implica que cuando se creen dichos objetos, dicha creación deba hacerse
utilizando algún tipo de patrón creacional, por ejemplo un “abstract factory” (Gamma et al.,
1995).
Por lo tanto, la aplicación de patrones de diseño es un tipo específico de
corrección de violaciones de reglas de diseño.
Tesis Doctoral Daniel Cabrero Moreno
126
4.4 Ejemplo de Utilización
Ilustraremos la aplicación del DSBV a través de un ejemplo simple, siguiendo las
pautas establecidas en los epígrafes anteriores.
4.4.1 Fase I: Adaptación al tipo de proyecto
En la sección 3.4.2 se presenta un ejemplo donde se evalúa un sistema en función de
cuatro indicadores de valor: Importancia de fallo, flexibilidad, urgencia, e importancia relativa.
En la página 96, La Ilustración 3-14 muestra un ejemplo de distribución de valor de los
distintos indicadores para un grupo de requisitos de un sistema.
Por tanto, por simplicidad, se utilizará la información de los pasos 1 y 2 de dicho
ejemplo. Dado que para ilustrar el proceso de DSBV se utilizará el mismo ejemplo expuesto
entonces, remítase el lector a dichas secciones para más información sobre los pasos que
preceden a la aplicación de la Fase II.
4.4.2 Fase II: Aplicación al proyecto
Se tomará también el ejemplo presentado en la sección 3.4.3 como base para la
ilustración que nos ocupa. La fase de evaluación de requisitos fue utilizando AHP como técnica
de elicitación (paso 3).
Como se ha comentado anteriormente, la trazabilidad es una tarea muy costosa. Por
ese motivo, se recomienda economizar los esfuerzos en la medida de lo posible. Como norma
general, se tomarán en cuenta únicamente los requisitos mejor valorados en función de cada
indicador. Siguiendo con el ejemplo planteado, en la Ilustración 4-9 se muestra cómo es
posible elegir gráficamente los requisitos que tienen una mayor puntuación.
En valores normalizados, el valor más significativo de cada requisito obtenido como
consecuencia de la aplicación de GVAL es el siguiente: El Requisito 4 tiene una influencia en la
flexibilidad del 29%. El requisito 8 tiene influencia en la flexibilidad (34%), la importancia de
fallo (24%), y la urgencia (23%). El requisito 6 tiene influencia en la urgencia (23%). El
requisito 5 en la importancia relativa (30%). Por último, el requisito 10 tiene influencia en la
flexibilidad (23%). La Ilustración 4-9 muestra gráficamente los requisitos más relevantes por
cada uno de los indicadores.
Tesis Doctoral Daniel Cabrero Moreno
127
Ilustración 4-9. Elección de indicadores y requisitos para aplicar trazabilidad
La Tabla 4-2 resume los valores más significativos de los indicadores para los requisitos
que deben ser trazados.
R4 R5 R6 R8 R10
I4:Importancia de Fallo 24%
I3:Flexibilidad 29% 34% 23%
I2:Urgencia 23% 23%
I1:Importancia Relativa 30%
Tabla 4-2. Resumen de los requisitos a trazar
Tal y como hemos comentado anteriormente, se recomienda como técnica de
trazabilidad el enlace simple de requisitos con artefactos de diseño (en este caso, clases). En
ese sentido, se utilizará el método clásico de matriz de trazabilidad entre los requisitos y las
clases del diseño del sistema. Un ejemplo de la implementación de la trazabilidad de las clases
de la Ilustración 4-10 se muestra en la Tabla 4-3.
0% 20% 40% 60% 80% 100%
I1 :Importancia Relativa
I2 :Urgencia
I3: Flexibilidad
I4: Importancia falloReq 1
Req 2
Req 3
Req 4
Req 5
Req 6
Req 7
Req 8
Req 9
Req 10
Tesis Doctoral Daniel Cabrero Moreno
128
R4 R5 R6 R8 R10 TOTAL
Clase 1 I1:30% I3:34% I1:30%; I3:34%
Clase 2 I3:29% I3:34%;I2:24% I3:63%; I2:24%
Clase 3 I3:34% I3:34%
Clase 4 I3:29% I3:23% I3:52%
Clase 5 I1:30% I2:23% I1:30%; I2:23%
Clase 6 I2:24% I3:23% I2:24%; I3:23%
Clase 7 I3:29% I3:23% I3:52%
Clase 8
Clase 9
Tabla 4-3. Trazado de la probabilidad de cambio a las clases de diseño
Como puede observarse, a través de la trazabilidad entre los requisitos y las clases, es
posible asignar un valor relativo para cada clase. La Clase 1 está trazada con el Requisito 5 y
con el Requisito 8. Por lo tanto, las importancias relativas con respecto a la importancia relativa
(I1:40%) y flexibilidad (I3:34%) se trasladan a la Clase 1.
Si hubiese varios requisitos trazados con una misma clase, y con un mismo indicador
alto, las importancias se sumarían, como ocurre con la Clase 7, donde la flexibilidad es del
52%, debido a la suma de la flexibilidad del 29% del Requisito 4, y del 23% del Requisito 10.
La suma de los indicadores se justifica por el hecho de que las importancias de los requisitos
están normalizadas (suman 100% entre todas), por lo tanto, en el caso en que una clase
afectase a la ejecución de todos los requisitos, se sumarían los indicadores de todos ellos, y
obtendríamos un valor máximo del 100%.
El mismo razonamiento ejemplificado aquí con clases puede ser aplicado a cualquier
otro artefacto de diseño, como métodos, atributos, paquetes, módulos o subsistemas.
4.4.3 Fase III: Aplicación de Tareas Priorizables
Se define la aplicación de dos tareas priorizables para este ejemplo de diseño.
Tesis Doctoral Daniel Cabrero Moreno
129
Ilustración 4-10. Diseño antes de la aplicación de DSBV
La primera tarea priorizable es la corrección de la violación de la regla “las dependencias
no pueden ser de clases concretas”. La aplicación de dicha regla a todo el modelo implicaría
que para toda clase tuviera una clase abstracta o interfaz padre, que todas las relaciones
fuesen a través de dicha abstracción, y que para la creación de los objetos asociados se
utilizasen patrones creacionales (Gamma et al., 1995). La segunda tarea priorizable es rotura
de un ciclo de referencias mediante la adición de una clase adicional, como cumplimiento de la
regla “evitar dependencias cíclicas entre clases”.
La aplicación de ambas tareas sobre todos los artefactos resultaría en un incremento
innecesario de clases de servicio, en el caso del ejemplo se añadirían 8 clases de servicio (una
por violación) que supondrían una carga de trabajo considerable, además de aportar muy poco
a la mantenibilidad debido a la reducción de la analizabilidad. Por este motivo, se plantea la
aplicación del paradigma basado en valor.
Según establece GVAL, es necesario trazar ambas tareas priorizables con los indicadores
de valor. La Ilustración 4-11 muestra la distribución pesos de indicadores de valor por cada
regla. El indicador “Urgencia” (I2), tiene influencia negativa sobre la aplicación de ambas
tareas priorizables. Por ese motivo se representa por debajo del 0%. El resto de indicadores
tienen peso positivo, pero el indicador de “Flexibilidad” (I3) es especialmente importante en el
caso de la segunda tarea priorizable, ya que si no está previsto tener más comportamientos en
el futuro, el coste de separar cada tarea en una clase sería difícilmente justificable.
Tesis Doctoral Daniel Cabrero Moreno
130
Ilustración 4-11. Distribución de pesos de indicadores por Tarea de Diseño
En contraste con el ejemplo de aplicación de GVAL mostrado en el Capítulo 3, los
indicadores ahora indican el valor relativo de clases de diseño, en lugar de requisitos.
Pongamos por ejemplo que el diseño sobre el que debemos priorizar las tareas es el mostrado
en la Ilustración 4-12, donde pueden verse las violaciones de las dos reglas del ejemplo.
Ilustración 4-12. Violaciones encontradas en el diseño antes de la aplicación de DSBV
Nótese que en este ejemplo simple, únicamente para la aplicación de dos tareas
priorizables, ya hay un gran número de violaciones detectadas, con lo que el esfuerzo de
-40%
-20%
0%
20%
40%
60%
80%
100%
T1 :Regla "Dependencias de clases concretas"
T2 :Regla "Ciclo de clases"
Distribución de pesos de indicadores (PI) por tarea (T)
PI1 :Importancia Relativa PI2 :Urgencia PI3: Flexibilidad PI4: Importancia fallo
T1 T1
T1
T1
T1
T1 T2
T2
Tesis Doctoral Daniel Cabrero Moreno
131
adaptación del diseño será considerable. En un caso real, con cientos de clases y decenas de
tareas priorizables, el esfuerzo necesario para acometer todas las mejoras puede requerir de
una cantidad de recursos muy grande. Adicionalmente, tal y como se ha visto anteriormente,
según se añadan indirecciones, se perderá analizabilidad, por lo que es necesario asegurarse
de que las tareas priorizables se apliquen únicamente allí donde aporten valor.
La Ilustración 4-13 muestra los indicadores de valor asociados a cada artefacto (en este
caso a cada clase).
Ilustración 4-13. Distribución de indicadores por Clase de Diseño
Dado que los artefactos que deben ser implementados de manera más urgente influyen
negativamente en la aplicación de tareas priorizables, el valor de los artefactos “urgentes” será
pequeño, a no ser que su importancia relativa y/o flexibilidad sea comparativamente grande.
La Tabla 4-4 muestra el valor de la aplicación de cada tarea sobre las distintas clases
resultantes del proceso mencionado.
C1 C2 C3 C4 C5 C6 C7 C8 C9
Tarea 1 57,05 19,61 15,87 24,28 31,78 24,28
Tarea 2 41,25 4,05
Tabla 4-4. Valor de las tareas priorizables para cada clase
A primera vista, ya se intuye que para maximizar el valor minimizando el coste, es
necesario en primer lugar aplicar ambas tareas a la Clase 1. La Tarea 1 también puede ser
aplicada quizá a la Clase 5, y con menor prioridad, a las Clases 2, 3 ,4 y 7. En este punto, ya se
dispone de información suficiente para priorizar este diseño. Sin embargo, se trata de pocas
tareas y clases. Si se desea que la técnica pueda ser aplicada para cientos de clases y decenas
de tareas de forma automatizada, es conveniente continuar con la aplicación metodológica de
los pasos definidos en GVAL.
0% 20% 40% 60% 80% 100%
I1 :Importancia Relativa
I2 :Urgencia
I3: FlexibilidadClase 1
Clase 2
Clase 3
Clase 4
Clase 5
Clase 6
Clase 7
Clase 8
Clase 9
Tesis Doctoral Daniel Cabrero Moreno
132
El siguiente paso definido por GVAL es la definición del coste. Supongamos por
simplicidad que el coste por realización de la Tarea 1 es de 250 euros para cualquier clase, y el
coste de aplicar la Tarea 2 es de 200 euros. Otra posible suposición podría ser asignar un coste
en función del tamaño de las clases.
GVAL establece entonces la definición de los distintos escenarios por tarea, según la
variación del coste. En este caso, se plantea la siguiente distribución de límites de valor.
Ilustración 4-14. Escenarios de límite de valor para la aplicación de Tareas de Diseño
El coste asociado a los distintos escenarios se resume en la siguiente tabla:
Clases con mejoras de diseño Coste Adicional
Escenario 1 T1: {C1}; T2: {} 250 €
Escenario 2 T1: { C1}; T2: {} 250 €
Escenario 3 T1: { C1}; T2: {C1} 450 €
Escenario 4 T1: { C1}; T2: { C1} 450 €
Escenario 5 T1: { C1, C5}; T2: { C1} 700 €
Escenario 6 T1: { C1, C4, C5, C7}; T2: { C1} 1200 €
Escenario 7 T1: { C1, C2, C4, C5, C7}; T2: { C1} 1450 €
Escenario 8 T1: { C1, C2, C4, C5, C7}; T2: { C1} 1450 €
Escenario 9 T1: { C1, C2, C3, C4, C5, C7}; T2: { C1} 1700 €
Escenario 10 T1: { C1, C2, C3, C4, C5, C7}; T2: { C1} 1700 €
Tabla 4-5. Aplicación de los escenarios a las mejoras de diseño
020406080
100120
Esce
nar
io 1
Esce
nar
io 2
Esce
nar
io 3
Esce
nar
io 4
Esce
nar
io 5
Esce
nar
io 6
Esce
nar
io 7
Esce
nar
io 8
Esce
nar
io 9
Esce
nar
io 1
0
T1: Dependencia
No se aplica Se aplica
020406080
100120
Esce
nar
io 1
Esce
nar
io 2
Esce
nar
io 3
Esce
nar
io 4
Esce
nar
io 5
Esce
nar
io 6
Esce
nar
io 7
Esce
nar
io 8
Esce
nar
io 9
Esce
nar
io 1
0
T2: Varios Comport.
No se aplica Se aplica
Tesis Doctoral Daniel Cabrero Moreno
133
La aplicación de la metodología confirma el orden de aplicación de las técnicas,
dependiendo del presupuesto disponible, y siempre en un orden que maximice el valor
planteado por los distintos implicados a través de los indicadores de valor. La aportación más
importante de la técnica, es guiar las decisiones de diseño a partir del valor percibido por los
distintos implicados. En este caso se aplicará el escenario 5, tal y como se preveía
informalmente antes de aplicar los últimos pasos.
La aplicación de las sugerencias de mejora de tarea especificadas en el escenario 5, tras
la aplicación de GVAL deja el diseño mostrado en la Ilustración 4-15. Se han creado dos
interfaces, correspondientes a las clases 1 y 5, y adicionalmente, se ha creado una nueva clase
que rompe la referencia en la que la Clase 1 estaba involucrada.
Ilustración 4-15. Diseño tras la aplicación de DSBV5
La reducción de costes de la introducción de mejoras en los diseños ha sido considerable
en este ejemplo simple. Suponiendo que el coste inicial de implementación sea
aproximadamente de 250 euros por clase, es decir, 2250 euros en total, la siguiente gráfica
muestra el coste por escenario del diseño e implementación de cada diseño resultante.
5 Nótese que el ejemplo es ilustrativo y no se consideran clases de servicio de implementación
de patrones creacionales (como por ejemplo factorías), o ni patrones de acceso a datos (como
por ejemplo Data Access Object). En un caso real, las normas se aplicarían a todo el conjunto
de clases, incluidas las mencionadas en caso de existir, que no han sido presentadas en el
ejemplo por motivos de claridad en la exposición.
T1 T1
T2
Tesis Doctoral Daniel Cabrero Moreno
134
Ilustración 4-16. Evolución del coste con las variaciones de límite en DSBV
El ahorro de coste respecto a la aplicación de todas las mejoras de diseño posibles varía
entre escenarios desde el 5% hasta el 40%. En el caso del escenario elegido, el coste ahorrado
mediante la priorización basada en valor es del 29%.
0,00 €
500,00 €
1.000,00 €
1.500,00 €
2.000,00 €
2.500,00 €
3.000,00 €
3.500,00 €
4.000,00 €
4.500,00 €
0 2 4 6 8 10 12
Co
ste
Escenarios
Escenario
Elegido
Tesis Doctoral Daniel Cabrero Moreno
135
4.5 Aportaciones Realizadas en Este Capítulo
En este capítulo se ha presentado el concepto valor en diseño, inédito hasta ahora en
la literatura. A través de ejemplos, se definen los objetivos últimos de las decisiones de diseño
desde el punto de vista de todos los implicados.
La mayor aportación realizada en este capítulo es la introducción del Diseño Software
Basado en Valor (DSBV), que a través de la aplicación de GVAL, aplica a diseños reales los
conceptos de valor percibidos por todos los implicados a los diseños. De este modo, se
pretende guiar las decisiones de diseño de manera que maximicen las expectativas de todos
los implicados.
Dado que los usuarios no tienen el conocimiento técnico suficiente para evaluar el
diseño, en el ámbito de GVAL se utilizan técnicas de trazabilidad para trasladar la
importancia relativa de los requisitos a los artefactos de diseño. Esta orientación
tampoco ha sido abordada hasta entonces, constituyendo un enfoque completamente nuevo.
La aplicación de GVAL se lleva a cabo del mismo modo que se presentó en el Capítulo 3.
Para ello, los indicadores de valor han sido clasificados en función de su influencia en las
decisiones de diseño, y las tareas priorizables han sido definidas en función de reglas
de diseño.
Finalmente se muestra un ejemplo de aplicación de GVAL sobre un diseño simple, con el
objetivo de ilustrar la aplicación de los conceptos teóricos presentados a lo largo del capítulo.
Tesis Doctoral Daniel Cabrero Moreno
136
Tesis Doctoral Daniel Cabrero Moreno
137
Capítulo 5 –
Mantenimiento
Software Basado en
Valor
5.1 Introducción
Cuando se trata de la priorización de recursos y costes, muy ligados al valor global de
las propuestas, el mantenimiento es un elemento que puede ser fundamental, dado que
consume la mayor parte del ciclo de vida de los sistemas (Pigosky, 1997, Bennet &
Rajlich, 2000), especialmente en el caso de los sistemas de éxito, que son los que más valor
aportan.
Según los estudios realizados (Wiederhold, 2006), el coste de la gestión de un sistema
crece constantemente y raramente se reduce, reservando excepcionalmente la labor de
simplificación y reorganización de dichos sistemas a complejas y costosas tareas de
reingeniería global. Incluso en el caso de simplificación mediante reingeniería, los ingenieros
del software no disponen de datos que permitan evaluar la importancia relativa de los distintos
artefactos a reingenierizar.
En este capítulo se propone aplicar la orientación basada en valor al mantenimiento. La
idea principal es hacer énfasis en la distinta aportación de valor que las actuaciones de
mantenimiento de los sistemas tienen para los distintos implicados. En ese sentido se pretende
priorizar los esfuerzos de mantenimiento. Esta aportación es novedosa, al no haber sido
realizada ninguna aportación en este sentido hasta la fecha, y es especialmente relevante dado
el impacto que puede tener la priorización de la inmensa cantidad de recursos que suponen los
mantenimientos.
Tesis Doctoral Daniel Cabrero Moreno
138
Se parte de la idea de que no todos los artefactos software son igualmente
importantes, y por lo tanto, no todas las labores de mantenimiento realizadas sobre ellos
aportan el mismo valor a los implicados en un sistema.
Una manera de optimizar el mantenimiento es seleccionar los elementos de diseño que
aportan una mejor relación valor-coste a la solución, y descartar aquellos que no cumplan
dicha premisa. Otra forma de optimizar el mantenimiento es seleccionar las actuaciones de
mantenimiento más relevantes para los distintos implicados. Ambas aproximaciones son
contempladas en una nueva rama de la ISBV, introducida en esta Tesis Doctoral bajo el
nombre de “Mantenimiento Software Basado en Valor” (MSBV).
Tesis Doctoral Daniel Cabrero Moreno
139
5.2 El Concepto de Valor en Mantenimiento
El mantenimiento de sistemas software tiene algunas peculiaridades que no tiene el
desarrollo de software nuevo, objeto del estudio realizado hasta ahora durante este trabajo. En
muchos casos, las tareas de mantenimiento deben ser realizados sobre sistemas legados,
cuyos implicados pueden no estar disponibles, por ejemplo por haber abandonado la
organización. Adicionalmente, no se suele disponer de información de requisitos, análisis o
diseño, al tratarse los casos más frecuente de mantenimiento de sistemas legados, que
típicamente tienen varios años de antigüedad.
Los condicionantes del mantenimiento de software implican particularidades importantes
en lo que respecta a la definición del valor, dado que en muchos casos no se sabe cuál es el
valor que los sistemas a mantener aportan a las organizaciones. En otros casos, aunque se
conoce el valor, no se sabe qué artefactos de diseño y código están relacionados con cada una
de las funcionalidades valoradas por los implicados, que para mayor complejidad, no están
documentadas en ningún sitio.
Para afrontar esta singular problemática, proponemos dos tipos de orientación al valor
en el ámbito del mantenimiento:
Priorización de actuaciones de mantenimiento. Se propone tratar a las
actuaciones de mantenimiento como requisitos independientes, y estimar el
valor que aportan a los distintos implicados, tal y como se hacía en la
priorización de requisitos basada en valor con GVAL. En el epígrafe 5.2.1 se
plantea este escenario.
Priorización de esfuerzos dentro de cada tarea de mantenimiento. Esta
segunda aproximación consiste en evaluar cada uno de los artefactos a
modificar en las labores de mantenimiento, y priorizar los esfuerzos sobre
aquellos que aporten más valor a los implicados. Se trata por tanto de priorizar y
optimizar el número de acciones a llevar a cabo en el ámbito de la realización de
una tarea de mantenimiento, con el condicionante de preservar la percepción
que los implicados tienen de la funcionalidad del sistema. El epígrafe 5.2.2
plantea este escenario.
Ambas formas de alinear el mantenimiento al valor son compatibles entre sí, del mismo
modo que en el ejemplo de aplicación del método GVAL expuesto en la sección 3.4, la
implementación o no de un requisito era compatible con las distintas técnicas priorizables que
podían aplicarle en el caso de ser implementado.
Tesis Doctoral Daniel Cabrero Moreno
140
5.2.1 Priorización de las actuaciones de mantenimiento
Una primera forma de alinear las labores de mantenimiento con las necesidades de
negocio es aplicar directamente GVAL para priorizar el valor de tareas. Para ello, proponemos
considerar tareas priorizables cada uno de las peticiones de mantenimiento.
Teniendo varias peticiones de mantenimiento, y disponiendo de recursos limitados para
acometerlos, la priorización de los mismos es una tarea habitual para los responsables del
mantenimiento de los sistemas software. La aportación que GVAL puede hacer en este aspecto
es aplicar metodológicamente dicha priorización, en función de los indicadores de valor que se
estimen importantes en cada caso, así como la combinación de distintos indicadores.
Los pasos a llevar a cabo son los mismos que se presentaron para el caso general de
GVAL en el Capítulo 3. En primer lugar se definen los indicadores, que pueden ser cualesquiera
de entre los definidos en el árbol de indicadores de la página 81. Es necesario también definir
las tareas priorizables, tal y como define GVAL. En este caso la realización del mantenimiento o
la priorización de algún aspecto de la realización de dicha tarea, como puede ser por ejemplo la
documentación de la misma.
La aplicación es idéntica al caso general de priorización por requisitos, dado que
podemos considerar las peticiones de mantenimiento como requisitos, y asociarles valor
utilizando GVAL directamente. Todos los pasos son los mismos definidos en el ejemplo general
del Capítulo 3.
En el punto 5.5 se presentan dos ejemplos de aplicación de GVAL al mantenimiento de
software.
5.2.2 Priorización de dentro de cada actuación de mantenimiento
Al igual que sucedía con el diseño, la elicitación del valor relativo de los distintos
artefactos involucrados en los mantenimientos es una tarea compleja. Esto es debido a que,
del mismo modo que sucedía con el DSBV, los implicados no técnicos no tienen el conocimiento
suficiente para evaluar la importancia relativa de aquellos artefactos que no sean requisitos
funcionales.
En la propuesta de DSBV presentada en el 0, se resolvió dicho problema implementando
la trazabilidad de requisitos a artefactos de diseño, para aquellos requisitos cuyos indicadores
eran más importantes. En aquel caso, dado que se estaba en fase de desarrollo, era posible
construir únicamente las trazabilidades que se necesitaran desde la fase de requisitos. Se
trataba de un conocimiento disponible en esa fase del desarrollo, y de un esfuerzo acotado a
realizar.
Tesis Doctoral Daniel Cabrero Moreno
141
Sin embargo, cuando se trata del mantenimiento de sistemas legados, en la mayoría de
los casos no sólo no se dispone de dicha información de trazabilidad, sino que tampoco se
dispone ni de una especificación de requisitos, ni de un diseño que permita soportar el proceso
de asignación de valor realizado en diseño. Por lo tanto, la priorización de esfuerzos de
mantenimiento debe ser realizada de otro modo.
Para poder introducir esta nueva técnica de priorización, es necesario primero distinguir
dos factores fundamentales que afectan al coste de la ejecución de una tarea de
mantenimiento:
En primer lugar está la “analizabilidad”. Para realizar cualquier cambio en
un sistema es necesario comprender primero las partes que lo componen, de
manera que puedan ser localizados los puntos donde hay que tocar para
modificar su comportamiento. Cuanto más complejo y voluminoso sea el
sistema a analizar, mayor será el coste requerido para saber dónde deben ser
realizados los cambios.
En segundo lugar está el número de artefactos a modificar para variar un
comportamiento. Para realizar un cambio que sea coherente con el resto del
sistema, normalmente hay que modificar un número determinado de
artefactos. Cuanto mayor sea el número de cambios a realizar, mayor será el
esfuerzo requerido por dicha actuación.
Para disminuir ambos factores de coste de mantenimiento, proponemos reducir el
tamaño y la complejidad del software a mantener, de forma que se reduzca la analizabilidad, al
ser más simple de comprender el sistema, y se evite en la medida de lo posible modificar
aquellos artefactos que no son importantes para los implicados.
En esa línea, se introduce en este trabajo la “Reducción de Software” (RS), una
nueva propuesta que tiene por objeto aplicar las tareas de mantenimiento únicamente sobre
los artefactos de código más importantes, y donde el resto de artefactos a mantener han sido
“apartados temporalmente” de las labores de mantenimiento. En la práctica, dicha reducción
implica que parte del código se retira del software a mantener, de manera que se
proporciona al equipo de mantenimiento una versión más pequeña y mantenible del sistema.
Tesis Doctoral Daniel Cabrero Moreno
142
5.3 La Reducción de Software (RS) como Tarea
Priorizable
5.3.1 Introducción
Los gestores de sistemas software enfocan casi todo sus recursos a la creación de
nuevos sistemas y funcionalidades, y prácticamente ningún esfuerzo a retirar sistemas y
funcionalidades obsoletas o no utilizadas (Chikofsky, 2007). El resultado de esta práctica, es
que el coste de mantenimiento de los sistemas suele incrementarse de manera ininterrumpida.
La retirada de sistemas no utilizados es una tarea relativamente sencilla partiendo de
estadísticas de utilización disponibles en muchos tipos de sistemas centralizados, incluidos los
Sistemas Web o Mainframe. Desgraciadamente este no es el caso de la simplificación de
subsistemas, módulos o incluso clases de diseño de un aplicativo software, donde las
frecuencias de utilización no son monitorizadas por los equipos de explotación y sistemas. Otro
problema adicional son los efectos colaterales de la retirada de los módulos o subsistemas,
cuyas relaciones pueden hacer que otras partes no funcionen correctamente.
El mantenimiento de los sistemas se ve afectado porque, muy frecuentemente, en la
industria del software se desarrollan productos de gran tamaño, que se corresponden con
especificaciones funcionales simples, que sugieren desarrollos de menor tamaño. Interrogantes
similares a los siguientes son comunes en los equipos de mantenimiento:
¿400.000 líneas de código para algo tan sencillo?
¿Es realmente necesario que el sistema contemple esta funcionalidad?
Este método/clase parece no ser útil. ¿Dejaría de funcionar algo si lo borrase?
En muchos casos, ciertamente la respuesta es no. El problema reside en la
imposibilidad de identificar qué elementos no aportan valor alguno de entre una compleja
maraña de referencias entre clases, habitualmente exentas de la documentación de análisis y
diseño necesaria para comprender el sistema.
El resultado es que tanto si algo funciona como si no, no suele eliminarse ningún
elemento software por temor a efectos indeseados. Este razonamiento, que podría ser definido
como prudente, es generalmente aconsejable de cara a evitar efectos indeseados, pero es lo
que hace que los sistemas sean cada vez más grandes y menos mantenibles.
Tesis Doctoral Daniel Cabrero Moreno
143
5.3.2 El problema del tamaño y la complejidad del software
El tamaño del software disminuye la mantenibilidad y la predictibilidad de los sistemas.
McConell (McConnell, 2006) coincide con otros expertos en que el tamaño de los sistemas
aumenta en un proyecto software las posibilidades de retrasos en la entrega o cancelaciones
del proyectos en una media de un 15% y un 60% respectivamente (Jones, 1998). La gran
mayoría de los autores coinciden también en que el crecimiento de los sistemas es un
problema a evitar de cara a un mantenimiento efectivo del software.
Si bien no existe acuerdo en la tasa media de crecimiento de un sistema a lo largo de
su versionado, “se podría considerar una tasa de crecimiento modesta aquella en que cada
nueva versión añade tantas líneas de código como contenía la versión inicial” (Wiederhold,
2006). Esto significaría que un sistema puede doblar su tamaño en la primera versión,
aumentar un 33% en la segunda, un 25% en la tercera, y así sucesivamente. El aumento del
tamaño de los sistemas hace que en general sean más difíciles de comprender, y más costosos
de mantener a todos los niveles.
Podemos, según lo argumentado anteriormente, concluir que la tendencia natural a lo
largo del tiempo de la mayoría de los proyectos software es la de crecer y volverse más
complejos, y por ende menos mantenibles.
La praxis más común en la industria del software es realizar el mantenimiento de los
sistemas sin realizar optimizaciones, hasta llegar a un punto en que la reconstrucción total se
hace imprescindible por la ineficaz mantenibilidad de los sistemas. De hecho, las técnicas de
simplificación y reducción de sistemas para mejorar la mantenibilidad raramente son
empleadas en la industria de desarrollo software. Sin embargo, el impacto económico del
mantenimiento de los sistemas, unido a la tendencia natural de crecimiento del software,
justifica la realización de un esfuerzo de investigación en ese sentido.
La parte izquierda de la Ilustración 5-1 muestra gráficamente lo comentado
anteriormente, donde las aplicaciones crecen a lo largo de las distintas versiones. Una vez que
el sistema llega a un punto donde es demasiado difícil de mantener, se plantea una
reingeniería, con objeto mejorar la mantenibilidad del diseño.
La parte derecha de la Ilustración 5-1 muestra la nueva orientación, donde en
contraposición con el modelo clásico, se potencia la eliminación de artefactos software que no
aportan valor a lo largo de la vida útil del sistema, de manera que el mantenimiento sea en
todo momento lo más sencillo posible. Nótese que siguiendo esta nueva orientación de
simplificación podremos evitar en muchos casos el costoso proceso de reingeniería. En
su lugar, se llevan a cabo simplificaciones del código no utilizado en cada versión liberada a los
usuarios.
Tesis Doctoral Daniel Cabrero Moreno
144
Ilustración 5-1. Modelo clásico (izquierda) vs modelo propuesto (derecha) en la evolución del tamaño
La idea consiste en desarrollar un método ágil, que permita realizar tareas de
optimización menos pesadas que la reingeniería mostrada anteriormente, eliminando artefactos
que no son necesarios. De esta forma, se pretende que el sistema no crezca indefinidamente a
lo largo del mantenimiento.
5.3.3 Un Primer Ejemplo de RS
Con el fin de que se entienda nuestra propuesta, se procederá a analizar un ejemplo
sencillo de mantenimiento de un sistema. Imaginemos que tenemos un pequeño aplicativo que
permite realizar consultas sobre distintos campos de una base de datos de vehículos y
conductores. En particular, existe una clase en la capa de presentación
(ControladorPresentación) capaz de invocar a clases de negocio de vehículos (GestorVehículos)
y conductores (GestorConductores).
El objetivo de este aplicativo es gestionar el acceso y modificación a sendas bases de
datos de conductores y vehículos. La siguiente figura muestra un diseño en UML de las clases
que componen este pequeño subsistema.
Tesis Doctoral Daniel Cabrero Moreno
145
Ilustración 5-2. Ejemplo simple de modelo de clases a optimizar
Imaginemos ahora que los usuarios únicamente estuvieran interesados en las consultas
de vehículos, de forma que la clase “GestorConductores” únicamente es invocada unas pocas
veces al año. Este hecho podría ser motivado por ejemplo por que la dirección de la
organización ha decidido que el perfil de usuarios que manejan este aplicativo no tenga
permisos para gestionar conductores.
Adicionalmente, las funcionalidades de “insertarConductor” y “borrarConductor”,
incluida dentro de dicha clase, nunca ha sido invocada durante toda la vida de la aplicación,
dado que el alta de nuevos conductores se realiza a través de otro aplicativo. La Tabla 5-1
muestra las frecuencias de utilización de los distintos artefactos de diseño involucrados en el
ejemplo anterior.
Módulo Clase Método
Presentación ControladorPresentación
(14126)
consultarVehiculo (14023)
consultarConductor (3)
Vehiculos GestorVehiculos (21160) borrarVehiculo (100)
insertarVehiculo (500)
consultarVehiculo (20560)
Conductores GestorConductores (20) borrarConductor (0)
insertarConductor (0)
consultarConductor (20)
Tabla 5-1. Número de invocaciones por artefactos.
El equipo de mantenimiento, de nueva incorporación, tiene la sospecha de que el
sistema proporciona funcionalidades que no son utilizadas, pero cada vez que una petición de
mantenimiento es abordada, por prudencia se decide cambiar todos los artefactos implicados.
Es decir, para realizar un cambio, en primer lugar hay que analizar su influencia sobre todas las
clases. En segundo lugar, si añado por ejemplo un parámetro a la tabla de conductores de la
Tesis Doctoral Daniel Cabrero Moreno
146
base de datos, los métodos de lectura, insertado y borrado de conductores deberán ser
modificados para ser coherentes con dicho cambio.
Obviamente, si el equipo de desarrollo hubiera conocido estas frecuencias de utilización
a priori, probablemente no se hubiera desarrollado ninguna gestión de conductores, y casi con
toda seguridad, no se habría construido ninguna inserción ni borrado de conductores. Tampoco
sería necesario modificar dichos artefactos cuando una petición de mantenimiento es atendida.
Incluso pasado un tiempo prudencial de utilización del aplicativo por parte del usuario,
probablemente tampoco se dispusiera de estos datos de gran importancia para priorizar los
esfuerzos.
Basándose en dicha frecuencia de utilización, sería posible simplificar el
sistema, eliminando los artefactos que no se utilicen. En el caso del ejemplo, se propone
eliminar los artefactos sombreados en la tabla. El resultado de la supresión de artefactos poco
utilizados es el diseño mostrado en la Ilustración 5-3.
Ilustración 5-3. Ejemplo simple de modelo de clases optimizado
El sistema ha sido simplificado aproximadamente en un 50% del tamaño original.
Como consecuencia de ello, las tareas de mantenimiento realizadas son menos, y cada una de
ellas es menos compleja de realizar. Como se verá más adelante, varios estudios establecen
una correlación significativa entre el tamaño y complejidad de los sistemas y el esfuerzo de
mantenimiento asociado. Sin duda, el sistema resultante es más sencillo de entender, y un
cambio afecta a menos artefactos, con lo son necesarios menos recursos.
Imaginemos que, una vez simplificado el sistema, éste falla porque un usuario intenta
ejecutar una funcionalidad “reducida” anteriormente, como por ejemplo la consulta de
conductores. La probabilidad de invocación de los métodos “consultarConductor” es baja, pero
existe. ¿Qué ocurre si un usuario intenta invocar dicha funcionalidad? Una simplificación
automatizada conlleva riesgos de este estilo. Por tanto, es necesario tomar medidas de
contingencia para cubrir estos casos.
Lo que se propone es habilitar un mecanismo de vuelta a tras o “rollback” de
manera que se tenga constancia de qué funcionalidades borradas son invocadas, posibilitando
que el sistema vuelva a restaurar esa parte que ha sido suprimida. La vuelta atrás es el
procedimiento que dota de la seguridad suficiente al mecanismo de Reducción de Software
para poder ser aplicado a proyectos reales, donde el coste de mantenimiento es importante,
Tesis Doctoral Daniel Cabrero Moreno
147
pero no se puede sacrificar la fiabilidad de los sistemas. En el ejemplo anterior, tras el proceso
de vuelta atrás, el diseño quedaría como se muestra a continuación.
Ilustración 5-4. Vuelta atrás en una simplificación de diseño
Lo que realmente está sucediendo a lo largo de las distintas simplificaciones y vueltas
atrás, es que se está ofreciendo una visión reducida del código a mantener al equipo de
desarrollo. Únicamente los artefactos que son utilizados frecuentemente son visibles de cara a
los mantenimientos, y el resto de código no usado se “guarda” en un repositorio aparte.
Se puede considerar que la RS provee al equipo de mantenimiento de una visión
“parcial” del sistema a mantener que, al ser más reducido que el original, reduce tanto el
tiempo necesario para analizar un sistema como para cambiarlo.
La Ilustración 5-5 muestra la generalización del mismo concepto sobre un diseño más
complejo. El objetivo de nuestra propuesta es localizar los artefactos que aportan poco valor, y
posponer o evitar su mantenimiento en la medida de lo posible, centrando el esfuerzo en
modificar los artefactos que son más importantes desde el punto de vista de los implicados.
Tesis Doctoral Daniel Cabrero Moreno
148
Ilustración 5-5. Artefactos no usados
En el ejemplo mostrado, los artefactos identificados como “no usados” también se
eliminarían de la visión del equipo de mantenimiento, con lo que el sistema resultante es más
fácilmente mantenible. En caso de que se produzca una invocación de uno de los artefactos
borrados, se ejecutará la vuelta atrás de manera automática.
5.3.4 Aspectos de Implementación de RS
La RS consiste en implementar la tarea de retirada de software mostrada en los últimos
pasos del ejemplo anterior. Corresponde a la aplicación de GVAL determina el valor de cada
artefacto de código (en el ejemplo se usa únicamente la frecuencia de utilización, pero es
posible combinar otros indicadores), y una vez se detecte qué código no aporta valor al sistema
en mantenimiento, se aplica RS para adaptar el tamaño del sistema, y el esfuerzo de
mantenimiento a los criterios de valor establecidos.
RS comienza con un proceso que hemos denominado “borrado lógico”, por el cual se
identifican los métodos del código a mantener que deben ser retirados del mantenimiento.
Estos artefactos son movidos del código fuente original a un repositorio paralelo. Una vez que
los métodos son movidos, puede haber atributos que antes eran necesarios en métodos que
han sido “borrados”, y ya no son necesarios. Por este motivo, un análisis de código estático es
realizado a posteriori para identificar atributos no usados, que también serán trasladados al
repositorio paralelo.
Tesis Doctoral Daniel Cabrero Moreno
149
Para configurar y almacenar el código retirado, proponemos utilizar un Sistema de
Gestión de la Configuración (SGC) de la siguiente manera; Una copia de la estructura de
paquetes es definido en un repositorio identificado como “Repositorio Rollback” o “RR”.
Dentro del mismo SGC, se crea también un repositorio que contiene el código a mantener,
llamado “Repositorio Original” o “RO”. RR contiene únicamente el código movido desde RO,
estructurado en paquetes y clases del mismo modo.
Por ejemplo, si una clase de un determinado paquete contiene los atributos at1 y at2, y
los métodos m1() y m2(), y se decide aplicar RS a at1 y m1(), ambos repositorios (RO y RR)
contendrán el paquete y la clase que los contiene, pero el código de la clase ubicado en RO
contendrá únicamente at2 y m2(), y la clase ubicada en RR contendrá el código
complementario movido desde RO, es decir, at1 y m1(). El reemplazo de los métodos y
atributos entre clases de ambos repositorios está basado en las refactorizaciones “move
attribute” y “move field” (Fowler, 1999). La Ilustración 5-6 muestra el concepto.
Ilustración 5-6. Proceso de Borrado Lógico
Si todos los miembros de una clase son movidos al RR, la clase que los contiene puede
también ser movida. Si todas las clases de un paquete son movidas, entonces el paquete
puede ser eliminado del RO. Nótese que el proceso de vuelta atrás de atributos, métodos,
clases y paquetes es siempre posible, porque toda la información suprimida del RO está
disponible en el RR. Este proceso se denomina “borrado lógico”, porque el código es borrado
del entorno de desarrollo, y almacenado en otra ubicación.
La razón de crear RO y RR en el mismo SGC es posibilitar que el código visible para el
equipo de mantenimiento, y el código suprimido pueda evolucionar bajo el mismo controlado
de versiones.
Tesis Doctoral Daniel Cabrero Moreno
150
Para habilitar el proceso de vuelta atrás, toda invocación de un método suprimido
debe ser sustituida en el RO por una escritura en log, que almacena una entrada en el log
cada vez que la lógica del programa precise invocar el artefacto borrado. Este log será utilizado
para identificar automáticamente los artefactos borrados que deben ser restaurados.
Un proceso batch analiza el fichero log, y para cada entrada (invocación de un método
borrado), recupera dicho artefacto de la RR y lo mueve de nuevo al RO. De este modo, el
proceso opuesto al borrado lógico es ejecutado, y el método vuelve a ser visible para el equipo
de mantenimiento.
Sin embargo, un problema de coherencia puede aparecer entre el código residente en el
RO y el RR que es necesario tratar con precaución. Si parte del código es suprimido de la vista
a mantener, y el código restante es modificado, es posible que si se realiza una vuelta atrás, el
código restaurado ya no se corresponda con el código original y la funcionalidad falle. El
problema es que no es sencillo automatizar una solución, porque depende de qué cambios se
hayan hecho, y solventar dicho problema requiere análisis manual. Este inconveniente puede
ser minimizado mediante la generación de un mensaje de alerta si se detecta que una versión
más antigua del código está siendo recuperada en una invocación de código más nueva. El
aviso apuntará el lugar donde una comprobación manual debe ser realizada.
Aunque la necesidad de análisis manual en este caso puede significar perder parte de los
beneficios de reducción de costes de mantenimiento que justifica la aplicación de RS, nótese
que la posibilidad de que esto ocurra es pequeña, porque el código borrado tiene una
probabilidad muy baja de volver a ser invocado. Más aún, la herramienta puede mostrar qué
código debe ser analizado, reduciendo el esfuerzo requerido. De hecho, ningún esfuerzo
adicional es requerido, porque si no se aplicas RS, el esfuerzo de análisis debe realizarse de
todos modos para estudiar el impacto del cambio de código propuesto.
El proceso es automatizable salvo en el caso particular mencionado más arriba. Esto
significa que en caso de fallo debido a RS, una nueva versión podría ser preparada y
desplegada en minutos en la mayoría de los casos.
Los procesos de borrado lógico y la vuelta atrás forman las operaciones fundamentales
del RS, porque gracias a ellas el software puede “contraerse” o “expandirse”
dependiendo de la actividad de los usuarios. El proceso permite reducir el tamaño y la
complejidad del software a mantener, proporcionando al mismo tiempo la seguridad necesaria
para aplicar RS a sistemas reales.
Tesis Doctoral Daniel Cabrero Moreno
151
5.4 Generalización del problema: Aplicando GVAL
Es importante que los conceptos teóricos sobre Mantenimiento Basado en Valor, que se
han ido introduciendo a lo largo de este Capítulo, estén soportados por una metodología que
permita su aplicación en proyectos reales.
En este sentido, del mismo modo que sucedía en DSBV, en el caso del MSBV se
propone aplicar GVAL, para lo que es necesario definir las tareas e indicadores necesarios. A
lo largo de los siguientes epígrafes se definirán dichos elementos.
5.4.1 Indicadores de Valor
Por las singulares características que posee el mantenimiento, se distingue entre dos
tipos de indicadores en la aplicación de GVAL; Indicadores objetivos y subjetivos. Ambos se
presentan a continuación.
5.4.1.1 Indicadores objetivos
El mantenimiento de software es una función llevada a cabo una vez que el software
está en producción. Esto introduce un componente de valor que no existía en el caso del
desarrollo software: Es posible tener en cuenta los datos estadísticos del uso y la modificación
del software, que hasta entonces, en las fases de desarrollo, no existían.
Se trata fundamentalmente de datos numéricos, cuya recogida suele estar basada en
herramientas automáticas, y que recogen tendencias del usuario que pueden ser útiles para
alinear las actividades de IS al valor esperado de los usuarios, pero no requieren
intervención directa por parte de los implicados. Otra característica fundamental que
poseen estos datos es su objetividad. Los indicadores subjetivos, como la importancia relativa o
la urgencia, están basados en las visiones personales de los implicados. Probablemente, el
resultado del análisis de indicadores subjetivos sea diferente según el implicado elegido,
aunque el objetivo de las técnicas de grupo como AHP sea precisamente minimizar estas
desviaciones. En el caso de los datos estadísticos, no existe este problema.
Se introduce en esta sección un grupo de indicadores basados en los datos recogidos
automáticamente, que recibe el nombre de “indicadores objetivos”, según la definición
proporcionada en el punto 3.3.1. Dichos indicadores fueron ya incluidos en el árbol general de
indicadores de la página 81, durante la presentación del método GVAL, aunque no han sido
utilizados por ninguna técnica planteada en este documento hasta la introducción del MSBV en
el presente Capítulo. A continuación se muestra la rama del árbol de indicadores que agrupa
los indicadores objetivos.
Tesis Doctoral Daniel Cabrero Moreno
152
Ilustración 5-7. Sub-Árbol de Indicadores Objetivos
Como puede observarse por los círculos rojos que señalan los indicadores no utilizados
hasta la fecha en ninguna propuesta, por el momento se ha definido un total de cinco
indicadores, de los que únicamente el escalado de incidencias ha sido encontrado en la revisión
de la literatura basada en valor (Ling et al., 2005) presentada en el 0. Los indicadores se
presentan agrupados según el tipo de artefacto al que asigna valor relativo: requisitos o
artefactos de diseño y código.
Los indicadores de número de incidencias y escalado de incidencias aplican a nivel de
requisito, y tienen por objeto examinar el número de incidentes registrados en el pasado, y la
gravedad de escalado que estos tuvieron. Dichos indicadores podrían usarse por ejemplo a
nivel de priorización de actuaciones de mantenimiento (ver punto 5.2.1).
Para su utilización, es necesario disponer de algún tipo de repositorio de incidencias que
proporcionen el histórico de cambios requeridos, y los requisitos a los que afectan. Si dicho
repositorio almacenase además la información de los artefactos de diseño o código modificados
como producto de ese mantenimiento, los indicadores podrían ser también aplicados a dicho
tipo de artefacto.
Por otro lado, los indicadores que aplican a nivel de artefacto de diseño y código son:
probabilidad de cambio, propensión al fallo, y frecuencia de uso. Diversos autores han
realizado estudios y comparativas de aplicación de distintas técnicas que tienen por objeto su
estimación, así como su aplicación a otros campos de la IS. En el ANEXO I a este documento
se examina de forma detallada el estado del arte en técnicas de predicción de cada uno de
estos tres indicadores.
Tesis Doctoral Daniel Cabrero Moreno
153
La frecuencia de uso es la característica fundamental en la que se basa la
“Reducción de Software”, presentada en el punto 5.3.3 como propuesta para la
optimización de esfuerzos para cada actuación de mantenimiento. También es el
indicador principal sobre que se basa el ejemplo presentado en dicho punto. La
frecuencia de uso extraída de manera automatizada es un indicador de valor mucho
más fiable que la opinión de las frecuencias de uso estimadas por los implicados y
usuarios, al tratarse de datos reales.
La frecuencia de uso puede ser utilizada para guiar el valor de varias prácticas.
Además de para ejecutar la reducción de software, es útil por ejemplo en la
priorización de esfuerzos de refactorización.
La probabilidad de cambio está directamente relacionada con el valor de
anticipación y flexibilidad ante cambios de los diseños que, según Boehm, es la
aportación principal que los diseños pueden hacer al valor global del software. La
propensión al cambio puede ser estimada utilizando varias técnicas, pero según las
comparativas realizadas (Tsantalis et al., 2005), las más fiables son aquellas basadas
en históricos, ya sea total o parcialmente. El indicador de probabilidad de cambio
puede ser útil para guiar mantenimientos perfectivos (refactorizaciones) o
mantenimientos preventivos.
La propensión al fallo es un aspecto recurrente en la literatura relacionada con la
calidad del software, donde muchas han sido las propuestas presentadas. Se trata
de un factor que indudablemente puede colaborar en el establecimiento del valor a
la hora de realizar mantenimientos perfectivos, preventivos, o incluso correctivos.
Por ejemplo, un mantenimiento correctivo sobre una serie de artefactos propensos al
fallo debería realizarse con mayor prioridad que el resto de mantenimientos, ya que
la probabilidad de que el fallo sea recurrente es alta.
La realización de mantenimientos preventivos sobre artefactos propensos al fallo es
otra posible aplicación de este indicador, ya que se invierte en recortar costes en
futuros mantenimientos.
5.4.1.1.1 Ventajas e inconvenientes de la utilización de indicadores objetivos
Dado que GVAL establece el método de combinación de distintos indicadores, cualquier
extensión futura del árbol de indicadores objetivos podría usarse o por separado, o en
combinación con los indicadores subjetivos, para la asignación de valor a cualesquiera tareas
priorizables identificadas en la página 83 o propuestas en un futuro. Por tanto, cualquier
técnica de extracción de datos automatizados de cualquier aspecto del desarrollo software
puede ser incluido como una extensión del árbol de indicadores objetivos, y utilizado en
combinación con los anteriores.
Tesis Doctoral Daniel Cabrero Moreno
154
La utilización de indicadores objetivos tiene dos ventajas principales. Por un lado, la
priorización se realiza en función de datos objetivos, por otro lado, no es necesaria la
intervención directa de los implicados.
Como se ha comentado anteriormente, la objetivación de los indicadores evita las
posibles distorsiones que la subjetividad de los implicados puede introducir en su estimación.
Un aspecto importante a tener en cuenta, es que GVAL permite combinar indicadores
objetivos y subjetivos con cualquier tarea priorizable. La función de los indicadores objetivos
es en ese caso sería la objetivación de los indicadores subjetivos, en la medida en que la
asignación de pesos asigne más o menos peso a un tipo de indicador o a otro.
En las aplicaciones legadas, no siempre es posible la interlocución directa con impulsores
del proyecto (quien normalmente financia el desarrollo), representantes de los usuarios, o
equipo original de desarrollo. Por lo tanto, la información de valor únicamente puede ser
extraída de manera indirecta a partir del sistema en funcionamiento (a partir de indicadores
objetivos). Otras veces los implicados sí están accesibles, pero al no existir documentación
actualizada de ningún tipo, el software es una caja negra en la que se desconoce la
composición y aportación al total de cada una de sus partes.
Como principal inconveniente de la utilización de indicadores objetivos, cabe señalar que
la semántica de los datos estadísticos suele ser más pobre que en el caso de los subjetivos, al
limitarse a frecuencias de uso, cambios realizados y datos similares. En ocasiones, no es
posible dilucidar el tipo de importancia (urgencia, importancia, valor social…) que dichos
indicadores tienen. Por ese motivo, es recomendable su combinación con indicadores
subjetivos, siempre que sea posible.
Otro inconveniente es la escasa disponibilidad de herramientas y datos históricos.
Aunque siempre es posible implantar herramientas de código abierto que monitoricen a partir
de un determinado momento los sistemas a mantener, sólo se dispondrán de datos desde
entonces, ya que su utilización no es habitual en sistemas legados.
5.4.1.1.2 Indicadores objetivos versus orientación no basada en valor
Es conveniente diferenciar entre utilización de indicadores objetivos y la IS tradicional
(sin orientación basada en valor). En ocasiones pueden confundirse, al no ser necesaria la
intervención directa de los implicados para la obtención de los indicadores objetivos.
Los indicadores objetivos tienen por objeto guiar la aplicación de las prácticas de IS,
dependiendo de los datos de valor recogidos indirectamente de los usuarios. La única
diferencia con los indicadores subjetivos es que se obtienen a partir de datos estadísticos
extraídos indirectamente del comportamiento de los implicados, en lugar de mediante
elicitación directa. Sin embargo, en consonancia con la aplicación de valor, la aplicación de las
prácticas de IS variará con la situación concreta de la organización y sus implicados.
Tesis Doctoral Daniel Cabrero Moreno
155
En el caso de la aplicación neutra de técnicas de IS (la utilizada comúnmente), las
técnicas a aplicar son las mismas independientemente del uso que se haya hecho de los
sistemas, o de los datos históricos de propensión al cambio.
A modo de ejemplo, imagínese un aplicativo software en fase de mantenimiento
perfectivo. Una aproximación basada indicadores objetivos buscaría por ejemplo realizar o no
refactorizaciones en función de la probabilidad de cambio y la frecuencia de uso, es decir,
implementará unas técnicas (por ejemplo, patrones) de IS u otras dependiendo del contexto
concreto. El resultado (el software) será diferente en dos organizaciones distintas, ya que el
producto dependerá del contexto en que los implicados hagan uso de ella y hayan solicitado
cambios en la misma. En una orientación tradicional, el resultado no depende del contexto,
sino que las técnicas se aplican del mismo modo en todos los casos.
5.4.1.2 Indicadores subjetivos
Todos los indicadores de valor subjetivos consisten en extraer de los distintos
implicados las nociones de valor que deben regir las actuaciones de mantenimiento. Sin
embargo, existen varios tipos de mantenimientos, para los que distintos conjuntos de
indicadores pueden ser válidos.
Podemos destacar dos indicadores especialmente importantes en el caso del
mantenimiento correctivo: la urgencia y la importancia. Dado que el mantenimiento
correctivo se encarga de corregir los defectos del sistema, el principal valor que aportan es
medido en términos de la importancia que las actuaciones tienen, y la urgencia o plazos que
los implicados manejan para que el defecto no erosione el valor del producto en el mercado.
En el caso de los mantenimientos perfectivos, es decir, aquellos que se centran en
mejorar internamente el sistema para facilitar actuaciones futuras, la urgencia no suele tener
tanta relevancia, siendo más importante la probabilidad de cambio.
En el caso de los mantenimientos adaptativos (evolucionan la funcionalidad actual
de los sistemas), los indicadores aplicables son exactamente los mismas que para cualquier
requisito de desarrollo nuevo. La diferencia con los desarrollos nuevos, es que todos los
indicadores subjetivos pueden ser utilizados además en combinación con los indicadores
objetivos.
Por tanto, es posible aplicar un grupo diferente de indicadores dependiendo del tipo de
mantenimiento a realizar. Para la adaptación del árbol de indicadores al caso concreto, es
fundamental el hecho de que GVAL contemple, en la fase de definición de indicadores y tareas
priorizables, una tarea de personalización de indicadores y tareas que deberá ser aplicada a
cada caso concreto.
Tesis Doctoral Daniel Cabrero Moreno
156
5.4.2 Tareas priorizables
A nivel de mantenimiento se identifican distintos tipos de tareas priorizables, aplicables
en el marco de GVAL, relacionadas con los epígrafes anteriores:
Aplicación de la Reducción de Software, considerada también como una tarea
priorizable, y presentada en detalle en el punto 5.3. Sobre la RS, es importante señalar
que se trata de una tarea únicamente aplicable al “mantenimiento perfectivo”, es decir,
tareas de mantenimiento que reducen en un futuro el coste de otros mantenimientos.
Aplicación de refactorizaciones guiadas por valor, se trata de realizar mejoras de
mantenimiento allá donde los indicadores de valor (principalmente los objetivos)
apunten mejoras susceptibles. Se propone básicamente aplicar las reglas de diseño
presentadas para el DSBV en el 0, pero aplicada al código legado, de forma que se
refactoricen las partes más importantes, que más cambian, o que se utilizan con más
frecuencia. Este concepto puede ser aplicado, no sólo a las reglas de diseño, sino
también a las reglas de codificación presentadas en el ANEXO I. Se trata en ambos
casos de tareas de “mantenimiento perfectivo”.
El valor de los artefactos legados de código, puede sugerir también la ejecución de
tareas priorizables que se encarguen de crear artefactos de documentación, pruebas,
trazabilidades, o cualquier otro definido en el árbol de tareas priorizables de desarrollo.
Por ejemplo, aunque no existiese anteriormente, para un subsistema legado
especialmente importante, podría aplicarse la tarea priorizable de crear un juego de
pruebas que antes no existía.
Priorización de las actuaciones de mantenimiento. La implementación de
actuaciones de mantenimiento es un caso particular de la tarea priorizable
“implementación de requisito” ya planteada anteriormente, aplicada a las distintas
actuaciones de mantenimiento, dependiendo del valor.
Se trata de realizar correcciones de errores o mejoras allá donde los indicadores de
valor (principalmente los subjetivos) apunten mejoras susceptibles. En este caso, se
priorizan tareas de “mantenimiento correctivo y adaptativo”.
Adicionalmente, es posible aplicar muchas de las tareas priorizables que se definían
para la gestión de proyectos en el desarrollo de software, puesto que el mantenimiento de
software es de por sí un proyecto.
Las tareas de control de planificación son también priorizables, dado que las tareas de
mantenimiento deben realizarse con arreglo a una planificación, los recursos de control pueden
distribuirse con arreglo a las condiciones de valor. También son aplicables las tareas de gestión
Tesis Doctoral Daniel Cabrero Moreno
157
de riesgos, pues en los casos más críticos será conveniente administrar los riesgos que las
distintas actuaciones puedan acarrear.
Normalmente no se dispondrá de las especificaciones de requisitos y diseño, pero de
ser así, la actualización de la documentación es también una tarea priorizable, que puede
plantearse como diferible o no dependiendo de los indicadores de valor. Si no existiese, es
posible también plantear la creación de la misma como tarea priorizable.
En todo caso, el mantenimiento se realizará finalmente sobre el código, por lo que la
totalidad de las tareas relacionadas con el código, tales como la documentación del código, el
cumplimiento de reglas de código o la integración continua, también son aplicables.
Las tareas de pruebas posteriores a las distintas actuaciones de mantenimiento
también deben ser consideradas tareas priorizables, ya que están destinadas a asegurar que
los cambios realizados han tenido el resultado esperado.
En definitiva, en general todas las tareas priorizables definidas para desarrollo
pueden ser aplicables a los mantenimientos. Por supuesto, la aplicación a cada tipo de
artefacto dependerá de la existencia previa de requisitos, juegos de prueba, y demás
artefactos. Se añade, también alguna tarea priorizable específica de mantenimiento,
relacionada con el mantenimiento perfectivo, como puede ser la Reducción de Software, y la
refactorización sobre sistemas existentes.
El árbol de tareas priorizables puede ser consultado en detalle en la página 83.
Tesis Doctoral Daniel Cabrero Moreno
158
5.5 Ejemplos de aplicación de MSBV
Según los tipos de mantenimientos y tareas priorizables expuestos anteriormente, se
distinguen dos tipos de aplicaciones de mantenimiento. Por un lado están aquellas actuaciones
preventivas, a los que aplican las tareas priorizables de Reducción de Software y la creación de
entregables no existentes. Por otro lado están las actuaciones correctivas y adaptativas, a las
que aplican todas las tareas priorizables definidas en desarrollo.
Para ilustrar ambos tipos de mantenimiento, se mostrarán dos ejemplos: Uno de
mantenimiento correctivo (punto 5.5.1), y otro de mantenimiento preventivo o de mejora
(punto 5.5.2).
5.5.1 Ejemplo de mantenimiento correctivo
En el ámbito de este ejemplo, se definirán tres tareas a realizar en el marco del
mantenimiento correctivo de defectos en el software.
Implementar Petición. La realización de esta tarea define la atención a la
corrección del defecto. Es de obligada aplicación para realizar las otras tareas, y
hay dos posibilidades, realizarla o no.
Gestionar Riesgo, consistente en identificar los riesgos asociados al cambio y
monitorizarlos. Hay dos niveles de aplicación también en esta tarea: realizarla o
no.
Realización de pruebas de regresión, con objeto de asegurar el
funcionamiento después del cambio. Definimos tres niveles: no realización,
prueba del requisito, prueba de los requisitos relacionados.
Para estas tres tareas priorizables, se definen 3 indicadores a nivel de requisito
(importancia relativa, urgencia e importancia de un fallo potencial). La importancia
relativa de las tareas con respecto a los indicadores es calculada según el método presentado
en el Capítulo 3, y como resultado de la misma, se presenta el siguiente ejemplo de
distribución de pesos de indicadores.
Tesis Doctoral Daniel Cabrero Moreno
159
Ilustración 5-8. Pesos de indicadores para la ejecución de peticiones de mantenimiento
Con este paso, finaliza la parte genérica de establecimiento de indicadores y pesos
relativos por tipo de proyecto.
Supongamos que el sistema tiene 4 peticiones de mantenimiento. Como resultado de la
elicitación de indicadores por medio de AHP de los distintos implicados, obtenemos indicadores
subjetivos de valor mostrados a continuación.
Ilustración 5-9. Evaluación de indicadores por petición de mantenimiento
Los pasos a realizar son los mismos que en el caso del ejemplo presentado en el
Capítulo 3, es decir, los definidos por GVAL. El resultado será a la postre que, dependiendo de
los recursos a invertir, se implementarán una serie de tareas de mantenimiento, que
además serán probados y gestionados en cuanto a riesgo siguiendo las indicaciones de valor
proporcionadas.
0%
20%
40%
60%
80%
100%
T1 :Implementar Petición
T2 :Gestionar Riesgo
T3 : Realizar Pruebas
Pesos de Indicadores
PI1 :Importancia Relativa PI2 :Urgencia
PI3: Importancia fallo
0% 20% 40% 60% 80% 100%
I1 :Importancia Relativa
I2 :Urgencia
I3: Importancia fallo
Petición 1
Petición 2
Petición 3
Petición 4
Tesis Doctoral Daniel Cabrero Moreno
160
El resto de valores de las tres tareas para todos los requisitos, obtenidos utilizando el
mismo método, se muestran en la Tabla 5-2.
P1 P2 P3 P4
T1: Implementación Petición. 64,78 16,18 26,88 69,73
T2 :Gestionar Riesgo 33,75 10,59 21,19 90,08
T3 :Realizar Pruebas 71,01 14,01 28,02 72,22
Tabla 5-2. Valor obtenido por petición de mantenimiento y tarea
A primera vista ya se intuye que las peticiones de mantenimiento a implementar serán
P1 y P4, en el caso de P4 además se recomienda hacer una gestión de riesgos, y en ambos
casos parece importante realizar pruebas de regresión. Se ha reducido el coste en
implementación de peticiones en un 50%, el coste de de gestión de riesgos en un 75%, y el
coste de realización de pruebas en un 50%.
En el caso de tener un número superior de tareas a realizar que dificulte la evaluación
manual, se deberá aplicar la asignación por escenarios establecida en el método general (ver
sección 3.4.3.2), previa estimación del coste estimado de implementación de peticiones de
mantenimiento.
5.5.2 Ejemplo de mantenimiento perfectivo
Probablemente, el caso más común de mantenimiento de software es aquel en el que no
existe documentación de ningún tipo. Es habitual realizar actuaciones de mantenimiento sobre
software que lleva varios años dando servicio, y que es fundamental para los distintos
implicados.
Lo normal, es realizar tareas de mantenimiento que cada vez son más costosas, hasta un
punto en que se plantea la reingeniería del sistema. Sin embargo un correcto mantenimiento
perfectivo puede ayudar a retrasar o evitar ese momento, y por tanto a optimizar la relación
valor-coste que el sistema proporciona a los implicados.
En el caso del ejemplo que nos ocupa, supondremos que no existe documentación
en el sistema a mantener, por lo que no es posible trazar indicadores subjetivos hasta los
artefactos de diseño o código. Los indicadores a utilizar serán los objetivos, que sí aplican a
nivel de artefacto de código (que son los únicos artefactos existentes). Se plantea por tanto la
aplicación de un mantenimiento basado en valor en el ámbito de GVAL según los siguientes
términos.
Se definirán cuatro tareas a realizar en el marco del mantenimiento de defectos en el
software.
Tesis Doctoral Daniel Cabrero Moreno
161
Reducción de Software, según la técnica presentada en el punto 5.3 de este
Capítulo.
Creación de especificación de requisitos, para un subconjunto del sistema.
Hay dos niveles de aplicación también en esta tarea: realizarla o no. La
realización de esta tarea condiciona la realización de las dos siguientes.
Creación de trazabilidad de requisitos a código. Hay dos niveles de
aplicación también en esta tarea: realizarla o no.
Creación de juego de pruebas de unitarias para un conjunto de clases,
con objeto de asegurar el funcionamiento después de los cambios. Definimos
tres niveles de cobertura: no realización, prueba la clase implicada, prueba
además de las clases que usan la clase implicada.
Para estas tareas priorizables, se definen 2 indicadores a nivel de artefacto de código:
Frecuencia de Uso
Probabilidad de cambio.
La frecuencia de uso es el factor principal en la aplicación de Reducción de Software, ya
que la idea es eliminar los artefactos no utilizados. Sin embargo, la probabilidad de cambio
tiene más peso en las tareas de creación de artefactos adicionales al código, ya que éstos
aportarán su valor cuando se requiera hacer un cambio. Se elicita la siguiente distribución de
pesos de indicadores:
Ilustración 5-10. Pesos de indicadores para mantenimiento perfectivo
0%
20%
40%
60%
80%
100%
T1: RS T2 : Requisitos
T3: Trazabilidad
T4: Pruebas
Pesos de Indicadores
PI1 :Frec. de Uso PI2 :Prob. de Cambio
Tesis Doctoral Daniel Cabrero Moreno
162
Supongamos que el sistema tiene 10 clases. Como resultado de la extracción
automatizada de los datos, obtenemos indicadores objetivos de valor mostrados a
continuación.
Ilustración 5-11. Evaluación de indicadores por mantenimiento perfectivo
La relación entre indicadores y tareas arrojan el valor relativo de cada tarea que se
muestra en la Tabla 5-3.
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10
T1 :RS 1,5 36,9 0,0 100,0 6,2 81,5 0,0 66,2 52,3 0,0
T2 :Requisitos 1,9 50,1 30,0 46,7 46,5 35,9 58,0 86,5 51,6 1,3
T3 :Trazabilidad 1,9 50,1 30,0 46,7 46,5 35,9 58,0 86,5 51,6 1,3
T4 :Pruebas 2,2 58,9 50,0 11,1 73,3 5,6 96,7 100,0 51,1 2,2
Tabla 5-3. Valor obtenido por mantenimiento perfectivo y tarea
RS se aplicará sobre todos los artefactos utilizados con una frecuencia muy baja o no
utilizados: {C1, C3, C7 y C10}, dichos artefactos corresponden a las columnas sombreadas en
la Tabla 5-3. Para las demás tareas priorizables, establecemos los escenarios que definirán el
coste. La Ilustración 5-12 muestra cómo varían los límites de aplicación de los distintos tipos de
tareas priorizables.
0% 20% 40% 60% 80% 100%
I1 :Frec. Uso
I2 :Prob. Cambio
Clase 1
Clase 2
Clase 3
Clase 4
Clase 5
Clase 6
Clase 7
Clase 8
Clase 9
Clase 10
Tesis Doctoral Daniel Cabrero Moreno
163
Ilustración 5-12. Adaptación de los límites de valor para el mantenimiento perfectivo
Se establece para la T2 y T3 un esfuerzo relativo del 25%, y para la tarea de pruebas
(T4), el esfuerzo varía entre 0% (no se prueba), 25% (se prueba la clase implicada) o 50% (se
prueban también las clases que usan la clase implicada). Suponemos por simplicidad, que la
realización de las tareas supone el mismo esfuerzo para cada tarea T2 y T3 de 100 euros, para
cada tarea T4 varía entre 0 euros, 100 euros, o 200 euros, dependiendo del tipo de prueba
realizada. De este modo, se plantean los siguientes escenarios, que varían según los recursos
disponibles.
Clases trazadas y
Requisitos creados
Pruebas unitarias Coste
La clase Clases
relacionadas
Escenario 1 2,8,9 2,9 5,8 900 euros
Escenario 2 2,4,5,8,9 9 2,5,8 1200 euros
Escenario 3 2,4,5,8,9 2,5,8,9 1300 euros
Escenarios 4 a 7 2,4,5,6,8,9 2,5,8,9 1400 euros
Escenarios 8 a 10 2,4,5,6,8,9 4 2,5,8,9 1500 euros
TOTAL de TAREAS 2,4,5,6,8,9 2,4,5,6,8,9 1800 euros
Tabla 5-4. Valor y coste obtenido en mantenimiento perfectivo
El método nos permite controlar que la cantidad de dinero a invertir en las mejoras de
mantenimiento, y que el esfuerzo llegue a las zonas del aplicativo a perfeccionar que más
valor aporten en un futuro.
La Ilustración 4-16 muestra la variación de coste con arreglo a los escenarios.
020406080
100120
Esce
nar
io 1
Esce
nar
io 2
Esce
nar
io 3
Esce
nar
io 4
Esce
nar
io 5
Esce
nar
io 6
Esce
nar
io 7
Esce
nar
io 8
Esce
nar
io 9
Esce
nar
io 1
0
T2 y T3:Req. y traz.
No se implementa Se implementa
020406080
100120
Esce
nar
io 1
Esce
nar
io 2
Esce
nar
io 3
Esce
nar
io 4
Esce
nar
io 5
Esce
nar
io 6
Esce
nar
io 7
Esce
nar
io 8
Esce
nar
io 9
Esce
nar
io …
T4: Pruebas
No se prueba
Prueba clase implicada
Prueba clases que usan la clase implicada
Tesis Doctoral Daniel Cabrero Moreno
164
Ilustración 5-13. Evolución del coste con las variaciones de límite en mantenimiento perfectivo
Los valores proporcionados por los escenarios definidos por los límites varían de 900 a
1800 euros. A la reducción del sistema en un 40% del tamaño, hay que añadir la priorización
de costes de la aproximación basada en valor sobre la ejecución de todas las tareas sobre el
sistema entero. El ahorro en mantenimiento para las tareas de trazado, creación de requisitos y
pruebas varía del 17% hasta el 50%. En este caso, el presupuesto disponible hace que el
escenario elegido sea el 2, con un ahorro del 33% de coste, que se distribuye de forma que se
respeten las directrices de valor establecidas.
0,00 €
200,00 €
400,00 €
600,00 €
800,00 €
1.000,00 €
1.200,00 €
1.400,00 €
1.600,00 €
1.800,00 €
2.000,00 €
0 2 4 6 8 10 12
Co
ste
Escenarios
Escenario
Elegido
Tesis Doctoral Daniel Cabrero Moreno
165
5.6 Aportaciones Realizadas en Este Capítulo
A pesar de que en la literatura se hace énfasis frecuentemente de que el mantenimiento
de software consume la mayor parte de los recursos del ciclo de vida, hasta ahora no se habían
estudiado los aspectos de mantenimiento desde una perspectiva basada en valor. En este
Capítulo se introduce el concepto de valor en mantenimiento. Los conceptos de valor
aplican al mantenimiento en base a indicadores de valor y tareas priorizables, del mismo modo
que al resto de las áreas de la ISBV.
En esa línea, se han definido un conjunto de tareas priorizables de mantenimiento,
únicamente aplicables a las fases de mantenimiento, al no tener sentido si un desarrollo no
está ya implantado. Se ha introducido además la utilización de indicadores de valor
objetivos. Este tipo de indicadores se basa en los datos recogidos durante la vida útil del
software, de forma que no es necesaria la colaboración de los implicados. Dado que se basa en
estadísticas históricas, únicamente es aplicable a la fase de mantenimiento, donde ha sido
posible monitorizar y recoger dichos datos.
El MSBV no era un área de conocimiento propuesta por Boehm para ISBV, pero sí es un
área de conocimiento de IS identificada en el proyecto SWEBOK (ver sección 1.3, página 20).
En este Capítulo, se ha definido una nueva área de la ISBV llamada Mantenimiento
Software Basado en Valor (MSBV), y se ha puesto énfasis en definir el valor de manera
distinta dependiendo del tipo de mantenimiento:
En el caso del mantenimiento correctivo y adaptativo, se propone una priorización
de tareas de mantenimiento con arreglo a los indicadores de valor. Del mismo
modo que sucedía con los requisitos, las tareas de mantenimiento son evaluadas y
priorizadas con arreglo a las visiones de los distintos implicados.
En el caso del mantenimiento perfectivo, se pueden aplicar las tareas de
corrección de violaciones de reglas de diseño introducidas en el DSBV para
maximizar el valor del software, así como crear artefactos de distintos tipos que
ayude al mantenimiento allá donde los indicadores indiquen que es necesario.
Otra aportación importante en el ámbito del mantenimiento perfectivo es la introducción
del concepto de Reducción de Software (RS), como una forma de mejorar el valor de las
tareas de mantenimiento mediante la reducción de los costes de mantenimiento. Más
concretamente, RS reduce el tamaño y complejidad del código mediante un mecanismo de
“borrado lógico”, que retira de las tareas de mantenimiento aquellos artefactos que los
indicadores de valor objetivos (principalmente, la frecuencia de uso) indican.
Todos estos conceptos son ordenados y clasificados utilizando los conceptos
proporcionados por GVAL: tareas priorizables, indicadores de valor, y límites de valor. Asimismo
son aplicados a ejemplos automatizables, que muestran la viabilidad de aplicación, ya por
separado o de manera combinada, de los conceptos introducidos.
Tesis Doctoral Daniel Cabrero Moreno
166
Tesis Doctoral Daniel Cabrero Moreno
167
Capítulo 6 –
Automatización
6.1 Introducción
El objetivo último de la automatización es facilitar la aplicación de las técnicas
propuestas en esta Tesis Doctoral, pero también guiar los pasos a llevar a cabo para evitar
errores. En definitiva, la automatización pretende que los conceptos de GVAL, DSBV y MSBV
sean aplicables a proyectos reales, para lo cual es imprescindible que el proceso sea rápido,
sencillo y guiado.
El presente capítulo presenta un conjunto de automatizaciones que permiten hacer
viable la aplicación en un entorno real, en este caso el entorno de la DGT, los conceptos de
valor presentados en esta Tesis Doctoral. En el capítulo de validaciones (Capítulo 7) se analiza
la utilización de las automatizaciones y herramientas presentadas en esta sección.
Las automatizaciones realizadas en el ámbito de esta Tesis Doctoral son variadas, dado
que se han ido realizando en función de las necesidades concretas que la aplicación de los
principios de valor demandaba en la DGT. Contemplan tanto la automatización del método
GVAL, tanto como la recolección de distintos datos en los que se apoya la ejecución del
método, como detección de infracciones o extracción y almacenamiento automatizado de
indicadores que puedan guiar el valor de los desarrollos.
Tesis Doctoral Daniel Cabrero Moreno
168
6.2 GVAL-EX: Primeros pasos en GVAL con Excel
A lo largo de este trabajo, se han realizado varios ejemplos de aplicación de GVAL (ver
páginas 93, 126, 158 y 160). A continuación se muestra gráficamente el proceso en la
Ilustración 6-1, dividido en los distintos pasos definidos para GVAL en el Capítulo 3.
Ilustración 6-1. Pasos a automatizar en GVAL
Paso 4. Ajustar recursos y valores Paso 3. Evaluación de
indicadores y asignación Tareas
Paso 2. Asignación de indicadores a tareas Paso 1. Elicitación de
indicadores y tareas
b) Pesos Indicadores c) Pesos Tareas
a) Relación Indicadores-Tareas
a) Estimar peso por artefacto
b) Asignar pesos a tareas en
función de los pesos
b) Crear escenarios variando los
límites de valor
a) Evaluar coste/valor
Tarea
Tarea
Tarea
Indicador Indicador
Indicador Indicador
Tarea
Tarea
Tesis Doctoral Daniel Cabrero Moreno
169
Los pasos a realizar en toda aplicación de GVAL son: elección de un conjunto de
identificadores y tareas priorizables (paso 1), asignación y normalización de pesos a los
identificadores, asignación y normalización de pesos a las tareas priorizables por indicador
(paso 2), asignación de valor a los indicadores y cálculo del valor de las tareas en función de lo
definido anteriormente (paso 3), creación de límites de valor, cálculo de escenarios y costes, y
finalmente, elección de un escenario a implementar (paso 4).
La aplicación de GVAL conlleva la constante normalización de pesos, aplicación de pesos
a valores, y tareas de cálculo similares. Para la aplicación de GVAL a todos los ejemplos
mostrados en este trabajo se ha utilizado un conjunto de hojas Excel, denominado
“GVAL-EX” (GVAL para EXcel) que ordena los pasos, realiza los cálculos, y genera los
gráficos utilizados para tomar decisiones. Esta primera aproximación de automatización es
aplicable a cualquier caso que el método GVAL contemple, y puede ser aplicado directamente
en casos de estudio y proyectos reales.
GVAL-Ex se compone de una serie de hojas Excel, que soportan las distintas partes del
proceso. El primer paso, la elección de indicadores y tareas priorizables, se ha implementado a
través de dos hojas. La primera hoja contiene todas las tareas, su peso relativo (normalizado
para que sumen 100), el tipo de tarea y el tipo de sub-tarea definidos en el árbol de tareas
priorizables. El aplicativo muestra además gráficamente el valor relativo de cada tarea (paso
2b).
Ilustración 6-2. Elección de tareas priorizables con GVAL-Ex
El mismo proceso es llevado a cabo para el árbol de indicadores en la segunda hoja
Excel. En este caso, lo que se cuantifica mediante pesos relativos es la importancia desde el
punto de vista del valor de cada indicador, que será utilizado posteriormente.
Tesis Doctoral Daniel Cabrero Moreno
170
Ilustración 6-3. Elección de indicadores con GVAL-Ex
Los indicadores y tareas priorizables definidos en las dos primeras hojas son entonces
relacionados en la siguiente hoja. Las relaciones indicador-tarea, son ponderados utilizando los
pesos relativos de cada indicador definidos en la hoja anterior, y se genera la gráfica mostrada
en la Ilustración 6-4. Si por ejemplo una tarea priorizable está relacionada con dos indicadores
que se definieron en la segunda hoja con pesos 0,1 y 0,2, el peso de cada uno de ellos será
proporcional al definido en el árbol de indicadores (una vez normalizados), influyendo los
indicadores en un 33% y un 66% respectivamente sobre la tarea que priorizan.
La hoja que relaciona indicadores y tareas importa los pesos definidos en la hoja de
indicadores, y genera el gráfico de indicadores por tarea, mostrado en cada uno de los
ejemplos descritos a lo largo de este trabajo.
Ilustración 6-4. Relación indicador-tarea con GVAL-Ex
Tesis Doctoral Daniel Cabrero Moreno
171
Según lo comentado anteriormente, se normalizan los valores de importancia relativa
para que el peso de los indicadores que están relacionados con cada tarea sume 1. De este
modo, se obtiene automáticamente el peso de cada indicador en las tareas priorizables, en
base al peso que cada indicador tiene por sí mismo. En este punto termina la fase de
adaptación de GVAL al tipo de proyecto concreto.
Ilustración 6-5. Relación indicador-tarea normalizado con GVAL-Ex
El paso tres es implementado en otra hoja, donde se introduce el valor de cada
indicador desde el punto de vista de los distintos implicados, utilizando cualquier
técnica de elicitación (AHP, Planning Game, o cualquier otra). La hoja genera una gráfica, que
se presenta a continuación, y que puede servir para descartar de manera visual algunos
artefactos.
Ilustración 6-6. Asignación de Valor a los artefactos con GVAL-Ex
Gracias a la representación gráfica, otra opción plausible es continuar con la aplicación
de valor únicamente para algunos casos concretos (aquellos mejor valorados), como se
mostraba en el ejemplo mostrado en el punto 4.4.2 de la página 126. En cualquier caso, dichos
valores son automáticamente normalizados en la siguiente hoja, tal y como se muestra a
continuación.
Tesis Doctoral Daniel Cabrero Moreno
172
Ilustración 6-7. Valor normalizado de los artefactos con GVAL-Ex
El cálculo del valor relativo de cada par tarea-artefacto es realizado sumando el
resultado del producto de cada peso relativo de los indicadores con el valor del indicador de
cada artefacto (paso 3b).
Ilustración 6-8. Valor de cada tarea con GVAL-Ex
El valor de cada tarea es representado también gráficamente por la hoja Excel, de
manera que en la mayoría de los casos, es posible descartar directamente la realización de
tareas sobre algunos artefactos. En el ejemplo, el control de la planificación no es prioritario en
los artefactos 1, 3, 4 y 6 (el coste de dicha tarea se reduciría a la mitad sin necesidad de
realizar más cálculos). La definición de recursos en las tareas 3, 6 y 8 tampoco aporta mucho
valor, y así sucesivamente.
En cualquier caso, si se desea llevar a cabo una aproximación más metodológica, puede
llevarse a cabo una evaluación coste-esfuerzo a través de escenarios (paso 4a), tal
como se mostraba en la página 102. En el caso en que desee utilizarse esta opción, para
facilitar dicha tarea, la siguiente hoja define los distintos escenarios para la realización de cada
tarea.
Tesis Doctoral Daniel Cabrero Moreno
173
La Ilustración 6-9 muestra distintos escenarios de aplicación, que han sido divididos en
lo que hemos llamado “tramos”. Si existe una tarea que tiene 2 modos de aplicarse (p.ej. no
aplicarse o aplicarse), entonces se definen los límites de aplicación en función de 2 tramos. Si
el valor asignado a dicha tarea es por ejemplo de 35, la tarea se situará en el segundo tramo
(se aplica) en los tres primeros escenarios, dado que los límites entre el primer y segundo
tramo son respectivamente 50 (escenario 1), 42,5 (escenario 2) y 36,125 (escenario 3). La
gráfica generada permite situar gráficamente el valor de cada tarea y determinar el modo de
aplicación.
Para tareas que puedan aplicarse de más modos (en la Ilustración 6-9 pueden verse
también límites de 3 y 4 tramos), se llevaría a cabo el mismo razonamiento. Dependiendo del
tramo donde se sitúe la tarea, se aplicarán las tareas priorizables de un modo u otro.
Ilustración 6-9. Creación de escenarios con GVAL-Ex
Para cada escenario, es necesario comparar el valor de las tareas a realizar con el límite
definido en cada escenario. Si el límite es menor se descarta. Si es mayor, se aplica. El coste de
la aplicación de las tareas se extrae de los pesos relativos que se ha definido para cada una de
ellas en la hoja 1. El resultado de este proceso es el mostrado en el ejemplo de la página 98.
Todos los valores de las distintas hojas están relacionados entre sí mediante referencias,
de manera que si una vez terminado el proceso se desea ajustar cualquiera de los valores
introducidos, el aplicativo recalculará automáticamente todos los datos asociados. Esta
característica es muy útil para plantear los escenarios de valor y coste en tiempo real a los
distintos implicados, y darles la posibilidad de modificar el alcance de los desarrollos en
función de los recursos que se esté dispuesto a invertir de forma automatizada.
Tesis Doctoral Daniel Cabrero Moreno
174
6.3 Control de la priorización de tareas y la
recogida de datos
El establecimiento del nivel de cumplimiento de tareas priorizables es realizado
mediante la utilización de la herramienta GVAL-EX presentada en la sección 6.2. Sin embargo,
GVAL-EX cubre únicamente una parte del proceso. A partir de este momento, surgió la
necesidad de ordenar la aplicación de las distintas tareas a aplicar para un gran número de
proyectos (más de 100). En el Capítulo 7 de validaciones se plantea monitorizar el
comportamiento de una gran cantidad de artefactos, y el control de ejecución de tareas
priorizables, así como la recogida de datos extraídos de su aplicación, deben necesariamente
en este contexto ser ordenadas a través de una herramienta.
La creación de una infraestructura adecuada de recolección de datos es posible en la
DGT gracias a la obligatoriedad de todos los proyectos de pasar el conjunto de auditorías
establecidas por el Departamento de Calidad, cuya finalidad es presentada en detalle en la
sección 7.2.2.
6.3.1 Control y priorización de entregables
Con el objetivo de ordenar la aplicación de tareas priorizables, la DGT ha implementado
un desarrollo a medida, consistente en un aplicativo web, llamado “Plataforma de
Auditorías”, que debe utilizar todo el personal del Departamento de Calidad a la hora de
evaluar los productos entregados por los adjudicatarios. Este aplicativo está ya siendo utilizado
en la ejecución de auditorías, y la recogida de datos ha sido iniciada en Mayo de 2009. El
aplicativo consta de dos secciones diferenciadas:
Una interfaz de administración que permite administrar los proyectos
existentes, sus datos económicos y los entregables que se exigen (la estructura de
las auditorías y comprobaciones a realizar para cada proyecto, los miembros de los
equipos de los adjudicatarios, su perfil, y su dedicación a los desarrollos, etcétera).
La interfaz web de la parte de administración del aplicativo se presenta en la
Ilustración 6-10. Los datos introducidos en esta parte de administración tienen por
objetivo reflejar la estructura de proyectos y sus datos básicos, además de las
comprobaciones de entregables y tareas que aplica a cada equipo de desarrollo.
El aplicativo permite personalizar un subconjunto de comprobaciones para cada
proyecto concreto, lo que permite aplicar la priorización planteada en esta Tesis
Doctoral, ya que puede reflejar las necesidades concretas de cada proyecto
basadas en las directrices de valor. El objetivo de este aplicativo es automatizar el
control sobre las tareas priorizables que son exigidas a los distintos adjudicatarios,
mediante el establecimiento y control de entregables asociados a dichas tareas.
Tesis Doctoral Daniel Cabrero Moreno
175
Ilustración 6-10. Interfaz de administración de la aplicación de soporte a auditorías
Un módulo de auditorías. Una vez definidas las directrices de calidad y los
entregables (asociados a las tareas priorizables) que aplican a cada proyecto, se
utilizará el módulo de auditorías para guiar todos los pasos y comprobaciones que
el equipo de auditores de la DGT lleva a cabo sobre cada entregable de cada
proyecto. Adicionalmente, todos los resultados de las auditorías, y los
incumplimientos de las directrices iniciales son almacenados en la base de datos
para su posterior explotación.
Ilustración 6-11. Interfaz de ejecución de chequeos de la aplicación de soporte a auditorías
Tesis Doctoral Daniel Cabrero Moreno
176
La Ilustración 6-11 muestra la interfaz gráfica del módulo de auditoría, donde para
cada proyecto (en este caso el proyecto CCAL), y para cada entregable (en el
ejemplo, el entregable de Plan de Proyecto), la aplicación muestra el historial de
auditorías, y para cada una de ellas, muestra el conjunto de chequeos a realizar
para este proyecto concreto. Todas las auditorías son guardadas en un histórico,
dado que los datos de retrasos por entregas fallidas, y los datos de
incumplimientos de los proyectos son muy valiosos en la explotación de
información que se realiza posteriormente.
La potencia de esta herramienta de cara a la implantación y validación de los
planteamientos de valor reside en que la interfaz de administración permite administrar
(añadir, modificar, consultar y borrar) las comprobaciones sobre los entregables y tareas
priorizables. Esto permite adaptar y ampliar el árbol de tareas priorizables sin necesidad de
desarrollos, por medio de la interfaz web habilitada al efecto.
6.3.2 Conectores de importación de datos
El desarrollo de la plataforma de auditorías ha sido realizado de manera que es posible
importar ficheros de datos provenientes de otras herramientas, y añadir dichos datos a la base
de datos que se explotará posteriormente. La herramienta da la opción de definir la posibilidad
de importar ficheros de datos por cada posible chequeo, mediante un upload en la interfaz
web. La asignación de los conectores disponibles a los chequeos únicamente requiere
configuración, aunque la inclusión en el aplicativo de nuevos conectores si requiere desarrollos
adicionales.
Actualmente hay varios conectores de importación (generalmente de ficheros planos y
ficheros XML) desde varias herramientas. El detalle de los datos recogidos se describe a
continuación.
6.3.3 Almacenamiento de los datos de cara a su explotación
Todos los datos recogidos en la aplicación se almacenan en una base de datos (en este
caso, de tecnología ORACLE), de la manera más desagregada posible. Los datos más
significativos que actualmente se están almacenando son:
Proyectos en cartera, datos económicos de cada proyecto, adjudicatario al que
pertenecen, equipo de trabajo asignado, perfiles de cada componente, usuarios de
la DGT implicados, responsables por parte de la DGT.
Tesis Doctoral Daniel Cabrero Moreno
177
Comprobaciones sobre los entregables a realizar para cada proyecto. Cada
desarrollo es asociado en la herramienta a un subconjunto de comprobaciones
realizadas a lo largo del ciclo de proyecto. Para cada entregable se registra la fecha
de finalización, las revisiones del Departamento de Calidad, y los rechazos y vistos
buenos obtenidos.
o Planificación: hitos previstos en todas las entregas, fechas de entregas
reales (de donde se pueden deducir los retrasos), equipo de proyecto
involucrado en cada tarea, comprobación del detalle de la planificación y
de la existencia de todos los entregables exigidos en la metodología de la
DGT, verificación de la asignación de recursos para su contraste con la
información contractual, controles sobre la sobre-asignación de recursos,
estructura, plantillaje y estilo exigido en la DGT, visto bueno de los
usuarios e implicados.
o Objetivos, diagramas de contexto y subsistemas: Existencia de un
modelado que refleje los objetivos, chequeo de que los objetivos están
debidamente relacionados con requisitos, chequeo de coherencia entre los
actores presentados en los diagramas de contexto y el resto del modelado,
adecuación de dichos objetivos al contrato, visto buen de los usuarios e
implicados.
o Maqueta y prototipo: Elaboración del entregable, adecuación a los
estándares de estilo, accesibilidad, visto bueno de los usuarios e implicados
según el tipo de validación escogida (maqueta, prototipo, o ambas), uso de
los componentes de presentación estandarizados.
o Requisitos: Existencia de un modelado basado en casos de uso,
consistencia con el diseño y los objetivos, formato de los diagramas de
flujo que describen los escenarios de casos de uso, coherencia entre dichos
diagramas y los diagramas de casos de uso, documentación adecuada de
cada elemento del modelado, localización de malas prácticas, identificación
de flujos duplicados, adaptación a la plantilla, existencia de realización de
casos de uso y formato adecuado.
o Análisis y Diseño: Coherencia con los requisitos y el código, correcta
documentación, adaptación a la plantilla y estilos, completitud del diseño
en relación con los requisitos, coherencia entre los distintos diagramas
estáticos y dinámicos.
o Código: Reglas de Checkstyle y PMD, comprobación de que todas las
interfaces definidas en código aparecen en el diseño, comprobación del
porcentaje de clases, métodos y atributos públicos están reflejados en el
diseño.
Tesis Doctoral Daniel Cabrero Moreno
178
o Construcción y paso de entornos: Chequeo de los artefactos requeridos
para compilar en la infraestructura corporativa.
o Pruebas: Chequeo de pruebas unitarias, evaluación mediante EMMA de la
cobertura de pruebas funcionales, ejecución del subconjunto de pruebas
automatizadas, ejecución de pruebas de rendimiento, chequeo de los
planes de pruebas, adecuación de la cobertura obtenida.
o Implantación y aceptación: Completitud de los documentos de
implantación, manuales de usuario, adecuación a las plantillas,
documentos de instalación… etcétera.
o Mantenimiento: Fechas de subidas urgentes como consecuencia de errores
registrados, evolutivos realizados, o nuevas versiones.
Datos extraídos de los conectores:
o Frecuencias de utilización a través de EMMA (formato XML).
o Frecuencia histórica de cambios almacenada en el CVS (formato texto
plano a través del API que proporciona CVS).
o Infracciones de reglas de modelado de objetivos, requisitos, análisis y
diseño importadas (formato XML). Esta información es extraída
automáticamente a través de un plug-in de ECLIPSE desarrollado a medida
en la DGT para automatizar las comprobaciones de estructura y
coherencia.
o Actividad de los miembros del equipo en el CVS (formato texto).
o Horario de fichajes de los miembros del equipo (fichero exportado de la
aplicación corporativa de fichajes).
o Incidencias por proyecto (fichero plano exportado del sistema de control
de incidencias corporativo).
o Número de accesos y registros de auditoría de cada software. La
importación de estos datos es sencilla gracias a que la auditoría está
estandarizada mediante un componente común de arquitectura
(importación directa de otra Base de Datos).
o Errores detectados en el log de las aplicaciones. El log y los formatos de
salida también están estandarizados mediante un componente común
(fichero de texto).
Tesis Doctoral Daniel Cabrero Moreno
179
o Disponibilidad de los aplicativos en producción, a través de sondas que
periódicamente chequean páginas de prueba en cada aplicativo. El
software de monitorización genera un fichero de texto que es importado a
través de un conector. Esta información contiene el número y momento de
las indisponibilidades de cada aplicativo.
Las comprobaciones comentadas un subconjunto de los más de 300 chequeos
desglosados en unos 20 entregables. Es importante que cada una de las tareas priorizables
definidas tenga una o varias comprobaciones sobre los artefactos asociados. Las
comprobaciones a realizar son extensibles a través de la herramienta, y cada uno de los
resultados de auditoría sobre cada entregable es almacenado en el modelo de datos.
Tesis Doctoral Daniel Cabrero Moreno
180
6.4 Extracción del Indicador de Frecuencia de Uso
La Reducción de Software puede estar basada en múltiples indicadores, pero
fundamentalmente trata de retirar aquellos artefactos que no son utilizados. Por lo tanto, la
primera automatización que es necesario llevar a cabo para la aplicación de RS es la
recolección de la actividad de ejecución de cada método. Dicha actividad servirá para asignar
un valor relativo (posiblemente en combinación con otros indicadores), que marcará los
artefactos sobre los que aplicar la Reducción.
La frecuencia de uso de los distintos artefactos puede también ser usado, según GVAL,
para priorizar cualquier otra tarea relacionada con el mantenimiento del software.
6.4.1 Herramientas
La frecuencia de utilización de cada método debe ser obtenida por método y resumida y
ordenada para su aplicación. Para automatizar este proceso, tres opciones principales han sido
consideradas.
La primera opción es utilizar Programación Orientada a Aspectos (Aspect-Oriented
Programming - AOP). AOP surgió de las limitaciones de la Programación Orientada a
Objetos, con el objetivo de aislar aspectos transversales a varios módulos, que fueron
llamados “aspectos”. Algunos autores (Gschwind & Oberleitner, 2003) han propuesto el
uso de AOP para llevar a cabo el análisis dinámico del comportamiento del software.
Según comentan, un punto a favor de su utilización es que proporciona mayor detalle
de la ejecución de programas.
En segundo lugar, se han considerado las herramientas de cobertura de pruebas.
Existen herramientas disponibles, tanto en versión de pago como en versión de código
abierto, como EMMA (EMMA, 2008) o Cobertura (Cobertura, 2008). Estas herramientas
son utilizadas principalmente para evaluar la cobertura de un conjunto de pruebas
funcionales. En lugar de eso, pueden ser usadas para extraer la frecuencia de uso de
los artefactos, a través de los datos que éstas recogen.
En tercer lugar, puede utilizarse una herramienta de monitorización de propósito
general. En ese sentido, existen estudios comparativos que evalúan las distintas
opciones tecnológicas para llevarlas a cabo de forma que sobrecargue lo menos posible
los sistemas monitorizados (Kumar et al., 2006). Una de las utilidades de
monitorización más utilizadas es la Java Virtual Machine Profiler Interface (JVMI, 2008),
el API proporcionado por SUN.
AOP y las herramientas de monitorización recogen normalmente una gran cantidad de
información que, en sistemas con carga de usuarios, puede ser muy difícil de gestionar y
Tesis Doctoral Daniel Cabrero Moreno
181
almacenar debido a su volumen. Por esa razón, se suele realizar algún tipo de agregación
(Ducasse et al., 2004), procesamiento on-line (Breech et al., 2005), o compresión (Antoniol &
Penta, 2004) de la información.
Para la aplicación de la frecuencia de uso en el marco de este trabajo, únicamente es
necesaria la información de ejecución más básica, y la agregación puede hacerse sobre la
marcha mediante contadores. Dado que en este caso no es necesario más detalle que el
número de invocaciones por método, clase y paquete, no es necesario un método de
extracción de información tan detallada como AOP o las herramientas de monitorización.
Otro problema que presenta tanto AOP como la monitorización es que debe
desarrollarse un software específico encargado de resumir y ordenar la información, mientras
que las herramientas de cobertura de pruebas ya realizan esta labor.
Dados los requisitos específicos de este trabajo, se propone utilizar una herramienta de
cobertura de pruebas que proporcione la información ya ordenada y resumida en formato XML.
Una herramienta de código abierto es además recomendable, porque ofrece la posibilidad de
ser modificada si fuese necesario. Otro factor a tener en cuenta es la tecnología a monitorizar
(J2EE, .NET u otras). En el entorno donde esta Tesis Doctoral es desarrollada y contrastada, la
mayoría del software está construido en J2EE.
Teniendo todo lo anterior en cuenta, se ha seleccionado la herramienta de código
abierto para J2EE “EMMA” Coverage Tool. Nótese sin embargo que para la implementación
de la RS, cualquier otra herramienta podría ser utilizada.
6.4.2 Pruebas de automatización realizadas en la DGT
El proceso de investigación encaminado a recoger las frecuencias de utilización se inició
como respuesta a una necesidad concreta existente en los departamentos de desarrollo
software de la DGT. En el marco de la Investigación en Acción, la empresa (en este caso la
DGT) identifica un problema real, y la entidad de investigación (en este caso la Universidad de
Castilla la Mancha) colabora con la empresa para solucionar dicho problema a la vez que se
aportan los logros de investigación en el campo que se esté tratando. En el caso de la recogida
y utilización de frecuencias de utilización, el proceso que se siguió fue el descrito a
continuación.
Inicialmente, la DGT disponía de 3 entornos diferenciados: Entorno de desarrollo,
entorno de preproducción y entorno de producción.
En el entorno de desarrollo es donde los las empresas que desarrollan para la DGT
(también llamados “adjudicatarios” o “proveedores”) tienen control absoluto, y es donde debe
realizarse todas las pruebas previas al inicio de la subidas a producción. En este punto, se
delega en los proveedores de software la responsabilidad del correcto funcionamiento del
Tesis Doctoral Daniel Cabrero Moreno
182
software. Una vez que el equipo de desarrollo da el visto bueno al desarrollo, el software es
instalado por el personal de la DGT en el entorno de preproducción, donde el
Departamento de Calidad asegura que las aplicaciones soportan la carga exigida en la
especificación de requisitos. El entorno de preproducción es una réplica del de producción, por
lo que es un buen escenario para asegurar los requisitos de rendimiento. Una vez que todos los
requisitos se cumplen, la aplicación puede subir al entorno de producción, donde es
utilizada por los usuarios. El escenario inicial, muy común en la mayoría de las factorías de
software, es el reflejado en la Ilustración 6-12.
Ilustración 6-12. Escenario inicial de infraestructura de la DGT
El Departamento de Calidad asegura el rendimiento de las funcionalidades más
importantes de los aplicativos, pero no dispone de recursos para realizar una batería de
pruebas unitarias, funcionales, y de regresión de todos los aplicativos, por lo que los
adjudicatarios son los responsables de realizar las pruebas necesarias para que el software sea
fiable.
El problema detectado es que los adjudicatarios no probaban el software que
entregaban, por lo que en colaboración con la UCLM se comenzó a investigar cómo podía
establecerse un criterio de calidad de obligado cumplimiento, y en este punto es donde se
comenzó a investigar las herramientas analizadas en la sección 6.4.1. La solución pasó por
añadir un entorno a la infraestructura existente, donde se monitorizara la cantidad de pruebas
funcionales realizadas a través del framework de EMMA. La Ilustración 6-13 muestra la
infraestructura definitiva, donde se añadió un entorno al escenario inicial.
Entorno de
DESARROLLO BD
Entorno de
PREPRODUCCIÓN BD
Entorno de
PRODUCCIÓN BD
Pasos de
Entorno
Tesis Doctoral Daniel Cabrero Moreno
183
Ilustración 6-13. Escenario final de infraestructura de la DGT
A partir de la introducción de este nuevo entorno, se monitoriza con la ayuda del
framework EMMA que un porcentaje lo suficientemente alto de métodos, clases y paquetes son
invocados durante la batería de pruebas (tanto automáticas como manuales) realizadas por los
adjudicatarios. Cuando el adjudicatario pide la subida a producción, el Departamento de
Calidad analiza los porcentajes ejecutados, chequea que los logs de errores y avisos sean
correctos, y autoriza la subida al entorno de preproducción donde se realizan las pruebas de
rendimiento.
La introducción del nuevo entorno cubrió el objetivo deseado, incrementando la
fiabilidad de los aplicativos, y minimizando el número de subidas requeridas antes de la puesta
en producción, con el consiguiente ahorro de costes. Sin embargo, el análisis de la cobertura
de pruebas de varios aplicativos reales llevó a la conclusión de que una gran parte de los
aplicativos (sobre todo los aplicativos legados) no eran utilizados en ningún caso, y
se propuso la refactorización de algunas partes de los aplicativos. Para ello, una vez más, en
colaboración con la UCLM se estudiaron las directrices a aplicar en los mantenimientos, en lo
que a la postre ha desembocado en lo que ha llamado Mantenimiento Software Basado en
Valor (MSBV) presentado en el Capítulo 5.
Entorno de
PRODUCCIÓN
Entorno de
DESARROLLO
Entorno de
PREPRODUCCIÓN
Pasos de
Entorno
BD
Nuevo Entorno de
MONITORIZACIÓN
para cobertura
BD
BD
BD
Tesis Doctoral Daniel Cabrero Moreno
184
Para cada subida de software, se generan de manera automatizada dos aplicaciones
empaquetadas (ficheros .EAR en el caso de la DGT, al tratarse de aplicaciones J2EE). Una con
monitorización destinado al entorno de monitorización, y otra sin monitorización destinado al
entorno de preproducción. La existencia de dos entornos, por los que todos los aplicativos
deben pasar en las subidas importantes, permite además realizar pruebas de rendimiento sobre
aplicativos, y evaluar las diferencias de rendimiento para establecer cuáles pueden ser
monitorizados en producción, para recoger las tendencias de los usuarios.
Adicionalmente, se han utilizado los datos extraídos de algunos aplicativos en
producción a través de esta herramienta para llevar a cabo validaciones sobre la potencia de la
Reducción de Software en proyectos reales (el tanto por ciento potencial de simplificación que
hay en los aplicativos). Véase el punto 7.3 (página 200) para consultar el detalle del porcentaje
de artefactos no utilizados para una decena de proyectos reales.
Tesis Doctoral Daniel Cabrero Moreno
185
6.5 Aportaciones realizadas en este Capítulo
En esta sección se presenta una primera aproximación de automatización de los
pasos de GVAL realizada con hojas Excel, que ha sido utilizada como soporte para la
realización de los distintos ejemplos presentados a lo largo de este documento. La experiencia
acumulada confirma que las ponderaciones por pesos se vuelven inmanejables a partir de dos
o tres tareas priorizables e indicadores.
La ordenación de la aplicación de tareas priorizables, y el almacenamiento de todos los
datos de ejecución de proyecto sobre los que se basarán los indicadores, ha sido llevada a
cabo mediante un desarrollo a medida presentado en esta sección.
Finalmente, otro aspecto presentado en esta sección es la automatización del
proceso de extracción de la frecuencia de uso, que ha sido realizado en el marco de la
Investigación en Acción en la que participa la DGT y la Universidad de Castilla la Mancha.
Tesis Doctoral Daniel Cabrero Moreno
186
Tesis Doctoral Daniel Cabrero Moreno
187
Capítulo 7 – Validación
de Propuestas
7.1 Sobre la validación de técnicas basadas en valor
La validación de las técnicas basadas en valor tiene una serie de condicionantes
especiales, que serán analizados a lo largo de la presente sección, con objeto de justificar el
escenario de validación planteado en esta Tesis Doctoral.
7.1.1 Clasificación de validaciones en trabajos previos
En el ámbito de la ISBV, la revisión proporcionada en el 0 expone fundamentalmente
dos tipos de validaciones de técnicas basadas en valor:
La mayoría de las validaciones realizadas hasta la fecha establecen típicamente
dos grupos de alumnos, y aplican la orientación basada en valor a uno de ellos.
Por ejemplo, se utilizan dos grupos de alumnos para comprobar que las pruebas
encuentran un mayor porcentaje de defectos importantes para los clientes en
menos tiempo si se utilizan priorizaciones basadas en valor (Srikanth & Williams,
2005). También se realiza un experimento similar (Thelin et al., 2003) pero
orientado a las revisiones, donde se seleccionan otros dos grupos de alumnos para
medir el tiempo que se tarda en encontrar los defectos a través de revisiones sobre
un sistema simple.
El segundo tipo de validación es aquel que en lugar de utilizar diversos grupos,
únicamente se ocupan de asegurar que las tareas despriorizadas dejan de
consumir recursos. Por ejemplo, en (Heindl & Biffl, 2005) se demuestra que la
trazabilidad basada en valor reduce en un 35% el esfuerzo a realizar con respecto
al trazado total de los artefactos, es decir, se demuestra que el esfuerzo realizado
en trazabilidad disminuye, pero no se evalúa de ningún modo el impacto que esta
reducción de esfuerzo tiene.
Tesis Doctoral Daniel Cabrero Moreno
188
7.1.2 Carencias del planteamiento previo
En los dos tipos de validaciones que pueden encontrarse en una revisión de los trabajos
realizados en ISBV, existen dudas razonables de la aplicabilidad de las técnicas a entornos
reales de desarrollo y mantenimiento de software. Las carencias más relevantes de las
validaciones analizadas se detallan a continuación:
Inexistencia de implicados de negocio reales. La ISBV tiene por objetivo
alinear el negocio y las prácticas de IS. En ninguna validación planteada se
extraen los indicadores que guían las prácticas de implicados reales. La
aplicación de técnicas en grupos controlados de alumnos no son el mejor
escenario para evaluar las directrices de valor, dado que éstas no existen o son
artificialmente supuestas.
Carencia de evaluación de las implicaciones de negocio. La no aplicación
de una determinada práctica de IS tendrá a la postre un impacto negativo sobre
la calidad del producto. La ISBV trata de permitir estas posibles deficiencias
únicamente si los objetivos de negocio pueden asumirlo.
Validación mediante experimentos controlados. Para poder evaluar la
validez de la alineación del negocio de los sistemas de información a largo plazo,
es necesario analizar series temporales de varios años. Esto es debido a que los
objetivos de negocio suelen situarse a medio o largo plazo. A esto es necesario
sumarle el tiempo de montar la infraestructura y ejecutar los experimentos, que
en una organización real suele ser de años. Por tanto, su cumplimiento no puede
evaluarse en un experimento de horas de duración.
Indisponibilidad de datos de mantenimiento y explotación. La
evaluación de la priorización por valor de las técnicas destinadas a elaborar
software de calidad debe ser contrastada mediante la monitorización del
comportamiento de dicho software a lo largo de periodos de mantenimiento. La
disponibilidad de dichos datos hace necesario la implantación y recogida de
datos durante varios años, por lo que es difícilmente simulable en un
experimento.
Como se ha comentado, la validación de la correcta aplicación de las directrices de valor
a las prácticas de IS debe estar basada en datos de monitorización de series temporales de
varios años. Esta es la principal dificultad que motiva que no se hayan encontrado validaciones
más allá de lo comentado anteriormente.
Adicionalmente, el contraste de los datos almacenados durante todo ese tiempo en una
organización exige la implantación de un sistema de recogida de datos de los distintos
proyectos a desarrollar y mantener. Tratándose además GVAL de un método genérico, que
integra y mejora propuestas de otros autores, una multitud de combinaciones de indicadores y
Tesis Doctoral Daniel Cabrero Moreno
189
tareas priorizables es posible, por lo que se requiere un marco amplio de aplicación y
monitorización. En este sentido, la siguiente sección describe la propuesta de infraestructura
que se está construyendo en la Dirección General de Tráfico.
Tesis Doctoral Daniel Cabrero Moreno
190
7.2 Planteamiento de Validación en la DGT
7.2.1 El desarrollo y mantenimiento de software en la DGT
En la sección 1.4.3 se describe el papel en esta investigación de la Dirección General de
Tráfico en el marco de la Investigación-Acción. Como se expone entonces, el desarrollo y
mantenimiento software de la DGT implica a un gran abanico de adjudicatarios (sobre la
veintena), y a multitud de equipos diferentes implicados en más de 100 proyectos, para un
departamento de desarrollo que consta de entre 200 y 300 profesionales. Este entorno
aporta la diversidad necesaria para validar propuestas.
La Dirección General de Tráfico es la responsable en España del tratamiento de los
datos de accidentes, radares, vehículos, conductores, tasas y multas de tráfico. Para realizar la
labor encomendada, el parque de aplicaciones informáticas ordena en distintas áreas los
sistemas más importantes:
1. Conductores:
a. Automatización exámenes teóricos.
b. Automatización de los reconocimientos médicos desde los distintos Centros de
Reconocimiento de conductores.
c. Acceso controlado de los usuarios externos a la información de bases de datos
de la DGT.
d. Campaña de permiso de conducir a 1€.
e. Perseo (expedición del permiso de conducción en tarjeta plástica).
f. Permiso por puntos.
g. Pérdida de vigencia del carnet.
2. Recursos Humanos:
a. Interfaces con sistemas de nóminas estatales.
b. Gestión de la productividad del personal.
c. Gestión de la Acción Social.
d. Sistema de personal y control horario
3. Internet: Desarrollo de la Web corporativa.
4. Canjes de permisos y cita previa.
5. Radares y puntos kilométricos.
6. Vehículos:
Tesis Doctoral Daniel Cabrero Moreno
191
a. Tramites telemáticos disponibles al ciudadano (Informe técnico de vehículos,
matriculación telemática desde los Colegios Gestores, bajas telemáticas de
vehículos…).
b. Incorporación de datos ITVs automática.
c. Pre-matriculación.
7. Procedimiento sancionador:
a. Gestión de expedientes sancionadores.
b. Integración con Pride (tramitación de denuncias automáticas desde terminales
móviles de la Guardia Civil).
c. Pago con tarjeta de sanciones desde terminales de la guardia civil.
d. Gestión de Recursos y Alegaciones.
e. Recursos de sanciones de tráfico por Internet.
8. Data Warehouse corporativo para el análisis de datos por el observatorio de tráfico.
9. Tablón edictal de publicación de sanciones.
10. Sistema de notificaciones automatizadas al ciudadano.
11. Arena (sistema integrado de accidentes de tráfico).
12. Arquitectura de componentes transversales a todas las aplicaciones, incluyendo el
desarrollo de un Registro Telemático que deberá ser utilizado por todos los trámites
telemáticos.
13. Sistema de información georeferenciada de los centros de gestión de tráfico.
14. E-traffic: Sistema de gestión del tráfico para el ciudadano.
15. Integración e intercambio de información con los sistemas de 8000 ayuntamientos,
2000 centros de reconocimiento médico, todas las Comunidades autónomas, todos los
ministerios, colegios de gestores, estaciones de ITV… etc.
16. Componentes comunes transversales a todas las aplicaciones como log, auditoría,
autenticación, tablas comunes, envío de correos y sms, envío de correo ordinario, firma
digital, fecha y hora sincronizada con el Instituto Real de la Armada, utilidades, etc.
17. Pasarela de pagos de multas y tasas.
a. Pago de multas por Internet
b. Pago de tasas por internet
c. Compra de tasas múltiples
Tesis Doctoral Daniel Cabrero Moreno
192
18. Integración de intercambio de datos con más de 8000 ayuntamientos, Correos, el
Banco Santander, todas las comunidades autónomas, los centros de reconocimiento de
conductores, las jefaturas de tráfico, la mayoría de los ministerios, la agencia tributaria,
la seguridad social, los cuerpos de seguridad del estado, los cuerpos de seguridad
autonómicos, el consejo general del poder judicial, los juzgados, el ministerio de
presidencia, la casa real... etcétera.
19. Adicionalmente a los proyectos en marcha, a lo largo de 2009 y 2010 se prevé poner
en marcha la reingeniería completa (para su traspaso a sistemas abiertos) de una gran
cantidad de transacciones que actualmente residen en el Host Corporativo.
a. Conductores (expedición de permisos, renovación de permisos, mantenimiento
de permisos, gestión de la BD de conductores…),
b. Vehículos. Es necesario migrar la práctica totalidad de las transacciones que
todavía residen en Host.
c. Procedimiento Sancionador. Algunas transacciones todavía residen en Host.
d. Inditraf (anotación y gestión de pagos de tasas y multas).
e. Exámenes: Automatización de exámenes prácticos.
7.2.2 El Departamento de Calidad
En el ámbito de la administración pública, raramente los sistemas son desarrollados y
mantenidos por personal interno. En su lugar, se adjudican concursos de desarrollo a empresas
colaboradoras. Según este modelo, los adjudicatarios desarrollan el software que debe ser
evaluado y certificado de cara a su pago. La DGT cuenta con un Departamento de Calidad, que
se creó a mediados de 2007 con el objetivo de controlar la consecución de los objetivos
funcionales, calidad del producto, y calidad del proceso de desarrollo y mantenimiento
exigido a los adjudicatarios.
En la DGT, para que un contrato pueda ser pagado es necesario que el adjudicatario
pase todos los filtros y prácticas exigidos por el Departamento de Calidad. El autor de esta
Tesis Doctoral es el responsable de dicho departamento, que en 2009 consta de unas
40 personas encargadas de:
Definir de ciclo de desarrollo, herramientas, metodologías y buenas prácticas a
utilizar por todos los adjudicatarios de desarrollos o mantenimientos de la DGT. Las
herramientas obligan a modelar todos los requisitos, diseño y entregables de
pruebas de manera formal, para su posterior estimación de tamaño y complejidad.
Definir una arquitectura tecnológica de desarrollo, identificar componentes
comunes y de arquitectura, desarrollarlos y ponerlos a disposición de los
Tesis Doctoral Daniel Cabrero Moreno
193
adjudicatarios. Comprobar mediante auditorías e inspecciones su correcta
utilización. Autorizar las opciones tecnológicas planteadas por los adjudicatarios.
Definir, realizar y evaluar las pruebas de rendimiento, funcionales y de regresión de
todos los desarrollos. Emitir informes de adecuación de dichos entregables a cada
proyecto.
Realizar auditorías de Calidad vinculantes para el pago de los contratos. Cada
auditoría de Calidad finaliza con un informe de incumplimientos que deben ser
corregidos antes de cada pago.
Realizar las comprobaciones necesarias previas a la autorización de subidas del
entorno de desarrollo a preproducción, y del entorno de preproducción a
producción.
Recoger todos los datos posibles de los proyectos en el marco de la certificación
del nivel 3 de CMMI ACQ 1.2. El análisis de los datos recogidos será necesario para
la mejora continua de los procesos de la DGT, cuya definición también es
responsabilidad del Departamento de Calidad.
Definir y auditar los métodos de trabajo de los equipos de desarrollo.
Certificar y asegurar la calidad de los desarrollos antes del pago de los contratos.
Definir y controlar los servicios IT contratados por la DGT, apoyándose en la
implantación de los procesos de gestión de cambios, gestión de incidencias,
gestión de los Acuerdos de Nivel de Servicios (ANS), y gestión de cambios ITIL.
El Departamento de Calidad tiene la potestad de definir las normas de Calidad
aplicables a cada desarrollo, por lo que establece la obligatoriedad del cumplimiento de
prácticas y entregables. En el ámbito de este trabajo de investigación, el Departamento de
Calidad establece el grado de implementación de las distintas tareas priorizables definidas por
GVAL en la Ilustración 3-2. Es también este departamento el que evalúa el cumplimiento de
las directrices, y recoge los datos de actividad, productividad, incidencias, incumplimientos,
retrasos, rechazos de entregables, etcétera.
En una primera fase de certificación de la Calidad de los procesos y entregables, el
Departamento de Calidad se centró en exigir un mínimo de entregables que debían cumplir
unos estándares de Calidad. Posteriormente, el nivel de exigencia se ha incrementado
paulatinamente, hasta llegar a exigir un gran número de entregables, para los que se
realizaban centenares de comprobaciones repartidas entre las distintas fases del desarrollo y
mantenimiento. Muchas de las comprobaciones se realizan actualmente apoyándose en
herramientas de comprobación desarrolladas al efecto.
Tesis Doctoral Daniel Cabrero Moreno
194
El problema de la aplicación de todos los criterios de Calidad a todos los
proyectos choca actualmente con algunos objetivos de negocio, dado que un nivel de
calidad muy alto exige un mayor tiempo de desarrollo y una mayor inversión. Por este motivo
se está comenzando a aplicar los conceptos de ISBV, para priorizar el cumplimiento de los
criterios de calidad por los distintos adjudicatarios. Por ejemplo, en el caso de una aplicación
que debe ser muy fiable como la de infraestructura de pago, de la que depende el ingreso de
centenares de millones de euros en la DGT, el proceso de pruebas debe ser especialmente
exigente (así como las tareas priorizables de pruebas), y debe primar sobre la urgencia. Por
tanto, desde el Departamento de Calidad se puede guiar la aplicación de valor a todos los
sistemas, mediante la definición de criterios de auditoría y buenas prácticas personalizadas por
cada proyecto, y alineadas con el valor de la organización.
Como se comentaba anteriormente, el contraste de los resultados obtenidos por la
aplicación de GVAL debe ser evaluada en un horizonte temporal de no pocos años, por este
motivo, el Departamento de Calidad de la DGT ha puesto en marcha una infraestructura
de medición, que permita evaluar la aplicación de conceptos de valor, y modificar los
requisitos exigidos que contractualmente se exige a los adjudicatarios en función de los datos
recogidos. A continuación se describe en detalle.
7.2.3 Infraestructura de medición y plan de recogida de datos
La validación de la aplicación de GVAL únicamente puede ser probada disponiendo de
los datos adecuados de un número grande de proyectos. La recogida de gran cantidad de
datos de un número tan alto de proyectos exige una automatización adecuada que asegure su
viabilidad. Por este motivo, el primer paso en la implantación de la infraestructura de validación
es el desarrollo (expuesto en la sección 6.3) de las herramientas de apoyo a las auditorías y
recogida de datos mediante conectores.
Como se comentaba entonces, el control del grado de ejecución de las tareas
priorizables se realiza a través de un aplicativo que relaciona cada desarrollo con un
subconjunto de comprobaciones, y almacena todos los datos para su explotación. El desarrollo
de diversos conectores presentados en la página 176 es también fundamental para
complementar la información de las auditorías.
Los datos almacenados en la aplicación pueden dividirse en varios tipos, tal y como se
muestra en la Ilustración 7-1:
Tareas priorizables a aplicar a cada proyecto.
Datos provenientes de las auditorías del Departamento de Calidad.
Datos de actividad complementarios extraídos a través de conectores.
Tesis Doctoral Daniel Cabrero Moreno
195
Estos datos son cargados actualmente por el aplicativo de gestión de la Calidad en una
Base de Datos que almacenará la actividad de todos los proyectos, para su posterior carga en
el DataWarehouse corporativo, actualmente implementado sobre tecnología Teradata y
Microstrategy.
Ilustración 7-1. Infraestructura de validación del Departamento de Calidad de la DGT
Toda la información contenida en la base de datos del aplicativo de gestión de
auditorías es cargada de forma desagregada en el DataWarehouse (DWH) corporativo para su
posterior análisis y cruce.
Adicionalmente, es importante realizar encuestas sobre la percepción que todos los
implicados tienen de cada uno de los indicadores de valor utilizados. La información de los
indicadores de valor asociados a cada requisito importante es fundamental para realizar un
análisis detallado de qué datos están correlacionados con qué indicadores.
- Auditorías - Planes de proy. y desviaciones - Entregables - Indicadores de valor aplicados - Tareas priorizables aplicadas - Rechazos de entregables - Costes y recursos - Subidas a producción - Infracciones planificación,
requisitos, análisis, diseño, código y pruebas
- Planes de Prueba - Resultados de pruebas
- Gestor de incidencias - Actividad de cada sistema - Frecuencia de Uso (EMMA) - Errores y Actividad de los
aplicativos - Indisponibilidades - Mantenimientos correctivos - Índice de actividad en el CVS - Personal (horario y estructura)
DPTO. CALIDAD
OTRAS FUENTES
DWH CORPORATIVO
INT
EG
RA
CIÓ
N D
E D
AT
OS
MINERÍA
INTRODUCCIÓN DE DATOS PROCESAMIENTO Y
ALMACENAMIENTO ANÁLISIS
- Modelo de datos - Extensible
- Data Warehouse - Cuadros de mandos
VALIDACIÓN INDICADORES
DE IMPLICADOS
Tesis Doctoral Daniel Cabrero Moreno
196
7.2.4 Análisis de los datos
7.2.4.1 Correlación entre las tareas priorizables y los indicadores
Mediante el análisis de los datos recogidos se pretende demostrar que es factible influir
en el valor que el software aporta a los implicados a través de la aplicación de técnicas de IS.
La idea es utilizar los datos indicados en la sección anterior para contrastar la aplicabilidad de
GVAL.
Para ello, se propone estudiar la correlación entre las prácticas de IS aplicadas a cada
proyecto y los indicadores de valor relevantes para los distintos implicados. Dicho de otro
modo, se pretende contrastar lo “valiosa” o “perjudicial” que es para la percepción de los
implicados cada práctica de IS. El grado de correlación entre los indicadores y las tareas
priorizables contrastará a través de datos empíricos la definición de las tareas e indicadores (la
fase 1 de GVAL). De este modo, se puede utilizar dicha información para actualizar el árbol de
tareas priorizables y el árbol de indicadores que GVAL propone.
Los datos desagregados almacenados utilizando las herramientas presentadas en el
Capítulo 6 son agregados y segmentados por cada requisito y proyecto. De este modo, por
cada requisito se recogen los datos sobre el grado en que se ejecutó de cada tarea priorizable,
y los indicadores de valor que los implicados perciben (o que son recogidos en el caso de ser
indicadores objetivos) al final de un periodo de utilización del software.
Los indicadores recogidos son normalizados a 100, y pueden ser obtenidos mediante
encuestas de percepción de los implicados (utilizando las técnicas de elicitación analizadas
anteriormente), o mediante la recogida de datos estadísticos.
Las tareas priorizables son asignadas en función al “tramo” de grado de ejecución de la
tarea priorizable con valores normalizados a 100. Si por ejemplo esta tarea tiene 4 modos de
ejecución, se asignarían 0 puntos si no se ejecuta, 33 si se ejecutó con arreglo al segundo
tramo, 66 al tercero, y 100 si se ejecuta totalmente. En el caso de haber 2 modos de ejecución,
se asignarán 0 puntos si no se ejecuta y 100 si se ejecuta.
Para cada requisito, se recoge la percepción subjetiva y objetiva a través de los
indicadores, y el grado en que se ejecutó cada tarea priorizable. La Tabla 7-1 muestra un
ejemplo de los datos que pretenden ser recogidos.
Tesis Doctoral Daniel Cabrero Moreno
197
Requisitos
R1 R2 R3 R4 …
Ind
ica
do
res I1 2 56 4 100 …
I2 3 74 3 5 …
I3 93 0 37 1 …
I4 76 100 54 0 …
… … … … … …
Ta
rea
s P
rio
riza
ble
s T1 0 50 50 100 …
T2 33 66 33 0 …
T3 100 0 100 100 …
T4 0 33 0 33 …
T5 25 75 0 0 …
T6 0 50 0 100 …
T7 100 100 50 50 …
… … … … … …
Tabla 7-1. Datos históricos de indicadores y ejecución de tareas
A partir de estos datos desagregados, es factible encontrar la correlación que existe
entre cada indicador y cada tarea priorizable. Si, por ejemplo, la mayoría de las veces que se
aplica una determinada práctica de IS a un requisito, hay un conjunto indicadores de valor que
se incrementa y otro conjunto que decrementa, podemos demostrar en base a los datos
recogidos que existe una correlación entre esa práctica y los indicadores que varían.
A partir de los datos desagregados, es posible cuantificar las correlaciones entre series
de datos. La Tabla 7-2 muestra un subconjunto de datos de ejemplo de índices de correlación
para ilustrar el concepto. En el ejemplo mostrado se normalizan también los índices de
correlación. Un índice de correlación negativo entre dos series indica que cuando un dato
aumenta el otro disminuye, y debe ser reflejado en GVAL como un indicador de influencia
negativa sobre la tarea concreta (como en el ejemplo de la página 130).
Tareas Priorizables
T1 T2 T3 T4 T5 T6 T7 …
Ind
ica
do
res I1 90 -63 3 90 2 90 0 …
I2 -23 23 43 -34 2 23 -32 …
I3 53 2 2 23 78 -64 79 …
I4 1 98 -45 6 4 32 5 …
… … … … … … … … …
Tabla 7-2. Datos de correlación entre tareas priorizables e indicadores
Los datos extraídos del análisis de resultados servirán para analizar qué prácticas de IS
tienen efectos sobre el valor que los aplicativos tienen para las organizaciones. La información
Tesis Doctoral Daniel Cabrero Moreno
198
obtenida podrá ser utilizada para ajustar los pesos que las tareas priorizables tienen sobre los
indicadores.
Por ejemplo, si los implicados nos indican que el indicador 2 (I2) es fundamental para la
organización, sabremos que no debe implementarse las tareas priorizable 1,4 y 7 (al tener un
índice negativo de correlación), e incluso podremos ajustar los pesos de dichas tareas en el
indicador con arreglo a datos extraídos automáticamente.
Las tareas priorizables e indicadores de valor sobre los que se están recogiendo datos
son los identificados en los árboles propuestos en GVAL y recogidos en el aplicativo de
auditorías presentado en la sección 6.3. Ya se vio cómo se extraen los datos de los indicadores
objetivos en la sección 5.4.1.1. Los indicadores subjetivos son elicitados del mismo modo que
en los ejemplos vistos a lo largo de la Tesis Doctoral, a través de encuestas. La novedad reside
en que los datos recogidos a lo largo del histórico de proyecto por medio del aplicativo de
auditorías (ver sección 6.3.3) pueden ser utilizados como indicadores objetivos de actividad.
Cada indicador de actividad, por ejemplo, el número de rechazos del Departamento de
Calidad, o el número de días de retraso sobre la planificación prevista, puede ser analizado del
mismo modo. La variación de los mismos con arreglo a la aplicación de tareas priorizables es
también una fuente de información muy valiosa de cara a analizar el valor que aportan las
distintas prácticas de IS.
Una vez recogidos los datos durante un periodo de tiempo lo suficientemente largo
(estimamos que unos 4 o 5 años: un mínimo de 2 años para poner en producción los
desarrollos guiados por valor, y 2 o 3 años para evaluar su mantenimiento y alineación con los
indicadores definidos), se dispondrá de la suficiente información para evaluar de forma
empírica la reducción de costes por priorización de tareas, y el efecto en los indicadores de
valor que tiene cada tarea priorizable.
Las herramientas de minería descritas en la infraestructura habilitada automatizan de
manera sencilla el proceso, cargando las series de datos desde la Base de Datos del aplicativo
web del departamento de Calidad, y generando informes automáticamente con los índices de
correlación.
7.2.4.2 Creación de modelos de predicción de indicadores
Utilizando los datos históricos y la evolución de indicadores, es posible también estimar
en base a los datos existentes qué ocurrirá con los datos recogidos si se asocian distintas
tareas priorizables a los indicadores.
Por tanto, los datos permitirán no sólo confirmar o desmentir la influencia de las
distintas tareas de IS en la construcción y mantenibilidad de los proyectos, sino también
establecer qué tareas pueden ser despriorizadas y cuáles son fundamentales en cada escenario
de valor de negocio.
Tesis Doctoral Daniel Cabrero Moreno
199
Las herramientas de minería ayudan también a automatizar el proceso. Generan
informes de predicción de la probabilidad de obtener datos en una futura serie (por ejemplo de
un indicador) a partir de las series históricas de ese mismo indicador.
7.2.4.3 Horizonte temporal de la recogida de datos
Del modo que se ha descrito, es posible contrastar la aplicabilidad de GVAL de manera
genérica para todos los proyectos. Sin embargo, nos encontramos con un problema temporal
insalvable que hace que la obtención de los resultados exceda el marco de esta Tesis Doctoral.
Serían necesarios no pocos años para disponer de un grupo de datos de proyectos sobre los
que distintas tareas priorizables han sido aplicadas.
Dado además que la mayoría de los objetivos de valor son a medio y largo plazo, el
horizonte temporal necesario para poder observar empíricamente la influencia de las prácticas
de IS en los indicadores de valor es de varios años.
Dado que la infraestructura comienza a funcionar en el momento de la presentación de
esta Tesis Doctoral, los resultados no pueden ser mostrados en este estudio. Sin
embargo, la infraestructura de recogida de datos esta ya habilitada, y se podrán comenzar a
validar el éxito de la aplicación de prácticas y su priorización en algunos años.
Tesis Doctoral Daniel Cabrero Moreno
200
7.3 MSBV: Análisis de viabilidad de RS
La validación de la Reducción de Software requiere, al igual que en el resto de las
técnicas orientadas a valor, la infraestructura descrita en la sección anterior. Sin embargo,
dada la novedad de esta práctica que, al contrario que el resto de tareas priorizables, no existía
anteriormente, a continuación se plantea un modo alternativo basado en los indicadores de
mantenibilidad de validación de la propuesta.
7.3.1 Viabilidad de RS sin datos históricos
La validación de la aplicabilidad de la Reducción de Software es compleja, debido al
coste que implicaría medir el coste de mantenimiento de dos equipos en paralelo, uno para el
software reducido, y otro para el software original. Se trata de una comprobación inviable
sobre proyectos reales. Una vez que la infraestructura de medición esté habilitada, sería
posible estudiar los indicadores de mantenimiento de un número suficientemente grande de
proyectos que lo han usado y de proyectos que no.
Debido a que para eso es necesario esperar varios años, en su lugar se propone medir
los indicadores mejor correlacionados con el esfuerzo de mantenimiento, según la literatura de
IS encontrada al respecto. Se analizará la evolución de dichos indicadores a lo largo del
proceso de RS. Esta tarea puede ser realizada en un corto espacio de tiempo, sin esperar a que
los sistemas estén en fase de mantenimiento.
La Ilustración 7-2 muestra las características de los proyectos seleccionados para el
estudio, en términos de coste anual de mantenimiento estimado y tanto por ciento de código
no usado, extraído a través de EMMA.
Nótese que el análisis de los datos sugiere una cierta correlación, mostrada mediante
una regresión lineal en la Ilustración 7-2. En general, el coste de mantenimiento varía en
función de la cantidad de código no utilizado, que normalmente es estimado en función del
tamaño del sistema y de las necesidades de cambio del mismo. Se concluye, por tanto, que la
Reducción de Software debe ser aplicada preferentemente sobre sistemas con un coste de
mantenimiento alto, con objeto de maximizar los beneficios de su aplicación.
Tesis Doctoral Daniel Cabrero Moreno
201
Ilustración 7-2. Código no usado por proyecto DGT analizado
La información mostrada en la ilustración establece el contexto del estudio realizado. Sin
embargo, para evaluar los beneficios de la reducción, se han utilizado otros indicadores de
métricas de producto más relacionados con el coste de mantenimiento, descritos en la
siguiente sección.
7.3.2 Evolución de las métricas de producto con RS
Las métricas de producto han sido utilizadas para medir el tamaño y la complejidad del
software desde su aparición en los años 70. En particular, las métricas de productos Orientadas
a Objetos han sido introducidas principalmente en los últimos 15 años. Purao y Vaishnavil
presentaron un interesante resumen y clasificación de las métricas propuestas en la literatura
(Purao & Vaishnavi, 2003), analizando el momento de propuesta de cada una ellas. El estudio
señala que la mayoría de las métricas fueron propuestas entre 1994 y 1998. Se señala también
que, en muchos casos, distintos autores nombran las mismas métricas de manera diferente.
Una gran cantidad de propuestas que estudian validaciones tanto subjetivas (basadas en
opiniones de expertos), como objetivas pueden ser encontradas en la literatura (Li & Henry,
1993, Harrison et al., 1998, Briand et al., 2001, Fioravanti & Nesi, 2001, Emam et al., 2002,
Alshayeb & Li, 2003, Bandi et al., 2003, Dagpinar & Jahnke, 2003, Misra, 2005, Genero et al.,
2007).
En este trabajo se propone evaluar el impacto de la aplicación de RS en la
mantenibilidad utilizando algunas métricas simples de tamaño, presentes en la mayoría de los
estudios mencionados. La Tabla 7-3 muestra las métricas utilizadas.
-50.000,00 €
- €
50.000,00 €
100.000,00 €
150.000,00 €
200.000,00 €
250.000,00 €
0% 10% 20% 30% 40% 50% 60% 70%
Co
ste
an
ual
de
m
ante
nim
ien
to (a
pro
x)
% código no usado
Tesis Doctoral Daniel Cabrero Moreno
202
Métrica Predictiva Description
Average Class Size
(ACLOC)
Proporciona la media en líneas de código
de las clases que componen el sistema
Average Method Size
(AMLOC)
Proporciona la media en líneas de código
de los métodos que componen el sistema
Number of Classes (∑NC) Cuenta el número de clases
Number of Methods (∑NM) Cuenta el número de métodos públicos,
protegidos y privados (Lorenz & Kidd,
1994).
Number of Statements
(∑NS)
Proporciona el número de sentencias, en el
sentido definido por (Dagpinar & Jahnke,
2003) como extensión de la métrica
aplicada en (Lorenz & Kidd, 1994).
Tabla 7-3. Métricas de producto a aplicar en la evaluación de RS
El siguiente paso es medir la influencia de la aplicación de RS en el conjunto de
sistemas seleccionados. En la Tabla 7-4 se muestran las métricas de producto de cada uno de
los proyectos en dos partes. La columna de la izquierda muestra las métricas aplicadas sobre el
código original a mantener. La columna de la derecha muestra la variación en tanto por ciento
de dichas métricas después de la aplicación de RS.
Métricas ANTES de RS Variación de las Métricas con RS
Métricas/
Proyectos ACLOC AMLOC ∑NC ∑NM ∑NS %ACLOC %AMLOC %∑NC %∑NM %∑NS
PR 1 63,05 6,54 269 2590 16961 -29% -45% -33% -60% -71%
PR 2 40,71 6,88 530 3135 21581 -27% -66% -26% -14% -37%
PR 3 39,25 10,02 12 47 471 -21% -55% -8% -15% -33%
PR 4 32,94 5,43 34 206 1120 7% 22% -15% -45% -41%
PR 5 52,21 5,47 32 305 1671 25% 48% -31% -34% -17%
PR 6 44,11 7,30 27 163 1191 -3% -6% -7% -57% -58%
PR 7 36,08 7,46 12 58 433 -16% -45% 0% -15% -29%
PR 8 48,92 6,22 14 110 685 18% 36% 0% -25% -12%
PR 9 55,22 5,37 344 3534 18998 20% 36% -8% -48% -38%
PR 10 80,86 9,05 847 7568 68492 -33% -40% -4% -40% -60%
Tabla 7-4. Métricas de producto antes y después de RS
Los datos registrados muestran una disminución considerable del tamaño y
complejidad de los proyectos que, según los trabajos indicados anteriormente, debe
desembocar en una disminución importante del coste de mantenimiento de los sistemas. A
continuación se realiza un estudio más detallado de los resultados.
Tesis Doctoral Daniel Cabrero Moreno
203
7.3.3 Análisis de resultados
La opinión de los autores sobre la correlación entre las métricas de producto y el
esfuerzo de mantenimiento no es unánime. Dagpinar y Jahnke concluyen que el tamaño y el
acoplamiento (direct coupling) son los predictores más exactos del esfuerzo de mantenimiento,
en detrimento de las métricas relacionadas con la herencia (Dagpinar & Jahnke, 2003). Otros
resultados presentados (Fioravanti & Nesi, 2001), sin embargo, indican que la complejidad
ciclomática y el número de métodos y atributos son los predictores de esfuerzo más eficaces.
Por otro lado, validaciones llevadas a cabo (Misra, 2005) sugieren que la media de tamaño de
los métodos es el mejor indicador, y en otras ocasiones (Genero et al., 2007) se establece
como tal el número de asociaciones.
Como puede verse, los estudios sobre la utilidad y exactitud de los predictores de
mantenimiento varían dependiendo de los autores, de ahí la dificultad de cuantificar el retorno
de inversión de la aplicación de RS. Sin embargo, en general, los autores están de
acuerdo en que existe una correlación entre el tamaño y la complejidad y el coste
de mantenimiento.
En ese sentido, la ilustración de la utilidad de RS puede ser validado en función del
análisis de algunas métricas de tamaño simples, que en todos los estudios están altamente
correladas con otras métricas que indican el coste de mantenimiento (por ejemplo, con la
complejidad ciclomática (Fioravanti & Nesi, 2001), o con el acoplamiento directo (Dagpinar &
Jahnke, 2003)).
Se observa además una cierta correlación entre las distintas métricas de tamaño
utilizadas. Este hecho tiene una explicación simple: Si el número de métodos se reduce,
entonces el número de sentencias se reduce también. El número de métodos también está
relacionado con la media de métodos por clase y el número de sentencias por método,
influyendo ésta reducción de métodos en uno de los dos indicadores, y así sucesivamente.
Los resultados muestran una reducción muy significativa del tamaño del software,
que varía del 37% hasta el 70% para los proyectos 1, 2, 4, 6, 9 y 10. Es interesante
señalar que la mayoría de ellos corresponden a sistemas grandes (casi siempre sistemas
legados). Este hecho sugiere la necesidad de un estudio más detallado en lo referente a la
selección de proyectos a reducir, que podría estar basada en el tamaño, coste de
mantenimiento o antigüedad de los mismos.
Tesis Doctoral Daniel Cabrero Moreno
204
7.4 Aportaciones realizadas en este Capítulo
En este Capítulo se han realizado dos aportaciones fundamentales.
La primera aportación consiste la realización en la DGT de todas las tareas de
recolección de información que permitan validar el método genérico de aplicación de
valor “GVAL”. Dadas la longitud de las series temporales necesarias para la validación de los
conceptos de valor, se describe la infraestructura habilitada en la DGT para la recolección de
datos, y se describe el análisis a realizar cuando ésta concluya.
En segundo lugar, se analiza la viabilidad de la Reducción de Software,
mediante un experimento en el que se monitorizan las métricas de predicción de los costes de
mantenimiento software más comúnmente utilizadas. Los datos de aplicación de RS sobre
proyectos reales sugieren que, especialmente para proyectos legados grandes, RS puede ser
utilizado para optimizar los costes de mantenimiento de manera significativa.
Tesis Doctoral Daniel Cabrero Moreno
205
Capítulo 8 - Conclusiones
y trabajo futuro
8.1 Conclusiones generales
A lo largo de la presente Tesis Doctoral, se han realizado diversas aportaciones en el
campo de la Ingeniería del Software Basada en Valor inéditas hasta la fecha. La última sección
de cada capítulo resume en detalle estas nuevas propuestas.
La aportación más relevante es la sistematización de la aplicación de valor a través del
método GVAL. Las revisiones realizadas sobre la literatura revelan que el concepto de valor
es difuso, y que cada autor interpreta de un modo distinto para su aplicación a un nicho
concreto de la Ingeniería del Software. En este trabajo se plantea por primera vez la
ordenación de todas las posibles influencias y consecuencias de valor a través de un árbol de
indicadores y un árbol de tareas priorizables, que aglutinen respectivamente todas las posibles
influencias de los implicados y las acciones a llevar a cabo en consecuencia.
La revisión reveló también carencias en muchas áreas de ISBV. En este sentido, la
segunda aportación importante de este trabajo consiste en cubrir, a través de la utilización del
método GVAL, algunas carencias detectadas. Se debe resaltar entre ellas, la definición del
concepto de valor en diseño y mantenimiento software, así como la ejemplificación de la
aproximación mediante diversos casos de utilización. En el caso del mantenimiento, y dada la
gran influencia que tiene sobre los costes asociados al funcionamiento de los sistemas
software, se propone además crear un área de conocimiento específica de Mantenimiento
Software Basado en Valor, no detectada por Boehm en su hoja de ruta.
También mediante la utilización de GVAL, y mediante la definición de tareas priorizables
que abarcan todos los aspectos de la Ingeniería del Software, se ha llevado a cabo la
priorización basada en valor de otros nichos definidos por Boehm, pero no abordados por
ningún trabajo hasta la fecha: El control y planificación y la gestión de riesgos.
La aplicabilidad de las propuestas ha sido mostrada mediante la ejecución de casos de
utilización para cada uno de los nuevos conceptos propuestos en esta Tesis Doctoral. En
particular, la validación una nueva técnica llamada Reducción de Software (tarea priorizable
de mantenimiento perfectivo basado en valor), ha sido validada utilizando proyectos reales
llevados a cabo en la Dirección General de Tráfico.
Tesis Doctoral Daniel Cabrero Moreno
206
8.2 Análisis de la Consecución de Objetivos
El objetivo general que se planteó en el primer capítulo de este trabajo, y que se recoge
en la sección 1.2, fue el de:
Para ello se plantearon una serie de sub-objetivos cuya consecución analizamos a
continuación.
OBJETIVO CONSECUCIÓN
Objetivo 1. Estudiar el estado del
arte y propuestas de la Ingeniería del
Software Basada en Valor. Identificar
nichos de investigación potenciales.
En el 0 se ha introducido la ISBV (2.2), y se ha desarrollado
un estudio pormenorizado del estado del arte en lo
referente a la Ingeniería del Software Basada en Valor (2.3).
Se ha resumido la información obtenida de manera
esquemática (2.4), y a partir de dicha información, se han
identificado las líneas de investigación abordadas en esta
Tesis Doctoral (2.5).
Objetivo 2. Definir el concepto de
“técnica basada en valor”, y proponer
una serie de requisitos mínimos que
una técnica debe tener para
considerarse basada en valor.
En el Capítulo 3 se introduce a través de ejemplos los
elementos comunes a todas las técnicas de valor (3.2), se
identifican y definen los Indicadores de Valor, las Tareas
Priorizables y los Valores Límite (3.3).
Objetivo 3. Proponer un método
sistemático de aplicación de valor que
permita la combinación de las
distintas técnicas.
También en el Capítulo 3, se presenta un método
genérico de aplicación de valor –GVAL-, y se muestra
su aplicación a través de un ejemplo (3.4). La técnica
propuesta es utilizada para combinar indicadores y tareas
priorizables pertenecientes a distintas técnicas encontradas
en la literatura (3.4). Se ha elaborado también un cuadrante
que especifica qué indicadores y tareas usan los distintos
trabajos encontrados en la literatura (3.5). De este modo, la
combinación de trabajos es automática, mediante la
elección de un grupo concreto de indicadores y tareas.
Proponer un conjunto de técnicas sistemáticas para llevar
a cabo la construcción y evolución del software teniendo
en cuenta el valor que las decisiones de diseño aportan a
los distintos stakeholders
Tesis Doctoral Daniel Cabrero Moreno
207
Objetivo 4. Proponer técnicas para la
aplicación práctica del Diseño
Software Basado en Valor.
En el 0 se introduce por primera vez el concepto de valor
en diseño, y se acuña el término Diseño Software
Basado en Valor (4.2), se analizan los indicadores y tareas
priorizables a utilizar con el método GVAL para
implementarlo (4.3), y se lleva a cabo un ejemplo de toma
de decisiones de diseño basadas en valor (4.4). Es
importante resaltar que el DSBV es un caso particular del
método GVAL.
Objetivo 5. Proponer técnicas para la
aplicación práctica del Mantenimiento
Software Basado en Valor.
En el Capítulo 5 se introduce otro concepto inédito en la
literatura: el Mantenimiento Software Basado en Valor
(5.2). Se identifica una serie de tareas priorizables e
indicadores específicos de mantenimiento (5.4), y se aplica
el método GVAL. Se introduce además una tarea inédita
hasta ahora en mantenimiento perfectivo: La Reducción de
Software, que permite optimizar los costes y recursos
(5.3). Se estudia la aplicación de GVAL al mantenimiento
(5.4). Finalmente se lleva a cabo sendos ejemplos de
utilización de todos los conceptos presentados (5.5).
Objetivo 6. Desarrollar herramientas
que faciliten la aplicación de las
técnicas y principios basados en valor.
La automatización de los conceptos y técnicas presentados
en esta Tesis Doctoral han sido discutidos en el Capítulo 6.
Se presenta la herramienta GVAL-EX de automatización de
los pasos de GVAL a través de Excel (6.2), se describen los
desarrollos realizados para controlar la priorización de tareas
y recogida de datos (6.3), y se describe la utilización de
herramientas para la recogida de la frecuencia de uso (6.4).
Objetivo 7. Validar los conceptos y
técnicas presentados.
En el Capítulo 7 se analiza la problemática de validaciones
de técnicas basadas en valor. Se clasifican los tipos de
validaciones llevados a cabo (7.1), y se plantea el escenario
de validación de GVAL con proyectos reales desarrollado
en colaboración con la DGT (7.2). Para ello se describe la
infraestructura de recogida de datos habilitada actualmente,
y se propone un análisis de resultados a realizar en un
futuro. Al margen de la validación genérica, se contrasta la
viabilidad de la Reducción de Software (7.3).
Tabla 8-1. Consecución de Objetivos.
Tesis Doctoral Daniel Cabrero Moreno
208
8.3 Contraste de Resultados
A continuación se muestran las publicaciones realizadas en diversos foros científicos
nacionales e internacionales. El contenido de cada una de las publicaciones, así como la
relación que dicho contenido tiene con todos los conceptos y técnicas introducidos en esta
Tesis Doctoral puede ser también consultado a lo largo de esta sección.
8.3.1 Capítulos de Libro
GARZÁS, J., CABRERO, D. & PIATTINI, M. (2007) El valor y el retorno de inversión de
las TSI. Gobierno de las Tecnologías y Sistemas de Información. Madrid, España, RA-MA.
8.3.2 Conferencias Nacionales
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007) Técnica de Mantenimiento Software
Basada en Valor. Congreso Español de Informática - Jornadas de Ingeniería del Software y
Bases de Datos (CEDI`07- JISBD’07). Zaragoza (Spain). [Ratio de aceptación del 36%
(32/87), artículo largo (págs. 317-325)]
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2008) Priorización del Valor de Artefactos
Software Basada en la Frecuencia de Uso. Jornadas de Ingeniería del Software y Bases de
Datos (JISBD'08). Gijón, Spain. [Ratio de aceptación del 25%, artículo largo (págs.
183-194)]. PREMIO A BEST PAPER SELECCIONADO PARA SU PUBLICACIÓN EN LA
REVISTA IEEE AMÉRICA LATINA (ver referencia más abajo).
8.3.3 Conferencias Internacionales
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007) Maintenance Cost of a Software
Design. A Value-Based Approach. 9th International Conference on Enterprise Information
Systems (ICEIS). Funchal, Madeira. Portugal. [Ratio de aceptación del 65%, artículo
corto (págs. 384-389)]
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007) Understanding Software Product
Lines through Design Patterns. 2nd International Conference on Software and Data
Technologies (ICSOFT’07). Barcelona (Spain). [Poster]
Tesis Doctoral Daniel Cabrero Moreno
209
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007) Choosing the best design strategy
from requirements: A value-based approach. 1st IEEE Computer Society Conference on
Exploring Quantifiable Information Technology Yields. Amsterdam, IEEE Computer Society.
[Ratio de aceptación para su publicación de entre los expuestos en la conferencia
del 57% (11/19), artículo largo (PENDIENTE DE PUBLICACIÓN)]
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2008) Combining Different Change
Prediction Techniques. 10th International Conference on Enterprise Information Systems
(ICEIS). Barcelona (Spain). [Ratio de aceptación del 9,3% (62/665), artículo largo
(págs. 57-63)].
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2008) Object Oriented Design Rules.
Definition and Automatic Detection. Conference on Quality Engineering in Software Technology
(CONQUEST'08). Berlin, Germany. [Ratio de aceptación del 45% (27/60), Artículo largo
(págs. 81-94)]
8.3.4 Revistas Nacionales
GARZAS, J., CABRERO, D. & PIATTINI, M. (2007) La Ingeniería del Software Basada
en Valor. CUORE-Circulo de Usuarios de Oracle de España, 34, 3 -12.
8.3.5 Revistas Internacionales (pendientes de evaluación)
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2009) Value-Based Maintenance: Improving
Software Maintainability through Automated Adaptive Reduction. Journal of Software
Maintenance and Evolution. Enviado para su evaluación.
PUBLICACIÓN IEEE AMÉRICA LATINA SELECCIONADO EN JISBD 2008 ENTRE LOS 4
MEJORES PAPERS. Aceptado y pendiente de publicación. CABRERO, D., GARZÁS, J. &
PIATTINI, M. (2009) Priorización del Valor de Artefactos Software Basada en la Frecuencia de
Uso. IEEE América Latina.
Tesis Doctoral Daniel Cabrero Moreno
210
8.3.6 Evolución de la propuesta a lo largo del proceso de
investigación
En esta sección se describirá la evolución cronológica de las distintas propuestas
presentadas, así como su contraste a través de los distintos trabajos que han ido publicándose
en los diversos foros de investigación.
Las propuestas se dividen en tres ejes principales: El Diseño Basado en Valor, el
Mantenimiento Basado en Valor, y la aplicación sistemática a través de GVAL de los conceptos
de valor al ámbito de la Ingeniería del Software. En este contexto, las siguientes secciones
presentarán la evolución cronológica de los trabajos publicados, que finalmente desembocaron
en los contenidos presentados en esta Tesis Doctoral.
8.3.6.1 Concepto de valor y estado del arte
Los trabajos comenzaron con la realización de una primera revisión sistemática de
los trabajos realizados en el ámbito de la Ingeniería del Software Basada en Valor (ISBV). Los
resultados de la búsqueda fueron presentados en el Diploma de Estudios Avanzados (DEA). Se
realizó una síntesis de las propuestas relacionadas con el valor, que desvelaba que había un
área donde ningún trabajo había sido presentado: El área de diseño y desarrollo software.
Sobre el trabajo de búsqueda y síntesis previo, se realizaron unas primeras
publicaciones. En el Capítulo 3 del libro de Gobierno de Sistemas y Tecnologías de la
Información (Garzás et al., 2007), se plantean desde un punto de vista divulgativo los
indicadores económicos de Retorno de Inversión (ROI), coste-beneficio y productividad (pilares
básicos de la aplicación de valor), y se presentan los objetivos de la ISBV.
En otra publicación realizada en el Circulo de Usuarios de Oracle “CUORE” (Garzas et al.,
2007) se exponen los resultados de la revisión de literatura realizada. Se presentan los
conceptos básicos de ISBV introducidos por Barry Boehm, se realiza una comparativa entre la
IS convencional y la ISBV, y se clasifican los distintos trabajos presentados hasta 2007 en
relación con las áreas de conocimiento propuestas en ISBV.
La clasificación presentada en el estado del arte presentada en CUORE es la primera
versión del contenido que fue posteriormente actualizada en 2009 para la elaboración del
estado del arte de esta Tesis Doctoral.
En esta primera etapa, se identificó la oportunidad de mejora de la aplicación de valor al
diseño software, que fue desarrollándose posteriormente, y que se comenta en la siguiente
sección.
Tesis Doctoral Daniel Cabrero Moreno
211
8.3.6.2 Diseño Software Basado en Valor
8.3.6.2.1 Primeras propuestas: Flexibilización de los Diseños
En el ámbito del proyecto IDONEO, que pretende estudiar la relación entre las Líneas de
Producto Software (LPS) y la ISBV, se planteó el estudio de la utilización de elementos de
diseño software realizada en la literatura para modelar la variabilidad entre los distintos
miembros de una familia de producto similares.
El trabajo resultante, publicado posteriormente en (Cabrero et al., 2007d), realiza una
revisión sistemática sobre los elementos de diseño comúnmente utilizados para modelar la
variabilidad. Los resultados se muestran a continuación, con el número de autores que usan
cada elemento de diseño entre paréntesis:
Abstract Factory (7)
Singleton (3)
Mediator (2)
Null Object (2)
Proxy, Command, Adapter, Interpreter, Message Redirector, Strategy, Service
Abstraction Layer, Command Processor, Replace If with Inheritance. (1)
Los patrones de diseño son utilizados por los distintos autores para introducir
indirecciones o puntos de variabilidad, que será el principio en el que se basará la propuesta de
valor en diseño realizado posteriormente.
En la literatura (Bockle et al., 2004) pueden además encontrarse análisis del Retorno de
Inversión de la utilización de LPS. El coste de construcción y mantenimiento de los sistemas es
un elemento importante de la orientación a valor, sin embargo, todavía existía el problema de
generalizar los análisis de coste-beneficio para su utilización en la evaluación de cualquier
diseño.
La generalización de la evaluación de diseños realizada para algunos casos concretos se
propuso a través de la realización de mejoras de diseño. Para ello, era llevar a cabo una
revisión de los modos de localizar las ubicaciones donde una indirección o mejora de diseño
puede ser realizada. Las reglas de diseño y codificación son la alternativa sobre la que se basó
el concepto de valor en diseño, y el estado del arte en la detección y automatización de las
mismas fue presentado en (Cabrero et al., 2008b).
Como propuesta de innovación en lo referente a las reglas existentes, se clasifica todo el
conjunto de reglas encontradas en cuatro categorías: de arquitectura, de diseño, basadas en
API, y de codificación. Se propone utilizar cada tipo de regla en una fase distinta del desarrollo,
para localizar las mejoras de diseño lo antes posible, y optimizar así el retrabajo necesario para
corregirlas. La Ilustración 8-1 muestra el concepto.
Tesis Doctoral Daniel Cabrero Moreno
212
Ilustración 8-1. Distintos tipos de reglas y su momento de aplicación (Cabrero et al., 2008b)
8.3.6.2.2 Creación del Diseño Basado en Valor
El término “Diseño Software Basado en Valor” fue introducido en (Cabrero et al.,
2007a). Según esta propuesta, se propone guiar la aplicación de reglas de diseño a través de la
probabilidad de cambio y la importancia relativa de cada artefacto involucrado en la violación
de dichas reglas. La estimación del coste asociado a cada mejora de diseño fue también
introducido en esta publicación. La Ilustración 8-2 muestra el concepto.
Ilustración 8-2. Reglas de diseño según probabilidad de cambio e importancia (Cabrero et al., 2007a)
En un trabajo posterior (Cabrero et al., 2007b) se presentaron dos técnicas que tenían
por objeto el cálculo de la probabilidad de cambio y la importancia, necesarias para la
implementación de aquella primera aproximación de diseño basado en valor. Para el cálculo de
la probabilidad de cambio se proponía una técnica llamada CORT (Change Oriented
Requirement Tracing), que estimaba la probabilidad de cambio en función de la opinión de
los implicados y trazaba dichas probabilidades a los artefactos de diseño. La trazabilidad de
Tesis Doctoral Daniel Cabrero Moreno
213
requisitos a diseño es también utilizada en (Cabrero et al., 2007c) para estimar la importancia
relativa de los distintos artefactos de diseño.
La elicitación de la opinión de los implicados, en este caso de la probabilidad de cambio
y la importancia, y su posterior trazado a los artefactos de diseño es la base del diseño basado
en valor, son la base que posibilita el diseño y mantenimiento basados en valor. Los criterios de
valor aplicados a artefactos de código y diseño fueron utilizados por primera vez en dicho
trabajo.
En (Cabrero et al., 2008a) se propone otra técnica alternativa de estimación de la
probabilidad de cambio. En dicho trabajo, se realiza una revisión del estado del arte y se
propone una técnica llamada AHCP (Automatic Heterogeneous Change Prediction).
AHCP tiene por objeto poder combinar distintos indicadores de probabilidad de cambio,
extraídos a gracias a la utilización de técnicas distintas. Las distintas predicciones de cambio
son ponderadas con arreglo a pesos. La Tabla 8-2 muestra los distintos selectores de cambio,
correspondientes a las distintas técnicas de predicción de cambio presentadas en el ANEXO I.
Las distintas métricas pueden ser parametrizadas a través de variables.
Trabajo Previo Selector de Cambio Variables
Histórico Número de cambios por versión > M M = Núm. de Cambios
CORT Probabilidad obtenida < N N = Límite.
Ejes de cambio (Tsantalis et al.,
2005)
Probabilidad obtenida < N N = Límite.
CS (Class Size) Clases mayores de N Kb N = Tamaño in KB
CBO(Coupling) La clase está acoplada al menos con otras
N clases
N = Núm. de clases
NOO (Núm. de métodos) Todas las clases deben contener al menos
N métodos
N = Núm. de métodos
Refactorings Sentencia Switch o If con más de N
sentencias
N = Núm. de sentencias
Tabla 8-2. Selectores de cambio de AHCP (Cabrero et al., 2008a)
La técnica pretende identificar una serie de artefactos propensos al cambio. Por ejemplo,
existe un selector que marca todas las clases mayores de un tamaño dado. Se llama selector
porque “selecciona” dichas clases de acuerdo a ese criterio.
Incluso si los arquitectos conocen la existencia de las distintas técnicas deben elegir cuál
aplicar a su caso concreto, para lo cual no existe ninguna propuesta, limitándose estas a
pruebas de efectividad sobre pequeños sistemas de código abierto. En este trabajo se propone
analizar la efectividad de cada una de las técnicas utilizando versiones anteriores. La simulación
de aplicación señalará las técnicas más apropiadas para el caso concreto, y se podrán aplicar
dichos criterios a las siguientes versiones. Adicionalmente se extraen los pesos de cada una de
las clases, en base a los resultados obtenidos en la simulación.
La Tabla 8-3 muestra un ejemplo de parametrización de la técnica extraída de un
histórico.
Tesis Doctoral Daniel Cabrero Moreno
214
Selector Límite Peso
Histórico Cambios = 3 0,5
CORT Límite = 0,6 0,3
Ejes de Cambio Límite = 0,3 0,2
Tabla 8-3. Ejemplo de aplicación de AHCP (Cabrero et al., 2008a)
AHCP es una aplicación de distintos indicadores llamados selectores de cambio, que
posteriormente evolucionaría en el método GVAL cuando se comenzaron a añadir otros tipos de
indicadores distintos a los de probabilidad de cambio.
8.3.6.3 Mantenimiento Software Basado en Valor
El concepto de Reducción de Software basado en la frecuencia de utilización de los
artefactos de código y diseño fue introducido por primera vez en (Cabrero et al., 2008c). En
este trabajo se presentan por primera vez todos los razonamientos de optimización de valor en
mantenimiento, así como los ejemplos explicativos expuestos a lo largo de este trabajo. Este
trabajo fue seleccionado como uno de los 4 mejores trabajos presentados en JISBD 2008, y
consecuentemente modificado y publicado en la revista internacional IEEE América Latina
(Cabrero et al., 2009a).
El caso de estudio de análisis de la reducción del coste de mantenimiento sobre los
proyectos de la DGT presentado en el capítulo de validaciones fue a su vez introducido en una
publicación posterior (Cabrero et al., 2009b).
8.3.6.4 GVAL: Generalización de la aplicación de valor
Todos los conceptos de reglas de diseño, probabilidades de cambio, importancia, valor
en diseño y mantenimiento, han sido refundidos para que todas las técnicas e indicadores
pudieran ser combinables en entornos industriales. La propuesta de método llamado GVAL, así
como los árboles de indicadores y tareas priorizables, han sido recientemente enviados para su
evaluación.
En esta propuesta se analizan los distintos trabajos encontrados en la literatura en el
ámbito de la aplicación de valor, y se clasifican con arreglo a indicadores, tareas y valores
límite. Algunos ejemplos de aplicación de la misma son también presentados en este trabajo.
GVAL generaliza la aplicación de todos los demás conceptos. Como puede verse, el
proceso de creación del marco de valor se ha comenzado por casos concretos, para
posteriormente crear una técnica de aplicación y combinación de los mismos que fuera válida
para todos ellos.
Tesis Doctoral Daniel Cabrero Moreno
215
8.4 Líneas Futuras del Trabajo de Investigación
La aplicación de valor tiene un carácter transversal a todos los aspectos de la Ingeniería
del Software. Por este motivo, son muchas las vías de investigación que pueden basarse en las
conclusiones aportadas en este trabajo.
8.4.1 Aspectos genéricos relacionados con el valor
En primer lugar, se puede extender la definición inicial de indicadores y tareas
priorizables sobre los que se articula la ejecución de GVAL, plasmados en los árboles de
indicadores (página 81) y tareas priorizables (páginas 84 y 88). Es posible crear nuevas ramas,
nuevas maneras de priorizar tareas, o incluso nuevos árboles, que permitan adaptar la
ejecución de GVAL a casos no contemplados en esta versión inicial.
El método GVAL está actualmente pensado para que el ingeniero de software elija una
serie de tareas a priorizar para su caso concreto, normalmente aquellas que aportan mayor
valor o son más costosas. Para adaptar GVAL a un tipo de proyecto concreto es necesario tener
un conocimiento detallado de los indicadores y tareas disponibles, y evaluar qué opciones son
más relevantes para el caso concreto. En esta línea, un posible trabajo futuro a realizar con
objeto de extender la aplicación de valor a no expertos en la materia, sería posible definir un
conjunto básico de proyectos tipo, donde la fase de definición estuviera ya realizada, y
únicamente se aplicara en función de manera automatizada.
Respecto a la validación de las propuestas de esta Tesis Doctoral, un aspecto
importante sería evaluar GVAL una vez esta haya sido probada en un número considerable de
proyectos reales. La sección 7.2 describe los pasos a seguir y el método de análisis de los datos
obtenidos mediante la infraestructura ya implantada. Ya se apuntó entonces los horizontes
temporales de varios años de implantación y mejora en organizaciones reales que son
necesarias para poder obtener datos de validación fiables. Debido a la especial dificultad y
requerimiento de tiempo de las validaciones de aspectos basados en valor, se plantea el
análisis de los resultados encontrados como trabajo futuro.
Tesis Doctoral Daniel Cabrero Moreno
216
8.4.2 Planificaciones de tareas priorizables
La creación y utilización en el ámbito de la ISBV de planificaciones, que reflejen la
priorización de tareas elicitada a través del valor, es un ámbito de investigación especialmente
interesante. Esto es debido a la importancia que los tiempos de disponibilidad de los sistemas
suelen tener para los distintos implicados.
La idea es que en el marco del desarrollo de software nuevo, GVAL establece que las
distintas tareas a realizar se ejecuten de manera más exhaustiva, menos exhaustiva, o no se
ejecuten. La ejecución de los distintos escenarios implica la aplicación o no de distintas tareas
priorizables, en función del coste que se esté dispuesto a asumir.
El resultado de la aplicación de las tareas priorizables repercute, además de en el
coste, en el plazo en el que una funcionalidad está disponible. La asociación entre los
indicadores relacionados con la urgencia y las tareas priorizables, asegura que las
funcionalidades más urgentes se implementen antes. Una estimación de los ahorros de coste
de alto nivel de las distintas opciones disponibles puede ser realizada (como por ejemplo la que
se muestra en la Ilustración 3-18, página 102).
Sin embargo, posteriormente, una vez elegido uno de los escenarios de aplicación, el
ingeniero de software debe generar una planificación detallada de la ejecución de las tareas
que deban ser aplicadas, que pueden variar según los principios de valor. Adicionalmente, es
posible que el valor que el software aporte a la organización varíe en función de las fechas de
disponibilidad del mismo. Sería conveniente estudiar la influencia que las implicaciones de valor
tienen en las planificaciones, y a su vez, la influencia que las planificaciones tienen sobre las
implicaciones de valor.
Un posible modo de resolver esta incógnita podría ser la creación de planificaciones
de manera automática, previa investigación teórica sobre los aspectos comentados.
Partiendo de una planificación estándar que comprende todos los recursos necesarios para
implementar todas las tareas, se podrían eliminar las tareas priorizables prescindibles, con lo
que los horizontes temporales podrían variar de puesta a disposición de las funcionalidades. La
importancia de la automatización reside en que según los implicados proporcionen sus criterios
de valor, podríamos instantáneamente obtener las tareas priorizables, y una planificación
estimativa de los tiempos necesarios para ser llevados a cabo. La retroalimentación “in situ”
que una adecuada automatización proporciona es en este caso clave para dar visibilidad a este
aspecto generalmente tan importante para los implicados.
Para automatizar el proceso expuesto es necesario, bien integrar el conjunto de tareas
priorizables con una herramienta de planificación de proyectos, bien desarrollar a medida un
software capaz de estimar la fecha de inicio y fin de cada tarea que tenga en cuenta la
supresión de tareas prescindibles con arreglo a las consideraciones de valor, y que estime los
recursos (temporales y humanos) necesarios para acometerlas.
Tesis Doctoral Daniel Cabrero Moreno
217
8.4.3 Identificación de automatizaciones futuras
8.4.3.1 Ampliación de GVAL-EX
Para los ejemplos expuestos a lo largo de exposición, se ha utilizado una hoja Excel que
permite automatizar algunos pasos de GVAL. Sin embargo, para su aplicación en proyectos
reales, sería recomendable desarrollar una aplicación web o de escritorio que soportase los
últimos pasos de soporte a la decisión que no son cubiertos con la hoja de cálculo, a la vez que
proporcionasen una interfaz más amigable y sencilla de utilizar.
Por otro lado, un desarrollo dedicado podría dar respuesta a una funcionalidad más
amplia, con objeto de facilitar la aplicación de la metodología. A continuación, en las siguientes
subsecciones, se proponen algunas funcionalidades que sería interesante que proporcionase
una herramienta de soporte a la aplicación de valor.
8.4.3.2 Propuesta de Herramienta de RS: JMERES
Una vez que la frecuencia de utilización de cada método está disponible (en este caso,
a través de EMMA), el borrado lógico y la vuelta atrás pueden ser automatizados también. En
este caso, debido a la tarea específica a implementar, no se ha encontrado ninguna solución en
el mercado que pudiese automatizar, total o parcialmente, la funcionalidad requerida. Por este
motivo se plantea el desarrollo de JMERES (J2EE - MÉtodo de REduccción de Software).
JMERES tiene por objeto automatizar los pasos planteados por RS. Una interfaz gráfica
tentativa de JMERES se presenta a continuación.
Como puede observarse en la Ilustración 8-3, la interfaz gráfica define cuatro pasos. En
el primer y segundo paso se definen los límites de aplicación, y se importan los indicadores de
actividad de cada uno de los artefactos. El tercer paso ejecuta el borrado lógico sobre los
artefactos indicados por los límites de valor. El cuarto paso ejecuta la vuelta atrás.
La herramienta importaría los datos de actividad desde EMMA, que es capaz de
generar ficheros de intercambio XML, y realizaría las refactorizaciones de la manera que se
plantea en la metodología descrita en el punto 5.3.
Tesis Doctoral Daniel Cabrero Moreno
218
Ilustración 8-3. Adaptación de los límites de valor para el mantenimiento perfectivo
8.4.3.3 Automatización de extracción de indicadores objetivos
Del mismo modo que en la sección 6.3 se planteaba la extracción automatizada de la
frecuencia de uso de los artefactos de código, sería conveniente ahondar en la manera de
recuperar otros indicadores objetivos identificados en este trabajo. El número y escalado de las
incidencias, la propensión al fallo, o la frecuencia de cambio podrían ser recogidos de manera
automatizada, del mismo modo que se ha llevado a cabo para la frecuencia de uso.
Tal y como propone el Mantenimiento Software Basado en Valor, todos estos indicadores
serían de gran utilidad para guiar un mantenimiento efectivo y orientado al valor real de las
organizaciones.
Tesis Doctoral Daniel Cabrero Moreno
219
ANEXO I - Técnicas
auxiliares de soporte al
cálculo del valor
I.i. Técnicas auxiliares de soporte al cálculo del
valor
El presente anexo a la Tesis Doctoral tiene por objeto presentar una serie de técnicas
que son utilizadas en la aplicación de las propuestas basadas en valor introducidas en el
documento principal. Todas las técnicas que se proponen en este documento son utilizadas en
el ámbito de la aplicación de valor, pero pueden ser utilizadas igualmente en muchas otras
áreas de Ingeniería del Software. Por este motivo, y para mejorar la claridad de la exposición
del documento principal, se presentan de forma separada.
En primer lugar (sección I.ii), se introducen las reglas de diseño y codificación en
desarrollos orientados a objetos. Las reglas son utilizadas en el ámbito del Diseño Software
Basado en Valor propuesto en esta Tesis Doctoral para localizar mejoras de diseño, que
posteriormente serán priorizadas en función del valor que dichas mejoras pueden aportar.
También se discute la automatización de la localización de reglas.
En segundo lugar, se analiza la predicción de una serie de características que guiarán el
proceso de Mantenimiento Basado en Valor propuesto en el documento principal. Se trata de la
probabilidad de cambio (sección I.iii), la probabilidad de uso (sección I.iv), y la propensión al
fallo (sección I.v). Estos indicadores aplican sobre los sistemas ya desarrollados.
Finalmente, se analizan las distintas opciones de trazabilidad de requisitos a diseño
existentes actualmente (sección I.vi). La trazabilidad es utilizada en el marco de este trabajo
para trasladar indicadores de valor subjetivos desde los requisitos a los artefactos de diseño.
El objetivo de estas revisiones, no centradas exclusivamente en la Ingeniería del
Software Basado en Valor, no es la localización de nichos de investigación potenciales, sino la
correcta comprensión de las propuestas realizadas en el documento principal. Cada técnica de
estimación es revisada de forma breve con el propósito de resumir sus características y tipos
de aplicación más importantes.
Tesis Doctoral Daniel Cabrero Moreno
220
I.ii. Reglas de Diseño y Codificación Orientadas a
Objetos
Hace más de 20 años, Giddings y Colburn introdujeron un conjunto de reglas de diseño
y codificación para el paradigma estructurado (Giddings & Colburn, 1984), que debían
cumplirse para asegurar la mantenibilidad del software. Según este trabajo, un diseño de
calidad debe cumplir dicho conjunto de reglas para asegurar la mantenibilidad del mismo.
La aplicación de reglas de diseño a los sistemas estructurados primero, y a sistemas
orientados a objetos después, ha continuado con el transcurso de los años. En la última década
ya completamente centrados en los sistemas orientados a objetos.
Las propuestas de reglas de diseño y codificación, tanto en lo concerniente a los foros
de investigación como a su aplicación práctica en la industria del software, son analizadas a
continuación.
I.ii.i. Reglas de Diseño versus Reglas de Codificación
Un aspecto importante a definir es la diferencia entre reglas de “codificación” y
reglas de “diseño”. Se trata de reglas de un nivel de abstracción distinto, aunque la gran
mayoría de las herramientas que las soportan equivocan su significado y las presentan como
un todo.
Una regla de diseño debe ser independiente de implementación. Por ejemplo, una regla
que asegure el correcto uso de un operador en un lenguaje de programación concreto es una
regla de codificación, no una regla de diseño, porque es dependiente del tipo de lenguaje que
se utilice, y únicamente pueden ser evaluadas una vez que existe el código.
Además, son reglas de “diseño” aquellas que se basan en información disponible en
fase de diseño, cuando la codificación todavía no ha comenzado. Normalmente el
incumplimiento de reglas de diseño revela defectos profundos del sistema, que típicamente
necesitan de una cantidad más grande de trabajo para ser reparadas que en el caso de las
reglas de codificación.
Por tanto, a lo largo de este trabajo se usará el término de regla de “diseño” para
determinar aquellas reglas cuyo incumplimiento puede ser detectado y corregido en fase de
diseño, en oposición a las reglas de “codificación”, que deben ser detectadas sobre el código.
La definición de un conjunto de reglas que guíe el diseño y desarrollo software es
importante, pero no lo es menos la automatización de su comprobación. El software de análisis
automatizado de reglas tiene por objeto que el cumplimiento de las reglas sea aplicable al
Tesis Doctoral Daniel Cabrero Moreno
221
trabajo diario de los diseñadores y programadores en un entorno industrial de desarrollo
software. Una vez automatizada la comprobación del conjunto de reglas, el modo más rápido y
barato de aseguramiento de la calidad es detectar automáticamente incumplimientos, también
llamados “violaciones” de reglas.
Una vista rápida de estado actual de las herramientas disponibles en el mercado indica
que la mayoría de dichas reglas están centradas en la codificación, ayudando a los
programadores a usar los recursos de un lenguaje concreto apropiadamente. Muy pocas reglas
basadas en heurísticas, principios o malos olores son automatizadas a través de herramientas.
El estado del arte actual se centra en “detectar defectos, código no referenciado o errores de
sintaxis. Dichas herramientas se enfocan a problemas de código, pero no examinan defectos de
más alto nivel” (Moha et al., 2006). El mismo autor, en (Moha, 2007) señala que “los defectos
de diseño no han sido especificados de manera precisa, y hay muy pocas herramientas
apropiadas que permitan su detección y corrección”. Aunque los trabajos de Moha y algunos
otros (Marinescu, 2004) atacan este problema, se hace necesaria una mejor conexión entre
aquellos que implementan las herramientas, y la comunidad de investigación en lo referente a
la categorización y detección de incumplimientos de reglas de diseño.
El estado del arte actual muestra una utilización muy común de análisis de reglas de
codificación, pero la casi total inexistencia de aplicación de reglas de diseño. Murphy-Hill y
Black publicaron un interesante estudio donde se contabilizaban las refactorizaciones (Fowler,
1999) más utilizadas por un grupo de estudiantes. Las refactorizaciones están estrechamente
ligadas a la corrección de incumplimientos de buenas prácticas, que son definidas a través de
reglas. En el estudio concluyen que las herramientas de refactorización están infrautilizadas
(Murphy-Hill & Black, 2008). Un análisis detallado muestra además que dicha infrautilización es
más acusada a nivel de diseño, ya que las refactorizaciones de código son con mucho las más
utilizadas.
I.ii.ii. Fuentes de reglas de diseño y código
Existen dos fuentes principales de reglas de diseño y código; la literatura de
investigación que puede ser consultada en conferencias y revistas, y el conjunto de
herramientas disponible en el mercado. Ambas son analizadas en los siguientes párrafos.
Con respecto a la bibliografía de investigación, durante muchos años los autores
han señalado la necesidad de clasificar el conocimiento disponible en cada disciplina, y
organizarlo en nichos de conocimiento, también llamados “chunks” (Shaw, 1990). En lo
referente a las mejores prácticas del desarrollo software, y siguiendo dicha filosofía, Garzas y
Piattini propusieron una ontología basada en reglas que tenía por objeto agrupar el
conocimiento previo en Orientación a Objetos en forma de reglas (Garzás & Piattini, 2005).
Dicho trabajo incluía heurísticas (Riel, 1996), patrones (Gamma et al., 1995), principios (Martin,
1996, Pescio, 1997), refactorizaciones y malos olores (Fowler, 1999). Todos ellos muestran
problemas que pueden existir en el desarrollo en forma de reglas. La Tabla 4-1 muestra
algunas reglas extraídas de dicho trabajo:
Tesis Doctoral Daniel Cabrero Moreno
222
Regla Efecto
SI Hay dependencias de clases concretas
ENTONCES Hacer que estas dependencias sean de
abstracciones.
La regla recomienda no depender de cosas concretas
ya que los cambios en aspectos concretos de las
clases servidoras tendrían impacto en las clases
clientes
SI en ejecución un objeto tiene diferente comportamiento
según su estado
ENTONCES Colocar cada uno de estos comportamientos en
una clase separada.
La regla recomienda colocar cada rol en una clase, lo
que minimiza el impacto de ampliar o variar estos
comportamientos.
SI una Súper Clase Conoce a Alguna de sus Subclases
ENTONCES Eliminar ese conocimiento.
La regla recomienda eliminar este conocimiento, que
claramente limita los cambios basados en
polimorfismo.
SI una Clase Colabora con Muchas
ENTONCES Reducir el número de colaboraciones.
La regla recomienda reducir este número de
colaboraciones, ya que el impacto de un cambio
tendría demasiados efectos.
SI Un Cambio en una Interfaz Impacta en Muchos Clientes
ENTONCES Crear interfaces específicas para cada cliente.
La regla recomienda crear varias interfaces, una por
cada necesidad concreta de cliente, evitando que un
cambio afecte a todos los clientes.
SI entre una Interfaz y su Implementación no hay una
Abstracción
ENTONCES Crear una clase abstracta con una
implementación por defecto entre la interfaz y la clase que la
implementa.
La regla recomienda introducir una abstracción por
defecto, para evitar duplicar código en las clases hijas
y evitar el impacto que esto tiene a la hora de hacer
modificaciones.
SI una Súper-clase es Concreta
ENTONCES Reestructurar para eliminarla.
La regla recomienda eliminar las clases concretas, ya
que estas tienen estrategias demasiado concretas que
pudieran tener que rechazarse por futuras subclases.
SI un Servicio Tiene Muchos Parámetros
ENTONCES Crear varios métodos, reduciendo la lista o pasar
un objeto.
La regla recomienda tener listas de parámetros ya que
en futuras modificaciones futuros usuarios de estos
servicios pudieran no conocer o no necesitar estos
parámetros, siendo preferible más servicios con
menos parámetros.
SI Una clase es grande
ENTONCES Reducir su tamaño repartiendo funcionalidad en
otras clases.
La regla recomienda dividirla, ya que cambios en
partes afectarían al todo de manera innecesaria.
SI Una Clase Rechaza algo de lo que hereda
ENTONCES Evitarlo, generalmente cambiando la herencia
por delegación.
La regla recomienda reestructurar la jerarquía ya que
las modificaciones en estas clases que rechazan lo
que heredan son complejas.
SI los datos de una clase son públicos o protegidos
ENTONCES Hacer estos privados y acceder a ellos a través
de servicios.
La regla recomienda ocultar los datos y acceder a
ellos por servicios, ya que de lo contrario cambios en
las estructuras de datos o en la manera de actualizar
los datos afectarían a los clientes de los mismos.
Tabla 8-4. Catálogo de reglas de diseño y su efecto
Otros trabajos (Skublics et al., 1996) proporcionan también un conjunto de reglas de
ayuda que permiten evitar infracciones graves de buenas prácticas en el desarrollo de
Tesis Doctoral Daniel Cabrero Moreno
223
programas. El examen de técnicas de lectura de artefactos de diseño (Travassos et al., 1999)
para detectar defectos, puede mostrar también el camino para la automatización de reglas de
diseño.
Algunos malos olores han sido incluidos por los trabajos anteriormente referenciados.
Sin embargo, adicionalmente a los propuestos por Fowler, otros autores (Crespo et al., 2006)
centran sus propuestas en encontrar malos olores en base a métricas. Para ello, es necesario
establecer límites por encima de los cuales se considera probable que un diseño sea candidato
a ser refactorizado. Tal y como se propone en (Garzás & Piattini, 2005), es posible considerar
reglas el cumplimiento de dichos límites en las métricas.
Otras fuentes de reglas extensibles pueden ser también consideradas, como por
ejemplo herramientas extensibles de refactorización (Marticorena & Crespo, 2008), donde para
cada nueva refactorización puede añadirse un predicado de obligado cumplimiento para la
aplicación del cambio. Cualquier herramienta, como la mencionada, donde pueden establecerse
pre-condiciones y post-condiciones para la aplicación de un cambio, puede ser considerada
como fuente de reglas.
En lo referente a herramientas de comprobación de reglas, una evaluación
detallada del mercado revela una gran cantidad de aplicativos de verificación de reglas de
codificación, así como una carencia importante en lo referente a reglas de diseño. La siguiente
lista muestra las herramientas de código abierto evaluadas para tecnología J2EE:
• PMD (PMD, 2008) : 6 reglas de diseño y 200 reglas de codificación.
• Checkstyle (Checkstyle, 2008) : 8 reglas de diseño y 200 reglas de codificación.
• FindBugs (FindBugs, 2008) : Todas las reglas son de codificación..
• Jamit (Jamit, 2008): Todas las reglas son de codificación.
• JCSC (JCSC, 2008): Todas las reglas son de codificación.
• JDepend (JDepend, 2008): 7 reglas de diseño de 7.
• DoctorJ (DoctorJ, 2008): Todas las reglas son de codificación.
Todas las herramientas evaluadas realizan los chequeos sobre el código fuente,
generalmente mediante el parseo o compilación del mismo.
En la revisión de mercado también se han analizado dos de las herramientas que más
reglas implementan, AppPerfect y CodePro, que implementan respectivamente 800 reglas (de
las que sólo 8 son reglas de diseño), y 950 reglas (de las que sólo 4 pueden ser consideradas
realmente de diseño).
Las herramientas revisadas son comúnmente utilizadas en la industria del software. Los
datos concuerdan con las opiniones de otros investigadores expuestas anteriormente: La gran
mayoría de las herramientas están orientadas al código y no al diseño.
Tesis Doctoral Daniel Cabrero Moreno
224
I.ii.iii. Categorización de las aproximaciones a la detección de
reglas
En la industria del software, los entregables de análisis y diseño son frecuentemente
deficientes o inexistentes. Raramente se entregan modelos UML bien formados. Por ese
motivo, la mayoría de las herramientas disponibles están basadas en el parseo o compilación
del código fuente. Estas técnicas reciben el nombre de “Abstract Syntax Tree-Based
techniques (AST)”, o basadas en el árbol sintáctico abstracto.
Por otro lado, existen también métodos alternativos, la mayoría de ellos desarrollados
por la comunidad investigadora a través de contribuciones en revistas y conferencias. En esta
sección se presentan los métodos de comprobación sobre modelos de diseño, que pueden
ser utilizados para interpretar chequear diseños técnicos en formatos como UML. Este tipo de
métodos son los más adecuados para desarrollos MDA (Model Driven Architecture), en
creciente implantación.
Otras alternativas, como la definición de lenguajes de reglas capaces de describir y
detectar defectos de diseño se describen a continuación.
I.ii.iii.i. Herramientas basadas en AST
Morgan comenta que “una aproximación muy comúnmente utilizada para construir
comprobaciones de reglas de diseño es utilizar un API que permita inspeccionar el programa.
Ejemplos de esta orientación incluyen PMD o FindBugs” (Morgan et al., 2007). Como se ha
visto anteriormente, la gran mayoría de herramientas están basadas en esta técnica.
Estas herramientas están basadas en el parseo de código, es decir, un compilador
genera un árbol de compilación (Abstract Syntax Tree - AST) que representa el código en una
estructura navegable. Inspeccionando dicho árbol usando un API proporcionado por la
herramienta en cuestión, un programador puede especificar una serie de condiciones de
cumplimiento de una práctica en concreto. Finalmente, la herramienta permite al usuario final
seleccionar un subconjunto de esas comprobaciones, que serán automáticamente aplicadas al
código.
Aunque generalmente no sea el caso, este tipo de técnica puede también ser utilizado
para obtener “métricas de Orientación a Objetos que puede ser usado como indicador para
detectar mejoras en los diseños automáticamente” (Sahraoui et al., 2000), o malos olores
(Munro, 2005).
La principal ventaja de este tipo de aproximación es la aplicabilidad de la técnica
incluso cuando no se dispone de diseño, es decir, en sistemas legados. Otra ventaja importante
es la flexibilidad proporcionada por un lenguaje de programación. Como inconvenientes,
podemos subrayar que en algunos casos este método puede ser una tarea muy trabajosa
(Moha et al., 2006), no es aplicable a modelos de más alto nivel como diseños de alto nivel,
Tesis Doctoral Daniel Cabrero Moreno
225
arquitecturas o modelos de análisis, y en ocasiones las herramientas ofrecen limitaciones al
parsear las estructuras de clases, ya que están pensadas únicamente para el análisis estático
de código.
I.ii.iii.ii. Herramientas basadas en modelos
La gran mayoría de la comunidad investigadora está de acuerdo en que las
herramientas de comprobación sobre modelos deberían ser compatibles con la especificación
UML (Fowler, 2003), al ser el estándar de facto en cuanto a modelado de sistemas orientados a
objetos. También hay un acuerdo generalizado en la conveniencia del estándar “XML Metadata
Interchange” (OMG-XMI, 2008) para el intercambio de modelos, debido al hecho de que la
mayoría de las herramientas de modelado UML soportan dicho estándar.
Un resumen interesante en lo concerniente a validación de reglas de diseño sobre
modelos ha sido presentada recientemente (Egyed, 2007), pero tanto el trabajo presentado por
el autor, como los trabajos referenciados se enfocan únicamente en la detección de
inconsistencias entre distintas partes del mismo modelo, en lugar de en buenas prácticas. Por
ejemplo, una comprobación sobre inconsistencias podría ser que “un mensaje en un diagrama
de secuencia debe tener dicho método definido en el diagrama estático”.
Podemos concluir por tanto que los trabajos encontrados en la literatura se centran en
la realización de análisis de consistencia entre distintos diagramas UML. Únicamente se han
encontrado dos herramientas que realizasen comprobaciones de reglas de diseño sobre
modelos de diseño. Se trata de EMPANADA (EMPANADA, 2008) y SDMetrics (SDMetrics, 2008),
que implementan unas decenas de reglas directamente sobre un modelo de diseño compatible
con XMI. En el caso de EMPANADA, un sistema de visualización de infracciones de reglas es
también proporcionado en aras de una mayor facilidad. SDMetrics no visualiza los resultados,
pero posee un conjunto de reglas basadas tanto en métricas como en características
estructurales.
Una opción inexplorada es utilizar otras facilidades de implementación de reglas, como
por ejemplo el “Eclipse Modeling framework - EMF” (EMF, 2008), que es un API capaz de
navegar a través de modelos compatibles con XMI, y utilizar las facilidades que eclipse
proporciona para integrarlo con la labor diaria de los desarrolladores. Desafortunadamente, no
se ha encontrado ninguna herramienta desarrollada en ese sentido, lo que plantea un nicho de
investigación no explorado interesante, sobre todo en su aplicación a proyectos reales donde
todavía no se han proporcionado datos sobre el uso de herramientas de este estilo.
Contrastando con las herramientas basadas en AST, las herramientas basadas en
modelos son recomendables para evaluar diseños, arquitecturas o análisis, e inaplicables a
código legado a no ser que se realice una ingeniería inversa del código previamente a su
comprobación.
Tesis Doctoral Daniel Cabrero Moreno
226
I.ii.iii.iii. Herramientas basadas en lenguajes
Recientemente se ha propuesto un nuevo entorno de validación de reglas basado en la
especificación de un lenguaje utilizando técnicas de Programación Orientada a Aspectos
(Morgan et al., 2007). Más concretamente, basado en el entorno de aspectos sobre Java
AspectJ (Kiczales et al., 2001). Su nombre es “PDL-Program Description Logic”, y propone la
definición declarativa de estructuras de programación, en este caso, estructuras
correspondientes a violaciones de reglas. Un software habilitado al efecto se encarga de
comprobar dichas definiciones contra los sistemas, de forma que la ampliación o variación de
las reglas sea sencilla y barata.
Siguiendo la misma línea de investigación, también se ha definido un lenguaje basado
en notación BNF, que se ha utilizado para especificar defectos de diseño (Moha et al., 2006).
Se realizó una prueba de concepto exitosa de implementación de los defectos Blob,
Descomposición Funcional, Código Espagueti, y Navaja Suiza, definidos por (Brown et al.,
1998).
Esta aproximación tiene una importante ventaja. Una vez que el lenguaje está definido,
es posible desarrollar verificaciones de nuevas reglas sin necesidad de programar. Este es un
punto muy importante, y el motivo de que mucho trabajo de investigación esté siguiendo dicha
línea actualmente. Por otro lado, todavía es necesario realizar demostraciones más profundas
del poder de expresividad de dichos lenguajes, con el objeto de validar su flexibilidad. En
cualquier caso, los lenguajes de detección de defectos necesitan todavía encontrar un
compromiso entre flexibilidad y simplicidad.
I.iii. Predicción de la Probabilidad de Cambio
Muchos trabajos de investigación relacionados con la estimación de la probabilidad de
cambio de los distintos artefactos software han sido presentados en los últimos años.
La probabilidad de cambio es utilizada intensivamente en la aplicación del paradigma
de valor al diseño y mantenimiento software presentados en esta Tesis Doctoral. Esto es
debido a que el valor de un diseño y el coste de mantenimiento de un artefacto software están
muy relacionados con el número de cambios que éste pueda sufrir en un futuro.
A continuación se presenta una revisión y clasificación de las técnicas de predicción del
cambio en los siguientes grupos: “Métodos Basados en Información Histórica” y “Métodos
Basados en Análisis Estático del Diseño”.
Tesis Doctoral Daniel Cabrero Moreno
227
I.iii.i. Métodos Basados en Información Histórica
Predecir el futuro es una tarea muy compleja, sin embargo es posible estudiar en
detalle qué sucedió en el pasado y esperar un comportamiento similar en el futuro más
cercano. Trasladado a términos de predicción del cambio, las técnicas basadas en información
histórica se basan en la “observación empírica de que las clases que cambiaron más en el
pasado reciente, también sufrirán cambios importantes en un futuro cercano” (Girba et al.,
2004).
Las técnicas de cambio basadas en información histórica tienen por objeto revisar qué
artefactos de diseño o código cambiaron a lo largo de la historia conocida del sistema (por
ejemplo, mediante el análisis de los datos almacenados en una herramienta de control de
versiones) e inferir una probabilidad de cambio a partir de dichos datos. Existen varias
alternativas para llevar a cabo dicho objetivo como las que se presentan en (Ying et al., 2004,
Zimmermann et al., 2004), cambiando el modo en que se revisa el histórico (de forma íntegra
o por versiones), o asignando distinto valor a los cambios más recientes o a los más antiguos
(Girba et al., 2004).
Los siguientes epígrafes describen los métodos más destacados de predicción de
cambio.
I.iii.i.i. Revisión de la vida completa del proyecto
La primera aproximación al problema, es la de analizar el histórico de cambios de todos
los artefactos de código que componen el diseño de un proyecto software. Como artefacto se
entiende en este caso un método, clase, o conjunto de clases. La Tabla 8-5 muestra un
ejemplo de sumario de cambios.
Artefactos Número de cambios
Art. 1 3
Art. 2 5
Art. 3 0
Tabla 8-5. Histórico de cambios de la vida completa de un proyecto
Una vez se haya recogido esta información, se analizará el número de cambios de cada
una de las clases. Se esperará que los artefactos que más hayan cambiado, en este caso el
artefacto 2, sufran una mayor cantidad de cambios en el futuro.
Sin embargo, la aplicación de esta técnica tal y como se describe aquí plantea una serie
de problemas importantes:
No se está teniendo en cuenta la evolución de cambios a lo largo de las distintas
versiones del producto.
Tesis Doctoral Daniel Cabrero Moreno
228
Con este tipo de recogida de datos, no podemos inferir una probabilidad o número de
cambios esperados, dado que no sabemos qué número de cambios se esperan por
unidad de tiempo (o versión).
No es posible aplicar técnicas de priorización dependiendo de cuándo se haya
producido cada cambio.
I.iii.i.ii. Revisión de cambios por versión
Una aproximación común en la aplicación de este tipo de técnica es la de dividir la vida
del proyecto en las distintas entregas o parches que han tenido lugar. El ejemplo que se
muestra en la Tabla 8-6 muestra un ejemplo de recogida de datos por versión.
Artefactos Número de cambios por versión
V1 V2 V3
Art. 1 3 0 1
Art. 2 5 1 3
Art. 3 0 4 2
Tabla 8-6. Histórico de cambios de un proyecto por versión
Esta información puede ser utilizada de varias maneras con el objetivo de extraer
probabilidades de cambio. Los cambios esperados en la próxima versión (Cambios n+1) puede
ser calculado como la media de las últimas versiones, esto es, la suma los cambios de las
últimas versiones ( últimos num_cambios) dividido por el número de versiones (n), como se
muestra en la Ecuación 8-1.
Ecuación 8-1. Probabilidad de cambio de la próxima versión
La Tabla 8-7 muestra los datos resultantes de la aplicación de la Ecuación 8-1 sobre los
datos de la Tabla 8-6.
Artefactos Número de cambios
Art. 1 3
Art. 2 5
Art. 3 0
Tabla 8-7. Número de cambios estimados para la próxima versión
Sin embargo, esta aproximación tiene un defecto, y es que no todas las versiones del
sistema tienen por qué tener igual duración. En el caso en el que se desee tener esta variable
en cuenta, es necesario normalizar las unidades de tiempo para que las versiones más cortas
no adquieran más importancia relativa que las versiones más largas. (Sharafat & Tahvildari,
Cambios n+1 = ( ultimos num_cambios / n )
Tesis Doctoral Daniel Cabrero Moreno
229
2007) propone una serie de métodos para hacerlo. Para ello utiliza varios modelos matemáticos
para llevar a cabo la normalización.
I.iii.i.iii. Priorización temporal de los cambios
Para completar esta aproximación, también podemos tener en cuenta que en algunos
casos, los cambios más recientes son los que aportan una mejor capacidad de predecir el
futuro más cercano. (Girba et al., 2004) utiliza una técnica llamada “Yesterday’s Weather” (YW)
que utiliza métricas para signar una importancia relativa diferente a los cambios dependiendo
de cuándo ocurrieron. En su caso, es utilizada para priorizar la ingeniería inversa sobre
sistemas grandes, pero el mismo concepto puede ser aplicado para muchos otros propósitos.
YW utiliza tres métricas distintas que asignan distinta prioridad a cambios más
recientes o más antiguos:
Evolution of Number of Methods (ENOM). Se utiliza para mostrar los cambios a lo
largo de la vida de una clase C, asignando la misma importancia a todos los cambios.
Se define como la diferencia del número de métodos (NOM) entre las versiones i e i-1,
como muestra la Ecuación 8-2
Ecuación 8-2. Métrica ENOM entre dos subversiones consecutivas
ENOM j...k se define como el número de cambios entre una versión j y una
versión k. Se calcula como la suma de los cambios de todas sus subversiones, tal
y como muestra la Ecuación 8-3
Ecuación 8-3. Métrica ENOM entre dos subversiones (ENOM j...k)
Latest Evolution of Number of Methods (LENOM). Se utiliza para dar una mayor
importancia a los cambios más recientes sobre los cambios más antiguos aplicando una
función de pesos (2 i-k), que aplica un decremento de la importancia de un cambio a
medida que la versión i del cambio se aleja de la versión considerada k. La Ecuación
8-4 muestra el método de cálculo.
Ecuación 8-4. Métrica LENOM entre dos subversiones (LENOM j...k)
(i > 1) ENOM i (C) = | NOM i (C) - NOM i-1 (C)|
(i j < k n) ENOM j...k (C) = ki=j+1 ENOM i (C)
(i j < k n) LENOM j...k (C) = ki=j+1 ENOM i (C) 2 i-k
Tesis Doctoral Daniel Cabrero Moreno
230
Earliest Evolution of Number of Methods (EENOM). De manera opuesta a
LENOM, se define EENOM para favorecer los cambios más cercanos a la primera
versión de la historia en lugar de a la última. El método de cálculo queda definido
mediante la Ecuación 8-5.
Ecuación 8-5. Métrica EENOM entre dos subversiones (EENOM j...k)
I.i.i.i. Ventajas e inconvenientes
La principal ventaja de este tipo de técnicas es que pueden ser fácilmente
automatizadas, pero existen dos prerrequisitos para su utilización. En primer lugar,
necesitamos tener disponible la información histórica de control de versiones. En segundo
lugar, dicha herramienta debe haber sido utilizada por un periodo de tiempo lo suficientemente
largo como para tener una cantidad representativa de cambios almacenados.
I.iii.ii. Métodos Basados en Análisis Estático del Diseño
Algunos investigadores se han dado cuenta que las estructuras y propiedades de los
diseños orientados a objetos pueden identificar clases propensas al cambio. Un ejemplo de
predicción del cambio basada en la estructura estática de un diseño puede ser por ejemplo el
definido por el antipatrón “God Object”. Se trata de un objeto que asume una cantidad muy
elevada de responsabilidades, y que típicamente debe ser dividido en varios objetos.
Estos objetos suelen enviar mensajes a muchos otros objetos, y suelen tener una
mayor probabilidad de cambio, porque cuando un objeto referenciado cambia, el cambio podría
propagarse hasta el primer objeto.
Las propiedades o estructuras de código pueden también señalar una clase propensa al
cambio. La clase y número de métodos de un objeto puede también ser indicadores de alta
probabilidad de cambio. Por ejemplo, una gran sentencia “case” o cualquier otro mal olor, o
“Bad Smell” según (Fowler, 1999), puede también señalar una mayor probabilidad de cambio.
I.iii.ii.i. Métodos basados en estructuras estáticas
(Tsantalis et al., 2005) propuso un nuevo método basado en “Ejes de cambio” (Axes of
Change - AC), que asignaba una probabilidad de cambio distinta teniendo en cuenta la
estructura y dependencias de la estructura estática de clases.
(i j < k n) EENOM j...k (C) = ki=j+1 ENOM i (C) 2 k-i
Tesis Doctoral Daniel Cabrero Moreno
231
El modelo propuesto estudia cómo un cambio en una clase puede afectar al resto de
las clases, forzándolas también a cambiar, y propagando el cambio a lo largo del diseño. Ya
mucho antes, (Haney, 1972) utilizó el término “Efecto Ripple” (o efecto onda) para el concepto
de propagación de cambios. Por ejemplo, el cambio en la firma de un método requerirá el
cambio en todas las clases que referencien a dicho método.
La técnica de los ejes de cambio aglutina los tipos de cambios propuestos en muchos
otros trabajos, clasificando dichas propagaciones en tres categorías o Ejes Externos:
Eje de Herencia. Subdividida en dos tipos:
o Interface. Una clase implementa una o más interfaces. Por ejemplo, la adición de
un nuevo método en la interfaz o el cambio de su firma fuerza a todas las clases
que implementan dicha interfaz a cambiar para ser compatibles con el cambio.
o Herencia. En el caso de una clase abstracta, la declaración de un nuevo método
fuerza a todas sus subclases a implementarlo. En el caso de una clase no
abstracta, dicha propagación se reduce al caso de la utilización del constructor
de la superclase
Eje de Referencia. Cuya posible causa puede ser:
o Instanciación directa. Una clase instancia un objeto. Un cambio en la firma del
constructor implica que la clase que crea la instancia debe modificar su llamada.
o Referencia. Una clase emplea un objeto como parámetro en su constructor o uno
de sus métodos. Un cambio en la declaración de un método fuerza a las clases
que usan ese método a modificar las correspondientes llamadas.
Eje de Dependencia. Un cambio en una clase o nombre de paquete de la clase
referenciada, forzará cambios en la clase dependiente.
Existe otro tipo de ejes de cambio debidos a modificaciones que sólo afectan a la
propia clase, pero que fuerzan a modificaciones por propagaciones internas de cambios. Para
ello, Tsantalis define también Ejes Internos de cambio que agrupan las posibles causas de
cambio: modificación de la declaración de los métodos, nuevos métodos o atributos, cambio de
la implementación... etcétera.
(Tsantalis et al., 2005) realiza además un importante trabajo comparativo, a través de
una herramienta desarrollada a medida, al aplicar todas las técnicas de probabilidad de cambio
precedentes y estudiar su índice de acierto en dos proyectos de código libre. Entre este
conjunto de técnicas, debemos destacar por su mayor acierto en la predicción del cambio las
Tesis Doctoral Daniel Cabrero Moreno
232
técnicas basadas en históricos, métricas de acoplamiento y las métricas de tamaño.
La muestra los resultados de la comparativa.
Ilustración 8-4. Comparativa de métodos de predicción de cambio (Tsantalis et al., 2005)
(Sharafat & Tahvildari, 2007) proporciona además una aproximación basada en
probabilidad para combinar el método propuesto por Tsantalis, y el método de
revisión histórica de cambios, que proporciona una mayor predictibilidad que los métodos
propuestos hasta entonces.
I.iii.ii.ii. Métodos basados en métricas de acoplamiento
Las métricas de acoplamiento han sido referenciadas a lo largo de la literatura de
análisis de impacto. (Briand et al., 1999) proporciona una lista de técnicas destinadas a
encontrar dependencias entre clases. Inicialmente, esta información fue usada para analizar el
impacto de las diferentes alternativas de diseño, pero más tarde, una nueva utilidad de
predicción de cambio fue propuesta.
Algunos investigadores sugirieron que si una clase puede tener un gran impacto en el
diseño, es decir en otras clases, esto haría que la probabilidad de cambio de esas otras clases
fuera más alta.
Entre las técnicas de análisis de impacto referenciadas en la literatura, podemos
destacar (Chidamber et al., 1998), que propuso un conjunto de métricas orientadas a objetos,
llamadas métricas C&K: DIT (depth of inheritance tree), NOC (number of children), CBO
(coupling between objects), y RFC (response for a class). Además propusieron dos métricas
internas a cada clase, WMC (weighted methods per class), y LCOM (lack of cohesion in
methods).
Tesis Doctoral Daniel Cabrero Moreno
233
(Chen & Rajlich, 2001) también propusieron una técnica en el contexto del análisis de
impacto, basada en la construcción de un “Grafo Abstracto de Dependencias del Sistema” o
“Abstract System Dependence Graph – ASDG”, que representaba las dependencias entre
componentes software y conceptos del modelo de análisis del dominio. Además desarrollaron
una herramienta llamada RIPPLES que lo implementaba.
I.iii.ii.iii. Métodos basados en el tamaño de los artefactos
Por otro lado existen las métricas basadas en tamaño, que parten del principio de que
cuanto mayor es una clase, menos modularizado es su diseño. Esta es la razón por la que
algunas heurísticas de diseño recomiendan mantener las clases simples y de tamaño reducido.
El número de métodos por clase (Number of Methods per Class - NOO) utilizado en
(Arisholm et al., 2004) para identificar clases propensas a cambio, o el tamaño de las clases
(Class Size - CS), usado en (Wilkie & Kitchenham, 2000) para investigar la relación del tamaño
de las clases y el esfuerzo de implementación de cambios, figuran en este grupo de técnicas.
I.iv. Estimación de la Probabilidad de Uso
La estimación de la frecuencia de uso de cada artefacto software puede ser una
información muy valiosa de cara a refactorizaciones que optimicen la comprensión y el
mantenimiento del código. Consiste en averiguar la probabilidad que cada uno de los artefactos
que componen un sistema tienen de ser necesarios en las distintas ejecuciones demandadas
por los usuarios.
Dentro de todos los posibles tipos de artefactos involucrados en el desarrollo de
software (requisitos, pruebas, diseño, código… etc.), entenderemos la probabilidad de uso
aplicada únicamente a los artefactos de código y de diseño. Esencialmente, tendremos en
cuenta los paquetes, las clases, los métodos y atributos, y los bloques de código. Se entiende
que un artefacto tiene una probabilidad alta de uso, si para muchas operaciones de negocio es
necesaria su colaboración. Un artefacto con probabilidad de uso cero sería aquel que nunca va
a utilizarse en un sistema, es decir, aquel que no afectaría al funcionamiento del sistema si
fuese eliminado.
Existen varias aproximaciones que permiten identificar la frecuencia de uso de los
artefactos. Básicamente podemos separar dichas técnicas en dos tipos de técnicas. Las basadas
en análisis estático de código y las basadas en el análisis de la información de ejecución de los
sistemas. Ambos tipos de técnicas son analizados a continuación.
Tesis Doctoral Daniel Cabrero Moreno
234
I.iv.i. El análisis estático de código
La aplicación de análisis estático se basa en el examen de la estructura del código. La
aproximación más simple es la identificación de código muerto o no referenciado (“dead code”
en terminología anglosajona), que por su propia naturaleza tendrá una probabilidad de uso
nula.
La detección de código no usado puede ser también realizada analizando los
predicados de las sentencias, generalmente con objeto de eliminar parte del código. Este tipo
de técnicas reciben el nombre de “Partial Dead Code Elimination” o eliminación parcial de
código muerto (Knoop et al., 1994, Bodík & Gupta, 1997). En lugar de buscar código no
referenciado, este tipo de técnicas evalúan los grafos de un programa y eliminan el código que
no es necesario. Generalmente se elimina el código replicado para varios caminos de un
programa, haciendo uso de refactorizaciones simples. Este último tipo de técnicas son
aplicadas frecuentemente en el campo de la optimización de compiladores.
La detección de código muerto, ya sea total o parcial, tiene por objeto localizar el
código cuya utilización es imposible debido a la estructura estática que posee.
Normalmente, el objetivo suele ser la eliminación de los elementos no referenciados o
duplicados, para así incrementar la “analizabilidad” del sistema, es decir, para conseguir que
sea más fácilmente entendible, y por ende, más fácilmente mantenible.
Como ventaja principal, cabe señalar que el análisis estático de código muerto es
realizado por una gran cantidad de herramientas, como por ejemplo (Eclipse, 2008), y se ha
convertido en una práctica habitual en la industria del software. Los entornos de desarrollo son
capaces de indicar en tiempo real artefactos de código no referenciados. La total fiabilidad de
los resultados (un elemento no referenciado o cuya condición de acceso es imposible que
pueda llegar a ser usado) son otra característica positiva a resaltar.
Como principal inconveniente se puede indicar que pueden existir artefactos que sí
estén referenciados y no se usen. Las técnicas estáticas no son capaces de reflejar las
tendencias de los usuarios, o los artefactos no utilizados por otros motivos distintos a los
expuestos. Adicionalmente, las técnicas estáticas no son capaces de proporcionar un
porcentaje. La probabilidad de uso únicamente puede tomar los valores 0 (código muerto) o 1
(código accesible).
I.iv.ii. El análisis dinámico de código
“El análisis del código fuente no proporciona información suficiente para entender
completamente un programa porque hay componentes y relaciones que sólo existen durante la
ejecución” (Souder et al., 2001).
Tesis Doctoral Daniel Cabrero Moreno
235
La única manera de obtener una frecuencia de uso fiable distinta de 0 o 1 es
monitorizar las ejecuciones que pasan por cada paquete, clase, método y bloque que lo
compone. Dicha información puede ser tratada y resumida para proporcionar la frecuencia de
uso, que puede servir para estimar frecuencias de uso futuro.
El análisis dinámico de código puede ser encontrado en la literatura aplicado a una
gran variedad de usos. El análisis dinámico consiste en procesar la información de
ejecución de un programa, y normalmente, en combinar dicha información con técnicas de
análisis estático.
La información dinámica es utilizada en varias propuestas para crear automáticamente
diagramas UML de secuencia o de colaboración (Kollmann & Gogolla, 2001). Quante y Koschke
proponen seguir la misma filosofía pero aplicada a nivel de objeto, analizando el flujo interno
en lugar de describir relaciones entre objetos (Quante & Koschke, 2008). Otros autores
explotan la información de ejecución para presentarla gráficamente (Ducasse et al., 2004),
descomponer programas con arreglo a la ejecución conjunta de módulos (Jalote et al., 2006),
identificar conceptos del mismo modo (Jeremy Singer & Kirkham, 2006), ingeniería inversa
(Stroulia & Systä, 2002) o reconocer patrones (Pettersson, 2005). Todos estos usos de la
información dinámica están encaminados a mejorar la analizabilidad de los sistemas.
I.v. Predicción de la Propensión al Fallo
Muchos son los trabajos que relacionan métricas de producto con la propensión al fallo
de los distintos artefactos de diseño y código. Una revisión detallada de los trabajos
relacionados puede ser consultada en (Briand & Wuest, 2002). Básicamente existen tres tipos
de predictores contrastados:
La mayoría de los estudios realizan un análisis de la relación existente entre las
distintas métricas obtenidas del software y los históricos de fallos detectados. La
correlación entre los datos sugiere que propiedades estructurales como el tamaño
del código, y características como la complejidad ciclomática o el acoplamiento
(relacionados fuertemente con el tamaño) son predictores útiles de la propensión al
fallo.
Otros predictores útiles de la probabilidad de fallo están basados en el historial de
cambios que los artefactos software sufren. Los resultados presentados en (Mockus &
Weiss, 2000) sugieren, en base a los datos, que el riesgo inherente a la aparición de
defectos puede ser modelado como el número de métricas simples de variación de
tamaño, duración de los cambios, y alcance del cambio. Explican esta correlación
debido a la alta probabilidad de introducir errores cada vez que se realiza un cambio en
el software.
En (Arisholm & Briand, 2006) se sugiere además que la combinación de los predictores
anteriores, con los datos históricos de defectos en forma de cambios realizados en
Tesis Doctoral Daniel Cabrero Moreno
236
versiones anteriores como consecuencia de mantenimientos correctivos, aumenta
drásticamente el acierto de la predicción.
La aplicación de los distintos tipos de predictores en el ámbito de la ISBV es analizada en el
documento principal.
Tesis Doctoral Daniel Cabrero Moreno
237
I.vi. Técnicas de Trazabilidad de Requisitos a
Diseño
“La trazabilidad de requisitos es la habilidad de seguir la vida de un requisito hacia
delante o hacia atrás” (Gotel & Finkelstein, 1994). Esta relación permite analizar qué
artefactos de diseño cambiarán si un requisito cambia, trasladando cualquier propiedad
inherente a los requisitos hasta las clases u objetos. Por ejemplo, si un requisito tiene un 50%
de probabilidades de cambiar según los usuarios, y sabemos que este requisito está
relacionado con las clases A y B, deduciremos que dichas clases tienen también un 50% de
probabilidad de cambio.
Muchas técnicas de trazabilidad de requisitos han sido propuestas a lo largo de los
años. Un interesante sumario de técnicas es proporcionado por (Cleland-Huang et al., 2004),
en la presentación de una nueva aproximación de trazabilidad que combina varios tipos de
métodos anteriormente propuestos, en función de las características del proyecto y del
desarrollo concreto. Los métodos que combina en su técnica son:
Enlaces simples (Simple Links). Es la forma más utilizada y simple de enlace, que
tiene por objetivo establecer la relación entre dos artefactos usando en la mayoría de
los casos una matriz de trazabilidad (Davis, 1990), y en menor medida, links de
hipertexto (Kaindl, 1991, Glinz, 2000) o grafos (Pinheiro & Goguen, 1996). Un requisito
es trazado a los artefactos de diseño impactados utilizando consultas simples que
devuelven el conjunto de artefactos relacionados.
Enlaces recogidos semánticamente (Semantic Retrieved Links). Se basa en
técnicas de recuperación de información (Information Retrieval - IR) (Rijsbergen,
1979). Puede ser utilizado para generar relaciones dinámicamente en lugar de ser
definidos directamente por los usuarios. Muchas de estas técnicas pueden ser
utilizadas, desde la utilización de técnicas algebraicas (Berry et al., 1995), redes
neuronales artificiales (Artificial Neural Networks - ANN) (Judd, 1990), o la
Descomposición Singular de Valores (Singular Value Decomposition -SVD) (Corless et
al., 1995, Kolda & O'Leary, 1998, Schroeder, 1999 , Dowling, 2002). Pueden además
ser combinadas con técnicas de tratamiento de sufijos (Porter, 1980, Harman, 1991), o
de utilización de pesos relativos (Salton & Buckley, 1988), entre otras.
Enlaces ejecutables (Executable Links). Algunos tipos de requisitos, especialmente
los relacionados con rendimiento o utilización de recursos, pueden utilizar modelos
ejecutables para validar dinámicamente que se cumplen ciertas condiciones (Jain,
1991).
Trazado de Requisitos No Funcionales (RNF) usando patrones de diseño. (Gross
& Yu, 2001) sugirieron la posibilidad de trazar RNF a través del uso de patrones,
mediante el establecimiento de un conjunto de clases en el que un requisito es
implementado. Esta técnica podría proporcionar un control muy fino a bajo coste de las
Tesis Doctoral Daniel Cabrero Moreno
238
relaciones entre este tipo de requisitos y las clases de diseño. Sin embargo, su
aplicación a proyectos reales debe ser todavía contrastada.
El objetivo final de todas las técnicas aquí nombradas es el de asociar un requisito con
un artefacto de diseño. Lo ideal es realizar todo el trazado mediante enlaces simples, sin
embargo en la realidad suele haber restricciones de recursos (cuesta mucho esfuerzo realizar la
trazabilidad de cada artefacto y mantenerla a lo largo de los cambios). Por ese motivo se crean
técnicas más complejas que automaticen en algún modo la gestión de las relaciones.
Las técnicas de recuperación de la información son un claro ejemplo de ello. Se trata
de técnicas automáticas o semi-automáticas que ahorran mucho esfuerzo a la hora de
mantener links, pero sólo pueden utilizarse en casos no críticos y en entornos controlados,
porque no tienen una efectividad del cien por cien.
Tesis Doctoral Daniel Cabrero Moreno
239
ANEXO II - Técnicas
auxiliares de soporte al
cálculo del valor
II.i. Introducción
La extracción de los intereses de los distintos implicados de un sistema suele estar
soportada por técnicas de asignación de valor, en su mayoría propuestas por matemáticos y
psicólogos.
En este anexo se exponen las técnicas de asignación de valor más utilizadas en la
Ingeniería del Software, como Planning Game, la técnica de los 100 dólares (sección II.ii), y la
técnica AHP (sección II.ii.i).
También se analiza la técnica Win-Win propuesta por Barry Boehm para la
reconciliación de los distintos objetivos de los implicados.
Tesis Doctoral Daniel Cabrero Moreno
240
II.ii. Técnicas y métodos más habituales de
elicitación de valor en IS
Existen varias técnicas para extraer de los implicados una priorización de los distintos
requisitos. En (Karlsson et al., 2006) se presenta un interesante trabajo comparativo sobre las
distintas técnicas existentes.
La técnica más comúnmente utilizada consiste en que el responsable de proyecto o el
usuario dividan en grupos los requisitos según la importancia relativa que tienen. En este
sentido, el IEEE (IEEE, 1998) propone dividirlos en “esenciales”, “condicionales” u
“opcionales”. Esta categorización no nos da información sobre la importancia relativa de los
requisitos pertenecientes a un grupo dado, ni cuantifica dicha importancia. Tampoco especifica
cómo definir mediante una metodología dicha clasificación, ni qué factores (de valor o no) hay
deben ser tenidos en cuenta.
La técnica de “Planning Game” es utilizada habitualmente en proyectos de “Extreme
Programming”. Los requisitos son plasmados en tarjetas que son ordenadas en tres montones
por los desarrolladores. Un primer montón que contiene los requisitos imprescindibles para el
funcionamiento, un segundo montón que contienen los que aportan valor, y otro con los que
serían deseables. Las tarjetas son después priorizadas por los usuarios en cada montón, con
arreglo a lo pronto que desean que dichos requisitos sean implementados. Finalmente los
requisitos son ordenados en un único montón que definirá la planificación. Sobre la técnica
anterior, esta propuesta aporta adicionalmente un orden relativo de todos los requisitos,
independientemente del grupo al que pertenecieran en un principio.
La técnica de los 100 dólares consiste en repartir a cada implicado 100 billetes
ficticios que deben distribuir entre los requisitos. Sumando lo sugerido por todos se obtiene la
importancia relativa, que además nos dice no sólo el orden de prioridad, sino que nos permite
comparar cuantitativamente su importancia (Leffingwell & Widrig, 2000).
El método Wiegers calcula la importancia relativa dividiendo el valor asignado al
requisito por el riesgo técnico y el coste (Wiegers, 1999). Aunque no todos los autores
coinciden en catalogarla como técnica, sino más bien como un método que tiene en cuenta la
combinación de diversas variables.
Tesis Doctoral Daniel Cabrero Moreno
241
II.ii.i. Analytic Hierarchy Process (AHP)
La técnica de ayuda a la decisión llamada (Analytic Hierarchy Process - AHP) es
una técnica comúnmente utilizada en psicología para realizar evaluaciones poco sesgadas
introducida en (Saaty, 1980). Se basa en realizar comparaciones por pares de requisitos, de
manera que mediante un cálculo matemático es posible averiguar la importancia relativa de
cada requisito. Tiene además una ventaja fundamental, y es que también puede evaluar la
fiabilidad de las asignaciones, ya que puede compararse la consistencia entre las distintas
puntuaciones.
(Karlsson et al., 2007) analiza un ejemplo de aplicación a la elicitación de requisitos,
detallando los cuatro pasos a llevar a cabo para implementar esta técnica de ayuda a la
decisión:
Paso 1. Para los n requisitos a evaluar, elaborar una matriz de n por n elementos
donde se sitúen todos los requisitos tanto en las filas como en las columnas.
Paso 2. Elaborar comparaciones por cada par de requisitos posibles, e insertarlos
en la matriz en el lugar correspondiente. Las puntuaciones son establecidas
comparando dos requisitos i y j, para un rango entre 1/10 y 10, estableciendo un
valor de 1 para los requisitos de igual importancia. Cuando la relación i-j es
evaluada con x, la relación j-i debe ser evaluada con 1/x. La diagonal que
representa coincidencias de cada requisito con sí mismos es evaluada con 1.
Para una matriz de n por n elementos, deben realizarse un mínimo de n*(n-1)/2
comparaciones. Por tanto, en el ejemplo que se muestra en la Tabla 8-8, deben ser
realizadas al menos 6 comparaciones.
Req 1 Req 2 Req 3 Req 4
Req 1 1 1/3 2 4
Req 2 3 1 5 3
Req 3 1/2 1/5 1 1/3
Req 4 1/4 1/3 3 1
Tabla 8-8. Paso 2 de AHP
Paso 3. Estimar el “autovalor” de la matriz. Para ello, Tomas Saaty sugiere usar
una aproximación simple consistente en sumar los valores de cada fila, y
normalizar dicho vector dividiéndolo por el número de requisitos.
Tesis Doctoral Daniel Cabrero Moreno
242
Req 1 Req 2 Req 3 Req 4 Suma Suma
Normalizada
Req 1 0,21 0,18 0,18 0,48 1,05 0,26
Req 2 0,63 0,54 0,45 0,36 1,98 0,50
Req 3 0,11 0,11 0,09 0,04 0,34 0,09
Req 4 0,05 0,18 0,27 0,12 0,62 0,16
Tabla 8-9. Paso 3 de AHP
Paso 4. El vector resultante señala el valor relativo de cada requisito.
o El Requisito 1 tiene el 26% del valor total.
o El Requisito 2 tiene el 50%.
o El Requisito 3 tiene el 9%.
o El Requisito 4 tiene el 16%.
AHP aporta la ventaja fundamental de que es posible analizar el índice de consistencia
de las asignaciones de los usuarios. Si los resultados entre las asignaciones no son coherentes
(Por ejemplo, el requisito 1 es más valioso que el requisito 2, el requisito 2 es más valioso que
el requisito 3, pero el requisito 3 es más valioso que el requisito 1) pueden desecharse algunas
puntuaciones, o proceder a evaluar de nuevo los requisitos.
Para formalizar esta fiabilidad de forma determinista, se propuso el cálculo de lo que se
llamó “índice de Consistencia” o IC. Este índice es calculado según la Ecuación 8-6.
Ecuación 8-6. Índice de Consistencia en AHP
Donde n es el número de requisitos, y max se calcula de la siguiente manera. En primer
lugar es necesario multiplicar la matriz de asignaciones del usuario por el vector de prioridad
obtenido de la suma normalizada, como se muestra en la Ecuación 8-7
1 1/3 2 4 0,26 1,22
3 1 5 3 0,50 2,18
1/2 1/5 1 1/3 0,09 0,37
1/4 1/3 3 1 0,16 0,64
Ecuación 8-7. Cálculo de max. Paso 1.
Posteriormente se divide el primer elemento del vector resultante entre el primer
elemento del vector original, el segundo por el segundo, y así sucesivamente.
IC max n / n 1
. =
Tesis Doctoral Daniel Cabrero Moreno
243
1,22 / 0,26 1,22
2,18 / 0,50 2,18
0,37 / 0,09 0,37
0,64 / 0,16 0,64
Ecuación 8-8. Cálculo de max. Paso 2.
max es calculado calculando la media de los elementos del vector resultante en la
Ecuación 8-8.
Ecuación 8-9. Cálculo de max. Paso 3.
Lo que da en el caso del ejemplo un valor de consistencia de 4,37 / 1
Para saber si el índice es aceptable, es necesario calcular el “Ratio de Consistencia” o RC,
resultante de dividir IC por un valor numérico dependiente del número de filas, mostrado en la
tabla siguiente.
n 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
divisor 0 0 0,58 0,90 1,12 1,24 1,32 1,41 1,45 1,49 1,51 1,48 1,56 1,58 1,59
Tabla 8-10. Divisores por número de filas de la matriz para calcular RC
En el caso del ejemplo n=4, por lo que el divisor es 0,90 según la tabla. El ratio de
consistencia tiene el siguiente valor: RC = 1,12 /1.90 = 0,14.
Como regla general, un ratio de consistencia inferior a 0,10 es considerado aceptable,
sin embargo en la práctica aparecen con frecuencia valores por encima de este, como en el
caso del ejemplo.
Existen experimentos comparativos entre las distintas técnicas. Según los
experimentos, la técnica Planning Game consume menos recursos que AHP, y es más sencilla
de utilizar (Karlsson et al., 2007). Sin embargo, en un análisis más exhaustivo de comparación
de técnicas (Berander et al., 2006), se muestra de forma detallada que no todos los casos de
estudio concuerdan en sus resultados a este respecto.
=
max = = 4,37
Tesis Doctoral Daniel Cabrero Moreno
244
II.iii. Teoría Win-Win
(Boehm & Jain, 2005) presenta una teoría inicial llamada “4+1” (véase figura 1) que
pretende ayudar a las compañías de software a asegurar el éxito de sus inversiones,
asegurando que el valor aportado por el software sea realmente de utilidad.
El centro de la propuesta es la “Teoría W” o “Success-Critical Stakeholder (SCS) Win-Win
Theory W”, que trata de convertir en “ganadores” a los actores críticos de éxito (CSC) del
sistema. Según esto, si todos los actores críticos ganan con el software propuesto, podemos
afirmar que el sistema tiene un éxito. Esta teoría se complementa con otras cuatro teorías
adicionales:
Teoría de dependencia (Dependency Theory): Identifica los SCS empleando la
técnica BRA-Benefits Realization Approach introducida por (Thorp, 1998), que identifica
no sólo iniciativas y actores relacionados con el software, sino cualquier otra cuestión
que aporte valor a la organización. De esa forma se obtiene una visión general de
cómo afecta el software a toda la organización.
Teoría de utilidad (Utility Theory), que permite conocer qué condiciones establece
cada SCS para considerarse “ganador”.
Teoría de decisión (Decision Theory), que establece la negociación entre las
condiciones de los actores, con el fin de alcanzar el equilibrio que permita considerar a
todos los actores ganadores. En algunos casos los conflictos de intereses serán
irresolubles, y por lo tanto, es mejor aclarar esto en un principio antes de desarrollar el
sistema.
Teoría de control (Control Theory), que permite controlar el progreso hacia el
estatus de “ganador” de cada actor.
La Ilustración 8-5 muestra la relación entre las distintas teorías expuestas.
Tesis Doctoral Daniel Cabrero Moreno
245
Ilustración 8-5. Teoría Win-Win
Teoría W
Teoría de
Dependencia
Teoría de
Control
Teoría de
Utilidad
Teoría de
Decisión
Tesis Doctoral Daniel Cabrero Moreno
246
Tesis Doctoral Daniel Cabrero Moreno
247
Acrónimos
Acrónimo Descripción
ACLOC Average Class Size
AMLOC Average Method Size
AOP Aspect-Oriented Programming
AHP Analytic Hierachical Process
ATAM Architecture Tradeoff Analysis Method
BPM Business Processing Management
BRA Benefit Realization Approach
CBAM Cost Benefit Analysis Method
COCOMO COnstructive COst MOdel
COTS Commercial-Of-The-Shelf
DAO Data Access Object
DGT Dirección General de Tráfico
DSBV Diseño Software Basado en Valor
DSM Design Structure Matrix
DWH DataWareHouse
EcoPOST Economic-driven Evaluations of Process-oriented Software
Technologies
EQUITY Exploring QUantifiable Information Technology Yields
EVA Earned Value Analysis
GCR Grupo Crítico de Referencia
IEEE Institute of Electrical and Electronics Engineers
IDONEO Ingeniería de Software basada en Valor y Calidad en Líneas
de Producto
IEC International Electrotechnical Commission
IMF Incremental Funding Method
IS Ingeniería del Software
ISBV Ingeniería del Software Basada en Valor
ISO International Organization for Standardization
IT Information Technology
JVMI Java Virtual Machine profiler Interface
JMERES Java MÉtodo de REducción de Software
LPS Líneas de Producto Software
MMF Minimal Marketable Features
MSBV Mantenimiento Software Basado en Valor
NC Number of Classes
NM Number of Methods
NOV Net Options Value
Tesis Doctoral Daniel Cabrero Moreno
248
NS Number of Statements
PFCU Puntos de Función de Casos de Uso
PMBoK Project Management Body of Knowledge
PORT Priorization of Requirement for Testing
ROI Return of Investment (Retorno de Inversión)
RO Repositorio Original
RR Repositorio Rollback
RS Reducción de Software
SD System Dynamics
SEI Software Engineering Institute
SGC Sistema de Gestión de la Configuración
SWEBOK Software Engineering Body of Knowledge
TraCS Traceability for Complex Systems
VOP Value-Oriented Prioritization
UBR Usage-Based Reading
GVAL Método Genérico de aplicación de VALor
GVAL-EX GVAL para EXcel
VBR Value-Based Review
VBRT Value-Based Requirement Tracing
XML Extensible Markup Language
Tabla 8-11. Acrónimos
Tesis Doctoral Daniel Cabrero Moreno
249
Referencias
ALSHAYEB, M. & LI, W. (2003) An Empirical Validation of Object-Oriented Metrics in Two Different Iterative Software Processes. IEEE Transactions on Software Engineering 29,
1043 - 1049.
ANTONIOL, G. & PENTA, M. D. (2004) A Distributed Architecture for Dynamic Analyses on User-Profile Data. IEEE Conference on Software Maintenance and Reengineering (CSMR). Tampere, Finland.
ARISHOLM, E. & BRIAND, L. C. (2006) Predicting fault-prone components in a java legacy
system. 2006 ACM/IEEE international symposium on Empirical software engineering. Rio de Janeiro, Brazil.
ARISHOLM, E., BRIAND, L. C. & FØYEN, A. (2004) Dynamic Coupling Measurement for Object-
Oriented Software. IEEE Transactions on Software Engineering, 30, 491-506.
AVISON, D., LAN, F., MYERS, M. & NIELSEN, A. (1999) Action Research. Communications of the ACM., 42, 94-97.
AZAR, J., SMITH, R. K. & CORDES, D. (2007a) Value-Oriented Prioritization: A Framework for
Providing Visibility and Decision Support in the Requirements Engineering Process.
Alabama, Department of computer science. University of Alabama.
AZAR, J., SMITH, R. K. & CORDES, D. (2007b) Value-Oriented Requirements Prioritization in a
Small Development Organization. IEEE Software, 24, 32-37.
BAJRACHARYA, S. K., NGO, T. C. & LOPES, C. V. (2005) On using Net Options Value as a value
based design framework. Seventh international workshop on Economics-driven software engineering research. International Conference on Software Engineering (ICSM). St. Louis, Missouri.
BALDWIN, C. Y. & CLARK, K. B. (2000) Design Rules vol I, The Power of Modularity, MIT Press.
BANDI, R. K., VAISHNAVI, V. K. & TURK, D. E. (2003) Predicting Maintenance Performance
Using Object-Oriented Design Complexity Metrics. IEEE Transactions on Software Engineering 29, 77 - 87.
BARDHAN, I., BAGCHI, S. & SOUGSTAD, R. (2004) A Real Options Approach for Prioritization of
a Portfolio of Information Technology Projects: A Case Study of a Utility Company. 37th Annual Hawaii International Conference on System Sciences (HICSS'04).
BASKERVILLE, R. (1999) Investigating Information Systems with Action Research. Communications of the Association for Information Systems, 2, 4.
BENAROCH, M. & KAUFFMAN, R. J. (1999) A Case for Using Real Options Pricing Analysis to
Evaluate Information Technology Project Investment. Information Systems Research, 10, 70-86.
Tesis Doctoral Daniel Cabrero Moreno
250
BENNET, K. H. & RAJLICH, V. T. (2000) Software Maintenance and Evolution: a Roadmap. ICSE (Track on The Future of Software Engineering). Limerick, Ireland.
BERANDER, P., KHAN, K. A. & LEHTOLA, L. (2006) Towards a Research Framework on
Requirements Prioritization. SERPS. Umeå, Sweden.
BERRY, M. W., DUMAIS, S. T. & O'BRIEN, G. W. (1995) Using linear algebra for intelligent
information retrieval. SIAM Review, 37, 573 - 595
BOCKLE, G., CLEMENTS, P., MCGREGOR, J. D., MUTHIG, D. & SCHMID, K. (2004) Calculating
ROI for software product lines. IEEE Software, 21, 23- 31.
BODÍK, R. & GUPTA, R. (1997) Partial dead code elimination using slicing transformations. ACM SIGPLAN 1997 conference on Programming language design and implementation. Las
Vegas, Nevada, United States, ACM.
BOEHM, B. (2003) Value-Based Software Engineering. ACM SIGSOFT Software Engineering Notes, 28.
BOEHM, B. (2005a) Value-based quality processes and results. International Conference on Software Engineering. Proceedings of the third workshop on Software quality. St.
Louis, Missouri.
BOEHM, B. (2005b) Value-Based Software Engineering: Overview and Agenda. Value-Based Software Engineering Heidelberg, Germany, Springer.
BOEHM, B. (2006) A View of 20th and 21st Century Software Engineering. International Conference on Software Engineering (ICSE). Shanghai, China
BOEHM, B., HOROWITZ, E., MADACHY, R., REIFER, D., CLARK, B. K., STEECE, B., BROWN, A.
W., CHULANI, S. & ABTS, C. (2000) Software Cost Estimation with Cocomo II Prentice
Hall PTR.
BOEHM, B. & HUANG, L. G. (2003) Value-Based Software Engineering : A Case Study. IEE Computer Society, 36, 33-41.
BOEHM, B. & JAIN, A. (2005) An Initial Theory of Value-Based Software Engineering. Value-Based Software Engineering Springer.
BOEHM, B. & SULLIVAN, K. J. (2000) Software economics: a roadmap. ICSE Limerick, Ireland.
BOEHM, B. & TURNER, R. (2003) Balancing Agiligy and Discipline: A Guide for the Perplexed,
Addison-Wesley.
BOURQUE, P., DUPUIS, R., ABRAN, A., MOORE, J. W. & TRIPP, L. L. (1999) The Guide to the
Software Engineering Body of Knowledge. IEEE Software, 16, 35-44.
BREECH, B., TEGTMEYER, M. & POLLOCK, L. (2005) A Comparison of Online and Dynamic Impact Analysis Algorithms. IEEE Conference on Software Maintenance and Reengineering (CSMR).
BRIAND, L. C., BUNSE, C. & DALY, J. W. (2001) A Controlled Experiment for Evaluating Quality
Guidelines on the Maintainability of Object-Oriented Designs. IEEE Transactions on Software Engineering, 27, 513 - 530.
Tesis Doctoral Daniel Cabrero Moreno
251
BRIAND, L. C., EMAM, K. E., SURMANN, D., WIECZOREK, I. & MAXWELL, K. D. (1999) An assessment and comparison of common software cost estimation modeling techniques.
International Conference on Software Engineering Los Angeles, California, United
States IEEE Computer Society Press.
BRIAND, L. C. & WUEST, J. (2002) Empirical Studies of Quality Models in Object-Oriented
Systems. Advances in Computers, 59, 97–166.
BROWN, W. J., MALVEAU, R. C., BROWN, W. H., III, H. W. M. & MOWBRAY, T. J. (1998)
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis.
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007a) Choosing the best design strategy from
requirements: A value-based approach. 1st IEEE Computer Society Conference on Exploring Quantifiable Information Technology Yields. Amsterdam, IEEE Computer Society.
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007b) Maintenance Cost of a Software Design. A Value-Based Approach. 9th International Conference on Enterprise Information Systems (ICEIS). Funchal, Madeira. Portugal.
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007c) Técnica de Mantenimiento Software Basada en Valor. Congreso Español de Informática - Jornadas de Ingeniería del Software y Bases de Datos (CEDI`07- JISBD’07). Zaragoza (Spain).
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2007d) Understanding Software Product Lines
through Design Patterns. 2nd International Conference on Software and Data Technologies (ICSOFT’07). Barcelona (Spain).
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2008a) Combining Different Change Prediction
Techniques. 10th International Conference on Enterprise Information Systems (ICEIS). Barcelona (Spain).
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2008b) Object Oriented Design Rules. Definition and Automatic Detection. Conference on Quality Engineering in Software Technology (CONQUEST'08). Berlin, Germany.
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2008c) Priorización del Valor de Artefactos Software Basada en la Frecuencia de Uso. Jornadas de Ingeniería del Software y Bases de Datos (JISBD'08). Gijón, Spain.
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2009a) Priorización del Valor de Artefactos Software
Basada en la Frecuencia de Uso. IEEE América Latina.
CABRERO, D., GARZÁS, J. & PIATTINI, M. (2009b) Value-Based Maintenance: Improving Software Maintainability through Automated Adaptive Reduction. Journal of Software Maintenance and Evolution.
CLELAND-HUANG, J. & DENNE, M. (2005) Financially informed requirements prioritization.
International Conference on Software Engineering St. Louis, MO, USA ACM Press.
CLELAND-HUANG, J., ZEMONT, G. & LUKASIK, W. (2004) A Heterogeneous Solution for
Improving the Return on Investment of Requirements Traceability. Requirements Engineering Conference, 12th IEEE International (RE'04). IEEE Computer Society
Tesis Doctoral Daniel Cabrero Moreno
252
CLEMENTS, P. & NORTHROP, L. (2001) Software Product Lines: Practices and Patterns, Addison-Wesley.
CLEMONS, E. K. (1991) Evaluation of strategic investments in information technology.
Communications of the ACM, 34, 22-36.
COBERTURA [en línea], <http://cobertura.sourceforge.net/>, [Consulta: 25 enero 2009].
COCKBURN, A. (2001) Agile Software Development, Addison-Wesley.
COLLINS, J. C. & PORRAS, J. I. (1997) Built to Last: Successful Habits of Visionary Companies,
Harper Business.
CORLESS, R. M., GIANNI, P. M., TRAGER, B. M. & WATT, S. M. (1995) The singular value
decomposition for polynomial systems. International Conference on Symbolic and Algebraic Computation Montreal, Quebec, Canada ACM Press
COSTA, H. R., BARROS, M. D. O. & TRAVASSOS, G. H. (2005) A risk based economical
approach for evaluating software project portfolios. seventh international workshop on Economics-driven software engineering research (International Conference on Software Engineering). St. Louis, Missouri.
CRESPO, Y., LÓPEZ, C., MANSO, E. & MARTICORENA, R. (2006) From Bad Smells to Refactoring: Metrics Smoothing the way. en VELTHUIS, M. P. (Ed.) Object-Oriented Design Knowledge: Principles, Heuristics and Best Practices. Idea Group Publishing.
CHECKSTYLE [en línea], <http://checkstyle.sourceforge.net/>, [Consulta: 25 enero 2009].
CHEN, K. & RAJLICH, V. (2001) RIPPLES: tool for change in legacy software. International Conference on Software Maintenance. Florence, Italy, IEEE Computer Society.
CHIDAMBER, S. R., DARCY, D. P. & KEMERER, C. F. (1998) Managerial Use of Metrics for
Object-Oriented Software. IEEE Transactions on Software Engineering, 24, 629-639.
CHIKOFSKY, E. (2007) Engineering Management & Integration. 1st IEEE Computer Society Conference on Exploring Quantifiable Information Technology Yields. Amsterdam, IEEE Computer Society.
CHIKOFSKY, E., DINUNNO, D. & SLOVIN, M. (2007) IT Investment and Portfolio Management
in U.S. Government Agencies. IEEE Equity. Amsterdam, IEEE Computer Society.
CHULANI, S., STEECE, B. M. & BOEHM, B. (2002) Determining Software Quality Using
COQUALMO. Case Studies in Reliability and Maintenance. John Wiley & Sons.
DAGPINAR, M. & JAHNKE, J. H. (2003) Predicting Maintainability with Object-Oriented Metrics -
An Empirical Comparison. 10th Working Conference on Reverse Engineering Victoria,
B.C., Canada.
DAVIS, A. (2004) Great Software Debates, Wiley-IEEE Computer Society Press.
DAVIS, A. M. (1990) Software Requirements: Analysis and Specification, Upper Saddle River, NJ, USA Prentice-Hall.
DOCTORJ [en línea], <http://doctorj.sourceforge.net/>, [Consulta: 25 enero 2009].
Tesis Doctoral Daniel Cabrero Moreno
253
DOWLING, J. (2002) Information Retrieval using Latent Semantic Indexing and a Semi-Discrete Matrix Decomposition. School of Computer Science and Software Engineering. Monash
University.
DUCASSE, S., LANZA, M. & BERTULI, R. (2004) High-Level Polymetric Views of Condensed Run-time Information. IEEE Conference on Software Maintenance and Reengineering (CSMR). Tampere, Finland.
ECLIPSE [en línea], <http://www.eclipse.org/>, [Consulta: 25 enero 2009].
EGYED, A. (2007) Fixing Inconsistencies in UML Design Models. 29th International Conference on Software Engineering (ICSE'07). Minneapolis, MN, USA, IEEE Computer Society.
EGYED, A., BIFFL, S., HEINDL, M. & GRÜNBACHER, P. (2005) A value-based approach for
understanding cost-benefit trade-offs during automated software traceability. 3rd international workshop on Traceability in emerging forms of software engineering Long
Beach, California ACM Press.
ELBAUM, S., MALISHEVSKY, A. G. & ROTHERMEL, G. (2002) Test Case Prioritization: A Family
of Empirical Studies. IEEE Transactions on Software Engineering, 28, 159-182.
EMAM, K. E., BENLARBI, S., GOEL, N., MELO, W., LOUNIS, H. & RAI, S. N. (2002) The Optimal Class Size for Object-Oriented Software. IEEE Transactions on Software Engineering, 28, 494 - 509.
EMF [en línea], <http://www.eclipse.org/modeling/emf/>, [Consulta: 25 enero 2009].
EMMA [en línea], <http://emma.sourceforge.net/>, [Consulta: 25 enero 2009].
EMPANADA [en línea], <http://www.win.tue.nl/empanada/>, [Consulta: 25 enero 2009].
FINDBUGS [en línea], <http://findbugs.sourceforge.net/>, [Consulta: 25 enero 2009].
FIORAVANTI, F. & NESI, P. (2001) Estimation and Prediction Metrics for Adaptive Maintenance Effort of Object-Oriented Systems. IEEE Transactions on Software Engineering, 27,
1062-1084.
FLEMING, Q. W. & KOPPELMAN, J. M. (2006) Earned Value Project Management, Atlanta,
Project Management Institute.
FOWLER, M. (1999) Refactoring, Addison Wesley Professional.
FOWLER, M. (2003) UML Distilled: Applying the Standard Object Modeling Language, MA, USA,
Addison-Wesley.
FREEMAN, R. E. (1984) Strategic Management: A Stakeholder Approach, Pitman Publishing.
GAMMA, E., HELM, R., JOHNSON, R. & VLISSIDES, J. (1995) Design Patterns, Addison-Wesley
Professional.
GARZAS, J., CABRERO, D. & PIATTINI, M. (2007) La Ingeniería del Software Basada en Valor.
CUORE-Circulo de Usuarios de Oracle de España, 34, 3 -12.
GARZÁS, J., CABRERO, D. & PIATTINI, M. (2007) El valor y el retorno de inversión de las TSI.
Gobierno de las Tecnologías y Sistemas de Información. Madrid, España, RA-MA.
Tesis Doctoral Daniel Cabrero Moreno
254
GARZÁS, J. & PIATTINI, M. (2002) Analyzability and Changeability in Design Patterns. SugarLoafPLoP. The Second Latin American Conference on Pattern Languages of Programming. Itaipava, Río de Janeiro, Brasil.
GARZÁS, J. & PIATTINI, M. (2005) An ontology for micro-architectural design knowledge. IEEE Software Magazine, 22, 28-33.
GENERO, M., MANSO, E., VISAGGIO, A., CANFORA, G. & PIATTINI, M. (2007) Building measure-based prediction models for UML class diagram maintainability. Empirical Software Engineering, 12, 517 - 549.
GENERO, M., PIATTINI, M. & CALERO, C. (2005) A survey of metrics for UML class diagrams.
Journal of Object Technology, 4, 59-92.
GIDDINGS, N. & COLBURN, T. (1984) An automated software design evaluator. ACM'84 Annual Conference. ACM Press.
GIRBA, T., DUCASSE, S. & LANZA, M. (2004) Yesterday's Weather: Guiding Early Reverse Engineering Efforts by Summarizing the Evolution of Changes. 20th IEEE International Conference on Software Maintenance Washington, DC, USA IEEE Computer Society.
GLINZ, M. (2000) A lightweight approach to consistency of Scenarios and Class Models. International Conference on Requirement Engineering. Washington, DC, USA, IEEE
Computer Society
GOTEL, O. C. Z. & FINKELSTEIN, A. C. W. (1994) An analysis of the requirements traceability
problem. 1st International Conference on Requirements Engineering. Colorado Springs, CO, USA, IEEE Computer Society.
GROSS, D. & YU, E. S. K. (2001) From Non-Functional Requirements to Design through
Patterns. Requirements Engineering, 6, 18-36.
GSCHWIND, T. & OBERLEITNER, J. (2003) Improving dynamic data analysis with aspect-
oriented programming. IEEE Conference on Software Maintenance and Reengineering (CSMR). Benevento, Italy.
HANEY, F. M. (1972) Module Connection Analysis-A tool for Scheduling of Software Debugging
Activities. IEEE Software, 21, 101-103.
HARMAN, D. (1991) How effective is suffixing? Journal of the American Society for Information Science, 42, 7-15.
HARRISON, R., COUNSELL, S. J. & NITHI, R. V. (1998) An investigation into the applicability
and validity of object-oriented design metrics International Journal of Empirical Software Engineering, 3, 255 - 273.
HEINDL, M. & BIFFL, S. (2005) A Case Study on Value-based Requirements Tracing. 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering Lisbon, Portugal ACM
Press.
HUANG, L. & BOEHM, B. (2006) How Much Software Quality Investment Is Enough: A Value-
Based Approach. IEEE Software, 23, 88-95.
Tesis Doctoral Daniel Cabrero Moreno
255
HUANG, L. & BOHEM, B. (2006) How Much Software Quality Investment Is Enough: A Value-Based Approach. IEEE Software, 23, 88- 95.
IEEE (1998) Std. 830-1998 Recommended Practice for Software Requirements Specifications.
ISO (2001) ISO / IEC 9126. Software Engineering Product Quality.
JAIN, R. K. (1991) The Art of Computer Systems Performance Analysis; Techniques for Experimental Design, Measurement, Simulation and Modelling John Wiley and Sons.
JALOTE, P., VANGALA, V., SINGH, T. & JAIN, P. (2006) Program partitioning: a framework for
combining static and dynamic analysis. International Conference on Software Engineering. Shanghai, China.
JAMIT [en línea], <http://www.ovmj.org/jamit/index.html>, [Consulta: 25 enero 2009].
JCSC [en línea], <http://jcsc.sourceforge.net/>, [Consulta: 25 enero 2009].
JDEPEND [en línea], <http://clarkware.com/software/JDepend.html>, [Consulta: 25 enero
2009].
JEREMY SINGER & KIRKHAM, C. (2006) Dynamic analysis of program concepts in Java.
International symposium on Principles and practice of programming in Java. Mannheim, Germany.
JONES, C. (1998) Estimating Software Costs. en MCGRAW-HILL (Ed. New York.
JUDD, J. S. (1990) Neural network design and the complexity of learning, Cambridge, MA, USA, MIT Press.
JUNG, H.-W. (1998) Optimizing Value and Cost in Requirements Analysis. IEEE Software, 15, 74-78.
JVMI [en línea], <http://java.sun.com/j2se/1.5.0/docs/guide/jvmpi/jvmpi.html>, [Consulta: 25
enero 2009].
KAINDL, H. (1991) The missing link in requirement engineering. ACM SIGSOFT Software Engineering Notes, 18, 30-39.
KARLSSON, J. & RYAN, K. (1997) A Cost-Value Approach for Prioritizing Requirements. IEEE Software, 14, 67-64.
KARLSSON, L., HÖST, M. & REGNELL, B. (2006) Evaluating the practical use of different measurement scales in requirements prioritisation. International Symposium on Empirical Software Engineering. Rio de Janeiro, Brazil
KARLSSON, L., THELIN, T., REGNELL, B., BERANDER, P. & WOHLIN, C. (2007) Pair-wise
comparisons versus planning game partitioning-experiments on requirements
prioritisation techniques. Empirical Software Engineering, 12, 3-33.
KAZMAN, R., ASUNDI, J. & KLEIN, M. (2001) Quantifying the Costs and Benefits of
Architectural Decisions. Proceedings of the 23rd International Conference on Software Engineering. Toronto, Ontario, Canada, IEEE Computer Society.
Tesis Doctoral Daniel Cabrero Moreno
256
KAZMAN, R., ASUNDI, J. & KLEIN, M. (2002) CBAM: Making Architectural Decisions. An Economic Approach (Technical Report CMU/SEI-2002-TR-035). Software Engineering
Institute.
KAZMAN, R., KLEIN, M. & CLEMENTS, P. (2000) ATAM: Method for Architecture Evaluation (Technical Report CMU/SEI-2000-TR-004). Software Engineering Institute.
KEEPENCE, B. & MANNION, M. (1999) Using patterns to model variability in product families. IEEE Software, 16, 102-108.
KICZALES, G., HILSDALE, E., HUGUNIN, J., KERSTEN, M., PALM, J. & GRISWOLD, W. G. (2001) An overview of AspectJ. Computer Science, 2072, 327–355.
KIM, J. & KANG, S. (2008) Architecture decision based on value-based software engineering
concepts. India Software Engineering Conference. Hyderabad, India.
KNOOP, J., RÜTHING, O. & STEFFEN, B. (1994) Partial dead code elimination. ACM SIGPLAN 1994 conference on Programming language design and implementation. Orlando, Florida, United States.
KOCK, N. & LAU, F. (2001) Information Systems Action Research: Serving Two Demanding
Masters. Information Technology & People (special issue on Action Research in Information Systems), 14, 6-11.
KOGUT, B. & KULATILAKA, N. (2001) Capabilities as Real Options. Organization Science, 12, 744-758.
KOLDA, T. G. & O'LEARY, D. P. (1998) A semidiscrete matrix decomposition for latent semantic indexing information retrieval. ACM Transactions on Information Systems (TOIS), 16,
322 - 346
KOLLMANN, R. & GOGOLLA, M. (2001) Capturing Dynamic Program Behavior with UML Collaboration Diagrams. IEEE Conference on Software Maintenance and Reengineering (CSMR). Lisbon, Portugal.
KUMAR, N., CHILDERS, B. R. & SOFFA, M. L. (2006) Low overhead program monitoring and
profiling. ACM SIGPLAN-SIGSOFT. Workshop on Program Analysis for Software Tools and Engineering (PASTE).
LEE, K. & BOEHM, B. (2005) Empirical results from an experiment on value-based review (VBR)
processes. International Symposium on Empirical Software Engineering (ISESE). Noosa Heads, Australia.
LEE, Y. & CHOI, H.-J. (2005) Experience of Combining Qualitative and Quantitative Analysis
Methods for Evaluating Software Architecture. Fourth Annual ACIS International Conference on Computer and Information Science. Jeju Island, South Korea.
LEFFINGWELL, D. & WIDRIG, D. (2000) Managing Software Requirements - A Unified Approach, Addison-Wesley.
LETIER, E. & LAMSWEERDE, A. V. (2004) Reasoning about partial goal satisfaction for requirements and design engineering. Foundations of Software Engineering. Newport
Beach, CA, USA.
LEWIN, K. (1947) Frontiers in Group Dynamics. Human Relations., 1, 5-41.
Tesis Doctoral Daniel Cabrero Moreno
257
LI, J., MA, Z. & DONG, H. (2008) Monitoring Software Projects with Earned Value Analysis and Use Case Point. Seventh IEEE/ACIS International Conference on Computer and Information Science (icis 2008). Portland, Oregon, USA.
LI, W. & HENRY, S. (1993) Object-oriented metrics that predict maintainability. Journal of Systems and Software, 23, 111-122.
LING, C. X., SHENG, S., BRUCKHAUS, T. & MADHAVJI, N. H. (2005) Predicting Software Escalations with Maximum ROI. Fifth IEEE International Conference on Data Mining. Houston, Texas.
LITTLE, T. (2005) Context-Adaptive Agility: Managing Complexity and Uncertainty. IEEE Software, 22, 28-35.
LOMBARDI, C. A. & MASSAKI, C. (2008) Integrating functional metrics, COCOMO II and earned value analysis for software projects using PMBoK. ACM symposium on Applied computing. Fortaleza, Ceara, Brazil.
LORENZ, M. & KIDD, J. (1994) Object-oriented software metrics: a practical guide, Englewood
Cliffs, New Jersey.
MARINESCU, R. (2004) Detection strategies: Metrics-based rules for detecting design flaws. 20th International Conference on Software Maintenance (ICSM'04). Chicago Illinois,
USA, IEEE Computer Society.
MARTICORENA, R. & CRESPO, Y. (2008) Dynamism in Refactoring Construction and Evolution -
A Solution Based on XML and Reflection Third International Conference on Software and Data Technologies. Porto, Portugal.
MARTIN, R. C. (1996) The Dependency Inversion Principle. C++ Report, 8, 61–66.
MCCONNELL, S. (2006) Software Estimation: Demystifying the Black Art, Redmond, Wa, Microsoft Press.
MCTAGGART, R. (1991) Principles of Participatory Action Research. Adult Education Quarterly, 41.
MESSERSCHMITT, D. G. & SZYPERSKI, C. (2004) Marketplace issues in software planning and
design. IEEE Software, 21, 62-70.
MISRA, S. C. (2005) Modeling Design/Coding Factors That Drive Maintainability of Software
Systems. Software Quality Control, 13, 297 - 320.
MOCKUS, A. & WEISS, D. M. (2000) Predicting Risk of Software Changes. Bell Labs Technical Journal, April-June, 169–180.
MOHA, N. (2007) Detection and Correction of Design Defects in Object-Oriented Designs. Object-Oriented Programming, Systems, Languages and Applications (OOPSLA’07). Montréal, Québec, Canada, ACM Press.
MOHA, N., GUÉHÉNEUC, Y.-G. & LEDUC, P. (2006) Automatic Generation of Detection
Algorithms for Design Defects. 21st IEEE International Conference on Automated Software Engineering (ASE'06). Tokyo, Japan, IEEE Computer Society.
Tesis Doctoral Daniel Cabrero Moreno
258
MORGAN, C., VOLDER, K. D. & WOHLSTADTER, E. (2007) A Static Aspect Language for Checking Design Rules. 6th International Conference on Aspect-Oriented Software Development. Vancouver Canada.
MUNRO, M. J. (2005) Product Metrics for Automatic Identification of "Bad Smell" Design Problems in Java Source-Code. 11th IEEE International Software Metrics Symposium (METRICS '05). Como, Italy IEEE Computer Society.
MURPHY-HILL, E. & BLACK, A. P. (2008) Refactoring Tools: Fitness for Purpose. IEEE Software, 25, 38-44.
MUTSCHLER, B., BUMILLER, J. & REICHERT, M. (2006) Designing an economic-driven
evaluation framework for process-oriented software technologies. International Conference on Software Engineering. Shanghai, China
NEUBAUER, T., KLEMEN, M. & BIFFL, S. (2005) Business process-based valuation of IT-
security. Seventh international workshop on Economics-driven software engineering research. International Conference on Software Engineering (ICSM). St. Louis,
Missouri.
NGO-THE, A. & RUHE, G. (2003) Requirements Negotiation under Incompleteness and Uncertainty. Software Engineering and Knowledge Engineering.
NORD, R. L., BARBACCI, M. R., CLEMENTS, P., KAZMAN, R., KLEIN, M., O’BRIEN, L. & TOMAYKO, J. E. (2003) Integrating the Architecture Tradeoff Analysis Method (ATAM)
with the Cost Benefit Analysis Method (CBAM). (Technical Report CMU/SEI-2003-TN-038). Software Engineering Institute.
NORDBERG, M. E. (2001) Aspect-Oriented Indirection – Beyond OO Design Patterns. OOPSLA 2001, Workshop Beyond Design: Patterns (mis)used. Tampa Bay, Florida, EEUU.
OGATA, K. (2003) System Dynamics, Prentice Hall.
OMASREITER, H. (2007) Balanced Decision Making in Software Engineering-General Thoughts and a Concrete Example from Industry. First International Workshop on The Economics of Software and Computation. Minneapolis, Minnesota.
OMG-XMI [en línea], <http://www.omg.org/technology/documents/formal/xmi.htm>, [Consulta: 25 enero 2009].
PESCIO, C. (1997) Principles Versus Patterns. Computer Science, 30, 130-131.
PETTERSSON, N. (2005) Measuring precision for static and dynamic design pattern recognition
as a function of coverage. International Conference on Software Engineering.Workshop on Dynamic Analysis (WODA). St. Louis, Missouri.
PIGOSKY, T. M. (1997) Practical Software Maintenance, New York (EEUU), John Wiley & Sons.
PINHEIRO, F. A. C. & GOGUEN, J. A. (1996) An Object-Oriented Tool for Tracing Requirements. IEEE Software 13, 52 - 64
PMD [en línea], <http://pmd.sourceforge.net/>, [Consulta: 25 enero 2009].
PORTER, M. F. (1980) An algorithm for suffix stripping. Program, 14, 130-130.
Tesis Doctoral Daniel Cabrero Moreno
259
PURAO, S. & VAISHNAVI, V. (2003) Product metrics for object-oriented systems. ACM Computing Surveys, 35, 191 - 221.
QUANTE, J. & KOSCHKE, R. (2008) Dynamic object process graphs. Journal of Systems and Software, 81, 481-501.
REIFER, D. (2002) Making the Software Business Case, Addison Wesley.
RIEL, A. J. (1996) Object-Oriented Design Heuristics, Boston, MA, USA, Addison-Wesley Professional.
RIJSBERGEN, C. J. V. (1979) Information Retrieval, London, Butterworths.
ROTHERMEL, G., UNTCH, R. J. & CHU, C. (2001) Prioritizing Test Cases For Regression Testing.
IEEE Transactions on Software Engineering, 27, 929-948.
SAATY, T. L. (1980) The Analytic Hierarchy Process, New York, McGraw-Hill.
SAHRAOUI, H. A., GODIN, R. & MICELI, T. (2000) Can Metrics Help to Bridge the Gap Between
the Improvement of OO Design Quality and Its Automation? International Conference on Software Maintenance (ICSM'00). San José, CA, USA IEEE Computer Society.
SALTON, G. & BUCKLEY, C. (1988) Term-weighting approaches in automatic text retrieval.
Information Processing and Management: an International Journal, 24, 513-523.
SCHROEDER, M. (1999 ) Using singular value decomposition to visualise relations within multi-
agent systems. International Conference on Autonomous Agents ACM Press
SDMETRICS [en línea], <http://www.sdmetrics.com/>, [Consulta: 25 enero 2009].
SEAMAN, C. B. (1999) Qualitative Methods in Empirical Studies of Software Engineering. IEEE Transactions on Software Engineering., 25, 557-572.
SHARAFAT, A. R. & TAHVILDARI, L. (2007) A Probabilistic Approach to Predict Changes in
Object-Oriented Software Systems. International Conference in Software Maintenance and Reengineering. Amsterdam, IEEE Computer Society.
SHAW, M. (1990) Prospects for an Engineering Discipline of Software. IEEE Software Magazine, 7, 15-24.
SHAW, M., ARORA, A., BUTLER, S., POLADIAN, V. & SCAFFIDI, C. (2007) First Steps toward a
Unified Theory for Early Prediction of Software Value. IEEE Equity. Amsterdam.
SKUBLICS, S., KLIMAS, E. J. & THOMAS, D. A. (1996) Smalltalk with style, Prentice Hall.
SOUDER, T., MANCORIDIS, S. & SALAH, M. (2001) Form: a framework for creating views of program executions. IEEE International Conference on Software Maintenance (ICSM). Florence, Italy.
SRIKANTH, H. & WILLIAMS, L. (2005) On the economics of requirements-based test case prioritization. 7th international workshop on Economics-driven software engineering research St. Louis, Missouri ACM Press
STROULIA, E. & SYSTÄ, T. (2002) Dynamic analysis for reverse engineering and program
understanding. ACM SIGAPP Applied Computing Review, 10, 8 - 17.
Tesis Doctoral Daniel Cabrero Moreno
260
SULLIVAN, K. J., GRISWOLD, W. G., CAI, Y. & HALLEN, B. (2001) The Structure and Value of Modularity in Software Design. 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering. Vienna, Austria.
THELIN, T., RUNESON, P. & WOHLIN, C. (2003) Prioritized Use Cases as a Vehicle for Software
Inspections. IEEE Software, 20, 30-33.
THORP, J. (1998) The Information Paradox: Realizing the Business Benefits of Information Technology, Toronto, Mcgraw-Hill
TRAVASSOS, G. H., SHULL, F., FREDERICKS, M. & BASILI, V. R. (1999) Detecting Defects in
Object Oriented Designs: Using Reading Techniques to Increase Software Quality.
OOPSLA. Denver, CO, USA, ACM.
TSANTALIS, N., CHANTZIGEORGIOU, A. & STEPHANIDES, G. (2005) Predicting the Probability
of Change in Object-Oriented Systems. IEEE Transactions on Software Engineering, 31, 601-614.
WADSWORTH, Y. [en línea], <What is participatory Action Research? Action Research Internation, paper 2.>, [Consulta: 25 enero 2009].
WENDORFF, P. (2001) Assessment of Design Patterns during Software Reengineering: Lessons
Learned from a Large Commercial Project. Procedings of the Fifth European Conference on Software Maintenance and Reeingineering (CSMR). Lisbon, Portugal,
IEEE Computer Society.
WIEDERHOLD, G. (2006) What is your Software Worth? Communications of the ACM, 49, 65-
75.
WIEGERS, K. (1999) Software Requirements, Microsoft Press.
WILKIE, F. G. & KITCHENHAM, B. A. (2000) Coupling Measures and Change Ripples in C++
Application Software. Systems and Software, 52, 157-164.
WOOD-HARPER, T. (1985) Research Methods in Information Systems: Using Action Research.
En Mumford et al. (eds.). Research Methods in Information Systems. Amsterdam: North-Holland., 169-191.
YANG, Y., BHUTA, J., BOEHM, B. & PORT, D. N. (2005) Value-Based Processes for COTS-Based
Applications. IEEE Software, 22, 54-62.
YING, A., MURPHY, G., NG, R. & CHU-CARROLL, M. (2004) Predicting Source Code Changes by
Mining Change History. IEEE Transactions on Software Engineering, 30, 574-586.
ZIMMERMANN, T., ZELLER, A., WEIGERBER, P. & DIEHL, S. (2004) Mining Version Histories to Guide Software Changes. IEEE Transactions on Software Engineering, 31, 429-445.