Diagramas Funcionales y de Arbol

 

REPÚBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA INSTITUTO UNIVERSITARIO POLITÉCNICO “SANTIAGO MARIÑO”

EXTENSIÓN MARACAY

Diagramas Funcionales, Diccionario de Datos, Diseño de Pruebas y Documentación de sistemas

DOCENTE: 

ING. LILIANGEL CÁRDENAS 

Análisis y Diseño de Sistemas  SECION SL 

INTEGRANTE 

SANCHEZ ALEXANDER V-22.956.799 

 

Diagrama funcional y diagrama de árbol

Diagrama funcional:

Representación gráfica o dibujo de figuras geométricas que sirve para mostrar el funcionamiento; ya sea, una institución, empresa, equipo, club o una máquina o teoría t eoría científica. El diagrama muestra el conjunto en su totalidad, sus figuras geométricas por lo general están escritas dentro con una letra, nombre o número que las identifica y distingue de las demás. Las figuras van acompañadas de líneas que unen a una con otras demostrando así los pasos que envuelven el funcionamiento del objeto que representan. la mayoría de las veces va acompañada con una leyenda o explicación debajo del dibujo, otras veces las explicaciones están contenidas dentro de las figuras geométricas. Las entradas y salidas de los bloques se conectan entre sí con líneas de conexión o enlaces. Las líneas sencillas se pueden utilizar para conectar dos puntos lógicos del diagrama, es decir:

Una variable de entrada y una entrada de un bloque Una salida de un bloque y una entrada de otro ot ro bloque Una salida de un bloque y una variable de salida Se muestran las relaciones existentes entre los procesos y el flujo de señales de forma más realista que una representación matemática.

 

 

Diagrama de Árbol:

Un árbol es ampliamente utilizado estructura de datos que emula una estructura jerárquica árbol de la estructura con un conjunto de vinculados nodos. Un diagrama de árbol es un método gráfico para identificar todas las partes necesarias para alcanzar alcanzar algún objetivo final. En mejora de la calidad, los diagramas de árbol se utilizan generalmente para identificar todas las tareas necesarias para implantar una solución. solución. Se emplea para descomponer descomponer una meta u objetivo en una serie de actividades que deban o puedan hacerse. A través de la representación gráfica de actividades se facilita el entendimiento de las acciones que intervendrán. Permite a los miembros del equipo de trabajo expandir su pensamiento al crear soluciones sin perder de vista el objetivo principal o los objetivos secundarios. Ubica al equipo para que se dirija a situacion situaciones es reales versus teóricas. Asimismo, se dimensiona el nivel real de complejidad de algún proyecto y se puede prever el encontrarse con soluciones inviables antes del arranque. Para la construcción de un diagrama en árbol se partirá poniendo una rama para cada una de las posibilidades, acompañada de su probabilidad. Cada una de estas ramas se conoce como rama de primera generación. En el final de cada rama de primera generación se constituye a su vez, un nudo del cual parten nuevas ramas conocidas como ramas de segunda generación, según las posibilidades del siguiente paso, salvo si el nudo representa un posible final del experimentó (nudo final). Hay que tener en cuenta que la construcción de un árbol no depende de tener el mismo número de ramas de segunda generación que salen de cada rama de primera generación y que la suma de probabilidades de las ramas de cada nudo ha de DVD xh Existe un principio sencillo de los diagramas de árbol que hace que éstos sean mucho más útiles para los cálculos rápidos de probabilidad: multiplicamos las probabilidades si se trata de ramas adyacentes (contiguas), el ejemplo de alumna de la primera facultad, o bien las sumamos si se trata de ramas separadas que emergen de un mismo punto, el ejemplo de encontrar un alumno.

 

