Ciclo de vida de lanzamiento de software

La fase pre-alfa abarca todas las actividades realizadas durante el proyecto de software antes de las pruebas formales. Estas actividades pueden incluir el análisis de requisitos , el diseño del software , el desarrollo del software y las pruebas unitarias . En el desarrollo típico de código abierto , existen varios tipos de versiones pre-alfa. Las versiones de hito incluyen conjuntos específicos de funciones y se publican tan pronto como la funcionalidad está completa.

La fase alfa del ciclo de vida de lanzamiento es la primera fase de las pruebas de software (alfa es la primera letra del alfabeto griego , que representa el número 1). En esta fase, los desarrolladores suelen probar el software mediante técnicas de caja blanca . Posteriormente, otro equipo de pruebas realiza una validación adicional utilizando técnicas de caja negra o caja gris . El paso a las pruebas de caja negra dentro de la organización se conoce como lanzamiento alfa . ^{[ 1 ] [ 2 ]}

El software alfa no es probado exhaustivamente por el desarrollador antes de su lanzamiento a los clientes. El software alfa puede contener errores graves, y cualquier inestabilidad resultante podría causar fallos o pérdida de datos. ^{[ 3 ]} El software alfa puede no contener todas las características planificadas para la versión final. ^{[ 4 ]} En general, la disponibilidad externa de software alfa es poco común para el software propietario , mientras que el software de código abierto suele tener versiones alfa disponibles públicamente. La fase alfa generalmente termina con una congelación de características , lo que indica que no se agregarán más características al software. En este momento, se dice que el software está completo en cuanto a características . Se lleva a cabo una prueba beta después de las pruebas de aceptación en el sitio del proveedor (la prueba alfa) e inmediatamente antes del lanzamiento general del software como producto. ^{[ 5 ]}

Beta, nombre que proviene de la segunda letra del alfabeto griego , es la fase de desarrollo de software que sigue a alfa. Generalmente, la fase beta comienza cuando el software está completo en cuanto a funcionalidades, pero es probable que contenga varios errores conocidos o desconocidos. ^{[ 7 ]} El software en fase beta suele tener muchos más errores que el software completo, así como problemas de velocidad o rendimiento, y aún puede causar fallos o pérdida de datos. El objetivo de las pruebas beta es reducir el impacto en los usuarios, incorporando a menudo pruebas de usabilidad . El proceso de entrega de una versión beta a los usuarios se denomina lanzamiento beta y suele ser la primera vez que el software está disponible fuera de la organización que lo desarrolló. Los lanzamientos beta de software pueden ser abiertos o cerrados, dependiendo de si están disponibles públicamente o solo para un público limitado. El software en versión beta suele ser útil para demostraciones y previsualizaciones dentro de una organización y para clientes potenciales. Algunos desarrolladores se refieren a esta etapa como previsualización , lanzamiento de previsualización , prototipo , previsualización técnica o previsualización tecnológica ( TP ). ^{[ 8 ]}

Los beta testers son personas que informan activamente sobre problemas con el software beta. Suelen ser clientes o representantes de clientes potenciales de la organización que desarrolla el software. Los beta testers tienden a ofrecer sus servicios de forma gratuita, pero a menudo reciben versiones del producto que prueban, descuentos en la versión final u otros incentivos. ^{[ 9 ] [ 10 ]}

Una versión candidata ( RC ), también conocida como prueba gamma o "versión plata", es una versión beta con el potencial de convertirse en un producto estable, lista para su lanzamiento a menos que surjan errores importantes . En esta etapa de estabilización del producto, todas las características del producto se han diseñado, codificado y probado a través de uno o más ciclos beta sin errores críticos conocidos. Una versión se considera completa cuando el equipo de desarrollo acuerda que no se agregará código fuente completamente nuevo. Aún podría haber cambios en el código fuente para corregir defectos, cambios en la documentación y los archivos de datos, y código periférico para casos de prueba o utilidades. ^{[ 12 ]}

