El método de análisis y diseño de sistemas estructurados ( SSADM ) es un enfoque de sistemas para el análisis y diseño de sistemas de información. El SSADM se elaboró para la Agencia Central de Computación y Telecomunicaciones , una oficina del gobierno del Reino Unido encargada 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 la cumbre 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 de Jackson de Michael A. Jackson y el análisis estructurado de Tom DeMarco .
Los nombres "Structured Systems Analysis and Design Method" y "SSADM" son marcas 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 realizarse algún tipo de investigación sobre los objetivos y las implicaciones del proyecto. En el caso de proyectos de escala muy pequeña, esto puede no ser necesario en absoluto, ya que el alcance del proyecto se entiende fácilmente. En proyectos más grandes, la viabilidad puede realizarse, pero de manera informal, ya sea porque no hay tiempo para un estudio formal o porque el proyecto es “imprescindible” y deberá realizarse de una manera 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 realiza un estudio de viabilidad, hay cuatro áreas principales a considerar:
Aspectos técnicos: ¿el proyecto es técnicamente posible?
Aspectos financieros: ¿la empresa puede permitirse llevar a cabo el proyecto?
Aspectos organizativos: ¿el nuevo sistema será compatible con las prácticas existentes?
Aspectos éticos: ¿el impacto del nuevo sistema es socialmente aceptable?
Para responder a estas preguntas, el estudio de viabilidad es, en efecto, una versión condensada de un análisis y diseño de sistemas completos. Se analizan en cierta medida los requisitos y usos, se trazan algunas opciones comerciales e incluso algunos detalles de la implementación técnica. El producto de esta etapa es un documento formal de estudio de viabilidad. El SSADM especifica las secciones que debe contener el estudio, incluidos los modelos preliminares que se hayan construido y también los detalles de las opciones rechazadas y las razones de su rechazo.
Los desarrolladores de SSADM comprendieron que en casi todos los casos existe algún tipo de sistema actual, incluso si está compuesto enteramente de personas y papel. Mediante una combinación de entrevistas a empleados, distribución de cuestionarios, observaciones y documentación existente, el analista llega a comprender plenamente el sistema tal como es al comienzo del proyecto. Esto sirve para muchos propósitos (¿como ejemplos?).
Después de haber investigado el sistema actual, el analista debe decidir el diseño general del nuevo sistema. Para ello, utiliza los resultados de la etapa anterior para desarrollar un conjunto de opciones para el sistema empresarial. Se trata de distintas formas de producir el nuevo sistema, que van desde no hacer nada hasta desechar por completo el sistema antiguo y construir uno completamente nuevo. El analista puede realizar una sesión de intercambio de ideas para generar tantas ideas como sea posible.
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. Puede ser una de las ya definidas o 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 del 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ógica, queremos decir que la especificación no dice cómo se implementará el sistema, sino que describe lo que hará el sistema.
Para producir la especificación lógica, el analista construye los modelos lógicos requeridos tanto para los diagramas de flujo de datos (DFD) como para el modelo lógico de datos (LDM), que consiste en la estructura lógica de datos (conocida en otros métodos como 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 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 cada evento interactúa con todas las entidades relevantes. Estos se comparan continuamente con los requisitos y, cuando es necesario, se agregan y completan los requisitos.
El producto de esta etapa es un documento completo de especificación de requisitos que 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 de Negocio, en esta etapa se generan un gran número de opciones para la implementación del nuevo sistema. Estas se reducen a dos o tres para presentarlas al usuario de entre las cuales se elige o sintetiza la opción final.
Sin embargo, las consideraciones son bastante diferentes:
Todos estos aspectos también deben ajustarse a las restricciones impuestas por el negocio, 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 de 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 comandos.
Un área de actividad es la definición de los diálogos de usuario. Se trata de las principales interfaces con las que los usuarios interactuarán con el sistema. Otras actividades se ocupan del análisis tanto de los efectos de los eventos en la actualización del sistema como de la necesidad de realizar consultas sobre los datos del sistema. Ambas utilizan los eventos, las descripciones de funciones y los diagramas de correspondencia de efectos producidos en la etapa 3 para determinar con precisión cómo actualizar y leer los datos de forma coherente y segura.
El producto de esta etapa es el diseño lógico el cual está compuesto por:
Esta es la etapa final en la que 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 física de datos 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}}: CS1 maint: 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