Administraci

1
Administración de la Configuración
Prof. Patricia Vargas Robles Ingeniería de
Software
2
Administración de la configuración

• Las nuevas versiones de un software de sistema se
  crean por razones como
• Diferentes Sistemas Operativos.
• Ofrecer diferente funcionalidad.
• Requerimientos particulares del usuario.
• La administración de la configuración se encarga
  del manejo de la evaluación del software de
  sistemas
• El cambio de un sistema es un trabajo de equipo.
• La administración de la configuración ayuda a
  controlar los costos y esfuerzos relacionados con
  la tarea de hacer cambios a un sistema.

3
Administración de la configuración (cont)

• Implica el desarrollo y la aplicación de
  procedimientos y estándares para manejar un
  producto de software en evolución.
• La administración de la configuración AC puede
  ser vista como parte del proceso de manejo de
  calidad.

4
Familias de sistemas
5
Estándares de la Administración de la
Configuración

• La AC debe siempre estar basada en un conjunto de
  estándares que son aplicados dentro de una
  organización.
• Los estándares deben definir como los objetos se
  identifican, cómo se controlan los cambios y cómo
  se manejan las nuevas versiones.
• Los estándares pueden estar basados en estándares
  externos para la administración de la
  configuración (Por ejemplo el estándar que provee
  la IEEE para la administración de la
  configuración).
• Algunos estándares existentes están basados en el
  modelo de cascada. Se necesitan nuevos estándares
  para el modelo evolutivo.

6
Desarrollo concurrente y pruebas

• Suponga que se ha acordado las 2 de la tarde para
  la entrega de un sistema y sus componentes.
• Una nueva versión de un sistema se ha construído
  con dichos componentes.
• Esta nueva versión se prueba usando pruebas
  predefinidas.
• Las fallas que se descubren durante el proceso de
  prueba se documentan y se devuelven a los
  desarrolladores del sistema.

7
La construcción frecuente de sistemas.

• Es más fácil encontrar problemas en las primeras
  etapas del proceso.
• Esto obliga a los desarrolladores a no derribar
  el edificio.
• Se requiere de una administración de cambios
  apropiada para mantener registros de los
  problemas que se descubren y reparan.

8
Planeamiento de la Administración de la
Configuración.

• Todos los productos del proceso de software deben
  ser administrados
• Especificaciones.
• Diseños.
• Programas.
• Datos de prueba.
• Manuales de usuario.
• Miles de documentos separados deben ser generados
  para un sistema grande y complejo.

9
El plan de Administración Configuración

• Define los tipos de documentos que se deben
  administrar. Además el esquema para nombrar los
  archivos.
• Define quién tiene responsabilidad de los
  procedimientos de la Administración de la
  Configuración.
• Define políticas de control de cambio y manejo de
  versiones.
• Define la información que debe ser guardada.

10
El plan de Administración Configuración (cont).

• Describe las herramientas que deberían ser usadas
  para ayudar el proceso de administración de la
  configuración y cualquier limitación de uso.
• Define el proceso de uso de la herramienta.
• Define la base de datos de administración de la
  configuración que debe ser usada para guardar la
  información de la configuración.

11
Identificación de configuración de objetos.

• Los proyectos grandes típicamente producen miles
  de documentos que deben ser identificados de
  forma única.
• Algunos de estos documentos deben ser conservados
  durante todo el período de vida del software.
• El esquema para nombrar documentos debe ser
  definido, de manera que los documentos
  relacionados tengan nombres relacionados.
• Un esquema jerárquico es probablemente la
  aproximación más apropiada.

12
La base de datos de configuración

• Toda la información de la Administración de la
  Configuración debe ser almacenada en una base de
  datos.
• Debe permitir consultas que permitan responder
• Quién tiene una versión particular del sistema.
• Que plataforma debe ser utilizada para correr una
  versión particular.
• Cuáles versiones se afectan con un cambio de
  componente X.
• Cuántos errores reportados tiene la Versión X.
• La Base de datos de Administracíón de la
  Configuración debe preferiblemente estar ligada
  al software que maneja.

13
Implementación de una base de datos para
Administración Configuración

• Puede ser parte de un ambiente integrado para dar
  soporte al desarrollo de software.
