Agregar a favoritos      Ayuda      Português      Ingles     
 Página anterior Volver al principio del trabajoPágina siguiente 

Análisis y Diseño de Sistemas de Información (página 3)




Partes: 1, 2, 3


7. OBSERVACIÓN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE OFICINA.

Los analistas usan la observación como una técnica de recopilación de ir, formación. Por medio de la observación obtienen apreciaciones sobre lo que se hace realmente, ven de primera mano las relaciones entre los tomadores de decisiones en una organización, comprenden la influencia del ambiente físico de éste, interpretan los mensajes enviados por el tomador por medio de su vestimenta y el acomodo de su oficina y comprenden la influencia del tomador de decisiones con respecto a los demás. Usando el muestreo de tiempos o eventos, el analista observa las actividades típicas del tomador de decisiones y su lenguaje corporal. Hay varios sistemas para registrar tales observaciones, incluyendo sistemas di categorías, listas de verificación, escalas, notas de campo y guiones. Además de la observación del comportamiento del tomador de decisiones, el analista de sistemas debe observar también lo que le rodea. Un método para la observación estructurado del ambiente es llamado STROBE, Un analista de sistemas usa STROBE en la misma forma que un crítico de cine usa un método llamado mise-en-scène para analizar una toma de una película Varios elementos concretos del ambiente del tomador de decisiones pueden ser observados e interpretados. Estos elementos incluyen (1) la ubicación de la oficina, (2) la ubicación del escritorio del tomador de decisiones, (3) el equipo de oficina fijo, (4) las propiedades, tales como calculadoras y pantallas, (5) revistas del negocio y periódicos, (6) iluminación y color de la oficina y (7) la vestimenta usada por el tomador de decisiones. Se puede usar STROBE para obtener una mejor comprensión sobre la manera en que los tomadores de decisiones actualmente recopilan, procesan, guardan y comparten información, Hay varias alternativas para la aplicación de STROBE en una organización. Estas incluyen el análisis de fotografías, el uso de una lista de verificación con base en la escala Likert, la adopción de una lista anecdótica con símbolos y la simple escritura de una comparación de observación/narrativa, Cada método tiene determinadas ventajas, así como desventajas, que el analista debe sopesar cuando seleccione una alternativa sobre la otra.

8. PROTOTIPOS.

La elaboración de prototipos es una técnica de recopilación de información útil para complementar el ciclo de vida de desarrollo de un sistema tradicional. Cuando el analista de sistemas usa prototipos está buscando reacciones, sugerencias, innovaciones y planes de revisión del usuario para hacer mejoras al prototipo y, por lo tanto, modificar los planes del sistema con un mínimo de gastos y trastornos. Los sistemas que apoyan la toma de decisiones semiestructuradas (tal como lo hacen los sistemas de apoyo a decisiones) son buenos candidatos para la elaboración de prototipos.

El término prototipo tiene diferentes significados, de los cuales son comúnmente usados cuatro de ellos. La primera definición de la elaboración de prototipos es la de construcción de un prototipo parchado. Una segunda definición es un prototipo no operacional que es usado para probar determinadas características del diseño. Un tercer concepto es la creación de un prototipo primero de la serie que es completamente operacional. Este tipo de prototipo es útil cuando están planeadas muchas instalaciones del mismo sistema de información (bajo condiciones similares). El cuarto tipo es un prototipo con características seleccionadas que tiene algunas, pero no todas, de las características esenciales del sistema. Usa módulos autocontenidos como bloques de construcción, para que si las características prototípicas son satisfactorias puedan ser conservadas e incorporadas en el sistema terminado mucho más grande.

Los cuatro lineamientos principales para el desarrollo de un prototipo son: (1) trabajar en módulos manejables, (2) construir el prototipo rápidamente, (3) modificar el prototipo y (4) enfatizar la interfaz de usuario. Una desventaja de los prototipos es que el manejo del proceso de elaboración del prototipo es difícil, debido a la rapidez del proceso y a sus muchas iteraciones. Una segunda desventaja es que puede haber presiones para que sea puesto en servicio un prototipo incompleto, como si fuera un sistema completo. Aunque la elaboración de prototipos no es siempre necesaria o deseable, debe hacerse notar que hay tres ventajas principales interrelacionadas de su uso: (1) el potencial para cambiar el sistema en etapas tempranas de su desarrollo, (2) la oportunidad de detener el desarrollo de un sistema que no es funcional y (3) la posibilidad de desarrollar un sistema que satisfaga en mejor forma las necesidades y expectativas de los usuarios. Los usuarios tienen un papel distinguido en el proceso de elaboración de prototipos. Su primer interés debe ser interactuar con el prototipo mediante experimentación. Los analistas de sistemas deben trabajar sistemáticamente para obtener y evaluar las reacciones de los usuarios ante el prototipo, y luego trabajar para incorporar las sugerencias e innovaciones de los usuarios que valgan la pena en las modificaciones subsecuentes.

UNIDAD III

El uso del análisis

9. USO DE DIAGRAMAS DE FLUJO DE DATOS

Para comprender mejor el movimiento lógico de los datos en un negocio, el analista de sistemas traza diagramas de flujo de datos (DFD). Los diagramas de flujo de datos son análisis estructurados y herramientas de diseño que permiten que el analista comprenda visualmente el sistema y subsistemas como un juego de flujos de datos interrelacionados.

La representación gráfica del movimiento, almacenamiento y transformación de datos es trazada con el uso de cuatro símbolos: un rectángulo redondeado para indicar procesamiento o transformaciones de datos, un cuadrado doble para mostrar una entidad de datos externa (origen o receptor de datos), una flecha para mostrar el flujo de datos y un rectángulo de extremo abierto para mostrar un almacén de datos.

