¿Es Alpha o Beta?

Parecería que el control de las versiones de software no es una tarea fácil, pero la realidad es otra. Este tipo de administración es muy sencilla si se basa en la nomenclatura adecuada.

Esta nomenclatura es la que define a simple vista los detalles de las versiones que se están trabajando en nuestro desarrollo.

¿Cómo se define?
El esquema para administrar estas versiones se expresa típicamente por una nomenclatura formada por tres dígitos, los cuales, de acuerdo a su posición adquieren un significado, definiendo bajo el siguiente esquema sus valores:

Para las versiones comerciales de un producto, esta nomenclatura comienza a partir de la versión 1.0 identificando a las versiones alpha o beta cuando la parte de la versión mayor está por debajo de 1, y aumenta su valor cuándo el producto ha sufrido cambios relevantes en su funcionamiento.

Las bases
Pre-alfa
Se le llama pre-alfa a la etapa que define todas las actividades previas a las pruebas de software, pueden considerarse dentro de esta el análisis de requerimientos, diseño de software, desarrollo de software y el unit testing.

Alfa
Su nombre se deriva de la primera letra del alfabeto griego. Esta versión no es pública y su liberación solamente se hace dentro de las áreas internas de testing. A esta fase se le considera como la primera de desarrollo concreto de la lógica. Básicamente estamos hablando de un prototipo.

Generalmente un desarrollo en esta etapa no contiene toda la funcionalidad que tiene contemplado el producto final, por lo tanto, se pueden presentar numerosos bugs en su fase de revisión.

Beta
Cuando el desarrollo ha alcanzado cierta madurez, es decir, cuando se tiene la primera versión completa conforme a los requisitos establecidos en la pre-alfa, entonces el producto pasa a otra etapa del control de versiones. Generalmente es aquí cuando los desarrolladores congelan la solicitud de nuevas características al producto que no hayan sido definidas en las etapas previas.

Las versiones beta comienzan a definirse bajo la nomenclatura:

Como la fase aún no cuenta con las caraterísticas necesarias para considerarse un producto candidato a una primera versión, el dígito mayor se define con un 0, formando el distintivo para la versión beta de 0.X. Conforme al esquema, si en esta fase existiera un cambio que no es tan relevante para catalogarlo como un producto candidato al siguiente nivel, entonces las modificaciones iniciarian en 1 e irían en una posición después del número de la revisión, es decir, se tendría definida la beta:

Indicando el cambio que ha presentado el producto en esta fase. Si esta fuera la versión 1 de la beta con una primera revisión, entonces la nomenclatura estaría formada de la siguiente manera:

Aquí podemos realizar dos tipos de pruebas:
1. Abierta, el número de participantes que se asignan para su prueba no está limitado.
2. Cerrada, en la que un grupo de personas es seleccionado para realizarle las pruebas necesarias al producto.

Los testers (evaluadores) asignados, reportarán al equipo de desarrollo los errores encontrados y en ocasiones, características de menor importancia que les gustaría ver en la versión final del producto, para que se realicen las correcciones necesarias dentro de esta misma fase.

Versión RC (release candidate)
En esta etapa se puede considerar al desarrollo como un producto final que solamente será considerado como versión definitiva si éste no presenta fallas. Cuando se llega hasta aquí, no deben existir errores que detengan el desarrollo y avance del mismo. Debe contemplar todos los puntos que se definieron en el diseño del sistema (considerado en la etapa pre-alfa).

Siguiendo la nomenclatura, en este momento ya tendríamos la versión 1 del producto y la 0 en el dígito de la versión menor. Si existieran cambios en esta etapa, se definirian después del segundo dígito separado por punto, es decir:

El incremento del dígito que indica la versión mayor, se realiza cuando éste ha sufrido cambios relevantes a su funcionalidad actual.

Versión final
En esta etapa, el producto es considerado como estable y relativamente libre de errores, aunque puede presentar algunos, pero deben ser los mínimos. En este momento, el producto está listo para ser liberado al usuario final. Generalmente a este tipo de versiones con fines comerciales, se les define con un nombre de control diferente al de la nomenclatura pasada.

Conclusión
El control de versiones no solamente ayuda a la buena administración de un proyecto, sino que además brinda, a simple vista, un panorama general del estado en el que se encuentra el desarrollo de una aplicación. Esta ingeniería brinda consistencia, reproducibilidad y verificabilidad durante el proceso de desarrollo.