Análisis estructurado

Es parte de una serie de métodos estructurados, que representan una colección de

técnicas de análisis, diseño y programación que se desarrollaron en respuesta a los
problemas que enfrenta el mundo del software desde 1960 hasta la década de 1980.

El análisis estructurado normalmente crea una jerarquía que emplea un único mecanismo
de resumen. El método de análisis estructurado puede emplear IDEF (del
inglés Integration DEFinition es una familia de lenguajes de modelado en el campo de
la Ingeniería de sistemas y la Ingeniería de software.), es un proceso conducido, y
comienza con un propósito y un punto de vista. Este método identifica la función global y
de forma iterativa divide funciones en funciones más pequeñas, entradas conservantes,
salidas, controles y mecanismos necesarios para optimizar los procesos.

Enfoque
El análisis estructurado considera un sistema desde la perspectiva de los datos que fluyen
a través de él. La función del sistema es descrita por procesos que transforman los flujos
de datos. El análisis estructurado se aprovecha de la ocultación de información a través
del análisis de descomposición sucesiva (o de arriba hacia abajo). Esto permite que la
atención se centre en los detalles pertinentes y evita la confusión de mirar los detalles
irrelevantes. Como el nivel de detalle aumenta, se reduce la amplitud de la información. El
resultado del análisis estructurado es un conjunto relacionado de diagramas, gráficas,
descripciones de procesos, y las definiciones de datos. Ellos describen las
transformaciones que deben llevarse a cabo y los datos necesarios para cumplir con
el Requisito funcional de un sistema.

Conceptos claves de análisis estructurados

Diagrama de contexto

Ejemplo de un diagrama de contexto del sistema.

Los Diagrama de contexto de sistema son diagramas que representan los usuarios que
fuera de un sistema podrían interactuar con él. Este diagrama es la vista de más alto nivel
de un sistema, similar al diagrama de bloques, que muestra, posiblemente un sistema de
software basado en entradas y salidas además de sus factores externos.
Este tipo de diagrama según Kossiakoff (2003) por lo general "muestra el sistema en el
centro, sin detalles de su estructura interior, rodeado de todos sus sistemas de interacción,
medio ambiente y actividades. El objetivo de un diagrama de contexto del sistema es
centrar la atención en factores y eventos que deben ser considerados en el desarrollo de
un conjunto completo de las propuestas del sistema y las limitaciones externas". El
diagrama de contexto del sistema está relacionado con el Diagrama de flujo de datos, y
muestran las interacciones entre un sistema y otros usuarios con los que el sistema está
diseñado para hacer frente. Un diagrama de contexto del sistema puede ser útil para
comprender el contexto en el cual el sistema será parte de la ingeniería de software.

Diccionario de datos

Modelo entidad-relación, esencial para el diseño de tablas de bases de datos, extractos y

metadatos.

Un diccionario de datos o diccionario de base de datos es un archivo que define la

organización básica de una base de datos. Un diccionario de la base de datos contiene
una lista de todos los archivos de la base de datos, el número de registros en cada
archivo, y los nombres y tipos de cada campo de datos. La mayor parte del sistema de
gestión de base de datos mantiene el diccionario de datos ocultos a los usuarios para
evitar la destrucción accidental de los contenidos. Los diccionarios de datos no contienen
los datos reales de la base de datos, sólo la contabilidad de información para su gestión.
Sin un diccionario de datos, sin embargo, un sistema de gestión de base de datos no
puede acceder a los datos desde la base de datos.
Los usuarios de bases de datos y desarrolladores de Aplicación informática pueden
beneficiarse de un documento del diccionario de datos de una autoridad que cataloga la
organización, contenidos, y las convenciones de una o más bases de datos. Esto incluye
típicamente los nombres y las descripciones de varias tablas y campos en cada base de
datos, además de detalles adicionales, como el tipo y la longitud de cada elemento de
datos. No hay un estándar universal para el nivel de detalle en un documento de este tipo,
pero es sobre todo una destilación de metadatos acerca de la estructura y diseño de
la Base de datos, no los datos en sí. Un documento de diccionario de datos también puede
incluir información que describe cómo se codifican los elementos de datos. Una de las
ventajas del buen diseño de la documentación del diccionario de datos es que ayuda a
establecer la coherencia en una base de datos compleja.
Diagramas de Flujo de Datos

Ejemplo de un Diagrama de flujo de datos.

Un diagrama de flujo de datos (DFD) es una representación gráfica del "flujo" de datos a

