GERENCIA DE SISTEMAS INFORMÁTICOS

GERENCIA DE TECNOLOGÍAS DE LA INFORMACIÓN
PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (ACS)
PARA LOS ITEMS DEL PROYECTO 14101
Fecha: Mayo de 2011.
No. proyecto: 14101.
Responsable de ACS: ISC. Dirceu Pérez Vidal
Herramientas: DARWIN, SODA y PROTAGON pertenecientes a la herramienta de colaboración
para el desarrollo de software Génesis.
CollabNet Subversion para las aplicaciones Grails.
REGLAS Y ACTIVIDADES:
1. Para controlar las versiones liberadas instaladas en Productivo se utiliza DARWIN, que nos
permite llevar el registro y los archivos que corresponde a una versión del sistema, módulo o
documento que se entrega al cliente. Aquí se comprime en archivos .zip la versión del
sistema, módulo o documento que fue liberado incluyendo base de datos, gráficos,
documentación. Es necesario indicar en el registro la versión del sistema liberado, las
modificaciones hechas en la versión y cualquier otra observación que se considere pertinente
para la implantación de la versión en productivo.
2. Los archivos zip deberán llevar el siguiente formato:
nombre.versión
a. nombre = Nombre del sistema o ítem de configuración sin espacios y en
minúsculas. En caso de nombres compuestos se pude optar por separarlos con
guión bajo o la primer letra del segundo nombre en mayúsculas
(nombre_compuesto o nombreCompuesto).
b. versión = Número de versión del sistema o ítem de configuración.
3. En SODA se deposita cualquier elemento, componente o información que se requiera
compartir con el equipo y que no se entregue al cliente, archivos de trabajo. Los ítems de
configuración deberán llevar un número de versión si es necesario.
4. En PROTAGON se lleva un control de las solicitudes de requerimientos nuevos, cambios o
mejoras a los sistemas.
5. Los documentos cargados en SODA deberán tener un número de versión junto con el nombre
de archivo si es necesario. El nombre de archivo no sigue ningún formato en especial y el
número de versión debe ser antecedido por un punto (nombre del archivo.versión).
6. Los documentos cargados en Darwin deben seguir el control de trazabilidad de documentos
entregados a los clientes.
7. En SODA existe un registro que nos permite llevar el control de trazabilidad de documentos
entregados a los clientes.
8. Es necesario realizar un respaldo periódico a cada ítem de configuración cada vez que este
sufre alguna modificación y amerite un cambio de versión. Los ítems de configuración
deben ser publicados en Darwin o Soda.
9. Al final del proyecto se crea un CD con todos los fuentes, BD, manuales y cualquier otra
información que deba ser incorporada para establecer una versión definitiva a todos los
elementos del software que comprende el proyecto. Este es un respaldo definitivo de los
ítems de configuración
10. Los CDs de respaldo del proyecto estarán bajo resguardo físico del responsable de la ACS
o del Jefe de proyecto.
11. Todos los sistemas deben contar con una página Web para el registro de las versiones con
el nombre versión, controlVersion o ControlVersionP. En esta página se debe indicar la
fecha de liberación, nombre de los responsables de las modificaciones, número de versión y
de manera general la descripción de los cambios realizados en cada uno de los módulos
que integran el sistema.
12. Las librerías de JavaScript, LotusScrits, Java y Hojas de estilo deben llevar en la parte
superior de su contenido al menos la siguiente información:
a.
b.
c.
d.
e.
f.
Nombre de la librería
Descripción del funcionamiento de la librería u objetivo de ésta.
Número de versión.
Fecha de liberación.
Responsables de la liberación.
Cambios efectuados en la versión si es necesario.
13. El manejo del número de versión para cualquier ítem de configuración estará formado por
números decimales con el siguiente formato:
x.y.z
a.
b.
c.
d.
x = 0 para versiones en fases de desarrollo inicial.
x>=1 versiones liberadas.
Se suma 1 a x cuando se hacen entregas finales (al final del proyecto).
Se suma 1 a y cuando se hacen entregas parciales, cuando el número de
modificaciones lo amerite o cuando el impacto de los cambios sea bastante visible.
Este criterio queda a consideración de quien realice las modificaciones.
e. Se suma 1 a Z cuando se hacen entregas menores. No es forzoso el valor de z,
esto queda a consideración de quien realiza las modificaciones.
14. Todas las plantillas y bases de datos de Lotus Notes creadas o modificadas en el proyecto
deberán integrar una página de About donde se describa el nombre de la aplicación así
como la versión. Podrán tener opcionalmente fecha de última modificación y responsable de
la plantilla.
En el caso de aplicaciones GRAILS
15. Se utiliza CollabNet Subversion para el control del código de la aplicación en etapa de
desarrollo.
o
Cada miembro del equipo deberá tener instalada la aplicación cliente para poder
trabajar con los módulos que tenga asignados para lo cual deberá bajar la última
versión del código instalado en el servidor. Opcionalmente podrá instalar un cliente
gráfico como TortoiseSVN para facilitar las tareas de versionado de código.
16. Cada Viernes o después de un cambio mayor en el sistema cada miembro del equipo
subirá los cambios realizados al servidor.
o
o
Una vez que se suban los cambios al servidor, se deberán actualizar las copias del
sistema que cada desarrollador tiene en su equipo.
Cada quien deberá compilar su copia de la aplicación para verificar que no existan
errores.
17. El último viernes de cada mes, se deberá realizar un respaldo del código fuente y base de
datos del sistema.
o
Crear un “volcado” de cada uno de los repositorios que se encuentren en el
servidor SVN, el cual se nombrará con la fecha en que se realiza el volcado y el
nombre del repositorio.
i.
Orion_20081210
ii.
Mercurio_20090101
o
Guardar los archivos en la carpeta donde se lleve el control de los respaldos de la
aplicación.
bitacora_respaldos_sistema_gestion\
Orion_20081210
o
También se deberá realizar el respaldo del sistema y base de datos en un CD
grabable o disco externo conservando la estructura de la carpeta en la que se lleva
la bitácora de respaldos del sistema.
RESPALDOS
1. Cada miembro del equipo de trabajo es responsable de hacer un respaldo al menos una
vez por mes de los elementos o archivos de trabajo relacionados con el proyecto en el
dispositivo de memoria que considere conveniente, puede ser una memoria USB, puede
ser un CD o puede ser un folder compartido configurado por el RAC.
2. Una vez al mes se debe hacer un respaldo de las bases de datos de GENESIS, esta tarea
será responsabilidad del RAC, del Jefe de proyecto o de una persona designada para esta
tarea y los archivos serán resguardados en el fólder compartido que indique el RAC.
3. La evidencia del respaldo será registrada en SODA, registrando la siguiente información :
Fecha
Identificador y tipo
de respaldo
(Periódico o
Extraordinario)
Medio de
respaldo
Contenido (versión completa,
algunos módulos,
Programas,...) Productos en
desarrollo, instalados, o
entregados.
Aprobado
M.C. Isaac A. Parra Ramírez
Jefe del proyecto
Nombre del
responsable
Control de revisiones
Versión
0.1
1.0
Descripción
Primera versión del PAC
Revisión del jefe de proyecto
Responsable
Dirceu Vidal
Isaac Parra
Fecha
10/05/2011
20/05/2011