(c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Fundamentos de Administración de Configuración de Software (SCM), v2.1.

Presentación del tema: "(c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Fundamentos de Administración de Configuración de Software (SCM), v2.1."— Transcripción de la presentación:

1 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Fundamentos de Administración de Configuración de Software (SCM), v2.1 Ing. Melvin Pérez, CSDP, M.S.E VP & Chief Software Engineer CAM Informática, S. A.

2 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Objetivos l Al concluir esta charla, usted estará en capacidad de: l Comprender la importancia de SCM l Identificar beneficios del uso de SCM l Comprender los conceptos básicos de SCM l Comprender las funciones principales de SCM l Identificar Mejores Prácticas para problemas comunes de SCM

3 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Contenido l Lección 01 – Visión General de SCM l Qué es SCM, su importancia y beneficios l Lección 02 – Conceptos Básicos l Conceptos fundamentales de todo sistema de SCM l Lección 03 – Funciones de SCM l Descripción de principales Funciones de SCM l Lección 04 – Mejores Prácticas l Soluciones efectivas a problemas comunes de SCM

4 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L01 – Visión General de SCM: Objetivos l Al concluir esta lección usted estará en capacidad de: l Definir Administración de Configuración (SCM) l Identificar las funciones principales l Identificar la importancia de SCM dentro del ciclo de desarrollo de software

5 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Por qué estamos aquí? l Soportamos múltiples versiones de nuestras aplicaciones? l Podemos reconstruir de manera eficiente cualquier versión de nuestras aplicaciones? l Podemos realizar cambios a versiones anteriores sin interferir con el desarrollo actual? l Podemos rastrear efectivamente el origen de los cambios y los errores introducidos por estos? l Podemos controlar de manera efectiva el acceso al código y otros componentes del software? l Podemos comunicar efectivamente de manera periódica los cambios realizados?

6 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 La “Primera Ley” La administración de los cambios es una actividad del ciclo de vida, no sólo del mantenimiento! These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 No importa en que parte del ciclo de vida del sistema se encuentre, el sistema cambiará, y el deseo de cambiar persistirá a todo lo largo del ciclo de vida. Bersoff, et al, 1980

7 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 SCM en el Proceso de Desarrollo

8 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Preguntas Básicas de CM Cuáles cambios se hacen? Cuándo se hacen los cambios Quién hace los cambios Por qué se hacen los cambios Cambios

9 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Cuáles Cambios? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

10 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 La Configuración de Software These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

11 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Qué es SCM? l El propósito de la Administración de Configuración es establecer y mantener la integridad de productos de trabajo utilizando identificación de configuración, control de configuración, administración del estado de configuración y auditorias de configuración. [CMMI, 2002] l Es el proceso de administrar los cambios a los componentes de un sistema de software, buscando establecer y mantener la integridad de estos componentes a lo largo del proceso de desarrollo. l Es el proceso de identificar, organizar y administrar los cambios al software que está siendo construido por un equipo trabajando en paralelo, concurrente y/o proyectos distribuidos.

12 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Funciones Principales de CM [STSC, 2003] Qué vamos a controlar? Cómo nos vamos a asegurar de hacer sólo los cambios acordados? Cómo vamos a mantener informados a los involucrados sobre los cambios? Cómo nos vamos a asegurar que lo estamos haciendo bien?

13 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Funciones Principales de SCM l Identificación de Configuración l Selección y registro de los elementos de configuración de un sistema l Control de Configuración l Evaluación, coordinación, [aprobación] e implementación de cambios a los elementos de configuración l Mantenimiento del Estado de Configuración l Registro y reporte de información necesaria para manejar una configuración eficientemente l Auditorias y Revisiones de Configuración l Asegurar que el sistema de SCM está funcionando correctamente

14 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Otras Funciones Asociadas a SCM l Build Management l Actividades asociadas al proceso de construir el producto final l Release Management l Actividades asociadas al proceso de crear el medio de distribución del producto final

15 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Por qué se Necesita SCM l Incremento de la complejidad de los sistemas de software l Integración con diversas tecnologías, mercado dinámico l Naturaleza cambiante del software l Personalización, cambios en reglas de negocios l Incremento en la demanda del software l La dependencia en los sistemas de software incrementa la presión para realizar los cambios

16 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Qué dice la industria sobre SCM? “In large development projects with thousands of interrelated code modules and supporting documents, small errors in any of these areas could create a domino effect that might cost a company millions of dollars. There has to be some way of handling change effectively.” PC Magazine, March 4, 1997 “Some development tools fall into the 'nice but not essential' category. Software configuration management is not one of them.” VB Tech Journal, November 1996

17 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Situaciones Comunes sin SCM l Qué le pasó a este programa? Estaba funcionando ayer! l Aquí está funcionado bien! Por qué no me da el mismo error? l Quién hizo este cambio? l Por qué se hizo este cambio? l Dónde está el cambio que le hice a este programa la semana pasada? l En esta versión, están los cambios que hicimos? l Qué versión es ésta? Es ésta la actual? l Cliente: “tuvimos un problema con los discos, podrías enviarnos nuevamente el sistema?”

18 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Mitos Comunes de SCM l SCM es sólo para el código fuente l SCM es administración de cambios y seguimiento de defectos l SCM es una actividad dificultosa, monótona y que consume mucho tiempo l SCM es sólo para desarrolladores l El desarrollo de software puede progresar sin SCM l SCM sólo es necesario para obtener certificaciones l Las herramientas de SCM se encargarán de todo

19 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Beneficios de SCM l Asegura que se construya el sistema correcto l Las auditorias se aseguran el software a entregar sea funcional y físicamente el que se espera l Mejora la productividad de desarrollo de software l Mejora la comunicación, evita duplicar esfuerzos l Reduce los defectos l Ayuda a identificar de manera precisa la versión sobre que se realizarán los cambios l Agiliza la identificación de problemas y corrección de errores l Mantiene historial de problemas y cómo fueron resueltos

20 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Beneficios de SCM [2] l Ayuda al proceso de desarrollo l Se reduce la dependencia de las personas l Disminuye el costo de mantenimiento l Establece una forma sistemática de resolver las requisiciones de cambios l Mejora el aseguramiento de calidad l La información de CM ayuda a determinar las causas de los problemas y así evitar que ocurran nuevamente

21 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L01 – Visión General de SCM: Resumen l Los proyectos de software implican cambios l Mejorar el producto existente l Crear uno totalmente nuevo l Los requerimientos suelen cambiar frecuentemente durante el ciclo de desarrollo l Es necesario establecer un sistema que permita determinar cuáles cambios se hicieron, quién los hizo, porqué se hicieron y cuándo se hicieron l Las funciones principales de SCM son l Identificar los elementos que se quiere controlar l Controlar los cambios l Mantener el estado de la configuración, y l Auditar y verificar el contenido y funcionalidad de la configuración l SCM es para todos y es vital en el proceso de desarrollo

22 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L01 – Visión General de SCM: Verificación l Usted debe estar en capacidad de:  Definir Administración de Configuración (SCM)  Identificar las funciones principales  Identificar la importancia de SCM dentro del ciclo de desarrollo de software

23 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L02 – Conceptos Básicos: Objetivos l Al concluir esta lección usted estará en capacidad de: l Comprender los conceptos básicos de SCM l Comprender la relación entre estos

24 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Conceptos Básicos de SCM

25 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Elemento de Configuración (CI) l Producto de trabajo o pieza de software que es tratada como una simple entidad para el propósito de CM. [bruegge, 2000] l Programas (fuentes, librerías) l Documentación (requerimientos, modelos, manuales, planes) l Data (datos de prueba, datos iniciales) l Regularmente es un elemento fuente: no se puede obtener a partir de otro elemento

26 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Agregado de CM (Proyecto) l Es elemento de configuración que agrupa otros elementos de configuración que cumplen con un objetivo específico l Sistema l Subsistema l Paquete l Librería l Se conforma una estructura jerárquica y las operaciones de CM son aplicables en cualquier nivel de la jerarquía

27 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Repositorio de CM l Ubicación en donde se almacenan los elementos de configuración con sus respectivas características, interdependencias e historial de cambios desde su creación l El contenido y la estructura se define en el Plan de CM. l La estructura regularmente se corresponde con la arquitectura del producto en desarrollo

28 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Versiones l Identifican el estado de un elemento de configuración o una configuración en un punto definido en el tiempo [bruegge, 2000] l Una versión es una instancia del CI en el tiempo que difiere de alguna manera de otras instancias: l Agrega funcionalidad l Cambia la funcionalidad l Corrige un error o mal comportamiento

29 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Evolución de Versiones l Las versiones van creciendo en una línea evolutiva (trunk) l La diferencia entre dos versiones se denomina Delta

30 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Variantes l Versiones funcionalmente equivalentes, pero diseñadas para ambientes diferentes l Linux l Windows l Una variante de un elemento de configuración no es una mejora sobre otra

31 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Branch l Es una revisión que surge a partir de una versión de la línea evolutiva principal (trunk) y evoluciona independientemente l Permiten implementar desarrollo en paralelo

32 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Codeline l Línea evolutiva de un Agregado de CM l Una especie de branch a nivel de proyecto l Contiene cada versión de cada elemento de configuración contenido en su ruta evolutiva

33 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Merge l Incorporar cambios realizados en una versión de un branch en una versión del trunk

34 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Nombrando las Versiones l Se debe seleccionar un esquema de numeración de las versiones y utilizarlo consistentemente l Ejemplo, X.Y[.Z]: l X = número de release l Y = cambio mayor l Z = reparación Reparación Cambio Mayor Nuevo Release

35 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Labels (Tags) l Un version label es una etiqueta utilizada para identificar una versión de un elemento de configuración l Permite asociar más información a la versión: cliente, plataforma, solicitud de cambio, etc. l Se pueden asociar múltiples etiquetas a una misma versión l Pueden ser flotantes o fijas

36 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Configuración de Software l Conjunto consistente de versiones de elementos de configuración que definen el estado de un proyecto. l Es la versión de un proyecto y se puede identificar utilizando un label l Una configuración cumple con características funcionales y físicas específicas establecidas en una documentación técnica o logradas por el producto en sí.

37 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Archivo de Trabajo (workfile) l Archivo utilizado para crear una nueva versión de un elemento de configuración l Estos workfiles pueden ser copias tanto de versiones iniciales como de versiones previamente sacadas del repositorio

38 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Workspace l Área en donde se crean y se mantienen los archivos de trabajo (workfiles) l Adicionalmente contienen otros elementos requeridos para verificar los cambios (librerías, componentes de terceros, etc.) l Los workspaces pueden ser públicos o privados l Existe un tipo especial para integrar/construir el producto, no para introducir cambios en los elementos de configuración

39 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Check-in l Registra en el repositorio de CM una nueva versión de un elemento de configuración utilizando un workfile, regularmente conteniendo cambios sobre una versión anterior l Para registrar en el repositorio la primera versión de un elemento de configuración, regularmente se hace con un check-in especializado l Luego de esta operación se pueden tomar algunas acciones con el workfile: bloquearlo para escritura, removerlo, copiarlo a workspace de integración

40 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Check-out/Get l Check-out l Extrae del repositorio de CM una versión específica de un elemento de configuración para introducir algún cambio l Esta versión del elemento de configuración es copiada en un archivo de trabajo (workfile) en donde se realizaron los cambios l Regularmente esta versión queda bloqueada para edición para cualquier otro usuario l Get l Extrae una versión de un elemento de configuración para fines de consulta o referencia l No bloquea dicha versión, por lo que queda habilitada para check-out por cualquier otro usuario

41 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Baseline l Una especificación o producto que ha sido revisado formalmente y arribado a un acuerdo, el cual de ahí en adelante sirve de base para desarrollo posterior y el cual puede ser cambiado sólo a través de procedimientos formales de control de cambios [IEEE-Std-610] l Es una versión de un elemento de configuración o Agregado de CM lo suficientemente estable para ser tomado como punto de partida l Regularmente están asociados a una configuración y a un label

42 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Promoción (promotion) l Mecanismo utilizado para indicar el nivel de madurez o progreso de una versión de elemento de configuración o Agregado de CM l Un promotion model es una jerarquía de grupos representando hitos en el proceso de desarrollo de la aplicación. DESARROLLO-QA-RELEASE l El promotion model impone a que el trabajo de desarrollo se lleve a cabo en el nivel más bajo del modelo (por ejemplo, el promotion group Desarrollo)

43 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Integración/Build l Integración l Combinar elementos de configuración desarrollados por distintos usuarios para crear el producto final l Build (Construcción) l Actividades asociadas al procesamiento de elementos de configuración fuentes para construir el producto final l Ej. extraer configuración, compilar, verificar integración

44 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Release (Liberación) l Es una versión que se ha puesto disponible a los usuarios finales l Regularmente está asociado a un baseline de una configuración l Indica que los elementos de configuración han alcanzado los criterios de calidad establecidos que puede ser utilizado o revisado por los usuarios

45 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L02 – Conceptos Básicos: Resumen l Un sistema de SCM mantiene un repositorio con los elementos de configuración y su historial de cambios correspondiente l Para realizar un cambio sobre un CI se debe sacar (check-out) del repositorio. Una vez realizado el cambio se registra (check- in) la nueva versión l Las versiones siguen un esquema de numeración jerárquico l Una configuración es un conjunto de CIs relacionados en un determinado estado (versión) l A las versiones se le pueden asociar labels para facilitar su identificación l Un baseline permite ver el estado del producto en un punto en el tiempo

46 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L02 – Conceptos Básicos: Verificación l Usted debe estar en capacidad de:  Comprender los conceptos básicos de SCM  Comprender la relación entre estos

47 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L03 – Funciones de SCM: Objetivos l Al concluir esta lección usted estará en capacidad de: l Comprender las funciones principales de la Administración de Configuración l Identificar algunas tareas para cada una de estas funciones

48 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Identificación de Configuración l Identificar los elementos a ser controlados l Establecer esquemas de identificación para estos elementos y sus versiones l Establecer las herramientas y las técnicas a utilizar para adquirir y manejar los elementos controlados l Establecer en qué momento deben comenzar a controlarse

49 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Elementos de Configuración l Del ciclo de desarrollo l Plan de desarrollo de software l Especificaciones de requerimientos l Especificaciones de diseño l Código fuente l Esquema de Base de Datos l Scripts de compilación l Planes de prueba l Datos de prueba l Documentación de usuario l Del ambiente l Sistemas operativos l Compiladores l Depuradores l Herramientas de terceros

50 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Checklist de Identificación de Configuración  Se estableció un criterio para seleccionar los CIs  Se estableció una estructura jerárquica del producto para ubicar los CIs y las relaciones entre ellos  Se estableció un esquema de nomenclatura para identificar claramente los CIs  Se estableció cómo identificar los baselines y los CIs que lo componen  Se definieron y establecieron los baselines a crearse  Se estableció el procedimiento para adquirir los CIs de un baseline

51 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Control de Configuración y Cambios l Es un elemento de administración de configuración que consiste en la evaluación, coordinación, aprobación o rechazo, y la implementación de cambios a elementos de configuración luego del establecimiento formal de su identificación de configuración [IEEE-Std-610] l Registro y seguimiento de problemas o solicitudes de cambio l Identificación de problemas y defectos l Clasificación de solicitudes de cambio (defecto, mejora) l Verificación de realización de cambios

52 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Solicitud de Cambio (SCR) l Un SCR (System Change Request) es un formulario físico o electrónico conteniendo una solicitud de cambio al sistema originada por un usuario o por un integrante del equipo l Usualmente el SCR es el mecanismo utilizado para coordinar la asignación de trabajo l Es recomendable que todo cambio a un elemento de configuración sea soportado por un SCR

53 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Change Control Board (CCB) l Analiza y determina si un cambio se va a llevar a cabo l Se asegura de que el cambio se haya implementado correctamente l Su estructura depende de la naturaleza de la organización o proyecto y de la disponibilidad de recursos

54 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Procedimiento de Control de Cambios [RUP, 2004]

55 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Mantenimiento de Estado de Configuración l Registro y reporte de la información necesaria para manejar efectivamente un sistema de software y sus características l Esta información incluye una lista de configuraciones aprobadas, el estado de los cambios propuestos a la configuración y el estado de la implementación de los cambios aprobados [IEEE-Std-610]

56 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Información Mantenida l Debe responder a las siguientes preguntas: l Cuál es el estado de un CI? l Se ha aprobado un SCR particular? l Cuál es el estado de los SCRs pendientes o abiertos? l Cuáles elementos fueron afectados por un SCR particular? l Quién realizó el cambio para un SCR particular y cuándo lo completó? Quién lo revisó? Quién lo aprobó? l Cuál versión de un elemento implementa un SCR aprobado? l Cuáles SCRs fueron asignados a quién? l Cuántos SCRs de alta prioridad no se han implementado actualmente?

57 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Algunos Reportes l Log de cambios (Historial de cambios de un CI) l Reporte de progreso (SCRs y su estado en un rango de fecha) l Reporte de estado de CI (Relación de CI, descripción y ubicación) l Cambios en progreso (CIs en check-out) l Log de actividades (Qué sucedió en un rango de fecha) l Tendencia de SCRs (causa, tipo, tasa de rechazo, antes vs. después de liberación)

58 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Verificaciones y Auditorias de Configuración l Verifican que el sistema de software se corresponda con la descripción del elemento de configuración en las especificaciones y documentos y que la configuración en revisión esté completa l Proveen confianza para establecer un baseline del producto y su eventual liberación

59 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Functional Configuration Audit (FCA) l Verifica que las funciones definidas en las especificaciones estén todas implementadas de la manera correcta l Una FCA verificará que todos los requerimientos funcionales fueron probados y que los resultados de las pruebas fueron satisfactorios

60 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Physical Configuration Audit (PCA) l Verifica que todos los elementos identificados como parte de la configuración estén presentes en el baseline del producto l Se asegura que no falte algún entregable l Al completarse la PCA y la FCA se establece el baseline del producto

61 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Integración/Construcción (Build) l Recomendaciones: l Hacer frecuentemente (Diario) l Asegurar que sea reproducible l Automatizar l Hacer construcciones limpias (sólo a partir del contenido de la configuración)

62 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L03 – Funciones de SCM: Resumen l La identificación de los CIs es la base de las demás funciones de SCM. Especifica qué se va a controlar, cómo se van a identificar los CIs y cómo se van a obtener l El control de la configuración asegura que se realicen los cambios autorizados de la manera correcta l El mantenimiento del estado de configuración mantiene información y produce reportes para dar seguimiento a los cambios realizados l Las verificaciones y auditorias de configuración permiten verificar que el contenido y la funcionalidad de la configuración sean correctas

63 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L03 – Funciones de SCM: Verificación l Usted debe estar en capacidad de:  Comprender las actividades principales de la Administración de Configuración  Identificar algunas tareas para cada una de estas funciones

64 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L04 – Mejores Prácticas: Objetivos l Al concluir esta lección usted estará en capacidad de: l Aplicar políticas generales para facilitar el funcionamiento del proceso de SCM l Identificar mejores prácticas para problemas comunes de SCM l Aplicar mejores prácticas a problemas comunes de SCM

65 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Políticas Generales l Los cambios deben documentarse apropiadamente l Todo cambio debe tener asociado un SCR l Se debe actualizar estado de SCRs asociados luego de someter el cambio l Crear un baseline al final de cada iteración o etapa del proyecto l Actualizar workspace antes de entregar l No liberar con cambios pendientes

66 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Ramificación & Merging l Minimice el merge y mantenga un número manejable de codelines activos desarrollando en un mainline l Cree codelines adicionales sólo cuando requiera realizar mantenimiento y desarrollo concurrentemente

67 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Configuración Inutilizable l Etiquete o promueva las versiones (builds) que pasaron satisfactoriamente las pruebas l Los clientes sólo deben utilizar estas versiones nombradas como estables (Named Stable Bases)

68 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Conflictos de Cambios l Desarrolle sus cambios en un Workspace Privado l Previene que los problemas de integración lo distraigan l Previene que sus cambios causen problemas a otros

69 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Uso de Elementos Incorrectos l Cree su workspace a partir del Repositorio que contiene todo lo que necesita (“one-stop shopping”) l Utilice las etiquetas para identificar la configuración con la que desea trabajar

70 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Configuración Inconstruible l Verifique que sus cambios no van a romper la compilación (build) haciendo una Construcción Privada del Sistema antes someter sus cambios al repositorio

71 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Conflictos de Integración l Asegúrese que su código siempre se construye confiablemente haciendo una Construcción de Integración periódicamente

72 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Descontrol de Código de Terceros l Administre el código de proveedores utilizando un Codeline de Terceros l Someta al repositorio cada nueva versión liberada l Etiquete cada versión que van con cada configuración de su producto

73 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Inconsistencia de Configuración l Organice los cambios al código fuente por unidades de trabajo orientadas a tareas y someta los cambios como Sometimiento a Nivel de Tarea l Ejemplo: l Un SCR l Un conjunto de cambios consistentes de un día

74 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Indefinición de Políticas de Versiones l Cree una Política de Codeline para ayudar a los desarrolladores a decidir cuándo someter código a un codeline y cuáles procedimientos seguir previamente l Ejemplos l Codeline de desarrollo – se pueden someter cambios interinos; los componentes afectados deben ser compilables l Codeline de liberación – el software debe ser construido y pasar las pruebas de regresión; los check-ins están limitados a corrección de errores, no a agregar funcionalidad

75 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 El Sistema Compila, Pero No Corre l Asegúrese de que el sistema sigue funcionando después de haber hecho un cambio haciendo una Prueba de Humo l La construcción y prueba de humo diaria (Daily Build & Smoke Test) permite detectar errores de integración tempranamente e identificar configuraciones funcionales l Una Prueba de Humo debe ser rápida de correr, auto-evaluable y tener una amplia cobertura del sistema

76 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 El Programa Cambiado no Funciona l Verifique que un módulo o programa se mantiene funcionando luego de un cambio corriéndole una Prueba Unitaria l Una Prueba Unitaria: l Es automática y auto-evaluable l Es de bajo nivel (cada método de una interfaz de una clase) l Es aislada l Es fácil de correr

77 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Se Daña el Código Existente al Introducir Mejora l Asegúrese de que el código existente no se empeora al hacer otras mejoras corriendo Pruebas de Regresión l Cree Pruebas de Regresión a partir de casos de prueba en los que el sistema ha fallado en el pasado l Como pueden tomar mucho tiempo en correr se recomienda que estén automatizadas y que se corran previo a una liberación no para cada cambio

78 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Un Experimento se Introdujo Erróneamente l Utilice Versionamiento Privado para experimentar con cambios complejos localmente hasta asegurarse de su implementación l Permite echar hacia atrás malas ideas sin hacerlas públicas

79 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Código de Versiones Liberadas se Entremezclan con Código Actual l Establezca una Línea de Liberación para mantener las versiones liberadas sin interferir con el desarrollo actual l Separe el mantenimiento y el desarrollo actual en codelines diferentes l Cada Línea de Liberación nace como un branch del mainline

80 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Inestabilidad de una Futura Liberación por Cambios Actuales l Estabilice el codeline una próxima liberación sin interrumpir el desarrollo actual separando el trabajo de estabilización en un Codeline Pre-Liberación l En lugar de congelar, complete la liberación en un branch y deje el mainline para el trabajo actual l Este branch se convertirá en la Línea de Liberación

81 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Inconsistencia y Desintegración por Cambios Superpuestos l Permita que parte el equipo realice una tarea desviada sin forzar el resto del equipo a trabajar alrededor de ellos utilizando un Task Branch l Permite realizar múltiples y superpuestos cambios a largo plazo sin comprometer la consistencia y la integridad

82 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L04 – Mejores Prácticas: Resumen l Existen soluciones probadas (patrones) para problemas típicos de SCM l Estos patrones o mejores prácticas son recomendaciones; deben evaluarse para cada situación l Se debe determinar si la herramienta en uso permite implementar los patrones deseados

83 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L04 – Mejores Prácticas: Verificación l Usted debe estar en capacidad de:  Aplicar políticas generales para facilitar el funcionamiento del proceso de SCM  Identificar mejores prácticas para problemas comunes de SCM  Aplicar mejores prácticas a problemas comunes de SCM

84 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L05 – Plan de SCM: Objetivos l Al concluir esta lección usted estará en capacidad de: l Definir qué es un Plan de Manejo de Configuración, su propósito y cómo se utiliza l Explicar el propósito y el alcance del Plan de Manejo de Configuración l Tener una idea general del contenido del Plan de Manejo de Configuración l Identificar los roles involucrados en las funciones de SCM

85 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 El Plan de Manejo de Configuración l Describe todas las actividades de administración de configuración y control de cambios que se llevarán a cabo durante el ciclo de vida de un producto o proyecto l Especifica cómo se llevarán a cabo estas actividades, quién será responsable de cada actividad, cuándo se realizarán, y cuáles recursos son necesarios l Se puede definir con alcance a nivel organizacional y/o de proyecto

86 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Cómo se Utiliza? l El Líder de Proyecto para la creación Plan de Desarrollo de Software del proyecto. Este documento es referenciado y se incluyen las actividades de más alto nivel de CM dentro del cronograma del proyecto. l Los integrantes del equipo del proyecto para comprender su compromiso con las actividades de CM

87 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Visión General de un Plan de CM l Consistente con el modelo de proceso de desarrollo en uso (RUP, Agile, MSF, etc.) l Acorde con los estándares de la industria (IEEE-Std-828, IEEE-Std-1042, etc.) l Acorde con modelos de madurez (CMMI) l Incluye detalles de alto de nivel de herramienta de CM en uso l Se complementa con guías de trabajo de la herramienta de CM en uso

88 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Contenido del Plan de CM l Organización, Responsabilidades y Políticas de CM l Especificaciones para la Identificación, Control, Mantenimiento y Auditoria de Configuración l Hitos de CM l Recursos de CM

89 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Organización: Equipo de Trabajo

90 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Responsabilidades PerfilDescripción Administrador de Configuración Responsable de proveer al equipo de desarrollo de la infraestructura general y el ambiente para el Manejo de Configuración. Encargado de Control de Cambios Supervisa el proceso de control de cambios. Regularmente este rol es desempeñado por el mismo Líder de Proyecto IntegradorResponsable de planificar y realizar la integración de Elementos de Implementación para la construcción Analista de Pruebas Verifica los cambios aplicados en una construcción (build) Cualquier RolEncargados de desarrollar las actividades asignadas, utilizando los objetos versionados. Comité de Control de Cambios (CCB) Comité que supervisa el proceso de cambios conformado por representantes de las partes interesadas en el proyecto, incluyendo clientes, desarrolladores y usuarios. Este comité es convocado para tomar decisión en caso de cambios mayores que representen una variación significativa en las características del producto y/o planes del proyecto. Regularmente la viabilidad de los cambios es determinada por el Encargado de Control de Cambios y/o Líder de Proyecto.

91 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Interfaces PerfilResponsabilidad Líder de Proyecto Coordina la inclusión apropiada de nuevos o nuevas versiones de elementos de configuración Gerente de QACoordina las auditorias y revisiones de configuración y los informes de estado de ésta Arquitecto de Software Provee la estructura del repositorio de CM en función de la arquitectura del producto a desarrollar. Regularmente se utiliza una estructura de directorios estándar durante la creación inicial del ambiente de CM. Administrador de Sistemas Gestiona y provee los recursos de infraestructura requeridos para las actividades de CM en coordinación con el Administrador de Configuración. Proveedores/ Subcontratistas Recibe y controla las versiones liberadas de componentes de software desarrollados externamente y forman parte del producto que se está desarrollando Herramientas & Librerías Al igual que los componentes de terceros, mantiene un control de la versión en uso de componentes de aplicación general desarrollados internamente

92 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Identificación de Configuración l Son elementos de configuración: l Todos los artefactos sujetos a revisión formal l Requerimientos (Visión, Casos de Uso) l Análisis y Diseño (Modelos, Documento de Arquitectura) l Implementación (código, Plan de Construcción/Integración) l Pruebas (Plan de Prueba, Casos de Prueba, Escenarios, scripts) l Administración de Proyecto (Plan de Desarrollo, Planes de Iteración) l Etc. l Las herramientas y componentes de terceros requeridos para construir el producto l El momento y el mecanismo de adquisición de cada artefacto depende de su volatilidad y la herramienta utilizada

93 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Control de Configuración y Cambios l Procesamiento y Aprobación de Solicitudes de Cambio l Los cambios al sistema y a liberaciones se hacen de una manera controlada y siguiendo un procedimiento formal l Comité de Control de Cambios l Regularmente los cambios son aprobados por el Encargado de Control de Cambios [Líder de Proyecto] l El comité del proyecto actúa como CCB para cambios mayores

94 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Mantenimiento y Reporte del Estado de Configuración l Información requerida y mecanismos de obtención l Para cada elemento de configuración se estableció la herramienta y el momento de someterlo a CM l Reportes de Configuración l Los reportes requeridos están especificados en el Plan de Mediciones l Su frecuencia es acorde a la frecuencia de seguimiento o revisión del proyecto

95 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Auditorias de Configuración l Se deben realizar para cada baseline l Auditoria Física de Configuración (PCA) l Se listan los elementos de configuración utilizando el label asociado al baseline l Se cuenta con un checklist para verificar que una configuración contenga los elementos de configuración requeridos l Auditoria Funcional de Configuración (FCA) l Se lleva a cabo utilizando el Plan de Iteración y los resultados de prueba correspondientes l Forman parte de la revisión de iteración

96 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Hitos de CM al Final de Cada Iteración l Baseline creado l Se identificaron todos los artefactos correspondientes y estableció un baseline que permite recrear el estado del producto en ese punto de manera satisfactoria y repetible l Instalable creado l En las iteraciones que produzcan un ejecutable se debe haber creado un instalable a partir del baseline conteniendo los elementos de instalación correspondientes l Auditorias de Configuración Completadas l Se realizaron las auditorias establecidas en este plan y se documentaron los hallazgos l Estado de Configuración Reportado l Se generaron y distribuyeron los reportes establecidos y los hallazgos de las auditorias

97 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Recursos de CM l Herramientas, técnicas y equipos a utilizar l Personal l Capacitación requerida para implementar las actividades de CM

98 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L05 – Plan de SCM: Resumen l El Plan de SCM define cómo se van a poner en práctica las actividades de Administración de Configuración l Cuales actividades se llevarán a cabo l Quien es responsable de cada actividad l Cuando se llevarán a cabo l Cuáles recursos se necesitan

99 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 L05 – Plan de SCM: Verificación l Usted debe estar en capacidad de:  Definir qué es un Plan de Manejo de Configuración, su propósito y cómo se utiliza  Explicar el propósito y el alcance del Plan de Manejo de Configuración  Tener una idea general del contenido del Plan de Manejo de Configuración  Identificar los roles involucrados en las funciones de SCM

100 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Resumen l Para desarrollar y mantener software efectivamente es imprescindible disponer de los procedimientos, herramientas y recursos necesarios que permitan administrar los cambios y las configuraciones de software l Con la administración de configuración podemos conocer qué cambió, quién lo cambió, cuándo cambió y porqué cambió l Se apoya en 4 funciones básicas: l Identificación de Configuración l Control de Cambios l Mantenimiento de Configuración l Auditorias y Revisiones de Configuración l La Administración de Configuración es necesaria para asegurar la madurez del proceso, la estabilidad y la confianza

101 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Verificación l Usted debe estar en capacidad de:  Comprender la importancia de SCM  Identificar beneficios del uso de SCM  Comprender los conceptos básicos de SCM  Comprender las funciones principales de SCM  Aplicar mejores prácticas para contrarrestar problemas comunes asociados a SCM  Comprender la estructura de un Plan de CM

102 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 The End! Gracias!! melperez@ieee.org

103 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Referencias [bays, 1999]Bays, Michael. Software Release Methodology. 1999 [berczuk, 2003]Berczuk, Stephen. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. 2003 [bruegge, 2000]Bruegge, Bernd – Dutoit, Allen. Object-Oriented Software Engineering, 2000. [CMMI,2002]Carnegie Mellon University, Capability Maturity Model® Integration (CMMI SM ), Version 1.1, 2002. [IBM CMMI]Achieving Capability Maturity Model Integration (CMMI) Maturity Level 2 Using IBM Rational Software’s Solutions [IEEE-Std-610]IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610-1990), IEEE Standards Collection (Software Engineering), Piscataway, NJ: IEEE, 1997. [IEEE-Std-828]IEEE Standard for Software Configuration Management Plans(IEEE Std-828-1990), IEEE Standards Collection (Software Engineering),Piscataway, NJ: IEEE, 1997. [leon, 2005]Leon, Alexis. Software Configuration Management Handbook, 2005. [pressman, 2001]Pressman, Roger. Software Engineering: A Practitioner’s Approach, 5th Edition. 2001 [RUP, 2004]IBM Rational Unified Process®, Version 2003.06.13, 2004 [STSC, 2003]Guidelines for Successful and Management of Software-Intensive Systems (GSAM), version 4.0, 2004

