Tema 8 Gestión de la Configuración del Software · La línea de base se puede considerar una...

Tema 8 Gestión de la Configuración del Software

Ingeniería del Software I

[email protected]

www.kybele.eswww.kybele.etsii.urjc.es Ingeniería del Software I – 2011/2012

Gestión de la Configuración del Software.

Plan de Gestión de la Configuración.

Índice


Gestión de la Configuración del Software

Procesos principales Procesos de Soporte

Procesos generales

Adquisición

Suministro

Explotación

Mantenimiento

Desarrollo

Gestión de la Config.

Asegu. de la calidad

Verificación

Validación

Revisión conjunta

Auditoría

Documentación

Resolución problemas

Gestión

Mejora

Infraestructura

Formación


Gestión de la configuración del SoftwareActividades principales

Identificar todos los productos/elementos que vamos generando durante el proceso de desarrollo.

Evaluar y controlar los cambios de estos elementos, mediante un control de cambios y un control de versiones. Se controla la evolución del producto.

Facilitar la trazabilidad del producto. Para saber en qué se convierte cada requisito, o de qué requisito proviene cada elemento.

Generación de informes.


Durante el desarrollo de un SI (sistema de información) los cambios son inevitables (cambios en las condiciones o normas comerciales, nuevas necesidades del cliente, nuevas restricciones presupuestarias, etc.) . Tantos cambios pueden generar confusión en el grupo de desarrollo si no se lleva una buena gestión.

Aplicar un mecanismo de control para todos los productos que se van generando se convierte en algo imprescindible.

El arte de coordinar el desarrollo de software para minimizar la confusión, se denomina gestión de la configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que

construye un equipo de trabajo. La meta es maximizar la productividad minimizando los errores. (BABICH)

Gestión de la configuración del Software ¿Por qué?


Tener identificados y controlados los productos que se van generando. (Identificación de la configuración)

Establecer un protocolo de actuación para llevar el control de los cambios de estos elementos. (control de cambios)

Establecer los nexos entre una representación y otra. De tal manera, que se haga visible la evolución del elemento y pueda ser gestionada (trazabilidad)

Ayuda a la organización y comunicación dentro del mismo equipo de desarrollo o entre diferentes grupos.

Garantiza la calidad del software.

Gestión de la configuración del Software ¿Qué nos ofrece?


Gestión de la Configuración vs Mantenimiento

No se debe confundir Gestión de la Configuración del Software (GCS) con mantenimiento.

Mantenimiento: conjunto de actividades que se produce después de que el software se haya entregado al cliente y esté en funcionamiento.

GCS: Conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina cuando el sw queda fuera de circulación (durante todo el ciclo de vida del sw)


Gestión de la Configuración del Software

Definición IEEE:

La Gestión de la Configuración del Software es el conjunto de actividades y procesos necesarios para identificar y definir los elementos de la configuración de un sistema, controlando la

entrega y los cambios de estos elementos a través del ciclo de vida del sistema, almacenando el estado de los elementos de la configuración y de las peticiones de cambio, y verificando que se

cumple respecto a los requisitos especificados.


¿Qué es un Elemento de la Configuración del Software (ECS)?

Cualquier producto sw que se puede definir y controlar de forma separada. Se controlan los cambios.

¿Qué es la Línea de Base (LB)?

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios. (IEEE, 1990)

Gestión de la configuración del Software Conceptos Básicos


Clasificación de los ECSs:

Proceso de

Ingeniería

Programas• Código fuente

• Ejecutables

DatosDocumentos



Ejemplo de elementos de la configuración:

La especificación de requisitos de software.

Diagramas de colaboración de análisis.

El diseño detallado.

Un prototipo.

Programas en código fuente.

El manual de usuario.

El plan de viabilidad.

El plan de negocio.

El modelo de datos.



Un producto se convierte en una línea de base, solamente después de haber sido revisado y aprobado.

Es un punto de referencia en el desarrollo del software.

Es una foto del sistema en un cierto instante de su evolución, y está asociada a un hito en el desarrollo (Bryan y Siegel)

Los ECSs que conforman la línea de base han sido evaluados mediante una Revisión Técnica Formal (RTF).

Un elemento que pertenece a la línea de base está almacenado en la base de datos del proyecto (biblioteca del proyecto o depósito de software).

Gestión de la configuración Línea de Base


Para realizar algún cambio sobre un ECS de la línea de base se extrae de la biblioteca dejando siempre una copia.

Para cualquier cambio se debe seguir un procedimiento formal.

La línea de base se puede considerar una imagen congelada, un punto de referencia: “producir software a partir de una línea de base es como caminar por encima del agua, es más fácil si está congelada”



