CAPÍTULO

ADMINISTRACIÓN
CONFIGURACIÓN DEL SOFTWARE
DE LA
22
CONCEPTOS uando se construye software de computadoras, el cambio es inevitable. Y el cambio

C
CLAVE

administración de contenido . 517
auditoría de configuración . . 514
líneas de referencia . . . . . . . 504
control de cambio . . . . . . . . 511
control de versión . . . . . . . . 510
identificación. . . . . . . . . . . . 509
ítems de configuración
de software (ICS) . . . . . . . . 505
objeto de configuración . . . . 505
objetos de configuración
de webapps . . . . . . . . . . . . 517
proceso ACS . . . . . . . . . . . . 508
reporte de estado . . . . . . . . 615
repositorio . . . . . . . . . . . . . 506
webapps . . . . . . . . . . . . . . 515
aumenta el nivel de confusión cuando los miembros de un equipo de software trabajan
en un proyecto. La confusión surge cuando los cambios no se analizan antes de que se
realicen, cuando no se registran antes de que se implanten, si no se reportan a quienes tienen
necesidad de conocerlos o si no se controlan en forma que mejore la calidad y se reduzca el
error. Babich [Bab86] analiza esto cuando afirma:
El arte de coordinar el desarrollo de software para minimizar [...] la confusión se llama administración
de la configuración, que es el arte de identificar, organizar y controlar las modificaciones que se hacen
al software que construirá un equipo de programación. La meta es maximizar la productividad al
minimizar los errores.
La administración de la configuración del software (ACS) es una actividad sombrilla que se
aplica a lo largo del proceso de software. Puesto que el cambio puede ocurrir en cualquier mo-
mento, se desarrollan actividades ACS para 1) identificar el cambio, 2) controlar el cambio, 3)
garantizar que el cambio se implementó de manera adecuada y 4) reportar los cambios a otros
que puedan estar interesados.
Es importante hacer una distinción clara entre el apoyo al software y la administración de la
configuración del software. El apoyo es un conjunto de actividades de ingeniería de software
que ocurren después de que éste se entregó al cliente y de que se puso en operación. La admi-
nistración de la configuración del software es un conjunto de actividades de rastreo y control
que inicia cuando comienza un proyecto de ingeniería de software y sólo termina cuando el
software se retira de la operación.

UNA
MIRADA ¿Qué es? Cuando se construye software de
RÁPIDA
computadora, ocurren cambios. Y puesto que
ocurren, es necesario administrarlos de manera
efectiva. La administración de la configuración
del software (ACS), también llamada gestión del cambio,
es un conjunto de actividades diseñadas para administrar
el cambio mediante la identificación de los productos de
trabajo que es probable que cambien, el establecimiento
de relaciones entre ellos, la definición de mecanismos para
administrar diferentes versiones de dichos productos de
trabajo y el control de los cambios impuestos, así como la
auditoría y reporte de los cambios realizados.
¿Quién lo hace? Todos los involucrados en el proceso de
software se relacionan en cierta medida con la gestión del
cambio, pero en ocasiones se crean posiciones de apoyo
especializadas para administrar el proceso ACS.
¿Por qué es importante? Si no se controla el cambio,
éste lo controla a uno. Y eso nunca es bueno. Es muy fácil
que un torrente de cambios descontrolados convierta en
caos un proyecto de software bien estructurado. Como
consecuencia, la calidad del software se reduce y la entre-
ga se demora. Por dicha razón, la gestión del cambio es
parte esencial de la administración de la calidad.
¿Cuáles son los pasos? Puesto que muchos productos de
trabajo se realizan cuando el software se construye, cada
uno debe identificarse de manera única. Una vez logrado,
pueden establecerse mecanismos para control de versión y
de cambio. Para garantizar que la calidad se mantiene
conforme se realizan cambios, audite el proceso; y para
asegurarse que quienes deben conocerlos estén informa-
dos acerca de los cambios, realice reportes.
¿Cuál es el producto final? Un Plan de Administración
de la Configuración del Software define la estrategia del
proyecto para la gestión del cambio. Además, cuando se
invoca ACS formal, el proceso de control de cambio pro-
duce solicitudes de cambio de software, reportes y órdenes
de cambio de ingeniería.
¿Cómo me aseguro de que lo hice bien? Cuando
todo producto de trabajo pueda explicarse, rastrearse y
controlarse; cuando todo cambio pueda rastrearse y ana-
lizarse; cuando todos los que deben saber acerca de un
cambio están informados, entonces la gestión del cambio
se hizo correctamente.

501

www.FreeLibros.me

22Pressman(501-525).indd 501 19/1/10 17:12:05

 502
22. 1
Cita:
“No hay nada permanente,
excepto el cambio.”
Heráclito, 500 a.C.
? ¿Cuál es el origen de
los cambios que se
solicitan para el
software?
22Pressman(501-525).indd 502
PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD
Una meta principal de la ingeniería de software es mejorar la facilidad con la que los cam-
bios pueden acomodarse y reducir la cantidad de esfuerzo empleado cuando deban realizarse
cambios. En este capítulo se estudian las actividades específicas que permiten administrar
el cambio.
ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
La salida del proceso de software es información que puede dividirse en tres categorías amplias:
1) programas de cómputo (tanto en el nivel de fuente como en formatos ejecutables), 2) produc-
tos de trabajo que describen los programas de cómputo (dirigidos a varios participantes) y 3)
datos o contenido (incluidos dentro del programa o externos a él). Los ítems que comprenden
toda la información producida como parte del proceso de software se llaman colectivamente
configuración del software.
Conforme avanza el trabajo de ingeniería de software, se crea una jerarquía de ítems de con-
figuración del software (ICS): un elemento de información nominado que puede ser tan pequeño
como un solo diagrama UML o tan grande como el documento de diseño completo. Si cada ICS
simplemente conduce a otros ICS, dará como resultado poca confusión. Por desgracia, en el
proceso entra otra variable: el cambio, que puede ocurrir en cualquier momento, por cualquier
razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [Ber80] establece: “Sin importar
dónde se esté en el ciclo de vida del sistema, el sistema cambiará, y el deseo por cambiar per-
sistirá a lo largo del ciclo de vida.”
¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los
mismos cambios. Sin embargo, existen cuatro fuentes fundamentales de cambio:
• Nuevas condiciones empresariales o de mercado dictan los cambios en los requeri-
mientos del producto o en las reglas empresariales.
• Nuevas necesidades de los accionistas demandan modificación a los datos producidos
por los sistemas de información, a la funcionalidad que entregan los productos o a los
servicios que ofrece un sistema basado en computadora.
• La reorganización o crecimiento/reducción de la empresa produce cambios en las prio-
ridades proyectadas o en la estructura del equipo de ingeniería de software.
• Restricciones presupuestales o de calendario causan una redefinición del sistema o del
producto.
La administración de la configuración del software es un conjunto de actividades que se de-
sarrollaron para administrar el cambio a lo largo del ciclo de vida del software de computadora.
La ACS puede verse como una actividad que garantiza la calidad del software y que se aplica a
lo largo del proceso de software. En las siguientes secciones se describen las principales tareas
ACS y los conceptos importantes que pueden ayudar a gestionar el cambio.
22.1.1 Un escenario ACS1
Un escenario operativo de administración del cambio (AC) típico involucra a un gerente de pro-
yecto que está a cargo de un grupo de software, a un gerente de configuración responsable de
los procedimientos y políticas AC, a los ingenieros de software encargados de desarrollar y
mantener el producto de software y al cliente que usa el producto. En el escenario, se supone
que el producto es pequeño y que involucra a alrededor de 15 000 líneas de código desarrollado
por un equipo de seis personas. (Observe que es posible que existan otros escenarios de equipos
1 Esta sección se extrajo de [Dar01]. El permiso especial para reproducir “Spectrum of functionality in CM System”,
de Susan Dart [Dar01], © 2001 de Carnegie Mellon University, se obtuvo del Software Engineering Institute.
www.FreeLibros.me
19/1/10 17:12:07

? ¿Cuáles son las metas
de y las actividades
realizadas por cada uno
de los elementos
constituyentes
involucrados en la
administración del
cambio?
PU
NT
O nieros no deben interferir innecesariamente unos con otros en la creación y prueba del código
CLAVE
Debe existir un mecanismo para
asegurar que los cambios
simultáneos hechos al mismo
componente se rastreen, gestionen y
ejecuten de manera adecuada.
22Pressman(501-525).indd 503
C AP Í T UL O 22 ADMINIST RACIÓN DE LA CONFIG U RACIÓN DEL SOFT WARE 503
más pequeños o más grandes, pero, en esencia, hay temas genéricos que cada uno de estos
proyectos enfrenta con respecto a la AC).
En el nivel operativo, el escenario involucra varios roles y tareas. Para el gerente de proyecto,
la meta es garantizar que el producto se desarrolla dentro de cierto marco temporal. Por
tanto, monitorea el progreso del desarrollo y reconoce y reacciona ante los problemas. Esto se
hace mediante la generación y el análisis de reportes acerca del estado del sistema de software
y al realizar revisiones al sistema.
Las metas del gerente de configuración son garantizar que se sigan los procedimientos y
políticas para crear, cambiar y probar el código, así como hacer accesible la información acerca
del proyecto. Para implantar técnicas a fin de mantener el control sobre los cambios de código,
este gerente introduce mecanismos para: realizar peticiones oficiales de cambios, evaluarlos
(mediante un Consejo de Control de Cambios que sea responsable de aprobar los cambios al
sistema de software) y autorizarlos. El gerente elabora y difunde la lista de tareas para los inge-
nieros y básicamente crea el contexto del proyecto. Además, recopila estadísticas acerca de los
componentes que hay en el sistema de software, tales como la información que determina cuá-
les componentes del sistema son problemáticos.
Para los ingenieros de software, la meta es trabajar eficazmente. Esto significa que los inge-
y en la producción de productos operativos de apoyo. Pero, al mismo tiempo, deben intentar
comunicarse y coordinarse de manera eficiente. Específicamente, los ingenieros usan herra-
mientas que ayudan a construir un producto de software consistente. Se comunican y coordinan
al notificarse unos con otros las tareas requeridas y las tareas completadas. Los cambios se
propagan a través del trabajo mutuo mediante fusión de archivos. Existen mecanismos para
garantizar que, para componentes que experimentan cambios simultáneos, hay alguna forma
de resolver los conflictos y la fusión de cambios. Se conserva una historia de la evolución de
todos los componentes del sistema, una bitácora con las razones de los cambios y un registro
de lo que realmente cambió. Los ingenieros tienen su propio espacio de trabajo para crear,
cambiar, poner a prueba e integrar código. En cierto punto, el código se convierte en una línea
de referencia desde la cual continúan mayores desarrollos y se realizan variantes para otras
máquinas objetivo.
El cliente usa el producto. Puesto que éste se encuentra bajo control AC, el cliente sigue pro-
cedimientos formales para solicitar cambios y para indicar errores en el producto.
De manera ideal, un sistema AC utilizado en este escenario debe apoyar todos estos roles y
tareas, es decir, los roles determinan la funcionalidad requerida de un sistema AC. El gerente de
proyecto ve la AC como un mecanismo de auditoría; el gerente de configuración la considera
un mecanismo de control, rastreo y generación de políticas; el ingeniero de software, como un
mecanismo de control de cambio, construcción y acceso; y el cliente la ve como un camino para
garantizar la calidad.
22.1.2 Elementos de un sistema de administración de la configuración
En su exhaustivo artículo acerca de la administración de la configuración del software, Susan
Dart [Dar01] identifica cuatro elementos importantes que deben existir cuando se desarrolla un
sistema de administración de la configuración:
• Elementos componentes: conjunto de herramientas acopladas dentro de un sistema de
administración de archivos (por ejemplo, base de datos) que permite el acceso a cada
ítem de configuración del software, así como su gestión.
• Elementos de proceso: colección de acciones y tareas que definen un enfoque efectivo de
la gestión del cambio (y actividades relacionadas) para todos los elementos constitu-
yentes involucrados en la administración, ingeniería y uso del software.
www.FreeLibros.me
19/1/10 17:12:07
 504
