METODOLOGIA DE DESARROLLO PSP

Proceso Personal de Software (por sus siglas en ingles Personal Software Process), es un proceso
de superacin personal que ayuda a controlar, administrar y mejorar la forma de trabajar de cada
desarrollador. Es un Framework estructurado de formas, guas y procedimientos para desarrollar
software. Creado por Watts Humprey del Software Engineering Institute (SEI).
Los ingenieros utilizan PSP para desarrollar software siguiendo los procesos definidos y
recolectando mtricas detalladas sobre el tiempo requerido para producir un producto, los
defectos que se inyectan y se retiran en las distintas etapas del desarrollo, y el tamao del
producto terminado.
Estos indicadores son analizados con mtodos estadsticos, permitiendo a los ingenieros producir
estimaciones muy precisas sobre histricos, seguir el progreso y la calidad de un proyecto en
curso, predecir el impacto del calendario y predecir la calidad de un producto de software
terminado. PSP ensea a los ingenieros a determinar cuantitativamente la forma de mejorar sus
procesos.
Usado en forma adecuada PSP provee la informacin necesaria para cumplir los compromisos, y
hace a los elementos rutinarios de trabajo ms predecibles y eficientes.
El propsito de PSP es ayudar a mejorar las habilidades del ingeniero de software, es una
herramienta que puede ser utilizada de muchas formas, por ejemplo: ayudar a administrar su
trabajo, evaluar sus talentos y construir sus habilidades. Puede ayudarle a hacer mejores planes,
seguir de manera precisa su rendimiento y medir la calidad de sus productos. Ya sea para disear
programas, evaluar requisitos, documentar o mantener software existente, PSP puede ayudarle a
hacer mejor el trabajo.
PSP provee la informacin y tcnicas de anlisis que necesitas para determinar cual tecnologa y
mtodos de trabajo son mejores para usted. Tambin le ayuda a entender porque comete errores
y como encontrarlos, repararlos y prevenir que vuelva a hacerlos.
PSP, es uno de los 3 vrtices donde descansa un proceso de mejora que trabaja sobre 3 niveles de
la organizacin, los otros 2 son CMM y TSP



CMM se enfoca a nivel organizacional
TSP se enfoca a un proceso de grupos de trabajo
PSP se enfoca a nivel personal



CARACTERISTICAS
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso
de desarrollo de un producto de software, estn puntualmente definidas en un conjunto de
documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace
mucho nfasis en que deben ser seguidos en forma disciplinada, ya que de ello depender el xito
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generar
en su realizacin un conjunto de datos, fundamentalmente de carcter estadstico. La aplicacin
de PSP en varios procesos de desarrollo, y el anlisis de la informacin estadstica generada en
cada uno de stos, permitirn al ingeniero de software identificar, tanto sus fortalezas como sus
debilidades, y crecer a travs de un proceso de autoaprendizaje y auto mejora.
La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos que el
producto de software contiene.
En este nivel se introducen algunos mtodos aplicables al proceso de desarrollo de software,
dentro de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicacin y
coordinacin de los equipos de trabajo.

Proceso PSP
El principal objetivo del proceso PSP, es proveer un Framework para escribir los programas y
reunir informacin sobre tu trabajo, el proceso PSP provee algunos beneficios como:
Una estructura conveniente para la realizacin de tareas a pequea escala.
Un Framework para medir estas tareas.
Una base para la mejora de procesos.
El proceso se divide en tres partes principales Planeacin, Desarrollos y Post Mortem. A
continuacin describo los principales objetivos de estas epatas, las cuales se ilustran en la Figura 1:
1. Planeacin:
Producir u obtener los requisitos del programa.
Asegurar que los requerimientos son claros y sin ambigedades.
Resolver cualquier inquietud.
Estimar el tiempo de desarrollo necesario.

