(c) 2005, ing. melvin pérez fundamentos de administración de configuración, v2.1 fundamentos de...

(c) 2005, Ing. Melvin PérezFundamentos 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.


Objetivos

Al concluir esta charla, usted 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 Identificar Mejores Prácticas para problemas

comunes de SCM


Contenido

Lección 01 – Visión General de SCM Qué es SCM, su importancia y beneficios

Lección 02 – Conceptos Básicos Conceptos fundamentales de todo sistema de

SCM Lección 03 – Funciones de SCM

Descripción de principales Funciones de SCM Lección 04 – Mejores Prácticas

Soluciones efectivas a problemas comunes de SCM


L01 – Visión General de SCM:Objetivos

Al concluir esta lección usted 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


Por qué estamos aquí?

Soportamos múltiples versiones de nuestras aplicaciones?

Podemos reconstruir de manera eficiente cualquier versión de nuestras aplicaciones?

Podemos realizar cambios a versiones anteriores sin interferir con el desarrollo actual?

Podemos rastrear efectivamente el origen de los cambios y los errores introducidos por estos?

Podemos controlar de manera efectiva el acceso al código y otros componentes del software?

Podemos comunicar efectivamente de manera periódica los cambios realizados?


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 No importa en que parte del ciclo de vida del sistema se encuentre, el sistema del sistema se encuentre, el sistema cambiará, y el deseo de cambiar cambiará, y el deseo de cambiar persistirá a todo lo largo del ciclo de persistirá a todo lo largo del ciclo de vida.vida.

Bersoff, et al, 1980Bersoff, et al, 1980


SCM en el Proceso de Desarrollo


Preguntas Básicas de CM

Cuáles cambios se hacen?

Cuáles cambios se hacen?

Cuándo se hacen los cambios

Cuándo se hacen los cambios

Quién hace los cambios

Quién hace los cambios

Por qué se hacen los cambios

Por qué se hacen los cambios

Cambios


Cuáles Cambios?



La Configuración de Software

programasprogramas documentosdocumentos

datadataLos Los elementoselementos



Qué es SCM?

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]

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.

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.


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?


Funciones Principales de SCM

Identificación de Configuración Selección y registro de los elementos de configuración de

un sistema Control de Configuración

Evaluación, coordinación, [aprobación] e implementación de cambios a los elementos de configuración

Mantenimiento del Estado de Configuración Registro y reporte de información necesaria para manejar

una configuración eficientemente Auditorias y Revisiones de Configuración

Asegurar que el sistema de SCM está funcionando correctamente


Otras Funciones Asociadas a SCM

Build Management Actividades asociadas al proceso de

construir el producto final Release Management

Actividades asociadas al proceso de crear el medio de distribución del producto final


Por qué se Necesita SCM

Incremento de la complejidad de los sistemas de software

Integración con diversas tecnologías, mercado dinámico

Naturaleza cambiante del software Personalización, cambios en reglas de negocios

Incremento en la demanda del software La dependencia en los sistemas de software

incrementa la presión para realizar los cambios


Situaciones Comunes sin SCM

Qué le pasó a este programa? Estaba funcionando ayer!

Aquí está funcionado bien! Por qué no me da el mismo error?

Quién hizo este cambio? Por qué se hizo este cambio? Dónde está el cambio que le hice a este programa la

semana pasada? En esta versión, están los cambios que hicimos? Qué versión es ésta? Es ésta la actual? Cliente: “tuvimos un problema con los discos, podrías

enviarnos nuevamente el sistema?”


Mitos Comunes de SCM

SCM es sólo para el código fuente SCM es administración de cambios y seguimiento de

defectos SCM es una actividad dificultosa, monótona y que

consume mucho tiempo SCM es sólo para desarrolladores El desarrollo de software puede progresar sin SCM SCM sólo es necesario para obtener certificaciones Las herramientas de SCM se encargarán de todo


Beneficios de SCM

Asegura que se construya el sistema correcto Las auditorias se aseguran el software a entregar sea

funcional y físicamente el que se espera Mejora la productividad de desarrollo de software

Mejora la comunicación, evita duplicar esfuerzos Reduce los defectos

Ayuda a identificar de manera precisa la versión sobre que se realizarán los cambios

Agiliza la identificación de problemas y corrección de errores

