Captulo II

Caractersticas del Desarrollo de Sistemas

1. Cmo es el Ciclo de Desarrollo?
Se puede decir que la ingeniera del software nace como disciplina a finales de los aos 60, cuando se acua el trmino software engineering para referirse a los procedimientos de diseo y construccin de programas. Desde entonces, las tcnicas para desarrollar sistemas han venido evolucionando, guiadas por diferentes propuestas metodolgicas: estructuradas, de orientacin a objetos, etc. Por lo general, la mayora de las propuestas metodolgicas vigentes dividen el Ciclo de Desarrollo de Sistemas en varias fases o grandes etapas, para las que se utilizan diversas denominaciones. Una de ellas, de uso bastante generalizado es la siguiente: Fase I Planificacin de Tecnologa de Informacin Fase II Anlisis y Diseo General Fase III Diseo Detallado y Construccin Fase IV Pruebas e Implantacin Fase V Produccin/Mantenimiento Muchos autores no incluyen, dentro del ciclo de desarrollo de sistemas, la fase de planificacin de tecnologa de informacin, sino que consideran que el desarrollo de un sistema se inicia en su fase de anlisis y diseo general. Las empresas Microsoft y Rational (hoy da IBM) han propuesto guas metodolgicas, en las que la denominacin de fases difiere de la denominacin tradicional, por llamarla de alguna forma, arriba presentada; sin embargo, en lneas generales, las diferencias entre un esquema y otro es ms de denominacin. El ciclo de desarrollo de sistemas propuesto por la empresa Microsoft, en su MSF (Microsoft Solutions 15

Framework), como puede observarse en la grfica, propone una denominacin diferente a las fases: I. Visualizacin II. Planificacin III. Desarrollo IV. Estabilizacin V. Implantacin Dentro de esta metodologa, en las fases I y II (Visualizacin y Planificacin) se desarrolla tanto la definicin de requerimientos funcionales, como el plan para desarrollar el sistema. La fase III (Desarrollo) incluye todas las actividades de construccin (desarrollo de programas, instructivos, etc.). Las fases IV y V (Estabilizacin e Implantacin) comprenden las actividades de prueba, aceptacin del sistema y puesta en operaciones. MSF es una excelente gua metodolgica, que incluye una descripcin sumamente interesante y completa de las disciplinas que deben gobernar todas las actividades de desarrollo de sistemas y, adems, enfatiza los aspectos relacionados con los productos que cada fase debe generar. Algo similar ocurre con el modelo RUP (Rational Unified Process), en el que se presenta el ciclo de desarrollo integrado por las siguientes fases:

I. Preparacin Inicial o Conceptualizacin (Inception) El objetivo principal de esta fase es establecer los objetivos del sistema, en ella se establece el caso del negocio (business case), con el fin de delimitar el alcance del sistema y el alcance del proyecto. II. Preparacin Detallada o Elaboracin (Elaboration) El objetivo principal de esta fase es establecer la arquitectura del producto. En ella se realiza el levantamiento de la mayor parte de 16

los requerimientos funcionales, analizando los riesgos que pudieran amenazar el logro de los objetivos del sistema. III.Construccin (Construction) El objetivo principal de esta fase es desarrollar el producto. En esta fase, a travs de sucesivas iteraciones e incrementos, se desarrolla un producto de software, hasta dejarlo listo para operar. IV.Transicin (Transition) El objetivo principal de esta fase es instalar el producto, una vez realizadas las pruebas de aceptacin y habiendo efectuado los ajustes y correcciones que sean requeridos.