• La base de datos para la administración de la
  configuración y los documentos asociados deben
  ser mantenidos en el mismo sistema.
• Las herramientas CASE deben estar integradas con
  ésto, de manera que exista una relación estrecha
  entre las herramientas CASE y las herramientas de
  administración de la configuración.
• Comúnmente, la base de datos AC se mantiene
  separadamente, para lograr que sea más barato y
  flexible.

14
Administración de cambios

• Los sistemas de software afrontan diversos
  cambios
• Por parte de los usuarios.
• Por parte de los desarrolladores.
• Por las fuerzas de mercado.
• El manejo de cambios debe almacenar información
  de estos cambios. Debe asegurarse que se
  implementaron de la mejor manera (costo, etc).

15
El formulario para solicitud de cambios

• La definición de un formulario para solicitar
  cambios es parte del proceso de control de
  cambios.
• Este formulario almacena el cambio que se
  propone, la persona que solicita, la razón por la
  que se sugiere el cambio, y la urgencia del
  cambio.
• También almacena la evaluación del cambio, el
  análisis del impacto, el costo del cambio y
  recomendaciones.

16
Herramientas para el control de cambios

• Un problema importante en el manejo de cambios es
  manejar el estado actual del cambio.
• Las herramientas para el control de cambios
  mantienen registros de cada cambio y aseguran que
  las solicitudes de cambio lleguen a las personas
  correctas en el tiempo correcto.

17
Pizarra de control de cambios

• Los cambios deben ser revisados por un grupo
  externo que decide cuando son ó no efectivos en
  costo, desde un punto de vista estratégico y
  organizacional (y no desde un punto de vista
  técnico).
• Este grupo se llama comúnmente la pizarra de
  control cambios. Debe ser independiente de los
  responsables del proyecto del sistema.
• El grupo pizarra control cambios puede incluir
  representantes del cliente y el equipo
  contratista.

18
Historial de cambios

• Esto es un archivo de cambios aplicados a un
  documento ó a un componente de código.
• Debe almacenar, el cambio hecho, el motivo del
  cambio, el nombre de la persona que hizo el
  cambio y cuándo fue implementado.
• Puede ser incluído como un comentario dentro del
  código. Si se sigue un estándar, es fácil que un
  programa futuro procese esta información de ser
  necesario.

19
Información de encabezado
20
Manejo de versiones

• Invente un esquema de identificación para las
  versiones del sistema.
• Planee cuando a nueva versión del sistema se
  producirá.
• Asegúrese que los procedimientos de manejo de
  versiones se aplican apropiadamente.
• Planee y distribuya las nuevas versiones del
  programa.

21
Versión/Variante/Lanzamiento

• Versión Una instancia de un sistema, cuya
  funcionalidad difiere en alguna forma de otras
  instancias de sistema.
• Variante Una instancia de un sistema que es
  funcionalmente idéntica pero no distinta de otras
  instancias del sistema.
• Lanzamiento Una instancia de un sistema que es
  distribuido a usuarios fuera del equipo de
  desarrollo.

22
Identificación de versiones

• Los procedimientos para la identificación de
  versiones deben definir un forma no-ambigua de
  identificar los compontes de una versión.
• Existen tres técnicas básicas para la
  identificación de un componente
• Numeración de la versión.
• Identificación basada en un atributo.
• Identificación del cambio.

23
Numeración de versiones

• Un esquema simple de nomenclatura usa una
  derivación linear. Por ejemplo
• V1, V1.1, V1.2, V2.1, V2.2, etc
• La estructura actual de derivación es un árbol o
  red, en lugar de una secuencia.
• Los nombres no son significativos.
• Un esquema de nomenclatura jerárquico pemite que
  existan menos errores en la identificación de las
  versiones.

24
Estructura de derivación de versiones
25
Identificación basada en atributos

• Los atributos pueden ser asociados con una
  versión con una combinación que identifique
  claramente esa versión.
• Ejemplos de atributos son fecha, creador,
  lenguaje de programación, cliente, estado, etc.
• Esto es más flexible que un esquema explícito de
  nomenclatura.
