Plan de gestion de configuración de software

16,742 views

Published on

2 Comments
27 Likes
Statistics
Notes
No Downloads
Views
Total views
16,742
On SlideShare
0
From Embeds
0
Number of Embeds
208
Actions
Shares
0
Downloads
0
Comments
2
Likes
27
Embeds 0
No embeds

No notes for slide

Plan de gestion de configuración de software

  1. 1. CONTENIDOIntroducciónObjetivoAlcanceDefinicionesOrganizaciónRolesFlujo de trabajoProcedimientosResponsabilidadesPolíticas
  2. 2. INTRODUCCIÓN
  3. 3. INTRODUCCIÓNActividades de Gestión de configuración del software• Identificación de la configuración• Control de configuración• Informes de estado de la configuración• Revisiones y auditorias de configuración
  4. 4. OBJETIVOEl objetivo de la gestión de configuración esgarantizar que los cambios no se realicen de formainapropiada, debe existir una integridad en elproducto obtenido a lo largo del ciclo de vida delsoftware; todos los interesados en sudesarrollo, deben tener la versión correcta de laaplicación y su documentación
  5. 5. ALCANCEDentro del control de la gestión de configuración se encuentran:• El producto software en todos sus ambientes: desarrollo, pruebas, y producción• Documentos de ingeniería• Documentos de gestión del proyecto• Documentos de calidad de producto• Documentación de usuarioEn general toda fuente que es manejada dentro delproyecto.
  6. 6. DEFINICIONESComité de control de la configuración CCCConjunto de personas que revisan y aprueban los cambios sugeridos aun producto.Petición de cambioSolicitud formal que se presenta ante el CCC, la cual describe unproblema de software, una mejora solicitada o un cambio en losrequerimientos del software.Ítem de configuraciónSe entiende como elemento de configuración aquel producto detrabajo, cuyo cambio pueda resultar crítico para el desarrollo delproyecto. 1
  7. 7. DEFINICIONESLínea BaseConjunto de elementos de configuración formalmente aprobados quesirve como punto de partida para futuras versiones. Especificación oproducto que se ha revisado formalmente y sobre los que se ha llegadoa un acuerdo y de ahí en adelante sirve como base para un desarrolloposterior que puede cambiarse solamente a través de procedimientoformales de control de cambios. 1
  8. 8. DEFINICIONESControl de CambiosProceso responsable de controlar el ciclo de vida de todos los cambios.VersiónEstado de un conjunto de clases (y de otro tipo de archivos) que formanun sistema o componente. El conjunto de clases forman una versión enun momento dado. 2
  9. 9. DEFINICIONESVersión en desarrolloVersión de un sistema o componente que está sufriendo modificacionespor mejoras o correcciones por lo que aún no está disponible paraproducción.Versión en producciónEs una versión de un sistema o componente que se encuentradisponible para el uso de usuarios finales.TroncoEs un término equivalente a la versión estable oficial de desarrollo delsistema.RamaVersión de desarrollo paralela a la versión oficial (tronco) que se trabajahasta tenerla lista para salir a pruebas y posterior producción. Ambasversiones, la oficial y la rama comparten un ancestro común y están 3destinadas a converger en el futuro cercano.
  10. 10. ORGANIZACIÓNLa gestión de configuración de cambios se realiza a través del CCC CCC Nivel 1: conformado por el grupo de comité técnico CCC Nivel 3: CCC Nivel 2: conformado por el conformado grupo de comité por el grupo técnico y gerencia de comité general técnico y clientes
  11. 11. ORGANIZACIÓNEl Comité de Control de Configuración CCC es la autoridadpara:1. Evaluar todas las peticiones de cambio2. Aceptar o rechazar los cambios propuestos3. Toma las respectivas decisiones sobre los cambios a implementar, cualquier cambio en los requerimientos, o en el diseño, deben ser aprobados por CCC.
  12. 12. ROLES Y RESPONSABILIDADES Director del proyecto Líder de gestión de Líder de CCC configuraciónLíder de documentación Líder funcional Ingeniero de calidad
  13. 13. PROCEDIMIENTO GENERAL DE CONTROL DECAMBIOS
  14. 14. PROCEDIMIENTO CÓDIGO FUENTE Y DOCUMENTACIÓN DE USUARIO Del Líder funcional a líder de Solicitar la creación de la rama de configuración desarrollo SVN Ticket tipo requerimiento interno de infraestructura de gestión de configuración Crear la rama de desarrollo a partir del Líder de configuración tronco del cliente utilizando la nomenclatura Script BD y código fuente Crear paquete de clases, nota del reléase, manuales para entrega a calidad Nota del reléase. Matriz de afectación Crear ticket de pruebas adjuntando la información anterior Ingeniero de Entregar paquetes de clases, notas de calidad o reléase, Léame y documentación de usuario líder de para custodia configuracióIngeniero de Solicitar la creación de la rama de pruebas n calidad a de SVN Integrar la rama “paquete de clases al Líder de líder de tronco, nota de reléase, léame, script base configuracióconfiguración de datos n Crear la rama de pruebas a partir del tronco Líder de del clientegestión de la Líder de Integrar documentación de usuario a la ramaconfiguración configuració n Líder de Crear la rama de la documentación de Generar el archivo provisioning.zip Líder degestión de la usuario para el proyecto configuracióconfiguración n a director de proyecto
  15. 15. ROLES Y RESPONSABILIDADESLíder de Comité de Control de Configuración Dirigir las reuniones de CCC Definir ítems de configuración Asignar roles al equipo de trabajo Planear, informar y hacer seguimiento de los comités de control de cambios Documentar la decisión de las peticiones de cambio Establecer fechas de liberación y contenido de las versiones del producto software. Recibir, priorizar y asignar las solicitudes de cambio. Asignar al responsable de evaluar el impacto del cambio. Reportar el estado de los cambios. Realizar entrevistas con los usuarios funcionales en caso que se requieran aclarar dudas originadas en una solicitud de cambio
  16. 16. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de software Desarrollar y mantener el plan de gestión de la configuración. Reportar los cambios no autorizados sobre los ítems de configuración (IC). Identificar los IC y documentar sus características. Controlar los cambios a las características de un IC. Realizar auditorías para verificar el cumplimiento del Plan gestión de configuración. Aprobar cambios estructurales en la base de datos de configuración. Informar al CCC, el estado de aprobación de todos los cambios propuestos y el estado de ejecución de todos los cambios aprobados. Programar, junto con el líder del CCC, las reuniones así como la programación de la agenda para cada reunión. 1
  17. 17. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de software Responsable de la administración del sistema de gestión de configuración, lo cual incluye introducir la línea base, otorgar permisos y administrar los usuarios. Revisar el cronograma de proyecto para determinar hitos, que permitirán conocer fechas de creación de las líneas base y las actividades correspondientes de gestión de configuración. Documentar el estado de la línea base para cada IC Supervisar con qué frecuencia se realizan los cambios. 2
  18. 18. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de software Responsabilidades asociadas al manejo del código fuente: 1. Crear nueva rama en SVN cuando se inicia un proyecto:  Tomar el tronco actualizado, (no deberían haber cambios pendientes sobre el tronco, suponiendo que todo cambio se maneja en una rama)  Si es la primera vez que se toma el proyecto correspondiente al tronco, conectarse al repositorio, hacer checkout de este repositorio  Si ya se tiene el proceso correspondiente al tronco, hacer un update del proyecto 2. Marcar la versión actual del tronco con una etiqueta (con la etiqueta se logra tener una versión de referencia de cómo estaba el tronco antes de la extensión o modificación), la etiqueta debe seguir el estándar de nombramiento 3.2.1.4. 3. Abrir una rama a partir del tronco 4. Integrar la rama al tronco (responsable de modificar el tronco del proyecto, integrando cada rama probada al tronco). 3
  19. 19. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de software 5. Si las pruebas de regresión sobre la rama salieron exitosas, el líder de gestión de configuración realiza las siguientes acciones:  Selecciona el tronco como el proyecto a trabajar  Marca con una etiqueta el tronco (antes de integración)  Integra la rama al tronco, resolviendo posibles conflictos  Marca con una etiqueta el tronco (después de integración) 6. Con la etiqueta del tronco antes de integrar la rama se logra tener una versión de referencia de cómo estaba el tronco antes de la integración. Con la etiqueta del tronco después de integrar la rama se obtiene la nueva versión del tronco. NOTA: se necesita rol administrador para crear etiquetas 7. Debe generar el provisioning.zip cuando el director de proyecto solicite la versión oficial aprobada del producto software para entrega al cliente. Debe entregar dicho archivo al director de proyecto con su documentación de usuario respectiva. 4
  20. 20. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de softwareResponsabilidades asociadas al manejo del código fuente enpruebas: Crear nueva rama en SVN cuando se inicia un proyecto Tomar el tronco actualizado, (no deberían haber cambios pendientes sobre el tronco, suponiendo que todo cambio se maneja en una rama) Si es la primera vez que se toma el proyecto correspondiente al tronco, conectarse al repositorio, hacer checkout de este repositorio Si ya se tiene el proceso correspondiente al tronco, hacer un update del proyecto Marcar la versión actual del tronco con una etiqueta (con la etiqueta se logra tener una versión de referencia de cómo estaba el tronco antes de la ejecución del proceso de pruebas. 5
  21. 21. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de softwareResponsabilidades asociadas al manejo de documentación deusuario: Crear nueva rama en SVN para documentación de usuario cuando se inicia un proyecto Tomar el tronco actualizado, (no deberían haber cambios pendientes sobre el tronco, suponiendo que todo cambio se maneja en una rama) Si es la primera vez que se toma el proyecto correspondiente al tronco, conectarse al repositorio, hacer checkout de este repositorio Si ya se tiene el proceso correspondiente al tronco, hacer un update del proyecto Marcar la versión actual del tronco con una etiqueta (con la etiqueta se logra tener una versión de referencia de cómo estaba el tronco antes de la ejecución del proceso de pruebas. 6
  22. 22. ROLES Y RESPONSABILIDADESLíder de gestión de configuración de software Integrar la rama “paquetes de clases” al tronco del cliente cuando el área de calidad de software lo solicita. Generar el archivo provisioning.zip cuando es solicitado por el director de proyecto para entrega al cliente 7
  23. 23. ROLES Y RESPONSABILIDADESLíder funcionalA nivel de código fuente:Para trabajar el requerimiento en la rama: Mientras se construye en la rama, la extensión o modificación del proyecto, no se afecta el tronco pero sí se tienen en cuenta los cambios que va teniendo el tronco. Al incorporar los cambios del tronco hacia la rama pueden surgir conflictos sobre la rama, los cuales deben resolverse. Cuando son varios desarrolladores en la misma rama, eventualmente deben resolver conflictos entre ellos cuando hacen commit en la rama (después de resolver conflictos utilizar los comandos commit y update). Se debe tener cuidado de incorporar cambios del tronco hacia la rama y no al revés, colocando un rango de versiones referentes al tronco (solo indicado por el líder de gestión de configuración de software) 1
  24. 24. ROLES Y RESPONSABILIDADESLíder funcionalA nivel de código fuente: Tomar el tronco actualizado, (No se debe hacer una rama cuando hay cambios pendientes sobre el tronco. Si es el caso, se debe hacer commit sobre el tronco para aplicar los cambios y luego update) o Si es la primera vez que se toma el proyecto correspondiente al tronco, conectarse al repositorio, hacer checkout de este repositorio o Si ya se tiene el proceso correspondiente al tronco, hacer un update del proyecto Seleccionar la rama a trabajar (antes de hacer los cambios asociados al requerimiento se debe seleccionar como proyecto, el asociado a la rama). Trabajar en la rama: A medida que se trabaja en la rama para realizar la extensión o modificación requerida, el líder funcional debe hacer periódicamente las siguientes acciones: o Incorporar los últimos cambios del tronco hacia la rama. o Modificaciones y pruebas de la rama. 2
  25. 25. ROLES Y RESPONSABILIDADESIngeniero de calidadHacer pruebas sobre una rama: Recibe el paquete de clases de los lideres funcionales y las agrega a la rama de pruebas del proyecto. Trabaja en su rama para hacer las pruebas. Idealmente se ejecuta el conjunto de casos de pruebas de regresión (sobre la rama) que garanticen la compatibilidad hacia atrás. Debe evaluar el contenido de la matriz de afectación recibida en la nota del release. Fin del trabajo en la rama: cuando la extensión o modificación, (código fuente probado y aprobado) está lista en la rama de pruebas, el ingeniero de pruebas solicita al líder de gestión de configuración (administrador del repositorio, pues, es el responsable de modificar el tronco del proyecto) la incorporación de la rama al tronco, es decir, el paquete de clases.
  26. 26. ROLES Y RESPONSABILIDADESLíder de documentación Generar el manual de usuario a partir el entrenamiento dado por los lideres funcionales en primer ciclo de pruebas Revisar los manuales de instalación, técnico y de configuración con respecto al formato aprobado Debe mantener en la rama de documentación de usuario del proyecto en SVN, todos los manuales marcando la versión con un tag Debe mantener las versiones aprobadas de los manuales, pues deben ser publicados en el administrador de contenido del curso correspondiente Debe solicitar la información necesaria al equipo de desarrollo para generar la documentación de capacitación en línea
  27. 27. HERRAMIENTASPara gestionar las líneas base se utilizan las siguientes herramientas:SVN, es una herramienta de gestión de versiones que se utiliza para almacenar las versiones del software y su documentaciónGoogle docs, para almacenar la documentación de gestión de proyecto, de ingeniería, calidad de software y documentación de usuario.Moodle, para administrar el contenido de documentación de usuario del producto software por cliente.
  28. 28. POLÍTICASPolítica de Configuración de código fuente y documentación de usuario• Para la configuración de nuevas versiones del código fuente la política es la siguiente:• El código fuente será almacenado en el SVN• Después de un cambio en base de datos se debe verificar la actualización de su script. Es necesario indicar cuáles son las sentencias alter que afectan la base de datos. Estos alter deben especificarse en el manual técnico• El release para pruebas debe incluir manual de configuración, manual de instalación y manual técnico. Los cambios a estos manuales deben ser realizados por el grupo de desarrollo y manejados por el líder de documentación, quien conserva la versión aprobada para el release.
  29. 29. POLÍTICASPolítica de Configuración de código fuente y documentación de usuario• Trabajar el tronco o la rama como un todo: • El checkout inicial del proyecto debe tomar todo el tronco del cliente. • Toda rama representa una copia de todo el tronco. • Para cambios hechos en una rama de desarrollo debe hacerse un commit de archivos individuales. • La integración debe llevar los cambios ocurridos en todo el tronco hacia una rama o integrar los paquetes de las clases (de una rama) hacia el tronco. Después de estas integraciones debe hacerse commit de toda la rama o de todo el tronco, según el caso.• Registrar buenos comentarios con los comandos subversion• Durante el desarrollo de una rama se recomienda hacer commits frecuentes para hacer visibles los cambios a los otros desarrolladores de la rama. El comentario de un commit debe indicar la naturaleza de cada cambio que se está registrando.
  30. 30. POLÍTICASPolítica de Configuración de código fuente y documentación de usuario• Minimizar los conflictos en la integración de las ramas al tronco: • Después de cada integración de los paquetes de clases (de una rama) al tronco, el líder de configuración debe avisar para que todos los desarrolladores actualicen sus ramas activas integrando el tronco hacia cada rama. De esta manera las ramas se mantienen actualizadas respecto al tronco y se reduce la probabilidad de que ocurran conflictos en la integración de las clases de una próxima rama al tronco. • Para cada integración de las clases de una rama al tronco, el líder de gestión de configuración debe obtener el log de integración y agregarle cómo se resolvieron los conflictos, si los hubo. Posteriormente, envía este log al responsable de la rama integrada (lideres funcionales) para que confirme si fue correcta la resolución de conflictos. • Otra práctica adicional para minimizar conflictos es que el líder de configuración no integre varias ramas (paquetes de clases) al tronco en forma consecutiva sino que permita después de cada integración que los desarrolladores actualicen sus ramas activas, antes de proceder a una siguiente integración de otra rama (paquetes de clases) al tronco.
  31. 31. POLÍTICASPolíticas de repositorio• Los documentos en su versión para inspección y revisión continua se mantienen en la colección del proyecto en el sistema de gestión de documentos.• Los documentos relacionados a calidad de software que han sido revisados y aprobados por el área de calidad de software deben ser almacenados en la carpeta respectiva al cliente en el sistema de gestión de documentos en formato pdf. El área de calidad de software es quien tiene los documentos en su formato de edición, ya que cualquier cambio en éstos deben ser manejados a través del área.• Los documentos relacionados al área de ingeniería y de gestión de proyecto estarán almacenados en las carpetas respectivas de proyecto en el sistema de gestión de documentos, aquellos documentos que necesiten ser protegidos por la criticidad de la información serán manejados por el director de proyecto, quien decide cuáles documentos pueden o no ser editables.• Se debe tener una rama en SVN por cada cliente, con el fin de conservar la copia de seguridad de documentación, configuración y código fuente de cada cliente.• En el sistema de gestión de documentos deben ir los documentos de ingeniería relacionados a planes, diseños y reportes de pruebas.
  32. 32. POLÍTICASPolíticas de manejo de línea base• Los defectos deben ser corregidos en ambiente de desarrollo. Debe actualizarse en paralelo la documentación de usuario (manuales).• El release autorizado es el tronco del cliente.• El release definitivo para liberar a producción debe ser solicitado por el director del proyecto al líder de gestión de configuración.

×