Sobre la Gestión de la Configuración

Trabajando en el Plan de Gestión de Configuración nos hemos dado cuenta de que no es un proceso banal, tal y como pudiera parecer en un principio, sino que el documento que se genera va a tener una importantísima repercusión en todo el trabajo que desarrollemos en el futuro. El principal objetivo de este Plan es el de mantener la integridad de nuestro producto a lo largo de todo el ciclo de vida del producto software, habida cuenta de las numerosas modificaciones que va a sufrir a lo larto de todo el proceso de trabajo a causa de reuniones con el cliente, malentendidos en el funcionamiento, etc. Todo esto infiere, de una forma irremediable en el siguiente plan a tratar, el de calidad.

En lo que a nosotros se refiere, va a marcar las directrices para múltiples aspectos de nuestro proyecto:

• Identificación de los documentos: se especificará cuál será la nomenclatura de los distintos productos generados a lo largo de las distintas actividades del mismo (documentos de desarrollo, actas de reuniones, actas de gestión de cambios, etc.).
• Establecimiento de las bibliotecas de almacenamiento del sistema: en ellas se crearán múltiples directorios para ir almancenando los distintos productos generados, ya sean versiones beta, definitivas, copias de seguridad, control de tiempos,etc., tales como biblioteca maestra, de backup, de seguimiento...
• Gestión de cambios: se diseñarán los formatos de las hojas de control de estado de los documentos, de las solicitudes de cambios, de los informes, de las certificaciones de aceptación, etc., así como una definición de cuál será el proceso que sigue un cambio desde que se propone hasta que se acepta/rechaza.

Una vez explicado cómo se ha de hacer, es interesante ver que este plan realmente tiene ventajas y que puede aportar un valor añadido a nuestro producto.

• Mantenimiento integral de la integridad de los distintos elementos del proceso, en una atmósfera de cambio continuo.
• Control de la evaluación y ejecución de los cambios.
• Visión objetiva y concreta acerca de la creación y evolución del producto.
• Robustez ante auditorías y revisiones, pues se muestra el estado del avance real del proyecto.
• Reducción de costes de desarrollo, manteniendo una estabilidad en el proyecto.
• Aseveración de la integridad del producto en la operación, actualización y consistencia de toda la documentación generada.
• Incremento en la eficiencia y efectividad de la administración.

Por todo ello podemos asegurar que, a pesar de ser un documento no excesivamente extenso, sí es fundamental para un mejor proceso de desarrollo del proyecto y creemos que seguirlo fielmente puede ayudarnos a ser más eficientes en nuestro trabajo.

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.

Primeras impresiones

Parece que nos hemos salvado de la quema... por lo menos por ahora.

Esta mañana nos han corregido la oferta, el primer documento a entregar del proyecto de IS3, y salvo algunos errores tontos (calificados como "de Barrio Sésamo") y cosillas fácilmente modificables, no hemos salido muy mal parados, o al menos esa es la sensación que nos ha quedado.

Esta semana pasada nos ha servido para ir dándonos cuenta, a escala bastante reducida, de lo que va a significar esta asignatura a lo largo de todo un cuatrimestre: muchas reuniones, muchas horas de trabajo, y sobre todo la dificultad de coordinar a 7 personas a la vez para que se pongan de acuerdo (aunque sólo sea para elegir un día de reunión). De todas formas lo afrontamos con optimismo y vitalidad, por lo menos ahora, ya veremos cómo estamos en noviembre...

Es gracioso comprobar cómo, al igual que pasa en los grupos de amigos y en otros conjuntos más o menos reducidos de personas, es complicado ponerse de acuerdo hasta para elegir la tontería más insignificante (quién no se habrá pasado discutiendo con los colegas durante 2 horas para decidir a qué garito nos vamos de copas... como si eso importase). Pues eso, nosotros somos capaces de tirarnos una hora delante de la pantalla de un ordenador intentando decidir qué nombre le ponemos a nuestro producto, llegando al extremo de consultar un generador automático de nombres (bastante pésimo, por otra parte). En fin, qué sería de nosotros sin esos momentos de dispersión.

Y hablando de momentos de dispersión, nuestro proyecto se basa en "Twitter.com" (para entenderlo, hay que verlo hasta el final, como las buenas pelis):



Y nada más, como punto final hay que felicitar a nuestro compañero de equipo Marcos, que tras mucho esfuerzo y sacrificio se ha sacado una merecida Matrícula en su PFC de la Ingeniería Técnica. Esperamos que te vaya todo igual de bien en esta etapa.