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 calidad
2. Definición de calidad del software
3. Aspectos de la gestión de calidad
4. Ámbitos de la gestión de calidad
4.1. Calidad a nivel de la organización
4.2. Calidad a nivel del proyecto
5. Marco normativo
5.1. Estándares ISO 9000
5.2. Estándares ISO 9000:2000
5.3. Estándares IEEE
6. Actividades de aseguramiento de la calidad
7. Evaluación de la calidad
7.1. Modelos de calidad del software
7.2. Fiabilidad del software
7.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
CALIDAD
PROGRAMADA
CALIDAD
NECESARIA
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 calidad4. Á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 Dolado
Plan 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 calidad
4.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 calidad
4.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 normativo
5.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.
organizaciones cuya actividad se basa en las fases de
producción y de instalación.
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 normativo
Está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 9000
CONCEPTOS Y DIRECTRICES
GENERALES
ISO 9004
GESTIÓN INTERNA DE LA
CALIDAD
ISO 9001
DISEÑO, PRODUCCIÓN,
INSTALACIÓN Y POSVENTA
ISO 9002
PRODUCCIÓN, INSTALACIÓN
ISO 9003
INSPECCIÓN Y ENSAYOS
FINALES
ASEGURAMIENTO EXTERNO
DE LA CALIDAD
UNE 66-907-91
GUÍA PARA MANUALES DE
CALIDAD
Figura 3. Normativa ISO 9000

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

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

5.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 desviaciones
Registrar lo que no se ajuste a los requisitos
Control 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 calidad
7.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 and
Capability dEtermination) : modelo de valoración de la
arquitectura que define los procesos y prácticas
aconsejables.

Evaluación de la calidadEvaluación de la calidad
Modelos de calidad del softwareModelos de calidad del software
Modelo deModelo de BoehmBoehm
Los componentes o constructores del modelo se centran
en el producto final
Se identifican características de calidad desde el punto de
vista del usuario.
Ingeniería
humana
Fiabilidad
eficiencia
Chequeabilidad
Comprensibilidad
Portabilidad
Modificabilidad
Como es su
utilidad
Mantenibilidad
Independencia dispositivo
Completitud
exactitud
Consistencia
Eficiencia Dispositivo
Accesibilidad
Comunicatividad
Estructuración
Autodescriptividad
Concisión
Legibilidad
Expansivilidad
MM
ÉÉ
TT
RR
II
CC
AA
SS
UsosUsos
PrimariosPrimarios
Utilidad
general
CConstructoresonstructores
intermediosintermedios
CConstructoresonstructores
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 factores
que 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 9126
La 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ándar
el lenguaje
Cantidad
de código
Errores...
Experiencia de
codificadores en:
el estándar
el lenguaje
el entorno...

Modelo de Gilb
Determinar 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 (Quality
Function Deployment) para la gestión de la calidad
industrial.
El proyecto COQUAMO (Constructive Quality Model) se
apoya en el enfoque de Gilb.

Modelo CMM
SW-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 CMM
Cada 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 1
Inicial
Ninguna
Nivel 2
Repetible
Gestión de configuraciones
Garantía de calidad
Gestión de subcontratación del software
Seguimiento y supervisión del proyecto
Planificación del proyecto
Gestión de requisitos
Nivel 3
Definido
Revisiones periódicas
Coordinación entre grupos
Ingeniería de productos de software
Gestión de integración del software
Programa de formación
Definición del proceso de la organización
Enfoque del proceso de la organización
Nivel 4
Gestionado
Gestión de calidad del software
Gestión cuantitativa del proceso
Nivel 5
Optimizado
Gestión de cambios del proceso
Gestión de cambios de tecnología
Prevención de defectos

Modelo CMM
Cada á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 CMMI
El 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
procesos
Algunos 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 SPICE
Vista 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 SPICE
Cada informe de evaluación es un perfil: cada proceso se
evalúa y se documenta
La principal diferencia entre CMM y SPICE radica en que
CMM está orientado a organizaciones, mientras que el
modelo SPICE está dirigido a los procesos.
Totalmente
adecuado
Parcialmente
adecuado
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 SPICE
Ejemplo de mejora de procesos: perfil de valoración SPICE y
perfil ISO 9001 (diagrama de kiviat)

7.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 software
se 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
entradas
Ee
Conjunto
de salidas Se
SistemaSistema

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

Fiabilidad 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 para
recuperar el sistema
No corruptor No corrompe el estado del sistema o los datos
Corruptor Corrompe el estado del sistema o los datos

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

Revisiones 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ño
Mé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
G
F
A input (puntos)
B if puntos < 45
C then mostrar “pierde”
D else mostrar “pasa”
E if puntos > 80
F 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
F
D1
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 vez
TERT =
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-oriented
software 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 Engineering
Institute, 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”, 1995
ISO/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”, 2004
ISO 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 .
Part 7: Guide for use in process improvement”, 1998 .
Part 8: Guide for use in determining supplier process capability”, 1998 .
Part 9: Vocabulary”, 1998 .

SEGUNDA PARTE - Gestion de la calidad del software

Más contenido relacionado

La actualidad más candente

Destacado

Similar a SEGUNDA PARTE - Gestion de la calidad del software

Más de Miguel Angel Sandoval Calderon

SEGUNDA PARTE - Gestion de la calidad del software