Está en la página 1de 19
PSP 2.0 Parte 1 Revisiones de Diseño y Código Copyright © Carnegie Mellon University Carlos
PSP 2.0 Parte 1 Revisiones de Diseño y Código Copyright © Carnegie Mellon University Carlos

PSP 2.0

Parte 1

Revisiones de Diseño y Código

Copyright © Carnegie Mellon University

Carlos Mojica

Copyright © Carnegie Mellon University Carlos Mojica Contenido •¿Qué son las Revisiones? •¿Por qué

Contenido

© Carnegie Mellon University Carlos Mojica Contenido •¿Qué son las Revisiones? •¿Por qué debemos aplicar

•¿Qué son las Revisiones?

•¿Por qué debemos aplicar revisiones?

•La estrategia de revisión de PSP.

•Los principios de revisión de PSP.

•Los indicadores de revisión con PSP.

•Consideraciones al aplicar revisiones.

Copyright © Carnegie Mellon University

Carlos Mojica

¿Qué son las Revisiones?

¿Qué son las Revisiones?

¿Qué son las Revisiones?

Las revisiones son una manera en que personalmente, es decir, de forma individual examinamos nuestro trabajo.

+

Es un método que pertenece a una familia de técnicas de aseguramiento de la calidad:

 
 

-Inspecciones.

-Caminatas.

-Revisiones.

Todas estas técnicas tienen como objetivo encontrar y corregir los defectos de los productos lo más temprano posible dentro del proceso de desarrollo de software.

Copyright © Carnegie Mellon University

Carlos Mojica

Inspecciones

Inspecciones

Inspecciones

+ Las inspecciones fueron introducidas por Fagan en 1976 en IBM.

+ Las inspecciones siguen un proceso estructurado:

-Realizadas por pares. -No participan los Administradores (encargados de proyectos). -Cada participante tiene un rol definido. -Es necesaria una preparación. -El objetivo es encontrar problemas (No culpables).

Las inspecciones son útiles en los requerimientos, diseños, código, casos de prueba, planes, etc.

+

Copyright © Carnegie Mellon University

Carlos Mojica

Caminatas

Caminatas

Caminatas

+

Las caminatas siguen típicamente un formato de reunión:

-El desarrollador (autor) guía a la audiencia a través del producto. -Dentro de la audiencia se puede contar con pares, encargados de proyectos u otros compañeros interesados. -El objetivo es comunicar u obtener aprobación. -No se requiere preparación. -Pueden ser usadas para entrenar a los usuarios o miembros del equipo de desarrollo.

+

Las caminatas son más útiles en los requerimientos y el diseño.

Copyright © Carnegie Mellon University

Carlos Mojica

 
Revisiones

Revisiones

Revisiones

+

En una revisión personal:

-Los profesionales, en privado, revisan su trabajo (productos). -El objetivo es encontrar los defectos antes de la primera compilación y las pruebas. -Las revisiones son más efectivas cuando están estructuradas y son medidas.

Las revisiones pueden ser usadas con los requerimientos, diseños y código.

+

Copyright © Carnegie Mellon University

Carlos Mojica

¿Por qué hacer revisiones? [1/3]

¿Por qué hacer revisiones? [1/3]

¿Por qué hacer revisiones? [1/3]

Las estadísticas muestran que es mucho más eficiente encontrar defectos en las revisiones que en las pruebas:

+

-Típicamente en las pruebas unitarias sólo se encuentran entre el 2% y el 4% de los defectos en una hora. -Durante las revisiones de código típicamente se encuentran entre el 6% y el 10% de los defectos por hora. -Desarrolladores experimentados en revisiones pueden encontrar más del 70% de los defectos en un producto. -En las pruebas de diseño es raro exceder el 50% del yield .

+

Las estadísticas recabas de PSP muestran que a través de las

 

revisiones se encuentran entre 2 y 5 veces más defectos por hora

que con las pruebas unitarias.

Copyright © Carnegie Mellon University

Carlos Mojica

Frecuencia de Remoción de Defectos en una clase con PSP

Frecuencia de Remoción de Defectos en una clase con PSP

Frecuencia de Remoción de Defectos en una clase con PSP
 

30

Defectos/Hora

25

 

20

     
CR Def/H

CR Def/H30 Defectos/Hora 25   20       15 Def/Hr C 10 Def/Hr T 5  

15

Def/HrC

C

10

Def/HrT

T

5

 
 

0

 

1

2

