Lí­nea de Base

Como en muchas otras ocaciones vamos a tirar del concepto de “reutilización”, por lo que paso a describir Lí­nea de Base con la definición que podemos encontrar en Wikipedia
“Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí­ en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.”
Otra definición, algo más de andar por casa puede llevarse a cabo utilizando el siguiente sí­mil
“Imaginaos un restaurante en el cual está separado la cocina del comedor mediante una puerta corredera. El producto (el primer plato por ejemplo) se inicia desde la cocina. Mientras el plato no salga de la cocina el cliente no va a tener constancia de su existencia por lo que podremos hacer todos los cambios que consideremos oportunos sin tener que realizar ningíºn tipo de notificación al cliente. Incluso, si justo antes de mover la puerta corredera podrí­amos pedirle al camarero que volviera a dejar el plato, para darle ese íºltimo toque que se nos habí­a pasado dar antes de sacarlo a la luz (la sal por ejemplo). Eso sí­, en el momento que salimos de la cocina y atravesamos la puerta corredera, ya no hay vuelta atrás. Se le presenta al cliente el producto resultante y a partir de ahí­ estamos sujetos a los cambios que este nos solicite (dije al punto, pero esto está demasiado crudo).”
La lí­nea base de nuestra historia está en la puerta corredera, en el momento que la cruzamos marcamos versión y no hay vuelta atrás. Cuando cruzamos la puerta para salir es porque hemos realizado el trabajo segíºn lo acordado y en caso de que el cliente solicite algíºn cambio tendremos que volver a la cocina, realizar el cambio y sacar una nueva versión.
Saludos.
Miguel.

Repositorios de Código, la Potencia de Trabajar con Ramas

Hablamos ya anteriormente de “Repositorios de Código Fuente”, una herramienta básica para ayudar a mantener la “Gestión de Configuración” de nuestro proyecto (algo de lo que hemos hablado también).
Entre las principales bondades de los Repositorios de Código hablamos de la trazabilidad completa y de la posibilidad de trabajar con ramas. El uso de ramas es algo en lo que me gustarí­a hacer algo más de fuerza, ya que me temo que aunque haya bastante gente que esté acostumbrada a trabajar con respositorios como CVS, Subversion y SourceSafe, no hay tanta que esté acostumbrada a utilizar la posibilidad de utilizar ramas, una opción que permiten los tres repositorios.
Pongo un ejemplo de una situación que seguramente os sonará.
Estamos desarrollando una aplicación de la cual hemos liberado nuestra flamante version 1.0, fruto de un esfuerzo de varios meses de trabajo. Una vez liberada, varios clientes adquieren la aplicación por la cual pagan una cantidad de dinero tanto por su adquisición como por el mantenimiento de la misma (nuevos módulos y corrección de errores). Pasan las semanas y tras las primeras impresiones que se reciben por parte de los clientes, se decide comenzar el desarrollo de nuevos módulos y ampliación de los módulos existentes. Y cuando llevamos ya un mes de nuevos desarrollos para lanzar la esperada versión 2.0… uno de nuestros clientes explota un error de aplicación debido a que un módulo en concreto gestiona de manera incorrecta la memoria. Este fatí­dico error provoca que el cliente no pueda facturar el mes, y deja al descubierto un problema que se puede dar también en el resto de clientes que están utilizando la v1.0.
¿Qué hacemos ahora? Estamos a mitad del desarrollo de la v2.0. Ante esta situación podrí­amos plantear una solución de mí­nimos que pasarí­a por invitar al cliente que ha detectado el error a esperar a que salga a la luz la v2.0, y mientras tanto rezar que el resto de clientes que tienen la v1.0 (ya hemos vendido e instalado la aplicación en más de 20 clientes) no les ocurra lo mismo.
La otra opción, claro está, es utilizar ramas. Si tras cerrar la v1.0 hemos marcado la versión como lí­nea de base, estamos salvados. íšnicamente tendremos que partir de la v1.0, hacer la rama correspondiente y actualizar el código necesario para resolver el error. Una vez realizados los cambios, marcamos dicha versión como la versión 1.0.1, paquetizamos, y enviamos la versión de actualización a todos los clientes. Además, el propio repositorio de código va a permitir que podamos solventar directamente los cambios de código en la futura v2.0, en la que debemos evitar también el error.
Esta segunda solución va a permitir entre otras cosas mantener dos equipos de trabajo, uno centrado en nuevos desarrollos y otro preparado para solventar los posibles errores o pérdidas de versiones ya publicadas. Además dicho segundo equipo serí­a el encargado también de mezclar las correcciones en la nueva versión.
Saludos.
Miguel.

Repositorios de Código Fuente

