Proyecto de Construcción de Software Notas de Clase. Facultad de Tecnología Informática Ingeniería en Informática

Transcripción

1 Facultad de Tecnología Informática Ingeniería en Informática Proyecto de Construcción de Software Notas de Clase Guía para aplicar el Proceso Personal de Software Profesora: Prof. Graciela D. S. Hadad

2

3 Facultad de Tecnología Informática Proyecto de Construcción de Software Notas de Clase Guía para aplicar el Proceso Personal de Software Prof. Graciela D. S. Hadad Ciclo Académico: 2011

4 Índice 1 Introducción Principios de PSP Objetivos de PSP El Proceso PSP Medidas en PSP Medidas de Tiempo Medidas de Tamaño Medidas de Calidad Medidas de Cronograma Gestión del Tiempo Cuaderno de Registro de Tiempos Gestión de las Interrupciones Control de las Tareas Finalizadas Recomendaciones para registrar el tiempo Resumen periódico de las actividades Gestión de la Calidad Cuaderno de Registro de Defectos Estándar de Tipos de Defectos Estándar de Codificación Planificación Plan Resumen del Proyecto Cronograma Cuaderno de Notas de Ingeniería Propuesta de Mejoras al Proceso Bibliografía... 17

5 1 Introducción El Proceso Personal de Software (PSP: Personal Software Process) fue definido por Watts S. Humphrey del Software Engineering Institute (SEI) en Carnegie Mellon University. Propone a los ingenieros de software una forma disciplinada de estructurar su trabajo personal. PSP consta de métodos, formularios y procedimientos que ayudan a los ingenieros de software a planificar, medir, y gestionar su trabajo. PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos. PSP sirve para trabajar con cualquier lenguaje de programación y metodología de diseño, y contempla la mayoría de los aspectos del desarrollo de software, como especificación de requerimientos, pruebas, definición de procesos y eliminación de defectos. Al usar PSP, el objetivo del proceso debería ser obtener productos sin defectos y dentro de los plazos y costos previstos. A continuación se detallan los principios base y los objetivos que se persiguen con PSP. 1.1 Principios de PSP PSP se basa en los siguientes principios de planificación y calidad: - Cada ingeniero es diferente; para ser más eficaces, los ingenieros deben planear su trabajo, y deben basar sus planes en sus propios datos personales. - Para mejorar consistentemente su eficiencia, los ingenieros deben usar personalmente procesos bien definidos y medidos. - Para producir productos de calidad, los ingenieros deben sentirse personalmente responsables por la calidad de sus productos. Los productos superiores no se producen al azar; los ingenieros deben esforzarse para hacer trabajos de calidad. - Cuesta menos encontrar y corregir defectos tempranamente en un proceso que tardíamente. - Es más eficiente prevenir defectos que encontrarlos y corregirlos. - La manera correcta es siempre la manera más rápida y más barata de hacer un trabajo. UB FTI Proyecto de Construcción de Software Guía PSP

6 1.2 Objetivos de PSP - Planificar el trabajo - Esforzarse para cumplir la planificación - Esforzarse para obtener productos de la mejor calidad. 2 El Proceso PSP Se debe seguir un proceso sistemático que ayude a planificar y gestionar el trabajo. Se define proceso como un conjunto definido de pasos para hacer un trabajo. PSP se describe en función de guiones ( scripts ) que brindan orientación para las fases (planificar, desarrollo, postmortem) que se llevan a cabo a partir de los requisitos y hasta terminar en el producto acabado. Estas actividades dan lugar al registro de datos de defectos y de tiempos en cuadernos, a partir de los cuales se obtienen datos reales que se comparan con los datos del plan, lo que sirve para tomar decisiones de mejoras al proceso. El proceso PSP consta de tres fases, como se muestra en la Figura 1: Requisitos Planificación Desarrollo Post Mortem Figura 1. Proceso básico de PSP Producto Final Datos del Proyecto y del Proceso 1) Planificación: elaborar un plan para hacer el trabajo. 2) Desarrollo: realizar el trabajo. a) Diseñar en base a los requisitos b) Revisar el diseño y corregir defectos c) Codificar d) Revisar el código y corregir defectos e) Compilar y corregir defectos f) Probar el código y corregir defectos UB FTI Proyecto de Construcción de Software Guía PSP