3

4

5

6

7

8

9

10

 

Programa

 

Copyright © Carnegie Mellon University

 

Carlos Mojica

¿Por qué hacer revisiones? [2/3]+ Después de las pruebas unitarias, el costo de la remoción de defectos se incrementa

¿Por qué hacer revisiones? [2/3] + Después de las pruebas unitarias, el costo de la remoción

+ Después de las pruebas unitarias, el costo de la remoción de

defectos se incrementa (mucho):

-Durante las pruebas de integración y pruebas toma entre 10 y 40 horas de programador encontrar y corregir cada defecto. -Típicamente las inspecciones toman menos de una hora por defecto.

+ Algunos datos recogidos sobre inspecciones:

-Un yield de 80-90% a 25 minutos/defecto (O´Neil). -15 minutos/defecto contra 8 horas en pruebas (Phillips).

Copyright © Carnegie Mellon University

Carlos Mojica

¿Por qué hacer revisiones? [3/3]

¿Por qué hacer revisiones? [3/3]

¿Por qué hacer revisiones? [3/3]

Las razones para eliminar los defectos tan pronto como se pueda son:

+

-Cada revisión, inspección, compilación y prueba encuentran únicamente una fracción de los defectos. -Así, entre más limpio entre el código a una fase, más limpio será al salir.

+

La remoción temprana de defectos ahorra tiempo y dinero:

 

-Los defectos cuestan más y son más difíciles de encontrar en etapas posteriores del proceso de desarrollo. -Los defectos cuestan más y son más difíciles de encontrar después de la finalización del desarrollo.

Copyright © Carnegie Mellon University

Carlos Mojica

¿Por qué son eficientes las revisiones? [1/3]

¿Por qué son eficientes las revisiones? [1/3]

¿Por qué son eficientes las revisiones? [1/3]

+ En las pruebas:

-Se comienza con un problema. -Luego, hay que encontrar el defecto. -Hay que encontrar la solución. -Hay que implementar la solución. -Y, finalmente probar la solución.

 

+ Con las revisiones e inspecciones:

-Se ve (encuentra), el defecto. -Se encuentra la solución. -Se implementa la solución. -Y, finalmente, se revisa la solución.

Copyright © Carnegie Mellon University

Carlos Mojica

¿Por qué son eficientes las revisiones? [2/3]

¿Por qué son eficientes las revisiones? [2/3]

¿Por qué son eficientes las revisiones? [2/3]

En las pruebas, si el sistema produce un resultado inesperado entonces debes:

+

 

-Darte cuenta de lo que el programa está haciendo. -Detectar qué es lo que lo está causando. -Encontrar el lugar donde se encuentra el problema. -Detectar qué defecto está causando el comportamiento anómalo.

+ Estás buscando algo que no está planeado y que es inesperado.

+ Esto puede tomar muchííííííísimo tiempo.

 

Copyright © Carnegie Mellon University

Carlos Mojica

¿Por qué son eficientes las revisiones? [3/3]

¿Por qué son eficientes las revisiones? [3/3]

¿Por qué son eficientes las revisiones? [3/3]

+

Con las revisiones e inspecciones:

 

-Sigues tu propia lógica. -Cuando encuentras un defecto, sabes perfectamente donde

estás.

-Sabes lo que debe y no debe hacer el programa. -Entonces, inmediatamente sabes si es o no y por qué lo es o no un defecto. -Por lo tanto, estás en una mejor posición para encontrar e implementar una solución completa y efectiva.

Copyright © Carnegie Mellon University

Carlos Mojica

La estrategia de revisión de PSPCopyright © Carnegie Mellon University Carlos Mojica + El objetivo de PSP es producir la más

Carlos Mojica La estrategia de revisión de PSP + El objetivo de PSP es producir la

+ El objetivo de PSP es producir la más alta calidad en el programa en cada fase del proceso de desarrollo.

+ La estrategia de revisión para poder lograr este objetivo es:

-Recolectar datos sobre el proceso de revisión (tú proceso). -Estudiar estos dato. -Decidir qué te funciona mejor y lo que no. -Ajustar tu proceso de acuerdo a los resultados.

+ Este es un proceso de aprendizaje continuo, utilizando los datos de tu propio trabajo.

Copyright © Carnegie Mellon University

Carlos Mojica

Los Principios de Revisión de PSP

Los Principios de Revisión de PSP

Los Principios de Revisión de PSP

+

