Software Configuration Management

Ingeniería de Software II
Segundo Cuatrimestre 2008
Clase 20: Software Configuration Management
Buenos Aires, 13 de Noviembre de 2008
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Objetivos de la clase de hoy
Ejemplos de la vida real
Entender la problemática detrás de SCM
Definiciones de SCM
Misión
Conceptos Generales
Herramientas más comunes
2
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Ejemplos de la vida real
 Manejo de los artifacts de los TPs
 Problemas para modificar los archivos
 Pisarse en las modificaciones, perdiendo cambios realizados
 Problemas en la integración
 Perdí todo, se me clavó el disco
 ¿Quién tiene la última versión?
 Construcción de autos
 Cambio de modelos
 Construcción de pieza del modelo anterior
 Cuando el auto está terminado se sabe que motor tiene,
que paragolpes, etc
 Manuales de componentes electrónicos
 ¿Qué manual corresponde a que modelo?
 Se modificó el manual del modelo nuevo y se perdió el
manual viejo
3
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Entendiendo la problemática
Versión actual de un archivo (artifact) reemplazada por
una versión vieja modificada
Aplicar cambios sobre la versión incorrecta
Sin historia de cambios
No se puede identificar cuales son las versiones en
producción de los artifacts
Alta probabilidad de errores cuando se mantienen
múltiples versiones
No se puede volver a generar una versión ya generada
Se pierde todo por la ruptura de un hardware
4
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Entendiendo la problemática (cont.)
Las personas involucradas no se enteran de los cambios
realizados
No hay control sobre quien puede modificar qué en que
momento
No se sabe quién hizo los cambios
Se puede borrar un archivo y perder todo el trabajo
No existe trazabilidad entre un componente de software y
que requerimientos implementa
No se pueden corregir defectos sobre versiones que están
instaladas en un cliente, simplemente porque no se sabe
cuál es la versión
5
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Definiciones de SCM
One thing is clear: software change  too easy.
Here is about as short as a definition of SCM as you will
find:
SCM is about managing change to software
Brian White
6
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Definiciones de SCM
Definición según el SEI:
“Las disciplinas y técnicas de iniciación, evaluación y
control de cambios sobre productos de software
durante y después del proceso de desarrollo”
The disciplines and techniques of initiating,
evaluating, and controlling change of software
products during and after the development process”
Jim Tomayko
SEI Workshop on SCM
7
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Misión de SCM
Custodiar la integridad de los productos.
 Acompañar
control.
la actividad de cambio con actividades de
 Gestionar
los tipos de cambio permitidos a lo largo
del ciclo de vida del producto.
 Brindar
acceso al componente adecuado en la version
correspondiente
8
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Entropía y Actividad de Cambio
“Ley de la evolución del software”:
…entropy of software systems continually increases
unless steps are take to control…” (Lehman & Belady)
9
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Cambio
Incrementando la complejidad del Software
 Tamaño
 Cambios
en los requerimientos
 Inclusión
de componentes de terceras partes
 Incrementando
el número de plataformas que
debemos mantener
10
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Cambio (cont.)
Incrementando la complejidad del Entorno
 Tamaño
del team
 Distribución
 Frecuencia
 Cambios
