El ciclo de vida clsico INTRODUCCIN - DESCRIPCION GENERAL El Ciclo de vida clsico (CDVC) es el ms antiguo y utilizado mtodo o metodologa de anlisis

de sistemas de informacin. Tambin llamado modelo en cascada o por fases, exige un enfoque sistemtico y secuencial que comienza con un boceto del problema en general y acaba cuando conseguimos una serie de procesos razonablemente asequibles para la programacin que una vez implantados solucionarn el problema percibido. Se compone de una secuencia de fases consecutivas de manera que ninguna fase puede comenzar si no ha terminado completamente la anterior. Dentro de cada fase, que tendr un objetivo bien determinado, se dan una serie de procesos protagonizados por distintos actores, se utilizan diversas herramientas, se genera una serie de documentacin. Como consecuencia de todo esto. a partir de una entrada la fase entrega una salida para la siguiente fase (Fig. 5.]). LAS FASES DEL CDVC Aunque con un esquema general comn, las fases del ciclo de vida clsico tienen distintos nombres segn diferentes autores u organizaciones. Dentro de las fases, los objetivos suelen ser iguales para todas las organizaciones y autores. Los actores dependern de la organizacin o empresa y de la entidad de la aplicacin. Las herramientas en general suelen ser las mismas, pero cada organizacin elegir un conjunto propio; adems, se pueden dar herramientas muy particulares en alguna empresa. Los procesos son propios de cada organizacin, autor, CPD, etctera, as como el soporte y cdigos de la documentacin. aunque no los contenidos, que dependern lgicamente de la aplicacin. LAS FASES DEL CICLO DE VIDA CLASICO ANALISIS PREVIO ANALISIS FUNCIONAL ANALISIS ORGANICO PROGRAMACION + PRUEBAS IMPLANTACION Y MANTENIMIENTO

CADA FASE TIENE ACTORES o PROCESOS HERRAMIENTAS DOCUMENTOS

A la seleccin de procesos, herramientas, cdigos, etc., se le denomina de desarrollo y vendr reflejado en los manuales del centro de procesos de datos.
1

El uso de estndares facilita enormemente el aspecto prctico del anlisis. Todo comienza cuando, bien a peticin de los usuarios o por deteccin problemas por parte de los analistas de informacin, comienza a pensarse nuevo sistema de informacin, la modificacin de uno ya existente o la sustitucin total del mismo. A partir de aqu las primeras fases en general tienen por definir el problema mediante las aclaraciones que sean precisas y estudiar soluciones al mismo, evalundolas convenientemente a fin de intentar encontrar solucin general viable del problema en cuestin. En las siguientes fases la solucin ser sometida a refinamientos sucesivos, comenzando por un primer gran refinamiento en el que el sistema se precisa a un nivel funcional, dividiendo la solucin global en partes que pretenden solucionar ciertas parcelas concretas. Posteriormente estas soluciones funcionales son sometidas a un segundo refinamiento cuyo objeto es la construccin informtica del sistema. Las salidas de la fase anterior se someten una a una a las revisiones necesarias para convertirlas en programas que, a la postre y en funcin de los diseos de archivos, entradas y salidas que ya se han realizado de cara a codificar la solucin, que ser la siguiente fase, constituirn el sistema informtico que se deber probar e implantar, para lo que se necesitarn adems algunos manuales, como son el del propio sistema, donde se describe globalmente el mismo; el de explotacin, donde se dice cmo utilizarlo por los informticos, y el de usuario que describe en este entorno cmo utilizar el sistema por los no informticos, las interacciones usuarioproceso de datos a fin de que la aplicacin o sistema sea utilizada correctamente. Una vez implantado el sistema, durante su explotacin sern necesarias revisiones, lo que conocemos como mantenimiento, en funcin de pequeas modificaciones o de los errores que siempre se producen y que nos llevarn a corregir ciertos aspectos. En definitiva, el ciclo de vida clsico, que es un ciclo de vida lineal, desarrolla y especifica un sistema de manera descendente. Las fases y actividades se realizan de una manera estricta. Las fases sucesivas elaboran y detallan las anteriores, aumentando y completando las soluciones parciales que en ellas se reflejan. CRITICAS AL MODELO En la actualidad, el ciclo de vida clsico est recibiendo diversas criticas, hasta el punto de cuestionar su utilidad. Los problemas que se le achacan son muy variados. A continuacin se mencionan los ms comunes. Normalmente es muy difcil por parte de los usuarios establecer y detallar todos sus requerimientos al principio, con lo que quedarn incertidumbres que se tendrn que suponer o resolver de la mejor manera posible. Tiene gran dificultad cuando los requerimientos son imprecisos para captar de una forma completa las necesidades del usuario. Se cuenta bien poco con los utilizadores>) de la aplicacin, Basndonos en las aseveraciones realizadas por usuarios de alto nivel (enlaces de usuarios) que pueden no estar al tanto de los pequeos detalles que dan precisin a las especificaciones. Con frecuencia los planteamientos realizados durante las primeras fases no se mantienen en las posteriores, quedando las fases Iniciales incompletas. Esto har que tengamos que volver a redefiniras y rehacer algunos trabajos. Algunos objetivos que se pensaron viables en un principio puede que ahora no lo sean. En el caso an peor de que los problemas se detecten durante la fase de desarrollo, habr que redisear todo el sistema; as pues, los proyectos reales raramente siguen el flujo secuencial que propone el modelo, crendose bucles e iteraciones durante el proyecto que complican y distorsionan la metodologa.
2

