Diapositiva 1. Diapositiva 2. Ingeniería de Software II

(1)

Diapositiva 1

Ingeniería de Software II

Primer Cuatrimestre 2008

Buenos Aires, 19 de Mayo de 2008 Clase 16: Administración de Configuraciones

Diapositiva 2

1

Objetivos de la clase de hoy

8Ejemplos de la vida real

8Entender la problemática detrás de SCM

8Definiciones de SCM

8Misión

8Conceptos Generales

(2)

1

Ejemplos de la vida real

8Manejo de los artifacts de los TPs

8Problemas para modificar los archivos

8Pisarse en las modificaciones, perdiendo cambios realizados 8Problemas en la integración

8Perdí todo, se me clavó el disco 8¿Quién tiene la última versión? 8Construcción de autos

8Cambio de modelos

8Construcción de pieza del modelo anterior

8Cuando el auto está terminado se sabe que motor tiene, que

paragolpes, etc

8Manuales de componentes electrónicos

8¿Qué manual corresponde a que modelo?

8Se modificó el manual del modelo nuevo y se perdió el manual viejo

Diapositiva 4

1

Entendiendo la problemática

8Versión actual de un archivo (artifact) reemplazada por una versión vieja modificada

8Aplicar cambios sobre la versión incorrecta 8Sin historia de cambios

8No se puede identificar cuales son las versiones en producción de los artifacts

8Alta probabilidad de errores cuando se mantienen múltiples _versiones 8No se puede volver a generar una versión ya generada

(3)

Diapositiva 5

1

Entendiendo la problemática (cont.)

8Las personas involucradas no se enteran de los cambios realizados

8No hay control sobre quien puede modificar qué en que

momento

8No se sabe quién hizo los cambios

8Se puede borrar un archivo y perder todo el trabajo

8No existe trazabilidad entre un componente de software y que _{requerimientos implementa} 8No se pueden corregir defectos sobre versiones que están

instaladas en un cliente, simplemente porque no se sabe cuál es la versión

(4)

1

Here is about as short as a definition of SCM as you will find: SCM is about managing change to software

Brian White

Definiciones de SCM

Administración de Configuraciones - Introducción

La facilidad de cambio en el software pone en riesgo la integridad de los productos. Cambios sin control, despliegue de componentes inconsistentes entre sí, o la falta de disponibilidad del componente adecuado en una determinada etapa del ciclo de vida, pueden desestabilizar la calidad de mi aplicación.

Es de la sensibilidad al cambio presente en la disciplina de ingeniería de software que se

desprenden las radicales diferencias que tiene esta actividad de la ingeniería con otras actividades de la industria. El dinamismo intrínseco del software genera la necesidad de contar con un

framework para el control de cambios y estados de la configuración, es desde esta necesidad que surge CM (Configuration Management).

Paradójicamente, la naturaleza sensitiva al cambio presente en el software hace que la “burocracia” en los controles de cambio sea algo positivo dentro de este contexto.

CM colabora con el proceso a través de la implementación de políticas de tracking, seguridad, integración y administración de cambios.

(5)

Diapositiva 7

1

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

Software Configuration Management - Introducción

Según el SEI, nos centramos en actividades específicas de SCM que, de ser cumplimentadas, pueden al menos garantizar ciertos niveles de calidad en la configuración.

Nuestro enfoque partirá de observar a SCM también como un proceso, o sea que nos centraremos en sus actividades como propone el SEI.

(6)

1

Misión de SCM

8Custodiar la integridad de los productos.

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

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

8Brindar acceso al componente adecuado en la version correspondiente

Misión de CM (Configuration Management)

La misión de la Administración de Configuraciones es custodiar la integridad de los productos a medida que evolucionan desde la especificación, pasando a través del diseño, el desarrollo, el despliegue a producción y el posterior mantenimiento. Su existencia tiene sentido como actividad de soporte que acompaña a los productos en la actividad de cambio a lo largo del ciclo de vida. El valor invertido en CM está relacionado con el costo del producto vs la exposición al riesgo de obtener un producto inestable. Entonces, ¿cuál es el equilibrio entre el gasto en CM y exposición a dicho riesgo?, ¿cómo mido dicho riesgo?

(7)

Diapositiva 9

1

Entropía y Actividad de Cambio

8“Ley de la evolución del software”:

…entropy of software systems continually increases unless steps are take to control…” (Lehman & Belady)

Entropía vs Actividad de Cambio

La entropía aumentan en el software en forma continua a menos que acciones de control sean aplicadas sobre los cambios.

