SlideShare ist ein Scribd-Unternehmen logo
1 von 47
Planeación de la Calidad 
1 
Rubby Casallas 
Departamento de Ingeniería de Sistemas y 
Computación 
Uniandes
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 Sistemas 
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 Sistemas 
4 
Procesos: TSP 
“Las métricas de Software son una obscura y 
esotérica especialidad”
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
5 
Procesos: TSP 
Agenda 
· Métricas de producto y de proceso de software 
· GQM: Objetivos, Preguntas,Métricas 
· Plan de Calidad
· 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 
Procesos: TSP 
Propósito 
6
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
10 
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 
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
Componentes de las métricas de software 
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
12 
Procesos: TSP 
· Proceso 
· Producto 
· Recursos 
· Atributos internos y externos
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 Sistemas 
Ejemplos: Proceso 
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: Recursos 
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
19 
Procesos: TSP 
· Hechos: 
GQM 
 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 
20 
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 
21 
Procesos: TSP 
GQM
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
Procesos: TSP 
Ejemplo 
22 
· 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 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
28 
Procesos: TSP 
GQM 
· Cuál es la relación entre métricas y madurez del proceso?
Process measured and 
controlled 
Process characterized, 
fairly well understood 
Can repeat previously mastered tasks 
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 
Focus on continuous 
process improvement
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
34 
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 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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).
70 
60 
50 
40 
30 
20 
10 
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
39 
Procesos: TSP 
Defectos/KLOC 
0 
Revision DD 
Revisión 
Código 
Compilación 
Pruebas 
Unitarias 
Integración 
Pruebas de 
Sistema 
A 
B
Rubby Casallas G. 
Departamento de Ingeniería de Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
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 Sistemas 
46 
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 
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%

Weitere ähnliche Inhalte

Was ist angesagt?

Definición de planificación de proyectos de software presentación
Definición de planificación de proyectos de software presentaciónDefinición de planificación de proyectos de software presentación
Definición de planificación de proyectos de software presentaciónOvidio Fernando Hernández Albarran
 
aseguramiento de la calidad de software acs
aseguramiento de la calidad de software acsaseguramiento de la calidad de software acs
aseguramiento de la calidad de software acsMARCO POLO SILVA SEGOVIA
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software Brihany Rossell
 
4-IEEE-829.pptx
4-IEEE-829.pptx4-IEEE-829.pptx
4-IEEE-829.pptxngelTovar3
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assuranceRizky Munggaran
 
Software quality iso-cmm-psp
Software quality  iso-cmm-pspSoftware quality  iso-cmm-psp
Software quality iso-cmm-pspGurbakash Phonsa
 
Team Software Process (TSP)
Team Software Process (TSP)Team Software Process (TSP)
Team Software Process (TSP)Juan Garcia
 
EstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al SoftwareEstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al Softwareeduardo89
 
SDLC or Software Development Life Cycle
SDLC or Software Development Life CycleSDLC or Software Development Life Cycle
SDLC or Software Development Life CycleJyothi Vbs
 
PORTAFOLIO DE SERVICIOS MOPROSOFT - NYCE
PORTAFOLIO DE SERVICIOS MOPROSOFT - NYCEPORTAFOLIO DE SERVICIOS MOPROSOFT - NYCE
PORTAFOLIO DE SERVICIOS MOPROSOFT - NYCEjpalma200680
 
Introducción, Niveles y Evaluación CMMI
Introducción, Niveles y Evaluación CMMIIntroducción, Niveles y Evaluación CMMI
Introducción, Niveles y Evaluación CMMIJuan F. Padilla
 
Chapter 8 software testing
Chapter 8 software testingChapter 8 software testing
Chapter 8 software testingdespicable me
 

Was ist angesagt? (20)

Reingeniería
ReingenieríaReingeniería
Reingeniería
 
Definición de planificación de proyectos de software presentación
Definición de planificación de proyectos de software presentaciónDefinición de planificación de proyectos de software presentación
Definición de planificación de proyectos de software presentación
 
