Gestion de la configuracion de Software (control de Cambios en la Configuracion).

- Control de Cambios en la Configuracion:

Proporcionar un mecanismo regurioso para controlar los cambios, partiendo de la
base de que los cambios se van a producir. normal combina procedimientos humanos y
el uso de herramientas autom�ticas.
* Correcci�n de un defecto: Los clientes tienden a clasficar todo los cambios de
esta categiroas
* Mejora del sistema: Asginado por el equipo de trabajo.

Por lo general siempre hay 3 etapas:

* Control de cambios informal: Se da cuando no hay una linea base. no necesita
control.

* Control de cambios a nivel de proyecto o semi-formal: Cuando ya tenemos una

linea base, paso la revision tecnica.
Previo aprobacion de:
Director del proyecto si es cambio local
El comite de control de cambios, si el cambio tiene lagun impacto sobre otros ECS.

* Control de cambios formal: Sele adoptar una vez que se empieza a comerciales el
productos, cuando se tranfiere los ECS a la biblioteca Maestra.

Todo cambio deber� ser aprobado por el Comit� de Control de Cambios. Determina si
se hace el cambio. previa evaluaci�n.

El commit� de Control de Cambios es responsable del Control de Cambios, tambien van

a tener alguna responsabilidad:
Todo los miembros de un proyecto
* Puede solicitar cambios
* ser�n los encargados de realizar los cambios
* deben informar acerca del estado de los cambios que est�n realizando.

El Jefe de Proyecto:
* Debe asegurar de que los procedimientos de Contro lde cambios se siguen
correctamente.
* Pueden participar en la evaluaci�n de los cambios, sobre todo en la
determinaci�n de impactos sobre otros EC.
* Informar acerca del estado de Cambios.

El bibliotecario:
* Debe controlar la realizaci�n de los cambios sobre las �ltimas versiones.
* TRansferira los elementos a modoficar desde la Biblioteca deSoporte del Proyecto
a la biblioteca de Trabajo.

El proceso de Control de Cambios.

* No hay ningun estandar para el ocntrol informal o interno de los cambios, aunque
si hay algunas recomendaciones IEEE STD 1042 Guide to Software COnfiguration
Management.

* En cuanto al control de cambios formal, se puede estructurar de muchas formas.

Veamos a ver cu�les son las etapas t�picas de un proceso formal, es decir, el
proceso que habr�a que seguir para hacer un cambio sobre la l�nea bas.

1. Iniciacnion delCambio : Se presenta una solicitud de cambio, que puede venir

provocado por un problema que se ha detectado o por un cmabio en los requisitos.
2. Clasificacion y registro de solicutd de cambio.
3. Aprobacion o rechazo inicial de la solitud de cambio. De ello suele ser
responsable el Comite de control de CAmbios.
4. Evaluacion de la solicutd de cambio, si ha aprobado, para calcular el esfuerzo
tecnico, los posibles efectos secundarios, el impacto global sobre otras funciones
del sistema y el costo estimado del cambio.
5. Se presenta el informa de cambios al Comite de Control de Cambios
6. Se realiza el cmbio, entrando en eun proceso de seguimiento y control
7. Se certifica, mediante uina revision que se ha efectuado correctametne el cambio
y con ellos se ha corregido el problema detectado.
8. Se notifica el resultado al originador del cambio

Un Proceso de Control de Cambios no nunca puede ser lineal, siempre habr�

condiciones.

* En un proceso semi-formal, puede suprimirse la necesidad generar la solicitud de

cambio, el informe de cambio y la orden de cambio, pero si debe realizarse la
evaluacion del cambio y su seguimiento.

La Biblioteca de Proyecto Deben implementar dos elementos:

*Control de Acceso: Se refiere a los derechos que tienen los diferentes miembros
del equipo de desarrollo para acceder y modificar ECS concretos. Ocurre cuando
estamos en la etapa de desarrollo.
* Control de Sincronizacion: Ayuda a asegurar que los cambios en paralelo,
realizados por equipos o personas diferentes, no se sobreescriben.

El almac�n de una herramienta de control de versiones se puede considerar como la

biblioteca de Sorpote o de Proyecto. Estas herramientas ofrecen tambi�n de forma
autom�tica.

Mecanismos para Solicitar Cambios

* Es necesario definir el mecanismo para solicitar cambios sobre los elelemtnos de
Configuracion.
Definir el formulario que se debe utilizar para solicitur cambios. Este formulario
de Solicitud de Cambio debe contener informacion Suficiente para DEterminar:

* Debe ser Simple, y aceptado por las personas autorizadas.

* A los formulario que se usan
incidente: Pasa muy eventual.
Problema:Es una incidente de forma habitual, que se convierte en un problema.

* La notificaicon de Cambio puede dar respuesta a varios Informes de Incidencias,

cuando todos ellos corresponden al mismo problema.
* Criterios para tomar la decision de aprobar o rechazar las solicitudes de
cambio:
- Valor del cambio para el Proyecto / Organizacion.
- Retorno de la inversion
- Tama�o
- Complejidad - Impacto sobre el rendimiento del producto. - Recursos
Disponibles para efectuar el cambio - Tiempo estimado para completar el
cambio - Relaci�n con las pol�ticas de la emrpesa - Existencia de alternativas.

Seguimiento de los CAmbios. Gesiton de Probmelas.

Conlleva tareas como :
- Adminsitra y registro de notificaciones.
- Asignacion del problema a una persona responsable.
- Asociacion de informacion al problema y mantenimiento de la misma en una base de
datos.
 - MOnitorizacion del estado del problema.
- Registro de actividades efectuadas para resolver un problema
- Generacion de informes acerca de los problemas

Algunos de los datos que puede resultar interesante almacenar acerca de los
problemas:
- Descripcion
- Severidad
- Urgencia o prioridad
- Causa del problema
- Solucion al problema
- Modulo afectados
- persona que no notifico.