Sesion de capacitacion sobre Personal Software Process (TM) / Español / 2014.02. NOTA: Todas la marcas son propiedad de sus respectivos dueños.

1. SESIÓN 03: CALIDAD
Indicar que prevenir los errores es mejor que cometerlos en fases posteriores. Además que los errores
funcionales son los mas costosos de encontrar. Para ello, incluyendo fases de
revisión/inspección/walkthrough es más efectivo. Ir extrayendo un checklist a partir del análisis de
errores cometidos históricamente. Hacer comparativa entre Appraisal Vs Test.
1

2. 2

3. 3

4. 4

5. 5

6. 6

7. 7

8. 8

9. 9

10. 10

11. 11

12. 12

13. PSP Quality focus [10min]
Calidad: Lo que el usuario quiere
En el proceso, que permita basicamente producir un resultado “Bug free”
Que no afecten la operación, ni causen inconvenientes,
Atributos de calidad del software (ilities)
Functionality: lo que el usuario quiere: condiciones normales y anormales, pero no solo eso
Performance (desempeño):
Usability (claro): para el usuario final
Reliable (confiable/confidence): confiable en los resultados y que queden capturados los datos
13

14. Al principio del proyecto se piensa que todo es perfecto, pero se van introduciendo pequeños
“pescaditos” que representan los defectos en las primeras fases. Luego estos pescaditos van
madurando mas y mas. Al final del proyecto ya son unas ballenas o tiburones que a veces no se pueden
pescar ni siquiera. Parecen monstruos que no se pueden eliminar (“no silver bullet”/”no hay balas de
plata”).
Ver: http://www.scribd.com/doc/44038107/No-Silver-Bullets-Espanol
• Dentro de desarrollo, se cometen errores: [los que comete la persona al seguir los procesos (o la
metodologia)]
• Defectos ( los que se inyectan al producto: el software no tiene errores sino defctos)
• Fallas (los que percibe o reporta [ej: el carro no está funcionando bien]. quien lo recibe debe
encontrar el defecto asociado para poderlo corregir)
Manejar los defectos antes de que aparezcan
• Remover los defectos
• Analizar las causas de los defectos
• Prevenir la aparición de defectos,
Pero cómo se encuentran los defectos de toda índole, cómo se encuentran los defectos en el área azul
de la figura hoy en día?: A través de Testing
• La industria del software es la única tecnología moderna que deja que los problemas aparezcan en
testing para manejar la calidad
• Si se sigue así, los cronogramas nunca se cierran, no se puede predecir cuándo terminar, se termin
con productos pobres en términos de calidad.
• Incluso existe una fase que se llama “estabilización” para corregir problemas que se debieron
detectar antes.
Ejemplo: un programa de 50mil LOC, con 25 defectos/KLOC, va a tener: 1250 defectos en total, y que en
promedio se pueda solucionar cada bug con prueba y todo en 10 horas, serán 12500 horas de trabajo.
Calcular los años de ésta tarea
Se deben encontrar métodos más eficientes, dentro de los métodos existentes para capturar defectos
encontramos:
• Unit, Integration, System Test
• Reviews /Inspections /Walkthroughs (ver siguiente slide): se ejecutan antes de compilar, requieren
intervencion humana.
14

15. • Compiling/Static code analysis (Lint)
[APPRAISAL VS TEST]
Appraisal (valoracion previa, enfoque preventivo): analizar la logica de procesamiento
y encontrar el defecto. Saber en qué punto de la lógica se presentó el defecto:
manipular la logica del programa y poder corregir un error funcional
Test (prueba unitaria, enfoque reactivo): encontrar el error cuando se totea el
programa
14

16. En cuanto a especificación, se entregan unos requerimientos que van evolucionando hasta ser vasos de
uso y prueba.
Sin embargo debemos estar preparados para controlar lo que sucede internamente en el software que
hacemos: prevenir.
Verification: evaluar si cumple los requerimientos
Validation: asegurar que cumple la necesidad
Ver Modelo en V de ITIL> Transición de Servicios:
(http://itilv3.osiatis.es/transicion_servicios_TI/gestion_entregas_despliegues/planificacion_entregas.ph
p)
15

17. Las estrategias de revisión son el método más efectivo para mejorar la calidad. Algunos métodos o
estrategias son los siguientes:
• Personal review: el individuo que hace la revisión examina su código, con el fin de encontrar tantos
errores como sea posible. Es clave usar un checklist, derivado de las revisíones. Es aconsejable tomar
un descanso antes de iniciar la revisión y revisar uno a uno los puntos del checklist (OJO: no todos a
la vez). La idea es que se capturen también los errores más obvios.
• Inspection: el equipo o algún otro integrante revisa el producto. No se trata entonces de discutir los
problemas identificados sino que se colaborar en pro de corregirlos
• Walkthroughs: un diseño de un producto presentado ante una audiencia
• Debe existir una responsabilidad profesional respecto a las revisiones:
• Antes de pedir una inspeccion, se deben eliminar tantos defectos como sea posible: tener respeto
por el tiempo del otro
• En lugar de concentrarse en errores obvios, el par que revisa, observará que la lógica de negocio
fluya más que todo.
16

