Ingeniería del Software II

SIS - 312
Gustavo Palabral
 “No hay nada permanente, excepto el cambio.”
Heraclito

ADMINISTRACIÓN DE
LA CONFIGURACIÓN
DEL SOFTWARE
 Administración de la Configuración
del Software
—  El cambio es inevitable en un sistema software. Cada
cambio involucra confusión entre los miembros del
equipo.
—  La confusión surge cuando los cambios no son
analizados, registrados antes que sean
implementados, reportados a los involucrados y
controlados de manera que incremente la calidad y
reduzcan los errores.
—  La Administración de Cambios (Software Configuration
Management - SCM) es una actividad paraguas que se
aplica a través del proceso de software, se ocupa de
las políticas, procesos y herramientas para
administración del cambio del software.
 Administración de la Configuración
del Software
—  Debido a que el software cambia con frecuencia, los
sistemas se pueden considerar como un conjunto de
versiones, cada una de las cuales tiene que ser
mantenida y administrada.
—  Las versiones implementan:
◦  Propuestas de cambio
◦  Correcciones de errores
◦  Adaptaciones para diferentes sistemas operativos y
hardware.
—  La SCM es necesaria porque es fácil perder el
seguimiento a los cambios y versiones de
componentes han sido incorporados en cada versión
del sistema.
 Administración de la Configuración
del Software
—  La información que se genera de un proceso de software se
puede dividir en tres categorías:
◦  Programas (a nivel de código fuente y formato ejecutable)
◦  Productos que describen los programas (a nivel técnico y
a nivel de descripción de funcionalidad)
◦  Datos (contenida dentro los programas o externa a los
programas).
—  A esta información se le conoce como Configuración del
Software.
—  La primera Ley de la Ingeniería de Sistemas dice: “No
importa en que momento del ciclo de vida del sistema te
encuentres, el sistema cambiara, y el deseo de cambio
persistirá a través de todo el ciclo”
 Administración de la Configuración
del Software
—  El cambio puede ocurrir en cualquier momento,
por cualquier razón.
—  Cual es el origen de estos cambios?
◦  Nuevas condiciones de negocio y mercado dictan los
cambios en los requerimientos de l producto o las
reglas del negocio.
◦  Nuevas necesidades de los clientes demandan las
modificación de los datos producidos por los sistemas,
la funcionalidad o los servicios de los productos.
◦  Reorganización del negocio ( + / - ) causan cambios en
las prioridades de los proyectos.
◦  Restricciones de planificación o presupuesto causan
redefinición del sistema o del producto.
Actividades de la SCM
—  Administración de Cambios:
Seguimiento a las peticiones de cambios
por parte de los clientes, costos e
impacto de los mismos.
—  Administración de Versiones:
Seguimiento de las múltiples versiones de
los componentes del sistema, con el
objetivo de asegurar que los cambios a
los componentes no interfieran entre si.
Actividades de la SCM
—  Construcción del Sistema: El proceso de
ensamblado de los componentes, datos y
librerías con el objetivo de compilarlos y
crear el sistema ejecutable.
—  Administración del Release:
Preparación del software para una
entrega externa y realizar el seguimiento
de la versión que ha sido entregada al
cliente.
 Terminología de SCM
Termino Descripción
Ítem de Cualquier objeto asociado a un proyecto software que esta bajo control de
Configuración configuración. Existen diferentes versiones de un ítem de configuración,
estos ítem tiene un único nombre.
Control de la El proceso de asegurar que las versiones de los sistemas y los
Configuración componentes están registrados y mantenidos de forma que los cambios
sean manejados y todas las versiones de los componentes sean
identificados y almacenados por todo el ciclo de vida del sistema
Versión Una instancia de un ítem de configuración que difiere de alguna forma con
otras instancias de ese ítem. Las versiones deben tener un único
identificador que debe estar compuesto del nombre del ítem mas un
numero de versión.
Baseline Es una colección de versiones de componentes que conforman un sistema.
(Línea Base) Los baselines están controlados, lo que significa que las versiones de los
componentes no pueden cambiar. Siempre debe ser posible recrear o
reconstruir una línea base desde sus componentes constituyentes.
Codeline Un codeline es un conjunto de versiones de un componente software y otros
ítems de configuración de los que depende el componente.
 Terminología de SCM
