PLANEACIÓN DE LA CALIDAD - Profesoresisis2603/...Proporción Equivalencia Más grande que Conoce la...

PLANEACIÓN DE LA

CALIDAD Rubby Casallas

Departamento de Ingeniería de Sistemas y Computación

Universidad de Los Andes

1

Referencias2

Software Metrics

Normal E. Fenton and Shari Lawrence Pfleeger. Second

Edition. PWS publishing Company. ISBN: 0-534-95425-1

1999

Metrics and Modals in Software Quality Engineering

Stephen H. Kan Addison Wesley ISBN 0-201-6339-6 2001

Introduction to the Team Software Process SM. Capítulo 5

Watts Humphrey. Addison Wesley. 2000

Ejercicio3

¿Cuál información Ud. debe tener para poder

responder a estas preguntas?

“¿Cuánto ha costado el proceso de pruebas en el proyecto?”

“¿Qué tan bueno es el código que se ha desarrollado? “

“¿Están los clientes satisfechos con el producto hasta ahora

desarrollado?”

“¿Se han encontrado todas las fallas?”

“¿Cómo se puede mejorar el proceso?”

Métricas de Software4

“Las métricas de Software son una obscura

y esotérica especialidad”

Agenda5

Métricas de producto y de proceso de software

GQM: Objetivos, Preguntas, Métricas

Plan de Calidad

Agenda6



Plan de Calidad

Propósito7

Las métricas de Software ayudan a una organización

en dos frentes:

Evaluación de la calidad del producto

Evaluación de la calidad del proceso para producir

productos de software

Definiciones Básicas8

La acción de medir es el proceso por el cual números o

símbolos son asignados a atributos de entidades en el mundo

real, de tal forma que los describen de acuerdo a reglas

claramente definidas

Ejemplos:

Entidades Atributos Mediciones

Cuarto área 20x30 metros

Fase de pruebas tiempo invertido 2 horas

Aire temperatura 20C

Proceso de SW nivel CMM nivel 3

Definiciones Básicas (2)9

Y ahora:

Entidades Atributos Mediciones

Software Calidad ?

Programa Tamaño ?

Programa Complejidad ?

Software Confiabilidad ?

Definiciones Básicas (3)10

“Lo que no es medible, hágalo medible”

Galileo Galilei

Sugiere que uno de los objetivos de la ciencia es

encontrar formas para medir atributos de las cosas en las

que estamos interesados

Las métricas hacen los conceptos más visibles y por lo

tanto más entendibles y controlables

Alcance de las métricas de Software

11

Métricas para entender, controlar y mejorar

ProcesoRecursos Producto

• Proceso: cualquier actividad relacionada con la producción de

software

• Diseño, codificación, pruebas, administración de

configuraciones

• Producto: un artefacto resultado de una actividad del proceso

• Especificación, plan, código, caso de prueba

• Recurso: un elemento que es necesario para realizar el proceso

• Gente, tiempo, hardware, software, método

Alcance de las métricas de Software (2)

12

Para un Producto, Proceso o Recurso tenemos:

Atributos externos

Pueden ser medidos únicamente con respecto a su

interacción con el ambiente

Por ejemplo: Confiabilidad

Atributos Internos

Pueden ser medidos en términos puramente de las

entidades en si mismas.

Por ejemplo, líneas de código

Componentes de las métricas de

software13

Proceso

Producto

Recursos

Atributos internos y externos

Ejemplos: Productos14

Entidad Interno Externo

Especificaciones

tamaño, reutilización,

modularidad, corrección

sintáctica

entendible,

mantenibilidad

Diseñostamaño, reuse, modularidad,

acoplamiento, funcionalidad

calidad, complejidad

mantenibilidad

Código

tamaño, reuse, complejidad

algorítmica, flujo de control

estructuración

confiabilidad,

mantenibilidad

Ejemplos: Proceso15


Especificar

tiempo, esfuerzo, número de

cambios en los

requerimientos

calidad, costo, estabilidad

efectividad

Pruebastiempo, esfuerzo, número de

defectos encontrados

costo, costo-efectividad

Planeacióntiempo, esfuerzo, error de

estimaciónprecisión, costo

Ejemplos: Recursos16


Personal edad, salario productividad, experiencia

Software precio, tamaño uso (usability), confiabilidad

Oficinas temperatura, tamaño, luz confort, calidad

Escalas de medición: Ejercicio17

En un estudio reciente sobre calidad de los procesos en las organizaciones, se encontró que:

15 organizaciones fueron nivel 1




y 1 organización fue nivel 5

Entonces ¿Podemos decir que el nivel de CMM promedio es:

2.17?

Tipo de escala RelacionesEjemplo de

estadísticas

