CAPITULO 6

Métricas y Estándares de Calidad

Ingenieria de Software III

Facultad Politecnica

Métricas del producto para el SW Introducción
La medición es un elemento clave en cualquier proceso de ingeniería  Las medidas se emplean para:

comprender mejor los atributos de los modelos que se crean, y evaluar la calidad de los productos de la ingeniería o de los sistemas que se construyen

Ingenieria de Software III

Facultad Politecnica

Calidad General

Calidad del software es el cumplimiento de:

los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo explícitamente documentados, y de las características implícitas que se esperan de todo software desarrollado profesionalmente

Ingenieria de Software III

Facultad Politecnica

Calidad General (Cont.)

3 Puntos Importantes:
Los requisitos del SW son la base de las medidas de calidad.  La falta de concordancia con estos requisitos es una falta de calidad  Los estándares especificados definen un conjunto de criterios de desarrollo que guían la ingeniería del sw  Si no se siguen los criterios, el resultado será, casi seguramente, la falta de calidad  A menudo se pasa por alto un conjunto de requisitos implícitos (por ejemplo, el deseo de alcanzar la facilidad de uso)  Si el sw cumple con los requisitos explícitos pero no con los implícitos, la calidad del sw estará en duda

Ingenieria de Software III

Facultad Politecnica

 su capacidad para adaptarse a nuevos entornos. Estos factores se concentran en tres aspectos: sus características operativas.  Ingenieria de Software III Facultad Politecnica Factores de Calidad de McCall Facilidad de mantenimiento (¿Puedo arreglarlo?) Flexibilidad (¿Puedo modificarlo?) Facilidad de prueba (¿Puedo probarlo?) Portabilidad (¿Podré utilizarlo en otra maquina?) Facilidad de reutilización (¿Podré reutilizar parte del SW?) Interoperabilidad (¿Podré comunicarlo con otros Sist.?) Revisión del producto Transición del producto Operación del producto Corrección Facilidad de uso Eficiencia confiabilidad Integridad Ingenieria de Software III Facultad Politecnica .Factores de Calidad de McCall McCall. Richards y Walters [MCC77] propusieron una clasificación útil de los factores que afectan la calidad del SW.  su capacidad para experimentar cambios.

Factores de Calidad de McCall  Corrección: (¿Hace lo que se le pide?) El grado en que el programa cumple con su especificación y satisface los objetivos que propuso el cliente  Confiabilidad: (¿Lo hace de forma fiable todo el tiempo?) El grado en que se esperaría que un programa desempeñe su función con la precisión requerida  Eficiencia: (¿Qué recursos hardware y software necesito?) La cantidad de código y de recursos de cómputo necesarios para que un programa realice su función Ingenieria de Software III Facultad Politecnica Factores de Calidad de McCall (Cont.)  Integridad: (¿Puedo controlar su uso?) El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado  Facilidad de uso: (¿Es fácil y cómodo de manejar?) El esfuerzo necesario para aprender. operar y preparar los datos de entrada de un programa e interpretar la salida  Facilidad de mantenimiento: El esfuerzo necesario para localizar y corregir un error en un programa  Flexibilidad: El esfuerzo necesario para modificar un programa en operación Facultad Politecnica Ingenieria de Software III .

tolerancia a fallas y facilidad de recuperación Facultad Politecnica Ingenieria de Software III . interoperabilidad.Factores de Calidad de McCall (Cont. exactitud. cumplimiento y seguridad  Confiabilidad: La cantidad de tiempo en que el sw está disponible para usarlo según los siguientes subatributos: madurez.)  Facilidad de prueba: El esfuerzo que demanda probar un programa con el fin de asegurar que realiza su función  Portabilidad: El esfuerzo necesario para transferir el programa de un entorno de hardware o software a otro  Facilidad de reutilización: El grado en que un programa (o partes de él) puede reutilizarse entre otras aplicaciones  Interoperabilidad: El esfuerzo necesario para acoplar un sistema con otro Ingenieria de Software III Facultad Politecnica Factores de Calidad del Estándar ISO 9126   Se desarrolló como un intento por identificar los atributos de calidad para el software Identifica seis atributos claves de calidad:  Funcionalidad: El grado en que el sw satisface las necesidades que indican los siguientes subatributos: idoneidad.

