Análisis Estructurado y Técnicas de Diseño

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda
Elementos básicos del AETD

El análisis estructurado y técnicas de diseño es en ingeniería de sistemas y proceso para el desarrollo de software para la descripción de sistemas como una jerarquía de funciones.

Información General[editar]

En una organización o empresa, el análisis y diseño de sistemas es un proceso que consiste en estudiar su situación de manera que, al observar cómo se trabaja se pueda detectar si es necesario realizar alguna mejora. El encargado de realizar estas tareas es el analista de sistemas: antes de comenzar el desarrollo de cualquier proyecto, se realiza un estudio de sistemas para detectar todos los detalles de la situación actual en la empresa. La información reunida con este estudio sirve como base para crear varias estrategias de diseño. Los administradores deciden qué estrategia puede seguir. Los gerentes, empleados y otros usuarios finales que se familiarizan cada vez más con el empleo de computadoras están teniendo un papel muy importante en el desarrollo de sistemas.

Todas las organizaciones son sistemas que actúan recíprocamente con su medio ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar formados por otros sistemas más pequeños denominados subsistemas, funcionan para alcanzar fines específicos; sin embargo, los propósitos o metas se alcanzan sólo cuando se mantiene el control.

Historia[editar]

AETD fue desarrollado y probado en campo entre los años 1969 y 1973 por Douglas T. Ross y SofTech, Inc..[1][2]​ La metodología se utilizó en el MIT de herramienta de programación automática del proyecto (HPA). También, recibió un uso extensivo de partida en 1973 por la Fuerza aérea de los Estados Unidos.

Según Levitt (2000) "Es parte de una serie de métodos estructurados, que representan un conjunto 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 calendario de programación más comercial se hizo en COBOL y FORTRAN, luego C y BASIC. Hubo poca orientación sobre las técnicas de diseño y programación, no había técnicas estándar para documentar los requisitos y diseños. Los sistemas se vuelven cada vez más grandes y más complejos, y el desarrollo de sistemas de información se hizo más difícil. Como una manera de ayudar a manejar el software grande y complejo, desde finales del año 1960, varios métodos estructurados surgieron”.[3]

En 1981, se publicó el formalismo el IDEF0, basado en TDAA.[4]

Temas AETD[editar]

Arriba-abajo descomposición de estructura.
Un ejemplo de AETD.

Enfoque arriba y abajo[editar]

La técnica de análisis y diseño estructurado utiliza una descomposición con el Top-down y bottom-up. Esta descomposición se lleva a cabo sólo en el dominio físico desde una perspectiva de diseño axiomático. Debido a este proceso sin rodeos, no hay garantía de la funcionalidad o la productividad. Por lo tanto, esos métodos se desvanecieron como los requisitos para los sistemas de software y se incrementaron, el método orientado a objetos se introdujo.[5]

Diagramas[editar]

AETD usa dos tipos de diagramas: modelos de función y modelo de datos. Este usa flechas para construir estos diagramas.

La representación de el AETD es la siguiente:

  • Un cuadro principal, donde se especifica el nombre del proceso o la acción
  • En el lado izquierdo de esta caja de texto, flechas entrantes: entradas de la acción.
  • En la parte superior, las flechas entrantes: los datos necesarios para la acción.
  • En la parte inferior de la caja, flechas entrantes: medios empleados para la acción.
  • En el lado derecho de la caja, flechas salientes: salidas de la acción.

La semántica de flechas para actividades:[6]

  • Entradas entran por la izquierda y representan los datos o consumibles que son necesarios para la actividad.
  • Salidas salen por la derecha y representan datos o productos que son producidos por la actividad.
  • Controles entran por la parte superior y representan comandos que influyen en la ejecución de una actividad, pero no se consumen.
  • Mecanismos de identificar los medios, componentes o herramientas utilizadas para llevar a cabo la actividad. Representa la asignación de actividades.

La semántica de flechas para datos:[6]

  • Las entradas son las actividades que producen los datos.
  • Salidas consumen los datos.
  • Controles influyen en el estado interno de los datos. Véase también
  • IDEF0
  • Análisis de sistemas estructurado y método de diseño
  • Análisis de sistemas
  • ANÁLISIS Y SISTEMAS El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de mejorar con métodos y procedimientos más adecuados. El desarrollo de sistemas tiene dos componentes. Análisis Es el proceso de clasificación e interpretación de hechos, diagnostico de problemas y empleo de la información para recomendar mejoras al sistemas. Diseño: Especifica las características del producto terminado. Análisis: Especifica que es lo que el sistema debe hacer. Diseño: Establece como alcanzar el objetivo. Javier[7]

Referencias[editar]

  1. D. Marca, C. McGowan, Structured Analysis and Design Technique, McGraw-Hill, 1987, ISBN 0-07-040235-3
  2. D. T. Ross: Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering, SE-3(1), pp. 16-34. Abstract
  3. Dave Levitt (2000): Introduction to Structured Analysis and Design. Retrieved 21 September 2008.
  4. Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  5. Nam Pyo Suh (2007). Axiomatic Design - Advances and Applications. Nueva York: Oxford University Press Chapter 5, pp. 239-298.
  6. a b John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 September 2008.
  7. «Facebook - Inicia sesión o regístrate». Facebook. Consultado el 16 de noviembre de 2016. 

Enlaces externos[editar]