• Author / Uploaded
• andres_ts

Citation preview

Calidad del Software Curso 2014/15

Resumen de la asignatura para apuntrix.com

Índice I

1

Introducción a la Calidad

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

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

1 1 2 2 3 3

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

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

6 6 6 6 6 6 7 9 9 10 11 12

3. Calidad de los Sistemas Informáticos 3.1. Concepto de Calidad del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Aseguramiento de la Calidad del Software . . . . . . . . . . . . . . . . . . . 3.1.2. Gestión de la Calidad del Software . . . . . . . . . . . . . . . . . . . . . . . 3.2. Situación de la calidad de SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Importancia de la calidad en los SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Componentes de la calidad de un SI . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 3.5.2. Modelos de Gestión de Conocimiento en Ingeniería del Software . . . . . . 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) . . . . . . . . . . . . . . . . . 3.6.2. Factoría de Experiencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3. Base o Repositorio de Experiencia . . . . . . . . . . . . . . . . . . . . . . . . 3.7. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 16 16 16 17 17 17 18 18 19 20 20 20 21 21

4. Aplicación práctica (apuntes E.D.) 4.1. El departamento de calidad en las organizaciones . . . . . . . . . . . . 4.1.1. Entornos pequeños: quality circles . . . . . . . . . . . . . . . . . 4.1.2. El departamento de calidad . . . . . . . . . . . . . . . . . . . . . 4.2. Contenido práctico: guía de implantación de la norma ISO 9001:2008 . 4.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Apartados de la norma . . . . . . . . . . . . . . . . . . . . . . . 4.3. Contenido práctico: guía de implantación del manual de calidad . . . 4.3.1. Guía del Plan de Calidad . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Guía del Manual de Calidad . . . . . . . . . . . . . . . . . . . .

23 23 23 24 25 25 26 26 26 27

II

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Calidad de Productos

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

31

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

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

31 31 31 31 32 32 35 35 35 37 37

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 . . . . . . 6.1.2. Métricas del software . . . . . . . . . . . . . 6.2. Métricas del Software . . . . . . . . . . . . . . . . . . 6.2.1. Métricas internas . . . . . . . . . . . . . . . . 6.2.2. Métricas externas . . . . . . . . . . . . . . . . 6.2.3. Métricas de uso . . . . . . . . . . . . . . . . . 6.3. Modelos de Calidad . . . . . . . . . . . . . . . . . . 6.3.1. Conceptos básicos sobre modelos . . . . . . 6.4. Medición práctica . . . . . . . . . . . . . . . . . . . . 6.4.1. Medición personal y medición institucional 6.4.2. Guía de medición . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

41 41 41 41 42 42 52 54 54 54 55 55 56

III

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

57

Calidad del Proyecto

7. La gestión de la calidad de los proyectos 7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Gestión de la calidad de los proyectos según PMBOK . . . . . . . . . . . . . 7.2.1. Planificar la Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2. Realizar el Aseguramiento de la Calidad . . . . . . . . . . . . . . . . 7.2.3. Realizar el Control de la Calidad . . . . . . . . . . . . . . . . . . . . . 7.3. Estándares IEEE 730-2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2. Documentos de Referencia . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3. Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.5. Estándares, prácticas, convenciones y métricas . . . . . . . . . . . . . 7.3.6. Revisiones Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.8. Informe de Problemas y Acciones Correctivas . . . . . . . . . . . . . 7.3.9. Herramientas, Técnicas y Metodologías . . . . . . . . . . . . . . . . . 7.3.10. Control de Medios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.11. Control del Proveedor . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.12. Recopilación, Mantenimiento y Conservación de Registros . . . . . . 7.3.13. Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.14. Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.15. Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.16. Historia y Procedimientos de Cambio del Plan de Aseguramiento Calidad del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . la . . . .

57 57 57 57 59 60 61 62 62 62 62 62 62 63 63 63 63 63 63 63 63 63 63 64

