El analista de sistemas y el paradigma estructurado

Enviado por slorenzo

El analista de sistemas y el paradigma estructurado

Introducción

El Analista de Sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen.

Todo desarrollo líderizado o no por un analista de sistemas posee fases que pueden dividirse lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. Este conjunto de fases son conocidas como el Ciclo de Vida de Desarrollo de Sistemas, herramienta fundamental para el desempeño de un analista de sistemas.

Análisis y diseño de Sistemas

El Análisis y Diseño de Sistemas

"El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados." (Senn, 1992, p.11). Se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable.

En pocas palabras; "El análisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo" (op. cit., p.13) Ciertamente, todo sistema de información debe presentar salidas en base a entradas de datos y procesos, lo que nos dice que si deseamos entender todo lo que le ocurre a los datos antes de llegar al usuario como información –Es decir antes de ser interpretado por el usuario final- debemos utilizar metodologías que permiten ver los sistemas en base a sus procesos, por lo menos en sistemas de procesado por lotes o secuencial. Un ejemplo de ello es la metodología estructurada. Existen muchas metodologías pero esta es la más arraigada debido a su antigüedad. Recordemos que hace apenas dos décadas los computadores no soportaban el multitasking (procesamiento multitarea), lo que limitaba a procesar una pantalla a la vez, esto sólo permitía sistemas secuenciales donde cada tarea en procesamiento comenzaba cuando la anterior ya había terminado por completo.

El Analista de Sistemas

El Analista de Sistema nace de la necesidad de recopilar, desglosar, catalogar y analizar información necesaria de una empresa para poder proponer nuevos métodos, mejores o modificar los actuales para que así aumente el desempeño de los departamentos dentro de la organización.

En toda organización un analista se vale de la información de entrada, los procesos modificadores y la información de salida, para así definir los procesos intermedios y poder entender con claridad a la organización. Todos estos flujos y procesos son estudiados sistemáticamente para poder determinar si son los adecuados, si se deben mejorar o si deben ser reemplazados por otros más idóneos.

Santos (1980, p.12) define las funciones del analista de sistemas para la década de los ochenta como sigue;

"…el analista de problemas en computación deberá conocer procedimientos para indagar sobre lo existente y para saber proponer un verdadero sistema racionalizado, pero también deberá conocer sobre modernos sistemas de información, base del diseño, sobre todo en computación… Estos últimos factores son los que justifican tal especialidad, porque realmente debieron existir los analistas de sistemas, aunque no hubiera computadores, toda vez que siempre hubo sistemas para organizar, que posiblemente no se difundieron porque no existieron en importancia esos dos factores que hoy prevalecen: el computador y la información."

La definición de analista de sistemas de Senn (1992, p. 12), agrega: "…Los analistas hacen mucho más que resolver problemas. Con frecuencia se solicita su ayuda para planificar la expansión de la organización…", es decir, el papel de los analistas sobrepasa los limites impuestos por la definición inicial, también cumplen el papel de asesores, ya sea en sistemas manuales o informatizados, o cualquier otro sistema donde la empresa tenga que invertir en información, después de todo esa es la razón de ser del analista.

Comparando las dos definiciones anteriores podemos notar que en veinte años no ha cambiado la descripción de analista de sistemas, más bien se le han atribuido nuevas características que lo definen como un ente de cambio, necesario en cualquier organización con tendencia a crecer.

Según Senn, dependiendo de las funciones de un analista de sistemas se puede clasificar en: Analista de sistemas, Analista y diseñador de sistemas y analista diseñador y programador de sistemas, en donde cada uno se puede identificar y diferenciar de los demás por las actividades que definen sus denominaciones. También podemos clasificar a los analista de sistema como Consultor, Experto de soporte y Agente de cambio, clasificación según Kendall (1997, p.6).

Vale la pena explicar un poco la clasificación de éste último autor debido a que no se basa en las actividades propias del analista, sino los papeles que cumple en las fases impuestas en el paradigma Ciclo de Vida de Desarrollo de Sistemas (CVDS). Cuando se comienza el CVDS el analista cumple en papel de consultor, asesorando a la empresa sobre los mejores métodos y sistemas que se pueden emplean para la óptima gestión de información, recomendando sistemas ya sean de tipo manual o de tipo informático, predominando claro, los sistemas informáticos que le dan la vida a ésta profesión. El experto en soporte se identifica con los últimos pasos del CVDS donde el analista se desempeña en el asesoramiento de hardware y software, basado en el conocimiento y especialmente en la experiencia. Sirviendo el analista muchas veces de escalón para hacer que el sistema desarrollado (no liderizado por él) tenga éxito. Como Agente de Cambio se tiene el papel más importante y más difícil, la comunicación con empleados dentro de la fase de recopilación de información es probable que los empleados piensen que el sistema los va a sustituir, aunque algunas veces es cierto, el analista debe internalizar que el cambio es en pro de la organización y no de un grupo minoritario o sectorial. Así desarrollar sus actividades de manera regular.

Una pregunta común sobre los analistas de sistemas es ¿Todos los analistas deben programar?, Según Senn (1992, p.16); "…La respuesta depende de la organización. Sin embargo, una cosa es evidente: el analista de sistemas más valioso y mejor calificado es aquel que sabe programar.", ciertamente el analista que tiene fuertes principios de programación sabe que se puede y que no se puede, o que es difícil de desarrollar en un lapso de tiempo, recordemos que todos los proyectos informáticos tienen siempre lapsos de tiempo bien reducidos y que si no se tiene el equipo apropiado es difícil cumplir con los plazos establecidos, lo que trae como consecuencia muchas veces la falla de todo el proyecto. Además el analista programador tiene facilidad para comunicar sus ideas a los constructores de código, ya que él estuvo en ese lugar alguna vez y sabe en que forma se necesita la información al momento de generar código.

