Gerardo es un ingeniero de software que trabaja en una empresa de renombre que desarrolla sistemas para empresas. Ha participado en algunos proyectos importantes como ingeniero programador, lo que le permite ir construyendo experiencia y reputación como un elemento clave en los proyectos importantes de la empresa. En reuniones con los administradores de los proyectos, es muy común que le pidan estimar el tiempo que requiere para construir un componente de software, sin embargo, sus respuestas no han sido del todo certeras. En ocasiones solicita tiempo de forma excesiva, lo que ha provocado que las estimaciones del costo del proyecto sean muy elevadas y el cliente decide mejor contratar a otra compañía. En otros casos, Gerardo ha ofrecido tiempos de entrega muy apretados, que le impiden entregar con calidad, lo que ha provocado que el cliente utilice un software lleno de defectos, lo que ha provocado mayores costos en las correcciones y mantenimientos necesarios al código.

Ya sea por sobreestimación o subestimación, los proyectos de software se ven impactados en sus costos. Ante tal situación, Gerardo se pregunta si existirá alguna forma en la que pueda medir mejor el proceso que sigue para construir un software, que genere una base más certera para realizar estimaciones reales.

2.1 Conceptos básicos del PSP

Watts Humphrey (1947-2010) Recuperado de http://sdtimes.com/watts-humphreys-road-to-excellence-is-worth-following/ Sólo para fines educativos.

PSP (Personal Software Process) es un modelo del proceso de desarrollo de software desarrollado por Watts Humphrey en 1997. Watts ideó este modelo con el propósito que pudiera ser utilizado por un ingeniero de software en proyectos de desarrollos pequeños o en componentes que pudieran ser construidos por una sola persona. Este modelo abarca las tareas de planificación, desarrollo y medición del software, de manera que el ingeniero pueda aplicarlo para mejorar sus propias habilidades de ingeniería de software, controlar su trabajo, cumplir con sus compromisos, medir su productividad y la calidad de sus productos, a través de un marco de referencia estructurado que incluye directrices y procedimientos de desarrollo de software.

PSP es fundamentalmente un proceso de mejora, que, si se utiliza de forma estructurada y disciplinada, permite obtener resultados predecibles. Los ingenieros pueden apoyarse en el PSP para recopilar requerimientos precisos, diseñar y desarrollar programas limpios de errores, documentar su trabajo y mejorar la mantenibilidad del software existente. En opinión de Humphrey (2005), el PSP no una respuesta mágica a todos los problemas que enfrenta la ingeniería del software, pero sí ayuda a reconocer dónde se encuentran y qué hacer para mejorar.

A continuación revisarás algunos conceptos en los que se basa el modelo PSP.

Proceso de software

Un proceso es una secuencia de pasos para obtener un resultado esperado. El objetivo que persigue al documentar un proceso es obtener siempre el mismo resultado.

Según Humphrey (2005), cuando un proceso de software se encuentra adecuadamente diseñado, se convierte en una guía para realizar el trabajo, mejora la planeación y coordinación, comunicación y control de actividades involucradas con el resultado esperado. En contraste, cuando un equipo de trabajo no sigue un proceso definido, es parecido a tener un equipo de fútbol con jugadores que saben béisbol, básquetbol, tenis, incluso podrían ser los mejores jugadores en su disciplina, pero perderían los partidos porque ningún de ellos conoce cómo se debe patear un balón.

Flujo del proceso de software

El modelo PSP propone que todo ingeniero de software considere este flujo de actividades cada vez que intervenga en un proyecto de desarrollo, independientemente si la tarea asignada es simple o compleja. Esto le permitirá mantener una estructura que a la larga le ahorrará tiempo en la planeación y ejecución de las tareas, y sus entregables se harán en tiempo y forma. Este flujo de actividades no debe ser una camisa de fuerza que entorpezca el trabajo de ingeniero, sino simplemente una guía, con la seguridad que ha sido probada con éxito por ingenieros de software. PSP da la libertad de cambiar según se considere o se adapte mejor en cada caso.

“Cuando tu proceso no funcione, cámbialo hasta que lo haga” Humphrey, 2005.

Flujo del proceso del PSP. Tomado del libro Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EE. UU: Pearson Education. Sólo para fines educativos.

