DEPARTAMENTO DE INFORMTICA UNIVERSIDAD TCNICA FEDERICO SANTA MARA

EL ESTUDIO PRELIMINAR EN EL DESARROLLO DE SISTEMAS INFORMTICOS.

RICARDO ACEVEDO ALMONACID

EL ESTUDIO PRELIMINAR El desarrollo de sistemas informticos, en la mayora de las propuestas metodolgicas, sugiere 9 actividades. En el contexto de estas actividades y segn muestra la figura 1.1, aparecen tres orgenes y destinos: la comunidad de Usuarios, la Gerencia y la Unidad de operaciones.

USUA RIOS
Requerimientos de_usuario Descripcin_ operar_actual

GERENCIA

OPERA CIONES
Base_de_datos existente

Restricciones

Restricciones Operacionales

1.
Estudio preliminar
Informe_tentativo de_costo/ beneficio

Estudio Preliminar

2.
A nlisis

3.
Diseo

Especificacin de_diseo

8.
Conversin de_bases de_datos

Restricciones

Informe costo/ beneficio Especificacin_de Requerimientos Especificacin de_diseo

GERENCIA

7.
Descripcin de_procedimientos

Base_de_datos convertida

4.
Implantacin

5.
Generacin de_prueba_de aceptacin
Conjunto de pruebas de control de calidad Manual_de usuario

Sistema integrado

9.
Instalacin
Sistema aceptado

6.
Control_de calidad

Sistema instalado

Figura1.1: El desarrollo de sistemas. La comunidad de Usuarios corresponde a todos aquellos que se desenvuelven al interior del proceso objeto de tratamiento informtico, sean estos los que tienen la responsabilidad de alcanzar los objetivos que la organizacin ha encomendado al proceso o quienes llevan el peso de tareas operativas cotidianas. Por Gerencia, para estos propsitos, debe entenderse a todas las instancias de direccin que se vinculan directamente con el proceso de desarrollo de sistemas
2

informticos. En particular incluye a los directivos de nivel superior, es decir, a la Gerencia general y a todas las Gerencias que dependen directamente de ella; a los directivos de las unidades de informtica, esto es, a los administradores de nivel superior y a los que se siguen en jerarqua, incluyendo a los jefes de proyectos y, en tercer lugar, a los directivos de las unidades organizacionales para las cules deben desarrollarse los sistemas, es decir a los administradores de nivel superior y medio que esperan de los sistemas a desarrollar ciertos resultados especficos. La Unidad de operaciones corresponde especficamente al personal de operaciones responsable de los centros de procesamiento, de las redes de telecomunicaciones, de la seguridad del hardware y del software, de la ejecucin de los programas, del manejo de los discos e impresoras, etc. Cabe consignar que aunque en muchos casos los Usuarios normalmentes disponen de sus propios equipos, no es inusual que deban conectarse a una mquina central, como para, por ejemplo, bajar de una base de datos, aquellos que el operar de un sistema precisa en un momento dado. No es inusual tampoco que los PCs se comuniquen entre s a travs de una red local, caso en los cules el personal de operaciones tiene normalmente algo que decir. Es precisamente con estas tres instancias externas con las cules las diferentes actividades por las que debe pasar el desarrollo del proyecto se vinculan directamente adems, por cierto, de todas las otras relaciones que se establecen entre ellas. El anlisis de cada una de estas actividades sus relaciones permitir obtener una visin detallada de lo que significa y de los alcances que tiene el desarrollo de un proyecto informtico. El Estudio preliminar. El Estudio preliminar tiene como propsito, una vez identificado el sistema o proceso que se debe someter a tratamiento informtico, reconocer los problemas y desajustes organizacionales que manifiesta en su modo de operar actual, dejando explcitamente de manifiesto las reconfiguraciones que precisa para que se ajuste a los cambios en su misin y a los nuevos objetivos de performance que la superacin de aquellos problemas y desajustes necesitan. Persigue tambin, pronunciarse acerca de si se justifica someter el sistema a desarrollo informtico, para lo cual sugiere establecer varias opciones posibles -o escenarios- y evaluarlas tcnica, legal, operacional y econmicamente. La figura 1.1 muestra como unidad simple este estudio, en cuanto primera fase de todo proyecto de desarrollo informtico.

USUARIOS
Requerimientos de_usuario Descripcin_ operar_actual

GERENCIA

OPERACIONES
Base_de_datos existente

Restricciones

Restricciones Operacionales

1.
Estudio preliminar
Informe_tentativo de_costo/ beneficio

Estudio Prelimina r

Especificacin_de Requerimientos

2.
Anlisis

3.
Diseo

Especificacin de_diseo

8.
Conversin de_bases de_datos

Restricciones

Informe costo/ beneficio

GERENCIA

Especificacin_de Requerimientos

Especificacin de_diseo

7.
Descripcin de_procedimientos

Base_de_datos convertida

4.
Implantacin

5.
Generacin de_prueba_de aceptacin
Conjunto de pruebas de control de calidad Manual_de usuario

Sistema integrado

9.
Instalacin
Sistema aceptado

6.
Control_de calidad

Sistema instalado

Figura 1.2: Estudio preliminar como unidad simple En la figura 1.2, es posible apreciar que las dos instancias organizacionales con las cuales, en cuanto actividad, se vincula son: Usuarios y Gerencia. Muestra tambin que la fase de desarrollo con la cual se relaciona directamente es la fase de Anlisis. La figura 1.3, por su parte, muestra el Estudio preliminar como una unidad compuesta. En ella es posible apreciar cuatro tareas secuencialmente vinculadas. Estas son: Identificar las actuales deficiencias; Establecer los objetivos de la nueva propuesta para el proceso; Generar escenarios plausibles para la nueva propuesta y Elaborar las directrices del proyecto.

USUARIOS

requerimientos_ sistema descripcin_ operar_actual

nuevos_objetivos

1.2 Establecer_ nuevos_ objetivos

deficiencias_ de_proceso

1.5 Elaborar_ directrices_ del_proyecto

directrices_ proyecto

1.1 Identificar_ actuales_ deficiencias

Escenarios_ plausibles

Informe_tentativo costo/beneficio

1.4 Generar_ escenarios_ plausibles

restricciones

GERENCIA