facilidad para reemplazarse Ingenieria de Software III Facultad Politecnica . comportamiento de los recursos Ingenieria de Software III Facultad Politecnica Factores de Calidad del Estándar ISO 9126 (Cont.Factores de Calidad del Estándar ISO 9126 (Cont. facilidad de aprendizaje y operabilidad  Eficiencia: El grado en que el sw emplea en forma óptima los recursos del sistema. cumplimiento.)  Facilidad de mantenimiento: La facilidad con que se repara el sw de acuerdo con los siguientes subatributos: facilidad de análisis. estabilidad y facilidad de prueba  Portabilidad: La facilidad con que se lleva el sw de un entorno a otro según los siguientes subatributos: adaptabilidad. facilidad para instalarse. facilidad de cambio.)  Facilidad de uso: La facilidad con que se usa el sw de acuerdo con los siguientes subatributos: facilidad de comprensión. como lo indican los siguientes subatributos: comportamiento en el tiempo.

Gestión de la Calidad El aseguramiento de la calidad de software (Software Quality Assurance SQA) y la Verificación & Validación (V&V) son los principales procesos de esta área de conocimiento Ingenieria de Software III Facultad Politecnica SQA: Aseguramiento de Calidad del software  Componentes:  monitorear el cumplimiento de las actividades definidas en el plan de SQA asociado a cada proyecto de desarrollo. garantizar la calidad de los productos de trabajo y monitorear los procesos utilizados para producir software. Facultad Politecnica   Ingenieria de Software III .

Trata de responder preguntas del tipo:   ¿se satisfacen los criterios de calidad especificados? ¿se ha desarrollado en base a los estándares establecidos? Facultad Politecnica Ingenieria de Software III .   Asiste al grupo de desarrollo para lograr un producto final de buena calidad.SQA  Verificación: ¿Estamos construyendo el producto correctamente?  Validación: ¿estamos construyendo el producto correcto? Ingenieria de Software III Facultad Politecnica El Grupo SQA  Sirve como el representante del cliente  mira el producto desde el punto de vista del cliente.