El tiempo de desarrollo es muy largo. Los usuarios han de tener mucha paciencia fe. Los errores no descubiertos hasta que los programas estn funcionando pueden ser catastrficos. Suele ser excesivamente artesanal en cuanto a las soluciones en base a las empresas y organizaciones, con tcnicas que aparentemente conllevan el "aprendizaje" dentro de la organizacin. No hay separacin entre los flujos fsicos y lgicos, trminos que se aclararn cuando hablemos de enfoques ms actuales. VIGENCIA ACTUAL El CDVC permanece hoy como el modelo ms ampliamente utilizado, ocupa un lugar muy importante entre las metodologas de anlisis, es el arranque de todas las dems y en general con diversas adaptaciones puede ser til para cualquier tipo de aplicacin. Sin embargo, se adapta mejor a los entornos similares a los que en un principio se aplic, aplicaciones muy voluminosas orientadas a procesos por lotes o distribuidos, pero con control fuertemente centralizado, con varios departamentos implicados con equipos de anlisis y desarrollo grande, y tiempo de desarrollo muy largo Es especialmente adecuado cuando la nueva aplicacin reemplaza a una existente ya obsoleta. Las especificaciones ya se conocen y el proyecto pueden manejarse en con gran eficacia dentro de mrgenes de tiempo y costes. Tambin es adecuado cuando las especificaciones de estndares y datos ya existen junto con las maquinas necesarias, o cuando los usuarios tienen gran experiencia en el rea y pueden explicar con gran precisin los requerimientos y especificaciones actuales y futuros; tambin cuando se necesita una coordinacin muy cuidadosa y eficiente al estar involucradas muchas reas en la organizacin. Es importante el tener en cuenta que en la prctica no hay una metodologa nica. El CDVC es sumamente adaptable a situaciones concretas y adems se puede combinar con estrategias y enfoques ms actuales. Esto es de alguna manera lo proponemos realizar dentro de lo que hemos llamado enfoque prctico del anlisis. Anlisis previo INTRODUCCION Como ya se ha dicho, en el CDVC cada fase se compone de manera genrica de un objetivo, actores, herramientas y procesos, generando a partir de una entrada la salida para la fase siguiente. En esta introduccin trataremos el objetivo, los actores y los procesos, dejando el resto para puntos posteriores. OBJETIVO El objetivo del anlisis previo es el de proporcionar bases ponderables para la toma de decisin respecto a la conveniencia o no de llevar a cabo la informatizacin de un determinado problema de informacin en la empresa. En caso de decidirse la informatizacin, en esta fase se ofrece una primera visin global de la solucin elegida.

ACTORES Respecto a los actores, stos suelen ser: Personal informtico: En general, analistas experimentados de alto nivel. Personal no informtico: Por un lado, usuarios de alto nivel, a veces y en este contexto llamados enlaces de usuario. Y por otro se pueden tener consultores de otras reas, tanto internos como externos a la organizacin.

La responsabilidad del anlisis previo corresponde en general a un analista de alto nivel designado por la direccin del CPD, que organizar un equipo de trabajo en colaboracin con los departamentos afectados, contando con las personas que crea convenientes y que en general, como ya se ha dicho, sern informticos, usuarios y asesores internos o externos, dimensionando el grupo en funcin de la importancia del trabajo considerado. PROCESOS De una manera amplia podemos decir que el anlisis previo es el conjunto de estudios que permite evaluar la viabilidad del sistema de informacin informatizado que se va a adoptar de acuerdo con las necesidades planteadas por el usuario. En general, consistir en: Una investigacin amplia de operaciones y procedimientos relacionados con el problema. Seleccin de reas afectadas para un posterior anlisis. Estudio de la documentacin y procesos actuales incluyendo volmenes, costes y Tiempos. Consideracin de sistemas alternativos incluyendo tiempos y costes.

