8. Presentación de un Cambio

Todo nuevo requerimiento debe ser documentado y sometido a un procedimiento de revisión formal, donde debe ser aprobado para ser incluido en la construcción.

El requerimiento debe ser evaluado de acuerdo a la etapa donde se encuentre y/o impacto que genere en el proyecto. Por ejemplo:

i) Si se está iniciando la construcción, aún sin base de datos ni códigos realizando transacciones, los cambios tienen una mayor factibilidad de se realizados.

ii) Si la petición de cambio no afecta mayormente los tiempos y el presupuesto, entonces se procede a aprobar el requerimiento (o a renegociar los términos del proyecto).

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso y sólo hacia el Gerente de Desarrollo, quien evaluará y, eventualmente, delegará el requerimiento para que sea atendido por otro miembro del equipo de desarrollo.

9. Normas de Evaluación de un Cambio

Cuando se esté próximo a una entrega, por lo menos 1 día hábil antes, los encargados del testing ya deben poseerlo con el fin de hacerles las pruebas necesarias, además de dar paso a las acciones correctivas en caso de necesitarlas, y luego dar la autorización para el cambio de versión y presentación al cliente.

Se medirán los requerimientos estipulados, esto implica cumplimento de compromisos y responsabilidades, los que en caso de ser fallados inducirán a una mala imagen de DocIRS para el cliente, por lo que siempre el equipo velará por que esto no ocurra y siempre estemos presentando un excelente prototipo y, al final debe tener la calidad que nos proponemos.

Para cualquier tarea de programación que realice algún integrante del equipo de desarrollo, éste debe registrar en el documento “Registro de Desarrollo” los siguientes datos: la fecha en que se compromete a realizar la tarea, el caso de uso al que atiende la tarea, el tipo de trabajo que se realizará (creación, revisión, mantención o corrección), la descripción detallada de la tarea, los nombres de los documentos fuentes generados y la fecha de entrega del trabajo. Una vez terminado el trabajo, el Jefe de Proyecto o la persona que esté a cargo de la revisión, debe dar el Visto Bueno o solicitar la revisión del trabajo desarrollado.

Todos los cambios deben ser probados primeramente por los propios programadores en Ambiente de Desarrollo, posteriormente en el Ambiente de Pruebas por el Jefe de Proyecto y posteriormente una vez aprobado por el Gerente de Desarrollo, pasado al Ambiente de Producción.

Como medidas generales de tratamiento de Desarrollo y en particular para los cambios:

• Se respaldará la información del desarrollo del proyecto cada vez que se realice una modificación, esto con el fin de evitar los riesgos que van desde la pérdida de información por efectos internos (falta de respaldo en momento apropiado) o externos (siniestros como corte de electricidad, incendio u otra catástrofe).

• Se respaldará todas las carpetas semanalmente de forma automática mediante un script ya implementado. Esta tarea está asignada al encargado de soporte del DataCenter de DocIRS.

• En caso de ser necesario modificar la tarea de otro integrante del equipo, se debe avisar al involucrado, a fin de realizar la modificación y posterior respaldo.

• Todas las acciones a realizar por alguno de los integrantes del grupo debe ser debidamente informado al resto del equipo, en especial al jefe de proyecto que es el encargado de la organización frente al cliente.

• Todo cambio a la Base de Datos por alguno del equipo de desarrollo debe ser informado al Gerente de Desarrollo.