Termino Descripción
Mainline Una secuencia de baselines que representan las diferentes versiones del sistema.
Release Una versión de un sistema que ha sido liberado a los usuarios para su uso y
explotación.

Workspace Un área de trabajo privada donde el software puede ser modificado sin afectar a
(Ambiente de otro miembros del equipo que pueden también estar modificando el software
trabajo)

Branching La creación de un nuevo codeline a partir de una versión en un codeline

(Rama) existente. El codeline nuevo y el codeline existente pueden desarrollarse
independientemente
Merging La creación de una nueva versión de un componente mediante la combinación de
(Combinación) versiones separadas en diferentes codelines. Estos codelines pueden haber sido
creados desde una rama (branch) anterior de uno de los codelines involucrados.

Construcción La creación de una versión del sistema ejecutable mediante la compilación y

del sistema enlace de versiones apropiadas de los componentes y librerías que componen el
(Building) sistema.
ADMINISTRACIÓN DEL
CAMBIO
 Administración del cambio
—  Las necesidades y requisitos de la organización cambian
durante la vida útil de un sistema, los errores tienen que
ser reparados y los sistemas tienen que adaptarse a los
cambios en su entorno.
—  La gestión del cambio tiene por objeto garantizar que la
evolución del sistema sea un proceso administrado y que
se dé prioridad a los cambios más urgentes y rentables.
—  El proceso de gestión del cambio tiene que ver con el
análisis de los costos y beneficios de los cambios
propuestos, la aprobación de los cambios que valen la
pena y el seguimiento de los componentes del sistema
que han cambiado o cambiaran.
Proceso de la Administración del
Cambio Customer support
Customer

Submit Check CR
CR
Invalid Valid

Change Close CR Register CR

requests
Development

Implementation
Product development/CCB analysis

Cost/impact
Assess CRs
analysis

Select CRs Modify

software

Test software

Close CRs Pass

Fail
Close CR
 Formulario de Solicitud de Cambios

Change Request Form

Project: SICSA/AppProcessing Number: 23/02

Change requester: I. Sommerville Date: 20/01/09
Requested change: The status of applicants (rejected, accepted, etc.) should be
shown visually in the displayed list of applicants.

Change analyzer: R. Looek Analysis date: 25/01/09

Components affected: ApplicantListDisplay, StatusUpdater

Associated components: StudentDatabase

Factores del Análisis de Cambios
—  Las consecuencias de no hacer el cambio
—  Los beneficios de realizar el cambio
—  El número de usuarios afectados por el
cambio
—  Los costos de implementar el cambio
—  El ciclo de lanzamiento / liberación de
productos (releases)
 Administración del Cambio en los
métodos agiles
—  En algunos métodos ágiles, los clientes están
directamente involucrados en la gestión del cambio.
—  Se propone un cambio en los requisitos y se trabaja
con el equipo para evaluar su impacto y decidir si el
cambio debe tener prioridad sobre las funciones
previstas para el próximo incremento del sistema
(release / sprint).
—  Los cambios para mejorar el software son decididos
por los programadores que trabajan en el sistema.
—  El Refactoring, donde el software se mejora
continuamente, no es visto como un gasto sino como
una parte necesaria del proceso de desarrollo.
ADMINISTRACIÓN DE
VERSIONES
Administración de versiones
—  La Administracion de Versiones (VM) es el
proceso de realizar el seguimiento de las
diferentes versiones de los componentes del
software y los sistemas en los que se utilizan
estos componentes.
—  También implica asegurar que los cambios
realizados por diferentes desarrolladores de
estas versiones no interfieran entre sí.
—  Por lo tanto la gestión de versiones se puede
considerar como el proceso de administrar
de el ‘mainline’, ‘codelines’, ‘baselines’,
‘branches’ y otros.
 Codelines y Baselines
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)
A1.3 B1.2 C1.2
C C1.1 C1.2 C1.3
L1 L2 Ex2
Libraries and external components

