Aplicación del Proceso Software Personal PSP

El Proceso Software Personal (PSP) es una disciplina de desarrollo de software, que trata de
mejorar individualmente, de forma paulatina e incremental la formación de las personas dedicadas
al rubro. PSP muestra las bases para iniciar un trabajo de calidad mediante la aplicación de
técnicas y buenas prácticas 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 técnicas que desea aplicar y además modificarlo según sus
necesidades.

En el presente trabajo se presenta un ejemplo de aplicación del PSP, que abarcan las fases de
Planeación, Diseño, Codificación, Compilación, Pruebas y Postmortem. Si bien este no trata a
profundidad los practicas del PSP, se intenta facilitar la adopción y los inicios para continuar con la
profundización 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 años el ingeniero X desarrolla programas de gestión para negocios como
farmacias, ferreterías y otros, el está acostumbrado a entregar los productos de software con
documentación mínima. A menudo el Ing. X falla en las fechas de entrega y al apresurar el
desarrollo provoca muchos defectos en los productos y críticas 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 elaboración 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 gestión de un inventario para el almacén
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 aplicación a desarrollar y con la empresa acordaron en

un plazo de entrega de aproximadamente 1 mes, X procede a una programación de
actividades en un diagrama de Gantt de las actividades que tiene que realizar. Si bien sus
programaciones no serán exactas, con la experiencia se tendrá que mejorar las mismas.
2. Requisitos del Software

El Ing. X comenzó reuniéndose con el propietario para ir aprendiendo sobre el funcionamiento

de la empresa e ir obteniendo los requisitos explícitos al igual que los implícitos.

A partir de los requerimientos del cliente, X identifico que eran necesarios los siguientes
módulos:

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 Estadísticas

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 adaptarían mejor a dichos requisitos, y llega a la conclusión que el desarrollo se debe
realizar con Delphi 5 y MySQL.
3. Estimacion del Software

La siguiente actividad que se debe realizar, es la planificación 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 estimación de varias secciones. Sin embargo X considerará datos según su criterio, que
usará para la estimación 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 aproximación debe

incluir el diseño lógico, revisión y pruebas)

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

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

Para el Tamaño 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 función, y basándose en la experiencia el X estima un total de:

Función de Introducción de datos Tabla Galletas = 42 LOC

Función de Modificación de datos Tabla Galletas = 62 LOC

Función de Eliminación de datos Tabla Galletas = 42 LOC

Función de Introducción de datos Tabla Fideos = 40 LOC

Función de Modificación de datos Tabla Fideos = 60 LOC

Función de Eliminación de datos Tabla Fideos = 40 LOC

Función de Búsqueda de un Producto = 60 LOC

Función de consultar sobre Marcas de Productos = 30

Función de consultar sobre Precio de los Productos = 30

Función de consultar sobre Cantidad en Stock de los productos = 30

Función de consultar sobre Estadísticas = 120

LOC Nuevas y Cambiadas = 556 LOC

El tamaño Máximo y mínimo 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 máximo de tiempo por fase = 606 * 2 = 1212 min.

Para el mínimo 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 planificación y
estimación.

4. Diseño
Continua con la elaboración del diseño de los distintos módulos que X había identificado, y
expresando los diseños en Diagramas de Flujo, y anota el tiempo empleado en el cuaderno de
registro de tiempos a continuación del anterior registro.

5. Codificacion

El siguiente paso es codificar los diseños, para lo cual X necesita tener o elaborar un estándar
de codificación. Debido a que empieza a usar por primera vez un estándar, toma como guía
uno general y corto, como el siguiente:

ESTANDAR DE CODIFICACION EN DELPHI

Formato de encabezado: Deben ser como el siguiente:

{********************************************* }
{ Programa: ___________________ }
{ Autor: _______________________ }
{ Fecha ______________________ }
{ Versión: ____________________ }
{ Descripción: _________________ }
{********************************************* }

Uso y reuso de una funcion. Describir al máximo el uso de una función. Ej.

{******************************************************************************* }
{ Función: ____Factorial______________________________ }
{ Autor: ____Ing. X __________________________________ }
{ Fecha: ___09 / 01 / 08______________________________ }
{ Versión: ____1.0 __________________________________ }
{ Descripción: Esta rutina obtiene el factorial de un numero ___ }
{ entero cuyo resultado devuelve en un entero largo. El número }
{ ingresado debe ser menor a 150, se debe comprobar este __ }
{ valor antes de llamar a esta función. }
{******************************************************************************* }