CONSEJO
La mayoría de los cambios de
software se justifican, así que no hay
razón para quejarse por su presencia.
En su lugar, asegúrese de que tiene
los mecanismos para lidiar con ellos.
CONSEJO
Asegúrese de que la base de datos
del proyecto se mantenga en una
ubicación centralizada controlada.
22Pressman(501-525).indd 504
PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD
• Elementos de construcción: conjunto de herramientas que automatizan la construcción
de software al asegurarse de que se ensambló el conjunto adecuado de componentes
validados (es decir, la versión correcta).
• Elementos humanos: conjunto de herramientas y características de proceso (que abarcan
otros elementos AC) utilizados por el equipo de software para implementar ACS efectiva.
Estos elementos (que se estudiarán con más detalle en secciones posteriores) no son mutua-
mente excluyentes. Por ejemplo, los elementos componentes trabajan en conjunción con los
elementos de construcción conforme evoluciona el proceso de software. Los elementos de pro-
ceso guían muchas actividades humanas que se relacionan con la ACS y, por tanto, también
pueden considerarse como elementos humanos.
22.1.3 Líneas de referencia
El cambio es un hecho de vida en el desarrollo de software. Los clientes quieren modificar los
requerimientos. Los desarrolladores quieren cambiar el enfoque técnico. Los gerentes quieren
modificar la estrategia del proyecto. ¿Por qué todas estas modificaciones? La respuesta real-
mente es muy simple. Conforme pasa el tiempo, todos los elementos constituyentes saben más
(acerca de lo que necesitan, sobre qué enfoque sería mejor, cómo realizarlo y todavía obtener
dinero). Este conocimiento adicional es la fuerza motora que hay detrás de la mayoría de los
cambios y que conduce a un enunciado de hechos que es difícil de aceptar para muchos profe-
sionales de la ingeniería de software: ¡la mayoría de los cambios se justifican!
Una línea de referencia es un concepto de administración de la configuración del software que
le ayuda a controlar el cambio sin impedir seriamente cambios justificados. El IEEE (IEEE Std.
No. 610.12-1990) define una línea de referencia como:
Una especificación o producto que se revisó formalmente y con el que se estuvo de acuerdo, que a
partir de entonces sirve como base para un mayor desarrollo y que puede cambiar sólo a través de
procedimientos de control de cambio formal.
Antes de que un ítem de configuración del software se convierta en línea de referencia, los
cambios pueden realizarse rápida e informalmente. No obstante, una vez establecida la línea de
referencia, pueden realizarse cambios, pero debe aplicarse un procedimiento formal específico
para evaluar y verificar cada uno de ellos.
En el contexto de la ingeniería de software, una línea de referencia es un hito en el desarrollo
del software. Una línea de referencia se marca al entregar uno o más ítems de configuración del
software que se aprobaron como consecuencia de una revisión técnica (capítulo 15). Por ejemplo,
los elementos de un modelo de diseño se documentaron y revisaron. Se encontraron y corrigie-
ron errores. Una vez que todas las partes del modelo se revisaron, corrigieron y luego aprobaron,
el modelo de diseño se convierte en línea de referencia. Los cambios adicionales a la arquitectura
del programa (documentada en el modelo de diseño) pueden realizarse sólo después de que cada
uno se evalúa y aprueba. Aunque las líneas de referencia pueden definirse en cualquier nivel de
detalle, en la figura 22.1 se muestran las líneas de referencia de software más comunes.
En la figura 22.1 también se ilustra la progresión de eventos que conducen a una línea de
referencia. Las tareas de la ingeniería de software producen uno o más ICS. Después de revisar
y aprobar los ICS, se colocan en una base de datos del proyecto (también llamada librería de pro-
yecto o repositorio de software, y que se estudia en la sección 22.2). Cuando un miembro de un
equipo de ingeniería de software quiere hacer una modificación a un ICS que se ha convertido
en línea de referencia, se copia de la base de datos del proyecto en el espacio de trabajo priva-
do del ingeniero. Sin embargo, este ICS extraído puede modificarse solamente si se siguen
controles ACS (que se estudian más adelante en este capítulo). Las flechas de la figura 22.1
ilustran la ruta de modificación de un ICS convertido en línea de referencia.
www.FreeLibros.me
19/1/10 17:12:07
 C AP Í T UL O 22 ADMINIST RACIÓN DE LA CONFIG U RACIÓN DEL SOFT WARE 505

FIGURA 22.1
Modificado
ICS como línea de ICS
referencia y base
Base de datos del proyecto
de datos del
proyecto Aprobado
Tareas de Revisiones
la ingeniería ICS ICS
técnicas
de software

Almacenado

ICS

Extraído
Controles
ICS
ACS
LÍNEAS DE REFERENCIA:
Especificación del sistema
Requerimientos de software
Especificación de diseño
Código fuente
Planes/procedimientos/datos de prueba
Sistema operativo

22.1.4 Ítems de configuración del software

Ya se definió un ítem de configuración del software como la información que se crea como parte
del proceso de ingeniería de software. En última instancia, un ICS podría considerarse como una
sola sección de una gran especificación o como un caso de prueba en una gran suite de pruebas.
De manera más realista, un ICS es todo o parte de un producto de trabajo (por ejemplo, un do-
cumento, toda una suite de casos de prueba o un componente de programa nominado).
Además de los ICS que se derivan de los productos de trabajo de software, muchas organi-
zaciones de ingeniería de software también colocan las herramientas de software bajo control
de configuración, es decir, versiones específicas de editores, compiladores, navegadores y otras
herramientas automatizadas se “congelan” como parte de la configuración del software. Puesto
que dichas herramientas se usaron para producir documentación, código fuente y datos, deben
estar disponibles cuando tengan que realizarse cambios a la configuración del software. Aunque
los problemas son raros, es posible que una nueva versión de una herramienta (por ejemplo, un
compilador) pueda producir resultados diferentes que la versión original. Por esta razón, las
herramientas, como el software que ayudan a producir, pueden convertirse en líneas de refe-
rencia como parte de un proceso amplio de administración de la configuración.
En realidad, los ICS se organizan para formar objetos de configuración que puedan catalo-
garse con un solo nombre en la base de datos del proyecto. Un objeto de configuración tiene un
nombre y atributos, y está “conectado” con otros objetos mediante relaciones. En la figura 22.2,
los objetos de configuración DesignSpecification (especificación de diseño), DataModel (mo-
delo de datos), ComponentN (componente n), SourceCode (código fuente) y TestSpecifica-
tion (especificación de prueba) se definen cada uno por separado. Sin embargo, cada uno de los
objetos se relaciona con los demás, como se muestra mediante las flechas. Una flecha curva
indica una relación composicional, es decir, DataModel y ComponentN son parte del objeto
DesignSpecification. Una flecha con doble punta indica una interrelación. Si se realizara un
cambio al objeto SourceCode, las interrelaciones permiten determinar qué otros objetos (e ICS)
pueden resultar afectados.2

2 Esas relaciones se definen dentro de la base de datos. La estructura de la base de datos (repositorio) se estudia
con mayor detalle en la sección 22.2.

www.FreeLibros.me

22Pressman(501-525).indd 505 19/1/10 17:12:08

 506 PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD

FIGURA 22.2
Objetos de DataModel
configuración
DesignSpecification

diseño de datos
diseño arquitectónico
diseño de módulo
diseño de interfaz
ComponentN

descripción de interfaz
descripción de algoritmo
TestSpecification PDL

plan de pruebas
procedimiento de pruebas
casos de pruebas
SourceCode

22. 2 EL REPOSITORIO ACS

En los primeros días de la ingeniería de software, los ítems de configuración del software se
mantenían como documentos en papel (¡o tarjetas perforadas!), colocadas en carpetas de papel
o de anillos, y se almacenaban en archiveros metálicos. Este mecanismo era problemático por
muchas razones: 1) con frecuencia era difícil encontrar un ítem de configuración cuando se
necesitaba, 2) era muy desafiante determinar cuáles ítems cambiaban, cuándo y por quién, 3)
construir una nueva versión de un programa existente consumía mucho tiempo y era proclive
al error y 4) describir relaciones detalladas y complejas entre los ítems de configuración era
virtualmente imposible.
En la actualidad, los ICS se mantienen en una base de datos del proyecto, o repositorio. El
Diccionario Webster define la palabra repositorio como “cualquier cosa o persona que se consi-
dera como centro de acumulación o almacenamiento”. Durante la historia temprana de la inge-
niería de software, de hecho el repositorio era una persona: el programador que debía recordar
la ubicación de toda la información relevante para un proyecto de software, quien debía recu-
perar la información que nunca se escribió y reconstruir la información perdida. Tristemente,
usar a una persona como “el centro para acumulación y almacenamiento” (aun conforme con
la definición del Webster) no funciona muy bien. En la actualidad, el repositorio es una “cosa”:
una base de datos que actúa como el centro de acumulación y de almacenamiento de la infor-
mación de ingeniería de software. El papel de la persona (el ingeniero del software) es interac-
tuar con el repositorio, usando las herramientas que se integran con él.

22.2.1 El papel del repositorio

El repositorio ACS es el conjunto de mecanismos y estructuras de datos que permiten a un
equipo de software administrar el cambio en forma efectiva. Proporciona las funciones obvias
de un moderno sistema de administración de base de datos, al asegurar integridad, posibili-
dad de compartir e integración de datos. Además, el repositorio ACS proporciona un centro para
la integración de herramientas de software, es fundamental en el flujo del proceso de software
y puede reforzar la estructura y el formato uniforme para los productos que son resultado de la
ingeniería de software.

www.FreeLibros.me

22Pressman(501-525).indd 506 19/1/10 17:12:08

 MATERIA:
Introducción a la
Ingeniería de Software
Modulo
UNIVERSIDAD DE EL SALVADOR :
Facultad Multidisciplinaria de Docent
Occidente Departamento de Ingeniería e:
y Arquitectura Grupo:
 UNIDAD 3.1
ADMINISTRACIÓN Y GESTIÓN DE LA CONFIGURACIÓN

La ACS (Administración de la Configuración del Software) son un

