# data[].attributes.body
También podemos evaluar el tipo de cambio por prioridad ya que algunos cambios deben ser requeridos:
▪ Cambio Estándar: son realizados aplicando un procedimiento de trabajo, previamente definido, deben ser autorizados por los integrantes de la reunión del comité de control de cambios,
por tratarse de un cambio que puede afectar la plataforma tecnológica. Ejemplo: Actualización de plataforma tecnológica,
cambio de versión de aplicaciones que tengan una implicación directa sobre la plataforma tecnológica.
▪ Cambio Normal: son aquellos realizados sin que su aplicación afecte el buen funcionamiento de la plataforma tecnológica, por ejemplo: cambio de contraseña de cuenta de Directorio
Activo o cambio de algún periférico. Este tipo de cambio finaliza con registro de tipo REQ en herramienta de gestión
de solicitudes, el cual es atendido por el Grupo de Soporte de TI y Mesa de Ayuda.
▪ Cambio Emergencia: cambios que al se aplicados solucionará un incidente o interrupción del servicio que se esté
presentando. Por lo tanto deben ser aplicados de inmediato, con la autorización del jefe de Oficina de Tecnologías y Sistemas de Información.

# data[].attributes.headline
Aportacion 1: Beneficios del control de cambios.

# data[].attributes.subject
Aportacion 1: Beneficios del control de cambios.

# data[].attributes.body
Hola compañeros, la información que plasman en este trabajo es muy interesante, pues tocan todos los puntos importantes del control de cambios, nuestra opinión es que es un trabajo muy completo.

Nos pareció muy interesante la parte donde mencionan los problemas que pueden presentarse por no utilizar el control de cambios, pero tocan muy poco el tema de los beneficios que tiene utilizar este control, nuestro aporte va dirigido a los diferentes beneficios que tiene el control de cambios.

A grandes rasgos el control de cambios puede ayudar a organizar y gestionar con eficiencia el trabajo de equipo, así como los entregables y los plazos del proyecto. Tiendo como resultado un flujo de información actualizada cuando sea necesario realizar algún cambio. A continuación mencionamos algunos beneficios de este control:

1.-Mayor productividad: Un control de cambios eliminará la confusión en torno a los entregables del proyecto y permitirá que el equipo se centre en la ejecución en lugar de recopilar información

2.-Comunicación efectiva: La correcta documentación de los cambios puede ayudar a disminuir los problemas de comunicación. Cuando las metas y los objetivos están claramente definidos, la comunicación del equipo puede prosperar.

3.-Mayor colaboración y trabajo en equipo: La comunicación efectiva además de ser un beneficio en sí misma, también ayuda a mejorar la colaboración. La comunicación clara sobre los cambios del proyecto potencia la colaboración y el trabajo en equipo.

# data[].attributes.headline
Aportación 2: Cuándo usar un proceso de control de cambios

# data[].attributes.subject
Aportación 2: Cuándo usar un proceso de control de cambios

# data[].attributes.body
Tenemos que tener en cuenta que nos encontraremos con muchos tipos de cambios, dependiendo de las nuevas iniciativas y las herramientas implementadas.
Algunos de los cambios más comunes incluyen solicitudes para extender los plazos, reorganizar la información o cambios en los entregables.
Otros casos en los que se utiliza el control de cambios son:

Desviación del alcance del proyecto: Considera usar este proceso cuando exista una desviación en el alcance del proyecto.

Inconsistencias del proyecto: Si identificas inconsistencias durante un proyecto, solicitar cambios puede evitar que tengas que corregir los entregables en el futuro.

Objetivos demasiado ambiciosos: En algunos casos, los objetivos y resultados claves propuestos pueden ser demasiado difíciles de lograr. En esos casos, es bueno detectar esos problemas antes de que se finalice el proyecto.

Nuevas herramientas: Si adoptas nuevos procesos o herramientas, los cambios pueden ser inevitables para poder resolver nuevos problemas que surjan durante los primeros proyectos.