Los casos patológicos de ejemplo son los legacy systems donde existen, en algunos casos, décadas de cambios sin documentar por lo que debe interpretarse las reglas del negocio a través de ingeniería inversa sobre el código.

(8)

1

Cambio

8Incrementando la complejidad del Software 8Tamaño

8Cambios en los requerimientos

8Inclusión de componentes de terceras partes

8Incrementando el número de plataformas que debemos mantener

Cambio - Incrementando la complejidad del Software

Con este tipo de cambio nos referimos a modificaciones que sufre directamente el producto de software en sí sin incluir consideraciones del entorno.

- Size

Líneas de código

Nuevos Módulos (Cambio de arquitectura)

- Inclusión de componentes de terceras partes

Controlar versiones de componentes por terceras partes.

Grabar versiones que conforman el baseline del sistema de software

- Incrementando el número de plataformas sobre las cuales el sistema opera

La organización de test se ve afectada.

(9)

Diapositiva 11

1

8Incrementando la complejidad del Entorno 8Tamaño del team

8Distribución geográfica del team

8Frecuencia con la cual salen nuevos releases 8Cambios en plataformas SO y Hardware

Cambio (cont.)

Cambio - Incrementando la complejidad del Entorno - Team Size

Incrementar el tamaño del team significa aumentar la cantidad de líneas de comunicación. Por Ejemplo:

2 personas = 1 línea 3 personas = 3 líneas n personas = n* (n-1)/2

Acceso concurrente a los componentes aumenta. Complejidad en el merge de los cambios en paralelo. - Distribución geográfica del team

Comunicación más compleja.

Merge integration se hace imposible sobre los niveles superiores de integración. - Frecuencia de los Releases o cantidad de variantes

Aumenta la cantidad de releases mantenidos al mismo tiempo. Los bug fixes son mas difíciles de distribuir.

Los arreglos sobre versiones existentes colisionan con mayor número de versiones funcionando. - Cambio en plataformas de SO y Hardware

Muchas veces no atendido, las partes de la configuración que no son software (como firmware y hardware) no son tenidas en cuenta como parte de la configuración con la consecuente desatención durante el mantenimiento.

El SO, el hardware sobre el cual este funciona, como así también la versión de Firmware instalada en el Hardware son elementos de terceros que deben sr mantenidos bajo control de configuración.

(10)

1

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

Definiciones

:

Artifact: Cualquier elemento de un producto de software que esté sujeto a cambios.

Esto incluye código fuente, documentación, planes de prueba, datos de prueba, librerías,

código objeto, etc.

También es conocido en la terminología traducida que encontramos como “ítem de

configuración”.

Baseline:

Todo artifact se encuentra sujeto a una política de “versionado”.

Un producto de software está compuesto por un conjunto de artifacts cada uno de los

cuales pertenezca a una versión específica.

La idea de baseline entonces es establecer qué versión de cada artifact corresponde a

cada versión producto de software.

El baseline no contendrá ningún producto sino que será simplemente un conjunto de pares

<artifact, version number> que servirá para determinar que ítems de configuración debe

seleccionar la herramienta SCM para poder reproducir una versión determinada de mi

producto.

(11)

Variante: Una instancia del sistema que es funcionalmente idéntica pero que a nivel no

funcional distinta de las otras instancias del sistema.

Un ejemplo de esto es tener una variante distinta para cada plataforma de software y

hardware. Cambios en el look and view del producto son otros motivos para generar

nuevas variantes.

Versión: Una instancia del sistema funcionalmente distinta de las otras instancias del

mismo sistema.

Release: Una instancia del sistema que es distribuida a los usuarios fuera del equipo de

desarrollo.

Revision: Una instancia del sistema que solamente corrige defectos y no agrega nueva

(12)

1

Otros Conceptos Generales

8Check-out 8Check-in / Commit 8Update 8Branch 8Cambios Concurrentes 8Merge / Integración Definiciones:

Branch: Es una linea de desarrollo que da independencia de la línea principal o de otros branches Merge: Integración parcial o total de un branch con la linea base o con otro branch

Checkout: Creación de un ambiente privado local para trabajar

Check-in/Commit: Actualización de los cambios realizados en el ambiente privado al repositorio central Update: Actualización de los cambios realizados en el repositorio central al ambiente privado

(13)

Diapositiva 14

1

Branch

8“Generically, a branch is a means to organize file versions and show their history” (White 2000)

8Más especificamente un branch es una configuración de un

sistema derivada de otra configuración en donde se puede desarrollar de manera independiente.

8Los branches son un mecanismo para lograr independencia en los cambios.

