Date post: | 19-Jun-2015 |
Category: |
Software |
Upload: | rut-cruz-s |
View: | 101 times |
Download: | 0 times |
1
Planeación de la Calidad
Rubby Casallas
Departamento de Ingeniería de Sistemas y Computación
Uniandes
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 2
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 SistemasUniversidad de los Andes 3
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 SistemasUniversidad de los Andes 4
Procesos: TSP
“Las métricas de Software son una obscura y esotérica especialidad”
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 5
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 SistemasUniversidad de los Andes 6
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 SistemasUniversidad de los Andes 7
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 Atributos Mediciones
Cuarto área 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 SistemasUniversidad de los Andes 8
Procesos: TSP
Definiciones Básicas(2)
Y ahora:
Entidades Atributos Mediciones
Software Calidad ? Programa tamaño ? Programa Complejidad ? Software Confiabilidad ?
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 9
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 SistemasUniversidad de los Andes 10
Procesos: TSP
Alcance de las métricas de Software
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
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 11
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 SistemasUniversidad de los Andes 12
Procesos: TSP
Proceso Producto Recursos Atributos internos y externos
Componentes de las métricas de software
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 13
Procesos: TSP
Ejemplos: Productos
Entidad Interno Externo
Especificaciones tamaño, reutilización, modularidad, corrección sintáctica
Entendible
mantenibilidad
Diseños tamaño, reuse, modularidad, acoplamiento, funcionalidad
calidad, complejidad
mantenibilidad
Código tamaño, reuse, complejidad algorítmica, flujo de control estructuración
confiabilidad, mantenibilidad
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 14
Procesos: TSP
Entidad Interno Externo
Especificar tiempo, esfuerzo, número de cambios en los requerimientos
calidad, costo, estabilidad
efectividad
Pruebas tiempo, esfuerzo, número de defectos encontrados
costo, costo-efectividad
Planeación tiempo, esfuerzo, error de estimación
Precisión, costo
Ejemplos: Proceso
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 15
Procesos: TSP
Entidad Interno Externo
porsonal Edad, salario Productividad, experiencia
Software Precio, tamaño Uso (Usability), Confiabilidad
Oficinas Temperatura, tamaño, luz Confort, calidad
Ejemplos: Recursos
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 16
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 SistemasUniversidad de los Andes 17
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 SistemasUniversidad de los Andes 18
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 SistemasUniversidad de los Andes 19
Procesos: TSP
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
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 20
Procesos: TSP
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
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 21
Procesos: TSP
GQM
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 22
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 SistemasUniversidad de los Andes 23
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 SistemasUniversidad de los Andes 24
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 SistemasUniversidad de los Andes 25
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 SistemasUniversidad de los Andes 26
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 SistemasUniversidad de los Andes 27
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 SistemasUniversidad de los Andes 28
Procesos: TSP
Cuál es la relación entre métricas y madurez del proceso?
GQM
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 29
Procesos: TSP
CMM
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 andcontrolled
Focus on continuousprocess improvement
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 30
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 SistemasUniversidad de los Andes 31
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 SistemasUniversidad de los Andes 32
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 SistemasUniversidad de los Andes 33
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 SistemasUniversidad de los Andes 34
Procesos: TSP
Plan de Calidad2. 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 SistemasUniversidad de los Andes 35
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 SistemasUniversidad de los Andes 36
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 SistemasUniversidad de los Andes 37
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 SistemasUniversidad de los Andes 38
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 SistemasUniversidad de los Andes 39
Procesos: TSP
Defectos/KLOC
0
10
20
30
40
50
60
70
Re
vis
ion
DD
Re
vis
ión
Có
dig
o
Co
mp
ilac
ión
Pru
eb
as
Un
ita
ria
s
Inte
gra
ció
n
Pru
eb
as
de
Sis
tem
a
A
B
Rubby Casallas G.Departamento de Ingeniería de SistemasUniversidad de los Andes 40
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 SistemasUniversidad de los Andes 41
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 SistemasUniversidad de los Andes 42
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 SistemasUniversidad de los Andes 43
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 SistemasUniversidad de los Andes 44
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 SistemasUniversidad de los Andes 45
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 SistemasUniversidad de los Andes 46
Procesos: TSP
Plan de Calidad11. 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 SistemasUniversidad de los Andes 47
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%