3.3 CONSTRUCCIÓN DEL SISTEMA.

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

completo al compilar y vincular los componentes del sistema, librerías externas,
archivos de configuración, etcétera.
Las herramientas de este y las de gestión diversiones deben comunicarse, puesto
que 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.

La construcción es un proceso complejo, donde suelen ocurrir errores, ya que hay

tres diferentes plataformas de sistema que pueden estar implicadas:

1. Sistema de desarrollo: incluye herramientas de desarrollo, como los

compiladores, 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 mucho antes de hacer cambios al sistema. Tal vez quieran construir
una versión del sistema para probarla en su entorno de desarrollo antes de
aplicar los cambios que hicieron ante el sistema de gestión de versiones.
Esto supone usar herramientas de construcción locales que usan versiones
de componentes sacadas en el espacio de trabajo privado.
2. Servidor de construcción: usado para construir versiones ejecutables
definitivas del sistema. Éste interactúa estrechamente con el sistema de
gestión de versiones. Los desarrolladores ingresan código a este sistema
antes de que se construya. La elaboración del sistema puede depender de
librerías externas que no se incluyen en el sistema de gestión de versiones.
3. Entorno objetivo: plataforma donde se ejecuta el sistema. Éste puede ser
el mismo tipo de computadora que se usó para los sistemas de desarrollo y
construcción. Sin embargo, para sistemas embebidos y de tiempo real, el
entorno objetivo con frecuencia es más pequeño y sencillo que el entorno de
desarrollo. Para sistemas grandes, el entorno objetivo puede incluir bases de
datos y otros sistemas COTS que no pueden instalarse en máquinas
 desarrollo. En ambos casos, no es posible construir y probar el sistema en la
computadora de desarrollo o en el servidor de construcción.

Para sistemas embebidos puede instalarse un entorno de simulación en el entorno

de desarrollo para pruebas, en vez de usar la plataforma de sistema embebido real.
Dichos simuladores pueden ofrecer mejor soporte de depuración que el disponible
en un sistema embebido. Sin embargo, es muy difícil simular el comportamiento de
un sistema embebido en todos los aspectos. Por lo tanto, las pruebas del sistema
se deben realizar en la plataforma real donde se ejecutará el sistema, así como en
el simulador del sistema.

La construcción del sistema implica ensamblar una gran cantidad de información

acerca del software y su entorno operacional. Entonces, para cualquier sistema
aparte de los pequeños, siempre tiene sentido usar una herramienta de construcción
automatizada para crear una construcción del sistema.

Puede observar que no sólo necesita los archivos del codigo fuente implicado
en la construcción, sino tal vez se deban vincular dichos archivos, archivos
de datos (como un archivo de mensajes de error) y archivos de configuración
proporcionados externamente que definan la instalación objetivo.

Existe una gran cantidad de herramientas de construcción disponibles, y un sistema

de construcción ofrece algunas características o todas ellas:

1. Generación de rutinas (scripts) de construcción: Si es necesario, el

sistema de construcción debe analizar el programa en construcción,
identificar los componentes dependientes y generar automáticamente una
rutina de construcción (llamado algunas veces archivo de configuración).
2. Integración del sistema de gestión de versiones: El sistema de
construcción debe sacar las versiones de componentes requeridas del
sistema de gestión de versiones.
3. Recopilación mínima: El sistema de construcción debe establecer qué
código fuente necesita volver a compilarse y establecer las compilaciones si
así se requiere.
4. Creación de sistema ejecutable: El sistema de construcción debe vincular
los archivos de código de objeto compilado entre sí y con otros archivos
 requeridos, como las librerías y los archivos de configuración, para crear un
sistema ejecutable.
5. Automatización de pruebas: Algunos sistemas de construcción pueden
efectuar pruebas automatizadas utilizando herramientas de automatización
de pruebas como JUnit. Éstas comprueban que la construcción no se haya
“roto” por los cambios.
6. Informes: El sistema de construcción debe ofrecer informes sobre el éxito o
fracaso de la construcción y las pruebas que se efectuaron.
7. Generación de documentación: El sistema de construcción puede generar
notas referentes a las páginas de ayuda de la construcción y del sistema.

La rutina de construcción incluye la especificación de la configuración, de manera

que el lenguaje de escritura de rutinas utilizado generalmente es el mismo que el
lenguaje de descripción de la configuración. El lenguaje de configuración incluye
sentencias para describir los componentes del sistema a incluir en la construcción
y sus dependencias.
Puesto que la compilación es un proceso de cómputo intensivo, las herramientas
para soportar la construcción de sistemas se diseñan por lo general para minimizar
la cantidad de compilación que se requiere. Esto se hace comprobando si está
disponible una versión compilada de un componente. De ser así, no hay necesidad
de volver a compilar dicho componente.
La forma en que se hace esto es asociar una firma única con cada archivo donde
se almacene un componente del código fuente. El código objeto correspondiente,
que se compiló a partir del código fuente, tiene una firma relacionada que identifica
cada versión del código fuente y cambia cuando éste se edita. Al comparar las
firmas en los archivos de código fuente y objeto, es posible decidir si el componente
del código fuente se usó para generar el componente de código objeto.

