SlideShare una empresa de Scribd logo
ANÁLISIS Y DISEÑO
ESTRUCTURADO DE
SISTEMAS
Análisis de requerimientos
Conjunto de técnicas y procedimientos que nos
permiten conocer los elementos necesarios para
definir un proyecto de software.
 La IEEE los divide en:




                                              resolver un problema o
                           Funcionales
                                                alcanzar un objetivo


                                              satisfacer un contrato, un
                                           estándar, una especificación u
                          No funcionales
                                            otro documento formalmente
                                                      impuesto
Actividades en la determinación de
requerimientos
   Actividad                        Descripción
 Anticipación de    Prever las características del sistema con base
 requerimientos     a la experiencia previa. Esto puede llevar al
                    analista a investigar áreas y aspectos que de
                    otra forma no serían tomados en cuenta.

Investigación de    Estudio y documentación del sistema actual
 requerimientos     utilizando para ello técnicas para hallar
                    hechos, análisis de flujo de datos y análisis de
                    decisión.

Especificación de   Análisis de los datos que describen el sistema
 requerimientos     para determinar que tan bueno es su
                    desempeño, qué requerimientos se deben
                    satisfacer y las estrategias para alcanzarlos.
Especificaciones de
requerimiento
   Es la descripción de las características del
    nuevo sistema. Tiene 3 partes relacionadas
    entre sí:
            Análisis de datos basados en hechos
            reales

              Identificación de requerimientos
              esenciales

            Selección de estrategias para satisfacer
            los requerimientos
Análisis de requerimientos

   Se debe establecerse la comunicación
    necesaria para el análisis, de forma que se
    asegure el reconocimiento del problema.
   El analista debe establecer contacto con el
    equipo técnico y de gestión del usuario/cliente
    y con la empresa que vaya a desarrollar el
    software.
   El objetivo del analista es reconocer los
    elementos básicos del programa tal como lo
    percibe el usuario/cliente.
Análisis de requerimientos
   El analista debe evaluar el flujo y estructura de
    la información
   Refinar en detalle todas las funciones del
    programa
   Establecer las características de la interface
    del sistema
   Una vez que se hayan descrito las
    funcionalidades básicas, comportamiento,
    interface e información, se especifican los
    criterios de validación para demostrar una
    comprensión de una correcta implementación
    de los programas.
Requerimientos básicos
   ¿Cuál es el proceso básico de la empresa?
   ¿Qué datos utiliza o produce este proceso?
   ¿Cuáles son los límites impuestos por el
    tiempo y la carga de trabajo?
   ¿Qué controles de desempeño utiliza?
Requerimientos básicos
Para comprender el proceso, se debe responder
estas interrogantes:
 ¿Cuál es la finalidad de esta actividad dentro de
  la empresa?
 ¿Qué pasos se siguen para llevarla a cabo?

 ¿Dónde se realizan estos pasos?

 ¿Quiénes lo realizan?

 ¿Cuánto tiempo tardan en efectuarlos?

 ¿Con cuánta frecuencia lo hacen?

 ¿Quiénes emplean la información resultante?
Requerimientos de las
 transacciones de los usuarios
Para conocer y entender los requerimientos de las
transacciones, los analistas sin lugar a dudas formulan
preguntas como:
 ¿Qué es lo que forma parte de la transacción que está
   siendo procesada?
 ¿Qué es lo que inicia la transacción?

 ¿Quién inicia la transacción?

 ¿Con qué propósito?

 ¿Con que frecuencia ocurre?

 ¿Qué volumen esta asociado a la transacción?

 ¿Existen diferentes condiciones que pueden afectar la
   forma en que se procesan las transacciones?
 ¿Qué detalles son necesarios para procesar la
   transacción?
Requerimientos de decisión de los
    usuarios
   Los analistas que investigan los sistemas para el
    soporte de las decisiones deberán considerar otras para
    determinar los requerimientos de las decisiones:
   ¿Que información se utiliza para tomar una decisión?
   ¿Cuál es la fuente de más información?
   ¿Qué sistema transaccional produce datos utilizados en
    el proceso de la decisión?
   ¿Qué otros datos son necesarios y no es posible
    obtener del proceso transaccional?
   ¿Que datos originan las fuentes externas a la
    organización?
   ¿Cómo se deben procesar los datos para producir
    información necesaria?
