Gestión de Configuración

de Software
 El Proceso de Gestión de
Configuración de Software.

• La Gestión de Configuración de Software

(SCM) es una disciplina de la Ingeniería de
Software que se preocupa de:

• Identificar y documentar las características

funcionales y físicas de los elementos de
configuración del Software.
• Controlar los cambios a tales características.
• Reportar el proceso de tales cambios y su estado de
implantación.
 SCM (Diferencias con
Mantenimiento de Software)

• SCM difiere del mantenimiento, debido a que este

último es un conjunto de actividades de
Ingeniería de Software que se produce una vez
que el producto ha sido distribuido a los clientes
y está en operación.

• SCM, en cambio, es un conjunto de actividades de

seguimiento y control que comienzan al inicio de
un proyecto de desarrollo de software y termina
sólo una vez que el producto queda fuera de uso.
 Manejo de SCM en las
organizaciones

• ¿Cómo identifica y gestiona una organización las

muchas versiones existentes de un programa (y su
documentación), de forma que se puedan introducir
cambios eficientemente?
• ¿Cómo controla la organización los cambios antes y
después de que el software sea distribuido al cliente?
• ¿Quién tiene la responsabilidad de aprobar y de
asignar prioridades a los cambios?
• ¿Qué mecanismo se usa para avisar a otros de los
cambios realizados?
• ¿Cómo podemos garantizar que los cambios se han
llevado a cabo adecuadamente?
SCM: Divisiones en la Gestión
 Proceso General para SCM

• Determinar el estado y necesidades de SCM.

• Examinar el estado del arte en las herramientas de
SCM.
• Evaluar herramientas candidatas de SCM.
• Escribir el plan de adopción.
• Implantar un proyecto piloto.
• Institucionalizar el sistema de SCM.
• Retroalimentar el sistema de SCM.
 SCM y el resto de Procesos de
Desarrollo

• SCM no es una actividad aislada del resto de los

procesos partícipes en el desarrollo. Muy por el
contrario, SCM puede ser visualizado como un
comunicador al interior de cada proyecto.

• SCM cumple el rol de comunicador porque:

• Mantiene una estrecha relación de trabajo con todas las
entidades del proyecto.
• Informa a cada desarrollador sobre el estado del producto y su
evolución.
• Recopila y gestiona la documentación definida y aprobada para
el producto, poniéndola a disposición de quien la requiera.
 ¿Por qué hacer uso de SCM?
• SCM como una herramienta de control permite:
• El mantenimiento de la integridad de los elementos, en una atmósfera
de cambio continuo.
• La evaluación y ejecución de los cambios, en un ambiente controlado.
• SCM como una herramienta de visibilidad permite:
• Que el estado de la configuración proporcione evidencia objetiva y
concreta de la creación y evolución del producto.
• Que las inspecciones y auditorías de la configuración establezcan el
estado de avance real del proyecto.
• SCM como una herramienta de reducción de costos permite:
• La reducción de los costos de desarrollo, ayudando a mantener el
“orden” en el proyecto.
• La reducción de los costos de mantenimiento, asegurando la integridad
del software en la operación, actualización y consistencia de toda la
documentación.
 ¿Por qué hacer uso de SCM?

• SCM como una herramienta de apoyo a la

administración del proyecto permite:
• Como función de servicio, incrementar la eficiencia y la
efectividad de la administración.
• Que la efectividad de sus disciplinas se incremente
proporcionalmente, en la medida que son parte explícita del día
a día.
 Implicaciones del Uso de SCM

• Requiere un esfuerzo de capacitación inicial de los

involucrados.
• Requiere recursos (personal y equipamiento) no
considerados previamente.
• Generalmente, al principio, produce una “pseudo
burocratización” que desaparece luego, una vez que los
procedimientos se optimizan y se adquiere la cultura del
control.
 Proceso de Madurez de SCM

• El modelo se compone de cuatro niveles de madurez.

