Calidad

1. Calidad MBA Juan Pablo Salazar F. INFO 265 - 2004

2. ¿Qué es la Calidad? • Clásicamente, se refiere a cumplimiento de las especificaciones. • Es reconocida como un arma competitiva clave (ventaja diferenciadora). • La globalización transforma a las certificaciones de calidad en una necesidad.

3. Cuadro comparativo ISO 9000-ISO 14000

4. Problemas de calidad en sistemas de software • El software es un producto mental, no restringido por las leyes de la Física o por los límites de los procesos de fabricación. Es algo abstracto, y su calidad también lo es. • Se desarrolla, no se fabrica. El coste está fundamentalmente en el proceso de diseño, no en la producción. Y los errores se introducen también en el diseño, no en la producción. • El software no se deteriora con el tiempo. No es susceptible a los efectos del entorno, y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban allí desde el principio, y afectan a todas las copias del mismo; no se generan nuevos errores.

5. Problemas de calidad en sistemas de software • Es engañosamente fácil realizar cambios sobre un producto software, pero los efectos de estos cambios se pueden propagar de forma explosiva e incontrolada. • Como disciplina, el desarrollo de software es aún muy joven, por lo que las técnicas de las que disponemos aún no son totalmente efectivas o no están totalmente calibradas. • El software con errores no se rechaza. Se asume que es inevitable que el software presente errores. • No se sabe cómo especificar ciertas características de calidad (ejm: mantenibilidad) de forma no ambigua. • Es muy difícil redactar especificaciones concretas de software.

6. Problemas de calidad en sistemas de software • El software, en su mayoría, se construye a medida, con métodos que serían considerados artesanales por otras ingenierías. • Existen aspectos intangibles de la calidad que no se encuentran incluidos en los estándares (elegancia, transparencia, etc.).

7. Administración de la Calidad • Aseguramiento de la calidad (QA): Establecimiento de un marco de trabajo de procedimientos y estándares organizacionales. • Planeación de la calidad: Selección de procedimientos y estándares adecuados a partir de este marco de trabajo y su adaptación a un proyecto específico. • Control de la calidad: Definición y promulgación de los procesos que aseguran que los procedimientos y estándares definidos son seguidos por el equipo de desarrollo. La administración de la calidad debiese estar separada de la administración de proyectos de software.

8. Administración de la Calidad La administración de la calidad debiese estar separada de la administración de proyectos de software.

9. ISO 9000 y Adm. de la Calidad

10. Estándares de Calidad - Importancia • Proveen conjunto de mejores prácticas que evita la repetición de errores anteriores. • Asegura que todos los ingenieros dentro de una organización adopten las mismas prácticas. Reduce el esfuerzo de aprendizaje.

11. Estándares de Calidad • Estándares de Producto: • Estándares de documentos (ejm: estructura del documento de requerimientos) • Estándares de codificación. • Formato de petición de cambios. • Estándares de Proceso: • Definición de los procesos de especificación, diseño y validación. • Procedimiento de entrega de las versiones. • Proceso de control de cambios.

12. Estándares de Documentación • Estándares de proceso. • Etapas que se deben seguir para producir un documento de calidad. • Estándares del documento. • Estándares de identificación de documentos. • Estándares de estructura del documento. • Estándares de presentación del documento. • Estándares para actualizar los documentos.

13. Estándares de Proceso - Ejemplo

14. Estándares de documentación – Ejemplos • Estándares de Identificación: • AA-BB-CCCC-vDD, donde: • AA: Identificación del cliente • BB: Identificación de la etapa del proyecto. • CCCC: Número de proyecto. • DD: Versión • Ejm: PL-PP-0068-V1: Propuesta para Paperless, proyecto Número 68, versión 1.

15. Estándares de documentación – Ejemplos • Estándares para actualizar documentos:

16. Calidad de producto y proceso • Existe relación bastante directa entre la calidad del proceso y la calidad de los productos a entregar. • Es importante que exista adecuada sintonía entre el proceso escogido y el tipo de software a desarrollar. Ejm: Un software que requiere desarrollo de prototipos & un proceso que requiere una especificación completa y aprobada antes de comenzar la construcción.

17. Planeación de la calidad. • Definir la calidad implica dar una valoración a cada uno de los atributos que especifica la calidad de un producto. • Debe seleccionarse sólo aquellos más importantes.

18. Planeación de la Calidad • Estructura de un plan de calidad: • Introducción del producto, mercado objetivo, expectativas de calidad. • Planes del producto (hitos, fechas, responsables). • Descripción del proceso. • Metas de calidad. Incluye identificación y justificación de los atributos de calidad importantes del producto. • Riesgos y administración de los mismos.

19. Modelo de McCall

20. Modelo de McCall • A partir de los 11 factores, se desprenden 23 criterios y 41 métricas de tipo subjetivo (no las veremos en detalle). • Se utiliza un cuestionario con respuestas SI/NO y se obtiene una valoración de la calidad a partir de éstas. • El modelo propone asociar a cada criterio una fórmula de regresión del tipo: • CC = r1 m1 + r2 m2 + ... + rn mn • (rj son los coeficientes de regresión y mj corresponden a las distintas métricas asociadas al criterio).

21. Métricas (ejemplo). • Fiabilidad = 1 - (número de errores/ número de líneas de código) • Facilidad de mantenimiento = 1 - 0.1 (número medio de días-hombre por • corrección) • Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar) • Flexibilidad = 1 - 0.05 (número medio de días-hombre por cambio)