Figura 1.3: Las tareas del Estudio preliminar. Las tareas del Estudio preliminar. 1.- Identificar actuales deficiencias. Se puede sostener que el origen de todo desarrollo de sistemas informticos est en el reconocimiento por parte de quienes se desenvuelven al interior de un proceso organizacional, de la existencia de ciertos problemas tales como ineficiencia, ineficacia, necesidad de ajustar las tareas a nuevas exigencias que la organizacin impone, etc. As, entonces, una vez identificado el proceso objeto de tratamiento informtico, el primer paso tendiente a dejar de manifiesto las deficiencias, no puede ser otro que conversar con los miembros claves de la comunidad de personas que tiene como misin llevar a cabo las tareas al interior del proceso, precisamente para que ello sea posible. De gran ayuda, cabe sealar, resulta el contextualizar las deficiencias identificadas para lo cual lo que se debe hacer es simplemente identificar al proceso como componente o parte del todo orgnico del que forma parte. Una manera de hacerlo es explicitar tanto lo que se puede denominar su contexto global como su contexto local. El contexto global corresponde a aquel en el cul el proceso se desenvuelve, vale decir, la propia Organizacin y su entorno. Ello no es otra cosa que especificar los rasgos ms distintivos de la Organizacin, en funcin, obviamente, de su relevancia para el desarrollo de un proyecto informtico.
5

El contexto local, por su parte, lo que deja explcitamente de manifiesto es el proceso y su entorno inmediato, o sea sus entradas y salidas y los procesos con los cuales se relaciona directamente tanto por la entrada como por la salida, tal como lo muestra la figura 1.4.

PRE1

fde1

P fde2

fds1

PRS1

PRE2

Figura 1.4 : El Contexto Local

PRE1 = Proceso de Entrada 1. PRE2 = Proceso de Entrada 2. PRS1 = Proceso de Salida 1. P = Proceso. fde1 = Flujo de datos de entrada 1. fde2 = Flujo de datos de entrada 2. fds1 = Flujo de datos de salida 1. Al definir las entradas y salidas lo que se especifica son los flujos de datos a travs de los cuales el proceso interacta con los otros procesos con los cules se vincula. Estos son aquellos que determinan el universo que influye explcitamente sobre l, pero que no estn bajo el mbito de estudio del proyecto especfico considerado. Como lo muestra la figura 1.3, esta primera tarea del Estudio preliminar, Identificar las deficiencias, se lleva a cabo a partir de los requerimientos del sistema y de la descripcin de su operar actual. En ella interesa percibir principalmente 2 tipos de falencias: las falencias de misin y las falencias de misin. Las falencias de misin apuntan a la necesidad de reconfigurar la trama de subprocesos en virtud de los cules el sistema lleva a cabo sus tareas, reconfiguracin que normalmente apunta a la creacin de algunos nuevos subprocesos o a la eliminacin o modificacin de otros, situacin que de ocurrir, habitualmente se presenta cuando la organizacin ha estimado conveniente la redefinicin de la misin encomendada al proceso objeto de estudio.
6

Las falencias de performance se refieren a las deficiencias de rendimiento que la comunidad de usuarios estima se requieren para conformar una nueva versin del proceso. Es posible que la informacin susceptible de obtener de la descripcin del operar actual se encuentre disponible ya escrita en algn documento existente en la unidad organizacional responsable del proceso. Pero tambin puede no existir o estar simplemente desactualizada. Por lo tanto, de ocurrir esto ltimo, para poder efectivamente identificar las deficiencias del proceso no queda otro camino que recabarla para que una vez obtenida sea posible, mediante un trabajo mancomunado con los usuarios, obtener la exacta dimensin de los problemas. Generalmente el documento final que da cuenta del trabajo realizado durante esta primera subactividad no es ms que un documento escrito al estilo narrativo que se puede denominar Deficiencias del proceso. En l se debe hacer referencia preferentemente a: subprocesos inexistentes, a subprocesos actuales que no son necesarios o que se llevan a cabo deficientemente, a costos elevados, a problemas de confiabilidad y exactitud, a problemas throughput/respuesta, es decir a problemas relacionados con cantidad de trabajo terminado por unidad de tiempo. Estos problemas deben presentarse en un orden tal que coloque en primer lugar aquellos asuntos que el usuario estima deben enfrentarse de manera prioritaria. Ejemplos de las declaraciones que puede contener el documento Deficiencias del proceso son: - El sistema en su versin actual no permite generar los nuevos informes que solicitan las entidades contraloras del estado. - El sistema en su versin actual se cae en promedio cada 72 horas. En sntesis, las falencias se ordenan alrededor de los dos tipos ya sealados: falencias de misin y falencias de performance. 2.- Establecer nuevos objetivos. Establecer a grandes lneas las nuevas perspectivas para el proceso es la segunda subactividad que contempla el Estudio preliminar. Se trata especficamente: - de establecer, de requerirse, la nueva configuracin del proceso, considerada como aquella que ha de responder a una eventual nueva misin que la organizacin le ha encomendado al sistema. - de puntualizar los nuevos objetivos de performance o criterios de desempeo, a los cules usuarios y Gerencia estiman debe responder el sistema. Estos nuevos objetivos deben hacer referencia: a los requerimientos throughput/respuesta, a las restricciones de costos y a los requerimientos de exactitud y confiabilidad. Ambos aspectos, se refieren, obviamente, a la redefinicin a que se somete la versin actual del sistema, la cual, por cierto, debe tener un correlato directo con lo especificado en la fase, Identificar deficiencias actuales. Cabe sealar que, por cierto, tanto la reconfiguracin del proceso como los nuevos objetivos de performance, deben tener una exacta correspondencia con aquellos
7

problemas que fueron explicitados durante la identificacin de las deficiencias del operar actual. Por ejemplo, si en el documento Deficiencias del proceso aparece una declaracin como el sistema en su versin actual se cae en promedio cada 72 horas, entre los objetivos de la nueva propuesta para el sistema debera aparecer una declaracin del tipo la nueva propuesta para el sistema debe contemplar un tiempo medio entre fallas de 500 horas. No es inusual que los nuevos objetivos que la comunidad de usuarios ha propuesto para la nueva versin del sistema objeto de tratamiento informtico afecten las fronteras que marcan el dominio en cuyo marco el sistema lleva a cabo actualmente sus actividades y en cuyo contexto se identificaron en la primera actividad las deficiencias del proceso. Ello sobre todo si los requerimientos del usuario contemplan ya sea la eliminacin de subprocesos fronterizos o bien el agregar otros conectados a algunos ya existentes ubicados en los bordes. Cabe agregar que an cuando para la nueva versin del sistema no se redefinan las fronteras del modo expuesto, no deja de ser un asunto al cual es conveniente prestar suficiente atencin, ello en gran medida porque las directrices del proyecto deben establecer el grado de libertad que se tendr durante el Anlisis para definir y especificar qu es aquello que el sistema har. As, es durante esta primera fase del desarrollo de un proyecto informtico cuando se debe establecer si, por ejemplo, al desarrollar una nueva propuesta para el proceso contable de una empresa se incluye o no el proceso de determinacin de costos, con el cual aquel se encuentra altamente cohesionado. Debido a la importancia que stos aspectos tienen en cuanto a perfilar el panorama de desarrollo que se viene por delante, es que se sugiere consignarlos en este momento del Estudio preliminar, ya sea, de ser posible, reconfigurando el diagrama que da cuenta del contexto local de la versin actual o bien simplemente presentando narrativamente la nueva dimensin que adquiere el proceso producto de los cambios deseados. Es bien cierto que muchas veces un problema que se manifiesta en una determinada rea de una organizacin no es ms que el sntoma de un problema cuyas causas residen en otra. Sin embargo, obviamente tratando de incluir las causas ltimas de los problemas podra llegarse al extremo de tener que considerar en su totalidad los procesos organizacionales que configuran el segundo estrato de la empresa vista como un todo. No cabe duda que un proyecto de desarrollo de tal envergadura no ser del agrado de la Gerencia por su alta complejidad, por el excesivo tiempo que habra de requerir y por los altos costos involucrados. En realidad lo aconsejable es procurar que el nuevo sistema a configurar no impacte algn rea organizacional que est fuera de su mbito de accin. Es difcil sugerir un mtodo formal para establecer aquel dominio de modo tal que sea a la vez suficientemente amplio y no excesivamente extenso. Con toda seguridad no existe otra opcin que recurrir a la experiencia. Es pertinente destacar que el contexto de la nueva propuesta para el sistema es uno de los aspectos que debe recoger el documento Directrices del proyecto.