L1 L2 Ex1 Ex2 Mainline

Sistemas de Control de Versiones -
SCV
—  Proporcionan manejo de versiones y la
identificación de liberación.
◦  Se asignan identificadores cuando los cambios se
envian al SCV.
—  Gestión del almacenamiento
◦  Para reducir el espacio de almacenamiento
requerido por múltiples versiones de los
componentes, los sistemas de gestión de versión
suelen proporcionar facilidades de
almacenamiento.
—  Registro del histórico de cambios
◦  Todos los cambios realizados en el código de un
sistema o componente se registran y se listan.
Sistemas de Control de Versiones -
SCV
—  CVS - Concurrent Versions System
—  Mercurial
—  SVN - SubVersion
—  Git
—  Etc.
Sistemas de Control de Versiones

Creation date
Version sequence

Version Version Version Version

1.0 1.1 1.2 1.3

Most recent

V1.3 source
D1 D2 D3 code

Storage structure
 Sistemas de Control de Versiones –
Check In / Check Out
Workspace (U1) Workspace (U2)

A B X Y

C C Bob
Alice

check_in check_out check_in check_out

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

A B C Z X R

Version management system

 Codeline Branches (Ramas)
—  En lugar de una secuencia lineal de versiones que
reflejen cambios en el tiempo, puede haber varias
secuencias independientes.
◦  Esto es normal en el desarrollo, donde los diferentes
desarrolladores trabajan de forma independiente en
diferentes versiones del código fuente y lo cambian de
diferentes maneras.
—  En algún momento, puede ser necesario fusionar o
combinar las ramas para crear una nueva versión de
un componente que incluye todos los cambios que
se han hecho.
◦  Si los cambios realizados involucran a diferentes partes
del código, las versiones de los componentes se pueden
combinar de forma automática mediante la combinación
de los deltas que se aplican al código.
CONSTRUCCIÓN DEL
SISTEMA
Construcción del Sistema
—  Construcción del sistema es el proceso de crear
un sistema ejecutable completo mediante la
compilación de los componentes del sistema,
bibliotecas externas, archivos de configuración,
etc.
—  Las herramientas para la Construcción de
sistemas y Administración de Versiones deben
comunicarse a medida que el proceso de
construcción implica revisar versiones de los
componentes del repositorio.
—  La descripción de la configuración utilizada para
identificar una línea de base también es utilizado
por la herramienta de construcción del sistema.
Construcción del Sistema
—  El proceso de desarrollo incluye herramientas de
desarrollo como compiladores, editores de código
fuente, etc.
◦  Los desarrolladores descargan (check-out) del sistema de
gestión de versiones en un espacio de trabajo privado
antes de realizar cambios en el sistema.
—  El servidor de compilación se utiliza para construir
versiones definitivas y ejecutables del sistema.
◦  Los desarrolladores suben (check-in) de código en el
sistema de gestión de versiones antes de su construcción.
La construcción del sistema puede depender de bibliotecas
externas que no están incluidos en el sistema de gestión
de versiones.
—  El ambiente destino (target) es la plataforma en la que
el sistema se ejecuta.
 Plataformas de Desarrollo,
Construcción y Ejecución
Development system Target system

Development Executable system

tools
Private workspace Target platform

Check-in

Check-out Version management and build server

(co)
Version co
management Build server
system
Construcción del Sistema

Source Configuration Executable

code files files tests

Data files Automated Executable

build system target system

Libraries Compilers Test results

and tools
AGILE BUILDING
Agile Building
—  Una vez que se termino de desarrollar la
funcionalidad, se debe verificar en el sistema de
construcción, pero aun no se debe subir los cambios
al repositorio (commit).
—  Se debe construir el sistema en el servidor de
compilación y ejecutar las pruebas. Se debe realizar
esto en caso de que otros hayan modificado
componentes desde el ultimo check-out. Si este es el
caso, se debe verificar los componentes que han
fallado y editarlos para que pasen las pruebas en el
espacio de trabajo privado.
—  Si el sistema pasa sus pruebas en el sistema de
construcción, entonces se debe subir los cambios
(commit) como una nueva línea base del sistema.
 Integración Continua
