Protocolo DocIRS 3/5

Indice

3.1 El eterno problema de un Cambio (Aumentar la Cantidad de Trabajo y dejar las otras variables constantes)

Entendemos que cuando se realiza un Cambio en un proyecto de construcción se afectan las tres variables que aparecen en la figura.

Es decir, un cambio es función o se explica por tres variables agregadas: la Cantidad de Trabajo que demandará el cambio, el Tiempo Requerido en HH y el Precio que significa la modificación.

Donde, la correlación está dada por el orden DCt Þ DTÞ DP

• Ct: Cantidad de Trabajo que demanda el cambio

• T: Tiempo Requerido (por el cambio)

• P: Precio (Costo de HH para desarrollar el Cambio)

Por tanto, se debe evitar,- para no perjudicar a ninguna de las partes-, exigir que varíe la Cantidad de Trabajo y se espere (o solicite) que las otras dos variables permanezcan constantes.

Este hecho es frecuente por parte de variados clientes que solicitan cambios. Es decir, generalmente desean incorporar una modificación mayor dentro del requerimiento inicial, sin querer cambiar ni el tiempo ni el precio. La consecuencia final de este comportamiento “winner” conlleva a romper el trabajo en equipo y a generar un actitud defensiva por el proveedor y socio tecnológico.

De ahí que DocIRS propone, incluir y acordar un modelo de Control y Administración de Requerimientos que comience a operar desde que se inicia el proyecto de desarrollo de sistemas, que permita acoger los cambios definiendo un margen de presupuesto adicional que eventualmente cubra estas necesidades de cambios que pudiesen surgir durante la construcción. Si el protocolo está claro en términos de procedimientos, como así mismo el estándar de costos HH, entonces se evitará un conflicto y perjuicio económico de una de las partes.

3.2 Implementar con el cliente un modelo de Control y Administración de Requerimientos.

Contar con un modelo de Control y Administración de Requerimientos concertado en el protocolo, permitirá identificar en todo momento el avance del proyecto de software y tener un tratamiento apropiado para las modificaciones. Porque no toda necesidad es un requerimiento,  la mayoría de lo mejoramientos que se vislumbren podrían concretarse en la presente versión o en la siguiente. Sin embargo, cuando existe una relación entre las partes de imposición, de obtener ganancias,...  es muy probable que el análisis  de la petición esté influido por la desconfianza.

Lo importante es tener presente la función Cambio=F(Ct,T,P), (  Ver [1]) y preservar los alcances dentro del marco de acuerdo las variaciones, con el fin que todos los cambios sugeridos sigan el procedimiento.

En sintesis,

El iniciador del cambio será un representante del cliente autorizado para elevar tal solicitud. El origen del cambio puede tener lugar en un nuevo requerimiento que el cliente descubrió a medida que el proyecto fue avanzando, una necesidad de mejora, o simplemente un cambio solicitado por la no satisfacción del cliente con algún aspecto del producto en desarrollo. Deberá completar una solicitud formal para el cambio y firmarla.

4. Causas de Cambios de un Sistema

Cuando el sistema está implantado y se está usando pueden surgir modificaciones a éste debido a las siguientes causas:

i) Cambios tecnológicos

ii) Cambios en las estrategias o prioridades del negocio

Estos dos tipos de cambios difícilmente pueden ocurrir cuando DocIRS está construyendo, debido a la magnitud y los plazos acotados o limitados de construcción que poseen las aplicaciones que se desarrollan.

Además de los cambios anteriormente mencionados, se presentan modificaciones por la carencia de un protocolo, los cuales surgen cuando se está en la etapa de construcción, las causas de estos cambios son:

i) Al analizar el problema a solucionar, no se hacen las preguntas correctas y necesarias a las personas indicadas. Y/o no se obtiene la aprobación de la persona pertinente al requerimiento.

iii) Cambió el problema que se estaba resolviendo.

vi) Los usuarios o los propios miembros del equipo DocIRS cambiaron su forma de pensar o sus percepciones.

Estas tres causas mencionadas, pueden ser prevenidas al formalizar el Diseño Inicial, el cual debe ser aprobado por el Cliente.

5. Carácter de los Cambios

Desde nuestra experiencia, es claro que el carácter de los cambios es emergente, dado que surgen al ir analizando las reglas de negocio del cliente y el sistema en profundidad. .

Así mismo, el carácter de los cambios puede ser de dos tipos: Colateral, debido a que surgen como efecto de la inclusión de otros requerimientos ; o de Compatibilidad, puesto que aparecen al adaptar el sistema a su entorno, debido a que el medio físico cambia. Trasladar un sistema de un entorno a otro siempre requiere modificaciones.

La propia existencia del sistema va a generar nuevos requerimientos por parte de los usuarios.

6. Tipo de Cambios

Los cambios solicitados a una aplicación están divididos en dos tipos:

i) Cambio Menor. Cuando se esté en etapa En Construcción y se requiere un cambio que no afecta simultáneamente:

a. La estructura de la base (nueva tabla, nuevos campos),

b. La creación y modificación de Procedimientos almacenados, y

c. Los códigos de las rutinas, script y formularios.

Es decir, será Menor cuando sea un cambio a nivel de formularios, parámetros, etiquetas, entre otros, que no requiera disponer de varias horas y recursos de horas hombre para desarrollar y probar, distintas a lo planificado hasta ese instante. En términos de la función la función reguladora Cambio=F(Ct,T,P),    (Ver [1]), diremos que un Cambio Menor si preserva los alcances dentro del marco de acuerdo las variaciones y no afecta las otras tareas de la Carta Gannt.

ii) Cambio Mayor. Cuando se esté en etapa En Construcción y no se pueda catalogar como un cambio menor. Es decir, todas aquellas modificaciones distintas a cambios menores donde las variaciones afectan el tiempo, el costo y las otras tareas de la Carta Gannt del equipo. Es decir, si su impacto en costos, calendario y recursos es significativo.

La clasificación del cambio como Cambio Menor o Cambio Mayor para una modificación solicitada es determinada por el equipo de Desarrollo, luego de haber analizado la solicitud en función de los criterios que regula la función Cambio=F(Ct,T,P),  (Ver [1]).

Siguiente Capítulo