thumb|320px|Ejemplo de un enfoque de Análisis Estructurado.Tricia Gilbert (2006) FCS Evaluation criterea for technology assessment
El Análisis Estructurado (SA) en ingeniería de software y su técnica aliada, Diseño estructurado (SD), es un conjunto de métodos orientados a analizar y convertir requisitos de negocio en especificaciones y en última instancia, programas informáticos, configuraciones de hardware y procedimientos manuales relacionados.
Las técnicas de análisis y diseño estructurados son herramientas fundamentales de análisis de sistemas desarrolladas a partir de análisis de sistemas clásicos de los años 1960 y 1970.Edward Yourdon (1986). Managing the Structured Techniques: Strategies for Software Development in the 1990s. Yourdon Press. p.35.
Objetivos del Análisis Estructurado
El análisis estructurado se hizo popular en las década de 1980 y sigue siendo utilizado por muchos. El análisis consiste en interpretar el concepto del sistema (o situaciones del mundo real) en datos y controlar la terminología representada por el diagrama de flujo de datos. El flujo de datos y el control de la burbuja para el almacén de datos de la burbuja pueden ser muy difíciles de seguir y el número de burbujas puede llegar a ser muy grande. Un enfoque es definir primero los eventos del mundo exterior que requieren que el sistema reaccione, a continuación, asignar una burbuja para ese evento, las burbujas que necesitan interactuar se conectan luego hasta que se defina el sistema. Esto puede ser bastante abrumador y así las burbujas suelen agruparse en burbujas de nivel superior. Se necesitan los Diccionario de datos para describir los flujos de datos y de mando como también se necesita una especificación de proceso para capturar la información de la transacción/transformación.FAA (2000).FAA System Safety Handbook, Appendix D. December 30, 2000.
SA y SD fueron acompañados por un método de notación incluyendo los diagrama de estructura compuesta, diagrama de flujo de datos y diagramas de modelo de datos, de los cuales hubo muchas variaciones, incluyendo las desarrolladas por Tom DeMarco, Ken Orr, Larry Constantine, Vaughn Frick, Ed Yourdon, Steven Ward, Peter Chen, y otros.
Estas técnicas se combinaron en varios publicados de procesos para el desarrollo de software, incluyendo el método de análisis y diseño de sistemas estructurados, Información Rentable por Diseño (PRIDE), Análisis Estructurado y diseño Nastec, SDM/70 y la metodología de desarrollo de sistemas de Espectro Estructurado.
Historia
El 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. En este marco de tiempo más programación comercial se hizo en Cobol y Fortran, luego en Lenguaje C y BASIC. Hubo poca orientación sobre las "buenas" técnicas de diseño y programación, y no había técnicas estándar para la documentación de requisitos y diseños. Los sistemas fueron cada vez más grandes y más complejos, y el desarrollo de sistemas de información se hicieron más y más difíciles de hacer ".Dave Levitt (2000):Introduction to Structured Analysis and Design. Retrieved 21 Sep 2008. Como una manera de ayudar a manejar un software grande y complejo, surgieron los siguientes métodos estructurados.
Desde finales de la década de 1960 varios Métodos Estructurados surgieron:
La programación estructurada en alrededor de 1967 con Edsger Dijkstra - "La sentencia GOTO considerada perjudicial" Niklaus Wirth Diseño paso a paso en 1971 Diagrama Nassi-Shneiderman en 1972 Diagrama Warnier/Orr en 1974 - "La construcción lógica de los programas" HIPO en 1974 - IBM Jerarquía entrada-proceso-salida (aunque esto debería ser realmente la salida-entrada-proceso) Diseño Estructurado en torno a 1975 con Larry Constantino, Ed Yourdon y Wayne Stevens. Programación Estructurada Jackson en torno a 1975 elaborado por Michael A. Jackson Análisis Estructurado cerca de 1978 con Tom DeMarco, Yourdon, Gane y Sarson, McMenamin & Palmer. Técnica de Análisis y Diseño Estructurado (SADT) desarrollada por Douglas T. Ross Método Estructurado Yourdon desarrollado por Edward Yourdon. Análisis Estructurado y Especificación del Sistema publicada en 1979 por Tom DeMarco. Método de análisis y diseño de sistemas estructurados (AETD) presentado por primera vez en 1983 desarrollado por la Office of Government Commerce del Reino Unido. IDEF0 basado en TDAA, desarrollado por Douglas T. Ross en 1985.Gavriel Salvendy (2001).Handbook of Industrial Engineering: Technology and Operations Management.. p.508. Modelado Hatley-Pirbhai, definido en "Estrategias para el Sistema de Especificación de Tiemo Real" por Derek J. Hatley y Imtiaz A. Pirbhai en 1988. Ingeniería de la Información en alrededor de 1990 con Finkelstein y popularizada por James Martin.
Según Hay (1999) "La ingeniería de la información era una extensión lógica de las técnicas estructuradas que se desarrollaron durante la década de 1970. La programación estructurada condujo al diseño estructurado, que a su vez condujo a sistemas de análisis estructurado. Estas técnicas se caracterizan por su uso de diagramas: diagramas de estructura para el diseño estructurado y diagramas de flujo de datos para el análisis estructurado, tanto para ayudar en la comunicación entre usuarios y desarrolladores, y para mejorar el análisis de la disciplina y del diseñador. Durante la década de 1980, comenzaron a aparecer herramientas para el dibujo de los diagramas automatizados, y llevaron un registro de las cosas dibujadas en un diccionario de datos".David C. Hay (1999) Achieving buzzword compliance in Object orientation Essential Strategies, Inc. Después del ejemplo de diseño asistido por computadora y la fabricación asistida por computadora (CAD / CAM), el uso de estas herramientas fue nombrada la Herramienta CASE.
Temas de análisis estructurado
Sencillo mecanismo de resumen thumb|320px|Imagen:Ejemplo de Análisis Estructurado.DoD Architecture Framework Working Group (2003). DoDAF 1.5 Volume 2, 15 August 2003. 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 (ver figura), 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. También es conocido como un enfoque de descomposición funcional, se centra en la cohesión dentro de las funciones y de acoplamiento entre las funciones que llevan a los datos estructurados.
La descomposición funcional del método estructurado describe el proceso sin delinear el comportamiento del sistema y la estructura del sistema dictados en forma de funciones requeridas. El método identifica las entradas y salidas en relación con las actividades. Una de las razones de la popularidad del análisis estructurado es su capacidad intuitiva para comunicar procesos y conceptos de alto nivel, si los niveles del sistema son sencillos o empresariales. El descubrimiento de cómo los objetos pueden ayudar a las funciones de desarrollo orientado a objetos comercialmente está claro. En contraste con IDEF, el UML está impulsada con múltiples interfaces de mecanismos de resumen útiles para describir las arquitecturas orientadas a servicios (SOAs).
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.Alan Hecht and Andy Simmons (1986) Integrating Automated Structured Analysis and Design with Ada Programming Support Environments NASA 1986. thumb|320px|El enfoque del análisis estructurado desarrolla perspectivas tanto en los objetos del proceso y los datos de los objetos.
El enfoque de De MarcoTom DeMarco Structured Analysis and System Specification. Yourdon Press, New York, 1978. consta de los siguientes objetos (véase el gráfico): Diagrama de contexto de sistema Diagrama de flujo de datos Especificaciones de los procesos Diccionario de datos
Con el diagrama de flujo de datos (DFDs) se dirigen gráficos. Los arcos representan los datos, y los nodos (círculos o burbujas) representan procesos que transforman los datos. Un proceso se puede descomponer además a un DFD más detallado que muestra los subprocesos y los flujos de datos dentro de ella. Los subprocesos pueden a su vez descomponerse aún más con otro conjunto de DFD hasta que sus funciones se pueden entender fácilmente. Las funciones primitivas son procesos que no necesitan ser descompuestas aún más. Estas funciones primitivas se describen por una especificación de proceso (o mini-spec). La especificación del proceso puede consistir en pseudocódigo, diagramas de flujo, o Inglés estructurado. En el modelo de DFD la estructura del sistema es como una red de procesos interconectados compuestos de funciones primitivas. El diccionario de datos es un conjunto de entradas (definiciones) de los flujos de datos, elementos de datos, archivos y bases de datos. Los diccionarios de datos se dividen de una manera de arriba hacia abajo. Estos pueden ser referenciados en otras entradas del diccionario de datos y en los diagramas de flujo de datos.
Diagrama de contexto thumb|320px|Ejemplo de un diagrama de contexto del sistema.NDE Project Management (NPOESS) Data Exploitation web site. 2008. 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".Alexander Kossiakoff, William N. Sweet (2003). Systems Engineering: Principles and Practices p. 413. 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
thumb|320px|left| Modelo entidad-relación, esencial para el diseño de tablas de bases de datos, extractos y metadatos.