Estos niveles permiten describir los diferentes
escenarios de madurez en que se desenvuelven las
organizaciones que desarrollan o mantienen software.
• Los cuatro niveles son:
• Inmaduro
• Básico
• Definido
• Controlado
• Nivel 1: Inmaduro
• No existe un compromiso de la alta organización por aplicar los
conceptos y prácticas de SCM.
• Principalmente se realizan actividades básicas de
mantenimiento de software.
 Proceso de Madurez de SCM

• Por qué pasar de Inmaduro a control Básico:

• Problemas relacionados con el cumplimiento de plazos.
• Ningún especialista tiene entrenamiento en SCM.
• Las tareas de configuración son dejadas como extras.
• No existe un control de cambios.
• Prácticas asociadas:
• Realización de procedimientos básicos de mantenimiento.
• Reconocimiento de la necesidades de aplicar SCM.

• Nivel 2: Básico
• Se logra el control inmediato de los aspectos más críticos de un
proyecto de desarrollo de software y se construye un
fundamento para un posterior plan de SCM.
 Proceso de Madurez de SCM

• Se da especial énfasis al control del código.

• Prácticas:
• Existencia de un control de versiones del código (fuente, objeto y
ejecutable). Documentación de cada versión.
• Existencia de un control formal de cambios. Apoyado en uso de
formularios y un proceso estricto de revisión y aprobación del
código.
• Existencia de un comité de control de configuración del
proyecto. Debe hacerse responsable de todos los cambios en la
configuración.
• Existencia de una política para implementar actividades de
SCM. Política organizacional escrita y el respectivo mecanismo
para la adherencia a la política.
 Proceso de Madurez de SCM

• Nivel 3: Definido
• En este nivel se establece un plan y un proceso definido de
SCM. Existe un grupo responsable por las actividades de los
procesos de SCM.
• Prácticas:
• Existencia de un proceso definido para implementar las actividades
de los procesos de SCM.
• Existencia de un plan de SCM.
• Existencia de un grupo de SCM.
• Desarrollo, mantenimiento y distribución de planes de SCM,
estándares y procedimientos.
• Herramientas para soportar las actividades de SCM están
disponibles.
• Entrenamiento al grupo de Ingeniería en el uso de las herramientas.
 Proceso de Madurez de SCM

• Nivel 4: Controlado
• Establece metas cuantitativas de actividades de SCM.
• Fundamento para la evaluación de los componentes de SCM.
• Número de requerimientos de cambio procesados.
• Completación de actividades SCM según plan.
• Relación esfuerzo desplegado, fondos gastados y trabajo
completado.
• Se establece una base de datos para el proceso SCM.
• Prácticas:
• Definición y análisis de mediciones sobre SCM. Calidad,
productividad, riesgo y complejidad de las actividades.
• Verificación de la implementación. Análisis de los criterios de
éxito.
• Evaluación de las actividades de SCM. Verificación de su utilidad,
según la percepción personal y de grupo.
 Repositorios SCM

• El tener el historial de cambios realizados sobre un

repositorio nos va a deparar numerosos beneficios
(aparte de poder saber a quien culpar cuando alguien
comete un error). Nos va a permitir, en primera
instancia, ser capaces de revisar y deshacer las cosas
que nosotros mismos hicimos, aprender de lo que otros
hicieron, nos va a facilitar encontrar errores porque
vamos a poder ver en que punto se rompió algo, realizar
numerosas pruebas, etc.
 Repositorios SCM

• Generalmente hay 2 tipos de repositorios SCM

centralizados, los que usan el modelo Lock-Modify-
Unlock y los que usan el modelo Copy-Modify-Merge.
• El primero es el más simple y limitado, y consiste en que cada
vez que un usuario quiere modificar un archivo, este archivo se
bloquea y no puede ser modificado por nadie más hasta que este
usuario termine de editarlo. Este modelo, además de ser muy
limitado e incómodo, rompe bastante el concepto de changeset,
ya que los cambios están centrados en archivos y en cambios al
repositorio como un todo.
• El segundo modelo propone lo siguiente: se hace una copia del
estado actual del repositorio (sería nuestra Working Copy), se
modifica y se aplica el changeset al repositorio central haciendo
un merge.
Lineas Base

• Fundamental para la gestión de configuración

