Gestión de la calidad 1
Administración de Proyectos Informáticos
Tema 5 (I)GESTIÓN DE LA CALIDADGESTIÓN DE LA CALIDAD
1. Concepto de calidad2. Definición de calidad del software3. Aspectos de la gestión de calidad4. Ámbitos de la gestión de calidad
4.1. Calidad a nivel de la organización4.2. Calidad a nivel del proyecto
5. Marco normativo5.1. Estándares ISO 90005.2. Estándares ISO 9000:20005.3. Estándares IEEE
6. Actividades de aseguramiento de la calidad7. Evaluación de la calidad
7.1. Modelos de calidad del software7.2. Fiabilidad del software7.3. Revisiones
8. Métricas de calidad
Gestión de la calidad 2
Administración de Proyectos Informáticos
1. Concepto de calidad1. Concepto de calidad
Definiciones de calidad:Propiedad o conjunto de propiedades inherentes a una cosa, que permiten apreciarla como igual, mejor o peor que las restantes de su especie (Diccionario de la Real Academia Española).
Totalidad de las características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implícitas (Norma UNE 66-001-92 traducción de ISO 8402) [AENOR, 1992].
La consecución de la calidad puede tener tres orígenes:– Calidad realizada: la que es capaz de obtener la persona que
realiza el trabajo.– Calidad programada: La calidad que se ha pretendido
obtener.– Calidad necesaria: La calidad que el cliente exige con
mayor o menor grado de concreción
CALIDADPROGRAMADA
CALIDADNECESARIA
CALIDAD REALIZADA
Figura 1. Los orígenes de la calidad
Gestión de la calidad 3
Administración de Proyectos Informáticos
2. Definición de calidad del software2. Definición de calidad del software
Definiciones de calidad del software:Grado con el que un sistema, componente o proceso cumple:
– Los requisitos especificados– Las necesidades o expectativas del cliente o usuario.(IEEE Std. 610-1990) [IEEE, 1993].
Concordancia del software producido 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 [Pressman, 1998].
Los requisitos establecidos explícitamente se reflejan en el documento de especificación de requisitos del sistema (ERS):
– Requisitos funcionales: funciones a realizar por el software.– Requisitos no funcionales o extendidos: requisitos de
seguridad, rendimiento, interfaz...
Los estándares y las normas de desarrollo permiten que se consiga una calidad técnica.Los requisitos implícitos no aparecen en la ERS. Si se cumplen los requisitos explícitos, pero no se alcanzan los implícitos, la calidad del software queda en entredicho.
Gestión de la calidad 4
Administración de Proyectos Informáticos
3. Aspectos de la gestión de calidad3. Aspectos de la gestión de calidad
Gestión de la calidad del software: Aspecto de la función general de la gestión que determina y aplica la política de calidad [AENOR, 1992].
Aseguramiento (garantía) de calidad del software:Conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto satisfará los requisitos dados de calidad [AENOR, 1992].Conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el producto. [IEEE, 1990].
Control de calidad del software:Técnicas y actividades de carácter operativo utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: mantener bajo control un proceso y eliminar las causas de defectos en las diferentes fases del ciclo de vida [AENOR, 1992].Proceso de verificar el propio trabajo o el de un compañero. [IEEE, 1990].
Verificación y validación:– Verificación. Comprobar si los productos construidos en
una fase del ciclo de vida satisfacen los requisitos establecidos en la fase anterior.
– Validación: Comprobar si el software construido satisface los requisitos de usuario.
Gestión de la calidad 5
Administración de Proyectos Informáticos
4. Ámbitos de la gestión de calidad 4. Ámbitos de la gestión de calidad
El trabajo para la mejora de la calidad tiene dos ámbitos de actuación:– Nivel de empresa/organización– Nivel de proyecto
La gestión de la calidad a nivel de empresa u organización consiste en la creación de una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa.En cada proyecto de desarrollo se deben aplicar las directrices de calidad fijadas a nivel de la organización. Para ello es imprescindible la adaptación de las mismas a las condiciones de cada proyecto.
Figura 2. Relaciones entre los dos ámbitos de la calidad
PgPg.229 Dolado.229 DoladoPlan de calidad adaptado
Plan de calidad del proyecto
Plan de calidad adaptado
Gestión de la calidad 6
Administración de Proyectos Informáticos
Ámbitos de la gestión de calidadÁmbitos de la gestión de calidad4.1. Calidad a nivel de la organización4.1. Calidad a nivel de la organización
Para la implantación de una infraestructura de calidad es necesario el apoyo de un sistema de calidad: Estructura de organización, de responsabilidades, de actividades, de recursos y de procedimientos que se establecen para llevar a cabo la gestión de calidad (ISO-9000/UNE 66-900) [AENOR, 1992].
El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa.
Un sistema de calidad consta de dos partes:
– Documentación en la que se describe el sistema, procedimientos, etc. ajustándose a una norma:
» Manual de calidad. Descripción del sistema que sirve de referencia permanente en la aplicación del sistema.
» Procedimientos de calidad. Instrucciones específicas para ciertas actividades o procesos.
» Registros de datos sobre calidad. Almacenamiento de información sobre actividades relacionadas con la calidad.
– Parte práctica, que tiene dos vertientes:» Aspectos físicos» Aspectos humanos.
Gestión de la calidad 7
Administración de Proyectos Informáticos
Ámbitos de la gestión de calidadÁmbitos de la gestión de calidad4.2. Calidad a nivel del proyecto4.2. Calidad a nivel del proyecto
Para adaptar las directrices marcadas por los sistemas de calidad a cada proyecto particular hay que generar un plan específico de calidad: Plan de aseguramiento de la calidad.
El plan de aseguramiento debe contener:
– Objetivos de calidad del proyecto y enfoque para su consecución
– Documentación referenciada en el plan.– Gestión de aseguramiento de la calidad.– Documentación de desarrollo y de control o gestión.– Estándares, normas y prácticas que hay que cumplir– Actividades de revisión y auditorías– Gestión de la configuración del software– Informes de problemas– Herramientas, técnicas y métodos de apoyo.– Control del código, de los equipos y de los suministradores.– Recogida, mantenimiento y almacenamiento de datos sobre
la documentación de las actividades de aseguramiento de la calidad realizadas.
Gestión de la calidad 8
Administración de Proyectos Informáticos
5. Marco normativo5. Marco normativo5.1. Estándares ISO 90005.1. Estándares ISO 9000
La organización internacional de estándares, ISO, ha producido una serie de estándares para la gestión y aseguramiento de la calidad conocidos colectivamente como ISO 9000.
Se pueden dividir en dos grupos:– Normas para el aseguramiento externo de la calidad.
» ISO 9001: Aseguramiento de la calidad en organizaciones cuyo proceso abarca desde el diseño hasta el servicio posventa.
» ISO 9002: Aseguramiento de la calidad en organizaciones cuya actividad se basa en las fases de producción y de instalación.
» ISO 9003: Aseguramiento de la calidad en organizaciones cuya actividad consiste en inspecciones y ensayos finales.
– Normas para la gestión interna de la calidad.» ISO 9004: Elementos de un sistema de calidad
Guía ISO 9000-3: guía para aplicar ISO 9001 al desarrollo, suministro y mantenimiento de software.– Marco de trabajo de la empresa– Actividades del ciclo de vida– Actividades de apoyo
Gestión de la calidad 9
Administración de Proyectos Informáticos
Marco normativoMarco normativoEstándares ISO 9000Estándares ISO 9000
Las normas de la serie ISO 9000 han sido adoptadas sin modificación como normas europeas (serie EN 29000) y como normas españolas (serie UNE 66-900).La norma UNE 66-907-91 (guía para manuales de calidad) se ha inspirado en la normativa nuclear (norma NFX 50-160:1988.
ISO 9000CONCEPTOS Y DIRECTRICES GENERALES
ISO 9004
GESTIÓN INTERNA DE LA CALIDAD
ISO 9001DISEÑO, PRODUCCIÓN, INSTALACIÓN Y POSVENTA
ISO 9002PRODUCCIÓN, INSTALACIÓN
ISO 9003INSPECCIÓN Y ENSAYOS
FINALES
ASEGURAMIENTO EXTERNO DE LA CALIDAD
UNE 66-907-91
GUÍA PARA MANUALES DE CALIDAD
Figura 3. Normativa ISO 9000
Gestión de la calidad 10
Administración de Proyectos Informáticos
Marco normativoMarco normativo5.2. Estándares ISO 9000:20005.2. Estándares ISO 9000:2000
ISO 9000:2000. Sistemas de gestión de la calidad. Fundamentos y vocabulario)– Define los términos fundamentales y definiciones usadas en
la familia ISO 9000
ISO 9001:2000. Sistemas de gestión de la calidad. Requisitos– Define la auditoría de sistemas de calidad: permite realizar
certificaciones externas de la calidad– Se organiza en las siguientes secciones:
» Responsabilidad de gestión» Gestión de recursos» Realización de productos y/o servicios» Medición, análisis y mejora
ISO 9004:2000. Sistemas de gestión de la calidad. Guías para la mejora del desempeño (performance)– Describe un sistema de calidad que cumple los requisitos
básicos especificados en la norma 9001– Es una guía para las organizaciones que quieren mejorar la
calidad de sus sistemas después de aplicar ISO 9001
Gestión de la calidad 11
Administración de Proyectos Informáticos
Marco normativoMarco normativoEstándares ISO 9000:2000Estándares ISO 9000:2000
ISO/IEC 90003:2004– Guía para la aplicación de ISO 9001:2000 a la adquisición,
suministro, desarrollo, operación y mantenimiento de software servicios de soporte relacionados
– Las directrices recogidas en ISO/IEC 90003:2004 no tienen por objeto su uso como criterio de valoración en la certificación de sistemas de gestión de la calidad, sino que su aplicación es apropiada para software que es parte de un contrato comercial con otra organización:
» Un producto disponible para un sector del mercado » Usado para apoyar los procesos de la organización » Empotrado en un producto hardware » Relacionado con servicios software
– ISO/IEC 90003:2004 identifica todas los aspectos que hay que considerar en los sistema de gestión de calidad de las organizaciones, relacionados o no con el software, siendo independiente de la tecnología, de los modelos de ciclo de vida, de los procesos de desarrollo, de la secuencia de actividades y de la estructura organizativa de la empresa
– Contiene además directrices adicionales y se complementa con estándares de ingeniería del software como ISO/IEC 12207, ISO/IEC TR 9126, ISO/IEC 14598, ISO/IEC 15939 e ISO/IEC TR 15504.
Gestión de la calidad 12
Administración de Proyectos Informáticos
Marco normativoMarco normativo5.3. Estándares IEEE5.3. Estándares IEEE
Los estándares IEEE están orientados al aseguramiento de la calidad a nivel del proyecto:– Std. 730: proporciona la estructura de la documentación del
plan de aseguramiento de la calidad.– Std.1061: definición de métricas para productos y para
procesos, así como procedimientos para la recogida de valores de métricas.
– Existen también estándares para otras actividades relacionadas con la calidad como pruebas, verificación y validación, revisiones, etc. Los principales se recogen en la siguiente tabla.
IEEE 730-2002 Planes de aseguramiento de la calidad del software
IEEE 829-1998 Documentación de pruebas del software
IEEE 982.1, 982.2
Diccionario estándar de medidas para producir software fiable
IEEE 1008-1987 Pruebas de unidad del software
IEEE 1012-1998 Verificación y validación del software
IEEE 1028-1997 Revisiones del software
IEEE 1044-1993 Clasificación estándar para anomalías del software
IEEE 1061-1998 Estándar para una metodología de métricas de calidad del software
IEEE 1228-1994 Planes de seguridad del software
Gestión de la calidad 13
Administración de Proyectos Informáticos
6. Actividades de aseguramiento de la calidad6. Actividades de aseguramiento de la calidad
Establecimiento de un plan para el aseguramiento de la calidad del proyecto:– Se desarrolla durante la planificación del proyecto– Se revisa por todas las partes involucradas
Revisión de la descripción del proceso para asegurar:– Ajuste a la política de la empresa– Cumplimiento de estándares internos y externos
Revisión de las actividades de IS y de los productos:– Seguimiento de las desviaciones– Verificación de la realización de las correcciones
Asegurar la documentación de las desviacionesRegistrar lo que no se ajuste a los requisitosControl y gestión de cambios: – Establecimiento de configuraciones de referencia que
permitan controlar y gestionar los cambios del software de una manera formal.
Recopilación y análisis de métricas: identificación y selección de las métricas de calidad más adecuadas para evaluar tanto la calidad del producto como la calidad del proceso.
Gestión de la calidad 14
Administración de Proyectos Informáticos
7. Evaluación de la calidad7. Evaluación de la calidad7.1. Modelos de calidad del software7.1. Modelos de calidad del software
La resolución del problema de la evaluación se basa en la descomposición del concepto genérico de calidad en propiedades más sencillas de medir y evaluar. Este tipo de descomposición recibe el nombre de modelo de calidad.Los modelos de mayor difusión son los siguientes:– Modelo de Boehm [Boehm et al., 1978]: modelo de
descomposición de características de calidad del software en tres niveles (usos principales, componentes intermedios y componentes primitivos) previos a la aplicación de métricas.
– Modelo factores/criterios/métricas [McCall et al., 1977]: modelo similar al de Boehm en el cual se ha introducido mayor grado de descomposición en cada nivel.
– Marco ISO 9126: este estándar denominado Evaluación de Productos Software: Características de calidad y guías para su uso, la calidad se descompone en seis factores.
– Paradigma GQM (Goal-Question-Metric) Objetivo-pregunta-métrica [Basili y Rombach, 1988]: enfoque de medición para evaluar la calidad del software basado en la identificación de objetivos a lograr.
– Modelo de Gilb [Gilb, 1988]: creación de una especificación de requisitos de calidad para cada proyecto que deben escribir conjuntamente el usuario y el analista.
– Modelo CMM (Capability Maturity Model) : modelo de capacidad de madurez del SEI.
– Modelo SPICE (Software Process Improvement andCapability dEtermination) : modelo de valoración de la arquitectura que define los procesos y prácticas aconsejables.
Gestión de la calidad 15
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo de Modelo de BoehmBoehmLos componentes o constructores del modelo se centran en el producto finalSe identifican características de calidad desde el punto de vista del usuario.
Ingenieríahumana
Fiabilidad
eficiencia
Chequeabilidad
Comprensibilidad
Portabilidad
Modificabilidad
Como es suutilidad
Mantenibilidad
Independencia dispositivo
Completitud
exactitud
Consistencia
Eficiencia Dispositivo
Accesibilidad
Comunicatividad
Estructuración
Autodescriptividad
Concisión
Legibilidad
Expansivilidad
MMÉÉTTRRIICCAASS
Usos Usos PrimariosPrimarios
Utilidadgeneral
CConstructores onstructores intermediosintermedios
CConstructores onstructores primitivosprimitivos
Gestión de la calidad 16
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
ModeloModelo factores/criterios/métricasfactores/criterios/métricas (McCall) Descompone el concepto de calidad en tres usos o capacidades importantes para un producto de software
– Operación– Revisión– Transición
Cada capacidad se descompone en una serie de factoresque determinan la calidad en cada una de ellas.
– Operación: » Facilidad de uso» Integridad» Eficiencia» Corrección o exactitud» Fiabilidad
– Revisión:» Facilidad de prueba» Facilidad de mantenimiento» Flexibilidad
– Transición» Reusabilidad» Portabilidad» Interoperabilidad
Gestión de la calidad 17
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
ModeloModelo factores/criterios/métricasfactores/criterios/métricas (McCall)
Cada factor determinante de la calidad se descompone, a su vez, en una serie de criterios o propiedades que determinan su calidad.Los criterios pueden ser evaluados mediante un conjunto de métricas. Para cada criterio deben fijarse unos valores máximo y mínimo aceptables para cada criterio.
Gestión de la calidad 18
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Marco ISO 9126La calidad se descompone en seis factores:– Funcionalidad– Fiabilidad– Usabilidad– Eficiencia– Mantenibilidad– Portabilidad
Gestión de la calidad 19
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Paradigma GQM (Objetivo-pregunta-métrica)
El enfoque GQM basa la mejora en la definición clara de procesos y productos.Proporciona la estructura para obtener los objetivos cruciales del proyecto. Consta de tres etapas:– Lista de los objetivos principales del desarrollo y
mantenimiento del proyecto. – Para cada objetivo obtener las preguntas que deben
contestarse para saber si se están cumpliendo los objetivos.– Decidir qué medir para poder contestar las preguntas de
forma adecuada.La medidas individuales obtenidas se relacionan para poder ser utilizadas en el contexto del proyecto completo.
OBJETIVO: Evaluar la efectividad del estándar de codificación
PREGUNTAS: ¿Quien está usando el estándar?
¿Cual es la productividad del
codificador?
¿Cual es la calidad del código?
Proporción de codi-ficadores usando:
el estándarel lenguaje
Cantidad de código
Errores...Experiencia de codificadores en:
el estándarel lenguajeel entorno...
Gestión de la calidad 20
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo de GilbDeterminar una lista de características que definen la calidad de la aplicación. Pueden ser de dos tipos– Originales– De los modelos tradicionales
Las características se pueden medir mediante varias subcaracterísticas o métricas detalladas. Para cada una de ellas se debe especificar los siguientes conceptos:– Nombre y definición de la característica– Escala o unidades de medición– Recogida de datos o prueba– El valor previsto– El valor óptimo– El valor en el sistema actual– Comentarios
Este modelo se ha asociado con la filosofía QFD (QualityFunction Deployment) para la gestión de la calidad industrial.El proyecto COQUAMO (Constructive Quality Model) se apoya en el enfoque de Gilb.
Gestión de la calidad 21
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo CMMSW-CMM describe los principios y prácticas que conducen a mejores productos de software.Se agrupan en cinco niveles que proporcionan el camino para mejorar la visibilidad y el control:
– Nivel 1 (Inicial): se definen pocos procesos– Nivel 2 (Repetible): se establecen los procesos de gestión
del proyecto para hacer un seguimiento del coste, de la planificación y de la funcionalidad.
– Nivel 3 (Definido): El proceso del software de las actividades de gestión y de ingeniería se documenta, se estandariza y se integra dentro de un proceso de software de toda una organización.
– Nivel 4 (Gestionado): Se recopilan medidas detalladas del proceso de software y de la calidad del producto.
– Nivel 5 (Optimizado): Mediante un resultado cuantitativo del proceso y de las ideas y tecnologías innovadoras se posibilita una mejora del proceso.
El modelo se puede usar de dos formas:– Por los clientes– Internamente, por los desarrolladores
Gestión de la calidad 22
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo CMMCada nivel se asocia con un conjunto de áreas clave de proceso sobre las que la organización tiene que mejorar sus actividades.
Niveles de madurez Áreas claves
Nivel 1Inicial
Ninguna
Nivel 2Repetible
Gestión de configuracionesGarantía de calidadGestión de subcontratación del softwareSeguimiento y supervisión del proyectoPlanificación del proyectoGestión de requisitos
Nivel 3Definido
Revisiones periódicasCoordinación entre gruposIngeniería de productos de softwareGestión de integración del softwarePrograma de formaciónDefinición del proceso de la organizaciónEnfoque del proceso de la organización
Nivel 4Gestionado
Gestión de calidad del softwareGestión cuantitativa del proceso
Nivel 5Optimizado
Gestión de cambios del procesoGestión de cambios de tecnologíaPrevención de defectos
Gestión de la calidad 23
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo CMMCada área de proceso se descompone en un conjunto de prácticas clave que proporcionan la evidencia de que el área de proceso es efectiva.Las prácticas clave se organizan en características comunes:
– Compromiso de realización: acciones que aseguran que el proceso se ha establecido y será usado.
– Capacidad de realización: precondiciones que aseguran que la organización es capaz de implementar el proceso.
– Actividades realizadas: roles y procedimientos necesarios para implementar el área clave.
– Medición y análisis: procedimientos y análisis de las medidas.
– Verificación de la implementación: asegura que las actividades cumplen con los procesos establecidos.
Una organización satisface un área clave de proceso sólo cuando el área de proceso está implementada e institucionalizada.
Gestión de la calidad 24
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelos CMMIEl modelo SW-CMM se ha ampliado con los modelos CMMI (Capability Maturity Model Integration) que permiten la expansión y el crecimiento de los conceptos CMM a múltiples disciplinas (SW-CMM, EIA/IS 731 IPD-CMM, SA-CMM) y a otros modelos de mejora de procesosAlgunos modelos:– CMMI for Systems Engineering/Software Engineering/
Integrated Product and Process Development/Supplier Sourcing, V 1.1 (CMMI-SE/SW/IPPD/SS)
» Continuous Representation (CMU/SEI-2002-TR-011)» Staged Representation (CMU/SEI-2002-TR-012)
– CMMI for Software Engineering, V 1.1: medición del proceso de mejora usando los niveles de capacidad.
» Continuous Representation (CMU/SEI-2002-TR-028)Los niveles de madurez se aplican a la mejora de procesos dentro de áreas individuales de proceso.
» Staged Representation (CMU/SEI-2002-TR-029)Los niveles de madurez se aplican a la mejora de procesos a nivel de la unidad de la organización.
Gestión de la calidad 25
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo SPICE (ISO/IEC 15504)Modelo similar al CMM que también se utiliza para la mejora de procesos y determinación de la capacidad.Hay dos tipos de prácticas:– Prácticas base– Prácticas genéricas
Arquitectura de mejores prácticas Nivel de
capacidad
Características comunes
Práctica genérica
Índice actual
Vector de índices
Categoría de procesos
Práctica base
Índice actual
Procesos
Perfil de proceso
Gestión de la calidad 26
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo SPICEVista funcional (parte izquierda del diagrama):– suministro al cliente: procesos que afectan al cliente
directamente.– Ingeniería: Procesos que especifican, implementan o
mantienen el sistema y su documentación.– Proyecto: procesos que establece el proyecto.– Soporte: procesos de apoyo a la realización de otros
procesos.– Organización: procesos relacionados con los objetivos de
negocio.
Vista de gestión (parte derecha del diagrama). Las prácticas genéricas se sitúan en seis niveles:– 0: no realizada: no hay productos de trabajo identificables.– 1: realizada informalmente: planificación y seguimiento
dependientes del conocimiento individual. Productos de trabajo identificables.
– 2: planificada: verificada de acuerdo a los procedimientos especificados.
– 3: bien definida: procesos bien definidos y documentados– 4: controlada cuantitativamente : medidas detalladas de
realización, predicción, etc. Productos de trabajo evaluados cuantitativamente.
– 5: mejorada continuamente : objetivos cuantitativos de eficiencia basados en los objetivos de negocio.
Gestión de la calidad 27
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo SPICECada informe de evaluación es un perfil: cada proceso se evalúa y se documentaLa principal diferencia entre CMM y SPICE radica en que CMM está orientado a organizaciones, mientras que el modelo SPICE está dirigido a los procesos.
Totalmenteadecuado
Parcialmenteadecuado
Muy adecuado
No adecuado
Proceso Nivel de capacidad
Identificación de necesidades
Soporte de operación
Diseño de software
Implementación del diseño
Integración y prueba
Gestión de la calidad 28
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Modelo SPICEEjemplo de mejora de procesos: perfil de valoración SPICE y perfil ISO 9001 (diagrama de kiviat)
Gestión de la calidad 29
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadModelos de calidad del softwareModelos de calidad del software
Gestión de la calidad 30
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidad7.2. Fiabilidad del software7.2. Fiabilidad del software
La fiabilidad es la característica dinámica más importante de casi todos los sistemas de software.Definición de fiabilidad:Probabilidad de operación libre de fallos de un programa de computadora en un entorno determinado y durante un tiempo específico.Entendiéndose por fallo cualquier falta de concordancia con los requisitos del software. Un fallo tiene lugar cuando el softwarese está ejecutando.La ejecución del software trabaja sobre un conjunto de entradas y produce un conjunto de salidas. La fiabilidad del software está relacionada con la probabilidad de que en una ejecución particular del programa la entrada del sistema sea miembro de un conjunto de entradas que causan una salida errónea.
Conjunto de
entradasEe
Conjunto de salidas Se
SistemaSistema
Gestión de la calidad 31
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadFiabilidad del softwareFiabilidad del software
Los fallos se pueden producir por defectos en el código, en el diseño o en el análisis. También se pueden producir durante el mantenimiento.Las pruebas contribuyen a mejorar la fiabilidad, pero no la garantizan totalmente debido varios factores:– La especificación puede no reflejar los requisitos de los
usuarios.– Las pruebas pueden contener errores– Las pruebas pueden suponer patrones de uso que son
incorrectos.El aumento de la fiabilidad del sistema supone un aumento exponencial del coste y una disminución de la eficiencia.Existen muchas razones para considerar que hay que dar más importancia a la fiabilidad que a la eficiencia: los ordenadores son cada vez más rápidos y baratos, los fallos pueden ser muy costosos, los sistemas no fiables son difíciles de mejorar y pueden causar pérdida de información, etc.).La fiabilidad del producto software está influenciada por el proceso de desarrollo, sin embargo no hay una relación simple entre la fiabilidad del producto y la fiabilidad del proceso.
Gestión de la calidad 32
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadFiabilidad del softwareFiabilidad del software
Especificación de la fiabilidad:– La fiabilidad requerida del sistema debe aparecer en la
especificación de requisitos. Puede expresarse de varias maneras:
» Cualitativamente» Cuantitativamente» Cuasi-cuantitativamente
– El plan de pruebas del software debe incluir un perfil operacional del software para medir su fiabilidad.
– Las consecuencias del fallo de un sistema dependen de la naturaleza del fallo. Deben especificarse los tipos de fallos que pueden ocurrir.
Tipo de fallo Descripción
Transitorio Ocurre sólo con ciertas entradas
Permanente Ocurre con todas las entradas
Recuperable El sistema se recupera sin intervención del operador
Irrecuperable Se requiere la intervención del operador pararecuperar el sistema
No corruptor No corrompe el estado del sistema o los datos
Corruptor Corrompe el estado del sistema o los datos
Gestión de la calidad 33
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidad7.3. Revisiones del software7.3. Revisiones del software
Las revisiones son técnicas estáticas que se aplican en varios momentos del desarrollo del software y sirven para detectar defectos que puedan así ser eliminados.En cualquier revisión se pretende:– Señalar la necesidad de mejora en el producto– Confirmar las partes de un producto que no es necesario
mejorar– Conseguir un trabajo técnico de una calidad más uniforme
Tipos de revisiones (IEEE Std. 1028):
– Revisiones de gestión: sirven para controlar el progreso y detectar inconsistencias de los planes con la programación y los requisitos.
– Revisiones técnicas: revisan la documentación producida a lo largo del proyecto.
– Inspecciones: revisiones que involucran al autor de un producto.
– Walkthrough: inspecciones conducidas únicamente por miembros del grupo de desarrollo que examinan una parte específica del producto.
– Auditorías: evaluaciones independientes sobre el cumplimiento de estándares, planes, procedimientos ...
Gestión de la calidad 34
Administración de Proyectos Informáticos
Evaluación de la calidadEvaluación de la calidadRevisiones del softwareRevisiones del software
Auditorías– Revisiones dirigidas a evitar el fraude o mal uso, aún
involuntario, de las aplicaciones informáticas.– La misión de un auditor será diseñar y promover la
inclusión de los controles que el nuevo sistema ha de llevar incorporados, para que su integridad quede garantizada.
– Medidas de control:» Medidas sobre datos: precisión en el procesamiento.» Medidas de operatividad: economía, efectividad y
eficiencia de las operaciones.» Medidas relativas al plan: cumplimiento de los
objetivos establecidos.– Las medidas de control se aplican en diferentes aspectos
(controles detectores) a lo largo del ciclo de vida (fig. 3).
AUDITORÍA
PREVIA
POSTERIOR
NORMAS
CONTROLES
ACCESOS AUTORIZ. USUARIOS
Figura 3. Tipos de auditoría
Gestión de la calidad 35
Administración de Proyectos Informáticos
8. Métricas de calidad8. Métricas de calidad
Métricas basadas en atributos internos del producto:− Medidas de estructuración de un programa
− Métricas de complejidad
− Métricas de cobertura de pruebas
− Métricas de calidad del diseñoMétricas basadas en atributos externos del producto:− Métricas de portabilidad
− Métricas de defectos
− Métricas de usabilidad
− Métricas de mantenibilidad
− Métricas de fiabilidad Métricas para sistemas orientados a objetos:– Métricas orientadas a clases: proporcionan un conjunto de
medidas para valorar la complejidad y la calidad del diseño.– Métricas orientadas a operaciones: se utilizan para medir
la complejidad de los métodos, comprobar la asignación correcta de responsabilidades o la complejidad de la colaboración entre objetos.
– Métricas para pruebas orientadas a objetos: orientadas a medidas de encapsulamiento y complejidad de la jerarquía de la herencia.
Gestión de la calidad 36
Administración de Proyectos Informáticos
Métricas de calidadMétricas de calidad
Métricas de cobertura de pruebas (I)Su objetivo es comprobar el esfuerzo y rigor en la realización de las pruebas.Si P es un programa producido por una especificación S, Se define caso de prueba como el par (i,S(i)) siendo i una entrada al programa.Las estrategias de prueba se agrupan en dos categorías:– Pruebas de caja negra: los casos de prueba se derivan de la
especificación de los requisitos sin considerar el código ni su estructura.
– Pruebas de caja blanca: los casos de prueba se seleccionan basándose en el conocimiento de la estructura interna del programa. Los objetivos pueden ser:
» que cada sentencia del programa se ejecute al menos una vez (cobertura de sentencias)
» que cada rama del programa se ejecute una sola vez (cobertura de ramas)
» casos de prueba que permitan ejecutar todos los posibles caminos del programa al menos una vez (cobertura de caminos)
» que se ejecuten los caminos simples (prueba del camino simple)
» que se ejecuten los caminos linealmente independientes (prueba estructurada)
Gestión de la calidad 37
Administración de Proyectos Informáticos
Métricas de calidadMétricas de calidad
A
B
DC
E
GF
A input (puntos)B if puntos < 45C then mostrar “pierde”D else mostrar “pasa”E if puntos > 80F then mostrar “con distinción”G fin
– Los caminos <ABCEFG> y <ABDEFG> cubren todas las sentencias pero no cubren el arco EG
– El camino <ABCEFG> no se ejecuta nunca
La estrategia de cobertura de caminos es imposible realizarla en muchas ocasiones debido a la existencia de caminos inviables: caminos que no pueden ejecutarse para ninguna entrada.Las estrategias de prueba deberían cumplir:– Ser más completas que la cobertura de sentencias o ramas.– El número de casos de prueba que requieren sea finito.
Métricas de cobertura de pruebas (II)
Gestión de la calidad 38
Administración de Proyectos Informáticos
Métricas de calidadMétricas de calidad
Métricas de cobertura de pruebas (III)Existen dos métricas importantes asociadas con las estrategias de prueba– Número mínimo de casos de prueba
» Ayuda a planificar las pruebas proporcionando el número mínimo de casos que hay que generar para un programa determinado y una estrategia de prueba dada.
– Índice de efectividad de las pruebas» Proporciona una medida del grado en que los casos de
prueba satisfacen una estrategia particular para un programa dado y un conjunto determinado de casos de prueba.
Para calcular el número mínimo de casos de prueba se puede hacer uso del teorema de descomposición básica:
» Un caso de prueba corresponde a un camino del grafo de flujo F.
» Para calcular el número mínimo de casos de prueba se calculará el número mínimo de caminos, m(F), que se requieren para satisfacer una estrategia.
» El cálculo de m(F) a partir del árbol de descomposición definiendo medidas para las primitivas, concatenación y anidamiento.
Gestión de la calidad 39
Administración de Proyectos Informáticos
Métricas de calidadMétricas de calidad
Ejemplo: cobertura de sentencias
– Primitivas: m(D1) = 2, m(Cn) = n y m(F) = 1 si F ≠ D1 y F ≠ Cn
– Secuencia: m(F1; ......; Fn) = max (m(F1 ), ......, m(Fn))
– Anidamiento:m(D1(F1, F2)) = m(F1 ) + m(F2))m(Cn(F1, ......, Fn)) = ∑ m(Fi)m(D0(F)) = m(F)m(D2(F)) = 1
FD1
P3 D0
D0 P1 D2 D3
ÁRBOL(F)
F = D1 ((D0 ; P1 ; D2), D0 (D3))
Métricas de cobertura de pruebas (IV)
Gestión de la calidad 40
Administración de Proyectos Informáticos
Métricas de calidadMétricas de calidad
Índice de efectividad de las pruebas– Grado de cobertura de los casos de prueba para una
estrategia particular y un programa dado.
– Si T es una estrategia que requiere cubrir una clase de objetos, podemos expresar formalmente el índice de efectividad TERT (Test Effectiveness Ratio):
Métricas de cobertura de pruebas (V)
número de objetos T probados alguna vezTERT =
número total de objetos
– En algunos casos, el denominador de la expresión anterior es el número mínimo de casos de prueba que se requieren para satisfacer la estrategia de prueba.
Gestión de la calidad 41
Administración de Proyectos Informáticos
BIBLIOGRAFÍABIBLIOGRAFÍA
AENOR. Normas para la gestión y el aseguramiento de la calidad, Madrid, AENOR, 1992.
Basili, V.R. y Rombach, H.D., The TAME project: Towards improvement-orientedsoftware environments, IEEE Transaction on Software Engineering,14(6), 758-73 1988.
Boehm, B.W., Kaspar, J.R. y otros “Characteristics of Software Quality”, TRW Series of Software Technology, 1978.
Dolado, J.J. y Fernández, L. (coordinadores). “Medición para la Gestión en la Ingeniería del Software”. Ra-ma, 2000.
Fenton, N.E. y Pfleeger, S.L., “Software Metrics. A Rigorous & Practical Approach”, PWS, 1997.
Fernández, L. “Una Revisión Breve de la Medición del Software". Novática, 137, pp 20-24, 1999.
Gilb, T. “Principles of Software Engineering Management”, Addison-Wesley, 1988.McCall, J.A., Richards, P.K. and Walters, G.F. “Factors in Software Quality”, RADC
TR-77-369, US Rome Air Development Center Reports NTIS AD/A-049 014, 015, 055, 1977.
Paulk, M. et al., Capability Maturity Model for Software, Software EngineeringInstitute, Carnie Mellon University, Pittsburgh, P.A., 1993.
Pressman, R.S., Ingeniería del Software, un enfoque práctico, 4ª ed., Mc Graw Hill, 1998.
Piattini, M.G., Calvo-Manzano, J.A., Cervera, J. y Fernández, L. “Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión”. Ra-ma. 1996.
Rout, T.P. “Software Process Improvement and Practice”, 1(1), pp 57-66, 1995.
SPICE, “SPICE Document Suite, Software Process Improvement and Capability determination”, http://www.sqi.gu.edu.au/spice/, 1999.
Gestión de la calidad 42
Administración de Proyectos Informáticos
ESTÁNDARESESTÁNDARES
CMMI for Systems Engineering/Software Engineering/ Integrated Product and Process Development/Supplier Sourcing, V 1.1 (CMMI-SE/SW/IPPD/SS)
– Continuous Representation (CMU/SEI-2002-TR-011)– Staged Representation (CMU/SEI-2002-TR-012)
CMMI for Software Engineering, V 1.1– Continuous Representation (CMU/SEI-2002-TR-028)– Staged Representation (CMU/SEI-2002-TR-029)
IEEE Sdt. 12207, “IEEE Standard for developing Software Life Cycle Processes”, 1998.
IEEE Sdt. 610.12, “IEEE Standard Glossary of Software Engineering Terminology”, 1990.
IEEE Std. 1008 “Software Unit Test”, 1998.
IEEE Std. 1012, “Software Verification and Validation”, 1998.
IEEE Std. 1028, “Software Reviews”, 1997.
IEEE Std. 1044, “Standard Classification for Software Anomalies”, 1993.
IEEE Std. 1061, “Standard for a Software Quality Metrics Methodology”, 1998.
IEEE Std. 1228, “Software Safety Plans”, 1994.
IEEE Std. 730, “Software Quality Assurance Plans”, 2002.
IEEE Std. 829, “Software Test Documentation”, 1998.
Gestión de la calidad 43
Administración de Proyectos Informáticos
ESTÁNDARESESTÁNDARES
ISO/IEC 12207, “Information Technology-Software Life Cycle Processes”, 1995ISO/IEC 8402, “Quality - Vocabulary”, 1986.ISO 9000, “Quality Management and Quality Assurance Standards”, 1994.ISO 9000:2000, “Quality management systems -- Fundamentals and vocabulary”,
2004.ISO 9001:2000, “Quality management systems -- Requirements”, 2000.ISO 9004:2000, “Quality management systems -- Guidelines for performance
improvements”, 2000.ISO/IEC 90003:2004, “Software engineering -- Guidelines for the application of ISO
9001:2000 to computer software”, 2004ISO 9001, “Quality Systems”, 1994.ISO/IEC 9126-1:2001, “Software engineering -- Product quality -- Part 1: Quality
model, 2001. ISO/IEC TR 9126-2:2003, “Software engineering -- Product quality -- Part 2: External
metrics”, 2003 . ISO/IEC TR 9126-3:2003, “Software engineering -- Product quality -- Part 3: Internal
metrics”, 2003. ISO/IEC TR 9126-4:2004, “Software engineering -- Product quality -- Part 4: Quality
in use metrics”, 2004.ISO/IEC TR 15504, “Software Process Assessment”, 1998.ISO/IEC TR 15504-1:1998, “Information technology -- Software process assessment --
Part 1: Concepts and introductory guide”, 1998. ISO/IEC 15504-2:2003, “Information technology -- Process assessment -- Part 2:
Performing an assessment”, 2003 . ISO/IEC 15504-3:2004, “Information technology -- Process assessment -- Part 3:
Guidance on performing an assessment”, 2004. ISO/IEC TR 15504-5:1999, “Information technology -- Software Process Assessment --
Part 5: An assessment model and indicator guidance”, 1999 . ISO/IEC TR 15504-7:1998, “Information technology -- Software process assessment --
Part 7: Guide for use in process improvement”, 1998 . ISO/IEC TR 15504-8:1998, “Information technology -- Software process assessment --
Part 8: Guide for use in determining supplier process capability”, 1998 . ISO/IEC TR 15504-9:1998, “Information technology -- Software process assessment --
Part 9: Vocabulary”, 1998 .