Gestion de configuracion_INGENIERIA DEL SOFTWARE

Vista previa del material en texto

CONTENIDO 
 
 TEMAS A DESARROLLAR FUENTE BIBLIOGRÁFICA 
 - Sommerville I., Cap. 25 
 
 
 
 
 
 
-Se descubren bugs y los 
sistemas deben corregirse 
-Los sistemas de software 
siempre cambian durante 
su desarrollo y uso. 
-Los requerimientos del sistema cambian y 
es necesario implementar dichos 
cambios en una versión del sistema. 
-Conforme se hacen cambios al software se crea una versión del sistema 
- En consecuencia, “la mayoría de los sistemas pueden considerare como 
un conjuntos de versiones, cada una de las cuales debe mantenerse y 
gestionarse “ 
- Se dispone de nuevas versiones de 
hardware y plataformas del sistema, 
por lo que hay que adaptar los 
sistemas para que funcionen con 
ellos. 
-Los competidores introducen 
nuevas características en sus 
sistemas que deben igualar. 
“Se ocupa de las políticas, los 
procesos y las herramientas para 
administrar los sistemas 
cambiantes de software” 
 
 
 
Es necesario gestionar los sistemas 
en evolución porque es fácil perder 
la pista de cuales cambios y 
versiones del componente se 
incorporaron en cada versión del 
sistema. 
 
 
 
 
-Si no se cuenta con procedimientos efectivos de CM se puede 
malgastar esfuerzo al: 
- Modificar la versión equivocada de un sistema 
- Entregar a los clientes la versión incorrecta de un sistema 
-Olvidar dónde se almacena el código fuente del software para una 
versión particular del sistema o componente. 
 
 
 
 
 
 
Versiones de 
componente 
4.Construcción 
del Sistema 
Versiones del 
Sistema 
Entregas del Sistema 
 
3.Gestión de 
versiones 
2.Gestión de 
entregas 
(release) 
1.Administración 
del cambio 
Propuestas de cambio 
 
 
1. Las consecuencias de no realizar el cambio. 
2. Los beneficios del cambio. 
3. El número de usuarios afectados por el cambio. 
4. Los costos de hacer el cambio. 
5. El ciclo de liberación del producto. 
 
 Conforme el equipo de desarrollo modifica los 
componentes de software, debe mantener un 
registro de los cambios realizados (Historial de 
derivación) 
 Una buena forma de conservar el historial de 
derivación es un comentario estandarizado al 
principio del código fuente del componente. 
1. La CM por lo general recibe soporte de herramientas 
especializadas de software. 
2. Pueden ser herramientas sencillas basadas en la 
Web, como Bugzilla, que se utiliza para reportar 
problemas con muchos sistemas de código abierto. 
3. También pueden utilizarse herramientas más 
complejas para automatizar todo el proceso de 
manejar las peticiones de cambio desde la propuesta 
inicial del cliente hasta la aprobación del cambio. 
Es el proceso de realizar un 
seguimiento de las diferentes 
versiones de los componentes de 
software o ítems de configuración y 
los sistemas donde se usan dichos 
componentes. 
 
 
 
 
Es una secuencia de versiones del sistema, 
desarrolladas a partir de una línea base original 
Es una secuencia de versiones de código fuente 
con las versiones más recientes en la secuencia 
derivadas de las versiones anteriores 
Especifíca 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 
 Para soportar La VM siempre se deben usar 
herramientas de gestión de versiones (llamadas 
sistemas de control de versiones o sistemas de 
control de código fuente). 
 Estas herramientas identifican, almacenan y 
controlan el acceso a las diferentes versiones de los 
componentes. 
 Existen diversos sistemas de control de versiones: 
- Client-Server 
 . Código abierto: 
 *Concurrent Versions System (CVS) — basado 
originalmente en RCS, licenciado mediante GPL 
 *CVSNT — basado en CVS 
 *OpenCVS — clon CVS bajo licencia BSD, con énfasis en 
seguridad y correcto uso del código fuente 
 *Subversion (svn) — inspirado en CVS 
 *Vesta — sistema de construcción con soporte para 
versionado de ficheros en repositorios distribuidos 
- Propietario: 
*AccuRev 
* CA SCM 
 *Autodesk Vault -gestiona las relaciones complejas entre 
ficheros de diseño elaborados por AutoCAD y Autodesk 
Inventor. 
 *ClearCase – sistema de gestión de configuración -
compaltible con VSS- fabricado por Rational Software 
(IBM) 
 *codeBeamer – plataforma colaborativa para la gestión del 
ciclo de vida de aplicaciones 
 Configuration Management Version Control (CMVC) – 
sistema de control de versiones de IBM, retirado 
- Propietario: 
*Configuration Management Version Control (CMVC) – 
sistema de control de versiones de IBM. 
*Global Design Platform (GDP) – gestión de diseño de 
circuitos integrados 
* MKS Integrity - sistema para gestión del ciclo de vida de 
aplicaciones software 
 *Perforce – 
 *PVCS 
 *Quma Version Control System - solución para Windows de 
muy bajo costo 
 
- Distribuido 
 . Código abierto: 
*Aegis - orientado a sistemas de archivos, con soporte de red 
limitado 
* ArX 
 *Bazaar 
 Codeville 
 Darcs 
 DCVS - CVS descentralizado 
SVK -en base a subversion permite hacer commit distribuidos 
 
- Distribuido 
 . Propietario: 
