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

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.

Sinopsis

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 y el de Edward Yourdon. El método estructurado de Yourdon, la programación estructurada de Jackson de Michael A. Jackson y el análisis estructurado de Tom DeMarco.

Los nombres "Método de diseño y análisis de sistemas estructurados" y "SSADM" son marcas registradas de la Oficina de Comercio Gubernamental (OGC), que es una oficina del Tesoro del Reino Unido.

Historia

Las principales etapas del desarrollo del Método de Análisis y Diseño de Sistemas Estructurados fueron:

• 1980: Central Computer and Telecommunications Agency (CCTA) evalúa métodos de análisis y diseño.
• 1981: Consultores de Learmonth " Burchett Management Systems, dirigidos por John Hall, decidieron desarrollar SSADM v1.
• 1982: John Hall y Keith Robinson se fueron a fundar Model Systems Ltd, LBMS desarrolló posteriormente LSDM, su versión patentada.
• 1983: SSADM hizo obligatorio para todos los nuevos desarrollos del sistema de información
• 1984: versión 2 de SSADM publicada
• 1986: versión 3 de SSADM publicada, aprobada por NCC
• 1988: SSADM Certificado de competencia lanzado, SSADM promovido como estándar "abierto"
• 1989: Avances hacia Euromethod, lanzamiento del esquema de certificación de productos CASE
• 1990: versión 4 lanzada
• 1993: SSADM V4 Standard and Tools Conformance Scheme
• 1995: SSADM V4+ anunció, V4.2 lanzado
• 2000: CCTA cambió el nombre de SSADM como "Business System Development". El método se reemplazó en 15 módulos y se agregaron otros 6 módulos.

Técnicas SSADM

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

Modelización de datos lógicos

El proceso de identificación, modelización y documentación de los requisitos de datos del sistema que se está diseñando. El resultado es un modelo de datos que contiene entidades (cosas sobre las cuales una empresa necesita registrar información), atributos (hechos sobre las entidades) y relaciones (asociaciones entre las entidades).

Modelo de flujo de datos

El proceso de identificación, modelización y documentación de cómo se mueven los datos alrededor de un sistema de información. Data Flow Modeling examina procesos (actividades que transforman datos de un formulario a otro), almacenes de datos (las áreas de retención de datos), entidades externas (lo que envía datos a un sistema o recibe datos de un sistema), y flujos de datos (rutas por las cuales los datos pueden fluir).

Modelado de eventos de Entidades

Un proceso de dos etapas: Entity Behavior Modelling, identifying, modelling and documenting the events that affect each entity and the sequence (or life history) in which these events occur, and Event Modelling, designing for each event the process to coordinate entity life histories.

Etapas

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.

Etapa 0 – Estudio de viabilidad

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.

Etapa 1 – Investigación del entorno actual

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?).

Etapa 2: Opciones del sistema empresarial

Habiendo 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.

Las ideas luego 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
• la distribución del sistema, por ejemplo, ¿se centraliza en una oficina o se distribuye en varios?
• costo/beneficio
• impacto del nuevo sistema

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 analistas 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.

Etapa 3 – Especificación de requisitos

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 como relación de entidad). diagramas) 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 que se compone de:

• el catálogo de datos actualizado
• el catálogo de necesidades actualizadas
• la especificación de procesamiento que a su vez se compone de

• función del usuario/ matriz de funciones
• definiciones de función
• necesario modelo lógico de datos
• entidad historia de la vida
• Efectos diagramas de correspondencia

Etapa 4 – Opciones técnicas del sistema

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:

• las arquitecturas de hardware
• el software para utilizar
• el costo de la aplicación
• personal necesario
• las limitaciones físicas como un espacio ocupado por el sistema
• la distribución incluyendo las redes que puedan requerir
• el formato general de la interfaz de computadora humana

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

El resultado de esta etapa es una opción técnica del sistema elegida.

Etapa 5 – Diseño lógico

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:

• Catálogo de datos
• Estructura lógica necesaria de datos
• Modelo de proceso lógico – incluye diálogos y modelo para los procesos de actualización e investigación
• Primer momento.

Etapa 6 – Diseño físico

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 en detalles específicos de hardware y software y según los estándares apropiados.