Las revisiones de PSP siguen un proceso disciplinado con:

 

-Criterios de entrada y salida definidos. -Una estructura de revisión. -Guías, listas de verificación y estándares.

Las metas sugeridas de PSP para las revisiones es encontrar cada defecto antes de la primera compilación o prueba.

+

+

Para lograr esta meta, debes:

-Usar estándares de codificación. -Usar criterios de completitud del diseño. -Medir y mejorar tu proceso de revisión.

 

Copyright © Carnegie Mellon University

Carlos Mojica

Principios de Revisión del Diseño

Principios de Revisión del Diseño

Principios de Revisión del Diseño

1. Producir diseños que puedan ser revisados.

 

2. Seguir una estrategia de revisión explícita.

3. Revisar el diseño por etapas.

4. Verificar que la lógica del diseño implementa correctamente los requerimientos.

Copyright © Carnegie Mellon University

Carlos Mojica

Producir diseños que puedan ser revisados

Producir diseños que puedan ser revisados

Producir diseños que puedan ser revisados

+ Un diseño que puede ser revisado incluye:

 
 

-Un contexto definido. -Una representación precisa. -Una estructura consistente y clara.

+ Esto sugiere que:

 

-El propósito y función del diseño esté claramente y explícitamente establecido. -Se tiene un criterio para determinar la completitud del

diseño.

 

-El diseño está estructurado en elementos lógicos.

Copyright © Carnegie Mellon University

Carlos Mojica

 
Seguir una Estrategia de Revisión

Seguir una Estrategia de Revisión

Seguir una Estrategia de Revisión

La estrategia de revisión especifica el orden en el cual se deben revisar los elementos del diseño:

+

-Esto depende de la estructura del producto. -Así, la estrategia de revisión debe ser considerada durante la revisión.

+

El objetivo debe ser producir un diseño que pueda ser:

 

-Revisado por etapas. -Probado por etapas. -Integrado por etapas.

Copyright © Carnegie Mellon University

Carlos Mojica

 
Revisar el diseño por etapas

Revisar el diseño por etapas

Revisar el diseño por etapas

+

Revisando por etapas se asegura que todos los tópicos

 

seleccionados son verificados cuidadosamente. Algunas etapas

para revisión sugeridas son:

-Verificar que todos los elementos han sido diseñados. -Verificar toda la estructura y flujo del programa. -Verificar la construcción lógica para asegurar su completitud. -Verificar la robustez. -Verificar el uso apropiado de las funciones, métodos, procedimientos, tipos y archivos.

 

Copyright © Carnegie Mellon University

Carlos Mojica

Verificar que la Lógica Implementa Correctamente los Requerimientos

Verificar que la Lógica Implementa Correctamente los Requerimientos

Verificar que la Lógica Implementa Correctamente los Requerimientos

Revisar los requerimientos para asegurar que cada función requerida está establecida en el diseño.

+

 

+

Verificar cuidadosamente buscando omisiones y fallas.

Copyright © Carnegie Mellon University

Carlos Mojica

Los Indicadores de Revisión con PSP+ Indicadores explícitos: -El tamaño del programa a ser revisado. -El tiempo de revisión. -El

Los Indicadores de Revisión con PSP + Indicadores explícitos: -El tamaño del programa a ser revisado.

+ Indicadores explícitos:

-El tamaño del programa a ser revisado. -El tiempo de revisión. -El número de defectos encontrados. -El número de defectos no encontrados (los escapados).

+ Indicadores derivados:

-Yield de revisión: % encontrado. -LOC revisadas por hora. -Defectos encontrados por KLOC. -Defectos encontrados por hora de revisión. - Leverage de revisión.

Copyright © Carnegie Mellon University

Carlos Mojica

Yield de Revisión [1/2]Copyright © Carnegie Mellon University Carlos Mojica + Yield: -Un indicador de la calidad de un

Mellon University Carlos Mojica Yield de Revisión [1/2] + Yield: -Un indicador de la calidad de

+ Yield:

-Un indicador de la calidad de un paso del proceso. -El porcentaje de defectos en el producto que fueron encontrados en tiempo de revisión. -Mide la efectividad del proceso. *Revisiones de diseño y código. *De todo el proceso – antes de las pruebas. *El proceso de desarrollo – incluyendo pruebas.

+ Yield (de una fase o el proceso completo) = 100 * (defectos encontrados) / (defectos encontrados + no encontrados)

Copyright © Carnegie Mellon University