BitKeeper — usado en el desarrollo del Núcleo de Linux 
 Code Co-op — sistema de control de versiones P2P (puede 
sincronizar mediante e-mail) 
 Sun WorkShop TeamWare — retirado, reemplazado por 
BitKeeper 
 Plastic SCM — por Codice Software, Inc 
 
Privado 
Público 
(Repositorio) 
Es el proceso de crear un sistema 
ejecutable y completo al compilar 
y vincular los componentes del 
sistema, librerías externas, 
archivos de configuración, etc. 
 
 
 
 
Compiladores 
Editores 
1 
2 
3 
Se utiliza para construir versiones 
ejecutables definitivas del sistema. 
Espacio donde se 
ejecuta el 
sistema 
 Generación de rutinas (Scripts) de construcción. 
 Integración del sistema de gestión de versiones (sacar 
las versiones requeridas del sistema de gestión de ver.) 
 Recompilación mínima (Det. cual CF requiere compil.) 
 Creación del sistema ejecutable (CO+Lib+Arch.Conf.) 
 Automatización de pruebas (Herramientas de aut.) 
 Informes (sobre éxito o fracaso de la const. y pruebas) 
 Generación de documentación (generar notas referidas 
a las páginas de ayuda de la const. y del sistema) 
 En la construcción del sistema se debe Minimizar la 
cantidad de Compilaciones. 
 Debe existir una forma de vincular sin ambiguedades 
el código fuente (CF) con el código objeto (CO) 
equivalente. 
 Esto se realiza asociando una Firma única con cada 
archivo donde se almacene un componente del CF. 
 El CO correspondiente que se compiló a partir del CF, 
tiene una firma relacionada que identifica cada 
versión del CF y cambia cuando éste se edita. 
 Al comparar las firmas en los archivos del CF y CO, es 
posible decidir si el componente del código fuente se 
utilizó para generar el componente del CO. 
 Tipos de Firmas: 
1. Modificación de marca de tiempo (Timestamp): la 
firma en el archivo del CF es la fecha y hora de su 
modificación. 
2. Sumas de verificación (Checksum) del CF: la firma en el 
archivo del CF es una suma de verificación calculada a 
partir de datos en el archivo. 
 Los métodos ágiles recomiendan que los componentes 
de sistema muy frecuentes deben realizarse con 
pruebas automatizadas (pruebas de humo) para 
descubrir problemas de software. 
 Los componentes frecuentes pueden ser parte de un 
proceso de integración continua. 
 La integración continua implica reconstruir 
frecuentemente la línea principal (mainline), después 
de realizar pequeños cambio al CF. 
1 2 3 
4 
5 
6 
7 
1- Sacar la mainline y llevarla al espacio de 
trabajo privado 
2-Construir y probar el sistema 
3-Realizar cambios al componente 
4- Construir y probar el sistema 
5- Ingresar al servidor de construcción sin 
confirmar unalínea base nueva del sistema. 
6- Construir y probar el sistema 
7- Si el sistema pasa las pruebas, confirmar los 
cambios como una nueva línea base en la mainline 
 
 
 La integración continua (IC) permite que los problemas 
causados por las interacciones entre diferentes 
desarrolladores se descubran y reparen rápidamente. 
 El sistema más reciente en la línea principal es el sistema 
definitivo. 
 No siempre es posible aplicar la IC debido a que : 
1. Si el sistema es muy grande, puede tardar mucho 
tiempo construir y probar. 
2. Si la plataforma de desarrollo es diferente a la 
plataforma objetivo, tal vez no sea posible efectuar 
pruebas del sistema en el espacio de trabajo privado. 
Una entrega (release) de sistema 
es una versión de un sistema de 
software que se distribuye a los 
clientes. 
 
 
 
 
Para software de Mercado 
masivo hay dos tipos de 
entregas: 
1) Release Mayor: 
proporciona funcionalidad 
significativamente nueva. 
2) Release Menor: repara 
bugs y corrige problemas 
reportados por el cliente. 
Para software a medida o líneas de 
producto de software: 
1) Es posible que deban producirse 
entregas especiales del sistema 
para cada cliente. 
2) Para Clientes individuales se 
pueden ejecutar muchas 
entregas diferentes del sistema 
al mismo tiempo. 
 Una compañía de software que vende un producto de 
software especializado, tal vez deba gestionar decenas o 
incluso cientos de diferentes entregas del producto. 
 Sus sistemas y procesos de administración de la 
configuración deben diseñarse para dar información 
sobre qué clientes tienen que releases del sistema y 
sobre la relación entre entregas y versiones del sistema 
 En caso de problemas, quizá sea necesario reproducir 
con exactitud el software que se entregó a un cliente 
particular. 
 Cuando se produce una entrega del sistema, esto debe 
documentarse para garantizar que pueda recrearse con 
exactitud en el futuro. 
 Para documentar una entrega, es necesario: 
1. Registrar las versiones específicas de los componentes de código 
fuente que se usaron para la creación. 
2. Conservar copias de los archivos de código fuente, los ejecutables 
correspondientes y todos los datos y archivos de configuración. 
3. Registrar las versiones del sistema operativo, librerías, 
compiladores y otras herramientas utilizadas para construir el 
software 
 
 BIBLIOGRAFÍA 
 
- Sommerville, Ian, Ingeniería del Software,Pearson-Addison Wesley, 9na. 
Ed.,2011.