conjunto de actividades diseñadas para administrar el cambio
mediante la identificación de los componentes que es probable que
cambien, sus relaciones, la administración de sus versiones, el control
de los cambios impuesto y el reporte de los cambios realizados.
 ÍTEMS DE CONFIGURACIÓN DEL SOFTWARE

Un Ítem de Configuración del Software (ICS) comprenden toda la

información producida como parte del proceso de software, estos
pueden ser pequeños como un diagrama o tan grandes como un
documento de diseño completo.
 ORIGEN DE LOS CAMBIOS

Existen cuatro fuentes fundamentales del cambio:

1) Nuevas condiciones empresariales o de mercado.
2) Nuevas necesidades de los accionistas.
3) La reorganización o crecimiento/reducción de la empresa.
4) Restricciones presupuestales o de calendario.
 UN ESCENARIO DE ACS

Un escenario operativo de AC típico involucra a un gerente de proyecto, a un

gerente de configuración, a los ingenieros de software y al cliente.
Para el gerente de proyecto, la meta es garantizar que el producto se
desarrolle dentro de un marco de tiempo temporal.
Las metas del gerente de configuración es garantizar que se sigan los
procedimientos y políticas para crear, cambiar y probar el código, así como
hacer accesible la información acerca del proyecto.
Para los ingenieros de software le meta es trabajar eficazmente, es decir que
estos no deben interferir unos con otros en la creación y pruebas del código y
en la producción de productos operativos de apoyo.
El cliente usa el producto; este usa procedimientos formales para solicitar
cambios y para indicar errores en el producto.
 ELEMENTOS DE UN SISTEMA DE ACS

⚫ Elementos componentes: conjunto de herramientas dentro de un

sistema de administración de archivos que permite el acceso a
cada ICS, así como su gestión.
⚫ Elementos de proceso: colección de tareas que definen un
enfoque efectivo de la gestión del cambio para todos los
elementos en la administración, ingeniería y uso del software.
⚫ Elementos de construcción: conjunto de herramientas que
automatizan la construcción de software al asegurarse que ha
ocurrido un ensamble adecuado de los componentes validados.
⚫ Elementos humanos: conjunto de herramientas utilizadas por el
equipo de software para implementar ACS efectiva.
⚫ Estos elementos no son mutuamente excluyentes.
 3.2 ÍTEMS DE CONFIGURACIÓN DEL SOFTWARE

Se ha definido ya un ICS como la información que se crea como parte

del proceso de ingeniería de software.
Existen organizaciones donde también se colocan herramientas de
software bajo control de la configuración, por ejemplo: versiones
específicas de compiladores, editores, navegadores, etc. Puesto que
dichas herramientas se utilizaron para producir documentación, código
y datos deben de estar disponibles cuando tengan que realizarse
cambios a la CS..
 510
PU
NT
O única: un nombre, una descripción, una lista de recursos y una “realización”. El nombre del
CLAVE
Las interrelaciones establecidas por
los objetos de configuración le
permiten valorar el impacto del
cambio.
CONSEJO
Incluso si la base de datos del
proyecto proporciona la capacidad
para establecer dichas relaciones,
éstas consumen mucho tiempo para
su establecimiento y son difíciles de
mantener actualizadas. Aunque son
muy útiles para el análisis de
impacto, no son esenciales para la
administración de cambio global.
22Pressman(501-525).indd 510
PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD
Por ejemplo, un DesignSpecification es un objeto agregado. Conceptualmente, puede vérsele
como una lista nominada (identificada) de punteros que especifican objetos agregados, como
ArchitecturalModel y DataModel, y objetos básicos, como ComponentN y UMLClass-
DiagramN.
Cada objeto tiene un conjunto de características distintivas que lo identifican de manera
objeto es una cadena de caracteres que identifica el objeto sin ambigüedades. La descripción
del objeto es una lista de ítems de datos que identifican el tipo ICS (por ejemplo, elemento de
modelo, programa, datos) representado por el objeto, un identificador de proyecto e información
de cambio y/o versión. Los recursos son “entidades que se proporcionan, procesan, referencian
o que de algún modo el objeto las requiere” [Cho89]. Por ejemplo, los tipos de datos, las funcio-
nes específicas o incluso los nombres de variable pueden considerarse como recursos del ob-
jeto. La realización es un puntero hacia la “unidad de texto” para un objeto básico, y nulo para
un objeto agregado.
La identificación del objeto de configuración también puede considerar las relaciones que
existen entre los objetos nominados. Por ejemplo, al usar la notación simple
Diagrama clase <parte de> modelo requerimientos;
Modelo requerimientos <parte de> especificación requerimientos;
se puede crear una jerarquía de ICS.
En muchos casos, los objetos se interrelacionan a través de ramas de la jerarquía de objetos.
Estas relaciones transestructurales pueden representarse en la forma siguiente:
ModeloDatos <interrelacionado> ModeloFlujoDatos
ModeloDatos <interrelacionado> CasoPruebaClaseM
En el primer caso, la interrelación se efectúa entre un objeto compuesto, mientras que la se-
gunda relación es entre un objeto agregado (ModeloDatos) y un objeto básico (CasoPrueba-
ClaseM).
El esquema de identificación para objetos de software debe reconocer que los objetos evolu-
cionan a lo largo del proceso de software. Antes de que un objeto se convierta en línea de refe-
rencia, puede cambiar muchas veces; incluso, después de establecer una línea de referencia, los
cambios pueden ser bastante frecuentes.
22.3.2 Control de versión
El control de versión combina procedimientos y herramientas para administrar diferentes ver-
siones de objetos de configuración que se crean durante el proceso de software. Un sistema de
control de versión implementa o se integra directamente con cuatro grandes capacidades: 1)
una base de datos de proyecto (repositorio) que almacena todos los objetos de configuración
relevantes, 2) una capacidad de administración de versión que almacena todas las versiones de
un objeto de configuración (o que permite la construcción de cualquier versión usando diferen-
cias de las versiones pasadas) y 3) una facilidad para elaboración que le permite recopilar to-
dos los objetos de configuración relevantes y construir una versión específica del software.
Además, los sistemas de control de versión y de control de cambio con frecuencia implementan
una capacidad de rastreador de conflictos (también llamado rastreador de errores) que permite al
equipo registrar y rastrear el estado de todos los conflictos sobresalientes asociados con cada
objeto de configuración.
Algunos sistemas de control de versión establecen un conjunto de cambio, una colección de
todos los cambios (en relación con cierta configuración de referencia) que se requieren para
crear una versión específica del software. Dart [Dar91] observa que un conjunto de cambio
www.FreeLibros.me
19/1/10 17:12:09
 C AP Í T UL O 22 ADMINIST RACIÓN DE LA CONFIG U RACIÓN DEL SOFT WARE 511

“captura todos los cambios habidos en todos los archivos que hay en la configuración, junto con
la razón de los cambios y detalles de quién y cuándo hizo los cambios”.
Algunos conjuntos de cambio nominados pueden identificarse para una aplicación o sistema.
Esto permite construir una versión del software al especificar los conjuntos de cambios (por
nombre) que deben aplicarse a la configuración de referencia. Para lograr esto, se aplica un
enfoque de modelado de sistema. El modelo del sistema contiene: 1) una plantilla que incluye una
jerarquía de componente y un “orden de construcción” para los componentes que describen
cómo debe construirse el sistema, 2) reglas de construcción y 3) reglas de verificación.4
Durante las décadas pasadas se propusieron algunos enfoques automatizados diferentes
para el control de versión. La diferencia principal en los enfoques es la sofisticación de los atri-
butos que se usan para construir versiones específicas y variantes de un sistema y la mecánica
del proceso para su construcción.

El Sistema de Versiones Concurrentes (SVC)
El uso de herramientas para lograr el control de ver-
sión es esencial para la administración efectiva del cam-
bio. El sistema de versiones concurrentes (SVC) es una herramienta
ampliamente utilizada para el control de versiones. Originalmente
diseñada para código fuente, pero útil para cualquier archivo basado
en texto, el SVC 1) establece un repositorio simple, 2) mantiene todas
las versiones de un archivo en un solo archivo nominado al almace-
nar sólo las diferencias entre versiones progresivas del archivo origi-
nal y 3) protege a un archivo contra los cambios simultáneos al esta-
blecer diferentes directorios para cada desarrollador, lo que, por
tanto, aísla uno de otros. El SVC mezcla los cambios cuando cada
desarrollador completa su trabajo.
Es importante observar que el SVC no es un sistema “de construc-
ción”, es decir, no construye una versión específica del software.
H ERRAMIENTAS DE SOFTWARE
Deben integrarse otras herramientas (por ejemplo, Makefile) con el
SVC para lograr esto. El SVC no implanta un proceso de control de
cambio (por ejemplo, solicitudes de cambio, reportes de cambio, ras-
treo de errores).
Incluso con estas limitaciones, el SVC “es un dominante sistema de
control de versión, de red transparente y código abierto, [que] es útil
para todos, desde desarrolladores individuales hasta grandes equipos
distribuidos” [CVS07]. Su arquitectura cliente-servidor permite a los
usuarios acceder a los archivos mediante conexiones de internet, y su
filosofía de código abierto lo vuelve disponible para la mayoría de las
plataformas más usadas.
SVC está disponible sin costo alguno para entornos Windows,
Mac OS, LINUX y UNIX. Vea [CVS07] para más detalles.

22.3.3 Control de cambio

La realidad del control de cambio en un contexto moderno de ingeniería de software la resume
Cita: bellamente James Bach [Bac98]:

“El arte de avanzar es preservar El control del cambio es vital. Pero las fuerzas que lo hacen necesario también lo hacen desconcer-
el orden en medio del cambio y tante. Nos preocupamos por el cambio porque una pequeña perturbación en el código puede crear una
preservar el cambio en medio gran falla en el producto. Pero también puede corregir un gran fallo o permitir maravillosas nuevas
del orden.” capacidades. Nos preocupamos por el cambio porque un solo desarrollador granuja podría hundir el

Alfred North Whitehead proyecto, aunque en las mentes de dichos granujas se originan ideas brillantes y un abrumador pro-
ceso de control del cambio podría efectivamente desalentarlos de hacer trabajo creativo.

Bach reconoce que se está frente a un acto de equilibrio. Mucho control del cambio y se crearán
problemas. Muy poco y se crearán otros problemas.
Para un gran proyecto de software, el cambio descontrolado conduce rápidamente al caos.
Para tales proyectos, el control del cambio combina procedimientos humanos y herramientas

4 También es posible consultar el modelo del sistema para valorar cómo impactará un cambio en un componente
a otros componentes.

www.FreeLibros.me

22Pressman(501-525).indd 511 19/1/10 17:12:09

 522 PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD

22.4.5 Control de versión

Conforme una webapp evoluciona a través de una serie de incrementos, pueden existir al mismo
tiempo algunas versiones diferentes. Una versión (la webapp operativa actual) está disponible
mediante internet para usuarios finales; otra (el siguiente incremento de webapp) puede estar
en las etapas finales de prueba antes de su implementación; una tercera versión está en desa-
rrollo y representa una gran actualización en contenido, estética de interfaz y funcionalidad. Los
objetos de configuración deben definirse con claridad, de modo que cada uno pueda asociarse
con la versión adecuada. Además, deben establecerse mecanismos de control. Dreilinger
[Dre99] analiza la importancia del control de versiones (y de cambios) cuando escribe:

En un sitio descontrolado, donde múltiples autores tienen acceso para editar y contribuir, surge el
potencial para conflictos y problemas, más aún si dichos autores trabajan desde diferentes oficinas en
diferentes momentos del día y de la noche. Usted puede pasar el día mejorando el archivo index.html
para un cliente. Después de que usted realiza sus cambios, otro desarrollador que trabaja en casa
después de las horas de oficina, o en otra oficina, puede pasar la noche actualizando su propia versión
recientemente revisada del archivo index.html, ¡y sobreescribir por completo su trabajo sin que haya
forma de recuperarlo!

Es probable que usted haya experimentado una situación similar. Para evitarla, se requiere un
proceso de control de versiones.

1. Debe establecerse un repositorio central para el proyecto web, que contendrá las versiones
actuales de todos los objetos de configuración webapp (contenido, componentes funcio-
nales y otros).
2. Cada ingeniero web crea su propia carpeta de trabajo, que contiene aquellos objetos que
se crean o cambian en cualquier momento.
3. Los relojes en todas las estaciones de trabajo de los desarrolladores deben estar sincroniza-
dos para evitar conflictos de sobreescritura cuando dos desarrolladores realizan actuali-
zaciones que están muy cercanas en el tiempo.
4. Conforme se desarrollan nuevos objetos de configuración o se cambian los objetos existen-
tes, deben importarse hacia el repositorio central. La herramienta de control de versión
(vea la discusión de SVC en la barra lateral) gestionará todas las funciones de entrada y
salida de las carpetas de trabajo de cada desarrollador web. Cuando se hagan cambios
al repositorio, la herramienta también proporcionará actualizaciones automáticas por
correo electrónico a todas las partes interesadas.
5. Conforme los objetos se importen al o se exporten del repositorio, se elabora un mensaje de
bitácora automático con marca de tiempo. Esto proporciona información útil para auditar
y puede volverse parte de un esquema de reporte efectivo.

La herramienta de control de versión conserva diferentes versiones de la webapp y puede rever-

tir una de ellas a una versión más antigua si se requiere.

22.4.6 Auditoría y reporte

Con la intención de obtener agilidad, las funciones de auditoría y reporte no tienen mucho én-
fasis en el trabajo de ingeniería web.10 Sin embargo, no se eliminan por completo. Todos los
objetos que entran o salen del repositorio se registran en una bitácora que puede revisarse en

10 Esto empieza a cambiar. Hay un creciente énfasis en la ACS como un elemento de la seguridad de la webapp
[Sar06]. Al proporcionar un mecanismo para rastrear y reportar todo cambio hecho a cada objeto Web, una he-
rramienta de administración del cambio puede proporcionar valiosa protección contra cambios maliciosos.

www.FreeLibros.me

22Pressman(501-525).indd 522 19/1/10 17:12:13

 690 Capítulo 25 ■ Administración de la configuración

Codeline (A) Baseline - V1

A A1.1 A1.2 A1.3
A B1.2 C1.1

Codeline (B)
L1 L2 Ex1
B B1.1 B1.2 B1.3

Baseline - V2
Codeline (C)
C C1.1 C1.2 C1.3 A1.3 B1.2 C1.2

Figura 25.6 Líneas de L1 L2 Ex2

Librerías y componentes externos
código (codelines) y
L1 L2 Ex1 Ex2
líneas base (baselines) Mainline

2 5 .2 Gestión de versiones

La gestión de versiones (VM, por las siglas de version management) es el proceso de

hacer un seguimiento de las diferentes versiones de los componentes de software o ítems
de configuración, y los sistemas donde se usan dichos componentes. También incluye
asegurar que los cambios hechos a dichas versiones por los diferentes desarrolladores no
interfieran unos con otros. Por lo tanto, se puede considerar a la gestión de versiones como el
proceso de administrar líneas de código y líneas base.
La figura 25.6 ilustra las diferencias entre línea de código y línea base. En esencia,
una línea de código es una secuencia de versiones de código fuente con las versiones más
recientes en la secuencia derivadas de las versiones anteriores. Las líneas de código se
aplican regularmente a componentes de sistemas, de manera que existen diferentes ver-
siones de cada componente. Una línea base es una definición de un sistema específico.
Por consiguiente, la línea base especifica las versiones del componente que se incluyen
en el sistema más una especificación de las librerías usadas, archivos de configuración,
etcétera. En la figura 25.6 se observa que diferentes líneas base usan distintas versiones
de los componentes de cada línea de código. En el diagrama se sombrearon los recuadros
que representan componentes en la definición línea base para indicar que en realidad son
referencias a componentes en una línea de código. La línea principal es una secuencia de
versiones del sistema desarrolladas a partir de una línea base original.
Las líneas base pueden especificarse mediante un lenguaje de configuración, lo que
permite definir cuáles componentes se incluyen en una versión de un sistema particular.
Es posible especificar de manera explícita una versión de componente específica (X.1.2,
por ejemplo) o simplemente especificar el identificador del componente (X). Si usa
el identificador, esto significa que en la línea base debe usarse la versión más reciente
del componente.
Las líneas base son importantes porque muchas veces es necesario volver a crear una
versión específica de un sistema completo. Por ejemplo, una línea de producto puede
ejemplificarse de modo que existan versiones de sistema individuales para diferentes
clientes. Posiblemente se tenga que volver a crear la versión entregada a un cliente espe-
cífico si, por ejemplo, dicho cliente reporta bugs en su sistema que deban repararse.
Para soportar la gestión de versiones, siempre se deben usar herramientas de gestión
de versiones (llamadas en ocasiones sistemas de control de versiones o sistemas de control

M25_SOMMERVILLE_INGENIERIA_1ED_SE_681-704.indd 690 3/18/11 5:16:31 PM

 25.2 ■ Gestión de versiones 691

Fecha de creación
Secuencia de versión

Versión Versión Versión Versión

1.0 1.1 1.2 1.3

Más reciente

Código
Figura 25.7 Gestión D1 D2 D3 fuente V1.3
de almacenamiento
con deltas Estructura de almacenamiento

de código fuente). Estas herramientas identifican, almacenan y controlan el acceso a

las diferentes versiones de los componentes. Se hallan disponibles muchos sistemas dife-
rentes de gestión de versiones, incluidos los sistemas de código abierto ampliamente
usados como CVS y Subversion (Pilato et al., 2004; Vesperman, 2003).
Los sistemas de gestión de versiones ofrecen a menudo varias características:

1. Identificación de versión y entrega (release) A las versiones gestionadas se les asig-

nan identificadores cuando se envían al sistema. Dichos identificadores se basan, por
lo general, en el nombre del ítem de configuración (por ejemplo, ButtonManager),
seguido por uno o más números. De esta manera, ButtonManager 1.3 significa la
tercera versión en codeline 1 del componente ButtonManager. Algunos sistemas
CM también permiten la asociación de atributos con versiones (por ejemplo, móvil,
pantalla pequeña), que también pueden usarse para identificación de la versión. Es
importante que el sistema de identificación sea consistente, ya que esto simplifica el
problema de definir configuraciones. Hace más sencillo el uso de referencias abre-
viadas (por ejemplo, *.V2, que significa la versión 2 de todos los componentes).
2. Gestión de almacenamiento Para reducir el espacio de almacenamiento requerido
por múltiples versiones de los componentes que difieren sólo ligeramente, los siste-
mas de gestión de versiones ofrecen, por lo general, facilidades de gestión de alma-
cenamiento. En vez de conservar una copia completa de cada versión, el sistema
almacena una lista de diferencias (deltas) entre una versión y otra. Al aplicar esto
a una versión fuente (por lo regular, la versión más reciente), puede recrearse una
versión objetivo. Esto se ilustra en la figura 25.7.
3. Registro del historial de cambios Todos los cambios realizados al código de un
sistema o componente se registran y enumeran. En algunos sistemas, dichos cam-
bios pueden usarse para seleccionar la versión de un sistema en particular. Esto
implica etiquetar componentes con palabras clave que describan los cambios reali-
zados. Entonces se pueden usar dichas etiquetas (tags) para seleccionar los compo-
nentes a incluir en una línea base.
4. Desarrollo independiente Es posible que diferentes desarrolladores trabajen en el
mismo componente al mismo tiempo. El sistema de gestión de versiones hace un
seguimiento de los componentes que se marcaron para la edición y se asegura de que
no interfieran los cambios hechos a un componente por diferentes desarrolladores.
5. Soporte de proyecto Un sistema de gestión de versiones puede soportar el desarro-
llo de varios proyectos que comparten componentes. En los sistemas de soporte de

M25_SOMMERVILLE_INGENIERIA_1ED_SE_681-704.indd 691 3/18/11 5:16:31 PM

 692 Capítulo 25 ■ Administración de la configuración

Espacio de trabajo (U1) Espacio de trabajo (U2)

A B X Y

C C
Alice Bob

ingreso salida ingreso salida

(check_in) (check_out) (check_in) (check_out)

A1.1 B1.1 C1.1 Y P Q

Figura 25.8 Ingreso y A B C Z X R

salida de un repositorio
de versión Sistema de gestión de versiones

proyecto, como CVS (Vesperman, 2003), es posible ingresar (chek in) y sacar (check
out) todos los archivos asociados con un proyecto en lugar de tener que trabajar a la
vez con un archivo o directorio.

Cuando se desarrollaron por primera vez los sistemas de gestión de versiones, la gestión
del almacenamiento fue una de sus funciones más importantes. Las características de ges-
tión de almacenamiento en un sistema de control de versiones reduce el espacio de disco
requerido para mantener todas las versiones del sistema. Cuando se crea una nueva ver-
sión, el sistema simplemente almacena una delta (una lista de diferencias) entre la nueva
versión y la anterior que se usó para crear esa nueva versión (lo que se ilustra en la parte
inferior de la figura 25.7). En esta misma figura, los recuadros sombreados representan
versiones anteriores de un componente que se recrean automáticamente a partir de la ver-
sión de componente más reciente. Por lo general, las deltas se almacenan como listas de
líneas que cambiaron y, al aplicarlas automáticamente, puede crearse una versión de un
componente a partir de otro. Como es más probable que se use la versión más reciente de
un componente, la mayoría de los sistemas almacenan completa dicha versión. Entonces,
las deltas definen cómo recrear versiones anteriores del sistema.
La mayor parte del desarrollo de software es una actividad grupal, de modo que con
frecuencia surgen situaciones en las que diferentes miembros del equipo trabajan paralela-
mente en el mismo componente. Por ejemplo, suponga que Alicia hace algunos cambios a
un sistema, lo que implica cambiar los componentes A, B y C. Al mismo tiempo, Roberto
trabaja en cambios que requieren modificar los componentes X, Y y C. Entonces, tanto
Alicia como Roberto cambian C. Es importante evitar que estos cambios interfieran entre
sí, es decir, que los cambios de Roberto a C sobrescriban en los de Alicia o viceversa.
Para apoyar el desarrollo independiente sin interferencia, los sistemas de gestión de
versiones usan el concepto de repositorio público y un espacio de trabajo privado. Los
desarrolladores sacan componentes del repositorio público hacia su espacio de trabajo
privado y pueden cambiarlos como deseen en su mismo espacio. Cuando sus cambios
están completos, ingresan los componentes al repositorio. Esto se ilustra en la figura
25.8. Si dos o más personas trabajan en un componente al mismo tiempo, cada uno debe
sacar el componente del repositorio. Si se extrae un componente, el sistema de gestión
de versiones por lo general advierte a otros usuarios que quieren sacar dicho componente
que alguien más lo está usando. El sistema también garantizará que, al ingresar los