8. Calidad del software (apuntes E.D.) 8.1. Conceptos generales del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1. Concepto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2. Clasificación de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. Aspectos de un proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.4. Organización de la gestión de un proyecto . . . . . . . . . . . . . . . . 8.1.5. Etapas de un proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Conceptos generales de un proyecto software . . . . . . . . . . . . . . . . . . . 8.2.1. Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2. Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Gestión de la calidad de los proyectos según PMBOK . . . . . . . . . . . . . . 8.4. Estándar IEEE 730-2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1. Comparativa del plan de SQAP (IEEE STD 730-2002) con la ISO 9001

IV

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

71

Calidad de Procesos

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

65 65 65 65 65 66 66 67 67 67 68 68 68

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

71 71 71 71 71 72 73 73 73 74

10. Evaluación y mejora de procesos (apuntes E.D.) 10.1. Introducción . . . . . . . . . . . . . . . . . . . 10.2. Norma ISO 90003 . . . . . . . . . . . . . . . . 10.3. Modelo Six-Sigma . . . . . . . . . . . . . . . . 10.3.1. Six-Sigma para software . . . . . . . . 10.3.2. Metodología DMAIC . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

76 76 76 77 77 78

V

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

81

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 . . . . . . . . . . . . 11.1.2. Diagrama de causa-efecto: Ishikawa . . 11.1.3. Diagrama de Pareto . . . . . . . . . . . 11.1.4. Hojas de comprobación . . . . . . . . . 11.1.5. Diagrama de control . . . . . . . . . . . 11.2. Pruebas de software: JUnit . . . . . . . . . . . . 11.2.1. Anotaciones . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

81 81 81 81 83 84 85 89 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 internacionales, la calidad se define como “el grado en el que un conjunto de características inherentes 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 necesidades 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 disponible) 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.

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.

Fabricante

Proporciona medidas precisas. Desagrega de los cambios constantes de los usuarios y se centra en la producción.

Difícilmente se aplica a los servicios. Las especificaciones pueden convertirse en obsoletas ante el cambio constante.

Producto

Orientado al mercado. Reconocible universalmente.

Difícil de cuantificar por la mayor parte de los usuarios.

Incorpora múltiples atributos. Centra la atención en la eficacia interna y la efectividad externa. Permite la comparación entre distintos productos.

Dificulta la extracción de los componentes individuales. Calidad y valor son diferentes en determinados casos.

Valor

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 organizació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 considera 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 producto 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 informació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 Calidad. 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 procedimientos 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 conveniente, 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, proyecto 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. 2.1.

Modelos y normas de calidad 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 elaborados 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 medioambiental. Esta norma proporciona directrices básicas para la realización de una auditorí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 organizació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 interrelacionados 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 beneficiosa 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 satisfagan 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 operació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 eficaz 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 observaciones 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 competitivo, 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 requisitos de calidad

Criterios incluidos en el modelo

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 referencia. 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 aprendizaje 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 sobresalientes 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 nuevos 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 variació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 diferentes 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 automá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 particulares. 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 cliente

el tipo de cliente al que le pueden resultar atractivos los productos 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 personal

se cuenta con un sistema de revisión y determinación de las 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 en procesos

procesos identificados y repetidos 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 sistema hacia la gestión

existe una política de calidad existen mecanismos de difusión de la política de calidad 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 en hechos para la toma de decisión

la planificación y la estrategia está basada en hechos y datos los objetivos están basados en hechos y datos 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 mutuamente beneficiosa con el proveedor

se cuenta con políticas de desarrollo de proveedores se tienen procesos sistemáticos para la selección y evaluación de proveedores 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 madurez

Nivel de desempeño

Comentario

1

Principiante

No hay una aproximación sistemática que sea evidente. Los resultados son pobres o impredecibles.

2

Proactivo

Aproximación sistemática basada en problema o la prevención. Se disponen de los mínimos datos sobre la mejora.

3

Flexible

Aproximación sistemática basada en el proceso. Se usa una etapa temprana de aplicación de las mejoras sistemáticas. Hay objetivos y procesos de mejora.

4

Progresivo

5

Exitoso