# data[].attributes.body
Incluyeron una buena definición de diferentes tipos de cambios que pueden ocurrir en el desarrollo de un proyecto de software, y cómo la guía PMBOK los clasifica y define. Es importante tener en cuenta que los cambios en un proyecto son inevitables, y que la capacidad de manejarlos de manera efectiva es crucial para el éxito del proyecto. Por lo tanto, es importante que los equipos de desarrollo de software estén preparados para manejar diferentes tipos de cambios y contar con una metodología y herramientas adecuadas para gestionarlos. Además, es importante que el equipo de desarrollo de software trabaje en estrecha colaboración con los stakeholders, como los usuarios finales, para comprender sus necesidades y expectativas, y manejar los cambios de manera efectiva en el proyecto.

# data[].attributes.headline
Aportación 1: Herramientas para el control de Cambios

# data[].attributes.subject
Aportación 1: Herramientas para el control de Cambios

# data[].attributes.body
Hola compañeros, nos pareció muy importante la clasificación que hacen de las herramientas de conntrol de cambio así que ampliaremos ese subtema:

1. Control de versiones: es una herramienta que permite gestionar las distintas versiones del código fuente, así como controlar los cambios realizados en cada una de ellas. Ejemplos de herramientas de control de versiones son Git, SVN, Mercurial, entre otros.

2. Herramientas de seguimiento de errores: estas herramientas permiten registrar y hacer seguimiento a los errores o incidencias que surgen durante el desarrollo del software. Ejemplos de estas herramientas son Jira, Bugzilla, Redmine, entre otros.

3. Documentación: la documentación del proyecto es importante para registrar los cambios realizados, así como para mantener actualizada la información del proyecto. Las herramientas de documentación como Confluence, Wiki, Google Docs, entre otros, son útiles para este fin.

4. Herramientas de gestión de proyectos: estas herramientas permiten planificar y coordinar las tareas del proyecto, así como hacer seguimiento al progreso y tomar decisiones en base a los cambios realizados. Ejemplos de estas herramientas son Trello, Asana, Jira, entre otros.

Bugzilla. (2023). En Bugzilla - Sistema de seguimiento de errores. Recuperado el 22 de abril de 2023, de https://www.bugzilla.org/

Redmine. (2023). En Redmine - Software de gestión de proyectos. Recuperado el 22 de abril de 2023, de https://www.redmine.org/

Atlassian. (2023). Confluence. https://www.atlassian.com/es/software/confluence

Asana. (2023). Asana - Trabaja en cualquier momento y lugar con Asana. Recuperado el 22 de abril de 2023, de https://asana.com/es

# data[].attributes.body
La siguiente infografía plasma de forma resumida el tema de control de cambios, puede ingresar a verla a partir del enlace.
https://create.piktochart.com/output/eb0890779469-google-in-cloud-computing

# data[].attributes.attachment_link.description
Google in Cloud Computing | Piktochart Visual Editor

# data[].attributes.headline
Algunas de las herramientas más comunes son:

# data[].attributes.subject
Algunas de las herramientas más comunes son:

# data[].attributes.body
Sistemas de control de versiones

Herramientas de seguimiento de errores o incidencias

Herramientas de gestión de cambios

Herramientas de revisión de código

Herramientas de automatización de pruebas

# data[].attributes.headline
Aporte 1: Responsabilidades que conlleva tener un control de Cambios del proyecto de software

# data[].attributes.subject
Aporte 1: Responsabilidades que conlleva tener un control de Cambios del proyecto de software

# data[].attributes.body
Revisar y evaluar las solicitudes de cambio, esto implica asegurarse de que todas las solicitudes de cambio sean adecuadamente documentadas y revisadas para determinar su impacto en el proyecto.

# data[].attributes.headline
Se refiere a la práctica de gestionar y registrar los cambios realizados en un proyecto o sistema a lo largo del tiempo. 

# data[].attributes.subject
Se refiere a la práctica de gestionar y registrar los cambios realizados en un proyecto o sistema a lo largo del tiempo. 

# data[].attributes.body
Calvo Torres Jafed              19161246

Colmenares Cortés Oliver Axel          19161255