18. Principios de quality management, son expuestos en el slide:
• La calidad de un sistema es determinada por la calidad del peor de sus compoentes
[>] cuando se tiene un error en el que no funciona la aplciación, el usuario dice: este sistema no sirve
(no dice, el componente x no funciona)
• La calidad de un producto es governada por los individuos que lo desarrolaron
• La caliad de un producto es governada por el proceso usado para desarrollarlo
• La clave será entonces los skills, acuerdos y disciplina a nivel de proceso personal, para mejorar la
calidad del producto
17

19. Medidas de Calidad [20min]
Psp tiene varias medidas de calidad relacionadas con calidad
Las siguientes medidas de calidad se observan en PSP:
• Yield: es la efectividad de “cazar defectos”
• Yield de Fase: porcentaje de defectos en un programa, que son removidos en una fase
particular
• Yield de Proceso: pordentaje de defectos removidos antes de entrar a la fase de compilacion
• Appraisal Cost of quality (Appraisal COQ): porcentaje del tiempo de desarrollo gastado en prevención
de errores
• Failure COQ: porcentaje de tiempo gastado en fases reactivas (compilacion y testing)
• Appraisal to Failure Ratio (AF/R) = = Appraisal COQ / Failure COQ
• DefectRemovalRate [FASE-X] = Numero de defectos encontrados por hora en esa fase
• DRL [FASE-X/FASE-Y] (Defect removal leverage)= comparación del DefectRemovalRate entre 2 fases
cómo calcular los defectos por KLOC
Cómo calcular el DRL (defect removal leverage)
18

20. 19

21. 20

22. Quality Profile & Performance [40 min]:
• permite evaluar un perfil de calidad, saber cómo calcularlo y extraerlo
• Es derivado de 5 items que caracterizan la calidad del proceso de software, y que se normalizan en el
rango [0..1] y se presentan en un gráfico radial o de kiviat.
• Existe una medida que computa los 5 elementos y se llama el Indice-PQI. Un valor en este cómputo
menor a 0.5 significa que el componente puede tener una muy baja calidad.
• Si tenemos más de un componente, se toma el producto del Indice-PQI de todos los componentes.
21

23. Assignment 03: [20min] Checklists para fases DLDR y CR
Para aprender PSP2
• Hacer checklist: con los resultados de los assignments anteriores.
• La idea es definir un checklist de revision de codigo.
• Indicar que también existen checlists de revision del diseño.
Enviar el assignment: Archivo .zip con:
• Documento de checklist para DLDR
• Documento de checklist para CR
22

24. Tutorial: PSP2 [20min]
(1) Sacar una copia de los datos en el processdashboard (C/Tools/SaveDataBackup +
C/Tools/OpenDataset)
(2) 2 fases nuevas se adicionan al proceso PSP (DLDR,CR). Además se incorporan al proceso las
checklists. Se adiciona el plan de calidad
En el plan de calidad se estima el tiempo para ejecutar estas fases
Se estiman los defectos que se van a encontrar en dichas fases
Se disminuyen los defectos encontrados en las fases de UT y COMP
Se disminuye el tiempo estimado en UT acorde a la eficiencia esperada para remover defectos
en fases de DLDR y C
(3) Iniciar como en las fases anteriores: iniciar con la fase de planeación, cree un diseño conceptual en
la fase de planeacin y entrelo en el SizeEstimationTemplate. abra el Wizard de PROBE.
(4) Requerimeintos: camcular media y desviacion. Usar losta encadenada.
(5) Seguir la guia de estimar los tiempos de revision:
DLDR = 0.5* DLD
CR = 0.5 * CODE
Ejemplo: se gastan 32 minutos en DLD y 40 min en CODE, DLDR=16min,CR=20min
(6) La idea es reducir el tiempo de UT, eliminando los defectos que se produjeron antes de UT
(7) Seguir los puntos de la pagina 13 del tutorial para elegir un yield-target
Digamos que se escoje un Yield de 0.75
El primer paso es Calcular NumDefRemovidos (DLDR) .Para ello multiplicar Yield por defectos
inyectados en DLD
-----------> Yield (FaseX) = NumDefRemovidos (FaseX) /NumDefAEntradaFaseX
-----------> Yield (DLRD) = NumDefRemovidos (DLDR) /NumDefAEntradaFaseDLDR
-----------> Yield (DLRD) = NumDefRemovidos (DLDR) /NumDefInyectadosDLD
-----------> 0.75
= x / 3 . x = 2.25
-----------> El valor resultante es el NumDefRemovidos (DLDR)
El segundo es Calcular NumDefectosRemovidos (CR). Para ello:
-----------> x = (NumDefInyectadosDLD - NumDefRemovidos (DLDR) + NumDefInyectadosCODE) *
Yield(CR) .
-----------> x = (3 – 2.25 + 7) * 0.75 = (7.75)*(0.75) = 5.81
Ello debido a que el despejar de la formula de yiel de fase X da este resultado.
23

25. -----------> Yield (FaseX) = NumDefRemovidos (FaseX) /NumDefAEntradaFaseX
El tercero es calcular los errors restantes para obtener los errores que
corregirá la fase de UT . Para ello
-----------> x = (NumDefInyectadosDLD + NumDefInyectadosCODE) –
(NumDefRemovidos (DLDR) + NumDefRemovidos (DLDR)) .
Verificar que la suma final permanece igual-
23