M�todo de an�lisis y dise�o de sistemas estructurados

Ir a la navegaci�nIr a la b�squeda
(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.

�ndice
1 Informaci�n general
2 Historia
3 T�cnicas SSADM
4 Etapas
4.1 Etapa 0 - Estudio de viabilidad
4.2 Etapa 1 - Investigaci�n de la situaci�n actual
4.3 Etapa 2 - opciones del sistema de negocios
4.4 Etapa 3 - Requisitos de especificaci�n
4.5 Etapa 4 - opciones del sistema T�cnicas
4.6 Etapa 5 - Dise�o l�gico
4.7 Etapa 6 - Dise�o f�sico
5 Ventajas y desventajas
6 Referencias
7 Enlaces externos
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 propietaria.
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.