Carlos Mojica

Yield de Revisión [2/2]+ El Yield no puede ser calculado hasta que todos los defectos hayan sido encontrados

Yield de Revisión [2/2] + El Yield no puede ser calculado hasta que todos los defectos

+ El Yield no puede ser calculado hasta que todos los defectos

hayan sido encontrados a través de las pruebas y uso del producto.

+ El Yield es útil en etapas tempranas del proceso si todos o la mayoría de los defectos son contados:

-Defectos en las revisiones de diseño y código. -Defectos en compilación. -Defectos en pruebas unitarias.

+ Usando los datos del proceso, los parámetros del control pueden ayudar para asegurar un yield alto en las revisiones.

Copyright © Carnegie Mellon University

Carlos Mojica

El Leverage en la Remoción de Defectos (DRL)

El Leverage en la Remoción de Defectos (DRL)

El Leverage en la Remoción de Defectos (DRL)

El DRL mide la efectividad relativa de un paso del proceso en la remoción de defectos.

+

El DRL es el número de defectos removidos por hora en un paso del proceso relativo al proceso base. -La base usual son las pruebas unitarias. -DRL(X/UT), es el DRL para la fase X con respecto a las pruebas unitarias.

+

+

El DRL es calculado como sigue:

DRL(X/UT) = (defectos/hora en la fase X) / (defectos/hora en las pruebas unitarias)

Copyright © Carnegie Mellon University

Carlos Mojica

Control del Proceso

Control del Proceso

Control del Proceso

Para controlar tu proceso, necesitas indicadores (métricas) que estén disponibles mientras estás estableciendo el proceso.

+

+

Mientras que el yield y el DRL son muy útiles, no se encuentran

disponibles hasta la finalización del proceso (finalización del desarrollo del proyecto).

+

Hace falta indicadores que:

 

-Se correlacionen con el Yield. -Estén disponibles a lo largo del desarrollo.

Copyright © Carnegie Mellon University

Carlos Mojica

Parámetros de Control Potenciales

Parámetros de Control Potenciales

Parámetros de Control Potenciales

+

Los parámetros de control potenciales para el Yield son:

 

-LOC revisadas por hora. -Defectos encontrados por hora. -Defectos encontrados por KLOC.

La investigación en PSP ha encontrado las siguientes correlaciones respecto al Yield:

+

-LOC/hora: -0.63, con una significancia > 0.005 -Defectos/hora: 0.14, con una significancia de 0.25 -Defectos/KLOC: 0.47, con una significancia de 0.01

+

Mientras ninguna es buena, LOC/hora es la mejor.

Copyright © Carnegie Mellon University

Carlos Mojica

Yield vs. LOC/hora de un estudiante de un estudiante

Yield vs. LOC/hora de un estudiante
80 70 60 50 40 30 20 10 0 0 200 400 600 800 LOC/hora
80
70
60
50
40
30
20
10
0
0
200
400
600
800
LOC/hora
Yield - % de defectos
removidos tempranamente

Copyright © Carnegie Mellon University

Carlos Mojica

Yield vs LOC/hora de un estudiante de un estudiante

Yield vs LOC/hora de un estudiante

Yield - % de Defectos Removidos Tempranamente

120

 

100

100

80

60

40

 
40  
40  

20

 

0

   

0

200

400

LOC/hora

600

Copyright © Carnegie Mellon University

Carlos Mojica

LOC Revisadas por Hora+ Los datos recolectados de los asistentes al curso de PSP tienen variaciones considerables. +

LOC Revisadas por Hora + Los datos recolectados de los asistentes al curso de PSP tienen

+ Los datos recolectados de los asistentes al curso de PSP tienen variaciones considerables.

+ Estos ejemplos muestran que las revisiones estructuradas pueden ser efectivas si:

-Siguen un procedimiento definido. -Usan listas de verificación. -Están adecuadas a los defectos de cada ingeniero.

+ Para PSP, un objetivo de control sugerido es revisar no más de 200 LOC/hora.

Copyright © Carnegie Mellon University

Carlos Mojica

Consideraciones al aplicar las Revisiones las Revisiones

Carlos Mojica Consideraciones al aplicar las Revisiones + Listas de Verificación. + Revisar antes o después

+ Listas de Verificación.

+ Revisar antes o después de compilar.

+ La relación entre las revisiones y las inspecciones.

Copyright © Carnegie Mellon University

Carlos Mojica

Listas de Verificación

Listas de Verificación

