Métricas para el Control

A raíz de encontrarnos inmersos en la primera sesión de control del proyecto, se nos ha ocurrido investigar algo sobre métricas o métodos para la mejora del control de los proyectos, de la planificación de los mismos y del rendimiento de los trabajadores. Con este post se pretende dar una visión global de dos de estas métricas: PSP (Personal Software Process) y TSP (Team Software Process). Éstas surgen por la necesidad de poder aplicar un modelo de madurez (CMM) a proyectos pequeños, yendo desde el ingeniero de software como entidad hasta el equipo de desarrollo; de ahí la primera P (Personal) de PSP y la T (Team) de TSP.

PSP

Fue definido por Watts S. Humphrey, y tiene como principios:

• Cada ingeniero es diferente, por lo que debe planificar su trabajo en base a su propia trayectoria profesional.
• Para mejorar, los ingenieros deben usar procesos personales bien definidos y cuantificados.
• Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos, que no es fruto del azar, sino del esfuerzo por hacer un trabajo de calidad.
• Cuanto antes se detecten y corrijan los errores, menos esfuerzo será necesario.
• Es más efectivo evitar los defectos que detectarlos y corregirlos.
• Trabajar bien es la forma más rápida y económica de trabajar.

Así mismo, el ingeniero, como profesional, debe:

• Planificar el trabajo.
• Esforzarse por cumplir la planificación.
• Esforzarse por obtener productos de calidad.
• ... y esto en un contexto de mejora continuo.

Actividades de PSP:

• Planificación: estimar errores, creación de una planificación del proyecto, estimación de tamaño y recursos.
• Diseño de Alto Nivel: diseño del componente y creación de prototipos.
• Revisión de diseño de Alto Nivel: verificar errores en el diseño.
• Desarrollo: generar el código, revisarlo, compilarlo y corregir errores.
• Análisis de Resultados: medir la efectividad del proceso en base a todas las mediciones tomadas durante el mismo.

PSP es un método que puede proporcionar una gran mejoría en el rendimiento del Ingeniero de Software y, para ello, se centra en una serie de aspectos en los que incide para lograr tal mejoría. El primero de ellos es el Control del tiempo, que infiere en que el Ingeniero ha de medir el tiempo que dedica a cada una de las tareas, teniendo en cuenta posibles interrupciones y anotando aquellas fases que se concluyan. En este punto entran en liza el Resumen Semanal de Actividades y la Tabla de Registro de Tiempos, formularios en los que se anotan las horas dedicadas a cada actividad por día. Ello permite ver en qué tareas se dedica más tiempo y establecer unas planificaciones futuras más ajustadas. Otro aspecto es la Planificación, que tiene como pilar el punto anterior, puesto que en base al recuento de tiempos veremos qué actividades necesitan mayor dedicación y cuales menos. El Tamaño del producto es otro punto importante. Aquí entra en juego el Resumen de Plan de Proyecto, documento que recoge las estimaciones tanto de tamaño como de posibles errores, así como los datos reales, de tal forma que nos dan una visión clara de cómo de bien planificamos o en qué fallamos más. Todo esto también afecta al punto de la Planificación, que es el epicentro de PSP.

Como conclusión, a pesar de ser un proceso muy costoso, que puede hacer que el profesional pierda motivación, sí que se ha demostrado que las personas que emplean este método consiguen una mejoría notable, con unos datos, en un periodo de tiempo razonable, netamente superiores a los de un Ingeniero que trabaja sin métrica de control alguna.

TSP

Al igual que PSP, fue creado por Humphrey. Su idea es la de ajustar los principios de PSP al trabajo en equipo, algo fundamental en nuestros días. Propone que los datos ofrecidos por los ingenieros capacitados en PSP pueden ser utilizados para administrar equipos de desarrollo de software.

Proporciona directrices para que el equipo pueda establecer unos objetivos realistas y pueda planificar los procesos en los que se ve involucrado, con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y dar lugar a productos eficientes, fiables y de calidad.

Fases del ciclo TSP:

• Lanzamiento: revisión de objetivos, formación de equipos de trabajo y describir las necesidades del cliente.
• Estrategia: diseño conceptual, elaboración de estrategia de desarrollo, identificación de riesgos y estimación de tamaño del producto y del esfuerzo requerido.
• Plan: estimación del tamaño de los componentes, identificación de tareas y establecimiento del plan de calidad.
• Requisitos: análisis de las necesidades, establecimiento de requisitos y plan de pruebas.
• Diseño: de alto nivel, especificando cada componente, establecimiento de estándares de codificación y plan de integración.
• Implementación: diseño detallado, implementación, revisión, compilación y pruebas unitarias.
• Pruebas: integración y pruebas globales del sistema.
• Postmortem: análisis del producto desarrollado y documentación.

La principal pega que tiene esta métrica es que añade un trabajo extra al propio del PSP, y esto, en un equipo de trabajo acosado por plazo de entrega inviables, cantidades ingentes de trabajo, etc., puede resultar una tarea que, en vez de sumar, reste.

A pesar de todo, y de que es mucho más reciente y, por lo tanto, menos maduro, que PSP, se trata de un método que, si se elabora de una forma estricta y constante puede dar lugar a mejores prácticas de ingeniería y un aumento del rendimiento de los equipos de trabajo.