Plan de gestion de configuración de software

CONTENIDO
Introducción
Objetivo
Alcance
Definiciones
Organización
Roles
Flujo de trabajo
Procedimientos
Responsabilidades
Políticas

INTRODUCCIÓN
Actividades de Gestión de configuración del software
• Identificación de la configuración
• Control de configuración
• Informes de estado de la configuración
• Revisiones y auditorias de configuración

OBJETIVO
El objetivo de la gestión de configuración es
garantizar que los cambios no se realicen de forma
inapropiada, debe existir una integridad en el
producto obtenido a lo largo del ciclo de vida del
software; todos los interesados en su
desarrollo, deben tener la versión correcta de la
aplicación y su documentación

ALCANCE

Dentro del control de la gestión de configuración se encuentran:
• El producto software en todos sus ambientes:
desarrollo, pruebas, y producción
• Documentos de ingeniería
• Documentos de gestión del proyecto
• Documentos de calidad de producto
• Documentación de usuario

En general toda fuente que es manejada dentro del
proyecto.

DEFINICIONES
Comité de control de la configuración CCC
Conjunto de personas que revisan y aprueban los cambios sugeridos a
un producto.

Petición de cambio
Solicitud formal que se presenta ante el CCC, la cual describe un
problema de software, una mejora solicitada o un cambio en los
requerimientos del software.

Ítem de configuración
Se entiende como elemento de configuración aquel producto de
trabajo, cuyo cambio pueda resultar crítico para el desarrollo del
proyecto.

1

DEFINICIONES
Línea Base
Conjunto de elementos de configuración formalmente aprobados que
sirve como punto de partida para futuras versiones. Especificación o
producto que se ha revisado formalmente y sobre los que se ha llegado
a un acuerdo y de ahí en adelante sirve como base para un desarrollo
posterior que puede cambiarse solamente a través de procedimiento
formales de control de cambios.

1

DEFINICIONES
Control de Cambios
Proceso responsable de controlar el ciclo de vida de todos los cambios.
Versión
Estado de un conjunto de clases (y de otro tipo de archivos) que forman
un sistema o componente. El conjunto de clases forman una versión en
un momento dado.

2

DEFINICIONES
Versión en desarrollo
Versión de un sistema o componente que está sufriendo modificaciones
por mejoras o correcciones por lo que aún no está disponible para
producción.
Versión en producción
Es una versión de un sistema o componente que se encuentra
disponible para el uso de usuarios finales.

Tronco
Es un término equivalente a la versión estable oficial de desarrollo del
sistema.

Rama
Versión de desarrollo paralela a la versión oficial (tronco) que se trabaja
hasta tenerla lista para salir a pruebas y posterior producción. Ambas
versiones, la oficial y la rama comparten un ancestro común y están 3
destinadas a converger en el futuro cercano.

ORGANIZACIÓN

La gestión de configuración de cambios se realiza a través del CCC

CCC Nivel 1:
conformado por el
grupo de comité
técnico

CCC Nivel 3:
CCC Nivel 2: conformado por el
conformado grupo de comité
por el grupo técnico y gerencia
de comité general
técnico y
clientes

ORGANIZACIÓN
El Comité de Control de Configuración CCC es la autoridad
para:
1. Evaluar todas las peticiones de cambio
2. Aceptar o rechazar los cambios propuestos
3. Toma las respectivas decisiones sobre los cambios a
implementar, cualquier cambio en los requerimientos, o en el
diseño, deben ser aprobados por CCC.

ROLES Y RESPONSABILIDADES

Director del proyecto
Líder de gestión de
Líder de CCC
configuración

Líder de documentación Líder funcional
Ingeniero de calidad

PROCEDIMIENTO GENERAL DE CONTROL DE
CAMBIOS

PROCEDIMIENTO CÓDIGO FUENTE Y
DOCUMENTACIÓN DE USUARIO
Del Líder funcional a líder de
Solicitar la creación de la rama de configuración
desarrollo SVN
Ticket tipo requerimiento interno de
infraestructura de gestión de
configuración
Crear la rama de desarrollo a partir del Líder de configuración
tronco del cliente utilizando la nomenclatura
Script BD y código fuente

Crear paquete de clases, nota del
reléase, manuales para entrega a calidad Nota del reléase. Matriz de afectación