Monteón Ricárdez Nizvan                   19161357

Guevara González Abraham Yael             19161289

Salazar Vásquez Viviana Isabel (Líder) 19161403

Torres Cruz Naim Vladimir           19161425

# data[].attributes.body
En conclusión, el control de cambios es una parte crítica de la gestión de proyectos de software que permite a los equipos de desarrollo manejar los cambios propuestos de manera efectiva y controlar su impacto en el proyecto.

# data[].attributes.body
La actividad inicial es reconocer el cambio sugerido en el software. Esto puede involucrar modificaciones en los requisitos, la arquitectura, el diseño o el código del software.

# data[].attributes.body
Tiene como objetivo evaluar cómo el cambio propuesto afectará al proyecto en términos de recursos, tiempo y costo, así como la calidad del software.

# data[].attributes.body
Ayer, S. J., & Patrinostro, F. S. (1992). Software Configuration Management: identification, accounting, control, and management. McGraw-Hill, Inc.

Babich, W. A. (1986). Software configuration management: coordination for team productivity. Addison-Wesley Longman Publishing Co., Inc.

Berlack, H. R. (2002). Software configuration management. Encyclopedia of Software Engineering.

Morales, J. A. L., & Luzardo, M. L. G. (2007). Administración de proyectos en ingeniería del software. Telos, 9(1), 26-41.

Carrizo, D., & Alfaro, A. (2018). Método de aseguramiento de la calidad en una metodología de desarrollo de software: un enfoque práctico. Ingeniare. Revista chilena de ingeniería, 26(1), 114-129.

# data[].attributes.body
El control de cambios es una parte crítica de la gestión de proyectos de software, ya que permite administrar las modificaciones que se realizan en el software durante todo el ciclo de vida del proyecto.

# data[].attributes.attachment_link.title
[RESUMEN] Gestiona Correctamente un Control de Cambios en Proyectos de Software

# data[].attributes.body
Coordinar la aprobación de los cambios, es decir, se debe colaborar con el equipo de proyecto, los stakeholders y otras partes interesadas para obtener la aprobación de los cambios propuestos.

# data[].attributes.body
El proceso de control de proyecto en cinco fases descrito por Asana es una excelente manera de gestionar los cambios en un proyecto de manera estructurada y ordenada. Cada fase se enfoca en una tarea específica y ayuda a garantizar que los cambios se evalúen, analicen e implementen de manera efectiva.
Es importante destacar que la fase de evaluación de la solicitud del cambio es crucial para el proceso, ya que permite al encargado evaluar la solicitud y determinar si es viable o no. Si se pasa por alto esta fase, se corre el riesgo de aprobar cambios que no son necesarios o que pueden tener un impacto negativo en el proyecto.

# data[].attributes.body
También otras consideraciones que demos considerar para realizar o no realizar un cambio son que La organización debe revisar y controlar los cambios para la producción o la prestación del servicio, en la extensión necesaria para asegurarse de la continuidad en la conformidad con los requisitos. Al igual que la organización debe conservar información documentada que describa los resultados de la revisión de los cambios, las personas que autorizan el cambio y de cualquier acción necesaria que surja de la revisión.

# data[].attributes.headline
Aportación 2: Problemas que surgen como consecuencia de no tener un control de cambios

# data[].attributes.subject
Aportación 2: Problemas que surgen como consecuencia de no tener un control de cambios

# data[].attributes.body
No tener un control de cambios adecuado puede generar varios problemas en los proyectos, incluyendo:

1. Pérdida de información: Si no se lleva un registro de los cambios realizados en un proyecto, puede ser difícil rastrear cuándo y por qué se realizaron ciertos cambios, lo que puede resultar en la pérdida de información valiosa.

2. Confusión en el equipo: Si se realizan cambios sin notificar al equipo, puede causar confusión en cuanto a cuál es la versión más reciente o cuál es el trabajo que se debe realizar.

3. Aumento del riesgo de errores: Si los cambios no se registran adecuadamente, es más probable que se introduzcan errores en el proyecto, lo que puede resultar en costos adicionales y retrasos en el cronograma.

