Administración de la Configuración

¿POR QUÉ ES NECESARIO ADMINISTRAR LAS CONFIGURACIONES DE SOFTWARE DE LOS PRODUCTOS?

Cambio constanteLeyes de Lehman:

• Cambio continuo: Un sistema utilizado en un entorno real necesariamente debe cambiar o llegara a ser progresivamente menos útil a ese entorno.

• Incremento de la complejidad: Puesto que un sistema evolutivo cambia, su estructura tiende a ser más compleja. Se deben dedicar recursos extra para preservar y simplificar la estructura.

• Evolución prolongada del sistema: La evolución del sistema es un proceso autoregulatorio. Una vez que se excede de un límite de cambios, éstos introducen nuevas fallas que degradan la funcionalidad del sistema.

Cambio constanteLeyes de Lehman:

• Estabilidad organizacional: Un cambio en los recursos tiene efectos imperceptibles en la evolución a largo plazo del sistema, confirmando que los equipos de trabajo grandes son improductivos por la sobrecarga de comunicación

• Conservación de la familiaridad: – Entre más funcionalidad se agregue, habrán más

fallos. – No deben hacerse presupuestos para incrementos

grandes de funcionalidad en cada versión, sin tomar en cuenta la necesidad de la reparación de fallas.

Casos Reales: Síntomas de problemas• La última versión del código no se encuentra almacenada en

ningún medio de almacenamiento.

• Se están utilizando versiones incorrectas (p.e. desactualizadas) de documentos u otros objetos.

• Se efectuaron cambios simultaneos al código por más de un programador, resultando en la pérdida de algunos cambios

• Un programa probado y listo para liberar de repente no funciona.

• Nadie sabe cuales módulos constituyen el “software delivery” entregado al cliente.

• Versiones erróneas de elementos de configuración se están administrando como parte de la versión oficial del software

Necesidades• Ayuda a reducir problemas coordinando los

productos generados por los integrantes que trabajan en un proyecto común.

• Sin control, su trabajo frecuentemente entrará en conflicto, resultando en problemas tales como: – Modificaciones simultáneas: Cuando dos o más

personas trabajan separadamente en el mismo documento, el último en hacer los cambios puede destruir todo el trabajo de los anteriores.

– Código compartido: Cuando un error es arreglado en un programa compartido por varias personas, algunos de ellos no se enteran.

Necesidades– Código común: En programas grandes, si una función

es modificada, el resto del equipo debe ser notificado.

– Versiones: La mayoría de los sistemas grandes son desarrollados en forma evolutiva. Con un release siendo utilizado por los clientes, otro siendo testeado, y un tercero en desarrollo, el arreglo de errores debe propagarse entre ellos. Si el error es detectado por el cliente, el error debiese propagarse en todas las versiones. Si el error es detectado en el release en desarrollo, debiese arreglarse en las versiones que lo contienen. Todo esto puede producir grandes confusiones en sistemas grandes.

NecesidadesEstos problemas se producen por la confusión y falta de coordinación.

La solución es contar con un sistema de control que responda las siguientes preguntas:

• ¿Cuál es mi configuración actual?

• ¿Cuál es su estado?

• ¿Cómo controlo cambios en mi configuración?

• ¿Cómo le informo al resto de mis cambios?

• ¿Qué cambios se han hecho a mi software?

• ¿Afectan los cambios de otros a mi software?

Definiciones y Conceptos• Administración de la Configuración (AC): Es el

arte de coordinar el desarrollo de software para minimizar la confusión... Es el arte de identificar, organizar y controlar las modificaciones o cambios que sufre el software que construye un equipo de programación. ..Babich

• Elemento de configuración de software (ECS): Todos aquellos productos que conforman el proyecto (documentos, códigos, manuales), tanto los que se entregan al cliente como los que no

Propósito de la AC

“Establecer y mantener la integridad de los elementos de configuración de software a lo largo del ciclo de vida del proyecto”

Metas y CompromisoMetas:

• Planear las actividades de la AC.

• Identificar los elementos a administrar, controlarlos y ponerlos a disposición.

• Controlar los cambios en estos elementos.

• Informar del estado de esos elementos a los grupos involucrados.

Compromiso:

• El proyecto debe seguir una política organizacional estricta, para implementar la AC

Habilidades requeridas

• Debe existir un comité que tiene la autoridad para administrar los elementos del proyecto.

• Debe existir un equipo de AC responsable de coordinar e implementar la AC del proyecto.

• Existen los recursos necesarios para realizar las actividades de la AC.

• Los miembros del equipo de AC son entrenados con objetivos, procedimientos y métodos para realizar las actividades de la AC.

• Miembros de otros equipos son entrenados para que realicen sus propias actividades de AC

IDENTIFICACIÓN DE LA CONFIGURACIÓN

Identificación de la Configuración• Grandes proyectos producen miles de documentos.

• Algunos de esos documentos deben mantenerse durante el tiempo de vida del software.

• El esquema del documento debe ser definido.

• Un esquema jerárquico de multi-niveles es probablemente la aproximación más flexible.

• Selección de los elementos: Todo producto resultado del ciclo de vida y de la metodología de desarrollo de software: Planes, Especificaciones de Requerimientos, Documento de Diseño, Herramientas de software, Componentes (fuente y objeto), Bibliotecas de software, Referencias

Identificación de la Configuración

• Re lac iones ent re lo s ECS : Re lac iones estructurales entre dist intos elementos seleccionados y sus partes constituyentes.

Ejemplo:

• El diagrama de la base de datos depende del documento de diseño.

• El diagrama de casos de uso, depende del documento de requerimientos.

Métodos de Identificación

• Nivel Básico: ítems de configuración, componentes o unidades son etiquetados con un nombre único

• Etiquetado (labeling/tagging): identifica relaciones entre dichas entidades de configuración

• Etiquetado de archivos (File labeling): un conjunto de archivos son asociados sin especificar las versiones/revisiones de cada uno. Reglas son usadas para identificar cuales versiones/revisiones fueron usadas en un momento determinado del tiempo

Ejemplo de Esquema de Identificación

• Nombre alfanumérico para un software producto/sistema, por ejemplo: SIST1-

• Versión funcional Mayor, por ejemplo: 01

• Versión funcional Menor, por ejemplo: 02

• Revisión correctiva, por ejemplo: 00

• Estado, Revisión interna: usado internamente para dar seguimiento a su estado en su proceso de construcción, por ejemplo D.03indica que este es la tercer versión de desarrollo-testing del producto

• Ejemplo Final: SIST1-.01.02.00.D.03

Esquema de identificación

Esquema de nombres únicos para identificar los elementos de configuración de software.

• Pueden ser nombres largos o nombres cortos significativos (abreviaturas)

– DocumentoRequerimientos

– DOC_Requerimientos

– DOC_ERS

– DERS

Esquema de identificación