22. Control de Calidad • El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no posee una determinada característica de calidad en el grado requerido. Cuando un producto no posee una determinada característica de calidad se dice que tiene un DEFECTO. Por lo tanto, se puede decir también que el objetivo del Control de Calidad es identificar defectos en el producto y corregirlos.

23. Controles estáticos

24. Controles estáticosmanuales disciplinados • Auditorías: • Objetivos: • El grado de cumplimiento y la adecuación de los procedimientos, instrucciones, especificaciones, códigos, estándares u otros requisitos de tipo contractual establecidos y aplicables. • La efectividad y adecuación de la implementación realizada. • Tipos de auditorías: • Auditoría de producto. • Auditoría de proceso (de proyecto y de gestión de proyecto). • Auditoría del sistema de calidad.

25. Procedimiento de una auditoría • Planificación (definir objetivos y alcance). • ¿Por qué se realiza la auditoría? ¿Para qué? • ¿Qué producto se auditará? • ¿Qué resultados se esperan? • ¿Cómo y dónde serán utilizados los resultados de la auditoría? • ¿Quiénes son los responsables de realizarla? ¿De qué forma se llevará a cabo? ¿Cuándo? • Desarrollo de la investigación.

26. Procedimiento de una auditoría • Análisis de los datos recogidos. • Importancia de seleccionar información relevante. • Importancia de comparar diferentes perspectivas. • Sugerir soluciones a los problemas y posibles mejoras. • Elaborar y presentar informe con resultados.

27. Controles estáticos automáticos. • Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de programas. • La mayor parte del análisis estático automático del código lo realizan los compiladores, que pueden detectar desde expresiones sintácticamente incorrectas hasta incompatibilidades de tipo y otros errores de tipo semántico.

28. Controles estáticos automáticos. • Análisis de Flujo. • Ejecución simbólica. Consiste en la ejecución simbólica de ciertos caminos dentro del programa, durante la cual se verifican ciertas expresiones simbólicas con respecto a ciertas condiciones y afirmaciones preestablecidas. • Verificación Formal. Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus especificaciones.

29. Controles Dinámicos. • Se llama controles dinámicos a aquellos que requieren la ejecución del objeto que se está probando o de un modelo del mismo. • Hasta la fecha no se ha desarrollado ninguna teoría universalmente aceptada acerca de la prueba de software. Lo único que hay es un conjunto de aproximaciones metodológicas que facilitan y hacen más eficiente el proceso de prueba. • Es muy importante seleccionar bien las pruebas que se van a realizar, teniendo en cuenta que sólo las pruebas que revelan defectos son las que realmente merecen la pena.

30. Pruebas • Prueba Modular: Prueba de cada módulo aislado del resto del sistema. • Prueba de Integración: El objetivo es comprobar que las interfaces entre los distintos módulos son correctas. • Prueba del sistema: Su objetivo es comprobar que el sistema satisface los requisitos del usuario, tanto los funcionales como los no funcionales. • Prueba de aceptación: Se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus necesidades.

31. Métodos de prueba • Método de caja negra: La elección de los casos de prueba no se va a basar en el conocimiento que se tenga acerca de la estructura del objeto, sino en el conocimiento acerca de la funcionalidad deseada (descripción funcional). • Método de caja blanca: La elección de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto (diseño detallado, diagramas de flujo de datos y de control, código fuente).

32. CMM- Capability Maturity Model • Es un modelo de referencia cuyo objetivo es ayudar a las organizaciones a mejorar sus procesos de desarrollo de software de una manera evolutiva. • Preguntas clave: • ¿Cuánto tiempo toma? ¿Cuánto cuesta? • ¿Es CMM el marco apropiado para medir y mejorar el desarrollo de software en las organizaciones? http://www.sei.cmu.edu/cmm/cmms/cmms.html

33. CMM- Capability Maturity Model

34. CMM- Capability Maturity Model

35. CMM- Capability Maturity Model

36. Existe preocupación a nivel empresa por capacitación, estándares y software compatible Relación CMM – Calidad de la Información Existe un plan y desarrollo de proyectos informáticos se asemeja a línea de montaje Existe preocupación por mejora continua de procesos y resultados. Feedback Proceso no es importante, sólo satisfacer el requerimiento Existe algún plan que incluye documentación y control de calidad Cada cual maneja sus propios datos por separado Existe acceso a los datos, pero no seguridad respecto de su significado Datos necesitan algún proceso para ser integrados con otros, no es directo Datos y estructura de éstos a nivel corporativo

37. CMM- Capability Maturity Model • Empresas certificadas en Chile (abr-2003): • Citibank en Nivel 3 • América XXI en Nivel 3 • Altec en Nivel 3 (del Banco Santander) • Link en Nivel 3 • Kepler en Nivel 2 • Sonda en Nivel 2 • Lan Chile en Nivel 2 • Motorola Santiago estaba en Nivel 3, pero el centro se disolvió hace unos dos años. http://www.sei.cmu.edu/cmm/cmms/cmms.html

38. CMM- Capability Maturity Model • Agenda Digital del Gobierno (punto 26): • Instrumentos de gobierno para fomentar la certificación ISO 9001 y CMM (Corfo). • Tipos de evaluaciones: • Formales (entregan certificación). • Informales (entregan información y permiten elaborar programas de mejora continua). • Consultoras que se dedican en Chile a realizar evaluaciones o certificaciones CMM: • América XXI (http://www.americaxxi.cl) • Practia (http://www.practia.cl) • Testgroup (http://www.testgroup.cl)