• Base oficial para el trabajo subsiguiente
• cambios controlados (para no poner en riesgo
trabajos en curso)
• Luego de que se establece una línea base
• cada cambio se registra como delta hasta que se
establezca otra línea base
• ¿Cuándo establecerla?
• muy pronto puede burocratizar innecesariamente el
desarrollo
• mientras los programadores pueden trabajar solos con
poca interacción, no es necesario
• tan pronto como comienza la integración, es esencial
• vital durante mantenimiento
 Alcance de la Línea Base

Para el control de código

• nivel actual de cada módulo (fuente y objeto)
• nivel actual de cada caso de prueba (fuente y objeto)
• nivel actual de cada herramienta usada
• nivel actual de cada prueba especial o datos
operacionales
• nivel actual de software auxiliar (bibliotecas, archivos)
• nivel actual de procedimientos de instalación u
operación
• si hay cambios en la plataforma, nivel de esta

• En sistemas grandes y complejos, registrar un cambio

considerando que:
• “¡a menos que sepa que no es importante, lo es!” (Humphrey)
 Control de la Línea Base

• Balancear:
• control apropiado
• servicio flexible a los programadores
• Flexibilidad a través de:
• copias de trabajo a los programadores
• pueden experimentar soluciones, variantes
• Control:
• no pueden incorporar esos cambios sin prueba de regresión de
lo que ya existe
• cada cambio propuesto se debe probar contra una versión de
prueba de la nueva línea base garantizar que no invalidan a
los otros
• Solución:
• bloqueo y
• test de regresión
Registros de Gest. Configuración

• Procedimientos
• cada propuesta de cambio documentada y
autorizada antes de hacerse
• al realizarse los cambios se registra lo hecho
• una Orden de Cambio puede involucrar múltiples ítems de
configuración (fuentes, objetos, documentación)
• identificar las pruebas realizadas, para que se puedan
repetir
• cada programador que trabaja en cambios para
nueva versión de línea base debe mantener:
• lista actual de todas las funciones, características, arreglos
e interfaces de sus programas a ser integrados
• necesario para informar a otros afectados, en particular
test, documentación e integración
 Responsabilidades Gestión Configuración

• Dependiendo del tamaño del proyecto y del

equipo, pueden ser manejadas por una única
persona, o varias:
• gerente de configuración
• propietario de módulo
• Comité de Control de Cambios (Change Control
Board)
 Gerente de Configuración

• Responsabilidades:
• desarrolla, documenta y distribuye procedimientos de Gestión
de Configuración
• Establece la línea base del sistema, incluyendo provisiones
para respaldo
• Asegurar que
• no se realizan cambios no autorizados a la línea base
• todos los cambios a la línea base se registran con detalle
suficiente como para reproducirlos o volverlos atrás
• todos los cambios a la línea base pasaron test de regresión
• Proporcionar información para resolución de problemas
• Permite responder a preguntas:
• qué código es este, qué cambió, qué pruebas se corrieron,
cuáles fueron los resultados de las pruebas, dónde está el
código
• “esta responsabilidad debe recaer en alguien, inclusive
para proyectos de dos personas”
 Propietario de módulo

• Responsabilidades:
• conocer y entender el diseño del módulo
• asistir a quien trabaja con o tiene interfaces con el
módulo
• experto de referencia para toda modificación del
módulo, incluyendo mejora y reparación
• asegurar la integridad del módulo revisando todos
los cambios y llevando a cabo pruebas de regresión
• Problemas:
• Depende de las habilidades y disponibilidad de las
personas
• se puede establecer un sistema de respaldos
• Proporciona control del diseño a nivel de detalle
 Comité de Control de Cambios

Responsabilidades:
• revisar cada solicitud de cambio para
aprobarla/rechazarla/diferirla
• disponer condiciones de liberación del cambio
• pruebas y revisiones especiales

• Tiene poder de bloquear el proyecto

• gerente de proyecto de software debiera formar
parte de él
 Comité de Control de Cambios

