Proceso de software personal

Este artículo incluye una lista de referencias generales , pero carece de suficientes citas en línea correspondientes . Ayúdenos a mejorar este artículo introduciendo citas más precisas. ( agosto de 2023 ) ( aprenda cómo y cuándo eliminar este mensaje )

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 mejor y mejorar su desempeño al incorporar disciplina en la forma en que desarrollan software y realizar un seguimiento de su desarrollo previsto y real del código. Muestra claramente a los desarrolladores cómo gestionar la calidad de sus productos, cómo hacer 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 una dirección 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. Afirma brindar a los ingenieros de software las habilidades de proceso necesarias para trabajar en un equipo de proceso 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:

• Mejorar sus habilidades de estimación y planificación.
• Hacer compromisos que puedan cumplir.
• Gestionar la calidad de sus proyectos.
• Reducir el número de defectos en su trabajo.

La formación en 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 necesarios y lo ayuda a mejorar su propio proceso de software personal. Humphrey alienta a los ingenieros competentes a personalizar estos guiones y plantillas a medida que comprenden sus propias fortalezas y debilidades.

Proceso

La entrada al PSP son los requisitos; el documento de requisitos se completa y se entrega al ingeniero.

PSP0, PSP0.1 (Introduce la disciplina y la medición de procesos)

El PSP0 tiene 3 fases: planificación, desarrollo (diseño, codificación, compilación, prueba) y un análisis posterior. Se establece una línea base para la medición del proceso actual: tiempo dedicado a la programación, fallas introducidas/eliminadas y tamaño de un programa. En un análisis posterior, el ingeniero se asegura de que todos los datos de los proyectos se hayan registrado y analizado correctamente. El PSP0.1 avanza en el proceso añadiendo un estándar de codificación, una medición del 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.

PSP1, PSP1.1 (Introduce la estimación y la planificación)

Con base en los datos de referencia recopilados en PSP0 y PSP0.1, el ingeniero calcula el tamaño del 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 empleado. Esta información se utiliza para la planificación y estimación de tareas y cronogramas (PSP1.1).

PSP2, PSP2.1 (Introduce la gestión y el diseño de calidad)

PSP2 agrega dos nuevas fases: revisión de diseño y revisión de código. La prevención y eliminación de defectos son el foco de PSP2. Los ingenieros aprenden a evaluar y mejorar sus procesos midiendo cuánto tiempo toman las tareas y la cantidad de defectos que introducen y eliminan en cada fase de desarrollo. Los ingenieros construyen y utilizan listas de verificación para las revisiones de diseño y código. PSP2.1 introduce técnicas de análisis y especificación de diseño.

(PSP3 es un nivel heredado que ha sido reemplazado por TSP).

Uno de los aspectos fundamentales del PSP es el uso de datos históricos para analizar y mejorar el rendimiento del proceso. La recopilación de datos del PSP se sustenta en cuatro elementos principales:

• Guiones
• Medidas
• Normas
• Formularios

Los guiones del PSP brindan orientación a nivel experto para seguir los pasos del proceso y brindan un marco para aplicar las medidas del PSP. El PSP tiene cuatro medidas principales:

• Tamaño: la medida del tamaño de una parte del producto, como líneas de código (LOC).
• Esfuerzo: el tiempo necesario para completar una tarea, generalmente registrado en minutos.
• Calidad: el número de defectos en el producto.
• Cronograma: una medida del progreso del proyecto, comparada con las fechas de finalización planificadas y reales.

La aplicación de estándares al proceso puede garantizar que los datos sean precisos y consistentes. Los datos se registran en formularios, normalmente mediante 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 que se recopilan en la herramienta PSP son datos de tiempo, defectos y tamaño: el tiempo empleado en cada fase; cuándo y dónde se inyectaron, encontraron y solucionaron los defectos; y el tamaño de las piezas del producto. Los desarrolladores de software utilizan muchas otras medidas derivadas de estas tres medidas básicas para comprender y mejorar su rendimiento. Las medidas derivadas incluyen:

• precisión de la estimación (tamaño/tiempo)
• intervalos de predicción (tamaño/tiempo)
• distribución del tiempo en fase
• distribución de inyección defectuosa
• distribución de eliminación de defectos
• productividad
• porcentaje de reutilización
• índice de rendimiento de costos
• valor planificado
• valor ganado
• valor ganado previsto
• densidad de defectos
• densidad de defectos por fase
• Tasa de eliminación de defectos por fase
• apalancamiento para la eliminación de defectos
• revisar tarifas
• rendimiento del proceso
• rendimiento de fase
• Coste de fallo de la calidad (COQ)
• COQ de evaluación
• Relación COQ de evaluación/falla

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 de un desarrollador y lograr 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 la correlación, la regresión lineal y la desviación estándar, para convertir los datos en información útil para mejorar la estimación, la planificación y la calidad. Estas fórmulas estadísticas se calculan mediante la herramienta PSP.