Function Factorial ( Numero : int ) : Longint;

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

Identificación 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 explícitos:

Aceptado en estándar:

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 descripción de las secciones principales en bloque de comentarios.

{Esta sección del programa, obtendrá los contenidos del array notas, además 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 función 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 Estándar.

Para cada codificación del diseño, X tiene que anotar el tiempo dedicado en el cuaderno de
registro de tiempos.
6. REVISION DE CODIGO

Una vez terminada la codificación, ahora corresponde realizar la revisión del código, mediante
una la lista de comprobación, siempre antes de compilar. Por el momento X utilizara una lista de
comprobación general, con el tiempo tendrá que definir una lista personalizada de acuerdo a los
errores que comete. También necesita una clasificación 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 Análisis de Errores, esta
última tabla será necesaria para completar el Resumen del Plan del proyecto
LISTA DE COMPROBACIÓN PARA REVISIÓN DE CÓDIGO
 ANALISIS DE ERRORES

Al finalizar la revisión de las 11 funciones que X esta desarrollando, obtiene un total de

20 defectos encontrados antes de la primera compilación. Los porcentajes nos indicarán donde es
que tenemos más defectos, y sobre ello debemos idear la forma de reducirlos. También se anota
los tiempos en el cuaderno de registro de tiempos.
7. COMPILACIÓN
Luego se procede a la compilación del código, se registra cada defecto en el cuaderno de
defectos y en la tabla de análisis de errores y el tiempo dedicado también en el cuaderno de
registro de tiempos.
8. Pruebas
El Ing. X llego a la parte de las pruebas, donde cada modulo 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 función insertar adicione datos a la Base De Datos
correctamente, y que la modificación y la eliminación sean exitosas.
De esta manera completamos las pruebas de las 11 funciones.

Completamos la el análisis 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 debería tener la siguiente forma.
n este punto cada quien debe hacer un análisis de los defectos que comete, y pensar en
estrategias de cómo debemos dejar de cometer esos errores. Si nuestras ideas dan resultados,
estos defectos empezaran a disminuir al mínimo, 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 había estimado el desarrollo hasta antes del 3 de
mayo, por lo que tuvo un retraso de algo más de una semana. Para el Ing. X, tal vez este retraso
no significa mucho, pero no sucede lo mismo en proyectos grandes donde implique más 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 Valoración/Fallo de 0.52 indican que estamos gastando mucho tiempo en las
pruebas y compilación, 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 habría 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 apéndice 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

Valoración/Fallo = Tiempo Revisión / (tiempo compilación + tiempo pruebas) = 374 / (80+636) =

374 / 716 = 0.52
11. Historiales

Estimación de LOC Nuevas y cambiadas. X puede empezar a llenar las tablas de Tamaño de
Programas para tener un historial y sirva para próximas estimaciones por comparación

Con este historial es posible calcular una parte de un nuevo programa. Por ej. Si X trabajo en la
inserción, modificación y eliminación de 7 datos de una tabla y le costó programar N líneas y T
tiempo, en un programa nuevo usara igualmente una inserción 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 programación. En caso de tener otras actividades, como por
ejemplo pasar clases de actualización por las mañanas, el Ing. deberá registrarlo en esta tabla.
Así se irá obteniendo distintos resúmenes 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 continuación
veamos como X obtiene un resumen semanal a partir del cuaderno de registro de tiempos.
De la primera semana que trabajo X, debería completar un resumen semanal como sigue:
Una segunda semana con las mismas actividades sería:
Una segunda semana con las mismas actividades sería:
Con esto queda completada una primera adopción del PSP del Ing. X. De esta manera se irá
completando la base de datos de funciones que permitan una mejor estimación. También contará
con un registro semanal de tiempo que lo protegerán 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 Resúmenes del Plan, permitiendo que el nuevo Resumen Del Plan del proyecto se
pueda iniciar correctamente. A continuación veamos como completar una nueva estimación 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
básicamente 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 guía.

Rerencia

http://proceso-software-personal.blogspot.com.co/