10. Aprobación del Cambio en Etapa en Curso

Una vez identificado el cambio (Ver Ficha de Solicitud de Requerimiento), el Gerente de Desarrollo junto con el equipo de Desarrollo, realiza el análisis de la solicitud de cambio y la evaluación de costos respectivos, para establecer el número de requerimientos que se verán afectados al ejecutar el cambio y el costo, en cuanto a tiempo y recursos. A partir del análisis, el Gerente de Desarrollo toma la decisión, que en el caso de ser positiva, permite el inicio de la implementación del cambio.

Los aspectos que se deben considerar para la aprobación de un cambio solicitado son:

i) Impacto del cambio en el costo y funcionalidades del sistema.

 ii) Impacto para el cliente.

 iii) Desestabilización potencial del sistema que pudiera ocasionar un cambio.

Todo cambio factible debe ser clasificado y documentado, para poderlo realizar en el periodo de tiempo correcto, por lo tanto:

i) Si el cambio es menor y factible, el equipo de Desarrollo lo llevará a cabo dentro de la misma etapa de Construcción.

ii) Si el cambio es mayor y factible, pero impacta la estructura, tiempo y recursos en la etapa en curso, será realizado en la siguiente versión, es decir, debe ser puesto en la lista de los mejoramientos para la siguiente versión.

11. Cambios cuando se está construyendo

Esta etapa es una de las más complejas para realizar cambios. Sin embargo, dentro de DocIRS es cuando más surgen, dado que el equipo de Procesos va descubriendo múltiples posibles mejoramientos y cambios, que desde su punto de vista y deseo son factibles de realizar en el instante . Este deseo o petición debe ser recogido por el equipo de Desarrollo y en forma flexible lo debe analizar.

Nótese que:

• Los requerimientos durante esta etapa, se tienden a clasificar erróneamente como una falla del sistema y, no como una ampliación, una mejora, o una nueva funcionalidad.

 • Siempre se parte de la base que el cliente hasta ese instante ha llevado su negocio en marcha, sin contar con el sistema, por lo tanto, éste puede esperar hasta el desarrollo de la siguiente versión para incorporar el cambio.

 • Aunque el cliente esté dispuesto a pagar por el cambio y ampliar los tiempos entrega, de igual modo, deberá someterse a un análisis y continuar con la metodología de consolidar la primera versión. (Un objetivo, que según las políticas de DocIRS, siempre es terminar y probar de acuerdo a lo planificado).

12. Cambios cuando está implantado el sistema

Cuando el sistema se esté probando y/o ya se esté usando, los controles de cambios deben ser cubicados, y luego cargados sus costos ya sea a la mantención o al número de horas hombre que requiere la ejecución del cambio, de acuerdo a los estándares previamente definidos con el cliente. (Ver funcion de Cambio[1])