18. Paper 7 - Análisis Estructurado

Paper 7
ANÁLISIS ESTRUCTURADO DE SISTEMAS
Por: Alberto R. Lardent
Concepto
El análisis estructurado de sistemas debe considerarse como una disciplina que
aplica un conjunto de herramientas y técnicas que permiten conocer aquello que
debe hacer un sistema nuevo para que sirva mejor a los interese de los usuarios
del mismo.
Consiste en la construcción de un modelo lógico de un sistema para lo cual
utiliza técnicas gráficas que facilitan a usuarios y analistas observar cómo actúan y
cómo se ensamblan las partes del sistema para satisfacer los requerimientos de
los usuarios.
Los problemas del análisis de sistemas tradicional
El análisis de sistemas tradicional enfrentaba problemas en varias fuentes: a)
dificultades políticas: se presentan en grandes proyectos, en los que el nuevo
sistema deberá servir a distintos grupos de interés, tal vez en conflicto; b)
problemas de comunicación que se plantean cuando varias personas que
provienen de distintas fuentes y con distintas experiencias deben trabajar juntas;
c) problemas propios de aspectos técnicos: usuarios que conocen y sufren sus
necesidades pero no saben explicarlas en un sentido técnico, y programadores
que dominan la técnica pero no tienen experiencia directa en cuanto a aplicarla
para el mejoramiento del negocio.
Se hacía difícil así compatibilizar aquello que “es actualmente posible” para la
tecnología y aquello que “vale la pena hacer” para beneficio de la empresa. En
consecuencia:



Se hacía difícil para el técnico en informática comprender lo suficiente del
negocio tal como lo ve el usuario.
El usuario no tenía los conocimientos técnicos necesarios (ni le interesaba
tenerlos) dado que no eran parte de sus objetivos profesionales o laborales.
En el momento de análisis de un problema tanto el usuario como el experto
en informática se veían invadidos por una cantidad enorme de detalles que,
en la medida en que los mismos no fueran organizados conforme a una
rigurosa disciplina y con herramientas adecuadas, podrían causar
inconvenientes serios en el entendimiento del problema y, obviamente en el
Alberto R.ardent


Sistemas y Métodos Administrativos
1
logro de su solución (diseño posterior al análisis).
El diseño del nuevo sistema se veía limitado si se daba prioridad a la
especificación física del sistema ( diseño físico de archivos, bases de datos,
elaboración de programas) con relación a la formulación del modelo lógico
(descripción funcional).
La ausencia de un modelo de sistema de fácil comprensión para el usuario
provocaba la generación de errores (por ejecución o por omisión) que eran
detectados en una etapa muy tardía en el ciclo de desarrollo de un sistema
(cuando éste estaba prácticamente terminado). El costo de corrección de
un error crece fuera de toda proporción cuanto más tarde se detecta.
En resumen: antes de la formulación del análisis estructurado no había forma
de exponer las funciones lógicas básicas y requerimientos de un sistema: se
mostraban directamente los detalles de la implementación física. Esto provocaba
inconvenientes en cuanto a calidad, costo y tiempo de desarrollo de los sistemas.
Atributos, beneficios y problemas potenciales del análisis estructurado
Tal como se ha planteado más arriba el análisis tradicional presentaba varios
problemas, cuya solución se convierte en los atributos fundamentales del análisis
estructurado. Entre esos atributos mencionaremos los siguientes:



Estimula la construcción de un modelo lógico (comprensible por los
usuarios) antes que la elaboración de un diseño físico (casi siempre
comprensible sólo por quienes tienen conocimiento avanzado en
informática).
Los usuarios obtienen una idea más real del sistema propuesto al visualizar
los diagramas lógicos de flujo de datos (para lo cual no necesitan tener
conocimientos de programación de computación). Por tanto prodigan una
actitud más positiva hacia el proyecto. La consecuencia será que el sistema
luego de construido se ajustará a los requerimientos manifestados por los
usuarios.
La forma gráfica de presentar la lógica del sistema permite detectar (en
tiempo temprano con relación al avance del proyecto) los aspectos mal
interpretados y conflictivos. Esto facilita su corrección antes de que el
proyecto avance hacia otras actividades y que los errores de definición no
corregidos obliga a modificaciones trascendentes y costosas cuando el
proyecto ya ha avanzado un trecho importante.
Evita la sobre-documentación propia de las metodologías tradicionales, que
contaban con una exhaustiva descripción narrativa del sistema (que
resultaba tediosa, poco clara y ambigua). En el análisis estructurado las
narraciones son reemplazadas por herramientas gráficas de fácil
comprensión