2. Desarrollo:
Diseo
Disear el programa de acuerdo con los requerimientos.
Ingresar en el log de defectos cualquier defecto encontrado con respecto a los
requerimientos, mientras se hace el diseo.
Ingresar en el log de tiempos, el tiempo total gastado en el diseo.

Cdigo
Implementar el diseo.
Ingresar en el log de defectos cualquier defecto encontrado con respecto al
diseo.
Ingresar en el log de tiempos, el tiempo total gastado en la codificacin.

Compilacin
Compilar el programa hasta que no haya errores de compilacin.
Reparar todos los defectos encontrados.
Ingresar en el log de defectos cualquier defecto encontrado con respecto al
cdigo.
Ingresar en el log de tiempos, el tiempo total gastado en compilacin.

Pruebas
Probar hasta que no haya errores.
Reparar todos los defectos encontrados.
Ingresar en el log de defectos cualquier defecto encontrado con respecto al
cdigo.
Ingresar en el log de tiempos, el tiempo total gastado en pruebas.

3. Post Mortem
Revisar el resumen del plan del proyecto, con los tiempos reales, defectos y tamao de los
datos, que se registraron en el log de cada etapa para:
Recordar y guardar en el log cualquier defecto que fuese omitido.
Corregir la informacin guardada sobre los defectos y corregir.
Corregir cualquier error en la recopilacin de tiempos.



7 Niveles del PSP
PSP 0
Identificar actividades: definicin, secuencia
Bases mejoras: planeacin, evaluacin, resultados
Documentar proceso:
Formas de:
Actividades (Scripts)
Tiempos (Logs Time)
Defectos (Defect Logs)
Resumir planes, resultados (Proyect plan summary)


PSP 0.1
Registrar tamao del producto y hacer un histrico:
Lineas de cdigo
Function points
Estandarizacin de la codificacin
Registrar problemas y mejoras de propuestas



PSP 1
Mejora la planeacin:
Con la estimacin tamao del producto (historico)
Decidir en base a reportes de pruebas



PSP 1.1
Mejora la planeacin:
Con la estimacin de recursos
Introduccin de calendarizar, plasmar el plan con nmeros, un presupuesto.

PSP 2
Mejora la ejecucin:
Deteccin temprana de defectos, en base a la prediccin de estos.
Revisiones de diseo
Revisiones de cdigo
Uso de checklists (Listas de verificacin)

PSP 2.1
Mejora el diseo:
Al hacer uso de formas detalladas de diseo (formas C76, C77)

PSP 3
Mejora el ciclo, mejora del proceso en trminos de hacerlo repetible (ciclico):
Para aplicacin a programas de mayor tamao
Registro del seguimiento de asuntos importantes
Anlisis del resumen de la planeacin, tiempos, tamaos y defectos por cada ciclo



VENTAJAS Y DESVENTAJAS PARA UTILIZAR PSP
PSP es una alternativa, de las muchas que han surgido recientemente, para mejorar el proceso de
desarrollo de software. Ms que clasificar un conjunto de sentencias como ventajas o desventajas,
a continuacin se citan algunas caractersticas:
PSP es una metodologa basada en estimacin. La estimacin permite saber cundo y cmo se
desarrollan las tareas de un proceso, por lo que podra citarse como un aspecto importante de
esta metodologa el estar basada en mtricas y estimaciones.
La informacin de las mtricas y estimaciones se utiliza para evaluar y mejorar procesos futuros.
PSP parte de la premisa que, si el ingeniero de software conoce sus fortalezas y debilidades, puede
establecer las acciones necesarias para erradicar o explotar los aspectos identificados en la forma
en que desarrolla software.
Aunque lo mencionado en el punto anterior podra sonar bastante atractivo, la forma de llegar a
ese auto conocimiento puede resultar tediosa y, en el peor de los casos, una pesadilla para el
desarrollador. Salvo muy pocas excepciones, los ingenieros de software nunca realizan
procedimientos formales para conocer la forma en que trabajan, no saben con exactitud cuntas
lneas de cdigo generan por hora, cunto tiempo invierten al corregir un error, cunto tiempo
invierten en pruebas, etctera.
Los pasos de registro de informacin a detalle en el nivel de medicin pueden resultar frustrantes
cuando se tiene presin de tiempo.
En los scripts de PSP no se incluyen tareas y actividades para la etapa de anlisis de
requerimientos. Siempre se parte de una definicin de requerimientos que no va a cambiar.
An no existe una herramienta automatizada que facilite el registro y anlisis de datos generados
por la aplicacin de PSP.