Version
Private
management
workspace
system
Tests fail

Check-out Build and Make Build and Tests fail

mainline test system changes test system

Tests OK

Check-in to Build and OK Commit

build server test system changes to VM

Version
Build server management
system
 Construcción Diaria – Daily Building
—  La equipo de desarrollo establece un plazo de entrega
(por ejemplo 14:00) para los componentes del sistema.
◦  Si los desarrolladores tienen nuevas versiones de los
componentes, deben entregarlos en ese momento.
◦  Una nueva versión del sistema se construye a partir de estos
componentes de compilar y enlazar para construir el sistema
completo.
◦  Este sistema se entrega al equipo de pruebas (QA), que lleva a
cabo una serie de pruebas del sistema predefinidas.
◦  Las fallas que se descubren durante las pruebas del sistema se
documentan y se devolverán a los desarrolladores.
◦  Se reparan estas fallas en una versión posterior.
 Release Management
—  Un Release es una versión de un sistema software
que se distribuye a los clientes.
—  Para el software de mercado masivo, por lo general
es posible identificar dos tipos de release:
◦  Releases Mayores con funcionalidades importantes
◦  Releases Menores con reparación de bugs y
correcciones a problemas que los clientes han
reportado.
—  Para el software personalizado o de líneas de
productos, los releases tienen que ser producidos
para cada cliente y los clientes individuales pueden
ejecutar varias versiones diferentes del sistema al
mismo tiempo.
Seguimiento de Releases
—  En caso de que ocurra un problema en producción,
puede ser necesario reproducir el problema
exactamente en la versión que ha sido entregada.
—  Cuando se produce un release, este debe ser
documentado (Release Notes) para asegurarse de
que se puede volver a crear la versión exacta en el
futuro.
—  Esto es particularmente importante para los sistemas
personalizados, o de largo plazo, los clientes pueden
utilizar una versión del sistemas durante muchos años
y pueden requerir cambios específicos mucho tiempo
después de su fecha de lanzamiento original.
Componentes de un Release
—  Al igual que el código ejecutable del sistema, un
Release puede incluir:
◦  Archivos de configuración que definen la forma en la
que el sistema debe ser configurado para
instalaciones particulares.
◦  Archivos de datos, tales como archivos de mensajes
de error, que son necesarios para el funcionamiento
del sistema.
◦  Un programa de instalación que se utiliza para ayudar
a instalar el sistema en el hardware destino
◦  Documentación electrónica o impresa que describe el
sistema;
◦  Publicidad asociada que se han diseñado para esa
versión.
Conclusiones
—  La Administración de la Configuración es la gestión de
un sistema en constante evolución. Se debe garantizar
que los cambios se incorporan en el sistema de una
manera controlada y se registra los detalles de los
cambios que se han implementado.
—  Los principales procesos de gestión de configuración
son la gestión de cambios, gestión de versiones, la
construcción del sistema y la gestión del release.
—  La Gestión de versiones consiste en hacer el
seguimiento de las diferentes versiones de los
componentes de software, y los cambios que se
hicieron para ellos.
 Conclusiones
—  La Construcción del sistema es el proceso de
ensamblar los componentes en un programa ejecutable
para ejecutarse en un equipo hardware destino.
—  El software debe ser reconstruido con frecuencia y
probado inmediatamente después que una nueva
versión se ha construido. Esto hace que sea más fácil
detectar los errores y problemas que se han
introducido desde la última generación.
—  Los Releases incluyen código ejecutable, archivos de
datos, archivos de configuración y documentación.
—  La Administración de Releases consiste en la toma de
decisiones sobre las fechas de lanzamiento del sistema,
la preparación de toda la información para la
distribución y la documentación de cada versión del
sistema.