Observa que el proceso PSP lo podrías dividir en tres partes generales: Planeación, Desarrollo y Postmortem. Más adelante en este mismo tema revisarás los elementos que lo componen.

Marco de referencia para la medición

Humphrey (2005) afirma que todo proceso definido debe establecer métricas con el principal objetivo de recabar información necesaria para conocer cuánto tiempo se lleva realizar una tarea, obtener el tamaño del producto resultante, contabilizar la cantidad de errores introducidos y detectados a tiempo, en otras palabras, medir un proceso te permite analizarlo, entender sus fortalezas y debilidades y, lo que es más importante, mejorarlo.

Fundamento para la mejora

Definir una secuencia de pasos para obtener un resultado te permite analizar cada paso de forma individual. Si no obtuviste el resultado esperado, quiere decir que un paso o la secuencia de pasos no fue la adecuada. Es parecido a lo que sucede en la repostería. Una persona podría seguir al pie de la letra una receta para hacer un pastel, pero si al final el pastel no tiene buen sabor, pudo deberse a que no utilizó los ingredientes adecuados o no siguió el procedimiento como lo marca la receta. Lo que obliga a la persona a estudiar paso a paso toda la receta y determinar qué fue lo que omitió o realizó de forma incorrecta, de tal suerte que la próxima vez que haga el pastel mejore el resultado. En ingeniería de software sucede lo mismo, sin embargo, el mayor problema es que no se analiza detenidamente el proceso de software para saber dónde necesita hacer ajustes y mejorarlo.

2.2 Elementos del PSP

Fase de Planeación

El proceso PSP establece una fase de planeación, que permite general y documentar el plan que guiará el proceso de software. En un principio esta fase de planeación puede llegar a considerarse como una pérdida de tiempo, sobre todo cuando la tarea asignada es muy simple, sin embargo, el hábito de dedicarle algunos minutos para analizar el problema y decidir cómo abordarlo, resultará en grandes beneficios posteriores, ahorrando tiempo en recopilar la información necesaria, abordar de mejor manera la tarea, y asegurar los entregables. Si el ingeniero de software planea en las tareas pequeñas mejorará sus planes en las tareas complejas.

Proceso de la fase de planeación:

Tabla tomada de Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EEUU: Pearson Education. Sólo para fines educativos.

Fase de desarrollo

Las actividades de la fase de desarrollo incluyen el diseño del programa, la construcción o codificación, compilación y pruebas unitarias. Varias de estas actividades suceden al mismo tiempo por lo que no debes considerarlas como secuenciales. Por ejemplo, una primera compilación del programa sirve también como prueba a nivel de sintaxis de los comandos y parámetros utilizados, incluso algunos compiladores utilizados en las aplicaciones IDE suelen alertar sobre errores de lógica, como en el caso de visual studio. El objetivo que busca PSP al detallar las actividades del desarrollo es generar el hábito del análisis del problema antes de iniciar la programación. Esto permitirá que el ingeniero encuentre la mejor forma de solucionarlo, minimizando la cantidad de defectos que pueda introducir en el código, haciendo así que las pruebas sean más ágiles y efectivas.

Proceso de la fase de desarrollo:

Tabla tomada de Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EE. UU: Pearson Education. Sólo para fines educativos.

Fase Postmortem

La parte final del PSP establece realizar un reporte postmortem, que se utiliza para documentar detalles importantes de la tarea realizada, qué problemas surgieron y como se solucionaron. Es un momento que el ingeniero de software debe dedicar para documentar las lecciones aprendidas. Este reporte es necesario que se realice de manera inmediata, justo cuando se ha entregado el producto. Si se deja pasar tiempo, es muy probable que se olviden detalles importantes que puedan ser valiosos para otras tareas o proyectos, y podría exigir más tiempo tratando de encontrar la información de sustento. Esta actividad sólo requiere de algunos minutos de tiempo cuando se tienen frescos los detalles importantes.
Al igual que la fase de planeación, realizar el reporte postmortem exige disciplina por parte del ingeniero de software y podría considerarla como una actividad tediosa, sin embargo, es un hábito que rendirá frutos en el futuro.

Proceso de la fase de Postmortem