2. Divide y Vencers
Pocos aos atrs, discutiendo sobre la conveniencia de fraccionar el rgido ciclo que presenta el modelo de desarrollo de software en cascada, un consultor veterano en los quehaceres del desarrollo de sistemas me sealaba que eso era un planteamiento acadmico, que los sistemas se tenan que desarrollar por fases perfectamente delimitadas. Al trmino de cada una de ellas, los usuarios firmaban en seal de aceptacin del producto y, en la ltima fase, se instalaba el nuevo sistema. Hoy da, esa discusin ya no tiene cabida, pues todos los enfoques metodolgicos (incluyendo los dos mencionados en la seccin anterior: MSF y RUP) reconocen que los macroproyectos no llevan sino al fracaso y a la frustracin. Los ingenieros de sistemas han aceptado, despus de muy amargas experiencias, la validez del principio divide y vencers. La Ingeniera de Sistemas ha aceptado, como verdad universal, que los proyectos de desarrollo de sistemas deben tener alcances suficientemente manejables, para que no se caiga en la clebre trampa de papel, la cual llamamos as, porque era muy comn observar proyectos muy ambiciosos que, ms que a desarrollar un sistema, parecan estar destinados a producir largas piezas de documentacin que los usuarios nunca terminaban de entender y que nunca terminaban de concretarse en hechos. Una vieja encuesta hecha por el Standish Group, publicada en el peridico Computerworld; sealaba que el 73 % de los proyectos de tecnologa informtica desarrollados por las corporaciones americanas durante 1996 fueron cancelados o, si se concluyeron, ello ocurri con retraso y con un costo muy superior al presupuestado originalmente. Esa misma encuesta sealaba tambin que el costo de estos fracasos superaba los 145 millardos de dlares.

17

No pretendemos afirmar que la nica razn de los fracasos arriba sealados fue la falta de habilidad para fraccionar esos proyectos en subproyectos manejables. Lamentablemente, la complejidad no es el nico factor que pesa; sin embargo, es uno de los factores ms importantes y puede afirmarse, como regla general, que cada vez que un proyecto, en cualquiera de sus etapas, trata de atacar todo de una vez, arriesga la calidad de su producto y atenta contra la productividad de los recursos disponibles. Contraponindose a la necesidad de dividir para vencer, est la necesidad de crear sistemas integrales. La calidad de un sistema de informacin est dada por su capacidad para atender y automatizar, en forma integral, los requerimientos del negocio; los sistemas de informacin no pueden estar parcelados, pues las empresas, dada la dinmica y sofisticacin de los negocios modernos, necesitan sistemas que ofrezcan soluciones perfectamente integradas. Y sabemos muy bien que un sistema integrado no es la simple suma de aplicaciones parceladas, sino la combinacin e interrelacin de varias aplicaciones bajo una arquitectura comn de datos y procedimientos. As pues, el gran reto de la Ingeniera de Sistemas es desarrollar sistemas integrales, que atiendan todos los requerimientos de cada proceso del negocio, descomponiendo y agrupando pequeos proyectos bajo una arquitectura nica. Esta situacin nos trae a la memoria el famoso proyecto del tnel bajo el Canal de la Mancha. Un tnel de cincuenta kilmetros, treinta y ocho de ellos bajo el mar, que aseguran la conexin terrestre entre Europa e Inglaterra. Su construccin se realiz simultneamente desde el lado ingls y desde el lado francs. Antes del 1 de diciembre de 1990, cuando se produjo el momento histrico del encuentro entre los equipos de trabajo de Francia e Inglaterra (que tuvo lugar bajo el mar en el tnel de servicio a 15,6 kilmetros de Francia y 22,3 kilmetros de Inglaterra), la pregunta que todo el mundo se haca era si los equipos llegaran a encontrarse, si no habran tomado direcciones diferentes. Como es bien sabido, el proyecto fue un verdadero xito, el 6 de mayo de 1995, la reina Isabel II de Inglaterra y el presidente francs, Francois Mitterand, inauguraron los cincuenta kilmetros de tnel. Evidentemente, los ingenieros que disearon el clebre tnel tenan la visin de conjunto y los equipos de trabajo cumplieron su cometido, siguiendo las direcciones establecidas en esa visin de conjunto. Para enfrentar el reto de calidad vs. productividad que en los prrafos anteriores discutamos, la Ingeniera de Sistemas ha adoptado enfoques similares al que siguieron los ingenieros del tnel: establecer la visin de 18

conjunto y llevarla a la prctica a travs de la ejecucin de pequeos proyectos que desarrollan slo un segmento de ese conjunto. De esta forma, partiendo de un Plan de Tecnologa de Informacin, en el que se presenta el diseo de la arquitectura de sistemas requerida por un rea funcional, se especifican los alcances y caractersticas de los sistemas que debern integrar tal arquitectura.

