Mejores practicas

Instituto Nacional de Tecnologías de la Comunicación

GUÍA DE MEJORES PRÁCTICAS DE CALIDAD DE PRODUCTO

Junio 2008

Instituto Nacional de Tecnologías de la Comunicación

AVISO LEGAL •

CMMI® es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad Carnegie Mellon

•

ISTQB® es una marca registrada en la Oficina de Propiedad Intelectual de UK por The British Computer Society

•

Windows® es una marca registrada de Microsoft Corporation en EEUU y otros países

•

Las distintas normas ISO mencionadas han sido desarrolladas por la International Organization for Standardization.

Todas las demás marcas registradas que se mencionan, usan o citan en la presente guía son propiedad de los respectivos titulares. INTECO cita estas marcas porque se consideran referentes en los temas que se tratan, buscando únicamente fines puramente divulgativos. En ningún momento INTECO busca con su mención el uso interesado de estas marcas ni manifestar cualquier participación y/o autoría de las mismas. Nada de lo contenido en este documento debe ser entendido como concesión, por implicación o de otra forma, y cualquier licencia o derecho para las Marcas Registradas deben tener una autorización escrita de los terceros propietarios de la marca. Por otro lado, INTECO renuncia expresamente a asumir cualquier responsabilidad relacionada con la publicación de las Marcas Registradas en este documento en cuanto al uso de ninguna en particular y se eximen de la responsabilidad de la utilización de dichas Marcas por terceros. El carácter de todas las guías editadas por INTECO es únicamente formativo, buscando en todo momento facilitar a los lectores la comprensión, adaptación y divulgación de las disciplinas, metodologías, estándares y normas presentes en el ámbito de la calidad del software.

Guía de mejores prácticas de calidad de producto

2

Instituto Nacional de Tecnologías de la Comunicación

ÍNDICE 1. 

INTRODUCCIÓN 1.1. 

2. 

Gestión de calidad del SW

10 

1.1.1. 

12 

Calidad del producto

1.2. 

QA vs. QC

13 

1.3. 

Descripción del contenido

15 

1.4. 

Evolución de la guía

16 

GESTIÓN EFECTIVA DE LA CALIDAD DEL PRODUCTO

17 

2.1. 

Introducción

17 

2.2. 

Gestión de requisitos

19 

2.2.1. 

Definición y tipos

20 

2.2.2. 

Evolución de los requisitos

23 

2.2.3. 

Gestión de requisitos

25 

Optimización de la estrategia de pruebas

28 

2.3.1. 

Estrategia de pruebas

28 

2.3.2. 

Estimación del esfuerzo

33 

2.3.3. 

Valoración del riesgo

38 

2.3. 

3. 

9 

2.4. 

Diseño de pruebas

44 

2.5. 

Gestión de defectos

49 

2.6. 

Gestión de la puesta en marcha

53 

VERIFICACIÓN Y VALIDACIÓN

56 

3.1. 

Introducción

56 

3.2. 

Niveles de pruebas

57 

3.3. 

Tipos de pruebas

68 

3.4. 

Técnicas de pruebas

73 

3.4.1. 

Dinámicas

74 

3.4.2. 

Estáticas

91 

3.4.2.1.  Proceso de una revisión

3.5. 

92 

3.4.2.2.  Tipos de revisiones

100 

3.4.2.3.  Factores de éxito de una revisión

103 

3.4.2.4.  Análisis estático

105 

Enfoque desde distintas metodologías

108 

3.5.1. 

SPICE

108 

3.5.2. 

CMMI®

110 

Guía de mejores prácticas de calidad de producto

3

Instituto Nacional de Tecnologías de la Comunicación

3.5.3.  4. 

113 

4.1. 

Introducción

113 

4.2. 

Fundamentos de la medición del software

114 

4.3. 

Definición de métricas

119 

4.3.1. 

Buenas prácticas

119 

4.3.2. 

Definición de métricas basada en metodología CMMI®

125 

4.3.3. 

Definición de métricas basada en metodología SPICE

131 

4.3.4. 

Otros métodos de definición de métricas

136 

Métricas de calidad de producto habituales

142 

4.4.1. 

Métricas de calidad de producto en desarrollo

143 

4.4.2. 

Métricas de calidad de producto final

146 

4.4.3. 

Métricas de mantenimiento de software

152 

PUBLICACIÓN Y DIFUSIÓN

154 

5.1. 

Introducción

154 

5.2. 

KPI (Key Performance Indicator) – Elemento de medición del rendimiento 155 

5.3. 

6. 

112 

MEDICIÓN DE LA CALIDAD DEL SOFTWARE

4.4. 

5. 

Comparativa

5.2.1. 

Introducción: Qué son. Características generales.

155 

5.2.2. 

Definir KPI en proyectos

157 

Cuadros de mando – Publicación de KPIs

159 

5.3.1. 

161 

Mejores prácticas para construir cuadros de mando

5.4. 

Balanced Scorecard

164 

5.5. 

Integración de Balanced Scorecard con modelos de calidad

166 

5.5.1. 

166 

Balanced IT Scorecard de ESI

PLANTILLAS / GUÍAS RÁPIDAS

168 

6.1. 

Plantilla del plan de calidad

168 

6.2. 

Plantillas relacionadas con los requisitos

168 

6.2.1. 

Plantilla del Plan de gestión de requisitos

168 

6.2.2. 

Plantilla de Registro de requisitos del cliente

168 

6.2.3. 

Plantilla de Especificación de objetivos y requisitos

169 

6.2.4. 

Plantilla de Especificación de requisitos

169 

6.3. 

Plantillas relacionadas con las pruebas

169 

6.3.1. 

Plantilla del Plan de pruebas

169 

6.3.2. 

Plantilla de Caso de prueba

169 

6.3.3. 

Plantilla de Especificación de pruebas

169 

Guía de mejores prácticas de calidad de producto

4

Instituto Nacional de Tecnologías de la Comunicación

6.3.4.  6.4. 

6.5.  6.6.  6.7. 

Plantilla de Registro de ejecución de pruebas

170 

Plantillas relacionadas con la gestión y seguimiento de fallos

170 

6.4.1. 

Plantilla de Informe de fallos en las pruebas

170 

6.4.2. 

Plantilla de Informe de incidencias

170 

6.4.3. 

Plantilla de Registro de fallos

170 

Plantillas relacionadas con métricas

170 

6.5.1. 

170 

Plantilla de plan de medición

Plantillas relacionadas con la publicación y difusión

171 

6.6.1. 

Plantilla de recogida de KPIs

171 

Plantillas relacionadas con la gestión de riesgos

171 

6.7.1. 

Plantilla de la Estrategia de gestión de riesgos

171 

6.7.2. 

Plantilla de Registro de riesgos

171 

7. 

GLOSARIO

172 

8. 

BIBLIOGRAFÍA

186 

Guía de mejores prácticas de calidad de producto

5

Instituto Nacional de Tecnologías de la Comunicación

ÍNDICE DE TABLAS Tabla 1 

Comparativa QA vs QC

Tabla 2  Tabla 3  Tabla 4  Tabla 5  Tabla 6  Tabla 7  Tabla 8  Tabla 9  Tabla 10  Tabla 11  Tabla 12  Tabla 13  Tabla 14  Tabla 15  Tabla 16  Tabla 17  Tabla 18 

Análisis del impacto del negocio Probabilidad de fallo Cálculo de las categorías Tipos de procedimientos y su nivel de riesgo Ejemplo de particiones de equivalencia Particiones de equivalencia Ejemplo particiones de equivalencia y valores frontera I Ejemplo particiones de equivalencia y valores frontera II Estructura de una tabla de decisión Ejemplo de tablas de decisión Representación de un diagrama de transición de estados Tabla de estados Caso de uso parcial para la introducción del PIN Factores de éxito de una revisión formal Comparativa Validación-Verificación desde enfoques CMMI® y SPICE Métricas de negocio Métricas de proceso

39  40  40  41  78  79  80  80  82  83  84  87  88  105  112  124  125 

Tabla 19  Tabla 20 

Comparativa entre índice de defectos y problemas del cliente(PUM) Comparativa entre dashboard y scorecard

149  161

Guía de mejores prácticas de calidad de producto

15 

6

Instituto Nacional de Tecnologías de la Comunicación

ÍNDICE DE FIGURAS Figura 1  Figura 2  Figura 3  Figura 4  Figura 5  Figura 6  Figura 7 

Elementos influyentes sobre la calidad Gestión de la calidad Ciclo de vida de la calidad del producto Control de la calidad Aseguramiento de la calidad Paralelismo entre el ciclo de vida del SW y el de calidad del producto Creación de requisitos

10  11  13  14  14  19  25 

Figura 8  Figura 9  Figura 10  Figura 11  Figura 12  Figura 13  Figura 14  Figura 15  Figura 16  Figura 17  Figura 18  Figura 19  Figura 20  Figura 21  Figura 22  Figura 23 

Automatización: Ventajas vs Coste Cálculo del nivel óptimo de automatización Automatización vs Coste Análisis del riesgo durante la gestión de pruebas Componentes de un caso de prueba Detección de defectos en las distintas fases de desarrollo Introducción de defectos en las etapas de desarrollo Ciclo de vida del informe de incidencias Criterio de salida a producción Pruebas dentro del ciclo de vida del SW Modelo en cascada Modelo en V Desarrollo iterativo Pruebas unitarias Servicio de pruebas unitarias Estructura de control top-down

31  37  37  38  46  49  50  52  54  57  58  59  60  61  62  63 

Figura 24  Figura 25  Figura 26  Figura 27  Figura 28  Figura 29  Figura 30  Figura 31  Figura 32  Figura 33  Figura 34  Figura 35  Figura 36  Figura 37  Figura 38 

Estructura de control bottom-up Servicio de pruebas de integración Servicio de pruebas de sistema Servicio de aceptación de usuario Pruebas de caja negra Características y sub características de calidad según ISO 9126 Pruebas de caja blanca Clasificación de técnicas dinámicas Ejemplo de transición de estados Fases de una revisión formal Actividades de la fase de planificación de una revisión Tipos de revisión en función del nivel de formalidad Medición y análisis (CMMI®) Gestión cuantitativa de proyectos (CMMI®) Ejecución de Procesos Organizacionales (CMMI®)

Guía de mejores prácticas de calidad de producto

64  65  66  68  69  71  71  75  85  95  97  100  128  130  131 

7

Instituto Nacional de Tecnologías de la Comunicación

Figura 39  Marco para un proceso de medición Figura 40  Programa de medición según PSM Figura 41  Modelo de información de la medición según PSM

134  138  139 

Figura 42  Figura 43  Figura 44  Figura 45  Figura 46  Figura 47  Figura 48  Figura 49  Figura 50 

140  142  146  150  156  162  163  165  167 

Descripción de los 6 pasos del proceso GQM Ejemplo de preguntas y métricas relacionadas con una meta Curva S del progreso de pruebas Perspectivas de la calidad del producto Desarrollo de KPIs Ejemplo datos sin contexto Ejemplo datos con contexto Perspectiva del Balanced Scorecard Componentes de cada perspectiva

Guía de mejores prácticas de calidad de producto

8

Instituto Nacional de Tecnologías de la Comunicación

1.

INTRODUCCIÓN

“Calidad es la idoneidad de uso. Es decir, las características del producto que satisfacen las necesidades del cliente y por tanto producen satisfacción de producto. La calidad es la inexistencia de deficiencias” - Juran “La calidad se define desde el punto de vista del cliente, como cualquier cosa que aumenta su satisfacción” – Deming “La calidad es la totalidad de características de un producto o servicio que tienen la capacidad de satisfacer necesidades explícitas o implícitas”- ANSI “Nivel al que una serie de características inherentes satisfacen los requisitos”- ISO 9000:2000 ISO 8402 define calidad como: “Conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explícitas o implícitas.” CMMI® define calidad como: “La capacidad de un conjunto de características inherentes de un producto, o componente del producto, o proceso, de satisfacer por completo los requisitos del cliente.” El mercado de las TI ha experimentado un gran crecimiento. Sin embargo, aunque se produce mucho software, todavía existe un gran desconocimiento de las metodologías y estrategias de calidad que conseguirían mejores resultados en esa producción, tanto en la calidad final de los productos como en los procesos que llevan a su creación. El concepto de calidad tiene varias definiciones formales. Algunas de ellas ponen mayor énfasis en el producto y otras en el cliente o el servicio. Sin embargo, todas tienen un mensaje común, que es el de obtener una mejora, ya sea en un producto software, o los procesos que llevan a la creación del mismo. Para aumentar la calidad se establecen una serie de metodologías formales y buenas prácticas que permiten tener control sobre lo que está ocurriendo a distintos niveles y así poder evaluarlo y mejorarlo. Gracias a ellas, se consigue no sólo que el producto final tenga las características que deseamos (robustez, usabilidad, corrección, fiabilidad, etc.) sino que los procesos asociados se vean afectados positivamente y los tiempos de entrega disminuyan, los costes se reduzcan y la satisfacción del cliente final aumente. Las métricas y herramientas complementan estos procesos y ayudan a la mejora de la calidad. Esta guía de mejores prácticas relacionadas con la mejora de la calidad de software pretende servir como punto de partida y futura referencia para la introducción de modelos de

Guía de mejores prácticas de calidad de producto

9

Instituto Nacional de Tecnologías de la Comunicación

calidad en la empresa. Pretende ser un referente integrador de las diferentes mejores prácticas y metodologías que están presentes en los procesos de calidad del software. Todos los modelos o metodologías que se plantean en esta guía ya están presentes en el mercado.

1.1.

GESTIÓN DE CALIDAD DEL SW

Calidad del software: ‐

“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente” R.S.Pressman (1992)

La Gestión de la Calidad es el conjunto de actividades que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema de calidad. Estas actividades están relacionadas con el aseguramiento de que un producto consiga el nivel de calidad requerido. Incluyen la definición adecuada de estándares y procesos de calidad y el cumplimiento de los mismos. Deberían estar dirigidas a desarrollar una cultura de calidad donde ésta se vea como una responsabilidad de todo el mundo. Entre las actividades que se llevan a cabo en la gestión de la calidad están el Aseguramiento de la Calidad, la Planificación de la Calidad, el Control de la Calidad, etc. Hay cuatro elementos que influyen de manera importante sobre la calidad: Procesos y prácticas

Medidas y Métricas

Herramientas

Figura 1

Personas

Elementos influyentes sobre la calidad

Los elementos clave relacionados con la calidad son: ‐

Procesos y (buenas) prácticas: La calidad aumenta al aplicar una serie de procesos o metodologías y (buenas) prácticas. Controlan el proceso para poderlo analizar y mejorar.

‐

Herramientas: Proporcionan apoyo a la gestión de la calidad

Guía de mejores prácticas de calidad de producto

10

Instituto Nacional de Tecnologías de la Comunicación

‐

Personas: Son elementos clave en la calidad como creadores y ejecutores.

‐

Medidas y métricas: Son los datos los que permiten evaluar el estado actual y ejecutar acciones para mejorar.

Niveles de gestión de la calidad La calidad del software puede gestionarse a distintos niveles: ‐

A nivel de producto: cuando nos centramos en el proceso de desarrollo de software y hacemos una serie de pruebas en paralelo con cada etapa, para detectar y corregir los posibles defectos que puedan surgir.

‐

A nivel de proyecto: cuando nos centramos en controlar todas las fases y áreas de gestión de proyecto, implantando metodologías y mejores prácticas que aseguren la correcta gestión de las mismas.

‐

A nivel de proceso: cuando nos centramos en gestionar todas las áreas de proceso de una organización, mediante la implantación de una metodología. De esta forma se consigue tener mayor información de los procesos de modo que puedan controlarse y mejorarse, y produzcan así, un aumento de la calidad de los productos y servicios relacionados con ellos.

GESTIÓN DE LA CALIDAD GESTIÓN de PROCESO SPICE

CMMI

GESTIÓN de PROYECTO Gestión de la Gestión del Gestión del Gestión de Gestión de alcance tiempo la calidad integración RRHH

Gestión de la Gestión de costes comunicación

Gestión del Gestión de la riesgo logística

GESTIÓN de PRODUCTO GESTIÓN de REQUISITOS

Requisitos de Negocio

Requisitos de Pruebas

Estrategia De Pruebas

Definir Casos de Uso

PRUEBAS FUNCIONALES

Crear/automatizar casos de prueba

Ejecutar escenarios de prueba

PRUEBAS RENDIMIENTO

Evaluar

Analizar resultados Informar defectos

Planificar capacidad

PRUEBAS SEGURIDAD

Probar Diagnosticar seguridad problemas Incidencia

Incidencia

Def ectos

Crear plan de pruebas

Diagnosticar problemas

Ajuste

Planificar seguridad

Ajuste

METRICAS de CALIDAD PUBLICACIÓN y DIFUSIÓN - KPIs

DISEÑO y DESARROLLO

Figura 2

Guía de mejores prácticas de calidad de producto

Gestión de la calidad

11

Instituto Nacional de Tecnologías de la Comunicación

En esta primera versión de la guía se va a hacer hincapié en la calidad del software a nivel de producto, como primer paso para abordar la calidad. En futuras guías se pondrá el foco sobre la gestión de proyecto y de proceso.

1.1.1.

Calidad del producto

La calidad del producto software es una preocupación cada vez mayor en el ámbito de las tecnologías de la información. Actualmente, la satisfacción hacia el uso de un producto puede marcar una gran diferencia en el mercado de productos similares. Es así como el desarrollo de artículos que satisfacen las expectativas de los clientes y usuarios harán la diferencia entre dos organizaciones que desarrollan productos que compiten en el mercado. La preocupación por ofrecer productos acompañados de altos niveles de calidad no es una actividad nueva. A lo largo de este siglo han surgido distintas interpretaciones de cómo brindar calidad. El desarrollo de productos software no está ausente de ofrecer calidad. Dicho nivel de calidad, incluido en los productos, considera muchas actividades dentro del desarrollo de los proyectos software. La calidad en la ingeniería del software, que depende en gran medida de la pericia del equipo que lo desarrolla, puede definirse como un conjunto de características o cualidades, tales como: eficiencia, fiabilidad, usabilidad, funcionalidad, mantenibilidad, portabilidad, etc., variando la importancia de cada una de ellas de un producto a otro. Dicho de otra manera, es el cumplimiento de los requisitos contractuales por parte del producto software desarrollado, así como durante el proceso de desarrollo. El concepto de calidad en los productos software debe formularse de forma particular. Hay que destacar que el producto software tiene características diferenciadoras de otros productos. El software se desarrolla, no se fabrica en el sentido clásico, es inmaterial y no se deteriora con el uso o el tiempo (aunque tiene un ciclo de vida). Su fiabilidad es difícil de comprobar. La mayoría del software se desarrolla a medida y necesita actualizaciones permanentes, además es dependiente del entorno donde se ejecuta. Todas estas características hacen del producto software algo particular. La calidad de un producto software puede medirse en diferentes aspectos: ‐

Interna: calidad medible a partir de las características intrínsecas, como el código fuente.

‐

Externa: calidad medible en el comportamiento del producto, como en una prueba.

‐

En uso: durante la utilización efectiva por parte del usuario.

Para poder ofrecer un producto software de calidad, las empresas tienen que hacer hincapié en todo el ciclo de vida del producto.

Guía de mejores prácticas de calidad de producto

12

Instituto Nacional de Tecnologías de la Comunicación PUERTAS DE CALIDAD

CICLO DE VIDA GENÉRICO DEL SOFTWARE

PLANIFICACIÓN

DISEÑO

ESTRATEGIA DE PRUEBAS

CODIFICACIÓN

Pruebas sistema

Pruebas unitarias

DISEÑO DE PRUEBAS

Pruebas integración

GESTIÓN DE REQUISITOS

LIBERACIÓN DEL PRODUCTO

PRUEBAS

CIERRE

GESTIÓN DE PUESTA EN MARCHA

UAT

PRUEBAS DE RENDIMIENTO Verificación de requisitos PRUEBAS DE SEGURIDAD

CICLO DE VIDA DE LA CALIDAD DEL PRODUCTO

SEGUIMIENTO DE DEFECTOS Y GESTIÓN DE CAMBIOS MÉTRICAS y KPIS

Figura 3

Ciclo de vida de la calidad del producto

Hay que empezar por un buen entendimiento y recogida de los requisitos del cliente, hasta llegar a pruebas de aceptación de usuario, una vez que el software está desarrollado. En la figura anterior se muestra las etapas del ciclo de vida del proyecto y los distintos tipos de pruebas que se pueden llevar a cabo para conseguir un software de calidad.

1.2.

QA VS. QC

El Aseguramiento de la Calidad (QA) y el Control de la Calidad (QC) son dos conceptos muy importantes dentro de la gestión de la calidad, los cuales no siempre están bien definidos y no se tiene una idea clara de cuáles son las diferencias entre ellos. En este apartado se van a definir ambos conceptos haciendo hincapié en las diferencias existentes entre ellos. El Control de la Calidad es el conjunto de técnicas operativas y actividades utilizadas para cumplir con las demandas o requisitos de la calidad.

Guía de mejores prácticas de calidad de producto

13

Instituto Nacional de Tecnologías de la Comunicación

Pasos típicos del QC Gestión de problemas

Identificación de problemas

Análisis de problemas

Corrección de problemas

Retroalimentación a QA

Salida a QA

Figura 4

Control de la calidad

El Aseguramiento de la Calidad se entiende como el conjunto de actividades planificadas y sistemáticas necesarias para proporcionar la confianza suficiente de que un producto o servicio satisfará los requisitos de calidad. Pasos típicos del QA Entrada de QC

Recolección de datos

Análisis de tendencias de problemas

Identificación de procesos

Mejora de procesos

Figura 5

Guía de mejores prácticas de calidad de producto

Análisis de procesos

Aseguramiento de la calidad

14

Instituto Nacional de Tecnologías de la Comunicación

En el cuadro que se muestra a continuación aparece una comparativa entre ambos conceptos y algunas actividades que se pueden llevar a cabo dentro de ellos: QA – Aseguramiento de la calidad • • • • •

QC – Control de la calidad

Preventivo y proactivo Orientado a proceso Responsabilidad a nivel de la organización Identifica las debilidades de ciertos procesos y las mejora Evalúa si QC funciona o no

• • • •

Reactivo Orientado a producto o servicio Responsabilidad a nivel del equipo de control Verifica si los atributos especificados están presentes en el producto o no

ACTIVIDADES • • • •

Tabla 1

1.3.

• • •

Auditorías de procesos Definiciones de procesos Selección de herramientas Formación

Revisiones Inspecciones Ejecución de pruebas

Comparativa QA vs QC

DESCRIPCIÓN DEL CONTENIDO

En esta guía, en el capítulo 2, se verá cómo gestionar la calidad de producto teniendo en cuenta que debe considerarse como un proceso paralelo al de desarrollo del producto, desde la planificación hasta la entrega del producto. Se explicará la importancia de realizar una buena gestión de los requisitos del producto. Es clave lograr un entendimiento de los requisitos por todas las partes implicadas para que el producto tenga éxito. En primer lugar, se presentarán los distintos tipos de requisitos que hay que tener en cuenta a la hora de especificar el producto, así como buenas prácticas y técnicas que ayuden a realizar esta especificación: prototipos, escenarios, documentación, etc. Es importante asegurarse de que los requisitos están bien definidos antes de comenzar el desarrollo y, por ello, es necesario verificarlos de acuerdo a unos criterios de aceptación que se expondrán también en este capítulo. En la etapa de planificación, es necesario contemplar y planificar la estrategia de pruebas que se va a seguir en el proyecto. En esta guía se explicarán algunas de las estrategias más importantes, tanto de tipo preventivo como reactivo, y qué factores se deben considerar a la hora de elegir la estrategia más adecuada. Una vez elegida, se deberá estimar el esfuerzo y, para ello, se mencionarán algunas técnicas de estimación, así como factores que afectan al esfuerzo de pruebas. La valoración de los riesgos también determinará el enfoque y procedimiento a seguir en las pruebas. Durante la etapa de diseño, se especificarán los casos de prueba. En esta guía se explicará una técnica para diseñar las pruebas con la ayuda de un modelo de comportamiento.

Guía de mejores prácticas de calidad de producto

15

Instituto Nacional de Tecnologías de la Comunicación

La gestión de los defectos es un proceso que se ejecuta durante todo el ciclo de vida. Se hará hincapié en la importancia de detectar estos defectos en etapas tempranas del proceso de desarrollo para que el coste de su corrección sea menor. Como última etapa, antes de entregar el producto, habrá que gestionar cómo se va llevar a cabo su puesta en marcha. En este sentido, se indicarán una serie de acciones y criterios a tener en cuenta y en qué consiste la última fase de pruebas - pruebas de disponibilidad operativa. Entre el diseño de las pruebas y las pruebas de disponibilidad operativa hay toda una serie de niveles de pruebas sobre el producto (unitarias, integración, sistema, aceptación) que se expondrán en el capítulo 3. También se describirán los distintos tipos de pruebas que se pueden realizar según el objetivo de las mismas (funcionales, no funcionales, estructurales, relacionadas con cambios). Además, se explicarán ampliamente algunas técnicas de pruebas, indicando cuáles son más adecuadas para encontrar qué tipo de defectos. Se verá cómo tratan este aspecto de verificación y validación del producto dos de los principales modelos de calidad como son CMMI® y SPICE. En el capítulo 4 se hablará de la importancia de la medición del software, por qué es fundamental recoger métricas para controlar el proyecto y poder mejorar. Esta guía pretende resaltar unas buenas prácticas y lecciones aprendidas en esta área y cómo algunos modelos muy extendidos pueden servir de guía para implantar un programa de medición en una organización. También se mencionarán algunas de las métricas más habituales sobre calidad de producto, de forma que puedan servir como ejemplo y referencia. Por último, en el capítulo 5, se definirá el concepto de KPI (Key Performance Indicator) como indicador de rendimiento alineado con los objetivos estratégicos de una organización y cómo monitorizar, controlar y gestionar los procesos de una organización a través de estos indicadores mediante herramientas como son los cuadros de mando, que contribuyen a la publicación y difusión del progreso de una organización hacia sus metas.

1.4.

EVOLUCIÓN DE LA GUÍA

Con la edición de esta guía, se pretende iniciar la elaboración de un conjunto de materiales genéricos – como la presente guía – y temáticos orientados a facilitar el conocimiento necesario para abordar con garantías el conjunto de actividades relacionadas con la calidad del software. De este modo, siguiendo el hilo conductor descrito en el apartado Gestión de calidad del SW, se ha partido de la calidad del producto como punto de inicio de estos contenidos. El Laboratorio Nacional de Calidad del Software pretende cubrir los diferentes escenarios de la calidad del software desde diversos prismas e interpretaciones. Así, partiendo de la calidad del producto se irán avanzando en diferentes áreas (gestión de la configuración, gestión de riegos, gestión de costes,….) hasta alcanzar los modelos de referencia en la industria relacionados con la mejora de procesos y certificación.

Guía de mejores prácticas de calidad de producto

16

Instituto Nacional de Tecnologías de la Comunicación

2.

GESTIÓN EFECTIVA DE LA CALIDAD DEL PRODUCTO “¿Por qué es tan cara la tecnología de la información (TI) cuando los costes del hardware están cayendo y el desarrollo de las tecnologías está mejorando la productividad?” “¿Por qué los proyectos con éxito tienen éxito?” “¿Por qué es tan importante la involucración del usuario?” “¿Por qué es más perjudicial cuanto más tarde se detecten y arreglen los defectos?” “¿Por qué no se usa todo el conocimiento que hay sobre la gestión de la calidad del producto para mejorar su proceso de pruebas?”

2.1.

INTRODUCCIÓN

“La calidad no puede tenerse en cuenta únicamente al final del proyecto ya que sería demasiado tarde. La calidad es el resultado de un proceso bien gestionado y bien organizado” La gestión de calidad es un método para asegurar que todas las actividades necesarias para diseñar, desarrollar e implementar un producto o servicio son eficaces y eficientes con respecto al sistema y su rendimiento. Hoy en día las compañías son cada vez más conscientes de la importancia de una buena gestión de calidad de sus productos. Existen multitud de estadísticas que demuestran con datos esta realidad. Un ejemplo son los resultados del informe CHAOS 1 del Standish Group que es una de las estadísticas más reconocidas a nivel mundial. El informe trata de dar a conocer el alcance de los fallos en el desarrollo de las aplicaciones de software, los factores que causan fallos en los proyectos y reconocer los ingredientes claves para reducir estos fallos. Menos de un tercio de todos los proyectos TI a nivel mundial cumplen sus objetivos y cerca del 20% fallan provocando enormes costes financieros y de recursos. Según el estudio, uno de los factores que más afecta a los proyectos de software es la forma de implementar y ejecutar la gestión de la calidad. A pesar de los avances en procesos TI y en la tecnología, los proyectos casi siempre finalizan fuera del tiempo establecido y no disminuyen sus costes. En la actualidad los proyectos son cada vez más complejos y la necesidad de una mejora en su gestión y una adecuada planificación es cada vez mayor, sobre todo cuando hay fuertes restricciones de

1 El Standish Group International anunció en el 2006 la disponibilidad de su último informe CHAOS. Este informe es un estudio del éxito y fracaso de los proyectos, y comenzó en 1994.

Guía de mejores prácticas de calidad de producto

17

Instituto Nacional de Tecnologías de la Comunicación

presupuesto y tiempo. En la mayoría de los casos cuando el tiempo escasea la gente tiende a sacrificar la calidad del producto y esto es un claro error. La gestión de calidad de un producto se ha de llevar a cabo durante todo su ciclo de vida, es decir, ha de apoyar las distintas etapas del proceso de creación, desde su planificación hasta su liberación. Como se ve en la figura siguiente, la gestión de calidad del producto es un proceso que va en paralelo con el ciclo de vida del producto. Durante la etapa de planificación es imprescindible especificar los requisitos de forma clara y precisa ya que de ello dependerá cómo es el producto final y por lo tanto la satisfacción del cliente. Los requisitos tienden a evolucionar con el tiempo por lo que es importante llevar a cabo una gestión de los mismos estableciendo desde un principio unos criterios de aceptación para su correcta verificación. En esta etapa, también es importante establecer una buena estrategia de pruebas, seleccionar las técnicas adecuadas de estimación en función de los factores que afecten a las pruebas del proyecto y realizar la valoración oportuna de los riesgos que conlleva el proyecto, gestionarlos y mitigarlos en los casos en que sea necesario. La siguiente fase de desarrollo es el diseño del producto que trae consigo el diseño de casos de pruebas. En esta fase de la gestión de la calidad es recomendable el uso de un modelo de comportamiento que ayude al correcto diseño e implementación de las pruebas. Durante las siguientes fases de codificación y pruebas del producto se ejecutan las pruebas de sistemas, de integración, etc., de las que se hablará en el capítulo 3 (validación y verificación). Una vez que el software ha superado las pruebas oportunas, se libera el producto, gestionando antes su puesta en marcha para verificar que su calidad es la adecuada, y se definen estrategias a seguir para posibles mejoras, nuevas funcionalidades del producto, solicitudes de cambio, mantenimiento del producto, etc. Por último, y no por ello menos importante, la gestión de defectos es un proceso que se ejecuta durante todas las fases del ciclo de vida del producto. La detección y corrección temprana de los defectos suele suponer un importante ahorro de dinero, lo cual es uno de los objetivos principales de los proyectos. También se recogerán métricas y KPIs durante todas las fases, para tener un control acerca de la evolución del proyecto y obtener datos significativos que puedan utilizarse en otros proyectos o fases del mismo. En los apartados que siguen, se intentará explicar detalladamente todo el proceso de gestión de la calidad del producto teniendo en mente que se va a llevar a cabo de forma paralela al propio desarrollo del producto.

Guía de mejores prácticas de calidad de producto

18

Instituto Nacional de Tecnologías de la Comunicación PUERTAS DE CALIDAD

CICLO DE VIDA GENÉRICO DEL SOFTWARE

PLANIFICACIÓN

ESTRATEGIA DE PRUEBAS

DISEÑO

DISEÑO DE PRUEBAS

CODIFICACIÓN

Pruebas sistema

Pruebas unitarias

Pruebas integración

GESTIÓN DE REQUISITOS

LIBERACIÓN DEL PRODUCTO

PRUEBAS

CIERRE

GESTIÓN DE PUESTA EN MARCHA

UAT

PRUEBAS DE RENDIMIENTO Verificación de requisitos PRUEBAS DE SEGURIDAD

CICLO DE VIDA DE LA CALIDAD DEL PRODUCTO

SEGUIMIENTO DE DEFECTOS Y GESTIÓN DE CAMBIOS MÉTRICAS y KPIS

Figura 6

2.2.

Paralelismo entre el ciclo de vida del SW y el de calidad del producto

GESTIÓN DE REQUISITOS

Los mejores productos, desde el punto de vista del usuario, son aquellos creados por desarrolladores que tienen muy claro lo que se pretende conseguir con el producto y cómo obtenerlo. Para llegar a este punto, se debe entender el trabajo del usuario, cómo afectará el producto a su trabajo y cómo se adecuará a los objetivos de la organización. Lo que hace el producto y las condiciones que debe satisfacer en este contexto son los requisitos del producto. Excepto en unos cuantos casos fortuitos, ningún producto tendrá éxito sin un claro entendimiento previo de sus requisitos. No importa el tipo de trabajo del usuario, ni tampoco qué lenguaje de programación o herramientas de desarrollo serán usadas para construir el producto. Si no se entiende cómo se quiere que el producto sea y funcione, no se podrá construir correctamente. En este caso, el proceso de desarrollo es irrelevante. Los requisitos del producto deben ser entendidos por todas las partes (cliente y desarrollador) antes de que comience su construcción o el proyecto fracasará. Sólo cuando se conocen los requisitos correctos se podrá diseñar y construir un producto que permita a los usuarios hacer su trabajo de forma que satisfaga las necesidades del negocio. Por desgracia, los requisitos no son siempre entendidos correctamente. Existen muchos estudios que lo demuestran, por ejemplo, de acuerdo con el Instituto Nacional de

Guía de mejores prácticas de calidad de producto

19

Instituto Nacional de Tecnologías de la Comunicación

Estándares y Tecnología de Estados Unidos, los requisitos incompletos, imprecisos y conflictivos normalmente causan un 70% de los defectos de una aplicación. Aunque los desarrolladores tienen la oportunidad de subsanar la mayoría de los errores en la definición de requisitos, muchas veces se precipitan o hacen suposiciones que, como consecuencia, dan lugar a un producto erróneo. Todo lo anterior puede ser debido a varios motivos como falta de tiempo o de presupuesto, tal y como se explica más adelante. Como resultado, el coste del producto se multiplicará cosa que no ocurriría si se cumpliera con un análisis correcto de los requisitos. El proceso de búsqueda de requisitos es una exploración minuciosa del producto con la intención de descubrir su funcionalidad y comportamiento. El resultado de este proceso es una descripción, preferiblemente escrita, de los requisitos que serán usados como entradas del diseño del producto. Los requisitos normalmente se expresan de una manera tecnológicamente neutra para evitar influenciar el diseño de la solución. Los requisitos son un puro comunicado de las necesidades del negocio sin ninguna predisposición sobre la implementación. El papel del diseño del producto es traducir los requisitos en un plan que determina los dispositivos que van a usarse, los componentes de software necesarios y cómo serán construidos. Para que el producto tenga éxito es importante que la decisión final sobre el diseño no sea tomada hasta que los requisitos más relevantes estén claros y definidos. Una vez que el producto se ha construido y se empieza a usar, empieza a evolucionar. Los usuarios demandan más funcionalidad y el producto debe ser capaz de crecer alojando las nuevas demandas. La evolución de un producto y de sus requisitos es un proceso que no se puede controlar, pero es algo que hay que aceptar. Los requisitos de un producto no se congelan en el momento éste se construye sino que evolucionan durante un periodo de tiempo.

2.2.1.

Definición y tipos

Hasta el momento hemos usado el término requisitos de forma muy general pero ¿qué definición se les podría dar y qué tipos de requisitos existen? Definición Un requisito es algo que el producto debe hacer o una característica que debe tener. Un requisito existe por el tipo de demanda que tiene el producto o porque el cliente quiere que el requisito sea parte del producto entregado. La tarea de todo analista de requisitos es hablar con la gente, entenderla, escuchar lo que dicen y también lo que no dicen, para entender lo que necesitan. Hay que tener muy claro que un requisito no es una solución. Hay que conocer los requisitos antes de encontrarla. El trabajo de recopilar los requisitos no es sólo del analista de requisitos sino que tanto los usuarios como los demás agentes que intervienen en el negocio colaboran con él. El analista tiene que entender lo que se dice, traducir este conocimiento en requisitos del producto y hacer que el trabajo sea más fácil.

Guía de mejores prácticas de calidad de producto

20

Instituto Nacional de Tecnologías de la Comunicación

Por lo tanto, los pasos a seguir para identificar y definir los requisitos de un producto se podrían enumerar de la siguiente manera: ‐

Observar y entender el trabajo desde el punto de vista del usuario. Para ello, es necesario trabajar con el usuario, estudiar su trabajo y preguntarle acerca de lo que hace y por qué lo hace.

‐

Interpretar el trabajo del usuario y la forma en la que él lo describe ya que él es el experto del mismo.

‐

Inventar mejores formas de hacer el trabajo. El analista de requisitos interpreta lo que el producto debe hacer para satisfacer el trabajo.

‐

Plasmar estos resultados en forma de especificación de requisitos de tal forma que sean fáciles de entender para todos los implicados en el proyecto. El analista debe asegurarse de que él y el resto del equipo de trabajo tienen el mismo concepto del producto que se va a crear.

Tipos Requisitos funcionales Los requisitos funcionales especifican qué hace el producto. Describen las acciones que el producto debe llevar a cabo. Hay que pensar en estos requisitos como aquello que el producto debe hacer desde el punto de vista del negocio. Los agentes del negocio describirán estas acciones que el producto deberá realizar para completar alguna parte de su trabajo. Han de ser independientes de cualquier tecnología que pueda ser usada, es decir, son la esencia del trabajo. Cuando llega el momento de diseñar una solución para los requisitos funcionales, el diseñador añade requisitos técnicos necesarios para la tecnología usada en la solución. Los requisitos técnicos algunas veces se unen a los requisitos de negocio y se puede referir a ellos como requisitos funcionales ya que se refieren a funciones del diseño o de la solución. Sin embargo, es más preciso y menos confuso separar los requisitos técnicos y los funcionales de negocio. La especificación de requisitos sirve de contrato a la hora de construir el producto. Por lo tanto, los requisitos funcionales deben contener suficiente detalle para que el desarrollador construya el producto correcto con una mínima explicación de los analistas de requisitos y demás agentes del negocio. Requisitos no funcionales Los requisitos no funcionales son las cualidades que debe tener el producto. Estos requisitos hacen que el producto sea atractivo, útil, rápido, fiable o seguro. Estas propiedades no son requeridas porque no son actividades funcionales del producto, pero son deseables, ya que el cliente espera que las actividades sean ejecutadas de cierta manera y con un específico grado de calidad. Los requisitos no funcionales no alteran la funcionalidad esencial del producto pero pueden añadir más. Es más fácil pensar en los requisitos funcionales como aquellos que hacen que

Guía de mejores prácticas de calidad de producto

21

Instituto Nacional de Tecnologías de la Comunicación

el producto realice el trabajo y los no funcionales como aquellos que hacen que el producto dé cierto carácter al trabajo. Los requisitos no funcionales forman una parte significativa de la especificación de requisitos. Además, las propiedades no funcionales como la usabilidad o la conveniencia, pueden ser la diferencia entre un producto aceptado y que guste al usuario y un producto que no se utilice. La usabilidad de un producto crea una importante diferencia en cuanto a la aceptación del cliente. El conocido ‘look and feel’ es importante para un gran número de usuarios, y la mantenibilidad o falta de la misma elimina muchas frustraciones a los responsables del producto. Como se puede observar, los requisitos no funcionales son tan importantes como los funcionales. Cada producto tiene un estilo que lo diferencia del resto. Alguien puede comprar una televisión porque le transmita una sensación distinta, porque sea estéticamente mejor o porque sea más fácil de usar que otra. Todo esto forma el carácter del producto. Los requisitos no funcionales describen este carácter. Hay muchas posibles formas de agrupar los requisitos no funcionales. Una de ellas es la siguiente: ‐

Look and feel: Engloba aspectos referentes a la apariencia del producto

‐

Usabilidad y humanidad: Engloba aspectos referentes a la usabilidad del producto y cualquier consideración especial necesaria para una mejor experiencia del usuario.

‐

Ejecución: Engloba aspectos referentes a cómo de rápido, seguro, disponible y exacto debe ser el producto.

‐

Operacional: Engloba aspectos referentes al entorno operativo del producto y cualquier consideración que deba tenerse en cuenta para este entorno.

‐

Mantenibilidad y soporte: Engloba aspectos referentes a los cambios esperados y el tiempo necesario para hacerlos; también la especificación del soporte que se dará al producto.

‐

Seguridad: Engloba aspectos referentes a la seguridad, confidencialidad, y facilidad de recuperación del producto.

‐

Cultural y político: Engloba aspectos referentes a requisitos especiales que se deben a la cultura y costumbres de la gente involucrada con el producto.

‐

Legal: Engloba aspectos referentes a las leyes y estándares que se aplican al producto.

Los requisitos no funcionales son las propiedades, o cualidades que el producto debe tener. En algunos casos, los requisitos no funcionales son críticos para el éxito del producto. Los requisitos no funcionales son normalmente, aunque no siempre, determinados después de la funcionalidad del producto. Una vez que conocemos lo que el producto va a hacer, podemos determinar cómo se va a comportar, qué cualidades va a tener, cómo de rápido, útil, legible y seguro será.

Guía de mejores prácticas de calidad de producto

22

Instituto Nacional de Tecnologías de la Comunicación

Restricciones Las restricciones son requisitos globales. Pueden ser restricciones del propio proyecto o del diseño del producto. Por ejemplo, una restricción del proyecto podría ser: “El producto debe estar disponible al principio del mes que viene”. Puede haber también restricciones en el diseño y construcción del producto, por ejemplo: “El producto debe ser operativo para Windows® XP”. Ésta es una restricción real de negocio y cualquier solución que no la cumpla no será aceptada.

2.2.2.

Evolución de los requisitos

Al principio de todo proyecto, el análisis de requisitos se centra en entender el negocio para crear un producto que solvente las necesidades del mismo. De esto se encargan los responsables del proyecto, los cuales llegan a un acuerdo sobre las condiciones que ha de tener el producto para que sea óptimo. En esta etapa, los analistas trabajan con escenarios, prototipos y otros modelos que les puedan servir de ayuda en dicha identificación y análisis. Prototipos Algunas veces los analistas de requisitos no pueden continuar su trabajo porque les faltan datos: •

el usuario no ha dado suficientes detalles

•

el producto es tan innovador que nadie conoce realmente sus requisitos

En esos casos, el analista de requisitos o el resto de personas involucradas necesitan trabajar con algo más concreto que una lista de requisitos escritos, y para ello utilizan un prototipo. Un prototipo es un borrador de un producto potencial o de una parte del mismo. Es una simulación de los requisitos. Hay dos aproximaciones para construir prototipos: ‐

Prototipos de alta fidelidad que usan herramientas de software especializadas.

‐

Prototipos de baja fidelidad en los que se usa papel y bolígrafo o cualquier otro medio familiar.

Los equipos usan normalmente prototipos de baja fidelidad porque pueden generarse rápidamente y los usuarios valoran la espontaneidad y la inventiva de estos prototipos. Escenarios Los escenarios son una descripción paso a paso de la funcionalidad de un caso de uso del producto o del negocio, sin demasiado detalle, con el objetivo de hacer entender cómo funciona este caso de uso. No hay un número fijo de pasos a completar por escenario. Sin embargo, un número demasiado elevado (más de 50) hará que el escenario sea difícil de seguir y entender, con lo que una buena pauta sería entre 3 y 10 pasos. Los analistas consideran los escenarios como un medio neutral, entendible por todo el mundo, y el analista lo usa para llegar a acuerdos con los responsables del proyecto sobre

Guía de mejores prácticas de calidad de producto

23

Instituto Nacional de Tecnologías de la Comunicación

el trabajo que se tiene que hacer. Una vez que ellos los aprueban, los escenarios forman los cimientos de los requisitos. Documentar los requisitos Una vez finalizada esta primera etapa, los analistas de requisitos empiezan a determinar la funcionalidad detallada del producto y escriben sus requisitos. En este punto, los requisitos son escritos de una forma tecnológicamente neutra, es decir, especifican lo que el producto hace y no qué tecnología se usará para crearlo. Su especificación no debe ser ambigua. Es aconsejable no usar ningún pronombre y tener cuidado con adjetivos y adverbios ya que pueden llevar a confusiones. Se debe evitar usar palabras tales como ‘debería’ al escribir los requisitos ya que da a entender que el requisito es opcional. Un gran problema en el desarrollo del sistema es malinterpretar los requisitos. Por ello, los analistas deben escribir los requisitos de modo que se asegure que todas las partes han llegado a un único entendimiento sobre las necesidades del negocio, con el que están de acuerdo. Una forma de comprobarlo es seleccionando un determinado número de requisitos de forma aleatoria, y pidiendo a los agentes del negocio que los interpreten uno cada vez. Si todo el mundo está de acuerdo con su significado para el primer requisito se coge otro y se repite el proceso hasta que quede claro que la especificación es aceptable. Si se ve que hay muchas discordancias entre las interpretaciones de la gente se debería plantear reescribir la especificación. Aunque la tarea de escribir los requisitos pueda parecer una carga, es la única forma de asegurar que la esencia de los requisitos ha sido capturada y comunicada, y que el producto desarrollado pueda ser probado. Para poder probar los requisitos, los analistas les añaden criterios. Un criterio es una cuantificación o medida del requisito de tal forma que el técnico de pruebas pueda determinar de forma precisa si la implementación cumple con ese requisito. En definitiva, la documentación de requisitos no se limita al hecho de ponerlos por escrito, sino que se encarga de comunicar a las distintas personas involucradas en el proyecto los criterios que el producto debería tener. Si los requisitos no se han entendido o no han sido aprobados por la gente de negocio, el esfuerzo de escribirlos no tendrá ningún sentido y será detectado cuando los requisitos lleguen a las llamadas ‘puertas de calidad’ de las que se hablará más adelante. Una idea comúnmente equivocada es que se piensa que se han de especificar todos los requisitos antes de pasar a las siguientes etapas de diseño y construcción. En algunas circunstancias es necesario pero no siempre. Por ejemplo, si el documento de los requisitos es una de las bases del contrato, claramente se necesita tener una especificación completa de los mismos. Una vez especificados, se entregan al diseñador quien añade los requisitos técnicos. En este punto habrá finalizado la especificación final de los requisitos y estará lista para entregarse al desarrollador.

Guía de mejores prácticas de calidad de producto

24

Instituto Nacional de Tecnologías de la Comunicación

Se puede empezar a crear el producto antes de que todos los requisitos estén perfectamente especificados. Para ello, los agentes de negocio seleccionan casos de uso de alta prioridad para el negocio. Los analistas de requisitos revisan los requisitos para esos casos de uso, exclusivamente. Es viable ignorar el resto porque siempre hay una conexión funcional mínima entre ellos. Cuando este primer ‘grupo’ de requisitos ha sido aprobado, se entrega a los desarrolladores, quienes podrán empezar su trabajo. El objetivo es implementar un pequeño número de casos de uso tan pronto como sea posible para poder detectar posibles errores o deficiencias en los requisitos lo antes posible. De este modo, mientras que los primeros casos de uso están siendo desarrollados y liberados, los analistas están trabajando en los siguientes requisitos. En poco tiempo, se consigue establecer un ritmo de liberación con nuevos casos de uso cada pocas semanas. En resumen, los requisitos evolucionan a la vez que lo hace el producto. El cliente comienza la especificación con vagas ideas; mientras, los analistas y el resto de gente implicada en el proyecto exploran el área de trabajo. Van surgiendo nuevas ideas para el producto y los requisitos, a su vez, se van haciendo más precisos y más fáciles de probar. Estos permanecen tecnológicamente neutros hasta que el diseñador se involucra en el trabajo y añade aquellos requisitos necesarios para hacer que el producto trabaje en el entorno tecnológico. Esta evolución se ve reflejada en la siguiente figura: Casos de uso

Escenarios

Requisitos funcionales

Entender el trabajo

Requisitos no funcionales

Restricciones

Entender el producto

Requisitos técnicos Especificación del software o del sistema

Figura 7

2.2.3.

Creación de requisitos

Gestión de requisitos

Unos requisitos claros mejoran la calidad final del proyecto, reduciendo el tiempo para completar el proyecto y el coste del mismo.

Guía de mejores prácticas de calidad de producto

25

Instituto Nacional de Tecnologías de la Comunicación

Definición de los requisitos Obtener requisitos claramente definidos puede ser difícil. Se necesita para ello la perspectiva del usuario y, a menudo, los usuarios están demasiado ocupados como para definir con precisión lo que necesitan. Algunas organizaciones resuelven el problema del ‘usuario ocupado’ creando un perfil – a menudo llamado analista de negocio - que represente las necesidades de la aplicación del usuario. Si no se toma el tiempo necesario para definir lo que se necesita, más que ahorrar tiempo se perderá. Al final del proyecto se tendrán que redefinir los requisitos incompletos para obtener una solución satisfactoria al problema que no hemos podido resolver. Si falta tiempo, la reutilización de los requisitos puede ser una buena solución. Los requisitos de un producto nunca serán completamente únicos. Es aconsejable que antes de empezar cualquier proyecto se revisen proyectos ya finalizados para ver si contienen material potencialmente reutilizable. En ocasiones hay requisitos que se pueden reutilizar sin ni siquiera alterarlos pero lo más habitual es encontrar requisitos que, aunque no son exactamente lo que se quiere, son una buena base para construir los requisitos deseados. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requisito no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee. Una vez finalizada la especificación de requisitos se recomienda realizar una serie de entrevistas a los agentes del negocio y sesiones de grupo con los desarrolladores para descubrir si el proceso hasta el momento ha sido bueno o malo y sugerir una acción que lo remedie. La intención es hablar con toda la gente que está involucrada en el proceso y hacerles una serie de cuestiones tales como: ‐

¿Qué hicimos bien?

‐

¿Qué hicimos mal?

‐

Si lo tuviéramos que hacer otra vez, ¿qué haríamos de forma diferente?

Revisar y apuntar las respuestas a este tipo de preguntas ayudará a mejorar el proceso de tal forma que en el siguiente proyecto se pueden usar estos apuntes como punto de partida. Este proceso puede ser algo informal, una reunión con el grupo del proyecto o responsables del proyecto donde se recopilen mensajes de los distintos participantes. Si la participación es muy grande se podría formalizar de tal forma que una persona ajena al proyecto se comunique con los distintos participantes, tanto de forma individual como en grupo, y publique un informe. Las compañías que regularmente realizan esta técnica de forma consistente consiguen significantes mejoras en sus procesos. Verificación de los requisitos Los requisitos son el medio de comunicación entre el negocio y el área de TI. Debido a su importancia, se podría incluir la verificación de requisitos como una etapa más dentro del ciclo de vida de calidad del producto. En esta fase, el usuario final añade criterios de aceptación para cada requisito.

Guía de mejores prácticas de calidad de producto

26

Instituto Nacional de Tecnologías de la Comunicación

Además, apoya el hecho de que los requisitos han de ser correctos antes de que sean entregados a los diseñadores y desarrolladores. La puerta de calidad es un punto por el que pasan cada uno de los requisitos antes de formar parte de la especificación. Las puertas de calidad normalmente se establecen de tal forma que una o dos personas, probablemente el responsable del análisis de los requisitos y el técnico de pruebas, sean las únicas personas autorizadas para pasar los requisitos a través de las puertas de calidad. Ambas personas se reúnen y validan una serie de características de cada uno de los requisitos tales como: su relevancia, coherencia o facilidad de seguimiento y de pruebas, entre otras cualidades, antes de permitir que pasen a formar parte de la especificación. Una de las tareas de las puertas de calidad es asegurarse de que cada requisito cumple con el criterio que tiene asignado. Este criterio es una medida del requisito que le hace entendible y con capacidad para ser probado. Con este criterio de aceptación se pretende: • • • • •

Validar que los requisitos están completos y son correctos. Asociar los requisitos a las funciones de negocio. Eliminar ambigüedades. Validar que el resultado de cada requisito sea fácil de probar. Identificar las funciones de negocio que se cambiaron durante el proyecto.

La característica de poder entender con facilidad los requisitos es siempre en beneficio del cliente que en muchas ocasiones no está dispuesto a aceptar requisitos que no es capaz de entender o que no contribuyen a su trabajo. El cliente quiere contribuir en el proceso por lo que es necesario poder medir cada requisito. El analista de los requisitos tiene una razón diferente para medir y probar los requisitos. Necesita asegurarse de que no hay requisitos ambiguos, es decir, han de tener el mismo significado para los clientes y los desarrolladores. También necesitan medirlos para poder decir que se está construyendo el producto que el cliente realmente necesita. Otra razón por la que el proyecto tiene puertas de calidad es para prevenir posibles fugas de requisitos. Los requisitos, algunas veces, aparecen en las especificaciones sin que nadie realmente sepa de donde vienen o qué valor añaden al producto. Asegurándose de que la única forma de que los requisitos entren a formar parte de las especificaciones sea a través de las puertas de calidad, el equipo del proyecto tiene un total control de los requisitos. La función principal de las puertas de calidad es prohibir el paso de requisitos no adecuados a la especificación. Para ello, las puertas hacen seguimientos de cada requisito. Revisión de la especificación Una vez que la especificación de los requisitos está completa debería ser revisada. En esta revisión final se valida que no falta ningún requisito, que todos los requisitos concuerdan con el resto y que cualquier conflicto entre los requisitos ha sido resuelto. En resumen, la revisión confirma que la especificación está totalmente completa y es apta para poder pasar a la siguiente fase de desarrollo.

Guía de mejores prácticas de calidad de producto

27

Instituto Nacional de Tecnologías de la Comunicación

Esta revisión también ofrece la oportunidad de revisar el coste y los riesgos del proyecto. Una vez que la especificación de los requisitos está completa, se tendrá un conocimiento preciso del alcance y funcionalidad del producto. Es, pues, el momento de volver a medir su tamaño. Con el tamaño, el conocimiento de las restricciones del proyecto y la arquitectura de la solución se podría estimar el coste de construir el producto. En esta fase también se conoce qué tipo de requisitos están asociados a los mayores riesgos. Por ejemplo, los usuarios pueden pedir una interfaz que la organización no ha construido antes o una tecnología para construir el producto que nunca se ha usado y puede que la compañía no tenga gente capacitada para construir el producto especificado con esas condiciones. Volver a calcular el riesgo en este punto dará una buena oportunidad para construir el producto deseado de forma exitosa.

2.3.

OPTIMIZACIÓN DE LA ESTRATEGIA DE PRUEBAS

Como no es rentable ni, en ocasiones, viable, detectar y corregir todos los fallos existentes, es importante encontrar un equilibrio entre una tasa de defectos aceptable y la inversión necesaria para conseguirlo. Hay que analizar el riesgo del negocio y, en función de dicho riesgo, tomar las decisiones para optimizar las pruebas.

2.3.1.

Estrategia de pruebas

La elección de la estrategia de pruebas es un importante factor para el éxito de las mismas. Este factor está bajo el control de los responsables de pruebas. Tipos de estrategias de pruebas Los tipos de estrategia de pruebas más importantes son: ‐

Analítica: Las estrategias de pruebas analíticas tienen en común el uso de alguna técnica analítica formal o informal normalmente durante la etapa de gestión de requisitos y la de diseño del proyecto. Por ejemplo, un análisis de riegos. Para identificarlos se suele usar documentación de proyectos anteriores y datos que aporte la gente involucrada en el proyecto. Después, se planifican, diseñan y priorizan las pruebas basadas en este riesgo. Otra estrategia de prueba analítica típica es la basada en requisitos donde un análisis de la especificación de requisitos forma las bases para planificar, estimar y diseñar las pruebas

‐

Basado en modelo: Se pueden crear pruebas basadas en modelos (matemáticos u otros). Si el comportamiento del sistema bajo pruebas se ajusta a lo que se predijo en el modelo, entonces se estima que el sistema está trabajando correctamente. Las estrategias de pruebas basadas en el modelo tienen en común la creación o selección de algún modelo formal o informal para comportamientos de sistemas crítico, normalmente durante las etapas de requisitos y diseño del proyecto.

‐

Metódico: Se debe tener una lista de control que sugiera las áreas principales de ejecución de pruebas o se puede hacer un seguimiento de los estándares de la

Guía de mejores prácticas de calidad de producto

28

Instituto Nacional de Tecnologías de la Comunicación

industria de calidad del software y así tener un resumen de las principales áreas de pruebas. Después, de forma metodológica, se ha de diseñar, implementar y ejecutar las pruebas siguiendo este extracto. ‐

Proceso o estándar conformista: Estas estrategias siguen un desarrollo externo orientado a pruebas a menudo con poca personalización y puede tener un temprano o tardío punto de implicación a pruebas. Por ejemplo, se puede adoptar el estándar IEEE 829 para las pruebas y alternativamente adoptar una de las metodologías ágiles como, ‘Extreme Programming ‘.

‐

Dinámico: Las estrategias dinámicas, como pruebas exploratorias, tienen en común que se concentran en encontrar tantos defectos como sea posible durante la ejecución de pruebas y adaptan todo lo posible el sistema bajo prueba a las condiciones que habrá cuando se libere. Típicamente enfatizan las últimas etapas de pruebas. Se trata de crear un pequeño conjunto de pautas de pruebas que se enfoquen en debilidades conocidas del software.

‐

Consultativo o directo: Estas estrategias tienen en común la confianza en un grupo de gente que no son técnicos de pruebas para guiar o realizar el esfuerzo de pruebas. Por ejemplo, se puede preguntar a los usuarios o desarrolladores del sistema sobre qué probar o incluso confiar en ellos para hacer las pruebas. Enfatizan las últimas etapas de pruebas simplemente debido a la falta de reconocimiento del valor de pruebas tempranas.

‐

Regresión: Estas estrategias tienen en común el conjunto de procedimientos, normalmente automatizados, que les permiten detectar defectos de regresión. Esta estrategia suele envolver pruebas funcionales automatizadas antes de la liberación del producto, pero algunas veces se centra por completo en funciones liberadas con anterioridad. Por ejemplo, se puede intentar automatizar todas las pruebas de sistemas de tal forma que cuando se produzca cualquier cambio se pueda volver a ejecutar cada prueba para asegurarse de que ningún área se ha visto afectada.

Estrategias preventivas y reactivas Las estrategias de pruebas pueden clasificarse como preventivas o reactivas. Por ejemplo, las estrategias de pruebas analíticas implican un análisis de las bases de prueba y tienden a identificar problemas de las mismas antes de la ejecución de pruebas. Esto permite la temprana y barata eliminación de errores. Esta es una estrategia preventiva. La estrategia de pruebas dinámicas se centra en el periodo de ejecución de pruebas. Permite la localización de defectos que puedan haber sido difíciles de anticipar hasta tener el sistema actual enfrente. Esta es una estrategia reactiva. Pero, ¿cómo saber cuál es la estrategia más adecuada que nos lleve al éxito? Hay que considerar muchos factores. Entre los más significativos están:

Guía de mejores prácticas de calidad de producto

29

Instituto Nacional de Tecnologías de la Comunicación

‐

Riesgos: En el diseño de las pruebas se consideran los riesgos y sus niveles. En el caso de una aplicación bien construida que evoluciona despacio, la regresión es un riesgo importante por lo que en este caso tendría sentido aplicar la estrategia de regresión. Para una aplicación que se cree desde cero, la estrategia de análisis de riesgos puede ayudar a revelar diferentes riesgos.

‐

Conocimientos: Las estrategias no deben elegirse sino también llevarse a cabo. Se tienen que tener en cuenta los conocimientos de los técnicos de pruebas. La estrategia ‘estándar conformista’ sería una elección acertada cuando hay falta de tiempo o desconocimiento en el equipo.

‐

Objetivos: El proceso de pruebas debe satisfacer las necesidades de las personas involucradas en el proyecto para que tenga éxito. Si el objetivo es encontrar el mayor número de defectos posibles en el menor tiempo posible e invirtiendo el menor esfuerzo posible tendría sentido usar la estrategia dinámica.

‐

Normativas: Algunas veces se debe satisfacer no sólo a las personas del proyecto sino también la normativa vigente. En este caso es necesario idear una estrategia de pruebas metódica que la satisfaga cumpliendo todos los requisitos.

‐

Producto: Algunos productos exigen tener bien especificados los requisitos. Esto dirige a una estrategia analítica basada en requisitos.

‐

Negocio: A menudo es especialmente importante las consideraciones y continuidad del negocio. Si se usa un sistema heredado como modelo para crear un nuevo sistema, se podría usar la estrategia basada en modelos.

Un buen equipo de trabajo puede imponerse a una situación donde la mayoría de factores estén en contra del éxito del proyecto. Sin embargo, ejecutar con éxito una estrategia desaconsejable es equivalente a realizar un trabajo que no sirve. Por lo tanto, se deben tomar decisiones inteligentes en términos de estrategias de pruebas. La elección de la estrategia de pruebas se debe hacer teniendo en cuenta los factores mencionados antes, la programación de tiempo establecida, el presupuesto y las restricciones del proyecto y la política de la organización. Otras estrategias: La automatización Podemos considerar la automatización como una estrategia para aumentar la calidad de un producto a un bajo coste y optimizar el esfuerzo de las pruebas, como se ve reflejado en la siguiente figura:

Guía de mejores prácticas de calidad de producto

30

Instituto Nacional de Tecnologías de la Comunicación

La automatización como parte de la Estrategia de Pruebas (Indirecto) Coste del Fallo Coste Total de la Calidad

Coste

Ventaja de la  Automatización

(Directo) Coste  de las Pruebas

0% 100% Defectuosa

Nivel de Calidad

100% 100% Correcta

Fuente: J.M. Juran’s Quality Control Handbook Giga Information Group 2001, Justifying IT Investments: Quality Assurance

Figura 8

Automatización: Ventajas vs Coste

A pesar de su gran utilidad, en ocasiones la inversión extra que supone para el proyecto y la necesidad de ciertas habilidades por parte de miembros de la organización hacen que la automatización sea un proceso costoso. Algunas de sus ventajas son: 9 La automatización puede reducir drásticamente el esfuerzo de las pruebas de regresión. 9 La automatización permite realizar validaciones durante los ciclos de cambios, cosa que sería imposible hacer manualmente debido a restricciones de tiempo. 9 La automatización habilita la consistencia y cobertura lógica. No hay riesgo alguno de excluir casos de prueba o pasar por alto errores si se diseña correctamente. 9 La automatización da la opción de una alta tasa de regresión ya que el tiempo de computación sólo se contabiliza cuando se están ejecutando las pruebas. Para hacer factible la automatización de pruebas se necesitaría combinar la tecnología tradicional con marcos de pruebas orientados al negocio. A continuación se describe un marco que hace viable el uso de automatización. Marco BPT® (Business Process Testing) La prueba de proceso de negocios (Business Process Testing®) es el primer marco de pruebas completo que permite la colaboración eficiente de los analistas del negocio con los ingenieros de calidad. BPT® aparece por la necesidad de una mejora que pudiera hacer más eficiente el diseño de pruebas, la automatización de pruebas, su mantenimiento y procesos de documentación que hasta ese momento eran caros y consumían mucho tiempo.

Guía de mejores prácticas de calidad de producto

31

Instituto Nacional de Tecnologías de la Comunicación

El marco BPT® permite a los analistas de negocio o especialistas en la materia no técnicos construir, manejar datos, ejecutar y documentar los distintos pasos de pruebas sin tener conocimiento técnico muy profundo. Pueden crear flujos de prueba de alto nivel que reflejen los procesos actuales de negocio y liberar a los ingenieros de calidad de tal forma que éstos pueden concentrar sus esfuerzos en áreas que faciliten la automatización. Los beneficios de BPT® sobrepasan cualquier solución de generaciones anteriores: -

Simplifica en gran medida y agiliza el proceso de diseño de pruebas mediante el uso de componentes (bloques de construcción de proceso de negocio).

-

Permite al supervisor de QA (aseguramiento de calidad) y a los equipos de pruebas empezar el proceso de diseño de pruebas mucho antes – durante el diseño del sistema - lo que acelera el tiempo de desarrollo de alta calidad del software.

-

Genera pruebas automatizadas y documentación de caso de pruebas en un solo paso, y elimina los caros procesos de creación y mantenimiento de las grabaciones de prueba.

-

Permite al equipo de QA usar activos de pruebas pre-empaquetados y mejores prácticas que implementen la automatización de pruebas para dirigir el ERP (enterprise resource planning) y las aplicaciones CRM (customer relationship manager) que ahorran tiempo e impulsan el conocimiento de los expertos.

-

Aumenta la tasa de adopción de automatización de pruebas porque es más fácil de usar.

Por lo tanto, BPT® sienta las bases para aumentar la eficiencia de las pruebas con un esfuerzo aceptable de mantenimiento de las mismas. En un mundo ideal, se generarían las pruebas de automatización basadas en la especificación, o aún mejor, en los requisitos. Pero en el mundo real es recomendable que siempre se ejecuten las pruebas al menos una vez de forma manual antes de automatizarlas para verificar que el caso de prueba cubre adecuadamente los requisitos. La ventaja de usar BPT® es que es un marco que funciona para pruebas tanto manuales como automatizadas. Nos permite diseñar pruebas de componentes tan pronto como finalice la fase de definición de los requisitos, antes de que la función de negocio esté enteramente programada o desarrollada. Esto significa que el proceso de pruebas puede empezar mucho antes, y se puede alinear el diseño de los componentes de prueba mucho más cerca de los requisitos del negocio. En resumen, con el marco de pruebas de proceso de negocio (BPT®) se consigue realzar las tecnologías de automatización de pruebas tradicional y permite conseguir un mejor nivel de calidad del software con la misma inversión en calidad. Pruebas del impacto del cambio (CIT®) Aunque muchas organizaciones ahora prestan más atención a los procesos de calidad y a la eficiencia de las pruebas para nuevas aplicaciones y proyectos, los procesos de pruebas para parches, actualizaciones, etc. son generalmente pobres.

Guía de mejores prácticas de calidad de producto

32

Instituto Nacional de Tecnologías de la Comunicación

La mayoría de las nuevas implementaciones son llevadas a cabo con un gran número de personal, con un presupuesto suficiente para llevarlo a cabo. Después de que la aplicación se pone en funcionamiento, sólo un pequeño equipo de desarrolladores y técnicos de pruebas están dedicados a mantener el sistema. Dado que casi todos los cambios del sistema de producción son estimados como críticos, el ya reducido equipo de pruebas nunca tendrá el tiempo necesario para ejecutar las adecuadas pruebas de regresión. El aumento de la complejidad de las aplicaciones de hoy en día aumenta este problema – cada parche para un sistema posiblemente impacta en una docena de otros. Los planes de pruebas llegan a ser una tarea difícil. Los equipos de pruebas que se enfrentan a estos cambios pueden: -

Pedir tiempo suficiente para ejecutar un 100% de la regresión para asegurarse de que todo está cubierto.

-

Probar solo el componente cambiado y esperar que no tenga impacto sobre otras áreas de la aplicación.

-

No probar los cambios y cruzar los dedos.

-

Convencer a dirección de que no se hagan cambios, algo difícil de conseguir.

Las pruebas del impacto del cambio (CIT®, Change Impact Testing) están ganando gran importancia. Las nuevas tecnologías ejecutan un análisis de cambio para cada parche o nueva versión y entonces determinan exactamente qué módulo de la aplicación tiene impacto y qué casos de prueba deben ser probados con pruebas de regresión. Por lo que en vez de tener que ejecutar una regresión completa sólo se necesita ejecutar un pequeño porcentaje de las pruebas de regresión que cubre los módulos con impacto de la aplicación. Esta solución asegura que nosotros podemos liberar aplicaciones con la máxima calidad al más bajo nivel de riesgo.

2.3.2.

Estimación del esfuerzo

El trabajo de realizar pruebas puede verse como un sub-proyecto dentro del proyecto de creación del software o producto, de tal forma que se pueden adoptar unas técnicas fundamentales para realizar estimaciones sobre el proceso de pruebas. Se puede empezar creando una estructura que identifique las etapas, actividades y tareas. Empezando por el nivel más alto, se podría dividir el proyecto de pruebas en las siguientes fases, que son las que propone el ISTQB® (International Software Testing Qualifications Board): •

Planificación y control

•

Análisis y diseño

•

Implementación y ejecución

•

Evaluación de criterios de salida e informes

•

Cierre de prueba.

Guía de mejores prácticas de calidad de producto

33

Instituto Nacional de Tecnologías de la Comunicación

Dentro de cada fase se identifican las actividades a llevar a cabo y dentro de cada actividad se identifican tareas y quizás sub-tareas. Además, hay que considerar el riesgo extraído del análisis de riesgo, del que se hablará más adelante. Pero, ¿qué actividades y tareas son requeridas en cada etapa para llevar a cabo el proceso de prueba? Para entenderlo mejor vamos a ver un ejemplo. Supongamos que el rendimiento es una de las áreas de mayor riesgo del producto. Las pruebas de rendimiento son una actividad dentro de la fase de ejecución de pruebas. Habría que estimar qué tareas forman parte de la ejecución de pruebas de rendimiento, cuánto tiempo durarán estas tareas y cuantas veces se necesitarían ejecutar. Una vez que se tiene conocimiento de estos datos, alguien tiene que desarrollar las pruebas y estimar las tareas involucradas en este proceso tales como escribir los scripts de pruebas y crear datos de pruebas. Típicamente las pruebas de rendimiento necesitan ser ejecutadas en un entorno de pruebas especial que sea diseñado para que se parezca al entorno de producción al menos en la forma en que afectará a los tiempos de respuesta y utilización de recursos. De esta forma, la adquisición y configuración del entorno de pruebas de rendimiento es una actividad de la fase de implementación. Ahora habría que estimar las tareas involucradas en la adquisición y configuración tales como entorno de pruebas, simulación del rendimiento basadas en el entorno de producción para buscar los cuellos de botella potenciales, obtener el hardware apropiado, el software apropiado y herramientas. No todo el mundo sabe cómo usar las herramientas de pruebas de rendimiento o cómo diseñar estas pruebas. Debido a esto, la formación sería una actividad a tener en cuenta en la fase de planificación de pruebas. Es momento para estimar el tiempo requerido para identificar y contratar a profesionales y para formarlos para que realicen su trabajo. Finalmente, se debe estimar el tiempo requerido para realizar el boceto, revisar y finalizar un plan de pruebas de rendimiento. Una vez que la estructura está creada, hay que recordar que ha de ser usada tanto para la estimación como para la monitorización y control. Técnicas de estimación de esfuerzo Hay dos técnicas de estimación de esfuerzo de pruebas contempladas por el ISTQB®. Una trata de consultar a gente con conocimientos específicos en el trabajo y otra realiza el análisis de métricas basándose en proyectos ya finalizados y datos industriales. Preguntar a los usuarios y a los expertos implica trabajar con personal experimentado en el desarrollo de la estructura del proyecto. Hay que trabajar conjuntamente con el fin de identificar cada tarea, el esfuerzo, la duración, las dependencias y los recursos. Existen herramientas que pueden ser de ayuda en esta tarea, tales como Microsoft Project. El análisis de métricas puede ser tan simple o sofisticado como se quiera hacer. Hay que preguntarse, ¿cuántos técnicos de pruebas por desarrollador tendrá el proyecto? También habría que clasificar el proyecto en términos de tamaño (pequeño, mediano, grande) y complejidad (simple, moderado o complejo) y después ver cuánto, aproximadamente, duraron los proyectos de un particular tamaño y complejidad realizados en el pasado. Otra

Guía de mejores prácticas de calidad de producto

34

Instituto Nacional de Tecnologías de la Comunicación

simple y fiable aproximación sería ver la media del esfuerzo realizado por casos de pruebas en proyectos similares del pasado y usarlo para estimar el esfuerzo total. Otras aproximaciones más sofisticadas implican la construcción de modelos matemáticos en hojas de cálculo basándose en parámetros claves tales como número de defectos encontrados por técnico de pruebas por día, y después utilizar estos parámetros para determinar la duración y esfuerzo de las tareas y actividades del proyecto. Incluso la mejor estimación debería ser negociada con cierta gestión. Existen posiciones de negociación clásicas. El éxito de estas negociaciones se basa en estimar cuál sería la mejor forma de equilibrar las posibles presiones de competitividad teniendo en cuenta los términos de calidad, tiempo y presupuesto. Factores que afectan al esfuerzo de pruebas El proceso de pruebas es una actividad compleja en muchos proyectos y hay una serie de factores que pueden influir en la misma. Al crear los planes de pruebas y estimar el esfuerzo y la programación del proceso de pruebas, siempre hay que tener en cuenta estos factores o, si no, las estimaciones podrían verse afectadas desde al principio del proyecto, no viéndose esta alteración hasta el final del mismo. Algunos de estos factores se enumeran a continuación. o

La estrategia de pruebas elegida tendrá una gran influencia en el esfuerzo de las pruebas.

o

La existencia o no de suficiente documentación del proyecto para que los técnicos de pruebas puedan comprender el sistema, cómo funciona y cuál es su correcto comportamiento. En otras palabras, información adecuada y de alta calidad que servirá de ayuda para realizar mejor y de forma más eficiente el trabajo de definición de las pruebas.

o

La importancia de las características no funcionales, tales como la usabilidad, seguridad o fiabilidad también influyen en el esfuerzo del proceso de pruebas, pueden ser caros de implementar y consumen tiempo. La complejidad es otro factor importante.

o

Crear una buena documentación del proyecto es un factor positivo, pero si es muy detallado y meticuloso puede llevar a retrasos ya que el mantenimiento de datos de pruebas muy frágiles, por ejemplo, requiere mucho esfuerzo.

o

Aumentar el tamaño del producto conduce a un aumento del proyecto y del equipo de proyecto, lo que aumenta la dificultad de predicción y gestión del mismo.

o

La disponibilidad de herramientas de pruebas, especialmente aquellas que reducen el esfuerzo asociado con pruebas de ejecución o las de detección de errores de codificación también reducen el tiempo requerido para completar el proceso de pruebas.

o

El ciclo de vida es un factor muy influyente ya que, por ejemplo, el modelo en V tiende a ser frágil en cuanto a cambios, y el modelo incremental tiende a tener altos costes de pruebas de regresión.

Guía de mejores prácticas de calidad de producto

35

Instituto Nacional de Tecnologías de la Comunicación

o

La madurez del proceso, incluida la madurez del proceso de pruebas, es otro factor que precisa una gestión cuidadosa de cambio a mitad y final del proyecto.

o

La presión del tiempo es otro factor a considerar. La presión no debería ser una excusa para asumir riesgos innecesarios. Sin embargo, es una poderosa razón para tener especial cuidado, considerar las decisiones a tomar y planificar de forma inteligente y minuciosa el proceso ya que es otro factor distintivo de los procesos maduros.

o

Los factores relacionados con las personas que llevan a cabo el proceso son muy importantes. De hecho, cuando aparecen muchos problemas en un proyecto, un excelente equipo de trabajo puede ser decisivo. Estos factores incluyen los conocimientos de los individuos del equipo y la idoneidad de estas habilidades con las necesidades del proyecto. La estabilidad del equipo del proyecto es un factor muy importante.

Como se ha visto, los factores anteriormente nombrados, están fuera del alcance y control de los responsables del proceso de pruebas. Por esta razón, es importante que los técnicos de pruebas, y especialmente los responsables de las pruebas, tengan un compromiso y conocimiento del contexto en el que van a operar. Algunos de estos factores resultan en riesgos del proyecto que deberían ser tratados en el plan de pruebas. Ejemplo Un mapa de esfuerzo de pruebas es generado por la combinación de riesgo y complejidad. Basándose en el esfuerzo estimado por proceso de negocio, se puede calcular el coste total para un riesgo y una complejidad alta, mapeado con cada ciclo de prueba (de 1 a 10) a diferentes niveles de automatización (de 0% a 100%).Las bandas coloreadas mostrarían el rango de costes. En el siguiente ejemplo se ve que a partir del 5º ciclo de pruebas se empiezan a ver los beneficios de automatizar. Este es el punto de inflexión a partir del cual si se aumenta el grado de automatización disminuirá el esfuerzo (coste). Para el caso concreto de tener 75 días-hombre para probar completamente los requisitos de una aplicación, con alto riesgo y alta complejidad, y usar 3 ciclos de prueba para completar esta prueba, el nivel óptimo de automatización sería del 35% como se ve en la figura. A partir de ese punto, a mayor automatización requerirá más recursos y más tiempo, es decir más esfuerzo.

Guía de mejores prácticas de calidad de producto

36

Instituto Nacional de Tecnologías de la Comunicación

Coste (días) del esfuerzo de pruebas para Alto Riesgo y Alta Complejidad 10 9

Ciclos de prueba

8 7 6 5 4 3 2 1 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Automatización 0-15 75-90

30-45 105-120

15-30 90-105

45-60 120-135

60-75 135-150

Nº días

Figura 9

Cálculo del nivel óptimo de automatización

Basándose en el mapa de esfuerzos, se podría calcular el número de ciclos de prueba requeridos a partir del cual la automatización empiece a dar beneficios. Con esta información podría fácilmente decidirse si se debería o no automatizar para un caso en particular. Por ejemplo, se podría decidir invertir en automatización para aquellos casos de pruebas que proveen ROI después del 5º ciclo de pruebas, pero no para aquellos que vayan más allá del 6º ciclo de pruebas. En el caso de la siguiente figura el 7º ciclo de pruebas es el punto de inflexión a partir del cual saldría rentable aumentar la automatización. Coste (días) del esfuerzo de pruebas para Alto Riesgo y Alta Complejidad 10

Ciclos de prueba

9 8 7 6 5 4 3 2 1 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Automatización 0-15 75-90

15-30 90-105

30-45 105-120

45-60 120-135

60-75 135-150

Nº días

Figura 10 Automatización vs Coste

Guía de mejores prácticas de calidad de producto

37

Instituto Nacional de Tecnologías de la Comunicación

2.3.3.

Valoración del riesgo

Todos los proyectos implican riesgos. El riesgo no es algo necesariamente malo ya que no se podría progresar sin asumir alguno. Sin embargo, hay diferencias entre riesgos sin gestionar y gestionados, donde las probabilidades estén bien entendidas y existan planes de contingencia. El riesgo es perjudicial sólo en el caso de que los riesgos sean ignorados y lleguen a generar problemas. Es importante realizar un análisis de los mismos para llevar una buena gestión de riesgos. Análisis

Diseño

Construcción

Prueba

Liberación

R I E S G O

1

0

Actividades de pruebas

Figura 11 Análisis del riesgo durante la gestión de pruebas Gestión de riesgos La gestión de riesgos conlleva una valoración de los riesgos más comunes del proyecto, definiendo un plan de acción por si su ocurrencia causara problemas y monitorizando los proyectos para obtener avisos cuando se entre en una zona de riesgo, de modo que se tomen las medidas oportunas. Capers Jones propone una lista de riesgos y sus probabilidades. Esta lista puede ser un buen punto de partida para comenzar con la gestión de los mismos. Entre los riesgos más graves se encuentran los siguientes: •

Métricas inexactas.

•

Medidas inadecuadas.

•

Excesiva presión en cuanto a las fechas de entrega del proyecto.

•

Una mala gestión.

•

Inexactitud en la estimación de costes.

•

Baja productividad

•

Cancelación de proyectos

Guía de mejores prácticas de calidad de producto

38

Instituto Nacional de Tecnologías de la Comunicación

Cálculo del riesgo Hay muchas posibles definiciones de riesgo. Una de ellas es el factor que podría resultar en consecuencias negativas en un futuro y que es normalmente expresado como impacto o probabilidad. En otras palabras, el riesgo es la probabilidad de que un resultado negativo e indeseable suceda. La probabilidad de que el riesgo se transforme en un hecho real, es un factor a considerar cuando se piensa en el nivel de riesgo asociado al proyecto y sus posibles consecuencias negativas. El esfuerzo de calcular el riesgo de un producto es debido al deseo de conseguir los siguientes objetivos: •

Transparencia de la funcionalidad que se está probando.

•

Centrarse en las funciones críticas del negocio

•

Tener conocimiento de la cobertura de las pruebas.

Para calcular el riesgo del negocio es necesario determinar las consecuencias negativas esperadas de un fallo y la probabilidad de que este fallo ocurra. Como resultado, dirigimos nuestra valoración del riesgo en 2 fases: 1. Valorar el impacto de cada función de negocio. En este contexto, el impacto representa la importancia de la funcionalidad con el objetivo de realizar las operaciones de negocio día a día, o cuánto daño causará al negocio un fallo de esa función. 2. Ver la probabilidad de que aparezca un defecto en la función de negocio valorada. De ambos pasos se obtendrá el riesgo asociado a cada función de negocio que pertenece a la aplicación que está bajo prueba. Se usan criterios comunes a las unidades de negocio de tal forma que los resultados sean comparables para toda la empresa. Los criterios de impacto de negocio están definidos en función del efecto negativo que sufriría el negocio si un fallo ocurriese, como muestra la siguiente tabla: Resultados Criterio Alto impacto

Medio impacto

Bajo impacto

Tipo de procesos

Calculo / validación

Cambio de datos

Visualización

Implicaciones del negocio

Legal

Información incorrecta

Ninguna

Frecuencia de uso

Muy frecuente

A menudo

Rara

Número de clientes afectados

Muy importante

Grupo

Alguna

Tabla 2

Guía de mejores prácticas de calidad de producto

Análisis del impacto del negocio

39

Instituto Nacional de Tecnologías de la Comunicación

Al igual que el impacto del negocio, la probabilidad de fallo es el resultado de una valoración basada en un criterio que debería ser estándar para toda la compañía. Resultados Criterio Poco probable

Probable

Muy probable

Tasa de cambio

Sin cambios

Función cambiante

Nueva función

Madurez del SW

Maduro (>10 años)

Progresando (5-10 años)

Inmaduro ( 100 Acciones: No descuento Descuento extra Puntos fidelidad

Por la tabla de decisión se pueden determinar casos de prueba estableciendo valores para las condiciones y determinando las salidas esperadas, p.ej. de la regla 1 podemos introducir un cliente normal con una transacción de 50€ y comprobar que no se le aplica ningún descuento. El mismo cliente con una transacción de 150€ debería contar con un descuento. De esta forma se puede ver que cada columna de la tabla de decisión representa un posible caso de prueba. Tabla 11 Ejemplo de tablas de decisión Las tablas de decisión ayudan en la elección sistemática de casos de prueba efectivos y puede ser beneficial a la hora de encontrar defectos o ambigüedades en la especificación. Es una técnica que funciona bien en conjunto con el particionamiento de equivalencia. La combinación de condiciones exploradas puede ser combinaciones de particiones de equivalencia. A la hora de usar tablas de decisión para el diseño de pruebas la primera tarea es identificar una función o subsistema apropiado que tenga un comportamiento que reaccione de acuerdo a una combinación de entradas o eventos. El comportamiento de interés no debe ser muy extenso (p.ej. no debería contener muchas entradas), de lo contrario el número de combinaciones sería muy voluminoso y difícil de manejar. Es mejor tratar con grandes números de condiciones dividiéndolas en subconjuntos y tratando estos conjuntos por separado.

Guía de mejores prácticas de calidad de producto

83

Instituto Nacional de Tecnologías de la Comunicación

Una vez que se han identificado los aspectos que han de ser combinados, entonces se ponen en una tabla listando todas las combinaciones de verdadero o falso para cada uno de los aspectos. Además de estas tablas, hay otras técnicas que tratan con pruebas de combinaciones: pruebas de pares y arrays ortogonales. 3.4.1.5.

Transición de estados

La técnica anterior, pruebas con tablas de decisión, es particularmente útil cuando las combinaciones de condiciones de entrada producen varias acciones. Ahora se va a considerar una técnica similar, pero que concierne a sistemas en los que las salidas son desencadenadas por cambios en las condiciones de entrada, o cambios de “estado”; en otras palabras, el comportamiento depende del estado actual y estado pasado, y es la transición la que desencadena el comportamiento del sistema. Las pruebas de transición de estados se usan cuando alguno de los aspectos del sistema se puede describir en lo que se denomina una “máquina de estados finitos”. Esto significa que el sistema puede estar en un número (finito) de estados, y las transiciones de un estado a otro están determinadas por las reglas de la “máquina”. Este es el modelo en el que se basan el sistema y las pruebas. Cualquier sistema en el que se puedan conseguir diferentes salidas con la misma entrada, dependiendo en lo que haya pasado antes, es un sistema de estados finitos. Un sistema de estados finitos se suele representar mediante un diagrama de estados. El siguiente cuadro muestra la representación de un diagrama de transición de estados: DIAGRAMAS DE TRANSICIÓN DE ESTADOS Un diagrama de transición de estados es una representación del comportamiento de un sistema. Consta sólo de dos símbolos: El primero es:

Estado 1

Es el símbolo para un estado. Un estado es cuando el sistema está estático, en una condición estable desde la que cambiará si es estimulado por un evento de algún tipo. El segundo es:

Es el símbolo de una transición, p.ej. El cambio de un estado a otro. El cambio de estado estará desencadenado por un evento (p.ej. Presionar un botón). La transición estará etiquetada con el evento que la causó y la acción que surge de ella

Tabla 12 Representación de un diagrama de transición de estados

Guía de mejores prácticas de calidad de producto

84

Instituto Nacional de Tecnologías de la Comunicación

Hay que destacar que en un estado dado, un evento puede causar sólo una acción, pero el mismo evento, desde un estado diferente, puede causar una acción diferente o un diferente estado final. Si contamos con una representación de un diagrama de transición de estados podemos analizar el comportamiento en términos de qué pasa cuando se produce una transición. Las transiciones están causadas por eventos y pueden generar salidas y/o cambios de estado. Un evento es algo que actúa como un desencadenador para un cambio; puede ser una entrada del sistema, o puede ser algo dentro del sistema que cambia por alguna razón, como un campo de una base de datos que se actualiza. En algunos casos un evento genera una salida, en otros el evento cambia el estado interno del sistema sin generar una salida, y otros pueden causar una salida y un cambio de estado. Lo que pasa con cada cambio se puede deducir siempre del diagrama de transición de estados. Por ejemplo, si se realiza una petición de sacar 100€ de un banco, podría ser que se entregase el dinero. Después se realiza la misma petición, pero se niega el dinero (porque el saldo es insuficiente). Esta última petición se rechazó porque el estado de la cuenta del banco cambió de tener suficientes fondos para cubrir la petición a no tenerlos. La transición que causó que la cuenta cambiase de estado fue probablemente la retirada de dinero anterior. Con los diagramas de estados podemos representar un modelo desde el punto de vista del sistema, de la cuenta o del cliente. Cuando miramos los casos de prueba que se pueden generar hay que tener en cuenta que existen transiciones de estado válidas, pero también transiciones de estado no válidas. La siguiente figura muestra un ejemplo de introducir un Número de Identificación Personal (PIN) para entrar en la cuenta de un banco. Como ya se explicó en la figura anterior los estados se muestran mediante círculos, las transiciones mediante flechas y los eventos con las etiquetas de las transiciones (En la figura del ejemplo no se muestran las acciones de forma explícita, pero sería un mensaje al cliente con cosas como “Por favor introduzca el PIN”).

Inicio

Tarjeta insertada Introducir el PIN

Esperando el PIN

PIN incorrecto

PIN incorrecto

1º intento

PIN correcto

PIN incorrecto

2º intento PIN correcto

Se traga la tarjeta

3º intento PIN correcto

Acceso a la cuenta

Figura 32 Ejemplo de transición de estados Guía de mejores prácticas de calidad de producto

85

Instituto Nacional de Tecnologías de la Comunicación

El diagrama de estados muestra siete estados pero sólo cuatro posible eventos (Tarjeta insertada, Introducir el PIN, PIN correcto y PIN incorrecto). No se han especificado todas las posibles transiciones aquí, habría también un tiempo de espera desde “Esperando el PIN” y desde los tres intentos desde el que se volvería al estado inicial una vez que el tiempo hubiese pasado y probablemente expulsaría la tarjeta. También habría una transición desde el estado “Se traga la tarjeta” que volvería al estado inicial. Tampoco se han especificado todos los eventos posibles, habría una opción de “cancelar” desde “Esperando el PIN” y los tres intentos, desde el que se volvería también al estado inicial y se expulsaría la tarjeta. El estado de “Acceso a la cuenta” sería el inicio de otro diagrama de estados que mostraría las transiciones válidas que se podrían llevar a cabo en la cuenta. Para empezar con los casos de pruebas cogeremos un escenario típico. Un primer caso de prueba razonable sería la situación normal, donde se mete el código PIN correcto a la primera. Para ser más minuciosos, queremos estar seguros que pasamos por todos los estados (p.ej. al menos una de las pruebas pasa por cada estado) o por todas las transiciones. Un segundo caso de prueba (para visitar todos los estados) sería meter un PIN incorrecto cada vez, de tal forma que el sistema se tragase la tarjeta. Pero aún no hemos probado todas las transiciones. Para hacerlo, probaríamos el caso en el que el PIN es incorrecto la primera vez, pero correcto la segunda, y otro caso en el que el PIN fuese correcto la tercera vez. Estos casos son probablemente menos importantes que los dos primeros. Las condiciones de prueba se pueden obtener del gráfico de estados de varias formas. Cada estado puede considerarse una condición de prueba, como cada transición. Una de las ventajas que tiene la técnica de transición de estados es que el modelo puede ser tan detallado o abstracto como se necesite. Cuando una parte del sistema sea más importante (requiera más pruebas) se necesitará mayor profundidad en el modelo. Cuando la parte del sistema sea menos importante (requiera menos pruebas), el modelo puede usar un estado individual para significar lo que de otra forma serían una serie de estados diferentes. La obtención de pruebas sólo desde el gráfico de estados es muy bueno para ver las transiciones válidas, pero no se ven fácilmente las pruebas negativas, donde se intentan generar transiciones no válidas. Para ver el número total de combinaciones de estados y transiciones, válidos e inválidos, lo más útil es una tabla de estados. La tabla de estados lista todos los estados en un lado de la tabla y todos los eventos que causan transiciones a lo largo de la parte de arriba o viceversa. Cada celda representa un par estado-evento. El contenido de cada celda indica a qué estado se ha de mover el sistema, cuando ocurra el correspondiente evento en el estado asociado. Esto puede incluir eventos erróneos posibles, eventos que no se espera que pasen en ciertos estados. Son condiciones de prueba negativas. La tabla que aparece a continuación lista los estados en la primera columna y las posibles entradas en la fila de arriba. De esta forma, por ejemplo, si el Sistema está en el Estado 1, insertar una tarjeta le llevará al Estado 2. Si está en el Estado 2, y se introduce un PIN correcto, irá al Estado 3. En las celdas que no se pueden dar la combinación estado-evento se ha puesto un guión, p.ej. representan transiciones inválidas desde ese estado.

Guía de mejores prácticas de calidad de producto

86

Instituto Nacional de Tecnologías de la Comunicación

Se ha puesto una interrogación en dos de las celdas, en el caso en el que se introduce un PIN correcto o incorrecto cuando ya se está accediendo a la cuenta. Quizá el sistema tomará el número PIN como la cantidad de dinero que queremos sacar. Esta sería una buena prueba, comprobar cómo reacciona el programa si se introduce el PIN una vez que ya se ha accedido a la cuenta. La mayoría de las otras celdas no válidas serían físicamente imposibles en este ejemplo. Las pruebas inválidas ayudarán a generar transiciones no válidas, transiciones que no deberían ser posibles (pero con frecuencia se convierten en buenas prácticas cuando al probarlas resulta que son posibles). Insertar tarjeta

PIN correcto

PIN incorrecto

S1) Estado de inicio

S2

-

-

S2) Esperando el PIN

-

S6

S3

S3) 1º Intento inválido

-

S6

S4

S4) 2º Intento inválido

-

S6

S5

S5) 3º Intento inválido

-

-

S7

S6) Acceso a la cuenta

-

?

?

S7)Se traga la tarjeta

S1 (para una tarjeta nueva)

-

-

Tabla 13 Tabla de estados 3.4.1.6.

Pruebas de Casos de uso

Los casos de uso son una forma de especificar la funcionalidad como escenarios de negocio o flujos de procesos. Las pruebas de caso de uso son una técnica que ayuda a identificar casos de pruebas que ejerciten el sistema entero transición a transición desde el principio al final. Un caso de uso es una descripción de un uso particular del sistema por un actor (un usuario del sistema). Cada caso de uso describe las interacciones que el actor tiene con el sistema para conseguir una tarea concreta (o, al menos, producir algo de valor al usuario). Los actores son generalmente gente pero pueden ser también otros sistemas. Los casos de uso son una secuencia de pasos que describen las interacciones entre el actor y el sistema. Los casos de uso están definidos en términos del actor, no del sistema, describiendo que hace y ve el actor, más que qué entradas o salidas espera el sistema. De forma muy frecuente usan el lenguaje y términos de negocio más que términos técnicos, especialmente cuando el actor es un usuario de negocio. Sirven como fundamento para desarrollar casos de pruebas en su mayoría en los niveles de pruebas de sistema y pruebas de aceptación. Los casos de uso pueden descubrir defectos de integración, defectos causados por la interacción incorrecta entre diferentes componentes.

Guía de mejores prácticas de calidad de producto

87

Instituto Nacional de Tecnologías de la Comunicación

Los casos de uso describen el flujo de proceso a través de un sistema basado en su uso más probable. Esto hace que los casos de prueba obtenidos de los casos de uso sean particularmente útiles a la hora de encontrar defectos en el uso real del sistema (p.ej. los defectos que los usuarios son más propensos a hacer la primera vez que usan el sistema). Cada caso de uso tiene un escenario dominante (o más probable) y algunas ramas alternativas (cubriendo, por ejemplo, casos especiales o condiciones excepcionales). Cada caso de uso debe especificar cualquier precondición que tenga resultados observables y una descripción del estado final del sistema después de que el caso de uso haya sido ejecutado de forma exitosa. El ejemplo del PIN que usamos para las pruebas de transición de estados podría definirse también en términos de casos de uso, como se puede ver en la tabla siguiente:

Escenario de éxito principal A: actor

PASO

DESCRIPCIÓN

1

A: Insertar tarjeta

2

S: Validar tarjeta y preguntar por el PIN

3

A: Introducir PIN

4

S: Validar PIN

5

S: Permitir el acceso a cuenta

2a

Tarjeta no válida

S: sistema

Extensiones

S: muestra un mensaje y rechaza la tarjeta 4a

PIN no válido S: muestra un mensaje y pide de nuevo el PIN (dos veces)

4b

PIN no válido 3 veces S: se traga la tarjeta y sale

Tabla 14 Caso de uso parcial para la introducción del PIN Para las pruebas de caso de uso, tendríamos una prueba de escenario de éxito y una prueba para cada extensión. En este ejemplo, le daremos a la extensión 4b una prioridad más alta que a la 4a desde un punto de vista de la seguridad. Los requisitos del sistema pueden especificarse también como un conjunto de casos de uso. De esta forma se puede hacer más fácil la involucración de los usuarios en el proceso de definición de los mismos.

Guía de mejores prácticas de calidad de producto

88

Instituto Nacional de Tecnologías de la Comunicación

3.4.1.7.

Basados en la estructura (de caja blanca)

Las técnicas más sofisticadas proporcionan, de forma incremental, una cobertura de código completa. En algunas aplicaciones esto es algo esencial. En un sistema donde la seguridad es crítica, es vital estar seguro que al ejecutar el código no habrá problemas. Medidas como la cobertura de condiciones o la cobertura de condiciones múltiples son usadas para medir la probabilidad de que el código tenga un comportamiento impredecible en escenarios complejos. La cobertura también se aplica a otros tipos y niveles de estructura. Por ejemplo, a nivel de integración, es útil conocer el porcentaje de módulos o conexiones probadas dentro del paquete de pruebas. Las técnicas basadas en estructura suelen usarse para medir la cobertura de las pruebas realizadas. Las técnicas de diseño de pruebas basadas en estructura son una buena forma de generar casos de pruebas adicionales distintos a las pruebas existentes, asegurando así un mayor rango de pruebas. Estas técnicas exploran la estructura de los programas. En vez de probar el código entero, simplemente se aseguran que una serie de elementos particulares del código funcionan correctamente. Pueden ejecutarse casos de prueba simples para hacer un primer sondeo antes de empezar con detalladas pruebas funcionales, o también pueden interpretarse los resultados de las pruebas realizadas por los programadores para asegurar que probaron el código de forma adecuada. Por lo tanto, el punto de partida será el código. Los lenguajes de programación reales tienen una amplia variedad de formularios y estructuras, por lo que no es viable cubrirlos todos. La ventaja del pseudocódigo es que tiene una estructura simple. Existen tres formas de estructurar código ejecutable: ‐

Secuencia: Consiste en ejecutar las instrucciones una a una tal y como van apareciendo en el código.

‐

Selección: En este caso el ordenador tiene que decidir si una condición es verdadera o falsa. Si es verdadera, se toma esa ruta, sino se tomaría una ruta diferente.

‐

Iteración: Consiste en ejecutar un trozo de código más de una vez. 3.4.1.8.

Pruebas de sentencia

El objetivo de las pruebas de sentencia es ir probando las distintas sentencias a lo largo del código. Si se prueban todas y cada una de las sentencias ejecutables del código, habrá una cobertura de sentencia total. Es importante recordar que estas pruebas sólo se centran en sentencias ejecutables a la hora de medir la cobertura. Es muy útil el uso de gráficos de flujo de datos para identificar este tipo de sentencias - que se representan mediante rectángulos. Generalmente, la cobertura de las sentencias es demasiado débil para ser considerada una medida adecuada para probar la efectividad. º º

Guía de mejores prácticas de calidad de producto

100

89

Instituto Nacional de Tecnologías de la Comunicación

3.4.1.9.

Pruebas de decisión

El objetivo de estas pruebas es asegurar que las decisiones en un programa son realizadas adecuadamente. Las decisiones son parte de las estructuras de selección e iteración, por ejemplo, aparecen en construcciones tales como: IF THEN ELSE, o DO WHILE, o REPEAT UNTIL. Para probar una decisión, es necesario ejecutarla cuando la condición que tiene asociada es verdadera y también cuando es falsa. De esta forma, se garantiza que todas las posibles salidas de la decisión se han probado. Al igual que las pruebas de sentencias, las pruebas de decisión tienen una medida de cobertura asociada e intentan conseguir el 100% de la cobertura de decisión. º º 3.4.1.10.

100

Basados en la experiencia

Las técnicas basadas en experiencias son aquellas a las que se recurre cuando no hay una especificación adecuada desde la que crear casos de pruebas basados en especificación, ni hay tiempo suficiente para ejecutar la estructura completa del paquete de pruebas. Las técnicas basadas en experiencia usan la experiencia de los usuarios y de los técnicos de pruebas para determinar las áreas más importantes de un sistema y ejercitar dichas áreas de forma que sean consistentes con el uso que se espera que tengan. Existe un gran rango de técnicas de pruebas, desde las más sofisticadas a las más simples, pero en todas ellas el conocimiento y experiencia de los técnicos de pruebas son factores decisivos para el éxito de las mismas. A continuación se detallan dos tipos de técnicas basadas en la experiencia: ‐

Adivinar errores

‐

Pruebas exploratorias 3.4.1.10.3. Adivinar errores

La técnica ‘adivinar errores’ es una técnica que debería usarse siempre como complemento de otra técnica más formal. El éxito de esta técnica depende en gran medida de las habilidades de los técnicos de pruebas. Hay gente, que por naturaleza, es buen técnico de pruebas, y otros que lo son gracias a su experiencia. Una persona que ha trabajado con un determinado sistema, conocerá mucho mejor las debilidades que tiene y su forma de trabajar, y por lo tanto, al ejecutar las pruebas oportunas, este técnico podrá adivinar con facilidad cuales son los caminos sobre los que el sistema no trabaja de forma adecuada. Hay que aprovechar las habilidades, la intuición y la experiencia de los técnicos de pruebas para identificar pruebas especiales que no son fáciles de capturar mediante técnicas más formales. Realmente no hay ninguna regla a la hora de usar esta técnica. Sin embargo es recomendable que los técnicos de pruebas, en colaboración con los usuarios, construyan lista de posibles errores, y que luego diseñen las pruebas de tal forma que cubran estos errores.

Guía de mejores prácticas de calidad de producto

90

Instituto Nacional de Tecnologías de la Comunicación

Otra manera de aplicar esta técnica es creando listas de fallos y defectos como punto de partida, y luego ir aumentando esta lista mediante la experiencia de los técnicos de pruebas y de los usuarios. Esta lista de fallos y defectos puede usarse para crear un paquete de pruebas y aplicarlo tras el uso de técnicas sistemáticas. 3.4.1.10.4. Pruebas exploratorias Las pruebas exploratorias son una técnica que combina la experiencia de los técnicos de pruebas con una aproximación estructurada a las pruebas con faltan de especificaciones o que son inadecuadas, y donde hay una gran presión respecto al tiempo. Las pruebas exploratorias requieren una planificación mínima y una ejecución máxima de pruebas. El diseño y ejecución de las actividades de pruebas son ejecutadas normalmente en paralelo sin ningún tipo de documentación formal para las condiciones de pruebas, casos de pruebas ni scripts de prueba. De esta forma, las pruebas exploratorias maximizan la cantidad de pruebas que pueden realizarse en un marco de tiempo determinado, cumpliendo siempre los objetivos de las pruebas sobre las áreas más importantes. Esto no significa que no se use algún tipo de técnicas de pruebas más formales. Si se usa por ejemplo el análisis de valor frontera, se probarían los valores frontera más importantes sin escribirlos. Durante la sesión de pruebas exploratoria se tomarían algunas notas para más delante generar un informe. Como su propio nombre indica, las pruebas exploratorias tratan de explorar el software (qué hace, qué no hace, sus debilidades…). El técnico de prueba está constantemente tomando decisiones sobre qué será lo siguiente a probar, cuándo realizar la prueba y de cuánto tiempo se dispone para realizarla. De esta forma las pruebas exploratorias pueden usarse para validar el proceso de pruebas formal, asegurando que los defectos más serios han sido encontrados.

3.4.2.

Estáticas

Las técnicas de pruebas estáticas proporcionan una forma de mejorar la calidad y productividad del desarrollo del software. El objetivo fundamental de las pruebas estáticas es mejorar la calidad de los productos software, ayudando a los ingenieros a reconocer y arreglar sus propios defectos en etapas tempranas del proceso de desarrollo. Aunque las técnicas de este tipo de pruebas son muy efectivas y todas las organizaciones deberían usarlas en la mayoría de los aspectos de su trabajo, no conviene que sustituyan a las pruebas dinámicas. Las pruebas estáticas, como se comentó anteriormente, en ningún momento ejecutan código. Por esta razón, también se llaman técnicas de no ejecución. Estas pruebas son, generalmente, el primer tipo de pruebas que se aplican sobre el software. La mayoría de las técnicas estáticas pueden probar cualquier tipo de documentación ya sea código fuente, o documentación y modelos de diseño, o especificación funcional o de requisitos. Los defectos más encontrados durante este tipo de pruebas son: ‐

Desviaciones respecto a estándares

Guía de mejores prácticas de calidad de producto

91

Instituto Nacional de Tecnologías de la Comunicación

‐

Defectos en los requisitos: por ejemplo, los requisitos son ambiguos.

‐

Defectos del diseño: por ejemplo, que el diseño no encaja con los requisitos.

‐

Difícil mantenibilidad: por ejemplo, que el código sea muy complejo de mantener.

‐

Especificaciones inconsistentes e incorrectas: por ejemplo, la especificación de las conexiones no se corresponde con el diseño.

Como se comentó en la introducción, la revisión es una técnica estática, quizás sea la más conocida y utilizada. Además de encontrar defectos, el objetivo de las revisiones también consiste en informar a la gente involucrada en el proyecto del contenido de los productos, y así ayudarles a entender el papel de su propio trabajo y planear futuras etapas de desarrollo. El tipo y cantidad de defectos encontrados durante las revisiones, pueden ayudar a los técnicos de pruebas a enfocar y seleccionar pruebas efectivas. En algunos casos, los propios clientes asisten a las revisiones, y su participación es de gran ayuda para el equipo de desarrollo. Muchos estudios confirman que las revisiones provocan un aumento significante de la productividad y calidad del producto. Reducir el número de defectos en etapas tempranas del ciclo de vida del producto también significa gastar menos tiempo en pruebas y mantenimiento. Otras ventajas representativas del uso de pruebas estáticas, como por ejemplo las revisiones, son: ‐

El esfuerzo de realizar re-trabajo se reduce sustancialmente, mientras que la productividad de desarrollo probablemente aumente.

‐

La evaluación realizada por un equipo tiene la ventaja adicional de que hay un intercambio de información entre participantes.

‐

Las pruebas estáticas contribuyen a un aumento en la conciencia sobre temas de calidad.

En conclusión, las pruebas estáticas son un apropiado método de mejora de la calidad de software. Es importante que la mejora en la calidad de un producto no se consiga de una sola vez, sino que tenga un carácter más estructural. Aplicar un proceso de pruebas estáticas sobre el proceso de desarrollo permite una mejora del proceso evitando cometer errores similares en el futuro.

3.4.2.1.

Proceso de una revisión

Una revisión consiste en realizar un análisis de un documento con el objetivo de encontrar y eliminar errores. Las revisiones pueden llevarse a cabo por una o varias personas. Las revisiones se usan para revisar documentos escritos tales como especificaciones de requisitos, diseño de sistemas, código, planes de pruebas y casos de prueba. Las revisiones representan la primera forma de pruebas que puede llevarse a cabo durante el ciclo de vida de desarrollo de un producto, ya que los documentos revisados han de estar listos bastante antes de escribir el código.

Guía de mejores prácticas de calidad de producto

92

Instituto Nacional de Tecnologías de la Comunicación

La práctica de revisar documentos (especificaciones) al principio del ciclo de vida del producto, ayuda a identificar defectos antes de que lleguen a formar parte del código ejecutable, de tal forma que serán más fáciles y baratos de eliminar. Si ese mismo defecto es encontrado durante la ejecución de pruebas dinámicas, esto supondrá el coste extra de crear y probar el código defectuoso, diagnosticar la fuente del defecto, corregir el problema y reescribir el código eliminando el defecto. Revisar código según estándares de desarrollo puede también prevenir la aparición de defectos durante la ejecución de pruebas, aunque en este caso, como el código ya está escrito, no se podrán evitar todos los costes y retrasos adicionales. Los objetivos típicos de una revisión son: ‐

Encontrar defectos.

‐

Conseguir un mayor entendimiento

‐

Generar discusiones

‐

Tomar decisiones por consenso.

La forma de dirigir una revisión dependerá de cuál sea su objetivo principal, ya que por ejemplo, una revisión cuyo objetivo sea encontrar defectos será bastante distinta a una que pretenda aumentar el entendimiento acerca de un documento. Todas las revisiones, tanto formales como informales, siguen el mismo proceso básico: ‐

El documento bajo revisión es estudiado por los revisores.

‐

Los revisores identifican los problemas o temas a tratar en la revisión y se lo comunican al autor de forma verbal o mediante un documento.

‐

El autor responde a los comentarios y actualiza el documento según corresponda.

Este proceso básico está siempre presente, pero la mayoría de revisiones formales incluyen etapas adicionales, y prestan más atención a la documentación y a la medición. Roles y responsabilidades Los participantes de cualquier tipo de revisión formal deberían tener conocimiento sobre el proceso de revisión. Un factor crítico de éxito de una inspección o revisión técnica es formar a los participantes que van a tomar parte en la misma. Las mejores revisiones formales surgen de equipos bien organizados, y guiados por un moderador formado. Dentro del equipo de revisión, se distinguen 5 tipos de participantes: ‐

Moderador

‐

Autor

‐

Documentador

‐

Revisor

‐

Supervisor

Guía de mejores prácticas de calidad de producto

93

Instituto Nacional de Tecnologías de la Comunicación

De alguno de estos roles se ha hablado con anterioridad para explicar las fases de una etapa formal, pero se intentará dar más datos acerca de sus responsabilidades. El moderador El moderador de la revisión dirige el proceso de revisión. En cooperación con el autor del documento, el moderador determina el tipo de revisión que se va a realizar y la composición del equipo de trabajo. El moderador realiza una validación de entrada y un seguimiento del trabajo realizado con el objetivo de controlar la calidad del proceso de revisión. El moderador también se encarga de programar las reuniones, entregar documentos antes de la reunión, preparar a los miembros del equipo, marcar el ritmo de la reunión, dirigir las posibles discusiones y almacenar los datos recogidos durante la misma. El autor El autor es la persona que ha creado el documento bajo revisión. El objetivo principal del autor en una revisión sería el de aprender lo máximo posible con el objetivo de mejorar la calidad del documento y su propia habilidad para escribir futuros documentos. La tarea del autor es enfocar tareas que no están del todo claras y entender los defectos encontrados. El documentador (Scribe) Durante la reunión, el documentador tiene que tomar nota de cada defecto mencionado y de cualquier sugerencia acerca de la mejora del proceso, aunque en la práctica, es el autor quien juega este papel. Una buena práctica consiste en que los autores registren sus propios defectos, o tomen notas de ellos con sus propias palabras. Esto les ayudará a entender mejor este documento de registro en un futuro, por ejemplo en la etapa de re trabajo. Sin embargo, que una persona distinta del autor tome el papel de documentador, puede traer ventajas significativas, como que el autor tendrá mucho más tiempo para trabajar sobre su documento. Los revisores La tarea del revisor, también llamado validador o inspector, es la de validar cualquier material con posibles defectos antes de realizar la propia reunión de revisión. El nivel de minuciosidad, el conocimiento del revisor sobre el dominio o su propia habilidad técnica dependen del tipo de revisión. Los revisores deberían ser elegidos para poder representar distintas perspectivas y papeles del proceso de revisión. Además del documento bajo revisión, los revisores trabajan con otro tipo de material como por ejemplo las fuentes de los documentos, estándares, listas de control, etc. En general, cuantos menos documentos de referencia y fuentes se suministren, más habilidad sobre el dominio acerca del contenido del documento bajo revisión se necesitará.

Guía de mejores prácticas de calidad de producto

94

Instituto Nacional de Tecnologías de la Comunicación

El supervisor El supervisor también se involucra en las revisiones. Es quien decide destinar un tiempo de la programación del proyecto para realizar las revisiones, quien determina si se han cumplido los objetivos de la revisión, y por supuesto, quien decide ejecutarla. El supervisor también se ocupa de las solicitudes de formación de los participantes en la revisión. También puede formar parte de la propia revisión dependiendo de su experiencia y formación anterior. En este caso tomaría el papel de revisor. Fases de una revisión A diferencia de las revisiones informales, las revisiones formales siguen un proceso formal. Tienen 6 etapas clave, tal y como muestra la siguiente figura:

Arranque

Preparación

Planificación

1. Planificación 2. Arranque (kick-off) 3. Preparación 4. Reunión de revisión 5. Corrección

Reunión de revisión

Seguimiento

6. Seguimiento

Corrección

Figura 33 Fases de una revisión formal Planificación El proceso de revisión comienza con una ‘solicitud de revisión’ por parte del autor al moderador. El moderador es el responsable de la programación de la revisión, es decir, se encarga de decidir fecha, hora, lugar y los asistentes de la revisión. Además es importante reflejar las revisiones en el plan de proyecto para reservar tiempo suficiente para realizar actividades de revisión y de re-trabajo. En las revisiones formales, por ejemplo las inspecciones, el moderador siempre hace una validación de entrada y define un criterio de salida. La validación de entrada asegura que no se va a perder tiempo realizando una revisión de un documento que no está listo para revisión. Un documento que contenga muchos errores claramente no estará listo para

Guía de mejores prácticas de calidad de producto

95

Instituto Nacional de Tecnologías de la Comunicación

formar parte del proceso de revisión formal. Algunos criterios de entrada básicos para llevar a cabo una validación de entrada son: -

La validación de una muestra de un producto no revelará la mayoría de los defectos.

-

El documento revisado tendrá números de línea.

-

El documento habrá sido corregido aplicando validaciones automáticas.

-

Las referencias necesarias para las inspecciones son estables y están disponibles.

-

El autor está preparado para unirse al equipo revisión y poder confiar en la calidad del documento.

Si el documento pasa la validación de entrada, el moderador y el autor deciden qué partes del documento revisar. El número de páginas a revisar depende de, entre otras cosas, el objetivo de la revisión, el tipo de revisión, el tipo de documento a revisar y el conocimiento extraído de la experiencia de la organización. Por ejemplo, en una revisión el tamaño máximo del documento a revisar es normalmente entre 10 y 20 páginas, y el de una inspección formal es solamente 1 o 2 páginas con el objetivo de poder examinar el documento en profundidad y encontrar los defectos que no son obvios más serios. Después de establecer el tamaño del documento que se va a revisar y de haber seleccionado las páginas que van a validarse, el moderador determina, con la ayuda del autor, la composición del equipo de revisión. El equipo normalmente consta de 4 a 6 participantes, incluyendo al moderador y al autor. Para mejorar la efectividad de la revisión, se asignan distintos papeles a cada participante. Estos papeles ayudan a los revisores a centrarse en tipos particulares de defectos durante la validación reduciendo así la probabilidad de que distintos revisores encuentren el mismo defecto. El moderador asigna los papeles a los revisores. Dentro de las revisiones pueden identificarse los siguientes focos: -

Foco sobre los documentos de alto nivel. Por ejemplo, hacer que el diseño cumpla con los requisitos.

-

Foco sobre estándares. Por ejemplo, consistencia interna, claridad, convención de nombres, plantillas.

-

Foco sobre documentos relacionados en el mismo nivel. Por ejemplo, interfaces entre funciones de software.

-

Foco sobre el uso. Por ejemplo, mantenibilidad o facilidad de pruebas.

El moderador también puede desempeñar un papel dentro de la revisión, a parte del suyo propio. De esta forma, el moderador tendrá un mejor entendimiento del documento y mejorará su habilidad para dirigir la revisión. Además, se mejorará la eficiencia de la revisión ya que el moderador está reemplazando a un ingeniero que puede continuar con su trabajo.

Guía de mejores prácticas de calidad de producto

96

Instituto Nacional de Tecnologías de la Comunicación

Selección del personal

Asignar papeles o roles

Definir criterios de entrada y salida Seleccionar partes del documento a revisar

Figura 34 Actividades de la fase de planificación de una revisión Arranque (Kick-off) Un paso opcional en un proceso de revisión es una reunión de arranque, cuyo objetivo es que todo el mundo tenga la misma visión sobre el documento bajo revisión y asignar el tiempo que se invertirá en la validación del producto. También se pretende conocer el resultado de la validación de entrada y definir el criterio de salida. En general, realizar una reunión de arranque es muy recomendable ya que tiene un efecto positivo en la motivación de los revisores y en la efectividad del proceso de la revisión. Durante la reunión de arranque, los revisores reciben una corta introducción sobre los objetivos de la revisión y sobre los documentos. Se explica la relación entre los documentos a revisar y el resto de documentos, especialmente si el número de documentos relacionados es alto. Durante la fase de arranque también se discuten temas tales como la asignación de roles, la tasa de validación, las páginas a validar, los cambios del proceso y otras posibles cuestiones relacionadas (distribución del documento bajo revisión, fuentes del documento, documentación relacionada…). Preparación Los participantes trabajan de forma individual sobre el documento en revisión, usando documentos relacionados, procedimientos, reglas y listas de validación. Cada individuo identifica defectos, cuestiones y comentarios en función del papel que tienen asignado. Todas las actividades de la revisión han de ser registradas preferentemente en formularios. Los errores de escritura son registrados en documentos que serán entregados al autor al final de la reunión, pero no se mencionan en la propia revisión. Durante esta fase pueden usarse listas de control para hacer las revisiones más efectivas y eficientes, por ejemplo, una lista basada en las perspectivas del usuario, el técnico de pruebas, el técnico de mantenimiento, o listas de control para los problemas típicos de codificación. Un factor de éxito crítico en toda fase de preparación es el número de páginas validadas por hora. A este número se llama tasa de validación. La tasa óptima de validación es el resultado de una mezcla de factores tales como:

Guía de mejores prácticas de calidad de producto

97

Instituto Nacional de Tecnologías de la Comunicación

-

El tipo de documento

-

La complejidad del documento

-

El número de documentos relacionados

-

La experiencia del revisor

Normalmente, este valor está entre el rango de 5 a 10 páginas por hora, aunque como se ha comentado antes, para revisiones formales el rango desciende a 1 página por hora. Durante la fase de preparación, los participantes en la revisión no deberían exceder estos valores. Puede ser útil recoger información y medir el proceso de revisión, el criterio especifico de la compañía sobre la tasa de validación y el tamaño del documento. Reunión de la revisión La reunión consiste, normalmente, en los siguientes elementos: -

Fase de registro

-

Fase de discusión

-

Fase de decisión

Fase de registro Durante la primera fase, los defectos identificados durante la preparación son mencionados uno a uno, revisor tras revisor, y son registrados normalmente por el propio autor. Puede ser útil la participación de una persona distinta al autor en las revisiones formales, como por ejemplo en las inspecciones. Para asegurar la eficiencia en el proceso de la reunión no debería haber discusiones durante esta primera fase. Si hay algún tema que necesita ser discutido, se registra y se trata en la fase de discusión. La severidad de los defectos encontrados debería proponerse por la persona que los encuentra, y tanto la severidad como el defecto han de ser registrados. Las clases de severidad pueden ser: ‐

Critica: Los defectos causarán grandes daños. El alcance e impacto del defecto va más allá del documento bajo revisión.

‐

Mayor: Los defectos podrían causar grandes efectos, por ejemplo, un fallo en el diseño puede resultar en un error en la implementación.

‐

Menor: No es probable que los defectos causen mucho daño. Por ejemplo, podría ocurrir que no se cumpla con los estándares o las plantillas.

Los errores de escritura no son parte de la clasificación de defectos, simplemente son anotados por los participantes y entregados al autor del documento al final de la reunión. El objetivo de la fase de registro es registrar tantos fallos como sean posibles en un marco de tiempo determinado. Para asegurarse de esto, el moderador intentará conseguir una alta tasa de registro, que es el número de defectos registrados por minuto. En una reunión de

Guía de mejores prácticas de calidad de producto

98

Instituto Nacional de Tecnologías de la Comunicación

revisión formal de pruebas disciplinada y dirigida, la tasa de registro debería estar entre 1 y 2 defectos registrados por minuto. Fase de discusión En esta fase se tratarán los temas clasificados como ‘temas de discusión’. Las revisiones informales normalmente no tendrán fase de registro, empezarán directamente con la fase de discusión. En esta fase, los participantes pueden tomar parte en la discusión mediante comentarios y razonamientos. El moderador es el encargado, entre otras cosas, de evitar que las discusiones se vean afectadas por temas personales, reformular comentarios (si fuese necesario) y establecer descansos para calmar discusiones acaloradas entre participantes. Una de las funciones más importantes del moderador en esta fase es asegurarse que se llega a un resultado tras la discusión. Al final de la reunión, se tomará una decisión sobre el documento basándose en un criterio formal de salida. El criterio de salida más importante es el número medio de defectos encontrados por página. Si este número excede cierto nivel, el documento deberá ser revisado de nuevo. Fase de decisión Si un proyecto está bajo presión, el moderador algunas veces se verá forzado a saltarse la repetición de revisiones (re-revisiones), y usar un documento de los defectos más comunes. Establecer un acuerdo acerca del criterio del nivel de salida, de forma cuantificable, ayudará al moderador a tomar decisiones firmes. Si el documento cumple los criterios de salida, será validado durante la fase de seguimiento (que se tratará más adelante) por el moderador o por uno o más participantes de la revisión. Corrección En función de los defectos detectados, el autor mejorará el documento bajo revisión. No todos los defectos necesitan corrección. Es responsabilidad del autor juzgar si un defecto tiene que ser o no arreglado. Aunque no se tome ninguna medida correctora sobre un defecto, éste debería ser registrado para informar que el autor tiene conocimiento de dicho defecto. Es importante para la fase de seguimiento que los cambios realizados sobre el documento sean fáciles de identificar. Para ello puede usarse un control de cambios, por ejemplo. Seguimiento (Follow-up) El moderador es el responsable de asegurar que se han tomado acciones sobre los defectos registrados, sugerencias de mejora de procesos, y solicitudes de cambio. Aunque el moderador se asegura de que el autor ha tomado acciones sobre todos los defectos conocidos, no es necesario que valide todas sus correcciones en detalle. Para revisiones más formales, el moderador además validará la conformidad del criterio de salida. Con el objetivo de controlar y optimizar el proceso de revisión, el moderador recogerá una serie de mediciones en cada paso del proceso tales como el número de defectos encontrados, el número de defectos encontrados por página, el tiempo invertido en validar

Guía de mejores prácticas de calidad de producto

99

Instituto Nacional de Tecnologías de la Comunicación

cada página, el esfuerzo en realizar la revisión, etc. Es responsabilidad del moderador asegurarse de que la información es correcta y almacenada para un futuro análisis.

3.4.2.2.

Tipos de revisiones

Un único documento puede ser objeto de más de una revisión. Por ejemplo, una revisión informal puede realizarse antes que una revisión técnica, o una inspección puede llevarse a cabo durante la especificación de requisitos antes de presentársela al cliente para su revisión y aprobación. El tipo de una revisión varía en función de su nivel de formalidad. En este caso, ‘formalidad’ se refiere a nivel de estructura y documentación asociada con la revisión. Unos tipos de revisión son completamente informales mientras que otros son muy formales. Los factores que determinan el nivel de formalidad en una revisión son: ‐

La madurez del proceso de desarrollo: cuanta más madurez tenga el proceso, más formales tenderán a ser las revisiones.

‐

Requisitos legales o normativa: son usados para guiar y dirigir las actividades de desarrollo de software en ciertas industrias, especialmente en áreas de seguridad crítica.

‐

La necesidad de un seguimiento de auditorías. Los procesos de revisión formal aseguran la posibilidad de seguir de forma minuciosa todo el ciclo de vida del desarrollo del software. El nivel de formalidad en este tipo de revisiones puede ayudar a aumentar el nivel de este seguimiento.

La siguiente figura muestra los distintos niveles de formalidad en función del tipo de revisión:

Figura 35 Tipos de revisión en función del nivel de formalidad

Guía de mejores prácticas de calidad de producto

100

Instituto Nacional de Tecnologías de la Comunicación

No existe una revisión perfecta, sino que cada una tiene un propósito distinto durante las etapas del ciclo de vida del documento. Los principales tipos de revisiones, sus características fundamentales y los objetivos comunes se describen a continuación. Informal Dar un borrador de un documento a un colega para que lo lea es el ejemplo más simple de revisión. El objetivo principal de las revisiones informales es el de encontrar defectos. Es una forma de conseguir beneficios (limitados) a un bajo costo. Las principales características de este tipo de revisiones son: ‐

No tienen ningún proceso formal a seguir.

‐

La revisión puede documentarse, aunque no es necesario ni habitual.

‐

El uso de este tipo de revisiones varían en función del revisor. Por ejemplo, si el revisor no tiene habilidades técnicas, pero es capaz de validar de forma rápida el documento y asegurar que tiene sentido.

‐

La revisión puede implementarse mediante ‘pares de programadores’, donde uno revisa el código del otro, o mediante un técnico que lidere el diseño de las revisiones y el código.

Walkthrough Un walkthrough se caracteriza porque el autor del documento bajo revisión va guiando al resto de participantes a través del documento exponiendo sus ideas para conseguir un entendimiento común y recoger respuestas. Es especialmente útil si los asistentes no están relacionados con el software, o no son capaces de entender los documentos de desarrollo de software. En las revisiones walkthrough se explica el contenido del documento paso a paso hasta llegar a un consenso en los cambios y en el resto de información. Los participantes seleccionados proceden de distintos departamentos y tienen diferentes conocimientos y experiencias. Por la forma en que se estructura la reunión, pueden participar un gran número de personas. De esta forma, se consiguen diversos puntos de vista respecto al contenido del documento revisado. Si la audiencia de la revisión representa una amplia gama de habilidades y disciplinas, se asegura que no se pasa por alto ningún defecto importante durante el walkthrough. El walkthrough es especialmente útil en documentos de alto nivel como especificaciones de requisitos. Las metas específicas de un walkthrough dependen de su papel en la creación del documento. En general, se podrían aplicar los siguientes objetivos: ‐

Presentar los documentos a la gente involucrada con el software, con el objetivo de reunir información con respecto al tema documentado.

‐

Explicar y evaluar los contenidos del documento.

‐

Establecer un entendimiento común del documento.

Guía de mejores prácticas de calidad de producto

101

Instituto Nacional de Tecnologías de la Comunicación

‐

Examinar y discutir la validez de las soluciones propuestas y la viabilidad de las alternativas, estableciendo consenso.

Las características principales de los walkthroughs son: ‐

La reunión es dirigida por los autores y a menudo está presente un documentador.

‐

Pueden usarse escenarios y simulacros para validar el contenido.

‐

Es opcional realizar reuniones previas a la propia reunión.

Revisión técnica Una revisión técnica es una reunión de discusión que se centra en conseguir consenso sobre el contenido técnico de un documento. En comparación con las inspecciones, las revisiones técnicas son menos formales y se centran menos (o nada) en la identificación de defectos de los documentos. Los expertos necesarios para una revisión técnica son, por ejemplo, responsables del diseño y usuarios clave. En la práctica, las revisiones técnicas varían pudiendo ser informales o muy formales. Los objetivos de una revisión técnica son: ‐

Evaluar el valor de conceptos técnicos y alternativas del entorno del proyecto y del propio producto.

‐

Establecer consistencia en el uso y representación de conceptos técnicos.

‐

Asegurarse, en una etapa temprana, de que los conceptos técnicos son usados de forma correcta.

‐

Informar a los participantes del contenido técnico del documento.

Las características clave de una revisión técnica son: ‐

A menudo se lleva a cabo por ‘pares’ (revisión por pares).

‐

Es un proceso de detección de defectos documentado que involucra a expertos técnicos.

‐

Idealmente es dirigida por un moderador formado, pero también es posible que lo lleve un experto técnico.

‐

Se realiza de forma separada, mientras que se examina el producto y se encuentran los defectos.

‐

El uso de listas de comprobación o listas de registro son opcionales.

Inspección La inspección es el tipo de revisión más formal. El documento bajo inspección es preparado y validado minuciosamente por revisores antes de la reunión, se compara el producto con sus fuentes y otros documentos, y se usan listas de comprobación. En la reunión de la inspección se registran los defectos encontrados y se pospone toda discusión para la fase de discusión. Todo esto hace que la inspección sea una reunión muy eficiente.

Guía de mejores prácticas de calidad de producto

102

Instituto Nacional de Tecnologías de la Comunicación

Dependiendo de la organización y los objetivos de un proyecto, las inspecciones pueden tener distintas metas. Las más comunes son: ‐

Ayudar al autor a mejorar la calidad del documento bajo inspección.

‐

Eliminar defectos de forma eficiente tan pronto como sea posible.

‐

Mejorar la calidad del producto creando documentos con alto nivel de calidad.

‐

Crear un entendimiento común intercambiando información entre los participantes de la inspección.

‐

Formar a nuevos empleados sobre el proceso de desarrollo de las organizaciones.

‐

Aprender de los defectos encontrados y mejorar los procesos con el objetivo de evitar recurrencia en defectos similares.

‐

Tomar una muestra de un documento grande (secciones o alguna página del mismo) con el objetivo de medir la calidad del documento, y así, mejorar el trabajo y el proceso en el futuro.

Las características principales de una inspección son: ‐

Está dirigido normalmente por un moderador formado, no por el autor.

‐

Usa papeles o roles definidos durante el proceso.

‐

Involucra a dos personas (o pares) para examinar el producto.

‐

Se usan listas de comprobación durante la fase de preparación.

‐

Se lleva a cabo una preparación por separado mientras que se examina el producto y se encuentran sus defectos.

‐

Los defectos encontrados son documentados en una lista de registro.

‐

El moderador realiza un seguimiento formal aplicando criterios de salida.

‐

Opcionalmente, para mejorar los procesos y aprender de los defectos encontrados, se realiza un análisis de las causas de los mismos.

‐

Las métricas son agrupadas y analizadas para optimizar el proceso.

3.4.2.3.

Factores de éxito de una revisión

Implementar una revisión (formal) no es algo fácil, ya que hay muchos caminos que llevan al fracaso. La siguiente lista contiene un número de factores de éxito que mejoran las oportunidades de tener éxito a la hora de implementar las revisiones, y que por tanto deberían considerarse: ‐

Cada revisión debería tener un objetivo claramente predefinido y previamente acordado, y una persona que asegurase que el objetivo se cumple. Esta persona necesitará tener experiencia, entusiasmo y pensamiento crítico para guiar a los moderadores y al resto de los participantes. Su autoridad debería ser clara para toda la organización. (Encontrar a la persona indicada)

Guía de mejores prácticas de calidad de producto

103

Instituto Nacional de Tecnologías de la Comunicación

‐

Seleccionar los documentos que sean más importantes en un proyecto para revisarlos. Revisar los documentos más críticos, como los relacionados con los requisitos o la arquitectura del producto, beneficiará el proceso de revisión del proyecto. Todas estas horas invertidas en realizar revisiones, tendrán un claro y alto retorno de inversión. Además, es importante estar seguro de que cada revisión tiene un objetivo claro, y que se ha seleccionado el tipo correcto de revisión que encaje con el objetivo definido, no revisar todo mediante inspecciones. En función del riesgo que el documento tenga asociado, puede darse el caso de que simplemente necesita una revisión informal. (Seleccionar los documentos adecuados)

‐

Asegurarse que las revisiones forman parte de las actividades diarias, y que las horas invertidas en este proceso estén plasmadas en el plan del proyecto. Los ingenieros involucrados en las revisiones han de ser informados de esta planificación con suficiente antelación para prepararse. Hacer un seguimiento del tiempo invertido ayudará a planificar las revisiones siguientes. También es importante gestionar las revisiones. (Planear y realizar seguimiento de las revisiones)

‐

Es importante proporcionar formación sobre las técnicas de revisión, especialmente sobre las técnicas más formales como las inspecciones. Si no, es probable que haya dificultades en el proceso debido a la gente que no lo entiende. Debería darse formación especial a los moderadores para prepararles en su papel dentro del proceso de revisión. (Formación de los participantes)

‐

Las revisiones tratan de evaluar la documentación de alguna persona dentro de un proyecto. Algunas revisiones tienden a ser demasiado personales cuando no están bien gestionadas por el moderador. Los aspectos psicológicos también deberían ser un tema importante de formación, de tal forma que la revisión sea una experiencia positiva para el autor. Durante las revisiones, los defectos deberían ser tratados de forma objetiva. (Gestionar temas relacionados con las personas)

‐

Hacer que el proceso sea tan formal como la propia cultura del proyecto y el nivel de madurez permitido, siempre siguiendo las reglas formales. No llegar a ser demasiado teórico o detallado. Las listas de control y los papeles o roles tienden a aumentar la efectividad de la identificación de defectos. (Seguir las reglas)

‐

La mejora continua del proceso y las herramientas basadas en las ideas de los participantes (listas de comprobación) aseguran la motivación de los ingenieros involucrados. La motivación es la clave para tener un proceso de cambios exitoso. (Proceso de mejora continua y herramientas)

‐

Informar de los resultados y beneficios obtenidos del proceso de revisión tan pronto como sea posible, y discutir las consecuencias de los defectos si no han sido encontrados en etapas tempranas. Debe realizarse un seguimiento de los costes, y los beneficios deberían, al igual que los costes, cuantificarse. (Informar de los resultados)

Guía de mejores prácticas de calidad de producto

104

Instituto Nacional de Tecnologías de la Comunicación

Factores de éxito 9

Encontrar a la persona indicada

9

Seleccionar los documentos adecuados

9

Planear y realizar seguimientos de las revisiones

9

Formación de los participantes

9

Gestionar temas relacionados con las personas

9

Seguir las reglas

9

Informar de los resultados

9

Proceso de mejora continua y herramientas

Tabla 15 Factores de éxito de una revisión formal El proceso de revisión es simple, pero no fácil. Cada paso del proceso es claro y es necesaria gente con experiencia para llevarlo a cabo.

3.4.2.4.

Análisis estático

Al igual que las revisiones, el análisis estático busca defectos sin ejecutar el código. Sin embargo, el análisis estático se lleva a cabo una vez que se escribe el código. Su objetivo es encontrar defectos en el código fuente y en los modelos del software. El análisis estático puede encontrar errores difíciles de detectar durante la ejecución de pruebas mediante el análisis del código del programa. Las ventajas del análisis estático son: ‐

Temprana detección de defectos antes de la ejecución de las pruebas. Como ocurre en las revisiones, cuanto antes se encuentren los defectos más barato y fácil será corregirlos.

‐

Avisos tempranos acerca de aspectos sospechosos del código o del diseño del producto. Esto se consigue mediante el cálculo de métricas como por ejemplo, métricas de complejidad alta.

‐

El uso de técnicas dinámicas no facilita la identificación de defectos del tipo: inconsistencias en los modelos de software, como por ejemplo enlaces o conexiones incorrectas o desconocidas, o incumplir estándares de desarrollo. Este tipo de defectos pueden detectarse mediante análisis estático.

‐

Mejora la mantenibilidad del código y del diseño. El análisis estático puede reconocer código complejo que si es modificado puede llegar a ser fácil de entender y por lo tanto más fácil de mantener.

‐

Prevención de defectos. Realizando un análisis desde las etapas tempranas del ciclo de vida, se detectará no sólo los defectos sino la raíz de los mismos, de tal forma que esta información puede ser muy útil para prevenir la aparición de estos defectos.

Guía de mejores prácticas de calidad de producto

105

Instituto Nacional de Tecnologías de la Comunicación

Defectos detectados Los defectos típicos encontrados con herramientas de análisis estático son: ‐

Referenciar una variable con un valor indefinido, como por ejemplo, usar una variable como parte de un cálculo antes de haberle asignado un valor.

‐

Inconsistencia en la conexión entre módulos y componentes. Por ejemplo, un módulo que solicite dos valores de un segundo módulo que tenga una sola salida.

‐

Variables que nunca son usadas. Esto no es estrictamente un error, pero es recomendable no declarar variables que no van a usarse.

‐

Código inalcanzable, es decir, líneas de código que nunca serán ejecutadas ya que la lógica o flujo del programa no tiene un camino que las incluya.

‐

Violación de los estándares de programación.

‐

Vulnerabilidades de seguridad.

‐

Violación de la sintaxis del código o de los modelos del software, por ejemplo el uso incorrecto de un modelo.

Las herramientas de análisis estático añaden gran valor cuando se usan durante las pruebas de integración y unitarias. Normalmente, implican una valoración de las normas y estándares de desarrollo por parte de los desarrolladores y diseñadores durante el modelado del software. Herramientas Las herramientas de análisis estático se ejecutan automáticamente e informan de todos los defectos que identifican. Algunos de ellos son insignificantes y no implica apenas trabajo el corregirlos, mientras que otros pueden ser críticos y necesitan corrección urgente. Estos defectos, además, necesitan una buena gestión para asegurar el beneficio del uso de estas herramientas. Las herramientas muestran no sólo atributos estructurales (métricas de código) sino también representaciones gráficas de control de flujo, relación de los datos y el número de distintos caminos que puede haber de una línea de código a otra. Un compilador puede ser considerado como una herramienta de análisis estático ya que muestra usos incorrectos y detecta no conformidades con respecto al lenguaje de codificación convencional (sintaxis). Las herramientas estáticas más comunes son: ‐

Estándares de código

‐

Métricas de código

‐

Estructuras de código

Estándares de código Un estándar de codificación consiste en un conjunto de reglas de programación, convenciones de nombres y especificaciones. Es recomendable la adopción de estándares Guía de mejores prácticas de calidad de producto

106

Instituto Nacional de Tecnologías de la Comunicación

ya que ahorran mucho esfuerzo. Además, los estándares de codificación más conocidos tienen herramientas de validación disponibles que soportan el estándar. (Otra forma de hacerlo sería comprar analizadores estáticos de código y declarar reglas para el estándar). Sin el uso de estas herramientas, la aplicación de un estándar de codificación en una organización es probable que fallase. Las tres causas principales son: ‐

El número de reglas del estándar normalmente es muy grande y por lo tanto es casi imposible recordar todas sus normas.

‐

Algunas reglas dependientes del contexto necesitan revisión de varios archivos, y sería realmente duro de validar por un ser humano.

‐

Si la gente gastara tiempo en validar los estándares de codificación durante las revisiones, se distraerían de encontrar otros defectos, haciendo el proceso de revisión menos efectivo.

Métricas de código Al llevar a cabo análisis de código estático, normalmente la información se calcula mediante atributos estructurales de código, como la frecuencia de comentarios, profundidad de anidamiento de código, complejidad ciclomática y número de líneas del código. Esta información es útil cuando hay cambios en el sistema, para ver si el diseño o el código es más grande, o más complejo, o más difícil de mantener y entender. Las métricas también ayudarán a decidir entre varias alternativa de diseño. Hay muchos tipos distintos de medidas estructurales. Cada una de ellas informa del esfuerzo requerido para escribir el código. El 20% del código causará el 80% de los problemas, y el análisis de la complejidad ayudará a detectar este 20%. La complejidad ciclomática se basa en el número de decisiones o ‘caminos’ de un programa. La forma más sencilla de calcular este número es sumar el número de sentencias de decisiones binarias (if, while, for…) y sumarle 1. Es importante dar un indicador acerca del número de pruebas necesarias para eliminar la mayor parte de los defectos de una aplicación. Las áreas de código identificadas como más complejas serán candidatas para las revisiones y para pruebas dinámicas adicionales. Estructuras de código A menudo se asume que los módulos de gran tamaño llevan más tiempo de especificación, diseño, codificación y prueba. La estructura del código juega un papel muy importante en todo esto. Hay distintos aspectos relacionados con la estructura de código a considerar: ‐

La estructura de flujo de control

‐

La estructura de flujo de datos

‐

La estructura de datos.

Guía de mejores prácticas de calidad de producto

107

Instituto Nacional de Tecnologías de la Comunicación

Flujo de control La estructura de flujo de control marca la secuencia de ejecución de las instrucciones. Este aspecto refleja las iteraciones y bucles en el diseño de un programa. Si sólo se mide el tamaño de un programa, no se dará ningún tipo de información relacionada con la frecuencia de ejecución de las instrucciones. Hay muchas métricas de código relacionadas con la estructura de flujo de control, como por ejemplo, el número de niveles anidados o la complejidad ciclomática. Flujo de datos La estructura de flujo de datos sigue el rastro de los datos a los que se acceden y modifican desde el código. Muchas veces, las transacciones aplicadas sobre estos datos son más complejas que las instrucciones que los implementan. Las métricas de flujo de datos muestran cómo actúan los datos a medida que son transformados por el programa. Los defectos típicos que pueden encontrarse son: ‐

una referencia a una variable que no tiene un valor asignado

-

variables que nunca son usadas.

Estructura de datos La estructura de datos se refiere a la propia organización de los datos, independientemente del programa. Cuando un dato es añadido a cualquier tipo de estructura bien definida (lista, cola, pila…), los algoritmos de modificación, creación o borrado es más probable que también estén bien definidos. Por lo tanto, la estructura de datos proporciona mucha información sobre la dificultad de manejar datos y diseñar casos de pruebas. Es decir, en muchos casos un programa es complejo porque su estructura de datos es compleja, y no por la propia complejidad de control y flujo de datos.

3.5.

ENFOQUE DESDE DISTINTAS METODOLOGÍAS

Tanto CMMI® como SPICE contemplan la verificación y la validación como actividades importantes dentro de alguna de sus categorías o procesos. CMMI® y SPICE son dos de las más importantes metodologías que existen y por esa razón vamos a ver el enfoque que cada una de ellas da cada una de estas actividades (verificación y a la validación).

3.5.1.

SPICE

El modelo SPICE describe los procesos que una organización debe ejecutar para adquirir, proveer, desarrollar, operar, evolucionar y dar soporte al software, y las prácticas genéricas que caracterizan la capacidad de esos procesos. Cada proceso del modelo se describe en términos de prácticas básicas, que son las actividades esenciales de un proceso específico. El modelo clasifica los procesos en cinco categorías que son: Cliente-Proveedor, Ingeniería, Proyecto, Soporte y Organización. De todos los procesos del modelo, los siguientes son los que contemplan actividades de verificación y validación:

Guía de mejores prácticas de calidad de producto

108

Instituto Nacional de Tecnologías de la Comunicación

Verificación ‘Integración y pruebas de software’ e ‘Integración y pruebas del sistema’ son dos procesos de SPICE relacionados con la verificación. Ambos procesos pertenecen a la categoría de ingeniería. La principal diferencia entre ambos es que mientras que el primero trata de probar los requisitos funcionales del sistema, el proceso de ‘Integración y pruebas del sistema’ prueba los requisitos del sistema (no funcionales). Estos procesos consisten en agrupar y probar los elementos del software (unidades) o del sistema, dependiendo del proceso, para comprobar que cumplen con los requisitos del software o del sistema respectivamente. Las prácticas propuestas para estos procesos son: -

Construir conjuntos de unidades de software o de elementos del sistema (dependiendo del proceso).

-

Desarrollar pruebas para estos conjuntos.

-

Ejecutar las pruebas.

-

Desarrollar pruebas para el software o para el sistema.

-

Probar el software o sistema integrado.

Otro proceso que también contempla actividades de verificación es la ‘Realización de revisiones de pares’. Este proceso pertenece a la categoría de soporte de SPICE. Su propósito es encontrar y eliminar los defectos de los productos del proyecto de manera eficiente. Cuando los clientes o personas de dirección se involucran en las revisiones, normalmente se las llama revisiones técnicas. Algunas revisiones se centran en comprobar aspectos técnicos del producto, por lo que los revisores normalmente son ‘colegas’ con las mismas habilidades que el autor del producto. Este tipo de revisiones se llaman ‘revisiones por pares’. Hay distintas formas de realizar las revisiones. Una de ellas son las ‘inspecciones’, de las que se habló con anterioridad. Las prácticas propuestas para este proceso son : -

Seleccionar los productos a revisar.

-

Identificar los estándares que se van a usar en la revisión.

-

Establecer criterios de conformidad.

-

Establecer criterios para volver a revisar un producto.

-

Distribuir los materiales de la revisión.

-

Realizar la revisión de pares

-

Documentar los puntos de actuación.

-

Hacer seguimiento de estas acciones.

Guía de mejores prácticas de calidad de producto

109

Instituto Nacional de Tecnologías de la Comunicación

Validación ‘Realizar auditorias y revisiones colectivas’ es un proceso de la categoría ‘ClienteProveedor’, cuyo objetivo es conseguir un entendimiento común entre los clientes acerca de los objetivos del contrato, y llegar a un acuerdo acerca de lo que debería hacerse para asegurar que el desarrollo del producto satisface al cliente. Este proceso se consigue a través de distintas auditorias y revisiones como las siguientes: -

Auditorias del contrato

-

Revisiones de gestión

-

Revisiones técnicas

-

Revisiones de aceptación

Las prácticas recomendadas son: -

Establecer qué revisiones y auditorias colectivas se van a realizar.

-

Preparación previa estableciendo alcance, resultados deseado, …

-

Organizar revisiones de gestión colectivas con el cliente.

-

Organizar revisiones técnicas colectivas con el cliente.

-

Apoyo al cliente en la revisión de aceptación

-

Realizar valoración del proceso colectivo.

3.5.2.

CMMI®

CMMI® es un modelo de madurez de mejora de procesos para el desarrollo y mantenimiento de productos y servicios. Consiste en una serie de mejores prácticas que dirigen las actividades de desarrollo y mantenimiento que cubren el ciclo de vida del producto. Al igual que ocurre en SPICE, el modelo CMMI® organiza sus áreas de proceso en categorías: Gestión de proceso, Gestión de proyecto, Ingeniería y Soporte. Las áreas de proceso ‘Validación’ y ‘Verificación’ están englobadas en la categoría de Ingeniería. Validación El propósito de la ‘Validación’ en CMMI® es demostrar que un producto o componente del mismo satisface el uso para el que se creó al situarlo sobre el entorno previsto. Las dos metas que se pretenden cumplir en esta área son: Preparar la validación Las actividades de preparación incluyen la selección de productos o componentes a validar, establecer y mantener el entorno de validación, procedimientos y criterios. Cualquier producto o componente del producto puede ser objeto de validación, incluyendo mantenimiento, sustituciones o productos de formación.

Guía de mejores prácticas de calidad de producto

110

Instituto Nacional de Tecnologías de la Comunicación

Los entornos usados para realizar la integración y verificación de los productos pueden compartirse con las actividades de validación y así reducir costes y mejorar la eficiencia y la productividad. Las prácticas relacionadas con esta meta son: ‐

Seleccionar productos a validar: Seleccionar los productos y componentes de productos a validar y los métodos de validación que van a aplicarse.

‐

Establecer un entorno de validación: Establecer y mantener el entorno necesario que soporte la validación.

‐

Establecer procedimientos y criterios de validación: Establecer y mantener procedimientos y criterios de validación.

Validar los productos y los componentes de los productos. Los productos y componentes de productos son validados para asegurar que son apropiados para usarse en su entorno operativo. Las actividades de validación se realizan a través del ciclo de vida del producto, y las prácticas a realizar son: ‐

Realizar validación

‐

Analizar los resultados de las actividades de validación

Verificación El propósito de la ‘Verificación’ en CMMI® es asegurar que los productos seleccionados cumplen los requisitos especificados. Esta área de proceso tiene una serie de metas: Preparación de la verificación Para preparar la verificación las prácticas a seguir son: ‐

Seleccionar productos para la verificación: Se debe hacer una selección de los productos a verificar y los métodos de verificación aplicables a cada producto.

‐

Establecer el entorno de verificación: Establecer y mantener el entorno necesario para soportar la verificación.

‐

Establecer criterios y procedimientos de verificación: Establecer y mantener procedimientos y criterios para los productos seleccionados.

Realización de revisiones de pares Las revisiones de pares incluyen un examen metodológico de los productos para identificar posibles defectos del producto o recomendar cambios necesarios. Las revisiones de pares se aplican sobre los productos seleccionados, y las prácticas a seguir son: -

Preparar revisiones por pares

-

Dirigir revisiones por pares: conducir las revisiones de pares e identificar temas resultantes de la revisión. Analizar los datos de las revisiones por pares: Analizar los datos obtenidos de las prácticas anteriores.

-

Guía de mejores prácticas de calidad de producto

111

Instituto Nacional de Tecnologías de la Comunicación

Verificar la selección de productos La verificación de los métodos, procedimientos y criterios se usa para verificar los productos seleccionados y cualquier mantenimiento asociado, formación y servicios de soporte, usando para ello el apropiado entorno de verificación. -

Realizar la verificación de los productos seleccionados.

-

Analizar los resultados de la verificación de las actividades de verificación

3.5.3.

Comparativa CMMI® SP 1.1 Selección de productos para la verificación. SP 1.2 Establecer el entorno de verificación SP 1.3 Establecer procedimientos y criterios de verificación.

VERIFICACIÓN

SP 2.1. Preparar revisiones de pares SP 2.2 Dirigir revisiones por pares SP 2.3 Analizar datos de las revisiones por pares SP 3.1 Realizar verificación SP 3.2 Analizar resultados de la verificación.

SPICE ENG 5/6.1 Construir conjuntos de unidades de software /elementos del sistema ENG 5/6.2 Desarrollar pruebas para estos conjuntos. ENG 5/6.3 Ejecutar las pruebas. ENG 5/6.4 Desarrollar pruebas para el software /sistema. ENG 5/6.5 Probar el software /sistema integrado. SUP 5.1 Seleccionar los productos a revisar. SUP 5.2 Identificar los estándares que se van a usar en la revisión. SUP 5.3 Establecer criterios de conformidad. SUP 5.4 Establecer criterios para volver a revisar un producto. SUP 5.5 Distribuir materiales de revisión. SUP 5.6 Realizar la revisión de pares SUP 5.7 Documentar los puntos de actuación. SUP 5.8 Hacer seguimiento de estas acciones.

VALIDACIÓN

SP 1.1 Selección de productos a validar SP 1.2 Establecer entorno de validación SP 1.3 Establecer procedimientos y criterios de validación

CUS 4.1 Establecer revisiones y auditorías colectivas a realizar. CUS 4.2 Preparación previa CUS 4.3 Organizar revisiones de gestión colectivas.

SP 2.1 Llevar a cabo la validación

CUS 4.4 Organizar revisiones técnicas colectivas.

SP 2.2. Analizar los resultados de la validación

CUS 4.5 Apoyo al cliente en la revisión de aceptación CUS 4.6 Realizar valoración del proceso colectivo.

Tabla 16 Comparativa Validación-Verificación desde enfoques CMMI® y SPICE

Guía de mejores prácticas de calidad de producto

112

Instituto Nacional de Tecnologías de la Comunicación

4.

MEDICIÓN DE LA CALIDAD DEL SOFTWARE

“Cuando puedes medir aquello de lo que estás hablando, y expresarlo en números, sabes algo sobre ello; pero cuando no lo puedes medir, y no lo puedes expresar en números, tu conocimiento acerca de ello es insatisfactorio”- Lord Kelvin. “Si no puedes medir, no puedes controlar. Si no puedes controlar, no puedes mejorar”- Anónimo. “In God we trust. All other must provide data”- W. Edwards Deming. Necesitamos números para: •

Saber a qué nos comprometemos

•

Conocer cuál es la probabilidad de alcanzar ese compromiso

•

Saber si estamos en el camino correcto para conseguir los compromisos

•

Saber si estamos consiguiendo los compromisos de manera efectiva en costes

•

Saber si hemos mejorado

4.1.

INTRODUCCIÓN

Este capítulo comenzará exponiendo unos fundamentos sobre la teoría de la medición, indicando las relaciones entre conceptos teóricos, definiciones y mediciones, y describiendo algunas medidas básicas que se utilizan con frecuencia. Se explicarán los distintos niveles o escalas de medición que se pueden utilizar: nominal, ordinal, intervalo y razón o ratio, así como las diferencias entre algunas mediciones básicas como ratio, proporción, porcentaje e índice, y la conveniencia de utilizar unos u otros según el concepto a medir. A continuación, se mencionarán los criterios más importantes para comprobar la calidad de la medición, fiabilidad y validez, y su relación con los errores que se producen en la medición. A la hora de implementar un programa de medición en una organización, hay una serie de buenas prácticas y lecciones aprendidas de programas de medición llevados a cabo con éxito que pueden ser de gran utilidad para las empresas que hayan decidido dar este paso. Uno de los objetivos de este capítulo es resaltar estas buenas prácticas y difundir las lecciones aprendidas. Además, se va a profundizar en la definición de métricas, proporcionando guías de acuerdo a distintas metodologías y técnicas: ‐

Se abordará cómo contemplan la definición de métricas los modelos de calidad más extendidos en el panorama de las empresas de TI en España: CMMI® y SPICE.

‐

Se explicará cómo aplicar la métrica de punto función, un método para medir el tamaño del software independientemente de la tecnología utilizada y que se puede aplicar al software en todas las fases de su ciclo de vida.

Guía de mejores prácticas de calidad de producto

113

Instituto Nacional de Tecnologías de la Comunicación

‐

Se mostrará el proceso para definir métricas que cubran las necesidades de información de los proyectos y de la organización, según el método PSM.

‐

Se explicará el enfoque GQM para relacionar la definición de las métricas con los objetivos de negocio.

Por otra parte, a lo largo de este capítulo, se expondrán algunos ejemplos de las métricas de calidad de software más habituales, haciendo especial énfasis en las métricas de calidad de producto, ya que esta primera versión de la guía de mejores prácticas está enfocada a la calidad de producto, aunque también se mencionarán algunas métricas de calidad de los procesos y métricas de negocio alineadas con los objetivos de negocio.

4.2.

FUNDAMENTOS DE LA MEDICIÓN DEL SOFTWARE

Es indiscutible que la medición es crucial para el progreso de todas las ciencias. El progreso científico se alcanza a través de observaciones y generalizaciones basadas en datos y mediciones, la derivación de éstos en teorías y la confirmación o refutación de las teorías mediante hipótesis basadas en datos empíricos. Vamos a considerar como ejemplo la proposición “cuanto más rigurosa sea la ejecución del proceso de desarrollo software del front-end de una aplicación, mejor será la calidad en el back-end”. Para confirmar o refutar esta proposición, primero es necesario definir los conceptos clave. Por ejemplo, definimos “proceso de desarrollo software” y distinguimos los pasos del proceso y las actividades del front-end de las del back-end. Asumimos que después del proceso de recogida de requisitos, el proceso de desarrollo consiste en las siguientes fases: •

Diseño

•

Revisión del diseño e inspecciones

•

Codificación

•

Inspección del código

•

Depuración y pruebas del desarrollo

•

Integración de los componentes y módulos que forman el producto

•

Pruebas del sistema

•

Pruebas de aceptación de usuario

La integración es la fase del desarrollo en la que varias partes y componentes se unen para formar un único producto software completo. Normalmente, después de la integración el producto pasa a estar bajo control formal de cambios. Es decir, cada cambio en el software debe tener una razón específica (p.ej. corregir un error no detectado en las pruebas) y debe ser documentado y se le debe realizar un seguimiento. Así pues, podemos usar la integración como punto diferenciador: las fases de diseño, codificación, depuración e integración se clasifican como el front-end del proceso de desarrollo y las pruebas de sistema y pruebas de aceptación de usuario constituyen el back-end.

Guía de mejores prácticas de calidad de producto

114

Instituto Nacional de Tecnologías de la Comunicación

Necesitamos especificar unos indicadores para la definición y hacerlos operativos. Por ejemplo, supongamos que la documentación del proceso dice que todos los diseños y el código deben ser inspeccionados. Una definición operativa de implementación rigurosa puede ser la cobertura de inspecciones expresada en términos de porcentaje de líneas de código (LOC) estimadas o puntos función (FP) inspeccionados. Otro indicador de buenas revisiones e inspecciones podría ser la valoración de cada inspección basándose en una serie de criterios. Se puede utilizar una escala de cinco puntos para evaluar el grado de efectividad (p.ej. 5 = muy efectivo, 4 = efectivo, 3 = algo efectivo, 2 = inefectivo, 1 = inspección mala) Además del diseño, revisiones de diseño, implementación de código e inspecciones de código, la prueba del desarrollo es parte de nuestra definición de front-end del proceso de desarrollo. Necesitamos definir “ejecución rigurosa” de las pruebas. Dos indicadores que se pueden utilizar son el porcentaje de cobertura en términos de instrucciones ejecutadas y el índice de defectos expresado en términos de número de defectos eliminados por miles de líneas de código (KLOC) o por puntos función. De la misma forma, necesitamos definir calidad en el back-end y decidir qué indicadores utilizar. Para simplificar, vamos a usar el indicador de defectos encontrados por KLOC durante las pruebas de sistema como indicador de calidad en el back-end. A partir de estas métricas, podemos formular varias hipótesis como las siguientes: •

Para proyectos de software, cuanto mayor sea el porcentaje de diseños y código inspeccionados, menor será el índice de defectos en la última fase de pruebas de sistema.

•

Cuanto más efectivas sean las revisiones de diseño y las inspecciones de código, según la valoración del equipo de inspección, menor será el índice de defectos en la última fase de pruebas de sistema.

•

Cuanto más minuciosas sean las pruebas del desarrollo (en términos de cobertura de pruebas) antes de la integración, menor será el índice de defectos en la fase de pruebas del sistema.

Con las hipótesis formuladas, podemos recoger datos y probar las hipótesis. Necesitamos determinar la unidad de análisis para nuestras mediciones y datos. En este caso, podría ser a nivel de proyecto o a nivel de componente de un gran proyecto. Si somos capaces de recoger datos de un número considerable de fuentes (p. ej. 35 proyectos o componentes), podemos realizar análisis estadísticos para probar las hipótesis. Podemos clasificar los proyectos o componentes en varios grupos de acuerdo a la variable independiente de cada hipótesis y luego comparar el resultado de la variable dependiente (índice de defectos durante las pruebas de sistema) entre los distintos grupos. Podemos realizar un simple análisis correlativo o llevar a cabo un análisis estadístico más sofisticado. Si las hipótesis se sostienen por los datos recogidos, podemos confirmar la proposición. En caso contrario, refutamos la proposición. Si surgen dudas o cuestiones sin resolver durante el proceso (p.ej. ¿Son válidos los indicadores?, ¿Son los datos fiables?, ¿Hay otras variables que necesitamos controlar para hacer un análisis de la hipótesis?), quizá hace falta una investigación mayor. Sin embargo, si la hipótesis o proposición se confirma, podemos utilizar

Guía de mejores prácticas de calidad de producto

115

Instituto Nacional de Tecnologías de la Comunicación

el conocimiento obtenido y actuar en consecuencia para mejorar la calidad de nuestro desarrollo de software. Este ejemplo demuestra la importancia de la medición y los datos, en el sentido de que conducen el progreso de la ciencia y la ingeniería. Sin una verificación empírica a través de datos y mediciones, las teorías y proposiciones se vuelven abstractas. Los conceptos se pueden definir formalmente y hacer operativos generando unas métricas e indicadores a partir de los cuáles se puedan recoger datos. En una definición teórica, un concepto se define en términos de otros conceptos primitivos. Una definición operativa, por el contrario, es aquella en la que se describen las métricas y procedimientos utilizados para obtener datos. Por ejemplo, una definición operativa de “índice de defectos de un producto software” indicaría la fórmula del índice de defectos: defecto que se va a medir (numerador), el denominador (p.ej. número de líneas de código, puntos función), cómo realizar la medición, etc. Nivel de medición Cuando hacemos operativa una definición y derivamos indicadores de medición debemos considerar una escala de medición. Por ejemplo, para medir la calidad de la inspección de software podemos usar una escala de cinco puntos para valorar la efectividad de la inspección o podemos utilizar un porcentaje para indicar la cobertura de la inspección. En algunos casos, se puede aplicar más de una escala de medición. En otros, la naturaleza del concepto y su definición operativa sólo permiten una determinada escala. A continuación, se van a exponer los cuatro niveles o escalas de medición: nominal, ordinal, intervalo o razón/ratio: Nominal Consiste en clasificar elementos en categorías en función de un determinado atributo. Es el nivel más bajo de medición. Las categorías deben cubrir todas las posibles categorías de un atributo y deben ser exclusivas, es decir, un elemento sólo puede pertenecer a una categoría. Por ejemplo, si clasificamos los productos software en función del modelo del proceso de desarrollo podemos tener las siguientes categorías: cascada, espiral, iterativo, etc. Así, podemos comparar los valores de distintos indicadores, como índice de defectos, en las distintas categorías de productos software. Ordinal Es un nivel más alto de medición que el nominal ya que, no sólo agrupamos los elementos en categorías sino que las ordenamos. Por ejemplo, podemos clasificar los proyectos de desarrollo software según los niveles de madurez del SEI o una escala de rigor en los procesos: cumple totalmente el proceso, cumple algo el proceso, no cumple el proceso. Sin embargo, esta escala no ofrece información acerca de la magnitud de la diferencia entre elementos. Por ejemplo, según la escala anterior, sabemos que “cumple totalmente el proceso” es mejor que “cumple algo el proceso” y que esto es mejor que “no cumple el proceso” pero no podemos decir que la diferencia entre las dos primeras categorías es igual que la diferencia entre las dos segundas.

Guía de mejores prácticas de calidad de producto

116

Instituto Nacional de Tecnologías de la Comunicación

Intervalo Una escala de intervalos indica la diferencia exacta entre los puntos de medición. Se le pueden aplicar las operaciones matemáticas de suma y resta. Esta escala requiere una unidad de medición bien definida que se puede tomar como estándar. Razón/Ratio Este es un tipo de escala de intervalos en el que se puede colocar una unidad cero de forma no arbitraria. Es el nivel más alto de medición y se le pueden aplicar todas las operaciones matemáticas. Cada nivel contiene las propiedades de los niveles inferiores. Cuanto más alto sea el nivel, más potente será el análisis que se pueda realizar de los datos. Mediciones básicas Independientemente de la escala de medición utilizada, cuando recogemos datos necesitamos analizarlos para extraer información significativa. Existen varias medidas y estadísticas para consolidar los datos y poder realizar comparaciones. A continuación, vamos a explicar algunas medidas como ratio, proporción, porcentaje e índice, que son utilizadas frecuentemente en el ámbito del desarrollo de software y la calidad de software. Ratio Es el resultado de dividir una cantidad por otra. El numerador y el denominador son dos categorías excluyentes. Por ejemplo, podemos tener el ratio del número de personas en el departamento de pruebas de una organización con respecto al número de personas en el departamento de desarrollo. º

100%

º

El ratio podrá ir desde 1:1 a 1:10. En el primer caso, será un equipo independiente del desarrollo el que tenga la responsabilidad de las pruebas y el aseguramiento de la calidad. En el segundo caso, será el grupo de desarrollo el que asuma la mayor parte de las pruebas del producto y un grupo de pruebas realizará pruebas de sistema en el entorno del cliente. Proporción La proporción se diferencia del ratio en que el numerador es parte del denominador, no son categorías excluyentes. Además, se pueden comparar múltiples categorías, en lugar de sólo dos como en el ratio. En el siguiente ejemplo, tenemos la proporción de clientes satisfechos sobre el total de clientes: º º Porcentaje Una proporción se convierte en porcentaje cuando se expresa en términos de unidades por cien. Los porcentajes se utilizan normalmente para presentar resultados en informes pero muchas veces no se utilizan de forma correcta. En primer lugar, como los porcentajes

Guía de mejores prácticas de calidad de producto

117

Instituto Nacional de Tecnologías de la Comunicación

representan un dato relativo, es importante dar suficiente información del contexto, como el número total de casos, para que la información se pueda interpretar correctamente. En segundo lugar, el número total de casos debe ser suficientemente grande como para poder utilizar porcentajes. Si el número de casos es pequeño, se deberían utilizar números absolutos en lugar de porcentajes. Índice Los ratios, proporciones y porcentajes son medidas estáticas que proporcionan una visión del fenómeno de interés en un momento específico. El concepto de índice se asocia al dinamismo del fenómeno de interés. Se puede definir como una medida del cambio en una cantidad (y) por unidad de otra cantidad (x) de la que la primera (y) depende. La variable x suele ser tiempo pero es importante especificar qué unidad se va a utilizar cuando describimos un índice de este tipo. El concepto de riesgo de exposición también es clave en la definición de índice y es lo que lo distingue de la proporción. Este concepto significa que todos los elementos en el denominador son susceptibles de convertirse en elementos del numerador. En calidad de software, se utiliza el índice de defectos, donde el riesgo de exposición se define como oportunidades de error mientras que el numerador es el número de defectos. Normalmente, el índice de defectos se define como el número de defectos por miles de líneas de código (KLOC) en una unidad de tiempo determinada. En ese caso, no se conoce la oportunidad de error. Cualquier línea de código es susceptible de error y un defecto puede involucrar a varias líneas de código. Por tanto, la métrica es una medida aproximada del índice de defectos. Fiabilidad y validez Una vez que se han definido las métricas y se han recogido los datos, hay que evaluar si estas métricas son buenas, es decir, si cumplen su objetivo – medir el concepto que queremos medir y hacerlo con calidad. De los criterios para comprobar la calidad de la medición, los más importantes son la fiabilidad y la validez. La fiabilidad se refiere a la consistencia de un número de medidas tomadas utilizando un mismo método y sobre un mismo elemento. Si estas medidas tomadas de forma repetida son altamente consistentes o incluso idénticas, podemos decir que el método de medición tiene un alto grado de fiabilidad. Si hay bastantes variaciones entre las medidas tomadas sobre el mismo elemento, el método utilizado tiene poca fiabilidad. Estas variaciones pueden deberse, en algunos casos, a falta de especificación acerca de cómo tomar las medidas (en qué momento, qué escala utilizar, etc.). La cantidad de errores en la medición puede ser mayor o menor pero siempre está presente. El objetivo, por supuesto, es alcanzar el mayor grado de fiabilidad posible. La fiabilidad puede expresarse en términos del tamaño de las desviaciones estándar de las mediciones tomadas. La validez se refiere a si la métrica realmente mide lo que se pretende medir, es decir, hasta qué punto la medida empírica refleja el significado real del elemento que estamos considerando. El hecho de que una medida sea fiable no implica que sea válida y viceversa.

Guía de mejores prácticas de calidad de producto

118

Instituto Nacional de Tecnologías de la Comunicación

Por ejemplo, una báscula de peso puede dar idénticos resultados en cinco medidas consecutivas y, por tanto, ser fiable. Sin embargo, las medidas puede que no sean válidas y no reflejen el peso real de una persona si la báscula está mal regulada y tiene un desfase de 500 gr. Errores en la medición Podemos considerar dos tipos de errores en la medición: sistemáticos y aleatorios. Los errores sistemáticos en la medición están relacionados con la validez mientras que los aleatorios están asociados con la fiabilidad. La manera de eliminar los errores sistemáticos es mediante un mejor entendimiento del concepto que queremos medir y utilizar deducciones lógicas y razonamiento para conseguir una mejor definición del mismo. Para reducir los errores aleatorios, necesitamos buenas definiciones operativas y, en base a ellas, una buena ejecución de las operaciones de medición y recogida de datos.

4.3. 4.3.1.

DEFINICIÓN DE MÉTRICAS Buenas prácticas

La medición en el entorno de las TI Los sistemas de información y comunicación cada vez son más sofisticados y complejos para afrontar un mercado en continuo cambio. Las organizaciones necesitan tomar mejores decisiones y a tiempo para tener éxito en los proyectos y sistemas de la organización. Con este panorama, la información objetiva es un requisito para la toma de decisiones críticas y basadas en hechos. Un buen proceso de medición puede proporcionar esta información objetiva. La implementación de un programa de medición que proporcione información detallada de una organización, les permitirá tomar decisiones rápidas y adecuadas en áreas competitivas. A continuación, se exponen algunas guías para obtener beneficios de la implementación de un programa de medición exitoso basado en la información: •

Utilizar los resultados: la información medida debe ayudar a los encargados de la toma de decisiones a entender los problemas de los proyectos y de la organización, evaluarlos y actuar en consecuencia.

•

Empezar poco a poco: no intentar hacer demasiado en poco tiempo. Empezar con un conjunto de mediciones pequeño, evaluar estas mediciones y el proceso, e intentar evolucionar el programa con el tiempo. Como los procesos de TI están bastante interrelacionados, a veces, un número pequeño de mediciones puede solventar un amplio conjunto de necesidades de información.

•

Proporcionar formación adecuada: todos los usuarios deben entender lo que representan los datos medidos y cómo interpretar los resultados. Se recomienda ofrecer formación tanto en la metodología como en las herramientas para obtener un

Guía de mejores prácticas de calidad de producto

119

Instituto Nacional de Tecnologías de la Comunicación

resultado efectivo. Normalmente, la medición implica un cambio en la mentalidad del negocio así que será necesario gestionar el cambio de forma activa. •

Demostrar compromiso: la aceptación de un nuevo proceso comienza con la demostración del compromiso por parte de la organización y la dirección. Es necesario renovar y mantener el compromiso a medida que el programa evoluciona con el tiempo.

•

Minimizar costes: un proceso de medición debe ser efectivo en costes para considerarse exitoso. Recoger sólo los datos necesarios, de acuerdo a los objetivos de medida y necesidades clave de información. Automatizar el proceso siempre que sea posible.

•

Adoptar una orientación a la acción: en las primeras fases de planificación de la medición, seleccionar medidas alineadas con las necesidades clave de información tanto a nivel de la organización como a nivel de proyectos. La información se debe obtener de forma temprana para reducir riesgos y poder corregir posibles problemas a tiempo. El programa de medición debe estar integrado en las prácticas del negocio de la organización, no debe ser tratado como un proceso añadido y aislado del resto.

•

Comunicar: la buena comunicación mejora la comprensión por todas las partes involucradas y conduce a una situación exitosa. La comunicación es esencial y la actualidad de los datos es crítica.

Uno de los obstáculos más críticos para el éxito de la medición es que los objetivos de distintos grupos dentro de una organización no siempre están alineados y a veces pueden resultar contradictorios. Por ejemplo, todas las organizaciones realizan un seguimiento del calendario de los proyectos. Sin embargo, los datos que se toman y la importancia de las mediciones del calendario varían dentro de la organización. La mayoría de gerentes técnicos se preocupan por desarrollar un producto que cumpla los requisitos funcionales y de fiabilidad; los objetivos de calendario y costes son, a menudo, determinados por otras partes como clientes, gerentes de marketing y alta dirección. A los directivos les preocupa estimar el tiempo para la entrega de un producto. Al gerente de negocio le interesa conocer el tiempo que llevará comercializar una nueva funcionalidad y el impacto de un retraso en la cuota de mercado. Por otro lado, el gerente de procesos estará preocupado por los cambios en el tiempo de desarrollo del software y su impacto en otros procesos. Un proceso de medición a nivel organizacional debe seleccionar medidas sobre el calendario que cubran todas estas necesidades de información. En grandes organizaciones, las medidas definidas por la organización se pueden sustituir por medidas específicas a nivel de proyecto que cubran las necesidades de información tanto de la organización como de los gerentes de proyecto, haciendo el programa más flexible. Un programa de medición exitoso debe integrar las necesidades de información de todos los involucrados en tomas de decisiones.

Guía de mejores prácticas de calidad de producto

120

Instituto Nacional de Tecnologías de la Comunicación

Lecciones aprendidas Al comenzar a medir los procesos y productos software y sistemas de ingeniería, obtener unos resultados de medición útiles puede ser un desafío. La parte positiva es que la mayoría de programas de medición exitosos están basados en unos pocos conceptos básicos que forman la base de un programa de medición efectivo y un enfoque efectivo en costes y flexible para alcanzar las necesidades de información identificadas, incluso en los entornos más complejos. A continuación, se exponen unas lecciones aprendidas de programas de medición llevados a cabo con éxito: 1. La medición es un proceso consecuente pero flexible que debe ser adaptado a las necesidades de información y características de un proyecto particular u organización. Las mediciones deben cambiar a medida que el entorno y las necesidades de información cambian. La medición no es una lista de medidas a tomar sino un proceso para refinar los datos que nos proporcionan información relativa a las necesidades de información cambiantes. 2. Los responsables de la toma de decisiones deben comprender lo que se está midiendo. La comunicación adecuada de los resultados de las mediciones a los gerentes, tanto de negocio como técnicos, fomenta la toma de decisiones en el momento adecuado. 3. Las mediciones se deben utilizar para que sean efectivas. El programa de medición debe jugar un papel importante a la hora de ayudar a los responsables de la toma de decisiones a optimizar el rendimiento. Las organizaciones con éxito utilizan los resultados de las mediciones de forma regular para la toma de decisiones. Como la mayoría de organizaciones se componen de una cartera de diversos proyectos, la información obtenida a nivel de proyecto debe ser agrupada en los niveles apropiados de la organización para poder ser utilizada de forma efectiva. Además, dentro del proceso de medición y análisis, los siguientes puntos son clave: •

Definir buenas métricas: o

Conectadas con las metas y objetivos

o

Conectadas con los procesos que impactan a las metas y objetivos

o

No ambiguas y claramente definidas

o

Con una definición operativa para las mediciones/datos

o

Sencillas de entender e implementar

•

Comprobar la validez de los datos recogidos: que son correctos, precisos, íntegros, consistentes y completos.

•

Analizar las métricas inmediatamente después de calcularlas y compararlas con las metas u objetivos fijados. El análisis de los datos es más fructífero cuando conduce a un proceso de mejora continua. Las medidas deben mostrar un

Guía de mejores prácticas de calidad de producto

121

Instituto Nacional de Tecnologías de la Comunicación

aumento en la estabilidad, una reducción en la desviación, una mejora en la media del rendimiento. Si el análisis de los datos sólo se utiliza para mostrar lo que hemos hecho, puede ser informativo, pero no será más útil que leer el periódico del día anterior. •

Tomar acciones correctivas y preventivas. Si hay alguna desviación sobre la meta o la meta no se alcanza, se deben iniciar acciones correctivas y preventivas. Posibles acciones correctivas y preventivas podrían ser: o

Actualizar el proceso de documentación

o

Utilizar distintos métodos y/o ciclos de vida de proyecto

o

Introducir controles adicionales a través de la verificación y validación

o

Utilizar distintas tecnologías/herramientas

o

Actualizar la infraestructura/sistema de medición

o

Automatizar algunas actividades del proyecto

o

Actualizar las habilidades/formación de la gente

Implementar un programa de medición en la organización Un buen programa de medición ayuda a: •

Entender el pasado cuantitativamente

•

Controlar el presente cuantitativamente

•

Predecir el futuro cuantitativamente

Implementar un programa de medición es un esfuerzo importante, especialmente cuando los objetivos a nivel de proyecto y a nivel de la organización difieren o surgen algunos conflictos. Sin embargo, llegar a un equilibrio entre las necesidades de información de ambos niveles es posible. Las necesidades de información de los responsables de la toma de decisiones dirigen la selección de medidas de software y técnicas de análisis asociadas. Estas necesidades normalmente se derivan de unos objetivos establecidos por la dirección o de problemas (riesgos, falta de información) que dificultan la consecución de estos objetivos. La medición no tiene sentido si no hay un responsable de toma de decisiones con una necesidad de información que lo motive. La primera tarea para planificar un programa de medición es definir las necesidades de información de la organización. Para ello, será necesario formar a la dirección y trabajar con ellos para identificar y priorizar sus necesidades de información. Según PSM (Practical Software Measurement), las necesidades de información se pueden clasificar en siete categorías: •

Calendario y progreso

•

Recursos y costes

Guía de mejores prácticas de calidad de producto

122

Instituto Nacional de Tecnologías de la Comunicación

•

Tamaño de producto y estabilidad

•

Calidad de producto

•

Ejecución de proceso

•

Efectividad de la tecnología

•

Satisfacción del cliente

Una vez que se han definido las necesidades de información de la organización, se pueden identificar un conjunto de medidas común que cubra estas necesidades. Esto quedará recogido en un plan de medición organizacional que, además, describirá el repositorio donde se almacenarán los datos y el proceso a seguir por cada proyecto para incorporar los datos a este repositorio. Este conjunto de medidas será requerido para cada proyecto, pudiendo realizarse adaptaciones para proyectos específicos. Al tratarse de un conjunto común de medidas, se puede comenzar la implantación del programa a pequeña escala, a modo de piloto, para extenderlo posteriormente a todo el departamento de TI. A la hora de decidir qué medidas recoger se pueden tener en cuenta varios factores: •

¿Qué datos existen ya y están disponibles para ser analizados?

•

¿Qué datos nuevos serían relativamente fáciles de obtener?

•

¿Qué medidas contribuirían de forma inmediata a la toma de decisiones?

La segunda fase de un programa de medición involucra a los proyectos. Los gerentes de proyecto tienen unas necesidades de información específicas a nivel de proyecto, aparte de las definidas por la organización. El proceso de medición, por tanto, debe cubrir tanto las medidas requeridas por la organización (adaptadas, si es necesario) como aquellas orientadas a las necesidades de información específicas del proyecto. Tener un único proceso de medición simplifica la recogida de datos y reduce la duplicidad. Las medidas del proyecto se documentan en un plan de medición del proyecto. Los analistas del proyecto deben recopilar los datos de su propio proyecto a la vez que reportar las medidas comunes al repositorio de la organización para su consolidación y análisis. La clave para equilibrar las necesidades de información de múltiples niveles de la organización es definir medidas que sean útiles tanto a nivel de proyecto como a nivel organizacional. Las medidas organizacionales normalmente están basadas en consolidaciones de datos de proyecto. Por ejemplo, si una necesidad de información para la organización es entender la calidad de producto, se requerirán datos sobre defectos en cada proyecto. A nivel de proyecto, se pueden generar medidas detalladas de los defectos encontrados y cerrados orientadas a satisfacer necesidades de información como “¿Estará listo el producto para comenzar las pruebas de aceptación en el tiempo planificado?”. A nivel organizacional, los datos sobre los defectos se pueden consolidar para cubrir necesidades de información del tipo “¿Cuántos defectos se generan, por término medio, en cada fase del proyecto?” o “Para un proyecto nuevo, ¿cuánto esfuerzo y tiempo se debe planificar para el re-trabajo derivado de la resolución de defectos?”.

Guía de mejores prácticas de calidad de producto

123

Instituto Nacional de Tecnologías de la Comunicación

Como conclusión, la implementación de un proceso objetivo de medición basado en hechos implica definir necesidades de información a nivel de la organización y de proyecto y seleccionar medidas que proporcionen información relativa a esas necesidades. La información debe ser comunicada en la organización y utilizada de forma regular en la toma de decisiones para que el proceso de medición tenga éxito. 4.3.1.1.

Ejemplos de métricas

A continuación, se exponen algunos ejemplos de métricas alineadas con objetivos de negocio así como métricas que se pueden utilizar para controlar la ejecución de los procesos de un proyecto. Métricas de negocio Objetivo de negocio

Métrica de negocio Índice medio de satisfacción del cliente Desviación en calendario

Maximizar la satisfacción del cliente

Cumplimiento del acuerdo sobre el nivel de servicio Desviación en calendario Entrega a tiempo

Cumplimiento del acuerdo sobre el nivel de servicio Densidad de defectos entregados

Mejorar la calidad de los entregables

% correcciones rechazadas Desviación del índice de llegadas entre versiones

Mejorar la productividad

Productividad total Productividad total

Mejorar la efectividad de costes

Coste de calidad Volatilidad de requisitos Desviación de esfuerzo en los proyectos con precio fijo

Mejorar los ingresos

Volatilidad de requisitos Mejorar la precisión de la estimación

Desviación de esfuerzo en los proyectos con precio fijo

Minimizar re-trabajo

Coste de calidad

Mejorar la calidad de los entregables

Eficiencia en eliminación de defectos

Mejorar la adherencia a los procesos

Cumplimiento de los procesos de calidad

Tabla 17 Métricas de negocio

Guía de mejores prácticas de calidad de producto

124

Instituto Nacional de Tecnologías de la Comunicación

Métricas de proceso Procesos

Métricas asociadas Desviación de esfuerzo de cada tarea completada

Planificación y seguimiento y control de proyecto

Desviación en calendario de cada tarea completada % de tareas/hitos completados a tiempo Densidad de defectos de las revisiones

Proceso de revisión de código

Eficiencia de las revisiones Índice de revisiones Densidad de defectos de las pruebas

Proceso de pruebas unitarias Eficiencia de las pruebas Tiempo en corrección de defectos durante revisiones de código Codificación y pruebas de sistema Tiempo en corrección de defectos durante pruebas de sistema Ingeniería

% coste de baja calidad Esfuerzo de resolución por parche/versión liberado

Proceso de mantenimiento Tiempo de resolución por parche/versión liberado Esfuerzo de resolución de incidencias por incidencia Proceso de gestión de incidencias

Edad de las incidencias cerradas Edad de las incidencias abiertas Nº caídas del sistema

Proceso de gestión de la disponibilidad

Porcentaje de comprobaciones de mantenimiento preventivo realizadas frente a las planificadas

Tabla 18 Métricas de proceso

4.3.2.

Definición de métricas basada en metodología CMMI®

El modelo CMMI® contempla la medición del software en las áreas de proceso Medición y Análisis (MA), perteneciente al nivel de madurez 2: Gestionado, y las áreas de proceso Gestión Cuantitativa de Proyectos (QPM) y Ejecución de Procesos Organizacionales (OPP), del nivel de madurez 4: Gestión cuantitativa.

Guía de mejores prácticas de calidad de producto

125

Instituto Nacional de Tecnologías de la Comunicación

Área de Medición y Análisis El propósito del área de Medición y Análisis es desarrollar y sostener la capacidad de tomar medidas para dar soporte a la gestión de las necesidades de información. Esto implica lo siguiente: •

Especificar los objetivos de la medición y análisis de forma que estén alineados con las necesidades de información y objetivos identificados.

•

Especificar las medidas que se van a tomar, mecanismos de recogida y almacenamiento de datos, técnicas de análisis y mecanismos para informar y recoger feedback.

•

Implementar la recogida, almacenamiento, análisis e informe de datos.

•

Proporcionar resultados objetivos que se puedan utilizar en la toma de decisiones y llevar a cabo acciones correctivas apropiadas.

La integración de las actividades de medición y análisis en los procesos del proyecto ayuda a conseguir lo siguiente: •

Planificación y estimación objetiva.

•

Seguimiento de la ejecución real frente al plan y objetivos establecidos.

•

Identificación y resolución de problemas relacionados con el proceso.

•

Una base para incorporar la medición en procesos adicionales en un futuro.

El enfoque inicial para las actividades de medición es a nivel de proyecto. Sin embargo, la capacidad de medición debe proporcionar valor a las necesidades de información de toda la organización. Los proyectos pueden almacenar sus datos y resultados en un repositorio específico de su proyecto. Cuando los datos sean compartidos o consolidados por toda la organización, deben residir en el repositorio de medición de la organización. En la figura 36, se reflejan las metas de este proceso: alinear las actividades de medición y análisis con las necesidades de información y objetivos identificados, y proporcionar resultados de estas mediciones basados en una evidencia objetiva, de forma que ayuden al seguimiento de la ejecución, cumplimiento de obligaciones contractuales, toma de decisiones técnicas y de gestión y toma de acciones correctivas. Cada una de estas metas se alcanza a través de una serie de prácticas, que se pueden observar también en la figura. -

Establecer objetivos de medida derivados de las necesidades de información y objetivos identificados. Los objetivos de medida deben documentar el propósito de las actividades de medición y análisis y especificar el tipo de acciones que se pueden tomar a partir de los resultados del análisis de los datos.

-

Especificar medidas alineadas con los objetivos de medida. Los objetivos de medida se refinan en medidas precisas y cuantificables. Las medidas pueden ser básicas o derivadas. Los datos de las medidas básicas se obtienen por mediciones directas (p.ej.: número de defectos, medidas estimadas y reales de esfuerzo y coste,

Guía de mejores prácticas de calidad de producto

126

Instituto Nacional de Tecnologías de la Comunicación

etc.) mientras que los datos de las medidas derivadas provienen de otros datos, normalmente combinando dos o más medidas básicas, y se suelen expresar como proporciones o índices (p.ej.: densidad de defectos, cobertura de pruebas, etc.). -

Especificar procedimientos para la recogida y almacenamiento de datos. La especificación explícita de los métodos de recogida de datos ayuda a asegurar que se recogen los datos correctos de forma adecuada. La especificación de los procedimientos de almacenamiento de datos ayuda a asegurar que los datos están disponibles y accesibles para su uso futuro.

-

Especificar procedimientos de análisis: especificar cómo se van a analizar y se va a informar sobre los datos medidos. Especificar los procedimientos de análisis por adelantado asegura que el análisis se va a realizar conforme a los objetivos de medida (y, por tanto, conforme a las necesidades de información y objetivos en que éstos se basan). Esto supone también una comprobación de que se van a recoger los datos necesarios.

-

Recoger datos medidos y comprobarlos para verificar que están completos y son íntegros.

-

Analizar los datos medidos e interpretarlos. Se revisan los resultados con los agentes involucrados y se anotan revisiones necesarias para futuros análisis.

-

Almacenar los datos y resultados: gestionar y almacenar los datos medidos, especificaciones de medida y resultados del análisis permite un uso futuro de los datos históricos efectivo en tiempo y coste. Esta información también es necesaria para proporcionar un contexto en el que interpretar los datos, los criterios de la medición y resultados del análisis.

-

Comunicar los resultados de las actividades de medición y análisis a todos los agentes involucrados en un tiempo adecuado para servir de apoyo en la toma de decisiones y ejecución de acciones correctivas.

Guía de mejores prácticas de calidad de producto

127

Instituto Nacional de Tecnologías de la Comunicación

Alinear las actividades de Medición y Análisis

Establecer objetivos de medida

Especificar medidas

Especificar procedimientos recogida y almacenamiento datos

Repositorio de medición

Objetivos de medida

Especificar procedimientos análisis

Procedimientos y herramientas

Indicadores de medida Proporcionar resultados de la medición

Comunicar resultados

Almacenar datos y resultados

Analizar datos medidos

Recoger datos medidos

Figura 36 Medición y análisis (CMMI®) Área de Gestión Cuantitativa de Proyectos El propósito del área de Gestión Cuantitativa de Proyectos es gestionar cuantitativamente los procesos definidos en el proyecto para alcanzar los objetivos establecidos en el proyecto en cuanto a calidad y ejecución de los procesos. Para ello, aplica técnicas cuantitativas y estadísticas. Los objetivos de calidad y ejecución de procesos para un proyecto están basados en los objetivos establecidos por la organización. El proceso definido para el proyecto consta de elementos y subprocesos cuya ejecución se puede predecir. Se pretende entender la variación que experimenten los subprocesos críticos para alcanzar los objetivos de calidad y ejecución de procesos. Cuando se identifique una causa para la variación del proceso se tomarán acciones correctivas. La Gestión Cuantitativa de Proyectos implica lo siguiente: •

Establecer y mantener unos objetivos de calidad y ejecución de procesos para el proyecto.

•

Identificar los subprocesos adecuados que componen el proceso definido del proyecto, basado en datos históricos de capacidad y estabilidad obtenidos de líneas base de la ejecución del proceso.

•

Seleccionar los subprocesos del proceso definido del proyecto que van a ser gestionados de forma estadística.

Guía de mejores prácticas de calidad de producto

128

Instituto Nacional de Tecnologías de la Comunicación

•

Realizar seguimiento del proyecto para determinar si se satisfacen los objetivos de calidad y ejecución de los procesos del proyecto e identificar acciones correctivas apropiadas.

•

Seleccionar las medidas y técnicas analíticas a utilizar para gestionar de forma estadística los subprocesos seleccionados.

•

Establecer y mantener una comprensión de la variación de los subprocesos seleccionados utilizando las medidas escogidas y las técnicas analíticas.

•

Realizar seguimiento de la ejecución de los subprocesos seleccionados para determinar si son capaces de satisfacer sus objetivos de calidad y ejecución de procesos e identificar acciones correctivas.

•

Registrar datos de la gestión estadística y de calidad en el repositorio de medición de la organización.

Los objetivos de calidad y ejecución de procesos, medidas y líneas base se desarrollan según describe el área de proceso de OPP (Ejecución de Procesos Organizacionales). La ejecución del proceso es una medida de los resultados reales alcanzados en el proceso. La ejecución del proceso se caracteriza tanto por medidas propias del proceso (p.ej.: esfuerzo, eficiencia en eliminación de defectos) como por medidas del producto (fiabilidad, densidad de defectos, tiempo de respuesta). Los subprocesos son componentes definidos de un proceso definido mayor. Por ejemplo, un proceso típico de desarrollo se puede definir en términos de subprocesos como desarrollo de requisitos, diseño, construcción, pruebas. Los subprocesos pueden descomponerse, a su vez, en otros subprocesos o elementos de proceso. Un elemento esencial de la gestión cuantitativa es tener confianza en las estimaciones. Los subprocesos que serán gestionados estadísticamente son elegidos en base a las necesidades identificadas para una ejecución predecible. Otro elemento esencial de la gestión cuantitativa es entender la naturaleza de la variación experimentada en la ejecución de un proceso, y reconocer cuándo la ejecución real del proyecto puede no ser adecuada para alcanzar los objetivos de un proyecto en cuanto a calidad y ejecución del proceso.

Guía de mejores prácticas de calidad de producto

129

Instituto Nacional de Tecnologías de la Comunicación

Gestión cuantitativa del proyecto

OPP Prediciones de calidad y ejecución del proceso Repositorio medición en  organización Medida capacidad subprocesos

Establecer objetivos del proyecto

Objetivos de calidad y  ejecución del proceso

Componer el proceso definido Subprocesos seleccionados

Acciones correctivas Gestionar ejecución del proyecto

Proceso definido del  proyecto

Seleccionar subprocesos a gestionar de forma estadística

Definiciones de  medidas, objetivos derivados

Gestión estadística de la ejecución de un subproceso Registrar datos de gestión estadística

Seguir ejecución subprocesos seleccionados

Estabilizar sub‐procesos

Aplicar métodos estadísticos para entender variación

Seleccionar medidas y técnicas analíticas

Figura 37 Gestión cuantitativa de proyectos (CMMI®) Área de Ejecución de Procesos Organizacionales El propósito del área de Ejecución de Procesos Organizacionales es establecer y mantener un entendimiento cuantitativo de la ejecución del conjunto de procesos estándar de una organización en función de los objetivos de calidad y ejecución de proceso, y proporcionar datos sobre la ejecución de proceso, líneas base, y modelos para poder gestionar cuantitativamente los proyectos de la organización. Las medidas comunes de la organización se componen de medidas de proceso y de producto que se pueden utilizar para resumir la ejecución real de los procesos en los proyectos individuales de la organización. Los datos organizacionales para estas medidas se analizan para establecer una distribución y rango de resultados, que caracterice la ejecución prevista del proceso cuando se utiliza en un proyecto individual de la organización. La ejecución de proceso prevista se puede utilizar para establecer los objetivos de calidad y ejecución de proceso del proyecto y se pueden usar como línea base contra la que se comparará la ejecución real del proyecto. Esta información se utiliza para gestionar cuantitativamente el proyecto. Cada proyecto gestionado cuantitativamente, por tanto, proporciona resultados reales de ejecución que formarán parte de la línea base para los activos del proceso organizacional. Los modelos de ejecución de proceso se utilizan para representar la ejecución pasada y presente y para predecir resultados futuros del proceso. Por ejemplo, los defectos latentes en el producto entregado se pueden predecir utilizando medidas de los defectos identificados durante las actividades de verificación del producto. Cuando la organización tiene medidas, datos y técnicas analíticas para los procesos críticos y características de producto, puede realizar lo siguiente:

Guía de mejores prácticas de calidad de producto

130

Instituto Nacional de Tecnologías de la Comunicación

•

Determinar si los procesos se comportan de forma consistente o tienen tendencias estables (son predecibles).

•

Identificar procesos donde la ejecución está dentro de los límites y es consistente a lo largo de distintos equipos que lo implementan.

•

Establecer criterios para identificar si un proceso o elemento de proceso debe gestionarse estadísticamente y, en ese caso, determinar las medidas pertinentes y técnicas analíticas que se utilizarán.

•

Identificar procesos que muestran un comportamiento inusual (esporádico o impredecible).

•

Identificar cualquier aspecto del conjunto de procesos estándar de la organización que se pueda mejorar.

•

Identificar cuál es el proceso implementado que mejor se ejecuta.

Establecer líneas base y modelos de la ejecución

Seleccionar procesos

Subprocesos seleccionados de  los proc. estánd. de la org.

Establecer líneas base de la ejecución del proceso

Procesos estándar de la organización

Establecer modelos de la ejecución del proceso

Líneas base de la ejecución de los  procesos de la org. Objetivos de la ejecución de los  procesos de la org.

Modelos de la  ejecución del  proceso

Establecer objetivos de  la ejecución del proceso

Objetivos de  negocio

Medidas del  proceso en  proyecto

QPM Conj.de medidas de la org.

MA

Establecer medidas de calidad y ejecución de proceso

Objetivos de  negocio

QPM

Figura 38 Ejecución de Procesos Organizacionales (CMMI®)

4.3.3.

Definición de métricas basada en metodología SPICE

En el modelo SPICE, la evolución de la capacidad de un proceso se expresa en términos de niveles de capacidad, características comunes y prácticas genéricas. Las prácticas genéricas son aplicables a cualquier proceso. Representan las actividades necesarias para gestionar un proceso y mejorar su capacidad y así alcanzar los resultados deseados.

Guía de mejores prácticas de calidad de producto

131

Instituto Nacional de Tecnologías de la Comunicación

Las prácticas genéricas se agrupan en características comunes y éstas, a su vez, en niveles de capacidad que ayudan a definir la efectividad del proceso para alcanzar su propósito definido. Hay seis niveles de capacidad en el modelo. Cada nivel proporciona una mejora en la capacidad de ejecutar un proceso sobre el nivel anterior. Una característica común es un conjunto de prácticas genéricas orientadas al mismo aspecto de la implementación de un proceso o su institucionalización. Las siguientes prácticas y características del modelo SPICE están relacionadas con la medición: •

Prácticas genéricas de nivel 2: Planificado y Controlado o

Característica común 2.4: Control de la ejecución ƒ

•

Prácticas genéricas de nivel 4: Controlado Cuantitativamente o

Característica común 4.1: Establecer unas metas de calidad medibles ƒ

•

Control con mediciones: controlar el estado del progreso contra el plan usando mediciones. El uso de mediciones implica que éstas han sido definidas y seleccionadas y que los datos han sido recogidos.

Establecer metas de calidad: establecer unas metas de calidad medibles para los productos/entregables generados por los procesos estándar de la organización. Estas metas de calidad deben estar alineadas con las metas estratégicas de calidad de la organización, las necesidades particulares y prioridades del cliente y las necesidades tácticas del proyecto.

Practicas genéricas de nivel 5: Mejora Continua o

Característica común 5.1: Mejorar la capacidad de la organización ƒ

Establecer metas de efectividad de proceso: establecer metas cuantitativas para mejorar la efectividad de los procesos estándar de la organización, basadas en las metas de negocio de la organización y la capacidad actual de los procesos.

Medir el proceso de mejora El papel de las mediciones es crucial en un proceso de mejora software. Las mediciones son necesarias para mostrar cuantitativamente el estado actual de los procesos y las prácticas contra unas mejores prácticas de ingeniería de software, y para mostrar hasta qué punto los procesos de software son efectivos para alcanzar las necesidades y metas de negocio de una organización. Las mejores prácticas proporcionan un modelo general de la industria de software pero no reflejan las características específicas de una organización. Cada organización tiene sus propias necesidades y metas de negocio específicas que influenciarán la selección de las mejores prácticas que utilizarán para la mejora.

Guía de mejores prácticas de calidad de producto

132

Instituto Nacional de Tecnologías de la Comunicación

En la evaluación del proceso de mejora se utilizarán tanto métricas de efectividad del proceso como la puntuación del cumplimiento de las distintas prácticas genéricas y básicas del modelo SPICE. La evaluación contra las prácticas de un modelo evalúa una serie de metas universales, se puede decir que actúa a alto nivel. En la práctica, las necesidades y metas de negocio de una organización pueden imponer metas del proceso y prioridades diferentes, y pueden conducir a la identificación de metas de mejora que no se pueden expresar en términos de un nivel de capacidad para el proceso. Por ello, surge la necesidad de contar con un tipo distinto de medida, la medida de la efectividad de un proceso, orientado a las metas del proceso específicas de la organización. Las medidas de efectividad indican hasta qué punto el proceso cumple las metas que se derivan directamente del análisis de las circunstancias específicas, necesidades y metas de negocio de la organización. Las medidas de la efectividad respaldan la elección de los procesos que se van a mejorar y el seguimiento de los resultados de la mejora. Las medidas de efectividad se definen normalmente en base a las características de la salida del proceso. Por ejemplo, la efectividad del proceso de planificación se puede asociar a su eficiencia, precisión, fiabilidad o capacidad de ser repetido, o una combinación de los anteriores. Como las organizaciones tienen circunstancias y necesidades únicas, la elección de una medida de efectividad diferirá entre las distintas organizaciones. Sin embargo, su valor siempre debe ser medido y comparado con un valor objetivo o un rango como forma de medir la mejora. Marco para procesos de medición La siguiente figura muestra el marco para un proceso de medición, que debe ser aplicado mediante la puntuación del cumplimiento del modelo y las medidas de efectividad e integrándolas para completar el propósito de mejora.

Guía de mejores prácticas de calidad de producto

133

Instituto Nacional de Tecnologías de la Comunicación

Necesidades de la organización

Son analizadas

Metas del proceso software Determinan la selección de

Métricas del proceso software

Se usan para medir

Se usan para validar

Se usan para expresar Es comparado con

Medición actual del proceso software

Valor objetivo del proceso software

Es punto de  referencia para

Resultados del proceso software

Son diseñadas para  alcanzar Empiezan con

Acciones de mejora del proceso software

Producen

Figura 39 Marco para un proceso de medición •

Meta de proceso software: un objetivo del proceso software o de parte de él. Debe ser definida, siempre que sea posible, de forma que una única métrica de proceso sirva para evaluar el grado de cumplimiento de la meta.

•

Métrica de proceso software: una medida cuantitativa del grado de cumplimiento de una meta de proceso software. Las métricas de proceso software incluyen tanto medidas de efectividad como cumplimiento de prácticas o nivel de capacidad del proceso.

•

Valor objetivo del proceso software: el valor deseado de una métrica de proceso software.

•

Acción de mejora de proceso: una acción planificada y ejecutada para mejorar el proceso software o parte de él. Esta acción puede contribuir a la consecución de más de una meta de proceso software.

•

Medida actual del proceso software: el valor de una métrica de proceso anterior a la implementación de una acción de mejora.

•

Resultado de la mejora del proceso software: el valor de la métrica de proceso después de ejecutar la acción de mejora.

Guía de mejores prácticas de calidad de producto

134

Instituto Nacional de Tecnologías de la Comunicación

Cuando se utiliza el marco para medir la puntuación del cumplimiento del modelo: •

La meta del proceso software se corresponde con el propósito del proceso definido en la parte 2 del Estándar.

•

La métrica del proceso software se corresponde con el mecanismo de puntuación definido en la parte 3 del Estándar.

•

Las medidas actuales, objetivos y resultados se expresan en términos de puntuación del nivel de capacidad de un proceso.

Cuando se utiliza el marco para medir la efectividad, la organización debe: •

Analizar sus circunstancias y necesidades para identificar y definir un conjunto de metas cualitativas para su proceso software. Las metas del proceso software deben ser elegidas de forma que tengan el impacto más directo y crítico sobre las necesidades de la organización. Esto es posible cuando las metas generales se descomponen y refinan en procesos individuales y responsabilidades particulares o de equipo. Estas metas pueden ser un proceso concreto del modelo, definido en la parte 2 del Estándar, o varios procesos relacionados o incluso una práctica concreta.

•

Idear una forma apropiada de medir si cada meta de proceso ha sido alcanzada, esto es, definir una métrica de proceso. Puede que sea necesario realizar varias iteraciones entre la definición de metas y métricas hasta que se encuentren métricas satisfactorias que midan el cumplimiento de cada meta cualitativa.

•

Utilizar las métricas de proceso para expresar los objetivos del proceso para cada meta definida. Un objetivo del proceso es un valor numérico cuantificando el grado de cumplimiento de la meta, elegido para cubrir las necesidades de la organización. Su valor puede ser mejor que el valor actual (el objetivo es de mejorar), o igual que el valor actual (el objetivo es mantener en estado estable la mejora), o en algunos casos puede ser peor que el valor actual, debido a que los objetivos anteriores se fijaron de forma incorrecta.

•

Seleccionar acciones de mejora de proceso, que son diseñadas para alcanzar el conjunto completo de objetivos de proceso. En general, muchas acciones pueden afectar a la consecución de un objetivo, y una acción puede afectar a la consecución de varios objetivos.

•

Realizar seguimiento del progreso de las acciones de mejora de proceso comparando los valores actuales de las métricas con los objetivos.

•

Validar los resultados de la mejora de proceso (los valores de las métricas después de haber completado las acciones) comparándolos con los objetivos.

Normalmente, la organización utiliza una combinación de medidas de efectividad y de adecuación al modelo para fijar unos objetivos de mejora. Las medidas de adecuación indicarán las áreas de mejora más prometedoras según la distancia entre las prácticas de la organización y la línea base; por otra parte, las medidas de efectividad de los procesos

Guía de mejores prácticas de calidad de producto

135

Instituto Nacional de Tecnologías de la Comunicación

proporcionarán información sobre la eficacia de los procesos de la organización comparado con las necesidades.

4.3.4.

Otros métodos de definición de métricas 4.3.4.1.

Métricas de Puntos Función

Cuando se trata de establecer métricas de productividad y calidad en la construcción de software, o realizar estimaciones de coste y duración, es imprescindible disponer de una medida fiable y comprensible del tamaño de lo que se construye. Tradicionalmente, se ha medido el tamaño del software mediante el recuento de las líneas de código, número de programas fuente, o técnicas similares, que no resultan aceptables porque: •

Su resultado depende fuertemente del entorno técnico y el lenguaje de programación utilizado.

•

Varía en función de la habilidad de cada programador y del uso de normas y metodologías. No resultan significativas al usuario ni a la dirección.

•

La métrica del punto función fue definida por Allan Albrecht, en 1970, como un método para medir el tamaño del software entregado al usuario que fuera independiente de la tecnología utilizada para la construcción y despliegue del software, y que fuera útil en cualquiera de las fases del ciclo de vida del software, desde el diseño inicial hasta el despliegue y mantenimiento del mismo. Los puntos función son independientes de la tecnología porque miden los sistemas desde una perspectiva funcional. El número de puntos función de un sistema permanecerá constante independientemente del lenguaje de programación, método de desarrollo o plataforma utilizada. La única variable es la cantidad de esfuerzo necesario para entregar un conjunto de puntos función, por tanto, el análisis de puntos función se puede utilizar para comparar si una herramienta, un entorno o un lenguaje es más productivo que otros dentro de una organización o entre distintas organizaciones. Esto supone uno de los valores más importantes del análisis de puntos función. El análisis de puntos función, además, proporciona un mecanismo para realizar un seguimiento y control de cambios de alcance. Se puede comparar el número de puntos función al final de las fases de requisitos, análisis, diseño, codificación y pruebas. También, se puede comparar el número de puntos función al final de la especificación de requisitos y/o diseño con el número de puntos función entregados. Si este número ha crecido indica que ha habido cambios de alcance. El volumen de este crecimiento indicará también lo bien que se han tomado los requisitos y/o se han comunicado al equipo de proyecto. Si el volumen de cambios de alcance disminuye en el tiempo significará que la comunicación con el usuario ha mejorado. La medición de puntos función debe ser planificada como parte del proyecto. De hecho, se debe utilizar una primera medición de los puntos función como base para la estimación.

Guía de mejores prácticas de calidad de producto

136

Instituto Nacional de Tecnologías de la Comunicación

El proceso requiere dos etapas fundamentales: en primer lugar, se identifican las funciones disponibles para el usuario y se organizan en cinco componentes. Después, se clasifica y pondera cada función por su nivel de complejidad y, por último, se ajusta este total de acuerdo a unas características del entorno. En definitiva, los puntos función se han convertido en una métrica estándar ampliamente aceptada para medir el tamaño del software. Conocer el tamaño del software es clave para conocer la productividad y la calidad. Si no se dispone de una métrica fiable relativa al tamaño del software, no se pueden realizar cálculos sobre cambios en productividad relativa (puntos función por mes de trabajo) o cambios en cuanto a calidad relativa (defectos por punto función). Una vez que se pueden calcular estos cambios relacionados con la productividad y la calidad y se pueden comparar en el tiempo, se pueden detectar las fortalezas y debilidades de una organización. Además, las acciones orientadas a corregir las debilidades se pueden medir para comprobar su efectividad. 4.3.4.2.

PSM (Practical Software and Systems Measurement) - ISO 15939

Practical Software Measurement (PSM) es un proyecto impulsado por el Departamento de Defensa y el Ejército norteamericano para desarrollar una guía de medición, basada en la experiencia de un grupo de trabajo que representa al gobierno, la industria y las universidades. PSM define un proceso de medición práctico, orientado a la información, junto con unos conceptos de medición consecuentes. Está basado en la norma ISO/IEC 15939, Software Engineering - Software Measurement Process, que define un proceso de medición para el desarrollo de software e ingeniería de sistemas. PSM tiene dos componentes principales: un modelo de proceso de medición y un modelo de información. El modelo de proceso incluye las actividades y tareas del proceso de medición. El modelo de información describe las relaciones entre los conceptos de medición y la terminología común. El proceso de PSM, descrito en la figura siguiente, proporciona una base para la medición en muchas disciplinas de IT, incluyendo ingeniería de software, ingeniería de sistemas y medición de la mejora de procesos. El mismo proceso de medición básico puede soportar una amplia variedad de necesidades de información diferentes en cada una de estas áreas. La medición es un proceso iterativo: las medidas son refinadas a medida que cambian las necesidades de información y la organización implementa acciones de mejora. El proceso de PSM describe cuatro actividades que son parte de un programa de medición exitoso:

Guía de mejores prácticas de calidad de producto

137

Instituto Nacional de Tecnologías de la Comunicación

Feedback usuarios

Procesos técnicos y de gestión Objetivos y necesidades

Resultados de análisis

Núcleo proceso medición Plan de medición

Establecer y mantener compromisos

Planificar la medición

Ejecutar la medición Nuevas necesidades

Resultados de análisis y medición de rendimiento Acciones de mejora

Evaluar la medición

Figura 40 Programa de medición según PSM •

Planificar la medición: las medidas se definen para cubrir las necesidades de información de los proyectos y de la organización. Esto incluye identificar lo que los responsables de la toma de decisiones necesitan saber, relacionando estas necesidades de información con aquellas entidades que pueden ser medidas, para después seleccionar e identificar posibles medidas basadas en procesos del proyecto y de la organización.

•

Ejecutar la medición: esta actividad implica la recogida de los datos, el análisis de estas mediciones y la presentación de los resultados para que la información se pueda utilizar para tomar decisiones.

•

Evaluar la medición: tanto el proceso de medición como las medidas específicas deben ser evaluadas y mejoradas periódicamente. Normalmente, la primera implementación de un programa de medición no responde a todas las necesidades de información de los gerentes. Con el tiempo, la organización va descubriendo mejores medidas y refina los procesos. A medida que una organización va madurando, cambian las necesidades de información. La medición es un proceso iterativo y debe ser refinado de forma continua para alcanzar el éxito.

•

Establecer y mantener compromisos: esta actividad implica proporcionar los recursos, formación y herramientas para implementar un programa de medición efectivo y asegurar que la dirección se compromete a utilizar la información. La mayor parte de esta actividad ocurre en la fase de planificación de la medición. El compromiso de la organización debe ser reforzado de forma continua.

Guía de mejores prácticas de calidad de producto

138

Instituto Nacional de Tecnologías de la Comunicación

El modelo de medición de PSM enlaza las necesidades de información de los responsables en la toma de decisiones con los atributos del proceso o proceso que se va a medir. Relaciona los distintos conceptos a medir y permite la comunicación adecuada de los resultados dentro de la organización. La siguiente figura muestra cómo los atributos se cuantifican y convierten en indicadores que proporcionan la base para la toma de decisiones. PSM define tres niveles de medidas: •

Medidas básicas: datos a recoger, como puntos función o número de líneas de código.

•

Medidas derivadas: datos calculados, basados en las medidas básicas, como la productividad.

•

Indicadores: gráficos analíticos construidos a partir de los datos recogidos y los derivados junto con los criterios de decisión. Información del producto

Nivel de análisis y flexibilidad

Indicador

Construcción de la medición

Medida derivada

Nivel de recogida de datos y estandarización

Medida básica

Atributo

Combinación de indicadores e interpretaciones

Medidas básicas o derivadas junto con criterios de decisión

Función de dos o más medidas básicas

Cuantificación de un atributo simple

Característica de un proceso o producto

Figura 41 Modelo de información de la medición según PSM 4.3.4.3.

GQM (Goal Question Metrics)

El enfoque GQM (Goal-Question-Metric) proporciona una manera útil para definir mediciones tanto del proceso como de los resultados de un proyecto. Según este método, un programa de medición puede ser más satisfactorio si se diseña orientado a las metas u objetivos que se quieren alcanzar. La diferencia entre metas y objetivos es la siguiente: •

Las metas son generales, abstractas e intangibles. Responden a la pregunta de ¿qué queremos alcanzar?, y la respuesta es cualitativa. P.ej.: Reducir el tiempo de entrega.

•

Los objetivos son precisos, tangibles y concretos. Las metas se descomponen en un conjunto de objetivos bien definidos, con la intención de que alcanzando

Guía de mejores prácticas de calidad de producto

139

Instituto Nacional de Tecnologías de la Comunicación

los objetivos alcanzaremos la meta. Responden a la pregunta de ¿cuánto queremos alcanzar?, y la respuesta es cuantitativa. P.ej.: Reducir el tiempo de entrega en un 20% al final del año. GQM define una meta, refina esta meta en preguntas y define métricas que intentan dar información para responder a estas preguntas. Las preguntas ayudarán a medir si se está alcanzando la meta definida, por lo tanto se considerarán preguntas que sean potencialmente medibles. GQM se puede aplicar a todo el ciclo de vida del producto, procesos y recursos. Este método fue originariamente definido por Basili y Weiss (1984) y extendido posteriormente por Rombach (1990) como resultado de muchos años de experiencia práctica e investigación académica. GQM sigue un proceso de seis pasos donde, los tres primeros tratan de identificar las métricas a partir de las metas del negocio y los tres últimos se basan en la recopilación de los datos de las medidas y su utilización eficaz en la toma de decisiones. Nivel Conceptual Paso 1

Identificar

Establecer las Metas

Objetivos de negocio Identificar

Nivel Cualitativo (Operacional) Paso 2

Acotar

Objetivos de medida

Generación de Preguntas

Respuestas generan

Nivel Cuantitativo Paso 3

Definir

Métricas

Especificación de Medidas Paso 4

Generar

Plan de medición

Preparar Recolección de  datos Paso 5

Recolectar, Validar  y Almacenar los datos Paso 6

Analizar los datos

Objetivos

•Reutilización de datos •Generación informes

Objetivos

•Evaluar objetivos logrados •Lecciones aprendidas

Figura 42 Descripción de los 6 pasos del proceso GQM En la figura anterior se mencionan distintos niveles, que son los que caracterizan al método GQM:

Guía de mejores prácticas de calidad de producto

140

Instituto Nacional de Tecnologías de la Comunicación

•

Nivel Conceptual – Goals: Los objetivos identifican lo que queremos lograr respecto a los productos, procesos o recursos. Objetos de la medición: o

Productos: entregables y documentos que se producen durante el ciclo de vida de un sistema.

o

Procesos: actividades relacionadas con el software y asociadas generalmente al tiempo.

o

Recursos: elementos que los procesos utilizan para producir sus salidas.

•

Nivel Operacional– Questions: Las preguntas nos ayudan a comprender cómo satisfacer el objetivo. Tratan de caracterizar al objeto de la medición con respecto a un aspecto de calidad concreto y tratan de determinar la calidad de dichos objetos desde el punto de vista seleccionado, analizando el grado de cumplimiento de los objetivos específicos. Habrá que tener en cuenta qué atributos tiene el objeto con respecto al objetivo planteado y qué características de los atributos del objeto son importantes con respecto al aspecto de calidad, además de cómo se van a evaluar dichas características.

•

Nivel Cuantitativo – Metrics: Se asocia un conjunto de datos a cada pregunta, con el fin de proporcionar una respuesta de manera cuantitativa. Los datos pueden ser: o

Objetivos: si dependen únicamente del objeto que se está midiendo y no del punto de vista desde el que se captan (por ejemplo, el número de versiones de un documento).

o

Subjetivos: si dependen tanto del objeto que se está midiendo como del punto de vista desde el que se captan (por ejemplo, el nivel de satisfacción del usuario).

Como resultado se seleccionan medidas existentes o se definen nuevas medidas. Para cada meta, puede haber varias preguntas y la misma pregunta se puede ligar a múltiples metas. De la misma forma, para cada pregunta puede haber múltiples métricas y una métrica puede ser aplicable a más de una pregunta.

Guía de mejores prácticas de calidad de producto

141

Instituto Nacional de Tecnologías de la Comunicación

Goal

Mejorar la calidad de los entregables  finales

Questions ¿Cuál es la efectividad del  Aseguramiento de la  Calidad?

¿Cuál es la efectividad de  la eliminación de  defectos?

¿Cuál es la calidad de los  productos en el  desarrollo?

Metrics Nº puertas de calidad   planificadas

Eficiencia de revisiones

Nº puertas de calidad   implementadas

Eficiencia de pruebas Efectividad de la  contención de defectos en  fase

Nº defectos introducidos  Tamaño producto  en cada fase (LOC,Nº páginas) Nº defectos detectados  en cada fase Densidad de defectos  del desarrollo

Figura 43 Ejemplo de preguntas y métricas relacionadas con una meta

4.4.

MÉTRICAS DE CALIDAD DE PRODUCTO HABITUALES

Las métricas del software se pueden clasificar en tres categorías: métricas de producto, métricas de proceso y métricas de proyecto. Las métricas de producto describen las características del producto como tamaño, complejidad, características de diseño, rendimiento y nivel de calidad. Las métricas de proceso se pueden utilizar para mejorar el desarrollo del software y el mantenimiento. Ejemplos de este tipo son la efectividad de la eliminación de defectos durante el desarrollo, el patrón de la llegada de defectos en las pruebas, y el tiempo de respuesta del proceso de corrección. Las métricas de proyecto describen las características del proyecto y su ejecución. Algún ejemplo puede ser el número de desarrolladores de software, la dotación de recursos a lo largo del ciclo de vida del software, el coste, calendario y productividad. Las métricas de calidad del software son un subconjunto de las métricas del software que se enfoca en los aspectos de calidad del producto, proceso y proyecto. En general, las métricas de calidad del software están más asociadas a las métricas de proceso y producto que a las métricas de proyecto. Se pueden dividir, además, en métricas de calidad de producto final y métricas de calidad de producto en desarrollo. Si vemos la calidad desde la perspectiva de todo el ciclo de vida del software, debemos incluir métricas que midan el nivel de calidad del proceso de mantenimiento como otra categoría de las métricas de calidad del software.

Guía de mejores prácticas de calidad de producto

142

Instituto Nacional de Tecnologías de la Comunicación

4.4.1.

Métricas de calidad de producto en desarrollo

Estas métricas no están definidas de manera tan formal como las de producto final y sus usos pueden variar entre los desarrolladores de software. En algunos casos, consiste en registrar la llegada de defectos durante una prueba formal de sistema. En otros casos, organizaciones con un programa de métricas bien definido, contemplarán varios parámetros en cada fase del ciclo de desarrollo. Densidad de defectos durante pruebas de sistema La densidad de defectos durante las pruebas formales de sistema está directamente relacionada con la densidad de defectos en producción. Un alto índice de defectos durante las pruebas es un indicador de que el software ha experimentado una alta inyección de errores durante su proceso de desarrollo, o bien, que se ha hecho un mayor esfuerzo en las pruebas que ha resultado en una detección de defectos más efectiva. La métrica de defectos por KLOC o punto función es un buen indicador de calidad durante las pruebas del software. Resulta útil realizar un seguimiento de versiones consecutivas de un producto. Se pueden utilizar los siguientes escenarios para evaluar la calidad de una versión: •

•

Si el índice de defectos durante las pruebas es el mismo o inferior que el de la versión anterior, entonces revisar: ¿Han empeorado las pruebas de la versión actual? o

Si la respuesta es no, la perspectiva de la calidad es positiva.

o

Si la respuesta es sí, se necesitan realizar pruebas adicionales (p.ej.: añadir casos de prueba para aumentar la cobertura, pruebas de usuario, pruebas de estrés, etc.)

Si el índice de defectos durante las pruebas es sustancialmente mayor que el de la versión anterior, entonces revisar: ¿Se ha planificado y se ha llevado a cabo una mejora de la efectividad de las pruebas? o

Si la respuesta es no, la perspectiva de la calidad es negativa. La única solución en este punto del ciclo de vida es realizar más pruebas, lo que generará un mayor índice de defectos.

o

Si la respuesta es sí, la perspectiva de calidad es la misma o positiva.

Patrón de llegada de defectos durante pruebas de sistema La densidad de defectos durante las pruebas es un indicador resumen mientras que el patrón de llegada de defectos (o tiempo trascurrido entre defectos) nos da más información. En esta métrica, el objetivo es buscar una estabilidad en la llegada de defectos o un distanciamiento en el tiempo trascurrido entre fallos, antes de terminar las pruebas y entregar el software a producción. Estos patrones en los que la llegada de defectos disminuye durante las pruebas son la base de muchos modelos de fiabilidad del software. La

Guía de mejores prácticas de calidad de producto

143

Instituto Nacional de Tecnologías de la Comunicación

unidad de tiempo para observar el patrón de llegada de defectos suele ser semanas o meses. Cuando se habla del patrón de llegada de defectos durante las pruebas, hay tres métricas diferentes que se deben considerar: •

La llegada de defectos durante la fase de pruebas por intervalo de tiempo (p.ej.: semanas). Este es el número total de defectos que han llegado, de los cuales no todos serán válidos.

•

El patrón de llegada de defectos válidos.

•

El patrón de defectos acumulados: todos los problemas registrados no se pueden investigar y corregir inmediatamente. Esta métrica es un indicador para la calidad y para la carga de trabajo. Si hay muchos defectos sin resolver acumulados al final del ciclo de desarrollo y todavía se tienen que integrar muchas correcciones en el sistema, se verá afectada la estabilidad del sistema. Se necesitará una prueba de regresión para asegurar que se alcanzan los niveles deseados de calidad de producto.

Patrón de eliminación de defectos en cada fase Esta métrica es una extensión de la métrica de densidad de defectos durante las pruebas. En este caso, es necesario registrar los defectos en todas las fases del ciclo de desarrollo, incluyendo las revisiones de diseño, inspecciones de código, y verificaciones formales antes de las pruebas. Como un gran porcentaje de los defectos de programación están relacionados con problemas de diseño, realizar revisiones formales o verificaciones funcionales para mejorar la capacidad del proceso de eliminación de defectos, reduce la inyección de errores. El patrón de eliminación de defectos en cada fase refleja la habilidad del proceso de desarrollo para eliminar defectos. En relación a las métricas para las fases de diseño y codificación, muchas organizaciones, además de los índices de defectos, utilizan métricas como cobertura de inspección y esfuerzo de inspección para la gestión de la calidad, estableciendo incluso valores modelo y límites de control para algunos indicadores de calidad en el proceso de desarrollo. Efectividad en la eliminación de defectos La efectividad en la eliminación de defectos (DRE) se puede definir de la siguiente forma: 100% Como el número total de defectos que permanecen en el producto en una determinada fase es desconocido, el denominador de la métrica DRE será un valor aproximado. Normalmente, se estima como: á Esta métrica se puede calcular para todo el proceso de desarrollo o para cada fase. Cuanto más alto sea el valor, más efectivo será el proceso de desarrollo y menos defectos se trasmitirán a las siguientes fases o a producción.

Guía de mejores prácticas de calidad de producto

144

Instituto Nacional de Tecnologías de la Comunicación

4.4.1.1.

Métricas de pruebas de software

Además de las métricas de densidad de defectos y patrón de llegada de defectos durante las pruebas, mencionadas anteriormente, se van a detallar algunas de las métricas claves para gestionar las pruebas del software y el estado de la calidad del proyecto. Una vez que se desarrolla un plan de pruebas, las actividades y planificación que se determinen en él tienen que ser revisados contra lo que realmente se está realizando. Los datos necesarios para realizar el seguimiento del progreso de las pruebas se pueden recoger manualmente (p.ej.: contando los casos de prueba desarrollados cada día) o mediante alguna herramienta de gestión de pruebas. Estos datos de progreso también se utilizan para medir criterios de salida como la cobertura de pruebas (p.ej.: 50% de cobertura de requisitos alcanzada). Algunas métricas de pruebas más comunes son: •

Porcentaje de trabajo realizado en la preparación de los casos de prueba (o porcentaje de casos de prueba planificados que han sido preparados).

•

Porcentaje de trabajo realizado en la preparación del entorno de pruebas.

•

Ejecución de casos de pruebas (p.ej.: número de casos de prueba ejecutados/no ejecutados, y casos de prueba pasados/fallados).

•

Información de defectos (p.ej.: densidad de defectos, defectos encontrados y corregidos, índice de fallos y resultados de repetir las pruebas).

•

Cobertura de pruebas de requisitos, riesgos o código.

•

Fechas de hitos en las pruebas.

•

Costes de las pruebas.

Curva S del progreso de pruebas Esta métrica se utiliza para el seguimiento y control del progreso de las pruebas. El eje X de la curva S representa las unidades de tiempo y el eje Y representa el número de casos de prueba. Para que sea útil, debe contener la siguiente información: •

Progreso planificado en términos de número de casos de prueba completados por semana (o la unidad de tiempo que se considere).

•

Número de casos de prueba que se han abordado por semana.

•

Número de casos de prueba que se han completado por semana.

La siguiente figura sería un ejemplo:

Guía de mejores prácticas de calidad de producto

145

Casos de prueba

Instituto Nacional de Tecnologías de la Comunicación

Comenzados

Semanas Completos ----- Planificados

Figura 44 Curva S del progreso de pruebas El propósito de esta métrica es seguir el progreso de las pruebas y compararlo con el plan para poder tomar acciones en el momento en que haya algún indicador de que las actividades de prueba no se están cumpliendo. Cuando hay riesgos de no cumplir el calendario del proyecto, se suelen sacrificar las pruebas del desarrollo. Al contar con una métrica formal del progreso de las pruebas, es más difícil que se ignore el problema. Además, desde el punto de vista de la planificación del proyecto, la curva S ayuda a realizar una mejor planificación.

4.4.2.

Métricas de calidad de producto final

La calidad de producto se mide normalmente por la densidad de defectos y el tiempo medio de fallo. La primera métrica mide los defectos relativos al tamaño del software (líneas de código, puntos función, etc.) y la segunda mide el tiempo que trascurre entre la detección de fallos. Recoger datos sobre el tiempo trascurrido entre fallos es muy caro. Requiere registrar el tiempo de ocurrencia de cada fallo de software. A veces es bastante difícil registrar el tiempo para todos los fallos observados durante las pruebas. Para que resulte útil, los datos del tiempo entre fallos requieren un alto grado de precisión. Ésta, quizá, es una de las razones por las que esta métrica no es ampliamente utilizada. El índice de defectos de un producto o el número esperado de defectos en un determinado periodo de tiempo es importante para estimar el coste y recursos de la fase de mantenimiento del ciclo de vida del software. Densidad de defectos Aunque pueda parecer sencillo, comparar el índice de defectos de distintos productos software puede implicar varios problemas. Para definir un índice, en primer lugar tenemos que hacer operativos el numerador y el denominador y especificar el periodo de tiempo.

Guía de mejores prácticas de calidad de producto

146

Instituto Nacional de Tecnologías de la Comunicación

El concepto de índice de defectos es el número de defectos sobre las oportunidades de error en un determinado periodo de tiempo. El denominador es el tamaño del software, normalmente expresado en miles de líneas de código (KLOC) o en el número de puntos función. En términos de periodo de tiempo, se utilizan varias definiciones operativas para la vida del producto, que van desde uno a varios años después de que el producto software ha sido lanzado al mercado. Para las aplicaciones software, la mayoría de los defectos se encuentran en los dos años después de su despliegue. La métrica de líneas de código (LOC) tiene un problema y es la ambigüedad de su definición. La diferencia entre las líneas físicas y las instrucciones (o líneas lógicas) y las diferencias entre los distintos lenguajes de programación, contribuyen a que el recuento de líneas de código pueda sufrir grandes variaciones. Incluso utilizando el mismo lenguaje, los métodos y algoritmos utilizados por distintas herramientas de recuento pueden provocar diferencias significativas en el número final de líneas de código. Jones (1986) describe algunas variaciones: •

Contar sólo líneas ejecutables

•

Contar líneas ejecutables y definiciones de datos

•

Contar líneas ejecutables, definiciones de datos y comentarios

•

Contar líneas ejecutables, definiciones de datos, comentarios y lenguaje de control

•

Contar líneas físicas en una pantalla de entrada de datos

•

Contar líneas que terminan con un delimitador lógico

En algunos casos, se realiza una normalización del recuento de LOC con respecto al lenguaje ensamblador, utilizando unos factores de conversión. Cuando se presenten datos sobre calidad donde aparezcan las LOC como medida del tamaño de un producto, se debe describir cuál ha sido el método utilizado para contar las LOC, si está basado en líneas físicas o lógicas. También se deben especificar los factores de conversión de un lenguaje de alto nivel a ensamblador, en caso de que se haya realizado la normalización. Hay que tener precaución a la hora de comparar el índice de defectos de dos productos si las definiciones de recuento de LOC, defectos y periodo de tiempo no son idénticas. Cuando un producto se lanza por primera vez al mercado, y se especifica un determinado método de recuento de LOC, es relativamente fácil calcular su nivel de calidad en función del índice de defectos en un periodo de tiempo. Sin embargo, cuando se realizan mejoras sobre el producto y se generan nuevas versiones del mismo, la situación se complica. Se necesita medir la calidad de todo el producto así como la calidad de la parte nueva del producto (el índice de defectos del código nuevo y de aquel que ha sido modificado). Para poder calcular este índice de defectos, debe estar disponible lo siguiente: •

Recuento de LOC tanto de todo el producto como del código nuevo y modificado en la versión.

•

Clasificación de defectos en función de la versión en que se han producido.

Guía de mejores prácticas de calidad de producto

147

Instituto Nacional de Tecnologías de la Comunicación

El índice de defectos del producto completo mejorará de una versión a la siguiente, sin embargo, el índice de defectos del código nuevo o modificado no mejorará a no ser que haya una mejora en el proceso de desarrollo. Otra forma de medir el tamaño del software son los puntos función. Tanto las LOC como los puntos función son indicadores de las oportunidades de error en las métricas de densidad de defectos. En los últimos años, los puntos función han ganado aceptación en el desarrollo de aplicaciones tanto en términos de productividad (p.ej.: puntos función por persona-año) como en términos de calidad (p.ej.: defectos por punto función). Una buena práctica en la calidad de software necesita considerar la perspectiva del cliente. Desde el punto de vista del cliente, el índice de defectos no es tan relevante como el número total de defectos que pueden afectar a su negocio. Por tanto, un buen objetivo para el índice de defectos debería conducir a una reducción del número total de defectos de una versión a la siguiente, independientemente del tamaño. Si una nueva versión es mayor que las anteriores, significa que el objetivo del índice de defectos del código nuevo y modificado tiene que ser mejor que el de las versiones anteriores para reducir el número total de defectos. Problemas del cliente Otra métrica de calidad utilizada con frecuencia es la que mide los problemas encontrados por el cliente al utilizar el producto. En la métrica de índice de defectos, el numerador es el número de defectos. Sin embargo, desde el punto de vista del usuario, todos los problemas que encuentre al utilizar el software, no solamente los defectos, son problemas con el software. Estos problemas que no son defectos pueden ser problemas de usabilidad, documentación o información que no está clara, o incluso errores de los usuarios. La métrica de problemas del cliente se expresa normalmente en términos de problemas por usuario al mes (PUM): º donde, º

º

º

PUM normalmente se calcula cada mes después de haber lanzado el producto. En este caso, el denominador es el número de meses de licencia en lugar de KLOC o puntos función, y el numerador es todos los problemas encontrados por el cliente. Fundamentalmente, esta métrica está relacionada con los problemas de usabilidad. Algunas acciones para reducir el valor de esta métrica serían: •

Mejorar el proceso de desarrollo y reducir los defectos del producto

•

Reducir los problemas no considerados como defectos, mejorando todos los aspectos del producto (como usabilidad, documentación), la educación al cliente y el soporte.

•

Aumentar la venta (número de licencias instaladas) del producto.

Guía de mejores prácticas de calidad de producto

148

Instituto Nacional de Tecnologías de la Comunicación

Todas estas acciones encajan en la mejora de la calidad y los objetivos de negocio de cualquier organización. Por eso, esta es una buena métrica a tener en cuenta. En la siguiente tabla, se resumen los principales puntos de las métricas de índice de defectos y problemas del cliente. Índice de defectos

PUM

Numerador

Defectos del producto

Todos los problemas detectados por cliente (defectos y no defectos)

Denominador

Tamaño producto (KLOC, PF)

Uso del producto por el cliente (usuarios al mes)

Perspectiva de medición

Organización de desarrollo de software

Cliente

Ámbito

Calidad de producto

Calidad de producto + otros factores

Tabla 19 Comparativa entre índice de defectos y problemas del cliente(PUM) Las dos métricas representan dos perspectivas diferentes de la calidad de producto. La métrica de problemas del cliente se puede considerar una medida intermedia entre la medición de defectos y la satisfacción del cliente. Para reducir los problemas del cliente, se tienen que reducir los defectos funcionales en el producto y, además, mejorar otros factores (usabilidad, documentación, etc.). Para mejorar la satisfacción del cliente, se tienen que reducir los defectos y otro tipo de problemas y, además, gestionar otros factores de mayor alcance como disponibilidad del producto, imagen de la compañía, servicios, otras soluciones orientadas al cliente, etc. Desde el punto de vista de la calidad del software, la relación entre el ámbito de las tres métricas mencionadas se puede representar mediante el siguiente diagrama de Venn.

Guía de mejores prácticas de calidad de producto

149

Instituto Nacional de Tecnologías de la Comunicación

Defectos

Problemas del cliente

Satisfacción del cliente

Figura 45 Perspectivas de la calidad del producto Satisfacción del cliente Lo que diferencia la gestión de calidad total del enfoque tradicional de calidad de producto es que la gestión de calidad total está orientada al éxito del negocio a largo plazo, relacionando la calidad con la satisfacción del cliente. Los estudios demuestran que es cinco veces más costoso conseguir un nuevo cliente que mantener uno existente, y que los clientes insatisfechos son más propensos a contar sus experiencias que los que están satisfechos. La satisfacción del cliente, normalmente, se mide mediante encuestas realizadas al cliente, que puntúa en una escala de cinco puntos: muy satisfecho, satisfecho, neutral, insatisfecho, muy insatisfecho. Algunos de los parámetros que se evalúan en las encuestas de satisfacción del cliente son: capacidad, funcionalidad, usabilidad, rendimiento, fiabilidad, mantenibilidad, documentación/información y servicio. En base a la escala de cinco puntos mencionada, se pueden extraer porcentajes sobre los distintos grados de satisfacción o insatisfacción del cliente. Los métodos más comunes para realizar estas encuestas son: entrevistas personales, entrevistas telefónicas y cuestionarios por correo. Cada uno de ellos tiene sus ventajas e inconvenientes. Si nos fijamos en el coste, lógicamente las entrevistas personales serán las más costosas y el correo lo menos costoso. Sin embargo, si queremos un alto grado de validez de los datos recogidos, las entrevistas personales proporcionan mayor valor, siempre y cuando el entrevistador esté debidamente formado. Los cuestionarios por correo tienen el índice de respuesta más bajo. Independientemente del método utilizado, resulta muy costoso realizar encuestas a todos los usuarios. Es más eficiente estimar el nivel de satisfacción de toda la población de usuarios a través de una muestra representativa. Para obtener muestras representativas de

Guía de mejores prácticas de calidad de producto

150

Instituto Nacional de Tecnologías de la Comunicación

la población, hay cuatro tipos de métodos de muestreo: muestreo aleatorio simple, muestreo sistemático, muestreo estratificado y muestreo agrupado. Cuanto más grande sea la muestra, mayor será el nivel de confianza y menor será la probabilidad de error. Un error frecuente es creer que el tamaño de la muestra tiene que ser un determinado porcentaje de la población para que se considere representativa. Para que la muestra sea representativa, tiene que tener haber sido escogida de forma científica. En caso contrario, no se puede garantizar que sea representativa por muy grande que sea. Cuando se analicen y presenten los datos de las encuestas de satisfacción del cliente, se debe incluir el intervalo de confianza y el margen de error. Un buen análisis es fundamental para transformar los datos en información útil y conocimiento. En las encuestas de satisfacción, se pregunta acerca de la satisfacción con respecto a atributos de calidad específicos del producto, así como acerca de la satisfacción global. El resultado de estas encuestas proporcionará unas fortalezas y áreas de mejora del producto software. A la hora de establecer una prioridad para la mejora, el enfoque no debe estar en aquellos atributos con un nivel más bajo de satisfacción sino en el contexto amplio de satisfacción global con el producto. Se debe establecer una correlación entre los niveles de satisfacción de los atributos específicos y la satisfacción en conjunto con el producto. Las acciones de mejora deben ir encaminadas a maximizar la satisfacción global. Más allá de la satisfacción del cliente con un producto, se debe analizar la satisfacción con la compañía. La visión del cliente al nivel de la compañía a menudo sugiere acciones de mejora en áreas más allá de la mejora del producto, como marketing, proceso de compras, entrega, soporte, etc. Se debe buscar la satisfacción global para mantener la fidelidad de los clientes y poder ampliar cuotas de mercado. ¿Qué porcentaje de satisfacción del cliente se puede considerar suficientemente bueno? Por supuesto, el objetivo a largo plazo sería el 100%, la satisfacción total del cliente. Sin embargo, desde el punto de vista del negocio se pueden plantear algunas preguntas como: ¿Debe mi compañía invertir 1M€ para mejorar la satisfacción del 85% al 90%?, o ¿Hasta qué punto interesa realizar una inversión para mejorar la satisfacción del cliente, que es del 95%? La respuesta a este tipo de preguntas viene dada por la relación entre la satisfacción del cliente y la cuota de mercado. Un cliente satisfecho continuará comprando productos de la misma compañía mientras que uno insatisfecho buscará productos en otras compañías. Por tanto, siempre que existe competencia en el mercado la satisfacción del cliente es clave para la fidelidad de los clientes. Incluso si una compañía no tiene competencia directa, los clientes pueden comprar productos sustitutivos si están insatisfechos con los productos que ofrece la compañía y además, esta insatisfacción del cliente puede provocar la aparición de competencia en el mercado. Por tanto, la conclusión acerca de qué porcentaje de satisfacción del cliente se puede considerar suficientemente bueno es que depende del nivel de satisfacción que tenga la competencia. Para alcanzar mayor cuota de mercado, hay que tener un mayor nivel de satisfacción del cliente que los competidores.

Guía de mejores prácticas de calidad de producto

151

Instituto Nacional de Tecnologías de la Comunicación

4.4.3.

Métricas de mantenimiento de software

Cuando finaliza el desarrollo de un producto software y se lanza al mercado, comienza la fase de mantenimiento dentro del ciclo de vida del producto. Durante esta fase, las métricas que se suelen recoger son la llegada de defectos por intervalo de tiempo y las incidencias del cliente (que pueden ser defectos o no) por intervalo de tiempo. Sin embargo, el número de defectos o problemas que llegan viene determinado por el proceso de desarrollo antes de la fase de mantenimiento. Ya no se puede hacer mucho para alterar la calidad del producto en esta fase. Por tanto, estas dos métricas, aunque son importantes, no reflejan la calidad del mantenimiento del software. Lo que se debe hacer en esta fase de mantenimiento es corregir los defectos lo antes posible y hacerlo con buena calidad. Estas acciones, aunque no pueden mejorar el índice de defectos de un producto, pueden mejorar en gran medida la satisfacción del cliente. En este sentido, las siguientes métricas son muy importantes: El trabajo acumulado en las correcciones y el índice de gestión de este trabajo acumulado El trabajo acumulado en las correcciones está relacionado tanto con el índice de llegada de defectos como con el ritmo al que estos defectos se van corrigiendo. Consiste en un recuento de los problemas reportados que permanecen al final de cada mes o cada semana. Esta métrica, presentada en el formato de un gráfico de tendencias, puede proporcionar información significativa para gestionar el proceso de mantenimiento. Otra métrica para gestionar el trabajo acumulado de los problemas abiertos o sin resolver es el índice de gestión de trabajo acumulado (BMI). º º

100%

En esta métrica, el objetivo siempre será obtener un valor mayor que 100, lo que indicará que el trabajo acumulado en la corrección de defectos es reducido. Una variedad de este índice puede ser la proporción del número de problemas abiertos respecto del número de problemas registrados durante el mes. Si el índice es 1, significa que el equipo mantiene un ritmo de corrección igual al de llegada de problemas. Si el índice es inferior a 1, significa que el equipo soluciona los problemas más rápido que el índice de llegada de problemas. Si es mayor que 1, esto significa que el equipo está perdiendo capacidad en la corrección de problemas. Por tanto, este índice también es un indicador de la respuesta a los problemas. Tiempo de respuesta en las correcciones En muchas organizaciones de desarrollo de software, se establecen guías sobre el tiempo límite en el que las correcciones de los defectos registrados deben estar disponibles. Normalmente, se establece un criterio según la severidad de los problemas. Para las situaciones críticas en las que el negocio del cliente está en riesgo debido a los defectos del producto software, los desarrolladores o equipo de soporte trabajan a contrarreloj para resolver los problemas. Para los defectos menos severos, el tiempo de respuesta requerido es más relajado. La métrica de tiempo de respuesta en las correcciones se calcula para

Guía de mejores prácticas de calidad de producto

152

Instituto Nacional de Tecnologías de la Comunicación

todos los problemas, según su nivel de severidad, como el tiempo medio desde que se registra un problema hasta que se cierra. En general, un tiempo corto de respuesta en las correcciones deriva en la satisfacción del cliente. Lo importante son las expectativas del cliente, el tiempo de corrección que se haya acordado y la habilidad de cumplir los compromisos que se hayan alcanzado con el cliente sobre este tema. Porcentaje de correcciones atrasadas Una corrección se clasifica como atrasada si el tiempo empleado en ella supera el tiempo de respuesta requerido. %

º

ú º

100%

Calidad de las correcciones La calidad de las correcciones o el número de correcciones defectuosas es otra métrica importante de calidad para la fase de mantenimiento. Desde la perspectiva del cliente, es malo encontrar defectos funcionales en el software pero es peor aún si las correcciones de estos defectos no solucionan el problema registrado, o lo solucionan pero introducen un nuevo defecto. La métrica del porcentaje de correcciones defectuosas es simplemente el porcentaje de todas las correcciones en un intervalo de tiempo que son defectuosas.

Guía de mejores prácticas de calidad de producto

153

Instituto Nacional de Tecnologías de la Comunicación

5.

PUBLICACIÓN Y DIFUSIÓN ¿Cómo define y mide una organización el progreso hacia sus metas? ¿Toda la organización está centrada en conseguir los objetivos establecidos en la misma? ¿Qué subconjunto de datos de la empresa ofrece la información más estratégica para mejorar la empresa?

5.1.

INTRODUCCIÓN

Toda organización desear prosperar y alcanzar el éxito dentro de su área profesional. Para ello, debe establecer una serie de metas u objetivos de negocio a alcanzar, es decir, definir claramente qué es lo que la empresa debe conseguir para mejorar y garantizar que los procesos organizativos conducen a la empresa hacia el éxito buscado. Una vez que han analizado su misión, identificado a los agentes implicados y definido sus metas, necesitan una forma de medir el progreso hacia dichas metas. Una de las claves para la gestión efectiva es monitorizar regularmente los factores críticos que determinan el éxito del negocio. Para ello, las empresas necesitan una serie de medidas clave que les permitan saber cómo se está desarrollando el negocio. La forma en la que muchas empresas hacen esto es mediante los Key Performance Indicators (KPIs). El mayor valor de los KPIs es la posibilidad de ayudar a crear una cultura de mejora continua y de trabajo en equipo dentro de la compañía. Los KPIs proporcionan una oportunidad para mantener a todos los implicados (dirección, empleados, proveedores) centrados en lo que se necesita hacer para mejorar el rendimiento y mantener el negocio. A lo largo de este capítulo se definirá de manera formal el concepto de KPI y se expondrán sus características generales. Además, se pondrá especial atención a la forma de desarrollarlos y aplicarlos en los proyectos dentro de las organizaciones. Existen herramientas que permiten monitorizar, controlar y gestionar los procesos de una organización a través de indicadores de rendimiento alineados con los objetivos estratégicos, los cuadros de mando. En este capítulo se abarcarán también dichas herramientas y se detallarán algunos de los tipos de uso más extendido como son los dashboards y los scorecards. Además de las herramientas existe un plan estratégico y sistema de gestión que permite alinear las actividades de negocio a la visión y estrategia de la organización, mejorando las comunicaciones internas y externas, y monitorizando el rendimiento de la organización contra metas estratégicas. Esta estrategia, llamada Balanced Scorecard, permite a los ejecutivos llevar a cabo fielmente sus estrategias. Por último, este capítulo trata de relacionar la gestión de los KPIs y el Balanced Scorecard con algún modelo de calidad.

Guía de mejores prácticas de calidad de producto

154

Instituto Nacional de Tecnologías de la Comunicación

5.2. 5.2.1.

KPI (KEY PERFORMANCE INDICATOR) MEDICIÓN DEL RENDIMIENTO

–

ELEMENTO

DE

Introducción: Qué son. Características generales.

La clave para tener éxito en un negocio depende de una buena información de gestión. Además de controlar la rentabilidad y los flujos de caja, un negocio también necesita mantener sus Indicadores Clave de Rendimiento (KPI) bajo riguroso control. Los KPI son medidas cuantificables que reflejan los factores críticos de éxito de una organización. Se usan para medir el progreso hacia la consecución de los objetivos del negocio. Están basados en medidas acordadas de antemano y revelan una imagen de alto nivel de la organización. Evalúan los datos de negocio contra los objetivos del mismo y muestran el estado actual usando indicadores gráficos fáciles de entender. Estos indicadores varían dependiendo de la clase de organización que caracterizan; por ejemplo un negocio deberá tener un KPI del volumen de ventas anuales, mientras que los KPIs de una organización de servicios sociales tendrían que ir orientados a cuantificar el número de gente a la que han ayudado. Los colegios deberán tener, como uno de sus KPIs, el número de estudiantes graduados cada año. Sin KPIs previamente definidos, los empleados y directores de los negocios tendrían que extraer laboriosamente la información de rendimiento y evaluar los datos contra los objetivos, y emplear mucho tiempo para presentar la información en un informe dirigido a las personas que se encargan de la toma de decisiones en el negocio. Es difícil conseguir un estado óptimo sin una forma rápida y automática de evaluar la información disponible. Además, los KPIs permiten detectar cualquier desviación con respecto a los objetivos, de modo que puedan tomarse acciones correctivas lo antes posible, evitando así futuros problemas y costes. Antes de seleccionar cualquier KPI, es vital identificar cual es la meta de la organización, ya que los KPIs actúan como medidas de progreso hacia esas metas. Cualquiera que sean, deben ser críticas respecto al éxito de la organización. Una compañía debe establecer sus objetivos estratégicos y operacionales y una vez estén definidos se deberán elegir los KPIs que mejor reflejen estos objetivos. Por ejemplo, si el objetivo de una compañía de software es tener el mayor crecimiento en su industria, su principal factor de rendimiento podría ser la medida de crecimiento de ingresos año a año.

Guía de mejores prácticas de calidad de producto

155

Instituto Nacional de Tecnologías de la Comunicación

Organización

Establecer objetivos estratégicos Establecer objetivos operacionales Definir KPIs: qué medidas/conceptos concretas reflejan los objetivos establecidos. Consiguiendo qué se lograrán los objetivos que se han marcado

Medidas y datos reales KPIs – actualizar datos

Estado real organización

Figura 46 Desarrollo de KPIs La utilización de KPIs proporciona a los ejecutivos de negocio una vista en tiempo real y a un alto nivel del progreso de la compañía. Pueden consistir en una combinación de informes, hojas de cálculo y gráficos. A la hora de elegir un KPI hay que tener en cuenta que debe haber una forma de definirlo y medirlo de forma exacta. Un KPI debe cumplir con el criterio de reflejar la meta de la organización, la cual podría referirse, por ejemplo, a ser la compañía más popular. Sin embargo, la popularidad de la compañía no puede ser medida o comparada con otras, por lo que no podría ser elegida como un KPI. Cualquiera que sea la forma de seleccionar los KPIs, deben reflejar los objetivos de la organización, deben ser valores clave para el éxito, y deben ser cuantificables (medibles). Las consideraciones respecto a cómo se mide un KPI deben establecerse por adelantado. Las definiciones exactas de cómo debe ser calculado un KPI o de cómo debe ser medido deberían especificarse también. Además, es imprescindible que la organización mantenga estas definiciones cada año para permitir comparaciones anuales. Los KPIs suelen ser factores a largo plazo. La definición de qué son y cómo se miden no cambia con frecuencia. Los objetivos de un KPI particular pueden cambiar si los objetivos de la organización cambian. Una vez que se hayan definido los KPIs y se haya determinado un modo de medirlos, hay que distinguir un objetivo claro que sea entendido por todos. El objetivo deberá también ser específico, de tal manera que cada individuo pueda tomar acciones para llevarlo a cabo. Es necesario decir que para conseguir un nivel de objetivo particular de KPI para una compañía, cada departamento tiene que trabajar en sinergia hacia él. Para este propósito, todas las unidades de una organización necesitan definir sus respectivos KPIs que trabajarán hacia la consecución global de los KPIs de la organización.

Guía de mejores prácticas de calidad de producto

156

Instituto Nacional de Tecnologías de la Comunicación

Toda la organización debe trabajar conjuntamente hacia la consecución de los KPIs definidos. Es un trabajo global a nivel de todos los departamentos. Es importante que después de que se hayan identificado los KPIs y sus componentes relativos, se usen como herramientas de gestión de rendimiento. Han de definirse las mejores maneras de representar la varianza (de los niveles de objetivo), teniendo la seguridad de que todo el mundo en la organización está centrado en conseguir los niveles de objetivo de los KPIs.

5.2.2.

Definir KPI en proyectos

Los KPIs deberían preferiblemente cumplir los siguientes criterios esenciales: -

Ser directos (no cálculos complejos)

-

Ser objetivos

-

Ser adecuados

-

Ser cuantitativos

-

Ser prácticos

-

Ser fiables

El mejor momento para desarrollar los KPIs es en una reunión de arranque durante la fase de planificación de un proyecto. Incluye los siguientes pasos: -

Considerar detenidamente los resultados deseados.

-

Evitar declaraciones de resultados demasiado extensas.

-

Desarrollar muchos indicadores posibles durante una sesión corta de brain storming.

-

Seleccionar los mejores indicadores de rendimiento.

A la hora de seleccionar los mejores indicadores de rendimiento hay que tener en cuenta que debe elegirse un número adecuado de ellos de forma que se pueda mantener la atención centrada en ellos. Deben definirse indicadores dentro de las unidades de la compañía que apoyen el conjunto de los objetivos globales de la compañía. Puede ser un proceso iterativo: si los indicadores resultantes no parecen buenos, hacer una nueva sesión de brain storming. Posibles pasos para desarrollar KPIs: A continuación se muestra una visión general de los pasos elementales incluidos en la creación e implementación de un conjunto básico de KPIs para una compañía: Primer paso: comunicar la implantación y el objetivo de los KPIs dentro de la organización. Uno de los desafíos más grandes a los que se enfrentan las compañías a la hora de desarrollar los KPIs es vencer los miedos e incertidumbres de los miembros del equipo. La mayoría de los empleados mantiene una desconfianza en la incursión en la mejora del

Guía de mejores prácticas de calidad de producto

157

Instituto Nacional de Tecnologías de la Comunicación

rendimiento (p.ej. ¿Por qué se hace esto?, ¿Se usará la información en mi contra?). La mejor forma de eliminar estos miedos es explicar los fundamentos de los KPIs desde el principio e incluir a todo el mundo en el proceso. Cuando esto se hace de una forma clara y abierta, entonces todos los empleados deberían al menos creer que “se necesita empezar a hacer las cosas de forma diferente” y una parte de ellos deberían tener claro qué implican los KPIs y cómo han de usarse. Los KPIs que no son aceptados por el equipo de trabajo ó no se sienten como propios, no tendrán éxito. Primero hay que trabajar en crear el entorno interno adecuado y conseguir el apoyo de los agentes clave (empleados, managers, clientes, etc.). Ellos son los últimos conductores del éxito del proyecto. Segundo paso: identificar los factores de éxito críticos para la compañía. Los factores de éxito comprenden las áreas clave cuyo buen funcionamiento determinará que la empresa consiga competitividad y éxito. A veces estos factores se mencionan en los documentos de negocio de la compañía o en el plan estratégico. Otras veces no están escritos pero los implicados tienen una noción de cuáles son. En general, los factores de éxito críticos provienen de una de las cuatro áreas que determinan el éxito de una organización: clientes, rendimiento financiero, la gente y la innovación. Tercer paso: seleccionar y definir los KPIs. Una vez que los factores de éxito críticos se han identificado, el siguiente paso es empezar a definir y seleccionar los KPIs que mejor reflejen su evolución. Si los factores de éxito críticos están definidos de forma clara, entonces el proceso para generar ideas de posibles KPIs es bastante sencillo. Los empleados clave están involucrados de forma activa en este proceso y el trabajo se hace normalmente en equipos. De hecho, los mayores avances en la selección de KPIs no suelen venir de dirección sino de grupos locales. El papel principal de la dirección es proporcionar liderazgo y conducir el desarrollo de los KPIs, proporcionando el soporte y la asistencia para implementarlos. Consejos: 1. Centrarse en el sentido práctico, no en la perfección. Animar a los equipos a perseguir los KPIs que proporcionan información de valor pero no requieren recursos no ordinarios para recolectarlos. 2. Buscar indicadores que reflejen cosas que ya han pasado (p.ej. ventas) e indicadores que son útiles en predecir resultados futuros (p.ej. calidad del producto, satisfacción del cliente). Estos últimos indicadores dan a la dirección y los empleados la oportunidad de actuar rápidamente cuando no se están consiguiendo los objetivos, y por lo tanto, impactar en el rendimiento general de la organización. 3. Trabajar con un número limitado y manejable de KPIs. La mayoría de las compañías necesitan sólo unas pocas métricas. Demasiados KPIs dificultan el poder centrarse en ellos.

Guía de mejores prácticas de calidad de producto

158

Instituto Nacional de Tecnologías de la Comunicación

4. Hay que ser persistente. Prácticamente no hay un equipo que consiga un conjunto perfecto de KPIs en el primer o segundo intento. Hay que seguir experimentando para tener éxito. Cuarto paso: implementar los KPIs. Una vez que los KPIs se han definido y la gente dentro de la organización está involucrada en el proceso, el siguiente paso es implementar un sistema que regularmente haga un seguimiento de estos KPIs y reporte la información a individuos clave (p.ej. el dueño del negocio). En muchos casos, la implementación de un KPI implica dos personas: a un empleado del departamento donde se está midiendo la actividad (p.ej. ventas, servicio al cliente…), a quien se le dará la responsabilidad de reunir los datos, y el manager del departamento, quien tendrá la responsabilidad de conseguir el objetivo e informar de los resultados. Algunos tipos de datos (p.ej. datos operacionales) pueden ser recolectados semanal o mensualmente del sistema de la compañía. Otros tipos de datos (p.ej. información sobre la satisfacción del cliente con la organización) sólo pueden ser recogidos anualmente a través de una encuesta. Algunos otros métodos de recolección de datos incluyen listas de comprobación (p.ej. para analizar los resultados en un periodo de tiempo), inspecciones visuales (p.ej. para calidad)… Quinto paso: monitorizar resultados y hacer mejoras. En muchos aspectos, el quinto paso es el más obvio y el más fácil de completar. Lo importante es monitorizar los KPIs regularmente y compararlos a rendimientos pasados y objetivos establecidos. Si no se han conseguido los resultados deseados, la dirección ha de discutir las acciones a tomar. Acciones potenciales pueden incluir: mirar de forma detallada el área del problema, revisar objetivos, hacer correcciones operacionales, o cambiar la estrategia de la compañía.

5.3.

CUADROS DE MANDO – PUBLICACIÓN DE KPIS

Los cuadros de mando son herramientas de gestión del rendimiento que presentan al usuario una visualización de los indicadores empresariales. Permiten monitorizar, controlar y gestionar los procesos de una organización a través de códigos semafóricos que establecen alertas con las que disponer de una visión completa del rendimiento de la compañía. Permiten comprobar, por ejemplo, si la actividad diaria está alineada con la estrategia corporativa o interpretar lo que está ocurriendo y saber si debemos tomar medidas de mejora. Algunos de los beneficios que proporcionan los cuadros de mandos incluyen: -

Presentación visual de medidas de rendimiento.

-

Eliminación de entrada de datos duplicados.

-

Capacidad de identificación y corrección de tendencias negativas.

-

Medidas de eficacia/ineficacia.

-

Capacidad de generación informes detallados para mostrar nuevas tendencias.

Guía de mejores prácticas de calidad de producto

159

Instituto Nacional de Tecnologías de la Comunicación

-

Incremento de ingresos globales.

-

Alineación de estrategias y metas organizacionales.

Clasificación Cuadros de Mando En función de su contenido: •

Dashboards: se conocen así los cuadros de mando que muestran información sin compararla con objetivos propuestos. Es decir, con ellos únicamente se pueden visualizar los KPI (Key Performance Indicator). La percepción común de la industria es que un dashboard es en tiempo real, como un cuadro de mandos de un automóvil, que permite al conductor comprobar la velocidad actual, el nivel de gasolina, la temperatura del motor, todo de un vistazo. Un dashboard está unido directamente a los sistemas que capturan eventos en el momento que suceden y avisa a los usuarios de alertas o notificaciones de excepciones cuando el rendimiento se desvía de alguna de las métricas establecidas.

•

Scorecards: Son cuadros de mando que muestran información estratégica y están orientados a mostrar objetivos, por lo tanto, además de ofrecer los indicadores KPI, permiten almacenar en el sistema los KGI (Key Goal Indicador). La percepción común de la industria sobre un scorecard es que muestra imágenes periódicas del rendimiento asociado a los objetivos y planes de la organización. Los scorecards miden la actividad del negocio contra los objetivos predefinidos para ver si el rendimiento está dentro de los rangos aceptables. La selección de los KPIs ayuda a los ejecutivos a comunicar la estrategia y centrar a los usuarios en las tareas de mayor prioridad.

Mientras que un dashboard informa a los usuarios qué están haciendo, un scorecard les dice cómo de bien lo están haciendo. En otras palabras, un dashboard mide rendimiento mientras que un scorecard traza progreso. En conclusión, un dashboard es un sistema de monitorización del rendimiento mientras que un scorecard es un sistema de gestión del rendimiento.

Guía de mejores prácticas de calidad de producto

160

Instituto Nacional de Tecnologías de la Comunicación

Dashboard

Scorecard

Propósito

Muestra el rendimiento

Muestra el progreso

Uso

Monitorización del rendimiento

Gestión del rendimiento

Actualizaciones

Alimentación en tiempo real

Imágenes mensuales

Datos

Eventos

Resúmenes

Medidas

Métricas

KPI

Contexto

Excepciones, alertas

Objetivos, umbrales

Fuente

Unido a los sistemas

Unido a los planes

Tabla 20 Comparativa entre dashboard y scorecard

5.3.1.

Mejores prácticas para construir cuadros de mando

Las mejores prácticas son un conjunto de recomendaciones que ayuden a construir un cuadro de mandos más útil, eficiente y estéticamente satisfactorio. Estas prácticas comprenden todas las etapas de desarrollo del cuadro de mandos, desde su diseño a su implantación. Estas mejores prácticas incluyen las siguientes recomendaciones: 1. Identificar el usuario final La primera práctica y la más importante a la hora de construir un cuadro de mandos es identificar quien es el usuario a quien va dirigido. Un cuadro de mandos que esté dirigido a un ejecutivo de una compañía y uno dirigido a un director de marketing será muy diferente. Durante todo el proceso de desarrollo hay que tener en cuenta al usuario final, ya que la aplicación deberá hacerse a la medida de ese usuario. Este proceso de ‘hacer a medida’ puede incluir cosas muy simples como la colocación de controles o las fuentes de datos, pero también puede incluir cosas más complicadas como el flujo del cuadro de mandos entero, o la vista de datos seguros a través de una conexión segura. Lo importante es que presente la información que interesa y sea útil al usuario final. 2. Utilizar la representación gráfica adecuada Un requisito difícil a la hora de construir un cuadro de mandos es decidir qué tipo de visualización de datos usar para diferentes tipos de los mismos. Los datos se pueden presentar de las siguientes formas: -

Mapas -- Para datos geográficos (Compras por provincia)

-

Gráficos -- Datos en el tiempo, datos proporcionales, comparación de datos lineales.

-

Indicadores -- Datos instantáneos, valores simples (KPIs).

Guía de mejores prácticas de calidad de producto

161

Instituto Nacional de Tecnologías de la Comunicación

-

OLAP (Procesamiento analítico en línea) -- Datos multidimensionales

-

Diagramas -- Otros datos

A partir de esta lista, debería ser fácil desglosar cualquier dato en uno de los grupos y mostrarlo con la apropiada representación gráfica. También cabe la posibilidad de hacer un cuadro de mandos dinámico, de tal forma que el usuario sea libre de cambiar la visualización de los datos según las necesidades. Esto es una buena opción, ya que puede existir una perspectiva que el usuario desee y que no haya sido establecida durante el desarrollo. 3. Identificar los KPIs correctamente Un KPI es una medida cuantificable que refleja los factores que contribuyen al éxito dentro de una compañía. Normalmente, ciertas personas dentro de la compañía o una consultora externa acuerdan estas medidas de antemano, pero hay ocasiones en las que estas medidas las define el desarrollador del cuadro de mandos. Es imprescindible que los KPIs se elijan correctamente, ya que si no es así pueden ofrecer información incorrecta que induzca a malas decisiones. Hay que dedicar tiempo a investigar cuales son los indicadores de éxito de una organización o grupo para hacer un cuadro de mandos. 4. Dar un contexto a la información presentada El contexto es una cuestión que está olvidada en muchos cuadros de mando. Esto es incomprensible, ya que sin contexto, muchos cuadros de mandos no son útiles. Consideremos la siguiente figura: Ventas por mes en miles

Ventas al mes por empleado 80 60 40 20 0 Mario

Luis

Ana

Pedro Laura

Figura 47 Ejemplo datos sin contexto Después de echar un vistazo rápido a la figura anterior, se podría hacer la siguiente afirmación: Pedro está haciendo muy buenas ventas y los demás no. Sin embargo, esto puede no ser del todo cierto.

Guía de mejores prácticas de calidad de producto

162

Instituto Nacional de Tecnologías de la Comunicación

Ventas por mes en miles

Ventas al mes por empleado Objetivo de ventas

80 60 40 20 0 Mario

Luis

Ana

Pedro Laura

Figura 48 Ejemplo datos con contexto Esta segunda figura muestra los mismos datos con contexto. En este caso, se ve de forma clara en el gráfico que ninguno de los empleados ha llegado este mes al objetivo de ventas propuesto. Dar contexto a los datos puede parecer un paso obvio, pero es la práctica más omitida entre los desarrolladores de cuadros de mando. En la mayoría de los casos, el contexto se olvida porque la persona que crea el cuadro de mando ha trabajado tanto con los datos que sabe cuando éstos son buenos o malos. Esta suposición, sin embargo, no puede aplicarse al usuario final ya que puede traer falsas conclusiones. 5. Establecer la distribución de los datos La distribución incluye el diseño y el emplazamiento de controles dentro de un cuadro de mandos. La distribución tiene un gran impacto ya que determina si un usuario puede o no usar el cuadro de mandos fácilmente, y debería ofrecer un orden lógico y fluido con respecto a los datos específicos que se muestran. El cuadro de mandos debería cumplir también con la regla de 3 y 10 segundos; en 3 segundos el usuario debería tener una idea de todo el rendimiento global, y en 10 segundos el usuario debería tener una idea general de por qué se está consiguiendo ese rendimiento. Por ejemplo, si un usuario estuviera mirando un cuadro de mandos de marketing bien diseñado, a los 3 segundos sabría qué campañas se están desarrollando en la empresa actualmente y cómo se está haciendo cada una, y en 10 segundos sabría qué campañas se están haciendo mejor y quizás tendría alguna idea de por qué. Si el cuadro de mandos no es demasiado intuitivo como para cumplir con la regla de 3 a 10 segundos entonces no será útil. 6. Establecer la estética visual La estética visual incluye animación, paletas, efectos 2D y 3D, y la apariencia real de los controles. Está muy relacionado con la distribución de un cuadro de mandos pero afecta a la apariencia estética de cuestiones específicas dentro de un cuadro de mandos más que al diseño general. Mientras que la estética visual es importante a la hora de hacer un cuadro de mandos atractivo, los desarrolladores deben tener cuidado con que los efectos visuales no interfieran con la usabilidad y la eficiencia del cuadro de mandos.

Guía de mejores prácticas de calidad de producto

163

Instituto Nacional de Tecnologías de la Comunicación

7. Personalizar las vistas Una vez que se ha decidido qué información es importante para un usuario en un cuadro de mandos, es una buena práctica el proporcionar algunas capacidades de personalización de las vistas. Este punto es especialmente cierto en cuadro de mandos basados en OLAP donde la información es multidimensional y la única forma de tener una dibujo coherente de la información es verla desde todos los ángulos. De la misma forma, dar al usuario la capacidad de cambiar la perspectiva de los datos permite a veces ver tendencias o cambios importantes dentro de ellos que el usuario no sería capaz de ver de otra manera.

5.4.

BALANCED SCORECARD

El balanced scorecard es un sistema de gestión (no sólo un sistema de medida) que permite a la organización clarificar su visión y estrategia y traducirlo en acciones, creado por los Dres. Robert Kaplan y David Norton. Su objetivo es integrar en un solo procedimiento tanto los factores financieros como los no financieros obtenidos durante el desarrollo de la operación de una empresa, con el propósito de lograr alcanzar, por parte de los directivos, una rápida pero integral visión de la marcha de los negocios. Algunos beneficios de la implantación de un balanced scorecard son: -

Proporciona un medio ideal para comunicar la visión y la estrategia de la organización

-

Permite traducir objetivos, políticas y planes estratégicos en medidas independientes de rendimiento y productividad

-

Otorga a los empleados la oportunidad de contribuir al logro de los objetivos establecidos

-

Conecta los procesos desarrollados con los resultados obtenidos

-

Identifica los recursos requeridos para alcanzar los objetivos propuestos

-

Maximiza los niveles de servicio y calidad a clientes internos y externos.

La filosofía del balanced scorecard parte del principio de que la estrategia y la visión de una organización pueden ser enlazadas a cuatro medidas de rendimiento, cuyo comportamiento permitirá evaluar la forma como se están cumpliendo los objetivos incorporados en dichas variables. Estas medidas se mapean a 4 perspectivas: -

Perspectiva de aprendizaje y crecimiento

-

Perspectiva de proceso de negocio

-

Perspectiva de cliente

-

Perspectiva financiera

Guía de mejores prácticas de calidad de producto

164

Instituto Nacional de Tecnologías de la Comunicación

Financiera “Para tener éxito financieramente, ¿cómo deberíamos presentarnos a los accionistas?”

Clientes “Para conseguir nuestra visión, ¿cómo deberíamos presentarnos a los clientes?”

• Objetivos • Medidas • Metas • Iniciativas

Visión y estrategia

• Objetivos

• Medidas • Metas • Iniciativas

Procesos de negocio internos “Para satisfacer a nuestros accionistas y clientes, ¿en qué procesos de negocios deberíamos sobresalir?”

• Objetivos • Medidas • Metas • Iniciativas

Aprendizaje y crecimiento “Para conseguir nuestra visión, ¿cómo mantendremos nuestra capacidad de cambiar y mejorar?”

• Objetivos • Medidas • Metas • Iniciativas

Figura 49 Perspectiva del Balanced Scorecard 1. Perspectiva del aprendizaje y el crecimiento. Esta perspectiva evalúa cómo una organización gestiona su capacidad de innovar, mejorar y aprender para mantener el éxito en las operaciones y procesos críticos definidos en la perspectiva de procesos de negocio. Puede incluir la formación de los empleados y las actitudes culturales corporativas. En la filosofía de gestión moderna, el desarrollo de una cultura de aprendizaje en la empresa, donde los empleados estén constantemente aprendiendo y compartiendo el conocimiento para facilitar el crecimiento se está convirtiendo en un factor muy importante. La formación en el trabajo y las tutorías son también componentes esenciales de la perspectiva. 2. La perspectiva de procesos de negocio internos Las métricas basadas en esta perspectiva permiten a los directores saber cómo de bien se están llevando a cabo sus negocios, y si los productos y servicios cumplen con los requisitos del cliente. Estas métricas tienen que estar diseñadas cuidadosamente por aquellos que conocen los procesos de negocio en detalle. Se distinguen cuatro tipos de procesos: -

Procesos de Operaciones. Desarrollados a través de los análisis de calidad y reingeniería. Los indicadores son los relativos a costes, calidad, tiempos o flexibilidad de los procesos.

-

Procesos de Gestión de Clientes. Indicadores: Selección de clientes, captación de clientes, retención y crecimiento de clientes.

Guía de mejores prácticas de calidad de producto

165

Instituto Nacional de Tecnologías de la Comunicación

-

Procesos de Innovación: los cuales son difíciles de medir. Ejemplo de indicadores: % de productos nuevos, % productos patentados, introducción de nuevos productos en relación a la competencia...

-

Procesos relacionados con el Medio Ambiente y la Comunidad. Indicadores típicos de Gestión Ambiental, Seguridad e Higiene y Responsabilidad Social Corporativa.

3. Perspectiva del cliente Esta área se centra en la importancia de las acciones del cliente para alcanzar los objetivos de la organización. El centrarse en el cliente y en su satisfacción ha ganado terreno en la reciente filosofía de gestión. El aumento de la competitividad en los mercados significa que es más fácil que nunca para un cliente no satisfecho escoger un proveedor. Los objetivos, medidas, metas y actividades se planean para implementar la estrategia hacia la satisfacción de los clientes, y conseguir que su aportación lleve a alcanzar las metas de la organización. 4. Perspectiva financiera Los indicadores financieros son un objetivo final, dentro del modelo balanced scorecard, que deben ser complementados con otra clase de medidas, de tal manera que se pueda mejorar el funcionamiento de la organización. La perspectiva financiera del modelo busca responder a la pregunta de cómo los accionistas e inversionistas en general ven a la empresa y si los objetivos fijados son adecuados, de acuerdo a las expectativas en cuanto a crecimiento, utilidades, retorno de la inversión y eficiencia en el uso de los activos, entre los más comunes. La perspectiva financiera del balanced scorecard busca la maximización de los siguientes resultados y variables: valor agregado, ingresos, diversificación de fuentes, eficiencia operativa y un uso más adecuado del capital.

5.5. 5.5.1.

INTEGRACIÓN DE BALANCED SCORECARD CON MODELOS DE CALIDAD Balanced IT Scorecard de ESI

El ESI (European Software Institute) integró el modelo de referencia SPICE (ISO 15504) para la Mejora de Procesos Software en el modelo de gestión Balanced Scorecard. Se presenta en forma de modelo genérico, una metodología para adaptar el modelo a las necesidades específicas. El Balanced IT Scorecard de ESI tiene los siguientes componentes: 1. El modelo genérico de Balanced IT Scorecard de ESI. Este modelo define, para cada una de las perspectivas que forman parte del Balanced Scorecard, un conjunto de metas genéricas, factores relacionados e indicadores significativos.

Guía de mejores prácticas de calidad de producto

166

Instituto Nacional de Tecnologías de la Comunicación

OBJETIVOS

FACTORES

Afirmación  cuantitativa de qué se  debe alcanzar y  cuándo se debe  conseguir

Factores que afectan  positivamente la  consecución de un  objetivo (estrategia)

INDICADORES

INDICADORES

Miden el grado de  cumplimiento del  objetivo

Miden cómo el factor  apoya la consecución  del objetivo

Figura 50 Componentes de cada perspectiva 2. El método. Describe cómo aplicar el Balanced IT Scorecard de ESI.

Guía de mejores prácticas de calidad de producto

167

Instituto Nacional de Tecnologías de la Comunicación

6.

PLANTILLAS / GUÍAS RÁPIDAS

Existen distintos documentos que pueden ayudar a una organización en las tareas relacionadas con el aseguramiento de la calidad del producto software. En esta sección se van a proponer algunos modelos o plantillas que pueden ayudar a la hora de crear dichos documentos. Estas plantillas o modelos pretenden ser una guía a la hora de crear documentos relacionados con la calidad del producto software. Son un punto de partida, un ejemplo, que habrá que modificar de acuerdo a las necesidades de la organización y del proyecto. Las plantillas que se han desarrollado son las siguientes:

6.1.

PLANTILLA DEL PLAN DE CALIDAD

El plan de calidad, Plantilla_Plan_de_calidad, define el enfoque necesario para garantizar que la solución y el proceso de desarrollo de la solución cumplen los requisitos y estándares de calidad definidos. El plan explica de forma resumida las actividades y recursos precisos para verificar y validar el cumplimiento de los requisitos y estándares de calidad. Con esta plantilla se pretende dar una guía para la creación de un plan de calidad para el desarrollo de la solución. En ella se incluyen apartados correspondientes a los requisitos y estándares a seguir, a las actividades a llevar a cabo y a las personas implicadas y sus respectivas responsabilidades. Dichos apartados y todos los que componen la plantilla han de adecuarse a las necesidades concretas.

6.2. 6.2.1.

PLANTILLAS RELACIONADAS CON LOS REQUISITOS Plantilla del Plan de gestión de requisitos

El plan de gestión de requisitos establece un método ordenado por el que se deben conseguir los objetivos de la gestión de requisitos: identificación, desarrollo, mantenimiento, etc. Esta plantilla, Plantilla_Plan_de_gestión_de_requisitos, propone un punto de partida para la elaboración de un documento de este tipo. En él habrá que especificar de qué forma se van a recoger los requisitos, cómo se van a verificar, de qué forma se van a gestionar cambios relacionados con ellos, etc., asignando roles y responsabilidades a los implicados y describiendo los recursos que van a ser necesarios.

6.2.2.

Plantilla de Registro de requisitos del cliente

Esta plantilla, Plantilla_Registro_de_requisitos_del_cliente, pretende servir para el seguimiento y control de los distintos requisitos que se añaden o modifican en un proyecto, por parte del cliente. En ella se listan los distintos requisitos con su origen, fecha, tipo de requisito, etc. Las características que se reflejen en esta tabla pueden modificarse dependiendo de las necesidades.

Guía de mejores prácticas de calidad de producto

168

Instituto Nacional de Tecnologías de la Comunicación

6.2.3.

Plantilla de Especificación de objetivos y requisitos

El documento de especificación de objetivos y requisitos comunica las necesidades de negocio del cliente para una solución y especifica los requisitos del cliente. Detalla todos los requisitos capturados y actúa como el documento primario para la especificación. Plantilla_Especificacion_objetivos_y_requisitos

6.2.4.

Plantilla de Especificación de requisitos

Esta plantilla, Plantilla_Especificacion_de_requisitos, muestra una posible estructura del documento de especificación de requisitos. Este documento es el que recoge todos los requisitos del proyecto. Da una visión general del sistema y una descripción de la funcionalidad y de los requisitos con distintos tipos de detalle para que sean entendidos por todos los grupos de personas implicados en el proyecto. Los distintos apartados que se han propuesto han de adaptarse a las necesidades reales.

6.3. 6.3.1.

PLANTILLAS RELACIONADAS CON LAS PRUEBAS Plantilla del Plan de pruebas

El plan de pruebas refleja el enfoque y la programación de todas las pruebas del proyecto. Se planifican actividades, gente implicada, recursos, etc. Esta plantilla, Plantilla_plan_de_pruebas, recoge una posible estructura de este documento que como todas las demás tendrá que ser adaptada a las necesidades concretas.

6.3.2.

Plantilla de Caso de prueba

Esta plantilla, Plantilla_Caso_de_prueba, recoge una tabla en la que se pueden introducir los datos de cada uno de los casos de pruebas que se van a ejecutar. Permite recoger, además de los datos del caso de prueba y de la persona que lo va a realizar, los pasos que se van a llevar a cabo, señalando para cada uno si ha fallado o ha tenido éxito. En la plantilla aparece un número de casos que puede aumentarse o disminuirse según las necesidades. Al modificar alguna de las filas hay que tener cuidado con modificar alguna de las fórmulas de las celdas. Por cada acción del caso de prueba se marcará con una “x” si se ha completado con éxito o no y conforme a las casillas que se completen irán cambiando las celdas de Número de pasos completados por estado, y el Estado general del caso de prueba.

6.3.3.

Plantilla de Especificación de pruebas

La especificación de pruebas es un documento que se podría realizar para cada uno de los grupos de pruebas a realizar, es decir, se podría tener un documento de especificación de pruebas de aceptación o especificación de pruebas de sistema. El propósito de este documento es definir los objetivos, programación, responsabilidades, recursos, procedimientos y supuestos necesarios para llevar a cabo el tipo de prueba del que se esté haciendo la especificación. La estructura del mismo deberá adecuarse a las características de las pruebas y del proyecto concreto.Plantilla_Especificacion_de_pruebas

Guía de mejores prácticas de calidad de producto

169

Instituto Nacional de Tecnologías de la Comunicación

6.3.4.

Plantilla de Registro de ejecución de pruebas

El registro de ejecución de pruebas pretende ser un control de los distintos casos, escenarios o scripts de pruebas que se realizan. Como plantilla se propone una tabla que recoja las cuestiones más importantes de cada uno de ellos. Plantilla_Registro_de_ejecucion_de_pruebas

6.4. 6.4.1.

PLANTILLAS RELACIONADAS SEGUIMIENTO DE FALLOS

CON

LA

GESTIÓN

Y

Plantilla de Informe de fallos en las pruebas

Esta plantilla, Plantilla_Informe_fallos_en_pruebas, pretende servir de informe de los fallos encontrados durante la realización de pruebas. En ella se detallarán dichos fallos, el posible origen de los mismos, las acciones a llevar a cabo y las actividades de prueba que hay que volver a hacer, entre otros. En este modelo el informe se haría bien por plan de pruebas o por caso de pruebas. La elección podría depender del tamaño del proyecto o del número de fallos encontrados.

6.4.2.

Plantilla de Informe de incidencias

El objetivo de esta plantilla, Plantilla_Informe_incidencias, es la de informar de las distintas incidencias que vayan surgiendo a lo largo del ciclo de vida del software. Recoge toda la información relacionada con la incidencia producida y las posibles recomendaciones.

6.4.3.

Plantilla de Registro de fallos

La plantilla de registro de fallos, Plantilla_Registro_informe_de_fallos, es una plantilla genérica que puede estar orientada a mantener un seguimiento de cualquier fallo detectado durante el ciclo de vida del proyecto software. En este caso, que nos estamos centrando en documentos que puedan ayudar a gestionar este tipo de calidad, esta plantilla podría ceñirse sólo al registro de fallos encontrados durante las pruebas. Los datos recogidos en ella se pueden adecuar a las necesidades concretas del proyecto o de la organización.

6.5. 6.5.1.

PLANTILLAS RELACIONADAS CON MÉTRICAS Plantilla de plan de medición

El plan de medición tiene como objetivos la identificación y exposición de las métricas que se van a utilizar en el proyecto, asegurándose de que tales métricas están alineadas con los objetivos de negocio y del proyecto y que se implementan de forma organizada y planificada. Esta plantilla, Plantilla_Plan_de_medicion, contiene las directrices para crear un plan de este tipo que describa todas las cuestiones relacionadas con las métricas a utilizar durante el ciclo de vida del proyecto. Como se ha dicho de todas las plantillas, esto sólo es el punto de partida, hay que adecuarla a las necesidades concretas de los proyectos y las organizaciones.

Guía de mejores prácticas de calidad de producto

170

Instituto Nacional de Tecnologías de la Comunicación

6.6. 6.6.1.

PLANTILLAS DIFUSIÓN

RELACIONADAS

CON

LA

PUBLICACIÓN

Y

Plantilla de recogida de KPIs

Esta plantilla, Plantilla_KPI, pretende servir de apoyo a la hora de identificar y describir los distintos indicadores clave de rendimiento de una organización. Además se propone describir de qué forma se puede actuar dentro de cada área de la organización para impactar de forma positiva en esos indicadores.

6.7. 6.7.1.

PLANTILLAS RELACIONADAS CON LA GESTIÓN DE RIESGOS Plantilla de la Estrategia de gestión de riesgos

El proceso de gestión de riesgos tiene que asegurar que el nivel, tipo y visibilidad de la gestión de riesgos es proporcional al riesgo y a la importancia del proyecto. Mediante este documento se van a describir las actividades asociadas a la gestión de riesgos, siendo éstas asignadas a las distintas personas implicadas. Se ha de establecer la forma en la que se va a medir el impacto y la probabilidad de los riesgos y por la tanto la valoración final de los mismos. Plantilla_Estrategia_de_gestion_de_riesgos

6.7.2.

Plantilla de Registro de riesgos

Esta plantilla, Plantilla_Registro_de_riesgos, sirve como registro de los riesgos identificados, así como para el análisis, planificación de respuesta, monitorización y control de los mismos. En la plantilla se han definido unos valores modelo que aparecen en las tablas de la parte inferior y que son los que aparecen en las listas desplegables de cada una de las columnas. La valoración de los riesgos se hace en función del impacto y la probabilidad, para los que se han definido una serie de valores posibles, que pueden ser modificados de acuerdo a las necesidades. Éstos deberían ser consistentes con los datos expuestos en la estrategia de gestión de riesgos.

Guía de mejores prácticas de calidad de producto

171

Instituto Nacional de Tecnologías de la Comunicación

7.

GLOSARIO -

Adivinar errores: técnica de diseño de pruebas donde la experiencia del técnico de pruebas se usa para anticipar qué defectos se podrán presentar en el componente o sistema bajo prueba como resultado de errores cometidos, y para diseñar pruebas específicamente para encontrarlos.

-

Análisis del valor frontera: técnica de diseño de caja negra en la que los casos de prueba se diseñan basándose en valores frontera.

-

Análisis de punto función: método dirigido a medir el tamaño de la funcionalidad de un sistema de información. La medida es independiente de la tecnología. Esta medida puede usarse como la base para la medida de productividad, la estimación de los recursos necesarios y el control del proyecto.

-

Análisis de riesgos: proceso de evaluar riesgos identificados para estimar su impacto y probabilidad de ocurrencia.

-

Análisis dinámico: proceso de evaluar el comportamiento, p.ej. rendimiento de la memoria, uso de la CPU, de un sistema o componente durante la ejecución.

-

Análisis estático: análisis de artefactos software, p.ej. requisitos o código, llevados a cabo sin la ejecución de dichos artefactos.

-

Aseguramiento de la calidad: parte de la gestión de la calidad centrada en proporcionar confianza en que los requisitos de calidad se cumplirán.

-

Auditoría: evaluación independiente de un producto o proceso software para establecer conformidades de estándares, directrices, especificaciones, y/o procedimientos basados en criterios objetivos, incluyendo documentos que especifiquen: ƒ

la forma o contenido de los productos que se van a producir

ƒ

el proceso por el que se van a producir los productos

ƒ

cómo se va a medir la conformidad con los estándares o directrices

-

Automatización de pruebas: uso del software para realizar o soportar actividades de prueba.

-

Balanced Scorecard: El balanced scorecard es un sistema de gestión (no sólo un sistema de medida) que permite a la organización clarificar su visión y estrategia y traducirlo en acciones. Fue creado por los Dres. Robert Kaplan y David Norton.

-

Batería de casos de pruebas: ver baterías de pruebas.

-

Batería de pruebas: conjunto de varios casos de pruebas para un componente o sistema bajo prueba, donde la post condición de una prueba se usa con frecuencia como precondición de la siguiente.

-

Calidad: grado con el que un componente o sistema satisface los requisitos especificados y/o las necesidades y expectativas del usuario/cliente.

Guía de mejores prácticas de calidad de producto

172

Instituto Nacional de Tecnologías de la Comunicación

-

Camino: secuencia de eventos, p.ej. sentencias ejecutadas, de un componente o sistemas desde un punto de entrada hasta uno de salida.

-

Caso de prueba: conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y post condiciones de ejecución desarrolladas para un objetivo o condición de prueba particular, tal como probar un determinado camino de un programa.

-

Clase de equivalencia: ver partición de equivalencia.

-

Cobertura de camino: porcentajes de caminos que se han probado por una batería de pruebas.

-

Cobertura de código: método de análisis que determina qué partes del software se ha ejecutado y cuáles no, por el juego de pruebas.

-

Cobertura de decisión: porcentaje de resultados de decisión que se han ejecutado por una batería de pruebas. Un 100% de cobertura de decisión implica un 100% de cobertura de rama y un 100% de cobertura de sentencia.

-

Cobertura de pruebas: grado, expresado como porcentaje, de casos de pruebas de un sistema que han sido ejecutados.

-

Cobertura de sentencia: porcentaje de sentencias ejecutables que han sido probadas por una batería de pruebas.

-

Código: instrucciones o definiciones de datos expresadas en un lenguaje de programación o como forma de salida en un ensamblador, compilador u otro traductor.

-

Compilador: herramienta software que traduce programas expresados en leguaje de alto nivel a lenguaje máquina equivalente.

-

Complejidad: componente o sistema que tiene un diseño o estructura interna que es difícil de entender, de mantener o verificar.

-

Complejidad ciclomática: número de caminos independientes a través de un programa. Se define como: L-N+2P, donde: ƒ

L= número de enlaces en un grafo

ƒ

N= número de nodos en un grafo

ƒ

P= número de partes desconectadas del grafo

-

Componente: elemento software mínimo que puede probarse de forma aislada.

-

Comportamiento: respuesta de un componente o sistema respecto a un conjunto de valores de entrada y precondiciones.

-

Condición: expresión lógica que puede ser evaluada como verdadera o falso.

-

Condición de pruebas: un elemento o evento de un componente o sistema que podría verificar uno o más casos de pruebas, p.ej. función, transacción, característica, atributo de calidad o elemento estructural.

Guía de mejores prácticas de calidad de producto

173

Instituto Nacional de Tecnologías de la Comunicación

-

Configuración: composición de un componente o sistema definido por el número, naturaleza e interconexiones de las partes que lo constituyen.

-

Conformidad: capacidad del producto software para adherirse a los estándares, convenciones o regulaciones en leyes o prescripciones similares.

-

Consistencia: grado de uniformidad, estandarización y libertad de contradicción entre documentos o partes de un componente o sistema.

-

Control de cambios: ver control de configuración.

-

Control de configuración: un elemento de gestión de la configuración, que consisten en la evaluación, coordinación, aprobación o desaprobación y la implementación de cambios para configurar elementos después del establecimiento formal de la configuración.

-

Control de riesgos: proceso a través del cual se toman decisiones y medidas de protección para reducir o mantener los riesgos dentro de los niveles especificados.

-

Control de versiones: ver control de configuración.

-

Criterios de aceptación: criterios de salida que un componente o sistema debe satisfacer para ser aceptado por un usuario, un cliente, u otra entidad autorizada.

-

Criterio de entrada: conjunto de condiciones genéricas y específicas para permitir a un proceso progresar con una tarea definida, p.ej. fase de pruebas. El propósito del criterio de entrada es prevenir a una tarea de empezar lo que supondría un mayor esfuerzo comparado con el esfuerzo necesario para eliminar el criterio de entrada fallido.

-

Criterio de éxito/fallo: reglas de decisión usadas para determinar si un ítem de prueba (función) o característica ha pasado o fallado una prueba.

-

Criterio de salida: conjunto de condiciones genéricas y específicas, acordadas con las personas implicadas de la organización, que permiten a un proceso a estar completado oficialmente. El propósito del criterio de salida es prevenir a una tarea de ser considerada completa cuando hay todavía partes pendientes de la tarea que no se han terminado. El criterio de salida se usa para informar y planificar cuando parar de probar.

-

Dashboards: son los cuadros de mando que muestran información sin compararla con los objetivos propuestos. Es decir, con ellos únicamente se pueden visualizar los KPI (Key Performance Indicator). Ver Indicador clave de rendimiento (KPI)

-

Decisión: punto de un programa en el que el flujo de control tiene dos o más rutas alternativas. Un nodo con dos o más enlaces a ramas separadas.

-

Densidad de defectos: número de defectos identificados en un componente o sistema dividido por el tamaño del componente o sistema (expresado en términos de medidas estándares, p.ej. líneas de código, número de clases o puntos función).

-

Defecto: imperfección en un componente o sistema que puede causar un fallo a la hora de realizar su función. Un defecto encontrado durante la ejecución puede causar un fallo del componente o sistema.

Guía de mejores prácticas de calidad de producto

174

Instituto Nacional de Tecnologías de la Comunicación

-

Diagrama de estados: diagrama que representa los estados de un componente o sistema puede asumir y muestra los eventos o circunstancias que causan y/o resultan de un cambio de un estado a otro.

-

Diseño de pruebas: ver especificación de diseño de pruebas.

-

Disponibilidad: grado de un componente o sistema de estar operativo y accesible a la hora de usarlo.

-

Dominio: conjunto del que pueden seleccionarse valores de entrada y/o salida válidos.

-

Dominio de entrada: conjunto del cual puede seleccionarse un valor de entrada válido. Ver también dominio.

-

Dominio de salida: conjunto del cual puede seleccionarse un valor de salida válido. Ver también dominio.

-

Driver: componente software o herramienta de prueba que reemplaza un componente que se encarga del control y/o de la llamada a un componente o sistema.

-

Eficiencia: capacidad del producto software para proporcionar el rendimiento apropiado, relativo a la cantidad de recursos usados bajo las condiciones indicadas.

-

Ejecución de pruebas: proceso de ejecutar una prueba en el componente o sistema bajo prueba, produciendo resultados reales.

-

Entorno de pruebas: entorno que puede incluir hardware, instrumentación, simuladores, herramientas de software y otros elementos de soporte necesarios para llevar a caso una prueba.

-

Entregable: cualquier producto que debe ser entregado a alguien distinto del autor del proyecto.

-

Error: acción humana que produce un resultado incorrecto.

-

Escalas de medición: Son niveles que categorizan a las métricas de acuerdo a la rigurosidad con que han sido construidas y al propio comportamiento de las variables que miden. Normalmente se clasifican en cuatro tipos: nominal, ordinal, intervalo o razón/ratio.

-

Escalabilidad: capacidad del producto software de ser mejorado para contener incrementos de carga.

-

Escenario de prueba: Los escenarios son una descripción paso a paso de la funcionalidad de un caso de uso del producto o del negocio, sin demasiado detalle, con el objetivo de hacer entender cómo funciona este caso de uso.

-

Estimación del esfuerzo: documenta el propósito de las actividades de medición y análisis y especifica el tipo de acciones que se pueden tomar a partir de resultados de análisis de los datos.

-

Especificación: documento que especifica, de una forma completa, precisa y verificable, los requisitos, diseño, comportamiento u otras características de un

Guía de mejores prácticas de calidad de producto

175

Instituto Nacional de Tecnologías de la Comunicación

componente o sistema, y con frecuencia, especifica también los procedimientos para determinar si se ha cumplido lo que se ha propuesto. -

Especificación de casos de prueba: documento que especifica un conjunto de casos de prueba (objetivos, entradas, acciones de prueba, resultados esperados y precondiciones de ejecución) para un elemento de prueba.

-

Especificación de componentes: descripción de la función de un componente en términos de valores de salida obtenidos dados unos valores de entrada y bajo unas condicione específicas, y el comportamiento no funcional requerido.

-

Especificación de diseño de pruebas: documento que especifica las condiciones de prueba para un elemento de prueba, el enfoque de pruebas detallado y los casos de pruebas de alto nivel asociados.

-

Especificación de pruebas: documento que consiste en una especificación de diseño de pruebas, especificación de casos de prueba y/o especificación de procedimientos de prueba.

-

Estabilidad: capacidad del producto software de evitar efectos inesperados de modificaciones en el software.

-

Estrategia de pruebas: descripción a alto nivel de los niveles de pruebas y las pruebas dentro de dichos niveles para una organización o programa.

-

Evaluación: ver pruebas.

-

Exactitud: capacidad del producto software de proporcionar los resultados o efectos correctos o acordados con el grado de precisión necesario.

-

Éxito de una prueba: una prueba se considera que tiene éxito si sus resultados reales coinciden con los esperados.

-

Fallo: desviación de un componente o sistema de su servicio o resultado esperado.

-

Fallo de una prueba: una prueba se considera que ha fallado cuando se resultado real no coincide con los resultados esperados.

-

Fase de pruebas: conjunto de actividades de prueba recogidas en una fase manejable de un proyecto, p.ej. ejecución de actividades a nivel de prueba.

-

Fiabilidad: capacidad del producto software para realizar las funciones requeridas bajo las condiciones indicadas durante un periodo de tiempo especificado, o para un número concreto de operaciones.

-

Flujo de control: secuencia de eventos (trayectorias) en la ejecución de un componente o sistema.

-

Flujo de datos: representación abstracta de la secuencia y posibles cambios del estado de objetos de datos, donde el estado de un objeto es: creación, uso, modificación o destrucción.

-

Funcionalidad: capacidad del producto software de proporcionar funciones que satisfagan las necesidades indicadas cuando el software se usa bajo las condiciones especificadas.

Guía de mejores prácticas de calidad de producto

176

Instituto Nacional de Tecnologías de la Comunicación

-

Gestión de defectos: el proceso de reconocer, ejecutar acciones y eliminar defectos. Incluye registro de defectos, clasificación e identificación del impacto de los errores.

-

Gestión de la calidad: actividades coordinadas para dirigir y controlar una organización con respecto a la calidad. Dirigir y controlar una organización en relación a la calidad incluye generalmente el establecimiento de la política y los objetivos de calidad, la planificación de la calidad, el control de la calidad, el aseguramiento de la calidad y la mejora de la calidad.

-

Gestión de la configuración: disciplina que aplica directrices técnicas y administrativas y que vigila para identificar y documentar las características funcionales y físicas de un componente de configuración, controlar cambios de las características, grabar e informar del proceso de cambio y el estado de implementación y verificar la conformidad con los requisitos especificados.

-

Gestión de pruebas: planificación, estimación, monitorización y control de las actividades de pruebas, normalmente actividades llevadas a cabo por el jefe de pruebas.

-

Gestión de riesgos: aplicación sistemática de procedimientos y prácticas para las tareas de identificar, analizar, priorizar y controlar riesgos.

-

Gráfico de flujo de control: diagrama de la secuencia de eventos (trayectorias) en la ejecución de un componente o sistema.

-

Hito: punto en el tiempo en un proyecto en el que entregables y resultados definidos han de estar listos.

-

Incidencia: cualquier evento que ocurra que requiera una investigación.

-

Índice: El concepto de índice se asocia al dinamismo del fenómeno de interés. Se puede definir como una medida del cambio en una cantidad (y) por unidad de otra cantidad (x) de la que la primera (y) depende

-

Identificación de riesgos: proceso de identificar riesgos usando técnicas tales como brainstorming, checklist e histórico de fallos.

-

Indicadores: son gráficos analíticos construidos a partir de los datos recogidos y los derivados junto con los criterios de decisión.

-

Indicador clave de rendimiento (KPI): métrica de alto nivel de la efectividad y/o eficiencia que se usa como guía y control progresivo del rendimiento.

-

Índice de defectos: un buen objetivo para el índice de defectos debería conducir a una reducción del número total de defectos de una versión a la siguiente, independientemente del tamaño. El índice de defectos pueden expresarse en términos de número de defectos eliminados por miles de líneas de código (KLOC) o por puntos función.

-

Inspección: tipo de revisión entre pares que se basa en un examen visual de documentos para detectar defectos, p.ej. violaciones de estándares de desarrollo o no conformidades con documentación de más alto nivel. Es la técnica de revisión más formal y por lo tanto siempre está basada en un procedimiento documentado.

Guía de mejores prácticas de calidad de producto

177

Instituto Nacional de Tecnologías de la Comunicación

-

Integración: proceso de combinar componentes o sistemas en grandes montajes.

-

Interoperabilidad: capacidad del producto software de interactuar con uno o más componentes o sistemas especificados.

-

Línea base: una especificación o producto software que ha sido formalmente revisado o acordado, de tal forma que a partir del momento en que se establece sirve como base para el desarrollo futuro, y sólo puede ser cambiado a través de un proceso de control de cambios formal.

-

Madurez: capacidad de una organización respecto a la efectividad y eficiencia de sus procesos y prácticas de trabajo. Capacidad del producto software de evitar fallos como resultado de defectos en el software.

-

Mantenibilidad: facilidad con la que un producto software puede ser modificado para corregir defectos, modificar para satisfacer nuevos requisitos, modificar para hacer el mantenimiento futuro más sencillo, o adaptar a cambios de entorno.

-

Mantenimiento: modificación de un producto software una vez que se ha entregado para corregir defectos, mejorar el rendimiento u otros atributos, o adaptar el producto a un entorno modificado.

-

Máquina de estados finitos: modelo computacional que consiste en un número de estados y transiciones entre los estados, posiblemente acompañados de acciones.

-

Medición: proceso de asignar un número o categoría a una entidad para describir un atributo de dicha entidad.

-

Medida: número o categoría que se le asigna a un atributo de una entidad cuando se hace una medición.

-

Medidas básica: son los datos a recoger, como puntos función o número de líneas de código.

-

Medidas derivadas: son los datos calculados, basados en las medidas básicas, como la productividad.

-

Mejores prácticas: método superior o práctica innovadora que contribuye a la mejora de rendimiento en una organización bajo un contexto dado, normalmente reconocido como el mejor por otras organizaciones similares.

-

Metodología: Se refiere a los métodos de investigación que se sigue para alcanzar una gama de objetivos en una ciencia.

-

Métrica: escala de medida y método usado para medir.

-

Métrica de intervalo: indica la diferencia exacta entre los puntos de medición. Se le pueden aplicar las operaciones matemáticas de suma y resta. Esta escala requiere una unidad de medición bien definida que se puede tomar como estándar

-

Métricas de líneas de código (LOC): Es una métrica básica que sirve como indicador del tamaño del software.

-

Métricas de proceso: se pueden utilizar para mejorar el desarrollo del software y el mantenimiento. Ejemplos de este tipo son la efectividad de la eliminación de defectos

Guía de mejores prácticas de calidad de producto

178

Instituto Nacional de Tecnologías de la Comunicación

durante el desarrollo, el patrón de la llegada de defectos en las pruebas, y el tiempo de respuesta del proceso de corrección. -

Métricas de producto: describen las características del producto como tamaño, complejidad, características de diseño, rendimiento y nivel de calidad.

-

Métricas de proyecto: describen las características del proyecto y su ejecución. Algún ejemplo puede ser el número de desarrolladores de software, la dotación de recursos a lo largo del ciclo de vida del software, el coste, calendario y productividad.

-

Modelo de desarrollo iterativo: desarrollo del ciclo de vida donde un proyecto se divide en un número de iteraciones (normalmente grande). Una iteración es una vuelta completa de desarrollo que da como resultado una versión de un producto ejecutable, un subconjunto del producto final bajo desarrollo, que crece de iteración en iteración hasta convertirse en el producto final.

-

Modelo en V: un marco que describe las actividades del ciclo de vida del software desde la especificación de requisitos hasta el mantenimiento. El modelo en V ilustra cómo se pueden integrar las actividades de prueba en cada una de las fases del ciclo de vida del desarrollo del software.

-

Nivel de prueba: grupo de actividades de prueba que se organizan y gestionan de forma conjunta.

-

Niveles de capacidad: ayudan a definir la efectividad del proceso para alcanzar su propósito definido.

-

No conformidad: no cumplimiento de un requisito específico.

-

OLAP (On-Line Analytical Processing): El procesamiento analítico en línea es una solución usada en el campo de la Inteligencia de negocio cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello usa estructuras multidimensionales que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales. La razón principal de usar OLAP para las consultas es su alta velocidad de respuestas.

-

Particionamiento de equivalencia: técnica de diseño de pruebas de caja negra en la que los casos de pruebas se diseñan para ejecutar valores representativos de particiones de equivalencia. En principio, los casos de pruebas se diseñan para cubrir cada partición al menos una vez.

-

Partición de equivalencia: partición de un dominio de entrada o salida para el que el comportamiento de un componente o sistema se asume que sea el mismo, basándose en la especificación.

-

Plan de pruebas: documento que describe el alcance, enfoque, recursos y programación de las actividades de prueba. Identifica, entre otros, elementos de prueba, características a probar, las tareas de pruebas, quién debe hacer cada tarea, etc.

-

Porcentaje: Ver Proporción. Una proporción se convierte en porcentaje cuando se expresa en términos de unidades por cien. Los porcentajes se utilizan normalmente para presentar resultados en informes.

Guía de mejores prácticas de calidad de producto

179

Instituto Nacional de Tecnologías de la Comunicación

-

Portabilidad: facilidad con la que un producto software puede ser trasladado de un entorno software o hardware a otro.

-

Precondición: condición del entorno o estado que debe cumplirse antes de que se pueda ejecutar una prueba o procedimiento de pruebas particular en un componente o sistema.

-

Prioridad: nivel de importancia asignada a un elemento, p.ej. un defecto.

-

Proceso: conjunto de relaciones interrelacionadas, que transforman entradas en salidas.

-

Proceso de pruebas: proceso de pruebas fundamental que comprende planificación, especificación, ejecución, registro, comprobación y actividades de cierre.

-

Productividad: Capacidad de producir o desarrollar un producto de forma satisfactoria con los menos recursos posibles.

-

Proporción: Ver ratio. La proporción se diferencia del ratio en que el numerador es parte del denominador, no son categorías excluyentes

-

Prototipo: es un borrador de un producto potencial o de una parte del mismo, una simulación de los requisitos.

-

Proyecto: conjunto de actividades coordinadas y controladas con fecha de inicio y fin asumido para conseguir un objetivo conforme a unos requisitos específicos, incluyendo restricciones de tiempo, coste y recursos.

-

Prueba: conjunto de uno o más casos de pruebas.

-

Pruebas alpha: pruebas operacionales reales o simuladas llevadas a cabo por usuarios/clientes potenciales o por un equipo de pruebas independientes dentro de la organización, pero fuera de la organización del desarrollo.

-

Pruebas basadas en la especificación: ver pruebas de caja negra.

-

Pruebas basadas en requisitos: enfoque de pruebas en las que los casos de prueba se diseñan en base a los objetivos y condiciones de pruebas obtenidas de los requisitos.

-

Pruebas basadas en riesgos: pruebas orientadas hacia a explorar y proporcionar información sobre riesgos.

-

Pruebas beta: pruebas operacionales llevadas a cabo por usuarios/clientes potenciales y/o existentes en un sitio externo a la organización, para determinar si un componente o sistema satisface o no las necesidades del usuario/cliente y encaja dentro de los procesos de negocio.

-

Pruebas big-bang: es un tipo de pruebas de integración en la que elementos software, elementos hardware o ambos se combinan en un componente o sistema único.

-

Pruebas de aceptación: pruebas formales con respecto a las necesidades de los usuarios, los requisitos y los procesos de negocio llevados a cabo para determinar si

Guía de mejores prácticas de calidad de producto

180

Instituto Nacional de Tecnologías de la Comunicación

un sistema satisface o no los criterios de aceptación y para permitir a los usuarios, clientes u otras entidades autorizadas a determinar si se acepta o no el sistema. -

Pruebas de caja de cristal: ver pruebas de caja blanca.

-

Pruebas de caja blanca: pruebas basadas en el análisis de la estructura interna de un componente o sistema.

-

Pruebas de caja negra: pruebas, tanto funcionales como no funcionales, sin referencia a la estructura interna del componente o sistema.

-

Pruebas de carga: tipo de pruebas centradas en medir el comportamiento de un componente o sistema con carga incremental, p.ej. el número de usuarios paralelos y/o el número de transacciones, para determinar que carga puede manejar el componente o sistema. Ver también pruebas de estrés.

-

Pruebas de caso de uso: técnica de diseño de caja negra en las que los casos de prueba se diseñan para ejecutar escenarios de usuario.

-

Pruebas de componente: pruebas de componentes de software individuales.

-

Pruebas de confirmación: ver re-probar.

-

Pruebas de conformidad: proceso de pruebas para determinar el grado de conformidad del componente o sistema.

-

Pruebas de decisión: técnica de diseño de pruebas de caja blanca donde los casos de pruebas se diseñan para ejecutar resultados de decisión.

-

Pruebas de desarrollo: pruebas formales e informales llevadas a cabo durante la implementación de un componente o sistema, normalmente en el entorno del desarrollo y realizadas por desarrolladores.

-

Pruebas de escalabilidad: pruebas para determinar la escalabilidad de un producto software.

-

Pruebas de estrés: pruebas llevadas a cabo para evaluar un sistema o componente al límite de los requisitos especificados. Ver también pruebas de carga.

-

Pruebas de funcionalidad: proceso de pruebas para determinar la funcionalidad de un producto software.

-

Pruebas de integración: pruebas realizadas para detectar defectos en las interfaces e interacciones entre componentes o sistemas integrados.

-

Pruebas de integración de sistemas: pruebas de la integración de sistemas o paquetes; pruebas de interface a organizaciones externas, etc.

-

Pruebas de integridad de componentes: pruebas realizadas para descubrir errores en las interfaces e interacciones entre componentes integrados.

-

Pruebas de regresión: pruebas sobre un programas que ya ha sido probado previamente sobre el que se ha hecho alguna modificación para asegurar que no se han introducido o descubierto defectos en las áreas que no se han modificado, como resultado de los cambios que se han introducido. Estas pruebas se llevan a cabo cuando se ha producido algún cambio en el software o su entorno.

Guía de mejores prácticas de calidad de producto

181

Instituto Nacional de Tecnologías de la Comunicación

-

Pruebas de rendimiento: proceso de probar para determinar el rendimiento de un producto software.

-

Pruebas de seguridad: pruebas para determinar la seguridad de un producto software.

-

Pruebas de sentencia: técnica de diseño de pruebas de caja blanca en las que los casos de prueba se diseñan para ejecutar sentencias.

-

Pruebas de sistemas: proceso de probar un sistema integrado para verificar que satisface los requisitos especificados.

-

Pruebas de tablas de decisión: técnica de diseño de pruebas de caja negra en las que los casos de pruebas se diseñan para ejecutar las combinaciones de entradas y/o estímulos (causas) mostradas en la tabla de decisión.

-

Pruebas de transición de estados: técnica de diseño de pruebas de caja negra en las que los casos de pruebas se diseñan para ejecutar transiciones de estado válidas y no válidas.

-

Pruebas de usuario: pruebas donde usuarios reales se involucran para evaluar la usabilidad de un componente o sistema.

-

Pruebas dinámicas: pruebas que implican la ejecución del software de un componente o sistema.

-

Pruebas estáticas: pruebas de un componente o sistema a nivel de especificación o implementación sin la ejecución de dicho software, p.ej. revisiones o análisis estático.

-

Pruebas exhaustivas: enfoque de pruebas en las que la batería de pruebas comprende todas las combinaciones de valores de entrada y precondiciones.

-

Pruebas exploratorias: enfoque de pruebas de software que realiza de forma simultánea aprendizaje, diseño de pruebas y ejecución de las mismas. Mientras que se prueba el software, el técnico de pruebas aprende cosas que junto con la experiencia y creatividad genera nuevas y mejores pruebas para ejecutar.

-

Pruebas funcionales: pruebas basadas en el análisis de la especificación de la funcionalidad de una componente o función. Ver también pruebas de caja negra.

-

Pruebas negativas: pruebas que se realizan para mostrar que un componente o sistema no funciona.

-

Pruebas no funcionales: pruebas de los atributos de un componente o sistema que no están relacionados con la funcionalidad.

-

Pruebas no válidas: pruebas que se realizan usando valores que deberían ser rechazados por el componente o sistema.

-

Puerta de calidad: es un punto por el que pasa cada uno de los requisitos antes de formar parte de la especificación de requisitos. Las puertas de calidad se aseguran de que cada requisito cumple con el criterio que tiene asignado.

-

Puntos función: indicador de las oportunidades de error en las métricas de densidad de defectos

Guía de mejores prácticas de calidad de producto

182

Instituto Nacional de Tecnologías de la Comunicación

-

Ratio: Es el resultado de dividir una cantidad por otra. El numerador y el denominador son dos categorías excluyentes.

-

Registro de incidencias: grabación de los detalles de todas las incidencias que ocurran.

-

Rendimiento: grado con el que un componente o sistema consigue las funciones designadas dentro de las restricciones establecidas respecto a tiempo de proceso y tasa de transferencia. Ver también eficiencia.

-

Re-probar: consiste en ejecutar casos de pruebas que fallaron con anterioridad con el objetivo de verificar que las acciones que se tomaron para corregir los fallos tuvieron éxito.

-

Requisito: condición o capacidad necesitada por un usuario para solucionar un problema o conseguir un objetivo que debe ser satisfecho o poseído por un sistema o un componente de un sistema para satisfacer un contrato, estándar, especificación u otro tipo de documento.

-

Requisito funcional: requisito que especifica una función ha de realizar un componente o función.

-

Requisito no funcional: requisito que no está relacionado con la funcionalidad, pero sí con atributos como fiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad.

-

Resultado: consecuencia de la ejecución de una prueba. Incluye salidas de pantalla, cambios de datos, informes y comunicación de mensajes.

-

Resultado de decisión: resultado de una decisión, por el que se determina que rama seguir.

-

Resultado esperado: comportamiento predicho por la especificación, u otra fuente, del componente o sistema bajo las condiciones especificadas.

-

Reusabilidad: un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee.

-

Revisión: evaluación del estado un producto o proyecto para averiguar discrepancias de los resultados planificados y recomendar mejoras. Como ejemplos se incluyen revisión informal, revisiones técnicas, inspecciones…

-

Revisión entre pares: una revisión de un producto de trabajo software realizada por compañeros con el propósito de identificar defectos y mejoras. Como ejemplos están las inspecciones, las revisiones técnicas y los walkthrough.

-

Revisión formal: revisión caracterizada documentados, p.ej. una inspección.

-

Revisión informal: revisión que no se basa en un procedimiento formal (documentado).

-

Revisión técnica: actividad de discusión entre pares que se centra en conseguir un consenso en el enfoque técnico a tomar.

Guía de mejores prácticas de calidad de producto

por

procedimientos

y

requisitos

183

Instituto Nacional de Tecnologías de la Comunicación

-

Riesgo: factor que puede resultar en una consecuencia negativa en el futuro; normalmente expresado como impacto y probabilidad.

-

Robustez: grado en el que un componente o sistema puede funcionar correctamente en presencia de entradas inválidas o con condiciones de entorno de estrés.

-

Satisfacción del cliente: La satisfacción del cliente, normalmente, se mide mediante encuestas realizadas al cliente, que puntúa en una escala de cinco puntos: muy satisfecho, satisfecho, neutral, insatisfecho, muy insatisfecho. Algunos de los parámetros que se evalúan en estas encuestas son: capacidad, funcionalidad, usabilidad, rendimiento, fiabilidad, mantenibilidad, documentación/información y servicio Scorecards: Son cuadros de mando que muestran información estratégica y están orientados a mostrar objetivos, por lo tanto, además de ofrecer los indicadores KPI, permiten almacenar en el sistema los KGI (Key Goal Indicador). Ver KGI

-

-

Script de prueba: se usa para referirse a la especificación de un procedimiento de prueba, especialmente uno automatizado.

-

Seguridad: atributos del producto software que se relaciona con su capacidad para prevenir accesos no autorizados, bien sean accidentales o deliberados, a programas o datos.

-

Sentencia: entidad de un lenguaje de programación, que suele ser la unidad más pequeña indivisible de ejecución.

-

Sentencia ejecutable: sentencia que, cuando se compila, se traduce a código objeto, y se ejecutará de forma procedimental cuando el programa se ejecute y podrá realizar una acción en los datos.

-

Severidad: grado de impacto que tiene un defecto en el desarrollo u operación de un componente o sistema.

-

Simulación: representación de las características de comportamiento seleccionadas de un sistema físico o abstracto por otro sistema.

-

Sistema: colección de componentes organizados para conseguir una función o un grupo de funciones específicas.

-

Stub: implementación esquemática o con un propósito especial de un componente software, usado para desarrollar o probar un componente que llama o depende de él. Reemplaza al componente llamado.

-

Tabla de decisión: una tabla que muestra las combinaciones de entradas y/o estímulos (causas) con sus salidas asociadas y/o acciones (efectos), que puede usarse para diseñar casos de pruebas.

-

Tabla de decisión causa-efecto: ver tabla de decisión.

-

Tabla de estados: una tabla que muestra las transiciones resultantes para cada combinación de estados con cada posible evento, mostrando tanto las transiciones válidas como las inválidas.

Guía de mejores prácticas de calidad de producto

184

Instituto Nacional de Tecnologías de la Comunicación

-

Tasa de defectos: proporción de fallos de una categoría dada en una unidad de medida dada, p.ej. fallos por unidad de tiempo, fallos por número de transacciones…

-

Técnica de diseño de pruebas: procedimiento usado para obtener y/o seleccionar casos de prueba.

-

Técnicas de diseño de pruebas basadas en la especificación: ver técnicas de diseño de pruebas de caja negra.

-

Técnicas de diseño de pruebas basadas en la experiencia: procedimiento para obtener y/o seleccionar casos de pruebas basados en la experiencia, conocimientos e intuición del técnico de pruebas.

-

Técnica de diseño de pruebas de caja blanca: procedimiento para obtener y/o seleccionar casos de prueba basados en el análisis de la estructura interna de un componente o sistema.

-

Técnica de diseño de pruebas de caja negra: procedimiento para obtener y/o seleccionar casos de pruebas basados en el análisis de la especificación, funcional o no funcional, de un componente o sistema sin referencia a su estructura interna.

-

Técnicas de diseño de pruebas funcionales: procedimiento para obtener y/o seleccionar casos de prueba basados en el análisis de la especificación de la funcionalidad de un componente o sistema sin hacer referencia a su estructura interna. Ver también técnicas de diseño de pruebas de caja negra.

-

Tipo de prueba: grupo de actividades de prueba dirigidas a probar un componente o sistema centrado en un objetivo de prueba específico.

-

Transición de estados: transición entre estados de un componente o sistema.

-

Usabilidad: capacidad del software de ser entendido, aprendido y usado y de ser atractivo al usuario cuando se usa bajo las condiciones especificadas.

-

Validación: confirmación por el examen y a través de la provisión de evidencia objetiva que los requisitos para un uso específico o aplicación se han cumplido.

-

Validez: se refiere a si la métrica realmente mide lo que se pretende medir, es decir, hasta qué punto la medida empírica refleja el significado real del elemento que estamos considerando. El hecho de que una medida sea fiable no implica que sea válida y viceversa

-

Valor frontera: un valor de entrada o salida que está en el borde de una partición de equivalencia o a ambos lados de un límite a la menor distancia posible, por ejemplo el mínimo y el máximo valor de un rango.

-

Verificación: confirmación por examen y a través de la provisión de evidencia objetiva que los requisitos específicos se cumplen.

-

Walkthrough: presentación paso a paso por el autor de un documento para reunir información y para establecer un entendimiento común de su contenido.

Guía de mejores prácticas de calidad de producto

185

Instituto Nacional de Tecnologías de la Comunicación

8.

BIBLIOGRAFÍA

Alexander, Christopher, y al. A,”A pattern language”, (1997) Alexander, Ian, Neil Maiden, y al., “Scenarios, Stories, Use Cases Through the Systems Development Life-Cycle”, (2004) Alexander, Ian, y Richard Stevens, “Writing Better Requirements”, (2002) Andrea Golze, Charlie Li y Shel Prince, “Optimize Quality for Business Outcomes - A practical approach to software testing” (2005) Beizer, B., “Software Testing Techniques”, Segunda edición, (1990) Black, R., “Managing the Testing Process”, Segunda edición, (2001) Boehm, Barry, “Software Risk Management”, (1989) Brian Hambling, Peter Morgan, Angelina Samaroo, Geoff Thompson y Peter Williams, “Software Testing - An ISEB Foundation” (2007) Buwalda, H., Janssen, D. y Pinkster, “Integrated Test Design and Automation”, (2001) Dorothy Graham, Erik Van Veenendaal, Isabel Evans y Rex Black, “Foundations of Software Testing - ISTQB® Certification” (2007) Fenton, B.E., and S.L. Pfleeger, “Software Metrics: A Rigorous Approach”, Segunda edición, (1997) Ferdinandi, Patricia A. “ Requirements Pattern: Succeding in the Internet Economy”, (2002) Gause, Donald, y Gerald Weinberg, “Exploring Requirements: Quality Before Design”, (1989) Gilb, T. y Graham, “Software Inspection”, (1997) Grady, R.B., and D.L. Caswell, “Software Metrics: Establising a Company-Wide Program”, (1986) Heztzel, B., “Making Software Measurement Work: Bulding an Effective measurement Program”, (1993) Hetzel, W., “The Complete Guide to Software Testing”, Segunda edición, (1988) Hull, Elizabeth, Ken Jackson, y Jeremy Dick, “Requirements Engineering”, Segunda edición, (2005) IEEE Standard for Software Test Documentation, IEEE 829 ISO/IEC Software Process Assessment – Part 2: A model for process management (Standard SPICE) Jackson y Michael, “Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices”, (1996) Jackson y Michael, “Problem Frame: Analyzing and Structuring Software Development Problems”, (2001)

Guía de mejores prácticas de calidad de producto

186

Instituto Nacional de Tecnologías de la Comunicación

Jones, Capers, “Assessment and Control of Software Risks”, (1994) Jones, C., “Applied Software Measurement, Assuring Productivity and Quality”, Segunda edición , (1997) Jones, C., “Software Assessments, benchmarks, and Best Practices”, (2000) Kaner, C., bach, J. y Pettricord, “Lessons Learned in Software Testing”, (2002) Lawrence-Pfleeger y Shari, ”Software Engineering: Theory and Practice”, (1998) Layman, B., B.Curtis, J. Puffer, y C. Webet, “Solving the Challenge of quantitative Management”, (2002) Leffing, Dean, y don Widrig, “Managing Software Requirements: A Use Case Approach”, Segunda edición, (2003) Loshing, D., “Enterprise Knowledge Management: The Date of Quality Approach”, (2001) Mary Beth Chrissis, Mike Konrad y Sandy Shrum, “CMMI® Second Edition. Guidelines for Process Integration and Product Improvement” (2007) McGarry, J., D.Card, C.Jones, B.Layman, e.Clark, J.Dean, y F.Hall “Practical Software Measurement, Objective Information for Decision Makers”, (2001) Myers, G.J., “The Art of Software Testing”, (2001) Myers, Glenford, Corey Sandler y al., “The Art of Software Testing”, Segunda edición, (2004) National Institute of Science and Technology (NIST), (2002) Ohno, Taïchi,” The Toyota Production System” Pardee, William J., “To Satisfy and Delight Your Customer”, (1996) Sommerville, Ian and Pete Sawyer, “Requirements Engineering: A Good practice Guide”, (1998) Stephen H. Kan “Metrics and models in Software Quality Engineering “, Segunda edición (2003) Standish Group International, Inc. CHAOS Report Suzanne Robertson y James Robertson, “Mastering the Requirements Process”, Segunda edición (2006) Tockey, Steve, “Return on Software: Maximizing the Return on Your Software Investment”, (2004) Weigers, Karl, “Software Requirements”, Segunda edición, (2003)

Guía de mejores prácticas de calidad de producto

187

Instituto Nacional de Tecnologías de la Comunicación

Enlaces http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Def ault.aspx - What is the Balanced scorecard? http://bi.abast.es/dashboards.shtml - Cuadros de mando (Dashboards y Scorecards) http://www.carnegiequality.com/ - Carnegie Quality- Tools, Tips and Templates for Quality Software. http://www.coursework4you.co.uk/balanced_scorecard.htm - Balanced scorecard http://www.dundas.com/Dashboards/BestPractices3.aspx - Best Practices for Building Digital Dashboards. http://www.jiludwig.com/Template_Guidance.html - Requirements Document Templates http://www.psmsc.com/ - Practical Software and Systems Measurement http://www.psmsc.com/Downloads/Other/Implementing_a_SuccessfulMeasurementProgram. pdf - Implementing a Successful Measurement Program: Tried and True Practices and Tools. http://www.qadownloads.com/Templates/ - Software Testing Tools Resources – Quality Assurance Downloads http://www.softwaremetrics.com/ - Software Metrics http://www.testinggeek.com/ - Software Testing http://www.totalmetrics.com/ - Total Metrics http://www.vanilla-accounting.com/blog/archives/000056.php - The Accounting Blog – Key Performance Indicators http://www.visitask.com/balanced-scorecard.asp - Balanced scorecard, Indicator, Balanced Scorecard, Performance Management. http://www.visitask.com/Developing-key-performance-indicators.asp-Developing performance indicators in projects.

key

http://www.visitask.com/key-performance-indicators.asp - Using key performance indicators (KPI) for effective project management.

Guía de mejores prácticas de calidad de producto

188