Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
org
SISTEMAS DE PROCESAMIENTO ELECTRONICO
Alkins, A. C. Computadores y procesamiento de datos
Bellavoine, C. Qu es una computadora?
Benice, D. D. Temas de computacin electrnica
Brady, A. H. - Richardson, J. T. Lenguaje de programacin
BASIC (SEPA)
Clark, F. J. Procesamiento de informacin
Couger, J. D. - Shannon, L. E. Introduccin al lenguaje
FORTRAN (SEPA)
Christie, L. G. - Curry, J. W. El ABC de los microcomputadores
Donovan, J. J. Programacin de sistemas
Ekman, T. - Nilsson, K. COBOL
Elliot, C. O. Introduccin al procesamiento de datos (SEPA)
Flores, I. Arquitectura de bases de datos
Flores, I. - Terry, Ch. Sistemas de microcomputacin
Gane, Ch. - Sarson, T. Anlisis estructurado de sistemas
Garca Poquet, J. Computacin para todos
Gardner, A. Programacin estructurada: LCP prctico
Jensen, K. - Wirth, N. Pascal
Kallin, S. FORTRAN
Langefors, B. Teora de los sistemas de informacin
Langefors, B. - Sanrtuelson, K. Informacin y datos en los
sistemas
Lyon, J. K. Bases de datos
Morange, P. Introduccin a la programacin
Myers, G. J. El arte de probar el software
Parker, A. J. - Stewart, J. F. Programacin BASIC para
contadores
Shipman, C. Cmo programar su computador personal.
BASIC elemental para PC
Tomlin, . Introduccin de la computadora en la empresa
Vazsonyi, A. Introduccin a la computacin electrnica
Wirth, N. Introduccin a la programacin sistemtica
www.FreeLibros.org
ANALISIS
ESTRUCTURO
DE SISTEMAS
Chris Gane
Trish Sarson
Traduccin
Ing. Julio C. Abramoff
Sociedad de Computacin Argentina
Cuidado de la edicin
Dr. Edmundo Said
Universidad Catlica Argentina (UCA)
LIBRERIA "EL ATENEO" EDITORIAL __________
BUENOS AIRES - LIMA - RIO DE JANEIRO CARACAS |V|I|I||
MEXICO - BARCELONA MADRID - BOGOTA ----------
www.FreeLibros.org
Serle; Sistemas de procesamiento electrnico
. Directo; Dr. Federico FfIsMomcM
Titulo de te obra original.; "Structured Systems Anaiysia;
Tole and Technlquee"
1881, t982 by McDonnell Douglas Corporation,
Saint Louis, Missouri.
Todos los derechos reserva*.
Eetellbro no puede producirse, total o parcialmente,
por jtlndn mtodo grfseo, electrnico o mecnico,
Incluyendo los sistemas de fotocopia, registro magnetofnico
o de alimentacin de dalos, sin expreso consentimiento del editor.
Queda hecho el depsito que establees la ley N0 11.723.
1987 El. ATENEO*' Pedro Sarcia S.A.
Librera, Editorial e Inmobiliaria, Florida 340, Buenos Aires.
Fondada eR 1912 por don Pedro Garca.
ISBN 950-02-5261-2
M t R E S O E N L A A R G E N T I N A
www.FreeLibros.org
INDICE
PREFACIO . . . . . ........... XI
1. La necesidad de mejores herramientas . . . ....................................... ., . 1
1.1 Qu fracasa en el anlisis? .............................................. 1
1.2 Podemos culpar a nuestras herramientas? ........... 3
1.2.1 No existe "modelo en el procesamiento de datos. 1.2.2 l a narra
cin en lenguaje corriente es muy vaga y embrollada. 1.2.3 Los flujogra-
mas hacen ms mal que bien, 1.2.-4 No poseemos una forma sistemtica
para registrar las preferencias y las soluciones de compromiso del usuario,
especialmente en trminos de acceso inmediato de tos datos.
1.3 Cunto importan las especificaciones funcionales?................................ 6
2. Cules son tas herramientas y cmo encajan entre s i ______ 8
2.1 Primero* dibujar un diagrama lgico de flujo de datos . . . . . . ___. . . . . . I
2.1.1 Condiciones de error. 2.1.2 Implementaciones fsicas alternativas.
2.1 J La clase general dei sistema,
2.2 A continuacin, colocar el detalle en un diccionario de dalos . . . . . . . . . . . 15
2.3 Definir a lgica de los procesos.............................................. 1?
2.4 Definir los almacenamientos de datos; contenidos y acceso Inmediato . 19
2.4.1 Son tos almacenamientos lgicos de datos los mis simples po
sibles? 2,4.2 Qu accesos inmediatos se necesitarn?
2.5 Utilizacin de las herramientas para crear una especificac n funcional . 23
Ejercicios y puntos de discusin................... 23
3. Dibujo de tos fiujogramas de datos ............... 28
3.1 Convenciones sobre smbolos .............._.................... 26
3.1.1 Entidad externa. 3.1.2 Flujo de datos. 3,1,3 Proceso. 3.1,4 Al
macenamiento de ciatos.
3.2 Convenciones sotare la explosin............................................. 32
3.3 Tratamiento de errores y excepciones ..................................................... 34
3.4 Rautas para dibujar ios diagramas de flujo de da to s . 35
3.5 Ejemplo; Distribucin con inventario . . . . . . . . . . . . . ___ 36
3.6 Flujo de materiales y flujo de datos....................... 48
Ejercicios y puntos de discusin ........................ ' 50
4. Construccin y uso de un diccionario de datos ...... 51
4.1 El problema de describir datos ..................... 51
4.2 Qu desearamos que contenga un diccionario de d a to s ................................ 54
V I I
www.FreeLibros.org
4.2.1 Descripcin de un elemento de datos. 4.2.2 Descripcin de estruc
turas de datos. 4.2.3 Descripcin de los flujos de datos. 4,2.4 Descrip
cin de los almacenamientos de datos. 4.2.5 Descripcin de tos proce
sos, 4.218 Descripcin de tas entidades externas. 4,2.7 Descripcin de
las entradas ai glosario.
4.3 Diccionarios de datos manuales y automatizados.................................... 65
4.4 Qu podemos desear extraer de un diccionario de datos ___ 65
4.4.1 Listados ordenados de todas las entradas o de varias clases de
entradas con un detalle total o parcial. 4.4.2 Informes compuestos,
4.4.3 Capacidad de referencia cruzada. 4.4.4 Encontrar el nombre a par
tir de una descripcin. 4 4,5 Control de consistencia e integridad. 4.4,6
Generacin de definiciones de datos legibles por mquina. 4.4,7 Extrac
cin de las entradas del diccionario de datos desde programas existentes.
4.5 Ejemplo de un diccionario de datos automatizado ......... 69
4.6 Proyectos cruzados O diccionarios de dates globales para ia empresa , . 76
4.7 Diccionario de datos y procesamiento distribuido........................... 77
Ejercicios y puntos de discusin...................... 78
5. Anlisis y presentacin de la lgica del proceso . . . 80
5.1 Los problemas para expresar ia lgica ....................................................... ' 80'
5.1.1 No solo pero no obstante, y/o a menos que... 5.1.2 Mayor que, mi-
. or que. 5.1.3 Ambigedad y/o, 5.1.4 Adjetivos indefinidos. 5.1,5 Ma-
1 nejo de combinaciones de condiciones.
/ 5.2 Arboles de decisin ................................... 87
5.3 Tablas de decisin ......... 92
5.3.1 Condiciones, acciones y reglas. 5,3,2 Construccin de ia matriz de
reglas. 5.3.3 Indiferencia. 5.3,4 Extensin de las entradas, el problema
de la tarifa del flete. 5.3.5 Tablas de decisin y rboles de decisin.
5.4 Lenguaje estructurado, pseudocdigo" y "lenguaje comprimido" . . . . . 99
5.4.1 Las "estructuras" de la programacin estructurada. 5.4.2 Conven
ciones para el lenguaje estructurado. 5.4.3 Pseudocdigo". 5.4,4 "Len
guaje comprimido" lgicamente, 5.4.5 Pros y ccentras de las cuatro herra
mientas. 5.4,6 Quin hace qu?
Ejercicios y puntos de discusin ....... 112
6. Definir el contenido de los almacenamientos de datos ........................... 113
6.1 Lo que sale debe entrar , , ....... 113
-6.2 Simplificacin del contenido del almacenamiento de dalos mediante ins
peccin .............. ............................................... / ............... 116
6.3 Simplificacin del contenido del almacenamiento de datos mediante la
normalizacin ............ 117
6.3.1 El vocabulario para la normalizacin.
6.4 Algunas formas normalizadas son ms simples que otras ................ 120
6.4.1 Primera forma normal 1FN). 6.4.2 Segunda forma normal
(2FN). 6.4.3 Tercera forma normal (3FN).
6.5 Haciendo relaciones a partir de relaciones-proyeccin y unin 123
6.5.1 Proyeccin. 6.5,2 Unin.
6.6 La importancia de la tercera forma norma! --------- 126
6.7 Un ejemplo prctico de 3FN..................... 127
6.7.1 Normalizacin del almacenamiento de datos de CLIENTES. 6.7.2
Normalizacin del almacenamiento de datos de LIBROS. 6.7,3 Normaliza
cin del almacenamiento de datos de CUENTAS A COBRAR. 6.7.4 Norma-
Vlil
www.FreeLibros.org
Hzacin del almacenamiento de datos de INVENTARIO. 6.7.5 Juntando
las relaciones.
Ejercicios y puntos de discusin ........ ............. ...................................
7. Anlisis de los requerimientos de r e sp u e st a ........................................... ..
7.1 Descripcin de las formas en que se utilizan tos datos .......... ..
7.2 Tcnicas fsicas para el acceso inmediato...................................................
7.2.1 Indices. 7.2.2 Registros jerrquicos.
7.3 Capacidad de lenguaje genera) de consulta , .......... .......................
7.4 Tipos de consulta..............., ............... ...
7.4.1 Entidades y atributos. 7.4.2 Seis tipos bsicos de consulta. 7.4.3
Variaciones en los tipos bsicos de preguntas.
7.5 Bsqueda de ias necesidades y preferencias de los usuarios .
7.5.1 El acceso operativo vs. el acceso informativo. 7.5.2 Obtencin de
un listado de deseos compuesto. 7.5.3 Refinacin del listado de deseos.
7.6 Consideraciones sobre seguridad.............. .............. ..................................
Ejercicios y puntos de discusin........................ ............... .............................
8. Empleo de las herramientas; una metodologa estructurada . . . . . . ___
,8.1 El estudio inicial , .......... ............. .............................................................
8.2 El estudio detallado ........ ..........................................................
8-2.1. Definir con mayor detalle quines sern los usuarios de un sistema
nuevo. 8.2.2 Construccin de un modelo lgico del sistema actual. 8.2.3
Perfeccionar las estimaciones de IRACIS.
8.3 Definir un men de alternativas ............................................. .
8.3.1 Derivar objetivos para el nuevo sistema a partir de fas limitaciones
del sistema actual. 8.3.2 Desarrollar un modelo lgico del nuevo
sistema. 8,3.3 Producir diseos fsicos tentativos alternativos.
8.4 Utilizar el "men'* para obtener ei apoyo de los usuarios que toman deci
siones ............ ..........................................................................................
8.5 Refinacin del diseo fsico del nuevo proyecto ; ...... ................
8.5.1 Refinacin del modelo lgico. 8.5.2 Disear la. base de dalos fsi
ca. 8.5.3 Establecer la jerarqua de las funciones modulares que debern
programarse, 8.5.4 Definir las nuevas tareas administrativas que se Inter-
conectarn con el nuevo sistema. 8.5.5 Nota sobre estimaciones.
8.6 Ultimas fases del proyecto ...................................................................... .
Ejercicios y puntos de discusin.......................... .............................................
9. Derivar un diserto estructurado a partir de un modelo lgico . . . . . . . . . .
9.1 Los objetivos de! diseo ........ . ............. ................................................
9.1.1 Consideraciones de rendimiento. 9.1.2 Consideraciones sobre
control. 9.1,3 Consideraciones sobre la cambiabilidad.
9.2 Diseo estructurado para cambiabilidad .............. .................................
9.2.1 Qu contribuye a que un sistema sea modificadle? 9.2,2 Derivar
un sistema moddicable desde un diagrama de flujo de datos. 9.2.3
Acoplamiento de mdulos. 9,2.4 Mdulos bien formados; coherencia,
cohesin, ligazn. 0.2.5 Problemas de alcance de efecto/alcance de
control.
9.3 La solucin de compromiso entre cambiabilidad y rendimiento . . . . -----
9.4 Un ejemplo de diseo estructurado .......... .........................
9.4.1 Los limites del diseo, 9.4.2 Consideraciones del diseo del archi
vo fsico. 9.4.3 Ubicacin de la trasformaein central en el diagrama de
134
135
135
136
141
143
148 '
154
155
157
S
i s |
169
170
175
175
177
177
184
196
197
IX
www.FreeLibros.org
flujo de datos. 9.4.4 Perfeccionamiento del diseo desde arriba hacia
abajo.
9.5 Desarrollo de arriba hacia abajo....................................................................... 216
9.5.1 Posibles versiones de arriba hacia abajo del sistema CBM, 9,5,2
Por qu desarrollar de arriba hacia abajo? 9.5.3 El papel del
analista. 9.5.4 Resumen.
Ejercicios y puntos de discusin.................................................................................. 222
10. La implementacin del anlisis estructurado de sistemas en su empre
sa ....................................................................................................................... 223
10.1 Los pasos en la implementacin del anlisis estructurado de sistemas 223
10.1.1 Revisin de las reglas fundamentales para la administracin de
proyectos. 10.1.2 Establecer normas y procedimientos para el uso del dic
cionario de datos y de otro software. 10.1.3 Capacitacin de los.analistas
en el uso de herramientas y tcnicas, 10.1.4 Orientar a los usuarios en_Los
nuevos procedimientos.
10.2 Beneficios y problemas.................................................. 227
10.2.1 Beneficios del empleo det anlisis estructurado de sistemas.
10,2.2. Problemas potenciales.
Glosario ..................................................................................................................... 231
X
www.FreeLibros.org
PREFACIO
Tenemos confianza en las tcnicas descritas en este libro. Han probado que sirven en
un rea dificultosa del procesamiento de datos: el anlisis y la definicin de aquello que
debe hacer un sistema nuevo para que tenga mayor valor segn el criterio de las personas
que pagan por ella
La disciplina consiste en un conjunto creciente de herramientas y tcnicas que han
sacado partido del xito de la programacin y el diseno estructurados. El concepto
fundamental es la construccin de un modelo lgico (no fsico) de un sistema, empleando
tcnicas grficas que permiten a usuarios, analistas y diseadores obtener un cuadro claro
y comn del sistema y, mostrarles cmo se ensamblan sus partes para satisfacer las
necesidades de los usuarios. Hasta el desarrollo de las herramientas del anlisis
estructurado de sistemas, no haba forma de mostrar las funciones lgicas bsicas y los
requerimientos de un sistema; se caa rpidamente en los detalles de la implementacin
fsica actual o de la-propuesta.
El libro comienza con una discusin sobre algunos de los problemas que encontramos
en el anlisis y, luego, sepasa revista a las herramientas grficas y la forma de combinarlas
para obtener un model lgico. Luego tomamos una herramienta por vez y las tratamos en
detalle en los Captulos 3 al 7, comenzando con la herramienta clave, el diagrama lgico de
finjo de datos. Como empleamos herramientas para construir un modelo lgico, aforma en
que desarrollamos el sistema es algo diferente a los enfoques tradicionales; en el Captulos
bosquejamos una metodologa para el desarrollo de sistemas estructurados aprovechando
las ventajas de las nuevas herramientas. Esta metodologa involucra la construccin de un
sistema desde arriba hacia abajo mediante refinamientos sucesivos, produciendo primero
un flifio de datos de todo el sistema, luego desarrollando flujos de datos detallados,
posteriormente definiendo el detalle de las estructuras de datos y la lgica de los procesos, y
por fin para entrar en el diseo de una estructura modular, etc. Analizamos de arriba hacia
abajo, diseamos de arriba hacia abajo, desarrollamos de arriba hacia abajo, probamos de
arriba hacia abajo. Incluso reconocemos que el buen desarrollo incluye iteraciones; se debe
estar preparado para perfeccionar el modelo lgico y el diseo fsico a la luz de la
informacin resultante del uso de una versin temprana de este modelo o diseo.
- Distinguimos el trabajo del analista (definiendo "qu" deber hacer el sistema) del
trabajo del diseador (definiendo "cmo" deber hacerlo), reconociendo que a menudo el
analista hace diseo y los diseadores tambin, a menudo, hacen anlisis. Parte del valor
del anlisis estructurado de sistemas radica enproveer al diseador las entradas necesarias
para definir los programas de modo de obtener la mxima cambiabilidad, o facilidad para
su cambio, empleando diseo estructurado. En el Captulo 9, repasamos la importancia de
la cambiabilidad y las tcnicas y conceptos del diseo estructurado, tomando un sistema
real, analizndolo y disendolo hasta el nivel de mdulo.
XI
www.FreeLibros.org
Finalmente en el Captulo 10, discutimos los beneficios que aparecen al cambiar tos
procedimientos tradicionales por estas nuevas tcnicas, con sus implicancias en la
administracin del control de losproyectos, y tos beneficios que se pueden esperar.
Hemos tratado en lo posible de no introducir nuevos trminos; pero, como la disciplina
se basa en el diseo estructurado ( que tiene su propio vocabulario) y en la teora de la base
de datos relaciona}(que tiene tambin su propio vocabulario), aparecen algunos trminos
np familiares. Cada uno de estos trminos se explica en su primera aparicin y tambin es
definido en el Glosario que se encuentra al final del libro.
Esperamos que usted encuentre titiles estas herramientas y tcnicas, ya sea un analista
de sistemas, un diseador, un gerente o un usuario de los servicios de procesamiento de
datos. Desearamos saber sobre sus experiencias en el empleo del anlisis estructurado de
sistemas, particularmente si las desea compartir con otros.
Agradecemos la ayuda de aquellos que nos kan autorizado a reproducir su material
registrado las contribuciones realizadas para el desarrollo de estas ideas por parte de
nuestros anteriores colegas de Yourdon, Inc., Tom de Marco, Vctor Weinberg y Ed
Yourdon.
CHRIS GANE
TRISH SARSON
www.FreeLibros.org
1
LA NECESIDAD
DE MEJORES HERRAMIENTAS
Por muchas razones, el anlisis de sistemas es la parte ms dificultosa del desarrollo de
un sistema de procesamiento de datos. No se trata simplemente de la dificultad tcnica del
trabajo, si bien muchos proyectos exigen que el analista tenga conocimientos profundos de la
tecnologa actualizada de procesamiento de datos. No se trata simplemente de las dificultades
polticas que se presentan, especialmente en grandes proyectos, donde el nuevo sistema
deber servir a varios grupos de inters, posiblemente en conflicto. Tampoco se trata
solamente de los problemas de comunicacin que surgen en cualquier situacin en la cual
personas de diferentes antecedentes, con distintos enfoques del contexto y diferentes
vocabularios, deban trabajar juntas. Es la resultante de estas dificultades lo que hace al
anlisis de sistemas tan duro y exigente: el hecho es que el analista debe / hacer de
intermediario entre la comunidad de los usuarios aquellos que tienen la sensibilidad de sus
problemas, pero encuentran dificultoso explicarlo y adems tienen vagos conocimientos de
cmo los puede ayudar el computador y la comunidad de los programadores aquellos que
estn ansiosos de que la organizacin cuente con una importante seccin de procesamiento de
datos, pero no poseen la informacin que permite saber qu es lo mejor para el negocio. El
analista debe hacer un balance entre aquello que es actualmente posible en nuestra tecnologa
en constante progreso (minis, micros, procesamiento distribuido, bases de datos, comunica
cin de datos) y aquello que vale la pena hacer en la empresa, tal como est dirigida por sus
administradores.
Si se hace un balance que resulte aceptable por todas las partes y que pueda resistir la
prueba del tiempo, se ha logrado la parte ms ardua del esfuerzo; si ha sido bien hecho,
cualesquiera sean las dificultades de diseo y programacin, el sistema que se construya
servir a las necesidades de! negocio. Si ha sido hecho pobremente, cualquiera sea la
excelencia de la implementacin, el sistema no satisfar las necesidades de la organizacin y
el costo exceder a los beneficios. Para lograr dicho balance, necesitaremos toda la ayuda que
podamos obtener. Este libro presenta algunas herramientas que han sido probadas satis
factoriamente.
1.1 QUE FRACASA EN EL ANALISIS?
Los problemas que el analista debe enfrentar estn todos relacionados; sta es una de las
razones de su dificultad. Podemos distinguir cinco aspectos que merecen comentarse:
Problema 1. El analista encuentra muy difcil aprender lo suficiente del negocio para
poder verlos requerimientos del sistema a travs de los ojos del usuario. (Cuando empleamos
el trmino negocio queremos significar a la empresa de cualquier organizacin con o sin fines
1
www.FreeLibros.org
de lucro.) Una y otra vez omos decir: Hemos hecho un sistema tcnicamente excelente,
pero no era lo que el usuario deseaba. Por qu habr sido asi? Por que no podr el analista
estudiar sencillamente el negocio y reunir los elementos suficientes como para poder
especificar el sistema correcto? En el corazn de estos problemas encontramos el hecho de
que muchos gerentes usuarios son ejecutores ms que explicadores. Conocen y manejan
la informacin que necesitan de una forma intuitiva, sin pensar en trminos de flujo de
informacin o de lgica de decisin. Esto es natural; se llega a gerente tomando decisiones
correctas y haciendo tareas superiores y no explicando necesariamente cmo debe hacerse la
tarea y cmo deben tomarse las decisiones. Pero esto significa que el analista no tiene derecho
a esperar por parte de los usuarios una explicacin brillante de los requerimientos del sistema;
debe ayudarlos a resolver los problemas: Al mismo tiempo, el analista no posee el don de la
telepata; no puede saber aquello que no le han contado. Este hecho penoso se descubre
particularmente en trminos de la importancia relativa que los usuarios dan a las distintas
partes del sistema. Supongamos que un gerente en particular desee un informe del
movimiento diario de caja. Qu es ms importante, que lo reciba a las 08.30 horas aunque
existan algunos tem sin completar o bien que lo conozca hasta el detalle de los centavos,
aunque ello signifique recibirlo algunos das a las 11.00 horas? El gerente lo sabe muy bien y
podr decir: Vea, cualquier tonto que conozca algo de negocios debera saberlo! Pero es
arduo llegar en el negocio al nivel de sentir intuitivamente la mejor solucin de compromiso.
Problema 2. La comunidad usuaria no conoce an lo suficiente de procesamiento de
datos como para saber lo que es factible y lo que no lo es. La publicidad Sobre computadoras,
en general, no da a las personas una idea especfica y real sobre aquello que pueden o no
pueden hacer. Muchas personas no tienen idea de las posibilidades que puede brindar una
terminal CRT en linea y por qu habran de tenerla? La tecnologa es todava muy reciete
para que la mayora de las personas tenga un conocimiento bsico y una orientacin que le
permita imaginarse la forma en que podra afectarles un nuevo sistema. Los medios populares
no han ayudado; la imagen que tienen de las computadoras es, o bien que son caras y con
errores sin sentido, o bien, como en ciencia ficcin, de que cajas con decisiones propias se
apoderan del mundo.
Comparemos esta situacin con las ideas de las personas,digamos por ejemplo, con las
vinculadas a la industria de la construccin. Pensemos en un empresario que nunca antes ha
encargado la construccin de una fbrica, pero que ha entrado y salido de las fbricas durante
toda su vida de trabajo y se ha formado un conocimiento completo que le permite entender
todas las cosas de las que su arquitecto le habla. Adems, una fbrica es muy semejante a las
otras; por lo menos tendrn mucho ms en comn entre s que, digamos, un sistema en lote con
un sistema en lnea. Nuestros problemas son mayores en el procesamiento de datos que los de
la industria de la construccin, como consecuencia, en gran medida, de que no tenemos
manera de hacer un modelo de aquello que queremos construir. En un proyecto de ingeniera
o de construccin, culquiera sea su dimensin, el arquitecto discutir los requerimientos de
sus clientes y entonces podr producir un modelo que represente cmo se ver la estructura
terminada. Cualquier interesado podr mirar el modelo, relacionarlo Con sus experiencias
anteriores con este tipo de estructuras, y formarse una clara idea de lo que podr obtener por
su dinero. Las herramientas del anlisis estructurado de sistemas nos permitirn producir un
modelo grfico de un sistema que podr jugar casi el mismo rol que el modelo de una
construccin o de una refinera de petrleo.
Problema 3. El analista puede rpidamente verse abrumado por los detalles, tanto por
tos detalles del negocio como por los detalles tcnicos del nuevo sistema. La mayor parte del
tiempo de la fase de anlisis del proyecto se emplea en obtener informacin detallada de la
situacin actual, los procedimientos administrativos, los documentos de entrada, los informes
producidos y requeridos, las polticas en uso y los miles de hechos que surgen de una cosa tan
compleja como es una empresa real. A menos que exista algn esquema o estructura para
organizar estos detalles, el analista (y aun todo un equipo de analistas) podr verse
2
www.FreeLibros.org
sobrecargado con hechos y papeles. Los detalles son necesarios y debern estar disponibles
cuando se los requiera, pero el analista deber tener herramientas para controlar los detalles,
o de lo contrario encontrar que el rbol no le dejar ver el bosque. Parte del valor de un
enfoque de arriba hacia abajo, tal como veremos ms adelante, consiste en que le permitir
mirar el gran cuadro y luego ubicarse en el detalle de cada pieza, cuando y como sea
necesario.
Problema 4. El documento donde ubicamos los detalles de un nuevo sistema (el cual
puede denominarse de diferentes maneras: especificacin del sistema, diseo general,
especificacin funcional, o cualquier otro nombre equivalente) constituye un contrato
efectivo entre el departamento usuario y el grupo de desarrollo de sistemas, si bien es
frecuentemente imposible para dichos usuarios comprenderlo debido a su volumen y a los
conceptos tcnicos que contiene. De cierta manera recuerda el viejo estilo de las plizas de
seguro; las cosas que realmente son importantes se escriben en letra pequea. Los usuarios a
menudo hacen un esfuerzo valiente para conocer a fondo estos documentos y terminan
encogindose mentalmente de hombros y los firman, dicindose a s mismos Bueno, creo que
esta gente de computacin sabe lo que va a hacer. Solo cuando se les entrega el sistema
terminado tendrn algo que pueden entender y recin podrn reaccionar; por supuesto, ser
demasiado tarde.
Problema 5. Si el documento de especificaciones pudiera escribirse de manera que
tuviera sentido para los usuarios, quiz no seria de mucha utilidad para los diseadores fsicos
y programadores que deben construir el sistema. A menudo, debern hacerse una cantidad
considerable de iteraciones en el anlisis, duplicando en esencia el trabajo que el analista ha
realizado, para redefinir datos y procesos lgicos en trminos que los programadores puedan
utilizar. Aunque el analista tenga conocimientos tcnicos y de esa manera escriba las
especificaciones con un ojo puesto en la facilidad de la programacin, finalizar limitando la
libertad de accin de los programadores para implementar el sistema de la mejor manera. El
diseo fsico de los archivos, programas y mtodos de entrada/salida deber ser hecho por
alguien que tenga un conocimiento tcnico actualizado, basado en la comprensin de los
requerimientos lgicos completos del sistema. Comenzar a especificar el diseo fsico antes
que el modelo lgico del sistema est terminado es ser fsico prematuramente y a menudo,
da como resultado un sistema de inferior calidad.
1.2 PODEMOS CULPAR A NUESTRAS HERRAMIENTAS?
Aun contando con las mejores herramientas analticas posibles, nos encontraremos con
algunos de los problemas que hemos discutido recin. No existen, por ejemplo, herramientas
analticas que permitan al analista saber lo que tiene en su mente el usuario si ste no se lo
dice. No obstante, el tema de este libro es que los problemas de anlisis pueden ser
significativamente facilitados con las herramientas lgicas que describiremos, e identifica
mos cuatro limitaciones en nuestras actuales herramientas analticas.
1.2.1 No existe "modelo" en el procesamiento de datos
No tenemos forma de mostrar a los usuarios un modelo tangible vivido del sistema. A los
usuarios les es muy difcil imaginarse lo que podr hacer el nuevo sistema hasta que ste se
encuentre realmente en operacin y para ese entonces, ya ser tarde. Cmo puedo saber
qu quiero hasta ver lo que tengo? es el grito oculto de muchos usuarios. Las herramientas
grficas de este libro darn al usuario un mejor modelo del sistema de lo que fue posible
tener hasta ahora.
3
www.FreeLibros.org
1.2.2 La narracin eri lenguaje corriente es muy vaga y embrollada
Si no tenemos una forma de mostrar un modelo tangible, debemos tener lo mejor que
puede reemplazarlo, que es el empleo de la narracin en idioma comente para describir el
sistema propuesto. Puede usted imaginarse pagando cinco aos de sueldos por una casa
construida a su deseo, sobre la base de una exhaustiva descripcin narrativa de cmo se
construir la casa? Sin fotografas, sin planos, sin visitas a una casa similar slo ISO
paginas narrativas. La sala de estar que mira al sudsudeste tendr 8 x 5 m de ancho
mximo, con su mitad oeste en forma trapezoidal, la pared oeste tendr 4 m de largo (lindando
la parte norte de la pared este con la cocina)..
Habiendo pagado el dinero en base a la descripcin narrada y no habiendo visto nada
hasta que la casa se ha terminado, estara usted sorprendido si se desilusionara al mudarse?
Nos sorprendera que los usuarios se desilusionaran cuando se les entregan los sistemas?
Si usted utiliza el idioma corriente para describir un sistema complejo (o pard
construirlo) el resultado ser tan voluminoso que resultara muy difcil para el lector entender
cmo se combinan las partes. Peor que esto, como veremos en el Captulo 5, el idioma
Corriente tiene problemas de construccin, k> que hace muy difcil emplearlo donde se
requiere precisin.
1.2.3 Los flujogramas hacen ms mal que bien
Si no podemos hacer un modelo y el idioma corriente es muy vago y difuso, entonces,
qu pasara cOn un dibujo? Desafortunadamente hasta ahora el nico dibujo que disponemos
para un sistema es el fujograma. Aunque un flujograma puede valer por mil palabras, atrapa
al analista con una obligacin; utilizar los smbolos normalizados de flujogramas (ver Fig.
1.1) significa inevitablemente que el analista debe entregar la implementacin fsica del
nuevo sistema. El solo hecho de dibujar un diagrama de flujo significa que se ha tomado una
decisin de cmo ser la entrada: en tarjetas o a travs de una terminal CRT, qu archivos
estarn en cinta y cules en disco, qu programas tendrn salidas y cules no, etc. Sin
embargo, estas decisiones son esenciales para la tarea de los diseadores. Una vez que el
analista dibuj un flujograma del sistema qu le queda para hacer al diseador? Este tiene la
opcin entre aceptar el diseo fsico del analista y continuar pon los detalles del programay de
la estructura de los archivos, o (como sucede muy a menudo) retomar a las especificaciones
escritas y producir un nuevo diseo a partir de ellas. Ninguno ci estos cursos de accin es
satisfactorio. Con palabras de Fred Brooks:
El manual (e specific acin) debe describir no solo todas las cosas que el usuario ve, incluyendo las
interfaces, sino que debe contener aquello que el usuario no ve. Esta es la actividad del
implemenlador y aqu su libertad no puede ser restringida. El arquitecto (analista) debe estar
siempre preparado para mostrar una implementacin para cualquier seccin o aspecto que
describa, pero no debe intentar dictar la implementacin. [1.1]
Si el analista y el diseador son la misma persona, itijbujo del flujograma debe tomarse
como una accin de diseo, no de anlisis. Existe una ron tentacin hacia el bosquejo de un
diseo fsico del nuevo sistema antes de haber comprendido completamente todos los
requerimientos lgicos; ste es el significado que tiene la expresin prematuramente fsico.
Tambin es mucho ms difcil, una vez iniciado el diseo, considerar situaciones
alternativas. Los flujogramas para un sistema en lnea y para otro que lleva a cabo las mismas
funciones lgicas pero en lote, son muy diferentes. La similitud lgica fundamental es
imposible de ver. Para colmo de males, el smbolo de decisin del flujograma alienta al
creador a entrar en el detalle en las decisiones por ejemplo, qu pasa con las transacciones
invlidas? y el diagrama general se ha convertido, antes de ser bien conocido, en el
flujograma detallado de un programa. Necesitamos los detalles pero no en el estudio global.
1 analista necesita desesperadamente tener la posibilidad de ver un mapa del bosque. No
4
www.FreeLibros.org
Figura 1.1 Smbolos convencionales de diagramas de flujo (de la plantilla de diagramacin
BM X 20-8020).
es siempre verdad que el flujograma sirva de ayuda para modelar el sistema para los
usuarios. Si bien es cierto que algunos usuarios expertos pueden aprender a leer flujogramas,
para la mayora son jerigonza visual.
1.2.4 No poseemos una forma sistemtica para registrar las preferencias y
las soluciones de compromiso del usuario, especialmente en trminos
de acceso inmediato de los datos
Como se ha indicado, el analista necesita detectar las preferencias del usuario (a menudo
intuitivas) respecto de los diversos aspectos del nuevo sistema. Para algunos usuarios no
importa que los valores tengan el 100% de precisin mientras el informe est disponible sin
falta a las 09.00 horas, mientras que otros estn dispuestos a esperar, siempre y cuando los
valores que lleguen sean los correctos. Obviamente, podemos dejar contentos a todos pero
solo a un precio. Estos datos de las soluciones de compromiso de los usuarios son muy
importantes para el diseador cuando compara la relacin costo/eficiencia de varios diseos.
Pero, a menos que el analista tenga una herramienta para registrar preferencias explcitamen
te, la informacin se perder. Este es un tema particularmente dificultoso cuando los datos de
un archivo deben ser de acceso inmediato en diferentes formas, por ejemplo, en el clsico
problema de ventas donde cualquier vendedor suministra varios artculos y cualquier articulo
puede ser suministrado por varios vendedores. Si organizamos el archivo por vendedor,
podemos fcilmente dar una respuesta inmediata a la pregunta Qu artculos ha
suministrado el vendedor A? Pero nos resta la pregunta Quin suministra el artculo
123456? Para dar una respuesta inmediata a esta pregunta puede ser necesario construir un
ndice secundario o alguna otra tcnica de base de datos. Pero cun importante es esta
segunda pregunta? Es vital para la forma en que el usuario maneja su negocio? O es
solamente algo lindo, que se mencion al analista por un gerente al finalizar una entrevista
5 www.FreeLibros.org
y se puso dentro de las especificaciones sin mayor nlisis? n el Captulo 7 discutiremos las
herramientas para el registro y anlisis de las preferencias.
1.3 {CUANTO IMPORTAN TAS ESPECIFICACIONES FUNCIONALES?
Podemos utilizarlas herramientas de anlisis estructurado de sistemas descriptas en este
libro para preparar una especificacin funcional que
1. Sea bien, interpretada y cuente con el completo acuerdo de los usuarios,
2. Fije los requerimientos lgicos del sistema sin imponer una Implementacin fsica, y
3. Exprese las preferencias y las soluciones de compromiso.
Pero qu hacemos con ello? Qu es lo que nos va a proporcionar? Por qu no aceptamos
que el anlisis es un arte inexacto y que, dado que los usuarios van a cambiar sus puntos de
vista de todos modos, podemos trabajar con los mtodos de especificacin corrientes?
100 _ _ _ i i i i 1 i
Figura 1.2 Costo relativo de correccin de un error durante el desarrollo del sistema.
Barry Boehm [1.2] ha producido cierta evidencia manifiesta que muestra cmo el costo
de correccin de uta error crece fuera de toda proporcin cuanto ms tarde se detecta, en el
ciclo de vida del sistema desarrollado (ver Fig. 1.2).
En el grfico se puede observar el costo relativo de corregir un error ntese la escala
logartmica! dependiendo de la fase del desarrollo del sistema en que el error es detectado.
Asi un error que se advierte en la fase de requerimientos debido tal vez a que el usuario
examin nuestro ntodelo lgico grfico puede costar 0,2 unidades (digamos $ 200), y en
cambio, si el mismo error no es detectado hasta que el sistema entra en operacin, el costo
resulta mayor a 10 unidades ($ 10.000).' As, la construccin de un modelo lgico que
comunica claramente al usuario qu es lo que puede y no puede hacer el sistema, es un
Requeri
mientos
Disert Codifi- i Prueba efe Prueba de
cacin , desarrollo aceptacin
Fase en la cual se detecta el error
Operacin
6
www.FreeLibros.org
ejercicio crucialmente importante en funcin del costo de corregir los errores ms tarde.
Realizar los cambios en una hoja de papel es barato; realizar cambios en la codificacin es
muchas veces ms caro, y realizar cambios en un sistema funcionando es muchsimo ms
caro an. No es conveniente esperar a que el usuario vea lo que recibe antes de que sepa lo
que quiere.
BIBLIOGRAFIA
1.1 F.P. Brooks, The Mythica! Man-Month, Addison-Wesley, Reading, Mass., 1975.
1.2 B. Boehm, Software Engineering, IEEE Transactions on Computen, Vol. C-25, diciembre de
1976.
www.FreeLibros.org
2
CUALES SON LAS HERRAMIENTAS
Y COMO ENCAJAN ENTRE SI
Antes de examinar en detalle cada una de las herramientas del anlisis estructurado,
daremos una visin general de cada herramienta mostrando sus relaciones mutuas y viendo
cmo se utilizan en un caso de anlisis relativamente simple.
La Corporacin CBM (Computers Books by Mail - Libros de Computacin por Correo)
fiie adquirida recientemente por una corporacin "holding nacional y es actualmente una
divisin de ella. Establecida hace 12 aos, el negocio de la compaa fue actuar como
intermediario de libros recibiendo pedidos de las libreras sobre libros de computacin y
pidiendo los libros al editor con su correspondiente descuento para cumplimentar el ped do al
recibir los libros de los editores. Las facturas eran confeccionadas por un servicio de
computacin a partir de los formularios llenados por CBM; el negocio atenda normalmente
100 facturas diarias, cada una con un promedio de 4 ttulos de libro con un valor promedio por
factura de $ 50. La nueva gerencia planifica expandir considerablemente las operaciones,
mejorando los niveles de servicio mediante la conservacin en stock de los 100 libros de
pedido ms frecuente y la admisin de pedidos por parte de todos los profesionales (no
solamente libreros) mediante llamada telefnica sin cargo al nmero 800-372-6657 (800 -
DP BOOKS), asi como tambin continuar con los pedidos por correo como en el presente.
Todo esto crear problemas de verificacin de crditos, por supuesto, y plantear la
necesidad de algn tipo de sistema de control de inventario. Los empleados que. reciban los
pedidos telefnicos necesitarn un acceso rpido a un catlogo de libros para verificafautores
y ttulos y para poder estar en capacidad de asesorar a quienes consultan, sobre qu libros
estn disponibles con referencia a determinados temas.
El volumen de transacciones en el nuevo sistema depender, por supuesto, de la
aceptacin de este nuevo mtodo de ordenar libros, que est proyectado para un crecimiento a
1000 facturas diarias, o ms, sibiencon un promedio menor de libros porfactura (teniendo en
cuenta que las libreras tienden a pedir ms por vez, que los profesionales).
Un analista de sistemas ha sido asignado a la divisin recin adquirida con la
responsabilidad de investigar y especificar el nuevo sistema en representacin del Vicepresi
dente de Marketing. Cmo puede empezar a construir un modelo lgico del sistema
requerido sin caer en las conclusiones de tipo prematuramente fsico, como por ejemplo
qu deber automatizarse, qu deber ser manual, si deber el sistema automatizado ser en
lnea o en lote, si deber utilizarse el servicio de computacin o tener el propio computador,
etctera?
8
www.FreeLibros.org
2.1 PRIMERO, DIBUJAR UN DIAGRAMA LOGICO DE FLUJO DE DATOS
En lineas generales podemos decir que al igual que en el sistema actual, el nuevo
sistema tomar pedidos de libros, los verificar contra un archivo de libros en existencia,
verificar contra algn archivo para determinar si el crdito del cliente es correcto y producir
la orden para que el libro(s) sea despachado con su factura.
Podemos verlo en el diagrama lgico de flujo de datos (DFD; en ingls, data flow
diagram) de la Fig, 2,1, donde empleamos los cuatro smbolos que se indican en la Fig. 2.2.
DATOS DEL LIBRO
Pedidos
CUENTE
Procesar
DATOS DEL CUENTE
pedidos
Estado
Facturas d'el cr-
Figura 2.1 Diagrama lgico de flujo de datos.
Fuente o destino de las datos
Flecha
Flujo de los datos
r \
Rectngulo
redondeado
_____
Proceso que transforma flu
jos de datos
Rectngulo de ex Almacenamiento de los datos
Figura 2.2 Smbolos del DFD.
Estos smbolos y los conceptos que representan, se encuentran en el nivel lgico; un flqjo
de datos puede estar contenido fsicamente en una nota, una factura, una llamada telefnica,
de programa a programa, va enlace de datos por satlite en cualquier medio por el cual
los datos pasan de una entidad o proceso a otro. Un proceso puede ser fsicamente una oficina
repleta de empleados que calculan descuentos, un procedimiento catalogado en JCL
(lenguaje de control de trabajos, en ingls, job control language), o una combinacin de
actividades manuales y automatizadas. Un almacenamiento de datos puede ser un archivo
rotativo de taijetas, una microficha, un archivo, una tabla en ncleos, o un archivo en cinta o
www.FreeLibros.org
discomplendo los cuatro smbolos disponibles, es posible dibujar un grfico def sistema
tptoi preocupamos de cmo deber ser su implementacin.
Por supuesto, el sistema graficado en la Fig. 2.1 es muy general a tan alto nivel de
abstraccin que puede resultar bastante intil. Sin embargo podemos usar los cuatro
smbolos bsicos para trazar un mapa del bosque a cualquier nivel de detalle que
deseemos. Expandamos el proceso de pedidos para mostrar las funciones lgicas que
realiza el sistema actual. A los novatos podemos indicarles que los pedidos que ingresan
deben ser verificados para asegurarnos de que los detalles sean correctos (que el ttulo y el
autor se corresponden, por ejemplo). Una vez que se ha validado el pedido, necesitamos
despacharlo juntamente con los pedidos de otros libros del mismo editor, de manera que
podamos obtener el beneficio del descuento por cantidad.
La Fig. 2.3 muestra cmo ha quedado ahora el diagrama lgico de flujo de datos. Vemos
que a medida que cada pedido es verificado se lo coloca en algn almacenamiento de pedidos
pendientes hasta que (de acuerdo con cierta lgica que no necesitamos especificar todava) el
despacho de los pedidos pueda ser reunido en una orden masiva.
Hasta ahora todo va muy bien; pero qu pasa con el completamiento de los pedidos y,
como esperamos, con su pago? Cada editor remitir una nota de embarco con cada envo,
detallando su contenido; sta debe compararse con el pedido que le hemos colocado para
aseguramos de que se hayan recibido las cantidades y los ttulos correctamente. Dnde
encontramos los detalles de los pedidos que colocamos? Evidentemente debe existir otro
almacenamiento de datos, llamado tal vez pedidos a los editores, que pueda ser consultado.
Una vez que dispongamos de los libros correctos, podemos armar y despachar los pedidos a
nuestros clientes, en forma individual. La Fig. 2.4 muestra el sistema con estos agregados.
Obsrvese que no se ha mostrado el movimiento propio de los libros; para nuestro
propsito, los libros no son datos y por ello no se incluyen en el diagrama lgico de flujo de
datos. Discutiremos la relacin entre un diagrama lgico de fluio de datos y un diagrama de
fSUttio de materiales en el Captulo 3. Por ahora, nos interesan los tem, como las notas de"
embarco, las cuales son datos acerca de los libros.
Figura 2.3 Expansin dei DFD.
En la Fig. 2.4 hasta ahora nadie ha recibido ningn pago por nada. Necesitamos remitir
las facturas a nuestros clientes (hasta ahora lo hace el servicio, pero ste es un detalle fsico) y
atender el pago de nuestros clientes; como nada es gratis, deberemos a nuestro turno ser
facturados por los editores y pagarles. La Fig. 2,5 muestra el agregado de estas funciones
financieras con sus almacenamientos de datos asociados, conocidos comnmente como
cuentas a cobrar y cuentas a pagar.
10
www.FreeLibros.org
Figura 2,4 Expansin adicional de l a DFD.
Por razones de claridad no se indican las funciones lgicas para la creacin y
mantenimiento del'archivo de cliente, del archivo de libros y del archivo de editor y no
atendemos consultas. Estas funciones las trataremos en el prximo captulo.
Por supuesto que cada una de las casillas de proceso que se muestran resumen una
cantidad de detalles. Cada casilla de nroceso puede ser explotada en un nixeUaeaa03s
detallado del diagrama lgico de flujo de datos. La Fig. 2.6 muestra la explosin-de reunir
requerimientos a los editores.
Si se requiere, cada casilla correspondiente a los procesos componentes puede, a su vez,
ser descompuesta a un nivel inferior, a un tercer nivel de detalle. Como veremos en el Captulo
3, ello a menudo no es necesario. En el Captulo 3 trataremos en detalle las pautas para
dibujar este diagrama lgico de flujo de datos y las convenciones para efectuar las
explosiones.
2.1.1 Condiciones de error
Usted se habr dado cuenta de que no hemos considerado las condiciones de error; no
hemos especificado qu pasa con un pedido de un usuario que se encuentra fuera del lmite del
crdito o qu pasa con una factura de un editor correspondiente a un despacho que nunca
recibimos. Por supuesto que debemos considerar estas circunstancias, pero queda su
tratamiento para los diagramas de segundo nivel o inferiores, de manera que ello no
interfiera con el gran cuadro. Sin esta regla de simplificacin es muy fcil empantanarse
con el manejo de errores y excepciones, hundindose sin dejar rastros.
11
www.FreeLibros.org
Figura 2.5. DFD completo.
2.1.2 Implementaciones fsicas alternativas
Otro punto importante respecto a la Fig. 2.5 es que, dado que es un diagrama lgico de
flujo de datos, es muy fcil representarse mentalmente diversas implementaciones fsicas.
Como sabemos, en el sistema presente, confeccionar factura y aplicar pago a factura son
automatizadas por el servicio y el resto de las funciones son manuales. Ahora que tenemos un
mapa del bosque podemos ver diferentes soluciones alternativas dibujando en el sistema
lmites alrededor de diferentes procesos y almacenamientos de datos. En la Fig. 2.7 se
muestran dos de tales posibilidades.
Lmite 1. Automatizacin de la validacin de los pedidos, as como de la facturacin y de
12
www.FreeLibros.org
las cuentas a cobrar, al tiempo que dejamos en forma manual la acumulacin en lotes de los
pedidos y todas las funciones de compra. Dentro de esta regin automatizada podemos
representamos por lo menos dos soluciones fsicas.
Figura 2.6 Explosin de proceso en otro DFD.
Limite 1: En lote. Los pedidos pueden revisarse para su completamiento y perforacin.
Despus de validarlos contra el archivo de libros y el archivo de clientes, debern ser
agregados al archivo de pedidos pendientes, y debe imprimirse una confirmacin
impresa de la orden y producirse una salida impresa clasificada por ttulo dentro de editor.
Los despachos y los pagos debern ser perforados y utilizados como entrada de un
sistema convencional de cuentas a cobrar.
Lmite 1: En lnea. A medida que van llegando los pedidos debern ser introducidos por
una terminal CRT con capacidad para llamar a todos los libros por un autor
determinado, o por una palabra o una frase del ttulo y con una validacin en lnea contra
el archivo de clientes. Una vez ingresada satisfactoriamente la orden, deber imprimirse
una confirmacin en la impresora de la terminal para su control visual contra la orden,
actualizndose el archivo de pedidos pendientes.
Lmite 2. Automatizar la produccin de rdenes de compra y el desglose de los
despachos principales en rdenes individuales, as como la entrada de rdenes y las
cuentas a cobrar.
Lmite 2: En lote. Adems del sistema descripto para el Lmite 1, este sistema ms
amplio correr todas las noches a travs de la cinta de pedidos pendientes, extractando
aquellos ttulos cuyo total de pedidos exceda la cantidad econmica de pedido,
13
www.FreeLibros.org
clasificando por editor, imprimiendo rdenes de compra y actualizando el archivo de
rdenes de editores en trmite. Cuando se reciban los despachos, su contenido deber
perforarse y validarse contra el archivo de pedidos en trmite y luego correrse contra el
archivo de pedidos pendientes para confeccionar las notas de embarco por pedidos
individuales de los clientes.
Limite 2: Hn linea. Las funciones adicionales disponibles sern tas de controlar de
inmediato el contenido del despacho recibido de un editor y generar instrucciones para
desglosar en el acto dicho despacho en rdenes individuales.
Figura 2.7 Posibles limites de automatizacin.
14
www.FreeLibros.org
Como es de imaginar, resultan factibles varias familias de sistemas. Qu sistema tiene
la mejor relacin costo/beneficio depende de factores tales como volumea magnitud de la
orden masiva con descuento, valor asignado a la respuesta rpida a los clientes, etc. El punto
importante es que cualquiera sea la implemeiitacin fsica que se elija, el resto de las
funciones manuales puede ser fcilmente observable, y que tanto las funciones automatizadas
como las manuales podrn siempre ser incorporadas al mismo diagrama lgico de flujo de
datos.
2,1.3 La clase general del sistema
Deber quedar claro que la Fig. 2.7, con muy pocos cambios podr ser aplicada a una
empresa distribuidora de autopartes, alimento para ganado, o artculos hospitalarios. Los
profesionales de administracin de empresas las reconocern como un miembro de laclase de
operaciones de distribucin sin inventa rio, en otras palabras cualquier empresa que recibe
pedidos pequeos los agrupa en pedidos masivos a un gran vendedor al por mayoro fabricante
y luego fracciona a stos para abastecer a los clientes, sin mantener existencias para la
provisin en el acto desde los estantes.
En el Captulo 3 desarrollaremos el diagrama lgico de flujo de datos para el nuevo
sistema de CBM, que corresponde a un sistema de distribucin con inventario.
Se invita al lector a considerar otros sistemas lgicos de empresas diferentes. Es un
ejercicio muy til bosquejar un diagrama de flujo de datos para un sistema distinto y marcar
los lmites de automatizacin para cada una de las mple mentaciones que le son familiares.
2.2 A CONTINUACION, COLOCAR EL DETALLE EN UN DICCIONARIO DE DATOS
En los diagramas de flujos de datos de la seccin anterior hemos dado a los fliyos de
datos, almacenamientos de datos y procesos los nombres ms significativos y descriptivos
posibles, con la condicin de ser suficientemente cortos para caber en el diagrama. Tan pronto
como empezamos a observar con mayor detalle, por ejemplo, al tratar de responder a la
pregunta qu quiere usted significar exactamente con pedidos?, nos vemos introducidos
inmediatamente en un sinnmero de detalles, especificando posiblemente el diseo del
formulario de pedido, acumulando ejemplos, dibujando disposiciones de registros en tarjeta o
en cinta, etc. Lo que deseamos es mantenemos en el nivel lgico, identificar cada uno de los
elementos de datos que se encuentran presentes en un flujo de datos, darles nombres
significativos, definir cada uno de ellos y organiza ros de manera de localizar fcilmente dicha
definicin.
Qu queremos significar con pedidos^. Como minimo la orden de pedido para un libro
deber tener cierta identificacin de la orden, el nombre y direccin del cliente y los detalles
de un libro, por lo menos, (y por lo general, ms). Podremos entonces comenzar a dar nombres
significativos y mostrar el siguiente desglose,
PEDIDO
PEDIDO-IDENTIFICACION
CLIENTE-DETALLES
LIBRO-DETALLES
y podemos expandir esto ms an con notas:
PEDIDO
PEDIDO-IDENTIFICACION
PEDIDO-FECHA
15
www.FreeLibros.org
CLIENTE-PEDIDO-NUMERO..........Normalmente presente
CLIENTE-DETALLES
EMPRESA-NOMBRE
PERSONA-AUTORIZANTE..................... Opcional
NOMBRE.....................Puede ser slo la inicial
APELLIDO
TELEFONO
CODIGO-DE-AREA
CENTRAL
NUMERO
EXTENSION..................... Opcional
DESPACHARA-DIRECCION
CALLE
CIUDAD-LOCALIDAD
CODIGO-POSTAL
FACTURAR-A-DIRECCION Si no se indica, igual a DESPACHAR-A-DIRECCION
CALLE
CIUDAD-LOCALIDAD
CODIGO-POSTAL
LIBRO-DETALLES.. .Una o ms iteraciones de este grupo de elementos de datos
AUTOR-NOMBRE.. .Una o ms iteraciones de este elemento de datos
TITULO
ISBN.. . .International Standard Book Numben Nmero internacional asignado al libro (opcional)
LOCN... .Librery of Congress Numben Nmero de la Biblioteca del Congreso de EE.UU. (opcional)
EDITOR-NOMBRE..................... Opcional
CANTIDAD
Obsrvese que esta estructura de datos de una orden de pedido no nos indica nada de su
disposicin fsica, tamao de los campos, si el campo es decimal empaquetado, caractersti
cas de la impresin, etc. Al mismo tiempo que omiten estos detalles fsicos es, en cambio,
preciso que el analista y el usuario efecten las revisiones para evitar errores y omisiones. Por
ejemplo, el cliente puede decir Si se da el dato FACTURAR-A-DIRECCION, se debe
registrar el nombre de la persona a la cual se debe enviar la factura y el analista puede
agregar otro elemento de datos.
Cada uno de los elementos de datos referido a la estructura de datos de PEDIDO deber
definirse en forma separada. Por ejemplo, qu queremos significar con ISBN, el nmero
internacional asignado al libro? Debemos estar en condiciones de localizar rpidamente una
explicacin de que el ISBN es un nmero de diez dgitos, dividido en cuatro grupos. El primer
dgito o par de dgitos representa el idioma, el siguiente grupo representa al editor, el tercero al
libro en particular y el ltimo dgito es un dgito verificador. Por ejemplo:
Ingls^ 0-13-881474-0 ______^ Dgito verificador
Prentice-Hall Identificacin del libro
Este es el ISBN del libro Systems A nalysisandDesign Using Network Techniques( Anlisis
y Diseo de Sistemas utilizando tcnicas de redes) de Gary E. Whitehouse, editado por
Prentice-Hall.
En el Captulo 4 examinaremos una tcnica para documentar las definiciones de los
elementos de datos. Por el momento observemos que si tenemos una definicin y la
explicacin de cada flujo de datos, del contenido de cada almacenamiento de datos, y de cada
elemento de datos que los componen, de los cuales y si podemos disponer estas definiciones
en orden alfabtico para referimos a ellos fcilmente, podremos tener un diccionario de datos
del sistema. Si alguien desea conocer el significado de A VISO-DE-EMBARCO, deber
16 www.FreeLibros.org
buscar AVI SO-DE-EMBARCO en la letra A del diccionario de datos donde encontrar su
estructura de datos. Si luego quiere saber qu significa METODO-DE-TRANSPORTE
(uno de los elementos de datos de AVISO-DE-EMBARCO) deber buscar en la letra M
donde encontrar su definicin y explicacin.
Las tcnicas, implementaciones y ventajas de los diccionarios de datos se discuten
extensamente en el Captulo 4. El beneficio ms importante para los analistas es que se pueden
describir flujos de datos y almacenamiento de datos con un solo nombre significativo,
sabiendo que todos los detalles correspondientes al nombre estarn rpidamente disponibles.
2.3 DEFINIR LA LOGICA DE LOS PROCESOS
Definido cada elemento de datos del sistema, podemos comenzar a explorar qu est
pasando dentro de los procesos. Por ejemplo, qu queremos significar en la Fig. 2.5 con
aplicar pago a la factura? Hemos visto que cada uno de estos procesos puede ser expandido
o explotado en procesos de nivel inferior. Supongamos que uno de tales procesos de nivel
inferior, verificar descuento implica controlar que se ha efectuado correctamente el
descuento. Si el analista pregunta Cul es la poltica de descuentos? se le podr mostrar un
memorndum, o una pgina del manual de procedimientos, donde dice ms o menos lo
siguiente:
El descuento comercial (a libreros establecidos al gremio es del 20%. Para clientes
particulares y bibliotecarios se concede el 5% de descuento por 6 o ms libros, 10% para pedidos
de 20 o ms libros y 15% para pedidos de 50 o ms. Los pedidos comerciales por 20 o ms libros
reciben el 10% de descuento sobre el descuento comercial.
Este es un ejemplo muy simple de lo que llamaremos lgica externa, externa en el
sentido de que tiene relacin con la poltica empresaria, procedimientos o reglas administrati
vas en oposicin a lgica interna, la cual especifica la forma en que la computadora la va a
implementar.
Aunque este ejemplo es simple, la lgica relativa a polticas puede rpidamente volverse
confusa, en especial considerando que las excepciones y cambios de polticas se plantean
escribiendo ms memorndum, en lugar de corregir los documentos de la poltica original. El
analista necesita herramientas para graficar la estructura de la lgica y expresar las polticas
en una forma global y sin ambigedades.
La primera de estas herramientas es el rbol de decisin, que se muestra en la Fig. 2.8.
Las ramas del rbol corresponden a cada una de las posibilidades lgicas; es evidente que la
forma de obtener la cantidad del descuento depende de la combinacin de las posibilidades.
Como herramienta para bosquejar una estructura lgica y para permitir al usuario confirmar
que la lgica de la poltica expresada es correcta, el rbol de decisin es excelente. Es posible
indicar la combinacin de circunstancias que conduce a cada accin en forma clara y directa.
Si bien el rbol de decisin muestra muy claramente el esqueleto de la estructura de la
decisin, no nos lleva fcilmente a la incorporacin de instrucciones y clculos. Si
necesitamos escribir la lgica como un conjunto de instrucciones paso a paso, incluyendo la
estructura de decisin y los clculos inmediatos o acciones (posiblemente porque deseamos
que un empleado sea capaz de seguirlas) quiz prefiramos utilizar una forma lgica estricta
del idioma corriente, como se muestra en la Fig. 2.9. Este tipo de idioma corriente se ha
denominado lenguaje estructurado, porque utiliza construcciones lgicas similares a las de la
programacin estructurada. Las instrucciones para llevar a cabo las acciones que no incluyen
decisin se escriben en forma de frases imperativas (Sumar el nmero total de volme
nes...). Cuando se deba tomar una decisin, se expresar como una combinacin de SI,
ENTONCES, SI-NO, LUEGO, CON SI y SI-NO alineados apropiadamente para mostrar
la estructura de decisin.
17 www.FreeLibros.org
Tipo de cliente
Magnitud del pedido
20 o mis
~ menos de 20------
Descuerno
20%+ 10%
Comercio' 20%
15%
1 0 %
5%
nada
Particu
o
50 o ms
-20-49 -
bibliotecario
6-19
menos de 6
Figura 2.8 Arbol de decisin.
Podemos hacer el lenguaje estructurado (y el rbol de decisin) ms preciso y compacto,
utilizando, cuando sea pertinente, trminos que se han definido en el diccionario de datos. Por
ejemplo, podemos definir PEDIDO-MAGNITUD como un elemento de datos que puede
tonar hasta cuatro valores:
PEQUEA: 5 o menos volmenes
MEDIANA; 6 a 19 volmenes
GRANDE: 20 a 49 volmenes
MASIVA: 50 o ms volmenes
La primer parte de la Fig. 2.9 podr leerse entonces
Poltica de descuentos
Sumar la cantidad total de volmenes (Jet pedido (en la columna cantidad)
SI el pedido es de un cliente comercial
y-Si el pedido es por 20 o ms volmenes
ENTONCES: el descuento es del 30%
SI-NO (el pedido es de menos de 20 volmenes)
LUEGO: el descuento es del 20%
SI-NO (el pedido es de un cliente particular o bibliotecario)
SI el pedido es por 50 o ms volmenes
el descuento es dei 15%
SI-NO SI el pedido es por 20 a 49 volmenes
el descuento es del 10%
SI-NO SI el pedido es por 6 a 19 volmenes
el descuento es del 5%
SJ-NO (el pedido es por meros de 6 volmenes)
LUEGO: no se har descuento
SI el pedido es de un comerciante
y-SI PEDIDO-MAGNITUD es GRANDE o MASIVA
ENTONCES: descuento es 30%
SI-NO (PEDIDO-MAGNITUD es MEDIANA o PEQUEA)
LUEGO:....................
Las convenciones y notaciones de los rboles de decisin y del lenguaje estructurado,
junto con otras tcnicas de representacin de polticas y procedimientos, se encuentran
detalladas en el Capitulo 5.
Figura 2.9 Lenguaje estructurado.
18
www.FreeLibros.org
2.4 DEFINIR LOS ALMACENAMIENTOS DE DATOS: CONTENIDOS Y ACCESO
INMEDIATO
Una vez armado el diagrama de flujo de datos, identificamos los lugares donde deben
alegarse los datos entre una transaccin y la siguiente o bien almacenarse permanentemente
debido a que describen algn aspecto del mundo exterior al sistema (por ejemplo, la direccin
del cliente). El analista debe obviamente especificar los elementos de datos que se deben
oonservar en cada almacenamiento de datos en forma similar a las especificaciones de cada
flujo de datos de la Seccin 2.2. Claro est, como los datos solo pueden llegar a un
almacenamiento de datos a travs de algn flujo de datos y no pueden salir si antes no fueron
colocados, el contenido de un almacenamiento de datos puede ser obtenido a partir de las
especificaciones de los flujos de datos entrantes y salientes, como podr verse en el Captulo
6, El contenido lgico de cada almacenamiento de datos se encuentra en el diccionario de
datos bajo el nombre del almacenamiento de datos. Tal como ocurre con el flujo de datos, los
elementos individuales de datos del almacenamiento de datos se definen en otra parte del
diccionario de datos. Por ejemplo, en la Fig. 2.5 identificamos un almacenamiento de datos
denominado LIBROS, el cual es utilizado en la verificacin del pedido, entrando con un titulo
o autor y recibiendo detalles del libro, Qu queremos significar con detalles del librdl Si
buscamos LIBRO-DETALLES en el diccionario de datos, encontraremos lo siguiente*.
LIBRO-DETALLES
AUTOR-NOMBRE.................... Una o ms iteraciones
ORGANIZACION-ASOCIACION Universidad, corporacin
TITULO
ISBN.....................Nmero Internacional asignado al libro (opcional)
LOCN.....................Nmero de la Biblioteca del Congreso de EE.UU (opcional)
EDITOR-NOMBRE Opcional; ver archivo de abreviaturas
PRECIO-ENCUADERNADO
PRECIO-RUSTICA
PUBLICACION-FECHA........ Puede haber iteraciones si existen ediciones
Evidentemente, si todos estos elementos de datos se encuentran presentes en el flujo de
datos, tambin debern estarlo en el almacenamiento de datos. El analista puede tomar esto
como punto de partida y a medida que desarrolla el flujo del sistema puede preguntarse
Existir cualquier otro elemento de datos que describa libros y que debera estar
almacenado aqu? Qu pasa, por ejemplo, con PESO-PARA-CORRESPONDENCIA?
Si el peso de un pedido debe ser calculado a partir del peso de los libros componentes, el
franqueo deber calcularse en base a una tabla de tarifas postales e ingres ado como parte de la
factura. Deber almacenarse este elemento de datos? Si es as, cmo debe (a nivel lgico)
obtenerse el valor del elemento de datos para cada nuevo libro?
Una vez que se ha establecido el contenido de cada almacenamiento de datos propuesto a
nivel lgico en el diagrama de flujo de datos, el analista tiene que resolver dos problemas:
1. Son estos almacenamientos lgicos de datos los ms simples posibles? Pueden
combinarse? Deben combinarse?
2. Qu accesos inmediatos necesitaremos para el almacenamiento de datos, y qu valor
implica cada tipo de acceso?
2.4,1 Son los almacenamientos lgicos de datos los ms simples posibles?
Una vez identificado el contenido de cada almacenamiento de datos, los mismos deben
compararse para ver s existen similitudes o superposiciones. Supongamos que posteriormen
te identificamos un almacenamiento de datos de inventario: Qu deber contener? Los
19
www.FreeLibros.org
elementos de datos debern incluir el ttulo del libro, probablemente l autor(es), y el ISBN
como nica identificacin, y tambin elementos que describan
Cantidad-disponible
Cantidad-ordenada
Pedidos-cumplidos-en-los-ltimos-30-das
Pedidos-pendientes-durante-los-ltimos-30-das
Fecha-ltima-orden-colocada
Tiempo-promedio-de-entrega
y cualquier otra informacin necesaria para la gestin del inventario. Pero este almacena
miento de datos contiene informacin sobredada libro, exactamente igual que el almacena
miento de datos LIBROS. Por qu ilo combinamos los dos y mantenemos la informacin de
inventario en LIBROS? De acuerdo con la implementacin elegida existirn argumentos a
favor de combinar estos archivos y argumentos a favor de mantenerlos separados, lo cual ser
discutido en el Captulo 9. Por ejemplo, si el analista y el diseador deciden que el
almacenamiento de datos LIBROS deber ser un catlogo de libros impreso con secciones
organizadas por autor, por ttulo y por materia, se ve claramente que es inapropiado incluir en
el mismo datos de inventario que cambian rpidamente. Por otra parte, si LIBROS llega a ser
una base de datos en lnea accesible a los empleados que toman pedidos telefnicos, puede
tener sentido disponer de un inventario actualizado e informacin de fechas de entrega dentro
del archivo LIBROS, de modo que puedan ser recuperados al mismo tiempo que los datos
necesarios para verificar el pedido.
Independientemente de consideraciones fsicas como las vistas, es importante en las
primeras etapas de anlisis que el analista sea capaz de definir los detalles del contenido de
cada almacenamiento de datos, est seguro que la definicin es completa, y sea capaz de
identificar similitudes y diferencias existentes en los diferentes almacenamientos de datos del
sistema. Es muy til aplicar en este caso el enfoque relacional expresar un archivo
complejo en forma de varias relaciones normalizadas simples que se discutir en detalle en
el Captulo 6.
2.4.2 Qu accesos inmediatos se necesitarn?
Ms difcil y aun ms critica que la tarea de especificar contenidos, es la tarea de decidir
qu accesos inmediatos a cada almacenamiento de datos necesitar el usuario. Por ejemplo,
supongamos que hemos decidido tener el archivo de LIBROS disponible en pantalla, en una
terminal en lnea. El elemento de datos que identifica unvocamente cada libro es el ISBN.
Pero si lo hacemos clave principal del archivo y solo tenemos acceso inmediato por esta clave,
ello significa que tendremos que conocer el ISBN de un libro para poder desplegar en la
pantalla su ttulo, cdigo del tema, editor, precio, etc. Ello es comparable a tener que conocer
el nmero de la pliza de seguro de una persona para poder localizar la pliza o tener que
conocer el nmero de parte de un artculo para poder saber su precio.
Mucho ms frecuentemente queremos tener acceso inmediato por el nombre de algo, y
esto significa que el analista deber especificar accesos mltiples del archivo. En este caso, el
usuario puede decidir en forma estricta que desea desplegar los detalles del libro en su
pantalla como resultado de digitar, o bien el nombre de un autor (en cuyo caso podran
aparecer varios libros), o bien un encabezamiento en base al tema, (en cuyo caso se
encontrar seguramente con varias pantallas completas), o bien el ttulo real, o el ISBN.
Podr especificar posteriormente que desea tener la respuesta de inmediato, digamos lo
suficientemente rpido como para poder contestar una consulta telefnica. Por acceso
inmediato queremos significar ms rpido que lo que insumira leer de punta a punta el
archivo o clasificarlo Obviamente el significado exacto de esto ser variable, dependiendo
del tamao del archivo y de la potencia de la computadora; en una 370/168 ser posible leer
20
www.FreeLibros.org
un archivo de 100.000 caracteres en menos de un segundo, y en cambio en una mquina ms
lenta algunas bases de datos grandes de clientes tomarn todo un fn de semana para ser
procesados de punta a punta.
Es importante conocer el significado de inmediatamente en cada contexto, debido a que
si el usuario quiere saber la respuesta de una consulta y puede esperar mientras pasamos o
clasificamos el archivo completo, el diseador no tiene necesidad de construir ninguna
estructura en el archivo. Si el usuario insiste en una respuesta inmediata, tan rpida que no d
tiempo a pasar o clasificar el archivo, el diseador deber crear algn tipo de ndice o alguna
estructura y proveer algn software que le permita al usuario tener acceso al archivo con
argumento de bsqueda que desea. Por ejemplo, el diseador podra crear un archivo
subsidiario por autor, conteniendo por cada autor el ISBN de todos los libros que ha escrito.
Conociendo el ISBN, el software de recuperacin deber utilizarlo como acceso al archivo
principal y desplegar en la pantalla del usuario todos los libros escritos por el autor cuyo
nombre fue tecleado.
Hay diversas tcnicas para lograr accesos mltiples, y las mismas se vern brevemente
en el Captulo 7. No interesa la forma de realizarlo, el acceso inmediato cuesta dinero en
funcin del mayor tiempo necesario para su desarrollo y mantenimiento, de la necesidad de
mayor software para manej ar los accesos y de la utilizacin de ms espacio en disco. Si bien es
difcil obtener costos exactos, como regla aproximada se puede esperar que un acceso
inmediato cueste hasta cinco veces ms que la obtencin de la misma informacin mediante
clasificacin del archivo en los momentos en que no se encuentra en uso.
En consecuencia, es muy importante para el analista establecer exactamente qu accesos
se requiere que sean inmediatos y, adems, cules de esos accesos inmediatos son los ms
importantes para el negocio. Para el diseo de los accesos de la base de datos, el analista y el
diseador realizarn una serie de iteraciones: primero, tratando de satisfacer todo aquello que
fue solicitado por los usuarios y luego, calculando el costo del sistema y, si resulta mayor que
el presupuesto, suprimiendo las facilidades ms caras o difciles, realizando un nuevo diseo
tentativo, etc. En esta ltima proposicin hacemos un llamado de atencin a una de las cosas
que llevan a error, suprimiendo las facilidades ms caras o difciles. Si fuera muy caro
proveer todas las facilidades solicitadas, la primera economa deber ser la supresin de la
facilidad de menor valor para el usuario, no la ms cara o difcil. Pero, cmo podr hacerse
si el analista no conoce la importancia relativa de los diferentes accesos?
En el simple caso del archivo LIBROS, se supone que el pblico o bien conoce al autor
pero tiene una vaga idea del ttulo, o bien conoce el tema pero tiene una vaga idea tanto del
ttulo como del autor. La capacidad de localizar un libro por su ISBN (que es fcil de proveer
dado que el ISBN es la clave primaria) es de muy poco valor. Ubicar un libro solamente por su
ttulo es til, pero de relativo valor. Podemos crear una imagen de estos accesos inmediatos en
un diagrama de datos de acceso inmediato (DIAD, en ingls, data inmediate-access
diagram); ver la Fig. 2.10. El diagrama indica que existe un archivo que describe libros con un
ISBN como clave primaria y elementos de datos adicionales que describen los atributos de
cada libro, tales como autor, precio, etc. El hecho de sealar al ISBN como la clave primaria
(dentro de un rectngulo de lneas llenas), implica que la pregunta Dado un ISBN,
mustreme el autor(es) y el ttulo puede ser contestada inmediatamente.
Una pregunta tal como Dado un editor, mustreme todas sus publicaciones no puede
ser contestada inmediatamente con los accesos definidos en el DIAD anterior. Sin embargo,
el editor debe aparecer en cada registro de LIBROS, de manera que siempre es posible
clasificar el archivo por el campo de editor o escribir un programa que sea capaz de leertodo el
archivo, extrayendo los registros de libros para un editor determinado. (Es cierto que un grupo
del ISBN es el cdigo del editor, pero el que consulta no siempre conoce ese cdigo.)
Por otra parte, el DIAD muestra que las preguntas Dado el nombre de un autor,
mustreme los libros escritos por l y Dado un ttulo, mustreme todos los libros con ese
ttulo "pueden ser respondidas inmediatamente, aun cuando autor y ttulo sean atributos
de LIBROS y campos dentro de los registros de LIBROS. El hecho de indicar rectngulos
21 www.FreeLibros.org
l TITULO ~l
i PRECIO 1
{......... j
L !PiT21 J
Figura 2,10 Diagrama de datos de acceso inmediato.
separados en el DIAD con flechas que apuntan a LIBROS, indica que se tendr acceso
inmediato al archivo mediante ndices de autor y ttulo o mediante algn mecanismo de
bsqueda rpida.
El acceso tema es completamente claro; TEMA no es un atributo de LIBROS, es un
ndice totalmente separado dentro del archivo y por haberlo incluido en el diagrama de acceso
inmediato estamos indicndole al diseador de la base de datos que de alguna manera esta
facilidad deber ser incluida en el diseo.
Podemos utilizar el diagrama de accesos inmediatos para registrar la informacin que
necesitamos sobre las preferencias de los usuarios y sobre el valor de cada acceso para la
empresa. La Fig. 2.11 muestra los resultados de una consulta realizada a tres gerentes sobre
el valor relativo que tienen los diferentes accesos para ellos y su personal. La pregunta
formulada fue Considerando que usted puede tener la respuesta de esta pregunta maana por
la maana al costo de $ 1, cunto pagara por tener la respuesta inmediatamente (mientras el
cliente est al telfono)? Las preferencias de los tres gerentes se han codificado en la Fig.
2.11 como MI, M2, y M3.
Si usted fuera el analista que est en consulta con el diseador, y recibe la informacin
.. de que solamente dos de los tres accesos son econmicamente posibles, cul eliminara?
Las convenciones para la representacin de un DIAD y las tcnicas de entrevistas se
encuentran ms detalladas en el Captulo 7. Tambin deseamos proveerle al diseador la
informacin sobre el volumen y la frecuencia de estos accesos inmediatos. Adems, debemos
reunir informacin de seguridad (por ejemplo, quin est autorizado a tener acceso a la
historia de los salarios del personal?)
TEMA
HT
M2
M3
AUTOR
$5
S2
S10
S25
$50
$100
LIBROS
$10
$20
TITULO
No malgaste mi (expresin
eliminada) tiempo".
Figura 2.11 Valores relativos de varios accesos.
El lector puede encontrar de utilidad dibujar un DIAD para un sistema de acceso
inmediato que le sea familiar, luego dibujar el diagrama que podra, en su opinin, satisfacer
todos los requerimientos de todos los usuarios y a continuacin comparar ambos.
22
www.FreeLibros.org
2.5 UTILIZACION DE LAS HERRAMIENTAS PARA CREAR UNA ESPECIFICACION
FUNCIONAL
Para resumir este captulo de visin global diremos que el diagrama lgico de flujo de
datos muestra las fuentes y destinos de los datos (y en consecuencia los lmites del sistema),
identifica y asigna nombre a las funciones lgicas, identifica y da nombre a los grupos de
elementos de datos que conectan una funcin con otra, e identifica los almacenamientos de
datos a los cuales tienen acceso. Se analiza cada flujo de datos, y sus estructuras y las
definiciones de sus elementos de datos componentes se almacenan en el diccionario de datos
Cada funcin lgica puede ser fraccionada en diagramas de flujo de datos ms detallados.
Cuando ya no resulta de utilidad subdividir las funciones lgicas, se expresa su lgica externa
empresaria utilizando rboles de decisin, lenguaje estructurado, u otras herramientas. Los
contenidos de cada almacenamiento de datos son analizados y almacenados en el diccionario
de datos. El valor relativo, para los usuarios, de los diferentes caminos de acceso inmediato a
los datos en los almacenamientos de datos, es analizado y expresado en un diagrama de datos
de acceso inmediato. La Fig. 2.12 muestra esas relaciones.
Estos documentos configuran una descripcin completa del sistema, ya sea el sistema
existente en una empresa o el nuevo sistema que se va a construir. Cuando se ha preparado
el paquete completo para el nuevo sistema tenemos una especificacin funcional lgica, una
presentacin detallada de lo que har el sistema, la cual es, en lo posible, independiente de las
consideraciones fsicas de cmo ser implementado. Este tipo de especificacin funcional
brindar al diseador una idea clara del resultado final que debe alcanzar y una evidencia
escrita de las preferencias del usuario para los casos en que haya que adoptar soluciones de
compromiso. En este punto el analista transfiere la responsabilidad primaria del trabajo
tcnico a un diseador, y contina con los otros aspectos del proyecto (tales como planificar
la prueba y aceptacin del sistema). Si el analista y el diseador son una misma persona, sta
ahora cambia de sombrero y mira la especificacin funcional lgica con los ojos de un
diseador, confiado en el conocimiento de que la misma representa una base firme de
requerimientos a partir de los cuales debe disear el sistema.
A menudo, como ya lo hemos indicado, el analista y el diseador deben realizar diversas
iteraciones de ajuste de diseos fsicos de prueba, trabajando sobre sus implicancias tcnicas
y econmicas, cambiando algunos aspectos, y volviendo a probar. Discutiremos este proceso
de diseo tentativo y la intervencin del usuario en el Capitulo 8.
Ejercicios y puntos de discusin
1. Liste tantos distintos mtodos fsicos para implementr un flujo de datos determinado como
le sea posible.
2. Liste tantos distintos mtodos fsicos para crear un almacenamiento de datos, como le sea
posible.
3. Explote cada uno de los procesos expuestos en la Fig. 2.5 al mismo nivel de detalle de la
Fig. 2.6. Incluya cualquier condicin de error y excepcin que le parezca posible.
4. Adapte el diagrama de flujo de la Fig. 2.5 para representar la Compaa Amiga de
Alimentos, que toma pedidos de los agricultores para alimento de ganado y cerdos, coloca
pedidos masivos en fbricas y luego los fracciona para su entrega a los agricultores en
forma individual.
5. Cuntos tipos de empresas diferentes desde el punto de vista lgico (tales como
distribuidoras sin inventario, distribuidoras con inventario, fabricantes a pedido, fabrican
tes con inventario) puede definir?
6. Elija una declaracin de poltica compleja y dibuje un rbol de decisin para indicar su
estructura lgica.
www.FreeLibros.org
Diagrama de acceso
inmediato (Capitulo 7)
Diccionario de datos
(Capitulo 4)
Herramientas lgicas
(Captulo 5)
Figura 2.12 Componentes de un modelo lgico.
24
www.FreeLibros.org
7. Cul es el mayor archivo legible por mquina que conoce personalmente?
Cunto tarda
(a) para buscar?
(b) para clasificar?
8. Cul es, segn su punto de vista, la diferencia entre anlisis y diseo? Los analistas que
usted conoce, hacen solamente anlisis?
25
www.FreeLibros.org
3
DIBUJO DE LOS FLUJOGRAMAS DE DATOS
'l a idea de un grfico para representar el flujo de datos a travs de un sistema, no es
nueva; Martin y Estra [3,1 ] propusieron un grafo de programa en 1967, donde los flujos de
datos se representaban mediante flechas y las transformaciones, con crculos. En el enfoque
del flujo de datos se ha utilizado una notacin similar al diseo del programa,, que forma parte
de I disciplina de diseo estructurado 3.2]. Whitehouse (3,31 describe una notacin grfica
de flujo similar para modelizar sistemas matemticos. Ross [3.4] ha descripto un enfoque
grfico muy general para el anlisis de sistemas, el cual comprende el flujo de datos como uno
dess aspectos. Lo que es nuevo, es el reconocimiento de que el diagrama de flujo de datos en
el nivel lgico e's la herramienta clave para comprender y trabajar con un sistema de cualquier
complejidad, junto con el refinamiento de la notacin para su uso en el anlisis.
Como vimos en el Capitulo 2, en el anfisis necesitamos reconocer entidades externas y
almacenamientos de datos, asi como tambin flujos de datos y transformaciones o procesos.
Para poder representar completamente nuestro sistema lgico, necesitaremos agregar
smbolos al grfico simple de programa. Tambin, como necesitamos describir nuestras
transformaciones o procesos claramente y es difcil escribir claramente dentro de na circulo,
adoptaremos un retngalo con ngulos redondeados como smbolo de proceso.
%
3.1 CONVENCIONES SOBRE SIMBOLOS
Vamos a examinar en detalle las convenciones de smbolos.
3,1.1 Entidad externa
l a s entidades externas son generalmente clases lgicas de cosas o de personas, las
cuales representan una fuente o destino de transacciones, por ejemplo, clientes, empleados,
a
26
www.FreeLibros.org
aviones, unidades tcticas, proveedores, contribuyentes, tenedores de plizas. Tambin
pueden ser una fuente o destino es pee fico, por ejemplo, Departamento de C antabilidad, DGI,
Oficina del Presidente, depsito. Como el sistema que estamos considerando acepta datos de
otro sistema o bien se los provee, este otro sistema es una entidad externa.
Una entidad externa puede simbolizarse con un cuadrado de lineas llenas, con los lados
superior e izquierdo de doble ancho para hacer resaltar el smbolo del resto del diagrama. La
entidad puede identificarse con una letra minscula en el ngulo superior izquierdo, como
referencia.
Para evitar el cruzamiento de tas lineas de flujo de datos, la misma entidad se puede
dibujar mas de una vez en el mismo diagrama; las dos (o ms) casillas por entidad pueden
identificarse con una linea inclinada en el ngulo inferior derecho, como se observa en la Fig.
3.1.
Cuando otra entidad deba ser duplicada, se dibujar con dos lineas en el ngulo inferior
derecho, y as sucesivamente; ver Fig. 3.2.
Mediante la designacin de alguna cosa o algn sistema como una entidad externa,
estamos estableciendo implcitamente que se encuentra fuera de los limites del sistema que
estamos considerando.
A medida que avancemos en el anlisis y aprendamos ms sobre los objetivos del
usuario, tomaremos algunas entidades extemas y las introduciremos en nuestro diagrama de
flujo de datos del sistema, o, por el contrario, dejaremos de considerar alguna parte de las
funciones de nuestro sistema designndola como una entidad extema con datos que fluyan
desde y hacia ella.
b
1
PROVEEDORES
a
CUENTES
CUENTES
/ /
Flgu ra 3.1 Smbolo de duplicacin para entidades fxtemas.
a
CLIENTES
/
Figura 3.2 Duplicacin mltiple para entidades extemas.
3.1.2 Flujo de datos
El flujo de datos se simboliza mediante una flecha, preferentemente horizontal y/o
vertical, con la punta indicando la direccin del flujo. Para mayor claridad, y especialmente
en los primeros borradores del diagrama se utilizar una flecha con doble punta en lugar de
dos flechas, cuando los flujos de datos estn apareados. Ver Fig. 3.3.
27
www.FreeLibros.org
Cada flujo de datos se asemeja a una tubera por donde se envan paquetes de datos. Se
puede hacer referencia a la tubera del flujo de datos dando los procesos, entidades o
almacenamiento de datos en su punta y cola, pero cada flujo de datos deber tener a lo largo
una descripcin escrita de su contenido. La descripcin deber elegirse de manera que sea lo
ms til posible a los usuarios que deseen revisar el diagrama de flujo de datos (consistente
con el nivel de una descripcin lgica). En las primeras versiones, la descripcin del flujo de
datos se escribir en el diagrama con letras maysculas y minsculas. Ver Fig. 3.4.
En una etapa posterior del anlisis, cuando han sido definidos los contenidos del
diccionario de datos, la descripcin puede cambiarse por letras maysculas nicamente, para
indicar que se ha ingresado en el diccionario de datos. Encontramos frecuentemente que se
trasladan varios diferentes paquetes de datos a lo largo del mismo flujo de datos. Por
ejemplo, si observamos en el diccionario de datos en VENTAS-INFORMES, encontrare
mos el listado de sus componentes como:
VENTAS-INFORMES-POR-DIA
VENTAS-TENDENCIA-ANALISIS
VENDEDOR-RENDIMIENTO-ANALISIS
VENTAS-POR-PRODUCTO-ANALISIS
A su vez, cada uno de estos componentes se describe en el diccionario de datos; cada uno
contendr alguna disposicin diferente de elementos de datos.
Figura 3.3 Flujos de datos apareados.
Referencia del flujo de datos: 29-c
Descripcin del flujo de datos: Informes de ventas
Figura 3.4 Descripcin de flujo de datos.
Particularmente cuando se dibuja un flujograma de datos, es aceptable no colocar la
descripcin si ella resulta evidente para quien la va a revisar, pero el creador del diagrama
deber estar en condiciones, en cualquier momento, de suministrar la descripcin de todos los
tem. La Fig. 3.5 nos muestra un flujo de datos que no necesita descripcin.
En algunas ocasiones es difcil encontrar una descripcin que caracterice adecuadamen
f 29 ^ c
Analizar
Informes de ventas
GERENCIA
ventas
V J
28
www.FreeLibros.org
te el contenido de un flujo de datos. Por ejemplo, los clientes pueden enviar pedidos, pagos,
devolucin de mercadera deteriorada, consultas, reclamos, etc. Es muy pesado dibujar el
flujo de datos como se muestra en la Fig. 3.6. Hay dos formas de resolver este tipo de
situacin. Si el hecho lgico ms importante es que solo existe un nico flujo de datos (tal vez
hacia una oficina de ventas) y la funcin encaminar transacciones es muy importante,
entonces la solucin podra ser agrupar el contenido bajo un trmino lo suficientemente vago,
tal como transacciones de los clientes o informes gerenciales. El contenido de este flujo
de datos se puede hallar tanto en el diccionario de datos como por medio de un examen de la
salida de la funcin de encaminamiento. La Fig. 3.7 muestra un ejemplo de esta solucin.
La segunda solucin se puede utilizar cuando la funcin de encaminamiento es trivial y
cada transaccin se procesa en forma diferente (y por supuesto consta de elementos
diferentes). En este caso se puede dibujar una flecha diferente por cada tipo de transaccin
distinta, cada una de ellas dirigida a una casilla diferente de proceso; ver Fig. 3.8.
La descripcin y contenido de cada flujo de datos en el diccionario de datos, se trata en
detalle en el Captulo 4.
Figura 3.5 Flujo de datos que no necesita descripcin.
Figura 3.6 Flujo de datos de tratamiento difcil.
Figura 3.7 Una solucin para el flujo de datos de tratamiento difcil.
29
www.FreeLibros.org
Figura 3.8 Otra solucin para el flujo de datos de tratamiento difcil.
3.1.3 Proceso
Necesitamos describir la funcin de cada proceso y para una fcil referencia, dar a cada
proceso una nica identificacin vinculada, en lo posible, a un sistema fsico. Los procesos
pueden simbolizarse con un rectngulo vertical, con los ngulos redondeados, y dividido
opcionalmente en tres reas; ver Fig. 3.9.
La identificacin puede ser un nmero atravesado de izquierda a derecha en el diagrama
de flujo de datos, con el solo objeto de identificar el proceso. No hay dificultad en asignar
nmeros a los procesos si tenemos en cuenta que algunos procesos se abrirn a su vez en dos o
ms procesos (lo que implica la asignacin de nuevos nmeros) o bien algunos procesos se
unificarn (lo que implica la desaparicin de nmeros) durante el trabajo de anlisis. Una vez
asignada, la identificacin del proceso no deber cambiarse, excepto para aperturas o
unificaciones, dado que se utiliza como referencia para los flujos de datos y para la
descomposicin del proceso en niveles inferiores, como se describi en la Sec. 3.2. Para
mayor claridad, las lneas finas divisorias de la identificacin y la descripcin podrn omitirse,
en especial, si el diagrama ha de mostrarse a los usuarios.
La descripcin de la funcin deber hacerse con una frase imperativa, que consistir
idealmente en un verbo activo (extractar, calcular, verificar) seguido por una clusula objeto,
cuanto ms simple, mejor. Por ejemplo:
Extractar-ventas mensuales
Ingresar-nuevos detalles de los clientes
Verificar-si el crdito del cliente es bueno
En caso de dudas, una ayuda seria pensar que la descripcin de la funcin es una orden
a un empleado tonto. Si la descripcin no resulta ambigua para un empleado, y si usted
puede representarse mentalmente que la funcin podr llevarse a cabo en S -30 minutos en un
ambiente administrativo simple, posiblemente tenga una buena descripcin de la funcin.
Descripcin de la
Ubicacin fsica donde
se realiza
v * )
Figura 3.9 Smbolo de proceso.
30
www.FreeLibros.org
Calcular
solucin
de costo
mnimo
^ PM602 j
^ Departamento Nombre del programa
Figura 3.10 Casillas de proceso con referencias fsicas.
Generalmente hablando, cuando usted se encuentre utilizando los verbos procesar,
actualizar o validar ello puede significar que an no ha comprendido mucho acerca de
esta funcin y que an necesitar posteriores anlisis.
Crear, producir, extractar, recuperar, almacenar, computar, calcular,
determinar y verificar son todos verbos activos, sin ambigedad. Controlar o
chequear, pueden utilizarse, pero puede llevar a confusin con el sustantivo en las reas de
contabilidad o finanzas*. Clasificar significa que se ha elegido una solucin fsica, ya que la
clasificacin es meramente una agrupacin fsica distinta de la secuencia de registros en un
archivo y no posee valor lgico.
Obsrvese que estas frases imperativas no tienen sujeto; tan pronto como se introduce un
sujeto (por ejemplo, El gerente de ventas extracta mensualmente las ventas) se habr
indicado cmo deber realizarse fsicamente la funcin. Podr ser de utilidad cuando se est
estudiando un sistema existente, ver cul departamento o cul programa lleva a cabo la
funcin. En forma similar, cuando se ha completado el anlisis, y se est haciendo el diseo
fsico del nuevo sistema, es conveniente hacer notar cmo se ejecuta fsicamente la funcin.
Este es el propsito de la parte opcional inferiorde la casilla de proceso: incluir una referencia
fsica; ver Fig. 3.10. De esta manera, la descripcin de la funcin lgica y la implementacin
fsica pueden mantenerse separadas.
Extractar
ventas
mensuales
Gerencia ventas.
3.1.4 Almacenamiento de datos
Sin tomar un compromiso fsico durante el anlisis, encontramos que existen lugares
donde necesitamos definir datos para que puedan ser almacenados entre procesos. Los
almacenamientos de datos pueden simbolizarse por medio de dos lineas horizontales
paralelas cerradas en un extremo, preferentemente del ancho necesario para colocar el
nombre (0,6 cm en un diagrama sin reducir). Cada almacenamiento puede identificarse con
una letra D y un nmero arbitrario en un recuadro en el extremo izquierdo, para su fcil
referencia. Deber elegirse el nombre que sea ms descriptivo para el usuario.
D3 CUENTAS ACOBRAR
Para evitar complicaciones con el cruce de lneas en un diagrama de flujode datos, puede
dibujarse el mismo almacenamiento de datos ms de una vez en el diagrama, identificando Iqs
almacenamientos de datos duplicados mediante lneas verticales adicionales colocadas a la
izquierda.
D1
CUENTES D2 EMPLEADOS o CUENTES
La confusin surge en ingls al utilizar check (controlar, verbo, o cheque, sustantivo). (N. del T.)
31
www.FreeLibros.org
Cuando un proceso almacena datos, la flecha del flujo de datos se indica en la direccin
al almacenamiento de datos; inversamente, cuando un almacenamiento de datos es accedido
para ser ledo nicamente, es suficiente con mostrar el grupo de elementos de datos
recuperados como flujo de datos saliente; ver Fig. 3.11.
Horas trabajadas
Calcular
*
horas
trabajadas
D2 EMPLEADOS
Calcular
sueldo
bruto
Detalles de pagos acumulativos
D2 EMPLEADOS
Almacenamiento de datos Acceso a los datos
Figura 3.11 Almacenamiento de datos con acceso para lectura solamente.
Calcular
sueldo
bruto
Detalles de pagos acumulativos
N Seg. Soc.
D2 EMPLEADOS
Figura 3.12 Especificacin del argumento de bsqueda.
Si fuera necesario especificar el a rgumento de bsqueda, ste podr mostrarse en el lado
opuesto de la descripcin del flujo de datos; una punta de flecha indicar que el argumento de
bsqueda pasa del proceso al almacenamiento de datos, tal como se muestra en la Fig. 3.12.
3.2. CONVENCIONES SOBRE LA EXPLOSION
Como vimos en el Captulo 2, cada proceso en el diagrama de flujo de datos de alto nivel
de un sistema puede ser explotado para convertirse en un diagrama de flujo de datos en s
mismo. Cada proceso en el nivel inferior deber estar relacionado, inversamente, con el
proceso del nivel superior. Esto puede hacerse dndole a la casilla de proceso de nivel inferior
un nmero de identificacin que sea una fraccin decimal de la casilla de proceso del nivel
superior, por ejemplo, el 29 se descompone en 29.1,29.2,29.3, etc. y si es necesario llegar a
un tercer nivel, el 29.3 se descompone en 29.3.1, 29.3.2, etc.
La representacin ms clara de la expansin del proceso se obtiene dibujando los
diagramas de flujo de datos de nivel inferior dentro de los lmites que encuadran la casilla de
proceso de nivel superior. Obviamente, todos los flujos de datos hacia adentro y hacia afuera
de la casilla de proceso de nivel superior deben entrar y salir a travs del lmite. Los flujos de
datos que se muestran por primera vez en el nivel inferior, tales como los circuitos de errores,
tambin pueden salir fuera de los lmites. Cuando ello ocurre, se puede remarcar con una X
el punto de salida. Los almacenamientos dedatos solo se muestran dentro de los lmites si son
creados y accedidos por este proceso y no por otro. Por ejemplo, la Fig. 3.11 es un extracto de
la Fig. 2.5. La explosin del proceso de nivel inferior se muestra en la Fig. 3.14. Esta
explosin ilustra un nmero de detalles grficos:
Pago
r 4
Detalles de factura
Aplicar
pago a
factu
ra
V. . J
* \
Detalles de pago
D3 CUENTAS A COBRAR
32
Figura 3.13 Extracto de la Fig. 2.5.
www.FreeLibros.org
X": Los flujos de datos que se han visto previamente en el nivel superior, tales como circuito de errores, pueden tambin salir de
los limites. Cuando ello ocurre se marca con "X" en el punto de salida.
Figura 3.14 Explosin del proceso.
33
www.FreeLibros.org
1. Los almacenamientos de datos externos al proceso que se est haciendo explotar
pueden forzarse dentro de los limites si al dibujarlos as se simplifica el diagrama: D3:
CUENTAS A COBRAR realmente est fuera de APLICAR PAGO A FACTURA y ha
sido dibujado mitad adentro y mitad afuera, para mayor claridad. Los tres flujos de datos
D3-4.4: detalles de factura, D3-4.3: detalles de factura, y 4.9-D3: registro de pago
cruzan el lmite y concuerdan con los flujos en la Fig. 3.13.
2. El almacenamiento de datos D4/1, PAGOS NO IDENTIFICADOS, solamente
existe para propsitos internos de este proceso y por eso se lo muestra adentro. Si tuviera
acceso a l cualquier proceso que no formara parte del 4: APLICAR PAGO A F ACTURA,
debera dibujarse como externo (como DI: CLIENTES). Hemos utilizado la convencin
D4/1para indicar el primer almacenamiento interno de datos del proceso 4. No tiene por qu
tener relacin con ningn almacenamiento de datos D4 del diagrama de nivel superior
correspondiente.
3. Las entidades extemas no se muestran dentro de los limites de las explosiones aun
cuando, como BANCO en este caso, puedan no estar involucradas en ningn otro proceso.
4. Cuando resulte inevitable que un flujo de datos deba cruzar a otro, utilizaremos en
forma convencional un pequeo gancho, como se ejemplifica en 4.4-4.7: factura y detalles
de pago.
r h -------------
5. En el caso muy extrao que un flujo de datos necesite cruzar un almacenamiento de
datos, como en 4.9-4.8: detalles de pago tambin se colocar el gancho, tal como se
ilustra.
3.3 TRATAMIENTO DE ERRORES Y EXCEPCIONES
Cuando sea posible, los flujos de datos que resulten de condiciones de error y excepcin,
debern manejarse dentro del diagrama de segundo nivel en el cual aparecen. Esto es, las
transacciones errneas rechazadas por validar debern manejarse dentro de la expansin
de validar. Cuando una entidad extema, tal como un supervisor o un empleado de ajustes,
deba procesar manualmente el error, la entidad se mostrar en el diagrama de nivel.inferior,
pero fuera de lmite.
Cuando se trate de un proceso completo, comparable en complejidad con el diagrama de
nivel superior, se deber confeccionar un flujo de datosde nivel inferior para el mismo y luego
tomar la decisin de si el proceso sumario ser o no incluido en el diagrama de nivel superior.
Ello podr ser necesario cuando las excepciones puedan traer consecuencias financieras,
tales como mercadera devuelta, cheques sin fondos, etc.
Este proceso surge en APLICAR PAGO A F ACTURA respecto al manejo de pagos no
identificables, esto es, en el caso en que se recibe un pago sin ninguna indicacin de la factura
relacionada, y ms an, en que no existen antecedentes de haber enviado ninguna factura al
cliente o de haber confeccionado factura alguna por este monto (esto puede suceder, como por
ejemplo cuando una casa matriz paga una cuenta de una subsidiaria cuyo nombre es
completamente diferente, y el importe es errneo). Los procesos 4.2 y 4.5 contemplan esta
situacin, consultando al cliente y manteniendo el pago en D4/1 hasta tanto se reciba una
explicacin satisfactoria o bien hasta que el cliente que realiz el pago errneo reclame su
devolucin.
Una vez que han sido definidos los flujos de datos y los procesos, como se muestra en la
Fig. 3.14, el analista deber decidir si esta funcin es lo suficientemente importante como
para ser incluida en el diagrama de flujo de datos de nivel superior. Aunque ello involucra
dinero, la necesidad de la funcin solo aparecer en contadas ocasiones y las sumas
ingresarn en la empresa, no egresarn. Por estas razones, la funcin probablemente no ser
lo suficientemente importante como para ser incluida en el nivel superior.
34
www.FreeLibros.org
Para identificar las funciones en niveles inferiores que ms bien son agregados que
explosiones de procesos de nivel superior, las podemos numerar como procesos XI , X2, etc.
3.4 PAUTAS PARA DIBUJAR LOS DIAGRAMAS DE FLUJO DE DATOS
1. Identificar las entidades externas involucradas. Como ya dijimos, ello implica decidir
sobre un limite preliminar del sistema. Si tiene dudas, incluya dentro de los lmites de su
sistema la primera capa exterior de los sistemas manuales o automatizados que tenga como
interfaces. Recuerde que los flujos de datos se crean cuando pasa algo en el mundo exterior;
una persona decide comprar algo, u ocurre un accidente o un camin llega a la playa de cargas.
Si puede, vaya directamente a la ltima fuente de sus datos y dibuje el flujo desde all.
2. Identificar las entradas y salidas programadas que se espera puedan producirse en el
curso normal del negocio. Si la lista crece, trate de descubrir agolpamientos lgicos de
entradas y salidas. Marcar las entradas y las salidas que estn relacionadas solo con
condiciones de error y de excepcin.
3. Identificar las consultas y los pedidos de informacin que podran surgir. Especificar
un flujo de datos que defina la informacin dada al sistema y un segundo flujo de datos que
indique qu se requiere del sistema.
4. Tomar una hoja grande de papel (el reverso de una hoja usada de impresora, es bueno)
y, comenzando por el costado izquierdo con la entidad externa que le parezca la principal
fuente de entradas (por ejemplo, clientes), dibujar los flujos de datos que surjan, los procesos
que son lgicamente necesarios y los almacenamientos de datos que cree que se requerirn.
No preste atencin a las condiciones de tiempo, excepto a las naturales precedencias lgicas y
a los almacenamientos de datos necesarios desde el punto de vista lgico. Dibujar un sistema
que nunca comience ni pare. Algunas veces es muy til seguir una buena transaccin tpica de
entrada a travs de todo el sistema y preguntarse, Qu es lo prximo que debe sucederle a
esta transaccin? Seguir las reglas de notacin indicadas en la Sec. 3.1, pero no numerar los
procesos hasta el borrador final.
5. Dibujar el primer borrador a mano alzada y concentrarse en incluir todo, excepto
errores* excepciones y decisiones. Si se encuentra con que est dibujando un rombo de
decisin, pguese en la mano las decisiones se toman dentro de los procesos de nivel
inferior y no aparecen en los diagramas de flujo de datos.
6. Aceptar que se van a necesitar como mnimo tres borradores del flujo de datos del
nivel superior. No debe importar que el primerborrador resulte una maraa infructuosa. Se lo
podr ordenar (ver el ejemplo de la seccin siguiente).
7. Cuando tenga listo el primer borrador, controle nuevamente con su lista de entradas y
salidas para asegurarse que estn todas incluidas con excepcin de aqullas que operan con
errores y excepciones. Anote en el borrador cualquier entrada o salida normal que no pueda
ubicar. Recordar que cada dato que describe algn hecho exterior del mundo real debe ser
creado y mantenido.
8. Confeccionar ahora un segundo borrador ms claro utilizando una plantilla para
dibujarlos smbolos. Usted est pretendiendo realizar un diagrama con procesos nicos y con
un mnimo de cruzamiento de flujos de datos. Para minimizar los cruzamientos:
- Primero duplique las entidades extemas, si fuera necesario;
- Luego duplique los almacenamientos de datos, si fuera necesario;
- Admita entonces que se crucen los flujos de datos si no puede encontrar la disposicin
que reduzca el cruzamiento.
Su segundo borrador lucir ms claro, pero an contendr algunos cruces innecesarios, y si
los revisa, ver que se puede mejorar el diseo y la relacin de los smbolos de proceso.
Controle nuevamente su lista de entradas y salidas y anote en el segundo borrador cules no
ha podido ubicar.
www.FreeLibros.org
9. Si tiene un representante simptico del usuario, o alguien que conozca la aplicacin,
revise con l el segundo borrador, explicando que solo es un borrador y tone nota de cualquier
cambio que pueda resultar de la revisin.
10. Producir una explosin de nivel inferior de cada proceso definido en el segundo
borrador, de acuerdo con las convenciones especificadas en la Sec. 3.2. Resolver el manejo de
los errores y excepciones y si es necesario incorporar modificaciones en el diagrama de nivel
superior. Ahora puede completarse la versin tercera y final del diagrama del nivel superior.
11. Sicree que vale la pena la inversin, pdale a un dibujante que realice una excelente
copia de su diagrama de nivel superior, ya finalizado en un tamao aproximado de 0,90x1,20
Servir de invalorable ayuda para la presentacin a los usuarios, implementadores, revisores
y todos aquellos que tengan que ver con el sistema.
3.5 EJEMPLO: DISTRIBUCION CON INVENTARIO
Como ejemplo de la construccin de un diagrama de flujo de datos a escala completa,
consideraremos la Coiporacin CBM (Computer Books by Mail) que hemos descripto al
comienzo del Capitulo 2. Como ejemplo de un diagrama de flujo de datos, mostraremos el
sistema actual de CBM, que resulta un clsico caso de distribucin sin inventario. El sistema
requerido por la nueva gerencia para la comercializacin a particulares y a bibliotecarios, as
como la provisin de la mayor parte de los libros desde un stock, ser mucho ms complejo. Se
ha extrado de las especificaciones del sistema del viejo estilo la siguiente descripcin.
Numeramos las lneas para facilitar la referencia.
1. Los pedidos sern recibidos por correo, o tomados telefnicamen-
2. te a travs de la linea interna WATS. Los pedidos telefnicos se
3. tomarn en un formulario standard, o sern ingresados directamente en
4. una CRT usando un formato standard. Cada pedido ser revisado
5. para verificar que contiene toda la informacin importante,
6. que existe el ttulo (o puede ser identificado), que el autor
7. es el correcto (o puede ser identificado) y que se dispone del
8. Libro (por ej. no est fuera de impresin). Si el pedido fuera defectuoso se lo encaminar a un
supervisor para
9. verificar si, por ejemplo La programacin de la gerencia por Does Jane es
10. realmente La gerencia de programacin por Jane Doe. Cuando se in-
11. cluye el pago, se controlar que el importe sea correcto (en su de-
12. fecto se confeccionar una nota de dbito o de crdito). Las
13. pequeas diferencias se podrn ignorar.
14. Cuando el pago no acompaa al pedido, deber controlarse el
15. archivo del cliente para verificar si proviene de una persona u
16. organizacin que dispone de crdito; de no ser as se
17. remitir a la persona una confirmacin del pedido solicitndole
18. el pago anticipado. Si el cliente es nuevo ser incluido en el
19. archivo de clientes. Para los pedidos con pago incluido o con
20. crdito disponible, se deber controlar el inventario para verificar si se
21. puede cumplir. Si se puede, se preparar una nota de embar-
22. que con una factura (sellada pagado para las facturas pre-
23. pagas) y se remitir con los libros. Si el pedido solo puede
24. cumplirse parcialmente, se preparar una nota de embarque y una
25. factura por la parte remitida con una confirmacin de la parte
26. no satisfecha (y la factura pagada cuando el pago fue enviado
27. con el pedido) crendose un registro de entrega pendiente. Los
28. pedidos pendientes se satisfarn tan pronto se reciban del editor. Cuando el pedido corres
ponda a
29. un libro sin existencia en el inventario, los pedidos se agruparn en
30. lotes para efectuar una requisicin de compra al editor, al alcanzarse el tamao ,
36
www.FreeLibros.org
31. con asignacin de descuento. Los libros devueltos se examinarn para veri-
32. ficar si estn deteriorados y se ingresarn nuevamente al stock, emitiendo un
33. crdito o un reintegro al cliente, segn corresponda. Cuando el
34. libro devuelto no fuera un tem del inventario, y el editor admite
35. devoluciones, ser devuelto al editor.
36. Cuando se recibe el despacho de libros de un editor, su con-
37. tenido se controlar contra la orden de compra original y las
38. diferencias sern consultadas. Los ttulos del despacho se con-
39. trolarn con los pedidos pendientes para su prioridad de envo
40. y el resto se ingresar al inventario. La poltica de control de
41. inventario requiere un punto de pedido para cada ttulo igual
42. al (promedio de los pedidos recibidos en las 4 semanas previas)
43. X (plazo de entrega de los editores) ms un factor de seguridad del 50%.
44. De este modo, si la venta promedio de un ttulo es de 10 semanales
45. y el plazo estimado de entrega es de 3 semanas, deber colocar-
46. se una orden al editor cuando el total de ejemplares disponibles
47. (y en pedidos) haya llegado a 45 (3x10x150%). El factor de seguridad
48. podr modificarse cada tanto por la gerencia, siendo incrementado
49. para los ttulos con ventas en aumento y viceversa. La cantidad para cada
50. orden se determinar tomando el producto de la tasa relacin de
51. orden promedio por el tiempo de entrega, como se indic anterior-
52. mente, y multiplicando el resultado por un factor de acopio (normalmente 3), y re-
53. dondeando hasta el prximo punto de descuento superior, a menos que esto aumente la or
den ms del 25%.
54. As, en el caso anterior la orden normal ser de 3x10x3 (factor
55. de acopio) o sea 90 ejemplares. Si el editor ofrece un descuento
56. adicional por rdenes de 100 ejemplares o ms, se deber ordenar
57. 100. Si el descuento se ofrece soto para 120 o ms ejemplares, se
58. ordenarn 90, puesto que al ordenar 120 habra un excesivo incre-
59. ment del 33%. El factor de acopio puede ser modificado por la gerencia
60. para cada titulo, de tiempo en tiempo.
61. El clculo de la tasa de la orden promedio incluye las rde-
62. nes ya cumplidas y tos pedidos no cumplidos, tales como rdenes
63. devueltas, rdenes sin pagos y consultas que no se transformaron
64. en rdenes debido a que el libro no poda suministrarse desde
65. el stock.
66. Cuando se recibe el pago por los libros provistos, deber
67. compararse con la correspondiente factura. Cuando varias facturas
68. estn pendientes en una cuenta y el pago no coincide exactamente
69. con ninguna de ellas, se aplicar en primer trmino a la factura ms antigua. Con fre-
70. cuencia un cliente enviar un pago para cancelar varias
71. facturas. Cuando una factura cualquiera est atrasada en su pago
72. ms de 30 das, se le enviar al cliente un estado de cuenta
73. con toda las facturas impagas. Cuando
74. una factura cualquiera est atrasada en su pago ms de 60 das se confec-
75. cionar una nota enrgica con la firma del Vicepresidente.
76. Cuando se reciben facturas de los editores, se controlarn
77. contra los registros de recepcin de embarques y se ingresarn
78. en cuentas a pagar. Si el descuento por pronto pago dado por
79. el editor excede, en una base anualizada,
80. el costo marginal de fondos (tal como la gerencia lo especifi-
81. ca de tiempo en tiempo), el sistema deber confeccionar un che-
82. que de pago el ltimo da disponible para el descuento. Por ej. si
83. se ofrece el 2 1/2% por pago a 30 das, equivalente al 30% anual.
84. El sistema deber confeccionar un cheque
85. el da 29.
86. Regularmente debern producirse informes de facturas remitidas
87. por da, semana, mes, pagos recibidos por da, semana, mes, im-
88. portes impagos por distintos perodos, agotamientos de stock, pedido pen-
37
www.FreeLibros.org
89. dientes y compras a los editores. Los anlisis de demanda de ven-
90. tas por titulo, tema, editor, con informacin sobre tendencias,
91. debern estar disponibles en una base inmediata, junto con los
92. tiempos de entrega de los editores y tendencia de compras.
93. El acceso inmediato s los valores de inventario, tales como,
94. cantidad disponible, cantidad en pedido y fechas esperadas de
95. entrega son muy convenientes, as como la posibilidad de suministrar a un cliente
96. informacin inmediata sobre el estado de su
97. pedido en particular. Si un cliente llama y dice, Yo le envi un cheque
98. por $10 hace cinco semanas por un libro de Bloggs, nos gustaria
99.\poder decirle qu da le despachamos
100. el libro, o qu da estaremos en condiciones de despa-
101. chrselo.
Esta declaracin descriptiva de los requerimientos del nuevo sistema, como toda
exposicin, contiene informacin correspondiente a distintos niveles de detalle procedi
mientos combinados con estructuras, polticas importantes mezcladas con cosas triviales.
Cmo podemos extractar la informacin para confeccionar un diagrama de flujo de datos de
nivel superior?
Primero, identifiquemos cuntas entidades externas tenemos, mediante un examen de la
declaracin, antes de identificar y clasificar las entradas y salidas:
ENTIDADES EXTERNAS
NOMBRE REFERIDAS EN LA LINEA N
Clientes 1-2 (por implicacin), 15-19, 70, 73
Supervisor de Entrada de Pedidos 8-9
Editor 28, 30, 34-35, 36, 43, 46, 55, 76, 79
Gerencia 48, 60, 81,86-89 (por implicacin)
Vicepresidente 75,89-95?
%
Podr resultar que gerencia y Vicepresidente sean la misma entidad, o podremos
encontrar que gerencia realmente est compuesta por gerente de ventas, gerente de
abastecimiento y gerente de compras. Por lo menos tenemos una lista en borrador como
resultado de la exposicin. En cuanto a las entradas y salidas, vase la tabla de la pgina
siguiente. All el anlisis de entradas/salidas identifica todos los flujos de datos que podemos
encontrar en la exposicin, con excepcin de las consultas que puedan realizarse. Conviene
tratarlas por separado (ver ms adelante), puesto que comnmente consisten en entradas y
salidas apareadas.
En varios lugares hemos colocado un asterisco en una entrada o salida que corresponde a
un flujo de materiales (envos, devoluciones) sin un flujo de datos especificado. Normalmen
te, por supuesto, cada movimiento de materiales va acompaado de un comprobante (nota de
embarque, reclamo de crdito por devolucin) que contiene los datos de inters. Hacemos
notar que estos flujos de datos deben ser determinados y analizados.
Vale la pena recalcar tambin que este listado de entradas/salidas se ha confeccionado a
partir de una exposicin que nos fue provista. Tambin podra hacerse a partir de las
entrevistas del analista, de un conjunto de memorando, o de un conjunto de ambos. En
cualquier caso, la referencia debe indicarse en el listado de entradas/salidas.
38
www.FreeLibros.org
ENTRADAS
LISTADO DE ENTRADAS/SALIDAS
DESDE (EE) SALIDAS HACIA (EE) LINEA (REF)
Pedidos-Correo Cliente 1
Pedidos-telefnicos Cliente
1
Ordenes defectuosas B
Supervisor
de ingreso
de pedidos
Pago Cliente
11
Confirmacin Cliente 17
Pedido de prepago Cliente 18
Nota de envo Cliente 21
Factura Cliente 22
Libros * Cliente 23
Requisicin de Editor 30
compra
Libros devueltos * Cliente 31
Crdito Cliente 32
Reintegro Cliente 32
Libros devueltos * Editor 34
Embarque de libros * Editor 36
Consulta por Editor 38
diferencias
Orden Editor 45
(En qu se diferencia esto de la
"Requisicin de Compra", 307)
Modificacin factor Gerencia 47
de seguridad
Modificacin factor Gerencia 59
de acopio
Pedido no cumplido * Cliente 64
Informe Cliente 72
Nota enrgica Vicepresi 74
dente, luego
Cliente
Facturas Editor 76
Cheque de pago Editor 81
Facturas-informe Gerencia 86
diario
Facturas-informe Gerencia 86
semanal
Facturas-informe Gerencia 86
mensual
Ingresos-informe Gerencia 0
0
w
diario
Ingresos-informe Gerencia 87
semanal
Ingresos-infornse Gerencia 87
mensual
Importes impgos- Gerencia 87
informe
Falta de stock- Gerencia 88
informe
Pedidos pendientes- Gerencia 88
informe
Compras a editores- Gerencia 88
informe
* Movimiento de materiales: qu datos estn asociados con l?
39
www.FreeLibros.org
Desde/Hacia Dado
Consultas
Representar Lnea (Ref.)
Gerencia Ttulo del libro Anlisis de ventas 90
Gerencia Tema Anlisis de ventas 90
Gerencia Editor Anlisis de ventas 90
Gerencia Editor Anlisis tiempo de entrega 92
Gerencia Editor Anlisis de compras 93
Gerencia Ttulo Cantidad disponible 94
Gerencia Ttulo Cantidad pedida 94
Fecha de entrega 94
Cliente Nombre y detalle Estado del pedido 96-101
del pedido
Por el momento no nos interesa mayormente la inmediatez o el valor de estas consultas;
en este contexto representar podra significar producir un informe impreso el lunes
prximo por la maana. Las consultas se analizarn en detalle en el Captulo 7, Lo que nos
preocupa es la existencia de los flujos de los datos necesarios (y el almacenamiento de datos).
Para mantenemos dentro de la regla de simplificacin de los diagramas de flujo de datos
(pg. 35), queremos eliminar de nuestro primer borrador aquellas entradas y salidas
relacionadas con las condiciones de error o de excepcin y tratar como un solo flujo a aquellas
que sean similares lgicamente. Por eso trataremos pedidos por correo y pedidos
telefnicos simplemente como pedidos; lo lgicamente importante es conocer si estn
acompaadas o no del pago. Omitiremos en nuestro flujo de datos de nivel superior a
rdenes defectuosas, libros devueltos, crdito, reembolsos, consultas pordiferen-
cias, pedidos sin completar, informes y notas enrgicas.
Hecho esto, realicemos un primer borrador del diagrama de flujo de datos partiendo del
hecho saludable de que los clientes originan los pedidos.
LIBROS
Detalles
y precio
(Cumplir
/ f p e d i d o s
Redtdos con
/ \ Crdit o
OK
f e! crdito no es Suero)
Montos
adeudados
CUENTAS A COBRAR
Figura 3.15 Primer dibujo (parcial).
40
www.FreeLibros.org
La Fig. 3.15 muestra un borrador a mano alzada de los primeros pocos pasos del
procesamiento de pedidos. En este primer borrador reunimos todos los procesos que
examinan el pedido para comprobar si est completo, para controlar el archivo de libros a fin
de verificar si existe el libro, para controlar que el pago (si el cliente lo ha enviado) tiene el
importe correcto y para consultar en el archivo d clientes si ya hemos tenido relaciones
anteriores con l. Confeccionamos luego el proceso simple validar pedido y prepago
(cuando lo haya), y observamos que necesitaremos expandirlo cuando comencemos a
dibujar el flujo de datos de nivel inferior.
Nuestra prxima tarea ser explicar qu queremos decir con cumplir pedido. Vamos a
ampliar un poco nuestro borrador, hasta el punto que se ve en la Fig. 3.16. Aqu tomamos los
pedidos y obtenemos acceso al inventario existente para verificar si los podemos satisfacer o
no. Para aquellas que podemos satisfacer, generaremos una nota de envo (la que puede ser
utilizada por el depsito para tomar los libros del stock) y una factura (la que deber sellarse
pagado en el caso de haberse recibido el pago juntamente con el pedido). El borrador se
est haciendo algo complejo, pero podemos ver cmo est creciendo el sistema. Continuamos
por este camino hasta finalizar el primer borrador del sistema completo, tal como se muestra
en la Fig. 3.17.
Como se puede ver, el primer borrador puede resultar algo desordenado y confuso; slo
cuando se identifican los flujos de datos y los procesos se puede ir analizando cmo se
conectan entre s, de manera que es casi imposible obtener de entrada una buena distribucin.
Por lo menos ahora tenemos los aspectos ms importantes del sistema en una hoja de papel. El
prximo paso es volver a dibujar el primer borrador con una plantilla. La Fig. 3.18 muestra el
resultado.
/N VENTAR 10
x.-----------
LIBROS
D etat/es
y p re cio
' l/diic/dr
ped/do y
payo previo
(Cundo
se presente)
'\
V
Verificar
inventario
disponible
y ajustar
. stocA )
Pedidos con
/ pagopre vio
Pedidos
d ? crdito
/tem no embarca/es
(fuera c/e stock o sin existencia)
/tem tmbarcabies
JOireccion
SU E R TES
S o /ic itu d de p a g o p r e v io
f e i cre'dito no e s Sueno)
Rota de env/o y factura (corj /ibros)
Figura 3.16 Primer dibujo (extendido).
41
www.FreeLibros.org
//ros embarcador
\ P * l
Confirma c/on d e/pedi do con p a g o p r e v / 0 n o e n v i a d o /
-r facCurapopada a-ms fecha eCZ/mada de envo
Figura 3.17 Primer dibujo (final).
43
42
www.FreeLibros.org
No se indica: Consulta de clientes, informes a gerencia sobre compras y pedidos pendientes
creacin/mantenimiento de archivos para libros y editores
Figura 3.18 Segundo dibujo.
44
45 www.FreeLibros.org
04 HISTORIA OE PEDIDOS 05 INVENTARIO
t _
010 REQUERIMIENTOS PENDIENTES
01 QUEKTES
CUENTES
Pedido y
pagos previos
Validar
pedidos y
pago previo
{si se
presenta)
III 02
LIBROS
Solicitud de pago previo
Nota de envi y factura (con libros)
Confirmacin de pedido con pago previo no embarcare
Aplicar
pagos a
facturas
_____/
Figura 3,19 Dibujo fina!.
46
www.FreeLibros.org
f i \
Gen
confirr
erar
nacido
J
02 LIBROS
Detalles da
mercaderil
lecibida
D12 CUENTAS A PAGAR
Montos
adeudados
[ 17 1
Mantener
detalles
de libros
20
Preparar
pago
a
editores
21
Facturas
Verificar
facturas
Cheques por libros provistos
libres nuevos, cambio de precios
47
www.FreeLibros.org
\
El segundo borrador es ms claro y prolijo, ya que una vez que se pueden ver todos los
procesos y conexiones, es factible mejorar la distribucin de los mismos en la hoja. Obsrvese
que un flujo de datos confuso se ha aclarado mediante la duplicacin del almacenamiento de
datos de CUENTAS A COBRAR. El grfico todava est muy lleno en su parte superior,
alrededor de la entidad GERENCIA y se puede observar en la parte inferior que algunas
funciones significativas (aunque no complejas) han sido omitidas pra no restarle claridad al
resto del diagrama. Como se ha dicho, cada almacenamiento de datos que contiene
informacin bsica sobre el mundo exterior, debe ser creado y mantenido a medida que se
modifique el mundo exterior. El almacenamiento de datos CLIENTES se mantiene en el
segundo borrador en la medida en que podamos detectar y agregar nuevos nombres. Tambin
necesitamos las funciones de modificacin (por ejemplo, de la direccin o de la persona
responsable de la facturacin) y de eliminacin o baja de clientes. El almacenamiento de
datos LIBROS deber actualizarse con bastante frecuencia, ya que todos los das se publican
nuevos libros y los editores ocasionalmente modifican los precios. El almacenamiento de
datos EDITORES, una vez establecido, podr tener unos pocos cambios durante el ao, pero
generalmente es muy estable.
A costa de complicar el diagrama podemos agregar los diferentes flujos de datos y las
funciones asociadas con las consultas gerenciales sobre ventas, inventarios, compras y
devoluciones como se muestra en el diagrama de flujo de datos final de la Fig. 3.19.
Se invita al lector a recorrer los flujos de datos y funciones y verificar que las pautas
especificadas en las pginas 35 y 36 han sido satisfechas, excepcin hecha de aqullas
relacionadas con condiciones de error y excepcin que especficamente hemos excluido.
Hacemos notar que aun con un grfico de esta complejidad solo ha sido necesario duplicar
una entidad externa (m: GERENCIA) y tres almacenamientos de datos (D3, DIO y D2).
3.6 FLUJO DE MATERIALES Y FLUJO DE DATOS
En varios puntos anteriores cuando describamos el sistema que acabamos de graficar,
comentbamos que estbamos tentados a describir el flujo de materiales en lugar del flujo de
datos asociado, que es lo correcto. Es importante mantener separados estos dos conceptos,
especialmente en industrias manufactureras y de distribucin, donde la mayor parte del
negocio gira alrededor del movimiento de materiales. Aun n bancos, negocio que pensamos
se encuentra ms prximo al dato puro, existen serios problemas vinculados con el movimien
to fsico de cheques y comprobantes.
En consecuencia, necesitamos disponer de una forma para graficarel flujo de materiales
cuando sea necesario, y vincular el diagrama de flujo de materiales al diagrama de flujo de
datos. El flujo de materiales es de naturaleza esencialmente fsica, pero deseamos en la
medida de lo posible, describir en trminos lgicos las operaciones realizadas con los
materiales. Por ello no estamos satisfechos con el grfico de flujo de materiales del tipo de la
Fig. 3.20 pero necesitamos alguna forma de describir las funciones lgicas que transforman el
material en cada punto con la indicacin de los flujos de datos asociados. La Fig. 3.21 muestra
ambos flujos de datos y materiales con referencias al diagrama de flujo de datos original
(Fig. 3.19).
Obsrvese que solo dos de las transformaciones de materiales corresponden a procesos
del diagrama de flujo de datos (16 y 19) y que algunos flujos de materiales tienen lugar sin un
flujo de datos (por ejemplo, agregados al stock).
48
www.FreeLibros.org
o o
cc
<
UJO
=3O
O <
t r o
S? ^
CD
-5 CC
O o
uj a.
o
o
uj o
g>
O o
T3
O
o
o
o
te
rt
u-
O
-
49
F
i
g
u
r
a
3
.
2
1
F
l
u
j
o
d
e
d
a
t
o
s
y
f
l
u
j
o
d
e
m
a
t
e
r
i
a
l
e
s
.
www.FreeLibros.org
BIBLIOGRAFIA
3.1 D. Martin y G. Estrin, Models of Computations and System-Evaluations of Vertex Probabilities in
Graph Models of Computations, Journal of theACM, Vol. 14, N 2, abril de 1967.
3.2 E. Yourdon y L.L. Constantine, Structured Design, Prentice-Hall, Englewood Cliffs, N J., 1979.
3.3 G.E. Whitehouse, Systems Analysis and Design Using Network Techniques. Prentice-Hall,
Englewood Cliffs, N. J., 1973.
3.4 D. Ross, Structured Anlysis (SA): A Language for Communicating Ideas, IEEE Transactions
on Software Engineering, Vol 3, Nmero 1, enero de 1977.
Ejercicios y puntos de discusin
1. En la Fig. 3.19, por qu requerimientos para inventario (9-15) va directamente a 15: Reunir
requerimientos para editores, mientras que los item que no estn almacenados en el inventario son
acumulados en DIO: REQUERIMIENTOS PENDIENTES?
2. Por qu el proceso 9 1determinar puntos de pedido para tem de inventaro, no requiere los datos de
D8: ORDENES DEVUELTAS?
3. Es razonable el algoritmo de pedido utilizado por CBM (lineas 44-49 de la exposicin)? Puede
mejorarse?
4. Suponiendo que el nico negocio de CBM es la venta de pedidos por correo, qu otros sistemas de
informacin y procesamiento de datos podra suponer Ud. que posee, adems del sistema indicado en
la Fig. 3.19?
5. Adapte la Fig. 3.19 para indicar el flujo de datos de una empresa que almacena autopartes pra
automviles nacionales e importados (slogan: Si no lo tengo, lo conseguir) para su posterior venta
de pedidos por correo. Cmo deber modificarse el flujo de datos si se crea un departamento de
ventas en el mostrador?
6. Haciendo algunas suposiciones razonables, explotar los procesos 19: Verificar contenidos de
embarques, 20; Preparar pago a vendedores, y 21: Verificar facturas (en la Fig. 3.19) a los
efectos de realizar un diagrama de flujo de datos en detalle del subsistema de cuentas a pagar, que
incluya las condiciones probables de error y excepcin.
7. Liste todas aquellas empresas en que considere que el negocio consiste en el mantenimiento de
inventarios y la distribucin, sea por correo o por mostrador. Identifique las similitudes y diferencias
. de sus flujos de datos.
8. Dibuje los diagramas de flujo de datos completos de los siguientes tipos de empresas:
(a) Fabricacin a pedido * ,
(b) Fabricacin, mantenimiento en stock y distribucin
(c) Concesin de prstamos al consumidor
(d) Mantenimiento de cuentas de ahorro
(e) Emisin y mantenimiento de plizas de seguros contra accidentes y atencin de reclamos
(f) Venta por horas de servicios profesionales y pago de honorarios a profesionales (por ejemplo^
prctica legal).
(g) Agencia de registros de reservas para viajes.
50
www.FreeLibros.org
4
CONSTRUCCION Y USO DE UN
DICCIONARIO DE DATOS
En el Captulo 2, vimos que si quisiramos profundizar los detalles de los contenidos de
los flujos de datos, almacenamientos de datos y procesos, necesitaramos algn lugar
estructurado para guardar todos estos detalles. El diccionario de datos provee este lugar. El
nombre diccionario de datos comienza a extenderse cuando empezamos a incluir Ios-detalles
de los procesos, que estrictamente hablando son lgica ms bien que datos. Posiblemente el
diccionario de datos debera llamarse realmente gua de proyecto. Sin embargo, el nombre de
diccionario de datos es de un uso muy amplio y lo adoptaremos sin inhibiciones para todo lo
que necesitemos describir.
4.1 EL PROBLEMA DE DESCRIBIR DATOS
En los buenos tiempos del registro unitario, los trminos utilizados para describir los
datos, eran muy simples. Una taijeta se divida en campos; la taijeta en s misma era un
registro, y una cantidad de registros constituan un archivo. No era tan simple como esto; un
campo de datos de la forma MMDDYY podia considerarse compuesto por tres sub-campos,
de manera que la descripcin jerrquica del dato abarcaba cuatro niveles, como se muestra a
continuacin:
51
www.FreeLibros.org
Esta jerarqua se tom para el procesamiento de cinta y luego para el procesamiento $6
disco. IBM denomina a un archivo como conjunto de datos, y encontramos registros de
longitud variable en donde un encabezamiento era seguido por un nmero de registros de cola
o grupos repetitivos, tal como en un pedido:
Fecha Nombre del cliente Pedido N Producto N Cant. Producto N Cant
Todava podemos utilizar las mismas palabras para describir nuestros datos.
Con el desarrollo de la tecnologa de base de datos, el vocabulario simple ya no es
suficiente. Desde que parte de la tcnica de la base de datos se basa en tomar los archivos para
cada aplicacin e integrarlos en una base de datos que pueden utilizar todas las aplicaciones,
el trmino archivo se hace cuestionable. El Information Management System (IMS)
(Sistema de Informacin Gerencial) [4.1 ] de IBM describe a los datos como campos, que se
combinan en segmentos, que se combinan en bases de datos. El Date Base Task Group
(DBTG) (Grupo de Tareas de Base de Datos) de la Conference on Date Systems Languages
CODASYL (Conferencia sohre lenguajes de Sistemas de Datos) [4.2] describe a los datos
como tem de dato, los cuales se combinan en agregaciones de datos, los cuales a su vez se
combinan en registros, donde sus relaciones se expresan como conjuntos. La Divisin de
Datos de COBOL estipula tem elementales, los cuales se combinan en tem de grupo, los
cuales por su parte se combinan en registros, que conforman archivos. Discutiremos otras
terminologas en el Captulo 6; algunos trminos diferentes se resumen en la Tabla 4.1.
Dado este cmulo de conceptos y trminos, necesitamos elegir algunas palabras simples
que no deben entrar en conflicto indebidamente con estos vocabularios comunes y que
debern permitimos describir tanto los flujos de datos como los almacenamientos de datos a
nivel lgico.
La experiencia nos ensea que podemos describir en tres niveles todo lo que nos resulte
de inters como analistas.
\ 1. Elementos de datos: Son partes de datos que no resulta significativo descomponer
ms an para nuestro propsito. Por ejemplo, fecha es un elemento de datos a los finesde la
mayor parte de nuestros propsitos durante el anlisis, aunque sea necesario al codificar una
rutina de conversin de fecha, tenerla en cuenta como unS estructura formada por mes, da,
ano'.
2. Estructuras de datos: est formada por elementos de datos, o por otras estructuras de
datos, o por una combinacin de ambas. Consideremos el contenido del flujo de datos
pedidos que vimos en el Captulo 2:
PEDIDO
PEDIDO-IDENTIFICACION
CLIENTE-DETALLES
UBRO-DETALLES
y podemos expandir esto ms an con notas:
PEDIDO
PEDIDO-IDENTIFICACION
PEDIDO-FECHA
CLIENTE-PEDIDO-NUMERO Normalmente presente
CLIENTE-DETALLES
EMPRESA-NOMBRE
PERSONA-AUTORIZANTE..................... Opcional
NOMBRE.....................Puede ser slo la inicial
APELLIDO
TELEFONO
52
www.FreeLibros.org
TABLA 4.1 Ejemplos de definiciones de datos
COBOL PL/1 IMS(DL/1) CODASYL
Unidad ms pequea
de dato
Item
elemental
Elemento Campo Item de datos
Grupo de las unidades
ms pequeas
Item de
grupo
Estructura Segmento Agregacin de datos
Unidades
repetitivas
Tabla/grupo
de repeticin
Matriz Segmento Vector/grupo de
repeticin
Entidad que se procesa
de una vez
Registro Registro Registro
lgico
Registro
Mayor agrupamiento
reconocido
Archivo Archivo Base de
datos
Conjunto/esquema
CODIGO-DE-AREA
CENTRAL
NUMERO
EXTENSION..................... Opcional
DESPACHARA-DIRECCION
CALLE
CIUDAD-LOCALIDAD
CODIGO-POSTAL
FACTURAR-A-DIRECCION.. .Si no se Mica, igual a DESPACHAR-A-DIRECCION
CALLE
- CIUDAD-LOCALIDAD
CODIGO-POSTAL
LIBRO-DETALLES.. .Una o ms iteraciones de este grupo de elementos de datos
AUTOR-NOMBRE.. .Una o ms iteraciones de este elemento de datos
TITULO
ISBN.,..International Standard Book Numben Nmero internacional asignado al libro (opcional)
LOCN....Librery of Congress Number. Nmero de la Biblioteca del Congreso de EE.UU. (opcional)
EDITOR-NOMBRE.....................Opcional
CANTIDAD
TELEFONO es una estructura de datos compuesta por cuatro elementos de datos
CODIGO-DE-AREA, CENTRAL, NUMERO y EXTENSIN. CLIENTE-DETA-
LLES es una estructura de datos compuesta por el elemento de datos EMPRESA-
HOMBRE ms la estructura de datos PERSONA-AUTORIZANTE ms la estructura
de .datos TELEFONO, etc. PEDIDO es pa s mismo una gran estructura de dtos.
3. Flujos de datos y almacenamiento de datos: Ya hemos discutido este nivel de la
descripcin de datos. Los flujos de datos son circuitos o tuberas a travs de las cuales se
trasladan las estructuras de datos; los almacenamientos de datos son lugares donde las
estructuras de datos se almacenan hasta que son utilizadas. Los flujos de datos son
estructuras de datos en movimiento; los almacenamientos de datos son estructuras de datos
en reposo.
Nuestra descripcin jerrquica de datos es entonces la siguiente:
53
www.FreeLibros.org
Una vez que tenemos la descripcin lgica de datos en este nivel, es fcil volcarla al
vocabulario del lenguaje particular o sistema de base de datos que se utilizar en la
implementacin fsica.
4.2 QUE DESEARIAMOS QUE CONTENGA UN DICCIONARIO DE DATOS
Previo a discutir las implementaciones especificas de los diccionarios de datos manuales
y automatizados, examinaremos los elementos de datos y estructuras de datos para ver qu
podemos desear registrar acerca de ellas en las diferentes circunstancias. Veremos tambin
los atributos de los flujos de datos, almacenamientos de datos, procesos, entidades externas y
dems elementos que encontramos en el anlisis, para analizar qu es lo que tiene valor
registrar. Ello nos dar un panorama para evaluar cualquier sistema diccionario de datos para
programar uno propio.
4.2.1 Descripcin de un elemento de datos
La informacin mnima necesaria para definir un elemento de datos es su nombre y su
descripcin. Por ejemplo,
r
e
o
:
A
e
l
:
M
t
o
d
o
T
e
r
r
e
s
t
r
e
:
T
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
L
o
c
a
l
:
L
c
2
:
D
e
s
t
i
n
a
t
a
r
i
o
E
s
t
e
:
E
O
e
s
t
e
.
0
L
i
v
i
a
n
o
:
L
c
3
:
P
e
s
o
M
e
d
i
a
n
o
:
M
P
e
s
a
d
o
:
P ^ Z
*S *cS
y
UJ Z
0
1
4
. 5/3
t/i
. 2
es
a
2
:
1
2
l
i
j
o
s
a
3
:
6
0
+
2
u
/
l
b
a
4
:
1
2
0
+
4
u
/
l
b
!
I
j
JO
*3
es
th
(D
O
*3
w
I
! "3
! 40
1
98
www.FreeLibros.org
de decisin cuando se utilicen abreviaturas, es posible seguir las combinadMii d#las
condiciones de cuta rama del rbol y ver cmo encajan todas entre s. Esto contrasta con la
tabla de decisin donde el significado de cada regla debe ensamblarse mentalmente,
condicin por condicin.
Pauta 3. Aun cuando se necesite una tabla de decisin para llegar al final d la lgica, termine
presentndola como un rbol, si puede hacerlo sin violar la Pauta 1.
,5.4 LENGUAJE ESTRUCTURADO, "PSEUDOCODIGO" Y LENGUAJE
COMPRIMIDO"
Los rboles de decisin y las tablas de decisin son las herramientas preferidas para
fatar con los procesos ramificados complejos, tales como los que tpicamente se encuentran
en los clculos de descuentos, clculos de tarifas, comisiones de venta y clculos de primas de
productividad, procedimientos de control de inventarios, etc. Sin embargo, muchos de los
procesos que debemos documentar no sai tan complejos. Encontramos que incluyen
operaciones (Hacer esto, luego aquello.. . ), algunas decisiones y unos pocos lazos
(Repetir este proceso hasta.. . ). Esto no nos sorprende ya que sabemos que puede probarse
[5,4} que cualquier programa se compone de una adecuada combinacin de instrucciones
paso a paso (como MOVER o SUMAR), decisiones binarias (SI-LUEGO-SI NO-
ENTONCES), y lazos. Los procesos lgicos que estamos definiendo en el anlisis
estructurado son justamente esto, programas para ser ejecutados ya sea por empleadoso por
computadoras. Estas pocas estructuras proveen las bases para la programacin estructurada,
parte de cuya efectividad deriva de la simplificacin y normalizacin resultante del uso de Unas
pocas estructuras, en lugar de la gran variedad permitida por el lenguaje de programacin a
utilizar. Si pudiramos escribir nuestras especificaciones empleando un enfoque similar en
lenguaje corriente, podramos obtener algunos de esos mismos beneficios. Vamos a estudiar
estas estructuras con un poco ms de detalle para ver cmo las podemos incorporar al
lenguaje. , .
5.4.1 Las "estructuras" de la programacin estructurada
I. Instrucciones secuenciales. Esta estructura abarca cualquier instruccin o grupos de
instrucciones que no tienen repeticin o ramificacin dentro de ellos, como por ejemplo,
Multiplicar horas trabajadas por salario horario para obtener el pago bruto.
Despachar libros a la direccin de destino.
Sumar importe del flete a la factura.
Calcular importe del flete. (El importe del flete es de 60 unidades por cada libra que
exceda las 20.)
Tramitar la cesanta del empleado.
Conceder el 25% de descuento.
A veces es necesario incluir descripciones o definiciones de los trminos empleados,
como en el caso precedente de importe del flete. Lo que no tenemos que hacer es entrar a
hurtadillas en cualquier ramificacin o repeticin escondida, como en
Despachar libros a la direccin de embarque, o a la de facturacin, la que sea de
aplicacin (ramificacin escondida).
Continuar asignando paci, una unidad por vez, y detenerse cuando todas las
solicitudes se han satisfecho (un lazo escondido, con una prueba clara para saber
cundo interrumpir el lazo).
www.FreeLibros.org
Si tenemos un grupo de declaraciones verdaderamente secuenciales y las juntamos, el
/oque resultante de declaraciones se ver como una sola declaracin secuenciaL Si creamos
el siguiente grupo de declaraciones y las denominamos calcular-deducciones,
- Obtener remuneracin bruta
- Obtener detalles de la remuneracin acumulada a la fecha
- Calcular retenciones federales
- Calcular retenciones estatales o provinciales
- Calcular seguro social
y tambin creamos un grupo de declaraciones denominadas emitir cheques de pago
- Ingresar bruto y retenciones en el taln del cheque
- Ingresar remuneracin neta en el cheque
- Firmar cheque
- Enviar por correo cheque y taln
podemos escribir legtimamente como instrucciones secuenciales
HACER (DO) calcular deducciones
HACER (DO) emitir cheque de pago
sin emplear ninguna decisin o lazo escondido. HACER (DO) significa Llevar a cabo
todas las instrucciones listadas bajo el siguiente nombre.. .
2. Instrucciones de decisin. Como vimos, el formato normal para una decisin es la
estructura
SI Condicin.l
LUEGO accin-A
SI NO (no Condicin-1)
ENTONCES accin-B
Cada accin puede ser un conjunto de instrucciones secuenciales, o un lazo, u otra
decisin. Supongamos que se reemplaza accin-A por otra estructura SI-LUEGO-SI
NO-ENTONCES, obtendremos
SI
LUEGO
SI NO
ENTONCES
Condicin-1
SI
LUEGO
SINO
ENTONCES
(no condicin-1)
accin-B
Condicin-2
accin-C
(no Condicin-2)
accin-D
Un ejemplo de este caso podra ser
SI
LUEGO
necesita una vacacin
SI
LUEGO
SINO
ENTONCES
SI NO no necesita una vacacin
ENTONCES siga trabajando
puede pagarse una vacacin
tmese una vacacin
(no puede pagarse una vacacin)
pinte la casa
La oracin SI.. . LUEGO SI.. . , si bien es correcta en castellano, se lee un poco
extraa. Como en los ejemplos anteriores del captulo, preferimos escribir SI.. .y-SI.. ,, lo
cual significa lo mismo pero se lee un poco ms natural, y ahorra el LUEGO para indicar una
accin.
Si puede sustituir un SI-LUEGO-SI NO-ENTONCES por una accin en un lugar, lo
100
www.FreeLibros.org
puede hacer en cualquier parte. Podemos sustituir otro SI por tome una vacacin; asi
SI necesita una vacacin
y-SI puede pagarse una vacacin
y-SI tiene alguien con quien ir
y-SI tiene algn lugar donde ir
LUEGO...
SINO
As es como aparecen los SI anidados, a medida que la lgica que estamos
representando se hace ms compleja. Esta lgica anidada puede ser difcil de seguir, de
manera que es importante usar las convenciones de alinear cada SI NO con el SI al que
pertenece. Como una regla prctica, si se tiene ms de tres SI anidados unos en otros, resulta
ms claro representar la lgica con un rbol de decisin, al costo de no poder trascribir
completamente las condiciones.
2.1 Instrucciones de decisin caso" ( case). Un tipo especial de estructura de decisin
aparece cuando hay varias posibilidades de una condicin que nunca se presenta en
combinacin; por ejemplo, las mismas representan diferentes casos los cuales son
mutuamente excluyentes.
Este tipo de estructura siempre puede representarse en una tabla simple, como por
ejemplo,
Condicin Accin
La transaccin es un pedido Sumar a ventas-a-la-fecha
La transaccin es una devolucin Restar de ventas-a-la-fecha
La transaccin es un pago Sumar a pagos-recibidos
La transaccin es un reclamo Pasar al Departamento Reclamos
La transaccin es una cancelacin Restar de ventas-a-la-fecha
La faceta importante de esta situacin es que la transaccin debe ser de uno de estos
cinco tipos y solo de uno. Por ejemplo, no puede ser a la vez un pedido y una cancelacin.
Solamente se aplica un caso por vez. Esta estructura especial se conoce como estructura
caso (case, en ingls) y se representa convencionalmente en lenguaje estructurado de la
siguiente manera;
SI caso-1
LUEGO SI accin-1
SI NO, SI caso-2
accin-2
SI NO, SI caso-3
accin-3
SINO...
Si aplicamos esta convencin a nuestra estructura de transccin tendremos
SI la transaccin es un pedido
sumar a ventas-a-la-fecha
SI NO, SI la transaccin es una devolucin (
restar de ventas-a-la-fecha
SI NO, SI la transaccin es un pago
sumar a contado recibido
SI NO, SI la transaccin es un reclamo
pasar al Departamento Reclamos
101
www.FreeLibros.org
SI NO, SI la transaccin es una cancelacin
restar de ventas-a-la-fecha
SI NO (no es ninguno de los de arriba)
ENTONCES dirigirse al supervisor
Obsrvese el ltimo SI NO; se lo requiere a fin de que hay a igual cantidad de SI y SINO. Si se
omite este ninguno de los de arriba o caso defecto, existe la posibilidad de que aparezca
en la prctica un caso que no se encuentre cubierto por la lgica especificada. El analista debe
considerar este caso y proceder en consecuencia. Esta posibilidad puede parecer remota
cuando los casos representen divisiones arbitrarias a lo largo de un continuo completo, como
por ejemplo.
SI la persona es menor de 18 aos
sumar al total de menores"
SI NO, SI la persona es de 19 o mayor pero menor de 35
sumar al total de adultos jvenes
SI NO, SI la persona es de 35 o mayor pero menor de 65
sumar al total de adultos maduros
SI NO, SI la persona es de 65 o mayor
sumar al total de ciudadanos ancianos
SI NO (ninguno de los de arriba)
Qu puede representar posiblemente (ninguno de los de arriba) El analista debe
permitir que el ltimo SI NO quede suspendido en esta situacin; le corresponde
considerar al programador cmo debe proceder en un caso donde fallan todas las pruebas de
edad (tal vez por que la edad haya sido codificada incorrectamente).
3. Instrucciones repetitivas (lazos). Esta estructura se aplica a cualquier situacin en la
cual una instruccin o grupo de instrucciones se repite hasta que se obtiene algn resultado
deseado.
Para tomar un ejemplo muy simple, en que una factura cubre la venta de una cantidad de
item, cada uno se listar en un rengln separado con la cantidad vendida y el precio unitario,
como se ve en la Fig. 5.14.
Se podr especificar la confeccin de la factura escribiendo
Por cada lnea de item, multiplicar la cantidad por el preci unitario, para obtener los totales de l
nea. Cuando se han considerado todas las lneas de tem, sumar todos los totales de lnea para obte
ner el total de la factura.
Ms formalmente, podramos especificar
REPETIR EXTENDER-LINEA-ITEM HASTA QUE todas las lneas hayan sido resueltas
y definir EXTENDER-LINEA-ITEM como
Multiplicar cantidad por precio unitario para obtener total de la linea
Con solo una instruccin para construir el cuerpo del lazo, esto es como tomar una maza
para partir una nuez, pero puede ser una estructura valiosa para utilizar cuando la situacin
requiere una cantidad de instrucciones a repetir una y otra vez como un grupo. Lo que es ms
importante an, pone de relieve los dos aspectos que debemos especificar para definir una
estructura de repeticin:
1. Exactamente qu es lo que debe repetirse?
2. Cmo se sabe cundo hay que parar?
102
www.FreeLibros.org
Factura
A: Nombre del cliente
Direccin del cliente
Cantidad Descripcin Precio unitario Importe
7 Sillas de montar $200.00
28 Herraduras $ 1,00
_
7
Bridas $ 10,00
-
1 Escopeta $ 50,00
Total de ta factura
Figura S.14
Mientras que el analista debe estar preparado para especificar repeticiones cuando ellas
sean claramente parte de la funcin lgica, es ms usual que el diseador y el programador se
encarguen de producir lazos a ser ejecutados por la mquina, debido a que el analista est
relacionado primariamente con el procesamiento lgico de cada estructura de datos, y el
diseador/programador est vinculado con el procesamiento fsico de una serie de estas
estructuras. La definicin de lazos se hace ms importante a medida que nos acercamos ms a
la impementacin fsica, como veremos en la Sec. 5.4.3.
5.4.2 Convenciones para el lenguaje estructurado
Como se indic anteriormente, es posible escribir cualquier especificacin lgica
empleando las cuatro estructuras bsicas que hemos expuesto. Cuando la lgica est escrita
en idioma corriente, utilizando letras maysculas y sangrado, se la conoce como lenguaje
estructurado. Podemos resumirlas convenciones para el lenguaje estructurado de la siguiente
forma:
1. La lgica de todos los procesos en un sistema se expresa como una combinacin de
estructuras secuenciales, de decisin, de caso .y de repeticin.
2. Deben observarse las reglas del castellano sin ambigedades, tal como se indic en la
Sec. 5.1.1.
3. Las palabras clave SI, LUEGO, SI NO, ENTONCES, REPETIR y HASTA
debern escribirse con mayscula y las estructuras deben sangrarse para mostrar su jerarqua
lgica.
4. Los bloques de instrucciones pueden agruparse entre s y debe drseles un nombre
significativo que describa su funcin, que tambin deber escribirse con maysculas.
5. Cuando se utilice una palabra o frase que se encuentre definida en el diccionario de
datos, dicha palabra o frase deber subrayarse.
Para ilustrar la fortaleza y la debilidad del lenguaje estructurado tomaremos como ejem
plo parte de la funcin 7. Generar nota dy embarque y factura" del diagrama de flujo de
datos del Captulo 3. La generacin de la factura comprende tres pasos:
- El clculo del total de cada tem y de la factura
- El clculo del descuento (si existe alguno)
- El clculo del cargo por despacho y manipuleo (empleando una versin simplificada de
la poltica que hemos examinado con el rbol de decisin y la tabla de decisin).
103 www.FreeLibros.org
La Fig. 5.15 muestra una representacin, en lenguaje estructurado, de la mayor parte de la
lgica. Se efectuarn varas aclaraciones sobre la base de este ejemplo de lenguaje
estructurado:
GENERAR FACTURA
HACER (00) CALCULAR-TOTAL-FACTURA
HACER CALCULAR-DESCUENTO
HACER CALCULAR-DESPACHO-MANIPULEO
Restar descuento de total-factura para tener neto-factura
Sumar carao-despacho-manipuleo a neto-factura para tener total-a-pagar
Escribir factura
CALCULAR-TOTAL-FACTURA
REPETIR EXTENOER-UNEA-ITEM-HASTA que todas las lineas-tem hayan sido
extendidas
Sumar todos los totales lineas-tem para obtener total-factura
EXTENDER-LINEA-ITEM
Multiplicar cantidad por costo-unitario para obtener total-lnea-tem
CALCULAR-DESCUENTO
SI factura total es Ml$10i000
descuento es 5% de total-factura
SI NO SI factura-total 'es MIS250 pero mi $1.000
descuento es 2 1/2% de total-factura
SI NO SI factura-total es Ml$100 pero mi $250
descuento es 1% de total-factura
SI (factura-total es mQ$100)
ENTONCES descuento es cero
CALCULAR-DESPACHO-MANIPULEO
SI pedido especifica despacho areo .
LUEGO HACER CALCULAR-FLETE-AEREO
SI NO (pedido especifica despacho terrestre o no especifica el mtodo)
ENTONCES HACER CALCULAR-FLETE-TERRESTRE
Multiplicar tarifa por valor-unitario-corriente para ten cargo-despacho-manipuleo
CALCULAR-FLETE-AEREO
-SI peso es ml2
flete es 6 unidades
SI NO SI peso es rrfQ2 pero ml20
Multiplicar cada libra de peso por 3 unidades para obtener flete
SI NO (peso es MQ20)
ENTONCES Restar 20 del peso para obtener exceso
Multiplicar exceso por 2 unidades por libra y sumar 60 (20 libras
3 unidades por libra) para obtener tarifa
CALCULAR-FLETE-TERRESTRE
SI destino es local
y-SI cdigo-servicio es expreso
LUEGO Multiplicar cada libra de peso por 2 unidades para obtener
tarifa
etc.
Figura 5.15 Lenguaje estructurado.
104
www.FreeLibros.org
1. Tiene mucho de la precisin de un programa de computacin, pero no es un programa
de computacin. No existe especificacin para la lectura y grabacin de tos archivos fsicos,
ni ajuste de cntadores o interruptores, ni diseo fsico alguno. El procedimiento as escrito
puede ser ejecutado perfectamente bien por un empleado, aunque se puede elegir presentar las
instrucciones de diferente manera.
2. El procedimiento ha sido escrito como una jerarqua de bloques de instrucciones,
como se muestra en la Fig. 5.16. Si se desea obtener un resumen del procedimiento solo hay
que leer el bloque superior. Si se desean tos detalles de cualquier parte especfica, se debe leer
solamente esa parte.
3. El subrayado de tem definidos en el diccionario de datos pone de manifiesto el uso de
trminos que an necesitan definicin. En la Fig. 5.15 la condicin el destino es local sin
subrayar indica que an no se ha realizado una definicin estricta de local. Si se hubiera
realizado, habramos hallado dicha condicin expresada como destino-tipo es locar.
4. Sujetas a la necesidad de ms definiciones, las instrucciones estn completas. Ello
incluye la descripcin de la tarea paso a paso, a diferencia del rbol de decisin y la tabla de
decisin, tos cuales solo muestran la lgica de las ramificaciones respectivas.
5. La precisin e integridad del lenguaje estructurado se obtienen a costa de una
presentacin verbosa y poco usual, que define cada pequeo detalle para la persona que no
est familiarizada con el procedimiento, pero que pronto resulta irritante para aquel que solo
desea que le expongan tos hechos bsicos. El lenguaje comprimido es una derivacin del
lenguaje estructurado que trata este problema; lo discutiremos en la Sec. 5.4.4.
Figura. 5.16 Jerarqua de los bloques de funciones.
5.4.3 "Pseudocdigo"
Hemos indicado que un problema definido en lenguaje estructurado no es un programa
de computacin. Sin embargo, una vez realizado el trabajo principal del diseo fsico y
definidos los archivos fsicos, resultar muy conveniente poder especificar la lgica del
programa fsico utilizando las convenciones del lenguaje estructurado pero sin llegar a la
sintaxis en detalle d ningn lenguaje de programacin en particular. Esta notacin casi-
cdigo se conoce como pseudocdigo [5.5] (en ingls, pseudocode).
Para especificar un programa en pseudocdigo debemos ser capaces de manejar la
inicializacin y la terminacin, leer y grabar los archivos, manejar fin de archivo y especificar
contadores y seales. As, si el diseador fsico ha decidido que GENERAR FACTURAS
deber ser un programa separado que lea un archivo llamado, digamos, EMBARQUES-
DIARIOS, el pseudocdigo para el nivel superior de la jerarqua del programa ser como
el de la Fig. 5.17.
105
www.FreeLibros.org
Inicializar el programa (abrir archivos, ajustar contadores)
leer ei primer registro-pedido
HACER-MIENTRAS haya ms registros-pedido
HACER-MIENTRAS haya mas tem en el pedido
Calcular total-item
Sumar total-item a total-factura
FIN-HACER
Calcular descuento
Calcular cargo por despacho y manipuleo
Calcular neto-factura, total-a-pagar
Imprimir factura
Grabar factura en archivo cuenias-a-cobrar
Sumar detalle-factura a contadores resumen
Leer prximo registro-pedido
FIN-HACER
Imprimir resumen de facturas del da
Terminar programa
Figura 5.17 Pseudocdigo del nivel superior.
En pseudocdigo distinguimos la estructura del lazo HACER-MIENTRAS (DO-
WHILE) respect de la estructura del lazo REPETIR-HASTA (REPEAT-UNTIL), la
cual tiene un significado especial. La estructura del lazo HACER-MIENTRAS implica que
la prueba de terminacin se hace antes de que se ejecute el cuerpo del lazo; la estructura
REPETIR-HASTA implica que el cuerpo del lazo es ejecutado antes de hacer la prueba. En
trminos de diagrama de flujo estas estructuras son
Condicin HACER-MIENTRAS Condicin REPETIR-HASTA
Hacer el
cuerpo
del lazo
FIN-HACER (END-DO)
106
www.FreeLibros.org
La diferencia importante es que en una situacin donde la condicin es distinta de la
esperada, la primera vez el lazo HACER-MIENTRAS no ejecuta el cuerpo de instruccio
nes, saltando directamente al FIN-HACER, mientras que el REPETIR-HASTA atravesar
el cuerpo de instrucciones antes de efectuar la prueba.y encontrar, por ejemplo, que no hay
pedidos que procesar. En lenguaje estructurado, donde'especificamos una lgica no fsica, no
nos preocupa esta distincin. En el pseudocdigo, donde estamos desarrollando la lgica
del programa, debemos tener mucho cuidado.
El programa consiste de un lazo HACER-MIENTRAS dentro de otro lazo HACER-
MIENTRAS, donde el lazo externo procesa cada registro de pedido. El diseador ha
especificado que despus de la inicializacin el programa deber leer el primer registro del
archivo de pedidos, de manera que en el caso que no existan pedidos en el archivo, la prueba
de HACER-MIENTRAS fallar de entrada, el control saltar al FIN-HACER externo, no
se imprimir ningn resumen y el programa terminar normalmente.
Vemos, por lo tanto, que el pseudocdigo representa un diseo de programa muy
detallado. Especialmente en un entorno donde todas las estructuras de datos y elementos de
datos estn definidos en un diccionario de datos legible por mquina, la tarea de traducir el
pseudocdigo al COBOL o al BASIC-PLUS, digamos por ejemplo, es relativamente
simple. A partir del lenguaje estructurado, en cambio, debern tomarse varias decisiones
importantes sobre el diseo fsico antes de que pueda escribirse un programa, ya que el
lenguaje estructurado representa solamente la lgica externa.
5.4.4 "Lenguaje comprimido" lgicamente
Comentbamos que las convenciones de lenguaje estructurado, al mismo tiempo que
produce una exposicin precisa y completa, abarca muchas palabras y una notacin muy
poco comn, como para resultar ideal en una presentacin a los usuarios. Esto nos lleva a
preguntarnos si es posible obtener los beneficios del rigor del lenguaje estructurado, sin sus
desventajas. Una vez que se comprenden las razones por las cuales el lenguaje estructurado
elimina las ambigedades y la falta de integridad, podemos desechar las partes molestas de la
notacin y escribir en un estilo equivalente de castellano, que sea comprimido lgicamente,
en el sentido de reflejar un anlisis preciso y completo. La Fig. 5.8 muestra el proceso
generar facturas escrito en lenguaje comprimido.
Es admisible incluir rboles de decisin en una descripcin en lenguaje comprimido, si se
tiene la seguridad que ser comprensible para cualquiera que utilice el documento. El
lenguaje comprimido es familiar en su apariencia, y estructuralmente resulta equivalente al
lenguaje estructurado. La irona es que resulta difcil de escribir hasta tanto la lgica del
proceso no haya sido resuelta en idioma estructurado y entendida en detalle en funcin de las
cuatro estructuras (secuencia, decisin, caso y repeticin).
Podemos resumir las convenciones del idioma comprimido como sigue:
1. Las operaciones secuenciales se presentan como instrucciones imperativas que se
deben cumplir rutinariamente.
2. Las estructuras SI-LUEGO-SI NO-ENTONCES se representan con notacin
decimal y con sangra para mostrar cmo se' anidan entre s, por ejemplo
5.
5.1
5.1.1 f
5.1.1a
Tambin pueden representarse como rboles de decisin.
3. Las condiciones SI NO se representan como Para (explicacin de la condicin).
4. Las estructuras de casos se representan como tablas.
107
www.FreeLibros.org
Para generar una factura:
Paso 1: Calcular el total de la factura de la siguiente forma:
1.1 Tomar cada linea de la factura y multiplicar la cantidad del tem por el orecio
unitario para obtener el total det Item
1.2 Sumar los totales de tem para obtener el total de la factura.
Paso 2: Calcular el descuento (si hay alguno).
El valor del descuento est basado en el total de la factura de acuerdo con la siguiente
tabla:
Factura total % Descuento
Menor que $100 No
Mayor que $100 pero
menor que $250 1%
Mayor que $250 pero
menor que $1.000 2 1/2%
Mayor que $1.000 5%
Restar el descuento del total de la factura para obtener el importe neto de la factura.
Paso 3: Calcular el cargo por despacho y manipuleo (D&M).
{D&M) est basado en unidades* cada una cuesta actualmente 50 centavos
Los pedidos especifican el flete areo o terrestre: cuando no se especifica flete, la
omisin se considera flete terrestre.
3.1 Para los pedidos que especifican flete areo:
Hasta 2 libras incluida: tarifa 6 unidades fijas
Ms de 2 pero menor que 20: 3u/lb.
20 libras o ms: 60 unidades + 2 unidades por cada libra que exceda tas 20.
3.2 Para los pedidos que especifican flete terrestre (o que no especifican ningn
mtodo):
3.2.1 Para destinatarios locales:
a. Para servicio expreso: 2 u/lb
b. Para servicio normal: 1 iVlb
3.2.2 Para destinatarios externos al rea local:
& Para servicio expreso
peso mayor que 20 Ib: 2 u/lb
peso menor o igual que 20 Ib: 3 u/lb
b. Para servicio normal 2 u/ib
Figura 5.18 Lenguaje comprimido.
5. Cuando se incluyen condiciones genuinas de excepcin, la estructura( ver Sec. 5.1.1)
Accin-1 salvo condicin en cuyo caso Accin-2 podr utilizarse por razones de claridad.
. As cuando escribimos el resumen de la lgica para el proceso en el diccionario de datos
(que repetmos ms adelante) ser suficiente emplear lenguaje comprimido con clusulas
salvo o a menos que (unless) para explicar el manejo de las excepciones. El lenguaje
comprimido utilizado en Verificar si crdito es OK fue escrito como un resumen del
lenguaje estructurado, el cual expresa todos los detalles de la lgica. La Fig. 5.19 muestra el
lenguaje estructurado completo para Verificar si crdito es OK.
www.FreeLibros.org
| V | E | * | i | f 1' Ic 1 * I * I - | | * | | 0 | i r | 0 | - | > t K | 1 1 1 | 1 I I 1 1 1 Proceso ref:
previo odQO. o s i de&e ItaMriiKfti A ? c'tdr adonck se embarcan los pedidos sin
reouerfrse a i cliente osan previo
Entradas Resumen de lgica Salidas
y - 3 R e t e o s
Z>3 *3 Historia de pago
FECHA - APERTURA-CUENTA
FACTURA *
P A GO*
BALANCE - E N - ORPEN
Re fsica- Prte, de b ent>
Recuperar historie de poyo
S i ei cliente es nuevo, enviar
pedido dep*$oprevio.
S i es diente corriente.
(promedio dedosp>edidos
mensuales)
0K e l pedido, a menos que
ef balance este sencido con
mas de 2 meses.
Para dientes anteriores
que no sean corrientes, OK
los pedidos, a menos que
tengan cualquier alance
vencido.
da d e l pedido en lnea. 0
3-C Pedido depago previo
lRecordatorio de balance]
3 -03 Huevo balance en orden
3 -6 Pedidos con crdito OK
7 0 7
Detalles completos de eta lgica se pueden encnnltar sp>ec;/7cacin func/onal, Seccin ?. 2
I .......... . ' . . 11 - J
Nombre del proceso: VERIFICAR SI CREDITO ES OK Ref:3
Por cada pedido:
Recuperar historia-de-pagos
SI historia-de-pagos no se encuentra (nuevo cliente)
LUEGO generar requerimiento-de-prepago
SI NO (cliente existente)
ENTONCES calcular frecuencia-Dromedio-de-pedido
(cantidad promedio de pedidos por mes de los ltimos
tres meses)
calcular saldo total vencido
SI frecuencia-promedio-de-pedido es MQ 2.0
(cliente regular)
y-SI antig edad del saldo vencido ms antiguo
es mQ60 das
LUEGO calificar pedido OK para crdito trasmitir
flujo de datos 3-6
(pedidos con crdito OK)
SI NO (saldo vencido MI60 das)
ENTONCES generar requerimiento-de-prepago ms
recordatorio-de-saldo-vencido
SI NO (cliente no regular)
y-SI saldo vencido es MQ cero
LUEGO generar requerimiento-de-prepago
SI NO (sin daldo deudor)
ENTONCES calificar pedido OK para crdito trasmitir
flujo de datos 3-6 (pedidos con crdito OK)
Figura 5,19 Lenguaje estructurado.
5.4.5 Pros y contras de las cuatro herramientas
La tabla 5.1 resume las fuerzas y debilidades relativas de las cuatro herramientas para
lgica de procesos que hemos discutido en este capitulo. La tabla compara las cuatro
herramientas lgicas en funcin de ocho consideraciones. Estas consideraciones pueden
agruparse en tres reas bsicas:
109 www.FreeLibros.org
1. Cuto fciles de usar son las herramientas para el analista? Se tabularon tres
consideraciones: verificacin de la lgica, representacin (de la) estructura lgica y
simplicidad. Verificacin d la lgica describe la facilidad con la quecada herramienta
asegura que se han cubierto todas las posibilidades lgicas. Representacin estructura
lgica describe hasta qu punto cada herramienta provee una representacin grfica de los
cuatro tipos bsicos de estructura (secuencia, decisin, lazo y caso). Simplicidad evala,
para cada herramienta, la facilidad o dificultad para aprender cmo utilizarla.
2. Cun fciles de usar son las herramientas para la comunidad de usuarios? Las
evaluaciones de verificacin del usuario se refieren a esto.
3. Cun fciles de usar son las herramientas para el diseador/programadoi? El
encabezamiento especificacin del programa describe la adaptabilidad de cada herramien
ta para este propsito. Las consideraciones de legible por mquina y editable por
mquina describen la facilidad con que cada herramienta podr ser procesada por un
compaginador de texto y la facilidad con que podr emplearse un paquete de software para
verificar la consistencia y sintxis de la lgica. Cambiabilidad describe la facilidad con la
cual la herramienta permite cambiar la lgica debido, por ejemplo, a que se han modificado
los requerimientos del usuario.
Tabla 5.1 Comparacin de las herramientas
para las estructuras de proceso.
Uso
Arboles de
decisin
Tablas de
decisin
Lenguaje
estructurado
Lenguaje
comprimido
Verificacin
de la lgica Moderada Muy buena Buena Moderada
Representacin
de la estructura
lgica
Muy buena
(pero solo
decisin)
Moderada
(solo decisin)
Buena
(todo)
Moderada
(toda pero
dependiendo
del autor)
Simplicidad (fa
cilidad de uso) Muy buena Muy pobre a pobre Moderada Buen
Verificacin
del usuario
Buena Pobre (a me
mos que el
usuario est
capacitado)
Pobre a mo
derada (lige
ramente jer
ga)
Buena
Especificacin
de programa Moderada Muy buena Muy buena Moderada
legibilidad por
mquina Pobre Muy buena Muy buena Muy buena
Validacin por
mquina
Pobre Muy buena Moderada
(necesita
sintxis)
Pobre
Cambiabilidad Moderada Pobre
(a menos
que se trate
de modificacin
de reglas
sencillas)
Buena Buena
Podemos resumir, a partir de la tabla, las situaciones ms convenientes para utilizar cada
herramienta:
Arboles de decisin se usan mejor para verificaciones de lgica o decisiones
na
www.FreeLibros.org
moderadamente complejas de 10-15 acciones. Los rboles de decisin tambin son tiles
para presentar a los usuarios la lgica de una tabla de decisin.
Tablas de decisin se usan mejor en problemas que involucran combinaciones
complejas de hasta 5-6 condiciones. Las tablas de decisin pueden manejar cualquier
cantidad de acciones; un gran nmero de combinaciones de condiciones puede hacer
incmodo operar con tablas de decisin.
Lenguaje estructurado se usa mejor cuando el problema comprende la combinacin de
secuencias de acciones con decisiones o lazos.
Lenguaje comprimido se usa mejor en la presentacin de una lgica moderadamente
compleja, una vez que el analista est seguro de que no pueden aparecer ambigedades.
5.4.6 Quin hace qu?
A lo largo de este libro hemos distinguido los tres papeles de analista, diseador y
programador:
1. El analista establece las especificaciones funcionales lgicas.
2. El diseador especifica cmo debe ensamblarse o armarse el sistema para satisfacer
los requerimientos lgicos.
3. El programador implementa las especificaciones del diseador.
Hemos dicho que estos papeles pueden ser desempeados por una sola persona (el caso
de un proyecto pequeo); por dos o tres personas, 9 por un equipo. El estilo de administracin
de proyectos de cada organizacin y la capacidad del personal disponible indicarn quin
desempea cada funcin en el proyecto. Uno de los puntos ms discutidos en la divisin del
trabajo es Quin escribe la lgica en detalle? Tenemos claro que el papel del analista no
incluye la escritura del pseudocdigo; esto es fsico y deber ser hecho por el diseador o
por el programador. Pero corresponde al papel del analista escribir en lenguaje estructurado
o deber limitarse a los rboles de decisin y probablemente'al lenguaje comprimido, dejando
el anlisis detallado de la lgica a los diseadores/programadores? Por un lado, el analista es
la persona que est en contacto ms estrecho con las actividades de la organizacin y con los
detalles de la lgica; por otra parte muchos programadores encuentran satisfaccin en el
trabajo de resolver el detalle de la lgica a partir de un claro pero conciso resumen lgico como
el de la entrada del diccionario de datos; y en cambio cuando se les entregan definiciones de
estructuras de datos y lenguaje estructurado, gritan Me estn convirtiendo en un mero
codificador!
Adoptamos la solucin de compromiso, esto es, que el analista deber estar entrenado y
encontrarse cmodo con las tablas de decisin y el lenguaje estructurado, pero los deber
utilizar como herramientas de ltimo recurso para poder llegar al fondo de un proceso
complejo. El analista normalmente presentar la lgica del proceso al diseador/programa
dor en forma de rboles de decisin o lenguaje comprimido (las cuales, felizmente, son
tambin las herramientas ms tiles para comunicarse con los usuarios). Si el diseador o el
programador los requiere, el analista deber estar preparado para proveer tablas de decisin
o lenguaje estructurado. La prueba deber ser siempre es esta exposicin lgica suficiente
mente clara como para poder escribir un programa a partir de ella?
BIBLIOGRAFIA
5.1 G. E. Whitehouse, Systems Analysis and Design Using Network Techniques, Prentice-HaU,
Englewood Cliffs, N.J., 1973.
5.2 S. L. Pollack, H. T. Hicks, y W. J. Harrison, Decisin Tables: Theory and practice, New York,
1971.
111
www.FreeLibros.org
5.3 K. R. London, Decisin Tables, Auerbach, Philadelphia, Pa., 1972.
5.4 C. B6hm y G. Jacopini, Fkw Diagrama, Turing Machines, and Languages with Only Two
Formulation Rules, Communications q f the ACM, mayo de 1966.
5.5 P. Van Leer,Top-downDevelopmentUsingaProgram Des\gflCa.ng[iag,e, IBM Systems Journal,
VoL 15, N 2, 1976.
Ejercicios y puntos de discusin
1. Aplicar la prueba de indiferencia a la tabla de decisin extendida de la Fig. 5.13.
2. Convertir a lenguaje estructurado la tabla de decisin realizada en el ejercicio anterior.
3. La descripcin siguiente corresponde al procedimiento seguido por el personal administrativo en el
depsito de un distribuidor de repuestos elctricos:
Al recibirse un pedido del Departamento de Ventas verificar si cada tem puede atenderse con el
inventario corriente. Si se dispone de inventario suficiente, el empleado del depsito ajusta los
registros de stock y trasfiere el Item para su recoleccin y despacho. Cada vez que los registros de
stock se modifican, el nuevo nivel de inventario se compara con el nivel de reposicin que est
asentado en la taijeta de inventario del tem. Si el nuevo nivel de inventario fuera menor que el nivel de
reposicin, el empleado del depsito llena un formulario de orden de compra, registra la cantidad
pedida en la taijeta de inventario del item y eleva el formulario de la orden de compra al Jefe de
Compras para su aprobacin y despacho al proveedor.
Si hav existencia, pero insuficiente para atender el pedido (cumplimiento parcial), el empleado
del depsito despacha los tem disponibles, ajusta los registros de stock y confecciona un pedido
pendiente de entrega por la cantidad requerida. El pedido pendiente de entrega se archivaporordende
nmero de parte, a la espera de la recepcinde un embarque. Si el item va fue solicitado, el empleado
del depsito remite al Jefe de Compras un aviso de pronta entrega. Si el tem no fue pedido, se prepara
un formulario de orden de compra.
Si no hay existencia del item, se confecciona un pedido pendiente de entrega, el cual se archiva
de la forma ya indicada, y el empleado remite un aviso de pronta entrega al Jefe de Compras, est ano
pedido el item.
Dibuje una tabla de decisin para indicar la lgica de este proceso. Cuando disponga de la tabla de
decisin, presente la lgica en un rbol de decisin, y escrbala tambin en formato de lenguqje es
tructurado. Confeccione un conjunto de instrucciones, utilizando el lenguaje comprimido, para un
empleado de depsito recientemente incorporado, y para verificar su claridad revselas con un em
pleado administrativo.
4. Tome un programa que tenga una lgica medianamente compleja, y escriba la seccin lgica en
pseudocdigo. Esto le ayuda a comprender el programa'?
5. Existe una cantidad de paquetes de software que convierten tablas de decisin directamente a
codificacin. A su juicio por qu estos paquetes no tienen hoy un uso ms amplio?
6. Si puede utilizar un software de procesamiento de tablas de decisin convierta la tabla de decisin de
la tarifa del flete desarrollada en el Ejercicio 1 a codificacin COBOL. Compare la salida con el
lenguaje estructurado realizado en el Ejercicio 2.
7. La prxima vez que tenga que escribir un memorndum que contenga la palabra si, redctelo
primero en lenguaje estructurado y luego convirtalo a lenguaje comprimido.
8. Si su empresa tuviera un plan de jubilaciones, analice la descripcin de la poltica que especifica el
monto de la jubilacin, recurriendo a las herramientas lgicas descritas en este captulo. Cul es la
representacin ms fcil de entender?
112
www.FreeLibros.org
6
DEFINIR EL CONTENIDO DE LOS
ALMACENAMIENTOS DE DATOS
6.1 LO QUE SALE DEBE ENTRAR
Como se indic en el Captulo 2, una vez que hemos especificado las estructuras de los
datos en los flujos de datos que salen de un almacenamiento de datos, sabemos cul deber
ser el contenido mnimo de ese almacenamiento de datos. Para que un elemento de datos
pueda ser extrado, en primer lugar deber ser introducido en el almacenamiento. Podemos
pues examinar los detalles de los flujos de datos que ingresan al almacenamiento de datos para
Controlar que se almacenen todos los elementos necesarios y para observar si algn dato a
almacenar no va a ser usado nunca.
La Fig. 6.1 muestra parte de un flujo de datos de un sistema de personal.
Podemos ver, a partir de la naturaleza de los flujos de datos y los procesos relacionados
que el almacenamiento de datos D5: EMPLEADOS-DETALLES debe contener la
; informacin de todos los empleados, sus nombres, direcciones y salarios. Pero qu significa
sto en detalle? Podemos buscar cada uno de los cinco flujos de datos en el diccionario de
datos para encontrar sus estructuras de datos componentes y buscar las estructuras de datos
para hallar sus contenidos. Luego podemos comparar los contenidos de los flujos que entran
en los almacenamientos de datos con los flujos que salen de los mismos, los que podrn ser
pomo se muestra en la Fig. 6.2.
El prximo paso es hacer un borrador con el contenido de D5, basado en nuestro anlisis
de flujos de entrada y salida. Un primer intento podr ser el que se muestra en la Fig. 6.3.
Comparando los flujos de salida con los de entrada, observamos los siguientes detalles:
1. EMPLEADO-DIRECCION claramente requiere detalles de la direccin actual,
mientras qu DIRECCION-CAMBIO implica que la direccin anterior tambin est
almacenada. Es necesario? Alguna vez se desea saber la direccin anterior del empleado?
No en los flujos de salida listados aqu, por lo menos.
2. EMPLEO-HISTORIA, por otro lado, requiere un listado de todos los distintos
salarios percibidos por un empleado a travs de su carrera, de manera que necesitaremos
almacenar una cantidad variable de pares de salarios y fechas, y no solamente SALARIO-
ANTERIOR y SALARIO-ACTUAL, como requiere la estructura de SALARIO-CAM
BIOS.
3. EMPLEO-HISTORIA requiere un almacenamiento de datos similar a SALARIO-
HISTORIA. Pero no tenemos definido el flujo de datos para introducir cambios en TA
REA-DENOMINACION! Segn se ve en la Fig. 6.2, un nuevo empleado tiene una
TAREA-DENOMINACION cuando ingresa y nunca la va a cambiar. Comparando los
flujos de entrada y salida aparece una omisin realmente seria en el diagrama de flujo de
113
www.FreeLibros.org
D5
f 17 1
Nuevos
Modificacin
f " 19 'N
Mantener
empleados.eeses, salarios
Procesar
datos cambios
empleados
de direccin
aumentos
V J
v y
Autorizaciones
de aumentos
EMPLEADOS-DETALLES
18
Generar listas
de direcciones
postales para
revista
\emoresana;
Direcciones Detalles
de empleados de salarios
Historia
de empleados
T
F i g u r a 6,1 Diagrama de flujo parcial de un sistema de personal.
Estructura de datos contenida en:
Flujos entrantes a 05
NUEVO-EMPLEADO (17-D5)
FECHA-INGRESO
NOMBRE
EMPLEAOO-N
DIRECCION
TAREA-DENOMINACION
SALARIO-INICIAL
CESANTIAS (17-05)
NOMBRE
EMPLEADO-N5
DIRECCION-CAMBIO (17-05)
NOMBRE
EMPLEADO-N
OIRECCIO'N-ANTERIOR
DIRECCION-ACTUAL
SALARIO-MODIFICACION
NOMBRE
EMPLEADO-N
SALARIO-ANTERIOR
SALARIO-ACTUAL
FECHA-EFECTIVA
19-05)
Flujos salientes de D5
EMPLEADO-DIRECCION (05-018)
NOMBRE
DIRECCION
SALARIO-OETALLES (05-020)
NOMBRE
EMPLEADO-N
SALARIO-ACTUAL
EMPLEADO-HISTORIA (05-021)
NOMBRE
EMPLEAOO-N"
FECHA-INGRESO
TAREA-HISTORIA*
TAREA-DENOMINACION
FECHA-EFECTIVA
SALARIO-HISTORIA*
SALARIO
FECHA-EFECTIVA
[REVISION-RESUMEN]
Para todos
los emplea
dos de la
organiza
cin
Figura 6.2 Flujos entrantes y salientes de D5.
www.FreeLibros.org
Estructura de datos I Elemento
NOMBRE
EMPI.EAOO-N
DIRECCION
SALARIO-ACTUAL
FECHA-INGRESO
TAREA-HISTORIA *
TAREA-DENOMINACION
FECHA-EFECTIVA
SALARIO-HISTORIA"
SALARIO
FECHA-EFECTIVA
[REVISION-RESUMEN!
Figura 6.3 Estructura de D5 (primer borrador).
datos, que debemos corregir inmediatamente, junto con algunas redundancias menores en
algunas estructuras de datos. Un comentario similar se aplica a REVISION-RESUMEN.
Para ver la realidad que reflejan las estructuras de datos, vamos a indicar algunos
ejemplos del contenido, como se muestra en la Fig. 6.4. Examinando las historias de empleo
de estas tres personas, vemos que un cambio de tarea normalmente (pero no siempre) implica
un cambio de salario. Como ejemplo de una excepcin a esta regla, Jones fue ascendido a
supervisor el 08/01/76,sin aumento. Observamos tambin que cada empleado es objeto de
una revisin en el aniversario de haber sido contratado y que el resultado de la misma se
expresa como un nico valor (una evaluacin compuesta en una escala 0-5).
Contenidos de muestra de D5: EMPLEAOO-DETALLES
NOMBRE '
EMPLEADO DIRECCION SALARIO
FECHA TAREA-HISTORIA SAlAfHd-HfSTORIA
NUMERO ACTUAL INGRESO TAREA OENOM.
SALAR. FECHA-EFEC. REV.
FECHA EFECTIVA
RES.
. John P. Jones 26622 15 Corona Dr 18200 12/01/74 Supervisor 08/0 1 '76 18200 12/01/76 4.0
New York NY 1Q077
Prog, sen". 04/16/75
Programador ,!,0,/74
15250 12/01/75 3 5
14500
12750
04/15/75
12/01/74
*iry' A Worth 30604 2221 W 54 21250 06/15/73 Gerente 11/01/75 21250 06/15.76 45
Paterson NJ 07070 Jefe Turno 12/15/74 19000 11/0175 4.8
16500 06 15 75
Operador 07.0 1 -74 14000 12*15/74
Mecangrafo 06n5/73
9500 06 7 5.74 4,5
8500 C6 15/73
Edwrd P Dulson 20927 491 East Highway 8500 01/01/76 Empleado de 01/01, 75 8500 01 01-76 2.8
New York NY 10066
correo
8250 01/01/75
Figura 6.4 Ejemplo del contenido de D5: EMPLEADO-DETALLE.
115
www.FreeLibros.org
6.2 SIMPLIFICACION DEL CONTENIDO DEL ALMACENAMIENTO DE DATOS
MEDIANTE INSPECCION
Puede simplificarse' este primer borrador de la estructura? Primero veamos qu
podemos hacer aplicando solo el sentido comn. Podemos observar de inmediato alguna
duplicacin de datos. SALARIO-ACTUAL ser siempre el valor ms reciente de
SALARIO-HISTORIA. Entonces, por qu debemos almacenarlo como elemento de datos
separado? En forma similar, FECHA-INGRESO siempre ser el dato ms temprano, tanto
en TAREA-HISTORIA como en SALARIO-HISTORIA, entonces, por qu conservarlo
en forma separada? Esta observacin sugiere una simplificacin muy importante: como
varios datos en TAREA-HISTORIA y SALARIO-HISTORIA son los mismos, podemos
hacer una estructura de datos compuesta en base a TAREA-HISTORIA y SALARIO-
HISTORIA, llamada SALARIO-TAREA-HISTORIA y hacerle una entrada todas las
veces que cambie la tarea o el salario. La estructura puede definirse como
SALARIO-TAREA-HISTORIA*
FECHA-DE-CAMBIO
TAREA-DENOMINACION
[SALARIO-RE SUMEN]
y para el seor Jones, su contenido ser
Fecha-Del-Cambio Tarea-Denominacin Salario Revisin-Resumen
12/01/76 Supervisor 18200 4,0
08/01/76 Supervisor 15250
12/01/75 Programador Snior 15250 3,5
04/05/75 Programador Snior 14500
12/01/74 Programador 12750
Es justo decir que esta simplificacin de la estructura se hace al precio de una lgica
ligeramente ms compleja en algunos procesos subsiguientes. Por ejemplo, en el proceso 20
Producir listado salarios debemos hacer algo ms que recuperar nombre, nmero de
empleado y salario actual (como vimos en el primer borrador). Se deber buscar la entrada
ms reciente del grupo repetitivo SALARIO-TAREA-HISTORIA y extraer de all el salario
actuaL Sin embargo, lo que perdemos en movimientos, lo ahorraremos con creces en rodeos o ,
desvos. Volviendo a la pequea lgica adicional del proceso hemos obtenido tres ventajas:
1. Tenemos un almacenamiento de datos ms simple y pequeo. !
2. Cada vez que cambie SALARIO-ACTUAL, solo se tiene que registrar en un solo
lugar en lugar de dos, como se ve en el borrador original. Esto reduce la posibilidad de que las
dos entradas se desfasen, ya sea porque alguien se olvid de realizar ambos cambios (en un
archivo manual) o por que un error del hardware haga que una se actualice y la otra na
Hacemos notar como un principio general que la redundancia (duplicacin, triplicacin, etc.)
aumenta el riesgo de error.
3. Tenemos mayor seguridad contra el cambio. Consideremos el proceso 21 Producir
perfil individual. La estructura de los flujos de datos de la Fig. 6.2 implica que el usuario
quiere por separado los informes de la historia de tareas y la historia de salarios; por eso se ve
el primer borrador del almacenamiento de datos de esa manera. Pero qu sucede si el usuario
cambia de idea y quiere un listado combinado con los cambios de tarea y de salario ordenados
por fecha? Con la estructura original, la lgica del proceso deber hacer la combinacin y
clasificacin; con la nueva estructura simplificada, el procesamiento ser casi trivial.
116
www.FreeLibros.org
Tanto para los sistemas manuales como para los computerizados comnmente es ms
fcil y ms barato modificar la lgica de un proceso que modificar la estructura de un
almacenamiento de datos, En consecuencia, cuanto ms simple y ms general sea la
estructura de un almacenamiento de datos, tent ms fcil y ms barato resultar hacer
cambios en los datos.
6.3 SIMPLIFICACION DEL CONTENIDO DEL ALMACENAMIENTO DE DATOS
MEDIANTE LA NORMALIZACION
En la seccin anterior hemos simplificado el contenido del almacenamiento de datos
buscando y eliminando los elemente de datSs redundantes. Se puede obtener un nivel adicio
nal de simplificacin reorganizando el contenido para eliminar los grupos repetitivos, proceso
que se conoce con el nombre de normalizacin.
Despus de eliminar la redundancia, el contenido de D5 tiene la estructura
NOMBRE
EMPLEADO N
DIRECCION
SALARIO-TAREA-HISTORIA*
FECHA-DEI^CAMBIO
TAREA-DENOMINACION
SALARIO
[REVISION-RESUMEN]
Cmo podemos libramos del grupo repetitivo SALARIO-TAREA-HISTORIA? El nico
camino es dividir la estructura en dos, las cuales sern, ambas, ms simples. Se llega as a una
estructura que contiene nombre y direccin ( lo que ocurre solo una vez por cada empleado y a
otra que contiene cada cambio de tarea o salario (lo que puede ocurrir varias veces por
empleado). Cada estructura deber contener EMPLEADO-N, el nico elemento de datos
que especifica unvocamente a cada empleado. Ver Fig. 6.5.
D5: EMPLEADO-DETALLE EMPLEADO-DOMICILIO
NOMBRE
t = >
EMPLEADO-N
EMPLEADO-N NOMBRE
DIRECCION
SALARIO-TAREA-HISTORIA*
FECHA-DEL-CAMBIO
DIRECCION
TAREA-DENOMINACION SALARIO-TAREA-HISTORIA
SALARIO EMPLEADO-N
[REVISION-RESUMEN] FECHA-DEL-CAMBIO
TAREA-DENOMINACION
SALARIO
[REVISION-RESUMEN]
Estructura sin normalizar Dos estructuras normalizadas
Figura 6.5 Normalizacin.
La Fig. 6.6 muestra cmo se pres enta ahora el contenido del almacenamiento de datos de
los tres empleados que se vieron en la Fig. (j.4. Se invite al lector a verificar que textos los
flujos de datos listados en la Fig 6.2 como salientes del almacenamiento de date, pueden
obtenerse en base a las estructuras de la Fig 6.6, mediante una apropiada seleccin de los
elementos de datos.
117
www.FreeLibros.org
EMPLEADO-DOMICILIO
(EMPLEADO-*,
20927
26622
30604
NOMBRE, DIRECCION)
Ed'Dullson 492 E. Highway, New York, N Y 10066
John P. Jones 15 Corona Dr, New York, N Y 10077
Mary A. Worth 2221 W 54, Peterson, NJ 07070
SALARIO-TARE A-HISTORIA
(EMPLEADO-*, FECHA-DEL-CAMBIO, TAREA-DENOMINACION, SALARIO, REVISION-RESUMEN)
20927 01/01/76 Empleado de correos 6500 2.8
20927 01/01/75 Empleado de correos 8250
-
26622 12/01/76 Supervisor 18200 4.0
26622 08/01/76 Supervisor 15250
CUENTE
Cliente-N"
Cliente-nombre
Direccin j
PROPUESTA
Cliente-N
Propuesta-fecha
Componentes
f Cantidad $
I Uso-final-tipo "j
j.----------------- j
I Pedido-fecha I
|------------------j
I I
j Componentes j
P Cantidad $ j
Uso-final-tipo
V ---------------j
Envfo-fecha-planficada
I Envio-fecha-real I
r ------------- 1
Figura 7.5 Las flechas indican los accesos inmediatos.
150
www.FreeLibros.org
podemos incluir el nmero de VENDEDOR como un atributo de cada PEDIDO y crear un
ndice secundario. Por ahora no nos interesa cual.
El usuario pide algunos accesos que implican solamente la recuperacin de una entidad
basada en su atributo clave. El requerimiento del gerente de ventas para tener acceso a las
comisiones de cada vendedor podra ser el siguiente: dado el nmero del vendedor, debe
poder recuperarse el registro especificado, que incluye la comisin. No es necesario indicar
especficamente un requerimiento como ste pues surge de la presencia del atributo.
Por otra parte, cuando una entidad deba ser recuperada, basndose en un atributo no-
clave (la situacin del ndice secundario discutido en la Sec. 7.2), debemos indicar este hecho
para la creacin de una nueva entidad a partir del atributo. Por ejemplo, supongamos que el
gerente de ventas desea acceso a cada vendedor por el nombre en lugar del nmero; se deber
indicar este hecho como se muestra en la Fig. 7.6.
El requerimiento del contralor tambin puede representarse de esta manera, ya que
consiste en tener acceso a PEDIDOs sobre la base de un atributo no-clave de PEDIDOs. La
Fig. 7.7 muestra el agregado de este camino de acceso inmediato.
VENDEDOR
NOMBRE
Mostrando esto
como una entidad separada se
indica que se puede tener acceso a
esto basado en
este atributo
Direccin
Territorio ]
Comisiones I
CUENTE PROPUESTA
Cliente-N Cliente-N"
Propuesta-fecha
Cliente-nombre
| Direccin
Componentes
L
PEDIDO
Cliente-N0
Pedido-fecha
j Componentes
[~ Cantidad $
j Uso-final-tipo
|Envio-fecha-planificado
j Envio-fecha-real
I------------------
------------------i i Cantidad S I
j i-------------------- i
| Uso-final-tipo j
{" Pedido-fecha "|
h--------------------i
I . I
Figura 7.6 Diagrama de Datos de Acceso Inmediato, mostrando parte de los requerimientos del
gerente de ventas.
La Fig. 7.8 muestra el conjunto completo de consultas que representan la surta total de las
listas de deseos del contralor, gerente de ventas, gerente de planeamiento d productos y
supervisor administrativo de ventas.
www.FreeLibros.org
Figura 7,7 Diagrama de Datos de Acceso Inmediato con los requerimientos del contralor,
agregados.
7.5.3 Refinacin del listado de deseos %
Si no se objeta el presupuesto del proyecto y si cada gerente usuario expresa una fuerte
necesidad de acceso inmediato, la nica informacin adicional que necesitar el analista es la
frecuencia probable de cada acceso. A menudo, sin embargo, no todos los pedidos podrn ser
satisfechos a bajo costo. Entonces el analista deber enfrentar el problema de resolver cules
accesos son menos valiosos y pueden ser degradados a una respuesta nocturna. Una forma de
hacerlo es presentando el diagrama de acceso inmediato por tumo a cada usuario, para
discutir el significado de todos los diversos accesos. Aunque algunos de ellos no sern de
inters para algn gerente, es importante mostrar la descripcin completa a todos los
responsables de tomar decisiones, explicando cmo cada acceso adicional aumenta el costo
del sistema. Esta presentacin, si se hace con mucho tacto, estimular la imaginacin de los
gerentes para los posibles usos del sistema, a la vez que minimizar las posibilidades de
friccin y de desilusin, en el caso que el sistema final no cumpla con toda la lista de pedidos
del ejecutivo.
La presentacin de un diagrama de datos de acceso inmediato puede ser seguido por un
cuestionario que normalmente es llenado por el analista en conversacin con cada gerente. La
Fig. 7.9 muestra unas notas breves realizadas por un analista para explicar este cuestionario,
y la Fig. 7.10 muestra el ejemplo de una pgina del cuestionario para Sunray Engineering.
Las preguntas estn encuadradas para que cada gerente pueda poner lo ms rpido y
fcilmente posible un valor aproximado a cada respuesta y dar una idea de la frecuencia
152
www.FreeLibros.org
VENDEDOR
USO-FINAl-TIPO COMPONENTES S-CANTIDAO
NOMBRE
Componentes
Cantidad $ "j
Uso-final-tipo |
Envlo-fecha-planlicada|
Envo-fecha-real j
ENVIO-FECHA
PLANIFICADA
Figura 7.8 Diagrama de Datos de Acceso Inmediato compuesto, de Sunray Engineering.
Estamos en el proceso de decisin acerca del costo-efectividad de distintos dispositivos de un
sistema integrado de comercializacin. De la informacin que usted y otros gerentes entreguen,
redactaremos una !ista de todas las posibles consultas de informacin que se pueden formular al
sistema Serla de mi agrado revisarlas con usted, ver cules encuentra Otiles y qu cl^se de uso
podr hacer de ellas cuando el sistema est disponible.
Cada pedido de informacin ha sido especificado en funcin de cmo debe ser provista por el
sistema (en un formulario de consulta o tecleada en una terminal), y cmo se la devolver el
sistema Por ejemplo, podr dar al sistema "Cliente nmero y desear que le conteste Detalles de
la ltima factura. Por cada consulta, le solicito que me d una idea de cuntas veces desear
hacerla y una indicacin de qu valor tiene para usted obtener la respuesta al instante, como
alternativa de tener el informe a la mafiana siguiente, o como alternativa de disponer de un listado
para consulta (digamos los nombres y nmeros de clientes).
Estoy seguro de que usted sabe que cuesta mucho ms una respuesta inmediata, en segundos,
comparada con la preparacin de la respuesta durante la noche para entregarle un informe al da
siguiente, o con la provisin de un listado esttico. Debemos estar seguros de que no estamos
incorporando al sistema dispositivos lindos-para-tenet, de manera que para cada requerimiento
yo le preguntar cunto cree que vale para usted tener la respuesta al instante, suponiendo que la
podra tener maliana por la mafiana al costo de $1 (no le estoy diciendo que ste ser el costo, sino
que busca ser una medida del valor para usted). Por supuesto, si tiene que tener la informacin al
instante para su tarea, la pregunta carece de significado; por favor dgame si ste es su casa
Figura 7.9 Breves notas para el cuestionario de acceso inmediato.
153
www.FreeLibros.org
Nombre del Gerente _
Basado en este
Item que conoce...
Posicin_______
Desea que el
sistema le diga...
Fecha de la entrevista.
Cul es la frecuencia
media probable de este
tipo de consulta en
cuanto a usted
concierne?*
Nombre del vendedor Pedidos no despacha
dos de este vendedor
Nombre del vendedor Propuestas pendientes
de este vendedor
Nombre del cliente Pedidos no despachados
para este cliente
Nombre del cliente Historia de pedidos
despachados para este cliente
Nombre del cliente Propuestas pendientes
para este cliente
Dos fechas Todos los pedidos con
cualesquiera fecha de envo planifi
cada en este intervalo
Componente nmero Pedidos que utilizan
este componente, anali
zadas por mes
Analista
Si pudiera te
ner esta infor
macin maitana
por $1, aproxi
madamente cunto
valdra para
usted tenerla in
mediatamente?
1> t/min= muy alta, > 10/hora = alta > 10/da = mediana, > 10/semana = baja < 10/semana = muy baja
Figura 7.19 Ejemplo Sunray Engineermg.
probable. No se est tratando de comparar la importancia de una respuesta con respecto a las
otras, sino solo el valor relativo aproximado. A pesar de ello, los gerentes tienden a dar
valores ms altos a los accesos ms importantes; podrn agregar comentarios tales como No
lo necesito muy a menudo, pero cuando lo necesito, lo necesito pronto y a cualquier precio
(por ejemplo, un anlisis de la tarifa exitosa de la reciente propuesta, como guia para cotizar
en forma competitiva).
- Con accesos relacionados con datos que solo se rtiodi^can lentamente, tales como
recuperar el nmero del cliente dado el nombre del cliente, la alternativa est en comparar la
bsqueda de la respuesta en un listado, contra tener la respuesta presentada o impresa en una
terminal. Con 50 clientes el acceso a la terminal parecer un lujo; con 5000 clientes la
bsqueda en el listado podr insumir mucho tiempo. Le corresponde a cada gerente decidir
sobre el valor relativo que tiene la facilidad para l y su gente.
Cuando se han comparado los resultados de los cuestionarios de las entrevistas con cada
gerente, puede obtenerse por lo general una buena indicacin del valor global de cada
respuesta inmediata, junto a una indicacin de la frecuencia total probable de utilizacin. Si el
cuestionario no puede ser contestado con toda claridad debido a la gran variedad de usos .que
los gerentes pueden hacer de los datos, es muy posible que la solucin est dada por la
disponibilidad de un lenguaje general de consulta.
7.6 CONSIDERACIONES SOBRE SEGURIDAD
Mientras que la cuestin de seguridad de datos contra robo, destruccin o cambios
concierne al analista y al diseador en cada etapa del diseo [7.4j, la misma toma particular
importancia cuando se analizan los requerimientos de acceso inmediato. Los documentos
confidenciales generados por computadora pueden guardarse bajo llave y desmenuzarse
154
www.FreeLibros.org
cuando no se los requiere ms. Los datos confidenciales en un almacenamiento de datos al
que se ha provisto de acceso inmediato via terminal pueden a menos que se tomen
precauciones ser ledos por personas no autorizadas, sin dejar rastros.
En consecuencia, el analista deber establecer quin est autorizado para realizar cada
acceso. Por ejemplo, el gerente de ventas deber tener acceso a las comisiones ganadas por los
vendedores. Podr el supervisor administrativo de ventas tener tambin este acceso? Si se
dispusiera de un acceso a las propuestas pendientes y a sus importes en dlares, quin
detendra a alguna persona pagada por la competencia a que leyera esta informacin en un
CRT?
El diagrama de acceso inmediato y el cuestionario, una vez confeccionados, son tiles
como herramientas para considerar cada acceso por separado y decidir sobre los aspectos de
seguridad de cada acceso. Esta es una cuestin que el analista deber aclarar con la gerencia,
explicando que es posible, dado el software adecuado, permitir a determinadas personas
ver parte del almacenamiento de datos, pero no todo su contenido. Tambin podra ocurrir
que todas las terminales tengan acceso al nombre, direccin, telfono y territorio del
vendedor, pero que solamente algunos de los que utilizan la terminal en la oficina del gerente
de ventas, provistos de la palabra clave conocida solamente por el gerente de ventas, el
presidente y el contralor pudieran ver los importes de las comisiones individuales. La
gerencia podra decidir que un amplio grupo de personas pueda tener acceso a las estadsticas
de los importes en dlares correspondientes a las propuestas, pero que solo el vendedor de la
cuenta tenga acceso al importe especfico de una propuesta especfica.
APENDICE
Paquetes generales de consultas
CULPRIT-Cullinane Corporation - 20 William Street - Wellesley, MA 02181
EASYTRIEVE - Pansophic - 709 Enterprice Drive - Oakbrook, IL 60521
MARK IV - Informatics - 65, Route 4 - Riveredge, N.J. 07661
Esta no es una lista exhaustiva: Consultar otros paquetes en las publicaciones especializadas.
BIBLIOGRAFIA
7.1 IQF General Information Manual, GH20-1074, IBM Corp., White Plains, N.Y.
7.2 J. Martin, Principies o f Data-Base Management, Prentice-Hall, Englewood ClifFs, N.J., 1976,
Cap. 17. i
7.3 J. Martin, Computer Data-Base Organization, Prentice-Hall, Englewood Cliffs, N.J., 1975,
Cap. 5.
7.4 J. Martin, Security, Accuracy and Privacy in Computer Svstems, Prentice-Hall. Englewood Cliffs.
N.J., 1973.
Ejercicios y puntos de discusin
1. En los trminos de este captulo, qu relacin existe entre las pginas amarillas y las pginas blancas
de su guia telefnica? Es posible realizar otras inversiones de los datos de la gua telefnica?
2. Revise los sistemas de su empresa que clasifican o exploran archivos para producir informes. Existen
sistemas en los que sera deseable tener un ndice secundario y proveer acceso inmediato a los datos?
3. Si cualquiera de los sistemas de su empresa usa ndices secundarios, averige cul es la magnitud del
ndice comparado con el archivo principal. Con qu frecuencia se reorganiza el ndice? Se emplea
el ndice con fines operativos o informativos? Cuntos accesos se hacen en un da promedio?
4. Si tiene acceso a un archivo o base de datos jerrquicos, dibuje un diagrama de su estructura. Qu
previsiones hay que hacer para accesos que no descienden a travs del camino jerrquico?
5. Familiarcese con una de las facilidades de consulta general mencionadas en este capitulo. En las
155
www.FreeLibros.org
empresas que la han empleado, en cunto se ha aliviado la carga del departamento de programacin?
Qu factores limitan su uso ms amplio? Cuntos meses-hombre gast su empresa el ao pasado en
la confeccin de programas para informes por una nica vez?
6. Tome un sistema del que sepa que tiene accesos mltiples a los datos almacenados y describa cada
acceso en funcin de los tipos de la Sec. 7.4.
7. Dibuje un diagrama de datos de acceso inmediato del sistema (o de cualquier otro sistema que tenga
accesos inmediatos mltiples). Rena la informacin que pueda sobre el valor de los diversos accesos
a la empresa.
8. Hable con uno de los expertos en diseo de base de datos de su empresa y pregntele ael (o ella) qu
informacin le agradara, como ideal, que el analista de sistemas le proveyera para poder realizar el
diseo ptimo en lo que hace a costo-efectividad.
156
www.FreeLibros.org
8
EMPLEO DE LAS HERRAMIENTAS:
UNA METODOLOGIA ESTRUCTURADA
En los Captulos 3 al 7, examinamos en detalle las diversas herramientas y tcnicas del
anlisis estructurado de sistemas. En este captulo repasaremos el uso al cual se pueden
aplicar en la primera parte del desarrollo del sistema, comenzando por el punto donde se
plantea por primera vez la cuestin del esfuerzo de desarrollar un sistema, continuando con
las fases de estudio y anlisis, y concluyendo con el diseo fsico. (Las tcnicas de diseo
estructurado, que utiliza el producto de nuestro anlisis, se describen en el prximo captulo.)
Para ello bosquejamos una metodologa para el desarrollo de sistemas estructurados, esto
es, una aproximacin general para la construccin de sistemas comerciales de procesamiento
de datos, construidos alrededor del anlisis y diseo estructurado.
8.1 EL ESTUDIO INICIAL
A medida que las computadoras se hacen ms y ms baratas, nuevas organizaciones se
encuentran con que pueden obtener ventajas de la automatizacin, aun aquellas que tienen
menos de 50 empleados. Si una organizacin no tiene todava una computadora, las
herramientas de anlisis estructurado son tiles para analizar el sistema manual existente,
para entenderlo con claridad previamente a la toma de decisin sobre si se debe instalar una
computadora, y decidir qu partes del sistema se automatizarn.
La secuencia de actividades establecidas en este captulo es de aplicacin al desarroll
de cualquier sistema de informacin, est automatizado o no. Debemos puntualizar, sin
embargo, que la metodologa ha sido desarrollada en primer trmino para situaciones donde
ya existe un sistema computadorizado, vinculado con sistemas manuales, procedimientos
administrativos y quizs con otros sistemas computadorizados, y se trata de efectuar algunas
mejoras en este conjunto de sistemas.
Las preguntas que debern contestarse en un estudio inicial son:
Qu tiene de malo la situacin actual?
Qu mejoras son posibles?
Quin ser afectado por el nuevo sistema?
En una organizacin de cualquier tamao es usual tener una corriente continua de
requerimientos por parte de los gerentes a fin de mejorar el servicio de procesamiento de
datos. Mientras que algunos de stos requerimientos puedan lograrse mediante una mejor
operacin, como ser mejorar el tiempo de respuesta o utilizar una facilidad de consulta
existente, y otros puedan lograrse perfeccionando los sistemas existentes, como ser proveer
un nuevo informe a partir de datos ya existentes, muchos otros implican el desarrollo de un
nuevo sistema. Nos interesan principalmente estos nuevos desarrollos.
157
www.FreeLibros.org
Muchas organizaciones encuentran que la demanda de nuevos sistemas es varias veces
superior a sus posibilidades de construirlo. Realmente, a medida que se implementen ms y
ms sistemas, la tarea de mejorarlos adecuadamente ocupa ms y ms tiempo del personal
disponible, en algunos casos del 50-60% del equipo humano de desarrollo. En consecuencia,
los sistemas que se elijan para su construccin debern ser aquellos que presenten el mximo
beneficio para la mayora de los gerentes de la organizacin, con la esperanza que se ajusten
bien al plan global de desarrollo del procesamiento de datos en la organizacin. El estudio
inicial {a veces denominado evaluacin de requerimientos) es en parte un proceso de filtro
para suprimir los requerimientos de desarrollo que no van a ser de suficiente utilidad y puedan
hacerse en forma relativamente rpida y barata (ya que realizar un estudio involucra personal
y tiempo, de los que se est escaso).
Este estudio inicial podr insumir de 2 das a 4 semanas (excepcionalmente ms), El
analista deber estudiar los requerimientos (si son escritos) y reunirse con los gerentes para
obtener los antecedentes de la situacin y comenzar a analizar el valor probable del nuevo
sistema. Deber hacer preguntas como Puede indicar qu cantidad de ingresos estamos
perdiendo a consecuencia de las deficiencias del sistema actual? y En qu costos estamos
incurriendo, que podran evitarse mediante un mejor sistema? y Es posible hacer una
estimacin en dinero sobre el servicio mejorado que podramos dar con un mejor sistema?.
Cuando el sistema se necesita para poder cumplir con un requerimiento estatutario, debe
determinar la fecha en la cual se lo requiere, as como tambin las penalidades por demora
Los gerentes debern ser invitados a definir en trminos muy generales los beneficios
intangibles que ven surgir del sistema mejorado e identificar otras reas de la organizacin que
se vern afectadas. Si es necesario, los gerentes de esas otras reas debern ser entrevistados
para obtener una informacin similar.
Es til tener presente las razones fundamentales que dan lugar al desarrollo del nuevo
sistema. Las organizaciones pueden estar aprovechando una oportunidad (para aumentar
ingresos, bajar costos, o mejorar servicios) o estar reaccionando a una presin, ya sea
estatutaria^ de la competencia. Por ejemplo, cuando un banco es el primero del rea en
instalar una facilidad que permita a los clientes pagar facturas mediante un telfono con
teclado, entrando el cdigo del pagador seguido del importe de la factura, est aprovechando
claramente una oportunidad de incrementar los ingresos a travs de la mejora de un servicio.
La competencia no lo est forzando a hacerlo,ni tampoco el gobierno. La justificacin del
sistema deber basarse en estimaciones empresarias del v^lor del nuevo servicio para atraer
depsitos. El segundo banco del rea que instale este sistema lo har en respuesta a la presin
competitiva, tal vez como resultado de ver cmo los depositantes mueven sus cuentas hacia el
primer banco. En las reparticiones pblicas el aspecto de los ingresos es menos comn, y la
reduccin de costos, sumado a la mejora del servicio al electorado, son las justificaciones ms
usuales. El acrstico IRACIS (Increase Revenue, Avoid Cost, Improve Service - Aumentar
Ingresos, Bajar Costos, Mejorar Servicios) ha sido sugerido a modo de resumen de todos estos
objetivos empresarios generales de los sistemas.
Dentro de estas categoras generales, hay varias formas en que el nuevo sistema puede
contribuir:
1. Proveyendo la informacin existente, pero ms rpidamente, por ejemplo, proveyen
do un acceso inmediato a los datos que ahora aparecen en un informe semanal.
2. Proveyendo informacin ms actualizada (fresca), por ejemplo, proveyendo datos
sobre ventas de la noche anterior en lugar de las del ltimo mes, o proveyendo balances de
cuenta hasta el ltimo minuto en lugar de balances de cierre del da de ayer.
3. Proveyendo informacin ms exacta, ya sea en trminos de exactitud aritmtica,
como en el caso de un informe que se presenta sujeto a ajuste cuando existen transacciones
que no han podido ser procesadas; o en trminos que le permitan representar en forma ms
aproximada el mundo real, como en el caso en que las cantidades de inventario estn
conciliadas con las cantidades actualmente disponibles y en trmite de pedido. Algunos
158
www.FreeLibros.org
usuarios hablan de mayor exactitud en la informacin y quieren significar informacin ms
actualizada.
4. Proveyendo informacin basada en ms elementos de datos, como en el caso de un
sistema que nunca ha contado con la historia del entrenamiento de un empleado, y que es
remplazado por otro que permite obtener detalles sobre los cursos realizados y la experiencia
ganada. Esto implica la creacin de un nuevo almacenamiento de datos o un agregado al
contenido de uno existente.
5. Proveyendo informacin basada en nuevas funciones lgicas. Cuando se calcula la
proyeccin de la tendencia de ventas a partir de los valores de ventas mensuales existente
empleando el anlisis de series de tiempo, los almacenamientos de datos permanecen iguales
pero se ha introducido un nuevo proceso lgico.
Por supuesto, frecuentemente un requerimiento se expresa como una combinacin de
estos tipos: El usuario desea capturar ms informacin que en la actualidad, obtenerla ms
actualizada, analizarla de una manera ms compleja, y tener la respuesta ms rpidamente!
Ac le resulta til al arialista estar atento a estas dimensiones implcitas, de manera de poder
fraccionar un requerimiento complejo en sus componentes.
As como entrevistar a los gerentes apropiados, el analista deber obtener y revisar toda
documentacin sobre las limitaciones del sistema actual. Deber revisar el plan de desarrollo
de procesamiento de datos (si existe alguno!) para ver cmo esta rea se ajusta a l, y deber
hallar toda la informacin que le sea posible acerca de lo que estn haciendo otras
organizaciones similares en esta rea.
Al finalizar el estudio inicial, el analista deber estar razonablemente seguro acerca de la
magnitud de los beneficios que podrn resultar de un nuevo sistema. Deber saber si un
requerimiento tuvo origen en un rapto de inspiracin de un gerente, pero solo puede ahorrar
$10.000 al ao o si, por el contrario, es algo que puede hacer crecer la facturacin de $100
millones entre el 1% y el 3%. Probablemente estar en posicin de dibujar un diagrama de
flujo de datos general del sistema existente y sus interrelaciones; si desea conocer ms acerca
del sistema actual durante el estudio inicial, el diagrama logico de flujo de datos es una
herramienta muy til para reunir todos los fragmentos.
Deber ser capaz de estimar el tiempo y el costo necesarios para realizar un estudio
detallado (la prxima fase del desarrollo) podr tener una idea muy aproximada de cunto
podrn costar algunos posibles nuevos sistemas. Deber ser muy cauto cuando indique
cualquier total estimado del proyecto; existe una gran presin de los usuarios y de la gerencia
superior en establecer presupuestos del proyecto lo antes posible. Con todo, nuestra
experiencia indica que el precio en firme no puede darse hasta que se conozca el nmero y la
complejidad de los mdulos del sistema, esto es, hasta despus de haberse producido un
diseo fsico firme. El mejor curso es indicar un amplio y confortable margen de costos y
tiempos para todo el proyecto y entregar solamente una cantidad en firme en la prxima fase.
Luego, sintetizando, el resultado de un estudio inicial podra expresarse como sigue:
Una investigacin inicial de dos semanas del sistema de compras actual indica que, basado
en estimaciones del gerente X y del gerente Y, estamos pagando entre el 1% y el 2,5 % ms por las
materias primas que lo que pagaramos si pudiramos centralizar los requerimientos y obtener la
mxima ventaja posible de los descuentos por cantidad y pronto pago ofrecidos por los
vendedores. Nuestra proyeccin de gasto en materias primas durante este ao es de $20 millones,
indicando la posibilidad de una economa potencial anual entre $200.000 y $500.000. Adems,
un sistema de compras mejorado podr tener una cantidad de otros beneficios, que no podemos
cuantificar todava, incluyendo una reduccin de compras urgentes y una reduccin en el
inventario. Basados en la experiencia de otras compaas, estimamos que desarrollar un sistema
de'este tipo costar entre $300.000 y $750.000 y llevar entre 15 y 30 meses. No se pueden
estimar costos operativos con la informacin disponible. Aunque estas cantidades son necesaria
mente muy tentativas, nuestra conclusin es que este proyecto tiene suficiente potencial como
para garantizar un estudio detallado, el cual permitir:
1. Ajustar nuestras estimaciones de beneficios potenciales.
2. Establecer objetivos para un nuevo sistema.
159 www.FreeLibros.org
3. Definir las funciones de un nuevo sistema y cmo se integrarn.
4. Ajustar nuestras estimaciones del costo de desarrollo.
El estudio detallado requerir dos analistas durante 8 semanas, con un costo total de
$16.000.
8,2 EL ESTUDIO DETALLADO
El resultado del estudio inicial deber ser revisado por un nivel de gerencia apropiado.
Muchas organizaciones cuentan con un comit de alta direccin que imparte instrucciones
para el desarrollo del procesamiento de datos. Dependiendo de una combinacin de
prioridades, polticas y de los hechos establecidos en el estudio.inicial, se podr autorizar un
estudio detallado. Deber quedar claro a todos los interesados que el estudio detallado no
representa un compromiso para la implementacin del proyecto. En administracin se dice,
en efecto, luce promisorio; cunteme ms. El estudio detallado cuenta con los hechos
producidos por el estudio inicial para documentar las limitaciones del sistema actual con
mayor detalle y mayor confiabilidad, y para llevar la comprensin de las funciones del
sistema actual al nivel necesario para poder especificar un remplazo. Ahora discutiremos las
actividades de un estudio detallado.
8.2.1 Definir con mayor detall quines sern los usurios
de un sistema nuevo
Se puede concebir que la comunidad de usuarios est constituida en tres niveles:
1. Los gerentes de alto/iivel con responsabilidad en los beneficios, cuyas reas sern las
afectadas y que se ven a s mismos pagando el sistema. Este grupo ha sido denominado los
comisionados ya que ellos comisionan el desarrollo del sistema de la funcin procesamiento
de datos, as como sern posibles usuarios de sus salidas de informacin.
2. La gerencia intermedia y supervisores cuyos departamentos se vern afectados.
3. Los empleados administrativos y dems personl que trabajar directamente con el
sistema mediante el uso de terminales o completando formularios de entrada e interpretando
salidas para realizar sus tareas.
Los comisionados de sistemas, tales como el Presidente, el Vicepresidente de Ventas, o
el Vicepresidente de Produccin estn habilitados para considerar el mediano plazo, el
cuadro de 3-5 aos y realizar esencialmente una decisin de inversin, a favor o en contra de
un proyecto significativo, sobre esta base. Pueden evaluar beneficios intangibles, aunque no
puedan valorizarlos. Tienden a interesarse mucho en los aspectos de un sistema que pueden
incrementar su control real o aparente sobre la empresa, ya que una de las cosas de mayor
importancia para un ejecutivo antiguo consiste en tomar la responsabilidad por alguna
actividad con cuyos detalles no podr mantenerse en contacto.
.Cuando se considera que los sistemas servirn a ms de un rea funcional importante, la
alta gerencia podr desear diferentes cosas del sistema e impulsar a ste en diferentes
direcciones. Es tradicional que los gerentes de ventas deseen tiempos cortos de entrega
porque ello les permite dat mejor servicio al cliente y maximizar ventas, que es para lo que se
les paga. Es igualmente tradicional que los gerentes de produccin deseen tiempos largos de
entrega porque ello les permite mejor programacin de la produccin y menor costo de
produccin, que es para lo que a ellos se les paga. Si el analista tiene mala suerte, l y el
sistema se vern arrastrados'a una lucha de poderes que le demostrar que ningn gerente se
encuentra satisfecho con el informe borrador de objetivos y funciones. Evidentemente, el
analista no puede resolver una situacin como sta; si sospecha que est tratando de servir a
dos patrones que no estn de acuerdo, deber buscar el apoyo en su propia gerencia, la que
160 www.FreeLibros.org
deber, si es necesario, plantear la situacin al gerente general para obtener una resolucin.
Las gerencias intermedias y los supervisores tienden a estar menos preocupados con el
cuadro estratgico y ms interesados en el desempeo en el corto plazo de su departamento,
respecto de su presupuesto. El analista debe soportar presiones para explicar las consecuen
cias de un nuevo sistema sobre los costos y el personal, y debe estar preparado para lidiar con
la resistencia de los gerentes intermedios que temen que el desarrollo pueda quitarles poder y
autonoma. Los gerentes intermedios a menudo estn asediados por los problemas de
conseguir y mantener personal capaz, y si el analista puede mostrar cmo el nuevo sistema
puede facilitar este problema, ganar aliados.
Respecto del personal administrativo cuyo trabajo se ver impactado el analista deber
hacer todo lo posible para que su trabajo sea ms placentero e interesante bajo el nuevo
sistema. Durante las etapas de anlisis y diseo, la gente deber ser tranquilizada acerca del
impacto del sistema sobre su trabajo mediante charlas y demostraciones. Como parte del
estudio detallado, el analista deber familiarizarse con el trabajo de oficina involucrado en el
estudio. Si el tiempo lo permite y es factible, el analista deber ejecutar personalmente una de
las tareas (por ejemplo, la de empleado que atiende consultas telefnicas) por un corto
perodo. Ello le dar una riqueza de informacin de primera mano que le seria difcil, si no
imposible, obtener via entrevistas.
Cuando el analista no se ha encontrado con la alta gerencia durante el estudio inicial,
deber tratar de obtener sus opiniones sobre objetivos y preferencias durante el estudio
detallado. Lo ideal es que cada uno de los gerentes intermedios afectados sea entrevistado,
pero usualmente el tiempo es tirano especialmente si estn geogrficamente separados. Por
ltimo el analista deber obtener o preparar un organigrama actualizado de los departamen
tos de inters, sus gerentes/supervisores y sus funciones. Deber determinar la cantidad de
personal administrativo y su rgimen natural de rotacin, as como entender mejor sus tareas.
8.2.2 Construccin de un modelo lgico del sistema actual
A partir de la. informacin del estudio inicial y de la informacin adquirida al definir la
comunidad de los usuarios, el analista puede ahora producir un borrador del diagrama lgico
de flujo de datos del sistema actual. Pero, qu es exactamente el sistema actuaP. La
preocupacin de los usuarios tiene relacin a menudo con los resultados empresarios de un
rea especfica, digamos, compras. A medida que el analista investiga puede encontrar que
estn involucrados varios sistemas interconectados, algunos manuales, otros automatizados.
En estos casos, puede existir el problema de definir el lmite del problema, de decidir qu
funciones deben ser consideradas como parte del estudio del sistema y cules no. Ac el
diagrama lgico de flujo de datos es de gran utilidad; permite al analista reducir cada uno de
los sistemas interconectados a una terminologa comn y ver cmo se adaptan. Algunas
organizaciones requieren que sus analistas dibujen los diagramas de flujo de datos de cada
sistema que se relacione con el rea bajo estudio, especialmente los sistemas administrativos.
Esto requiere tiempo y esfuerzo adicionales, pero tiene el beneficio de mostrar las funciones
duplicadas y redundantes, dando al analista mayor confianza de que est dibujando los
lmites del sistema en el lugar correcto y mayor comprensin de las tareas administrativas que
deber modificar. x
Cuando debe desarrllame un diagrama de flujo de datos de un sistema automatizado
existente, normalmente el analista tiene poca dificultad en identificar la naturaleza de las
funciones y las entradas y salidas. Puede existir problema en especificar la lgica detallada de
un proceso si est impiementado en un lenguaje mnemotcnico pobremente documentado co
mo el Autocode 1401 (S seor, todava hay programas 1401 que estn corriendo!) Aqu el
analista tendr que elegir entre el trabajo de hormiga de extraer la lgica de un programa (lo
que a menudo no es una forma econmica de usar el tiempo) y el de redifinir la lgica de la
fiincin por comparacin del flujo de datos de entrada con el flujo de datos de salida y consulta
161
www.FreeLibros.org
con un usuario conocedor acerca de la naturaleza de la lgica externa (empresaria) que se
utiliza para transformar estas entradas en salidas. El segundo mtodo no es tan malo porque
no nos interesa interiorizarnos de la lgica interna de un programa no documentado (la forma
en que se ajustan y prueban interruptores, se acumulan contadores y se ejecutan lazos), sino
solamente de las polticas empresarias externas, reglas y procedimientos que estn
incorporados en el programa.
Dado que puede no estar decidida an la realizacin de un sistema, el analista puede
decidir no investigar a fondo la lgica detallada de las funciones del sistema actual, sino
identificar solamente las funciones del nivel de Confeccionar facturas. Este temperamento
puede tomarse tambin con otras funciones cualesquiera, que el analista sabe que no sern
incluidas en cualquier nuevo sistema. Debe adoptarse una decisin similar d sentido comn
con respecto al diccionario de datos. Mientras se dibuja el diagrama de flujo de datos, el
analista deber identificar muchos elementos de datos y estructuras de datos. Si la estructura
de los archivos del sistema actual est bien documentada, ser una fuente adicional de
definiciones de datos. Si stas definiciones son fciles de establecer, el analista podr usar
cualquier manual o facilidades automatizadas que se encuentren disponibles para su captura.
Si la definicin de detalles requiere una cantidad desproporcionada de trabajo, el analista
podr identificar y poner nombre a los flujos de datos y procesos, con breves descripciones de
cada uno, dejando los detalles para ms adelante. Cuando el modelo lgico est construido, el
analista tambin deber estar a la expectativa de cualquier entrada que parezca no ser
utilizada, y de cualquier informe que no tenga valor en adelante o que pueda ser remplazado
por informes de excepcin o consultas. Este tipo de salidas redundantes y sus funciones
asociadas podrn describirse brevemente.
8.2.3 Perfeccionar las estimaciones de IRACIS
El estudio inicial muestra el orden de magnitud del aumento de los ingresos/reduccin de
costos/mejora del servicio que podr resultar de un sistema nuevo o mejorado. Cuando los
beneficios potenciales de un sistema nuevo son obvios y excelentes o la penalidad por no tener
un sistema nuevo es claramente inaceptable, no ser necesario perder ms tiempo en esta
rea. Vale la pena frecuentemente,sin embargo, hacer un segundo anlisis las limitaciones
del sistema actual y a los beneficios potenciales, especialmente a la luz de las proyecciones
del crecimiento en el volumen de las transacciones.
Por ejemplo, en el estudio inicial indicamos un ahorro potencial entre el 1% y el 2,5 % en
la compra de la materia prima, lo que significaba $20 millones en el ao. Cul es la tendencia
de crecimiento en la compra de la materia prima? Existe algn modo de hacer un control
cruzado del ahorro potencial? Ahora que hemos tratado con la mayora de los gerentes ms
importantes, podemos cuantificar algunos de los beneficios intangibles a los que nos hemos
referido ep el estudio inicial? Si se han instalado sistemas similares en cualquier otra parte,
podemos saber qu beneficios han dado? Cmo, se distribuyen los beneficios entre el efecto
de centralizar las compras en forma masiva y el efecto de obtener descuentos por pronto pago?
Ser importante conocer los valores relativos de los beneficios que se podrn obtener de los
diversos aspectos de un sistema nuevo, ya que los mismos podrn ser un indicador importante
de aquellos aspectos que debern ser implementados primero. Obviamente, si el 1,5% del
ahorro podr hacerse en base al descuento por pronto pago, el cual parece ser un sistema
relativamente simple de implementaf, y otro 1% podr ser atribuido a la compra centralizada
masiva, que adems de ser un sistema ms complejo requiere cambios grandes en la
organizacin, deberemos tomar en cuenta estos hechos en el planeamiento posterior.
Al finalizar el estudio detallado se tendr disponible la siguiente informacin:
Una definicin de la comunidad de usuarios del nuevo sistema-
Nombres y responsabilidades de los gerentes de mximo nivel
!62
www.FreeLibros.org
Funciones de los departamentos afectados
Relaciones entre los departamentos afectados
Descripciones de las tareas administrativas que sern afectadas
Cantidad de personal en cada tarea administrativa, rgimen de ingresos y rgimen natural
de rotacin.
Un modelo lgico del sistema actual:
Diagrama de flujo de datos general (incluyendo los sistemas interrelacionados, si son de
inters)
Diagramas de flujo de datos detallados por cada proceso importante
Especificacin lgica de cada proceso bsico a un apropiado nivel de detalle
Definiciones de datos a un apropiado nivel de detalle
Una presentacin de aumento de ingresos/reduccin de costos/mejora de servicios que
podrn obtenerse mediante un sistema mejorado, incluyendo:
Premisas
Volmenes de transacciones actuales y proyectadas y cantidad de datos acumulados
Estimacin en pesos de los beneficios cuando sea posible
Presin de la competencia/factores de ndole estatutario (si existen).
Revisin del costo estimado del probable sistema de remplazo y un presupuesto en firme
del costo/tiempo para la prxima fase ( con la definicin del "men" de alternativas
posibles).
Esta informacin puede presentarse como un informe a la gerencia, en cuyo caso deber
prepararse un corto resumen y tenerlo disponible en forma separada de la documentacin de
ios detalles que ahora se posee. Resulta mejor hacer una presentacin personal al grupo
gerencial de inters, organizando la presentacin alrededor del diagrama de flujo de datos
completo del sistema actual. Frecuentemente es conveniente tener el diagrama completo
dibujado como una gran ayuda visual, porque permitir a los gerentes usuarios tener una idea
clara de la situacin y cmo se integran sus partes.
Un comentario tpico es por primera vez entiendo cmo es el sistema en conjunto. El
analista debe estar preparado para recibir mayores criticas cuando presenta el diagrama de
flujos de datos que cuando expona segn los mtodos tradicionales; siendo ms fcil de
entender, tambin es ms fcil para los usuarios detectar errores en el diagrama de flujo de
datos (lo cual es, en rigor, uno de los objetivos de la presentacin).
Como resultado de esta presentacin, se deber tomar una decisin respecto de
continuar con el proyecto en su prxima fase, o dejarlo de lado. Algunas veces el grupo
gerencial podr decir, Construya el mejor sistema nuevo que pueda por $n. Se deber, en lo
posible, requerir de ellos que difieran la fijacin del presupuesto hasta que se completen los
resultados del anlisis de la prxima fase, la definicin de las alternativas. En parte por esta
razn el estudio detallado y la definicin de las alternativas es tratado como una sola fase, y no
se toma como punto de control para los gerentes usuarios al final del estudio detallado.
8.3 DEFINIR UN MENU DE ALTERNATIVAS
En el pasado fue una prctica comn para los analistas y diseadores estudiar el sistema
fsico actual, comprender algunas de sus limitaciones y a continuacin ir directamente a
proyectar un nuevo sistema fsico de acuerdo con algunas de estas limitaciones. En parte, se
adoptaba este temperamento debido a la dificultad que existia para producir un modelo
lgico; la nica manera de dar forma a los pensamientos de uno sobre un sistema era dibujar
cursogramas fsicos y era tal el esfuerzo para producir cualquier nueva solucin que casi no
quedaba energa para la investigacin de alternativas. En parte, esta produccin de una sola
solucin se debi a la sensacin de una relacin "mdico-paciente entre el profesional de
procesamiento de datos y el usuario. Despus de estudiar los sntomas del paciente, el mdico
prescribe la nica solucin que podr curar el problema. Nosotros vemos que un modelo mejor
163
www.FreeLibros.org
Nombre del Gerente. . Posicin Fecha de la entrevista. . Analista
Basado en este
Item que conoce...
Desea que el
sistema le diga...
Cul es la frecuencia
media probable de este
tipo de consulta en
cuanto a usted
concierne?*
Nombre del vendedor Pedidos no despacha
dos de este vendedor
Nombre del vendedor Propuestas pendientes
de este vendedor
Nombre del cliente Pedidos no despachados
para este cliente
Nombre del cliente Historia de pedidos
despachados para este cliente
Nombre del cliente Propuestas pendientes
para este cliente
Dos fechas Todos los pedidos con
cualesquiera fecha de envi planifi
cada en este intervalo
Componente nmero Pedidos que utilizan
este componente, anali
zadas por mes
Si pudiera te
ner esta infor
macin maitana
por $1, aproxi
madamente cunto
valdra para
usted tenerla in
mediatamente?
> t/min= muy alta, > 10/hora = alta, > 10/da = mediana, > 10/semana = baja < 10/semana = muy baja
Figura 7.19 Ejemplo Sunray Engineermg.
probable. No se est tratando de comparar la importancia de una respuesta con respecto a las
otras, sino solo el valor relativo aproximado. A pesar de ello, los gerentes tienden a dar
valores ms altos a los accesos ms importantes; podrn agregar comentarios tales como No
lo necesito muy a menudo, pero cuando lo necesito, lo necesito pronto y a cualquier precio
(por ejemplo, un anlisis de la tarifa exitosa de la reciente propuesta, como guia para cotizar
en forma competitiva).
- Con accesos relacionados con datos que solo se rtiodi^can lentamente, tales como
recuperar el nmero del cliente dado el nombre del cliente, la alternativa est en comparar la
bsqueda de la respuesta en un listado, contra tener la respuesta presentada o impresa en una
terminal. Con 50 clientes el acceso a la terminal parecer un lujo; con 5000 clientes la
bsqueda en el listado podr insumir mucho tiempo. Le corresponde a cada gerente decidir
sobre el valor relativo que tiene la facilidad para l y su gente.
Cuando se han comparado los resultados de los cuestionarios de las entrevistas con cada
gerente, puede obtenerse por lo general una buena indicacin del valor global de cada
respuesta inmediata, junto a una indicacin de la frecuencia total probable de utilizacin. Si el
cuestionario no puede ser contestado con toda claridad debido a la gran variedad de usos .que
los gerentes pueden hacer de los datos, es muy posible que la solucin est dada por la
disponibilidad de un lenguaje general de consulta.
7.6 CONSIDERACIONES SOBRE SEGURIDAD
Mientras que la cuestin de seguridad de datos contra robo, destruccin o cambios
concierne al analista y al diseador en cada etapa del diseo [7.4j, la misma toma particular
importancia cuando se analizan los requerimientos de acceso inmediato. Los documentos
confidenciales generados por computadora pueden guardarse bajo llave y desmenuzarse
154
www.FreeLibros.org
cuando no se los requiere ms. Los datos confidenciales en un almacenamiento de datos al
que se ha provisto de acceso inmediato via terminal pueden a menos que se tomen
precauciones ser ledos por personas no autorizadas, sin dejar rastros.
En consecuencia, el analista deber establecer quin est autorizado para realizar cada
acceso. Por ejemplo, el gerente de ventas deber tener acceso a las comisiones ganadas por los
vendedores. Podr el supervisor administrativo de ventas tener tambin este acceso? Si se
dispusiera de un acceso a las propuestas pendientes y a sus importes en dlares, quin
detendra a alguna persona pagada por la competencia a que leyera esta informacin en un
CRT?
El diagrama de acceso inmediato y el cuestionario, una vez confeccionados, son tiles
como herramientas para considerar cada acceso por separado y decidir sobre los aspectos de
seguridad de cada acceso. Esta es una cuestin que el analista deber aclarar con la gerencia,
explicando que es posible, dado el software adecuado, permitir a determinadas personas
ver parte del almacenamiento de datos, pero no todo su contenido. Tambin podra ocurrir
que todas las terminales tengan acceso ai nombre, direccin, telfono y territorio del
vendedor, pero que solamente algunos de los que utilizan la terminal en la oficina del gerente
de ventas, provistos de la palabra clave conocida solamente por el gerente de ventas, el
presidente y el contralor pudieran ver los importes de las comisiones individuales. La
gerencia podra decidir que un amplio grupo de personas pueda tener acceso a las estadsticas
de los importes en dlares correspondientes a las propuestas, pero que solo el vendedor de la
cuenta tenga acceso al importe especfico de una propuesta especfica.
APENDICE
Paquetes generales de consultas
CULPRIT-Cullinane Corporation - 20 William Street - Wellesley, MA 02181
EASYTRIEVE - Pansophic - 709 Enterprice Drive - Oakbrook, IL 60521
MARK IV - Informatics - 65, Route 4 - Riveredge, N.J. 07661
Esta no es una lista exhaustiva: Consultar otros paquetes en las publicaciones especializadas.
BIBLIOGRAFIA
7.1 IQF General Information Manual, GH20-1074, IBM Corp., White Plains, N.Y.
7.2 J. Martin, Principies of Data-Base Management, Prentice-Hall, Englewood ClifFs, N.J., 1976,
Cap. 17. i
7.3 J. Martin, Computer Data-Base Organization, Prentice-Hall, Englewood Cliffs, N.J., 1975,
Cap. 5.
7.4 J. Martin, Security, Accuracy and Privacy in Computer Svstems, Prentice-Hall. Englewood Cliffs.
N.J., 1973.
Ejercicios y puntos de discusin
1. En los trminos de este captulo, qu relacin existe entre las pginas amarillas y las pginas blancas
de su guia telefnica? Es posible realizar otras inversiones de los datos de la gua telefnica?
2. Revise los sistemas de su empresa que clasifican o exploran archivos para producir informes. Existen
sistemas en los que sera deseable tener un ndice secundario y proveer acceso inmediato a los datos?
3. Si cualquiera de los sistemas de su empresa usa ndices secundarios, averige cul es la magnitud del
ndice comparado con el archivo principal. Con qu frecuencia se reorganiza el ndice? Se emplea
el ndice con fines operativos o informativos? Cuntos accesos se hacen en un da promedio?
4. Si tiene acceso a un archivo o base de datos jerrquicos, dibuje un diagrama de su estructura. Qu
previsiones hay que hacer para accesos que no descienden a travs del camino jerrquico?
5. Familiarcese con una de las facilidades de consulta general mencionadas en este capitulo. En las
155
www.FreeLibros.org
Cuando se incluyen nuevos flujos de datos y estructuras de datos, los mismos debern ser
agregados al diccionario de datos.
Cuando se deban incluir nuevos elementos de datos en almacenamientos de datos
existentes, los elementos debern ser definidos y tas definiciones del almacenamiento de
datos, actualizadas.
Cuando se involucran nuevos procesos, su lgica deber ser especificada al nivel de
detalle necesario para estimar el esfuerzo probable requerido para su programacin. Por
ejemplo, si la nueva funcin es Preparar informe de inversin de capital, con los flujos de
datos entrantes y salientes especificados, ser adecuado un resumen de la lgica. Si la nueva
funcin es Determinar el trayecto ptimo para los camiones de reparto, se necesitar una
descripcin ms extensa y detallada.
Para desarrollar este modelo lgico, se debern elegir, entre los objetivos fuertemente
establecidos, aquellos ms exigentes. En esta etapa, el analista est tratando de definir un
sistema que satisfaga todos los pedidos de todos los usuarios.
La realidad aparece cuando el analista lleva a cabo un anlisis de acceso inmediato para
cada uno de los almacenamientos de datos para los cuales le fue requerido algn acceso
inmediato. El analista confecciona una cuestionario de acceso inmediato a partir del borrador
del diagrama de acceso inmediato, descripto en el Capitulo 7 y obtiene estimaciones de los
miembros relevantes de la comunidad usuaria, acerca de los valores relativos y frecuencia
probable de los diferentes accesos de la informacin. Consolida esta informacin para
obtener un cuadro general con el valor y frecuencia agregados a cada acceso inmediato.
8.3.3 Producir diseos fsicos tentativos alternativos
En este punto el analista deber decidir si va a tomar o no la responsabilidad del diseo
fsico. La filosofa de la organizacin podr ser tener a la misma persona haciendo el anlisis
y el diseo (y posiblemente codificando) o alternativamente hcer que el analista produzca la
especificacin funcional lgica en la forma que ya se describi, y luego la entregue a otra
persona para el diseo fsico, con las revisiones mutuas apropiadas. Desde nuestro punto de
vista, el segundo temperamento se extender cada vez ms, ahora que se dispone de tcnicas
para presentar con precisin qu se requiere que el sistema haga sin entrar en "cmo lo
hace.
Aun cuando la misma persona haga diseo y anlisis, es una buena prctica usar el
sombrero del analista hasta el punto que justamente hemos alcanzado en el desarrollo (la
especificacin de la funcin lgica) y luego colocarse el sombrero del diseador" y revisar
las especificaciones funcionales pensando que ellas han sido producidas por cualquier otro
para ver cmo se pueden implementar con la mejor relacin costo/efectividad.
El analista y el diseador, entonces ya sea una cabeza o dos trabajan juntos para
idear varios sistemas alternativos que permitan lograr diversas versiones de los objetivos para
distintas inversiones de costo y tiempo. Debern dibujar limites tentativos alrededor de
diferentes conjuntos de funciones del diagrama lgico de flujo de datos propuesto. Debern
considerar la implementacin de todos los accesos inmediatos requeridos, o solamente los
ms importantes, o bien ninguno. Las consideraciones y tcnicas de diseo se discutirn con
ms detalle en el captulo siguiente.
4 Los siguientes son algunos tipos comunes de soluciones tentativas que podemos
considerar.
1. Un sistema en lote, remplazando a un sistema manual o de cinta por otro en el cual los
archivos, aunque sigan siendo posiblemente secuenciales, se puedan colocar en disco, Es
relativamente rpido y barato, y los beneficios son normalmente la reduccin del tiempo de
retomo, el agregado de algunos elementos de datos extras a los nuevos archivos e informes, y
la confeccin de programas ms modificables (este tipo de solucin se usa a menudo para
remplazar a los primitivos sistemas de segunda generacin).'
166
www.FreeLibros.org
2. Un sistema de entrada de datos fuente, con actualizacin durante la noche, en el cual
las transacciones son ingresadas via terminal en el rea del usuario y validadas en lnea,
construyendo asi un archivo de transacciones durante el da, que se utiliza para actualizar la
base de datos principal durante una corrida nocturna. Es ms costoso que el tipo 1, y los
beneficios en general incluyen mayor seguridad (porque los errores pueden ser corregidos en
el momento en que ingresan, por personal que sabe lo que est haciendo), mejora en el tiempo
de proceso (porque las corridas de informacin no tienen que esperar que los errores
atraviesen ciclos repetitivos de validar, rechazar, corregir, validar), y la facultad de
consultar sobre el estado de los negocios de la empresa al cierre del da de ayer.
3. Un sistema de entrada de datos en linea, actualizado inmediatamente, con consulta
en lnea, en el cual cada transaccin es validada y corregida en linea y, una vez aceptada,
usada inmediatamente para actualizar la base de datos. Estos sistemas son relativamente
costosos en funcin del hardware requerido, del desarrollo y mantenimiento del software, y de
la seguridad y precauciones de recuperacin que deben tomarse para prevenir la degradacin
de la base de datos. Los beneficios, por supuesto, pueden ser considerables; no solamente los
errores pueden corregirse en el momento de la entrada, sino que los datos de los archivos son
frescos al mximo posible. En un sistema de reservas de pasajes areos, la disponibilidad de
ubicaciones para un vuelo registra hasta el ltimo billete vendido, lo cual pudo tener lugar
hace unos pocos segundos. En un sistema bancario en lnea si un cliente tiene $100 en su
cuenta y retira $80 a travs de un cajero distribuidor de efectivo en lnea, su saldo queda
inmediatamente indicado como $20, y cualquier intento posterior para retirar ms que este
importe es rechazado. Este tipo de sistema, en general, permite al personal operativo
responder a los cambios del cuadro empresario que tienen lugar minuto a minuto a travs de
todo el da. Esto faculta a la gerencia a consultar sobre la situacin de hace pocos minutos, en
lugar de la que exista al cierre de ayer.
4. Un sistema distribuido del tipo descripto en la Sec. 4.7, en el cual minicomputadoras
locales o terminales inteligentes permiten la entrada de datos fuente y una limitada cantidad
de validaciones contra los datos contenidos en los archivos del microcomputador o de la
terminal. Los informes operacionales tales como facturas, podran ser confeccionados por
cada procesador local; de'cuando en cuando (a menudo cada noche) los procesadores locales
trasmiten informacin a un computador central. El computador central emplea la informa
cin (que puede consistir en los detalles completos de las transacciones o solo en un resumen
de los datos) para actualizar su base de datos y a su tumo puede retrasmitir informacin a los
computadores locales para que actualicen sus propios archivos. Estos sistemas distribuidos
ofrecen muchos de los beneficios del sistema centralizado del tipo 3. Cada gerente local tiene
acceso a sus propios datos y puede actualizarlos inmediatamente si se justifica. La gerencia
central tiene acceso a los datos correctos al cierre de la actividad la noche anterior (o ms
reciente si las computadoras cambian informacin ms frecuentemente). Debido a que las
minicomputadoras y terminales son tan baratas, un sistema distribuido tiende a ser menos
costoso que un sistema centralizado de potencia similar. Cuando una empresa est dispersa
geogrficamente el sistema centralizado necesita lineas telefnicas ms caras y vulnerables
para permitir la entrada y el acceso de datos fuente. Asimismo, si un sistema centralizado se
cae, todo el procesamiento se detiene. Si una microcomputadora local o la central de un
sistema distribuido se caen, los efectos son menos drsticos.
5. Un sistema que utiliza una minicomputadora dedicada en lugar de compartirla UCP
central existente. Este sistema no debe ser necesariamente distribuido, pero se puede
aprovechar la ventaja del bajo costo de las minicomputadoras para implementar un sistema
que no se caiga cuando se caiga el sistema central, y no deteriore su tiempo de respuesta o su
rendimiento total cuando el sistema central est excesivamente cargado. Este sistema a
menudo es apropiado cuando un gerente tiene una aplicacin que no necesita mucha
comunicacin con ninguna otra aplicacin, pero requiere un alto nivel de servicio.
6. Por ltimo, se deber tener en mente que una alternativa puede ser disear un sistema
manual mejorado con o sin un sistema automatizado. F recuentemente, el diagrama de flujo de
167 www.FreeLibros.org
datos de un sistema administrativo presenta redundancias y duplicaciones que han ido
creciendo a travs de los aos y que pueden eliminarse ventajosamente. Tambin podemos
sacar en conclusin (preferiblemente antes de la acumulacin excesiva de detalles) que los
objetivos de los usuarios no requieren ningn cambio en el sistema de informacin, sino que
pueden ser atendidos con cambios de organizacin o de personal. Tal vez, la razn que los
deudores morosos sean tantos no sea porque la informacin necesaria para reducirlos no se
encuentre disponible sino porque aun cuando el gerente de crditos rechaza un pedido, el
gerente de ventas se apersona al presidente y consigue anular el rechazo. En esta situacin
podemos utilizar toda nuestra capacidad como consultores y sugerir que el gerente de crditos
documente el costo de estas decisiones y silenciosamente haga llegar esta informacin al
presidente.
Naturalmente, estas seis posibles alternativas son solo sugerencias que no deben
seguirse ciegamente. Su consideracin es muy til, as como es til hojear un catlogo de
modelos de casas de vacaciones antes de comenzar a discutir los requerimientos de la casa
que pensamos construir. F renuentemente el analista y el diseador seleccionarn una parte de
una alternativa, y una parte de otra alternativa, y as siguiendo hasta llegar a un diseo fsico
tentativo.
Lo ideal es que los diseos fsicos tentativos para un nuevo sistema se seleccionen de la
siguiente forma:
1. Un sistema de bajo presupuesto, de implementacin razonablemente rpida que
incluya solo los objetivos de mayor presin para el usuario, pero que haga factible un
posterior desarrollo hacia una solucin ms elaborada:
(la solucin de la hamburguesa)
2. Un sistema de mediano presupuesto, con una escala de tiempo mediana, que incluya
la mayora substancial de los objetivos, si bien no los ms ambiciosos:
(la solucin del pollo frito)
*
3. Un proyecto de presupuesto muy alto, con un tiempo largo, que incluya todos los
objetivos del usuario y tenga el mximo impacto sobre la gestin empresaria:
(la solucin del bife a la Chateaubriand)
Por cada posible alternativa tentativa, el analista y el diseador debern realizar
estimaciones groseras del probables costos y listar los beneficios, cuantificando estimaciones
todo lo que sea posible. Las estimaciones de costo y tiempo podrn basarse en costos y
duracin conocidos de proyectos similares o en la estimacin de los costos de los
componentes del hardware y del software que requiere cada sistema; preferiblemente
ambos.
Luego, al final de este paso el analista est en posicin de decir a la comunidad de
usuarios algo como lo que sigue:
Por aproximadamente $50.000-$70.000 y aproximadamente en 6-9 semanas de trabajo,'
podremos desarrollar el Sistema A. Este les dar los mismos informes que en la actualidad pero
dentro de los 3 das despus de finalizado el mes, en lugar de los 10 das como en el presente.
Acelerar el ciclo de facturacin, despachando las facturas con un tiempo medio de retraso de solo
2 das despus del despacho y proveer recordatorios automticos, lo cual permitir reducir el
periodo medio de cobranza a 20 dias en lugar de los 38 actuales. Por encima de ello mejorar
nuestra posicin de efectivo en $500.000, con una economa anual en intereses bancarios de
168
www.FreeLibros.org
$35,000. Este nuevo sistema permitir hacer el anlisis de cliente por dimensin y por industria,
que no se puede lograr en el presente. Ser mucho ms fcil de modificar y de extender que el
sistema actual.
Por aproximadamente $150.000-$250.000 y aproximadamente en 12 a 18 meses de
trabajo, y empleando una minicomputadora de $50.000-$70.000, podemos desarrollar el
Sistema B. Este permitir a nuestrosempleados encargados de recibir los pedidos telefnicos
controlar el crdito de los clientes y verificar el estado del inventario, actualizado hasta la noche
anterior, antes de aceptar un pedido; y brindar a la gerencia la facultad de recuperar cualquier
cuenta de cliente sobre una base inmediata. Adems de los beneficios del Sistema A, los
beneficios adicionales del Sistema B son la reduccin de los morosos en un estimado 50%
(equivalente a $20.000 el ltimo ao), el despacho de los pedidos en el mismo da en el caso de
tener existencia, una intangible mejora del servicio al cliente, e intangibles mejoras en las ventas.
Por aproximadamente $600.000-5900.000 y aproximadamente en 2,5-4 aos de trabajo
podemos desarrollar el Sistema C, el cual integrar el procesamiento de pedidos y el control de
inventarios, de forma tal que el vendedor, utilizando una terminal porttil pueda discar sobre
nuestro computador desde la oficina del cliente, obtener una fecha de entrega y precio para los
tem solicitados por el cliente, ingresar de inmediato los detalles del pedido y obtener en el acto
una confirmacin para el cliente. El Vicepresidente de Ventas estima que esta facilidad
posibilitar incrementar las ventas entre el 2% y el 5% y permitir la reubicacin de
aproximadamente 30-35 empleados en la Gerencia de Ventas y Compras. Sujeto al control
gerencial el Sistema C podr ordenar automticamente componentes y materias primas cuando el
inventario disponible caiga por debajo de un nivel de seguridad especificado.
Obviamente, las caractersticas y beneficios de cada alternativa debern registrarse con
gran detalle, pero aunque imperfectas, las tres alternativas anteriores presentan el tipo de
decisin de inversin que puede justificadamente pedrsele al empresario. Vemos que esta es
una decisin de inversin (cunto debemos invertir para obtener cunto beneficio y en qu
tiempo) y no una decisin tcnica. No estamos pidiendo a los usuarios que decidan entre los
mritos del ltimo producto anunciado por IBM y la arquitectura de 17 bits mejorada de
Digital Datawhack. El analista y el diseador han realizado el trabajo de trasformar los
elementos de cada diseo tentativo en beneficios para los usuarios.
8.4 UTILIZAR EL MENU" PARA OBTENER EL APOYO DE LOS USUARIOS
QUE TOMAN DECISIONES
Una vez que se formul el men debe ser presentado al gerente( s)*que deber( n) tomar
la decisin de la inversin. Podr ser un grupo formal existente, denominado tal vez, Comit
de Orientacin de Procesamiento de Datos, o Grupo de Poltica de Automatizacin; si no
existiera tal grupo, el analista regresar a los usuarios que toman decisiones y que fueran
identificados como partes de la comunidad usuaria en la Sec. 8.2.1. Vale la pena tomarse el
trabajo de reunir simultneamente, a todo el grupo en una sala, si es posible, y hacer una
presentacin formal de las alternativas empleando las herramientas del anlisis estructurado
de sistema, como ayudas visuales. Si los responsables de tomar decisiones estn dispersos en
un rea geogrfica extensa o tienen otras actividades programadas, el analista puede llegar a
la conclusin de que vale la pena hacer una serie de presentaciones a cada uno de ellos. S i esto
no se justifica econmicamente, se deber redactar un informe y hacerlo circular para sus
comentarios, reconociendo que ste es el modo menos satisfactorio para llegar a un consenso
sobre las alternativas.
Asumiendo que los responsables de tomar decisiones puedan reunirse en un grupo, el
analista, acompaado por su gerente, deber hacer una presentacin ante el grupo cubriendo
los siguientes puntos:
1. El sistema actual (si existe) recorriendo el diagrama de flujo de datos.
2. Las limitaciones del sistema o situacin actual. Si el mismo grupo de gerentes recibi
una presentacin al final del estudio detallado, las limitaciones debern resumirse. De lo
169
www.FreeLibros.org
contrario, vale la pena perder 5-10 minutos en explicar los valores del IRACIS y las cosas que
hay detrs, ya que esto es una entrada importante para los usuarios que toman decisiones.
3. El modelo lgico del nuevo sistema, recorriendo el diagrama lgico de flujo de datos
que represente la alternativa ms amplia del men, y puntualizando las nuevas funciones que
debern ser incorporadas.
4. Cada uno de los sistemas alternativos que componen el menT, explicando para
cada uno
Las partes del diagrama general de flujo de datos que debern implementarse
La forma en que el sistema aparecer ante el usuario, en funcin de las terminales,
informes y facilidades de consulta (el diagrama de acceso inmediato podr utilizarse como
ayuda visual). Deber emplearse la menor cantidad de jerga posible.
Los beneficios estimados de la alternativa.
Las mejores estimaciones actuales del costo y del tiempo que insume la impiementacin de
la alternativa.
Una especificacin del factor de riesgo respectivo.
5. Una consulta sobre cul de las alternativas representan a los ojos de los usuarios la
mejor solucin de compromiso respecto del costo/beneficio.
El grupo gerencial podr tener una cantidad de preguntas que formular, surgidas a raz de
esta presentacin; podra serles posible alcanzar de inmediato una decisin en consenso sobre
la alternativa a seleccionar, o podrn requerir ai analista que evale algunas soluciones de
compromiso alternativas. Podrn pedir un informe para reconsiderarlo y revisarlo por si
mismos; en cualquier situacin, tiene lugar un dilogo que termina cuando se alcanza el
consenso sobre la naturaleza del sistema que deber ser constraidd y la asignacin al analista
y al diseador de un presupuesto firme de costo y tiempo (dentro del rango de las estimaciones
ya cotizados).
Como se indic al comienzo de la Sec. 8.3, este proceso compromete muy directamente a
los gerentes usuarios en la seleccin de los objetivos del proyecto y en la asignacin de
recursos. Existe una mpyor probabilidad de que la comunidad de usuarios se convierta en la
duea del proyecto en lugar de verlo como otra donacin del personal de procesamiento
de datos, algo que el personal de computacin arma para atender a sus propios objetivos, que
a su vez pueden servir o no a las necesidades de la empresa. Este compromiso hacia el
proyecto y participacin de los principales gerentes usuarios se ha identificado muchas veces
como uno de los factores claves del xito o fracaso de los proyectos de procesamiento de
datos.
8.5 REFINACION DEL DISEO FISICO DEL NUEVO PROYECTO
Cuando los responsables de tomar decisiones han asumido un compromiso, el analista y
el diseador trabajan juntos para traducir el modelo lgico y el diseo fsico tentativo en un
diseo fsico firme. Este proceso comprende cuatro actividades que se superponen.
8.5.1 Refinacin del modelo lgico
Tpicamente, el modelo lgico en esta etapa consiste en el diagrama general de flujo de
datos, entradas del diccionario de datos a nivel lgico para cada flujo de datos principal,
estructura de datos, almacenamiento de datos, y procesos, y un diagrama de acceso inmediato
por cada almacenamiento de datos, cuando sea de inters. Comnmente la lgica detallada de
cada proceso no ha sido an especificada, a menos que sea critica para la estimacin de
costos. Debern desarrollarse diagramas de flujo de datos detallados, entrando en el
170
www.FreeLibros.org
tratamiento de errores y excepciones y en todo otro proceso an no especificado, segn lo
descripto en el Captulo 3. Los contenidos de las entradas del diccionario de datos debern ser
ahora revisados y completados si fuera necesario, como se describi en el Captulo 4. Los
informes y formatos de pantalla podrn simularse a partir de los elementos de datos definidos
en el diccionario de datos. La lgica de procesos deber definirse a un nivel lgico externo,
especificando las reglas y procedimientos que debern incorporarse en el sistema, como se
describe en el Captulo 5. Los contenidos de los almacenamientos de datos lgicos debern
analizarse y simplificarse, como se describe en el Captulo 6.
Este modelo lgico deber revisarse en detalle con los usuarios. A menudo se designa un
enlace en representacin de los usuarios, tpicamente un gerente intermedio con conocimien
to de la aplicacin, y tiene la responsabilidad de aprobar las especificaciones de detalle. Se ha
observado en diversas empresas que cuanto ms importante es el representante del sector
usuario y cuanto ms tiempo le dedique al proyecto, mayor ser la probabilidad del xito
consiguiente. Por ejemplo, si el asistente del gerente de ventas puede ser asignado con medio
tiempo para colaborar con el analista en la definicin de los requerimientos de detalle del
nuevo sistema, su participacin y autoridad har probablemente que cada miembro de la
comunidad usuaria se dedique a fondo a pensar en sus requerimientos y a proveer al analista
una informacin pronta y completa. Algunas empresas han ido ms lejos, designando a este
gerente usuario principal como gerente de proyecto y asignndole el grupo necesario de
procesamiento de datos como recurso para desarrollar el sistema. En toda circunstancia, se
debe hacer todo lo posible para Atener la participacin activa de personal usuario
importante.
8.5.2 Disear ia base de datos fsica
En base al contenido del almacenamiento de datos lgicos, a la informacin contenida en
el diccionario de datos sobre los volmenes de transacciones, y al anlisis del acceso
inmediato, el diseador fsico deber adoptar un compromiso casi definitivo sobre los
contenidos y organizacin de los archivos fsicos y/o base de datos. Se habr hecho un diseo
tentativo de archivo/base de datos para el ejercicio del men, y ste ahora deber refinarse
y probarse contra el modelo lgico. Si el sistema va a utilizar un archivo o una base de datos
existente, el diseador deber comprobar que los datos disponibles y la organizacin sean
conocidos y se adapten a los flujos de datos planificados en el modelo lgico.
El tema del diseo fsico del archivo/base de datos es extenso y complejo, y escapa al
objeto de este libro su tratamiento en detalle; algunos balances de compromiso se discuten en
el captulo siguiente. El mejor libro reciente sobre el tema es el de James Martin [8.1J. Como
analistas, ms que como diseadores fsicos, nos concierne aseguramos que hemos
especificado toda la informacin necesaria para el proceso de diseo, de manera tal que el
diseador fsico pueda realizar el mejor trabajo en el aspecto costo/efectividad.
8.5.3 Establecer la jerarqua de las funciones modulares que
debern programarse
Una vez que se han especificado los archivos fsicos, los procesos y flujos de datos entran
en el mbito de ios subsistemas fsicos. Por lo tanto, una vez tomada la decisin de validaren
linea las transacciones que ingresan, y construir un archivo con las transacciones aceptadas
como entrada de un proceso de actualizacin nocturna de la base de datos principal, se sigue
que todos los procesos y flujos de datos involucrados en validar transacciones y construir el
archivo de transacciones pueden considerarse como el subsistema de entrada de pedidos.
Este subsistema terminar siendo implementado como un programa en lnea, o como varios
programas. Antes de tomar la decisin acerca de qu paquetes fsicos resultarn en
171 www.FreeLibros.org
definitiva necesitamos estructurar cada subsistema como una jerarqua de mdulos, en la cual
cada mdulo tenga una funcin claramente definida. Este concepto, y las tcnicas para
trasformar un diagrama de flujo de datos en una estructura modular se describen en el prximo
capitulo.
8.5.4 Definir las nuevas tareas administrativas que se interconectarn
con el nuevo sistema
Las tareas administrativas que requerir el nuevo sistema estn determinadas por:
i
1. Dnde se dibuja el lmite del sistema automatizado en el diagrama de flujo de datos, y
2. La eleccin fsica que se haga de la entrada y la salida. Entonces, si la validacin de
las transacciones se hace en lnea, deben considerarse las tareas administrativas del ingreso
de la entrada en una terminal (probablemente una CRT), de la interpretacin de las respuestas
de la terminal y del tratamiento de dichas respuestas. Si la validacin de las transacciones
para verificar que sus datos estn completos y la decisin acerca del crdito de los clientes
deben hacerse manualmente, seguidas por la perfoverificacin de los datos de las
transacciones a partir de un formulario de entrada, esto involucra un conjunto de tareas
administrativas completamente diferentes.
Deber especificarse cada tarea administrativa as como los manuales de consulta y de
entrenamiento necesarios para los empleados. Algunas empresas definen un subsistema
personal consistente de todos los flujos de datos y procesos que sern implementados
manualmente y asignan un gerente o analista de documentacin/entrenamiento como
responsable del mismo. Muchas empresas hacen al analista responsable del diseo e
implementacin de este subsistema personal. Especialmente donde los empleados adminis
trativos no han trabajado antes con computadores, el subsistema personal es un componente
crtico que puede amenazar el xito de todo el sistema. Los procedimientos administrativos
debern disearse de manera que puedan llevarse a cabo por los empleados, lo cual implica
que dichos procedimientos debern ser probados completamente, lo mismo que el
software. A pesar de todo lo bueno que sea el anlisis o el diseo del software, si un sistema
requiere que los obreros de fbrica tipeen largos mensajes en las terminales, o exige a los
gerentes que recuerden los cdigos numricos de cada Estado y ciudad del pas, casi con
seguridad est sentenciado al desuso y al fracaso. Para detalles de diseo de subsistemas
personales, consultar Gilb y Wainberg [8.2] y Martin [8.3],
8.5.5 Nota sobre estimaciones
Cada una de las cuatro actividades anteriores est orientada a llegar al punto en que es
posible dar una firme estimacin de costos de desarrollo y operacin de un nuevo sistema. Los
componentes principales de estos costos son:
1. El tiempo profesional y el tiempo de prueba del computador requeridos para
desarrollar los mdulos que han sido definidos. A medida que el personal se hace ms costoso
y el hardware ms barato, estos elementos del sistema de costos se convierten rpidamente
en el factor principal, alcanzando el 70-80% del costo en algunos proyectos de minicompu
tadoras.
2. La velocidad de la UCP, tamao de la memoria, y almacenamiento auxiliar (disco)
necesario para operar con el volumen de transacciones y la base(s) de datos fsica(s)
planificada) s) y satisfacer los requerimientos de produccin y de tiempos de respuesta, tal
como se especifican en los objetivos del sistema.
3. Las terminales, costos de las comunicaciones de datos (lneas arrendadas, cargo por
discado) y otros equipamientos perifricos necesarios para implementar el sistema. Cuando
172
www.FreeLibros.org
interesa el costo del hardware se lo puede expresar tanto como el precio de compra total o
como el costo mensual equivalente, elegido a menudo como el 1/40 al 1/60 del precio de
compra, ya que el equipamiento de computacin a menudo se deprecia en 40,50 o 60 meses.
4. El tiempo profesional requerido para desarrollar la documentacin del usuario e
impartirle el entrenamiento correspondiente. Este es normalmente un item menor, pero
especfico.
5. El tiempo del personal administrativo que interacta con el sistema. Como muchos
sistemas permiten liberar parte del personal existente, la reduccin de la carga de trabajo
administrativo algunas veces se expresa como un beneficio del sistema, en lugar de clasificar
la carga del trabajo remanente como un costo operativo. Claramente, si el sistema actual
emplea 30 personas y el nuevo sistema requiere 10 a un costo promedio de $1.000 por mes en
ambos casos, el cambio puede ser expresado tanto como una economa de $30.000 por mes
con un costo de $10.000 por mes o como una economa neta de $20.000.
6. El tiempo profesional del personal requerido para mantenimiento o ampliacin del
sistema durante su vida til.
Diferentes empresas han desarrollado esquemas distintos de costos para poner un valor
monetario a estos diversos componentes. Ejemplos representativos son:
1K de memoria real por hora 50 centavos
(incluyendo todos los costos de operaciones
y mantenimiento)
1 X eje de disco 3330 en lnea por hora $6
(100 millones de bytes) ($1.000 por mes)
1 hora de tiempo profesional $30
Tomando un ejemplo muy simple, basado en estas cifras, el sistema requiere 60
hombres/mes para desarrollarlo, empleando 4 horas/da de tiempo de prueba para los ltimos
seis meses del proyecto y correr en una regin de 150K, 8 horas/da, con cuatro ejes de disco
3330 permanentemente en linea, necesitando dos personas de tiempo completo para el
mantenimiento de programas; los costos son los siguientes:
Desarrollo:
Tiempo profesional: $290.000 aprox.
60 hombres mes x 20 das/mes
x 8 horas/da x $30
Tiempo de prueba en computador: $36.000
6 meses x 20 das x 4 horas/da
x 150K x $0,50
$325.000 aprox.
Operacin (por mes):
UCP: $.12.000
8 horas/da x 20 das
x150K x0,50
Disco: $ 4.000
4 ejes x $1.000
$16.000 por mes
Mantenimiento (por mes):
2 personas x 20 das x 8 horas x $30 $ 9.600
En este anlisis se ignora el costo de los puntos 3,4, y 5 anteriores, por supuesto, pero es
173
www.FreeLibros.org
indicativo. Como puntualizamos en el capitulo prximo, cuando usted lea estas lineas, el
costo del tiempo profesional habr aumentado y el costo del hardware habr disminuido
substancialmente. Cada analista debe establecer valores realistas para su propia empresa y
estimar la tendencia de los costos operativos durante la vida del proyecto.
Estas estimaciones, por supuesto, tienen como punto de partida las estimaciones de la
mano de obra, capacidad de memoria y tiempo de corrida. De dnde provienen estas
estimaciones? Existe una cantidad de esquemas ms o menos bien probados para estimar la
mano de obra necesaria para un proyecto de programacin (ver, por ejemplo, el trabajo de
Aron [8.4]), pero todos ellos asumen que el estimador conoce cuntos programas deben
escribirse y cun largos son. IBM ha construido una base de datos de 60 proyectos, que
abarcan tamaos desde 4000 lneas de cdigo fuente hasta 467.000 lneas, y ha estudiado el
efecto de muchos factores sobre el esfuerzo requerido y la velocidad de desarrollo del sistema
[8.5]. Los proyectos medianos producen 20.000 lneas de cdigo fuente en 11 meses, con un
promedio de seis personas, para un trabajo total de 67 hombre-mes, con un costo de prueba de
$36.000 aproximadamente. Partiendo de la base de datos es posible predecir con cierta
certeza el nmero promedio de lneas de codificacin a producir por hombre-mes en un
proyecto, basado en factores tales como el uso de la programacin estructurada, la
experiencia profesional, la facilidad de comunicacin con el cliente, y ms de otras veinte
variables. Asi, una vez que el gerente de proyecto conoce la cantidad de lneas de codificacin
que se van a producir, puede predecir la productividad que se puede esperar del personal que
tiene disponible y determinar la duracin y costo del proyecto.
Por ello es que la construccin del modelo lgico y las tcnicas de diseo jerrquico que
se describen en el prximo captulo son tan tiles. Las tcnicas nos permiten identificar las
funciones y mdulos que se necesitarn programar, el diseador puede emplear entonces su
experiencia para estimar la cantidad de lneas fuente que se necesitarn para implementar
cada mdulo y as obtener una estimacin de la tarea de programacin total.
Tambin es, por supuesto, muy til tener un resumen de los costos, esfuerzo y duracin
requeridos por similares proyectos anteriores, de manera que puede hacerse una estimacin
por comparacin y verificarla con la estimacin realizada mdulo por mdulo. Realmente,
sospechamos que la diferencia entre alguien que hace buenas estimaciones y otro que no es
tan bueno reside principalmente en las bases de datos de costos y duraciones de anteriores
proyectos que mantienen en su memoria. Una cantidad de empresas, como IBM, estn
pensando en formalizar sus experiencias para ponerlas a disposicin de cualquiera que
necesite trabajar en estimaciones en una forma fcilmente utilizable. Si se dispone de algo
parecido a un catlogo de Sears-Roebruck de proyectos anteriores (con la descripcin de
cada proyecto, la naturaleza de los informes y los medios de consulta en linea, los costos de
personal y el tiempo de mquina, la experiencia del personal en proyectos y tcnicas
similares, y otras variables de inters), puede ser extraordinariamente valioso para acotar
el proyecto que se est tratando de estimar. Cada caso descrito en el catlogo puede
compararse con el problema o sistema que se est considerando y decidir si es ms simple,
ms complejo, o aproximadamente igual. Esto nos dar una buena indicacin sobre el costo y
duracin relativa que el proyecto actual probablemente insumir dentro de una variacin del
20-30%. Realmente, durante el estudio inicial y detallado este tipo de comparaciones ser el
nico mtodo para estimar el alcance del proyecto, en vez de introducir un dedo hmedo en
el aire.
Los usuarios, en forma muy comprensible, presionan fuertemente a los analistas y
gerentes de proyecto para que produzcan estimaciones tempranas de los costos totales de
proyectos, y considerando, como se ha indicado, que no es realmente posible producir una
estimacin firmemente basada hasta haber realizado el diseo jerrquico, es notable que
muchas empresas no hayan confeccionado an tal catlogo Sears-Roebruck. Si no lo
tiene, le recomendamos ste como un proyecto de gran valor potencial.
174 www.FreeLibros.org
8.6 ULTIMAS FASES DEL PROYECTO
Como este es fundamentalmente un libro de anlisis y no de diseo o implementacin, no
llevaremos la metodologa estructurada ms all de dicho punto. El diseo estructurado y las
tcnicas de implementacin se discuten en el prximo captulo para demostrar cmo se
relacionan con el anlisis estructurado. Para completar podemos distinguir las siguientes
fases en el desarrollo subsiguiente del sistema:
Confeccin de un plan de implementacin, incluyendo planes para la prueba y
aceptacin del sistema.
El desarrollo concurrente de los programas de aplicacin, el subsistema personal, y la
base de datos/funciones de comunicaciones de datos (cuando sean de inters).
La conversin y carga de la base(s) de datos.
La prueba y aceptacin de cada parte del sistema.
Prueba del sistema bajo cargas reales para asegurar que satisface los criterios de
operacin previsto en los objetivos del sistema, en trminos de tiempo de respuesta y
de rendimiento.
Previsiones para la operacin activa del sistema.
Medicin del desempeo del sistema para identificar los cuellos de botella y los
ajustes necesarios para su solucin.
Comparacin de las facilidades globales de sistema y de su desempeo con los
objetivos originales, y accin para resolver cualquier diferencia, donde sea posible.
Anlisis de los requerimientos de mejoras, asignacin de prioridades a los mismos, y
colocacin del sistema en estado de mantenimiento.
El analista frecuentemente acta como agente de los usuarios en las ltimas fases, as
como un arquitecto verifica la construccin de un edificio para asegurarse de que se han
seguido los planos y se han empleado los materiales de la calidad aprobada. El analista deber
participar en las especificaciones de las pruebas de aceptacin y posiblemente en la
generacin de los datos de prueba.
Cuando deba utilizarse un diccionario de datos automatizado en el proyecto, puede ser
muy conveniente la generacin de datos de prueba, ya que los valores aceptables e
inaceptables de cada elemento de datos de entrada han sido definidos en el diccionario de
datos, y a partir de los mismos se pueden armar a su vez transacciones aceptables e
inaceptables.
El modelo lgico debe mantenerse actualizado a travs del diseo y la implementacin,
en especial los diagramas de flujo de datos. Servirn como una herramienta bsica para
planificar mejoras, especialmente aquellas que involucran nuevas funciones.
BIBLIOGRAFIA
8.1 J. Martin, Computer Data-Base Organization, Prentice-Hall, Englewood Cliffs, N.J., 1975.
8.2 T.GilbyG. M. Weinberg, Humanizedlnput: Tech iques forReliableKeyedlnpui, Prentice-Hall.
Englewood Cliffs, N.J., 1976.
8.3 J. Martin, Design o f Man-Computer Dialogues, Prentice-Hall, Englewood Cliffs. N J. , 1973.
8.4 J. D. Aron, The Program Development Process, Addison-Wesley, Reading, Mass., 1974.
8.5 C. E. Walston y C. P. Flix. "A Method of Programming Meassurement and Estimation. IBM
Systems Journal, Vol. 16, N 1, 1977.
Ejercicios y puntos de discusin
*
1. Revisar el enfoque normal de los proyectos de desarrollo que se emplea en su empresa( ya sea formal o
informal). En qu difiere de la metodologa del Captulo 8? En qu se asemejan?
175
www.FreeLibros.org
2. Producir un conjunto de objetivos fuertemente etabiecidos para un sistema recientemente instalado
con el que usted est familiarizado.
3. Producir una definicin de IRACIS real del sistema del Ejercicio 2, comparndolo con el sistema que
remplaza.
4. Desarrollar un DFD lgico general para el sistema del Ejercicio 2 y confeccionar diseos tentativos
para:
(a) Un sistema ms econmico con menos benefricios que el sistema existente.
(b) Un sistema ms amplio con mayores beneficios que el sistema existente.
5. En qu circunstancias sera inadecuado el enfoque men?
6. Desarrollar el costo de desarrollo y el costo de operacin corriente de los ltimos sistemas
implementados en su empresa, como se describe en la Sec. 8.5.5. Emplee hombre/hora y
computadora/hora si no dispone de valores monetarios. Confeccione los diagramas de datos de
acceso inmediato por cada uno de los sistemas que permiten algn acceso inmediato. Existe alguna
relacin entre los costos del sistema y la cantidad de accesos inmediatos?
7. Observa alguna conexin entre el valor de un sistema y el grado de participacin del usuario en su
desarrollo? Cul ha sido la experiencia de su empresa en obtener la participacin del usuario? En su
opinin cules son las causas de que los usuarios no participen ms plenamente en el desarrollo de los
sistemas?
176
www.FreeLibros.org
9
DERIVAR UN DISEO ESTRUCTURADO
A PARTIR DE UN MODELO LOGICO
Qu queremos significar con la palabra diseo? Que es diseo estructurado? En este
captulo vamos a tratar de contestar estas preguntas, demostrar cmo un diseo puede
realizarse desde nuestro modelo lgico de un sistema y ver cmo los diseos mejorados
permiten desarrollar ms fcilmente los sistemas a travs del denominado desarrollo de
arriba hacia abaja
Hay una gran confusin entre anlisis y diseo, en parte porque hasta que fue posible
producir el tipo de modelo lgico que hemos descrito era muy difcil separar el anlisis(qu
debe hacer el sistema) del diseo (cmo va a ser hecho). Definiremos al diseo como el
proceso (iterativo) de tomar un modelo lgico de un sistema junto con un conjunto de
objetivos fuertemente establecidos para este sistema y producir las especificaciones de un
sistema fsico que pueda satisfacer estos objetivos
En los ltimos aos se ha logrado un gran progreso en las tcnicas de diseo de sistemas.
Desde una aproximacin ms o menos intuitiva al diseo donde era casi un milagro ver
cualquier forma de deducir las salidas requeridas a partir de las entradas dadas han surgido
algunos procedimientos y pautas bastante claros. Desde nuestro punto de vista, el conjunto de
pautas de mayor utilidad lo origin Larry Constantine [9.1], como resultado de su trabajo en
IBM, en Hughes Aircraft y en otros sitios a fines de la dcada de los 60, y fue perfeccionado
por Myers [9.2] y Yourdon [9.3]. Este es un enfoque particular conocido como diseo
estructurado; las herramientas lgicas que hemos discutido en este libro penetran profunda
mente en los conceptos de diseo estructurado. Para ver porqu el diseo estructurado (en
oposicin al diseo de arriba hacia abajo defendido por IBM o en oposicin al diseo de
abajo hacia arriba o diseo al azar) es la aproximacin ms til, revisaremos los objetivos del
diseo y relacionaremos el diseo estructurado con estos objetivos.
9.1 LOS OBJETIVOS DEL DISEO
El objetivo ms importante del diseo, por supuesto, es entregar las funciones requeridas
por el usuario. Si el modelo lgico exige la confeccin de cheques y el diseo no produce
cheques, o no los produce correctamente, entonces el diseo es un fracaso. Pero, dado que son
posibles muchos diseos correctos, hay tres objetivos principales que el diseador tendr que
tener presente mientras desarrolla y evala un diseo:
Rendimiento, cun rpido permitir el diseo realizar el trabajo del usuario dado un
recurso particular de hardware.
Control, la medida en que el diseo est protegido contra errores humanos, mquinas
defectuosas, o daos intencionales.
177
www.FreeLibros.org
(
Cambiabilidad, la facilidad con la cual el diseo permite modificar el sistema, por
ejemplo, satisfacer las necesidades del usuario de procesar diferentes tipos de
transacciones,
Aunque ello no siempre es cierto, acontece que generalmente estos tres factores trabajan
unos en contra de los otros; un sistema con controles de mucha seguridad tender a degradar
su rendimiento, un sistema diseado para muy alto rendimiento solo podr ser cambiado con
dificultad, etc. Vamos a rever algunos de los factores que estn detrs de cada uno de estos
objetivos del diseo, considerando con algn detalle la naturaleza de los sistemas
modifieables(See. 9.2). Luego en la Sec. 9.3, consideraremos las soluciones de compromiso
entre los factores.
9.1.1 Consideraciones de rendimiento
El rendimiento normalmente se expresa en trminos de
Volumen de procesamiento (transacciones/clculos por hora)
Tiempo de corrida (para una tarea en lote, donde se procesa la misma cantidad de
trabajo en cada corrida)
Tiempo de respuesta (el tiempo entre que se pulsa la tecla de "entrada en una
terminal y el comienzo de la aparicin de la respuesta del computador en dicha
terminal).
Como la mayora de los sistemas computadorizados estn afectados bsicamente a la
manipulacin o reduccin de los datos (sistemas comerciales), est implcita en cada una de
estas mediciones la cantidad real de memoria utilizada, ya que casi siempre es posible mejorar
el volumen total de procesamiento o tiempo de respuesta, asignando una regin mayor o irfs
memoria real al programa(s).
Esto no es cierto en los sistemas orientados a algoritmos, tales como control de procesos
en tiempo real, donde el rendimiento depende ms de la velocidad del procesador central y de
las instrucciones utilizadas en el proceso. Se invita a los lectores relacionados con dichos
sistemas desmenuzadores generadores de nmeros, a pasar a la Sec. 9.1.3, ya que nuestra
discusin de rendimiento y control es aplicable principalmente a los sistemas orientados a
datos.
En los computadores modernos el diseador, normalmente, est preocupado bsicamen
te con el volumen o cantidad total de procesamiento y en segundo trmino con el tamao de
memoria. Se presenta una excepcin con las pequeas minicomputadoras y microcompta-
doras, donde el objetivo primordial de rendimiento consiste en obtener la mxima cantidad de
funciones en 4K bytes, o algo as.
Identificamos cinco factores que afectan el desempeo en volumen total de procesamien
to de un sistema orientado a datos a nivel bruto, y podemos disponerlos aproximadamente en
orden de importancia decreciente de la siguiente manera:
1. La cantidad de archivos intermedios de un sistema: Un archivo intermedio es aquel
que se utiliza para estacionar datos entre programas, en lugar de un archivo que aloja un
almacenamiento de datos de atributos sobre cierta entidad importante. Un archivo intermedio
es grabado, y luego ledo nuevamente por el prximo programa, despus de lo cual es
desechado sin afectar el procesamiento satisfactorio de los datos. Las instalaciones de
taijetas perforadas y computadoras de segunda generacin con cintas magnticas pero sin
discos se vieron forzadas a correr sistemas diseados con archivos intermedios en una
secuencia programa-archivo-programa-archivo-programa. El diagrama de flujo fsico de la
Fig. 9.1 muestra un sistema de este tipo.
Por supuesto que con grandes computadores y archivos de discos ya no hace falta esta
estructura de sistema; la creacin y nueva lectura de todos los archivos innecesarios tiende a
178 www.FreeLibros.org
o
Figura 9.1 Diagrama de flujo de un sistema fsico.
producir un sistema de corrida esencialmente lenta, aun cuando los archivos se saquen de
cintas y se coloquen en discos. Sin embargo, el hbito de crear archivos intermedios es an
muy fuerte, y estos archivos a menudo se especifican innecesariamente por personas que
obtuvieron su experiencia inicial de diseo de sistemas en los das de la segunda generacin.
2. La cantidad de veces que se pasa un archivo determinado: Supongamos que un
archivo contiene una mezcla de registros de tres tipos, para transacciones del tipo A, del tipo B
y del tipo C. E1diseador puede elegir leer todo el archivo en procura del tipo A y procesar el
tipo A, luego leerlo en procura del tipo B y luego del tipo C, o'bien especificar un programa que
lea el archivo una sola vez y atienda cada tipo de transaccin al encontrarla. Ya sea que el
archivo est en cinta o en disco, la segunda estrategia nos dar el mejor rendimiento total de
procesamiento, a igualdad de las dems condiciones. Clasificar un archivo o buscar de punta
a punta para contestar una consulta (como se describi en la Sec. 7.2) requiere una pasada de
archivo; ya hemos comentado que clasificar o buscar toma un tiempo considerable y puede
degradar el rendimiento de otros sistemas que utilicen simultneamente el mismo archivo.
3. La cantidad de bsquedas contra un archivo de discos: Dando por sentado que un
179
www.FreeLibros.org
diseo tiene una cantidad mnima de archivos intermedios y los corre una cantidad mnima de
veces, la prxima limitacin del volumen total de procesamiento reside normalmente en la
cantidad de movimientos de bsqueda realizado por el brazo de la cabeza mvil del disco.
Siempre que el disco debe ser ledo o grabado, el software administrador del disco deber
determinar dnde se encuentra alojado en el disco el registro apropiado y hacer que la cabeza
lectora grabadora se mueva desde donde se encuentre hasta el lugar correcto para leer el
registro. Este movimiento de bsqueda puede no tomar tiempo (si el brazo est justo en el
lugar correcto) o insumir hasta 250 o 500 milisegundos (1/4 a 1/2 segundo) si el brazo tiene
que moverse a todo lo ancho del disco en un modelo de unidad de disco lenta. Ms an, una
lectura o grabacin dada puede involucrar el examen de diferentes lugares del disco. Para
tomar un caso simple, si los registros en el archivo se localizan a partir de un ndice, la cabeza
lectora grabadora deber moverse primero hasta el ndice y luego a la posicin del registro
deseado, que se encontr en el ndice. Si la posicin especificada no contiene el registro
verdadero sino una direccin de desborde que indica donde_ encontrar el registro, ser
necesaria una tercera bsqueda. Con algunos mtodos de acceso a discos y formatos de
archivos, encontrar un registro puede involucrar de 15 a 20 bsquedas. Algunos de los
factores que incrementan las bsquedas estn fuera del control del diseador debido a que
forman parte del software de administracin de disco que se utiliza. El diseador puede
asegurarse, por su conocimiento del software, de que el formato del archivo no da lugar a
excesivas bsquedas; por ejemplo, el diseador debe ser capaz de especificar reorganizacio
nes regulares de la disposicin fsica para lograr desbordes mnimos en la bsqueda. Puede
resultar posible especificar que el ndice del archivo se encuentre en el medio del archivo, en
lugar de estar en un extremo, lo cual acortar la distancia media de movimiento de la cabeza
lectora grabadora. Ambas medidas son,sin embargo, esencialmente tcticas; lo ms
importante que debe hacer el diseador es estructurar el sistema de manera que el archivo sea
leido la menor cantidad de veces. E sto significa que, si el rendimiento es el objetivo principal,
cuando el archivo maestro de clientes deba leerse para controlar la direccin, todos los datos
de un registro deben permanecer en el sistema hasta que aparezca la necesidad de controlar el
telfono, o saldos pendientes, o la historia de un cliente o cualquier otro dato contenido en el
registro. Estas consideraciones algunas veces entran en conflicto con otros objetivos del
diseo, tales como simplicidad o cambiabilidad, pero el diseador debe revisar el diseo con
el objeto de minimizar lecturas, si puede hacerlo.
4. El tiempo empleado en llamar programas y otros recursos del sistema: Un sistema
est compuesto por una serie de programas, cada uno de los cuales puede estar formado por
sub-programas. En la mayora de las computadoras cada programa principal es invocado por
el lenguaje de control de trabajo, que en s mismo forma un mini-programa invocado por el
operador de la consola. Podemos proporcionar la estructura de invocacin en la mayora de
los sistemas como una jerarqua, tal como se ve en la Fig. 9.2. La flecha de invocacin a
diferencia de la flecha de un grfico de flujo o de un diagrama de flujo de datos, implica que el
control se trasfiere de programa a programa, pero tambin que dicho control es devuelto
cuando el programa invocado o llamado ha terminado su ejecucin. Este tipo de jerarqua de
control, en el cual una cantidad de pequeos mdulos manejables (programas o secciones de
programas) se combinan para formar un sistema, tiene muchas ventajas, como veremos al
discutir la cambiabilidad de los diseos. Desde el punto de vista del rendimiento cada
invocacin toma un cierto tiempo, ya sea porque el computador (su sistema operativo) tiene
que determinar el lugar de la memoria donde se encuentra el programa invocado, y trasferirle
el control, o porque lo que es ms serio si el programa no est en la memoria, el sistema
operativo debe ir a proveerlo desde alguna otra biblioteca, ya sea va un CALL (llamado)
dinmico, o una extraccin por superposicin (overlay fetch), o en una operacin de
paginado desde en un sistema de memoria virtual. Genricamente hablando, las
invocaciones dentro de un programa (por ejemplo, un PERFORM en COBOL) involucran
menos proceso auxiliar que las invocaciones de un programa por otro (por ejemplo, un CALL
en COBOL). Por esta razn el diseador puede decidir empaquetar dos mdulos juntos en
el mismo programa si se llaman entre s frecuentemente.
180 www.FreeLibros.org
5. El tiempo insumido para ejecutar el programa real: Despus de haberse ledo los
datos necesarios y despus que el programa apropiado ha sido invocado y ha recibido el
control, se ejecutan las instrucciones reales de mquina generadas por el compilador a partir
del programa fuente. Esta ejecucin de la codificacin generada, a menudo representa la
menor proporcin de todo el tiempo insumido por el sistema, y debe ser el ltimo lugar en el
que un diseador o un programador consciente gaste tiempo en lograr mejoras. Muchos
tcnicos no aprecian la relativa poca importancia de una eficiente codificacin de mquina, en
estos das de grandes mquinas y sistemas operativos poderosos. Es difcil recordar que si la
bsqueda promedio toma 30 milisegundos, una instruccin larga de mquina puede tomar 30
microsegundos, 1000 veces menos. Prestar atencin a la eficiencia en la generacin de
codificacin sola ser importante cuando las mquinas eran pequeas y lentas; ocasional
mente puede ser an importante en mini o microcomputadoras y en UCP asignadas a
sistemas en tiempo real, donde son importantes las fracciones de segundo en los tiempos de
respuesta. En general, sin embargo, el diseador y el programador logran mayores mejoras de
rendimiento dedicando su tiempo a los primeros cuatro factores, en lugar de preocuparse
acerca de la cantidad de instrucciones en lenguaje compaginador (assembler) generadas por
alguna sentencia. Citando a Ed Yourdon,
F i g u r a 9 . 2 Estructura de invocacin.
.. .uno debe siempre sonrer un poco ante las quejas de ineficiencia de los programadores COBOL
trabajando bajo un sistema operativo tal como el OS/360. Si realmente estuviramos interesados
en la eficiencia, deberamos estar codificando en octal en mquinas sin un sistema operativo...
(9.4).
En realidad, a menos que podamos simular el sistema operativo en nuestras mentes, es
insustancial pre-optimizar la codificacin hasta que no veamos dnde se pierde la mayor
parte del tiempo.
181
www.FreeLibros.org
9.1.2 Consideraciones sobre control
Dependiendo de la naturaleza del sistema y la cantidad de dinero enjuego, el diseador
necesitar introducir diversos tipos de controles. Obviamente un sistema donde se manejan
grandes sumas de dinero o donde se almacena importante informacin secreta, necesita
controles ms fuertes contra errores o daos, que el sistema de distribucin de libros.
Algunos aspectos comunes de control son:
1. El uso de dgitos de verificacin sobre nmerospre-determinados:Hemos visto que
ISBN tiene un dgito de verificacin, que es el ltimo de sus diez dgitos. Muchos bancos
asignan el ltimo dgito del nmero de la cuenta personal como dgito verificador. En el
momento en que se asigna el nmero del cliente, el dgito verificador se calcula en base a los
otros dgitos del nmero y a una frmula adecuada. Luego, cada vez que se procese en el
futuro el nmero de cuenta en particular durante la entrada del dato los dgitos del
nmero, tal como ingresan, se utilizan para recalclar el dgito verificador, y la respuesta se
compara con el dgito verificador ingresado. Si los dos no concuerdan uno o ms dgitos han
sido ingresados incorrectamente, y la transaccin ser rechazada. El uso de un dgito
verificador requiere un pequeo procesamiento extra, pero ste se justifica ampliamente en
razn de los errores que previene.
2. El uso de los totales de control de lote: Cuando las transacciones se ingresan al
sistema en lotes, el total (tal vez la cantidad total de todos los pedidos del lote) es calculado
manualmente antes de la entrada. Como parte de la validacin de este lote, el diseador
deber especificar que el computador calcule el total del lote y lo compare con el total
calculado manualmente. Si no concuerdan puede ocurrir que una transaccin se haya perdido
o que haya entrado incorrectamente un importe.
3 . La creacin de libros diarios y lneas de auditora:Es deseable que la gerencia o los
auditores internos estn siempre en posicin de decir qu transacciones ha procesado el
sistema, y qu ha hecho con ellas. El diseador puede especificar que cada transaccin que
entre al sistema se grabe en un registro o archivo diario, que podr ser ledo por los auditores a
su comodidad. Algunas veces se llevar tambin un diario de archivo de acciones el que
registrar cada cambio de cualquier archivo. La creacin de estos libros diarios retardar algo
al sistema y requerir ms recursos de hardware; el diseador tendr que encontrar una
solucih de compromiso con las necesidades de control y seguridad. Realmente, puede no
tener mucho para elegir en materia de controles, ya que ellos pueden ser impuestos por los
auditores. En los sistemas en lnea, el archivo diario se crea por otra razn. Si el sistema
llegara a fallar, algunas de las transacciones que habran debido entrar desde terminales
remotas se perderan; puede ser necesario hacer previamente una copia del archivo maestro y
correr las transacciones del da contra l desde el archivo diario. Tornar copias de respaldo de
los archivos o de puntos de control tambin representa un uso, por el diseador de recursos de
hardware para seguridad y control.
4. Las limitaciones de los accesos a los archivos: Muchos de los aspectos de diseo de
seguridad y control estn vinculados con las respuestas a las preguntas
Quin puede acceder a estos datos?
Quin est autorizado a modificar estos datos?
Los accesos pueden limitarse mediante el empleo de contraseas, o palabras clave, las
que debern'ingresarse antes de que una persona pueda utilizar una terminal, o mediante el
software que prevenga contra usuarios no autorizados a usar ciertos programas, o que
prevenga para que ciertos programas no puedan leer elementos de datos especficos de un
archivo. Tambin puede controlarse mediante la posesin fsica del propio archivo, como en
el caso que la cinta maestra de la nmina se encuentre encerrada en la caja fuerte. Para una
descripcin detallada de estos temas y de toda la cuestin de seguridad y precisin en el diseo,
ver Martin [9.5]. En general, podemos decir que el control y la seguridad cuestan dinero ya
sea por el hardware y/o software adicional, y tambin que puede afectar el rendimiento. El
182
www.FreeLibros.org
diseador, guiado por el analista, tiene que encontrar la mejor solucin de compromiso entre
estos factores.
9.1.3 Consideraciones sobre la cambiabilidad
Hablamos acerca del sistema pensando en l como si fuera una cosa fsica esttica,
pero por supuesto nada podra estar ms lejos de la verdad. Puesto que el sistema procesa
datos sobre el mundo real, siempre que el mundo real externo cambie, el sistema puede
necesitar cambiar. Nuevas lneas del negocio se introducen o se quitan, los precios y los
esquemas salariales cambian, los gerentes usuarios cambian y los nuevos usuarios tienen
ideas diferentes sobre sus requerimientos de informacin, las polticas cambian y nuevas
leyes se sancionan.
As como estos cambios son inducidos externamente, tambin la tecnologa del
procesamiento de datos est en agitacin. Mayor potencia, hardware ms barato, nuevos
sistemas operativos y lenguajes, nuevas tcnicas de comunicacin de datos y de base de datos,
todo ello podr significar que el sistema debe ser cambiado de alguna manera. Por otro lado,
no importa cun cuidadosa sea la prueba que reciba el sistema, siempre habr errores que solo
aparecen una vez que el sistema est en estado de produccin; estos errores deben encontrarse
y eliminarse. Encontrar y eliminar un error involucra muchas veces las mismas actividades
que hacer un cambio para beneficiar al usuario; el programador deber localizar la parte del
sistema que necesita ser reparada o cambiada, hacer el arreglo y asegurarse que trabaja bien.
(Realmente, los tres tipos de cambios se trabajan juntos y con frecuencia se llama a esto
mantenimiento, aunque hacer cambios que provean al usuario de funciones adicionales o
mejores podra llamarse ms apropiadamente, perfeccionamiento).
Existe alguna diferencia entre la remocin de errores despus de poner el sistema en
produccin o removerlos antes de ponerlo en funcionamiento? Aparte del impacto de los
errores en el entorno de la produccin, las actividades involucradas son idnticas. Por lo tanto
sacamos en conclusin que la cambiabilidad de un sistema es algo muy importante; si se
pudiera encontrar una manera de disear el sistema ms modificable, sera fcil de corregir,
fcil de adaptar a hardware y software cambiantes, y fcil para incorporarle los cambios y
mejoras solicitadas por los usuarios.
Por cambiabilidad queremos significar una medida del tiempo que lleva hacer cualquier
cambio en el sistema, ya sea suprimir un error o instalar una mejora. Supongamos un sistema
dado que ha sido diseado de dos maneras diferentes y que se ha hecho el mismo conjunto de
cambios en cada sistema. Si el diseo A requiere 20 hombres-horas para el cambio y el diseo
B requiere 60 hombres-horas para introducir los mismos cambios, podemos decir razonable
mente que el diseo A es tres veces ms modificable que el diseo B.
Valores recientes muestran justamente cun importante es el factor de cambiabilidad en
el costo total del sistema. La Fig. 9.3 resume valores representativos que indican que para
sistemas desarrollados en la actualidad, la mayor parte del costo a lo largo de su vida til se
invierte en modificar dichos sistemas, y que en el presupuesto de la mano de obra visible
para su desarrollo, se gasta aproximadamente la mitad en los cambios correspondientes a
pruebas y correcciones. No es de extraar que en muchas instalaciones el esfuerzo que
implica mantener el sistema existente en el aire interfiera con el desarrollo de nuevos
sistemas aun cuando la empresa necesite de ellos con urgencia.
Corregir y cambiar el software son tareas con ardua exigencia de mano de obra; no es de
gran ayuda lo que se podr obtener del uso de la capacidad del computador, aparte del uso de
las tcnicas de depuracin interactivas. Mientras, como se ve en la Fig. 9.4,el costo del
hardware declina a un ritmo notable, el costo de la mano de obra profesional crece
continuamente. Hay por lo tanto una gran presin que ir creciendo mes a mes, para que los
sistemas a disear sean lo ms modijicables que sea posible. Despus de todo, si podemos
producir sistemas que sean dos veces ms modificables que los actuales, podramos reducir
183
www.FreeLibros.org
Actividad
DESARROLLO DEL SISTEMA [9.6]
Anlisis y diseo
Codificacin
Pruebas y correcciones
Reducidos
por sistemas
modificables
OPERACION DEL SISTEMA
MANTENIMIENTO DEL SISTEMA [9.7]
Proporcin del
costo de desarrollo
35%
15%
50%
Actividad no labor-intensiva
Correcciones en produccin
Cambios para ajustar a nuevo hardware/software|
Perfeccionamientos]
Proporcin
del costo total
de vida til
20%
80%*
* La carga de mantenimiento aumenta a medida que son completados ms proyectos: en la mayora de las instalaciones
actuales insume hasta el 40-70% de todo el tiempo profesional [9.8],
Figura 9.3 Resumen de la distribucin del costo de la mano de obra a travs del ciclo de vida de un
proyecto.
Precio de compra equivalente por
1K Memoria
Costo promedio por
hora por Programador/Analista
1964
$2.000 (360/30)
1969 $1.000 (S/3)
$20
Sep 1975
$ 260(370/158)
May 1976 $ 170(370/158)
Abr 1977
$ 110(370/158) $30
TENDENCIA' DISMINUCION 20% por aflo INCREMENTO 7% por ario
Figura 9.4 Comparacin del costo del hardware con el costo del personal (unidades monetarias
en dlares estadounidenses).
potencialmente su costo total en su tiempo de vida en un 40%! y, lo que es ms importante
para muchos gerentes, podramos reducir su costo de desarrollo en un 25 % (la mitad del costo
de pruebas y correcciones). Estos son valores importantes.
9.2 DISEO ESTRUCTURADO PARA CAMBIABILIDAD
9.2.1 Qu contribuye a que un sistema sea modificabie?
Existe un acuerdo general en el sentido de que los sistemas ms fciles de cambiar son
aquellos que estn constituidos por mdulos manejablemente pequeos, cada uno de los
184
www.FreeLibros.org
cuales es independiente, hasta donde es posible, de cualquier otro, de manera que pueden
sacarse del sistema, cambiarse, y reponerse sin afectar al resto del sistema.
Qu queremos significar con mdulo?
Qu es manejablemente pequeo?
Qu es independencia?
Un mdulo lgico es una funcin definida con un nombre que expresa el propsito de la
funcin; los procesos que hemos definido en el diagrama de flujo de datos, como Verificar
cantidad despachada, Calcular total de los pedidos, Generar pagos, pueden conside
rarse mdulos lgicos. Un mdulo fsico es una implementacin particular de un mdulo
lgico, normalmente en trminos de cierto grupo de sentencias en un lenguaje de
programacin, al cual se puede hacer referencia por un nombre. Por lo tanto un mdulo fsico
puede ser un programa, un sub-programa, una seccin COBOL, o aun un pargrafo COBOL.
Cuando el lenguaje de control de trabajo permite dar un nombre a los conjuntos de sentencias
y almacenarlos como un procedimiento catalogado, este procedimiento es un mdulo fsico.
Estrictamente hablando, un conjunto de instrucciones a un operador de consola o a un
empleado puede considerarse como un mdulo fsico. Obviamente, los mdulos a menudo
invocan a otros mdulos, los cuales invocan a otros mdulos, etc., como se muestra en el
croquis de la Fig. 9.2. Dentro de un sistema, o dentro de un programa, los mdulos caen
naturalmente dentro de una jerarqua de jefe, sub-jefe, sub-sub-jefe, etc., hasta los mdulos de
trabajo que desempean tareas particulares.
Cuando decimos que queremos un mdulo manejablemente pequeo significamos que
una persona competente ser capaz de tomar el listado de un mdulo, leerlo y hacerse
mentalmente un cuadro de su funcin interna mientras decide cmo cambiarlo. Algunos
mdulos pueden ser tan pequeos como de 10 lneas de codificacin y otros (donde la funcin
es simple en principio pero de larga ejecucin, como el caso de un problema de programacin
lineal) pueden implicar algunos centenares de lneas; 50-100 lneas es un tamao comn para
mdulos de trabajo bien formados.
Los mdulos que componen un sistema no pueden ser completamente independientes
unos de otros o no existira un sistema sino solamente un montn de mdulos aislados. La
tarea del diseador es formar los mdulos y disear sus interconexiones para minimizar la
posibilidad del temido efecto de onda{ ripple, en ingls) [9.9]. El efecto de onda se presenta
cuando el diseador (o implementador) ha permitido que las diversas partes del sistema se
conecten de manera confusa; tal vez dos mdulos comparten el mismo almacenamiento
temporario, o una parte del programa lee un interruptor que se acciona en una parte com
pletamente diferente del programa. Si existen muchos de estos sutiles acoplamientos inter-
modulares, el programador de mantenimiento tendr una vida muy dura. Supongamos que un
usuario necesite hacer un cambio que afecte al mdulo A. El programador resuelve los
detalles del cambio, modifica el mdulo A y pone el sistema nuevamente en produccin. Ay!
el cambio del mdulo A de alguna manera causa un error en el mdulo B, y este error no es
percibido hasta mediados de la noche siguiente. El programador rastrea el error y modifica el
mdulo B para anularlo. Pero este cambio afecta el mdulo C, y reparar el mdulo C deteriora
al mdulo D... El efecto del cambio original provoca ondas a lo largo del sistema, como las
ondas causadas al tirar una piedra en un estanque. Algunos sistemas estn tan interconecta
dos que se vuelven imposibles de mantener, el pobre programador persigue los errores por
todo el sistema sin poder eliminarlos jams.
Las normas del diseo estructurado son de gran ayuda para producir sistemas en los
cuales el efecto onda se mantiene en un mnimo.
Otro factor que hace a la cambiabilidad es el grad con el cual el diseador logra aislar la
funcionen la menor cantidad de mdulos posible. Esto resulta obvio, una vez expuesto; si el
usuario quiere cambiar la poltica del clculo de descuento y el descuento est calculado en un
mdulo (el cual es modificable sin originar el efecto onda), el cambio ser relativamente fcil,
rpido y barato de hacer. Si las diferentes partes del clculo de descuento estn distribuidas a
travs de varios mdulos o si se calculan descuentos independientemente dentro de varios
185
www.FreeLibros.org
mdulos en el sistema, los cambios sern correlativamente ms difciles de introducir.
En ltimo trmino, queremos que nuestras funciones estn contenidas dentro de cajas
negras, donde la funcin producir siempre resultados predecibles a partir de un conjunto de
datos que pasen a travs de la misma. Por caja negra, especficamente queremos decir:
1. Que produce resultados que pueden predecirse, vista desde los mdulos que la
invocan.
2. Que no necesitamos conocer la codificacin interna especfica del mdulo para
conocer su funcin.
LaFig. 9.5 resume los factores que hemos discutido para construir diseos modificables.
Sistema compuesto de una jerarqua de mdulos caja negra.
Cada mdulo manuablemente pequeo.
Cada mdulo modificable sin crear un efecto onda.
Las funciones del usuario aisladas al menor nmero posible de mdulos.
Figura 9.5 Factores que contribuyen a un diseo cambiable.
9.2.2 Derivar un sistema modificable desde un diagrama de flujo de datos
La experiencia del diseo estructurado y el examen de los sistemas que se conocen son
cambiables, sugieren que los mdulos en un sistema cambiable a menudo se parezcan a
unidades de una organizacin militar. Cada mdulo tiene su propia tarea, que desempea
cuando recibe rdenes superiores; se comunica solo con su jefe superior y con sus
subordinados, a los cuales a su vez imparte rdenes. La Fig. 9.6 ilustra esta analoga.
En esta jerarqua modular el mdulo jefe de sistema invoca al jefe de entrada con la
orden implcita Deme una transaccin correcta. El jefe de entrada a su tumo invoca al
mdulo lector con la orden Consgame una transaccin. El lector desempea esta sola
funcin en su vida y luego devuelve el control a su jefe superior, diciendo Ac hay una
transaccin o Ac no hay ms transacciones. Ignorando la posibilidad de fin de archivo
por el momento, el jefe de entrada llama a un mdulo editor le transfiere la transaccin
en bruto y le pregunta Es sta una transaccin correcta? El editor ejecuta su funcin y
retorha con la respuesta. Si la transaccin no es buena, el jefe de entrada decidir si debe ser
arreglada de alguna manera o si debe ser rechazada, y el lector recibir la orden de obtener
otra. La suma total de este proceso es que el jefe de entrada devuelve el control al jefe de
sistema y le trasfiere una transaccin correcta. El jefe de sistema pasa entonces esta
transaccin correcta al jefe de trasformacin, el cual, utilizando a cada uno de sus
subordinados para que ejecute su funcin especial, calcular el resultado que deber tener la
salida correspondiente a la transaccin correcta original. La trasformacin deber calcular el
pago neto y las deducciones de un registro de pago, o determinar el plan de vuelo ptimo para
un avin con los parmetros de carga y estado del tiempo, o determinar la cantidad de
mercadera a pedir con la informacin de consumo y condiciones de descuento. Cualesquiera
que sean los detalles, el mdulo jefe de trasformacin har llegar a su jefe el resultado, el que
ser entregado al jefe de salida para su disposicin. Obsrvese que los mdulos de trabajo
no se comunican directamente entre ellos, sino con susjefes. Esta es una forma de simplificar
el acoplamiento inter-modular y hacer fcil de comprender el comportamiento del sistema.
Los sistemas con este tipo de estructura, en los cuales un tramo de entrada maneja todas
las funciones de entrada, un tramo de trasformacin toma una entrada correcta y produce un
resultado y un tramo de salida maneja toda la salida correspondiente a ese resultado, se
denominan sistemas centrados en trasformacin, por razones obvias. Su estructura
186
www.FreeLibros.org
F i g u r a 9 . 6 Analoga con la organizacin militar.
jerrquica puede establecerse casi directamente desde el flujo de datos a travs del sistema
como puede verse en la Fig. 9.7.
Para pasar del flujo de datos a una estructura jerrquica, empezamos por la forma ms
bruta de la entrada y la rastreamos a travs del flujo de datos hasta alcanzar un punto donde no
se puede decir que es una entrada. Igualmente se toma la salida final y se rastrea hacia atrs
dentro del sistema hasta donde no se pueda concebir pensar ms como una salida. La Fig. 9.8
muestra el flujo de datos con estos puntos marcados.
Una vez que estos puntos de mayor abstraccin han sido identificados, siempre
podremos crear un diseo centrado en trasformacin mediante la especificacin de un sistema
que requiere la forma de entrada ms abstracta, la transforma en la forma de salida ms
abstracta y la coloca en la salida. La Fig. 9.9 muestra el nivel superior de este tipo de
jerarqua.
Ntese que en este caso hemos denominado a los mdulos de acuerdo con sus funciones
O las rdenes que ellos obedecen'' en lugar de llamarlos jefe de entrada", etc. Esto es
precisamente similar a la forma en la cual hemos descripto las funciones lgicas en nuestro
diagrama de flujo de datos, utilizando un verbo activo y un objeto nico.
Podemos completar los mdulos del nivel inferior y marcar en este asi llamado
diagrama de estructura los datos que se han trasferido entre mdulos. Es convencional
mostrar cada estructura de datos o elemento de datos con una flecha pequea con un pequeo
crculo en blanco en el extremo: o--------- . Donde un mdulo trasfie re una seal o interruptor
de control a otro mdulo, indicando al mdulo receptor qu fue lo que sucedi o qu debe
hacer, el elemento de control se indica con un crculo lleno: -------------.
La Fig. 9 . 1 0 muestra la estructura hipottica de nuestro sistema utilizando estas
convenciones. Seal de validacin" es un elemento de datos de control, operado por el
mdulo VALIDAR ENTR ADA , tal vez a "s", si la entrada pasa la validacin o a "no" en
caso contrario.
El sistema centrado en trasformacin, comnmente se deriva de un flujo de datos donde
todas las transacciones siguen caminos iguales o muy similares. A menudo, especialmente en
los sistemas comerciales, ste no es el caso, el flujo de datos muestra que el sistema maneja
187
www.FreeLibros.org
Figura 9.7 Flujo de datos hipottico.
F i g u r a 9 . 8 Puntos de mayor abstraccin de entrada y salida.
F i g u r a 9 . 9 Jerarqua bsica derivada de un flujo de datos.
varios tipos diferentes de transacciones, como se indica en la Fig. 9.11. Aqu se muestran
cuatro tipos diferentes de transacciones (podran ser ms o menos), cada una de ellas tendr
que validarse en forma separada, y luego ser empleada para actualizar diferentes archivos
maestros, segn una lgica diferente, despus de la cual se imprime un registro o diario para
mostrar los detalles de cada transaccin, junto con los contenidos de cada registro maestro
antes y despus de la actualizacin.
Una jerarqua modificable correspondiente a este mdulo de flujo de datos se muestra en
la Fig. 9.12. En este tipo de sistema el mdulo ejecutivo principal invoca primero un mdulo
analizador que retorna con una transaccin y su tipo; el ejecutivo principal entonces invoca a
un despachador cuya tarea es dirigir la transaccin a un subsistema apropiado establecido
para cada tipo de transaccin.
Este modelo de jerarqua se conoce como centrado en transaccin. Como vimos cuando
consideramos nuestro ejemplo de diseo, muchos sistemas de flujos de datos implican una
combinacin de ambos tipos de jerarquas, trasformaciones y transacciones, de manera que la
clave reside en que en el punto de trasformacin haya un camino de datos o varios. AJ estudiar
el diagrama de flujo de datos detallado, el diseador puede determinar la estructura del nivel
superior (centrada en trasformacin o en transaccin) y derivar una jerarqua de primer
corte; luego el problema est en asegurar que los mdulos de la jerarqua y la comunicacin
188
www.FreeLibros.org
PRODUCIR
LA MEJOR
SOLUCION
Entrada
correcta
OBTENER CALCULAR DAR SALIDA
ENTRADA LA MEJOR AL A
CORRECTA SOLUCION SOLUCION
Entrada j
bruta /
S . \ \ Validar
E n t r a d a \ \ \ sea|
bruta \ \ *
Salida
con formado
LEER
VALIDAR DAR FORMATO EXHIBIR
ENTRADA
ENTRADA A LA SALI0A SALIDA
F i g u r a 9 . 1 0 Diagrama de estructura para un sistema simple centrado en trasformacin.
F i g u r a 9 . 1 1 Flujo de datos con varios tipos de transacciones.
entre ellos es todo lo modificable que sea posible. Para hacer esto, necesitamos algunas guas
de accin, como ser la forma de llegar al acoplamiento ms modificable entre mdulos, y qu
constituye un mdulo bien formado. Analizaremos por tumo cada uno de estos factores.
189
www.FreeLibros.org
F i g u r a 9 . 1 2 Jerarqua centrada en transaccin.
9.2.3 Acoplamiento de mdulos
Como dijimos, uno de los objetivos del diseo en cuanto hace a la camuabilidad es tener
el menor acoplamiento posible entre los distintos mdulos, sin afectar el funcionamiento al
sistema. Qu tipos de acoplamientos existen? Son algunos peores que otros? Surgieron
diversos estudios de acoplamientos con tipos ligeramente diferentes [9.2, 9.3, 9.10];
resumiremos los puntos sobre los cuales hay un acuerdo general.
1. Acoplamiento de datos. Est claro que la forma ms deseada de acoplar es donde un
mdulo le trasfiere datos a otro como parte de la invocacin o del retomo del control. Este es
el mejor acoplamiento debido a que es acoplamiento mnimo. Los dos mdulos que se
muestran a continuacin estn acoplados por datos. En general un diseo en el cul se
trasfieren entre mdulos pocas porciones de datos es ms modificable que otro en el que se
transfieren muchos datos:
190
www.FreeLibros.org
El acoplamiento es ms claro y fcil de seguir cuando los elementos de datos se trasfieren
como parmetros en una interfaz entre mdulos, en vez de que el dato sea parte de un conjunto
global o comn, al que pueden tener acceso todos los mdulos. Uno de los problemas de
cambiabilidad que aparece en el COBOL proviene del hecho que todos los mdulos
(secciones o pargrafos) dentro de un programa COBOL dado, tienen acceso a la totalidad de
la divisin de datos, especialmente el almacenamiento de trabajo. Por lo tanto cada mdulo
dentro del programa tiene, en teora, acoplamiento-por-datos a cualquier otro dato. A
menudo es valioso establecer en forma separada un rea de almacenamiento de trabajo que
pertenezca a cada mdulo y no pueda ser utilizada por ningn otro mdulo excepto para la
trasferencia explcita de datos como se ha ilustrado ms arribaj( Esta situacin tambin es v
lida para las sentencias de FORTRAN COMMON, pero es posible una implementacin
alternativa de FORTRAN mediante la trasferencia de parmetros explcitos).
2. Acoplamiento de control. Idealmente un sistema podr disearse solo con acopla
mientos de datos explcitos de mdulo a mdulo. Sin embargo cada vez que un mdulo de
trabajo lee, graba, o entra de alguna otra manera en contacto con el mundo exterior, tiene que
informar a su jefe lo ocurrido; puede alcanzar fm-de-archivo, o detectar que una transaccin
es invlida, o que un nmero de cuenta no est en el archivo. Esta informacin de retorno
involucra trasferir una variable de control, como vimos en la Fig. 9.10.
El acoplamiento de control tiene un efecto ms serio sobre la cambiabilidad que el
acoplamiento de datos y debe mantenerse al mnimo absoluto necesario para que funcione el
sistema. A medida que aumenta la cantidad de interruptores y seales, se hace ms compleja
la tarea del programador de mantenimiento. Las seales de control trasferidas hacia abajo de
la jerarqua, es decir, en el momento de invocacin, son indicaciones de que el mdulo
invocado no es caja negra; ser ejecutado en formas diferentes dependiendo de las seales de
control. Esta situacin no es deseable debido a que implica que el mdulo invocado contiene
una mezcla de funciones.
3. Acoplamiento patolgico/extemo/interno. Estos trminos se refieren al acoplamien
to rgido entre mdulos en el cual un mdulo apunta al interior de otro, ya sea para extraer
algunos datos definidos dentro del segundo mdulo, o para trasferir el control al interior del
segundo mdulo, o para modificar la forma de ejecutar dicho segundo mdulo. Ver Fig. 9.13.
Si, por ejemplo, un mdulo de salida lee un contador de transacciones que pertenece a un
mdulo de entrada, el acoplamiento entre los mdulos puede no ser visible, ya que el contador
de transacciones no es trasferido hacia arriba ni hacia abajo en la jerarqua. El programador
de mantenimiento puede modificar alegremente el mdulo LEER sin darse cuenta del dao
efectuado al mdulo de salida. Cuando una situacin se presenta tan raramente que no vale la
pena trasferir datos o control a lo largo de toda la jerarqua, puede justificarse un
acoplamiento severo de esta naturaleza. En general, sin embargo, cualquier forma de
acoplamiento que no sean datos o control, deber evitarse a toda costa; aqu es donde
comienza la onda sin fin. Esto implica que cuando estamos diseando los mdulos debemos
estar seguros de especificar explcitamente todos los datos o informacin de control
necesarios para que el mdulo funcione.
191
www.FreeLibros.org
transacciones
TCONT
Conexin
patolgica
Figura 9.13 Conexin patolgica.
IF TCONT GT 10000
THEN...
9.2.4 Mdulos bien formados: coherencia, cohesin, ligazn
Al mismo tiempo que se minimiza el acoplamiento debemos especificar mdulos
elegidos y formados lo mejor posible. Los trminos empleados para describir la cualidad del
mdulo coherencia, cohesin y ligazn indican la medida en la cual todas las partes de un
mdulo se corresponden entre s. Un mdulo altamente cohesivo, cuyas partes contribuyan
todas a una sola funcin, probablemente no necesite mucho acoplamiento con otros mdulos;
un mdulo pobremente cohesivo, a menudo una combinacin de partes no relacionadas,
probablemente necesite un alto acoplamiento con otros. Luego el bajo acoplamiento y la
alta cohesin van unidas de la mano y viceversa.
Diversos estudios identifican seis o siete tipos de cohesin entre mdulos. Describire
mos los tipos ms generalmente aceptados, desde el peor al mejor.
1. Cohesin coincidente (la peor): No puede apreciarse que los elementos del mdulo
lleven a cabo ninguna funcin definible. Estn all por accidente. Cuando una organizacin
impone como norma que los programas debern ser modulares y que ningn mdulo debe
contener ms de 50 sentencias, un programador tomar un listado de un programa de 2.000
sentencias y un par de tijeras y cortar el listado cada 50 lineas para hacer mdulos de las
partes. Estos mdulos fueron cohesivos por coincidencia.
2. Cohesin lgica (sigue a la peor): En este tipo de mdulos varias funciones
semejantes, pero ligeramente diferentes, estn combinadas juntas, configurando un mdulo
ms compacto que si cada funcin fuera programada separadamente. Un ejemplo tpico es un
mdulo que valida todos los tipos de transacciones empleando secciones comunes de
codificacin cuando corresponde y salteando otras partes de la codificacin cuando no son
requeridas por un tipo particular de transaccin. Un mdulo lgicamente cohesivo a menudo
requiere un interruptor de control al ser trasferido desde el mdulo que lo invoca, para
indicarle cmo debe ejecutarse en esa ocasin especfica. Las seales de control que se van
trasfiriendo hacia abajo de la jerarqua son entonces a menudo indicios de la presencia de
mdulos lgicamente cohesivos. Los mdulos de este tipo son a menudo difciles de
modificar, debido a que los circuitos lgicos que pasan a travs de ellos son complejos. Deben
ser remplazados por mdulos de propsitos especiales a razn de uno por funcin.
3. Cohesin temporal (de moderada a pobre): Los mdulos tales como inicializacin,
preparacin previa y reiniciacin automtica contienen una variedad de funciones cuyo
nico elemento comn es el de ser ejecutados al mismo tiempo. La cambiabilidad se mejora
aislando cada funcin en su propio mdulo.
192
www.FreeLibros.org
4. Cohesin de procedimiento (moderada): Este tipo de cohesin se encuentra donde
los mdulos han sido derivados de un diagrama de flujo y cada pedazo o procedimiento del
diagrama ha sido armado en un mdulo. Dentro de cada mdulo se ejecutan varias funciones,
pero por lo menos las funciones estn relacionadas a travs del flujo de control entre ellas.
5. Cohesin de comunicacin (moderada a buena). Las funciones componentes de un
mdulo con cohesin de comunicacin operan todas sobre la misma comente de datos
adems de ser cohesivas de procedimiento. Algunas descripciones de mdulos de comunica
cin podran ser Representar el resultado y grabar registro del diario, Leer sentencia
fuente y eliminar blancos y Calcular solucin e imprimir resultado.
6. Cohesin funcional (la mejor): Un mdulo funcionalmente cohesivo, que es nuestro
ideal, realiza una y solo una funcin identificable. Una prueba para un mdulo funcional es
ver si puede ser acusado como de comunicacin, de procedimiento, temporal o lgicamente
cohesivo. Si es inocente de estos cargos, probablemente sea funcional. Los mdulos fun
cionalmente cohesivos pueden comnmente describirse por medio de una sola frase, con un
verbo activo y un objeto nico del tipo que hemos encontrado antes, tales como Calcular la
mejor solucin, Validar consulta y Representar respuesta. Una gua para determinar el
nivel de cohesin de un mdulo es escribir una sola oracin comenzando con El propsito
total de este mdulo es ... y luego examinar esta oracin. Si la misma no puede ser
completada, el mdulo es posiblemente solo cohesivo coincidentemente. Si la sentencia tiene
un objetivo plural e incluye la palabra todas, por ejemplo, Validar todas las transacciones
el mdulo probablemente sea lgicamente cohesivo. Si la oracin emplea palabras que
guardan relacin con tiempo o secuencia primero, prximo, luego, despus, de otra
manera, comienzo podr ser cohesivo temporal, de procedimiento o de comunicacin. Si la
oracin consiste en un solo verbo activo con un objeto no plural, el mdulo probablemente sea
fncionalmente cohesivo. Una de las razones para tomarse el trabajo en describir los procesos
lgicos que identificamos durante el anlisis en trminos funcionales, es que hacindolo as se
facilita al diseador la identificacin de mdulos funcionales a partir del diagrama de flujo de
datos. As como conociendo la tercera forma normal es ms probable que el analista pueda
identificar almacenamientos de datos lgicos simples, conociendo la cohesin funcional es
ms probable que el analista pueda identificar procesos simples.
9.2.5 Problemas de alcance de efecto/alcance de control
Suponiendo que hemos diseado una jerarqua utilizando estas guas para minimizar el
acoplamiento y maximizar la cohesin, hay otro refinamiento que considerar.
En algunos casos un mdulo puederoontener lgica para tomar una decisin sobre algn
acontecimiento; basado en esta decisin el mdulo invocar otros mdulos. La,.Fig. 9.14
muestra un caso simple.
Figura 9.14 Diagrama de estructura indicando el alcance de efecto dentro del alcance de control.
193
www.FreeLibros.org
El denominado alcance del efecto de la decisin son los dos mdulos que estn por
debajo de CALCULAR PREMIO; la decisin tiene un efecto en base al cual ser invocado
uno de ellos. El llamada/cance del control de un mdulo son todos los mdulos que el llama,
y todos los mdulos llamados por ellos, etc.
En la Fig. 9.14 el alcance del control de CALCULAR PREMIO cubre a los tres
mdulos llamados por l. El alcance del efecto de la decisin sobre la edad est entonces
dentro del alcance del control del mdulo que toma la decisin; as es como debe suceder. As
como un oficial no impartir rdenes a la tropa que no se encuentra bajo su mando, ningn
mdulo tomar una decisin que afecte a mdulos fuera de su alcance de control.
Pero supongamos que el diseo fuera como el de la Fig. 9.15. Los pequeos rombos con
flechas de invocacin salientes indican que se toma una decisin en alguna parte del mdulo,
y cules sern los mdulos subordinados que se invoquen depender de dicha decisin.
Hemos indicado la lgica de la decisin en cada caso.
Figura 9.15 Diagrama de estructura indicando el alcance de efecto fuera del alcance de control.
Ahora el alcance de efecto de la decisin original es ms amplio; cubre no solo los
mdulos llamados por CALCULAR PREMIO sino tambin a los dos llamados por
CALCULAR CARGA, ya que CALCULAR PREMIO pasa un elemento de control,
ESTADO, a CALCULAR CARGA, el cual determina qu mdulo inferior se va a llamar.
El alcance del efecto de la decisin no permanece ms dentro del alcance del control del
mdulo que contiene la decisin. Esto no es deseable por varias razones: crea acoplamiento
de control entre mdulos (va la seal de control ESTADO, en este caso), crea decisiones
duplicadas las cuales pueden crear problemas de mantenimiento, y confunde el efecto de la
decisin.
La estructura deber disearse nuevamente para llevar el alcance del efecto de la
decisin dentro del alcance del control del mdulo que contiene la decisin, como se muestra
en la Fig. 9.16. En esta estructura modular no es necesario ningn acoplamiento de control y
la decisin sobre la edad se toma una sola vez.
El diseador deber estar vigilando la oposicin del alcance de control/alcance de efecto
a medida que el diseo avanza.
194
www.FreeLibros.org
F i g u r a 9.16 Diagrama de estructura indicando el alcance de control dentro del alcancede efecto.
Su presencia a menudo es sealada por variables de control innecesarias, como vimos en
el ejemplo.
Derivar la estructura a partir del (lujo de datos
Cntrela en trasformacin donde entrada/salida es homognea.
Centrada en transaccin donde diferentes tipos de estructuras de datos son procesados en
forma diferente.
Minimizar el acoplamiento inter-modular
Acoplamiento de datos en cuanto sea posible.
Acoplamiento de contral tan pequeo como sea necesaria
Acopiamiento ms riguroso solo bajo protesta
Maximizar la cohesin del mdulo
Mdulos funcionales en cuanto sea posible.
Evitar mdulos cohesivos lgicamente o por coincidencia a toda costa
Verificar posibles oposiciones de alcance de control/alcance de efecto
Figura 9.17 Guas para producir diseos modulares modificables.
Podemos resumir las guias principales del diseo estructurado tal como se indica en la
Fig. 9.17.
195
www.FreeLibros.org
9.3 LA SOLUCION DE COMPROMISO ENTRE CAM8IABILIDAD Y RENDIMIENTO
Ahora que hemos discutido los factores que contribuyen a un diseo modificable,
podemos considerar el impacto de la cambiabilidad sobre el rendimiento y las soluciones de
compromiso que el diseador tiene que tomar.
Muchos diseadores al encontrarse con tcnicas de diseo estructurado por primera vez
temieron que las mismas tuvieran un serio efecto sobre el rendimiento de cualquier sistema
diseado para ser modificable. Esto proviene principalmente de dos factores:
1. Disear un sistema como un conjunto de pequeos mdulos modificables, en lugar de
algunos programas grandes, podra involucrar una mayor estructura superior, causada por
mdulos que llaman a otros mdulos.
2. Evitar mdulos pobremente cohesivos podria significar dividir un mdulo de
propsito general lgicamente cohesivo, digamos, en varios mdulos funcionales, dando
como resultado programas que requeriran ms memoria.
Adems, aunque no lo discutimos especficamente, si se utiliza programacin estructu
rada para la codificacin de los mdulos, se puede producir una cantidad relativamente mayor
de instrucciones de mquina que si se utilizaran mtodos ms tradicionales con ardides de
codificacin para una mayor eficiencia de mquina. (Se acepta generalmente que la
programacin estructurada produce codificaciones que son ms fciles de leer y depurar, los
estudios indican que la codificacin estructurada puede ser a veces ligeramente ms larga y
ms lenta que la codificacin tradicional [9.11] pero a veces ms reducida y veloz [9.12].
Estas preocupaciones acerca del rendimiento no pueden ocultarse bajo la alfombra, si
bien en muchos aspectos no se justifica la preocupacin sobre ello. Realmente, el hecho
singular es que los diseos modificables pueden producir actualmente mejor rendimiento que
los diseos tradicionales. Consideremos los siguientes hechos:
1. Hemos indicado que algunos de los factores ms importantes del rendimiento de los
sistemas orientados a datos eran los archivos innecesarios, pasadas de archivos y lecturas. El
diseo estructurado no empeora estos efectos; por el contrario, la produccin de la jerarqua
de mdulos lgicos alienta al diseador a evitar archivos intermedios y a buscar cmo
optimizar el acceso de archivos.
2. Hemos indicado que la cantidad de codificacin generada y el tiempo perdido en la
trasferencia del control entre mdulos en la memoria principal era de mucho menor
importancia en los sistemas orientados a datos que las trasferencias y accesos de archivos,
excepto en el caso donde el llamado de un mdulo origine la lectura de un archivo de
biblioteca o una operacin de paginado en un sistema de memoria virtual. Salvo estas
excepciones, la produccin de un diseo modificable afecta al factor de rendimiento de
importancia mnima.
3. Es difcil conocer por anticipado dnde se producirn los cuellos de botella en el
rendimiento de un sistema, en especial en un entorno operativo complejo. Lo que necesitamos
ser capaces de hacer es implementar un sistema donde los problemas ms importantes de
rendimiento hayan sido resueltos, ensayar el sistema con datos reales y medir dnde se
insume el tiempo, ya sea en la entrada/salida, en los clculos o en la estructura superior del
sistema. Una vez que conocemos por medicin dnde estn los cuellos de botella debemos ser
capaces de modificar el sistema para eliminarlos. Tpicamente, el tipo de cambios necesarios
para mejorar el rendimiento ser volver a escribir la tabla de bsqueda que consume tiempo en
lenguaje assembler, cambiar la estructura de superposicin para asegurar que la seccin
frecuentemente llamada est siempre en la memoria principal, o modificar los detalles de
acceso a los archivos. En el pasado era difcil y costoso hacer esta optimizacin de post-
implementacin. Por qu? Debido a que los sistemas haban sido diseados de tal forma que
eran difciles de modificar sin introducir el efecto onda! El hecho cierto de que ahora estemos
diseando nuestros sistemas para poder ser modificados significa que podemos optimizar sus
rendimientos rpida y fcilmente una vez que sabemos qu partes necesitan mejorarse.
196
www.FreeLibros.org
La solucin de compromiso entre cambiabilidad y rendimiento es en consecuencia
paradjica. Si el diseador se preocupa mucho por los detalles finos jiel rendimiento del
sistema durante el diseo, existe la posibilidad de introducir cohesin lgica y severo
acoplamiento a travs de la estructura modular, al intentar economizar memoria y tiempo de
ejecucin. Todos estos hechos harn dificultoso y costoso mejorar el rendimiento del sistema
una vez que haya sido implementado.
As, cul es la moraleja? El diseador necesita adoptar una aproximacin de seis pasos:
Paso 1. Obtener el diseo fsico tentativo global del sistema y los archivos principales a
partir del modelo lgico, con la menor cantidad de archivos intermedios, las menores pasadas
posibles de archivos, y la menor cantidad posible de bsquedas en estos archivos
suplementarios.
Paso 2. Incluir los controles necesarios, tratando de minimizar cualquier efecto
degradante del rendimiento. (El diagrama de flujo de datos es una herramienta til para
presentar a los auditores para la discusin de los controles de auditora).
Paso 3. Disear la estructura de mdulos lgicos para mxima cambiabilidad, sin
prestar atencin en este paso al rendimiento del sistema final (salvo los aspectos ya tratados
en los pasos 1 y 2).
Paso 4. Estudiar los mdulos lgicos en la estructura jerrquica para estimar el tamao
de los mdulos fsicos que ser necesario implementar. Observar aquellos mdulos que se
invocarn frecuentemente (en cada transaccin o en cada elemento de datos), y observar
aquellos que se invocarn menos frecuentemente durante la ejecucin (por ejemplo, rutinas
de tratamiento de errores, inicializacin o terminacin). Elegir un embalaje fsico de los
mdulos lgicos en programas, subprogramas o secciones, de manera que, hasta donde sea
posible, los mdulos llamados frecuentemente estn en la memoria al tiempo de ser llamados;
es decir, se minimizar la cantidad de bsquedas de las bibliotecas de programas.
Paso 5. Implementar el sistema como se especific en el paso 4 sin comprometer
adicionalmente la cambiabilidad del diseo, excepto en los casos donde el rendimiento es tan
vital que sobrepasa la importancia de la cambiabilidad. En estos casos existe el compromiso
en combinar mdulos y compartir recursos, pero esto debe hacerse en la menor medida
posible.
Paso 6. Ejecutar el sistema con datos representativos y utilizar un monitor de tiempo de
ejecucin para medir qu partes del sistema toman la mayor proporcin del tiempo de
ejecucin o identificar qu mdulos estn causando problemas de memoria. Cambiar estas
partes para hacerlas ms rpidas o pequeas, segn sea el caso. En un entorno de memoria
virtual, redistribuir el orden fsico de los mdulos en la biblioteca apropiada para lograr el
conjunto de trabajo (aquellos mdulos que se utilizan frecuentemente), todos dentro del
menor nmero de pginas. Considerar la posibilidad de dejar fijo el conjunto de trabajo en
memoria real, si el sistema operativo lo permite.
Repetir el paso 6 hasta que el sistema satisfaga los objetivos de rendimiento. E1diseo de
sistemas orientados a algoritmos, puede en principio seguir incluso los pasos delineados
anteriormente. Particularmente en sistemas muy complejos, las pruebas y la depuracin
necesarias se vern favorecidas si se mantienen las funciones lo ms aisladas posibles hasta
que pueda demostrarse que todas las funciones del sistema trabajan correctamente, pudiendo
comenzarse entonces con la optimizacin.
9.4 UN EJEMPLO DE DISEO ESTRUCTURADO
En esta seccin aplicaremos las guas y tcnicas discutidas anteriormente en el captulo
para el nuevo sistema de la Corporacin CBM. Vamos a asumir que se ha seguido la
metodologa discutida en el Captulo S y que los usuarios han optado por la alternativa del
presupuesto medio, en el cual los pedidos de libros ingresan al sistema va terminales CRT y
se validan en linea; los archivos de tem despachables y no despachables se generan durante el
197
www.FreeLibros.org
da. Las notas de despacho se imprimen desde estos archivos durante la noche junto con las
facturas. Los niveles de inventario se ajustan a medida que van entrando los pedidos, pero el
control del inventario y de los puntos de pedido son atendidos por un subsistema separado que
verifica el stock disponible al finalizar cada dia. Compras, cuentas a cobrar y cuentas a pagar
son subsistemas separados, en lote. Algunos informes son creados en modo lote; hay
facilidades de consulta disponibles en algunos de los archivos.
9.4.1 Los lmites del diseo
A los fines de este ejercicio disearemos el subsistema de entrada de pedidos cuyos
limites se definen en la Fig. 9.18 (que muestra un extracto de todo el diagrama de flujo de
datos). Para simplificar, disearemos una versin inicial que atender aquellos pedidos que
no han sido pagados previamente, es decir, aquellos que solicitan crdito. Como muestra el
diagrama de flujo de datos, la entrada de los detalles de nuevos clientes se encuentra fuera del
lmite de nuestro diseo. De hecho, cuando se observa que un pedido no proviene de un cliente
existente, o se nota un cambio en la direccin, es encaminado hacia el supervisor de entrada
de pedidos, el cual ingresa los detalles en el archivo de CLIENTES regresando despus el
pedido al sistema para su procesamiento normal. Tenemos entonces que disear un sistema
que maneje los tres procesos:
1. Validar pedidos (omitiendo los pagos previos, por ahora)
2. Verificar que el crdito sea correcto
3. Verificar el inventario disponible y ajustar el nivel de stock.
La Fig. 9.19 muestra las explosiones de cada uno de estos procesos, junto con algn
detalle del flujo de datos en el proceso manual de tomar el pedido escrito o telefnico y
entrarlo en el CRT. Estos procesos estn numerados MI, M2, etc. ya que son parte de un
proceso que no aparece como tal en el diagrama global de flujo de datos.
9.4.2 Consideraciones del diseo del archivo fsico
Antes de considerar la construccin de la jerarqua modular, consideraremos algunos de
los factores de la especificacin del archivo fsico, ya que ellos clarificarn el DFD y el diseo
modular.
1. DM/1: A UTOR/UTULO-INDICE, en el proceso M-Entrada Manual Cuando
analizamos el almacenamiento de datos que describa los libros en el Captulo 6, indicamos
que el nico identificador de un libro era el ISBN. A1mismo tiempo, los clientes piden un libro
especificando su ttulo y autor y al editor cuando se lo conoce. Cuando vamos a ingresar los
pedidos de libros tenemos, entonces, la necesidad de un acceso inmediato a LIBRO-
TITULO o AUTOR o a ambos para encontrar el ISBN. Esto podr hacerse proveyendo
ndices secundarios al archivo de LIBROS y permitiendo el acceso va los CRT al
Departamento Entrada de Pedidos. Las caractersticas del archivo debern sen
Cantidad de registros: alrededor de 1.500 libros sobre computacin son los conocidos
por CBM.
Cantidad de accesos: uno por cada item pedido.
Volatilidad (rgimen de cambios del archivo): alrededor de 20 nuevos libros por mes.
C uando vemos un archivo pequeo con baja volatilidad como ste, que requiere accesos
mltiples, nos debemos preguntar si no es factible proveer a los usuarios una salida impresa
del archivo pre-clasificado de diferentes formas en lugarde crear y mantener ndices. Durante
el diseo tentativo para la alternativa del presupuesto medio, el diseador decidi ahorrar
dinero de esta manera.
198 www.FreeLibros.org
CUENTES
\
1
Validar
pedido y
pago previo
(si se presentan]
Entrar
detalles
\ clientes nuevos '
\ y modificaciones j
\ s ' /
Pedidos
con
crdito OK
Verificar
inventario ,
disponible
y aiustar
nivel
de stock
/ Item no despachables
i (fuera de stock o agotados)
Item despachables
Pedidos con pago previo
Notas de crdito
r
Verificar
crdito
OK
Entrar
detalles de
pago previo
Generar
nota de
embarco y
factura
Requerimiento de pago previo
D3
Detalles
factura/
pagos
CUENTAS A COBRAR
Nota de embarco y factura (con libros)
Pagos
4 "
Aplicar
pagos a
facturas
V ... )
F i g u r a 9 . 1 8 Subsistema de entrada de pedidos.
A cada empleado de entrada de pedidos se le provee un listado impreso de computadora
con todos los ttulos conocidos, con su autor, editor y el ISBN. Debido a las formas variadas
en que la gente recuerda los ttulos de los libros (este libro podra citarse como Anlisis
estructurado. Herramientas de anlisis de sistemas. Tcnicas de sistemas estructurados,
etc.), el listado se provee como un ndice de palabra clave del contexto(KWIC: KeyWord-In-
Context) en el cual el titulo aparece una vez por cada palabra importante en l y la lista de
ttulos es clasificada por cada palabra. Un resumen de la seccin S del ndice KWIC es el
siguiente:
199
www.FreeLibros.org
ENTRADA MANUAL
Pedido
M1
Extractar
identificacin
cliente
V_
Org.-nombre/
cdigo postal
M3
Extractar
detalles
direccin
Direccin,
oficina postal N1,
nombre del
contacto
M5
Extractar
tem
libro
Titulo/
autor
M6
Averi
guar
ISBN
ISBN
Org.-nombre, cdigo
postal interno
M4
Verificar
direccin
cliente y
Direccin cliente
entrar contacto Contacta oficina postal N, cliente vlido
y oficina
I y
ISBN
postai N
M7
Direccin invlida
o cliente nuevo
Entrar
ISBN
M8
ISBN
interno
Verificar
libro
y
entrar
cantidad
SEP (supervisor
entrada de pedidos)
Titulo/autor
Item libro, cantidad pedido
ISBN libro
invalidado
Libros inexistentes
SEP
DM/1 INDICE AUTOR/TITULO
Supervisor
entrada pedido
Figura 9.19 (parte 1) Explosiones.
SYSTEMS ANALYSIS AND DESIGN USING NETWORK TECHNIQUES
(Anlisis y Diseo de Sistemas utilizando tcnicas de red)
Whitehouse ISBN ...................
STRUCTURED SYSTEMS ANALYSIS: tools and techniques
(Anlisis Estructurado de Sistemas; herramientas y tcnicas)
200
www.FreeLibros.org
1 VALIDAR PEDIDOS
Fecha
del da
1.4
Obtener
fecha
del da
Pedido N
(org.-id. fecha)
contacto, oficina postal N"
PEDIDO)
IDENT
Pedido vlido
pedido-ident.
Item de libros+)
cantidad pedida
Figura 9.19 (parte 2)
Gane, Sarson ISBN .....................................
INTRODUCTION TO SYSTEMS SAFETY ENGINEERING
(Introduccin a la Ingeniera de Seguridad de Sistemas)
Rodgers ISBN........................................................
INTRODUCTION TO GENERAL SYSTEMS THINKING
(Introduccin al pensamiento general de sistemas)
Weinberg I S B N ...............................................
El libro de Whitehouse tambin aparecer bajo ANALISIS, DISEO, RED y
TECNICAS; el libro de Weinbetg tambin aparecer bajoGENERAL y PENSAMIENTO,
etc. Luego para localizar cualquier libro el empleado de entrada de pedidos podr tomar la
- 201
www.FreeLibros.org
0 3 CUENTAS A COBRAR
Figura 9.19 (parte 3).
palabra ms significativa del ttulo, buscar en el ndice K WIC. y explorar a travs de todos los
libros que contengan esa palabra en cualquier lugar del ttulo hasta localizarlo. El ndice
K.WIC provee alguna ayuda para aconsejar a los clientes sobre libros referidos a un topco
dado.
Si el cliente especifica al autor pero es vago sobre el titulo o el ttulo no se puede
encontrar en el ndice KWIC, el empleado de entrada de pedidos puede utilizar un segundo
impreso con los libros listados en secuencia de AUTOR.
Las salidas impresas se producen una vez por mes (del archivo LIBROS), con la fecha
actualizada impresa con claridad sobre las mismas; cada semana, cualquier agregado o
202
www.FreeLibros.org
cambio que haya tenido lugar circula como hojas actualizadas que deben ser agregadas al
frente de cada impreso.
2. D2: LIBROS, con acceso desde el proceso l- Validar pedidos. Una vez que el ISBN
de cada libro ha sido determinado y entrado al sistema, los detalles del libro deben ser
representados ante el empleado de entrada de pedidos como una doble verificacin de que se
utiliza el ISBN correcto. El archivo LIBROS contiene la misma informacin que el ndice
TITULO/AUTOR, con el agregado del precio actual de cada libro. Es un archivo pequeo
203
www.FreeLibros.org
1.500 registros con un promedio de 100 caracteres, o sea, 150.000 caracteres. Toda vez
que, como mostr en el Captulo 6, tanto LIBROS como INVENTARIO estn organizados
por ISBN, el diseador consider que ambos podan estar-combinados y contenidos en un
solo archivo fsico, pero decidi lo contrario, ya que del total de esos 1.500 ttulos, solo 100-
200 se conservarn en inventario. Tambin el archivo LIBROS,que ser mantenido cada
noche, ser ledo, pero no actualizado, de da. En consecuencia, no ser necesario tener
copias de respaldo con fines de seguridad. Los datos de INVENTARIO sern actualizados
constantemente, por lo que ser necesario copiarlo por seguridad a intervalos frecuentes, ya
que resultara muy inconveniente perder el registro de lo que hay en stock. Como objetivo
menor en orden al rendimiento, podra ser ventajoso poner LIBROS e INVENTARIO en
unidades de discos separadas y ocupando el resto de cada unidad con archivos de baja
actividad tales como PEDIDOS-PENDIENTES-DE-ENTREGA, PEDIDOS-ESPE
CIALES o PEDIDOS-QUE-REQUIEREN-PAGO. En cada caso el archivo de alta
actividad es pequeo y solo ocupar unas pocas pistas. La cabeza lectora grabadora deber
entonces perder la mayor parte del tiempo en ubicarse sobre el archivo activo, reduciendo el
tiempo de bsqueda a un mnimo.
Si la gerencia de CBM tiene xito en atraer 1.000 pedidos por da, y cada pedido,
digamos, por tres libros, y si muchos de los pedidos son telefnicos, habr una actividad
durante el perodo pico de la maana (10,30 a 11,30 horas) de 700-800 item que requerirn
un acceso a LIBROS y un acceso a INVENTARIO. Esto significa un acceso cada 4
segundos en la hora pico, lo cual, sin llegar a ser abrumador, no es despreciable.
3. DI: CLIENTES; con acceso desde proceso I-Validar pedidos. Dijimos en el
Captulo 6 que el almacenamiento de datos lgico CLIENTES consista en registros que
describen tanto a las empresas como a las personas dentro de las organizaciones. La nica
definicin de una organizacin es la clave ORG-ID, consistente en cinco dgitos que
especifican la organizacin, ms dos dgitos que especifican una ubicacin particular, ms un
dgito verificador. Habr de 10.000-20.000 clientes de CBM en el nuevo sistema, contando
cada ubicacin como un cliente separado, con mltiples contactos potenciales en cada una. E1
diseador ha decidido en este sistema de presupuesto medio, no almacenar el contacto pero s
ingresar el nombre de la persona que coloca el pedido (y el nmero del pedido del cliente,
cuando exista) con los detalles del pedido. La estructura de datos del archivo CLIENTES
ser
ORG-ID
ORG-CODIGO
UBICACION-CODIGO
DIGITO-VERIFICADOR
ORGANIZACION-NOMBRE
ORGANIZACION-DIRECCION
CALLE
CIUDAD
ESTADO
CODIGO-POSTAL
TELEFONO-PRINCIPAL
Observamos que esta decisin significa que no ser posible recuperar los telfonos de los
CONTACTOS individuales; si necesitramos hablarles tendramos que hacerlo a travs de
su conmutador. Los registros de ORGANIZACION requieren un promedio de 150
caracteres, cada registro de CONTACTO requiere un promedio de 60 caracteres y hay un
promedio de 1,8 contactos por ubicacin. El diseador ha reducido pues los requisitos del
disco en lnea de aproximadamente 5 millones a 3 millones de caracteres (20.000
organizaciones x 150 =3 millones de caracteres; 20.000x1,8 x 60 contactos =2,16
millones de caracteres). Un pequeo ahorro por una pequea penalidad; ste es el contenido
del diseo fsico.
204
www.FreeLibros.org
Muchos clientes desconocen su ORG-ID y por eso muchos pedidos no lo traern. (Con
cada despacho, el analista prev enviar formularios de pedido pre-impresos con ei ORG-ID
del cliente, pero ello representar la minora de los pedidos recibidos). Cmo hace el
empleado de entrada de pedidos para encontrar el ORG-ID de cada cliente de manera tal que
el pedido pueda ser procesado? Podemos adoptar la modalidad que se describi recin para
encontrar el ISBN y dar a cada empleado un listado de CLIENTES actualizado
regularmente. Si bien ello es factible para 1.500 libros, se vuelve engorroso para 20.000
clientes. En consecuencia, el diseador ha decidido proveer una capacidad de ndice
secundario dentro del archivo de CLIENTES por ORGANIZACION-NOMBRE y/o
CODIGO-POSTAL, como se muestra en el DIAD de la Fig. 9.20. Esto significa que el
acceso inmediato delineado en la F ig. 9.21 es factible para el empleado de entrada de pedidos.
Figura 9.20 DIAD.
Entrar El sistema representa
CODIGO-POSTAL ' Todas las organizaciones cuyas direcciones tienen
ese cdigo postal
ORGANIZACION-NOMBRE Todas las organizaciones con este nombre
ORGANIZACION-NOMBRE Todas las organizaciones con este nombre
y CODIGO-POSTAL en este cdigo postal
Figura 9.21 Accesos inmediatos.
Tpicamente, el empleado teclear el nombre de la organizacin como aparece en el
pedido, usando ciertas abreviaturas normales, ms el cdigo postal de la direccin del pedido
y recuperar el registro de toda la organizacin, que le mostrar el ORG-ID. Supuesto que la
direccin que se exhibe en la pantalla coincide con la direccin de! pedido, se pueden ingresar
los detalles del pedido. En el diagrama de flujo de datos de la Fig. 9.19, los procesos
correspondientes son M2, 1.1. 1.2. y M.4.
4. D3: CUENTAS A COBRAR, con acceso desde el proceso 3-Verificar crdito.
Aunque la parte esttica de CUENTAS A COBRAR podra combinarse con el registro de
CLIENTES sobre una base lgica, los auditores de CBM requieren que los registros
contables se mantengan separados de los otros archivos y solo puedan tener acceso desde
terminales instaladas en el Departamento de Contabilidad. La gerencia requiere que la
historia de los ltimos 6 meses de facturas y pagos se mantenga en lnea; cada seis meses los
registros correspondientes al perodo de antigedad de 7 meses deben ser grabados en cinta y
almacenados en un depsito. En consecuencia CUENTAS A COBRAR deber armarse
205
www.FreeLibros.org
como un archivo fsico separado de CLIENTES, (Hacemos notar que un sistema
administrador de base de datos con dispositivos apropiados de seguridad nos permitir
satisfacer a los auditores y combinar aun asi los datos de CLIENTES con CUENTAS A
COBRAR),
CUENTAS A COBRAR ser un archivo algo mayor. Deber contener 20.000 cuentas
con la informacin maestra porcada ORG-ID. Debemos admitir 1.000 rdenes por da, las
cuales crean 1,2 facturas en promedio (algunos pedidos se llenarn en dos o tres partes y cada
parte deber facturarse separadamente), de lo cual resultar un mximo de 1.000
pedidos xl2Q das (6 meses) x l , 2 facturas, o 144.000 facturas en el archivo en todo
momento. Algunos pagos cubrirn ms de una factura; es razonable suponer unos 100.000
pagos. ConsiderandolOO caracteres por cada encabezamiento de registro y 30 caracteres por
cada registro de pago, tendremos una capacidad de archivo de
20.000 encabezamientos xlOO =2 millones
144.000 facturas x30 =4,3 millones
100.000 pagos x30 =3 millones
Total de caracteres: 9,3 millones
El archivo tendr acceso desde el subsistema de entrada de pedidos una vez por cada
pedido vlido, y por supuesto, desde otros subsistemas vinculados con facturas y pagos.
5. DI 5: ITEM DESPACHABLES, creado por el proceso 6- Verificar inventario
disponible. Puede considerarse que el objetivo principal de todo el subsistema de entrada de
pedidos es el de producir este archivo, que tiene un registro por cada tem que sea vlido, parte
de un pedido de un cliente con crdito yen stock de acuerdo con los registros de computadora.
E ste archivo se utilizar como la entrada principal del subsistema de despacho, el cual crear
notas de despacho basadas en las cantidades reales embarcadas del stock y alimentar al
subsistema de facturacin con informacin del cumplimiento de cada pedido.
La estructura de datos del archivo es:
PEDIDO-IDENTIFICACION
PEDIDO-NUMERO
ORG-ID
PEDIDO-FECHA (tal como la recibi el sistema)
CONTACTO-NOMBRE
(CLIENTE-COMPRA-NUMERO] (ingresar solo si est disponible)
ISBN
CANTIDAD-PEDIDA
CANTIDAD-DESPACHABLE
Debemos observar que en realidad es un archivo intermedio, creado porque hemos
descompuesto el sistema total en subsistemas.
6. Otros archivos creados por el subsistema. D 13: PEDIDOS QUE REQUIEREN
PREVIO PAGO contiene aquellos pedidos de clientes que no tienen crdito vlido de
acuerdo con la lgica de la poltica del proceso 3.2. Contiene detalles de los pedidos que han
sido colocados y es la entrada a un subsistema que representa cada pedido, con la historia del
crdito de los clientes para que el Departamento de Contabilidad determine finalmente si el
crdito va a ser acordado o no.
D8: PEDIDOS PENDIENTES DE ENTREGA Y DI4: PEDIDOS ESPECIA
LES tienen la misma estructura que ITEM DESPACHABLES pero reflejan los casos donde
el tem no tiene existencia o es uno de los 1.300 ttulos que no se encuentran en el inventario.
D8: HISTORIA PEDIDO contiene un registro completo por cada pedido vlido, sea
despachable o no. Se emplea como base del anlisis de demanda de libros y en el informe a la
gerencia. Se utilizar para consultas de clientes, cuando este subsistema sea implementado.
206
www.FreeLibros.org
9.4.3 Ubicacin de la trasformacin central en el diagrama de flujo de datos
Si revisamos el diagrama de flujo de datos de la Fig. 9.19 a la luz de los archivos fsicos,
resulta difcil a simple vista saber cmo corresponde el mismo al modelo simple de entrada-
trasformacin-salida descrito en la Sec. 9.2.
El subsistema manual descompone cada pedido en los tem de libros componentes para
ingresarlos y validarlos contra el archivo de LIBROS. El proceso 1.5 combina nuevamente
los tem en un pedido vlido (con los precios agregados a cada tem) de manera que la cantidad
total del pedido se pueda calcular y utilizar para decidir si puede acordarse al cliente este
crdito adicional. (Cuando el diseo se extienda a la atencin de los pagos previos,
necesitaremos el importe total de cada pedido para verificar que se ha enviado el importe
correcto con el pedido). Una vez que se ha establecido el crdito, el pedido debe
descomponerse nuevamente en tem por el proceso 6.2 para verificarlo contra el inventario.
Dnde se hace visible por primera vez como salida la corriente de salida principal de
ITEM DESPACHABLES?: en el flujo de datos de salida Item despachables del proceso
6.3. A partir de este razonamiento podemos ver que el proceso 6.3 representa la funcin
central del sistema y los puntos de mayor abstraccin de entrada y salida estn a ambos lados
del mismo, como se muestra en la Fig. 9.22. Esto puede parecer algo raro ya que implica que
la mayora del sistema est en el tramo de entrada y muy poco en el tramo de salida. Con
todo, no es lo que uno esperaba de un sistema de entrada de pedido? Ahora sabemos que
podemos derivar una estructura de alto nivel de la jerarqua modular estableciendo un mdulo
que llama por un tem de pedido vlido, lo compara con el inventario y graba registros
apropiadamente. Adems, vemos que tenemos en el tope de la jerarqua un centro de
transaccin, antes que un centro de trasformacin. El flujo de datos se divide en tres
trayectorias diferentes que dependen de la situacin del inventario. La Fig. 9.23 muestra
dicha estructura de alto nivel.
ENTRADA HASTA AQUI SALIDA DESDE AQUI
Figura 9.22 Proceso central del subsistema de entrada del pedido.
9.4.4 Perfeccionamiento del diseo desde arriba hacia abajo
El mdulo DETERMINAR PROVISION ITEM juega el papel de analizador,
determinando qu tipo de transaccin est siendo atendida. La funcin de despachar est
contenida en el mdulo principal PROCESAR PEDIDOS, como se ve en el smbolo de
decisin que llama a mdulos que atienden el caso dondeeltem es, obiendespachable, obien
sin existencia, o ambos (en caso en que to haya suficiente cantidad de tem para completar el
pedido). La flecha curva que atraviesa a todas las flechas de invocacin, indica que existe un
lazo dentro de PROCESAR PEDIDOS; el cual invoca a todos los mdulos inferiores cada
207
www.FreeLibros.org
Item pedido
terrt pedido
^provisto/no provisto
^Tipo de tem
OBTENER ITEM
DETERMINAR DESPACHAR
PEDIDO PROVISION TIPO-ITEM
VALIDO ITEM
Item pedido
no provisto
PROCESAR
PROCESAR ITEM PROCESAR
ITEM PARCIALMENTE ITEM NO
PROVISTOS PROVISTOS PROVISTOS
GRABAR ACTUAt IZAR GRABAR GRABAR
REGISTRO ITEM NIVEL REGISTRO PEDIDO REGISTRO PEDIDO
DESPACHABLES INVENTARIO PENDIENTE ENTREGA
i________________i
ESPECIAL
Figura 9.24 Perfeccionamiento o refinacin del diseo.
*AO www.FreeLibros.org
vez que un tem es procesado. ACTUALIZAR INVENTARIO no ser llamado si el tem
est fuera de stock o si el inventario ya est en cero (sin existencia). El prximo
perfeccionamiento del borrador de este diseo, como se ve en la Fig. 9.24, especifica las
funciones del tramo de salida en mayordetalle. Creamos un mdulo de despacho que invoca
un mdulo separado para tratar cada una de las tres circunstancias, ya sea que un tem de
pedido pueda cumplirse completamente (la situacin ms frecuente), o que pueda
completarse parcialmente, o que no pueda cumplirse de ninguna manera. El despachador
sigue siendo muy simple realmente trivial ya que solo tiene que llamar al mdulo
apropiado; la lgica para determinar las distintas acciones est contenida en esos mdulos
que son llamados. Realmente el despachador es tan simple que aun mostrndolo como un
mdulo separado en el diagrama de estructura podemos pensar que ser implementado como
parte de la codificacin de PROCESAR PEDIDOS. El trmino que se emplea para esto es
inclusin lexicogrfica de un mdulo en otro; existen dos modules lgicos dentro de un
mdulo fsico. Esto se muestra en el diagrama de estructura mediante un tringulo achatado
en la parte superior del mdulo, como se ve en la Fig. 9.25.
PROCESAR
PEDIDOS
inclusin texicogrtic'
OBTENER ITEM
DETERMINAR
DESPACHAR
PEDIDO PROVISION
TIPO-
VALIDO ITEM
ITEM
, ^ > N i v e l p
^ v e i - inventario.
Item 1
,, Cantidad provista
Cantidad no provista
Nuevo nivel inventario
Fuera de stock
OBTENER I DETERMINAR PROCESAR PROCESAR ITEM PROCESAR
NIVEL | CANTIDAD ITEM PARCIALMENTE ITEM NO
INVENTARIO PROVISTA-NO PROVISTA
L .............. .................. ...............
PROVISTOS
PROVISTOS PROVISTOS
GRABAR
REGISTRO ITEM
DESPACHASTE
ACTUALIZAR
NIVEL
INVENTARIO
Igrabar registro)
EDI DO PENDIENTE
DE ENTREGA 1
GRABAR
REGISTRO
PEDIDO-
ESPECIAL
Decisiones duplicadas sobre "Item fuera de stock
Figura 9.25 Aparicin del problema de alcance de control/alcance de efecto.
En la Fig. 9.25 el analizador ha sido fracturado adicionalmente (o factoreado) en un
mdulo que obtiene el nivel de inventario para el tem que est siendo procesado, y un segundo
mdulo DETERMINAR CANTIDAD PROVISTA/NO PROVISTA que es llamado si el
tem est ordinariamente mantenido en stock.
209 www.FreeLibros.org
Ahora percibimos que tenemos en nuestras manos un conflicto de alcance de
control/alcance de efecto. Una decisin es tomada en DETERMINAR PROVISION ITEM
para saber si el tem est o no incluido en el inventario (basado en BUSCAR NIVEL
INVENTARIO y considerando que no hay registro de inventario). Pero esta misma decisin
se hace nuevamente en PROCESAR ITEM NO PROVISTOS para decidir si llama
GRABAR REGISTRO PEDIDO PENDIENTE DE ENTREGA o GRABAR REGIS
TRO PEDIDO ESPECIAL.
Cmo podemos resolver este conflicto y suprimir la toma de decisin duplicada?
Podemos procesar los pedidos especiales como parte de DETERMINAR PROVISION
ITEM, pero ello confundira la funcin del mdulo creando un mdulo cohesivo de
procedimiento. DETERMINAR PROVISION ITEM Y CUANDO EL ITEM ES UN
PEDIDO ESPECIAL, CREAR EL PEDIDO ESPECIAL. Una mejor aproximacin es
hacer que el mdulo central principal maneje la decisin solo una vez, llamando un mdulo
que atienda solo pedidos especiales. La solucin se muestra en la Fig. 9.26 donde se ha
incorporado la funcin analizadora y la funcin DETERMINAR CANTIDAD PROVIS
TA se ha desplazado a PROCESAR PEDIDOS, ya que podemos ver que ambas son
triviales.
Hemos hecho el mdulo de control principal muy complicado? Invocamos otros seis
mdulos llamados su espectro de control de manera que debemos ser cuidadosos en no
introducir demasiada complejidad. Vamos a expresar la lgica que necesitamos en
PROCESAR PEDIDOS mediante el empleo de pseudocdigo. La Fig. 9.27 muestra este
resultado.
GRABAR ACTUALIZAR GRABAR REGISTRO GRABAR
REGISTRO ITEM NIVEL PEDIDO REGISTRO
DESPACHABLE
INVENTARIO
PENDIENTE PEDIDO
DE ENTREGA ESPECIAL
Figura 9.26 Supresin de toma de decisiones duplicadas.
210
www.FreeLibros.org
OBTENER ITEM PEDIDO VAUDO
OBTENER NIVEL INVENTARIO
SI NO REGISTRO INVENTARIO
LUEGO HACER RUTINA-PEDIDO-ESPECIAl
SI NO (INCLUIDO EN INVENTARIO)
ENTONCES SI NIVEL-INVENTARIO ES CERO
LUEGO HACER RUTINA-PEDIDO-PENDIENTE-ENTREGA
SI NO (EXISTE STOCK)
ENTONCES RESTAR PEDIDO-CANTIDAD DE NIVEL
INVENTARIO DANDO NUEVO-NIVEL-
INVENTARIO
SI NUEVO-NIVEL-INVENTARIO
MIE CERO
LUEGO HACER RUTINA-PEDIDO-REPOSICION
SI NO (PEDIDO PARCIALMENTE REPUESTO)
ENTONCES RESTAR NIVEL-INVENTARIO DE PEDIDO-
CANTIDAD DANDO CANT-Ne-REPUESTA
HACER RUTINA-PEDIDO-PARCIALMENTE-
REPUESTO
FIN HACER
HACER MIENTRAS MAS ENTRADA
F i g u r a 9.27 Pseudo-codficacin para PROCESAR PEDIDOS.
Hasta aqu nos hemos dedicado en especial al tramo de salida del sistema. Es tiempo de
volver al ms extenso tramo de entrada todo aquello que est subordinado a BUSCAR
ITEM PEDIDO VALIDO y disearlo. La Fig. 9.28 muestra el primer paso; BUSCAR
ITEM PEDIDO VALIDO ha sido factoreado en BUSCAR PEDIDO VALIDO y
AISLAR PROXIMO ITEM. Cuando el ltimo tem de cada pedido ha sido procesado,
AISLAR PROXIMO ITEM pasar la seal No hay ms tem" a BUSCAR PEDIDO
VALIDO, despus de lo cual ste llamar al prximo pedido para luego llamar nuevamente a
AISLAR PROXIMO ITEM.
Qu est pasando en BUSCAR PEDIDO VALIDO? Podemos ver en el diagrama de
flujo de datos que estn involucradas varias funciones; ellas estarn bajo el control de
BUSCAR PEDIDO VALIDO, que es un subconjunto de la estructura, como se observa en la
Fig. 9.29. Vemos que CREAR HISTORIA-PEDIDO es una de esas funciones, una salida
subsidiaria que justamente surge de la corriente de datos de entrada en este punto.
Estrictamente hablando, CREAR HISTORIA-PEDIDO no tiene nada que hacer con
BUSCAR PEDIDO VALIDO, o con BUSCAR ITEM PEDIDO VALIDO en ese aspecto.
Es un ejemplo de efecto lateral, algo que se requiere al mdulo, aparte de su propia funcin.
Un programador de mantenimiento observando la codificacin de BUSCAR ITEM
PEDIDO VALIDO no podr saber por el nombre del mdulo que la historia del pedido ftie
creada como parte de una de sus sub-funciones. Podemos disear de nuevo la estructura de
manera que CREAR HISTORIA-PEDIDO se ubique en un lugar ms natural y
comprensible? Podramos trasladar la lgica de BUSCAR ITEM PEDIDO VALIDO hacia
el interior de PROCESAR PEDIDOS e invocarCREAR HISTORIA-PEDIDO desde all,
pero ello involucrar dos lazos anidados, como se ve en la Fig. 9.30; un lazo para atender
pedidos y otro lazo para atender tem. Este es un diseo indebidamente complejo: aun asi, su
simplificacin mediante la confeccin de un mdulo que atienda el procesamiento de tem,
como se muestra en la Fig. 9.31,implica cierta delegacin del trabajo real de manejar a!
sistema, a fin de operar algo que, despus de todo, es meramente una funcin de registracin.
No, debemos reconocer mejor que CREAR HISTORIA-PEDIDO es una salida lateral
subordinada a la funcin principal del sistema y aceptar que sea invocada por BUSCAR
211
www.FreeLibros.org
Item pedido vlido
No hay ms
DETERMINAR
CANTIDAD
PROVISTA
NO PROVISTA
DESPACHAR
TIPO-
ITEM
OBTENER AISLAR PROCESAR PROCESAR ITEM
1- - - - - - - - - - - - - - - - - - - - - - - - - - - - - ,
PROCESAR PEDIDOS PROCESAR
PEDIDO PROXIMO ITEM PARCIALMENTE PENDIENTES PEDIDOS
VALIDO ITEM PROVISTOS PROVISTOS DE ENTREGA ESPECIALES
GRABAR
ACTUALIZAR
r - "i
GRABAR REGISTRO 1 GRABAR
REGISTRO ITEM
NIVEL PEDIDO PENDIENTE REGISTRO PEDIDO?
DESPACHABLE
INVENTARIO | DE ENTREGA | | ESPECIAL
Figura 9.28 Iniciacin del diseo del tramo de entrada.
Figura 9.29 Funciones de OBTENER PEDIDO VALIDO.
PEDIDO VALIDO, haciendo as a BUSCAR PEDIDO VALIDO un mdulo cohesivo de
comunicacin. Lo que tenemos que hacer para evitarle sorpresas indeseables al programador
de mantenimiento es documentar la existencia y posicin estructural de CREAR HISTO-
www.FreeLibros.org
Pedido vlido
acreditable
AISLAR OBTENER DETERMINAR DESPACHAR
ITEM NIVEL CANTIDAD TIPO-ITEM
PEDIDO INVENTARIO PROVISTA-NO PROVISTA
PROCESAR PROCESAR ITEM
PROCESAR
PROCESAR
ITEM PARCIALMENTE
PEDIDOS
PEDIOOS
PROVISTOS PROVISTOS
PENDIENTES
-DE ENTREGA.
ESPECIALES
Figura 9.30 U n intento para resolver el efecto lateral causado por CREAR HISTORIA-
PEDIDO.
Figura 9.31 Di seo del lazo simplificado.
RIA-PEDIDO en el punto de BUSCAR ITEM PEDIDO VALIDO donde es invocado
BUSCAR PEDIDO VALIDO y tambin en PROCESAR PEDIDOS. Adems, tendra
mos que cambiarle el nombre al mdulo BUSCAR PEDIDO VALIDO para que represente
verdaderamente su funcin.
Ahora estamos en condicin de colocar los mdulos del nivel inferior del tramo de
entrada y llegar al diseo completo del subsistema tal como se muestra en la Fig. 9.32.
213
www.FreeLibros.org
No hay mas
No hay ms
'Pedido
OBTENER 1
AISLAR
PEDIDO JL
PROXIMO
VALIDO
\ a. PV
ITEM
No hay ms
REUNIR
VERIFICAR
PEDIDO
CREDITO
<Pedido
CREAR 1
REQUERIMIENTO
(p a s o p r ev i o !
CREAR
HISTORIA-
PEDIDO
Figura 9.32 Diseo completo del subsistema.
214
www.FreeLibros.org
Abrev. Nombre Descripcin
CNR
Cantidad no provista Cantidad de Item de libro de pedidos pendientes de entrega
CR Cantidad provista Cantidad de tem de libro a despachar
IC Identificacin diente Nombre organizacin y/o cdigo postal
ILV Item libro vlido ISBN, precio, cantidad
IPV Item pedido vlido Pedido-identidad, item libro vlido
ISBN International Standard Identificador de 10 dgitos del libro
Book Number
ND Nombre y direccin Nombre organizacin, direccin organizacin, org-d
NI Nivel inventario Nivel actual del inventario
NNI Nuevo nivel inventario Nivel inventario menos cantidad del pedido
Pl Pedido-identidad Org-id, fecha (contacto, Oficina Postal N]
PV
Pedido vlido Pedido-identidad, Item libro vlido +
Rl Registro inventario ISBN, nivel inventario, cantidad del pedido, nivel de pedido
Obsrvese la utilizacin de la tabla resumen del diccionario de datos para reunir las
abreviaturas de las diversas estructuras de datos y elementos de datos que se trasfieren en el
sistema.
Este diseo, por supuesto, puede continuarse perfeccionando; por ejemplo, mediante la
expansin posterior de los mdulos de nivel inferior. Sin embargo, aparte de estas pocas
instancias que hemos observado, est compuesto de mdulos funcionalmente cohesivos los
215
www.FreeLibros.org
cuales estn acoplados, principalmente por el pasaje de datos, con unas pocas variables de
control que informan hacia atrs qu ha sucedido. Para comprobar el grado de
cambiabilidad del diseo, resulta interesante considerar los efectos de diversos cambios que
puede solicitar el usuario. Cuntos mdulos necesitarn modificarse si el usuario quiere
alterar las reglas de concesin de crdito? Cuntos mdulos tendrn que modificarse si todos
los pedidos, vlidos y no vlidos, debieran ser grabados en el archivo HISTORIA-PEDIDO?
Qu pasa si el usuario decide eliminar los envos parciales y despachar todo el pedido o nada,
con excepcin de una confirmacin? Tambin podemos ver que el agregado de la lgica que
trata el pago previo es ms claro que cuando empezamos.
Suponiendo que implementamos el sistema as definido, qu podramos hacer si el
tiempo de respuesta fuese demasiado grande como para ser aceptado? Primero, podemos
empaquetar los mdulos lgicos del tramo de entrada en menos mdulos fsicos, incluyendo
subordinados lexicogrficos. Si esta estructura es an muy larga para procesar, podemos
considerarla descompuesta en dos subsistemas, en el punto en que se produce un pedido
vlido. El empleado de entrada de pedidos podr invocar un programa que trate con los
pedidos vlidos. Por separado, podemos invocar la estructura de nivel superior que pueda
trasferir los pedidos vlidos desde el archivo de HISTORIA-PEDIDOS y procesarlos contra
el inventario. Como los empleados de entrada de pedidos no tienen nada que ver con el hecho
de que un pedido sea actualmente despachable o no, sto reduciria la cantidad de accesos de
archivo y la cantidad de mdulos invocados. La cuestin es que el diseo puede optimizar su
rendimiento de muchas maneras.
9.5 DESARROLLO DE ARRIBA HACIA ABAJO
Una vez que el diagrama de flujo de datos se ha terminado y se han dibujado los
diagramas de estructura de todos los subsistemas, se los puede utilizar para planificar la
implementacin de arriba hacia abajo del sistema. Esto es, en vez de definir programas y
construir subsistemas como unidades completas y comprobar que las unidades trabajan
juntas despus de estar listas (la aproximacin de desarrollo de abajo hacia arriba) pode
mos iniciar el desarrollo produciendo una versin esqueleto en bruto del sistema, que
acepte algunos datos simples de entrada, los procese de alguna manera muy simplificada a
travs de tantos subsistemas como sea posible, y genere alguna salida muy sencilla. Des
pus que esta versin esqueleto est trabajando en nuestra computadora real, podemos
agregar ms complejidad a cada subsistema y hacer que ste funcione. Veamos cmo se
puede aplicar este concepto a CBM y despus discutir porqu tiene ventajas sobre el
procedimiento tradicional.
9.5.1 Posibles versiones de arriba hacia abajo del sistema CBM
Versin 1. Nuestra pretensin con la versin 1 ser tener algo trabajando lo ms rpido
posible y que involucre la mayor cantidad posible de subsistemas y sus correspondientes
interfaces. Una versin 1 realista debe tener las siguientes funciones:
Aceptar pedidos de 1 a 10 clientes desde una sola CRT.
Aceptar pedidos por solo 10 ttulos, un tem por pedido.
Aceptar siempre que el crdito del cliente es bueno.
Decir siempre que hay 100 copias en stock de cada ttulo.
Escribir una nota de despacho y factura en papel simple de computadora, sin
actualizar CUENTAS A COBRAR.
Realizar estas funciones no requerir mucho esfuerzo y presentar una tarea bastante
simple para el empleado de entrada de pedidos! Se demostrar que podemos leer y grabar en
216
www.FreeLibros.org
la pantalla CRT, grabar tem despachables en el archivo intermedio y volver a leer el archivo
como entrada del subsistema de despacho y facturacin. El mdulo VERIFICAR
CREDITO de la Fig. 9.32 podr ser el denominado mdulo simulado, que se compone de dos
lineas:
MOVE OK' TO CRED1T-STATUS (Mover OK a ESTADO-CREDITO)
EXIT (SALIDA)
En forma similar, para todos los otros mdulos bobos o simulados que no sean
requeridos por la versin 1, se requerir solo lo suficiente de sus codificaciones como para
permitir compilar y ejecutar los distintos programas. Mientras que la lgica en el mdulo
principal PROCESAR PEDIDOS deber ser completa, el mdulo PROCESAR PROVI
SIONES PARCIALES podr contener simplemente las sentencias
DISPLAY'INVOCADO MODULO PROVISION
EXIT.
y si este mensaje aparece mientras probamos la versin con pedidos de menos de 100 copias,
sabremos que algo ha andado mal.
Versin 2. Una vez que la versin 1 ha sido desarrollada y demostr que funciona, el
grupo de proyecto mplementar la versin siguiente, que implica mayor cantidad de
subsistemas y emplea ms interfaces. La versin 2 podr tener las siguientes funciones:
Aceptar pedidos de los mismos 10 clientes (como la versin 1, probando la interfaz
del archivo CLIENTES).
Aceptar pedidos por cualquier cantidad de libros de un determinado editor,
suponiendo que hay normalmente existencia en stock.
Aceptar siempre que el crdito del cliente es bueno.
Escribir en formato correcto la nota de despacho y la factura.
Introducir y cambiar niveles de pedido del archivo INVENTARIO.
Crear una orden de compra por 100 copias del editor de cualquier libro por debajo del
nivel de pedido.
Esto involucrar la implementacin de partes de los subsistemas de control de inventario
y de compras, as como algo ms de los subsistemas de entrada de pedidos y de despacho; y
emplear mayor cantidad de archivos e interfaces de programas. Proveer a los usuarios de
ejemplos realistas de tres de los documentos importantes que salen de la empresa y lo har en
una temprana etapa del desarrollo.
Versiones subsiguientes. Una vez que la versin 2 funciona de acuerdo a lo
especificado, se puede desarrollar la versin 3, seguida de la versin 4, etc., cada una de ellas
con ms funciones del sistema definitivo. Es conveniente planificar la implementacin del
sistema completo en una serie de tales versiones, cada una de las cuales puede llevar de 1-3
meses, en funcin de la escala del proyecto. Contar con este tipo de referencias cada 30-60
das, y poder mostrar evidencias tangibles de progreso a intervalos regulares, motiva al grupo
de proyecto e infunde confianza a los usuarios.
9.5.2 Por qu desarrollar de arriba hacia abajo?
Por qu realizamos la implementacin de esta manera? La razn principal es que el
desarrollo de arriba hacia abajo evita uno de los problemas ms dificultosos, de mayor
prdida de tiempo y ms costosos en el que la implementacin normal (de abajo hacia
217 www.FreeLibros.org
arriba) tiende a caer, esto es, el problema de las interfaces o hacer que las partes se
integren. El enfoque normal de la implementacin ha sido dividirel sistema en programas,
especificar los programas, escribir y probar cada programa por separado, ensamblar los
programas en subsistemas y luego al final del proyecto, ensamblar los subsistemas en un
sistema operante. El sistema est formado por los mdulos de detalle de nivel inferior, con los
niveles ms altos de control, tales como el JCL (Job Control Language, lenguaje de control de
trabajo), agregndose en ltimo trmino; de ahi la denominacin desarrollo de abajo hacia
arriba. Especialmente, si los diferentes subsistemas son desarrollados por diferentes
equipos o personas, en muchos proyectos, al integrarse los subsistemas, aparece un error en
alguna parte de la interfaz entre dos subsistemas. Debido a la falta de comunicacin de un
cambio en las especificaciones, o debido a especificaciones vagas, la interfaz del subsistema
A producido por el equipo A no se adapta a la interfaz requerida por el subsistema B
producido por el equipo B. Todos los errores son desagradables, pero los errores de interfaz
son los peores, por tres razones:
Tienden a involucrar mayores cambios en las codificaciones existentes que, digamos, los
errores lgicos. Si se hace mal un clculo de descuento tendremos que corregir un
programa; si el subsistema control de inventario se ha codificado utilizando el formato de
registro errneo para un pedido y en consecuencia no puede aceptar los datos del
subsistema de entrada de pedidos, tendremos que codificar y compilar nuevamente y
volver a probar todos los programas que utilizan este registro en uno u otro de los
subsistemas.
Tienden a ser detectados uno despus del otro; hasta que el error de la primera interfaz no
se haya resuelto, no se puede proceder a realizar pruebas de integracin para ver si hay
otros errores. Esto extiende el perodo de prueba en forma impredecible.
En el desarrollo de abajo hacia arriba los errores se encuentran en su mayora despus de
que se ha gastado la mayor parte del presupuesto del proyecto y de su tiempo, y cuando la
fecha de entrega del sistema est prxima o ya se ha cumplido. Esto significa que siempre
existe el riesgo de que justo cuando los usuarios esperan la entrega del sistema, ste se ve
suspendido por un perodo impredecible de tiempo para arreglar una cantidad de errores de
interfaz.
El gerente de proyecto que tenga mala suerte con los errores de interfaz durante el
desarrollo de abajo hacia arriba, cayendo en una serie de ellos, se encuentra en la situacin de
tener que concurrir a ver a los usuarios y decirles S que hace cuatro semanas les promet
que el sistema estara listo en dos semanas, y tambin s que hace dos semanas les promet
que el sistema estara listo para hoy, pero nos hemos encontrado con otro problema.... Los
usuarios no lo comprendern, se irritarn y rpidamente perdern confianza en el gerente de
proyecto que ha desperdiciado una cantidad sustancial de su dinero y parece no tener el
control de la operacin.
El desarrollo de arriba hacia abajo que es el opuesto al de abajo hacia arriba crea
primero la lgica de alto nivel y todas las interfaces importantes del sistema, antes de que se
haya escrito mucho de la codificacin detallada. Las versiones 1 y 2 han sido proyectadas
para ejercitar las interfaces, de manera que si aparece algn problema, ser detectado y
corregido relativamente pronto en el proyecto antes de que requiera mucho trabajo adicional.
Esto tiene el mayor efecto en la uniformidad de la implementacin posterior; los horrores de la
integracin son en gran medida desterrados. Hace posible mostrar a los usuarios evidencias
tangibles de progreso a intervalos regulares. El desarrollo de arriba hacia abajo tambin es
una gran ayuda para que el analista pueda presentar modelos del sistema a los usuarios, ya
que es posible mostrar una versin temprana, como ser la entrada de pedidos va una CRT o
consultas al archivo HISTORIA-PEDIDO, y preguntar a los usuarios si eso es lo que tienen
en mente. Aunque esta demostracin normalmente no puede tener lugar hasta alcanzar
aproximadamente entre el 65-70% del total del proyecto cuando ya es muy tarde para
hacer grandes cambios es an muy valiosa para probar el dilogo hombre-mquina, dando
218
www.FreeLibros.org
tiempo a los usuarios para que asimilen la naturaleza del nuevo sistema y descubran errores
de concepto que no se han evidenciado en el modelo lgico. Especialmente, cuando los
usuarios no tienen experiencia con sistemas en lnea, mostrarles una versin temprana hace a
las discusiones previas de requerimientos (y al diagrama de acceso inmediato) mucho ms
reales. A menudo, esto estimular a los usuarios a preguntar por mejoras del sistema en las
que de otra manera no hubieran pensado. Si estas mejoras pueden ser incorporadas dentro del
presupuesto del proyecto, todos ganan.
9.5.3 El papel del analista
Incluimos esta discusin de desarrollo de arriba hacia abajo en un libro de anlisis, en
parte, debido al valor e inters de la tcnica, pero principalmente al impacto que el
procedimiento tiene sobre los usuarios y a la contribucin que el analista necesita para lograr
un proyecto de arriba hacia abajo exitoso.
Mientras que el diseo estructurado y la codificacin estructurada se ocultan a la
comunidad usuaria (excepto en cuanto a que ellos producen sistemas ms rpidos y mejores),
el desarrollo de arriba hacia abajo hace que el proyecto completo luzca diferente. En un
proyecto normal, los usuarios estn incluidos en el estudio y en las especificaciones
funcionales, despus de lo cual desciende un silencio de muerte mientras el equipo de
proyecto regresa a su cueva para disear, codificar y probar el sistema. Puede que los usuarios
por muchos meses no escuchen nada, salvo informes de estado, sobre sus sistemas hasta el
inicio de las pruebas de aceptacin y del entrenamiento del usuario. En un desarrollo de arriba
hacia abajo trascurre un periodo mucho ms corto despus de la especificacin funcional para
que los usuarios sean invitados a venir y ver la versin 1. De ah en ms tienen lugar a
intervalos (regulares) demostraciones y aceptacin de versiones a lo largo de la ltima tercera
parte de la duracin del proyecto.
En esta situacin de mucha mayor visibilidad, el analista tiene una cantidad de papeles
que jugar:
1. El analista deber ayudar a proyectar las versiones de arriba hacia abajo para el
plan de implementacin. Como vimos antes en esta seccin, el diagrama de flujo de datos y
los diagramas de estructura de los subsistemas son las herramientas principales para
planificar las versiones tempranas. Una gua es imaginar la lgica ms simple de todas las
transacciones y resolver la cantidad de implementacin mnima necesaria para procesar esta
transaccin con la mayor cantidad de interfaces posibles. El analista est en una buena
posicin para saber cul es la transaccin lgica ms simple, el diseador conocer la
cantidad de implementacin necesaria para procesarla. Una vez que se han establecido las
versiones tempranas, el analista podr ver si es posible crear versiones posteriores, aunque
parciales, que provean algn servicio til a los usuarios. Por ejemplo, sera posible empezar
proveyendo capacidad de consulta a algunos archivos antes de que se complete la versin
total del sistema. Sera posible comenzar produciendo listas de correo desde el archivo de
CLIENTES antes de que est instalado el sistema completo de entrada de pedidos. El
analista conoce qu partes son valiosas para el usuario y puede aportar ese conocimiento al
plan de implementacin.
2. El analista deber explicar el concepto de desarrollo de arriba hacia abajo a la
comunidad usuaria para asegurar la colaboracin armnica. Como se puntualiz al
comienzo de esta seccin, el desarrollo de arriba hacia abajo es mucho ms visible a los
usuarios. El analista deber esmerarse cuando explique el plan a todos los usuarios, que
sern impactados por cada versin, detallando qu har cada versin y tambin qu no
har. Si esta explicacin y orientacin no estn bien realizadas, surgen dos peligros. El
primero es que los usuarios podrn desilucionarse por la versin temprana que ven, debido a
su funcin limitada, y perdern confianza en el sistema. El segundo es el peligro opuesto, que
219
www.FreeLibros.org
queden tan impactados con la versin 1que quieran comenzar a usarla en su empresa el lunes
siguiente. El analista puede explicar el procedimiento de versiones por comparacin con la
construccin de una casa, diciendo, La versin 1es comparable con la visin de la estructura
de la casa solamente, sin paredes, ni techo, ni interiores. Nos permite aseguramos que
estamos construyendo la casa en el lugar correcto y que tiene el tamao adecuado, pero
ustedes no se quejarn porque penetra la lluvia ni esperaran mudarse el lunes prximo. La
misma comparacin es til para explicar el impacto de los cambios que los usuarios querrn
hacer. Cambiar un formato de informe es como querer las paredes de la sala pintadas de otro
color, es agradable saberlo de antemano, y de cualquier manera es una de las ltimas cosas
que se suelen hacer en la construccin (y en el desarrollo de arriba hacia abajo), pero si el
cambio se desea despus de realizado el trabajo, no es conveniente. Algunos cambios son
comparables a trasformar un dormitorio en otro bao un importante trabajo estructural que
implica tiempo y gastos. Otros cambios son comparables a que el usuario diga, Quiero la
casa como est, pero podra desplazarla tres metros ms lejos del camino?
3. El analista deber asegurarse el apoyo de la gerencia para el desarrollo de arriba
hacia abajo de manera que el hardware est disponible cuando se lo necesite. T picamente
la versin 1 deber estar implementada al completarse alrededor del 60-70% del proyecto,
como lo mencionamos anteriormente. Luego, en un proyecto de 12 meses de duracin que se
inicia en enero, el modelo lgico puede aparecer en marzo/abril y los diagramas de estructura
en mayo/junio, y la versin 1 podra entregarse a fines de julio y tal vez con cinco versiones
ms que seguirn a intervalos de cuatro semanas. Si el sistema tiene que tener funciones en
lnea, esto significa que por lo menos una terminal con facilidades de comunicaciones y
acceso al hardware requerido necesita estar disponible a ms tardar en junio. Los gerentes
que firman los cheques para el hardware, esperan, sin embargo, que no lo van a necesitar hasta
noviembre! El analista debe vender los beneficios de esta estrategia de desarrollo a la alta
gerencia y asegurarse de que no existen obstculos para obtener el hardware y el software
necesarios. Cuando el hardware se est desarrollando al mismo tiempo que el sistema
(digamos una terminal de propsitos especiales) es importante poder obtener un prototipo en
la etapa ms temprana posible y probar las interfaces con l. A este requerimiento de tener
algn hardware ms temprano puede contraponerse el hecho de que la carga de prueba en la
parte final del proyecto tiende a ser menor con el desarrollo de arriba hacia abajo que con el
desarrollo de abajo hacia arriba, debido a que, con el desarrollo de arriba hacia abajo,
evitamos la carga de rehacer tareas y pruebas, que es tpica de la fase de integracin de un
proyecto de abajo hacia arriba y que a menudo conduce a emplear ms y ms tiempo de
prueba para entregar el sistema.
4. El analista deber ejercer presin para la frecuente y completa integracin de los
subsistemas. Una vez que se ha comenzado a codificar y probar de arriba hacia abajo, existe
frecuentemente la tentacin de diluir el concepto. Por ejemplo, el programador que trabaja
en el subsistema entrada de pedidos puede preferir desarrollar y probar su subsistema solo,
despus de demostrar que la versin 1trabaja. Puede desarrollar el subsistema de arriba hacia
abajo, pero si no se rene regularmente con el resto del personal que est desarrollando otros
subsistemas y comprueba que todas las interfaces siguen funcionando, se perdern en gran
medida las ventajas del desarrollo de arriba hacia abajo. En forma similar, si algunas piezas
del hardware no estn disponibles y la interfaz del hardware es simulada, o no es probada
junto con las otras, aumenta el riesgo de problemas de integracin. El analista, como
representante de los usuarios, puede ejercer presin para inducir a la prueba completa de
arriba hacia abajo, asegurndose de que el equipo de proyecto se tome tiempo para probar
cada interfaz en el sistema final, tan temprana y frecuentemente como sea posible. El personal
que es ms renuente a integrar sus subsistemas con l resto del sistema es probablemente el
que ms lo necesita.
5. El analista deber ver que el subsistema personal sea desarrollado de arriba hacia
abajo y operado juntamente con las versiones del sistema de aplicacin. Aunque hayamos
prestado bastante atencin a las interfaces software/software y software/hardware, la interfaz
220 www.FreeLibros.org
hombre/sistema es igualmente critica y tiene la misma probabilidad de presentar problemas
de integracin. Uno de los beneficios del desarrollo de arriba hacia abajo es que el manual del
usuario y la capacitacin del usuario pueden desarrollarse a lo largo de las distintas versiones
del sistema. Tomando el caso de la versin hipottica del sistema CBM que hemos discutido,
la documentacin y la capacitacin necesarias para entrar por cada cliente un libro entre diez,
no son, evidentemente, extensas, y sin embargo la versin 1 provee una oportunidad de
entrenar a alguien para interactuar con una terminal CRT aun cuando no haya visto una
anteriormente, dentro de una situacin muy simple, libre de riesgo. Las versiones posteriores
permiten desarrollar gradualmente en complejidad la documentacin y la capacitacin, y
verificarlas con las pruebas del subsistema. Un corolario de este concepto es que cada versin
debe ser ejercitada con un empleado usuario en la terminal, utilizando la documentacin
producida por la gente responsable del subsistema personal. No es bueno tener la versin
ejecutada por un programador snior utilizando codificaciones y procedimientos que solo
el/ella conoce!
6. El analista deber actuar como representante de los usuarios en la aceptacin de
cada versin del sistema. El plan de implementacin deber especificar la entrega de cada
versin en funcin de objetivos fuertemente establecidos. El da fijado para la entrega de cada
versin, el analista y representantes apropiados de los usuarios debern supervisar y ejercitar
el sistema para ver si, en efecto, se han alcanzado los objetivos de la versin. Naturalmente
esta ejercitacin se hace ms elaborada a medida que las versiones posteriores suministran
ms funciones, hasta que la versin final recibe la aceptacin completa de la prueba y entra en
produccin. El analista acta como asesor tcnico del usuario en este proceso y deber
asegurarse de que todos los miembros de la comunidad usuaria en condiciones de proveer
informacin til sobre cada versin, tengan la oportunidad de hacerlo. Deber coordinar la
realimentacin de los usuarios y presentarla al equipo de proyecto. Para hacer esto deber
reforzar los comentarios realizados en los puntos 4 y 5, asegurndose de que todas las
interfaces hayan sido ejercitadas adecuadamente, incluso las del personal.
9.5.4 Resumen
El desarrollo de arriba hacia abajo es una aproximacin excitante. Planificada y
realizada adecuadamente puede evitar muchos de los problemas que han significado una
plaga por aos en el desarrollo de sistemas. En el estudio realizado por Walston y Flix sobre
productividad dentro de IBM [9.13], los proyectos que no utilizaron el desarrollo de arriba
hacia abajo obtuvieron una productividad promedio de 196 lneas de codificacin por
hombre-mes; los proyectos que lo utilizaron promediaron 321 lneas por hombre-mes, es
decir, una mejora de aproximadamente el 60%. Tal vez el aspecto ms importante, al menos
para nosotros como analistas, es la creciente participacin de los usuarios a medida qu el
sistema se construye, tanto en funcin de los comentarios valiosos y de la ayuda que pueden
suministrar a medida que evoluciona el sistema, como en funcin de la confianza que
adquieren sabiendo que se est construyendo para ellos el sistema correcto y que el mismo
hace progresos tangibles.
BIBLIOGRAFIA
9.1 W. P. Stevens, G. J. Myers, y L. L. Constantine, Structured Design, IBM Systems Journal,
Vol. 13, N 2, 1974.
9.2 G. J. Myers, Reliable Software Through Composite Design, Petrocelli/Charter, New York, 1975.
9.3 E. Yourdony L. L. Constantine, Structured Design, Prentice-Hall, Englewood Cliffs, N.J., 1979.
9.4 E. Yourdon, Techniques ofProgram Structure and Design, Prentice-Hall, Englewood Cliffs, N.J.,
1975.
221 www.FreeLibros.org
9.5 J. Martin, Security, Accuracy, and Prvacy in Computer Systems, Prentice-Hall, Englewood
ClifFs, N. J., 1973.
9.6 F. P. Brooks, The Mythical Man-Month, Addison-Wesley, Reading, Mass., 1975.
9.7 B. Bochn, Software Engineering, IEEE Transactions on Computen, Vol. C-25. Dec. 1976.
9.8 H. Mills, Software Development, IEEE Transactions onf Software Engineering, Vol. SE-2,
Dec. 1976.
9.9 F. M. Haney, Module Connection Analysis: A Tool for Scheduling Software Debugging
Activities, Proceedings FJCC, Vol. 41, 1972.
9.10 R. C. Tausworthe, Standardized Development of Computer Software, Prentice-Hall, Englewood
Cliffs, N.J., 1977.
9.11 R, J. Weiland, Experiments in Structured COBOL, in Structured Programming in COBOL-
Future and Present, ed. H. Stevenson. ACM Publications, New York, 1975.
9.12 P. Kraft and G. M. Weinberg, The Professionalization of Programming, Datamation, Vol. 21,
Oct. 1975.
9.13 C. E. Walston and C. P. Flix, A Method of Programming Measurement and Estimation", IBM
Systems Journal, Vol. 16, N 1, 1977,
Ejercicios y puntos de discusin
1. Identificar un sistema que emplee una gran cantidad de archivos intermedios. Aproximadamente
qu proporcin del tiempo promedio de operacin de ese sistema se consume en la lectura y en la
grabacin de dichos archivos o esperando que el operador monte los volmenes?
2. Cul es el tiempo de bsqueda ms largo y el promedio de las unidades de disco de su instalacin?
Cul es el tiempo de ejecucin ms largo y el promedio de una instruccin de mquina en su
computador?
3. Si tiene acceso a un monitor de ejecucin de programas, del tipo PPE o SUPERMON utilcelo en un
programa con el que est familiarizado para observar dnde el programa utiliza ms tiempo. Le
sorprendieron los resultados?
4. Qu proporcin del tiempo profesional total de su instalacin utilizan las actividades de
mantenimiento?
5. Tome un sistema que se encuentre en produccin desde hace varios aos y evale los hombre-horas
empleados en su mantenimiento. Cunto tiempo aprecia que el sistema continuar en uso antes de
ser remplazado definitivamente? Cul ser el trabajo total de mantenimiento durante la vida del
sistema en relacin con el trabajo de desarrollo original?
6. Si tiene acceso a un sistema escrito en forma de mdulos, grafique ia estructura del sistema y evale
los tipos de acoplamiento y de cohesin involucrados. Cmo correlaciona sus conclusiones con la
posibilidad de cambio del sistema?
7. Algunos mdulos de propsitos generales son lgicamente cohesivos, como ser las funciones
generales de validacin, los operadores generales de entrada/salida, etc. Puede pensar en algunos
ejemplos de mdulos funcionalmente cohesivos que an puedan considerarse de propsitos
generales, en el sentido que pueden utilizarse en una cantidad de tugares de un sistema y de distintos
sistemas? Cules serian los beneficios de tener una biblioteca con mdulos funcionalmente
cohesivos, tipo caja negra, de propsitos generales?
8. Desde su punto de vista podra reducirse la posibilidad de cambio en beneficio del rendimiento? En
este caso podra definir en qu circunstancias?
9. A partir del diagrama de flujo de datos de la Fg. 9.19 y del grfico de estructura de la Fig. 9.32
ample el diseo para atender pagos previos, verificando que el pago previo corresponda a la
cantidad correcta, y grabando un registro en el archivo CUENTAS A COBRAR que conecte el
importe con la identidad del pedido.
10. A partir de suposiciones razonables, disee un subsistema de compras para CBM.
11. En el grfico de estructura de la Fig. 9.32 marque los mdulos que deberan haberse implementado
para entregar la hipottica versin 1 que se especifica en la Seccin 9.5.1. Clasifique cada mdulo
como F (requiere implementacin total), P (requiere implementacin parcial) o S (para ser
implementado solamente como una simulacin).
12. Realizar un plan de implementacin de arriba hacia abajo para un sistema entregado recientemente,
con el que se encuentre familiarizado. Cules serian los beneficios probables que se habran
obtenido de haberse seguido este plan?
222 www.FreeLibros.org
10
LA IMPLEMENTACION DEL ANALISIS
ESTRUCTURADO DE SISTEMAS EN SU EMPRESA
En primer lugar vamos a considerar en este capitulo los pasos que deben tomarse en una
organizacin de desarrollo de sistemas para implementar las herramientas y tcnicas
discutidas en este libro, y luego veremos los beneficios que razonablemente se pueden esperar
juntamente con los problemas que experimenta el personal.
10.1 LOS PASOS EN LA IMPLEMENTACION DEL ANALISIS ESTRUCTURADO
DE SISTEMAS
10.1.1 Revisin de las reglas fundamentales para la administracin
de proyectos
La cantidad de trabajq abarcada en esta rea ser muy variable, ya que depende del uso o
no de una metodologa formal de desarrollo de sistemas y en el caso afirmativo de lo que
prescriba esta metodologa para la fase de anlisis.
Como respuesta a los problemas que presenta el desarrollo de sistemas, algunas
empresas han adoptado conjuntos formales de procedimientos para el desarrollo de sistemas,
ya sea, elaborndolos por s mismas o adoptando un "paquete" metodolgico desarrollado
por firmas consultoras. Cada metodologa especifica como lo indicamos en el Captulo 8
la secuencia de actividades que deben seguirse al desarrollar el sistema, los productos a ser
desarrollados en cada etapa y los controles gerenciales a aplicar. Tpicamente, debern
especificar la conduccin de un estudio de factibilidad, el contenido del informe del estudio de
factibilidad y el equipo gerencial que deber revisar el estudio de factibilidad y autorizar el
trabajo siguiente. A continuacin del estudio de factibilidad deber especificarse una fase de
diseo general y una fase de diseo detallado, continuando con la codificacin, las pruebas
unitarias, las pruebas de los subsistemas y la prueba del sistema.
Si ya se tiene este tipo de metodologa, ser necesario revisarla cuidadosamente para
detectar si sus prescripciones o prohibiciones entran en conflicto con el uso de las tcnicas
estructuradas de sistemas. Las siguientes preguntas se encuentran entre aquellas que
necesitamos considerar.
1. La presente metodologa prescribe o estimula el diseo fsico prematuro? Si es as,
cmo puede modificarse la metodologa para permitir la construccin del modelo lgico
antes que el diseo fsico?
2. La metodologa estimula la sobre-documentacin, por ejemplo, escribir exhausti
vamente sobre los detalles narrativos? Cmo puede modificarse la metodologa para
223
www.FreeLibros.org
permitir que las herramientas grficas del anlisis estructurado de sistemas tomen el lugar
donde sea posible de las narraciones? Aunque el uso del diagrama de flujo de datos, el
diccionario de datos y las dems herramientas no eliminan la necesidad de todas las
narraciones en la especificacin, puede reducir considerablemente el volumen de las
descripciones narrativas necesarias, supuesto que su uso sea aceptable en el contexto de la
metodologa.
3. La presente metodologa permite el desarrollo de arriba hacia abajo? Aunque
especficamente no est relacionado con la fase de anlisis, este hecho tiene su impacto sobre
el analista como se indic en el Sec. 9.5. Algunas metodologas requieren que se
complete todo el diseo detallado antes de que pueda iniciarse cualquier codificacin y solo
supervisan la entrega de una versin del sistema (la final) empleando el completamiento de las
pruebas unitarias y las pruebas de los subsistemas como puntos de control gerencial. Por
supuesto, esto hace algo dificultoso el empleo del desarrollo de arriba hacia abajo, ya que el
procedimiento de arriba hacia abajo permite codificar los mdulos de alto nivel en un sistema
a encarar, antes de que se complete el diseo detallado de los mdulos de bajo nivel, y se
puedan entregar series de versiones de trabajo ms bien que fases de pruebas completas.
El ltimo punto da lugar a un aspecto ms fundamental y sutil, el del enfoque en lnea
recta como opuesto al enfoque en espiral. En el pasado hemos tendido a suponer que el
desarrollo de un proyecto bien administrado va en la lnea recta desde el estudio de
factibilidad a travs del anlisis, del diseo, la prueba, aceptacin y la operacin. La Fig. 10.1
muestra este esquema
Anlisis Diseo Codificacin Prueba
Figura 10.1 El ideal del progreso del proyecto.
A pesar de lo cristalino y manejable que puede ser el enfoque en lnea recta, no parece
corresponder a la realidad del desarrollo de sistemas. Aun un proyecto bien administrado,
conducido por personal competente, necesita manejarse iterativamente, comenzando por
algn anlisis, luego un pequeo diseo, luego retroceder para un anlisis ms detallado para
seguir con algo ms de diseo, luego tal vez la codificacin de la versin 1, luego seguir
con ms diseo, etc. La trayectoria de este tipo de proyecto puede representarse con una
espiral, como se muestra en la Fig. 10.2.
El concepto de espiral se introdujo en nuestra discusin de una metodologa estructurada
en el Captulo 8. All describimos la construccin de un diagrama de flujo de datos global
antes de la construccin de flujos de datos detallados y la construccin de un diseo tentativo
seguido de perfeccionamientos o refinaciones sucesivos. Este enfoque desde nuestro punto
de vista refleja la realidad de los dificultosos problemas que afrontamos en el desarrollo de
sistemas; as como desarrollo de arriba hacia abajo, hacemos diseo de arriba hacia abajo y
anlisis de arriba hacia abajo. En cada caso y en cada nivel construimos un esqueleto, primero
lgico y despus fsico, vemos cmo funciona dicho esqueleto, y luego retrocedemos para
armarlo poniendo la carne sobre los huesos.
Cmo podemos ejercer el control gerencial sobre una actividad en espiral? Las
metodologas convencionales identifican tpicamente los hitos de los proyectos como
224
www.FreeLibros.org
Figura 10.2 La realidad de los proyectos en espiral.
anlisis terminado o diseo completo. Los informes de estado intermedios requieren que
el analista o el gerente de proyecto estimen el grado en que se ha completado la actividad, tal
como completado el 40% del anlisis o terminado el 90% de la codificacin. Este
criterio es poco significativo, especialmente cuando el proyecto est marchando en espiral. El
control gerencial no puede seguir basado en actividades y deber basarse en entregas; en
lugar de decir Hasta dnde lleg usted en el anlisis?, los gerentes dicen, Mustreme la
ltima versin del diagrama de flujo de datos o Mustreme el diagrama de estructura.
Aunque discutimos la metodologa estructurada en el Captulo 8 en funcin de una serie de
fases, solamente lo hicimos por conveniencia; lo que se est construyendo realmente en un
proyecto estructurado es un conjunto de entregas de refinacin creciente, que llegan a la
entrega de cada una de las versiones de arriba hacia abajo del sistema. Aqu, por supuesto, las
entregas son mucho ms definidas que en el proyecto tradicional y el control gerencial es
correlativamente ms estrecho; si el plan de implementacin especifica que la versin 3 ser
entregada el 31 de diciembre, y consiste en el procesamiento de dos transacciones que
producen 7 informes, y si a las 5 de la tarde de ese da el jefe del proyecto no puede presentar
esa facilidad a su gerente, el proyecto estar atrasado. No es cuestin de que aparezca 90%
completo; la versin se entrega o no se entrega. El lapso que lleve entregar la versin des
pus de la fecha especificada es una medida exacta del atraso del proyecto y del tiempo que
deber desplazarse la fecha de entrega final.
Por lo tanto, las reglas fundamentales del control gerencial de un proyecto necesitan
itiodificarse en el entorno estructurado para poder poner nfasis en la entrega de productos
diagramas de flujo de datos, diagramas de estructura, versiones de las funciones ms bien
que en el grado en que completan las actividades.
10.1.2 Establecer normas y procedimientos para el uso del diccionario
de datos y de otro software
Deber decidirse entre desarrollar o adquirir el recurso de un diccionario de datos
automatizado, si es que ya no existe uno. Si las tcnicas de diccionario de datos son manuales
225
www.FreeLibros.org
debern confeccionarse los formularios y procedimientos de control. Si se dispone de
capacidad de edicin de textos, deber adaptrsela para proveer una cierta medida de la
capacidad de diccionario de datos, como se describi en el Captulo 4. Los empleados que
utilicen el editor de textos necesitarn estar capacitados en las convenciones de los
diccionarios de datos.
Es probable que se pueda disponer de un software ms extenso para el soporte del
anlisis; ser muy conveniente tener un trazador de diagrama de flujo de datos para el
mantenimiento y fcil actualizacin de los diagramas, y software, para la lectura y
verificacin de la lgica de procesos en formato de lenguaje estructurado. Un esfuerzo de
pioneros es, en este sentido, el proyecto ISDOS de la Universidad de Michigan [ 10.1 ], que ha
desarrollado un software que permite a los analistas expresar flujos de datos, estructuras de
datos y lgica de procesos en un lenguaje casi corriente, denominado Problem Statement
Language (Lenguaje de Declaraciones de Problemas) (PSL). Las sentencias PSL son
procesadas por el Problem Statement Analyser (Analizador) (PSA), el cual verifica la
correccin y consistencia de las sentencias PSL y construye una base de datos de informacin
sobre el proyecto, a partir del cual se pueden producir informes y diagramas.
10.1.3 Capacitacin de los analistas en el uso de herramientas y tcnicas
Hemos tratado de exponer en este libro las herramientas y tcnicas del anlisis
estructurado de sistemas, del modo ms simple, si bien realista, posible. El empleo fluido de
las herramientas lleva estudio y prctica. Mientras que las reglas y convenciones pueden ser
aprendidas con bastante facilidad, digamos, con una semana de prctica, el esfuerzo mayor
significa comenzar a pensar en un nivel lgico, ms bien que en trminos de implementacin
fsica. Hemos observado un fenmeno paralelo en nuestros seminarios de diseo estructura
do; el aspecto ms difcil es ver al sistema como una jerarqua en lugar de verlo como un
diagrama secuencial que muestre la secuencia de los sucesos. Tanto en el anlisis como en el
diseo estamos pidiendo a las personas que piensen en los problemas con un mayor nivel de
abstraccin que antes, y esto lleva tiempo y perseverancia.
Tanto como fluidez en el uso de las herramientas lgicas, los analistas necesitan
famiiiarizacin con el nuevo soporte del software o con los procedimientos manuales del
diccionario de datos.
Si se deben modificar las reglas fundamentales de los proyectos, los analistas debern
explicarlo a la comunidad usuaria, para lo cual aquellos deben ser informados sobre la nueva
metodologa y pensar en las implicaciones que sta traer a los usuarios.
Si se va a utilizar el desarrollo de arriba hacia abajo, los analistas debern estar
informados a fondo sobre el concepto y el plan de implementacin de cada proyecto con el que
estn relacionados, ya que les corresponde una participacin significativa en la mayor
intervencin del usuario,que implica el desarrollo de arriba hacia abajo. As como nosotros
hemos llegado en este libro a cierto detalle del diseo estucturado, cada analista deber
comprender los principios del mismo y ser capaz de criticar un diseo a la luz de estos
principios, aun cuando no sea l quien hizo el diseo. Esto puede lograrse estudiando este
libro y las referencias sobre diseo estructurado o con una prctica formal.
10.1.4 Orientar a los usuarios en los nuevos procedimientos
Dado que las nuevas tcnicas y enfoques mejoran la comunicacin con los usuarios y los
compromete ms en la administracin del proyecto, las mismas son, en general, bienvenidas
por la comunidad usuaria. Al mismo tiempo, las nuevas ideas representan un cambio en las
reglas de cmo puede ser desarrollado algo alrededor de esto, y como tal generan
desconfianza, a menos que se expliquen claramente sus implicaciones y beneficios.
226
www.FreeLibros.org
El informe escrito a los usuarios, comnmente hecho al comenzar cada proyecto
estructurado, deber cubrir los siguientes puntos:
La notacin de los diagramas de flujo de datos (y posiblemente el rbol de decisin).
El concepto de presentar un men de sistemas alternativos para la consideracin de los
usuarios a cargo de la decisin (si esto es de aplicacin al proyecto en cuestin).
El concepto de desarrollo de arriba hacia abajo.
Una explicacin de la participacin necesaria por parte de los usuarios.
Una reafirmacin de que las nuevas tcnicas remplazan al enfoque existente, en lugar de
imponer an un mayor esfuerzo, y de que el proyecto generar menos, y no ms,papel
escrito para la revisin de los usuarios.
La mayora de las herramientas involucradas el diccionario de datos, el diagrama de
datos de acceso inmediato, el lenguaje estructurado debern dejarse de lado hasta que cada
usuario tenga que revisar un producto que las utilice. El analista deber estar enterado de
quin ha recibido informacin sobre cada herramienta, y estar preparado para explicar la
que va a utilizar antes de mostrrsela al usuario por primera vez.
De igual manera, el concepto de desarrollo de arriba hacia abajo deber ser explicado
nuevamente cuando el analista presente el plan de implementacin a los usuarios.
Deber capacitarse a los usuarios para que confeccionen los diagramas de flujo de datos
y escriban luego sus polticas en lenguaje estructurado? Nos inclinamos a favor de ello,
supuesto que cada individuo usuario desee hacerlo. En otras palabras, no podemos requerir a
los usuarios que expresen sus necesidades en un modelo lgico, pero podemos inducirlos a
hacerlo cuando estn dispuestos a dedicar el tiempo y el esfuerzo necesarios. Hemos tenido
algunos usuarios no tcnicos asistiendo a nuestros seminarios de anlisis estructurado.
Aunque ellos han encontrado que los detalles tcnicos de los sistemas fsicos estaban ms all
de sus conocimientos han encontrado, sin excepcin, en el modelo lgico un concepto fcil de
entender y una manera valiosa para poder pensar sobre los sistemas que necesitan. El
diagrama de flujo de datos y el rbol de decisin aparecen como las tcnicas ms fciles de
adquirir por parte del personal no tcnico. Paradjicamente, podra ser por su total
ignorancia de los detajles tcnicos que se les hace ms fcil comenzar pensando a nivel lgico!
Cuando se asignan especficamente ejecutivos como enlaces en representacin de los
usuarios, es deseable que stos sean capacitados en el empleo de todas las herramientas del
anlisis estructurado de sistemas. Ello les dar habilidad para pensar con ms precisin sobre
sus negocios y sus requerimientos, para comunicar sus ideas al analista y a los diseadores en
forma normalizada y para ser un crtico bien informado de los modelos lgicos producidos por
el personal de procesamiento de datos.
10.2 BENEFICIOS Y PROBLEMAS
Con la codificacin estructurada o el desarrollo de arriba hacia abajo, es posible
cuantificar algunos de los beneficios que resultarn: mejora de la productividad de lneas de
codificacin por da, uso ms controlable de tiempo de prueba, etc.
Con el diseo estructurado, los beneficios son exactamente tan reales, pero ms difciles
de cuantificar. Podemos pedirle a un grupo de programadores de mantenimiento que compare
la cambiabilidad de un sistema que utiliza diseo estructurado con la de otro que no lo haga;
tericamente podemos medir el costo de mantenimiento de un grupo de tales sistemas y
compararlo con el de un grupo de sistemas no estructurados. Un estudio indito sugiere que un
sistema que utilice diseo estructurado es unas siete veces ms fcil y barato de modificar que
los diseos tradicionales ( 10.2J. Otros estudios tienden a confirmar este dramtico resultado
pero son anecdticos; Bill Inmon [ 10.3J comenta que en un sistema de diseo estructurado,
Los mayores cambios requeran cuatro das y los cambios que le siguen en magnitud, menos
de un da.
227
www.FreeLibros.org
Con el anlisis estructurado de sistemas los beneficios son an ms difciles de medir.
Realmente, en algunos casos, si el trabajo de anlisis est perfectamente hecho, el nico
resultado ser la ausencia de problemas! Tenemos una cantidad de comentarios subjetivos y
anecdticos que parecen ser fielmente representativos de la experiencia del personal con las
herramientas de anlisis estructurado de sistemas. Ver por ejemplo [10.4], En la siguiente
seccin se resumen estos beneficios.
10.2.1 Beneficios del empleo del anlisis estructurado de sistemas
1. Los usuarios obtienen una idea ms vivida del sistema propuesto por intermedio de
los diagramas lgicos de flujo de datos que de las descripciones y cursogramas de los sistemas
fsicos. Como lo entienden, tienen una actitud ms positiva hacia el proyecto. De esta forma
se reduce notablemente la probabilidad de construir un sistema, que siendo excelente, no
satisfaga las necesidades de los usuarios.
2. La presentacin del sistema en trminos de flujos de datos lgicos destaca los
aspectos mal interpretados y conflictivos mucho antes de lo normal. El comentario que se
hace es con especificaciones narrativas, cualquiera traza mentalmente su propio diagrama
de flujo de datos. Una vez que este flujo de datos mental ha sido volcado al papel y hecho
pblico, se hacen obvias muchas diferencias entre las ideas que las personas mantenan
privadamente sobre el sistema. Por ejemplo, una narracin escrita puede especificar que
Deber crearse un archivo HISTORIA-PEDIDO CONTENIENDO DETALLES DE
TODOS LOS PEDIDOS PROCESADOS. De la manera como est redactada esta frase
podra ser perfectamente aceptable por los usuarios. Sin embargo, cuando comiencen a
revisar el diagrama de flujo de datos, vern ms claro partiendo del lugar del diagrama donde
se origina el flujo de datos de la historia del pedido, exactamente qu se incluiri en la
HISTORIA-PEDIDO. Slo los pedidos despchados? O todos los pedidos, sean o no
despachables? O incluye todos los pedidos, sean despachables o no, incluso aquellos
rechazados por falta de crdito? Esta despiadada exposicin de vaguedad a travs del
diagrama de flujo de datos significa que tiene lugar mucha mayor discusin sobre el flujo de
datos que sobre la especificacin de una tpica narracin. Es, sin embargo, una discusin muy
productiva. Hacer cambios en el papel es muy barato comparado con hacerlos en la
codificacin.
3. Las interfaces entre el nuevo sistema y los sistemas administrativos y/o los sistemas
automatizados, existentes, se ven claramente mediante el diagrama de flujo de datos; y la
necesidad de documentar los detalles de los flujos de datos en el diccionario de datos, en una
etapa temprana, fuerza a una clara definicin de estas interfaces. Algunas empresas
especifican que debe dibujarse un diagrama de flujo de datos no solo para el sistema bajo
estudio, sino tambin para cada uno de los otros sistemas administrativos o automatiza
dos con los cuales interactan.' Este ejercicio, aunque involucra un considerable trabajo,
muestra las duplicaciones de funciones y seala las oportunidades de incluir tareas
administrativas dentro del nuevo sistema.
4. El uso del modelo lgico elimina cierta cantidad de duplicacin de esfuerzo que tiene
lugar en los proyectos tradicionales. Tpicamente, el representante de los usuarios y el
analista deban, en el pasado, trabajar juntos para producir una especificacin narrativa del
sistema. Una vez redactada la especificacin narrativa, el grupo de diseo y programacin
deba volver sobre ella, repitiendo una buena parte del trabajo de definicin de la lgica y de los
datos. Es digno de atencin que las herramientas de anlisis estructurado de sistemas sean
igualmente valiosas para usuarios y tcnicos. Una vez que los usuarios estn de acuerdo con el
flujo de datos, el anlisis de acceso inmediato y la lgica de la poltica, estos documentos
podrn ser utilizados directamente como entrada del diseo fsico. E sta ventaja es particular
mente notable para el diseador de la base de datos, quien anteriormente tenia que seguir la
especificacin narrativa para extraer los requerimientos de tem de datos y de accesos. Ahora
228
www.FreeLibros.org
se les presenta un diccionario de datos, relaciones en 3FN y un anlisis de acceso inmediato.
5. El uso del diccionario de datos para contener el glosario de tem del proyecto ahorra
tiempo debido a la resolucin rpida de los casosrionde el personal llama a las mismas cosas
con nombres diferentes o cuando un trmino significa distintas cosas dependiendo del
contexto. Estos usos de las palabras se consideran naturales por el personal de la comunidad
usuaria, ya que ellas forman parte de s vida diaria, pero son muy desconcertantes para los
analistas.
En pocas palabras, los beneficios se reducen a dos:
Mostrar claramente qu es lo que usted va a hacer, de manera que todos puedan estar
seguros de que va a construir el sistema correcto.
Resolver las alternativas y detalles con la menor prdida de tiempo posible.
Expresado as, suena algo trivial, pero sin embargo, cunto tiempo y dinero se han
perdido en los ltimos 20 aos porque no fuimos capaces de hacer estas dos cosas?
10.2.2 Problemas potenciales
Los beneficios de las jwevas herramientas analticas no son gratis, por supuesto; existen
ciertos costos y problemas potenciales asociados con su introduccin. En parte son los
problemas asociados con cualquier cambio; en parte son el resultado de la mayor formalidad
y disciplina de las herramientas lgicas.
1. Se requiere orientar a los usuarios y capacitar a los analistas, tal como se discuti en
la seccin previa. Dado que la introduccin del anlisis estructurado de sistemas es percibida
como cambiar de reglas, debe explicarse con claridad a cada imo cules son las nuevas
reglas y cmo mejoran el juego.
2. El esfuerzo, formalidad y grado de detalle requerido, especialmente en la construc
cin del diccionario de datos,son resistidos a menudo. Es cuestin de hacer una inversin de
esfuerzo durante el anlisis, en aras de una mayor armona en el proyecto posterior, de hacer
correctamente las cosas desde un comienzo de manera de no tener que rehacerlas. En parte, la
resistencia proviene de los usuarios, debido a que los proyectos anteriores no han requerido
definiciones tan claras de trminos y significados; el equipo de proyecto haba sufrido as que
los usuarios continuaran con su vieja terminologa chapucera. La resistencia podr surgir a
raz del intento de una definicin con excesivo detalle muy temprano; como se coment en el
Captulo 8, se deber tomar una decisin finamente balanceada acerca del nivel de detalle de
la documentacin especialmente en las funciones del sistema actual que no van a ser incluidas
en el nuevo sistema. Pero debe afrontarse un hecho: hacer un buen anlisis significa esfuerzo
tanto para el usuario como para el analista. La compensacin es que resulta un esfuerzo ms
productivo.
3. Podr existir cierta inquietud por parte de los programadores, de que al recibir
especificaciones detalladas de lgica en lenguaje estructurado perdern toda la diversin de
programar; convirtindose en meros codificadores. Estos miedos se pierden cuando los
diseadores y programadores ven que el anlisis estructurado de sistemas les permite realizar
una tarea mayor al recibir un modelo lgico para trabajar. Nuestra discusin sobre las
soluciones de compromiso de diseo del Captulo 9 nos aclar cunto trabajo resta por hacer
despus de concluir el modelo lgico. Creemos que los problemas surgen debido a que hasta
que los programadores no tienen cierta experiencia de trabajo con modelos lgicos, no pueden
apreciar la diferencia entre la lgica externa de validacin del crdito digamos expresada
en lenguaje estructurado, y la lgica interna del mdulo fisico. La lgica extema est dada por
el analista, la lgica interna se debe disear completamente.
4. Por ltimo, aparece un problema en ciertas empresas despus de su primera
experiencia positiva con el anlisis estructurado de sistemas. Qu vergenza no haber tenido
229
www.FreeLibros.org
estas herramientas en el proyecto XYZ; hemos trabajado en l por seis meses y no
finalizamos su anlisis. Podemos usar las herramientas de anlisis estructurado de sistemas
en XYZ ahora que hemos hecho parte del camino? La leccin de esta experiencia parece ser
que resulta provechoso utilizar las tcnicas estructuradas para anlisis, diseo y desarrollo a
partir de cualquier punto de un proyecto. Aunque parezca a los usuarios del proyecto XYZ
que vamos a tirar por la boFda el trabajo de los ltimos seis meses y volver a empezar (lo cual
no es cierto), quedarn rpidamente convencidos cuando vean las mejoras en marcha.
Citemos a un analista de una compaa de seguros, Una vez que haya visto lo que estos
nuevos mtodos pueden hacer, no querr continuar empleando los viejos mtodos.
BIBLIOGRAFIA .
10.1 D. Teichroew y E. Hershey, PSL/PSA; A Computer- Aided Technique for Structured Documen
taron and Analysis, IEEE Transactions on Software Engineering, Vol. SE-3, enero de 1977.
10.2 Larry Constantine, artculos no publicados.
10.3 Bill Inmon, An example of Structured Design, Datamation, Vol. 22, marzo de 1976.
10.4 W. James Kain, "The Practice of Structured Analysis, articulo presentado al Life Office
Management Association Systems Forum, Atlanta, marzo de 1977.
230
www.FreeLibros.org
GLOSARIO
A c c e s o i n m e d i a t o . Recuperacin de una parte de los datos de un almacenamiento de datos m s
velozmente que por medio de la lectura de todo el almacenamiento buscando esa parte del dato o
clasificando el almacenamiento de datos.
A c o p l a m i e n t o d e c o n t e n i d o . Una forma rigurosa de acoplamiento, donde un mdulo hace una
referencia directa al contenido de otro mdulo.
A c o p l a m i e n t o d e c o n t r o l . Una forma de acoplamiento mediante la cual un mdulo trasfiere a otro una o
ms seales o interruptores, como parte de la invocacin o retorno del control.
A c o p l a m i e n t o e x t e r n o . Una forma rigurosa de acoplamiento inter-modular, en la cual un mdulo se
refiere a elementos internos de otro mdulo y dichos elementos han sido declarados accesibles por
otros mdulos.
A d m i n i s t r a d o r d e d a t o s ( a d m i n i s t r a d o r d e b a s e d e d a t o s ) . Una persona (o grupo) responsable del
control y la integridad de un conjunto de archivs (bases de datos).
A g r e g a d o d e d a t o s . Una determinada coleccin de tem de datos (elementos de datos) dentro de un
registro. Ver tambin grupo.
A l c a n c e d e l c o n t r o l ( d e u n m d u l o ) . Todos aquellos mdulos que son invocados por un mdulo, y todos
aqullos invocados por sus niveles inferiores, etc. El "departamento" del cual el mdulo es el
"jefe".
A l c a n c e d e l e f e c t o ( d e u n a d e c i s i n ) . Todos aquellos mdulos cuya ejecucin o invocacin depende del
resultado d la decisin.
AHas. Un nombre o simbolo que se da a una cosa y que no es su nombre propiamente dicho.
A l m a c e n a m i e n t o d e d a t o s . Cualquier lugar de un sistema donde se almacenan los datos entre
transacciones o entre ejecuciones del sistema (incluye archivos manuales y legibles por mquina,
bases de datos y tablas).
A r b o l d e d e c i s i n . Un grfico de ramificaciones que muestra las acciones que resultan de las diversas
combinaciones de condiciones.
A r c h i v o i n v e r t i d o . Aqul que provee mltiples ndices de los datos: los propios datos pueden estar
contenidos dentro de los ndices. .
A r g u m e n t o . Un valor que se emplea como entrada a algn proceso, a menudo trasferido a travs de una
interfaz mdulo/mdulo.
A r g u m e n t o d e b s q u e d a . El valor(s) del atributo empleado(s) para recuperar algn dato de un
almacenamiento de datos, ya sea a travs de un ndice o mediante una bsqueda. Ver
tambin argumento.
A t r i b u t o . Un elemento de datos que contiene informacin sobre una entidad.
B a s e d e d a t o s . Una coleccin de datos interrelacionados almacenados juntos con redundancia
controlada para servir a una o ms aplicaciones: los datos estn almacenados de manera que sean
independientes de los programas que los usan: se emplea un procedimiento comn y controlado
para agregar nuevos datos, y para modificar y recuperar los existentes dentro de una base de datos.
[James Martin. Ref. 7.2|.
B a s e d e d a t o s r e l a c i o n a l . Una base de datos construida nicamente con relaciones normalizadas.
Clave. Un elemento de datos (o grupo de elementos de datos) empleado para encontrar o identificar un
registro ("tupia").
231
www.FreeLibros.org
C l a v e c a n d i d a t a . Un atributo o grupo de atributos cuyos valores identifican unvocamente cada tupia
de una relacin y para la cual no puede qutame ninguno de ios atributos sin destruir la identificacin
unvoca.
C l a v e p r i m a r i a . Clave que identifica unvocamente un registro (tupia).
C o h e s i n d e c o i n c i d e n c i a . Utilizada para describir un mdulo que no tiene una relacin significativa
entre sus componentes (aparte de aparecer en un mismo mdulo). La cohesin ms dbil d un
mdulo.
C o h e s i n d e c o m u n i c a c i n . Utilizada para describir un mdulo donde todos los componentes operan en
la misma estructura de datos. Una cohesin buena, pero no ideal en un mdulo.
C o h e s i n d e p r o c e d i m i e n t o . Empleada para describir un mdulo cuyos componentes forman dos o ms
bloques en un diagrama de flujo. No es tan buena como la cohesin de comunicacin o la funcional
D e s a r r o l l o d e a r r i b a h a c i a a b a j o . Una estrategia de desarrollo mediante la cual los mdulos ejecutivos
de control de un sistema se codifican y prueban primero para integrar una versin esqueleto del
sistema, y despus que se ha probado el funcionamiento de las interfaces del sistema, se codifican y
prueban los mdulos de los niveles inferiores.
D F D . Ver diagrama de flujo de datos.
D I A D . Ver diagrama de acceso inmediato de datos.
D i a g r a m a d e a c c e s o i n m e d i a t o d e d a t o s ( D I A D ) . Una representacin de los caminos de acceso
inmediato a un almacenamiento de datos que muestra lo que los usuarios quieren recuperar del
almacenamiento de datos sin llevar a cabo la bsqueda o la clasificacin.
D i a g r a m a d e f l u j o d e d a t o s ( D F D ) . Una representacin de los flujos de datos a travs de un sistema de
cualquier tipo, que muestra las entidades externas que son fuente o destino de los datos, los procesos
que trasforman los datos, y los lugares donde los datos son almacenados.
D i c c i o n a r i o d e d a t o s . Un almacenamiento de datos que describe la naturaleza de cada parte de los datos
empleados en el sistema, que a menudo incluye las descripciones de procesos, entradas del glosario,
y otros tem.
D i r e c t o r i o d e d a t o s . Un almacenamiento de datos, usualmente legible por mquina, que indica dnde
se almacena un dato en un sistema.
D i s e o . El proceso (iterativo) de tomar un modelo lgico de un sistema con un conjunto de objetivos
fuertemente establecidos para este sistema, y producir la especificacin de un sistema fsico que
satisfaga dichos objetivos.
D i s e o e s t r u c t u r a d o . Un conjunto de guias para producir una jerarqua de mdulos lgicos que
representan un sistema altamente modificable. Ver tambin diseo.
D o m i n i o . El conjunto de todos los valores de un elemento de datos que forma parte de una relacin. Es
un equivalente efectivo de un campo o de un elemento de datos.
E E . Ver entidad externa.
E f e c t o l a t e r a l . La disminucin de la cohesin de un mdulo debido a que realiza algunas funciones
menores laterales y que no forman parte de la funcin principal del mdulo.
E l e m e n t o d e d a t o s ( I t e m d e d a t o s , c a m p o ) . La unidad de datos ms pequea que tiene significado para
el propsito que se trata.
E l e m e n t o d e d a t o s c o n t i n u o . Aquel que puede tomar tantos valores dentro de su rango que no resulta
prctico enumerarlos, por ejemplo, una suma de dinero.
E l e m e n t o d e d a t o s d i s c r e t o . Aquel que toma solo un nmero limitado de valores, cada uno de los cuales
tiene generalmente un significado. Ver tambin elemento de datos continuo.
E n l i n e a . Conectado directamente a la computadora de manera que la entrada, la salida, los accesos de
datos y los clculos pueden tener lugar sin ninguna intervencin humana.
E n t i d a d . 1. Entidad externa: fuente o destino de datos en un diagrama de flujo de datos. 2. Algo sobre lo
cual'se almacena informacin en un almacenamiento de datos, por ejemplo, clientes, empleados.
E n t i d a d e x t e r n a (EE). Ver entidad.
E s p e c t r o d e c o n t r o l . El nmero de mdulos directamente invocados por otros mdulos. No debera ser
ni muy alto (excepto en el caso de un mdulo despachador) ni muy bajo.
Estructura de datos. Uno o ms elementos de datos con una forma de relacin particular, que
generalmente se utilizan para describir alguna entidad.
F a c t o r e a r . Una funcin o mdulo lgico se factorea cuando se lo descompone en funciones o mdulos
menores componentes.
F s i c o . Relacionado con la forma particular en que los datos o la lgica es representada o implementada
en un momento particular. A una declaracin fsica no se le puede asignar ms de una
implementacin del mundo real. Ver tambin lgico.
F u n c i o n a l . 1. Cohesin funcional: empleada para describir un mdulo donde todos sus componentes en
232
www.FreeLibros.org
conjunto contribuyen a la ejecucin de una sola funcin. 2. Dependencia funcional: un elemento de
datos A es funcionalmente dependiente de otro elemento de datos B s dado el valor de B se
determina el correspondiente valor de A.
G r a d o ( d e r e l a c i n n o r m a l i z a d a ) . El nmero de dominios que integran la relacin (Si existieran siete
dominios, la relacin es de grado 7).
G r f i c o d e e s t r u c t u r a . Un modelo lgico de una jerarqua modular, que muestra invocacin,
comunicacin inter-modular (datos y control), y la ubicacin de lazos y decisiones importantes. Ver
Fig. 9.32.
G r u p o ( t e m ) . Una estructura de datos compuesta de un pequeo nmero de elementos de datos, con un
nombre, referida como un conjunto. Ver tambin agregado de datos.
H I P O (proceso jerrquico de entrada salida). Una tcnica grfica similar al diagrama de estructura que
muestra un modelo lgico de una jerarqua modular. Un diagrama HIPO generalizado indica la
jerarqua de los mdulos: los detalles de entrada, procesamiento y salida de cada mdulo se indican
en un diagrama de detalle separado, a razn de uno por mdulo.
I n d i c e . Un almacenamiento de datos que como parte del proceso de recuperacin toma informacin
sobre los valores de algn atributos) y retorna con informacin que permite que el/los registro(s)
con esos atributos sea(n) recuperado(s) rpidamente.
I n d i c e s e c u n d a r i o . Un ndice de un almacenamiento de datos basado en algn atributo distinto de la
clave primaria.
I R A C I S : Acrstico en idioma ingls que significa mayores ingresos, gastos evitables, servicio mejorado.
L e n g u a j e c o m p r i m i d o . Una herramienta para representar polticas y procedimientos con la menor
ambigedad posible.. Ver tambin lenguaje estructurado.
L e n g u a j e e s t r u c t u r a d o . Una herramienta para representar polticas y procedimientos en lenguaje
corriente en forma precisa, empleando las estructuras lgicas de la codificacin estructurada. Ver
tambin pseudocdigo.
I t e m d e d a t o s . Ver e l e m e n t o d e d a t o s .
L x i c o g r f i c o . Hace al orden en el que se escriben las sentencias de un programa. El mdulo A est
lxicogrficamente incluido en el mdulo B si las sentencias de A se encuentran incluidas en las
sentencias de B en el listado fuente.
L g i c o . 1. No fsico (de una entidad, sentencia, o grfico): factible de ser implementado en ms de una
forma, y que expresa la naturaleza subyacente del sistema referido. 2. Cohesin lgica: empleado
para describir un mdulo que realiza un nmero de funciones similares aunque ligeramente
diferentes - una cohesin pobre de mdulos.
M d u l o . 1. Mdulo lgico: una funcin o un conjunto de funciones referidas por un nombre. 2. Mdulo
fsico: una secuencia de sentencias contiguas de programa, limitada por un elemento vecino, y
referida por un nombre.
N o r m a l i z a d a ( r e l a c i n ) . Una relacin (archivo), sin grupos repetitivos, de manera que los valores de los
elementos de datos (dominios) puedan ser representados como una tabla bidimensional.
P a t o l g i c a ( c o n e x i n ) . Una forma rigurosa de acoplamiento intermodular donde un mdulo se refiere a
algo que se encuentra dentro de otro mdulo. Ver tambin acoplamiento de contenido.
P r i m e r a f o r m a n o r m a l (lFN).Una relacin sin grupos repetitivos (una relacin normalizada) pero que
no satisface las pruebas ms exigentes de la segunda y tercera forma normal.
P r o c e s o ( t r a n s f o r m a c i n ) . Un conjunto de operaciones de transformacin de datos, lgica o
fsicamente, de acuerdo con alguna lgica de proceso.
P r o g r a m a c i n e s t r u c t u r a d a ( c o d i f i c a c i n ) . La construccin de programas empleando un pequeo
nmero de construcciones lgicas, cada una con una entrada, una salida, en una jerarqua
enlazada.
P s e u d o c d i g o . Una herramienta para la especificacin de un programa lgico en un formato legible, en
forma similar al lenguaje corriente, pero sin observar las reglas sintcticas de ningn lenguaje de
programacin en particular.
R e l a c i n . Un archivo representado en formato normalizado como una tabla bidimensional de elementos
de datos.
S e g m e n t o . Un grupo de (uno o ms) elementos de datos; la unidad de datos accedida por el software
IMS. Comparar grupo, agregado de datos.
S e g u n d a f o r m a n o r m a l ( 2 F N ) . Una relacin normalizada en la cual todos ios dominios no-clave son
completamente dependientes de la clave primaria.
S u b s i s t e m a p e r s o n a l . Los flujos de datos y procesos, dentro de un sistema integral de informacin, que
son manejados por personas: la documentacin y capacitacin necesarios para hacer funcionar este
tipo de subsistema.
233
www.FreeLibros.org
T a b l a d e d e c i s i n . Un grfico tabular que presenta la lgica que relaciona diversas combinaciones de
condiciones con un conjunto de acciones. Generalmente se tratari en la tabla todas las
combinaciones posibles de condiciones.
T e r c e r a f o r m a n o r m a l ( 3 F N ) . Una relacin normalizada en la cual todos los dominios no-clave son
completamente dependientes de la clave primaria y todos los dominios no-clave son mutuamente
independientes.
T S O . Opcin de tiempo compartido: un dispositivo del software de IBM que permite el ingreso y la
edicin de programas y de texto a travs de terminales en linea.
T u p i a . Un conjunto especifico de valores para los dominios que permiten realizar una relacin. El
trmino ''relaciona!'' para un registro. Ver tambin segmento.
Volatilidad. Una medida del rgimen o tasa de cambio del contenido de un archivo, en especial en
trminos de agregados de nuevos registros y de eliminacin de los antiguos.
234
www.FreeLibros.org
Este libro se termin de imprimir el 20 de abril de 1987
en Grfica Yanina, Repblica Argentina 2686, V. Alsina, Bs. As.
www.FreeLibros.org