aseguramiento de la calidad de software acs
aseguramiento de la calidad de software acsaseguramiento de la calidad de software acs
aseguramiento de la calidad de software acs
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
4-IEEE-829.pptx
4-IEEE-829.pptx4-IEEE-829.pptx
4-IEEE-829.pptx
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
 
Ieee 12207
Ieee 12207Ieee 12207
Ieee 12207
 
Software quality iso-cmm-psp
Software quality  iso-cmm-pspSoftware quality  iso-cmm-psp
Software quality iso-cmm-psp
 
Team Software Process (TSP)
Team Software Process (TSP)Team Software Process (TSP)
Team Software Process (TSP)
 
EstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al SoftwareEstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al Software
 
Calidad Del Software
Calidad Del SoftwareCalidad Del Software
Calidad Del Software
 
SDLC or Software Development Life Cycle
SDLC or Software Development Life CycleSDLC or Software Development Life Cycle
SDLC or Software Development Life Cycle
 
PORTAFOLIO DE SERVICIOS MOPROSOFT - NYCE
PORTAFOLIO DE SERVICIOS MOPROSOFT - NYCEPORTAFOLIO DE SERVICIOS MOPROSOFT - NYCE
PORTAFOLIO DE SERVICIOS MOPROSOFT - NYCE
 
Introducción CMMI
Introducción CMMIIntroducción CMMI
Introducción CMMI
 
Introducción, Niveles y Evaluación CMMI
Introducción, Niveles y Evaluación CMMIIntroducción, Niveles y Evaluación CMMI
Introducción, Niveles y Evaluación CMMI
 
Estándar IEEE-12207
Estándar IEEE-12207Estándar IEEE-12207
Estándar IEEE-12207
 
ISTQB Advanced Test Manager Training 2012 - Testing Process
ISTQB Advanced Test Manager Training 2012 - Testing Process ISTQB Advanced Test Manager Training 2012 - Testing Process
ISTQB Advanced Test Manager Training 2012 - Testing Process
 
Herramientas case
Herramientas caseHerramientas case
Herramientas case
 
Chapter 8 software testing
Chapter 8 software testingChapter 8 software testing
Chapter 8 software testing
 
Calidad en el desarrollo del software
Calidad en el desarrollo del softwareCalidad en el desarrollo del software
Calidad en el desarrollo del software
 

Ähnlich wie Metricas

Ähnlich wie Metricas (20)

S4-CDSQA.pptx
S4-CDSQA.pptxS4-CDSQA.pptx
S4-CDSQA.pptx
 
Clase04 16092014
Clase04 16092014Clase04 16092014
Clase04 16092014
 
Métricas de calidad de software
Métricas de calidad de softwareMétricas de calidad de software
Métricas de calidad de software
 
Métricas de calidad de software
Métricas de calidad de softwareMétricas de calidad de software
Métricas de calidad de software
 
12 introduccion a las metricas
12 introduccion a las metricas12 introduccion a las metricas
12 introduccion a las metricas
 
Calidad del Software
Calidad del SoftwareCalidad del Software
Calidad del Software
 
metricas.pdf
metricas.pdfmetricas.pdf
metricas.pdf
 
13 Gesein Solo Pruebas 2009
13 Gesein Solo Pruebas 200913 Gesein Solo Pruebas 2009
13 Gesein Solo Pruebas 2009
 
Catedra psp
Catedra pspCatedra psp
Catedra psp
 
Metricas de software
Metricas de softwareMetricas de software
Metricas de software
 
Calidad de software Unidad 3
Calidad de software Unidad 3Calidad de software Unidad 3
Calidad de software Unidad 3
 
Capitulo8 rita expo
Capitulo8 rita expoCapitulo8 rita expo
Capitulo8 rita expo
 
Team Software Process (TSP)
Team Software Process  (TSP)Team Software Process  (TSP)
Team Software Process (TSP)
 
capitulo8_rita_expo.ppt
capitulo8_rita_expo.pptcapitulo8_rita_expo.ppt
capitulo8_rita_expo.ppt
 