Mantiene historial de problemas y cómo fueron resueltos


Beneficios de SCM [2]

Ayuda al proceso de desarrollo Se reduce la dependencia de las personas

Disminuye el costo de mantenimiento Establece una forma sistemática de resolver las

requisiciones de cambios Mejora el aseguramiento de calidad

La información de CM ayuda a determinar las causas de los problemas y así evitar que ocurran nuevamente


L01 – Visión General de SCM:Resumen

Los proyectos de software implican cambios Mejorar el producto existente Crear uno totalmente nuevo

Los requerimientos suelen cambiar frecuentemente durante el ciclo de desarrollo

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

Las funciones principales de SCM son Identificar los elementos que se quiere controlar Controlar los cambios Mantener el estado de la configuración, y Auditar y verificar el contenido y funcionalidad de la configuración

SCM es para todos y es vital en el proceso de desarrollo


L01 – Visión General de SCM:Verificación

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


L02 – Conceptos Básicos:Objetivos

Al concluir esta lección usted estará en capacidad de: Comprender los conceptos básicos de

SCM Comprender la relación entre estos


Conceptos Básicos de SCM

Rep

osito

rio

Workspace

SCR#

Workfile (Copia deVersion N)

Sol

icitu

des

de

Cam

bio

SCRs

Version N-1

Version N

Version N+1

Archive

Label

Bas

elin

es

SCR#

Check-out

Check-in

CICreate/Admin

Workfile + Cambios

(Version N+1)


Elemento de Configuración (CI)

Producto de trabajo o pieza de software que es tratada como una simple entidad para el propósito de CM. [bruegge, 2000]

Programas (fuentes, librerías) Documentación (requerimientos, modelos,

manuales, planes) Data (datos de prueba, datos iniciales)

Regularmente es un elemento fuente: no se puede obtener a partir de otro elemento


Agregado de CM (Proyecto)

Es elemento de configuración que agrupa otros elementos de configuración que cumplen con un objetivo específico

Sistema Subsistema Paquete Librería

Se conforma una estructura jerárquica y las operaciones de CM son aplicables en cualquier nivel de la jerarquía

V 1.0 V 1.1

V 1.0 V 1.1

V 1.0 V 1.1 V 1.2

File1.java

Makefile

SRS.doc


Repositorio de CM

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

El contenido y la estructura se define en el Plan de CM.

La estructura regularmente se corresponde con la arquitectura del producto en desarrollo


Versiones

Identifican el estado de un elemento de configuración o una configuración en un punto definido en el tiempo [bruegge, 2000]

Una versión es una instancia del CI en el tiempo que difiere de alguna manera de otras instancias:

Agrega funcionalidad Cambia la funcionalidad Corrige un error o mal comportamiento


Evolución de Versiones

Las versiones van creciendo en una línea evolutiva (trunk)

La diferencia entre dos versiones se denomina Delta

V 1.0 V 1.1 V 1.2

Delta Delta


Variantes

Versiones funcionalmente equivalentes, pero diseñadas para ambientes diferentes Linux Windows

Una variante de un elemento de configuración no es una mejora sobre otra


Branch

Es una revisión que surge a partir de una versión de la línea evolutiva principal (trunk) y evoluciona independientemente

Permiten implementar desarrollo en paralelo

V 1.0 V 1.1 V 1.2

V 1.1.1.0 V 1.1.1.1


Codeline

Línea evolutiva de un Agregado de CM

Una especie de branch a nivel de proyecto

Contiene cada versión de cada elemento de configuración contenido en su ruta evolutiva

V 1.0 V 1.1 V 1.2

V 1.0 V 1.1

V 1.0 V 1.1 V 1.2

File1.java

Makefile

SRS.doc


Merge

Incorporar cambios realizados en una versión de un branch en una versión del trunk

V 1.0 V 1.1 V 1.2 V 2.0

V 1.1.1.0 V 1.1.1.1


Nombrando las Versiones

Se debe seleccionar un esquema de numeración de las versiones y utilizarlo consistentemente

Ejemplo, X.Y[.Z]: X = número de release Y = cambio mayor Z = reparación

V 1.0 V 1.1 V 1.2

V 1.3 V 1.4

V 2.0 V 2.1

