El proceso de software personal ( PSP ) es un proceso de desarrollo de software estructurado que está diseñado para ayudar a los ingenieros de software a comprender y mejorar su desempeño aportando disciplina a la forma en que desarrollan software y rastreando el desarrollo real y previsto del código. Muestra claramente a los desarrolladores cómo gestionar la calidad de sus productos, cómo elaborar un plan sólido y cómo asumir compromisos. También les ofrece los datos para justificar sus planes. Pueden evaluar su trabajo y sugerir direcciones de mejora analizando y revisando el tiempo de desarrollo, los defectos y los datos de tamaño. El PSP fue creado por Watts Humphrey para aplicar los principios subyacentes del Modelo de Madurez de Capacidad (CMM ) del Instituto de Ingeniería de Software (SEI ) a las prácticas de desarrollo de software de un solo desarrollador. Pretende brindar a los ingenieros de software las habilidades de proceso necesarias para trabajar en un equipo de procesos de software en equipo (TSP).
"Personal Software Process" y " PSP " son marcas de servicio registradas de la Universidad Carnegie Mellon . [1] [2]
El PSP tiene como objetivo proporcionar a los ingenieros de software métodos disciplinados para mejorar los procesos de desarrollo de software personal. El PSP ayuda a los ingenieros de software a:
La formación de PSP sigue un enfoque de mejora evolutiva: un ingeniero que aprende a integrar el PSP en su proceso comienza en el primer nivel (PSP0) y progresa en la madurez del proceso hasta el nivel final (PSP2.1). Cada nivel tiene guiones detallados, listas de verificación y plantillas para guiar al ingeniero a través de los pasos requeridos y ayudarlo a mejorar su propio proceso de software personal. Humphrey anima a los ingenieros competentes a personalizar estos scripts y plantillas a medida que comprenden sus propias fortalezas y debilidades.
El insumo de PSP son los requisitos; El documento de requisitos se completa y se entrega al ingeniero.
PSP0 tiene 3 fases: planificación, desarrollo (diseño, código, compilación, prueba) y autopsia. Se establece una línea de base para medir el proceso actual: tiempo dedicado a la programación, fallas inyectadas/eliminadas y tamaño de un programa. En una autopsia, el ingeniero se asegura de que todos los datos de los proyectos se hayan registrado y analizado correctamente. PSP0.1 avanza el proceso agregando un estándar de codificación, una medición de tamaño y el desarrollo de un plan de mejora de procesos personal (PIP). En el PIP, el ingeniero registra ideas para mejorar su propio proceso.
Con base en los datos de referencia recopilados en PSP0 y PSP0.1, el ingeniero estima el tamaño de un nuevo programa y prepara un informe de prueba (PSP1). Los datos acumulados de proyectos anteriores se utilizan para estimar el tiempo total. Cada nuevo proyecto registrará el tiempo real invertido. Esta información se utiliza para la planificación y estimación de tareas y cronogramas (PSP1.1).
PSP2 añade dos nuevas fases: revisión de diseño y revisión de código. La prevención de defectos y su eliminación son el objetivo de PSP2. Los ingenieros aprenden a evaluar y mejorar sus procesos midiendo cuánto tiempo llevan las tareas y la cantidad de defectos que inyectan y eliminan en cada fase de desarrollo. Los ingenieros construyen y utilizan listas de verificación para revisiones de diseño y código. PSP2.1 introduce especificaciones de diseño y técnicas de análisis.
(PSP3 es un nivel heredado que ha sido reemplazado por TSP).
Uno de los aspectos centrales del PSP es el uso de datos históricos para analizar y mejorar el desempeño del proceso. La recopilación de datos de PSP se sustenta en cuatro elementos principales:
Los guiones de PSP brindan orientación a nivel de experto para seguir los pasos del proceso y brindan un marco para aplicar las medidas de PSP. El PSP tiene cuatro medidas fundamentales:
La aplicación de estándares al proceso puede garantizar que los datos sean precisos y consistentes. Los datos se registran en formularios, normalmente utilizando una herramienta de software PSP. El SEI ha desarrollado una herramienta PSP y también hay opciones de código abierto disponibles, como Process Dashboard.
Los datos clave recopilados en la herramienta PSP son datos de tiempo, defectos y tamaño: el tiempo dedicado a cada fase; cuándo y dónde se inyectaron, encontraron y arreglaron los defectos; y el tamaño de las piezas del producto. Los desarrolladores de software utilizan muchas otras medidas que se derivan de estas tres medidas básicas para comprender y mejorar su rendimiento. Las medidas derivadas incluyen:
El registro de datos de tiempo, defectos y tamaño es una parte esencial de la planificación y el seguimiento de proyectos de PSP, ya que los datos históricos se utilizan para mejorar la precisión de las estimaciones.
El PSP utiliza el método de estimación basada en PROxy (PROBE) para mejorar las habilidades de estimación del desarrollador para una planificación de proyectos más precisa. Para el seguimiento de proyectos, el PSP utiliza el método del valor ganado .
El PSP también utiliza técnicas estadísticas, como correlación, regresión lineal y desviación estándar, para traducir datos en información útil para mejorar las estimaciones, la planificación y la calidad. Estas fórmulas estadísticas son calculadas por la herramienta PSP.
El PSP tiene como objetivo ayudar al desarrollador a mejorar su proceso personal; por lo tanto, se espera que los desarrolladores de PSP sigan adaptando el proceso para garantizar que satisfaga sus necesidades personales.
En la práctica, las habilidades de PSP se utilizan en un entorno de equipo de TSP. Los equipos de TSP están formados por desarrolladores capacitados por PSP que se ofrecen como voluntarios en áreas de responsabilidad del proyecto, por lo que el proyecto lo gestiona el propio equipo. Usar datos personales recopilados utilizando sus habilidades de PSP; el equipo hace los planes, las estimaciones y controla la calidad.
El uso de métodos de proceso de PSP puede ayudar a los equipos de TSP a cumplir con sus compromisos de cronograma y producir software de alta calidad. Por ejemplo, según una investigación de Watts Humphrey, un tercio de todos los proyectos de software fracasan, [3] pero un estudio de SEI sobre 20 proyectos de TSP en 13 organizaciones diferentes encontró que los equipos de TSP no cumplieron con sus cronogramas objetivo en un promedio de sólo el seis por ciento. [4]
El cumplimiento exitoso de los compromisos del cronograma se puede atribuir al uso de datos históricos para hacer estimaciones más precisas, de modo que los proyectos se basen en planes realistas y, al utilizar métodos de calidad de PSP, producen software con pocos defectos, lo que reduce el tiempo dedicado a eliminar defectos en fases posteriores. como pruebas de integración y aceptación.
El PSP es un proceso personal que se puede adaptar para satisfacer las necesidades del desarrollador individual. No es específico de ninguna metodología de programación o diseño; por lo tanto se puede utilizar con diferentes metodologías, incluido el desarrollo de software ágil .
Se puede considerar que los métodos de ingeniería de software varían desde predictivos hasta adaptativos. El PSP es una metodología predictiva y Agile se considera adaptativo, pero a pesar de sus diferencias, TSP/PSP y Agile comparten varios conceptos y enfoques, particularmente en lo que respecta a la organización de equipos. Ambos permiten al equipo:
Tanto Agile como TSP/PSP comparten la idea de que los miembros del equipo asuman la responsabilidad de su propio trabajo y trabajen juntos para acordar un plan realista, creando un ambiente de confianza y responsabilidad. Sin embargo, el TSP/PSP se diferencia de Agile en su énfasis en documentar el proceso y el uso de datos para predecir y definir cronogramas del proyecto.
El objetivo de la PSP es el software de alta calidad, y la calidad se mide en términos de defectos. Para el PSP, un proceso de calidad debe producir software con pocos defectos que satisfaga las necesidades del usuario.
La estructura de fases de PSP permite a los desarrolladores de PSP detectar defectos tempranamente. Al detectar los defectos a tiempo, el PSP puede reducir la cantidad de tiempo dedicado a fases posteriores, como la prueba.
La teoría de PSP es que es más económico y eficaz eliminar los defectos lo más cerca posible de dónde y cuándo se inyectaron, por lo que se anima a los ingenieros de software a realizar revisiones personales para cada fase de desarrollo. Por lo tanto, la estructura de fases del PSP incluye dos fases de revisión:
Para realizar una revisión eficaz, debe seguir un proceso de revisión estructurado. La PSP recomienda el uso de listas de verificación para ayudar a los desarrolladores a seguir consistentemente un procedimiento ordenado.
El PSP sigue la premisa de que cuando las personas cometen errores, sus errores suelen ser predecibles, por lo que los desarrolladores de PSP pueden personalizar sus listas de verificación para abordar sus propios errores comunes. También se espera que los ingenieros de software completen propuestas de mejora de procesos para identificar áreas de debilidad en su desempeño actual a las que deben apuntar para mejorar. Los datos históricos del proyecto, que exponen dónde se gasta el tiempo y los defectos introducidos, ayudan a los desarrolladores a identificar áreas para mejorar.
También se espera que los desarrolladores de PSP realicen revisiones personales antes de que su trabajo pase por una revisión por pares o en equipo.
El SEI de la Universidad Carnegie Mellon ofrece una certificación que cubre PSP. Los pasos para convertirse en un desarrollador de PSP certificado por SEI son: conocer el PSP; realizar el examen de certificación; mantener credenciales. El examen de desarrollador de PSP se basa en conceptos que se encuentran en el conjunto de conocimientos de PSP. [5] El SEI mantiene una sección de preguntas frecuentes [1] sobre certificación.
{{cite web}}: Enlace externo en |work=