Calidad del

Software

Curso 2014/15

Resumen de la asignatura
para apuntrix.com
 Índice

I Introducción a la Calidad 1
1. Concepto de Calidad 1
1.1. Definición de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Conceptos relacionados con la Calidad . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. Conceptos relacionados con la Gestión de Calidad . . . . . . . . . . . . . . 2
1.2.2. Conceptos relacionados con la Documentación de la Calidad . . . . . . . . 3
1.3. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Modelos y normas de calidad 6

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Gestión de la Calidad Total (TQM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Normas ISO 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. ISO y el Proceso de Normalización . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Normas sobre Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3. Norma ISO 9001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Modelo EFQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Criterios del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Seis-Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Calidad de los Sistemas Informáticos 16

3.1. Concepto de Calidad del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Aseguramiento de la Calidad del Software . . . . . . . . . . . . . . . . . . . 16
3.1.2. Gestión de la Calidad del Software . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Situación de la calidad de SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Importancia de la calidad en los SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Componentes de la calidad de un SI . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Calidad de un SI y la Gestión del Conocimiento . . . . . . . . . . . . . . . . . . . . 18
3.5.1. Necesidades de la Gestión del Conocimiento en Organización de Software 18
3.5.2. Modelos de Gestión de Conocimiento en Ingeniería del Software . . . . . . 19
3.6. Factoría de experiencia y Paradigma de Mejora de la Calidad (QIP) . . . . . . . . 20
3.6.1. QIP (Paradigma para la mejora de la calidad) . . . . . . . . . . . . . . . . . 20
3.6.2. Factoría de Experiencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.3. Base o Repositorio de Experiencia . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4. Aplicación práctica (apuntes E.D.) 23

4.1. El departamento de calidad en las organizaciones . . . . . . . . . . . . . . . . . . . 23
4.1.1. Entornos pequeños: quality circles . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2. El departamento de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Contenido práctico: guía de implantación de la norma ISO 9001:2008 . . . . . . . . 25
4.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2. Apartados de la norma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Contenido práctico: guía de implantación del manual de calidad . . . . . . . . . . 26
4.3.1. Guía del Plan de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2. Guía del Manual de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

II Calidad de Productos 31
5. Calidad de producto software 31
5.1. Modelos clásicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Normas ISO sobre calidad de producto software . . . . . . . . . . . . . . . . . . . . 31
5.3. Familia de normas ISO 25000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Normas sobre Gestión de Calidad (ISO/IEC 2500n) . . . . . . . . . . . . . . 32
5.3.2. Normas sobre Modelado de Calidad (ISO/IEC 2501n) . . . . . . . . . . . . 32
5.3.3. Normas sobre Medición de Calidad (ISO 2502n) . . . . . . . . . . . . . . . . 35
5.3.4. Normas sobre Requisitos de Calidad (ISO 2503n) . . . . . . . . . . . . . . . 35
5.3.5. Normas sobre Evaluación de Calidad (ISO 2504n) . . . . . . . . . . . . . . . 35
5.3.6. Otras normas de la Familia 25000 . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6. Calidad del producto de software (apuntes E.D.) 41

6.1. Introducción a la medición del software . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.1. Conceptos básicos de la medición . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.2. Métricas del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2. Métricas del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.1. Métricas internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.2. Métricas externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.3. Métricas de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3. Modelos de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.1. Conceptos básicos sobre modelos . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4. Medición práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.1. Medición personal y medición institucional . . . . . . . . . . . . . . . . . . 55
6.4.2. Guía de medición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

III Calidad del Proyecto 57

7. La gestión de la calidad de los proyectos 57
7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. Gestión de la calidad de los proyectos según PMBOK . . . . . . . . . . . . . . . . . 57
7.2.1. Planificar la Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2.2. Realizar el Aseguramiento de la Calidad . . . . . . . . . . . . . . . . . . . . 59
7.2.3. Realizar el Control de la Calidad . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3. Estándares IEEE 730-2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.2. Documentos de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.3. Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.4. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.5. Estándares, prácticas, convenciones y métricas . . . . . . . . . . . . . . . . . 62
7.3.6. Revisiones Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.8. Informe de Problemas y Acciones Correctivas . . . . . . . . . . . . . . . . . 63
7.3.9. Herramientas, Técnicas y Metodologías . . . . . . . . . . . . . . . . . . . . . 63
7.3.10. Control de Medios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.11. Control del Proveedor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.12. Recopilación, Mantenimiento y Conservación de Registros . . . . . . . . . . 63
7.3.13. Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.14. Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.15. Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.16. Historia y Procedimientos de Cambio del Plan de Aseguramiento de la
Calidad del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.4. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8. Calidad del software (apuntes E.D.) 65
8.1. Conceptos generales del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.1. Concepto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.2. Clasificación de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.3. Aspectos de un proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.4. Organización de la gestión de un proyecto . . . . . . . . . . . . . . . . . . . 66
8.1.5. Etapas de un proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2. Conceptos generales de un proyecto software . . . . . . . . . . . . . . . . . . . . . . 67
8.2.1. Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.2.2. Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.3. Gestión de la calidad de los proyectos según PMBOK . . . . . . . . . . . . . . . . . 68
8.4. Estándar IEEE 730-2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.4.1. Comparativa del plan de SQAP (IEEE STD 730-2002) con la ISO 9001 . . . 68

IV Calidad de Procesos 71
9. Evaluación y mejora de procesos 71
9.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.2. Panorámica general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.2.1. Armonización de estándares . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.3. La norma ISO/IEC 90003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.4. Seis-Sigma para software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.5. EFQM para software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.6. Mejora de procesos en Pymes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.6.1. COMPETISOFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.6.2. ISO 29110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10. Evaluación y mejora de procesos (apuntes E.D.) 76

10.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.2. Norma ISO 90003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.3. Modelo Six-Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.1. Six-Sigma para software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.2. Metodología DMAIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

V Técnicas y Herramientas para la calidad del software 81

11. Técnicas y herramientas de calidad (apuntes E.D.) 81
11.1. Herramientas básicas de medición . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.1.1. Diagrama de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.1.2. Diagrama de causa-efecto: Ishikawa . . . . . . . . . . . . . . . . . . . . . . . 81
11.1.3. Diagrama de Pareto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
11.1.4. Hojas de comprobación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.1.5. Diagrama de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.2. Pruebas de software: JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
11.2.1. Anotaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Parte I
Introducción a la Calidad
1. Concepto de Calidad
1.1. Definición de Calidad
La calidad se ha convertido hoy en día en uno de los principales objetivos estratégicos para
las organizaciones. Definición según el DRAE:
1. Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.

2. Carácter, genio, índole.

Las organizaciones están interesadas en estas dos acepciones. En las principales normas inter-
nacionales, la calidad se define como “el grado en el que un conjunto de características in-
herentes cumple con los requisitos”. Otra definición interesante: “Conjunto de propiedades o
características de un producto o servicio que le confieren aptitud para satisfacer unas necesida-
des expresadas o implícitas”.
La calidad no se trata de un concepto absoluto. Es posible considerarla como un concepto
multidimensional (de muchas cualidades), sujeta a restricciones (depende del presupuesto dis-
ponible) y ligada a compromisos aceptables (plazos de entrega). No es ni totalmente subjetiva
ni totalmente objetiva. La calidad suele ser transparente cuando está presente pero fácilmente
reconocible cuando está ausente.
Las cinco vistas de la calidad:
Vista trascendental: la calidad es algo que se reconoce pero no se define.
Vista del usuario: la calidad es adecuación al propósito.

Vista del fabricante: la calidad es la conformidad con las especificaciones.

Vista del productor: la calidad está unida a las características inherentes del producto.
Vista basada en valor: la calidad depende de la cantidad que el cliente esté dispuesto a
pagar.

Se pueden resumir las ventajas y desventajas de las cuatro vistas con una tabla:

Vista Fortalezas Debilidades

Usuario Evaluación desde la perspectiva del
cliente.
Aplicable en los sectores más variados y
específicos.
Sensible a los cambios y a la evolución del
mundo moderno.
Fabrican- Proporciona medidas precisas.
te Desagrega de los cambios constantes de
los usuarios y se centra en la producción.
Producto Orientado al mercado.
Reconocible universalmente.
Valor Incorpora múltiples atributos.
Centra la atención en la eficacia interna y
la efectividad externa.
Permite la comparación entre distintos
productos.
Dificultad de definir: lo bueno hoy puede
ser malo mañana.
Difícil de medir: para gustos colores.
Las actitudes/aptitudes previas pueden
fijar la opinión.
Confundir el servicio al cliente con la
satisfacción al cliente.
Difícilmente se aplica a los servicios.
Las especificaciones pueden convertirse en
obsoletas ante el cambio constante.
Difícil de cuantificar por la mayor parte de
los usuarios.
Dificulta la extracción de los componentes
individuales.
Calidad y valor son diferentes en
determinados casos.

La calidad puede tener varios orígenes:

1
 La calidad realizada: la que es capaz de obtener la persona que realiza el trabajo.
La calidad planificada: la que se ha pretendido obtener. Es la que aparece descrita en una
especificación.

La calidad necesaria: la que el cliente exige con mayor o menor grado de concreción.
La gestión de la calidad pretenderá conseguir que estos tres círculos coincidan lo más posible.
Todo lo que esté fuera de dicha coincidencia será motivo de derroche, de gasto superfluo o de
insatisfacción.

1.2. Conceptos relacionados con la Calidad

Se tratan los términos requisito, entendido como “necesidad o expectativa establecida” y
satisfacción del cliente, es decir, la percepción del cliente sobre el grado en que se han cumplido
sus requisitos. También se define la capacidad de una organización, sistema o proceso, como la
aptitud para realizar un producto que cumple los requisitos para el mismo.

1.2.1. Conceptos relacionados con la Gestión de Calidad

Se definen otros conceptos:

Política de la calidad: intenciones globales y orientación de una organización relativas a la

calidad tal como se expresan formalmente por la alta dirección.
Sistema de gestión de la calidad: sistema de gestión para dirigir y controlar una organi-
zación con respecto a la calidad.

Planificación de la calidad: parte de la gestión de la calidad enfocada al establecimiento

de los objetivos de la calidad y a la especificación de los procesos operativos necesarios y
de los recursos relacionados para cumplir los objetivos de la calidad.
Control de la calidad: parte de la gestión de la calidad orientada al cumplimiento de los
requisitos de la calidad.

Aseguramiento de la calidad: parte de la gestión de la calidad orientada a proporcionar

confianza en que se cumplirán los requisitos de la calidad.
Mejora de la calidad: parte de la gestión de la calidad orientada a aumentar la capacidad
de cumplir con los requisitos de la calidad.

Son muy importantes los términos relativos a la conformidad como aceptación del producto o
servicio:
Conformidad: cumplimiento de un requisito.
No Conformidad: incumplimiento de un requisito.

Defecto: incumplimiento de un requisito asociado a un uso previsto o especificado.

Acción Preventiva: acción tomada para eliminar la causa de una no conformidad potencial.
Acción Correctiva: acción tomada para eliminar la causa de una no conformidad detectada.
Corrección: acción tomada para eliminar una no conformidad detectada.

Reparación: acción tomada sobre un producto no conforme para convertirlo en aceptable

para su uso previsto.
Desecho: acción tomada sobre un producto no conforme para impedir su uso inicialmente
previsto.

2
1.2.2. Conceptos relacionados con la Documentación de la Calidad
La documentación contribuye a:
Lograr la conformidad con los requisitos del cliente y la mejora de la calidad.
Proveer la información apropiada.

La repetibilidad y la trazabilidad.
Proporcionar evidencias objetivas.
Evaluar la eficacia y la adecuación continua del sistema de gestión de la calidad.

En la norma ISO 9000 se distingue entre:

Manuales de la calidad: documentos que proporcionan información coherente acerca del
sistema de gestión de la calidad de la organización.
Planes de la calidad: documentos que describen cómo se aplica el sistema de gestión de la
calidad a un producto.

Especificaciones: documentos que establecen requisitos.

Guías: documentos que establecen recomendaciones o sugerencias.
Procedimientos documentados: instrucciones de trabajo que proporcionan información
sobre cómo efectuar las actividades y los procesos de manera coherente.

Registros: Documentos que proporcionan evidencia objetiva de las actividades realizadas

o resultados obtenidos.

1.3. Ejercicios
1. De las definiciones de calidad dadas por los gurús y normas internacionales, ¿Cuál consi-
dera que refleja mejor la “vista del fabricante” en terminología de Garvin (1984)? ¿Y cuál
la “vista de usuario”?
La visión del fabricante de Garvin o enfoque basado en la fabricación propone aplicar
la calidad a la estrategia de fabricación. La estrategia de fabricación busca asegurar que
se minimicen las desviaciones del modelo estándar ya que éstas reducen la calidad del
producto fabricado.
La visión de usuario de Garvin determina la calidad según el usuario que utiliza un pro-
ducto o servicio en términos que él necesita, quiere o espera. Los usuarios como clientes
pueden tener unos requisitos de usuario que sean diferentes a los de requerimientos de las
normas o de los estándares tanto internos como externos de las organizaciones. El mero
hecho de cumplir con las normas o las especificaciones no es la respuesta a la calidad, es
simplemente insuficiente.
2. Comente estas dos apreciaciones sobre la calidad: Kitchenham afirma que “la calidad es
difícil de definir, imposible de medir y fácil de reconocer”, según Gillies la calidad es
“transparente cuando está presente, pero fácil de reconocer en su ausencia”. Compare
estas afirmaciones con las definiciones de calidad citadas en este capítulo.
La sentencia de Kitchenham indica que esta visión coincide con la visión trascendental
de Garvin que fija la calidad como algo subjetivo de la persona que la evalúa. También
coincide con Garvin en comentar que esta definición no es útil y desde su punto de vista
se debe buscar una cuantificación de la calidad ya sea en términos absolutos o relativos.
La cita de Gillies es similar a la anterior sobre la visión trascendental de Garvin, y es
consecuencia de la idea que no es posible prever todas las circunstancias relacionadas con
la calidad y por lo tanto la especificación de las necesidades y los requisitos para todas
las características de calidad puede no ser apropiada, y cambiar con los cambios que se
producen en el día a día.

3
3. Describa la organización de la AEC (Asociación Española de la Calidad), y de la ASQ
(American Society for Quality).
Ambas son sociedades dedicadas a la calidad básicamente como recopiladoras de informa-
ción relacionada con la calidad y autoridades de formación y certificación. Las funciones
de estas organizaciones son prácticamente las mismas y se enfocan a:
Dar soporte a los asociados en todo lo relacionado con la calidad, realizando soporte,
formación o auditoría a sus asociados;
Certificación de personas en formación relacionada con calidad (no se debe confundir
con certificaciones de organizaciones);
Formación con un extenso catálogo de cursos desde los temas más generales a los
más específicos, tanto presenciales como semipresenciales;
Fomento de la cultura de la calidad a través de publicaciones tanto de revistas perió-
dicas como de libros relacionados con la calidad;
4. ¿Qué diferencia hay entre una “acción correctiva” y una “corrección”? Ponga ejemplos de
ambas.
Las correcciones son el conjunto de actividades realizadas para eliminar o subsanar lo
que no ha salido bien (no conformidad). La norma define corrección como una acción
tomada para eliminar una no conformidad, por ejemplo, si una no conformidad es que
un catálogo técnico de un producto ha incluido errores, la corrección será modificar el
catálogo eliminando los errores. Una corrección resuelve el problema.
Las acciones correctivas son un conjunto de actividades que se realizan para eliminar la
causa de algo que no ha salido bien. Según la norma, la acción correctiva se define como
la acción tomada para eliminar la causa de una no conformidad detectada u otra situación
no deseada. Si utilizamos el mismo error anterior, si la no conformidad es que el catálogo
tiene errores, debemos buscar la causa que ha provocado ese error, por ejemplo, que los
catálogos se están escribiendo y no se están revisando, y por lo tanto la acción correctiva
será que se debe implantar un método de revisión de los catálogos.
5. Explique qué actividades de la gestión de la calidad podrían considerarse de “control de
la calidad” y cuáles de “aseguramiento de la calidad”.
El control de calidad se refiere a las actividades de la gestión de calidad relacionadas
con el cumplimiento de los requisitos de fabricación. Se utiliza para verificar y medir
que el producto que se entrega o vende tenga la calidad aceptada y que está completo y
comprobado. Por ejemplo, actividades de control de calidad son revisar los documentos o
comprobar medidas.
El aseguramiento de la calidad se refiere a los procesos que se utilizan para la fabricar
el producto o dar servicio. Se trata de actividades que se encargan de comprobar que las
tareas se realizan como se debe realizar sin entrar a analizar el resultado. Por ejemplo, una
auditoría o una lista de comprobación de ítems pueden ser tareas de aseguramiento de
calidad.
6. Especifique el contenido que debería tener un Manual de la Calidad, para ello puede ser
conveniente revisar la norma ISO 10013: Directrices para desarrollar Manuales de la Cali-
dad.
El contenido de un manual de calidad debe incluir los siguientes apartados:
a) Título, alcance y campo de aplicación.
b) Tabla de contenido del manual.
c) Introducción acerca de la organización y el manual.
d) Política de calidad y objetivos de la organización.
e) Descripción de la organización, responsabilidades y autoridades.
f ) Descripción de los elementos del sistema de calidad y las referencias a los procedi-
mientos del sistema de calidad.
g) Definiciones, si corresponde.

4
 h) Guía del manual.
i) Anexos con los datos de apoyo.

7. Especifique un método para desarrollar un Plan de Calidad. Consulte, si lo estima conve-

niente, la norma ISO 10005: Gestión de la Calidad – Directrices para Planes de la Calidad.
La norma 10005:2005 es aplicable a planes de la calidad para un proceso, producto, proyec-
to o contrato, a cualquier categoría de producto (hardware, software, materiales procesados
y servicios) y cualquier industria.
Los pasos que se incluyen para el desarrollo de un plan de calidad son:

a) Identificación de la necesidad del plan.

b) Identificar las entradas para la preparación del plan.
c) Determinar el alcance del plan.
d) Preparación del plan.

5
2. Modelos y normas de calidad
2.1. Introducción
Diferentes modelos para la gestión de calidad, y diversas normas, varias de las cuales han
sido aplicadas en las organizaciones. Dentro de las diferentes propuestas destacan la Gestión de
la Calidad Total, el modelo EFQM y Seis-Sigma.

2.2. Gestión de la Calidad Total (TQM)

La Gestión de la Calidad Total (TQM, Total Quality Management), representa una “actitud”
por la cual la organización pretende ofrecer a sus clientes productos y servicios que satisfagan
completamente sus necesidades.
La TQM concibe la organización como un conjunto de procesos que se pueden gestionar
siguiendo el ciclo Planificar-Hacer-Verificar-Actuar (PDCA), que se conoce como Ciclo de Deming:
Planificar: establecer los objetivos y procesos necesarios para conseguir resultados de
acuerdo con los requisitos del cliente y las políticas de la organización.

Hacer: implementar los procesos.

Verificar: realizar el seguimiento y la medición de los procesos y los productos respecto a
las políticas, los objetivos y los requisitos para el producto, e informar sobre los resultados.
Actuar: tomar acciones para mejorar continuamente el desempeño de los procesos.

Lo más importante de TQM es cómo podemos utilizarlo. Cada organización debe adaptar su
enfoque para explotar los puntos fuertes y concentrarse en sus debilidades.

2.3. Normas ISO 9000

2.3.1. ISO y el Proceso de Normalización
La International Organization for Standarization nació en 1947 con el objetivo de facilitar la
coordinación internacional de las normas técnicas en los diferentes campos de la industria.
El proceso de elaboración de una norma internacional puede ser bastante largo. En España
las normas internacionales son traducidas y publicadas por AENOR como normas UNE.

2.3.2. Normas sobre Calidad

La familia de normas ISO 9000 son documentos técnicos de referencia que han sido ela-
borados a partir de la información, las experiencias y las innovaciones recogidas en diferentes
organizaciones a escala internacional. Está compuesta de cuatro normas:
ISO 9000. Sistemas de gestión de la calidad. Fundamentos y vocabulario. Describe los
fundamentos de los sistemas de gestión de la calidad y especifica su terminología.
ISO 9001. Sistemas de gestión de la calidad. Requisitos. Especifica los requisitos para un sistema
de gestión de la calidad que pueden utilizarse para su aplicación interna por las organizaciones.
Se centra en la eficacia del sistema de gestión de la calidad.
ISO 9004. Gestión para el éxito sostenido de una organización. Enfoque de gestión de la
calidad. Proporciona orientación sobre un rango más amplio de objetivos de un sistema de
gestión de la calidad que la Norma ISO 9001, especialmente para la mejora continua del
desempeño y de la eficiencia global de la organización. Se recomienda como una guía para
aquellas organizaciones cuya alta dirección desee ir más allá de los requisitos de la norma
ISO 9001.

ISO 19011. Directrices para la auditoría de sistemas de gestión de la calidad y/o me-
dioambiental. Esta norma proporciona directrices básicas para la realización de una audi-
toría conjunta de ISO 9001 e ISO 14001.

6
La familia de normas ISO 9000 se basa en ocho principios de gestión de la calidad que pueden
ser utilizados por la dirección con el fin de conducir a la organización hacia una mejora en el
desempeño:
Enfoque al cliente: las organizaciones dependen de sus clientes y por lo tanto deberían
comprender las necesidades actuales y futuras de los mismos.
Liderazgo: los líderes establecen la unidad de propósito y la orientación de la organización.
Participación del personal: el personal, a todos los niveles, es la esencia de una organiza-
ción y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de
la organización.
Enfoque basado en procesos: promueve la adopción de un enfoque basado en procesos
cuando se desarrolla, implementa y mejora un sistema de gestión de la calidad. Los clientes
juegan un papel significativo para definir los requisitos como elementos de entrada.
Enfoque de sistema para la gestión: identificar, entender y gestionar los procesos interre-
lacionados como un sistema, contribuye a la eficacia y eficiencia de una organización.
Mejora continua: la mejora continua del desempeño global de la organización debería ser
un objetivo permanente.
Enfoque basado en los hechos para la toma de decisión: las decisiones eficaces se basan
en el análisis de los datos y la información.
Relaciones mutuamente beneficiosas con el proveedor: una relación mutuamente benefi-
ciosa aumenta la capacidad de ambos para crear valor.

2.3.3. Norma ISO 9001

Norma internacional que especifica los requisitos para un sistema de gestión de la calidad,
cuando una organización:
Necesita demostrar su capacidad para proporcionar regularmente productos que satisfa-
gan los requisitos del cliente.
Aspira a aumentar la satisfacción del cliente a través de la mejora eficaz del sistema.
Todos los requisitos de esta norma internacional se pretende que sean aplicables a todas las
organizaciones sin importar su tipo, tamaño y producto suministrado.

2.3.3.1. Sistema de Gestión de la Calidad

La organización debe:
1. Determinar los procesos necesarios para el sistema de gestión de la calidad y su aplicación
a través de la organización.
2. Determinar la secuencia e interacción de estos procesos.
3. Determinar los criterios y métodos necesarios para asegurarse de que tanto la operación
como el control de estos procesos sean eficaces.
4. Asegurarse de la disponibilidad de recursos e información necesarios para apoyar la ope-
ración y el seguimiento de estos procesos.
5. Realizar el seguimiento, la medición y el análisis de estos procesos.
6. Implementar las acciones necesarias para alcanzar los resultados planificados y la mejora
continua de estos procesos.
La documentación del SGC debe incluir:
1. Declaraciones documentadas de una política de la calidad y de objetivos de la calidad.
2. Un manual de la calidad.

7
 3. Los procedimientos documentados requeridos en esta norma internacional.
4. Los documentos que la organización determina que son necesarios para asegurarse la efi-
caz planificación, operación y control de sus procesos.

2.3.3.2. Responsabilidad de la Dirección

La norma trata varios aspectos relativos a: Compromiso de la dirección, Enfoque al cliente,
Política de la calidad, Planificación, Responsabilidad, Autoridad y Comunicación, y Revisión
por la dirección.

2.3.3.3. Gestión de los recursos

La organización debe determinar y proporcionar los recursos necesarios para:

1. Implementar y mantener el sistema de gestión de calidad y mejorar continuamente su

eficacia.
2. Aumentar la satisfacción del cliente mediante el cumplimiento de sus requisitos.
Tratándose diferentes aspectos relativos a los recursos humanos, infraestructura y ambiente de
trabajo.

2.3.3.4. Realización del producto

Se tratan diversos aspectos relacionados con la realización del producto.

2.3.3.5. Medición, análisis y mejora

La organización debe planificar e implementar los procesos de seguimiento, medición, análisis
y mejora necesarios para:

1. Demostrar la conformidad del producto

2. Asegurarse de la conformidad del sistema de gestión de la calidad
3. Mejorar continuamente la eficacia del sistema de gestión de la calidad

Se establece que debería realizarse un seguimiento y medición de la satisfacción del cliente. Las
diversas fuentes de información se clasifican en:
Activas: si la organización va al cliente y le pregunta cuestiones deliberadas o hace obser-
vaciones directas del comportamiento del cliente.

Pasivas:

• Receptivas: en las que el cliente acude a la organización con devoluciones o quejas.

• Indirectas: se utilizan fuentes secundarias como Informes del cliente, Análisis compe-
titivo, Medios de noticias.

La organización debe llevar a cabo auditorías internas a intervalos planificados para determinar
si el sistema de gestión de la calidad:
1. Es conforme con las disposiciones planificadas.
2. Se ha implementado y se mantiene de manera eficaz.

También trata sobre el seguimiento y medición de los procesos y del producto. Así como del
control del producto no conforme, del análisis de datos.
Por último en la norma se aborda la mejora, tanto la mejora continua como las acciones
correctivas y preventivas. En estos temas se profundiza en la norma ISO 9004.

8
2.4. Modelo EFQM
2.4.1. Visión general
Fue creado como marco para evaluar las organizaciones con el fin de conceder el European
Quality Award, se puede utilizar como:
Herramienta para autoevaluación.
Forma de comparación (benchmark) con otras organizaciones.

Guía para identificar las áreas de mejora.

Base para un vocabulario común y una manear de pensar.
Estructura para sistemas de gestión de la organización.

Se basa en nueve criterios, cinco “agentes facilitadores” y cuatro “resultados”.

Figura 1: Criterios Modelo EFQM

EFQM se basa en una serie de principios:

Orientación a los resultados.

Orientación al cliente.
Liderazgo y coherencia en los objetivos.
Gestión por procesos y hechos.
Desarrollo e implicación de las personas.

Aprendizaje, innovación y mejora continuos.

Desarrollos de alianzas.
Responsabilidad social.

9
Las diferencias fundamentales con las normas ISO pueden resumirse en:

Objeto Enfoque tradicional ISO Enfoque basado en la excelencia

Prioridad Producir productos Satisfacer a los clientes
Objetivos Departamentales Por procesos
Forma de trabajo Confrontación-negociación Trabajo en equipo
Agente Trabajo individual Trabajo en equipo
Empleados Son recursos Satisfacción del trabajo
Mejora Como inversión Imprescindible que sea continua
Énfasis Recursos productivos Personas
Evaluación Determinar el cumplimiento de los Criterios incluidos en el modelo
requisitos de calidad
Cómo evaluar Certificación Autoevaluación

2.4.2. Criterios del modelo

Principales criterios del modelo EFQM:

2.4.2.1. Liderazgo
Los líderes excelentes se basan en que estos:
Desarrollan la misión, visión, valores y principios éticos y actúan como modelo de referen-
cia.
Se implican personalmente para garantizar el desarrollo del sistema de gestión.

Interactúan con clientes, proveedores y representantes.

Refuerzan una cultura de excelencia entre el personal.
Definen e impulsan el cambio en la organización.

2.4.2.2. Política y Estrategia

La política y estrategia:
Se basan en las necesidades y expectativas actuales y futuras de los grupos de interés.

Se basan en la información de los indicadores de desempeño, la investigación, el aprendi-

zaje y las actividades externas.
Se desarrollan, revisan y actualizan.

2.4.2.3. Personas
Se evalúan:
Planificación, gestión y mejora de los recursos humanos.

Identificación, desarrollo y mantenimiento del conocimiento y la capacidad de las personas

de la organización.
Implicación y asunción de responsabilidades por parte de las personas de la organización.
Existencia de un diálogo entre las personas y la organización.

Recompensa, reconocimiento y atención a las personas de la organización.

10
2.4.2.4. Alianzas y recursos
Las organizaciones excelentes planifican y gestionan las alianzas externas, sus proveedores
y recursos internos en apoyo de su política y estrategia y del eficaz funcionamiento de sus
procesos, por lo que se determinan los siguientes subcriterios:
Gestión de las alianzas externas.
Gestión de los recursos económicos y financieros.
Gestión de los edificios, equipos y materiales.

Gestión de la tecnología.
Gestión de la información y del conocimiento.

2.4.2.5. Procesos
Se evalúa:
Diseño y gestión sistemática de los mismos.
Introducción de mejoras mediante innovación.

Diseño y desarrollo de productos y servicios basándose en las necesidades y expectativas

de los clientes.
Producción, distribución y servicio de atención, de los productos y servicios.
Gestión y mejora de las relaciones con los clientes.

2.4.2.6. Clientes
El modelo establece dos subcriterios basados en medidas de percepción y en indicadores de
rendimiento.

2.4.2.7. Resultados en las personas

Las organizaciones excelentes también miden de manera exhaustiva y alcanzan resultados
sobresalientes con respecto a las personas que las integran.

2.4.2.8. Resultados en la sociedad

De forma análoga a la anterior se evalúan los resultados en la sociedad.

2.4.2.9. Resultados clave de desempeño

Las Organizaciones Excelentes miden de manera exhaustiva y alcanzan resultados sobresa-
lientes con respecto a los elementos clave de su política y estrategia, para lo que se tiene en
cuenta tanto los resultados clave del desempeño de la organización como los indicadores clave
del desempeño de la organización.

2.5. Seis-Sigma
Tiene su origen en la estadística. Se puede considerar como una filosofía de gestión que
agrupa varias técnicas con el fin de conseguir procesos casi perfectos, cuyo origen se remonta a
1986 en la empresa Motorola.
Se basa en los siguientes presupuestos:
Prevenir defectos.

Reducir la variación.
Centrarse en el cliente.
Tomar decisiones basadas en hechos.
Alentar el trabajo en grupo.

11
Se proponen dos metodologías: DMAIC (mejorar un proceso existente) y DMADV (diseñar nue-
vos productos o procesos).

DMAIC se descompone en cinco fases:

Definir el problema e identificar lo que es importante.
Medir el proceso actual.
Analizar lo que está mal y las soluciones potenciales, determinando las causas de la varia-
ción.
Mejorar (Improve) el proceso implantando las soluciones.
Controlar el proceso mejorado asegurando que los cambios se mantienen.
DMADV también se descomponen en cinco fases:
Definir los objetivos del diseño teniendo en cuenta la demanda de los clientes.
Medir e identificar las características críticas para la calidad, capacidades del producto, del
proceso de producción, riesgos, etc.
Analizar alternativas de diseño.
Diseñar detalles, optimizar el diseño y planificar la verificación del diseño.
Verificar el diseño, poner en marcha la creación de un piloto, implementar el proceso de
producción y transferir el proceso al propietario del mismo.

2.6. Ejercicios
1. Analice la utilización de la aproximación Seis Sigma en la gestión de la calidad en diferen-
tes sectores: automóvil, servicios, defensa, etc.
Seis Sigma es un método de mejora continua que se propone específicamente para un
sector de fabricación pero que ha sido adaptada a otros sectores.
En el sector automovilístico los ejemplos de aplicación son:
Calidad en el proceso de suministros.
Seguridad y fiabilidad de automóviles acabados.
Reducción de defectos en cada etapa de producción.
Calidad de las piezas ya sean suministros simples o montajes.
Reducción del tiempo de fabricación.
Reducción de los defectos de diseño.
Calidad del proceso de diseño.
Reducción del tiempo para alcanzar la primera fabricación de un nuevo modelo.
En la fabricación en líneas de producción continua, los ejemplos son:
Mejorar el rendimiento de cada turno de producción.
Reducir materiales defectuosos y desechables.
Reducir los fallos del proceso de producción y las paradas completas.
Incrementar la capacidad de la planta.
Aumentar la productividad de los operarios.
Reducir el tiempo de reinicio del proceso después de una parada.
Crear mecanismos para prevenir fallos de los eslabones de la cadena.
Mejorar el control del proceso.
En el sector del desarrollo de software puede aplicarse a:

12
 Reducir el tiempo total de desarrollo de aplicaciones.
Reducir el número de errores que se encuentran en la fase de explotación.
Mejorar el proceso de estimación para reducir tiempo y coste.
Crear sistemas de detección de errores lo más pronto posible y de la forma más auto-
mática posible.
Reducir el coste por defectos en cada fase de producción de software.
Reducir el “re-trabajo” de aplicaciones ya entregadas y que deben rehacerse para
resolver errores encontrados en explotación.

En el sector del I+D se puede aplicar a:

Reducir el time-to market.
Reducir el “re-trabajo” de productos entregados a producción y que se devuelven a
desarrollo.
Minimizar los defectos en los diseños.
Mejorar la calidad de los diseños y sus revisiones.
2. Explique el papel que juegan en la filosofía Seis Sigma los roles de: Executive Leadership,
Champions, Master Black Belts, Black Belts, Green Belts y Yellow Belts.
Las personas que utilizan Seis Sigma se enmarcan dentro de roles que determinan las
tareas que deben realizar de las propuestas en el modelo. Los roles son de dos tipos: roles
del nivel de proyecto y roles de nivel de la organización.
Los roles de proyecto son:
Black belt: líderes de proyectos con dedicación total que los desarrollan en cualquier
ámbito de la organización.
Green belt: líderes de proyectos con dedicación parcial.
Master Black belt: formadores de personan que tienen el rol de Black belt o Green
belt.
Yellow belt: miembros del equipo de proyecto que deben aplicar las mejoras.
Withe belt: personas que colaboran con los equipos de proyecto Seis Sigma en tareas
de soporte dentro de la organización.
Los roles organización son:
Champions: traslada la visión de la organización a los planes de proyecto particula-
res. Realiza la coordinación de recursos y elimina barreras que se establezcan en la
ejecución de un proyecto.
Executives: realizan el alineamiento de los objetivos del programa Seis Sigma con el
contexto, la cultura y los objetivos de la organización.
3. Proponga una serie de indicadores que permitan verificar el grado de cumplimiento de los
ocho principios de gestión de la calidad que propone la familia de normas ISO 9000.

Principio Indicadores de ejemplo

Enfoque al el tipo de cliente al que le pueden resultar atractivos los productos

cliente la duración de la relación de nuestros clientes con nuestra organización
el papel del cliente en el diseño de nuevos productos
el apoyo que damos al cliente
el éxito que tenemos con nuestros clientes en cuanto a proporción de
compras y de quejas
Liderazgo directrices dadas al equipo
control del grupo
motivación del grupo
estabilidad del equipo
soluciones a las cuestiones que se plantean en el grupo
13
Principio Indicadores de ejemplo

Participación del se cuenta con un sistema de revisión y determinación de las

personal necesidades de capacitación y entrenamiento de todo el personal
se han establecido prácticas para evaluar el aprendizaje de los
empleados
existen programas que permiten el desarrollo de planes de carrera
se cuenta con esquemas para favorecer la participación del personal en
la mejora continua de la calidad
existe un programa de evaluación de la satisfacción del personal
se pueden detectar las insatisfacciones del personal
programas de trabajo en equipo tanto en el mismo área como entre
áreas de trabajo
Enfoque basado procesos identificados y repetidos
en procesos procesos con proveedores, entradas, salidas y clientes
procesos con indicadores de desempeño establecidos
procesos con funciones definidas
funciones definidas en procesos que tienen establecidos indicadores de
desempeño
grado de cumplimiento de los indicadores de funciones definidas en
procesos establecidos
Enfoque de existe una política de calidad
sistema hacia la existen mecanismos de difusión de la política de calidad
gestión existe una normativa propia o externa que sirva de base
se tienen asignados recursos y personal para la establecer, documentar
y mantener el sistema de gestión
existe un proceso para la puesta en marcha del sistema de gestión
existe un alcance definido del sistema de gestión
existe evaluación de la efectividad del sistema de gestión
Mejora continua está incluido el concepto de mejora continua en alguno de los
enunciados de la política de calidad o de la estrategia de la organización
existe promoción de la mejora continua entre el personal
existe compromiso de mejora continua de los procesos y de los sistemas
el personal conoce las actividades en las que debe participar para la
mejora continua
existe un programa de mejora continua
están definidas las funciones responsables del programa de mejora
continua
se conoce el impacto y los beneficios de la mejora
Enfoque basado la planificación y la estrategia está basada en hechos y datos
en hechos para la los objetivos están basados en hechos y datos
toma de decisión los problemas recurrentes se resuelven utilizando análisis de hechos y
datos
se tienen indicadores del negocio que permiten la recolección de datos
se tiene la práctica de documentación de los problemas que se repiten
con hechos y datos
se cuenta con sistemas de información que permiten la recolección de
datos para la toma de decisiones basados en hechos
Relación se cuenta con políticas de desarrollo de proveedores
mutuamente se tienen procesos sistemáticos para la selección y evaluación de
beneficiosa con proveedores
el proveedor se cuenta con un programa de desarrollo de proveedores
se evalúa el desempeño de los proveedores en términos de calidad

4. Analice los diferentes niveles de madurez propuestos por la norma ISO 9004 (principiante,
proactivo, flexible, progresivo, exitoso).

14
 Nivel de Nivel de
Comentario
madurez desempeño
No hay una aproximación sistemática que sea evidente.
1 Principiante
Los resultados son pobres o impredecibles.
Aproximación sistemática basada en problema o la
2 Proactivo prevención. Se disponen de los mínimos datos sobre la
mejora.
Aproximación sistemática basada en el proceso. Se usa
3 Flexible una etapa temprana de aplicación de las mejoras
sistemáticas. Hay objetivos y procesos de mejora.
Se usa el proceso de mejora continua y se detecta la
4 Progresivo
mejora de resultados y la tendencia de la mejora.
El proceso de mejora está integrado en la organización y
5 Exitoso
se evalúan los resultados de la mejora.

5. ¿Qué diferencias aprecia entre la construcción del software y la fabricación de otro tipo de
productos industriales? Analice hasta qué punto las normas de calidad presentadas en este
capítulo pueden ser aplicables a los sistemas informáticos.
Las principales particularidades en el proceso de construcción de software y que lo hacen
diferente a otros procesos productivos son:
El software es intangible
No hay un proceso único y estándar de creación de software
No hay una relación cerrada entre tipos de producto software y proceso que lo genera
El constructor último del software es el ingeniero de software

15
3. Calidad de los Sistemas Informáticos
3.1. Concepto de Calidad del Software
Una definición de calidad software bastante extendida es la que indica que es:
El grado con el que un sistema, componente o proceso cumple los requisitos
especificados y cubre las necesidades o expectativas del cliente o usuario.

Los requisitos especificados o explícitos se reflejan en la “Especificación de Requisitos del Soft-

ware” o ERS, documento que constituye la culminación de la etapa de análisis dentro del proceso
de desarrollo. La elaboración de estos requisitos es fundamental para lograr una alta calidad del
producto software.
Conceptos asociados a la calidad software:

Aseguramiento de la Calidad del Software: conjunto de actividades planificadas y siste-

máticas necesarias para proporcionar la confianza adecuada de que un producto o servicio
satisfará los requisitos dados de calidad.
Gestión de la Calidad de Software: aspecto de la función general de la gestión que deter-
mina y aplica la política y objetivos de calidad del software.

El concepto de aseguramiento ha sido englobado en el de gestión. Se podría incluir otro concepto

anterior a ambos, el Control de la Calidad Software, consistente en el conjunto de actividades
diseñadas para evaluar la calidad de los productos desarrollados.

3.1.1. Aseguramiento de la Calidad del Software

El SGC no puede tener en cuenta a todos los proyectos pasados, presentes y futuros. Si se
quiere realizar una gestión eficaz del software es necesario que muchas de las actividades se
hagan correctamente, y es necesaria una organización que se preocupe de realizar este segui-
miento.
El Aseguramiento de la Calidad Software implica la revisión y la inspección de los productos
y de las actividades de software, con objeto de verificar que se cumplen los procedimientos y
estándares aplicables.
Para ello, el aseguramiento de la calidad software debe:
Planificar las actividades de aseguramiento de la calidad software.
Verificar objetivamente que tanto los productos como las actividades software cumplen los
requisitos, estándares y procedimientos establecidos.

Informar a los grupos afectados sobre las actividades y resultados del aseguramiento de la
calidad software.
Elevar a la dirección aquellos aspectos que no puedan solucionarse en el contexto del
proyecto.

3.1.2. Gestión de la Calidad del Software

Tradicionalmente la gestión de la calidad ha seguido dos orientaciones que pueden conside-
rarse complementarias.
Por una parte se ha incorporado la tendencia establecida por las entidades internacionales
de estandarización. Principalmente se han impuesto las marcadas por ISO a través de la serie
9000. El hecho de que el sector software sea tan diferente del resto de sectores productivos ha
llevado a la creación de una guía específica para su aplicación, el anexo ISO 90003. Este enfoque
se dirige en asegurar la calidad del proceso empleado en la producción como medio indirecto
de asegurar la calidad.
Por otra parte la gestión de software ha creado su propia línea de trabajo aplicada a la gestión
de calidad tomando ideas básicas del anterior enfoque. El modelo CMM (Capacity Madurity
Model) clasifica los procesos usados en las organizaciones de desarrollo software.

16
3.2. Situación de la calidad de SI
Sólo el 32 % de los proyectos informáticos finalizan en el tiempo estimado, con los recursos
planificados y con una calidad aceptable, mientras que casi una cuarta parte (24 %) no llegan a
finalizar nunca. El resto lo hace pero consumiendo más recursos o con menos funcionalidades
de los previstos. Proponen distintos niveles de madurez que determinan la forma de trabajar de
una organización.

3.3. Importancia de la calidad en los SI

Durante los setenta la productividad era la preocupación de moda, sustituida en los ochenta
por la calidad, y en los noventa por el time-to-market y el desarrollo rápido. Las organizaciones
deberían considerar la importancia del time-to-market para su éxito, teniendo en cuenta los dos
factores que determinan el mercado: la cantidad de consumidores y de proveedores.

Figura 2: Mercados según la cantidad de consumidores/proveedores

Estos dos factores definen cuatro mercados:

Capacidad. Cuando se inicia un mercado, la capacidad de ofrecer un producto es lo más

importante. Los primeros clientes están dispuestos a obtener menos calidad de la habitual.
Coste. Con muchos proveedores y pocos consumidores, el consumidor es quien dicta la
calidad que desea. Hay que conseguir la calidad deseada al menor coste posible.

Time-to-market. Con pocos proveedores compitiendo por muchos consumidores, lo más

importante será poner el producto lo antes posible en el mercado.
Calidad. En los mercados maduros la calidad es el determinante principal del éxito.

3.4. Componentes de la calidad de un SI

La calidad de un SI puede descomponerse en diferentes factores que contribuyen a la misma.
Proponemos un modelo sencillo, que denominamos de las “cinco pes”, en el que se destaca
cómo la calidad de un sistema informático depende de la calidad de:

Las personas que desarrollan, mantienen y operan el software.

Los procesos de los que dispone la organización.
Los productos incluyendo tanto aplicaciones como datos/información.

Los proyectos que se llevan a cabo.

Las plataformas que se utilizan en el desarrollo, mantenimiento y operación del software.

17
3.5. Calidad de un SI y la Gestión del Conocimiento
3.5.1. Necesidades de la Gestión del Conocimiento en Organización de Software
Todas las organizaciones que desarrollan y mantienen software comparten las siguientes
necesidades:
Comprender los procesos y productos.
Evaluar los éxitos y fracasos.
Aprender de las experiencias.
Empaquetar experiencias exitosas.
Reutilizar experiencias exitosas.
Las organizaciones dedicadas al desarrollo del software requieren y generan grandes cantida-
des de conocimiento de diverso tipo acerca de todos los componentes que identificamos en el
apartado anterior: producto, procesos, proyecto, personas y plataformas.
La calidad de los SI no puede ser mejorada si todo este conocimiento no se encuentra dispo-
nible o no se utiliza adecuadamente.
En este sentido la gestión del conocimiento permite “producir mejor software, de una forma
más rápida y económica, así como tomar mejores decisiones”, ya que facilita:
La localización de fuentes de conocimiento.
La reutilización de experiencias.
La mejora de los procesos de desarrollo del software.
La reutilización de artefactos del proceso de desarrollo.
Existen organizaciones de todo tipo que empiezan a adoptar arquitecturas de gestión de conoci-
miento como la que se muestra en la figura. La gestión de conocimiento se puede considerar el
nexo que une las actividades de producción diarias con las iniciativas de mejora y los objetivos
de negocio.
En las organizaciones software, la gestión del conocimiento se da específicamente en las
siguientes áreas:
Gestión de configuración y control de versiones, ya que los sistemas de este tipo crean
indirectamente la memoria del proyecto, que indica la evolución del software y puede
servir para identificar expertos.
Decisiones de diseño, que es una aproximación que consiste en capturar explícitamente
decisiones de diseño para crear una memoria del producto.
Trazabilidad, que contribuye indirectamente a la memoria del producto.
Informe de problemas y trazabilidad de defectos, los cuales, pudiéndose considerar fuen-
tes de conocimiento “negativo”, podrían llegar a transformarse en conocimiento “positivo”.
Herramientas CASE y entornos de desarrollo de software.

3.5.1.1. Técnicas y Herramientas para la Gestión del Conocimiento Diferentes técnicas y

herramientas para la gestión del conocimiento:
Sistemas cooperativos y de trabajo en grupo
Aprendizaje asistido por ordenador
Sistemas de gestión documental, bibliotecas y repositorios de conocimiento
Sistemas de soporte a la toma de decisiones
Portales e intranets de conocimiento
Modelos de predicción
...

18
 Figura 3: Arquitectura de gestión de conocimiento

3.5.1.2. Implantación de la gestión del Conocimiento

Existen tres factores que posibilitan el proceso de implantación de estrategias de gestión del
conocimiento en las organizaciones de software:
La tecnología disponible en la organización para los desarrolladores, que le permitirá crear
un repositorio de memoria organizacional accesible.
El liderazgo que pretende impulsar la gestión de conocimiento en el desarrollo de los
productos y servicios software así como en los procesos de trabajo.
La cultura organizacional que soporte la compartición de conocimiento, experiencias, tec-
nologías e innovación.
Para garantizar el éxito de un programa de gestión del conocimiento es obligatorio elegir el mo-
delo de gestión del conocimiento adecuado.

Estrategia Modelo de Tipo de

Organización Conceptos
empresarial gestión conocimiento
Reducción de Base de
Productividad Compartir, evitando redundancia Explícito
costes información
Especializa- Procesos
Calidad Mejores prácticas Explícito
ción comunes
Conocimiento
Innovación Creatividad Integración y combinación de conocimiento Tácito
dinámico

3.5.2. Modelos de Gestión de Conocimiento en Ingeniería del Software

3.5.2.1. Modelo de Dybå (2003)
Modelo dinámico que se centra en las necesidades de comunicación, coordinación y colabo-
ración. Trata de cómo los equipos de software adquieren y utilizan conocimiento en un entorno
organizacional para mejorar sus procesos software. Consta de cuatro elementos principales:
Contexto organizacional, que describe el entorno general que impone restricciones y opor-
tunidades acerca de lo que puede y no puede hacer la organización.

19
 Ciclo de aprendizaje, que comprende el proceso dialéctico que integra la experiencia local
y los conceptos organizacionales.
Desempeño organizacional, que agrupa los resultados de las actividades de mejora de la
organización.
Factores facilitadores, que reflejan las condiciones que facilitan la creación de conocimiento
y la mejora de procesos software.
Define la creación del conocimiento en Ingeniería del Software como el intercambio dinámico
entre dos dialécticas: entre el conocimiento organizacional y el local; y entre la generación y la
interpretación del conocimiento organizacional.

3.5.2.2. Modelo Seks

Este modelo reconoce la interacción entre los individuos y dentro de los equipos como pro-
ducto de tres factores; motivación para descubrir conocimiento, una cultura de apoyo y la expe-
riencia previa. Asociados a estos factores se encuentran el deseo y la oportunidad de aprender.
Las dificultades más importantes son hacer tácito el conocimiento explícito y mantenerlo
actualizado.

3.6. Factoría de experiencia y Paradigma de Mejora de la Calidad (QIP)

3.6.1. QIP (Paradigma para la mejora de la calidad)
El paradigma de mejora de la calidad (QIP, Quality Improvemente Paradigm) es una aproxi-
mación a la medición y control de la calidad dirigida por objetivos, basada en una estructura
organizativa denominada “factoría de experiencia”.
El objetivo de este paradigma es la adquisición de competencias básicas que soporten compe-
tencias estratégicas y la mejora de la calidad en el entorno de desarrollo mediante la reutilización
del conocimiento y la experiencia.
El proceso de mejora de la calidad es iterativo y ocurre en seis pasos agrupados en dos ciclos:
1. Ciclo de Aprendizaje Corporativo:

Caracterización, la empresa construye modelos del entorno actual.

Fijación de objetivos.
Elección de procesos, métodos, técnicas y herramientas adecuadas.

2. Ciclo de aprendizaje de Proyecto:

Se inicia con la ejecución.

La organización analiza los resultados para aprender de ellos.
La organización almacena y propaga el conocimiento.

3.6.2. Factoría de Experiencia

Consiste en una organización basada en la capacidad, en la que la reutilización de expe-
riencia y el aprendizaje colectivo se convierten en cuestión corporativa. Proporciona cluster de
competencias denominados paquetes de experiencias.
La organización de proyectos proporciona a la factoría de experiencia características del pro-
yecto y entorno, datos de desarrollo, información sobre la utilización de recursos, registros de
calidad, información sobre el proceso, los productos, planes y modelos utilizados, así como los
datos obtenidos durante el desarrollo y la explotación. La factoría de experiencias transforma
estos elementos en unidades reutilizables y proporciona, a la organización de proyectos, confi-
guraciones base, herramientas, lecciones aprendidas, y datos, parametrizados de alguna forma
para adaptarse a las características de los proyectos específicos.

20
3.6.3. Base o Repositorio de Experiencia
Una base de experiencia debe:
Contener el conocimiento relevante para la organización.
Residir en un marco de aprendizaje bien concebido.
Disponer de metodologías que establezcan cómo se estructura la experiencia.
Estar automatizada lo máximo posible.
Hay que tener en cuenta diferentes aspectos de calidad a la hora de construir y gestionar un
repositorio de experiencia:
Guía al usuario, sobre todo para empezar reutilizando las experiencias.
Usabilidad, ya que una pobre usabilidad puede alejar al usuario.
Conformidad con el proceso, hacer un proceso mejorado centrado en el repositorio de
experiencias, siguiendo la estructura del proceso subyacente.
Mecanismos de realimentación, por medio de diferentes canales (correo electrónico, piza-
rras, FAQ, contactos telefónicos, etc.).
Mantenibilidad, para que las restructuraciones sean fáciles.

3.7. Ejercicios
1. Analice en qué cuadrante del marco propuesto por Card (1995) se situarían las siguientes
técnicas:

a) Desarrollo rápido de aplicaciones (RAD).

b) Orientación a objetos.
c) Herramientas CASE.
d) Métodos ágiles.
e) Líneas de producto software.

a) Mercado de calidad. La técnica de desarrollo rápido de aplicaciones estaría enmarcada

en el mercado de calidad puesto que en estos momentos estamos habituados a soft-
ware que se fabrica rápido y existen muchos proveedores. Un ejemplo es el mercado
de las Apps que se rige directamente por la técnica RAD y se orienta al gran público
a través de las tiendas de las plataformas.
b) Mercado de calidad. La técnica de orientación a objetos (ídem al anterior).
c) Mercado de capacidad. Herramientas CASE. Pocos consumidores y pocos proveedores.
d) Mercado de calidad. Métodos ágiles (ídem a y b).
e) Mercado “Time to market”. Líneas de productos software. Pocos proveedores para mu-
chos consumidores.

3. Estime, consultando las fuentes bibliográficas que considere oportuno, el coste total debido
a la baja calidad del software en el que puede haber incurrido su país o comunidad.
Respecto al “estado del arte” en la calidad y la certificación del software en España lo
habitual es que las empresas prefieren establecer sus propios medios de medición. Lo que
normalmente valoran los clientes como signo de calidad es la entrega a tiempo y que el
valor del software se corresponda con su precio. La dificultad para medir la calidad del
software radica en la naturaleza especial del software que en vez de fabricarse, en sentido
clásico, se desarrolla y además de forma artesanal ya que normalmente se construye a
medida. Por ello el coste se lo lleva el diseño y el producto final es más lógico que físico.
A nivel de empresa, la calidad debe formar parte de la política general y la dirección debe
expresarla explícitamente diciendo lo que debe hacerse y haciendo lo que se dice. Además

21
debe considerarse la posibilidad de conseguir una certificación de terceros. Lo habitual en
nuestro país es que no exista una cultura de la innovación y la calidad en las organizaciones
y podríamos definir la calidad del software en España como desconocida, aunque algunos
y evidencias apuntan a una calidad errática. En muchas empresas se han institucionalizado
las malas prácticas y se nota una carencia de profesionales y una necesidad de reciclaje de
los existentes. La calidad en el software es proporcionar a los clientes lo que quieren, de
acuerdo con unos estándares y unas especificaciones de los que desean, con un grado
predecible de fiabilidad y uniformidad, a un precio que se ajusta a sus necesidades. Para
obtener software de calidad no basta con aplicar una ingeniería del producto adecuada, sin
considerar todos los procesos que intervienen en su desarrollo de una manera integrada,
sistemática y sincronizada para obtener un producto de calidad, en los plazos y coste
acordados.
Según los estudios específicamente en España, se señalan como fallos más frecuentes en
proyectos software la desviación de tiempo de proyectos, los costes de mantenimiento y
una calidad desconocida en la mayor parte de los proyectos realizados. Este último punto
se apoya en el hecho de que un 28 % de las empresas de software españolas no utilizan
ningún modelo de calidad en el periodo 2006-2010.

22
4. Aplicación práctica (apuntes E.D.)
4.1. El departamento de calidad en las organizaciones
Los cinco elementos de cualquier sistema de gestión de la Calidad son: la estructura de la
organización, el plan de calidad, los recursos, los procesos y los procedimientos. La estructura
organizacional es la jerarquía de funciones y responsabilidades que define una organización. El
primer criterio que se debe tener en cuenta a la hora de fijar la estructura es la dimensión de la
organización que se quiere implantar.

4.1.1. Entornos pequeños: quality circles

Definición Un círculo de calidad es un pequeño grupo de trabajadores que realizan una serie
de tareas similares en un área de trabajo común y bajo un mismo responsable. Son ellos mismos
quienes identifican, seleccionan y analizan las opciones de mejora de su propio trabajo.

Ámbito Los círculos de calidad se utilizan en entornos organizativos pequeños y permiten

aplicar el concepto de “calidad total” en el sentido de que la calidad se mejora de forma continua
en el trabajo.

Puntos más importantes

La calidad. Se puede considerar como el gran objetivo de los círculos; los mercados son
cada vez más competitivos y los clientes tienen un mayor nivel de exigencia, lo que provoca
que la calidad sea una preocupación central para la mayor parte de las empresas.
La productividad. Los círculos pueden colaborar a incrementar la productividad en todas
las áreas de la empresa.
La mejora de costes. El conocimiento de los costes evita el despilfarro y la mala adminis-
tración de los recursos.

La motivación. Gracias a los círculos se puede motivar de una forma más constante a los
trabajadores, ofreciéndoles oportunidades de participar en los objetivos de la empresa y de
sentirse valorados.
La integración. Los círculos facilitan la ruptura de los compartimentos estancos, y hacen
que sus integrantes conozcan y valoren el trabajo de los demás.
La reorganización. Cuando una reorganización puede ser lenta en el tiempo, es una buena
alternativa encomendar a los círculos el estudio de dicha reorganización.

Características Algunas son las siguientes:

La participación en el círculo es voluntaria.
Son grupos pequeños, de 4 a 12 personas.
Sus miembros suelen formar parte de un equipo que tiene objetivos comunes.

Se reúnen periódicamente para analizar y resolver los problemas que ellos mismos descu-
bren.
Deben participar diversas categorías laborales.
No tiene relación jerárquica de autoridad y dependencia, sus miembros son igualitarios.

El objetivo es el deseo común de mejorar la técnica de trabajo.

El líder es elegido por los miembros y puede ir cambiando.

23
Técnicas empleadas Brainstorming o generación espontánea de ideas. Se procura que los par-
ticipantes den el máximo número de ideas, sin importar su calidad.
Técnicas de registro de la información, usando la hoja de registro y el muestreo. La Hoja
de Registro permite al círculo organizar la información obtenida en un formato que puede ser
fácilmente entendido y analizado.
Técnicas de análisis de información, donde se incluyen las tablas resumen de información y
diversos tipos de gráficas.
Técnicas de análisis de problemas, donde sobresale el diagrama causa-efecto, que es una
representación gráfica de la relación que existe entre las causas potenciales de un problema y el
problema mismo.

4.1.2. El departamento de calidad

El departamento de calidad puede estructurarse de formas muy variadas y distintas, pero se
suelen seguir tres modelos básicos:

Modelos de inspección.
Modelos de control de calidad.
Modelo de aseguramiento de calidad.

Modelo de inspección La inspección consiste en separar los productos con defectos. Implica la
realización de una operación automática o manual que incrementa el coste del producto creado
y que además limita la detección de fallos a cuando estos ya se han producido.
Aparece un grupo funcional en la organización encargado de las inspecciones.

Figura 4: Grupo de Inspección y su orden en la jerarquía

Modelo de control de calidad El control de calidad consiste en medir y evaluar la calidad del
producto en todas las fases del proceso. Implica la utilización de un control estadístico basado
en muestreos y controles que permiten asegurar la conformidad de los productos. La principal
ventaja de este modelo es que permite introducir una prevención gracias al control de entrada.
Las organizaciones suelen introducir un grupo de control de calidad en la jerarquía departa-
mental.

Modelo de aseguramiento de calidad Es sinónimo de administración de la calidad o de mejora

continua de la producción. Las actividades incluyen la forma en la que se hacen las cosas, el
control de los procedimientos o la evaluación posterior a la producción. Se tienen en cuenta otros
recursos como auditorías, evaluaciones internas/externas, o las políticas y estrategias globales
de calidad.
Se encuentra en organizaciones con una estructura que reconozca el grupo de aseguramiento
de la calidad dependiendo directamente de la máxima responsabilidad de la organización. El
grupo de aseguramiento de la calidad emite directrices generales y asiste a todos los niveles

24
 Figura 5: Grupo de Control de Calidad en la jerarquía departamental

de la organización (se puede considerar como una organización autónoma que interviene en el
resto).

Figura 6: Grupo de Aseguramiento de Calidad en la jerarquía de la empresa

4.2. Contenido práctico: guía de implantación de la norma ISO 9001:2008

4.2.1. Introducción
Las compañías que desean certificarse en un SGC deberían hacerlo en base a la norma ISO
9001:2008. Más de 176 países la han adoptado como norma nacional. Esta norma especifica los
requisitos para un SGC aplicables cuando la organización necesita:
Demostrar su capacidad para suministrar de forma consistente productos que satisfagan
los requisitos del cliente y los requisitos reglamentarios aplicables.
Conseguir la satisfacción del cliente a través de la efectiva aplicación del sistema, incluyen-
do procesos de mejora continua y la prevención de no conformidades.
La organización debe establecer, documentar, implementar, mantener y mejorar continuamente
la eficacia de un SGC de acuerdo con los requisitos de esta Norma.

Documentación que debe incluir el Sistema de Gestión de la Calidad

Declaraciones documentadas de una política y de objetivos de calidad.

25
 Un manual de la calidad.
Los procedimientos documentados requeridos por la norma.
Los documentos requeridos por la organización para la planificación, operación y control
eficaz de sus procesos.
Los registros de la calidad requeridos por la norma ISO 9001.
Estos documentos son: Manual de Calidad, Manual de Procedimientos, Instrucciones de tra-
bajo, Planes de Calidad específicos, Especificaciones de materiales y/o productos, Registros y
formularios.

Manual de Calidad Refleja los compromisos de la Dirección y sirve de explicación de cómo se

gestiona la Calidad.

Manual de Procedimientos Lo constituyen todos los procedimientos operativos que describen

las distintas actividades de la empresa para asegurar que se consigue un producto o servicio
conforme a los requisitos del cliente.

Instrucciones de trabajo Son las que describen específicamente cómo se llevan a cabo las ac-
tividades que describen los procedimientos. Sólo se realizan en función de la complejidad de la
actividad.

Planes de Calidad Recoge la forma de operar, recursos necesarios y secuencia de actividades

para proporcionar un producto o servicio concreto a un cliente.

Especificaciones de producto o servicio Establece los requisitos referenciados a Normas y

otros parámetros proporcionados por el proveedor y que describen las características del pro-
ducto o servicio. Nos permite comprobar que lo recibido cumple con esos requisitos y que es lo
que le ofrecemos al cliente.

4.2.2. Apartados de la norma

La norma exige la aplicación de TODOS los requisitos. Podrían excluirse algunos siempre y
cuando no afecten a la capacidad de la organización.
Los requisitos generales de la norma se deben cumplir durante el diseño del sistema de
gestión, tanto en el diseño inicial como en las modificaciones que se vayan introduciendo. Los
requisitos son en esencia resultados que debe proporcionar el análisis de las necesidades de la
organización y de sus clientes de acuerdo con las expectativas de la Dirección y los recursos
disponibles. Resumiendo„ los requisitos generales demandan que se determine cómo vamos a
hacer las cosas (procesos necesarios), qué recursos hacen falta, y cómo vamos a controlar los
resultados.
El conjunto de todos los requisitos demandados y su mutua interconexión conforman el
modelo ISO 9001:2008.

4.3. Contenido práctico: guía de implantación del manual de calidad

La organización debe planificar y desarrollar los procesos necesarios para la realización de
un producto, que además debe ser consistente con los requisitos de otros procesos del SGC.

4.3.1. Guía del Plan de Calidad

Se muestra un plan de calidad para un proyecto determinado de desarrollo software.
1. Propósito y alcance del plan de calidad.
El propósito es especificar las actividades que se llevarán a cabo con objeto de asegurar
que el producto final tiene la calidad deseada.
Afecta a los siguientes productos y fases del ciclo de desarrollo:

26
 Plan de gestión de configuración.
Plan del proyecto.
Plan de calidad.
Documento de especificación de requisitos software.
Diagramas de flujo de datos y modelo E/R.
Plan de pruebas y aceptación del sistema.
Diagramas de estructuras, modelo de datos relacional y pantallas.
Plan de pruebas de integración.
Código.
2. Gestión de la calidad
Las tareas a realizar por el responsable de calidad son:
Ayudar a que el equipo de proyecto realice su trabajo de calidad. La forma de cumplir
este objetivo es comprobando el grado en el que los miembros del equipo del proyecto
registran sus datos de forma exacta y completa.
Guiar al equipo en la realización de un producto de calidad.
Moderar e informar de forma adecuada al equipo en las inspecciones realizadas. Las
inspecciones se deben realizar según el procedimiento previsto y se deben rellenar los
datos correspondientes.
Dirigir al equipo en la realización y seguimiento del plan de calidad. Se deben acordar
los productos y criterios que se seguirán para obtener productos de alta calidad.
Informar al responsable del proyecto cuando existan problemas de calidad.
Establecer estándares de documentación, codificación, etc.
Revisar y aprobar todos los productos antes de que sean entregados al Comité de
Control de Cambios para su introducción en la línea base del proyecto.
Ser el moderador de las inspecciones del equipo.
El responsable de calidad no formará parte del equipo de desarrollo con objeto de no caer
en responsabilidades de desarrollo que tiendan a omitir la calidad.
3. Métricas
Algunos ejemplos de medias relativas a las “tasas de revisión e inspección” y de “rendi-
mientos de fase” son:
Tasa de revisión e inspección en la fase de requisitos.
Tasa de revisión e inspección en la fase de diseño de alto nivel.
Rendimiento en las inspecciones de requisitos.
Rendimiento en las revisiones e inspecciones de diseño.
4. Revisiones, inspecciones y auditorías
En esta sección se deberán describir los procedimientos concretos que se llevan a cabo para
realizar las revisiones, inspecciones y auditorías.

4.3.2. Guía del Manual de Calidad

Dentro del Manual de Calidad se debe incluir:
El alcance del Sistema de Gestión de la Calidad, incluyendo los detalles y la justificación
de cualquier exclusión.
Política y Objetivos de la calidad.
Los procedimientos documentados establecidos para el Sistema de Gestión de la Calidad,
o una referencia a los mismos.
Una descripción de la interacción entre los procesos del Sistema de Gestión de la Calidad.

27
Política de la Calidad La alta dirección debe asegurar que:
Es adecuada al propósito de la organización.
Incluye el compromiso de satisfacer los requisitos y de mejorar continuamente la eficacia
del SGC.
Proporciona un marco de referencia para establecer y revisar los objetivos de la calidad.
Se comunica y entiende dentro de la organización.
Se revisa para mantenerla adecuada continuamente.

Objetivos de Calidad La alta dirección debe asegurar que los objetivos de la calidad se esta-
blecen en las funciones y niveles pertinentes dentro de la organización. Los objetivos deben ser
medibles y coherentes con la política de la calidad.
Los objetivos deben comunicarse claramente a todo el personal, que debería ser capaz de
trasladarlos a sus contribuciones individuales.

Responsabilidad de la Dirección La alta dirección debe designar a un miembro quien, con

independencia de sus otras responsabilidades, debe tener la responsabilidad y autoridad que
incluya:
Asegurar que se establecen, implantan y mantienen los procesos necesarios para el SGC.
Informar a la alta dirección sobre el desempeño o funcionamiento del SGC y de cualquier
necesidad de mejora.
Asegurar que se promueva la toma de conciencia de los requisitos de los clientes en todos
los niveles de la organización.
La alta dirección debe asegurar que se establecen los procesos apropiados de comunicación
dentro de la organización y que la comunicación se efectúa considerando la eficacia del SGC.
Reuniones informativas.
Revistas internas.
Email, web.
Los niveles de la organización.
La alta dirección debe revisar el SGC para asegurar su continua consistencia, adecuación y
eficacia. También debe asegurar que la planificación del SGC se lleva a cabo con el fin de cumplir
los requisitos dados en el apartado 3.1 (requisitos generales), así como los objetivos de la calidad,
y que se mantiene la integridad del SGC cuando se planifican e implementan cambios en éste.

Gestión de los Recursos La organización debe determinar y proporcionar los recursos necesa-
rios para:
Implementar y mantener el SGC y mejorar continuamente su eficacia.
Aumentar la satisfacción del cliente.
Los recursos pueden incluir:
Personal
Suministradores
Información
Ambiente laboral
Infraestructura
Recursos financieros

28
Realización del Producto La organización debe planificar y llevar a cabo la producción y el
suministro del servicio bajo condiciones controladas, las cuales deben incluir (cuando sea apli-
cable):

La disponibilidad de información que describa las características del producto.

La disponibilidad de instrucciones de trabajo.
La utilización del equipo apropiado.
La disponibilidad y utilización de equipos de medición y seguimiento.

La implementación de actividades de seguimiento y medición.

La implementación de actividades de liberación, entrega postventa.
La organización debe validar todo el proceso de las operaciones de producción y de servicio en
aquellos puntos en los que los elementos de salida resultantes no puedan verificarse mediante
actividades de seguimiento o medición.

Medición y Seguimiento La organización de medir y hacer un seguimiento de las caracte-

rísticas del producto para verificar que se cumplen todos los requisitos. Debe realizarse en las
etapas apropiadas del proceso de realización del producto. No se debe proceder a la liberación
del producto o a la entrega del servicio hasta que se hayan completado satisfactoriamente todos
los preparativos planificados.

Control del Producto No Conforme La organización debe asegurar que el producto que no se
sea conforme con los requisitos se identifica y se controla para prevenir su utilización o entrega
no intencionada. Los controles y las responsabilidades para tratar los productos no conformes
deben estar definidas en un procedimiento documentado.
La organización debe tratar los productos no conformes mediante una o más de las siguientes
maneras:
Tomando acciones para eliminar la no conformidad detectada.
Autorizando su utilización, liberación o aceptación cuando corresponda por el cliente.
Tomando acciones para prevenir su utilización o aplicación original.

Deben mantenerse registros de la naturaleza de las no conformidades y de cualquier acción

tomada posteriormente, incluyendo las concesiones que se hayan obtenido.

Medición, Análisis y Mejora La organización debe planificar e implementar los procesos de

seguimiento, medición, análisis y mejora necesarios para:
Demostrar la conformidad del producto.
Asegurar la conformidad del SGC.
Mejorar continuamente la eficacia del SGC.

Análisis de Datos La organización debe determinar, recopilar y analizar los datos apropiados
para demostrar su adecuación y la eficacia del SGC y para evaluar donde puede realizarse
la mejora continua del SGC. Debe incluir los datos generados del resultado de la medición y
seguimiento, y de cualquier otra fuente pertinente. Debe proporcionar información sobre:
La satisfacción del cliente.
La conformidad con los requisitos del producto.
Las características y tendencias de los procesos y de los productos.

Los proveedores.

29
Mejora Continua La organización debe mejorar continuamente la eficacia del SGC por medio
de la utilización de:
La política de la calidad.

Los objetivos de la calidad.

Los resultados de las auditorías.
El análisis de los datos.

Las acciones correctivas y preventivas.

La revisión por la dirección.

Acciones Correctivas La organización debe tomar acciones correctivas para eliminar la causa
de no conformidades con objeto de prevenir su repetición. Las acciones correctivas deben ser
apropiadas a los efectos de las no conformidades encontradas. Se debe establecer un procedi-
miento documentado para definir los requisitos para:
Revisar las no conformidades (incluyendo las quejas de los clientes).

Determinar las causas de las no conformidades.

Evaluar la necesidad de adoptar acciones para asegurar que las no conformidades no vuel-
van a ocurrir.
Determinar e implementar las acciones correctivas necesarias.

Registrar los resultados de las acciones tomadas.

Revisar las acciones correctivas tomada.

Acciones preventivas La organización debe determinar las acciones preventivas para eliminar
las causas potenciales de no conformidad al objeto de prevenir su ocurrencia. Se debe establecer
un procedimiento documentado para definir los requisitos para:
Determinar no conformidades potenciales y sus causas.
Evaluar la necesidad de actuar para prevenir la ocurrencia de no conformidades.

Determinar e implementar las acciones preventivas necesarias.

Registrar los resultados de las acciones tomadas.
Revisar las acciones preventivas tomadas.

30
Parte II
Calidad de Productos
5. Calidad de producto software
5.1. Modelos clásicos
Históricamente se han desarrollado para evaluar la calidad de los productos software di-
ferentes modelos que pretenden seguir las directrices de calidad de otros tipos de productos:
descomponer la calidad en una categoría de características más sencillas que facilita su estudio.
Todos estos modelos clásicos requieren identificar métricas para esas características de cali-
dad que permitan medir cuantitativamente cómo de bueno es un software atendiendo a esos
criterios.

5.2. Normas ISO sobre calidad de producto software

La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, espe-
cialmente las normas ISO/IEC 9126 e ISO/IEC 14598, que proporcionan diferentes métricas y
normas:

ISO/IEC TR 9126-2: Métricas externas.

ISO/IEC TR 9126-3: Métricas internas.
ISO/IEC TR 9126-4: Métricas para calidad en uso.
ISO/IEC 14598-1: Visión general.

ISO/IEC 14598-2: Planificación y gestión.

ISO/IEC 14598-3: Proceso para desarrolladores.
ISO/IEC 14598-4: Proceso para compradores.
ISO/IEC 14598-5: Proceso para evaluadores.

ISO/IEC 14598-6: Documentación de módulos de evaluación.

Estas dos familias de normas cubren la mayor parte de los aspectos relacionados con la evalua-
ción de productos software, tal y como se ve en la Figura 6:
En el año 1999 se empezó a discutir la revisión de estas normas, dando lugar a la fami-
lia ISO/IEC 25000, conocida como SQuaRE (Software Quality Requirements and Evaluation), que
presenta varias ventajas:
Mayor coordinación entre la evaluación y la medición de la calidad de un producto soft-
ware.
Una guía para la especificación de requisitos de calidad.

Mejor armonización con otras normas como la ISO/IEC 15939.

5.3. Familia de normas ISO 25000

Esta familia de normas se organiza en cinco apartados principales:
ISO/IEC 2500n – División de Gestión de Calidad. Normas que definen todos los modelos,
términos y definiciones comunes referenciados por todas las otras normas de la familia.
ISO/IEC 2501n – División de Modelo de Calidad. La norma presenta un modelo de cali-
dad detallada incluyendo características para calidad interna, externa y en uso.

31
 Figura 7: Relaciones entre las normas ISO/IEC 9126 e ISO/IEC 14598.

ISO/IEC 2502n – División de Medición de Calidad. Normas que incluyen un modelo de

referencia de la medición de la calidad del producto, definiciones de medidas de calidad
(interna, externa y en uso) y guías prácticas para su aplicación.
ISO/IEC 2503n – División de Requisitos de Calidad. Normas que ayudan a especificar
requisitos de calidad que pueden ser utilizados en el proceso de licitación de requisitos de
calidad del producto software a desarrollar.
ISO/IEC 2504n – División de Evaluación de Calidad. Apartado que incluye normas que
proporcionan requisitos, recomendaciones y guías para la evaluación de productos softwa-
re.

5.3.1. Normas sobre Gestión de Calidad (ISO/IEC 2500n)

La norma ISO/IEC 2500n proporciona una visión general de la nueva serie 25000 (SQuaRE),
así como los términos y definiciones relacionados con la calidad de producto software.

5.3.2. Normas sobre Modelado de Calidad (ISO/IEC 2501n)

Esta parte de la familia está compuesta principalmente por dos normas: ISO/IEC 25010:
Systems and software engineering, e ISO/IEC 25012: Software engineering. Se proponen tres modelos
de calidad: modelo de calidad de producto software y modelo de calidad en uso del sistema (ISO
25010); y modelo de calidad de datos (ISO/IEC 25012).
La norma clasifica además las propiedades del software en:
Inherentes, que a su vez distingue entre propiedades funcionales específicas de dominio
(qué puede hacer el software) y propiedades de calidad (adecuación funcional, operabili-
dad, seguridad, etc.).
Asignadas, que son propiedades de gestión: precio, fecha de entrega, futuro del producto,
etc.

5.3.2.1. Modelo de calidad de producto software

Este modelo distingue ocho características de calidad de un producto software.
Adecuación funcional Capacidad del producto software para proporcionar funciones que satis-
facen necesidades declaradas e implícitas cuando se usa en las condiciones especificadas.

32
 Completitud funcional. Grado en el cual el conjunto de funcionalidades cubre todas
las tareas y los objetivos del usuario especificados.
Corrección funcional. Capacidad del producto o sistema para proveer resultados co-
rrectos con el nivel de precisión requerido.
Adecuación funcional. Capacidad del producto software para proporcionar un con-
junto apropiado de funciones para tareas y objetivos de usuario especificados.

Fiabilidad Capacidad de un sistema o componente para desempeñar las funciones especifica-

das, cuando se usa bajo las condiciones y el periodo de tiempo especificados.

Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en con-
diciones normales.
Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible
para su uso cuando se requiere.
Tolerancia a fallos. Capacidad del sistema o componente para operar según lo pre-
visto en presencia de fallos hardware o software.
Capacidad de recuperación. Capacidad del producto software para recuperar los da-
tos directamente afectados y restablecer el estado deseado del sistema en caso de
interrupción o fallo.

Eficiencia de desempeño Trata del desempeño relativo al total de recursos utilizados bajo de-
terminadas condiciones.

Comportamiento temporal. Los tiempos de respuesta y procesamiento y los ratios de

throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determi-
nadas en relación con un banco de pruebas establecido.
Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el soft-
ware lleva a cabo su función bajo condiciones determinadas.

Capacidad de Uso Capacidad del producto software de para ser entendido, aprendido, usado
y resultar atractivo para el usuario, cuando se usa bajo determinadas condiciones.

Capacidad para reconocer su adecuación. Capacidad del producto que permite al

usuario entender si el software es adecuado para sus necesidades.
Capacidad para ser usado. Capacidad del producto que permite al usuario operarlo
y controlarlo con facilidad.
Protección contra errores de usuario. Capacidad del sistema para proteger a los usua-
rios de hacer errores.
Estética de la interfaz de usuario. Capacidad de la interfaz de agradar y satisfacer la
interacción con el usuario.
Capacidad de aprendizaje técnico. Capacidad del producto que permite al usuario
aprender su aplicación.
Accesibilidad técnica. Capacidad del producto que permite que sea utilizado por
usuarios con determinadas discapacidades.

Seguridad Capacidad de protección de la información y los datos de manera que personas o

sistemas no autorizados no puedan leerlos o modificarlos, y que las personas o sistemas
autorizados sí puedan.

Confidencialidad. Capacidad de protección contra el acceso de datos e información

no autorizados, ya sea accidental o deliberadamente.
Integridad. Capacidad del sistema o componente para prevenir accesos o modifica-
ciones no autorizados.
No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de
manera que dichas acciones o eventos no puedan ser repudiados posteriormente.

33
 Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una
entidad.
Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.

Compatibilidad Capacidad de dos o más sistemas o componentes para intercambiar informa-

ción y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hard-
ware o software.

Coexistencia. Capacidad del producto para coexistir con otro software independiente,
en un entorno común, compartiendo recursos comunes sin detrimento.
Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercam-
biar información y utilizar información intercambiada.

Mantenibilidad Capacidad del producto software para ser modificado efectiva y eficientemente.

Modularidad. Capacidad de un sistema o programa de ordenador que permite que

un cambio en un componente tenga un impacto mínimo en los demás.
Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un
sistema software o en la construcción de otros activos.
Capacidad para ser analizado. Facilidad con la que se puede evaluar el impacto de un
determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas
de fallos en el software, o identificar las partes a modificar.
Capacidad para ser modificado. Capacidad del producto que permite que sea modi-
ficado de forma efectiva y eficiente sin introducir defectos o degradar el desempeño.
Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de
prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas
para determinar si se cumplen dichos criterios.

Portabilidad Capacidad del producto o componente de ser transferido de forma efectiva y efi-
ciente de un entorno hardware, software, operacional o de utilización a otro.

Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efecti-
va y eficiente a diferentes entornos determinados de hardware, software, operaciona-
les o de uso.
Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o
desinstalar de forma exitosa en un determinado entorno.
Capacidad para ser remplazado. Capacidad del producto para ser utilizado en lu-
gar de otro producto software determinado con el mismo propósito y en el mismo
entorno.

5.3.2.2. Modelos de calidad en uso del sistema

La norma 25010 entiende por calidad en el uso la capacidad del producto software para permitir a
determinados usuarios alcanzar determinados objetivos con efectividad, eficiencia, seguridad y satisfacción
en determinados contextos de uso. Contempla las siguientes características:
Efectividad Capacidad del producto software para permitir a los usuarios alcanzar determina-
dos objetivos con exactitud y compleción.
Eficiencia Esta característica considera los recursos empleados en relación con la exactitud y
compleción con las que el usuario consigue sus objetivos.
Satisfacción Capacidad del producto software para satisfacer a los usuarios en un contexto de
uso especificado.
Libre de riesgos Capacidad del producto o sistema para alcanzar niveles aceptables del riesgo
de hacer daño a la vida, salud o propiedades de las personas, o al medio ambiente en un
determinado contexto de uso.
Cobertura del contexto Capacidad del producto de ser utilizado por determinados usuarios
para conseguir sus objetivos con efectividad, eficiencia y satisfacción en un determinado
contexto de uso.

34
5.3.2.3. Modelo de calidad de datos
La norma entiende por calidad de datos la capacidad de las características de los datos de satisfacer
necesidades explícitas e implícitas bajo determinadas condiciones de uso. Sus características se clasifican
considerando dos puntos de vista:
1. Inherente. Capacidad de las características de los datos de tener el potencial intrínseco
para satisfacer las necesidades explícitas e implícitas. Las características que se consideran
en este apartado son:

Precisión. Capacidad de los datos para representar correctamente el valor verdadero

de los atributos de un concepto o evento.
Compleción. Capacidad de los datos de tener valores para todos los atributos esperados
e instancias de entidad relacionadas.
Consistencia. Capacidad de los datos de estar libres de contradicciones y de ser cohe-
rentes.
Credibilidad. Capacidad de los datos de ser considerados verdaderos y creíbles por los
usuarios.
Actualidad. Capacidad de los datos de tener el tiempo adecuado.

