El proceso personal de software, PSP, 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, mediante el seguimiento del desempeño predicho frente al desempeño real. 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.
Con PSP los ingenieros de software pueden adquirir las habilidades necesarias para trabajar en un proceso de software en equipo TSP.
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.
PSP pretende formar ingenieros de software con métodos disciplinados para mejorar su desarrollo personal de software. PSP le ayuda a los desarrolladores a:
El entrenamiento de PSP sigue una metodología evolutiva de mejora: quien empieza a integrar PSP en su proceso comienza en el nivel PSP0 y progresa hasta alcanzar el nivel PSP2.1 que es el nivel máximo de madurez.
Cada nivel tiene guiones detallados, listas de chequeo y plantillas. Humphrey, creador de la metodología, motiva a los ingenieros experimentados a personalizarlos para que puedan aumentar el entendimiento de sus fortalezas y debilidades.
La entrada de PSP son los requerimientos; el documento de requerimientos es completado y entregado al ingeniero.
PSP0 tiene 3 fases: planeación, desarrollo (diseño, codificación, pruebas) y un post mortem. Se establece una base del proceso normal de medición: tiempo tomado programando, fallos inyectados/removidos, tamaño de un programa. En un post mortem el ingeniero asegura que todos los datos del proyecto hayan sido registrados y analizados correctamente. PSP0.1 agrega un estándar de código, una medida de tamaño y el desarrollo de un plan de mejora personal PIP. En el PIP el ingeniero registra ideas para mejorar su propio proceso.
Teniendo como base los datos recolectados en PSP0 y PSP0.1, el ingeniero estima el tamaño que tendrá el nuevo programa y prepara un reporte de pruebas (PSP1). Los datos recolectados para proyectos previos se usan para estimar el tiempo total. Cada proyecto nuevo registrará el tiempo gastado actualmente. Esta información es usada para tareas de agendamiento, planeación y estimación(PSP1.1).
PSP2 agrega dos fases nuevas: revisión de diseño y de código. Se enfoca en la prevención de defectos y su remoción. Los ingenieros aprenden a evaluar y mejorar su proceso midiendo la extensión de sus tareas y la cantidad de defectos inyectados y removidos en cada fase de desarrollo. Los ingenieros construyen y usan listas de chequeo para diseño y revisión de código.
PSP2.1 introduce especificaciones de diseño y técnicas de análisis.
(PSP3 es un legado de PSP que ha sido sustituido por TSP.)
Los niveles son:
Uno de los aspectos fundamentales de PSP es el uso de datos históricos para analizar y mejorar el desempeño del proceso. La recolección de datos para PSP es soportada por cuatro elementos importantes:
Los guiones de PSP proveen una guía de nivel experto para seguir los pasos del proceso, los guiones proveen un marco de trabajo para aplicar las mediciones. En PSP hay cuatro mediciones esenciales:
La aplicación de estándares al proceso puede asegurar que los datos sean precisos y consistentes. Los datos son registrados en formatos, frecuentemente son registrados en aplicaciones para medir PSP.
Los desarrolladores de software usan otras medidas, que se derivan de las esenciales, para entender su desempeño. Entre las medidas derivadas están:
El registro de tiempos, defectos, y tamaños es fundamental para planear y realizar seguimientos a los proyectos de PSP, los datos históricos son usados para mejorar la precisión estimación.
PSP usa el método PROBE para mejorar las habilidades de estimación de los desarrolladores para obtener más planeaciones más precisas. Para hacer el seguimiento del proyecto PSP usa el método del valor ganado (EV).
PSP también usa técnicas estadísticas, tales como correlación, regresión lineal, y desviación estándar, para traducir datos en información útil para mejorar la estimación, planeación y calidad. Las fórmulas estadísticas son calculadas por las herramientas para PSP.
Producir software de alta calidad es la meta de PSP, y la calidad es medida en términos de defectos. Para PSP, un proceso de calidad debería producir software de pocos defectos que cumple con las necesidades del usuario.
PSP permite a los desarrolladores encontrar defectos en fases tempranas. Al encontrarlos pronto, PSP reduce la cantidad de tiempo gastado en fases posteriores como la fase de pruebas.
Según PSP es más económico y efectivo remover defectos tan pronto como sea posible. Se exhorta a los ingenieros de software a realizar revisiones personales para cada fase del desarrollo. Por lo tanto PSP incluye dos fases de revisión:
Para realizar una revisión efectiva, usted necesita seguir un proceso de revisión estructurado. PSP recomienda usar listas de verificación para ayudar a los desarrolladores a seguir un procedimiento ordenado.
PSP sigue la premisa que cuando la gente comete errores, sus errores son usualmente predecibles, así los desarrolladores PSP pueden personalizar sus listas de verificación, para revisar sus propios errores. También se espera que los ingenieros de software realicen propuestas de mejora, para identificar debilidades en su desempeño actual enfocándose en corregirlas. Los datos históricos del proyecto, los cuales exponen dónde se gasta el tiempo y los defectos introducidos, ayudan a los desarrolladores a identificar áreas para mejorar.
PSP es un proceso personal que puede ser adaptado a las necesidades individuales de cada desarrollador. PSP no es específico para un lenguaje de programación o metodología de diseño; por lo tanto puede usarse con diferentes metodologías inclusive desarrollo Ágil de software.
Los métodos de la ingeniería de software pueden variar desde predictivos hasta adaptativos. PSP es una metodología predictiva, desarrollo Ágil es considerada una metodología adaptiva, pero a pesar de sus diferencias, TSP/PSP y desarrollo Ágil comparten varios conceptos aproximaciones – particulmente en cuanto a la organización del equipo. Con ambos es posible:
Desarrollo Ágil y TSP/PSP comparten la idea que los miembros del equipo se responsabilicen por su propio trabajo y trabajen juntos para acordar un plan realista, crear un ambiente de confianza y responsabilidad. Sin embargo, el TSP/PSP se diferencia del desarrollo Ágil en su énfasis en la documentación del proceso y el uso de datos para predecir y definir la agenda del proyecto.
Frente a UML, PSP obtiene la información de la interacción dinámica y estática, interna y externa capturando datos con formatos que se asemejan a los formatos de los de casos de uso, los diagramas de secuencias, y de clases. Basado en un diagrama UML se puede obtener la información base para crear ciertos formatos de PSP.
El Software Engineering Institute (SEI), de la Universidad Carnegie Mellon ofrece una certificación en PSP. Los pasos para hacerse un desarrollador certificado en PSP son: aprender PSP, realizar el examen de certificación, mantener las credenciales.
Escribe un comentario o lo que quieras sobre Personal Software Process (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)