También llamada versión de producción , la versión estable es la última candidata a lanzamiento ( RC ) que ha superado todas las etapas de verificación y pruebas. Cualquier error restante conocido se considera aceptable. Esta versión pasa a producción .

Algunos productos de software (por ejemplo, distribuciones de Linux como Debian ) también tienen versiones de soporte a largo plazo ( LTS ) que se basan en versiones completas que ya han sido probadas y comprobadas y que solo reciben actualizaciones de seguridad. ^{[ 13 ] [ 14 ] [ 15 ] [ 16 ]}

El término "lanzamiento a fabricación" (RTM), también conocido como "going gold", es un término utilizado cuando un producto de software está listo para su entrega. Esta compilación puede estar firmada digitalmente, lo que permite al usuario final verificar la integridad y autenticidad de la compra del software. La compilación RTM se conoce como " gold master " o GM ^{[ 18 ]} y se envía para duplicación masiva o replicación de discos, si corresponde. La terminología se toma de la industria de la grabación de audio, específicamente del proceso de masterización . RTM precede a la disponibilidad general (GA) cuando el producto se lanza al público. Una compilación golden master (GM) suele ser la compilación final de un software en las etapas beta para desarrolladores. Normalmente, para iOS , es la compilación final antes de un lanzamiento importante, aunque ha habido algunas excepciones.

RTM se utiliza normalmente en ciertos contextos de software de producción masiva para el sector minorista —a diferencia de la producción o el proyecto de software especializado en el ámbito comercial o gubernamental— donde el software se vende como parte de un paquete junto con hardware informático relacionado y, por lo general, donde el software y el hardware relacionado se comercializarán masivamente en tiendas minoristas para indicar que el software ha alcanzado un nivel de calidad definido y está listo para su distribución masiva. En otros contextos, RTM también puede significar que el software se ha entregado o publicado a un cliente para su instalación o distribución en los ordenadores o máquinas de usuario final. El término no define el mecanismo de entrega ni el volumen; solo indica que la calidad es suficiente para la distribución masiva. El producto final de la organización de ingeniería suele ser un archivo maestro dorado utilizado para la duplicación o para generar la imagen para la web.

La disponibilidad general ( AG ) es la etapa de comercialización en la que se han completado todas las actividades de comercialización necesarias y un producto de software está disponible para su compra, dependiendo, sin embargo, del idioma, la región y la disponibilidad electrónica o en medios. ^{[ 19 ]} Las actividades de comercialización pueden incluir pruebas de seguridad y cumplimiento, así como localización y disponibilidad mundial. El tiempo entre RTM y AG puede variar de días a meses antes de que se pueda declarar una versión de disponibilidad general, debido al tiempo necesario para completar todas las actividades de comercialización requeridas por AG. En esta etapa, el software ya está en funcionamiento.

La publicación en la web ( RTW ) o publicación web es un método de distribución de software que utiliza Internet. En este tipo de mecanismo de publicación, el fabricante no produce ningún soporte físico. Las publicaciones web se han vuelto más comunes a medida que ha crecido el uso de Internet. ^{[ 20 ]}

Cuando un software deja de venderse o de recibir soporte, se dice que el producto ha llegado al final de su ciclo de vida, que se ha descontinuado, retirado, descontinuado, abandonado u obsoleto, pero la lealtad de los usuarios puede mantener su existencia durante algún tiempo, incluso mucho después de que su plataforma esté obsoleta, por ejemplo, el Entorno de Escritorio Común ^{[ 23 ]} y el Sinclair ZX Spectrum . ^{[ 24 ]}

Tras la fecha de fin de vida útil, el desarrollador normalmente no implementará nuevas funciones, corregirá defectos, errores o vulnerabilidades existentes (tanto si se conocían antes de esa fecha como si no), ni proporcionará soporte para el producto. Si lo desea, puede liberar el código fuente para que la plataforma pueda ser mantenida por voluntarios.