| Resumen DocIRS se propone que en sus
proyectos, todos ganen (Ver videos)
Cuando se
inicia un proyecto, DocIRS dedica un tramo de tiempo significativo a comprender los
intereses de su cliente, a fin de establecer los lineamientos de un acuerdo que
satisfaga a ambas partes. Este conocimiento, se lleva a cabo durante las primeras fases de
la metodología DocIRS, especialmente en la Definición del Modelo de Negocio, donde se
define una amplia gama de opciones para que el proceso fluya. Por tanto el presente
protocolo, no es para inhibir la imaginación sino para encontrar criterios y
procedimientos objetivos entre las partes y fundamentalmente para lograr un trabajo en
equipo, con amplitud de mente y flexibilidad inteligente, hacia las dificultades y cambios
que se avecinan.
El presente documento ha sido elaborado como referencia para gestionar
los requerimientos y los inevitables cambios a los que están sujetos a un proyecto de
desarrollo computacional.
El objetivo es dotar de un instrumento técnico con enfoque proactivo, que permita normar
la relación entre el cliente, el equipo que está en terreno trabajando con él, y el
equipo que está desarrollando y realizando el soporte en los servidores de DocIRS.
(Ver Plataforma de Gestión
de Calidad DocIRS)
Es necesario que el cliente comprenda que todo cambio tiene un costo desde el momento
mismo en que completa y firma la solicitud de cambio, pues aunque finalmente no se
apruebe, la evaluación previa requiere de esfuerzo, tiempo y dinero. Debe quedar en claro
que será muy favorable para el calendario y recursos consumidos elevar las solicitudes de
cambio en la etapa más temprana posible.
El documento cuenta con 16 capítulos distribuidos en 8 páginas, que se pueden visualizar
y enlazar directamente desde el Índice, el cual está localizado en la cabecera de cada
una de las páginas.
|
1. Introducción
 El diseño de sistemas es un concepto que define los requerimientos
funcionales asociados al negocio (procesos) que se solicita apoyar, lo que se traduce en
el producto de aplicación computacional como un conjunto de componentes funcionales o
estructurales. Este concepto es utilizado en la construcción como base para el diseño
detallado.
Los sistemas que construye DocIRS, son elaborados con la intención que
posean una vida útil amplia, porque sabemos que las condiciones de los requerimientos
iniciales del sistema y el entorno de la organización del cliente varían constantemente
en el tiempo, y por tanto también constituye un negocio el brindar servicios
permanentemente.
Para que tales sistemas respondan a los requerimientos operativos para
los que fueron desarrollados y, que además se ajusten a las nuevas condiciones, se hace
necesaria la mantención y políticas de cambio claras y honestas por parte de
todas las partes involucradas, de
tal manera el cliente siempre esté informado, desde la génesis del proyecto, acerca del
costo de las horas hombre y las medidas de tiempo que se aplicarán a dichos
mejoramientos.
Este concepto dice relación con la metodología de ir desarrollando
versiones mejoradas y de entregar soporte a través de un convenio o contrato de
prestación de servicios. Nótese que DocIRS no desarrolla mega paquetes cerrados de
software, sino soluciones evolutivas.
En general, todo sistema se va haciendo cada vez más complejo y su
tamaño se incrementa a medida que le son adicionadas nuevas funcionalidades. Dichas
adiciones son incorporadas a través de actividades de mantenimiento, que van ajustando la
aplicación y, por ende, implican modificar la estructura del sistema. De manera el tiempo
y el diseño en ese instante ya no corresponde a la arquitectura inicial considerada para
su desarrollo y, además, el código no corresponde a la documentación generada
inicialmente. Dado lo anterior, se hace cada vez más difícil entender el sistema y,
sobre todo, si los cambios no se consideran realizar por versiones bien especificadas.
Dado lo anterior, los cambios de un sistema deben controlarse y
documentarse, no se debe olvidar que las modificaciones siempre van a aparecer. Por lo
tanto, es esencial anticipar posibles cambios a los requerimientos cuando el sistema se ha
desarrollado y utilizado, teniendo presente que se deben mantener las fronteras dentro del
presupuesto y tiempo comprometido. Esto se logra a través de la comunicación entre las
partes CLIENTE-PROCESO Y DISEÑO-CONSTRUCCIÓN, la cual es fundamental.
Por todo lo anterior, el objetivo de este documento es establecer una
herramienta que se base en la arquitectura del producto a construir y, que además
controle su evolución, para evitar:
• Recargar el equipo de trabajo.
• Traspasar responsabilidades a terceros.
• Ambigüedades.
• Generar expectativas que nunca se registraron.
• Generar déficit aumentando la cantidad de trabajo y de tiempo, e
• Impedir la desestructuración del sistema a lo largo de su vida útil.
Siguiente Capítulo |
