Transcript Procesos: TSP

Planeación de la Calidad
Rubby Casallas
Departamento de Ingeniería de Sistemas y
Computación
Uniandes
1
Procesos: TSP
Referencias

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
2
Procesos: TSP
Ejercicio

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?”
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
3
Procesos: TSP
“Las métricas de Software son una obscura y
esotérica especialidad”
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
4
Procesos: TSP
Agenda

Métricas de producto y de proceso de software
 GQM: Objetivos, Preguntas,Métricas
 Plan de Calidad
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
5
Procesos: TSP
Propósito

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
6
Procesos: TSP
Definiciones Básicas

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
Cuarto
Atributos
área
Mediciones
20x30 metros
Fase de Pruebas
tiempo invertido
2 horas
Aire
temperatura
20C
Software Process
CMM level
level 3
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
7
Procesos: TSP
Definiciones Básicas(2)
Y ahora:
Entidades
Atributos

Calidad
tamaño
Complejidad
Confiabilidad
Software
 Programa
 Programa
 Software
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
Mediciones
?
?
?
?
8
Procesos: TSP
Definiciones Básicas (3)
“Lo que no es medible, hágalo medible” Galileo

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.
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
9
Procesos: TSP
Alcance de las métricas de Software

Métricas para entender, controlar y mejorar
Recursos
Proceso
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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
10
Procesos: TSP
Alcance de las métricas de Software(2)

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
11
Procesos: TSP
Componentes de las métricas de software

Proceso
 Producto
 Recursos
 Atributos internos y externos
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
12
Procesos: TSP
Ejemplos: Productos
Entidad
Interno
Especificaciones tamaño, reutilización,
modularidad, corrección
sintáctica
Externo
Entendible
mantenibilidad
Diseños
tamaño, reuse, modularidad, calidad, complejidad
acoplamiento, funcionalidad mantenibilidad
Código
tamaño, reuse, complejidad
algorítmica, flujo de control
estructuración
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
confiabilidad,
mantenibilidad
13
Procesos: TSP
Ejemplos: Proceso
Entidad
Interno
Externo
Especificar
tiempo, esfuerzo, número calidad, costo, estabilidad
de cambios en los
efectividad
requerimientos
Pruebas
tiempo, esfuerzo, número costo, costo-efectividad
de defectos encontrados
Planeación
tiempo, esfuerzo, error de Precisión, costo
estimación
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
14
Procesos: TSP
Ejemplos: Recursos
Entidad
Interno
Externo
porsonal
Edad, salario
Productividad, experiencia
Software
Precio, tamaño
Uso (Usability),
Confiabilidad
Oficinas
Temperatura, tamaño, luz Confort, calidad
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
15
Procesos: TSP
Escalas de medición: Ejercicio

“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?
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
16
Procesos: TSP
Tipo de escala
Relaciones
Ejemplo de estadísticas
Nominal
Equivalencia
Moda
Frecuencia
Ordinal
Equivalencia
Más grande que
Media
percentile
Intervalo
Equivalencia
Más grande que
Conoce la diferencia en cualquier
intervalo
Media
Desviación estándar
Proporción
Equivalencia
Más grande que
Conoce la diferencia en cualquier
intervalo
Conoce la diferencia en cualquier
intervalo y escala
Media geométrica
Coeficiente de variación
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
17
Procesos: TSP
Agenda

Métricas de producto y de proceso de software
 GQM: Objetivos, Preguntas,Métricas
 Plan de Calidad
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
18
Procesos: TSP
GQM

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
19
Procesos: TSP
GQM

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
20
Procesos: TSP
GQM
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
21
Procesos: TSP
Ejemplo

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?
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
22
Procesos: TSP
Ejemplo cont.

Métricas:
 Quién usó el estándar?
 Proporción de codificadores usando el estándar
 Experiencia de los codificadotes 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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
23
Procesos: TSP
Definición de Objetivos

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
24
Procesos: TSP
Objetivos: Ejemplo

Propósito
 Caracterizar el proceso de inspección de software para poder
evaluarlo
 Evaluar la calidad del producto para mejorarla
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
25
Procesos: TSP
Objetivos: Ejemplo

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?
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
26
Procesos: TSP
Objetivos: Ejemplo

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
27
Procesos: TSP
GQM

Cuál es la relación entre métricas y madurez del proceso?
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
28
Procesos: TSP
CMM
Continuously
improving
process
Managed
(4)
Predictable
process
Standard,
consistent
process
Repeatable
(2)
Disciplined
process
Initial
(1)
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
Defined
(3)
Optimizing
(5)
Focus on continuous
process improvement
Process measured and
controlled
Process characterized,
fairly well understood
Can repeat previously mastered tasks
Unpredictable and poorly controlled
29
Procesos: TSP
Agenda

Métricas de producto y de proceso de software
 GQM: Objetivos, Preguntas,Métricas
 Plan de Calidad
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
30
Procesos: TSP
Plan de Calidad

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
31
Procesos: TSP
Plan de Calidad

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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
32
Procesos: TSP
Plan de Calidad
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.
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
33
Procesos: TSP
Plan de Calidad
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.
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
34
Procesos: TSP
Plan de Calidad
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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
35
Procesos: TSP
Plan de Calidad
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.
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
36
Procesos: TSP
Plan de Calidad
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.
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
37
Procesos: TSP
Plan de Calidad
4. Defectos por KLOC (cont ...)
 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).
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
38
Procesos: TSP
Defectos/KLOC
70
60
50
40
A
B
30
20
10
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
Pruebas de
Sistema
Integración
Pruebas
Unitarias
Compilación
Revisión
Código
Revision DD
0
39
Procesos: TSP
Plan de Calidad
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 !!
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
40
Procesos: TSP
Plan de Calidad
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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
41
Procesos: TSP
Plan de Calidad
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.
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
42
Procesos: TSP
Plan de Calidad
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 pseudo código por hora
 Código: < 200 líneas de código por hora
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
43
Procesos: TSP
Plan de Calidad
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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
44
Procesos: TSP
Plan de Calidad
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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
45
Procesos: TSP
Plan de Calidad
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
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
46
Procesos: TSP
Plan de Calidad
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%
Rubby Casallas G.
Departamento de Ingeniería de Sistemas
Universidad de los Andes
47