M25_SOMMERVILLE_INGENIERIA_1ED_SE_681-704.indd 692 3/18/11 5:16:31 PM

 25.3 ■ Construcción del sistema 693

Codeline 2.1
<ramificación>
V2.1.1 V2.1.2
Codeline 2
<combinación>
V2.0 V2.1 V2.4

V2.2 V2.3
Figura 25.9 <ramificación>
Ramificación
(branching) y V1.0 V1.1 V1.2
combinación
(merging) Codeline 1

componentes modificados a las distintas versiones, se les asignen diferentes identificado-

res de versión y se almacenen por separado.
Una consecuencia del desarrollo independiente del mismo componente es que las
líneas de código pueden ramificarse (branch). En vez de una secuencia lineal de versio-
nes que refleje los cambios al componente con el paso del tiempo, puede haber varias
secuencias independientes, como se muestra en la figura 25.9. Esto es normal en el desa-
rrollo de sistemas, en el que los diferentes desarrolladores trabajan de manera indepen-
diente en distintas versiones del código fuente y lo cambian en diversas formas.
En alguna etapa, tal vez sea necesario combinar ramificaciones de líneas de código
para crear una nueva versión de un componente que incluya todos los cambios realizados.
Esto también se muestra en la figura 25.9, donde las versiones 2.1.2 y 2.3 del compo-
nente se combinan para crear la versión 2.4. Si los cambios realizados involucran partes
completamente diferentes del código, las versiones del componente pueden combinarse
automáticamente mediante el sistema de gestión de versiones, al combinar las deltas que
se aplican al código. Con más frecuencia, existen traslapes entre los cambios realizados
que además interfieren entre sí. Un desarrollador debe verificar los conflictos y modificar
los cambios de manera que sean compatibles.

2 5 . 3 Construcción del sistema

La construcción del sistema es el proceso de crear un sistema ejecutable y completo al

compilar y vincular los componentes del sistema, librerías externas, archivos de con-
figuración, etcétera. Las herramientas de construcción del sistema y las de gestión de
versiones deben comunicarse, pues el proceso de construcción implica extraer versiones
del componente del repositorio administrado por el sistema de gestión de versiones. La
descripción de configuración que se usa para identificar una línea base utiliza también la
herramienta de construcción del sistema.
Construir es un proceso complejo, que potencialmente es proclive al error, pues tres
diferentes plataformas de sistema pueden estar implicadas (figura 25.10):

1. El sistema de desarrollo, que incluye herramientas de desarrollo, como los compi-

ladores, editores de código fuente, etcétera. Los desarrolladores sacan código del
sistema de gestión de versiones hacia un espacio de trabajo privado antes de hacer

M25_SOMMERVILLE_INGENIERIA_1ED_SE_681-704.indd 693 3/18/11 5:16:31 PM

 COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA
CONFIGURACIÓN
COMPARISON OF CONFIGURATION MANAGEMENT TOOLS
Enrique Carbonell Muela1, Ana María García Pérez2

1 DATYS, Cuba, enrique.carbonel@datys.cu, Máximo Gómez #65 Norte e/Tirso Marín y Calderón, Sancti Spíritus, Sancti
Spíritus, Cuba, CP 10600
2 DESOFT, Cuba, anamaria.garcia@vcl.desoft.cu

RESUMEN: Las herramientas de gestión de la configuración (CMT) en esencia permiten la automatización de

la instalación, configuración y actualización de software en un sistema. La variedad de estas herramientas
disponibles en el mercado hace difícil la selección de la adecuada, acorde a las necesidades de los clientes
cuando no se cuenta con expertos en el área para consultar. El propósito de este trabajo es seleccionar las
características para establecer un marco de comparación y aplicarlo a cuatro de las CMT más populares. Para
la selección se tuvieron en cuenta algunos criterios de comparación de estudios previos que de conjunto con los
aportados en este trabajo dan lugar a un sencillo marco de comparación para las CMT. Las herramientas
seleccionadas por su popularidad fueron: CFEngine, Puppet, Ansible y Salt. El estudio aporta una tabla
resumen donde se evidencian las características seleccionadas y su evaluación en cada una de las
herramientas.

Palabras Claves: herramientas de gestión de la configuración; marco de comparación; CFEngine; Puppet;

Ansible; Salt

ABSTRACT: The configuration management tools (CMT) essentially allow automation of installation,
configuration and update of system’s software. The variety of these tools available in the market makes it difficult
the right selection according to the needs of clients when you do not have consultant experts. The purpose of
this work is select the features to build a comparative framework and apply it to four of the most popular CMT. In
order to select some CMT we take into account some benchmarks of previous studies and join with others
proposed here to obtain a simple comparative framework. The tools selected by popularity went: CFEngine,
Puppet, Ansible and Salt. This work provides a summary table where the selected features are evaluated in
each of analyzed tools.

KeyWords: configuration management tools; comparison framework; CFEngine; Puppet; Ansible; Salt

“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”

 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
1. INTRODUCCIÓN
Cada día las personas se relacionan con
aplicaciones de software, tanto en el ámbito
personal como son las redes sociales para
comunicarnos con amistades, así como en el
ámbito profesional con servicios para la gestión de
los clientes de una organización. Estas aplicaciones
pueden estar alojadas en host físicos, entornos
virtualizados o incluso en la nube y a su vez estar
interconectadas para crear sistemas distribuidos de
gran escala. Para que funcione, el software
necesita ser puesto en marcha. Esto significa
instalar, configurar y mantener los recursos
necesarios para su explotación en producción.
Mientras estas acciones se ejecuten manualmente,
siempre se corre el riesgo de generar complejidad
innecesaria en el sistema, haciendo el
mantenimiento difícil y costoso. Siendo agravado
cuando se necesita escalar los servicios o hay que
mantener diferentes ecosistemas para el desarrollo
y pruebas de software. Desafortunadamente las
aplicaciones de software suelen fallar y el costo del
tiempo fuera de servicio aumenta con cada
segundo. Estos errores frecuentemente son
causados por problemas de configuración y cuando
se manejan sistemas distribuidos donde existen
dependencias entre los servicios, la probabilidad de
error aumenta drásticamente.
La configuración de las aplicaciones, está formada
por diversos parámetros que deben ser
consistentes en toda la configuración: desde los
parámetros de la aplicación final de usuarios hasta
los de configuración de red de la infraestructura.
Asimismo debe garantizarse que luego de cada
actualización de las configuraciones, estos
parámetros queden consistentes en aras de evitar
futuras fallas en el funcionamiento de las
aplicaciones.
Las herramientas de gestión de la configuración
(CMT) como Puppet y Chef fueron diseñadas para
resolver estas tareas de forma consistente y
confiable, haciendo el software fácil de configurar e
instalar, preparándolo para su modificación o
expansión.
Estas herramientas simplifican las tareas de gestión
de grandes y complejos despliegues manteniendo
los sistemas actualizados, reduciendo los costos de
operación. Su objetivo fundamental es la
automatización de la instalación, configuración,
actualización de software en un entorno dado.
Adicionalmente, pueden mantener un seguimiento
del estado y brindar una descripción del software
instalado.
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
Las CMT emplean las especificaciones de entrada
para modelar el estado deseado de la
configuración, incluyendo la interdependencia entre
los parámetros de configuración.
Algunos trabajos se han realizado en el área de las
pruebas de las especificaciones de entrada para
garantizar la consistencia de la configuración [1]-[4].
En la actualidad existen en el mercado varios
sistemas reconocidos que se pueden utilizar, sin
embargo como toda aplicación de software, la
adopción de uno específico implica una inversión
grande de tiempo y dinero. Por lo que hacer una
elección bien fundamentada sobre la base de
criterios objetivos es lo mejor para asegurarse que
la empresa va a adquirir la herramienta justa para
su entorno.
Pero, ¿cuáles pudieran ser estos criterios objetivos
en ausencia de expertos en el tema?
El objetivo de este trabajo consiste en seleccionar
esos criterios estableciendo un marco de
comparación y aplicarlo a cuatro de las CMT más
referenciados y populares [5]-[9]: CFEngine,
Puppet, Ansible y Salt.
El marco propuesto es un ajuste y actualización de
varios estudios previos sobre el tema.
El resultado del trabajo es útil para los
profesionales en la selección rápida de una CMT y
dando a conocer las características actualizadas de
cada una de ellas, sobre todo en el contexto
cubano con una limitada adopción de este tipo de
herramientas, aun cuando constituyen una mejora
sobre la continua explotación del scripting ad-hoc
que se ha empleado en las últimas dos décadas.
2. CONTENIDO
En los últimos tiempos con la popularidad de las
redes sociales, blog y demás plataformas de
comunicación, se suele realizar una búsqueda
rápida de los pros y contras para evaluar un
producto de software. Sin embargo estos resultados
suelen estar influenciados por los requerimientos y
experiencias individuales de los redactores quienes,
en determinados momentos pueden llegar a
contradecirse entre sí. Por lo que no es
recomendable tomar decisiones definitivas basadas
en estos resultados parciales.
Se hace necesario establecer las características a
considerar y cómo evaluarlas. En el ámbito de los
proyectos de código abierto podemos encontrarnos
con varios trabajos que proponen y analizan
metodologías de evaluación para estos tipos de
 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