Crear ticket de pruebas adjuntando la
información anterior Ingeniero de
Entregar paquetes de clases, notas de
calidad o
reléase, Léame y documentación de usuario
líder de
para custodia
configuració
Ingeniero de Solicitar la creación de la rama de pruebas n
calidad a de SVN Integrar la rama “paquete de clases al Líder de
líder de tronco, nota de reléase, léame, script base configuració
configuración de datos n
Crear la rama de pruebas a partir del tronco
Líder de
del cliente
gestión de la Líder de
Integrar documentación de usuario a la rama
configuración configuració
n
Líder de Crear la rama de la documentación de
Generar el archivo provisioning.zip Líder de
gestión de la usuario para el proyecto
configuració
configuración
n a director
de proyecto

Líder de Comité de Control de Configuración
Dirigir las reuniones de CCC
Definir ítems de configuración
Asignar roles al equipo de trabajo
Planear, informar y hacer seguimiento de los comités de control de
cambios
Documentar la decisión de las peticiones de cambio
Establecer fechas de liberación y contenido de las versiones
del producto software.
Recibir, priorizar y asignar las solicitudes de cambio.
Asignar al responsable de evaluar el impacto del cambio.
Reportar el estado de los cambios.
Realizar entrevistas con los usuarios funcionales en caso que se
requieran aclarar dudas originadas en una solicitud de cambio

Líder de gestión de configuración de software
Desarrollar y mantener el plan de gestión de la configuración.
Reportar los cambios no autorizados sobre los ítems de
configuración (IC).
Identificar los IC y documentar sus características.
Controlar los cambios a las características de un IC.
Realizar auditorías para verificar el cumplimiento del Plan gestión de
configuración.
Aprobar cambios estructurales en la base de datos de configuración.
Informar al CCC, el estado de aprobación de todos los cambios
propuestos y el estado de ejecución de todos los cambios
aprobados.
Programar, junto con el líder del CCC, las reuniones así como la
programación de la agenda para cada reunión.
1

Responsable de la administración del sistema de gestión de
configuración, lo cual incluye introducir la línea base, otorgar
permisos y administrar los usuarios.
Revisar el cronograma de proyecto para determinar hitos, que
permitirán conocer fechas de creación de las líneas base y
las actividades correspondientes de gestión de configuración.
Documentar el estado de la línea base para cada IC
Supervisar con qué frecuencia se realizan los cambios.

2

Responsabilidades asociadas al manejo del código fuente:
1. Crear nueva rama en SVN cuando se inicia un proyecto:
 Tomar el tronco actualizado, (no deberían haber cambios pendientes
sobre el tronco, suponiendo que todo cambio se maneja en una rama)
 Si es la primera vez que se toma el proyecto correspondiente al
tronco, conectarse al repositorio, hacer checkout de este repositorio
 Si ya se tiene el proceso correspondiente al tronco, hacer un update del
proyecto
2. Marcar la versión actual del tronco con una etiqueta (con la
etiqueta se logra tener una versión de referencia de cómo estaba
el tronco antes de la extensión o modificación), la etiqueta debe
seguir el estándar de nombramiento 3.2.1.4.
3. Abrir una rama a partir del tronco
4. Integrar la rama al tronco (responsable de modificar el tronco del
proyecto, integrando cada rama probada al tronco).

3

5. Si las pruebas de regresión sobre la rama salieron exitosas, el
líder de gestión de configuración realiza las siguientes acciones:
 Selecciona el tronco como el proyecto a trabajar
 Marca con una etiqueta el tronco (antes de integración)
 Integra la rama al tronco, resolviendo posibles conflictos
 Marca con una etiqueta el tronco (después de integración)
6. Con la etiqueta del tronco antes de integrar la rama se logra tener
una versión de referencia de cómo estaba el tronco antes de la
integración. Con la etiqueta del tronco después de integrar la rama
se obtiene la nueva versión del tronco. NOTA: se necesita rol
administrador para crear etiquetas
7. Debe generar el provisioning.zip cuando el director de proyecto
solicite la versión oficial aprobada del producto software para
entrega al cliente. Debe entregar dicho archivo al director de
proyecto con su documentación de usuario respectiva.

4