capitulo8_rita_expo.ppt
capitulo8_rita_expo.pptcapitulo8_rita_expo.ppt
capitulo8_rita_expo.ppt
 
Modelo Cmmi 7
Modelo Cmmi 7Modelo Cmmi 7
Modelo Cmmi 7
 
Taller metricas
Taller metricasTaller metricas
Taller metricas
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 

Metricas

  • 1. Planeación de la Calidad 1 Rubby Casallas Departamento de Ingeniería de Sistemas y Computación Uniandes
  • 2. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 3. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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?”
  • 4. Rubby Casallas G. Departamento de Ingeniería de Sistemas 4 Procesos: TSP “Las métricas de Software son una obscura y esotérica especialidad”
  • 5. Rubby Casallas G. Departamento de Ingeniería de Sistemas 5 Procesos: TSP Agenda · Métricas de producto y de proceso de software · GQM: Objetivos, Preguntas,Métricas · Plan de Calidad
  • 6. · 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 Procesos: TSP Propósito 6
  • 7. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 8. Rubby Casallas G. Departamento de Ingeniería de Sistemas 8 Procesos: TSP Definiciones Básicas(2) Y ahora: Entidades Atributos Mediciones · Software Calidad ? · Programa tamaño ? · Programa Complejidad ? · Software Confiabilidad ?
  • 9. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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.
  • 10. Rubby Casallas G. Departamento de Ingeniería de Sistemas 10 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
  • 11. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 12. Componentes de las métricas de software Rubby Casallas G. Departamento de Ingeniería de Sistemas 12 Procesos: TSP · Proceso · Producto · Recursos · Atributos internos y externos
  • 13. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 14. Rubby Casallas G. Departamento de Ingeniería de Sistemas Ejemplos: Proceso 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
  • 15. Ejemplos: Recursos Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 16. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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?
  • 17. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 18. Rubby Casallas G. Departamento de Ingeniería de Sistemas 18 Procesos: TSP Agenda · Métricas de producto y de proceso de software · GQM: Objetivos, Preguntas,Métricas · Plan de Calidad
  • 19. Rubby Casallas G. Departamento de Ingeniería de Sistemas 19 Procesos: TSP · Hechos: GQM  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
  • 20. Rubby Casallas G. Departamento de Ingeniería de Sistemas 20 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
  • 21. Rubby Casallas G. Departamento de Ingeniería de Sistemas 21 Procesos: TSP GQM
  • 22. Rubby Casallas G. Departamento de Ingeniería de Sistemas Procesos: TSP Ejemplo 22 · 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?
  • 23. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 24. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 25. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 26. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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?
  • 27. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 28. Rubby Casallas G. Departamento de Ingeniería de Sistemas 28 Procesos: TSP GQM · Cuál es la relación entre métricas y madurez del proceso?
  • 29. Process measured and controlled Process characterized, fairly well understood Can repeat previously mastered tasks Rubby Casallas G. Departamento de Ingeniería de Sistemas 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 Focus on continuous process improvement
  • 30. Rubby Casallas G. Departamento de Ingeniería de Sistemas 30 Procesos: TSP Agenda · Métricas de producto y de proceso de software · GQM: Objetivos, Preguntas,Métricas · Plan de Calidad
  • 31. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 32. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 33. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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.
  • 34. Rubby Casallas G. Departamento de Ingeniería de Sistemas 34 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.
  • 35. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 36. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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.
  • 37. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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.
  • 38. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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).
  • 39. 70 60 50 40 30 20 10 Rubby Casallas G. Departamento de Ingeniería de Sistemas 39 Procesos: TSP Defectos/KLOC 0 Revision DD Revisión Código Compilación Pruebas Unitarias Integración Pruebas de Sistema A B
  • 40. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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 !!
  • 41. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 42. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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.
  • 43. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 44. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 45. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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
  • 46. Rubby Casallas G. Departamento de Ingeniería de Sistemas 46 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
  • 47. Rubby Casallas G. Departamento de Ingeniería de Sistemas 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%