Requerimientos de la
organización

   Cuando los analistas estudian sistemas para
un     departamento   también     evalúa   las
implicaciones para los demás departamentos
con los que interactúa el sistema bajo
investigación.
Técnicas para encontrar
hechos

    Entrevistas

      Cuestionarios

      Revisión de los registros

    Observación
Diagrama de flujo de datos

  Los diagramas de flujos de datos son una
técnica de análisis estructurado que van de
lo general a lo específico muestran las
posibles entradas, procesos y salidas del
sistema.
  Los diagramas son usados cuando los
analistas   tratan    de    comprender    los
requerimientos de información de los usuarios
de una manera gráfica utilizando solo cuatro
símbolos combinados entre sí.
Diagrama de flujo de datos
Tiene cuatro ventajas principales de la forma en
que se mueven los datos a través del sistema,
estas son:

1. Libertad para realizar en forma muy temprana la
implementación técnica del sistema.
2. Comprensión de las interrelaciones de los
sistemas y subsistemas.
3. Comunicación del conocimiento del sistema
actual a los usuarios por medio del diagrama de
flujo de datos.
4. Análisis de un sistema propuesto para
determinar si han sido definidos los datos y
procesos necesarios.
Entidad Externa
   Representa personas, organizaciones, o sistemas que no
    pertenecen al sistema.
   En el caso de que las entidades externas se comunicasen
    entre sí, esto no se contemplaría en el diagrama, por estar
    fuera del ámbito de nuestro sistema
   Puede aparecer en los distintos niveles de DFD para
    mejorar su comprensión, aunque normalmente sólo
    aparecerá en el diagrama de contexto.
   Pueden aparecer varias veces en un mismo diagrama,
    para evitar entrecruzamientos de líneas.
   Suministra información acerca de la conexión del sistema
    con el mundo exterior.
Procesos
   Cuando un flujo de datos entra en un proceso
    sufre una transformación. Un proceso no es
    origen ni final de los datos, sólo lugar de
    transformación de ellos.
   Un proceso puede trasformar un dato en
    varios.
   Es necesario un proceso entre una Entidad
    Externa y un Almacén de datos.
   Un proceso puede representarse señalando
    una localización. La localización expresa la
    unidad o área dentro de la organización donde
    se realiza el proceso.
Almacén de Datos
   Representa la información en reposo
   No puede crear, destruir ni transformar datos
   No puede estar comunicado directamente con otro
    almacén o Entidad externa
   El flujo de datos (Entrada y Salida) no lleva nombre
    cuando incide sobre su contenido completo
   No debe estar referido al entorno físico, y por tanto,
    no se diferencian los ficheros convencionales de las
    bases de datos
   No se representa la clave de acceso a este almacén
    sino sólo la operación que se realiza (lectura,
    escritura, actualización)
Diagrama de flujo de datos

Utilizan cuatro símbolos básicos como los son (Gane y
Sarson):
  un cuadrado para representar las
    entidades del sistema
  una flecha para representar los
    flujos dentro del sistema
  un rectángulo con esquinas
    redondas para representar los
    procesos
  un rectángulo con un lado abierto

    para representar los
    almacenamientos de datos.
Descomposición por Niveles
   El desarrollo de un DFD ayuda en la
    identificación de los datos de la transacción en
    el modelo de datos.
   Sus niveles son:
      Nivel 0: Diagrama de contexto.
      Nivel 1: Diagrama de nivel superior.
      Nivel 2: Diagrama de detalle o expansión.
Diagrama de Contexto: Nivel 0
   En el diagrama de contexto se caracterizan todas
    las interacciones que realiza un sistema con su
    entorno (entidades externas)
   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.
   Resulta de gran utilidad para los niveles
    posteriores de análisis como herramienta de
    balanceo.
Diagrama de Nivel Superior:
Nivel 1
   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
Diagrama     de    Detalle                     o
Expansión: Nivel 2
   En un diagrama de nivel 2 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.
   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.