Por ltimo cabe indicar que para preparar el documento final de esta subactividad denominado Nuevas perspectivas, se necesita contar, como lo muestra la figura 1.2, con los Requerimientos del sistema y con las Deficiencias del proceso. Se trata de un documento que presenta para el proceso objeto de tratamiento informtico tanto su nueva configuracin de subprocesos como sus nuevos objetivos de performance. 3.- Generar escenarios plausibles. El propsito de esta tercera subactividad es perfilar, tambin a grandes lneas, algunas -las ms relevantes- de las opciones que podran satisfacer la nueva propuesta para el proceso. Los documentos que sirven como base para determinar aquellos escenarios, como lo presenta la figura 1.3, son Las deficiencias del proceso, Las nuevas perspectivas y las Restricciones de Gerencia. Por el lado de las entradas a esta actividad, el documento que recoge las nuevas perspectivas es el mismo que emana de la actividad anterior y que, como se seal, hace referencia a la necesidad de reformular algunos subprocesos, a la necesidad de incorporar otros, a los requerimientos relativos a cantidad de trabajo terminado por unidad de tiempo, a las restricciones de costos y a los requerimientos de exactitud y confiabilidad. Las deficiencias del proceso, por su parte, estn contenidas en el documento que emana de la primera subactividad, Identificar las actuales deficiencias, el cual se hace referencia a subprocesos inexistentes, a subprocesos actuales que se llevan a cabo deficientemente, a costos elevados, a problemas de confiabilidad y exactitud, a problemas relativos a la cantidad de trabajo terminado por unidad de tiempo o thruoghput/respuesta, presentados en orden de prioridad. Las Restricciones de Gerencia, en tanto, hacen referencia a limitaciones presupuestarias, a otras relativas a la adquisicin de hardware; a restricciones de tiempo; de recursos humanos, as como tambin a algunas limitaciones asociadas al entorno en que ha de operar cotidianamente la nueva propuesta, como las restricciones de espacio fsico, por ejemplo. Se trata de restricciones que se caracterizan por afectar a cualquiera sea la opcin que se configure para el logro de los nuevos objetivos para el sistema. El significado de las restricciones es bastante claro. El analista necesita conocer cul es el monto de los recursos monetarios disponibles para el proyecto, de cunto tiempo dispone, cul es el personal asignado y si puede adquirir nuevo hardware. Sin embargo, no en pocas ocasiones el equipo de desarrollo debe enfrentar algunos problemas adicionales en relacin a las restricciones que la Gerencia impone. Lo que ocurre es que muchas veces estas imposiciones son slo preliminares y solo cuando tiene a mano los distintos escenarios, con sus costos y beneficios estimados, entregan un conjunto ms definitivo de restricciones. An ms, generalmente estas redefiniciones de las restricciones se constituyen en un input para la fase de Anlisis. Hay otro aspecto al que, respecto de las restricciones, es preciso prestar atencin. En un mundo ideal las restricciones de Gerencia no tienen porqu afectar el proceso a travs del cual el analista establece sus programas, presupuestos, sus necesidades de recursos humanos y, en general, todas sus estimaciones. Las restricciones de Gerencia representan los lmites dentro de los cuales las estimaciones del analista encajan sin problemas. Pero en el mundo real ello por cierto no es lo que acontece.
9

Ellas constituyen ms bien la base para iniciar una serie de reuniones cuyo resultado no es otro que programas, presupuestos y estimaciones negociados. Considerando, en consecuencia, las nuevas perspectivas que se espera permitan superar las deficiencias del proceso y todas las restricciones que lo afectan, se prepara el documento final de esta tercera subactividad, un documento denominado Escenarios plausibles. En l se hace referencia a las diferentes opciones vistas desde la perspectiva del uso de las Tecnologas de informacin que pueden satisfacer las nuevas perspectivas para el proceso. stas se presentan en trminos de un breve resumen de la propuesta, acompaado, de ser posible y eficiente hacerlo, de un Diagrama de flujo de datos -un instrumento de representacin que a modo de grafo da cuenta de las diferentes transformaciones, realizadas por subprocesos, que al interior del sistema sufren los flujos de datos que ste recibe por la entrada para, a la postre, generar los flujos de datos que debe entregar por la salida- que recoja la nueva dimensin del sistema, de una relacin costo/beneficio que proporcione una indicacin acerca de su factibilidad econmica y de un pronunciamiento acerca de su factibilidad tanto tcnica como legal y operacional. Estudio de Factibilidad. Todos los proyectos son factibles de realizar teniendo recursos ilimitados y tiempo infinito. Como ste generalmente no es el caso, el desarrollo de cualquier sistema informtico est sujeto a restricciones. Entre ellas la disponibilidad de recursos financieros es una limitante significativa, la que a su vez trae como consecuencia, muchas veces, la imposibilidad de contar con las Tecnologas de informacin que la solucin al problema requiere. La capacidad operacional que existe en la Organizacin y los recursos tecnolgicos requeridos para la generacin de informacin y el procesamiento de datos, son tambin un factor de limitancia que es preciso considerar. Los proyectos de desarrollo de sistemas, sern exitosos slo si permiten que el proceso organizacional objeto de tratamiento informtico obtenga mejoras que se traduzcan directamente o indirectamente en beneficios significativos. De esta manera, si se considera que un sistema provee de la informacin necesaria para aumentar la eficacia de la toma de decisiones que requieren las instancias de regulacin de los procesos, si facilita la incorporacin de caractersticas deseables a los productos de su actividad si permite brindar mejores servicios a los clientes, si incrementa la participacin en el mercado, o incluso si disminuye costos y gastos administrativos, entonces ese sistema s se justifica. Tales bondades, sin embargo, deben demostrarse y el modo de hacerlo es sometiendo cada uno de los escenarios plausibles identificados a un Estudio de factibilidad. Este estudio consiste en estimar las inversiones requeridas y los beneficios y costos derivados de su posterior puesta en marcha, en establecer si con el nivel tecnolgico con que puede contar la organizacin, las soluciones sugeridas adems de implementables pueden operar normalmente bajo la plataforma tecnolgica disponible, en determinar la capacidad que existe en la Organizacin para llevar adelante la propuesta y en verificar si la solucin no escapa a las disposiciones legales existentes. En otras palabras, lo que se debe hacer es evaluar cada escenario con respecto a su factibilidad econmica, tcnica, legal y operacional. Cabe destacar que llevar adelante un exhaustivo estudio de este tipo slo se justifica en proyectos de gran envergadura financiera y tecnolgica, porque en rigor llevar a cabo un
10