Diagrama de flujo de datos Un diagrama de flujo de datos o DFD Es un gráfico lógico del plan de trabajo que se ejecutara para la solución de un determinado problema. A través de él, se planifica la solución del problema independiente del lenguaje de computación a usar. De esta manera se separa loas instrucción es un lenguaje determinado con todas las reglas. Se utiliza para hacer varias cosas entre ellas trabajos y tareas. Es una representación gráfica del flujo de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas.

Tipos de diagramas de flujo: Diagrama de flujo de sistemas: Muestra en qué forma se procesan los datos, entre as principales funciones o estaciones de trabajo. En este diagrama completo de computadora se presenta con un solo símbolo de procesamiento. Diagrama de flujos de programación: Son las operaciones y decisiones en la secuencia en que las ejecutará una computadora de procesamiento de datos. Los símbolos representan esas operaciones e indican el orden en que se ejecutaran. Por lo ttanto, anto, un diagrama de flujo de programa proporciona una descripción gráfica del programa.

L os niveles de un DFD: Nivel 0: Diagrama de contexto: En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo. Nivel 1: Diagrama de nivel superior: En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un Requisito funcional, siendo en realidad un requisito no-funcional. Nivel 2: Diagrama de detalle o expans expansión: ión: En un diagrama diagrama de nivel 3 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos. El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama de nivel superior.

 

Simbología de los flujogramas Las diversas organizaciones usan distintos símbolos,  símbolos,  pero el comité sobre computadoras sobre  computadoras y procesadores de información de la Asociación Norteamericana de de Normas  Normas ha hecho un gran esfuerzo para normalizar los símbolos de los diagramas de flujo. Esa normalización Esa  normalización permite comprender cualquier diagrama de flujo que use los símbolos recomendados.

Cada símbolo normal de diagrama de flujo tiene un significado especial.

Expresa Inicio o Fin de un Programa. un  Programa.  

Expresa operación algebraica o de Asignación.

Expresa condiciones y asociaciones alternativas de una decisión lógica. decisión lógica.  

Expresa condición y acciones y acciones alternativas de una decisión numérica.

 

  Entrada / Salida: Representa cualquier tipo de Fuente de entrada y salida

Entrada: Lectura Entrada:  Lectura de datos por tarjeta perforadas.

Conector dentro de página.

Representa resultado mediante un reporte impreso

Conector fuera de página.

Expresa operación cíclica repetitiva.

Expresa proceso Expresa  proceso de llamada a una subalterna.

 

Diccionario de datos Un diccionario de datos, o repositorio de metadatos, un repositorio centralizado de información sobre datos tales como significado, relación con otros datos, origen, uso y formato. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos. Si los analistas desean conocer cuántos caracteres abarca un determinado dato o qué otro nombre recibe en distintas partes del sistema, o dónde se utiliza, encontrarán las respuestas en un diccionario de datos desarrollado en forma apropiada. El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos de sistemas. Fases a cumplir un diccionario de Datos: 1. Objetivo General y Objetivos Específicos del Sistema Propuesto

  Se identifica el Objetivo General del Sistema Propuesto Gener al, se identifican los Objetivos Específicos.   Al desagregar el Objetivo General,   Al usuario no le interesan los Objetivos del Proyecto, sino qué va a hacer el nuevo Sistema.



 

  Los objetivos a determinar son los del Sistema. ¡¡¡No los del proyecto!!! Un sistema no



puede tener como Objetivo “Desarrollar un Sistema”.  Sistema”. 

2. Identificación de Usuarios (Directos, Indirectos, y Usuarios de los Usuarios)

  Tradicionalmente, los usuarios son aquellos que se benefician del Sistema de Información.   El haber hecho un Organigrama de la empresa facilita su identificación.   Se identifican tres (3) tipos de usuarios: o  Usuarios Directos: los que van a operar directamente el Sistema de Información, y



 

van a interactuar con él. Pertenecen a la Unidad Funcional donde se desarrolla el Sistema. Indirectos: los supervisores de los Usuarios Directos, que, a pesar de no   Usuarios estar interactuando directamente con el Sistema, reciben información de él.

