Dentro de la complejidad del desarrollo de software está también el de administrar el código y los documentos generados en el proyecto. Puede ser común que se nos pierda un documento, que no probemos el programa correcto o que instalemos algo que no tiene la funcionalidad que se desarrolló. Todos estos problemas están relacionados con un deficiente manejo de la Configuración del Software. Con relación a este tema es de mucha utilidad para el proyecto identificar el historial y las versiones de los documentos que generamos para una correcta comunicación y asegurarnos que el equipo está trabajando con la versión correcta. Una forma de administrar las versiones sería:

Versión ..

En donde:

XX: Cambios mayores YY: Cambios menores ZZ: Actualizaciones, correcciones

Para el historial de las versiones en el documento incluir:

Fecha: De la actualización Versión: Del documento Responsable: De hacer la actualización Descripción: De la actualización

Una herramienta de configuración nos ayuda a mantener nuestras versiones de software y no siempre la utilizamos correctamente. Cuando almacenamos o sacamos archivos de la herramienta no siempre indicamos el motivo del movimiento por lo que nos perdemos parte de su evolución. Una buena práctica es siempre documentar las razones por la que sacamos o guardamos un documento en la herramienta, no es necesario todo un ensayo, solo la información necesaria para saber que ha sucedido con ese archivo. Con los reportes de la herramienta podemos saber el estado de los componentes y como han evolucionado.

Un cambio que quita requerimientos puede ser igual de complicado que uno que añade un requerimiento si estamos en una etapa avanzada. Entre las cosas que hay que observar en el impacto es la modificación a los requerimientos, los planes, las pruebas, los diseños, etc para dejar el producto congruente con la documentación y su diseño. El impacto que resulte de dicho cambio lo debe de autorizar el comité de cambios así como el usuario. Este tipo de cambio no quiere decir que vamos a dejar de hacer actividades relacionadas con lo que se quitó, debemos de dejar los productos acorde con las nuevas circunstancias y comunicarlos.

Tocando el tema de la generación de las líneas base las he visto implementadas de dos formas, por paquetes o incremental. En por paquetes se define una línea para requerimientos o análisis, una de diseño, código, pruebas y proyecto. Aquí cada una tiene documentos propios de cada actividad, en análisis están los requerimientos, en diseño solo documentos de diseño. En la línea base de proyecto se encuentran las ultimas versiones de las líneas base generadas durantes el proyecto (análisis + diseño + etc.). La ventaja aquí es que el código queda en un paquete de línea base, el contra es que hay que mantener varias líneas base hasta terminar el proyecto. Cuando la línea base se hace incremental en cada línea base se van sumando nuevos elementos, así en la línea base de diseño se tienen los requerimientos y los documentos de diseño. En la de código están los documentos de análisis, diseño y el código. Al final del proyecto tenemos todos los documentos del proyecto en una línea base. El detalle aquí es el manejo del código junto con todos los documentos del proyecto. Otra opción es solo sacar la línea base de código y el resto líneas base que contienen puros documentos. Importante recordar que los documentos que están en línea base solo se actualizan por un procedimiento formal de cambios.

La mayoría de nosotros y las organizaciones aspiramos a estar mejor de lo que estamos ahora, sin embargo, no todos tenemos la voluntad de hacer las cosas necesarias para mejorar, y es un hecho que tenemos que hacer algo diferente a lo que estamos haciendo, es decir, debemos cambiar la forma de hacer las cosas. Aún teniendo las ganas de cambiar e iniciar un cambio nos enfrentamos a muchos problemas para lograrlo, entre los que están: miedos a perder lo que hemos logrado como poder, dinero, destreza, o privilegios, salir de nuestra zona de confort, falta de seguridad, falta de información, falta de motivación, necesidades diferentes, resistencia al cambio, fallas en cambios anteriores, falta de credibilidad, falta de participación, ambiciones personales, grupos de interés, estructura, incapacidad. Antes de iniciar un cambio en la empresa es importante ver el entorno y cuales son las condiciones, en qué nos vamos a apoyar, cuál será la estrategia, si lo que estamos buscando realmente aplica a nuestra organización y va de acuerdo a los objetivos de la misma. ¿Han existido otros intentos de cambiar?, ¿Sabemos quienes están mas dispuestos a cambiar y quienes no?, ¿Sabemos a donde queremos llegar?, ¿Tenemos un plan? Todo esto nos lleva a aceptar nuestra realidad, en dónde estamos como organización, qué somos capaces de hacer y qué no, cuáles son nuestras debilidades y nuestras fortalezas, y a partir de allí, empezar construir.