Nominal EquivalenciaModa

Frecuencia

OrdinalEquivalencia

Más grande que

Media

Percentil

Intervalo

Equivalencia

Más grande que

Conoce la diferencia en cualquier

intervalo

Media

Desviación estándar

Proporción

Equivalencia

Más grande que


intervalo


intervalo y escala

Media geométrica

Coeficiente de

variación

Agenda19



Plan de Calidad

GQM20

Hechos:

Una métrica es útil sólo si ésta ayudad a entender o

el proceso o el producto producido

Reconocer mejoramiento del proceso o del producto

de software solo puede ocurrir cuando los objetivos

(del proceso y del producto) fueron claramente

definidos

GQM21

El método GQM ayuda en la definición de objetivos de

una organización

Una vez establecidos los objetivos, se pueden refinar a

través de preguntas cuya respuesta permitirá concluir si

los objetivos se cumplieron o no

Asociado a las preguntas se definen métricas cuyos

valores ayudaran a contestar las preguntas

Ejemplo23

Objetivos:

Evaluar la efectividad de usar un estándar de

codificación

Preguntas:

¿Quién usó el estándar?

¿Cuál es la productividad de codificación?

¿Cuál es la calidad del código?

Ejemplo cont.24

Métricas:

Quién usó el estándar?

Proporción de codificadores usando el estándar

Experiencia de los codificadores con el estándar, el

lenguaje, la plataforma

Cuál es la productividad de codificación?

Tamaño del código, esfuerzo

• Cuál es la calidad del código? • Defectos/LOC

Definición de Objetivos25

Propósito:

Para (caracterizar, evaluar, predecir, motivar, etc.) el

(proceso, producto, métrica, etc.) para poder (entender,

evaluar, controlar, administra, aprender, mejorar, etc.)

Perspectiva:

Examinar el (costo, efectividad, defectos, cambios, etc.)

desde el punto de vista del (desarrollador, gerente,

cliente, usuario, etc.)

Ambiente (dentro de ciertas características de):

Factores de proceso, la gente, los métodos, las

herramientas, las restricciones

Objetivos: Ejemplo26

Propósito

Caracterizar el proceso de inspección de software para

poder evaluarlo

Evaluar la calidad del producto para mejorarla


Preguntas

¿Cuánto cuesta el proceso de inspección?

¿Cuánto tiempo calendario toma el proceso de

inspección?

¿Cuál es la calidad del software inspeccionado?

¿Cuál es el grado de conformidad de la gente con el

proceso de inspección?

¿Cuál es la productividad del proceso de inspección?


Métricas

Promedio de esfuerzo por KLOC

Porcentaje de reinspecciones

Promedio de fallas detectadas por KLOC

Total KLOC inspeccionadas

Promedio de líneas de código inspeccionadas

Eficiencia de los defectos removidos

Promedio de esfuerzo por defecto detectado

GQM29

¿Cuál es la relación entre métricas y madurez del

proceso?

CMM30

Initial (1)

Repeatable (2)

Defined (3)

Managed (4)

Optimizing (5)

Disciplined process

Standard, consistent process

Predictable process

Continuously improving process

Unpredictable and poorly controlled

Can repeat previously mastered tasks

Process characterized,

fairly well understood

Process measured and

controlled

Focus on continuous

process improvement

Agenda31



Plan de Calidad

Plan de Calidad32

Construir un plan de calidad basado en ciertos

índices de desempeño

Contenido del Plan

1. Resumen de Porcentajes

2. Porcentaje libre de defectos (PDF)

3. Defectos por Página

4. Defectos por KLOC

5. Proporción de defectos (Ratio)

6. Proporción de tiempos de desarrollo

Plan de Calidad (2)33

Contenido del Plan

7. A/FR

8. Porcentaje de revisión e inspección

9. Porcentaje de inyección de defectos

10. Porcentaje de eliminación de defectos

11. Rendimiento (yield) de fase

12. Rendimiento (yield) de proceso


1. Resumen de Porcentajes

Las tres medidas del resumen dan una perspectiva

global de la calidad del Proceso:

LOC/Horas: mide la productividad global del grupo. Un

número grande indica gran productividad y bajos costos

% Reutilización: mide el porcentaje global de este

producto que fue reutilizado de proyectos anteriores

% Reutilización nuevo: mide la contribución de este ciclo

al mejoramiento de la productividad en ciclos posteriores

o proyectos


2. Porcentaje libre de defectos (PDF)

Mide el porcentaje de los componentes de un producto que

no tiene defectos en una fase dada.

Ejemplo:

Un componente con 5 partes y cuatro tenían defectos en la fase de

compilación, el PDF del componente en la fase de compilación es

del 20% (no se tiene en cuenta el número de defectos)

