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