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.