Las Versiones intermedias
Alfa, beta, gamma, delta u omega, son algunos de los nombres que suelen utilizarse para nombrar a las distintas versiones de un desarrollo. Estas versiones se encuentran entre la primera denominada alfa y la versión definitiva que será la que vera la luz como producto o software, resultado de un desarrollo.
Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.
Todo nuevo desarrollo debe comenzar con un claro objetivo en contra partida con el camino a recorrer que será difuso e impredecible mientras no realicemos una detallada planificación. Mediante la planificación, fijaremos cuales serán las especificaciones, el diseño y su arquitectura, con lo que podremos comenzar con el desarrollo con la claridad necesaria para alcanzar los resultados que buscamos.
Las versiones intermedias son como los peldaños de una escalera que deberemos necesariamente transitar para alcanzar el éxito de nuestro proyecto.
Muchos proyectos de software o de productos en general, fallan estrepitosamente por no seguir ninguna metodología. Con muy buenas intenciones, se suele comenzar rápidamente a construir con sólo tener una idea aproximada de lo que se quiere desarrollar y con un plan aún más impreciso de cómo hacerlo.
También te podría interesar:
- ¿Cómo planificar para alcanzar el éxito en un proyecto?
- Gestión de Stakeholders, gestionando necesidades y expectativas
- Errores comunes en la gestión de proyectos
- La Comunicación en la gestión de proyectos
Versiones desde la alfa hasta la dorada
La primera versión, generalmente llamada alfa, es la que es enviada a los verificadores para ser probada. Algunos equipos de desarrollo utilizan el término alfa para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.
Una versión beta representa generalmente la primera versión completa de un desarrollo informático o de un producto en general, es posible que sea inestable pero útil para que se realice la inspección técnica previa. Esta etapa comienza a menudo cuando, los responsables del desarrollo indican que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores.
Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los responsables del desarrollo las facilitan a un grupo de probadores beta para una prueba de usuario. Los probadores dan a conocer los errores que van encontrando y las características que quisieran ver en la versión final.
Una versión candidata para el lanzamiento comprende un producto final, preparado para publicarse como versión definitiva a menos que aparezcan errores que lo impidan. En esta fase el producto implementa todas las funciones del diseño y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo. Otros términos relacionados incluyen gamma, delta y tal vez más letras griegas para nombrar versiones que están prácticamente completas pero todavía en pruebas. Omega se suele utilizar para nombrar versiones que se creen libres de errores y se hallan en el proceso final de pruebas.
La versión candidata es considerada muy estable y relativamente libre de errores con la calidad adecuada para su distribución amplia y para ser utilizada por usuarios finales.
La versión dorada o de disponibilidad general de un producto es su versión final. Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de última hora. Esta versión también es considerada muy estable y relativamente libre de errores con la calidad adecuada para su total distribución para ser utilizada por todos los usuarios finales.
Metodología para alcanzar Versiones de éxito
El proceso de desarrollo que nos facilitaran lograr una versión final exitosa requiere una metodología que consta de las siguientes etapas :
- Plan operativo. Etapa de definición del problema a resolver, las metas del proyecto, las metas de calidad e identificación de las restricción que se aplicaran al proyecto.
- Análisis de requerimientos. Definición de los requisitos del producto a desarrollar. En esta etapa la habilidad y experiencia es crítica para reconocer requisitos incompletos, ambiguos o contradictorios. Usualmente el cliente o usuario suele tener solo una expresión de deseo de lo que quiere obtener con el desarrollo y es necesario ayudarles para obtener la visión completa de los requerimientos. La comunicación en esta etapa es muy intensa con todos los interesados del proyecto ya que el objetivo es eliminar la ambigüedad en la medida de lo posible.
- Especificación. Es el momento de describir detalladamente el producto final de una forma rigurosa. Se describe el comportamiento esperado del producto y su interacción con los usuarios y/o otros sistemas.
- Diseño y arquitectura. Determinar como funcionará el producto final de forma general sin entrar en detalles incorporando consideraciones de su implementación. Consiste en el diseño de los distintos componentes que conformaran el sistema y que darán respuesta a las funcionalidades descritas en la etapa anterior
- Desarrollo. Es la etapa más obvia del trabajo y la primera en que se obtienen resultados tangibles. No necesariamente es la etapa más larga ni la más compleja aunque una especificación o diseño incompletos o ambiguos pueden exigir que, tareas propias de las etapas anteriores se tengan que realizarse en esta.
- Prueba: Consiste en comprobar que el producto responda o realice correctamente las tareas indicadas en la especificación. Es una buena práctica realizar pruebas a distintos niveles y llevadas a cabo por equipos diferenciados del equipo de desarrollo.
- Documentación: Realización de los manuales de usuario y un manual técnico con el propósito de mantenimientos futuros y posibles ampliaciones.
- Mantenimiento: En esta etapa se realizan tanto el mantenimiento correctivo o resolución de errores del producto como el mantenimiento preventivo que tiene la finalizad de detectar y resolver posibles fallos en el producto antes de que estos se hagan una realidad.
Control de Versiones
El control de versiones es una herramienta que registra los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo, guardando así las versiones del producto en todas sus fases del desarrollo. Las versiones son como fotografías que registran su estado en un momento determinando de tiempo y se van guardando a medida que se hacen modificaciones al producto.
Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones. Estos sistemas facilitan el control y la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas.
Para un desarrollador esta herramienta es muy valiosa porque permite viajar atrás en el tiempo si los cambios aplicados no resultaron de la manera que se esperaba, pudiendo restaurar en cualquier momento una versión previa. Es como realizar un respaldo permanente.
Un sistema de control de versiones nos debe proporcionar:
- Mecanismo de almacenamiento de los elementos que deba gestionar.
- Posibilidad de realizar cambios sobre los elementos almacenados.
- Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos.
Es de mucha utilidad la generación de informes con los cambios introducidos entre las distintas versiones, informes de estado, marcado con nombre identificativo de la versión de un conjunto de ficheros.
¿Qué opinas sobras las Versiones intermedias? ¿Consideras que son necesarias para alcanzar un producto exitoso?
Espero tus comentarios y si te ha parecido interesante, sería genial que lo compartieras. Gracias.