El documento habla sobre la gestión de la configuración de software. Explica los roles y responsabilidades en el proceso como el gestor de configuración y el coordinador de configuración. También describe el proceso de identificación de elementos de configuración, solicitud de cambios, análisis de impacto, aprobación o rechazo de cambios e implementación de cambios aprobados.

1. TRAZABILIDAD Y CONFIGURACION DE
SOFTWARE

2. TEMARIO SEMANA 3.
5. Gestión de la configuración del software
5.1. Propósito y alcance
5.2. Objetivos y terminología
5.3. Roles y responsabilidades
6. Identificación de la configuración y control de cambios
en el software
6.1. Elementos y nomenclatura
6.2. Solicitud de cambios y análisis de impacto
6.3. Aprobación o desaprobación de cambios
6.4. Implementación de cambios

3. Gestión de la Configuración de
Software
 Es un conjunto de actividades desarrolladas para
gestionar cambios a lo largo del ciclo de vida del
software de computadora.

4. Gestión de la Configuración de
Software
 Es un conjunto de actividades diseñadas para
identificar y definir los elementos en el sistema que
probablemente cambien, controlando el cambio de
estos elementos a lo largo de su ciclo de vida,
estableciendo relaciones entre ellos, definiendo
mecanismos para gestionar distintas versiones de estos
elementos, y auditando e informando de los cambios
realizados.

6. 5.1 Propósito y Alcance
 Tener control sobre cada una de las iteraciones y fases,
de los productos generados en estas y de los cambios
surgidos, evaluados y aprobados.
 Se deben incluir en control de configuración la mayor
cantidad de productos posibles, tomando en cuenta
siempre las restricciones dadas por la duración del
proyecto y por la capacidad organizativa del equipo.

7. 5.1 Propósito y Alcance
 Si es necesario, se realizarán las modificaciones que el
cliente ha pedido y se actuará con las estrategias
pertinentes.

8. 5.2 Objetivos y Terminología
 Determinar cuál es la versión actual de cada uno de los
componentes.
 Determinar el proceso de cambios.
 Determinar la política de releases.

9. 5.3 Roles y Responsabilidades
 Gestor de configuración
 Gestionar la planificación, identificación, control,
seguimiento y auditoría de todos los elementos de
configuración en la base de datos de configuración.
 Desarrollar el plan de gestión de configuración.
 Promover el uso efectivo de la base de datos de
configuración dentro de la organización.

10. 5.3 Roles y Responsabilidades
 Gestor de configuración
 Monitorear y reportar los cambios no autorizados sobre
los elementos de configuración.
 Asegurar la consistencia e integridad de los datos de la
base de datos de configuración a través de la ejecución
de procedimientos de verificación y auditoría.

11. 5.3 Roles y Responsabilidades
 Gestor de configuración
 Liderar las actividades de evaluación del proceso: revisar
tipos de elementos de configuración, relaciones,
atributos y valores asociados, estructura de la base de
datos, derechos de acceso.
 Aprobar cambios estructurales en la base de datos de
configuración.

12. 5.3 Roles y Responsabilidades
 Coordinador de configuración
 Asegurar que todos los elementos de configuración
están registrados de forma adecuada en la base de datos
de configuración.

13. 5.3 Roles y Responsabilidades
 Coordinador de configuración
 Asegurar la consistencia e integridad de los datos de la
base de datos de configuración y la estructura del
sistema a través de la ejecución de procedimientos de
verificación y auditoría.

14. 5.3 Roles y Responsabilidades
 Coordinador de configuración
 Reportar cualquier discrepancia o no conformidad en los
elementos de configuración al gestor de configuración.
 Participar en la mejora continua del proceso de gestión
de configuración.

15. 5.3 Roles y Responsabilidades
 Responsable de elementos de configuración
 Asegurar que los elementos de configuración de los que
es responsable están registrados en la base de datos de
configuración con el estado y datos de configuración
apropiados.

16. 5.3 Roles y Responsabilidades
 Responsable de elementos de
configuración
 Verificar que los cambios sobre los
elementos de configuración siguen el
proceso de cambios definido.
 Asegurar la idoneidad e integridad de
los elementos de configuración de los
que es responsable.

17. 5.3 Roles y Responsabilidades
 Responsable de elementos de configuración
 Trabajar conjuntamente con el gestor de configuración
para identificar las causas de cualquier discrepancia
identificada en las auditorías e implementar las acciones
correctivas.

18. 5.3 Roles y Responsabilidades
 Gestor de cambio
 Evaluar el impacto y riesgo de los
cambios.
 Asegurar que los responsables de
los elementos de configuración
actualizan los históricos de estos
elementos con los cambios
implementados.

19. 6. Identificación de la configuración
y control de cambios en el
software
 La actividad de identificación de la configuración
identifica los elementos que van a ser controlados,
establece esquemas para la identificación de los
elementos y sus versiones, y establece las herramientas
y técnicas a usar para adquirir y gestionar los
elementos controlados.

21. 6.1 Elementos y Nomenclatura
 Los elementos que componen toda la información
