1.
Midiendo la Calidad del Software Ingeniería de Software II

2.
Antecedentes <ul><li>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 </li></ul><ul><li>La inferencia de esto era la calidad del software o la ausencia de errores </li></ul><ul><li>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 </li></ul>

3.
Antecedentes <ul><li>Valores menores en esta medida implicaban una mejor calidad en el desarrollo o liberación </li></ul><ul><li>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 </li></ul>

4.
Arquitectura de Software <ul><li>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. </li></ul>

5.
Medidas clásicas de software <ul><li>La calidad del software es un concepto multi dimensional </li></ul><ul><li>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 </li></ul><ul><li>Más aún, hay niveles de abstracción que rebasan el punto de vista de un usuario o desarrollador </li></ul>

6.
Medidas clásicas del software <ul><li>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. </li></ul><ul><li>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 </li></ul>

7.
Administración de Calidad Total <ul><li>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 </li></ul>

8.
TQM <ul><li>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 </li></ul><ul><li>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 </li></ul>

9.
TQM <ul><li>El estándar ISO 9000 es el legado de TQM </li></ul><ul><li>La implementación del TQM tiene muchas variaciones, pero son cuatro sus características esenciales </li></ul><ul><ul><li>Enfoque en el cliente </li></ul></ul><ul><ul><li>Mejora en el proceso </li></ul></ul><ul><ul><li>Cultura de calidad </li></ul></ul><ul><ul><li>Medición análisis </li></ul></ul>

10.
Enfoque en el cliente <ul><li>El objetivo es lograr la satisfacción total del cliente (o deleitar al cliente). </li></ul><ul><li>Esto incluye estudiar las necesidades y deseos del cliente, recabar requerimientos del cliente y medir la satisfacción del mismo </li></ul>

11.
Mejora en el proceso <ul><li>El objetivo es reducir las variaciones del proceso alcanzar la mejora continua del mismo tanto para el negocio como para el desarrollo del producto </li></ul>

12.
Cultura de calidad <ul><li>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 </li></ul>

13.
Medición y análisis <ul><li>El objetivo es llevar una mejora continua en todos los parámetros de calidad mediante sistemas de medidas orientados a metas </li></ul>

14.
TQM <ul><li>Este modelo hizo una enorme contribución al desarrollo de software de aplicación empresarial en la década de 1990 </li></ul>

15.
Métricas genéricas de calidad <ul><li>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 </li></ul><ul><li>Aquí se muestra una introducción a este estándar </li></ul>

16.
Métricas genéricas de calidad <ul><li>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 </li></ul><ul><li>Este dividía el ciclo de desarrollo en cinco pasos: </li></ul>

17.
Métricas genéricas de calidad <ul><li>Establecer los requerimientos de calidad del softw. </li></ul><ul><li>Identificar las métricas de calidad </li></ul><ul><li>Implementar las métricas de calidad </li></ul><ul><li>Analizar los resultados de éstas </li></ul><ul><li>Validar las métricas </li></ul>

18.
Métricas genéricas de calidad <ul><li>En la primera etapa es importante establecer métricas directas con valores como metas numéricas a cumplirse con el producto final </li></ul><ul><li>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 </li></ul>

19.
Métricas genéricas de calidad <ul><li>El segundo paso es identificar las métricas descomponiendo cada factor en subfactores y estos en métricas </li></ul><ul><li>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) </li></ul>

20.
Métricas genéricas de calidad <ul><li>Por cada métrica validada se debe asignar un valor que será el valor meta a lograr durante el desarrollo </li></ul><ul><li>La siguiente tabla muestra la sugerencia de la IEEE para la descripción de métricas </li></ul>

21.
Herramientas para obtener los datos, calcular la métrica y analizar los resultados Herramientas Factores relacionados con la métrica Factores Valor numérico a ser alcanzado para cumplir la meta Valor meta ¿Puede la métrica ser usada para alterar o detener el proyecto? Impacto Beneficio de usar la métrica Beneficio Costo por usar la métrica Costo Funciones matemáticas para calcular la métrica Métrica Nombre de la métrica Nombre Descripción Término

22.
Proyectos que han usado esta métrica y su historia de validación Historia Un ejemplo de la aplicación de la métrica Ejemplo Entrenamiento requerido para aplicar la métrica Entrenamiento Lista de proyectos usados, detalles de proyectos, etc Referencia Suposiciones respecto a la métrica y apropiaciones Consideraciones Cómo interpretar el resultado del cálculo Interpretación Pasos involucrados en el cálculo Computación Los valores de entrada necesarios para calcular la métrica Elementos de datos Cómo será usada la métrica Aplicación Descripción Término

23.
Métricas dentro del proceso para probar software <ul><li>Hasta recientemente la mayoría de las métricas de calidad del software eran de naturaleza interna al proceso </li></ul><ul><li>Esto es, estaban diseñadas para rastrear ocurrencias de defectos durante la prueba formal en máquina </li></ul><ul><li>A continuación se enumeran brevemente por su importancia histórica </li></ul>

24.
Rango de defectos durante la prueba formal <ul><li>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 </li></ul>

25.
Rango de defectos durante la prueba formal <ul><li>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 </li></ul><ul><li>Si esto ocurre, el administrador de desarrollos tendrá que plantear escenarios de “control de daños” </li></ul>

26.
Densidad de defectos en general durante pruebas <ul><li>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. </li></ul><ul><li>Naturalmente la organización del desarrollo no puede arreglar todos los problemas inmediatamente, por lo que se necesita un registro de defectos acumulados </li></ul><ul><li>Esta métrica se vuelve no solo una medida de calidad sino que también ayuda a predecir problemas </li></ul>

27.
Eliminación de defectos por fases <ul><li>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 </li></ul><ul><li>Esta métrica se recomienda usarse antes de la integración de código y en cada fase subsiguiente </li></ul>

28.
Eliminación de defectos por fases <ul><li>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 </li></ul>

29.
Métricas más recientes <ul><li>Se introducen cuatro métricas nuevas para medir la calidad una vez que se ha entregado el software: </li></ul><ul><ul><li>Arreglar el registro de fallas acumuladas y la administración del índice del registro de fallas acumuladas </li></ul></ul><ul><ul><li>Arreglar el tiempo de respuesta </li></ul></ul><ul><ul><li>Porcentaje de arreglos morosos </li></ul></ul><ul><ul><li>Calidad en los arreglos (es decir, ¿si se arreglaron los problemas?) </li></ul></ul>

30.
Métricas más recientes <ul><li>Estas métricas no son complejas </li></ul><ul><li>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 </li></ul><ul><li>El tiempo de respuesta es el tiempo que tardan todos los problemas desde que se registran hasta que se solucionan </li></ul>

31.
Métricas más recientes <ul><li>Si un problema tarda demasiado en solucionarse, más allá del tiempo estándar, entonces se declara moroso </li></ul><ul><li>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 </li></ul>

32.
Métricas más recientes <ul><li>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 </li></ul>