Generalidades
A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el código como en la documentación asociada. La Gestión de Configuración del Software es una disciplina encargada del control de la evolución de los productos de software.
Como todo proceso, la Gestión de Configuración también puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestión de Configuración (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o más actividades de la Gestión de Configuración.
Definiciones
Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los correctos.
El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software.
La Gestión de Configuración del Software implica la identificación de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:
Software distribuido al cliente.
Documentos de requerimientos del software.
Código.
Elementos requeridos para crearlos (ejemplo: el compilador)
A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el código como en la documentación asociada. La Gestión de Configuración del Software es una disciplina encargada del control de la evolución de los productos de software.
Como todo proceso, la Gestión de Configuración también puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestión de Configuración (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o más actividades de la Gestión de Configuración.
Definiciones
Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los correctos.
El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software.
La Gestión de Configuración del Software implica la identificación de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:
Software distribuido al cliente. Documentos de requerimientos del software. Código. Elementos requeridos para crearlos (ejemplo: el compilador)
Aspectos Funcionales
1. Identificación: Se necesita definir un esquema de identificación para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificación de versión y una identificación de Configuración.
2. Control: Se deben controlar los cambios que se le hacen a través del ciclo de vida, asegurando que el software sea consistente a través de la creación de una línea base del producto.
3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio.
4. Auditoria y revisión: Se debe validar que el producto este completo y se asi mantener la consistencia entre los componentes, asegurando que estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes.
2. Control: Se deben controlar los cambios que se le hacen a través del ciclo de vida, asegurando que el software sea consistente a través de la creación de una línea base del producto.
3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio.
4. Auditoria y revisión: Se debe validar que el producto este completo y se asi mantener la consistencia entre los componentes, asegurando que estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes.
Algunos conceptos presentes en la DisciplinaConfiguración
Las características funcionales y físicas de una versión especifica de hardware y elementos de software que combinados de acuerdo a procedimientos de construcción específicos cumplen un propósito particular.
Elementos de configuración de software
Definimos como un elemento de Configuración a una unidad física y/o lógica parte de un conjunto mayor de elementos, producida o adquirida, que por sus características es distinguible de las demás y cuya evolución interesa administrar.
Son elementos de Configuración en un proyecto de software:
01. El plan de proyecto.
02. El plan de Gestión de Configuración.
03. El documento de definición de requerimientos.
04. Estándares de análisis, diseño, codificación, pruebas, y auditoria.
05. Documentos de análisis del sistema.
06. Documentos de diseño del sistema.
07. Prototipos.
08. Documentos de diseño de alto nivel.
09. Documentos de diseño de bajo nivel.
10. Especificaciones de prueba del sistema.
11. El plan de pruebas del sistema.
12. El Código fuente del programa.
13. Código objeto y ejecutable.
14. Especificaciones de pruebas de unidad.
15. Planes de pruebas de unidad.
16. Documentos de diseño de base de datos.
17. Datos de prueba.
18. Datos del proyecto.
19 .Manuales de usuario.
02. El plan de Gestión de Configuración.
03. El documento de definición de requerimientos.
04. Estándares de análisis, diseño, codificación, pruebas, y auditoria.
05. Documentos de análisis del sistema.
06. Documentos de diseño del sistema.
07. Prototipos.
08. Documentos de diseño de alto nivel.
09. Documentos de diseño de bajo nivel.
10. Especificaciones de prueba del sistema.
11. El plan de pruebas del sistema.
12. El Código fuente del programa.
13. Código objeto y ejecutable.
14. Especificaciones de pruebas de unidad.
15. Planes de pruebas de unidad.
16. Documentos de diseño de base de datos.
17. Datos de prueba.
18. Datos del proyecto.
19 .Manuales de usuario.
Versión
Una versión es una instancia de un elemento de Configuración. El término se usa para señalar a un elemento de Configuración del software que tiene un conjunto definido de características funcionales.
Revisión
Se define revisión como una versión que se construye sobre otra versión anterior. El término revisión generalmente se asocia a la noción de corrección de errores, esto es, hacer cambios a un programa que corrigen solo errores en el diseño lógico pero no afectan las capacidades funcionales documentadas, dado que ningún requerimiento ha cambiado.
Variante
Se define variante como una versión que es una alternativa a otra versión. Las variantes pueden permitir a un elemento de Configuración satisfacer requerimientos en conflicto. Una variante es una nueva versión de un elemento que será añadida a la Configuración sin reemplazar a la versión anterior.
Por ejemplo, si se desarrolla una aplicación para varios sistemas operativos, algunas librerías pueden requerir modificaciones para poder ser compiladas o ejecutadas en los diferentes sistemas; la versiones para Unix y para Windows NT de una librería serían variantes del mismo elemento.
La creación de variantes implica la creación de ramas en un grafo de evolución.
Línea base
Una línea base es una especificación o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a través de procedimientos formales de control de cambios.
El término también se usa para referirse a una versión particular de un elemento de software que ha sido aprobado. En cualquier caso, la línea base solo se puede modificar a través de procedimientos formales de control de cambios. Una línea base, junto con todos los cambios aprobados a la línea base, representa la Configuración aprobada actual.
Procesos Asociados
Una versión es una instancia de un elemento de Configuración. El término se usa para señalar a un elemento de Configuración del software que tiene un conjunto definido de características funcionales.
Revisión
Se define revisión como una versión que se construye sobre otra versión anterior. El término revisión generalmente se asocia a la noción de corrección de errores, esto es, hacer cambios a un programa que corrigen solo errores en el diseño lógico pero no afectan las capacidades funcionales documentadas, dado que ningún requerimiento ha cambiado.
Variante
Se define variante como una versión que es una alternativa a otra versión. Las variantes pueden permitir a un elemento de Configuración satisfacer requerimientos en conflicto. Una variante es una nueva versión de un elemento que será añadida a la Configuración sin reemplazar a la versión anterior.
Por ejemplo, si se desarrolla una aplicación para varios sistemas operativos, algunas librerías pueden requerir modificaciones para poder ser compiladas o ejecutadas en los diferentes sistemas; la versiones para Unix y para Windows NT de una librería serían variantes del mismo elemento.
La creación de variantes implica la creación de ramas en un grafo de evolución.
Línea base
Una línea base es una especificación o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a través de procedimientos formales de control de cambios.
El término también se usa para referirse a una versión particular de un elemento de software que ha sido aprobado. En cualquier caso, la línea base solo se puede modificar a través de procedimientos formales de control de cambios. Una línea base, junto con todos los cambios aprobados a la línea base, representa la Configuración aprobada actual.
Procesos Asociados
El estándar ISO/IEC 12207 ([ISO 12207]) para Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración como uno de los Procesos de Soporte del Ciclo de Vida. Un Proceso de Soporte ”apoya” a otro proceso como una parte integral, con un propósito distinto, y contribuye al éxito y a la calidad del proyecto de software.
Este proceso consiste de las siguientes actividades:
1. Implementación del Proceso: Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y el cronograma para su realización, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado.
2. Identificación de la Configuración: Se establece un esquema de identificación de los elementos de software y sus versiones a ser controlados por el proyecto.
3. Control de la Configuración: Se identifican y registran las solicitudes de cambio, se analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado.
4. Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo líneas base.
5. Evaluación de la Configuración: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y físicamente completos (es decir, si su diseño y Código reflejan una descripción técnica actualizada).
6. Gestión de actualización y distribución: Se controla formalmente la actualización y distribución de los productos de software.
Este proceso consiste de las siguientes actividades:
1. Implementación del Proceso: Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y el cronograma para su realización, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado.
2. Identificación de la Configuración: Se establece un esquema de identificación de los elementos de software y sus versiones a ser controlados por el proyecto.
3. Control de la Configuración: Se identifican y registran las solicitudes de cambio, se analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado.
4. Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo líneas base.
5. Evaluación de la Configuración: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y físicamente completos (es decir, si su diseño y Código reflejan una descripción técnica actualizada).
6. Gestión de actualización y distribución: Se controla formalmente la actualización y distribución de los productos de software.
En la figura se presenta un modelo de este proceso elaborado utilizando el perfil de UML para modelamiento de procesos de software, propuesto por el Object Management Group (OMG)
El estándar IEEE Std. 1074-1995 ([IEEE 1074]) para el Desarrollo de Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración del Software como uno de los Procesos Integrales. Estos son los Procesos necesarios para completar exitosamente las actividades del proyecto, y son utilizados para asegurar la finalización y calidad de las funciones del proyecto. Este proceso consiste de las siguientes actividades:
1. Planificar la Gestión de Configuración.
2. Desarrollar la Identificación de la Configuración.
3. Realizar el Control de la Configuración.
4. Realizar la Contabilidad de Estado.
Escenarios de Configuración en el Proceso de Software
Gestión de configuración del código fuente
Gestión de configuración del código fuente
La evolución del Código fuente es quizás el ejemplo mas claro en la Gestión de Configuración. A lo largo del desarrollo (y posteriormente en el mantenimiento) las modificaciones al software se realizan sobre el Código fuente. Y es según el Código fuente que se valida la documentación asociada.
Los sistemas administradores de versiones se suelen integrar a los entornos de desarrollo y realizan administración de versiones del Código fuente. Cada modificación de uno de los archivos del programa va generando una revisión del mismo, y periódicamente se crean líneas base de todo el proyecto.
De este modo, un equipo de desarrollo puede trabajar en paralelo, compartiendo versiones de archivos de Código fuente y actualizándolos periódicamente según se van creando o modificando los archivos que conforman el proyecto.
Gestión de configuración en el desarrollo de software
Como ya habíamos comentado, un elemento de Configuración puede ser prácticamente cualquier producto o subproducto del desarrollo de software. Las especificaciones de requisitos, los documentos de análisis y de diseño, el Código fuente y ejecutable, y los procedimientos y datos de prueba pueden ser sometidos a control de Configuración.
Con un control riguroso, es posible entonces mantener registro del estado de todos estos elementos, lo que facilita la introducción de cambios si se tiene registro de las dependencias entre ellos, además de facilitar la elaboración de entregables; por ejemplo, si se tiene registro de las dependencias entre los elementos de Configuración, es posible que si se produce un cambio en las especificaciones, los documentos de análisis y diseño y el Código fuente asociados puedan ser actualizados sin que tome demasiado tiempo realizar su búsqueda.
Gestión de configuración en el mantenimiento de software
En el mantenimiento de software, cobra importancia la función del Comité de Control de Cambios (CCC), que se encarga de recibir, estudiar y aprobar las solicitudes de cambio en el software que son presentadas, sea por los usuarios o por los propios encargados del mantenimiento. En este caso, las funciones de control y de auditoria se vuelven casi indispensables, pues es necesario mantener registro de todas las solicitudes de cambio presentadas y del estado actual de cada una de ellas. Un sistema de Gestión de Configuración que apoye la Gestión de solicitudes de cambio, debería permitir el registro por parte de los usuarios de las solicitudes de cambio, su revisión por parte del CCC, y si son aprobadas la creación de ordenes de cambio.
Un cambio implica generalmente la actualización tanto del Código fuente, como de los documentos de especificación de requisitos, análisis y diseño, casos de prueba y manuales. Por lo tanto, en el escenario anterior, resulta de utilidad mantener un registro de las dependencias entre los elementos de Configuración. El cambio se vera reflejado en la creación de nuevas versiones de los elementos respectivos.
Gestión en la distribución del software a las PC- Usuarios
Cuando se pone en producción un software, se distribuyen copias del mismo entre los diversos usuarios del sistema. En este escenario, un sistema de Gestión de Configuración debería permitir registrar las Configuraciones (conjunto de versiones de elementos de Configuración) que cuenta cada PC - usuario. Puede ocurrir, que si un mismo sistema se vende a distintos clientes, en algún momento surjan requerimientos contradictorios o necesidades que lleven a la creación de variantes de los elementos de Configuración. El sistema de Gestión de Configuración apoyaría entonces al momento de estudiar una solicitud de un usuario a conocer cual es la Configuración con la que esta trabajando.
Modelo Genérico
A continuación se propone un modelo genérico para la Gestión de Configuración del software, representado en la figura 2. Este modelo procura abarcar los escenarios presentados anteriormente y da soporte a los siguientes requerimientos:
1. Permite la creación de tipos de elementos de Configuración. De este modo, es posible que el usuario cree sus propios tipos de elementos dependiendo que es lo que desea controlar.
2. Permite la creación de tipos de relaciones entre los elementos de Configuración. Es posible que el usuario cree los tipos de relaciones que desee, y que especifique dependencias para la creación de nuevas versiones entre el origen y el destino de la relación. Estas dependencias pueden ser:
Ninguna, Condicional-Origen (sí el origen cambia, el destino podría cambiar), Condicional-Destino (sí el destino cambia, el origen podría cambiar), Obligatoria-Origen (sí el origen cambia, el destino debe cambiar), Obligatoria-Destino (si el destino cambia, el origen debe cambiar).
3. Cada tipo de elemento y cada tipo de relación puede tener los campos de información adicional que el usuario considere necesarios.
4. Un elemento de Configuración corresponde a un tipo y sus versiones pueden estar relacionadas con versiones de otros elementos según se creen relaciones para él.
5. Un elemento de Configuración tiene un conjunto de versiones asociadas, cada una de las cuales esta asociada al usuario (dueño) que la creo.
6. Un conjunto de versiones de elementos de Configuración conforma una Configuración. Es posible de este modo registrar muchas Configuraciones para el mismo software, que pueden diferir en cuanto a versiones, o ser variantes (Configuraciones alternativas).
De este modelo es posible obtener información acerca de:
1. Los tipos de elementos sometidos a Gestión de Configuración.
2. Las relaciones entre dichos elementos.
3. Las dependencias para la creación de versiones al momento de analizar la introducción de un cambio. Es posible conocer como un cambio en un elemento afectara a los demás.
4. Los usuarios que generaron cada versión de un elemento.
2. Las relaciones entre dichos elementos.
3. Las dependencias para la creación de versiones al momento de analizar la introducción de un cambio. Es posible conocer como un cambio en un elemento afectara a los demás.
4. Los usuarios que generaron cada versión de un elemento.
Tomado de: http://www.histaintl.com/soluciones/configuracion/configuracion.php
No hay comentarios:
Publicar un comentario