Contacto del Analista con los Usuarios

Es difícil determinar el tamaño de un sistema a desarrollar si no conocemos los diferentes niveles del mismo, los diferentes detalles de las salidas de información, a quienes van dirigidas y cual es la mejor forma de hacerlo.

Los analistas de Sistemas están en la obligación de recorrer desde los niveles más altos de la empresa (gerentes y directivos), hasta los niveles más bajos (obreros y empleados) para determinar quienes realmente necesitan la información, con que oportunidad y grado de detalle de cada peldaño de la escalera institucional. "Los gerentes y empleados tienen buenas ideas a qué es lo que si trabaja y qué es lo que no, qué causa problemas y qué no, dónde son necesarios los cambios y dónde no."(Senn, p.13), en efecto, quien mejor que los que día a día ven el sistema y como sus compañeros o subordinados lo reciben, para decirle al analista con anticipación cual será la aceptación del producto final y que mejoras deben tener. A fin de cuentas ellos son los que le sacarán provecho al sistema, los que se alimentarán del mismo.

Ciclo de vida deL Desarrollo de Sistemas

El Ciclo de Vida del Desarrollo de Sistemas (CVDS) es un paradigma de la programación estructurada que proporciona lineamientos para desarrollar un proyecto de sistema de información.

Kendall (1997) divide el CVDS en siete fases que son las siguientes:

Identificación de problemas, oportunidades y objetivos.
Determinación de los requerimientos de información.
Análisis de las necesidades del sistema.
Diseño del sistema recomendado.
Desarrollo y documentación del software.
Prueba y mantenimiento del sistema.
Implementación y evaluación del hardware.

Siendo la división de Senn (1992) la siguiente;

Investigación preliminar.
Determinación de los requerimientos del sistema.
Diseño del sistema.
Desarrollo del software.
Prueba de los sistemas.
Implantación y evaluación.

Comparando los dos autores podemos observar que su división de las fases del CVDS es similar, de hecho a primera vista y sin definir cada una de las fases, si comparamos con sus homólogas podemos notar que Senn define las fases; Análisis de las Necesidades del Sistema Recomendado (3) y Diseño del Sistema Recomendado (4) de Kendall en una sola fase llamada Diseño del Sistema, la cual comprende estas dos actividades.

Simplificando aún más estas fases descritas anteriormente obtenemos el CVDS moderno;

Planificación del Proyecto.
Análisis del Sistema Actual.
Diseño del Sistema Propuesto.
Implantación y documentación del sistema.
Evaluación y soporte del sistema.

El CVDS es un conjunto de pasos que si bien son secuenciales no necesariamente deben llevarse con rigidez, en cualquier momento que el analista lo requiera puede devolverse al paso o fase anterior, de hecho, es muy común que si en alguna fase se requiera modificar algún análisis de una fase previa, o hasta repetir varias veces una misma tarea para comparar algún resultado.

"Los analistas no están de acuerdo con qué tantas fases exactas hay en el ciclo de vida de desarrollo de sistemas, pero, por lo general, alaban su enfoque organizado."(Kendall, 1997, p.8) Es cierto que el CVDS es un modelo muy organizado para la programación estructurada, pero no siempre se puede aplicar para el desarrollo de aplicaciones, especialmente cuando empezamos a utilizar nuevas metodologías y convenciones. Un ejemplo de ello es la dificultad de aplicar el enfoque estructurado del CVDS para el desarrollo de una aplicación Web.

Digamos que tenemos que diseñar un periódico electrónico y que nuestra base de datos se encuentra en un servidor A, que tenemos un servidor Web (WWW) en otra ubicación B y que tenemos un servidor de archivos (FTP) en otro sitio diferente C. Ya este tipo de organización lógica del sistema se sale de las expectativas de las personas que idearon la metodología estructurada del CVDS. Claro, con esto no digo que el paradigma no pueda adaptarse, crear como una especie de metodología híbrida que permita combinar diferentes herramientas, pero ya no tendría la estructura original.

Conclusiones

Cada sistema a desarrollar debe ser tratado con la metodología que mejor se adapte a los objetivos del análisis un producto final de calidad. El CVDS es el paradigma más fuertemente difundido para el desarrollo de sistema de cómputos y lotes óptimos, sin embargo el desconocimiento de nuevas metodologías nos puede llevar al uso indiscriminado de éste paradigma, ajustándose o no a nuestros objetivos.

Como analistas de sistemas debemos mantenernos a la par de los últimos avances en cuanto a las metodologías y tendencias dentro del incesante mundo del manejo de la Información.

Conforme pasa el tiempo el perfil del analista de sistemas irá incorporando nuevas posibilidades y deberes dentro de las organizaciones, lo que nos afirma que durante mucho tiempo tendremos trabajo, claro, manteniéndonos en la excelencia.

Bibliografía

SANTOS, Ernesto. (1980). Procesamiento de Datos. Ediciones Macchi. Argentina.

SENN, James A. (1992) Análisis y Diseño de Sistemas de Información. Segunda Edición. Editorial McGrawHill. México.

KENDALL&KENDALL, Kenneth y Julie. (1997) Análisis y Diseño de Sistemas. Tercera Edición. Editorial Prentice Hall. México.

Autor:

Br. Soulberto Lorenzo Torres

Estudiante de Licenciatura en Informática

Universidad de Oriente, Núcleo de Sucre.

Cumaná, Edo. Sucre. Venezuela.