Anáilisis de requerimientos y DFD
Anáilisis de requerimientos y DFD
Actividad

         Genere un diagrama de flujo de
          datos para una biblioteca que
          necesita gestionar el préstamo y
          devolución de libros

Más contenido relacionado

PPT
Diagramas de clases
PPTX
MODELO COCOMO (INGENIERA DE SOFTWARE)
PPT
Clase: Uso correcto de subprocesos bpmn
PDF
42 preguntas que deberias hacerte antes de abordar un proyecto
DOCX
Doc. lista de requerimientos ver. 1.0
PPTX
Métricas de procesos y proyectos
PPT
Pruebas De Software
PPTX
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Diagramas de clases
MODELO COCOMO (INGENIERA DE SOFTWARE)
Clase: Uso correcto de subprocesos bpmn
42 preguntas que deberias hacerte antes de abordar un proyecto
Doc. lista de requerimientos ver. 1.0
Métricas de procesos y proyectos
Pruebas De Software
Estándar IEEE 830-1998 - Especificacón de requisitos de Software

La actualidad más candente (20)

PPT
Curso Java Inicial 5 Relaciones Entre Objetos
PDF
5.comprensión de los requerimientos
PPTX
casos de uso
PPTX
Modelado del sistema
PDF
Metodologías De Diseño Y Desarrollo De Sistemas De Información
PPT
Modelo Del Negocio con RUP y UML Parte 2
PPTX
Sistemas paralelos vs distribuidos
DOCX
Requerimientos funcionales y no funcionales de la aplicación
DOC
Desarrollo de aplicaciones web con casos de uso
PPTX
Exposición Diagrama de Clases
PDF
C4model - Arquitectura de Software
PPT
Uml presentacion
DOCX
Elementos del BPMN
PDF
Diagrama de clases - Ejemplo monográfico 02
PDF
Concepto y extensiones de negocio de Eriksson Penker
PPTX
Modelos de proceso evolutivo
PPTX
Uml lenguaje unificado de modelado
PPTX
Ingeniería de requisitos y de requerimientos
PPT
Diagrama de contexto
Curso Java Inicial 5 Relaciones Entre Objetos
5.comprensión de los requerimientos
casos de uso
Modelado del sistema
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Modelo Del Negocio con RUP y UML Parte 2
Sistemas paralelos vs distribuidos
Requerimientos funcionales y no funcionales de la aplicación
Desarrollo de aplicaciones web con casos de uso
Exposición Diagrama de Clases
C4model - Arquitectura de Software
Uml presentacion
Elementos del BPMN
Diagrama de clases - Ejemplo monográfico 02
Concepto y extensiones de negocio de Eriksson Penker
Modelos de proceso evolutivo
Uml lenguaje unificado de modelado
Ingeniería de requisitos y de requerimientos
Diagrama de contexto
Publicidad

Similar a Anáilisis de requerimientos y DFD (20)

PPTX
Diseño de Sistemas
PPTX
Eje temático Nº 1 - Diseño de Sistemas
PPTX
Analisis de sistemas
PPTX
Analisis de sistemas
PPTX
Primer Eje Temático - Diseño de Sistemas
PPTX
Presentacion de larry unidad 2
PPTX
Análisis de sistemas fases del diseño de sistemas
PPTX
Diseño estructurado
PPT
Análisis
PPTX
Unidad 3 TÉCNICAS PARA EL ANALISIS DE REQUERIMIENTO
PDF
Revista TicNews Enero 2015
PDF
Clase Practica3 Requerimientos del Negocio Modelos RdeS 2015.pdf
PPT
TIC como Herramienta para la Informática Educativa
PPT
Introduccion al análisis de sistemas de información
PDF
Diagrama de Flujo de Datos
PDF
Ciclo de-vida-de-un-sistema-1
PPS
Sistemas de informacion
PDF
Ciclo de vida de un sistema
PDF
Anlisisydiseodesistemas
PPTX
Diapositivas ciclo
Diseño de Sistemas
Eje temático Nº 1 - Diseño de Sistemas
Analisis de sistemas
Analisis de sistemas
Primer Eje Temático - Diseño de Sistemas
Presentacion de larry unidad 2
Análisis de sistemas fases del diseño de sistemas
Diseño estructurado
Análisis
Unidad 3 TÉCNICAS PARA EL ANALISIS DE REQUERIMIENTO
Revista TicNews Enero 2015
Clase Practica3 Requerimientos del Negocio Modelos RdeS 2015.pdf
TIC como Herramienta para la Informática Educativa
Introduccion al análisis de sistemas de información
Diagrama de Flujo de Datos
Ciclo de-vida-de-un-sistema-1
Sistemas de informacion
Ciclo de vida de un sistema
Anlisisydiseodesistemas
Diapositivas ciclo
Publicidad

Más de Angela Inciarte (20)

PDF
Investigación Grupo7 corregida
PDF
Investigación Grupo 7
DOCX
Módulo II (Grupo 7)
PPT
Diccionario de datos
PPTX
Páginas web II
PPTX
Páginas web (1)
PPTX
Análisis de requerimientos y DFD (II)
PPTX
Ciclo de vida y bases de datos
PPTX
Fundamentos de los sistemas de información
PPT
Base de Datos - Modelo Entidad Relación
PPT
Unidad III
PPT
Unidad II
PPT
Unidad I
PPTX
Bloque Académico - FATLA
PDF
PDF
Suscripcion a una red en Ning
PDF
Creacion de redes en Ning
PDF
Creacion de la cuenta en Delicious
PPT
Planificacion
Investigación Grupo7 corregida
Investigación Grupo 7
Módulo II (Grupo 7)
Diccionario de datos
Páginas web II
Páginas web (1)
Análisis de requerimientos y DFD (II)
Ciclo de vida y bases de datos
Fundamentos de los sistemas de información
Base de Datos - Modelo Entidad Relación
Unidad III
Unidad II
Unidad I
Bloque Académico - FATLA
Suscripcion a una red en Ning
Creacion de redes en Ning
Creacion de la cuenta en Delicious
Planificacion

Último (20)

DOCX
2 GRADO UNIDAD 5 - 2025.docx para primaria
DOCX
V UNIDAD - SEGUNDO GRADO. del mes de agosto
PDF
OK OK UNIDAD DE APRENDIZAJE 5TO Y 6TO CORRESPONDIENTE AL MES DE AGOSTO 2025.pdf
PDF
Educación Artística y Desarrollo Humano - Howard Gardner Ccesa007.pdf
PDF
Cronograma de clases de Práctica Profesional 2 2025 UDE.pdf
PDF
Tomo 1 de biologia gratis ultra plusenmas
PDF
Salcedo, J. et al. - Recomendaciones para la utilización del lenguaje inclusi...
PDF
Escuela Sabática 6. A través del Mar Rojo.pdf
PDF
Romper el Circulo de la Creatividad - Colleen Hoover Ccesa007.pdf
PDF
Escuelas Desarmando una mirada subjetiva a la educación
PDF
biología es un libro sobre casi todo el tema de biología
PPTX
caso clínico iam clinica y semiología l3.pptx
PDF
el - LIBRO-PACTO-EDUCATIVO-GLOBAL-OIEC.pdf
PDF
Didactica de la Investigacion Educativa SUE Ccesa007.pdf
PDF
Crear o Morir - Andres Oppenheimer Ccesa007.pdf
PDF
COMPLETO__PROYECTO_VIVAN LOS NIÑOS Y SUS DERECHOS_EDUCADORASSOS.pdf
PPTX
AGENTES PATÓGENOS Y LAS PRINCIPAL ENFERMEAD.pptx
PDF
Salvese Quien Pueda - Andres Oppenheimer Ccesa007.pdf
PDF
Gasista de unidades unifuncionales - pagina 23 en adelante.pdf
PDF
Breve historia de los Incas -- Patricia Temoche [Temoche, Patricia] -- Breve ...
2 GRADO UNIDAD 5 - 2025.docx para primaria
V UNIDAD - SEGUNDO GRADO. del mes de agosto
OK OK UNIDAD DE APRENDIZAJE 5TO Y 6TO CORRESPONDIENTE AL MES DE AGOSTO 2025.pdf
Educación Artística y Desarrollo Humano - Howard Gardner Ccesa007.pdf
Cronograma de clases de Práctica Profesional 2 2025 UDE.pdf
Tomo 1 de biologia gratis ultra plusenmas
Salcedo, J. et al. - Recomendaciones para la utilización del lenguaje inclusi...
Escuela Sabática 6. A través del Mar Rojo.pdf
Romper el Circulo de la Creatividad - Colleen Hoover Ccesa007.pdf
Escuelas Desarmando una mirada subjetiva a la educación
biología es un libro sobre casi todo el tema de biología
caso clínico iam clinica y semiología l3.pptx
el - LIBRO-PACTO-EDUCATIVO-GLOBAL-OIEC.pdf
Didactica de la Investigacion Educativa SUE Ccesa007.pdf
Crear o Morir - Andres Oppenheimer Ccesa007.pdf
COMPLETO__PROYECTO_VIVAN LOS NIÑOS Y SUS DERECHOS_EDUCADORASSOS.pdf
AGENTES PATÓGENOS Y LAS PRINCIPAL ENFERMEAD.pptx
Salvese Quien Pueda - Andres Oppenheimer Ccesa007.pdf
Gasista de unidades unifuncionales - pagina 23 en adelante.pdf
Breve historia de los Incas -- Patricia Temoche [Temoche, Patricia] -- Breve ...