proyectos [10][11] Pero como ningún método es
perfecto, frecuentemente sus criterios están siendo
revisados y actualizados.
Para la selección de los criterios específicos del
campo de aplicación tratado, se tuvieron en cuenta
en primera instancia estudios comparativos previos
[12], trabajos que introducen y caracterizan
diferentes alternativas de CMS [8][13],
presentaciones en eventos, documentaciones
oficiales de los productos, criterios de la comunidad
(blog, IRC, redes sociales, etc. ), entre otras fuentes
disponibles de los últimos cinco años. De igual
forma se tuvo en cuenta que en Cuba no se cuenta
con grandes compañías que empleen estos
sistemas, por lo que el reducido nivel de expertos
en el área llevó a descartar cualquier criterio
previamente empleado que dependa de la
validación por el criterio de expertos.
2.1 Criterios de comparación
Propiedades de la especificación
Algunos trabajos basados en la opinión de la
comunidad plantean como elementos esenciales a
tener en consideración el lenguaje para usar el
software [14] y si este es declarativo o imperativo
[15]. Adicionalmente se tiene en cuenta si la
herramienta brinda una interfaz de usuario para la
gestión de los recursos.
Un elemento a considerar es si la herramienta
provee de un mecanismo de modularización que
permita la reutilización del código escrito por los
desarrolladores y que este pueda ser empleado en
futuras tareas (por ejemplo: las recetas de Chef o
los roles de Ansible) y si cuenta con un repositorio
de estos elementos para socializar el conocimiento
(como Galaxy en Ansible).
Propiedades del despliegue
Delaet, Joosen y Vanbrabant [15] se refieren a la
escalabilidad como la habilidad de la CMT de
adaptarse a los cambios en el crecimiento de la
infraestructura. La herramienta debe ser capaz de
proveer la especificación de configuración
necesaria para estos grandes y complejos
entornos.
Aunque la mayoría de las herramientas analizadas
en el estudio comparten elementos de la
arquitectura de despliegues típica Figura 1,
consideramos necesario incluir este elemento en la
comparación, analizando: la arquitectura de los
agentes de traducción y la tecnología empleada
para distribuir las especificaciones (push o pull).
Es común encontrar variedad de plataformas en las
infraestructuras actuales: Windows/Unix/Mac OS X
servers; de igual forma podemos hallar la
necesidad de gestionar diversos dispositivos:
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
servidores, teléfonos inteligentes, equipamiento de
red, etc. Es por ello que considerar las plataformas
y dispositivos soportados aportan elementos para
evaluar cuán flexible es la CMT y cuántos sistemas
diferentes se pueden gestionar con el software
[14][15].
Propiedades de gestión
Figura 1 Arquitectura general de los CMT.
De los elementos para valorar la usabilidad
solamente se tienen en cuenta: si la herramienta
brinda soporte para probar las especificaciones
introducidas y si la herramienta provee algún
sistema o si cuenta con algún mecanismo para
monitorear el estado de la infraestructura actual.
La integración con el entorno ilustra la habilidad de
la herramienta de permitir a la especificación
creada utilizar información proveniente del entorno
de trabajo, por ejemplo adquirir los usuarios a partir
de un servidor LDAP.
Durante el empleo de estas herramientas suelen
presentarse conflictos en las definiciones como:
conflictos específicos de aplicación (ejemplo:
cuando se declaran varios servicios con el mismo
puerto en un host), conflictos de modalidad que son
contradicciones en la especificación de la
configuración.
El versionado de las especificaciones es un
elemento deseable en los sistemas que trabajan la
infraestructura como código, mediante el empleo de
sistemas de control de versiones (CVS). Estos
posibilitan el restablecimiento de los sistemas ante
fallos, así como el seguimiento de la evolución de
las especificaciones.
Las especificaciones para la configuración de las
infraestructuras usualmente son desarrolladas por
diferentes personas, por lo que es necesario tener
un control de acceso a los recursos que cada cual
puede configurar. Por esto se analizó la presencia
de mecanismos de autenticación y autorización.
Soporte
Una característica del soporte es la documentación
 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
disponible y dentro de esta, la documentación de
instalación; evaluando los prerrequisitos o cantidad
de elementos necesario a instalar para que
funcione, así como las formas de instalación
pueden dar una idea de cuán rápido pudiera ser la
puesta en marcha del nuevo sistema.
Un elemento deseable para viabilizar la evaluación
de un producto de software es que se provean
recursos para el mismo de forma tal que se
minimicen los esfuerzos de instalación y
configuración que en etapas de exploración
pudiesen incurrir en gasto de tiempo por la falta de
familiarización con los productos, para ello es
frecuente encontrar demos online, recursos de
Vagrant, recursos para un despliegue limitado en
un proveedor de servicios en la nube o máquinas
virtuales con los componentes instalados para
probar localmente.
Constar con una versión comercial del producto
usualmente brinda mayor confianza a la hora
seleccionar una alternativa, pues generalmente
estas vienen asociadas con un alto compromiso de
soporte técnico por parte de los creadores y
funcionalidades que no podemos encontrarnos en
las versiones de la comunidad. Adicionamos
entonces al análisis la presencia de versiones
comerciales del producto y sus funcionalidades
adicionales en comparación con la de la
comunidad.
La estabilidad de un proyecto depende de muchos
factores difíciles de medir cuando estamos
iniciándonos en un producto; sin embargo podemos
investigar sobre su política y frecuencia de
liberación para tener una idea al respecto.
Comunidad
Un elemento importante que buscamos en
productos de software es la comunidad que tiene
un proyecto. En presencia de una comunidad
grande es fácil resolver problemas, encontrar las
mejores prácticas, casos de uso exitoso de las
herramientas, etc. Por lo que se adicionó la
evaluación de la comunidad teniendo en
consideración: la cantidad de usuarios
contribuyentes del proyecto, la cantidad de
proyectos relacionados y los canales de
comunicación (blog, redes sociales, salas de chat,
foros) donde usualmente se publica información al
respecto.
Actualización
Para medir la actividad de actualización se tuvo en
cuenta: el tiempo transcurrido desde la última
actualización del producto y la cantidad de issues
resueltos en el primer semestre del año.
Popularidad
Usualmente cuando evaluamos un producto de
software buscamos la cantidad de usuarios y cuáles
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
son las compañías de referencia que emplean el
producto. Estos elementos muestran su
generalización en las diferentes organizaciones y si
sirve para grandes escenarios de despliegue
[14][16]. No obstante es difícil medir exactamente el
número de usuarios y despliegues, por lo que se
emplean otros criterios aproximados como el
número de usuarios en la lista de distribución y las
organizaciones que emplean el producto.
Adicionalmente se analizó la presencia en las redes
sociales teniendo en cuenta su actividad.
Licencias
Aunque todos los CMT que se evalúan en este
trabajo tienen una distribución de código abierto, es
interesante conocer bajo qué licencia específica se
distribuyen: MIT, GPL, LGPL, etc., criterio que ha
sido empleado por Torberntsson y Rydin [14].
Precio
El precio constituye un factor determinante en todo
producto a adquirir que usualmente varía en
dependencia de la cantidad de nodos a gestionar y
el soporte contratado, por lo que se tuvo en cuenta
el precio anual más bajo para 100 instancias con la
versión Empresarial, similar al trabajo de
Torberntsson y Rydin [14].
Lenguaje de desarrollo
El lenguaje de desarrollo de un software puede
afectar elementos como la comunidad y el
desempeño. Es común considerar que un software
desarrollado en un lenguaje muy popular tenga
mayor cantidad de contribuidores y seguidores. De
igual forma sucede con un software desarrollado en
C, debe tener mejor rendimiento que otro
desarrollado en un lenguaje a más alto nivel. Por
estas razones se agregó al estudio el lenguaje con
que es desarrollada la CMT.
A modo de resumen la Figura 1 muestra las
características que fueron seleccionadas para
conformar el marco de comparación.
Requerimientos de hardware
Para tener una idea de las prestaciones básicas
necesarias en la explotación de las CMT se
incluyeron los requerimientos de hardware mínimos
para el despliegue más básico de la distribución
empresarial.
2.2 Evaluaciones
2.2.1 CFEngine
CFEngine es una CMT que permite gestionar de
forma segura las infraestructuras de IT. Los
escenarios de usos son disimiles entre los que
podemos encontrar: verificación del contenido y la
integridad de archivos, despliegue de aplicaciones y
actualizaciones de sistemas.
 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
Su Design Center (DC) es ofrecido como el
repositorio público donde los miembros de su
comunidad pueden compartir código y patrones de
diseño. En la versión Empresarial se cuenta con el
Design Center UI que permite a los ingenieros de
infraestructura autorizados configurar, desplegar y
monitorear plantillas de políticas. El DC se
encuentra público en Github pero según las
estadísticas del repositorio no cuenta con mucha
actividad y en los últimos 6 meses ha estado
prácticamente inerte.
Figura 1: Criterios aplicados para el análisis de CMT.
De forma general si está preparado para grandes
despliegues incluso manteniendo la alta
disponibilidad de servicio mediante un pull de
servidores de políticas (configuraciones).
La arquitectura empleada es distribuida con el
énfasis en los agentes que se ejecutan en cada
host gestionado. El servidor central solo se emplea
para coordinar la distribución de las políticas.
Los clientes de CFEngine pueden trabajar como
clientes o como una estructura multinodo. Cuando
se opera como una estructura multinodo, algunos
clientes pueden ser configurados como servidor de
políticas y otros como simples clientes. Los clientes
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
contactan al servidor de políticas que son los
responsables de la distribución de las políticas. Una
política no es más que un conjunto de promesas
que a su vez son empleadas para describir el
estado deseado de un sistema.
Cuando el servidor de políticas ha publicado una
promesa los clientes pueden actualizarse
automáticamente. Cada nodo en una red de
CFEngine son actores independientes y trabajan de
forma oportunista que significa que incluso si un
servidor de políticas desaparece, se mantendrá en
funcionamiento haciendo lo que puede con la
información que tiene almacenada.
No está documentado el uso de herramientas
complementarias para la ejecución de pruebas de
las especificaciones, solo aparece una referencia
sobre la necesidad de hacer test de las políticas
antes de liberarlas en producción. No obstante
como parte del mecanismo de distribución de los
estados deseados, los agentes locales siempre
ejecutan una comprobación de sintaxis antes de
aplicar los cambios [17].
Soporta la gestión de conflictos detectando
conflictos de modalidad, como una configuración
inestable que no converge [12][18].
CFEngine cuenta dos versiones del producto: la
Empresarial recomendada para producción y la de
la Comunidad que fue la pionera en 1993.
Valoramos la actividad del proyecto cfengine/core
analizando los 12K commits, 210 releases y la
cantidad de issues resueltos cuya mayor actividad
se enmarca entre 2013 y finales del 2014, por lo
que se valoró como activo.
Su presencia en las redes sociales se mantiene
activa, con actividad en: Google+ con casi 100
seguidores y más de 13K visitas, junto a su canal
de YouTube que desde 2010 ha compartido más de
100 videos para sus 300 suscriptores. En el caso
de LinkedIn se puede encontrar junto a su sitio
oficial varios grupos que garantizan la constante
actualización de temáticas relacionadas con sus
funcionalidades y mejores prácticas. De igual forma
la actividad se mantiene en el caso de Twitter con
valores que superan los 2K tweet y 1K seguidores.
Por estas razones de clasifico como activo.
2.2.2 Puppet
Puppet Labs es uno de los líderes en la
automatización de IT desde sus inicios en 2005,
facilitando la automatización y gestión de los host y
sus softwares tanto en máquinas físicas como
virtuales en servidores dedicados o integrándose
con servicios en la nube. Puppet aparece como
proyecto de código abierto y a partir de este se
distribuye Puppet Enterprise (PE). PE es una
extensión de Puppet que incluye soporte
profesional, un stack de Puppet listo para
 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
