PSP Personal Software Process

El proceso personal de software Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.

Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.

Niveles

• Nivel 1 - inicial:
  • Seguimiento y control de proyectos.
  • Planeación de los proyectos.
• Nivel 2 - repetible:
  • Revisión entre colegas.
  • Ingeniería del producto de software.
  • Manejo integrado del software.
  • Definición del proceso de software.
  • Foco del proceso de software.
• Nivel 3 - Definido:
  • Control de calidad.
  • Administración cuantitativa del proyecto.
• Nivel 4 - Controlado:
  • Administración de los cambios del proceso.
  • Administración del cambio tecnológico.
  • Prevención de defectos....

ANTECEDENTES, justificación

Los ingenieros de software rara vez basan su trabajo en prácticas y metodologías establecidas y son prácticamnete excépticos a cambiar sus hábitos de trabajo. Los ingenieros estan en un círculo vicioso, "sólo creen en lo que han probado y no prueban otras metodologías", por esta rezón para poder implantar PSP, se tuvo que obligarlos y se tuvieron buenos resultados.

PASOS PARA IMPLANTACION PSP

Los ingenieros deben ser entrenados por un instructor calificado de PSP. La Capacitacion es sobre grupos o equipos, y seran grupos que asi lo han sido y seguiran siendo. Requiere un fuerte soporte de administración, en este sentido es necesario que los administradores entiendan el PSP, saber como apoyarlos y como monitorear sus avances, sin un adecuado monitoreo los ingenieros caeran otra vez en los malos habitos. Después de ser bien entrenados y bien administrados lo que sigue es optimizar la interaccion entre equipos y aquí entraría Team Software Process, el TSP extiende y refina los metodos de CMM y PSP sobre desarrollo y mantenimiento de equipos, y llegar a lo que se le llama un equipo autodirigido. Requisitos Planeación Diseño de alto nivel Revisión de alto nivel del diseño Desarrollo cliclico Post Mortem Integración Pruebas Producto 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. 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.