Listas de Verificación

Cuando se lleven tareas específicas, es difícil hacer bien más de una cosa al mismo tiempo.

+

La lista de verificación define los pasos de revisión en el orden sugerido para llevarlos a cabo.

+

Chequeando cada elemento de la lista de verificación, es más probable que se realice apropiadamente.

+

Establecer una lista de verificación personal que esté adecuada de acuerdo a tus defectos.

+

Copyright © Carnegie Mellon University

Carlos Mojica

Revisando antes de la Compilación [1/2]

Revisando antes de la Compilación [1/2]

Revisando antes de la Compilación [1/2]

Las revisiones de código en PSP deben llevarse a cabo antes de la primera compilación.

+

+

Las razones son:

-El tiempo de revisión es el mismo cuando se hace antes o después de la compilación. -Las revisiones de código sirven para encontrar defectos de sintaxis que el compilador omita. -Las revisiones de código del código compilado tienden a ser menos efectivas. -El compilador es igual de efectivo antes o después de las revisiones.

Copyright © Carnegie Mellon University

Carlos Mojica

Defectos en Compilación vs Defectos en Prueba de un estudiante Defectos en Prueba de un estudiante

Defectos en Compilación vs Defectos en Prueba de un estudiante

Defectos en Prueba

12 10 8 6 4 2 0
12
10
8
6
4
2
0

0

10

20

30

40

50

Defectos en Compilación

Copyright © Carnegie Mellon University

Carlos Mojica

Defectos en Compilación vs Defectos en Prueba de un estudiante Defectos en Prueba de un estudiante

Defectos en Compilación vs Defectos en Prueba de un estudiante

Defectos en Prueba

12 10 8 6 4 2 0
12
10
8
6
4
2
0

0

10

Defectos en Compilación

5

15

20

Copyright © Carnegie Mellon University

Carlos Mojica

Revisando antes de la Compilación [2/2]

Revisando antes de la Compilación [2/2]

Revisando antes de la Compilación [2/2]

PSP usa la compilación como un chequeo de la calidad de las revisiones. -Si se encuentran muchos defectos en la compilación es necesaria otra revisión. -Si la compilación es limpia, lo más probable es que se hayan encontrado la mayoría de los defectos.

+

+

Después de que hayas completado los ejercicios de PSP, quizá

desees recolectar datos de tus revisiones tanto antes como después de la compilación y determinar cuál te resulta más efectiva.

Copyright © Carnegie Mellon University

Carlos Mojica

Revisiones e InspeccionesCopyright © Carnegie Mellon University Carlos Mojica + El foco principal de las inspecciones debe ser

Mellon University Carlos Mojica Revisiones e Inspecciones + El foco principal de las inspecciones debe ser

+ El foco principal de las inspecciones debe ser encontrar aquellos problemas en los requerimientos y diseño que se te hayan pasado.

+ Cuando los programas tienen muchos defectos simples, los

inspectores se distraen y frecuentemente omiten problemas importantes.

+ Revisando el código primero:

-Provee un producto de calidad para la inspección. -Mostrar respeto por el tiempo de los inspectores. -Producir inspecciones de alta calidad.

Copyright © Carnegie Mellon University

Carlos Mojica

Asignación 7 + Leer el capítulo 8 del libro de texto del curso y generar

Asignación 7

Asignación 7 + Leer el capítulo 8 del libro de texto del curso y generar el

+ Leer el capítulo 8 del libro de texto del curso y generar el reporte R4, ver el apéndice D para los detalles de los requerimientos.

+ La asignación comprende:

-Diseñar un proceso para generar el reporte R4. -Incluir las fases de planeación y postmortem. -Planear el reporte R4. -Generar el reporte. -Entregar el reporte, el proceso y los datos del proceso.

Copyright © Carnegie Mellon University

Carlos Mojica

Copyright © Carnegie Mellon University Carlos Mojica Cosas a Recordar + Las revisiones de diseño y

Cosas a Recordar

© Carnegie Mellon University Carlos Mojica Cosas a Recordar + Las revisiones de diseño y código:

+ Las revisiones de diseño y código:

-Mejoran la calidad de los programas. -Ahorra tiempo de desarrollo.

+ Para realizar revisiones efectivas se debe:

-Establecer objetivos de revisión. -Seguir un proceso de revisión disciplinado. -Medir y mejorar la calidad de las revisiones.

Copyright © Carnegie Mellon University

Carlos Mojica