Calidad del Software - Departamento de Informática ...manso/calidad/trascalidad-2011.pdf · 4.2...

1

1

Calidad del SoftwareCalidad del Software

ITI Gestión

M.E.Manso.

2

1 Medición y experimentación en Ingeniería del Software

Programa

Calidad del Software

1. Medición y experimentación en Ingeniería del SoftwareIntroducciónTeoría representacional de la medición.Recursos y problemas de la experimentación en Ingeniería del software.

2. Medidas del Producto3. Modelos y métricas del Proceso

4. Calidad del Software

M.E.Manso.

4.1 Introducción4.2 Control y Aseguramiento de la calidad4.3 Estándares de calidad

2

• Piattini M., García F.O.. Calidad en el desarrollo y mantenimientodel software. Ed RAMA, 2003.

Bibliografía

Control de la calidad 3

,• Camisón C., Cruz S., González T. Gestión de la calidad, 2006.

Pearson. Prentice Hall.• Minguet Melián J.M. y Hernández Ballesteros J.F. La calidad del

software y su medida. E. Centro de Estudios RA. 2003.• Martí Casadesús et al, Calidad Práctica. Prentice Hall. 2005.

Algunas referencias webhttp://deming.eng.clemson.edu/onlineq.htmlp g g qhttp://mijuno.larc.nasa.gov/dfc/toc.htmlhttp://www.aqp.orghttp://www.qualitycircles.com/QCHome/Home.htmlhttp://www.euroqual.org/http://www.norbackley.com/HACCP_Home.htmlhttp://www.quality.org/html/benchm.html

4

C d l t d lid d

4.1. Objetivos del Tema

Calidad Calidad del Software

• Comprender el concepto de calidad• Conocer modelos de calidad y su aplicación • Conocer conceptos básicos: control y

aseguramiento de la calidad• Ventajas e inconvenientes de los modelos de

calidad

M.E.Manso.

3

5

4.1 Introducción¿Qué es la calidad del software?

En 1990 se establecen principios de calidad del

IntroducciónCalidad del Software

En 1990 se establecen principios de calidad delsoftware:

Calidad del producto, en todos sus estadosCalidad del proceso

¿Qué diferencia hay con otros productos?Naturaleza

M.E.Manso.

Ciclo de vidaFlexibilidadReutilización

Concepto de Calidad (i)

Concepto de Calidad:

6

Concepto de Calidad:Multidimensional

• Referida a varias cualidades:• Funcionalidad, Oportunidad, Coste, …

Sujeta a restricciones• Presupuesto disponible

Ligado a compromisos aceptables• Plazos de fabricación

No es ni totalmente subjetiva (porque ciertos aspectos pueden medirse) Ni totalmente objetiva (ya que existen cualidades cuya evaluación sólo puede ser subjetiva).

M.E.Manso.

4

7Introducción

Concepto de Calidad (ii)


“La calidad es la suma de todos aquellos aspectos ocaracterísticas de un producto o servicio quecaracterísticas de un producto o servicio queinfluyen en su capacidad para satisfacer lasnecesidades expresadas o implícitas” ISO 8402

“La capacidad del producto software para satisfacerlos requisitos establecidos” DoD 2168

M.E.Manso.

La calidad es algo relativoSu evaluación implica una comparación No se puede conseguir buena calidad sin una buena ERS

8

Perspectivas de la Calidad

• TRASCENDENTAL (calidad = excelencia)


• BASADA EN USUARIO (adecuación al propósito)

• BASADA EN FABRICANTE (capacidad y madurez de proceso)

• BASADA EN PRODUCTO (conformidad con requisitos)

• BASADA EN VALOR (precio asequible)

M.E.Manso.

5

9Introducción

Perspectivas de la calidad (ii)


L i l

• Niveles de la calidad

Necesaria o requerida

Programada especificada

Realizada

La que quiere el cliente

La que hemos

La que se pretende obtener

M.E.Manso.

La que hemos construido

La gestión de la calidad busca conseguir que estos tres círculos coincidan entre sí.

• Todo lo que no sea coincidencia es gasto superfluo o insatisfacción.

10Introducción

Proceso a seguir


• Definición precisaModelos de calidadModelos de calidad

• ConstrucciónAseguramiento de la calidadGestión de la calidad

• ConfirmaciónControl de la calidad

M.E.Manso.

La norma ISO 9000:2000 es la principal referenciainternacional sobre conceptos de calidad.

versión española: UNE-EN ISO 9000:2000 Sistemas de Gestión de la Calidad. Fundamentos y Vocabulario

6

11

• Jerarquizan el concepto de calidad

Introducción

Modelos de calidad


q p

• Facilita las operaciones

• Estructura clásica para productos (F-C-M)

Factores: Punto de vista del usuario. Atributos de calidad externos

Criterios: Punto de vista del producto

M.E.Manso.

Criterios: Punto de vista del producto. Atributos de calidad internos

Métricas: Medidas cuantitativas

12

l l d d d f é d l d é d l

Introducción

Utilidad de los modelos de calidad (i)


• Concretan la calidad, definiéndola, midiéndola y

planificando

• Ayudan a comprender las relaciones entre las

características del producto software

• Facilitan la comunicación entre usuarios directivos y

M.E.Manso.

• Facilitan la comunicación entre usuarios, directivos y

ténicos

• Son empíricos, su validez se demuestra observando

resultados

7

13

• En la planificación, establecimiento de los requisitos

Introducción

Utilidad de los modelos de calidad (ii)


p , q

de calidad

Aceptación del Modelo de calidad: F-C-M u otro

Aceptación de las relaciones

Establecimiento de los requisitos de calidad, dependen de:

M.E.Manso.

• Tipo de producto

• Ciclo de vida: duración y tipo

• Evolución del hardware

14

Establecimiento de los requisitos de calidad (sigue):

Introducción

Utilidad de los modelos de calidad (iii)


• Costes del factor vs. beneficios esperados

• Repercusiones en el ciclo de vida

• Interrelaciones con otros factores

Ordenar los requisitos por prioridades

M.E.Manso.

Obtener F-C-M involucrados. ¿Problemas?

Establecer objetivos medibles, y mínimos aceptables

(revisar métricas externas)

8

15

• Calidad: # defectos

Introducción

Calidad 6 σ (i)


• Métrica: Tasa de defectos

• Objetivo: 6σ (valores medios 2-60de/KLDC)

• Justificación: modelos de calidad muy costosos

M.E.Manso.

• Riesgos de mal uso:

Todos los fallos no tienen la misma importancia

Todos los defectos no ocurren con la misma probabilidad

Calidad 6 σ (ii)

• Procesos de desarrollo: distribución normalP b bilid d ( l f d (LI LS)) b bilid d d d f t “

16Introducción

• Probabilidad (valores fuera de (LI, LS))= probabilidad de defecto“• Un proceso poco preciso y sesgado tiene alta probabilidad de

defecto.

M.E.Manso.

9

Calidad 6 σ (iii)

Introducción 17

M.E.Manso.

Objetivos del 4.2

• Control y Aseguramiento de la calidad


• Control y Aseguramiento de la calidadDiferenciar entre verificación y validaciónConocer y saber usar actividades de control de calidad

• Inspecciones• Revisiones• Pruebas

Conocer que es un Plan de Aseguramiento de Calidadq gSaber aplicar ciertas fases del PGAC de las Administraciones públicas

M.E.Manso.

10

Definiciones (i)

• Error


• Defecto (Fault)• Fallo (Default)• Incidencia:

Situación en la que se produce e informa de uncomportamiento no esperado del sistema

M.E.Manso.

Definiciones (ii)

• Validación (con respecto a ERS)


( p )

Grado en que el sistema hace lo que el usuario espera¿Estamos construyendo el producto correcto?

• Verificación (con respecto a las entradas)

Grado en que el producto se construye correctamente¿El sistema está bien construido? ¿El sistema está bien construido?

Control de Calidad: Verifica o Valida

M.E.Manso.

11

Auditorías (i)

Investigación para:


g pVerificar conformidad con procedimientos, instrucciones, estándares, ER de cualquier tipo…Identificar desviacionesProponer solucionesE l l d ió d l biEvaluar la adecuación de los cambios

M.E.Manso.

Auditorías (ii)

Tipos de auditorías


• Del productoo Funcionalo Física

• Del procesoo Equipo (productividad, eficacia…)o Métodos y herramientas (efectividad)

• De la gestióno Prácticas de gestión (efectividad)o Organización

• Del sistema de calidadM.E.Manso.

12

Auditorías (iii)

Procedimiento


• Planificacióno ¿Porqué? ¿para qué? o Entradas , salidas esperadas, destino de las

salidaso ¿Quién? ¿Cómo? ¿Cuándo?

• Investigaciónóo Reunión de apertura

o Recogida de datos

M.E.Manso.

Auditorías (iv)

Procedimiento


• Análisis de resultadoso Análisis estadísticoo Evaluación en paraleloo Comparación de conclusioneso Estudio de causas

• Sugerencias de soluciones, mejoras…• Informes con los resultados

M.E.Manso.

13

Cuándo: primeras fases vs. fases finalesObjetivos: detectar defectos vs. certificar conformidad

Revisiones vs. Auditorías


j

Atributo Revisiones Auditorías

Mecanismo Reuniones Reuniones, exámenes, observaciones

Responsabilidad Del equipo, usualmente Equipo ajeno a la empresa, con un de la organización auditor responsable

Duración Corta: unas horas Media - larga: días o mesesDuración Corta: unas horas Media - larga: días o meses

Estructura del Reuniones de múltiples Incluye otras auditorías, revisionesdesarrollo sesiones o pruebas periódicas

Frecuencia Depende de la fase del Periódicaciclo de vida

Revisiones formales (i)

Objetivos


• Ofrecer información fiable y objetiva a los gestores

• Asignar responsabilidades no sólo a los autores

Tipos• Por objeto: de gestión o proyecto y técnicas• Por objeto: de gestión o proyecto y técnicas• Por formalidad y mecánica

o Inspeccioneso Recorridos

M.E.Manso.

14

Revisiones formales (ii)

De gestión. Recomendaciones para:


• seguir el plan del proyecto• determinar cambios• mantener control

Técnicas. Evalúan el producto intermedio para comprobar si:• Se ajusta a especificaciones• Se ajusta a especificaciones• El desarrollo sigue planes, estándares y guías• Los cambios se hacen bien

M.E.Manso.

Inspecciones (i)“Técnica de revisión formal, en la que requisitos de software,diseño o codificación se examinan en detalle por un grupo de


diseño o codificación se examinan en detalle por un grupo depersonas distintos del autor, para detectar defectos,disconformidades con las normas de desarrollo y otrosproblemas” (IEEE, 1990)

Reglas a seguir:• Inspeccionar toda clase de problemas• Participan personas de todos los niveles• Etapas predefinidasEtapas predefinidas• Reuniones no superiores a 2h• Moderadores y directores expertos• Cada miembro tiene funciones detalladas para hacer• Listas de comprobación• Archivo de estadísticas y defectos

M.E.Manso.

15

Inspecciones (ii)Control de la calidad 29

Etapa Objetivo Tarea Participantes Planificación Organizar Aprobar criterios de entrada

Establecer tiempos y participantes Determinar presentación

ifi ió d l

Moderador Autor

Preparar notificación de la I.Distribuir material a los inspectores

Visión general Enseñar producto (P) Presentar el producto Todos Preparación Comprender P

Identificar defectosEstudio individual del P Todos

Reunión Verificar P Introducción Comprobar preparación inspectores Lectura y detección de defectos Revisar lista de defectos Determinar disposición del P

Todos

Determinar disposición del PTercera hora (*) Aprovechar posibles

soluciones Analizar posibles mejoras o soluciones

Todos