Sección Estándares. pasos para la revisión. estándares. etc.) Facultad Politecnica Ingenieria de Software III . procedimientos de reporte de errores. Facultad Politecnica Ingenieria de Software III Detalle de las actividades de SQA  Plan de SQA : mapa para institucionalizar la garantía de calidad del software.     El plan incluye: Sección Gestión: Tareas y actividades de SQA dentro del proceso de software y los roles y responsabilidades relativas a la calidad del producto. El plan es revisado por todas las partes interesadas. (Ejemplos: estándares de documentación. Es una plantilla para definir las actividades de SQA aplicables a cada proyecto de software. etc. Sección Documentación: Detalle de los productos de trabajo del proceso de software que podrán ser revisados. auditorías. métricas a obtener. estándares de codificación.    El plan se prepara durante la etapa de planeación del proyecto.Plan de SQA  Preparar el plan de SQA:  evaluaciones. documentos. El plan es la base de todas las actividades de SQA. Prácticas y Convenciones: Detalle de lo que está acordado y establecido para el proceso y los productos a obtener.

verificar que el software satisface los requisitos. (Ejemplos: Revisiones de documentación.) Sección de Pruebas: Plan y procedimiento de Pruebas del Software y de gestionar los defectos detectados. lógica o implementación).  hacer más manejable los proyectos.Detalle de las actividades de SQA    Sección Revisiones y Auditorias: Revisiones que se llevarán a cabo durante el proceso y los responsables de cada una de ellas. asegurar que se cumplen los estándares predefinidos. Propósito:    descubrir errores (función. Facultad Politecnica Ingenieria de Software III .etc. revisiones técnico formales (RTF’s). Sección Métodos y Herramientas que soportan las actividades de SQA Ingenieria de Software III Facultad Politecnica Revisiones Técnicas Formales   Las revisiones técnicas constituyen una de las actividades más importantes de SQA.

 Beneficios de SQA: asociados a la disminución de rework (menos defectos y mayor confiabilidad). Ingenieria de Software III Facultad Politecnica Ejemplos de Categorías de Errores            IES Especificación errónea o incompleta MCC Mala interpretación de comunicación con el cliente IDS Desviación intencional de la especificación VPS Violación del estándar de programación EDR Error de representación de los datos IMI Interfaz de módulo inconsistente EDL Error en el diseño lógico IET Testeo erróneo o incompleto IID Documentación errónea o incompleta PLT Error en lenguaje HCI Interfaz ambigua o incompleta Ingenieria de Software III Facultad Politecnica .Análisis costo/beneficio de SQA  Costos de SQA: prevención y evaluación.

Checklist El checklist debe completarse al finalizar cada etapa del ciclo de vida del software: Nota:  (1) Sí  La actividad o tarea fue realizada en su totalidad.Identificación del proyecto y producto Proyecto: Producto: 2.Checklist SI NO N/A Fono: • • • Rol Moderador  Secretario  Observador  Inspector • Adherencia ¿ El documento se adhiere a los estándares establecidos? • Claridad ¿ En el modelo conceptual no existen características o conceptos irrelevantes? ¿Se muestra el ciclo de vida de un objeto a través del diagrama de secuencia? ¿ La especificación es clara y fácil de comprender? ¿ Se refleja el comportamiento del sistema en la especificación? Ingenieria de Software III Facultad Politecnica ..  (3) N/A La actividad no se aplica al desarrollo del proyecto de software..  La información contenida en el checklist debe servir como base para informar sobre el estado de avance de las actividades de SQA en el proyecto. Ingenieria de Software III Facultad Politecnica Checklist: Especificación de Requerimientos 1.Inspector Nombre: E-mail: 3.  (2) No  La actividad o tarea no fue completada..

.Identificación del proyecto y producto Proyecto: Producto: 2..Checklist: Especificación de Requerimientos 1. técnicas...Inspector Nombre: E-mail: 3..Identificación del proyecto y producto Proyecto: Producto: 2..Checklist SI • NO N/A Fono: • • • Rol Moderador  Secretario  Observador  Inspector Completitud ¿ Están especificados todos los requerimientos y restricciones? ¿ Están priorizados los requerimientos y restricciones? ¿ Están definidos correc-tamente los criterios de prioridad? ¿ Están todos los conceptos necesarios para que el sistema opere correctamente? ¿ Los requerimientos ayudan a cumplir con el propósito del sistema? ¿ Se especifican todas las funciones que se necesitan para cumplir con los objetivos del sistema? ¿ Las instancias creadas en los contratos (poscondiciones) provienen del modelo conceptual y están expresadas en tiempo pasado? ¿ Existe un contrato por cada operación del sistema que aparece en el diagrama de secuencia? Ingenieria de Software III ¿ Están especificados los requerimientos de interfaz? Facultad Politecnica Checklist: Especificación de Requerimientos 1. recursos humanos y no humanos y calendarización previamente fijada? • Correctitud ¿ El diagrama de secuencia muestra todo el comportamiento del sistema con los actores externos y con otros sistemas? ¿ Los requerimientos reflejan las necesidades del cliente? Ingenieria de Software III Facultad Politecnica .Checklist SI NO N/A Fono: • • • Rol Moderador  Secretario  Observador  Inspector • Factibilidad ¿ Es posible llevar a cabo los requerimientos con las herramientas.Inspector Nombre: E-mail: 3.

Este grupo tiene una serie de actividades que se presentan a continuación.Identificación del proyecto y producto Proyecto: Producto: 2.Inspector Nombre: E-mail: 3..• Checklist: Diseño interfaz hombre-máquina 1.. Facultad Politecnica Ingenieria de Software III .. 3) tareas que el usuario debe desempeñar? • Consistencia Grupo SQA     Muchas organizaciones empiezan a crear grupos de SQA. Estas personas actúan como representantes interno del cliente.. 2) información sobre tutoriales y manuales de usuario. a lograr una alta calidad en el programa o aplicación de software determinado. Es responsabilidad del grupo SQA ayudar a los Ing.Checklist Fono: • Rol  Moderador  Secretario  Observador  Inspector SI NO N/A • Adherencia ¿ Se utilizaron las metodologías y técnicas acordadas para desarrollar el diseño? • Claridad ¿ El diseño representa las interfaces? ¿ Está totalmente documentado el diseño? • Completitud ¿ El diseño cumple con todos los requerimientos relacionados a la interfaz? ¿ Se utilizan mensajes de error? ¿ Se modelaron todas las interfaces? ¿ Existe un modelo de la interfaz considerado para el usuario final: 1) descripción de los conocimientos técnicos Facultad Politecnica Ingenieria de Software III del usuario.