Se usa el proceso de mejora continua y se detecta la mejora de resultados y la tendencia de la mejora. El proceso de mejora está integrado en la organización y 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 Software” 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 sistemá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 determina 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 seguimiento. 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 considerarse 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 cantidades 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 disponible 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 conocimiento 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 fuentes 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 herramientas para la gestión del conocimiento:

Diferentes técnicas y

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, tecnologías e innovación. Para garantizar el éxito de un programa de gestión del conocimiento es obligatorio elegir el modelo de gestión del conocimiento adecuado. Estrategia empresarial

Modelo de gestión

Organización

Conceptos

Tipo de conocimiento

Reducción de costes

Productividad

Compartir, evitando redundancia

Base de información

Explícito

Especialización

Calidad

Mejores prácticas

Procesos comunes

Explícito

Innovación

Creatividad

Integración y combinación de conocimiento

Conocimiento dinámico

Tácito

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 colaboració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 oportunidades 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 producto de tres factores; motivación para descubrir conocimiento, una cultura de apoyo y la experiencia 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 aproximació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 competencias 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 experiencia 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 proyecto 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, configuraciones 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, pizarras, 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 software 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 muchos 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. 4.1.

Aplicación práctica (apuntes E.D.) 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 administració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 descubren. 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 participantes 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 departamental. 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, incluyendo 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 trabajo, 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 actividades 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 producto 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 “rendimientos 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 establecen 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 rios para:

La organización debe determinar y proporcionar los recursos necesa-

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 aplicable): 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 caracterí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 procedimiento 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 vuelvan 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 diferentes 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 calidad 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, especialmente 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 evaluació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 familia 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 software. 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 calidad 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 software. 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, operabilidad, 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 satisfacen 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 correctos con el nivel de precisión requerido. Adecuación funcional. Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados. Fiabilidad Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo las condiciones y el periodo de tiempo especificados. Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones 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 previsto en presencia de fallos hardware o software. Capacidad de recuperación. Capacidad del producto software para recuperar los datos 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 determinadas 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 determinadas en relación con un banco de pruebas establecido. Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el software 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 usuarios 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 modificaciones 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 información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware 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 intercambiar 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 modificado 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 eficiente de un entorno hardware, software, operacional o de utilización a otro. Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y eficiente a diferentes entornos determinados de hardware, software, operacionales 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 lugar 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 determinados 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 coherentes. 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 autorizados. Portabilidad. Capacidad de los datos de poder ser instalados, reemplazados o trasladados 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 identificació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 correspondientes salidas (plan de evaluación, medidas, criterios de decisión, resultados e informe de evaluació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, seleccionar 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 requisitos, 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 caracterí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 evaluació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 producto

Mantenibilidad Flexibilidad Testeabilidad

Transición del producto

Portabilidad Reusabilidad Interoperabilidad

Operación del producto

Correctitud 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 al producto

Funcionalidad 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, mantenibilidad, 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 Compatibilidad Eficiencia del desempeño Fiabilidad Funcionalidad Portabilidad Seguridad

Capacidad Desempeño Documentación Fiabilidad Funcionalidad Instalabilidad Mantenibilidad Servicio Usabilidad

Desempeño Fiabilidad Funcionalidad Usabilidad Servicio

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, documentación y configurabilidad de la herramienta. Especificar la evaluación Los requisitos anteriores deben evaluarse en características concretas 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: funcionalidad 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 como 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 usabilidad, 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 evaluació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 continuación diferentes formas de medir las características propuestas. Siguiendo el estándar 25040 es necesario determinar los cuatro pasos: análisis, especificació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 determinar 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 considerar 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 mediante 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 debemos 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 entidades 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 caracterizar 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 empí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 valores 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 elementos 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 representació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 conseguir 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 universal, 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 estos 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 considerar 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 programa 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 : numero de operadore unicos ´ ´ µ2 : numero de operandos unicos ´ N1 : numero de ocurrencias de los operadores ´ N2 : numero 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órmula: E( P) =

N1 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: T ( P) =

E( 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 2 3 4 5 6 7 8 9 10 11 12 13

void ordenar(int vector, int tamano) { int i, j, t; if(tamano