El documento describe los procedimientos de control de cambios para proyectos de desarrollo de software. El control de cambios combina procedimientos humanos y herramientas para evaluar, aprobar y realizar cambios de manera eficiente. Todo cambio debe ser aprobado por la Autoridad de Control de Cambios y generar una Orden de Cambio de Ingeniería antes de realizarse. Luego del cambio se realizan pruebas y auditorías para verificar que se haya implementado correctamente.

1. CONTROL DE CAMBIOS
02/05/2016

2. CONTROL DE CAMBIOS
• En un gran proyecto de desarrollo de
software, el cambio incontrolado lleva
rápidamente al caos.
• El control de cambios combina los
procedimientos humanos y las herramientas
automáticas para proporcionar un mecanismo
eficiente para el control de cambios.

3. CONTROL DE CAMBIOS
• Los resultados de la evaluación se presentan
como un informe de cambios a la ACC
(Autoridad de Control de Cambios).
• Para cada cambio aprobado se genera una OCI
(Orden de Cambio de Ingeniería).
• La OCI describe el cambio a realizar, las
restricciones que se deben respetar y los
criterios de revisión y de auditoria.

4. CONTROL DE CAMBIOS
• El objeto a cambiar es "dado de baja" de la
base de datos del proyecto.
• Se realiza el cambio y se aplican las adecuadas
actividades de SQA (Actividades de
aseguramiento de la calidad).
• Luego, el objeto es "dado de alta" en la base
de datos y se usan los mecanismos de control
de versiones apropiadas para crear la
siguiente versión del software.

5. CONTROL DE CAMBIOS
Los procedimientos de "alta" y "baja"
implementan dos elementos importantes del
control de cambios: Control de Acceso y Control
de Sincronización.

6. CONTROL DE CAMBIOS
• El Control de Acceso gobierna los derechos de
los ingenieros de software a acceder y
modificar objetos de configuración concretos.
• El Control de Sincronización asegura que los
cambios en paralelo, realizados por personas
diferentes, no se sobrescriben mutuamente.

7. Control de Acceso y de
Sincronización

8. CONTROL DE CAMBIOS
• Antes de que un ECS (Elemento de Configuración
de Software) se convierta en una línea base, sólo
es necesario aplicar un control de cambios
informal.
• El que haya desarrollado el ECS en cuestión podrá
hacer cualquier cambio justificado por el
proyecto y por los requisitos técnicos.
• Una vez que el objeto ha pasado la revisión
técnica formal y ha sido aprobada, se crea la línea
base.

9. CONTROL DE CAMBIOS
Una vez que el ECS se convierte en una línea
base, aparece el control de cambios a nivel de
proyecto, para hacer un cambio, el encargado
del desarrollo debe recibir la aprobación del
gestor del proyecto (si el cambio es local), o de
la ACC si el cambio impacta en otros ECS.

10. CONTROL DE CAMBIOS
• En algunos casos, no se generan formalmente
las peticiones de cambio, los informes de
cambio y las OCI. Sin embargo, hay que hacer
una evaluación de cada cambio así como un
seguimiento y revisión de los mismos.
• Cuando se distribuye el producto de software
a los clientes, se instituye el control de
cambios formal.

11. CONTROL DE CAMBIOS
• El papel de la ACC (Autoridad de Control de
Cambios) es el de tener una visión general, se
encarga de evaluar el impacto del cambio
fuera del ECS en cuestión, es decir:
– ¿Cómo impactará el cambio en el hardware?
– ¿Cómo impactará en el rendimiento?
– ¿Cómo alterará el cambio la percepción del cliente
sobre el producto?

12. AUDITORIA DE LA CONFIGURACIÓN
¿Cómo podemos asegurar que el cambio
se ha implementado correctamente?
1) Revisiones técnicas formales.
2) Auditorias de configuración del software.

13. AUDITORIA DE LA CONFIGURACIÓN
• Los revisores evalúan el ECS para determinar
la consistencia con otros ECS, las omisiones o
los posibles efectos secundarios.
• Una auditoria de configuración del software
complementa la revisión técnica formal al
comprobar características que generalmente
no tiene en cuenta la revisión.

14. AUDITORIA DE LA CONFIGURACIÓN
La auditoria se plantea y responde con las
siguientes preguntas:
• ¿Se ha hecho el cambio especificado en la OCI?
• ¿Se han incorporado modificaciones adicionales?
• ¿Se ha llevado a cabo una revisión técnica formal
para evaluar la corrección técnica?
• ¿Se han seguido adecuadamente los estándares
de ingeniería de software?

15. AUDITORIA DE LA CONFIGURACIÓN
• ¿Se han "recalcado" los cambios en el ECS?
• ¿Se han especificado la fecha del cambio y el
autor?
• ¿Reflejan los cambios los atributos del objeto
de configuración?
• ¿Se han seguido procedimientos del GCS para
señalar el cambio, registrarlo y divulgarlo?
• ¿Se han actualizado adecuadamente todos los
ECS relacionados?

16. INFORMES DE ESTADO
La generación de informes de estado de la
configuración es una tarea de GCS que responde
a las siguientes preguntas:
1) ¿Qué pasó?
2) ¿Quién lo hizo?
3) ¿Cuándo pasó?
4) ¿Que más se vio afectado?

17. INFORMES DE ESTADO
• La generación de informes de estado de la
configuración desempeña un papel vital en el
éxito del proyecto de desarrollo de software.
• Cuando aparece involucrada mucha gente es muy
fácil que no exista una buena comunicación,
pueden darse errores entre las personas
desarrolladoras del software.
• El IEC (Informes de Estado de la Configuración)
ayuda a eliminar esos problemas, mejorando la
comunicación entre todas las personas
involucradas.

18. PROCESO DE CONTROL DE CAMBIOS
Se reconoce la
necesidad del
cambio
El usuario suscribe
la petición del
cambio
El desarrollador la
evalúa
Se genera un
informe de cambios
La autoridad de
control de cambios
decide
Si es aceptada la
petición queda
pendiente de
actuación
Se genera la orden
de cambio de
ingeniería (OCI)
Asignación
personalizada de los
objetos de
configuración
Dar de baja objetos
de configuración
pertinentes
Realización del
cambio
Revisión del cambio
Los elementos de
una línea base para
la prueba
Realización de
actividades de
garantía, calidad y
prueba.
Promoción de los
cambios para la
próxima versión.
Reconstrucción de la
versión adecuada de
software.
Revisión de todos
los cambios
Distribución de la
nueva versión

19. BIBLIOGRAFÍA
• Specifications in Software Engineering
I. Horebeek. y J. Lewi.
Springer-Verlag, 1989
• Ingeniería del Software: un enfoque práctico
R.S. Pressman. McGraw Hill. Madrid, 1993. 3ª
Edición.

20. Docente:
Mónica María Espejo Pérez
Ingeniera De Sistemas
Especialista en Administración de la
Informática Educativa