Especificacin

Requisitos y Planeacin

Diseo de Alto Nivel

Revisin del Diseo de Alto Nivel

Desarrollo Cclico (Anlisis Ciclo)

Especificacin el ciclo

Diseo detallado y su revisin

Definicin de pruebas y su revisin

Implementacin y Revisin de Cdigo

Compilacin

Pruebas

Evaluacin


PostMortem

Integracin
Pruebas de Sistema
Uso

Producto

CICLO DE VIDA PSP, FASES
Requisitos
Planeacin

Diseo de alto nivel

Revisin de alto nivel del diseo

Desarrollo cliclico

Post Mortem

Integracin

Pruebas
Producto

FASES DE PSP

CICLO DE VIDA PSP,
FASE REQUISITOS
REQUISITOS
Descripcin del problema
Especificacin de componentes
Formas de proceso
Estimadores del tamao del producto y tiempos en base a historicos


CICLO DE VIDA PSP,
FASE PLANEACIN (PLAN DE PROYECTO)
INPUT Descripcin del problema, resumen del proyecto, resumen cclico, tamao estimado,
tiempo estimado, formas de planeacin.
ACTIVIDAD Requerimientos, tamao estimado, desarrollo estrategia, estimados de recursos,
planificacin y programas de tareas, estimacin de defectos.
OUTPUT Diseo conceptual, resumen plan, resumen del ciclo, patrones de estimados de
tamao y planeacin de tareas, programas de patrones de planeacin, registro de
tiempos.



CICLO DE VIDA PSP,
FASE DISEO DE PRODUCTO
INPUT Tipificacin requerimientos, diseo conceptual, patrones de estimaciones de tamao,
resumen parte ciclico, seguimiento
ACTIVIDAD Especificaciones externas, diseo modular, prototipos, estrategia de desarrollo y
documentacin, seguimiento
OUTPUT Diseo de programa, escenarios operacionales, especificacin de funciones y lgica,
resumen cclico, seguimiento y estrategias de pruebas y ciclo



CICLO DE VIDA PSP,
FASE REVISIN O VALIDACIN DEL DISEO
INPUT Programa de diseo, escenarios operacionales, especificacin de funciones y lgica,
resumen ciclico, seguimiento y estrategia de pruebas y ciclo.
ACTIVIDAD Diseo de apariencia, verificacin de mquinas y lgica, consistencia del diseo, reuso,
estrategia de verificacin, detectar errores.
OUTPUT Fiseo de alto nivel, registro de seguimiento, tiempos y defectos.



CICLO DE VIDA PSP,
FASE DESARROLLO O IMPLEMENTACIN
INPUT Diseo de alto nivel, registro de seguimiento, tiempos y defectos, ciclo de desarrollo,
estrategia de pruebas, patrones de operacin y funcin.
ACTIVIDAD Diseo de mdulos, revisin de diseo, cdigo, revisin de cdigo, compilacin,
pruebas, aseguramiento de calidad y del ciclo.
OUTPUT Modulos de sw, patrn de diseo, lista de verificacin de cdigo y diseo, resumen del
ciclo, patrn de reporte de pruebas, registro de tiempo, defectos y seguimiento.