El analista de sistemas extrae procesos, fuentes, almacenes y flujos de datos desde las primeras narraciones organizacionales, y usa un enfoque de arriba hacia abajo para trazar primero un diagrama de contexto del sistema, dentro de la imagen más grande. Luego es trazado un diagrama de flujo de datos lógico a nivel 0. Se muestran los procesos y se añaden los almacenes de datos. Luego el analista crea un diagrama hijo para cada uno de los procesos del Diagrama 0. Las entradas y salidas permanecen constantes, pero cambian los almacenes de datos y las fuentes. La explosión del diagrama de flujo original permite que el analista de sistemas se enfoque en las representaciones cada vez más detalladas de los movimientos de datos dentro del sistema. Luego, el analista desarrolla un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico, particionándolo para facilitar la programación. Cada proceso es analizado para determinar si debe ser un procedimiento manual o automatizado. Los procesos automatizados son agrupados subsecuentemente en una serie de programas de computadora diseñados para ser por lotes o en línea. Seis consideraciones para partición de diagramas de flujo incluyen si:

1.- Hay procesos ejecutados por diferentes grupos de usuarios, hay procesos que se ejecuten al mismo tiempo

2.- Hay procesos que ejecuten tareas similares, los procesos por lotes pueden ser combinados para un procesamiento eficiente

3.- Los procesos pueden ser combinados en un programa para tener consistencia de datos

4.- O si los procesos pueden ser partidos en diferentes programas por razones de seguridad.

El diagrama de flujo de datos correcto para el ejemplo de la nómina.

Las ventajas de los diagramas de flujo de datos incluyen la simplicidad de la notación, usándola para obtener información más clara de los usuarios, permitiendo que el analista de sistemas conceptualice los flujos de datos necesarios sin estar atado a una implementación física particular, permitir que los analistas conceptualicen mejor las interrelaciones del sistema y sus subsistemas y analicen un sistema propuesto para determinar si han sido definidos los datos y procesos necesarios.

Características comunes de los diagramas de flujo de datos lógicos y físicos.

El diagrama de flujo de datos físico (abajo) muestra determinados detalles que no se encuentran en el diagrama de flujo de datos lógico (arriba).

10. ANÁLISIS DE SISTEMAS USANDO DICCIONARIOS DE DATOS.

Usando un enfoque de arriba hacia abajo, el analista de sistemas usa los diagramas de flujo de datos para comenzar la compilación de un diccionario de datos, que es una referencia que contiene datos acerca de datos, o "metadatos" sobre todos los datos de procesos, almacenes, flujos, estructuras y los elementos lógicos y físicos dentro del sistema que está siendo estudiado. Una manera para comenzar es incluyendo todos los conceptos de datos de los diagramas de flujo de datos.

La forma en que el diccionario de datos se relaciona con el diagrama de flujo de datos.

Una colección grande de la información de proyecto es llamada un depósito. Las herramientas CASE permiten que el analista cree un depósito, que puede incluir información acerca de los flujos, almacenes, estructuras de registro y elementos de datos, la lógica de procedimiento de diseños de pantalla y reporte, relaciones de datos, requerimientos del proyecto y lo que produce el sistema final e información sobre la administración de proyecto. Cada entrada del diccionario de datos contiene: el nombre del concepto, una descripción verbal, alias, elementos de datos relacionados, rango, longitud, codificación y la información de edición necesaria. El diccionario de datos es útil en todas las fases del análisis, diseño y documentación última, debido a que es la fuente autorizada sobre la manera en que es usado y definido un elemento de datos en el sistema. Muchos sistemas grandes tienen diccionarios de datos computarizados que tienen referencias cruzadas con todos los programas de la base de datos que usan un elemento de datos particular.

Dos diagramas de flujo de datos y sus entradas del diccionario de datos correspondientes para la producción de un cheque de pago a un empleado.

11. DESCRIPCIÓN DE ESPECIFICACIONES DE PROCESO Y DECISIONES

ESTRUCTURADAS.

Una vez que el analista identifica los flujos de datos y comienza a construir el diccionario de datos es tiempo de pasar a las especificaciones de proceso y análisis de decisiones. Los tres métodos para el análisis de decisiones y la descripción de la lógica de proceso tratados en este capítulo son: lenguaje estructurado, tablas de decisión y árboles de decisión. Las especificaciones de proceso (o mini especificaciones) son creadas para los procesos primitivos en un diagrama de flujo de datos así como para algunos procesos de alto nivel que explotan a diagramas hijos. Estas especificaciones explican la lógica de toma de decisiones y las fórmulas que transformarán los datos de entrada al proceso en salida.

Los tres objetivos de la especificación de proceso son: reducir la ambigüedad de los procesos, obtener una descripción precisa de lo que se logra y validar el diseño de sistema. Una gran parte del trabajo del analista de sistemas involucrará decisiones estructuradas, esto es, decisiones que pueden ser automatizados si suceden condiciones identificadas. Para lograr esto, el analista necesita definir cuatro variables en la decisión que está siendo examinada: condiciones, alternativas de condición, acciones y reglas de acción.

Una forma para describir las decisiones estructuradas es usar el método mencionado como lenguaje estructurado, donde la lógica es expresada en estructuras secuenciales, estructuras de decisión, estructuras de caso o iteraciones.

El lenguaje estructurado usa palabras reservadas aceptadas, tales como SI, ENTONCES, SINO, HACER, HACER MIENTRAS y HACER HASTA para describir la lógica usada y usa sangrías para indicar la estructura jerárquica del proceso de decisión. Las tablas de decisión proporcionan otra forma para examinar, describir y documentar decisiones. Cuatro cuadrantes (vistos en sentido del reloj a partir de la esquina superior izquierda) son usados para: (1) describir las condiciones, (2) identificar alternativas de decisión posibles (tales como S o N), (3) indicar cuáles acciones deben ser ejecutadas y (4) describir las acciones. Las tablas de decisión son ventajosas, debido a que las reglas para desarrollar la tabla misma, así como las reglas para eliminar redundancia, contradicciones y situaciones imposibles son directas y manejables. El uso de tablas de decisión promueve la integridad y precisión en el análisis de decisión estructuradas.

El tercer método para el análisis de decisiones es el árbol de decisión que consiste de nodos (un cuadrado para acciones y un círculo para condiciones) y ramas. Los árboles de decisión son adecuados cuando se deben realizar acciones en una secuencia determinada. No hay requerimientos de que el árbol tenga que ser simétrico, por lo que solamente se encuentran en una rama particular aquellas condiciones y acciones que son críticas para las decisiones presentes.

Cada uno de los métodos de análisis de decisión tiene sus propias ventajas y debe ser usado de acuerdo con ellas. El lenguaje estructurado es útil cuando muchas acciones son repetidas y cuando es importante la comunicación con otros. Las tablas de decisión proporcionan análisis completo de situaciones complejas y a la vez limitan la necesidad por cambios atribuibles a situaciones imposibles, redundancias o contradicciones. Los árboles de decisión son importantes cuando es crítica la secuencia adecuada de condiciones y acciones y cuando cada condición no es relevante para cada acción.

Cada proceso del diagrama de flujo de datos se expande a un diagrama hijo, a una gráfica de estructura o a una especificación de proceso (tal como el lenguaje estructurado). Si el proceso es primitivo las especificaciones muestran la lógica, aritmética o algoritmos para transformar la entrada en la salida. Estas especificaciones del modelo lógico son parte de las reglas del negocio (que son usadas frecuentemente como la base para crear lenguajes procedurales cuando se usa generadores de código). Si el proceso se expande a un diagrama hijo o a una gráfica de estructura, la especificación de proceso describe el orden y condiciones bajo los cuales ejecutarán los procesos del diagrama hijo. Esta lógica de control es parte del modelo físico.

12. ANÁLISIS DE SISTEMAS DE APOYO A DECISIONES SEMIESTRUCTURADAS.

Los sistemas de apoyo a decisiones (DSS) son una clase especial de sistemas de información que enfatizan el proceso de toma de decisiones y cambian a los usuarios del DSS por medio de su interacción con el sistema. Los sistemas de apoyo a decisiones están bien adecuados para resolver problemas semiestructurados, donde el discernimiento humano todavía es deseado o requerido. Los sistemas de apoyo a decisiones no dan una solución a los usuarios, sino que, en vez de ello, dan soporte al proceso de toma de decisiones ayudando al usuario a encontrar alternativas y considerar sus ramificaciones por medio de diferentes técnicas de modelado. Los usuarios del DSS o de los sistemas de apoyo a decisión en grupo (GDSS), vienen de todos los tres niveles administrativos de la organización. Sin embargo, las decisiones semiestructuradas son requeridas más frecuentemente por los niveles administrativos medio y estratégico. Los usuarios de un DSS son eventualmente cambiados por medio del proceso de interacción con el sistema. El estilo de toma de decisiones de los usuarios puede ser categorizado como analítico o heurístico. Los tomadores de decisiones analíticos tienden a dividir los problemas en componentes cuantitativos y usan modelos matemáticos para tomar una decisión y, en cambio, los tomadores de decisiones heurísticos se apoyan en la experiencia. Los sistemas de apoyo a decisiones pueden ser diseñados pensando en el estilo predominante del tomador de decisiones, para que a los pensadores analíticos se les proporcionen modelos cuantitativos y a los tomadores de decisiones heurísticos se les proporcione información resumida y ayudas de memoria que les permitan recordar cómo usaron la heurística en el pasado. Las decisiones semiestructuradas son aquellas en las que el discernimiento humano todavía es requerido o considerado deseable. Se considera que algunas decisiones son semiestructuradas debido a que el tomador de decisiones no posee las habilidades para la toma de decisión y poder tomar ésta.

También, si un problema es demasiado complejo es clasificado como semiestructurado. Por último, un problema puede ser llamado semiestructurado si deben ser atacados criterios múltiples. Los sistemas de apoyo a decisiones están especialmente bien indicados para ayudar a resolver problemas semiestructurados. En todas las soluciones de problemas los tomadores de decisiones recorren tres fases: inteligencia, selección y diseño. En la fase de inteligencia el tomador de decisiones está revisando ambientes de negocios internos y externos, buscando problemas y oportunidades potenciales. La fase de diseño consiste en la articulación del problema u oportunidad, descubriendo y creando alternativas, evaluándolas y examinando sus aplicaciones. La fase de selección está compuesta de la selección de una alternativa entre aquellas que han sido consideradas y la determinación de razones y argumentos para la adopción de esa solución. Los sistemas de apoyo a decisiones deben ser diseñados para dar soporte a decisiones en las tres fases de la solución de problemas. Un sistema de apoyo a decisiones completo debe ser capaz de dar apoyo a la toma de decisiones de criterios múltiples. El tomador de decisiones que usa este tipo de DSS tiene un gran repertorio de métodos disponibles, incluyendo un proceso de pro y contra, métodos ponderados, eliminación secuencias por lexicografía, eliminación secuencias por restricciones conjuntivas y la programación por metas.

13. PREPARACIÓN DE LA PROPUESTA DE SISTEMAS.

La evaluación de hardware y software, identificación y pronóstico de costos y beneficios y la realización de análisis de beneficio - costo son actividades necesarias que el analista de sistemas debe lograr para la preparación del material para la propuesta de sistema. Los requerimientos de información ayudan a conformar qué software es comprado o codificado, así como qué hardware es necesario para realizar las funciones de transformación de datos requeridas. Los analistas de sistemas deben estimar las cargas de trabajo para caracterizar adecuadamente la capacidad de cargas de trabajo actual y la proyección necesaria para el hardware. Se pueden ejecutar cargas de trabajo de muestra en el hardware bajo consideración. Aunque el equipo de cómputo cambia rápidamente, el procedimiento usado para la evaluación del hardware no necesita cambiar. Mediante el inventariado del equipo que ya se tiene a la mano y pedido, los analistas de sistemas serán capaces de recomendar si se conserva el actual, o se modifica o se compra nuevo hardware computacional.

El hardware computacional puede ser adquirido mediante compra, arrendamiento financiero o renta. Los vendedores proporcionarán servicios de apoyo, tales como mantenimiento preventivo y entrenamiento a usuarios, que son típicamente negociados por aparte. Los paquetes de software también deben ser evaluados por el analista de sistemas y los usuarios pertinentes. Se puede ahorrar mucho tiempo de programación si uno de estos paquetes es utilizable sin gran personalización. El software necesita ser evaluado sobre qué tan bien desarrolla las funciones deseadas, su facilidad de uso, adecuación de la documentación y servicios de apoyo que puedan ofrecer los vendedores. La preparación de una propuesta significa la identificación de todos los costos y beneficios de varias alternativas. El analista de sistemas tiene varios métodos disponibles para pronosticar los costos, beneficios, volúmenes de transacciones y variables económicas futuras que afectan los costos y beneficios. Los costos y beneficios pueden ser tangibles (cuantificables) o intangibles (no cuantificables y resistentes a una comparación directa). Un analista de sistemas tiene muchos métodos para el análisis de costos y beneficios. El análisis de punto de equilibrio examina el costo del sistema existente contra el costo del sistema propuesto. El método de recuperación determina la cantidad de tiempo que transcurrirá antes de que el nuevo sistema sea rentable. El análisis de flujo de efectivo es adecuado cuando es crítico saber la cantidad de desembolsos de efectivo, y el valor presente toma en cuenta el costo de pedir dinero prestado. Estas herramientas ayudarán al analista a examinar las alternativas a la mano y tomar una recomendación bien documentada sobre la propuesta de sistemas.

Lineamientos para la evaluación de software

14. ESCRITURA Y PRESENTACIÓN DE LA PROPUESTA DE SISTEMAS.

Los analistas de sistemas tienen tres pasos principales a seguir para reunir una propuesta de sistemas efectiva: organizar funcionalmente el contenido de la propuesta, escribir la propuesta en un estilo de negocios apropiado y exponer verbalmente una propuesta de sistemas informativa. Debido a que la propuesta es el resultado del trabajo que ha sido realizado hasta el momento y el esfuerzo propuesto, es un documento crítico para vender el sistema. Para ser efectiva, la propuesta debe ser escrita en una forma clara y comprensible, y su contenido debe estar dividido en 10 secciones funcionales. Debe tener un título adecuado que atrape el interés de los lectores y refleje claramente lo que está por venir. La propuesta debe tener un resumen ejecutivo que proporcione un panorama conciso del proyecto de sistemas y las recomendaciones del analista.

Las consideraciones visuales son importantes cuando se arma una propuesta que comunica bien. Use suficiente espacio en blanco para destacar el texto, sea generoso cuando incluya encabezados y subencabezados, numere todas las páginas y mantenga al mínimo las referencias y los apéndices. Mucho de lo que es importante en la propuesta de sistemas puede ser mejorado mediante el uso adecuado de figuras, incluyendo tablas y gráficas. Las gráficas comparan dos o más variables a lo largo del tiempo o en un momento particular del tiempo. Las figuras siempre son acompañadas con una interpretación escrita en la propuesta. Las gráficas y tablas usadas para planeación, anteriormente a la propuesta, pueden ser incorporadas a ella cuando sean relevantes. La presentación verbal del sistema está basada en la propuesta escrita y es otra forma de vender eficientemente el sistema. Una opción para la presentación es crear una presentación de transparencias usando software de presentación. También, los paquetes de presentación gráficos y el clipart pueden ser usados para mejorar la presentación visual de la propuesta de sistemas. Lineamientos para la presentación verbal efectiva de la propuesta de sistemas. Para dar una fuerte presentación verbal, el analista debe conocer cuatro elementos por anticipado: quiénes compondrán la audiencia, el tema (presumiblemente la propuesta de sistemas o parte de ella), el tiempo asignado para la presentación y el equipo disponible (incluyendo la disposición de la sala). Los cuatro elementos están interrelacionados y cada uno necesita ser analizado y planeado para asegurar el éxito.

UNIDAD IV

Los puntos esenciales del diseño

15. DISEÑO DE SALIDA EFECTIVA

La salida es cualquier información útil o datos proporcionados por el sistema de información o, el sistema de apoyo a decisiones ante el usuario. La Salida puede tomar virtualmente cualquier forma, incluyendo la impresión, pantallas, audio, microformas, CD-ROM y electrónica. Estos diseñan la salida para que sirva al propósito pretendido y para que se ajuste al usuario, proporcionar la cantidad adecuada de salida, proporcionarla en el lugar adecuado, proporcionar la salida a tiempo y seleccionar la salida a tiempo y seleccionar el método de salida adecuado.

