El analista de sistemas y el
paradigma
estructurado
- Análisis y
diseño de Sistemas - El Analista de
Sistemas - Contacto del Analista con los
Usuarios - Ciclo de vida deL Desarrollo de
Sistemas - Conclusiones
- Bibliografía
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 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.
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.
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.