Software Release Management, en castellano, gestión de entregas de software, es el proceso de entregas de software nuevo o de actualizaciones del software. El proceso es mucho más que crear una nueva versión o actualizar un programa. Cuando se necesita una nueva entrega hay que seguir varios pasos. Reunir las nuevas exigencias y conocer las dependencias con las componentes existentes es el primer paso. Después se puede producir la nueva versión, se le somete a prueba y se prepara la nueva entrega. La entrega que es llevada finalmente al entorno de operaciones consiste en un archivo listo para ser instalado, con los manuales de uso. La firma también recibe los documentos de diseño y pruebas.

Contenido 1 En el pasado 2 Desafíos 3 Beneficios 3.1 1. Información y descripción 3.2 2. Release Building 3.3 3. Prueba de aceptación 3.4 4. Preparación de la entrega 3.5 5. Instalación de la entrega 4 Release manager 5 Véase también 6 Referencias 7 Enlaces externos 8 Apendice

En el pasado

En el pasado era usual que una firma desarrollara un sistema. Un sistema simple de gestión de configuración era usado para apoyar al release management. Cuando un nuevo software debía ser entregado, todas las componentes eran congeladas, se dejaba de trabajar en el código fuente. A los usuarios se les notificaba donde obtener el nuevo software. La internet cambió esa manera de trabajar.

Desafíos

Muchos nuevos desafíos han aparecido en los últimos años. Muchas veces el software no es desarrollado por un equipo principal sino que el desarrollo se distribuye entre equipos e incluso entre compañías. Los diseñadores deben tener presente componentes ya existentes y las dependecias entre las componentes, sobre todo en el caso de equipos trabajando en lugares geográficamente alejados. El software debe ser descrito acusiosamente. Uno de los aspectos más importantes son las dependencias con otros sistemas. La localización, recepción y revisión de componentes puede ser fuente de errores. Hoek (1997&2003) señala que el gestor de entrega de software en un puente entre las organizaciones donde se escribe y produce una componente y las organizaciones donde son integrados en una aplicación.

Beneficios

Es necesario desarrollar el software para enfrentar nuevos requisitos, fallas y tecnologías. Al usar Release Management se gana un desarrollo estructurado y otros beneficios al contrario de desarrollar el software en forma intuitiva.

El Release management:

• da la posibilidad de planificar el uso de recursos
• es un proceso estructurado eficiente y efectivo
• los cambios aparecen de una vez, limitando en el tiempo los efectos sobre el usuario
• ayuda a verificar la funcionalidad y su uso antes de la entrega mediante pruebas
• utiliza control de versiones y almacenamiento central que aseguran el uso de la versión correcta

El proceso de entrega tiene varias fases:

1. Información y descripción

Cuando se prepara una entrega, primero debemos informarnos de lo que se exige que cumpla la nueva entrega, estos son los requerimientos. Por ejemplo, las mejoras que deben superar las fallas en el software existente. Eso se puede organizar mediante el uso de un Sistema de seguimiento de errores (Bugtracker). Un paso paralelo es fijarse en las dependencias. El software esta a menudo compuesto de muchos módulos que dependen uno del otro para trabajar. Si cambia uno, eso afectára al otro. Una vez que los requerimientos y las dependencias nos son conocidas se puede comenzar a planificar el proceso de entrega. La planificación consiste en fijar los pasos necesarios, los plazos límites, etc. En la figura 1 se puede visualizar el proceso usando meta modeling technique.

2. Release Building

Cuando nos sean conocidos los requerimientos, dependencias y plazos, comienza el build de la nueva entrega. El primer paso es el diseño de la nueva entrega. Se puede hacer usando técnicas de desarrollo de software, por ejemplo UML. El diseño es convertido en código fuente de algún lenguaje de programación (por ejemplo C). Se da a conocer a los desarrolladores la fecha de término para cambios (congelar el repositorio). Las piezas de código, clases, archivos de configuración, etc son entonces traídas desde el repositorio mediante un checkout, compiladas, enlazadas y finalmente armadas en un solo programa, un built. Se debe colocar una marca (tag) en el repositorio sobre la versión que fue traída, para posteriormente conocer el estado de avance de la versión usada por el usuario.

3. Prueba de aceptación

Cuando el built está listo, es enviado al departamento de control de calidad para las pruebas estándares de aceptación. El programa es revisado para verificar que cumple con los requerimientos y dependencias y que funciona correctamente. Durante esta fase, el proceso completo es documentado para tener en el futuro una base de conocimientos. Después de la verificación final se deben actualizar los estándares de prueba para adaptarlos al nuevo software.

4. Preparación de la entrega

Cuando se tiene una entrega correcta y probada, esta entrega debe ser empacada con los documentos necesarios como pueden ser:

1. lista de fallas que han sido corregidas,
2. nombre de la entrega (release tag),
3. especificación del entorno para el cual se ha construido la entrega,
4. documentación,
5. archivos de configuración,
6. informes de las pruebas realizadas, etc.

La transferencia al usuario se hace según lo que se haya acordado con el: por internet (descarga), un CD, etc.

5. Instalación de la entrega

La instalación consiste en la transferencia de la entrega al usuario su implementación.

Una descripción de los conceptos utilizados se encuentra en la tabla 1. Una descripción de las actividades se encuentra en la tabla 2.

Release manager

Existe la necesidad de tener una persona responsable de supervigilar el desarrollo, pruebas, implementación y apoyo al usuario de los programas más complejos. Esta persona debe tener un conocimiento general de cada aspecto del desarrollo del ciclo de vida del software, de varios sistemas operativos y plataformas de aplicaciones para software junto con una comprensión de las diferentes funciones y perspectivas económicas. La gestión de entregas apunta a esa necesidad. Un gestionador de entregas es:

• Facilitador - un gestionador de entregas sirve como eslabón entre diferentes departamentos de la empresa para garantizar entregas oportunas de software y actualizaciones y menor fricción entre los actores.
• Guardia – un gestor de entregas "guarda las llaves" de los sistemas de producción y es responsable de su calidad y disponibilidad.
• Arquitecto – el gestor de entregas ayuda a identificar, crear y/o implementar los procesos para gestionar eficientemente las entregas de Código.
• Ingeniero de apoyo para las aplicaciones en un servidor – a menudo se espera del gestor de entregas que ayude en la solución de problemas en las aplicaciones.

Véase también

• Ingeniería de software (el mismo tema, pero tratado más rigurosamente)
• Process Lifecycle management
• Change management
• Configuration management
• Software Release Decisions.

Referencias

Beck, B., Fowler, M. (2000). Planning Extreme programming, Addison Wesley.

Erenkrantz, J. R.(2003) Release Management Within Open Source Projects. In: Proceedings of the 3rd Open Source Software DevelopmentWorkshop. Portland, Oregon, USA, May 2003, S. 51–55.

Hoek, A. van der, Hall, R. S., Heimbigner D., Wolf, A. L. (1997) Software release management, Proceedings of the 6th European conference held jointly with the 5th ACM SIGSOFT international symposium on Foundations of software engineering, p.159-175, September 22-25, Zurich, Switzerland.

Hoek, A. van der, Wolf, A. L. (2003) Software release management for component-based software. Software—Practice & Experience. Vol. 33, Issue 1, pp. 77-98. John Wiley & Sons, Inc. New York, NY, USA.

Krishnan M. S., (1994). Software release management: a business perspective, Proceedings of the 1994 conference of the Centre for Advanced Studies on Collaborative research, p.36, October 31-November 03, 1994, Toronto, Ontario, Canada

Enlaces externos

Microsoft TechNet, Microsoft Solutions for Management: Release Management March, march 26h 2004. [online knowledge database] viewed on February 14th 2006. Available through: http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfrelmg.mspx

SM Foundation: ITIL Release Management, create date unknown. [online IT infrastructure library], viewed on February 8th 2006. Available through: http://www.itil-itsm-world.com/itil-5.htm

Apendice

Table 1: Lista de conceptos

Concepto	Explicación	Fuente de información
ENTREGA (RELEASE)	La entrega consiste en los archivos que componen el software. Puede ser una nueva versión, la corrección de una entrega anterior, todos los archivos o solo un parche para la ya instalada (patch)	Van der Hoek 1997&2003
REQUERIMIENTOS (REQUIREMENTS)	Los requerimientos describen las funcionalidades y los estándares que debe cumplir la nueva entrega.	Van der Hoek 1997&2003
DEPENDENCIAS(DEPENDENCIES)	Las dependencias describen The dependencies describe what the new release must comply to.	Van der Hoek 1997&2003
ITINERARIO DE LA ENTREGA (RELEASE SCHEDULE)	El itinerario de la entrega es el plan de como se realizará la entrega.	SM Foundation 2006
DISEÑO (DESIGN)	El diseño es la descripción (física) de como trabaja la entrega (el software).	Beck 2000
CÓDIGO (CODE)	The code is the computer language describing the program.	Beck 2000
MÓDULOS COMPILADOS (COMPILED MODULES)	Módulos compilados son partes del codigo, clases, etc. enlazados en subsecciones ya operativas.	Beck 2000
BUILT (BUILT)	Un built es un software operativo compuesto de los módulos compilados.	Beck 2000
CONTROL DE CALIDAD (RELEASE REVIEWS)	revisar o probar es el proceso de verificar que el built trabaja correctamente y cumple con los requerimientos.	Erenkrantz 2003
SECURE LIBRARY	The steps of the design, dependencies, constraints and explanations are documented as a future knowledge base.	SM Foundation 2006
TESTING STANDARDS	One of the last steps is to verify the new release and to update the testing standards for the new release.	SM Foundation 2006
PAQUETE DE ENTREGA (RELEASE PACKAGE)	The package will be verified against the requirements of specific customers, resulting in audit reports.	Erenkrantz 2003
AUDIT REPORTS	The audit reports give a last verification of the release.	SM Foundation 2006

Table 2: Activity table

Activity	Explanation	Source
Gathering requirements	When a new release is being prepared, requirements are gathered, e.g. what improvements are needed comparing to the previous release.	Van der Hoek 1997&2003
Gathering dependencies	Programs often consist of many modules that depend on each other to work. Changing one will affect the other.	Van der Hoek 1997&2003
Release planning	The next step is to plan the complete release process. What needs to be done, when, etc.	Van der Hoek 1997&2003 Microsoft TechNet 2004
Design	When it is clear what needs to be released, what the dependencies are and the time constraints, the design of the new release begins. This can any technique e.g. UML.	Beck 2000
Coding	After the design of the new release the actual coding is done. (e.g..NET code)	Beck 2000
Compiling	The pieces of codes, classes etc. are joined together into working subsections.	Beck 2000
Built	The working subsections are put together in one working program.	Beck 2000 Microsoft TechNet 2004
Reviewing	Reviewing or testing is the process of verifying the correct working of the built and lives up to the requirements.	Microsoft TechNet 2004
Documenting	The steps of the design, dependencies, constraints and explanations are documented as a future knowledge base.	Erenkrantz 2003
Verifying standards	One of the last steps is to verify the new release and to update the testing standards for the new release.	Microsoft TechNet 2004
Assemble package	Finally the release will have to be packaged, meaning	Erenkrantz 2003
Verifying	The package will be verified against the requirements of specific customers, resulting in audit reports.	Microsoft TechNet 2004
Release deployment	The deployment itself means getting the release to the customer and implementing it.	Krishnan 1994 Microsoft TechNet 2004