El anlisis previo acabar con la presentacin de la documentacin sobre el sistema elegido o en otro caso una decisin negativa. La decisin slo se puede tomar cuando el usuario posee elementos suficientes para evaluar la rentabilidad del sistema propuesto y su viabilidad de acuerdo con sus propios planes y necesidades. Por tanto, habr que establecer un mtodo riguroso a fin de obtener los resultados y conclusiones que el usuario necesite para la toma de decisin. Hay que tener en cuenta que la aprobacin llevar implcita la autorizacin de gastos en medios y recursos tanto humanos como materiales que se producirn inevitablemente en las siguientes fases. Durante el anlisis funcional y orgnico y el desarrollo se producen, entre otros, gastos en personal informtico, especialistas, enlaces de usuario, etc.; tambin consumo de ordenadores para la codificacin y prueba de programas durante la implantacin, gastos en adaptacin o ampliacin de recursos informticos, formacin..., y posteriormente los gastos de explotacin. Se realizar un plan de trabajo en el que se contemplen los plazos asignados a las tareas a realizar dentro de la fase y las herramientas a utilizar, que en general en esta primera etapa consistirn en entrevistas, cuestionarios, observaciones directas, participacin en tareas, etc. Todo ello quedar plasmado en los documentos propios del informe final del anlisis previo y adems en las actas de las reuniones que se realizarn peridicamente, por lo que es conveniente designar un secretario del equipo de trabajo.
4

ENTRADA Por ser la primera, no hay fase que preceda al anlisis previo. Antes de l se encuentra nicamente el sistema existente, el cual se ve afectado por una serie de problemas, por lo que en primer lugar conviene revisarlo a fin de evaluarlo y definir con claridad el problema que se pretende resolver. SALIDA La salida del anlisis previo es fundamental para la metodologa, ya que es la base para la realizacin del sistema. Constar lgicamente del sistema propuesto ms toda la documentacin generada, siendo la entrada a la siguiente fase del ciclo. DOCUMENTACIN Adems de la documentacin que hasta ahora ha venido apareciendo, si finalmente la solucin propuesta se acepta, se realiza el informe final del anlisis previo, en el que en primer lugar ir un ndice, seguido por un resumen de conclusiones que coincidir con el punto anterior, ampliando posteriormente las conclusiones obtenidas en base a un esquema, que podra ser:
1. 2. 3. 4.

5. 6. 7.

Situacin actual Organizacin. Descripcin del sistema actual, problemas y critica. Costes. Soluciones a considerar. Alternativas factibles, ponderacin de las alternativas en Funcin de sus ventajas, desventajas y medios implicados. Sistema propuesto, descripcin general. Beneficios tangibles e intangibles, economa de costes actuales, previsin de economa sobre costes futuros, exposicin de beneficios no mensurables o medibles. Necesidades de desarrollo, recursos humanos y materiales. Costes de explotacin del sistema, equipos y personal. Estimacin de desarrollo, duracin y plan de tiempo.

Se debe incluir fecha y firma de todos los implicados en el informe y responsables de las reas afectadas, as como el visto bueno del jefe de anlisis que design al analista responsable. Antes de llegar a este punto, naturalmente los afectados se habrn reunido para revisar el informe y hacer las revisiones y objeciones pertinentes. HERRAMIENTAS DEL ANLISIS PREVIO Para llevar a cabo los procesos de la fase se utilizan una serie de herramientas, algunas de las cuales se exponen a continuacin. HERRAMIENTAS DEL ANALISIS PREVIO LAENTREVISTA CUESTIONARIOS OBSERVACION Y PARTICIPACIN EXAMEN DE ARCHIVOS Y DOCUMENTOS MUESTREOS

ENTREVISTA La entrevista es sin duda la principal herramienta en esta fase del anlisis. Convenientemente utilizada, nos ayudar a encontrar diferentes hechos, necesidades de informacin, responsabilidades y objetivos, operaciones, estructuras jerrquicas, etc. Mediante la informacin de ella extrada podemos realizar, auxilindonos de herramientas descriptivas, diagramas jerrquicos, esquemas decisionales, flujos de informacin, etc. Para que la entrevista sea efectiva debemos seguir un mtodo, antes, durante y despus de ella. Antes de la entrevista es importante determinar a quin preguntar, cundo, qu preguntar y dnde. Se debe fijar da, hora y lugar, procurando que la entrevista sea introducida por una persona con autoridad en la organizacin. Se debe buscar un ambiente propicio y evitar en los posible las interrupciones. Convendr ser puntuales, identificndonos y haciendo una pequea introduccin sobre nuestra intencin. Nuestro comportamiento debe ser formal pero relajado, creando un ambiente distendido con el entrevistado de manera que sus respuestas sean lo ms espontneas posible. Debemos tener cuidado en que nuestras preguntas estn al nivel de nuestro entrevistado (no es igual un directivo que un mando intermedio, por ejemplo), evitar un lenguaje informtico, procurando en lo posible un lenguaje acorde con la organizacin). No es un interrogatorio, hay que dejar hablar al entrevistado sin acosarlo con nuestros propios argumentos y consejos. En el transcurso de la entrevista es conveniente tomar notas, pero sin que ello descentre la cuestin. Al llegar aqu se nos plantea un dilema que estar presente en todas nuestras entrevistas: hasta qu punto debemos planificar o estructurar rgidamente la entrevista. Aunque la tendencia es planificar, incluso de acuerdo a un mtodo en el que se entrena al analista, a veces el no seguir rgidamente un guin nos puede dar ms flexibilidad, si bien necesitaremos emplear en general ms tiempo. Si el nmero de entrevistas es elevado, las conclusiones sern ms difciles de obtener. En cualquier caso es sumamente importante verificar y revisar las notas que se han tomado con la persona entrevistada antes de despedirnos. No debemos obsesionarnos con acotar todo el problema en una sola entrevista. Si se estima oportuno, podemos acordar una o varias ms, por lo que es importante que tengamos localizados a los protagonistas dentro de la organizacin. Es importante agradecer la ayuda prestada a la persona entrevistada y ofrecerle, si es su deseo, copia de las notas registradas. Inmediatamente despus de acabar es fundamental releer nuestras anotaciones, complementndolas con aquellas impresiones que no son convenientes dejar al usuario, reorganizar y planificar para siguientes contactos; posteriormente, ya en diferente lugar, debemos proceder a escribir nuestras conclusiones con herramientas de documentacin adecuadas. Como otros tantos aspectos, el xito de la entrevista depender de la experiencia y preparacin del entrevistador. Se requiere especialmente habilidad cuando los usuarios entrevistados no estn relajados y se muestran tensos ante nosotros. Hay que hacer un esfuerzo por aprender a escuchar, dejar hablar, no adelantarse a las respuestas, introduciendo sesgos en los resultados. Conviene mezclar preguntas con respuesta abierta que faciliten la expansin del entrevistado, con preguntas ms o menos cerradas y premeditadas siempre precedidas de alguna frase amable (me podra aclarar..., me gustara escuchar su opinin sobre...).

