Analisis De Sistema 1

Roles

EL ROL DE CONSULTOR DEL ANALISTA DE SISTEMAS

Con frecuencia, el analista de sistemas desempeña el rol de consultor para un negocio y, por tanto, podría ser contratado de manera específica para enfrentar los problemas de sistemas de información de una empresa. Esta contratación se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual carecen los demás miembros de una organización. También se puede traducir en una desventaja porque alguien externo nunca conocerá la verdadera cultura organizacional. En su función de consultor externo, usted dependerá en gran medida de los métodos sistemáticos que se explican en este libro para analizar y diseñar sistemas de información apropiados para una empresa en particular. Además, tendrá que apoyarse en los usuarios de los sistemas de información para entender la cultura organizacional desde la perspectiva que tienen ellos.

EL ROL DE EXPERTO EN SOPORTE TECNICO DEL ANALISTA DE SISTEMAS

Otro rol que tendrá que desempeñar es el de experto en soporte técnico dentro de la empresa en la cual labora de manera regular. En este rol el analista recurre a su experiencia profesional con el hardware y software de cómputo y al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino más bien la realización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo departamento.

Como experto de soporte técnico, usted no esta a cargo del proyecto; tan solo actúa como recurso para aquellos que si lo están. Si usted es un analista de sistemas contratado por una empresa de manufactura o servicios, gran parte de sus actividades podrían ajustarse a este rol.

EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS

El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio, ya sea interno o externo para la empresa. Como analista, usted es un ajen te de cambio si desempeña cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas (que se explicara en la siguiente sección) y está presente en la empresa durante un largo periodo (de dos semanas a mas de un año). Un agente de cambio se puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para el cambio y coopera con los demás para facilitar el cambio.

Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar consciente de este hacho y utilizarlo como punto de partida para su análisis. De ahí que tenga que interactuar con los usuarios y la administración (sino son un o solo y el mismo) desde el principio de su proyecto. Sin su colaboración usted no podría entender lo que ocurre en una organización y el cambio real nunca se daría.

Si el cambio (es decir, la mejora al negocio que se pueden concretar mediante los sistemas de información) parece factible después de efectuar el análisis, el siguiente paso es desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de autorizarlo. Una vez que se haya alcanzado el consejo acerca de los cambios por realizar, usted tendrá que interactuar constantemente con quienes hayan a cambiar.

En su calidad de analista de sistema desempeñando la función de agente de cambio, debe promover un cambio que involucre el uso de los sistemas de información. También es parte de su tarea enseñar a los usuarios el proceso del cambio, ya que las modificaciones a un sistema de información no sólo afectan a éste sino que provocan cambios en el resto de la organización.

Ciclo de vida de un sistema

DENTIFICACION DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS

En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del resto del proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un problema que no era el que se debía resolver.

La primera fase requiere que el analista observe objetivamente lo que sucede en un negocio. A continuación, en conjunto con otros miembros de la organización, el analista determina con precisión cuales son los problemas. Con frecuencia los problemas son detectados por alguien más, y esta es la razón de la llamada inicial al analista. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados. El aprovechamiento de las oportunidades podría permitir a la empresa obtener una ventaja competitiva o establecer un estándar para la industria.

La identificación de objetivos también es una parte importante de la primera fase. En primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A continuación, podrá determinar si algunas funciones de las aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos.

Los usuarios, los analistas y los administradores de sistemas que coordinar el proyecto son los involucrados en la primera fase. Las actividades de esta fase consisten en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos. A continuación, la administración debe decidir si se sigue adelante con el proyecto propuesto.

Si el grupo de usuarios no cuenta con fondos suficientes, si desea atacar problemas distintos, o si la solución a estos problemas no amerita un sistema de cómputo, se podría sugerir una solución diferente y el proyecto de sistemas se cancelaría.

DETERMINACION DE LOS REQUERIMIENTOS DE INFORMACION

La siguiente fase que enfrenta el analista es la determinación de los requerimientos de información de los usuarios. Entre las herramientas que se utilizan y son para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos de oficina, al igual que métodos de amplio alcance como la elaboración de prototipos