7 3) Post Mortem: analizar el proceso. En la planificación, se definen los requisitos y se genera un diseño conceptual. En base a este, se estima el tamaño del software a producir y se estima el tiempo requerido en cada etapa del desarrollo. Se produce un Plan Resumen del Proyecto con estos datos estimados. Durante el desarrollo, se registran los tiempos utilizados y los defectos detectados en cada actividad. Al finalizar el desarrollo, en la fase de post mortem, se compara el desempeño real contra lo planeado. Para ello, se totalizan los tiempos y defectos registrados, se mide el tamaño del código, se registran estos datos en el Plan Resumen del Proyecto, y se documentan todas las ideas sobre mejoras al proceso. En la Figura 2 (extraída de Humphrey, 2000) se muestra el flujo completo de PSP, incluyendo las sub-actividades de desarrollo y los productos intermedios que se generan. Figura 2. Flujo de PSP Algunos formularios que se completan o generan a lo largo del proceso son: - Plan Resumen del Proyecto (ver la Figura 3) - Cronograma - Cuaderno de Notas de Ingeniería - Cuaderno de Registro de Tiempos - Cuaderno de Registro de Defectos - Reporte de Pruebas UB FTI Proyecto de Construcción de Software Guía PSP

8 - Propuesta de Mejoras al Proceso - Estándar de Codificación - Estándar de Tipos de Defectos En resumen, hay dos actividades básicas a realizar: medir y estimar. Para poder estimar es necesario tener una historia de mediciones realizadas, sino la estimación se realizaría al vuelo. Qué se mide? El tiempo insumido en las tareas, los defectos encontrados en los productos generados, el tamaño de los productos. Por qué estos elementos? Dan una idea de la productividad, pues ellos indican cuánto se produjo, en cuánto tiempo y con qué calidad. Si se tienen mediciones realizadas, se podrán realizar estimaciones en el próximo proyecto. Qué se estima? El tamaño del producto a generar, qué tareas realizar y cuánto tiempo insumirá cada una. 3 Medidas en PSP Los ingenieros usan datos para controlar su trabajo y ayudar a mejorar la realización de planes. Para ello deben recolectar datos sobre el tiempo que usaron en cada fase del proceso, sobre el tamaño de los productos que generaron y sobre la calidad de esos productos. Las medidas básicas de PSP son entonces: tiempo, tamaño, calidad (defectos) y datos del cronograma. 3.1 Medidas de Tiempo El tiempo se mide en minutos y se registra mientras se hace el trabajo. Si se lo registra posteriormente es más probable que no sea exacto. Los ingenieros usan un Cuaderno de Registro de Tiempo individual, donde anotan, por cada tarea que realizan, la hora de comienzo y fin, el tiempo de interrupciones y la duración real de la tarea. Una interrupción puede ser por ejemplo, una llamada telefónica, un pequeño receso, una pregunta que hace alguien. Estas medidas de tiempo permitirán establecer el avance del proyecto y determinar si se está cumpliendo con los plazos estimados en el plan. Ver más detalles en la sección Medidas de Tamaño Una medida de tamaño se usa para establecer cuán grande es un producto. UB FTI Proyecto de Construcción de Software Guía PSP

9 Esto es necesario pues el tiempo que lleva desarrollar un producto depende de su tamaño. Lo primero que debe hacerse al planificar es entonces estimar el tamaño de lo que se va a producir. Las medidas de tamaño a elegir dependen del producto a generar. Por ejemplo, se usa cantidad de páginas para medir un documento, cantidad de elementos para medir un diagrama o líneas de código para medir un programa. Líneas de código (LOC: lines of code) es la medida principal de PSP. Las medidas de tamaño también deben registrarse a medida que se generan los productos, para lograr mayor exactitud en el tamaño. Las medidas de tamaño no solo se aplican al producto final sino también a las partes o componentes del producto y a las versiones intermedias del mismo. Algunas medidas típicas pueden ser: - Elementos de una Base de Datos: contar registros, campos, consultas u otros elementos típicos en un producto de base de datos. - Líneas de código (LOC): contar las líneas de código lógicas de un producto. - Elementos de una pantalla: contar los elementos o controles en una interfaz gráfica de usuario. - Tamaño de un documento: contar páginas, líneas, palabras o caracteres. - Tamaño de un diseño: contar clases, definiciones de datos, especificaciones de interfaces. - Tamaño de Requisitos: contar páginas del documento de requisitos, sentencias de requisitos, o puntos de función. Por otro lado, también se debe determinar cómo tomar estas medidas de tamaño. Para ello se define un estándar, que indicará por ejemplo cómo contar las LOC: - Líneas modificadas o eliminadas - Líneas en blanco o líneas de comentario - Líneas con múltiples sentencias - Sentencias vacías o nulas, tales como continue, break, ;, - Archivos incluidos (se cuentan una o varias veces). - Funciones Inline o macros - Declaraciones - Etiquetas o rótulos - Símbolos tales como { }, begin / end, then, else, case, UB FTI Proyecto de Construcción de Software Guía PSP

