Upload
ya1000c
View
12
Download
0
Embed Size (px)
Citation preview
Ingenieria de Software III Facultad Politecnica
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
Factores de Calidad de McCall
McCall, Richards y Walters [MCC77]
propusieron una clasificación útil de los
factores que afectan la calidad del SW.
Estos factores se concentran en tres
aspectos:
sus características operativas,
su capacidad para experimentar cambios,
su capacidad para adaptarse a nuevos entornos.
Ingenieria de Software III Facultad Politecnica
Factores de Calidad de McCall
Revisión del producto Transición del producto
Operación del producto
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.?)
Corrección Facilidad de uso Eficiencia
confiabilidad Integridad
Ingenieria de Software III Facultad Politecnica
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
Ingenieria de Software III Facultad Politecnica
Factores de Calidad de McCall
(Cont.)
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, exactitud, interoperabilidad, cumplimiento y seguridad
Confiabilidad: La cantidad de tiempo en que el sw está disponible para usarlo según los siguientes subatributos: madurez, tolerancia a fallas y facilidad de recuperación
Ingenieria de Software III Facultad Politecnica
Factores de Calidad del Estándar
ISO 9126 (Cont.)
Facilidad de uso: La facilidad con que se usa el
sw de acuerdo con los siguientes subatributos:
facilidad de comprensión, facilidad de aprendizaje
y operabilidad
Eficiencia: El grado en que el sw emplea en
forma óptima los recursos del sistema, como lo
indican los siguientes subatributos:
comportamiento en el tiempo, comportamiento de
los recursos
Ingenieria de Software III Facultad Politecnica
Factores de Calidad del Estándar
ISO 9126 (Cont.)
Facilidad de mantenimiento: La facilidad con
que se repara el sw de acuerdo con los siguientes
subatributos: facilidad de análisis, facilidad de
cambio, 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, cumplimiento, facilidad para
reemplazarse
Ingenieria de Software III Facultad Politecnica
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.
Ingenieria de Software III Facultad Politecnica
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.
Asiste al grupo de desarrollo para lograr un producto final de buena calidad.
Trata de responder preguntas del tipo: ¿se satisfacen los criterios de calidad
especificados?
¿se ha desarrollado en base a los estándares establecidos?
Ingenieria de Software III Facultad Politecnica
Plan de SQA
Preparar el plan de SQA: evaluaciones, auditorías, estándares,
procedimientos de reporte de errores, documentos, etc.
El plan se prepara durante la etapa de planeación del proyecto.
El plan es revisado por todas las partes interesadas.
El plan es la base de todas las actividades de SQA.
Ingenieria de Software III Facultad Politecnica
Detalle de las actividades de
SQA
Plan de SQA : mapa para institucionalizar la garantía de calidad del software. Es una plantilla para definir las actividades de SQA aplicables a cada proyecto de 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.
Sección Documentación: Detalle de los productos de trabajo del proceso de software que podrán ser revisados.
Sección Estándares, Prácticas y Convenciones: Detalle de lo que está acordado y establecido para el proceso y los productos a obtener. (Ejemplos: estándares de documentación, estándares de codificación, pasos para la revisión, métricas a obtener, etc.)
Ingenieria de Software III Facultad Politecnica
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. (Ejemplos: Revisiones de
documentación, revisiones técnico formales
(RTF’s),etc.)
Sección de Pruebas: Plan y procedimiento de
Pruebas del Software y de gestionar los defectos
detectados.
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.
Propósito:
descubrir errores (función, lógica o
implementación);
verificar que el software satisface los requisitos;
asegurar que se cumplen los estándares
predefinidos;
hacer más manejable los proyectos.
Ingenieria de Software III Facultad Politecnica
Análisis costo/beneficio de
SQA
Costos de SQA: prevención y evaluación.
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
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.
(2) No La actividad o tarea no fue completada.
(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.- Identificación del proyecto y producto
Proyecto:
Producto:
2.- Inspector
Nombre: • Rol
• Moderador Secretario
• Observador InspectorE-mail: Fono:
3.- Checklist
SI NO N/A
• 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
Checklist: Especificación de Requerimientos
1.- Identificación del proyecto y producto
Proyecto:
Producto:
2.- Inspector
Nombre: • Rol
• Moderador Secretario
• Observador InspectorE-mail: Fono:
3.- Checklist
SI NO N/A
• 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?
¿ Están especificados los requerimientos de interfaz?
Ingenieria de Software III Facultad Politecnica
Checklist: Especificación de Requerimientos
1.- Identificación del proyecto y producto
Proyecto:
Producto:
2.- Inspector
Nombre: • Rol
• Moderador Secretario
• Observador InspectorE-mail: Fono:
3.- Checklist
SI NO N/A
• Factibilidad
¿ Es posible llevar a cabo los requerimientos con las herramientas, técnicas, 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: Diseño interfaz hombre-máquina
1.- Identificación del proyecto y producto
Proyecto:
Producto:
2.- Inspector
Nombre: • Rol
Moderador Secretario
Observador InspectorE-mail: Fono:
3.- Checklist
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
del usuario, 2) información sobre tutoriales y manuales de usuario, 3) tareas que el usuario debe
desempeñar?
• Consistencia
Ingenieria de Software III Facultad Politecnica
Grupo SQA
Muchas organizaciones empiezan a crear grupos de SQA.
Estas personas actúan como representantes interno del cliente.
Es responsabilidad del grupo SQA ayudar a los Ing., a lograr una alta calidad en el programa o aplicación de software determinado.
Este grupo tiene una serie de actividades que se presentan a continuación.
Ingenieria de Software III Facultad Politecnica
Actividades
SQA
Preparación de
Plan SQA
Desarrollo de la
descripción del
proceso de
software
Revisión de
software
Actividades de
verificación DocumentaciónReporte de no
conformidad
Grupo SQA
Ingenieria de Software III Facultad Politecnica
Estándares de calidad
IEEE 730 Software Quality Assurance Plans
IEEE 730.1 Guide for Software Assurance Planning
IEEE 982.1 Standard Dictionary of Measures to Produce Reliable Software
IEEE 1061 Standard for a Software Quality Metrics Methodology
ISO/IEC 12119 Information Technology-Software Packages-Quality Requirements and Testing
ISO/IEC 14598-1 Information Technology-Evaluation of Software Products-General Guide
ISO/IEC 25030 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements
Ingenieria de Software III Facultad Politecnica
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 - 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.
CMMI [SEI]: Estándar basado en CMM pero con una visión más integral.
Ingenieria de Software III Facultad Politecnica
CMM - CMMI
Capability Maturity Model
Capability Maturity Model Integration
Ingenieria de Software III Facultad Politecnica
Software Engineering Institute
SEI
Financiado por el Departamento de Defensa
de Estados Unidos en la Carnegie Mellon
University, desde 1984
(http://www.sei.cmu.edu).
Su primer director su Watts Humphrey,
CMMI del SEI
http://www.sei.cmu.edu/cmmi/
Ingenieria de Software III Facultad Politecnica
Producto del SEI
Modelo de Madurez del Proceso de
Software:
desarrollado para evaluar las capacidades de una
organización de software,
para identificar las áreas más importantes de
mejoramiento,
tratando el proceso completo de desarrollo de
software como un proceso que puede ser:
controlado, medido y mejorado.
Ingenieria de Software III Facultad Politecnica
Modelo de Madurez
Para mejorar sus capacidades, las organizaciones
de software deben:
comprender el estado actual de sus procesos de software,
desarrollar una visión de los procesos deseados,
establecer una lista de las acciones de mejoramiento
requeridas en orden de prioridad,
producir un plan para cumplir dichas acciones,
comprender los recursos necesarios para ejecutar el plan.
Herramienta: framework de madurez.
Ingenieria de Software III Facultad Politecnica
Proceso de Mejora Continuo:
CMM y CMMICMM (Década del ’90): Características
• Mide la capacidad del proceso seguido para desarrollar software incrementando la predictibilidad en
cuanto a costos, tiempos y calidad lograda.
• Es el modelo más utilizado en la industria de software.
• 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.
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), Ingeniería de software (SWE), el desarrollo integrado entre el producto y el proceso (IPPD) y la
gestión de compras y control de proveedores.
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.
Ingenieria de Software III Facultad Politecnica
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, hasta alcanzar la madurez total: 1-Inicial
2-Repetible
3-Definido
4- Gestionado
5-En Mejora Continua.
Ingenieria de Software III Facultad Politecnica
Proceso de Mejora Continuo:
CMMI
Gestión básica de proyectos
Nivel 1: Inicial
Nivel 2: Gestionado
Nivel 3: Definido
Nivel 4: Gestionado
de forma cuantitativa
Nivel 5: Optimizado
Procesos estandarizados
Procesos analizados y medidos
Mejora continua de los procesos
5 Niveles de Madurez
28 Áreas Claves de Proceso
Ingenieria de Software III Facultad Politecnica
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
Ingenieria de Software III Facultad Politecnica
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
Detalle de los Niveles de
Madurez:
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
Ingenieria de Software III Facultad Politecnica
Tiempo para Madurar
Tiempo promedio para alcanzar cada nivel
de CMM:
nivel 1 a nivel 2: 2 a 3 años;
nivel 2 a nivel 3: 1.5 a 2.5 años;
nivel 3 a nivel 4: ?
nivel 4 a nivel 5: ?