4. Dificultades en la colaboración: Sin un control adecuado de cambios, es más difícil para los miembros del equipo colaborar de manera efectiva, ya que no saben en qué punto del proyecto se encuentra cada uno.

5. Retrasos en el proyecto: Si los cambios se realizan sin un control adecuado, puede resultar en retrasos en el proyecto debido a la necesidad de revisar y corregir errores, lo que puede afectar el presupuesto y el cronograma del proyecto.

Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th ed.). Project Management Institute.

Kharade, K. (2019). Change Management in Projects: Why It Matters and How to Implement It. Project Management Institute.

# data[].attributes.body
Se realiza una evaluación exhaustiva del mismo para determinar su factibilidad y su conformidad con los requisitos del proyecto.

# data[].attributes.attachment_link.readable_text
Control de cambios en la configuración. Es la actividad de Gestión de Configuración más importante y su objetivo es proporcionar un mecanismo riguroso para controlar los cambios, partiendo de la base de que los cambios se van a producir. Normalmente combina procedimientos humanos y el uso de herramientas automáticas.

Tipos de cambio

Se pueden considerar fundamentalmente dos tipos de cambios:

Corrección de un defecto: Los clientes tienden a clasificar todos los cambios en esta categoría.

Mejora del sistema: Los programadores, sin embargo, los suelen clasificar aquí.

Para solucionar el problema de determinar realmente de qué tipo es un cambio es importante la trazabilidad de los requisitos. Por lo general se establecen varios niveles de control de cambios:

Control de cambios informal: Antes de que el Elemento de Configuración del Software pase a formar parte de una línea base, aquel que haya desarrollado el Elemento de Configuración del Software podrá realizar cualquier cambio justificado sobre él.

Control de cambios al nivel del proyecto o semi-formal: Una vez que el Elemento de Configuración del Software pasa la revisión técnica formal y se convierte en una línea base, para que el encargado del desarrollo pueda realizar un cambio debe recibir la aprobación de:

El director del proyecto, si es un cambio local

El Comité de Control de Cambios, si el cambio tiene algún impacto sobre otros Elementos de Configuración del Software

Control de cambios formal: Se suele adoptar una vez que se empieza a comercializar el producto, cuando se transfieren los ECS a la Biblioteca Maestra. Todo cambio deberá ser aprobado por el Comité de Control de Cambios.

Es necesario establecer de forma precisa, al comienzo de cada proyecto, cuál será el proceso de gestión de cambios que se va a utilizar. Para ello, será necesario definir:

Políticas a nivel organizativo que promuevan las actividades de control de cambios.

Los estándares que se van a adoptar y a los que será necesario ajustarse.

Los procedimientos que se van a utilizar para poner en práctica las políticas de Gestión de Configuración.

Las políticas de Gestión de Configuración deben reflejar la filosofía y las metas de la organización en cuanto a las actividades de Gestión de Configuración. Mientras que el objetivo de las políticas es definir el 'por qué' de la Gestión de Configuración, deben establecer un marco para definir el 'qué', el 'cuándo', el 'cómo' y el 'quién':

Las responsabilidades.

El contenido de las líneas base.

Los tipos de cambios que se van a controlar.

Las funciones del Comité de Control de Cambios.

El flujo de documentación entre el solicitante de un cambio y el Comité de Control de Cambios.

Los criterios para la valoración de las solicitudes de cambio, tanto de tipo técnico como de gestión.

Proceso de control de cambios

No hay ningún estándar para el control informal o interno de los cambios, aunque sí hay algunas recomendaciones (IEEE STD 1042 Guide to Software Configuration Management). En cuanto al control de cambios formal, se puede estructurar de muchas formas. Vamos 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 una línea base:

Iniciación del Cambio: se presenta una solicitud de cambio, que puede venir provocada por un problema que se ha detectado o por un cambio en los requisitos.

Clasificación y registro de la solicitud de cambio.

Aprobación o rechazo inicial de la solicitud de cambio. De ello suele ser responsable el Comité de Control de Cambios.