Diapositiva 15

1

¿Cuando usar branches?

8Versiones en producción

8Tareas grandes y complejas

8Integrar branches complejos

8¿Cuando no usar branch?

8Cuando no existe una fecha de merge

8Existen varias alternativas para usar branches pero hay que analizar bien las consecuencias

Versiones que están en producción y todavía se continua agregando funcionalidad, sobre los branches se puede corregir bugs sin afectar la linea base.

Para integrar branches complejos en la linea base, primero se integra sobre un branch y luego se integra (merge) sobre la linea base

(14)

1

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

(15)

Diapositiva 17

1

Soportar cambios concurrentes sobre artifacts

8Una única persona modificando un ítem de configuración

a la vez.

8Desarrollo concurrente resuelto por la herramienta SCM.

8Integrar los cambios con la asistencia de la herramienta de SCM.

8Complejidades en la serialización de cambios de algunas herramientas.

Actividades Esenciales

Soportar cambios concurrentes sobre los artifacts

Idealmente quisiéramos tener una única persona modificando un ítem de configuración a la vez. Dado que esto es ineficiente y no práctico, la complejidad introducida por el desarrollo concurrente debe ser resuella también por la herramienta SCM.

Los cambios realizados en paralelo deben poder ser integrados con la asistencia de la herramienta de SCM.

La serialización de cambios propuesta por algunas herramientas SCM presenta algunos inconvenientes...

(16)

1

Problemas de la serialización de cambios

Bajo Control de SCM 1 2 3 Co rre c c ió n bu g fix 6 Co rre c c ió n bu g fix 3 copia 1 1 + bug fix 3 1 + bug fix 6 Actividades Esenciales

Problemas

Algunos cambios, como la resolución de errores, no son serializables.

Para esto la herramienta debe brindar la posibilidad de realizar un merge de los cambios en forma automática, en caso de que sea posible interpretar la estructura de un ítem de configuración, o en forma manual facilitando el acceso a los elementos modificados.

(17)

Diapositiva 19

1

Propuesta de Solución vía merge

Bajo Control de SCM 1 2 3 Co rre c c ió n bu g fix 6 Co rre c c ió n bu g fix 3 copia ₁ 1 + bug fix 3 1 + bug fix 6 1 + bug fixs 3 y 6 4 Actividades Esenciales

Solución

La solución es crear una nueva versión en base al merge de los cambios aplicados sobre las versiones 2 y 3.

(18)

1

Integración

Integración es el proceso a través del cual los cambios desarrollados en forma independiente son reunidos para formar una pieza de software que pueda ser ejecutada y probada.

Integración

Integración es el proceso a través del cual, los cambios desarrollados en forma independiente

son juntados para formar una pieza de software que pueda ser ejecutada y probada.

El trabajo del integrador es tomar el trabajo del equipo de desarrollo construyendo una versión única del sistema o, dependiendo del nivel de integración, un conjunto de componentes de software.

Los niveles de integración se determinarán por la estructura del equipo de trabajo. A medida que crece la estructura del equipo de trabajo, los niveles de integración requeridos crecen en igual medida.

(19)

Diapositiva 21

1

Tipos de Integración

8Merge Integration es concerniente a la resolución de cambios en paralelo que realizados por diferentes miembros del equipo sobre artifacts en común.

8Assembly Integration involucra los procesos tendientes a crear una pieza de software a partir de varias componentes que comparten la misma baseline.

Integración

Tipos de Integración

Merge Integration es concerniente a la resolución de cambios en paralelo que son realizados por

diferentes miembros del equipo sobre artifacts en común.

En algunos casos el merge puede ser realizado automáticamente a través de herramientas que comprenden la estructura interna de los componentes. En otros casos, el merge deberá ser realizado en forma manual. Bajo la opción de merge manual, es posible sea necesario agregar nuevos cambios al componente resultante de modo que el merge conserve la union de las propiedades de las versiones combinadas.

Assembly Integration involucra los procesos tendientes a crear una pieza de software a partir de

varias componentes que comparten la misma baseline. Esta actividad nunca abarca modificaciones sobre los componentes.

Assembly Integration puede ser realizado en tiempo de construcción o de ejecución, esto quiere

decir que los componentes pueden ser ensamblados creando una única pieza de software ejecutable o conformar un conjunto de componentes ejecutables que compartan un entorno de ejecución.

(20)

1

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.

Integración

Tipos de Integración Consistent Merge

Turn-Taking: Los componentes son accedidos en forma exclusiva por una persona o equipo de trabajo. Esto solo es practicable en equipos de desarrollo pequeños.