CICLO DE VIDA PSP,
FASE POSMORTEM, EVALUACIN CICLO
INPUT Definicin de problema y requerimientos, plan de proyecto y de ciclo, producto de
software, patrn de diseo, lista de verificacin de cdigo y diseo, resumen del ciclo,
patrn de reporte de pruebas, registro de tiempo, defectos y seguimiento.
ACTIVIDAD Defectos previstos, removidos, tamao, tiempo del producto.
OUTPUT Producto, listas de verificacin, plan de proyecto y ciclo, patrn de reporte de pruebas
y diseo, forma con propuesta de mejora, registro seguimiento pruebas y tiempo.
















EJEMPLO DEL PROCESO PSP
1. ENUNCIADO
Desde hace 5 aos el ingeniero X desarrolla programas de gestin para negocios como farmacias,
ferreteras y otros, el est acostumbrado a entregar los productos de software con documentacin
mnima. A menudo el Ing. X falla en las fechas de entrega y al apresurar el desarrollo provoca
muchos defectos en los productos y crticas de los clientes. Sin embargo, X desea mejorar su
productividad de desarrollo y empieza a aplicar un proceso definido de desarrollo de software
para la elaboracin de sus productos, convencido de las ventajas del Proceso Software Personal
decide utilizarlo.

El pedido de software que tiene el Ing. X trata de la gestin de un inventario para el almacn de
una tienda de Galletas y Fideos. Actualmente la empresa controla sus datos de venta y compra en
un programa sencillo de registro de datos, sin contar con consultas que son necesarias y tiles
para un mejor control.

El Ing. X no ve mayor dificultad en la aplicacin a desarrollar y con la empresa acordaron en un
plazo de entrega de aproximadamente 1 mes, X procede a una programacin de actividades en un
diagrama de Gantt de las actividades que tiene que realizar. Si bien sus programaciones no sern
exactas, con la experiencia se tendr que mejorar las mismas

Proyecto: AFG
Autor: Ing. X
Fecha: 07/04/08

2. REQUISITOS DEL SOFTWARE

El Ing. X comenz reunindose con el propietario para ir aprendiendo sobre el funcionamiento de
la empresa e ir obteniendo los requisitos explcitos al igual que los implcitos.

A partir de los requerimientos del cliente, X identifico que eran necesarios los siguientes mdulos:

Funciones
Introducir datos de Fideos y Galletas
Modificar datos de Fideos y Galletas
Eliminar Datos de Fideos y Galletas



Consultas
Consulta de Productos por Marcas,
Consulta de Productos por Precio.
Consulta de Cantidad de Productos en Stock.
Consultas Estadsticas


Base de datos necesaria:
Fideos (Id_Fideo, Tipo, Marca, PrecioPaquete, PesoPaquete, CantidadPaquetesStock)
Galletas (Id_Galleta, Nombre, Sabor, Marca, PrecioPaquete, CantidadPaquete,
CantidadPaquetesStock)


A partir de los requerimientos, X estudia sobre las herramientas, lenguaje, y gestor de datos que
se adaptaran mejor a dichos requisitos, y llega a la conclusin que el desarrollo se debe realizar
con Delphi 5 y MySQL.

3. ESTIMACIN DEL SOFTWARE

La siguiente actividad que se debe realizar, es la planificacin del proyecto, que corresponde a
llenar los valores estimados del formulario Resumen del Plan del Proyecto. Como el Ing. X est
usando por primera vez este formulario del PSP, no dispone de muchos datos para hacer la
estimacin de varias secciones. Sin embargo X considerar datos segn su criterio, que usar para
la estimacin del Resumen del plan. En un uso continuado de PSP, X ser capaz de completar todas
las estimaciones que el formulario requiera.

X asume que programa aproximadamente 30 LOC en 60 minutos (Esta aproximacin debe incluir
el diseo lgico, revisin y pruebas)

Minutos/LOC = 60 / 30 LOC = 2 min.

LOC / Hora = 60 / (Minutos/LOC) = 60 / 2 = 30 LOC

Para el Tamao del programa, es posible estimar Total Nuevo y Cambiado, por el momento X an
no tiene registrado un historial de funciones que ayuden a estimar las LOC necesarias para cada
tipo de funcin, y basndose en la experiencia el X estima un total de:


Funcin de Introduccin de datos Tabla Galletas = 42 LOC

Funcin de Modificacin de datos Tabla Galletas = 62 LOC
Funcin de Eliminacin de datos Tabla Galletas = 42 LOC

Funcin de Introduccin de datos Tabla Fideos = 40 LOC

Funcin de Modificacin de datos Tabla Fideos = 60 LOC

Funcin de Eliminacin de datos Tabla Fideos = 40 LOC

Funcin de Bsqueda de un Producto = 60 LOC

Funcin de consultar sobre Marcas de Productos = 30

Funcin de consultar sobre Precio de los Productos = 30

Funcin de consultar sobre Cantidad en Stock de los productos = 30

Funcin de consultar sobre Estadsticas = 120

LOC Nuevas y Cambiadas = 556 LOC

El tamao Mximo y mnimo deber ser a criterio. En este caso +50 y -50

Para el total de tiempo por fase = LOC Nuevas * (Minutos/LOC) = 556 * 2 = 1112 min.

Para el mximo de tiempo por fase = 606 * 2 = 1212 min.

Para el mnimo de tiempo por fase = 506 * 2 = 1012 min.





Ahora llega el momento de ir anotando los tiempos de las actividades que X realiza en el Cuaderno
de Registro de Tiempos. Para empezar X anota el tiempo de planificacin y estimacin.
Nombre: Ing. X
Programa: AFG



4. DISEO
Continua con la elaboracin del diseo de los distintos mdulos que X haba identificado, y
expresando los diseos en Diagramas de Flujo, y anota el tiempo empleado en el cuaderno de
registro de tiempos a continuacin del anterior registro.


5. CODIFICACIN
El siguiente paso es codificar los diseos, para lo cual X necesita tener o elaborar un estndar
de codificacin. Debido a que empieza a usar por primera vez un estndar, toma como gua
uno general y corto, como el siguiente:

ESTANDAR DE CODIFICACIN EN DELPHI
Formato de encabezado: Deben ser como el siguiente:

{********************************************* }
{ Programa: ___________________ }
{ Autor: _______________________ }
{ Fecha ______________________ }
{ Versin: ____________________ }
{ Descripcin: _________________ }
{********************************************* }


Uso y reuso de una funcion. Describir al mximo el uso de una funcin. Ej.

{****************************************************************************
*** }
{ Funcin: ____Factorial______________________________ }
{ Autor: ____Ing. X __________________________________ }
{ Fecha: ___09 / 01 / 08______________________________ }
{ Versin: ____1.0 __________________________________ }
{ Descripcin: Esta rutina obtiene el factorial de un numero ___ }
{ entero cuyo resultado devuelve en un entero largo. El nmero }
{ ingresado debe ser menor a 150, se debe comprobar este __ }
{ valor antes de llamar a esta funcin. }
{****************************************************************************
*** }



Function Factorial ( Numero : int ) : Longint;
Var
Resultado, Contador: Longint;
Begin
Resultado := 1;
For Contador := 1 to Numero Do
Resultado := Resultado * Contador;
Factorial := Resultado;
End;



Identificacin de variables. Utilizar siempre nombres descriptivos para todas las variables,
nombres de funciones, constantes u otros. Evitar variables de una letra o silaba. Ej.

var
cantidad_alumnos: integer; //Aceptado en Estandar
ca: integer //Evitar este tipo de declaraciones



Comentarios. Deben tener el siguiente formato y ser explcitos:

Aceptado en estndar:

while (contador_alumno < num_alumno) do // Faltan procesar
// los registros de alumnos?



No aceptado:

while (contador_alumno < num_alumno) do // Compara si contador alumno
// es menor a num_alumno


Poner la descripcin de las secciones principales en bloque de comentarios.