Esquema: – XXX_YYY_ZZZ_AA[AA#]: – Ejemplos:

• QSS_CIL_DOC_DIS • QSS_CIL_DGR_ER • QSS_CIL_DOC_AVA1

– XXX : Nombre de la organización (QSS) – YYY : Nombre del proyecto (CIL) – ZZZ : Tipo del ECS (DOC, DGR, CMP, PAG) – AA[AA] : Abreviatura del ECS de 2 a 4 letras – # : número de consecutivo

Líneas Base (LB)

• Se deben establecer al inicio del proyecto.

• Conforman una serie de ECS en sus versiones finales.

• Se crean como puntos de control (hitos o milestones).

• Por ejemplo: – LB_Requerimientos – LB_Diseño – LB_Programación – LB_Pruebas – LB_Implantación

Bibliotecas de Software

• Colección controlada y documentada de los ECS del proyecto.

• Organizan los ECS de una manera física.

• Su estructura se guía por las líneas base del proyecto y la metodología

Procedimientos Transición• No sólo es necesario definir LB o Bibliotecas

• Es necesario definir procedimientos para cambiar entre las distintas bibliotecas:

• Para cambiar de la B_Trabajo a B_Integración el ECS debe de haber sido probado previamente por su creador.

• Para cambiar de B_Integración a B_Producción el ECS debe de haber sido probado en conjunto por el equipo de trabajo.

• Todos los viernes se respaldarán B_Trabajo, B_Integración y B_Producción en B_Respaldo.

CONTROL DE LA CONFIGURACIÓN

Control de la configuración

• Los sistemas de software son sujetos a requerimientos continuos de cambios: – de los usuarios – de los desarrolladores – del mercado

• El control de la configuración permite administrar estos cambios y asegurar que sean implementados de la manera mas efectiva.

Tipos de cambios

• Cambios Formales: – Son aquellos cambios cuyo ECS ya ha sido aprobado por

el cliente y se debe modificar una línea base para su realización.

– Cambios que impliquen todo un proceso de administración del cambio.

• Cambios Informales: – Son aquellos cambios cuyo ECS no ha sido aprobado por

el cliente y se debe modificar una pequeña sección para su realización.

– Pequeños cambios que se pueden aplicar sin necesidad de crear todo un proceso de administración del cambio

Comité de control de cambios• Decide si se acepta el cambio o no.

• Considera el cambio desde el punto de vista estratégico y organizacional.

• No tanto desde el punto de vista técnico.

• Decide si el cambio se justifica económicamente y si existen buenas razones organizacionales para aceptarlo.

• Proyecto grande: incluye a clientes y contratistas

• Proyecto pequeño: director del proyecto y 1 o 2 ingenieros de software. (puede ser una sola persona)

GENERACIÓN DE INFORMES

Generación de Informes de Estado de las Configuraciones

¿ Cómo rastrear un cambio ?

– Un problema mayor en el control de la configuración es el rastreo de el estatus de los cambios

– Existen herramientas que permiten llevar cuenta del estatus de cada petición de cambio y asegurar que las peticiones de cambios se envían a la gente adecuada y al momento adecuado.

– Integrando correo-electrónico al sistema permitirá distribuir las peticiones de cambios

Pizarrón de control de cambios

• Los cambios deben ser revisados por un grupo externo que decida si es efectivo en costos desde un punto de vista de la organización, en vez de el punto de vista técnico

• Debe de ser independiente del responsable del sistema.

• Puede incluir representantes de los clientes y los contratistas.

Historia de derivaciones

• Es el registro de los cambios aplicado a un documento o un componente de código

• Debe registrar, los cambios hechos, la razón de los cambios, quien hizo los cambios y cuando fueron implementados.

• Podrían estar incluidos como comentarios en el código.

Informe de Estado General

• Este informe pretende dar una visión global del estado de los ECS.

• Listado de los ECS con su versión más actualizada con el propietario actual.

• Muestra cuellos de botella y ECS dependientes que han atrasado la construcción de otros ECS

Informe de Estado

• Para este informe es necesario tener una bitácora (log) de todos los movimientos realizados con cada uno de los ECS.

• Para cada ECS es necesario: – Fecha de Creación – Creador – Detalle de las modificaciones realizadas:

• Fecha de la modificación • Autor de la modificación

Informe de solicitudes de cambio

• Este informe pretende brindar un estado de las solicitudes de cambio:

• Incluye: – Número de solicitud – Responsible – Estado – Comentarios

• Debe ser acumulativo de todos los cambios solicitados al proyecto.

AUDITORIAS DE LAS CONFIGURACIONES

Auditorías de la Configuración• Determinan cuáles elementos de configuración

de software cumplen con las características funcionales y físicas para lo que fueron creadas.

Tipos: • Funcionales: Asegurar que el ECS auditado es

consistente con las especificaciones de su creación.

• Físicas: Asegurar que el diseño de los distintos ECS son consistentes con el producto construido.

• Del proceso: Mezcla de ambas en cualquier momento del proceso de desarrollo de software. Verificando la realización con detalle del proceso.

HERRAMIENTAS Y TENDENCIAS

Herramientas y Tendencias

• Algunas herramientas: – Microsoft:

• Visual Team Foundation • GitHub Plug in

– IBM Rational Software: • Clear Case • Clear Quest

– Borland • StartTeam

Problemas

• Aplicaciones muy grandes y heterogéneas

• Sitios distribuidos

• Aplicaciones muy longevas

• La tecnología es limitada

• No existe una “bala de plata” en AC

• Diferentes vistas, roles y expectativas de la AC

• Las personas reaccionan negativamente al control y a las restricciones.

• Destinos cambiantes

• Muchas clases de mantenimiento (correctivo, adaptativo, perfectivo)