Monografias.com > Computación > General
Descargar Imprimir Comentar Ver trabajos relacionados

El analista de sistemas y el paradigma estructurado




Enviado por slorenzo



    El analista de sistemas y el
    paradigma
    estructurado

    1. Análisis y
      diseño de Sistemas
    2. El Analista de
      Sistemas
    3. Contacto del Analista con los
      Usuarios
    4. Ciclo de vida deL Desarrollo de
      Sistemas
    5. Conclusiones
    6. Bibliografía

    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:

    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.

    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.

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter