Descargar

Transición de análisis del diseño

Enviado por Rocío García


    1. Características de un buen diseño de sistemas
    2. Características del diseño conceptual
    3. Proyección del análisis a las salidas
    4. Proyección del análisis a las entradas y controles
    5. Proyección del análisis a la base de datos
    6. Proyección del análisis a los procesos (programas)
    7. Proyección del análisis a los procedimientos
    8. Propuesta del sistema
    9. Preparación del reporte
    10. Alternativas de solución
    11. Documentación del análisis preliminar

    CARACTERÍSTICAS DE UN BUEN DISEÑO DE SISTEMAS

    Los componentes de un sistema de información descritos durante el análisis de requerimientos son el punto focal del diseño de sistemas.

    • Flujos de datos. Movimientos de datos hacia, alrededor y desde el sistema.
    • Almacenes de datos. Conjunto temporales o permanentes de datos.
    • Procesos. Actividades para aceptar, manejar y suministrar datos e información.
    • Procedimientos. Métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados.
    • Controles. Estándares y lineamientos para determinar si las actividades que están ocurriendo en la forma anticipada o aceptada.
    • Funciones del personal. Las responsabilidades de todas las personas que tiene que ver con el nuevo sistema, incluyendo los usuarios, operadores d computadora y personal de apoyo.

    CARACTERÍSTICAS DEL DISEÑO CONCEPTUAL

    El manejo del proceso de diseño significa tomar los pasos necesarios para que el esfuerza de desarrollo avance en forma apropiada y produzca los resultados esperados.

    Carpeta de descripción del diseño de sistema

    Los analistas de sistema denominan a esta s especificaciones información liberada o carpeta de diseño.

    La información liberada incluye los siguientes aspectos:

    • Cuadro de despliegue. Descripciones de las entradas y salidas donde se muestra la ubicación de todos los detalles que aparecerán en los reportes, documentos y pantallas de terminal.
    • Estructuras de registros. Descripciones de todos los datos contenidos en los archivos maestros y de transacciones así como los diagramas relacionados con la base de datos.
    • Sistemas de codificación. Descripciones de los códigos que explican o identifican tipos de transacciones, clasificaciones y categorías de eventos o entidades.
    • Especificaciones de los programas. Cuadros, tablas y descripciones gráfica de los módulos y componentes del software de computadora junto con la interacción entre cada una de ellos.
    • Especificaciones de procedimientos. Procedimientos planificados para instalar y operar el sistema cuando este terminado.
    • Plan de desarrollo. Cronogramas que indican los tiempos necesarios para el desarrollo de las actividades.
    • Costo del paquete. Gastos anticipados para el desarrollo, implantación y operación de nuevos sistemas, clasificados por categorías tales como personal, equipo, comunicaciones, facilidades y suministros.

    PROYECCIÓN DEL ANÁLISIS A LAS SALIDAS

    Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación.

    Cuado diseñan la salida, los analistas deben realizar lo siguiente:

    • Determinar que información presentar.
    • Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de salida.
    • Disponer la presentación en un formato aceptable.
    • Decidir como distribuir la salida entre los posibles destinatarios.

    PROYECCIÓN DEL ANÁLISIS A LAS ENTRADAS Y CONTROLES

    Los analistas de sistemas deciden los siguientes detalles del diseño de entradas:

    1. Que datos ingresan los sistemas.
    2. Que medios utilizar.
    3. La forma en que se debe disponer o codificar los datos.
    4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
    5. Validación necesaria de datos y transacciones para detectar errores.
    6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan errores.

    Las decisiones de diseño para el manejo de entradas especifican la forma en que serán aceptados los datos para su procesamiento por computadora.

    El diseño de la entrada también incluye la especificación de los medios por los que tanto los usuarios finales como los operadores dan instrucciones al sistema sobre las acciones que deben emprender.

    Controles de entrada.-

    El analista de sistemas debe especificar los controles para evitar la entrada errónea al sistema de información. Para los campos críticos el control de la entrada implica verificar o volver a teclear. Si un campo es crítico para la verificación de una entrada y está sujeto a errores de transcripción o transposición, como un número de cuenta o el número de identificación de un empleado, en analista también podría elegir anexarle un dígito de verificación.

    En consecuencia, se debe decidir acerca de un algoritmo en particular de dígitos de verificación y documentarlo.

    Dependiendo del tipo de método empleado para la captura de datos, puede ser necesario realizar sobre la entrada varias pruebas de racionalidad. Estos controles de entrada se aplican en cuatro niveles: (1) Campos, (2) registros, (3) lotes y (4) archivos.

    Controles de procesamiento.-

    Aún cuando el analista de sistemas pudiera proponer un extenso conjunto de controles de entrada para el sistema que se está desarrollando, siempre habrá algunos errores de entrada que no puedan detectarse, creando errores adicionales durante el procesamiento.

    Operando bajo la suposición de que ningún sistema de información está completamente libre de errores, el analista de sistemas inserta en los programas de procesamiento ciertos controles del tipo de los de la entrada.

    Verificación de racionalidad. En la codificación de los programas se especifican pruebas de racionalidad como parte de las rutinas básicas para la validación de las entradas.

    Bitácora de transacciones. Se utilizan para respaldo, recuperación y pruebas de auditoría contable. Este deberá incluir información acerca del lugar, el momento y la terminal de donde se originaron las transacciones, además del número de usuario.

    Controles de acceso a las bases de datos.-

    Los controles de acceso a la base de datos incluyen un gran número de dispositivos y procedimientos desde puertas con cerradura y procedimientos de firma de entrada/ firma de salida hasta dispositivos biométricos.

    Los usuarios autorizados se identifican con base en un dispositivo de control de acceso mediante geometría manual. Unos apuntadores conectan a los usuarios autorizados a la tabla de autorizaciones, la cual especifica lo que puede hacer un usuario una vez que se le ha dado acceso a ciertas relaciones o conjuntos de datos de la base de datos.

    Controles de salida.-

    Una vez que se produce la salida, deberán existir ciertos controles para asegurar que esta salida no se pierda, corrompa o sea robada. Por lo general, los controles más extensos se aplican a la salida en lotes debido a que en la producción y distribución de las copias en papel está involucrado un mayor número de personas.

    La salida en línea por pantalla, normalmente requiere menores controles debido a la interfaz directa usuario/ sistema y a controles de acceso más estrechos.

    PROYECCIÓN DEL ANÁLISIS A LA BASE DE DATOS

    En estos casos, el analista de sistemas no afecta el diseño de l base de datos sino que consulta al administrador.

    A su vez el papel del administrador de base de datos incluye las siguientes responsabilidades:

    • Evaluar la conveniencia de la solicitud del analista.
    • Describir los métodos para interactuar con la base de datos.
    • Asegurar que la aplicación no pueda dañar la base de datos o que la afecte de manera adversa a las necesidades de otros sistemas de información.

    PROYECCIÓN DEL ANÁLISIS A LOS PROCESOS (PROGRAMAS)

    Hasta el momento, en la fase del diseño detallado, el analista de sistemas ha especificado las entradas, las salidas, la base de datos, los controles y los procedimientos para el nuevo sistemas de información. Si el nuevo sistema de información requiere hardware o software de sistemas adicionales, el analista de sistemas ya se habrá ocupado de que el proceso de abastecimiento de dichos recursos está en camino.

    El diseño detallado de los programas requiere concentrar los esfuerzos del analista de sistemas en definir los programas que formaron el sistema de información, los módulos detallados de cada programa y las relaciones entre los módulos y los programas.

    Definición de programas.-

    El objetivo de la definición de programas es la preparación de una descripción de cada programa del sistemas de información. El analista de sistemas podría empezar agrupando las salidas que serán producidas por el sistema de información.

    Luego se podría diseñar un programa para generar cada grupo de salida. Para las entradas podría seguirse un proceso similar de agrupamiento y designación, comparando tareas tales como validación y edición de la entrada. Si los datos necesitan ordenarse, entonces podría definirse otros programas de utilería.

    Este proceso de agrupar las entradas y las salidas y luego pensar en las transformaciones necesarias para pasar de la entrada a la salida, produce una lista de programas.

    Esta lista contendrá el nombre, número en clave, y una definición breve de cada programa del sistema de información.

    PROYECCIÓN DEL ANÁLISIS A LOS PROCEDIMIENTOS

    Uno de lo principales beneficios del diseño de los sistemas es la generación automática de documentación y procedimientos como un subproducto del desarrollo de trabajo en sistemas. Para cuando uno ha concluido la fase del diseño detallado de sistemas, se han completado entre muchas otras cosas, los procedimientos tanto para los programas de aplicaciones como para el personal.

    El inglés estructurado, los diagramas de flujo de datos y el diseño detallado de la salida, la entrada, la base de datos, los controles y los procedimientos, proporcionan especificaciones suficientes para permitir a los programadores escribir el código.

    Cuando el programador de aplicaciones termina un programa, entonces se agregan detalles adicionales como el número de identificación del programa, el lenguaje de control de trabajos (JCL), los procedimientos de prueba y el listado fuente para formar un paquete completo de la documentación del programa de aplicaciones.

    Los analistas de sistemas también identifican las actividades realizadas por el personal. Se escriben procedimientos para guiar al personal en sus tareas, de manera similar a los procedimientos escritos para los programas de aplicaciones.

    Se presenta un ejemplo de captura de pedidos para ilustrar los procedimientos escritos para los programadores de aplicaciones, seguido de los procedimientos de descuento por pago en efectivo para el personal de ventas y de captura de pedidos.

    PROPUESTA DEL SISTEMA

    CONCLUSIÓN DEL ANÁLISIS DE SISTEMAS

    A lo largo de toda la fase del análisis de sistemas, el analista deberá mantener una extensa comunicación con el solicitante, y demás personal de proyectos. Esta comunicación comienza con el reporte de la propuesta para realizar el análisis de sistemas que se describió anteriormente.

    En forma continua este esfuerzo de comunicación incluye una retroalimentación a las personas entrevistadas, u observadas, con relación a lo que el analista atiende; la verificación con el personal usuario con respecto a los hallazgos en otras funciones o actividades relacionadas que el analista identifique y reuniones periódicas para informar a la gerencia y demás personal del proyecto acerca del progreso, situación y apego al calendario.

    PREPARACIÓN DEL REPORTE ESCRITO

    Reporte de terminación del análisis de sistemas

    Quizás es la comunicación mas importante de todas, que describe los hallazgos del análisis de sistemas. El formato y contenido de este reporte incluye lo siguiente:

    1. Una nueva exposición de la razón y alcance del análisis.
    2. Una lista de los principales problemas identificados.
    3. Una presentación de todos los requerimientos de los usuarios.
    4. Un planteamiento de todas la suposiciones críticas hechas por el analista durante el análisis.
    5. Una proyección de los recursos requeridos y los costos esperados que estarán involucrados en el diseño de cualquier nuevo sistema o en la modificación del sistema actual.
    6. Cualquier recomendación referente al sistema propuesto o a sus requerimientos.

    PREPARACIÓN ORAL DEL REPORTE

    La simple entrega de los reportes de sistemas no es suficiente. Es necesaria una presentación oral para una comunicación clara del trabajo realizado. Cuatro métodos para la presentación oral de los reportes de sistemas son la memorización, la presentación improvisada, la lectura, y el método extemporáneo.

    MEMORIZADA

    Una presentación memorizada es eficaz en cierta forma y le proporciona a uno un sentimiento de seguridad, pero a costa de una libertad y frescura, incluso en la presentación memorizada, se necesita tener un bosquejo para el caso en que uno se pierde.

    IMPROVISADA

    El método improvisado es una presentación sin ensayo y no se recomienda en absoluto para la presentación de los reportes del sistema. Debido a que uno es el autor de estos reportes, se podría considerar que no es necesario revisarlos; sin embargo, sino se hace, se olvidarán los puntos principales y se tenderá a divagar.

    LECTURA

    La lectura de los reportes puede describirse en una palabra arrullo; es una pastilla para dormir la lectura de los reportes, además de la incapacidad para mantener un contacto visual.

    EXTEMPORÁNEA

    El método extemporáneo es la mejor forma de presentar los reportes. Si uno ha hecho su tarea y conoce sus reportes de pies a cabeza, entonces éste es el método de entrega más versátil y expresivo. Se es espontáneo y enérgico. Uno se puede adaptar fácilmente a tópicos y situaciones que no estaban planeadas.

    ALTERNATIVAS DE SOLUCIÓN

    1. Parar el trabajo.- Este resultado significa que ya no se va a realizar más trabajo y que el trabajo en sistemas y los recursos deberán dirigirse hacia otros trabajos. Este resultado podría presentarse debido a que una propuesta no cumple las consideraciones de factibilidad, debido a un cambio en las decisiones de la gerencia o del solicitante, o debido a un reordenamiento de las prioridades de los sistemas.
    2. Estado de espera.- Este resultado es bastante común y generalmente se da por una falta de fondos o una actitud conservadora de la gerencia.
    3. Modificar.- Este resultado significa que la gerencia decide que algunos aspectos de la propuesta se deben cambiar o combinar con otros subsistemas.
    4. Proceder bajo condición.- Este resultado significa que el trabajo en sistemas proseguirá según se propuso, pero que la propuesta del diseño final antes de la implementación tendrá que justificarse en base a la factibilidad.
    5. Proceder sin condiciones.- Muchas propuestas de sistemas o subsistemas son autorizadas por la gerencia con un conocimiento total de que los costos superaron los beneficios medibles.

    DOCUMENTACIÓN DEL ANÁLISIS PRELIMINAR

    El reporte está dirigido a dos receptores diferentes. Primeramente, el gerente para determinar si el analista ha realizado un trabajo competente.

    El segundo lugar a la gerencia general y a la gerencia de los usuarios para determinar si el analista ha considerado o no todos los requerimientos de la organización.

    Para proporcionar un reporte significativo a estas dos partes interesadas, el analista deberá esforzarse por ser conciso pero completo al preparar el reporte. Los requerimientos deberán cuantificarse y explicarse de manera específica.

    El analista deberá evitar en el reporte el lenguaje técnico y los acrónimos. Deberán anexarse exposiciones y los documentos de trabajo que se utilizaron en el análisis de sistemas.

     

    Rocío García