Evaluación de la solicitud de cambio, si ha sido aprobada, para calcular el esfuerzo técnico, los posibles efectos secundarios, el impacto global sobre otras funciones del sistema y el coste estimado del cambio. Como resultado se obtiene un Informe de Cambio.

Se presenta el Informe de Cambio al Comité de Control de Cambios. Si se considera que el cambio es beneficioso se genera una Orden de Cambio (también llamada Orden de Cambio de Ingeniería), que describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoría. Esta Orden de Cambio es asignada a alguno de los ingenieros de software para que se encargue de llevarlo a cabo. En este momento, el objeto a cambiar se da de baja en la Biblioteca de Soporte al Proyecto.

Se realiza el cambio, entrando en un proceso de seguimiento y control.

Una vez finalizado el cambio, se certifica, mediante una revisión, que se ha efectuado correctamente el cambio y con ello se ha corregido el problema detectado o bien se han satisfecho los requisitos modificados. El objeto se devuelve a la Biblioteca de Soporte al Proyecto.

Se notifica el resultado al originador del cambio.

Al definir este proceso, será también necesario:

Definir los mecanismos para solicitar cambios sobre los Elementos de Configuración.

Definir los mecanismos para analizar y evaluar el impacto de las solicitudes de cambio.

Definir los mecanismos para aprobar o rechazar las solicitudes de cambio.

Definir los mecanismos para controlar la realización de los cambios aprobados.

Los procesos de alta y baja de la Biblioteca del Proyecto implementan dos elementos importantes del Control de Cambios: el control de acceso y el control de sincronización:

El Control de Acceso se refiere a los derechos que tienen los diferentes miembros del equipo de desarrollo para acceder y modificar ECS concretos. Así, por ejemplo, hay que controlar el acceso del ingeniero de software que da de baja el ECS de la Biblioteca de Proyecto para realizar un cambio aprobado por una Orden de Cambio.

El Control de Sincronización ayuda a asegurar que los cambios en paralelo, realizados por equipos o personas diferentes, no se sobrescriben. Así, cuando un ECS se da de baja de la Biblioteca de Soporte, el Control de Sincronización bloquea el objeto para que no se puedan hacer más actualizaciones sobre él hasta que se haya reemplazado con una nueva versión. El almacén de una herramienta de control de versiones se puede considerar como la Biblioteca de Soporte o de Proyecto. Estas herramientas ofrecen también de forma automática el control de acceso y control de sincronización.

Mecanismo para solicitar cambios

El primer mecanismo que es necesario definir es el mecanismo para solicitar cambios sobre los Elementos de Configuración. El primer paso es definir el formulario que se debe utilizar para solicitar cambios. Este formulario de Solicitud de Cambio debe contener información suficiente para determinar:

por qué se necesita el cambio (el elemento no funciona tal y como debe hacerlo, le falta alguna característica, etc.)

qué hay que cambiar

quién lo solicita

descripción del problema lo suficientemente detallada como para que se pueda recomendar una solución.

otros ECS que se pueden ver afectados por el cambio.

otros cambios con los que está relacionado.

aprobación del cambio.

cómo se solucionó el problema, etc.

En cualquier caso, debe ser simple, y aceptado por las personas que lo tendrán que manejar. El formulario más común es el de Solicitud de Cambios. Sin embargo, casi siempre se utilizan formularios diferentes para solicitar una mejora y para informar de un problema o deficiencia detectado durante una auditoría, una prueba o el uso del sistema (y que posiblemente requerirá un cambio). A los formularios que se usan para informar de problemas se les suele llamar Informes de Incidencias o Informes de Problemas. Recogen información adicional sobre el incidente que ha desvelado la existencia de un problema:

Fecha y hora en que ocurrió,

descripción del incidente,

efectos que ha producido,

de qué forma se puede duplicar el incidente, si es que se ha podido duplicar,

volcado de datos,

referencia al tipo de prueba que se estaba efectuando.

Este Informe de Incidencia es analizado por los desarrolladores, y estos pueden recomendar alguna de las siguientes acciones:

No requiere acción: Cuando lo que se describe en el informe de incidencia no es realmente una deficiencia. Esta situación suele ser debida a malentendidos acerca de la forma de funcionamiento del sistema. También se puede dar esta situación cuando ya se ha informado previamente de una incidencia similar, y se están tomando las acciones correctivas necesarias.

Solicitud de Cambio: La implementación se corresponde con el diseño del sistema, pero una mejora en el diseño del sistema solucionaría el problema. Se genera entonces una Solicitud de Cambio, que se tratará por los cauces normales.

Notificación de Cambio: Cuando la deficiencia que se describe en el informe de incidencia se debe a una mala implementación que debe ser corregida. Se informa entonces al CCC y se pasa a corregir la deficiencia.

Aparece, como vemos, un nuevo formulario, la Notificación de Cambio. Una Notificación de Cambio puede dar respuesta a varios Informes de Incidencias, cuando todos ellos corresponden al mismo problema. Para solicitar cambios en la documentación se pueden utilizar los formularios anteriores o un nuevo formulario al que se suele llamar Formulario de Seguimiento de la Documentación. La resolución de un Informe de Incidencia o de una solicitud de cambio.

Mecanismo para aprobar o rechazar las solicitudes de cambio

Algunos criterios que se pueden tener en cuenta para tomar la decisión de aprobar o rechazar las solicitudes de cambio son los siguientes:

Valor del cambio para el proyecto/organización

Retorno de la inversión

Tamaño

complejidad

impacto sobre el rendimiento del producto (uso de memoria y CPU)

recursos disponibles para efectuar el cambio (humanos y materiales)

relación con otros cambios ya aprobados y en progreso

tiempo estimado para completar el cambio

relación con las políticas de la empresa (satisfacción del cliente, competitividad, etc.)

existencia de alternativas, etc.

Seguimiento de los cambios. Gestión de Problemas

Una vez aprobado un cambio debido a un problema se debe realizar un seguimiento del mismo. 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 la misma 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

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

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

# data[].attributes.attachment_link.description
Control de cambios en la configuración. Es la actividad de Gestión de Configuración más importante y su objetivo es proporcionar un mecanismo riguroso para controlar los cambios, partiendo de la base de que los cambios se van a producir. Normalmente combina procedimientos humanos y el uso de herramientas automáticas.

# data[].attributes.body
Si se determina que el cambio propuesto es viable y cumple con los requisitos del proyecto, se avanza hacia la aprobación del cambio por parte del equipo de gestión del proyecto

# data[].attributes.headline
Su objetivo es mantener un registro histórico de los cambios realizados en un proyecto, permitiendo a los equipos de desarrollo o a otros interesados rastrear y comprender los cambios.

# data[].attributes.subject
Su objetivo es mantener un registro histórico de los cambios realizados en un proyecto, permitiendo a los equipos de desarrollo o a otros interesados rastrear y comprender los cambios.

# data[].attributes.body
Se llevan a cabo y poner en práctica las modificaciones planificadas en el software

# data[].attributes.body
Comunicar los cambios a las partes interesadas, esto implica asegurar de que todas las partes interesadas sean informadas acerca de los cambios propuestos y de cómo afectarán al proyecto.

# data[].attributes.body
El objetivo es encontrar errores para corregirlos y asegurar que el software se ha diseñado y construido de acuerdo con las especificaciones y estándares establecidos

# data[].attributes.body
Mantener actualizada la documentación del proyecto, incluyendo el plan de proyecto, el plan de gestión de cambios y cualquier otra documentación relevante.

Monitorear y reportar el estado de los cambios, con lo cual se debe llevar un seguimiento del estado de los cambios y reportar periódicamente el progreso y los resultados a las partes interesadas.

# data[].attributes.body
Se refiere a la creación y mantenimiento de registros y documentos relacionados con los cambios realizados en el software durante el proceso de desarrollo y mantenimiento.

# data[].attributes.body
Se refiere a la supervisión continua y control de un sistema o proyecto de software para asegurar su correcto funcionamiento,