Tesis Doctoral Construcción y Evolución del Software ...

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



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.


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)


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.


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


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.


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.


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


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.


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


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


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.


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


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.


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.


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.


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)


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


32

comprender las aportaciones de otros autores y las propuestas planteadas en esta Tesis

Doctoral.


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.


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.


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.


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.


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


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,


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)


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


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.


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


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.


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.


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.


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.


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.


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


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)


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.


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.


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.


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.


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.


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.


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)


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.


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.


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.


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


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


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.


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:


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.


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


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.


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


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


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.


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.


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.


72


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


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.


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.


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


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.


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


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.


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.


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


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.


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


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


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


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


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.


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.


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


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.


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.


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


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)


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


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


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


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


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


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.


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


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 €


24.485,76 €


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.


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


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é


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.


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.


106


107

Capítulo 4 – Diseño

Software Basado en

Valor


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.


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.


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


111


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


112


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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


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


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


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.


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.


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%


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


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.


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.


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


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%


I2 :Urgencia

I3: FlexibilidadClase 1

Clase 2

Clase 3

Clase 4

Clase 5

Clase 6

Clase 7

Clase 8

Clase 9


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


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


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


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.


136


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.


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


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.


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.


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.


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.


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.


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.


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


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,


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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%


I2 :Urgencia

I3: Importancia fallo

Petición 1

Petición 2

Petición 3

Petición 4


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.


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


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


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


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


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.


166


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.


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


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.


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


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.


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.


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.


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.


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


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.


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.


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


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.


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


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


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


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


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.


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.


186


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.


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


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.


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:


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


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


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.


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.


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


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.


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


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.


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.


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.


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


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.


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.


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.


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.


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


207

Objetivo 4. Proponer técnicas para la

aplicación práctica del Diseño


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


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.


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]


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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


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:


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


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.


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,


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.


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


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.


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 )


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


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


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


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


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.


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


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


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.


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


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.


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.


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.


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.


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



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

. =


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


max es calculado calculando la media de los elementos del vector resultante en la

Ecuación 8-8.


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


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.


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


246


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


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


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.


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.


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


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

http://cobertura.sourceforge.net/%3e

http://checkstyle.sourceforge.net/%3e

http://doctorj.sourceforge.net/%3e


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.

http://www.eclipse.org/%3e

http://www.eclipse.org/modeling/emf/%3e

http://emma.sourceforge.net/%3e

http://www.win.tue.nl/empanada/%3e

http://findbugs.sourceforge.net/%3e


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.


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.

http://www.ovmj.org/jamit/index.html%3e

http://jcsc.sourceforge.net/%3e

http://clarkware.com/software/JDepend.html%3e

http://java.sun.com/j2se/1.5.0/docs/guide/jvmpi/jvmpi.html%3e


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.


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.


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.

http://www.omg.org/technology/documents/formal/xmi.htm%3e

http://pmd.sourceforge.net/%3e


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.

http://www.sdmetrics.com/%3e


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.

Tesis Doctoral Construcción y Evolución del Software ...

Documents

Transcript of Tesis Doctoral Construcción y Evolución del Software ...