B- CUESTIONARIOS Los cuestionarios son tiles cuando se quiere informacin concreta que involucra a un gran nmero de personas. Es inevitable en este caso utilizar formatos ms o menos estandarizados. Seria nefasto dejar en este caso respuestas abiertas, salvo en contadas ocasiones. Hay que tener precaucin, ya que las respuestas, si las preguntas no son muy claras, pueden resultar contradictorias o carentes de sentido. Una gran desventaja es no poder ver las reacciones de los sujetos. Sin embargo, son muy tiles cuando hay que recabar la opinin de personas en localidades remotas o, como se ha dicho, el nmero es elevado. Su xito se basa en gran manera en la comprensin por parte de los encuestados y la honestidad de sus respuestas. 1 C- OBSERVACIN Y PARTICIPACIN Mediante estas herramientas podemos descubrir detalles imposibles de conseguir con otras. No siempre es posible participar, pero s observar. Sobre todo es importante cuando queremos obtener una idea del grado de aceptacin de las tareas y quejas de los operarios, y tambin a la hora de confirmar ciertas respuestas anteriormente obtenidas. Debemos observar todo lo posible a nuestro alcance, condiciones en las que se desarrolla el trabajo, distribucin del personal, el uso del telfono, movimiento de personas entre mesas, trasiego de documentos. Si es posible participar, no debemos perder la oportunidad. Asistir a una reunin de trabajo o realizar alguna de las tareas nos aportar una informacin preciosa. D- EXAMEN DE ARCHIVOS Y DOCUMENTOS Mediante esta herramienta podemos obtener informacin cuantitativa en cuanto a volmenes, frecuencias, tendencias y manejo de los archivos de la entidad. Tambin podemos medir en gran manera el grado de confianza que se puede depositar en las estimaciones hechas por el propio personal durante las entrevistas o cuestionarios. Tambin se deben examinar los manuales de procedimientos y normas, estndares de operacin, reglamentos internos, publicaciones sobre polticas de la organizacin, etc., que pueden ser de gran ayuda para comprender las lneas maestras de la organizacin, as como las relaciones formales en ella. E- MUESTREOS Cuando los documentos son de gran volumen o se repiten con mucha frecuencia, puede ser til y aceptable la utilizacin de muestreos, es decir, el examen al azar de los documentos. Si es posible, se debe evitar como nica forma de examinar archivo y documentos. Anlisis Funcional INTRODUCCION Esta fase es una frontera entre todas las partes implicadas, direccin, usuarios e informticos. Se suele decir muy a menudo que el anlisis funcional es independiente de la computadora y equipos tcnicos, por ser de alto nivel tcnico-organizativo. Sin embargo, desde un punto de vista prctico, los analistas que saben dnde se mueven, comienzan a orientar de una manera ms o menos sutil la solucin hacia determinados equipos informticos, sobre todo si pertenecen a una organizacin con sus propios equipos informticos.
7

ENTRADA. OBJETIVO A partir del anlisis previo y su documentacin generada en esta fase se estudia con un enfoque ms tcnico la solucin aportada, orientndola hacia el producto final, en cuanto a funciones y tratamientos, constituyendo as un primer refinamiento de la solucin general, sumergindonos por completo en el entorno informtico y utizando ya estndares del proceso de datos. En definitiva, tratarnos de reproducir un modelo que a partir de la visin funcional del usuario sea implementable en un entorno de proceso de datos. ACTORES Se debe constituir un equipo de anlisis funcional compuesto en este caso por tcnicos. Sin embargo, es conveniente revisar la solucin junto con los usuarios a fin de fijar los objetivos de gestin. A partir de aqu slo participan en este estudio tcnicos informticos, y por tanto lo que ocurra ser transparente al usuario. HERRAMIENTAS Esta etapa utiliza fundamentalmente herramientas grficas y Estndares de procesos de datos Mediante la adopcin de estndares se reducen los esfuerzos de desarrollo y se facilita la tarea de las especificaciones a todos los niveles, permitiendo una comunicacin ms gil y eficaz entre los miembros del equipo de trabajo. Los estndares, que en gran medida dependen de la instalacin, son de muy diverso tipo, simbologa, documentacin, cdigos, etc. LOS PROCESOS En este punto se producen diferentes variaciones en cuanto a los pasos a dar segn distintos autores y organizaciones, aunque dentro del mismo objetivo comn. En definitiva, ser la organizacin en la que nos encuadremos la que marcar la pauta. Sin embargo, a continuacin exponemos sintetizadamente dos enfoques sobre este punto. Primer enfoque Vamos a revisar un enfoque muy clsico de los procesos a realizar en el anlisis funcional. Es un enfoque lineal en un solo nivel, muy rgido. El anlisis funcional est totalmente separado del anlisis orgnico. Los pasos son los siguientes: * Estudio de las normas de gestin de la empresa

Consiste en estudiar las frmulas de clculo, condiciones, imperativos administrativos, plazos, etc., que constituyen las normas de gestin y tratamiento funcional de la informacin y que nuestra aplicacin debe reproducir. * Estudio de las salidas

En este enfoque, y en general en casi todos, es fundamental saber qu tipo de salidas espera obtener el usuario de la aplicacin, ya que en funcin de ellas se disearn los archivos de datos. Se deben estudiar los modos, soportes, contenidos y caractersticas de todas las salidas de la aplicacin.
8

Estudio de los archivos

En este enfoque se recomienda estudiar y disear primero los archivos permanentes (maestros, de constantes e histricos fundamentalmente), pues de ellos se obtendrn las salidas, posponiendo para el anlisis orgnico el resto Se deben definir las caractersticas y contenidos de cada uno de los archivos permanentes. * Estudio de las entradas

Con la salvedad de procesos on-line en cuyo caso se debe invertir el orden de este punto y el siguiente, estudiaremos aqu los modos, soportes, contenidos y caractersticas en las entradas a la aplicacin. * Estudio de los controles

Debemos estudiar y definir tanto los controles manuales como por programas de las entradas y salidas. * Divisin de la aplicacin en unidades funcionales

Es un paso muy importante. Una unidad funcional resuelve un subconjunto de los problemas que la aplicacin trata de resolver. En si es una pequea aplicacin dentro de la aplicacin. Es, en definitiva, el producto obtenido en esta fase de la metodologa que posteriormente, en la siguiente fase, se convertir en unidades ms pequeas y tratables desde el punto de vista de la programacin. Las principales razones que justifican la divisin de una aplicacin en unidades funcionales son fundamentalmente facilitar su realizacin, prueba y mantenimiento. El criterio ms usual para dividir una aplicacin en unidades funcionales es hacerlo en base a las funciones de gestin percibidas segn el punto de vista del usuario. No obstante, se siguen otros muchos criterios como la magnitud de la aplicacin, el nmero de archivos permanentes, el nmero de archivos de movimientos, el calendario de ejecucin de procesos, etc. Una unidad funcional se representa grficamente mediante organigramas, en conjunto por un organigrama funcional que se puede acompaar de una pequea descripcin narrativa sobre el sentido de la misma, y en detalle representando las unidades de menor nivel y ms detalle que la forman por un organigrama orgnico que suele acompaarse a su vez de una descripcin de su finalidad y sirve de enlace con el anlisis orgnico (vanse Figs. 7.5 y 7.6). Tambin podemos representar, aunque no es corriente en este entorno, una unidad funcional mediante un diagrama jerrquico. * Estudio de la red funcional

Se estudian aqu los puestos afectados por la futura entrada en vigor de la aplicacin y la circulacin de la informacin en base a esto. * Estudio de los problemas de seguridad
9

Este punto es de vital importancia. Se deben estudiar todos los procesos orientados a este fin, como copias de seguridad, proteccin contra accesos indebidos, procedimientos de restauracin de la informacin, etc. Segundo enfoque Consiste en realizar el anlisis funcional en dos niveles, global y en detalle, de manera que anlisis funcional y orgnico se tocan, siendo el segundo prcticamente una continuacin del primero, formando en ocasiones un solo bloque llamado diseo del sistema propuesto. No obstante, aqu separaremos el funcional del orgnico a partir de la exposicin que estamos haciendo. En el nivel global realizaremos un primer esquema general de la solucin para, posteriormente, en detalle concretar los puntos que la componen. En el Capitulo 10 estudiaremos un caso concreto que utiliza este tipo de enfoque. * Visin global

Se realiza una descripcin general de la aplicacin definiendo sus objetivos y alcance, utilizando la narrativa, auxilindose si es preciso de herramientas grficas descriptivas. De acuerdo con los estndares de la organizacin, se introduce la aplicacin y sus objetivos generales, se definen los puntos que se crean de importancia para situar el sistema, se citan las reas afectadas, las relaciones con otras aplicaciones y, dependiendo de la naturaleza de la aplicacin, aquellos puntos de inters general que se crea conveniente tratar. * Visin detallada

Utilizando siempre documentos y herramientas estandarizadas, se especifican de manera concreta los elementos que constituyen la solucin con vistas a su desarrollo en una computadora. Se relacionan, describen y disean los documentos de entrada y salida de la aplicacin. Se relacionan, describen y disean los archivos que participan en ella (al menos los ms importantes, dejando los auxiliares para el anlisis orgnico), as como sus registros. Se relacionan, describen y disean los listados que se obtienen de la aplicacin. Muy importante tambin en este enfoque y en general en todos los que tienen que ver con el anlisis funcional es la divisin de la aplicacin en unidades funcionales, que aqu definiremos como un conjunto de operaciones lgicas que resuelven una determinada funcin desde el punto de vista del usuario. Las razones para dividir una aplicacin en unidades funcionales son muy variadas, tal como se ha dicho en el punto anterior. Posiblemente cada organizacin tenga unas normas concretas para hacerlo. Adems, se suelen agrupar a su vez, ya desde una ptica casi exclusiva de explotacin, en bloques superiores denominados subsistemas o simplemente bloques. Las unidades funcionales se describen utilizando los organigramas funcionales y orgnicos, como hemos visto en el punto anterior. Los bloques, a su vez, se describen mediante organigramas
10

funcionales. Si la aplicacin es o tiene parte de entorno on-line, debemos recordar que desde el punto de vista clsico la implementacin de esta parte de la aplicacin la realiza el rea de sistemas, concretamente el grupo de teleproceso. Por tanto, la descomposicin on-line termina aqu identificando la transaccin como una unidad funcional, descrita con su correspondiente organigrama funcional, ya no orgnico, que posteriormente ser resuelto por el rea de sistemas. Por transaccin se entiende una unidad lgica de tratamiento en lnea de la informacin. SALIDA. DOCUMENTACION La salida de esta fase es, como se ha dicho, desde el punto de vista de resolucin, el problema de las unidades funcionales. Desde el punto de vista de la comunicacin, la salida es la documentacin generada sobre el sistema o aplicacin propuesta. Ahora que sabemos mucho ms sobre el sistema en cuestin, puede que sea el momento de ajustar previsiones. Puede que tambin sea un buen momento para preguntarnos si de acuerdo con este reajuste la decisin file correcta. Si el resultado es positivo, pasaremos a la redaccin de la documentacin de esta etapa, que puede recoger los siguientes puntos: ndice 1. Introduccin. (Donde se habla del sistema en general y los factores que han llevado a su Objetivo. 2. Objetivo (Donde se explican claramente los objetivos a cubrir por el sistema en cuestin) 3. Descripcin del sistema propuesto. Con los siguientes puntos: Visin general del sistema. Definiciones previas. Areas afectadas. Diagramas de flujo. Descripcin de funciones. Descripcin de documentos. Documentos de entrada. Documentos de salida. Especificaciones y descripciones de archivos y registros. Unidades funcionales. 4. Relacin con otras aplicaciones. 5. Anexos que se crean convenientes. Anlisis orgnico INTRODUCCION A partir de las unidades funcionales obtenidas en la fase anterior, sta, que es totalmente tcnica, tiene como objeto desmenuzaras y detallaras suficientemente para que su programacin sea posible. Los trminos utilizados en esta fase son totalmente tcnicos, transparentes para el usuario y basados fundamentalmente en los estndares de la organizacin. M final de ella obtendremos los Denominados cuadernos de carga, que contienen todas las especificaciones necesarias para realizar
11

los programas de computadora que constituirn la aplicacin que estamos desarrollando. As pues, podemos decir que: La entrada a esta fase son las unidades funcionales generadas en la fase anterior. La salida la constituyen las unidades de tratamiento o partes en las que se dividen o refinan las unidades funcionales de cara a la programacin. Los actores son todos tcnicos, fundamentalmente analistas-programadores o programadores experimentados, constituyendo los distintos equipos de anlisis orgnico. Los procesos fundamentales giran en torno a uno solo: descomposicin de la unidad funcional en unidades de tratamiento. Previamente se habrn constituido los equipos y realizado la planificacin temporal (calendario). Dependiendo de la metodologa, en algunos casos se hace un estudio previo de aquellos archivos que no se estudiaron durante el anlisis funcional, fundamentalmente auxiliares y de movimientos, y en ocasiones los llamados de enlace)> que son aquellos archivos que relacionan unas unidades funcionales con otras; es decir, son a la vez salida en una UF y entrada a otra. La documentacin consiste fundamentalmente en los cuadernos de carga, precedida por los organigramas orgnicos de las unidades funcionales correspondientes. Las herramientas son fundamentalmente descriptivas, diagramas y organigramas as como descripciones a partir de estndares de documentacin son en su concepcin general ya conocidas, particularizndolas ahora conforme avancen los siguientes puntos. DESCOMPOSICION DE LAS UNIDADES FUNCIONALES Para descomponer una unidad funcional en unidades de tratamiento se siguen NORMAS similares a las de descomposicin de una aplicacin en unidades funcionales. De igual forma los motivos para la descomposicin son idnticos. EL CUADERNO DE CARGA Dentro del enfoque clsico, el cuaderno de carga es el caballo de batalla) para el programador de gestin, su razn de ser. Es el trabajo que le asigna el analista correspondiente para la realizacin de un programa concreto. Desde un enfoque ms general, el cuaderno de carga es fundamental para el desarrollo de la aplicacin. Contiene todas las especificaciones necesarias para la realizacin correcta de una unidad de tratamiento, no debiendo el programador iniciar su trabajo hasta que queden resueltas todas sus dudas. Aunque los estndares en este caso son similares para todas las organizaciones, proponemos como estructura y contenido del cuaderno, a veces tambin llamado simplemente UT, la contenida en los siguientes puntos. HOJA GENRICA HOJA DE PORTADA HOJA DE ESPECIFICACIONES HOJA DE PSEUDOCODIGO
12

HOJA DE DESCRIPCION DE ARCHIVOS HOJA DE DESCRIPCION DE REGISTRO HOJA DE DISEO DE IMPRESORA HOJA DE DISEO DE PANTALLA HOJA DE ANEXOS HOJA DE JUEGOS DE PRUEBAS

13

Las fases finales INTRODUCCION En este capitulo vamos a revisar las fases finales del ciclo de vida clsico, programacin y pruebas, implantacin y mantenimiento. Posteriormente se har una breve recapitulacin de lo visto hasta ahora dentro del enfoque clsico. PROGRAMACION Y PRUEBAS En esta fase convertiremos en programas de computadora todas las especificaciones de las fases anteriores, basndonos en las unidades de tratamiento obtenidas en la fase anterior. De acuerdo con los estndares de la instalacin, primero se codifican y luego se prueban todos y cada uno de los programas, tanto de una forma conjunta como individual. El protagonista absoluto de esta fase es el programador de gestin, y la herramienta principal, el lenguaje de programacin que se elija. Codificacin De acuerdo con las instrucciones recibidas mediante el cuaderno de carga, se realiza la codificacin del programa en el lenguaje elegido, as como su compilacin y depuraciones. Es fundamental en esta etapa que los programas se documenten lo ms completa y claramente posible, para facilitar al mximo su mantenimiento. Pruebas El siguiente paso es probar el producto resultante. Independientemente de las pruebas que se van a realizar en la fase de implantacin, aqu se debe diferenciar entre la prueba individual del programa y la prueba conjunta posterior. Prueba del programa Ya sea porque lo facilita el analista-programador dentro del cuaderno de carga o responsabilidad del programador, se realiza un juego de pruebas para evaluar el funcionamiento tanto en condiciones normales como excepcionales del programa en base a las indicadas en la unidad de tratamiento. A partir de los datos ficticios que constituyen el juego de pruebas se ejecuta el programa en mquina comprobando los resultados y realizando, si es preciso, los correspondientes ajustes y correcciones. Cada instalacin tiene sus propias normas sobre el modo de realizar las pruebas. Un ejemplo de esto podra ser el siguiente: Cada programa se probar siguiendo los siguientes puntos:
14

