Midiendo la Calidad del Software

Ingeniería de Software II

Antecedentes Históricamente las métricas de calidad

del software eran medidas por sus opuestos, es decir, por la frecuencia en defectos o errores en el software

La inferencia de esto era la calidad del software o la ausencia de errores

Por ejemplo, se medía la densidad de error en mil líneas de código descubiertos por año o por versión liberada

Antecedentes Valores menores en esta medida

implicaban una mejor calidad en el desarrollo o liberación

Comenzaremos revisando algunos de los principales modelos históricos de calidad para establecer el estado de arte en las métricas de software actuales y poner las bases para construir un conjunto de métricas robustas para la arquitectura de software

Arquitectura de Software De manera abstracta, la arquitectura

de software involucra la descripción de elementos para la construcción de un sistema, las interacciones entre estos elementos, patrones que guían su composición y las restricciones de esos patrones.

Medidas clásicas de software La calidad del software es un concepto

multi dimensional Los múltiples puntos de vista en la

calidad de un producto pueden ser muy diferentes desde el punto de vista popular o no especializado

Más aún, hay niveles de abstracción que rebasan el punto de vista de un usuario o desarrollador

Medidas clásicas del software

Sin embargo, muy pocos usuarios finales estarán de acuerdo en qué un programa que implemente a la perfección la especificación dada es un producto de calidad.

Por supuesto que, cuando hablamos de arquitectura de software, estamos hablando de una etapa de diseño mucho más elevada que la especificación del programa

Administración de Calidad Total

Se acuñó este término en 1985 para describir la aproximación a la mejora de calidad, establecida después de la aproximación japonesa a la mejora en la calidad

TQM Llamada TQM por sus siglas en inglés

(Total Quality Management) se basa en las enseñanzas de gurús como Philip Crosby, Edwards Deming, Armand Feigenbaum, Kaoru Ishikawa y Joseph Juran

De manera simple, es la aproximación de la administración exitosa a largo plazo que es obtenida mediante el apego y el enfoque a la satisfacción del cliente

TQM El estándar ISO 9000 es el legado de

TQM La implementación del TQM tiene

muchas variaciones, pero son cuatro sus características esenciales

1. Enfoque en el cliente2. Mejora en el proceso3. Cultura de calidad4. Medición análisis

Enfoque en el cliente

El objetivo es lograr la satisfacción total del cliente (o deleitar al cliente).

Esto incluye estudiar las necesidades y deseos del cliente, recabar requerimientos del cliente y medir la satisfacción del mismo

Mejora en el proceso

El objetivo es reducir las variaciones del proceso alcanzar la mejora continua del mismo tanto para el negocio como para el desarrollo del producto

Cultura de calidad

El objetivo es crear una organización con una amplia cultura de calidad, incluyendo el liderazgo, el compromiso de la administración, la total participación del personal y otorgar poder al empleado

Medición y análisis

El objetivo es llevar una mejora continua en todos los parámetros de calidad mediante sistemas de medidas orientados a metas

TQM

Este modelo hizo una enorme contribución al desarrollo de software de aplicación empresarial en la década de 1990

Métricas genéricas de calidad

Metodología de métricas: En 1993 la IEEE publicó un estándar para la metodología de métricas de calidad de software que desde entonces ha definido y liderado el desarrollo en el campo

Aquí se muestra una introducción a este estándar

Métricas genéricas de calidad

Su propósito es ser una aproximación más sistemática para establecer los requerimientos de calidad e identificar, implementar, analizar validar las métricas de calidad del software para el desarrollo de éstos sistemas

Este dividía el ciclo de desarrollo en cinco pasos:

Métricas genéricas de calidad

1. Establecer los requerimientos de calidad del softw.

2. Identificar las métricas de calidad3. Implementar las métricas de

calidad4. Analizar los resultados de éstas5. Validar las métricas

Métricas genéricas de calidad En la primera etapa es importante

establecer métricas directas con valores como metas numéricas a cumplirse con el producto final

Los factores a medirse pueden variar de producto en producto, pero es crítico asignar rango a cada factor según su prioridad y asignar un valor métrico directo como requerimiento cuantitativo

Métricas genéricas de calidad

El segundo paso es identificar las métricas descomponiendo cada factor en subfactores y estos en métricas