10 3.3 Medidas de Calidad En PSP la calidad del producto se mide principalmente en términos de defectos. Un defecto es aquello en un programa o producto de software que debe cambiarse para estar adecuadamente diseñado, desarrollado, mantenido, mejorado o usado. Los defectos pueden estar en el código, en el diseño, en la especificación de requisitos o en cualquier otra documentación. Un defecto puede ser, por ejemplo, un error ortográfico, un error de puntuación o una sentencia de código incorrecta. Los defectos también deben registrarse a medida que se descubren. Debe registrarse en qué momento se originó el defecto, cuándo se encontró y se corrigió, y cuánto tiempo llevó corregirlo. Ver más detalles en la sección 5. Las medidas principales de calidad que utiliza PSP son: - Densidad de defectos: cantidad de defectos detectados por cada mil líneas de código (KLOC). - Velocidad en revisiones de diseño o de código. - Proporciones de tiempo de desarrollo: i) tiempo de diseño sobre tiempo de codificación, ii) tiempo de revisión de diseño sobre tiempo de diseño, y iii) tiempo de revisión de código sobre tiempo de codificación. - Índices de defectos: compara defectos encontrados en una fase contra defectos encontrados en otra fase. Los dos índices principales son: i) defectos detectados al revisar código dividido por defectos detectados en compilación, y ii) defectos detectados al revisar diseño dividido por defectos detectados durante las pruebas unitarias. - Rendimiento: porcentaje de defectos encontrados y eliminados en una fase respecto del total de defectos. - Defectos por hora: cantidad de defectos que se introducen al producto por hora y cantidad de defectos que se corrigen por hora. - Efectividad en la eliminación de defectos. - Valoración de la proporción de fracasos: mide el costo de obtener calidad, considerando el tiempo ocupado en revisiones de diseño y de código, incluyendo los tiempos de corrección de los defectos detectados. 3.4 Medidas de Cronograma Las medidas de cronograma se utilizan para planificar el proyecto (cuándo debe finalizar) y controlar el avance del proyecto según el plan. En el cronograma se debe registrar: el nombre y descripción de cada tarea planificada, fases en las que se desarrollan, el producto involucrado, las fechas UB FTI Proyecto de Construcción de Software Guía PSP

11 comprometidas para completar las tareas y las fechas en que efectivamente se completaron las tareas. Los datos del cronograma deben registrarse a medida que ocurren, en particular la información sobre las fechas de finalización de las tareas. Esto sirve para calcular el valor ganado que permite a cada persona seguir su progreso en relación al cronograma planeado. El valor ganado ( earned value ) mide el costo presupuestado de la cantidad de trabajo terminado en un momento dado del proyecto. 4 Gestión del Tiempo La gestión del tiempo permite: - hacer planes realistas - intentar seguir el plan - controlar el uso del tiempo Para comprender cómo se utiliza el tiempo se debe: - Clasificar las actividades - Medir y registrar los tiempos dedicados a dichas actividades - Hacer registros normalizados de tiempos - Conservar los registros adecuadamente El objetivo de registrar el tiempo es el de obtener datos de cómo se trabaja realmente. Para ello se utiliza el Cuaderno de Registro de Tiempos. La forma y el procedimiento utilizados para reunir los datos no son tan importantes mientras los datos sean exactos y completos. Es recomendable controlar el tiempo en unidades pequeñas. Aunque generalmente se lo controla en horas, PSP aconseja controlar el tiempo en minutos. Práctica de la gestión del tiempo. Cada individuo tiene la capacidad para decidir en qué utilizar su tiempo, para lo cual tiene que tener claro en qué lo utiliza habitualmente y cómo establecer reglas básicas para transferir el tiempo dedicado de algunas actividades a otras y controlarlo. Cuando se desarrollan programas, se realizan pruebas del sistema o se documenta un trabajo, se necesita saber cuánto tiempo ha requerido y cuánto trabajo se ha realizado, y así se podrá calcular la productividad de la tarea. Con este conocimiento se puede mejorar la planificación de futuros proyectos. UB FTI Proyecto de Construcción de Software Guía PSP

12 4.1 Cuaderno de Registro de Tiempos El Cuaderno de Registro de Tiempos se utiliza para anotar individualmente el tiempo ocupado en cada actividad del proceso. Este Cuaderno debe contener los siguientes datos por cada actividad realizada: - fecha de realización de la actividad - hora de inicio de la actividad - hora de finalización de la actividad - tiempo perdido por interrupciones - tiempo dedicado a la actividad en minutos (hora de fin hora de comienzo descartando tiempo de interrupciones) - descripción de la actividad (o fase del proceso) - descripción completa de la actividad (comentarios) En el cuaderno también se indica la cantidad de unidades de trabajo realizadas y si se completó la tarea o no (ver sub-sección 4.3). Este cuaderno puede integrarse al Cuaderno de Notas de Ingeniería (ver subsección 6.3). 4.2 Gestión de las Interrupciones Las interrupciones son inevitables y frecuentes. Dado que el tiempo de las interrupciones no es tiempo de trabajo productivo, se debe controlar su frecuencia y duración, es por ello que deben anotarse en el Cuaderno de Registro de Tiempos en una columna separada. Si la cantidad de este tiempo fuese constante no habría que hacer mucho para gestionarlo. Sin embargo, el tiempo de las interrupciones es muy variable. Si no se mide, habría que añadir un número aleatorio en todos los datos de tiempos, lo que haría más difícil utilizar estos datos para planificar o gestionar el tiempo. Esos datos registrados pueden utilizarse para comprender con qué frecuencia se interrumpe el trabajo. Las interrupciones no son solamente un despilfarro de tiempo, sino que rompen el ritmo de pensamiento, llevando a la ineficiencia y al error. Comprender cómo se es interrumpido ayuda a mejorar la calidad y eficiencia del trabajo. 4.3 Control de las Tareas Finalizadas Para controlar cómo se gasta el tiempo se necesita controlar los resultados producidos. No solo se necesita saber el tiempo insumido sino también cuánto trabajo se realizó. UB FTI Proyecto de Construcción de Software Guía PSP

13 Por ello, se agregan dos columnas al Cuaderno de Registro de Tiempos: Tarea Completada y Cantidad de Unidades de Trabajo. Estas columnas ayudan a identificar rápidamente el tiempo dedicado a las distintas tareas y lo que se ha hecho. Por ejemplo, cuando se ha terminado de codificar una clase significa que se ha completado una unidad de trabajo. Un diagrama acabado es otra unidad de trabajo. Para rellenar la columna Tarea Completada hay que comprobar cuándo se ha terminado dicha tarea. Para tener registros de tiempos exactos, es importante completar ambas columnas cada vez que se finaliza una tarea que tiene resultados medibles. 4.4 Recomendaciones para registrar el tiempo El control del tiempo es sencillo. Recomendaciones para ayudar a hacerlo de forma más consistente y precisa: - Llevar siempre el Cuaderno de Notas de Ingeniería. - Cuando ocasionalmente se olvide de registrar la hora de comienzo, la hora de fin o la duración de la interrupción, hacer una estimación tan pronto uno lo recuerda. - Se puede utilizar un cronómetro para controlar las interrupciones. Puede parecer excesivamente preciso pero así es más sencillo registrar el tiempo de inicio y finalización de cada interrupción. - Resumir el tiempo utilizado puntualmente. Utilizar el Resumen Semanal de Actividades para resumir semanalmente el tiempo. - Los registros personales se pueden llevar a mano para más comodidad, pero los resúmenes periódicos se deben realizar en la computadora. 4.5 Resumen periódico de las actividades Para hacer una planificación correcta es importante conocer cómo se gasta el tiempo. El primer paso es registrar el tiempo utilizando el Cuaderno de Registro de Tiempos. Después de reunir los datos de tiempo durante una o dos semanas, se empezará a ver cómo se emplea el tiempo. Puesto que los registros de tiempos son muy detallados para el propósito de la planificación, se necesita resumir los datos de una forma más útil, para ello se genera el Resumen Semanal de Actividades, que debe confeccionar cada miembro del equipo de desarrollo. Este resumen semanal se lleva por actividad, donde se pueden agregar promedios, máximos y mínimos. Los datos de este resumen semanal se resumirán cada tres semanas en una tabla similar que englobará los datos de todos los miembros del equipo. Es decir, se tendrá entonces: los cuadernos de registro de tiempos y los resúmenes semanales de cada miembro del grupo, así como el resumen de UB FTI Proyecto de Construcción de Software Guía PSP

14 todo el equipo. 5 Gestión de la Calidad PSP mide la calidad en función de los defectos detectados y corregidos. Se define al defecto como la consecuencia de errores cometidos por personas al considerar los requisitos, al diseñar o al escribir el programa, y que tienen efectos potencialmente desastrosos para el procesamiento. Es importante entender los defectos, registrando información sobre cada defecto a fin de analizarlos e idear formas de encontrarlos y corregirlos. Por ello se propone un Cuaderno de Registro de Defectos que facilita el análisis de la información sobre los defectos para mejorar la programación, reducir el número de defectos y ahorrar tiempo y dinero, haciendo el trabajo en forma responsable. También esta información se debe volcar o integrar al Plan Resumen del Proyecto. Para facilitar el registro de defectos, estos se tipifican. Es conveniente entonces desarrollar un estándar de tipos de defectos. Se hace hincapié en la forma de encontrar los defectos: el compilador (para la mayor parte de los defectos sintácticos), las pruebas (para algunos defectos de ejecución), los usuarios (para los que no se encontraron antes) y las revisiones de código. Estas se realizan después de escribir el código y antes de compilarlo o probarlo, y se concentra no en los síntomas sino en los problemas, es por ello que resultan mucho más eficientes que otras técnicas de verificación. Para la revisión de código se proponen listas de comprobación ( checklists ), que ayudan a encontrar los defectos, agregando ejemplos y consejos para utilizarlas o personalizarlas. Estas checklists se completan con información de estándares de codificación o prácticas de estilo para la escritura de programas, que los hacen más legibles y fácilmente comprensibles. 5.1 Cuaderno de Registro de Defectos El Cuaderno de Registro de Defectos se usa para anotar cada defecto encontrado y corregido. El cuaderno debe incluir los siguientes datos: - Fecha en que se detecta el defecto. - Número identificatorio del defecto. - Tipo de defecto (ver sub-sección 5.2). - Fase en la que el defecto se originó. - Fase en la que el defecto se eliminó. - Tiempo requerido para corregir el defecto. UB FTI Proyecto de Construcción de Software Guía PSP

15 - Si el defecto se agregó mientras se corregía otro defecto, debe identificar el número de defecto original. - Una breve descripción del defecto. El tiempo requerido para corregir cada defecto incluye el tiempo total requerido para encontrarlo, solucionarlo y validar la corrección. 5.2 Estándar de Tipos de Defectos Se debe usar algún estándar de tipos de defectos y codificarlo. Por ejemplo: No. Descripción 10 Comentarios para documentación, mensajes 20 Sintaxis, ortografía, signos de puntuación, formatos 30 Construcción, gestión de cambios, biblioteca, control de versiones 40 Declaración de asignación, nombres duplicados, alcance, límites 50 Llamadas y referencias a procedimientos de interfaz, entradas/salidas, formatos de usuarios 60 Control de mensajes de error, controles inadecuados 70 Estructura de datos, contenido 80 funciones, punteros, bucles, recursividad, cálculos 90 Configuración del sistema, tiempos, memoria 100 Diseño del ambiente, compilación, prueba y otros problemas del sistema de soporte 5.3 Estándar de Codificación Se debería desarrollar un estándar de codificación teniendo en cuenta los siguientes ítems: - Encabezados - Uso y reuso - Identificadores - Comentarios - Secciones principales - Espacios en blanco - Indentación UB FTI Proyecto de Construcción de Software Guía PSP

16 - Uso de mayúsculas ( capitalization ) El estándar debería incluir definiciones y ejemplos. 6 Planificación La planificación del producto es aplicable a cualquier cosa: escribir un programa, leer un libro, preparar un informe. El primer paso consiste en definir claramente qué se está intentando hacer (el qué). A partir de ello se puede comenzar a planificar (el cómo), lo cual requiere tres cosas: 1. establecer el tamaño y las características más importantes, 2. estimar el tiempo requerido para hacerlo, y 3. en el caso de proyectos más complejos, ordenar (programar) las tareas a realizar. Se deben registrar los tiempos dedicados a un trabajo determinado, y comparar lo insumido contra lo previsto, tomando en cuenta la cantidad realizada y facilitando calcular velocidades (promedio, máximos y mínimos). También entra en consideración el tamaño del producto, que permite estimar mejor y corregir los tiempos. Es importante el concepto de compromiso. Se deben establecer condiciones o responsabilidades para asumir y gestionar compromisos: analizar el trabajo antes de asumirlo, apoyarlo con un plan, e informar a la otra parte cuando se tienen dificultades para cumplirlo. Se realiza la programación de un proyecto utilizando un simple diagrama de Gantt, haciendo hincapié en los puntos de control, el seguimiento y la asignación de un valor a los resultados. Se genera entonces el Plan Resumen del Proyecto. Se estiman las actividades, el tiempo que insumirán, el tamaño o cantidad de instrucciones involucradas, dejando prevista la posibilidad de comparar contra los resultados reales. 6.1 Plan Resumen del Proyecto El Plan Resumen del Proyecto contiene datos estimados y datos reales (lo efectivamente realizado). Ver la Figura 3 extraída de Humphrey, El plan debe incluir lo siguiente: - Estimación original de LOC que se espera desarrollar. UB FTI Proyecto de Construcción de Software Guía PSP

17 - LOC real desarrollado. - Estimación original del tiempo requerido en cada fase. - Tiempo real requerido por cada fase. - La cantidad total y el porcentaje de defectos originados en cada fase. - La cantidad total y el porcentaje de defectos eliminados en cada fase. Figura 3. Plan Resumen del Proyecto 6.2 Cronograma El cronograma se usa para registrar las horas reales usadas en el período. Se UB FTI Proyecto de Construcción de Software Guía PSP

18 utiliza para relacionar las tareas planeadas con el calendario planeado. Los cronogramas pueden establecerse por semanas. Para proyectos pequeños, puede ser mejor control el esfuerzo por día. El cronograma debe contener lo siguiente, considerándolo por semana: - Número de semana por cada semana, comenzando por la semana 1. - Fecha por cada semana, generalmente se coloca la fecha del primer día hábil de cada semana. - Horas que se planea trabajar en el proyecto esa semana. - Horas planeadas acumuladas. - Horas reales trabajadas en el proyecto en esa semana. - Horas reales acumuladas. 6.3 Cuaderno de Notas de Ingeniería El Cuaderno de Notas de Ingeniería es un registro cronológico de actividades; apuntes y notas de diseño o revisión; con un índice que facilite la búsqueda de información registrada. Sirve para organizarse y registrar las actividades a fin de planificar, registrar lo que se planifica y compararlo contra lo realmente realizado. Es un cuaderno de trabajo individual para controlar compromisos, anotar ideas de diseño y cálculos, registrar tiempos, anotar problemas durante el trabajo, registrar soluciones a problemas. Puede ser útil como justificativo en caso de problemas. Permite anotar en todo momento lo relevante que va ocurriendo del proyecto. 7 Propuesta de Mejoras al Proceso La Propuesta de Mejoras al Proceso provee un registro de problemas del proceso y de ideas para mejorarlo. Debe contener los siguientes ítems: - Describir los problemas encontrados en el proyecto. Numerar cada problema. Describir cualquier dificultad. Describir el impacto que el problema tuvo sobre el producto o el proceso. UB FTI Proyecto de Construcción de Software Guía PSP

19 - Describir propuestas para mejorar el proceso. Numerar cada propuesta. Identificar el elemento específico del proceso que afecta. Relacionar la propuesta con el problema. Asignar una prioridad a la propuesta y justificar su importancia. - Agregar comentarios generales acerca del proyecto. Lecciones aprendidas. Condiciones por las que el proceso funcionó particularmente bien o pobremente. 8 Bibliografía - Introducción al Proceso Software Personal (PSP), Watts S. Humphrey, Addison Wesley, ISBN: , A Discipline for Software Engineering, Watts S. Humphrey, Addison- Wesley Professional, ISBN: , The Personal Software Process (PSP), Watts S. Humphrey, SEI, Reporte Técnico CMU/SEI-2000-TR-022, The Personal Software Process (PSP) Body of Knowledge, Version 2.0, Marsha Pomeroy-Huff, Robert Cannon, Timothy A. Chick, Julia Mullaney, William Nichols, SEI, Reporte Técnico CMU/SEI-2009-SR-018, The Personal Software Process. A Software Engineering Seminar, Mike Grasso, Tutorial, University of Maryland Baltimore County UB FTI Proyecto de Construcción de Software Guía PSP