Método de análisis y diseño de sistemas estructurados

El método de análisis y diseño de sistemas estructurados ( SSADM , por sus siglas en inglés) es un enfoque sistémico para el análisis y diseño de sistemas de información. SSADM fue desarrollado para la Agencia Central de Computación y Telecomunicaciones (CATA) , una oficina gubernamental del Reino Unido encargada del uso de la tecnología en el gobierno, a partir de 1980.

SSADM es un método en cascada para el análisis y diseño de sistemas de información . Se puede considerar que SSADM representa la cúspide 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 que se basa en el trabajo de diferentes escuelas de métodos de análisis y desarrollo estructurados , como la metodología de sistemas blandos de Peter Checkland , el diseño estructurado de Larry Constantine , el método estructurado de 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 etapas principales del desarrollo del Método de Análisis y Diseño de Sistemas Estructurados fueron: ^{[ 2 ]}

• 1980: La Agencia Central de Computación y Telecomunicaciones (CCTA) evalúa los métodos de análisis y diseño.
• 1981: Los consultores que trabajaban para Learmonth & Burchett Management Systems, liderados por John Hall, fueron elegidos para desarrollar SSADM v1.
• 1982: John Hall y Keith Robinson se marcharon para fundar Model Systems Ltd. LBMS desarrolló posteriormente LSDM, su versión propia.
• 1983: SSADM se convierte en obligatorio para todos los nuevos desarrollos de sistemas de información.
• 1984: Se lanza la versión 2 de SSADM.
• 1986: Se publica la versión 3 del SSADM, adoptada por el NCC.
• 1988: Se lanza el Certificado de Competencia SSADM y se promueve como un estándar "abierto".
• 1989: Avances hacia Euromethod , lanzamiento del esquema de certificación de productos CASE.
• 1990: Lanzamiento de la versión 4
• 1993: Esquema de conformidad con el estándar y las herramientas SSADM V4
• 1995: Se anuncia SSADM V4+, se lanza la versión V4.2.
• 2000: CCTA cambió el nombre de SSADM a "Desarrollo de Sistemas Empresariales". El método se reorganizó en 15 módulos y se añadieron otros 6. ^{[ 3 ] [ 4 ]}

Las tres técnicas más importantes que se utilizan en SSADM son las siguientes:

Modelado lógico de datos

El proceso consiste en identificar, modelar y documentar los requisitos de datos del sistema que se está diseñando. El resultado es un modelo de datos que contiene entidades (elementos sobre los que una empresa necesita registrar información), atributos (datos sobre las entidades) y relaciones (asociaciones entre las entidades).

Modelado del flujo de datos

El modelado del flujo de datos consiste en identificar, modelar y documentar cómo se mueven los datos dentro de un sistema de información. Este proceso examina los procesos (actividades que transforman los datos de un formato a otro), los almacenes de datos (los lugares donde se guardan los datos), las entidades externas (lo que envía datos a un sistema o recibe datos de un sistema) y los flujos de datos (las rutas por las que pueden fluir los datos).

Modelado de eventos de entidades

Un proceso de dos vertientes: Modelado del comportamiento de las entidades, que consiste en identificar, modelar y documentar los eventos que afectan a cada entidad y la secuencia (o historia de vida) en la que ocurren estos eventos, y Modelado de eventos, que consiste en diseñar para cada evento el proceso para coordinar las historias de vida de las entidades.

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 la viabilidad de un proyecto, es necesario realizar una investigación sobre sus objetivos e implicaciones. En proyectos de pequeña escala, esto puede no ser necesario, ya que su alcance es fácilmente comprensible. En proyectos de mayor envergadura, la viabilidad puede evaluarse de forma informal, ya sea por falta de tiempo para un estudio formal o porque el proyecto es imprescindible y deberá llevarse a cabo de una u otra manera. Un diagrama de flujo de datos se utiliza para describir el funcionamiento del sistema actual y visualizar los problemas conocidos.

Cuando se realiza un estudio de viabilidad, hay cuatro áreas principales a considerar:

Aspectos técnicos: ¿Es técnicamente viable el proyecto? Aspectos financieros: ¿Puede la empresa permitirse llevar a cabo el proyecto? Aspectos organizativos: ¿Será compatible el nuevo sistema con las prácticas existentes? Aspectos éticos: ¿Es socialmente aceptable el impacto del nuevo sistema?

Para responder a estas preguntas, el estudio de viabilidad es, en esencia, una versión condensada de un análisis y diseño de sistemas integral. Se analizan los requisitos y usos, se elaboran algunas opciones de negocio e incluso se definen algunos detalles de la implementación técnica. El resultado de esta etapa es un documento formal de estudio de viabilidad. SSADM especifica las secciones que debe contener el estudio, incluyendo los modelos preliminares elaborados, así como los detalles de las opciones rechazadas y los motivos de su rechazo.