producción, una consola web para analizar reportes
y controlar las infraestructuras, funcionalidades de
orquestación y herramientas para provisionar en la
nube.
El ecosistema de Puppet incluye decenas de
proyectos de código abierto que se emplean tanto
en la versión de la Comunidad como en la
Empresarial. Dentro de estos podemos encontrar
Geppeto que es un IDE para facilitar el desarrollo
en Puppet. Adicionalmente provee una interfaz:
Forge para crear proyectos desde módulos
preexistentes y facilitar su socialización en la
comunidad.
En la versión PE se incluye una interfaz web
llamada Console que permite analizar los
elementos de la infraestructura de forma
centralizada, ofreciendo una forma sencilla para
desplegar configuraciones y aplicaciones a los
servidores y dispositivos de red.
Adicionalmente Puppet cuenta con un repositorio
de módulos escritos por la comunidad llamado
Forge. Al publicarse un módulo, este puede ser
revisado y clasificación según su popularidad,
originalidad entre otros elementos aportados por la
comunidad. Como resultado el modulo se etiqueta
estableciendo su estabilidad y confiabilidad para el
empleo en producción.
Puppet está diseñado para funcionar en una
arquitectura cliente/servidor o de forma
independiente. En la primera todos los ficheros de
configuración con las “recetas” escritas en el
lenguaje declarativo son almacenados en el nodo
servidor denominado “Puppet Master”. Este nodo
central se encarga de muchas de las tareas como
analizar las recetas y compilarlas para generar
catálogos. Estos catálogos son conjuntos de
ficheros XML que serán recogidos por los clientes o
agentes. Los clientes solo se encargan de
implementar la funcionalidad requerida al comparar
los catálogos almacenados en su cache local con
los del servidor y finalmente reporta al servidor los
cambios realizados. El Master también puede
enviar notificaciones a los clientes en caso de que
los ficheros de configuración hayan cambiado para
hacer que el cliente obtenga los nuevos catálogos.
En la arquitectura independiente los nodos
administrados contienen la copia completa de su
información de configuración y compilan su propio
catalogo para luego en demanda o por un proceso
planificado aplicarlos.
Trabaja con gran variedad de plataformas,
anunciando para próximas entregas la ampliación
del soporte de los agentes en Mac OS, AIX, Solaris,
etc.
Se emplea para gestionar servidores pero es capaz
de trabajar sobre cualquier sistema que soporte la
instalación de los agentes. En las recientes
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
versiones ya se soporta el sistema operativo Cisco
NX-OS como plataforma para correr los agentes en
los switches de red. Inclusive algunos socios como
Huawei ya han incluido nativamente el soporte de
los agentes en sus dispositivos de red.
Puppet fue de los pioneros en facilitar el trabajo de
la Infraestructura como Código (IaC) y tiene
experiencia aplicando test sobre las infraestructuras
[7]. Por ejemplo para que un módulo de Forge esté
listo para producción es requerido su verificación en
PE asegurando el estilo de la sintaxis con Puppet-
lint, pasar los test unitarios con rspec-puppet y
realizar test de aceptación con Beaker framework.
Considerando estos elementos junto a la facilidad
para trabajar varios entornos podemos decir que
tiene soporte para test de especificaciones.
Para la integración con un CVS hay algunas
referencias donde abordan como emplear Git para
trabajar con Puppet, incluso el IDE Geppeto permite
trabajar con los módulos de la comunidad e
integrarlos con Git para su provisionamiento en PE.
Para valorar actividad del proyecto
puppetlabs/Puppet se contó con los 20K commits,
301 releases y la cantidad de issues resueltos que
se ha mantenido bastante alta desde finales del
2011, por lo que es un proyecto muy activo.
Mantiene cuentas en las redes sociales como
Google+ con más de 2K seguidores y 60K visitas,
junto a su canal de YouTube creado en el 2011 con
+500 videos compartidos para más de 7K
suscriptores. En el caso de LinkedIn se puede
encontrar junto a su sitio oficial varios grupos en los
que se comparten experiencias de desarrollo y
administración. Esta actividad se mantiene en
Twitter con valores que superan los 8K tweet y
53.6K seguidores. Por estas razones se clasificó
como muy activo.
2.2.3 Ansible
Ansible es una de las más recientes herramientas
de automatización de IT, dentro de sus uso
podemos encontrar la automatización del
aprovisionamiento en la nube, la gestión de la
configuración, el despliegue de aplicaciones y la
orquestación de servicios y sus interdependencias.
Ansible Tower es su distribución comercial
recomendada para el contexto empresarial. Es una
interfaz web que permite centralizar y controlar las
infraestructuras incluyendo: un dashboard, control
de acceso basado en roles, planificación de
trabajos y la gestión visual de los inventarios;
simplificando la creación de nuevos entornos,
permitiendo a desarrolladores establecer fácilmente
sus entornos para QA y Test amend de la
intervención del personal de Ops. Incluso el propio
personal comercial podría establecer en demanda
entornos para demos.
 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
Cuenta con roles y playbook. Los roles son la
agrupación de un conjunto de tareas, variables,
plantillas para lograr un fin específico y los playbook
son los que permiten representar el conjunto de
pasos o roles a seguir/aplicar en la infraestructura
gestionada con Ansible.
Los roles en Ansible son construidos en aras de
incluir ficheros y combinarlos de forma clara,
reusable que nos permitan abstraernos y
enfocarnos en la idea general y solo profundizar en
los detalles de implementación cuando sea
necesario.
Los roles pueden ser compartidos a la comunidad
mediante Galaxy que es el sitio web para compartir
roles o herramientas de línea de comandos creadas
para ayudar a trabajar con los roles.
Ansible trabaja sin contar con un agente instalado
en cada host, evitando la necesidad de mantener
actualizado estos agentes y pudiendo resolver el
impedimento de gestionar host donde no existen los
agentes instalados. Ansible es descentralizado
delegando el control de acceso a las credenciales
del OS a administrar o integrándose a sistemas de
gestión centralizada de usuarios.
Su versatilidad le permite su aplicación en gran
variedad de dispositivos, incluso dentro de sus
socios hay proveedores de dispositivos de red
como CISCO y Juniper Networks.
Ansible está diseñado para ser fail-fast, sin
embargo se plantea que existen diferentes formas
de plantear test con su sintaxis. Aplicando estos
mecanismos de pruebas en las diferentes etapas
de desarrollo local, QA y producción podemos
reducir los riesgos en los entornos reales de
producción. Existen diferentes formas de trabajo
para los test, pero la esencia es siempre ejecutar
los mismos playbook en desarrollo, QA y
producción.
Usualmente se liberan nuevas versiones cada dos
meses. La aplicación principal se desarrolla
conservadoramente valorando la simplicidad en el
diseño del lenguaje y la configuración. Sin
embargo, el desarrollo de la comunidad alrededor
de nuevos módulos y plugins ocurre rápidamente,
añadiendo 20 o más módulos en cada entrega.
Cuenta con un servicio de consultoría y
entrenamiento, mediante el que especialistas
pueden revisar los contenidos y configuraciones de
Ansible y Tower instalados haciendo
recomendaciones para futuros proyectos; ayudando
en el proceso de migración desde otros CMT o
soluciones locales. También cuenta con un sitio
destinado al soporte en el que se organizan las
respuestas a preguntas frecuentes.
Tower se ofrece en diferentes ediciones: Básica,
Empresarial y Premium diferenciándose respecto al
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
soporte en el tiempo de atención, las vías de
comunicación y el tiempo de respuesta según el
tipo de problema reportado.
La actividad del proyecto ansible/ansible se
evidencia con los 16K commits, 81 releases y la
cantidad de issues resueltos que se ha mantenido
alta desde principios del 2013, por lo que se valora
como muy activo.
Mantiene cuentas en las redes sociales como
Google+ con más de 625 seguidores y más de 42K
vistas, junto a su canal de YouTube con muy pocos
videos compartidos para alrededor de 600
suscriptores. En el caso de LinkedIn se puede
encontrar junto a su sitio oficial varios grupos en
diferentes localidades. Pero donde se evidencia
una gran actividad es en Twitter con cifras
superiores a los 6K tweet y 12K seguidores. Por
estas razones de clasificó como activo.
2.2.4 Salt
SaltStack es una de las herramientas para
desplegar y orquestar infraestructuras de nube,
optimizar la configuración de sistemas y controlar
una vasta cantidad de entornos como: VMware,
OpenStack, Google Compute Engine, AWS,
Docker, etc.
SaltStack es comúnmente empleado para
desplegar, gestionar y automatizar infraestructuras
y aplicaciones para big data, IoT, storages
dinámicos, redes definidas por software, servidores
de seguridad, etc.
Ha sido acreedora de varios premios en los últimos
años en competencias y eventos relacionados con
la gestión de virtualización, entornos de nube y big
data, siendo un referente en las mejores prácticas
de DevOps y herramienta de gestión de la nube.
En la próxima versión empresarial han anunciado la
incorporación de una GUI siguiendo los pasos de
su competencia.
Para la modularización cuenta con módulos y
fórmulas que permiten representar la configuración,
despliegue y orquestación de los host.
Adicionalmente mantiene público en github una
colección de fórmulas y además cuenta con un
gestor de fórmulas Salt Package Manager (SPM)
que permite construir y desplegarlas de forma
sencilla y análoga a los sistemas de empaquetado
como Yum o RPM.
Una de sus ventajas es que soporta ambos
mecanismos de distribución (push y pull) según
sean las necesidades del cliente. Cuenta con
diferentes componentes desde los que podemos
ejecutar las acciones remotamente sobre los nodos
administrados o distribuir los cambios mediante
aplicaciones instaladas previamente en los nodos a
gestionar.
 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”

Salt emplea dos enfoques de prueba: pruebas de servicio de certificación.

integración y pruebas unitarias, para las que provee Los requerimientos de hardware no aparecen
bibliotecas en aras de minimizar las pruebas oficialmente, no obstante se menciona que requiere
manuales. pocos recursos y deben ser afinados en
Salt permite trabajar por entornos de trabajo dependencia de la cantidad de nodos y tareas
quedando agrupados sus archivos por estos concurrentes que se quiera realizar.
entornos. Esta estructura de archivos puede La actividad del proyecto saltstack/salt se evidencia
integrarse con diferentes CVS para que los minions con más de 50K commits, 101 releases y la
(agentes instalados en los host) los empleen como cantidad de issues resueltos desde los inicios que
código fuente. ha ido en ascenso, por lo que lo estimamos como
Cuenta con una detallada guía para probar las muy activo.
funcionalidades básicas de las herramientas de su Mantiene cuentas en las redes sociales como
arquitectura, incluyendo para ello un proyecto en Google+ con más de 600 seguidores y más de
github con el Vagrantfile necesario para probar el 115K visitas, junto a su canal de YouTube con 82
despliegue de un master y 2 minions. videos compartidos para alrededor de 115K
La licencia de la versión Empresarial se basa en la suscriptores. En el caso de LinkedIn se puede
cantidad de nodos y la suscripción del soporte en encontrar junto a su sitio oficial algunos grupos
dependencia del entorno y la infraestructura. relacionados. La actividad en Twitter se mantiene
Brindando siempre un soporte exclusivo y activa con cifra superiores a los 2K tweet y 6K
priorizado con expertos. Adicionalmente cuenta con seguidores. Por estas razones se clasificó como
servicios de consulta y entrenamiento que pueden muy activo.
ser incluidos en el contrato de soporte e incluso un
Tabla I: Comparación de las CMT seleccionadas
CFEngine Puppet Ansible Salt
Propiedades de la especificación
Tipo de lenguaje declarativo declarativo, imperativo declarativo declarativo
Interfaz de usuario CLI, Web CLI, Web CLI, Web CLI
Mecanismo de modularización si/Design Center si/Forge si/Galaxy si
Propiedades del despliegue
pequeños-medios-
Escalabilidad medios-grandes medios-grandes pequeños-medios
grandes
Agentes de
Arquitectura Gestión distribuida Gestión centralizada Gestión centralizada Gestión centralizada
traducción
de
Mecanismo de
despliegue pull pull push push, pull
distribución
Red Hat Enterprise
Linux, CentOS, Oracle Plataformas Unix con
CentOS, Debian, Plataformas con Python
Servidores Linux, Scientific Linux, Python 2.6 o superior e
RHEL, Ubuntu 2.6 o 2.7 (no Windows).
SUSE Linux Enterprise inferior a 3.0
Plataformas

