Calidad de Software - PSP

Personal Software
Process
(Desarrollo Software
Personal)
Principios PSP



la calidad de un sistema software está
condicionada por la calidad del peor de sus
componentes.
la calidad de un componente software está
condicionada por el individuo que lo desarrolló.
Está condicionada por el
conocimiento
 disciplina
 compromiso
del desarrollador

Principios PSP (cont...)




Todo profesional software debería conocer su
propio rendimiento.
Debería medir, seguir/controlar y analizar su
trabajo.
Debería aprender de las variaciones de su
rendimiento.
Debería incorporar esas lecciones a su manera
personal de hacer las cosas.
¿Qué proporciona el PSP?

Un PSP estable permite




estimar y planificar el trabajo
cumplir los compromisos
resistir a presiones de compromiso no razonables
Con un PSP estable, también se podrá


comprender nuestras capacidades
estar mas posibilitado para mejorar
¿Qué te proporciona PSP?
(cont...)

Un PSP también proporciona



Una base probada para desarrollo y práctica
de las disciplinas personales de la industria.
Una disciplina que muestra como mejorar el
proceso personal.
Los datos para mejorar de manera continua la
productividad, calidad, y el grado de predicción
de trabajo
¿Qué es un PSP?

Un PSP es un proceso personal para desarrollar
software.





pasos definidos
formularios
estándares
Un PSP es un marco de trabajo de medición y
análisis que nos ayuda a caracterizar nuestro
proceso.
Es también un procedimiento definido para
ayudar a mejorar nuestro rendimiento.
El flujo de Proceso del PSP
Requisitos
Proceso PSP0
Planificación
Desarrollo
Guiones
de proceso
Diseño
Código
Compila
Pruebas
Postmortem
Producto acabado
Logs de
tiempos
y
defectos
Resumen
Plan
Proyecto y proceso
El PSP



El PSP es un proceso diseñado para uso
individual, basado en una versión a escala de
un proceso industrial.
El principal objetivo del PSP es ayudar a los
ingenieros software a hacer mejor su trabajo.
EL PSP se ha diseñado también para demostrar
el valor del uso de un proceso definido y
medido.
El PSP (cont…)

El PSP se aplica en tareas personales
estructuradas:






Desarrollo de módulos de programas.
Definición de requisitos o procesos.
Realización de revisiones o pruebas.
Escritura de documentación, etc….
El PSP se puede extender al desarrollo de
sistemas software de gran tamaño.
Es un proceso de Nivel 5 para los individuos y
Gestión del Tiempo
Usando un Cuaderno de Ingeniería
La lógica de la Gestión de
Tiempo



Probablemente harás esta semana lo mismo
que hiciste la semana pasada. Esto te permite
estimar que harás en semanas próximas.
Para hacer un plan realista, tienes que
controlar tu forma de gastar el tiempo.
Registrar lo que haces te dara pautas
importantes que no conocidas.
Para comprobar la exactitud de tus
estimaciones de tiempo y los planes, debes
documentar y posteriormente compararlas con
La lógica de la Gestión del
Tiempo


Para hacer mas precisos tus planes,
determina las equivocaciones de los
planes anteriores y que podrías haber
hecho mejor.
Para gestionar tu tiempo, planifica tu
tiempo y sigue el plan.
Entiende cómo utilizas el
tiempo

Clasifica tus actividades.

Anota el tiempo dedicado a cada actividad.

Anota el tiempo de manera estándar.

Guarda los datos de tiempo en un lugar
adecuado
El Cuaderno de Ingeniería

Usado para anotar y controlar:





Las actividades de los ejercicios (planificación,
programación, etc.)
Compromisos.
Anotaciones de clase.
Ideas de diseño y cálculos.
Importante para:


Posibles evidencias legales.
Protección de la propiedad Intelectual.
El diseño del cuaderno

Se suele usar un cuaderno en espiral.

Las páginas numeradas.

Numeración y fecha en cada hoja.

Deja una o dos páginas para la tabla de
contenidos.
Ejemplo de Portada


Cuaderno de Ingeniería




Cuaderno Nº: 1
PROYECTO
Nombre: Tomás
E-mail: [email protected]
Apertura: 10-Feb Cierre:
Página de Ejemplo
Fecha
3
9/3
12/3
ingeniería
206
Ejercicio PSP0, terminar
Preparar cuaderno de
Mirar libro de texto pagina
11/3
Completar tabla de tiempos,
ver definición
Completar el post-mortem
para ejercicio 2
¿Por qué controlar el tiempo?