Corrección Cumplir criterios de salida Resolver todos los defectos Autor Seguimiento Verificar la corrección Comprobar que se resolvieron

y que no hay nuevosModerador

Análisis de resultados (*)

Analizar para posteriores inspecciones

Clasificar defectos (clase, tipo y gravedad

Coordinador

• ¿Uniformidad en el diseño?

Listas de comprobación Inspecciones (iii)


• ¿Interfaces entre módulos definidas correctamente

• ¿ Interfaces externas definidas correctamente?

• ¿El diseño cubre todas las funciones de la especificación de requisitos?

• ¿El diseño cumple todos los requisitos no funcionales?

• ¿Se ha aplicado la notación de diseño correctamente?• ¿Se ha aplicado la notación de diseño correctamente?

• ¿ La documentación del diseño es ambigua?

• ¿Diseño suficientemente detallado para implementarlo en el lenguaje elegido?

16

Inspecciones (iv)


Documentos generadosNotificación de la reunión y detalle de tareas, lugares, tiempos etcInforme resumen de defectos• Distribución de defectos

Informe final de la inspecciónp• Administrativo• Esfuerzo realizado

Inspecciones (v)


Documentos generadosLista de defectos• Registro detallado que incluye:

o Localizacióno Descripcióno Clasificacióno Gravedado Gravedad

17

Tipo de defectoCumplimiento con estándares Desviación del producto respecto de los estándares

Una clasificación de defectos


Cumplimiento con estándares Desviación del producto respecto de los estándaresFactores humanos (error) Procedimientos operativos incorrectosDocumentación Algún componente esta mal descritoFuncionalidad Componente con especificaciones funcionales defectuosasInterfaz Defectos en la comunicación Datos Datos mal especificadosLógico Módulo con lógica de control defectuosaEntrada/Salida Comunicación con dispositivos defectuosaSintaxis Defectos gramaticalesCasos de prueba Condición de prueba mal especificada, o desviada del planEjecución Eficiencia menor que la prevista

Gravedad del defecto: Depende de las consecuencias.

Clase de defecto: Por ausencia, error o añadido

Cálculo del coste de la recogida de información sobre defectos:


Coste de las inspecciones (i)

Cálculo del coste de la recogida de información sobre defectos:• Coste = Tamaño x Densidad media de defectos x Tº para registrar

1/12 horas/defecto = 8 1/3 horas• 100 KLDC x 1 defecto/KLDC x

1/6 horas/defecto = 16 2/3 horas• Tamaño 100 KLDC• Nº de inspectores 4 ó 5• tº de preparación/ tº de inspección > 1.75• Productividad de la inspección 300-400 líneas de diseño/hora• Efectividad de la inspección 2.5 defectos/hora• tasa de defectos/kldc, estimada 8• tasa de defectos producidos en el diseño, estimada 18%• tasa de defectos de diseño encontrados en inspecciones 55%

18

Estimación de defectos encontrados en insp. de diseño: 100 kld 8 d f/kld 0 18d f di /d f 0 55 d f di /d f di 79 d f di

Coste de las inspecciones (ii)


kldc x 8 def/kldc x 0.18def-dis/def x 0.55 def-dis-en/def-dis = 79 def-dis

Estimación de horas de insp. para encontrar los defectos:

Estimación de horas para encontrar defectos en la fase det t (t d t d f t t d 6 25)

inspechorasinshorainshoraencdisdef

inspechorasencdisdef .392_1)_/__5.2(

5.4)175,1(__79=

××+×

test (tasa de coste defectos atrasados = 6,25)392 horas x 6.25 = 2450 horas

Conclusión: 2450 - 392 = 2058 horas ahorradas

1. Planificación

Procedimiento de un recorrido


1. PlanificaciónSólo hay dos roles:• Presentador• Participante

2. Preparación individualSin lista de comprobación

36

Sin lista de comprobación

3. ReuniónSe pueden sugerir soluciones

19

Inspecciones vs. Recorrido

Propiedades Inspección Recorrido 1 Entrenamiento formal del moderador SI NO


1. Entrenamiento formal del moderador SI NO

2. Roles definidos para participantes SI NO

3. Guía de la revisión Moderador Propietario producto

4. Usan listas de comprobación SI NO 5 Errores distribuidos por tipo SI NO

M.E.Manso.

5. Errores distribuidos por tipo SI NO 6. Seguimiento para controlar la corrección

SI NO

7. Se puede mejorar eficiencia de la revisión (análisis resultados)

SI NO

Obj ti

Mét d i i l

Uso de las actividades de control


Objetivos Método principal Evaluación

Revisión de gestión (del proceso) Revisión técnica

Verificación

Inspección Recorrido (walkthrough)

Validación

Pruebas (propias del producto) Validación Pruebas (propias del producto)

Confirmación del cumplimiento

Auditoría

20

Plan de Revisiones &Auditorías (IEEE)

• Revisión de requisitos del software, sobre las ERS (con el usuario)R i ió d l di ñ li i ió é i d l di ñ d l

Plan de revisiones y auditorías (IEEE)


• Revisión del diseño preliminar, corrección técnica del diseño de alto nivel• Revisión de diseño crítico sobre diseño detallado, comprobando su ajuste a las ERS• Revisión del plan de V&V de software. Comprueban adecuación de métodos.• Auditoría funcional: sobre el software justo antes de entregarlo, para verificar que cumple requisitos.• Auditoría física: verifican que software y documentación son consistentes y están listos para entregar (junto a pruebas de aceptación)• Auditoría durante el desarrollo: verifican consistencia del diseño • Revisiones de gestión: periódicas. Comprueban el seguimiento del plan de calidad.

• PruebaEjecución de un sistema con el fin de encontrar fallos

Controles dinámicos: Pruebas


Ejecución de un sistema con el fin de encontrar fallosDiseño de la prueba: Sólo es exitosa si encuentra fallos

• DepuraciónLocalización del defecto que es la causa del falloDeterminar la forma de corregirloEvaluar el efecto de la correcciónCorrección

• Coste Detectar cuesta más que corregir50 - 60% del esfuerzo en grandes proyectos

21

• Modular o Unitariaá


Tipos de pruebas

Objetivo: encontrar errores basándose en la estructura o en las especificaciones

• De IntegraciónObjetivo: Comprobar las interfaces entre módulosEstrategias:• Ascendente o Bottom-up

D d t T d• Descendente o Top-down• Gran explosión o Big-bang

• Del Sistema ¿Se satisfacen los requisitos del usuario?

• De Aceptación Demostración del funcionamiento en su entorno real (pruebas β)

Métodos de caja negra


Diseño de pruebas (i)

j gBasadas en las especificaciones de entrada y saliday combinaciones

Estrategias• Clases de equivalencia• Análisis de valores límites

42

• Grafos causa-efecto• Conjetura de errores

22

Métodos de caja blanca


Diseño de pruebas (ii)

Basadas en cada posible camino en el grafo deflujo de control

Estrategias• Sentencias• Decisiones • Condiciones• Combinaciones de condiciones

Métrica de cobertura del grafo: V(G)

Plan de PruebasIEEE std 892


Metodología de las pruebas

Especificación de diseño de pruebas

Especificación de diseño de pruebas

E ifi ió d E ifi ió d

....

44

Especificación de procedimientos de pruebas

Especificación de casos de pruebas

Ejecución

Informes

23

45

4.3 Objetivos de Estándares de calidad

• Qué son las ISO


Q• Qué aportan a la calidad del software• Como ayudan a las organizaciones• Qué aportan a los clientes• Ventajas e inconvenientes

M.E.Manso.

ISO 14598 y 9126

46

M.E.Manso.

24

ISO 14598 y 9126

47

M.E.Manso.

Calidad del Software - Departamento de Informática ...manso/calidad/trascalidad-2011.pdf · 4.2...

Documents

Transcript of Calidad del Software - Departamento de Informática ...manso/calidad/trascalidad-2011.pdf · 4.2...