estudio de factibilidad acabado exige realizar una suerte de pre-anlisis, el cual aunque se exprese en trminos globales, debe ser tal que proporciona todos los elementos necesarios para llevarlo a cabo. Y ello, por cierto, requiere de tiempo y recursos. Por otro lado, llevar adelante un completo Estudio de factibilidad para sistemas pequeos y triviales en realidad no se justifica si se considera lo que normalmente son factibles. Cabe consignar, adems, que el desarrollo de un Estudio de factibilidad generalmente se lleva a cabo en un ambiente organizacional no totalmente propicio, pues existen varios factores que entorpecen las actividades que comprende, tales como las presiones de los usuarios por sobrevalorar los parmetros que haran atractivo implementar el proyecto, el desconocimiento que ellos tienen con respecto a las tcnicas empleadas, las fallas producidas en las comunicaciones entre analistas y usuarios, debido entre otros factores, muchas veces, a la resistencia al cambio que muchos usuarios manifiestan. El Estudio de factibilidad es de carcter tcnico y una vez que ha concluido se debe agregar al documento Escenarios plausibles que emana de la tercera subactividad del Estudio preliminar. En particular, para cada escenario, puede sugerir, por ejemplo: - Aceptar la solucin que lleva asociado como factible en todas las dimensiones que contempla el Estudio de factibilidad. - Continuar estudiando con ms detalle alguna parte de la propuesta - Sugerir cambios en las restricciones o presupuestos entregados al iniciarse el proyecto. - Que la solucin asociada al escenario no es factible. Factibilidad Tcnica. Probar la factibilidad tcnica consiste en determinar, para cada escenario, si la solucin que trae consigo es susceptible de llevar a cabo con los recursos computacionales y de comunicaciones -incluyendo los conocimientos tcnicos respectivos- disponibles en la organizacin. Ms especficamente, consiste en: - el observar si se contar con los recursos de hardware y software necesarios para desarrollar y en particular para implementar el sistema. - el observar la competencia de los recursos humanos disponibles para llevar adelante el desarrollo de los sistemas asociados a cada escenario. - establecer si el sistema puede ser desarrollado de forma tal que los subprocesos necesarios puedan cumplir su rol con las restricciones existentes. Probar la Factibilidad tcnica obviamente tambin comprende verificar si para cada escenario, el sistema que tiene asociado, una vez implementado, es posible de instalar y hacer que opere efectivamente en el ambiente Hard/software disponible -o con aquel con el cual se pudiese contar- para ello en la organizacin.
11

Factibilidad Operacional. Probar la factibilidad operacional tiene como objetivo determinar si es posible que los sistemas asociados a cada escenario operen efectivamente una vez instalados dado el ambiente organizacional existente. Consiste en determinar la capacidad potencial de la Organizacin para llevar a cabo el proyecto en trminos de los planes, polticas y procedimientos vigentes, es decir se trata de averiguar a qu se expone la Organizacin al incorporar un nuevo sistema, cual ser la reaccin que suscitar en los dems procesos, en los recursos humanos y en general en toda la Organizacin, considerando incluso los clientes. No pocas veces ocurre que un producto de software de excelente factura tcnica no es utilizado por aquellos que lo han requerido. Un aspecto de vital importancia, dentro de las consideraciones relativas a la incorporacin de un sistema informtico a una estructura organizacional ya existente, es observar su impacto global, de lo contrario el resultado puede ser un fracaso. Ello no es otra cosa que prestar atencin a aquellos aspectos relacionados con los efectos que provoca la solucin a un problema especfico que se presenta en un cierto dominio organizacional sobre el resto de las reas. Dentro de cualquier Organizacin, obviamente el factor ms relevante es el recurso humano, imprescindible para alcanzar los resultados deseados. Tomando en cuenta la naturaleza del ser humano, la forma ms adecuada de incorporar cambios, sean stos tecnolgicos o de procedimientos, es hacerlo a travs de un proceso evolutivo; esto significa que no es aconsejable que una Organizacin queme etapas, pasando en un corto perodo de tiempo, por ejemplo, desde mtodos manuales rudimentarios a un uso sofisticado de computadores. Por el contrario, debe avanzarse paso a paso, empezando con las aplicaciones simples sin mayores requerimientos. Esto debe complementarse con un perodo paralelo de entrenamiento, que se constituya el medio ambiente adecuado para avanzar hacia un uso ms sofisticado de las tecnologas de informacin. El impacto que la incorporacin de un sistema informtico produce en la organizacin, est determinado por ciertas situaciones que normalmente trae esa incorporacin. Entre ellas cabe destacar: - La mejora a un problema especfico, no siempre trae aparejado una mejora global. - Resolver un problema en un rea, mediante el uso de tecnologas de informacin, a veces provoca en otra un problema semejante al resuelto originalmente. - Para algunos clientes, el trato humano no puede ser sustituido, ya que muchos sistemas totalmente automatizados no entregan tratos preferenciales, ni consideraciones especiales que para ellos son significativos. -Un subproceso sustentado significativamente en software, puede necesitar demasiado tiempo para responder ante requerimientos inusuales, en los cules normalmente es el criterio personal el que determina. - El personal que opera con sistemas automatizados, puede perder la motivacin, debido al tedio que en eventualmente se pudiese producir por lo rutinario y poco creativo de algunos sistemas.
12