o

  Usuarios de los Usuarios: Entes externos a la Unidad Funcional o a la organización,

o

que proporcionan las entradas al sistema, y/o reciben sus salidas 3. Elaboración de Diagramas de Flujo de Datos del Sistema Actual través avés   Herramienta gráfica que se emplea para describir y analizar el movimiento de datos a tr



de un sistema.

       



Presenta una visión (lo más amplia posible) de las entradas, procesos y salidas del sistema



Es un modelo lógico de los datos del sistema No muestra control ni movimiento



Prácticamente no requiere explicación



  Permite modelar el sistema con símbolos gráficos



 

4. Elaboración del Diccionario de Datos del Sistema Actual

  Se reseñan Almacenes de Datos, Repositorios o Archivos o  Flujos de Datos o  Procesos o  re señan son del último nivel de resolución.   Normalmente los Flujos y Procesos que se reseñan





  Son los datos de los datos del sistema (metadatos)   Es un catálogo de los elementos de un sistema





Importancia           

  





Facilita el manejo de detalles en e n sistemas grandes Comunica un significado común a todos los elementos del sistema Documenta las características del sistema Localiza errores y omisiones Facilita el posterior mantenimiento del sistema

Existen dos tendencias razonadas, para usar un formato para el Diccionario de Datos en el Análisis, y otro formato para el Diccionario Dicc ionario de Datos en el Diseño. El DD en el Análisis no debe ser tan detallado, ya que sirve para e entender ntender cómo se llevan a cabo los procesos en la actualidad. 5. Recopilación de Reportes del Sistema Actual Ac tual

  Se hace una recopilación de los reportes actuales usados por la organización, a fin de



determinar la pertinencia y la necesidad de cada uno de ellos.

  Los reportes actuales pueden ser facturas, reportes, formatos.   La idea es que nos ayude a comprender mejor el sistema actual, y nos de una idea de cómo





son sus salidas. En muchos casos, nos ofrecen un punto de partida para el diseño de los reportes propuestos. 6. Elaboración de Procedimientos Propuestos

  De acuerdo con la recolección de información y entrevistas con los usuarios, se elaboran,



 



también a grosso modo, los Procedimientos Propuestos para el Sistema. La idea es que estos procedimientos alimenten el Nivel 1 del DFD propuesto.

Carta estructurada La carta estructurada también es conocida como el modelo de producto, es una metodología de análisis y diseño de sistemas de análisis estructurado, lo que muestra es un mapa de diseño de arriba hacia abajo (top-down) de tipo jerárquico en el que se asienta cómo será programado el proyecto, construido, integrado y probado.

 

Pasos para obtener una apropiada carta estructurada:

1) Fraccionar el sistema en unidades apropiadas a través del análisis de transacciones. 2) Convertir cada uno de esas unidades en una carta de estructura a través del análisis de transformaciones. 3) Refinar cada una de las cartas de estructuras obtenidas y vinculadas en la implantación del sistema. 4)Transacción: Es un componente del sistema que nace de algún evento que tiene lugar en el ambiente (fuera del sistema) y culmina con algún efecto o resultado sobre el ambiente. Tiene 5 pasos: 1) Evento. 2) Estimulo sobre el sistema. 3) Actividad que realiza el sistema de acuerdo acuer do con el estímulo. 4) Respuesta del sistema. 5) Efecto sobre el ambiente. Cada transacción pertenece a una clase o tipo de transacción, se identifican a tra través vés de los eventos del sistema.Cada unidad física del sistema surge a partir de un evento.

Análisis de Transformaciones: Es el método (estrategia) que permite darle una forma apropiada a la carta de estructura a través de la identificación de la transformación central. Pasos para el análisis de transformación: 1) Construir el DFD (diagrama de flujo de datos) para la transacción que pretendemos graficar. 2) Encontrar la transformación central dentro del DFD. 3) Convertir a esa unidad del DFD en una carta de estructura. 4) Refinar a la carta de estructura a través de los criterios del diseño estructurado. 5) Verificar que la carta de estructura cumpla con todos los requisitos planteados para el modelo esencial.

 

