Personal software process
- 2. PSP es un proceso de auto-mejora que nos ayuda a controlar, gestionar y mejorar la forma en la que realizamos nuestro trabajo. Es un marco de trabajo estructurado, compuesto de guías y procedimientos para desarrollar software. Usado de manera adecuada el PSP nos brinda la información necesaria para hacer y cumplir compromisos (en términos de calidad y calendario) y hacer mas eficiente y predecible la forma en que realizamos el trabajo.
- 3. La filosofía del PSP se basa en: Para mejorar su rendimiento y calidad, los desarrolladores deben medir su trabajo, analizar sus resultados y trazarse metas de mejora usándolos Cada Desarrollador es absolutamente diferente, pero para ser efectivos, los desarrolladores deben planear su trabajo usando como referencia su información histórica (Comportamiento en proyectos anteriores)
- 4. La Calidad del Producto/Software/Proyecto es responsabilidad del quien lo desarrolla (El Desarrollador) y dicha calidad no es accidental, exigiendo de los desarrolladores un compromiso personal. Encontrar los defectos (errores, bugs, requerimientos no contemplados, etc) en fases tempranas del Proceso es mucho menos costoso que encontrarlas en Pruebas de Unidad, del Sistema, de Integración y mucho mas que cuando son encontrados por el usuario
- 5. El PSP se compone de 4 elementos fundamentales, que unidos aportan las herramientas para la mejora continua, estos elementos son: Scripts: Son los elementos que documentan el proceso e indican que hacer y cuando hacerlo. Siendo apegados a la definición formal, su propósito es proveer una guía de alto nivel de como usar el proceso. Un ejemplo puede ser el siguiente (Script general del Proceso)
- 6. Medidas: Miden el proceso y el producto, muestran si las cosas están funcionando bien. Algunas de las medidas que PSP recoge se enfoca en 4 aspectos, Tamaño, Esfuerzo, Calidad y Programación (Agenda ó Cronograma) Formas: Son formularios para recopilar de manera sencilla y consistente la información. Entre los mas básicos: Log de Tiempo (Donde se almacena cuando se invierte en cada fase o tarea del proyecto), Log de Defectos (En el cual se recopila la información de los defectos encontrados) Estándares: Definen como yo (personalmente) hago las cosas. Por ejemplo: Estándar de Código (Permite saber como cada uno de los desarrolladores escribirá su código)
- 7. PSP y posteriormente TSP (Team Software Process) se aprenden de manera incremental, iniciando por PSP0, PSP1, PSP2 y luego TSP. Existen unos procesos transicionales PSP0.1 y PSP2.1, el siguiente gráfico trata de mostrarlo mejor.
- 8. En PSP0 y PSP0.1 se aprende a usar de manera eficiente y eficaz un proceso y a recopilar información, siendo tal vez el punto donde muchos desarrolladores se hacen a un lado pues nunca o muy pocas veces nos hemos preocupado por saber cuanto tiempo nos demoramos haciendo XYZ tarea del proyecto o cuanto invertimos en las pruebas o cuanto nos demoramos corrigiendo un defecto (error/cambio). Esta parte del proceso es particularmente sorprendente! En PSP1 se conoce como estimar el tamaño de un producto de software partiendo claro está, de información histórica y si no se tiene se acude a una excelente herramienta de estimación llamada PROBE, donde con un diseño conceptual encontramos partes del producto y estimamos de acuerdo a unas tablas relativas de tamaño. Básicamente se contestan estas preguntas ¿cuan grande será mi producto (Tamaño)? ¿Cuanto esfuerzo tendré que usar para terminarlo? PSP2 y PSP2.1 son especialmente interesantes para los amantes del Diseño y la Calidad, pues a través de “artefactos” de Diseño, se desarrollan diseños detallados del producto y se incorporan nuevas actividades de