Universidad Autónoma del Carmen
ISC
Ciencias de la Información.
Quinto Semestre.
EQUIPO:
Marcos Hiram Contreras Mendoza
Jose Angel Barradas Castañeda
Ivan Ismael Narvaez Lara
Alan Valor Villanueva
Lic. En Ing. En Sistemas Computacionales
Curso: Análisis y diseño de Sistemas I.
10/11/2022
TEMA:
Capítulo 7: Metodología de Yourdon.
Capítulo 9: Metodología de Yourdon.
CAPITULO 7.
CAMBIOS EN EL ANALISIS DE SISTEMAS
Para muchos profesionales del proceso de datos, el tecno-stress se define mejor como la
frustración que trae el lento cambio que se está dando en los métodos de desarrollo de
software, ante la siempre creciente demanda de servicios de procesamiento de datos.
EL MOVIMIENTO HACIA EL ANALISIS ESTRUCTURADO
Hasta fines de los años 70, la gran mayoría de los proyectos de desarrollo de sistemas
empezaban con la creación de una “novela victoriana” de requerimientos del usuario.
Es decir, el analista escribía lo que entendía de los requerimientos del usuario en un
enorme documento que consistía primariamente en una narrativa.
Los primeros autores de textos de “análisis estructurado", sobre todo [De Marco, 1978J,
[Gane y Sarson, 1977] y [Weinberg, 1978], señalaron que estos pesados tomos (a
menudos conocidos como “especificación funcional”) se veían afectados por diversos
problemas importantes;
• Eran monolíticos: había que leer completamente la especificación, de principio a fin,
para poder entenderla.
• Eran redundantes: a menudo se repetía la misma información en diversas partes del
documento.
• Eran ambiguas: el reporte detallado de los requerimientos podía ser (y a menudo era)
interpretado de diferente manera por el usuario, el analista, el diseñador y el
programador.
• Eran imposibles de mantener: por todas las razones descritas anteriormente, la
especificación funcional era casi obsoleta para cuando llegaba el final del proceso de
desarrollo del sistema (es decir, para cuando el sistema se ponía en operación), y a
menudo era obsoleto para el final de la fase de análisis.
Como resultado, ha habido un movimiento gradual (puesto que aceptarlo le ha llevado a
la profesión de desarrollo de sistemas alrededor de diez años) tendiente a hacer
especificaciones funcionales que sean:
• Gráficas: compuestas de una variedad de diagramas, apoyadas con material textual
detallado que, en muchos casos, sirve de material de referencia más que como cuerpo
principal de la especificación.
• Particionadas: de tal manera que se puedan leer independientemente porciones
individuales de la especificación.
• Mínimamente redundantes: de tal manera que los cambios en los requerimientos de
usuario puedan incorporarse normalmente en sólo una parte de la especificación.
Se pueden encontrar aún algunas organizaciones que produzcan especificaciones tipo
novela victoriana, pero son minoría y, como los dinosaurios, se extinguirán.
CAMBIOS EN EL ANALISIS ESTRUCTURADO CLASICO.
La mayoría de las organizaciones que ahora usan el análisis estructurado basan su
enfoque en los primeros textos de DeMarco, Gane y Sarson, y Weinberg y otros, al
igual que en seminarios, videos y otros materiales de capacitación basados en dichos
libros.
Los principales cambios son:
• El énfasis en la construcción de modelos “físicos actuales” y “lógicos actuales” del
sistema del usuario se han demostrado que es políticamente.
• El análisis estructurado clásico hacía una distinción difusa y poco definida entre los
modelos físicos (que hacen suposiciones acerca de la tecnología de la implantación o
están predispuestos por ésta) y los modelos lógicos (que son completamente
independientes de la tecnología de implantación).
• El análisis estructurado clásico se concentraba casi totalmente en modelar las
funciones que deberían llevarse a cabo en un sistema.
EL SURGIMIENTO DE HERRAMIENTAS AUTOMATIZADAS DE ANALISIS
los analistas comenzaron a percatarse de que existía un gran problema: el trabajo
necesario para crear diagramas de flujo de datos, diagramas de entidad-relación,
diagramas de estructura, diagramas de transición de estados y otros modelos gráficos a
menudo eran abrumadores.
La consecuencia práctica de esto, en muchas organizaciones, es que el análisis
estructurado clásico no fue tan exitoso como debiera ser. Se plantearon los siguientes
problemas:
• Tras la segunda y tercera correcciones de un diagrama, el analista se volvía cada vez
más opuesto y renuente a hacer más cambios.
• Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el
modelo del sistema en modelos de menor nivel.
• A menudo no se incorporaban en el modelo del sistema los cambios en los
requerimientos del usuario sino hasta después de la fase de análisis del proyecto.
CAPITULO 9.
DIAGRAMAS DE FLUJO DE DATOS
El diagrama de flujo de datos es una de las herramientas más comúnmente usadas,
sobre todo por sistemas operacionales en los cuales las funciones del sistema son de
gran importancia y son más complejas que los datos que éste maneja.
Los DFD se utilizaron por primera vez en la ingeniería de software como notación para
el estudio del diseño de sistemas.
LOS COMPONENTES DE UN DFD
los componentes de un diagrama típico de flujo de datos son: el proceso, el flujo, el
almacén y el terminador.
Antes de examinar sus componentes en detalle, nótese lo siguiente:
• Prácticamente no requiere explicación; se puede simplemente mirar el diagrama y
entenderlo.
• El diagrama cabe fácilmente en una página.
• El diagrama se dibujó con computadora.
El proceso
El primer componente del DFD se conoce como proceso. Los sinónimos comunes son
burbuja, función o transformación. El proceso muestra una parte del sistema que
transforma entradas en salidas
El flujo
Un flujo se representa gráficamente por medio de una flecha que entra o sale de un
proceso; El flujo se usa para describir el movimiento de bloques o paquetes de
información de una parte del sistema a otra.
El almacén
El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se
denota por dos líneas paralelas, De modo característico el nombre que se utiliza para
identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen
del almacén por medio de flujos.
El Terminador
El siguiente componente del DFD es un terminador; gráficamente se representa como
un rectángulo, Los terminadores representan entidades externas con las cuales el
sistema se comunica. En algunos casos, un terminador puede ser otro sistema, como
algún otro sistema computacional con el cual se comunica éste.
GUIA PARA LA CONSTRUCCION DE DFD
Las reglas incluyen las siguientes:
1. Escoger nombres con significado para los procesos, flujos, almacenes y
terminadores.
2. Numerar los procesos.
3. Redibujar el DFD tantas veces como sea necesario estéticamente.
4. Evitar los DFD excesivamente complejos.
5. Asegurarse de que el DFD sea internamente consistente y que también lo sea con
cualesquiera DFD relacionados con él.
