El analista de sistemas y el paradigma estructurado
1.
Introducción
2.
Análisis y diseño de Sistemas
4.
Contacto del Analista con los Usuarios
5.
Ciclo de vida deL Desarrollo de Sistemas
6.
Conclusiones
7.
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:
1.
Identificación de problemas, oportunidades y objetivos.
2.
Determinación de los requerimientos de información.
3.
Análisis de las necesidades del sistema.
4.
Diseño del sistema recomendado.
5.
Desarrollo y documentación del software.
6.
Prueba y mantenimiento del sistema.
7.
Implementación y evaluación del hardware.
Siendo la
división de Senn (1992) la siguiente;
1.
Investigación preliminar.
2.
Determinación de los requerimientos del sistema.
3.
Diseño del sistema.
4.
Desarrollo del software.
5.
Prueba de los sistemas.
6.
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;
1.
Planificación del Proyecto.
2.
Análisis del Sistema Actual.
3.
Diseño del Sistema Propuesto.
4.
Implantación y documentación del sistema.
5.
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.