Factibilidad Legal. El estudio de la factibilidad legal tiene como objetivo verificar, para cada escenario, si el sistema a desarrollar no vulnera las leyes vigentes o la reglamentacin propia de la organizacin. Es decir pretende observar si no incurre en infracciones, violaciones u otros que podran provocar la imposibilidad de poner en ejecucin el sistema, o su interrupcin en algn momento de su operacin rutinaria. Factibilidad Econmica. El estudio de la factibilidad econmica tiene como objetivo determinar si se justifica, en trminos de una relacin costo/beneficio, llevar adelante la solucin asociada a cada escenario. Para llevar a cabo la factibilidad econmica, es preciso, en primer lugar, determinar la inversin requerida, los beneficios y los costos asociados al sistema en un horizonte de tiempo preestablecido, considerando la vida til del proyecto para, luego, evaluarlo a objeto de determinar su rentabilidad. Los datos con los cules se necesita contar para realizar el estudio de la Factibilidad econmica, o estudio costo/beneficios, como tambin se le denomina, son aquellos referidos a la inversin, los costos y beneficios que cada escenario lleva asociados. La inversin se relaciona con todos aquellos desembolsos en que es preciso incurrir para la incorporacin del sistema a la organizacin. Es decir, todos aquello generados durante su desarrollo y antes de su puesta en operacin rutinaria. Puede incluir algunos de los siguientes: - Desembolsos relativos al desarrollo del sistema. - Desembolsos ligados a consultoras. - Desembolsos relativos a adquisicin e instalacin de equipos. - Desembolsos relacionados con la modificacin del ambiente necesario para el equipamiento (alajamiento, aire acondicionado, seguridad, etc.). - Desembolsos derivados de la adquisicin de software. - Desembolsos correspondientes a la instalacin de equipos de comunicacin (lneas de telfono, lneas de datos, etc.). - Desembolsos asociados a la bsqueda y contratacin de personal. - Desembolsos relativos a modificacin de software para ambiente apropiados. - Desembolsos a incurrir para preparar documentacin. - Desembolsos ligados a la administracin del proceso de desarrollo. Los beneficios y los costos se refieren aquellos ingresos y egresos que se espera se generen durante la operacin rutinaria del sistema. Entre los beneficios que puede generar un sistema informtico se puede mencionar:
13

- Beneficios derivados de la disminucin de horas/hombre. - Beneficios derivados de menores tasas de errores. - Beneficios derivados de mayores facilidades para recuperar y almacenar datos. - Beneficios derivados del aumento en la capacidad de almacenamiento. - Beneficios derivados de la mayor seguridad en el almacenamiento. - Beneficios derivados de los nuevos clientes atendidos como consecuencia de la mayor y mejor capacidad operativa. - Beneficios derivados del disponer de mejor y ms oportuna informacin para la toma de decisiones. En general, ser beneficio todo que signifique ahorro de costos. Entre los principales tems de costos cabe destacar: - Costo de operacin de sistema. - Costos de mantencin del sistema. - Costos de alquiler (electricidad, telfonos, etc.). - Costos de depreciacin del hardware. - Costos de capital. Cabe agregar que normalmente se dan dos tipos de valorizaciones para costos y beneficios, los cules dependen de si existe o no la posibilidad de cuantificarlos concretamente. Si la posibilidad no existe, este proceso es subjetivo y depende del sistema en cuestin, constituyndose por esto en una de las actividades ms difciles de llevar a cabo. Es conveniente destacar que en relacin al anlisis costo/beneficio pueden darse diversas situaciones en torno a la relacin que existe entre el incremento de costo y el beneficio generado (procesos ms ajustados a los propsitos de la organizacin y mejor performance). Esta relacin costo/beneficio puede ser representada como se muestra en la figura 1.5.

14

Beneficio

curva 2 curva 1

Costo

Figura 1.5 : Relacin Costo / Beneficio

En algunos casos el costo (curva 1) aumenta proporcionalmente con los beneficios hasta algn punto A. Despus de este punto, cada beneficio adicional es excesivamente caro. El costo marginal aumenta por lo tanto significativamente. En otros casos el costo (curva 2) aumenta proporcionalmente hasta A y luego se mantiene casi constante para nuevos beneficios (Hasta B) y finalmente aumenta dramticamente para los siguientes beneficios. Determinacin de la factibilidad econmica. Con los valores de costos, beneficios e inversiones ya estimados para cada escenario, es posible llevar a cabo los anlisis econmicos correspondientes. Para este propsito existe una serie de herramientas, equivalentes a diferentes mtodos de evaluacin de proyectos de inversin, los cuales en general consisten en comparar de alguna forma el flujo de ingresos con el flujo de desembolsos del proyecto. De stos mtodos los ms utilizados son Valor Actual Neto (VAN), Tasa Interna de Retorno (TIR) y Pay back o periodo de recupero. 1.- Valor Actual Neto. Todo proyecto, visto en perspectiva financiera se puede expresar en trminos de un flujo de fondos positivos (ingresos) y de un flujo de fondos negativos (egresos). Los valores que conforman aquellos flujos obviamente se producen en diferentes momentos en el tiempo, lo cual hace que no sea correcto compararlos directamente, pues una unidad monetaria de hoy no posee el mismo valor de una unidad monetaria de, por ejemplo, 3 aos ms. Para comparar el dinero disponible en distintos momentos en el tiempo se utiliza la Tasa de Descuento. As, sumas de dinero correspondientes a diferentes momentos pueden hacerse equivalentes en valor econmico, cuando se les aplica aquella tasa.

15

Supngase que se cuenta con una tasa de descuento de un 15% para un ao, y se espera disponer de un flujo futuro de $1000 para dentro de un ao. En este caso, si se desea saber cunto (X) se debe entregar hoy en efectivo -asumiendo por cierto que se le invierte al 15%- para que se convierta, al cabo de un ao en los $1000 ya sealados, lo que se debe hacer es lo siguiente: X + 0.15X = 1000 X(1 + 0.15) = 1000 X = 1000/1.15 X = 869.56 Ms simple an, si hoy se cuenta con $1000, y la tasa de inters a la cual se puede invertir aquel monto es del 15%, al cabo de un ao se tendr: 1000 + 1000(0.15) o 1000(1 + 0.15); es decir, $1150 Ahora, para el mismo ejemplo, si dentro de un ao se espera tener $1150, y considerando la misma tasa de inters -tasa de descuento- del 15%, hoy, un ao antes, obviamente se tendr: 1150/(1 + 0.15); es decir, $1000. Habida, entonces la consideracin expuesta referente al valor del dinero en el tiempo, si se designa como Rt al ingreso neto -ingresos menos desembolsos- positivo o negativo que se obtiene al perodo t y como i a la tasa de descuento, y si consecuentemente se denomina Ro a cierta inversin inicial, entonces el valor actual neto hoy (ao 0) de un flujo de ingreso netos que se producir durante n perodos consecutivos ser: VAN = Ro + (R1/(1+i)) + (R2/ (1+i)^2) + .............+ (Rn/(1+i)^n) donde: Ro = Inversin inicial Rt = Flujo neto por perodo. Es decir: VAN = Rt/ (1+i)^t; t= 0,....,n. Es fcilmente constatable que si los flujos netos del proyecto se distribuyen a travs de una lnea de tiempo, calcular el VAN no es otra cosa que expresar estos flujos netos en unidades monetarias del momento to. De este modo, si Pi corresponde al valor presente de cada uno de los ingresos Ri, entonces dada la taza de inters i por unidad de tiempo se tiene: Ro = Po R1 = P1 + P1*i = P1(1+i) R2 = P2(1+i) + P2(1+i)*i = P2(1+i)(1+i) = P2(1+i)^2
16

R3 = P3(1+i)^2 + P3(1+i)^2*i = P3(1+i)^2 (1+I) = P3(1+i)^3 * * * Rn = Pn(1+i)^n-1 + Pn(1+i)^n-1*i = Pn(1+i)^n-1(1+i) = Pn(1+i)^n Luego, el valor actual neto ser simplemente la suma de todos los valores presentes, es decir: VAN = P0 + P1 + P2 + P3 + . . . . + Pn VAN = Ro + (R1/(1+i)) + (R2/ (1+i)^2) +............+ (Rn/(1+i)^n) Para todos los proyectos que se deseen comparar, el valor actual neto de cada uno de ellos debe ser calculado para un mismo momento en el tiempo. Por lo tanto, aunque los proyectos a cotejar tengan distinta duracin o su construccin comience en momentos diferentes, siempre se debe actualizar el flujo de ingresos netos de esos proyectos a un momento comn. No est dems resaltar que el mtodo del valor actual neto toma en cuenta la forma como el flujo de ingresos y egresos del proyecto se distribuye a travs del tiempo. Obtener para un proyecto un VAN positivo significa que es conveniente realizarlo. Por el contrario, de un VAN negativo se deduce la conveniencia de su rechazo. Esto significa que un proyecto ser aceptable si el valor actual de sus ingresos supera el valor actual de sus egresos. Consecuentemente, al comparar proyectos que son mutuamente excluyentes se debe elegir aquel con mayor VAN, siempre y cuando ste sea positivo. Un asunto que respecto de este mtodo resulta de particular importancia dejar de manifiesto tiene que ver con la exigencia de contar con la tasa de descuento, que es un dato externo al proyecto, pues diferentes tasas producirn diferentes resultados. Resulta aclarador precisar que la tasa de descuento corresponde al precio de las diversas fuentes de financiamiento (fondos propios o ajenos) que se conoce en trminos conceptuales como la tasa de costo capital. ii) Tasa Interna de Retorno (TIR) Se llama tasa interna de retorno a aquella tasa de actualizacin que hace el valor actual neto de un proyecto igual a cero, es decir, se trata de aquella tasa que iguala el valor actual de los egresos previstos con el valor actual de los ingresos previstos tal como lo muestra la relacin:

R0 = (Rt / (1+TIR)t)
t=0

all, TIR es la tasa interna de retorno, la cual obviamente corresponde al resultado del clculo de la raz o races del polinomio conformado. Por ejemplo, si se tiene los dos flujos siguientes:
17

R0 = (R1/(1+TIR)) + (R2/(1+TIR)2) y si 1/(1+TIR) = V entonces: R0 = R1 V + R2 V2 0 = R1 V + R2 V2 - R0 La solucin para este polinomio entregar el o los resultados -TIR- que lo igualan a 0. Cabe destacar que si se trata de proyectos de diferente tamao en inversin inicial, el TIR indicar un orden de prioridad diferente al VAN. Para solucionar esta contradiccin se debe calcular el TIR marginal, procedimiento que permite obtener la misma prioridad que otorga el VAN. Por ejemplo, si se tienen las dos alternativas siguientes para un costo de capital del 10%: Proyecto A B R0 $32100 $200000 R1 $20000 $120000 R2 $20000 $12000 VAN $2611 16. $8264 13. TIR 01% 07%

Es constatable en el ejemplo que en base al TIR, el Proyecto A es ms deseable que el B, pues el TIR del primero es mayor que el segundo, esto es, para el costo de capital del 10%, aquel representa un mayor incremento de patrimonio. Sin embargo, en base al VAN, es el proyecto B el ms deseable, dado que para ste caso la tasa de costo de capital, 10%, proporciona un mayor incremento de patrimonio. Ello, sin dudas da cuenta de una contradiccin. Para resolverla se debe recurrir a lo que en Finanzas se denomina Anlisis marginal o incremental. Para tal efecto se debe calcular B-A en trminos de inversin inicial y flujos netos. En otras palabras, qu cantidad habra que invertir adicionalmente tomando como base A para poder realizar B y cules seran las diferencias en cuanto a flujos. De proceder as, lo que se tiene, entonces es: A + (B-A) = B En consecuencia, si se efecta la diferencia B-A, se obtienen los siguientes resultados: B-A R0 167900 R1 100000 R2 100000 TIR Mg 12.50%

18

Con estos datos se puede calcular la tasa de rentabilidad intrnseca de la inversin marginal, o sea el TIR Mg -TIR marginal- que es de un 12.50%, mayor que el costo de capital del 10%. Luego, al realizar la inversin marginal, en definitiva el proyecto B generar un incremento de patrimonio. De no hacerlo, se perdera ese incremento, incurriendo por tanto en ese costo de oportunidad. En sntesis, despus de utilizar el mtodo TIR con una ptica marginalista, se puede concluir que el VAN, en el ejemplo presentado haba dado una clara seal relacionada con la superioridad del proyecto B. Lo interesante de este mtodo, a pesar de las limitaciones que presenta cuando se debe comparar inversiones de tamao significativamente diferentes, o flujos negativos grandes en el horizonte de tiempo, es que permite comparar dos expresiones porcentuales -TIR y costo de capital- que son fciles de entender para quin no tiene un dominio acabado del instrumental disponible en Finanzas. Cabe por ltimo consignar que si la tasa del proyecto supera a la tasa de corte, que corresponde a la tasa de costo capital, se lo acepta; en caso contrario se lo rechaza. iii) PAY BACK o Perodo de Recupero El pay back o perodo de recupero se define como el perodo de tiempo que requiere un proyecto para recuperar el monto de su inversin inicial. Este perodo de tiempo se calcula segn la relacin: Monto de la Inversin Inicial PPB = -------------------------------------Flujo de Caja Anual Donde PPB es el perodo de PAY BACK en aos. Ambos trminos de la frmula estn expresados en base a flujo de caja, y es vlida slo para el caso que dichos flujos sean regulares a travs del tiempo, es decir, para iguales perodos de tiempo entre flujo y flujo. En el caso de flujos irregulares, el clculo del PAY BACK requiere del conocimiento del comportamiento de los flujos de caja, de tal forma de poder identificar claramente el momento en que dichos flujos cubren la inversin inicial. Si no se conociera la forma en que se generan los flujos sera necesario calcular un PPB estimado asumiendo alguna forma de obtencin de flujos de caja. Este criterio tiene la ventaja de su simplicidad, pero adolece de una desventaja fundamental, el comparar directamente valores producidos en distintos momentos de tiempo, adems de no tener en cuenta la rentabilidad del proyecto, ni los flujos de caja que se generan una vez recuperada la inversin inicial. El PAY BACK no es adecuado para comparar proyectos entre s, ya que puede llevar al elegir el proyecto que ms rpido recupere el capital aunque no produzca ningn aumento neto del patrimonio. No es un criterio econmico, solo una medida de tiempo.
19

A pesar de ello este mtodo sigue utilizndose, aunque ms bien como complemento de otros mtodos ms rigurosos. Ofrece una visin, por cierto limitada, del riesgo y de la liquidez de un proyecto. Cuanto ms breve sea el perodo de recupero, tanto menos riesgoso y tanto ms liquido se supone que es el proyecto, normalmente se aplica en la etapa que en Evaluacin de proyectos se denomina de idea, y muchas veces los inversionistas internacionales lo utilizan como medida antiriesgo. Las organizaciones con escasos recursos financieros, quiz consideren que el mtodo es til para forzar la ms rpida recuperacin de los fondos invertidos. En este sentido tiene algn mrito, pero no toma en cuenta la dispersin de posibles resultados; solo la oportunidad y magnitud, en relacin con la inversin original, del monto probable de esos resultados. Por lo tanto, no puede considerarse, en estricto rigor, como un ndice adecuado del riesgo; si se lo emplea es preferible considerarlo como una condicin a satisfacer ms bien que como una magnitud que debe optimizarse. Aplicacin Se desea desarrollar un sistema informtico para el proceso Ventas de una empresa comercial. El equipo de desarrollo -conformado por usuarios y especialistas- estima que para la obtencin del sistema se requiere del trabajo de un profesional especialista en anlisis y diseo por seis meses a tiempo completo y de dos profesionales, a tiempo completo durante tres meses para implementacin. Los desembolsos asociados a las tareas de anlisis y diseo alcanzan a US$ 4200 anuales. Para las tareas de implementacin, prueba y puesta en operacin, por su parte, se requiere de US$ 3000 como total anual. Como soporte, el sistema requiere de un equipamiento hardware/software equivalente a US$ 10.800. Se estima tambin, que el funcionamiento del sistema, en su operacin normal, generar un ahorro de costos de US$ 350 mensual, y que exige de costos de operacin de US$ 500 mensuales. Los ejecutivos de Ventas perciben que el sistema informtico les permitir tomar decisiones ms oportunas, las cuales redundarn en un aumento de las ventas que generarn un beneficio adicional de US$ 7.400 anuales. Dados estos datos, en consecuencia, los flujos de fondos para el sistema alcanzan a: - Inversin: Hardware/Software Anlisis y diseo Implementacin prueba y operacin Total Inversin - Flujos netos de Fondos (por perodo anual) Beneficios: Ahorro de costos US$ US$ US$ US$ 10.800 4.200 3.000 --------18.000

US$

4.200
20

Mejora de decisiones Total beneficios Costos: Costos de operacin Total de costos Beneficios menos costos

US$

7.400 --------US$ 11.600 US$ 6.000 --------US$ 6.000 US$ 5.600

La evaluacin del proyecto se llevar a cabo utilizando VAN, TIR y periodo de recupero, considerando perodos anuales y una vida til del proyecto de cinco aos, al cabo de los cuales no existe valor residual. Valor Actual Neto de Proyecto Si se considera una tasa de descuento -costo de capital- de un 10% anual, el VAN ser: VAN = -18.000+(5.600/1.10)+(5.600/1.10^2)+(5.600/1.10^3)+(5.600/1.10^4)+ 5.600/1.10^5) VAN = US$ 3.228,48 De acuerdo al VAN obtenido, entonces el proyecto es factible desde el punto de vista econmico. Tasa Interna de Retorno del Proyecto. A modo de una segunda evaluacin, se aplicar el mtodo de la Tasa Interna de Retorno, con lo cual se tiene: 18.000 = (5.600/(1+TIR))+(5.600/(1+TIR)^2)+(5.600/(1+TIR)^3)+ (5.600/(1+TIR)^4)+ (5.600/(1+TIR)^5) 5 18.000 = (5.600/(1+TIR)^t) t=1 Despejando, se obtiene: TIR = 0.168 = 16.8% As, la tasa de inters necesaria para igualar el valor actual de los futuros ingresos con el valor del egreso inicial, es de 16.8%, lo cual tambin indica que el proyecto resulta ventajoso. Perodo de Recupero del Proyecto. Finalmente, si se aplica el mtodo del perodo de recupero para este proyecto se tiene: PPB = (18.000/5.600) = 3.2 aos
21

Un rasgo caracterstico de sta tercera subactividad, es que durante ella se propone configurar ms de un escenario plausible. La razn de ello es, simplemente, el ofrecer opciones para elegir. Si el analista propone uno solo, el sistema ser a la postre el sistema del analista y si este falla, toda la responsabilidad caer sobre l. Cabe consignar que los escenarios tienen como destino la fase de Anlisis. Todo lo que se hace durante el Estudio preliminar es identificar diferentes escenarios que sern objeto de un examen posterior, al momento del Anlisis. As, la eleccin definitiva de uno de ellos por parte del usuario no se har en este momento del desarrollo. Cabe consignar que de no ser posible configurar escenarios plausibles no es extrao que el proyecto se detenga. No en pocos casos, en algunas organizaciones, se da inicio a un Estudio preliminar en relacin a sus sistemas de mayor envergadura o ms crticos para ver si existe alguna nueva solucin digna de estudiar. De no existir, es bastante probable que el proyecto se detenga en esta tercera subactividad, debido a que muchas veces las Gerencias tienen tendencia a sostener que el modo de hacer actual, an con todas sus deficiencias es an costo-efectivo. Sin embargo, cabe al respecto sealar que con los sostenidos avances tecnolgicos del presente, siempre existe la posibilidad de mejorar el performance de un sistema. 4.- Preparar las directrices del proyecto. El propsito de esta subactividad es generar las directrices que servirn de gua para llevar a cabo el resto de las tareas propias del desarrollo de todo proyecto informtico. En una primera aproximacin dichas directrices deben establecer los objetivos del proyecto, su mbito, los plazos estipulados y los estudios de factibilidad realizados para cada escenario. Las directrices del proyecto deberan incluir, adems, un detallado plan de trabajo que deje de manifiesto todas las actividades -las fases por las cules debe pasar el proyecto- que se vienen por delante y todos los resultados que se precisa entregar en cada una de ellas. Las salidas de esta subactividad son el documento que recoge las directrices, a denominar precisamente Directrices del proyecto y un Informe tentativo de factibilidad para cada uno de los escenarios establecidos en la subactividad anterior. Para lograr estos resultados es necesario contar, como lo muestra la figura 1.2, con las nuevas perspectivas para el sistema establecidos en la segunda subactividad, con las restricciones establecidas por la Gerencia y con los escenarios configurados en la tercera subactividad. El documento Directrices del proyecto debe contener: un resumen del proyecto, su contexto, una declaracin de metas y objetivos, las actividades a desarrollar para obtener la nueva versin para el proceso, un programa relativo a aquellas actividades, las restricciones tcnicas y de procedimientos y los escenarios plausibles. El resumen del proyecto debe contener el nombre del proyecto, el usuario responsable, la unidad organizacional bajo estudio, la fecha de inicio del proyecto, la fecha de trmino, la asignacin presupuestaria, el analista responsable y una declaracin de los propsitos del proyecto.