Necesidades de información:
• estimación del tamaño del cambio
• alternativas – consideradas, criterio para elección-
• complejidad – uno o múltiples componentes-
• calendario –fechas requeridas/planificadas-
• impacto –consecuencias futuras del cambio-
• costo – costos y ahorros potenciales –
• severidad – cuán crítico es el cambio
• relación con otros cambios –sustituye a otros o depende de
otros
• test – requerimientos especiales –
• Recursos – personas necesarias disponibles?
• Impacto en el sistema – recursos de Hw –
• Beneficios
• Cuestiones políticas – quien pidió, a quienes afecta
• Madurez del cambio – hace cuánto tiempo se evalúa -
•
 Comité de Control de Cambios

Necesidades de información (Cont):

Para problemas informados por cliente
• definición del problema que se pretende corregir
• condiciones bajo las cuales el problema fue observado
• el reporte de problema
• descripción técnica del problema
• nombre de otros componentes afectados
Información adicional previa a liberación:
• fuente y/o objeto final
• cambios finales a la documentación
• evidencia de inspecciones y pruebas al código y la
documentación
DEVOPS
DEVOPS
DEVOPS
 Plan de gestión de configuración

• Visión general
• objetivos de la GCS (gestión de configuración del software)
• visión general del sistema
• Organización de la GCS
• responsabilidades
• Comité de Control de Cambios – miembros y
responsabilidades
• Relación con QA
• Métodos de GCS
• Líneas base y contenidos
• Sistema de identificación
• Sistema de control
• Auditoría
• Evaluación del estado
• Herramientas de soporte
 Plan de gestión de configuración

• Procedimientos
• Manual de procedimientos
• Formularios y registros
• Implementación
• Plan de personal
• Plan de soporte
• Recursos
• Puntos clave de la implementación
 Cuestiones en el ciclo de vida
• Requerimientos
• Dónde está la versión oficial de los requerimientos
• Qué cambios se hicieron
• Fueron aprobados?
• Cuántos cambios hubo y qué impacto tuvieron sobre diseño y
desarrollo
• Cuántos cambios se hicieron sin cambiar el alcance del
contrato
• Diseño
• Dónde está satisfecho en el diseño este requerimiento
particular
• Cuál es el requerimiento particular que este diseño satisface
• cuál es la versión actual aprobada para esta interfaz
• El formato de este ítem de datos fue especificado dónde, por
quién, y quién lo usa
• cuál es el impacto de diseño de este cambio en los
requerimientos
 Cuestiones en el ciclo de vida

• Implementación
• cuál es la lógica de diseño para ese elemento de código
particular
• cómo se afecta el diseño por este cambio en el código
• cuál es el impacto en la implementación de este cambio en los
requerimientos
• qué versión del compilador se usó para generar este código
• Pruebas
• Dónde están las pruebas para verificar este requerimiento
• dónde están los datos de prueba para estos tests
• dónde está la documentación que explica los resultados
esperados de estas pruebas
• este conjunto de pruebas fue actualizado para contemplar los
cambios de la nueva versión
 Auditorías

• Llevada a cabo:
• por alguien independiente y calificado
• de forma periódica para asegurar la integridad de
las líneas base
• cambios a la línea base se implementaron de la
forma prevista
• un plan documentado de GCS es la base para la
auditoría
 Problema

• Sistemas:
• ERP: sistema hecho en casa, web, sobre sistema
operativo linux, con un motor de base de datos
Oracle.
• CRM: sistema hecho en casa, cliente/servidor, sobre
sop windows, base de datos SQL Server.
• HCM: sistema hecho en casa, web, sop linux, base
de datos MySql.
• Planeación y presupuesto, hojas de excel, en file
server, sop windows.
La integración continua es un proceso que permite comprobar
continuamente que todos los cambios que lleva cada uno de los
desarrolladores no producen problemas de integración con el
código del resto del equipo.

Los entornos de integración continua construyen el software

desde el repositorio de fuentes y lo despliegan en un entorno de
integración sobre el que realizar pruebas unitarias o de
aceptación.

Implantar procesos de este tipo conlleva una inversión en tiempo que

