Post on 23-Jan-2016
transcript
(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.
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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?
(c) 2005, Ing. Melvin PérezFundamentos 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 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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
SCM en el Proceso de Desarrollo
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos 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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
La Configuración de Software
programasprogramas documentosdocumentos
datadataLos Los elementoselementos
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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.
(c) 2005, Ing. Melvin PérezFundamentos 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?
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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?”
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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)
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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í.
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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)
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
L02 – Conceptos Básicos:Verificación
Usted debe estar en capacidad de:Comprender los conceptos básicos de
SCMComprender la relación entre estos
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos 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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
Procedimiento de Control de Cambios
[RUP, 2004]
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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]
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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?
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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)
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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)
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
Conflictos de Integración
Asegúrese que su código siempre se construye confiablemente haciendo una Construcción de Integración periódicamente
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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.
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
Recursos de CM
Herramientas, técnicas y equipos a utilizar
Personal Capacitación requerida para
implementar las actividades de CM
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
The End!
Gracias!!
melperez@ieee.org
(c) 2005, Ing. Melvin PérezFundamentos 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 (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
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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/
(c) 2005, Ing. Melvin PérezFundamentos de Administración de Configuración, v2.1
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