Plan Configuracion JARC

Andrés González. 201018063 Julián Morales. 200213074Carlos Criales. 200925612José Daniel García. 200818257Robinson De La Hoz. 201018033Haiver Páez. 201018119

Pág. 1 de 23

Plan deAdministración

de la

Especialización enconstrucción de softwareUniversidad de los Andes

Bogotá 2010

Plan de Administración de la ConfiguraciónMEJORAMIENTO DEL PROCESO ORIGINACION DE CREDITO

.JARC

Versión 1.40

19-oct-22

Pág. 2 de 23

Control de VersionesFecha Versión Descripción Autor

20-03-2010

1.0 Primera Versión del Documento .JARC

Pág. 3 de 23

Tabla de Contenido

1. INTRODUCCIÓN 51.1. PROPÓSITO 51.2. ALCANCE 51.3. DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES 51.4. REFERENCIAS 51.5. VISIÓN GENERAL 5

2. ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE 62.1. ROLES Y RESPONSABILIDADES 62.2. HERRAMIENTAS, AMBIENTE E INFRAESTRUCTURA 7

2.2.1. Herramientas de administración de la configuración: 72.2.2. Servidores: 72.2.3. Plataformas Cliente 72.2.4. Gestión de la seguridad 8

2.3. ADMINISTRACIÓN Y MANTENIMIENTO 82.3.1. Estrategias de Backup 8

3. PROGRAMA DE ADMINISTRACIÓN DE CONFIGURACIONES 93.1. IDENTIFICACIÓN DE LA CONFIGURACIÓN 9

3.1.1. Métodos de Identificación 93.1.2. Líneas Base del Proyecto 11

3.2. ADMINISTRACIÓN DE CAMBIOS Y CONFIGURACIONES 123.2.1. Proceso de Administración de Configuraciones 123.2.2. Proceso de Administración de Cambios 133.2.3. Comité de Control de Cambios 14

4. HITOS 155. RECURSOS 166. BIBLIOGRAFIA 17

Plan de Administración de la Configuración1. INTRODUCCIÓN

1.1. PropósitoEl objetivo de este documento es presentar la estrategia generalpara la Administración de Configuraciones de la aplicaciónMEJORAMIENTO DEL PROCESO ORIGINACION DE CREDITO (en adelanteMEPROC).

Pág. 4 de 23

1.2. AlcanceEl contenido de este documento será aplicable a todos losinvolucrados en la administración del entorno de Gestión de laConfiguración en .JARC para la aplicación “MEPROC”.

1.3. Definiciones, Acrónimos y AbreviacionesMEPROC – MEJORAMIENTO DEL PROCESO ORIGINACION DE CREDITOACS – Administración de la Configuración de SoftwarePAC – Plan de Administración de la ConfiguraciónFS – Fábrica de SoftwareRUP – Rational Unified ProcessLT – Líder Técnico

1.4. Referencias [1] ANSI/IEEE Std 828-1990, IEEE Standard for SoftwareConfiguration Management Plans.

1.5. Visión GeneralEste documento contiene la documentación requerida para conocer yorganizar el entorno de control de cambios y configuraciones paraMEPROC y está organizado de acuerdo a las siguientes secciones:

1. Introducción : Resume el contenido de este documento.2. Administración de la configuración del software : Explica los

roles y responsabilidades de la ACS-MEPROC, describe losrequerimientos de hardware y software; y provee una visióngeneral del PAC.

3. Identificación de la configuración : Muestra el modelo usadopara ACS-MEPROC, la estrategia de streams, convenciones denombramiento, modelo de promoción y guías de administraciónde los espacios de trabajo.

4. Configuración y control de cambios : Se incluye en estedocumento la información referente a la configuración ycontrol del cambio; y el flujo de requerimiento de cambio.

5. Control de los estados de la configuración : explica losestándares de presentación de informes para ACS-MEPROC.

6. Hitos : Describe los hitos principales del ACS-MEPROC.7. Capacitación y Recursos : describe la capacitación requerida

por el equipo de trabajo y lista cualquier recurso externoque se requiera en el ACS-MEPROC.

Pág. 5 de 23

8. Subcontratistas y proveedores : Documenta el esquema detrabajo con los proveedores de FS para el ACS-HC

Pág. 6 de 23

2. ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