geográfica del team
con la cual salen nuevos releases
en plataformas SO y Hardware
11
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Conceptos Generales
Artifact (scm-item)
Baseline
Version
Revision
Variant
Release
12
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Otros Conceptos Generales
Check-out
Check-in / Commit
Update
Branch
Cambios Concurrentes
Merge / Integración
13
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Branch
“Generically, a branch is a means to organize file
versions and show their history” (White 2000)
Más especificamente un branch es una configuración de
un sistema derivada de otra configuración en donde se
puede desarrollar de manera independiente.
Los branches son un mecanismo para lograr
independencia en los cambios.
14
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
¿Cuando usar branches?
Versiones en producción
Tareas grandes y complejas
Integrar branches complejos
¿Cuando no usar branch?
Cuando no existe una fecha de merge
Existen varias alternativas para usar branches pero
hay que analizar bien las consecuencias
15
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Ejemplo de branches con CVS
+-------------+
Branch 1.2.2.3.2 ->
! 1.2.2.3.2.1 !
/ +-------------+
/
/
+---------+
+---------+
+---------+
Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
/ +---------+
+---------+
+---------+
/
/
+-----+
+-----+
+-----+
+-----+
+-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+
+-----+
+-----+
+-----+
+-----+
!
!
!
+---------+
+---------+
+---------+
Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
+---------+
+---------+
+---------+
16
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Soportar cambios concurrentes sobre artifacts
Una única persona modificando un ítem de
configuración a la vez.
Desarrollo concurrente resuelto por la herramienta
SCM.
Integrar los cambios con la asistencia de la
herramienta de SCM.
Complejidades en la serialización de cambios de
algunas herramientas.
17
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Problemas de la serialización de cambios
copia
Corrección
bug fix 6
Corrección
bug fix 3
1
1
2
1 + bug fix 3
3
1 + bug fix 6
Bajo Control de SCM
18
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Propuesta de Solución vía merge
copia
Corrección
bug fix 3
1
Corrección
bug fix 6
2
3
1
1 + bug fix 3
1 + bug fix 6
1 + bug fixs
3y6
Bajo Control de SCM
4
19
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Concurrencia - Consistent Merge
Turn-Taking
Un desarrollador a la vez accede a un component
Split-Combine
Dividimos el sistema en piezas que son modificadas
independientemente y luego ensambladas (assembly
integration)
Copy-Merge
Diversas copias del mismo component son modificadas en
espacios de trabajo aislados que luego serán combinadas
para conformar una pieza única.
20
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Ejemplo - File-Sharing
21
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Ejemplo - Turn-Taking (lock-modify-unlock)
22
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Ejemplo - Copy-Merge (copy-modify-merge) - 1
23
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Ejemplo - Copy-Merge (copy-modify-merge) - 2
24
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Buena Práctica – baselines x milestone
Crear baselines para cada milestone del proyecto
Al menos debe ser creado un baseline al final de cada
iteración del proyecto. Típicamente, nuevos baselines son
creados con mas frecuencia a medida que nos acercamos al
final de una iteración o también, a la etapa de entrega.
25
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Buena Práctica – baselines x milestone - motivación
1. Reproducibility
• Unir requerimientos, planes de proyecto, casos de prueba,
y artifacts. (análisis de impacto + análisis de causa)
• Regenerar cualquier release o entorno del sistema que
haya sido liberado antes.
• Indispensable para identificar problemas nuevos generados
por nuevos releases
26
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Buena Práctica – baselines x milestone - motivación
2. Traceability
• Unir requerimientos, planes de proyecto, casos de prueba,
y artifacts (análisis de impacto + análisis de causa)
3. Reporting
• Consultar el contenido de cualquier baseline
• Comparar un baseline con otro
• Nos asiste durante la etapa de debugging y la generación
de notas de release
• Mail sobre cambios en tiempo real
27
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Entorno CM
Implementation Processes
Configuration Change Control
Configuratin Status Accounting
Software
CM Processes
Configuration Identification
Hardware
Production
Firmware
Development
Configuration Audits
28
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM –Proceso de CM – Identificación de la Configuración
Las actividades de Identificación de la Configuración tienen el
objetivo de identificar los ítems que deberán ser controlados,
establecer esquemas de identificación, versionado y detalla el
uso herramientas y técnicas. A continuación se listas algunas
de las tareas básicas:
• Identificar los ítems
• Mantener las relaciones entre los mismos
• Manejar las políticas de versionado
• Manejar versiones de herramientas y librerías
• Identificar configuración de hardware
• Identificar configuración de software
29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Proceso de CM – Control de la Configuración
El Control de la Configuración del Software se preocupa de
manejar los cambios a lo largo de todo el ciclo de vida del
desarrollo.
La información recolectada de estas actividades es útil para
medir la frecuencia de cambio y el retrabajo.
• Solicitar, evaluar y aceptar pedidos de cambio
• Tablero de control
• Proceso de control de cambios
• Implementar los cambios en el software
• Desviaciones por control
30
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Proceso de CM – Ejemplo de Control de la Configuración
Need for
change
Preliminary
investigation
Change
Identified for
controled
item
(CCB)
Configuration
Control Review
Rejected
Inform
Requester
Approved
SCR
generated or
updated
Assign to
Engineer
incomplete
SCR
Evaluated
Schedule,
design, test,
complete test
31
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Proceso CM – Configuration Status Accounting (SCSA)
El reporte del estado de la configuracion (“Software
configuration status accounting”) se preocupa por guardar y
reportar toda la información necesaria para una efectiva
administración de configuración de software
• Software configuration status information
• Identificar
• Recolectar
• Mantener
• Status Reporting
32
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
SCM – Proceso de CM – Auditorías de la Configuración
Las auditorias se pueden efectuar en el momento en el que se
entrega un release o en cualquier momento en el ciclo de
desarrollo, las principales auditorias que se realizan son:
• Software functional configuration audit (FCA)
Para validar que los ítems sean consistentes con las
especificaciones funcionales. Se recibe como input las
salida del testing y la validación
• Software physical configuration audit (PCA)
Para validar que los ítems de configuración sean
instalados de manera consistente con la documentación
de diseño.
33
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Funcionalidad Importantes de una herramienta de SCM
completa
SCR – Software change request y los procedimientos de
aprobación
Manejar el repositorio para los ítems
Manejar las tareas de pedidos de cambios
Reportes de software configuration status y recolección de
métricas de SCM
Manejo de auditorias de software
Administración y seguimiento de la documentación
Generación de builds
Administración y seguimiento de la distribución del software.
34
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Herramientas más conocidas
Visual Source Safe – Team Foundation Server (Microsoft)
CVS (OSS)
Subversion – SVN (OSS)
Clear Case/Quest (IBM/Rational)
Bugzilla (OSS)
35
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
Bibliografía
“Software Configuration Patterns”, Stephen Berczuk.
“Software Configuration Managment Strategies and
Rational ClearCase”, B. White & G. Clemms
John A. Scott and David Nisse , "Software Configuration
Management" for the IEEE/ACM Software Engineering
Body of Knowledge (SWEBOK) project, Guide to the
Software Engineering Body of Knowledge, Trial Version,
IEEE Computer Society, May 2001.
Sitio oficial de la herramienta CVS, www.cvshome.org
36
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008