Transcript Gestión de la Configuración aplicada al Modelo de Proceso

Gestión de la Configuración
aplicada al Modelo de
Proceso Incremental
Autores:
Bertune, Maximiliano
Gil, Myrian
Santoli, Lucía
Grupo 7
Temas a desarrollar
 El modelo de proceso incremental
 Gestión de la Configuración del Software
 Aproximación al modelo incremental considerada en este estudio
 Desarrollo de las actividades de la GCS
 Identificación de la configuración
 Control de cambios en la configuración
 Generación de informes de estado
 Auditoría de la configuración.
 Conclusión
Grupo 7
Modelo de Proceso Incremental
 Alternativa al clásico modelo en cascada.
 Permite dar respuesta a la ansiedad de los clientes por
obtener resultados rápidos.
 Soporta la necesidad de que los requisitos puedan cambiar
a lo largo del proceso de desarrollo.
 Se particiona el sistema en pequeños subsistemas de
acuerdo con su funcionalidad.
 En cada incremento se construye un módulo del sistema.
Grupo 7
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 programación” Babich.
 Actividades de la Gestión de la Configuración
 Identificación de la configuración
 Control de cambios en la configuración
 Generación de informes de estado
 Auditoría de la configuración.
Grupo 7
Aproximación al modelo considerada en este estudio
 Modelo incremental conformado por n+1 incrementos.
 En el primer incremento se realizarán tareas de definición del
sistema, elicitación de requisitos, clasificación y priorización de
los mismos.
El los incrementos restantes se construirán módulos del
sistema.
Incrementos pequeños (no más de 30.000 de código).
Es
indistinta la metodología utilizada dentro de cada
incremento.
Grupo 7
GCS ~ Identificación de la Configuración
 Selección de ECS (Elementos de la Configuración del Software)

La Especificación del Sistema, ERS, Plan del Proyecto,
Documento de Diseño, Documento de Arquitectura, Diagramas de
Entidad Relación de las bases de datos, Código fuente, Plan de
pruebas, Casos de prueba, Informes de errores, Manual de Usuario,
Manual de Instalación, Hardware, Software.
 La Especificación del Sistema, Especificación de Requisitos,
el Plan del Proyecto, el Hardware y el Software: se crearán en
el primer incremento y podrán ser actualizados
 El resto, serán creados a partir del segundo incremento y
serán actualizados en todos los restantes.
Grupo 7
GCS ~ Identificación de la Configuración
 Identificación de los ECS:
<nombreProy>_<línea_base>_<tipo_ECS[:nombre_funcion]>_<versión>
 Identificación de los Componentes de Software:
//Nombre del proyecto
//Nombre del ECS
//Autor
//Fecha de creación
//Historial de modificaciones
//Versión | Modificado por | Fecha | Solicitud número | Motivo del cambio
 Identificación de líneas base:

Una al final de cada incremento, luego de integrar el módulo al sistema.

Sin líneas base dentro de los incrementos.
Grupo 7
GCS ~ Identificación de la Configuración
Descripción del modelo y establecimiento de líneas base:
Líneas Base
Incremento
0
Incremento
1
ECSs:
- Esp. del Sistema
-ERS
-Plan del Proyecto
Incremento
N
ECSs:
- ERS
- Plan del Proyecto
- Documento de Diseño
- Documento de Arquitectura
- Etc.
Grupo 7
GCS ~ Identificación de la Configuración
 Se creará una biblioteca de trabajo por proyecto, identificada por un
conjunto de caracteres formado por el nombre del proyecto y el año de inicio
 Al establecerse la línea base, los ECS serán trasladados a una biblioteca
maestra.
 La biblioteca maestra se identificará con: nombre del proyecto, año de inicio
y número de release.
 Será mantenida por el Bibliotecario.
 Al finalizar el proyecto, el bibliotecario debe entregar los ECS al equipo de
GCS.
 Los ECS se incluyen en un repositorio común a todos los proyectos.
Grupo 7
GCS ~ Control de Cambios de la Configuración
Los cambios se realizan informalmente sólo hasta que los ECS forman parte
de una línea base.
A partir de ese momento, se debe seguir un procedimiento formal.
 Interviene el Comité de Control de Cambios, formado por:
Líder de Proyecto
Representantes de la gerencia de la empresa
Una persona que tome nota y complete los formularios.
Opcionalmente, el cliente para justificar el pedido de cambio.
Grupo 7
GCS ~ Control de Cambios de la Configuración
Procedimiento para solicitar un cambio
Un usuario o desarrollador solicita un cambio.
 Un miembro del equipo de desarrollo lo registra en una solicitud de cambio.
 Se archiva hasta la siguiente reunión del Comité de Control de Cambios.
 El Comité de Control de Cambios se reúne y evalúa la solicitud.
 Si el cambio es rechazado, la solicitud se archiva se informa al solicitante.
 Si es aceptado, se asigna prioridad y se envía al equipo de desarrollo.
 Se asignan responsables al cambio.
 Se realiza y se prueba el cambio.
 La nueva versión se integra al siguiente incremento.
Grupo 7
GCS ~ Control de Cambios de la Configuración
Flujo de los ECS:
ECS
Biblioteca de
Trabajo
Terminad
Biblioteca de
Maestra
os
Línea
Base
Terminad
as
NO
¿Línea
Base
Aprobada
?
Biblioteca de
Auditoría
SI
Repositorio
Común
Grupo 7
GCS ~ Generación de informes de estado
Informes
 Semanalmente:

Informe de Solicitudes de Cambio, que contendrá todas las solicitudes
recibidas durante la semana.

Informe de Cambios realizados, que contendrá un listado de todas las
modificaciones hechas durante esa semana.

Informe de Cambios a realizar, que mostrará los cambios que fueron
aprobados y pendientes de implementación.
 Bajo demanda:

Informes para ver diferencias entre versiones, historial de cambios, listas
de cambios aprobados y rechazados, entre otros.
Grupo 7
GCS ~ Generación de informes de estado
Informes
 Al finalizar cada incremento y establecer la línea base:

Informe de Contenido de la Línea Base, que contendrá los nombres de
cada ECS incluido en esa línea base.

Informe de Evolución de los ECS: que mostrará las diferencias entre la
línea base actual y la inmediatamente anterior.
 Al finalizar el proyecto

Informe de contenido de la Biblioteca Maestra.

Informe de Cambios Realizados, que contendrá el listado de todos los
cambios que se aprobaron y llevaron a cabo en algún momento del proceso.
Grupo 7
GCS ~ Generación de informes de estado
Registros
 ECS.
 Líneas Base.
 Cambios realizados, pendientes y rechazados.
 Información acerca de los cambios, como ser, quién lo solicitó, una breve
descripción , número de solicitud, motivo, estado, historia, etcétera.
 Informes de incidencia
 Modificaciones del código
 Modificaciones de la documentación
Grupo 7
GCS ~ Auditoría de la Configuración
 Se realizarán auditorías sobre las líneas base para validar la completitud del
producto y la consistencia entre sus componentes.
 Se realizarán revisiones técnicas formales mientras se está desarrollando el
incremento.
 Las revisiones y auditorías estarán a cargo de un grupo ajeno al equipo de
desarrollo, a fin de garantizar la objetividad.
 La manera de auditar las líneas base dependerá de qué incremento fue el
que la produjo:

El primero.

Los restantes.
Grupo 7
GCS ~ Auditoría de la Configuración
Auditoría de la línea base producida por el Primer Incremento
Se validará el Plan de Proyecto, asegurándose de que la planificación de
actividades sea coherente con los tiempos requeridos por el cliente, y que los
recursos no se superpongan.
Se auditará la Especificación de Requisitos, para verificar que cumple con el
formato impuesto por el estándar IEEE-830.
Si en la Auditoría se encuentran errores, se llenará un formulario indicando
cuáles son y en qué requisitos fueron encontrados. Luego se enviará la
Especificación de Requisitos junto con dichos formularios, para que el equipo
de desarrollo pueda corregirla.
En caso de que no se encuentren errores, la Especificación de Requisitos se
aprueba y se almacena en la biblioteca.
Grupo 7
GCS ~ Auditoría de la Configuración
Auditoría de la línea base producida por los demás incrementos
Los documentos a auditar serán:

El documento de Diseño
 Plan de pruebas

El documento de Arquitectura
 Casos de prueba

Diagramas de Entidad Relación
 Informes de

Código fuente
errores
 Manuales.
Será necesario contar con diversos documentos, como ser informes de
incidencias, resultados de las pruebas, informe de estado de la línea base
anterior y actual, etcétera.
Grupo 7
GCS ~ Auditoría de la Configuración
Auditoría de la línea base producida por los demás incrementos
El procedimiento a seguir es:

Se compara el informe de estado de la línea base actual con el
contenido de la biblioteca de auditoría, para comprobar que todos los ECS
que debe tener una línea base fueron construidos.

Se verifica que todos los requisitos que debían realizarse en el
incremento fueron desarrollados. Para ello se utilizará una matriz de
trazabilidad de los requisitos al código fuente.

Se verifica, utilizando el informe que arroja el compilador, que los
componentes usados para construir el ejecutable son los correctos.

Se comprueba que cada caso de prueba puede rastrearse hasta al
menos un requisito.
Grupo 7
GCS ~ Auditoría de la Configuración
Auditoría de la línea base producida por los demás incrementos

Se comprueban los resultados de las pruebas. Para eso se utilizan los
resultados de los casos de prueba y los casos de prueba. Además, se
ejecutan tres casos elegidos al azar para una segunda verificación.

Si hay informes de errores en las pruebas, se verifica que los módulos
que figuran en los informes hayan sido corregidos.

Se comprueba la trazabilidad desde los manuales hasta los módulos.
Cada módulo debe ser mencionado al menos en una sección del manual.

Todos estos pasos se registran en un formulario de auditoría de la línea
base. Si se aprueba, se copia a la biblioteca maestra, si es rechazado por
algún problema, se genera un pedido de cambio y vuelve a las manos del
equipo de desarrollo, a fin de corregir los defectos hallados.
Conclusiones
Luego de desarrollar las características del Modelo de
Proceso Incremental y de la Gestión de la Configuración del
Software y al describir el procedimiento para aplicarlos
conjuntamente, llegamos a la conclusión de que ambas
metodologías no son en absoluto incompatibles.
Es totalmente posible usarlas dentro de un mismo proyecto
para gozar las ventajas que ambas ofrecen a los
desarrolladores de software.
Grupo 7
¿Preguntas?
Grupo 7