Es importante que el analista se dé cuenta de que el contenido de la salida está relacionado con el método de la salida. La salida de diferentes tecnologías afecta a los usuarios en formas diferentes. Las tecnologías de salida también difieren en su velocidad, costo, portabilidad, flexibilidad y posibilidades de almacenamiento y recuperación. Todos estos factores deben ser considerados cuando se decide entre impresión, en pantalla, audio, microformas o salida electrónica, o una combinación de estos métodos de salida. La presentación de la salida puede tergiversar la interpretación que los usuarios hacen de ella. Los analistas deben estar conscientes de las fuentes de ascendencia, interactuar con los usuarios para diseñar la salida, informar a los usuarios de las posibilidades de ascendencia en la salida, crear salida flexible y modificable y entrenar a los usuarios para que usen varias salidas para que les ayuden a verificar la precisión de cualquier reporte particular. Los reportes impresos son diseñados con el uso de hojas de diseño de reporte en pantalla o en papel. El diccionario de datos sirve como fuente de los datos necesarios para cada reporte.

A los usuarios se muestran modelos o prototipos de los reportes antes de terminar el diseño de reporte y se realiza cualquier cambio necesario. El analista de sistemas usa el diseño de hoja o pantalla para comunicar el diseño físico al programador. Las pantallas VDT, que son una forma especialmente de salida para los sistemas de apoyo a decisiones, así como para los MIS tradicionales, son diseñadas usando formas de diseño de reporte en pantalla. Nuevamente, la estética y utilidad son importantes para crear una pantalla bien diseñada. Es importante producir prototipos de pantallas que permitan que los usuarios hagan cambios donde deseen. La salida gráfica en pantalla está llegando a ser cada vez más utilizado, en especial para los sistemas de apoyo a decisiones. El analista de sistemas debe considerar los efectos de las gráficas ante los usuarios, el tipo de datos debe ser desplegado, el objetivo de las gráficas y su audiencia pretendida. Se dispone de muchos paquetes de software dedicados a los gráficos. Es esencial que los tomadores de decisiones reciban entrenamiento sobre la forma de interpretar las gráficas para que les sean útiles.

16. DISEÑO DE ENTRADA EFECTIVO.

Este capítulo trata a los elementos del diseño de entrada para formas y pantallas VDT. La entrada bien diseñada debe satisfacer los objetivos de efectividad, precisión, facilidad de uso, consistencia y atractivo. El conocimiento de muchos elementos de diseño diferentes permitirá que el analista de sistemas alcance estos objetivos. Los cuatro lineamientos para las formas de entrada bien diseñadas son:

1. Las formas deben ser fáciles de llenar.

2. Las formas deben satisfacer el propósito para el que fueron diseñadas.

3. Las formas deben ser diseñadas para asegurar su llenado preciso.

4. Las formas deben ser atractivas.

El diseño de formas y pantallas útiles se traslapa en muchas formas importantes, pero hay algunas distinciones. Las pantallas despliegan un cursor que orienta continuamente al usuario. Las pantallas proporcionan frecuentemente asistencia con la entrada y, en cambio, aparte de las instrucciones preimpresas, puede ser difícil obtener ayuda adicional para una forma.

Los cuatro lineamientos para pantallas VDT bien diseñadas son:

1. Las pantallas deben ser mantenidas simples.

2. Las pantallas deben ser consistentes de pantalla a pantalla.

3. El diseño de pantalla debe facilitar el movimiento entre pantallas.

4. Las pantallas deben ser atractivas.

Muchos elementos de diseño diferentes permiten que el analista de sistemas satisfaga estos lineamientos. Es importante el flujo adecuado tanto en formas como en pantallas. Las formas deben agrupar lógicamente la información en siete categorías y las pantallas deben ser divididas en tres secciones principales. Los títulos en formas y pantallas pueden ser variados, tal como lo permita los tipos de letra y grosores de línea que dividan las subcategorías de información, Las formas de varias copias son otra manera de asegurar que las formas satisfacen su propósito pretendido. Los diseñadores pueden usar ventanas, preguntas, cuadros de diálogo y valores por omisión en pantalla para asegurar la efectividad del diseño. Hay muchas similitudes, pero algunas diferencias críticas, entre el diseño de pantallas para sistemas de macrocomputadora y de microcomputadora. Para aumentar la eficiencia, las pantallas de macrocomputadora son enviadas como un todo, en vez de como series de tecleos individuales.

Los campos de datos en una pantalla de macrocomputadora son definidos usando un carácter de atributo de campo que controla las cualidades de protección, intensidad, desplazamiento y atributos extendidos. El carácter de atributo debe ser tomado en cuenta cuando se diseñan pantallas para terminales de macrocomputadora.

17. DISEÑO DEL ARCHIVO O BASE DE DATOS.

Cómo guardar datos es frecuentemente una decisión importante en el diseño de un sistema de información. Hay dos enfoques para el almacenamiento de datos. El primer enfoque es guardar los datos en archivos individuales y un archivo para cada aplicación. El segundo enfoque es desarrollar una base de datos que pueda ser compartida por muchos usuarios para una variedad de aplicaciones conforme se necesita. Se han realizado mejoras dramáticas en el diseño de software de base de datos para aprovechar la interfaz gráfica de usuario.

El enfoque de archivo convencional puede ser, a veces, un enfoque más eficiente, debido a que el archivo puede ser específico de la aplicación. Por otro lado, el enfoque de base de datos puede ser más adecuado debido a que los mismos datos necesitan ser capturados, almacenados y actualizados una sola vez. Para comprender el almacenamiento de datos es necesario tener un conocimiento de tres reinos: la realidad, los datos y los metadatos. Una entidad es cualquier objeto o evento del que deseamos recolectar y almacenar datos. Los atributos son las características actuales de esas entidades. Los conceptos de datos pueden tener valores y pueden ser organizados en registros que pueden ser accesados por medio de una llave. Los metadatos describen a los datos y pueden contener restricciones acerca del valor de un concepto de datos (tal como que sea solamente numérico). Ejemplos de archivos convencionales incluyen archivos maestros, archivos de tabla, archivos de transacción, archivos de trabajo y archivos de reporte. Pueden tener organización secuencias, listas encadenadas, organización de archivo de dispersión, organización indexada u organización secuencias indexadas. Una forma más moderna y eficiente para manejar archivos secuenciales indexados es el VSAM. Las bases de datos pueden tener estructura jerárquica, de red o relacionar. La normalización es el proceso que toma las vistas de usuario y las transforma en estructuras menos complejas, llamadas relaciones normalizadas.

Hay tres pasos en el proceso de normalización. Primero son eliminados todos los grupos repetidos. Segundo, son eliminadas todas las dependencias parciales. Por último, son quitadas las dependencias transitivas. Después de estos tres pasos, el resultado es la creación de muchas relaciones que están en la tercera forma normal (3NF). Se puede usar el diagrama entidad-relación para determinar las llaves requeridas para un registro o relación de base de datos. Los tres lineamientos a seguir cuando se diseñan archivos maestros o relaciones de bases de datos son:

(1) cada entidad de datos separada debe crear un archivo maestro. No combine dos entidades distintas en un solo archivo.

(2) Un campo de dato específico debe existir solamente en un archivo maestro y

(3) cada archivo maestro o relación de base de datos debe tener programas para crear, leer, actualizar y borrar.

El proceso de recuperación de datos puede involucrar hasta ocho pasos:

(1) la relación o relaciones se seleccionan y

(2) se unen;

(3) se realizan la proyección y

(4) selección sobre la relación para extraer los renglones y columnas relevantes.

(5) Se pueden derivar nuevos atributos,

(6) los renglones son ordenados o indexados,

(7) se calculan totales y medidas de desempeño y, por último,

(8) se presentan los resultados al usuario.

18. DISEÑO DE LA INTERFAZ DE USUARIO.

En este capítulo se ha enfocado en los usuarios del sistema, su interfaz con la computadora, su necesidad de retroalimentación y el diseño de su estación de trabajo. El éxito del sistema que se diseñe depende del involucramiento y aceptación del usuario. Por lo tanto, el pensar acerca de los usuarios en formas sistemáticas y empáticas es de gran importancia y no un asunto periférico para los analistas de sistemas. En este capítulo se trata varios tipos de interfaz de usuario y dispositivos de entrada. Algunas interfaces están particularmente bien adaptadas para los usuarios sin experiencia, tales como: lenguaje natural, pregunta y respuesta, menús, llenado de forma, interfaz gráfica de usuario, el ratón, plumas ópticas y pantallas sensibles al tacto.

El lenguaje de comandos está mejor adecuado para los usuarios experimentados. La combinación de interfaces puede ser extremadamente efectiva. Por ejemplo, el uso de menús desplegables con interfaces gráficas de usuario, o el empleo de menús anidados dentro de interfaces de preguntas y respuestas, produce combinaciones interesantes. Cada interfaz plantea un nivel diferente de reto para los programadores, siendo el lenguaje natural el más difícil de programar. La retroalimentación se usa de muchas formas. También se enfatiza la necesidad de retroalimentación a los usuarios por parte del sistema. Es necesaria la retroalimentación del sistema para hacer que los usuarios sepan si su entrada está siendo aceptada, si la entrada está o no en la forma correcta, si el procesamiento está avanzando, si las peticiones pueden ser o no procesadas y si se encuentra disponible información más detallada y cómo obtenerla. También puede ser efectiva la retroalimentación por audio.

Las consultas están diseñadas para permitir a los usuarios extraer datos significativos de la base de datos. Hay seis tipos básicos de consultas y pueden ser combinados usando lógica booleana para formar consultas más complejas. Por último, consideramos la manera en que los espacios de trabajo del usuario influencian su disponibilidad para el uso del sistema y cómo pueden ser mejoradas las estaciones de trabajo mediante la implementación de principios ergonómicos relevantes. Hay lineamientos de productividad y confort específicos para la construcción y posicionamiento de las VDT, teclados, soportes de computadora y asientos para usuario, pero por lo general todos ellos deben ser lo suficientemente flexibles para permitir el ajuste para uso individual.

19. DISEÑO DE PROCEDIMIENTO PARA LA CAPTURA DE DATOS PRECISA.

El aseguramiento de la calidad de los datos de entrada al sistema de información es crítico para asegurar la calidad de la salida. La calidad de los datos alimentados puede ser mejorada por medio del logro de tres principales objetivos de la captura de datos: codificación efectiva, captura de datos efectiva y eficiente y validación de los datos. Una de las mejores formas para agilizar la captura de datos es mediante el uso efectivo de la codificación, que pone los datos en secuencias cortas de dígitos y/o letras. Se pueden usar códigos de secuencia simple Y códigos de derivación alfabética para seguir el avance de un concepto dado a través del sistema. Los códigos de clasificación y los códigos de secuencia en bloque son útiles para distinguir clases de artículos entre ellas. Los códigos, tales como el código de cifrado, también son útiles para ocultar información que es sensible o está restringida a determinadas personas dentro del negocio. La revelación de información es también un uso de códigos que vale la pena, debido a que permite que los empleados del negocio localicen conceptos en existencia y también puede hacer que la captura de datos sea más significativa.