A su vez, al iniciar el desarrollo de cada uno de los sistemas que conforman el Plan de TI, la fase de Anlisis y Diseo General permitir detallar ms el diseo arquitectnico, con el fin de fraccionarlo en aplicaciones y mdulos, facilitando as, la definicin de un conjunto de proyectos pequeos y manejables, pero capaces de convertir realidad la visin de conjunto. As pues, el fraccionamiento de la complejidad de los sistemas requeridos por las diferentes funciones de la empresa se inicia desde la fase de Planificacin de TI, de la cual se deriva un plan de sistemas de informacin capaz de dar a la gerencia de informtica la visin de conjunto necesaria para fraccionar la complejidad de los sistemas requeridos las reas del negocio, en trminos de proyectos manejables.

3. El Plan de Versiones
Tal como discutamos en el punto anterior, el plan de sistemas, producto de la fase de Planificacin de TI, es el primer corte o la primera particin de la complejidad ofrecida por los sistemas funcionales. Cada uno de los sistemas (partes del plan), a su vez, ir sufriendo segmentaciones 19

adicionales en la fase de Anlisis y Diseo General, de la cual se derivar un plan de desarrollo por versiones.

3.1. Desarrollo por Versiones

El concepto de versin se basa en la idea de que un sistema puede ser construido e instalado gradualmente en lugar de hacerlo de una sola vez. Se aplica en forma muy similar al concepto de release utilizado por los proveedores de software, pues cada nueva versin de un sistema incorpora un grupo adicional o mejorado de funciones.

El concepto central del desarrollo por versiones es instalar, lo ms pronto posible, las funciones y facilidades ms importantes para el usuario (atender las prioridades del negocio), de tal manera que pueda comenzar a obtener los beneficios del nuevo sistema, sin tener que esperar a que todo el sistema est construido. Las funciones que constituyen el resto del sistema se irn incorporando paulatinamente, a medida que se desarrollen nuevas versiones, hasta que, con la ltima versin, se hayan incorporado todas. El desarrollo de sistemas por versiones y su solapamiento permiten optimizar el uso del personal y, a la vez, satisfacer ms rpidamente las necesidades prioritarias del negocio. La administracin de versiones permite, adems, manejar convenientemente los cambios que, a travs del proyecto, el usuario vaya requiriendo, ya que cada nueva versin puede incorporar los cambios que hayan sido planteados por los usuarios, a medida que han ido adquiriendo experiencia en la operacin de la versin instalada. 20

Debe sealarse tambin, que el desarrollo por versiones no slo permite que los beneficios del nuevo sistema puedan obtenerse a ms corto plazo, sino que tambin permite planificar y ejecutar mejor las tareas de un proyecto, al concentrar la atencin de sus participantes en un reducido nmero de funciones; en efecto, el desarrollo por versiones es la mejor solucin a la necesidad de manejar eficientemente la complejidad total del proyecto. Es necesario, sin embargo, tener presente que el desarrollo por versiones presenta dos problemas: Aumenta el riesgo de tener un producto heterogneo. Se hace necesario, por lo tanto, vigilar muy de cerca que cada versin encaje dentro del concepto arquitectnico del sistema (asegurar que los equipos que construyen el tnel se encuentren). Crea, en muchos casos, la necesidad de desarrollar mdulos provisionales de interfaz con el sistema actual; dado que el nuevo sistema slo se instala parcialmente, es posible que deban conservarse algunos mdulos del sistema vigente. Lo cual requiere crear mdulos provisionales que permitan intercambiar datos entre ambas partes.

3.2. Mantenimiento por Versiones