V 1.1.1.0 V 1.1.1.1ReparaciónReparación

Cambio MayorCambio Mayor

Nuevo ReleaseNuevo Release


Labels (Tags)

Un version label es una etiqueta utilizada para identificar una versión de un elemento de configuración

Permite asociar más información a la versión: cliente, plataforma, solicitud de cambio, etc.

Se pueden asociar múltiples etiquetas a una misma versión

Pueden ser flotantes o fijas

V 1.0 V 1.1 V 1.2

V 1.3

V 2.0

V 1.1.1.0 V 1.1.1.1

SCR #2509

Cust_Key

STD STD


Configuración de Software

Conjunto consistente de versiones de elementos de configuración que definen el estado de un proyecto.

Es la versión de un proyecto y se puede identificar utilizando un label

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í.


Archivo de Trabajo (workfile)

Archivo utilizado para crear una nueva versión de un elemento de configuración

Estos workfiles pueden ser copias tanto de versiones iniciales como de versiones previamente sacadas del repositorio


Workspace

Área en donde se crean y se mantienen los archivos de trabajo (workfiles)

Adicionalmente contienen otros elementos requeridos para verificar los cambios (librerías, componentes de terceros, etc.)

Los workspaces pueden ser públicos o privados

Existe un tipo especial para integrar/construir el producto, no para introducir cambios en los elementos de configuración


Check-in

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

Para registrar en el repositorio la primera versión de un elemento de configuración, regularmente se hace con un check-in especializado

Luego de esta operación se pueden tomar algunas acciones con el workfile: bloquearlo para escritura, removerlo, copiarlo a workspace de integración


Check-out/Get

Check-out Extrae del repositorio de CM una versión específica de un

elemento de configuración para introducir algún cambio Esta versión del elemento de configuración es copiada en

un archivo de trabajo (workfile) en donde se realizaron los cambios

Regularmente esta versión queda bloqueada para edición para cualquier otro usuario

Get Extrae una versión de un elemento de configuración para

fines de consulta o referencia No bloquea dicha versión, por lo que queda habilitada para

check-out por cualquier otro usuario


Baseline

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]

Es una versión de un elemento de configuración o Agregado de CM lo suficientemente estable para ser tomado como punto de partida

Regularmente están asociados a una configuración y a un label

V 1.0 V 1.1 V 1.2

Baseline2Baseline1

V 1.0 V 1.1

V 1.0 V 1.1 V 1.2

File1.java

Makefile

SRS.doc

Tiempo


Promoción (promotion)

Mecanismo utilizado para indicar el nivel de madurez o progreso de una versión de elemento de configuración o Agregado de CM

Un promotion model es una jerarquía de grupos representando hitos en el proceso de desarrollo de la aplicación. DESARROLLO-QA-RELEASE

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)


Integración/Build

Integración Combinar elementos de configuración

desarrollados por distintos usuarios para crear el producto final

Build (Construcción) Actividades asociadas al procesamiento de

elementos de configuración fuentes para construir el producto final

Ej. extraer configuración, compilar, verificar integración


Release (Liberación)

Es una versión que se ha puesto disponible a los usuarios finales

Regularmente está asociado a un baseline de una configuración

Indica que los elementos de configuración han alcanzado los criterios de calidad establecidos que puede ser utilizado o revisado por los usuarios


L02 – Conceptos Básicos:Resumen

Un sistema de SCM mantiene un repositorio con los elementos de configuración y su historial de cambios correspondiente

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

Las versiones siguen un esquema de numeración jerárquico Una configuración es un conjunto de CIs relacionados en un

determinado estado (versión) A las versiones se le pueden asociar labels para facilitar su

identificación Un baseline permite ver el estado del producto en un punto en

el tiempo


L02 – Conceptos Básicos:Verificación

Usted debe estar en capacidad de:Comprender los conceptos básicos de

SCMComprender la relación entre estos


L03 – Funciones de SCM:Objetivos

Al concluir esta lección usted estará en capacidad de: Comprender las funciones principales de la

Administración de Configuración Identificar algunas tareas para cada una

de estas funciones


Identificación de Configuración

Identificar los elementos a ser controlados Establecer esquemas de identificación para

estos elementos y sus versiones Establecer las herramientas y las técnicas a

utilizar para adquirir y manejar los elementos controlados