2. Dependiente del sistema. Capacidad del sistema informático de alcanzar y preservar la

calidad de los datos cuando estos se utilizan en determinadas condiciones. Contempla:

Disponibilidad. Capacidad de los datos de poder ser recuperados por los usuarios au-
torizados.
Portabilidad. Capacidad de los datos de poder ser instalados, reemplazados o trasla-
dados de un sistema a otro preservando la calidad.
Recuperabilidad. Capacidad de los datos de mantener y preservar un nivel especificado
de operaciones y de calidad, incluso en caso de fallo.

5.3.3. Normas sobre Medición de Calidad (ISO 2502n)

El modelo de medición de calidad distingue entre diferentes tipos de medidas: internas,
externas y de calidad de uso. Las primeras (visión de “caja blanca”) tratan de las propiedades
estáticas del software que se pueden evaluar durante su desarrollo.
Las medidas externas (visión “caja negra”) tratan propiedades relacionadas con la ejecución
del software en un hardware y un sistema operativo.
Las medidas de calidad en uso se obtienen a partir de pruebas o mediante la observación de
resultados en el uso simulado o real del sistema.

5.3.4. Normas sobre Requisitos de Calidad (ISO 2503n)

La norma 25030 se centra en requisitos de calidad software desde una perspectiva sistémica.
Comenta el proceso de definición de requisitos de los beneficiarios (stakeholders) y el proceso de
análisis de requisitos. También repasa la jerarquía de los requisitos del sistema.
Distingue entre propiedades del software inherentes (propiedades funcionales y de calidad)
y asignadas (precio, proveedor, etc.).
En la norma se muestra cómo se derivan los requisitos de calidad del software y el papel que
juegan las normas ISO/IEC 25010 en la definición de los requisitos de calidad de los stakeholders
e ISO/IEC 2502n para formalizar los requisitos de calidad.
También establece requisitos para los propios requisiots de software, en cuanto a su identifi-
cación, documentación, trazabilidad, etc.

5.3.5. Normas sobre Evaluación de Calidad (ISO 2504n)

La ISO/IEC 25040 propone un modelo de referencia para la evaluación, que considera tanto
las entradas al proceso de evaluación y los recursos disponibles para obtener las correspondien-
tes salidas (plan de evaluación, medidas, criterios de decisión, resultados e informe de evalua-
ción, etc.).

35
 En la Figura 8 se resume las tareas del proceso de evaluación que se agrupan en cuatro
actividades:

Figura 8: Modelo de referencia del proceso de evolución de la Calidad de Producto Software.

Establecer los requisitos de la evaluación. Incluye:

• Establecer el propósito de la evaluación, predecir la calidad del producto final, selec-

cionar el producto entre alternativas, decidir la liberación del producto, etc.
• Obtener los requisitos de calidad del producto software, identificando los stakeholders
del mismo.
• Identificar las partes del producto incluidas en la evaluación, especificación de requi-
sitos, documentación de diseño, etc.

36
 • Definir la rigurosidad de la evaluación teniendo en cuenta el presupuesto, la fecha
objetivo de la evaluación, etc.

Especificar la evaluación. Incluye:

• Seleccionar medidas de calidad (módulos de evaluación).

• Definir criterios de decisión para medidas de calidad (con la suficiente precisión).
• Establecer criterios de decisión para la evaluación, de forma separada para cada ca-
racterística de calidad.

Diseñar la evaluación. Consiste en planificar las actividades de evaluación teniendo en

cuenta los recursos disponibles.

Ejecutar la evaluación. Se compone de:

• Realizar las mediciones, de acuerdo al plan de evaluación.

• Aplicar los criterios de decisión a las medidas.
• Aplicar los criterios de decisión para la evaluación.

Finalizar la evaluación. Se compone de:

• Revisar el resultado de la evaluación, incluyendo los comentarios sobre la evaluación

en la versión final del informe.
• Eliminar los datos de la evaluación, según lo acordado con el solicitante de la evalua-
ción.

5.3.6. Otras normas de la Familia 25000

La norma ISO/IEC 25051 define requisitos de calidad para productos COTS y los requisitos
para la documentación de pruebas cuyo propósito es demostrar la conformidad del software con
los requisitos.
La ISO/IEC TR 25060 define una familia de estándares que documentan la especificación y
evaluación de la usabilidad de los sistemas interactivos.

5.4. Ejercicios
1. Compare las características y subcaracterísticas de calidad del modelo de McCall y del
modelo propuesto en la norma ISO 25010, ¿cuál le parece más completo?, ¿a qué elementos
de la calidad le concede más importancia McCall?, y ¿a cuáles la norma 25010?, ¿encuentra
similitud entre ambos?
En el caso de McCall podemos agrupar las once características del modelo en tres grupos:
Revisión del Mantenibilidad
producto Flexibilidad
Testeabilidad
Transición del Portabilidad
producto Reusabilidad
Interoperabilidad
Operación del Correctitud
producto Confiabilidad
Eficiencia
Integridad
Usabilidad
En el caso del ISO 25010, agrupamos según las características internas, externas y de uso:

37
 Internas y externas Funcionalidad
al producto Seguridad
Interoperabilidad
Fiabilidad
Mantenibilidad
Usabilidad
Eficiencia
Portabilidad
Uso del producto Usabilidad de uso
Contexto de uso
Riesgo
Adaptabilidad
Algunas de las subcaracterísticas del modelo ISO 25010 son características del modelo
de McCall. Por ejemplo la característica de Corrección aparece en el modelo 25010 como
subcaracterística de Funcionalidad. Lo mismo ocurre con otras características de McCall
como Flexibilidad, Facilidad de prueba, Reusabilidad o Interoperabilidad.
De forma general el modelo 25010 es más completo y cubre más características.
2. Como señala Kan (2003), los parámetros de satisfacción del cliente que monitoriza IBM
son: capacidad, funcionalidad, usabilidad, desempeño, fiabilidad, instalabilidad, mante-
nibilidad, documentación/información y servicio, mientras que Hewlett-Packard utiliza:
funcionalidad, usabilidad, fiabilidad, desempeño y servicio; compare estos parámetros con
las características de la norma ISO 25010.
Para representar las características de los tres modelos presentamos la tabla:
ISO 25010 IBM HP
Capacidad de uso Capacidad Desempeño
Compatibilidad Desempeño Fiabilidad
Eficiencia del desempeño Documentación Funcionalidad
Fiabilidad Fiabilidad Usabilidad
Funcionalidad Funcionalidad Servicio
Portabilidad Instalabilidad
Seguridad Mantenibilidad
Servicio
Usabilidad
En los dos modelos de las compañías aparece la característica del “Servicio” que en el caso
del ISO 25010 está incluida como subcaracterística de la capacidad de uso. Sin embargo
hay otras características del ISO 25010 que no se consideran en los modelos corporativos
como Seguridad, Portabilidad o Compatibilidad.

3. Tomando como base el proceso de selección propuesto por la norma ISO 25040 defina un
proceso de selección para herramientas de análisis y diseño orientado a objetos, adaptando
si fuera necesario el modelo de calidad de la ISO 25010. Compare el modelo definido con
la norma ISO 14102.
El estándar ISO 25040 propone como pasos del proceso de evaluación seguir los siguientes
apartados:
Preparar y establecer los requisitos de evaluación.
Especificar la evaluación.
Diseño de la evaluación.
Evaluar.
Documentar para concluir.
Si lo que se quiere es realizar una evaluación de herramientas CASE podrían plantearse de
forma resumida los siguientes pasos:

38
 Establecer los requisitos Los requisitos de evaluación se considerarán en los siguientes
aspectos: soporte para el modelado, mantenimiento de los modelos realizados, docu-
mentación y configurabilidad de la herramienta.
Especificar la evaluación Los requisitos anteriores deben evaluarse en características con-
cretas y medibles que podemos obtener del estándar ISO 25010. Por ejemplo, en el
caso de la capacidad de modelado podríamos obtener las siguientes medidas: funcio-
nalidad de la edición de UML estándar, adecuación de la edición UML, rendimiento
en la edición UML y usabilidad de la edición UML.
Diseñar la evaluación Es necesario diseñar un plan de evaluación a partir de los requisitos
y la especificación de la evaluación. Una opción posible es considerar la evaluación
basándose en un cuestionario en el que fijamos puntuaciones.
Ejecutar la evaluación El propósito de la evaluación de la ejecución es el de obtener los
resultados de la realización de acciones para medir y verificar el producto de software
de acuerdo con los requisitos de evaluación, tal como se indique en la especificación
de evaluación y como estaba previsto en el plan de evaluación.
Informar la evaluación Los informes de evaluación se generan una vez que se dispone
de la información en conjunto de todas las medidas sobre las herramientas. Debe
ajustarse a la norma ISO/IEC 25041:2012.
Respecto al ISO 14102 para la evaluación de herramientas CASE proporciona un método
sistemático para la evaluación y adopción de este tipo de herramientas, una equivalencia
entre los requisitos y las características a evaluar y un proceso de selección para determinar
la mejor opción en cada caso.
En general el proceso de selección propuesto en este estándar es similar al propuesto
con carácter general según el ISO 25040 puesto que propone básicamente cuatro pasos:
inicial que dé lugar a los requisitos que la organización tiene para el uso de la herramienta
CASE, un paso de estructuración que determina el marco de evaluación, el paso de la
evaluación que genera un informe de evaluación, y un paso final de selección que aplica
los criterios fijados en la estructuración al informe de evaluación para dar lugar a un
informe de selección.
4. Compare las diferentes propuestas existentes sobre modelos de calidad para componentes
–por ejemplo Simao y Belchior (2003) o Berton et al. (2005)– analizando qué características y
subcaracterísticas de la norma ISO 25010 se han adoptado tal cual, modificado o descartado
para este tipo de software.
Los modelos más amplios como el ISO 9126 o el ISO 25000 no son adecuados para su
aplicación a este tipo de software. Intentan proponer mdoelos basados en la obtención de
medidas sobre las características particulares de este tipo de software. En concreto y co-
mo ejemplo, el modelo propuesto por Simao y Belchior propone un total de 124 atributos
organizados según seis características básicas como la funcionalidad, la fiabilidad, la usa-
bilidad, la eficiencia, la mantenibilidad y la portabilidad y desde tres puntos de vista: el
dominio de aplicación, la función en la arquitectura y el nivel de abstracción. Todos estos
atributos se evalúan siguiendo un cuestionario de preguntas que permiten realizar la eva-
luación de los elementos individuales y se integran utilizando un modelo de agregación
basado en lógica difusa en el que se pondera la importancia de cada atributo en el modelo
según una tabla de valores creada por expertos en software de componentes.
5. Desarrolle un proceso de análisis y selección para sistemas de información geográfica (SIG)
teniendo en cuenta las características distintivas de este tipo de sistemas. Proponga a con-
tinuación diferentes formas de medir las características propuestas.
Siguiendo el estándar 25040 es necesario determinar los cuatro pasos: análisis, especifica-
ción, diseño y realización. El análisis de los requisitos de la evaluación se puede plantear
en tres niveles: en el nivel básico puede utilizarse ISO 25010 para el modelo de calidad del
producto SIG y el ISO 25030 para el modelo de calidad de uso del SIG. un segundo nivel
podría tener en cuenta cuestiones como el presupuesto y las fechas de entrega; y un tercer
nivel sirve para definir los niveles mínimos esperados en la evaluación.
Como no se indica nada en relación al punto de vista del evaluador del SIG podrían
plantearse dos opciones: una que se tratara de la visión de un explotador/desarrollador

39
del sistema, y otra que se tratara sólo de la visión de un usuario. Consideremos únicamente
este segundo punto de vista.
De acuerdo al estudio, la experiencia y la observación de los sistemas SIG, podemos deter-
minar que los atributos a considerar en la evaluación del uso de los SIG son: productividad,
curva de aprendizaje, satisfacción de uso y tasa de fallos. Los factores que podemos consi-
derar pueden ser:
Términos/conceptos usados en el SIG son claros y no ambiguos.
Uso de conceptos técnicos en acciones de usuario.
Navegación de funcionamiento básico.
Mensajes de error claros y no ambiguos.
Uso de convenciones estándar en los mapas.
Calidad de la presentación del mapa.
Alternativas de acciones sobre el mapa: zoom/pan/layer.
etc. . .

40
6. Calidad del producto de software (apuntes E.D.)
6.1. Introducción a la medición del software
6.1.1. Conceptos básicos de la medición
La necesidad de medir es evidente en la mayoría de las actividades técnicas o científicas.
Definimos medición como el proceso por el cual se asignan números o símbolos a tributos de entidades
del mundo real de tal forma que los describan de acuerdo a reglas claramente definidas.
Toda medición debe asegurar una adecuada representación del atributo real medido median-
te los símbolos o números asignados. Así, los datos obtenidos como medidas deben representar
los atributos de las entidades reales que pretendemos caracterizar y el manejo de dichos datos
debe preservar las relaciones que existen entre dichas entidades. Para establecer medidas debe-
mos partir de nuestra observación del mundo real o dominio. Debemos identificar cuáles son las
entidades que queremos medir (p.ej. código) y definir qué atributo deseamos caracterizar (p.ej.
longitud de código).
Es importante identificar las relaciones empíricas que se pueden establecer entre las entida-
des reales en relación con el atributo que nos interesa. Pueden ser simples comparaciones que
establecen un orden o relaciones de otros tipos. Se puede hablar entonces del dominio como de
un sistema de relaciones empíricas. La medición asigna un valor a cada entidad para caracte-
rizar su atributo y debe establecer también qué relación entre valores se corresponde con cada
relación empírica. Lo importante es que la medición que establezcamos no resulte inconsistente
con las relaciones observadas en el mundo real.
Se podrían establecer múltiples representaciones para un mismo sistema de relaciones em-
píricas. En general, cuantas más relaciones empíricas estén especificadas, más se restringe la
variedad de representaciones posible. Una asignación que se establece entre mundo real y valo-
res de medida se suele denominar escala de medición. Podemos presentar cinco tipos principales
de escalas de medición:

Nominal: se clasifica cada entidad (p.ej. código) en grupos (COBOL, Basic, Java, etc.).
Ordinal: se clasifican las entidades en grupos pero estableciendo un orden (p.ej. fallos de
software: parada de sistema, mal funcionamiento, leve o cosmético).
De intervalo: establece un orden y además informa sobre que la diferencia existente entre
un valor y otro consecutivo en orden es siempre la misma.

De ratio: además de lo dicho para la escala de intervalo, tenemos un cero de referencia

(p.ej. longitud de código: número de líneas).
Absoluta: además de lo dicho para la escala de ratio, se mide siempre contando elemen-
tos y sólo es posible una representación: la cuenta real de elementos (p.ej. el número de
personas en un proyecto sólo se puede medir contándolas).

6.1.2. Métricas del software

Se define como métrica a una medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo dado. Las métricas son la maduración de una disciplina, que ayudan a
la evaluación de los modelos de análisis y de diseño, en donde proporcionarán una indicación
de la complejidad de diseños procedimentales y de código fuente, y ayudarán en el diseño de
pruebas más efectivas. Un modelo de medición básico propone cinco actividades:
1. Formulación. La obtención de medidas y métricas del software apropiadas para la repre-
sentación de software en cuestión.
2. Colección. El mecanismo empleado para acumular datos necesarios para obtener las mé-
tricas formuladas.
3. Análisis. El cálculo de las métricas y la aplicación de herramientas matemáticas.
4. Interpretación. La evaluación de los resultados de las métricas en un esfuerzo por conse-
guir una visión interna de la calidad de la representación.

41
 5. Realimentación. Recomendaciones obtenidas de la interpretación de métricas técnicas
transmitidas al equipo de software.
Está demostrado que no existe un conjunto de métricas que puedan aplicarse de forma uni-
versal, e independiente de lenguajes, entornos o metodologías de programación, por lo que los
elementos básicos que debemos considerar a la hora de determinar una métrica son:
Complejidad de la métrica: cuánto nos cuesta obtenerla.
Calidad de la medida: cómo de bien mide, en términos de corrección y precisión.
Utilidad de la medida: realmente sirve para algo en términos de consistencia y utilidad en
el proceso de medición.

6.2. Métricas del Software

A continuación se presentan algunos comentarios y ejemplos de métricas relacionadas con el
producto software.

6.2.1. Métricas internas

Se acepta que la calidad externa de un determinado producto dependerá siempre de su
calidad interna. La mayor parte de los métodos en ingeniería del software proporcionan técnicas
heurísticas enfocadas justamente a conseguir que la calidad interna de los productos sea buena.
Los cinco atributos internos que vamos a considerar son:
1. Tamaño (físico o longitud).
2. Reutilización (en términos de producto reusado).
3. Funcionalidad (en términos de lo que hace para el usuario).
4. Complejidad (en términos de lo complejo del problema que resuelve).
5. Estructura lógica (complejidad estructural).

6.2.1.1. El tamaño del software

Cada producto software puede definirse en términos de su tamaño. Medir el tamaño de es-
tos productos resulta relativamente complejo por todos los componentes que intervienen en su
construcción. Existen tres productos software sobre los que es interesante medir el tamaño: el
código, las especificaciones y el diseño.
Para el tamaño del código se ha medido tradicionalmente el número de líneas de código
(LOC: Lines Of Code). Esta medida presenta muchas cuestiones. La primera es cómo conside-
rar determinadas líneas de código especiales, como las líneas en blanco, los comentarios o los
delimitadores.
De forma general la métrica más aceptada es la llamada NCLOC (Non Commented or blank
Lines Of Code) o ELOC (Effective Lines Of Code), que define el tamaño del código como una lista
de código en el que se han eliminado todas las líneas de código y todos los comentarios. En
cualquier caso puede resultar más útil medir el tamaño completo como:

TOTAL( LOC ) = NCLOC + CLOC (Commented Lines O f Code)

Otra consideración respecto al tamaño es la cantidad de código reusado/nuevo/modificado

que se debe considerar a la hora de medir. Así, una alternativa que se define es el tamaño de
líneas entregadas o DSI (Delivered Source Instructions):

DSI = TOTAL( LOC ) − CLOC − DLOC ( Debugging LOC )

Como variante de esta métrica se define EDSI (Effective Delivered Source Instructions) como
DSI más las sentencias efectivas que se encuentran en un misma línea física de código.
Una de las medidas clásicas del software es la propuesta por Halstead, que define un progra-
ma P como una colección de tokens que se clasifican en operadores y operandos. Las métricas
básicas para medir el tamaño de un programa son:

42
 µ1 : número de operadore únicos
µ2 : número de operandos únicos
N1 : número de ocurrencias de los operadores
N2 : número de ocurrencias de los operandos

A partir de estas medidas básicas se derivan métricas como la longitud de P:

N ( P) = N1 + N2

El vocabulario de P:

µ ( P ) = µ1 + µ2

El volumen de P:

V ( P) = N ( P) ∗ log2 µ( P)

Que se interpreta como el número de comparaciones mentales necesarias para escribir un

programa de longitud N.
El esfuerzo de implementar un programa se mide en términos de este volumen con la fór-
mula:
N1
E( P) = V ( P)
2N2

Que sería las discriminaciones mentales para hacer un programa. Y desde este esfuerzo y
aplicando estudios psicológicos sobre las capacidades de discriminar en el cerebro humano,
Halstead fija el tiempo como:

E( P)
T ( P) =
β

siendo β una constante fijada a 18.

Una de las cuestiones más controvertidas respecto a las métricas Halstead es fijar el concepto
de operando y operadores en cada lenguaje. Una vez fijado este criterio, debe asegurarse que se
aplica siempre de la misma forma para poder obtener resultados coherentes.

Ejemplo de métricas Halstead Dado el siguiente fragmento de código en Java, calcular las
medidas de Halstead para el procedimiento ordenar que implementa:
1 void ordenar(int vector, int tamano) {
2 int i, j, t;
3 if(tamano<2) return;
4 for(i=0; i<tamano; i++) {
5 for(j=i+1; j<n; j++) {
6 if(vector[i]>vector[j]) {
7 t=vector[i];
8 vector[i] = vector[j];
9 vector[j] = t;
10 }
11 }
12 }
13 }

Si tomamos el criterio de ignorar la declaración del procedimiento ordenar y contamos el

resto de operadores y operandos en las siguientes tablas:

43
 Operador No de Operador No de
ocurrencias Ocurrencias
< 3 = 5
> 1 [] 6
- 1 { 3
, 2 } 3
; 9 + 1
( 4 ++ 2
) 4 for 2
if 2 int 1
return 1

Y los operandos:

Operando No de Operando No de
ocurrencias Ocurrencias
0 1 i 8
1 2 j 7
2 1 tamano 3
vector 6 t 3

El resultado de las medidas de Halstead es:

N1 = 50, N2 = 30, µ1 = 17, µ2 = 7

Por lo tanto el volumen de P es:

V ( P) = (50 + 30) ∗ log2 (17 + 7) ≈ 392 operaciones

Y el esfuerzo:
17 ∗ 30
E( P) = 392 ≈ 14112
2∗7
Que pasado al factor de tiempo se queda en 793 segundos que son aproximadamente 13
minutos. Ahora siempre cabe la pregunta: ¿corresponde esta medida con su estimación personal
para resolver el problema de ordenación planteado?

6.2.1.2. Medir la reutilización La reutilización del software es una de las actividades más
utilizadas en la construcción de software. En ocasiones no está claro a lo que se llama reutili-
zación ni cómo se mide esta mejora. Se pueden encontrar diferentes modelos de métricas de
reutilización:
Modelos de nivel de reutilización: sirven para estimar cuánto hemos reutilizado diferen-
ciando código nuevo de código reutilizado o adaptado.
Modelos de reusabilidad: describen el patrón de un componente reutilizable. Esta medida
es de interés desde la perspectiva del desarrollo para reutilización.
Modelos de influencia de la reutilización: estiman cuánto se ha mejorado con la reutiliza-
ción.

Modelos económicos que incluyen:

44
 • Modelos de coste-beneficio. Se considera tanto los costes como los beneficios del desa-
rrollo sin reutilización y con reutilización.
• Modelos de ahorro de costes. Permiten estimar la inversión ahorrada por la reutiliza-
ción de productos existentes.
• Modelos de recuperación de la inversión con reutilización o ROI: permiten estimar el
beneficio neto de la reutilización tras haber consumido ciertos recursos.

Comentaremos algunas de las métricas más empleadas. El porcentaje de reutilización (PR) es

una medida estándar definida como:
So f tware reutilizado
PR = ∗ 100
So f tware total

Esta medida es fácil de usar siempre que quede bien establecido lo que es reusado dentro
del total; ¿se debe incluir un elemento reusado tantas veces como se use o sólo una?. En algún
modelo, para evitar este tipo de cuestiones, se prefiere hablar en términos de medida de objetos
software: módulos, macros, objetos, etc. Se define así un nuevo porcentaje de reutilización PR1
con la siguiente fórmula:
 
1
PR1 = 1 − ∗ 100
IR

Siendo IR (Influencia de la Reutilización):

( Total de objetos usados)

IR =
( Total de nuevos objetos construidos)

De esta forma se cuenta tanto la reutilización interna como la externa.

Ejemplo de métricas de reutilización en POO. Existen diversas medidas de reutilización

que intentan calcular el beneficio de la reutilización a partir del porcentaje de reutilización (PR)
y de diversos factores propios del diseño orientado a objetos. Comentaremos dos brevemente:
el CRR (Coste Relativo de la Reutilización) y el CRER (Coste Relativo de la Escritura para
Reutilizar).
El CRR representa el ratio del esfuerzo que es necesario para reutilizar software frente al
esfuerzo necesario para desarrollar el software para usarlo una vez. Por ejemplo, si podemos
reusar el 20 % del coste de un nuevo desarrollo, diremos que el CRR es 0,2.
El CRER representa el ratio de esfuerzo que es necesario para desarrollar software que sea
reutilizable frente al esfuerzo necesario para desarrollar el software para usarlo una vez. Por
ejemplo, si el coste para hacer un análisis de reutilización, crear un diseño genérico de objetos,
documentación, etc. es de un 50 % adicional al inicial, diremos que el CRER es 1,5.
El CRR y el CRER dependen de cada organización y de otros factores. Si lo que buscamos
es una medida del coste podemos calcular el Beneficio Total de Reutilización (BTR) y los Cos-
tes Adicionales de Desarrollo por Reutilización (CADR), Así, el retorno de la inversión de un
proyecto se define como la suma de los beneficios totales de reutilización menos los costes adi-
cionales de desarrollo por reutilización:
n
Project ROI = ∑ BTRi − CADR
i =1

Y el BTRi en cada caso se calcula como la suma de los Beneficios por Reutilización en la fase
de Desarrollo (BRD) y los Beneficios por la fase de Mantenimiento (BRM):

BTRi = BRDi + BRMi

El beneficio por reutilización se contabiliza como lo que nos ahorramos en el coste de desa-
rrollo:

BDRi = IR ∗ (1 − CRR) ∗ (Coste nuevo código )

45
 Siendo IR las instrucciones reusadas y (1-CRR) el porcentaje del esfuerzo ahorrado por la
reutilización.
En cuanto a los beneficios por la fase de mantenimiento, se pueden calcular como:

BDMi = IR ∗ ( Tasa de errores) ∗ (Coste Error )

En cuanto a los costes adicionales por reutilización los calculamos como:

CADR = (CRER − 1) ∗ (C ódigo escrito por reusar ) ∗ (Coste nuevo código )

Como ejemplo, supongamos un desarrollo completo realizado por tres equipos de trabajo que
cada uno ha realizado un subsistema. Estos equipos han reusado en librerías de clases y métodos
10KLOC el primer equipo, 15KLOC el segundo y 5KLOC el tercero (total IR = 30KLOC). La
mayor parte de estas IR proceden de una librería en la que se invirtió en su momento. Además
los tres equipos han necesitado 1500 LOC adicionales de librerías nuevas y que han quedado
incorporadas al repositorio. Suponemos que el CRR es 0,2 y el CRER es 1,5. Además conocemos
que la tasa de error de los ingenieros involucrados en el proyecto es 1,5 por cada KLOC y el
coste de fijar un error es de 5.000 . El coste establecido en la organización es de 100 /LOC para
el desarrollo de nuevas aplicaciones. Calcular el Project ROI final en este proyecto.
Es necesario obtener los beneficios por la reutilización, primero en desarrollo:

BDRi = IR ∗ (1 − CRR) ∗ (Coste nuevo código ) = 30 KLOC ∗ (1 − 0, 2) ∗ 100 = 2, 4 millones

Y el mantenimiento:

30 KLOC
BDMi = IR ∗ ( Tasa errores) ∗ (Coste error ) = ∗ 5000/error
1, 5 errores/KLOC
= 20 errores ∗ 5000/error = 0, 1 millones
Por lo tanto el total es:

BTRi = BRDi + BRMi = 2, 4 + 0, 1 = 2, 5 millones

Ahora es necesario quitar el coste adicional que hemos tenido en la reutilización:

CADR = (CRER − 1) ∗ (C ódigo escrito por reusar ) ∗ (Coste nuevo código )

= (1, 5 − 1) ∗ 1500 LOC ∗ 100/LOC = 0, 075 millones
Y por lo tanto el Project ROI total será de:
n
Project ROI = ∑ BTRi − CADR = 2, 5 − 0, 075 = 2, 425 millones
i =1

6.2.1.3. Funcionalidad del Software

Otro de los atributos internos del software que más se suele considerar es la cantidad de fun-
ciones que se implementan. Este atributo prefiere considerar qué debe realizar el software frente
al tamaño que ocupa para resolverlo. Las métricas se centran en realizar la estimación del tama-
ño en función de las funciones que implementa o que debe contener según las especificaciones.
Encontramos la métrica de la funcionalidad de Albrecht (los puntos función), los puntos función
Mark II y la métrica Bang.
El Análisis de Puntos Función (FPA) nos proporcionará una medida objetiva de la funciona-
lidad de una aplicación software. Está basado en la teoría de que las funciones de una aplicación
software son la mejor medida de su tamaño. Este método tratará de determinar el número total
de Puntos Función de un sistema, basándose únicamente en los documentos técnicos que recogen
la especificación de requisitos funcionales. El análisis de Puntos Función tratará de determinar,
tan pronto como sea posible, la funcionalidad que proporciona a los usuarios una determinada
aplicación software. Para el conteo de Puntos Función se han de seguir una serie de pasos con-
cretos basados en reglas y criterios específicos hasta llegar al resultado final. Dicho resultado no
es único, sino que de la aplicación FPA pueden derivarse otros, a saber:

46
 Cuenta del número total de Puntos Función sin ajustar.
Cuenta de Puntos Función para cada componente del sistema.

Factor de Ajuste (VAF) o Factor de Complejidad Técnica.

Cuenta del número total de Puntos Función ajustados.
Informes de validación de resultados.
Los datos de partida necesarios para comenzar el proceso de análisis de PF suelen estar locali-
zados en documentos técnicos que recogen:
Objetivos que se pretenden cubrir, necesidades y requerimientos del usuario.
Toda la información disponible acerca del sistema actual (si existe).
Cualquier objetivo específico que se pretenda para el nuevo sistema y restricciones concre-
tas que puedan existir.
El interfaz gráfico de usuario que se desea.
Los interfaces existentes con otros sistemas.
Los modelos de datos físicos y/o lógicos preliminares.

El proceso de análisis de PF consta de ocho pasos:

1. Planificación del conteo de Puntos Función. El proceso de FPA puede aplicarse a cualquier
otra etapa del ciclo de vida. Una vez concluido el proceso de conteo, es recomendable
comparar el resultado con otros obtenidos en etapas anteriores. Así podremos tener en
cuenta el impacto provocado por la introducción de nuevos componentes.

2. Recogida de información. Disponer de la siguiente documentación nos resultará bastante

útil: objetivos que se pretenden cubrir, necesidades y requerimientos del usuario, informa-
ción acerca del sistema actual (si existe).
3. Cálculo del Factor de Ajuste (VAF). EL VAF debería calcularse ya en las primeras ocasiones
en las que se realiza el conteo de Puntos Función para, más adelante, ir recalculándolo y
actualizándolo según vayamos obteniendo más información.
El VAF está basado en 14 Características Generales del Sistema (GSC) que evalúan la
funcionalidad general de la aplicación que se está midiendo. Cada GSC tiene asociada una
serie de cuestiones cuya respuesta se escala de cero (sin influencia) a cinco (esencial).
Una vez que se ha determinado la influencia de cada GSC en el sistema, se utiliza la
siguiente fórmula para obtener el valor del VAF:

14
VAF = 0, 65 + 0, 01 ∑ Fi
i =1

Siendo Fi el valor adjudicado a cada GSC.

4. Inventariado de transacciones lógicas y ficheros lógicos. Es necesario contabilizar las en-
tradas externas, las salidas externas y las consultas externar para conformar el conjunto de
transacciones lógicas. Por ejemplo en un programa de corrección ortográfica tendríamos
dos entradas –el nombre del fichero a examinar y el nombre del diccionario personalizado–
, tres salidas –número total de palabras revisadas, número de errores encontrados y lista de
palabras erróneas–, dos peticiones al sistema –el usuario puede saber en cualquier instan-
te el número de palabras procesadas hasta ese momento y la lista de palabras erróneas–,
dos ficheros externos –el archivo a examinar y el diccionario personalizado– y un fichero
interno –el diccionario general–. En este ejemplo, el número total de elementos del sistema
sería: 2 + 3 + 2 + 2 + 1 = 10.

47
 5. Clasificación de componentes. Una vez que se han inventariado tanto las transacciones
lógicas como los ficheros lógicos, puede procederse a la clasificación de los componentes
del sistema. Se trata de determinar la complejidad de cada componente (algo subjetivo) y
tabular los resultados.
6. Revisión de las 14 características generales del sistema (GSC’s). Es necesario volver a
calcular el Factor de Ajuste (VAF).
7. Tabulación de los resultados. Para mostrar los resultados obtenidos, se construye una
tabla donde se indican los tipos de componentes contabilizados (filas) y la complejidad
asociada a cada uno de ellos (columnas).
El número total de puntos de función sin ajustar corresponde con la siguiente expresión:

15
PFsA = ∑ ( N o de componentes de tipo i ∗ peso del componente i)
i =1

8. Validación de resultados. Antes de utilizar el resultado final obtenido para posibles esti-
maciones, el proceso de conteo descrito en los pasos anteriores deberá ser exhaustivamente
revisado para detectar posibles errores u omisiones que hayan podido producirse.
Los Puntos Función Mark II se obtienen de forma similar al proceso anterior, como resultado
del producto de dos componentes: el Tamaño de Procesamiento de la Información (TPI) y el
Ajuste de Complejidad Técnica (ACT). Se analiza la especificación del sistema desde el punto
de vista de las transacciones lógicas. Donde una transacción lógica es una combinación única
de entrada/proceso/salida desencadenada por un único evento de interés para el usuario o por
una necesidad de recuperar información. Para cada transacción hay que contar el número de
elementos de entrada (EE) y de salida (ES) que implica, así como las Entidades de Datos (ED)
tratadas. A cada tipo se le asigna un peso (P1 , P2 , P3 ) para obtener el TPI. En los PF Mark II
los pesos se deben calibrar en cada entorno en donde se va a aplicar la medida a partir de unos
valores de referencia que son: P1 = 0, 58, P2 = 1, 66, P3 = 0, 26.
Las expresiones de cálculo son:

TPIi = P1 ∗ EE1 + P2 ∗ ESi + P3 ∗ EDi

TPI = ∑ TPIi
PF MKI I = TPI ∗ ACT, donde ACT = 0, 65 + C ∑ f actores
Por último la métrica BANG es el nombre de una métrica de producto propuesta como in-
dicador de la funcionalidad entregada al usuario. La medida se realiza sobre una especificación
de requisitos documentada mediante análisis estructurado y diagramas de flujo (DFD). Se con-
tabilizan hasta seis tipos distintos de componentes elementales: primitivas funcionales como por
ejemplo cualquier proceso de un DFD que no es divisible, los datos elementales como números,
variables, etc. Una vez contabilizados todos los componentes elementales, el siguiente paso es
elegir uno de ellos como indicador principal y utilizar los otros como modificadores. El indicador
principal suele ser el componente FP, es decir, las primitivas funcionales del sistema.
Así, definimos el TCmedio como el factor medio dado por:
∑ TCi
TCmedio =
FP
Siendo TCi el número de tokens implicados en la i-ésima primitiva funcional (un token es
un dato o conjunto de datos que la primitiva trata como un todo), y FP el número de primitivas
funcionales.

Ejemplo de métrica con Puntos de Función Calcular los puntos de función para una apli-
cación de procesado de texto que recibe un documento y opcionalmente un fichero diccionario
personal. La aplicación separa todas las palabras del documento de acuerdo a un diccionario y
genera un listado con todas ellas. El usuario puede pedir un informe con el número de palabras
procesadas y el número de errores encontrados.
Primero debemos calcular los puntos de función no ajustados teniendo en cuenta:

48
 Figura 9: Diagrama para la aplicación de procesado de texto del ejemplo.

2 entradas externas: fichero con el texto y fichero diccionario.

2 salidas externas: palabras procesadas, errores encontrados y el informe de palabras con
error.
2 consultas externas: buscar errores y procesar texto.
2 ficheros externos: fichero de texto y diccionario.
1 fichero interno: diccionario.
Ahora debemos asignar de forma subjetiva y de acuerdo a la experiencia del evaluador la com-
plejidad de cada elemento. Por facilidad, consideremos a todos los elementos de complejdad
media, y elaboremos la tabla de ponderación:

Complejidad del componente

Componente Total
Baja Media Alta
Entradas externas __x3=__ 2x3=6 __x3=__ 6
Salidas externas __x4=__ 2x5=10 __x7=__ 10
Consultas externas __x3=__ 2x4=8 __x6=__ 8
Ficheros lógicos internos __x7=__ 1x10=10 __x15=__ 10
Ficheros externos __x5=__ 2x7=14 __x10=__ 14
Número de Puntos de Función sin Ajustar (PFsA) 48
Cuadro 2: Tabla ponderada de pesos.

Para calcular los puntos de función ajustados necesitamos calcular el factor de ajuste VAF
que debe considerar los 14 factores:

F1 : Backup y recuperación F2 : Comunicación de datos

F3 : Sistema distribuido F4 : Rendimiento
F5 : Sistema con mucha configurabilidad F6 : Entradas on-line
F7 : Facilidad de uso F8 : Actualizaciones on-line
F9 : Interfaz Compleja F10 : Proceso complejo
F11 : Reutilización F12 : Facilidades de instalación
F13 : Portabilidad F14 : Facilidad de cambio
Cuadro 3: Factores o Características Generales del Sistema (CGS).

Con la fórmula:
14
VAF = 0, 65 + 0, 01 ∑ Fi
i =1

Siendo Fi un peso entre 0 si no afectan al sistema y 5 si afectan en importancia. Por ejemplo,

podemos considerar los siguientes pesos:

49
 Nulo (peso 0): F3 , F5 , F9 , F11 , F12 .
Medio (peso 3): F1 ,F2 ,F6 ,F7 ,F8 ,F14 .
Alto (peso 5): F4 ,F10 .
Y por lo tanto los puntos de función ajustados resultan:
14
VAF = 0, 65 + 0, 01 ∑ Fi = 0, 65 + 0, 01 (18 ∗ 10) = 0, 93
i =1

Y los puntos ajustados:

PFA = 48 ∗ 0, 93 = 45 Puntos Funci ón

6.2.1.4. Complejidad del software

Ahora nos centraremos en la complejidad del problema que resuelve el software frente a la
complejidad con la que se soluciona.
La idea fundamental es que la complejidad de una solución no sea mayor que la complejidad
del problema que se plantea. Podemos definir la complejidad de un problema como la cantidad
de recursos óptimos que se necesitan para resolver un problema, y consideramos al menos dos
aspectos:
Complejidad temporal: tomamos el tiempo de proceso necesario como recurso.
Complejidad espacial: tomamos el uso de memoria como recurso.
En definitiva lo que vamos a buscar es alguna medida de la eficiencia de la solución, y vamos
a hacerlo a través de la complejidad asintótica O. Además, es necesario considerar los factores
que afectan a la eficiencia de un programa, ya sean propios (cómo se ha resuelto el problema) o
dependientes del entorno (tipo de procesador, lenguaje de programación, compilador, etc.).
Se pueden seguir dos aproximaciones para el análisis de la eficiencia: un análisis a posteriori
o experimental, o un análisis a priori o teórico. En cuanto al análisis teórico, además de la
mencionada técnica de análisis de la complejidad asintótica, cabe mencionar otras dos opciones:
el conteo de pasos y el análisis de caso.
El conteo de pasos permite obtener una medida tanto temporal como espacial de la eficiencia
de un algoritmo a partir de contar el número de pasos que se ejecutan en una determinada
solución. A partir de este conteo puede establecerse una función de coste:

coste(n)
que relacione el número de pasos con el consumo de coste espacial o temporal.
En cuanto al análisis de casos, intenta tener en cuenta no sólo los pasos para resolver un
problema sino también el funcionamiento para un caso concreto de entrada. Así, la función
anterior se convierte en:
coste(n, l )
siendo n el número de pasos y l una instancia. Lo que más nos interesa son los casos peores,
los mejores, y el comportamiento intermedio. Así, si n es el número de pasos para un problema
A de talla determinada definimos:
S(n) = {l : l | Instancia ∧ talla(l ) = n}
Entonces, el coste peor es:
p
coste A (n) = max{coste A (l, n) : l ∈ S(n)} = coste A (l p , n)
el coste mejor es:

costem
A ( n ) = min{ coste A ( l, n ) : l ∈ S ( n )} = coste A ( lm , n )

y el coste medio es:

costemed
A (n) = ∑ P(l ) ∗ coste A (l, n) = coste A (lm , n)
l ∈S(n)

50
6.2.1.5. La estructura del software
A continuación comentamos alguna de las medidas destacables sobre la estructura interna del
software.
El mínimo número de caminos y las métricas de alcanzabilidad. Se trata del número total
de caminos que se pueden describir sobre el grafo del programa. Valores altos de estas medidas
se relacionan con un elevado número de defectos.
También podemos calcular el nivel de anidamiento, que se refiere a insertar una estructura
básica de control (bucle o decisión) dentro del cuerpo de otra. Cuanto mayor es el anidamiento,
más dificultades tendremos en establecer las condiciones de ejecución de determinadas senten-
cias.
La medida más destacada de complejidad es el número ciclomático de McCabe. Esta métrica
mide el número de caminos linealmente independientes (todos aquellos que introducen al menos
un conjunto nuevo de sentencias o una nueva condición) del grafo de flujo de control de un
determinado programa. La complejidad de McCabe se expresa con la medida de la complejidad
ciclomática V(G) siendo G el grafo del flujo de control (que debe ser directo y acíclico), la cual se
calcula como:

v( G ) = e − n + 2
v( G ) = d + 1
v( G ) = R

Siendo e el número de arcos del grafo, n el número de nodos, d el número de decisiones

binarias en el programa y R el número de regiones cerradas del grafo, incluida la exterior.
Por ejemplo, para el siguiente código y aplicando las tres fórmulas sobre el grafo, obtenemos:

Figura 10: Ejemplo de cálculo de la complejidad ciclomática de McCabe.

McCabe propuso el 10 como límite superior práctico para que un módulo sea probado y
mantenido con éxito. Para valores mayores sería interesante dividir el módulo. A mayor número
ciclomático mayor es la complejidad del programa.

Ejemplo de métrica de complejidad. La complejidad esencial. Es una medida cuantitativa

de la cantidad de construcciones no estructuradas que se encuentran en un módulo, entendién-
dose como construcciones no estructuradas aquellas que no siguen la lógica formal de su uso.
La Complejidad Esencial siempre se encuentra entre 1 y el valor de la Complejidad Ciclomática.
Si la complejidad esencial fuese 1, significaría que el código está completamente estructurado.
Si fuese igual a la complejidad ciclomática, significaría que el código está completamente deses-
tructurado.
El método de cálculo de la complejidad esencial consiste en calcular la complejidad ciclo-
mática del grafo de flujo reducido (aquel grafo de flujo en el que los nodos correspondientes a
instrucciones estructuradas son reducidos a un nodo).
Así, dado el código de la Figura 11 y sus grafos G y G’ reducido:

51
 Figura 11: Código y grafos del ejemplo.

Tenemos que, aplicando la fórmula de la complejidad:

∑ Aristas − ∑ Nodos


V (G) = +2
el valor de la complejidad ciclomática es:

V ( G ) = (11 − 10) + 2 = 3

y el valor de la complejidad esencial:

V ( G 0 ) = (7 − 8) + 2 = 1

6.2.2. Métricas externas

En esta caso se trata de medir las características del software que dependen de la visión ex-
terna del producto. La calidad del software es seguramente el atributo externo de los productos
de software que más interesa medir. Se puede considerar que la calidad comprende otros atri-
butos más sencillos entre los que destacan en cuanto a su interés para la medición la fiabilidad,
la facilidad de uso y la facilidad de mantenimiento.

6.2.2.1. Calidad del software

Se considera que la calidad es un atributo relativo, una propiedad que depende de las expec-
tativas y necesidades del usuario. La definición oficial concibe la calidad como satisfacción de
expectativas explícitas o implícitas del cliente o usuario. Esta exigencia y la naturaleza compleja
de calidad conducen a la definición de modelos que ayuden a evaluar y medir esta propiedad
en los productos del software.
Otra manera de evaluar y medir la calidad consiste en restringir la calidad a una medida
simple que es la inexistencia de defectos. No se contemplan como defectos las mejoras necesarias
del software como un cambio que no se hubiera detectado o un cambio detectado pero no
corregido.

6.2.2.2. Fiabilidad del software

La fiabilidad es el atributo que más extensamente se ha estudiado. Se puede definir como la
capacidad de un sistema o componente para ejecutar las funciones requeridas de forma satis-
factoria bajo condiciones determinadas en un periodo de tiempo especificado. El objetivo más

52
habitual del estudio de la medición de la fiabilidad del software es resolver el problema de
predecir cuándo podría fallar un sistema.
Uno de los supuestos de trabajo consiste en asumir que los fallos ocurren probabilísticamen-
te en el tiempo según una tasa de intensidad de fallos. En función de los datos de fallos, se
construyen los modelos que permitan predecir la evolución de la fiabilidad del software en el
futuro.
Entre las métricas empleadas para describir el comportamiento del software en cuanto a la
fiabilidad, podemos destacar las siguientes:
El tiempo medio hasta el siguiente fallo (MTTF, Mean Time To Failure).
El tiempo medio de reparación del software (MTTR, Mean Time To Repair).
El tiempo medio entre fallos (MTBF, Mean Time Between Failures).
La disponibilidad D de un sistema se puede concebir de la siguiente manera:
 
MTTF
D= ∗ 100
MTBF

La densidad de fallos se suele concebir como una función f(t) que se obtiene a partir de
datos de ejecución y que describe la incertidumbre sobre cuándo fallará un componente
de software.

6.2.2.3. Facilidad de uso software

Se define como la facilidad con la cual un usuario puede operar con un sistema o componente,
preparar las entradas de datos e interpretar las salidas. Se trata de la probabilidad de que el
usuario de un sistema no experimente problemas de interfaz durante un cierto periodo dado en
un perfil operativo concreto. Su medición depende de la división en atributos más sencillos, por
ejemplo en:
Nivel de cualificación requerido para comenzar a usar la aplicación.
Aprendizaje preciso para conocer el uso de la aplicación hasta que se demuestra un cierto
nivel de pericia.
Capacidad de manejo o productividad neta para realizar ciertas tareas tras superar la for-
mación necesaria.
Aceptación de la aplicación o grado en que los usuarios tienen una actitud positiva hacia
ella.

6.2.2.4. Mantenimiento software

La mantenibilidad es la facilidad con la cual un sistema o componente se puede modificar
para corregir defectos, mejorar el rendimiento o adaptarlo a un entorno cambiado. Se suelen
considerar tres tipos de mantenimiento:
Correctivo. Dedicado a la corrección de defectos encontrados en el funcionamiento del
software.
Adaptativo. Introduce nuevos cambios debidos a cambios en el entorno en el que se ejecuta
el sistema.
Perfectivo. Introducción de nuevas funcionalidades.
Además existe el llamado mantenimiento preventivo, que consiste en cambiar el producto pen-
sando en futuras mejoras.
Las medidas más comunes de facilidad de mantenimiento se basan en atributos de proceso.
Así, una medida común dependiente del entorno es el tiempo medio para realizar un cambio
(MTTR) comentado antes. Otras medidas son las relacionadas con el número de defectos encon-
trados, el seguimiento de cada problema y su depuración o resolución.
Los ingenieros del software desean, ante todo, saber qué atributos internos de los productos
pueden facilitar su posterior mantenimiento.

53
6.2.3. Métricas de uso
Para el concepto de usabilidad, no siempre se ha definido claramente si lo que se desea
medir es la calidad del producto, la calidad en uso o ambas. La calidad en uso está directa-
mente condicionada por la percepción que el usuario tiene del producto en uso, en un contexto
determinado.
Vamos a referirnos a la calidad en uso por medio de características de alto nivel como la
efectividad, la productividad, la seguridad y la satisfacción del usuario. Estas características son
de tal nivel de abstracción que no son directamente cuantificables, por lo que necesitaremos
definir atributos que sí lo sean.
En el desarrollo del proceso de evaluación de la calidad en uso se deberán considerar los
siguientes pasos principales:

1. Análisis de los diferentes contextos y tareas en las que al producto de uso debe ser some-
tido a prueba, conforme a la meta de la evaluación.
2. Especificación de los requerimientos de calidad en uso para los contextos y tareas identifi-
cados, en los que se ha de situar a los usuarios para cada perfil. Se establecerá el modelo
de calidad en uso.

3. A partir del modelo de calidad especificado, se diseñarán los criterios, métricas, instrumen-
tos como cuestionarios, casos de prueba, herramientas y procedimientos de evaluación.
4. Una vez planificado y diseñado el proceso de evaluación se llevará a fase de implementa-
ción.

5. Por último, se establecerán las conclusiones y recomendaciones.

Respecto al modelo de calidad en uso, las características definidas son efectividad, productivi-
dad, seguridad y satisfacción de usuario.
Para medir la satisfacción del usuario se utilizarán cuestionarios en los que el objetivo sea
considerar aspectos como la apariencia estética, la velocidad percibida, la relevancia de conteni-
dos, o si las funciones son adecuadas a la funcionalidad esperada, entre otros.

6.3. Modelos de Calidad

6.3.1. Conceptos básicos sobre modelos
Los modelos aquí presentados son los de mayor acogida en gran parte de los autores consul-
tados. Se hace necesario tener en cuenta algunos criterios de selección que sirvan para elección
de aquellos modelos que pueden ser de interés-
Criterio 1. Disponibilidad El grado en que es posible acceder a la información existente. Se
refiere a la facilidad de obtener la información sobre el modelo.

1: si la información no se encuentra disponible al público en general.

2: hay disponibilidad de algunos documentos pero es limitado el acceso.
3: se encuentra información suficiente y disponible para ser utilizada.

Criterio 2. Claridad El grado en que el modelo es presentado y si posee mecanismos explicati-

vos sobre su uso. Se refiere a cómo de sencillo puede ser entender el modelo.

1: el modelo no es claro o se dificulta su entendimiento. No posee mecanismos de

ayuda.
2: el modelo es presentado en forma clara, sin embargo no posee mecanismos de
ayuda.
3: el modelo es presentado en forma clara, y posee mecanismos explicativos acerca de
su modo de empleo.

Criterio 3. Adaptabilidad El grado en el que el modelo posee la capacidad de adaptarse a dis-

tintas situaciones dependiendo del producto al que se va a aplicar.

54
 1: el modelo no es adaptable. Se presenta de forma rígida para su uso.
2: el modelo puede ser adaptado pero exige ciertas reglas a seguir.
3: el modelo permite ser adaptado.

Criterio 4. Completitud El grado en el que el modelo describe todas sus partes en su totalidad
sin dejar fuera información importante.

1: el modelo no menciona toda la información necesaria. Se encuentra incompleto.

2: el modelo describe medianamente sus componentes, pero deja a algunos elementos
fuera.
3: el modelo describe todas sus partes. Está completo.

Criterio 5. Área de aplicación Se refiere a la aplicabilidad del modelo a las diferentes áreas de
calidad del software.

1: modelo de proceso, metodología o estándar (no incluye modelo).

2: puede ser modelo de proceso y producto al mismo tiempo.
3: modelo para producto software.

Respecto a los modelos disponibles, hemos establecido la siguiente valoración de los criterios:

Criterio
Modelo/Estándar Total
C1 C2 C3 C4 C5
McCall 2 2 2 2 3 11
Boehm 2 2 2 2 3 11
FURPS 1 2 3 1 3 10
Dromey 1 2 2 2 3 10
SQAE 2 2 2 2 3 11
Bansiya 2 2 2 2 3 11
ISO 9126 2 2 2 2 3 11
QUINT2 1 2 2 2 3 10
ISO 25000 2 2 2 NA 1 7
Cuadro 4: Modelos de Calidad y su puntuación atendiendo a los criterios expuestos.

6.4. Medición práctica

6.4.1. Medición personal y medición institucional
Toda organización se cuestiona “¿Logramos los resultados que deseamos?”. Variantes de
esta pregunta suelen ser “¿Alcanzamos los objetivos del negocio?”, “¿Están satisfechos nuestros
clientes con nuestros productos y servicios?”, etc. Las respuestas a estas preguntas tienen las
raíces en tres elementos básicos: cómo hacemos las cosas o los procesos operativos, la dirección,
y los empleados de la organización.
¿Por qué medir?
Los métodos de medición y análisis permiten identificar puntos importantes y tendencias y,
al mismo tiempo, permiten distinguir entre situaciones reales de riesgo de las que no los son, lo
cual es vital para una adecuada toma de decisiones así como para seguir un rumbo adecuado
en la dirección de la empresa.
Para que las actividades de medición sean rentables, estas deben dar soporte a la consecución
de los objetivos de negocio y proporcionar información efectiva para la toma de decisiones.
La implementación de un buen proceso de medición apoyado por una herramienta que lo
automatice permitirá a la organización tomar decisiones rápidas y adecuadas en áreas competi-
tivas.

55
6.4.2. Guía de medición
Las métricas son fundamentales para el control y mejora del software, ya que, como decía De
Marco, “no se puede controlar lo que no se puede medir”.
En este apartado se han incluido algunos comentarios importantes a la hora de implantar
con éxito métricas software.
En primer lugar se recomienda empezar con pocas métricas y que estas ayuden al negocio.
Una recomendación generalizada es que las métricas deben ayudar a los objetivos de negocio. Es
decir, debemos definir primero los objetivos de negocio y que estos me determinen qué métricas
tomar. Si el objetivo de negocio es “aumentar la satisfacción del cliente con mi producto” se
pueden medir las incidencias, el ratio/tiempo de resolución de errores, la cobertura de pruebas
funcionales, los errores detectados por las pruebas, etc.
Putman y Myers argumentan que las cinco métricas básicas se basan en medir tiempo, es-
fuerzo, tamaño, fiabilidad y productividad, aplicadas a productos/procesos software.
Se debe comenzar con pocas métricas, para ir aumentando iterativamente el proceso de me-
dición.
La mejor forma de medir es en periodos cortos, frecuentemente, de manera automatizada
y definiendo niveles de abstracción. Si los periodos de medición son muy grandes puede que
medir sólo me sirva para confirmar problemas software que ya es muy tarde para resolver. Pero
claro, medir muy frecuentemente puede tener el inconveniente de que lleve y consuma mucho
tiempo, y que esto reste productividad.
Otro elemento adicional consiste en definir los niveles de abstracción. Las métricas que in-
teresan a un programador, no son las mismas que interesan a un jefe de proyecto.