Anáilisis de requerimientos y DFD

  • 2. Análisis de requerimientos Conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. La IEEE los divide en: resolver un problema o Funcionales alcanzar un objetivo satisfacer un contrato, un estándar, una especificación u No funcionales otro documento formalmente impuesto
  • 3. Actividades en la determinación de requerimientos Actividad Descripción Anticipación de Prever las características del sistema con base requerimientos a la experiencia previa. Esto puede llevar al analista a investigar áreas y aspectos que de otra forma no serían tomados en cuenta. Investigación de Estudio y documentación del sistema actual requerimientos utilizando para ello técnicas para hallar hechos, análisis de flujo de datos y análisis de decisión. Especificación de Análisis de los datos que describen el sistema requerimientos para determinar que tan bueno es su desempeño, qué requerimientos se deben satisfacer y las estrategias para alcanzarlos.
  • 4. Especificaciones de requerimiento  Es la descripción de las características del nuevo sistema. Tiene 3 partes relacionadas entre sí: Análisis de datos basados en hechos reales Identificación de requerimientos esenciales Selección de estrategias para satisfacer los requerimientos
  • 5. Análisis de requerimientos  Se debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del problema.  El analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y con la empresa que vaya a desarrollar el software.  El objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el usuario/cliente.
  • 6. Análisis de requerimientos  El analista debe evaluar el flujo y estructura de la información  Refinar en detalle todas las funciones del programa  Establecer las características de la interface del sistema  Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interface e información, se especifican los criterios de validación para demostrar una comprensión de una correcta implementación de los programas.
  • 7. Requerimientos básicos  ¿Cuál es el proceso básico de la empresa?  ¿Qué datos utiliza o produce este proceso?  ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?  ¿Qué controles de desempeño utiliza?
  • 8. Requerimientos básicos Para comprender el proceso, se debe responder estas interrogantes:  ¿Cuál es la finalidad de esta actividad dentro de la empresa?  ¿Qué pasos se siguen para llevarla a cabo?  ¿Dónde se realizan estos pasos?  ¿Quiénes lo realizan?  ¿Cuánto tiempo tardan en efectuarlos?  ¿Con cuánta frecuencia lo hacen?  ¿Quiénes emplean la información resultante?
  • 9. Requerimientos de las transacciones de los usuarios Para conocer y entender los requerimientos de las transacciones, los analistas sin lugar a dudas formulan preguntas como:  ¿Qué es lo que forma parte de la transacción que está siendo procesada?  ¿Qué es lo que inicia la transacción?  ¿Quién inicia la transacción?  ¿Con qué propósito?  ¿Con que frecuencia ocurre?  ¿Qué volumen esta asociado a la transacción?  ¿Existen diferentes condiciones que pueden afectar la forma en que se procesan las transacciones?  ¿Qué detalles son necesarios para procesar la transacción?
  • 10. Requerimientos de decisión de los usuarios  Los analistas que investigan los sistemas para el soporte de las decisiones deberán considerar otras para determinar los requerimientos de las decisiones:  ¿Que información se utiliza para tomar una decisión?  ¿Cuál es la fuente de más información?  ¿Qué sistema transaccional produce datos utilizados en el proceso de la decisión?  ¿Qué otros datos son necesarios y no es posible obtener del proceso transaccional?  ¿Que datos originan las fuentes externas a la organización?  ¿Cómo se deben procesar los datos para producir información necesaria?
  • 11. Requerimientos de la organización Cuando los analistas estudian sistemas para un departamento también evalúa las implicaciones para los demás departamentos con los que interactúa el sistema bajo investigación.
  • 12. Técnicas para encontrar hechos Entrevistas Cuestionarios Revisión de los registros Observación
  • 13. Diagrama de flujo de datos Los diagramas de flujos de datos son una técnica de análisis estructurado que van de lo general a lo específico muestran las posibles entradas, procesos y salidas del sistema. Los diagramas son usados cuando los analistas tratan de comprender los requerimientos de información de los usuarios de una manera gráfica utilizando solo cuatro símbolos combinados entre sí.
  • 14. Diagrama de flujo de datos Tiene cuatro ventajas principales de la forma en que se mueven los datos a través del sistema, estas son: 1. Libertad para realizar en forma muy temprana la implementación técnica del sistema. 2. Comprensión de las interrelaciones de los sistemas y subsistemas. 3. Comunicación del conocimiento del sistema actual a los usuarios por medio del diagrama de flujo de datos. 4. Análisis de un sistema propuesto para determinar si han sido definidos los datos y procesos necesarios.
  • 15. Entidad Externa  Representa personas, organizaciones, o sistemas que no pertenecen al sistema.  En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema  Puede aparecer en los distintos niveles de DFD para mejorar su comprensión, aunque normalmente sólo aparecerá en el diagrama de contexto.  Pueden aparecer varias veces en un mismo diagrama, para evitar entrecruzamientos de líneas.  Suministra información acerca de la conexión del sistema con el mundo exterior.
  • 16. Procesos  Cuando un flujo de datos entra en un proceso sufre una transformación. Un proceso no es origen ni final de los datos, sólo lugar de transformación de ellos.  Un proceso puede trasformar un dato en varios.  Es necesario un proceso entre una Entidad Externa y un Almacén de datos.  Un proceso puede representarse señalando una localización. La localización expresa la unidad o área dentro de la organización donde se realiza el proceso.
  • 17. Almacén de Datos  Representa la información en reposo  No puede crear, destruir ni transformar datos  No puede estar comunicado directamente con otro almacén o Entidad externa  El flujo de datos (Entrada y Salida) no lleva nombre cuando incide sobre su contenido completo  No debe estar referido al entorno físico, y por tanto, no se diferencian los ficheros convencionales de las bases de datos  No se representa la clave de acceso a este almacén sino sólo la operación que se realiza (lectura, escritura, actualización)
  • 18. Diagrama de flujo de datos Utilizan cuatro símbolos básicos como los son (Gane y Sarson):  un cuadrado para representar las entidades del sistema  una flecha para representar los flujos dentro del sistema  un rectángulo con esquinas redondas para representar los procesos  un rectángulo con un lado abierto para representar los almacenamientos de datos.
  • 19. Descomposición por Niveles  El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos.  Sus niveles son: Nivel 0: Diagrama de contexto. Nivel 1: Diagrama de nivel superior. Nivel 2: Diagrama de detalle o expansión.
  • 20. Diagrama de Contexto: Nivel 0  En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas)  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.  Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo.
  • 21. Diagrama de Nivel Superior: Nivel 1  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
  • 22. Diagrama de Detalle o Expansión: Nivel 2  En un diagrama de nivel 2 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.  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.
  • 25. Actividad  Genere un diagrama de flujo de datos para una biblioteca que necesita gestionar el préstamo y devolución de libros