través de un sistema de información. Se diferencia del diagrama de flujo del sistema, ya
que muestra el flujo de datos a través de procesos en lugar del Hardware. Los diagramas
de flujo de datos fueron inventados por Larry Constantino, promotor del diseño
estructurado, basado en el modelo de computación Martin y Estrin "gráfico de flujo de
datos".
Es una práctica común dibujar un Diagrama de contexto de sistema que primero muestra
la interacción entre el sistema y entidades externas. El DFD está diseñado para mostrar
cómo un sistema se divide en porciones más pequeñas y para resaltar el flujo de datos
entre las partes. Este diagrama de flujo de datos de nivel de contexto se "explotó" para
mostrar más detalles del sistema que se está modelando.
Los diagramas de flujo de datos (DFDs) son una de las tres perspectivas esenciales
de Análisis de sistemas estructurado y método de diseño (SSADM). El patrocinador de un
proyecto y los usuarios finales tendrán que ser informados y consultados en todas las
etapas de la evolución de un sistema. Con un diagrama de flujo de datos, los usuarios son
capaces de visualizar cómo funcionará el sistema, lo que el sistema va a lograr, y cómo se
implementará el sistema. Los diagramas de flujo de datos del viejo sistema se pueden
elaborar y comparar con los diagramas de flujo de datos del nuevo sistema para
implementar un sistema más eficiente. Los diagramas de flujo de datos se pueden utilizar
para proporcionar al usuario final con una idea física de donde los datos de entrada tienen
en última instancia un efecto sobre la estructura de todo el sistema para ordenar una
reestructuración. Cómo cualquier sistema es desarrollado puede determinarse a través de
un diagrama de flujo de datos.

Diagrama de Estructura

Una configuración del Diagrama de Estructura del Sistema.

Un diagrama de estructura (SC) es un gráfico que muestra la distribución del sistema de
configuración de los niveles más bajos y manejables. Esta tabla se usa en
la programación estructurada para organizar los módulos de programa en una estructura
de árbol. Cada módulo está representado por una caja que contiene el nombre del módulo.
La estructura de árbol visualiza las relaciones entre los módulos.
En análisis estructurado los diagramas de estructura se utilizan para especificar el diseño
de alto nivel, o la arquitectura de un programa de computadora. Como una herramienta de
diseño, ayudan al programador a dividir y conquistar un problema de software grande, es
decir, de forma recursiva romper un problema en partes que son lo suficientemente
pequeños para ser entendido por un cerebro humano. El proceso es llamado Top-down y
bottom-up, o de descomposición funcional. Los programadores usan un diagrama de
estructura para construir un programa de una manera similar a cómo un arquitecto utiliza
un plano para construir una casa. En la etapa de diseño, el diagrama se dibuja y se utiliza
como una manera para que el cliente y los diferentes diseñadores de software puedan
comunicarse. Durante la construcción real del programa (aplicación), al gráfico se le refiere
continuamente como el plan maestro.

Diseño Estructurado[editar]
El Diseño Estructurado (SD) tiene que ver con el desarrollo de los módulos y la síntesis de
estos módulos en una llamada "jerarquía de módulo".  Para el diseño de la estructura del
módulo óptimo y las interfaces, éstos dos principios son cruciales:

 La cohesión en Diseño estructurado, que es "interés por la agrupación de procesos

relacionados funcionalmente en un módulo en particular", 10 y
 Acoplamiento informático, se refiere a "el flujo de información o parámetros que se
pasan entre los módulos. El acoplamiento óptimo reduce las interfaces de módulos y la
complejidad resultante del software ".
El Diseño Estructurado fue desarrollado por Larry Constantino a finales de 1960, luego
refinado y publicado con colaboradores en la década de 1970;  véase Larry Constantine:
Diseño Estructurado para obtener más información Page-Jones (1980) ha propuesto su
propio enfoque que consiste en tres principales objetos:

 diagramas de estructura
 Especificaciones del módulo
 diccionario de datos.
El Diagrama de estructura compuesta tiene como objetivo mostrar "la jerarquía del módulo
o llamada secuencia de relación de los módulos. Hay un módulo de especificación para
cada módulo mostrado en el diagrama de estructura. Las especificaciones del modulo
pueden estar compuestas de pseudocódigo o un lenguaje de diseño de programa.
El diccionario de datos es como el del análisis estructurado. En esta etapa del Proceso
para el desarrollo de software, después de haber realizado el análisis y el diseño, es
posible generar automáticamente las declaraciones de tipo de datos ", y de procedimientos
o plantillas de subrutinas.