Para los que estéis acostumbrados a trabajar en proyectos donde los recursos estén distribuidos geográficamente, en empresas de consultorí­a o en grupos de trabajo de más de dos o tres personas, seguramente tendréis el concepto de Repositorio de Código más que presente. Es más, seguramente no concebiréis el empezar un proyecto sin su existencia. Productos como CVS, Sourcesafe, Subversion… forman parte de vuestro dí­a a dí­a.
En cambio, para profesionales que acaban de salir de la carrera, o para profesionales con años de experiencia pero que trabajan en empresas que desarrollan y gestionan sus propias aplicaciones, en departamentos con pocas personas y con proyectos de no muy grandes dimensiones, el uso de un Repositorio de Código Fuente no es muy comíºn, es más, incluso puede llegar a ser desconocida cuál es su aplicación.
Uno de los principales fines de un Repositorio de Código fuente es el de centralizar en un punto la íºltima versión del código fuente de una aplicación. Soluciones rudimentarias al problema de la centralización utilizan una unidad compartida en la red. Se comparte una carpeta, y todos los miembros del equipo de desarrollo trabajan contra la carpeta que contiene la íºltima versión del código fuente. Esto en principio podrí­a ser válido en equipos pequeños, pero deja de lado otros problemas: ¿qué ocurre si dos personas modifican un mismo archivo al mismo tiempo? ¿qué ocurre con la versión anterior del fichero? ¿y si a mitad de un desarrollo necesito realizar una actualización de la aplicación para solucionar un error, tendré que esperar a cerrar el desarrollo que tengo en curso? Me vienen a la cabeza otras soluciones rudimentarias como… cuando cierro una versión me copio la aplicación a otra carpeta y le pongo que eso es la versión 3.
Son demasiados riesgos teniendo en cuenta que el código fuente son los ladrillos de nuestra aplicación, y sin ladrillos, no hay casa.
Utilizando un repositorio de código fuente podré obtener de forma directa de las siguientes ventajas:
1) Solución al problema de la concurrencia. Que varias personas quieran trabajar con el mismo fichero ya no es problema, el repositorio de codigo me ayudará a evitar errores y a tener un control total.
2) Trazabilidad completa. Voy a poder controlar todas las versiones que se han producido de forma automática para cada una de las modificaciones de un fichero. Podré compararlas entre ellas, conocer la fecha de modificación y su autor. Tengo control sobre el código y los cambios que se producen sobre el mismo.
3) Voy a poder retornar a una versión anterior de la aplicación sin problema, y a partir de dicha versión abrir una nueva rama que difiera de la que se tomó en su momento. Soy capaz de lanzar una actualización de una versión ya cerrada aunque esté a mitad de un desarrollo, y además, hacer que para la nueva versión que estoy preparando dicho error también esté solventado. El repositorio de código me ayudará.
4) Seguridad. Control de acceso al código, sólo usuarios autenticados podrán realizar modificaciones, borrar, crear nuevos ficheros.
Para finalizar, terminar con la reflexión de que mucha gente cree que un repositorio de código no tiene sentido para trabajar con grupos pequeños o desarrollos de una íºnica persona, pero, visto lo visto en el artí­culo, creo que queda bastante claro que la mayor potencia que obtenemos es la trazabilidad, y eso es totalmente independiente al níºmero de personas que trabajen en el proyecto.
Un saludo.
Miguel.

Gestión de la Configuración

Abrimos nuevo Tag, “Gestión de la Configuración”. Antes de nada empezamos primero con la definición de Gestión de Configuración que incorpora Wikipedia.
Gestión de la Configuración (tenéis en el link más ampliado el término a parte de la descripción).
“Se denomina Gestión de la Configuración el conjunto de procesos destinados a asegurar la validez de todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema de Información (S.I.), a través del estricto control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en el citado desarrollo. Estos dos elementos (control de cambios y control de versiones de todos los elementos del S.I.) facilitan también el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en cada etapa del desarrollo. La gestión de la configuración se realiza durante todas las fases del desarrollo de un sistema de información, incluyendo el mantenimiento y control de cambios, una vez realizada la puesta en producción.”
A esta definición añado una serie de puntualidades que pueden resultar también interesantes:
1) La Gestión de la Configuración es una de las áreas de proceso definidas como indispensables para obtener el Nivel de Madurez 2 de CMMI.
2) La Gestión de la Configuración no es un producto resultante de nuestro proyecto que debamos entregar al cliente, son un conjunto de técnicas de gestión interna que ayudará que a mejorar la calidad de nuestro desarrollo, minimizar los tiempos de respuesta, disminuir la tasa de fallos, mantener la trazabilidad hacia detrás y más temas que iremos viendo más adelante.
3) No se debe confundir la Gestión del Mantenimiento con la Gestión de la Configuración (guiño a los que fueron mis compañeros de la asignatura Técnicas y Herramientas de Gestión de Proyectos, en la UIB 🙂 ).
4) Otro de los conceptos que introduce la Gestión de la Configuración y que no aparecen en la definición es el de Lí­nea de Base. Trataremos también de él más adelante.
Saludos.
Miguel.