El método de diseño y análisis de sistemas estructurados ( SSADM ) es un enfoque de sistemas para el análisis y diseño de sistemas de información. SSADM fue producido para la Agencia Central de Informática y Telecomunicaciones , una oficina gubernamental del Reino Unido que se ocupa del uso de la tecnología en el gobierno, desde 1980 en adelante.
SSADM es un método en cascada para el análisis y diseño de sistemas de información . Se puede pensar que SSADM representa el pináculo del enfoque riguroso basado en documentos para el diseño de sistemas, y contrasta con métodos ágiles más contemporáneos como DSDM o Scrum .
SSADM es una implementación particular y se basa en el trabajo de diferentes escuelas de análisis estructurado y métodos de desarrollo, como la metodología de sistemas blandos de Peter Checkland , el diseño estructurado de Larry Constantine , el método estructurado Yourdon de Edward Yourdon , la programación estructurada Jackson de Michael A. Jackson y la programación estructurada Jackson de Tom DeMarco. análisis estructurado .
Los nombres "Método de diseño y análisis de sistemas estructurados" y "SSADM" son marcas comerciales registradas de la Oficina de Comercio Gubernamental (OGC), que es una oficina del Tesoro del Reino Unido. [1]
Las principales etapas del desarrollo del método de análisis y diseño de sistemas estructurados fueron: [2]
Las tres técnicas más importantes que se utilizan en SSADM son las siguientes:
El método SSADM implica la aplicación de una secuencia de tareas de análisis, documentación y diseño relacionadas con lo siguiente.
Para determinar si un proyecto determinado es factible o no, debe haber algún tipo de investigación sobre los objetivos y las implicaciones del proyecto. Para proyectos de muy pequeña escala esto puede no ser necesario en absoluto ya que el alcance del proyecto se comprende fácilmente. En proyectos más grandes, la viabilidad se puede hacer pero en un sentido informal, ya sea porque no hay tiempo para un estudio formal o porque el proyecto es “imprescindible” y tendrá que realizarse de una forma u otra. Se utiliza un diagrama de flujo de datos para describir cómo funciona el sistema actual y visualizar los problemas conocidos.
Cuando se lleva a cabo un estudio de viabilidad, hay cuatro áreas principales a considerar:
Técnico: ¿es el proyecto técnicamente posible?
Financiero: ¿puede la empresa permitirse llevar a cabo el proyecto?
Organizacional: ¿será el nuevo sistema compatible con las prácticas existentes?
Ético: ¿es socialmente aceptable el impacto del nuevo sistema?
Para responder a estas preguntas, el estudio de viabilidad es efectivamente una versión condensada de un análisis y diseño integral de sistemas. Se analizan en cierta medida los requisitos y usos, se elaboran algunas opciones de negocio e incluso algunos detalles de la implementación técnica. El producto de esta etapa es un documento formal de estudio de factibilidad. SSADM especifica las secciones que debe contener el estudio, incluidos los modelos preliminares que se hayan construido y también detalles de las opciones rechazadas y los motivos de su rechazo.
Los desarrolladores de SSADM entendieron que en casi todos los casos existe algún tipo de sistema actual, incluso si está compuesto enteramente de personas y papel. A través de una combinación de entrevistas a los empleados, circulación de cuestionarios, observaciones y documentación existente, el analista llega a una comprensión completa del sistema tal como estaba al inicio del proyecto. Esto sirve para muchos propósitos (¿te gustan los ejemplos?).
Una vez investigado el sistema actual, el analista debe decidir sobre el diseño general del nuevo sistema. Para ello, utilizando los resultados de la etapa anterior, desarrolla un conjunto de opciones de sistemas de negocio. Estas son diferentes maneras en que se podría producir el nuevo sistema, que van desde no hacer nada hasta desechar el viejo sistema por completo y construir uno completamente nuevo. El analista podrá realizar una sesión de lluvia de ideas para que se generen tantas y diversas ideas como sea posible.
Luego, las ideas se recopilan en opciones que se presentan al usuario. Las opciones consideran lo siguiente:
Cuando sea necesario, la opción se documentará con una estructura de datos lógica y un diagrama de flujo de datos de nivel 1.
Los usuarios y el analista eligen juntos una única opción de negocio. Esta puede ser una de las ya definidas o puede ser una síntesis de diferentes aspectos de las opciones existentes. El resultado de esta etapa es la única opción de negocio seleccionada junto con todos los resultados de la etapa de viabilidad.
Esta es probablemente la etapa más compleja de SSADM. Utilizando los requisitos desarrollados en la etapa 1 y trabajando dentro del marco de la opción de negocio seleccionada, el analista debe desarrollar una especificación lógica completa de lo que debe hacer el nuevo sistema. La especificación debe estar libre de errores, ambigüedades e inconsistencias. Por lógico queremos decir que la especificación no dice cómo se implementará el sistema, sino que describe qué hará el sistema.
Para producir la especificación lógica, el analista construye los modelos lógicos necesarios tanto para los diagramas de flujo de datos (DFD) como para el modelo lógico de datos (LDM), que consta de la estructura lógica de datos (denominada en otros métodos diagramas de relación de entidades ) y descripciones completas de los datos y sus relaciones. Estos se utilizan para producir definiciones de funciones de cada función que los usuarios requerirán del sistema, Historias de vida de las entidades (ELH), que describen todos los eventos a lo largo de la vida de una entidad, y Diagramas de correspondencia de efectos (ECD), que describen cómo interactúa cada evento. con todas las entidades pertinentes. Estos se comparan continuamente con los requisitos y, cuando es necesario, los requisitos se agregan y completan.
El producto de esta etapa es un documento completo de especificación de requisitos el cual se compone de:
Esta etapa es la primera hacia una implementación física de la nueva aplicación del sistema. Al igual que las Opciones del Sistema Empresarial, en esta etapa se genera una gran cantidad de opciones para la implementación del nuevo sistema. Esto se reduce a dos o tres para presentar al usuario entre los cuales se elige o sintetiza la opción final.
Sin embargo, las consideraciones son bastante diferentes siendo:
Todos estos aspectos también deben ajustarse a las limitaciones impuestas por la empresa, como el dinero disponible y la estandarización del hardware y el software.
El resultado de esta etapa es una opción de sistema técnico elegida.
Aunque el nivel anterior especifica detalles de la implementación, los resultados de esta etapa son independientes de la implementación y se concentran en los requisitos para la interfaz hombre-computadora. El diseño lógico especifica los principales métodos de interacción en términos de estructuras de menú y estructuras de comando.
Un área de actividad es la definición de los diálogos de usuario. Estas son las principales interfaces con las que los usuarios interactuarán con el sistema. Otras actividades se ocupan de analizar tanto los efectos de los eventos en la actualización del sistema como la necesidad de realizar consultas sobre los datos del sistema. Ambos utilizan los eventos, descripciones de funciones y diagramas de correspondencia de efectos producidos en la etapa 3 para determinar con precisión cómo actualizar y leer datos de una manera consistente y segura.
El producto de esta etapa es el diseño lógico el cual se compone de:
Esta es la etapa final donde todas las especificaciones lógicas del sistema se convierten en descripciones del sistema en términos de hardware y software reales. Esta es una etapa muy técnica y aquí se presenta una descripción general simple.
La estructura lógica de datos se convierte en una arquitectura física en términos de estructuras de bases de datos. Se especifica la estructura exacta de las funciones y cómo se implementan. La estructura de datos físicos se optimiza cuando es necesario para cumplir con los requisitos de tamaño y rendimiento.
El producto es un diseño físico completo que podría indicar a los ingenieros de software cómo construir el sistema con detalles específicos de hardware y software y según los estándares apropiados.
{{cite web}}: Mantenimiento CS1: URL no apta ( enlace )5. Keith Robinson, Graham Berrisford: SSADM orientado a objetos, Prentice Hall International (Reino Unido), Hemel Hempstead, ISBN 0-13-309444-8