Hay dos tipos de firmas que pueden usarse:

1. Modificación de marca de tiempo (timestamp0:) La firma en el archivo del
código fuente es la fecha y hora de cuándo éste se modificó. Si el archivo del
código fuente de un componente se modifica después del archivo del código
objeto relacionado, entonces el sistema supone que se requiere
“recopilación” para crear un nuevo archivo del código objeto.
2. Sumas de verificación (checksums) de código fuente: La firma en el
archivo del código fuente es una suma de verificación calculada a partir de
datos en el archivo. Una función checksum calcula un número único usando
el texto fuente como entrada. Si se modifica el código fuente (incluso por un
carácter), esto generará una suma diferente. La suma de verificación se
asigna al código fuente justo antes de la compilación e identifica de manera
exclusiva el archivo fuente. Entonces el sistema de construcción etiqueta el
archivo de código objeto generado con la firma checksum. Si no hay archivo
de código objeto con la misma firma que el archivo de código fuente a incluir
en un sistema, entonces es necesario recompilar el código fuente.

El enfoque checksum tiene la ventaja de permitir muchas versiones diferentes del

código objeto de un componente para mantenerse al mismo tiempo. La firma es el
vínculo entre el código fuente y objeto. Los archivos de código fuente y de código
objeto tienen la misma firma. Por lo tanto, cuando se recompila un componente, no
sobrescribe el código objeto, como sería normalmente el caso cuando se usa
timestamp. En vez de ello, genera un nuevo archivo de código objeto y lo etiqueta
con la firma del código fuente.

Los métodos ágiles recomiendan que los componentes de sistema muy frecuentes
deben realizarse con pruebas automatizadas (pruebas de humo) para descubrir
problemas del software. Los componentes frecuentes pueden ser parte de un
proceso de integración continua:

Pasos de la integración continua:

1. Sacar la línea principal del sistema de gestión de versiones hacia el espacio

de trabajo privado del desarrollador.
2. Construir el sistema y efectúe pruebas automatizadas para garantizar que el
sistema construido pasa todas las pruebas. Si no lo hace, la construcción se
descompone y hay que informar a quienquiera que ingrese al último sistema
línea base (baseline). Ellos son responsables de reparar el problema.
3. Realizar los cambios a los componentes del sistema.
4. Construir el sistema en el espacio de trabajo privado y vuelva a efectuar las
pruebas del sistema. Si las pruebas fallan, continúe la edición.
5. Una vez que el sistema pasa sus pruebas, ingresar en el sistema de
construcción, pero no confirme como una línea base nueva del sistema.
6. Construir el sistema en el servidor de construcción y efectúe las pruebas.
Necesita hacer esto en caso de que otros hayan modificado componentes
luego de que usted los sacó del sistema. Si éste es el caso, saque el
componente que falló y edítelo de modo que las pruebas pasen en su espacio
de trabajo privado.
 7. Si el sistema pasa sus pruebas en el sistema de construcción, confirmar
entonces los cambios que hizo como una nueva línea base en la línea
principal del sistema.

El sistema más reciente en la línea principal es el sistema funcional definitivo. Sin

embargo, aunque la integración continua es una buena idea, no siempre es posible
implementar este enfoque a la construcción del sistema.

Las razones para esto son:

1. Si el sistema es muy grande, puede tardar mucho tiempo construir y probar.

Por lo tanto, no es práctico construir muchas veces al día dicho sistema.
2. Si la plataforma de desarrollo es diferente de la plataforma objetivo, tal vez
no sea posible efectuar pruebas del sistema en el espacio de trabajo privado.
Puede haber diferencias en el hardware, el sistema operativo o el software
instalado. Por consiguiente, se requiere más tiempo para probar el sistema.

Para sistemas grandes o sistemas donde la plataforma de ejecución no es la misma

que la plataforma de desarrollo, la integración continua quizá no sea práctica. Ante
tales circunstancias se puede usar un sistema que se construya diariamente.

Características de esto:
1. La organización de desarrollo establece un tiempo de entrega (por ejemplo,
2 P.M.) para los componentes del sistema. Si los desarrolladores tienen
nuevas versiones de los componentes que escriben, deben entregarlas en
ese plazo. Los componentes pueden estar incompletos, pero deben ofrecer
alguna funcionalidad básica que pueda ponerse a prueba.
2. A partir de dichos componentes se crea una nueva versión del sistema al
compilarlos y vincularlos para formar un sistema completo.
3. Entonces este sistema se entrega al equipo de pruebas, que realiza un
conjunto de pruebas de sistema predefinidas. Al mismo tiempo, los
desarrolladores todavía trabajan en sus componentes, añaden funcionalidad
y reparan las fallas descubiertas en pruebas anteriores.
4. Las fallas que se descubren durante las pruebas del sistema se documentan
y regresan a los desarrolladores del sistema, quienes reparan dichas fallas
en una versión posterior del componente.

Las ventajas de usar componentes frecuentes de software son que aumentan las
posibilidades de descubrir de manera oportuna durante el proceso los problemas
que surgen a partir de las interacciones de los componentes.

Libro: ingeniería de software 9 edicion. Ian Sommerville

Libro: Ingernieria de software Sexta edición. Roger. Pressman