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

El método de análisis y diseño de sistemas estructurados (originalmente lanzada como metodología) es un enfoque de sistemas para el análisis y diseño de sistemas de información. SSADM fue producida para la Agencia Central de Informática y Telecomunicaciones (ahora Oficina de Comercio Gubernamental), un gobierno del Reino Unido la oficina de que se trate con el uso de la tecnología en el gobierno, a partir de 1980.

Información general

SSADM es un método de cascada para el análisis y diseño de sistemas de información. se considera que SSADM representa el pináculo del enfoque riguroso en la documentación hacia el diseño del sistema que contrasta con métodos ágiles como DSDM o Scrum.

SSADM es una aplicación en particular y se basa en el trabajo de las diferentes escuelas de análisis estructurados métodos y desarrollo, como la de Peter Checkland Metodología blanda de sistemas, de Larry Constantino diseño estructurado, de Edward Yourdon Método estructurado de Yourdon , de Michael A. Jackson Programación Estructurada de Jackson, y Tom DeMarco análisis estructurado.

Los nombres "Sistemas estructurados método de análisis y diseño" y "SSADM" son marcas registradas de la Oficina Gubernamental de Comercio (OGC), que es una oficina de Hacienda del Reino Unido.^[1]​

Historia

Las principales etapas del desarrollo de SSADM fueron:^[2]​

• 1980: Central de Informática y Telecomunicaciones Agencia (CCTA) evaluar los métodos de análisis y diseño.
• 1981: Consultores que trabajan para Learmonth y Burchett Sistemas de Gestión, dirigidos por John Hall, elegidos para desarrollar v1 SSADM.
• 1982: John Hall y Keith Robinson dejó para fundar Modelo Systems Ltd, LBMS más tarde desarrollaron LSDM, su versión privativa.
• 1983: SSADM hizo obligatorio para todos los nuevos desarrollos de sistemas de información
• 1984: La versión 2 de SSADM lanzado
• 1986: La versión 3 de SSADM liberada, aprobada por NCC
• 1988: SSADM Certificado de Competencia lanzó, SSADM promovida como estándar "abierto"
• 1989: Se mueve hacia Euromethod, lanzamiento del programa de certificación de productos CASE
• 1990: La versión 4 lanzada
• 1993: Plan de Conformidad SSADM V4 estándar y Herramientas
• 1995: SSADM V4 + anunció, V4.2 lanzó
• 2000: ACTC renombrado SSADM como "Business Development System". El método fue reenvasado en 15 módulos y se añadieron otras 6 módulos.^[3]​^[4]​

Técnicas SSADM

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

Modelado de datos lógicos

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

Modelado de flujo de datos

El proceso de identificar, modelar y documentar cómo los datos se mueven alrededor de un sistema de información. El Modelado de flujo de datos examina los procesos (actividades que transforman los datos de una forma a otra), almacenes de datos (las zonas de espera de los datos), entidades externas (lo que envía los datos a un sistema o recibe datos de un sistema), y los flujos de datos (rutas por el cual los datos pueden fluir).

Modelado Entidad Evento

Es un proceso de dos hebras: Behavior Modeling Entidad, identificar, modelar y documentar los eventos que afectan a cada entidad y la secuencia (o historia de vida) en el que se producen estos eventos, y Modelado de eventos, diseñando para cada caso el proceso para coordinar las historias de vida entidad.

Etapas

El método SSADM implica la aplicación de una secuencia de tareas de análisis, documentación y diseño relacionados con lo siguiente.

Etapa 0 - Estudio de viabilidad

Con el fin de determinar si es o no viable un determinado proyecto, tiene que haber algún tipo de investigación sobre los objetivos y las implicaciones del proyecto. Para los proyectos de muy pequeña escala esto puede no ser necesario en absoluto ya que el alcance del proyecto es fácil de entender. En proyectos de mayor envergadura, 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 un "must-have", y tendrá que ser hecho de una manera u otra. Cuando un estudio de viabilidad se lleva a cabo, hay cuatro áreas principales de consideración:

Técnica - es el proyecto técnicamente posible?
financiera - puede permitirse el negocio para llevar a cabo el proyecto?
Organizacional - será el nuevo sistema sea compatible con las prácticas existentes?
ético - es el impacto del nuevo sistema socialmente aceptable?

Para responder a estas preguntas, el estudio de viabilidad es efectivamente una versión condensada de un análisis de sistemas totalmente soplado y diseño. Los requisitos y los usuarios se analizan en cierta medida, algunas opciones de negocio son elaboradas e incluso algunos detalles de la ejecución técnica. El producto de esta etapa es un documento formal del estudio de factibilidad. SSADM especifica las secciones que el estudio debe contener incluyendo cualquier modelos preliminares que se han construido y también los detalles de las opciones de excluidos y los motivos de su rechazo.

Etapa 1 - Investigación de la situación actual

Esta es una de las etapas más importantes de SSADM. Los desarrolladores de SSADM entendieron que en casi todos los casos hay algún tipo de sistema de corriente incluso si está compuesta en su totalidad de las personas y de papel. A través de una combinación de entrevistar a los empleados, cuestionarios, observaciones de circulación y documentación existente, el analista llega a la comprensión completa del sistema, ya que se encuentra al principio del proyecto. Esto sirve para muchos propósitos:

• el analista aprende la terminología de la empresa, lo que los usuarios hacen y cómo lo hacen.
• el viejo sistema proporciona los requisitos básicos para el nuevo sistema.
• fallas, errores y áreas de ineficiencia se resaltan y sus correcciones se añaden a los requisitos.
• el modelo de datos se puede construir.
• los usuarios se involucran y aprenden las técnicas y modelos del analista.
• los límites del sistema se pueden definir.

Los productos de esta etapa son:

• Catálogo de Usuarios describe todos los usuarios del sistema y cómo interactuar con él.
• Catálogo de Necesidades detalla todos los requisitos del nuevo sistema.
• Servicios actuales Descripción compuso más de
• Entorno actual lógica de datos Modelo
• Diagrama de Contexto ( DFD )
• Conjunto nivelado de DFD para la corriente sistema lógico
• Diccionario de datos completo incluyendo la relación entre los almacenes de datos y entidades

Para producir los modelos, el analista trabaja a través de la construcción de los modelos que hemos descrito. Sin embargo, el primer conjunto de diagramas de flujo de datos ( DFD ) son el modelo físico actual, es decir, con todos los detalles de cómo se implementa el sistema antiguo. La versión final es el modelo lógico actual que es esencialmente la misma que la corriente física pero con toda referencia a la aplicación eliminado junto con las redundancias como la repetición de la información que compone los usuarios y los requisitos catálogos.

Etapa 2 - opciones del sistema de negocios

Tras investigar el sistema actual, el analista debe decidir sobre el diseño general del nuevo sistema. Para hacer esto, él o ella deben usar las salidas de la etapa anterior, se desarrolla un conjunto de opciones de negocios del sistema. Estas son diferentes formas en que el nuevo sistema podría ser producido variando de no hacer nada para tirar el viejo sistema en su totalidad y la construcción de uno totalmente nuevo. El analista puede realizar una sesión de lluvia de ideas para que se generen tantas y diversas ideas como sea posible.

Las ideas se recogen entonces para formar un conjunto de dos o tres opciones diferentes que se presentan al usuario. Las opciones en cuenta lo siguiente:

• el grado de automatización
• el límite entre el sistema y los usuarios
• la distribución del sistema, por ejemplo, ¿es centralizada a una oficina o hacia fuera a través de varios?
• costo / beneficio
• impacto del nuevo sistema

Cuando sea necesario, la opción será documentada con una estructura de datos lógica y un diagrama de flujo de datos de nivel 1.

Los usuarios y analista juntos escogen una opción de negocio único. Esta puede ser una de las ya definidas o puede ser una síntesis de los diferentes aspectos de las opciones existentes. La salida de esta etapa es la opción seleccionada de negocios única, junto con todas las salidas de la etapa de factibilidad.

Etapa 3 - Requisitos de especificación

Esta es probablemente la etapa más compleja en SSADM. Usando los requisitos desarrollados en la etapa 1 y trabajando en el marco de la opción de negocio seleccionado, 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 error, ambigüedad e inconsistencia. Por lógica, nos referimos a que la especificación no dice cómo se implementará el sistema, sino que describe lo que el sistema va a hacer.

Para producir la especificación lógica, el analista construye los modelos lógicos necesarios tanto para los diagramas de flujo de datos (DFDs) y el modelo de datos lógicos (LDM), que consiste en la estructura lógica de datos (contemplados en otros métodos como diagramas entidad relación ) y una descripción completa de los datos y sus relaciones. Estos se utilizan para producir la definición de funciones de todas las funciones que los usuarios requieren del sistema, una entidad de vida-Historias (ELHs) que describen todos los acontecimientos a través de la vida de una entidad, y el efecto de Correspondencia Diagramas (ECD) que describen cómo interactúa cada uno de los eventos con todas las entidades pertinentes. Estos son continuamente comparan con los requisitos y en caso necesario, se añaden los requisitos para y completados. El producto de esta etapa es un documento completo con la especificación de requisitos que se compone de:

• el catálogo de datos actualizada
• el catálogo de requisitos actualizado
• la especificación de procesamiento que a su vez se compone de
  • rol de usuario matriz de funciones /
  • definiciones de funciones
  • modelo lógico de datos requerido
  • historias de vida entidad
  • diagramas efecto correspondencia