Los códigos de subconjuntos de dígito significativo usan subgrupos de dígitos para describir un producto. Los códigos mnemónicos también revelan información, sirviendo como ayudas de memoria para que ayuden al operador de captura de datos a teclear los datos correctamente o ayuden al usuario final para el uso de la información. Los códigos que son útiles para informar a las computadoras o a las personas acerca de qué funciones hay que realizar o qué acciones efectuar son llamados códigos de función, y evitan el tener que decir a detalle qué acciones son necesarias. Otra parte para asegurar la captura de datos efectiva es la atención a los dispositivos de entrada que se usan. El primer paso es una forma efectiva y bien diseñada que sirva como documento fuente (cuando se necesita), Los datos pueden ser alimentados por medio de muchos métodos diferentes, teniendo cada uno diferente velocidad y confiabilidad. Las mejoras en eficiencia sobre el teclado a cinta han sido realizadas por medio de la interacción de los sistemas teclado a disco y teclado a disco flexible. El reconocimiento óptico de caracteres (OCR) permite la lectura de datos de entrada por medio del uso de software especial que elimina algunos pasos y también requiere menos habilidades de los empleados. Otros métodos de captura de datos incluyen el reconocimiento de caracteres de tinta magnética usado por los bancos para codificar los números de cuenta de los clientes, las formas de marcas sensibles usadas para alimentación de gran cantidad de datos y las formas perforadas usadas en votaciones. Los códigos de barras (aplicados a productos y luego digitalizados) también agilizan la captura de datos y mejoran la precisión y confiabilidad de los datos. También están siendo desarrolladas nuevas tecnologías de entrada, tales como las cámaras digitales. Las terminales inteligentes son dispositivos de entrada (frecuentemente basadas en microprocesador) con una VDT, teclado y enlace de comunicación con la CPIJ. Permiten que se tecleen y completen transacciones en tiempo real. Junto con una codificación adecuada, captura de datos y dispositivos de entrada, la captura de datos precisa puede ser mejorada mediante el uso de la validación de la entrada. El analista de sistemas debe suponer que sucederán errores en los datos, y debe trabajar con los usuarios para diseñar pruebas de validación de entrada para prevenir que sean procesados y almacenados datos erróneos.

Las transacciones de entrada deben ser revisadas para asegurar que la transacción solicitada es aceptable, autorizada y correcta. Los datos de entrada pueden ser validados por medio de la inclusión en el software de varios tipos de pruebas que revisen datos faltantes, la longitud de concepto de datos, el rango y la razonabilidad de los datos y valores inválidos de los datos. Los datos de entrada también pueden ser comparados con datos almacenados para efectos de validación. Una vez que los datos numéricos son alimentados, pueden ser revisados y corregidos automáticamente mediante el uso de dígitos de verificación.

20. ASEGURAMIENTO DE LA CALIDAD POR MEDIO DE LA INGENIERÍA DE SOFTWARE.

El analista de sistemas usa tres amplios enfoques para la administración de calidad total (TQM) para analizar y diseñar sistemas de información: diseño de sistemas y software con un enfoque modular de arriba hacia abajo, diseño y documentación de sistemas y software usando métodos sistemáticos, y pruebas de sistemas y software para que puedan ser fácilmente mantenidos y auditados. Los usuarios son de importancia crítica para el establecimiento y evaluación de la calidad de varias dimensiones de los sistemas de manejo de información y los sistemas de apoyo a decisiones. Pueden estar involucrados en la evolución completa de los sistemas mediante el establecimiento de fuerzas de tarea MIS o círculos de calidad.

La TQM puede ser implementada satisfactoriamente tomando un enfoque de arriba hacia abajo para el diseño. Esto se refiere a ver primero los objetivos organizacionales generales y luego descomponiéndolos en requerimientos de subsistemas manejables. El desarrollo modular hace que la programación, depuración y mantenimiento sean más fáciles de lograr. La programación en módulos está muy bien adecuada para tomar un enfoque de arriba hacia abajo. Dos sistemas que enlazan programas en el ambiente Windows son el DDE (Intercambio dinámico de datos) que comparte código utilizando archivos de biblioteca de enlace dinámico (DLL). Mediante el uso del DDE un usuario puede almacenar datos en un programa y luego usarlos en otro. Un segundo enfoque para el enlace de programas en Windows es llamado OLE (vinculación e inclusión de objetos). Este método de enlace es superior al DDE para enlazar datos y gráficos de aplicaciones, debido a su enfoque orientado a objetos.

Una herramienta recomendada para el diseño de un sistema modular de arriba hacia abajo es llamada una gráfica de estructura. Se usan dos tipos de flechas para indicar los tipos de parámetros que son pasados entre los módulos. El primero es llamado un acople de datos y el segundo es llamado una bandera de control. Los módulos de las gráficas de estructuras caen en una de tres categorías: control, transformacional (a veces llamada trabajador) y funcional o especializado.

Parte de la administración de calidad total es ver que los programas y sistemas estén diseñados, documentados y mantenidos adecuadamente. Seis de las muchas técnicas de documentación y diseño que pueden ayudar al analista de sistemas son HIPO, diagramas de flujo, gráficas Nassi-Shneiderman, diagramas Warnier-Orr, seudocódigo, manuales de procedimiento y FOLKLORE. Los diagramas de flujo de datos pueden usarse para crear diagramas HIPO. El seudocódigo es usado para paseos estructurados cuando no hay suficiente tiempo para crear diagramas HIPO formales.

Los analistas de sistemas deben escoger una técnica que se ajuste bien con lo que fue usado anteriormente en la organización y que permita flexibilidad y facilidad de modificación. La generación de código es el proceso de usar software para crear todo o parte de un programa de computadora. Muchos generadores de código están disponibles ahora comercialmente. La reingeniería y la ingeniería inversa se refieren al uso de software para analizar código de programas existentes y crear elementos de diseño CASE a partir del código. El diseño CASE puede ser luego modificado y usado para generar nuevo código de programa de computadora. La prueba de programas específicos, subsistemas y sistemas completos es esencial para la calidad. La prueba se realiza para hacer que aparezca cualquier problema que exista en los programas y sus interfaces antes de que el sistema sea, de hecho, usado. Típicamente la prueba se realiza en una forma de abajo hacia arriba, siendo revisado el código de programa primero en escritorio. Siguiendo varios pasos de prueba intermedia se llega a la prueba del sistema completo con datos reales (datos reales que han sido procesados satisfactoriamente con el sistema antiguo). Esto proporciona una oportunidad para eliminar cualquier problema que se presente antes de que el sistema sea puesto en producción. El mantenimiento del sistema es una consideración importante. El software bien diseñado puede ayudar a reducir los costos de mantenimiento. Los analistas de sistemas necesitan establecer canales para la retroalimentación de los usuarios sobre las necesidades de mantenimiento, debido a que los sistemas que no son mantenidos caerán en desuso. Se consultan auditores, tanto internos como externos, para determinar la confiabilidad de la información del sistema. Ellos comunican sus hallazgos de auditoria a otros para mejorar la utilidad de la información del sistema.

