1

PLANEACIÓN DE LA
CALIDAD
Rubby Casallas
Departamento de Ingeniería de Sistemas y Computación
Universidad de Los Andes
 Referencias
2

 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
 Ejercicio
3

 ¿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 Software
4

“Las métricas de Software son una obscura

y esotérica especialidad”
 Agenda
5

 Métricas de producto y de proceso de software

 GQM: Objetivos, Preguntas, Métricas
 Plan de Calidad
 Agenda
6

 Métricas de producto y de proceso de software

 GQM: Objetivos, Preguntas, Métricas
 Plan de Calidad
 Propósito
7

 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ásicas
8

 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

Recursos Producto
Proceso

• 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
software
13

 Proceso
 Producto
 Recursos
 Atributos internos y externos
 Ejemplos: Productos
14

Entidad Interno Externo

tamaño, reutilización, entendible,
Especificaciones modularidad, corrección
sintáctica mantenibilidad

tamaño, reuse, modularidad, calidad, complejidad

Diseños
acoplamiento, funcionalidad mantenibilidad

tamaño, reuse, complejidad

confiabilidad,
Código algorítmica, flujo de control
mantenibilidad
estructuración
 Ejemplos: Proceso
15

Entidad Interno Externo

tiempo, esfuerzo, número de calidad, costo, estabilidad
Especificar cambios en los
requerimientos efectividad

tiempo, esfuerzo, número de costo, costo-efectividad

Pruebas
defectos encontrados

tiempo, esfuerzo, error de

Planeación precisión, costo
estimación
 Ejemplos: Recursos
16

Entidad Interno Externo

Personal edad, salario productividad, experiencia

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

Oficinas temperatura, tamaño, luz confort, calidad

 Escalas de medición: Ejercicio
17

 En un estudio reciente sobre calidad de los procesos en las

organizaciones, se encontró que:
 15 organizaciones fueron nivel 1
 20 organizaciones fueron nivel 2
 9 organizaciones fueron nivel 3
 6 organizaciones fueron nivel 4
 y 1 organización fue nivel 5

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

2.17?
 Ejemplo de
Tipo de escala Relaciones
estadísticas

Moda
Nominal Equivalencia
Frecuencia

Equivalencia Media
Ordinal
Más grande que Percentil
Equivalencia
Más grande que Media
Intervalo Conoce la diferencia en cualquier Desviación estándar
intervalo

Equivalencia
Más grande que
Conoce la diferencia en cualquier Media geométrica
Proporción intervalo Coeficiente de
Conoce la diferencia en cualquier variación
intervalo y escala
 Agenda
19

 Métricas de producto y de proceso de software

 GQM: Objetivos, Preguntas, Métricas
 Plan de Calidad
 GQM
20

 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
 GQM
21

 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
 GQM
22
 Ejemplo
23

 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 Objetivos
25

 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):
 Factoresde proceso, la gente, los métodos, las
herramientas, las restricciones
 Objetivos: Ejemplo
26

 Propósito

 Caracterizar el proceso de inspección de software para

poder evaluarlo
 Evaluar la calidad del producto para mejorarla
 Objetivos: Ejemplo
27

 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?
 Objetivos: Ejemplo
28

 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

 GQM
29

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

proceso?
 CMM
30

Continuously Optimizing Focus on continuous

improving (5) process improvement
process

Managed Process measured and

Predictable (4) controlled
process

Defined Process characterized,

Standard,
consistent (3) fairly well understood
process

Repeatable
Disciplined (2) Can repeat previously mastered tasks
process

Initial
(1)
Unpredictable and poorly controlled
 Agenda
31

 Métricas de producto y de proceso de software

 GQM: Objetivos, Preguntas, Métricas
 Plan de Calidad
 Plan de Calidad
32

 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
 Plan de Calidad (3)
34

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
 Plan de Calidad (4)
35

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.
 Plan de Calidad (5)
36

3. Defectos por página

 Muestrael número de defectos removidos de cada

página del documento de requerimientos y del
diseño de alto nivel
 Plan de Calidad (6)
37

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
 Plan de Calidad (7)
38

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
 Plan de Calidad (8)
39

4. Defectos por KLOC (cont...)

 Laexperiencia 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)
 4.

0
10
20
30
40
50
60
70
Revision DD

Revisión
Código

Compilación

Pruebas
Unitarias
Plan de Calidad (9)
Defectos por KLOC (cont...)

Integración

Pruebas de
Sistema
B
A

40
 Plan de Calidad (10)
41

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
 Plan de Calidad (11)
42

6. Proporción de tiempos de desarrollo

 Segúnla 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
 Plan de Calidad (12)
43

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
 Plan de Calidad (13)
44

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
 Plan de Calidad (14)
45

9. Porcentaje de inyección de defectos

 Deacuerdo 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
 Plan de Calidad (15)
46

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
 Plan de Calidad (16)
47

11. Rendimiento (yield) de fase

 Porcentajede 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%
 Sepuede calcular sólo cuando se ha terminado el
programa y se sabe el número total de defectos
 Plan de Calidad (17)
48

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%