22

El contexto del proyecto debe dar cuenta de la perspectiva actual del proceso objeto de tratamiento informtico y de los otros procesos con los cules se vincula, en cuanto unidad simple, tanto por la entrada como por la salida. Dicha expresin contextual debe ir acompaada de un acpite que recoja todos los cambios que figurando en el documento Nuevas perspectivas elaborado en la segunda subactividad, lo afectan efectivamente. El acpite referido a las metas y objetivos del proyecto debe recoger precisamente las nuevas perspectivas para el proceso objeto de tratamiento informtico, las cules no son otras que aquellas que fueron establecidos en la segunda subactividad. Corresponden a una sntesis que debe recoger los nuevos subprocesos a considerar, aqellos que se deben eliminar o reformular, las deficiencias que se precisa corregir y todos los aspectos a modificar o agregar. Las actividades a desarrollar es la seccin de las directrices del proyecto que debe puntualizar las diferentes actividades que se precisa llevar a cabo para la obtencin definitiva de la nueva versin para el proceso, junto con los resultados que debe entregar cada una de ellas. La propuesta del desarrollo estructurado sugiere utilizar para mostrar las diferentes actividades y sus relaciones un Diagrama de flujo de datos de alto nivel como aquellos que se emplean durante la fase de Anlisis. El acpite relativo a la programacin de las actividades debe mostrar las restricciones temporales que habrn de afectar al desarrollo del proyecto. Se basan en las restricciones impuestas por la Gerencia y se sugiere incluirlas en el Diagrama de flujo de datos de alto nivel -si se ha construido- que da cuenta de las etapas por las cuales debe pasar el desarrollo del proyecto. All aparecen las fechas claves y las restricciones impuestas a la entrega de resultados -parciales y finales- que contempla. Cabe destacar que para confeccionar este diagrama debe haberse tomado la decisin respecto del empleo de una estrategia de desarrollo radical o una conservadora. De este modo, si se ha optado por la ltima, las fechas marcadas representan el trmino total de las actividades de Anlisis, Diseo, etc., sugiriendo la secuencialidad propia de este enfoque. Las restricciones tcnicas y de procedimientos deben recoger las restricciones que impone la Gerencia en relacin, principalmente, a parmetros de efectividad, a la configuracin del hardware, a provisiones de seguridad, a condiciones ambientales y a convenciones de implementacin. Los escenarios plausibles es la seccin de las Directrices del proyecto que debe dar cuenta de los escenarios que fueron establecidos en la tercera subactividad. Cabe recordar que el desarrollo estructurado recomienda para documentar los diferentes escenarios el empleo de Diagramas de flujo de datos pero solo a dos estratos. Su propsito no es otro que dar una visin general de las posibles opciones que podran satisfacer las nuevas perspectivas, dentro, por cierto, de las restricciones establecidas. El Informe tentativo de factibilidad, por su parte, no hace ms que recoger los estudios realizados respecto de la factibilidad econmica, tcnica, operacional y legal para cada escenario. Lo Top-down en el Estudio preliminar.
23

Las estrategias para enfrentar el desarrollo de un sistema se pueden sintetizar en cuatro de ellas: ultraprogresivo, moderadamente progresivo, moderadamente secuencial y rigurosamente secuencial. Cada una de las actividades de desarrollo, incluyendo por cierto al Estudio preliminar, pueden enfrentarse de modo ultarprogresivo o rigurosamente secuencial. Pero aunque se sostenga que los extremos no son buenos, no es conveniente a priori su rechazo. Bajo un enfoque ultraprogresivo lo que se puede esperar es simplemente la omisin del desarrollo formal de las tres primeras subactividades, de modo tal que todo lo que de ellas debiera resultar se incorpora al documento Directrices del proyecto tan solo intuitivamente. Incluso, el analista podra establecer su enfrentamiento formal durante la fase de Anlisis. Obviamente proceder de este modo puede parecer razonable para proyectos muy pequeos, pero poco conveniente para proyectos de envergadura. Conforme a un enfoque moderadamente progresivo, todas las subactividades del Estudio preliminar se deberan abordar de modo sucinto pero con el compromiso formal de proceder ms profundamente a medida que el proyecto avanza. Puede pensarse en un documento en el cual se da a entender que existen razones para desarrollar el nuevo sistema, aunque tan solo se entreguen justificaciones superficiales. Tal vez lo ms importante que se desprende de este modo de proceder es que frente a las limitaciones del documento as logrado es necesario, durante el Anlisis, establecer con ms precisin las deficiencias, los nuevos objetivos y los escenarios plausibles. En realidad, el Estudio preliminar bien puede considerarse como una suerte de minianlisis ya que aunque las actividades que se deben llevar a cabo durante la fase de Anlisis pueden parecer muy diferentes de aquellas que se deben enfrentar durante el Estudio preliminar, existen entre ellas bastantes asuntos en comn. Lo que el enfoque estructurado de desarrollo de sistemas sugiere es que el Estudio preliminar se realice rpidamente y sin grandes gastos tan solo para ayudar a justificar los recursos monetarios y el tiempo normalmente bastante significativos que requiere el Anlisis. Una propuesta ms convencional es aquella que ofrece el enfoque moderadamente secuencial. Lo que sugiere es un completo desarrollo de todas las actividades que comprende el Estudio preliminar, pero sin la intencin de repetirlas ms tarde en las fases posteriores del proyecto. En realidad en la mayora de los proyectos parece optarse por este enfoque, tal vez como lo seala E. Yourdon [YOU-93] porque sera desconcertante re-examinar lo referente al costo/efectividad en la mitad del camino recorrido. Por ltimo, la propuesta del enfoque rigurosamente secuencial sugiere un completo estudio del dominio funcional del usuario. As, en vez de un estudio costo/beneficio tentativo, lo que se debe tener son cifras definitivas, en vez de escenarios tentativos, escenarios tambin definitivos. Es decir, bajo esta propuesta lo que se logra es lo que normalmente se alcanza durante la fase de Anlisis. Obviamente cuesta imaginar porqu resulta deseable proceder de este modo, a menos que la factibilidad del proyecto se asuma dada o resulte una inevitable conclusin y que la Gerencia desee que el analista comience con un trabajo detallado, con lo cual ms que en el Estudio preliminar el analista estara ya en el trabajo propio de la fase de Anlisis. REFERENCIAS.
24

YOU-93 Yourdon, E., Modern Structured Analysis, Prentice-Hall, N. York, 1996. ALV-95 Alvarez, C. Evaluacin Financiera de Proyectos, Ediciones Universitarias de Valparaso de la UCV, Valparaso, 1998.

25