30-8-2022 Tema 1.1.

1 Control de
cambios
3CM61 Modelos de Prueba de software

Victor Manuel Carreño G.

UPIICSA
 Tema 1.1.2 Control de cambios

OBJETIVO: Comprender mediante este reporte de tema que es el control de cambios, las
políticas de cambios y los estándares que se utilizan para agilizar el desarrollo de software

MISION: Establecer un grupo de conceptos por medio del reporte que nos permitirá realizar un
análisis de los diferentes términos recopilados

VISIÓN: Se espera encontrar información precisa y objetiva para que la compresión del tema
sea adecuada y puede aplicarse en diferentes proyectos de software

ALCANCE: Lograr entender la importación del control de cambios y como nos permite mejorar
la toma de decisiones empresariales o en el ámbito de desarrollo de software para poder
realizar futuras correcciones
 Tema 1.1.2 Control de cambios

Control de Cambios:

El control de cambios es un mecanismo para la evaluación y aprobación de los cambios

hechos a elementos de la configuración software durante el ciclo de vida.

Forma parte de un plan de gestión de cambios que define los roles para gestionar el
cambio dentro de un equipo o empresa. Existen 3 distintos tipos de control:
1) Control individual: antes de aprobarse un nuevo elemento.
2) Control de Gestión: conduce a la aprobación de un nuevo elemento.
3) Control formal: se realiza durante el mantenimiento.

A continuación, se analizara de forma más precisa:

1. Control individual
Cuando un elemento de la configuración está bajo
control individual, el técnico responsable cambia la
documentación como se requiere. Aunque se
mantiene un registro informal de revisiones, tales
registros no se ponen generalmente en el
documento. El control individual se aplica durante
las etapas más importantes del desarrollo del
documento y se caracteriza por los cambios
frecuentes.
 Tema 1.1.2 Control de cambios

2. Control de gestión
Implica un procedimiento de revisión y
aprobación para cada cambio propuesto en
la configuración. Como en el control
individual, el control a nivel de proyecto
ocurre durante el proceso de desarrollo,
pero es usado después de que haya sido
aprobado un elemento de la configuración
software. Este nivel de control de cambios
se caracteriza por tener menos cambios
que el control individual. Cada cambio es
registrado formalmente y es visible para la
gestión.

3. Control de cambios formal

Ocurre durante la fase de mantenimiento del
ciclo de vida software (el producto ya está
implantado). El impacto de cada tarea de
mantenimiento se evalúa por un Comité de
Control de Cambios (CCC), el cual aprueba las
modificaciones de la configuración software.

El proceso de Control

El control de cambios se aplica en donde un

elemento de la configuración software va a
cambiar. Una petición de cambio pide
modificaciones para corregir un error o
deficiencia, adaptar un nuevo entorno, o
acrecentar el software operativo y es
sometido al análisis de la organización
software.

Después de que ambos problemas, técnicos y de gestión, sean considerados, se presenta

un informe de cambios para ser evaluado por el Comité de Control de Cambios (CCC). La
petición es aprobada o rechazada y notificada al solicitante del cambio. Para cada cambio
aprobado, se genera una Orden de Cambio (OC), que describe el cambio realizado, las
restricciones que se deben respetar y los criterios de revisión y auditorías.
 Tema 1.1.2 Control de cambios

Identificación Control de cambios

Para una correcta identificación de lo controles de cambios de los requerimientos de las

organizaciones de desarrollo de software, se identifican las siguientes actividades: 

 Análisis de la Solicitud:

La solicitud es recibida por parte del cliente interno o externo, esta debe ser
recibida por parte del líder de implementación para ser analizada. Uno de los
puntos importantes para analizar son el Alcance y el Tiempo, esto con el fin de
identificar si la solicitud es viable realizarla sobre el mismo requerimiento o si por el
contrario es mejor manejarla como un requerimiento nuevo. Con respecto al
análisis con relación al alcance es recomendable buscar colaboración con las
áreas involucradas en la solicitud, para identificar de mejor manera el impacto y los
elementos que se ven afectados con la solicitud.

 Valorar el cambio

Otro punto importante es valorar la factibilidad de la solicitud realizada ya sea por

un cliente interno o uno externo. Para ello se deberá ir recorriendo todo el árbol de
requisitos viendo cómo les afecta el cambio, y aquí es donde entra la trazabilidad
de los requisitos.

 Analizar Modificación

El líder de implementación debe realizar el análisis de la solicitud para saber que