Server, Ubuntu
Flexibilidad

Red Hat Enterprise

AIX, CentOS, Debian, Linux, CentOS, Oracle
Plataformas con Python
UP-UX, RHEL, SLES, Linux, Scientific Linux, plataformas Unix o
Clientes 2.4 o superior e
Solaris, Ubuntu, SUSE Linux Enterprise Windows
inferiores a 3.0
Windows Server, Ubuntu, Debian,
Windows
Dispositivos host host, dispositivos de red host, dispositivos de red host, dispositivos de red
Propiedades de gestión
Puppet-lint, rspec- Manual, componentes
Usabilidad

Soporte para test de Manual, comprobación Manual, comprobación

puppet, Beaker para test de integración
especificación de sintaxis de sintaxis
framework y unitario
Monitoreo de la
si si si si
infraestructura
Integración con el entorno Características de los host administrados durante la ejecución
Resolución de conflictos Conflictos de modalidad Conflictos de modalidad NE NE
Soporte para CVS si/Repositorio externo
Control de acceso Autenticación integrable con recursos externos y Autorización

“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”

 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”

CFEngine Puppet Ansible Salt

Soporte
Documentación disponible
Documentación de instalación
Formas de instalación
Elementos para instalación
Hasta 25 nodos versión
Recursos para evaluar producto
Frecuencia/ Política de
liberación
Funcionalidades adicionales de
la versión comercial
documentación, referencias, tutoriales, presentaciones, videos
web web web + pdf(para Tower) Web + pdf
repo, script, manual o repo, manual, script
repo, script, manual repo, manual, script
Vagrant wizard para Tower
python-simplejson, msgpack-python, YAML,
Puppet Master,
Instalador del servidor Ansible Core, Ansible Jinja2, MarkupSafe,
PuppetDB y
de políticas y el de los Tower, libselinux- apache-libcloud,
PostgreSQL, Console,
clientes. python(si está habilitado Requests, ZeroMQ o
Agents
SELinux) RAET
máquina virtual de
Tower con Vagrant y Vagrant para prueba de
Empresarial con prueba hasta 10 nodos,
recursos para AWS un master con 2 nodos
Vagrant cursos online
2 x año/LTS NE cada 2 meses NE
GUI con dashboards para monitoreo de estado de los host, alertas, inventario y planificación de tareas.

Comunidad
Contribuidores 73 398 1156 1248
Proyectos relacionados <10 >2116 <15 <40
Actividad del proyecto activo muy activo muy activo muy activo
Redes sociales, IRC,
Redes sociales, IRC, Redes sociales, IRC,
Redes sociales, IRC, Newsletter, RSS,
Newsletter, RSS, Newsletter, RSS,
Canales de comunicación Newsletter, RSS, Youtube, grupos de
Youtube, grupos de grupos de google,
Youtube google, Puppet Ask,
google Youtube, Reddit
Reddit,
Actualización
Tiempo desde la última entrega <6 meses <6 meses <6 meses <6 meses
Issues resueltos 1er semestre 211 de 238 729 de 763 926 de 1290 1441 de 2730
Año de creación 1993 2005 2012 2011
Popularidad
Usuarios/Temas de la lista de
712/6070 8181/14527 5234/7070 3234/5252
distribución
LinkedIn, NASA JPL,
SONY, redhat, Twitter, Departamento de
Intel, Linkedin, Evernote, Universidad
SUN Oracle, Motorola, Defensa de los E.U,
Clientes SAMSUNG,Chevron, de Hardvard, Verizon,
Empresas de WMWare, github, Intel, Universidades de
Comcast, DIRECTV Twitter
referencia at&t, NESTLE Columbia y Hardvard,
Rakspace, Salesforce
IBM, Cisco, Amazon, VMWare, redhat, redhat,VMWare, Cisco,
Socios NE
Microsoft, HP, VMWare RackSpace, mas de 50 HP
Presencia en redes sociales Activo Muy Activo Activo Muy activo
Tipo de Licencia GPL v3,0 Apache License v2.0 GPL v3,0 Apache License v2.0
Precio Negociar con proveedor $10500 $5000 Negociar con proveedor
Lenguaje de desarrollo C 95% Ruby 97% Python 89,4% Python 97.6%
12núcleos, 2GRAM, 4 núcleos, 16GB RAM,
Servidor 4GB RAM, 20G Disco NE
100MB Disco x agente 142G Disco
Requerimientos
256MB RAM, 100MB
de hardware
Cliente Disco o 1G para NE NE NE
Windows
NE: no especificado oficialmente.

“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”

 Carbonell, E.; García, A. | “COMPARACIÓN DE HERRAMIENTAS DE GESTIÓN DE LA CONFIGURACIÓN”
3. CONCLUSIONES
Este trabajo permitió conformar un marco de
comparación basado en un conjunto de
características aplicables a las CMT, para de forma
sencilla y rápida poder conformar una descripción
general que caracterice este tipo de productos en
ausencia de expertos en el tema. El marco
establece una comparación entre cuatro de las
CMT más populares permitiendo a un usuario no
experto tomar en consideración los aspectos
planteados en el mismo para seleccionar la
herramienta que sea la más adecuada a las
necesidades de empresas e instituciones de
pequeña, media y gran escala.
4. REFERENCIAS BIBLIOGRÁFICAS
1. W. Hummer, F. Rosenberg, F. Oliveira, and
T. Eilam: “Testing idempotence for infrastructure as
code,” en Middleware 2013, Springer, 2013, pp.
368–388.
2. S. Nelson-Smith: “Test Driven Infrastructure
with Chef”, Segunda Edición, O’Reilly Media Inc.,
2014.
3. M. Burgess: “Testable system
administration,” Communications of the ACM, Vol.
54, No. 3, pp. 44 - 49, 2011.
4. B. Siebert, M. van Eekelen, y J. Visser:
“Evaluating the testing quality of software defined
infrastructures”, Thesis, Radboud University
Nijmegen, 2014.
5. J. Humble y D. Farley: “Continuous delivery:
reliable software releases through build, test, and
deployment automation”, 2010.
6. “Sysadmin & Security Salary and Skill Report”,
2015.
7. M. Hüttermann: “DevOps for developers:
integrate development and operations, the agile
way”, 2012.
8. C. Delettre: “Plateforme ouverte, évolutive,
sécurisée et orientée utilisateur pour l’e-commerce,”
Universidad Nice Sophia Antipolis. Escuela Doctoral
de Ciencias y Tecnologías de la Información y la
Comunicación (STIC), 2014.
9. D. Spinellis: “Don’t Install Software by Hand”,
IEE Computer Society, 2012.
10. D. A. Wheeler, “How to evaluate open
source software/free software (OSS/FS) programs”,
[Online]:
http://www.dwheeler.com/oss_fs_eval.html, 2011
11. K. Stol y M. Ali Babar: “A Comparison
Framework for Open Source Software Evaluation
Methods”, Libro: “Open Source Software: New
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”
Horizons”, pp. 389-394, 2010
12. J. Rahman: “Investigating Configuration
Management Tools Usage in Large Infrastructure”,
Tesis de maestría en la Universidad de OSLO,
2012
13. M. Caballer Fernández: “Gestión de
infraestructuras virtuales configuradas
dinámicamente”, Tesis doctoral en la Universidad
Politécnica de Valencia, 2014.
14. K. Torberntsson y Y. Rydin: “A Study of
Configuration Management Systems: Solutions for
Deployment and Configuration of Software in a
Cloud Environment”, 2014.
15. T. Delaet, W. Joosen, y B. Vanbrabant: “A
survey of system configuration tools”, 2010.
16. S. Pandey: “Investigating Community,
Reliability and Usability of CFEngine, Chef and
Puppet”, Tesis en la Universidad de Oslo, 2012.
17. A. Chandrasekar y G. Gibson: “A
Comparative Study of Baremetal Provisioning
Frameworks”, 2014.
18. B. Vanbrabant: “A framework for integrated
configuration management of distributed systems”,
Tesis doctoral en Universidad de KU Leuven, 2014.
5. SÍNTESIS CURRICULARES DE LOS
AUTORES
Enrique Carbonell Muela. Licenciado en Ciencias de la
Computación, graduado con honores en la Universidad Central de
Las Villas (UCLV, 2010). Se incorporó a trabajar en DATYS en
septiembre del 2010 donde ha trabajado en diferentes roles:
desarrollador de software, líder de un equipo de desarrollo y
actualmente se desempeña como DevOps Engineer en el equipo
de infraestructura y operaciones. Es miembro de la Unión de
Informáticos de Cuba y estudiante de la Maestría en Ciencias de La
Computación de la UCLV en su 11na edición.
Ana María García Pérez. Licenciada en Cibernética-Matemática de
la Universidad Central de Las Villas (UCLV, 1982). Profesora Titular.
Doctora en Ciencias Técnicas del Instituto Superior Politécnico
José Antonio Echevarría (CUJAE, 1997). Miembro del Comité
Académico de la Maestría en Ciencia de la Computación de la
UCLV y del Comité Académico de la Maestría en Gestión de
Proyectos de la Universidad de las Ciencias Informáticas (UCI).
Jefe de la Carrera Ciencia de la Computación de la UCLV (1995–
2009). Ha dictado pre y postgrado como profesora invitada en
varias universidades latinoamericanas, entre ellas: Universidad de
Antioquia de Medellín, Colombia, UPC de Lima, Perú, Universidad
de Guadalajara, México, Centro Universitario de la Ciénega de
Ocotlán, Jalisco, México, Universidad Católica de Santa María de
Arequipa, Perú y la Universidad de Managua, Nicaragua. Jefe del
Grupo Científico de Programación e Ingeniería de Software del
Centro de Estudios de Informática de la UCLV (2000 – 2008).
Miembro del Comité de Editores de la Revista Cubana de Ciencias
Informáticas (RCCI). Revisora de la revista ACIMED, Revista
Cubana de Investigaciones en Ciencias de la Salud. Pertenece al
CTN 18 de la ONN de Cuba para las normas cubanas del software
siendo coautora de 4 normas ya registradas. Actualmente es Sub
Directora Comercial de la División Territorial DESOFT Villa Clara.
“IV Taller Internacional Las TIC en la Gestión de las Organizaciones”