Línea base (LB). Ejemplos

LB Funcional: al final de la fase de análisis. Plan de análisis, req. del sistema, plan de calidad, plan de gestión de la configuración, plan de pruebas de aceptación.

LB de Asignación: al final de la fase de diseño de alto nivel. Arquitectura, interfaces de subsistemas, plan de pruebas de sistema.

LB de Diseño: al final de la fase de diseño detallado. Diseño de subsistemas y plan de pruebas de integración.

LB de Producto: al final de la codificación. Código fuente, objeto y ejecutable, resultados de pruebas de integración y versión preliminar de los manuales.

LB de Explotación: al final de la implantación. Resultados de pruebas de sistema y documentación de usuario.



¿Qué es una Revisión Técnica Formal?

Una Revisión Técnica Formal (RTF) es una actividad para garantizar la calidad del software.

Es una clase de revisión que incluye recorridos, inspecciones, revisiones cíclicas y otro pequeño grupo de evaluaciones técnicas del software. Se lleva a cabo mediante una reunión, y tendrá éxito si está bien planificada, controlada y atendida.

El centro de atención de la RTF es un producto de trabajo.

Objetivos: o Descubrir errores en la función, la lógica o la implementación de

cualquier representación del software.

o Verificar que el software bajo revisión alcanza sus requisitos.

o Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos.

o Conseguir un software desarrollado de forma uniforme.

o Hacer que los proyectos sean más manejables.



¿Características de la reunión? Deben convocarse para la revisión entre 3 y 5 personas.

Se debe preparar por adelantado sin que requiera más de dos horas de trabajo a cada persona.

La reunión no debe durar más de 2 horas.

Una reunión es frecuentemente un evento donde se aprovechan unos minutos y se pierden horas.

Protocolo de actuación: El individuo que ha desarrollado el producto informa al jefe del proyecto (JP) de que

el producto está terminado y que se requiere una revisión.

El JP contacta con el jefe de revisión (JR), que evalúa la disponibilidad del producto, genera copias del material del producto y las distribuye a dos o tres revisores para que se preparen por adelantado. Cada revisor estará entre una y dos hora revisando el producto, tomando notas y

familiarizándose con el trabajo. A la par, el JR revisa el producto y establece una agenda para la reunión de revisión que normalmente queda convocada para el día siguiente.



Protocolo de actuación (II): La reunión de revisión es llevada a cabo por el JR, los revisores y el productor. Uno de

los revisores registra de forma escrita todos los sucesos importantes que se producen durante la revisión.

Al final de la revisión todos los participantes a la RTF deben decidir si: Se acepta el producto sin modificaciones.

Rechazan el producto debido a los serios errores encontrados (una vez corregidos, se tiene que hacer otra revisión).

Se acepta el producto provisionalmente (errores menores que deben ser corregidos, sin necesidad de una posterior revisión).

Registro e informe de la revisión Durante la RTF se van registrando todas las pegas que vayan surgiendo. El informe

sumario debe responder a tres preguntas: ¿Qué fue revisado?

¿Quién lo revisó?

¿Qué se descubrió y cuáles son las conclusiones?

Se adjunta al registro histórico del proyecto y se envía al jefe de proyecto y a las partes interesadas.



Directrices para la revisión Revisar el producto, no al productor: no debe ser algo inquisidor para el productor.

Debe llevarse a cabo en un tono distendido y productivo.

Fijar una agenda y mantenerla: La RTF debe seguir un plan de trabajo concreto. El JRes quien se encarga de llevar a cabo este plan.

Limitar el debate: No se debe perder el tiempo debatiendo. Dejarlo para otro momento.

No intentar resolver cualquier problema que se ponga de manifiesto: La resolución de los problemas se lleva a cabo después de la reunión por el productor.

Tomar notas escritas: Es bueno tomar notas en pizarra para que el resto de revisores puedan comprobar la información que se recoge.

Limitar el número de participantes e insistir en la preparación anticipada: Dos personas mejor que una, pero catorce no son mejores que dos. Mantener el número mínimo y necesario. Importante que todos se lo preparen por anticipado.

Disponer de agenda: para que la RTF sea efectiva

Entrenar formalmente a los revisores.

Repasar las revisiones anteriores.



Identificación de la configuración.

Control de cambios a la configuración.

Control de versiones.

Auditoría de la configuración.

Generación de informes de estado.

Gestión de la configuración Actividades


Identificar los ECSs de forma única, asignarles una descripción, organizarlos y clasificarlos.