1. Prueba lgica de estructura seudo codificada del programa antes de codificacin. 2. Prueba lgica de la codificacin a partir de especificaciones. 3. Prueba en mquina, aportando a la documentacin los resultados finales. Prueba conjunta Se deben probar conjuntamente todos los programas que componen la aplicacin en sentido inverso (de abajo arriba) a como se han ido refinando, mediante los correspondientes juegos de prueba que ahora sern de una complejidad creciente de acuerdo con el nivel en que nos encontremos. Se probarn primero las unidades funcionales por separado y luego por bloques partir de la explotacin de la aplicacin. Finalmente la aplicacin se prueba en conjunto simulando situaciones reales de trabajo segn perodos tanto en batch como on-line con archivos cuasi-reales. IMPLANTACION Y MANTENIMIENTO Nos centraremos en este punto en las actividades de la implantacin, pues realmente procesos de mantenimiento son impredecibles y dependern de la vida, una vez entregado, del sistema. La implantacin es la verdadera prueba de fuego de la aplicacin. Es una fase muy delicada. De nuevo salimos a la luz desde nuestro entorno de trabajo hacia el 1 usuario encontrndonos con nuevos problemas, entre los que cabe sealar el pacto en los usuarios que por norma se opondrn al cambio. Pruebas de preimplantacin Antes de pasar a la implantacin en un sentido estricto, en una situacin que se puede denominar de preimplantacin, pues si todo va bien la aplicacin ya est finalizada, debe hacerse una prueba exhaustiva, de comienzo a fin de toda la aplicacin, por parte del equipo de desarrollo y del usuario, que debe intervenir e incluso puede proponer las pruebas que crea convenientes. Completar la documentacin Al final del ciclo la documentacin generada se completa con dos manuales de gran importancia que, aunque de alguna manera se han ido realizando durante el proyecto, ahora se formalizan para entregarlos a las partes afectadas. Manual de usuario El manual de usuario rene la informacin, normas y documentacin necesaria para que el usuario conozca y utilice adecuadamente la aplicacin desarrollada. Es fundamentalmente un problema de comunicacin, por lo que todo cuidado en su elaboracin ser poco Para ello nada mejor que intentar ponernos en el lugar del usuario. Entre otros se persiguen los siguientes objetivos: correcto uso de la aplicacin, utilidad para conseguir y detectar errores, utilidad para formar a los usuarios, uso como gua de consulta y
15

referencia. En su redaccin debe ser claro, conciso, correcto y completo, incluyendo los apoyos grficos que se crean necesarios para su correcta comprensin por parte de los destinatarios. El contenido del manual y su forma depender de la organizacin. Un ejemplo de contenidos podra ser: 1. Portada-ttulo. 2. Indice. 3. Presentacin. 3.1.Introduccin. 3.2.Cmo usar el manual. 4. Conceptos generales en la aplicacin. 5. Diagrama jerrquico de la aplicacin. 6. Preparacin de datos de entrada. 7. Interpretacin de resultados. 8. Procesos. 8.1. Batch. 8.2. On-line. 9. Procedimientos en caso de error. 10. Apndices. Manual de explotacin Recoge la informacin necesaria para poner en explotacin la aplicacin. Va dirigido a la instalacin (sala de computadoras) fundamentalmente, en cuanto a operatividad prctica, turnos..., por lo que su estructura es an ms dependiente que en caso anterior de la organizacin en cuestin donde se vaya a implantar la aplicacin. No obstante lo anterior, en general recoger informacin comn a los primeros puntos del manual de usuarios ms aquella dirigida a hacer operable el producto como disposicin de archivos, periodicidades de ejecucin, comunicacin con el operador del sistema, etc. FORMACION DE LOS USUARIOS Toda persona que deba utilizar la aplicacin debe ser formada y entrenada convenientemente. La formacin debe planificarse cuidadosamente a partir de un calendario lo ms detallado posible, especificando medios, lugares, contenidos, destinatarios e impartidores. Es preciso que previamente se disponga de la infraestructura y recursos necesarios, como locales, manuales, archivos de prueba, etc. LA CONVERSION AL NUEVO SISTEMA El objetivo de esta etapa es pasar del sistema existente al nuevo sistema o aplicacin que se ha desarrollado. Depender en gran parte del sistema actual, que podr estar o no informatizado. Es importante minimizar, basndose en una buena planificacin, el impacto del cambio para que ste no sea traumtico.
16

Las formas ms comunes de realizar la conversin son: 1. En paralelo: Coexistiendo durante algn tiempo el sistema en uso y el nuevo. 2. Piloto: Cuando existen varios centros operativos para la nueva aplicacin, eligiendo uno de ellos para implantar experimentalmente la aplicacin. 3. Directa: Se implanta de una manera total y simultnea en todos los centros operativos de la organizacin. LA ENTRADA EN FUNCIONAMIENTO Una vez ha finalizado la etapa de conversin, la nueva aplicacin entrar en funcionamiento pleno, abandonando el sistema anterior. Operatividad de la nueva aplicacin Para la operatividad plena de la nueva aplicacin se cubrirn las siguientes etapas: Entrega y aceptacin del manual de explotacin al rea de explotacin. Abandono por parte del usuario del sistema anterior. Seguimiento por parte de desarrollo de la nueva aplicacin mientras se estime oportuno. Eliminacin del sistema anterior Una vez que se comprueba la operatividad plena y satisfactoria del nuevo sistema se eliminan, si procede, los componentes del sistema anterior (fundamentalmente si ste estaba informatizado), en particular: Documentacin del sistema. Manuales de explotacin y usuarios. Bibliotecas de programas y procedimientos.

La destruccin no debe ser inmediata aunque en apariencia tome esta forma, sino en base al asentamiento del nuevo sistema.

17