Es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo de tal manera que sea posible recuperar versiones especificas más adelante.

1. LICENCIATURA EN
INGENIERIA EN SOFTWARE
Y REDES
TRAZABILIDAD Y CONFIGURACION
DE SOFTWARE

2. TEMARIO SEMANA 4.
7. Control de versiones
7.1. Importancia y funcionalidad
7.2. Divisiones y deltas
7.3. Políticas de control de versiones
7.4. Técnicas y herramientas
8. Planificación y gestión
8.1. Contabilidad y medición
8.2. Auditoría de la configuración del software
8.3. Gestión de entregas

3. CONTROL DE VERSIONES
• Es un sistema que registra los cambios realizados sobre un
archivo o conjunto de archivos a lo largo del tiempo de tal
manera que sea posible recuperar versiones especificas más
adelante.

4. 7.1 IMPORTANCIA Y FUNCIONALIDAD
• Acceso al registro de modificaciones sobre un fichero. Esto
nos permite además ver los comentarios asociados a cada
modificación y la persona que ha realizado dicha
modificación

5. • Posibilidad de regresar al estado anterior de un fichero o
conjunto de ficheros
• Creación de ramas para gestionar cambios que finalmente se
mezclarán con la rama principal
7.1 IMPORTANCIA Y FUNCIONALIDAD

6. • Facilidad para etiquetar modificaciones concretas. Esto
además, acaba desembocando en un DML de ITIL, con lo que
conseguimos un repositorio con todas las releases del
producto
7.1 IMPORTANCIA Y FUNCIONALIDAD

7. – Proporcionar mecanismos para evitar el caos ante cambios no
controlados.
– Proceso de Control de Cambios.
 Proceso por el cual se implementa el mecanismo de control de cambios.
7.2 DIVISIONES Y DELTAS

8. 7.2 DIVISIONES Y DELTAS

9. Versión delta: sólo se testean e instalan los elementos
modificados. Esta opción tiene como ventaja su mayor
simplicidad pero conlleva el peligro de que puedan aparecer
problemas e incompatibilidades en el entorno de producción.
7.2 DIVISIONES Y DELTAS

10. Versión completa: Se distribuyen
todos los elementos afectados ya
hayan sido modificados o no.
Aunque esta opción es obviamente
más trabajosa es más improbable
que se generen incidentes tras la
instalación si se han realizado las
pruebas pertinentes
7.2 DIVISIONES Y DELTAS

11. Paquete de Versiones: La Gestión de Cambios puede optar por
distribuir de forma sincronizada diferentes paquetes de
versiones, de esta forma se ofrece una mayor estabilidad al
entorno TI.
7.2 DIVISIONES Y DELTAS

12. Mantener la rama principal incorrupta. ¡La rama principal es tu
proyecto!
7.3 POLITICAS DE CONTROL DE VERSIONES

13. Aislar cambios en ramas.
Guarda cada cambio o característica nueva en su propia rama.
Ayudará a mantener la rama principal limpia, y te dará toda la
potencia del desarrollo paralelo real. También es muy bueno
para cambiar de tarea y hacer un seguimiento de los cambios
intermedios.
7.3 POLITICAS DE CONTROL DE VERSIONES
Nota: Asocia tu rama
con una con una tarea
en tu herramienta de
control de tareas para
poder tener el ciclo
completo.

14. Guarda los cambios con cierta frecuencia, con más de la que lo
haces ahora. Si desarrollas en la línea principal no harás commit
cada 5 minutos, los cambios suelen tardar más en realizarse. Si
tienes tu propia rama para la tarea puedes hacer commit tantas
veces como quieras (¡aunque no compile!)... y luego tendrás un
historial privado de los cambios.
7.3 POLITICAS DE CONTROL DE VERSIONES

15. Revisar los cambios antes de incluirlos en la línea principal. En el
desarrollo en la rama principal (y en integración continua) se
realizan las pruebas de tests después de que se hayan integrado
los cambios.
7.3 POLITICAS DE CONTROL DE VERSIONES

16. El repositorio
Es básicamente un árbol del sistema de archivos (directorio),
centralizado y controlado por una herramienta que gestiona los
permisos y conexiones para leer o escribir dichos archivos, y
guardar un registro histórico de las modificaciones que se les
realizan.
El procedimiento de modificación de un componente consiste,
de manera general, en adquirir una copia local del componente
para trabajar en ella. Luego el componente modificado se
establece como una nueva revisión en el repositorio.
7.4 TECNICAS Y HERRAMIENTAS

17. Mecanismos de control
Para permitir un acceso colaborativo al repositorio (para
modificación y lectura), las herramientas utilizan diferentes
estrategias, orientadas a evitar conflictos al compartir archivos.
Estos conflictos se generan cuando dos (o más) personas
trabajan en el mismo archivo, al terminar de modificarlo y
querer impactar sus cambios en el repositorio, corren el riesgo
de sobreescribir las modificaciones del otro.
7.4 TECNICAS Y HERRAMIENTAS