producida como parte del proceso se denominan
colectivamente "configuración del software". Dado que
la configuración software es la única representación
tangible de un programa o sistema software, debe ser
controlada para conservar su exactitud, mantener la
información actualizada, y asegurar una información
clara y concisa conforme avanzamos paso tras paso en
el proceso de Ingeniería del Software.

23. 6.1 Elementos y Nomenclatura
 Elementos creados durante el desarrollo.
– Programas (código fuente y ejecutables) y recursos
(gráficos, etc).
– Documentos (técnicos, administrativos y de usuario).
– Estructuras de datos (base de datos, archivos, etc).

24. 6.1 Elementos y Nomenclatura

25. 6.1 Elementos y Nomenclatura
 Los ECS se organizan como objetos de configuración
que deben ser catalogados por la base de datos del
proyecto con un nombre único.
 Un ECS tiene un nombre y atributos, y está conectado
a otros objetos mediante relaciones.

26. 6.2 Solicitud de cambios y análisis
de impacto
 El proceso de solicitud de cambios provee
procedimientos formales para: registrar solicitudes de
cambio; analizar la información del por qué es
requerido el cambio, y el impacto que tendrá; y
autorizar, rechazar o modificar la solicitud de cambio.

27. 6.2 Solicitud de cambios y análisis
de impacto
 Las solicitudes de cambio pueden provenir de
cualquier usuario o interesado, en cualquier punto del
ciclo del software, e incluir una solución propuesta,
prioridad e impacto, el cual debe ser analizado,
aprobado y rastreado formalmente. Una solicitud de
cambio puede originarse, por ejemplo, a partir de un
defecto en el producto de software, de una petición de
mejora o de un cambio a un requerimiento.

28. 6.2 Solicitud de cambios y análisis
de impacto
 El proceso de solicitud de cambios nos permite dar
seguimiento a las solicitudes de cambio y efectuar
mediciones acerca de la actividad del cambio. Una vez
que una solicitud es recibida, una evaluación técnica
(análisis de impacto) se lleva a cabo para determinar
qué modificaciones se requerirían y si la solicitud de
cambio debe ser aprobada.

29. 6.3. Aprobación o desaprobación
de cambios
 Requiere principalmente de herramientas de control
de cambios que deben haber demostrado su eficacia

30. 6.3. Aprobación o desaprobación
de cambios
 Los gerentes de proyecto establecen reuniones con el
equipo de trabajo

31. 6.3. Aprobación o desaprobación
de cambios
 Tener en cuenta el juicio de expertos. Una vez
aprobado un cambio se registrará en el plan de
dirección del proyecto y aparecerá, si aplica, en las
líneas base del Proyecto.

32. 6.4 Implementación de cambios
 Para que un cambio sea aprobado, se debe cumplir una
serie de pasos, los que funcionan como un marco
regulatorio para dicha gestión. Ellos se presentan, de la
siguiente manera:
 Elaboración de una solicitud de cambio: se
debe definir detalladamente tanto el tipo de cambio a
solicitar, como así también sus características generales y
específicas. Asimismo, este documento debe ser dirigido al
director, con la finalidad de que continúe con el resto de las
fases del procedimiento.

33. 6.4 Implementación de cambios
 Análisis técnico: es necesario que se efectúe un estudio
teórico sobre todos los aspectos de carácter técnico
implicados en el cambio propuesto. En el caso de que
sea considerado inapropiado y perjudicial para el
cumplimiento de la totalidad del proyecto, la solicitud será
rechazada, en esta instancia.
 Proceso de cuantificación del cambio solicitado: se
requiere que los efectos asociados puedan ser mensurables
y cuantificados, para poder tener conocimiento sobre
sus consecuencias sobre la totalidad del proyecto.
Este análisis debe ser presentado al director y al equipo de
trabajo responsable de la ejecución.

34. 6.4 Implementación de cambios
 Aprobación: debe contar con el consentimiento del
comité directivo y de los clientes que hayan solicitado
la gestión del proyecto.
 Modificación de la planificación: con posterioridad
a la correspondiente aprobación, se deben modificar
los planes de planificación, los cuales deben estar
en concordancia con el análisis cuantificado,
mencionada previamente.

35. 6.4 Implementación de cambios
 Brindar la información de la resolución a las
personas implicadas en la solicitud: en el caso de
que haya sido negativa, se deben explicitar los motivos
de dicho rechazo. Por el contrario, si fue aprobada, se
debe continuar con su aplicación procesal.
Asimismo, todos los integrantes del equipo de trabajo
deben ser informados correctamente, para que puedan
proceder según los planes reformulados y
establecidos, luego del procedimiento citado.

36. 6.4 Implementación de cambios
 Seguimiento del resultado del cambio aprobado: se
debe efectuar un control adecuado de todos
los cambios que hayan sido aprobados y generados en el
proyecto en cuestión. En efecto, es necesario que se
compruebe que estos cambios se hayan aplicado Para ello,
es importante que exista un proceso comunicacional
óptimo sobre el tema, con el fin de evitar malos entendidos
y que ocurran eventos perjudiciales, los cuales pueden ser
potenciales fuentes generadoras de cualquier tipo de
inconveniente asociado.