La implantacin de sistemas por versiones permite manejar los cambios en forma planificada, ya que los diferentes cambios que soliciten los usuarios sobre la versin en produccin, pueden irse acumulando con el fin de incluirlos en una versin posterior. Un criterio similar puede aplicarse cuando el sistema ya ha sido totalmente desarrollado e implantado, de tal forma que todos aquellos cambios que no sean de emergencia pueden reunirse para ser incorporados en una prxima versin. El mantenimiento por versiones es mucho ms eficiente, ya que es ms eficiente incorporar de una sola vez todo un conjunto de cambios, en lugar de irlos incluyendo puntualmente, a medida que sean solicitados. Adicionalmente, una nueva versin pueda ser probada como conjunto y mucho ms a fondo, por lo que su calidad ser superior.

4. La Administracin de Proyectos de Desarrollo

Muchas personas consideran que un proyecto de desarrollo de sistemas es perfectamente comparable con un proyecto de construccin civil; sin embargo, existen diferencias importantes entre ambos tipos de proyecto. Por ejemplo, los componentes de un sistema estn mucho ms interrelacionados que los componentes de una obra civil. En un proyecto 21

de construccin, las decisiones de diseo que se tomen sobre un componente, normalmente, no afectarn a toda la obra como conjunto; sin embargo, en el desarrollo de sistemas es normal que un pequeo cambio impacte todo un sistema. En el desarrollo de sistemas, cada decisin de diseo que se toma debe ser sopesada en relacin con todo el sistema, pues cada componente que se construye puede afectar y, a la vez ser afectado, por cualquiera de los restantes componentes. En el desarrollo de sistemas se mezcla el trabajo de investigacin, con el trabajo de creacin (diseo) y con el trabajo de desarrollo de los componentes (programas, procedimientos, especificaciones, manuales) que integran el sistema. En un proyecto de construccin civil, si bien existe la mezcla investigacin-diseo-desarrollo, existe una lnea divisoria perfectamente marcada entre el diseo y la construccin; lnea divisoria que, en sistemas, no existe, pues el desarrollo de cada componente combina tareas de diseo y construccin. Otra caracterstica distintiva de los proyectos de desarrollo de sistemas, como ya hemos discutido, es la forma particular como transcurre ciclo de desarrollo de sistemas de informacin: Planificacin de Tecnologa de Informacin; Anlisis y Diseo General; Diseo Detallado y Construccin; Pruebas e Implantacin y Produccin/Mantenimiento. Al inicio del ciclo se conocen pocos detalles acerca de los sistemas que requiere el rea del negocio estudiada; sin embargo, una vez concluida la fase de Planificacin de TI se dispone de una visin ms clara de los sistemas requeridos y de la complejidad de los mismos. La fase de Planificacin de TI permite realizar un primer acercamiento a los proyectos que debern ser ejecutados para construir los sistemas requeridos por un rea de la empresa. Ese primer acercamiento da una visin muy general y no incluye la suficiente informacin detallada que permita cuantificar en forma precisa los recursos necesarios y la duracin exacta de los proyectos. Sin embargo, ese conocimiento general, normalmente, ser lo suficientemente bueno como para preparar unos estimados iniciales, sobre los que pueda formularse un plan de sistemas de precisin razonable (entre un 50 % y un 100 % de error). Una vez aprobado el plan de sistemas, se comenzar a ejecutar cada uno los proyectos de acuerdo al plan. Cada proyecto comenzar por la fase de Anlisis y Diseo General, durante la cual se analizar y disear con 22