56
Parte III
Calidad del Proyecto
7. La gestión de la calidad de los proyectos
7.1. Introducción
El proceso de gestión de la calidad pretende asegurar que todas las actividades necesarias
para diseñar, planificar e implementar un proyecto se llevan a cabo de forma efectiva y eficiente
de acuerdo a los objetivos del proyecto.
La gestión de la calidad se trata de un proceso que se lleva a cabo de forma continua des-
de que el proyecto ha comenzado, es un proceso de vital importancia para asegurar que los
proyectos cumplen con los requisitos de calidad esperados.

7.2. Gestión de la calidad de los proyectos según PMBOK

Un proyecto es un esfuerzo temporal (con principio y final definidos) que se lleva a cabo
para crear un producto, servicio o resultado único. La gestión de proyectos es la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir
con los requisitos del mismo.
Los 42 procesos de PMBOK se clasifican de acuerdo a nueve áreas de conocimiento:
Gestión de la Integración.
Gestión del Alcance.
Gestión del Tiempo.

Gestión del Coste.

Gestión de la Calidad.
Gestión de los Recursos Humanos.

Gestión de las Comunicaciones.

Gestión de los Riesgos.
Gestión de las Adquisiciones.
Nos centraremos en el área de Gestión de la Calidad del Proyecto, que trata sobre la gestión
tanto de la calidad del proyecto como de los productos del proyecto. El enfoque básico en PM-
BOK es compatible con los estándares ISO relacionados así como con enfoques sobre la gestión
de calidad.
Para dar soporte a este área, se incluyen los procesos: Planificar la Calidad, Realizar el
Aseguramiento de Calidad y Realizar el Control de Calidad.

7.2.1. Planificar la Calidad

Este proceso se encarga de la identificación de los requisitos de calidad y/o normas para el
proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento
de los mismos.

7.2.1.1. Entradas Las entradas del proceso de planificación de la calidad son:

Línea Base, formada por: el enunciado del alcande, que contiene la descripción del proyec-
to y los criterios de aceptación; la Estructura de Descomposición de Trabajos (EDT). que
identifica los entregables, los paquetes de trabajo y las cuentas de control que se utilizan
para medir el rendimiento; diccionario de la EDT, que describe los aspectos técnicos de los
elementos incluidos en la EDT.

57
 Registro de Interesados, que identifica a aquellos que tienen un interés particular o pueden
influir en la calidad.
Línea Base del Rendimiento de Costes, que representa el presupuesto aprobado del pro-
yecto distribuido en el tiempo.
Línea Base del Calendario, que documenta las medidas de rendimiento del calendario del
proyecto, incluyendo sus fechas de inicio y finalización.
Registro de Riesgos, que contiene la información sobre las amenazas y oportunidades que
pueden impactar sobre los requisitos de calidad.
Factores de Entorno de la Empresa, que pueden influir en la planificación de la calidad,
tales como: las leyes gubernamentales; las reglas para un área de aplicación; las condiciones
de trabajo.
Activos de los Procesos de la Organización, que pueden influir tales como: las políticas,
los procedimientos y las pautas de calidad de la organización; las bases de datos históricas;
la política de calidad.

7.2.1.2. Herramientas y técnicas Las herramientas y técnicas del proceso planificación de la

calidad de PMBOK son:
Análisis Coste-Beneficio, durante el cual se comparan para cada actividad de calidad el
coste de su aplicación respecto al beneficio esperado.
Coste de la Calidad (COQ), que incluye todos los costes en los que se ha incurrido du-
rante la vida del producto. Los costes debidos a fallos se clasifican a menudo en internos
(constatados por el equipo del proyecto) y externos (constatados por el cliente).
Gráficos de Control, donde el director del proyecto y los interesados establecen los límites
de control superiro e inferior, para reflejar los puntos en los cuales debe implementarse
acciones correctivas.
Estudios Comparativos, que implican comparar prácticas reales o planificadas del proyecto
con las de proyectos comparables.
Diseño de Experimentos (DOE), se emplea para determinar la cantidad y el tipo de prue-
bas a efectuar.
Muestreo estadístico.
Diagramas de Flujo, en los que durante la planificación de la calidad pueden ayudar al
equipo del proyecto a anticipar problemas que pudieran ocurrir.
Metodologías Propietarias de Gestión de la Calidad, como las propuestas por Six-Sigma.
Herramientas Adicionales de Planificación de Calidad, entre otras:

• Tormenta de ideas.
• Análisis de los campos de fuerza.
• Técnicas de grupo nominal.
• Diagramas Matriciales de priorización.

7.2.1.3. Salidas Las salidas del proceso planificación de la calidad son:

Plan de Gestión de Calidad, que describe cómo el equipo de gestión del proyecto im-
plementará la política de calidad de la organización ejecutante. Es un componente que
proporciona las entradas a dicho plan general para abordar el control de la calidad. El plan
de gestión de calidad puede ser muy detallado o formulado de manera general.
Métricas de Calidad, que es una definición operativa que describe en términos muy espe-
cíficos un atributo del producto o del proyecto, y la manera en que se medirá.

58
 Listas de Comprobación de la Calidad, herramienta estructurada, por lo general específica
de cada componente, que se utiliza para verificar que se hayan realizado una serie de pasos
necesarios.

Plan de Mejora del Proceso, que detalla los pasos necesarios para analizar los procesos
de modo que se facilite la identificación de actividades que incrementen el valor de dichos
procesos.
Actualizaciones a los Documentos del Proyecto, siendo los documentos del proyecto que
pueden actualizarse: el registro de interesados y la matriz de asignación de responsabili-
dades.

7.2.2. Realizar el Aseguramiento de la Calidad

Este proceso se encarga de auditar los requisitos de calidad y los resultados obtenidos con
las mediciones de control de la calidad con el fin de asegurar que se utilizan los estándares de
calidad y las definiciones operacionales adecuadas.

7.2.2.1. Entradas Las entradas del proceso de aseguramiento de la calidad son:

Plan de Gestión del Proyecto, que incluye la siguiente información: El Plan De Gestión
de la Calidad, que describe cómo se realizará el aseguramiento de la calidad; y El Plan
de Mejoras del Proceso, que incluye los pasos necesarios para identificar las actividades
necesarias para mejorar el valor de los procesos.
Métricas de Calidad.
Información sobre Rendimiento del Trabajo, que se recopila de forma sistemática e in-
cluye: medidas de rendimiento técnico; estado de los entregables del proyecto; avance del
calendario; costes incurridos.
Mediciones de Control de Calidad, que se obtienen como resultado de las actividades de
control de la calidad y permiten analizar y evaluar las normas y procesos de calidad de la
organización ejecutante.

7.2.2.2. Herramientas y técnicas Las herramientas y técnicas del proceso de aseguramiento

de la calidad de PMBOK son:

Herramientas y Técnicas para Planificar y Realizar el Control de la Calidad. Las herra-

mientas utilizadas en estos procesos también se pueden aplicar para realizar el asegura-
miento de la calidad.
Auditorías de Calidad. Sus objetivos son identificar todas las buenas y mejores prácticas
que se emplean en la organización y también las anomalías. Como consecuencia de aplicar
auditorías se espera reducir el coste de la calidad. Las auditorías pueden ser planificadas
o aleatorias, así como realizadas por auditores internos o externos.
Análisis de Procesos. Sigue los pasos establecidos en el plan de mejoras del proceso para
determinar las mejoras necesarias. Examina también las restricciones y los problemas expe-
rimentados. Incluye el análisis causal, que es una técnica específica que permite identificar
un problema, determinar las causas subyacentes que lo ocasionan y desarrollar acciones
preventivas.

7.2.2.3. Salidas Las salidas del proceso de aseguramiento de la calidad son:

Actualizaciones de los Activos de los Procesos de la Organización, entre los que se en-
cuentran los estándares de calidad que pueden ser actualizados.
Solicitudes de Cambio, que son generadas a partir de las acciones para aumentar la efecti-
vidad y/o eficacia de las políticas, procesos y procedimientos de la organización ejecutante.

59
 Actualizaciones al Plan de Gestión del Proyecto, que afecta a los planes de gestión de
calidad, del calendario y de costes.
Actualizaciones a los Documentos del Proyecto, siendo los documentos del proyecto que
pueden actualizarse: informes de auditorías de calidad, planes de capacitación y la docu-
mentación del proceso.

7.2.3. Realizar el Control de la Calidad

El Control de la Calidad es un proceso que se lleva a cabo durante todo el proyecto, mediante
el cual se monitorizan y se registran los resultados de la ejecución de las actividades de gestión
de la calidad con el fin de evaluar su rendimiento y recomendar los cambios necesarios.

7.2.3.1. Entradas El proceso de control de la calidad recibe las siguientes entradas:

Plan de Gestión del Proyecto, que contiene entre otros el plan de gestión de la calidad.
Dicho subplan describe cómo se realizará el control de la calidad en el proyecto.
Métricas de Calidad.
Listas de Comprobación de Calidad.
Mediciones del Rendimiento del Trabajo, que se utilizan para producir las métricas de
actividad del proyecto con el fin de evaluar el progreso real del mismo respecto al planifi-
cado.
Solicitudes de Cambio Aprobadas, como peticiones de corrección de defectos, revisión de
métodos de trabajo o del calendario, Se debe verificar que dichos cambios son implemen-
tados de forma adecuada.
Entregables, que son cualquier producto, resultado o capacidad de prestar un servicio
único y verificable que se produce a la finalización de un proceso, una fase o un proyecto.
Activos de Procesos Organizacionales, de los cuales, aquellos que pueden influir en el
proceso de control de la calidad son: estándares y políticas de calidad; pautas normalizadas
de trabajo y procedimiento de generación de informes de problemas y defectos y políticas
de comunicación.

7.2.3.2. Herramientas y técnicas Las herramientas y técnicas del proceso de control de la

calidad son (véase Anexo A):
Diagrama Causa-Efecto.
Gráficos de Control.
Diagramas de Flujo.
Histogramas.
Diagramas de Pareto.
Diagrama de Comportamiento, que es similar a un gráfico de control, pero en el que no se
muestran los límites de control. Muestra mediante una gráfica lineal los puntos de datos
según el orden en que aparecen. Se usa a menudo para supervisar el rendimiento técnico
y de coste y calendario.
Diagrama de Dispersión, que muestra la relación entre dos variables.
Muestreo Estadístico.
Inspección, que consiste en examinar un producto de trabajo para comprobar si cumple
con las normas establecidas.
Revisión de Solicitudes de Cambio Aprobadas, que se utilizan para verificar que dichas
solicitudes se implementaron según lo aprobado.

60
7.2.3.3. Salidas Las salidas del proceso de control de la calidad son:
Mediciones de Control de Calidad, que son los resultados documentales de las actividades
de control de calidad de acuerdo al formato establecido.
Cambios Validados, que son los cambios que han sido ya inspeccionados con resultado
favorable.
Entregables Validados. Mediante la producción de esta salida se satisface uno de los objeti-
vos principales del control de la calidad, que es comprobar la corrección de los entregables.
Actualizaciones de los Activos de los Procesos de la Organización, en concreto los que
se pueden actualizar como resultado del control de la calidad son: listas de comprobación
completadas, que pasan a formar parte de los registros del proyecto, y la documentación
de lecciones aprendidas de la organización.
Solicitudes de Cambio, que se producen si las acciones correctivas o preventivas recomen-
dadas como resultado del control de la calidad requieren un cambio en el plan de gestión
del proyecto.
Actualizaciones del Plan de Gestión del Proyecto, en concreto se puede actualizar el plan
de gestión de calidad y de mejoras del proceso.
Actualizaciones de los Documentos del Proyecto, que incluyen entre otros los estándares
de calidad.

7.3. Estándares IEEE 730-2002

Este estándar internacional proporciona un conjunto uniforme y mínimo aceptable de los
requisitos para la preparación de Planes de Aseguramiento de la Calidad del Software (Software
Quality Assurance Plans, SQAP). Para ello define la estructura que dichos planes deben seguir y
facilita la evaluación de dichos planes.
El SQAP debe incluir una serie de apartados de acuerdo a una determinada estructura y
orden. También puede que ciertos apartados no sean aplicables en el plan, por lo que se debe
indicar. La estructura general del SQAP, que detallaremos en los siguientes apartados, es la
siguiente:
1. Propósito
2. Documentos de Referencia
3. Gestión
4. Documentación
5. Estándares, Prácticas, Convenciones y Métricas
6. Revisiones Software
7. Pruebas
8. Informas de Problemas y Acciones Correctivas
9. Herramientas, Técnicas y Metodologías
10. Control de Medios
11. Control del Proveedor
12. Colección de Registros, Mantenimiento y Conservación
13. Formación
14. Gestión de Riesgos
15. Glosarios
16. Procedimiento de Cambio e Historial del SQAP

61
7.3.1. Propósito
Aquí se debe definir el propósito específico y alcance del SQAP. Debe incluir una lista de los
elementos software cubiertos por el plan y su uso previsto.

7.3.2. Documentos de Referencia

En este apartado se debe proporcionar la lista completa de todos los documentos referencia-
dos en el SQAP, incluyendo sus versiones y fechas.

7.3.3. Gestión
Este apartado debe describir la estructura de organización del proyecto, sus tareas y sus roles
responsabilidades. Se divide en:

Organización, en la que se describe la estructura de la organización que tiene influencia y

controla la calidad del software. Se debe documentar y describir cada uno de los elementos
principales de la organización.
Tareas, que describen qué parte del ciclo de vida del software está cubierto por el plan, las
tareas a realizar, los criterios de entrada y salida de cada tarea y las relaciones entre las
tareas así como sus principales puntos de control.
Roles y Responsabilidades, para la realización de cada tarea.
Recursos estimados para el Aseguramiento de la Calidad, en la que se indican los recursos
y costes estimados para el aseguramiento de calidad y las tareas de control de calidad.

7.3.4. Documentación
Este apartado se divide en:
Propósito, que debe identificar la documentación que regula el desarrollo, la verificación y
validación, el uso y el mantenimiento del software y listar los documentos que tienen que
ser revisados o auditados para comprobar su conformidad.
Requisitos Mínimos de Documentación, que permitan asegurar que la implementación
del software satisface los requisitos técnicos.

7.3.5. Estándares, prácticas, convenciones y métricas

Incluye:
Propósito, que identifica los estándares, prácticas, convenciones y técnicas estadísticas a
utilizar, así como los requisitos de calidad y las métricas a aplicar.
Contenido, que como mínimo debe incluir: estándares de documentación, diseño, codi-
ficación y de comentarios; estándares y prácticas de pruebas; métricas seleccionadas de
aseguramiento de la calidad de producto y proceso software.

7.3.6. Revisiones Software

Está formado por:
Propósito, que debe: definir las revisiones software a llevar a cabo; describir el calenda-
rio de revisiones respecto al calendario del proyecto: establecer cómo se realizarán las
revisiones y qué acciones adicionales serán necesarias así como la forma en la que se im-
plementarán y verificarán.
Requisitos mínimos, que establecen las revisiones mínimas que se deben llevar a cabo.
Otras revisiones y auditorías, como la revisión de la documentación del usuario que per-
mite evaluar su completitud, claridad, corrección y usabilidad.

62
7.3.7. Pruebas
En este apartado se identifican todas las pruebas que no han sido incluidas en el plan de
verificación y validación del software para el producto software cubierto por el SQAP y se
establecen los métodos a aplicar.

7.3.8. Informe de Problemas y Acciones Correctivas

Este apartado describe las prácticas y procedimientos a seguir para la generación de informes,
el seguimiento y la resolución de problemas identificados tanto en los artefactos software como
en sus procesos de desarrollo y mantenimiento.

7.3.9. Herramientas, Técnicas y Metodologías

En este apartado se identifican las herramientas software, técnicas y métodos utilizados para
dar soporte a los procesos de aseguramiento de la calidad del software, Para cada uno, se debe
indicar su uso previsto, aplicabilidad o circunstancias en las que se puede utilizar o no, así como
las limitaciones.

7.3.10. Control de Medios

Este apartado incluye la identificación de soportes o medios físicos necesarios para cada pro-
ducto de trabajo intermedio y entregable, así como la documentación necesaria para almacenar
dichos medios, incluyendo los procesos de copia y restauración.

7.3.11. Control del Proveedor

En este apartado se establecen las provisiones necesarias para asegurar que el software pro-
porcionado por los proveedores satisface los requisitos. Además se deben especificar los métodos
que se utilizarán para que el proveedor reciba requisitos adecuados y completos.

7.3.12. Recopilación, Mantenimiento y Conservación de Registros

Este apartado debe identificar la documentación de aseguramiento de la calidad del software
que se debe conservar, y se deben establecer los métodos y facilidades a utilizar para ensamblar,
archivar, salvaguardar y mantener esta documentación, así como el período en que se debe
conservar.

7.3.13. Formación
Este apartado identifica las actividades de formación necesarias para satisfacer las necesida-
des del SQAP.

7.3.14. Gestión de Riesgos

En este apartado se deben especificar los métodos y procedimientos empleados para identi-
ficar, evaluar, monitorear y controlar las áreas de riesgo que pueden surgir durante las fases del
ciclo de vida cubiertos por el SQAP.

7.3.15. Glosario
En este apartado se incluye un glosario de términos del plan SQAP.

7.3.16. Historia y Procedimientos de Cambio del Plan de Aseguramiento de la Calidad del

Software
Este apartado contiene los procedimientos para modificar el plan SQAP y mantener un his-
tórico de sus cambios.

63
7.4. Ejercicios
1. Analizar cómo se pueden complementar los procesos de gestión de la calidad de PMBOK
y el estándar IEEE 730.
En PMBOK, dentro del área de conocimiento Gestión de la Calidad, que determina las polí-
ticas, los objetivos y las responsabilidades relativas a la calidad, se incluyen los procesos:
Planificar la Calidad, Realizar el Aseguramiento de Calidad y Realizar el Control de Cali-
dad.
Es dentro del primer proceso de Planificación de la Calidad donde se obtiene como salida
el Plan de Gestión de Calidad, que describe cómo el equipo de gestión del proyecto im-
plementará la política de calidad de la Organización. Uno de los componentes de ese Plan
de Gestión es el aseguramiento de la calidad. Así pues, para realizar este plan una de las
opciones disponible y según la disponibilidad de detalles de los requisitos es el uso del
estándar IEEE 730 como formato tipo.
2. Realizar un búsqueda bibliográfica de casos en los que se haya documentado un plan de
aseguramiento de la calidad del software de acuerdo al estándar IEEE 730. Analizar los
ejemplo para una mayor compresión de la estructura del estándar y las formas en las que
se ha aplicado.

64
8. Calidad del software (apuntes E.D.)
8.1. Conceptos generales del proyecto
8.1.1. Concepto del proyecto
Un proyecto es una secuencia única de actividades complejas e interconectadas que tienen un
objetivo o propósito que debe ser alcanzado en un plazo establecido, dentro de un presupuesto
y de acuerdo con unas especificaciones. Tiene un inicio y un fin.
A la hora de plantearse un proyecto hay dos preguntas que siempre debe hacerse la empresa:

¿Qué va a hacer el proyecto?

¿Cómo se va a realizar el proyecto?
De este modo se puede hacer una idea si el proyecto será fácil (a la hora de implementar) o será
difícil, además de marcar el objetivo.
Hay que quedarse con dos aspectos muy importantes sobre los proyectos que son los siguien-
tes:
Los proyectos son un tipo de actividad específica con que toda empresa o administración
se ha de enfrentar.
Cada vez es más frecuente la necesidad de ejecutar proyectos al vivir en un mundo cam-
biante al que es necesario adaptarse con la suficiente rapidez.

8.1.2. Clasificación de proyectos

Una primera clasificación bastante intuitiva de proyectos puede ser atendiendo al cambio que
producen. Entre ellos se encontraría:
Construcción.

Investigación.
Ingeniería.
Desarrollo.

Organización.
También puede resultar interesante la clasificación de los proyectos atendiendo al carácter in-
terno o externo del cliente:
Proyectos externos son los que encargan clientes o entidades ajenas a la empresa ejecutora.
Por ejemplo: una operadora de telecomunicaciones encarga a una empresa la ejecución de
parte de sus procesos de negocio.
Proyectos internos son los que un empresa ejecuta para sí misma, encargando su dirección
y ejecución a personas o departamentos de la propia entidad.

8.1.3. Aspectos de un proyecto

Todo proyecto tiene tres facetas o aspectos diferentes. Se genera por la necesidad sentida por
el cliente que desea realizar una obra u obtener un determinado resultado u objetivo.
Para conseguir un correcto resultado es necesario articular y armonizar tres tipos de aspectos
bien diferenciados entre sí pero todos ellos imprescindibles:
1. Dimensión técnica. Todo proyecto tiene una dimensión técnica que es necesario conocer
y desarrollar y que depende de la naturaleza del proyecto a ejecutar. Es necesario obtener
conocimientos específicos sobre el proyecto y hacerlo cumpliendo los requisitos y formas
de trabajar que el saber hacer (knowhow) técnico de cada profesión aplica.

65
 2. Dimensión humana. En un proyecto se insertan muy diversos intereses, en algunos casos
contrapuestos: cliente, jefe de proyecto, especialistas, subcontratistas, empleados, provee-
dores, etc. Todos son necesarios y tienen algo que aportar al proyecto, pero conseguir que
su aportación sea positiva, convergente y coordinada es una tarea de gran dificultad.
3. Gestionar bien o mal. Un proyecto puede estar bien o mal gestionado y de ello depende
el éxito o el fracaso. La acumulación de recursos no produce ningún resultado importante
porque interviene un factor especial: la gestión.
La metodología de gestión de proyectos (Project Management) responde a estos conceptos y los
pretende integrar adecuadamente.

8.1.4. Organización de la gestión de un proyecto

Es necesario que la gestión de los proyectos se apoye en unos principios básicos o pilares:
Jefe de proyecto- Es imprescindible la existencia de una única cabeza que dirija e impulse
el proyecto, siendo responsable de la consecución de los objetivos del mismo.
Equipo de proyecto. Se requiere la colaboración de un equipo suficiente en número y con
las capacidades profesionales adecuadas para dar respuesta a las diferentes especificacio-
nes a cumplir.
Técnicas de gestión. El proyecto se apoyará también en técnicas de gestión adaptadas a la
circunstancia; planificación, organización y control.
El jefe de proyecto es una figura clave, pero su función requiere que se trate de un verdadero
puesto de jefatura con autoridad para dirigir el equipo y tomar decisiones en el ámbito del
proyecto. Su misión general puede descomponerse en un conjunto de funciones específicas, por
ejemplo:

Colaboración con el cliente en la definición de los objetivos.

Planificación del proyecto en todos sus aspectos.
Dirección de todos los recursos.

En el caso de proyectos externos es necesario mantener una buena comunicación con los
proveedores o empresas externas.
Toma de decisiones necesarias.
Seguimiento del proyecto.

Adopción de medidas correctoras en la detección de desviaciones.

8.1.5. Etapas de un proyecto

Para llegar al resultado deseado en un proyecto es necesario seguir una trayectoria que se
compone de una serie de etapas que deben ser previamente previstas y deben tener un determi-
nado orden.
La descomposición de un proyecto en etapas es una de las peculiaridades de la gestión de
proyectos ya que repercute directamente en la calidad de gestión del mismo. Se puede descom-
poner el proyecto en tres etapas básicas:
Fase de planificación. Las características de los proyectos implican la inclusión de una fase
previa dedicada a la planificación de los mismos.

Fase de ejecución. Representa el conjunto de tareas y actividades que suponen la realiza-

ción del proyecto. Implica también gestionar los recursos de forma adecuada.
Fase de cierre. Todo proyecto está destinado a finalizarse en un plazo predeterminado,
verificando que responde a los objetivos marcados sobre el mismo.

66
8.2. Conceptos generales de un proyecto software
Este apartado trata sobre la gestión de proyectos informáticos. Se presentan las principales
áreas que una gestión de proyectos software debe abordar: planificación y seguimiento.

8.2.1. Planificación del proyecto

El propósito de la planificación es elaborar un plan de proyecto que describa las tareas que
se van a llevar a cabo. El plan de desarrollo de software se produce al comienzo del proyecto.
Recoge el presupuesto inicial contenido en una posible oferta, además de la programación de
las actividades de desarrollo.
El plan de desarrollo de software se considera un documento dinámico. A lo largo del pro-
yecto, si se considera por los responsables del proyecto actualizar el plan del proyecto en algún
aspecto, éste se modifica para registrar el nuevo compromiso.
El propósito del plan de desarrollo de software es el establecimiento preciso de las tareas a
realizar y sus características, así como la organización para asegurar el desarrollo del software.
El plan de desarrollo de software indica:
Entorno técnico.

Productos, entregables o no.

Estimaciones de esfuerzo y duración.
Organización.
Responsabilidades.

Modos de seguimiento del avance.

Actividades necesarias para la gestión del proyecto.
El plan de desarrollo de software está dirigido a:

El jefe de proyecto, responsable de la elaboración del mismo.

El responsable de la planificación y seguimiento.
El cliente, responsable de la aprobación del documento.
El responsable de calidad.

Los documentos necesarios para escribir el plan de desarrollo de software son:

Los requisitos del sistema, incluyendo requisitos de calidad.
Ofertas, etc. (cualquier documento que defina el software a realizar).

Contratos, etc. (cualquier cláusula contractual que defina los requisitos de gestión del pro-
yecto).

8.2.2. Seguimiento del proyecto

Se identifica como un proceso independiente porque se ha observado que el éxito de los
proyectos radica en un adecuado seguimiento y control del mismo.
Una vez que se ha planificado el proyecto, hay que controlar su desarrollo para comprobar
que se está siguiendo el plan previsto: que satisface sus objetivos en calidad, coste y tiempo.
Existen tres prácticas diferentes del seguimiento de proyectos: recopilar los datos reales del
progreso del proyecto, determinar y realizar acciones correctivas, y gestionar los cambios a los
compromisos acordados.

67
8.3. Gestión de la calidad de los proyectos según PMBOK
El PMBOK es una guía de procesos y áreas de conocimiento generalmente aceptadas como
las mejores prácticas de la gestión de proyectos. La finalidad principal de la Guía del PMBOK
es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reco-
nocido como buenas prácticas.
El PMBOK adopta un modelo para la gestión de proyectos organizado como un cuerpo de
conocimiento compuesto por nueve áreas de conocimiento. Estas áreas representan las compe-
tencias y las buenas prácticas que se deben reunir en la gestión de proyectos. Cada área está
compuesta por procesos inherentes al área (44 procesos en total). Y para cada proceso se des-
criben metas, actividades, entradas, salidas, técnicas, destrezas, herramientas y vínculos a los
demás procesos.
Otra característica del PMBOK es el agrupamiento de los procesos en 5 grupos de proce-
sos; siguiendo el orden cronológico del ciclo de vida de un proyecto: Iniciación, Planificación,
Ejecución, Control y Cierre.

Figura 12: Ciclo de vida de un proyecto según PMBOK.

El PMBOK está dividido en tres secciones principales:

Sección I: Marco Conceptual de la Dirección de Proyectos. Proporciona una estructura
básica para entender la dirección de proyectos.
Sección II: Norma para la Dirección de Proyectos de un Proyecto. Especifica todos los pro-
cesos de dirección de proyectos que usa el equipo del proyecto para gestionar un proyecto.

Sección III: Áreas de conocimiento de la Dirección de Proyectos. Organiza los 44 procesos

de dirección de proyectos de los Grupos de Procesos de Dirección de Proyectos en nueve
Áreas de Conocimiento.

8.4. Estándar IEEE 730-2002

8.4.1. Comparativa del plan de SQAP (IEEE STD 730-2002) con la ISO 9001
En este apartado se describe las estructuras de organización de proyecto que debes aparecer
en un Plan de Calidad. Además, por cada una de ellas, se comenta cómo es cubierta por el
conjunto el estándar ISO 9001.

Propósito específico y alcance de dicho plan. Se enumerarán todos los ítems cubiertos por
el Plan de Calidad y el uso que se pretende para el software. Se dirá qué parte del ciclo de
vida es cubierto por el Plan de Calidad para cada ítem de software especificado.
Documentos de referencia. Se completa una lista completa de las referencias hechas en
algún lugar del Plan de Calidad.

Gestión. En esta sección se describen las tareas, la organización y las responsabilidades.

Referencia ISO 9001:
Esta sección es la más crítica para lograr la conformidad con ISO 9000. Aquí se incluye
la estructura de la organización con respecto a la calidad. ISO 9000 destaca que hay que
reseñar quién es el que tiene responsabilidad directa para la calidad de un desarrollo
específico.

68
Documentación. En esta sección se identifica la documentación que gobierna el desarro-
llo, verificación y validación, uso y mantenimiento del software, y se establece cómo se
comprobará la adecuación de esta documentación.
Referencia ISO 9001:
Ésta es una debilidad de ISO 9000. No se especifica qué tipo de documentación es necesaria.
Estándares, prácticas y métricas. El objetivo es establecer cómo la conformidad con estos
ítems (estándares, prácticas y métricas) se asegura y se monitoriza.

Revisiones y auditorías. El propósito es establecer qué revisiones y auditorías se van a

acometer, cómo y cuáles son las futuras acciones adicionales que son requeridas.
Referencia a ISO 9001:
ISO 9001 le da una gran importancia a las auditorías. Hoy en día se conoce que las acti-
vidades de revisiones y de auditorías son las técnicas más efectivas para detectar errores.
Sin embargo, en ISO 9000 está más orientado a la gestión y no sólo al aspecto técnico.

Tests. En esta sección se identifican todas las pruebas no incluidas en el Plan de V&V y los
métodos que se deben usar.
Referencia a ISO 9001:
ISO 9001 contiene tres cláusulas que tienen que ver con el testing: una que se refiere a la ins-
pección y testing; otra que se refiere al control de la inspección, medición y equipamiento
de pruebas; y una última que se refiere al estado de la inspección y de las pruebas.
Informe de problemas y acciones correctivas. Aquí se describen las prácticas y procedi-
mientos que se siguen para informar, monitorizar y resolver los problemas identificados
en ítems de software y también en su desarrollo y proceso de mantenimiento.
Referencia a ISO 9001:
ISO 9001 hace énfasis en el mantenimiento del producto. Hay dos cláusulas que lo contem-
plan: Acción correctiva y preventiva; y Servicio. En particular separa las acciones preventi-
vas de las correctivas.
Herramientas, técnicas y metodología. En esta sección se identifican las herramientas soft-
ware, herramientas y metodologías que soportan SQAP, el estado que requieren para este
propósito y se describe su uso.
Referencia a ISO 9001:
ISO 9001 establece que el proveedor necesita controlar, calibrar y mantener la inspección,
medición y equipamiento de pruebas. Incluso las herramientas de software necesitan ser
evaluadas por su aplicabilidad en un determinado proyecto.
Control de código. En esta sección se definen los métodos y facilidades usadas para man-
tener, almacenar, asegurar y documentar versiones controladas del software identificado
durante todas las fases del ciclo de vida software.
Referencia a ISO 9001:
Área problemática para ISO 9001. Se discute mucho sobre el diseño y su control, pero el
código nunca se menciona.
Control de Medios. En esta sección se establecen los métodos y facilidades para identifi-
car los dispositivos físicos de cada producto software, y la documentación requerida para
almacenar los dispositivos, incluyendo los procesos de copia y de restauración, y para pro-
teger a estos dispositivos de acceso no autorizado o de daño no advertido o de degradación
a lo largo de las fases del ciclo de vida.
Referencia a ISO 9001:
La situación es parecida a la del control del código. Aquí se refiere al control de los dispo-
sitivos físicos. Esto debe realizarse en interfaz constante con la gestión de configuración.

69
Control de proveedores. Esta sección establece las medidas que aseguren que el software
proporcionado por los proveedores reúne los requerimientos establecidos.
Referencia a ISO 9001:
La cláusula 4.7 discute el purchasing que consiste de: evaluación de los subcontratistas, la
comprobación de que los documentos adquiridos describen el producto pedido, la verifi-
cación del proveedor que cumple con las premisas de subcontratación, y la verificación por
el cliente del producto subcontratado. ISO 9001 tiene una cláusula denominada “control
de productos proporcionados al cliente” (4.7) que presta atención a este tema.

Gestión de registros: mantenimiento y retención. Esta sección identifica la documenta-

ción de SQAP que se tiene que retener, y los métodos usados para ensamblar, guardar y
mantener esta documentación, y designar el periodo de retención.
Referencia a ISO 9001:
La cláusula ISO 9001 4.20 “Técnicas estadísticas” establece que se necesita establecer pro-
cedimientos documentados para medir las capacidades de proceso.
Training. Esta sección identifica las necesidades de entrenamiento para reunir las necesi-
dades del Plan de Calidad.
Referencia a ISO 9001:
La cláusula 4.18 discute las necesidades de entrenamiento para toda la compañía.

Gestión de riesgos. En esta sección se especifican los métodos y procedimientos empleados

para identificar, valorar, monitorizar y controlar las áreas de riesgo que surgen durante la
parte del ciclo de vida de software cubierto por el Plan de Calidad.
Referencia a ISO 9001:
ISO 9001 no parece que discuta la gestión de riesgos. Sin embargo la cláusula 4.3 que
discute la revisión de contrato puede ser adaptada para cubrir este aspecto.

70
Parte IV
Calidad de Procesos
9. Evaluación y mejora de procesos
9.1. Introducción
La calidad final del producto software se encuentra directamente relacionada con la forma en
que se desarrolla y mantiene, es decir, con el proceso; lo que explica la aparición de numerosos
modelos de evaluación de procesos.
En este capítulo se presenta una perspectiva general de los modelos de evaluación, referencia
y mejora de procesos.

9.2. Panorámica general

En los últimos años se ha generado una gran proliferación de propuestas para la evaluación,
referencia y mejora de los procesos. En (Sheard et al., 1998) se destaca la gran cantidad de
marcos que pueden convertir este campo en “una ciénaga en la que se empantanen los esfuerzos
de mejora de procesos si una organización no es cuidadosa”.

9.2.1. Armonización de estándares

Actualmente existe un gran abanico de modelos que pueden ser tomados como referencia de
procesos, evaluación y mejora; sin embargo, ninguno de los marcos de referencia definidos en la
actualidad es la “panacea”. Las empresas necesitan diferentes modelos para abordar todos sus
procesos, es importante y necesario que se haga un framework que soporte la armonización de
los elementos de proceso de los diferentes modelos que pretenden utilizar.
En este sentido, proponemos un framework que describe un conjunto de elementos para ar-
monizar elementos de múltiples modelos de una manera sistemática y coherente. Los elementos
y relaciones que conforman este framework son, resumidamente:
Guía para la determinación de los objetivos de armonización. Los objetivos de armonización
deben estar claramente identificados. Para ello, es necesario analizar el plan estratégico y
los objetivos organizacionales. El análisis permitirá identificar los marcos a armonizar.
Proceso para la armonización de marcos. Este proceso constituye la guía sobre la cual se lleva
a cabo la identificación, definición y configuración de las estrategias de armonización.
Ontología para la armonización de marcos. Esta ontología1 identifica los términos, definiciones
y relaciones necesarias para apoyar la armonización de marcos.
Conjunto de técnicas y métodos. El conjunto de técnicas y métodos facilitan la configuración
y definición de las estrategias de armonización.

9.3. La norma ISO/IEC 90003

La norma ISO/IEC 90003 proporciona pautas para las organizaciones en la aplicación de
ISO 90001 para la adquisición, provisión, desarrollo, operación y mantenimiento del software
mediante la definición de un sistema de gestión de calidad. ISO 90003 no modifica los requisitos
de ISO 9001, sino que ofrece pautas que los aclaran, extienden y los hacen más específicos para
organizaciones desarrolladoras de software.
Según IDO 90003 la organización debe establecer, documentar, implementar y mantener un
sistema de gestión de la calidad software y mejorar continuamente su eficacia de acuerdo con
los siguientes requisitos generales:
Identificar los procesos necesarios para el sistema de gestión de la calidad y su aplicación
a través de la organización.
1 Formulación de un exhaustivo y riguroso esquema conceptual dentro de uno o varios dominios dados; con la

finalidad de facilitar la comunicación y el intercambio de información entre diferentes sistemas y entidades.

71
 Determinar la secuencia e interacción de estos procesos.
Determinar los criterios y métodos necesarios para asegurarse de que tanto la operación
como el control de estos procesos sean eficaces.
Asegurarse de la disponibilidad de recursos e información necesarios para apoyar la ope-
ración y el seguimiento de estos procesos.
Realizar el seguimiento, la medición y el análisis de estos procesos.
Implementar las acciones necesarias para alcanzar los resultados planificados y la mejora
continua de estos procesos.

9.4. Seis-Sigma para software

Seis-Sigma puede ser aplicado en ingeniería del software, ya que ofrece técnicas para garan-
tizar que se entienden los requisitos del cliente, que se mida y evalúe el impacto de los cambios,
y que el proceso de desarrollo sea más confiable.
El primer paso para aplicar Seis-Sigma al desarrollo de software es entender cómo definir la
metodología de desarrollo, quienes están involucrados en cada fase, y cuáles son los flujos de
trabajo y sus dependencias. Las fases típicas son: iniciación del proyecto, análisis del sistema,
diseño del sistema, construcción, pruebas y aseguramiento de la calidad e implantación. La
Tabla muestra la correspondencia entre las fases típicas para el desarrollo de software, las fases
de DMAIC y DMADV de Seis-Sigma.

Fases de desarrollo de DMAIC DMADV

software
Iniciación del proyecto Definir, medir, analizar Identificación y definición
Análisis del sistema Definir, medir, analizar Definición y desarrollo
Diseño del sistema Analizar Desarrollo
Construcción Mejorar Desarrollo
Pruebas y aseguramiento de Mejorar Verificación
la calidad
Implantación Mejorar y controlar Verificación
Cuadro 5: Mapeo de las fases de desarrollo, seis-sigma y DFSS.

Iniciación del proyecto. Identificar el problema, formar el equipo, identificar los requisitos
preliminares, validar los requisitos, desarrollar un estudio de viabilidad y obtener la apro-
bación del proyecto. Incorporar todos los pasos de la fase de definición del modelo DMAIC
y de la fase de identificación y definición de DMADV.
Análisis del sistema. El sistema o producto (y) es un resultado del diseño y construcción (f)
basado en los requisitos (x), es decir y = f ( x ). Se recomiendan los siguientes pasos:

1. Entender el proceso actual.

2. Identificar los requisitos.
3. Priorizar los requisitos.
4. Identificar potenciales mejoras del proceso.
5. Determinar cuáles mejoras tendrán un gran impacto sobre los requisitos de alta prio-
ridad.
6. Crear un mapa de procesos a llevar a cabo detallado.
7. Valorar el impacto y riesgo de las mejoras de procesos propuestas.
8. Completar el desarrollo del diseño conceptual.
9. Completar el documento de especificación de requisitos.

72
 10. Obtener la aprobación.

Diseño del sistema. Tres actividades que son ejecutadas secuencialmente: realizar el diseño
funcional, realizar el diseño técnico y realizar el diseño del programa, que pueden ser
apoyadas por técnicas de DMADV.
Construcción. Es útil comparar la funcionalidad del código contra la matriz de requisitos
del cliente descritos en QFD (Quality Function Deployement).
Pruebas. Un plan de pruebas ayuda a reducir la variación y asegurar que las medidas de
los defectos son repetibles y reproducibles.
Implantación. El objetivo es tener un producto entregable al cliente y colocarlo en produc-
ción en el entorno de trabajo.

9.5. EFQM para software

Hay pocos trabajos en la literatura que abordan la aplicación o integración de este modelo en
el campo de la calidad software, pero podemos destacar los siguientes:
El modelo integrado EFQM/SPICE, el cual combina las características de los modelos
EFQM y SPICE, llevando a la práctica las ideas de la calidad total aplicadas al proceso
de desarrollo de software. Este modelo se centra en la mejora de los resultados de los
procesos de negocio, considerando las expectativas de los clientes, y garantizando la cone-
xión entre la mejora del proceso software y los resultados empresariales que se obtienen.
Mantiene la estructura externa del modelo EFQM pero se configura internamente como
SPICE.
El “nuevo modelo de EFQM para organizaciones intensivas en software” aborda la mejora
de procesos software desde la perspectiva del impacto de esta estrategia en los resultados
de negocio y dentro de un marco de excelencia en gestión, tomando como referencia el
modelo de excelencia EFQM y el modelo de mejora de procesos software CNMI. Adopta
la estructura externa y el ciclo de mejora del modelo EFQM y propone un conjunto de
procesos operacionales específicos para el desarrollo del software basados en CNMI.
El framework propuesto en (Gray et al., 2005) para la evaluación y mejora de procesos soft-
ware. Esta propuesta analiza las técnicas de evaluación basadas en el uso de cuestionarios,
matrices de evaluación, talleres, y esquemas de evaluación proforma, junto con temas de
recursos humanos como son la motivación y la participación.

9.6. Mejora de procesos en Pymes

La evaluación y mejora de procesos software teniendo en cuenta las características y necesi-
dades especiales de las pequeñas empresas, las cuales necesitan sobrevivir en un mercado global
cada vez más competitivo, pero no tienen suficientes recursos económicos para aplicar métodos
complejos.

9.6.1. COMPETISOFT
COMPETISOFT es una iniciativa integradora de diferentes propuestas de mejora de procesos
software para Pymes desarrolladoras de software. Su objetivo es mejorar el nivel de competi-
tividad de las Pymes productoras de software mediante la creación y difusión de un marco
metodológico común.

9.6.1.1. Modelo de referencia de procesos El modelo de referencia de procesos de COMPETISOFT

agrupa los procesos en tres categorías principales: Alta dirección, Gestión y Operación.
Dentro de la categoría de Alta dirección (DIR) se incluye únicamente el proceso de Gestión
de Negocio, que engloba todas las prácticas relacionadas con la gestión de la empresa. La cate-
goría de Gerencia (GER) está compuesta por cinco procesos, en los que se incluyen las prácticas
necesarias para la gestión de procesos, proyectos y recursos. En la categoría de Operación (OPE)
se incluyen las prácticas de los proyectos de desarrollo y mantenimiento de software agrupadas

73
en tres procesos. t’La categoría de Operación realiza sus actividades de acuerdo a las directri-
ces marcadas por la categoría de Gerencia, y le debe entregar toda la información y productos
generados.

9.6.1.2. Modelo de evaluación de procesos Con respecto al modelo de evaluación de procesos,

COMPETISOFT sugiere utilizar como base la norma internacional ISO/IEC 15504.

9.6.1.3. Modelo de mejora de procesos El modelo de mejora de procesos de COMPETISOFT

se caracteriza por ser un modelo ligero con el fin de facilitar su aplicabilidad en las Pymes
desarrolladoras de software. El modelo propuesto ha sido desarrollado con el fin de:
Establecer los elementos necesarios para guiar y gestionar la mejora de procesos en una
pequeña organización software, y lograr institucuinalizar la cultura de la mejora continua
al interior de la organización.
Facilitar su aplicación en las pequeñas organizaciones software de forma económica, con
pocos recursos y en poco tiempo, buscando siempre obtener resultados de mejora visibles
a corto plazo.

El modelo de mejora de COMPETISOFT define un conjunto de componentes los cuales se des-

criben a continuación:
1. Un proceso para guiar la mejora continua de procesos denominado PmCOMPETISOFT.
2. Una metodología para la valoración de procesos denominada METvalCOMPETISOFT.

3. Una guía para formular y ejecutar mejoras utilizando Scrum.

4. Una estrategia para la selección y priorización de procesos.

9.6.2. ISO 29110

ISO ha constituido el grupo de trabajo denominado SC-7WG24 con el objetivo de que sus
estándares de procesos software puedan ser aplicados a pequeñas empresas desarrolladoras de
software. A las pequeñas empresas les resulta difícil relacionar las normas ISO con sus necesi-
dades de negocio y por tanto justificar la aplicación de estas normas.
El nombre general de la norma ISO/IEC 29110 es Software Engineering — Lifecycle Profiles
for Very Small Entities (VSE). Se compone de varios documentos, unos llamados perfiles y otros
llamados informes técnicos. Un perfil es un subconjunto de uno o más estándares necesarios para
llevar a cabo una función particular. Los informes técnicos se utilizan para presentar las guías
sobre la implementación de perfiles en VSE. Estas guías proporcionan información práctica para
facilitar la implementación de los perfiles.

9.6.2.1. Visión general La visión general introduce todos los conceptos principales necesarios
para comprender y utilizar los documentos del ISO/IEC 29110.

9.6.2.2. Perfiles (ISP) Los perfiles se definen con el objetivo de empaquetar referencias a y/o
partes de otros documentos de manera formal con el fin de adaptarlos a las necesidades y
características de las VSE. Preparar perfiles implica producir dos tipos de documentos para esta
norma:
Marco de trabajo y taxonomía. Este documente establece la lógica detrás de la definición y
aplicación de los perfiles. Especifica los elementos comunes a todos los perfiles e introduce
la taxonomía de los perfiles. Este documento está dirigido a autores y revisores de ISP.
Especificaciones de perfil. Por cada perfil, hay un documento de especificación de perfil. Su
propósito es proporcionar la composición definitiva de un perfil, proporcionar enlaces
normativos al subconjunto normativo de estándares usados en el perfil, y proporcionar
enlaces informativos a documentos de “entrada”.

74
9.6.2.3. Guías Las guías contienen directrices de aplicación sobre cómo realizar los procesos
para alcanzar los niveles de madurez. Las guías se desarrollan para la implementación del pro-
ceso y para la evaluación basada en aspectos de dominio, prácticas y riesgos del negocio. Las
guías están dirigidas a VSE y deberían ser accesibles por la VSE. Hay dos tipos de guías:
Guía de evaluación. Esta guía describe el proceso a seguir para realizar una evaluación
que determine las capacidades de proceso y/o la madurez organizacional.
Guías de ingeniería y gestión. Las guías de ingeniería y gestión proporcionan orientación
sobre la implementación de un perfil. Para cada perfil, existe un documento de guía de
ingeniería y gestión.

75
10. Evaluación y mejora de procesos (apuntes E.D.)
10.1. Introducción
La calidad del software está tomando mayor importancia en las organizaciones por su in-
fluencia en los costes finales y como elemento diferenciador de la competencia.
Los modelos de calidad existentes ofrecen normas y parámetros, con pasos específicos para
la creación de proyectos informáticos. La calidad del software es fundamental y su evaluación
se hace pertinente para que se cumplan los propósitos que se quieren lograr.

10.2. Norma ISO 90003

Esta norma internacional promueve la adopción de un enfoque basado en procesos cuando
se desarrolla, implanta y mejora la eficacia de un sistema de gestión de la calidad, basado a su
vez en el ciclo de mejora continua PDCA (Planificar, Hacer, Comprobar, Actuar).
Los beneficios que podemos encontrar ante el mercado son:
Mejorar la imagen de los productos ofrecidos.

Favorecer su desarrollo.
Ganar cuota de mercado y acceder a mercados exteriores gracias a la confianza que genera
entre los clientes.
Los beneficios ante los clientes son:

Aumento de la satisfacción.
Eliminar múltiples auditorías.
Acceder a acuerdos de calidad concertada con los clientes.

Beneficios para la gestión de la empresa:

Servir como medio para mantener y mejorar la eficacia y adecuación del sistema de gestión
de la calidad, al poner de manifiesto los puntos de mejora.
Cimentar las bases de la gestión de la calidad para entrar en un proceso de mejora continua.

Aumentar la motivación y participación de personal.

El ISO 9000 (descrito en la Parte I) proporciona un conjunto de estándares para la gestión de la
calidad en cualquier actividad relacionada con el proceso de producción.
El ISO 9000 se ha especializado en todo lo referente a la solución del software en el ISO 90003.
Las ideas básicas que se nos propone para el estándar ISO 90003 son las siguientes:

El control de calidad debe ser aplicado a todas las fases de la producción de software,
incluido el mantenimiento y tareas posteriores a su implantación.
Debe existir una estricta colaboración entre la organización que adquiere el software y el
proveedor del mismo.
El proveedor del software debe definir su sistema de calidad.

Como ya hemos comentado el ISO 90003 es una guía que está formada por una serie de cláusulas
que indican cómo aplicar esta guía. Las cláusulas más importantes que componen el ISO 90003
son:
Administración de la Responsabilidad. Permite organizar la estructura del sistema de ca-
lidad, abordando la estrategia y organización como requerimientos para verificar y revisar
la calidad.
Sistema de Calidad. Requiere una planificación y documentación del sistema de calidad,
requisito conocido como Plan de Garantía de Calidad del Software o SQAP.

76
 Acción correctora. No existe una receta para el proceso de acciones correctoras, pero el
estándar IEEE 1044 nos puede ser útil para clasificar los tipos de anomalías que pueden
ser encontradas.
Revisión del contrato. Esta cláusula insiste en la necesidad de que el proveedor examine
los contratos referidos al sistema de calidad.
Especificación de los requerimientos de la Organización. Se establece la premisa, de la
mutua colaboración entre el proveedor y la organización que adquiere el producto softwa-
re.
Planificación del desarrollo. Esta cláusula sitúa los requerimientos en un plan de desarro-
llo.
Planificación de la Calidad. La metodología de medidas de calidad puede sernos útil para
establecer los objetivos de calidad.
Diseño e implementación/testeo y validación. Estas dos cláusulas se centran en las activi-
dades centrales del proceso de desarrollo de software.
Adaptación. Estas pruebas son más bien generales, dado que en los estándares no hay
definido un homólogo.
Generación, entrega e instalación. Los requerimientos de pruebas y medios de control.
Mantenimiento. Esta cláusula proporciona una extensa lista de requerimientos de calidad,
para la fase de mantenimiento del ciclo de vida.
Las cláusulas restantes proporcionan requerimientos para las actividades de soporte, es decir
aquellas que no son específicas de ninguna fase en concreto.
Administración de la configuración/documentos de control. Las actividades que detallan
estos requerimientos, se encuentran en los llamados Planes de Gestión de la Configuración
del Software.
Medidas, reglas y convenciones, herramientas y técnicas. Estas cláusulas nos hablan del
uso de procedimientos y herramientas apropiados para implementar el sistema de calidad.
Compra/productos de software incluidos. Los requerimientos que rigen las compras del
proveedor de los vendedores se encuentran en estas dos cláusulas.
Formación. La única mención que se realiza en los estándares se encuentra en el estándar
730.
Se puede considerar que las relaciones más significativas y directas que mantiene el estándar
ISO 90003 son las que los relacionan con el ISO 9001 y con el IEEE 730, ya vistas en la Parte III.
El primero proporciona normativas de requerimientos para garantizar la calidad de los siste-
mas y es uno de los estándares de calidad más relevantes para la ingeniería del software. El ISO
90003 nos proporciona una guía específica para aplicar las necesidades del ISO 9001 al software.
La estrategia seguida por el 90003 es ampliar la parte de diseño del 9001, mientras dejará sin
tocar las otras partes.
El estándar IEEE 730 establece el puente entre la gestión de la calidad y la ingeniería del
software, el cual recomienda unos requerimientos para llevar a cabo un Plan de Garantía de
Calidad asociado a un proyecto de software. Mientras que la ISO 90003 está pensada para ser
aplicada en toda una organización, el IEEE 730 es aplicado a un único proyecto dentro de esa
organización.

10.3. Modelo Six-Sigma

10.3.1. Six-Sigma para software
El objetivo de utilizar Six-Sigma en un contexto de TI es el de lograr un diseño y desarrollo
de software de alta calidad mediante la aplicación de procesos y herramientas de calidad. La
aplicación de esta metodología busca un cambio en los procesos hacia la detección temprana

77
de defectos, ayuda a la toma de decisiones sobre tecnologías, diseño y arquitectura de sistemas,
basadas en datos reales.
La meta de Six-Sigma es llegar a un máximo de 3,4 defectos por millón de eventos u oportu-
nidades (DPMO), entendiéndose como defecto a cualquier evento en que un producto o servicio
no logra cumplir los requisitos del cliente.
Si desarrollamos los principales principios en los que se basa Six-Sigma:
1. Liderazgo comprometido de arriba a abajo. La estrategia se apoya y compromete desde
los niveles más altos de la dirección y la organización.

2. Six-Sigma se apoya en una estructura directiva que incluye personal a tiempo completo.
Cada uno de los líderes tiene roles y responsabilidades específicas para formar proyectos
de mejora.
3. Entrenamiento. Cada uno de los actores del programa de Six-Sigma requiere de unos
entrenamientos específicos.

4. Acreditación.
5. Orientada al cliente y enfocada a los procesos. Esta metodología busca que todos los pro-
cesos cumplan con los requerimientos del cliente y que los niveles de calidad y desempeño
cumplan con los estándares de Six-Sigma. Se requiere profundizar en el entendimiento del
cliente y sus necesidades.

6. Dirigida con datos. Los datos son necesarios para identificar las variables de calidad y los
procesos y áreas que tienen que ser mejorados.
7. Se apoya en una metodología robusta. Se requiere de una metodología para resolver los
problemas del cliente, a través del análisis y tratamiento de los datos obtenidos.

8. Los proyectos generan ahorros o aumento en ventas.

9. El trabajo se reconoce.
10. La metodología Six-Sigma plantea proyectos largos. Es una iniciativa con horizonte de
varios años.

11. Six-Sigma se comunica. Los programas de Six-Sigma se basan en una política intensa de
comunicación entre todos los miembros y departamentos de una organización, y de fuera
de la organización.
El Ciclo de Vida del Desarrollo de Software (SDLC) consiste fundamentalmente en cuatro fases:
Análisis, Diseño, Implementación y Pruebas. En el apartado 9.4 de este texto se describe de
manera general cómo Six-Sigma puede ser aplicado e integrado en estas fases.
El alumno debe conocer los dos procesos metodológicos que se proponen en Six-Sigma:
DMAIC para operaciones ya existentes y DMADV para nuevos productos o servicios.