21. IMPLEMENTACIÓN SATISFACTORIA EN EL SISTEMA DE INFORMACIÓN.

La implementación es el proceso de asegurar que el sistema de información y/o el centro de información es operacional y luego involucrar a usuarios bien capacitados en su operación. En proyectos de sistemas grandes, el papel principal del analista es supervisar la implementación, estimando correctamente el tiempo necesario y luego supervisando la instalación del equipo para los sistemas tradicionales, centros de información o procesamiento distribuido, la capacitación de usuarios y la conversión de archivos y bases de datos al nuevo sistema. Un centro de información implementado dentro de un negocio, como parte de un departamento de sistemas más grande, es una forma para hacer más fácil a los usuarios satisfacer sus necesidades de información a corto plazo. Por medio del centro de información los usuarios aprenden a resolver sus propios problemas de negocios inmediatos con el hardware y software de computadora disponible y la ayuda experta de los especialistas del centro. Tanto los usuarios como el personal del centro de información deben hacer propia la idea de que el centro de información es una empresa que vale la pena y estar dispuestos a desempeñar los nuevos papeles requeridos en el centro. Es posible comenzar un centro de información con un gerente y dos o tres personas técnicas (siendo uno o todos ellos analistas de sistemas). Los empleados del centro deben ser competentes técnicamente, pero también deben sentir agradable el interactuar con los usuarios en un papel de soporte. Los usuarios deben aceptar la responsabilidad de los recursos que están usando, querer aprender y ser capaces de formular sus problemas con base en su propio conocimiento de fondo del negocio. Los sistemas distribuidos aprovechan la tecnología de telecomunicaciones y la administración de bases de datos para una de las formas más populares para enfocar los sistemas distribuidos es mediante el uso de un modelo cliente/servidor. Los tipos estándar de redes organizacionales incluyen la red de área local (LAN) y la red de área amplia (WAN). Mediante el uso de un enfoque de arriba hacia abajo, los analistas pueden usar seis símbolos para ayudarse a trazar los diagramas de descomposición de la red y conectividad de núcleos. Un nuevo software, llamado groupware, está llegando a ser más funcional y más ampliamente distribuido. Su objetivo es ayudar a los miembros de grupos a trabajar juntos por medio de redes.

La capacitación de usuarios y de personal para interactuar con el sistema de información y/o el centro de información es una parte importante de la implementación, debido a que ellos deben ser capaces de ejecutar el sistema sin intervención del analista. El analista necesita considerar quiénes necesitan ser capacitados, quién los capacitará, los objetivos de la capacitación, los métodos de instrucción a ser usados, lugares y materiales.

La conversión también es parte del proceso de implementación. El analista tiene varias estrategias para cambiar del sistema de información antiguo al nuevo. Las cinco estrategias de conversión incluyen cambio directo, conversión en paralelo, conversión por fases, conversión de prototipos modulares y conversión distribuida. El tomar un enfoque de contingencia entre las estrategias de conversión puede ayudar al analista a seleccionar una estrategia adecuada que se ajuste a sistemas diferentes y a variables organizacionales. Una investigación exploratoria reciente sugiere que el analista de sistemas puede mejorar las oportunidades de que sea aceptado un sistema recientemente implementado si desarrolla el sistema con las metáforas organizacionales predominantes en mente. Nueve metáforas principales en uso son: familia, sociedad, máquina, organismo, viaje, juego, guerra, selva y zoológico. Por ejemplo, es más probable que los MIS tradicionales tengan éxito cuando se usan metáforas tales como la familia, sociedad o máquina, y es menos probable que tengan éxito con metáforas organizacionales tales como guerra y selva. Después de la implementación debe ser evaluado el nuevo sistema o centro de información. Se dispone de muchos enfoques de evaluación diferentes, incluyendo análisis de costo-beneficio, el enfoque de evaluación revisado y las evaluaciones de involucramiento de usuario. El marco de trabajo de utilidad del sistema de información es una forma directa para evaluar un nuevo sistema con base en las seis utilidades de posesión, forma, lugar, tiempo, actualización y objetivo. Estas utilidades corresponden y responden a las preguntas de quién, qué, dónde, cuándo, cómo y por qué para evaluar las utilidades del sistema de información o de un centro de información recientemente creado. Las utilidades también pueden servir como una lista de verificación para sistemas en desarrollo.

Bibliografía.

Internet

www.e_magister.com

www.monografias.com

www.postgrado.inea.org

www.inea.uva.es

www.tu_discovery.com

www.aulafacil.com

www.tecniciencia.com

www.wikipedia.com

 

Elaborado por:

T.S.U. Henry Jesús Mendoza Pacheco

37 Años de edad.

Partes: 1, 2, 3

Trabajo elaborado el 19 de Noviembre de 2007.


Partes: 1, 2, 3


 Página anterior Volver al principio del trabajoPágina siguiente 

Comentarios


Trabajos relacionados

Ver mas trabajos de General

 

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.