será recuperada conforme avance el proyecto. No obstante, esta
inversión es cada vez más reducida gracias a la disponibilidad de
herramientas Open Source que nos ofrecen soluciones de Integración
Continua cada vez más sencillas de implantar.
La integración continua es también un buen ejemplo de una
regla básica de un programador pragmático: “Intentar
automatizar todo el trabajo repetitivo que realiza”.

Integración continua consiste en disponer de un

proceso automatizado que permita la
construcción de nuestro software desde las
fuentes, que despliegue nuestro software en un
entorno similar al entorno final y que lleve a
cabo el conjunto de pruebas que validan su
correcto funcionamiento.
 El concepto que hay detrás de integración
continua (Continuous Integration o CI) es que se
debe integrar el desarrollo de una forma
incremental y continua. Esto permite encontrar
problemas de integración y resolver este tipo de
problemas durante el desarrollo.
 Para conseguir automatizar este proceso de
construcción, pruebas y despliegue de manera que se
realice diariamente muchas veces es necesario también:

• Almacenar las fuentes en un único lugar del que pueda

obtenerse la última versión del proyecto (y versiones
anteriores).
• Automatizar el proceso de construcción de manera que
se pueda, con un único comando, construir todo el
sistema a partir de las fuentes.
• Automatizar las pruebas de forma que sea posible y de
forma automática, saber si todo está bien o hay algún
problema.
Estos beneficios son los siguientes:

• Minimiza las sesiones de búsqueda de fallos a la hora de

integrar el código. Fallos realmente complicados de encontrar
dado que suelen ser efectos colaterales de código que ha sido
desarrollado de manera independiente.
• Permite identificar fallos en el entorno de producción en etapas
tempranas. Esto permite ser eficiente en los pasos a producción y
evitar los periodos de integración finales en los entornos de
producción.
• Minimización del tiempo de realimentación con el cliente, al
minimizar el paso de desarrollo a un entorno de integración.
• Eficiencia del equipo de desarrollo: no es necesario todo el
conjunto de pruebas en el entorno local, minimiza el tiempo de
paso a producción.
• Aumenta la confianza en el cdigo subido al control de versiones.
Desarrollar un conjunto de pruebas completas de nuestro sistema es una tarea cuya
complejidad dependerá del entorno de ejecución de nuestra aplicación y de las
interacciones con sistemas externos. Un conjunto de pruebas completas de nuestro
sistema implicaría tener diferentes conjuntos de pruebas:

• Pruebas Unitarias
• Pruebas de Rendimiento
• Pruebas de Integración con sistemas externos
• Pruebas de Diseño (Accesibilidad)
• Pruebas Funcionales

En el modelo tradicional de desarrollo este tipo de pruebas se realizaban una vez

finalizado el desarrollo. No obstante este enfoque no suele funcionar en la mayoría
de los proyectos de desarrollo y es realmente poco efectivo.

Desarrollar pruebas automáticas nos permite comprobar en cualquier momento y

ejecutando la ‘suite’ de pruebas si nuestro sistema cumple con la funcionalidad
implementada hasta el momento. Esta facilidad es tremendamente útil durante el
desarrollo, puesto que nos permitirá desarrollar cambios con seguridad, sin tener
que pagar el esfuerzo de volver a probar todo. Dejar las pruebas para el final del
desarrollo nos privará de esta ventaja.
Una vez llegados a este punto nos encontramos en situación de poder comenzar
a pensar en automatizar todas las tareas que realizamos, para conseguir
construir nuestro sistema a partir del código que hemos desarrollado y lograr
que sea desplegado y este disponible para poder ser utilizado.

Una de las claves de la eficiencia en el desarrollo es el nivel de automatización

que hemos conseguido implantar en todas las tareas relacionadas con el
desarrollo.

Pero aún siendo la mejora de la eficiencia una excelente razón para decidir
comenzar a automatizar los procesos de nuestro desarrollo hay otra razón que
muchas veces queda oculta y que es en mi opinión mucho más importante: la
capacidad de poder repetir los procesos de una manera exacta. El desarrollo de
software es una disciplina con un alto grado de incertidumbre. Al gran número
de variables que afectan a un desarrollo (Sistemas Operativos, Base de Datos,
Integración con sistemas externos, Servidores de aplicaciones) en muchas
ocasiones añadimos nosotros todavía más incertidumbre al introducir procesos
manuales al proceso de construcción del software.
La integración continua impone un desarrollo en equipo más
disciplinado. En muchos proyectos no se es consciente de que se
trabaja en equipo hasta que llega el momento de la integración
final.

La integración continua hace que nuestro desarrollo sea

incremental. En cada momento nuestro sistema ofrecerá una
serie de funcionalidades que serán las que prueben nuestro
conjunto de pruebas automáticas. Los nuevos desarrollos
añadirán nuevas funcionalidades evitando que las anteriores
dejen de funcionar. Cuando el conjunto de funcionalidades de
nuestro sistema ofrezca la posibilidad de tener un software
coherente con nuevas posibilidades, entonces en ese caso
deberemos crear una nueva versión.
Para que este desarrollo incremental funcione correctamente la
experiencia nos dice que es necesario seguir las siguientes
prácticas:

• Desarrollar pruebas a medida que se desarrollan funcionalidades: Cada nueva

funcionalidad que se integre en el control de Versiones deberá tener su conjunto de pruebas.
Cuando se modifique alguna funcionalidad también será necesario modificar su conjunto de
pruebas. Utilizar desarrollo dirigido por pruebas TDD facilita esta tarea.
• Política de Semáforos: Una vez que utilicemos integración continua el sistema nos
informara del estado del software De esta manera recibiremos continuamente notificaciones
cuando el código que tengamos en nuestro repositorio de versiones no pase las pruebas. En
ese caso tendremos el semáforo en rojo para subir nuevo código al CVS. Esto nos permitirá
no introducir nuevas clases antes de identificar cuales han sido las clases responsables de este
problema. Si el control de versiones nos ha enviado un mail avisándonos del éxito de
nuestras pruebas, entonces en ese momento el semáforo estará verde para subir nuevo código.
• Tiempo máximo de solución de errores en el control de Versiones: En la medida de lo
posible tenemos que minimizar el tiempo en que el desarrollo que hay en el control de
versiones no pasa las pruebas. En aquellos casos en los que sea difícil arreglar un problema
que hemos detectado una vez subido el código al control de versiones la mejor opción es
volver al código de la versión anterior.
Minimizar el tiempo entre integraciones: Uno de los objetivos principales de la
integración continua es realizar continuamente integraciones, cuanto mas a
menudo se realicen mejor funcionara el proceso. Por este motivo hay que intentar
que este tiempo sea el mínimo posible. Por este motivo tenemos que conseguir
mantener nuestro proceso automático lo mas rápido posible, tratando de reducir el
tiempo que consumen las pruebas y el tiempo que consume el despliegue.

Coordinar aquellos cambios o reestructuraciones que influyan en gran parte del

código: La integración continua implica un elevado grado de coordinación. Estas
coordinaciones son especialmente importantes en aquellas modificaciones que
vayan a afectar a muchos módulos. En estos casos muchas veces es más eficiente
hacer este tipo de cambios desde situaciones estables, para intentar evitar efectos
colaterales. Es posible que estos cambios sean realizados por cada programador en
los módulos en los que esta trabajando.

Responsable del entorno de integración continua: Nuestra experiencia aplicando

Integración Continua es que es muy conveniente tener un responsable encargado
de que este entorno funcione correctamente y de que el equipo esta siguiendo las
reglas anteriores. Esta persona será la responsable de arreglar aquellos errores que
surgen sin que se haya realizado ningún cambio por el entorno en el que se
ejecutan los test.
La integración continua minimizará el
tiempo de puesta en producción acortando el
ciclo desde que nuestro cliente nos pide un
desarrollo nuevo o un cambio hasta que
puede tenerlo en producción. Esto nos hará
ser mucho mas ágiles con nuestro cliente,
mostrándole en cada momento como
evoluciona el desarrollo para que, junto con
él, podamos llegar a la solución que mas
valor le aporte.