Plan de Gestión de Configuración.SC_GC Plan de Gestión de Configuración Proyecto: SmartCar Versión: 3 .2 Fecha: 25/05/2015 SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 2 de 16 ÍNDICE 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ficha del documento ……………………………………................... ……………….... 4 Introducción …………………………………………………………….…….................. 4 2.1. Propósito del Plan ……………………………………………………………. 4 2.2. Alcance ………………………………………………………………................ 4 2.3. Definiciones y Acrónimos……………………………………………………. 5 2.4. Referencias ………………………………………………………………….... 5 2.5. Definición de alto nivel del proceso de GCS ……………………………... 5 Especificaciones de Gestión …………………………………………………………. 6 3.1. Organización …………………………………………………………………... 6 3.2. Responsabilidades …………………………………………………………... 7 3.3. Plan de Implementación del plan …………………………………………... 7 Políticas, directivas y procedimientos aplicables ………………………………….. 8 4.1. Niveles del software en un árbol jerárquico ………………………………. 8 4.2. Nombrado de programas y módulos …………………………………….... 8 4.3. Designación de versiones …………………………………………………... 9 4.4. Identificación de documentación ………………………………………….... 9 4.5. Identificación de medios y ficheros…………………………………………. 9 4.6. Proceso de liberación de productos software……………………………... 10 4.7. Procesamiento de informes de incidencias, solicitudes de cambio y órdenes de cambio…………………………………………………..…………………... 10 4.8. Estructura y forma de operación de los CCCs…………………………….. 11 Actividades de GCS …………………………………………………..……………….... 12 5.1. Identificación…………………………………………….……………………... 12 5.2. Control de Versiones………………………………………………………….. 12 5.3. Control de cambios………………………………………………………….... 12 5.4. Generaciones de informes…………………………………………………... 13 Control de suministradores y subcontratistas…………………………………….... 13 Recogida y retención de registros……………………………………………………. 14 7.1. Documentación GCS a retener…………………………………………….... 14 7.2. Métodos y recursos para la recopilación, salvaguarda y mantenimiento de la documentación……………………………………………………………….... 14 7.3. Periodo de la retención……………………………………………………….. 14 Planificación de la GCS……………………………………………………………….... 15 Recursos de la GCS……………………………………………………………………. 15 Mantenimiento del plan de GCS………………………………………………………. 15 Historial de cambios…………………………………………………………………….. 16 SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 3 de 16 1. Ficha del Documento Título del documento Plan de Gestión de Configuración Nombre del Archivo del documento Plan de Calidad V2.1 IEEE730­2002 Número de versión 3.2 Autores: Javier Fernández Villanueva José Luis Padilla González Ismael Vallejo Amy Rojas Morán José Serrano Álvarez Jhonny Vargas Paredes Revisado por: José Luis Padilla Fecha de Creación 17/05//2015 Estado: Validado 2. Introducción 2.1. Propósito del Plan Este plan, realizado por el equipo correspondiente a la Gestión de la Configuración, tiene el objetivo de controlar y gestionar los distintos cambios que se realicen en nuestra documentación y en el diseño. Si estos no tuvieran este tratamiento, sería un alto riesgo para el continuo desarrollo de la aplicación debido a pérdidas de información y tiempo que no se pueden permitir. Vamos a seguir este método durante todo el desarrollo, manteniendo en definitiva, copias de cada versión de documento, un historial de cambios, y formalizar métodos para solicitar cambios. 2.2. Alcance Mediante las prácticas mencionadas en el apartado anterior, conseguiremos que los participantes del proyecto puedan acceder de forma rápida a cualquier documento y versión del proyecto para consultas, y que a su vez, tengan presente la versión actual que sí pueden modificar para continuar desarrollando la aplicación. Se debe tener especial cuidado en siempre acceder y modificar la versión actual y no las antiguas. Los documentos de la línea base serán: ­ ­ ­ ­ ­ ­ Gestión de Configuración del Software Especificación de Requisitos Plan de Calidad Plan de Proyecto Riesgos Planificación (se encuentra dentro del Plan de proyecto) SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 4 de 16 2.3. Definiciones y Acrónimos Definiciones ­ ­ ­ ­ ­ ­ Elemento de Configuración Software: Documento receptivo a cambios que son clave para el desarrollo del sistema. Control de Versiones: Sistema que consiste en ir enumerando una a una las versiones distintas de un documento, facilitando la GCS. Control de Cambios: Controla el ciclo de vida de los cambios. Versión: La versión de un documento hace referencia a un momento exacto de su vida, en la que se guarda para futuro uso o modificación. Revisión: Una versión que aparece con el tiempo. Línea base: Es una especificación o producto que se ha revisado formalmente y sobre el que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios. Acrónimos ­ ­ ­ ECS: Elemento de configuración software. GCS : Gestión de la configuración Software. CCC: Comité de control de cambios 2.4. Referencias Hemos usado el siguiente documento para llevar a cabo nuestra Gestión de Configuración: IEEE828­2012 ­ ANSI/IEEE Std 8281990, IEEE Standard for Software Configuration Management Plans. 2.5. Definición de alto nivel del proceso de GCS La GCS ayuda a gestionar las modificaciones que se realizan en todo el proceso de desarrollo. Su principal objetivo es maximizar la productividad evitando errores y manteniendo las versiones totalmente documentadas. Los procesos para conseguirlo son: ­ Identificar los documentos receptivos a ser gestionados por la GCS. ­ Definir el procedimiento para controlar el documento. ­ Informar del estado. ­ Revisar la GCS. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 5 de 16 3. Especificaciones de Gestión 3.1. Organización Durante los primeros meses, nos dividimos en grupos, cada grupo se encargaba de la elaboración de un documento específico como Especificación de requisitos, Gestión de Riesgos y Plan de Proyecto respectivamente, cada grupo tiene un representante que revisa y organiza el trabajo final en cada grupo. Estos últimos meses nuestra división ha cambiado, hemos cambiado nuestra organización, creando solo dos grupos. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 6 de 16 Finalmente existe un representante que es el que recopila los documentos terminados de cada grupo y realiza una última revisión para su entrega final. Comité de control de cambios (CCC) está compuesto por el representante mayor y los representantes de cada grupo. 3.2. Responsabilidades Todos los miembros toman decisiones por igual para la división del trabajo, sin embargo cada grupo es responsable de cómo se realiza su trabajo, recopilación de información, preguntas y duda, todo lo que pueda ser necesario para la elaboración de su trabajo. Los responsables de cada grupo son los encargados de cada documento, se haya organizado y repartido para que cada miembro trabaje por igual, y de asegurarse de que esté finalizado en la fecha establecida, y subido a drive, para poder ser vistos por todo el grupo final. Al final el representante del grupo es el encargado de la revisión final para su entrega final. 3.3. Plan de Implementación del plan Las discusiones y repartición de trabajo se realizan los martes de todas las semanas, cada representante de cada grupo comenta, se aclaran dudas y recopila opiniones de todos para la mejora de cada elaboración de los documentos. Los representantes de cada grupo varía, todos trabajan y aportan lo mismo en cada documento, los cambios en los miembros de cada grupo mejora la participación de todos los miembros en cada uno de los documentos. La planificación depende de cada uno de los grupos, la forma de organizar el trabajo es establecida por los mismos miembros de cada grupo, en todo momento existe comunicación entre todos los miembros a través del grupo de WhatsApp del equipo. Los documentos deben estar finalizados y revisados cada domingo de esa semana. El representante final es el encargado de la entrega de los documentos de cada grupo al profesor todos los Lunes por las mañanas. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 7 de 16 4. Políticas, directivas y procedimientos aplicable 4.1 Niveles del software en un árbol jerárquico La aplicación estará basada en una arquitectura multicapa. 4.2 Nombrado de programas y módulos Cada documento tendrá un identificador claro, es decir su nombre facilitará la explicación de su contenido.Se nombran los documentos de la siguiente manera: Especificación de Requisitos Software: SC_SRS Plan de Proyecto: SC_PP Plan de Riesgos: SC_PR Plan de Gestión de Configuración: SC_GC Plan de calidad: SC_SQA Estimación: SC_ES Del mismo modo los anexos necesarios tendrán un nombre representativo que al mismo tiempo contendra el numero del anexo que este representa. es decir SC_NombredelDocumento_Anexo<numero> SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 8 de 16 4.3 Designación de versiones Para el sistema de versiones se decidió empezar con la Versión 1.0 donde el valor entero indicará el estado del documento, mientras que los decimales corresponden al avance del desarrollo del documento. Es decir si el documento tiene un cambio menor se modificará su valor de “Versión 1.0” a “Versión 1.01”. Si la modificación es un cambio considerable del documento el valor aumentará de la siguiente manera.“Versión 1.0” a “Versión 1.1”. En cuanto a los valores enteros estos no cambian a no ser que el documento pase a sus siguiente fase es decir de su creación a una versión revisada y corregida. es decir: “Versión 1.0” refiriéndose al documento creado “Versión 2.0” hablando de el documento revisado y con correcciones,en este punto el valor decimal puede cambiar dependiendo del número de modificaciones. “Versión 3.0” validado. y así sucesivamente hasta llegar a su fase final. 4.4 Identificación de documentación Para facilitar la identificación del documento este contendrá su nombre en cada pie de página junto con su número de versión. además al final de cada documento contará con una tabla de versiones la cual marcará la fecha los autores y una breve descripción del cambio que se realizó en el documento. 4.5 Identificación de medios y ficheros Todos los directorios y ficheros deberán estar organizados de manera que su localización sea lo más rápida posible. Esto incluye tanto la organización en subdirectorios como el propio nombre del fichero, que deberá siempre ser descriptivo en cuanto a su contenido. Para la organización de la documentación, se usará Google Drive como repositorio temporal, que igualmente estará subdividido en directorios. Algunos ejemplos son: Plan de Proyecto/ Requisitos/ Riesgos/ Plan de Configuración/ Cuando hablemos de la implementación de la aplicación, algunos ejemplos a seguir son: bin/ img/ lib/ Archivos binarios Imágenes Librerías Si algún miembro del equipo no cumpliese esta configuración, y provocase problemas de localización de ficheros o nombres que den lugar a error, deberá comprometerse a su corrección informando antes del cambio de localización a todo el equipo. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 9 de 16 4.6 Proceso de liberación de productos software Para la liberación de los productos software, será necesario previamente la aceptación por parte del departamento de calidad. 4.7 Procesamiento de informes de incidencias, solicitudes de cambio y órdenes de cambio Cuando haya cualquier tipo de solicitud de cambio, en un principio deberá ser consultada al equipo de organización para contemplar si el cambio es viable. Esto se realizará rellenando el informe mostrado más abajo. Suponiendo que el equipo acepte dicho cambio, se mantendrá una reunión con el cliente para proponer el cambio informando de lo que esto supondrá en cuanto a una previsión de riesgos y del nuevo plan. Si el cliente está conforme con el cambio, se procederá a informar de nuevo al equipo, se asignará el personal necesario para dicho cambio, se documentará y por último, se informará al cliente del resultado. Informe de petición de cambio Solicitud de Cambio Proyecto: Fecha: Nombre peticionario: Producto: Datos del cambio Cambio propuesto Descripción Necesidad del cambio Beneficios que aportará Problemas que pueden surgir Estado de la petición Abierta Fecha modificación: SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 10 de 16 Desaprobada Fecha modificación: Aprobada Fecha modificación: Cerrada Fecha modificación: Firma 4.8 Estructura y forma de operación de los CCCs (Comité del Control de Cambios) SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 11 de 16 5. Actividades de GCS 5.1 Identificación El proceso de identificación ocurre justo después de la etapa de revisión del documento actual, al encontrar alguna parte del sistema que no funciona como se tenía planeado, o el resultado es correcto sin embargo no era lo que se solicitaba. Lo que prosigue, es informar al grupo de lo que se ha encontrado ya sea directamente en persona o enviar un mensaje al grupo de whatsapp previamente creado. Por otro lado si el cliente es el que se encuentra inconforme con alguno de los resultados del software el puede contactar directamente con el equipo con el correo que previamente se le ha otorgado. 5.2 Control de Versiones Para el control de versiones de los documentos de texto se utiliza el google drive y se optimiza con la tabla de versiones que se encuentra al final de cada documento, de esta manera pueden percatarse en qué momento el documento empezó a fallar y continuar desde una fase previa al fallo. En cuanto al software se puede utilizar un sistema de control de versiones como puede ser github que automatiza el control de cambios realizados al sistema, en donde claramente se pueden ver las distintas versiones de cada programa y en qué momento estos sufrieron un cambio que cause su malfuncionamiento, o bien genere un resultado distinto al esperado. 5.3 Control de cambios Usamos control de cambios con el código y diseño (interfaces) del programa, para ello usaremos GIT con distintas ramas respondiendo a eventos que surgen del mismo proyecto, sea por requerimientos propios del usuario o por mejoras o correcciones a realizar. Usaremos dos ramas, la principal que es donde se irá actualizando el proyecto con cosas nuevas y una rama secundaria que se actualizará con la rama principal cuando haya un cambio ya consensuado y aprobado. El cliente o la empresa deberá solicitar formalmente el cambio (por errores, solución de problemas o mala especificación del sistema) indicando la siguiente información en un documento: ● Solicitante con una breve descripción del cambio. ● Fecha de solicitud ● Nivel de urgencia del cambio ● Importancia del cambio ● Descripción del cambio Una vez enviado el reporte del cambio se procesa en la generación de informes (5.4) SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 12 de 16 5.4 Generación de informes Una vez enviado una solicitud de cambio, se priorizan los cambios a realizar: ­ Priorización de Atención El Jefe del Proyecto registrará la solicitud y evaluará el grado de importancia (si es importante para el proyecto, en el caso que no lo sea se tendrá en cuenta para posibles cambios a futuro), de acuerdo al proyecto y la disponibilidad de recursos, asignando una fecha para la evaluación de la solicitud. El documento contendrá la siguiente información: ● Número de solicitud ● Nivel de urgencia ● Nivel de importancia ● Fecha de evaluación ● Personal asignado Luego cuando se aborde el proyecto se analizará los costes e impacto. ­ Análisis de Impacto El Jefe del Proyecto deberá hacer una proyección sobre el impacto del cambio. Se hará la evaluación económica y evaluará el impacto en el cronograma general, determinando el costo del cambio según los recursos y tiempos especificados. El documento incluirá: ● Esfuerzos de implantación requeridos (tiempo y coste monetario) ● Horarios para implementar los cambios ● Fecha posible de inicio ● Fecha posible de término ● Alteraciones en el cronograma general del proyecto (si está en desarrollo) Por último la posible aprobación: ­ Aprobación El documento anterior deberá ser firmado y aceptado por la empresa y los posibles clientes (si es necesario). La aprobación deberá consignar: ● Fecha de Aprobación Funcional ● Nombre del aprobador funcional ● Firma del aprobador funcional ● Fecha de aprobación técnica ● Nombre del aprobador técnico ● Firma del aprobador técnico El Jefe del Proyecto procederá con el documento de propuesta de cambio, a modificar el cronograma detallado de la fase vigente y el cronograma general del proyecto. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 13 de 16 6. Control de suministradores y subcontratistas Al carecer este apartado de relevancia, no entraremos en detalle sobre su especificación. 7. Recogida y retención de registros 7.1. Documentación GCS a retener Durante el proceso de desarrollo del proyecto necesitaremos apoyarnos en distintos tipos de información de diversas fuentes que nos ayuden a conseguir los objetivos. 7.2. Métodos y recursos para la recopilación, salvaguarda y mantenimiento de la documentación Los documentos son hechos o rastros de “algo” que ha pasado, de ahí que como “testimonios” que proporcionan información, datos o cifras, constituyan un tipo de material útil para la investigación. Para recopilar tales documentos nos valemos de la técnica de recopilación documental cuya finalidad es obtener datos e información a partir de fuentes documentales. Ninguna guia de recopilación puede suministrar una orientación detallada del material a recopilar indicando qué documentos son importantes y cuáles no lo son, ello depende de las habilidades del investigador, de su experiencia y capacidad para descubrir los indicios que permitan ubicarlos. Por parte de todo el equipo de trabajo se decidió utilizar los servicios que Google proporciona para las labores de recopilación, salvaguarda y mantenimiento de la documentación. 7.3. Periodo de la retención Cada uno de los documentos serán retenidos para trabajar sobre ellos hasta que se consiga una versión final preparada para su entrega. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 14 de 16 8. Planificación de la GCS Una vez elegidos los ECS por parte de la gestión de la configuración y que, estos estén revisados y validados por el equipo de calidad, pasarán a formar parte de nuestra línea base que servirá como base para realizar el producto final. Una vez establecida la línea base, una vez cada dos semanas se realizará una auditoría donde se revisará la misma y los cambios que se hayan realizado aprobados por el Comité de control de cambios. En el caso en el que se hayan realizado cambios se comprobará su impacto, si es consistente con los requisitos del SRS y valorar si la línea base nueva sigue siendo aceptable para el desarrollo. La gestión de configuración debe asegurarse que no se provoquen duplicidades y evitar errores. Además del plan general anterior, también debe ocuparse de la gestión de versiones y variantes y de las relaciones entre los ECS y realizar informes de todos los cambio, creaciones de nuevos documentos, nuevos ECS, reuniones del Comité de Control de Cambios 9. Recursos de la GCS Dispondremos de distintas herramientas para afrontar las tareas de este proyecto. La siguiente tabla representa una clasificación de las mismas y nos ayudarán a la generación o mantenimiento y a la organización de los elementos de configuración. ID RECURSO NOMBRE PROPÓSITO UBICACIÓN 1 Servicios de Google Creación y gestión de documentos. (nube­online) 2 WhatsApp Comunicación entre los miembros del equipo de proyecto. (nube­online) 3 Microsoft Office Creación de documentos del proyecto. Directorio Local 10. Mantenimiento del plan de GCS Se intentará mantener este plan de configuración y avanzaremos con el. En caso de que sea necesario hacer alguna modificación en el, esta deberá ser aprobada en una reunión, intentando siempre que el plan original se mantenga en la medida de lo posible. SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 15 de 16 11. Historial de cambios Fecha Revisión Autor 30/04/2015 1 José Serrano Alvarez Contenido del punto 1 y estilos Contenido de los puntos 6, 7.2, 7.2 y 7.3 01/05/2015 2 Jhonny Vargas Paredes 02/05/2015 03/05/2015 3 4 Jhonny Vargas Paredes 03/05/2015 5 Jhonny Vargas Paredes 03/05/2015 6 Jose Luis Padilla 04/05/2015 7 Ismael Vallejo Ruiz 10/05/2015 10/05/2015 8 9 Ismael Vallejo Ruiz Jose Luis Padilla 10/05/2015 10 Javier Fernandez Villanueva 18/05/2015 23/05/2015 25/05/2015 26/05/2015 11 12 13 14 Jose Luis Padilla Jhonny Vargas Paredes Christian Álvarez Christian Álvarez Amy Rojas Morán Descripción Contenido del punto 9 Contenido del punto 3 Contenido de los puntos 8 y 10 Contenido parcial del punto 4 (4.1,4.2,4.3 y 4.4) Contenido parcial del punto 4 (4.5, 4.6, 4.7 y 4.8) Corrección del formato del documento contenido del punto 5.1 y 5.2 contenido del punto 5.3 y 5.4 Correcciones de rtf Correcciones de rtf Modificación punto 8 Validado SmartCar ­ Plan de Gestión de Configuración SC_GC ­ Versión 3.2 ­ Página 16 de 16
