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

Transcripción

1 Diapositiva Ingeniería de Software II Primer Cuatrimestre 2008 Clase 6: Administración de Configuraciones Buenos Aires, 9 de Mayo de 2008 Diapositiva 2 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 8Herramientas más comunes

2 Diapositiva 3 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 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 8Se pierde todo por la ruptura de un hardware

3 Diapositiva 5 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 Diapositiva 6 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 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 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 Diapositiva 8 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 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 Diapositiva 0 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. SCM tool debería ejecutarse en todas las plataformas que el producto corre

9 Diapositiva Cambio (cont.) 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 - 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 = línea 3 personas = 3 líneas n personas = n* (n-)/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 Diapositiva 2 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 funcionalidad

12 Diapositiva 3 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 4 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 5 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 Diapositiva 6 Ejemplo de branches con CVS Branch >! ! / / / Branch.2.2 -> _!.2.2.!----!.2.2.2!----!.2.2.3! / / / !.!----!.2!----!.3!----!.4!----!.5! <- The main trunk !!! Branch.2.4 -> +---!.2.4.!----!.2.4.2!----!.2.4.3!

15 Diapositiva 7 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 Diapositiva 8 Problemas de la serialización de cambios copia Corrección bug fix 6 Corrección bug fix bug fix bug fix 6 Bajo Control de SCM Actividades Esenciales Soportar cambios concurrentes sobre los artifacts 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 9 Propuesta de Solución vía merge Corrección copia bug fix 3 Corrección bug fix bug fix bug fix bug fixs 3 y 6 Bajo Control de SCM Actividades Esenciales Soportar cambios concurrentes sobre los artifacts 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 Diapositiva 20 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 2 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 Diapositiva 22 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 Ejemplo - File-Sharing Diapositiva 24 Ejemplo - Turn-Taking (lock-modify-unlock)

22 Diapositiva 25 Ejemplo - Copy-Merge (copy-modify-merge) - Diapositiva 26 Ejemplo - Copy-Merge (copy-modify-merge) - 2

23 Diapositiva 27 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 Diapositiva 28 SCM Buena Práctica baselines x milestone - motivación. 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:. Reproducibility Es la habilidad de poder ir hacia atrás y re-generar cualquier release o entorno del sistema que haya sido liberado antes. Esto es indispensable para identificar problemas nuevos generados por nuevos releases.

25 Diapositiva 29 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 Estas tres propiedades nos ayudan a corregir errores en productos liberados y facilita auditorías..

26 Diapositiva 30 Entorno CM Implementation Processes Development Production CM Processes Configuration Identification Configuration Change Control Configuratin Status Accounting Configuration Audits Soft ware Firmware Hardware Products 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 3 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 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 Diapositiva 33 SCM Proceso de CM Ejemplo de Control de la Configuración Diapositiva 34 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 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 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 8Administración y seguimiento de la distribución del software.

30 Diapositiva 37 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 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 Sitio oficial de la herramienta CVS,