tanto impacta la modificación e identificar puntualmente las modificaciones
solicitadas que afectan el requerimiento completo y así identificar si el cambio
afecta más de un requerimiento.

 Documentar Cambio

Para tener un mejor control sobre los cambios solicitados es recomendable

realizar una documentación clara para evitar ambigüedades en las modificaciones
que se van a realizar a los requerimientos. Este punto apoya también a tener un
control de las modificaciones que se realizan sobre un documento de
requerimiento esto con el fin de mantener informado al grupo de trabajo y al cliente
que actualizaciones se han realizado sobre los documentos, cual es la razón del
cambio y quien lo aprobó. 

Aprobación Control de Cambios

A continuación, se realizará los siguientes pasos para solicitar la aprobación de cambios.

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.
 Tema 1.1.2 Control de cambios

 Aprobar Cambios

Una vez se ha analizado el impacto del cambio, se debe tomar una decisión. Si se
acepta el cambio, tras negociarlo con el cliente, se continuará con la actividad de
implementar el cambio. En caso contrario, se deberá negociar con el cliente el
siguiente paso a realizar.

 Planear Cambio

Después de tener una aprobación formal del cambio aceptado se planea el tiempo
y los recursos necesarios para llevar a cabo el cambio aprobado.

 Realizar Cambio

Una vez se planea el cambio aprobado se debe realizar las modificaciones

necesarias a todos los productos que resulten afectados por dicho cambio.

 Revisar Cambio

Una vez se realice el cambio es recomendable hacer una verificación por parte del
líder para identificar que el requerimiento incluye todos los cambios solicitados y
que fueron aprobados.

 Actualizar Línea Base

Es recomendable utilizar el nuevo requerimiento como línea base, esto con el fin
de trabajar siempre sobre la última versión del requerimiento.

 Informar

Una vez se realice la modificación de la solicitud se debe informar a los

interesados que el cambio ya está realizado para que sea verificado por el cliente.

Entregable Control de Cambios

Como se especificó en los puntos anteriores es importante utilizar el documento que

apoye a la identificación de la solicitud realizada por los clientes internos o externos. Esta
documentación no debe ser ambigua y debe ser validada por las dos partes, el cliente y
las empresas de desarrollo de software.
 Tema 1.1.2 Control de cambios

Seguimiento de Control de Cambios

Una vez aprobado un cambio debido a un

problema se debe realizar un seguimiento de
este. A este proceso se le llama Gestión de
Problemas. La Gestión de Problemas se
considera una actividad complementaria a la
de Control de Cambios, que consiste en
gestionar la evolución de los problemas
detectados sobre el software desarrollado,
tanto aquellos que se detectan en la fase de
pruebas como los informes de problemas
que llegan del usuario. Conlleva tareas
como:

 Admisión y registro de notificaciones de problemas (vía llamadas telefónicas,

correo electrónico, herramienta específica)
 Asignación del problema a una persona responsable.
 Asociación de información al problema y mantenimiento de esta en una Base de
Datos de Problemas.
 Monitorización del estado del problema.
 Registro de actividades efectuadas para resolver un problema.
 Generación de informes acerca de los problemas.
 Resolución de interrogaciones sobre la Base de Datos de Problemas.
 Análisis estadísticos acerca de los problemas, como por ejemplo el estudio de
correlaciones entre problemas y componentes.

Algunos de los datos que puede resultar interesante almacenar acerca de los problemas
son:

 Descripción,
 Severidad,
 Urgencia o prioridad
 Causa del problema (omisiones en el análisis, error en la documentación de
entrada, falta de experiencia,)
 Solución al problema
 Módulos afectados,
 Persona que lo notificó,
 Persona responsable,
 Fechas de notificación, resolución, etc.
 Fase/etapa en la que se originó el problema
 Fase/etapa en la que se detectó el problema
 Tema 1.1.2 Control de cambios

El comité de Control de Cambios ( CCC )

El CCC es el "órgano de gobierno" para todos los

problemas relacionados con la GCS. En general, la
CCC está compuesta por los miembros de las
organizaciones de usuarios/pedidores de cambios y de
desarrolladores.
Para pequeños proyectos, el CCC puede estar
formado por uno de los representantes de los
usuarios, requeridores de cambios y desarrolladores.
Para grandes proyectos, el CCC puede estar
organizado en una jerarquía que trate los problemas
del sistema, del hardware y del software por separado.

