El objetivo de este proceso es establecer el Sistema de Gestión de la Configuración del proyecto, definiendo un Plan de Gestión de la Configuración, y preparar un repositorio SVN para el proyecto siguiendo dicho Plan, y con la estructura de directorios que define el citado Plan.

Los siguientes son los roles participantes en este proceso:

El Plan de Gestión de la Configuración es un documento en el que se describe cómo se va a gestionar la configuración dentro del proyecto, dónde se van a guardar los artefactos, cómo se van a nombrar, de qué manera se van a gestionar la versiones, etc. Este documento debe ajustarse al ciclo de vida del código del proyecto en MEDEA. En dicho documento se explica cómo deben gestionarse versiones del proyecto, cómo liberar release, etc. El seguir este documento hace que casi todos los proyectos que sigan MEDEA tengan un Plan de Gestión de la Configuración casi idéntico.

Este documento va a ser casi idéntico para TODOS los proyectos que sigan MEDEA.

El Gestor de la Configuración debe crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

Crea un nuevo Plan de Gestión de la Configuración (PGC) siguiendo las instrucciones de nombrado. A continuación definimos dicho Plan, indicando cuestiones como:

• Roles que intervienen en la gestión de la configuración.
• Procesos de checkin.
• Procesos de aprobación de baselines.
• Ciclo de vida de código del proyecto.
• Procesos de aprobación de cambios.
• Trazabilidad.
• Artefactos sometidos a la gestión de la configuración.
• Estructura de directorios del proyecto.
• Nombrado de ficheros.
• Versionado de la aplicación.

En el apartado 1.1 del Plan de Gestión de la Configuración se introducirá el nombre del Gestor de la configuración. En el apartado 1.2 del Plan de Gestión de la configuración rellena los nombres de las personas que intervienen en el Comité de Control de Cambios (CCB). Si se trata de un proyecto pequeño con el Jefe de proyecto y el Gestor de la configuración, que en muchos casos será la misma persona, es suficiente. Si es un proyecto más grande conviene que dentro del CCB se encuentre el cliente, algún analista y algún programador que pueda estimar esfuerzos.

En el apartado 2 del Plan de gestión de la configuración se indican los procesos de checkin de tronco y ramas de la aplicación. En principio todos los proyectos tendrán los mismos procesos para hacer checkin. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

En el apartado 3 del Plan de gestión de la configuración se indican los procesos de aprobación de baselines. En principio todos los proyecos tendrán los mismos procesos para aprobar baseline. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

En el apartado 4 del Plan de gestión de la configuración se muestra un gráfico con el ciclo de vida del código del proyecto. En principio todos los proyectos tendrán el mismo ciclo de vida del código del proyecto. Cambios en el ciclo de vida del proyecto deben estar plenamente justificados y deben ser aprobados por la sección de Metodologías, Normalización y Calidad del Software.

Ver Proceso Control de Cambios en Gestión de la Configuración.

En el apartado 6 del Plan de gestión de la configuración se indica cómo debe mantenerse la trazabilidad dentro del proyecto. En principio todos los proyectos tendrán los mismos procesos para mantener la trazabilidad. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

En el apartado 7 del Plan de gestión de la configuración se indica las herramientas a utilizar para gestionar la configuración en el proyecto. En principio todos los proyectos tendrán las mismas herramientas. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

En el apartado 8 del Plan de gestión de la configuración se indican de manera genérica los artefactos que serán sometidos a gestión de la configuración. Más adelante, al crear la matriz estandar de items de configuración se indicarán con todo detalle los items sometidos a gestión de la configuración y su ubicación.

En el apartado 9 del Plan de gestión de la configuración se indica la estructura de directorios que tendrá el proyecto. En principio todos los proyectos tendrán la mismas estructura de directorios. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos. No obstante ten en cuenta que si se modifica la estructura de directorios del proyecto debe parecerse mucho a la propuesta en MEDEA y que deben existir carpetas para versiones y ramas de manera obligatoria.

Nombre_Proyecto 
  |
  |__Proyecto 
  |    |
  |    |__Fuentes 
  |    |    |
  |    |    |__NombreProyecto 
  |    |    |__BD 
  |    |       |__modeloER 
  |    |       |__NombreEsquema 
  |    |       |  |__consultas
  |    |       |  |__funciones 
  |    |       |  |__paquetes 
  |    |       |  |__procedimientos 
  |    |       |  |__secuencias 
  |    |       |  |__servicios 
  |    |       |  |__tablas 
  |    |       |  |__triggers 
  |    |       |  |__vistas 
  |    |
  |    |__Documentacion 
  |         |
  |         |__1.GestionProyecto 
  |         |       |__1.1.Planificacion 
  |         |       |__1.2.OrdenesYactas 
  |         |       |__1.3.Seguimiento 
  |         |       |__1.4.Metricas 
  |         |
  |         |__2.Requisitos 
  |         |       |__2.1.Funcionales 
  |         |       |__2.2.NoFuncionales 
  |         |
  |         |__3.AnalisisYdiseno 
  |         |       |__3.1.Arquitectura 
  |         |       |__3.2.UML 
  |         |       |__3.3.BaseDatos 
  |         |       |__3.4.Prototipado 
  |         |
  |         |__5.Calidad 
  |         |       |__5.1.TestFuncionales 
  |         |       |__5.2.TestCarga 
  |         |       |__5.3.CalidadInterna 
  |         |
  |         |__6.Despliegue 
  |         |       |__6.1.Formacion 
  |         |
  |         |__7.GestionConfiguracion 
  |         |__8.DocumentacionAdicional 
  |        
  |
  |__versiones 
  |      |
  |      |__1.0.0.Beta 
  |      |     |__Fuentes 
  |      |     |    |
  |      |     |    |__NombreProyecto 
  |      |     |    |__BD 
  |      |     |        |__modeloER 
  |      |     |        |__NombreEsquema 
  |      |     |           |__consultas 
  |      |     |           |__funciones 
  |      |     |           |__paquetes 
  |      |     |           |__procedimientos 
  |      |     |           |__secuencias 
  |      |     |           |__servicios   
  |      |     |           |__tablas 
  |      |     |           |__triggers 
  |      |     |           |__vistas 
  |      |     |    
  |      |     |__Documentacion 
  |      |          |__1.GestionProyecto 
  |      |          |__2.Requisitos 
  |      |          |__3.AnalisisYdiseno 
  |      |          |__5.Calidad 
  |      |          |__6.Despliegue 
  |      |          |__7.GestionConfiguracion 
  |      |          |__8.DocumentacionAdicional 
  |      |
  |      |__1.0.0 
  |      |__1.0.1 
  |      
  |__ramas 
  |      |
  |      |__1.0.0.CR1 
  |      |__1.0.0.CR2 
  |      |__1.0.0.Beta1 
  |      |__1.0.1.CR1 
  |
  |__tags
  |      |
  |      |__101216_rev20
  |      |__111216_rev21
  |      |__151216_rev33
  |
  |__web_desa
  |
  |__web_test
  |
  |__web_prod

Tags: Representa las versiones de código candidatas a ser desplegadas en el entorno de producción. Estas versiones se generan a partir de despliegues exitosos en el entorno de test.

El contenido de esta carpeta se generará automáticamente por el servidor de integración continua (Jenkins). Se incluirá un Tag por cada despliegue en el entorno de test que se haya realizado con éxito. Es responsabilidad de los desarrolladores crear los test necesarios para asegurar que los despliegues en este entorno están suficientemente probados.

El formato de nombrado de cada tag es: [fechaDespliegue(ddmmyy)]_rev[Número revisión svn en la que se basa el despliegue]

En el apartado 9 del Plan de gestión de la configuración se indica cómo deben nombrarse los ficheros del proyecto. En principio todos los proyectos tendrán las mismas convenciones para el nombrado de ficheros. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

• ACT: acta
• ANA: documento de análisis
• ANM: documento de análisis de módulo
• CPU: casos de prueba de usuario
• CRA: control de requisitos de accesibilidad
• CRN: cronograma
• CRS: control de requisitos de seguridad
• CUS: caso de uso
• DAR: diagrama de arquitectura global
• DARM: diagrama de arquitectura de módulo
• DART: diagrama de arquitectura tecnológica
• DGF: documento de gestión de la accción formativa
• DIS: documento de diseño
• DISM: documento de diseño de módulo
• DPC: documento de petición de cambio
• DRQ: documento de requisitos
• DRS: Documento retrospectiva sprint
• ENA: Encuesta a los alumnos
• ECP: Estadisticas de cierre de proyecto
• FIC: Ficha de Seguimiento del Pórtico (nuevo desde 2019 y provisional)
• HST: historia
• MAN: manual de usuario
• MDT: modelo lógico de datos
• MDT: modelo físico de datos
• MET: métricas
• MIC: matriz de items de configuración
• NAV: documento de navegación entre páginas
• ORD: orden del día
• PAF: presentación de acción formativa
• PDM: Presentación demo de sprint
• PGC: plan de gestión de la configuración
• PLR: plan de release
• PP: plan de proyecto
• PRT: prototipado de pantalla
• QCP: Caso de prueba
• QCPC: Casos de prueba de carga
• QCPA: Caso de prueba automatizado
• QCPR: Caso de prueba de requisito
• QMT: Matriz de trazabilidad
• QRTC: Resultados test de carga
• QTC: Test de carga
• RNF: requisitos no funcionales
• REQ: Documento de Requisitos
• UML: diagramas UML
  • Diagrama de clases conceptual
  • Diagrama de clases de diseño
  • Diagrama de interacción entre módulos
  • Diagrama de secuencia de diseño
• VIS: documento de visión
• QCP: documento de casos de prueba
• QCPR: documento de casos de prueba de requisito
• QRCP: documento de resultados de casos de prueba
• QCPA: caso de prueba automatizado
• QCPC: caso de prueba de carga
• QTC: test de carga
• QRTC: resultado de test de carga
• SRC: Cronograma de seguimiento
• SRL: Seguimiento de Release

En el apartado 10 del Plan de gestión de la configuración se dan instrucciones acerca de cómo gestionar el versionado del software en el proyecto. En principio todos los proyectos seguirán las mismas instrucciones para el versionado del software. Comprueba lo que dice el plan y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

Este documento define todos los tipos de artefactos que va a haber en el proyecto, cómo han de nombrarse y dónde han de colocarse. En principio este documento es común a todos los proyectos.

El Gestor de la Configuración debe crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

Crea un nuevo Matriz estándar de items de configuración (MIC) siguiendo las instrucciones de nombrado. Comprueba el contenido del documento y realiza alguna modificación si es necesario, pero en principio este apartado será común para todos los proyectos.

La matriz estándar de ítems de configuración incluye la siguiente información para cada uno de los tipos de artefactos:

• Descripción del ítem de configuración
• Código del tipo de artefacto
• Nombre que tendrá en el proyecto
• Directorio padre
• Directorio
• Subdirectorio
• Observaciones

El repositorio ya fue creado en la tarea MDA-TR-1.0-GP-Crear y configurar el entorno del Proyecto del proceso MDA-TR-1.0-GP-Crear y configurar el entorno del Proyecto.

Una vez hemos realizado el primer checkout del proyecto debemos modificar algunas carpetas. A continuación realizaremos las siguientes acciones:

• Renombrar el directorio /proyecto/fuentes/bd/NombreEsquema con el nombre del Esquema de base de datos.

svn mv /proyecto/fuentes/bd/NombreEsquema /proyecto/fuentes/bd/Esquema

• Si tuvieramos objetos de base de datos de varios esquemas copiaremos el directorio /proyecto/fuentes/bd/NombreEsquema para cada uno de los esquemas que utilicemos.

svn cp /proyecto/fuentes/bd/Esquema1 /proyecto/fuentes/bd/Esquema2

También puedes realizar estas dos acciones con Tortoisesvn utilizando las opciones svn Mover ficheros versionados aquí o svn copiar ficheros versionados aquí de Tortoisesvn, pinchando con el botón derecho del ratón sobre la carpeta y escogiendo la opción adecuada.

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Gestión de la Configuración - GC-Establecer Sistema Gestión Configuración

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.