10 midiendo la calidad del software
Post on 03-Jun-2015
5.841 Views
Preview:
TRANSCRIPT
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
top related