Tabla tomada de Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EE. UU: Pearson Education. Sólo para fines educativos.

2.3 Medidas del PSP

El PSP sugiere 2 medidas del proceso de software: el tiempo transcurrido por fase y los defectos encontrados por fase. El objetivo será que ayuden a planear y administrar mejor los proyectos de software, al determinar la productividad y la calidad del trabajo realizado. Ambas acciones requerirán de tiempo para realizar mediciones precisas, sin embargo, es posible que el ingeniero de software se apoye de algunas herramientas que registran el tiempo de una forma muy simple. El ingeniero de software deberá llevar la contabilidad de minutos transcurridos en cada una de las fases y la cantidad de defectos que aparecen en el código cada vez que realice un cambio para solucionarlo, considerando que un cambio puede ser tan simple como agregar un punto y coma al final de una línea o hasta agregar varias instrucciones nuevas. Es importante que no se consideren como defectos el número de errores o advertencias arrojados en la compilación, ya que en muchos casos están relacionados a un solo error.

Registro del tiempo
A continuación, se muestra una forma simple para registrar el tiempo por fases:

Haz clic en campo del formato para conocer más detalle

El registro del tiempo requiere disciplina, por lo que es conveniente hacer uso de cronómetros que puedas activarlos fácilmente. Esto permitirá una medición precisa del tiempo, y es posible que te des cuenta de la cantidad de veces que eres interrumpido y los motivos, ello te permitirá afrontar mejor el problema que te impide ser más productivo.

Registro de defectos

El registro de defectos tiene información que servirá para identificar la cantidad de defectos detectados, el tiempo utilizado en la solución y el tipo de defectos. A continuación puedes observar un ejemplo del registro de defectos. 

Haz clic en campo del formato para conocer más detalle

Estos formatos pueden ser modificados según se crea conveniente, para facilitar el trabajo del registro de la información que servirá para reconocer la productividad actual y realizar mejores estimaciones en futuros proyectos.

El proceso PSP exige una disciplina de documentación a los programadores de software que les permite analizar su productividad en un proyecto particular y es la base para implementar un proceso de mejora continua personal. Los formatos de registro sugeridos por PSP pueden ser adaptados por el mismo programador, aunque se sugiere que al principio se utilicen sin cambios, mientras se acostumbra a documentar su propio trabajo. Es importante aclarar que PSP no debe ser tomado como un método de evaluación del personal, ya que, a diferencia de otras industrias, la construcción del software nunca es una tarea repetitiva, cada proyecto exige retos diferentes por lo que no sería posible comparar el esfuerzo o la productividad entre proyectos diferentes.

Lo mismo sucede con el registro de defectos propuesto por PSP. La cantidad de defectos detectados a tiempo no deben ser una métrica comparativa de la calidad del producto en diferentes proyectos, es decir, si el programador ha registrado una buena cantidad de defectos en un proyecto y otra una cantidad menor en otro, no significa que el primero tenga mayor calidad que el segundo. Probablemente en el segundo proyecto no se tuvo el tiempo suficiente para realizar pruebas, detectándose menos defectos, o se reutilizó código limpio que había sido implementado en otros proyectos. En cualquier caso, mantener un registro del trabajo del programador será una actividad muy útil sobre todo como base para realizar estimaciones del tamaño del software y el esfuerzo que implica. Estas estimaciones serían una herramienta para planear futuros proyectos.

Asegúrate de poder:

• Reconocer las ventajas de utilizar el PSP como un modelo base para realizar estimaciones reales del esfuerzo necesario en un proyecto de software.
• Reconocer las fases que propone el PSP para mejorar la productividad del desarrollo de software.
• Utilizar los formatos sugeridos por el PSP para registrar el tiempo y los defectos detectados, con la especificación recabar información para mejorar el proceso de desarrollo.

Compilar: se refiere a la acción de tomar un código fuente de un programa y pasarlo a un código que pueda ser interpretado por la computadora.

IDE (Integrated Deveoment Envionmental) es un programa que sirve de ayuda a los programadores al proporcionales algunas herramientas que le facilitarán escribir y estructurar mejor el código. Algunos ejemplos son Visual Studio, Netbeans, Eclipse.

• Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EEUU: Pearson Education.