El CCC puede llegar a formar parte del desarrollo del proyecto software y hacer las
siguientes tareas:
1. Analizar el impacto de cambios "revolucionarios" en el sistema, usando para
asesorarse, las disciplinas técnicas que se requieran.
2. Categorizar y dar prioridad a los cambios conforme son pedidos y aprobados.
3. Intervenir en los conflictos entre disciplinas y organizaciones que surgen para ser
cambiados.
4. Garantizar que las propiedades de mantenimiento de registro y contabilización se
cumplan.

EJEMPLOS PROPUESTOS

EJEMPLO 1
Se esta desarrollando un proyecto en donde le principal objetivo es desarrollar un
software de gestión de consultas y registros de citas de un consultorio dental, en este
caso el cambio que se desea realizar es con respecto a la fecha de entrega debido a que
los encargados del diseño se están tardando mas de lo previsto así que procederemos a
enviar una solicitud explicando los motivos, el plazo que se solicita que en este caso seria
un mes más de la fecha estipulada. El que hará la solicitud será el área de diseño ya que
ellos son los que quieren más tiempo.
Una vez llenado el formulario esperaremos a que el encargado del proyecto evalué
nuestra propuesta de cambio, analizando cada punto que se presenta en el formulario ya
que evaluara los detalles que se encuentren en el mismo como podrían ser los recursos
necesarios o el impacto de la solicitud.
Posteriormente sigue el análisis de la solicitud de cambio que en este caso se necesitara
la aprobación del cliente ya que el es directamente uno de los involucrados en el proyecto.
 Tema 1.1.2 Control de cambios

Ya una vez aprobado el cambio solicitado procederemos a la implementación del cambio

solicitado tomando en cuenta la responsabilidad de lo que se estipulo en el formulario por
lo que los encargados de que esto se cumpla empezaran a trabajar para implementar los
cambios del proyecto.

Una vez que la solicitud haya sido documentada, compartida e implementada, la solicitud
está lista para cerrarse. Y nos será útil tener uno para almacenar la información en un
lugar al que todos los miembros del equipo puedan hacer referencia en el futuro. 

Durante la fase de cierre, toda la documentación, los registros de cambios y la

comunicación deben almacenarse en un espacio compartido al que se pueda acceder en
el futuro

EJEMPLO 2

Se está desarrollando un proyecto en donde su objetivo es el desarrollo de un software

que ayude a los alumnos a tener acceso a cursos que se imparten, sin embargo, se
necesita implementar un cambio con respecto al diseño de la plataforma ya que no sería
tan intuitiva para los alumnos y su manejo no será fácil. Por lo que el encargado del
proyecto al igual que los que se encargan del diseño enviaran un formulario a la
institución educativa explicando por qué se harían los cambios y cuál es su finalidad.

Una vez llenada la solicitud esperaremos a

que la institución evalué nuestra petición y
haga el análisis de esta para tener un criterio
de lo que se hará. Posterior a la aceptación del
cambio se procederá a la realización de este
para tener lo más pronto el resultado esperado
ante dicha propuesta.
 Tema 1.1.2 Control de cambios

Por último procederemos al cierre de la solicitud, por lo que en esta fase nos va a importar
y funcionar mucho guardar toda la documentación que se hizo para lograr nuestro
objetivo.

EJEMPLO 3

Se tiene un software en implementación, sin embargo, en la última fase el cliente no

quedo satisfecho con el avance ya que la funcionalidad de uno de sus apartados no
cuenta con las características que quiere o tenía planeadas, por lo que necesita un
cambio, así que enviara el formulario con dichas especificaciones al encargado del
proyecto aclarando el motivo de su solicitud.
El encargado del proyecto tendrá que evaluar la situación y los aspectos que influyen en
este cambio ya que como consecuencia podrían verse afectados en cuestión de tiempo.
Así que una vez evaluado y analizada la solicitud la acepta. Por lo que el equipo de
trabajo encargado de esas funciones tendrá que empezar con su implementación para
poder llegar a los resultados que se desea con los cambios.
 Tema 1.1.2 Control de cambios

REFERENCIAS BIBLIOGRÁFICAS

 R. Pressman, Ingeniería del Software, 3ª edición, McGraw-Hill, 1993

 European Space Agency, ESA Guide to Software Configuration Management,
ESA Software Engineering Standards Issue 2, Febrero 1991
 S.J. Ayer, F.S. Patrinostro, Software Configuration Management: Identification,
Accounting, Control, and Management, McGraw-Hill, 1992
 W. Babich, Software Configuration Management, Addison-Wesley, 1986
 H.R. Berlack, Software Configuration Management, John Wiley & Sons, 1992