10.3.2. Metodología DMAIC

El proceso Six-Sigma para esta metodología DMAIC se caracteriza por cinco etapas concretas:

1. Definir el problema o el defecto.

2. Medir y recopilar datos.
3. Analizar datos.

4. Mejorar.
5. Controlar.

78
10.3.2.1. Definir En la fase de definición se identifican los posibles proyectos Six-Sigma que
deben ser evaluados por la dirección para evitar la inadecuada utilización de recursos.
Las salidas que debe proporcionar esta fase son:

Proyecto de alta prioridad, proceso que será mejorado.

Definición del proyecto: planteamiento del problema, objetivo del proyecto, alcance y enti-
dades, datos de apoyo, miembros del equipo y dueño del proceso.
Plan del proyecto: tiempo, recursos y coste.

10.3.2.2. Medir La fase de medición consiste en la caracterización del proceso identificando

los requisitos clave de los clientes, las características clave del producto y los parámetros que
afectan al funcionamiento del proceso.

Determinar qué medir (Y) y validar en el sistema de medición.

Cuantificar el desempeño actual y realizar la estimación de la meta de mejora.
Las salidas que debe proporcionar esta fase son:
Actualización del planteamiento del problema/objetivo del proyecto.

Validación del análisis del sistema de medición.

Datos base para calcular el desempeño del proceso/producto.
Meta estimada de mejora.

10.3.2.3. Análisis En la fase de análisis, el equipo evalúa los datos de resultados actuales e
históricos. Se desarrollan y comprueban hipótesis sobre posibles relaciones causa-efecto.
Identificar las causas (X) de variación y defectos.

Proporcionar evidencia estadística para probar que las causas son reales.
Comprometerse con la meta de mejora para Y.
Las salidas que debe proporcionar esta fase son:

Causas verificadas de la variación/defectos.

Compromiso de la meta de mejora.

10.3.2.4. Mejora En la fase de mejora el equipo trata de determinar la relación causa-efecto

para predecir, mejorar y optimizar el funcionamiento del proceso.
Determinar soluciones, incluyendo los niveles operativos y las tolerancias.
Instalar las soluciones y proporcionar la evidencia estadística que compruebe que las solu-
ciones funcionan.

Las salidas que debe proporcionar esta fase son:

Soluciones para contrarrestar las causas.
Instalación parcial de las soluciones y los datos que verifican el impacto de las soluciones
en Y.

Implementación total de las soluciones.

79
10.3.2.5. Control Esta fase de control consiste en diseñar y documentar los controles necesa-
rios para asegurar que lo conseguido mediante el proyecto Six-Sigma se mantenga una vez que
se hayan implementado los cambios.
Las salidas que debe proporcionar esta fase son:
Nuevos procedimientos operativos estándar y controles ya instalados.
Datos de la nueva capacidad del proceso.
Comparación del nuevo nivel de desempeño con la meta.

Documentación del proyecto.

Oportunidades de trasladar las mejoras a otras áreas (Plan de Despliegue).

80
Parte V
Técnicas y Herramientas para la calidad del
software
11. Técnicas y herramientas de calidad (apuntes E.D.)
11.1. Herramientas básicas de medición
11.1.1. Diagrama de flujo
El diagrama de flujo es una representación gráfica de una secuencia de pasos que se realizan
para obtener un resultado. El resultado perseguido puede ser un producto, un servicio, o bien
una combinación de ambos. El proceso para la construcción de un diagrama puede incluir los
siguientes pasos:
1. Preparación de la construcción del diagrama. El grupo de trabajo identificará los organis-
mos implicados en el proceso que debe ser analizado.
2. Desarrollo de la construcción. Definir claramente la utilización del diagrama de flujo y el
resultado que se espera obtener de la sesión de trabajo. Definir los límites del proceso en
estudio. La mejor forma de definir y clarificar dicha definición de los límites del proceso es
decidir cuáles son el primer y último paso del diagrama de flujo. Esquematizar el proceso
en grandes bloques o áreas de actividades. Identificar los grupos de acciones más relevan-
tes del proceso y establecer su secuencia temporal. Realizar el trabajo adecuado para los
puntos de decisión o bifurcación. Cuando se llega a u paso en el que existe un punto de
decisión o bifurcación:

a) Escribir la decisión o alternativa de acuerdo con la simbología utilizada e identificar

los posibles caminos a seguir mediante la notación adecuada.
b) Escoger la rama más natural o frecuente de la bifurcación y desarrollarla.
c) Retroceder hasta la bifurcación y desarrollar el resto de las ramas de igual modo.

Un ejemplo podría ser la emisión de billetes y facturación de equipajes de una línea aérea para
clientes que llegan sin billetes al aeropuerto. Se plantearía al cliente la realización de dos colas:
una para sacar el billete y otra para la facturación de acuerdo al siguiente proceso (Figura 13).

11.1.2. Diagrama de causa-efecto: Ishikawa

El diagrama de causa-efecto es una representación gráfica que muestra la relación cualitativa
e hipotética de los diversos factores que pueden contribuir a un efecto o fenómeno determinado.
La realización de un diagrama de Ishikawa puede conseguirse siguiendo los siguientes pasos:
1. Definir, sencilla y brevemente, el efecto o fenómeno cuyas causas han de ser identificadas.
2. Colocar el efecto dentro de un rectángulo a la derecha de la superficie de escritura y
dibujar una flecha, que corresponderá al eje central del diagrama, de izquierda a derecha,
apuntando hacia el efecto.
3. Identificar las posibles causas que contribuyen al efecto o fenómeno del estudio.
4. Identificar las causas principales e incluirlas en el diagrama.

a) En primer lugar se identificarán las causas más generales en la contribución al efecto.

b) En segundo lugar se escriben en un recuadro y se conectan a la línea central.

5. Añadir causas para cada línea principal. Se rellenan cada una de las ramas principales
con sus causas del efecto enunciado. Para incluir estas en el diagrama se escriben al fi-
nal de unas líneas, paralelas a la de la flecha central, y conectadas con la línea principal
correspondiente.

81
 Figura 13: Diagrama de flujo para un cliente que desea tomar un vuelo.

6. Añadir causas subsidiarias para las subcausas anotadas. Cada una de ellas se coloca al
final de una línea que se traza para conectar con la línea asociada al elemento al que afecta
y paralela a la línea principal. Este proceso continúa hasta que cada rama alcanza la causa
raíz. Causa raíz es aquella que:

Es causa del efecto que estamos analizando.

Es controlable directamente.

7. Comprobar la validez lógica de cada cadena causal. Para cada causa raíz leer el diagrama
en dirección al efecto analizado, asegurándose de que cada cadena causal tiene sentido
lógico y operativo. Por ejemplo, dado el texto “Un error de lectura es causa de la fatiga,
que es causa de un error en el número codificado”, mostramos su representación en la
Figura 14.

Figura 14: Parte de un diagrama de causa-efecto.

8. Comprobar la integración del diagrama.

82
Ejemplo En una organización se encarga a un equipo de mejora la solución del problema de
los retrasos en el proceso de órdenes de compra. Para identificar posibles causas del retraso,
se construye un diagrama de causa-efecto mediante proceso lógico paso por paso. El enfoque
adoptado consistió en basar la ordenación del diagrama en las fases del proceso, previamen-
te identificadas a través de un diagrama de flujo. Se observa en la Figura 15 el diagrama de
causa-efecto resultante.

Figura 15: Diagrama de causa-efecto para el ejemplo.

11.1.3. Diagrama de Pareto

El diagrama de Pareto es una herramienta de análisis de datos útil en la determinación de
la causa principal durante un esfuerzo de resolución de problemas. Permite ver cuáles son los
problemas más grandes.
Este diagrama se realiza aplicando 12 pasos:

1. Seleccionar categorías lógicas para el tópico de análisis identificado.

2. Reunir datos con alguna de las técnicas disponibles como las listas de comprobación.
3. Ordenar los datos de la mayor categoría a la menor.
4. Totalizar los datos para todas las categorías.

5. Calcular el porcentaje del total que cada categoría representa.

6. Trazar los ejes horizontal (x) y verticales (y primario, y secundario).
7. Trazar la escala del eje vertical izquierdo para frecuencia (0 a total).

8. De izquierda a derecha trazar las barras para cada categoría en orden descendente. Si existe
una categoría “otros”, debe ser colocada al final sin importar su valor.
9. Trazar la escala del eje vertical derecho para el porcentaje acumulativo, comenzando por el
0 y hasta el 100 %.

10. Trazar el gráfico lineal para el porcentaje acumulativo, comenzando en la parte superior
de la barra de la primera categoría.
11. Dar un título al gráfico.
12. Analizar la gráfica para determinar los “pocos vitales” (las categorías que tienen más peso).

83
Ejemplo Un gran almacén, que registraba elevados costes por hurtos, encargó a un grupo de
trabajo resolver el problema. El equipo decidió empezar las investigaciones recogiendo datos
sobre los costes por hurtos en varias secciones a partir de los cuales realizó un diagrama de
Pareto:

Sección Costes % del total % acumulado

Joyería 62 22 % 22 %
Perfumería 58 20 % 42 %
Deportes 50 18 % 60 %
Música 47 17 % 77 %
Electrodomésticos 22 8% 85 %
Ropa 16 6% 91 %
Alimentación 15 5% 96 %
Hogar 10 3% 99 %
Muebles 4 1% 100 %
TOTAL 284 100 %
Cuadro 6: Tabla de Pareto y los costes por hurtos.

Seguimos los 12 pasos y confeccionamos el diagrama de Pareto mostrado en la Figura 16:

Figura 16: Diagrama de Pareto.

En las primeras cuatro secciones se registran el 77 % de los costes totales por hurtos. Estas
son las “pocas vitales”. El equipo tendrá que concentrar sus esfuerzos en buscar soluciones que
evitan los hurtos en estas cuatro secciones.

11.1.4. Hojas de comprobación

Una hoja de comprobación es un impreso que se diseña como herramienta para la recogida
de datos, de forma que los resultados de la misma puedan ser más fáciles y rápidamente inter-
pretados. Comentaremos brevemente los dos tipos principales: la de recogida de datos y las de
lista de comprobación.
Las hojas de recogida de datos son impresos que se utilizan para reunir datos que normal-
mente se anotan de forma tabular o en columnas. En general requieren de un proceso adicional,
utilizando una herramienta de análisis. Las listas de comprobación se diseñan para responder a
preguntas específicas y son de por sí una herramienta de análisis.
El proceso se puede resumir en la generación de información y su planificación:
1. La generación de información útil requiere de los siguientes pasos:

a) Formular, de manera precisa, las preguntas que necesitamos contestar en cada mo-
mento para decidir de forma adecuada las futuras acciones a realizar.

84
 b) Recoger los datos relativos a esta pregunta.
c) Analizar esos datos para determinar la respuesta a las preguntas planteadas.
d) Presentar los datos de forma que dicha presentación sea capaz de comunicar clara-
mente la respuesta a dichas preguntas.

2. La adecuada planificación de este proceso requiere recorrerlo en sentido inverso:

a) Se comienza definiendo las preguntas que necesitamos contestar.

b) En segundo lugar se considera cuál sería la forma idónea de transmitir la respuesta a
dichas preguntas.
c) A partir de la herramienta de comunicación a utilizar, se define el tipo de análisis que
es necesario realizar para responder a las preguntas planteadas.
d) Una vez alcanzado este punto, estamos en disposición de definir las necesidades de
datos existentes e identificar qué características de los mismos son más importantes.

Ejemplo En una empresa de producción de coches un equipo fue encargado de incrementar

la rapidez del proceso de envío de las piezas de recambio pedidas por los concesionarios. El
equipo decidió empezar analizando el tiempo actualmente necesario para procesar los pedidos
que llegaban de los talleres.
La pregunta interesante era: “¿cuántos días laborables transcurren desde que el peticionario
firma el pedido hasta que se envían las piezas correspondientes?”. El enfoque ideal era preguntar
a los empleados del almacén. El diseño de la hoja de comprobación evidencia la distribución de
tiempos de forma inmediata y la distribución se puede analizar sin ningún tratamiento adicional,
tal y como puede observarse en la Figura 17.

Figura 17: Hoja de comprobación.

11.1.5. Diagrama de control

Son representaciones gráficas utilizadas para determinar desde un punto de vista estadístico
si un proceso está o no bajo control, esto es, si hay variabilidad en el proceso y descubrir a qué
obedece esta variabilidad.
Consta de una línea central (que suele ponerse entorno a la media muestral µ) y dos límites
de control superior (LCS) e inferior (LCI) que se basan en conceptos y resultados estadísticos.
En el gráfico se dibujan los datos correspondientes al proceso. Si todos los puntos están entre
estos dos límites, puede decirse que el proceso está bajo control.

11.1.5.1. Gráficos de Control por Variables Los pasos que hay que dar para elaborar un dia-
grama de control por variables son los siguientes:
Determinar el indicador de calidad que mejor describa la situación de calidad a controlar.
Tomar valores del indicador de muestras a intervalos regulares de tiempo (unos 25 valores).

85
 Decidir el tipo de gráfico de control por variable que deba utilizarse.
Calcular los parámetros estadísticos necesarios (tamaño de la muestra, media, recorrido y
límites de control).

Representar el gráfico con una herramienta software adecuada.

Analizar el gráfico y actuar en sobre el proceso en función del resultado obtenido.
En función de cómo estén agrupados los datos de las muestras, se pueden crear distintos tipos
de grafos de control por variables. Estos tipos son los siguientes:

X-Barra o de Medias: permite estudiar cómo varían las medias de las muestras estudiadas.
R o Recorrido: permite estudiar cómo varían los rangos de los valores muestrales estudia-
dos. Se utiliza cuando el tamaño de las muestras es inferior a 10.
S o de desviación típica (σ): permite estudiar cómo varían las desviaciones típicas de los
valores muestrales estudiados. Se utiliza cuando el número de muestras es superior a 10.
X-Barra / R o de Medias-Recorridos: son la representación conjunta de un gráfico X-Barra
con uno R. Si se presentan gráficos paralelos, entonces la distribución sería sesgada. Es
interesante siempre comparar la media de los rangos con la variación permitida.

Ejemplo Gráficos de Control “X, R”. Una empresa productora de ladrillos de construcción
recibió fuertes quejas de su mayor cliente por la inconstancia de la calidad de su producto. Una
de las características principales del ladrillo de construcción es el porcentaje de absorción de
agua. Se decidió controlar el proceso en base a esta característica, utilizando gráficos de control
por variables X, R. Durante una semana se recogieron, en cada uno de los 5 días laborables, una
muestra de cinco ladrillos cada dos horas (4 muestras por jornada de trabajo). Los resultados se
muestran en la tabla de la Figura 18.

Figura 18: Tabla con los resultados de las muestras.

El cálculo de los límites de control se muestra en la Figura 19.

Las constantes A2 , D4 , D3 están tabuladas según el número de muestras usadas para delimi-
tar estadísticamente el valor límite correcto en cada caso. Si hacemos la representación en cada
caso obtenemos los gráficos mostrados en la Figura 20.
Contrariamente a los resultados esperados, todas las muestras estaban dentro de sus límites
de control. La alta variabilidad del porcentaje de absorción de agua no era esporádica y debida
a causas especiales y puntuales, sino que era constante e inherente al propio proceso de pro-
ducción. La primera consecuencia del estudio fue la instalación de un medidor de caudal para
controlar mejor la cantidad de agua añadida.

86
 Figura 19: Límites de Control.

Figura 20: Gráfico de Control X, R.

11.1.5.2. Gráficos de Control por Atributos El contexto estadístico en el que se desarrollan

está regido por los mismos principios que los gráficos de control por variables, por lo que para
elaborar un diagrama de Control por Atributos se sigue un procedimiento similar al descrito
para los gráficos de control por variables.
Es posible hacer la siguiente clasificación atendiendo a qué se quiere estudiar:
Número de productos defectuosos: se pretende evaluar si el proceso está o no bajo control
atendiendo al número de productos defectuosos que genera. Se subdivide en los siguientes
diagramas:

• Tipo p o de Proporción de Unidades No Conformes: permite representar la propor-

ción de unidades no conformes de cada muestra respecto del tiempo.
• Tipo np o de Número de Unidades No Conformes: representa el número de unidades
no conformes de la muestra respecto del tiempo.

Número de defectos del producto: se pretende determinar si el proceso está bajo control,
estudiando el número de defectos que tiene cada producto. En función de la profundidad
del estudio se encuentran los siguientes diagramas:

87
 • Tipo C o de número de no conformidades: representa el número de defectos de todas
las unidades producidas con respecto del tiempo.
• Tipo U o número medio de no conformidades: se realiza calculando la media del
número de unidades no conformes.

Ejemplo Reducción de los rechazos en la inspección final. En una fábrica de montaje de equipos
de medición se presentaban numerosos rechazos en la estación final de inspección. Con el fin
de reducir el porcentaje de rechazos y los costes asociados se desarrolló un plan de mejora en
dos etapas: conseguir primero que el proceso trabajara “bajo control”, eliminando una a una
las causas especiales de variación, y estudiar luego posibilidades de mejora del proceso mismo.
Para realizar la primera parte del plan se decidió utilizar los Gráficos de Control de Número de
Unidades no Conformes “np”. Como “unidad no conforme” se definió a aquel equipo rechazado
en la inspección final.
Para construir el gráfico de control se tomó una muestra diaria de 50 equipos de medición,
procurando que fueran equipos pertenecientes al mismo lote, durante 20 días consecutivos. Los
resultados obtenidos fueron los que se muestran en el Cuadro 7.

Muestra Número de equipos no Fracción de equipos no

conformes (np) conformes (p)
1 7 14
2 6 12
3 12 24
4 5 10
5 8 16
6 4 8
7 9 18
8 6 12
9 6 12
10 10 20
11 11 22
12 7 14
13 8 16
14 5 10
15 9 18
16 4 8
17 12 24
18 6 12
19 9 18
20 8 16
Total: 152 304
Cuadro 7: Resultados de la medición.

El cálculo del valor de la media es:

n p = 152/20 = 7, 6
Los límites se calculan como:

√
LCS = n p + 3 ∗ n p = 7, 6 + 3 ∗ 2, 75 = 15, 87

88
 √
LCI = n p − 3 ∗ n p = 7, 6 − 3 ∗ 2, 75 = −0, 67

Y por lo tanto puesto que todas las muestras están dentro de los límites de control, el proceso
se encuentra bajo control estadístico. La alta fracción de equipos no conformes no es entonces
debida a causas externas y asignables, sino a causas internas del proceso. La única alternativa
posible es actuar sobre el propio diseño del proceso. Podemos apreciar en la Figura 19 el Gráfico
de Control resultante.

Figura 21: Gráfico de Control del ejemplo.

11.2. Pruebas de software: JUnit

JUnit es un marco (framework) para la realización de pruebas automáticas (tanto unitarias,
como de integración) en los proyectos con lenguaje Java. De forma resumida una prueba unitaria
se consigue con cinco pasos:

1. Crear un objeto y elegir el método a probar.

2. Seleccionar los valores de entrada para el método.
3. Calcular los valores esperados que deben ser devueltos en el método.

4. Ejecutar el método para el objeto creado y las entradas elegidas.

5. Verificar el resultado de la ejecución del método.
El marco JUnit proporciona la clase TestCase para definir cada prueba unitaria. Los programa-
dores deben extender esta clase para escribir casos de pruebas individuales. Una única subclase
TestCase puede contener cualquier número de pruebas sobre cualquier número de métodos dife-
rentes de una clase.
La clase TestCase extiende una clase llamada Assert que permite la realización de estas opera-
ciones para crear y comprobar los resultados de las pruebas. Esta clase dispone de los métodos:
AssertTrue(Expression): esta aserción comprueba que Experssion evalúa a cierto.
AssertEquals(Esperado, Real): esta aserción comprueba que Esperado sea igual a Real.

AssertSame(Obj_Esperado, Obj_Real): esta aserción comprueba que Obj_Esperado sea el

mismo objeto que Obj_Real.
AssertNull(Objeto): esta aserción comprueba que Objeto sea igual a Null.
Cada método de Assert dispone de un parámetro opcional que es una cadena que será la mostra-
da en caso de fallo. Si no se usa este parámetro opcional, entonces el entorno incluye una cadena
por defecto para cada tipo de Assert.
Supongamos que queremos realizar las pruebas de la siguiente clase:

89
1 public class Calculadora {
2 public double Suma(double num1, double num2) {
3 return num1+num2;
4 }
5 }

Lo primero será incluir la clase TestCase y la clase que estamos probando. A continuación
creamos la nueva clase que extiende la clase TestCase, que llamaremos TestCalculadora:
1 import junit.framework.TestCase;
2
3 public class TestCalculadora extends TestCase {
4 public void testSuma() {
5 Calculadora calc = new Calculadora();
6 double resultado = calc.Suma(123,321);
7 assertEquals(resultado, 444);
8 }
9 }

11.2.1. Anotaciones
Las anotaciones son un mecanismo alternativo a la realización de aserciones de forma que
se pueden crear y ejecutar pruebas de una forma más legible. Consiste en palabras reservadas
que comienzan por el símbolo @ y que indican a la API de JUnit determinadas instrucciones
concretas. Las anotaciones más comunes son:
@Test public void method(): identifica a un método de prueba.
@Before public void method(): indica que el siguiente método se debe ejecutar antes de
cada test.
@After public void method(): indica que el método se debe ejecutar después de cada test.
@Ignore: marca que el método de prueba se debe ignorar. Útil cuando se han realizado
actualizaciones sobre el código pero no sobre los casos de prueba.
@Test (expected = Exception class): prueba de excepción. Falla si el método no genera la
excepción esperada.
@Test (timeout = TIMEOUT): prueba de duración. Falla si se tarda más de TIMEOUT ms.
Por ejemplo, si tenemos el siguiente caso de prueba básico:
1 import junit.framework.TestCase;
2
3 public class PruebaUnitaria extends TestCase {
4 String MICADENA;
5
6 public void setUp() {
7 MICADENA = "inicial";
8 }
9
10 public void testValue() {
11 this.Assert.assertEquals("inicial", MICADENA);
12 MICADENA += " 1";
13 this.Assert.assertEquals("inicial 1", MICADENA);
14 }
15
16 public void tearDown() {
17 value = "";
18 }
19 }

Quedaría de la siguiente manera utilizando anotaciones:

1 import org.junit.*;
2 import junit.framework.JUnit4TestAdapter;
3
4 public class PruebaUnitaria {

90
 5 String MICADENA;
6
7 @Before
8 public void setUp() {
9 MICADENA = "inicial";
10 }
11
12 @Test
13 public void testValue() {
14 Assert.assertEquals("inicial", MICADENA);
15 MICADENA += " 1";
16 Assert.assertEquals("inicial 1", MICADENA);
17 }
18
19 @After
20 public void tearDown() {
21 value = "";
22 }
23
24 public static junit.framework.Test suite() {
25 return new JUnit4TestAdapter(PruebaUnitaria.class);
26 }
27 }

Ejemplo con anotaciones Realizar los casos de prueba que considere adecuados para la si-
guiente clase:
1 public class Rectangulo {
2 private int altura;
3 private int anchura;
4
5 Rectangulo() {
6 altura = 0;
7 anchura = 0;
8 }
9
10 Rectangulo(int h, int w) {
11 altura = h;
12 anchura = w;
13 }
14
15 public int getH() {
16 return altura;
17 }
18 public int getW() {
19 return anchura;
20 }
21 public int getA() {
22 return altura*anchura;
23 }
24
25 public String toString() {
26 return "Rectángulo: altura=" + altura + ", anchura =" + anchura + ", área=" +
getA() + ".";
27 }
28 }

Solución:
1 import static org.junit.Assert.*;
2 import org.junit.*;
3
4 public class Prueba_Rectangulo {
5 Rectangulo r;
6 Rectangulo r[] RLista = new Rectangulo[5];
7
8 @Before
9 public void testSetup() {
10 System.out.println("Inicio de pruebas.");
11 }
12
13 @After

91
14 public void testComplete() {
15 System.out.println("Final de pruebas.");
16 }
17
18 @Test
19 public void Caso1() {
20 r = new Rectangulo();
21 try {
22 assertTrue("Caso 1: Valores por defecto", r.getH() == 0 && r.getW() == 0);
23 System.out.println("Caso 1 - OK.");
24 } catch (AssertionError e) {
25 System.err.println(e.getMessage());
26 }
27 }
28
29 @Test
30 public void Caso2() {
31 r = new Rectangulo();
32 try {
33 r = new Rectangulo(8,9);
34 assertTrue("Caso 2: Constructor con valores", r.getH() == 8 && r.getW() == 9
&& r.getA() == 72);
35 System.out.println("Caso 2 - OK.");
36 } catch (AssertionError e) {
37 System.err.prinln(e.getMessage());
38 }
39 }
40
41 @Test
42 public void Caso3() {
43 r = new Rectangulo();
44 try {
45 for(int i=0; i<5; i++) {
46 RLista[i] = new Rectangulo(2*i,3*i);
47 RLista[i].setH(10*i);
48 RLista[i].setW(5*i);
49 assertTrue("Caso 3: Modificación de valores", RLista[i].getH() == 10*i &&
RLista[i].getW() == 5*i && RLista[i].getA() == 50*i*i);
50 }
51 System.out.println("Caso 3 - OK.");
52 } catch (AssertionError e) {
53 System.err.println(e.getMessage());
54 }
55 }
56 }

Ejemplo aplicado En este ejemplo se trata la prueba de un ejemplo simple de método que
realiza facturas de productos vendidos.
1 public class TestFactura extends junit.framework.TestCase {
2
3 public void main (String[] args) {
4 junit.textui.TestRunner.run(TestFactura.class);
5 }
6
7 // Constructor obligatorio, no existe por defecto para la clase TestCase
8 public TestFactura(String name) {
9 super(name);
10 }
11
12 public void testSumaArticulos() {
13 Factura miFactura = new Factura();
14 miFactura.add(new Articulo("articulo 1", 3, 1500.0));
15 miFactura.add(new Articulo("articulo 2", 1, 5000.0));
16
17 assertNotNull("La factura no puede ser nula", miFactura);
18 assertEquals("El total de la factura está mal calculado", 3*1500+5000, 0.0001,
miFactura.getTotal());
19 assertEquals("El número de artículos está mal calculado", 4, miFactura.
countArticles());
20 }
21

92
22 public void testValidacionFactura() {
23 Factura miFactura = new Factura();
24 miFactura.add(new Article("Artículo 1", 3, 1500.0));
25 miFactura.add(new Article("Artículo 2", 1, 5000.0));
26 miFactura.validar();
27
28 assertTrue("La validación de la factura no se ha realizado", miFactura.EsValida
());
29 try {
30 miFactura.add(new Articulo("Artículo 3", 1, 2000.0));
31 fail("Cambiada la factura después de validación");
32 } catch (FacturaException e) {
33 // Aquí se llega en caso de que no haya fallos, puesto que no se puede
cambiar
34 // la factura una vez validada.
35 }
36 }
37 }

93