1 Standard Dictionary of Measures to Produce Reliable Software IEEE 1061 Standard for a Software Quality Metrics Methodology ISO/IEC 12119 Information Technology-Software PackagesQuality Requirements and Testing ISO/IEC 14598-1 Information Technology-Evaluation of Software Products-General Guide ISO/IEC 25030 Software engineering .Quality requirements Ingenieria de Software III Facultad Politecnica .1 Guide for Software Assurance Planning IEEE 982.Grupo SQA Preparación de Plan SQA Desarrollo de la descripción del proceso de software Revisión de software Actividades SQA Actividades de verificación Ingenieria de Software III Documentación Reporte de no conformidad Facultad Politecnica Estándares de calidad        IEEE 730 Software Quality Assurance Plans IEEE 730.Software product Quality Requirements and Evaluation (SQuaRE) .

 CMMI [SEI]: Estándar basado en CMM pero con una visión más integral.Estándares de calidad   De la Serie ISO 9000:  ISO/IEC 9000-3 Lineamientos para la aplicación de la Norma ISO 9001 en el desarrollo. suministro y mantenimiento del Software  ISO/IEC 9000-4 Guía para la gestión de un programa de seguridad de funcionamiento  ISO/IEC 10007 Directrices para la gestión de la configuración  ISO/IEC 9126-1 Software Quality Characteristics and Metrics  ISO/IEC 12207 Software Life Cycle Processes  ISO/IEC 14102 Information Technology . Facultad Politecnica Ingenieria de Software III CMM .CMMI Capability Maturity Model Capability Maturity Model Integration Ingenieria de Software III Facultad Politecnica .Guidelines for the evaluation and selection of CASE tools  ISO/IEC 15026 System and Software Integrity Levels  ISO/IEC 15271 Guide to ISO/IEC Software Life Cycle Processes  ISO/IEC 15504 Software Process Assessment  ISO/IEC 15846 Software Configuration Management  ISO/IEC 17799 Seguridad Informática Otras normas internacionales:  CMM [SEI]: Estándar que sirve de guía para la mejora en el proceso de Desarrollo de Software.

Su primer director su Watts Humphrey. CMMI del SEI   http://www.cmu.edu/cmmi/ Facultad Politecnica Ingenieria de Software III Producto del SEI  Modelo de Madurez del Proceso de Software:    desarrollado para evaluar las capacidades de una organización de software.Software Engineering Institute SEI   Financiado por el Departamento de Defensa de Estados Unidos en la Carnegie Mellon University.edu).cmu. desde 1984 (http://www.sei. medido y mejorado.sei. para identificar las áreas más importantes de mejoramiento. Facultad Politecnica Ingenieria de Software III . tratando el proceso completo de desarrollo de software como un proceso que puede ser:  controlado.