A no ser que conozcas cuanto tiempo estás
gastando en una tarea, tu no puedes
controlarla.
Para saber cuanto tiempo usas, tu debes
medirlo.
Te puedes sorprender en que gastas tu tiempo.
Es más fácil controlar el tiempo que mejorar la
productividad.
Anotar datos de tiempos

Usa la tabla estándar.

Sigue un procedimiento escrito.

Para este curso, usa el método descrito
y después diseña un método ajustado a
tus necesidades.
Controla tu tiempo



Normalmente se miden
el tiempo en términos
de horas, pero no es útil
/ preciso hacerlo de esa
manera
Es muy raro gastar más
de una hora en una
actividad
Utilizar minutos para el
registro de tiempos
Tiempo de tareas
35
30
25
20
15
10
5
0
Tareas
La gestión de interrupciones

Las interrupciones son muy frecuentes.

EL tiempo de las mismas es muy variable.


Estar anotando cuando empieza y cuando
termina es muy moroso.
Anota mejor el tiempo total para ser
descontado.
La gestión del tiempo




Incluye las tablas de tiempos en el cuaderno de
ingeniería.
Mantén cerca el cuaderno de ingeniería.
Cuando se te olvide anotar el tiempo de inicio,
o de finalizaciones o de interrupción, anota una
estimación según te acuerdes.
Analiza tus tiempos.
Proceso PSP0



PSP0 es un proceso sencillo, definido y
personal.
Utiliza tus métodos actuales de diseño y
desarrollo.
Recoge datos sobre tu trabajo:



tiempo gastado por fase
defectos encontrados en compilación y pruebas
Proporciona un informe resumen.
El flujo de Proceso del PSP0
Requisitos
Proceso PSP0
Planificación
Desarrollo
Guiones
de proceso
Diseño
Código
Compila
Pruebas
Post-mortem
Producto acabado
Logs de
tiempos
y
defectos
Resumen
Plan
Proyecto y proceso
Proceso PSP0

Elementos





un
un
un
un
un
guión de proceso
formulario resumen de plan proyecto
registro tiempo
registro de defectos
estándar de tipos defecto
Guión de proceso
Número Propósito
Fase
Entradas
Necesarias
1
2
Planificación
Desarrollo
Guiarte en el desarrollo de programas a nivel de módulo














3
Post-mortem
Criterios de
salida



Descripción del problema
Formulario de Resumen del Plan de Proyecto PSP0
Tablas de Registro de Tiempos y Defectos
Estándar de Tipos de Defectos
Cronómetro (opcional)
Producir o obtener los requisitos.
Estimar las LOC (Line Of Code) necesarias.
Estimar el tiempo de desarrollo necesario.
Indicar los datos del plan en el Resumen del Plan de
Proyecto
Completar el Log de Registro de Tiempos
Diseñar el programa
Implementar el diseño.
Compilar el programa y corregir todos los defectos
encontrados.
Completar el Tabla de Registro de Tiempos.
Completar el Resumen del Plan de Proyecto con los datos
actuales de tiempo, defectos, y tamaño.
Un programa probado.
Un Resumen de Plan de Proyectos con los datos estimados
y los actuales.
Las Tablas de Registro de Tiempos y Defectos rellenos
El guión PSP0

Referencia - Tabla C10

Planificación - estimar tiempo de desarrollo.


Desarrollo - desarrollar el producto utilizando
tus métodos actuales.
Post-mortem - completar el resumen del plan
proyecto, con los tiempos gastados y defectos
encontrados e inyectados en cada fase.
El guión PSP0

Diseño - diseñar el programa, usando tus métodos de
diseño actuales.

Codificación- implementa el programa.

Compilación - compila hasta que este libre defectos.


Prueba - prueba el programa y corrige todos los
defectos.
Registra los defectos en el log de defectos y tiempos por
fase en el log de tiempos.
Resumen Plan PSP0




Referencia - Tabla C14
Header – Nombre, fecha, programa, instructor,
lenguaje.
Program Size – Plan -Indica tu mejor
estimación del tiempo total que tendrá el
desarrollo.
Program Size – Actual -Indica el tiempo actual
en minutos gastado en cada fase.
Resumen Plan PSP0



Time – To Date - indica el tiempo total
gastado en cada fase hasta hoy. Para
programa 1A, es el tiempo gastado en el
programa 1A.
Time – To Date % - indica el porcentaje del
total tiempo hasta hoy que se gasto en cada
fase.
Defects injected and removed - indicar el
numero actual de defectos inyectados y
eliminados en cada fase.
Resumen Plan PSP0


Defect - To Date - indica el total de defectos
inyectados y eliminados en cada fase hasta
hoy. Para el programa 1A, son los defectos
inyectados y eliminados en el programa 1A.
Defect - To Date % - indicar el porcentaje
sobre el total defectos inyectados y eliminados
hasta hoy en cada fase.
Log Registro de tiempo PSP0
Student
Instructor
Date
Start
Date
Program #
Stop
Interruption
Time
Delta
Time
Phase
Comments
Log Registro de tiempo PSP0




Referencia - Tabla C16
Header - indicar nombre, fecha, instructor, y
numero de programa.
Date - indicar la fecha actual.
Start - indicar el tiempo en minutos cuando
empiezas una fase del proyecto.
PSP0 Log Registro Tiempos



Stop - indicar el tiempo en minutos cuando tu
paraste trabajo en una fase del proyecto, aun
cuando tu no has terminado esa fase.
Interruption time - indicar el tiempo perdido
por interrupciones desde el periodo de
arranque a parada.
Delta time - indicar el tiempo transcurrido
desde el inicio al tiempo de parada descontado
el tiempo de interrupción.
PSP0 Log Registro Tiempos

Phase



Anotar la fase en la que estas trabajando.
Use el nombre de fase.
Comments – descripción de



la interrupción
la tarea que estas haciendo
cualquier aspecto significativo que afecte a tu
trabajo
Defect Types
10 Documentation
20 Syntax
30 Build, Package
40 Assignment
50 Interface
60
70
80
90
100
Checking
Data
Function
System
Environment
Log Registro
Defectos
Date
10-3
Description:
Kim Orihuela
Iraj
Number
Type
1
40
Add variable to structure.
Date
10-3
Description:
Number
Type
2
20
Misspelled variable.
Student
Instructor
Date
Program #
10-3-96
3A
Fix Defect
Inject
CODE
Remove
CODE
Fix Time
11
Inject
CODE
Remove
CODE
Fix Time
1
Fix Defect
Date
10-3
Description:
Number
Type
Inject
3
20
CODE
Missing “ in print statement.
Remove
Fix Time
1
Fix Defect
COMPILE
Date
10-3
Description:
Number
Type
Inject
4
10
CODE
Align/add print statements - beautify
Remove
TEST
Fix Time
39
Fix Defect
Log Registro Defectos




Referencia - Tabla C18
Header - indicar el nombre, fecha, instructor, y
numero de programa.
Date - indicar la fecha cuando encontraste y
corregiste el defecto.
Number - indicar un número único para este
defecto. Comienza cada cada proyecto con 1.
Log Registro Defectos



Type - indicar el tipo de defecto a partir
del estándar de tipos de defectos.
Inject - indicar la fase donde tu juzgas
que el defecto fue inyectado.
Remove - indicar la fase en la que
encontraste y eliminaste el defecto.
Log Registro Defectos



Fix Time - indicar el tiempo que tomaste para
corregir el defecto. Tu puedes dar el tiempo
exacto o usar tu mejor estimación.
Fix defect - Si este defecto fue inyectado
durante la corrección de otro defecto, indicar
el numero del ese defecto o una X si lo
desconoces.
Note - un defecto es cualquier cosa en el
programa que debe ser cambiado para que sea
desarrollado, mejorado o utilizado de manera
Estándar de Tipos de defecto



Referencia - Tabla 20
El estándar de tipos de defecto proporciona un
conjunto general de categorías de defectos.
Aunque tu puedes reemplazar este estándar
por el tuyo propio, es deseable que te manejes
con estas definiciones simples de tipos hasta
que tengas datos que te puedan guiar en las
modificaciones.
Estándar de Tipos de Defecto

Los tipos estándar de defecto en PSP son










10 20 30 40 50 60 70 80 90 100 -
Documentación
Sintaxis
Construcción, empaquetado
Asignación
Interfase
Comprobación
Datos
Funciones
Sistema
Entorno
Ejercicio Clasificación de Defectos
Describe con al menos un ejemplo de cada tipo para
tu lenguaje y entorno

Tipo
10
20
30
40
50
60
70
80
90
100
Tipo
10
20
30
40
50
Nombre
Documentación
Sintaxis
Construcción
Asignación
Interfaz
Comprobación
Datos
Funciones
Sistema
Entorno
Descripción
comentarios, mensajes
ortografía, puntuación, tipos, formatos de instrucción
gestión de cambios, librerías, control de versiones
declaración, nombres duplicados, ámbito, limites
Llamadas y referencias a rutinas, I/O, formatos
mensajes error, comprobaciones inadecuadas
estructura, contenido
lógica, punteros, bucles, recursion, calculo, defectos en funciones
configuración, tiempos, memoria
diseño, compile, pruebas, y problemas del sistema de soporte
ejemplo...
______________________________
______________________________
______________________________
______________________________
______________________________
Tipo
60
70
80
90
100
ejemplo...
______________________________
______________________________
______________________________
______________________________
______________________________
Visión general de la
Planificación y Medición de
tamaño

Visión general de Planificación

Tamaño de Software




¿Por qué medir el tamaño?
Criterios de medida de tamaño
El marco de trabajo del SEI para la medida del
tamaño
Contando el tamaño del programa


Contadores
Estándares de codificación
¿Por qué hacer Planes?

Planes





permite llegar a acuerdos que se puedan
cumplir
proporciona las bases para acuerdos en tu
trabajo
guía el trabajo
ayudan a seguir el progreso
terminación del proyecto
El marco de trabajo para la
planificación de proyectos
Definir
Necesidades
Producir
Diseño
Conceptual
Entrega
Producto
Estimar
Tamaño
Base de datos
de tamaño
Estimar
Recursos
Base datos de
productividad
Producir
Calendario
Recursos
Disponibles
Desarrollar
Producto
Datos Tamaño,
Recursos,
Plazos
Proceso
Análisis
Informes de
Seguimiento
¿Por qué medir el Tamaño?

Medidas de tamaño



Nos ayudan a hacer mejores planes
Ayudan en seguimiento del desarrollo
Normalizan otras medidas


Recursos de desarrollo
Tasas de defectos
Criterios para la Medición del
tamaño

La medición de tamaño debe




estar relacionada con el esfuerzo de
desarrollo
precisa
contables de manera automática
deseable en la planificación temprana
Tamaño frente a esfuerzo de
desarrollo


El requisito principal: si la medición del tamaño
no esta directamente relacionada con el costo
de desarrollo, no es bueno usarla.
Hay muchas medidas posibles:




líneas de código (LOC)
puntos de función
páginas, pantallas, scripts, informes
La medida del tamaño suele ser sensible al
lenguaje, diseño y al modo de desarrollo.
Recuento automático



La medición de tamaño es una actividad que
consume tiempo y es imprecisa.
Los contadores automáticos pueden trabajar
solo sobre caracteristicaza del programa
definidas.
Contadores pueden ser complejos por:


definición de tamaño seleccionada
método de conteo
Recuento del tamaño del
programa

El PSP utiliza un estándar de contador de líneas
físicas.




utiliza una línea física por cada línea lógica
utiliza un estándar de codificación definido
Este estándar debe ser seguido estrictamente.
Entonces el recuento de líneas físicas será igual
al recuento de líneas lógicas.
El estándar de recuento del
PSP

Contar todas las instrucciones:





begin, end, if, then, else, etc.
{, }, ;, ., etc.
contar declaraciones, directivas, encabezados, etc.
No contar blancos, líneas de comentarios,
código generado automáticamente, o código
reutilizado.
Contar el código nuevo y el cambiado para
medir y estimar la productividad de desarrollo.
Contabilidad de Líneas de
Código



Para pequeños programas, el seguimiento de
tamaño puede realizarse de manera manual,
aunque requiere cuidado.
Para grandes programas, el seguimiento del
tamaño requiere un sistema de contabilidad.
La contabilidad de LOC proporciona una
manera precisa y ordenada para realizar el
seguimiento de los cambios de LOC a través
de las múltiples versiones de programas.
Ejemplo de Contabilidad de
LOC - 1
Versión 0
350 LOC
Mejoras a Versión 1
+ 125 LOC Nuevas y
Cambiadas
Tamaño Esperado:
350+125=475 LOC
Tamaño medido
450 LOC
¿Qué ha sucedido?











Ejemplo de Contabilidad de
LOC - 2 Sumar Restar Base
Base V0
Borradas,
0
Modificadas
0
Añadidas
350
Total V0 LOC
350
-0
Borradas
0
Modificadas
25
-25
Añadidas
100
Producto Final 125
-25
Total Nuevas y Cambiadas LOC
0
0
350
450
475