Los desarrolladores de SSADM comprendieron que, en casi todos los casos, existe algún tipo de sistema vigente, aunque esté compuesto exclusivamente por personas y documentos en papel. Mediante entrevistas a empleados, cuestionarios, observaciones y documentación existente, el analista llega a comprender plenamente el sistema tal como se encuentra al inicio del proyecto. Esto tiene múltiples propósitos (¿Algún ejemplo?).

Tras analizar el sistema actual, el analista debe decidir el diseño general del nuevo sistema. Para ello, utilizando los resultados de la etapa anterior, desarrolla un conjunto de opciones para el sistema empresarial. Estas opciones incluyen diferentes maneras de implementar el nuevo sistema, desde no hacer nada hasta desechar por completo el sistema antiguo y construir uno totalmente nuevo. El analista puede organizar una sesión de lluvia de ideas para generar la mayor cantidad y variedad de ideas posible.

Las ideas se recopilan en opciones que se presentan al usuario. Las opciones consideran lo siguiente:

• el grado de automatización
• el límite entre el sistema y los usuarios
• Por ejemplo, ¿la distribución del sistema está centralizada en una sola oficina o se extiende a varias?
• costo/beneficio
• impacto del nuevo sistema

En caso 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 conjuntamente una única opción de negocio. Esta puede ser una de las opciones ya definidas o una síntesis de diferentes aspectos de las opciones existentes. El resultado de esta etapa es la 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 el nuevo sistema debe hacer. La especificación debe estar libre de errores, ambigüedades e inconsistencias. Por lógica, entendemos que la especificación no indica cómo se implementará el sistema, sino que describe qué hará el sistema.

Para elaborar la especificación lógica, el analista crea los modelos lógicos necesarios tanto para los diagramas de flujo de datos (DFD) como para el modelo de datos lógico (LDM), que consta de la estructura de datos lógica (denominada en otros métodos diagramas de entidad-relación ) y descripciones completas de los datos y sus relaciones. Estos se utilizan para generar definiciones de todas las funciones que los usuarios requerirán del sistema, historiales 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 relevantes. Estos se comparan continuamente con los requisitos y, cuando es necesario, se añaden y completan dichos requisitos.

El producto de esta etapa es un documento completo de especificación de requisitos que se compone de:

• el catálogo de datos actualizado
• el catálogo de requisitos actualizado
• la especificación de procesamiento que a su vez está compuesta por

• matriz de roles/funciones de usuario
• definiciones de funciones
• modelo de datos lógico requerido
• historias de vida de las entidades
• diagramas de correspondencia de efectos

Esta etapa es la primera antes de la implementación física de la nueva aplicación del sistema. Al igual que en las Opciones del Sistema Empresarial, en esta etapa se generan numerosas 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, ya que:

• las arquitecturas de hardware
• el software a utilizar
• el costo de la implementación
• la dotación de personal requerida
• las limitaciones físicas como el espacio ocupado por el sistema
• la distribución, incluidas las redes que puedan requerir
• el formato general de la interfaz hombre-máquina

Todos estos aspectos también deben ajustarse a las limitaciones impuestas por la empresa, como el presupuesto disponible y la estandarización del hardware y el software.

El resultado de esta etapa es una opción de sistema técnico seleccionada.

Si bien el nivel anterior especifica detalles de la implementación, los resultados de esta etapa son independientes de la implementación y se centran en los requisitos de la interfaz hombre-máquina. El diseño lógico especifica los principales métodos de interacción en términos de estructuras de menús y estructuras de comandos.

Una de las áreas de actividad consiste en la definición de los diálogos de usuario. Estos son las interfaces principales con las que los usuarios interactuarán con el sistema. Otras actividades se centran en el análisis de los efectos de los eventos en la actualización del sistema y la necesidad de realizar consultas sobre los datos del mismo. Para ello, se utilizan los eventos, las descripciones de funciones y los diagramas de correspondencia de efectos generados 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, que se compone de:

• Catálogo de datos
• Estructura de datos lógica requerida
• Modelo de proceso lógico: incluye diálogos y un modelo para los procesos de actualización y consulta.
• Esfuerzo y momento flector.

Esta es la etapa final, donde todas las especificaciones lógicas del sistema se convierten en descripciones del mismo en términos de hardware y software reales. Se trata de una etapa muy técnica, por lo que aquí se presenta una breve descripción general .

La estructura lógica de datos se transforma en una arquitectura física mediante estructuras de base de datos. Se especifica la estructura exacta de las funciones y su implementación. 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 puede indicar a los ingenieros de software cómo construir el sistema con detalles específicos de hardware y software, y de acuerdo con los estándares apropiados.

• ¿Qué es SSADM? en webopedia.com
• Introducción a las metodologías y SSADM
• Wiki de análisis estructurado