4III Gestin de la calidad

1
4(III) Gestión de la calidad
AUTORES Carlos López Bénézét Jesús Mata
Camacho Julio Fuertes Vázquez Manuel Carlos
Camacho Sousa
2
Concepto de calidad

• Definiciones de calidad
• Propiedad o conjunto de propiedades inherentes a
  una cosa, que permiten apreciarla como igual,
  mejor o peor que las restantes de su especie
• Totalidad de las características de un producto o
  servicio que le confieren su aptitud para
  satisfaces sus necesidades expresadas o
  implícitas
• La consecución de la calidad puede tener tres
  orígenes
• Calidad realizada
• Calidad programada
• Calidad necesaria

3
Definición de la calidad del software

• Grado con el que un sistema, componente o proceso
  cumple
• Los requisitos especificados
• Las necesidades o expectativas del cliente o
  usuario
• Los requisitos establecidos explícitamente se
  reflejan en el documento de especificación de
  requisitos del sistema
• Requisitos funcionales
• Requisitos no funcionales o extendidos
• Los estándares y las normas de desarrollo
  permiten que se consiga una calidad técnica
• Los requisitos implícitos no aparecen en la ERS

4
Aspectos de las gestión de calidad

• Gestión de la calidad del software
• Garantía de la calidad del software
• Control de calidad del software
• Verificación y validación

5
Ámbitos de la gestión de calidad

• El trabajo para la mejora de la calidad tiene dos
  ámbitos de actuación
• Nivel de empresa / organización
• Nivel de proyecto

6
Calidad a nivel dela organización

• Para la implantación de una infraestructura de
  calidad es necesario el apoyo de un sistema de
  calidad
• El sistema de calidad se debe adecuar a los
  objetivos de calidad de la empresa
• Dicho sistema consta de dos partes
• Documentación
• Parte practica

7
Calidad a nivel de proyecto

• Para marcar las directrices marcadas por los
  sistemas de calida a cada proyecto particular hay
  que generar un plan especifico de calidad
• Plan de aseguramiento de la calidad, y debe
  contener
• Objetivos de calidad del proyecto y enfoque para
  su consecución
• Documentación referenciada en el plan
• Gestión de aseguramiento de la calidad
• Documentación de desarrollo y de control o
  gestión
• Estándares, normas y practicas que hay que
  cumplir
• Actividades de revisión y auditoria
• Gestión de la configuración del software
• Informes de problemas
• Herramientas, técnicas y métodos de apoyo
• Control del código, de los equipos y de los
  suministros
• Recogida, mantenimiento y almacenamiento de datos
  sobre la documentación de las actividades de
  aseguramiento de la calidad realizadas

8
Estándares ISO 9000

• Se pueden dividir en dos grupos
• Normas para el asesoramiento externo de la
  calidad
• ISO 9001
• ISO 9002
• ISO 9003
• Gestión interna de la calidad
• ISO 9004

9
Estándares ISO 90002000

• ISO 90002000 Fundamentos
• Define los términos fundamentales de la familia
  ISO 90002000
• ISO 90012000 Requisitos
• Permite realizar certificaciones externas de la
  calidad, mediante cuatro áreas fundamentales, que
  son responsabilidad en la gestión, gestión de
  recursos, realización de productos y servicios y
  medición, análisis y mejora
• ISO 90042000 Mejora
• Describe como sería un sistema de control de
  calidad acorde con las normas 9001, y sirve como
  guía tras la implantación de 9001
• ISO/IEC 900032004
• Conjunto de directrices para la aplicación de las
  normas ISO 9001 a un determinado software, ya sea
  adquirido o desarrollado internamente

10
Estándares IEEE

• Se trata de una serie de estándares orientados al
  aseguramiento de la calidad a nivel de proyecto

11
Actividades deaseguramiento de calidad

• Establecimiento y revisión del mismo por parte de
  todas las partes involucradas
• Revisión de la descripción del proceso (Se
  ajusta a la política de la empresa y al
  cumplimiento de estándares internos y externos)
• Revisión de las actividades IS y productos (Se
  hace un seguimiento de las desviaciones y se
  verifica la realización de correcciones)
• Aseguramiento de la documentación de desviaciones
• Registrar aquello que no cumpla los requisitos
• Control y gestión de cambios (Se establecen una
  serie de configuraciones de referencia que
  permiten controlar y gestionar los cambios en el
  software)
• Recopilación y análisis de métricas

12
Modelos de calidad
Gilb
Iso 9126
BOEHM
Factores/Criterios/Métricas
CMM
13
BOEHM

• Divide la calidas en tres características usos
  principales, componentes intermedios y
  componentes primitivos

14
Factores / Criterios / Métricas

• Divide la calidad en tres partes Operación,
  Revisión y Transición
• Divide cada una de las partes en factores
• Divide los factores en criterios
• Se aplican una serie de métricas a estos criterios

15
ISO 9126

• Descompone la calidad en seis factores
• Funcionalidades
• Fiabilidad
• Usabilidad
• Eficiencia
• Mantenibilidad
• Portabilidad

16
GQM

• Paradigma Objetivo-pregunta-métrica

• Basa la mejora en la definición clara de
  procesos y productos
• Proporciona la estructura para obtener los
  objetivos cruciales del proyecto
• Consta de tres etapas
• Determinar los objetivos principales del
  desarrollo y mantenimiento del proyecto
• Obtener las preguntas que se deben contestar
  para saber si se cumplen los objetivos anteriores
• Decidir qué es lo que se debe medir para
  contestar las preguntas de forma adecuada

17
GQM

• Ejemplo

OBJETIVO Evaluar la efectividad del estándar de
codificación
Quién está usando el estándar?
Cuál es la productividad del codificador?
Cuál es la calidad del código?
PREGUNTAS
Proporción de codificadores usando El
Estándar El Lenguaje
Experiencia de codificadores en El Estándar El
Lenguaje El Entorno
Errores
Cantidad de código
18
GILB

• Consiste en determinar una lista de
  características que definen la calidad de la
  aplicación, pudiendo ser de dos tipos
• Originales
• De los modelos tradicionales
• Asociado con la filosofía QFD (Quality Function
  Deployment), para la gestión de la calidad
  industrial
• El proyecto COQUAMO (Constructive Quality Model)
  se apoya en el enfoque de Gilb
• Cada característica se medirá según métricas
  detalladas

19
CMM

• Modelo de Capacidad y Madurez
• para el desarrollo de Software

• Diseñado a finales de los ochenta por el SEI
  (Software Engineering Institute)
• Surgió a petición del Departamento de Defensa
  Norteamericano
• Evalúa la calidad de las empresas
  suministradoras de software a través de cinco
  niveles de madurez, en función de
• Procesos empleados en el desarrollo y
  mantenimiento del software
• Grados de capacidad e institucionalización de
  cada uno
• Posee dos finalidades
• Criterio para la evaluación de la madurez de la
  organización
• Guía para la mejora de sus procesos
• Hoy es un modelo obsoleto que SEI relevó e
  integró en el CMMi en 2000

20
CMM

• Niveles de madurez

Inicial
Nivel 1
Incremento de calidad
Repetible
Nivel 2
Definido
Nivel 3
Gestionado
Nivel 4
Optimizado
Nivel 5
21
CMM

• Áreas Claves de Proceso (KPA)

22
CMM

• Características del Nivel 1 (Inicial)

• Las organizaciones en este nivel no disponen de
  un ambiente estable para el desarrollo y
  mantenimiento de software
• Aunque se utilicen técnicas correctas de
  ingeniería, los esfuerzos se ven minados por
  falta de planificación
• El éxito de los proyectos se basa la mayoría de
  las veces en el esfuerzo personal
• A menudo se producen fracasos y casi siempre
  retrasos y sobrecostes
• El resultado de los proyectos es impredecible

23
CMM

• Características del Nivel 2 (Repetible)

• Las organizaciones disponen de unas prácticas
  institucionalizadas de gestión de proyectos
• Existen unas métricas básicas y un razonable
  seguimiento de la calidad
• La relación con subcontratistas y clientes está
  gestionada sistemáticamente

24
CMM

• Características del Nivel 3 (Definido)

• Correctos procedimientos de coordinación entre
  grupos
• Buena formación del personal
• Técnicas de ingeniería más detalladas
• Nivel más avanzado de métricas en los procesos
• Se implementan técnicas de revisión por pares

25
CMM

• Características del Nivel 4 (Gestionado)

• Conjunto de métricas significativas de calidad y
  productividad, usados de modo sistemático para la
  toma de decisiones y la gestión de riesgos
• Software resultante de alta calidad

Características del Nivel 5 (Optimizado)

• La organización completa está volcada en la
  mejora continua de los procesos
• Uso intensivo de las métricas y gestión del
  proceso de innovación

26
CMM

• Evolución Temporal

• 1987 -- SEI-87-TR-24 (cuestionario SW-CMM)
• 1989 ----- Managing the Software Process
• 1990 --------- SW-CMM v0.2
• 1991 ------------- SW-CMM v1.0
• 1993 ----------------- SW-CMM v1.1
• 1997 --------------------- SW-CMM (Fin de
  revisiones)