Esta seccin del programa, obtendr los contenidos del array notas, adems calculara el
promedio de la clase }

Procedimientos, funciones. Se deben considerar formatos de salida y entrada de las
funciones, como por ej. si el resultado de una funcin es verdad o falso se deben usar datos
booleanos en lugar de 0 y 1.

Espacios en blancos. Escribir los programas con los suficientes espacios en blanco para
facilitar la lectura. Se debe sangrar cada nivel begin end, estando alineados el inicio y final.
Ej.

while ( contador_alumno < cantidad_alumno) do
begin
if (array_alumno[contador_alumno] > mayor_nota )
begin
mayor_nota = array_alumno[contador_alumno]
end
contador_alumno = contador_alumno + 1;
end

Fin Estndar.
Para cada codificacin del diseo, X tiene que anotar el tiempo dedicado en el cuaderno de
registro de tiempos.


6. REVISIN DE CDIGO
Una vez terminada la codificacin, ahora corresponde realizar la revisin del cdigo,
mediante una la lista de comprobacin, siempre antes de compilar. Por el momento X
utilizara una lista de comprobacin general, con el tiempo tendr que definir una lista
personalizada de acuerdo a los errores que comete. Tambin necesita una clasificacin de
defectos, por lo que usar la que propone el PSP.


Para cada defecto que se encuentra, se compara con el tipo de error y se registra
inmediatamente en el cuaderno de registro de defectos y en la tabla de Anlisis de Errores,
esta ltima tabla ser necesaria para completar el Resumen del Plan del proyecto.

LISTA DE COMPROBCIN PARA REVISIN DE CDIGO













ANALISIS DE ERRORES


Al finalizar la revisin de las 11 funciones que X esta desarrollando, obtiene un total de
20 defectos encontrados antes de la primera compilacin. Los porcentajes nos indicarn
donde es que tenemos ms defectos, y sobre ello debemos idear la forma de reducirlos.
Tambin se anota los tiempos en el cuaderno de registro de tiempos.

7. COMPILACIN
Luego se procede a la compilacin del cdigo, se registra cada defecto en el cuaderno de
defectos y en la tabla de anlisis de errores y el tiempo dedicado tambin en el cuaderno de
registro de tiempos.



8. PRUEBAS
El Ing. X llego a la parte de las pruebas, donde cada mdulo se probar con distintos valores,
y se registrar en el reporte de pruebas que sugiere PSP. Para este caso solo se probar para
las primeras 3 funciones, se probara que la funcin insertar adicione datos a la Base De Datos
correctamente, y que la modificacin y la eliminacin sean exitosas.






De esta manera completamos las pruebas de las 11 funciones.
Completamos el anlisis de errores con los defectos de las pruebas.


Registrar en el Cuaderno de registro de tiempos el tiempo de las pruebas:



El cuaderno de registro de defectos debera de tener la siguiente forma.

En este punto cada quien debe hacer un anlisis de los defectos que comete, y pensar en
estrategias de cmo debemos dejar de cometer esos errores. Si nuestras ideas dan
resultados, estos defectos empezaran a disminuir al mnimo, y estaremos seguros de que
nuestro proceso mejora.
9. RESULTADOS:
Analizando los resultados vemos que el Ing. X logro terminar el desarrollo del proyecto el 11
de mayo, mientras que en el diagrama de Gantt haba estimado el desarrollo hasta antes del
3 de mayo, por lo que tuvo un retraso de algo ms de una semana. Para el Ing. X, tal vez este
retraso no significa mucho, pero no sucede lo mismo en proyectos grandes donde implique
ms 10000 LOC, donde los errores de etapas superiores provocan efectos domin.

En cuanto al Rendimiento que dio el resultado de 55.6%, advierte que aun estamos
eliminando pocos errores en las revisiones, por lo que significa mas tiempo en las pruebas. Se
debe apuntar como objetivo obtener arriba del 75%.

