• Author / Uploaded
• Jose Fernando Murillo Arango

• Categories
• Compilador
• Tabla (base de datos)
• Software
• Ingeniería de software
• Gestión de tecnología de la información

Citation preview

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

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.

Nombre: Ing. X Programa: AFG

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 UML, 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

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 módulo 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.

En 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:

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