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.

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]​

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

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

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.

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.

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:

Los productos de esta etapa son:

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.

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:

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.

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:

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.

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:

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.

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:

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.

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.