Permite el desarrollo “de arriba hacia abajo”. Esto significa graficar módulos
Alberto R. Lardent
Sistemas y Métodos Administrativos
2
.
del proyecto por niveles, lo que facilita a su vez codificar (escribir las instruc
ciones de programa) los módulos de alto nivel antes de que se complete el
diseño detallado de los módulos de bajo nivel. Las metodologías tradicionales requieren que se complete todo el diseño detallado antes de que pueda
iniciarse cualquier codificación de programa.
Esto deriva
en
el enfoque en línea recta como opuesto al enfoque en espiral propio del aná
lisis estructurado.
El enfoque en línea recta significa pasar sucesivamente por todas las etapas de desarrollo de un sistema que se inicia con el estudio de factibilidad y
continúa con el análisis, diseño, programación, prueba, aprobación y puesta
en marcha.
Factibilidad
Análisis
Diseño
Programación
Prueba
Proyecto en línea recta
El enfoque en espiral del análisis estructurado se ajusta mejor a la realidad
actual dado que las etapas mencionadas en el modelo anterior se administran en forma iterativa, formando en lenguaje figurado una espiral pues se
realiza una parte de análisis, luego un pequeño diseño; después se retroce
de y se efectúa otro pequeño análisis y un diseño más detallado y se comienza con codificación del primer diseño, etcétera.
Proyecto en espiral

Permite que el control que debe ejercer el director del proyecto se apoye en
entregas, en lugar de hacerlo sobre la base de actividades. Las
metodologías tradicionales controlaban el avance del proyecto declarando,
por ejemplo, que “el análisis está terminado” y “falta terminar el diseño”, o
bien “se ha completado el diseño”. Esto significa que el control se verificaba
(en las metodologías tradicionales) respecto a “etapas” del proyecto. Y si
una etapa no se había completado se estimaba el porcentaje de avance de
esa etapa. Pero esta forma de medición no es útil: si la codificación estaba
“avanzada en un 90 %” parecía una buena medida de adelanto, pero lo
cierto es que mientras tanto no se había concretado nada en la pràctica
sobre el proyecto . El control del avance del proyecto deberá medirse (en la
_______________________________________________________________
Alberto R. Lardent
Sistemas y Métodos Administrativos
3
nueva tecnología) por entregas. Cada entrega se referirá a una versión del
diagrama de flujo de datos (DFD) o del diagrama de estructura (DE).
A medida que avanza un proyecto estructurado cada entrega (presentación de un DFD) es un refinamiento en cuanto al nivel de detalle: al operar
“de arriba hacia abajo” a medida que se desciende se aumenta la cantidad
de detalles de cada versión hasta llegar a la versión definitiva. La diferencia del mecanismo de control en un escenario de análisis estructurado radica en definir entregas de productos terminados (DFD, DE) en lugar de
definir el grado de avance de actividades.
 La documentación en el diccionario de datos de las especificaciones de los
datos que participan en un diagrama de flujo de datos significa un ahorro
importante de tiempo en el momento en que los programadores deban
recurrir a esas especificaciones para elaborar los programas respectivos.
Además ese diccionario de datos servirá para dilucidar situaciones en las
que el personal de la empresa llama a las mismas cosas con nombres
diferentes o cuando un término sea considerado conceptualmente
dependiendo del contexto en el que se lo aplique. Por ejemplo, en una
empresa el concepto “producto” podría ser considerado equivalente a
“artículo” o bien no.
No obstante la existencia de los beneficios señalados, deben reconocerse también
los problemas potenciales que surgen de la aplicación de esta técnica, Entre ellos
indicaremos los siguientes:




La aplicación de esta técnica significa un cambio cultural que implica un
cambio de reglas. Todo cambio genera en un principio una resistencia por
parte del afectado. Requiere una reorientación de actividades y esto
provoca un esfuerzo.
Obliga al usuario a una mayor participación y compromiso. Debe insertarse
en la actividad de diseño, aunque él no sea ni pretenda ser un especialista
en el tema.
Significa un esfuerzo importante en cuanto al tiempo de dedicación al
proyecto, particularmente en las primeras etapas del desarrollo. Ello se
debe al nivel de detalle que se exige en las definiciones y determinación de
requerimientos.
Los programadores pueden sentir limitadas sus capacidades de creatividad
al tener que seguir estrictas normas estructuradas en su actividad de
codificación, al tener que ajustarse al modelo lógico ya diseñado.