Sobre el valor de Valoracin/Fallo de 0.52 indican que estamos gastando mucho tiempo en
las pruebas y compilacin, por lo que debemos mejorar nuestra forma de eliminar defectos
en las revisiones. Se recomienda llegar a valores de V/F superiores a 2.

El tiempo por fase nos indica el porcentaje que requerimos para cada fase dado un tiempo
total de desarrollo. De igual manera los defectos Introducidos y Eliminados indican el
porcentaje de defectos que se introduce y elimina en ciertas fases del desarrollo, estos datos
son tiles para nuevas estimaciones.
10. POSTMORTEN
Hasta aqu X habra completado el software de la empresa de Galletas y Fideos. Lo nico que
falta es la fase de PostMorten, que corresponde al completado del Resumen del plan del
proyecto con los valores reales. Debemos registrar un tiempo de postmorten estimado en el
cuaderno de registro de tiempos

El proceso de llenado podemos verlo en las instrucciones del Plan del Proyecto, en el
apndice A.
Defectos/KLOC = 1000 * Defectos Introducidos / LOC Nuevas = 1000 * 45 / 730 = 61.6

Rendimiento = 100 * (Defectos eliminados antes de compilar) / (Defectos Introducidos antes
de compilar) = 100 * 25 / 45 = 55.6
Valoracin/Fallo = Tiempo Revisin / (tiempo compilacin + tiempo pruebas) = 374 /
(80+636) = 374 / 716 = 0.52

11. HISTORIALES
Estimacin de LOC Nuevas y cambiadas. X puede empezar a llenar las tablas de Tamao de
Programas para tener un historial y sirva para prximas estimaciones por comparacin

Con este historial es posible calcular una parte de un nuevo programa. Por ej. Si X trabajo en
la insercin, modificacin y eliminacin de 7 datos de una tabla y le cost programar N lneas
y T tiempo, en un programa nuevo usara igualmente una insercin en una base de datos, esta
vez con 10 datos, y los anteriores datos puede usarlos de la siguiente manera:

RESUMEN SAMANAL DE ACTIVIDADES
A partir del cuaderno de registro de tiempos de las ltimas semanas, el Ing. X puede obtener
un Resumen Semanal de Actividades que le permitir conocer el tiempo que necesita en una
semana para llevar a cabo actividades de programacin. En caso de tener otras actividades,
como por ejemplo pasar clases de actualizacin por las maanas, el Ing. deber registrarlo en
esta tabla. As se ir obteniendo distintos resmenes semanales, tendr uno cuando
programa y pasa clases, otro cuando solo programa, etc. De esta manera, antes de obtener
un nuevo compromiso, X analizar el tipo de semanas que vienen, y en base a criterio aceptar
o rechazar. A continuacin veamos como X obtiene un resumen semanal a partir del
cuaderno de registro de tiempos.

De la primera semana que trabajo X, debera completar un resumen semanal como sigue:

Una segunda semana con las mismas actividades sera:

Con esto queda completada una primera adopcin del PSP del Ing. X. De esta manera se ir
completando la base de datos de funciones que permitan una mejor estimacin. Tambin
contar con un registro semanal de tiempo que lo protegern del exceso de compromisos.
12. ESTIMACIN DE NUEVOS PROYECTOS:
Ahora para cualquier otro pedido de software X, ya contar con datos reales que registr en
sus anteriores resmenes del plan, permitiendo que el nuevo resumen del plan del proyecto
se pueda iniciar correctamente. A continuacin veamos como completar una nueva
estimacin a partir del ltimo resumen:
X supone que las LOC Nuevas y cambiadas Estimadas = 400
























A partir de aqu comienza nuevamente todo el proceso anteriormente descrito, el cual
bsicamente nos permitir empezar a adoptar el PSP, recordando que las practicas
mencionadas aqu se profundizan en el libro de Watts Humphrey: A Discipline for software
Engineering y para aplicarlas se deben manejar las practicas que se presentan en este
tutorial gua.