mayor detalle el sistema requerido por el negocio (es decir, se dispondr de informacin ms precisa), por lo que, al finalizar esa fase, podr formularse un plan ms exacto para las siguientes fases. El Plan de Desarrollo e Implantacin del sistema, formulado al concluir la fase de Anlisis y Diseo General, incluir mejores estimados que los realizados en la fase anterior. Sin embargo, an despus de concluir el diseo general no se conocern todos los detalles de cada uno de los programas y componentes a desarrollar, por lo que el Plan de Desarrollo e Implantacin, si bien incluir un margen de error menor, an no incluir estimados 100 % exactos. Una vez que se concluyen las tareas de la fase de Diseo Detallado y Construccin, se conocer en mucho mayor detalle todos los componentes del sistema y resultar, por lo tanto, mucho ms fcil planificar la siguiente fase (Pruebas). Sin embargo, existen factores imponderables (como la calidad de los datos a convertir y la cantidad de errores de diseo o construccin que puedan haberse cometido) que impiden que, an al trmino de la fase de Construccin, los estimados sean 100 % exactos. En resumen, podemos decir que el proceso de planificacin de proyectos de desarrollo de sistemas se cumple con caractersticas muy particulares: No existe un nico plan, sino un conjunto de planes que conforman una jerarqua. Esta jerarqua est encabezada por el plan de sistemas y contina con los planes de cada sistema, de cada fase, de cada versin, de cada grupo y de cada individuo o problema particular. Al comenzar un proyecto existe una planificacin inicial para ese proyecto, producida durante la fase de Planificacin de Sistemas. En ella se establecen tanto los lineamientos de desarrollo para todo el proyecto, como su calendario y los recursos disponibles. Antes de comenzar cada fase, se elabora un plan detallado para la fase y se identifican las diferencias que puedan existir en relacin a la planificacin inicial para el proyecto. Estas diferencias se reportarn y explicarn ante el comit de sistemas1, con el fin de que este organismo pueda determinar el impacto de las diferencias sobre todo el plan de sistemas y, a la luz de esos elementos, pueda autorizar la continuacin del proyecto (otorgndole recursos adicionales, si es necesario, o recomendando ajustes) o posponer la ejecucin del mismo.

23

5. Niveles de Planificacin
Para precisar un poco ms lo discutido en las secciones anteriores, podemos decir que la jerarqua de planes de desarrollo de sistemas est conformada por los siguientes niveles: Plan de Sistemas, Plan General de Desarrollo de un Sistema, Plan Detallado para una Fase, Plan para el Resto del Proyecto.

5.1. El Plan de Sistemas

El plan de sistemas, como ya hemos discutido, es un plan que engloba todos los proyectos que deben ser abordados para dotar de sistemas un rea especfica del negocio. En este plan se muestran todos los planes para cada uno de los proyectos. Un plan de sistemas sufre revisiones frecuentes. A medida que los proyectos comienzan a ejecutarse, los logros que vayan siendo obtenidos se contrastarn contra ese plan, con el fin de determinar si la ejecucin marcha de acuerdo a lo previsto o si es necesario modificar las premisas sobre las cuales se elabor el plan de sistemas. Tambin, cuando ocurra algn cambio significativo o algn otro evento importante que afecte los costos o la fecha de terminacin, ser necesario hacer tales revisiones y actualizaciones del plan de sistemas.

5.2. El Plan General de Desarrollo de un Sistema

El plan general de desarrollo de un sistema es aquella parte del plan de sistemas que corresponde a ese sistema. En l se muestran los planes para las fases que habrn de ser cumplidas para llevarlo a trmino. El plan general de desarrollo tambin puede sufrir ajustes o modificaciones durante su ejecucin. Una vez que el proyecto se inicia, al finalizar cada fase, ser revisado en relacin a los logros obtenidos, con el fin de determinar los ajustes necesarios. Al igual que el plan de sistemas, cuando ocurra algn cambio significativo o algn evento importante que afecte los costos o la fecha de terminacin, tambin se revisar el plan general de desarrollo.

5.3. El Plan Detallado para una Fase

El plan detallado de una fase es la materia prima fundamental para dirigir y controlar los proyectos, pues en l se presentan todas las actividades que se cumplirn en la misma, as como las fechas estimadas de inicio y terminacin. En el plan detallado de una fase, se indica en detalle: qu deber ser hecho (productos), cmo deber ser hecho (actividades), quines debern hacerlo

24

(recursos, responsabilidades y asignaciones) y cundo deber ser hecho (fechas).

5.4. El Plan para el Resto del Proyecto

Tal como arriba mencionramos, al presentar el plan detallado de una fase, se deber incluir la proyeccin hasta el final del proyecto o, como muchos lo denominan, plan para el resto del proyecto. Junto al detalle de productos, actividades, responsabilidades y fechas de la fase, debe presentarse el ajuste del plan general de desarrollo con el estimado global para las siguientes fases del proyecto.

(Notas) 1 El Comit de Sistemas, como se detalla en el Captulo III, est integrado por los ejecutivos ms importantes del rea y de TI.

25

26