segunda parte - gestion de la calidad del software

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



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



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.



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.



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



Á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.



Á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.



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



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



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



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.



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



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.



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.



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




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




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.




Marco ISO 9126La calidad se descompone en seis factores:– Funcionalidad– Fiabilidad– Usabilidad– Eficiencia– Mantenibilidad– Portabilidad




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...




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.




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




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




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.




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.




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




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.




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




Modelo SPICEEjemplo de mejora de procesos: perfil de valoración SPICE y perfil ISO 9001 (diagrama de kiviat)



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



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.



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



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 ...



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



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.



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)




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)




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.




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)




Í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.



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.



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.



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 .