2.1. Roles y ResponsabilidadesEl equipo de MEPROC en lo relacionado con la Administración de laConfiguración esta conformado por las siguientes personas: unequipo de desarrolladores (fábrica de desarrollo), unadministrador de la configuración, un administrador de releases ylas responsabilidades del integrador que están compartidas por lafábrica de desarrollo y el líder de proyecto de .JARC. Acontinuación en la tabla se describen los roles yresponsabilidades:

CM Rol Responsabilidades

Recurso

Jefe delproyecto

Definir loscomponentes dedesarrollo.Definir el controlde accesos.Definir políticasgenerales.Definir laconsecución dehitos.Asignar actividades.

Julián Morales

Administradorde laConfiguración

Crear losrepositorios deadministración deconfiguraciones.Configurar elentorno UCM para elproyecto MEPROCImplementar laspolíticas definidaspor el Jefe delproyecto MEPROCEstablecer backupsde CC y CQ; y surecuperación.Mantenimiento de CC

Carlos JavierCriales Cardozo

Pág. 7 de 23

y CQ.Administración deusuarios de CC y CQ.

Administradorde Releases

Implementar lospasos de loselementos al entornode producción apartir de las líneasbase creadas por elSistema deAdministración deConfiguraciones

Andrés González

Integrador delproyecto(Fábrica deDesarrollo)

Identificar posiblesconstrucciones en elentorno dedesarrollo.Entregar losrequerimientosimplementados demanera formal parasu integración.Sincronizar cuandosea necesario loscambios realizadospor la fábrica conel punto de entradaal Sistema deAdministración deConfiguraciones.

Robinson De la Hoz

Integrador delproyecto(.JARC)

Identificar posiblesconstrucciones paralos entornos depruebas yproducción.Planificar lasliberaciones de laslínea base delproductoEstablecerliberacionesSeleccionar la

Robinson De la Hoz

Pág. 8 de 23

ubicación paraartefactos liberados

Desarrolladores

Crear vistas dedesarrollo.Trabajar con losítems deconfiguración.Promover cambios.

Julián MoralesRobinson de la HozJosé Daniel GarcíaAndrés GonzálezCarlos JavierCrialesHaiver Páez

2.2. Herramientas, ambiente e infraestructura

2.2.1. Herramientas de administración de la configuración: Las herramientas que se utilizaran para la Administración decambios son TortoiseSVN y para la administración deconfiguraciones es TortoiseSVN. Las dos herramientas se van aintegrar con el fin de enlazar las actividades de desarrollo oregistros de cambios con las versiones generadas en MEPROC.

2.2.2. Servidores:

El servidor de Google Code que va a contener el repositorio parala aplicación MEPROC es el http://code.google.com/p/meproc/.Adicionalmente, el servidor xue.uniandes.edu.co contendrá la basede datos del esquema de repositorios y de usuario que seráutilizada por este proyecto, los servidores xue.uniandes.edu.co /www.lagentek.com. El resumen de los roles asumidos por losservidores se encuentra en la siguiente tabla:

Pág. 9 de 23

2.2.3. Plataformas Cliente

Sistemaoperativo

RAM Clase deCPU

Almacenamiento disponible

Windows7Ultimate

4 GB Intel Core2 Duo 2P8400

100 GB

Windows7

4 GB Intel Corei5

240 GB

Windows7

2 GB AMD Athlon64 bits

550 GB

WindowsXP

3 GB Intel Core2 Duo 2.8Ghz

120 GB

SnowLeopard

2 GB Intel Core2 Duo 2.2Ghz

250 GB

Windows7 HomePremium

4 GB Intel Corei3 2.2 Ghz

100 GB

WindowsVista

2 GB IntelCeleron 2.3Ghz

41 GB

2.2.4. Gestión de la seguridad

La siguiente tabla describe la administración de cuentas deusuarios y grupos requeridos.

ID usuario o GrupoGlobal

Dominio

Descripción Notas adicionales

Project_Owners PropietariosdelProyecto

Dueño y administrador delproyecto puede realizarcualquier cambio sobre elproyecto.

Project_Commiters TrabajadoresdelProyecto

Grupo de usuarios quepueden trabajar en elproyecto pero noconfigurarlo.

Project_Contributors Participantedel

Son usuarios como si nofueran miembros pero su