El PSP está destinado a ayudar a un desarrollador a mejorar su proceso personal; por lo tanto, se espera que los desarrolladores de PSP continúen 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 formados en PSP que se ofrecen como voluntarios para las áreas de responsabilidad del proyecto, de modo que el proyecto lo gestiona el propio equipo. Utilizando los datos personales recopilados mediante sus habilidades de PSP, el equipo elabora los planes, las estimaciones y controla la calidad.

El uso de métodos de proceso PSP puede ayudar a los equipos 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 TSP en 13 organizaciones diferentes descubrió que los equipos TSP incumplieron sus cronogramas objetivo en un promedio de solo un seis por ciento. ^[4]

El cumplimiento exitoso de los compromisos de 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 usar métodos de calidad PSP, producen software con pocos defectos, lo que reduce el tiempo dedicado a eliminar defectos en fases posteriores, como las pruebas de integración y aceptación.

El PSP es un proceso personal que se puede adaptar a las necesidades de cada desarrollador. No es específico de ninguna metodología de programación o diseño, por lo que se puede utilizar con diferentes metodologías, entre ellas, el desarrollo de software ágil .

Se puede considerar que los métodos de ingeniería de software varían desde predictivos hasta adaptativos. La PSP es una metodología predictiva y Agile se considera adaptativa, pero a pesar de sus diferencias, TSP/PSP y Agile comparten varios conceptos y enfoques, en particular en lo que respecta a la organización del equipo. Ambos permiten que el equipo:

• Definir sus objetivos y estándares.
• Estimar y programar el trabajo.
• Determinar cronogramas realistas y alcanzables.
• Realizar planes y mejoras en los procesos.

Tanto Agile como TSP/PSP comparten la idea de que los miembros del equipo se responsabilicen de su propio trabajo y trabajen juntos para acordar un plan realista, creando un entorno de confianza y responsabilidad. Sin embargo, TSP/PSP se diferencia de Agile en su énfasis en la documentación del proceso y en el uso de datos para predecir y definir los cronogramas del proyecto.

El objetivo del PSP es ofrecer un software de alta calidad, y la calidad se mide en términos de defectos. Para el PSP, un proceso de calidad debe producir un software con pocos defectos que satisfaga las necesidades del usuario.

La estructura de fases del PSP permite a los desarrolladores del PSP detectar los defectos de forma temprana. Al detectarlos de forma temprana, el PSP puede reducir la cantidad de tiempo que se dedica a las fases posteriores, como la de prueba.

La teoría del PSP sostiene 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 de cada fase de desarrollo. Por tanto, la estructura de fases del PSP incluye dos fases de revisión:

• Revisión de diseño
• Revisión de código

Para realizar una revisión eficaz, es necesario seguir un proceso de revisión estructurado. El PSP recomienda utilizar listas de verificación para ayudar a los desarrolladores a seguir un procedimiento ordenado de forma sistemática.

El PSP parte de la premisa de que cuando las personas cometen errores, estos suelen ser predecibles, por lo que los desarrolladores del PSP pueden personalizar sus listas de verificación para abordar sus propios errores más 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 que deberían abordar para mejorar. Los datos históricos del proyecto, que revelan dónde se invierte el tiempo y se introducen los defectos, 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 se someta a una revisión por pares o por equipo.

El SEI de la Universidad Carnegie Mellon ofrece una certificación que cubre la PSP. Los pasos para convertirse en un desarrollador de PSP certificado por el SEI son: aprender la PSP; realizar el examen de certificación; mantener las credenciales. El examen de desarrollador de PSP se basa en conceptos que se encuentran en el Cuerpo de conocimientos de la PSP. ^[5] El SEI mantiene una sección de preguntas frecuentes ^[1] sobre la certificación.

• Desarrollo de software ágil
• Integración del modelo de madurez de capacidad (CMMI)
• Universidad Carnegie Mellon
• Estimación basada en proxy (PROBE)
• Instituto de Ingeniería de Software (SEI)
• Proceso de software de equipo (TSP)
• Watts Humphrey

• "Usando un proceso de software personal definido y medido" por Watts S. Humphrey , publicado en IEEE Software , mayo de 1996, páginas 77–88.
• PSP: Un proceso de automejora para ingenieros de software, 2005.
• Cómo ejecutar proyectos exitosos con TSP(SM) y Six Sigma: una guía práctica para implementar procesos de software de equipo, Mukesh Jain, 2008.
• "Cómo ejecutar proyectos con éxito frente a los desafíos de los nuevos equipos", por Mukesh Jain (http://www.sei.cmu.edu/tspsymposium/2009/2006/deliver.pdf), septiembre de 2006.
• Ingeniería de software: un enfoque práctico, séptima edición. Roger S Pressman. McGraw-Hill Higher Education. 2009. ISBN 0-07-337597-7 , ISBN 978-0-07-337597-7 , páginas 57–58.  
• Artículo "El cuerpo de conocimientos del proceso de software personal (PSP)" del Instituto de Ingeniería de Software de Carnegie Mellon .
• Artículo "Gestión de la Calidad Personal con el Proceso de Software Personal".

• Tablero de procesos de software, herramienta PSP y TSP de código abierto ( GPL3 ); se ofrece con y sin scripts SEI propietarios, este último requiriendo registro SEI gratuito.