Split-Combine: El producto es dividido en componentes independientes que son asignados a grupos separados. La concurrencia en el desarrollo es alta pero se acceden diferentes piezas a luego ser ensambladas eliminando de esta forma la complejidad existente en cambios inconsistentes sobre la misma pieza de software.

A posibilidad de aplicar este tipo de integración aumenta a medida que la granularidad del dieño es mayor.

Copy-Merge: El mismo componente es “copiado” en espacios aislados y modificado en forma paralela por diferentes desarrolladores en espacios de trabajo aislados.

La copia original del componente debe ser utilizada finalmente por el integrador en la etapa de merging para conocer cuales son los cambios realizados por cada uno de los desarrolladores.

Las herramientas que colaboran en este tipo de merge utilizan la estructura del código fuente para poder aumentar el nivel lógico de aislación de los cambios.

(21)

Diapositiva 23

1

Ejemplo - File-Sharing

Diapositiva 24

1

(22)

1

Ejemplo - Copy-Merge (copy-modify-merge) - 1

Diapositiva 26

1

(23)

Diapositiva 27

1

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.

Crear baselines para cada milestone del proyecto.

Todos los componentes y artifacts que conforman un sistema de software, deben ser agrupados seleccionando la versión correcta para cada uno de ellos bajo una línea de base (baseline). Cada

etapa del schedule del proyecto donde se presenta un milestone, debemos tener un entregable auditable y reproducible.

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.

Esto nos habilita a reproducir cualquier versión de mi sistema de software, consultar qué cambios han sido realizados, e indicar la estabilidad de la versión utilizando los atributos almacenados en la línea de base .

Nota: La mayor cantidad de baselines no se debe a una mayor actividad de cambio sino a que se hace necesario poder volver a un release mas reciente.

(24)

1

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

Actividades Esenciales

Crear baselines para cada milestone del proyecto.

Motivación

Existen tres razones principales para realizar un baseline: 1. Reproducibility

Es la habilidad de poder ir hacia atrás y re-generar cualquier release o entorno del sistema que haya sido liberado antes.

(25)

Diapositiva 29

1

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

2. Traceability

Es la posibilidad de unir requerimientos, planes de proyecto, casos de prueba, y artifacts todos juntos de modo de no solo poseer el release concerniente al sistema de software sino también, la información técnica requerida para comprender dicho sistema.

3. Reporting

Es la habilidad de poder consultar el contenido de cualquier baseline y poder además comparar un baseline con otro. La comparación de baselines nos asiste durante la etapa de debugging y la generación de notas de release. La comparación de baselines es utilizada en la actividad de “Peer

reviews”

(26)

1

Entorno CM

Configurat ion Ident ificat ion Configurat ion Change Cont rol Configurat in St at us Account ing

Configurat ion Audit s

So ft w a re Fi rm w a re H a rd w a re Product ion Development C M P ro c e sse s

Implement at ion Processes

Prod ucts

Entorno CM Products

Los productos sujetos a control de configuracion son todos aquellos que, al ser afectados por un cambio, pudieran afectar la integridad de la aplicacion.

Implementation Processes

La necesidad de operar sobre diversos ambientes nos obliga a conservar, al menos, entornos de produccion y desarrollo por separado. La actividad de cambio en ambos entornos tendra diferente volatilidad y por ende, debera poder ser aislada.

CM Processes

La integridad de los productos a lo largo de los entornos es gestionada a partir de las practicas de CM que se describen a lo largo de este presentacion.

(27)

Diapositiva 31

1

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

Diapositiva 32

1

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

(28)

1

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

Diapositiva 34

1

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

(29)

Diapositiva 35

1

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.

Diapositiva 36

1

Funcionalidad Importantes de una herramienta de SCM completa

8SCR – Software change request y los procedimientos de aprobación

8Manejar el repositorio para los ítems

8Manejar las tareas de pedidos de cambios

8Reportes de software configuration status y recolección de métricas de SCM

8Manejo de auditorias de software

8Administración y seguimiento de la documentación

8Generación de builds

(30)

1

Herramientas más conocidas

8Visual Source Safe – Team Foundation Server (Microsoft)

8CVS (OSS)

8Subversion – SVN (OSS)

8Clear Case/Quest (IBM/Rational)

8Bugzilla (OSS)

Diapositiva 38

1

Bibliografía

8“Software Configuration Patterns”, Stephen Berczuk.

8“Software Configuration Managment Strategies and Rational ClearCase”, B. White & G. Clemms

8John 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.