Flujo de datos esencial   Transformación central: Concatenamos la transformación central en el nivel más alto y subordinamos las demás burbujas/ramas.    Promoviendo: Debemos encontrar una burbuja que cumpla con las características, si hay





mas de una, hay que ver cual de ellas es mas adecuada.

Comentarios de los gráficos: • Agregar los módulos de leer/imprimir/grabar.  leer/imprimir/grabar.  • Reorganizar los módulos aferentes y eferentes manteniendo el balance (si resulta muy difícil es porque está mal hecho el DFD). • Agregar los módulos de tratamiento de errores. e rrores.   • Factorizar la transformación central si corresponde.  corresponde. 

Más comentarios: • Asegurarse de que todos todos los módulos tienen nombres concordantes con su rol jerárquico. • Incluir las señales que correspondan a funcionamiento de la transacción.  transacción.  • Tratar de que el acoplamiento sea el adecuado (identificar los datos e interfaces).  interfaces).  • mejorar la calidad de la carta ca rta de estructura.

Diseño de entrada, proceso y salida. Diseño de entradas: Diseñar el sistema de recopilación de datos. Las especifica especificaciones ciones de entrada describen la manera en que los datos ingresarán al sistema para su procesamiento. Las características de diseño de la entrada pueden asegurar la confiabilidad del sistema y producir resultados a partir de datos exactos, o también pueden dar como resultado la producción de información errónea. Asimismo, el diseño diseño de la entrada determina sí el usuario puede interactuar con el sistema de manera manera eficiente. El diseño de la entrada es el enlace que une une al sistema de información con el mundo y sus usuarios. Algunos aspectos del diseño cambian, lo que depende si el sistema está orientado hacia hacia lotes o en línea. Pero sin considerar el sistema, existen aspectos generales en la entrada que todos los analistas a nalistas deben tener en cuenta. El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los pasos necesarios para poner los datos de una transacción en una forma utilizable para su procesamiento, así como la entrada e ntrada de éstos.

 

Controles de la cantidad de entrada. Existen varias razones que explican por qué un buen diseño debe controlar la cantidad de datos en la entrada. Primero, las operaciones de preparación preparación y entrada dependen de las personas. Dado que los costos de la mano m ano de obra son altos, los asociados con la preparación e ingreso de los datos también lo son altos. Disminuir los requerimientos de datos puede reducir los costos costos y ocurrir lo mismo con los costos de mano de de obra. Segundo, la fase de entrada puede ser un proceso lento lento que toma mucho más tiempo que el que necesitan las computadoras para llevar a cabo sus tareas. De hecho, la computadora quizá permanezca sin hacer nada durante el tiempo en que se preparan los datos y la entrada para su procesamiento. Al disminuir lo loss requerimientos de la entrada, el analista puede acelerar todo el proceso proce so desde la captura de datos hasta que los resultados llegan a manos de los usuarios.

Diseño de procedimientos: procedimientos: Diseñar el sistema de de procesamiento de datos. Los procedimientos especifican qué tareas deben efectuarse al utilizar en sistema y quiénes son los responsables de llevarlas a cabo. Entre los procedimientos importantes se encuentran:

  Procedimientos para entrada de datos. Métodos para la captura de datos de las



 



 



transacciones y su ingreso en el sistema de información. Procedimientos durante la ejecución. Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios finales que interactúan con el sistema para alcanzar los resultados deseados. Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan resultados inesperados.

  Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus recursos



contra posibles daños.

Diseño de las salidas: Diseño del sistema de informes y producción de documentos. Se refiere a los resultados e información generados por el e l sistema. 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. En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresas datos en él, pero utilizan la salida generada por el sistema. Cuando diseñan la salida, los analistas deben de realizar lo siguiente: Determinar qué 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 de la información en un formato aceptable. Decidir cómo distribuir la salida entre los posibles destinatarios.

 