104 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Recursos en Línea l CM crossroads – comunidad en línea de profesionales de CM l http://www.cmcrossroads.com/ http://www.cmcrossroads.com/ l SCM Patterns – Recursos de Steve Berczuk l http://www.scmpatterns.com/ http://www.scmpatterns.com/ l UCM Central – Portal educativo de SCM l http://www.ucmcentral.com/ http://www.ucmcentral.com/ l SEI – Publicaciones sobre SCM l http://www.sei.cmu.edu/legacy/scm/ http://www.sei.cmu.edu/legacy/scm/ l STSC – Documentos técnicos del U.S. Air Force l http://www.stsc.hill.af.mil/resources/tech%5Fdocs/ http://www.stsc.hill.af.mil/resources/tech%5Fdocs/ l ACME – Recursos de Brad Appleton l http://acme.bradapp.net/ http://acme.bradapp.net/

105 (c) 2005, Ing. Melvin Pérez Fundamentos de Administración de Configuración, v2.1 Herramientas de SCM HerramientaProveedorSitio Web ClearCaseIBM Rationalhttp://www.rational.com/products/clearcase PVCS Version Manager / Dimensions Serenahttp://www.serena.com/pvcs MKS Source IntegrityMKS Inc.http://www.mks.com/products/sie/ StarTeamBorlandhttp://www.borland.com/ VSS-Visual Source Safe Microsofthttp://www.microsoft.com/ssafe CVS – Concurrent Version System Open Source! http://www.cvshome.org/ SubversionOpen Source! http://subversion.tigris.org/ AccuRevAccuRev Inc.http://www.accurev.com/ BitKeeperBitMover Inc.http://bitkeeper.com PerforcePerforce Softwarehttp://www.perforce.com