Pág. 10 de 23

Proyecto rol en el proyecto esvisible.

2.3. Administración y mantenimiento

2.3.1. Estrategias de BackupSe realizaran copias de seguridad local de los archivos fuentedel proyecto dos veces por semana los días lunes y jueves, elencargado de esta labor será el líder de soporte, los archivosfuente serán almacenados en el disco duro y en un CD, para tenerredundancia de la información.

Pág. 11 de 23

3. PROGRAMA DE ADMINISTRACIÓN DE CONFIGURACIONES

3.1. Identificación de la Configuración3.1.1. Métodos de Identificación

La nomenclatura para los artefactos de los proyectos, ya seanestos documentos, planes, modelos, etc., seguirá el siguientepatrón, con excepción de aquellos artefactos ya construidos o queno puedan ser renombrados como en el caso del código fuente:

PRY.DIS.T.NombreArfecto

En donde,

PRY: Sigla para identificar de manera única el proyecto.

DIS: Sigla de máximo tres (3) caracteres para identificar ladisciplina a la que pertenece el artefacto que está siendonombrado en la metodología, puede ser una de las siguientes:

MNG – Modelado de Negocio REQ – Requerimientos AYD – Análisis y Diseño IMP – Implementación PRU – Pruebas DES – Despliegue GPY – Gerencia de Proyecto CM – Administración de Cambios y Configuraciones ENT – Entorno

T: Carácter que identifica el tipo de artefacto, puede ser uno delos siguientes:

D: Documento P: Plan M: Modelo H: Archivo especial de herramienta.

NombreArtefacto: Nombre descriptivo del artefacto, no debecontener espacios y cada palabra debe empezar con su primeraletra en mayúscula, debe incluir su extensión.

Ejemplos:

Pág. 12 de 23

MEPROC.REQ.D.DocumentoVisión.doc (Documento de Visión delproyecto MEPROC)MEPROC.GPY.P.PlanDesarrolloSoftware.mpp (Cronograma del Plan deDesarrollo de Software del proyecto de mantenimiento de MEPROC)

Para los elementos de software propios de la aplicación MEPROC seespecifico una nomenclatura de nombramiento detallada acontinuación.

La estructura de carpetas definida para la aplicaciónMEJORAMIENTO PROCESO DE ORIGINACION DE CREDITO es la siguiente:

binclassesdatadocslibsourcetest

Pág. 13 de 23

Especificaciones

Bin: Los componentes ejecutables que son generadosautomáticamente por el IDE para generar documentación y versionesde la aplicación.

Classes: Archivos en bytecode de la aplicación generadosautomáticamente por el IDE que son de solo lectura son propios dela aplicación.

Data: Dedicada al almacenamiento y lectura de archivos a serusados en la aplicación como por ejemplo archivos de parámetros ode almacenamiento temporal.

Docs: Documentación requerida para el desarrollo de la aplicacióncomo diagrama de clases, descripción de requerimientosfuncionales, descripción de la aplicación entre otros que seanútiles para el desarrollo de la aplicación, no es permitidodefinir el nombre del archivo relacionado con fechas.

Lib: Librerías adicionales requeridas en el uso de la aplicaciónpara ser importadas, debe estar empaquetadas en archivos Java.

Source: La estructura creada para este componente fueespecificada por fabrica y se debe mantener el estándar en lasentregas, de igual forma los fuentes siempre se deben entregarcon el nombre allí especificado sin incluir: fechas, consecutivosy/o números de requerimientos.

Test: Se contiene una estructura definida para la ejecución depruebas automáticas, la estructura de este componente fueespecificada por fabrica y se debe mantener el estándar igual quelas entregas de código fuente, además los fuentes siempre sedeben entregar con el nombre allí especificado sin incluir:fechas, consecutivos y/o números de requerimientos.

3.1.2. Líneas Base del ProyectoTodos los cambios autorizados deben hacerse sobre un estándaroficial en términos de líneas base (baselines) del proyecto. Estaslíneas base deben ser creadas periódicamente y gestionadas

Pág. 14 de 23

durante el ciclo de vida, de tal manera, que representenconfiguraciones estables que se utilizan como “puntos de corte”,en los cuales se “congelan” los artefactos del proyecto en unpunto de tiempo determinado.

Durante el ciclo de vida del proyecto, se deben crear líneas basecon una periodicidad mínima que permita crear estas líneas basecada vez que se tenga una planificación de liberación de unconjunto de requerimientos. En general, esto lo debe definir elIntegrador de MEPROC de .JARC. El contenido de esta línea baseson todos los artefactos que se hayan creado y modificado a lolargo del proyecto en la versión en la que se encontraban almomento de la creación de la línea base. Se debe crear esta líneabase en Google Code incluyendo los cambios generados por losrequerimientos que se quieren empaquetar o integrar en la líneabase.

El nombramiento de la línea base se debe hacer utilizando elsiguiente estándar:

PROYE_N.XXX.YY_DDMMAA

En donde,

PROYE: Abreviación de máximo cinco (5) caracteres paraidentificar de manera única el proyecto o la aplicaciónN.XXX.YYY: Identificador número de la versión del producto querepresenta esta línea base (baseline):N: Número de la versión mayor del producto que va a ser liberadaexterna y oficialmenteXXX: Número de 001 a 999 que representa la versión consecutivadel producto en el entorno de integración y aseguramiento decalidad. Cada liberación (release) que tenga cualquier cambio debetener un número consecutivo diferente.YY: Número de la versión del producto cuando se libera de manerano intencionada, es decir, cuando los cambios hacen que se libereuna versión correctiva o “fix pack” sobre una versión liberadapreviamenteDDMMAA: Día, Mes y Año de la creación de la línea base.

Ejemplo:MEPROC_1.028.003_250508

Pág. 15 de 23

3.2. Administración de Cambios y Configuraciones3.2.1. Proceso de Administración de Configuraciones

La creación de líneas base se hará en el Stream de Integracióndel proyecto, cada una de estas líneas base será promovidadurante el ciclo de vida utilizando los siguientes niveles depromoción:

1. Creada2. Construida3. Probada_LT4. Probada_UAT5. Rechazada6. Liberada

Cada uno de los Streams “hijos” del Stream de integración estaránseleccionando una línea de base determinada, con excepción delStream de Desarrollo en el cual se implementarán los cambios ylas entregas que se hagan de fábrica. De esta manera, porejemplo, el Stream de Pruebas LT, deberá estar seleccionando lalínea base más reciente que se encuentre en el nivel de promoción“Probada_LT” y así sucesivamente.

El ciclo de la vida para la Administración de Configuracionesfunciona de la siguiente forma:

1. Los cambios realizados en el entorno de desarrollo por lafábrica se implementarán utilizando el mecanismo de“checkin-checkout” de los elementos con una vista que apuntaal Stream de Desarrollo de MEPROC, estos son los cambios quese deben implementar para darle soporte a los requerimientossolicitados, estos requerimientos se mapean a actividades.

2. Una vez estos requerimientos se han terminado, el Integradorde parte de la fábrica le informa al Integrador de .JARC,cuáles requerimientos están listos para su entrega y procedea hacer la entrega de estos requerimientos ejecutando laoperación de “deliver” de los mismos, mediante la cual estosrequerimientos pasan al Stream de Integración del proyecto.

Pág. 16 de 23

3. Según la planificación mantenida por el integrador de .JARC,este decide agrupar o empaquetar estos requerimientos paraque hagan parte de una línea base. La creación de línea baseanalizará las actividades UCM dependientes y se lasinformará al integrador en caso que sea necesario. La líneabase recién creada estará en el nivel de promoción “Creada”.

4. Se procederá a hacer una verificación inicial de compilacióny de aceptación del build obtenido, después de la cual lalínea base será promovida a “Construida”, en caso contrarioserá promovida a “Rechazada”.

5. Cuando se planifique el paso a pruebas del líder técnico, seprocederá a hacer un “rebase” de la línea base al Stream dePruebas LT, en donde se harán las pruebas respectivas por ellíder técnico. En caso de que la verificación sea exitosa,la línea base será promovida a “Probada_LT”.

6. Cuando se planifique el paso a pruebas de aceptación deusuario, se procederá a hacer un “rebase” de la línea baseal Stream de Pruebas UAT, en donde se harán las pruebas deaceptación de usuario. En caso de que la verificación seaexitosa, la línea base será promovida a “Probada_UAT”.

7. Cuando se planifique el paso a producción, se procederá ahacer un “rebase” de la línea base al Stream de Producción yse promoverá la línea base a “Liberada”.

8. Cuando existan correctivos urgente, se procederá a hacer unrebase desde el Stream de Producción al Stream “hijo” deCorrectivos, en el cual se implementarán las modificacionesurgentes que al ser terminadas se entregarán mediante unaoperación “deliver” al Stream de Producción. Para replicarestos cambios al resto del entorno, se verificarán losárboles de versiones de los elementos modificaciones y sehará una operación de deliver desde el Stream de Correctivoshacia los Streams de Desarrollo y/o Integración para que loselementos tomen estos cambios.

9. El ciclo se repite.

3.2.2. Proceso de Administración de Cambios

Se entiende como cambio todo aquello que afecte la línea base delsistema.

Pág. 17 de 23

Los cambios pueden proceder tanto a mejora como a la correcciónde errores, el procedimiento para el manejo de cambios serealizara de la siguiente manera:

Cada vez que se realiza una solicitud de cambio es deber llenarun formato que debe quedar publicado en el sitio web delproyecto, toda la información necesaria debe ser diligenciada yentregada al responsable de recibir esta solicitud.

Cambios en los Requerimientos: Debe ser diligenciado elformato MEPROC.REQ.D.CambiosRequerimientos.docx y este seentregara al Líder del Grupo quien será el responsable deevaluar el cambio.

Cambios en el Diseño: Este formato es el denominadoMEPROC.AYD.D.CambiosDisenio.docx y el responsable deber serel Líder de Desarrollo quien evaluara el impacto yrealizara los ajustes necesarios de ser el caso.

Cambios en la Arquitectura: Cambios en la arquitectura delproyecto debe llenarse el documentoMEPROC.AYD.D.CambiosArquitectura.docx y se entregan alLíder de Desarrollo

Cambios en las Herramientas: Las herramientas usadas sonresponsabilidad del Líder de Soporte, quien evaluaralicencias, disponibilidad en usar determinada herramientaentre otros aspectos a evaluar en el desarrollo delproyecto a esta persona se le entregara el documentoMEPROC.CM.D.CambiosHerramientas.docx y se aprobara orechazara el cambio.

Cambios en la Documentación: La documentación del proyectoestá a cargo del Líder de Calidad se deberá evaluaraspectos sobre la viabilidad de agregar nuevos documentos yla forma de estos que se pueden ver influenciada a aspectosexternos como una certificación ISO, se debe diligenciar eldocumento MEPROC.CM.D.CambiosDocumentacion.docx y seentregara a esta persona encargada.

Pág. 18 de 23

3.2.3. Comité de Control de Cambios

Se realizaran comités una vez por semana liderada por el líderdel grupo quien se reunirá con todos los líderes del proyecto yle informaran al líder del grupo los cambios efectuados dentro dela semana para evaluar el impacto que pueda tener sobre eldesarrollo del proyecto, también a modo de reunión extemporánease pueden reunir un líder con el líder del grupo en cualquiermomento en caso de necesitar una evaluación sobre un cambio parasu aprobación o rechazo de este.

Pág. 19 de 23

4. HITOSSe deben establecer la coordinación y secuencia de actividadesque puedan afectar la implementación o desarrollo del proceso enun cronograma.Se debe incluir un plan que defina las dependencias con losprocesos y los principales hitos en la planificación del proyectolabor realizada por el Líder de Planeación.Entre algunos hitos tenemos:

Definición de línea base Implementación del control de cambios Inicio de pruebas

Pág. 20 de 23

5. RECURSOS

Herramienta Descripción

EnterpriseArchitect

Permite modelar visualmente UML

Microsoft Office2007

Suite de oficina que incluye procesador de textos, hojas decálculo, presentaciones.

dotProject Herramienta útil para la administración de proyectosQualDev Planning

ToolExtender la funcionalidad de dotProject para la planeacióny seguimiento de los proyectos

TeamViewer Permite acceso remoto a otro computadorSkype Servicio de Llamadas desde el PC

TortoiseSVN Cliente de control de cambios

Pág. 21 de 23

Pág. 22 de 23

6. BIBLIOGRAFIA

- www.fing.edu.uy/inco/cursos/ingsoft

- www.wikipedia.org

Pág. 23 de 23