Diseño de las pruebas y documentación del sistema. Diseño de las pruebas.

Categorías de pruebas:

 



Según la naturaleza de la lo consistencia que se esté entre controlando, las pruebas yseelpueden dividir en dos categorías: Determina los requerimientos programa terminado. Soporta metodologías formales de testeo, de mucho componente matemático. De todas maneras, hay que ser cuidadoso, porque no suele ser fácil encontrar qué es lo que hay que demostrar.

  Pruebas centradas en la verificación: Consiste en determinar si estamos construyendo el



sistema correctamente, a partir de los requisitos.

  Pruebas centradas en la validación: Consiste en saber si estamos construyendo el sistema



correcto. Las tareas de validación son más informales. Las pruebas suelen mostrar la presencia de errores, pero nunca demuestran su ausencia.

Tipos de pruebas:          











Revisiones de código Pruebas unitarias Pruebas de integración Pruebas de sistema Pruebas de aceptación

Revisiones de código:  Las revisiones de código son las únicas que se podrían omitir de todos los tipos de pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas:

  Pruebas de escritorio: La prueba de escritorio rinde muy poco, tal vez menos de lo que



cuesta, pero es una costumbre difícil de desterrar. Es bueno concentrarse en buscar anomalías típicas, como variables u objetos no inicializados o que no se usan, ciclos infinitos y demás. escr ito   Recorridos de código: Los recorridos rinden mucho más. Son exposiciones del código escrito



frente a pares. El programador, exponiendo su código, encuentra muchos errores. Además da ideas avanzadas a programadores nuevos que se lleva a recorrer.

  Inspecciones de código: Consisten en reuniones en conjunto entre los responsables de la



programación y los responsables de la revisión. Tienen como objetivo revisar el código escrito por los programadores para chequear que cumpla con las normas que se hayan fijado y para verificar la eficiencia del mismo.

 

Pruebas unitarias: Las pruebas unitarias se realizan para controlar el funcionamiento de pequeñas porciones de código como ser subprogramas (en la programación estructurada) o métodos (en POO). Generalmente son realizadas por los mismos programadores puesto que al conocer con mayor detalle el código, se les simplifica la tarea de elaborar conjuntos de datos de prueba para ttestearlo. estearlo. Los métodos de cobertura de caja blanca tratan de recorrer todos los caminos posibles por lo menos una vez, lo que no garantiza que no haya errores er rores pero pretende e encontrar ncontrar la mayor parte.El tipo de prueba a la cual se someterá a cada uno de los módulos dependerá de su complejidad. Recordemos que nuestro objetivo aquí es encontrar la mayor cantidad de errores posible. Si se pretende realizar una prueba estructurada, se puede confeccionar un grafo de flujo con la lógica del código a probar. De esta manera se podrán determinar todos los caminos por los que el hilo de ejecución pueda llegar a pasar, y por consecuente elaborar los juegos de valores de pruebas para aplicar al módulo, con mayor facilidad y seguridad.

Documentación del sistema.

La documentación se suele clasificar en función de las personas p ersonas o grupos a los cuales está dirigida:

  Documentación para los desarrolladores: Es aquélla que se utiliza para el propio desarrollo



del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas.

  Documentación para los usuarios: Todo aquello que necesita el usuario para la instalación,



aprendizaje y uso del producto. Puede consistir en guías de instalación, guías del usuario, manuales de referencia3 y guías de mensajes. En el caso de los usuarios que son programadores, verbigracia los clientes de nuestras clases, esta documentación se debe acompañar con ejemplos de uso recomendados o de muestra y una reseña de efectos no evidentes de las bibliotecas.

  Documentación para los administradores o soporte técnico: a veces llamada manual de



operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. rec uperación. Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo.