Introduccion: El Proceso Software Personal.

El Proceso Software Personal (PSP) es una disciplina de desarrollo de software, que trata de
mejorar individualmente, de forma paulatina e incremental la formacin de las personas dedicadas
al rubro. PSP muestra las bases para iniciar un trabajo de calidad mediante la aplicacin de
tcnicas y buenas prcticas que mejoran habilidades de los desarrolladores.

Una de las grandes ventajas del PSP es que est definido como una disciplina y no como un
modelo de desarrollo de software. Un modelo exige que se cumplan todas las fases que lo
componen y en un orden definido, mientras que el PSP llega a ser totalmente flexible, siendo el
desarrollador el que elija las tcnicas que desea aplicar y adems modificarlo segn sus
necesidades.

En el presente trabajo se presenta un ejemplo de aplicacin del PSP, que abarcan las fases de
Planeacin, Diseo, Codificacin, Compilacin, Pruebas y Postmortem. Si bien este no trata a
profundidad los practicas del PSP, se intenta facilitar la adopcin y los inicios para continuar con la
profundizacin de esta disciplina.

Cabe recalcar que el PSP fue desarrollado por Watts Humphrey y difundido por el mismo en dos
libros, como son: A Discipline For Software Enginnering e Introducion To The Personal Software
Process.

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.
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. Estimacion 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
esta 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

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
aun 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 UML, y anota el tiempo empleado en el cuaderno de
registro de tiempos a continuacin del anterior registro.

5. Codificacion

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 CODIFICACION 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

Para cada codificacin del diseo, X tiene que anotar el tiempo dedicado en el cuaderno de
registro de tiempos.
6. REVISION DE CODIGO

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 COMPROBACIN 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 la 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 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.
10. 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.
9. PostMortem
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 SEMANAL 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. Estimacion de Nuevos Proyectos

Ahora para cualquier otro pedido de software X, ya contara 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