Ingeniería de Software II

(1)

Ingeniería de Software II

Segundo Cuatrimestre 2008

Buenos Aires, 13 de Noviembre de 2008 Clase 20: Software Configuration Management

(2)

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

(3)

3

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

(4)

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

(5)

5

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

(6)

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

(7)

7

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

(8)

Misión de SCM

Custodiar la integridad de los productos.

Acompañar la actividad de cambio con actividades de control.

Gestionar los tipos de cambio permitidos a lo largo del ciclo de vida del producto.

Brindar acceso al componente adecuado en la version correspondiente

(9)

9

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)

(10)

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

(11)

11

Incrementando la complejidad del Entorno

Tamaño del team

Distribución geográfica del team

Frecuencia con la cual salen nuevos releases

Cambios en plataformas SO y Hardware Cambio (cont.)

(12)

Conceptos Generales Artifact (scm-item) Baseline Version Revision Variant Release

(13)

13

Otros Conceptos Generales

Check-out Check-in / Commit Update Branch Cambios Concurrentes Merge / Integración

(14)

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.

(15)

15

¿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

(16)

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 ! +---+ +---+ +---+

(17)

17

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.

(18)

Problemas de la serialización de cambios Bajo Control de SCM

1

2

3

Corrección bug fix 6 Corrección bug fix 3 copia 1 1 + bug fix 3 1 + bug fix 6

(19)

19

Propuesta de Solución vía merge

Bajo Control de SCM

1

2

3

Corrección bug fix 6 Corrección bug fix 3 copia ₁ 1 + bug fix 3 1 + bug fix 6 1 + bug fixs 3 y 6

4

(20)

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)

(21)

21

(22)

(23)

23

(24)

(25)

25

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.

(26)

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

(27)

27

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

(28)

Entorno CM

Configuration Identification

Configuration Change Control

Configuratin Status Accounting

Soft

w ar e Firm w a re Ha rd w are

Production

Development

CM Processes Implementation Processes

(29)

29

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

(30)

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

(31)

31

SCM – Proceso de CM – Ejemplo de Control de la Configuración

Need for change Change Identified for controled item SCR generated or updated SCR Evaluated incomplete Preliminary investigation (CCB) Configuration Control Review Inform Requester Schedule, design, test, complete test Assign to Engineer Approved Rejected

(32)

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

(33)

33

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.

(34)

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

(35)

35

Herramientas más conocidas

Visual Source Safe – Team Foundation Server (Microsoft)

CVS (OSS)

Subversion – SVN (OSS)

Clear Case/Quest (IBM/Rational)

(36)

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,