Por ejemplo, una métrica directa final para el factor confiabilidad podría ser las fallas dentro de 1000 líneas de código (KLOC) con un valor meta de una falla por cada 1000 líneas de código (six sigma tiene este nivel de calidad como 3.4 fallas por un millón de líneas de código)

Métricas genéricas de calidad

Por cada métrica validada se debe asignar un valor que será el valor meta a lograr durante el desarrollo

La siguiente tabla muestra la sugerencia de la IEEE para la descripción de métricas

Término DescripciónNombre Nombre de la métrica

Métrica Funciones matemáticas para calcular la métrica

Costo Costo por usar la métrica

Beneficio Beneficio de usar la métrica

Impacto ¿Puede la métrica ser usada para alterar o detener el proyecto?

Valor meta Valor numérico a ser alcanzado para cumplir la meta

Factores Factores relacionados con la métrica

Herramientas Herramientas para obtener los datos, calcular la métrica y analizar los resultados

Término DescripciónAplicación Cómo será usada la métrica

Elementos de datos Los valores de entrada necesarios para calcular la métrica

Computación Pasos involucrados en el cálculo

Interpretación Cómo interpretar el resultado del cálculo

Consideraciones Suposiciones respecto a la métrica y apropiaciones

Entrenamiento Entrenamiento requerido para aplicar la métrica

Ejemplo Un ejemplo de la aplicación de la métrica

Historia Proyectos que han usado esta métrica y su historia de validación

Referencia Lista de proyectos usados, detalles de proyectos, etc

Métricas dentro del proceso para probar software Hasta recientemente la mayoría de

las métricas de calidad del software eran de naturaleza interna al proceso

Esto es, estaban diseñadas para rastrear ocurrencias de defectos durante la prueba formal en máquina

A continuación se enumeran brevemente por su importancia histórica

Rango de defectos durante la prueba formal

Esta altamente correlacionado con el rango de defectos futuros en campo debido a los defectos en mayor cantidad de los esperado durante las pruebas, lo cual normalmente indica un software complejo o problemas en especial durante el desarrollo

Rango de defectos durante la prueba formal

Aunque parezca poco intuitivo, la experiencia muestra que un alto rango en defectos durante las pruebas indican alto rango en defectos posteriormente en el uso

Si esto ocurre, el administrador de desarrollos tendrá que plantear escenarios de “control de daños”

Densidad de defectos en general durante pruebas Es un indicador muy genérico el patrón de

ocurrencias de defectos o “tiempo principal entre errores” es una métrica más sensible.

Naturalmente la organización del desarrollo no puede arreglar todos los problemas inmediatamente, por lo que se necesita un registro de defectos acumulados

Esta métrica se vuelve no solo una medida de calidad sino que también ayuda a predecir problemas

Eliminación de defectos por fases Usa la métrica de efectividad en

eliminación de defectos. Esto es, simplemente, la cantidad de errores eliminados durante cada fase de desarrollo dividido entre los defectos latentes en el producto, multiplicado por 100 para obtener el porcentaje

Esta métrica se recomienda usarse antes de la integración de código y en cada fase subsiguiente

Eliminación de defectos por fases

Debido a que el número de errores latentes aun es desconocido en esta etapa, se estima como los defectos eliminados durante la fase más los defectos encontrados después

Métricas más recientes Se introducen cuatro métricas nuevas

para medir la calidad una vez que se ha entregado el software:

1. Arreglar el registro de fallas acumuladas y la administración del índice del registro de fallas acumuladas

2. Arreglar el tiempo de respuesta3. Porcentaje de arreglos morosos4. Calidad en los arreglos (es decir, ¿si se

arreglaron los problemas?)

Métricas más recientes Estas métricas no son complejas El índice de administración del registro de

fallas acumuladas es multiplicar por 100 el número de problemas registrados durante el mes dividido entre el número de problemas solucionados durante el mes

El tiempo de respuesta es el tiempo que tardan todos los problemas desde que se registran hasta que se solucionan

Métricas más recientes

Si un problema tarda demasiado en solucionarse, más allá del tiempo estándar, entonces se declara moroso

El porcentaje de arreglos morosos es 100 veces el número de arreglos que no se solucionaron a tiempo dividido entre el número de arreglos que se solucionaron a tiempo

Métricas más recientes

La calidad en el arreglo tradicionalmente se mide negativamente como falta de calidad. Es el número de defectos arreglados menos aquellos arreglos que no funcionaron apropiadamente o peor, que ocasionaron otros problemas