Aunque algunos de estos artículos pueden ser desconocidos para usted, está más allá del alcance de esta unidad para entrar en ellos con gran detalle.

Etapa 4 - opciones del sistema Técnicas

Esta primera etapa es una implementación física del nuevo sistema. Al igual que las opciones del sistema de negocio, en esta etapa se generan un gran número de opciones para la aplicación del nuevo sistema. Esto se perfeccionó hasta dos o tres usuario para presentar desde que se elige la opción o sintetizado final. Sin embargo, las consideraciones son seres muy diferentes:

• las arquitecturas de hardware
• el software a utilizar
• el costo de la implementación
• la dotación de personal necesaria
• las limitaciones físicas, tales como un espacio ocupado por el sistema
• la distribución incluidas las redes que pueden requerir
• el formato general de la interfaz ofrecida a los usuarios

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

La salida de esta etapa es una opción de sistema técnico elegido.

Etapa 5 - Diseño lógico

Aunque el nivel anterior especifica los detalles de la ejecución, los resultados de esta etapa son independiente de la implementación y se concentran en los requisitos de la interfaz de la computadora humana. El diseño lógico especifica los principales métodos de interacción en términos de estructuras de menús y estructuras de mando.

Un área de actividad es la definición de los diálogos de usuario. Estas son las principales interfaces con que los usuarios podrán interactuar en el sistema. Otras actividades están relacionadas con el análisis de los efectos de actualización del sistema tanto de los acontecimientos en la necesidad de hacer consultas sobre los datos en el sistema. Ambos utilizan los eventos, descripciones de las funciones y diagramas efecto correspondencia 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 que se compone de:

• Catálogo de datos
• Estructura de datos lógica requerida
• Modelo de proceso lógico - incluye diálogos y modelo para los procesos de actualización y consulta
• El estrés y momentos de flexión.

Etapa 6 - Diseño físico

Esta es la etapa final en la que todas las especificaciones lógicas del sistema se convierten en las descripciones del sistema en términos de hardware y software real. Esta es una etapa muy técnica y un simple resumen se presenta aquí.

La estructura lógica de los datos se convierte en una arquitectura física en términos de estructuras de base de datos. Se especifica la estructura exacta de las funciones y la forma en que se implementan. La estructura de datos física se optimiza cuando sea necesario para satisfacer los requisitos de tamaño y rendimiento.

El producto es un diseño físico completo que podría decirle a los ingenieros de software la manera de construir el sistema en detalles específicos de hardware y software y para los estándares apropiados.

Ventajas y desventajas

Un enfoque metodológico del estudio de una empresa (o un área de una empresa) a partir de un número de diferentes perspectivas es más probable que proporcione una comprensión más completa de la empresa, sus procesos y datos, que los enfoques "ad-hoc" que se utilizaron previamente. Esto a su vez debería (se esperaba) conducen a los sistemas que son más completos y correctos.

Sin embargo, el enfoque SSADM de tener que completar una fase antes de comenzar la siguiente etapa que lleve a algunos proyectos en lo que se conoce como "parálisis de análisis". ¿Qué se quiere decir con esto es que debido a que una empresa y sus procesos nunca permanece igual por mucho tiempo, el equipo de sistemas continuamente tendría que revisar el análisis y diseño de productos para su modificación, causando (a veces muy largo) las demoras en llegar a las fases de la programación y entrega del sistema. En reconocimiento de esto, las versiones posteriores de la Metodología introdujeron un enfoque más opcional / dinámica al proceso.

También hay un coste en la formación de las personas a utilizar las técnicas. La curva de aprendizaje puede ser considerable si se utiliza el método de integración global, ya que no sólo hay varias técnicas de modelado para llegar a un acuerdo con, pero también hay una gran cantidad de normas para la preparación y presentación de documentos.

En resumen, el uso de esta metodología implica una tarea significativa que puede no ser adecuado para todos los proyectos.

Referencias

1. . Office of Government Commerce (OGC). Archivado desde el original el 1 de mayo de 2011. Consultado el 17 de diciembre de 2010. 
2. Mike Goodland; Karel Riha (20 de enero de 1999). . SSADM – an Introduction. Archivado desde el original el 22 de agosto de 2010. Consultado el 17 de diciembre de 2010. 
3. . Model Systems Ltd. 2002. Archivado desde el original el 2 de abril de 2009. Consultado el 2 de abril de 2009. 
4. SSADM foundation. Business Systems Development with SSADM. The Stationery Office. 2000. p. v. ISBN 0-11-330870-1. 

Enlaces externos

• ¿Qué es SSADM? at webopedia.com
• Estructurado Wiki (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).

•   Datos: Q1187450