Metodologia de Desarrollo Psp

METODOLOGIA DE DESARROLLO PSP Proceso Personal de Software (por sus siglas en ingles Personal Software Process), es un proceso de superación personal que ayuda a controlar, administrar y mejorar la forma de trabajar de cada desarrollador. Es un Framework estructurado de formas, guías 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 métricas 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 tamaño del producto terminado. Estos indicadores son analizados con métodos estadísticos, permitiendo a los ingenieros producir estimaciones muy precisas sobre históricos, 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 enseña a los ingenieros a determinar cuantitativamente la forma de mejorar sus procesos. Usado en forma adecuada PSP provee la información necesaria para cumplir los compromisos, y hace a los elementos rutinarios de trabajo tr abajo más predecibles y eficientes. El propósito 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 diseñar programas, evaluar requisitos, documentar o mantener software existente, PSP puede ayudarle a hacer mejor el trabajo. PSP provee la información y técnicas de análisis que necesitas para determinar cual tecnología y métodos de trabajo son mejores para usted. También le ayuda a entender porque comete errores y como encontrarlos, repararlos y prevenir pr evenir que vuelva a hacerlos. PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organización, 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, están 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 realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través 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 métodos aplicables al proceso de desarrollo de software, dentro de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicación y coordinación de los equipos de trabajo.

Proceso PSP El principal objetivo del proceso PSP, es proveer un Framework para escribir los programas y reunir información sobre tu trabajo, el proceso PSP provee algunos beneficios como:   

Una estructura conveniente para la realización de tareas a pequeña escala. Un Framework para medir estas tareas. Una base para la mejora de procesos.

El proceso se divide en tres partes principales Planeación, Desarrollos y Post Mortem. A continuación describo los principales objetivos objetivos de estas epatas, las cuales se ilustran en la Figura 1: 1. Planeación: Producir u obtener los requisitos del programa. Asegurar que los requerimientos son claros y sin ambigüedades. Resolver cualquier inquietud. Estimar el tiempo de desarrollo necesario.    

2. Desarrollo: Diseño  



Diseñar 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 diseño. Ingresar en el log de tiempos, el tiempo total gastado en el diseño.

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, están 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 realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través 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 métodos aplicables al proceso de desarrollo de software, dentro de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicación y coordinación de los equipos de trabajo.

Proceso PSP El principal objetivo del proceso PSP, es proveer un Framework para escribir los programas y reunir información sobre tu trabajo, el proceso PSP provee algunos beneficios como:   

Una estructura conveniente para la realización de tareas a pequeña escala. Un Framework para medir estas tareas. Una base para la mejora de procesos.

El proceso se divide en tres partes principales Planeación, Desarrollos y Post Mortem. A continuación describo los principales objetivos objetivos de estas epatas, las cuales se ilustran en la Figura 1: 1. Planeación: Producir u obtener los requisitos del programa. Asegurar que los requerimientos son claros y sin ambigüedades. Resolver cualquier inquietud. Estimar el tiempo de desarrollo necesario.    

2. Desarrollo: Diseño  



Diseñar 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 diseño. Ingresar en el log de tiempos, el tiempo total gastado en el diseño.

Código  



Implementar el diseño. Ingresar en el log de defectos cualquier defecto encontrado con respecto al diseño. Ingresar en el log de tiempos, el tiempo total gastado en la codificación.

Compilación   



Compilar el programa hasta que no haya errores de compilación. Reparar todos los defectos encontrados. Ingresar en el log de defectos cualquier defecto encontrado con respecto al código. Ingresar en el log de tiempos, el tiempo total gastado en compilación.

Pruebas   



Probar hasta que no haya errores. Reparar todos los defectos encontrados. Ingresar en el log de defectos cualquier defecto encontrado con respecto al código. 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 tamaño 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 información guardada sobre los defectos y corregir. Corregir cualquier error en la recopilación r ecopilación de tiempos.

7 Niveles del PSP PSP 0 Identificar actividades: definición, secuencia Bases mejoras: planeación, evaluación, resultados Documentar proceso: Formas de: Actividades (Scripts) Tiempos (Logs Time) Defectos (Defect Logs) Resumir planes, resultados (Proyect plan summary)

PSP 0.1 Registrar tamaño del producto y hacer un histórico:   

Lineas de código Function points Estandarización de la codificación

Registrar problemas y mejoras de propuestas

PSP 1 Mejora la planeación:  

Con la estimación tamaño del producto (historico) Decidir en base a reportes de pruebas

PSP 1.1 Mejora la planeación:  

Con la estimación de recursos Introducción de calendarizar, plasmar el plan con números, un presupuesto.

PSP 2 Mejora la ejecución:    

Detección temprana de defectos, en base a la predicción de estos. Revisiones de diseño Revisiones de código Uso de checklists (Listas de verificación)

PSP 2.1 Mejora el diseño: 

Al hacer uso de formas detalladas de diseño (formas C76, C77)

PSP 3 Mejora el ciclo, mejora del proceso en términos de hacerlo repetible (ciclico):   

Para aplicación a programas de mayor tamaño Registro del seguimiento de asuntos importantes Análisis del resumen de la planeación, tiempos, tamaños 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. Más que clasificar un conjunto de sentencias como ventajas o desventajas, a continuación se citan algunas características: PSP es una metodología basada en estimación. La estimación permite saber cuándo y cómo se desarrollan las tareas de un proceso, por lo que podría citarse como un aspecto importante de esta metodología el estar basada en métricas y estimaciones. La información de las métricas 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 podría 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 cuántas líneas de código generan por hora, cuánto tiempo invierten al corregir un error, cuánto tiempo invierten en pruebas, etcétera. Los pasos de registro de información a detalle en el nivel de medición pueden resultar frustrantes cuando se tiene presión de tiempo. En los scripts de PSP no se incluyen tareas y actividades para la etapa de análisis de requerimientos. Siempre se parte de una definición de requerimientos que no va a cambiar.

Aún no existe una herramienta automatizada que facilite el registro y análisis de datos generados por la aplicación de PSP.

Especificación Requisitos y Planeación Diseño de Alto Nivel Revisión del Diseño de Alto Nivel Desarrollo Cíclico (Análisis Ciclo)

Especificación el ciclo Diseño detallado y su revisión Definición de pruebas y su revisión Implementación y Revisión de Código Compilación Pruebas Evaluación

PostMortem Integración Pruebas de Sistema Uso Producto

CICLO DE VIDA PSP, FASES Requisitos Planeación

Diseño de alto nivel

Revisión de alto nivel del diseño

Desarrollo cliclico

Post Mortem

Integración

Pruebas Producto

FASES DE PSP CICLO DE VIDA PSP, FASE REQUISITOS REQUISITOS    

Descripción del problema Especificación de componentes Formas de proceso Estimadores del tamaño del producto y tiempos en base a historicos

CICLO DE VIDA PSP, FASE PLANEACIÓN (PLAN DE PROYECTO) INPUT

Descripción del problema, resumen del proyecto, resumen cíclico, tamaño estimado, tiempo estimado, formas de planeación.

ACTIVIDAD Requerimientos, tamaño estimado, desarrollo estrategia, estimados de recursos, planificación y programas de tareas, estimación de defectos.

OUTPUT

Diseño conceptual, resumen plan, resumen del ciclo, patrones de estimados de tamaño y planeación de tareas, programas de patrones de planeación, registro de tiempos.

CICLO DE VIDA PSP, FASE DISEÑO DE PRODUCTO INPUT

Tipificación requerimientos, diseño conceptual, patrones de estimaciones de tamaño, resumen parte ciclico, seguimiento

ACTIVIDAD Especificaciones externas, diseño modular, prototipos, estrategia de desarrollo y documentación, seguimiento OUTPUT

Diseño de programa, escenarios operacionales, especificación de funciones y lógica, resumen cíclico, seguimiento y estrategias de pruebas y ciclo

CICLO DE VIDA PSP, FASE REVISIÓN O VALIDACIÓN DEL DISEÑO INPUT

Programa de diseño, escenarios operacionales, especificación de funciones y lógica, resumen ciclico, seguimiento y estrategia de pruebas y ciclo.

ACTIVIDAD Diseño de apariencia, verificación de máquinas y lógica, consistencia del diseño, reuso, estrategia de verificación, detectar errores. OUTPUT

Fiseño de alto nivel, registro de seguimiento, tiempos y defectos.

CICLO DE VIDA PSP, FASE DESARROLLO O IMPLEMENTACIÓN INPUT

Diseño de alto nivel, registro de seguimiento, tiempos y defectos, ciclo de desarrollo, estrategia de pruebas, patrones de operación y función.

ACTIVIDAD Diseño de módulos, revisión de diseño, código, revisión de código, compilación, pruebas, aseguramiento de calidad y del ciclo.

OUTPUT

Modulos de sw, patrón de diseño, lista de verificación de código y diseño, resumen del ciclo, patrón de reporte de pruebas, registro de tiempo, defectos y seguimiento.

CICLO DE VIDA PSP, FASE POSMORTEM, EVALUACIÓN CICLO INPUT

Definición de problema y requerimientos, plan de proyecto y de ciclo, producto de software, patrón de diseño, lista de verificación de código y diseño, resumen del ciclo, patrón de reporte de pruebas, registro de tiempo, defectos y seguimiento.

ACTIVIDAD Defectos previstos, removidos, tamaño, tiempo del producto. OUTPUT

Producto, listas de verificación, plan de proyecto y ciclo, patrón de reporte de pruebas y diseño, forma con propuesta de mejora, registro seguimiento pruebas y tiempo.

EJEMPLO DEL PROCESO PSP

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

Proyecto: AFG Autor: Ing. X Fecha: 07/04/08 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. ESTIMACIÓN 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 P royecto. Como el Ing. X está 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 aún 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 de Flujo, y anota el tiempo empleado en el cuaderno de registro de tiempos a continuación del anterior registro.

5. CODIFICACIÓN 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 CODIFICACIÓN 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. REVISIÓN DE CÓDIGO 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 COMPROBCIÓ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 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 de 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. 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 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. 10. POSTMORTEN 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 SAMANAL DE ACTIVIDADES A partir del cuaderno de registro de tiempos de las últimas semanas, el Ing. X puede obten er 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. ESTIMACIÓN DE NUEVOS PROYECTOS: Ahora para cualquier otro pedido de software X, ya contará 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