Documente Academic
Documente Profesional
Documente Cultură
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.
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
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.
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:
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.
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:
{********************************************* }
{ 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. }
{******************************************************************************* }
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
Aceptado en estándar:
No aceptado:
{Esta sección del programa, obtendrá los contenidos del array notas, además calculara el
promedio de la clase }
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.
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
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.
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.
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:
Rerencia
http://proceso-software-personal.blogspot.com.co/