• De cualquier modo, puede causar problemas. El
  conjunto de atributos debe ser escogido de manera
  que cada versión se identifique de una manera
  única.
• En la práctica, una versión también necesita un
  nombre asociado para una fácil referencia.

26
Consultas basadas en atributos

• Una ventaja importante de una identificación
  basada en atributos es que puede ofrecer
  consultas de manera que usted puede encontrar
  la versión más reciente de un programa, etc.
• La consulta selecciona una versión dependiendo
  del valor de un atributo (lenguaje, plataforma,
  fecha, etc).

27
Identificación basada en el cambio

• Integra las versiones y los cambios hechos para
  crear esas versiones.
• Es usado para sistemas y no tanto para
  componentes.
• Cada cambio propuesto tiene un conjunto de cambio
  que describe los cambios hechos para implementar
  la modificación.

28
Manejo de lanzamientos

• Los lanzamientos deben incorporar cambios
  forzados por errores descubiertos por usuarios y
  por cambio de hardware.
• Deben incorporar también nuevas funcionalidades
  al sistema.

29
Lanzamiento de sistemas

• No es simplemente un conjunto de programas
  ejecutables.
• También debe incluir
• Archivos de configuración que definan cómo el
  lanzamiento debe ser configurado para una
  instalación particular.
• Archivos de datos necesarios para que el sistema
  opere.
• Un programa de instalación ó un script para el
  intérprete de comandos para instalar el sistema
  en el hardware destino.
• Documentación electrónica y en papel.
• Publicidad asociada.
• Los sistemas actualmente se lanzan en discos
  ópticos (CD,DVD) ó como una serie de archivos
  descargables desde la red Internet.

30
Problemas con los lanzamientos

• Cliente puede no querer una nueva versión del
  sistema.
• Puede estar contento con el sistema actual. El
  sistema nuevo puede ofrecer funcionalidad no
  deseada.
• El manejo de un lanzamiento no debe asumir que
  todas los lanzamientos previos han sido
  aceptados. Todos los archivos requeridos para un
  lanzamiento deben ser re-creados cuando una nueva
  versión se instala.

31
La decisión de un lanzamiento

• Preparar y distribuir un lanzamiento de un
  sistema es un proceso caro.
• Factores como la calidad técnica del sistema,
  competencia, requerimientos de mercado y cambio
  de requerimientos por parte del cliente debe
  influenciar la decisión de cuándo realmente debe
  llevarse a cabo el lanzamiento de un producto.

32
Creación de un lanzamiento

• La creación de un lanzamiento requiere recolectar
  todos los archivos y la documentación requerida
  para crear un lanzamiento de sistema.
• Las descripciones de configuración deben ser
  escritas para diferente harware y los scripts de
  instalación deben ser escritos.
• El lanzamiento específico debe ser documentado
  para almacenar exactamente que archivos se usaron
  para crearlo. Esto permitirá re-crearlo de ser
  necesario.

33
Construcción de un sistema

• Es el proceso de compilar y ligar componentes
  de software en un sistema ejecutable.
• Sistemas diferentes son construídos a base de
  diferentes combinaciones de componentes.

34
Herramientas CASE para el manejo de la
configuración

• Los procesos para la administración de la
  configuración están estandarizados y requiere
  aplicar procedimientos predefinidos.
• Grandes cantidades de datos pueden ser manejados.
• Es imprescindible el uso de herramientas CASE
  para el manjeo de la configuración.

35
Puntos clave

• La administración de la configuración es la
  administración del cambio de un sistema a un
  producto de software.
• Un esquema formal para la nomenclatura de los
  archivos debe ser establecida y los documentos
  deben ser manejados en una base de datos.
• La base de datos de configuración debe almacenar
  información acerca de los cambios y las
  solicitudes de cambio.
• Un esquema consistente de identificación de
  versiones debe ser establecido usando numeración
  de versiones, atributos o conjuntos de cambios.

36
Puntos clave

• Los lanzamientos de un sistema incluyen código
  ejecutable, configuración para los datos,
  archivos de configuración y documentación.
• La construcción de un sistema requiere ensamblar
  componentes para convertirlos en un sistema.
• Las herramientas CASE están disponibles para dar
  soporte a todas las actividades del manejo de la
  configuración.