Entre mayor el número de partes, mayor la precisión del PDF para

medir la calidad del componente.

Datos de PDF en todas las fases de eliminación de defectos

permite ver el mejoramiento de la calidad a través del

proceso de desarrollo.


3. Defectos por página

Muestra el número de defectos removidos de cada

página del documento de requerimientos y del

diseño de alto nivel


4. Defectos por KLOC

Un defecto es cualquier elemento asociado con los

requerimientos, el diseño o la implementación que de

no ser cambiado puede causar un diseño,

implementación, prueba, uso o mantenimiento del

producto no adecuados

Un defecto mayor es cualquier problema que cuando

se arregla cambia el código ejecutable

Defectos en formatos o comentarios son considerados

menores


4. Defectos por KLOC (cont...)

El número de defectos encontrados en una fase de pruebas indica la calidad del producto entrando y saliendo de esa fase

Cuando un producto tiene muchos defectos, una fase de pruebas encontrará muchos de ellos poro también dejará sin encontrar muchos

Si hay muchos defectos en pruebas unitarias, probablemente habrá todavía muchos terminada esa fase



La experiencia muestra que cuando un producto tiene

menos de 0.5 defectos/KLOC en construcción y

pruebas de integración y menos de 0.2

defectos/KLOC en pruebas de sistema, generalmente

no habrá defectos para que encuentre el usuario

(producto de alta calidad)

40

0

10

20

30

40

50

60

70

Re

vis

ion

DD

Re

vis

ión

Có

dig

o

Co

mp

ila

ció

n

Pru

eb

as

Un

ita

ria

s

Inte

gra

ció

n

Pru

eb

as

de

Sis

tem

a

A

B

Plan de Calidad (9)



5. Proporción de defectos (Ratio)

Provee un mayor detalle de la calidad de las revisiones de diseño y de código

La experiencia muestra que cuando se encuentra el doble de defectos en revisión de código que en compilación, la revisión de código fue realizada a conciencia. En este caso la proporción de defectos es 2.0

Número de defectos encontrados en revisión de diseño contra número de defectos encontrados en pruebas unitarias. Esta proporción debería ser más de 2.0


6. Proporción de tiempos de desarrollo

Según la experiencia, las siguientes proporciones dan

una idea de la buena calidad del producto (no es una

garantía poro la probabilidad es alta):

25% del tiempo de requerimientos debe ser en

inspección de requerimientos

50% del tiempo de diseño de alto nivel debe ser en

revisiones e inspecciones

>100% del tiempo de diseño detallado debería ser en

revisiones e inspecciones


7. A/FR (Appraisal to Failure Ratio)

(Revisión/Pruebas)

Para programas pequeños debería ser alrededor de

2.0

Para programas grandes debería ser alrededor de

1.0 porque aun si los programas tienen pocos

defectos en pruebas, probarlos es dispendioso


8. Porcentaje de revisión e inspección

Requerimientos: <2.0 páginas de texto a espacio

simple por hora

Diseño de alto nivel: <5.0 páginas de diseño por

hora

Diseño detallado: <100 líneas de pseudocódigo por

hora

Código: <200 líneas de código por hora


9. Porcentaje de inyección de defectos

De acuerdo con datos de varios cientos de

programas escritos por estudiantes y por ingenieros

experimentados en un curso de PSP, se tiene que:

La proporción de inyección de defectos durante diseño

detallado es de 2 defectos por hora

Y es de 6 defectos por hora en codificación


10. Porcentaje de eliminación de defectos

Tomando la misma muestra, los datos fueron más

variados:

En revisión de código va de 0 a 20 defectos por hora,

el resultado fue de 6 defectos por hora para el 61.5%

de los ingenieros

En revisión de diseño, 2 o más defectos por hora para el

57.9% de los ingenieros


11. Rendimiento (yield) de fase

Porcentaje de defectos en un programa que fueron removidos durante una fase dada

Ejemplo:

19 defectos en el programa a la entrada de la revisión de código

Se inyectó un defecto durante la revisión de código

Se encontraron 15 durante la revisión

yield = 100 * (defectos encontrados)/(defectos en el producto) = 100* 15/(19+1) = 75%

Se puede calcular sólo cuando se ha terminado el programa y se sabe el número total de defectos


12. Rendimiento (yield) de proceso

El porcentaje de defectos removidos antes de una

fase dada

Ejemplo: antes de pruebas de sistema debería ser

de 99%

PLANEACIÓN DE LA CALIDAD - Profesoresisis2603/...Proporción Equivalencia Más grande que Conoce la...

Documents

Transcript of PLANEACIÓN DE LA CALIDAD - Profesoresisis2603/...Proporción Equivalencia Más grande que Conoce la...