Establecer en qué momento deben comenzar a controlarse


Elementos de Configuración

Del ciclo de desarrollo Plan de desarrollo de software Especificaciones de requerimientos Especificaciones de diseño Código fuente Esquema de Base de Datos Scripts de compilación Planes de prueba Datos de prueba Documentación de usuario

Del ambiente Sistemas operativos Compiladores Depuradores Herramientas de terceros


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


Control de Configuración y Cambios

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]

Registro y seguimiento de problemas o solicitudes de cambio

Identificación de problemas y defectos Clasificación de solicitudes de cambio (defecto, mejora) Verificación de realización de cambios


Solicitud de Cambio (SCR)

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

Usualmente el SCR es el mecanismo utilizado para coordinar la asignación de trabajo

Es recomendable que todo cambio a un elemento de configuración sea soportado por un SCR


Change Control Board (CCB)

Analiza y determina si un cambio se va a llevar a cabo

Se asegura de que el cambio se haya implementado correctamente

Su estructura depende de la naturaleza de la organización o proyecto y de la disponibilidad de recursos


Procedimiento de Control de Cambios

[RUP, 2004]


Mantenimiento de Estado de Configuración

Registro y reporte de la información necesaria para manejar efectivamente un sistema de software y sus características

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]


Información Mantenida

Debe responder a las siguientes preguntas: Cuál es el estado de un CI? Se ha aprobado un SCR particular? Cuál es el estado de los SCRs pendientes o abiertos? Cuáles elementos fueron afectados por un SCR particular? Quién realizó el cambio para un SCR particular y cuándo lo

completó? Quién lo revisó? Quién lo aprobó? Cuál versión de un elemento implementa un SCR

aprobado? Cuáles SCRs fueron asignados a quién? Cuántos SCRs de alta prioridad no se han implementado

actualmente?


Algunos Reportes

Log de cambios (Historial de cambios de un CI) Reporte de progreso (SCRs y su estado en un rango

de fecha) Reporte de estado de CI (Relación de CI, descripción

y ubicación) Cambios en progreso (CIs en check-out) Log de actividades (Qué sucedió en un rango de

fecha) Tendencia de SCRs (causa, tipo, tasa de rechazo,

antes vs. después de liberación)


Verificaciones y Auditorias de Configuración

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

Proveen confianza para establecer un baseline del producto y su eventual liberación


Functional Configuration Audit (FCA)

Verifica que las funciones definidas en las especificaciones estén todas implementadas de la manera correcta

Una FCA verificará que todos los requerimientos funcionales fueron probados y que los resultados de las pruebas fueron satisfactorios


Physical Configuration Audit (PCA)

Verifica que todos los elementos identificados como parte de la configuración estén presentes en el baseline del producto

Se asegura que no falte algún entregable

Al completarse la PCA y la FCA se establece el baseline del producto


L03 – Funciones de SCM:Resumen

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

El control de la configuración asegura que se realicen los cambios autorizados de la manera correcta

El mantenimiento del estado de configuración mantiene información y produce reportes para dar seguimiento a los cambios realizados

Las verificaciones y auditorias de configuración permiten verificar que el contenido y la funcionalidad de la configuración sean correctas


L03 – Funciones de SCM:Verificación

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


L04 – Mejores Prácticas:Objetivos

Al concluir esta lección usted 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


Políticas Generales

Los cambios deben documentarse apropiadamente

Todo cambio debe tener asociado un SCR Se debe actualizar estado de SCRs

asociados luego de someter el cambio Crear un baseline al final de cada iteración o

etapa del proyecto Actualizar workspace antes de entregar No liberar con cambios pendientes


Ramificación & Merging

Minimice el merge y mantenga un número manejable de codelines activos desarrollando en un mainline

Cree codelines adicionales sólo cuando requiera realizar mantenimiento y desarrollo concurrentemente


Configuración Inutilizable

Etiquete o promueva las versiones (builds) que pasaron satisfactoriamente las pruebas

Los clientes sólo deben utilizar estas versiones nombradas como estables (Named Stable Bases)


Conflictos de Cambios

Desarrolle sus cambios en un Workspace Privado

Previene que los problemas de integración lo distraigan

Previene que sus cambios causen problemas a otros


Uso de Elementos Incorrectos