18. Modelo bloquear-modificar-desbloquear
En esta estrategia, el repositorio permite
que solamente un usuario modifique un
archivo, para ello primero debe
bloquearlo. Cuando otro usuario intente
bloquearlo, el sistema no lo permitirá y
deberá esperar a que el primero termine
y lo desbloquee. Este modelo ocasiona
ciertos problemas:
• Tiempos muertos: debido a que alguien
bloquea un archivo y olvida
desbloquearlo, mientras que otro usuario
necesita utilizarlo.
7.4 TECNICAS Y HERRAMIENTAS

19. Modelo bloquear-modificar-desbloquear
• Esperas injustificadas: en el caso de que un usuario deba modificar una
sección diferente de la que está modificando el usuario bloqueante.
• Falso sentido de seguridad: en el caso de dependencias entre los archivos,
se puede llegar a tener inconsistencias o deadlocks.
Estos problemas pueden ser manejados en grupos de desarrollo pequeños y
poco distribuidos, donde la comunicación por vías convencionales es factible.
7.4 TECNICAS Y HERRAMIENTAS

20. Modelo copiar-modificar-combinar
Este modelo permite que múltiples usuarios trabajen
simultáneamente en sendas copias locales del repositorio
(working copy). Al momento de actualizar el repositorio con los
cambios realizados, el sistema se encarga de comparar las
versiones y combinarlas (generalmente el usuario participa en la
toma de decisiones al respecto).
7.4 TECNICAS Y HERRAMIENTAS

21. Modelo copiar-modificar-combinar
La mayoría de los problemas del modelo anterior se resuelven
utilizando éste. Los conflictos en este modelo se dan cuando dos
(o más) usuarios modifican la misma porción de un archivo. La
resolución de este conflicto involucra comunicación entre los
desarrolladores
7.4 TECNICAS Y HERRAMIENTAS

22. Modelo copiar-modificar-combinar
El modelo copiar-modificar-combinar funciona correctamente
cuando se trata de archivos de líneas de texto (por ejemplo,
códigos fuente). Pero en el caso de archivos binarios (por
ejemplo, imágenes, sonidos, etc.) donde no se tiene una
representación legible del contenido, la mejor solución es utilizar
el modelo bloquear-modificar-desbloquear
7.4 TECNICAS Y HERRAMIENTAS

23. • Es crucial establecer un marco general para el lanzamiento
de nuevas versiones que fije una metodología de trabajo.
• La Gestión de Versiones es la encargada del diseño y
construcción de las nuevas versiones siguiendo las pautas
marcadas en las RFCs (Request For Change o Solicitud de
Cambio) correspondientes.
8. PLANIFICACION Y GESTION

24. • La planificación de costes en varios niveles se basa
directamente en el plan estructural y de gastos, de manera
que puede realizar cálculos previos con una base sólida.
Asimismo, la estructura general crea una base para
la comparación entre datos nominales y reales a medida
que avanza el proyecto.
8.1 CONTABILIDAD Y MEDICION

25. • Los costos se estiman para todos los recursos asignados al
proyecto, es decir, recursos de trabajo, recursos materiales,
coste de servicios e instalaciones y posibles costes por
contingencias.
8.1 CONTABILIDAD Y MEDICION

26. • La estimación de los costes de las actividades puede
necesitar de los resultados de los procesos de planificación
de otras áreas como por ejemplo el cronograma del
proyecto, el registro de riesgos y las asignaciones de
personal. Debido a ello las estimaciones no pueden darse por
definitivas hasta contar con tales informaciones.
8.1 CONTABILIDAD Y MEDICION

27. • Una auditoría es una
verificación independiente de
un trabajo o del resultado de
un trabajo o grupo de trabajos
para evaluar su conformidad
respecto de especificaciones,
estándares, acuerdos
contractuales u otros criterios.
8.2 AUDITORIA DE LA CONFIGURACION
DE SOFTWARE

28. • La auditoría de la Configuración es la forma de comprobar
que efectivamente el producto que se está construyendo es
lo que pretende ser.
8.2 AUDITORIA DE LA CONFIGURACION
DE SOFTWARE

29. • Es la actividad de GCS más costosa.
Requiere de personal experimentado, y
con un gran conocimiento del proceso de
desarrollo. Sin embargo, debe ser
realizada por personal ajeno al equipo de
desarrollo técnico para mantener la
objetividad de la auditoría.
8.2 AUDITORIA DE LA CONFIGURACION
DE SOFTWARE

30. Se pueden diferenciar tres tipos de actividades:
• Revisiones de fase: Se realizan al finalizar cada fase del
desarrollo y su objetivo es examinar los productos de dicha
fase. Las revisiones propias de la Gestión de configuración
son aquellas en las que se establecerán las líneas base. El
objetivo de esta revisión es descubrir problemas, no
comprobar que todo está bien. Hay que ser capaz de
desenmascarar los problemas ocultos y sutiles, no sólo los
que son obvios.
8.2 AUDITORIA DE LA CONFIGURACION
DE SOFTWARE

31. Se pueden diferenciar tres tipos de actividades:
• Revisiones de cambios: Se realizan para comprobar que los
cambios aprobados sobre una línea base se han realizado
correctamente.
• Auditorías: Se realizan al final del proceso de desarrollo de
software y su objetivo es examinar el producto en su
conjunto.
8.2 AUDITORIA DE LA CONFIGURACION
DE SOFTWARE