• 2000 ------------------------- CMMI v1.02
• 2002 ----------------------------- CMMI v1.1
• 2006 --------------------------------- CMMI v1.2

27
CMMi

• Modelo para la mejora o evaluación de los
  procesos de desarrollo y mantenimiento de
  sistemas y productos de software

• Evolución natural de varios modelos de calidad
  desarrollados por el SEI durante los 90, como
  eran CMM-SW, SE-CMM y IPD-CMM
• Es posible implementarlo siguiendo una de las
  dos posibles representaciones
• Continua Al estilo del SE-CMM
• Escalonada Al estilo del CMM-SW

28
Fiabilidad del Software

• La fiabilidad es la característica dinámica más
  importante de casi todos los sistemas software
• Una mayor fiabilidad aporta un menor número de
  fallos en el programa y arrastra un mayor coste
  de desarrollo en dicha aplicación

Conjunto de entradas
Conjunto de salidas
Ee
Se
Sistema
29
Los fallos

• Se pueden producir por defectos en el código, en
  el diseño, en el análisis e incluso también
  durante el mantenimiento
• Tipos de fallos

• Se corrigen usando técnicas de pruebas

30
SPICE

• Software Process Improvement
• and Capability Determination

• Aprobado en 1998, denominándose ISO/IEC TR 15504
• Se utiliza para la mejora de procesos y
  determinación de la capacidad
• Establece un marco para métodos de evaluación,
  no es un método o modelo en sí
• Posee equivalencia y compatibilidad con CMMi
• Comprende
• Evaluación de procesos
• Mejora de procesos
• Determinación de capacidad

31
SPICE

• Arquitectura en dos dimensiones

• (1) PROCESO
• Procesos primarios
• CUS Cliente - Proveedor
• ENG Ingeniería
• Procesos de soporte
• SUP Soporte
• Procesos organizacionales
• MAN Gestión
• ORG Organización

(2) CAPACIDAD DE PROCESO Nivel 0
Incompleto Nivel 1 Realizado Nivel
2 Gestionado Nivel 3 Establecido Nivel
4 Predecible Nivel 5 En
optimización
Identificador Nombre Tipo Propósito Salidas Notas
Componentes
32
Revisiones del software

• Técnicas estáticas que se aplican en varios
  momentos del desarrollo y que detectan defectos
  para así eliminarlos

Tipos de Revisión (IEEE 1028)

• De gestión
• Técnicas
• Inspecciones
• Walkthrough
• Auditorias

33
Auditorias

• Revisiones dirigidas a evitar el fraude o mal
  uso de las aplicaciones informáticas
• Misión del auditor -gt diseñar y promover la
  inclusión de los controles que ha de llevar el
  nuevo sistema (garantizando su integridad)
• Medidas de control
• Sobre datos
• Operatividad
• Relativas al plan

34
Métricas de calidad

• Basadas en atributos internos
• De Estructuración de un programa
• De complejidad
• De cobertura de pruebas
• De calidad del diseño
• Basadas en atributos externos
• De portabilidad
• De defectos
• De usabilidad
• De mantenibilidad
• De fiabilidad
• Basadas en sistemas orientados a objetos
• Orientadas a clases
• Orientadas a operaciones
• Orientadas a objetos

35
Métricas de Cobertura de Pruebas

• Objetivo -gt comprobar el esfuerzo y rigor en la
  realización de las pruebas
• Caso de prueba se define como el par (i,S(i))
  siendo i una entrada del programa y S una
  especificación.
• Existen dos categorías
• Pruebas de caja negra Se derivan de la
  especificación, sin conocer la estructura interna
  del programa
• Pruebas de caja blanca Se conoce la estructura
  interna del programa. Tipos
• De sentencias (cada sentencia se ejecuta al menos
  una vez)
• De ramas (cada rama se ejecuta una vez)
• De caminos (todos los caminos al menos una vez)
• Prueba del camino simple (todos los caminos
  simples)
• Prueba estructurada (todos los caminos
  linealmente independientes)

36
EJEMPLO Métricas de Cobertura de Pruebas
37

• Métricas asociadas con las estrategias de prueba

• Numero mínimo de casos de prueba
• - Determina el número mínimo de casos que hay
  que generar para un programa
• - Número mínimo de caminos de un grafo de flujo
  que se requieren para satisfacer una estrategia
• Índice de efectividad de las pruebas
• - Medida del grado en que los casos de prueba
  satisfacen una estrategia particular para un
  programa
• - Se expresa mediante el TER
• - TER nT/nO
• - Siendo nT el número de objetos probados alguna
  vez y nO el número total de objetos