Cree su workspace a partir del Repositorio que contiene todo lo que necesita (“one-stop shopping”)

Utilice las etiquetas para identificar la configuración con la que desea trabajar


Conflictos de Integración

Asegúrese que su código siempre se construye confiablemente haciendo una Construcción de Integración periódicamente


Inconsistencia de Configuración

Organice los cambios al código fuente por unidades de trabajo orientadas a tareas y someta los cambios como Sometimiento a Nivel de Tarea

Ejemplo: Un SCR Un conjunto de cambios consistentes de

un día


El Sistema Compila, Pero No Corre

Asegúrese de que el sistema sigue funcionando después de haber hecho un cambio haciendo una Prueba de Humo

La construcción y prueba de humo diaria (Daily Build & Smoke Test) permite detectar errores de integración tempranamente e identificar configuraciones funcionales

Una Prueba de Humo debe ser rápida de correr, auto-evaluable y tener una amplia cobertura del sistema


Código de Versiones Liberadas se Entremezclan con Código Actual

Establezca una Línea de Liberación para mantener las versiones liberadas sin interferir con el desarrollo actual

Separe el mantenimiento y el desarrollo actual en codelines diferentes

Cada Línea de Liberación nace como un branch del mainline


Inestabilidad de una Futura Liberación por Cambios Actuales

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

En lugar de congelar, complete la liberación en un branch y deje el mainline para el trabajo actual

Este branch se convertirá en la Línea de Liberación


L04 – Mejores Prácticas:Resumen

Existen soluciones probadas (patrones) para problemas típicos de SCM

Estos patrones o mejores prácticas son recomendaciones; deben evaluarse para cada situación

Se debe determinar si la herramienta en uso permite implementar los patrones deseados


L04 – Mejores Prácticas:Verificación

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 SCMAplicar mejores prácticas a problemas

comunes de SCM


L05 – Plan de SCM:Objetivos

Al concluir esta lección usted 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


El Plan de Manejo de Configuración

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

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

Se puede definir con alcance a nivel organizacional y/o de proyecto


Cómo se Utiliza?

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.

Los integrantes del equipo del proyecto para comprender su compromiso con las actividades de CM


Visión General de un Plan de CM

Consistente con el modelo de proceso de desarrollo en uso (RUP, Agile, MSF, etc.)

Acorde con los estándares de la industria (IEEE-Std-828, IEEE-Std-1042, etc.)

Acorde con modelos de madurez (CMMI) Incluye detalles de alto de nivel de

herramienta de CM en uso Se complementa con guías de trabajo de la

herramienta de CM en uso


Contenido del Plan de CM

Organización, Responsabilidades y Políticas de CM

Especificaciones para la Identificación, Control, Mantenimiento y Auditoria de Configuración

Hitos de CM Recursos de CM


Organización: Equipo de Trabajo

Coordinador de Proyecto

Líder de Proyecto

Gerente de QA

Enc. de Control de Cambios

Administrador de Configuración

Integrador

Analista de Pruebas

Cualquier Rol

Equipo de SCM


Responsabilidades

Perfil Descripció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

Integrador Responsable 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 Rol Encargados 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.


Interfaces

Perfil Responsabilidad

Líder de Proyecto

Coordina la inclusión apropiada de nuevos o nuevas versiones de elementos de configuración

Gerente de QA Coordina 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


Identificación de Configuración

Son elementos de configuración: Todos los artefactos sujetos a revisión formal

Requerimientos (Visión, Casos de Uso) Análisis y Diseño (Modelos, Documento de Arquitectura) Implementación (código, Plan de Construcción/Integración) Pruebas (Plan de Prueba, Casos de Prueba, Escenarios, scripts) Administración de Proyecto (Plan de Desarrollo, Planes de Iteración) Etc.

Las herramientas y componentes de terceros requeridos para construir el producto

El momento y el mecanismo de adquisición de cada artefacto depende de su volatilidad y la herramienta utilizada


Control de Configuración y Cambios

Procesamiento y Aprobación de Solicitudes de Cambio

Los cambios al sistema y a liberaciones se hacen de una manera controlada y siguiendo un procedimiento formal

Comité de Control de Cambios Regularmente los cambios son aprobados por el

Encargado de Control de Cambios [Líder de Proyecto]