El desarrollo rápido de aplicaciones (RAD, Rapad Application Development) es un enfoque orientado a objetos para el desarrollo de sistemas que incluye un método de desarrollo (que abarca la generación de requerimientos de información) y herramientas de software. En este libro se aborda en el capitulo 6, en conjunto con la elaboración de prototipos, porque su enfoque filosófico es similar, aunque su método para crear un diseño con rapidez y obtener una pronta retroalimentación por parte de los usuarios es un poco diferente. (En el capitulo 18 se abunda en los enfoques orientados a objetos.)

En la fase de determinación de los requerimientos de información del SDLC, el analista se esfuerza por comprender la información que necesita los usuarios para llevar a cabo sus actividades. Como puede ver, varios de los métodos para determinar los requerimientos de información implican interactuar directamente con los usuarios. Esta fase es útil para que el analista confirme la idea que tiene de la organización y sus objetivos. En ocasiones sólo realizan las dos primeras fases del ciclo de vida del desarrollo de sistemas. Esta clase de estudio podría tener un propósito distinto y por lo general lo lleva a la práctica un especialista conocido como analista de información (IA, Información Analista).

Los implicados en esta fase son el analista y los usuarios, por lo general trabajadores y gerentes del área de operaciones. El analista de sistema necesita conocer los detalles de las funciones del sistema actual: el quien (la gente involucra), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuando (el momento oportuno y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. A continuación el analista debe preguntar la razón por la cual se utiliza el sistema actual. Podría haber buenas razones para realizar los negocios con los métodos actuales, y es importante tomarlas en cuenta al diseño de un nuevo sistema.

Sin embargo, si la razón de ser de las operaciones actuales es que "siempre se han hecho de esta manera", quizá será necesario que el analista mejore los procedimientos. La reingeniería de procesos de negocios podría ser útil para conceptualizar el negocio de una manera creativa. Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

ANALISIS DE LAS NECESIDADES DEL SISTEMA

La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesidades del sistema. De nueva cuenta, herramientas y técnicas especiales auxilian al analista en la determinación de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma grafica estructurada. A partir de los diagramas de flujote datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, así como sus respectivas especificaciones.

Durante esta fase el analista de sistemas analiza también las decisiones estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden determinar las condiciones, las alternativas de condición, las acciones y las reglas de acción. Existen tres métodos principales para el análisis de decisiones estructuradas: español estructurado, tablas y árboles de decisión.

En este puno del ciclo de vida del desarrollo de sistemas, el analista el prepara una propuesta de sistemas que sintetizar sus hallazgos, proporciona un análisis de costo/ beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que debe hacer. Si la administración de la empresa considera factibles algunas de las recomendaciones, el analista sigue adelante. Cada problemas de sistemas es único, y nunca existe solo una solución correcta. La manera de formular una recomendación o solución depende de las cualidades y la preparación profesional de cada analista.

DISEÑO DEL SISTEMA RECOMENDADO

En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos que asegurar que los datos que ingresen al sistema de información sean correctos. Además, el analista facilita la entrada eficiente de datos al sistema de información mediante técnicas adecuadas de diseño de formularios y pantallas.

La concepción de la interfaz d usuarios forma parte del diseño lógico del sistema de información. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. Entre los ejemplos de interfaces de usuarios se encuentran el teclado (para teclear preguntas y respuestas), los menús en pantalla (para obtener los comandos de usuarios) y diversas interfaces graficas de usuarios (GUIs, Graphical User Interfaces) que se manejan a través de un ratón o una pantalla sensible al tacto.

La fase de diseño también incluye el diseño de archivos o bases de datos que almacenaran gran parte de los datos indispensables para los encargados de tomar las decisiones en la organización. Una base de datos bien organizada es el cimiento de cualquier sistema de información. En esta fase el analista también interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos.

Finalmente, el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento; también podrían incluir árboles o tablas de decisión, diagramas de flujos de datos, un diagrama de flujo del sistema, y los nombres y funciones de cualquier rutina de código previamente escrita.

DESARROLLO Y DOCUMENTACION DEL SOFTWARE

En la quinta fase del ciclo de vida del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructura, los diagramas de Nassi-Shneiderman y el pseudocodigo. El analista se vale de una mas de estas herramientas para comunicar al programador lo que se requiere programar.

Durante esta fase el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios Web que incluyan respuestas a preguntas frecuentes (FAQ, Frequently Asked Questions) en archivos "Léame" que se integran en el nuevo software. La documentación indica a los usuarios como utilizar el software y lo deben hacer en caso de que surjan problemas derivados de este uso.

Los programadores desempeñar un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de computo. Si el programa se ejecutara en un entorno de mainframe, se debe crear un lenguaje de control de trabajos (JCL, Job Control Language). Para garantizar la calidad, un programador podría efectuar un repaso estructurado del diseño o del código con el propósito de explicar las partes complejas del programa a otro equipo de programadores.

PRUEBA Y MANTENIMIENTO DEL SISTEMA

Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de las pruebas las realizan los programadores solo, y la otra la lleva a cabo de manera conjunta con los analistas de sistemas. Primero se realiza una seria de pruebas con datos de muestra para determinar con precisión cuales son los problemas y posteriormente se realiza otra con datos reales del sistema actual.

El mantenimiento del sistema de información y su documentación empieza en esta fase y se lleva a cabo de manera rutinaria durante toda su vida útil. Gran parte del trabajo habitual del programador cosiste en el mantenimiento, y las empresas invierten enormes sumas de dinero en esta actividad. Parte del mantenimiento, como las actualizaciones de programas, se pueden realizar de manera automática a través de un sitio Web. Muchos de los procedimientos sistemáticos que el analista emplea durante el ciclo de vida del desarrollo de sistemas pueden contribuir a garantizar que el mantenimiento se mantendrá al mínimo.

IMPLEMENTACION Y EVALUACION DEL SISTEMA

Esta es la ultima fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de esta es responsabilidad del analista de sistemas. Además, el analista tiene que planear una conversión gradual del sistema anterior al actual. Este proceso incluye la conversión de archivos formatos anteriores a los nuevos, o la construcción de una base de datos, la instalación de equipo y la puesta en producción del nuevo sistema.

Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en aras del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigido el sistema lo están utilizando realmente. Debe hacerse hincapié en que, con frecuencia, el trabajo de sistemas es cíclico. Cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar al analista a regresar a la fase previa y modificar el trabajo realizado.

Determinacion de la factibildad

. DETERMINACIÓN DE LA FACTIBILIDAD

Para los proyectos de sistemas la factibilidad es valorada en tres formas principales: operacional, técnica y económicamente. Un proyecto debe ser factible en las tres formas para merecer un desarrollo posterior, el estudio de factibilidad no es un estudio de sistema completo. En vez de ello, se usa al estudio de factibilidad para recopilar datos burdos para la administración, para que a su vez les permitan tomar una decisión sobre si deben continuar con el estudio de sistema.

Los datos para el estudio de factibilidad pueden ser recolectados por medio de entrevistas, están directamente relacionadas con el problema u oportunidad que está siendo sugerido. Aunque es importante atacar el problema adecuado, no se debe gastar mucho tiempo haciendo estudios de factibilidad, debido a que muchos proyectos serán solicitados y solamente unos cuantos deberán ser ejecutados. El estudio debe estar altamente comprimido en el tiempo, comprendiendo varias actividades en un pequeño lapso.

Definición de objetivos

La determinación de factibilidad en general de un proyecto solicitado significa el encontrar cuáles son los objetivos organizacionales, y luego determinar si el proyecto sirve para mover el negocio hacia sus objetivos en alguna forma. Los objetivos del proyecto deben ser calificados por medio de entrevistas con la persona, grupo o departamento que lo propone. Además, también es útil una revisión de los trabajos escritos que se relacionen con el proyecto solicitado.

Hay varios objetivos aceptables para los proyectos de sistemas que estos incluyen, pero no están limitados, a:

1- Reducir errores y mejorar la precisión de los datos de entrada.

2- Reducir el costo de la salida del sistema mediante la agilización y eliminación de reportes duplicados o innecesarios.

3- Integrar los subsistemas del negocio.

4- Mejorar los servicios al cliente para ganar una posición competitiva.

5- Acelerar la entrada.

6- Acortar el tiempo de procesamientos de datos.

7- Automatizar los procedimientos manuales para mejorarlos en alguna forma.

También podemos decir que es inaceptable automatizar procedimientos manuales simplemente por automatizarlos, o invertir en tecnología nueva sin tomar en consideración su contribución verdadera para el logro de los objetivos de la organización.

Determinación de recursos

La determinación de recursos para el estudio de factibilidad sigue el mismo patrón amplio tratado anteriormente, y será revisado y vuelto a evaluar cuando se encomiende el estudio del sistema formal. Los recursos serán tratados en relación con tres áreas de factibilidad: técnica, económica y operacional.

Factibilidad técnica: una gran parte de la determinación de recursos tiene que ver con la valoración de la factibilidad técnica. El analista debe encontrar si los recursos técnicos actuales pueden ser mejorados o añadidos, en forma tal que satisfaga la petición bajo consideración. Sin embargo, algunas veces las adiciones a los sistemas existentes son costosas y no valen la pena, debido simplemente a que satisfacen las necesidades en forma ineficiente. Si los sistemas existentes no pueden ser añadidos, la siguiente pregunta es si hay tecnología en existencia para satisfacer las especificaciones. La respuesta sobre si una tecnología particular se encuentra disponible y es capaz de satisfacer las peticiones del usuario es si, entonces se convierte en económica.

Factibilidad económica: La factibilidad económica es la segunda parte de la determinación de recursos. Los recursos básicos a considerar son: el tiempo propio y el equipo de sistemas, el costo de hacer un estudio de sistema completo, el costo del tiempo de los empleados del negocio, el costo estimado de hardware y el costo del software y/o desarrollos de software.

El negocio de que se trate debe ser capaza de hacer ver el valor de la inversión en su ponderación antes de comprometerse en un estudio de sistemas completo. Si los costos a corto plazo no son sobrepasados por las ganancias a largo plazo, o no producen una reducción inmediata en los costos de operación, el sistema no es factible económicamente y el proyecto ya no debe continuar.

Factibilidad operacional: La factibilidad operacional depende de los recursos humanos disponibles para el proyecto, e involucra proyectar si el sistema operará y será usado una vez esté instalado. Si los usuarios están casados virtualmente con el sistema presente, la resistencia ante la implementación del nuevo sistema será fuerte. Las oportunidades de que alguna vez llegue a ser operacional son escasas.

Si los usuarios han expresado la necesidad de que un sistema que es operacional la mayor parte del tiempo tenga una forma más eficiente y accesible, si tiene mejor oportunidad de que el sistema solicitado llegue a ser utilizado. En el momento de la determinación de la factibilidad operacional requiere creativa por parte del analista, que permita que los usuarios sepan cuales interfaces son posibles y cuales satisfacerán sus necesidades.

Evaluación de la factibilidad: Es evidente que la evaluación de la factibilidad de los proyectos de sistemas nunca es una tarea fácil o bien definida. Lo que es más, la factibilidad del proyecto no es una decisión a ser tomada por el analista sino por la administración. Las decisiones están basadas en los datos de factibilidad recolectados en forma expresa y profesional, presentados por el analista. El analista necesita asegurarse que las tres áreas de factibilidad, técnica, económica y operacional, sean atacadas en el estudio preliminar. El estudio de un proyecto de sistemas solicitado debe ser logrado rápidamente, a fin de que los recursos que se le dediquen sean mínimos, la información producida por el estudio sea sólida y cualquier interés existente en el proyecto se mantenga alto. Este es un estudio preliminar que precédela estudio del sistema, y debe ser ejecutado en forma rápida y competente. Aunque es laborioso, el estudio de la factibilidad vale la pena, y , a la larga, ahorra a los negocios y analistas gran cantidad de tiempo y dinero.

Recopilacion de la información

-interactivos.

Este capítulo abarca tres de los métodos interactivos clave para recopilar información que puede utilizar el analista de sistemas: las entrevistas, JAD y los cuestionarios. Durante el proceso de la entrevista con los tomadores de decisiones de la organización, que es un método utilizado por los analistas de sistemas para recopilar datos sobre los requerimientos de información, los analistas escuchan metas, sentimientos, opiniones y procedimientos informales. También venden el sistema durante las entrevistas. Las entrevistas son diálogos de preguntas y respuestas entre dos personas, planeados de antemano. El analista se vale de la entrevista para desarrollar su relación con un cliente, observar el lugar de trabajo y para recopilar datos relacionados con los requerimientos de información. Aunque el correo electrónico puede usarse para preparar al entrevistado planteándole preguntas previas a una reunión, por lo general las entrevistas deben realizarse en persona y no de manera electrónica.

Hay cinco pasos que deben realizarse para preparar la entrevista:

1. Leer los antecedentes.

2. Establecer los objetivos de la entrevista.

3. Decidir a quién entrevistar.

4. Preparar al entrevistado.

5. Decidir el tipo de preguntas y la estructura.

Hay dos tipos básicos de preguntas: abiertas o cerradas. Las preguntas abiertas permiten al entrevistado usar todas las opciones de respuesta. Las preguntas cerradas limitan las opciones de respuesta posibles. Los sondeos o preguntas de seguimiento pueden ser abiertos o cerrados, pero piden al encuestado una respuesta más detallada.

Las entrevistas pueden estructurarse de tres maneras básicas: pirámide, embudo o diamante. Las estructuras de pirámide empiezan con preguntas cerradas y detalladas y finalizan con preguntas más amplias y generales. Las estructuras de embudo empiezan con preguntas abiertas y generales y a continuación pasan a preguntas cerradas más específicas. Las estructuras con forma de diamante combinan las fortalezas de las otras dos estructuras, pero toman muchos más tiempo para realizarse. Hay ventajas y desventajas involucradas en la decisión de cuan estructuradas hacer las preguntas de la entrevista y las secuencias de preguntas.

Para reducir el tiempo y costo de las entrevistas personales, los analistas podrían considerar como una alternativa el diseño conjunto de aplicaciones. Con JAD, los analistas pueden examinar los requerimientos y diseñar una interfaz de usuario de manera conjunta con los usuarios. La evaluación cuidadosa de la cultura particular de una organización ayudará al analista a determinar si JAD es una alternativa adecuada.

Mediante los cuestionarios, los analistas de sistemas pueden recopilar datos sobre las actitudes, creencias, comportamiento y características de las personas importantes de la organización. Los cuestionarios son útiles si los miembros de la organización están dispersos en diversas ubicaciones, muchas personas están involucradas en el proyecto de sistemas, se requiere trabajo de investigación antes de recomendar alternativas, o hay necesidad de detectar problemas antes de que se realicen las entrevistas.

Una vez que se establecen los objetivos del cuestionario, el analista puede empezar a redactar preguntas abiertas o cerradas. La elección del vocabulario es sumamente importante y debe reflejar el lenguaje de los miembros de la organización. Las preguntas deben ser sencillas, específicas, cortas, libres de prejuicios, no condescendientes, técnicamente precisas, dirigidas a quienes puedan responderlas y escritas con un nivel de lectura apropiado.

El escalamiento es el proceso de asignar números u otros símbolos a un atributo o característica. El analista de sistemas podría requerir el uso de escalas para medir las actitudes o características de los encuestados o para que éstos actúen como jueces del tema de los cuestionarios.

Por lo general, los analistas de sistemas utilizan una escala nominal o una de intervalos y necesitan tomar en cuenta la validez y la confiabilidad. Validez significa que el cuestionario mida lo que el analista de sistemas requiera medir. La confiabilidad refleja si los resultados son consistentes. Al construir escalas, los analistas deben tener cuidado para evitar problemas como la condescendencia, tendencia central y el efecto de halo.

El control consistente del formato y el estilo del cuestionario puede dar como resultado una mejor tasa de respuesta. El diseño de las encuestas para Web puede estimular respuestas consistentes al incluir botones de opción, menús desplegables y cuadros de textodesplazables para plantear preguntas abiertas y cerradas. Además, la clasificación y agrupación lógicas de las preguntas es importante para facilitar a los encuestados la comprensión del cuestionario.

Las encuestas se pueden aplicar de diversas maneras, incluyendo (sin limitarse a] medios electrónicos como el correo electrónico o la Web, o con la presencia del analista en un grupo de usuarios.

...