Establecer relaciones entre los elementos identificados. Estas relaciones ayudan a evaluar el impacto del cambio.

La identificación de los ECSs ayuda a su gestión y al control de su evolución. Para un ECS se puede elaborar un grafo de evolución que describe la historia de los cambios de un objeto.

Identificación de la configuración


Definir la base de datos donde se guardarán todoslos elementos de la configuración y todas las relaciones entre ellos.

Definir el conjunto de procedimientos para definir, manipular y recuperar los datos de los elementos de la configuración.

Identificación de la configuración


Es la parte de la Gestión de la Configuración del Software que se encarga de controlar cualquier modificación, tanto de características como del comportamiento, del sistema.

El control de cambios proporciona mecanismos para gestionar la modificación del sistema, normalmente combinando procedimientos humanos con el uso de herramientas automáticas (SVS, Plastic SCM, SourceSafe…)

Existen diferentes niveles en la gestión de los cambios dependiendo del ECS que se quiera modificar:

Informal: si el ECS no forma parte de la Línea de Base (LB).

Semiformal: cuando el ECS en cuestión no forma parte de la LB, pero su cambio afecta a ECS que sí la conforman.

Formal: cuando el ECS forma parte de la LB.

Control de cambios de la configuración


El control de cambio es vital. Pero las fuerzas que lo hacen necesario también lo hacen molesto. Nos preocupamos por el cambio porque una diminuta perturbación en el código puede crear un gran fallo en el producto. Pero también puede reparar un gran fallo o habilitar excelentes habilidades nuevas.

Nos preocupamos por el cambio porque un desarrollador pícaro puede hacer fracasar el proyecto; sin embargo, las brillantes ideas nacidas en la mente de estos pícaros, y un pesado proceso de control de cambio pueden disuadirle de hacer un trabajo creativo. (James Bach)

Protocolo de actuación para la gestión de cambios (Nivel formal):

Mecanismos para la solicitud y aprobación del cambio.

Mecanismos para el seguimiento y control del cambio.



Petición del cambio:

o Se debe definir un formulario de solicitud de cambios, completo y fácil de rellenar. Donde se pida la siguiente información:

Descripción general del cambio solicitado: ¿Qué se tiene que cambiar?

Motivo de la solicitud. ¿Por qué se tiene que cambiar?

Persona o grupo que hace la petición ¿Quién solicita el cambio?

ECSs afectados por el cambio. ¿Qué se ve afectado?

Análisis y evaluación de la petición:

o Se tienen que establecer los criterios de evaluación de los cambios . Estos criterios los propone el Comité de Control de Cambios (CCC).

o Criterios: prioridad, complejidad, estimación temporal, impacto.

Control de cambios de la configuraciónMecanismos para la solicitud y aprobación del cambio


Aprobación o desaprobación de los cambios.

o Los resultados de la evaluación se presentan mediante un informe de cambios al CCC (una persona o un grupo de personas ) para que tome la decisión final de aprobarla o desestimarla .

o Para un cambio aprobado se genera una Orden de Cambio de Ingeniería (OCI) que describe el cambio a realizar, las restricciones, los criterios de revisión y de auditoría.

o El objeto a cambiar se da de baja de la base de datos y se crea la siguiente versión del ECS.

Implementación de los cambios

o Actividades para implementar los cambios.

Control de cambios de la configuraciónMecanismos para la solicitud y aprobación del cambio


Garantizar que el cambio se implementa adecuadamente.

Evaluación del cambio.

Informar del cambio a todos aquellos que puedan estar interesados.

Control de cambios de la configuraciónMecanismos para el seguimiento y control del cambio


Versiones de los ECSs

o Combina procedimientos y herramientas para gestionar las versiones de los ECSs creados durante el proceso del software.

o El control de las versiones puede ser tan simple como asociar el número específico de la versión a cada componente o tan complejo como asociar una cadena de variables lógicas.

Versiones de los sistemas

o Una versión del sistema es una instancia del sistema que difiere en algunos aspectos de otras instancias.

o Una nueva versión puede ofrecer una nueva funcionalidad o haber arreglado los errores, defectos o problemas de una versión anterior.

o Se deben conocer todos los elemento asociados a una versión determinada del sistema.

Control de versiones


Si entre dos instancias (tanto ECS o sistema) existen diferencias significativas, estamos ante dos versiones diferentes.

Si las diferencias son poco importantes, estamos ante dos variantes.

Una posible representación de las diferentes versiones y variantes del sistema se puede mostrar de manera sencilla con un grafo de evolución, donde cada nodo del grafo es una versión completa del software.

1.0 1.1

1.1.1

1.2

2.0 2.1

1.3

Control de versiones


Una auditoría es el medio que permite evaluar el trabajo que se ha hecho, y determinar si se han conseguido los resultados previstos.

Una auditoria tiene que garantizar que las diferentes LBs del producto, se corresponden con la descripción de sus elementos, con su especificación y su documentación, antes de la entrega del producto al cliente.

Es la actividad más costosa, de la Gestión de la Configuración, en tiempo y recursos.

Garantiza que los elementos auditados están completos y siguen las normas de GCS.

Auditorías de configuración


Como resultado produce informes de estado de la Configuración.

Factores que tiene en cuenta: ¿Se han seguido las pautas descritas en la OCI?

¿Se ha realizado el cambio especificado?

¿Se ha informado de los cambios?

¿Se han actualizado los ECSs relacionados?

¿Se ha seguido el estándar de la organización?

¿Es correcto (técnicamente) el cambio?



Se distinguen tres tipos de actividades:

Revisiones de fase: al final de cada fase para examinar los productos de esa fase.

Revisiones de cambio: para aprobar que los cambios realizados sobre una línea de base son correctos.

Auditorías propiamente dichas: al final del proceso de desarrollo, para examinar el producto en conjunto.



El objetivo principal es mantener a los usuarios, desarrolladores y gestores informados sobre el estado de la configuración.

Definen: ¿Qué pasó?

¿Quién lo hizo?

¿Cuándo pasó?

¿Qué más se vio afectado?

¿Cuándo se obtienen? Cuando se crea o actualiza un ECS

Cuando se emite una “orden de cambio”

Cada vez que se realiza una actividad de auditoría

Generación de informes de estado


Generación de informes de estado


Gestión de la Configuración.

Plan de Gestión de la Configuración.

Índice


Plan de gestión de configuración software

Plan de GCS IEEE Std. 828-2005

Secciones:

I. Introducción

II. Gestión de la GCS (¿quién?)

III. Actividades de GCS (¿qué?)

IV. Calendario de GCS (¿cuándo?)

V. Recursos de GCS (¿cómo?)

VI. Mantenimiento del plan de GCS

Plan de Gestión de la Configuración


Sección I. Introducción. Partes incluidas:

Objetivo: visión general simplificada

Elementos:

Propósito: razón de ser y audiencia. Sistema al que se

aplicará (breve).

Alcance:

Descripción del Proyecto Software

Identificación de los ECSs

Software a incluir dentro del plan

Limitaciones y suposiciones de impacto (coste,

calendario, capacidad de realizar el GCS)

Intereses del Plan: qué incluye y qué no



Elementos:

Definiciones: basadas en definiciones estándar (Punto

de control, liberación, línea base, etc).

Referencias: políticas, directivas, procedimientos,

estándares, terminología, etc.



Sección II. Gestión de la GCS:

Objetivo: Asignación de responsabilidades y

autoridades para las actividades de GCS.

Elementos:

Organización: unidades organizativas (técnicas y

de gestión), roles y relaciones entre las unidades.

Responsabilidades de la GCS: asignación de

actividades de GCS a las unidades organizativas.

Políticas, directivas y procedimientos aplicables:

impacto y uso.



Sección III. Actividades de GCS Objetivo: identificar las funciones y tareas requeridas para

gestionar la configuración del sistema.

Partes: Descripción de las tareas de GCS:

Identificación

Control de la configuración (cambios y versiones)

Generación de Informes de estado.

Auditorías y revisiones

Control de la interfaz: coordinación entre los ECS y los cambios en los elementos externos (HW, SW de soporte, etc) Interfaz software: acuerdos compartidos entre el programa y otras

entidades software

Interfaz hardware: acuerdos compartidos entre el programa y las características de cualquier hw. del entorno

Control del “subcontratista/vendedor”: gestión del software adquirido (tanto terminado como en producción)



Sección IV. Calendarios de GCS Objetivo: establecer la secuencia y coordinación para

las actividades de GCS.

Sección V. Recursos de GCS Objetivo : identificar las herramientas software,

técnicas, equipamiento, personal y entrenamiento necesario para las tareas de GCS.

Sección VI. Mantenimiento del plan de GCS Objetivo : identificar las actividades y

responsabilidades necesarias para asegurar la planificación continua de la GCS durante el ciclo de vida del proyecto.


Tema 8 Gestión de la Configuración del Software

Ingeniería del Software I

[email protected]

Tema 8 Gestión de la Configuración del Software · La línea de base se puede considerar una...

Documents

Transcript of Tema 8 Gestión de la Configuración del Software · La línea de base se puede considerar una...