El comité del proyecto actúa como CCB para cambios mayores


Mantenimiento y Reporte del Estado de Configuración

Información requerida y mecanismos de obtención

Para cada elemento de configuración se estableció la herramienta y el momento de someterlo a CM

Reportes de Configuración Los reportes requeridos están especificados en el

Plan de Mediciones Su frecuencia es acorde a la frecuencia de

seguimiento o revisión del proyecto


Auditorias de Configuración

Se deben realizar para cada baseline Auditoria Física de Configuración (PCA)

Se listan los elementos de configuración utilizando el label asociado al baseline

Se cuenta con un checklist para verificar que una configuración contenga los elementos de configuración requeridos

Auditoria Funcional de Configuración (FCA) Se lleva a cabo utilizando el Plan de Iteración y

los resultados de prueba correspondientes Forman parte de la revisión de iteración


Hitos de CM al Final de Cada Iteración

Baseline creado 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

Instalable creado En las iteraciones que produzcan un ejecutable se debe haber

creado un instalable a partir del baseline conteniendo los elementos de instalación correspondientes

Auditorias de Configuración Completadas Se realizaron las auditorias establecidas en este plan y se

documentaron los hallazgos Estado de Configuración Reportado

Se generaron y distribuyeron los reportes establecidos y los hallazgos de las auditorias


Recursos de CM

Herramientas, técnicas y equipos a utilizar

Personal Capacitación requerida para

implementar las actividades de CM


L05 – Plan de SCM:Resumen

El Plan de SCM define cómo se van a poner en práctica las actividades de Administración de Configuración Cuales actividades se llevarán a cabo Quien es responsable de cada actividad Cuando se llevarán a cabo Cuáles recursos se necesitan


L05 – Plan de SCM:Verificación

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


Resumen

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

Con la administración de configuración podemos conocer qué cambió, quién lo cambió, cuándo cambió y porqué cambió

Se apoya en 4 funciones básicas: Identificación de Configuración Control de Cambios Mantenimiento de Configuración Auditorias y Revisiones de Configuración

La Administración de Configuración es necesaria para asegurar la madurez del proceso, la estabilidad y la confianza


Verificación

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


The End!

Gracias!!

[email protected]


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 (CMMISM), 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


Recursos en Línea

CM crossroads – comunidad en línea de profesionales de CM http://www.cmcrossroads.com/

SCM Patterns – Recursos de Steve Berczuk http://www.scmpatterns.com/

UCM Central – Portal educativo de SCM http://www.ucmcentral.com/

SEI – Publicaciones sobre SCM http://www.sei.cmu.edu/legacy/scm/

STSC – Documentos técnicos del U.S. Air Force http://www.stsc.hill.af.mil/resources/tech%5Fdocs/

ACME – Recursos de Brad Appleton http://acme.bradapp.net/

http://www.cmcrossroads.com/

http://www.scmpatterns.com/

http://www.ucmcentral.com/



http://www.sei.cmu.edu/legacy/scm/







http://www.stsc.hill.af.mil/resources/tech%5Fdocs/

http://acme.bradapp.net/




Herramientas de SCM

Herramienta Proveedor Sitio Web

ClearCase IBM Rational http://www.rational.com/products/clearcase

PVCS Version Manager / Dimensions

Serena http://www.serena.com/pvcs

MKS Source Integrity MKS Inc. http://www.mks.com/products/sie/

StarTeam Borland http://www.borland.com/

VSS-Visual Source Safe

Microsoft http://www.microsoft.com/ssafe

CVS – Concurrent Version System

Open Source! http://www.cvshome.org/

Subversion Open Source! http://subversion.tigris.org/

AccuRev AccuRev Inc. http://www.accurev.com/

BitKeeper BitMover Inc. http://bitkeeper.com

Perforce Perforce Software http://www.perforce.com

http://www.rational.com/products/clearcase






http://www.serena.com/pvcs





http://www.mks.com/products/sie/

http://www.borland.com/

http://www.microsoft.com/ssafe

http://www.cvshome.org/

http://subversion.tigris.org/

http://www.accurev.com/

http://bitkeeper.com/

http://www.perforce.com/

(c) 2005, ing. melvin pérez fundamentos de administración de configuración, v2.1 fundamentos de...

Documents