Responsabilidades asociadas al manejo del código fuente en
pruebas:
Crear nueva rama en SVN cuando se inicia un proyecto
Tomar el tronco actualizado, (no deberían haber cambios
pendientes sobre el tronco, suponiendo que todo cambio se maneja
en una rama)
Si es la primera vez que se toma el proyecto correspondiente al
tronco, conectarse al repositorio, hacer checkout de este
repositorio
Si ya se tiene el proceso correspondiente al tronco, hacer un
update del proyecto
Marcar la versión actual del tronco con una etiqueta (con la etiqueta
se logra tener una versión de referencia de cómo estaba el tronco
antes de la ejecución del proceso de pruebas.
5

Responsabilidades asociadas al manejo de documentación de
usuario:
Crear nueva rama en SVN para documentación de usuario
cuando se inicia un proyecto
Tomar el tronco actualizado, (no deberían haber cambios
pendientes sobre el tronco, suponiendo que todo cambio se maneja
en una rama)
Si es la primera vez que se toma el proyecto correspondiente al
tronco, conectarse al repositorio, hacer checkout de este
repositorio
Si ya se tiene el proceso correspondiente al tronco, hacer un
update del proyecto
Marcar la versión actual del tronco con una etiqueta (con la etiqueta
se logra tener una versión de referencia de cómo estaba el tronco
antes de la ejecución del proceso de pruebas. 6

Integrar la rama “paquetes de clases” al tronco del cliente
cuando el área de calidad de software lo solicita.
Generar el archivo provisioning.zip cuando es solicitado por el
director de proyecto para entrega al cliente

7

Líder funcional
A nivel de código fuente:
Para trabajar el requerimiento en la rama:
 Mientras se construye en la rama, la extensión o modificación del
proyecto, no se afecta el tronco pero sí se tienen en cuenta los
cambios que va teniendo el tronco.
 Al incorporar los cambios del tronco hacia la rama pueden surgir
conflictos sobre la rama, los cuales deben resolverse.
 Cuando son varios desarrolladores en la misma rama, eventualmente
deben resolver conflictos entre ellos cuando hacen commit en la rama
(después de resolver conflictos utilizar los comandos commit y
update). Se debe tener cuidado de incorporar cambios del tronco
hacia la rama y no al revés, colocando un rango de versiones
referentes al tronco (solo indicado por el líder de gestión de
configuración de software)

1

Líder funcional
A nivel de código fuente:
 Tomar el tronco actualizado, (No se debe hacer una rama cuando hay
cambios pendientes sobre el tronco. Si es el caso, se debe hacer
commit sobre el tronco para aplicar los cambios y luego update)
o Si es la primera vez que se toma el proyecto correspondiente al
tronco, conectarse al repositorio, hacer checkout de este repositorio
o Si ya se tiene el proceso correspondiente al tronco, hacer un update
del proyecto
 Seleccionar la rama a trabajar (antes de hacer los cambios asociados
al requerimiento se debe seleccionar como proyecto, el asociado a la
rama).
 Trabajar en la rama: A medida que se trabaja en la rama para realizar
la extensión o modificación requerida, el líder funcional debe hacer
periódicamente las siguientes acciones:
o Incorporar los últimos cambios del tronco hacia la rama.
o Modificaciones y pruebas de la rama. 2

Ingeniero de calidad
Hacer pruebas sobre una rama:
Recibe el paquete de clases de los lideres funcionales y las
agrega a la rama de pruebas del proyecto.
Trabaja en su rama para hacer las pruebas. Idealmente se
ejecuta el conjunto de casos de pruebas de regresión (sobre
la rama) que garanticen la compatibilidad hacia atrás.
Debe evaluar el contenido de la matriz de afectación recibida
en la nota del release.
Fin del trabajo en la rama: cuando la extensión o
modificación, (código fuente probado y aprobado) está lista
en la rama de pruebas, el ingeniero de pruebas solicita al
líder de gestión de configuración (administrador del
repositorio, pues, es el responsable de modificar el tronco del
proyecto) la incorporación de la rama al tronco, es decir, el
paquete de clases.

Líder de documentación
Generar el manual de usuario a partir el entrenamiento dado
por los lideres funcionales en primer ciclo de pruebas
Revisar los manuales de instalación, técnico y de
configuración con respecto al formato aprobado
Debe mantener en la rama de documentación de usuario del
proyecto en SVN, todos los manuales marcando la versión
con un tag
Debe mantener las versiones aprobadas de los
manuales, pues deben ser publicados en el administrador de
contenido del curso correspondiente
Debe solicitar la información necesaria al equipo de
desarrollo para generar la documentación de capacitación en
línea

HERRAMIENTAS
Para gestionar las líneas base se utilizan las siguientes
herramientas:
SVN, es una herramienta de gestión de versiones que se utiliza
para almacenar las versiones del software y su
documentación
Google docs, para almacenar la documentación de gestión de
proyecto, de ingeniería, calidad de software y documentación
de usuario.
Moodle, para administrar el contenido de documentación de
usuario del producto software por cliente.

POLÍTICAS
Política de Configuración de código fuente y documentación de
usuario
• Para la configuración de nuevas versiones del código fuente la
política es la siguiente:
• El código fuente será almacenado en el SVN
• Después de un cambio en base de datos se debe verificar la
actualización de su script. Es necesario indicar cuáles son las
sentencias alter que afectan la base de datos. Estos alter deben
especificarse en el manual técnico
• El release para pruebas debe incluir manual de
configuración, manual de instalación y manual técnico. Los cambios
a estos manuales deben ser realizados por el grupo de desarrollo y
manejados por el líder de documentación, quien conserva la versión
aprobada para el release.

POLÍTICAS
Política de Configuración de código fuente y documentación de usuario
• Trabajar el tronco o la rama como un todo:
• El checkout inicial del proyecto debe tomar todo el tronco del cliente.
• Toda rama representa una copia de todo el tronco.
• Para cambios hechos en una rama de desarrollo debe hacerse un
commit de archivos individuales.
• La integración debe llevar los cambios ocurridos en todo el tronco hacia
una rama o integrar los paquetes de las clases (de una rama) hacia el
tronco. Después de estas integraciones debe hacerse commit de toda la
rama o de todo el tronco, según el caso.
• Registrar buenos comentarios con los comandos subversion
• Durante el desarrollo de una rama se recomienda hacer commits frecuentes
para hacer visibles los cambios a los otros desarrolladores de la rama. El
comentario de un commit debe indicar la naturaleza de cada cambio que se
está registrando.

POLÍTICAS
Política de Configuración de código fuente y documentación de usuario
• Minimizar los conflictos en la integración de las ramas al tronco:
• Después de cada integración de los paquetes de clases (de una rama) al
tronco, el líder de configuración debe avisar para que todos los
desarrolladores actualicen sus ramas activas integrando el tronco hacia
cada rama. De esta manera las ramas se mantienen actualizadas respecto
al tronco y se reduce la probabilidad de que ocurran conflictos en la
integración de las clases de una próxima rama al tronco.
• Para cada integración de las clases de una rama al tronco, el líder de
gestión de configuración debe obtener el log de integración y agregarle
cómo se resolvieron los conflictos, si los hubo. Posteriormente, envía este
log al responsable de la rama integrada (lideres funcionales) para que
confirme si fue correcta la resolución de conflictos.
• Otra práctica adicional para minimizar conflictos es que el líder de
configuración no integre varias ramas (paquetes de clases) al tronco en
forma consecutiva sino que permita después de cada integración que los
desarrolladores actualicen sus ramas activas, antes de proceder a una
siguiente integración de otra rama (paquetes de clases) al tronco.

POLÍTICAS
Políticas de repositorio
• Los documentos en su versión para inspección y revisión continua se
mantienen en la colección del proyecto en el sistema de gestión de
documentos.
• Los documentos relacionados a calidad de software que han sido revisados y
aprobados por el área de calidad de software deben ser almacenados en la
carpeta respectiva al cliente en el sistema de gestión de documentos en
formato pdf. El área de calidad de software es quien tiene los documentos en
su formato de edición, ya que cualquier cambio en éstos deben ser
manejados a través del área.
• Los documentos relacionados al área de ingeniería y de gestión de proyecto
estarán almacenados en las carpetas respectivas de proyecto en el sistema
de gestión de documentos, aquellos documentos que necesiten ser
protegidos por la criticidad de la información serán manejados por el director
de proyecto, quien decide cuáles documentos pueden o no ser editables.
• Se debe tener una rama en SVN por cada cliente, con el fin de conservar la
copia de seguridad de documentación, configuración y código fuente de cada
cliente.
• En el sistema de gestión de documentos deben ir los documentos de
ingeniería relacionados a planes, diseños y reportes de pruebas.

POLÍTICAS
Políticas de manejo de línea base
• Los defectos deben ser corregidos en ambiente de desarrollo. Debe
actualizarse en paralelo la documentación de usuario (manuales).
• El release autorizado es el tronco del cliente.
• El release definitivo para liberar a producción debe ser solicitado por el
director del proyecto al líder de gestión de configuración.

Plan de gestion de configuración de software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Plan de gestion de configuración de software

Ähnlich wie Plan de gestion de configuración de software (20)

Plan de gestion de configuración de software