1.1
PROPÓSITO
El objetivo de la gestión de la
configuración es mantener la integridad de los productos que se obtienen a lo
largo del desarrollo de los proyectos, garantizando que no se realizan cambios
incontrolados y que todos los participantes en el desarrollo disponen de la
versión adecuada de los productos. En este plan se describe el proceso que se llevará
a cabo para cubrir este objetivo.
1.1
ALCANCE
La Gestión de la Configuración es
realizada en todas las actividades asociadas al ciclo de vida del proyecto,
facilitando el mantenimiento del mismo, aportando información precisa para
valorar el impacto de los cambios y reduciendo el tiempo de implementación de
un cambio, tanto evolutivo como correctivo.
2
GESTIÓN DE LA CONFIGURACIÓN
Describe la asignación de responsabilidades y autorizaciones
para las actividades de Gestión de la Configuración dentro de la organización
del proyecto.
3
ACTIVIDADES DE GESTION DE LA CONFIGURACION
Las actividades de Gestión de la
Configuración incluye todas las funciones y tareas requeridas en la gestión de
los Elementos de Configuración del sistema tal y como se especifica en el
alcance de este Plan. Tanto las actividades técnicas como de gestión de Gestión
de la Configuración se identifican y controlan mediante la implementación de
las siguientes funciones de Gestión de la Configuración:
- Identificación de la Configuración
- Control de la Configuración
- Estado de la Configuración
- Revisiones y Auditorias de la Configuración (QA/QC)
- Control de Interfaces
3.1
IDENTIFICACIÓN DE LA CONFIGURACIÓN
Las actividades de Identificación de la
Configuración consisten en
seleccionar, identificar, nombrar, asignar identificadores únicos y registrar
documentalmente sus características funcionales y físicas para todos aquellos
elementos a ser controlados por el proyecto.
3.1.1 IDENTIFICAR ELEMENTOS DE CONFIGURACIÓN
3.1.3 IDENTIFICACIÓN Y NOMENCLATURA DE LOS ELEMENTOS DE
CONFIGURACIÓN
Para cada EC se
identificará justo antes y después de los puntos del código donde se realicen
las modificaciones el código de petición que realiza los cambios. Se
identificará también
en la cabecera del ítem de configuración el petición asociado a la modificación
y una breve descripción del cambio.
Para los Sistemas Web, cada una
de las modificaciones se identifican con la siguiente estructura:
CódigoPetición
– I
/**
Comentario con la descripción del cambio**/
Modificaciones
a realizar
CódigoPetición
– F
3.1.4 ACCESO Y ESTRUCTURA DE LOS REPOSITORIOS
3.2
CONTROL DE LA CONFIGURACIÓN
El BP
solicitará al Responsable de SF (GE/JP) de su área el análisis y valoración de
un determinado subproyecto, vía e-mail con copia al SM. En el correo deberán ir
informados los siguientes datos:
Código de Proyecto/Subproyecto
Título del Subproyecto
Área
Bussines Partner responsable del
proyecto/subproyecto
Solution Manager responsable del
proyecto/subproyecto
Línea Estratégica
Proyecto
URL a la documentación del requerimiento
El GE/JP del
SF dará de alta el subproyecto y le asignará un responsable del proveedor en la
Herramienta de gestión de requerimientos.
Es en el DIS-030-Diseño Técnico donde
se analizará el impacto del cambio sobre el sistema, tanto el impacto funcional
como técnico. Se identificará también el impacto en otros módulos, aplicaciones
o sistemas que se vean afectados por el desarrollo.
Se identifica en el DIS-030 el
inventario de objetos afectados por el desarrollo y la estimación del coste de
implementación:
3.2.3 APROBACIÓN / RECHAZO DEL CAMBIO
Tanto para el caso de Proyectos,
como para Avisos de VU (Correctivos y Evolutivos) existen diversos actores y
estados de aprobación que pueden consultarse en la Metodología ProcEde
o el Procedimiento de peticiones de VU para las fases de Desarrollo y
Construcción.
Si la solución del aviso no es
aceptada por el CAU o el Usuario, el aviso será devuelto a la SWF con la
justificación del rechazo para su resolución. En dicho caso el aviso volverá a
ser analizado comenzando de nuevo el ciclo.
3.2.4 IMPLEMENTACIÓN DEL CAMBIO
Para los Desarrollos, en fase de DT, el
equipo de SWF solicitará al Equipo de gestión de configuración un
código de petición. Se trata de un código asociado al requerimiento, con el
cual el equipo de desarrollo solicitará al equipo de gestión de configuración, por medio de la herramienta de Administración de Entornos, los
objetos que desean modificar, dar de alta o de baja en el sistema.
Cuando el SF disponga
de(los) código(s) de petición de Administración, deberá informarlo en la
Herramienta de gestión de requerimientos para todas las plataformas implicadas.
En caso de correctivos y EPT, si se trata de
un ACS, en el momento de pasar las solicitudes recibidas del cliente a estado
“Analizado” se generará desde AIC el código de petición asociado al mismo. Del
mismo modo que para los desarrollos, con este código de petición el equipo de
SWF solicitará, por medio de la herramienta de Administración de Entornos, los
objetos que desean modificar, dar de alta o de baja en el sistema.
Independientemente de si se trata de una
petición de desarrollo o de un ACS, el ciclo de vida de la Petición es el
mismo.
Ciclo
de vida de una petición de Administración
|
|
PM – Pendiente de
Analizar
AP – Apertura
RV – Revisión
PV – En Preliberación
FN – Finalizada
RCZ – Petición
rechazada por mantenimiento pendiente de aceptar por las CIAs
INC – Incompleta
RCR – Petición
Rechazada por mantenimiento y aceptada por las CIAs
RE – Rechazada
(1) Se pasa de estado PM a AP al hacer el
primer Solapert.
(2) Se pasa de estado AP a RV al hacer el
Comudisp. A partir de aquí lo revisa Calidad.
(3) Se pasa de estado RV a PV cuando
Administración sube la petición a Master.
(4) Se pasa de estado PV a FN cuando se
libera la petición a compañías.
Las solicitudes de alta, baja o modificación
sobre el sistema realizadas por medio de la herramienta de Administración se
denominan SOLAPERT (Solicitud de Apertura). El equipo de gestión de
configuración de la UTE procesará el SOLAPERT, lo cual consiste en la
realización de la copia de MASTER de los EC solicitados al entorno de
desarrollo correspondiente.
Al procesar el SOLAPERT el(los) objeto(s)
queda(n) bloqueado por la petición que lo solicita en el entorno de desarrollo
que le fue asignado en el alta de la petición. En este momento la petición pasa a estado AP (apertura). Mientras
la petición se encuentre en estado AP será posible el bloqueo o desbloqueo de
EC.
Una vez terminada la construcción del
requerimiento y obtenido el OK a la construcción del SM (HIT-050 Hito de
Aprobación de Pruebas de Sistemas), la SWF procederá a solicitar el COMUDISP (Comunicado de Disponibilidad) al
equipo de gestión de configuración de la UTE. El COMUDISP
es la comunicación de que los EC asociados a una petición se encuentran
disponibles para ser liberados en MASTER y a Producción. Una vez enviado el
COMUDISP en la base de datos, la Petición pasará a estado RV (revisión).
Una vez pasada a estado RV, el equipo de
gestión de configuración realizará una revisión de la petición: congruencia
de los objetos bloqueados, revisión de los RAI y Datos adicionales de
instalación y comprobación de la ubicación de los EC en los entornos de
desarrollos. Posteriormente, liberará la petición. La
liberación implica la actualización en MASTER de los EC dados de alta o
modificados por la
petición. Una vez los objetos han sido masterizados, la
petición pasa a estado PV.
El proceso de liberación de la petición se
realizará conforme a lo especificado en el Procedimiento de liberación de
versiones:
3.3
ESTADO DE LA CONFIGURACIÓN
La herramienta de Administración
de entornos permite el seguimiento del historial de cambios realizado sobre los
productos liberados. Recoge el tipo de cambio realizado, así como los datos de
la versión que los pone en Producción. De este modo se puede conocer el
historial de cambios realizados sobre cualquier elemento de software bajo
gestión de la
configuración. Adicionalmente, el código tendrá etiquetados
los cambios realizados sobre el mismo.
Informe de Versión. Este documento contendrá las peticiones de cambios contenidas en la versión, la prioridad de
estas peticiones de cambio, el código de anomalía o código de requerimiento
asociado a las peticiones de cambio versionadas, la descripción de las
peticiones de cambio, así como la relación de software versionado para cada
petición de cambio; se indicará: Tipo de objeto, Código de objeto, y acción
realizada sobre el mismo (Alta, baja o modificación de software).
3.4
REVISIONES Y EVALUACIÓN
DE LA CONFIGURACIÓN
3.5
CONTROL DE INTERFACES
Durante la elaboración del diseño
del proyecto se detectarán los sistemas impactados por las especificaciones del
mismo; las interfaces quedarán recogidas en el documento DIS-030-Diseño técnico
(Apartado 4).
3.6 GESTION DE VERSIONES Y ENTREGA
El equipo de Gestión de
configuración de la SWF realizará el empaquetado de los elementos modificados
que deban ser puestos en producción, de acuerdo al procedimiento de Liberación
de Versiones.
Se entrega para su puesta en
producción el contenido en la librerías de versión (contenido de estas indicado
en el punto 4.1.4), será el equipo de IBM el que copiará a Producción los objetos
contenidos en estas carpetas, tanto fuentes como ejecutables. También se
realizará la entrega de cualquier otra documentación necesaria para la
liberación (Ejemplo: hoja Excel con los registros a inserta/modificar de Tablas
de Mantenimiento centralizado, documentación referenciada en los
requerimientos, etc.…).
4 PLANIFICACION
El proceso a seguir en la
Planificación de los proyectos será el definido en la metodología Procede
y en los procedimientos acordados entre Cliente y proveedor.
Los hitos planificados para cada
subproyecto se encuentran registrados en el REQ-040-Plan de
Proyecto/Subproyecto.
5 RECURSOS
Se utilizaran las siguientes
herramientas:
-
Repositorio documental Procede
-
Entorno tecnológico
-
Sistema comercial
-
Metodología Procede
Procedimientos operativos acordados entre Cliente y proveedor.
6 MANTENIMIENTO DEL PLAN.
El responsable de Soporte
Funcional del subproyecto será el encargado de monitorizar el Plan de Gestión
de la Configuración.
El Plan de la Configuración se
revisará al menos anualmente y siempre que se detecte algún cambio en la
gestión de la configuración que deba ser reflejado en el plan.
El Plan de la Configuración será
aprobado por el responsable del servicio del proveedor
y posteriormente se enviará al equipo de QA del cliente para su aprobación.
En el entregable REQ-040 Plan de
proyecto/subproyecto se indicará el Plan de Gestión de la Configuración que se
seguirá en él. El REQ-040 Plan de proyecto/subproyecto deberá ser aprobado por
el Solution Manager responsable del proyecto.