Modelo de Madurez  Para mejorar sus capacidades.  Herramienta: framework de madurez. las organizaciones de software deben:      comprender el estado actual de sus procesos de software. Ingenieria de Software III Facultad Politecnica Proceso de Mejora Continuo: CMM y CMMI CMM (Década del ’90): Características • • • • Mide la capacidad del proceso seguido para desarrollar software incrementando la predictibilidad en cuanto a costos. producir un plan para cumplir dichas acciones. No contempla todas las necesidades de la organización. por lo que se fueron agregando otros modelos que daban solución a los problemas detectados. el desarrollo integrado entre el producto y el proceso (IPPD) y la gestión de compras y control de proveedores. CMMI (A partir del 2001): Características Sirve como guía única para la mejora de múltiples disciplinas tales como la Ingeniería de sistemas (SE). comprender los recursos necesarios para ejecutar el plan. Ingenieria de Software III Facultad Politecnica . Ingeniería de software (SWE). Es el modelo más utilizado en la industria de software. Objetivos que se persiguen: • • Determinar el nivel de madurez del Proceso de Desarrollo (Indicador de calidad) Servir de guía en el Proceso de Desarrollo permitiendo la Mejora Continua de la organización. establecer una lista de las acciones de mejoramiento requeridas en orden de prioridad. tiempos y calidad lograda. desarrollar una visión de los procesos deseados.

CMM   Califica el grado de madurez de los métodos y del personal interno de la empresa para desarrollar un sistema El CMM establece cinco niveles progresivos para los procesos relacionados con la construcción de aplicaciones informáticas.Gestionado 5-En Mejora Continua. hasta alcanzar la madurez total:      1-Inicial 2-Repetible 3-Definido 4. Facultad Politecnica Ingenieria de Software III Proceso de Mejora Continuo: CMMI Nivel 5: Optimizado Mejora continua de los procesos Nivel 4: Gestionado de forma cuantitativa Procesos analizados y medidos Nivel 3: Definido Procesos estandarizados Nivel 2: Gestionado Gestión básica de proyectos Nivel 1: Inicial 5 Niveles de Madurez 28 Áreas Claves de Proceso Facultad Politecnica Ingenieria de Software III .

Detalle de los Niveles de Madurez:  NIVEL 1: Inicial (a medida) Basado en las competencias y acciones individuales de las personas  NIVEL 2: Gestionado (Gestión básica de proyectos) • Gestión de Requisitos del producto y del proyecto • • • • • • • Planificación de los proyectos Seguimiento y Control de los proyectos de software Gestión de Subcontratación de producto y servicios Selección y Control de los proveedores Medición y análisis Aseguramiento de la calidad del producto y del proceso Gestión de Configuración del Software Facultad Politecnica Ingenieria de Software III Detalle de los Niveles de Madurez:  Nivel 3: Definido (estandarización de procesos) • Desarrollo de los requisitos del cliente y del producto • Diseño. desarrollo y puesta en práctica de soluciones técnicas • Aseguramiento de la integración del producto • Verificación y Validación • Enfoque hacia la gestión de procesos • Institucionalización del proceso a nivel organización • Educación y entrenamiento para mejorar la eficiencia y eficacia • Gestión integrada de los proyectos • Gestión de riesgos • Análisis sistemático y puesta en práctica de decisiones acordadas • Ambiente organizativo adecuado para el desarrollo integrado del producto y el proceso • Formación de un equipo para el desarrollo integrado • Gestión integrada de proveedores Ingenieria de Software III Facultad Politecnica .

3: 1. 4: ? 5: ? Ingenieria de Software III Facultad Politecnica .Detalle de los Niveles de Madurez:  Nivel 4: Gestionado de forma cuantitativa • • • Evaluación de los procesos de la organización (datos del rendimiento de los procesos) Gestión cuantitativa de los proyectos Gestión cuantitativa de los proveedores  Nivel 5: Optimización (mejora continua de los procesos) • • • Innovación y despliegue a lo largo de toda la organización (mejoras incrementales y su posterior generalización) Gestión de cambios tecnológicos Análisis y resolución de las causas que generan los diferentes problemas y errores Facultad Politecnica Ingenieria de Software III Tiempo para Madurar  Tiempo promedio para alcanzar cada nivel de CMM:     nivel 1 a nivel nivel 2 a nivel nivel 3 a nivel nivel 4 a nivel 2: 2 a 3 años.5 a 2.5 años.