Análisis Estructurado Moderno - Edward Yourdon

www.FreeLibros.
org
www.FreeLibros.org
A n l is is
E structurado
M oderno
www.FreeLibros.org
A musm
E STRUCTURADO
M oderno
E d w a r Youirdon
Traduccin:
F s ic a A ie x a n d ra T aylor A rm itage
Facultad d e In fo rm tic a y C o m p u ta c i n
U n iv e rs id a d d e G uadal ajara
Revisin Tcnica:
G u ille rm o L e v in e G u ti rre z
D ir e c to r F a c u lta d d e In fo rm tic a y C o m p u ta c i n
U n iv e rs id a d d e G u a d a la ja ra
www.FreeLibros.org
PRENTICE-HALL HISPANOAMERICANA, S.A.
M xico - Englewood C liffs - Londres - Sydney - Toronto

Nueva Delhil - Tokio - Singapur - Rio de Janeiro
EDICION EN ESPAOL
DIRECTOR:
EDITOR:
G EREN TE DE
SUPERVISOR
GERENTE DE
SU PERVISOR
TRADU CCION:
DE TRADUCCION
PRODUCCION:
DE PRODUCCION:
Raymundo Cruzado Gonzlez

Jos Tm as Prez Bonilla
Jorge B onilla Talavera
E nrique Palos Bez
Eloy Pineda
T eresa Parra Villafaa
EDICION EN INGLES
E ditorial/production supervisin: Sophie Papanikolaou
Cover design: W anda Lubelska Design
Manufaeturing buyer: M ary Aun Gloriande
EDW ARD YOURDON: A N A L I S I S ESTRUCTURADO M O D E R N O 1 /E

Traduccin de la prim era edicin en ingls de
M ODERN STRUCTURED ANALYSIS

Prohibida la reproduccin total o parcial de esta obra, por cualquier medio o m todo sin autorizacin por
escrito del editor.
D E R E C H O S R E S E R V A D O S 1993 respecto a la primera edicin en espaol por
P R E N T IC E -H A L L H IS P A N O A M E R IC A N A . S .A .
E nrique Jacob 20, Coi. Conde
53500 Naucalpan de Jurez, Edo. de M xico
ISBN 968-880-303-0
M iem bro de la Cm ara N acional de la Industria
E ditorial, Reg. Nm. 1524
O riginal English Language Edition Published by
C opyright 1989 by Prentice-Hall Inc.
AH Rights Rcserved
IS B N 0 -1 3 -5 9 8 6 2 4 -9
2
UTOGRFICA tNGSAMEX, S.A DECV
CENTENO 162-1
ukico.d '
Cl> , _____________________
g
Q
www.FreeLibros.org
IM P R E S O E N M E X IC O / P R IN T E D IN M E X IC O
CONTENIDO
PREFACIO
PA
1
2
3
4
5
S
7
PA
8
9
10
11
12
13
14
15
16
PA
17
18
19
vil
INTRODUCCION
Introduccin 1
La naturaleza de los sistem as 10
Los participantes en el juego de los sistem as 45
Herram ientas del anlisis e structurad o 72
El c ic lo de vida del proyecto 86
A spectos im portantes en el de sa rrollo de sistem as
Cambios en el anlisis de sistem as 136
117
LAS HERRAMIENTAS DE MODELADO

C aractersticas de las herram ientas de m odelado 149
Diagramas de flu jo de datos 157
El d iccio n a rio de datos 211
E specificaciones de proceso 227
Diagramas de entidad-relacin 260
Diagramas de tra n sici n de estados 288
Balanceo de m odelos 305
H erram ientas adicionales de m odelado 319
Herram ientas de m odelado para a dm inistracin de proyectos
EL PROCESO DE ANALISIS
El m odelo esencial 352
El m odelo am biental 368
C onstruccin de un m odelo prelim ina r de com portam iento
340
www.FreeLibros.org
V
395
20
21
T erm inado del m odelo de com portam iento 408

El m odelo de im plantacin del usuario 419
PARTE IV SEGUIMIENTO
22
Pasando al diseo 452
23
Program acin y prueba 470
24
M antenim iento de la especifica ci n 492
25
El fu tu ro del an lisis estru ctu ra d o 499
APENDICES
A
Herram ientas autom atizadas 513
B
Reglas de estim acin 534
C
C lculo de co sto /be n eficio 549
D
A u dito ra s e inspeccion es 568
E
Tcnicas de entrevista y recoleccin de datos 575
F
Caso de estudio: Y ourdon Press 588
G
Caso de estudio: El problem a del elevador 693
INDICE ALFABETICO
723
www.FreeLibros.org
P REF ACI O
Lo que es valioso no es nuevo y o que es nuevo no es valioso.

H enry Peter, Lord Brougham
The E d in b u rgh Review, 1802
P erm tanm e comenzar por hacer una pregunta muy importante: realmente
necesita el mundo de otro libro de anlisis de sistemas? Esto pudiera parecer una
pregunta retrica, pero ha habido muchas ocasiones, usualmente ya entrada la no
che, al estar trabajando en este libro, que me he preguntado: Por qu estoy ha
ciendo esto? Qu hay de malo con los dems libros que todo mundo ha estado
leyendo durante los ltimos diez aos? Cmo puedo tener siquiera la esperanza
de aadir algo al cuerpo literario existente?
Obviamente, sern otros los que tengan que juzgar los resultados. Pero s
pienso que es necesario un libro que actualice algo del material clsico de anlisis
estructurado que se public por primera vez a finales de la dcada de los 70. Cuan
do Tom DeMarco escribi Structured Analysis and Systemas Specification, y Chris
Gane y Trish Sarson escrib ieron S tru ctu re d S ystem s A n a lysis: Tools and
Techniques, no existan los lenguajes de programacin de cuarta generacin y no
haba herramientas de creacin de prototipos disponibles para los creadores de sis
temas. Las computadoras personales no existan en aquellos das, a excepcin de
algunas de las mquinas primitivas de Apple y Radio Shack. No haba productos de
software para estaciones de trabajo que pudieran auxiliar al analista de sistemas en
la creacin de diagramas de flujo de datos.
El desarrollo en estas reas ha tenido un gran impacto en la aceptacin gene
ralizada del anlisis estructurado: muchos discuten sobre si el anlisis estructurado
es pertinente en un ambiente en el que los usuarios crean sus propias aplicaciones
en cuestin de horas o de das. Esto por s solo es razn para crear un nuevo libro
que trate el tema de! anlisis de sistemas: la disponibilidad de tecnologa enorme
mente ms poderosa, tanto para analistas de sistemas como para el usuario, ha
cambiado nuestro enfoque y perspectiva.
Adems, los creadores de sistemas tuvieron que hacerse cargo de cuestiones
como sistemas de bases de datos y sistemas de tiempo real, as como de los siste
mas orientados a funciones originalmente tratados por el anlisis estructural a fines
www.FreeLibros.org
V i!
vi i i PREFACIO
de la dcada de los 70, Este libro analiza ios diagramas de entidad-relacin y de

transicin de estados, adems de los clsicos diagramas de flujo de datos, y mues
tra cmo pueden integrarse los tres modelos; esta integracin de modelos se volver
ms y ms importante en os aos venideros. Se han incluido en este libro varios
otros avances recientes en el anlisis estructurado, Incluyendo la particin de even
tos y la menor importancia del modelado de los sistemas fsicos actuales.
Existe una razn ms para escribir otro libro sobre el anlisis de sistemas: la
mayora de ios libros clsicos de anlisis estructurado estn dirigidos a analistas
de sistemas adultos y veteranos, con poca o ninguna consideracin para la persona
ms joven que apenas comienza en el campo. Al mismo tiempo, la mayora de los
textos universitarios que tratan el anlisis de sistemas y que se escribieron durante
ios ltimos diez aos prestaban escasa atencin a las nuevas tcnicas de anlisis
estructurado y han continuado dedicando demasiadas pginas a discusiones sobre
las tarjetas perforadas y los cdigos Hollerith. Adems del hecho de que muchos de
estos temas son obsoletos, generalmente se ofrece un estudio superficial del hard
ware de las computadoras, el software y la programacin por medio de un curso de
introduccin a la computacin que precedera a un curso a profundidad de anlisis
de sistemas. Este libro procura ser balanceado al reconocer que es necesario algn
material introductorio para el estudiante que ha llevado un curso de introduccin a
las computadoras pero que nunca ha hecho anlisis de sistemas, al mismo tiempo
que reconoce que ios conceptos del anlisis estructurado son lo suficientemente
sencillos como para ser presentados en bastante detalle a nivel de bachillerato y a
nivel universitario. Sin embargo, la mayor parte del material introductorio se coloc
en los apndices, de modo que pueda omitirlo el profesional en la industria.
El libro debe ser apropiado para un curso de anlisis de sistemas de un se
mestre, en el nivel de licenciatura; cubre los temas para el curso CIS-86/5 en el cu
rrculum modelo GIS 86 para la licenciatura en informtica. Sin embargo, no
pretende abarcar tanto el tema del anlisis de sistemas como el de su diseo, a
pesar de que varias universidades tratan de comprender ambos en un solo semes
tre. Creo que hay bastante material para discutir en cada una de las dos reas; reco
miendo, para un curso de un semestre de diseo estructurado, los siguientes libros:
PracticaI Gude to Structured Systems Desng, segunda edicin, de Meilir Page-Jones (YOURDON Press, Englewood Cliffs, N.J., 1988), o bien Structured Design,
segunda edicin, de Ed Yourdon y Larry Constantne (YOURDON Press, Englewood
Cliffs, N.J., 1989).
Es posible que los veteranos del anlisis de sistemas quieran leer slo el pri
mer captulo para orientarse y saltarse el resto de la parte I; los primeros siete cap
tu lo s son esenciale s para los e stu d ian te s nuevos. Los veteranos estarn
familiarizados con los diagramas de flujo de datos, los diccionarios de datos, etc.
Sin embargo, en el captulo 9 hay material que trata de las extensiones de los dia
gramas de flujo de datos para los sistemas de tiempo real, que pudieran ser novedo
sos para aquello s que se hayan dedicado exclusivam ente a os sistem as de
www.FreeLibros.org
PREFACIO x
negocios. Tambin pudieran ser novedosos ios diagramas de entidad-relacin para

los que estn ms familiarizados con los diagramas de estructura de datos; el cap
tulo 13, que trata de los diagramas de transiciones de estados, brinda una herra
mienta de modelado nueva e importante. Y algo que es de suma importancia para el
veterano: los captulos 19 y 20 brindan un planteamiento que contrasta enormemen
te con el enfoque rgido de arriba-abajo que han seguido ios analistas durante aos
para la construccin del modelo esencial (a veces conocido como el modelo lgico);
se trata del mtodo conocido como particin de eventos, basado en la obra de McMenamin y Palmer. El Captulo 17 recomienda que se elimine el enfoque clsico de
modelar el sistema actual del usuario; los analistas de sistemas cuya tcnica se ba
sa en textos de la dcada de los 70 debieran estudiar esto con cuidado.
Entre los apndices hay dos casos que ilustran las tcnicas y herramientas
que se tratan en este libro. El primero es una aplicacin tpica de negocios, basada
en la operacin de la editorial YOURDON Press; el segundo es un ejemplo ms ca
racterstico de un sistema de tiempo real , basado en el sistema de control de un
elevador. Ambos se presentan con detalle, aunque esto haga ms grueso el libro,
es importante para el estudiante ver un ejemplo completo de una especificacin.
Ambos modelos pueden usarse para discusiones y ejercicios en ciase.
Ei anlisis estructurado moderno utiliza aos de experiencia con cientos de
clientes, miles de estudiantes y docenas de colegas de las empresas YOURDON,
Inc., y de otras organizaciones. Me declaro en deuda con todas estas personas, que
son demasiadas para poderlas nombrar. Pero hay algunas que merecen una men
cin especial, pues me ayudaron a intentar que este libro fuera mejor. En la actuali
dad no se puede escribir un libro de anlisis estructurado sin darle reconocimiento a
las obras precursoras de Tom DeMarco, Chris Gane y Trish Sarson. Y me siento
igualmente en deuda con Steve McMenamin y John Palmer, quienes dieron un im
portante paso adelante con su obra Essential Systems Analysis; de manera similar,
Paul Ward y Steve Melior introdujeron varios conceptos y herramientas importantes
para los sistemas de tiempo real con su obra de tres volmenes, Structured Deveopment for Real-Time Systems. Tambin me han ayudado los debates que he teni
do con otros colegas, al ensear a n lisis estructurado en Estados Unidos e
Inglaterra. Agradezco de manera especial a John Bowen, Julin Morgan, Bob Spurgeon, Nick Mandato y Alex Gersznowicz por haberme mostrado maneras muy elo
cuentes de explicar el anlisis estructurado que jams se me hubieran ocurrido.
Adems, el profesor Peter Brown y un grupo de alumnos suyos de la Universidad
Duquesne depuraron el libro, al utilizarlo como texto para un curso de anlisis es
tructurado; les agradezco sus sufrimientos con todos los errores tipogrficos que te
nan los primeros borradores.
Tambin quiero agradecerle a Dennis Sipe de la sucursal en Washington
D.C. de YOURDON, Inc., por ei intenso trabajo de anlisis que hizo en el modelo de
anlisis estructurado del sistema de elevadores del apndice G. La mayora de los
textos actuales slo contienen casos de estudio de sistemas orientados a los neg-
www.FreeLibros.org
x PREFACIO
cios; este libro contiene tanto un caso orientado a negocios (apndice F), como un
ejemplo de tiempo real, basado en la descripcin de la ACM [Association for Computing Machinery, N. dei T.} de un problema real. Originalmente, Dennis dise el mo
delo de anlisis estructurado para un seminario de guerras de diseo patrocinado
por la seccin Washington de la ACM, en 1986, con el propsito de mostrar cmo se
manejara el problema del control de un sistema de cuatro elevadores con las dife
rentes metodologas de ingeniera de software; desde entonces se ha modificado va
rias veces.
Peter Brown, Pete Coad, Bob Spurgeon, Steve Weiss. Ron Teemley y Dale
Brown mejoraron enormemente el borrador de este libro con sus revisiones y comen
tarios; obviamente, me hago responsable de todos los errores cometidos y de las
omisiones que an queden. Mientras tanto, mi esposa y mis hijos me dieron un gran
apoyo abastecindome continuamente de Coca Cola diettica y papitas (y ocasional
mente cognac, cuando la ocasin lo ameritaba); para cuando acab el libro, haba
aumentado 10 kilos de peso y tuve que ponerme a dieta.
En contraste con lo que ios autores paranoicos como yo suelen sufrir a manos
de los editores, varias personas de YOURDON Press/Prentice Hall hicieron de la
produccin de este libro una experiencia encantadora. Pat Jenny y Ed Moura vigila
ron el proyecto desde el principio y me dieron nimos cuando ms lo necesitaba.
Sophie Papanikolaou supervis la produccin del libro y fue un placer trabajar con
ella. Bill Thomas se encarg de la revisin del libro y encontr los miles, o millones,
de errores tipogrficos y gramaticales. Despus, mi esposa, Toni, corrigi de buen
grado todos los errores en la computadora, aunque a escuch murmurar en voz baja
que un matemtico no debera pretender que sabe escribir.
Finalmente, me gustara agradecerle a mi(s) computadora(s) Macintosh por
batallar valientemente con el enorme manuscrito. La mayor parte del escrito se hizo
con Microsoft Word (versiones 1.0, 1.05, 3.0, y 3.01) pero tambin utilic MacPaint,
Fullpaint, SuperPant, MacDraw, Microsoft Chart, MacProject, Microsoft Multiplan,
ChessMaster, ConcertWare, MORE de Living Videotext, MacBubbles de StarSys
Inc., y Design de Meta Software, sin contar varios fragmentos de arte del recorte
de T/Maker y otros editores. Quienquiera que intente escribir un libro con algo que
no sea una Macintosh debera Ir a que le examinen la cabeza.
Edward Yourdon
Nueva York, agosto de 1988
www.FreeLibros.org
cj
PARTE 1: INTRODUCCION
El com ienzo y el fin a l de to d a actividad hum ana son desordenados: la co n s

trucci n de una casa, la e scritura de una novela, la d em olicin de un puente
y, em inentem ente, el trm ino de un viaje,
John G alsw orthy
O ve r the River, 1933
En est captulo ce aprender:

1. Por qu es interesante el anlisis de sistemas.
2. Por qu es ms difcil el anlisis de sistemas que la
programacin.
3. Por qu es importante estar familiarizado con el
anlisis de sistemas.
B ie n . Aqu estamos al comienzo de un largo libro. La perspectiva de leer un

libro tcnico tan largo probablemente lo aterrorice; pero, si le sirve de consuelo, es
an ms aterradora la perspectiva de estar comenzando a escribirlo. Afortunada
mente, as como los viajes largos se llevan a cabo un da por vez y, por ltimo, un
paso a la vez, de igual manera se acaban de leer los libros largos un captulo por
vez y, a fin de cuentas, una frase a la vez.
1.1
POR QUE ES INTERESANTE EL ANALISIS DE SISTEMAS?
Los libros largos a menudo son aburridos; espero que ste no lo sea. Por for
tuna, el tema de este libro, anlisis de sistemas, es interesante. De hecho, el anli
sis de sistemas es ms interesante que cualquier cosa que yo conozca, con la
www.FreeLibros.org
4 INTRODUCCION
Aun cuando no se vaya a dedicar a un empleo de oficina (es decir, si piensa

ser artista, escritor, msico o atleta), debiera saber de qu trata ei anlisis de siste
mas. Los sistemas computacionales de diversos tipos afectan a toda clase de per
sonas. Aun si jams piensa construir un sistema computacional ni hacer que le
diseen uno, es inevitable que vaya a hacer uso de sistemas computacionales para
sus finanzas, su educacin, su interaccin con las oficinas de impuestos y del segu
ro social, y para casi cualquier interaccin que pueda llegar a tener con la sociedad
moderna. Como lo afirma John Gal en su obra Systematics [Gall, 1977].
N adie puede, hoy en da, e vita r el contacto con los sistem as. Los
sistem as estn en to d as partes: sistem as grandes, sistem as peque
os, sistem as m ecnicos y electrnicos, y aq u ello s siste m a s e spe
ciales que consisten en a so cia cio n es o rganizadas de personas. En
defensa propia, debem os a p render a viv ir con los sistem as, a co n
trola rlo s antes de que ellos nos controlen a nosotros. Com o le dijo
H um pty D um pty a A licia (aunque en otro contexto): La pregunta es:
quin ha de se r ei am o, eso es todo."
Para enfatizar esto an ms, tenga en mente que la industria de las computa
doras represent aproximadamente el 8% del producto interno bruto (PIB) de los Es
tados Unidos en 1985; para 1990 se espera que represente el 15% del PIB 3 Casi
todos los productos fabricados hoy por las empresas americanas involucran una o
ms computadoras, y casi cualquier servicio ofrecido al mercado por las empresas
norteamericanas se basa en, o es controlado por, un sistema computacional.
1.3
QUE HARA ESTE LIBRO POR USTED
Como ya habr adivinado, uno de los principales propsitos de este libro es

ensearle ms acerca del anlisis de sistemas: qu es y cmo se las arregla uno pa
ra llevarlo acabo, Pero an hay ms: mi verdadero propsito es emocionarlo, entu
siasmarlo tanto con empezar a practicar ei anlisis de sistemas que querr acabar
este libro a toda prisa y comenzar a trabajar en su primer proyecto. Seymour Papert
hace ia siguiente remembranza en su obra Mindstorms [Papert, 1980],
Encontr un placer p a rticu la r en sistem as ta ie s com o la ca ja de ve
locidades d ife re n cia l, que no sigue una sim ple cadena lineal de cau
salidad, p uesto que el m ovim iento en el eje de transm isin puede
d istribu irse de m uchas form as d ife re n te s a las dos ruedas, d e pen
diendo de la resiste n cia que se encuentre. R ecuerdo con m ucha
cla rid ad mi em ocin ai d e scu brir que un sistem a poda se r vlido y
com pletam ente com prensible sin ser rgidam ente determ nstico.
Y como dijo Sir Stanley Eddington [Eddington, 1987],

Hem os e n contrado que donde la ciencia ms ha avanzado, la m en
te no ha hecho sino recuperar de !a naturaleza lo que puso en ella.
www.FreeLibros.org
3 Para ms d e talles sobre esto, a s com o para oros an lisis sobre ei im pacto de las com p u ta d o ra s
en la sociedad, vase N a tions a t R isk [Yourdon, 1986],
INTRODUCCION 5
H em os e n co ntra d o una e xtra a h u e lla en las p la ya s de lo

desconocido. Hem os elaborado p rofundas teoras, una tras otra, pa
ra exp lica r su origen. Finalm ente hem os tenido xito en reconstruir
la cria tu ra que hizo la huella. Y, sorpresa!, som os nosotros.
Otro propsito de este libro es hacerle entender y apreciar que vivimos en un

mundo de sistemas, y de sistemas dentro de sistemas, que son parte de otros an
mayores. Por tanto, todo lo que hacemos en nuestras vidas personales y profesio
nales tiene impacto (a menudo inesperado y no anticipado) sobre los diversos siste
mas de los cuales formamos parte. Este enfoque de pensar en sistemas no slo
es vital para los analistas profesionales sino para todos los miembros de nuestra so
ciedad moderna.
Desgraciadamente, este libro no lo podr convertir en un analista de sistemas
con experiencia, como tampoco un libro de teora musical puede convertirlo en pia
nista experimentado. Para cuando termine este libro, estar armado con una tre
menda cantidad de informacin que lo ayudar a desarrollar modelos precisos de
sistemas complejos, y conocer paso a paso las tcnicas para efectuar un esfuerzo
de anlisis de sistemas. Sin embargo, necesitar an una gran cantidad de trabajo
concreto para poder desarrollar habilidades: cmo entrevistar a una variedad de di
ferentes usuarios para entender la verdadera esencia de un sistema; cmo presentar
los resultados de su trabajo de anlisis de sistemas para que todo mundo pueda dar
se cuenta de los verdaderos costos y beneficios de desarrollar un nuevo sistema; c
mo diferenciar problemas de sntomas. Como seal Barry Bohem en su obra
clsica, Software Engineerng Economas [Bohem, 1981]:
C ada uno de nosotros com o ingeniero de softw are individual" tiene
la oportunidad de causar un im pacto po sitivo en la sociedad, smpiem ente volvindonos m s sensibles a las profundas im p licaciones
que nuestro trab a jo tiene en las relacion e s hum anas, y al incorporar
esta sensibilidad a nuestros productos y diseos de softw are.
Hacer esto bien requiere algo de prctica, as com o a p re n
der a balancear las cuestiones de relaciones hum anas con la pro
g ra m a ci n y con lo s a su n to s e co n m ico s c u a n tita tiv o s . La gran
cosa que hay que recordar al hacerlo es m antener claras nuestras
p rioridades entre la p rogram acin, ios presupuestos y las relaciones
hum anas.
1.4
ORGANIZACION DEL LIBRO
Este libro est organizado en cuatro partes principales, seguidas de una serie
de apndices. La parte I sirve de introduccin a todo el libro y ste comienza, en el
captulo 2, por una introduccin al concepto de sistemas y la naturaleza del anlisis
de sistemas; en este captulo veremos que los sistemas de informacin usualmente
estn compuestos por personas, hardware, software (programas de computadora),
procedimientos, datos e informacin. El captulo 3 describe a las personas que nor
malmente estn involucradas en el desarrollo de un sistema moderno de informa
www.FreeLibros.org
6 INTRODUCCION
cin: los usuarios, ios administradores, el personal de operaciones, los miembros del
grupo de control de calidad, etc., y el papel especial y las responsabilidades del ana
lista de sistemas. El Captulo 4 introduce las herramientas de modelado que el ana
lista de sistemas utiliza, incluyendo diagramas de flujo de datos, diagramas de
entidad-relacin y diagramas de transicin de estados. El captulo 5 presenta los
procedimientos (o la metodologa) que el analista sigue cuando desarrolla un sis
tema.
Aunque usted crea conocer muchas de estas cosas ya, hay algunos captulos
en la parte I que es importante que lea, porque definen el tono del resto del libro. El
captulo 2 , por ejemplo, presenta y discute los axiomas y principios fundamentales
que esperaramos encontrar en todo el trabajo de anlisis de sistemas: el desarrollo
de modelos de sistemas, la nocin de iteracin, y la nocin de particin de arribaabajo. Y el captulo 6 delinea las principales cuestiones que enfrenta el analista de
sistemas hoy: cuestiones de productividad, calidad de sistemas, mantenimiento, y
utilizacin estratgica de informacin. Finalmente, el captulo 7 resume los principa
les cambios que han sucedido en el campo del anlisis de sistemas en os ltimos
diez aos.
La parte II trata de las herramientas de modelado de sistemas con detalle.
Los captulos individuales cubren temas de diagramas de flujo de datos (captulo 9),
diccionarios de datos (captulo 10), especificacin de procesos (captulo 11), diagra
mas de entidad-relacin (captulo 12), y diagramas de transicin de estados (captu
lo 13). Los captulos 15 y 16 presentan otras herramientas de modelado que utilizan
los analistas cuando estudian un sistema: diagramas PERT, diagramas de Gantt,
diagramas de flujo, diagramas HIPO, diagramas de estructura, etc. Como podremos
ver, estas herramientas de modelado permitirn enfocarnos selectivamente a los as
pectos individuales de un sistema cuyas caractersticas es importante entender: las
funciones que el sistema debe desempear, los datos que debe manejar y su com
portamiento en el tiempo.
Aun cuando usted nunca vea una computadora al terminar de leer este libro,
as herramientas de modelado de la parte II pueden serle tiles para modelar (o des
cribir o imaginarse) prcticamente cualquier tipo de sistema: biolgicos, de negocios,
ecosistemas, sistemas de manufactura, polticos, de flujo de materiales, etc. Vivi
mos en un mundo de sistemas, y la mayor parte de nuestra vida cotidiana se emplea
tratando de comprender y trabajar con los mltiples sistemas con los cuales entra
mos en contacto; las herramientas de modelado son de enorme ayuda en este as
pecto.
La parte III se refiere al proceso de anlisis de sistemas, es decir, los pasos
que un analista lleva a cabo cuando construye el modelo de un sistema. Aqu tam
bin, la informacin que obtendr ser de utilidad independientemente de su profe
sin; el material definitivam ente se dirige hacia la construccin de sistemas de
Informacin automatizados. Veremos que el proceso, o metodologa, para construir
www.FreeLibros.org
INTRODUCCION 7
un sistema involucra el desarrollo de diversos tipos de modelos, el ltimo de los cua

les ser el producto del anlisis de sistemas. En muchas empresas este producto se
conoce como especificacin funcional, o documento de requerimientos de nego
cios, o diseo de sistemas de negocios. Independientemente de su nombre, es el
material para ios responsables de la construccin misma del sistema, es decir, de di
sear la arquitectura general de las computadoras y su software y, finalmente, de
escribir y probar los programas.
Esto nos lleva a la parte IV: la vida despus del anlisis de sistemas. Explora
remos el paso desde el anlisis de sistemas hasta el diseo y discutiremos breve
mente ios detalles finales de la programacin y la prueba. Dado que la mayora de
ios sistemas de informacin automatizados tienen una vida meda de varios aos (y
a menudo de varias dcadas), tambin discutiremos el tema del mantenimiento en el
captulo 24; pero nuestra principal preocupacin no ser ia programacin para el
mantenimiento, sino el mantenimiento dei producto del anlisis de sistemas. El lti
mo captulo trata del futuro: los cambios evolutivos en el campo del anlisis de siste
mas que podemos esperar ver durante los aos 90 y el prximo siglo.
Los Apndices que se encuentran al final del libro tratan cuestiones separadas
que pueden o no llegar a afectarlo cuando comience a trabajar como analista de sis
temas. El Apndice A, por ejemplo, maneja ei tema de las estaciones de trabajo ba
sadas en PCs para el anlisis de sistemas, a lo cual pocos analistas tenan acceso a
comienzo de la dcada de los 80, pero que se han vuelto cada vez ms comunes en
los aos 90. El Apndice B expone las frmulas de estimacin y la mtrica utiliza
das para calcular el tamao, duracin y costo de un proyecto. Ei Apndice C analiza
ios clculos de costo-beneficio. El Apndice D cubre el tema de los recorridos y las
inspecciones (watkthroughs), que a menudo se utilizan para revisar los productos
tcnicos del anlisis de sistemas. El Apndice E analiza las tcnicas de entrevista y
acopio de datos, sobre todo para aquellas entrevistas que se llevan a cabo entre el
usuario y el analista de sistemas. Todo esto se ha acomodado en apndices para
que ei analista experimentado pueda saltarse fcilmente los que considere prescindi
bles; los estudiantes principiantes pueden recurrir a los apndices cuando sea con
veniente para cubrir temas que seguramente surgirn durante los proyectos reales.
Los Apndices F y G presentan dos casos de estudio: uno es un sistema
orientado a los negocios, y ei otro es un sistema de tiempo real. Si usted es un es
tudiante que inicia, al final de cada captulo deber referirse a estos casos de estu
dio para ver cmo pueden aplicarse a situaciones reales los principios recin
aprendidos. De hecho, debera leer la introduccin y antecedentes de cada caso de
estudio ahora, para familiarizarse con la naturaleza de cada aplicacin.
Cada captulo tiene preguntas y ejercicios que lo ayudarn a revisar lo que ha
aprendido. Algunos ejercicios estn etiquetados como proyectos de investigacin",
lo cual significa que se enfocan a hechos que no estn cubiertos directamente en el
captulo, pero que son pertinentes en el mundo real del anlisis de sistemas. Agu-
www.FreeLibros.org
8 INTRODUCCION
as de las preguntas estn enfocadas a discusiones en clase; no hay respuestas co

rrectas o incorrectas, aunque s hay respuestas que son ms fciles de defender que
otras.
Terminemos con las introducciones y empecemos. Comenzaremos por hablar
de la naturaleza de los sistemas.
REFERENCIAS
1.
Tom DeMarco. Structured Anaiysis and Systems Specification.

Cliffs, N.J.: Prentice-Haii, 1979, pgina 6.
Englewood
2.
John Gal!, Systemantics.

Company, 1977, pg. xiii.
3.
Barry Bohem, Software Engineering Economics. Englewood Cliffs, N.J.: Prentiee-Hali, 1981.
4.
Seymour Papert, Mindsiorms. New York: Basic Books, 1980.
5.
Edward Yourdon, Natons at Risk.

1986.
6.
Sir Arthur Stanley Eddington, Space, Time and Gravitation An Outline o f ihe Ge
neral Theory. London: Cambridge University Press, 1987.
New York: Quadrangle/The New York Times Book
Englewood Cliffs, N.J.: YOURDON Press,
PREGUNTAS Y EJERCICIOS
1.
Explique cmo puede serle til el anlisis de sistemas en su empleo o profe

sin, aun si no planea convertirse en programador o analista.
2.
Proyecto de investigacin: Cuntas personas hay empleadas como analistas

de sistemas en el pas hoy en da? Cul es su salario promedio? Cul es su
nivel promedio de educacin?
3.
Proyecto de investigacin: Existe escasez de programadores y analistas de

sistemas? Trate de encontrar estadsticas de industrias o del Gobierno (por
ejemplo de la Secretara de Comercio o de alguna fundacin cientfica nacional)
que predigan ios requerimientos nacionales de analistas de sistemas durante
ios prximos 10 aos.
4.
D 10 ejemplos de sistemas con los que trata o con los cuales interacta en su
vida cotidiana.
www.FreeLibros.org
5.
Estara estudiando anlisis de sistemas si no tuviera la necesidad de hacerlo?

Si su respuesta es No, explique por qu piensa que el material no ser til o
INTRODUCCION 9
pertinente. Encuentre alguna otra persona que estudie este mismo material y
tenga un debate constructivo respecto a la utilidad general del anlisis de siste
mas.
6.
Cree usted importante que las personas que no utilizan computadoras (o que
no tienen una profesin relacionada) estudien anlisis de sistemas? Qu tan
conocedores cree que deban ser en este tema?
7.
Por qu es probable que el anlisis de sistemas sea ms interesante que la

programacin? Est de acuerdo con este punto de vista?
8.
Qu cosas debe aprender un analista de sistemas aparte de las habilidades

tcnicas para construir modelos de sistemas?
9.
Por qu pueden ser tiles para estudiar sistemas no computacionales las he

rramientas de modelado presentadas en este libro?
www.FreeLibros.org
LA NATURALEZA DE LO:
AS
Finalm ente, pondrem os ai Sol m ism o en el centro dei U niverso. To

do esto lo sugiere la siste m tica procesin de sucesos, as com o a
arm ona del U niverso entero, si tan slo encarram os los hechos,
com o se dice, con am bos oos abiertos".
Nicols Coprnico
De R eva lu iio n ib u s O rbium G oelestium , 1543.
1. Qu es la definicin de un sistema.
2. La diferencia entre sistemas naturales y sistemas
hechos por e! hombre.
3. Los 19 subsistemas principales encontrados en
todos los sistemas vivientes.
4. Las cinco razones principales por las que algunos
sistemas no deben automatizarse.
5. Los cinco componentes principales de un sistema de
informacin automatizado tpico.
6 . La definicin y caractersticas de varios tipos
especficos de sistemas.
7. La definicin de los principios generales de sistemas
y tres ejemplos de ellos.
www.FreeLibros.org
LA NATURALEZA DE LOS SISTEMAS 11
N o podemos decir mucho acerca del anlisis de sistemas hasta que tenga
mos una idea clara de lo que es un sistema: ste es el propsito de este captulo.
Como veremos, existe una definicin oficial dei trmino en el diccionario, que pare
cer algo abstracta. Sin embargo hay muchos usos comunes dei trmino que le se
rn familiares y existen muchos tipos comunes de sistemas con los que tenemos
contacto todos los das.
Se puede estar preguntando Y qu? . Es importante estar familiarizado con
diferentes tipos de sistemas debido, por lo menos a dos razones. Primero, aunque
su trabajo como analista de sistemas probablemente se enfoque en algn tipo de
sistema de informacin computarizado, generalmente formar parte de un sistema
mayor. As, usted tal vez pueda estar haciendo un sistema de nmina que forma
parte de un sistema de recursos humanos, que a su vez forma parte de alguna orga
nizacin (que en s, es un sistema), que a su vez es parte de un sistema econmico
mayor, etc., o bien puede estar haciendo un sistema de control de procesos que es
parte de una refinera qumica o un sistema operativo que sea parte de un paquete
de software suministrado por el proveedor. As, para que su sistema tenga xito, de
be entender los dems sistemas con los que va a interactuar.
Muchos de los sistemas computarizados que construimos son reemplazos o
nuevas versiones de sistemas no computarizados que ya existen. Tambin, la ma
yora de los sistemas computarizados interactan o tienen interfases con una varie
dad de sistemas existentes (algunos de los cuales pueden estar computarizados y
otros no). Para que nuestro nuevo sistema sea exitoso, debemos entender con ra
zonable detalle cmo se comporta el sistema actual.
Segundo, aunque muchos tipos de sistemas parezcan bastante diferentes, re
sulta que tienen similitud: existen principios, teoras y filosofas comunes que se apli
can muy bien, prcticam ente , a todos los tipos de sistem as.
Por ello,
frecuentemente podemos aplicar lo que hemos aprendido acerca de otros sistemas
basndonos en nuestra experiencia diaria, y en la de diversos tipos de cientficos
e ingenieros a ios sistemas que construimos en el campo de la computacin. Por
ejemplo, uno de los principios importantes de sistemas, primeramente observado en
el campo de la biologa, es conocido como la ley de la especializacin: entre ms
adaptado se encuentra un organismo a un ambiente especfico, ms difcil le ser
adaptarse a un ambiente diferente. Esto ayuda a explicar la desaparicin de los di
nosaurios cuando cambi drsticamente el clima de la tierra1- y tambin ayuda a los
analistas a entender que si optimizan un sistema computarizado para obtener la m
1 Los p a le ontlogos an estn discu tie n do esto: unos piensan que los din o sa urio s desaparecieron
en el curso de un periodo relativam ente breve, tras el im pacto de un gran m eteorito con la Tierra,
que o rigin una nube de poivo ta n densa que m at a la m ayora de i as plantas. O tros argum entan
que el cam bio fue m ucho m s gradual, ocurrido en el tran scu rso de casi un m illn de aos. De
cualquier modo, los dinosaurios estaban altam ente a d a pta d o s a un d e term inado tipo de am biente y
no pudieron adaptarse a otro.
www.FreeLibros.org
12 LA NATURALEZA DE LOS SISTEMAS
xima ventaja de un procesador, de un lenguaje de programacin y de un sistema ad

ministrador de base de datos, probablemente tendrn grandes dificultades para
adaptar dicho sistema de forma que se ejecute en un procesador diferente o con un
sistema de administracin de base de datos diferente.2
De aqu que si comprendemos algo acerca de la teora general de sistemas
nos ayudar a entender mejor los sistemas computarzados (automatizados) de in
formacin. Esto se vuelve cada vez ms importante, pues se desea construir siste
mas estables y confiables, que funcionen bien en nuestra compleja sociedad, y
existen, desde luego, muchos ejemplos de sistemas no computarzados que han so
brevivido durante millones de aos: la humilde cucaracha probablemente durar ms
que cualquier sistema computarizado que se haya podido construir, y ms que toda
la humanidad tambin.
As pues, empecemos con una definicin del trmino bsico: sistema. Todo li
bro de texto que cubra algn aspecto de los sistemas contiene tal definicin; he es
cogido el New Collegiate Dictonary de Webster3, que tiene varias definiciones:
1. Grupo de elementos interdependientes o que interactan regular
mente formando un todo <un ~ sistema numrico >: como
a.
(1 )
(2)
Un grupo de cuerpos que interactan bajo la influencia de

fuerzas relacionadas <un ~ gravitacionab
Un conjunto de sustancias que tiendan al equilibrio <un ~
termodinmico>
b.
(1)
(2)
c.
Un grupo de rganos del cuerpo que juntos llevan a cabo

una o ms funciones vitales <el ~ d ig e s tiv o
El cuerpo, considerado como una unidad funcional
Un grupo de fuerzas u objetos naturales <un ~ de ros>
d. Un grupo de aparatos o una organizacin que forma una red,

especialmente para distribuir algo o para servir a un propsito
comn <un - te le f n ic o , <un ~ de calefaccin;-, <un ~ de auto
pistas;, <un ~ de proceso de datos;
2 Tam bin puede a yu d ar al a n a lista de sistem as a entender el fenm eno del usuario que com n
m ente suele realizar activid a d es tan e sp e cia liza da s que no hay m anera de ca m b ia rla s aunque sean
com putarizadas. Y le recuerda que s (lega a d e sa rro lla r un sistem a co m p u ta riza do alta m e n te espe
cializado para la aplicacin a ctu a l que quiere ei usuario, ser m uy d ifcil ad a pta rlo luego, cuando
cam bien o evolucionen los req uerim ientos de ste (y el am biente en el cual trabaja).
www.FreeLibros.org
3 N e w C o llegiate D ictonary de W ebster, S pringfield, M ass.: G.& C. M erriam Com pany, 1977.
2. Juego organizado de doctrinas, ideas o principios, usualmente con

la intencin de explicar el acomodo o trabajo de un todo sistemtico
<el ~ newtoniano de la mecnica>
3. a. un procedimiento organizado o establecido <ei ~ de mecanogra
fa al t a c to
b. una manera de clasificar, simbolizar o esquematizar <un ~ taxo
n m ic o <el ~ decimal>.
4. patrn o arreglo armonioso: ORDEN
5. una sociedad organizada o situacin social considerada como anuladora: ORDEN ESTABLECIDO
2.1
TIPOS COMUNES DE SISTEMAS
Como podemos ver de la definicin anterior, existen muchos tipos diferentes

de sistemas; de hecho, casi todo aquello con lo cual entramos en contacto durante
nuestra vida cotidiana es un sistema o bien parte de un sistema (o ambas cosas).
Significa esto que debemos estudiar todo tipo de sistemas o intentar conver
tirnos en expertos en sistemas sociales, biolgicos y computacionales? Para nada!
Sin embargo, es til organizar los diferentes tipos de sistemas en categoras. Son
posibles muchas diferentes formas de categorizar; de hecho, la definicin obtenida
del diccionario muestra una categorizacin. Dado que nuestro objetivo son los siste
mas computacionales, empezaremos por dividir todos los sistemas en dos catego
ras: sistemas naturales y sistemas hechos por el hombre.
2.2
SISTEMAS NATURALES
La gran mayora de los sistemas no estn hechos por el hombre: existen en la

naturaleza y sirven a sus propios fines. Es conveniente dividir los sistemas natura
les en dos subcategoras bsicas: sistemas fsicos y sistemas vivientes Los sistemas
fsicos incluyen ejemplos tan variados como:
Sistemas estelares: galaxias, sistemas solares, etctera.
Sistemas geolgicos: ros, cordilleras, etctera.
Sistemas moleculares: organizaciones complejas de tomos.
Es interesante estudiar los sistemas fsicos pues, como humanos entrometidos

que somos, a veces queremos modificarlos. Tambin desarrollamos una variedad
de sistemas hechos por el hombre, incluyendo sistemas computacionales, que de
ben interactuar armnicamente con los sistemas fsicos; por tanto, suele ser impor
tante modelar dichos sistemas para asegurarnos que los comprendemos lo ms
completamente posible.
www.FreeLibros.org
Los sistemas vivientes, desde luego, comprenden toda la gama de animales y

plantas que nos rodean, al igual que a la raza humana. Y, como lo menciona James
Miller en su monumental obra, Sistemas Vivientes [Miller, 1978], esta categora tam
bin comprende jerarquas de organismos vivientes individuales, por ejemplo hier
bas, manadas, tribus, grupos sociales, compaas y naciones.
El estudio de los sistemas vivientes es una carrera en s; una breve lectura de
la obra de Miller mostrar lo enorme que es dicho tema. El propsito de este libro
no es estudiar los sistemas vivientes per se; pero algunas de sus propiedades y ca
ractersticas familiares pueden utilizarse para ayudar a lustrar y entender mejor los
sistemas hechos por el hombre. A menudo utilizamos una analoga para entender
mejor algo con o cual no estamos familiarizados; entre las ms elocuentes de las
analogas entre sistemas vivientes y sistemas organizacionales y de negocios, tene
mos las obras de Stafford Beer, Brain o f the Firm [Beer, 1972] y The Heart of Enter
prise [Beer, 1978],
Una analoga ms elaborada puede obtenerse de la categorizacin hecha por
Miller de los 19 subsistemas crticos de todos los sistemas vivientes. Miller argu
menta que los sistemas vivos, sean estos de nivel celular, de rgano, de organismo,
de grupo, de organizacin, de sociedad o de sistema supranacional, contienen los si
guientes subsistemas:
El reproductor, que es capaz de dar origen a otros sistemas similares a

aquel en el cual se encuentra. En una organizacin de negocios, pudiera
ser una divisin de planeacin de instalaciones que hace nuevas plantas
y construye oficinas regionales nuevas.
La frontera, que mantiene unidos a los componentes que conforman el

sistema, los protege de tensiones ambientales y excluye o permite la en
trada de diversos tipos de materia-energa e informacin. En una organi
zacin de negocios, esto pudiera constituir la planta misma (edificio de
oficinas, fbrica, etc.) y los guardias u otro personal de seguridad que evi
tan el ingreso de intrusos indeseables.
El inyector, que transporta la materia-energa a travs de ia frontera dei

sistema desde el medio ambiente. En una organizacin de negocios, ste
pudiera ser el departamento de compras o recepcin, que introduce la
materia prima, los materiales de oficina, etc. o pudiera ser el departa
mento de pedidos, que recibe pedidos verbales o por escrito de los servi
cios o productos de la organizacin.
El distribuidor, que trae material desde el exterior del sistema y lo reparte

desde sus subsistemas a cada componente. En una organizacin de ne
gocios, pudiera esta r conform ado por las lneas telefnicas, correo
electrnico, mensajeros, bandas y una variedad de otros mecanismos.
www.FreeLibros.org
El convertidor, que cambia ciertos materiales que ingresan al sistema a

formas mas tiles para los procesos especiales de dicho sistema particu
lar. Nuevamente, se puede imaginar un buen nmero de ejemplos de es
to en una organizacin de negocios tpica.
El productor, que forma asociaciones estables durables por periodos sig
nificativos con la materia-energa que ingresa al sistema o que egresa de
su convertidor. Estos materiales sintetizados pueden servir para creci
miento, reparacin de daos o reposicin de componentes del sistema, o
bien para proveer energa para mover o constituir los productos o la infor
macin de mercado a su suprasistema.
Ei subsistema de almacenamiento de materia-energa, que retiene en el
sistema, durante diferentes periodos, depsitos de diversos tipos de ma
teria-energa.
El expulsor, que transmite materia-energa hacia el exterior del sistema
en forma de desechos o de productos.
El motor, que mueve ei sistema o a sus partes en relacin con todo o parte
del medio ambiente, o bien que mueve a ios componentes del ambiente.
El soporte, que mantiene las relaciones espaciales apropiadas entre los
componentes del sistema, de manera que puedan interactuar sin ser un
lastre o estorbo entre ellos.
El transductor de entrada, que trae seales portadoras de informacin al
sistema, transformndolas en otras formas de materia- energa adecua
das para su transmisin al interior.
El transductor interno, que recibe de otros subsistemas o componentes
del sistema seales que portan informacin acerca de alteraciones signifi
cativas en dichos subsistemas o componentes, transformndolos en otras
formas de materia-energa transmisibles en su interior.
El canal y la red, que estn compuestos por una sola ruta en el espacio f
sico, o bien por mltiples rutas interconectadas, mediante ias cuales ias
seales portadoras de informacin se transmiten a todas las partes del
sistema.
El decodifcador, que altera las claves de informacin que le es introducida
por medio del transductor de entrada o del transductor interno, para dejar
una clave privada que pueda ser utilizada internamente por el sistema.
El asociador, que lleva a cabo la primera etapa del proceso de aprendiza
je, formando asociaciones duraderas entre elementos de informacin den
tro del sistema.
www.FreeLibros.org
La memoria, que lleva a cabo la segunda etapa del proceso de aprendiza

je, almacenando diversos tipos de informacin en el sistema durante dife
rentes periodos.
El que decide, que recibe informacin de todos ios dems subsistemas y

les transmite informacin que sirve para controlar al sistema completo.
El codificador, que altera la clave de informacin que se le introduce des

de otros subsistemas procesadores de informacin, convirtindola, de una
clave privada utilizada internamente por el sistema, en una clave pblica
que puede ser interpretada por otros sistemas en su medio ambiente.
El transductor de salida, que emite seales portadoras de informacin

desde el sistema, transformando los marcadores dentro del sistema en
otras formas de materia-energa que pueden ser transmitidas por medio
de canales en el medio ambiente del sistema.
Las figuras 2.1 (a) y 2.1 (b) muestran un ejemplo de los 19 principales subsis
temas de un equipo de comunicaciones en un crucero transocenico moderno; las fi
guras 2.2 (a) y 2.2 (b) muestran los principales subsistemas del crucero mismo; y las
figuras 2.3 (a) y 2.3 (b) muestran los principales subsistemas de toda Holanda. Vale
la pena estudiarlos, pues ilustran el hecho de que si se observa cualquier sistema
que tiene componentes vivientes, es posible localizar los principales subsistemas.
Tenga en mente que muchos sistemas hechos por el hombre {y sistemas auto
matizados) nteractan con sistemas vivientes; por ejemplo, los marcapasos compu
terizados interactan con el corazn humano. En algunos casos, se disean
sistemas automatizados para reemplazar a sistemas vivos; y en otros, los investiga
dores consideran a los sistemas vivos (conocidos como computadoras orgnicas)
como componentes de sistemas automatizados. Vanse [Hall, 1983], [DeYoung,
1983], [Shrady, 1985] y [Olmos, 1984] para anlisis de este punto de vista. Los sis
temas vivientes y los sistemas hechos por el hombre a menudo forman parte de un
metasistema mayor, y entre mas entendamos acerca de ambos, mejores analistas
de sistemas seremos.
2.3
SISTEMAS HECHOS POR EL HOMBRE
Como pudimos apreciar de a definicin que se encuentra al comienzo de este

captulo, un buen nmero de sistemas son construidos, organizados y mantenidos
por humanos, e Incluyen:
Sistemas sociales: organizaciones de leyes, doctrinas, costumbres, etc

tera.
Una coleccin organizada y disciplinada de ideas: el sistema decimal Dewey de organizacin de libros en bibliotecas, el sistema de reduccin de
los cuida-kilos, etctera.
www.FreeLibros.org
Sistemas de transporte: redes de carreteras, canales, aerolneas, buques

cargueros, etctera.
Sistemas de comunicacin: telfono, tlex, seales de humo, seales de

mano utilizadas por los corredores de bolsa, etctera.
Sistemas de manufactura: fbricas, lneas de ensamblado, etctera.
Sistemas financieros: contabilidad, inventarios, libro mayor, bolsa de valo

res etctera.
En la actualidad, la mayora de estos sistemas incluyen las computadoras; de

hecho, muchos no podran sobrevivir sin ellas. Sin embargo, es igualmente impor
tante sealar que dichos sistemas existan antes de que hubiera computadoras; de
hecho, algunos sistemas continan por completo sin computarizar y podran perma
necer as durante muchas dcadas ms. Otros contienen a la computadora como
componente, pero tambin incluyen uno o ms componentes no computarizados (o
manuales).
Considrese, por ejemplo, la frase comn, Juan tiene un sistema para llevar
a cabo su trabajo o Vaya que Mara tiene una manera sistemtica de hacer su tra
bajo. Tales frases no necesariamente sugieren que Mara ha computarizado su
trabajo o que Juan ha utilizado algunos de los instrumentos formales de modelacin
discutidos en los captulos 9 y 10 para documentar (o modelar) cmo propone hacer
su trabajo. Pero ciertamente las frases implican que Juan y Mara han dividido su
trabajo en una serie de pasos definidos, la suma acumulativa de los cuales lograr
algn propsito general.
El que un sistema de factura humana deba o no ser computarizado es una
cuestin que discutiremos a lo largo de este libro; no es algo que se daba dar por
hecho. Como analista de sistemas, usted naturalmente supondr que todo sistema
con el que se encuentre deber computarizarse, y el cliente o usuario (el dueo del
sistema en cuestin) con quien usted interacta generalmente supondr tal predis
posicin. Como veremos en captulos posteriores, su labor primaria como analista
de sistemas ser analizar o estudiar el sistema para determinar su esencia: su com
portamiento requerido, independientemente de la tecnologa utilizada para implantar
el sistema4. En la mayora de los casos, podremos determinar si tiene sentido utili
zar una computadora para llevar a cabo las funciones del sistema slo tras haber
modelado su comportamiento esencial.
Por qu no debieran automatizarse algunos sistemas de procesamiento de
informacin? Puede haber muchas razones; he aqu algunas de las ms comunes:
Costo. Puede ser ms barato continuar llevando a cabo las funciones y

almacenando la informacin del sistema en forma manual. No siempre es
www.FreeLibros.org
4 Se d iscutirn los m odelos esenciales y a esencia de un sistem a en el ca p tulo 17.
cierto que las computadoras sean ms rpidas y econmicas que el mto

do anticuado.
Conveniencia. Un sistema automatizado puede ocupar demasiado espa

cio. hacer demasiado ruido, generar demasiado calor o consumir dema
siada electricidad, o bien, en general, ser una molestia. Esto va dejando
de ser as con la creciente influencia de los microprocesadores, pero si
gue siendo un factor a considerar.
Seguridad. Si el sistema de informacin mantiene datos confidenciales,

el usuario pudiera no creer que el sistema automatizado sea lo suficiente
mente seguro; tal vez desee mantener la informacin fsicamente protegi
da y bajo llave.
Facilidad de mantenimiento. El usuario pudiera argumentar que un siste

ma de informacin computarizada sera costeabie, excepto por el hecho
de que no hay ningn miembro del personal que pudiera encargarse del
mantenimiento del hardware y o el software de la computadora, de mane
ra que nadie podra reparar el sistema si ste sufriera un desperfecto, ni
habra quien pudiera efectuar cambios o mejoras.
Polticas. La comunidad usuaria pudiera recelar que las computadoras

amenazan con privarla de sus empleos o con volver aburridos o mecni
cos sus trabajos o con una docena de otras razones que el analista de
sistemas podra considerar irracionales. Pero dado que se trata del siste
ma del usuario, sus recelos son de primera importancia. Si no desean te
ner un sistema automatizado, harn todo lo posible por lograr que falle si
se les quiere imponer.
2.4 SISTEMAS AUTOMATIZADOS

La mayor parte de este libro se concentrar en los sistemas automatizados, es
decir, en sistemas hechos por el hombre que interactan con o son controlados por
una o ms computadoras. Sin duda, usted ha visto muchos ejemplos diferentes de
sistemas automatizados en su vida cotidiana: parece ser que casi cada aspecto de
nuestra sociedad moderna est computarizado. Como resultado, podemos distinguir
muchos tipos diferentes de sistemas automatizados.
Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener
componentes en comn.
El hardware de la computadora: los procesadores, los discos, terminales,

impresoras, unidades de cinta magntica, etctera.
www.FreeLibros.org
El software de la computador^: los programas de sistemas tales como sis

temas operativos, sistemas de bases de datos programas de control de
Subsistemas que procesan tanto materia-energa como informacin:

frontera de a bordo (Bo), la pared del cuarto de radio (artefacto).
Subsistemas que procesan la materia-energa: Ei ingestor (IN), a camarera
que trae comida ai cuarto de radio desde la cocina del barco; el distribuidor (DI),
el camarero que reparte la comida a los miembros del equipo de comunicaciones;
| el convertidor (CO), el camarero que parte ei pan y corta la carne y el queso para
los sandwiches; el productor (PR), el camarero que hace los sandwiches y el ca| f; el almacenista de materia-energa (MS), ei camarero que almacena diversos
tipos de artefactos, incluyendo alimentos en ei refrigerador, sacos y gorras de ios
miembros del equipo en el clset, mantas y almohadas en el armario y
herramientas y equipo en una gaveta; el expulsor (EX), el camarero que se lleva
los utensilios usados, la basura y otros desechos del cuarto de radio; el soporte o
sustentador (SU), el piso, ias paredes, ei techo, y los muebles del cuarto de radio
| (artefactos).
|
Subsistemas que procesan informacin; el transductor de entrada o
| introductor (t), el operador de radio que recibe los mensajes; el transductor inter| no (in), el capataz de turno que informa al oficial de seales en jefe sobre la
eficiencia y nimo de los miembros del equipo en su turno; el canal y la red (en),
todos los miembros del grupo que se intercomunican por medio del habla que se
transmite a travs del aire del cuarto de radio; ei decodificador (de), ei operador
j de radio que transcribe a la lengua propia los mensajes recibidos en clave Morse;
la memoria (me), la secretaria que lleva el registro de todos los mensajes
f recibidos y transmitidos; el decididor (de), el oficial de seales en jefe, que dirige
) al equipo de comunicaciones; ei codificador en Morse (en), el operador de radio
| que codifica de la lengua propia al cdigo Morse los mensajes; el transductor de
| salida (ot), el operador de radio que transmite los mensajes por esta va.
|
j
j
figura 2.1 (a): Subsistem as de un equipo de com unicaciones de un crucero

telecomunicaciones, adems de ios programas de aplicacin que llevan a
cabo las funciones deseadas por el usuario.
Las personas: los que operan el sistema, los que proveen su material de
entrada y consumen su material de salida, y los que proveen actividades
de procesamiento manual en un sistema.
Los datos: la informacin que el sistema recuerda durante un periodo.
Los procedimientos: las polticas formales e instrucciones de operacin

del sistema.
www.FreeLibros.org
Una manera de ordenar por categoras los sistemas automatizados es por su
aplicacin: sistemas de manufactura, sistemas de contabilidad, sistemas de defensa
Figura 2 .1(b): Subsistem as de un equipo de com unicaciones de un crucero
militar, etc. Sin embargo, esto no resulta muy til, pues las tcnicas que discutire
mos en este libro para analizar, modelar, disear e implantar sistemas automatiza
dos generalmente son las mismas, independientemente de su aplicacin.5
5 Sin em bargo, cada aplicacin tiene su vocabulario, cu ltu ra y procedim ientos propios. El usuario
por io general espera que ei a n a lista de siste m a s sepa algo acerca de los de talle s, poltica y proce
d im ie nto s de la aplicacin, para no te n er que e xp lica rle todo desde el principio. P or lo tanto, si va a
d e sem pear el trab a jo de a n a lista de siste m a s en un banco, probablem ente le sea til a p render
cuanto pueda acerca de ia banca. No es cam ino de un solo sentido: los banqueros aprenden cada
d a m s acerca de la te cn olog a de ios sistem as de inform acin.
www.FreeLibros.org
Subsistemas que procesan tanto materia-energa como informacin: el

reproductor (Re), los representantes de la corporacin propietaria; la frontera de
a bordo (Bo), el casco del barco y el personal que lo protege y le da
mantenimiento.
I
p
Subsistemas que procesan la materia-energa: el ingestor (IN), la escotilla
|j que conduce a la bodega del barco y el personal que ayuda a los pasajeros, a
I: -H-,rcjar y qUe estiba el equipaje y el cargamento a bordo del barco; el distribuidor
i >, los pasillos, puentes y escaleras, y los camareros, meseros y mozos que
an alimentos, bebidas, equipaje y otros diversos tipos de materia-energa por
cienos pasillos, adems de los pasajeros que por ellos se desplazan de un lado
a otro del barco; el convertidor (CO), el personal de la galera que limpia las
verduras y prepara otros comestibles para cocinarlos; el productor (PR), los que
cocinan la comida y los panaderos que laboran en la galera del barco; el
aimacenador de materia-energa (MS), la bodega del barco y los tanques de
combustible, y el personal responsable de ellos; el expulsor (EX), la chimenea
para desechos gaseosos, salidas para la basura y drenaje para los desechos
lquidos y slidos, y el personal de operaciones responsable de asegurar que los
desechos sean eliminados adecuadamente; el motor (MO), los motores del barco,
su timn, hlices y todo e! casco del barco, que mueven pasajeros, tripulacin y
cargamento a travs del mar, junto con los ingenieros responsables de lograr es
te movimiento; el soporte (SU), el casco, los flancos, las paredes y los puentes
del barco, y el personal que los mantiene.
Subsistemas que procesan la informacin: el transductor de entrada (in), el
operador de radio y otros miembros del equipo de comunicaciones que reciben
mensajes para el barco; el transductor interno (in), el oficial que informa al oficial
de mando sobre el estado de los diversos componentes que forman el barco; el
canal y la red (en), el aire que rodea a los oficiales en el puente, a travs del cual
transmiten y reciben mensajes; el decodificador (de), el operador de radio en el
equipo de comunicaciones que descifra los mensajes en clave Morsa, dejndolos
en lengua propia despus de ser recibidos; la memoria (me), los cuadernos de
| bitcora de travesas pasadas, mapas martimos y el personal que los consulta en
el cuarto de mapas; el decididor (de), el capitn y otros oficiales de a bordo; el
codificador en clave Morse (en), el operador de radio del equipo de
comunicaciones que traduce los mensajes de la lengua propia al cdigo Morse
para su transmisin; el transductor de salida (ot), el operador de radio y otros
miembros del equipo de comunicaciones que transmiten mensajes desde el
barco.
Figura 2.2(a): P rincipales subsistem as de un crucero
www.FreeLibros.org
' ***
g 1**
Figura 2.2(b): P rincipales subsistem as de un crucero
www.FreeLibros.org
Figura 2.3(a): P rincipales subsistem as de Holanda
www.FreeLibros.org
L o s s u b s is te m a s q u e p ro c e s a n ta n to ia m a te ria -e n e rg a c o m o ia in fo rm a c i n ; L a fro n te ra
- ias o rg a n iz a c io n e s que
d e fie n d e n , c u id a n o im p o n e n ia ley en ia fro n te ra n a c io n a l.
L o s s u b s is te m a s q u e p ro c e s a n la m a te ria -e n e rg a ; Ei in g e s to r
f *
o rg a n iz a c io n e s co m o las a e ro ln e a s , e l fe rro c a rril, las
c o m p a a s d e tra n s p o r te te rr e s tre d e c a rg a y las d e tra n s p o rte m a rtim o , q u e im p o rta n d iv e rs a s fo rm a s d e m a te ria -e n e rg a a! in te rio r
, la s o rg a n iz a c io n e s n a c io n a le s q u e tra n s p o rta n d iv e rs a s fo rm a s d e m a te ria -e n e rg a p o r m ar,
de! p as; e l d is trib u id o r
, la s o rg a n iz a c io n e s q u e c o n v ie rte n las fo rm a s p rim a s d e m a te ria -
tie rr a , fe rro c a rr il o p o r v a a re a ; el c o n v e rtid o r
las o rg a n iz a c io n e s q u e fa b ric a n p ro d u c to s p a r a el
e n e rg a a fo rm a s q u e p u e d e u tiliz a r ia s o c ie d a d ; ei p ro d u c to r
, o rg a n iz a c io n e s ta le s co m o b o d eg a s.
co n s u m o d e la s o c ie d a d o p a ra e x p o r ta r; El a m a c e n a d o r d e m a te ria -e n e rg a
tas o rg a n iz a c io n e s que
p re s a s y p la n ta s e l c tric a s q u e a lm a c e n a n d iv e rs o s tip o s d e m a te ria - e n e rg a ; e! e x p u ls o r
e x p o rta n los p ro d u c to s h o la n d e se s a o tro s p a s e s , o q u e d e s c a rg a n d e s e c h o s en e m ar. y la s a g e n c ia s q u e d e p o rta n a la s p e rs o n a s
, las u n id a d e s d e tra n s p o rte , la in d u s tria d e la c o n s tru c c i n , las fu e rz a s a rm a d a s o ia ag e n c ia
in d e s e a b le s ; e m o to r
e sp a c ia !; e s o p o rte
, ios e d ific io s p b lic o s y ia tierra.
L o s s u b s is te m a s q u e p ro c e s a n ia in fo rm a c i n ; es ra n s d u c to r d e en tra d a
, la s o rg a n iz a c io n e s q u e re c ib e n s e a le s de
te l g ra fo , c a b le , te l f o n o o ra d a r, o b ien n o tic ia s e x tra n je ra s q u e v ie n e n d e ritas a i de las fro n te ra s h o la n d e sa s ; el tra n s d u c to r
in te rn o
~*BSL j
. ia le g is la tu ra , io s d irig e n te s d e p a rtid o s p o ltic o s y las o rg a n iz a c io n e s d e e n c u e s ta p b lic a q u e r e c ib a
in fo rm e s y c o m u n ic a c i n de to d o ei p a s ; ei c a n al y las re d es
d c c o d ific a d o r,
|u
|j
, ios sis te m a s d e c o m u n ic a c io n e s n a c io n a le s ;
ia o fic in a d e re la c io n e s e x te rio re s q u e d e e o d i e a lo s m e n s a je s s e c re to s re c ib id o s por las e m b a ja d a s de
H o la n d a e n to d o el m u n d o ; ei a s o c ia d o r
d M io ie c a s ; el q u e d e c id e
_ jas ;n s ttild o n e s e d u c a tiv a s h o la n d e sa s ; la m e m o ria
. ia re in a y su G o b ie r n o en L a H a y a; ei c o d ific a d o r
g u b e rn a m e n ta l h o la n d s o los a u to re s d e d is c u rs o s ; el tra n s d u c to r d e salid a
las
) , ei S e c re ta rio d e P ren sa
as p e rs o n a s q u e dan ios co m u n ic a d o s
www.FreeLibros.org
o fic a le s d e H o lan d a .
Figura 2.3(b): Principales subsistem as de Holanda
Una divisin en categoras ms til de ios sistemas automatizados es la si

guiente:
Sistemas en lnea
Sistemas de tiempo real
Sistemas de apoyo a decisiones
Sistemas basados en el conocimiento
Examinaremos con cuidado cada uno de stos.

2.4.1 Sistem as en lnea
En un libro anterior [Yourdon, 1972], defin los sistemas en lnea de la siguien
te forma:
Un sistem a en lnea es aquel que acepta m aterial de e n trada d irec
tam ente del
rea donde se cre. Tam bin es ei sistem a en el que ei
m aterial de salida, o el resultado de la com putacin, se devuelve d i
rectam ente a donde es requerido.
Esto usualmente significa que el sistema computacional tiene una arquitectura de

hardware parecida a la de la figura 2.4.
Una caracterstica comn de los sistemas en lnea esqueentran
datos a la
computadora o se les recibe de ella en forma remota. Esdecir, losusuarios del sis
tema computacional normalmente interactan con la computadora desde terminales6
que pueden estar localizadas a cientos de kilmetros de la computadora misma.
Otra caracterstica de un sistema en lnea es que los datos almacenados, es
decir, sus archivos o su base de datos, usualmente se organizan de tal manera que
los componentes individuales de informacin (tales como un registro individual de re
servacin area o un expediente individual de personal) puedan ser recuperadas mo
dificados o ambas cosas 1) rpidamente y 2) sin tener necesariamente que efectuar
accesos a otros componentes de informacin del sistema. Esto contrasta enorme
mente con los sistemas fuera de lnea o en lotes (batcli), que eran ms comunes en
las dcadas de los aos 60 y 70. En un sistema computacional por lotes, la informa
cin suele recuperarse de una manera secuencial, lo cual significa que el sistema
computacional lee todos los registros de la base de datos, procesando y actualizando
aquellos para los cuales haya actividad. La diferencia entre un sistema computacio6 A ctualm ente, la palabra term ina! se usa de m anera tan com n en la sociedad que en realidad no
requiere definirse. Sin em bargo, entrese de que hay m uchos sinnim os: panta lla , estacin de
trabajo", te cla d o , etc. A dem s, hay ab re via tu ras com unes (en ei ingls de uso habitual en infor
m tica) para de scrib ir la unidad de e n tra d a /sa lid a que se em plea para co m unicarse con la com puta
dora, com o C R T para d e scrib ir el tubo de rayos ca t d ico s , VD U para ia unidad de exhibicin
visual , etc. Estos trm inos se utilizarn in d istin ta m e n te a io largo d e l libro.
www.FreeLibros.org
nal por lotes y uno en lnea es anloga a ia diferencia entre encontrar una seleccin
musical especfica en un cassette o en un disco; lo primero involucra el acceso se
cuencia! a travs de todas las pistas, mientras que lo segundo permite el acceso
aleatorio a cualquiera de las pistas sin tener que escuchar las dems.
Dado que un sistema en lnea interacta directamente con personas (por ejem
plo, usuarios humanos en sus terminales), es importante que el analista de sistemas
planee cuidadosamente la interfaz humano-computadora.7 Es decir, el analista debe
tener alguna manera de modelar, esto, es, de crear modelos de todos los posibles
mensajes que el usuario humano puede teclear en su terminal, y de todas las res
puestas que el sistema pudiera dar, adems de todas las respuestas que pudiera dar
el humano ante las respuestas de la computadora, etc. Esto usualmente se lleva a
cabo identificando todos los estados en los que la computadora y el usuario pudieran
encontrarse, e identificando todos los cambios de estado. Un ejemplo de un estado
en el que pudiera encontrarse una computadora de un sistema de cajero bancario
automtico es el usuario ha insertado su tarjeta y se ha identificado, pero an no
La inform acin se te cle a desde el lugar de origen
Figura 2.4: Un sistem a en lnea
www.FreeLibros.org
7 A m enudo se hace referencia a esto com o d ilogo hom bre-m quina , o interfaz ho m b re -m q u i
na . C ada vez son ms las o rg a nizaciones de d e sarrollo de sistem as que utilizan la expresin in te r
faz hum a n o -com p u ta do ra o, sim plem ente, interfaz hum ana para evitar las inferencias sexistas.
me ha dado su clave secreta. Un ejemplo de cambio de estado es me ha dado su

clave secreta y ahora puedo proceder a determinar si desea retirar efectivo o desea
que le informe acerca de su estado de cuenta. Otro cambio de estado pudiera ser
ha tratado sin xito de ingresar su clave tres veces y ahora voy a hacer sonar la
alarma. Estos estados y cambios de estado se modelan tpicamente con diagramas
de transicin de estado, que discutiremos con detalle en el captulo 13.
Dado que los sistemas en lnea por lo comn requieren recuperar datos con
rapidez (para poder responder a preguntas y rdenes provenientes de terminales en
lnea), suele ser muy importante disear los archivos y las bases de datos de la ma
nera ms eficiente posible. De hecho, a menudo las operaciones de computacin
llevadas a cabo por un sistema en lnea suelen ser relativamente triviales, mientras
que los datos (sobre todo, la estructura y organizacin de los datos mantenida por el
sistema en lnea) suelen ser bastante complejos. De aqu que las herramientas de
modelado de datos discutidas en el captulo 12 sean de gran importancia para el
analista y para el diseador de sistemas.
La decisin de convertir o no un sistema ordinario en un sistema enlnea es,
en el contexto de este libro, una decisin de puesta en prctica, es decir, no es algo
que debiera ser determinado por el analista de sistemas sino ms bien por las perso
nas que ponen en prctica el sistema. Sin embargo, dado que decidir tal cosa tiene
un impacto tan obvio en el usuario (la presencia o ausencia de termnales de compu
tadora, etc ), es una decisin de puesta en prctica en la cual habitualmente los
usuarios querrn participar. De hecho, es parte del modelo de puesta en prctica
del usuario que discutiremos en el captulo 21.
2.4.2
Sistem as de tiem po real
Un sistema de tiempo real es considerado por muchos como una variante de

un sistema en lnea; de hecho, muchos usan ambos trminos indistintamente. Sin
embargo, es importante distinguirlos: utilizaremos ia siguiente definicin de [Martn,
1967]:
Un s is te m a c o m p u ta cio n a l de tie m p o rea i p u ede d e fin irs e com o
aquel que co n tro la un am biente recibiendo datos, p rocesndolos y
d e vo lvindolos con la su ficie n te rapidez com o para in flu ir en dicho
am biente en ese m om ento.
La expresin con la suficiente rapidez est, desde luego, sujeta a muchas in

terpretaciones. Ciertamente, existen muchos sistemas en lnea (sistemas banearios,
de reservaciones areas y sistemas de bolsa) que se espera reaccionen en uno o
dos segundos a un mensaje tecleado en la terminal. Sin embargo, en la mayora de
los sistemas de tiempo real, la computadora debe de reaccionar en miiisegundos y a
veces en microsegundos a los estmulos que recibe. Esto es caracterstico de los si
guientes tipos de sistemas:
www.FreeLibros.org
Sistemas de control de procesos: los sistemas computacionales que se

utilizan para verificar y controlar refineras, procesos qumicos, molinos y
operaciones de maquinado.
Sistemas de cajeros automticos: ias mquinas de efectivo que muchos

de nosotros usamos para hacer depsitos y retiros sencillos en el banco.
Sistemas de alta velocidad para adquisicin de datos: los sistemas com

putacionales que obtienen datos de telemetra a alta velocidad de satli
tes en rbita o ias computadoras que capturan cantidades enormes de
datos de experimentos de laboratorio,
Sistemas de gua de proyectiles: ios sistemas computacionales que de

ben rastrear la trayectoria de un proyectil y hacer ajustes continuos a la
orientacin y empuje de los propulsores.
Sistemas de conmutacin telefnica: sistemas computacionales que con

trolan la transmisin de voz y datos en miles de llamadas telefnicas, de
tectando los nmeros marcados, condiciones de ocupado y todas ias
dems condiciones de una red telefnica tpica.
Sistemas de vigilancia de pacientes: sistemas computacionales que de

tectan los signos vitales de diversos pacientes (por ejemplo, temperatu
ra y pulso) y que son capaces ya sea de a ju sta r el m edicam ento
administrado o de hacer sonar la alarma si los signos vitales se mantie
nen fuera de ciertos lmites predeterminados.
Adems de la velocidad, existe otra caracterstica que diferencia a los siste

mas de tiempo real de los sistemas en lnea: estos ltimos suelen interactuar con ias
personas, mientras que los sistemas de tiempo real usualmente nteractan tanto
con personas como con un ambiente que en generalmente es autnomo y a menudo
hostil. De hecho, ia principal preocupacin del analista de sistemas en tiempo real
es que, si la computadora no responde con la suficiente rapidez, el ambiente pudiera
quedar fuera de control, ios datos de entrada pudieran perderse sin remedio o un
proyectil pudiera salirse de su trayectoria tanto que ya no fuera posible recuperarlo,
o bien que un proceso de manufactura pudiera explotar8. En cambio, un sistema en
lnea que no responda con la suficientemente rapidez en general no har ms que
volver impacientes y gruones a sus usuarios. Si tienen que esperar ms de tres se
gundos la respuesta de un sistema en lnea, las personas pueden explotar en sen
tido figurado, pero no en sentido literal. Esto se ilustra en la figura 2.5.
8 Uno de ios ejem plos m s interesantes de una situacin de tiem po real es ei de un equipo de tra
bajo cuya m isin era unir una pequea com p u ta d o ra a una bom ba nuclear. C uando se detonara ia
bom ba (com o parte de un program a de pruebas), ia com putadora disp o n dra tan slo de unos cuan
tos m icrosegundos para ca p tura r ta n tos datos com o fuera posible y tra n sm itirlo s a un sistem a de
com putadoras rem oto, antes de que se d e sintegraran el hardw are y softw are p o r ia explosin. Esa
s que es una reai exigencia dei procesam iento en tiem po real.
www.FreeLibros.org
Paso del tiempo

Figura 2.5: Un sistem a de tiem po real
Dada la preocupacin con la respuesta instantnea a las entradas del sistema,
un analista que trabaja en sistemas de tiempo real generalmente estar muy preocu
pado por el comportamiento dependiente del tiempo que el sistema tenga. Discutire
mos las herramientas para el modelado del comportamiento dependiente del tiempo
en el captulo 13.
Desde un punto de vista de su puesta en prctica, los sistemas de tiempo real
(as como algunos sistemas en lnea) se caracterizan por lo siguiente:
Simultneamente se lleva a cabo el proceso de mjjchas actividades.
Se asignan prioridades diferentes a diferentes procesos: algunos requie

ren servicio inmediato mientras que otros pueden aplazarse por periodos
razonables.
Se interrumpe una tarea antes de concluirla, para comenzar otra de ma

yor prioridad.
Existe gran comunicacin entre tareas, especialmente dado que muchas

tratan diferentes aspectos de un proceso general, como el control de un
proceso de manufactura.
Existe acceso simultneo a datos comunes, tanto en memoria como en el

almacenamiento secundario, por lo cual se requiere de un elaborado pro
ceso de sincronizacin y semforos para asegurar que los datos comu
nes no se corrompan.
www.FreeLibros.org
2.4.3
Existe un uso y asignacin dinmicos de memoria RAM en el sistema

computacional, dado que a menudo resulta poco econmico (aun cuando
la memoria sea barata) asignar suficiente memoria fija para manejar si
tuaciones pico de alto volumen.
Sistem as de apoyo a decisione s y sistem as de planeacin estratgica
La mayor parte de los sistemas automatizados de informacin que se crearon

en los Estados Unidos durante los ltimos 30 aos son sistemas operacionales que
ayudan a llevar a cabo los detalles del trabajo cotidiano de una organizacin. Estos
sistemas, que tambin se conocen como sistemas de procesamiento de transaccio
nes, incluyen ejemplos tan familiares como os sistemas de nmina, de contabilidad
y de manufactura. En muchas organizaciones, en todo Estados Unidos, estos siste
mas operacionales se han creado lenta, penosamente y a alto costo. Dado que mu
chos de ellos se iniciaron hace ms de 20 aos, estn al borde del colapso. De aqu
que continuamente se estn creando nuevos sistemas operacionales en las principa
les organizaciones del mundo entero.
Sin embargo, dado que los sistemas operacionales actuales continan tamba
lendose, muchas organizaciones se estn enfocando su atencin a un nuevo tipo
de sistemas: ios de apoyo a la toma de decisiones. Como lo implica el trmino, es
tos sistemas computaconales no toman decisiones por s mismos, sino ayudan a los
administradores y a otros profesionistas trabajadores del conocimiento de una or
ganizacin a tomar decisiones inteligentes y documentadas acerca de los diversos
aspectos de ia operacin. Tpicamente, los sistemas de apoyo a decisiones son pasiv-s =r el sentido de que no operan en forma regular: ms bien, se utilizan de ma
ne a ed hoc, cuando se les necesita,
u*
Ea ste un gran nmero de ejemplos sencillos de sistemas de apoyo a decisio
nes: programas de hoja de clculo (por ejemplo, Lotus 1-2-3, Multiplan de Microsoft,
Framework de Ashton Tate). sistemas de anlisis estadstico, programas de prons
tico de mercados, etc. De hecho, una caracterstica comn de los sistemas de apo
yo a decisiones es que no slo recuperan y exhiben los datos, sino que tambin
realizan varios tipos de anlisis matemticos y estadsticos de ios mismos. Los sis
temas de apoyo a decisiones tambin tienen la capacidad, en ia mayora de los ca
sos, de presentar ia inform acin en una variedad de form as grficas (tablas,
grficos, etc.) ai igual que en forma de reportes (informes) convencionales. En la fi
gura 2.6 se muestra una hoja de clcuio financiera caracterstica que pudiera utilizar
un gerente para evaluar las ganancias de alguna divisin dentro de su organizacin;
la figura 2.7 es una grfica tpica que presenta las ganancias ci dicha divisin com
paradas con ei promedio de la industria. Ntese que en ambos casos ia informacin
de salida producida por el sistema no toma una decisin, sino que provee informa
cin relevante para que el gerente pueda decidir.
www.FreeLibros.org
Algunos sistemas de apoyo a decisiones son tiles para articular y mecanizar
las reglas utilizadas para llegar a alguna decisin de negocios. Uno de estos siste
mas es un programa llamado Lightyear (de Lightyear, Inc.), que se ejecuta en com
putadoras personales compatibles con IBM. Permite ai usuario (o a mltiples usua
rios) describir los detalles de un problema que requiera decisiones; un ejemplo
podra ser el problema de decidir en dnde ubicar una nueva oficina. Primeramente,
el usuario identifica los criterios que se utilizarn para tomar la decisin. Para el
problema de ubicar una nueva oficina esto pudiera incluir, por ejemplo, que debe
ser accesible en transporte pblico y que no debe estar en una zona de alta proba
bilidad ssmica. Algunos de los criterios son binarios, en el sentido de que si no se
satisface uno de ellos, se elimina una alternativa o se ocasiona la seleccin autom
tica de otra. Algunos de los criterios pueden clasificarse en una escala numrica;
por ejemplo, uno de los criterios pudiera ser la tasa de impuestos corporativos, los
cuales tomarn diferentes valores numricos dependiendo de la ciudad y estado
donde se ubique la nueva oficina. Y los criterios mismos pueden clasificarse entre
s: pudiera ser que la importancia de los impuestos sea de 5 puntos en una escala
de 10, mientras que la conveniencia de tener algn centro comercial cercano pudiera
valer 3. Habiendo definido los criterios para llevar a cabo una decisin, las diversas
alternativas pueden ser evaluadas y analizadas; la mejor alternativa automticamen
te ser seleccionada por el programa Lightyear. La figura 2.8 ilustra este proceso.
No hay nada mgico en esto; el programa meramente aplica en una forma me
cnica las reglas de evaluacin provistas por el usuario. Pero el poder del sistema
va ms all del simple clculo mecnico: fuerza al usuario a articular su propio crite
rio, lo cual a menudo no se hace. Tambin ofrece una posibilidad neutral de obtener
las opiniones de varios usuarios en situaciones en las que es de importancia lograr
un consenso. En un asunto emocionalmente delicado, como reubicar una oficina
(por ejemplo, reubicar a las familias de quienes llevan a cabo la decisin), puede ser
ti no slo articular los criterios de decisin, sino tambin la clasificacin de criterios
hecha por cada persona que participa en la decisin. Si dos miembros del comit de
reubicacin de oficinas estn en desacuerdo, debiera quedarles claro por io menos
en qu se basa su desacuerdo.
Los sistemas de planeador! estratgica son utilizados por ios gerentes en jefe
para evaluar y analizar la misin de la organizacin. En lugar de dar consejos acer
ca. de alguna decisin de negocios aislada, estos sistemas ofrecen consejos ms
amplios y generales acerca de ia naturaleza del mercado, las preferencias de los
consumidores, el comportamiento de la competencia, etc. Esto usualmente cae den
tro de los dominios del Departamento de Pianeacin Estratgica o del Departamento
de Pianeacin a Largo Plazo, aunque pudiera tratarse de una actividad ms infor
mal, levada a cabo por uno o dos gerentes.
La pianeacin estratgica es un concepto que se hizo popular durante la Se
gunda guerra mundial (aunque algunas organizaciones obviamente la practicaron
desde mucho antes) y es tema de muchos libros; vase [Steiner, 1979], [Drucker,
1974] y [Ackoff, 1970], Los sistemas de pianeacin estratgica no son programas de
computadora en s; son complejas combinaciones de actividades y procedimientos,
www.FreeLibros.org
muchas de los cuales las llevan a cabo humanos utilizando informacin obtenida de
fuentes externas (estudios de mercado, etc.) y datos internos de los sistemas operacionales de la organizacin y los sistemas de apoyo a decisiones. Steiner seala
que hay muchos tipos de sistemas de planeacin estratgica, segn el tamao y na
turaleza de la organizacin.
Las figuras 2.9 y 2.10 muestran dos modelos tpicos. El sistema de planeacin
estratgica basada en el anlisis de brecha de posicin trata de identificar la discre
pancia entre la posicin actual de la organizacin (en trminos de ganancias, renta
bilidad, etc.) y la posicin deseada por la gerencia, los accionistas y otros.
Los sistemas de planeacin estratgica conforman por s solos un tema y no
se tratarn con detalle en este libro. Haremos nfasis primordialmente en los siste
mas de apoyo a decisiones y los sistemas operacionales.
Ntese la relacin existente entre los tres distintos tipos de sistemas que se
discuten en esta seccin. Como lo muestra la figura 2.11, los sistemas operaciona
les representan la base sobre ia cual se cimentan los sistemas de apoyo a decisio
nes y de planeacin estratgica. Los sistemas operacionales crean los datos
requeridos por los sistemas de nivel superior y continan actualizando los datos de
una manera continua.
roveccln de p rd idas y ganancias de la compaa
Venas nacionales
V entas internacionales
C uotas por licencias
Ingresos diversos
T O T A L DE ING RESO S
C1
400
100
25
10
535
C2
425
150
60
10
645
C3
250
200
50
15
515
C4
375
125
25
10
535
TO TAL
1450
575
160
45
2230
C osto de ventas
S alarios
O tros gastos de em pleo
Renta
Telfono
C orreos
V iaje s/d ive rsio ne s
C onta bilid ad /a su n to s legales
Depreciacin
G astos diversos
T O T A L DE G ASTO S
123
100
15
15
20
5
10
10
12
5
315
148
120
18
15
20
6
10
10
13
5
365
118
120
18
15
20
5
10
15
13
5
339
123
125
19
18
20
7
10
10
14
5
351
513
465
70
63
80
23
40
45
52
20
1371
G A N A N C IA S /P E R D ID A S
220
280
176
184
859
Figura 2.6: Reporte tabulado de una hoja de clculo tpica
www.FreeLibros.org
Ventas de mercancas
12
10
Ventas en
millones
80
81
82
83
84
f i j t V e n ta de m e rc a n c a s
cm e d io de la in d u s tria
85
Ao
Figura 2.7: Una grfica tpica hecha con un sistem a de apoyo a la tom a de
decisiones
La forma piramidal de la figura 2.11 representa otra caracterstica tpica de los
sistemas de informacin que se pueden encontrar en la mayora de las organizacio
nes hoy en da: el tamao de los sistemas operacionales (medidos en aos-persona,
o en millones de instrucciones de COBOL, etc.) excede por mucho al de los sistemas
de apoyo a la toma de decisiones y al de los sistemas de planeacin estratgica. Pe
ro podemos esperar que esto cambie gradualmente a lo largo de la siguiente dca
da. Como se mencion anteriormente, muchas organizaciones han pasado los
ltimos 30 aos construyendo sus sistemas operacionales: en gran medida, el traba
jo ya est hecho 9. La mayor parte de la labor que se lleva a cabo actualmente en
algunas de esas organizaciones importantes consiste en el desarrollo de sistemas
de apoyo a la toma de decisiones y de sistemas de planeacin estratgica.
9 Existen algunas excepciones: las o rg a n iza cio n e s m s p e queas an no han co m p u ta riza do la

mayor parte de sus o p eraciones diarias; los viejos siste m a s d e sa rro lla d os por las com paas Fortu
ne 500 en la dcada de los aos 60 estn al borde del colapso; los nuevos sistem as que se necesi
tan p a ra la s fu s io n e s de e m p re s a s , la s a d q u is ic io n e s y los e s tu d io s de m e rc a d o y n u e vo s
productos; adem s la com unidad de la defensa aparentem ente tiene una lista interm inable de nue
vos sistem as que se necesitan crear. Sin em bargo, la tendencia general es la de o lvid a r los siste
mas operacionales y dedicarse a ios sistem as de apoyo a las decisiones.
www.FreeLibros.org
2.4.4
Sistem as basados en ei conocim iento
Un trmino relativamente novedoso en la industria de las computadoras es el

de sistemas expertos o sistemas basados en el conocimiento. Dichos sistemas
se asocian con el campo de la inteligencia artificial, la cual Elaine Rlch defini de la
siguiente manera [Rch, 1984]:
La m eta de los cie n tfic o s de la c o m p u ta ci n que tra b a ja n en el
cam po de la inte lig e n cia a rtificia l es producir program as capaces de
im ita r el d esem peo hum ano en una gran variedad de tareas in te li
ge n te s . Para alg u n os sistem as expertos la m eta est prxim a a
se r alcanzada; para otros, aunque an no sabem os co n stru ir pro
gram as que funcionen bien por s solos, podem os com enzar a crear
program as capaces de a u xilia r a las personas en la ejecucin de al
guna tarea.
Figura 2.8: El sistem a Llghtyear de apoyo a la toma de decisiones
Dos eminentes autores en ei campo de a inteligencia artificia!, Feigenbaum y

McCorduck. describen los sistemas basados en ei conocimiento y ios sistemas ex
pertos [Feigenbaum y McCorduck, 1983] de la siguiente manera:
Los sistem as basados en el conocim iento, por d e cir lo obvio, co n tie
nen grandes cantidades de d iversos co n o cim ie n to s que em plean en
el desem peo de una tarea dada. Los sistem as expertos son una
especie de sistem a basado en el conocim iento, aunque am bos tr
m inos a m enucio se utilizan indistintam ente.
Qu es precisam ente un sistem a experto? Es un progra
m a de c o m p u ta d o ra que co n tie ne ei co n o cim ie n to y ia capacidad
necesarios para desem pearse en un nivel de experto. Ei desem
peo experto significa, por ejem plo, ei nivel de desem peo de mdi-
www.FreeLibros.org
Figura 2.9: Un m odelo de planeacin estratgica basado en el anlisis de

brecha de posici n
eos que llevan a cabo d ia gnsticos y procesos teraputicos, o de f

sicos u otras personas de gran exp e rie n cia que llevan a cabo tareas
de ingeniera, de adm inistracin o cie n tficas. Ei sistem a experto es
un apoyo de alto nivel intelectual para ei experto hum ano, lo cual
explica su otro nom bre, asistente in teligente.
Los siste m a s e xpertos por lo g e neral se co n stru ye n de tai
m anera que sean capaces de exp lica r las lneas de razonam iento
que llevaron a las decisiones que tom aron. A lgunos de ellos pue
den incluso explicar por qu descartaron cie rto s cam inos de razo
nam iento y por qu e sco g ie ro n otros. Esta tra n sp a re n cia es una
caracterstica prim ordial de los sistem as expertos. Los diseadores
trab a ja n a rd u a m e nte para lo g ra rla , pues co m p re n d en que ei uso
que se le dar ai sistem a experto depender de ia credibilidad de
que disfrute por parte de los usuarios, y la cred ib ilida d surgir debi
do a un com portam iento transparente y explicable.
An se piensa en los sistemas expertos como una especie de sistemas espe

cializados, que utilizan hardware especial y lenguajes especiales, como LISP y PRO
LOG. Sin embargo, han comenzado a aparecer sistemas expertos sencillos, para
computadoras personales estndar, y cascarones" de sistemas expertos, que son
estructuras de software para el desarrollo de aplicaciones especficas de sistemas
expertos, tambin sencillos, en ambientes basados en COBOL estndar.
www.FreeLibros.org
Figura 2,10: Un m odelo de planeacin estratgica basado en la fuerza del

mercado
Aunque los sistemas expertos van ms all de los alcances de este libro, gra
dualmente se convertirn en un componente cada vez ms importante de los siste
mas tpicos en los que trabaja un analista de sistemas. A fines de la dcada de los
80, los investigadores comenzaron a estudiar la relacin entre las tcnicas de desa
rrollo de software clsico y la inteligencia artificial; un estudio tpico es [Jacob y
Froscher, 1986]. Keller [Keller, 1987] prev un momento en el futuro cercano en el
www.FreeLibros.org
cual los sistemas de IA y los sistemas expertos formarn parte de la actividad nor
mal del anlisis de sistemas; otros, como [Barstow, 1987] y [Lubars y Harandi,
1987], prevn que la inteligencia artificial auxiliar a los analistas de sistemas en la
documentacin de los requerimientos del usuario para mediados de la dcada de los
90. Posteriormente se tratar este punto.
2.5
PRINCIPIOS DE SISTEMAS GENERALES
Todos los ejemplos expuestos tienen una cosa en comn: todos son sistemas.
Mientras que pueden diferir en varias cosas, tambin poseen muchas caractersticas
comunes. El estudio de dichas caractersticas comunes se conoce como teora ge
nera! de sistemas y es un tema fascinante de explorar. Para obtener un panorama
inicial del tema, vase [Weinberg, 1976]; para un panorama ms formal, consltese
[Bertalanffy, 1969], y para un panorama ms humorstico de la frecuentemente per
versa naturaleza de ios sistemas, vase la encantadora obra de Gall, Sysiemanics
[Gall, 1977].
Aunque el tema de la teora general de los sistemas va ms all de lo que
abarca este libro, existen algunos principios generales que son de inters particu
lar para quienes crean sistemas automatizados de informacin, e incluyen los si
guientes:
www.FreeLibros.org
1.
Entre ms especializado sea el sistema, menos capaz es de adaptarse a

circunstancias diferentes. Esto a menudo se utiliza para describir los sis
temas biolgicos (por ejemplo, los animales tienen dificultad para adap-
tarse a nuevos ambientes), pero se aplica tambin a los sistemas computacionales. Entre ms general sea un sistema, menos ptimo ser para
una situacin determinada; pero entre ms ptimo sea, para tal situacin
menos adaptable ser a nuevas circunstancias. Esto presenta un proble
ma para muchos sistemas de tiempo real, que tienen que ser optimiza
dos para poder p roveer respuestas suficientem en te rpidas a los
estmulos externos. Pero el proceso de optimizacin suele aprovechar
las idiosincrasias dei hardware especial de la computadora y del software
de sistemas utilizados en el proyecto, lo cual significa que pudiera ser
muy difcil transportar el sistema a un hardware distinto. El principio tam
bin es de importancia para muchos sistemas de negocios, los cuaies re
fle ja n la p o ltic a del usuario, que pudiera tam bin ser altam ente
especializada. Entre ms especializados sean ios requerimientos para un
sistema de nmina, por ejemplo, menos probable es que pueda utilizarse
un paquete comercial.
2
Cuanto mayor sea el sistema mayor es el nmero de sus recursos que

deben dedicarse a su mantenimiento diario. La biologa es, una vez ms,
el ejemplo ms familiar de este principio: los dinosaurios pasaban la ma
yor parte del su tiempo llenndose de alimento para poder mantener sus
enormes cuerpos. Esto tambin se aplica a ejrcitos, a compaas y a
una gran variedad de otros sistemas, incluyendo los sistemas automatiza
dos que estudiar en este libro. Un pequeo sistema de juguete, del ti
po que se puede crear en una sola tarde, por ejem plo, involucrar
usualmente muy poca burocracia, mientras que un sistema grande re
querir de un esfuerzo enorme en reas tan improductivas como la revi
sin de errores, la edicin, el respaldo, el mantenimiento, la seguridad, y
la documentacin.10
3.
Los sistemas siempre forman parte de sistemas mayores y siempre pue

den dividirse en sistemas menores. Este punto es importante por dos ra
zones: primeramente, sugiere una forma obvia de organizar un sistema
10 A m enudo, los usuarios no aprecian este fenm eno, y sta pudiera ser una de las razones por
las cuales actualm ente estn fa scin a do s con los lenguajes de cuarta generacin y las herram ientas
para hacer prototipos. Puede crearse con rapidez un sistem a en un enguaje de cuarta generacin
que haga las p artes c e n tra le s del procesam iento (y que de esta m anera recom pense insta n t n e a
m ente al usuario), pero co sta r m ucho trab a jo aadirle la in teligencia n ecesaria para revisar erro
res, re s p a ld a r, d a r m a n te n im ie n to , a s e g u ra r, a fin a r, d o c u m e n ta r, e tc. D e b e to m a rs e e sto en
cuenta, ya que de no se r as probablem ente el usuario lo acosar para que construya un sistem a
rpido y su cio que a fin de cuentas fallar. Para dar una idea de ios a lcances de algo tan m unda
no com o la docum entacin, co n sid e re la sig u ie n te estadstica, de la que rin de inform e C apers Jo
n e s en P ro g ra m m in g P r o d u c tiv ity (N u e v a Y o rk: M cG ra w H ill, 1 9 8 6 ): Un s is te m a g ra n d e de
te le co m u n ica cio n e s te n a 120 p alabras en ingls en cada rengln de cdigo fuente, haciendo un to
tal de 30 m illones de p a la b ra s y de 60,000 pginas; un sistem a gubernam ental grande tena 200
palabras en ingls por rengln de cdigo fuente, haciendo un total de 125 m illones de p alabras y
250,000 pginas de docum entacin.
www.FreeLibros.org
computacional que estemos tratando de desarrollar, por el procedimiento

de dividirlo en sistemas menores (veremos mucho de esto en captulos
posteriores de este libro). Pero an ms importante es el hecho de que
sugiere que la definicin del sistema que estamos tratando de desarrollar
es arbitraria; pudimos haber escogido un sistema ligeramente menor o
mayor. Escoger lo que deber abarcar un sistema y definirlo cuidadosa
mente para que todo mundo conozca su contenido es una actividad im
portante; se discutir con mayor detalle en el captulo 18. Estoes ms
difcil de lo que pudiera parecer: tanto los usuarios como los analistas a
menudo piensan que la frontera del sistema es fija e Inmutable y que todo
lo que se encuentre fuera no merece la pena de ser estudiado. Estoy en
deudado con Lavette Teague y Christopher Pidgeon [Teague y Pidgeon,
1985] por haber localizado el siguiente ejemplo de sistemas dentro de sis
temas, tomado de [Eberhard, 1970]:
Una ansiedad Inherente en los m todos de diseo es la na
tu ra le z a je r rq u ic a de la c o m p le jid a d . E sta a n s ie d a d se
m ueve en dos direcciones, el e scalam iento y la regresin In
fin ita . U tilizar un cuento, La adve rte n cia de la m anija, para
lustrar el principio del escalam iento.
Esta fue mi exp e rie n cia en W ashington cuando tu ve dinero
hasta para regalar. Si co n tra to a un d iseador y le digo; La
m anija de a puerta de mi o ficina no es de buen diseo, ca re
ce de im a g in a ci n . Me p o d ra usted d ise a r una nueva
m anija? El me contestara S y, tra s acordar un precio, se
m arch a . Una se m a n a m s fa rd e re g re s a y me dice: Sr.
E berhard, he estado p e nsando acerca de esa m anija. Pri
m ero, debiram os p reguntarnos si a b rir y ce rra r una puerta
por m edio de una m anija es la m ejor form a de h a ce rlo . Yo
le c o n te sto , B ien, creo en la im a g in a ci n . H gase usted
c a rg o . M s tarde, l regresa y me dice: Sabe? He estado
pensando en su problem a y la nica razn por la cual ocupa
una m anija es porque supone que n ecesita una puerta para
su oficina. Est seguro de que una puerta es la m ejor ma
nera de co n tro la r el acceso y su p rivacida d ? . No, no estoy
se g u ro de eso , replico. B ueno, p ues q u ie ro d e d ica rm e a
ese problem a . R egresa una sem ana ms tarde y me dice:
la nica razn por la cual debem os preocuparnos por el pro
blem a de la apertura es porque usted insiste en te n er cuatro
paredes en torno a su oficina. Est seguro de que sta sea
la m ejor m anera de o rg a n iza r este e spacio para el tip o de
trab a jo que desem pea com o b u r cra ta? Yo le respondo:
No, no estoy seguro en ab so lu to . Bueno, esto escalara"
hasta que nuestro d iseador regresara con una cara muy se
rla (e s to de h e ch o s u c e d i en d o s c o n tra to s , a u n q u e no
exa ctam e n te p o r este m ism o p roceso) d iciendo: Sr. E b e r
hard, debem os d e cid ir si la d e m o cra cia ca p ita lista es la m e
jo r m anera de o rg a n iza r nuestro pas, antes de que yo pueda
a ta car su problem a .
www.FreeLibros.org
Por otro lado te n em o s el problem a de la regresin infinita.

SI cuando esta persona se enfrent al diseo de la m anija
hubiera dicho: Espere, antes de preocuparm e por la m anija
deseo e stu diar la fo rm a de una m ano hum ana y lo que el ser
hum ano es capaz de hacer con e lla , yo le hubiese dicho:
B u e n o . L u e g o h u b ie ra re g re s a d o y m e h u b ie ra d ich o :
C uanto m s pens ai respecto m s me co n ve nc de que se
trata de un problem a de ajuste. Lo que quiero estu diar pri
m ero es cm o se fo rm a el m etal y qu te cn olog a existe para
fa b rica r o bjetos con meta!, para a s poder conocer los verda
deros parm etros para a justarla a la m ano . Bueno , le hu
biera contestado. Pero entonces me hubiera dicho: Sabe?,
he estado co nsiderando la form acin de m etales y to d o pa
rece dep en d e r de las propiedades m etalrgicas. Q uiero pa
sa r tre s o cu a tro m eses revisan d o el asp e cto m etalrgico,
para poder co m p re n d er m ejor el pro b le m a . Bueno , le hu
biese contestado. D espus de tres m eses l hubiera vuelto
diciendo: Sr. E berhard, cuanto m s e studio el problem a me
ta l rg ico m s me convenzo de que es la estructura atm ica
la que se encuentra en el fondo de todo e sto . Y as, nues
tro d iseador a cabara inm iscuido en la fsica a t m ica por la
m anija. Esta es una de nuestras ansiedades, la naturaleza
je r rq u ica de ia com plejidad.
4.
2.6
Los sistemas crecen. Desde luego, esto pudiera no ser verdad para to
dos los sistemas pues violara un principio general muy familiar, la ley de
la conservacin de la energa. Pero muchos sistemas con los que es
tamos familiarizados s crecen y resulta importante reconocerlo, pues a
menudo omitimos (como analistas y como diseadores de sistemas) to
mar esto en cuenta al comenzar a crear el sistema. Un sistema de infor
m acin tp ic o , por ejem plo, crece r hasta el punto de in c lu ir ms
software, ms datos, ms funciones y ms usuarios que los que inbiaimente habamos planeado. Por ejemplo, en una encuesta clsica de alre
dedor de 500 organizaciones de procesamiento de datos en los Estados
Unidos, Lientz y Swanson [Lientz y Swanson, 1980] encontraron que la
cantidad de cdigo contenida en un sistema automatizado existente au
menta aproximadamente en un 10 por ciento al ao y el tamao de la ba
se de datos se incrementa en alrededor de un 5 por ciento al ao. No se
puede suponer que un sistema ya hecho pueda permanecer esttico; el
costo de hacerlo crecer a medida que transcurre el tiempo debe incluirse
en los clculos de costo- beneficio, que se discutirn en el captulo 5 y
en el apndice C.
RESUMEN
Los analistas de sistemas en la profesin del procesamiento de datos a menu

do son vctimas de la ley de la especializacin anteriormente expuesta: se convier
ten en expertos en su propio campo, sin darse cuenta de la existencia de otros :pos
de constructores de sistemas y de que se pudieran aplicar algunos principios gene-
www.FreeLibros.org
mies. El propsito primordial de este captulo ha sido ampliar su horizonte y ofrecer

una mayor perspectiva antes de ahondar ms en el estudio de los sistemas de infor
macin automatizados.
Obviamente, uno no puede convertirse en experto en sistemas vivientes, sistemas fsicos y todo tipo de sistemas hechos por ei hombre adems de ios sistemas
de informacin automatizados. Pero dado que ios sistemas que es probable que
uno cree casi siempre interactan con esos otros, es importante estar consciente de
su existencia. Ai comprender que otros sistemas obedecen a muchos de ios mismos
principios generales que observan los sistemas computacionales que est haciendo,
ser ms probable que tenga xito ai definir ios lmites entre su sistema y el mundo
exterior.
REFERENCIAS
1. Edward Yourdon, Design of On-Une Computer Systems. Englewood Cliffs, N.J.:
Prentiee-Hall, 1972, Pg. 4
2. James Martin, Design o f Real-Time Computer Systems. Englewood Cliffs, N.J.i
Prentlce-Hall, 1967.
3. James Grier Miller, Living Systems. New York: McGraw- Hill, 1978.
4. George Steiner, Strategic Planning. New York: Free Press, 1979.
5. Peter Drucker, Management: Tasks, Responsibilities, Practices. New York: Harper & Row, 1974.
6. Russell L. Ackoff, A Concept o f Corporate Pianning. New York: Wiley, 1970.
7. Stafford Beer, Brain of the Firm. New York: Wiley, 1972.
8. Stafford Beer, The Heart of Enterprise. New York: Wiley, 1978.
9. Stephen Hal, Biochips, High Technology, diciembre, 1983.
10. H. Garrett DeYoung, Biosensors", High Technology, noviembre, 1983.
11. Nchoas Shrady, Molecular Computing, Fortes, julio 29, 1985.
12. David, Olmos, DOD Finances Case Western Biochip Research Center, Computerworid, septiembre 3, 1984.
13. Elaine Rich, The Gradual Expansin of Artificial Snteiligence, IEEE Computer,
mayo, 1984.
www.FreeLibros.org
14. Edward Feigenbaum y Pamela McCorduck,
Mass.: Addison-Wesley, 1983.
The Fifth Generation.
Reading,
15. R.J.K. Jacob y J.N. Froscher, Software Engineering for Rule-Based Software
Systems , Proceedings of he 1986 Fal Joint Computer Conference. Washing
ton, D.C.: IEEE Computer Society Press, 1986.
16. Robert E. Keller, Expert Systems Technology: Development and Application.
Engewood Cliffs, N.J.: Prentce-Hali, 1987.
17. Robert Alloway y Judith Quiliard, User Managers Systems Needs, CISR Working Paper 8 6 . Cambridge, Mass.: MIT Sloan Schooi Center for Information
Systems Research, abril, 1982.
18. Ludwig von Bertalanffy, Teora General de los Sistemas. Mxico: Fondo de Cul
tura Econmica, 1976.
19. Gerald Weinberg, An Introduction to General Systems Thinking. New York: Wiley, 1976.
20. John Gal!, Systemantics.
Company, 1977.
New York: Quadrangle/The New York Times Book
21. D. Barstow, Artificial Intelligence and Software Engineering, Proceedings of

the 9th International Software Engineering Conference, abril, 1987.
22. M.D. Lubars y M.T. Harandi, Knowledge-Based Software Design Using Design
Sobernas, Proceedings o f the 9th International Software Engineering Conferen
ce, abril, 1987.
23. Bennet P. Lientz y E. Burton Swanson, Software Maintenance Management, Reading, Mass.: Addison-Wesiey, 1980.
24. Lavette Teague y Christopher Pidgeon, Structured Analysis Methods for Compu
ter Information Systems. Chicago: Science Research Associates, 1985.
25. John P. Eberhard, We Ought to Know the Dfference, Engineering Methods in
Environmental Design and Pianning, Gary T. Moore, ed. Cambridge, Mass.: MIT
Press, 1970, pp. 364-365.
1. D dos ejemplos de cada una de las definiciones de sistema obtenidas del dic
cionario Webster, expuestas al comienzo del captulo 2.
2. D cinco ejemplos de sistemas que hayan durado ms de un milln de aos y
que an existan hoy en da.
www.FreeLibros.org
3. D cinco ejemplos de sistemas hechos por el hombre que hayan durado ms de
1000 aos. En cada caso, d una breve explicacin de por qu han durado f
de si se pudiera esperar que continen durante los siguientes 1000 aos.
D cinco ejemplos de sistemas no hechos por el hombre que hayan fallado du

rante su vida. Por qu fallaron?
5 . D cinco ejemplos de sistemas hechos por el hombre que hayan fallado durante
su vida. Por qu fallaron?
g. Proyecto de investigacin: lea la obra Living Sistems, de Miller, y haga una crti
ca.
7 . Proyecto de investigacin: lea la obra de Beer, Brain of ihe Firm, y haga una
crtica.
8. Proyecto de investigacin: lea la obra de Beer, The Heart of Enterprise, y haga
una crtica.
9. De la seccin 2.3, d un ejemplo de un sistema hecho por el hombre que, en su
opinin, no debiera automatizarse. Por qu piensa que no debiera automati
zarse? Qu pudiera salir mal?
10. D un ejemplo de un sistema no automatizado que, en su opinin, debiera auto
matizarse. Por qu piensa que debiera automatizarse? Cuales seran los
beneficios? Cul sera el costo? Qu tanto puede confiar en ios beneficios y
en los costos?
11. D ejemplos de los 19 subsistemas de Miller para los siguientes tipos de sis
temas automatizados: a) nmina, b) control de inventarios, c) el sistema telef
nico.
12. Escoja una pequea organizacin con la cual est relativamente familiarizado, o
bien un departamento o divisin de una organizacin grande. Para la organiza
cin escogida, lleve a cabo un inventario de los sistemas que utiliza. Cuntos
de stos son sistemas operacionales? Cuntos son sistemas de apoyo a deci
siones? Cuntos son sistemas de pianeacin estratgica? Existen otras ca
tegoras tiles de sistemas? Para ayudarlo a enfocar su atencin en esto,
consulte [Alloway y Quilard, 1982].
13. D cinco ejemplos de su propia experiencia de a) sistemas de tiempo real, b)
sistemas en lnea, c) sistemas de apoyo a la toma de decisiones, d) sistemas
de pianeacin estratgica y e) sistemas expertos.
14. La figura 2.4 muestra una configuracin tpica de hardware para un sistema en
lnea. Dibuje el diagrama para una configuracin de hardware distinta que sea
razonable. Tiene sentido tener parte de los datos de sistema localizados en
las terminales? En qu momento del desarrollo del sistema debiera discutirse
esto con el usuario?
www.FreeLibros.org
15. D un ejemplo de un sistema comercial que se describa como de inteligencia
artificiar o como un sistema basado en el conocimiento y que, en su opinin,
no est siendo descrito honesta o exactamente.

cripcin sea engaosa?
Por qu piensa que la des
16. Podra aplicarse el modelo estmulo-respuesta mostrado en la figura 2.5 a

otros sistemas que no sean de los sistemas de tiempo real? No responden
acaso todos los sistemas a estmulos? Qu tienen de especial os sistemas
de tiempo real?
17. Realmente puede tomar decisiones un sistema de apoyo a la toma de decisio
nes? Si no, por qu no? Qu pudiera hacerse para modificar un tpico siste
ma de apoyo a la toma de decisiones para que pudiera tom arlas? Sera
deseable esto? Cuales son los inconvenientes?
www.FreeLibros.org
LOS PARTICIPAN!
JU E6 DE LOS
T odo el m undo es un escenario,
Y los hom bres y m ujeres son sim ples actores:
T ien e n sus e n tradas y salidas;
Y un hom bre, en el tran scu rso de su vida,
R ealiza m uchos papeles.
Shakespeare.
A s You Like It, II, vil
n este captulo se aprender:

1. Cules son las categoras de personas con las que
interactuar a lo largo de un proyecto.
2. Cules son as tres principales categoras de
usuarios, clasificados segn su trabajo.
3. Cules son las reacciones de los usuarios durante
un proyecto de desarrollo de sistemas.
4. Cul es la diferencia entre los usuarios novatos y los
expertos.
5. Cul es el papel de a administracin en un proyecto
de desarrollo de sistemas.
6. Cul es el papel de un analista en un proyecto de
desarrollo de sistemas.
7. Qu otros papeles se pueden dar en un proyecto de
desarrollo de sistemas.
www.FreeLibros.org
46 LOS PARTICIPANTES EN EL JUEGO
C o m o analista de sistemas, usted trabajar en proyectos de desarrollo con

una variedad de personas. Los personajes cambiarn de un proyecto a otro; las per
sonalidades variarn dramticamente, y el nmero de personas con las que tendr
que interactuar puede ir de una sola hasta docenas. Sin embargo, los papeles son
bastante constantes, y ver los mismos una y otra vez.
Ser un analista con xito requiere algo ms que una simple comprensin de la
tecnologa de las computadoras. Entre otras cosas, requiere de habilidades inter
personales; pasar buena parte de su tiempo trabajando con otras personas, mu
chas de las cuales hablan un idioma muy diferente al suyo y encontrarn extrao e
intimidante su idioma tcnico computacional. Por eso, es importante que conozca
las expectativas que los dems tendrn de usted y las que usted deber tener de
ellos.
En este captulo se enfoca la atencin sobre las caractersticas de las siguien
tes categoras principales de jugadores que probablemente encontrar en un pro
yecto caracterstico de desarrollo de sistemas;
Usuarios
Administracin
Auditores, personal de control de calidad, y verificadores de normas
Analistas de sistemas
Diseadores de sistemas
Programadores
Personal de operaciones
Cada una de estas categoras se describe a continuacin.

3.1
USUARIOS
El participante ms importante en el juego de los sistemas es alguien que el

analista conoce como usuario. El usuario es aqul (o aqullos) para quien se cons
truye el sistema. Es la persona a la que tendr que entrevistar, a menudo con gran
detalle, a fin de conocer las caractersticas que deber tener el nuevo sistema para
poder tener xito.
Debe hacerse notar que la mayora de los usuarios no se refieren a s mismos
como usuarios (a menudo se utiliza esta palabra en otros contextos para describir
a un drogadicto). En algunas organizaciones se evita ese problema utilizando el tr
mino cliente o dueo para identificar al usuario. El usuario es el dueo en el senti
do de que es l quien recibe el sistema cuando se termina de crearlo. Y el usuario
www.FreeLibros.org
LOS PARTICIPANTES EN EL JUEGO 47
es el cliente por lo menos en dos sentidos importantes: 1) como en muchas otras

profesiones, el cliente siempre tiene la razn, sin importar lo exigente, desagrada
ble o irracional que pueda parecer y 2) el cliente es el que a fin de cuentas paga el
sistema y usualmente tiene el derecho de rehusarse a pagar si no est conforme con
el producto.
En la mayora de los casos, es fcil identificar al usuario (o usuarios): de ma
nera caracterstica, es aquel que formalmente solicita un sistema. En una organiza
cin pequea, esto suele ser un procedim iento muy informal; pudiera consistir
simplemente en que el usuario llame por telfono al analista oficial de sistemas y le
diga: Oye, Adriana, necesito un nuevo sistema para dar seguimiento a nuestra nue
va campaa de comercializacin. En una organizacin grande, el inicio de un pro
yecto de desarrollo de sistemas suele ser mucho ms formal. Por lo comn, la
solicitud de consideracin y estudio de sistemas, como se le suele conocer, pasa
por diversos niveles de aprobacin antes de que se involucre al analista de siste
mas. El captulo 5 trata esto ms a fondo.
Sin embargo, hay un gran nmero de situaciones en las que no se conoce la
identidad del verdadero usuario o bien en las que hay poca oportunidad de que ste
interacte con el analista. Un ejemplo muy comn de esto es el de un sistema en
proceso de ser desarrollado por un negocio de consultora o por una compaa pro
ductora de software: la interaccin que exista entre el cliente y la compaa pudiera
llevarse a cabo a travs de administradores de contratos u otras agencias adminis
trativas, a veces con clusulas explcitas de que el analista no puede tener comuni
cacin directa con el usuario. Aun si el sistema se desarrolla por completo dentro de
una sola organizacin, el verdadero usuario pudiera nombrar a un representante
para trabajar con el analista, por estar demasiado ocupado personalmente con otros
asuntos.1
Obviamente, en situaciones de este tipo, hay una gran posibilidad de malos
entendidos: lo que el usuario quiere que el sistema haga pudiera no serle comunica
do de manera correcta al analista, y lo que ste crea que est construyendo para el
usuario pudiera no serle comunicado tampoco de manera correcta, hasta que ya es
tuviera todo terminado, cuando ya sera demasiado tarde. De esto podemos sacar
dos conclusiones importantes:
Siempre que sea posible, el analista debiera tratar de establecer contacto

directo con el usuario. Aun si se encuentran involucradas otras personas
como intermediarios (por ejemplo, para tratar detalles de ios contratos o
asuntos administrativos), es importante tener reuniones con la persona
1 Una situacin comn de esta naturaleza es la del enca rg a d o de co n tra ta r proyectos en una orga
nizacin gubernam ental. En la m ayora de los casos, esta persona no es el usuario y puede no co
nocer m ucho acerca de as ve rd a d e ras necesidades de ste, pero re su lta ser el nom inado para
m antener cu a lq u ie r com unicacin oficial con la persona (o com paa) que deber de sa rro lla r el sis
tema.
www.FreeLibros.org
que en ltimo trmino recibir el sistema. De hecho, suele ser an mejor

si el usuario forma parte activa dei equipo encargado del proyecto. En
muchas organizaciones, el usuario suele ser el gerente de proyectos; in
cluso, algunos argumentan que ei usuario mismo debiera llevar a cabo el
proyecto.
3.1.1
Si no es posible comunicarse directamente con el usuario, ia documenta

cin generada por el analista se vuelve an ms importante. La parte II
de este libro se dedica a las herramientas de modelado que pueden utili
zarse para describir el comportamiento de un sistema de manera formal y
rigurosa. Es esencial usar este tipo de herramientas para evitar malos
entendidos costosos.
La heterogeneidad de los usuarios.
Uno de los errores ms frecuentes que cometen en el campo de las computa

doras sobre todo los programadores y a veces tambin los analistas, es suponer que
todos los usuarios son iguales. La palabra usuario, como sustantivo singular, da a
entender que ei analista slo tendr que nteractuar con una persona. Aun cuando
sea obvio que deber intervenir ms de un usuario, se tiene la tendencia a pensar
en ellos como un grupo de humanos amorfo y homogneo.
Decir simplemente que un usuario difiere de otro es insuficiente: claro, tienen
diferentes personalidades, diferente preparacin, diferentes intereses, etc. Pero
tambin hay diferencias importantes que usted debe tener en mente al trabajar como
analista. He aqu dos maneras de clasificar a los usuarios:
3.1.2
Por categora de trabajo o nivel de supervisin
Por nivel de experiencia en el procesamiento de datos

C lasificacin de los usuarios por categora de trabajo
En un proyecto tpico de anlisis de sistemas se pasar una considerable can

tidad de tiempo entrevistando a ios usuarios para determinar los requerimientos del
sistema. Pero, cules usuarios?, a qu nivel? Desde luego, esto depender del
proyecto y de ias polticas de su organizacin. Sin embargo, habitualmente tendr
que interactuar con individuos de tres categoras de trabajo: usuarios operacionales,
usuarios supervisores y usuarios ejecutivos.2
Los usuarios operacionales son oficinistas, administradores y operadores que
son los que ms probablemente tendrn contacto diario con el nuevo sistema (a me
www.FreeLibros.org
2 Hay va rian te s de esta te rm in o lo g a: [Teague y Pidgeon, 1985], por ejem plo, se refieren tam bin al
usuario ben eficiad o , el que recibir los b e neficios del nuevo sistem a. Esta persona pudiera no te
ne r contacto d irecto con el sistem a, pero se b eneficiar de alguna m anera con el se rvicio m ejorado
o la fun cio na lida d del nuevo sistem a.
nos que est usted construyendo un sistema de apoyo a las decisiones, en cuyo ca
so tendr poco contacto con este grupo). Por eso, en una organizacin grande, ten
dr que entrevistar a secretarias, agentes de seguros, bibliotecarios, oficinistas
encargados de fletes, personal encargado de solicitudes y ayudantes de todos los
tamaos, formas y colores. En el caso de un sistema de tiempo real, pudiera tener
que hablar con usuarios operacionaies tales como ingenieros, fsicos, obreros, pilo
tos, operadoras telefnicas, etc. Debe tener tres cosas en mente cuando se trabaja
con usuarios de nivel operacional:
1.
Los usuarios de este nivel se preocupan mucho por las funciones que ten
dr el sistema, pero es ms probable an que se preocupen por los deta
lles de la interfaz humana. Por ejemplo: Qu tipo de teclado estar
usando para comunicarme con el sistema?; es como el teclado de la m
quina de escribir que he estado usando durante aos; como aparecern
las cosas en la pantalla?; deslumbrar mucho la pantalla?; se podrn
leer fcilmente los caracteres?;3 cmo me indicar el sistema si he co
metido un error?; tendr que volver a teclear todo?; qu tal si quiero
borrar algo que teclee hace un momento?; cuando el sistema me haga
un informe, en dnde estar localizada la informacin en la pgina?;
puedo hacer que se imprima la fecha y la hora en la parte superior de
cada hoja?, etc. Estos son detalles que el supervisor del usuario de nivel
operacional pudiera o no tomar en cuenta, pero que, como se podr ima
ginar, son vitales para el xito de un sistema y se tendrn que abordar.4
Esto significa que, como analista, necesitar tener comunicacin directa
con el usuario operacional o, en el peor de los casos, estar muy seguro
de que la persona que representa a ste tenga presentes tales detalles.
Estos se discuten ms a fondo en el modelo de puesta en prctica por el
usuario, en el Captulo 21.
2.
Los usuarios operacionaies tienden a poseer un panorama local del sis

tema; por lo general son conocedores del trabajo especfico que hacen y
de las personas con las que tienen comunicacin inmediata (clientes, su
pervisores, colegas, etc.). Sin embargo a menudo no estn familiarizados
con el panorama general; es decir, puede ser que tengan dificultad para
describir cmo es que su actividad propia encaja dentro de la organiza-
3 Hay argum entos en relacin con esto que hacen hincapi en el hecho de que un sistem a nuevo
es parte de un sistem a an m ayor: el usuario puede preguntar: Me lastim ar la esp a ld a o me
dar te n dinitis el estar sentado frente a una term inal todo el d a ? , N ecesito preocuparm e por la
radiacin proveniente de una pantalla de vid e o ? , Qu ta i si no s te cle a r? y, lo ms im portante,
Qu tal si este nuevo siste m a me reem plaza en el tra b a jo y me deja sin e m pleo?
www.FreeLibros.org
4 En casos extrem os, esto tam bin sig n ifica que es el usuario op e ra cio n a l quien puede hacer o
deshacer un sistem a nuevo. Los usuarios op e ra cio n a ie s pueden p a recer pasivos y puede ser que
no tengan la autoridad o el poder para apro b a r un pro ye cto de de sa rro llo de sistem as, pero si lo sa
botean, o sim plem ente no lo usan, el siste m a nuevo habr fallado.
cin global o para describir el carcter global de su organizacin. Esto

rara vez se debe a torpeza, sino a que no tienen inters en el asunto. O
tambin pudiera reflejar que el usuario supervisor no les haya dado a co
nocer nada de eso porque as lo prefiere. Una consecuencia de esta si
tuacin es que el analista debe poder desarrollar modelos de sistemas
que permitan ambos panoramas (es decir, descripciones de partes peque
as y detalladas del sistema, independientemente de otras partes) y des
cripciones globales (es decir, panoramas de alto nivel del sistema entero
que evitan caer en detalles).
3.
Los usuarios operacionales suelen pensar en los sistemas en trminos f

sicos, es decir, en trminos de la tecnologa de puesta en prctica que
comnmente se utiliza para implantar o hacer uso del sistema, o en tr
minos de a tecnologa que imaginan que pudiera utilizarse. Las discusio
nes abstractas acerca de funciones y tipos de datos" pueden resultar
difciles; de aqu que el analista de sistemas pudiera requerir hablar con
el usuario exclusivamente en trminos familiares. Luego, como una acti
vidad aparte, puede traducir esta descripcin fsica a un modelo esen
c ia l , es decir, a un m odelo de lo que el sistem a debe hacer,
independientemente de la tecnologa usada para realizarlo. Esto se dis
cute ms a fondo en el capitulo 17.
Los usuarios supervisores son, como el trmino lo da a entender, empleados

como supervisores: usualmente administran a un grupo de usuarios operacionales y
son responsables de sus logros (obviamente, se puede imaginar ms de un nivel de
usuarios supervisores en una organizacin grande). Pueden tener el ttulo de super
visor, pero pueden ser tambin jefes de turno, gerentes, ejecutivos, jefes de ingenie
ra u otra multitud de cosas. Lo importante acerca de los usuarios supervisores es
que:
Muchos de ellos son usuarios operacionales que han sido promovidos.

Por eso, usualmente estn familiarizados con el trabajo de sus subordina
dos operacionales y se puede suponer que estarn de acuerdo con sus
necesidades, preocupaciones y perspectivas. Sin embargo, esto no siem
pre es as. Dado que ei mercado, la economa y la tecnologa han cam
biado tanto, el trabajo operacional de hoy en da puede diferir mucho de
lo que era hace 20 aos.
Una de las razones por las cuales pudiera suponerse que no hay comuni
cacin entre el usuario supervisor y el operacional es porque el primero a
menudo debe regirse por un presupuesto. De aqu que a menudo se inte
resa en un nuevo sistema de informacin por la posibilidad de incremen
tar el volumen de trabajo realizado disminuyendo a la vez ei costo de
procesar las transacciones, y reduciendo tambin los errores en el traba
jo. Tambin pudiera ocurrrsele que un sistema nuevo le dar oportuni
www.FreeLibros.org
dad de supervisar el trabajo (e incluso la actividad minuto a minuto) de

cada usuario operacional. Dependiendo de cmo se realice esto, los
usuarios operacionales pudieran tener o no la misma perspectiva que el
usuario supervisor.
Debido a este nfasis en la eficiencia operacional, por lo general el usua

rio supervisor es el que ve al nuevo sistema como una forma de reducir el
nmero de usuarios operacionales (por despido o arrepentimiento) o de
evitar que aumente su nmero al crecer el volumen de trabajo. Esto no
es ni bueno ni malo, pero a menudo es el punto focal de batallas polticas,
en las cuales el analista suele encontrarse en medio.5
Por las mismas razones, el usuario supervisor a menudo acta como in

termediario entre el analista y los usuarios operacionales, arguyendo que
estos ltimos estn demasiado ocupados como para perder su tiempo ha
blando con el analista. El supervisor replicar: Despus de todo, necesi
tamos el sistem a com putacional pre cisam ente porque estam os tan
ocupados. Como se podr imaginar, sta es una posicin muy peligrosa
para usted. Despus de todo, el usuario operacional es el que se preocu
par ms por la interfaz humana del sistema y es poco probable que el
supervisor pueda hacerse eco debidamente de estas necesidades.
El usuario supervisor a menudo piensa en los mismos trminos fsicos

que el operacional, y su perspectiva a menudo resulta tan local como la
de este ltimo. Desde luego, uno esperar que una persona de nivel ad
ministrativo tuviera un panorama ms global; como corolario, pudiera re
sultar que el usuario supervisor ya no recuerde algunas de las detalladas
polticas de negocios que los usuarios operacionales llevan a cabo.
Finalmente, ser el usuario supervisor con quien usted tendr el contacto

cotidiano primario. Es el que definir los requerimientos y las polticas de
la empresa que su sistema deber realizar. Pudiera ser slo un miembro
pasivo del equipo (en el sentido de que participar slo cuando se le en
treviste), o bien un miembro de tiempo completo o incluso, como se men
cion anteriormente, el gerente del proyecto.
Los usuarios de nivel ejecutivo en general no se involucran directamente con

el proyecto de desarrollo del sistema, a menos que el proyecto sea tan amplio y tan
importante que tenga un impacto de primer orden en la empresa. Sin embargo, para
5 Advirtase que sta es una caracterstica de un siste m a operacional (com o se de fin i en el ca p
tulo 2), pero generalm ente no lo es de los sistem as de apoyo a d ecisiones. Ntese tam bin que los
gerentes o adm inistradores de nivel su p e rio r por lo general se interesan m s en los sistem as que
les ofrecen una ventaja co m p e titiva que en aquellos que reducen personal operacional en una o
dos personas.
www.FreeLibros.org
un proyecto normal, el usuario ejecutivo suele estar dos o tres niveles arriba de la
accin asociada con el proyecto. En la medida que usted se involucre con ellos, pro
bablemente descubrir lo siguiente acerca de los usuarios ejecutivos:
Pueden proporcionar la iniciativa para el proyecto, pero es ms probable

que sirvan slo como autoridad para financiar las solicitudes que se origi
nan en niveles ms bajos de la organizacin.
Por lo comn, no fueron previamente usuarios operacionales o, si lo fue

ron, habr sido hace tanto tiempo que cualquier experiencia que tengan al
respecto ser obsoleta. Por ello, no se encuentran en posicin que les
permita definir los requerimientos del sistema para aquellos que lo esta
rn manejando cotidianamente. Como excepcin de esto tenemos el sis
tema de apoyo a decisiones que se discuti en el captulo 2 ; tal sistema lo
utilizaran primordialmente usuarios supervisores y ejecutivos.
Los usuarios ejecutivos se preocupan ms por los detalles estratgicos y

las ganancias/prdidas a largo plazo. De aqu que, por lo regular, estn
menos interesados en asuntos operacionales tales como abatir los costos
de transaccin o ahorrarse tres oficinistas, que es lo que Paul Strassman
llama los beneficios de la informtica en su obra [Strassman, 1985]. Es
to es, los nuevos mercados, los nuevos productos o la nueva ventaja
competitiva que pudiera obtenerse con el sistema.
Los usuarios de nivel ejecutivo generalmente se interesan ms en el pa

norama global del sistema. En consecuencia, suelen no interesarse por
los detalles. Como ya se mencion, esto significa que debemos utilizar
las herramientas de modelado que permiten dar un panorama global del
sistema para los usuarios ejecutivos (y para cualquier otra persona que lo
requiera), as como porciones detalladas del sistema para los usuarios
operacionales que son los expertos locales.
Similarmente, los usuarios ejecutivos por lo general pueden trabajar con

modelos abstractos de un sistema; de hecho, ya estn acostumbrados a
trabajar con modelos abstractos tales como modelos financieros, modelos
de mercado, modelos organzacionaies y modelos de ingeniera (de nue
vos productos, oficinas, etc.). En realidad, no estarn interesados en los
modelos fsicos del sistema y se preguntarn por qu se toma usted la
molestia de mostrrselos.
En resumen, usted nteractuar con tres tipos o niveles diferentes de usuarios,

como lo muestra la figura 3.1. Recuerde que tienen distintas perspectivas, intereses
y prioridades y, a menudo distinta preparacin. Estos tres tipos de usuarios se pue
den caracterizar como lo muestra la tabla 3.1.
www.FreeLibros.org
En la explicacin anterior insinu que al usuario no siempre le agrada la pers

pectiva de un nuevo sistema; de hecho, a menudo se opondrn activamente a l. Es
te es casi siempre el caso con los usuarios operacionaies (dado que son los que lo
tendrn que usar), pero tambin se puede encontrar resistencia por parte del usuario
supervisor(dado que ste pudiera sentir que el sistema tendr un impacto negativo
sobre laeficiencia o ganancias del rea de la cual es responsable), oincluso
por
parte del usuario ejecutivo. Como lo seala Marjorie Leeson en su obra [Leeson,
1981],
El a n alista que entiende de m otivacin bsica, del por qu las per
sonas se resisten al cam bio y cm o se resisten a l, puede tal vez
superar en parte la resistencia. La m ayora de los te xto s de a dm i
nistracin hacen referencia a la o ra derarqua de las necesidades,
de A.H. M aslow . Las cinco categoras, desde la de m s baja hasta
de la m s alta prioridad, son
Necesidad
Ejeraela
1. F isiolgica
Alim ento, ve stid o y casa
2. Seguridad y
estabilidad
econm ica
Proteccin contra el peligro y ia prdida

dei em pleo
3. Social
Poder id e n tifica rse con in d ividuos y

grupos
4. Egosta
R econocim iento, situacin social e

im portancia
5. Realizacin
R ealizarse ai m xim o en la crea tivid a d y

el de sa rro llo personal
' i -
El usuario
supervisor
El usuario
ejecutivo
www.FreeLibros.org
El usuario operacional
Figura 3.1: Los tres tip o s de usuarios
As, si encuentra que algunos usuarios se resisten a la idea de tener un nuevo

sistema, deber pensar en la posibilidad de que una o ms de estas necesidades no
se est satisfaciendo. Desde luego, es raro que el usuario se preocupe acerca del
nivel fisiolgico de la necesidad, pero no sorprende el hecho de que pueda preocu
parse por la prdida de su empleo. Tambin es comn que los usuarios (sobre todo
los operacionales) se preocupen porque el sistema vaya tal vez a llevarlos a no po
derse identificar con los grupos sociales que les son familiares; temen que estarn
encadenados a una terminal todo el da y que pasarn todo su tiempo interactuando
con una computadora en lugar de hacerlo con otros humanos. Ei usuario operacional que se haya vuelto experto en la realizacin de determinada labor de procesa
miento manual de informacin pudiera temer que el nuevo sistema le perjudique en
sus necesidades egostas ; y el usuario que sienta que el sistema le restar creati
vidad a su trabajo tambin se resistir.
Tabla 3.1: C aractersticas de los diferentes usuarios
3.1.3
U suario o p e ra c io n a i
U suario su p e rviso r
U suario e je cu tivo
U sualm ente tiene un

panoram a local
Puede o no te n e r un
panoram a local
Tiene un
panoram a global
Hace fu n cio na r el
sistem a
G eneralm ente, est

fam ilia riza d o con a operacin
Provee la in iciativa
para e proyecto
Tiene una visin fsica

del sistem a
Lo rigen consideraciones
presupustales
No tiene exp e rie n cia

operacionai directa
Acta a m enudo com o

interm ediario entre ios
usuarios y ios niveles
superiores de adm inistracin
Tiene preocupaciones
estratgicas
......
C lasificacin de los usuarios en categoras por nivel de experiencia
Debera ser obvio que los diferentes usuarios tendrn diferentes niveles de ex
periencia; desafortunadamente, es comn que los analistas supongan que todos los
usuarios son idiotas en lo que concierne al uso de computadoras. Tal vez esta su
posicin fuera admisible hace 10 aos, pero es probable que le ocasione meterse en
problemas en muchas organizaciones hoy en da6: actualmente se puede diferenciar
6 Aun cuando cada usuario con el que se encuentre no conozca y no tenga inters por ia tecnologa :
de las com putadoras, d e biera e vita r el e rro r com n de co n sid e ra rlo s a todos com o una fo rm a de vi
da subhum ana. Los a n alistas y program adores jvenes, sobre todo los e xp e rim entadores que em
pezaron a u tiliz a r las co m p u ta d o ra s desde la escu e la p rim aria, suponen que to d o s deben estar ;
fa scin a do s con las com p u ta d o ra s y te n er habilidad para usarlas, y que aquellos que no cum plan
con esto son 1) retrasados m entales, o bien 2} m iem bros de una generacin a n tigua y, por tanto, ndignos de consideracin o respeto. M ientras tanto, el m undo est lleno de usuarios que no gustan
de las com putadoras por una va riedad de razones legtim as, y hay usu a rio s que estn dem asiado
ocupados tratando de s e r exp e rto s en su p ropia p ro fe si n o negocio com o p a ra pre o cu p a rse p o r ser
expertos en com putadoras. T ienen la m ism a opinin de los program adores de com p u ta d o ra s y de
www.FreeLibros.org
entre amateurs, novatos presuntuosos y un pequeo (pero creciente) grupo de ver

daderos expertos.
El amateur es aqul que jams ha visto una computadora y que exclama a to
do pulmn y con frecuencia que l no entiende todo este asunto de las computado
ras. A menudo, este tipo de usuario suele ser un empleado o negociante de
mediana edad que ha sobrevivido felizmente a lo largo de 16 aos de educacin y
de otros 10 o 20 aos en un empleo antes de que se introdujeran las computadoras.
Sin embargo, tambin es comn encontrar usuarios jvenes (de veintitantos aos)
que encuentran a las computadoras aburridas, intimidantes o inaplicables en sus vi
das. Esto presenta un reto para el analista de sistemas al que le encanta hablar del
acceso en lnea y los dilogos hombre-mquina dirigidos por mens y terminolo
ga por el estilo. Pero si el analista hace bien su trabajo, no hay razn por la cual el
usuario deba interesarse por las computadoras o tener grandes conocimientos acer
ca de ellas.
En realidad, el verdadero problema con el usuario amateur es un tanto ms
isutil: puede ser que encuentre difcil de entender el lenguaje que el analista usa
para describir las caractersticas, funciones y opciones que ofrece el sistema que se
va a implantar, aun cuando se evite la terminologa obviamente relacionada con las
computadoras. Como veremos en as partes II y III, el trabajo del analista de siste
mas comprende la creacin de varios modelos del sistema que se implantar. Estos
modelos son representaciones formales y rigurosas de un sistema computacional y
ai mismo tiempo son representaciones abstractas del sistema. La mayora de los
modelos comprenden grficas (imgenes) apoyadas con textos detallados y la repre
sentacin global (que es necesaria para asegurar una descripcin formal y rigurosa)
da a algunos usuarios la impresin de ser abrumadoramente matemtica y por lo
tanto no legible. Pudiera tratarse de usuarios que recuerdan la dificultad de leer las
notaciones grficas complejas utilizadas en qumica orgnica o la notacin igualmen
te compleja que se utiliza en el clculo diferencial y en el lgebra. Cualquiera que
sea la razn el resultado es el mismo: dejando de lado el entendimiento de a tecnologa computacional, si el usuario ni siquiera puede entender el modelo de un siste
ma, hay poca probabilidad de que le satisfaga el sistema cuando por fin est
terminado.7
los analistas de sistem as que la que tienen de los e le ctricista s, carp in te ro s, plom eros y m ecnicos
autom otrices: aprecian las habilidades y destrezas requeridas para llevar a cabo el trabajo, pero ex
hiben una to ta l fa lta de inters en los detalles. C o m prender este punto en m uchos casos determ i
nar si usted tendr xito o no en sus prim eros proyectos com o analista.
7 Como analoga: si le fueran a co n stru ir su casa, em p e za ra por d iscu tir las ca ra cte rsticas desea
das con el arquitecto. Tras m ucho discutir, ste se ra a su oficina y luego vo lve ra con varios bos
quejos o m aquetas a escala de la casa. Si usted se rehusara a m irar los bosquejos o a legara que
son dem asiado m atem ticos , el arquitecto te n dra pocas pro b a b ilid a d e s de xito. Lo que con toda
probabilidad hara usted es llevarlo a una casa existente y d ecirle con stru ya m e una com o esa .
Desgraciadam ente, a m enudo no estam os en una posicin adecuada para hacer eso en el cam po
de las com putadoras, aunque, m uchas veces, la elaboracin de pro to tip o s es una m anera viable de
lograr lo mismo.
www.FreeLibros.org
Un segundo tipo de usuario es aqul que pudiramos llamar el novato presun

tuoso"; es una persona que ha tenido que ver con uno o dos proyectos de desarrollo
de sistemas o (peor an) es un usuario que posee una computadora personal y que
ha escrito uno o dos (uf!) programas en BASIC. Por lo comn, alega saber exacta
mente lo que quiere que el sistema haga y suele sealar todos os errores que el
analista cometi en el ltimo proyecto. Esto est bien, excepto por una cosa: a me
nudo se enzarza demasiado en discusiones sobre ia tecnologa especfica que se
usar para realizar el sistema. Por eso, el usuario pudiera decirle al analista: Nece
sito un nuevo sistema de procesamiento de pedidos y quiero que se construya con
una red local que conecte a nuestras PCs IBM, y creo que debiramos usar dBASEIII o PC-FOCUS. A la larga, stas pudieran resultar ser las decisiones tcnicas co
rrectas, pero es prem aturo c o n sid erar siq uiera el hardw are, el lenguaje de
programacin o ios paquetes de base de datos antes de documentar los verdaderos
requerimientos del sistema. De hecho, en un caso extremo, la sugerencia del usua
rio acerca del hardware y software apropiados pudiera convertirse en una solucin
en busca de problema , es decir, el descubrimiento de que se tienen recursos de
hardware y software poco utilizados a los que se les pudiera dar otro uso.
Desde luego, hay algunos usuarios que realmente entienden el anlisis de sis
temas, y tambin la tecnologa de las computadoras (adems de su propia profe
sin). Es un placer trabajar con tales personas; de hecho, el nico problema pudiera
ser que el usuario y el analista obtengan tal placer de ia discusin sobre herramien
tas y tcnicas del anlisis de sistemas, que se olviden por completo de que su ver
dadero objetivo es implantar un sistema.8
3.2
ADMINISTRACION
El trmino administracin es bastante amplio; de hecho, es probable que el

analista de sistemas entre en contacto con diversos tipos de administradores:
Administradores usuarios. Son administradores que estn a cargo de va

rias personas en el rea operacional donde se va a implantar el nuevo
sistema. Esto se discuti anteriormente. Por lo general son administra
dores de nivel medio que desean sistemas que produzcan una variedad
de informes internos y de anlisis a corto plazo. Los informes internos
suelen ser informes financieros, operacionales, de fallas, y otros por el
estilo.
8 Tam bin levanta el nim o ve r que cada vez hay m s de estos exp e rto s que estn legando a
o cu p ar puestos altos en ia a d m in istra ci n de o rg a n iza cio n e s de negocios, y posiciones clave en
o tras partes de nuestra sociedad. C itib a n k y Am erican A irlines, adem s de alg u n as otras com pa
as y organizaciones de alta tecnologa, estn dirig id as por personas que ascendieron a travs de
los rangos del procesam iento de datos. Hacia m ediados de ia dcada de los 80, haba aproxim ada- ;
mente m edia docena de m iem bros dei C ongreso de ios Estados U nidos con a ntecedentes de pro
gram acin y anlisis.
www.FreeLibros.org
Administradores de informtica. Son las personas encargadas del pro

yecto en s de sistemas, y los administradores de nivel superior encarga
dos de la administracin global y distribucin de los recursos de todo el
personal tcnico de la organizacin de creacin o desarrollo de sistemas.
Administracin general. Son ios administradores de nivel superior que no

estn directamente involucrados con la organizacin de informtica ni son
de ia organizacin usuaria. Pudiera ser ei presidente de la organizacin o
ei jefe de administracin financiera (el contralor, el director de finanzas,
etc.). Generalmente se interesan ms bien por los sistemas de planeacin estratgica y de apoyo a decisiones que se discutieron en el captulo
2. A pesar de que ia administracin superior s requiere informes finan
cieros internos, no suele necesitar la cantidad de detalles que ocupan los
administradores usuarios (sobre todo en el rea de informes de fallas).
Adems, se concentran ms en la informacin externa: reglas guberna
mentales, informes de la competencia por el mercado, informes sobre
nuevos productos y mercados, etc.
La principal interaccin entre el analista de sistemas y todos estos administra

dores tiene que ver con los recursos que se asignarn al proyecto. Es tarea del analisia identificar y documentar los requerimientos del usuario y las limitaciones dentro
de las cuales se tendr que implantar el sistema. Por lo comn, estas limitaciones
son los recursos: personas, tiempo y dinero. De aqu que finalmente el analista har
un documento que diga: El nuevo sistema deber llevar a cabo las funciones X, Y y
Z, y deber desarrollarse en seis meses, con no ms de tres programadores y con
un costo mximo de 100,000 dlares
Obviamente, ia administracin querr que se le asegure que el proyecto de de
sarrollo del sistema se est manteniendo dentro de estos mrgenes; es decir, que no
se est atrasando ni est rebasando el presupuesto. Pero esto es un asunto de la
administracin de proyectos, no del anlisis de sistemas,9 Los administradores de
ias diferentes reas funcionales suelen formar un comit directivo que ayuda a clasi
ficar por prioridades los proyectos de desarrollo potencial, de manera que se lleven a
cabo primero los ms costeables.
Hay varios puntos que conviene tener en mente acerca de los administradores:
Cuanto ms alto nivel ocupen menos probable es que sepan (o que les
importe saber) de la tecnologa de las computadoras. Aunque esto sea
una generalizacin, suele ser vlida, dada la generacin actual de admi
nistradores superiores. Esto no debiera afectarle a usted como analista
(es ms difcil la labor de los diseadores de sistemas), pero debe recor
www.FreeLibros.org
9 Sin em bargo, en ocasiones el analista puede estar m uy involucrado con la adm inistracin. Discu
tirem os esto con ms detalle en el captulo 16, al igual que en el apndice B.
dar que ha de concentrarse en tratar de las caractersticas esenciales del

sistema cuando est hablando con ellos.
Las metas y prioridades de la administracin pudieran entrar en conflicto

con las de los usuarios, sobre todo las de los usuarios operacionales y los
usuarios supervisores. La administracin pudiera incluso querer imponer
les un sistema y obligarlos a usarlo (por ejemplo, si la organizacin usua
ria no ha podido responder a los cambios en el mercado o si no ha
resultado lucrativa).
Una variante de lo anterior es la siguiente; pudiera ser que la administra

cin no est dando los recursos, los fondos o el tiempo que los usuarios
crean necesarios para implantar un sistema efectivo. Es cmodo para el
analista y el usuario, en este caso, responder a esto que la administra
cin no entiende", pero a menudo se trata de una decisin consciente y
calculada. En el Apndice B se trata ms a fondo el tema de la poltica
de programacin y financiamiento de recursos.
El trmino administracin da a entender un grupo homogneo de perso

nas que piensan todas de la misma manera; desde luego, la realidad sue
le ser muy diferente. Los administradores tienen diferentes puntos de
vista y opiniones, y a menudo tienen diferentes metas y objetivos. Discu
ten y compiten unos con otros. Por esto, pudiera suceder que algunos
miembros de la administracin estn a favor del nuevo sistema y otros es
tn rotundamente en contra. Y la indiferencia que sufren algunos proyec
tos es an peor; finalmente mueren tras aos de rodeos y rodeos.
Tambin es cmodo suponer que una vez que la administracin toma una
decisin colectiva acerca de un determinado proyecto se atiene a dicha
decisin. Sin embargo, no necesariamente sucede as: pudiera ser que
fuerzas externas obliguen a la administracin a acelerar determinado pro
yecto, a quitarle recursos o, de plano, abandonarlo. Esto suele causar
una depresin emocional enorme a los que intervienen en el proyecto, in
cluyndolo a usted como analista.
La relacin entre su proyecto de desarrollo de sistemas y la administracin pu

diera depender en gran medida de la estructura administrativa global de su organiza
cin, sobre todo de la relacin de las actividades del desarrollo de sistemas con el
resto de la organizacin. La figura 3.2(a) muestra la estructura organlzacional clsi
ca. Ntese que toda la organizacin de procesamiento de datos rinde cuentas al je
fe de finanzas y contabilidad. La razn de esto es que muchas organizaciones
grandes originalmente introdujeron las computadoras para automatizar su contabili
dad (nminas, libro mayor y cuentas).
www.FreeLibros.org
Desde la dcada de los 70, algunas organizaciones empezaron a darse cuenta

de que esta estructura organlzacional era bastante desproporcionada; garantizaba
que el proceso de datos estuviera enfocado ms bien a aplicaciones contables y que

tuviera entonces poco que ver con otras partes de ia organizacin. Adems, al em
pezar a implantar ei proceso automatizado de datos (por ejemplo, en la manufactura,
la comercializacin y ia ingeniera), algunas organizaciones cambiaron al esquema
www.FreeLibros.org
mostrado en la figura 3.2(b), Al obligar al grupo de proceso de datos a informar di

rectamente al presidente de la organizacin, es obvio para todos que el proceso de
datos se vuelve tan crtico para la supervivencia de la organizacin como la manu
factura, la ingeniera, las ventas, etc.
Sin embargo, para la dcada de los 80, en algunas organizaciones ya haban
empezado a darse cuenta de que el departamento de proceso de datos se haba
convertido en un imperio , con sus propias polticas y prioridades; mientras tanto,
las organizaciones usuarias se encontraron con que tenan toda una lista de nuevos
proyectos retrasados en espera de ser desarrollados por el departamento de infor
mtica.10 Esto coincidi con la introduccin y proliferacin de computadoras perso
nales potente s y baratas. Por e llo, en algunos departam entos de usuarios
empezaron a pensar que podan desarrollar sus propios sistemas, sin depender de
una funcin centralizada. Como resultado de eso, algunas organizaciones tienen
ahora una estructura como la que se muestra en la figura 3.2{c). Aunque an existe
un departamento central de proceso de datos o informtica para aplicaciones clsi
cas tales como la nmina y el libro mayor, buena parte del proceso departamental lo
llevan a cabo grupos de desarrollo de sistemas dentro de ios departamentos.
Si trabaja para una organizacin por el estilo de la descrita por la figura 3.2(a),
puede encontrarse con que el analista de sistemas y los usuarios de los otros depar
tamentos no son tan buenos como deberan; de hecho, es probable que descubra
que la mayora de los proyectos de desarrollo de sistemas son de proceso de tran
sacciones, como ios que pudiera encontrarse en un departamento de contabilidad.
Si su organizacin se asemeja ms a la de la Figura 3.2(b), hay una buena probabili
dad de que su grupo de desarrollo de sistemas tenga una razonable vistosidad po
ltica en los altos rangos de la empresa; sin embargo, tambin pudiera detectar una
creciente frustracin por el rezago de los nuevos sistemas en espera de desarrollo.
Y si trabaja en una empresa caracterizada por la figura 3,2(c), es probable que tenga
mucho ms contacto directo con los usuarios de su sistema; de hecho, pudiera ser
que les rinda cuentas directamente a ellos. Y es ms probable que llegue a trabajar
con computadoras personales y en pequeas redes de sistemas computacionales,
comprados directamente por el departamento del usuario.
3.3
AUDITORES, CONTROL DE CALIDAD Y DEPARTAMENTO DE

NORMAS O ESTANDARES
Segn sea el tamao de su proyecto y la naturaleza de la organizacin para la

que trabaja, pudiera haber auditores, personal de control de calidad o miembros del
departamento de normas o estndares participando en su proyecto. Se ha agrupado
a estas personas en una sola categora porque su objetivo y perspectiva se parecen
en general, si no es que son iguales.
www.FreeLibros.org
10 D iscutirem os el retraso en ia creacin de las a p licaciones con ms de talle en el ca p tulo 6.
Figura 3.2{b): Un esquema ms com n de organizacin
El objetivo general de este equipo revuelto es asegurar que su sistema se de

sarrolle de acuerdo con diversos estndares o normas externos (es decir, externos a
su proyecto): estndares de contabilidad desarrollados por la agencia contable de su
organizacin, estndares desarrollados por otros departamentos de su organizacin
o por el usuario que recibir su sistema; y posiblemente estndares impuestos por di
versas dependencias gubernamentales reguladoras.
www.FreeLibros.org
Figura 3,2(c): El d e s a rrollo de sistem as dentro de las organizaciones usuarias
Hay tres problemas que debe prever, cuando est trabajando con auditores,
personal de control de calidad o miembros del departamento de normas o estn
dares:
www.FreeLibros.org
1.
A menudo no se involucran sino hasta el final en el proyecto. Despus de

que se ha terminado con el trabajo del anlisis del sistema, el diseo y la
programacin, cuando se ha comenzado con la prueba formal. A estas
alturas, por supuesto, es muy difcil hacer cambios importantes en el sis

tema.
2.
A menudo estn familiarizados con alguna notacin o formato antiguos

para documentacin de requerimientos de sistemas (diagramas de flujo).
Por eso, es importante asegurarse de que los modelos del sistema que
usted desarrolle sean comprensibles (vase el captulo 4).11
3.
Por desgracia, los miembros de este grupo a menudo se interesan ms

por la forma que por el contenido: si sus documentos no tienen la presen
tacin exacta que se exige pudieran ser rechazados.
EL ANALISTA DE SISTEMAS
3.4
Este es usted. El analista de sistemas es el personaje clave en cualquier pro

yecto de desarrollo de sistemas, y en otras partes de este Captulo ya se ha mostra
do la manera en la que ei analista interacta con otros participantes del juego.
En un sentido ms amplio, el analista desempea varios papeles:
Arquelogo y escribano. Como analista, una de sus principales labores

es descubrir detalles y documentar la poltica de un negocio que pudieran
existir slo como tradiciones tribales transmitidas de generacin a gene
racin por los usuarios.
Innovador. El analista debe distinguir entre sntomas, problemas del usua

rio y causas. Con sus conocimientos de la tecnologa de las computado
ras, el analista debe ayudar al usuario a explorar aplicaciones novedosas
y ms tiles de las computadoras as como formas nuevas de hacer nego
cios. Aunque muchos de los sistemas antiguos slo se limitaban a perpe
tuar el negocio original del usuario, pero a velocidades electrnicas, hoy
en da los analistas se enfrentan al desafo de ayudar al usuario a encon
trar productos y mercados radicalmente innovadores, con la ayuda de la
computadora. Pudiera ser aconsejable que lea la obra Lateral Thinking,
de Edward De Bono [De Bono, 1970], para conocer formas nuevas e inte
resantes de considerar los problemas.
Mediador. Como se mencion anteriormente en este captulo, el analista

a menudo se encuentra en medio, entre usuarios, administradores, pro
gramadores, auditores y otros diversos participantes, los cuales frecuen
temente estn en desacuerdo entre s. Es tentador para el analista
www.FreeLibros.org
11 Sin em bargo, en por io m enos algunos casos, esto est cam biando. Por ejem plo, m uchas de las
ocho grandes em presas con tab le s de los Estados U nidos ya estn bien fa m ilia riza d a s con ias he
rram ientas de docum entacin del anlisis estructurado descritas en este captulo; por eso no debie
ran tener problem a alguno en p a rticip a r com o au d itore s de alguno de sus proyectos.
imponer su propia opinin respecto a cmo debe ser el sistema o cules

funciones debe cumplir. Pero su labor primordial es obtener un consenso
y esto requiere del delicado arte de la diplomacia y la negociacin.
Jefe de proyecto. Este no es un papel universal, pero aparece con la sufi

ciente frecuencia como para ser digno de mencionarse aqu. Dado que el
analista suele tener ms experiencia que los programadores que laboran
en el proyecto y dado que se le asigna al mismo antes de que ellos em
piecen a trabajar, hay una tendencia natural a asignar al analista las res
ponsabilidades de la administracin ntegra.
Esto significa que, como analista de sistemas, se necesita ms que simple habilidad para dibujar diagramas de flujo y otros diagramas tcnicos. Se requiere faci
lidad en el manejo de personas para poder entrevistar a los usuarios, mediar en
desacuerdos y sobrevivir a las inevitables batallas polticas que se dan en todos los
proyectos excepto los ms triviales. Se necesita tener conocimientos de aplicacin
para entender y apreciar los asuntos del usuario. Se requiere habilidad en computa
cin para entender los usos potenciales dei hardware y el software en los asuntos
del usuario. Y (obviamente) se necesita una mente lgica y organizada: debe ser
capaz de ver un sistema desde diferentes perspectivas, debe poder dividirlo en nive
les de subsistemas y debe ser capaz de pensar en el sistema en trminos abstractos
adems de fsicos.12
jNadie dijo que iba a ser un trabajo fcil!
3.5
DISEADORES DE SISTEMAS
Como hemos dado a entender en discusiones anteriores, el diseador de sis

temas es quien recibe los resultados de su trabajo de anlisis: la labor de l es
transformar la peticin, libre de consideraciones de tecnologa, emanada de los re
querimientos del usuario, en un diseo arquitectnico de alto nivel que servir de ba
se para el trabajo de los programadores. En el captulo 22 se discutir la naturaleza
de esta labor.
En muchos casos, el analista y e! diseador son la misma persona o el mismo
grupo unificado de personas. Aun cuando sean personas distintas, es importante
que se mantengan en contacto directo a lo largo de todo el proyecto. La razn por la
cual se necesita esta retroalimentacin continua entre diseador y analista es la si
guiente: el analista tiene que ofrecer informacin detallada suficiente como para que
el diseador pueda elaborar un diseo tecnolgicamente superior y el diseador de
be proveer suficiente informacin para que el analista pueda darse cuenta de si los
www.FreeLibros.org
12 De hecho, es debido a este requisito de ser experto en m uchas reas, que la m ayora de los que
se dedican a la com putacin sienten que la in teligencia a rtificial y los sistem as e xpertos no se po
drn a p lica r ai a n lisis de sistem as por m uchos aos ms. Se discute esto ms a fondo en el cap
tulo 25.
requerimientos que del usuario est documentando son tecnolgicamente posibles.

en la informacin recibida, el analista posiblemente tendr que negociar
con el usuario para modificar otros requerimientos,
B a s n d o s e
3.6
LOS PROGRAMADORES
Se puede argumentar que en el mejor de los mundos no habra contacto entre

un analista y un programador. Sobre todo en los proyectos grandes de desarrollo de
sistemas, es probable que los diseadores funcionen como un amortiguador" entre
ios analistas y los programadores; es decir, los analistas entregan sus resultados
(una descripcin no tcnica de los requerimientos del sistema) a los diseadores,
quienes a su vez entregan los suyos (una descripcin arquitectnica del hardware y
software que se usar para poner en prctica el sistema) a ios programadores.
Existe otra razn por la cual el analista y el programador pudieran tener un
contacto muy reducido, o nulo, entre s: a menudo, se lleva a cabo el trabajo siguien
do una secuencia muy estricta en algunos proyectos de desarrollo de sistemas.13
Por eso, la labor del analista se hace primero y se termina por completo antes de
que comience la labor de programacin. Esto significa que el analista muy probable
mente estar incluso asignado ya a otro proyecto antes de que el programador inter
venga en el actual.
Sin embargo, es probable que s haya algn contacto entre programadores y
analistas, por lo siguiente:
En los proyectos pequeos, los papeles de analista, diseador y progra

mador se combinan, de tal manera que una sola persona hace tanto el
papel de analista como el de diseador y por tanto nteracta con el pro
gramador. O pudiera suceder que una sola persona realice la labor de di
seador y la de programador.
El analista a veces sirve de administrador del proyecto, as que aunque

haya concluido su labor de especificacin de los requerimientos del siste
ma, an estar Involucrado en el proyecto y tendr algn contacto con el
programador.
A menudo es el programador el que descubre errores y ambigedades en

la propuesta de requerimientos entregada por el analista, pues es du
rante la programacin, como dice mi colega Scott Guthery, cuando la
llanta se adapta al asfalto, donde una resea superficial de los requeri
mientos del sistema se traduce en un juego de instrucciones muy espec
ficas y detalladas de COBOL. Si algo falta, o est mal o confuso, el
www.FreeLibros.org
13 Discutirem os en el ca p tulo 5 algunas a lte rn a tiva s a este enfoque secuencia!, sobre to d o as co
nocidas com o de sa rro llo e volutivo o rastreo rpido. De hecho, en a lg u n os p royectos el anlisis
contina a la vez que se est llevando a cabo la program acin.
programador tiene dos opciones: pedirle una aclaracin ai analista o bien

preguntarle al usuario.14
Como se mencion en el captulo 2, muchas organizaciones se estn

viendo en la necesidad de reemplazar los sistemas operacionales origina
les que se crearon hace 20 aos. En la gran mayora de estos proyectos
de reemplazo, casi no hay documentacin que describa 1) cmo funciona
el sistema o, ms importante an, 2) qu es lo que se supone que el sis
tema debe hacer. Y dado que los sistemas tienen 20 aos de antigedad,
hay toda una nueva generacin de usuarios involucrados. Los usuarios
que nicialmente especificaron los requerimientos del sistema ya se jubila
ron o renunciaron, y la nueva generacin tiene pocas nociones sobre
esos requerimientos. A estas alturas, todas las miradas se vuelven hacia
el programador de mantenimiento, que ha estado manteniendo el sistema
durante los ltimos aos; es probable que ste tambin sea un trabajador
de segunda o tercera generacin, que nunca haya tenido contacto con los
diseadores y programadores que construyeron originalmente el sistema.
Como lo seala Nicholas Zvegintzov, (autor del boletn Software Maintenance News),
H asta ahora, el p rofesional cla ve de la com putacin era a l
guien que pudiera conocer lo suficiente acerca de las necesi
d a d e s de la s o rg a n iz a c io n e s c o m o p a ra e x p re s a rla s en
t rm in o s c o m p u ta c io n a le s . En el fu tu ro , ai co m p u te riz a rs e
irrevocablem ente nuestra sociedad, el profesional clave sera
a lguien que pueda a p render io suficiente acerca de los siste
m as com p u ta cio n a le s com o para expresarlos en trm inos hu
m a n o s. Sin ese a lg u ie n , h a b re m o s p e rd id o ei c o n tro l de
n u e stra sociedad. Ese alg u ie n es el in g e n ie ro a la inversa.
Los encargados del m antenim iento de softw are son los in g e
n ieros a la inversa de la sociedad.
Algunas organizaciones estn empezando a cambiar sus equipos de de

sarrollo de proyectos de una estructura vertical a una horizontal. La dis
tribucin tpica de responsabilidades (que se supone a lo largo de todo
este libro) implica que todas las tareas del analista se le asignen a una
sola persona (o a un solo grupo de personas); de manera similar, todas
las actividades de diseo se le asignan al diseador y todas las de pro
14 De hecho, el contacto directo entre el program ador y el usuario es ms com n de lo que pudiera
pensarse. En m uchos casos, el analista nunca llega a de scrib ir os d e talles de bajo nivel dei siste
ma, y los usuarios de alto nivel con los que se com unica el sistem a pudieran no e sta r ai tanto ni es
ta r interesados en dichos detalles. Por eso, a m enudo el program ador debe h a b la r directam ente
con el usuario de bajo nivel para de scu brir exactam ente qu es lo que se supone que debe hacer el
sistem a. Esto es im portante, pues m uchas organizaciones se quejan dei hecho de que el 50% de
sus proyectos de d e sarrollo de sistem as se dedican a las pruebas; pudiera suceder que el trabajo
que se hace con el pretexto de probar sea de hecho la labor de anlisis que se pudiera (y probable
m ente se debiera) haber hecho anteriorm ente.
www.FreeLibros.org
gramacin al programador. En la medida en que se cumpla esto, cierta

mente parecera que los analistas y los programadores tienen poco con
tacto entre s. No obstante algunas organizaciones estn empezando a
percatarse de que en esto existe un conflicto inherente: los analistas sue
len ser relativamente de alto nivel y de gran experiencia dentro de la em
presa; sin embargo se espera que ellos lleven a cabo no slo las labores
de alto nivel, tales como el establecimiento conceptual de los requeri
mientos del sistema, sino tambin labores de bajo nivel, como los engo
rrosos detalles de los requerimientos del usuario. Existe un conflicto
similar con los programadores, quienes tpicamente suelen ser empleados
menores y de menos experiencia. Una solucin sera darle al personal
tcnico superior (cuyo ttulo resulta ser el de analista) todas las tareas de
alto nivel: el anlisis de alto nivel de sistemas, ei diseo de alto nivel, y la
codificacin de los mdulos de alto nivel del sistema. Similarmente, a las
personas de nivel tcnico inferior se les dar tareas detalladas de bajo ni
vel en las reas de anlisis, de diseo y de programacin. En la medida
en que esto se siga, los analistas y los programadores mantendrn un
contacto cercano durante todo el proyecto; de hecho, cada uno har parte
del trabajo que anteriormente e corresponda ai otro. Esto se volver a
discutir en el captulo 23.
3.7
EL PERSONAL DE OPERACIONES
As como se pudiera argumentar que el analista nunca se encontrara con un

programador, pudiera argumentarse tambin que no necesitara tener contacto con el
personal de operaciones responsable del centro de cmputo, la red de telecomunica
ciones, la seguridad del hardware y del software, adems de la ejecucin de los pro
gramas, el montaje de ios discos y el manejo de la salida de las impresoras. Todo
esto sucede despus de haber sido tanto analizado y diseado como programado y
probado el sistema.
Sin embargo, hay ms de lo que parece a simple vista: el analista debe enten
der las restricciones impuestas ai nuevo sistema por ei personal de operaciones,
pues esto influye en la especificacin detallada que produzca. Es decir, el analista
pudiera elaborar un documento que diga: el nuevo sistema de pedidos deber ser
capaz de llevar a cabo las funciones X, Y y Z y. para poder satisfacer ios requisitos
impuestos por el departamento de operaciones, no debe de ocupar ms de 16 megabytes de memoria de la computadora principal. El sistema debe implantarse utili
zando term inales IBM 3270 e stn da r com unicadas con la red X Y Z de
telecomunicaciones de la compaa.
En algunos casos, los detalles operacionales del sistema pudieran reducirse a
una cuestin de negociacin entre el usuario y el grupo central de operaciones de la
computadora. Esto es muy comn hoy en da, dado que a menudo los usuarios es
tn en posibilidades de adquirir sus propias computadoras personales o minicompu
www.FreeLibros.org
tadoras de tamao apropiado para sus departamentos. A pesar de que la mayora

de estas computadoras pueden ser utilizadas por oficinistas o personal administrati
vo de la organizacin usuaria (es decir, no se requiere personal que tenga la especializacin del de operaciones), y a pesar de que muchas de ellas pueden trabajar
en un ambiente normal de oficina (es decir, que no requieren del sistema especial de
conexiones y del aire acondicionado que necesitan las grandes mquinas), an sue
le resultar que estas computadoras pequeas tendrn que comunicarse con la com
putadora principal (por ejemplo, para bajar parte de una base de datos o para subir
os resultados de un clculo departamental), y a menudo resultar que las PC o
computadoras personales pequeas o las minicomputadoras tendrn que comunicar
se entre s a travs de una red local o de algn otro sistema de telecomunicaciones.
Todo esto implica usualmente la interaccin con el personal de operaciones; sin su
aprobacin slo se podra construir un sistema realmente independiente.
Estos asuntos operacionales se documentan como parte de la tarea del anli
sis conocida como modelo de puesta en prctica o implantacin del usuario. Esto se
cubre con detalle en el captulo 21.
3.8
RESUMEN
Como se vio en este Captulo, el analista de sistemas es un orquestador, un

comunicador y un facilitador. En las Partes II y III se har evidente que el analista
lleva a cabo una gran cantidad de trabajo l solo, pero que realiza aun ms trabajo
en armona con los dems participantes del juego de los sistemas. Como analista,
cuanto ms conozca acerca de las personas con las que trabaje tanto mejor le ir.
Todos los participantes son personas y tienen diferentes metas, prioridades y
perspectivas. Aunque pudieran estar pblicamente comprometidos con el xito del
proyecto podran tener razones ocultas para oponerse a uno o ms aspectos de ste.
Las preguntas y ejercicios al final de este Captulo tienen como propsito ha
cerle pensar ms acerca de estos temas. Tal vez desee consultar el excelente libro
de Bock que trata de la poltica de los proyectos [Block, 1982] o incluso la obra cl
sica de Sun Tzu sobre el arte de la guerra [Tzu, 1983],
REFERENCIAS
1. Paul Strassman, Information Payoff. Nueva York: Free Press, 1985.
2. Robert Block, The Politics of Projects. Nueva York: YOURDON Press, 1982.
3. Alan Bril, Building Controls into Structured Systems. Nueva York: YOURDON
Press, 1982.
4. Sun Tzu, El arte de la guerra. Nueva York: Delacorte Press, 1983.
www.FreeLibros.org
5, Edward De Bono, Lateral Thinking. Nueva York: Penguin Books, 1970.

S,
Marjorie Leeson, Systems Anlisis and Design. Chicago: Science Research As

sociates, 1981.
7 . Lavette C. Teague, Jr. y Christopher Pidgeon, Structured Analysis Methods

for Computer Information Systems. Chicago: Science Research Associates,
1985.
PREGUNTAS EJERCICIOS
1. Mencione por io menos un participante adicional con el que pudiera interactuar
en un proyecto de desarrollo de sistemas.
2. Describa un proyecto en el cual el analista no tenga contacto directo con el ver
dadero usuario. Cules son las ventajas y desventajas de esta situacin?
Qu otros arreglos alternos pudieran haberse hecho?
3. Se le ocurre algn otro trmino que pueda usarse para el usuario, adems de
propietario o cliente?
4. Se le ocurre alguna situacin donde el analista no debiera hablar con el usua
rio?
5. Qu ventajas y desventajas se tendran al ser el usuario miembro de tiempo
completo del equipo del proyecto de desarrollo del sistema? Se le ocurre al
gn proyecto especfico en el que sera particularmente positivo incluir a un
usuario en el equipo?
6. Cules son las ventajas y desventajas de que el usuario sea administrador del
equipo encargado del proyecto de desarrollo del sistema? Se le ocurre algn
proyecto especfico donde fuera muy positivo tener de administrador del proyec
to a un usuario?
7. Cules son las ventajas y desventajas de que el usuario desarrolle el sistema
de informacin l solo? Se le ocurre algn proyecto donde fuera bueno que ei
usuario hiciera las veces de analista, diseador, programador y administrador?
8. Cunto tendra que saber el usuario de computadoras y software para poder
participar en un equipo de proyecto durante la fase de anlisis del sistema?
Cunto tendra que saber de las herramientas y tcnicas del anlisis de siste
mas?
9. Cunto tendra que saber un usuario acerca de las computadoras y ei software
para poder adm inistrar un equipo de proyecto de desarrollo de sistemas?
Cunto necesitara saber acerca del anlisis de sistemas para ser buen admi
nistrador?
www.FreeLibros.org
10. Cunto debe saber un usuario de computadoras y software para poder llevar a
cabo l solo un proyecto de desarrollo de sistemas? Cunto debiera saber
acerca del anlisis de sistemas?
11. Qu precauciones especiales tomara como analista de sistemas si no tuviera
contacto directo con el usuario? Cree que seran suficientes las herramientas
descritas en este libro?
12. En la seccin 3.1.2 se mencionan varias de las preocupaciones que pudiera te
ner el usuario operacionai acerca de un sistema nuevo. Mencione las tres ms
probables. Cree que estas preocupaciones son razonables o que slo reflejan
la tpica falta de familiaridad del usuario con las computadoras?
13. Qu responsabilidad tica y moral tiene el analista con el usuario operacionai
si el primero est convencido de que no causar despidos, pero el usuario se
preocupa por la posibilidad de que s los cause? (Vase tambin ia pregunta
19}
14. Describa el escenario en el que los usuarios operacionales pudieran ocasionar
que un nuevo sistema no funcione. Cree que su escena sea realista? No
podra el usuario supervisor simplemente ordenar que se use el sistema?
15. Cundo cree que deban discutirse con los usuarios ios asuntos relacionados
con la interfaz humana? Al comienzo del proyecto? A finales de ste?
Cul es la interaccin indicada? (Puede consultar el captulo 21 si lo desea}.
16. Cree que sea poco realista que los usuarios operacionales tengan slo un pa
norama local del sistema en el que participan? Cree que sea seguro para el
analista dar por un hecho esto? Cree que esto sea positivo? Debiera tratar
el analista de proporcionar un panorama global a los usuarios operacionales?
17. D un ejemplo del panorama fsico de un sistema o de su implantacin, que pu
diera tener el usuario operacionai. Le encuentra algn problema a esto?
18. Qu debe hacer el analista si el usuario supervisor no le permite hablar direc
tamente con ios usuarios operacionales? Cmo puede el analista manejar esta
situacin?
19. Qu responsabilidad tica o moral tiene el analista con el usuario supervisor si
los usuarios operacionales le expresan su preocupacin acerca de posibles
despidos ocasionados por el nuevo sistema? (Vase la pregunta 13.)
20. D un ejemplo de un sistema en el que el usuario supervisor pueda no estar fa
miliarizado con la poltica detallada de negocios a la que se estn ateniendo los
usuarios.
www.FreeLibros.org
21. Por qu los usuarios tpicos del nivel ejecutivo normalmente no se interesan
por el posible ahorro que representara la reduccin del personal, que se har
posible con la puesta en prctica o la implantacin del nuevo sistema?
22. Qu tanto se deben involucrar los usuarios del nivel ejecutivo en el desarrollo
de un nuevo sistema de informacin?
23. Qu opciones tiene ei analista si el usuario no entiende los modelos abstrac
tos en el papel?
24. Cmo deber hacerse cargo el analista del novato presuntuoso" descrito en
este captulo? Qu hacer si el usuario insiste en un determinado hardware o
software para el nuevo sistema?
25. Qu tanta responsabilidad debe asumir el analista por la obtencin del con
senso de los usuarios? Qu tal si el analista no logra hacerlo?
28. Qu riesgos cree que afronta el analista provenientes de la administracin, se
gn se expuso en la seccin 3.2? Qu puede hacer el analista para minimizar
estos riesgos?
27. Qu debe hacer el analista si las metas y prioridades de la administracin en
tran en conflicto con las de los usuarios?
28. Cundo cree que deba hacerse participante en proyecto a la gente de opera
ciones?
29. Debe la misma persona (o el mismo grupo de personas) llevar a cabo tanto el
anlisis como el diseo (y ia programacin) del sistema? Cules son las ven
tajas y desventajas?
www.FreeLibros.org
HERRAMIENTAS BEL
ANALISIS ESTRUCTURAS
La naturaleza cuenta con una especie de sistem a coordenado geomtrico-aritm tico, pues tiene toda clase de modelos. Nuestra experien
cia de ia n a tu ra le z a es p o r m e d io de m o d e lo s y to d o s son m uy
hermosos. Me di cuenta de que el sistem a de la naturaleza debe ser
una verdadera belleza, pues encontram os en qum ica que las asocia
ciones siem pre se dan en lindos nm eros enteros. No hay fracciones.
R. B uckm inster F uller
De In The O utlaw Area: Profile by
C alvin T o m kin s (En zona proscrita: sem blanza por Calvin T om kins),
The N e w Yorker, 8 de enero de 1966.
El hom bre es un anim al que em plea h e rra m ien ta s... Sin ellas nada
es, con e llas lo es todo.
T hom as C arlyle,
S a rto r Resartus, T om o I, ca p tulo 4.
En este captulo se aprender:

1. Para qu utiliza las herramientas de modelado un
analista.
2. La naturaleza y componentes de un diagrama de
flujo de datos.
3. Los componentes de un diccionario de datos.
4. Los componentes de una especificacin de proceso.
5. Cmo modelar datos almacenados y relaciones
entre datos.
6. Cmo modelar el comportamiento dependiente del
tiempo de un sistema.
7. Cmo modelar la estructura de un programa de
computadora.
www.FreeLibros.org
72
HERRAMIENTAS DEL ANALISIS ESTRUCTURADO 73
G r a n parte de la labor que desempear como analista involucra el modela

ba d e l sistema que desea ei usuario. Como veremos en este captulo y con ms de
pile en la parte II, hay muchos tipos diferentes de modelos que podemos elaborar,
aS c o m o hay muchos modelos diferentes que puede hacer de una casa nueva un ar
q u it e c t o .
Los modelos de anlisis de sistemas que se discuten en este libro son, en
su mayora, modelos en papel del futuro sistema, es decir, representaciones abstraetas de lo que al final ser una combinacin de hardware y software de computadora.
El trmino modelo pudiera parecerle algo formal y atemorizante, pero repre
senta un concepto que usted ha manejado durante la mayor parte de su vida. Consi
dere los siguientes tipos de modelos:
Mapas: modelos bidimensionales de nuestro mundo en que vivimos.
Globos terrqueos: modelos tridimensionales de nuestro mundo.
Diagramas de flujo: representaciones esquemticas de las decisiones y la

secuencia de actividades para llevar a cabo un determinado procedimiento.
Dibujos arquitectnicos: representaciones esquemticas de un edificio, o

de un puente, etctera.
Partituras musicales: representaciones grficas y textuales de notas musi

cales y tiempos de una pieza musical.
Aunque no sepa leer el modelo arquitectnico que se muestra en la figura 4.1, el

concepto de dicho modelo no debera asustarle; no es demasiado difcil imaginarse
que pudiera aprender a leer y entender tales modelos, aun si jams piensa crear uno
usted mismo. De manera similar, probablemente no sepa an leer o interpretar mu
chos de los modelos usados por los analistas de sistemas, pero sabr leerlos y
crearlos cuando termine de leer este libro. Los usuarios con los que trabaja podrn
ciertamente leer los modelos (con una pequea ayuda inicial) y pudieran incluso ser
capaces de crearlos.
Por qu construimos modelos? Por qu no se construye simplemente e!
sistema mismo? La respuesta es que podemos construir modelos de manera tal que
enfatizamos ciertas propiedades crticas del sistema, mientras que simultneamente
desacentuamos otros de sus aspectos. Esto nos permite comunicarnos con el usua
rio de una manera enfocada, sin distraernos con asuntos y caractersticas ajenas al
sistema. Y si nos damos cuenta de que nuestra comprensin de ios requerimientos
del usuario no fue la correcta (o de que el usuario cambi de parecer acerca de sus
requerimientos), podemos hacer cambios en el modeio o desecharlo y hacer uno
nuevo, de ser necesario. La alternativa es tener algunas reuniones preliminares con
el usuario y luego construir todo el sistema; desde luego, existe el riesgo de que el
producto final no sea aceptable, y pudiera ser excepcionalmente costoso hacer un
cambio a esas alturas.
www.FreeLibros.org
74 HERRAMIENTAS DEL ANALISIS ESTRUCTURADO
Por esta razn, el analista hace uso de herramientas de modelado para:
Concentrarse en las propiedades importantes del sistema y al mismo

tiempo restar atencin a otras menos importantes.
Discutir cambios y correcciones de los requerimientos del usuario, a bajo

costo y con el riesgo mnimo.
Verificar que el analista comprenda correctamente el ambiente del usua

rio y que lo haya respaldado con informacin documenta! para que los di- |
senadores de sistemas y los programadores puedan construir el sistema.
No todas las herramientas de modelado cumplen con estos propsitos: por

ejemplo, una descripcin narrativa de 500 pginas de los requerimientos del usuario
{que es, grosso modo, un modelo) podra 1) Contribuir a obscurecer todas las pro
piedades del sistema, 2) Costar ms en su elaboracin que el sistema mismo y 3) no
verificar si el analista comprendi o no las necesidades reales del usuario. En el ca
ptulo 8 se explorarn con ms detalle las caractersticas que debe tener una herra
mienta de modelado para serle til al analista.
Ahora, presentaremos y discutiremos brevemente tres herramientas de mode-
lado de sistemas importantes: el diagrama de flujo de datos, el diagrama de entidad- j
relacin y el diagrama de transicin de estados. El diagrama de flujo de datos ilustra j
las funciones que el sistema debe realizar; los diagramas de entidad-relacin hacen|;
nfasis en las relaciones entre los datos y el diagrama de transicin de estados se f
www.FreeLibros.org
enfoca al comportamiento dependiente del tiempo del sistema. Los captulos 9 al

16 tratan estas y otras herramientas con ms detalle. Como veremos, las tres herra
mientas principales consisten en grficas (imgenes) y herramientas textuales adi
cionales. Las grficas proporcionan una manera fcil de leer para que el analista
pueda mostrarle a los usuarios las principales componentes del modelo, al igual que
ias conexiones (o interfases) entre componentes. Las herramientas de modelado
textuales adicionales presentan definiciones precisas del significado de los compo
n e ntes y conexiones.
4.1
MODELADO DE LAS FUNCIONES DEL SISTEMA:

EL DIAGRAMA DE FLUJO DE DATOS
Un viejo adagio de la profesin de desarrollo de sistemas dice que un sistema

de proceso de datos involucra tanto los datos como el proceso, y no se puede cons
truir un sistema exitoso sin considerar ambos componentes. El aspecto de proce
so de un sistema ciertamente es algo importante de modelar y de verificar con el
usuario. El modelado que llevamos a cabo puede describirse en una variedad de
maneras:
Con qu funciones debe desempear ei sistema? Cules son las inte

racciones entre dichas funciones?
Qu transformaciones debe llevar a cabo el sistema? Qu entradas se

transforman en qu salidas?
Qu tipo de labor debe realizar ei sistema? De dnde obtiene ia infor

macin para llevar a cabo dicha labor? Dnde entrega ios resultados de
su labor?
La herramienta de modelado que utilizamos para describir la transformacin

de entradas a salidas es un diagrama de flujo de datos. En la figura 4.2 se muestra
un diagrama de flujo de datos tpico.
Los diagramas de flujo de datos consisten en procesos, agregados de datos,
flujos y terminadores:
Los procesos se representan por medio de crculos, o burbujas , en el

diagrama. Representan las diversas funciones individuales que ei siste
ma lleva a cabo. Las funciones transforman entradas en salidas.
Los flujos se muestran por medio de flechas curvas. Son las conexiones
entre los procesos (funciones del sistema) y representan la informacin
que dichos procesos requieren como entrada o la informacin que gene
ran como salida.
www.FreeLibros.org
Los agregados de datos se representan por medio de dos lneas paralelas

o mediante una elipse. Muestran colecciones (o agregados) de datos que
CLIE N T E S
Pedidos
cancelados
BO DEG A
Contabilidad
Nom bre del

oliente, detalles
de a factura
Figura 4.2: Un diagram a de flu jo de datos tp ico
ei sistema debe recordar por un periodo de tiempo. Cuando los diseado

res de sistemas y los programadores terminan de construir el sistema, los
agregados existirn como archivos o bases de datos.
Los erminadores muestran las entidades externas con las que el sistema
se comunica. Tpicamente se trata de individuos o grupos de personas
(por ejemplo, otro departamento o divisin dentro de la organizacin), sis
temas de cmputo externos y organizaciones externas.
Los diagramas de flujo de datos se discuten con ms detalle en el captulo 9.

(Adems de los procesos, flujos y agregados, un diagrama de flujo de datos puede
tener tambin flujos de control, procesos de control, y agregados de control. Estos
resultan tiles para modelar los sistemas de tiempo real y se discuten con ms deta
lle en el captulo 9.)
Aunque el diagrama de flujo de datos proporciona una visin global bastante
conveniente de los componentes funcionales del sistema, no da detalles de stos.
Para mostrar detalles acerca de qu informacin se transforma y de cmo se trans
forma, se ocupan dos herramientas textuales de modelado adicionales: El dicciona-
www.FreeLibros.org
ro de datos y la especificacin de procesos. La figura 4.3 muestra un diccionario de

datos tpico para el diagrama de flujo de datos que vimos en la figura 4.2. De mane
j similar, la figura 4.4 muestra una especificacin de proceso tpica para un solo
p ro c e s o del diagrama de flujo de datos de la figura 4.2.
Nombre =
Tratam iento de cortesa o ttu lo + nom bre

+ apellidos
Tratam iento de
cortesa o ttu lo =
[Sr. I Srta. I Sra. I Dr. I Prof.]
Nombre =
{carcter vlido}
A pellido =
{carcter vlido}
Carcter vlido =
[A-Z I a-zl I - I I]
Figura 4.3: Un d iccio n a rio de datos tpico

1.
2.
3.
Si el monto en dlares de la factura multiplicado por el nmero de sema

nas de retraso en el pago rebasa los 10,000 dlares ENTONCES:
a.
Proporcionar una fotocopia de la factura al encargado de ventas que

llamar al cliente.
b.
Anotar en el reverso de la factura que se le dio una copia al vende

dor, junto con la fecha en la que se hizo esto.
c.
Volver a archivar la factura para estudiarla de nuevo dentro de dos

semanas.
EN CASO CONTRARIO, Si se han enviado ms de cuatro recordatorios

ENTONCES:
a.
Dar una copia de la factura al vendedor apropiado para que llame al

cliente.
b.
Registrar en el reverso de la factura que una copia ha sido enviada

al vendedor, y la fecha en la que se hizo esto.
c.
Volver a archivar la factura para reexaminarla dentro de una semana.
EN CASO CONTRARIO (la situacin an no ha alcanzado proporciones

serias):
a.
Aadir 1 al contador de avisos de moratoria registrado en el inverso

de la factura (si no se ha registrado tal contador, escribir: cuenta
vencida de avisos de moratoria = 1 )
www.FreeLibros.org
b.
SI la factura archivada es ilegible ENTONCES mecanografiar una

nueva.
c.
Enviar una copia de la factura al cliente, con ei sello: n-simo aviso:

pago de factura vencido. Favor de remitir inmediatamente, donde n
es el valor de avisos de moratoria.
d.
Registrar en el reverso de la factura la fecha en la que se envi el nsimo aviso de moratoria.
e.
Volver a archivar la factura para examinarla dentro de dos semanas.

Figura 4.4: E specificacin de proceso tpica
Queda mucho que decir acerca de los diagramas de flujo de datos, ios diccio
narios de datos y las especificaciones de procesos; en los captulos 9 a 11 se pre
sentan ms detalles de esto. Veremos, por ejemplo, que la mayora de los sistemas
complejos se modelan con ms de un diagrama de flujo de datos; de hecho, pudiera
haber docenas o centenares de diagramas, acomodados de acuerdo con niveles de
jerarqua. Y veremos tambin que hay convenciones para la manera de etiquetar y
numerar los elementos del diagrama, y tambin hay guas y reglas que permiten dis
tinguir entre diagramas buenos y malos.
4.2
EL MODELADO DE DATOS ALMACENADOS: EL DIAGRAMA

DE ENTIDAD-RELACION
Aunque el diagrama de flujo de datos es una herramienta muy til para mode
lar sistemas, slo resalta un aspecto principal de un sistema: sus funciones. La no
tacin de los agregados de datos en los diagramas de flujo de datos muestra la
existencia de uno o ms grupos de datos almacenados, pero deliberadamente dice
muy poco acerca de sus detalles.
Todos los sistemas almacenan y usan informacin acerca del ambiente en el
cual interactan; a veces, la informacin es mnima, pero en la mayora de los siste
mas actuales es bastante compleja. No slo deseamos conocer en detalle qu infor
macin hay en cada agregado de datos, sino que tambin queremos conocer la
relacin que existe entre agregados. Este aspecto del sistema no es resaltado por el
diagrama de flujo de datos, pero s lo hace otra herramienta: el diagrama de entidadrelacin. La figura 4.5 muestra un diagrama tpico de entidad-relacin.
El diagrama de entidad-relacin consta de dos componentes principales:
1.
Tipos de objetos. Se representan por medio de un rectngulo en el dia

grama. Esto representa una coleccin o conjunto de objetos (cosas) del
mundo real cuyos miembros juegan algn papel en el desarrollo del siste
ma; pueden adems ser identificados de manera nica y ser descritos por
uno o ms atributos.
www.FreeLibros.org
2.
Relaciones. Se representan por medio de rombos en ei diagrama y son ia

serie de conexiones o asociaciones entre ios tipos de objetos que estn
conectados con la relacin por medio de flechas.
Figura 4.5: Un diagram a de entidad-relacin
Al igual que con ei diagrama de flujo de datos, hay mucho qu decir acerca del
diagrama de entidad-relacin y se tratar con ms detaile en el captulo 12. Vere
mos que existen ciertos tipos de objetos especializados, as como guas para asegu
rar que el diagrama de entidad-relacin sea completo y congruente.
Al igual que con el diagrama de flujo de datos, es necesario acompaar el dia
grama de entidad-relacin con informacin textual detallada. El diccionario de datos
que vimos por primera vez en la figura 4.3 tambin puede usarse para mantener in
www.FreeLibros.org
formacin apropiada acerca de objetos y relaciones. Esto se tratar ms a fondo en

los captulos del 10 al 12.
4.3
EL MODELADO DEL COMPORTAMIENTO DEPENDIENTE DEL

TIEMPO: EL DIAGRAMA DE TRANSICION DE ESTADOS
El comportamiento dependiente del tiempo, es decir, ia secuencia con la cual

se har el acceso a los datos y se ejecutarn las funciones es un tercer aspecto de
muchos sistemas complejos. Para algunos sistemas computacionales de empresas
este aspecto no es importante, puesto que la secuencia es esencialmente trivial.
As, en muchos sistemas computacionales (aquellos que ni son de tiempo real, ni es
tn en lnea), la funcin N no puede llevar a cabo su labor hasta que recibe la entra
da que requiere; y esta entrada se produce como salida de una funcin N-1, y as
sucesivamente.
Sin embargo, muchos sistemas en lnea y de tiempo real, tanto en el campo de
los negocios como en ei de la ciencia y la ingeniera, tienen complejas relaciones en
el tiempo que deben modelarse tan cuidadosamente como las funciones y las rela
ciones entre datos. Por ejemplo, muchos sistemas de tiempo real deben responder
dentro de un margen breve, posiblemente de tan slo unos microsegundos, a ciertas
entradas provenientes del ambiente exterior. Y deben estar preparados para recibir
diversas combinaciones y secuencias de entradas a las cuales se debe responder
adecuadamente.
La herramienta de modelado que utilizamos para describir este aspecto del
comportamiento de un sistema es el diagrama de transicin de estados, que a veces
se abrevia (por sus siglas en ingls) STD. Un diagrama tpico se muestra en la figu
ra 4.6: modela ei comportamiento de una lavadora controlada por computadora. En
este diagrama, los rectngulos representan los estados en ios que se puede encon
trar el sistema (por ejemplo, escenarios o situaciones reconocibles). Cada estado
representa entonces un periodo durante el cual ei sistema sigue algn comporta
miento observable; las flechas que conectan un rectngulo con otro representan el
cambio de estado o transiciones de un estado a otro, hay una o ms condiciones
(sucesos o circunstancias que propiciaron el cambio de estado) asociadas con cada
cambio de estado, y una o ms (o tal vez ninguna) acciones, es decir respuestas,
salidas o actividades que se llevan a cabo como parte del cambio de estado. En el
captulo 13 se examinar con ms detalle el diagrama de transicin de estados.
4.4
EL MODELADO DE LA ESTRUCTURA DE LOS PROGRAMAS:

EL DIAGRAMA DE ESTRUCTURAS
Aunque no las usar mucho como analista de sistemas, debe estar al tanto de
que se utilizan muchas herramientas de modelado adicionales durante ia creacin de
un sistema complejo. Por ejemplo, ios diseadores de sistemas suelen utilizar los
diagramas de flujo de datos, diccionarios de datos, especificaciones de procesos y
www.FreeLibros.org
diagramas de entidad-relacin y de transicin de estados creados por el analista pa

ra crear una arquitectura de software, es decir, una jerarqua de mdulos (los que a
veces se conocen como subrutinas o procedimientos) para realizar los requerimien
tos del sistema. Una herramienta grfica de modelado comnmente utilizada para re
presentar tal jerarqua de software es el diagrama de estructuras; en la figura 4.7 se
muestra uno tpico. En este diagrama, cada rectngulo representa un mdulo (por
e je m p lo , una subrutina de FORTRAN, un procedimiento de Pascal, o un prrafo o
s u b p ro g ra m a de COBOL). Las flechas que conectan los rectngulos representan las
invocaciones de mdulos (por ejemplo, llamados de subrutinas o llamados de proce
dimientos). El diagrama tambin muestra los parmetros de entrada que se le dan a
cada mdulo invocado, y ios parmetros de salida devueltos por cada mdulo cuan
do termina su labor y le devuelve el control al que lo llama.
www.FreeLibros.org
Figura 4.6: Un diagram a de tra n s ic i n de estados
A pesar de que el diagrama de estructuras es una herramienta excelente para

los diseadores de sistemas, no es el tipo de modelo que normalmente se mostrara
ai usuario, pues modela un aspecto de la implantacin del sistema, no de sus reque
rimientos.1 Discutiremos nuevamente los diagramas de estructuras en el captulo 22.
Figura 4.7: Un diagram a de estructuras
4.5
RELACIONES ENTRE MODELOS
Como podr verse, cada modelo grfico descrito en este captulo se enfoca a
un aspecto distinto de un sistema: el diagrama de flujo de datos lustra las funciones,
el diagrama de entidad-relacin resalta las relaciones entre datos y el diagrama de
transicin de estados resaita el comportamiento dependiente del tiempo del sistema.
Dado que los sistemas tpicos son muy complejos, es til estudiar por separado cada
uno de estos aspectos. Por otro lado, estos tres panoramas dei sistema deben ser
consistentes y compatibles entre s.
1 Com o se seal en el C ap tulo 3, algunos usuarios saben m s que otros de com putadoras, y al
gunos usuarios desem pean un papel m s activo en los proyectos de d e sarrollo de sistem as que
otros. Si est trab a ja n d o con un usuario que es m iem bro de tiem po com pleto del equipo de! pro
yecto, o tai vez incluso si es el jefe del proyecto, y si es conocedor del diseo de sistem as, no hay
razn por la que no deba m ostrarle un diagram a de e structuras. Sin em bargo, si el usuario slo se
interesa por de scrib ir qu tiene que hacer el sistem a, probablem ente no le interese ve r un diagrama
que describa la organizacin de as subrutinas de FOR TRAN que cubrirn dichos requisitos.
www.FreeLibros.org
En ei captulo 14 se examinarn algunas reglas de consistencia que aseguran

que esta caracterstica est presente en ios tres principales modelos de sistemas,
junto con sus modelos textuales detallados. Por ejemplo, veremos que cada agrega
do del diagrama de flujo de datos debe corresponder un objeto o relacin del diagra
ma de entidad-relacin.
4,6
RESUMEN
Los modelos que se muestran en este captulo son relativamente simples y f

ciles de leer o interpretar. Se tuvo mucho cuidado para lograr esto, pues la intencin
es que puedan leerlos los usuarios sin gran preparacin. Sin embargo, como vere
mos en los captulos 9 a 16, se requiere mucho trabajo y cuidado para crear diagra
mas y asegurarse de que sean completos y consistentes, y que representen de
manera precisa ios requerimientos del usuario.
p r e g u n t a s y e j e r c ic io s
1. La introduccin al captulo 4 menciona mapas, globos terrqueos, diagramas de
flujo de datos, dibujos arquitectnicos y partituras musicales como ejemplos de
modelos. Mencione otros tres ejemplos de modelos usados comnmente.
2.
Qu definicin da el diccionario de la palabra modelo? Se puede aplicar a

los sistemas de informacin?
3.
Por qu se utilizan modelos en ei desarrollo de los sistemas de informacin?

Mencione tres razones.
4.
Cmo respondera si el usuario le dijera que opina que ios modelos son un
desperdicio de tiempo y que debera empezar a codificar?
5.
Cree que la descripcin verbal que un usuario d acerca de los requerimientos

de su sistema deba considerarse como un modelo? Por qu s o por qu no?
6.
Por qu sera til tener ms de un modelo para un sistema?
7.
Todos los modelos que se discuten en el captulo 4 son modelos en papel. Se

le ocurre algn otro tipo de modelo?
8. La mayora de los modelos que se discuten en el captulo 4 son herramientas

grficas (por ejemplo, imgenes) Cules cree que puedan ser las ventajas de
utilizar imgenes como herramientas de modelado?
9. Considera que ias herramientas de modelado grfico sean suficientes para re
presentar los requerimientos de un sistema de informacin? Por qu s o por
qu no?
www.FreeLibros.org
10. Quin debera ser el responsable de la creacin de los modelos necesarios

para describir los requerimientos de un sistema de informacin?
11. Debera esperarse que los usuarios crearan sus propios modelos? De ser as,
en qu circunstancias?
12. Cules son los tres principales objetivos de un diagrama de flujo de datos?
13. Cules son los cuatro principales componentes de un diagrama de flujo de da
tos?
14. Ntese que los procesos se representan por medio de crculos en un diagrama
de flujo de datos y los terminadores se representan con rectngulos. Cree
que esto sea significativo? Qu pasara si los procesos se representaran?
15. Ntese que ia figura 4.2 muestra tres diferentes procesos, pero no indica cun
tas computadoras puedan estar trabajando en el sistema. Cree que esto sea
significativo? Qu cambios se requeriran si el equipo encargado del proyecto
decidiera implantar el sistema con una sola computadora? Y con tres?
16. Ntese que la figura 4.2 muestra varios distintos diagramas de flujo de datos
entre procesos, pero no indica el medio fsico que se usar para transportar los
datos. Cree que esto sea significativo? Qu puede ocurrir si los realizado
res del sistema deciden transportar datos entre procesos utilizando lneas de te
lecomunicacin? Qu pasa si deciden transportarlos de un proceso a otro
utilizando cinta magntica?
17. Cul es el propsito dei diccionario de datos?
18. Quin debiera encargarse de crear el diccionario de datos?
ser responsable de mantenerlo al da?
Quin debera
19. La figura 4.3 muestra la definicin que da el diccionario de datos de un nombre.

Qu cree que puedan significar los parntesis, (), en dicha definicin?
20. Cul es el propsito de la especificacin de procesos?
21. Cuntas especificaciones de proceso debera esperar ver en una especifica
cin completa de los requerimientos del usuario?
22. Quin debera encargarse de la especificacin de procesos? Quin debera
actualizarla?
23. Ntese que la especificacin de procesos mostrada en el ejemplo de este cap
tulo se parece en algo a la codificacin de programas. Qu piensa de la idea
de usar pseudocdigo para escribir las especificaciones de procesos? Qu
piensa de la idea de utilizar un verdadero lenguaje de programacin (por ejem-
www.FreeLibros.org
po Ada), como lo han sugerido muchos, para las especificaciones de progra

mas? Por qu estara bien o mal usar un verdadero lenguaje de programa
cin?
24. Cul es el propsito de un diagrama de entidad- relacin?
25. Cules son los principales componentes de un diagrama de entidad-relacin?
26. Cuntos tipos de objetos se muestran en la figura 4.5?
27. Cuntas relaciones se muestran en la figura 4.5?
28. Proporciona el diagrama de entidad-relacin al lector alguna informacin sobre
las funciones que lleva a cabo el sistema?
29. Proporciona el diagrama de flujo de datos al lector alguna informacin acerca
de los tipos de objetos o sobre las relaciones entre tipos de objetos en el siste
ma?
30. Dnde deberan describirse los detalles de tipos de objetos y relaciones que
se muestran en un diagrama de entidad-relacin?
31. Cul es el propsito de un diagrama de transicin de estados?
32. Cules son los componentes de un diagrama de transicin de estados?
33. Son tiles los diagramas de transicin de estados para modelar sistemas computacionales por lotes (batch)? Por qu s o por qu no?
34. Cul es el propsito de un diagrama de estructuras?
35. Cules son los componentes grficos de un diagrama de estructuras?
36. Es de esperarse que el usuario sea capaz de leer y entender un diagrama de
estructuras? Debera esperarse que el usuario sea capaz de crear uno?
37. Describa la relacin existente entre un diagrama de entidad-relacin y un dia
grama de flujo de datos.
38. Existe alguna relacin entre un diagrama de flujo de datos y un diagrama de
estructuras? De ser as, cul es?
www.FreeLibros.org
T odo e rro r hum ano es im paciencia, una renunciacin prem atura al

m todo, una e n gaosa sujecin a un engao.
Franz Kafka, Cartas

1.
El concepto del ciclo de vida de un proyecto.
2. Las caractersticas del ciclo de vida de un proyecto

clsico.
3. Las diferencias entre proyectos clsicos y
semiestructurados.
4. Los componentes del ciclo de vida estructurado.
5. Las diferencias entre ciclos de vida radicales y
conservadores.
P a r a ser un buen analista de sistemas se requiere ms que simples herra

mientas de modelado; necesitamos mtodos. En la profesin de desarrollo de siste
mas, los trminos mtodo , metodologa, ciclo de vida del proyecto y ciclo de
vida del desarrollo de sistemas se usan de manera casi indistinta. En la parte III ve
remos mtodos detallados de cmo efectuar el anlisis de sistemas, en el contexto
ms amplio de un mtodo -conocido como ciclo de vida del proyecto estructurado-,
para llevar a cabo el desarrollo global de un sistema nuevo.
Antes de presentar el ciclo de vida del proyecto estructurado, es importante
examinar el ciclo de vida del proyecto clsico que se trata en muchos textos y se uti
liza en muchas organizaciones para el desarrollo de sistemas hoy en da, sobre todo
www.FreeLibros.org
86
EL CICLO DE VIDA DEL PROYECTO 87
para identificar sus limitaciones y puntos dbiles. Despus de este examen haremos
una breve exposicin acerca del ciclo de vida del proyecto semiestructurado: un ci
clo de vida de proyecto que incluye algunos, pero no todos los elementos del desa
rrollo moderno de sistemas. En seguida se presentar el ciclo de vida del proyecto
estructurado, mostrando una visin global de las principales actividades y de cmo
se interrelacionan. Por ltimo, se vern brevemente el ciclo de vida formador de pro
totipos que popularizaron Bernard Boar, James Martin, y varios vendedores de len
guajes de programacin de cuarta generacin.
Tambin exploraremos el concepto de desarrollo iterativo o descendente. En
particular, se presentarn ios conceptos de desarrollo iterativo radical y desarrollo
iterativo conservador. Dependiendo de la naturaleza de un proyecto de desarrollo
de sistemas, puede haber razones vlidas para adoptar un mtodo en lugar de otro,
e incluso algunos proyectos pudieran requerir una combinacin de ambos.
5.1
EL CONCEPTO DE CICLO DE VIDA DE UN PROYECTO
Como pudiera esperarse, las organizaciones pequeas de proceso de datos

tienden a ser relativamente informales: los proyectos de desarrollo de sistemas na
cen de conversaciones entre el usuario y el administrador del proyecto (que puede
ser a la vez el analista, el programador, el operario y el conserje), y el proyecto pro
cede desde el anlisis hasta el diseo e implantacin sin mayor alboroto.
Sin embargo, en las organizaciones ms grandes, las cosas se llevan a cabo
de manera mucho ms formal. La comunicacin entre los usuarios, la administra
cin y el equipo del proyecto suele ser por escrito, y todo mundo entiende que el
proyecto pasar por diversas fases antes de completarse. Aun as, es sorprendente
ver la gran diferencia entre las maneras en que dos administradores afrontan sus
respectivos proyectos. De hecho, a menudo se deja a discrecin del administrador
determinar las fases y actividades de su proyecto, y cmo se llevarn a cabo.1
Recientemente, sin embargo, ha empezado a cambiar el enfoque que se le da
al desarrollo de sistemas. Cada vez son ms las organizaciones grandes y peque
as que estn adoptando un ciclo de vida uniforme y nico para sus proyectos. Esto
a veces se conoce como el plan del proyecto, la metodologa del desarrollo del siste
ma o, simplemente, la forma en la que hacemos las cosas aqu . El manual del ci
clo de vida del proyecto suele ser un libro tan voluminoso como el compendio de
normas, que yace (usualmente sin ser ledo) sobre el escritorio de todo analista y
1 Esto suena com o si la a n a rq u a p re va le cie ra en la m ayora de las o rg a n iza cio n e s de proceso
electrnico de datos. Sin em bargo, hay dos situ a cio n es com unes que llevan a este enfoque indivi
dualista aun en la organizacin m s ejem plar: 1) La organizacin alta m e n te descentralizada, donde
cada departam ento tiene su grupo de proceso e lectrnico de datos con sus p ropias norm as locales
y 2) el periodo de varios aos tra s de que el ltim o ciclo de vida oficial del pro ye cto se ju zg a ra in
til y se descartara.
www.FreeLibros.org
88 EL CICLO DE VIDA DEL PROYECTO
programador. Ese manual ofrece un procedimiento comn a seguir para desarrollar

un sistema computacional que puede orientar a cualquier miembro de la organiza
cin de desarrollo de sistemas.
El enfoque puede ser casero o, como alternativa, pudiera ser que la organiza
cin para el desarrollo de sistemas decida comprar un paquete de administracin de f
proyectos y ajustarlo a las necesidades de la compaa.2 Parece obvio que, aparte
de darle empleo a las personas que crean los manuales de ciclo de vida de los pro
yectos (y a aquellos que escriben libros de texto al respecto), es conveniente la me- f
todologa del proyecto. De qu sirve entonces tener un ciclo de vida de un :
proyecto? Existen tres objetivos principales:
1.
Definir las actividades a llevarse a cabo en un proyecto de desarrollo de

sistemas.
2.
Lograr congruencia entre la multitud de proyectos de desarrollo de siste

mas en una misma organizacin.
3.
Proporcionar puntos de control y revisin administrativos de las decisio

nes sobre continuar o no con un proyecto.
El primer objetivo es de particular importancia en una organizacin grande

donde constantemente est ingresando personal nuevo a ios puestos de administra
cin de proyectos. El administrador novato pudiera no tomar en cuenta o subestimar '
la importancia de fases clave del proyecto si se basa slo en su intuicin. De hecho,
pudiera suceder que los programadores y analistas de bajo rango no entiendan dn
de y cmo encajan sus esfuerzos individuales en e! proyecto global, a menos que se
les d una descripcin adecuada de todas las fases del proyecto.
El segundo objetivo tambin es importante en una organizacin grande. Para
los niveles ms altos de ia administracin pudiera ser bastante confuso seguir la pis
ta de cientos de proyectos diferentes, cada uno de los cuales se lleva a cabo de dis
tinta manera. Por ejemplo, si el proyecto A define la actividad de anlisis de
sistemas de diferente forma que el proyecto B y el B no incluye una fase de diseo,
cmo puede darse cuenta el administrador de segundo o tercer nivel de cul pro
yecto se est rezagando y cul contina segn lo previsto?3
2 Existen varios de estos paq ue te s en el m ercado, que cuestan entre $10,000 y $100,000 dlares
estadounidenses (o su equ iva le nte en m oneda nacional), o ms. A lgunos de los eje m p lo s ms co
nocidos son Spectrum (de S pectrum International Corp.), SDM -70 (de AGS Softw are), y Method/1
{de A rth u r A ndersen). No com entar acerca de ningn paquete de a dm inistracin de proyectos en
particular; slo le sugiero que te n ga en m ente los conceptos presentados en este libro si su organi
zacin utiliza un paquete o btenido en el m ercado.
www.FreeLibros.org
3 Mller en [M iller, 1978], se a la que ste es un fenm eno com nm ente observado; de hecho, lo
presenta com o una h ip tesis general ap licable a todos los sistem as en activo:
El tercer objetivo de un ciclo de vida de proyecto normal se refiere a ia necesi

dad de la administracin de controlar un proyecto. En los proyectos triviales, el ni
co punto de revisin probablemente est al final del proyecto: se concluy a tiempo
y dentro de ios mrgenes del presupuesto acordado? (o, ms simple an, se con
cluy siquiera?) Y cumpli con ios requisitos dei usuario? Pero, para proyectos
ms grandes, debera contarse con varios puntos intermedios de revisin, que per
mitieran determinar si el proyecto se estuviera retrasando o si fueran necesarios re
cursos adicionales. Adems, el usuario inteligente tambin necesitar puntos de
revisin en diversas etapas del proyecto para que pueda determinar si quiere conti
nuar financindolo.4
Dicho todo esto, no queda ms que subrayar que el ciclo de vida de! proyecto
definitivamente no est a cargo dei proyecto; no le evitar al administrador del pro
yecto la difcil labor de tomar decisiones, sopesar alternativas, librar batallas polti
cas, negociar con usuarios recalcitrantes, animar a programadores deprimidos, ni
ninguna de las dems tribulaciones relacionadas con los proyectos. El administrador
del proyecto todava tiene que administrar, en todo el sentido de la palabra. La ni
ca ayuda que puede proporcionar el ciclo de vida del proyecto es que puede organi
zar las actividades del administrador, aumentando ia probabilidad de que se aborden
los problemas pertinentes en el momento adecuado.
5.2
EL CICLO DE VIDA DEL PROYECTO CLASICO
El tipo de ciclo de vida de proyecto que se usa actualmente en la mayora de

las organizaciones difiere de aquel ai que estaremos dedicando la mayor parte de
nuestra atencin en la parte II!. En la figura 5.1 se muestra el ciclo de vida clsico o
convencional. Cada proyecto atraviesa por algn tipo de anlisis, diseo e implanta
cin, aunque no se haga exactamente como se muestra en el diagrama. El ciclo de
vida de proyecto utilizado, por ejemplo, en la organizacin de usted, pudiera diferir
del que se muestra en ia figura 5.1 en una o en todas las formas siguientes:
H IPO TESIS 2-1: Los com ponentes de un sistem a incapaces de a so
cia rse , o que ca re ce n de la e x p e rie n c ia que haya fo rm a d o ta le s
asociaciones, deben fu n cio na r de acuerdo con una program acin r
gida o con reglas de operacin a ltam ente estandarizadas. Se sigue
que si la rotacin de los com ponentes rebasa el ritm o con que se
estn de sa rro lla n do las a so cia cio n es n e ce saria s para su operacin,
aum enta la rigidez en la program acin.
4 De hecho, los procedim ientos de la m ayor parte de los proyectos de proceso de datos son tales
Que existe slo un punto de control desde el cual el usuario tiene una m anera obvia y lim pia de
arrepentirse: a! fin a l de ia fa se de encuesta o del estudio de fa ctib ilid a d . En teo ra , sin em bargo, el
usuario debera te n er ia oportunidad de ca n ce la r un p royecto de proceso de datos al fin a l de cual
quier fase si piensa que est d e sp erdiciando su dinero.
www.FreeLibros.org
www.FreeLibros.org
Figura 5.1 (a): El c ic lo de vida del proyecto clsico
Las fases de exploracin y anlisis pudieran juntarse en una sola (sobre

todo en organizaciones en las cuales se considera factible desde el inicio
cualquier cosa que quiera el usuario).
Puede no haber fase de estudio de hardware si se cree que cualquier sis

tema nuevo pudiera instalarse con las computadoras existentes sin cau
sar mayor problema operacional.
Las fases de diseo preliminar y de diseo de detalles pudieran juntarse

en una sola llamada simplemente de diseo.
Diversas fases de prueba pueden juntarse en una sola; de hecho, podran

incluirse con la codificacin.
De aqu que el ciclo de vida del proyecto en una organizacin sola puede tener
cinco fases o siete o doce, pero seguir siendo todava de tipo clsico.
Qu es lo que realmente caracteriza el ciclo de vida de un proyecto como cl
sico? Se distinguen dos aspectos: una fuerte tendencia a la implantacin ascenden
te del sistema y la insistencia en la progresin lineal y secuencia! de una fase a la
siguiente.
5,2.1
Im plantacin ascendente
El uso de la implantacin ascendente es una de las grandes debilidades del ci

clo de vida de los proyectos clsicos. Como se podr ver en la figura 5.1 (a), se es
pera que los programadores lleven a cabo primero sus pruebas modulares, luego las
pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque
tambin se conoce como el ciclo de vida de cascada, y est basado en el diagrama
presentado originalmente en [Royce, 1970], y popularizado posteriormente por Barry
Boehm [Boehm, 1981]. Se muestra en la figura 5.1 (b).
No est claro de dnde surgi originalmente este enfoque, pero pudiera haber
se tomado de las lneas de montaje de las industrias manufactureras. La implanta
cin ascendente es buena para el montaje de autom viles en lnea, pero slo
despus de que si prototipo est completamente libre de fallas/5 Desafortunada
mente, muchas organizaciones que desarrollan sistemas todava producen sistemas
nicos, para o cual el enfoque ascendente presenta un gran nmero de dificultades
serias:
5 Muchos creen que el enfoque ascendente pudiera p ro ve n ir de ia industria com putacional del hard
ware porque m uchos de los program adores y a d m in istra d o re s de program acin de ios aos 50 y 60
eran ingenieros e l ctr n ico s que haban tenido que ve r previam ente con el d e sarrollo ele hardware.
www.FreeLibros.org
5.2.2
Nada est hecho hasta que todo est terminado. Por eso, si el proye
se atrasa y la fecha lmite cae precisamente en medio del proceso
prueba del sistema, no habr nada que mostrarle al usuario ms que una S
enorme pila de listados de programas, ios cuales, vistos en su totalidad,
no le ofrecen nada de valor.
Las fallas ms triviales se encuentran al comienzo del periodo de prueba

y las ms graves al final. Esto es casi una tautologa: las pruebas modula
res dejan al descubierto fallas relativamente simples dentro de los mdu
los individuales. Las pruebas del sistema, por otra parte, descubren
errores grandes de interfaz entre subsistemas. La cuestin es que los
errores de interfaz no son lo que el programador desea descubrir al final
de un proyecto de desarrollo; tales fallas pueden obligar a la recodifica
cin de un gran nmero de mdulos, y pueden tener un impacto devasta
dor sobre el calendario, justo en un momento en el cual es probable que
todo el mundo est algo cansado y molesto tras haber trabajado duro du
rante tantos meses.
La eliminacin de fallas suele ser extremadamente difcil durante las lti

mas etapas de prueba del sistema. Ntese que se puede distinguir entre
pruebas y eliminacin de fallas. La eliminacin de fallas es el arte de
descubrir dnde est la falla (y subsecuentemente cmo arreglara) des
pus de que el proceso de prueba ha determinado que la falla de hecho
existe. Cuando la falla se descubre durante la fase de prueba del sistema
en un proyecto ascendente, a menudo suele ser extremadamente difcil
determinar cul mdulo la contiene; pudiera tratarse de cualquiera de ios
cientos (o miles) de mdulos que se han combinado por primera vez. Lo
calizar una falla a menudo es como hallar una aguja en un pajar.
La necesidad de prueba con la computadora aumenta exponencialmente

durante las etapas finales de prueba. Para ser ms especficos, el admi
nistrador del proyecto a menudo descubre que necesita una gran cantidad
de horas-mquina para probar el sistema; tal vez 12 horas de labor ininte
rrumpida diaria. Dado que suele ser difcil obtener tanto tiempo de uso de
la computadora,6 el proyecto suele retrasarse mucho.
P rogresin Secuencia!
La segunda debilidad ms importante del ciclo de vida de un proyecto clsico

es su insistencia en que las fases se sucedan secuencialmente. Querer esto es una
tendencia n a tira i humana: deseamos decir que hemos terminado la fase de anlisis
6 Estoy co nvencido de que aqu se aplica o tra m s de las leyes de M urphy: Entre m s grande y
m s crtico sea ei proyecto, m s probable es que la fe ch a lm ite coincida con el proceso de fin de
ao o alguna otra crisis org a n iza cio n a l que m on o p o liza to d o el tiem po de com putadora disponible.
www.FreeLibros.org
www.FreeLibros.org
Figura 5.1 (b): El m odelo de cascada del d e sarrollo de sistem as
del sistema y que nunca tendremos que volver a preocuparnos por ella. De hecho,
muchas organizaciones formalizan esto con un ritual conocido como congelar la
especificacin o congelar el documento de diseo.
El nico problema que trae consigo este deseo de progreso ordenado es que
no es nada realista. En lo particular, el enfoque secuencial no permite el tratamien
to de fenmenos reales como los relacionados con el personal, la poltica de la
compaa, o ia economa. Por ejemplo, la persona que hizo el trabajo, el analista o
el diseador, pudieron haber cometido un error y haber elaborado un producto con
fallas. De hecho, como humanos, rara vez atinamos a hacer bien un trabajo al pri
mer intento, pero se suelen hacer repetidas mejoras del trabajo imperfecto. Tam
bin pudiera ser que la persona que revisa el trabajo o, como caso particular, el
usuario que revisa el trabajo del analista del sistema pudiera haber cometido un
error, O tai vez el encargado de llevar a cabo la labor asociada con cada fase no
haya tenido tiempo suficiente para terminar, pero no quiera admitirlo. Esta es una
manera amable de decir que, en la mayora de los proyectos complejos, la labor de
anlisis, de diseo y de prueba concluye cuando alguien decide que se ha agotado
e! tiempo, no cuando se quisiera.
Comnmente surgen otros problemas asociados con el ciclo de vida del proyec
to clsico o secuencial: durante los meses (o aos) que toma desarrollar el sistema,
el usuario pudiera cambiar de parecer respecto a lo que debe hacer el sistema. Du
rante el periodo que transcurre para desarrollar el sistema, pueden cambiar ciertos
aspectos del ambiente del usuario {por ejemplo, la economa, la competencia, los re
glamentos gubernamentales que afectan a las actividades del usuario).
Una caracterstica adicional del ciclo de vida del proyecto clsico es que se
apoya en tcnicas anticuadas. Es decir, tiende a ignorar el uso dei anlisis estructu
rado la programacin estructurada, o cualquier otra tcnica moderna de desarrollo
de sistemas.7 Pero el hecho de que el clcio de vida clsico ignore estas tcnicas no
significa que el administrador del proyecto no pueda utilizarlas. Desafortunadamen
te, muchos programadores, analistas y jefes de proyecto sienten que e! ciclo de vida
del proyecto es un mandato de la administracin de alto nivel; y si la administracin
no dice nada al respecto del uso de ia programacin estructurada, entonces creen
que no estn obligados a utilizar mtodos no clsicos.
5.3
EL CICLO DE VIDA SEMIESTRUCTURADO
Los comentarios de la seccin anterior pueden hacer que parezca que la ma

yora de las organizaciones de proceso de datos todava viven en la Edad Media.
De hecho, esto es injusto: no todas las organizaciones utilizan el ciclo de vida clsi
co. Desde fines de los aos 70 y principios de los 80, ha crecido la tendencia a re
conocer al diseo estructurado, la programacin estructurada y la implantacin
descendente como parte del ciclo de vida del proyecto. Este reconocimiento ha lle
www.FreeLibros.org
7 R esum irem os estas t cn ica s m odernas de desarrollo en el captulo 7.
vado ai ciclo de vida del proyecto semiestructurado que se muestra en la figura 5.2.
g e muestran dos detalles obvios no presentes en el enfoque clsico:
1.
La secuencia ascendente de codificacin, ia prueba de mdulos y prueba

del sistema se reemplazan por una implantacin de arriba hacia abajo,
que es un enfoque en el cual los mdulos de alto nivel se codifican y
prueban primero, seguidos por los de bajo nivel, ms detallados. Tam
bin hay fuertes indicios de que la programacin estructurada debe usar
se como mtodo para codificar el sistema.
2.
El diseo clsico se reemplaza por el diseo estructurado, que es un en

foque de diseo formal de sistemas tratado en textos tales como [Yourdon
y Constantine, 1989] y [Page-Jones, 1988],
Aparte de estas diferencias obvias, hay algunos detalles sutiles acerca del ci
clo de vida modificado. Por ejemplo, considere que la implantacin descendente sig
nifica que se pondrn en ejecucin paralelamente parte de la codificacin y de las
pruebas. Esto difiere mucho de las fases secuenciaies que vimos en el ciclo de vida
clsico. En lo particular, puede darse una retroaiimentacin entre la codificacin, la
prueba y la eliminacin de las fallas. Cuando el programador prueba la versin de
alto nivel del sistema, a veces se le puede llegar a or exclamar: Vaya, no tena
idea de que la instruccin FRAMMIS de doble precisin funcionara de esa manera! .
Desde luego, se puede tener la seguridad de que en el futuro usar de manera muy
diferente esta instruccin.
Tal vez sea an ms importante el hecho de que la implantacin descendente
pone en tentacin a los ejecutores del sistema (y a los analistas s an no han aban
donado el proyecto) de no hablar con los usuarios sino hasta despus de haberse
congelado las especificaciones. Por eso, es posible que el usuario seale errores o
malentendidos en la especificacin, o incluso pudiera expresar el deseo de cambiar
la y, si ia conversacin se da directamente entre el usuario y el que implanta, ia mo
dificacin pudiera hacerse antes de que el administrador del proyecto se d cuenta
siquiera. En resumen, a menudo la implantacin descendente ofrece retroalimentacn entre ei proceso de implantacin y el de anlisis, aunque esto no se muestre
especficamente en la Figura 5.2. y aunque ei usuario y e administrador del proyecto
de proceso de datos pudieran negar que est sucediendo.
Gomo ltimo punto a tratar acerca del ciclo de vida semiestructurado, tenemos
que una gran parte de! trabajo que se realiza bajo e nombre de diseo estructura
do es en realidad un esfuerzo manual para enmendar especificaciones errneas.
Esto se puede apreciar en la figura 5.3, que muestra ios detalles del diseo estruc
turado. (Ntese que esta Figura consiste en los detalles del proceso 3 de la figu
ra 5.2)
www.FreeLibros.org
En ia figura 5.3, la actividad 3.1 (con el ttulo de CODIFICAR LA ESPECIFICA
CION FUNCIONAL) representa la labor qus han tenido que desempear desde hace
mucho los diseadores: traducir un documento narrativo, ambiguo, monoltico y re

dundante a un modelo til y no de procedimientos, para que sirva de base para deri
var la jerarqua de mdulos que ejecutarn los requisitos del usuario. En otras
palabras, los que llevan a cabo el diseo estructurado han supuesto tradicionalmen
www.FreeLibros.org
te que se les dara una especificacin clsica; en consecuencia, su primera tarea,

desde su punto de vista, es transformar la especificacin en un paquete de diagra
mas de flujo de datos, de diccionarios de datos, de diagramas de entidad relacin y
de especificaciones de procesos.
www.FreeLibros.org
Figura 5.3: Detalles de la a ctividad de diseo
Esta labor es ms difcil de lo que se pudiera Imaginar: histricamente se ha

llevado a cabo en el vaco. En general, los diseadores tenan poco contacto con el
analista que escriba la especificacin y definitivamente no tenan contacto con el
usuario!
Es obvio que esta situacin amerita un cambio. Al presentar el anlisis estruc
turado, que es el enfoque moderno de anlisis de sistemas que se maneja en este li
bro, adems de extenderse con la dea de la retroalimentacin entre una parte del
proyecto y otra, se crea un tipo totalmente distinto de ciclo de vida del proyecto. Es
te es el ciclo de vida estructurado del proyecto que discutiremos a continuacin.
5.4
EL CICLO DE VIDA ESTRUCTURADO DEL PROYECTO
Ahora que ya hemos visto los ciclos de vida del proyecto clsico y semiestructurado, estamos listos para examinar el ciclo de vida estructurado, que se muestra
en la figura 5.4.
Examinaremos brevemente las nueve actividades y los tres terminadores del
ciclo de vida del proyecto, como se muestra en la figura 5.4. Los terminadores son
ios usuarios, los administradores y el personal de operaciones: como se recordar,
discutimos sus papeles en el captulo 3. Se trata de individuos o grupos que propor
cionan las entradas al equipo del proyecto, y son los beneficiados finales del siste
ma. Ellos interactan con las nueve actividades que se muestran en la figura 5.4 .
En las siguientes secciones se resume cada una de las actividades.
5.4.1
A ctivid ad 1: La encuesta
Esta actividad tambin se conoce como el estudio de factibilidad o como el es

tudio inicial de negocios. Por lo comn, empieza cuando el usuario solicita que una o
ms partes de su sistema se automaticen. Los principales objetivos de la encuesta
son ios siguientes:
Identificar a los usuarios responsables y crear un campo de actividad"

inicial del sistema. Esto puede comprender la conduccin de una serie
de entrevistas para determinar qu usuarios estarn comprendidos en (o
sern afectados por) el proyecto propuesto.8 Pudiera tambin implicar el
desarrollo de un diagrama inicial de contexto, que es un diagrama de flujo
de datos sencillo del tipo que se muestra en ia figura 4,2. en ei cual se re
presenta el sistema completo con un solo proceso.9
8 Las t cn ica s de encuesta se discuten en el Apndice fc.

9 E! diagram a de contexto es parte del m odelo am biental que se discutir con m ayor de talle en el
captulo 18. Su p rincipal propsito, com o se indica aqu, es definir cunto abarca el sistem a, as
com o ios diversos te rm in a d o re s (personas, unidades organizaconales, otros sistem as de cmputo,
etc.) con los que el sistem a interactuar.
www.FreeLibros.org
identificar las deficiencias actuales en el ambiente del usuario. Esto en

general comprender la lista de funciones que hacen falta o que se estn
llevando a cabo insatisfactoriamente en el sistema actual. Por ejemplo,
esto pudiera incluir declaraciones como las siguientes:
www.FreeLibros.org
Figura 5.4: El c ic lo de vida del proyecto estructurado
El hardware del sistema actual no es confiable y el vendedor se aca

ba de declarar en quiebra.
El software del sistema actual no se puede mantener, y no podemos

ya contratar programadores de mantenimiento dispuestos a darle
mantenimiento en el lenguaje que originalmente se utiliz para desa
rrollarlo.
El tiempo de respuesta del sistema telefnico de pedidos actual es

tan malo que muchos clientes cuelgan frustrados antes de hacer su
pedido.
El sistema actual no es capaz de producir los informes requeridos

por la modificacin a los impuestos decretada el ao anterior.
El sistema actual no es capaz de recibir los informes sobre lmites de

crdito del departamento de contabilidad, y no puede producir los in
formes de promedio de volumen de pedidos que requiere el departa
mento de mercadotecnia.
Establecer metas y objetivos para un sistema nuevo. Esto puede ser tam
bin una simple lista narrativa que contenga las funciones existentes que
deben reimplantarse, las nuevas que necesitan aadirse y los criterios de
desempeo del nuevo sistema.
Determinar si es factible automatizar ei sistema y de ser asi, sugerir esce

narios aceptables. Esto implicar algunas estimaciones bastante rudi
mentarias y aproximadas del costo y el tiempo necesarios para construir
un sistema nuevo y los beneficios que se derivarn de ello:10 tambin in
volucrar dos o ms escenarios (por ejemplo, el escenario con una com
putadora grande, el de procesamiento distribuido, etc.). Aunque a estas
alturas la administracin y los usuarios usualmente querrn una estima
cin precisa y detallada, el analista tendr mucha suerte si logra determi
nar e tiempo, ios recursos y los costos con un error menor del 50% en
esta etapa tan temprana del proyecto.
Preparar el esquema que se usar para guiar el resto del proyecto. Este
esquema incluir toda la informacin que se lista anteriormente, adems
de identificar al administrador responsable del proyecto. Tambin pudiera
describir ios detalles del ciclo de vida que seguir el resto del proyecto.
En general, la encuesta ocupa slo del 5 al 10 por ciento del tiempo y los re
cursos de todo el proyecto, y para los proyectos pequeos y sencillos pudiera ni si
quiera ser una actividad formal. Sin embargo, aun cuando no consuma mucho del
www.FreeLibros.org
10 Los clculos de c o sto -b e n e ficio se d iscutirn en el apndice C.
tiempo y de tos recursos del proyecto, es una actividad verdaderamente importante:

al final de la encuesta, la administracin pudiera decidir cancelar el proyecto si no
parece atractivo desde el punto de vista de costo-beneficio.
Como analista, usted podr o no estar involucrado en la encuesta; pudiera ser
que antes de que siquiera se haya enterado del proyecto, el usuario y los niveles
apropiados de la administracin ya la hayan hecho. Sin embargo, en proyectos
g ra n d e s y complejos, la encuesta requiere trabajo tan detallado que a menudo el
u su a rio solicitar la colaboracin del analista lo ms pronto posible.
No discutiremos la encuesta con mayor detalle en este libro. Si llega a tener
que ver con esta actividad, encontrar de utilidad ios apndices E y C. Para detalles
adicionales, consulte [Dickinson, 1981], [Gore y Stubbe, 1983] y [Yourdon, 1988].
5.4.2
A ctividad 2: El anlisis de sistem as
El propsito principal de la actividad de anlisis es transformar sus dos entra

das -o insumos o factores- principales, las polticas del usuario y el esquema del
proyecto, en una especificacin estructurada. Esto implica modelar el ambiente del
usuario con diagramas de flujo de datos, diagramas de entidad- relacin, diagramas
de transicin de estado y dems herramientas que se presentaron en el captulo 4.
Estas herramientas se tratan con detalle en la parte II.
El proceso paso a paso del anlisis de sistemas (es decir, las subactividades
de la actividad de anlisis de la figura 5.4) se discute en la parte III. Como veremos,
implica el desarrollo de un modelo ambiental (que se trata en el captulo 18) y el de
sarrollo de un modelo de comportamiento (que se discute en los captulos 19 y 20).
Estos dos modelos se combinan para formar el modelo esencial (que se explica en
el captulo 17), que representa una descripcin formal de lo que el nuevo sistema
debe hacer, independientemente de la naturaleza de la tecnologa que se use para
cubrir los requerimientos.
Adems de! modelo del sistema que describe ios requerimientos del usuario,
generalmente se prepara un conjunto de presupuestos y clculos de costos y benefi
cios ms precisos y detallados al fina! de la actividad de anlisis. Esto se discute
con ms detalle en el apndice C.
Obviamente, como analista del sistema, en esto pasar la mayor parte de su
tiempo. No hay nada ms que se necesite decir acerca de ia actividad de anlisis en
este momento, ya que ese es el tema que trata todo el resto del libro.
5.4.3
A ctividad 3: el diseo
La actividad de diseo se dedica a asignar porciones de la especificacin

(tambin conocida como modelo esencial) a procesadores adecuados (sean mqui
nas o humanos) y a labores apropiadas (o tareas, particiones, etc.) dentro de cada
procesador. Dentro de cada labor, la actividad de diseo se dedica a la creacin de
www.FreeLibros.org
una jerarqua apropiada de mdulos de programas y de nterfases entre ellos para

implantar la especificacin creada en ia actividad 2. Adems, la actividad de diseo
se ocupa de la transformacin de modelos de datos de entidad-relacin en un diseo
de base de datos; vase [Inmon, 1988] para ms detalles.
Parte de esta actividad le interesar como analista: el desarrollo de algo cono
cido como el modelo de implantacin del usuario. Este modelo describe los asuntos
relacionados con la implantacin que le importan al usuario al grado de que no se
los quiere confiar a los diseadores y programadores. Los asuntos principales que
suelen preocupar al usuario son aquellos relacionados con la especificacin de la
frontera humano-mquina y la especificacin de la interfaz hombre-mquina. Esa
frontera separa las partes del modelo esencial que llevar a cabo una persona (co
mo actividad manual), de las partes que se implantarn en una o ms computadoras.
De manera similar, la interfaz hombre-mquina es una descripcin del formato y de
la secuencia de entradas que los usuarios proporcionan a la computadora (por ejem
plo, el diseo de pantallas y el dilogo en lnea entre el usuario y la computadora),
adems del formato y la secuencia de salidas - o productos- que la computadora
proporciona al usuario. El modelo de implantacin del usuario se describe en el ca
ptulo 21.
En el captulo 22 se puede encontrar una introduccin ai proceso de diseo de
sistemas. Se puede encontrar material adicional en [Yourdon y Constantine, 1989],
[Page-Jones, 1988], [Jackson, 1975], y otros.
5.4.4
A ctivid a d 4: im plantacin
Esta actividad incluye la codificacin y la integracin de mdulos en un esque

leto progresivamente ms completo del sistema final. Por eso, la actividad 4 incluye
tanto programacin estructurada como implantacin descendente.
Como podr imaginar, el analista tpicamente no se ver involucrado en esta
actividad, aunque hay algunos proyectos (y organizaciones) donde el anlisis, el di
seo y la implantacin de sistemas los hace la misma persona. Este tema se discu
te ms a fondo en el captulo 23.
5.4.5
A ctivida d 5: generacin de pruebas de aceptacin
La especificacin estructurada debe contener toda la informacin necesaria

para definir un sistema que sea aceptable desde el punto de vista del usuario. Por
eso, una vez generada la especificacin, puede comenzar ia actividad de producir un
conjunto de casos de prueba de aceptacin desde la especificacin estructurada.
Dado que el desarrollo de las pruebas de aceptacin puede suceder al mismo
tiempo que as actividades de diseo e implantacin, pudiera ser que al analista le
sea asignada esta labor al trmino del desarrollo del modelo esencial en la actividad
2. En el captulo 23 se discute con ms detalle el proceso de prueba.
www.FreeLibros.org
5 4.6
A ctivida d 6 : garanta de calidad
La garanta de calidad tambin se conoce como la prueba final o la prueba de

aceptacin. Esta actividad requiere como entradas ios datos de la prueba de acep
tacin generada en la actividad 5 y el sistema integrado producido en la actividad 4.
El analista pudiera estar involucrado con la actividad de garanta de calidad,
pero por lo regular no lo est. Pueden tomar la responsabilidad uno o ms miembros
de la organizacin usuaria, o pudiera llevarla a cabo un grupo independiente de
prueba o un departamento de control de calidad. Consecuentemente, no se discutir
con ms detalle la funcin de garanta de calidad.
Ntese, por cierto, que algunas personas le llaman a esta actividad control de
calidad en iugar de garanta de calidad . Sin importar la terminologa, se necesita
una actividad que verifique que el sistema tenga un nivel apropiado de calidad; le
hemos llamado garanta de calidad en este libro. Ntese tambin que es importante
llevar a cabo actividades de garanta de calidad en cada una de las actividades ante
riores para asegurar que se hayan realizado con un nivel apropiado de calidad. Por
eso, se esperara que esto se haga durante toda la actividad de anlisis, diseo y
programacin para asegurar que el analista est desarrollando especificaciones de
alta calidad, que el diseador est produciendo diseos de alta calidad y que el pro
gramador este escribiendo cdigos de alta calidad. La actividad de garanta de cali
dad que se menciona aqu es simplemente la prueba final de la calidad del sistema.
5.4.7
A ctividad 7: descrip cin del procedim iento
A lo largo de todo este libro nos preocupamos por el desarrollo de un sistema

completo: no slo de la porcin automatizada, sino tambin de la parte que llevarn
a cabo las personas. Por ello, una de las actividades importantes a realizar es la ge
neracin de una descripcin formal de las partes del sistema que se harn en forma
manual, lo mismo que la descripcin de cmo interactuarn los usuarios con la parte
automatizada del nuevo sistema. El resultado de la actividad 7 es un manual para el
usuario.
Como podr imaginar, esta tambin es una actividad en la que pudiera verse
ivolucrado como analista. Aunque no se discutir ms a fondo en este libro, podra
consultar libros acerca de redaccin tcnica para obtener mayor informacin sobre a
escritura de manuales para el usuario.
5.4.8
A ctividad 8: conversin de bases de datos
En algunos proyectos, la conversin de bases de datos involucraba ms traba

jo (y ms planeacin estratgica) que el desarrollo de programas de computadora
cara el nuevo sistema. En otros casos, pudiera no haber existido una base de datos
que convertir. En el caso general, esta actividad requiere como entrada la base de
latos actual del usuario, al igual que la especificacin del diseo producida por me
dio de la actividad 3.
www.FreeLibros.org
Segn sea de la naturaleza del proyecto, el analista podra tener que ver con
la actividad de conversin de la base de datos. Sin embargo no discutiremos esta
actividad con mayor detalle en este libro.
5.4.9
A ctivida d 9; instalacin
La actividad final, desde luego, es la instalacin; sus entradas son ei manual

del usuario producido en la actividad 7, la base de datos convertida que se cre con
actividad 8 y el sistema aceptado producido por la actividad 6, En algunos casos,
sin embargo, ia instalacin pudiera significar simplemente un cambio de ia noche a
la maana al nuevo sistema, sin mayor alboroto; en otros casos, la instalacin pudie
ra ser un proceso gradual, en el que un grupo tras otro de usuarios van recibiendo
manuales y entrenamiento y comenzando a usar el nuevo sistema.
5.4.10
Resumen del c ic lo de vida del proyecto estructurado
Es importante ver la figura 5.4 como lo que es: un diagrama de flujo de datos.
No es un diagrama de flujo; nada implica que toda ia actividad N debe concluir antes
de comenzar la actividad N + 1. Por el contrario, la red de flujos de datos que co
nectan las actividades hace ver con claridad que pudieran estarse llevando a cabo
diversas actividades paralelamente. Debido a este aspecto no secuencial, usamos
la palabra actividad en el ciclo de vida del proyecto estructurado en lugar de fase1',
que es ms convencional. El trmino fase tradicionaimente se refiere a un perio
do particular en un proyecto en el cual se estaba desarrollando una, y slo una, acti
vidad.
Hay otra cosa que debe recalcarse acerca del uso de un diagrama de flujo de
datos para describir el ciclo de vida del proyecto: un diagrama de flujo de datos cl
sico, como el que se muestra en la figura 5.4, no muestra en forma explcita la retroalimentacin, ni el control.11 Prcticamente todas las actividades de la figura 5.4
pueden y suelen producir informacin que puede llevar a modificaciones adecuadas
de una o ms de las actividades precedentes. De aqu que la actividad de diseo
puede producir informacin que acaso cambie algunas de las decisiones de costobeneficio en la actividad de anlisis; de hecho, el conocimiento que se obtiene a par
tir de la actividad de diseo pudiera incluso llevar a revisar decisiones anteriores
acerca de la factibilidad bsica del proyecto.
Ms an, en casos extremos, ciertos eventos que pudieran darse en cualquier
actividad pueden causar que todo el proyecto termine repentinamente. Las entradas
de la administracin se muestran slo para la actividad de anlisis pues sta es la
nica que requiere datos de la administracin; sin embargo, se supone, que la admi
nistracin ejerce control sobre todas las actividades.
www.FreeLibros.org
11 En realidad, hay m aneras de m ostrar la retroalm entacin y el control en los diagram as de flujo
de datos, com o se ver en el ca p tulo 9. Las notaciones adicionales {para flu jo s de control y de
procesos de control) norm alm ente se utilizan para m od e la r sistem as de tiem po reai y hem os evitado
su uso en este m odelo del sistem a para co n stru ir siste m a s .
En resumen, la fFigura 5.4 slo seala la o las entradas requeridas por cada
actividad, y la o las salidas o productos que se generan. La secuencia de las activi
dades slo puede suponerse en la medida en que la presencia o ausencia de datos
haga posible comenzar una determinada actividad.
55
IMPLANTACION RADICAL CONTRA IMPLANTACION

DESCENDENTE CONSERVADORA
En la seccin anterior seal que ei ciclo de vida del proyecto estructurado

permite que ms de una actividad se lleve a cabo a la vez. Pongmoslo de otra ma
nera: en la situacin ms extrema, todas ias actividades del ciclo de vida esructurado pudieran estarse realizando simultneamente. En el otro extremo, el administrador
del proyecto pudiera decidir adoptar el enfoque secuencial, que implica terminar
completamente una actividad antes de emprender la siguiente.
Es conveniente tener terminologa para discutir estos extremos as como los
trminos medios entre ellos. El enfoque radical del ciclo de vida del proyecto estruc
turado es aquel en el que las actividades 1 a 9 se llevan a cabo paralelamente desde
el principio del proyecto: la codificacin se inicia el primer da del proyecto, y la en
cuesta y el anlisis continan hasta el ltimo. En cambio, en el enfoque conservador
del ciclo de vida del proyecto estructurado, la actividad N completa se termina antes
de comenzar con la actividad N + 1.
Obviamente, ningn administrador en sus cabales adoptara cualquiera de es
tos dos extremos. La clave para reconocer esto consiste en que los extremos radi
cal y conservador definidos anteriormente son los puntos extremos de una gama de
opciones; esto se ilustra en la figura 5.5. Existe un infinito nmero de opciones entre
los extremos radical y conservador. Un administrador de proyecto pudiera decidir
terminar el 75% de la actividad de encuesta, seguido por la terminacin dei 75% del
anlisis del sistema, y luego del 75% del diseo para poder producir un esqueleto ra
zonable de un sistema cuyos detalles pudieran posteriormente retinarse al pasar por
segunda vez por ei ciclo de vida entero del proyecto. O bien, e! administrador pudie
ra decidir terminar todas las actividades de encuesta y de anlisis, seguido por la
terminacin del 50% del diseo y el 50% de la implantacin. Las posibilidades son
interminables.
ULTRA
RADICAL
M O D ER AD AM EN TE
R AD IC AL
M O D ER AD AM EN TE
C O N SE R VA D O R
ULTRA
C O N SE R VA D O R
www.FreeLibros.org
Figura 5.5: E lecciones de im plantacin radical y conservadora
Cmo decide un administrador de proyecto si adoptar un enfoque radical o

conservador? Bsicamente, no hay respuesta; ia decisin suele basarse en ios si
guientes factores:
Qu tan voluble es el usuario?
Bajo qu presin labora el equipo del proyecto para producir resultados

tangibles e inmediatos?
Bajo qu presin labora el administrador del proyecto para producir un

presupuesto, programa, y estimacin de personas y otros recursos?
Cules son los peligros de cometer un error tcnico importante?
Como podr apreciarse, ninguna de estas preguntas puede responderse clara

mente. Por ejemplo, uno no puede preguntarle al usuario, en una conversacin in
formal, Qu tan voluble andas hoy?. Por otro lado, el administrador del proyecto
debiera poder juzgar ia situacin basndose en la observacin, sobre todo si es un
veterano que ha lidiado anteriormente con muchos usuarios y administradores de al
to nivel.
Si el administrador del proyecto juzga que est tratando con un usuario voluble
cuya personalidad es tal que retrasa la toma de decisiones hasta estar seguro de
que el sistema va a funcionar, entonces probablemente optara por un enfoque ms
radical. Lo mismo si trata con un usuario sin experiencia, a quien le hayan creado
pocos sistemas. Por qu pasar aos desarrollando un conjunto perfecto de especi
ficaciones tan slo para descubrir que el usuario no comprendi su significado?
Por otro lado, si el administrador trata con un usuario veterano que est abso
lutamente seguro de lo que quiere, y si ste ltimo trabaja en un rea estable y con
poca probabilidad de cambiar radicalmente de un mes a otro, entonces puede darse
el lujo de adoptar un enfoque ms conservador. Desde luego, hay muchas situacio
nes intermedias: el usuario puede estar seguro de algunas de las funciones de nego
cios que debern llevarse a cabo, pero al mismo tiempo no estar seguro del tipo de
informes administrativos que desea que el sistema le proporcione. O bien, si el
usuario est familiarizado con sistemas computacionales por lotes (batch), podra no
estar seguro del impacto que pudiera tener en la empresa un sistema en lnea.
Adems de la volubilidad, existe un segundo factor que se debe considerar: la
presin a la que se est sometido para producir resultados tangibles e inmediatos.
Si, debido a las polticas u otras presiones externas, el equipo que realiza el proyec
to debe concluirlo forzosamente para una fecha determinada, entonces se requiere
un enfoque un tanto radical. El administrador del proyecto an corre el riesgo de
que el sistema slo est completo en un 90 por ciento para la fecha lmite, pero por
lo menos ser un esqueleto operante completo en un 90 por ciento que puede mos
trarse y tal vez incluso ponerse a producir. Eso generalmente es mejor que haber
www.FreeLibros.org
todo el anlisis de sistemas, todo el diseo y toda la codificacin, pero na

da de las pruebas.
te rm in a d o
Desde luego, todos ios proyectos llegan a verse apremiados a llegar a resulta
dos tangibles; la cuestin es el del apremio. Es un asunto que puede ser algo dinmco: un proyecto que comienza holgadamente con un programa cmodo puede de
repente volverse de alta prioridad y la fecha lmite adelantarse seis meses o un ao.
Una de las ventajas de hacer el anlisis, diseo, codificacin e implantacin del sis
tema en forma descendente es que se puede suspender una actividad en cualquier
momento y dejar los detalles restantes para consideracin posterior; mientras tanto,
el anlisis de alto nivel que se haya terminado puede usarse para comenzar ei dise
o de alto nivel, y as para los dems casos.
Otro factor ms en la administracin de proyectos es el requisito siempre pre
sente en la mayora de las organizaciones grandes de que se tienen que producir
programas, estimaciones, presupuestos, etc. En algunas organizaciones, esto suele
hacerse de manera bastante informal, normalmente porque los proyectos son relati
vamente pequeos y porque la administracin siente que cualquier error en la esti
macin tendr poco impacto en la organizacin global. En tales casos se puede
adoptar un enfoque radical, aunque cualquier intento de hacer una estimacin se
tendr que reducir al nivel de conjeturas viscerales. En cambio, la mayora de los
proyectos requieren estimaciones relativamente detalladas de necesidades de per
sonal, recursos computacionales, etc., y esto slo se puede realizar tras un sondeo,
anlisis y diseo bastante detallados. En otras palabras, entre ms detalladas y pre
cisas tengan que ser las estimaciones, ms probable es que el proyecto siga un en
foque conservador.
Finalmente, el administrador del proyecto debe considerar el peligro de come
ter un error tcnico importante. Por ejemplo, suponga que toda su experiencia pasa
da en desa rrollo de proyectos ha sido con una pequea com putadora de
procesamiento por lotes IBM/36. Ahora, de repente, est a cargo de desarrollar un
sistema de multiprocesamiento en lnea para administracin de bases de datos dis
tribuidas, en tiempo real, que procesar 2 millones de transacciones diarias desde
5000 terminales distribuidas en todo el mundo. En tal situacin, uno de los peligros
del enfoque radical es descubrir algn error importante en el diseo tras haber reali
zado una buena parte de! esqueleto de alto nivel del sistema.
Pudiera descubrir, por ejemplo, que para que su gran sistema funcione se re
quiere que un mdulo de bajo nivel lleve a cabo su funcin en 19 microsegundos,
pero sus programadores de repente le informan que es Imposible codificar un mdu
lo con tanta eficiencia, ni en COBOL, ni en C, ni siquiera (ufl) en lenguaje ensam
blador. Por lo tanto, debe estar alerta al hecho de que seguir un enfoque radical
requiere que sus analistas y diseadores escojan un tope mximo para su sistema
en etapa relativamente temprana, y que siempre existe el peligro de descubrir, ya
cerca del final, que escogieron un mximo equivocado.
www.FreeLibros.org
Sin embargo, considere otra situacin: el administrador del proyecto ha decidJ

do construir un sistema electrnico de proceso de datos con equipo nuevo, sisteme
operativo nuevo, sistema de administracin de bases de datos nuevo (producido p0
alguien que no sea el vendedor), y un paquete de telecomunicaciones nuevo (protjyj
cido por otra empresa ms). Todos los proveedores tienen manuales brillantes e inyi;
presionantes que describen sus productos, pero nunca han probado la interfaz entre!
sus respectivos productos de hardware y software. Quin sabe si siquiera fundo.I
narn juntos? Quin sabe si las funciones prometidas por un proveedor queden
anuladas por los recursos del sistema que utiliza el otro? Ciertamente, en un caso!
como ste, el administrador del proyecto pudiera elegir un enfoque radical, para que
la versin esqueleto o primaria del sistema pueda utilizarse para explorar los posi
bles problemas de interaccin e interfaz entre los componentes de los diferentes
proveedores.
Si el administrador del proyecto est a cargo de un tipo familiar de sistema co
mo, por ejemplo, su nonagsimo noveno sistema de nminas, probablemente tenga
bastante idea de qu tan realistas sean sus metas. Es posible que recuerde, de su
proyecto anterior, qu tipo de mdulos necesitar a nivel detallado, y probablemente
recuerde con claridad cmo se vea la estructura de alto nivel del sistema. En tal ca
so, pudiera estar dispuesto a correr ei riesgo de cometer un error dados los dems
beneficios que puede traerle un enfoque radical.
En resumen, el enfoque radical es el ms adecuado para intentos apenas dis
frazados de investigacin y desarrollo, en los que nadie est muy seguro de qu es
lo que se supone que debe hacer el sistema final. Y es bueno para los casos en los
que para determinada fecha algo tiene que estar ya funcionando, y en situaciones en
las que la percepcin del usuario respecto a lo que desea que el sistema haga est
sujeta a posibles cambios. El enfoque conservador, por otro lado, suele usarse en
proyectos ms grandes, en los que se invierten cantidades enormes de dinero y para
los cuales se requiere un anlisis y diseo muy detallados para evitar desastres sub
secuentes. Sin embargo, cada proyecto es diferente y requiere de su propia combi
nacin de im pla nta cin descend ente conservadora y radical. Para tra ta r la
naturaleza individual de cada proyecto, el administrador debe estar dispuesto a mo
dificar su enfoque en mitad de! camino si es necesario.
5.6
EL CICLO DE VIDA DE PROTOTIPOS
Se ha vuelto popular en los ltimos aos una variacin del enfoque descen
dente antes discutido. En general se le conoce como el enfoque de prototipos y lo
popularizaron Bernard Boar, James Martin y otros. Como lo describe Boar [Boar,
1984]:
Una a lte rn a tiva de enfoque para la definicin de los requerim ientos
consiste en c a p tu ra r un co njunto inicial de necesidades e im p la nta r
las rpidam ente con ia intencin d e clarada de expandirlas y retinar
las ite ra tiva m e n te al ir a u m entando la com prensin que del sistem a
tienen ei usuario y quien io d esarrolla. La definicin del sistem a se
www.FreeLibros.org
realiza m ediante el d e scubrim iento e volutivo y gradual y no a travs

de la p re visin o m n iscien te ... Este tip o de enfoq u e se llam a de
prototipos". Tam bin se le conoce co m o m odelado del siste m a o
desarrollo heurstico. O frece una a lte rn a tiva atra ctiva y practicable
a los m todos de especificacin para tra ta r m ejor la incertidum bre,
la am bigedad y la volubilidad de los p ro ye cto s reales.
Por muchas razones, esto suena exactamente como el enfoque descendente

radical aue se discuti en la seccin anterior. La principal diferencia es que el enfoQUe estructurado que se discute a lo largo de este libro supone que tarde o temprano
se construir un modelo en papel completo del sistema (es decir, un juego completo
de diagramas de flujo de datos, de diagramas entidad-relacin, de diagramas de
transicin de estados, de especificaciones de procesos, etc.). El modelo se comple
tar ms pronto con un enfoque conservador y ms tarde con uno radical, pero para
el final del proyecto habr un juego formal de documentos que debern permanecer
siempre con el sistema, a lo largo de su correccin y mantenimiento.
El enfoque de prototipos, por otro lado, casi siempre supone que el modelo se
r operante, es decir, una coleccin de programas de computadora que simularn al
gunas o todas las funciones que el usuario desea. Pero dado que se pretende que
dichos programas sean slo de modelo, tambin se supone que al concluirse el mo
delado, los programas se descartarn y se reemplazarn con programas REALES.
Quienes hacen prototipos generalmente usan los siguientes tipos de herramientas
de software:
Un diccionario de datos integrado
Un generador de pantallas
Un generador de reportes no guiado por procedimientos
Un lenguaje de programacin de cuarta generacin
Un lenguaje de consultas no guiado por procedimientos
Medios poderosos de administracin de bases de datos
El ciclo de vida de prototipos propuesto por Boar se muestra en la figura 5.6.

Comienza con una actividad de sondeo, similar a a que propone este libro. De esto
sigue inmediatamente una determinacin de s el proyecto es un buen candidato pa
ra un enfoque de prototipos. Los buenos candidatos son aquellos que tienen las si
guientes caractersticas:
El usuario no puede o no est dispuesto a examinar modelos abstractos

en papel, tales como diagramas de flujo de datos.
www.FreeLibros.org
El usuario no puede o no est dispuesto a articular (o pre-especificar)

sus requerimientos de ninguna forma y slo se pueden determinar sus re
querimientos mediante un proceso de tanteo, o ensayo y error. O, como
lo dice mi colega Bob Spurgeon, es la situacin en la que el usuario dice:

No s qu es lo que quiero, pero lo reconocer cuando lo vea.
www.FreeLibros.org
Figura 5.6: El c ic lo de vida por p ro totipos
EL CICLO DE ViDA DEL PROYECTO 111
Se tiene la intencin de que el sistema sea en lnea y con operacin total

por la pantalla, en contraposicin con los sistemas de edicin, actualiza
cin y reportes operados por lotes. (Casi todas las herramientas de soft
ware de prototipos apuntan al enfoque orientado a terminales en lnea y
manejadas por bases de datos; existen pocas herramientas de software
en el mercado para ayudar a la creacin de prototipos de sistemas de
procesamiento por lotes.)
El sistema no requiere la especificacin de grandes cantidades de deta

lles algortmicos, ni de muchas especificaciones de procesos para descri
bir los algoritmos con los cuales se obtienen los resultados. Por ello, ios
sistemas de apoyo a decisiones, de recuperacin ad hoe (a propsito) y
de administracin de registros son buenos candidatos para el prototipo.
Los buenos candidatos suelen ser sistemas en los cuales el usuario se
preocupa ms por el formato y distribucin de los datos de entrada y sali
da en la pantalla, y por los mensajes de error, que por los cmputos que
realiza ei sistema para lograrlo.
Es importante notar que el ciclo de vida de prototipos que se muestra en ia fi

gura 5.6 concluye con una fase de diseo de un ciclo de vida estructurado tradicio
nal" como los que describe este libro. Especficamente, esto significa que no se
tiene la intencin de que el prototipo haga las veces de un sistema operacionai; la
intencin es tan slo que modele ios requerimientos del usuario.
Ei enfoque de prototipos ciertamente tiene su mrito en muchas situaciones.
En algunos casos, ei administrador del proyecto tal vez quiera utilizar este enfoque
como alternativa al de anlisis estructurado que se presenta en este libro; en otros
casos, pudiera desear utilizarlo en conjunto con la creacin de modelos en papel,
como los diagramas de flujo de datos. Tenga en mente lo siguiente:
Ei enfoque descendente descrito en la seccin anterior es otra manera de

hacer un prototipo, pero en vez de usar herramientas que se pueden ob
tener en el mercado, como generadores de pantallas y lenguajes de cuar
ta generacin, el equipo que realiza el proyecto utiliza el sistema mismo
como su propio prototipo. Es decir, las diversas versiones de un esquele
to del sistema proveen un modelo operativo con el cual el usuario puede
interactuar y darse as una idea ms realista de las funciones del sistema
que la que se pudiera formar a partir de un modelo en papel.
El ciclo de vida de prototipos, como se describi anteriormente, involucra

el desarrollo de un modelo funcional, que luego se descarta y se reempla
za con un sistema de produccin. Existe un peligro considerable de que
el usuario o el equipo que desarrolla el sistema traten de convertir al pro
totipo mismo en un sistema de produccin. Esto suele resultar un desas
tre, pues el prototipo no puede trabajar eficientem ente con grandes
volmenes de transacciones, y porque carece de detalles operacionales
www.FreeLibros.org
tales como recuperacin de errores, auditoras, caractersticas de respal

do/reinicio, documentacin para el usuario y procedimientos de conver
sin.
5.7
Si de hecho se descarta ei prototipo y se reemplaza con ei sistema de

produccin, existe el peligro real de que pudiera concluirse el proyecto sin
dejar un registro permanente de los requerimientos del usuario. Esto pro
bablemente dificulte cada vez ms ei mantenimiento con el paso dei tiem
po (por ejemplo, diez aos despus de la construccin dei sistema, ser
difcil que los programadores de mantenimiento incorporen algn cambio,
pues nadie, incluyendo a los usuarios de segunda generacin que estn
trabajando actualmente con e! sistema, recordar lo que se supona en
primer lugar que deba hacer). Ei ciclo de vida que se presenta en este li
bro se basa en la dea de que los modelos en papel desarrollados durante
la actividad de anlisis no slo sern una entrada para la actividad de di
seo, sino que tambin se conservarn (y se modificarn segn vaya
siendo necesario) durante ei mantenimiento. De hecho, os modelos pu
dieran sobrevivir ms all dei sistema en el cual se implantaron, y pudie
ran servir como especificacin para el sistema de reemplazo.
RESUMEN
E! principal propsito de este captulo fue proporcionar una visin global de ios
ciclos de vida de los proyectos en general. Si examina el ciclo de vida formal de
proyectos en cualquier organizacin de desarrollo de sistemas, debera poder distin
guir si se trata de uno clsico, semiestructurado, estructurado, o de prototipos.
Si su proyecto slo permite una actividad a la vez, la discusin sobre implanta
cin descendente radica! y conservadora de la Seccin 5.6 puede haberlo perturba
do. Este fue mi propsito, y el principal objetivo de esa seccin fuehacerle pensar
acerca de ia posibilidad de traslapar algunas de las principales actividades en el pro
yecto de desarrollo de un sistema. Obviamente, es ms difcil administrar un pro
yecto en ei cual diversas actividades se ilevan a cabo en paralelo, pero, hasta cierto
punto, eso sucede en todo proyecto. An si el administrador decide que su gente se
concentrar en una actividad a la vez, de todos modos habr varias subactividades
que se llevarn a cabo en paralelo. Mltiples analistas de sistemas estarn entrevis
tando simultneamente a mltiples usuarios; diversas piezas del producto final del
anlisis se encontrarn en diversas etapas de progreso a io largo de toda la fase de
anlisis. Una labor del administrador es tener el suficiente control sobre dichas subactividades como para asegurar que se coordinen propiamente, Y en casi cualquier
proyecto de proceso electrnico de datos, este tipo de actividad paralela se da tam
bin a alto nivel; es decir, a pesar de lo que pueda haber recomendado el ciclo de vi
da formal del proyecto de una organizacin dada, la realidad es que muchas de las
principales actividades del proyecto s se traslapan hasta cierto punto. No obstante,
si el administrador decide insistir en una progresin de actividades estrictamente se
cuencia!, an funcionar el ciclo de vida presentado por este libro.
www.FreeLibros.org
Para obtener mayores detalles acerca de ciclos de vida de proyectos, consulte

[Dickinson, 1981] y [Yourdon, 1988], Tambin cubren este concepto una variedad de
libros de ingeniera de software y de libros de administracin de proyectos.
REFERENCIAS
1.
Edward Yourdon y Larry L. Constantine, Structured Design: Fundamentis and

Appcations in Software Engneering, 2a. edicin, Englewood Ciiffs, N.J.:
YOURDON Press, 1988.
2.
Melir Page-ones, The Practicai Guide fo Structured Systems Design, 2a edi

cin Englewood Ciiffs, N,J.:YOURDON Press, 1988.
3.
Bernard Boar, Application Prototyping. Reading, Mass.: Addison-Wesley, 1984.
4.
jam es Grier Milier. Living Systems. Nueva York: McGraw- Hill, 1978.
5.
Brian Dickingson, Developing Structured Systems. Nueva York: YOURDON

Press, 1981.
6.
Edward Yourdon, Managing ihe Systems Life Cycie, 2a edicin, Englewood

Ciiffs, N.J.: Prentice-Hall, 1988.
7. James Grier Milier, Living Systems. Nueva York: McGraw- Hill, 1978.
8.
Michael Jackson, Principies of Program Design. Nueva York: Academic Press,

1975.
9.
Winston W. Royce, Managing the Development of Large Software Systems ,

Proceedings, IEEE Wescon, agosto 1970, pp. 1-9.
10.
Barry Boehm, Software Engneering Economics. Englewood Ciiffs, N.J.: Prenti

ce-Hall, 1981.
11.
Bill Inmon, Information Engneering for the Practiiioner: Puiing Theory into
Practice. Englewood Ciiffs, NU,: Prentice-Hall, 1988.
12.
Marvin Gore y John Stubbe, Elemente of Systems Anatyss, 3a edicin, Publi

que, lowa: William Brown, 1983.
1.
Mencione dos sinnimos de metodologa.
2.
Cul es la diferencia entre una herramienta, como se utiliza en este iibro, y

una metodologa?
www.FreeLibros.org
3.
Cules son los tres principales propsitos dei ciclo de vida de un proyecto?
4.
Proyecto de investigacin: Encuentre el precio de tres productos para metodo

loga comerciales ofrecidos por proveedores de software o empresas consulto
ras.
5.
Por qu normalmente las organizaciones pequeas de proceso de datos no

usan metodologas formales?
6.
Por qu es til para los administradores nuevos una metodologa?
7.
Por qu es importante tener una metodologa en una organizacin en

se estn llevando a cabo muchos proyectos diferentes?
8.
Cmo es que una metodologa es til para controlar proyectos?
9.
Cules son las principales caractersticas que distinguen el ciclo de vida

sico?
10.
Qu significa la expresin implantacin ascendente?
la que
cl
11. Cules son las cuatro principales dificultades con la estrategia de implantacin
ascendente?
12.
Qu tipo de ambiente es el adecuado para un enfoque de implantacin as

cendente?
13.
Por qu es importante que nada est hecho hasta que todo est hecho, que
adems es lo que caracteriza al enfoque ascendente?
14.
Por qu debieran encontrarse los errores triviales primeramente en la fase de

prueba de un proyecto?
15.
Qu diferencia hay entre prueba y eliminacin de errores?
16.
Por qu es difcil la eliminacin de errores en una implantacin ascendente?
17.
Qu se entiende por la frase progresin secuencal cuando se describe el

ciclo de vida de un proyecto?
18.
Cules son los dos principales problemas de la progresin secuencial?
19.
Cules son las principales diferencias entre el ciclo de vida semiestructurado

y el clsico?
20.
Cules son las dos principales consecuencias del enfoque de la implantacin

descendente?
21.
Por qu, en el ciclo de vida semiestructurado, el diseo a menudo involucra

trabajo redundante?
www.FreeLibros.org
22.
Cules son las principales diferencias entre los ciclos de vida semiestructurado y estructurado?
23.
Nombre las nueve actividades del ciclo de vida estructurado del proyecto.
24.
Quines son los tres tipos de personas que proveen de entradas primarias al
ciclo de vida del proyecto?
25.
Cules son los cinco principales objetivos de la actividad de la encuesta?
26.
Qu es un diagrama de contexto?
27.
Cul es ei principal propsito de la actividad de anlisis?
28.
Cules son los tipos de modelos producidos por la actividad de anlisis?
29.
Cul es el propsito de la actividad de diseo?
30.
Cules son los dos asuntos principales que normalmente le preocupan al

usuario en la actividad de diseo?
31.
Cundo puede comenzar la generacin de pruebas de aceptacin? (activi

dad 5)
32.
Cul es el propsito de la actividad de descripcin dei procedimiento?
33.
Por qu se utiliz un diagrama de flujo de datos en la Figura 5.4 para mostrar

ei ciclo de vida del proyecto?
34.
Cul sera un posible sinnimo para la palabra actividad?
35.
Por qu es importante la retroalimentacin en ei ciclo de vida estructurado

del proyecto?
36.
Qu diferencia hay entre los enfoques radical y conservador para el ciclo de

vida estructurado dei proyecto?
37.
Cules son ios cuatro principaies criterios para elegir ei enfoque radical vs. el
enfoque conservador?
38.
Se le ocurre algn criterio adicional para elegir un enfoque radical vs. un en

foque conservador?
39.
Qu tipo de enfoque (radical vs. conservador) debe escoger el administrador

de un proyecto si es probable que el usuario cambie de opinin respecto a los
requerimientos del sistema?
www.FreeLibros.org
40.

del proyecto si tiene una gran presin de tiempo?
41.

del proyecto si se encuentra con riesgos tcnicos importantes?
42.
Qu diferencia existe entre el ciclo de vida de prototipos y el radical?
43.
Qu caractersticas tiene el proyecto de prototipos ideal?
44.
Qu clase de herramientas se requieren tpicamente para un proyecto de pro

totipos?
45.
Por qu no son generalmente buenos candidatos para proyectos de prototipo

los sistemas por lotes?
46.
Cules son los peligros del enfoque de prototipos?
47.
Cmo pueden utilizarse en combinacin en un proyecto los ciclos de vida es

tructurado y de prototipos?
www.FreeLibros.org
Los dogm as del tran q u ilo pasado son inadecuados para el b orrasco
so presente. La ocasin est a tib o rra d a de d ificultades y debem os
estar a ia altura. Com o nuestro caso es nuevo, debem os pensar y
a ctu ar en fo rm a no ve do sa . D ebem os d e se nre d a rn o s, y en ton ce s
salvarem os a nuestra nacin.
A braham Lincoln,
S egundo M ensaje A n u a l a l C ongreso
En este captulo se aprender

1. Por qu la productividad es un asunto importante
2. Las soluciones comunes al problema de la
productividad
3. El nmero de errores en un sistema tpico
4. La relacin entre ia edad de un sistema y el nmero
de errores encontrados
O o m o analista de sistemas, formar parte de un equipo de personas cuyo

propsito es desarrollar un sistema de informacin til y de alta calidad, que cubrir
las necesidades del usuario final. Al llevar a cabo su trabajo, usted y sus compae
ros miembros del equipo sin duda se vern influenciados por las siguientes impor
tantes cuestiones:
www.FreeLibros.org
118 ASPECTOS IMPORTANTES EN EL DESARROLLO
Productividad
Confiabilidad
Mantenibilidad
Desde luego, todo mundo est a favor de la productividad; es un trmino utili

zado de igual forma que ia maternidad y la lealtad a la patria. Pero hace una gene
racin, cuando se estaban creando la mayora de los sistem as operativos, la
productividad no era algo a lo que se hiciera mucho caso. Los analistas y programadores de los aos 60 trabajaban largas horas (aunque no siempre en horarios prede
cibles), pero nadie estaba seguro jams de cunto trabajo lograran hacer en una
semana, o cunto les tomara construir un sistema completo. El sentir comn era
que el equipo de desarrollo del proyecto trabajara Muy Duro cada da, y un da, voilal, magia! el sistema quedara terminado.
Hoy en da, la productividad es un asunto mucho ms serio. Asimismo lo es el
asunto de la confiabilidad: una falla del sistema en un sistema grande y complejo
probablemente tendra consecuencias devastadoras. Y la mantenibilidad se ha con
vertido en un asunto de importancia tambin: ahora es claro que muchos de los sis
temas construidos hoy debern durar por lo menos 20 aos o ms antes de que
puedan volverse a construir, y tendrn que someterse a constantes revisiones y mo
dificaciones durante su existencia.
Cada uno de estos asuntos se explora con ms detalle en este captulo. Algu
nos, como el asunto del mantenimiento, aparentan tener poco o nada que ver con el
anlisis de sistemas, pero, como se ver, el analista juega un papel crucial en el lo
gro de la productividad mejorada, una mayor confiabilidad y mejor mantenibilidad.
6.1
PRODUCTIVIDAD: EL RETRASO EN LAS APLICACIONES
Tal vez el problema ms visible al que se enfrenta actualmente la profesin de

desarrollo de sistemas sea el de la productividad. La sociedad y los negocios mo
dernos parecen exigir cada vez ms: ms sistemas, ms complejidad y todo ms r
pido. Como analista, ver ios dos principales aspectos de este problema: el retraso
en los nuevos sistemas que se necesita desarrollar, y el tiempo que se requiere para
construir un sistema individual nuevo.
En casi cualquier organizacin de los Estados Unidos donde exista un grupo
centralizado responsable del desarrollo de nuevos sistemas, existe un retraso de va
rios aos de trabajo en espera de que se le lleve a cabo;1 de hecho, muchas organi
zaciones tienen un retraso de cuatro a siete aos o ms. ES retraso se presenta en
tres tipos diferentes:
www.FreeLibros.org
1 Las conversaciones in fo rm a le s que he sostenido con a d m inistradores de proceso de datos en Ca
nad, Europa, A ustralia, Sudam rica y otra s partes del m undo me llevan a pensar que este proble
ma no es nico de los Estados Unidos.
ASPECTOS IMPORTANTES EN EL DESARROLLO 119
Retraso visible. Sistemas nuevos que los usuarios han pedido oficialmen
te y que han sido aprobados y financiados por comits apropiados de ad
ministracin. Sin embargo, los proyectos no se han iniciado porque no
existen los recursos adecuados (esto es, analistas, programadores, etc.).
Retraso invisible. Existen sistemas nuevos que los usuarios saben que
necesitan, pero no se han molestado en pedirlos oficialmente , porque
an estn aguardando a que se concluyan proyectos del retraso visible.
Retraso desconocido. Estos son sistemas nuevos que los usuarios ni si

quiera saben que quieren todava, pero que sern identificados en cuanto
se termine alguno de los sistemas del retraso visible o del invisible.
En un estudio clsico del retraso y de la demanda de sistemas de informacin

[Alloway y Quiliard, 1982], los investigadores Robert Ailoway y Judith Quillard, de la
escuela Sloan del Instituto de Tecnologa de Massachusetts, encontraron que el re
traso invisible era tpicamente 5.35 veces mayor que el retraso visible de los nuevos
sistemas. Esto sugiere que el problema del retraso es ms bien como el proverbial
iceberg: slo una pequea porcin es visible, con una gran parte oculta bajo el agua.
Esto, desde luego, es un problema de primera importancia para la organizacin de
desarrollo de sistemas que lleva a cabo su planeacin y sus presupuestos basndo
se slo en las exigencias conocidas y visibles de sus servicios.
Un segundo aspecto del problema de la productividad es el tiempo necesario
para desarrollar un sistema individual.2 Claro est que, si ei proyecto de desarrollo
de sistemas promedio pudiera reducirse de tres aos a uno, el problema del retraso
desaparecera rpidamente, Pero aqu el asunto es que los usuarios generalmente
no se preocupan por el problema global del retraso, sino tambin por el problema lo
cal de productividad asociado con un proyecto individual. Se preocupan por si, para
cuando el nuevo sistema est listo, habrn cambiado las condiciones de negocios
tan drsticamente que los requerimientos originales ya no sean relevantes.
O, ponindolo en otras palabras, un nuevo sistema se asocia con una oportu
nidad de negocios que el usuario percibe, y esa oportunidad a menudo tiene un mar
gen de oportunidad, es decir, un periodo tras el cual sta habr desaparecido y ya
no se necesitar el sistema nuevo.
Existe un tercer motivo del problema de la productividad en muchas organiza
ciones: algunos proyectos resultan ser Intiles y la administracin los cancela antes
de que se terminen. De hecho, varias encuestas han mostrado que hasta un 25% de
los proyectos en organizaciones grandes de sistemas de informacin jams se con
cluyen. Existen, desde luego, muchas razones por las cuales puede fallar un pro
www.FreeLibros.org
2 Para dar una idea de hasta dnde abarca este problem a, C aper Jones encontr, en una encuesta
de aproxim adam ente 200 o rg a nizaciones grandes en EUA, que el p royecto tp ico se retrasaba un
ao y se exceda en un 100% del presupuesto. Vase [Jones, 1986].
yecto: problemas tcnicos, problemas administrativos, personal sin experiencia, falta

de tiempo para llevar a cabo un buen trabajo de anlisis y diseo {lo cual usualmen
te es un problema de ia administracin), y falta de participacin por parte de la admi
nistracin o de ios usuarios. Para una excelente exposicin de ia razn de las fallas
de los proyectos, vase el agradable libro de Robert Block, The Poliiics of Projects
[Block, 1980].
Ei problema de la productividad ha existido por muchos aos en la profesin
de desarrollo de sistemas, y muchas organizaciones estn buscando de manera
agresiva ia forma de reducir radicalmente su retraso en las aplicaciones y disminuir
el tiempo requerido para desarrollar un nuevo sistema. Entre las tcnicas ms co
mnmente utilizadas estn las siguientes:
Contratar ms programadores y analistas. Esto es muy comn en las or

ganizaciones nuevas y que crecen (por ejemplo, una organizacin creada
como resultado de una fusin, o una organizacin nueva formada para
explotar mercados nuevos y nuevos negocios).3 Para organizaciones ma
duras, sin embargo, este enfoque usualmente se descarta; de hecho, mu
chas organizaciones sienten que tienen demasiados programadores y
analistas ya y que en realidad lo que se ocupa es hacerlos ms producti
vos. 4
Contratar programadores y analistas ms talentosos y darles mejores

condiciones de trabajo. En vez de armar un gran ejrcito de mediocres
creadores de sistemas, algunas organizaciones se concentran en crear
un grupo ms pequeo de profesionales de gran talento, altamente capa
citados y fuertemente apoyados (y se esperara que bien pagados). Este
enfoque se basa en la disparidad bien conocida en el rendimiento de pro
gramadores con experiencia: en un estudio clsico hecho en 1968 [Sackman, Erickson y Grant, 1968] se document por primera vez el hecho de
que algunos programadores son 25 veces ms productivos que otros.
Una forma extrema de este concepto es ei superprogramador o el equi
po con programador en jefe, que fue un concepto que populariz IBM en
los aos 70 (vase [Aron, 1976], [Baker, 1972] y [Mills y Baker, 1973]),
que consiste en un equipo de especialistas del proyecto (bibliotecarios,
3 Un buen ejem plo de esto ocu rri a m ediados de la dcada de ios aos 80, cuando varios pases
liberaron su banca y su bolsa. A ustralia, Japn e Inglaterra estn entre ios pases que de repente
encontraron que docenas de bancos y bolsas e xtranjeros abran sus puertas. De stos, Londres
fu e tal ve z la lo calidad m s visib le , con su d e sre g la m e nta ci n Big B ang del 27 de octu bre de
1986. Estas a ctividades requirieron del d e sarrollo de nuevos sistem as grandes de inform acin, ic
cual generalm ente se lograba em pleando a tantos program adores y an a lista s nuevos com o se pu
diera, en el tiem po m s corto posible.
www.FreeLibros.org
4 Esto co n tra sta con las p re d icciones de una escasez nacional de program adores hechas por el De
partam ento de C om ercio de los E.U., y la Fundacin N acional de C iencia. Para m ayores detalles
vase el C aptulo 28 de [Yourdon, 1986],
creadores de herramientas, etc.) que apoya a un profesional de talento

extraordinario que llevaba a cabo tanto el anlisis como el diseo del sis
tema. Desde luego, la mayora de las organizaciones no puede construir
toda una organizacin de desarrollo de sistemas en tomo a una persona
diez veces superior al promedio.5 Sin embargo, tiene bastante de positi
vo el tratar de volver lo ms productivo posible al personal existente, dn
dole cursos de actualizacin, herramientas modernas de desarrollo de
software (que se tratan posteriormente con ms detalle), y condiciones
apropiadas de trabajo.6
Permitir a los usuarios desarrollar sus propios sistemas. Es interesante

notar que muchos otros adelantos tecnolgicos interponan a alguien en
tre el usuario y el aparato mismo: el chofer del automvil y ia operadora
de conmutador telefnico son dos ejemplos obvios. Desde luego, la ma
yora de nosotros no tenemos choferes y la mayora no necesitamos ope
radoras para realizar nuestras llamadas; ei automvil y el telfono son lo
suficientemente amistosos" con el usuario como para que los podamos
operar nosotros mismos. De igual manera, la combinacin de computado
ras personales, centros de informacin y lenguajes de programacin de
cuarta generacin, todo lo cual fue introducido en muchas organizaciones
estadunidenses a mediados de los aos 80, hicieron posible para muchos
usuarios (incluyendo, como se vio en el captulo 2, a una generacin de
usuarios que aprendieron los fundamentos de la computacin en la se
cundaria, preparatoria o facultad) el desarrollar sus propias aplicaciones
sencillas. Los informes ad hoc, las bases de datos, las aplicaciones de
hojas de clculo y ciertos cambios de mantenimiento a los programas
existentes son algunos de los proyectos que un usuario motivado y letra
do en computacin puede desarrollar por s solo.
Mejores lenguajes de programacin. Los lenguajes de programacin han

sufrido enormes cambios desde los aos 50, cuando los programadores
creaban ios programas codificando laboriosamente los ceros y unos bina
rios que el hardware ejecuta. Esta primera generacin del lenguaje de
mquina dio lugar a una segunda generacin de lenguaje ensamblador en
los aos 60, y es interesante notar que el lenguaje ensamblador an se
utiliza hoy en da en algunos proyectos. Sin embargo, los lenguajes de
5 Para una exposicin de talla da del por qu no es p r ctico el concepto de su p erprogram ador en ia
mayora de las organizaciones, vase M anaging the S tru ctu re d Techniques [Yourdon 1988].
6 Una interpretacin obvia de las condiciones de trab a jo a p ropiadas es d a r a cada m iem bro del pro
yecto una o ficina privada, o para dos personas, o un cu b culo a islado de ruidos para p erm itir la pri
vacidad y la concentracin. Esto por s solo es probable que m ejore ia p roductividad dei analista/
programador en un 10 por cie n to o ms, en com paracin con el que tra b a ja en un re a abierta y
grande con m sica a todo volum en. O tra in te rp re tacin es esta: d je lo s tra b a ja r en casa. Para
ahondar m s so b re este c o n ce p to de la ca b a a e le c tr n ic a , vase el ca p tu lo 3 de [Yourdon,
19861.
www.FreeLibros.org
procedimientos de la tercera generacin empezaron a prevalecer en los

aos 70 y siguen siendo el tipo ms comn de lenguaje; como ejemplos
tenemos COBOL, FORTRAN, BASIC, Pascal, C, MODULA-2 y Ada. No
obstante que la industria de software contina mejorando estos lenguajes
(por ejemplo, la versin actual de FORTRAN es mucho mejor que la que
usaban los programadores a comienzos de ios aos 70), el enfoque se ha
dirigido a una nueva cuarta generacin de lenguajes que eliminan la ne
cesidad de preocuparse por engorrosos y morosos detalles de edicin y
valicin de entradas, formato de los reportes y manejo de archivos. Ejem
plos de esto son FOCUS, RAMIS, MAPPER y MARK V (al igual que len
guajes como PC-FOCUS, dBASE-lll y Rbase-5000 para computadoras
personales). Muchos arguyen que estos nuevos lenguajes pueden incre
mentar la productividad de la actividad de programacin hasta en un fac
to r de diez. Sin em bargo, dado que la program acin representa
tpicamente slo del 10 al 15 por ciento del proyecto global de desarrollo
del sistema, la ganancia global en productividad es a menudo mucho me
nos substancial.
Atacar el problema del mantenimiento. El mantenimiento es un asunto de

primera importancia en el campo del desarrollo de sistemas, como se dis
cutir en la seccin 6.4. Sin embargo, la mayor parte de la atencin est
enfocada actualmente (como era de esperarse) a la mantenibilidad de los
sistemas nuevos; mientras tanto, como se mencion anteriormente, mu
chas organizaciones estn dedicando un 50 a 70 por ciento de sus recur
sos ai mantenimiento de sistemas viejos. As, la interrogante es qu
puede hacerse para volver ms fciles de mantener estos sistemas vie
jos, aparte de ia idea obvia de desecharlos y construir reemplazos nue
vos? Un enfoque que crece en popularidad es el de reestructuracin, es
decir, la traduccin mecnica de los programas anteriores (cuya lgica ha
sido parchada y cambiada tantas veces que a menudo es completamente
Ininteligible) a programas nuevos, estructurados y bien organizados.7
Una idea relacionada con esto es el uso de paquetes automatizados de
documentacin que pueden producir listados de referencias cruzadas,
diccionarios de datos, diagramas de flujo de datos detallados, diagramas
de estructura, o diagramas de flujo del sistema directamente desde el pro
grama (a esto algunos encargados de mantenimiento le llaman ingeniera
en reversa). Otro enfoque, como se mencion anteriormente, es motivar
a los usuarios a realizar sus propias modificaciones de mantenimiento.8
7 Existen diversos productos co m e rcia le s en esta area. Entre los ms conocidos estn Superstruc
tura, de G roup O peration, Inc; S tru ctu re d R etrofit, com ercializada por Peal, M arw ick; y Recordar, de
Language Technology, Inc.
www.FreeLibros.org
8 Esto es p a rticu la rm e n te releva n te , p ues de acu e rd o con un estudio [L ie n tz y S w anson, 1980]
aproxim adam ente el 42 por ciento de la actividad de m antenim iento en una o rg a nizacin tp ica con-
Otro enfoque ms es el de documentar cuidadosamente a naturaleza es

pecfica del trabajo de mantenimiento: a menudo resulta que tan slo un 5
por ciento de la codificacin en un sistema operacional es responsable de
un 50 por ciento o ms del trabajo de mantenimiento.
Disciplinas de ingeniera de software. Otro enfoque ms para la mejor

productividad es un conjunto de herramientas, tcnicas y disciplinas ge
neralmente conocidas como ingeniera de software o tcnicas estructura
das que incluyen la programacin estructurada, el diseo estructurado y
el anlisis estructurado,9 adems de disciplinas relacionadas con esto, ta
les como mtrica de software, pruebas de correccin de programas, y
control de calidad de software. En general, las tcnicas estructuradas
han tenido un impacto modesto, tpicamente una mejora de un 10 a 20
por ciento, sobre la productividad de los profesionales del desarrollo de
sistemas durante la fase de desarrollo del proyecto. Sin embargo, los sis
temas desarrollados utilizando tcnicas estructuradas en general tienen
costos de mantenimiento substancialmente ms bajos y una confiabilidad
considerablemente mayor, a menudo por un factor de 10 o ms. Esto
tiende a liberar recursos que de otra manera estaran acaparados por ei
mantenimiento o ei arreglo de fallas, con lo cual se mejora la productivi
dad de toda ia organizacin.
Herramientas automatizadas para el desarrollo de sistemas. Por ltimo,

observamos que una razn del problema de la productividad es que mu
cho del trabajo de desarrollo de un sistema automatizado de informacin
se realiza, irnicamente, de manera manual. As como los hijos del zapa
tero son ios ltimos en recibir zapatos, los programadores y analistas tra
dicionalm ente han sido los ltim os en gozar de los beneficios de la
automatizacin en su propio trabajo. Desde luego, se puede argir que
un compilador es una herramienta automatizada para la programacin,
as como los paquetes de prueba y los auxiliares en correccin de errores
proporcionan una forma de automatizacin. Pero, hasta recientemente,
ha habido poca ayuda automatizada para el diseador de sistemas y casi
nada para el analista. Ahora hay estaciones de trabajo grficas que auto
siste en m ejoras dei u suario , en com paracin con el 12 por ciento para com posturas de em er
gencia , el 9 por ciento para co rre ccio n e s de rutin a , el 6 por ciento para el acom odo de cam bios
de hardware , etc. De la porcin invertida en m ejoras, el 40 por ciento se in virti en tra ta r de hacer
reportes nuevos adicionales, el 27% en aadir datos a los reportes e xistentes, ei 10 por ciento en
modificar el form ato de reportes sin cam biar ei co ntenido de datos, y el 6 por ciento en consoiidar
datos de reportes e xistentes y lenguajes de cuarta generacin. Es probable que m uchos de estos
cambios los hubiera podido hacer directam ente el usuario.
www.FreeLibros.org
S t i enfoque del anlisis discu tid o en este libro representa la form a actual del a n lisis estructurado.
Como verem os en el ca p tulo 7, ha habido cam bios desde que se intro d u je ra por prim era vez en ios
textos a fines de ios aos 70.
matizan la mayor parte de la tediosa labor de desarrollar y mantener dia

gramas de flujo de datos, diagramas de entidad-relacin y otros modelos
grficos que vimos en el Captulo 4. Estas herramientas automatizadas
tambin se encargan de una variedad de actividades de revisin de erro
res, lo cual asegura que la especificacin producida por el analista sea
completa, no ambigua, e internamente firme. Y, en algunos casos, las
herramientas automatizadas pueden incluso generar cdigo directamente
de la especificacin, eliminando de esta manera la actividad manual de
manera absoluta. En e apndice se tratan detalles de estas herramien
tas automatizadas para el anlisis de sistemas.
Muchos de estos enfoques de productividad pueden usarse en conjunto, pues
comprenden conceptos y tcnicas complementarias. Individualmente, cada uno de
los enfoques antes expuestos puede llevar a un 10 a 50 por ciento de mejora; toma
dos en conjunto, fcilmente pueden doblar la productividad de la organizacin y, en
casos especiales, tai vez incluso mejorar la productividad por un factor de 10, En
[Jones, 1986] se puede encontrar una exposicin excelente sobre el impacto cuanti
tativo, de estos mtodos as como de un gran nmero de factores de productividad.
Como analista su reaccin a todo esto pudiera ser: Y qu? Por qu es re
levante esto? De hecho, parece que la mayora de los asuntos relacionados con la
productividad tiene que ver con la programacin, la prueba y e! mantenimiento. Nin
guno parece tener que ver con el anlisis de sistemas. Sin embargo, existen tres ra
zones por ias cuales, como analista, debe ser muy sensible respecto al asunto de la
productividad:
1.
La calidad del trabajo hecho por el analista puede tener un impacto tre
mendo sobre el tiempo que se invierte en pruebas, dado que el 50 por
ciento de los errores (y el 75 por ciento del costo de su eliminacin)
usualmente se asocian con errores en el anlisis. Pudiera culparse a los
programadores de la baja productividad por el tiempo que invierten en re
alizar pruebas, pero a menudo esto es un indicio de la poca calidad de la
labor realizada por el analista.
2.
Algunas de las tcnicas de productividad -m s y mejor gente, mejores

condiciones de trabajo y, sobre todo, las herramientas automatizadasson de relevancia directa para e analista. Vale la pena pensar qu puede
hacerse para volver a usted y a su trabajo ms productivos.
3.
La productividad del anlisis de sistemas es un asunto polticamente deli

cado, pues a menudo le parece al usuario (y a veces a ios administrado
res del grupo de d e s a rrollo de sistem as y de otras partes de la
organizacin) que se hace muy poco durante la fase de anlisis. Con fre
cuencia se escucha el comentario: Cundo van a comenzar con la pro
gramacin? No podemos darnos el lujo de estar aqu sentados para
siempre platicando acerca del sistema; ya necesitamos que se realice!"
www.FreeLibros.org
Y los usuarios no le atribuyen gran valor a la especificacin funcional, que

es el producto del anlisis del sistema. La reaccin que se da a la espe
cificacin a veces ser: Para qu tanto alboroto con todas estas imge
nes y palabras? Le dijimos lo que queremos que haga el sistema. Para
qu tuvo que escribir todo esto?.
El hecho es que no se puede elaborar un sistema que d buen resultado, de
aia calidad y mantenibie si no se sabe precisamente, y con suficiente detalle, qu se
supone que debe poder hacer. As que, a pesar de que algunos usuarios y adminis
tra d o re s pudieran quejarse de que ei anlisis es meramente un periodo de descan
so mientras se prepara para la verdadera labor del proyecto (la programacin), el
hecho es que debe hacerse de manera cuidadosa y rigurosa. Pero tambin debe
hacerse con tanta eficiencia y productividad como sea posibie; as que conviene al
analista no pensar que el anlisis es simple cosa de programacin.
6.2
CONFIABILIDAD
Otro gran problema al que se enfrentan los que desarrollan sistemas es el de

la confiabilidad. Ei largo tiempo que se invierte en la prueba y la correccin de erro
res -tpicamente un 50 por ciento del proyecto de desarrollo de un sistema-, y la
muy poca productividad (que muchos sienten que se relaciona con el tiempo que se
invierte en probar) pudieran ser aceptables si el resultado fuesen sistemas altamente
confiables y fcilmente mantenibles. La evidencia de los ltimos 30 aos es justo lo
contrario: los sistemas producidos por las organizaciones en todo ei mundo estn
llenos de errores y son casi imposibles de modificar.
Estar llenos de errores significa cosas diferentes para diferentes personas.
En promedio, el software desarrollado en los Estados Unidos tiene entre tres y cinco
errores por cada 100 instrucciones del programa. Esto despus de que e! software
ha sido probado y entregado al cliente, -vase [Jones, 1986]-. Unos cuantos pro
yectos ejemplares de desarrollo de software han reportado slo de tres a cinco erro
res por cada 10 mil instrucciones, desde el proyecto del superprogramador de IBM
[Baker, 19721. Adems, ha habido reportes pesimistas, como [Sanger, 1985], que
sugieren que ei software estadounidense puede tener hasta de tres a cinco errores
por cada 1 0 instrucciones del programa.
Los errores de software van desde os sublimes hasta los ridculos. Un error
trivial pudiera consistir en salidas (resultados) correctas, pero que no se imprimen o
presentan tan bien como el usuario deseara. Un error moderadamente serio pudie
ra ser un caso en el cual ei sistema se rehsa a reconocer ciertos tipos de entradas,
pero ei usuario final puede hallar alguna forma de saltar el problema. Los errores
serios son aquellos que ocasionan que todo el programa deje de funcionar, con una
prdida asociada de dinero o de vidas humanas. Algunos ejemplos de errores serios
relacionados con software que se han ido documentando en el transcurso de los
aos son ios siguientes:
www.FreeLibros.org
En 1979, el sistema SAC/NORAD (siglas en ingls de Comando Areo

Estratgico/Defensa Area Norteamericana) registr 50 falsas alarmas,
incluyendo un ataque simulado, cuyos resultados o salidas comenzaron
accidentalmente una escaramuza en vivo.
Un error en el programa simulador de vuelo del F16 haca que el avin

volara en posicin invertida (cabeza abajo), cada vez que cruzaba el
ecuador.
Un proyectil F18 comenz su propulsin estando todava unido al avin e

hizo que ste perdiera 6 000 metros de altitud.
Las puertas dei sistema de trenes BART, controlado por computadora en

San Francisco, se abren a veces en tramos largos entre estaciones.
Una seal de alerta de la NORAD, del Sistema de Advertencia Rpida de

Proyectiles Balsticos (BMEWS), detect a la Luna como un proyectil que
llegaba.
El ndice de la Bolsa de Vancouver perdi 574 puntos en un periodo de 22

meses debido a redondeos (por ejemplo, redondear 3.14159 a 3.1416)
Ei 28 de noviembre de 1979, un avin de Air New Zealand se estrell en

una montaa. Las investigaciones posteriores mostraron que se haba
detectado y corregido un error en los datos de curso de la computadora,
pero que jams se inform de esto al piloto.
Desafortunadamente, la lista sigue y sigue. Para ver ms ejemplos, remtase

a [Neumann, 1985]. Muchos errores de software jams se reportan porque el indivi
duo o la organizacin culpables preferiran no admitirlo pblicamente. Al momento
de escribirse este libro, haba gran preocupacin por el hecho de que errores de es
te tipo pudieran llegar a consecuencias lamentables con el programa Guerra de las
Galaxias, del Departamento de Defensa de Estados Unidos, o con algunos otros sis
temas complejos controlados por software de defensa area; vase [Jacky, 1985] y
[Adams y Fischetti, 1985]. De hecho, aun si la confiabiiidad del software de la Gue
rra de las Galaxias fuese 100 veces mayor que la de los sistemas promedio desarro
llados en Estados Unidos, pudiera todava tener alrededor de 10 000 errores, lo cual
no es una perspectiva tranquilizante si se considera que cualquiera de esos errores
pudiera acabar con la vida en este planeta.
En muchos casos, nadie est muy seguro respecto a cuntos errores tiene un
sistema, pues 1) algunos errores jams se encuentran antes de que caduque el sis
tema y, 2) el proceso de documentacin y registro de errores es tan descuidado que
la mitad de los errores encontrados no se reportan,10 aun dentro de la organizacin
misma de desarrollo de sistemas. En cualquier caso, el fenmeno tpico de descu
www.FreeLibros.org
l o Esto se basa en la encuesta hecha por Lientz y Sw anson [Lientz y Swanson, 198C],
brimiento de errores, en un periodo de varios aos de utilidad de un sistema de soft

ware, usualmente toma la forma mostrada en la figura 6.1.
La forma de esta curva recibe influencias de buen nmero de factores. Por
ejemplo, cuando el sistema se entrega por primera vez a los usuarios finales, a me
nudo no pueden ponerlo a trabajar a su mxima capacidad. Lleva tiempo convertir
su sistema anterior (que pudiera haber sido un sistema manual) y capacitar a su per
sona!. Adems, desconfan un poco de la computadora y no la quieren usar dema
siado, por lo que se descubren pocos errores. Al convertir su operacin anterior al
nuevo sistema, a medida que su personal operacional ya est mejor preparado y que
dejan de sentirse intimidados, empiezan a usar ms el software y se encuentran ca
da vez ms errores. Desde luego, si esto continuara indefinidamente, si se encon
traran cada da ms errores, los usuarios finalmente dejaran de usar el software y lo
desecharan.11 En la mayora de los casos, los programadores arreglan frentica
mente nuevos errores al irlos descubriendo los usuarios. En la mayora de los ca
sos, llega un momento en el cual el sistema empieza a estabilizarse y los usuarios
encuentran cada vez menos errores.
Existen tres aspectos deprimentes en la figura 6.1. Primero, la curva jams re
gresa a cero; es decir, casi nunca encontramos una situacin donde transcurra el
tiempo sin encontrar nuevos errores. Segundo, el rea bajo la curva, que representa
Figura 6.1: trro re s d escubierto s com o fu ncin dei tiem po
www.FreeLibros.org
11 Desde iuego, hay e xcepciones ai acopiam iento gradual, sobre todo cuando un nuevo sistem a
tiene que a ceptar de una vez todo ei trab a jo (tra n sa ccio n es) dei anterior. Com o un ejem plo intere
sante, en el cuas se renov ei sistem a de bonos de cobertura naciona! de D inam arca, vase [Hansen, 18841.
el nmero total de errores descubiertos en funcin del tiempo, es atrozmente grande;

su promedio es de tres a cinco errores por cada cien instrucciones dei programa. Y,
tercero, la curva finalmente comienza a subir de nuevo, por lo comn despus de va
rios aos. Por ltimo, todos los sistemas de software llegan a un estado de parcha
do tal que cualquier intento de eliminar un error Introduce otros dos nuevos y las
modificaciones necesarias para eliminarlos introducirn cuatro, y as en adelante.
Existe un ltimo problema que cabe sealar acerca de os errores de software:
no son fciles de enmendar. Cuando alguien, ya sea programador, usuario final o
algn otro intermediario, descubre que el software no funciona correctamente, deben
suceder dos cosas: 1) el programador debe identificar el origen y la naturaleza del
error y, 2 ) debe encontrar la manera de corregir ei error (ya sea cambiando algunas
instrucciones de programacin existentes, quitando otras o aadiendo nuevas) sin
afectar algn otro aspecto de la operacin del sistema. Esto no es fcil de hacer; de
hecho, el programador tiene menos de un 50 por ciento de probabilidades de xito
en su primer intento, y stas probabilidades se reducen rpidamente si ei programa
dor debe modificar ms de 10 a 20 instrucciones (vase [Yourdon, 1988]).
6.3
MANTENIBILIDAD
La correccin de errores sobre la marcha es un aspecto del mantenimiento.

Lientz y Swanson [Lientz y Swanson, 1980] encontraron que en esto consistan ms
dei 21 por ciento de los esfuerzos de mantenimiento global en las organizaciones es
tadounidenses de proceso de datos.12 El mantenimiento tambin involucra la modifi
cacin de un sistema para reflejar cambios en el hardware, modificaciones para
apresurar ciertos aspectos operacionales o modificaciones para reflejar cambios en
los requerimientos de! usuario final del sistema.
El mantenimiento de software es un problema primordial en muchas organiza- j
ciones, entre el 50 y el 80 por ciento dei trabajo que se hace en la mayora de las or
ganizaciones de desarrollo de sistemas se asocia con la revisin, modificacin, :
conversin, mejoramiento o correccin de errores en algn programa de computado
ra que otra persona escribi hace mucho. Y es caro: a comienzos de los aos 70, la
Secretara de la Defensa de Estados Unidos inform que el costo promedio de desa
rrollar programas de computadora en un proyecto era de 75 dlares estadouniden
ses por instruccin de computadora; ei costo de mantener e! sistema llegaba hasta
os 4 000 dlares estadounidenses por instruccin.
Para poner esto de una manera mucho ms clara considere los siguientes
ejemplos de la Administracin del Seguro Social de los Estados Unidos:
12 Dado que la industria de ia com putacin representa aproxim adam ente un 8 o 10 por ciento dei
PIB de los EUA, esto sig n ifica que se estn gastando aproxim adam ente 75 d lares estadouniden
ses por cabeza al ao en m antenim iento de software.
www.FreeLibros.org
Calcular el incremento en el costo de la vida de 50 millones de receptores

de los beneficios del Seguro Social implica el uso de 20 000 horas de
tiempo de mquina en los sistemas ms viejos de cmputo del Sistema
del Seguro Social (vase [Rochester y Gantz, 1983].
Cuando el Sistema de Seguro Social aument sus sistemas de cmputo

en 1981 de cheques de cinco cifras a cheques de seis cifras, requiri de
20 000 horas-persona de trabajo y 2 500 horas de tiempo de mquina pa
ra modificar 600 programas distintos.
La moral dei departamento de mantenimiento dei Seguro Socai estaba

tan baja en un momento dado que se sorprendi a uno de los programadores orinando sobre un paquete de discos en la sala de computadoras.
Aunque esto definitivamente es una manera novedosa de descargar la
frustracin, no resulta muy bueno para el paquete de discos.
El resultado, en ms de alguna organizacin de proceso de datos, es que los

sistemas existentes que se crearon hace 10 o 20 aos simplemente no pueden mo
dificarse para ajustarlos a las nuevas exigencias del gobierno, de la economa, del
clima o de la volubilidad del usuario. Ai paso que las compaas y ia sociedad se
vuelven cada vez ms dependientes de las computadoras, encontramos una analo
ga interesante: en la medida en que se estanca el software se estancar la compa
a o la sociedad ala que sirve dicho software.
El problema es peor an. Si fuera simplemente un caso de que ei software
fuese malo, se podra considerar desecharlo o reemplazarlo. Pero muchas organiza
ciones jams han capitalizado su software (los costos se determinan cada ao), y
sus polticas de administracin y de negocios hacen que se vuelva prohibitivamente
caro reemplazar los sistemas antiguos. Y existe un problema an ms fundamental:
en la mayora de las organizaciones, no existe una descripcin coherente de lo que
se supone que los sistemas deben hacer. La documentacin existente suele ser ob
soleta y confusa. En cualquier caso, proporciona, cuando ms, alguna idea de cmo
funciona ei software, pero no de cul es su propsito fundamenta!, o qu poltica de
negocios se supone que debe realizar.
Por eso. aunque se pueda argumentar que ia mantenibilidad es enteramente
funcin de ia implantacin (es decir, algo que preocupa a Sos programadores), es im
posible mantener un sistema si no existe un modelo preciso y actualizado de sus re
querimientos. Esto, a fin de cuentas, es iabor del analista. Como se ver en el
captulo 8, las especificaciones funcionales desarrolladas por los analistas han pro
gresado gradualmente, desde novelas victorianas absolutamente nmantenibles (mi
les de hojas de texto narrativo) a modelos grficos del sistema hechos a mano, y
hasta modelos generados y mantenidos por la computadora. Tambin se discutir el
asunto del mantenimiento continuo de las especificaciones del sistema en el ca
ptulo 24.
www.FreeLibros.org
6.4
OTROS ASUNTOS
De qu tiene que preocuparse el analista adems de ia productividad, la confiabilidad y la mantenibilidad? La lista vara de una organizacin a otra y de un pro
yecto a otro, pero por lo comn incluye lo siguiente:
6.5
Eficiencia. Un sistema debe operar mediante salidas o productos (o re

sultados) apropiados (usualmente medidas en transacciones por segun
do) y con un tiempo de respuesta adecuado para las terminales en lnea.
Este no suele ser asunto del que se tenga que preocupar el analista,
puesto que los diseadores y programadores tendrn la influencia princi
pal en la eficiencia global del sistema ya realizado. De hecho, se est
volviendo un asunto cada vez menos importante para los sistemas moder
nos, dado que los costos de hardware se vuelven menores cada ao,
mientras que la potencia y la rapidez aumentan continuamente.13
Transportabilidad. La mayora de ios sistemas nuevos se realizan en una

marca de computadora, pero pudiera haber necesidad de desarrollar el
sistema de tal manera que se le pueda mudar fcilmente entre computa
doras. Nuevamente, ste no es asunto que deba preocupar al analista,
aunque pudiera requerir que se especifiquen las necesidades de transportablidad en el modelo de implantacin.
Seguridad. Dado que los sistemas modernos de computacin son cada

vez ms accesibles (pues tienden a estar en lnea), y dado que se utilizan
para administrar bienes cada vez ms delicados de la organizacin, la se
guridad se est convirtiendo en un asunto de importancia para muchos
proyectos de desarrollo de sistemas. El nuevo sistema debe evitar el ac
ceso no autorizado, adems de la actualizacin y la eliminacin no autori
zadas de datos delicados.
RESUMEN
Varios expertos predicen que la razn matemtica o proporcin precio/rendi

miento del hardware de computadora mejorar por un factor de mil y posiblemente
hasta de un milln, en ios prximos 10 a 15 aos. Desafortunadamente, la historia
del desarrollo de software en las ltimas tres dcadas llevara al observador prome
dio a concluir que la tecnologa de software mejorar slo en una cantidad modesta.
13 Hay algunas excepciones a esta afirm acin optim ista. Para algunas a p licaciones crtica s (predic
cin del clim a, investigacin nuclear, m odelado de propiedades a e rodinm icas de a e roplanos y au
to m v ile s , e tc .), an no es a d e c u a d a ia te c n o lo g a c o m p u ta c io n a i a c tu a l. P a ra u n a m ayor
exposicin de esto vase [Yourdon, 1986], Para m uchos sistem as de tiem po real e interconstruidos, ia te cn o lo g a s es adecuada, pero los diseadores y program adores deben tra b a ja r duro para
lograr un nivel de eficiencia aceptable. En algunos casos la tecn olog a de hardw are parece ade
cuada, pero el nuevo softw are (por ejem plo, lenguajes de cuarta generacin) resultan ser ineficien
tes a tal grado que el siste m a g lobal no es aceptablem ente eficiente.
www.FreeLibros.org
Dado que el software se ha vuelto el principal costo y la ruta crtica de muchos sis
una mejora tan modesta no puede considerarse aceptable. En toda la industria computacional existe un esfuerzo enorme y concertado para realizar mejoras de
u n orden de magnitud en el proceso de desarrollo de software.
tem as,
Las tcnicas de anlisis presentadas en este libro son parte de dicho esfuerzo.
Como se ha visto, parte del esfuerzo es asunto de la programacin o diseo del sistema; pero una buena especificacin del sistema crea ios cimientos en los cuales
deben sostenerse el diseo y la programacin.
r e f e r e n c ia s
1.
Robert Alloway y Judith Guillar, User Managers Systems Needs, CISR Working Paper 86. Cambridge Mass.: MST Sloan School for Information Systems
Research, abril 1982.
2.
Harold Sackman, W.J. Erickson, y E.E. Grant, Exploratory Experimental Studies Comparing Online and Offline Programming Performance, Communica
tions of the ACM, enero 1968, pp. 3-11.
3.
J. Aron, The Super-Programmer Project, Software Engneering Concepts and

Techniques. eds. J.M. Buxton, P. N aur y B. R andell. Nueva York:
Petrocelii/Charter, 1976, pp. 188-190.
4.
F.T. Baker, Chief Programmer Team Managment of Production Programming,

IBM Systems Journal, volumen 11, nmero 1 (enero 1972), pp. 56-73.
5.
H.D. Mills y F.T. Baker, Chief Programmer Teams , Datamation, volumen 19,
nmero 12 (diciembre, 1973), pp. 58-61.
6. Edward Yourdon, Managing the Structured Techniques: Straegies for Software

Development in the 1990s, 3a edicin, Nueva York: YOURDON Press, 1986.
7. Bennett P. Lientz y E. Burton Swanson, Software Maintenance Management.
Reading, Mass: Addison Wesley, 1980.
8. T. Capers Jones, Programming Productvity. Nueva York: McGraw-Hill, 1986.
9. T. Capers Jones, A Software Productvity Survey . discurso en la Primera
Conferencia Nacional sobre Calidad de Software y Productividad, Wiliamsburg, Virginia, marzo 1985.
10.
Edward Yourdon, op cit.
11.
F.T. Baker, op cit.
12.
David Sanger, Software Fears on Star Wars, New York Times, 4 de julio de
1985.
www.FreeLibros.org
13.
Peter G. Neumann, Some Computer-Related Disasters and Other Egregious

Horrors, ACM SIGSOFT Software Engineerng Notes, enero 1985.
14.
Jonathan Jacky, The Star Wars Defense Wont Compute, Atlantic Monthly, ju
nio de 1985.
15.
John A. Adams y Mark A. Fischetti, Star Wars-SDI: The Grand Experiment,

IEEE Spectrum, septiembre de 1985, pp. 34-64.
16.
Artculo del New York Times, alrededor del 16 de septiembre de 1986, que co
mentaba el nmero de errores en la Guerra de las Galaxias.
17.
Dies Hansen, Up and funning. Nueva York: YOURDON Press, 1984.
18.
Edward Yourdon, op d i.
19.
Bennett P. Lientz y Burton Swanson, op di.
20.
Jack Rochester y John Gantz, The Naked Computer. Nueva York:

rrow, 1983.
21.
Edward Yourdon, Nations at Risk. Nueva York: YOURDON Press,1986.
22.
Robert Block, The Poiitics o f Projects, Nueva York: YOURDON Press, 1981.
William Mo-
EJERCICIOS Y PROBLEMAS
1.
Examine un reporte financiero de una compaa pblica grande para ver si

puede determinar cunto se gasta en desarrollo de sistemas. Cunto dinero
se ahorrara si se pudiera doblar la productividad de la organizacin de desa
rrollo de sistemas?
2.
Escoja una compaa pblica grande que sea obvio que dependa de computa
doras para su operacin diaria. Estime cuntos das, semanas o meses poda
continuar funcionando la empresa si se detuvieran sus sistemas de computa
cin.
3.
Cules son los tres principales aspectos del desarrollo de sistemas actual
mente?
4.
Por qu es probable que la productividad sea el problema ms visible er. e!

desarrollo actual de sistemas?
5.
Cules son los tres tipos de retraso que se pueden encontrar en una org
zacin tpica actualmente?
www.FreeLibros.org
6.
Proyecto de investigacin: haga una encuesta en su organizacin para ver qu

tan grande es el retraso en el desarrollo de sistemas. Se conocen estas ci
fras entre Sos usuarios y administradores en su organizacin?
7,
Cul es la diferencia entre retraso visible e invisible?
g,
Cundo existe un retraso desconocido?
g,
Por qu es probable que el retraso invisible sea mucho mayor que el visible?
0.
Cules son las siete principales soluciones que siguen las organizaciones pa
ra resolver sus problemas de productividad? Puede sugerir otras?
11.
Cmo cree que una empresa deba medir la productividad de su organizacin

(Q desarrollo de sistemas?
12.
Qu tan prctico resulta solucionar el problema de la productividad contratan

do ms programadores y analistas? Cules son las ventajas y desventajas?
13.
Cree que sea prctico resolver el problema de productividad empleando pro

gramadores o analistas con ms talento? Por qu s o por qu no?
1 4.
Suponga que hubiese un programador diez veces ms productivo que el pro

gramador promedio que percibe 250 mil dlares de EUA, anuales. Cree que
la administracin de una organizacin tpica est dispuesta a gastar 250 mil
dlares de EUA, anuales en el programador con talento? Cree que debieran
estar dispuestos a ello? Por qu s o por qu no?
15. Qu tan prctico cree que sea resolver el problema de la productividad dejan
do a los usuarios desarrollar sus propios sistemas? Cules son las ventajas
y desventajas?
16.
Qu tipo de sistemas seran ms apropiados para que tos usuarios los desa
rrollaran por s solos? Qu porcentaje de proyectos en una organizacin tpi
ca cree que sea probable que entren en esta categora?
17.
Qu tan prctico cree que sea utilizar nuevos lenguajes de programacin, ya

sea de tercera generacin, como Ada, o de cuarta como Focus, RAMIS o NOivlAD. para resolver el problema de la productividad? Cules son las ventajas
y desventajas de este enfoque?
18.
Proyecto de Investigacin: Cunto mejorara la productividad en su organiza

cin durante los prximos cinco aos si se comenzara a utilizar un nuevo len
guaje de programacin? Cmo se vera afectado esto por el cdigo existente
y por la cultura" existente de los programadores y analistas?
19.
Por qu un lenguaje de programacin de cuarta generacin proporciona una

mayor mejora en la productividad que uno convencional de tercera genera
cin?
www.FreeLibros.org
20.
Cunto mejorara la productividad en una organizacin tpica si el manteni

miento pudiera reducirse en un factor de 10?
21.
Proyecto de investigacin: Utilice un producto comercial de tipo mquina de

estructuracin para reestructurar un programa existente en su organizacin, y
mida ia reduccin de los costos de mantenimiento. Qu le dice esto acerca
de los beneficios potenciales de una mquina o mtodo de estructuracin?
22.
Cree que la reestructuracin pueda convertir programas buenos en malos?

Por qu s o por qu no? Si su respuesta es no, entonces, cul es el prop
sito de la reestructuracin de programas?
23.
Pueden los usuarios llevar a cabo su propio mantenimiento de software?

Qu se ocupa para que esto funcione? Hablando en forma realista, cunto
trabajo de mantenimiento de software cree que los usuarios pudieran ser ca
paces de hacer?
24.
Por qu la ingeniera de software puede mejorar la productividad?
25.
Por qu pueden mejorar la productividad las herramientas automatizadas de

desarrollo de software?
26.
En qu puede afectar al trabajo del analista la productividad en un proyecto

de desarrollo de sistemas?
27.
Qu tanto de un proyecto se invierte en pruebas y correccin de errores?
28.
Proyecto de investigacin: Cul es ei nmero promedio de errores en ios sis

temas desarrollados por su organizacin? Cul es la varianza: la diferencia
entre el peor y el mejor?
29.
Proyecto de investigacin: encuentre por lo menos dos ejemplos documenta

dos de fallas en el ltimo ao en sistemas que hayan causado prdidas de vi
das o que hayan costado ms de 1 m illn de dlares de EUA. Cmo
pudieron haberse evitado estas fallas?
30.
Por qu tiende a aum entareI nmero de errores en un sistema despus de

que se pone a funcionar por primera vez?
31.
Por qu tiende a aumentar el nmero de errores gradualmente tras haber es

tado funcionando varios aos el sistema?
32.
Proyecto de investigacin: qu porcentaje de los recursos de su organizacin

de desarrollo de sistemas se invierten en mantenimiento? Est al tanto la
administracin superior de estas cifras?
33.
Qu factores, adems de la productividad, calidad y confiabilidad, son impor

tantes en la organizacin tpica actual de desarrollo de sistemas?
www.FreeLibros.org
34.
Qu papel representa el analista en ia determinacin de la eficiencia de un

sistema de informacin actualmente?
Qu papel juega el analista en la determinacin de la transportabilidad de un

sistema de informacin en la actualidad?
Qu papel tiene ei analista en la determinacin de la seguridad en un sistema
de informacin actualmente?
www.FreeLibros.org
AIMIHQS EN EL ANALISIS
DE SISTEMAS
Se han a cuado nuevos t rm in o s, ta le s com o te cn o -stre ss y tecn o-sh o ck,
para d e fin ir las m an ifestaciones p sicolgicas de un pblico avasallado por to
da cla se de cosas, desde hornos de m icro o n d a s hasta ju e g o s ca se ro s de
Pac-M an. D esafortunadam ente, estos trm inos no describen adecuadam ente
ei progreso en la in d u stria del procesam iento de datos, en o relacionado con
ei d e sarrollo de softw are. Para m uchos profesionales del proceso de datos,
ei te cn o-stress se define m ejor com o ia frustracin que trae el lento cam bio
que se est dando en los m todos de d e sarrollo de softw are, ante la siem pre
crecien te dem anda de servicios de procesam iento de datos.
A unque no hay duda de que se ha tenido algn p rogreso orientado
ha cia m ejore s m to d o s de d e s a rro llo de siste m a s d u ra n te ios ltim o s 30
aos, tam poco la hay de que, en general, cu a lq u ie r proceso de cam bio es
lento y discontinuo. Desde una perspectiva histrica, parece ser que para
que se logre un ve rd a d e ro progreso debe haber un replanteam iento peridico
y colectivo de ias ideas bsicas. Los lapsos que hay entre cada gran salto
de avance pueden ser de d ecenas a cientos de aos.
F.J. G rant, El softw are del siglo X X I
D atam ation, 19 de abril de 1985
n este captulo se aprender

1. Los problemas del anlisis clsico de sistemas,
2. Los cambios que se han dado en el anlisis
estructurado clsico.
3. Por qu las herramientas automatizadas son
importantes para el futuro del anlisis de sistemas.
4. Por qu los problemas del anlisis estructurado
clsico han llevado a la elaboracin de prototipos.
www.FreeLibros.org
136
CAMBIOS EN EL ANALISIS DE SISTEMAS 137
L o s mtodos y herramientas de anlisis de sistemas que se presentan en esje libro representan un enfoque de io ms avanzado que se usar en la mayora de
ias organizaciones de desarrollo de sistemas durante el resto de los aos 80 y co
mienzos de los 90. Para mediados de los 90 es probable que el anlisis de sistemas
^gya evolucionado sustancialmente; en el captulo 25 se discute la probable natura
leza de dicha evolucin.
Pero no es suficiente estar al tanto de las tcnicas actuales de anlisis de sis
temas. Tambin deben comprenderse los cambios que han sucedido en los ltimos
c in c o a diez aos, que han conducido a las tcnicas y herramientas que explorare
mos con mayor detalle en las partes II y III. Existen tres razones por las cuales debe
e s ta r familiarizado con la evolucin del anlisis de sistemas.
Primero, pudiera ser que encuentre que la organizacin de desarrollo de siste
mas para la que trabaja no ha evolucionado y que nadie tiene intencin de hacer
cambios. Aunque los cambios que se discuten en este captulo ocurrieron en aproxi
madamente un 80 % de las organizaciones de proceso de datos de Estados Unidos,
Canad, Europa y otras partes del mundo, an quedan aquellos baluartes de la me
diocridad que no ven razn alguna para cambiar la forma en la que han venido tra
bajando desde hace 20 aos. Si se encuentra en esta situacin, lo lgico sera
buscarse otro empleo; o, si se siente con valor, pudiera adoptar un papel de lder y
ayudar a su organizacin a entrar al mundo moderno del anlisis de sistemas.1
Segundo (y ms probablemente), pudiera encontrar que su organizacin ha
comenzado a implantar algunos de los cambios que se tratan en este captulo, pero
que el proceso de cambio durar otros cuantos aos ms. Un buen ejemplo de esto
es el desarrollo de herramientas automatizadas para el anlisis de sistemas. Casi
todos los analistas le dirn que estas herramientas basadas en PC (computadoras
personales) son una buena dea, y algunos administradores de proceso de datos es
tn comenzando a apoyar el concepto. Pero las herramientas son relativamente nue
vas; casi no existan antes de 1984. Y las organizaciones son lentas en hacer el
cambio; para fines de 1987 se estimaba que menos del 2 por ciento de los analistas
de sistemas en los Estados Unidos tenan acceso a las herramientas que se tratan
en este libro; para 1990 se estima que aproximadamente el 10% de los analistas las
estarn utilizando, y probablemente no ocurrir una verdadera saturacin del merca
do hasta mediados de los aos 90. Por ello, aunque usted, y otros miembros de su
organizacin sepan qu herramientas y tcnicas se instalarn dentro de tres aos,
es posible que el enfoque actual del anlisis de sistemas sea algo diferente. Es im
portante que sepa qu enfoque estuvo utilizando anteriormente la organizacin y
qu tipo de transicin est ocurriendo.
www.FreeLibros.org
1 Esta sugerencia no es frvola. Si estas o rg a nizaciones no cam bian, q uedarn fuera dei m ercado
en algn periodo de ios aos 90.
138 CAMBIOS EN EL ANALISIS DE SISTEMAS
Tercero, la nocin de transicin es importante aun si trabaja en una de las or-1

ganizaciones lderes que han implantado completamente el enfoque de anlisis!
que se presenta en este libro. El campo del anlisis de sistemas, como todos los
dems aspectos de las computadoras, es dinmico; la manera en la que se lleve el
anlisis de sistemas en 1995 indudablemente ser diferente de como se hace ahora,
Para dilucidar los cambios que sucedern durante la ltima mitad de ios aos 90 se
requiere una buena apreciacin del origen de este campo de actividades, as como
de hacia dnde se dirige.
7.1
EL MOVIMIENTO HACIA EL ANALISIS ESTRUCTURADO
Hasta fines de los aos 70, ia gran mayora de los proyectos de desarrollo de
sistemas empezaban con la creacin de una novela victoriana de requerimientos
del usuario. Es decir, el analista escriba lo que entenda de los requerimientos del
usuario en un enorme documento que consista primariamente en una narrativa. Los
primeros autores de textos de anlisis estructurado", sobre todo [De Marco, 1978J,
[Gane y Sarson, 1977] y [Weinberg, 1978], sealaron que estos pesados tomos (a
menudo conocidos como especificacin funcional) se vean afectados por diversos
problemas importantes;
Eran monolticos: haba que leer completamente la especificacin, de

principio a fin, para poder entenderla. Como en una novela victoriana, si
no se lea la ltima pgina, se tendra poca idea de cmo terminara la
historia.2 Esta es una falla importante, pues existen muchas situaciones
en las que el analista quisiera leer y comprender una parte de la especifi
cacin sin tener necesariamente que leer las dems.
Eran redundantes: a menudo se repeta la misma informacin en diversas

partes del documento.3 El problema con esto es que si cambia cualquier
aspecto de los requerimientos del usuario durante la fase de anlisis (o
peor an, despus de declararse terminada sta), el cambio debe reflejar
se en diversas partes del documento. Este sera un problema menor hoy,
pues hasta la organizacin ms primitiva cuenta con amplio acceso a ins
trumentos y medios de procesamiento de palabras; pero en los aos 60 y
70, la mayora de las organizaciones creaban sus especificaciones funcio
nales con nada ms elaborado que una mquina de escribir elctrica.4
2 O, para p o nerlo de otro m odo, nunca hay sexo sino ha sta la ltim a pgina.
3 Existen diversas teoras en cuanto a por qu la redundancia resulta ser una ca ra cte rstica tan co
m n. En mi p ropia e xp e rie n cia , ia e sp e cificacin fu n cio na l serva para tres p ro p sito s en la organi
zacin (y por lo tanto la m ism a inform acin se presentaba de tres m aneras distin ta s): p rim ero, era
la d aclaracin o fic ia l de los req uerim ientos del usuario; segundo, era un m anual e xtra o ficia l de en
trenam iento, con la in tencin de exp lica r cm o los "ton to s usuarios o peraran el sistem a; y tercero,
era una h erram ienta de ventas orientada polticam ente, con la intencin de fija r en las m entes de la
a d m in istra ci n la im presin de que el sistem a sera tan m aravilloso que bien valdra su costo.
www.FreeLibros.org
4 Tal vez uno de los m ejores ejem plos de este problem a se dio en la organizacin de proceso de
d atos de un banco neoyorquino im portante a m ediados de los aos 70. Em barcado en un proyecto
Debido a que era tan difcil actualizar y revisar un documento, ia redun

dancia inherente llevaba a un problema an peor: la inconsistencia. As
como es poco probable que una persona que tenga muchos relojes sepa
exactamente qu hora es, una especificacin funciona! que repita tres o
cuatro veces la misma informacin es probable que tenga informacin
errnea en diversos casos.
Eran ambiguas: ei reporte detallado de los requerimientos poda ser (y a

menudo era) interpretado de diferente manera por el usuario, el analista,
el diseador y el programador. En estudios hechos a fines de los aos
7Q5 se encontr que el 50 por ciento de los errores que finalmente apare
can en un sistema operacional y el 75 por ciento del costo de su elimina
cin podan atribuirse a malos entendidos o errores en la especificacin
funcional.
Eran imposibles de mantener: por todas las razones descritas anterior

mente, la especificacin funcional era casi obsoleta para cuando llegaba
el final del proceso de desarrollo del sistema (es decir, para cuando el
sistema se pona en operacin), y a menudo era obsoleto para el final de
ia fase de anlisis. Esto significa que la mayora de los sistemas que se
desarrollaron durante los aos 60 y 70, que ahora tienen 20 aos o ms
de existir, no tienen definiciones actualizadas de las polticas de negocios
que se supone que llevan a cabo. Y dado que los analistas y usuarios
originales del sistema han desaparecido, la realidad es que nadie sabe lo
que la mayora de los principales sistemas de cmputo estn haciendo
actualmente.
caracterstico de d e sarrollo de sistem a tipo horda m on g o ia n a , el grupo de a n lisis entrevist a

docenas de u suarios en todo el banco y gradualm ente de sa rro ll una e sp e cificacin tipo novela victoriana de g igantescas proporciones. T ra n scrib ir el d ocum ento ie llev dos sem anas al grupo de
mecanografa y todas las co p ia d ora s se m onopolizaron d u rante d a s para p o d er hacer duplicados
suficientes para todos los usuarios. Se le dio una sem ana a la com unidad u suaria para leer to d a la
especificacin funcional e in d ica r los cam bios o corre ccio n e s deseados . Un ta n to para su sorpresa
(pero tam bin para su gran alivio) los a n alistas no recibieron com entario alguno de los u suarios pa
ra la fecha indicada. Por lo tanto, se declar co n g elad a la especificacin y se dio inicio al diseo
y a la program acin. Tres sem anas despus, seis m iem bros de la co m unidad anunciaron que final
mente haban logrado leer toda la especificacin y, s, tenan unos cuantos pequeos cam bios qu
sealar. Da aqu sigui un leve pnico: Qu se le d e bera hacer a la especifica ci n? Tras dos
acaloradas ju n ta s en las que los usuarios y analistas in su lta ro n m utuam ente a sus respectivas pa
rentelas e in teligencias en t rm in o s que no pueden repetirse en un libro com o ste, se lleg a una
decisin: los cam bios no se introdujeron en la e sp e cificacin escrita (pues eso resu lta ra dem asiado
difcil), pero s se incorporaran ai sistem a m ism o. O, para p o nerlo de otro m odo: el equipo encar
gado del proyecto encontr que era m s f cil m od ifica r e! C O BO L que el ingls.
5 Vase Jam es M artin, A n In form ation S ystem s M an ife st (Englew ood C liffs, N .J.: Prentice-H al!,
1984).
www.FreeLibros.org
Mientras se debatan todos estos problemas, ya se estaba adoptando un cor.

junto complementario de ideas en el rea de programacin y diseo. Estas idc
normalmente conocidas como diseo y programacin estructurados, prometan grandes mejoras en la organizacin, codificacin, prueba y mantenimiento de los progra-:
mas de computadora. Y, de hecho, s han demostrado ser tiles, aunque cada ve? i
ms organizaciones de procesamiento de datos han empezado gradualmente a darse cuenta de que no tena caso escribir programas brillantes y disear sistemas alta
mente modulares si nadie saba realmente qu era lo que se supona que el sistema
debera hacer. En realidad, se podra argumentar que el diseo y la programacin
estructurados les permitan a algunos equipos de encargados de proyectos llegar a
un desastre ms rpidamente que antes, ai construir una brillante solucin al proble
ma equivocado.
Como resultado, ha habido un movimiento gradual (puesto que aceptarlo le ha
llevado a la profesin de desarrollo de sistemas alrededor de diez aos) tendiente a
hacer especificaciones funcionales que sean:
Grficas: compuestas de una variedad de diagramas, apoyadas con ma

terial textual detallado que, en muchos casos, sirve de material de refe
rencia ms que como cuerpo principal de la especificacin.
Particionadas: de tal manera que se puedan leer independientemente

porciones individuales de la especificacin.
Mnimamente redundantes: de tal manera que los cambios en los reque

rimientos del usuario puedan incorporarse normalmente en slo una parte
de la especificacin.
Este enfoque, al que por lo general se conoce como anlisis estructurado, se

utiliza ahora en la mayora de las organizaciones de desarrollo de sistemas orienta
dos a los negocios, ai igual que en gran nmero de las orientadas hacia la Ingenie
ra. Se pueden encontrar an algunas organizaciones que produzcan especificaciones
tipo novela victoriana, pero son minora y, como los dinosaurios, se extinguirn.
7,2
CAMBIOS EN EL ANALISIS ESTRUCTURADO CLASICO
Como se mencion anteriormente, el anlisis tradicional de sistemas (que se

caracteriza por especificaciones tipo novela victoriana) empez a cambiar a fines de
los aos 70. La mayora de las organizaciones que ahora usan e! anlisis estructu
rado basan su enfoque en los primeros textos de DeMarco, Gane y Sarson, y Weinberg y otros, a! igual que en seminarios, videos y otros materiales de capacitacin
basados en dichos libros.
Sin embargo, varios aos de experiencia prctica con el anlisis estructurado
clsico han sealado un buen nmero de reas en las que es necesario hacer cam
bios o extensiones. Los principales cambios son:
www.FreeLibros.org
Ei nfasis en ia construccin de modelos fsicos actuales y lgicos ac

tuales del sistema dei usuario se han demostrado que es polticamente
peligroso. A menudo, el equipo encargado del proyecto pasaba tanto
tiempo (a veces hasta seis meses, un ao o ms) estudiando el sistema
anterior, que todo mundo saba que iba a desecharse y reemplazarse con
ei nuevo, que el proyecto acababa siendo cancelado por un usuario impa
ciente antes de que el equipo pudiera darse a la tarea de estudiar ei nue
vo sistema propuesto. Esto no quiere decir que hayamos decidido evitar
modelar el sistema actual del usuario en todos ios casos, sino que simple
mente lo reconocemos como una actividad polticamente peligrosa, a la
que con toda probabilidad se tendr que minimizar, si no eliminar dei todo
en el mundo real. Trataremos esto nuevamente en el captulo 17.
El anlisis estructurado clsico haca una distincin difusa y poco definida

entre ios modelos fsicos (que hacen suposiciones acerca de la tecnolo
ga de la implantacin o estn predispuestos por sta) y ios modelos lgi
cos (que son com pletam ente ind ep e nd ientes de la te cn o lo g a de
implantacin); de hecho, aun los trminos lgico y fsico confunden a mu
chos. [McMenamin y Palmer, 1984] contribuyeron con ideas importantes
a esta rea, e incluso ha cambiado parte de la terminologa: ahora nos re
ferimos a modelos esenciales (modelos de ia esencia de! sistema) en lu
gar de modelos lgicos, y a modelos de implantacin en lugar de modelos
fsicos.
Cada vez son ms las organizaciones que estn usando las tcnicas del
anlisis estructurado para construir sistemas en tiempo reai.6 Sin embar
go, el anlisis estructurado clsico no tiene manera de modelar el com
portamiento dependiente dei tiempo de un sistema; carece de la notacin
necesaria para mostrar interrupciones y seales, y para mostrar la sincro
nizacin y coordinacin de distintas labores de proceso. Para resolver
este problema se ha aadido la notacin necesaria y una herramienta
nueva completa, que incluye flujos de control, procesos de control y dia
gramas de transicin de estados. Esto se trata con ms detalle en los ca
ptulos 9 y 13.
El anlisis estructurado clsico se concentraba casi totalmente en mode

lar las funciones que deberan llevarse a cabo en un sistema; el modelado
de datos se haca de una manera primitiva7 y a menudo se lo desenfatiza
6 Recuerde la definicin y ejem plos de sistem as de tie m p o rea dei ca p tulo 2.

7 Esto tal vez sea un poco injusto, dado que [D eM arco, 1978] y [Gane y Sarson, 1977] dedican un
captulo o ms a las estru ctu ras de datos. Pero su notacin (dia g ra m a s de e stru ctu ra de d a to s')
ahora se considera obsoleta; adem s, la m ayor parte del nfasis de los p rim eros textos era con res
pecto a la conversin de un co njunto a rb itra rio de e stru ctu ras de datos a la te rce ra fo rm a norma!, la
cual es 1) bastante se n cilla com o para que ei p ro ce so se haya m ecanizado y, 2)m s bien una
cuestin de im plantacin que de anlisis de sistem as.
www.FreeLibros.org
ba o incluso se lo ignoraba. Mientras tanto, ms y ms organizaciones

han encontrado que sus sistemas comprenden funciones, relaciones entre
datos y caractersticas de tiempo real, todas ellas complejas. Como he
mos visto, los diagramas de transicin de estados se han aadido al an
lisis estructurado para permitir el modelado de sistemas en tiempo real. Y
para permitir el modelado de sistemas con relaciones complejas entre da
tos se introdujeron los diagramas de entidad-relacin. E! hecho de que
las tres herramientas importantes puedan integrarse, es decir, que pue
dan utilizarse juntas de modo que cada una apoye a las dems, es ms
importante que el aadir una o dos herramientas adicionales de modela
do. Los diagramas de entidad-relacin se explican en el captulo 12, y el
concepto de los modelos integrados se trata en el captulo 14.
7.3
El proceso del anlisis estructurado ha cambiado asombrosamente. El

anlisis estructurado clsico supona que el analista empezara por dibu
jar un diagrama de contexto, es decir, un diagrama de flujo de datos con
una sola burbuja que representa a todo el sistema, y luego lo dividira en
varias funciones y almacenes de datos, en una forma estrictamente des
cendente. Por desgracia, esto no ha funcionado bien, por los motivos que
se discutirn en el captulo 20. En consecuencia, se ha aadido un nuevo
enfoque, conocido como divisin de eventos. La terminologa y el con
cepto bsico de la divisin de eventos los introdujeron [McMenamin y
Palmer, 1984] y los extendieron [Ward y Mellor, 1985].
EL SURGIMIENTO DE HERRAMIENTAS AUTOMATIZADAS
DE ANALISIS
Cuando a finales de los aos 70 y comienzos de los 80 se extendieron las tc

nicas de modelado grfico dei anlisis estructurado en las organizaciones de desa
rrollo de sistemas, los analistas comenzaron a percatarse de que exista un gran
problema: el trabajo necesario para crear diagramas de flujo de datos, diagramas de
entidad-relacin, diagramas de estructura, diagramas de transicin de estados y
otros modelos grficos a menudo era abrumadora. El problema, en la mayora de
los casos, no era la creacin inicial de los diagramas, sino su revisin y manteni
miento. Crear el diagrama inicial consume tiempo, pero por lo menos existe la satis
faccin de que es una actividad intelectual creativa y desafiante. En un proyecto
tpico, el analista encuentra que tiene que volver a dibujar ios modelos grficos va
rias veces antes de que l y los usuarios puedan llegar a algn acuerdo sobre los re
querimientos dei sistema.8
En un sistema muy grande puede haber 50, 100 o ms diagramas de flujo de
datos, diversos diagramas de entidad-relacin y, potencialmente, varios diagramas
www.FreeLibros.org
8 Esto p u diera no serle evid e n te an, pues slo hem os visto unos cuantos d ia g ra m a s de anlisis
estru ctu rad o en el ca p tulo 4. Sin em bargo, para el final de la parte II debiera ser abundantem ente
evidente; si no, espere a ver el fin a l de su p rim er proyecto real de an lisis estructurado.
de transicin de estados; a s que la cantidad de trabajo manual puede ser en verdad

intimidante. La consecuencia prctica de esto, en muchas organizaciones, es que el
a n lis is estructurado clsico no fue tan exitoso como debiera ser. Se plantearon los
siguientes problemas:
Tras la segunda y tercera correciones de un diagrama, el analista se vol

va cada vez ms opuesto y renuente a hacer ms cambios. Por ello, se
podan encontrar diagramas congelados que no reflejaban los verdade
ros requerimientos del usuario.
Debido a la cantidad de trabajo requerido, el analista dejaba a veces de

dividir el modelo del sistema en modelos de menor nivel; es decir, en lu
gar de desarrollar un modelo que consistiera por ejemplo, en cinco nive
les de diagram as de flujo, se detena en el cuarto nivel. El modelo
resultante contena funciones primitivas (esto es, las burbujas que se
muestran en el cuarto nivel) que no eran primitivas en lo ms mnimo; de
hecho, resultaban ser tan complejas que el programador tenia la necesi
dad de llevar a cabo un anlisis adicional del sistema antes de que pudie
ra escribir programas.9
A menudo no se incorporaban en el modelo del sistema ios cambios en

los requerimientos del usuario sino hasta despus de la fase de anlisis
del proyecto. Muchos de estos cambios se daban durante las fases de di
seo, programacin y prueba; otros se daban despus de implantado el
sistema. El resultado era una especificacin obsoleta.
Adems del trabajo que se necesita para crear y mantener los diagramas, el
anlisis estructurado clsico requiere de una gran cantidad de trabajo para verificar
los diagramas con el fin de asegurar que sean consistentes y estn completos; estas
reglas se discuten en el captulo 14.10 Durante los aos 70 y la mayor parte de los
80, los analistas tuvieron que depender de tcnicas de verificacin manual (es decir,
inspeccionar visualmente los diagramas para encontrar errores). Debido a que esta
labor es detallada y aburrida, tiende a estar plagada de errores. En consecuencia,
no se encontraban muchos de ios errores de especificacin que se debieran haber
encontrado.
9 Como se ver en el captulo 11, debiera haber una
crita como tabla de decisiones, diagram a de flu jo o en
da burbuja prim itiva de ltim o nivel del diagram a de
correctamente, la m ayora de las e sp e cificaciones de
gina.
e sp e cificacin ci! proceso (norm alm ente es

un form ato e structurado en espaol) para ca
flu jo de datos. Si el sistem a se ha dividido
proceso deberan se r de m enos de una p
10 Ejem plos de reglas de verificacin : to d os ios flu jo s de datos en un diagram a de flu jo de datos
deben tener nom bre, y los nom bres deben e sta r d e fin id o s en el d iccio n a rio de datos. T odos los
nombres en el d iccionario de d a tos deben co rre sp o n de r con flu jo s de datos o a lm acenes en el dia
grama. Cada burbuja en el diagram a debe tener por lo m enos un flu jo de datos que entra y uno que
sale, etctera.
www.FreeLibros.org
Muchos de estos problemas se pueden resolver con apoyo automatizado ade

cuado. Esto era bien conocido aun desde que por primera vez se introdujo ei anlisis
estructurado clsico, pero el costo de la automatizacin estaba por encima de las
posibilidades econmicas de la mayora de las organizaciones. Sin embargo, el desarrollo de poderosas estaciones de trabajo grficas a mediados de ios aos 80 llev
a una nueva industria llamada CASE (siglas que significan Computer-Aided Software
Engineerng: ingeniera de software auxiliada por computadora). Varios proveedores
ofrecen productos (normalmente basados en PC) que dibujan diagramas de flujo de
datos y otros, adems de llevar a cabo una variedad de labores de revisin de erro
res. Las propiedades y ejemplos de estas herramientas se presentan en el apndice A.
Como se mencion anteriormente, slo el 2 por ciento de los analistas de sis
temas en los Estados Unidos tenan acceso a estas herramientas en 1987, y se
estima que slo el 10 por ciento lo tendrn en 1990. Sin embargo, ste es in
discutiblemente el camino del futuro, y podemos esperar que todos los analistas pro
fesionales insistirn en tales herramientas al transcurrir el tiempo. Esto llevar
primordialmente a un nivel ms elevado de calidad en los modelos de sistemas pro
ducidos. Tambin, de manera secundaria, llevar a modelos grficos del sistema vi
sualmente ms atractivos. En la medida en que los conceptos de revisin de
errores que se discutieron en el captulo 14 sean automatizados, podrn eliminar la
necesidad de que los analistas aprendan el material del captulo 14. Y en la medida
en que las herramientas CASE comiencen a generar programas (en COBOL, Pascal,
o tal vez en un lenguaje de cuarta generacin) directamente desde las especificacio
nes, tambin incluso se reducir la necesidad de programadores.
7.4
EL USO DE PROTOTIPOS
Como se seal en el captulo 3, algunos usuarios tienen dificultades al tratar

con los modelos grficos del anlisis estructurado y prefieren alguna otra forma de
modelar los requerimientos y comportamiento del sistema. Las herramientas de ge
neracin de prototipos, que empezaron a ser muy accesibles a mediados de los
aos 80, se han considerado como una alternativa al anlisis estructurado para tales
usuarios.
Existe otra razn de la popularidad de los prototipos: en muchas organizacio
nes se considera que el anlisis estructurado clsico consume demasiado tiempo;
para cuando concluye la fase de anlisis, el usuario habr olvidado para qu quera
en un principio el sistema. Esto suele ser resultado de alguno de los siguientes pro
blemas:
Ei equipo encargado del proyecto tard demasiado en desarrollar mode

los del sistema actual y luego se tuvo que tardar an ms modelando el
nuevo. Como se mencion anteriormente, ahora consideramos el mode
lado del sistema actual como una actividad polticamente peligrosa.
www.FreeLibros.org
La organizacin invirti previamente poco o nada de tiempo, en hacer

anlisis, pues prefiri codificar lo antes posible. En tal ambiente, el largo
trabajo de anlisis, que aparentemente no produce nada fuera de muchas
imgenes con crculos y rectngulos, pudiera parecerles improductivo,
Los primeros proyectos que se han realizado utilizando el anlisis estruc

turado pudieran consumir ms tiempo de lo normal, pues los analistas es
tn aprendiendo nuevas tcnicas y discutiendo respecto a la mejor forma
de aplicar dichas tcnicas.
Las herramientas de generacin de prototipos (herramientas de software que

al analista construir un simulacro del sistema) se ven, por ello, como una
solucin efectiva a estos problemas. Ntese tambin que el uso de prototipos tiende
a concentrarse en el aspecto de la interfaz humana en los proyectos de desarrollo de
sistemas.
p e rm ite n
Desafortunadamente, las herramientas de generacin de prototipos a veces se

utilizan para evitar los detalles del anlisis y del diseo. En la seccin 5.6 se mostr
un uso apropiado de prototipos.
7.5
EL MATRIMONIO DEL ANALISIS Y EL DISEO DE SISTEMAS
Como se mencion anteriormente en este captulo, las mejoras en la ingenie

ra de software comenzaron con la programacin y el diseo estructurados. De he
cho, estos dos tem as estuvieron sujetos a un consid e ra b le debate en las
organizaciones de desarrollo de sistemas durante la primera mitad de los aos 70.
Tambin fue durante este periodo que empezaron a aparecer los primeros textos so
bre diseo estructurado (vase [Myers, 1975] y [Yourdon y Constantine, 1975]) Los
primeros libros no hacan referencia al anlisis estructurado (puesto que an no se
haban desarrollado los conceptos), mientras que libros posteriores, como [Page-Jones, 1980], incluan una breve resea del tema. El trabajo en anlisis estructurado
comenz a mediados de los 70 y los primeros textos empezaron a aparecer a fines
de esa dcada; pero haba poca o no haba conexin entre el discurso del anlisis
estructurado y el del diseo estructurado. El principal problema era que el anlisis
estructurado trataba con la especificacin de sistemas grandes y complejos, mien
tras que el diseo estructurado pareca ser ms apropiado para el diseo de progra
mas individuales que se ejecutaban en una misma computadora. El puente entre el
anlisis del sistema y el diseo de los programas, es decir, haca falta el diseo de
sistemas.
Este problema So han tratado muchos consultores, autores y organizaciones de
desarrollo de sistemas durante los aos 80. Libros recientes, como el de [WarcI y
Mellor, 1985], as como las ediciones nuevas de [Page-Jones, 1988] y [Yourdon y
Constantine, 1989], tratan ahora puntos del diseo de sistemas al igual que de pro
gramas,
www.FreeLibros.org
7.6
RESUMEN
Como cualquier campo de la ciencia o la ingeniera, el anlisis de sistemas ha

pasado por una serie de cambios evoiucionarios durante los ltimos 20 aos. Como
se indic al comienzo de este captulo, es Importante saber cules han sido estos
cambios porque la industria de la computacin es lo suficientemente amplia como
para que no todo mundo practique ias mismas tcnicas al mismo tiempo. La organi
zacin de usted pudiera estar a la vanguardia de la tecnologa o al triste final de la
cola.
Se puede esperar que el campo del anlisis de sistemas contine. Las tcni
cas que se presentan en este libro habrn evolucionado an ms en en los prximos
cinco a diez aos. En el captulo 25 se aborda la probable naturaleza de dichos cam
bios evolucionarlos.
REFERENCIAS
1.
Tom DeMarco, Structured Analysis and System Specifcatin. Nueva York:

2.
Chris Gane y Trish Sarson, Structured Systems Analysis and Design. Nueva
York: Improved Systems Technologies, Inc., 1977.
3.
Vctor Weinberg, Structured Analysis. Nueva York: YOURDON Press, 1978.
4.
Paul Ward y Steve Mellor, Structured Deveiopment for Real-Time Systems.

Volmenes 1-3. Nueva York: YOURDON Press, 1985.
5.
Steve McMenamin y John Palmer, Essential Systems Analysis. Nueva York:

6.
Glen Myers, Reliable Systems through Composite Design, 1a edicin. Nueva

York: Petrocelli/ Charter, 1975.
7.
Edward Yourdon y Larry Constantine, Structured Design, I a edicin. Nueva

York: YOURDON Press, 1975.
8.
Wleilir Page-Jones, The Practicas Guide to Structured Systems Design, 1a edi

cin, Nueva York: YOURDON Press, 1980.
9.
Meilir Page-Jones, The practicai Guide to Structured Systems Design, 2a edi

cin, Englewood Cliffs, N.J.: Prentice-Hail, 1988.
10.
Edward Yourdon y Larry Constantine, Structured Design, 2a edicin, Englewood

Cliffs, N.J.: Prentice-Hail, 1989.
www.FreeLibros.org
p r e g u n t a s y e j e r c ic io s
Cules son las tres principales razones por las cuales debe estar familiariza
do con la evolucin del anlisis de sistemas?
2.
Qu cree que deba hacer si la organizacin para la que trabaja no ha llevado

a cabo los cambios que se exponen en este captulo?
3.
Mencione cuatro problemas importantes de una especificacin narrativa clsi

ca.
4.
Por qu no es deseable la redundancia en una especificacin de sistemas?

Es posible eliminar por completo la redundancia de la especificacin?
5.
Se le ocurre alguna razn por la cual sera til la redundancia en la especifi

cacin de un sistema?
6.
Cules son las tres principales razones por las que aparece redundancia en
una especificacin clsica?
7.
Qu porcentaje de errores en un sistema operacional pueden atribuirse a

errores que ocurrieron durante ia fase de anlisis dei proyecto?
8.
Proyecto de investigacin: Qu porcentaje de errores puede atribuirse en su

organizacin a errores que ocurrieron durante la fase de anlisis del proyecto?
9.
Cules son las consecuencias de una especificacin imposible de mantener?
10.
Describa brevemente la programacin estructurada.
11.
Describa brevemente el diseo estructurado.
12.
Por qu algunas organizaciones no tuvieron xito al utilizar la programacin y

el diseo estructurados?
13.
Cules son las tres principales caractersticas de una especificacin estructu

rada?
14.
Cules son los cinco principales cambios que se han dado en el anlisis es
tructurado clsico?
15.
Qu problemas enfrenta el anlisis estructurado clsico cuando trata con sis

temas de tiempo real?
16.
Cules son los peligros asociados con modelar el sistema actual del usuario?
Cunto tiempo se debiera dedicar a esto?
www.FreeLibros.org
17.
Cules son los tres principales problemas a los que es probable que el ana
lista se enfrente si no tiene apoyo automatizado para su trabajo?
18.
Es importante contar con apoyo automatizado para proyectos pequeos de

desarrollo de sistemas de informacin? Por qu s o por qu no?
19.
Qu problemas es probable encontrar si el analista tiene que llevar a cabo

manualmente la revisin de errores?
20
Por qu cree que tan slo el 2 por ciento de los analistas de sistemas de los
Estados Unidos tenan estaciones de trabajo automatizadas de anlisis de sis
temas en 1987?
21.
Qu beneficios adicionales podemos esperar al introducir una red de herra

mientas automatizadas de anlisis de sistemas? (Por ejemplo, uno de estos
beneficios es si correo electrnico.)
22.
Cules son los tres principales problemas que han surgido en las organiza
ciones al implantar el anlisis estructurado clsico?
23.
Qu problemas de interfaz existan entre el anlisis estructurado y el diseo

estructurado en los aos 70 y principios de los 80?
www.FreeLibros.org
PARTE l : LA. H E R A M I E N i T . S
SE MODELADO
C ualquier cosa es fcil si puede asim ila rla a su coleccin de m odelos

Seym our Papert, M indstorm s
En sste captulo se aprender:

1. Por qu suelen ser grficas las herramientas de
modelado de sistemas.
2. Por qu se pueden segmentar en forma
descendente las herramientas de modelado de
sistemas.
3. Por qu tienen redundancia mnima las herramien
tas de modelado de sistemas.
4. Por qu ayudan las herramientas de modelado de
sistemas a modelar el comportamiento de un
sistema.
www.FreeLibros.org
149
150 CARACTERISTICAS DE LAS HERRAMIENTAS
L o s siguientes captulos de este libro describen las diversas herramientas de

modelado que usted usar como analista. Antes de ahondar en los detalles de
diagramas de flujo de datos, de entidad-relacin, etc, existen algunos puntos in
ductorios que necesitamos repasar.
Se recordar del captulo 4 que un modelo es un simulacro a bajo costo de un I
sistema complejo que se desea estudiar. Se construyen modelos de sistemas por I
tres motivos:
1.
Para enfocar caractersticas importantes del sistema, a la vez que para

minimizar las caractersticas menos importantes.
2.
Para discutir cambios y correcciones a los requerimientos del usuario, a s

bajo costo y con riesgo mnimo.
3.
Para verificar que se entiende el ambiente del usuario, y que se ha docu

mentado de tal manera que los diseadores y programadores puedan
construir ei sistema.
Sin embargo existen muchos tipos diferentes de modelos que se pueden cons
truir para el usuario: modelos narrativos, modelos de prototipos, modelos grficos di
versos, etc. De hecho, el sistema final que se le construir ai usuario pudiera
resultar ser un modelo, en el sentido de que puede representar, por primera vez, una
manera de que el usuario visualice lo que desea.
En este libro nos concentramos en los modelos en papel (o en modelos en pa- I
pe! producidos por sistemas CASE automatizados). Pero, nuevamente, existe una
gran variedad. Como se apreciar con ms detalle en los siguientes captulos, exis
ten diagramas de flujo, diagramas HIPO, tablas de decisin, diagramas de flujo de
datos, diagramas de flujo de sistemas, diagramas de transicin de estados, rboles
de decisiones, diagramas de entidad-relacin, diagramas de Ferstl, diagramas de
Hamilton-Zeldin, diagramas PAD y una interminable serie de diagramas, tablas y
grficas que se le pueden presentar ai usuario. Cul debemos usar?
La premisa bsica de este libro es que debe usarse cualquier modelo que fun
cione en la situacin en ia que se encuentra. Los diferentes usuarios pudieran re
querir distintas herramientas de modelado, sea por su experiencia pasada o porque
ciertos tipos de diagramas los confunden o intimidan.1 Diferentes proyectos pudie
ran requerir de distintas herramientas para cumplir con ios estndares de documen
tacin im puestos por organizaciones externas. Y diferentes tipos de sistemas
1 Un co ro la rio d e esto es que las buenas herram ientas de m odelado sueien em plear una notacin
sencilla, con pocas reglas, sm bo lo s y vo ca b ulario nuevo que el usuario te n ga que aprender. Un
purista pudiera argum entar incluso que una buena herram ienta no requiere explicacin ni prepara
cin. De cu a lquier m odo, no d e b e ra ser n ecesario leer un Sibro de 700 pginas corno ste para po
der aprender a leer y e n ten d e r un m odelo d e sa rro lla d o por el analista.
www.FreeLibros.org
CARACTERISTICAS DE LAS HERRAMIENTAS 151
requerir de modelos diversos para poder destacar adecuadamente caracte

rsticas importantes.
p u d ie ra n
Para llevar ms lejos esto, la mayora de los sistemas requieren d e mltiples

modelos: cada modelo se enfoca a un nmero limitado de aspectos del sistema, a la
yez que minimiza (o ignora totalmente) otros de sus aspectos. Esto se da sobre to
do en muchos de los sistemas que se estn construyendo actualmente, pues tienen
c a ra c te rs tic a s funcionales complejas, estructuras de datos complejas, y considera
c io ne s complejas de tiempos.
Cualquier herramienta que use debiera tener las siguientes caractersticas:
Debe ser grfica, con detalles textuales de apoyo apropiados.
Debe permitir que el sistema sea visto en segmentos, en forma

descendente.
Debe tener redundancia mnima.
Debe ayudar al lector a predecir el comportamiento dei sistema.
Debe ser transparente para el lector.
A continuacin discutiremos con ms detalle cada uno de estos puntos.
8.1
MODELOS GRAFICOS
La mayora de los modelos populares de sistemas, y todos los que se presen

tan en este libro, se apoyan mucho en grficas. No es requisito usar grficas en un
modelo de sistemas, pero el viejo adagio de que una imagen vale ms que mil pala
bras es una buena explicacin de nuestra preferencia por las grficas en lugar de
texto narrativo. Una imagen bien escogida puede transmitir de manera concisa y
compacta una gran cantidad de informacin.
Esto no significa necesariamente que una imagen pueda describir todo lo refe
rente a un sistema; hacerlo normalmente significara tener un desorden que nadie
quisiera mirar. En general, se utilizan los grficos para identificar los componentes
de un sistema y su interfaz. Todos los dems detalles (sto es, las respuestas a pre
guntas tales como Cuntos? y En qu orden? , etc.) se presentan en documen
tos textuales de apoyo. Los textos de apoyo que se describen en este libro son la
especificacin del proceso y el diccionario de datos.
Esto no significa que todos los analistas deban usar el conjunto particular de
herramientas grficas y de textos que se presentan en este libro; el Gran Analista de
Sistemas que est en el cielo no lo fulminar con sus rayos si no utiliza diagramas
de flujo de datos. Sin embargo, es probable que lo fulmine el rayo si opta por uno de
los extremos de nicamente grficos (sin textos de apoyo) o de slo texto (sin mate
rial grfico). Y seguramente le tocara aunque sea un pequeo relmpago si hiciera
www.FreeLibros.org
152 CARACTERSTICAS DE LAS HERRAMIENTAS
que ei texto fuera la parte dominante del modeio, y que los grficos tuvieran un pa
pe! pequeo y subordinado. Uno o ms grficos debieran ser el documento primarlo
al que se dirige el usuario para poder entender el sistema; los documentos textuales
debieran servir de material de referencia para consulta en caso de necesidad.
8.2
MODELOS SEGMENTABLES EN FORMA DESCENDENTE
Un segundo aspecto importante de una buena herramienta de modelado es su

capacidad de mostrar un sistema por partes en forma descendente. Esto no es im
portante para sistemas pequeos, pues de ellos se puede decir todo lo necesario en
una o dos pginas, y cualquiera que necesite conocer algn aspecto del sistema
bien puede conocerlo en su totalidad.
Sin embargo, los proyectos reales en ei mundo real generalmente no son pe
queos.2 De hecho, muchos de los proyectos en los que es probable que se involu
cre sern desde medianos hasta enormes. En consecuencia, ser imposible que
alguien, sea usuario, analista o programador, se enfoque a todo ei sistema al mismo
tiempo. Tampoco ser posible presentar un modelo grfico de un sistema grande y
complejo en una sola hoja de papel, a menos, claro, que se considere el extremo de
tener una microficha de 2 x 3 metros. Por eso, nuestras herramientas deben permi
tirnos mostrar partes individuales del sistema de manera independiente, junto con
una forma sencilla de moverse de una parte a otra del modelo del sistema.
Sin embargo, se necesita ms que esto: no sera apropiado, por ejemplo, crear
un modelo grfico enorme de 30 x 30 metros y luego cortarlo en 3,600 pedazos indi
viduales de medio metro cuadrado, con miles de conectores de hoja a hoja. Esto
equivaldra, a grandes rasgos, a dibujar un mapa de las calles de todo un pas en
una sola hoja y luego partirla en miles de pedacitos del tamao de una pgina.
De hecho, nuestra experiencia con mapas y atlas ilustra cmo debe organizar
se un modeio de un sistema complejo. Por ejemplo, un atlas de los Estados Unidos
empieza generalmente por un solo diagrama de una pgina de todo el pas, como se
muestra en la figura 8.1. Dicha pgina muestra los estados individuales, y pudiera
tambin mostrar las principales interfaces entre los estados (ros, autopistas interes
tatales, lneas de ferrocarril, rutas areas, etc.). Las siguientes pginas se dedican
normalmente a cada estado individual, en donde cada pgina muestra las ciudades y
condados individuales del estado, al igual que las autopistas locales que no apare
cen en el mapa de nivel nacional. Podramos imaginar mapas de nivel menor que
2 O, dicho de otro modo, los u suarios estn d e sa rro lla n do cada vez m s proyectos pequeos sin
necesidad de analistas o program adores. Con el gran acceso a com putadoras personales, paque
tes de hojas de clcu lo y le nguajes de cuarta generacin, m uchos trabajos que hubieran requerido
das (o incluso sem anas) de dedicacin de un profesional de las com putadoras el usuario puede
hacerlos actualm ente en cuestin de m inutos o de horas. Sin em bargo, an continan desarrolln
dose m uchos sistem as que requieren de m s de 10 m illo n e s de instrucciones para lle va r a cabo su
propsito.
www.FreeLibros.org
proporcionaran detalles de cada condado, de cada ciudad dentro de un condado de

terminado, y de cada barrio dentro de una ciudad dada.
Figura 8.1: Mapa de Estados Unidos
Un buen modelo de un sistema complejo de informacin debera proceder de

la misma manera descendente. Una porcin de la vista global de alto nivel del mo
delo debe dar al lector buena idea de los principales componentes de alto nivel y de
las interfaces del sistema. Las siguientes porciones del modelo deberan proporcio
nar informacin respecto a los componentes detallados de bajo nivel. Y as como el
atlas proporciona un mecanismo conveniente para recorrer el conjunto completo de
-napas individuales (sto es, llegar sin mayor confusin del mapa de nivel nacional
ei mapa apropiado al nivel de condado), un buen modelo de un sistema de informa
ron proporciona un mecanismo conveniente para pasar tranquilamente de un nivel
s to a uno bajo.
-.3
MODELOS MINIMAMENTE REDUNDANTES
Los modelos son representacin de algn sistema dei mundo real y el sistema
mismo pudiera ser esttico (no cambiante) o dinmico. Un mapa de Estados Uni
dos, por ejemplo, es una representacin grfica del pas. Mientras que muchos de
sus aspectos son obviamente muy dinmicos, podra decirse que los aspectos que
-'ocela un mapa son relativamente estticos: los estados individuales no aparecen o
cssaparecen muy a menudo y las fronteras entre ellos han permanecido constantes
durante un tiempo bastante largo. (En cambio, no puede decirse esto de un mapa
us todo el mundo).
www.FreeLibros.org
Por qu importa esto a quien construye un modelo? Simplemente, porque es

deseable mantenerlo en forma actualizada y precisa. Si el sistema cambia, entonces debe cambiar el modelo, si ha de tenerse actualizado. Obviamente, si slo cam
bia un aspecto local del sistem a, preferiram os cam biar slo un aspecto local
correspondiente de! modelo, sin tener por fuerza que cambiar algn otro. De hecho,
si se requieren mltiples cambios, existe una buena probabilidad de que no se ha
gan o de que se harn desordenadamente. Y esto significa que el modelo se volve
r gradualmente menos preciso.
Para ilustrar esto, considere nuevamente nuestro ejemplo del atlas de los Es
tados Unidos . Podemos imaginar, en el caso ms simple, una pgina que muestre
todo el pas, y 50 pginas siguientes que muestren los detalles de cada estado. Aho
ra, imagine qu sucedera si desapareciera el estado de Nueva Jersey:3 el mapa de
nivel nacional tendra que volver a dibujarse para mostrar el nuevo pas de 49 esta
dos, y el anterior mapa de nivel estatal de Nueva Jersey tendra que descartarse.
Sin embargo sera un poco ms difcil con los atlas de verdad, pues, como es
caracterstico de muchos modelos de sistemas, existe alguna redundancia. Cada
mapa de nivel estatal muestra no slo el estado que se describe sino tambin parte
de los que tienen frontera con l. Esta informacin se tiene en el mapa de nivel na
cional, pero es til en el nivel estatal tambin. Esto significa que si desapareciera
Nueva Jersey, probablemente tendramos que redibujar los mapas de Nueva York y
Pennsylvania, e incluso tal vez Delaware y Maryland. Qu molestia.
Los cartgrafos profesionales pudieran objetar esto y argumentar que se nece
sita una cierta cantidad de redundancia para hacer el atlas fcil de leer. Pero debe
ra ser evidente que cuanto ms redundante sea el modelo ms difcil ser de
mantener. Imagine, por ejemplo, que nuestro atlas mtico muestra las autopistas in
terestatales en el mapa nacional y en todos los mapas de nivel estatal. Imagine
tambin que algn emprendedor fabricante de mapas ha decidido mostrar la longitud
completa de cada autopista interestatal en cada mapa estatal que atraviesa. De es
ta forma, la carretera interestatal 95, que va de Maine a Florida, aparecera en alre
dedor de una docena de estados, y en cada uno se escribira el hecho (redundante)
de que la autopista mide 2,700 kilmetros. Y ahora qu sucede si descubrimos que
esta cifra estaba equivocada o que parte de la autopista se extendi o se desvi de
ruta? Obviamente, se tendran que modificar una docena de mapas estatales.
8.4
MODELOS TRANSPARENTES
Finalmente, un buen modelo debe ser tan fcil de leer que el lector no tenga
que detenerse a pensar siquiera que se trata de la representacin de un sistema y
no del sistema mismo. Esto no siempre es fcil de lograr y a menudo requiere de
prctica y preparacin por parte dei lector. Piense por ejemplo en un mapa: qu tan
www.FreeLibros.org
3 Si v iv i en Nueva Je rse y o tiene alguna otra conexin patolgica con este estado, sintase libre
de usar cu a lq u ie r otro para este ejem plo. M is d iscu lp a s a Bruce S pringsteen.
a menudo se pone a pensar en que est mirando una representacin abstracta del
estado de Nueva Jersey y no la realidad misma? Por otro lado, observe a un nio
pequeo que est viendo un mapa mientras sus padres o su maestro pretenden ex
plicarle que el estado de Nueva Jersey tiene frontera con el estado de Nueva York y
que Newark est a quince kilmetros de la ciudad de Nueva York. No, no es cierto,
dir el nio, Newark est a dos centmetros de Nueva York.
Al crecer, nos familiarizamos cada vez ms con el concepto de las representa
ciones abstractas, siempre que nos parezcan cmodas mentalmente. Los cientficos
han estudiado el comportamiento y a organizacin del cerebro humano y han encon
trado que el hemisferio izquierdo realiza los procesos secuenciales. Tambin se ha
ce cargo de los textos; por ejemplo, ias palabras que est leyendo, una tras otra, en
esta pgina. El hemisferio derecho trata con ias imgenes y el procesamiento asin
crnico, donde todo sucede a la vez. Esto indica que si estamos tratando de mode
lar algo que es intrnsecamente lineal y secuencial, como el flujo de control en un
programa de computadora, debemos usar una herramienta de modelado textual que
quepa cmodamente en el hemisferio izquierdo, que ser el mejor equipado para tra
tarlo. Y si estamos tratando de modelar algo que es intrnsecamente multidimensional, con muchas actividades que se dan a la vez, debemos usar una herramienta
grfica.
8.5
RESUMEN
Sin duda estar tan ocupado aprendiendo las herramientas de modelado que
se presentan en este libro que no pensar en la posibilidad de otras. Sin embargo,
s existen, y en el captulo 15 examinaremos brevemente varias otras.
Ms importante an, como analista se ver ante una variedad de herramientas
de modelado en proyectos del mundo rea!. Aunque los detalles (y formas) de estas
herramientas varan mucho, verifique con cuidado si siguen los principios bsicos
que se presentan en este captulo.
1.
Cules son las tres principales razones por las que se hacen modelos de un
sistema?
2.
Describa tres tipos diferentes de modelos de sistemas.
3.
Cules son las caractersticas principales que debe tener una herramienta de
modelado de un sistema?
4.
Por qu se prefieren generalmente las herramientas grficas a las textuales?
www.FreeLibros.org
5.
Es necesario usar herramientas de modelado grfico para desarrollar un sis

tema de informacin? Se le ocurren situaciones donde no quisiera usar di
chas herramientas?
6.
Qu cosas normalmente no muestran los modelos grficos acerca de un sis

tema?
7.
Por qu es importante que una herramienta de modelado muestre el sistema

de manera descendente? Existen situaciones donde no importe?
8.
Requiere la descripcin descendente de un sistema que ste se disee de

manera descendente?
9.
Describa una situacin en la que debiera ser aceptable incluir redundancia en

ei modelo del sistema.
www.FreeLibros.org
(o1.,
DIAGRAMAS DE FLOJO
DE DATOS
La fo rm a siem pre sigue a la funcin.
Louis Henri Sullivan
Ei gran edificio de oficinas, co n sid e ra d o a rtstica m e nte ',
L ip p in c o tts M agazine, m arzo de 1896
E este captulo se aprender:

1. Los componentes de un diagrama de flujo de datos.
2. Cmo dibujar un diagrama de flujo de datos sencillo.
3. Gua para dibujar diagramas eficaces de flujo de
datos.
4. Cmo volver a dibujar diagramas nivelados de flujo
de datos.
En este captulo exploraremos una de las tres herramientas grficas de mode

lado ms importantes del anlisis estructurado: el diagrama de flujo de datos. Esta
es una herramienta que permite visualizar un sistema como una red de procesos
funcionales, conectados entre s por "conducios y tanques de almacenamiento de
datos. En la literatura computaconal, y en sus conversaciones con otros analistas y
usuarios, puede utilizar cualquiera de los siguientes trminos como sinnimos de
diagrama de flujo de datos:
www.FreeLibros.org
157
158 DIAGRAMAS DE FLUJO DE DATOS
Carta de burbujas
DFD (Abreviatura que se usar en todo este iibro)
Diagrama de burbujas
Modelo de proceso
Diagrama de flujo de trabajo
Modelo de funcin
una imagen de lo que est sucediendo aqu
El diagrama de flujo de datos es una de las herramientas ms comnmente

usadas, sobre todo por sistemas operacionales en los cuales las funciones del siste
ma son de gran importancia y son ms complejas que los datos que ste maneja.
Los DFD se utilizaron por primera vez en a ingeniera de software como notacin
para el estudio del diseo de sistemas (por ejemplo, en los libros y artculos de dise
o estructurado tales como [Stevens, Myers y Constantine, 1974], [Yourdon y Cons
tantino, 1975], [Myers, 1975], y otros). A su vez, la notacin se tom prestada de
artculos anteriores sobre teora de grficas, y contina siendo utilizada por losinge
nieros de software que trabajan en la implantacin directa de modelos de los reque
rimientos del usuario.
Estos son antecedentes interesantes, pero con toda probabilidad no sern muy
relevantes para los usuarios a quienes usted mostrar los modelos de DFD del siste
ma; de hecho, probablemente lo peor que pueda usted hacer sea decir, Sr. Usuario,
quisiera mostrarle un modelo grfico-terico descendente y por partes de su siste
ma. En realidad, muchos usuarios estarn familiarizados con el concepto bsico de
DFD, pues la misma notacin ha sido empleada por investigadores de operaciones
durante los ltimos 70 aos para construir modelos de flujo de trabajo de organiza
ciones. Es importante tener esto en mente: los DFD no slo se pueden utilizar para
modelar sistemas de sistemas de proceso de informacin, sino tambin como mane
ra de modelar organizaciones enteras, es decir, corno una herramienta para la pla
neacin estratgica y de negocios.
Empezaremos nuestro estudio de los DFD examinando los componentes de un
diagrama tpico de flujo de datos: el proceso, el flujo, el almacn y el terminador.
Utilizaremos una notacin bastante comn, siguiendo ios textos clsicos de [DeMarco, 1978], [Gane y Sarson, 1977], y otros. Sin embargo, tambin incluiremos la no
tacin de DFD para modelar sistemas de tiempo reai (es decir, flujos de control y
procesos de control). Esta notacin adicional generalmente no se ocupa en los sis
temas dirigidos a los negocios, pero es crucial cuando se modela una variedad de
sistemas cientficos y de ingeniera.
www.FreeLibros.org
DIAGRAMAS DE FLUJO DE DATOS 159
En seguida, revisaremos algunas de las guas de elaboracin de diagramas de

flujo de datos para minimizar las posibilidades de construir un DFD confuso, inco
rre cto o inconsistente. Finalmente, discutiremos el concepto de DFD nivelado como
mtodo de modelar sistemas complejos.
Tenga en mente que el DFD es tan slo una de las herramientas de modelado
disponibles y que nicamente proporciona un punto de vista de un sistema, el orientado a las funciones. Si se est desarrollando un sistema en donde las relaciones
entre datos son ms importantes que las funciones, tal vez se d menos importancia
a opD ( o incluso ni nos molestemos en elaborarlo), para concentrarse ms bien en
desarrollar un conjunto de diagramas de entidad-relacin, como se expone en el ca
pitulo 12. De otra manera, si el comportamiento dependiente del tiempo de un siste
ma domina sobre cualquier otro factor, tal vez nos concentremos ms en el diagrama
de transicin de estados que se discute en el captulo 13.
LOS COMPONENTES DE UN DFD
9.1
La figura 9.1 muestra un DFD tpico para un sistema pequeo. Antes de exa
minar sus componentes en detalle, ntese lo siguiente:
Prcticamente no requiere explicacin; se puede simplemente mirar el

diagrama y entenderlo. La notacin es sencilla y clara y, en cierto senti
do, intuitivamente obvia. Esto es particularmente importante cuando re
cordamos quin se supone que est viendo la figura 9.1: no el analista,
sino ei usuario. S el usuario necesita una enciclopedia para poder leer y
entender el modelo de su sistema, probablemente no se tomar la moles
tia de hacer ninguna de las dos cosas.
El diagrama cabe fcilmente en una pgina. Esto significa dos cosas: 1)

alguien puede mirarlo sin ofuscarse y 2) el sistema que se est modelan
do no es muy complejo. Qu se hace si el sistema es intrnsecamente
complejo, tanto -p o r ejem plo- que hubiera literalmente cientos de crcu
los y lneas en el diagrama? Discutiremos esto en la seccin 9.4.
El diagrama se dibuj con computadora. Nada tiene de malo un diagrama

hecho a mano, pero la figura 9.1 y muchos de los otros DFD que se
muestran en este libro se hicieron con la ayuda de un programa de la Ma
cintosh llamado MacDraw. Esto significa que el diagrama probablemente
se har de manera ms ordenada y estndar que lo que en general sera
posible a mano. Tambin significa que se pueden hacer cambios y pro
ducir nuevas versiones en cuestin de minutos.1
1 Sin em bargo, la d esventaja de M acD raw (y de otros program as genricos por ei estilo) es que no
sabe nada de la naturaleza especial de ios DFD o de otros m odelos de sistem as que se presentan
en este libro. Slo m aneja figuras p rim itivas com o rectngulos, crculos y lneas. Los paquetes de
herramientas para analistas que se discuten en el A pndice A son ms poderosos, pues m anejan
mucho acerca de DFD.
www.FreeLibros.org
CLIEN TES
Pedidos
cancelados
BO DEG A
Contabilidad
Nom bre del

cliente, detalles
de la factura
Figura 9.1: DFD tpico
9.1.1
El proceso
El primer componente del DFD se conoce como proceso. Los sinnimos co

munes son burbuja, funcin o transformacin. El proceso muestra una parte del sis
tema que transforma entradas en salidas; es decir, muestra cmo es que una o ms
entradas se transforman en salidas. Ei proceso se representa grficamente como un
crculo, como se muestra en la figura 9.2(a). Algunos analistas prefieren usar ur,
valo o un rectngulo con esquinas redondeadas, como se muestra en la figura
9.2(b); y otros prefieren usar un rectngulo, como se muestra en la figura 9.2(c).
Las diferencias entre estas tres formas son puramente cosmticas, aunque obvia
mente es importante usar la misma forma de manera consistente para representar
todas las funciones de un sistema. A lo largo de este libro utilizaremos el crculo o
burbuja.2
2 La fig u ra que el an a lista utilice para e proceso a m enudo se asocia con una e scu e la pa
i
de an lisis estructurado. Ei crculo se asocia con la escuela Y o urdon/D eM arco , pues se ut l za
va rio s te xto s p u b lic a d o s p o r YO U R D O N Press, lo m ism o q ue en las a ctiv id a d e s de consulta y
ad ie stra m ie n to de YO U R D O N Inc. De m anera sim ilar, el valo se a socia a m enudo con la escueie
G ane/S arson , pues lo introdujeron Chris G ane y T rish S arson en su libro [G ane y Sarson, 1977], y
www.FreeLibros.org
CALCULAR \
IMPUESTOS \
DEVENIAS
Figura 9.2(a): Ejemplo de un proceso
CALCULAR
IMPUESTOS
DE VENTAS
V__________________ y
Figura 9.2(b): R epresentacin alternativa de un proceso
CALCULAR
IMPUESTOS
DE VENTAS
Figura 9.2(c): Una representacin ms de un proceso
Ntese que el proceso se nombra o describe con una sola palabra, frase u
oracin sencilla. En casi todos ios DFD que se discutirn en este libro, el nombre
del proceso describir lo que hace. En la seccin 9.2 hablaremos ms acerca de la
nomenclatura correcta para burbujas de proceso. Por ahora es suficiente decir que
un buen nombre generalmente consiste en una frase verbo-objeto tal como VALI
DAR ENTRADA o CALCULAR IMPUESTO.
fue usado por M cDonnell Douglas Autom ation C om pany (M cA uto) y varias o rg a n iza cio n e s m s. La
figura rectangular sueie a sociarse con la escuela S A D T , pues la p o p ularizaron d iversos artculos
acerca de la t cn ica de Softech para D iseo y A n lisis E structurado (SADT); vase, por ejem plo,
[Ross y Schom an, 1977],
www.FreeLibros.org
En algunos casos, el proceso contendr el nombre de una persona o un grupo

(por ejemplo, un departamento o una divisin de una organizacin), o de una computadora o un aparato mecnico. Es decir, el proceso a veces describe quin o qu io
est efectuando, ms que describir el proceso mismo. Discutiremos esto con ms
detalle en ei captulo 17 cuando veamos ei concepto de modelo esencial, y ms ade*
lante en la parte IV, cuando veamos los modelos de implantacin.
9.1.2
El flujo
Un flujo se representa grficamente por medio de una flecha que entra o sale
de un proceso; un ejemplo se muestra en la figura 9.3. El flujo se usa para describir
el movimiento de bloques o paquetes de informacin de una parte dei sistema a otra,
Por ello, ios flujos representan datos en movimiento, mientras que los almacenes
(que se describen en la seccin 9.1.3) representan datos en reposo.
En ia mayora de los sistemas que modele como analista, los flujos realmente
representarn datos, es decir, bits, caracteres, mensajes, nmeros de punto flotante
y los diversos otros tipos de informacin con los que las computadoras pueden tra
tar, Pero los DFD tambin pueden utilizarse para modelar otros sistemas aparte de
los automatizados y computarizados; pudiera escogerse, por ejemplo, usar un mode
lo de DFD para modelar una lnea de ensamblado en la que no haya componentes
computarizados. En tales casos, los paquetes o fragmentos mostrados por los flujos
sern tpicamente materiales fsicos. Un ejemplo de esto se muestra en la figura
9.4. Para muchos sistemas complejos del mundo real, el DFD mostrar el flujo de
materiales y datos.
Ntese que ios flujos de las figuras 9.3 y 9.4 tienen nombre. El nombre repre
senta el significado del paquete que se mueve a lo largo del flujo. Un corolario de
esto es que el flujo slo lleva un tipo de paquete, como io indica su nombre. El ana
lista no debe dar al flujo un nombre como MANZANAS Y NARANJAS Y ARTICU
LOS Y VARIAS COSAS MAS. Sin embargo, veremos en la parte III que hay
excepciones a este convenio: a veces es til consolidar varios flujos elementales en
www.FreeLibros.org
uno solo. Por ello, se pudiera ver un solo flujo llamado VEGETALES en lugar de di
versos flujos llamados PAPAS, COLES DE BRUSELAS y CHICHAROS. Como ve
remos, esto requerir de alguna explicacin en el diccionario de datos, que se
discutir en el captulo 10.
Figura 9,4: DFD con flujo de materiales

Aunque parezca obvio, tenga en mente que el mismo contenido pudiera tener
distintos significados en distintas partes del sistema. Por ejemplo, considere el frag
mento de sistema que se muestra en la figura 9.5.
El mismo fragmento de datos por ejemplo, 212-410-9955) tiene distinto signifi
cado cuando viaja a lo largo de un flujo llamado NUMERO TELEFONICO que cuan
do viaja a lo largo de uno llamado NUMERO TELEFONICO VALIDO. En el primer
caso, significa un nmero telefnico que pudiera ser o no vlido; en el segundo ca
so, significa un nmero telefnico que, dentro del contexto de este sistema, se sabe
que es vlido. Otra forma de verlo es que el flujo denominado nmero telefnico" es
como un ducto, lo suficientemente poco discriminador como para permitir el paso de
nmeros no vlidos al igual que vlidos; el flujo denominado NUMERO TELEFONI
CO VALIDO es ms estrecho, o ms discriminador, y permite pasar datos definidos
ms estrechamente.
Ntese tambin que los flujos muestran la direccin: una cabeza de flecha en
cualquier extremo (o posiblemente ambos) del flujo indica si los datos (o el material)
se est moviendo hacia adentro o hacia afuera de un proceso (o ambas cosas). El
flujo que se muestra en la figura 9.6(a), por ejemplo, indica claramente que el nme
ro se est mandando hacia el proceso denominado VALIDAR NUMERO TELEFONI
CO. Y el flujo denominado HORARIO DE ENTREGA DE CHOFERES de la figura
9.6(b) claramente indica que es una salida generada por el proceso GENERAR HO
RARIO DE ENTREGA DE CHOFERES. Los datos que se mueven a lo largo de di-
www.FreeLibros.org
Figura 9.5: DFD tpico
cho flujo viajarn ya sea a otro proceso (como entrada) o a un almacn (como se
discutir en la seccin 9.1,3) o a un terminador (como se indica en la seccin 9.1.4),
El flujo de dos cabezas que se muestra en la figura 9.6(c) es un dilogo, es decir, un
empacado conveniente de dos paquetes de datos (una pregunta y una respuesta) en
el mismo flujo. En el caso de un dilogo, los paquetes en cada extremo de la flecha
deben nombrarse, como se ilustra en la figura 9,6(c).3
Figura 9.6(a): Flujo de entrada

Los flujos de datos pueden divergir o converger en un DFD; conceptualmente
esto es algo as como un ro principal que se divide en varios ms pequeos, o va
rios pequeos que se unen. Sin embargo, esto tiene un significado especial en un
DFD tpico en el cual hay paquetes de datos que se mueven a travs del sistema: en
3 Una alte rn a tiva aceptable en lugar del d ilogo es el uso de dos flu jo s diferentes, uno que muestre
las entradas (preguntas) a un proceso y o tro que m uestre las salidas (respuestas). Esto es, de he
cho, una m ejor form a de m anejar las cosas si una entrada puede llevar a d iversas accio n e s (y res
puestas) del proceso. En el caso de una situacin se n cilla de pregunta-respuesta, el uso de un
flu jo de dilogo o de flu jo s de entrada y salida separados es cosa de gustos. La m ayora de loa
an alistas prefieren la notacin de dilogo porque 1) recalca al lector que los flu jo s de e ntrada y sali
da estn relacionados entre s y 2) reduce la com plejidad del diagram a.
www.FreeLibros.org
el caso de un flujo divergente, esto significa que se estn mandando copias por du
plicado de un paquete de datos a diferentes partes del sistema, o bien que un pa
cate complejo de datos se est dividiendo en varios paquetes individuales ms,
cada uno de los cuales se est mandando a diferentes partes del sistema, o que el
d i, co de flujo de datos lleva artculos con distintos valores (por ejemplo, vegetales
cuyos valores pudieran ser papa, col de bruselas o ejote) que estn siendo se
parados. De manera inversa, en el caso de un flujo convergente, significa que va
rios paquetes elementales de datos se estn uniendo para formar agregados ms
com p le jos de paquetes de datos. P o r ejemplo, a figura 9.7(a) muestra un D F D en ei
cual el flujo denominado DETALLES DE ORDENES diverge y lleva copias de los
m ism os paquetes a ios procesos GENERAR DOCUMENTOS DE ENVIO, ACTUALI
ZAR INVENTARIO y GENERAR FACTURAS. La figura 9.7(b) muestra como el flujo
DOMICILIO DE CLIENTE se divide en los paquetes ms elementales NUMERO TE,EC0NIC0, CODIGO POSTAL, y CALLE Y NUMERO, los cuales se mandan a tres
ye sesos de validacin diferentes.4
Figura 9.6(b): Flujo de salida
/D E T E R M IN A R \
[
S T A T U S DE
p e d id o
PR EG U N TA s o b r e s t a t u s d e p e d id o
N -------------------------
*respuesta
de
s ta tu s
de
p e d id o
Figura 9.6(c): Flujo de dilogo

4 Cmo se realiza exactam ente este proceso de duplicado o de scom posicin de paquetes de datos
se considera asunto de la im plantacin, es decir, algo de lo que se tendr que p re ocupar ei disea
dor, pero que ei analista no necesita m ostrar en el m odelo dei sistem a. A la larga pudiera llevarse
a cabo por hardware o softw are, m anualm ente, o por m agia negra. Si ei a n alista est m odelando
un sistema ya existente, puede haber tentacin de m ostrar ei m ecanism o {es decir, ei proceso) que
lisva a cabo la d u p lica ci n/ descom posicin de datos. Se d iscu tir esto m s a fondo en la parte lli.
www.FreeLibros.org
Mtese que ei flujo no responde a muchas dudas de procedimiento que pudieJ

ra tener cuando est viendo un DFD: no responde a dudas acerca de peticin de ervl
iradas o de flujos de salidas, por ejemplo. La figura 9.8(a) muestra el caso sencij
de un flujo de entrada que sale del proceso denominado PROCESAR ORDEN. p6,j
ro cmo sucede esto? PROCESAR ORDEN pide explcitamente al usuario las er.!
Iradas? O se mueven los paquetes a lo largo dei flujo por su propia voluntad, siiu
ser pedidos? Similarmente, la figura 9.8(b) muestra un flujo de salidas sencillo qyEl
emana de GENERAR REPORTE DE FACTURAS. Acaso las FACTURAS se mu* 1
ven a lo largo del flujo cuando GENERAR REPORTE DE FACTURAS los quier*
mandar, o cuando alguna otra parte del sistema pide el paquete? Finalmente, consi
dere la situacin ms comn que se muestra en la figura 9.8(c), en donde hay mltipies flujos de entrada y de salida: en qu secuencia llegan los paquetes de datos *
en qu secuencia se generan los paquetes de salida? Es decir, el proceso Q re
quiere exactamente un paquete de los flujos A, B y C para producir exactamente uil
paquete de salida para los flujos X, Y y Z? O existen dos Aes para cada tres Bes? I
www.FreeLibros.org
Figura 9.7(a): Flujo divergente
Figura 9.7(b): Otro ejemplo de flujo divergente
Figura 9.8(a): Flujo de entrada
www.FreeLibros.org
figura 9.8(b): Flujo de salida
La respuesta a todas estas preguntas es muy sencilla: no sabemos. Todas es

tas interrogantes acarrean detalles de tipo procedimiento, que son el tipo de pregun
ta que se modelara normalmente con un diagrama de flujo de datos o alguna otra
herramienta de modelado de tipo procedimiento. El DFD simplemente no intente
abordar estas cuestiones. Si estas preguntas se vuelven importantes, entonces ten- l
dr que modelarse el procedimiento interno de los diversos procesos; las herramientas para hacer esto se discuten en el captulo 11.
9.1.3
El almacn
El almacn se utiliza para modelar una coleccin de paquetes de datos en re- |

poso. Se denota por dos lneas paralelas, como ios muestra a figura 9.9(a); una al
ternativa de notacin se muestra en la figura 9,9{b);5 otra ms, que se utiliza en el :
caso de estudio del apndice F, se muestra en la figura 9.9{c). De modo caracters
tico el nombre que se utiliza para identificar al almacn es el plural dei que se utiliza
para ios paquetes que entran y salen del almacn por medio de flujos.
PEDIDOS
Figura 9.9(a): Representacin grfica de un almacn
www.FreeLibros.org
5 La notacin D I en la fig u ra 9.9(b) es sim plem ente una num eracin que sirve para d istin g u ir este
alm acn de otro s que hay en ei diagram a. La convencin que sigue este libro no pide etiquetar o
num erar los alm acenes (sim plem ente porque no ha parecido necesario, ni siq u ie ra til), pero (como
verem os en a seccin 9.2), s involucra ia num eracin de las burbujas.
DI
PEDIDOS
Figura 9.9(b): Notacin a lternativa para un almacn
PEDIDOS
Figura 9.9(c): Notacin usada en el apndice F

Para el analista con conocimientos de proceso de datos es tentador referirse a
l0S almacenes como archivos o bases de datos (por ejemplo, un archivo en. cinta
magntica o un archivo de disco organizado con IMS, DB2, ADABAS, 1DMS, o algn
otro sistema de manejo de bases de datos. De hecho, es as como a menudo se im
plantan los almacenes en un sistema computarizado; pero un almacn tambin pu
diera consistir en datos almacenados en tarjetas perforadas, microfilm, microfichas,
disco ptico o alguna ms de otras posibles formas electrnicas. Y un almacn tam
bin puede ser un conjunto de fichas de papel en una caja de cartn, nombres y do
micilios en un directorio, diversos archivos en un archivero, o varias formas no
computarizadas. La figura 9.9(d) muestra un ejemplo caracterstico de almacn en
un sistema manual existente. Es precisamente debido a la variedad de formas de im
plantacin posibles de un almacn que deliberadamente escogimos una notacin
grfica simple y abstracta as como el trmino almacn en lugar de, por ejemplo, ba
se de datos.6
Aparte de la forma fsica que toma el almacn, tambin existe la cuestin de
su propsito: Existe el sistema por causa de un requerimiento fundamental del
usuario o por algn aspecto conveniente de la realizacin del sistema? En el primer
caso, la base de datos existe como un rea de almacenamiento diferida en ei tiem; necesaria entre dos procesos que ocurren en momentos diferentes. Por ejem: j , la figura 9.10 muestra un fragmento de un sistema en el cual, como poltica de!
usuario (independientemente de la tecnologa que se use para implantar ei sistema),
: proceso de entrada de rdenes puede operar en tiempos diferentes (o posible
mente en el mismo) que el proceso de Investigacin de rdenes. El almacn de OR
DENES debe existir en alguna forma, ya sea en disco, cinta, tarjetas o inscrito en
adra.
ambin es com n refe rirse a un paquete de inform acin
sus com ponentes com o cam pos. Nada tiene de m alo esta
ei contexto de ias bases de datos que es probable que
anteriormente. Por ahora, utilizarem os e trm ino paquete
coleccin de objetos relacionados en un alm acn.
dei alm acn com o registro, y referirse a

te rm in o lo g a, pero se usa tan a m enudo
ocasione el tipo de problem as discutido
para de scrib ir una sola instancia de una
www.FreeLibros.org
Figura 9.9(d): Otro tip o de almacn
La figura 9.11 (a) muestra un tipo distinto de almacn: el almacn de implanta

cin. Podemos imaginar al diseador del sistema interponiendo un almacn de OR.
DENES entre ENTRA ORDEN y PROCESA ORDEN porque:
Se espera que ambos procesos se ejecuten en la misma computadora,

pero no hay suficiente memoria (o algn otro recurso de hardware) para
cubrir ambos al mismo tiempo. As, el almacn de ORDENES se crea co
mo archivo intermedio, pues la tecnologa de implantacin disponible ha
forzado a que los procesos se ejecuten en tiempos distintos.
Se espera que cualquiera de los procesos, o ambos, se ejecuten en una

configuracin de hardware que es poco confiable. As, el almacn de OR
DENES se crea como respaldo en caso de que cualquiera de los proce
sos se aborte.
DETALLES DE
PEDIDOS
www.FreeLibros.org
Se espera que diferentes programadores implanten los dos procesos (o,

en un caso ms extremo, que lo hagan diferentes grupos de programadores que trabajan en lugares geogrficos distintos). As, el almacn de
ORDENES se crea para probar y corregir, de manera que si el sistema
completo no trabaja ambos grupos puedan ver los contenidos del almacn
y detectar el problema.
Ei analista o el diseador pensaron que el usuario pudiera algn da ha

cer accesos al almacn de ORDENES por alguna otra razn, aun cuando
no haya expresado tal inters. En este caso, el almacn se crea antici
pando necesidades futuras del usuario (y dado que costar algo implantar
el sistema de esta manera, el usuario acabar pagando por algo que no
se pidi).
Si fueran a excluirse los asuntos y modelar slo los requerimientos esenciales

del sistema, no existira necesidad de un almacn deORDENES; enlugar de eso se
tendra un DFD como el que se muestra en la figura 9 . 1 1(b).
Como hemos visto hasta ahora, ios almacenes se conectan por flujos a los
procesos. As, el contexto en el que se muestra un almacn en un DFD es uno de
los siguientes (o ambos):
Un flujo desde un almacn
Un flujo hacia un almacn
www.FreeLibros.org
Figura 9.11 (a): Almacn de implantacin
Figura 9 ,1 1(b): Alm acn de im plantacin elim inado

En la mayora de los casos, los flujos se etiquetarn como se discute en la
seccin 9.1.3. Sin embargo, muchos analistas no se molestan en etiquetar el flujo si
una instancia completa del paquete fluye hacia o desde el almacn.7 Por ejemplo, la
figura 9.12 muestra un fragmento tpico de un DFD.
Normalmente se interpreta un flujo que procede de un sistema como una lectu
ra o un acceso a la informacin del almacn. Esto significa especficamente que:
Se recupera del almacn un solo paquete de datos; esto es, de hecho, el

ejemplo ms comn de flujo desde un almacn. Imagnese, por ejemplo,
un almacn llamado CLIENTES, donde cada paquete contiene nombre,
domicilio y nmero telefnico de los clientes individuales. As, un flujo t
pico del almacn podra implicar la recuperacin de un paquete completo
de informacin acerca de un cliente.
Se ha recuperado ms de un paquete del almacn. Por ejemplo, el flujo

podra recuperar paquetes de informacin acerca de todos los clientes de
la ciudad de Nueva York del almacn CLIENTES.
Se tiene una porcin de un paquete del almacn. En algunos casos, por

ejemplo, slo se podra recuperar la informacin del nmero telefnico del
cliente del almacn CLIENTES.
7 M encionarem os varias co n venciones de este tipo en este captulo, lo m ism o que d iversas ms re
lacionadas con otras herram ientas de m odelado. El a d m in istra d o r del proyecto, el m anual de es
t n da re s o la herram ienta CASE que est usando para su proyecto (vea el apndice A) pudieran
ob lig a rlo a usar una convencin u otra, pero debe ver que existe una cie rta fle xib ilid a d en cuanto a
las herram ientas y notacin que se presentan aqu. Lo im portante es la co n siste ncia: to d os ios flu
jo s portadores de paquetes que entran o salen de un alm acn deben etiquetarse o no etiquetarse
de m anera consistente.
www.FreeLibros.org
Figura 9.12: Alm acenes con flu jo s no etiquetados
Se tienen porciones de ms de un paquete del almacn. Por ejemplo, un

flujo podra recuperar del almacn CLIENTES la porcin del cdigo postal
de todos los clientes que viven en el estado de Nueva York.
Como notamos antes cuando examinamos los flujos que entraban y salan de
un proceso, tendremos muchas preguntas de tipo procedimiento cuando examine
mos los flujos que entran y salen de un almacn: representa el flujo un solo paque
te, muchos, porciones de uno o porciones de diversos paquetes? En algunos casos,
podemos darnos cuenta simplemente viendo la etiqueta del flujo: si el flujo no est
etiquetado, significa que todo el paquete de informacin se est recuperando (como
se dijo antes esto es simplemente una convencin cmoda); s la etiqueta del flujo
es la misma que la del almacn significa que se recupera todo un paquete (o mlti
ples instancias de uno completo); si la etiqueta del flujo es diferente del nombre del
almacn, entonces se estn recuperando uno o ms componentes de uno o ms
paquetes.8
8 Cmo podem os saber que las etiquetas del flu jo tienen que ver con los com ponentes de un pa
quete de inform acin del alm acn? Cm o saber, p or ejem plo, que el flu jo etiquetado com o NU
MERO T E LE FO N IC O tie n e a lg o q u e v e r co n lo s p a q u e te s de in fo rm a c i n d e l a lm a c n de
CUENTES? Es tentador, sobre todo en un proyecto real donde to d o m undo est relativam ente fa
miliarizado con el tem a, d e cir sim plem ente Es que es o b vio . Por su p u esto que el nm ero de tel
fono form a p a rte del p a q u e te del clie n te . Pero, p a ra e s ta r se g u ro , se re q u ie re una d e fin ici n
rigurosa de la com posicin del paquete CLIENTES. Esto se encuentra en el d iccio n a rio de datos,
que se discutir en el c a p tulo 10.
www.FreeLibros.org
A pesar de que algunas de las preguntas de tipo procedimiento pueden res

ponderse viendo con cuidado las etiquetas del flujo, no sern evidentes todos los de
talles. De hecho, para conocer todo lo deseado acerca del flujo que emana del
almacn, tendrn que examinarse los detalles: la especificacin del proceso al cual
se conecta el flujo. Las especificaciones de proceso se examinan en el captulo 11,
Existe un detalle de tipo procedimiento dei cual podemos estar seguros: el al
macn es pasivo, y los datos no viajarn a lo largo del flujo a menos que el proceso
lo solicite explcitamente. Existe otro detalle de tipo procedimiento que suponen, por
convenio, los sistemas de proceso de datos: el almacn no cambia cuando un pa
quete se mueve del almacn a lo largo del flujo. Un programador pudiera referirse a
esto como una lectura no destructiva o, en otras palabras, del almacn se recupera
una copia del paquete y el almacn mantiene su condicin original.9
Un flujo hacia un almacn habitualmente se describe como una escritura, una
actualizacin o posiblemente una eliminacin. Especficamente, slo puede signifi
car que se tiene una de las situaciones siguientes:
Se estn guardando uno o ms paquetes nuevos en el almacn. Depen

diendo de la naturaleza dei sistema, los paquetes nuevos pudieran ane
xarse (es decir, de alguna manera acomodarse para que estn despus"
de los paquetes existentes); o pudieran colocarse en algn lado entre los
paquetes existentes. Esto es a menudo un asunto de la implantacin (es
decir, controlado por el sistema especfico de administracin de bases de
datos), por lo que el analista no debiera preocuparse acerca de ello. Po
dra ser, sin embargo, cuestin de una poltica del usuario.
Uno o ms paquetes se estn borrando o retirando del almacn.
Uno o ms paquetes se estn modificando o cambiando. Esto pudiera

traer consigo un cambio de todo un paquete, o (ms comnmente), de s
lo una porcin, o de una porcin de mltiples paquetes. Por ejemplo, su
ponga que la polica tiene un alm acn de sospechosos y que cada
paquete contiene sus nombres y domicilios; puede ofrecrsele una nueva
identidad a un sospechoso que coopera, en cuyo caso toda la informa
cin relacionada con su paquete cambiara. Como alternativa, considere
un almacn CLIENTES que contenga informacin acerca de ios clientes
que residen en Manhattan; si la oficina de correos decidiera cambiar el
cdigo postal para un rea de Manhattan (como sucedi en 1983, cuando
9 Si est usando un DFD para m odelar a lg o que no sea puram ente un siste m a de proceso de infor
m acin, esto pudiera no darse. Por ejem plo, un alm acn puede co ntener cosas fsica s, y el flujo
puede ser un m ecanism o para tra n sfe rir m ateriales del alm acn al proceso. En este caso, se saca
ra tsica m e n te un paquete d e l alm acn y, com o resultado, te n dra m enos con ten id o s. En un mode
lo de siste m a que c o n ten g a alm acenes de inform acin y a lm acenes fsico s, es im p orta n te hacer
an otaciones en el DFD (o d a r e xp lica cio n es en el diccio n a rio de datos) para que el le cto r no se con
funda.
www.FreeLibros.org
el rea de Manhattan donde yo viva cambi de cdigo 10028 a 10128),

se necesitara un cambio a una porcin de diversos paquetes.
En todos estos casos es evidente que el almacn cambi como resultado del
flujo que ingresa. El proceso (o procesos) conectados con el otro extremo del flujo
es e| responsable de realizar ei cambio ai almacn.
Un punto que debiera ser evidente de todos los ejemplos que se han mostrado
hasta ahora es el siguiente: los flujos conectados a un almacn slo pueden trans
portar paquetes de informacin que el almacn sea capaz de guardar. Por elio, un
flujo conectado a un almacn CLIENTES slo puede transportar informacin relacio
nada con los clientes contenidos por ei almacn; no puede transportar paquetes de
inventarios o paquetes de manufactura o datos astronmicos.
g.1.4
El Term inador
El siguiente componente del DFD es un terminador; grficamente se represen

ta como un rectngulo, como se muestra en la figura 9.13. Los terminadores repre
sentan entidades externas con las cuales el sistema se comunica. Comnmente, un
terminador es una persona o un grupo, por ejemplo, una organizacin externa o una
agencia gubernamental, o un grupo o departamento que est dentro de la misma
compaa u organizacin, pero fuera del control del sistema que se est modelando.
En algunos casos, un terminador puede ser otro sistema, como algn otro sistema
computacional con el cual se comunica ste.
DEPARTAMENTO
DE CONTABILIDAD
Figura 9.13: Representacin grfica de un term inador
Suele ser muy fcii identificar los terminadores en el sistema que se est mo
delando. A veces el terminador es ei usuario; es decir, en sus discusiones con el
usuario, ste dir Pretendo suministrar al sistema los datos X, Y y Z, y espero que
me regrese los datos A, B y C. En otros casos, el usuario se considera parte del
sistema y ayudar a identificar ios terminadores relevantes; por ejemplo, le dir Te
nemos que estar listos para recibir las formas tipo 321 dei departamento de contadu
ra, y debemos enviar reportes financieros semanales al comit de finanzas. En
este ltimo caso, es evidente que el departamento de contadura y el comit de fi
nanzas son terminadores separados con los cuales se comunica el sistema.
www.FreeLibros.org
Existen tres cosas importantes que debemos recordar acerca de los termina
dores:
1.
Son externos al sistema que se est modelando; los flujos que conectan
los terminadores a diversos procesos (o almacenes) en el sistema repre
sentan la interfaz entre l y el mundo externo.
2.
Como consecuencia, es evidente que ni el analista ni el diseador del sis

tema estn en posibilidades de cambiar los contenidos de un terminado? o
la manera en la que trabaja. En el lenguaje usado por diversos libros de
texto clsicos sobre anlisis estructurado, el terminado? est fuera del do
minio del cambio. Lo que esto significa es que el analista est modelando
un sistema con la intencin de permitir una considerable flexibilidad y li
bertad al diseador para elegir la mejor implantacin posible (la ms efi
ciente o la ms confiable, etc.). El diseador puede implantar el sistema
de manera bastante diferente de aquella en la que actualmente est im
plantado; el analista puede escoger modelar los requerimientos del siste
ma en forma que se vea considerablemente diferente de la manera en la
que actualmente el usuario visualiza mentalmente ei sistema (se ver
ms acerca de esto en la seccin 9.4 y la parte III). Sin embargo, el ana
lista de sistemas no puede modificar los contenidos, la organizacin ni los
procedimientos internos asociados con los terminadores.
3.
Las relaciones que existan entre los terminadores no se muestran en el

modelo de DFD. Pudieran existir de hecho diversas relaciones, pero, por
definicin, no son parte dei sistema que se est estudiando. De manera
inversa, si existen relaciones entre los terminadores y si es esencial para
el analista modelarlos para poder documentar los requerimientos del sis
tema, entonces, por definicin, ios terminadores son en realidad parte del
sistema y debieran modelarse como procesos.
En los ejemplos sencillos que se han discutido hasta ahora hemos visto slo
uno o dos terminadores. En un sistema real tpico pueden existir docenas de termi
nadores diferentes interactuando con l. Identificar los terminadores y su interaccin
con el sistema es parte del proceso de construir el modelo del ambiente, que se dis
cutir en el captulo 17.
9.2
GUIA PARA LA CONSTRUCCION DE DFD
En la seccin anterior vimos que los diagramas de flujo de datos constan de

cuatro componentes sencillos: procesos (burbujas), flujos, almacenes y terminadores, Armado con estas herramientas, puede comenzar a entrevistar a los usuarios y
a construir modelos de DFD de sistemas.
www.FreeLibros.org
Sin embargo, existe un nmero de reglas adicionales que se requieren para
poder utilizar DFD con xito. Algunas de estas reglas ayudarn para no elaborar
DFD errneos (por ejemplo, incompletos o lgicamente inconsistentes). Algunas de
(aS regas tienen la finalidad de ayudarle para que dibuje un DFD grato a la vista, y
que, por tanto, tenga ms probabilidades de que lo lea con cuidado el usuario.
Las reglas incluyen las siguientes:
1.
2.
Escoger nombres con significado para los procesos, flujos, almacenes y

terminadores.
Numerar los procesos.
3.
Redbujar el DFD tantas veces como sea necesario estticamente.
4.
Evitar los DFD excesivamente complejos.
5 . Asegurarse de que ei DFD sea internamente consistente y que tambin lo

sea con cualesquiera DFD relacionados con l.
9.2.1
Escoger nom bres con sig n ific a d o para los procesos, flu jo s,
almacenes y term inadores.
Como se ha visto, un proceso en un DFD puede representar una funcin que

se est llevando a cabo, o pudiera indicar cmo se est llevando a cabo, identifican
do a la persona, grupo o mecanismo involucrado. En el ltimo caso, obviamente es
importante etiquetar con precisin el proceso, de modo que quienes leen el DFD, es
pecialmente los usuarios, puedan confirmar que se trata de un modelo preciso. Sin
embargo, si el proceso lo hace una sola persona, recomiendo que identifique el pa
pel que dicha persona est representando, ms que su nombre o identidad. As, en
lugar de dibujar un proceso como el que se muestra en la figura 9.14(a), con ei nom
bre de Paco inmortalizado a la vista de todos, sugerimos que represente el proceso
como se muestra en la figura 9.14(b). La razn de esto tiene tres aspectos:
1.
Paco pudiera ser reemplazado la prxima semana por Mara o por Juan.
Para qu introducir en el modelo algo susceptible de volverse obsoleto?
2.
Paco pudiera estar realizando diversas labores diferentes en el sistema.

En lugar de dibujar tres burbujas distintas, cada una etiquetada como Pa
co pero con distinto significado, es preferible indicar la labor misma que
se est logrando, o por lo menos el papel que Paco est jugando en el
momento (como se modela en cada una de sus burbujas).
3.
Identificar a Paco es probable que atraiga atencin hacia la manera parti

cular en la que realiza la labor dada. Como veremos en la parte III, gene
ralmente desearemos concentrarnos en la poltica de negocios que debe
cumplirse, sin referirnos a los procedimientos (los cuales pueden basarse
en costumbres e historia que ya no sean relevantes) que se utilizan para
seguir dicha poltica.
www.FreeLibros.org
pedidos
Figura 9.14(a): Nombre de proceso no apropiado
pedidos
Figura 9 .14(b): Nombre de proceso ms apropiado

Si tenemos suerte de evitar nombres de personas (o de grupos) y papeles po
lticos, entonces podemos etiquetar los procesos de tal manera que se puedan iden
tificar las funciones que el sistema est llevando a cabo. Un buen sistema que se
puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir, escoja
un verbo activo (un verbo transitivo, uno que tenga objeto) y un objeto apropiado pa
ra formar una frase descriptiva para el proceso. Los siguientes son ejemplos de
nombres de procesos:
CALCULAR TRAYECTORIA DEL PROYECTIL
PRODUCIR INFORME DE INVENTARIO
VALIDAR NUMERO TELEFONICO
ASIGNAR ESTUDIANTES A LA CLASE
www.FreeLibros.org
Encontrar, al seguir estas reglas, que es considerablemente ms fcil utilizar

objetos especficos si el proceso mismo es relativamente simple y est bien
Sin embargo, aun en los casos sencillos hay la tentacin de utilizar nom
bres ambiguos como HACER, MANEJAR y PROCESAR. Cuando se utilizan verbos
tan elsticos (verbos con significados para cubrir casi cualquier situacin), a menudo significa que ei analista no est seguro de cul funcin se est levando a cabo o
que se han agrupado diversas funciones que en realidad no debieran agruparse.
Estos son algunos nombres de procesos poco adecuados:
yerb os y
definido.
HACER ALGO
FUNCIONES MISCELANEAS
MANEJAR ENTRADAS
ENCARGARSE DE CUENTES
DATOS DE PROCESOS
EDICION GENERAL
Los nombres de los procesos (al igual que los nombres de flujos y de terminadores) deben provenir de un vocabulario que tenga algn significado para el usuario.
Esto suceder de manera muy natural si el DFD se dibuja como resultado de una se
rie de entrevistas con los usuarios y si el analista tiene algn entendimiento mnimo
de la materia de aplicacin subyacente. Pero se deben tener en cuenta dos precau
ciones:
1.
Hay una tendencia natural de los usuarios de utilizar abreviaturas y acrnimos especficos con los que estn familiarizados; esto es cierto tanto
para los procesos como para ios flujos que describen. Por desgracia, es
to suele resultar en un DFD fuertemente orientado a la manera en ia que
se hacen las cosas ahora. Por ello, el usuario pudiera decir: Bueno, se
consigue una copia de la forma 107, la forma rosada, usted sabe, y se la
mandamos a Jos una vez llena . Una buena manera de evitar tales tr
minos idiosincrsicos es escoger verbos (como llenar) y objetos (corno
forma 107) que tendran significado para alguien de ia misma industria o
aplicacin, pero que trabaje en una compaa u organizacin diferente.
Si se est creando un sistema para bancos, los nombres de procesos y
de flujos debieran, idealmente, ser comprensibles para alguien de un ban
co distinto.
2.
Si
el DFD o dibuja alguien que tenga bases de programacin, habr ia

tendencia a utilizar terminologa orientada a la programacin, tal como:
RUTINA , PROCEDIMIENTO , SUBSISTEMA y FUNCION , aunque
dichos trminos pudieran no tener significado alguno en el mundo del
usuario. A menos que oiga a ios usuarios utilizar estas palabras en su
propia conversacin, evite utilizarlas en su DFD.
www.FreeLibros.org
9.2.2
Numerar el proceso
Como una forma conveniente de referirse a los procesos en un DFD, muchos

analistas numeran cada burbuja. No importa mucho cmo se haga esto, de izquierda
a derecha, de arriba abajo o de cualquier otra manera servir, mientras haya cons
tancia en la forma de aplicar los nmeros.
La nica cosa que se debe tener en mente es que el sistema de numeracin
implicar, para algunos lectores casuales de su DFD, una cierta secuencia de ejecu
cin. Esto es, cuando se muestre el DFD a un usuario, ste pudiera preguntar:
Acaso la burbuja nmero 1 sucede primero, luego la 2 y luego la 3? . De hecho,
otros analistas y programadores pudieran hacer la misma pregunta; cualquiera que
est familiarizado con un diagrama de flujo puede cometer el error de suponer que
los nmeros asociados con las burbujas implican alguna secuencia.
Esto no es as en absoluto. El modelo de DFD es una red de procesos asin
crnicos que se intercomunican, lo cual es, de hecho, una representacin precisa de
la manera en la que en realidad muchos sistemas operan. Alguna secuencia pudiera
implicarse por la presencia o ausencia de datos (por ejemplo, pudiera resultar que la
burbuja 2 no pueda realizar su funcin sino hasta que reciba datos de la burbuja 1),
pero el esquema de numeracin no tiene nada que ver con eso.
Para qu numerar entonces las burbujas? En parte, como se indic anterior
mente, es una manera muy conveniente de referirse a los procesos. Es ms fcil en
una discusin animada sobre un DFD decir burbuja 1 en lugar de EDITAR TRAN
SACCION Y REPORTAR ERRORES'. Pero de mayor importancia an es el hecho
de que los nmeros se convierten en base para la numeracin jerrquica cuando se
introduzcan los diagramas de flujo por niveles en la seccin 9.3.
9.2.3
Evitar ios DFD demasiado complejos
El propsito de un DFD es modelar de manera precisa las funciones que debe

llevar a cabo un sistema y las interacciones entre ellas. Pero otro propsito del DFD
es ser ledo y comprendido, no sio por ei analista que construy el modelo, sino por
los usuarios que sean los expertos en la materia de aplicacin. Esto significa que el
diagrama debe ser fcilmente entendido, fcilmente asimilado y placentero a la vista.
Trataremos sobre varias reglas estticas en la siguiente subseccin, pero hay
una regla principal que se debe tener en mente: no cree un DFD con demasiados
procesos, flujos, almacenes y terminadores. En la mayora de los casos, esto signifi
ca que no debiera haber ms de media docena de procesos y almacenes, flujos y
terminadores relacionados en un solo diagrama.10 Otra manera de decir esto es que
el DFD debe caber cmodamente en una hoja norma!.
www.FreeLibros.org
10 Esta regla proviene de The M agical N um ber Seven, Plus or M inus Two", de G eorge M iller, Psych o lo g y Review, 1956.
Existe una excepcin importante a esto, que discutiremos en el captulo 18: un

DFD especial conocido como diagrama de contexto, que representa el sistema entefQ como un solo proceso y destaca las interfaces entre el sistema y los terminadores
exte rn os. La figura 9.15 muestra un diagrama de contexto tpico y, como puede verge con l basta para asustar a muchos analistas, por no mencionar al usuario des
p r e v e n id o . Comnmente, los diagramas de contexto como el que se muestra en la
figura 9.15 no se pueden simplificar, pues describen, con el ms alto detalle, una re
alidad que es intrnsecamente compleja.11
Figura 9 ,15: diagrama de contexto tpico

' 2,4
Redibujar el DFD tantas veces com o sea necesario
En un proyecto real de anlisis de sistemas, el DFD que se analiza en este ca

ptulo tendr que dibujarse y volverse a dibujar, a menudo hasta 10 veces o ms,
antes de 1) ser tcnicamente correcto, 2} ser aceptable para el usuario y 3) estar lo
11 En ia realidad, hay algo que podem os hacer: si hay d iversos flu jo s distintos entre un terminados
na sola burbuja del sistem a, pueden consolidarse en un solo flu jo de datos. El d iccio n a rio de dac=, que se discute en el ca p tulo 10, se usar para exp lica r la com posicin y sig n ifica d o de un flujo
agregado. Y, si el diagram a de contexto se est m ostrando a un pblico m uy d iverso (por ejem plo,
distintos grupos de usuarios con diferentes intereses), se pueden dib u ja r varios diagram as de con
texto que enfaticen ios flu jo s pa rticu la re s que puedan interesarte a cada grupo de usuarios. Pero,
en ia m ayora de los casos, no hay escapatoria: si ei siste m a global es intrn se ca m en te com plejo, lo
ser tam bin el diagram a de contexto. Se d iscutir m s a fondo esto en ei ca p tuio 18.
www.FreeLibros.org
suficientemente bien dibujado como para que no sea embarazoso mostrarlo a ia cj.
reccin de la organizacin. Esto pudiera parecer mucho trabajo, pero bien vale el
esfuerzo de desarrollar un modelo preciso, congruente y agradable, de los requermientos de su sistema. Lo mismo se cumple para cualquier otra disciplina de rigeniera: querra usted volar en un avin diseado por ingenieros que se aburrieron
de sus dibujos de ingeniera tras la segunda iteracin?12
Qu hace estticam ente agradable a un DFD? Esto es obviamente una
cuestin de gustos y puede determinarse por normas dispuestas por su organizacin
o por las caractersticas particulares de cualquier paquete que utilice de diseo de
diagramas basado en una estacin de trabajo automatizada. Y la opinin del usua
rio pudiera ser un tanto diferente de la suya; lgicamente, cualquier cosa que el
usuario encuentre agradable debe determinar la manera en la que se dibuje el dia
grama. Algunos de los asuntos que surgen para ser tratados en esta rea son los si
guientes:
Tamao y forma de las burbujas. Algunas organizaciones dibujan diagra

mas de flujo de datos con rectngulos u valos en lugar de crculos; esto
es obviamente una cuestin de esttica. Adems, algunos usuarios pu
dieran molestarse s las burbujas del DFD no son del mismo tamao: cre
en que si una burbuja es ms grande que otra eso significa que esa parte
del sistema es ms importante o que difiere del resto de una manera sig
nificativa. (De hecho, por lo comn sucede slo debido a que el nombre
de la burbuja era tan largo que el analista tuvo que dibujarla ms grande
para poderlo abarcar.)
Flujos curvos vs. rectos. Para ilustrar esto, considere los DFD de la Fi
guras 9.16(a) y 9.16(b). Cul es ms agradable? Muchos observadores
se encogern de hombros y dirn en realidad da igual. Pero otros, y s
te es el meollo dei asunto, escogern uno y rechazarn violentamente el
otro. Obviamente, sera una buena idea conocer de antemano qu opcin
ser aceptada y cul ser rechazada. El asunto de las flechas cruzadas
es similar. Se permiten o no se permiten?
Diagramas hechos a mano vs. los diagramas generados por mquina.

Dentro de algunos aos, casi todos los DFD y modelos de sistemas rela
cionados se dibujarn con sistemas grficos por computadora; sin embar
go, muchos de ios diagramas todava hoy se dibujan a mano porque los
12 En caso de que piense que ios avio n e s son d iferentes de ios sistem as a u tom atizados, o que son
m s crticos, te n ga en m ente que en la actualidad la m ayora de los aviones estn controlados por
com putadora; un avin grande de pasajeros puede te n e r una docena o m s de sistem as computa
cio n a le s com plejos a bordo, que a su vez tienen nterfase con sistem as de tiem po real complejos
tales com o el que usa la ad m in istra ci n federal de aviacin para revisar el espacio areo en ia ve
cindad de los aeropuertos.
www.FreeLibros.org
analistas no tienen acceso a tales herramientas. No obstante, el asunto

aqu es la reaccin del usuario a estos diagramas: algunos prefieren mar
cadamente los diagramas generados por la mquina pues son ms orde
nados, mientras que otros prefieren los dibujados a mano porque los hace
sentir que el diagrama no se ha congelado an, y que todava pueden
introducir cambios.
Asegrese de que su DFD sea lgicam ente consistente
9.2.5
Como se ver en el captulo 14, existen reglas que ayudan a asegurar la con
sistencia del DFD con los otros modelos de sistemas: el diagrama de entidad-rela
cin, el diagram a de tra n s ic i n de estados, el d iccio n a rio de datos, y la
especificacin de procesos. Sin embargo, existen algunas reglas respecto a cmo
asegurar que el DFD mismo sea consistente. Las principales regias de consistencia
son:
Evite sumideros infinitos, burbujas que tienen entradas pero no salidas.

Tambin son conocidos por los analistas como agujeros negros , en ana
loga con las estrellas cuyo campo gravitacional es tan intenso que ni la
luz se les escapa. Un ejemplo de vrtice infinito se da en la figura 9.17.
Evite las burbujas de generacin espontnea, que tienen salidas sin tener
entradas, porque son sumamente sospechosas y generalmente incorrec
tas. Un ejemplo factible de una burbuja que slo tiene salidas es un gene
rador de nmeros aleatorios, pero es difcil imaginar algn otro ejemplo
razonable. Una burbuja tpica que slo tiene salidas se muestra en la figu
ra 9.18.
Tenga cuidado con ios flujos y procesos no etiquetados. Esto suele ser
un indicio de falta de esmero, pero puede esconder un error an ms
grave: a veces ei analista no etiqueta un flujo o un proceso porque sim
plemente no se le ocurre algn nombre razonable. En el caso de un flujo
no etiquetado, pudiera significar que diversos datos elementales no rela
cionados se agruparon arbitrariamente; en el caso de un proceso no eti
quetado, pudiera significar que el analista estaba tan confundido que
dibuj un diagrama de flujo disfrazado en lugar de un diagrama de flujo de
datos.13
13 Hay un convenio idiom tico que vio la esto, que se d iscu tir en la seccin 9.1.3: un flujo no eti
quetado que sae o entra de un alm acn es, p o r acuerdo, un in d icio de que una in stancia (o regis
tro) com pleto se est m etiendo o sacando del alm acn.
www.FreeLibros.org
www.FreeLibros.org
Figura 9 .16(b): Versin diferente de un DFD
Figura 9.18: Ejemplo de burbuja nicamente de salida
Tenga cuidado con ios almacenes de slo lectura o slo escritura. Es

ta regia es anloga a la de ios procesos de nicamente entradas o ni
camente salidas. Un almacn tpico debiera tener tanto entradas como
salidas.14 La nica excepcin a esta regla es el almacn externo, que sir
ve de interfaz entre el sistema y algn terminador externo. La figura 9.19
muestra un ejemplo de un sistema de bolsa con un almacn legtimo que
slo es para escritura.
14 A veces p u diera no ser e vidente inm ediatam ente si ei alm acn tiene tanto e n tradas com o sali
das. Como verem os en la siguiente seccin, a m enudo io s DFD se dividen en partes, por lo que
pudiramos en co ntra r que una parte dei sistem a parece slo tener alm acenes de nicam ente lectu
ra (o nicam ente escritu ra ). A lg u n a o tra parte del siste m a , d o cu m e n ta d a en otro DFD, pudiera
tener la actividad de nicam ente e scritura (o nicam ente lectura) corre sp o n dien te . Para ve rificar
que alguna parte dei sistem a lea y alguna otra escriba en el alm acn se req u ie re de una labor muy
tediosa de revisin; es aqu donde los paquetes de a n lisis autom a tiza d o de siste m a s que se discu
ten en el apndice A se vuelven extrem adam ente valiosos.
www.FreeLibros.org
Figura 9.19: Caso legtim o de almacn de nicam ente escritura
9.3
DFD por niveles
Hasta donde hemos llegado en este captulo, los nicos diagramas de flujo de
datos completos que hemos visto son el sistema sencillo de tres burbujas de la figu
ra 9.1 y el sistema de una burbuja de la figura 9.19, pero ios DFD que veremos en
proyectos reales son considerablemente mayores y ms complejos. Considere por
ejemplo el DFD que se muestra en la figura 9.20. Puede imaginarse mostrndole
esto al usuario tpico?
La seccin 9.2.3 sugiere que deben evitarse diagramas como ei de la figura
9.20. Pero cmo? Si el sistema es intrnsecamente complejo y tiene docenas o in
cluso cientos de funciones que modelar, cmo puede evitarse el tipo de DFD que
muestra la figura 9.20?
La respuesta es organizar el DFD global en una serie de niveles de modo que
cada uno proporcione sucesivamente ms detalles sobre una porcin del nivel ante
rior. Esto es anlogo a la organizacin de mapas en un atlas, como se discuti en el
captulo 8: esperaramos ver un mapa global que mostrara un pas completo, o tal
vez incluso el mundo completo; los mapas subsecuentes mostraran los detalles de
los pases individuales, los estados individuales dentro de los pases, etc. En el ca
so de los DFD, la organizacin de los niveles se muestra conceptualmente en la figu
ra 9.21.
www.FreeLibros.org
El DFD del primer nivel consta slo de una burbuja, que representa el sistema
completo; los flujos de datos muestran las interfaces entre el sistema y los termina
dores externos (junto con los almacenes externos que pudiera haber, como lo ilustra
ja figura 9.19). Este DFD especial se conoce como diagrama de contexto y se expli
ca en el captulo 18.
El DFD que sigue del diagrama de contexto se conoce como la figura 0. Re

presenta la vista de ms alto nivel de las principales funciones del sistema, al igual
que sus principales interfaces. Como se discuti en la seccin 9.2.2, cada una de
estas burbujas debiera numerarse para una referencia conveniente.
Los nmeros tambin sirven como una manera adecuada de relacionar una
burbuja con el siguiente nivel del DFD que la describe ms a fondo. Por ejemplo:
La burbuja 2 en la figura 0 se asocia con un DFD inferior conocido como

figura 2. Las burbujas de la figura 2 se numeran 2.1, 2.2, 2.3, etc.
La burbuja 3 de la figura 0 se asocia con un DFD inferior conocido como

figura 3, las burbujas de la figura 3 se numeran 3.1, 3.2, 3.3, etc.
www.FreeLibros.org
La burbuja 2.2 de la figura 2 se asocia con un DFD de nivel inferior cono

cido como figura 2.2. Las burbujas de sta se numeran 2.2.1, 2.2.2,
2.2.3, etc.
Figura 9.21: DFD por niveles
Si una burbuja tiene nombre (que en realidad debiera tenerlo) entonces

dicho nombre se reutiliza en la figura de nivel inmediato inferior. As, si la
burbuja 2,2 se llama CALCULAR IMPUESTO DE VENTA, entonces la fi
gura 2.2, que parte la burbuja 2.2 en ms detalles, debe etiquetarse fi
www.FreeLibros.org
gura 2,2: CALCULAR IMPUESTO DE VENTA.
Como podr verse, sta es una manera bastante directa de organizar un DFD
ootencialmente enorme en un grupo de piezas manejables. Pero existen diversas
cosas que debemos aadir a esta descripcin de niveles:
1.
Cmo saber cuntos niveles debe haber en un DFD? La respuesta se

sugiri en la seccin 9.2.3: cada DFD debe tener no ms de media doce
na de burbujas y almacenes relacionados. As, si se ha partido un siste
ma grande en tres niveles, pero sus DFD de nivel ms bajo an contienen
50 burbujas cada uno, entonces falta por lo menos un nivel ms. En el
captulo 11 se ofrece una alternativa de verificacin, al discutir las especi
ficaciones de proceso para las burbujas en los DFD de! nivel ms bajo: Si
no podemos escribir una especificacin de proceso razonable para una
burbuja en alrededor de una pgina, entonces es probable que sea dema
siado compleja y debiera partirse en DFD de menor nivel antes de tratar
de escribir la especificacin.
2.
Existen reglas acerca del nmero de niveles que debieran esperarse en

un sistema tpico? En un sistema simple, probablemente se encontrarn
dos o tres niveles; uno mediano tendr generalmente de tres a seis nive
les; uno grande tendr de cinco a ocho niveles. Debe ser bastante preca
vido con quien le diga que todos los sistemas pueden m odelarse en
exactamente tres niveles; tal persona tambin tratar de venderle la Torre
Eiffel. Por otro lado, recuerde que el nmero total de burbujas se incre
menta exponencialmente a medida que se baja de nivel al inmediato infe
rior. Si, por ejemplo, cada figura tiene 7 burbujas, entonces habr 343 en
el tercer nivel, 16,807 en el quinto, y 40,353,607 en el noveno.
3.
Deben partirse todas las partes del sistema con el mismo nivel de deta
lle? Por ejemplo, si la burbuja 2 de ia figura 0 requiere tres niveles ms
de detalle, es necesario que tambin la burbuja 3 tenga tres niveles ms
de detalle? Es decir, la figura 3; un conjunto de figuras etiquetadas como
figura 3.1, 3.2,
y un conjunto de figuras etiquetadas 3.1.1, 3.1.2,
3.2.1, 3.2.2, etc. La respuesta es no. Algunas partes del sistema pue
den ser ms complejas que otras y pueden requerir uno o ms niveles de
particin. Por otro lado, si la burbuja 2, que existe en la figura 0, resulta
primitiva, mientras que la burbuja 3 requiere de siete niveles ms de parti
cin, entonces el modelo global del sistema est ladeado y probablemen
te est mal organizado. En este caso, algunas porciones de la burbuja
3 debieran separarse en una burbuja aparte o tal vez ser reasignadas a
la 2.
4.
Cmo se muestran estos niveles ai usuario? Muchos usuarios slo que

rrn ver un diagrama: un usuario ejecutivo de alto nivel pudiera querer ver
tan slo el diagrama de contexto o tal vez la figura 0; un usuario de nivel
operacional pudiera querer ver slo la figura que describe el rea en la
www.FreeLibros.org
cual est interesado. Pero si alguien quiere ver una parte ms extensa I
del sistema, o tai vez todo, entonces tiene sentido presentar los diagra- I
mas de una manera descendente: comenzar con el diagrama de contexto!
y continuar hasta niveles ms bajos de detalle. A menudo resulta til te-1
ner dos diagramas juntos en el escritorio (o mostrarlos por un proyector) I
cuando est haciendo esto: el diagrama en el cual est particularmente I
interesado y el diagrama progenitor que provee un contexto de alto nivel, i
5.
Cmo asegurar que los niveles del DFD sean consistentes entre s? E| ;
asunto de la consistencia resulta ser de importancia crtica, pues los di
versos niveles del DFD los desarrollan en general distintas personas en
un proyecto real; un analista en jefe puede concentrarse en el diagrama
de contexto y la figura 0, mientras que diversos analistas ayudantes tra
bajan en las figuras 1, 2, etc. Para asegurar que cada figura sea consis
tente con su figura de ms alto nivel se sigue una regla sencilla: los flujos
de datos que salen y entran de una burbuja en un nivel dado deben co
rresponder con los que entran y salen de toda la figura en el nivel inme
diato inferior que la describe. La figura 9.22(b) muestra dos niveles de un
DFD que no estn balanceados.
6.
Cmo se muestran los almacenes en los diversos niveles? Esta es un

rea donde la redundancia se introduce deliberadamente en el modelo.
La regla es la siguiente: mostrar un almacn en el nivel ms alto donde
primeramente sirve de interfaz entre dos o ms burbujas; luego, mostrarlo
de nuevo en CADA diagrama de nivel inferior que describa ms a fondo
(o parta ms) dichas burbujas de interfase. As, la figura 9.23 muestra un
almacn compartido por dos procesos de alto nivel: A y B; el almacn se
mostrara nuevamente en las figuras del nivel inmediato inferior que des
criben ms a fondo A y B. El corolario de esto es que los almacenes loca
les, que utilizan slo las burbujas en una figura de menor nivel, no se
mostrarn en niveles superiores, dado que se incluyen de manera implci
ta en un proceso del nivel inmediato superior.
7.
Cmo se realiza de hecho la particin de los DFD en niveles? La expo

sicin hasta aqu ha sido un tanto sutil: a pesar de que ciertamente los
DFD deben presentarse al pblico usuario de una manera descendente,
no es necesariamente cierto que el analista deba desarrollarlos as. El
enfoque descendente intuitivamente es muy atractivo: puede imaginarse
comenzando con el diagrama de contexto y luego desarrollando la figura
0 para ir trabajando metdicamente en forma progresiva hasta los niveles
ms bajos de detalle.15 Sin embargo, como se ver en el captulo 17,
www.FreeLibros.org
15 Tam bin es m uy atra ctivo para los a d m inistradores del proyecto. En una ocasin se escuch a
una a d m in istra d o ra de un p royecto m uy grande decirle a su equipo: Q uiero que to d os ustedes ba
je n burbujeando hasta el sig uiente nivel de detalle para este fin de sem ana .
DIAGRAMAS DE FLUJO DE DATOS
www.FreeLibros.org
Figura 9.22(a): Fragmento balanceado de un DFD
Figura 9,22(b): Fragmento
de
un DFD
no
balanceado
www.FreeLibros.org
Figura 9.23: Cmo se muestran los almacenes en niveles inferiores

existen problemas con este enfoque; un enfoque que tiene ms xito es
identificar primero los acontecimientos externos a los cuales debe respon
der el sistema y utilizarlos para crear un primer borrador del DFD, En el
captulo 20 veremos cmo es que esta primera aproximacin del DFD pu
diera requerir partirse hacia arriba (para crear DFD de mayor nivel), y ha
cia abajo (para crear DFD de menor nivel). Por ahora, es suficiente que
simplemente se d cuenta que la organizacin y presentacin de un con
junto de DFD por niveles no necesariamente corresponde a la estrategia
para desarrollar estos niveles en primer lugar.
9.4
EXTENSIONES DEL DFD PARA SISTEMAS DE TIEMPO REAL
Los flujos que se discuten a lo largo de este captulo son flujos de datos, son
simplemente los conductos a lo largo de los cuales viajan los paquetes de datos en
tre procesos y almacenes. Similarmente, las burbujas en los DFD que hemos visto
hasta ahora pudieran considerarse como procesadores de datos. Para una amplia
www.FreeLibros.org
seal de satlite
\
x ,--
...
\
/ 'c o n t r o l d e \
! SISTEMA DE
\ VIGILANCIA ,/
seal de f
radar
/
/
'v ,
........
habilitar proceso
de radar
J PROCESO DEN datos de radar

( DATOS DE W ------------\
RADAR
/
Figura 9.24: DFD con flujos y procesos de control
clase de sistemas, sobre todo de negocios, existen slo dos tipos de flujos necesa
rios en el modelo del sistema. Pero para otra clase de sistemas, los de tiempo reai,
necesitamos alguna manera de modelar flujos de control (es decir seales o inte
rrupciones). Y se requiere una manera de mostrar procesos de control (esto es, bur
bujas cuya nica labor es coordinar y sincronizar las actividades de otras burbujas
del DFD).16 Se muestran grficamente con lneas punteadas en ei DFD, como lo
ilustra la figura 9.24.
Un flujo de control puede imaginarse como un conducto que porta una seal
binaria (esto es, est encendido o est apagado). A diferencia de otros flujos que se
discuten en este captulo, el flujo de control no porta datos con valores. El flujo de
control se manda de un proceso a otro (o de algn terminador externo a un proceso)
como una forma de decir: Despierta, es hora de trabajar". Esto, desde luego, impli
ca que el proceso ha estado dormido hasta la llegada del flujo de control.
16 En algunos casos, pudiera p a recer apropiado incluir a lm acenes de co n tro l o a lm ace n e s de even
tos. Son anlogos ai co n ce pto de sem foro que introdujo D ijkstra en [D ijkstra, 1968]. Para mayo
res detalles, vea [W ard y M eilor, 1985].
www.FreeLibros.org
Un proceso de control puede considerarse como una burbuja supervisora o

cuya labor es coordinar las actividades de otras burbujas en el diagrama;
syS entradas y salidas consisten slo de flujos de control. Los flujos de control sa
lientes del proceso de control se utilizan para despertar a otras burbujas; los flujos
de control entrantes generalmente indican que una de las burbujas ha terminado su
Istbor o que se ha presentado alguna situacin extraordinaria, de la cual necesita in
form arse a la burbuja de control. Por lo comn slo hay un proceso de control de
estos en un DFD dado.
ejecu tiva,
Como se indic anteriormente, un flujo de control se utiliza para despertar un

normal; una vez despierto, el proceso normal procede a llevar a cabo su la
bor como lo describe la especificacin del proceso (vase el captulo 11). Sin em
bargo, el comportamiento interno de un proceso de control es diferente; aqu es
donde el comportamiento dependiente del tiempo del sistema se modela con detalle.
Ei interior del proceso de control se modela con un diagrama de transicin de esta
cas, que muestra los varios estados en los que se puede encontrar todo el sistema y
las circunstancias que lo llevan a cam biar de estado. Los diagram as de
transicin de estados se discuten en el captulo 13.
proceso
S.5
RESUMEN
Como vimos en este captulo, el DFD es una herramienta sencilla pero podero
sa para modelar las funciones de un sistema. El material de las secciones 9,1, 9.2 y
9.3 debiera bastar para modelar la mayora de los sistemas de informacin clsicos
dirigidos a los negocios. Si est trabajando con un sistema de tiempo real (por
ejemplo, control de procesos, direccin de proyectiles o conmutacin telefnica), se
rn importantes las extensiones de tiempo real que se discuten en la seccin 9.4,
Fara ms detalles sobre asuntos de tiempo real, consulte [Ward y Mellor, 1985].
Desafortunadamente muchos analistas piensan que los DFD son todo lo que
necesitan conocer acerca del anlisis estructurado. Si le pregunta a uno de sus co
legas si est familiarizado con el anlisis estructurado, es probable que diga: Ah, s,
aprend acerca de las burbujas y esas cosas. Por otro lado, esto es un tributo al po
der de los DFD; a menudo es lo nico que el analista recuerda despus de leer un li
bro o tomar un curso de anlisis estructurado. Por otro lado, es una situacin
peligrosa: sin las herramientas de modelado adicionales que se presentan en los ca
ptulos siguientes, los DFD no tienen valor alguno. Aun cuando las relaciones entre
datos y el comportamiento dependiente del tiempo del sistema sean triviales (lo cual
es improbable), ser necesario combinar los DFD con el diccionario de datos (que se
trata en el captulo 10) y las especificaciones de proceso (que se explican en el cap
tulo 11 ).
As que no suelte este libro an. Hay ms que aprender.
www.FreeLibros.org
REFERENCIAS
1.
Wayne Stevens, Glen Myers y Larry Constantine, Structured Design, IBh

Systems Journal, mayo de 1974.
2.
Ed Yourdon y Larry Constantine, Structured Design, Nueva York: YOURDON

Press, 1975.
3.
Glen Myers, eiiabie Software through Composite Design, Nueva York: Petrocelli/Charter, 1975.
4.
Tom de Marco, Structured Analyss and Systems Specfication. Englewood

Cliffs, N.J.: Prentice-Hall, 1979.
5.
Chris Gane y Trish Sarson, Structured Systems Anatysis: Tools and Techi
ques, Englewood Cliffs, N.J.: Prentice-Hall, 1978.
6.
Doug Ross y Ken Schoman, Jr., Structured Analysis for Requirements Definition , IEEE Transactions on Software Engineering, enero de 1977, pp. 41-48.
Tambin reimpreso en Ed Yourdon, Classics in Software Engineering. Nueva
7.
Paul Ward y Steve Mellor, Structured Developmeni o f Real-Time Systems, vo

lmenes 1-3. Nueva York: YOURDON Press, 1986.
8.
Edsger W. Dijkstra, Cooperating Sequential Processes , Programming Languages, F. Genuys (editor). Nueva York: Academic Press, 1968.
9.
Paul Ward, The Transformation Schema: An Extensin of the Dataflow Diagram to Represent Control and Timing, IEEE Transactions on Software Engi
neering, febrero 1986, pp. 198-210.
10.
Derek Hatley, The use of Structured Methods in the Development of Large

Software-Based Avionics Systems , AIAA/IEEE dth Digital Avionics Contem
os, Baltimore, 1984.
11.
M. Webb y Paul Ward, Executabie Dataflow Diagrams: An Experimental Implementatin . Structured Development Forum, Seattle, agosto de 1986.
12.
E. Reifly y J. Brackett, An Experimental System for Executing Real-Time

Structured Analysis Models , Proceedings of the 12th Structured Methods Conference, Chicago, agosto de 1987.
www.FreeLibros.org
1.
D una breve descripcin de un DFD. Cul es la diferencia entre un DFD y

un diagrama de flujo?
indique seis sinnimos de diagrama de flujo de datos.
Rara qu pueden usarse los DFD aparte de modelar sistemas deinforma

cin?
Cules son los cuatro principales componentes de un DFD?
5.
Cules son tres sinnimos comunes de proceso en un DFD?
g,
Existe algn significado en la eleccin de un crculo para un proceso? Se

ra mejor utilizar un tringulo o un hexgono? Por qu s o no?
7.
Qu est mal en el siguiente proceso?
8.
9.
www.FreeLibros.org
0-
11.
12.
Por qu querra un analista de sistemas dibujar un proceso que consistiera

en el nombre de una persona o grupo organizacional?
13.
Se restringen los flujos en un DFD a mostrar el movimiento de la informa

cin? Podran mostrar el movimiento de alguna otra cosa?
14.
Qu tiene de mal este DFD?
15.
www.FreeLibros.org
16.
Cmo puede tener diferentes significados el mismo fragmento de datos en un

DFD? Dibuje un ejemplo de tal situacin.
*-
Cul es el significado del siguiente DFD?
|3_
Existe un lmite para el nmero de entradas y salidas que puede tener un

proceso en un DFD? Cul sera su reaccin si viera un proceso con 100 en
tradas y 100 saiidas?
12.
Qu tiene de mai este DFD?
www.FreeLibros.org
21.
Qu tiene de mal estos DFDs?
22.
23.
24.
D una descripcin de flujo de dilogo.
www.FreeLibros.org
25
Es vlido el siguiente DFD? Hay alguna manera alternativa de dibujarlo?
2,
Es vlido el siguiente DFD? Hay alguna manera alternativa de dibujarlo?
27.
Bajo qu circunstancias esperara ver copias del flujo de salida de un proce

so?
28.
Por qu los DFD evitan mostrar detalles de procedimiento?
29.
En el diagrama siguiente, cuntos elementos X y cuntos Y se requieren para

producir una salida Z?
www.FreeLibros.org
30.
Qu representa un almacn en un DFD?
31.
Cul es la convencin para nombrar los almacenes en un DFD?
32.
Qu nombres alternativos puede tener un almacn? Es aceptable el trmM

no archivo? Por qu si o por qu no?
33.
Qu nombres se utilizan comnmente para describir paquetes de informacin

en un almacn?
34.
Cules son las cuatro razones comunes para mostrar almacenes de implan,
tacin en un DFD?
35.
Cree que los almacenes de implantacin deban permitirse en un DFD? p0.

qu s o por qu no?
36.
Qu significa un flujo no etiquetado que entra o sale de un almacn?
37.
Existe lmite para el nmero de flujos que entran o salen de un almacn? De

ser as, seale dicho lmite.
38.
Qu tienen de mal los siguientes DFD?

(a)
(b)
(c)
www.FreeLibros.org
(d)
1.
(8 )
39.
Cules son las cuatro posibles interpretaciones de un flujo de datos de un al

macn a un proceso?
40.
Tiene sentido el siguiente DFD? Por qu?
CLIENTES
41.
D un ejemplo de una situacin donde un proceso pudiera extraer porciones

de ms de un registro de un almacn en un solo acceso lgico.
42.
D un ejemplo de una situacin donde un proceso pudiera extraer ms de un

paquete de informacin de un almacn en un solo acceso lgico.
43.
Puede distinguir viendo nicamente los diagramas si los siguientes DFD es

tn correctos?
www.FreeLibros.org
(a)
CLIENTES
(b>
CLIENTES
(c)
www.FreeLibros.org
44
Qu le sucede a un almacn tras habrsele retirado datos, a lo largo de un

flujo, hacia un proceso? Sucede esto en todos ios sistemas o sio en los de
informacin?
45
Cules son las principales interpretaciones de un flujo hacia un almacn?
43
Como se muestra la eliminacin de paquetes de informacin en un almacn?
47.
Qu tiene de mal el siguiente DFD?
CLIENTES
48.
Cul es el propsito de mostrar un terminador en un DFD?
49.
Cmo debiera el analista identificar los terminadores?
50.
Qu representan los flujos entre terminadores y procesos?
51.
Qu tienen de mal los siguientes DFDs?

(a)
www.FreeLibros.org
(b)
CLIENTE
SISTEMA
DE
ORDENES
(c)
(d)
52.
Se e permite al analista cambiar los contenidos u organizacin de un terminador como parte de su proyecto? Qu tal si opina rotundamente que debiera
cambiarse?
53.
Por qu no deben los procesos mostrar el nombre de la persona que actual

mente realiza dicha funcin?
www.FreeLibros.org
54.
Cul sera una buena regla para nombrar los procesos en un DFD?
DIAGRAMAS DE FLUJO DE DATOS 2 07
D cinco ejemplos de nombres de procesos que no le gustara ver en un DFD.

50
Cmo se puede saber si es probable que el nombre escogido para un proce

so tenga sentido?
57
Cul sera la mala interpretacin que probablemente dara el usuario a los

nmeros en las burbujas de un DFD?
58. Cmo puede saberse si es probable que un DFD dado es demasiado comple
jo para que lo comprenda el usuario?
gg_ Cunto se debe insistir en las reglas de complejidad? Deben permitirse ex
cepciones? Por qu?
80. Por qu resulta a menudo necesario redibujar varias veces un DFD?
61. Cules son los aspectos principales para determinar si un DFD ser esttica
mente agradable? Cree que pudieran expresarse como estndares?
62. Prefieren sus colegas burbujas u valos para los procesos?
usted?
Qu prefiere
63.
Cree que los flujos entre procesos deban mostrarse como curvas o como rec
tas? Se le ocurren ventajas o desventajas en cualquiera de stas? Es im
portante esto?
64.
Qu es un sumidero infinito?
65. Que es la generacin espontnea de burbujas en un DFD? Por qu debe

evitarse en un DFD tpico?
66. Por qu son peligrosos los flujos y procesos no etiquetados?
67. Por qu son generalmente errneos los almacenes de nicamente lectura o
nicamente escritura en un DFD?
68.
Por qu son importantes los DFD por niveles en el modelo de un sistema?
69.
Cuntos niveles de un DFD debiera el analista esperar ver en un sistema

grande tpico? Puede sugerir un lmite superior para el nmero de niveles en
un DFD?
70.
En un DFD por niveles:

(a)
Cmo llamara a las burbujas hijas debajo de la burbuja 2.3?
(b)
Y a la figura en la que aparece la burbuja 2.3?
(c)
Cuntas figuras de mayor nivel hay por encima de fa figura en la que

aparece la Burbuja 2.3? Cmo se llaman?
www.FreeLibros.org
71.
Es necesario que todas las partes de un sistema se dividan hasta el

nivel de detalle? Por qu?
72.
Suponga que alguien le mostrara un DFD en el cual la burbuja 1 estuviera di'.,

dida en dos niveles inferiores, y la 2 en 17 niveles inferiores. Cul seria
reaccin? Qu podra recomendar?
73.
Qu significa balancear, en el contexto de este captulo? Cmo puede dar

se cuenta si un DFD est balanceado?
74.
Por qu no est balanceada la figura 9.22(b) de este captulo?
75.
Cul es la regla a seguir para mostrar almacenes en los diferentes niveles r

un DFD?
76.
Qu es un almacn local? Cules son las reglas para mostrar un almacn

local en un DFD por niveles?
77.
Proyecto de investigacin: Cul es la relacin entre la regla para mostrar un

almacn local y el concepto de diseo orientado a objetos?
Para ms infor
macin acerca de esto, vea los captulos 19 y 20.
78.
Qu problemas pudieran asociarse con el desarrollo de un conjunto de DFD

por niveles en forma descendente (en comparacin con la lectura de un con
junto de DFD que ya exista de manera descendente}?
79.
Qu es un flujo de control? En que difiere de un flujo de datos?
80.
Qu es un proceso de control? En qu difiere de un proceso normal en un

DFD?
81.
Qu es un almacn de control? En qu difiere de un almacn normal en un

DFD?
82.
Dibuje un DFD para modelar ia siguiente receta de Fruits de Mer au fiz (cala
mares surtidos con arroz), tomada de The New York Times 60-Minute Gourmet, de Fierre Franey (Nueva York: TIMES Books, 1979)
1.
Para em pezar, prepare y m ida las cantidades de todos los ingredientes para preparar
el arroz. Para a h o rra r tiem po, pique una taza extra de cebollas y dos dientes extra de
ajo para la m ezcla de m ariscos y seprelos.
2.
C a lie n te dos cucharadas de aceite para el a rroz en una sartn y a ada 1/4 de taza de
cebolla, pim ie nto ve rd e y un diente de ajo, y djelo al fuego hasta que se aje. Aada
azafrn y cu ezalo d os m inutos ms.
www.FreeLibros.org
3.
Aada ei arroz, agua, sal y pim ie nta y t p e lo bien. D jelo cocinarse d u rante 17 minutos
o hasta que se ablande el arroz. M ientras se cuece el arroz, prepare los mariscos.
R ecuerde re tira r el arroz del fuego cuando est listo. Puede dejarlo cu b ie rto durarte
va rios m inutos sin p erjuicio.
4.
C aliente 1/4 de taza de a ce ite y aada la taza de cebolla y ios dos d ientes de ajo. Re
vu elva y cocine hasta que se aje. Aada p im iento rojo, jitom ate, vin o y organo. Aa
da sal y pim ienta. T ape y cocine durante 10 m inutos.
5.
Aada los ca la m a re s y vuelva a tapar. C ocine durante unos tres m in uto s y aada ios
cam arones, los ostiones, y sai y p im ienta ai gusto. T ape y cocine cinco m inutos ms.
Dibuje un DFD para la siguiente receta de Coquille S i Jacques Meuniere (os

tiones fritos en mantequilla), tomada de The New York Times 60-Minute Gourmet, de Fierre Franey (Nueva York: TIMES Books, 1979):
Algo que se debe reca lca r cien veces es la org a n iza ci n . A ntes de cocinar, pique o que se
tenga que picar y m da lo que se tenga que m edir. Saque todas las olas y sartenes que se
vayan a ocupar, en este caso dos cazuelas (una para los o stiones y la otra p ara los jitom a
tes) y una sartn (para las papas).
1.
Vace los ostiones en un plato y aada la leche, revolviendo para cubrir. Deje reposar
un rato.
2.
Ponga la h a rina en otro plato y aada sai y p im ienta al gusto. Revuelva bien. Deje es
c u rrir ios ostiones. C bralos de h arina y p n ga lo s en una co ladera grande. Sacdalos
para q u ita rle s el exceso de harina. S e prelos sobre una hoja de papel a lum inio o pa
pel encerado para que no se adhieran unos a otros.
3.
Los o stiones deben cocerse a fuego ato e vitando que se ju n te n. C a lie n te tres cucha
radas de ace ite y una de m antequilla en una ca zuela grande. C uando la m ezcla est
m uy caliente, pero no hum eante, aada la m itad de los ostiones, sa cu d i nd o lo s y vol
tendolos para que se cuezan rpida y u n iform em ente hasta dorarse
4.
Use una e sptula con ranuras para tra n sfe rir los ostio n es a un plato ca lie n te . Aada
las dos cu charadas restantes de aceite a la cazuela y, cuam do est caliente, aada ei
resto de lo s o s tio n e s , s a c u d i n d o lo s y v o lte n d o lo s co m o se h izo a n te rio rm e n te .
Cuando estn dorados, tra n sfi ra lo s al plato ju n to con los dem s. Lim pie la cazuela
con una to a lla desechadle, aada el resto de la m antequilla y cocine hasta que adquie
ra un color castao. Pngaselo a los o stio n es. Luego pngales ju g o de lim n y perejil
picado.
Dibuje un DFD para la siguiente receta de Omeiette Paviilon (Omelette con po

lio, jitomate y queso), tomado de The New york Times 60-Minute Gourmet, de
Fierre Franey (Nueva York: TIMES Books, 1979):
Antes de iniciar, tenga a m ano un tazn por cada o m elette que piense preparar, y en cada
uno ponga tres huevos. Aada sal y pim ie nta al g u sto y dos cuch a ra d ita s de crem a espesa.
Tam bin puede ir ba tie nd o ios huevos para h a ce r todo ms rpido.
1.
Caliente dos cucharadas de m an te q u illa en una sartn y aada la harina. Revuelva

con un m olin illo hasta que la m ezcla est uniform e. A ada el caldo de pollo y ponga al
fuego sin d e ja r de revo lve r rpidam ente. Aada ia crem a y deje hervir. M antngalo
as durante 10 m inutos.
2.
M ientras ta n to, ca lie n te otra cucharada de m an te q u illa en una sartn y aada la cebo
lla. Cueza, sin d e ja r de revolver, hasta que se aje, y aada los jito m ate s, el tom illo,
hojas de laurel, sal y pim ienta. Deje co ce r a fu e go lento, revo lvien d o de vez en cuan
do, durante 10 m inutos.
www.FreeLibros.org
3.
C a lie n te otra cuch a ra d a de m an te q u illa y aada el pollo. Cueza, sin d ejar de revolver
durante 30 segundos. Aada 3 cucharadas de la salsa de crem a. Djelo al fuego ha&l
ta que hierva, y luego retrelo. Pngalo a un lado.
4.
A la salsa restante a dale la yem a de huevo y revuelva hasta o b tener una mezcla
uniform e. A ada sal y p im ienta al gusto y el queso suizo rayado. C allente, revolvando, hasta que se funda el queso. Pngalo aparte.
5.
Bata ios huevos con sal y pim ienta. Aada seis cucharadas de salsa de tom ate. Ca
liente las tres cuch a ra d a s restantes de m antequilla en una sartn para om elettes o en
una cazuela de tefln y, cuando est caliente, aada los huevos. Cueza, revolviendo
hasta que cuaje abajo pero siga estando hm edo en el centro. Pngale el pollo en el
c entro y aada el resto de la salsa de tom ate. Rpidam ente saque el o m elette y pn,
galo en un refractario.
6.
C ubra el o m elette con el resto de la salsa de crem a y espolvorelo con queso parrrtesano rayado. H ornee h asta que se dore.
www.FreeLibros.org
L DICCIONARIO
DE DATOS
Los d iccio n a rio s son com o los relojes: el peor es m ejor que no te n er
ninguno y del m ejor no puede esperarse que sea m uy exacto.
Sra. Prlozzi, A n cd o ta s de S a m u e l Johnson, 1786

1. Por qu se necesita un diccionario de datos en un
proyecto de desarrollo de sistemas.
2. La notacin de las definiciones de ios diccionarios
de datos.
3. Cmo debe presentarse ei diccionario de datos ai
usuario.
4. Cmo realizar un diccionario de datos.
L a segunda herramienta de modelado importante que discutiremos es ei dic

cionario de datos] aunque no t i e n e la presencia y el atractivo grfico d e los DFD, los
diagramas de entidad-relacin y los diagramas de transicin de estados, es crucial.
Sin los diccionarios de datos, e l modelo de los requerimientos del usuario no puede
considerarse completo; todo lo que se tendra es un borrador rudimentario, una vi
sin del a r t i s t a dei sistema.
L a importancia dei diccionario de datos a menudo l e s pasa de largo a muchos
a d u l t o s , pues no h a n utilizado un diccionario durante 10 o 20 aos. Trate de r e c o r
d a r s u s das en la p r i m a r i a , cuando constantemente se le asediaba con nuevas pala
www.FreeLibros.org
211
212
EL DICCIONARIO DE DATOS
bras en sus tareas. Recuerde tambin sus cursos de lenguas extranjeras, sobre todo los que requeran que leyera libros y revistas. Sin un diccionario, se habra perd,
do. Lo mismo sucede con un diccionario de datos en el anlisis de sistemas: sin l
se extraviar y el usuario no podr estar seguro de que entendi los detalles de |g
aplicacin.
El diccionario de datos de frases casi se autodeflne. El diccionario de datos es
un listado organizado de todos los datos pertinentes al sistema, con definiciones pr.
cisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento
comn de todas las entradas, salidas, componentes de almacenes y clculos inter
medios. El diccionario de datos define los datos haciendo lo siguiente:
10.1
Describe el significado de ios flujos y almacenes que se muestran en los

DFD.
Describe la composicin de agregados de paquetes de datos que se mue

ven a lo largo de los flujos, es decir, paquetes complejos (por ejemplo el
domicilio de un cliente), que pueden descomponerse en unidades ms
elementales (como ciudad, estado y cdigo postal).
Describen la composicin de los paquetes de datos en los almacenes.
Especifica los valores y unidades relevantes de piezas elementales de in

formacin en los flujos de datos y en los almacenes de datos.
Describe los detalles de las relaciones entre almacenes que se enfatizan

en un diagrama de entidad-relacin. Este aspecto del diccionario de da
tos se discutir con ms detalle en el captulo 12, despus de introducir la
notacin de entidad-relacin.
LA NECESIDAD DE LA NOTACION EN EL DICCIONARIO DE DATOS
En ia mayora de los sistemas reales con los que se trabaja, los paquetes, o
elementos de datos, sern lo suficientemente complejos corno para que se necesite
describirlos en trminos de otras cosas. Los elementos complejos de datos se defi
nen en trminos de elementos ms sencillos, y los sencillos en trminos de los valo
res y unidades legtimos que pueden asumir.
Imagine, por ejemplo, la forma en la que respondera a las siguientes pregun
tas de un marciano (que es el concepto que muchos usuarios tienen del analista)
acerca del significado del nom bre de una persona:
Marciano: Bien, qu es esto llamado nombre?
Usted (encogindose impacientemente de hombros): Pues, usted sabe, es s
lo un nombre, quiero decir, este, bueno, es lo que nos llamamos unos a otros.
www.FreeLibros.org
EL DICCIONARIO DE DATOS 213
Marciano (confundido): Significa eso que ios llama de distinto modo cuando
est contento y cuando est enojado?
Usted (un tanto sorprendido de la ignorancia de este extraterrestre): No, claro
que no. Un nombre es el mismo siempre. Un nombre de persona lo distingue de
otras personas.
Marciano (entendiendo de repente): Ah! Ya entiendo. Hacemos lo mismo en
m planeta. Mi nombre es 3.141592653589793238462643.
Usted (incrdulo): Pero eso es un nmero, no un nombre.
Marciano: Y es un muy buen nombre, me enorgullezco de l. Nadie tiene algo
parecido.
resto
Usted: Pero cul es su nombre y cul su apellido? O 3 es su nombre y el

su apellido?
solo
Marciano: Qu es todo esto de nombre y apellido? No entiendo. Tengo un

nombre y siempre es el mismo.
Usted: Pues no funcionan as las cosas aqu. Tenemos un nombre, un apelli

do, y en ocasiones un segundo nombre tambin.
Marciano: Significa eso que usted puede llamarse 23 45 99?
Usted; No. No permitimos nmeros en nuestros nombres. Slo puede usar
los caracteres alfabticos de la A a la Z,
Como podr imaginar, la conversacin podra continuar durante mucho tiempo.
Puede pensar que el ejemplo es exagerado porque rara vez nos encontraremos con
marcianos que no tengan el concepto del significado de un nombre. Pero no est
muy alejado de las discusiones que se suscitan (o que debieran suscitarse) entre el
analista y el usuario, en las cuales pudieran surgir las siguientes preguntas:
Debe tener todo mundo un nombre? Qu tal el personaje Sr. T de la

popular serie de televisin Los cuatro fantsticos?
Qu pasa con ios signos de puntuacin en los apellidos de las personas,

por ejemplo DArcy?
Se permiten los segundos nombres abreviados, por ejemplo, Juan X

Jasso?
Existe una longitud mnima para el nombre de una persona? Por ejem
plo, es legal el nombre X Y? (Es fcil imaginarse que pudiera confundir
a muchos sistemas de cmputo, pero existe alguna razn legal o de ne
gocios por la cual una persona no pudiera llamarse X y apellidarse Y?)
www.FreeLibros.org
214
Cmo debemos tratar ios sufijos que a veces siguen ai apelido? p0r
ejemplo, se supone que el nombre Juan Jasso Jr. es legtimo, pero Se j
considera el Jr. como parte del apellido, o en una categora aparte? Y $ j
est en una nueva categora, no debiramos permitir tambin dgitos
como por ejemplo, Samuel Sosa 3a?
!
Ntese, por cierto, que ninguna de estas cuestiones tiene algo que ver con la (
forma en la que se almacenar la informacin en la computadora; simplemente esta-1
mos tratando de determinar, como cuestin de poltica de negocios, lo que constity. i!
ye un nombre vlido.1
Como se podr imaginar, se vuelve algo tedioso describir la composicin de
los elementos de datos en una forma narrativa. Necesitamos una notacin concisa y j
compacta, as como un diccionario normal tiene notacin compacta y concisa para l
definir ei significado de las palabras ordinarias.
|
10.2
NOTACION DEL DICCIONARIO DE DATOS
Existen muchos esquemas de notacin comunes utilizados por el analista de |

sistemas. El que se muestra a continuacin es de los ms comunes y utiliza varios |
smbolos sencillos:
J
4_
0
{}
[]
**
@
I
est compuesto de
y
optativo (puede estar presente o ausente)
iteracin
seleccionar una de varias alternativas
comentario
identificador (campo clave) para un almacn
separa opciones alternativas en la construccin
Por ejemplo, se puede definir el nom bre para nuestro amigo marciano as:
nom bre =
ttu lo de cortesa + nom bre + (segundo nombre)

+ apellido
ttu lo de cortesa =
[Sr. I Srita. I Sra. IDr. I Profesor]
nom bre =
{carcter legal}
1 Por otro lado, es p robable que la po ltica de negocios actual haya tenido una fu e rte influencia
los sistem as de cm puto q ue la organizacin ha estado usando durante los ltim os 30 aos. Hace
50 aos se hubiera co n sid e ra d o exc n trico a alguien que se hiciera llam ar Jua5n So7to , pero pro
bablem ente hubiera sido acep ta d o por la m ayora de las organizaciones, porque ios nombres se
tran scrib a n en pedazos de papel por m anos hum anas. Los sistem as puram ente computacionaies
(com o la m ayora de ios de uso actual) tienen m uchos m s problem as con nom bres no estndar co
mo ste.
www.FreeLibros.org
segundo nom bre =
{carcter legal}
apellido =
{carcter legal}
carcter legal =
[A-Zia-zl0-9l l-l I]
Como puede apreciarse, los smbolos parecen algo matemticos y pudiera

preocuparse porque sea demasiado complicado de entender. Sin embargo, como ve
remos pronto, la notacin es bastante fcil de leer. Laexperiencia de miles depro
yectos de procesamiento de datos y varias decenas de miles deusuarios nos ha
mostrado que la notacin, adems, es bastante entendile para casi todos los usuarios s se presenta de manera correcta; discutiremos esto en la Seccin 10.3
10.2.1
D efiniciones
La definicin de un dato se introduce con el smbolo =. En este contexto, el

se lee: se define como, o se compone de ,o simplemente significa . Porello,
la notacin
A =B+C
puede leerse de las siguientes maneras:
Cuando digamos A, queremos decir una B y una C
A se compone de B y C
A se define como B y C
Para definir por completo un dato, nuestra definicin debe incluir lo siguiente:
El significado del dato dentro del contexto de la aplicacin de este usua

rio. Por lo comn se ofrece como comentario utilizando la notacin
La composicin del dato, si se compone de partes elementales con signi

ficado.
Los valores que puede tomar el dato, si es un dato elemental que no pue
de descomponerse ms.
As, si estamos construyendo un sistema mdico que siga la evolucin de

podran definirse los trminos peso y estatura de la siguiente manera:
p a c ie n te s ,
peso =
peso del paciente ai ser admitido al hospital*

unidades: kilogramos; gama 1-200*
estatura =
estatura del paciente al ser admitido al hospital*

unidades: centmetros; escala: 20-200*
lo s
www.FreeLibros.org
216
Ntese que hemos descrito las unidades relevantes y la escaia relevante entre
un par de caracteres
Repetimos que esto es un convenio de notacin que nnichas organizaciones encuentran adecuado, pero que puede cambiarse de ser necg.
sario.
I
I
|
Adems de las unidades y la escala, podra requerirse la especificacin di- l

precisin de la medicin del dato. Para datos tipo precio, por ejemplo, es importa
indicar si los valores se expresarn en moneda entera o redondeados al ltimo cen
tavo, etc, En muchas aplicaciones cientficas y de ingeniera es importante indicar I
el nmero de dgitos significativos en el valor de los datos.
10.2.2
Elem entos de datos bsicos
Las partes elementales de ios datos son aquellas para las cuales ya no existe
una descomposicin con significado dentro del contexto del ambiente del usuario.
Esto usualmente es una cuestin de aplicacin y es algo que se debe explorar cuidadosamente con el usuario. Por ejemplo, hemos visto en la exposicin anterior que
ei trmino nombre puede descomponerse en nom bre, segundo nom bre, apellido y
ttu lo de cortesa. Pero tai vez en algunos ambientes de usuario no se requiere tal
descomposicin, ni sea relevante, ni tenga significado {esto es, en ambientes donde
los trminos apellido, segundo nombre, etc., no tengan significado para el usuario).
Cuando se han identificado los datos elementales, deben introducirse al dic

cionario de datos. Como se indic anteriormente, el diccionario de datos debe pro
porcionar una breve narrativa, encerrada entre caracteres
que describa el
significado dei trmino en el contexto del usuario. Desde luego, habr trminos que
se definan solos, es decir, cuyo significado es universal para todos ios sistemas de
informacin, o donde ei analista pudiera estar de acuerdo en que no se necesita
aclarar ms. Por ejemplo, los siguientes pudieran considerarse trminos que se autodefinen en un sistema que maneja informacin sobre personas:
estatura actual
peso actual
fecha de nacim iento
sexo
telfono particular
En estos casos no se necesita un comentario narrativo; muchos analistas usan
la notacin ** para indicar sin comentarios' cuando el dato se defina solo. Sin em
bargo, es importante especificar los valores y unidades de medida que los datos ele
mentales pueden tomar. Por ejemplo:
peso actual =
www.FreeLibros.org
'unidades: libras; escala: 1-400*
estatura actual =
**
unidades: pulgadas; escala: 1-96*

fecha de nacim iento =
Unidades: das a partir del 1 de enero de
1900; escala: 0-36500*
sexo =
valores: [M I F]
10-2.3
Datos opcionales
Un dato opcional, como ia frase implica, es aquel que puede estar o no pre
gante en un dato compuesto. Existen muchos ejemplos de datos opcionales en sis
temas de informacin:
El nombre de un cliente pudiera no incluir un segundo nombre
El domicilio de un cliente pudiera incluir o no informacin secundaria, co

mo el nmero de departamento.
El pedido de un cliente pudiera contener ei domicilio al que se tiene que

mandar la cuenta, el domicilio ai que hay que hacer el envo, o ambos.
Las situaciones de este tipo deben verificarse con cuidado con el usuario y de
ben documentarse precisamente en ei diccionario de datos. Por ejemplo, la notacin
d o m icilio de cliente = (d o m ic ilio de envo) + (d o m icilio para cuenta)
significa, literalmente, que el domicilio del cliente pudiera consistir en:
slo un domicilio de envo
slo un domicilio para enviar cuentas
un domicilio de envo y uno para cuentas
ninguno de los dos
o bien
o bien
o bien
www.FreeLibros.org
Esta ltima posibilidad es dudosa. Es mucho ms probable que el usuario re
almente quiere decir que el domicilio debe consistir en uno u otro o ambos. Esto pu
diera expresarse de la siguiente manera:
218
d o m ic ilio del cliente = [d o m ic ilio de envo I d o m icilio para cuentas I

d o m ic ilio de envo + d o m icilio para cuentas]
Podra tambin argumentarse que, en un negocio por correspondencia, siem
pre se requiere un domicilio de envo a donde se deber mandar la mercanca solici
tada por el cliente; un segundo domicilio para el envo de la cuenta es opcional (por
ejemplo, el departamento de contabilidad dei cliente). As, es posible que la verda
dera poltica del usuario est expresada por
d o m ic ilio del cliente = d o m ic ilio de envo + (d o m icilio para cuentas)
Desde luego, la nica manera de saber esto es pedirle al usuario que explique con
cuidado las implicaciones de las diferentes notaciones que se mostraron.2
10.2.4
Iteracin
La notacin de iteracin se usa para indicar la ocurrencia repetida de un com

ponente de un dato. Se lee como cero o ms ocurrencias de. As, la notacin
s o lic itu d = nom bre del cliente + d o m ic ilio de envo + {a rtculo}
significa que la solicitud siempre debe contener un nombre de cliente, un domicilio
de envo, y tambin cero o ms ocurrencias de un artculo. As, pudiramos estar
tratando con un cliente que pide un artculo, o dos, o algn comprador compulsivo
que decide ordenar 397 artculos diferentes.3
En muchas situaciones reales, el usuario querr especificar los lmites inferior
y superior de la iteracin. Tal vez, en el ejemplo anterior, el usuario seale que no
tiene sentido que un cliente haga un pedido de cero artculos; debe haber por lo me
nos uno. Podra tambin especificarse un lmite superior; quiz, se permitirn cuan
do ms 10 artculos. Puede indicarse esto de la siguiente forma:
2 Existe una p osibilidad que pudiera exp lica r la ausencia tanto del d o m icilio de envo com o del de
cobro en un pedido de un cliente: ei cliente que llega personalm ente para co m p ra r un a rtculo y lle
vrselo en el acto. Es posible que se le q u isie ra id e n tifica r e xplcitam ente (definiendo un nuevo da
to en persona, que te n dra va lo r de verdadero o falso) ya que 1) los clie n te s que llegan en persona
pudieran requerir un tra to distin to (por ejem plo, sus pedidos estaran exe n to s de ca rg o s de envo) y
2) es una buena form a de a segurarse de que la ausencia del dato de dom icilio no fue por error.
3 Tenga en m ente nuevam ente que estam os definiendo el sig n ifica d o in trn se co de n e g ocios de un
dato dado sin referirnos a la tecn olog a usada para im plantarlo. A la larga, por ejem plo, es proba
ble que los d iseadores pregunten sobre un lm ite superior razonable o el nm ero de artcu lo s dife
rentes que puede co n ten e r un m ism o pedido. Para poder lograr una labor eficiente de nuestro
sistem a SU P E R M A R A V ILLA de a dm inistracin de bases de datos, tendrem os que re strin g ir el n
m ero de artcu lo s a 64. Es poco probable, de todos m odos, que alguien pida ms de 64 y, si lo ha
cen, pueden se n cillam ente co lo ca r varios pedidos . Adem s, el usuario pudiera te n e r sus propias
lim itaciones, basadas en las fo rm a s escrita s o los reportes im presos con los que trabaja; esto es
p arte del m odelo de im plantacin del usuario, que se tra ta r en el captulo 21.
www.FreeLibros.org
s o lic itu d = nom bre del cliente + d o m ic ilio de envo + 1{artculo}10

Es correcto especificar slo ei lmite inferior, slo el lmite superior, ambos, o
As que se permite cualquiera de los siguientes:
ning uno .
a = l{b }
a = {b} 10
a = 1{b}10
a = {b}
10.2.5
Seleccin
La notacin de seleccin indica que un dato consiste en exactamente un ele

mento de entre un conjunto de opciones alternativas. Las opciones se encierran en
corchetes [ y
y se separan por una barra vertical I. Como ejemplos tpicos te
nemos:
sexo =
[Femenino I Masculino]
tip o de cliente =
[Gobierno i Industria I Universidad I Otro]
Es importante revisar las opciones de seleccin con el usuario para asegurar

se de cubrir todas las posibilidades. En el ltimo ejemplo, el usuario pudiera tender a
concentrar su atencin en los clientes gobierno , industria y universidad , y podra
requerir un recordatorio de que existen clientes de la categora de ninguno de ios
anteriores.
10.2.6
Alias
Un alias, como el trmino implica, es una alternativa de nombre para un dato.

Esto es una ocurrencia comn cuando se trata con diversos grupos de usuarios en
eferentes departamentos o ubicaciones geogrficas (y a veces con diferentes nacio
nalidades e idiomas), que insisten en utilizar distintos nombres para decir io mismo.
E> alias se incluye en el diccionario de datos para que est completo, y se relaciona
con el nombre primario u oficial del dato. Por ejemplo:
com prador =
alias de cliente*
Ntese que la definicin de comprador no muestra su composicin (es decir,

no muestra que consiste en nombre, domicilio, nmero telefnico, etc.). Todos estos
detalles deben darse slo para el nombre primario del dato, para minimizar la redun
dancia en el modelo.4
- Tal vez pueda ignorar este consejo si est utilizando un paquete co m p u ta riza do de generacin de
accionarios de datos que pueda m anejar y controlar ia redundancia; sin em bargo, esto es poco cor 'un. Lo crucial es recordar que si se cam bia la definicin de un dato prim ario (por ejem plo, si se
cecide que la definicin de cliente ya no debe in clu ir nm ero telefnico), entonces el cam bio se de
es aplicar a todos los alias tam bin.
www.FreeLibros.org
220
Aun cuando el diccionario de datos relaciona correctamente los alias con si

nombre primario de los datos, debe evitarse el uso de alias hasta donde sea posible
Esto se debe a que los nombres de datos se suelen ver primero, y son ms visibles
para todos los usuarios en los DFDs, en donde pudiera no ser tan obvio que cortt.
prador y cliente sean alias. Es mejor, de ser posible, lograr que todos los usuarios
se pongan de acuerdo en un solo nombre.5
10.3
COMO MOSTRAR EL DICCIONARIO DE DATOS AL USUARIO
El diccionario de datos lo crea el analista durante el desarrollo del modelo del

sistema, pero el usuario debe ser capaz de leerlo y entenderlo para poder verificar el
modelo. Esto plantea unas preguntas obvias:
Podrn ios usuarios entender la notacin del diccionario de datos?
Cmo podran los usuarios verificar que ei diccionario est completo y

correcto?
Cmo se crea el diccionario?
La cuestin de la aceptacin por el usuario de la notacin del diccionario pue

de despistar en la mayora de los casos. Es cierto, la notacin del diccionario se ve
algo matemtica; pero, como se ha visto, el nmero de smbolos que el usuario debe
aprender es muy pequeo. Los usuarios estn acostumbrados a la variedad de no
taciones formales en su trabajo y vida personal; considere, por ejemplo, la notacin
musical, que es mucho ms compleja:
Figura 10.1: Notas m usicales

Similarmente, la notacin de los juegos de canasta, ajedrez, y varias activida
des ms es cuando menos igual de compleja que la del diccionario de datos que se
muestra en este captulo.
5 Una a lte rn a tiva sera a notarle algo a! flu jo en e i diagram a de flujo de datos para in dicar que es
alias de otra cosa; por ejem plo, se podra a g regar un a ste risco ai final a los nom bres que son alias.
De esta form a, la notacin comprador* podra usarse para indicar que com prador es alias de otra
cosa. Pero incluso esto es m olesto.
www.FreeLibros.org
Figura 10.2: Notacin de ajedrez

La cuestin de la verificacin del diccionario de datos por el usuario lleva ge
neralmente a esta pregunta: Deben los usuarios leer en detalle todo el diccionario
para asegurarse de que est correcto? Es difcil imaginar que algn usuario estu
viera dispuesto a hacer esto. Es ms probable que el usuario verifique que el diccio
nario es correcto en conjunto con el DFD, el diagrama de entidad-relacin y el
diagrama de transicin de estados o la especificacin del proceso que est leyendo.
Hay varios detalles acerca de la correccin del sistema que el analista puede
hacer por su cuenta, sin ayuda del usuario: puede asegurarse de que el diccionario
est completo y sea consistente y no contradictorio. As que puede examinar el dic
cionario por s solo y preguntar lo siguiente:
Se ha definido en ei diccionario cada flujo del DFD?
Se han definido todos los componentes de los datos enel diccionario?
Se ha definido ms de una vez algn dato?
Se ha utilizado la notacin correcta para todas las definiciones del dic

cionario de datos?
www.FreeLibros.org
222
10.4
Hay elementos de datos en el diccionario que no estn relacionados con

los DFD, los diagramas de entidad-relacin o los de transicin de estado?
IMPLANTACION DEL DICCIONARIO DE DATOS
En un sistema mediano o grande, el diccionario de datos puede representar

una cantidad formidable de trabajo. No es fuera de lo comn ver un diccionario de
datos con varios miles de entradas, e incluso un sistema relativamente sencillo tendr varios cientos de entradas. As que se debe pensar en cmo desarrollar el dic
cionario de datos, porque es probable que la tarea sea demasiado para el analista.
El enfoque ms fcil es hacer uso de una computadora para introducir defini
ciones al diccionario, verificar que estn completas y consistentes, y producir repor
tes apropiados. Si su organizacin est utilizando cualquier sistema moderno de
administracin de bases de datos (por ejemplo, IMS, ADABAS, TOTAL, IDMS), ya
dispone de una ayuda para el diccionario. En este caso, debiera aprovecharla y utili
zarla para construir el diccionario de datos. Sin embargo, debe tener cuidado de las
siguientes limitaciones posibles:
Pudiera verse forzado a limitar los nombres de datos a cierta longitud (por
ejemplo, 15 o 32 caracteres). Esto probablemente no sea un gran proble
ma, pero podra ser que el usuario insista en un nombre como destinodel-envo-del-cliente y que su paquete de elaboracin de diccionarios lo
obliga a abreviar esto a: dest-env-clien.
Podra haber otras limitaciones artificiales para el nombre. Por ejemplo,

el carcter
pudiera no permitirse, y podra verse forzado a utilizar en
su lugar el carcter
O podra verse obligado a utilizar prefijos (o sufi
jos) en todos los nombres, para indicar el nombre del proyecto de desa
rrollo del sistema, lo cual lleva a nombres como:
ctas.pag.GHZ345P14. nm ero_te!fono_vendedor
Podra verse obligado a asignarle atributos fsicos (por ejemplo, nmero

de bytes, o bloques de almacenamiento en disco, o representaciones co
mo decimales redondeados) a un dato, aun cuando no sea cuestin del
usuario. El diccionario de datos que se discute en este captulo debe ser
un diccionario de anlisis y no debiera requerir decisiones de implanta
cin innecesarias o irrelevantes.
Algunos analistas tambin estn empezando a utilizar paquetes automatizados

que incluyen grficos para DFD y otros, adems de capacidad para elaborar diccio
narios de datos. Nuevamente, si tal ayuda existe, debe aprovecharla. Estos paque
tes se discuten con mayor detalie en el apndice A.
www.FreeLibros.org
Si no dispone de ayudas automticas para construir el diccionario de datos,
debiera por lo menos hacer uso de un procesador de palabras convencional para
crear yo archivo de texto de definiciones del diccionario de datos. O, s tiene acceso

g una computadora personal, pudiera usar cualquiera de los programas comunes de
administracin de archivos o de bases de datos (por ejemplo, dBASE, Rbase-5000,
ppS-File, Microsoft File en la Apple Macintosh) para construir y administrar el diccio
nario de datos.
Slo en los casos ms extremos debiera recurrir a un diccionario manual, es
decir, tarjetas individuales de 3 x 5 para cada entrada del diccionario. Esto a menudo era necesario en los aos 70 e incluso en los 80; a pesar de la popularidad de las
computadoras personales y los procesadores de palabras, es decepcionante ver
cuntas organizaciones han mantenido a sus programadores y analistas en la poca
(jgl oscurantismo. Los hijos del zapatero, como dice el refrn, son los ltimos en re
cibir zapatos. Pero hoy en da esto es imperdonable. Si est trabajando en un pro
yecto donde no tiene acceso a un paquete para elaboracin de diccionarios de datos
a un paquete automatizado de herramientas para analista, o a una computadora
oersonal o un sistema procesador de palabras, entonces debera 1 ) renunciar y en
contrar un mejor empleo, o 2) conseguir su propia computadora personal, o 3) hacer
ambas cosas.
jO.g
RESUMEN
Construir un diccionario de datos es una de las labores ms tediosas, y largas,

del anlisis de sistemas. Pero tambin es una de las ms importantes: sin un diccio
nario formal que defina el significado de los trminos, no se puede esperar precisin.
En ei siguiente captulo veremos cmo se usa el diccionario de datos y el DFD
cara construir especificaciones de proceso para cada uno de los procesos de ms
bajo nivel.
h=FERENCIAS
1.
J.D. Lomax, Data Dictionary Systems. Rochelle Park, N.J.:NCC Publications,

1977.
2.
Tom DeMarco, Structured Analysis and Systems Specification.

3.
D. Kroenke, Database Processing.

1977.
4.
Shaku Atre, Data Base: Structured Tech iques for Design, Performance, and
Management. Nueva York, Wiley, 1980.
Nueva York:
Chicago: Science Research Associates,
'PEGUNTAS Y EJERCICIOS
www.FreeLibros.org
7
D una definicin de diccionario de datos,
3-
Por qu es importante un diccionario de datos para el anlisis de sistemas?
224
3.
Qu informacin da un diccionario de datos acerca de un dato?
4.
Qu significa la notacin = en un diccionario de datos?
5.
Qu significa la notacin
6.
Qu significa la notacin (} en un diccionario de datos?
7.
Qu significa ia notacin {} en un diccionario de datos?
8.
Qu significa la notacin [ II ] en un diccionario de datos?
9.
Cree lid . que los usuarios con los que trabaja pueden entender la notaci^
de diccionario estndar que se da en este captulo? Si no es as, puede su
gerir alguna alternativa?
en un diccionario de datos?
10.
D un ejemplo de dato elemental.
11.
D tres ejemplos de datos opcionales.
12.
Cules son ios posibles significados de lo siguiente:

(a)
d o m ic ilio =
(ciudad) + (estado)
(b)
d o m ic ilio =
calle +ciudad + (estado) + (cdigo postal)
13.
D un ejemplo del uso de la notacin de iteracin.
14.
Cul es el significado de cada una de las siguientes notaciones?
15.
(a)
a = 1{b}
(b)
a = {b}10
(c)
a = 1{b}10
(d)
a = 10{b}10
Tiene sentido definir un pedido de la siguiente manera?

pedido = nom bre-de-cliente + dom icilio-de-envo + 6{artcuio}
Por qu? o por qu no?
16.
D un ejemplo de la construccin de seleccin.
17.
Qu significado tiene un alias en ei diccionario de datos?
www.FreeLibros.org
18.
Por qu debieran usarse lo menos posible los alias?
Qu tipo de anotacin debe hacerse en el DFD para indicar que un dato es

un alias?
2Q
Cules son los tres asuntos de importancia que surgen cuando ei usuario ve
el diccionario de datos?
2f
Cree Ud. que los usuarios en su organizacin podrn entender la notacin

del diccionario de datos?
22.
Cree Ud. que la notacin que se muestra en este captulo sea ms compleja,
o menos, que la musical?
23.
Cules son las tres actividades de verificacin de posibles errores que puede
llevar a cabo el analista en el diccionario de datos sin ayuda dei usuario?
24.
Cules son las limitaciones probables de un paquete automatizado de gene

racin de diccionarios de datos?
25.
D una definicin de diccionario de datos de nom bre-del-cliente basada en la

siguiente especificacin verbal del usuario: Cuando registramos el nombre de
un cliente, tenemos cuidado de incluir un ttulo de cortesa, que puede ser
Sr., Srita., Sra. o Dr.. (Existen otros muchos ttulos como Profesor, Sir,
etc., pero no nos ocupamos de ellos.) Cada uno de nuestros clientes tiene un
nombre de pila, pero permitimos slo una inicial si ellos lo prefieren. Los se
gundos nombres son opcionales. Y, desde luego, se requiere el apellido; per
mitimos una buena gama de apellidos, incluyendo los que conllevan guin
(Smith-Frisby, por ejemplo) y apstrofo (DArcy), etc. Incluso permitimos un
sufijo optativo, para dar cabida a cosas como Tom Smith, Jr.o Harvey Sbmrdlu 38 .
26.
Qu est mal en las siguientes definiciones de diccionario de datos?

(a)
a = bcd
(b)
a=
(c)
a = {b
(d)
a = 4{b}3
(e)
a = (x)
(f)
x = ((y))
(9)
p = 4{6{y}8}6
b+ + c
www.FreeLibros.org
27.
En ei ejemplo del hospital de la seccin 9.2. qu implican ias definiciones de

peso y estatura? Comentario; Implicara que slo estarnos midiendo en uni
dades enteras y no estamos considerando (as fracciones adicionales, etc.
226
28.
Escriba una definicin de diccionario de datos de la informacin que contiene

su licencia de manejo. Si no tiene, encuentre algn amigo que tenga.
29.
D una definicin de diccionario de datos de ia informacin que contiene una

tarjeta comn de crdito bancario tpica (por ejemplo, Visa o MasterCard).
30.
D una definicin de diccionario de datos de la informacin que contiene un

pasaporte.
31.
D una definicin de diccionario de datos de la informacin que contiene un bi

llete de lotera.
www.FreeLibros.org
en
ES P E D IR AD1QIM
DE PROCESO
N uestros pequeos siste m a s tienen su da.

A lfred, Lord Tennyson
in M em oriam , 1850

!
1. Cmo escribir especificaciones estructuradas de

procesos.
2. Cmo escribir especificaciones de proceso con
pre/post condiciones.
3. Cmo utilizar tablas de decisiones para escribir
especificaciones de proceso.
4. Cundo utilizar herramientas alternativas de
especificacin.
E n este captulo se explora la especificacin del proceso, la descripcin de

qu es lo que sucede en cada burbuja primitiva de nivel ms bajo en un DFD. Varios
textos, incluyendo [DeMarco, 1978], [Gane y Sarson, 1977] y [Wenberg, 1978] tam
bin utilizan el trmino minispec (como abreviatura de especificacin en miniatura)
como alternativa de especificacin de proceso. Sin importar el nombre, el propsito
de una especificacin de proceso es bastante claro: define lo que debe hacerse para
transformar entradas en salidas. Es una descripcin detallada de la poltica de ne
gocios del usuario que cada burbuja lleva a cabo.
www.FreeLibros.org
227
228
ESPECIFICACIONES DE PROCESO
Como veremos en este captulo, existe una variedad de herramientas que pg.
demos utilizar para producir una especificacin de proceso: tablas de decisiones
lenguaje estructurado (espaol, ingls, etc.), pre/post condiciones, diagramas de %
jo, diagramas de Nassi/Shneiderman, etc. A pesar de que la mayora de los analis
tas estn a favor del lenguaje estructurado, debe recordar que se puede usgr
cualquier mtodo mientras satisfaga dos requerimientos cruciales:
La especificacin dei proceso debe expresarse de una manera que pje,

dan verificar tanto el usuario como el analista. Precisamente por esta ra
zn se evita el lenguaje narrativo como herramienta de especificacin: gs
notoriamente ambiguo, sobre todo si describe acciones alternativas (deci
siones) y acciones repetitivas (ciclos). Por naturaleza, tambin tiende a
causar gran confusin cuando expresa condiciones booleanas compues
tas (esto es, combinaciones de ios operadores booleanos AND, OR v
NOT) (y, o, no, respectivamente).
El proceso debe especificarse en una forma que pueda ser comunicado

efectivamente ai pblico amplio que est involucrado. A pesar de que el
analista es tpicamente quien escribe la especificacin del proceso, habi
tualmente ser un pblico bastante diverso de usuarios, administradores,
auditores, personal de control de calidad y otros, el que leer la especifi
cacin del proceso. Una especificacin pudiera expresarse tal vez con
clculo de predicados, o en Pascal, o en un enfoque de diagramacirt for
mal como USE-IT de Higher Order Software;1 pero de nada sirven esas
especificaciones si la comunidad usuaria se rehsa a verlas. Lo mismo
pudiera suceder con las tablas de decisiones, con el lenguaje estructura
do o con otras herramientas; en gran medida esto es funcin de la perso
nalidad, antecedentes y humor de los usuarios con los que trate.
Como se mencion anteriormente, la mayora de los analistas usan el lenguaje

estructurado como mtodo favorito para escribir especificaciones de proceso. Tal
vez sea ms importante sealar que la mayora de los analistas y de las organizacio
nes utilizan una herramienta para escribir todas sus especificaciones.2 Esto es, en
mi opinin, un gran error: usted debe sentirse libre para utilizar una combinacin de
herramientas de especificacin, segn a) las preferencias del usuario, b) sus propias
preferencias y, c) la naturaleza propia de los diversos procesos.
1 Para m s inform acin ace rca de USE-IT, vea S tru ctu re d Techniques fo r C om putng, de James
Martin y C arm a McCIure. (Englew ood C liffs, N.J.: P rentice-H all, 1986),
2 Esto a m enudo lo causa la introduccin de un conjunto com pleto de e st nd a re s para el anlisis
e structurado en ia org a n iza ci n . A pesar de que los e stndares son un buen esfuerzo para comba
tir (a desidia, ignorancia y a n a rq u a total, a m enudo van dem asiado lejos y prescriben una solucin
rgida para to d o problem a. C om o lo indica el dicho: Si su nica herram ienta es un m artillo, todos
m undo parece un cla vo .
www.FreeLibros.org
ESPECIFICACIONES DE PROCESO 229
Una buena herramienta de especificacin de proceso debe tambin tener una

caracterstica: no debe imponer (o implicar) decisiones de diseo e implantacin arbitrarias. A menudo esto es muy difcil, pues el usuario, de quien depende la
p o ltic a que realizar cada burbuja en el DFD, suele escribirla en ios trminos en
0s que la lleva a cabo en la actualidad. Su trabajo como analista consiste en destiiar de esto la esencia de lo que dicha poltica es y no cmo se lleva a cabo hoy en
te rce ra
da.
Considere ei siguiente ejemplo: el analista discute un pequeo fragmento del
como lo ilustra la figura 11.1. Quiere desarrollar una especificacin de pro
ceso para ia burbuja etiquetada CALCULAR FACTOR-W. Dado que el analista no
est familiarizado con la aplicacin, entrevist al usuario para aprender que la polti
ca a seguir para calcular los factores-W para cualquier valor de entrada x es la si
guiente:
s is te m a ,
1.
El factor-W no se produce como resultado de un solo clculo. De hecho,

tenemos que empezar por hacer una adivinanza. El usuario dice que en
lo particular le gusta usar el 14 como primer intento de adivinar.
2.
Luego volvemos a adivinar. Esto se hace dividiendo el nmero que aca

bamos de adivinar entre el nmero x con el que comenzamos.
3.
Luego tomamos el resultado de dicho clculo y se lo restamos al nmero

que acabamos de adivinar.
4.
Tomamos el resultado del paso 3 y lo dividimos entre dos. Esto se con

vierte en nuestro nuevo nmero adivinado.
www.FreeLibros.org
Figura 11.1: Clculo
del
factor-W
230
5.
Si el nuevo nmero adivinado y el anterior son muy cercanos, digamo?

con diferencia menor a 0 .0 0 0 1, entonces nospodemosdetener; elnuey!
nmero adivinado es el factor-W . De otro modo, regrese al paso 2 y vuS|, |
va a repetir todo.
f
Podra argumentarse que esta especificacin de proceso es difcii de leer y

tender pues est escrita en lenguaje narrativo. De hecho, la descripcin siguiente
ms compacta (note que las barras verticales I en el HASTA significan el valor ab"
soluto de la expresin que encierran.
factor-W0 = 14
REPITE para N = 0 en pasos de 1
factor-WN+1 = (factor-WN - (X/factor-WN)) / 2
HASTA lfactor-WN+1 - factor-WNl < 0.0001

Sin embargo, incluso esto tiene fallas: describe una poltica en trminos de
una implantacin de procedimiento particular. La poltica, como pudiera ser evidente
(pero que igualmente pudiera no serlo), es el algoritmo de Newton-Raphson de apro
ximacin a la raz cuadrada.3 La siguiente especificacin de proceso describe la
misma poltica, pero da al diseador/programador completa libertad para escoger su
propio algoritmo:
PRECONDICION
Existe un nmero X no negativo
POSTCONDICION
Se produce un factor-W tal que
X = factor-W * factor-W
El programador puede en efecto optar por usar el algoritmo del usuario para
calcular la raz cuadrada, pero no debera sentirse restringido por el analista a ha
cerlo. De hecho, la atencin extravagante al algoritmo del procedimiento, sobre todo
en ia primera versin de la especificacin anterior, impeda por completo ver lo que
el proceso era en realidad.
Antes de explorar las diversas herramientas de especificacin de proceso, de
bera hacerse nfasis en un punto: las especificaciones de proceso slo se desarro
llan para los procesos de ms bajo nivel en un conjunto de diagramas por niveles en
un DFD. Como se ve en la figura 11.2, los procesos de mayor nivel se definen por
medio de la red de procesos del nivel inmediato inferior. En otras palabras, la espe
cificacin de proceso para una burbuja de nivel superior es el DFD de nivel inferior.
www.FreeLibros.org
3 intente el algoritm o en un par de casos de prueba. E ncontrar que converge b astante rpidamen
te.
E s c rib ir una especificacin de proceso adicional en lenguaje estructurado sera supgrfluo y redundante; esto es, creara una especificacin ms difcil de actualizar.4
En
este captulo nos concentraremos en tres herramientas principales de es

de proceso:
p e c ific a c i n
Lenguaje estructurado (espaol, ingls, etc.)
Pre/post condiciones
Tablas de decisin
Tambin comentaremos brevemente sobre varias herramientas menos utiliza

das: lenguaje narrativo, diagramas de flujo y diagramas de Nassi-Shneiderman.
1,1
LENGUAJE ESTRUCTURADO
El lenguaje estructurado, como el nombre indica, es lenguaje espaol (o in

gls u otro) con estructura . Es decir, es un subconjunto de todo el idioma con impor
tantes restricciones sobre el tipo de frases que pueden utilizarse y la manera en que
pueden juntarse dichas frases. Tambin se conoce con nombres como PDL (siglas
en ingls de lenguaje de diseo de programas) y PSL (lenguaje de planteamiento o
especificacin de problemas). Su propsito es hacer un balance razonable entre la
precisin del lenguaje formal de programacin y la informalidad y legibilidad del len
guaje cotidiano.
Una frase en lenguaje estructurado puede consistir en una ecuacin algebrai
ca, por ejemplo,
X = (Y*Z)/(Q+14)
o en una sencilla frase imperativa que consista en un verbo y un objeto. Ntese que
esta frase no tiene el punto y coma que termina una instruccin en muchos lengua
jes de programacin; puede o no terminar con un punto (,), dependiendo de sus
gustos en esta materia. Adems, note que las frases que describen los clculos
pueden usarse con prefijos de los verbos CALCULAR, AADIR, FIJAR, etc., por lo
que se pudo haber escrito el ejemplo anterior as:
CALCULAR X = (Y*Z)/(Q+14)
y tambin se tienen clculos expresados en lenguaje, como los siguientes:
4 Sin im portar esta advertencia, debem os sealar que, com o analista, a veces se le pedir que protuzca una especificacin de proceso escrita de los procesos de m ayor nivel. Esto suceder si ei
usuario decide que quiere m ostrar la especificacin a su jefe, y e preocupa que ei jefe no tolere ia
'dea de DFD por niveles. A s que el usuario le dir, M ire, s que no necesita una e sp e cificacin de
orcceso para estas burbujas de alto nivel, pero a p re cia ra que las e scribiera de to d os m odos para
Que el jefe pueda entender de qu se trata el siste m a . T en d r que lid ia r con este problem a con la
rastra diplom acia que utiliza para resolver todos ios dem s problem as p o ltico s de su proyecto.
www.FreeLibros.org
232
FIJAR IMPUESTO A 13
SUMAR 3 A X
MULTIPLICAR PRECIO UNITARIO POR CANTIDAD
DIVIDIR GANANCIAS ACTUALES ENTRE PERDIDAS ACTUALES
www.FreeLibros.org
Los verbos deben escogerse de entre un pequeo grupo de verbos orientados

g la accin tales como:
CONSEGUIR ( o ACEPTAR o LEER)
PONER (o MOSTRAR o ESCRIBIR)
ENCONTRAR (o BUSCAR o LOCALIZAR)
SUMAR
RESTAR
MULTIPLICAR
DIVIDIR
CALCULAR
BORRAR
ENCONTRAR
VALIDAR
MOVER
REEMPLAZAR
FIJAR
ORDENAR
En muchas organizaciones se llega a la conclusin de que entre 40 y 50 ver
bos son suficientes para describir cualquier poltica dentro de una especificacin de
proceso.
Los objetos (el tema de las frases imperativas sencillas) deben consistir slo
en datos que se han definido en el diccionario o ser trminos locales. Los trminos
locales son aquellos que se definen explcitamente en una especificacin de proceso
individual; slo son conocidos, relevantes y con significado dentro de dicha especifi
cacin de proceso. Un ejemplo tpico de trmino local es un clculo intermedio, que
se utiliza para producir una salida final del proceso.5 Por ejemplo, la especificacin
de proceso en lenguaje estructurado que se muestra a continuacin examina una se
rie de registros de pedidos en el almacn PEDIDOS, para calcular un total diario:
total-diario = 0
HACER MIENTRAS haya ms pedidos en PEDIOOS con fecha-de-pedido = fecha
de hoy
LEER ei siguiente PEDIDO en PEDIDOS con fecha-de-pedido = fecha de
hoy
MOSTRAR a Contabilidad n m e ro -d e -p e d id o , n o m b re -d e l-c lie n te y
cantidad -to tal, total-diario = total-diario + cantidad-total
5 Los trm inos ocales se definen dentro de la e sp e cificacin de proceso donde ocurren, y no se
definen en el d iccionario de datos. A menucio se derivan (o calculan d irectam ente) de trm inos que
ya estn en el d iccio n a rio de datos, de m odo que sera redundante a a d ir d ich o s t rm in o s locales.
Adems, por definicin, ios t rm in o s locales slo se conocen en un co n texto local (es decir, dentro
fte una burbuja en un DFD). N o deben a p arecer corno flu jo en el DFD, y usualm ente no form an p a r
le del vocabulario norm al de as palabras orien ta d a s a la a p licacin del usuario.
www.FreeLibros.org
234
FIN HACER
MOSTRAR a Contabilidad total-diario
Finalmente, el lenguaje estructurado permite que se combinen frases en unas

cuantas formas limitadas que se toman de las construcciones acostumbradas de |6
programacin estructurada.6
La construccin SI-ENTONCES-OTRO se utiliza para describir frases a|.

ternativas que se deben realizar segn el resultado de la decisin binaria
La construccin Si-ENTONCES-OTRO puede tomar cualquiera de las for.
mas siguientes:
SI condicin-1
frase-1
FIN SI
o bien
SI condicin-1
frase-1
OTRO
frase-2
FIN SI
De esta forma, el analista puede escribir:
SI el clien te vive en Nueva York
aadir clien te a PROSPECTOS-DE-MERCADO
FIN SI
o bien
SI edad-del-cliente es mayor que 65
fijar cuota a cuota-ancianos
OTRO
fijar cuota a cuota-norm al
FIN SI
La construccin CASO se utiliza para describir frases alternativas que se

efectuarn basndose en los resultados de una decisin multivaluada (er
contraste con la decisin binara que tiene lugar con la construccn SI
ENTONCES). La construccin CASO toma la forma general:
www.FreeLibros.org
6 Si no est fa m ilia riza d o con la program acin estructurada, consulte cua lq u ie ra de ios textos ordi
narios sobre el tem a, o vea algunos de los prim eros artcu lo s sobre el tem a que se recopilaron
[Yourdon, 1979j.
HACER CASO
CASO variable = valor-1
frase-1
CASO variable = valor-n

frase-n
OTRO
frase-n+1
FIN CASO
Por lo que el analista puede escribir:
HACER CASO
CASO edad-del-cliente < 13
fijar cuota a cuota-nios
CASO edad-del-cliente > 12 y edad-del-cliente < 20
fijar cuota a cuota-adolescente
CASO edad-del-cliente > 19 y edad-del-cliente < 65
fijar cuota a cuota-adu ltos
OTRO
fijar cuota a cuota-ancianos
FIN CASO
O, como otro ejemplo, considere la siguiente porcin de una especifica
cin de proceso en lenguaje estructurado:
HACER CASO
CASO estado = NY"
fijar im puesto-de-venta a 0.0825
CASO estado = NJ
CASO estado = CA
OTRO
fijar impuesto-de-venta a 0
FIN CASO
Ntese que la clusula OTRO suele usarse para abarcar situaciones que
el usuario se olvida de especificar y por las que el analista se olvida de
preguntar; a menudo llevar a discusiones entre el usuario y el analista
que de otra manera no sucederan sino hasta despus de puesto en ope
racin el sistema. Considere el siguiente ejemplo:
www.FreeLibros.org
236
HACER CASO
CASO form a-de-pago = efectivo
fijar descuento a 0.05
CASO form a-de-pago = tarjeta-de-crdito
fijar descuento a 0.01
OTRO
fijar descuento a 0
FIN CASO
El usuario podra cuestionar esta especificacin del proceso y preguntar
por qu el analista incluy el OTRO; el analista pudiera responder pre.
guntando acerca de pagos con cheque, cheques de viajero, monedas de
oro e intercambios.
La construccin HACER-MIENTRAS se usa para describir una frase qt*
deber llevarse a cabo repetitivamente hasta que alguna condicin booleana se haga verdadera. Toma la forma general:
HACER-MIENTRAS condicin-1
frase-1
FIN HACER
La prueba (en el ejemplo anterior, la condicin-i) se hace antes de que
se ejecute la frase-1, por lo cual, si la condicin no se satisface, es posi
ble que la frase-1 se ejecute cero veces.
Por ejemplo, el analista puede escribir:
HACER-MIENTRAS haya ms artculos en el pedido-del-clente
precio-extendido = precio-unitario*cantidad-de-unidades
FIN HACER
Muchas organizaciones incluyen otra estructura que ejecuta una frase es
pecificada por lo menos una vez antes de hacer una prueba para ver si
debe repetirse. Esta variante, usualmente conocida como la construccir
REPITE-HASTA, tiene la siguiente forma:
REPITE
frase-1
HASTA condicin-1
Se pueden construir frases compuestas a partir de combinaciones de frases
sencillas y las estructuras sencillas que se presentaron anteriormente, de acuerdo
con las siguientes reglas:
www.FreeLibros.org
1.
Una secuencia lineal de frases sencillas equivale (estructuralmente) a una

frase sencilla. As que la secuencia
frase-1
frase-2
frase-n
es estructuralmente equivalente a una frase sencilla nica y puede ser
sustituida dondequiera que se espere una frase sencilla. Esto permite
construir estructuras como la siguiente:
SI condicin-1
frase-1
frase-2
OTRO
frase-3
frase-4
frase-5
FIN SI
o bien
HACER MIENTRAS condicin-1
frase-1
frase-2
frase-3
FIN HACER
2.
Una construccin SI-ENTONCES-OTRO sencilla se considera estructural

mente equivalente a una frase nica sencilla. Esto permite que las estruc
turas SI-EN TO N C ES-O TR O se aniden dentro de otras e structuras
iguales, o dentro de estructuras HACER-MIENTRAS, o dentro de estruc
turas CASO, Por ejemplo:
SI condicin-1
frase-1
SI condicin-2
frase-2
frase-3
OTRO
frase-4
frase-5
FIN SI
frase-6
www.FreeLibros.org
238
OTRO
frase-7
SI condicin-3
frase-8
FIN SI
frase-9
FIN SI
3.
Una estructura HACER-MIENTRAS sencilla se considera estructuraimente equivalente a una frase nica sencilla. Esto permite que las estructuras
HACER-MIENTRAS se aniden dentro de otras estructuras iguales, o den
tro de estructuras SI-ENTONCES-OTRO, o dentro de estructuras CASO.
As, se puede tener una especificacin en lenguaje estructurado de la si
guiente naturaleza:
gran-total = 0
HACER-MIENTRAS haya ms pedidos que procesar
total-de-pedidos = 0
LEER el siguiente pedido de PEDIDOS
HACER-MIENTRAS haya ms artculos en ei pedido
total-de-pedidos = total-de-pedidos + nmerode-artculos
FIN HACER
MOSTRAR nm ero-de-pedido, total-de-pedidos
gran-total = gran-total + total-de-pedidos
FIN HACER
MOSTRAR gran-total
4,
Una estructura sencilla CASO se considera estructuralmente equivalente

a una frase nica sencilla. Esto permite que las estructuras CASO se ani
den dentro de otras iguales, dentro de estructuras SI-ENTONCES-OTRO
o dentro de estructuras HACER-MIENTRAS.
Como puede verse, esto permite construir arbitrariamente descripciones com

plejas de polticas de negocios, que a la vez mantienen un control estricto sobre el
vocabulario, organizacin y estructura de la descripcin. Sin embargo, esta comple
jidad es tambin la principal desventaja del lenguaje estructurado: si el analista com
pone una especificacin de proceso demasiado com pleja para ser entendida y
verificada por el usuario, entonces fall. Esto usuaimente se puede evitar mediante
las siguientes tres reglas:
1.
Restrinja la especificacin de proceso en lenguaje estructurado a una so

la pgina de texto (por ejemplo, una hoja de 8 x 11, que son 66 lneas de
texto en un sistema procesador de palabras). Si la especificacin ocupa
ms de una pgina, entonces el analista (con la ayuda del usuario) debe
www.FreeLibros.org
pensar en una forma totalmente distinta de formular a poltica (por ejem

plo, escoger un algoritmo diferente, ms sencillo). Si no se puede, enton
ces es posible que el proceso mismo (esto es. la burbuja dentro del DFD)
sea demasiado complejo, y debe partirse en una red de procesos ms
simples de nivel inferior.
2.
No permita ms de tres niveles de anidamiento (es decir, tres niveles de

estructuras anidadas SI-ENTONCES-OTRO o tres niveles de estructuras
CASO, etc.). En particular, en el caso de estructuras SI-ENTONCESOTRO, incluso ms de dos niveles de anidamiento es un indicio de que
sera preferible una especificacin mediante una tabla de decisiones; esto
se discute en la seccin 11.3.
3.
Evite confusiones acerca de los niveles de anidamiento utilizando san

gras, como se muestra en ios ejemplos anteriores. Esto se puede lograr
y controlar muy fcilmente si est utilizando algn tipo de auxilio automa
tizado para desarrollar las especificaciones de proceso (incluso algo tan
sencillo como un sistema estndar de procesamiento de textos). Si las
especificaciones de proceso las est tecleando manualmente alguna per
sona no familiarizada con la programacin o el anlisis estructurados,
tendr que explicarle con mucho cuidado qu tipo de sangras se desea;
tambin debiera revisar con cuidado e! texto resultante para ver que est
correcto.
Muchos analistas preguntan si se puede esperar que el usuario lea y entienda

una especificacin de proceso escrita en lenguaje estructurado. En esta rea, mi
experiencia ha resultado casi uniformemente positiva: los usuarios s pueden leer el
lenguaje estructurado, con as siguientes advertencias:
1.
Tendr que repasar una o dos veces el documento para asegurarse de

que entiendan el formato y las diversas construcciones. En ia primera
lectura, bien pudiera parecer un documento legal, sobre todo si ha enfati
zado la construccin SI-ENTONCES-OTRO y las dems.
2.
No se refiera a la especificacin del proceso como lenguaje estructura

do . De ser necesario, refirase a ella como una descripcin formal de la
poltica de negocios para realizar esta actividad .
3.
Ponga mucha atencin al formato global y la distribucin del documento;

la sangra de los bloques anidados de lgica es de especial importancia.
Algunos usuarios prefieren un estilo de sangra de silueta , es decir, don
de los niveles de sangra se numeran 1.1, 1.1.1, 1.1.1.1, etc.
En el caso de estudio del Apndice F se muestran diversos ejemplos de espe

cificaciones de proceso en lenguaje estructurado.
www.FreeLibros.org
240
11.2
PRE/POST CONDICIONES
Las pre/post condiciones son una manera conveniente de describir la funcnque debe realizar el proceso, sin decir mucho acerca dei algoritmo o procedmkgt
que se utilizar. Resulta ser un enfoque particularmente til cuando:
"]
1)
Ei usuario tiene tendencia a expresar ia poltica llevada a cabo por la by,J

buja en trminos de un algoritmo particular que ha estado utilizando dy.
rante dcadas.
2)
Ei analista est razonablemente seguro de que existen muchos agoru

mos distintos que podran usarse,
3)
El analista desea que el programador explore v a r i o s de estos a l g o r i t m o s ,

pero no quiere involucrarse personalmente con tales detalles y, sobre todo, n o q u i e r e e n r e d a r s e e n d i s c u s i o n e s c o n e i u s u a r i o a c e r c a d e l m r i t o J
relativo de cada uno.
|
Un ejemplo de una especificacin de proceso escrita con e! enfoque de iaI

pre/post condicin se muestra en la figura 11.3:
I
ESPECIFICACION DE PROCESO 3.5: CALCULAR EL IMPUESTO
SOBRE VENTAS
P recondicin 1
Ocurre DATOS-VENTA con TIPO-ITEM que corresponde con
CATEGORIA-ITEM en CATEGORIAS-IMPUESTO
P ostcondlcln 1
IMPUESTO-SOBRE-VENTA se hace igual a MONTO-VENTA 4
IMPUESTO
|
:
P recondicin 2
Ocurre DATOS-VENTA con TIPO-ITEM que no concuerda con
CATEGORIA-ITEM en CATEGORIAS-IMPUESTO
P ostcondicin 2
Se genera MENSAJE-ERROR
Figura 11.3: E specificacin de una pre/post co ndicin
Como puede verse, existen dos partes principales del proceso: precondiciones
y postcondiciones. Adems, tales especificaciones pueden contener trminos la
les, como se define en ia seccin 11.1 (ver tambin la Nota 5).
Las precondiciones describen todas las cosas (si hay) que deben darse antes
de que el proceso pueda comenzar a ejecutarse. A veces es conveniente pensar
que el proceso es la bella durmiente, y que las precondiciones representan el be
so mgico que despertar al proceso y lo echar a andar. De manera alternativa, se
www.FreeLibros.org
imaginar a las precondiciones como una garanta del usuario: Garantizo que
se active este proceso se cumplirn las siguientes cosas. Tpicamente, las
precondiciones describirn lo siguiente:
ouede
cuando
Qu entradas se encuentran disponibles. Estas entradas llegan mediante

un flujo conectado con un proceso, como se muestra en el DFD. Ntese
que puede haber casos en ios que diversos flujos entran a un proceso,
pero slo uno de ellos es precondicin necesaria para que se active el
proceso. Por ejemplo, si hubiera una especificacin que empieza con:
P recondicin
ocurre el dato X
asociada con el DFD que se muestra en la figura 11.4, se interpretara de
la siguiente forma: la llegada del dato X es el estmulo activador que hace
que el proceso empiece a trabajar. Como parte de su trabajo, busca en
tradas de los flujos Y o Z, o ambos, pero Y y Z no son necesarios para

que el proceso comience su trabajo.
Qu relacin debe existir entre las entradas. Muy a menudo, una precon
dicin especificar que deben llegar dos entradas con campos que co
rresponden (por ejemplo, detalles de pedidos y detalles de envo con ei
mismo nmero de cuenta). O bien, la precondicin puede especificar que
un componente de un dato de entrada debe estar dentro de cierto interva
lo (por ejemplo, pedido con fecha de entrega a ms de 60 das).
www.FreeLibros.org
Qu relaciones deben existir entre entradas y almacenes de datos. Una

precondicin pudiera estipular que exista un registro dentro de un alma
cn que corresponda con algn aspecto de un dato de entrada (por ejem-
242
po, la precondicin puede establecer que hay un pedido-de-cliente con 1

nmero-de-cuenta-de-cliente que corresponde con un nmero-de-cuenta, I
de-cliente del almacn de clientes).
f
Qu relaciones deben existir entre diferentes almacenes o dentro de ut I

almacn dado. Es decir, la precondicin podra establecer que hay yn i
pedido en el almacn de pedidos cuyo nmero-de-cuenta-de-cliente co- !
rresponde con el nmero-de-cuenta-del-ciiente en el almacn de clien- i
tes . O bien, la precondicin pudiera establecer que existe un pedido en i
el almacn de pedidos con fecha-de-envo igual a la fecha actual.
De manera similar, las postcondiciones describen lo que debe darse cuando e|

proceso ha concluido. Nuevamente, esto puede imaginarse como una garanta: Ga
rantizo que cuando el proceso haya concluido se debe cumplir lo siguiente . Las
postcondiciones tpicamente describen lo siguiente:
Las salidas que generar o producir el proceso. Esta es la forma ms

comn de postcondicin (por ejemplo, se producir una factura).
Las relaciones que existirn entre ios valores de salida y los valores originales de entrada. Esto es comn para la situacin donde una salida es
una funcin matemtica directa de un valor de entrada. De esta forma,
una postcondicin pudiera afirmar que la factura-total se calcula como
la suma de precios-unitarios-de-artculos ms costos-de-envo.
Las relaciones que existirn entre valores de salida y ios valores en uno o
varios de los almacenes. Esto es comn cuando la informacin debe re
cuperarse de un almacn y utilizarse como parte de la salida de un proce
so. Por ejemplo, una especificacin de proceso pudiera tener como
postcondicin la siguiente afirmacin: el balance-actuai en el almacn
INVENTARIO se incrementar con cantidad-recibida, y el nuevo balan
ce-actual se producir como salida de este proceso.
Los cambios que se hayan dado en ios almacenes: nuevos artculos aa

didos, artculos existentes que se hayan modificado, o artculos existentes
que se hayan eliminado. As, pudieran verse afirmaciones tales como el
pedido se anexar ai almacn de PEDIDOS, o el registro de clientes
se eliminar del almacn de CLIENTES.
Cuando se est construyendo una especificacin de pre/post condiciones se

debe comenzar por describir las situaciones normales de proceso. Pudieran existir
diversas situaciones normales diferentes (por ejemplo, combinaciones nicas de re
laciones de entrada/almacenaje vlidas), cada una de las cuales se expresa como
precondicin distinguible e individual. Para cada una de estas precondiciones se de
be describir la condicin de la burbuja del proceso cuando se han producido las sali
das y se han modificado los almacenes. Despus de haber descrito las situaciones
www.FreeLibros.org
de proceso, deben incluirse precondiciones y postcondiciones apropiadas

ra ios casos de error y casos anormales. Considere la especificacin de pre/post
c o n d ic io n e s que se muestra en la figura 1 1 .5 ( b ) , que se desarrollara para un nuevo
gjsterna de la especificacin narrativa de la figura 11,5(a).
n o rm a le s
Si un cliente dice que est cla sifica d o com o cliente que puede llevar
m ercanca a su cuenta" cuando llega a ia ca ja a pagar, entonces
busco su cuenta en mi archivo. Si la encuentro, y no est sealada
com o su sp e nd id a o ca n ce la d a , entonces cargo la m ercanca a
su cuenta con el nm ero de sta y el m onto de la venta. De otra
m anera, le digo que tendr que pagar en e fe ctivo o h ablar con el
gerente.
Figura 11.5(a): Un ejem plo de e sp ecificaci n narrativa

P recondicin 1
El comprador llega con un nmero-de-cuenta que
corresponde con un nmero de cuenta en CUENTAS,
cuyo cdgo-de-status se pone en vlido .
P ostcondici n 1
Se produce una factura con nm ero-de-cuenta y
monto-de- venta.
P recondicin 2
La precondicin 1 falla por algn motivo (el nmerode- cuenta no se encuentra en CUENTAS, o el cdgo-destatus no es vlido).
P ostcondici n 2
Se produce un mensaje de error.
Figura 11.5(b): Ejem plo de pre/post condiciones
Aunque el enfoque de pre/post condiciones sea bastante til y tenga un gran
nmero de ventajas, hay ocasiones en las cuales puede no ser apropiado. La falta
de pasos intermedios entre entradas (precondiciones) y salidas (postcondicones) es
deliberada y consciente, pero puede volverse difcil de entender si el lector no visua
liza algn tipo de procedimiento que lleve de las entradas a las salidas. Adems, si
existen relaciones complejas entre entradas y salidas, podra ser ms fcil escribir
una especificacin utilizando lenguaje estructurado. Un ejemplo de especificacin
de precondicin/postcondicin que probablemente sea demasiado complicado se
muestra en la figura 11.6
DETERMINAR TASA DE PRESTAMO SEGUN FACTORES DE

COMPRADORES
www.FreeLibros.org
Precondicin 1
Ocurre una solicitud-de-p r stam o
244
y antigedad > 5 o valor-neto > m onto-del-prstam o

y gastos-m ensuales < 0.25 * m onto-del-prstam o o garanta-colateral > 2 *
m onto-del-prstam o y edad > 25
o garanta-colateral > m onto-del-prstam o y edad > 30
o antigedad > 2 y valor-n eto > 2 * m onto-del-prstam o y edad > 21 y
gastos-m ensuales < 0.5 * m onto-del-prstam o
P ostcondicin 1
m onto-aprobado = m onto-del-prstam o
Figura 11.6: E specificacin de pre/post con d ici n dem asiado com plicada
Como con todas las formas de especificacin de proceso, permita que su pro
pio juicio y las reacciones del usuario lo guen; si el usuario encuentra la especifica
cin de precondicin/postcondicin demasiado difcil de leer, escoja otro formato. En
el caso de estudio del apndice G se muestra el enfoque de precondicin/postcondi
cin; el enfoque alternativo de lenguaje estructurado se utiliza en el caso de estudio
del apndice F. Analice cuidadosamente ambos casos de estudio para determinar lo
adecuado de estas dos herramientas de especificacin de proceso.
11.3
TABLAS DE DECISION
Existen situaciones donde ni el lenguaje estructurado ni las pre/post condicio

nes son adecuadas para escribir especificaciones de proceso. Esto se da sobre to
do s el proceso debe producir alguna salida o tomar alguna accin basada en
decisiones complejas. Si las decisiones se basan en diversas variables distintas
(por ejemplo, datos de entrada), y si dichas variables pueden tomar diversos valores,
entonces la lgica expresada por el lenguaje estructurado o por las pre/post condi
ciones probablemente sea tan compleja que el usuario no la comprender. Proba
blemente sea preferible una tabla de decisiones.
Como se muestra en la figura 11.7, una tabla de decisiones se crea listando to
das las variables relevantes (a veces conocidas como condiciones o entradas) y to
das las acciones relevantes en su lado izquierdo; ntese que las variables y acciones
estn separadas por medio de una lnea horizontal gruesa. En este ejemplo, las va
riables son lgicas, lo cual significa que pueden tomar el valor de verdadero o falso.
En muchas aplicaciones es fcil (y preferible) expresar las variables como bi
narias (verdadero-falso), pero tambin se pueden construir las tablas de decisin a
partir de variables multivaluadas; por ejemplo, se puede construir una tabla de deci
siones con una variable llamada edaci-del-ciiene , cuyos valores relevantes sean
menos de 10 , entre 10 y 30 , y ms de 30.
A continuacin, se lista en columnas separadas cada combinacin posible de
valores de ias variabies; cada columna usualmente se conoce como regla. Una re
gla describe una accin (o acciones) que deben llevarse a cabo para una combina-
www.FreeLibros.org
pin especfica de valores de las variables. Por lo menos debe especificarse una ac
cin para cada regla (esto es, para cada columna de la tabla de decisiones), o ei
cornp0rtamiento del sistema para tal situacin no quedar especificado.
1
Sexo
pe so > 1 0 0
M e d ica m e n to 1
Edad>
21
X
X
X
X
N ing n m e d ic a m e n to
X
X
X
X
Figura 11.7: Tabla de decisiones tpica

Si existen N variables con valores binarios (verdadero-falso), entonces existi
rn 2n reglas distintas; as que si existen tres condiciones, habr 8 reglas, y si hay 7
condiciones habr 128 reglas. Enumerar todas las reglas es un proceso sencillo. Al
tratar ei S (o V) como un cero binario, y el No (o F) como un uno binario, es fcil ge
nerar una secuencia de 000, 001, 0 1 0 , 011, 100, 101, etc., hasta que se hayan ge
nerado todas las 2N combinaciones.7
Debe discutirse cada regia con el usuario para asegurarse de que se ha identi
ficado la accin o acciones correctas para cada combinacin de variables. Es bas
tante comn, ai hacer esto, encontrar que e usuario jams ha pensado en ciertas
combinaciones de variables, o que nunca hayan ocurrido en su experiencia.8 La
ventaja dei enfoque de la tabla de decisiones es que ei analista se puede concentrar
en una. regia a ia vez.
7 Desde luego, habr situaciones en (as cuales las co n d icio n es de a tabla de d e cisio n e s no sean
binarias por naturaleza, sino que puedan tom ar diversos va lo re s (por ejem plo, una so licitu d de se
guro puede in volucrar edad-de-clierrte, y puede usar valores tales com o m enor de 18 aos , de
18 a 64 , y de 65 o m s ). Para d e term in a r ei nm ero total ele regias en una tabla de stas debe
mos m ultiplicar el nm ero de valores que puede tornar ia va riab le 1 por ei nm ero de va riab le s que
Puede lom ar a variable 2 por ... el nm ero de valores que puede to m a r la va riab le N. As. si tene
mos una aplicacin donde la v a ria b le 1 puede tom ar 3 va lo re s, la 2 puede tom ar 5, y ia 3 puede to
mar 4, entonces necesitarem os 3 x 5 x 4 = 60 regias d istintas,
www.FreeLibros.org
8 Existen regias para sim p lifica r as tablas de de cisio n e s y co m b in a r diversas regias en regas com
puestas, pero no se vern en este libro. Vase [Yourdon, 1976] para m ayores detalles.
246
Otra ventaja del enfoque de la tabla de decisiones es que no implica ninguna 1

forma particular de implantacin. Es decir, cuando el analista entrega la tabla (junto
con los DFD, y otras cosas) al diseador/programador, hay una tremenda libertad de
eleccin en trminos de la estrategia de implantacin: la tabla de decisiones puede
programarse con afirmaciones anidadas tipo SI, con una construccin CASO o con
una construccin GO TO DEPENDING ON de COBOL; en ei caso extremo, un generador de cdigo de tabla de decisiones puede generar cdigo automticamente des
de la tabla. Por ello, a menudo se conocen las tablas de decisiones como una
herramienta de modelado de sistemas que no es de tipo procedimiento, pues no es
pecifican algn algoritmo de procedimiento especfico para realizar las acciones requeridas.
En resumen, deben seguirse ios siguientes pasos para crear una tabla de de
cisiones para una especificacin de proceso:
1.
Identificar todas las condiciones, o variables, de la especificacin. Identi

ficar todos los valores que cada variable pueda tomar.
2.
Calcular el nmero de combinaciones de las condiciones. Si todas las

condiciones son binarias, entonces existen 2N combinaciones de N varia
bles.
3.
Identificar cada posible accin que se pide en la especificacin.
4.
Crear una tabla de decisiones vaca, listando todas las condiciones y

acciones en el lado izquierdo y numerando las combinaciones de las con
diciones en la parte superior de la tabla.
5.
Listar todas las combinaciones de condiciones, una para cada columna

de ia tabla.
6.
Examinar cada columna (conocida como regla) e identificar las acciones

apropiadas que se deben tomar.
7.
Identificar con el usuario las omisiones, contradicciones o ambigedades.
11.4
OTRAS HERRAMIENTAS DE ESPECIFICACION DE PROCESO
11.4.1
G rficas y diagram as
En algunos casos puede ser apropiado expresar una especificacin de proce

so como una grfica o diagrama. De hecho, el usuario pudiera tener ya una grfica
o diagrama que se est utilizando para llevar a cabo aquella parte de la aplicacin.
De ser as, sela. No hay necesidad de que el analista traduzca la grfica a lengua
je estructurado; en lugar de ello, deje que el programador traduzca la grfica directa
mente a COBOL, FORTRAN o algn otro lenguaje de programacin, cuando sea el
momento de implantar el sistema.
www.FreeLibros.org
C o n s id e re , por ejemplo, una especificacin d e proceso que determina el monto

de! seguro del cliente como funcin de su edad. El usuario dijo que la poltica actual
e ne go cio es determinar el monto a partir de la grfica que se muestra en la figura
11.8 .
Figura 11.8: Prima de seguros com o fu n c i n de la edad

Suponiendo que la poltica no vaya a cambiar cuando se construya un nuevo
sistema, y suponiendo que el monto del seguro sea slo funcin de la edad, no hay
necesidad de que el analista haga ms trabajo. La figura 11.8 es la especificacin
del proceso.
11.4.2
Lenguaje n arrativo
Como se ha indicado varias veces en este captulo, el lenguaje narrativo no es

una herramienta recomendable para escribir especificaciones de proceso. Esto se
debe a:
Un vocabulario no restringido (es decir, uso indiscriminado de sujetos,

verbos y adjetivos) hace que sea probable que la descripcin del proceso
incluya trminos que no estn en el diccionario de datos y cuyo significa
do no quede claro.
Las acciones alternativas (es decir, decisiones) a menudo se expresan de

una manera burda y ambigua. Esto se vuelve an ms peligroso cuando
se expresan decisiones anidadas.
Las acciones receptivas (es decir, ciclos) tambin se expresan de una

manera burda y ambigua. Los ciclos anidados son extremadamente peli
grosos cuando se expresan en lenguaje coloquial.
www.FreeLibros.org
248
El concepto de estructuras de bloque slo se puede expresar con sari,

gras o con una presentacin de silueta. Si se est dispuesto a llega,
hasta aqu, bien puede usarse de una vez la notacin formal del lenguaje
estructurado.
Si por alguna razn se ve obligado a usar lenguaje narrativo, debe por lo menos mantener algunas de las ventajas del enfoque altamente diferenciado del an.
sis estructurado que hemos discutido a lo largo de todo este libro. Es decir, bajo
ninguna circunstancia debe permitirse tener que legar a escribir una especificacin
monoltica de novela victoriana de 2 000 pginas. Por lo menos, divida la especificacin en porciones pequeas, de modo que puedan escribirse 2 000 cuentos cortos*
independientes.
11,4.3
Diagramas de flu jo
Se ha evitado hasta ahora el uso de diagramas de flujo en el anlisis, pero es

to es reflejo de la falta de inters actual por ellos ms que una denuncia.9 Mucho ds
la crtica hacia ellos result de su mal uso en las dos siguientes reas:
1.
Como herramienta de alto nivel de modelado de sistemas, los diagramas

de flujo son muy malos. Un diagrama de flujo muestra una lgica secuen
cia! y de tipo procedimiento; como se vio en el captulo 9, los DFD son
una herramienta ms apropiada para modelar una red de procesos no sin
cronizados y comunicados entre s.
2.
No hay nada que impida que el analista pueda crear un diagrama de flujo
no estructurado y arbitrariamente complejo, del tipo que se muestra en la
figura 11.9.
Sin embargo, si el diagrama de flujo se usa slo para describir lgica detallada
y si el analista de sistemas se limita a los smbolos de elaboracin de diagramas de
flujo equivalentes a las construcciones del espaol (u otro lenguaje) estructurado
que se exponen en la seccin 11.1, entonces no tiene nada de incorrecto su uso.
Para crear un diagrama de flujo estructurado, el analista de sistemas tiene que orga
nizar su lgica con las combinaciones anidadas de los smbolos de diagrama de flujo
que se muestran en la figura 11.10.10
9 S in e m b a rg o , es in te re s a n te n o ta r q u e lo s d ia g ra m a s d e flu jo p u d ie ra n e s ta r a p u n to de experi
m e n ta r un re n a c im ie n to . El tra b a jo re c ie n te d e D a v id S c a n ia n d e la U n iv e rs id a d E s ta ta l d e Califor
n ia e n S a c ra m e n to m u e s tra q u e lo s e s tu d ia n te s d e p r o g ra m a c i n p r e fie re n ro tu n d a m e n te ios
d ia g ra m a s d e flu jo p a ra a p re n d e r a lg o ritm o s . Si e s to re s u lta c ie rto p a ra lo s e s tu d ia n te s d e progra
m a c i n , p u d ie ra s e rlo ta m b i n p a ra ios u s u a rio s . P a ra m s d e ta lle s s o b re e s to , v e a e l documento
de S c a n ia n titu la d o : A N ic h e fo r S tru c tu re d F lo w c h a rts , Proceedings of the 1987 ACM Compute
www.FreeLibros.org
Science Conference.
10 P a ra m s in fo rm a c i n s o b re io s d ia g ra m a s d e flu jo e s tru c tu ra d o s , v a s e ei te x to c l s ic o , [Bt

y J a c o p in i, 1 9 8 6 ].
Una alternativa es el uso de los diagramas de Nassi-Shneiderman, que se discuten en la seccin 11.4.4. Sin embargo, debe sealarse que muy pocos analistas
utilizan diagramas de flujo para especificaciones de proceso (ni, para el caso, para
Figura 11.9: Un diagram a de flu jo no e structurado
Figura 11.10: Los sm bolos de Bohm -Jacopini en un diagram a de flu jo

estru cturad o
www.FreeLibros.org
250
diseo tampoco). Aunque las herramientas automatizadas que se describen en e| |

Apndice A pueden usarse para crear y mantener diagramas de flujo, ia verdad
1
que el lenguaje estructurado, las tablas de decisiones y las especificaciones
pre/post condiciones son ms fciles de crear y mantener.
f
11.4.4
Los diagram as de Nassi-Shneiderm an
Cuando por primera vez se empez a volver popular la programacin estructu- t

rada a mediados de los aos 70, ios diagramas de Nassi-Shneiderman se introduje- I
ron como una tcnica estructurada de creacin de diagramas de flujo; vase [Nassi y l
Shneiderman, 1973] y [Chapn, 1974]. Un diagrama tpico Nassi-Shneiderman tiene !
la forma que se muestra en la figura 11.11.
Ntese que una afirmacin sencilla imperativa se representa por medio de un
rectngulo, como muestra la figura 11.12(a); el rectngulo tambin puede utilizarse I
para representar un bloque de afirmaciones secuenciales. La construccin binaria |
Sl-ENTONCES-OTRO se representa por medio de la notacin grfica de la figura I
11.12(b); y la construccin repetitiva HACER-MiENTRAS se representa por la nota-1
clon grfica de la figura 11.12(c).
|
Los diagramas de Nassi-Shneiderman usualmene son ms organizados, ms I
estructurados y ms comprensibles que un diagrama de flujo tpico; por eo, a veces ||
se los prefiere como herramienta para crear especificaciones de proceso. Sin em- f
bargo, an requieren una cantidad no trivial de grficos, y no est claro que los grfi- j
eos aadan mucho valor. Como se ha odo murmurar a muchos analistas tras |
pasarse una hora creando un diagrama de Nassi-Shneiderman, Esto es slo len- [
guaje estructurado con cajas dibujadas alrededor de las instrucciones .
[
www.FreeLibros.org
Figura 11.11: Diagrama tpico de Nassi-Schneiderman
enunciado 1
enunciado 2
Figura 11.12(a): R epresentacin de un enunciado secuencia!
condicin
T
enunciado 1
F
enunciado 2
Figura 11,12(b): R epresentacin de ia co n stru cci n SI-ENTONCES-OTRO
Figura 11.12 (c): R epresentacin de una c o n stru cci n HACER-MIENTRAS

Por otro iado, investigaciones recientes llevadas a cabo por David Scanlan en
la Universidad Estatal de California [Scanlan, 1987] muestran que del 75 ai 80 por
ciento de ios estudiantes de computacin prefieren con mucho los diagramas de
Nassi-Shneiderman ai pseudocdigo al estudiar algoritmos complejos; aunque esto
no coincide con la reaccin negativa tpica de los programadores con experiencia
hacia los diagramas de flujo, las conclusiones de Scanlan se basaron en estudios
cuidadosos y analticos de factores en una muestra de varios cientos de estudiantes.
Aunque los usuarios finales no necesariamente tienen las mismas preferencias que
los estudiantes de computacin, existe por lo menos la posibilidad de que prefieran
la representacin grfica de una especificacin de proceso a una narrativa textual.
www.FreeLibros.org
252
11.5
RESUMEN
El propsito de este captulo fue mostrar que hay muchas maneras diferentes
de describir la poltica detallada del usuario dentro de cada burbuja primitiva en un
DFD. Aunque el lenguaje estructurado sea la tcnica ms comnmente usada en |g
actualidad, debe considerarse el uso de tablas de decisiones, diagramas de flujo,
pre/post condiciones o cualquier otro enfoque que pueda verificarse y comunicarse
fcilmente a sus usuarios.
Tenga en mente que las especificaciones del proceso representan la mayor
parte del trabajo detallado que se tiene en la construccin de un modelo de siste
mas; pueden existir cientos, o incluso miles, de especificaciones de proceso, cada
una de las cuales mida una pgina. Debido a la cantidad de trabajo involucrado, podra considerar ei enfoque de implantacin descendente que se discuti en el captu
lo 5: comenzar la fase de diseo e implantacin de su proyecto antes de que hayan
concluido todas las especificaciones de proceso.
Tenga en mente tambin que la actividad de escribir especificaciones de pro
ceso sirve como prueba de cordura para los DFD que ya se hayan desarrollado.
Podra descubrirse que la especificacin del proceso requiere flujos de datos de en
trada o de salida adicionales (es decir, flujos que no aparecieron en el DFD). Y al
escribirla podra tambin encontrarse que se necesitan funciones adicionales; por
ejemplo, al escribir la especificacin para una funcin que aade un nuevo registro
ai almacn de CLIENTES, podra notarse que el DFD no tiene una burbuja que mo
difique o elimine un registro de dicho almacn. As que se pueden esperar cambios,
revisiones y correcciones del modelo de DFD, basadas en el trabajo detallado de la
escritura de las especificaciones del proceso.
REFERENCIAS
1.
Tom DeMarco, S tructured Analysis and Systems Specification. Englewood

Cliffs, N.J.: Prentice-Hall,1979.
2.
Chris Gane y Trish Sarson, Structured Systems Analysis: Tois and Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1978.
3.
Edward Yourdon, Techniques of Program Structure and Design, 2a edicin, En

glewood Cliffs, N.J.: Prentice-Hall, 1988.
4.
James Martin y Carma McCiure, Diagramming echniques for Software Engineering. Englewood Cliffs, N.J.: Prentice-Hall, 1985.
5.
Vctor Weinberg, Structured Analysis. Englewood Cliffs, N.J.: Prentice-Hall,

1978.
www.FreeLibros.org
6.
Edward Yourdon, Ciassics in Software Engineering. New York; YOURDON

Press, 1979.
C o rea do
Bohm y Guiseppe Jacopini, Flow Diagrams, Turing Machines, and

Languages with Only Two Formation Rules, Communications o f the ACM,
yol.9, nmero 5 (mayo de 1966), pp. 366-371. Tambin reimpreso en Ciassics
in Software Engineering (op. cit.).
|. Nassi y B. Shneiderman, Flowchart Techniques for Structured Programming , ACM SIGPLAN Notices, Vol. 8, nmero 8 (agosto de 1973), pp. 12-26.
Ned Chapn, New Forma! for Flowcharts, Software-Practice and Experisnce,

Vol. 4, nmero 4 (octubre a diciembre, 1974), pp. 341-357.
jO
H. McDaniel, editor, Application of Decisin Tabies. Princeton, N.J.: Brandon

Systems Press, 1970.
1 .
S. Poliack, H. Hicks, y W. Harrison, Decisin Tables: Theory and Practice.

Nueva York, Wlley, 1971.
12.
T.R. Giidersieeve, Decisin Tables and their Practica! Applications in Data Pro
cessing. Englewood Cliffs, N.J.: Prentice-Hall, 1970.
13.
David Scanian, Cognitive Factors in Preference for Structured Flowcharts: A

Factor Analytic Study, presentado en la primera conferencia de autores de
YOURDON Press, Nueva York, 5 de diciembre de 1987.
PREGUNTAS Y EJERCICIOS:
1.
Considere la siguiente especificacin, que se da en forma narrativa. Cul de

las herramientas de especificacin que se presentaron en este captulo cree
que sera la ms apropiada? Por qu?
C u a n d o m e lle g a u n a s o lic itu d d e c o m p ra , m i ta re a co n siste en e s
c o g e r a un p ro v e e d o r d e n u e s tro a rc h iv o d e p ro v e e d o re s d is p o n i
b le s . D e s d e lu e g o , a lg u n o s p ro v e e d o re s se e lim in a n de in m e d ia to
p o rq u e s u s p re c io s son d e m a s ia d o e le v a d o s , o p o rq u e se h a n p u e s
to te m p o ra lm e n te en la lista n e g ra p o r su b a ja c a lid a d . P e ro mi
v e rd a d e ra ta re a es escoger al m ejor p ro v e e d o r de e n tre io s q u e c a
lific a n : e l q u e e n tre g a r nuestro p e d id o e n e l tie m p o m s c o rto . Mi
je fe tena un s is te m a p a ra e stim ar el tie m p o d e e n tre g a , y m e lo e n
s e , p e ro a h o ra s lo v e o dnde e s t ei p ro v e e d o r, la c a n tid a d d e
a rtc u lo s p e d id o s y la fe ch a en la q u e n e c e s ita m o s la s c o s a s , y s
cu l p roveedor e s ei m e jo r... y a ni s iq u ie ra e s to y seguro d e cm o lo
hago.
2.
Qu es una especificacin de proceso? Cules son sus objetivos?
3.
Cules son las cinco herramientas comunes para modelado de especificacio

nes de proceso?
www.FreeLibros.org
4.
Cules son los tres requerimientos que debe satisfacer una especificacin de
proceso?
254
5.
Debe un proyecto de desarrollo de sistemas utilizar una soia herramienta pg.

ra las especificaciones de proceso? Por qu?
6.
Proyecto de investigacin: Qu herramientas de especificacin se utilizan en

su organizacin? Existen restricciones sobre qu herramientas deban usar,
se? Cree que se estn usando las herramientas correctas?
7.
Cules burbujas de un DFD requieren especificaciones de proceso?
8.
Cules son las consecuencias de escribir especificaciones de proceso para

burbujas no atmicas (no primitivas)?
9.
Cmo debe el analista determinar las especificaciones de proceso para una

burbuja?
10.
Cmo es que a veces ias especificaciones de proceso imponen decisiones

arbitrarias de diseo e implantacin? Cules son las consecuencias de esto?
11.
Proyecto de investigacin: Encuentre un ejemplo de especificacin de proceso

en su organizacin que muestre decisiones de diseo o implantacin arbitra
rias. Cmo lo reescribira para evitar ese problema?
12.
D una definicin del trmino Lenguaje Estructurado. Qu sinnimos hay pa

ra este trmino?
13.
Cuntos verbos se necesitan para formar frases del lenguaje estructurado?

Sugiera una lista de 20 verbos.
14.
Por qu se necesitan usualmente ecuaciones algebraicas en una especifica

cin de proceso en lenguaje estructurado?
15.
Qu caractersticas debieran tener los objetos en una especificacin de pro

ceso en lenguaje estructurado?
16.
Qu son los trminos locales?
17.
Deben incluirse trminos locales en ei diccionario de datos? Por qu?
18.
Aparecen los trminos locales como flujos en los DFD?
19.
D un ejemplo especfico de un trmino local.
20.
Qu construcciones de la programacin estructurada se utilizan en el lengua

je estructurado?
21.
Cul es el propsito del trmino O TR O en el lenguaje estructurado?
www.FreeLibros.org
22.
Cul es la diferencia entre la construccin H A C E R -M iE N T R A S y la construc

cin R E P IT E -H A S T A en el lenguaje estructurado?
23
Qu es una frase compuesta?
24
Se necesita la construccin C A S O en el lenguaje estructurado? Cules son

sus ventajas y desventajas?
25
Cules son los cuatro componentes de una frase compuesta?
26.
Cules la diferencia entre (a)

(a)
y (b)?
SI A E N T O N C E S B
SI B E N T O N C E S
frase-1
O TRO
frase-2
OTRO
frase-2
(b)
SI A Y B E N T O N C E S
frase-1
O TR O
frase-2
Cul de estos dos ejemplos cree que sea ms fcil de entender? Por qu?
27.
Proyecto de investigacin: Construya varios ejemplos similares al de la pre

gunta 26, y haga una encuesta entre sus usuarios para ver cul versin prefie
ren.
28.
Cules son las tres reglas que deben seguirse para asegurarse de que una
especificacin en lenguaje estructurado ser legible?
29.
Cree lid. que tres niveles de construcciones anidadas SI sean correctos en

una especificacin en lenguaje estructurado? Por qu?
30.
Proyecto de investigacin: Haga varios ejemplos de especificaciones de proce

so en lenguaje estructurado que empleen dos, tres y cuatro niveles de cons
trucciones SI anidadas. Haga una encuesta para determinar, en promedio,
cuntos niveles estn dispuestos a aceptar los usuarios en su organizacin.
31.
Cul es el verdadero propsito de la sangra en una especificacin de proce

so en lenguaje estructurado?
32.
Por qu es importante hacer revisiones de las especificaciones de proceso

en lenguaje estructurado con ei usuario apropiado?
www.FreeLibros.org
33.
Cul es el propsito de utilizar una numeracin de tipo silueta en una espe

cificacin de proceso en lenguaje estructurado?
256
34.
D una definicin de una tcnica de especificacin de precondicin/postcondicin.
35.
Cul es la diferencia entre la tcnica de especificacin del lenguaje estructu

rado y ia de precondicin/postcondicin?
36.
Bajo qu condiciones es buena la tcnica de especificacin de precondicin/postcondicin para que la use el analista?
37.
D una definicin de precondicin.
38.
Cules son las cuatro cosas que usualmente describe una precondicin?
39.
Cul es la relacin entre precondiciones en una especificacin de proceso y

flujo de entrada en un DFD?
40.
Qu pasa si no se satisfacen las precondiciones en una especificacin de

proceso?
41.
D una definicin de postcondicin.
42.
Cules son las cuatro cosas que tpicamente describe una postcondicin?
43.
Cul es la relacin entre postcondiciones y flujos de salida en un DFD?
44.
Si una especificacin de proceso tiene cuatro conjuntos de precondiciones,

cuntos conjuntos de postcondiciones debe tener?
45.
Cul es el nmero mnimo de precondiciones que pudiera tener una especifi

cacin de proceso?
46.
Cules son las desventajas en potencia dei enfoque precondicin/postcondi

cin?
47.
Proyecto de investigacin: Encuentre un ejemplo de una especificacin real a

la que no le quede bien el enfoque de precondicin/postcondicin. Por qu
no le quedara bien?
48.
Vea la figura 11.6. Cul sera una herramienta de modelado mejor para crear
una especificacin de proceso para esa situacin?
49.
Proyecto de investigacin: Encuentre un ejemplo de una especificacin de pro

ceso real a la que s le quede bien el enfoque de precondicin/postcondicin.
Por qu le quedara bien?
50.
Qu es una tabla de decisiones? Cules son sus componentes?
www.FreeLibros.org
51.
Bajo qu condiciones la tabla de decisiones es una buena herramienta para

modelar especificaciones?
g2
Qu tiene mal ia siguiente tabla de decisiones?
Edad mayor de 21 aos
Sexo Masculino
Medicamento 1
Medicamento 2
53 .
Qu tiene mal la siguiente tabla de decisiones?

Estatura mayor de 1.80 m
Peso mayor de 100
Prima de seguro = $100
X
X

54.
Qu tiene mal la siguiente tabla de decisiones?

Estatura mayor de 1.80 m
Peso mayor de 100
X
X

55.
Qu diferencia hay entre una tabla de decisiones con variables binarias y una
con variables muitivaluadas?
www.FreeLibros.org
56.
Si una tabla de decisiones tiene N variables binarias, cuntas reglas debe te

ner?
258
57.
Bajo qu condiciones debiera ei analista usar una grfica para una espeoifi.
cacin de proceso?
5 8.
Cules son las ventajas que tiene una grfica sobre el lenguaje estructurado
como herramienta para el modelado de especificaciones de proceso?
5 9.
Cules son las cuatro principales desventajas del lenguaje narrativo corno
herramienta para el modelado de especificaciones de proceso?
60.
Qu reglas se deben seguir en caso de que se tenga por fuerza que usar len
guaje narrativo como herramienta de modelado para especificaciones de proceso?
61.
Cules son las dos crticas que comnmente se hacen a los diagramas de
flujo como herramienta de modelado?
62.
Cules son las tres componentes de un diagrama de flujo estructurado?
63.
Proyecto de investigacin: Muestre la misma especificacin a un usuario en lg

forma de lenguaje estructurado y en forma de diagrama de flujo. Qu enfo
que se prefiere? Para ms informacin, vea [Scanian, 1987],
64.
Qu es un diagrama de Nassi-Shneiderman? Cul es la diferencia entre un

diagrama de flujo y un diagrama de Nassi-Shneiderman?
65.
Tomado de Structured Analysis, de Vctor Weinberg (Nueva York: YOURDON

Press, 1978): Escriba una tabla de decisiones para la siguiente especificacin
narrativa, e indique las omisiones, ambigedades o contradicciones que en
cuentre:
La tie n d a S w ell e m p le a a un cie rto n m ero de ve n d ed o re s para
ve n d er una va rie d a d de artcu io s. La m ayo ra de e sto s ve n d ed o re s
obtienen sus ingresos efe co m isiones sobre los a rtcu lo s que v e n
den, pero e xiste n a lg u n os em pleados que obtienen sa la rio ms c o
m is i n ; es d e c ir, o b tie n e n un s a la rio fijo , sin im p o rta r el tip o o
ca ntidad de a rtcu lo s que venden, ms una com isin sobre cie rto s
a rtcu lo s. La tie n d a Sw eli tiene d ive rsa s lneas de m ercanca, a l
g u n a s de la s c u a le s se c la s ific a n co m o a rtc u lo s e s t n d a r (p o r
ejem plo, una lata de sopa de tom ate) porque son de uso com n y
no requieren de t cn ica s crea tiva s de venta; adem s, hay artcu io s
e x tra que son a lta m e n te re m u n e ra tiv o s p e ro d ifc ile s de v e n d e r
(com o un C a d illa c de ch a p a de oro, in cru sta d o con d ia m a n te s).
Los a rtcu io s e stndar y los extra g e n eralm ente representan los l
m ites in fe rio r y su p e rio r dei espectro de precios, con un m ayor n
m ero de a rtcu lo s enm edio.
www.FreeLibros.org
Los com pradores tam bin se clasifican. A lgunos se conocen com o

regulares, pues hacen tran sa ccio n e s tan a m enudo que no se re
q u ie re h a c e rle s ve n a c re a tiv a . Sin e m b a rg o , la m a yo ra de los
olientes hace pocas tran sa ccio n e s en la tie n d a Sweli, y es probable
que entren, com pren algo y no vuelvan a ser vistos.
La poltica de com isiones de a g e rencia es la siguiente: si un em
pleado no a sa la ria d o vende un a rtculo que no es e stndar ni extra
a una persona que no sea com pradora regular, recibe un 10% de
com isin, a m enos que el a rtculo cueste m s de $10,000, en cuyo
caso la com isin es del 5 por ciento. Para to d os los vendedores, si
se vende un a rtcu lo estndar, o si se le vende algo a un cliente re
gular, no se da com isin alguna. Si un ve n d ed o r a sa la ria d o vende
un artculo extra, recibe una com isin del 5%, a m enos de que el ar
tculo se venda a m s de $1,000, en cuyo caso recibe una com isin
neta de $25. Si un vendedor no asalariado vende un a rtculo extra
a alguien que no sea un co m p ra d o r regular, recibe un 10% de com i
sin, a m enos de que el a rtculo cueste m s de $1,000, en cuyo ca
so recibe una com isin neta de $75".
www.FreeLibros.org
1]
/AlfiBi/S
TiDAD-lRELAOl
O bviam ente, el ju icio de un hom bre no puede su perar la inform acin
en la que l lo bas. D sele la verdad y aun as pudiera e rra r te n ie n
do la oportu n id a d de acertar; pero no le den noticias, o dnsele slo
datos incom pletos y d istorsionados, m ostrados de m anera ignorante,
descuidada o prejuiciosa, con propaganda y falsedades, y se d e stru i
rn to d os sus procesos de razonam iento, y l se co n ve rtir en algo
m enos que un hom bre.
A rth u r Hays S ulzberger
D iscurso, A so cia ci n de E ditores d e i E stado de Nueva York, 1948

1. Por qu son tiles los modelos de datos en el
anlisis de sistemas.
2. Los componentes de un diagrama de
entidad-relacin.
3. Cmo escribir un diagrama de entidad-relacin.
4. Cmo retinar un diagrama inicial de
entidad-relacin.
E n este captulo se explora una notacin grfica para modelar datos. El dia
grama de entidad-relacin (tambin conocido como DER, o diagrama E-R) es un mo
delo de red que describe con un alto nivel de abstraccin la distribucin de datos
almacenados en un sistema. Es muy diferente del DFD, que modela las funciones
que lleva a cabo un sistema; y es diferente del diagrama de transicin de estados,
que modela el comportamiento dependiente del tiempo de un sistema.
www.FreeLibros.org
260
DIAGRAMAS DE ENTIDAD-RELACION 261
Por qu podramos estar interesados en modelar los datos de un sistema?

Primariamente, porque las estructuras de datos y las relaciones pueden ser tan com
plejas que se deseara enfatizarlas y examinarlas independientemente del proceso
qUe se llevar a cabo. De hecho, esto se da sobre todo si mostramos el modelo del
sistema a los usuarios ejecutivos de mayor nivel de una organizacin (por ejemplo el
vcepresdente o los gerentes de departamento, quienes podran no estar interesa
dos en los detalles funcionales cotidianos del sistema). Tales usuarios a menudo se
preocupan ms por los datos: qu datos requerimos para manejar nuestro negocio?
Quin los tiene? Quin tiene acceso a ellos?
Algunas de estas preguntas, por ejemplo, ia tenencia o acceso a los datos, pu
dieran ser responsabilidad de un grupo dedicado dentro de la organizacin. A me
nudo, el grupo de administracin de datos (grupo AD) es responsable de administrar
y controlar la informacin esencial de un negocio; cuando se comience a construir un
nuevo sistema de informacin se requerir hablar con estas personas para poder co
ordinar la informacin del sistema con el modelo global, corporativo, de informacin.
El diagrama de entidad-relacin es una herramienta tii para llevar a cabo esta con
versacin.
A menudo existe otro grupo dentro de la administracin con un nombre similar:
el grupo de administracin de bases de datos (a veces conocido como grupo de
ABD). Se suele localizar dentro del departamento de proceso de datos (mientras
que ei de administracin de datos no necesariamente est ah), y su labor es asegu
rar que las bases de datos computarizadas se organicen, administren y controlen de
manera eficiente. As que suele ser el equipo de implantacin responsable de tomar
el modelo esencial (independiente de alguna tecnologa especfica) y traducirlo a un
diseo de base de datos eficaz para IMS, ADABAS, IDMS, TOTAL o algn otro siste
ma de base de datos. El diagrama de entidad-relacin es una herramienta efectiva
de modelado para comunicarse con el grupo de administracin de bases de datos.
Basndose en la informacin presentada por el DER, el grupo de administracin de
base de datos puede ver el tipo de claves o ndices o apuntadores que se necesita
rn pera llegar de manera eficiente a los registros de las bases de datos.
Para el analista, ei DER representa un gran beneficio tambin: enfatiza las re
laciones entre almacenes de datos en el DFD que de otra forma se hubieran visto
slo en la especificacin de proceso. Por ejemplo, un DER tpico se muestra en la
figura 12.1. Cada una de las cajas rectangulares corresponde a un almacn de da
tos en un DFD (correspondencia que se explorar ms a fondo en el Captulo 14), y
puede verse que hay relaciones (conexiones) que normalmente no se aprecian en un
DFD. Esto se debe a que el DFD enfoca la atencin del lector a las funciones que el
sistema efecta, no a los datos que ocupa.
Considere un caso extremo: Qu tal si no se estn realizando funciones?
Qu tal si el propsito del sistema que est construyendo no es hacer algo, sino
meramente ser ei recipiente de una gran cantidad de informacin interesante? Tal
www.FreeLibros.org
262
DIAGRAMAS DE ENTIDAD-RELACION
sistema pudiera llamarse sistema de consultas ad hoc, o sistema de apoyo a decj.

siones. En tal tipo de sistema, pudiramos concentrarnos por completo en el modelo
de datos, y ni siquiera preocuparnos por construir el modelo de DFD, que est orien
tado a las funciones. Desde luego, esto es claramente una situacin rara: la mayo,
ra de los sistemas s efectan funciones; a menudo, encontramos que construir
primeramente el modelo de datos hace ms fcil descubrir cules son las funciones
requeridas.
Desde luego, la notacin del DER de la figura 12.1 es bastante misteriosa has
ta el momento. En las siguientes secciones se exam inar la estructura y |0s
componentes de un DER para luego discutir las reglas para dibujar un DER bien es
tructurado. La notacin que se presenta en este captulo se deriva de [Flavin, 1981]
y es similar a la que desarrollaron [Chen, 1976], [Martin, 1982], [Date, 1986] y otros.
Figura 12.1: Diagrama de entidad-relacin tpico

12.1
LOS COMPONENTES DE UN DER

Hay cuatro componentes principales en un diagrama de entidad-relacin:
1. Tipos de objetos
2.
Relaciones
3.
Indicadores asociativos de tipo de objeto
4.
Indicadores de supertipo/subtipo
www.FreeLibros.org
12.1.1
Tipos de objetos
Ei tipo de objeto se representa en un diagrama de entidad-relacin por medio

de una caja rectangular; en la figura 12.2 se muestra un ejemplo. Representa una
le cci n
o conjunto de objetos (cosas) del mundo real cuyos miembros individuales

tienen las siguientes caractersticas:
c inSta n c a s )
(0
Cada una puede identificarse de manera nica por algn medio. Existe
alguna forma de diferenciar entre instancias individuales del tipo de obje
to. Por ejemplo, si se tiene un tipo de objeto conocido como CLIENTE,
debemos ser capaces de distinguir uno de otro (tai vez por un nmero de
cuenta, por su apellido, o por su nmero de Seguro Social). Si todos los
clientes son iguales (si hay un negocio en el que son slo entes sin cara y
sin nombre que entran a a tienda a comprar cosas), entonces CLIENTE
no sera un tipo de objeto con significado.
C LIEN TE
Figura 12.2: Un tip o
de
objeto
Cada uno juega un papel necesario en el sistema que se construye. Es

decir, para que ei tipo de objeto sea legtimo, debe poder decirse que el
sistema no puede operar sin tener acceso a esos miembros. Si se est
construyendo un sistema de ingreso de pedidos para la tienda, por ejem
plo, se pudiera pensar que, adems de los clientes, la tienda tiene mozos,
cada uno de los cuales se identifica de manera individual por su nombre.
A pesar de que los mozos juegan un papel til en la tienda, el sistema de
ingreso de pedidos puede funcionar felizmente sin ellos; por tanto, no me
recen un papel como tipos de objeto en ei modelo dei sistema. Obvia
mente, esto es algo que debe verificarse con los usuarios ai construir el
modelo.
Cada uno puede describirse por uno o ms datos. Es decir, un CLIENTE

puede describirse por medio de datos tales como nombre, domicilio, lmite
de crdito y nmero teiefnico. Muchos textos sobre bases de datos des
criben esto como asignar datos a un tipo de objeto. Ntese que los atri
butos deben aplicarse a cada instancia del tipo de objeto; por ejemplo,
cada cliente debe tener nombre, domicilio, lmite de crdito, nmero tele
fnico, etc.
En muchos de los sistemas que desarrolle, los tipos de objetos sern la repre
sentacin en el sistema de algo material del mundo real. Esto significa que los clien
tes, artculos de inventario, empleados, partes manufacturadas, etc, son objetos
www.FreeLibros.org
264
tpicos. Ei objeto es el algo material del mundo real, y el tipo de objeto es su rep.
sentacin en el sistema. Sin embargo, un objeto tambin pudiera ser algo no me
rial: por ejemplo, horarios, planes, estndares, estrategias y mapas.
Dado que a menudo las personas son tipos de objetos en un sistema, debe
nerse otra cosa en mente: una persona (o para el caso, cualquier cosa material)
diera ser diversos tipos de objetos distintos en distintos modelos de datos, o incl
en un mismo modelo. Juan Prez, por ejemplo, puede ser EMPLEADO en un mo-,
lo de datos y CLIENTE en otro. Tambin pudiera ser EMPLEADO y CLIENTE dentrdel mismo modelo.
Ntese que en todos los ejemplos de un objeto se ha usado un sustantivo g
guiar (por ejemplo, empleado, cliente). Esto no es necesario, pero es un convetil; como veremos en el Captulo 14, existe una correspondencia entre objetos er
DER y almacenes en el DFD; as, si existe un objeto CLIENTE en el DER, debe 1
ber un almacn de CLIENTES en el DFD.
12.1.2
Relaciones
Los objetos se conectan entre s mediante relaciones. Una relacin represar

ta un conjunto de conexiones entre objetos, y se representa por medio de un rombo
La figura 12.3 muestra una relacin sencilla que pudiera existir entre dos o ms ot>
jetos.
Figura 12.3: Una relacin

Es importante reconocer que la relacin representa un conjunto de conexio
nes. Cada instancia de la relacin representa una asociacin entre cero o ms ocu
rrencias de un objeto y cero o ms ocurrencias del otro. As, en la figura 12.3, la
relacin etiquetada como COMPRAS puede contener las siguientes instancias indivi
duales:
instancia 1:
el cliente 1 compra el artculo 1
Instancia 2:
ei cliente 2 compra ios artculos 2 y 3
www.FreeLibros.org
instancia 3:
el cliente 3 compra el artculo 4
instancia 4:
ei cliente 4 compra ios artculos 5, 6 y 7
instancia 5:
el cliente 5 no compra ningn artculo
instancia 6:
los clientes 6 y 7 compran el artculo 8
instancia 7:
los clientes 8, 9 y 10 compran los artculos 9, 10 y 11
etc.
Como puede verse, entonces, una relacin puede conectar dos o ms Instancias del
mismo objeto.
Ntese que la relacin representa algo que debe ser recordado por el sistema:
algo que no pudo haberse calculado ni derivado mecnicamente. As, el modelo de
datos de la figura 12.3 indica que existe alguna razn relacionada con el usuario pa
ra recordar ei hecho de que el cliente 1 compra el artculo 1, etc. Y la relacin tam
bin indica que no existe nada a priori que hubiera permitido determinar que el
cliente 1 compr el artculo 1 y nada ms. La relacin representa la memoria del sis
tema.1 (Un objeto representa la memoria del sistema tambin, desde luego.)
Ntese tambin que puede existir ms de una relacin entre dos objetos. La
figura 12.4, por ejemplo, muestra dos relaciones distintas entre un PACIENTE y un
MEDICO. A primera vista, pudiera pensarse que esto es rebuscar lo obvio: cada vez
que el mdico trata a un paciente, le cobra mediante un recibo. Pero la figura 12.4
sugiere que la situacin puede ser distinta; pudiera resultar, por ejemplo, que existan
diversas instancias de tratamiento entre un mdico y el mismo paciente (es decir,
un tratamiento inicial, tratamientos de seguimiento, etc.). La figura 12.4 implica que
la relacin de recibos est completamente separada de la relacin de tratamiento: tal
vez a algunos pacientes se les dan recibos slo por su primer tratamiento, mientras
que a otros se les dan para cada tratamiento y a otros jams se les dan.
Una situacin ms comn es ver mltiples relaciones entre mltiples objetos.
La figura 12.5 muestra la relacin que existe tpicamente entre un cliente, un vende
dor, un agente de bienes races, el abogado del cliente y el abogado del vendedor,
para la compra-venta de una casa.
Con un diagrama complejo como el de la figura 12.5 (que es tpico, y tal vez
ms simple que ios DER que es probable encontrar en un proyecto real), la relacin
y sus tipos de objetos deben leerse como una unidad. La relacin se puede descri
bir desde ia perspectiva de cualquiera de los tipos de objetos participantes, y todas
1 Entre los objetos, pueden e x is tir otras relaciones que no aparezcan en el DER. Dado que el DER
es un m odelo de datos alm acenados, no se m uestran las relacion e s que se pueden ca lcu la r o deri
var. Por ejem plo, considere ei o bjeto CONDUCTOR y el o b je to LICENCIA. Puede e xistir entre los
dos una relacin de fecha de renovacin que se ha ca lcu la d o con base en la fe ch a de nacim iento
del conductor (por ejem plo, un co n d ucto r debe renovar su licencia cada ao en su cum pleaos).
Tal relacin no se m ostrara en el DER pues no es una relacin de datos alm acenados. Sin em bargo, si la fecha de renovacin se escogiera al azar, p ro b ablem ente te n dra que ser recordada por ei
sistema.
www.FreeLibros.org
266
Figura 12.4: Relaciones m ltiples entre objetos

esas perspectivas son vlidas. De hecho, el conjunto de todos estos puntos de vista
es el que describe completamente la relacin. Por ejemplo, en la figura 12.5 puede
verse la relacin de negociacin de precios en cualquiera de las siguientes tres for
mas:
1.
El agente de bienes races negocia ei precio entre el cliente y el vende

dor.
2.
El cliente negocia ei precio con ei vendedor, mediante el agente de bie

nes races.
3.
Ei vendedor negocia el precio con ei cliente, mediante el agente de bie

nes races.
Ntese que, en algunos casos, puede haber relaciones entre diferentes instan
cias de un mismo tipo de objeto. Por ejemplo, imagine un sistema que se est desa
rrollando para una universidad, en el cual CURSO, ESTUDIANTE y PROFESOR son
tipos de objetos. La mayora de las relaciones de inters sern entre instancias de
diferentes tipos de objetos (por ejemplo, las relaciones se inscribe en, imparte*,
etc.). Sin embargo, pudiera requerirse modelar la relacin es prerrequisito para'
entre una instancia de CURSO y otra.
www.FreeLibros.org
Figura 12.5: Relaciones m ltip le s entre m ltiples objetos
12.1.3
Notacin alternativa para relaciones
Como se vio en la Seccin 12.1.2, las relaciones en el diagrama E-R son multidireccionaies; pueden leerse siguiendo cualquier direccin. Adems, vimos que los
diagramas E-R no muestran cardinalidad; es decir, no muestran el nmero de obje
tos que participan en la relacin. Esto es consciente y deliberado: se prefiere dejar
tales detalles en el diccionario de datos. Esto se discutir ms a fondo en la Sec
cin 12.3.
Una notacin alternativa utilizada por algunos analistas muestra tanto la cardinadad como la ordinalidad. Por ejemplo, la figura 12.6(a) muestra una relacin en
tre CLIENTE y ARTICULO en la cual la notacin adicional indica que:
(1)
El CLIENTE es el punto de ancla, es decir, el objeto primario desde cuyo

punto de vista debe leerse la relacin.2
(2)
La relacin consiste en un cliente conectado con N artculos. Es decir, un

cliente individual puede adquirir 0, 1, 2, ... o N artculos. Sin embargo, la
relacin indica que slo puede haber un cliente involucrado en cada ins
tancia de la relacin. Esto excluye, por ejemplo, la posibilidad de que ml
tiples clientes estuvieran involucrados en la compra de un solo artculo
www.FreeLibros.org
2 El trmino punto de ancla se introdujo en [Flavin, 1981],
268
Figura 12.6(a): Notacin de punto ancla para diagram as E-R

Otra notacin comn aparece en la figura 12.6(b), en donde la flecha de dos
puntas seguidas muestra la relacin de uno a muchos, mientras que se emplea una
flecha sencilla para mostrar relaciones de uno a uno entre objetos.
Figura 12.6(b): N otacin alternativa para relaciones de uno a m uchos

Tales diagramas de E-R anotados se discuten con detalle en [Chen, 1976], j
[Martin, 1982], y [Date, 1988]. Sin embargo, prefiero no agregar tales detalles, por- |
que se pueden incluir fcilmente en el diccionario de datos (como se discutir en la f
Seccin 12.4), y porque tienden a distraer la atencin del propsito principal del dia
grama E-R, que es dar una visin global de los componentes e interfaces entre da
tos en un sistema. Aunque no hay nada intrnsecamente malo en tener anotaciones
de tipo procedimiento en el diagrama, mi experiencia indica que los analistas a me
nudo llevan ms all una buena idea y atiborran el diagrama con demasiada informa
cin.
12.1.4
Indicadores a socia tivos de tip o de objeto
Una notacin especial en el diagrama de E-R es el indicador asociativo de tipo

de objeto; representa algo que funciona como objeto y como relacin. Otra manera
de ver esto es considerar que el tipo asociativo de objeto representa una relacin
acerca de ia cual se desea mantener alguna informacin.3
Considere, por ejemplo, el caso sencillo de un cliente que adquiere un art
culo (o artculos), que ilustra la figura 12.6. Sin tener en cuenta si se incluye o no
la anotacin de tipo procedimiento, el punto principal es que la relacin de COM
PRA no hace ms que asociar un CLIENTE con uno o ms ARTICULOS. Pero su
ponga que existen datos que deseamos recordar acerca de cada instancia de una
compra (por ejemplo, a qu hora del da se hizo). Dnde se podra almacenar di
cha informacin? Hora del da definitivamente no es un atributo de CLIENTE, r
de ARTICULO. Ms bien, se asocia hora del da con la compra misma, y esto
se muestra en un diagrama como el que ilustra la figura 12.7.
www.FreeLibros.org
3 En diversos libros de bases de datos e sto se conoce com o datos de interseccin.
Figura 12.7: Indicador asocia tivo de tip o de objeto
Ntese que COMPRA ahora se escribe dentro de una caja rectangular conectada, por medio de lneas dirigidas, a un rombo de relacin sin nombre. Esto preten
de indicar que COMPRA funciona como;
Un tipo de objeto, algo acerca de lo cual se desea almacenar informacin.

En este caso, se desea recordar la hora en la cual se realiz la compra y
el descuento que se dio al cliente. (Nuevamente, esto supone que tal in
formacin no la puede derivar, despus del hecho, el sistema).
Una relacin que conecta los dos tipos de objeto CLIENTE y ARTICULO.
Lo significativo aqu es que CLIENTE y ARTICULO se mantienen solos.
Existiran con o sin la compra.4
Una COMPRA, por otro lado, obviamente depende para su misma existencia
del CLIENTE y del ARTICULO. Aparece slo como resultado de una relacin entre
los otros objetos con los cuales est conectada.
La relacin de la figura 12.7 no tiene nombre a propsito. Esto se debe a que
el indicador asociativo de objeto (COMPRA) tambin es el nombre de la relacin.
12.1.5
Indicadores de su b tip o/su pe rtip o
Los tipos de objeto de subtipo/supertipo consisten en tipos de objeto de una o

ms subcategoras, conectados por una relacin. La figura 12.8 muestra un subti
po/supertipo tpico: la categora general es EMPLEADO y las subcategoras son EM
PLEADO ASALARIADO y EMPLEADO POR HORAS. Ntese que los subtipos se
conectan ai supertipo por medio de una relacin sin nombre; note tambin que el supertipo se conecta a la relacin con una lnea que contiene una barra.
4 Un purista pudiera argum entar que esto no se cum ple a la larga. Si no h u biera ARTICULOS du
rante varios das seguidos, los COMPRADORES d esapareceran de la escena y com p ra ra n en otra
parte. Y s no hubiera COMPRADORES, la tienda te n dra que ce rra r y ios ARTICULOS de sa pa re
ceran. Pero en la situacin de estado estable a corto plazo, es obvio que com pradores y artculos
pueden c o e xistir felizm ente sin te n e r algo que ve r n e cesariam ente unos con otros.
www.FreeLibros.org
270
Figura 12.8: Indicador de s u b tipo/su pertipo

En esta notacin el supertipo se describe por datos que se aplican a todos los
subtipos. Por ejemplo, en la figura 12.8, se podra imaginar que todos los emplea
dos se describen por hechos tales como:
Nombre
Aos de servicio
Domicilio particular
Nombre del supervisor
Sin embargo, cada subtipo se describe por medio de datos diferentes; de otro
modo, no tendra caso hacer distincin entre ellos. Por ejemplo, se podra imaginar
que un EMPLEADO ASALARIADO se describe por cosas tales como:
Salario mensual
Porcentaje anual adicional
Aportacin para coche de la empresa
Y el EMPLEADO POR HORAS por medio de cosas como:
Paga por hora
Cantidad por tiempo extra
Hora de comienzo
www.FreeLibros.org
12 2
REGLAS PARA LA CONSTRUCCION DE DIAGRAMAS DE ENTIDADRELACION
La notacin que se muestra en la seccin anterior es suficiente para construir

diagramas E-R arbitrariamente complejos. Sin embargo, podra estar pensando en
eSte momento: Cmo descubrir qu son, para comenzar, los objetos y las relaciones?. El modelo inicial de objetos y relaciones usualmente se derivar de 1) su
com p ren sin de la aplicacin del usuario, 2) entrevistas con el usuario y 3) cualquier
otro tipo de investigacin y recoleccin de informacin que pueda usar. (En el Apndice E se discuten tcnicas de entrevista y de recoleccin de datos.)
No espere que el primer diagrama E-R que haga sea el final, que revisar con
la comunidad usuaria o que entregar a los diseadores del sistema. Como los dia
gramas de flujo de datos y todas las dems herramientas de modelado, los diagra
mas E-R deben revisarse y mejorarse muchas veces; la primera versin tpicamente
no ser ms que un borrador, y las versiones subsecuentes se producirn utilizando
una serie de reglas de refinamiento que se presentan en esta seccin. Algunas de
as reglas de refinamiento llevan a la creacin de tipos adicionales de objeto, mien
tras que otras llevarn a la eliminacin de objetos y/o relaciones.
12,2.1
A adir tip o s de objetos adicionales
Como se indic anteriormente, el primer DER tpicamente se crear a partir de

entrevistas iniciales con el usuario, y de su conocimiento de la materia en cuanto ai
negocio del usuario. Esto, desde luego, le dar una buena pista respecto a la identi
dad de los principales objetos y relaciones.5
Despus de haber desarrollado el primer DER, el siguiente paso es asignar ios
datos del sistema a los diversos tipos de objetos. Se supone, desde luego, que sabe
cules son los datos. Esto puede suceder en cualquiera de tres maneras:
1.
Si el modelo del proceso (el DFD) ya se ha desarrollado o se est desa

rrollando paralelamente al modelo de datos, entonces el diccionario de
datos ya existir. Pudiera no estar completo an, pero lo que haya ser
suficiente para comenzar el proceso de asignacin.
5 Sin em bargo, probablem ente no identificar todas las relaciones entre objetos. Dado un sistem a
con N objetos, el nm ero de relaciones posibles es pro p o rcio n al a N!, !o cu a l tp ica m e n te es un n
mero enorme. M uchas de las relaciones (tericam ente) posibles resultarn en 1) no te n e r un signi
ficado legtim o dentro del sistem a, o 2) no te n er relevancia den tro del co n texto en el que se est
modelando. Se puede uno im aginar, por ejem plo, un sistem a en donde ia relacin prim aria entre
compradores y vendedores es VENDER. Pudiera tam bin resultar que co m p ra d o r y ve n d ed o ra es
tn casados el uno con la otra; o que la vendedora sea hija del com prador; o que el co m p ra d o r y el
vendedor sean co ndiscpulos en la escuela. T odo e sto p u diera se r muy interesante, pero no se va
a representar en el m odelo a m enos que le sea relevante.
www.FreeLibros.org
272
2.
Si el modelo del proceso no se ha desarrollado (o, en ei caso extremo, ^

no tiene intencin de desarrollar uno), entonces pudiera tener que empg. I
zar por entrevistar a todos los usuarios apropiados para construir una !sta
exhaustiva de datos (y sus definiciones). Ai hacer esto, puede asignarlos 1
datos a los objetos en el diagrama de E-R. (Sin embargo, note que este 1
es un proceso ascendente que consume tiempo, y que pudiera ocasionar I
retrasos y frustracin.)
3.
Si est trabajando con un grupo activo de administracin de datos, hay I

una buena probabilidad de que ya exista un diccionario de datos, que po,;
dra obtenerse pronto durante el proyecto, de manera que en ese momen
to ya pudiera comenzar el proceso de asignacin.
El proceso de asignacin puede ofrecer una de tres razones para crear nuevos
tipos de objetos:
1. Es posible descubrir datos que se pueden asignar a algunas instancias de
un tipo de objeto pero no a otras.
2.
Pudieran descubrirse datos aplicables a todas las instancias de dos obje

tos distintos.
3.
Podra descubrirse que algunos datos describen relaciones entre otros ti

pos de objetos.
Si durante
nos datos no se
necesitar crear
do trabajando, y
el proceso de asignar datos a tipos de objetos encuentra que algu

pueden aplicar a todas las instancias de algn tipo de objeto dado,
un conjunto de subtipos abajo del tipo de objeto con el que ha esta
asignar los datos especficos a los subtipos apropiados.
Suponga que, por ejemplo, se est desarrollando un sistema de personal, y se

ha identificado (con gran perspicacia y creatividad) un tipo de objeto llamado EM
PLEADO. Al revisar los datos disponibles se encuentra que muchos de ellos (edad,
estatura, fecha de contratacin , etc.) se aplican a todas las instancias de un em
pleado. Sin embargo, luego se descubre un dato llamado nmero-de-embarazos;
se trata obviamente de un dato relevante para las empleadas, pero no para los em
pleados varones. Esto llevara a crear EMPLEADOS-VARONES y EMPLEADAS co
rno subtipos de la categora general de empleado.
Obviamente, no estoy sugiriendo que todos os sistemas de personal deban
hacer seguimiento del nmero de embarazos que cada empleada ha tenido; el ejem
plo se escogi meramente porque existe un consenso general de que ios empleados
varones no se pueden embarazar. Compare esto, sin embargo, con ei dato nombredel-cnyuge: hay varias instancias de EMPLEADO para quienes no se aplicara es-
www.FreeLibros.org
*o (porque son solteros), pero es una situacin muy distinta a la de un dato que no
% puede aplicar definitivamente.6
En la mayora de los casos el proceso de crear nuevos subtipos y asignarles
datos de manera apropiada es bastante directo. Sin embargo, debe tenerse siempre
en mente una situacin excepcional: pudiera suceder que todos ios datos relevantes
se atribuyan a uno de los subtipos, y que ninguno de los datos se pueda asignar al
objeto supertipo; es decir, puede suceder que los datos sean mutuamente excluyentes. perteneciendo a un subtipo o a otro pero no a ambos. Suponga, por ejemplo,
aue ios nicos datos que se puede asignar a os empleados son nmero-de-embacazos y aos-de-experiencia-jugando-con-el-equipo-K nicks-de-basquetbol. Po
dra decidirse (tras preguntarnos a qu luntico usuario pudiera habrsele ocurrido
tal sistema) que el supertipo general EMPLEADO no se aplica.
Tambin puede ocurrir la situacin inversa: los datos pueden describir instancas de dos (o ms) tipos distintos de objetos de la misma manera. Si esto ocurre,
debe crearse un supertipo nuevo y asignarle los datos comunes al supertipo. Por
ejemplo, tal vez se identific CLIENTE-DE-CONTADO y CLIENTE-A-CREDITO co
mo dos tipos de objetos distintos cuando se cre ei DER para un sistema de pedidos
(tal vez porque el usuario seal que eran dos categoras distintas). Sin embargo,
pronto se hace evidente que los datos nom bre-del-cliente y d o m icilio -d e l-ciie n te
describen ambos tipos de cliente de la misma forma, lo cual apoyara la creacin de
un supertipo, como muestra la figura 12 .9.
CUENTE A
CREDITO
C L IE N T E DE
CONTADO
Figura 12.9: Creacin de un nuevo objeto su b tip o /su p e rtip o
S A o largo de io d o el e je m p lo obviam ente ignoram os una serie de exce p cio ne s obscuras. Ignora
ros, por ejem plo, el caso de la em pleada que tuvo tre s em barazos y luego se hizo una operacin
le cambio de sexo. Para el caso de los nom bres de los cnyuges suponem os que ninguno de los
empleados es un nio, porque se supone que les sera im posible estar casados.
www.FreeLibros.org
274
Similarmente, si un dato describe la interaccin de dos o ms tipos de al

tos, entonces debera reemplazarse la relacin desnuda entre los dos objetos c
un tipo asociativo de objeto. Por ejemplo, en el primer borrador de DER, que muestra en la figura 12.10(a), existe una relacin de COMPRA entre CLIENTE
ARTICULO. Durante la asignacin de datos pudiera encontrarse con que hay
dato llamado fecha-de-compra que 1) parece pertenecer a la relacin COMPRA v
obviamente describe, o proporciona datos acerca de, la interaccin de un CLIEK
con un ARTICULO. Esto sugiere que debe sustituirse la relacin COMPRA por
tipo asociativo de objeto, como muestra la figura 12.10(b)
Figura 12.10 (a): Diagrama E-R inicial
Figura 12.10 (b): Reemplazo de una relacin por un tip o asociativo de objete
A veces el diagrama E-R inicial tendr un tipo de objeto que, visto de cerca I
claramente amerita ser un tipo asociativo de objeto. Por ejemplo, la figura 12.11
muestra un diagrama E-R con tres objetos relacionados: CLIENTE, PEDIDO y PRO
DUCTO. Durante el proceso de asignar datos a los diversos objetos, se encuentra
que fecha-de-entrega en realidad se aplica al objeto PEDIDO porque a ios clientes
no se les entrega en ningn lado, y los productos se entregan slo como resultada
de un pedido. De hecho, esto hace evidente que PEDIDO en s es una relacin en
tre CLIENTE y PRODUCTO, adems de un objeto acerca del cual interesa recordar
algunos hechos. Esto lleva a la figura 12.11 (b).
Finalmente, tenemos ei caso de grupos que se repiten. Considere, por ejem-j
po, el tipo de objeto EMPLEADO, con los datos obvios como nombre y domicilio.
Suponga que hay datos adicionales como mombre-del-hijo, edad-del-hijo y sexodel-hijo. Podra argumentarse obviamente que son formas de describir un objete j
nuevo llamado HIJO, que inadvertidamente se haba incluido anteriormente en EM-j
PLEADO. Podra tambin argumentarse que existen (potencialmente) mltiples ins-
www.FreeLibros.org
cas de informacin relacionadas con hijos en cada instancia de un empleado, y

e cada instancia de informacin relacionada con los hijos se define de manera niga por el nom bre-del-hijo. En este caso, el tipo de objeto que inicalmente se imaajn de ia forma que muestra ia figura 12.12(a) debe transformarse en dos objetos
tipo, conectados por una nueva relacin, como se muestra en la figura 12.12(b).
Figura 12.11 (a): DER in icia l
EMPLEADO
HIJO
www.FreeLibros.org
Figura 12.12(a): Vista inicial de un
o b je to
276
Este proceso de eliminar objetos incluidos en otros es parte de una actividg

de refinamiento ms general llamada normalizacin. El objetivo de la n o rm aliza^
es producir tipos de objetos, en los que cada instancia (o miembro) consiste en yr.
valor llave primario que identifica a alguna entidad, junto con un conjunto de valore
de atributo independientes que describen a la entidad de alguna manera. El proceso
de normalizacin se describe con detalle en el Captulo 14 de [Date, 1986] y en si
captulo 19 de [DeMarco, 1978].
Figura 12.12(b): Diagrama E-R revisado

12.2.2
E lim inar tip o s de objetos
La seccin anterior trat los refinamientos del DER que crean objetos y/o rela
ciones adicionales. Sin embargo, existe un buen nmero de situaciones en las que
los refinamientos del DER llevan a la eliminacin de tipos de objetos y relaciones re
dundantes o errneos. Examinaremos cuatro situaciones comunes:
1.
Tipos de objetos que consisten slo en un identificador
2.
Tipos de objeto para los cuales existe una sola instancia
3.
Tipos asociativos de objetos flotantes
4.
Relaciones derivadas
www.FreeLibros.org
Si se tiene un diagrama E-R en ei cual uno de los tipos de objeto tiene slo un
asignado como dato, existe la oportunidad de eliminar ei tipo de objeto
y asignar el identiicador, como dato, a un tipo de objeto relacionado. Por ejemplo,,
imagine que se construy un DER como muestra la figura 12.13(a) para un sistema
je personal:
je n tific s d o r
Figura 12.13(a): Diagrama E-R inicial
Durante el proceso de asignar datos a los diversos objetos, sin embargo, po

dra encontrarse que la nica informacin que el sistema mantiene acerca del cnyu
ge es su nombre (es decir, el identificador que distingue a uno de cualquier otro en
el sistema). En este caso, un refinamiento obvio sera eliminar CONYUGE como tipo
de objeto e incluir nom bre-del-cnyuge como dato dentro del objeto EMPLEADO.
Observe que este refinamiento slo tiene sentido si existe una corresponden
cia uno a uno entre instancias del objeto que est a punto de ser eliminado e instan
cias del objeto relacionado. El ejemplo anterior tiene sentido porque la sociedad
moderna supone que una persona tendr cuando ms un cnyuge. Esto lleva al diagrarrta E-R reducido que se muestra en la figura 12.13(b).
www.FreeLibros.org
278
EMPLEADO
Figura 12.13(b): Diagrama E-R reducido

Se puede hacer una reduccin an mayor si encontramos que el diagrama E-R
inicial contiene un objeto para ei cual el nico hecho es el identificador, y se es un
objeto de una sola instancia. Considere ei diagrama E-R inicial que se muestra en a
figura 12.14(a).

A primera vista parece ser una manera razonable de mostrar la relacin entie pa
cientes y drogas (medicinales, claro) en un hospital. Pero suponga que la nica in
formacin que se guarda acerca del medicamento es su nombre (identificador); y
suponga que el hospital slo administra un tipo de medicamento (por ejemplo, aspiri
na). En este caso, el medicamento es una constante y ni siquiera tiene que mostrar
www.FreeLibros.org
se en ei diagrama. (Note que esto tambin significa que el sistema no tendra un al

macn de datos llamado medicamentos.) El diagrama reducido se vera como la f i
gura 1 2 .1 4(b)
PACIENTE

Debido a la situacin anterior, es posible crear un tipo asociativo de objeto flo
tante. Considere la siguiente variante del ejemplo del hospital anterior, que muestra
la figura 12.15(a). Si, como se sugiri anteriormente, resulta que MEDICAMENTO
es un objeto de instancia nica, slo con identificador, entonces se eliminara. Esto
resultara en el diagrama reducido de la figura 12.15(b); ntese que TRATAMIENTO
todava es un tipo de objeto asociativo, aunque se conecte slo con un tipo de obje
to. Esto se conoce como tipo de objeto asociativo flotante y es legal (aunque poco
usual) en un DER.
www.FreeLibros.org
Finalmente, las relaciones que se pueden derivar, o calcular, deben eliminarse
del diagrama E-R inicial. Como se mencion anteriormente en este captulo, el DER
debe mostrar los requerimientos para los datos alm acenados. Por ello, en la figura
280
12.16(a), si la relacin renovar entre CONDUCTOR y LICENCIA se puede deriva

(basndose en el cumpleaos del conductor, o en la primera letra de su apellido, e
en algn otro esquema usado en la oficina de trnsito), entonces debe eliminarse
Esto lleva a la figura 12,16(0), en la cual los tipos de objeto no estn conectados I
Esto es legal en un DER; no es necesario que todos los tipos de objetos estn cr I
nectados entre s.
f
TRATAMIENTO
Figura 12.16(a): DER inicial
CO ND UC TO R
LICENCIA
www.FreeLibros.org
Figura 12.16(b): DER reducido
12 3
e x t e n s io n e s a l d ic c io n a r io d e d a t o s p a r a d ia g r a m a s e - r
Finalmente, observamos que el diccionario de datos que se discuti en el captulo 10 necesita extenderse para tomar en cuenta la notacin de DER discutida en
gste captulo. En general, los objetos del DER corresponden con almacenes del
|o cual se analizar ms a fondo en el captulo 14. Esto significa que en la de
finicin sacada del diccionario de datos que se da a continuacin, CLIENTE es tanto
definicin del tipo de objeto como instancia del almacn CLIENTES.
CLIENTES = {CLIENTE}
CLIENTE
= @ nom bre-del-cliente + d o m ic ilio + nm ero- te lefnico
Ntese tambin que la definicin de un CLIENTE incluye la especificacin de!

es el dato (o atributo) q u e diferencia una instancia de un cliente de
signo de arriba (@) se utiliza para indicar el o los campos llave.7
campo llave, que

cualquier otra. El
Sin embargo, tambin hay que incluir en el diccionario de datos una defini
cin de todas las relaciones que se muestran en el DER. La definicin de relacin
debe incluir una descripcin de su significado en ei contexto de ia aplicacin; y de
be indicar los objetos que forman la asociacin. Los lmites superiores e inferiores
apropiados deben especificarse para indicar si la asociacin es de uno a uno, de
uno a muchos o de muchos a muchos. Por ejemplo, la relacin com pras que se
muestra en la figura 12.10(a) puede definirse en el diccionario de datos de la si
guiente forma:
com pras =
12.4
*la asociacin de un cliente y uno o ms artculos*

@identlda d-del-cliente + 1{@ identidad-del-artculo +
cantidad-com prada}
RESUMEN
Para un sistema con mltiples almacenes (objetos) y relaciones complejas en

tre datos, el DER puede ser una herramienta valiosa. Como se vio en este capitulo,
se enfoca totalmente a las relaciones entre datos, sin dar informacin acerca de las
funciones que los crean o usan.
A pesar de que en este libro hemos usado el DER como una herramienta grfi
ca de modelado para mostrar relaciones entre datos, debe saber que se utilizan va
rias herramientas ms para el mismo propsito; [M artin, 1982] y [Date, 1986]
muestarn muchas alternativas de herramientas de modelado.
www.FreeLibros.org
7 Algunos textos usan el co nvenio de subrayar el o los cam pos clave, por lo cual se puede definir
comprador com o
COMPRADOR = nom bre -del-com ora do r 4- d o m ic ilio + n m e ro -te le f n ico
282
Llegando hasta aqu, muchos estudiosos preguntan si debe desarrollarse

mero el DFD y luego el DER, o a ia inversa. Algunos incluso preguntan si es nec,
sario realmente desarrollar ambos modelos, siendo que cualquiera de ellos prove
tanta informacin interesante. La respuesta a la primera pregunta es sencilla: no rj
porta qu modelo se desarrolle primero. Uno de los modelos pedir a gritos ser efe.
sarrollado primero segn sus propias preferencias, las del usuario, o la naturales
dei sistema mismo (es decir, si es rico en funciones o rico en datos). En otros casos, sin embargo, pudiera encontrarse que ambos modelos se desarrollan paralelamente; esto es particularmente comn cuando el equipo del proyecto contiene ud
grupo bien definido de diseo de bases de datos, o cuando la organizacin de proce.
samiento electrnico de datos tiene un grupo administrador que desarrolla modelos
de datos corporativos.
La segunda cuestin es ms importante: Realmente tiene importancia desa
rrollar dos modelos distintos de un sistema (y, como veremos en el captulo 13, ut
tercer modelo del comportamiento dependiente de! tiempo del sistema)? La res
puesta es que depende del tipo de sistema que se est desarrollando. Muchos sis
temas clsicos de proceso de datos de negocios desarrollados en los aos 60 y 75
parecan (por lo menos superficialmente) consistir en muchas funciones complejas,
pero estructuras de datos relativamente triviales, por lo cual el modelo de DFD se
enfatizaba y a menudo se ignoraba el de DER. De manera inversa, muchos de los
sistemas de apoyo a decisiones y sistemas de bases de datos de investigacin ad
hoc que se crearon en los aos 80 parecan (por lo menos superficialmente) consisfit
en relaciones complejas entre datos, pero casi nada de actividades funcionales; de
aqu que se enfatizara el modelo de DER, y se redujera el de DFD. Las caractersti
cas de tiempo de los sistemas de tiempo real construidos en los aos 60 y 70 pare
can (por lo menos de manera superficial) dominar sobre cualquier consideracin de
funciones y relaciones entre datos; en tales sistemas, el modelo de transicin de es
tados (que se discute en el captulo 13) a menudo se enfatizaba, excluyendo los
DFD y DER.
Sin embargo, los sistemas de fines de los aos 80 y 90, tienden a ser bastante
ms complejos que los sistemas de propsito especial de hace una o dos dcadas,
De hecho, muchos de ellos son entre 100 y 1000 veces ms grandes y complejos.
Muchos de estos sistemas grandes y complejos tienen funciones, relaciones entre
datos y comportamientos dependientes dei tiempo increblemente complejos; consi
dere, por ejemplo, el sistema Guerra de las Galaxias que, segn se estima, requiere
de 100 millones de instrucciones de computadora, y que tendr un comportamiento
de tiempo real extraordinariamente complejo. Para un sistema as de elaborado, es
obvio que las tres herramientas que se discuten en este libro sern crticamente ne
cesarias. Por otro lado, si Ud. se involucra en un sistema sencillo y unidimensional,
puede concentrarse en la herramienta de modelado que enfatiza e ilumina el aspecto
ms importante de su sistema.
www.FreeLibros.org
En el captulo 14 veremos cmo el DER, el DFD, el diagrama de transicin de

estados, la especificacin del proceso y el diccionario de datos pueden compararse
entre s para producir un modelo completo del sistema que sea internamente consis
tente.
1.
Matt Flavin, Fundam ental Concepts o f Inform ation Modeling, Nueva York,
2. Peter Chen, The Entity-Relationship Model: Toward A Unified View of Data,

ACM Transactions on Catatase Systems, Vol. 1, nmero 1 (marzo de 1976),
pp. 9-36.
3.
Peter Chen, The Entity-Relationship Approach to Logicai Database Design.

Weliesley, Mass.: Q.E.D. Information Sciences, 1977.
4.
D.C. Tsichritzis y F.H. Lochovsky, Data Models, Engiewood Ciiffs, N.J.: Prentice-Hail, 1982.
5.
James Martin, Computer Database Organization, Engiewood Ciiffs, N.J.: Prentice-Hail, 1982.
6.
Proceedngs of the International Conference on Data Engineering. Washington,

D.C.: IEEE Press, 1984.
7.
C.J. Date, An Introduction to Database Systems, 4a edicin, Reading, Mass.:

Addison-Wesley, 1986.
8.
Saliy Shlaer y Stephen Mellor, Object-Oriented Systems Analysis: Modeling

the World in Data. Engiewood Ciiffs, N.J.: YOURDON Press, 1988.
9.
R. Veryard, Pragmatic Data Analysis. Oxford, U.K.: Blackwell Scientific Publications, 1984.
10.
Jeffrey Uliman, Principies o f Database Systems. Potomac, Md.: Computer

Science Press, 1982.
11.
Tom DeMarco, Structured Analysis and System Specifcatin. Nueva York,

1.
Qu es un diagrama de entidad-relacin? Cul es su propsito?
2.
En qu difiere un DER de un DFD?
www.FreeLibros.org
3.
Por qu se interesa tanto ia gente en los modelos de datos?
284
4.
Aparte de los analistas, qu otro grupo dentro de una organizacin pucer,

crear modelos de datos?
5.
Por qu se interesa normalmente el grupo DBA en una organizacin porg

modelo de datos?
6.
Cules son los cuatro principales componentes de un diagrama de entidadrelacin?
7.
Cul es la definicin de tipo de objeto?
8.
Cul es la diferencia entre un objeto y un tipo de objeto?
9.
Cules son los tres criterios que debe satisfacer un tipo de objeto?
10.
Cul de los siguientes es probable que sea un tipo de objeto razonable den
tro de un sistema de negocios tpico? Para aquellos que no considere tipos de
objetos razonables, indique por qu:
(a) cliente
(b) calcular impuestos de ventas
(c) estatura
(d) producto
(e) jitomate
(f) religin
(g) temperatura
(h) editar la transaccin
() parte manufacturada
(i) mapa
(k) carcter ASCII
Cul es la definicin de relacin?
12.
Cuntos tipos de objetos pueden conectarse por una relacin?
13.
Cules de las siguientes son relaciones probables en un DER y cules no?

Por qu s y por qu no?
(a) compras
www.FreeLibros.org
(b) cliente
(c) pertenece a
(d) peso
(e) produce
(f) clculo de impuestos de ventas
Cul es la diferencia entre relacin derivada y relacin recordada? Cul se
muestra en un DER?
)5
D dos ejemplos de una relacin derivada entre dos objetos.

Cuntas relaciones pueden existir entre dos objetos en un DER?
17.
Considere el DER que se muestra.
(a) Escriba una descripcin narrativa de objetos y relaciones.

(b) Cuntos pedidos pueden existir en una instancia de fabricante y una de
cliente?
(c) Cuntos p ro du cto s puede comprar un cliente en una instancia de la rela
cin com pras?
18. Muestran cardinalidad los DER?
19. Use la notacin de la figura 12.6 para mostrar una versin razonable del dia
grama de la figura 12.5.
20. Qu argumentos existen contra ia ordinalidad y la cardinalidad en un DER?
21. Cul es la notacin alternativa para los DER que muestra tanto la cardinali
dad como la ordinalidad?
www.FreeLibros.org
286
22.
Dibuje un diagrama DER para representar la siguiente situacin en una aero|[, 1

nea:
La aerolnea XYZ tiene tres recursos principales: aviones, pilotos y miembros

de ia tripulacin. Los pilotos y miembros de la tripulacin tienen sus respevas bases, a las cuales regresan al final de un vuelo. Un vuelo debe tener por [
lo menos un piloto y uno o ms miembros de la tripulacin en un avin. Cada t
avin tiene una base de mantenimiento.
j
23.
Dibuje un DER para describir la siguiente situacin de una editorial:

La editorial ABC trabaja con varios autores diferentes que escriben los libros I
que publica. Algunos autores han escrito slo un libro, mientras que otros han I
escrito varios; adems, algunos libros tienen coautora. ABC tambin trabaja I
con mltiples imprentas: sin embargo, un libro dado lo imprime una sola r,. I
prenta. Un editor de ABC trabaja con diversos autores al mismo tiempo, edi- I
tando y produciendo sus libros; es labor del editor dar a la imprenta la copia
final lista para la cmara cuando se ha revisado y formado el manuscrito.
24.
Dibuje un DER de la siguiente situacin para una organizacin de consultora

de administracin:
Cada representante de ventas trabaja con diversos tipos de clientes y tiene
acceso a varios consultores distintos en la organizacin. Una sesin de con
sultora con un cliente puede requerir varios consultores. Durante la sesin, el
vendedor no se involucra y los consultores rinden sus informes directamente a!
cliente.
25.
Dibuje un DER de ia siguiente situacin:

Un profesor puede impartir varias clases diferentes, siempre que est califica
do para hacerlo. Cada clase debe tener un profesor, pero pueden asistir a ella
varios alumnos. Al comienzo de cada semestre, los grupos se asignan a dis
tintos salones, donde se renen regularmente.
26.
Qu es un tipo asociativo de objeto?

asociativo de objeto y una relacin?
Cul es la diferencia entre un tipo
27.
Qu es un punto de ancla?
28.
D tres ejemplos de tipo asociativo de objeto.
29.
Vea ia figura 12.7. Suponga que no existen datos sobre ia compra que el sis
tema deba recordar. Cmo cambia esto ei diagrama?
30.
Qu es un subtipo/supertipo en un DER?
31.
D tres ejemplos de subtipo/supertipo.
www.FreeLibros.org
Por qu molestarse en tener subtipos/supertipos en un DER? Por qu no

se tienen simplemente tipos de objetos ordinarios?
23
Qu refinamientos puede esperar hacer ei analista despus de dibujar el pri

mer borrador del DER?
34
Cules son las tres formas probables que el analista usara para descubrir
los datos de un modelo de datos?
35.
Qu significa el trmino asignacin en el contexto de este captulo?
36. Cmo debe el analista proceder con un DER si ya est desarrollado el DFD?
37 . Cules son las tres razones para crear tipos de objetos adicionales en un
DER despus de terminar el primer borrador de modelo?
38.
debiera hacer el analista si descubre datos que se pueden asignar a al

gunas instancias de un tipo de objeto pero no a otras?
Qu
39. Qu debe hacer el analista si descubre datos que se aplican a todas as ins
tancias de dos tipos de objeto distintos?
40. Qu debe hacer el analista si descubre datos que describen relaciones entre
otros tipos de objetos?
41. Qu debe hacer ei analista si descubre conjuntos repetidos en un tipo de ob
jeto?
42. Describa el significado de tener conjuntos repetidos en un tipo de objeto. D
un ejemplo.
43. Cules son las cuatro razones comunes para eliminar un tipo de objeto en un
borrador de DER?
44. Qu es un tipo asociativo de objeto flotante?
45. Qu debe hacer el analista si descubre un tipo de objeto que consiste slo en
un identificador en un DER?
46. Qu debe hacer el analista si descubre un tipo de objeto para el cual existe
una sola instancia en el borrador del DER?
47. Qu debe hacer el analista si descubre una relacin derivada en un borrador
de DER?
48. Qu extensiones deben hacrsele al diccionario de datos para manejar el
DER?
www.FreeLibros.org
49. Qu significa la notacin @ en un diccionario de datos?
TRANSICION DE ESTADO;T odo cuerpo perm anece en su estado de reposo o de m ovim iento rectiln e o
uniform e m ientras no acte sobre l una fu e rza que altere dicho estado.
Sir Isaac Newton,
P hiiosophiae N aturalis P rincipia M athem atica,
Leyes d e l M ovim iento, I, 1687

1. La notacin de diagramas de transicin de estados.
2. Cmo dibujar diagramas de transicin de estados
particionados.
3. Cmo construir un diagrama correcto de transicin
de estados.
4. La relacin que existe entre DTE y otros modelos.
E n los captulos anteriores vimos herramientas de modelado que enfatizar

las funciones del sistema, as como los datos almacenados que ei sistema debe re
cordar. Ahora v e r e m o s un tercer tipo d e herramienta de modelado, e l diagrama de
transicin de estados (tambin conocido como DTE), que enfatiza el c o m p o r t a m i e n t o
d e p e n d i e n t e del tiempo d e l sistema.
Hasta hace poco, los modelos del comportamiento dependiente del tiempo del
sistema importaban slo para una categora especial de sistemas conocidos como
sistemas de tiempo-real. Como ejemplo de estos sistemas (que discutimos breve
mente en el captulo 2) se tiene el control de procesos, sistemas de conmutacin te-
www.FreeLibros.org
288
DIAGRAMAS DE TRANSICION DE ESTADOS 289
tnica, sistemas de captura de datos de alta velocidad y sistemas de control y

8 ci militares. Algunos de estos sistemas son pasivos, en el sentido de que no
buscan controlar el ambiente que los rodea, sino ms bien reaccionan a l o captu
ran datos que le ataen. Muchos sistemas de alta velocidad de captura de datos en
tran en esta categora (por ejemplo, un sistema que captura datos cientficos de un
s a t lit e a alta velocidad). Otros sistemas de tiempo real son ms activos, en el sen
tido de que pretenden mantener el control sobre algn aspecto del ambiente que los
rodea. Los sistemas de control de procesos y una variedad de sistemas interconstrudos en otros entran en esta categora.
Como podr imaginarse, los sistemas de este tipo manejan fuentes externas
de datos de alta velocidad, y deben proporcionar alguna respuesta y datos de salida
de manera suficientemente rpida como para manejar ei ambiente externo. Una parte importante de la especificacin de tales sistemas es la descripcin de qu sucede
cuando.
Para los sistemas enfocados a ios negocios, esto normalmente no ha sido tan
Las entradas pueden liegar al sistema de diferentes fuentes a velocida
des relativamente altas, pero habitualmente se pueden detener si el sistema est
ocupado haciendo otra cosa. Por ejemplo, un sistema de nmina no tiene que preo
cuparse por interrupciones y seales de unidades de radar externas. Generalmente
los nicos asuntos que involucran tiempos en este tipo de sistemas son especifica
ciones de tiempo de respuesta, que se incluyen en el modelo de implantacin del
usuario, que se discutir en el captulo 21.
im portante.
Sin embargo, estamos empezando a ver algunos sistemas grandes y comple

jos enfocados a los negocios que s tienen aspectos de comportamiento de tiempo
real. Si el sistema maneja entradas de miles de terminales y entradas de alta veloci
dad provenientes de otros sistemas de cmputo, as como satlites de comunicacio
nes, entonces pueden surgir asuntos de comportamiento dependiente del tiempo, del
tipo que surgen en un sistema clsico de tiempo real. Por ello, aunque no tenga que
catar tales problemas en cada sistema que construya, debiera estar familiarizado
con las herramientas de modelado para el comportamiento dependiente del tiempo.
13.1
NOTACION DE LOS DIAGRAMAS DE TRANSICION DE ESTADOS
En la figura 13.1 (a) se muestra un DTE tpico (aunque es algo ms sencillo

que los diagramas que se vern ms adelante en el captulo). Este diagrama mues
tra el comportamiento de una mquina contestadora de telfono normal.
Los principales componentes del diagrama son estados, y flechas que repre
sentan los cambios de estado. Existe una variedad de notaciones alternativas para
os diagramas de transicin de estados; una que es comn se muestra en la figura
13.1 (b ) . Aunque es equivalente a la de la figura 13.1 (a), tiene la desventaja de pare
cerse demasiado a un DFD. Para evitar confusiones, usaremos la notacin de la fi
sura 13.1 (a) en todo este libro.
www.FreeLibros.org
290
DIAGRAMAS DE TRANSICION DE ESTADOS
13.1.1
Estados del sistem a
Cada rectngulo representa un estado en el que se puede encontrar el sst6.

ma. El New World Dictionary de Webster define un estado de la siguiente maneraUn co n ju n to de circu n sta n cia s o a trib u to s que ca ra cte riza n a una
persona o cosa en un tie m p o dado; form a de ser; condicin.
Por tanto, los estados tpicos de un sistema pueden ser:
Esperar a que el usuario d su contrasea
Calentar una mezcla de sustancias qumicas
Esperar la siguiente orden
Acelerar ei motor
Mezclar ios ingredientes
Esperar los datos del instrumento
Llenar el tanque
Aguardar en reposo
Ntese que muchos de estos ejemplos implican que el sistema est esperando
a que algo ocurra, y no se expresan en trminos de que la computadora est hacien
do algo. Esto se debe a que el diagrama de transicin de estados se usa para desa
rrollar un modelo esencial del sistema,1 es decir, un modelo de cmo se comportara
el sistema si hubiera tecnologa perfecta. Un aspecto de la tecnologa perfecta sera
que la computadora trabaje de manera infinitamente rpida, de modo que cualquier
proceso o clculo que tenga que hacer, o cualquier accin que deba tomar, se haga
en cero momentos. As, cualquier estado observable en el que el sistema se pueda
encontrar slo puede corresponder a periodos en los que 1) est esperando que al
go ocurra en el ambiente externo o, 2) est esperando a que alguna actividad que se
est dando en ese momento en el ambiente (como mezclar, lavar, llenar, acelerar,
etc.) cambie a otra.
Esto no significa que nuestros sistemas sean incapaces de ejecutar accinese
que no pretendamos mostrarlas, sino slo que las acciones, que ocurren instantne
amente en nuestro modelo de tecnologa perfecta, no son lo mismo que los estados,
que representan condiciones observables en las que el sistema se puede encontrar.
Esto es, un estado representa algn comportamiento del sistema que es observable
y que perdura durante algn periodo finito.
www.FreeLibros.org
1 A n alizarem os el co n ce pto de m odelo e se n cia l con m s detalle en el captulo 17.
Figura 13.1 (a): Diagrama tp ic o de tra n s ici n de estados
www.FreeLibros.org
Figura 13.1(a): Diagrama alternativo de transicin de estados
292
13.1.2
Cam bios de estado
Un sistema que existi en un solo estado no sera un objeto de estudio muy

teresante: sera esttico. De hecho, los sistemas de informacin que modelamos
normalmente pueden tener docenas de estados diferentes. Pero, cmo cambia un
sistema de un estado a otro? Si tiene reglas ordenadas que gobiernan su compon^
miento, entonces generalmente slo algunos tipos de cambio de estado sern sigo.
ficativos y vlidos.
Se muestran los cambios de estado vlidos en el DTE conectando pares rele
vantes de estados con una flecha. As, la figura 13.2 muestra que el sistema pueq6
ir del estado 1 al estado 2. Tambin muestra que cuando el sistema se encuentre
en el estado 2 puede ir al estado 3 o regresar al 1. Sin embargo, de acuerdo con este DTE, el sistema no puede ir directamente del estado 1 al 3. Por otro lado, el diagrama dice que el sistema s puede ir directamente del estado 3 de regreso al i
Ntese que el estado 2 tiene dos estados sucesores. Esto es muy comn en los
DTE; de hecho, cualquier estado puede llevar a un nmero arbitrario de estados su
cesores.
A pesar de que la figura 13.2 proporciona informacin interesante acerca dei
comportamiento dependiente del tiempo de un sistema, no dice algo que pudiera resultar ser muy importante: cules son los estados inicial y fina! del sistema. De he
cho, la figura 13.2 es un modelo de estado estable de un sistema que ha estado
siempre activo y que continuar siempre estndolo. La mayora de los sistemas tie
nen un estado inicial reconocible y un estado final reconocible; esto se muestra en la
figura 13.3
www.FreeLibros.org
Figura 13.2: Cambios de estado
Figura 13.3: Estados in ic ia l y fin al

El estado inicial tpicamente suele ser el que se dibuja en la parte superior del
diagrama, aunque no es obligatorio. Lo que realmente identifica al estado 1 en la fi
gura 13.3 como inicial es la flecha desnuda que no est conectada a ningn otro
estado. De manera similar, el estado final suele ser el que se dibuja en la parte infe
rior, pero tampoco esto es obligatorio. Lo que realmente identifica al estado 5 como
final es la ausencia de una flecha que salga de l. En otras palabras, una vez que
se llega al estado 5 ya no se puede ir a ninguna otra parte.
Ei sentido comn dice que un sistema slo puede tener un estado inicial; sin
embargo, puede tener mltiples estados finales. Los diversos estados finales son
mutuamente excluyentes, lo cual significa que slo uno de ellos puede ocurrir duran
te alguna ejecucin del sistema. La figura 13.4 muestra un ejemplo en ei que los po
sibles estados finales son el 4 y el 6.
www.FreeLibros.org
Dado que estamos usando ios DTE para construir un modelo esencial, tam
bin podemos suponer que los cambios de estado ocurren Instantneamente; es de
cir, no se requiere tiempo observable para que el sistema cambie de un estado a
294
Figura 13.4: Estados finales m ltiples de un sistem a
otro. Cuando ios diseadores y programadores empiezan a construir un modelo de

implantacin, esto ser un asunto real: normalmente en una computadora el cambio
de una actividad del proceso a otra s tarda algunos mlcrosegundos, y se debe ase
gurar que suceda lo suficientemente rpido como para que el ambiente no se salga
de control.
13.1.3
C ondiciones y acciones
Para completar nuestro DTE necesitamos aadir dos cosas ms: las condicio
nes que causan un cambio de estado y las acciones que el sistema toma cuando
cambia de estado. Como ilustra la figura 13.5, las condiciones y acciones se mues
tran junto a la flecha que conecta dos estados relacionados.
ESTADO 1
Condicin
Accin
ir
ESTADO 2
www.FreeLibros.org
Figura 13.5: Muestra de condiciones y acciones
Una condicin es un acontecimiento en el ambiente externo que el sistema es

az (je detectar; tpicamente es una seal, una interrupcin o la llegada de un pate de datos. Esto usualmente hace que el sistema cambie de un estado de espe
rar X a un estado de esperar Y; o de llevar a cabo la actividad X a llevar a cabo la
actividad Y.
Como parte del cambio de estado, normalmente el sistema har una o ms ac
ciones: producir una salida, desplegar una seal en la terminal del usuario, llevar
a cat)0 un clculo, etc. As que as acciones que se muestran en un DTE son res
puestas regresadas al ambiente externo o bien clculos cuyos resultados el sistema
recuerda (tpicamente en un almacn de datos que se muestra en el DFD) para po
der responder a algn acontecimiento futuro.2
13.2
DIAGRAMAS PARTiCIONADOS
En un sistema complejo puede haber docenas de estados distintos del siste

ma; tratar de ponerlos todos en un mismo diagrama sera difcil, si no imposible. Por
tanto, tal como se usaron los niveles y las particiones en los DFD, se pueden usar
las particiones con los DTE. La figura 13.6(a) muestra un ejemplo de dos niveles de
DTE para un sistema complejo.
Ntese que, en este caso, cualquier estado individual de un diagrama de ma
yor nivel puede convertirse en un estado inicial para un diagrama de nivel inferior
que describe ms a fondo ese estado de mayor nivel; y el o los estados finales en un
diagrama de nivel inferior corresponden a las condiciones de salida en el estado
asociado de nivel superior. En otros casos, el analista puede requerir mostrar, expl
citamente, cmo es que un DTE de menor nivel sale a algn lugar apropiado en el
de nivel superior.
Un ejemplo de la necesidad de un DTE por partes puede ser el cajero autom
tico que se encuentra hoy en da en la mayora de los bancos; un DTE para esto se
muestra en la figura 13.6(b).
13.3
CONSTRUCCION DEL DIAGRAMA DE TRANSICION DE ESTADOS
Ahora que se ha visto la notacin para los DTE, brevemente discutiremos los
pasos a seguir para su construccin. Puede seguirse cualquiera de dos enfoques;
1.
Se puede comenzar por identificar todos los posibles estados del sistema
y representar cada uno como una caja separada en una hoja de papel.
Luego, se pueden explorar todas las conexiones con significado (es decir,
los cambios de estado) entre las cajas.
2 Observe que para llevar a cabo una accin, el sistem a puede req u e rir entradas a d icionales del
ambiente externo. A s que puede decirse que cada co n d ici n corresponde a un a co ntecim iento ex
terno ai cual debe responder el sistem a y que usualm ente ser reconocido por el sistem a cuando
llegue algn flujo de datos entrante. Sin em bargo, no es necesario que ca d a flu jo entrante de datos
sea un acontecim iento que corresponda a una condicin en el DTE.
www.FreeLibros.org
296
Figura 13.6(a): Dos niveles de DTE
2.
Como alternativa, se puede comenzar por el estado inicial, y luego met

dicamente ir siguiendo un camino hasta el o los estados restantes; luego
del o los estados secundarios, proseguir a los terciarios; etc.
Ei enfoque quedar determinado, en muchos casos, por el usuario con quien

est trabajando, sobre todo si l es el nico que est familiarizado con el comporta
miento dependiente del tiempo del sistema.
www.FreeLibros.org
www.FreeLibros.org
Figura 13.6(b): DTE particionado
p a ra
un cajero automtico
298
Cuando se termine de construir el DTE preliminar, deben seguirse las c,,gu;s.

tes reglas para verificar la consistencia:
Se han definido todos ios estados? Vea con cuidado el sistema para
tectar si existe algn otro comportamiento observable, o alguna otra .
dicin en la que el sistem a pudiera estar, aparte de las que se
identificado.
Se pueden alcanzar todos los estados? Se han definido estados qu,

no tengan caminos que lleven a ellos?
Se puede salir de todos ios estados? C o m o s e m e n c i o n a n t e r i o r m e n t ;

sistema p u e d e tener uno o ms estados finales c o n mltiples entre
a ellos; pero todos los dems estados deben tener un sucesor.
En cada estado, el sistema responde adecuadamente a todas las cor.?,

clones posibles? Este es el error ms comn cuando se construye i,DTE: ei analista identifica los cambios de estado cuando ocurren c
ciones normales, pero no especifica el comportamiento del sistema en:?
condiciones inesperadas. Suponga que el analista model el comporta
miento de un sistema como el que muestra la figura 13.7; se espera qi_=
el usuario presione una tecla de funcin en su terminal para causa
cambio de un estado 1 a un estado 2, y una tecla diferente para ir de
tado 2 al 3. Pero qu tal si el usuario presiona la misma tecla dos vr
seguidas? O alguna otra tecla? S no se especfica el comportamiento
del sistema, existe una buena posibilidad de que los diseadores y pre
el
www.FreeLibros.org
fig u r a
13.7: DTE incompleto
gramadores no lo programen tampoco, y el sistema tendr un comporta

miento impredecible bajo una variedad de circunstancias.
4
LA RELACION DEL DTE CON LOS DEMAS COMPONENTES DEL

MODELO
El DTE puede usarse por s solo como herramienta de modelado. Sin embar
y en general debiera, ser utilizado en conjunto con otras herramientas.
go pu ede,
En la mayora de los casos, el DTE representa una especificacin de proceso

para una burbuja de control en un DFD. Esto se ilustra en la figura 13.8; note que
las c o n d ic io n e s en un DTE corresponden a los flujos de control entrantes en un
pPD, y las acciones en el DTE corresponden a los flujos de control de salida en el
qFD. Como herramienta de modelado de alto nivel, el DTE puede servir incluso co
mo especificacin de proceso para todo el sistema. Si se representa todo el sistema
con un diagrama de una burbuja,3 puede usarse el DTE para mostrar la secuencia
de actividades en el sistema.
Figura 13.8: R elacin entre un DFD y un DTE
www.FreeLibros.org
3 Un diagram a as se conoce com o diagram a de co n texto . Se analizarn con m s de talle en el ca
ptulo 18.
300
13.5
RESUMEN
Los diagramas de transicin de estados son una herramienta poderosa de n

delado para describir el comportamiento requerido de los sistemas de tiempo real
igual que la porcin de la interfaz humana que la mayora de los sistemas en lr
tiene. Aunque no son ampliamente conocidos y utilizados en el desarrollo de sis
mas de informacin dirigidos a los negocios, son una herramienta con la que deb
familiarizarse, porque en un futuro se espera que cada vez ms sistemas, ya sea
ra negocios o para ciencias e ingeniera, adquieran algunas caractersticas de tie*.
po real.
REFERENCIAS
1.
Websters New World Dictonary, Second College Edition, Nueva York: Simor
Schuster, 1980.
1.
Qu es un diagrama de transicin de estados? Cul es su propsito?
2.
Qu tipo de sistemas ms probablemente emplearn un DTE como herra

mienta de modelado?
3.
Son los DTE herramientas importantes para describir los requerimientos t;

un sistema de informacin para negocios tpico? Por qu?
4.
Son ios DTE herramientas importantes para la descripcin del diseo/implan

tacin de un sistema de informacin tpico orientado a los negocios? Por
qu? Si as es, qu tipo de sistemas?
5.
Cules son los dos principales componentes de un DTE?
6.
Muestre una notacin alternativa para un DTE, es decir, una distinta a la es

tndar que se muestra en este captulo y en elresto del libro.
7.
Cmo se define un estado?
8.
D tres ejemplos de estado.
9.
Qu es un cambio de estado? Cmo se muestra en un DTE?
10.
Qu es un estado sucesor?
11.
Qu es un estado inicial de un sistema?

tener un sistema?
Cuntos estados iniciales puede
www.FreeLibros.org
12.
Qu es el estado final de un sistema?

existir en un sistema?
Cuntos estados finales pueden
^3
Qu son las condiciones en un DTE? Cmo se muestran?
14
Qu son las acciones en un DTE? Cmo se muestran?

Cuntas condiciones puede haber en un diagrama de transicin de estados?
Cuntas acciones pueden asociarse con cada condicin enun diagrama

transicin de estados?
de
Cules de los siguientes parecen estados razonables? Para los que no lo pa

rezcan, indique por qu:
(a)
Calcular impuesto de ventas

Revisar mezcla reactiva
(c) Domicilio-para-cobro-al-ciiente
(d) Archivo-de-productos
(e) Elevador subiendo
(f) Temperatura de reactivos fuera de rango
(g) Actualizar total de pedidos
(h) Detener elevador
() Tecla de interrupcin presionada
(j) Procesando datos
(b)
18.
Qu es un diagrama de transicin de estados por partes?
19. Cul es la relacin entre estados iniciales y estados finales en un DTE por
partes?
20.
Cuntos niveles puede haber en un DTE por partes?
21. Cules son los dos enfoques comunes en la construccin de un DTE?

22. Cules son las cuatro reglas para determinar la consistencia de un DTE?
23.
Cul es la relacin entre un DTE y un DFD?
24.
Qu tiene mal el siguiente DTE?

ESTADO
_
25.

ESTADO 1
www.FreeLibros.org
ESTADO 2
302
26.
Qu tiene mai el siguiente DTE?
27.
accin 1
28.
www.FreeLibros.org
ESTADO 1
30

condicin-1
ESTADO 1
31 .
accin-1
Qu tiene mal el siguiente DTE? Si no le ve nada mal, describa o que pudie

ra estar ocurriendo en el sistema que se est modelando con este DTE.
I
f
32.
condicin-1
Qu tiene mal ei siguiente DTE?
33.
En un sistema complejo, debiera empezar el analista por dibujar un conjunto

de DFD, comenzar con los DER, o con los DTE?
34.
Dnde deben describirse los detalles de las condiciones y acciones del DTE
en el modelo del sistema?
35.
Dibuje un DTE para una grabadora sencilla o un tocacintas sencillo.
www.FreeLibros.org
304
36.
Dibuje un DTE para ei cajero automtico de su banco.
37.
Dibuje un DTE para un reioj de pulsera digital (la mayora de los actuales te
nen un modo normal, adems de despertador y crongrafo).
38.
Dibuje un diagrama de transicin de estados para un horno de microondas.
39.
Dibuje un diagrama de transicin de estados para el men de la interfaz hutn8.

na de Lotus 1-2-3.
www.FreeLibros.org
j i
1ALANSE DE MOD
T o d o s los h o m b re s c o rre n el rie s g o de co m e te r e rro re s , y la m a y o ra ,

p o r p a s i n o in te r s , se s ie n te n con la te n taci n d e h a c e rlo .
John Locke,
Ensayo sobre el entendimiento humano, 1 6 9 0

1. Cmo balancear el diagrama de flujo de datos y el
diccionario de datos.
2. Cmo balancear el diagrama de flujo de datos y la
especificacin de proceso.
3. Cmo balancear la especificacin de proceso y ei
diccionario de datos.
4. Cmo balancear el DER, el DFD y ia especificacin
de proceso.
5. Cmo balancear el DER y el diccionario de datos.
6. Cmo balancear el diagrama de flujo de datos y el
diagrama de transicin de estados.
E n l o s ltimos cinco captulos hemos examinado diversas herramientas de

modelado para el anlisis estructurado:
www.FreeLibros.org
305
306
BALANCEO DE MODELOS
Diagrama de flujo de datos
Diccionario de datos
Especificacin de proceso
Diagrama de entidad-relacin
Diagrama de transicin de estados
Cada una de estas herramientas, como hemos visto, se enfoca en un aspecto |

crtico del sistema a modelar. Es importante tener esto en mente, pues significa que I
quien lee el modelo tambin se est enfocando en unaspecto crtico,es decir, el as-1
pecto al cual la herramienta de modelado est atrayendo su atencin.Dado que ei
1
sistema tiene tantos grados de complejidad, se desea que el diagrama de flujo de
datos enfoque la atencin del lector en las funciones del sistema,sinpermitir que las i
relaciones entre datos distraigan su atencin; se desea que eldiagrama deentidad-1
relacin enfoque la atencin en las relaciones entre datos, sin permitir distraccin
por las caractersticas funcionales; y se desea que el diagrama de transicin de es
tados enfoque la atencin en las caractersticas de tiempo, sin la distraccin de las
funciones o los datos.
Pero llega el momento de reunir todas las herramientas, y de eso trata este
captulo. La situacin que enfrenta el modelador del sistema es un tanto anloga a
la antigua fbula de los tres sabios ciegos en la India que se tropezaron con un ele
fante. Como lo ilustra la figura 14.1, llegaron a tres opiniones acerca de la realidad
con la que estaban tratando, tras tocar distintas partes dei elefante:
www.FreeLibros.org
Figura 14.1: Tres ciegos tocando un elefante
BALANCEO DE MODELOS 307
Uno toc la punta de uno de los colmillos del elefante. Aj, lo que tene
mos aqu es un toro. Siento sus cuernos, dijo.
El segundo toc su spera piel, y dijo: Sin duda, esto es un...qu ser?
Un puerco espn? S, definitivamente, un puerco espn.
El tercero sinti una de sus gruesas patas y dijo: Esto debe ser un rbol.
Similarmente, cuando se modelan tres aspectos distintos de un sistema (fun

datos y tiempos), adems de modelar las caractersticas detalladas del siste
ma en un diccionario de datos y un conjunto de especificaciones de proceso, es fcil
desarrollar diversas interpretaciones diferentes e inconsistentes de esa misma reali
dad. Este es un peligro particularmente serio cuando se trata de proyectos muy
grandes, donde es probable que estn involucrados varios grupos de inters y varias
personas. Tambin existe el peligro cuando el equipo que realiza el proyecto (y/o la
com unidad usuaria) involucra personas con muy diferente preparacin.
ciones,
Existe otra razn para enfocarse en ia consistencia entre modelos: cualesquie

ra errores que existan tarde o temprano se detectarn, pero se vuelven cada vez
ms difciles y caros cuanto ms avanza el proyecto. De hecho, es probable que los
errores que se puedan introducir en el modelo de requerimientos durante la fase de
anlisis se propaguen y magnifiquen durante las fases de diseo e implantacin del
proyecto. Esto se da sobre todo en los proyectos grandes donde el anlisis a menu
do lo realizan personas diferentes (o incluso distintas compaas) que las que reali
zan el diseo y la implantacin. Martin seala que un 50% de los errores que se
detectan en un sistema, y ei 75% dei costo de su eliminacin, se asocian con errores
en la fase de anlisis. Los estudios de [Boehm, 1981] muestran que el costo de co
rregir un error aumenta exponencialmente en fases posteriores del proyecto; es diez
veces ms econmico corregir un error del anlisis durante la fase misma de anlisis
que durante la fase de diseo.
Algunos de estos errores son, desde luego, errores simples en cada modelo
individual (por ejemplo, un diagrama de flujo de datos con un sumidero infinito). Y
algunos de los errores se pueden caracterizar como interpretaciones errneas de lo
que el usuario realmente quera. Pero muchos de los errores ms difciles e insidio
sos son errores entre modelos, es decir, inconsistencias entre un modelo y otro. De
una especificacin estructurada en la cual todas las herramientas se han verificado
entre s para asegurar su consistencia se dice que est balanceada.
El error ms comn de balanceo involucra alguna definicin faltante: algo que
se define (o describe) en un modelo y no se define apropiadamente en otro. Vere
cos diversos ejemplos de esto en las siguientes secciones (por ejemplo, un almacn
ce datos que se muestra en el DFD pero no se define en el diccionario de datos, o
-'i objeto en el DER que no se muestra como almacn de datos en el DFD). El se
cundo tipo de error comn es de inconsistencia: la misma realidad se describe de
dos maneras diferentes y contradictorias en dos modelos diferentes.
www.FreeLibros.org
308
BALANCEO DE MODELOS
Examinaremos varios aspectos importantes del balanceo:
Balanceo del diagrama de flujo de datos y el diccionario de datos.
Balanceo del diagrama de flujo de datos y las especificaciones del

proceso.
Balanceo de las especificaciones del proceso y el diccionario de

datos.
Balanceo del DER con el DFD y las especificaciones del proceso.
Balanceo del DER y ei diccionario de datos.
Balanceo de! DFD y el diagrama de transicin de estados.
Como veremos, ias reglas de balanceo son muy claras; requieren de poca in
teligencia o creatividad, pero deben seguirse, y diligentemente.
14.1
BALANCEO DEL DFD Y EL DD
Las regias de balanceo del diagrama de flujo de datos y eldiccionario de datos

son las siguientes:
Cada flujo de datos (es decir, cada flecha del DFD) y cada almacn de
datos deben estar definidos en el diccionario de datos. Si falta la defini
cin en el diccionario, ei flujo o el almacn se considera indefinido.
De manera inversa, cada dato y cada almacn que se define en el diccio

nario de datos debe aparecer en alguna parte del DFD. Si no aparece, di
cho dato o almacn es un fantasma, es decir, algo definido pero que no
se usa en el sistema. Esto puede suceder si los datos se definieron pa
ra que correspondieran con una versin temprana del DFD; el peligro que
se corre es que el DFD pueda cambiarse (es decir, un flujo o un almacn
pudiera eliminarse) sin un cambio correspondiente en el diccionario de
datos.
Esto significa, desde luego, que el analista debe revisar tanto el DFD como el
diccionario cuidadosamente para asegurarse de que estn balanceados. No importa
cul modelo se examine primero, aunque muchos analistas empiezan con el DFD
para asegurar que todos los datos estn definidos en el diccionario. Como todas las
dems actividades de balanceo que se vern en este captulo, es una labor tediosa'/
que se presta para tener un apoyo automatizado.
14.2
BALANCEO DEL DFD Y LA ESPECIFICACION DE PROCESO
www.FreeLibros.org
He aqu las reglas para el balanceo del DFD y las especificaciones del pro
ceso:
Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con
una especificacin de proceso, pero no ambos. Si el DFD muestra una
burbuja que se identifica como 1.4.2, entonces debe existir ya sea una fi
gura correspondiente identificada como 1.4.2, cuyas burbujas se identifi
quen como 1.4.2.1, 1.4.2.2, etc., o bien la especificacin estructurada
debe contener una especificacin de proceso para la burbuja 1.4.2. Si
ambas existen, el modelo es innecesario (y peligrosamente) redundante.
Cada especificacin de proceso debe tener una burbuja de nivel inferior

asociada en el DFD. Dado que la especificacin de proceso requiere de
mucho trabajo, podra pensarse que es altamente improbable que existan
especificaciones de proceso vagabundas rondando por el sistema. Pero
puede suceder: la especificacin del proceso pudiera haberse escrito pa
ra una versin preliminar del DFD, tras lo cual un proceso de revisin pu
do eliminar algunas de las burbujas del DFD.
Las entradas y salidas deben coincidir. El DFD muestra flujos de entrada

y salida para cada burbuja, al igual que las conexiones con los almace
nes. Esto debe ser evidente en la especificacin de proceso tambin: as,
se puede esperar una declaracin READ (o GET, o INPUT o ACCEPT, o
algn verbo similar) correspondiente a cada flujo de entrada, y WRITE (o
PUT o DISPLAY, etc.) para cada flujo de salida.
Observe que estos comentarios se aplican especficamente a las burbujas de

proceso. Para las burbujas de control en un DFD existe correspondencia entre las
burbujas y los diagramas de transicin de estados asociados, como se discuti en la
seccin 14.6
BALANCEO DE LAS ESPECIFICACIONES DEL PROCESO CON EL DFD

Y EL DD
14.3
Las reglas para balancear as especificaciones de proceso con el diagrama de

referencia de un da
debe satisfacer una
de las siguientes reglas:
flujo de datos y el diccionario de datos son las siguientes: Cada

to en la especificacin de proceso (tpicamente, un sustantivo)
Coincide con el nombre de un flujo de datos o almacn conectado a la

burbuja descrita por la especificacin de proceso, o
Es un trmino local, definido explcitamente en la especificacin de proce

so, o
Aparece como componente en una entrada dei diccionario de datos para

un flujo o almacn conectado con la burbuja. As, los datos X y Y apare
cen en la especificacin de proceso de la figura 14.2, pero no aparecen
www.FreeLibros.org
310
BALANCEO DE MODELOS
como flujo de datos conectado en el DFD que se muestra en la fQU|

14.3. Sin embargo, el diccionario de datos, del cual se muestra un fL
ment en la figura 14.4, indica que X y Y son componentes de Z; y @
n;
figura 14.3 vemos que Z es en efecto un flujo de datos conectado a'*
burbuja, por lo que concluimos que el modelo est balanceado.1
ESPECIFICACION DE PROCESO 3.5: CALCULO DEL FACTOR W
* P Y Q SON TERMINOS LOCALES UTILIZADOS PARA O B T E N E R RESULTADOS INTgfi,
MEDIOS *
P = 3.14156 * X
O = 2.78128 * Y - 13
FACTOR-W = P * Q + 2
Figura 14.2: Com ponente de especificacin de proceso de un m odelo de

sistem a
Figura 14.3: C om ponente de un DFD de un m odelo de sistem a
1 Sin em bargo, pudiera va le r ia pena revisar an m s: si X es el nico com ponente de Z que se usa
en la especificacin del proceso, debe cuestionarse seriam ente por qu se m ostr Z com o entrad
desde un principio. Es decir, ios dem s com ponentes de Z pudieran ser datos vagabundos q
deam bulan a travs de la burbuja sin utilizarse. Esto a m enudo refleja ei uso de un m odelo de rspia n tacin a rb itra rio de un sistem a, en lugar de un m odelo de su co m p o rta m ie n to esencial.
www.FreeLibros.org
X=
* com ponente horizontal del fa cto r fram m s *

* unidades: centm etros; escala: 0 - 100 *
Y=
* com ponente ve rtica l del fa cto r fram m is *

* unidades; centm etros; escala: 0 -10 *
Z =
* fa cto r fram m is, com o lo defini el Dr. Fram m is *

X + Y
Figura 14.4: Com ponente del diccio n a rio de datos de un m odelo de sistem a
14.4
BALANCEO DEL DICCIONARIO DE DATOS CON EL DFD Y LAS ESPE

CIFICACIONES DEL PROCESO
De ia discusin anterior puede verse que ei diccionario de datos es consisten

te con el resto del modelo si obedece la siguiente regla:
Cada entrada del diccionario de datos debe tener referencia en una espe
cificacin de proceso, un DFD, u otro diccionario de datos.
Esto supone, desde luego, que se est modelando el comportamiento esencia!

de un sistema. Un diccionario de datos complejo y exhaustivo de una implantacin
existente de un sistema puede contener algunos datos que ya no se usan.
Tambin se podra argumentar que el diccionario de datos se planee de forma
tal que permita una expansin futura; es decir, que contenga elementos que no se
ocupen hoy pero que pudieran ser tiles en un futuro. Un buen ejemplo de esto es
un diccionario de datos con elementos que puedan ser tiles para consultas ad hoc.
Ei equipo del proyecto, tal vez en conjuncin con el usuario, debe determinar si este
tipo de modelo no balanceado es lo apropiado. Sin embargo, es importante por lo
menos estar enterado de tales decisiones deliberadas.
14.5
BALANCEO DEL DER CON E L

PROCESO
DFD Y LAS ESPECIFICACIONES DE
El diagrama de entidad-relacin, como vimos en el captulo 12, presentaba

una visin muy distinta del sistema de la del DFD. Sin embargo, existen algunas re
laciones que deben darse para que el sistema global sea completo, correcto y con
sistente:
www.FreeLibros.org
312
BALANCEO DE MODELOS
Cada almacn del DFD debe corresponder con un tipo de objeto, una ?
lacin o una combinacin de un tipo de objeto y una relacin (es decir, ^
tipo asociativo de objeto) en el DER. Si en el DFD existe un almacn
no aparece en el DER, algo anda mal; y si hay un objeto o relacin en ei
DER que no aparece en el DFD, algo anda mal.
Los nombres de objetos en el DER y los nombres de almacenes de datos

en el DFD deben coincidir. Como vimos en ios captulos 9 y 12, la con.
vencin que sigue este libro es usar la forma plural (es decir, CLIENTES)
en el DFD y la forma singular en el DER.
Las entradas del diccionario de datos deben aplicarse tanto al modelo

DFD como al de DER. As, la entrada del diccionario de datos para e;
ejemplo anterior debe incluir definiciones tanto para e! objeto del DER
mo para ei almacn del DFD. Esto lleva a una definicin de diccionario
de datos como la siguiente:
I
i
I
I
CLIENTES = {CLIENTE}
CLIENTE
= nom bre + d o m ic ilio + nm ero-telefnico + ...
Las entradas del diccionario de datos para la forma singular (por ejemplo,
CLIENTE) deben proporcionar el significado y composicin de una sola instancia del
conjunto de objetos a los que se refiere (en singular) en ei DER, y (en plural) en el
almacn del DFD. Las entradas del diccionario para la forma plural (por ejemplo.
CLIENTES) proporcionan significado a la composicin de un conjunto de instancias.
De manera similar, hay regias que aseguran que el DER sea consistente con
la porcin de la especificacin de proceso dei modelo orientado a las funciones (ten
ga en mente que ias especificaciones de proceso son las componentes detallados
del modelo cuya encarnacin grfica es el DFD). Las reglas son que el conjunto
combinado de todas las especificaciones de proceso deben, en su totalidad:
Crear y eliminar instancias de cada tipo de objeto y relacin que se mues

tra en el DER. Esto puede entenderse viendo el DFD de la figura 14.5:
como se sabe, el almacn CLIENTES corresponde al objeto CLIENTE.
Algo debe ser capaz de crear y eliminar instancias de un cliente, lo cual
significa que alguna burbuja en el DFD debe tener un flujo de datos co
nectado con el almacn CLIENTES. Pero el trabajo mismo de escribir el
almacn (es decir, crear o eliminar una instancia del objeto CLIENTE re
lacionado en el DER) debedarse dentro de la burbuja, lo cual significa
que debe documentarse en ia especificacin de proceso asociada con
ella.2
www.FreeLibros.org
2 Note que !a situacin puede se r algo complicada: la burbuja que se muestra en el DFD pudiera no
ser del nivel inferior. Por ello es posible que la burbuja etiquetada como INGRESAR-NUEVOC LIE N T E en la fig u ra 14.5 se describa con un diagrama de flujo de datos de nivel inferior y no con
Alguna burbuja de DFD define valores para cada dato asignado a cada
instancia de cada tipo de objeto, y algn proceso del DFD usa (o lee) va
lores de cada dato.
CLIENTES
Figura 14.5: Creacin y e lim inacin de instancias dei DER

14.6
BALANCEO DEL DFD Y EL DIAGRAMA DE TRANSICION DE ESTADOS
La condicin de estado puede considerarse balanceada con el diagrama de

flujo de datos si se cumple con las siguientes reglas:
Cada burbuja de control del DFD se asocia con un diagrama de transicin

de estados como su especificacin de proceso. De manera similar, cada
diagrama de transicin de estados en ei modelo global del sistema debe
asociarse con un proceso (burbuja) de control en el DFD.
una especificacin de proceso. De ser ste ei caso, una de las b u rb u ja s de nivel in fe rio r (posible
mente no slo de uno, sino de varios niveles ms abajo) se r primitiva y tendr acceso directo al al
macn. Recuerde del captulo 9 la convencin de que el almacn se muestra en el nivel m xim o
del DFD cuando es interfaz entre dos burbujas, y se repite en cada diagrama de nivel inferior.
www.FreeLibros.org
314
BALANCEO DE MODELOS
Cada condicin del diagrama de transicin de estados debe correspon^,

con un flujo de datos de entrada al proceso de control asociado con si
diagrama de transicin de estados. De manera similar, cada flujo de con.
trol que entra en la burbuja de control debe asociarse con una condicin
apropiada en el diagrama de transicin de estados correspondiente.
Cada accin en el diagrama de transicin de estados debe corresponder

con un flujo de control de salida del proceso de control asociado con dn
cho diagrama. De manera similar, cada flujo de control de salida de la
burbuja de control debe asociarse con una accin apropiada en el diagra
ma de transicin de estados correspondiente.
Estas correspondencias se ilustran en la figura 14.6.
Figura 14.6: C orrespondencias entre el DFD y el DTE
14.7
RESUMEN
Observe que todas las reglas de balanceo de este captulo se presentaron co

mo si usted fuera a examinar personalmente todos los componentes de un modelo
de sistema para detectar errores e inconsistencias en potencia. Esto implicara que
www.FreeLibros.org
extendiera en el piso o en un gran pizarrn todos los DFD, las especificaciones de

proceso, los ERD, DTE y el diccionario de datos, y luego fuera de uno a otro, revi
rando cuidadosamente que todo est en su lugar.
Al estarse preparando este libro, en 1987, eso es precisamente lo que se ha
bra hecho en el 98% de las organizaciones de desarrollo de sistemas del mundo. Si
{ene la suerte de estar leyendo este libro en los aos 90, esto pudiera haber dismi
nuido a un 90%. Y si se est leyendo en 1995 (para cuando el editor ya me deber
haber forzado a producir una nueva edicin en la cual se elimine toda esta seccin),
ja cifra puede ser de un 50%. Lo importante es que las regias de balanceo que he
mos presentado en este captulo pueden automatizarse, y ya existen varias herra
m ie n ta s para estaciones de tra b a jo basadas en PCs que pueden efectuar
mecnicamente parte o toda ia revisin de errores.
Pero hemos visto exactamente el mismo fenmeno en una variedad de cam
pos ms. Se podra argumentar que la proliferacin de sistemas baratos de proce
samiento de palabras ya hizo innecesario aprender a escribir a mano; de hecho, se
podra argumentar que la disponibilidad de revisores de ortografa incluso hace inne
cesario el aprender las reglas. Y la disponibilidad universal de las calculadoras de
bolsillo ya hace innecesario aprender a dividir. Y la presencia de automviles de
transmisin automtica hace innecesario aprender a manejar autos estndar.
De hecho, no se me ocurre ninguna razn fuerte para ensearle a alguien en
Norteamrica a manejar un auto estndar para fines del siglo XX. Ni se me ocurre
razn alguna para enfatizar ei arte de la caligrafa (excepto, tal vez, como una forma
de arte) en una era en la que los sistemas de procesamiento de palabras estn a
punto de ser reemplazados por sistemas de reconocimiento de voz. Pero s aprecio
la necesidad de aprender ios principios bsicos de la divisin, aunque est uno muy
confiado en que nunca le faltar su calculadora de bolsillo; como seala Joshua
Schwartz, de la Universidad de Harvard, por lo menos nos ayuda a saber si la res
puesta que obtuvimos con la calculadora tiene el punto decimal en la posicin co
rrecta.
Se puede discutir incluso los mritos de aprender a escribir a mano en 1987,
siendo que (1) menos de la mitad de los nios privilegiados de los Estados Unidos
tienen una computadora personal en casa, (2) slo un 3% de la poblacin global de
los E.U.A. tiene una computadora personal en casa; (3) slo alrededor dei 10% de
los maestros tienen su propia PC y, (4) slo un pequeo porcentaje de las escuelas
de los E.U.A. estn preparadas para ensear mecanografa. La escritura a mano es
tecnolgicamente obsoleta, y para los padres familiarizados con la computacin (sin
mencionar a los nios familiarizados con la computacin) es penoso verse forzados
a aprender esta antigua y primitiva tcnica de comunicacin; pero probablemente es
una tcnica todava necesaria en nuestra sociedad actual. Despus de todo, fue s
lo hace unos cuantos aos que la mayora de los padres dejaron de ensearles a
sus hijos a reemplazar bujas, cambiar ei aceite y cambiar llantas de su automvil.
www.FreeLibros.org
316
BALANCEO DE MODELOS
De manera similar, estoy convencido de que un analista profesional necesitg

entender los principios del balanceo que se presentan en este captulo. Como analista, es probable que no tenga ms alternativa que seguir mecnicamente estas re,
gias durante los prxim os aos hasta que se d istribuyan am pliam ente |as
herramientas de ingeniera de software adecuadas. El proceso manual de revisin
de errores normalmente se validar en un ambiente de revisin global (waikthrough)
que se discute en el apndice D.
'
1
'
I
REFERENCIAS
1.
James Martin, An Inform ation Systems Manifest. Englewood Ciiffs, N.J.- |

Prentice-Hall, 1984.
t
2.
Barry Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Pren

tice-Hall, 1981.
1.
Por qu es importante balancear los modelos de una especificacin de siste

ma? Cules son los peligros de una especificacin no balanceada?
2.
Por qu es importante encontrar errores en un modelo de sistema tan pronto i

como sea posible?
I
3.
Qu porcentaje del costo de la eliminacin de errores se asocia con la fase

de anlisis de un proyecto?
4.
Cules son los dos errores de balanceo ms comunes?
5.
Con cules partes del modeio del sistema debe balancearse el DFD?
6.
Con cules partes del modelo del sistema debe balancearse el DER?
7.
Con cules partes del modelo del sistema debe balancearse el DTE?
8.
Con cules partes del modelo del sistema debe balancearse el diccionario de I
datos?
9.
Con cules partes del modelo del sistema debe balancearse la especificacin
del proceso?
10.
Existen otras componentes del modelo del sistema que deban balancearse?
11.
Cules son las reglas a seguir para balancear el DFD y el diccionario de datos?
www.FreeLibros.org
12.
Bajo qu condiciones puede definirse un artculo en el DD sin que aparezca

en el DFD?
13
Cules son las reglas a seguir para balancear el DFD y la especificacin de

proceso?
14
Qu sucedera si se escribiera una especificacin de proceso para una bur

buja no primitiva (o no atmica) en el DFD?
15
Debe existir una especificacin de proceso para ios procesos de control en el

DFD? De ser as, deben tener ia misma forma de la especificacin de proce
so para un proceso normal?
10
Cules son las reglas a seguir para balancear la especificacin del proceso
con el DFD y el diccionario de datos?
17. Qu son datos vagabundos?

18. Bajo qu condiciones es aceptable que un trmino (o referencia de dato) en
la especificacin de proceso no se defina en el diccionario de datos?
19. Cules son las reglas a seguir para balancear el diccionario de datos con ei
DFD y la especificacin del proceso?
20. Bajo qu condiciones es posible que ei equipo del proyecto deliberadamente
introduzca elementos en el diccionario de datos que no estn en el DFD?
21. Cules son las reglas a seguir para balancear el DER y el DFD?
22. Cul es la convencin que se sigue para hacer coincidir nombres del DER
con almacenes en el DFD?
23. Cules son las reglas a seguir para balancear el DER y ia especificacin del
proceso?
24.
Cules son las reglas para balancear el DTE y el DFD?
25. B a jo qu condiciones es vlido no tener un DTE en un modelo del sistema?

26. Cmo se deben aplicar ias reglas de balanceo que se presentan en este ca
ptulo en un proyecto tpico de desarrollo de sistemas? Quin debe ser res
ponsable de vigilar que todo se haga?
27.
Si tiene una estacin de trabajo autom atizada de anlisis, es necesario

aprender las regias de balanceo presentadas en este captulo? Por qu?
28.
Si se han balanceado los modelos del sistema, se puede confiar en que es

tn correctos? Por qu?
www.FreeLibros.org
318
BALANCEO DE MODELOS
s ig u ie n te
29.
Seale los errores de balanceo del
modelo.
30.
Deben balancearse el DTE y el DER? Por qu?
www.FreeLibros.org
La necesidad de d e scu brir pronto ia ineficienca vuelve im portante

externar (es decir, hacer visible) un diseo que evoluciona en cada
etapa. Los planos de ingeniera, por ejem plo, sirven para eso y le
son tiles no nada m s al diseador, a quien sealan los puntos p ro
blem ticos e inconsistencias potenciales, sino tam bin al equipo de
una organizacin entera que desarrolla un producto dado. Los p la
nos son el p rincipal m edio de com unicacin, critica y refinam iento
colectivo. M s an, los m todos de representacin deben ser relati
vam ente sencillos y directos al hacer el puente entre la realidad y el
programa, y deben ser tiles durante los m ltiples pasos iterativos.
L.. Belady, prefacio de S oftw are Design, [Peters, 1981]

1. Cmo identificar diversas variantes de los diagra
mas de flujo.
2. Cmo dibujar diagramas HIPO y diagramas de
estructura.
3. Cmo identificar diversas variantes de ios DFD.
4. Cmo identificar diversas variantes de DER.
L a s h e r r a m i e n t a s d e modelado que se presentan en los ltimos captulos de

ser s u f i c i e n t e s para cualquier proyecto en el que trabaje. Sin embargo, debe
tambin familiarizarse con algunas h e r r a m i e n t a s adicionales. Aun si no l a s usa, pu
ben
www.FreeLibros.org
319
320
HERRAMIENTAS ADICIONALES DE MODELADO
diera encontrarlas en su trabajo, y por lo menos debe saber cmo leerlas e interprg.
tarlas.
Las herramientas adicionales que analizaremos en este captulo incluyen la
siguientes:
Diagramas de flujo y sus variantes
Diagramas de flujo de sistema
Diagramas HIPO y diagramas de estructura
Variantes de los diagramas de flujo de datos
Variantes de los diagramas de entidad-relacin
El propsito de este captulo no es convertirlo en experto en alguna de estas

herramientas, sino simplemente mostrarle que existen como alternativas. Se pueden
encontrar detalles adicionales acerca de cada una en las referencias que se mencio
nan al final del captulo.
15.1
DIAGRAMAS DE FLUJO Y SUS VARIANTES
15.1.1
El diagram a cl sico de flu jo
Una de las primeras y mejor conocidas herramientas de modelado es el dia

grama clsico de flujo; en la Figura 15.1 se muestra uno tpico.
Si ha tenido contacto con computadoras, o con la programacin o proceso de
datos en cualquiera de sus formas, es probable que ya haya conocido al menos de
manera informal los diagramas de flujo. No los discutiremos con detalle en este li
bro, sino que slo veremos un subconjunto de la notacin. Para conocer ms deta
lles al respecto de la notacin de diagramas de flujo, vase [Chapn, 1970].
La notacin de ia figura 15.1 slo tiene tres componentes:
El cuadro representa una instruccin ejecutable o una secuencia contigua

de instrucciones de la computadora.
El rombo representa una decisin; en el caso sencillo, representa una de

cisin binara.
Las flechas que conectan los cuadros representan el flujo de control. S

lo puede haber una flecha que fluya hacia afuera de un rectngulo; es de
cir cuando la ejecucin de una instruccin de computadora concluye, se
puede proceder a alguna instruccin o decisin siguiente nica. De ma
nera similar, puede haber slo dos flechas que emanen de una decisin.
www.FreeLibros.org
HERRAMIENTAS ADICIONALES DE MODELADO 321
Figura 15.1: Diagrama tp ic o de flu jo
Como puede verse, el diagrama de flujo permite representar grficamente la

lgica de procedimiento de un programa de computadora. Y es ah donde los dia
gramas de flujo se utilizan ms, aunque la introduccin de los lenguajes de progra
macin de alto nivel en los aos 60 y 70 elimin en gran parte la necesidad de
diagramas de flujo detallados.
Pero si son una herramienta de programacin, por qu discutirlas en este li
bro? La respuesta pudiera habrsele ocurrido ya: algunos analistas usan diagramas
de flujo como manera de documentar las especificaciones del proceso (es decir, co
mo alternativa del lenguaje estructurado y otras herramientas que se presentaron en
el captulo 11). Como puede ser que recuerde del captulo 11, siento que cualquier
tcnica de documentacin que describa de manera precisa la poltica del usuario y la
comunique de manera efectiva es aceptable. As, si el usuario disfruta de leer dia
gramas de flujo y stos describen de manera precisa la poltica que realiza una bur
buja en un DFD, entonces pueden usarse.
www.FreeLibros.org
Sin embargo, muy pocos analistas usan realmente diagramas de flujo detalla
dos como especificaciones de proceso. Existen diversas razones para esto:
322
A menos que se tenga mucho cuidado, el diagrama de flujo puede volverse increblemente complicado y difcil de leer.1 La figura 15.2 muestra un
ejemplo de un diagrama de flujo no estructurado.
Aunque ya se encuentra disponible apoyo automatizado (en estaciones
de trabajo basadas en PCs), todava requiere mucho trabajo desarroll
los graficados de un diagrama de flujo. Y si la poltica detallada del usuario cambia, o el analista tiene que cambiarla varias veces antes de obte
ner algo que el usuario acepte como correcto, consumir mucho tiempo y
ser tedioso volver a dibujar el diagrama cada vez. Si la especificacin
del proceso se ha representado en alguna forma textual que pueda mani
pularse con un procesador de palabras usualmente los cambios sern
ms fciles.
Los modelos grficos usuaimente son la manera ms efectiva de ilustrar
una realidad multiimensionai. Los diagramas de flujo de datos, por ejem
plo, ilustran bien el hecho de que todas las burbujas del sistema se pue
den activar al mismo tiempo. Pero el flujo de control de un programa o
especificacin de proceso individual puede describirse en una forma uni
dimensional; es decir, la lgica puede acomodarse de manera que fluya
www.FreeLibros.org
1 C om o co n secuencia de esto, una especificacin d e sa rro lla d a con diagram as de flu jo se ra much
sim o m s grande que una especificacin d e sarrollada con otras herram ientas d iscutidas en este l- |
bro.
uniformemente de manera descendente.2 Debido a esto, los graficados

son innecesarios.
15.1.2
Variantes de los diagram as de flu jo
Aunque los diagramas clsicos de flujo son los ms comnmente usados, si es

que se usan, existen variantes que se deben conocer. Mencionaremos cuatro:
1.
Diagramas de Nassi-Shneiderman
2.
Diagramas de Ferstl
3.
Diagramas de Hamiiton-Zeldin
4.
Diagramas de anlisis de problemas
Los diagramas de Nassi-Shneiderman (a veces conocidos como diagramas de

Chapn)se introdujeron en los aos 70 (vase [Nassl y Shneiderman, 1973], y [Cha
pn, 1974]) como forma de obligar a un enfoque estricto deprogramacin estructura
da. Un diagrama de Nassi-Shneiderman tpico se muestra en a figura 15.3. Como
Obtener registro maestro
Obtener registro de transacciones
\
\
HACER MIENTRAS haya ms transacciones

0 haya ms registros maestros.
~ '~ ~ '~ ~ ^ ^ _ m a e s tro = transaccin?
falso
verdadero
actualizar maestro
maestro < fra n s a c c i rt^"^
falso
escribir maestro
v e rd a d e ro ^ \
obtener nuevo maestro
escribir maestro
imprimir error
obtener nueva trans.
obtener maestro
obtener trans.
Cerrar archivo maestro

Cerrar archivo de transacciones
Figura 15.3: Diagrama tp ico de Nassi-Shneiderm an
2 El hecho de que cu a lq u ie r lgica a rbitraria de diagram as de flu jo pueda reacom odarse en un flujo
descendente equivalente es la base de la pro g ra m a ci n estructurada. Bhm y Jacopin[2] probaron
que esto se poda hacer en trm inos de diagram as de flu jo p o r prim era vez; en trm inos de progra
macin, significa que cu a lq u ie r program a puede escribirse en un lenguaje tipo Pascal sin declara
ciones GOTO.
www.FreeLibros.org
324
puede verse, el diagrama es fcil de leer. Sin embargo, se podra argumentar c

ios diagramas de Nassi-Shneiderman son slo declaraciones del lenguaje estructL,
rado encerradas en cuadros.
Los diagramas de Ferstl son otra variante del diagrama clasico de flujo,
Ferstl, 1978] se proporciona una descripcin completa. Un diagrama de Ferstl t[p,l
co se muestra en la figura 15.4(a). Adems de mostrar la lgica normal y secuencia;-,
del programa, el diagrama de Fersti puede usarse para mostrar procesos en paral, |
lo; la notacin de Ferstl para procesos paralelos se muestra en la figura 15.4(b).
J
Los diagramas de Hamilton-Zeldin se produjeron como parte de las actividades!
de desarrollo de software del proyecto del transbordador espacial de la NASA; vas61
[Hamiton y Zeldin, 1972], Un diagrama tpico de Hamilton-Zeldin, a veces conockfe
como diagrama de diseo estructurado, se muestra en la figura 15.5. En los diagra
mas de Hamilton-Zeldin, los rectngulos tienen el mismo significado que los de un
diagrama de flujo ANSI: una declaracin ejecutable o un grupo de declaraciones eje
cutables contiguas. Un pentgono alargado se usa para mostrar tanto las declaracio
nes SI como las iteracio n es H ACE R-M i ENTRAS/RE PITE-HASTA. El control I
normalmente fluye de arriba hasta abajo del diagrama, excepto en el caso de prus- j!
bas SI e iteraciones (HACER y REPITE), que proceden de izquierda a derecha.
Figura 15.4(a): Diagrama tpico de Ferstl
www.FreeLibros.org
Los diagramas de anlisis de problemas (PAD, por sus siglas en ingls), que
la corporacin Hitachi (vase [Futamura, Kawai, Horikoshi y Tsutsumi,
1981])- son una rePresentacn bidimensional y arborescente de la lgica de progra^gs Los componentes de un PAD se muestran en la figura 15.6(a). Como los diararrtas de Hamilton-Zedin, los PAD se leen de arriba abajo, y las construcciones SI
se muestran de izquierda a derecha; hay un ejemplo en la figura 15.6(b).
d e s a r r o ll
Figura 15.4(b):
Notacin de procesos en paralelo en diagramas de Ferstl
Como los diagramas de Ferstl, un PAD puede mostrar procesos en paralelo;

tambin usa una combinacin de despliegue vertical de flujo secuencia! con desplie
gue horizontal de niveles de anidamiento (por ejemplo, ciclos dentro de ciclos) que
es similar a los diagramas de Hamilton-Zeldin.
www.FreeLibros.org
326
R E P IT E
HASTA
nexch=0
> ---------------
hacer
n e x tc h 0
Ejecuta d e 1=1
a N-1
si x m .
.ge. X ( l + 1 ) / /
hacer
NEXCH1
Intercambia^
X(l) y X(i+ij
Figura 15.5: Diagrama tp ic o de Ham ilton-Zeidn
Figura 15.6(a): Componentes de un PAD
15.2
DIAGRAMAS DE FLUJO DE SISTEMA
Los diversos enfoques de diagramas de flujo de la seccin anterior son tiles

para mostrar la lgica detallada, dentro de un programa o dentro de una especifica
cin de proceso para una burbuja individual en un DFD. Tambin se puede mostrar
una visin de mayor nivel de la organizacin de un sistema por medio de otro tipo de
www.FreeLibros.org
diagrama cie ^luio: el diagrama de flujo del sistema. Un diagrama de flujo tpico de
sistema se muestra en la figura 15.7.
Observe que los rectngulos representan agregados operativos de software de
cornputdora (por ejemplo, programas, pasos de la tarea, ejecuciones u otras unida
des de software). El diagrama de flujo del sistema tambin muestra varios tipos de
a r c h iv o s fsicos (por ejemplo, archivos de cinta magntica o de disco). Y puede
mostrar Ia presencia de terminales en lnea o enlaces de telecomunicaciones.
MIENTRAS c3
P4
P5
Figura 15.6(b): PAD tp ic o
El diagrama de flujo del sistema es a menudo muy til para los diseadores
que deben desarrollar una arquitectura global del hardware y software del sistema
para implantar los requerimientos del usuario. Sin embargo, siento que no es una
herramienta de modelado apropiada para el anlisis de sistemas, por la sencilla ra
zn de que enfatiza los detalles de implantacin fsica que no debieran estar discu
tiendo ei analista y el usuario. Por ejemplo, en lugar de hablar acerca de un archivo
en disco debieran estar discutiendo su contenido; en lugar de habiar acerca de los
programas individuales, deberan discutir las funciones a realizar.
www.FreeLibros.org
328
Existe una situacin en ia que el diagrama de flujo del sistema pudiera ser jj
para modelar: ai fina! de la actividad de anlisis, cuando se est desarrollando e
modelo de implantacin del usuario. En este momento, ei usuario, el analista y e
equipo de implantacin (diseadores y programadores) discuten las limitaciones de
implantacin que tendr el sistema; se incluyen cosas como la determinacin de ja
frontera de automatizacin (qu partes del sistema sern automatizadas y cules se.
rn manuales) y la interfaz humana (detalles de la interaccin entre el sistema y SUs
usuarios humanos).
Archivo
temporal
(disco)
Archivo
principal
ACTUALIZAR
PROGRAMA
Informe diario
I
Figura 15.7: Diagrama de flujo del sistema tpico
www.FreeLibros.org
15_3
d ia g r a m a s h ip o
IBM desarroll los diagramas HIPO en los aos 70 (vase [HIPO, 1974] y [Katzan, 1976]) y algunos analistas los han usado para presentar una visin de alto nivel
de las funciones que realiza el sistema, al igual que la descomposicin de funciones
en subfunciones, etc. Un diagrama HIPO tpico se muestra en la figura 15.8.
En algunos medios de usuarios, los diagramas HIPO pueden ser herramientas
e modelado tiles porque se parecen al diagrama de organizacin ya familiar que
d escribe la jerarqua de gerentes, subgerentes, etc. Sin embargo, ei diagrama no
m uestra los datos utilizados o producidos por el sistema; aunque es comprensible
que se quisiera desenfatizar relaciones entre datos en un modelo, no siento que e li
minar toda la informacin sobre os datos sea til.
En realidad, existe un segundo componente del diagrama HIPO que s muestra
los datos. El diagrama que se muestra en ia figura 15.8 es un VTOC, o tabla visual
de contenidos. Cada funcin que se representa por medio de un rectngulo puede
describirse con mayor detalle en un diagrama IPO (siglas en ingls de entrada-pro
ceso-salida); un diagrama IPO tpico se muestra en la figura 15.9.
www.FreeLibros.org
Figura 15.8: Diagrama tpico HIPO
330
de ACTUALIZAR-ARCHIVO-PRINCIPAL
INGRESO
primera
tarjeta
de la
1
transaccin
PROCESO: OBTENER transaccin

vlida
SENALADOR = 0
LLAMA INICIALIZATRANS
REPITE HASTA fin de archivo O
fin de transaccin
LLAMA TRAERCAMPOVALIDO
SI NO es fin de archivo o fin de
transaccin
LLAMA RECOLECTACAMPOS
FIN SI
FIN REPITE
SALIDA
transaccin
primera tarjeta
de siguiente
transaccin 1*
fin-de-archivo
A: INICIALIZATRANS
TRAERCAMPOVALIDO
RECOLECTACAMPOS
Figura 15,9: Un diagram a IPO tpico
Aunque los detalles de los datos se muestran de hecho en este nivel, no apa-j
recen en ei diagrama VTOC de alto nivel. As, no es fcil que alguien que vea un pa- 1
norarna global del sistema detecte las interfaces entre sus diversos componentes.
15.4
DIAGRAMAS D E ESTRUCTURA
Una variante de los diagramas HIPO que se utiliza ampliamente son los dia
gramas de estructura . Uno tpico aparece en la figura 15.10; observe que adems
de mostrar la jerarqua funcional muestra las Interfaces de datos entre los compo
nentes.
A diferencia de la mayor parte de los diagramas anteriores, el rectngulo en un
diagrama de estructura no representa una declaracin computacional ni un grupo
contiguo de declaraciones, sino que representa un mdulo. (Ejemplos comunes de
mdulos son las subrutinas de FORTRAN, los procedimientos de Pascal, los subpro-
www.FreeLibros.org
as y las SECTIGNes de COBOL). Las flechas q u e conectan los mdulos no redeclaraciones GOTO sino llamados de subrutinas; la notacin implica que
Jna su b ru fin a terminar o regresar a donde se llam cuando finalice de realizar su
9 ggentan
funcin.
Aunque el diagrama de estructura generalmente se prefiere frente al diagrama

ppO, todava no tiene un uso verdadero en ei rea dei anlisis de sistemas. Por
tiu? Porque se utiliza como herramienta de diseo para modelar una jerarqua sin
to n iz a d a de mdulos en un sistema; por sincronizada entendemos que slo un m
dulo se ejecuta en un tiempo dado, lo cual es una representacin precisa de la
manera en la que la mayor parte de as computadoras comunes trabajan hoy en da.
por otro lado, el analista necesita una herramienta que le permita mostrar una je ra r
qua de redes asincrnicas de procesos; esto se logra de manera efectiva con un
conjunto de DFD por niveles.
El diagrama de estructura se utiliza extensamente en el diseo de programas;
se dicutir con ms detalle en el captulo 22.
MODULO
EJECUTIVO
\
3 ^
O-
o
MODULO
.
MODULO
B
MODULO
C
MODULO
D
c a r c te r
ESCRIBIR
CARACTER
OBTENER
CARACTER
c a r c te r
OBTENER
REGISTRO
EXTRAER
CARACTER
xcarete.
INSERTAR
CARACTER EN
REGISTRO
ESCRIBIR
REGISTRO
Figura 15.10: Diagrama tp ic o de estructura
15.5
VARIANTES DE LOS DIAGRAMAS DE FLUJO DE DATOS
www.FreeLibros.org
Como se mencion en el captulo 9, hay varias diferencias cosmticas entre
los diagramas de flujo de datos de este libro y los que se muestran en otros. Las di
ferencias primarias usualmente involucran cosas tales como el uso de un rectngulo
332
o un valo en lugar de una burbuja para mostrar las funciones que realiza el sista I
ma; los diagramas de flujo de datos dibujados con valos usualmente se conoce I
como diagramas de Gane-Sarson.
Sin embargo, existe por lo menos una variante significante del diagrama de % I
jo de datos clsico; se conoce como diagrama SADT y se desarroll en Softech (va, I
se [Ross y Schoman, 1977]). La figura 15.11 muestra un diagrama SADT tpico.
Aunque similares en naturaleza a los diagramas de flujo de datos que se pre.
sentan en este libro, los diagramas SADT distinguen entre flujos de datos y efe cor7
tro! por la manera en la que se colocan las flechas en los rectngulos. Aunque esto
s se puede realizar, impone limitaciones topolgicas en el diagrama, que muchos
analistas encuentran incmodas.
15.6
VARIANTES DE LOS DIAGRAMAS DE ENTIDAD-RELACION
Los diagramas de entidad-relacin que se presentaron en e! captulo 12 son

considerados por la mayora de los analistas como la forma ms general y abstracta
de representar relaciones entre datos. Sin embargo, existen por So menos otras tres
notaciones populares de estructuras de datos:
El diagrama de Bachman
Los diagramas de estructura de datos de DeMarco
Los diagramas de estructura de datos de Jackson
Una de las formas ms comunes de modelo de datos es el diagrama de Bach

man, que primeramente desarroll Charles Bachman en los aos 60. La figura 15.12
muestra un diagrama de Bachman tpico. Observe que es similar al diagrama de en
tidad-relacin que se discuti en el captulo 12, pero no muestra explcitamente la
flujos de datos
de entrada
flujos de datos de salida
mecanismo
de apoyo
www.FreeLibros.org
Figura 15.11: Diagrama SADT tpico
Figura 15.12:
Diagrama tp ic o
de Bachman
relacin entre objetos. Note tambin la flecha de dos cabezas: indica una relacin
de uno-a-muchos (por ejemplo, un cliente puede poseer ms de una casa, pero (en
este modelo) una casa slo puede tener un dueo).
Los diagramas de estructura de datos de De Marco han logrado bastante popu
laridad durante los ltimos diez aos; un diagrama tpico de estructura de datos se
muestra en la figura 15.13. Observe que adems de mostrar cada objeto del modelo
de datos, se muestra el campo llave; como se recordar, la convencin que este li
bro usa es mostrar el campo llave en el diccionario de datos.
Aunque los diagramas de estructura de datos de Jackson no se utilizan mucho
en ios E.U. por ahora, son bastante populares en Inglaterra, Europa y otras partes
del mundo; Jean-Dominique Warnier, [Warnier, 1976] y Ken Orr [Orr, 1977] desarro
llaron modelos de datos similares, que son un tanto ms populares en los E.U. En
lugar de enfocarse en ia relacin entre distintos objetos en un sistema, los diagra
mas de Jackson ofrecen medios grficos para mostrar a estructura jerrquica de un
solo objeto. Los componentes de un diagrama de Jackson se muestran en ia figura
www.FreeLibros.org
334
Figura 15,13: Diagrama tp ic o de estructura de datos de DeMarco
15.14(a); note que esta misma estructura jerrquica puede documentarse directa- |
mente en ei diccionario de datos usando ianotacin que se presenta en el captulo |
11, como muestra la figura 15. 14(b).
|
15.7
RESUMEN
La iista de herramientas de modelado mostrada en este captulo no est com- |

pleta, ni se han discutido con detalle estas herramientas alternativas; para conocer I
ms se requiere consultar las referencias que se mencionan al final del captulo. Sin j
embargo, tenga en mente que pudiera nunca ver alguno de estos diagramas en un
proyecto real (con la probable excepcin del siempre presente diagrama de flujo);
Por ello, le recomiendo que no se familiarice mucho con los diagramas de HamiltonZeldin, los PAD, los diagramas de Ferstl, etc., a menos de que se encuentre traba
jando en un proyecto que los requiera.
Tenga presente que pudiera enfrentarse a tcnicas de construccin de diagra
mas totalmente especficas y particulares que no se discuten en este libro (y posible
mente en ninguno). Esto no debe preocuparle: no hay nada particularmente sagrado
acerca de las herramientas usadas aqu. Sin embargo, existe una diferencia entre
herramientas de modelado buenas y malas; si se encuentra ante nuevas tcnicas,
vuelva a leer el captulo 8 para identificar los criterios que distinguen a las herra
mientas buenas.
www.FreeLibros.org
El asterisco,
uno u otro
se utiliza para mostrar iteracin, y la O" para mostrar
As, este modelo indica que el dato (u objeto) X consiste en 0 o ms

ocurrencias de A, seguidas de una B, seguido por una E. El dato B
consiste en una C o una D.
Figura 15.14(a): Diagrama tp ic o de e stru ctu ra de datos de Jackson
X = {A } + B + E
B = [C I D]
Figura 15.14(b): Notacin de d ic c io n a rio de datos correspondiente a la
estru ctura de datos de Jackson de la figura 15.14 (a)
REFERENCIAS
1.
Ned Chapn, Fowchartng with the ANS Standard: A Tutora! , ACM Computing Surveys, volumen 2, nmero 2 (junio de 1970), pp. 119-146.
2.
Corrado Bhm y Guiseppe Jacopini, Flow Diagrama, Turing Machines and

Languages with Oniy Two Formation Rules, Communications of the ACM, vo
lumen 9, nmero 5 (mayo 1966), pp. 336-371. Tambin publicado en Classics
in Software Engineering, E. Yourdon (editor). Nueva York: YOURDON Press,
1979.
www.FreeLibros.org
336
3,
I. Nassi y B. Shneiderman, Flowchart Techniques for Structured Progra~

ming, ACM SIGPLAN Notices, volumen 8. nmero 8 (agosto de 1973), pp
26.
' |
4.
Ned Chapn, New Formal Flowcharts, Software: Practice and Experence, y0

lumen 4, nmero 4 (octubre-diciembre 1974), pp. 341-357.
5.
O. Ferstl, Fiowcharting by Stepwise Refinement, ACM SIGPLAN Notices, ye.

lumen 13, nmero 1 (enero de 1978), pp. 34-42.
6.
M. Hamton y S. Zeldin, Top-Down, Bottom-Up, Structured Programming, 8f!e

Program Structurng, Charles Stark Draper Laboratory, documento E-2?2g
Cambridge, Mass: Massachusetts Institute of Technology, diciembre de 1972
7.
Y. Futamura y otros, Development of Computer Programs by PAD (Problen

Analysis Diagram}, Proceedings o f the Fifth International Software Engine^,
ring Conference. Nueva York: IEEE Computer Society, 1981, pp. 325-332.
8.
HIPO: A Design Aid and Documentation Technique, IBM Corp., manual nmero
GC20-1851-0. White Plains, N.Y.: IBM Data Processing Div., octubre de 1974,
9.
Harry katzan, Jr., Systems Design and Documentation: An Introduction to the

HIPO Method. Nueva York: Van Nostrand Reinhold, 1976.
10.
Doug Ross y Ken Schoman, Structured Analysis for Requirements Definition,

IEEE Transactions on Software Engineering, volumen SE-3, nmero 1, enero
de 1977, pp. 6-15. Tambin reimpreso en Classics in Software Engineering, E,
Yourdon (editor). Nueva York: YOURDON Press, 1979.
11.
C.W. Bachman, Data Structure Diagrams", Data Base, The Quarterly Newsiett&r o f the Special interest Group on Business Data Processing of the ACM, vo
lumen 1, nmero 2 (verano de 1969), pp. 4-10.
12.
Tom DeMarco, Structured Analysis and Systems Specification, Nueva York:

13.
Michael Jackson, Principies o f Program Design. Londres: Academic Press,

1975.
14.
Larry Peters, Software Design: Methods and Techniques. Nueva York: YOUR
DON Press, 1981.
15.
Ken Orr, Structured Systems Development. Nueva York: YOURDON Press

1977.
16.
Jean-Domlnique Warnler, Lgica! Construction of Programs, 3a edicin, tradu

cida por B. Flanagan, Nueva York: Van Nostrand Reinhold, 1976.
www.FreeLibros.org
preguntas
y e je r c ic io s
-g
Por qu es importante familiarizarse con otras herramientas adems de DFD,

ERO y DTE?
Cules son los tres componentes principales de un diagrama de flujo?
proyecto de Investigacin: Qu otras imgenes se usan a veces en diagra

mas de flujo? Consulte [Chapn 1970] para ms informacin.
4,
Cuntas flechas pueden emanar de una caja de processo en un diagrama de

flujo?
5,
Cul es la diferencia entre un diagrama de flujo y un diagrama de flujo de da

tos?
B,
Dibuje un diagrama de flujo para un algoritmo de bsqueda binaria.
7.
Dibuje un diagrama de flujo para un algoritmo sencillo de ordenamiento por in

tercambio.
8.
Dibuje un diagrama de flujo para ia aproximacin de Newton-Raphson para el

clculo de la raz cuadrada.
9.
Cules son las tres principales razones por las que no se usan los diagramas
de flujo?
10.
Cules son las cuatro variantes principales de ios diagramas de flujo?
1 1 . Qu es un diagrama de Nassi-Shneiderman?
del diagrama de Nassi-Shneiderman?
Cul es un sinnimo comn
12.
Dibuje un diagrama de Nassi-Shneiderman para un algoritmo de bsqueda bi

naria.
13.
Dibuje un diagrama de Nassi-Shneiderman para un ordenamiento por inter

cambio sencillo.
14.
Dibuje un diagrama de Nassi-Shneiderman para el mtodo de Newton-Raph

son de aproximacin de la funcin raz cuadrada.
15.
Qu es un diagrama de Ferstl?
16.
Dibuje un diagrama de Ferstl para un algoritmo de bsqueda binaria.
17.
Dibuje un diagrama de Ferstl para un ordenamiento por intercambio sencillo.
www.FreeLibros.org
18.
Dibuje un diagrama de Ferstl para ei mtodo de Newton-Raphson de aproxi

macin de la raz cuadrada.
338
19.
En qu difiere un diagrama de Ferst! de un diagrama de flujo? Qu

mostrar que ei diagrama de flujo no pueda?
20.
Qu es un diagrama de Hamilton-Zeldin? Cul es un sinnimo de diagrama

de Hamilton-Zeldin? En dnde se desarroll?
21.
Dibuje un diagrama de Hamilton-Zeldin para un algoritmo de bsqueda binaria i
22.
Dibuje un diagrama de Hamilton-Zeldin para un ordenamiento por intercambio i

sencillo.
23.
Dibuje un diagrama de Hamilton-Zeldin para el mtodo de Newton-Raphson

para aproximar ia raz cuadrada.
24.
Qu es un diagrama PAD? Dnde se desarroll?
25.
Dibuje un diagrama PAD para un algoritmo de bsqueda binaria?
26.
Dibuje un diagrama PAD para un ordenamiento por intercambio sencillo.
27.
Dibuje un diagrama PAD para el mtodo de Newton-Raphson de aproximacin

de la raz cuadrada.
28.
Qu caractersticas tienen en comn los PAD y los diagramas de Ferstl?
29.
Qu es un diagrama de flujo de sistema? Para qu se usa?
30.
En qu fase del desarrollo de un sistema de informacin es probable que se

use un diagrama de flujo de sistema?
|[
31.
Qu es un diagrama HIPO? Dnde se desarroll?
|j
32.
Dibuje un diagrama HIPO que muestre el diseo de un programa para jugar ai

gato (tic-tac-toe).
33.
Qu es un diagrama de entrada-proceso-salida? Qu relacin tiene este

diagrama, conocido como PO por sus siglas en ingls, con el concepto HIPO?
34.
Dibuje un diagrama IPO para un algoritmo de bsqueda binaria.
35.
Dibuje un diagrama IPO para un ordenamiento por intercambio sencillo.
36.
Dibuje un diagrama IPO para ei mtodo de Newton-Raphson para aproximar la |

raz cuadrada.
37.
Qu es un diagrama de estructura?
puede
www.FreeLibros.org
38.
Cul es la diferencia entre un diagrama de estructura y un diagrama HIPO?
39.
Dibuje un diagrama de estructura para un programa sencillo que juegue gato.
40
Porqu resulta usualmente insuficiente usar el diagrama de estructura como

herramienta de modelado en el anlisis de sistemas?
41 _
Qu es un diagrama SADT? Cul es la diferencia entre un diagrama SADT

y un diagrama de flujo de datos?
42.
Qu es un diagrama de Bachman? Cul es a diferencia entre un diagrama

de Bachman y un diagrama de entidad-relacin?
43.
Qu es un diagrama de estructura de datos de DeMarco? Cul es la diferen

cia con un diagrama de entidad-relacin?
44.
Qu es un diagrama de estructura de datos de Jackson? Cul es la diferencia

con un diagrama de entidad-relacin?
www.FreeLibros.org
Para b e neficio de ias pe rso n a s de d istin to s tipos, la verdad cie n tfica d e biera
p re s e n ta rse en fo rm a s d ife re n te s, y co n sid e ra rse ig ualm ente cie n tfica , ya
sea que ap a re zca en ia form a robusta y de gran colorido de una ilustracin
fsica, o en ia te n uida d y p alidez de una expresin sim blica.
Jam es C lerk M axwell
D iscurso a la S eccin de Fsica y M atem ticas,
A so cia ci n B ritnica para e l D e sa rro llo de ia Ciencia, 1870
Ere este captulo se aprender:

1. Por qu la administracin necesita herramientas
propias,
2. Cmo dibujar diagramas PERT.
3. Cmo dibujar diagramas de Gantt.
4. Las relaciones entre herramientas de administracin
y otras herramientas de modelado.
www.FreeLibros.org
340
MODELADO PARA ADMINISTRACION 341
g1
INTRODUCCION
A u n q u e ste no es un libro sobre administracin de proyectos, es apropiado

hacer una pausa en este ltimo captulo sobre herramientas de modelado, para pre
sentar algunas que son tiles para administrar un proyecto de desarrollo de sise^gs; nos enfocaremos principalmente en ias herramientas de modelado conocidas
romo diagramas de PERT y de Gantt.
Por qu deben interesarte las herramientas de modelado de administracin?
varias razones posibles:
Existen
Adems de su papel como analista, tal vez tambin sea el administrador

del proyecto, y los analistas de nivel inferior y los programadores le repor
ten directamente. Podra desarrollar modelos administrativos para pre
sentarlos a ios niveles superiores de la administracin, o podra pedirle a
uno de sus subordinados que los desarrolle.
Como tcnico superior del equipo, el administrador dei proyecto podra

pedirle que desarrolle modelos administrativos. En este caso, usted sera
el administrador aprendiz, a quien ei administrador del proyecto recurre
para pedir ayuda y consejo sobre diversos asuntos de naturaleza tanto
administrativa como tcnica.
Incluso si no es responsable del desarrollo de los modelos es importante

conocerlos, pues reflejan la percepcin de ia administracin sobre cmo
debe estarse realizando su trabajo. Puede sacar sus propias conclusio
nes sobre s el proyecto tendr xito o no comparando ios modelos con su
propia percepcin de la realidad.
La organizacin del trabajo y la asignacin de personas a diversas activi

dades, proceso a menudo conocido como divisin del trabajo del proyec
to, usualmente ser paralela a la divisin tcnica dei sistema. Dado que
estar ntimamente involucrado con ia descomposicin dei sistema en sus
funciones y objetos de datos, podra tener influencia en la forma en que ei
proyecto se organice.1
En el resto del captulo se examinarn las herramientas de modelado adminis

trativo ms comunes, y veremos cmo tratan los asuntos importantes a los que se
enfrentan los administradores de proyectos. Se ver tambin cmo se relacionan
con las otras herramientas de modelado de sistemas que se discutieron en los lti
mos captulos.
www.FreeLibros.org
1 A veces es justo lo contrario. Com o dijo Q eorge M ealy, co n su ltor de IBM , acerca de algunos pro
yectos: La estructura del sistem a es isom orfa a la e stru ctu ra de la org a n iza ci n que lo cre a .
342
MODELADO PARA ADMINISTRACION
16.2
POR QUE REQUIERE MODELOS LA ADMINISTRACION?
Existen tres razones principales por las cuales la administracin de proyecto

requiere de modelos asociados con un proyecto de desarrollo de sistemas:
5
1.
Para estimar el tiempo, dinero y personal necesario para desarrollar 6i

proyecto.
2.
Para actualizar y revisar dichas estimaciones a medida que el proyecto

avanza.
3.
Para administrar las tareas y actividades de quienes laboran en el proyecto.
Las estimaciones de presupuesto son, desde luego, una actividad principal

los administradores en cualquier proyecto; en muchos proyectos de desarrollo
sistemas son an ms difciles pues cada uno es (o por So menos parece ser) unir
En el apndice B se discuten varias frmulas y mtodos para estimar la cantidad
trabajo a realizar en un proyecto y el nmero de personas que se ocuparn. Aun
con eso, la administracin necesita modelos grficos, de preferencia, por las mismas razones por las cuales son tiles en otros aspectos del anlisis de sistemaspara ver cundo estarn disponibles las personas para realizar las tareas del proyecto, qu suceder si no estn, etc. Examinaremos esto con ms detalle en la Seo-
cin 16.5 ,
|
Sin embargo, aun el mejor plan tiene probabilidades de fallar si se implanta a |
ciegas. Las circunstancias cambian continuamente durante un proyecto: los recu
ses crticos pudieran no estar disponibles en ei preciso momento en que se requie- )
ren; miembros importantes del personal pueden enfermarse o retirarse; ia estimacin |
original de ia cantidad de trabajo a realizar podra no ser exacta; el usuario anuncia |
de repente que necesita que el sistema arranque un mes antes de lo previsto; el ad- |
ministrador se da cuenta que el trabajo se est haciendo mucho ms lentamente de I
lo esperado. Por todo ello, para ei administrador es importante tener modelos que le ;
permitan explorar las consecuencias de cambios en sus planes.
Y, finalmente, el administrador no slo debe administrar tareas, sino personas.
Debe asegurarse que todos los analistas, programadores, diseadores y dems
miembros del personal estn haciendo lo que deben hacer, cuando deben hacerlo,
Por eso requiere herramientas de modelado que se enfoquen a las personas, ade
ms de herramientas que se enfoquen a las tareas.
16.3
DIAGRAMAS PERT
PERT es un acrnimo dado por las siglas en ingls de Tcnica de Revisin de

la Evaluacin de Programas. Originalmente se desarroll en los aos 60 como he
rramienta de administracin para el proyecto de submarinos Polaris de la fuerza na
www.FreeLibros.org
va| de los Estados Unidos; suele darse el crdito a Booz Alien (la empresa consulto, a Lockheed Aircraft y a la Marina por haber desarrollado el concepto. Los diaarTtas PERT se han utilizado am pliam ente en proyectos de la industria y el
gobierno desde entonces; muchos los conocen como diagramas de actividad.
En la Figura 16.1 se muestra un diagrama PERT tpico para un proyecto hipo
ttico. Cada rectngulo representa una tarea o actividad (es decir, un fragmento re
conocible de trabajo que debe hacerse). Los cuadros con esquinas redondeadas se
conocen como sealamientos y tienen un significado obvio dentro del contexto de un
proyecto tpico. Las lneas que conectan los cuadros muestran dependencias; es de
cir muestran qu actividades deben terminarse antes de comenzar otra. Las lneas
ms gruesas y obscuras que forman un camino contiguo del principio al final del pro
yecto representan el camino crtico, es decir, aquellas actividades cuyo retraso obli
gara al retraso del proyecto global (las actividades que no estn en e l camino crtico
tienen tiempo de ocio disponible; pueden comenzarse hasta despus de un tiempo
igual a ste luego de la fecha programada, si as se desea, sin afectar al proyecto en
conjunto).
Observe que el administrador del proyecto(o un subordinado) es quien determina cules tareas dependen de otras. En muchos casos, la dependencia se rela
ciona con los datos: la actividad N+1 requiere como entrada algo que se produce
como salida de la actividad N. En otros, la dependencia representa un punto de re
visin del proyecto (por ejemplo, ei sealamiento N pudiera ser una junta de revisin
administrativa en la que se debe aprobar la labor realizada hasta ese momento, an
tes de comenzar la actividad N+1).
Observe que el ejemplo de la Figura 16.1 es realmente trivial: contiene slo
diez actividades y termina cuando concluye la actividad de anlisis dei sistema.
Desde luego, un proyecto tpico contina an despus de terminarse la labor de an
lisis, e invierte una considerable cantidad de tiempo en el rea de diseo, codifica
cin, prueba, etc. De hecho, es probable que un proyecto tpico tenga varios cientos
de actividades que se mostraran en un diagrama PERT. Tai vez quepa en ia pared
de la oficina del administrador del proyecto, pero ciertamente no cabra de manera
conveniente en este libro.
De mayor importancia an es e hecho de que muchos proyectos identifican
actividades principales, las cuales posteriormente se dividen en otras menores. Por
ejemplo, la Figura 16.1 muestra una actividad etiquetada realizar actividades de
anlisis de sistemas. Como hemos visto en todo este libro, hay muchas cosas que
entran en esta clasificacin; de hecho, se esperara ver un gran diagrama PERT que
entre en detalles de estas subactividades. Como se vio en el concepto de diagra
mas de flujo de datos por niveles en el Captulo 9, podra imaginarse el concepto de
diagramas PERT por niveles para ayudar a organizar la complejidad de varios cien
tos, o incluso miles, de tareas en un proyecto grande.
www.FreeLibros.org
344
Plan de proyecto de la corporacin XYZ

1/4
Figura 16.1: Diagrama PERT

Note, por cierto, que el diagrama PERT se enfoca a las actividades y sus inter
dependencias, pero dice poco o nada acerca de otros aspectos del proyecto que son
de inters para un administrador. No indica, por ejemplo, qu persona o grupo debe
llevar a cabo las diversas actividades; tampoco dice nada explcitamente acerca de
la cantidad de tiempo (o nmero de das-persona) que cada actividad requiere. Y
tampoco muestra qu productos o salidas se obtienen por cada actividad. Parte de
esta informacin, sin embargo, se enfatiza en los modelos de administracin que se
discuten a continuacin.
Finalmente, observe que el diagrama PERT parece suponer que todo se mue
ve hacia adelante, como indica la secuencia de izquierda a derecha de las activida
des. De hecho, a menudo es necesario volver atrs y rehacer algunas de las
actividades anteriores si se encuentran posteriormente. Este tipo de actividad itera
tiva no se muestra bien en un diagrama PERT tpico.
Por otro lado, ei diagrama PERT s muestra, de manera clara, el hecho de que
muchas actividades pueden llevarse a cabo paralelamente en un proyecto real. Esto
es importante porque muchos de ios otros modelos implican fuertemente que las ac
tividades deben hacerse secuencialmente (vase por ejemplo, la Figura 5.1). Los
administradores del proyecto generalmente quieren aprovechar lo ms posible el
paralelismo, pues puede ayudar a reducir el tiempo necesario para el proyecto.
www.FreeLibros.org
g4
d ia g r a m a s d e g a n t t
Un segundo tipo de modelo de administracin de proyectos es el diagrama de

Gantt, que a veces se conoce como itinerario de tareas. La Figura 16.2 muestra un
diagrama de Gantt para el mismo proyecto hipottico que se us en la Figura 16.1.
Observe que cada actividad se muestra con una indicacin de cundo comienza y
cundo termina; el rea sombreada indica tiempos de ocio posible, mientras que las
activdades encerradas en rectngulos blancos pertenecen al camino crtico.
r"
2/1
1/4
2/29
3/28
4/25
Leas**
>
Comienzo
T a b la r con, j re p re s e n ta n te s de le s u s u a rio s
D e s a rro lla r e s c a ra n o s in ic ia le s de p ro y e c to s
les de lo s u s u a rio s
4?> P re s e n ta r e s tu d io de fa c tib ilid a d
j R e visa r! o ro e s d im ie n to s
r e g la m e n ta rio s
In v e s tirs e - a ita r":a tiv a s fin a n c ie ra s

"Realizar a c tiv id a d e s de a n lis is de s is te m a s
jL
y
P re s e n ta r re s u lta d o s d e l anl sis

de s is te m a s
i
i
Figura 16.2: Diagrama de Gantt
Como puede verse, el diagrama de Gantt presenta en gran medida el mismo ti

po de informacin que el diagrama PERT; su principal diferencia es el hecho de que
muestra la duracin de cada actividad,2 mientras que ei diagrama PERT no lo hace.
Dado que es una representacin un tanto ms tabular del proyecto, a menudo puede
usarse para presentar una gran cantidad de informacin en una forma relativamente
compacta.
2 No hemos indicado exactam ente cm o determ ina ei a d m in istra d o r dei proyecto la duracin de ca
da tarea. En el caso se ncillo puede e stim a rla por s so lo o pedir a quienes realizan el trabajo que
hagan sus propias estim aciones. Si la tarea es grande y com pleja, g e n eralm ente se divid ir en subactividades ms pequeas. En el Apndice B se dan f rm u la s para e stim a r el tiem po y recursos
be programacin, entre otra s cosas.
www.FreeLibros.org
346
16.5
HERRAMIENTAS ADMINISTRATIVAS ADICIONALES DE MODELADO
Adems de las dos herramientas principales de modelado que se analizaron

anteriormente, a ios administradores de proyectos les agrada usar diagramas y t.
blas adicionales para ayudarles a estar al tanto de su labor. Por ejemplo, en lug8r
de mostrar las tareas como se hizo en la Figura 16.2, se puede fcilmente producir
un diagrama que muestre la actividad de cada recurso dei proyecto.3 La Figura 16.3
muestra un listado de recursos para el mismo proyecto hipottico. Obviamente, esto
es til para estar al tanto de las diversas actividades de las que es responsable cada
miembro del proyecto. De manera similar, podra decidirse que resultara conve
niente tener un listado tabular de las diversas actividades del proyecto, tal vez como
indicacin de cul es la fecha ms temprana en la que cada actividad puede iniciar,
y la fecha ms tarda en la que puede iniciar sin perturbar otras tareas ni retrasar la
terminacin del proyecto.
Debiera ser evidente que la informacin de la Figura 16.4 es otra visin ms
de los aspectos administrativos del proyecto; debe ser compatible con otros aspec
tos, como los diversos modelos de DFD, DER y DTE para un sistema de informacin
son compatibles entre s. De hecho, habiendo creado cualquiera de los modelos de
administracin del proyecto, debera poderse derivar los dems de manera mecni
ca; regresaremos a este tema en la Seccin 16.7.
16.6
RELACIONES ENTRE HERRAMIENTAS DE ADMINISTRACION DE PRO

YECTOS Y OTRAS HERRAMIENTAS DE MODELADO DE SISTEMAS
Cul es la relacin entre los diagramas PERT, diagramas de Gantt y los di

versos modelos del sistema (DFD, DER, DTE, etc.) que hemos discutido a lo largo
de este libro? La relacin ms fuerte parece ser la existente entre el diagrama
PERT y ei diagrama de flujo de datos: ambos muestran actividades (o funciones)
que se estn llevando a cabo, y ambos muestran algo acerca de su interaccin. Sin
embargo, el DFD no muestra nada sobre la secuencia en la que dichas funciones se
realizan, mientras que el diagrama PERT s muestra cules actividades pueden rea
lizarse de manera concurrente y cules deben realizarse de manera secuencia!.
Adems, vimos que el diagrama PERT no muestra la salida producida por cada acti
vidad, ni indica las entradas requeridas por cada actividad.
Como vimos en el Captulo 5, los DFD se pueden usar para mostrar activida
des en un proyecto, al igual que las entradas y salidas, por lo cual sera posible utili
zarlo como herramienta de modelado en lugar del diagrama PERT. Sin embargo, ia
mayora de los administradores de proyectos quisieran que el diagrama tuviera ano
taciones para mostrar el camino crtico; y necesitaran informacin adicional, tal co3 En la m ayor parte de los p royectos los recursos que m s nos interesa m anejar son las personas, |
pero un recurso tam bin pede ser una m quina, un cu a rto de co n fere n cia s o cu a lq u ie r otra cosa j:
q ue sea (1) n ecesaria para el p royecto en algn m om ento dado y, (2) su ficie n tem e n te escaso como
p ara que se necesite adm inistrar.
www.FreeLibros.org
^0 la duracin de cada actividad y las personas que estaran trabajando en cada

na. De aqu que es ms comn ver la combinacin del diagrama PERT clsico junlo con el de Gantt y el calendario de recursos que discutimos anteriormente.
1/4
2/1
2/29
3/28
4/25
Bety
| D e s a rro lla r esce n a n o s in ic ia le s d p ro y e c to s
j
David
P re s e n ta r e s tu d io de fa c tib ilid a d
R evis; r p ro c e d im ie n to s re g la m e n ta rio s
Investiga-- a lte rn a tiv a s fin a n c ie ra s
i
|
V ip ita r se d s de u s u a rio s
Mara
P re se n ta r e s tu d io de fa c tib ilid a d ;
R ealizar a c tiv id a d e s de a n lis is de s is te m a s
j
^
Com ienzo
i
i i i i i i s de u s u a rio s
R ealizar a c tiv id a d e s de a n lis is d e s is te m a s
Carol
Ha 3lar con re p re s e n ta n te s de u s u a rio s
Jos
Figura 16.3: Listado de recursos

Es ms significativo an el hecho de que las actividades que se muestran en
un diagrama PERT tpico son las diversas actividades de dibujar DFD, DER, etc.
As, mientras que la Figura 16.1 muestra una actividad de alto nivel como realizar
anlisis de sistemas", un diagrama PERT realista probablemente mostrara una lista
de actividades como la siguiente:
www.FreeLibros.org
Dibujar diagramas de flujo de datos para el nuevo sistema
Dibujar diagramas de entidad-relacin para el nuevo sistema
348
Dibujar diagramas de transicin de estados para ei nuevo sistema

Desarrollar el diccionario de datos para el nuevo sistema
Escribir las especificaciones del proceso para las burbujas de njy8|
inferior
Balancear los modelos
Hacer los clculos de costo-beneficio
Etc.
Tarea
Das
Inicio ms
temprano
Final ms
temprano
Inicio ms
tardo
Fina! ms
tardo
Comienzo
1/4/88
1/4/88
1/4/88
1/4/88
Hablar con los

representantes de los
usuarios
1/4/88
1/11/88
1/19/88
1/26/88
Desarrollar escenarios
iniciales
20
1/4/88
2/1/88
1/4/88
2/1/88
Visitar sedes de
usuarios
1/11/88
1/15/88
1/26/88
2/1/88
Presentar estudio de
factibilidad
2/1/88
2/1/88
2/1/88
2/1/88
Revisar procedimientos
reglamentarios
10
2/1/88
2/15/88
2/15/88
2/29/88
Investigar alternativas
de (mandamiento
10
2/1/88
2/15/88
2/15/88
2/29/88
Realizar actividades
de anlisis de sistemas
20
2/1/88
2/29/88
2/1/88
2/29/88
Presentar resultados
2/29/88
2/29/88
2/29/88
2/29/88
Figura 16.4:
Listado de tareas
Como veremos en la parte IV, las herramientas de modelado para los diagra
mas de flujo de datos y otros se utilizan para construir una serie de modelos diferen
tes del nuevo sistema. As, es probable encontrar las siguientes actividades de alto
nivel:
www.FreeLibros.org
Desarrollar modelos ambientales
Desarrollar borradores del modelo de comportamiento
Retinar modelo de comportamiento

Desarrollar modelo de implantacin dei usuario
Hasta aqu, ninguno de estos trminos tiene sentido; en el Captulo 18 se dis
cute el modelo ambiental, el de comportamiento en los Captulos 19 y 20, y el de im
plantacin del usuario en el Captulo 21.
El punto principal a recordar es que las actividades que se muestran en los
diagramas PERT y Gantt corresponden a las actividades de construccin de mode
les que hemos discutido en todo este libro. Desde luego, un verdadero diagrama
pERT de un proyecto, que cubre todo su ciclo de vida, debe tambin mostrar las ac
tividades de diseo, programacin, prueba, conversin de bases de datos e instala
cin.
EL ASUNTO DE LA AUTOMATIZACION
-6.7
De ia breve discusin sobre herramientas de administracin de proyectos de

este captulo deben ser evidentes tres cosas:
1.
Varias de las herramientas Involucran grficos; por ello, para que funcio
nen, alguien o algo tiene que dibujar las figuras.
2.
Para un proyecto real grande, ios modelos se vuelven inmensos. Y a me

dida que las cosas cambian (cosa que inevitablemente sucede durante un
proyecto), los modelos tienen que volverse a dibujar. Esto implica una tre
menda cantidad de trabajo.
3.
Los modelos se relacionan todos entre s por lo que, teniendo suficiente

informacin acerca del proyecto, se debiera poder crear un diagrama
PERT o de Gantt, o bien un itinerario de recursos, adems del apoyo na
rrativo adecuado.
Esto lleva a una conclusin muy obvia: sera de tremenda ayuda si las herra
mientas de administracin de proyectos pudieran computarizarse. Y de hecho, lo
han sido; existe una variedad de paquetes de administracin de proyectos disponi
bles para computadoras personales, adems de para minicomputadoras o mainframes.4 As que un administrador de proyecto de inicios de los aos 90 sera tonto si
administrara cualquier proyecto, excepto ios muy triviales, sin tales herramientas au
tomatizadas. Adems de las actividades de modelado simples discutidas en este ca
ptulo, generalm ente las herram ientas com putarizad as tienen las siguientes
caractersticas:
4 Los diagram as que se m uestran en este ca p tulo se hicieron con M cP roject en ia com putadora
Apple M acintosh. En las PC IBM hay una variedad un ta n to m ayor de dnde escoger.
www.FreeLibros.org
350
M O D E L A D O PARA ADMINISTRACION
La posibilidad de especificar el costo de cada recurso del proyecto. Estt |

es de gran ayuda en las actividades de presupuesto.
La posibilidad de describir el calendario con el que deber trabajar el pQ.

yecto (por ejemplo, vacaciones, horas hbiles normales, etc.). De hecho
algunos programas permiten que cada recurso tenga su propio calenda'
rio, y toman en cuenta que las distintas personas tienen diferentes pero.
dos de vacaciones, etc.
La posibilidad de programar hacia atrs o hacia adelante. En un proyecto

normal, la fecha de inicio es conocida, y el objetivo es estimar cundo estar terminado. Pero en otros casos se conoce la fecha de finalizacin
(porque se ha impuesto externamente una fecha lmite para su conclnsin), y el objetivo es determinar ia ltima fecha posible para el inicio do
cada una de las actividades.5
La posibilidad de ofrecer una variedad de reportes en diversos formatos.
La posibilidad de tener interfaces con otros programas (por ejemplo, hojas

de clculo y programas grficos).
La posibilidad de comparar el desempeo real contra el desempeo esti

mado, para que el administrador pueda ver qu tan precisas son sus e&:maciones y tal vez usar esto como medio para revisarlas en el futuro.
Para los proyectos pequeos o medianos suele ser bastante adecuado un paquete de administracin de proyectos basado en una PC; entre los ms populares
estn Microsoft Project, Timeline y el Harvard Project Manager. Para los proyectos
grandes, donde se administran miles de tareas y cientos de recursos, pudiera requerirse una computadora ms grande. Adems, muchas organizaciones integran los
planes de los proyectos individuales en modelos y presupuestos agregados; por ello
es importante que todos usen sistemas de modelado basados en PC que sean compatibles, o bien que compartan algn sistema mayor basado en un mainframe.
1 6 .8
|
|
!:
[
|
(
|
RESUMEN
Obviamente, hay ms sobre la administracin de proyectos que dibujar diagra- |

mas PERT. Un administrador de proyecto tpico tiene que ver con contrataciones y
despidos, negociaciones y motivacin, adems de comunicacin con programadores, analistas, usuarios y ios niveles administrativos superiores. Sin la ayuda de las
herramientas de modelado del tipo que se describieron en este captulo es prctica
mente imposible que siga la pista de todas las actividades, costos y recursos involu
crados.
www.FreeLibros.org
5 A T om DeM arco ie gusta llam arle a esto: pedirle deseos al pasado .
REFERENCIAS
r
philip Metzger, Managing a Programming Project, 2* edicin, Engiewood Ciiffs,

N.J.: Prentice-Hall, 1983.
Tom Giidersleeve, Successful Data Processing Systems Analysis, 2 edicin,

Engiewood Ciiffs, N.J.: Prentice-Hall, 1985.
3,
Marvin Gore y John Stubbe, Elements of Systems Analysis, 3a edicin Dubuque, lowa: William C. Brown, 1983.
PREGUNTAS y e j e r c ic io s
1
D tres razones por las cuales los administradores de proyectos requieren mo

delos asociados con el proyecto de desarrollo de sistemas.
2. De qu es acrnimo PERT?
3. D una definicin breve de diagrama PERT.
4. Qu es el camino crtico en un diagrama PERT?
Por qu es importante?
5. Cul informacin no muestra el diagrama PERT acerca de un proyecto?

6.
D una breve definicin de diagrama de Gantt. Qu sinnimo tiene?
7.
Qu informacin proporciona un diagrama de Gantt que ei de PERT no pro

porcione?
8. D una definicin breve de listado de recursos.

9.
Qu relacin existe entre diagramas PERT, de Gantt y modelos de DFD de

un sistema?
10.
Por qu es til tener herramientas automatizadas para producir diagramas

PERT y de Gantt?
www.FreeLibros.org
PARTE
\:
EL PROCESO DE ANALISIS
EL MODELO ESENCIAL
B usca la e se n cia de una cosa, sea un punto de d o ctrin a , de p r ctica , o de

in te rp re ta ci n .
M arco Aurelio, M editaciones VIH

1. Los cuatro principales modelos de sistemas en el
ciclo de vida.
2. Por qu es peligroso modelar el sistema actual del
usuario.
3. La distincin entre modelos esenciales y de
implantacin.
4. Cmo definir en trminos lgicos un modelo de
implantacin.
E n la seccin anterior (Captulos 9 a 16), examinamos varias herramientas

de modelado que todo analista debe tener a su disposicin. Sin embargo, dadas
estas herramientas, qu tipo de modelo debemos construir? Debemos cons
truir un modelo de la implantacin actual dei sistema del usuario? Debemos
construir uno de la implantacin nueva que se propone? Un modelo indepen
diente de la tecnologa de implantacin? Las tres cosas? Estas preguntas se
contestan en los siguientes captulos.
www.FreeLibros.org
352
EL MODELO ESENCIAL 353
Comenzamos por examinar el enfoque del anlisis estructurado clsico para

esarroliar modelos de sistemas. Como veremos, hay grandes problemas con este
enfoque. Luego, discutiremos el modelo esencial, que es el modelo de anlisis de
s is t e m a s primario que recomendamos construir.
Finalmente, discutiremos algunas
reglas para la construccin de un modelo esencial a partir de un modelo de implanta
cin existente.
ENFOQUE D E L MODELADO CLASICO Y P O R QUE NO FUNCIONO
17-1
EL
17,1,1
Los cuatro m odelos de sistem as
Cuando se introdujo el anlisis estructurado, comnmente se argumentaba

que el analista debera desarrollar los cuatro modelos distintos que se muestran en
la Figura 17.1.
www.FreeLibros.org
Figura 17.1: Los cuatro modelos de sistemas
354
EL MODELO ESENCIAL
El modelo fsico actua l es un modelo del sistem a que actualm ente est
empleando el usuario. Puede ser un sistema manual, automatizado o mezcla den*,
bos. Tpicamente, los procesos (burbujas) del diagrama de flujo de datos paras:
sistema fsico actual se titulan con nombres de personas, de unidades organizado!
nales o de sistemas de cmputo que hacen ia labor de transformar entradas en sali
das. En la Figura 17.2 se muestra un ejemplo. Note tambin que los flujos de datos
tpicamente muestran la forma fsica de transporte de datos entre burbujas; adems
los almacenes de datos pueden representarse con carpetas, archivos de cinta mag
ntica o alguna otra tecnologa.
El modelo lgico nuevo es un modelo de los requerimientos puros o esenciales
del sistema nuevo que el usuario quiere. En el caso ideal (desde el punto de vista
del analista), es igual que el modelo lgico actual; es decir, contiene las mismas fun
ciones y datos. Esta situacin es factible si el usuario est completamente satisfe
cho con la funcionalidad del sistema actual, pero no con su implantacin.1 En ig
Figura 17.2: Un m odelo de sistem a actual
www.FreeLibros.org
1 Existen m uchas razones p o sib le s para esto. El sistem a puede estar im plantado en hardware ob
soleto o cuyo fabricante ya no exista. O la respuesta o el rendim iento del sistem a podran no ser
los adecuados. O ei usuario p u diera pedir que algunos de los datos que se m antienen manualmen-
mayora de los casos, sin embargo, el usuario pedir funciones adicionales: Aprovec'nando la ocasin, no podra aadir otra transaccin para cubrir la siguiente situacn... O el usuario podra pedir que ei sistema maneje nuevo tipo de datos. Por
eSo, aunque un 80% a 90% del modelo lgico nuevo pudiera parecer idntico al ac
tual. es probable que haya algunos cambios y adiciones por lo menos.
El modelo lgico actual es el modelo de los requerimientos puros o esenciales
realiza el sistema actual dei usuario. De esa forma se eliminan los detalles de
la implantacin arbitraria, y el modelo que resulta muestra lo que el sistema hara si
hubiera disponible una tecnologa perfecta.2 En la Figura 17.3 se muestra un ejem
plo de un modelo lgico actual.
qUe
Figura 17.3: El m odelo l gico actual
te (por ejem plo, archivos en papel) se com putaricen. O, com o es cada vez ms com n hoy en da,
el software podra e sta r tan pobrem ente docum entado que ya no se pueda m an te n e r o m odificar.
www.FreeLibros.org
2 Se puede Interpretar por te cn olog a perfecta el hardw are que no cuesta nada, no consum e ener
ga, no genera calor, trab a ja a velocidad infinita (es decir, rea liza cu a lq u ie r clcu lo instantneam en
te), alm acena una cantidad Infinita de datos que se pueden recuperar em pleando cero tiem po, y
que jam s se descom pone ni com ete errores.
356
EL MODELO ESENCIAL
El nuevo modelo fsico es un modelo que muestra las limitaciones de implanta,

cin impuestas por el usuario. Una de las limitaciones ms importantes es la det
minacin de la frontera de automatizacin (es decir, la determinacin de cules
funciones del nuevo sistema se automatizarn y cules se harn manualmente). gj
nuevo modelo fsico corresponde a lo que ahora llamamos el modelo de implanta
cin del usuario, que se discute con ms detalle en el Captulo 21.
17.1.2
Por qu no fu n c io n el enfoque clsico
El enfoque clsico descrito anteriormente se basaba en tres suposiciones prin

cipales:
1.
El analista pudiera no estar familiarizado con el rea de aplicacin o del

negocio: tal vez sea un experto en tecnologa computacional, pero con
slo conocimientos superficiales de ia banca, seguros, control de inventa
rios o cualquiera que sea ei rea en la que el usuario trabaja. Por ello es
importante que el analista comience con un modelo fsico actual corno
medio para educarse. El modelo que dibuje ser relativamente fcil de
verificar, porque contendr varios sealamientos fsicos que pueden ob
servarse en el ambiente fsico actual del usuario. Habiendo reunido esta
informacin, el analista puede continuar, transformando el modelo fsico
en un modelo lgico.
2.
El usuario pudiera estar renuente o imposibilitado para trabajar con el

nuevo modelo lgico al principio del proyecto. La razn ms comn de
esto es la duda sobre la capacidad del analista para desarrollar un mode
lo lgico del nuevo sistema. Aun si el analista cree que es un experto en
el rea de negocios del usuario, ste pudiera no estar de acuerdo. Por
qu he de confiarle el diseo de un nuevo modelo para m, si ni siquiera
entiende cmo trabaja mi negocio actualmente? , podra preguntarse.
Adems, algunos usuarios tienen dificultad con un modelo abstracto del
sistema sin sealamientos reconocibles; podran requerir un modelo del
sistema fsico actual como manera de familiarizarse con el proceso de
anlisis estructurado y asegurar que el analista no haya dejado de tomar
en cuenta algo. (Una alternativa es el enfoque de prototipos, que se dis
cute en el Captulo 5.)
3.
La transformacin de un modelo lgico actual en un modelo lgico nuevo

no requiere mucho trabajo y, en lo particular, no requiere de mucho traba
jo desperdiciado. Como se indic anteriormente, el usuario tpicamente
aadir algunas nuevas funciones, o nuevos datos, al sistema que ya tie
ne, pero en su mayor parte (si no todo) el sistema lgico (o esencial) exis
tente permanece intacto.
www.FreeLibros.org
Estas suposiciones de hecho resultaron ser correctas en muchos proyectos.

Sin embargo, ignoran un peligro mucho mayor: el proceso de desarrollar un modelo
del sistema actual puede requerir tanto tiempo y esfuerzo que el usuario se frustre e
impaciente y termine por cancelar el proyecto. Para darse cuenta de esto, se debe
;gtier en mente que:
Algunos usuarios (y algunos administradores y programadores-analistas)

consideran cualquier tipo de anlisis de sistemas como una prdida de
tiempo, es decir, lo consideran una forma de descansar hasta que el
verdadero trabajo del proyecto se presente (es decir, la codificacin).
Muchos usuarios comprensiblemente dudan de los mritos que pueda te

ner el modelado cuidadoso de un sistema que, por definicin, se superar
y reemplazar como resultado del desarrollo del nuevo sistema.
El problema ocurre ms frecuentemente porque el analista se distrae con la ta

rea de modelar el sistema actual y empieza a pensar en l como un fin en s mismo.
As, en lugar de slo dibujar el o los DFD y documentar slo unas cuantas especifi
caciones clave, a menudo dibuja todos los DFD y documenta cada especificacin de
proceso, a la vez que desarrolla un diccionario de datos completo.
Desafortunadamente, este enfoque casi siempre involucra un gran desperdicio
de tiempo. De hecho, normalmente podr esperarse que hasta un 75% del modelo
fsico se deseche en la transicin del modelo fsico al modelo lgico actual; o, dicho
de otra manera, el modelo fsico actual es tpicamente tres o cuatro veces ms gran
de que el modelo lgico actual. Esto se debe a la redundancia (el que la misma fun
cin se lleve a cabo en varias partes diferentes del sistem a y se dupliquen o
tripliquen varios datos), y a la verificacin, validacin y revisin de errores que son
apropiadas en el sistema fsico actual pero no en el sistema lgico actual.3
Todo esto pudiera parecer bastante obvio para el lector casual. Sin embargo,
proyecto tras proyecto, se ha observado que ios analistas se involucran tanto en el
proceso de modelar que olvidan el objetivo ltimo del usuario: producir un sistema
que funcione. Como lo seala Steve McMenamin (coautor de [McMenamin y Palmer,
1984], Las burbujas no se compilan.4
3 Sin im portar si se est construyendo un m odelo lgico (esencial) o fsico (de im plantacin), usuarnente resulta apropiado realizar alguna revisin de errores en los datos que llegan a l sistem a des
de el mundo exterior. Sin em bargo, ai tran sm itir ios datos de un lugar a otro dentro del sistem a, el
modelo lgico (esencial) no revisa errores, pues supone que el sistem a se realizar con tecn olog a
perfecta. En el m odelo fsico (de im plantacin), sobre to d o un m odelo del sistem a fsico actual, ia
revisin de errores es vital pues (1) parte del proceso es propenso a errores, sobre todo si lo llevan
a cabo hum anos, (2) el transporte de datos de un proceso a otro es propenso a errores, dependien
do del m edio de com unicacin que se use y, (3) ei alm ace n a d o y recuperacin de datos de los al
macenes fsicos pudiera ser una actividad propensa a errores.
4 Algn da s se com pilarn las burbujas. Es decir, la co m b in a ci n de diagram as de flu jo de datos,
diccionarios de datos y e sp e cificaciones rigurosas de procesos pueden co n ve rtirse en e n tradas de
un generador de cdigo que produzca program as ejecutables. Sin em bargo, aun en este caso, ei
esfuerzo de producir un m odelo fsico detallado es un d e sp e rd icio de tiem po. Nadie quiere una r
plica com putarizada del sistem a actual.
www.FreeLibros.org
358
EL MODELO ESENCIAL
Consecuentemente, este libro recomienda que el analista evite modelar el sjs.

tema actual de ser posible. Las herramientas de modelado que se discuten en i*
Parte II deben usarse para comenzar, tan pronto como sea posible, a desarrollar un
modelo del nuevo sistema que el usuario desea. Este nuevo sistema, conocido en
los libros clsicos de anlisis estructurado como el nuevo sistema lgico, se conoce
aqu como el modelo esencial del sistema.
Ocasionalmente existir alguna situacin en la que el analista deba construir
un modelo del sistema actual del usuario; esto sucede, por ejemplo, si el analista ne
cesita modelar el sistema fsico actual para poder descubrir los procesos esenciales
Esta situacin se discute ms a fondo en la Seccin 17.3 .
17.2
EL MODELO ESENCIAL
17.2.1
Qu es
El modelo esencial del sistema es un modelo de lo que el sistema debe hacer

para satisfacer los requerimientos del usuario, diciendo lo mnimo posible (de prefe
rencia nada) acerca de cmo se implantar. Como se mencion antes, esto significa
que nuestro modelo del sistema supone que se tiene disponible una tecnologa per
fecta y que se puede obtener fcilmente y sin costo.
Especficamente, esto significa que cuando el analista habla con el usuario
acerca de los requerimientos del sistema, debe evitar describir implantaciones espe
cficas de procesos (burbujas en un diagrama de flujo de datos) en el sistema; es de
cir, no debe mostrar las funciones del sistema que estn siendo realizadas por
humanos o por sistem as de cmputo existentes. Como io ilustran las Figuras
17.4(a) y (b), stas son opciones arbitrarias de cmo podra implantarse el sistema;
pero esta decisin debera retrasarse hasta que haya comenzado la actividad de di-
www.FreeLibros.org
Figura 17.4(a): Modelo de cm o har su labor una funcin del sistema
seo dei sistema.5 La Figura 17.4(c) muestra un modelo esencial ms apropiado de

l0 qUe la funcin del sistema debe realizar sin importar su implantacin final.
Lo mismo se da para los flujos y almacenes de datos: el modelo esencial debe
ei contenido de los flujos o almacenes de datos, sin describir el medio (por
ejemplo, disco o cinta) u organizacin fsica de ios datos.
describir
17.2.2
D ificultades en la c o n stru cci n de un m odelo esencial
Aunque las reglas anteriores parecen simples y obvias, a menudo resulta muy
difcil eliminar completamente todos los detalles de la implantacin en el modelo
e se n cia l. Los ejemplos ms comunes de detalles de implantacin son:
Secuenciado arbitrario de ias actividades en un modelo de flujo de datos.

El nico secuenciado en el diagrama de flujo de datos debe ser el que re
quieren los datos (por ejemplo, la burbuja 2 puede requerir un dato produ
cido por la burbuja 1 y por tanto no trabajar sino hasta que aquella haya
terminado) o los acontecimientos externos al sistema.
Archivos innecesarios, es decir, los almacenes de datos que no se reque

riran de existir una tecnologa perfecta. Los archivos temporales (o inter
medios) se requieren en un modelo de implantacin porque los procesos
estn programados para hacer su trabajo en distintos tiempos (por ejem
plo, un programa nocturno por lotes produce un archivo que ei sistema en
lnea diurno emplea); tambin se introducen para propsitos de respaldo
y recuperacin, porque la tecnologa de implantacin es propensa a erro
res, as como las personas que operan las computadoras.
\
ta rje ta s d e tie m p o s
\
fn rm 2 tn
- - E S T R O D E E M P L E A D O S (cin ta )
CO M PUTADORA\
ENCARGADA,
j
re p o rte de s a la rio s
Figura 17.4(b): Otro m odelo de cm o se realizar la fu ncin del sistem a
www.FreeLibros.org
5 Un trm ino popular para referirse a esto es aplazam iento constructivo . MI colega Steve W eiss
prefiere dierim iento seguro y es, de hecho, el p rincipio en el cual se basa ei enfoque descendente.
360
EL MODELO ESENCIAL
Figura 17.4(c): Un m odelo de cul es la fu ncin del sistem a
17.2.3
Revisin de errores y validacin innecesarias de datos y procesos dentro

del sistema. Dichas actividades de validacin se necesitan en un modelo
de implantacin, porque se debe trabajar con procesos propensos a erro
res (por ejemplo, algunas funciones las realizan humanos, que son nota
blem ente propenso s a errores) y canales ruidosos de datos entre
procesos,
Datos redundantes o derivados. A veces se incluyen datos redundantes

en los almacenes de datos para propsitos de eficiencia; aunque esto
usualmente es razonable, debe hacerse durante la fase de diseo del pro
yecto, y no durante el modelado de las funciones y datos esenciales.
Adems, sin darse cuenta, el analista puede incluir datos que sean derivables o calculables a partir de los valores de otros datos.
Com ponentes del m odelo esencial
El modelo esencial consiste en dos componentes principases:

1.
Modelo ambiental
2.
Modelo de comportamiento
El modelo ambiental define la frontera entre el sistema y el resto del mundo

(es decir, el ambiente en el cual existe el sistema). Esto se discute con ms detalle
en el Captulo 19. Como veremos, consiste en un diagrama de contexto, una lista de
acontecimientos y una descripcin breve del propsito del sistema.
El modelo de comportamiento describe el comportamiento que del sistema se
requiere para que interacte de manera exitosa con el ambiente. Los captulos 20 y
21 describen una estrategia para derivar el modelo del comportamiento; el modelo
www.FreeLibros.org
otlsste en los ya familiares diagramas de flujo de datos, de entidad-relacin, de

Yatisicin de estados y diccionarios y especificaciones del proceso que se han dis
i d o anteriormente en el libro.
73
QUE HACER SI SE DEBE CONSTRUIR UN MODELO DE

IMPLANTACION
Como se mencion en este captulo, existen circunstancias en las cuales po

dra ser deseable o necesario construir un modelo de implantacin antes de construir
ei modelo esencial del sistema. Tpicamente, esto se deber a que el usuario no es
t convencido de que se entiende su negocio lo suficientemente bien como para mo
delar un sistema nuevo, o porque el analista mismo haya decidido que necesita
estudiar el ambiente actual antes de proponer un sistema nuevo.
Si decide proceder de este modo, lo principal a recordar es que su primer ob
jetivo es llegar a un entendimiento y una visin generales del sistema existente. No
se trata de documentar el sistema actual con detalle. Asi, probablemente sea til o
apropiado crear uno o ms niveles de diagramas de flujo de datos del sistema ac
tual. Probablemente sea apropiado generar un diagrama de entidad-relacin y po
dra resultar til escribir las especificaciones del proceso para algunas de las
funciones ms crticas (u obscuras) del sistema. Podra ser til reunir algunos de los
documentos fsicos que representaran un diccionario de datos fsico. Pero no inten
te escribir especificaciones de proceso para todas las funciones, ni trate de desarro
llar un diccionario de datos completo para el sistema existente.
Cuando haya terminado de desarrollar el modelo de la implantacin actual, su
siguiente tarea ser definirlo en trminos lgicos (es decir, eliminar cuantos detalles
de implantacin sea posible). Esto usuaimente abarcar los siguientes pasos:
Buscar y separar flujos esenciales que hayan sido empaquetados de ma

nera arbitrara en el mismo medio. Por ejemplo, podra encontrarse con
que en el sistema actual diversos datos se transmiten juntos de una com
putadora a otra mediante algn enlace comn de telecomunicaciones; o
que varios datos no relacionados se copian a papel para transmitirse a di
versas funciones.
Buscar flujos empaquetados o agregados que se envan a burbujas (que

representan a personas, computadoras, etc.) que no requieren de todos
ios datos que hay en dichos flujos. La Figura 17.5(a) muestra un proceso,
CALCULAR FACTOR FRAMMIS, que requiere slo de un dato X; mien
tras tanto, otro proceso, CALCULAR FACTOR-W, requiere slo del dato
Y. Por conveniencia, la implantacin actual ha empaquetado X y Y en un
dato agregado Z; la definicin de este modelo en trminos lgicos resulta
ra en el diagrama de flujo de datos que se muestra en la Figura 17.5(b),
www.FreeLibros.org
362
EL MODELO ESENCIAL
Figura 17.5(a): M odelo fsico
Distinguir entre ei trabajo esencial realizado por un proceso y a identifica \

cin del procesador que aparece en el modelo de implantacin. El proce
sador puede ser una persona o una computadora, o alguna otra forma de
tecnologa; un procesador individual podra estar ejecutando fragmentos
de uno o ms procesos esenciales, o bien de mltiples procesos esencia
les en su totalidad. Como veremos en el Captulo 20, los procesos esen
ciales deben agruparse si son iniciados por el mismo acontecimiento |
externo.
?
Eliminar procesos cuyo nico propsito sea transportar datos de un lugar

a otro dentro del sistema. Adems, elimine las burbujas responsables de
entradas y salidas fsicas entre el sistema y el ambiente exterior. El modlo fsico de un sistema podra mostrar, por ejemplo, una funcin de corresponsala o mensajera; debe eliminarse del modelo esencial. Muchos
DFD fsicos tienen procesos con nombres como "obtener entradas del
usuario o imprimir reporte ; tambin deben eliminarse.
Eliminar procesos cuya labor sea verificar datos que se producen y usan
dentro del sistema. Dado que en el modelo esencial se supone una tec- j
nologa perfecta, esa verificacin y revisin interna no es necesaria. Es |
apropiado, sin embargo, proporcionar alguna revisin de errores para los
datos provenientes del exterior. As, se debe sospechar de cualesquiera
j
j
|
(
i
www.FreeLibros.org
EL MODELO
ESENCIAL 363
Figura 17.5(b): La versin lgica

procesos cuyos nombres sean volver a revisar... o verificar... o vali
dar... o editar... a menos que existan en la frontera del sistema y mane
jen entradas externas.
Buscar situaciones donde los almacenes esenciales se hayan empaque
tado en el mismo almacn de implantacin (por ejemplo, archivos en dis
co, en cinta o en papel); esto es muy comn en los sistemas de segunda
generacin y en sistemas que se han optimizado a lo largo de aos para
manejar grandes volmenes de datos de manera eficiente. Separe el
contenido del almacn del medio de almacenaje.
Eliminar datos de los almacenes si ningn proceso los usa; adems, eli
mine datos de los almacenes si se pueden calcular o derivar directamente
a partir de otros. (Note que los datos derivados y las copias redundantes
de datos pueden reinsertarse posteriormente cuando se desarrolle el mo
delo de implantacin durante ei diseo del sistema).
Finalmente, eliminar almacenes de datos que slo existan como separa
dores de tiempo entre procesos, y que sean dependientes de la implanta
cin. Esto incluye archivos intermedios, archivos de reportes, archivos de
impresin diferida y otros similares.
www.FreeLibros.org
364
1 7 .4
EL MODELO ESENCIAL
RESUMEN
El concepto de modelo esencial parece bastante natural, pero no es tan fs

de lograr en proyectos reales como pudiera pensarse. La mayora de los usuarios
estn tan involucrados en los detalles de la implantacin de su sistema actual qUe
les es difcil enfocarse a la visin de tecnologa perfecta de un sistema. Y es gUa|.
mente difcil para muchos analistas veteranos, pues han pasado tantos aos cons
truyendo sistemas que les es difcil evitar hacer suposiciones relacionadas con a
impiantacin al describir el sistema.
Recuerde que es crticamente importante desarrollar el modelo esencial de n
sistema, pues(como se recalc varias veces a lo largo de este libro) muchos siste
mas de informacin grandes tienen una vida media de unos 10 a 20 aos. Durante
ese perodo se puede esperar que el hardware mejore por io menos por un factor de
mil, y probablemente se acerque ms a un milln o ms. Una computadora un m- I
ln de veces ms rpida, pequea y barata que las actuales es en verdad algo muy I
cercano a la tecnologa perfecta; debe empezarse hoy a modelar sistemas como si
se tuviera esa tecnologa a la disposicin.
REFERENCIAS
1.
Tom DeMarco, Structured Analysis and Systems Specifcatin. Nueva York;

2.
Chris Gane y Trish Sarson, Structured Systems Analysis: Tools and Techniques. Engiewood Ciiffs, N.J.: Prentice-Hall, 1978.
3.
Edward Yourdon, Managing the Systems Life Cycle. Nueva York: YOURDON
Press, 1982.
4.
Vctor Weinberg, Structured Analysis. Nueva York: YOURDON Press, 1978.
5.

1.
Cules son los cuatro modelos que recomiendan los libros de anlisis de sis
temas clsico?
2.
Qu es un modelo fsico actual?
3.
D tres ejemplos de procesos fsicos (burbujas).
4.
D tres ejemplos de almacenes fsicos.
www.FreeLibros.org
5.
D tres ejemplos de flujos de datos fsicos.
i
i
Qu es un modelo lgico actual?
7.
Cul es la diferencia entre un modelo fsico actual y un modelo lgico actual?
Qu es tecnologa perfecta en el contexto de este captulo?
Qu es un modelo lgico nuevo?
10.
Cul es la diferencia entre modelo lgico actual y nuevo?
11 .
Bajo qu circunstancias podran ser guales el modelo lgico actual y nuevo

de un sistema?
12 .
Qu grado de traslape debe esperar el analista entre el modelo lgico actual

y el nuevo?
13.
Qu es un modelo fsico nuevo?
14.
Qu otro nombre hay para el modelo fsico nuevo?
15 .
Cul es la principal restriccin que describe el modelo fsico nuevo?
16.
Cules son las tres suposiciones principales en las que se basa el enfoque
clsico del anlisis estructurado?
17.
Proyecto de investigacin: En su organizacin, qu porcentaje de proyectos

tienen analistas no familiarizados con el rea de negocios dei usuario? Es
razonable este porcentaje en su opinin? Est cambiando?
18.
Cules son las dos principales razones por las que el usuario podra tener di
ficultades al leer y entender un modelo lgico?
19.
Cul es el principal problema del enfoque clsico del anlisis estructurado?
20.
Por qu dudan algunos usuarios de ios mritos de modelar su sistema ac

tual?
21.
Cunto del modelo fsico actual es probable que se deseche en la transicin

a un modelo lgico actuai?
22.
Cules son las razones por las cuales el modelo fsico actual es mucho ma
yor que el modelo lgico actual del sistema?
23.
Qu sinnimo hay de modelo lgico nuevo?
24.
Qu tipo de revisin de errores es apropiado en un modelo lgico? Qu ti

po es inapropiado? Por qu?
www.FreeLibros.org
25.
D una definicin de modelo esencial de un sistema.
366
EL MODELO ESENCIAL
26.
Qu significa aplazamiento constructivo en el contexto de este captulo?
27.
En un proyecto de desarrollo de sistemas, cundo debe tomarse a d e c i s i n

de implantar una funcin (es decir, un proceso en un DFD) con una persona en
ugar de con una computadora?
28.
Cules son los cuatro errores comunes que suelen cometer los analistas cuan
do tratan de crear un modelo esencial?
29.
Por qu no deben mostrarse los archivos temporales en un modelo esencial?
30.
Cundo deben mostrarse los archivos temporales en un modelo de sistema?

Por qu?
31.
Cundo deben mostrarse datos redundantes en un modelo de sistema?
32.
Cundo deben mostrarse datos derivados en un modelo de sistema?
33.
Cules son los dos componentes del modelo esencial de un sistema?
34.
Cul es el propsito del modelo ambiental de un sistema?
35.
Cul es el propsito del modelo de comportamiento de un sistema?
36.
Si tuviera que documentar la implantacin actual de un sistema, qu debera

tener cuidado de evitar?
37.
Es buena idea documentar todos los flujos de datos de la implantacin actual

del sistema? Por qu?
38.
Es buena dea documentar todas las especificaciones de procesos en la im

plantacin actual del sistema? Por qu?
39.
Es buena dea documentar todos los elementos del diccionario de datos en la

implantacin actual del sistema? Por qu?
40.
Cuando se define en trminos lgicos un modelo fsico actual, qu debe ha

cerse con los flujos esenciales que se empaquetaron en el mismo medio?
41.
Cuando se define en trminos lgicos un modelo fsico actual, qu se debe

hacer con los flujos empaquetados enviados a procesos que no requieren to
dos los datos?
42.

cerse con los procesos cuyo nico propsito es transportar datos de un lugar a
otro?
www.FreeLibros.org
43

hacer con las burbujas cuyo nico propsito es verificar los datos que se crean
dentro del sistema?
44

cerse con los almacenes esenciales que se empaquetaron juntos en el mismo
medio?
45

hacer con los datos que existen en almacenes pero no se usan en ninguna
parte dei sistema?
45
Cuando se define en trminos lgicos un modelo fsico acta!, qu debe ha

cerse con ios archivos temporales que se encuentran en el sistema fsico ac
tual?
www.FreeLibros.org
La estabilidad del m edio interno es una condicin prim aria para ia lib e r
tad e ind e p en d e n cia de cie rto s cuerpos vivo s en relacin con el a m
biente que os rodea.
C laude Bernard, Legons s u r les Phenom enes de ia Vie C om m uns aux
A n im a u x e t a u x Vegetaux, 1875-1879

1. Por qu la frontera del sistema es arbitraria pero cr
tica.
2. Cmo dibujar un diagrama de contexto para un sis
tema.
3. Cmo producir una lista de acontecimientos para un
sistema.
4. Cmo usar ei diagrama de contexto y la lista de
acontecimientos para construir el modelo ambiental.
P a r a el analista, la labor ms difcil en la especificacin de un sistema es a

menudo determinar qu es parte del sistema y qu no. Cualquier sistema que desa
rrolle, no importa lo ambicioso ni grandioso, ser parte de un sistema an mayor.
Como vimos en el Captulo 2, casi todos los sistemas con los que tenemos experien
cia humana son meramente subsistemas de sistemas mayores: aun si nuestra labor
fuera disear el mundo , tendramos que reconocer que ste es slo parte del siste
ma solar, el cual es parte de una galaxia pequea y obscura, la cual es parte del uni
verso.
www.FreeLibros.org
368
EL MODELO AMBIENTAL 369
As, el primer modelo importante que se debe desarrollar como analista es uno
ue no haga ms que definir las interfaces entre el sistema y el resto del universo,
@s decir, el ambiente. Por razones obvias, este modelo se conoce como el modelo
ambienta!. Modela el exterior del sistema; el modelo del interior del sistema, conoci
do com o modelo del comportamiento, se discute en os Captulos 20 y 21.
Adems de determinar qu est en el interior del sistema y qu en el exterior
(lo que se logra definiendo la frontera entre el sistema y el ambiente), tambin es cr
ticam ente importante definir las interfaces entre el sistema y el ambiente. S e necesi
ta saber qu inform acin entra al sistem a desde el am biente exterior, y qu
in fo rm aci n produce como salida ai ambiente externo.
Desde luego, las entradas y salidas no se producen ai azar: ningn sistema de
informacin toma todos los datos disponibles en el universo, ni expulsa cosas al azar
al ambiente exterior ningn sistema realista. Los sistemas que construimos son ra
cionales y tienen propsito; especficamente, producen salidas como respuesta a al
gn acontecimiento, o estmulo, en el ambiente. As, otro aspecto crtico del modelo
ambienta! consiste en identificar los acontecimientos que ocurren en el ambiente al
cual debe responder el sistema. No para todos los acontecimientos; despus de to
do, el ambiente en su totalidad genera un nmero infinito de acontecimientos. Slo
nos preocupan aquellos que (1) ocurren en el ambiente exterior y (2) requieren una
respuesta del sistema.
Observe que la frontera entre un sistema y su ambiente, como ilustra la Figura
18.1, es arbitraria. Puede haberse creado por algn decreto administrativo, como
www.FreeLibros.org
Figura 18.1: La frontera entre el sistema y
e l a m b ie n t e
370
EL MODELO AMBIENTAL
resultado de alguna negociacin poltica, o simplemente por accidente. Y eso es si

go que el analista de sistemas usualmente tiene oportunidad de influenciar.
Generalmente el usuario tendr una buena idea de la frontera general entre g|
sistema y el ambiente. Pero, como lustra la Figura 18.2, a menudo existe un rea
gris que est abierta a negociaciones, es decir, un rea sobre la cual el usuario (i)
no est seguro, (2) no haba pensado, (3) tena algunas deas preconcebidas que
est dispuesto a reflexionar o, (4) todas las anteriores.
Por ejemplo, el usuario podra pedirle al analista desarrollar un sistema (fe
cuentas por cobrar. Aunque esto pudiera representar una frontera firme y bien defi
nida entre el sistema (conocido como el sistema C/C) y el ambiente, el analista cier
tamente debiera considerar el rea gris, como lustra la Figura 18.3, de cuentas por
pagar, control de inventarios, manejo de efectivo, facturacin y entrada de pedidos,
como perspectiva un tanto ms amplia.
Figura 18.2: El rea g ris entre el sistem a y el am biente

Si el analista escoge una perspectiva demasiado pequea para un proyecto
est condenado al fracaso, pues ei usuario puede haber identificado sin darse cuen
ta el sntoma del problema (por ejemplo, nuestras cuentas por cobrar estn fuera de
control) en lugar de la causa del problema. Y si el analista, por exceso de confian
za, ingenuidad o exuberancia, escoge una perspectiva demasiado amplia para el
proyecto, est condenado al fracaso, puesto que estar tratando con una situacin
www.FreeLibros.org
Qoiica bastante ms compleja, y estar intentando desarrollar un sistema demasiajj0 grande bajo cualquier circunstancia. Adems pudiera estar tratando asuntos que
no le importan al usuario o que no se pueden cambiar en lo absoluto. As que es im
portante dedicar bastante tiempo y tener suficiente participacin del usuario en la
eleccin de una frontera apropiada para el sistema.
En un sistema grande se puede tomar en cuenta una cantidad de factores
cuando se est escogiendo la perspectiva de! proyecto. Entre los ms importantes
estn los siguientes:
El deseo del usuario de lograr una cierta participacin en el mercado para

el producto, o incrementara a ms de su nivel actual. Esto puede hacer
se ofreciendo un nuevo producto o una mayor funcionalidad de uno exis
tente (por ejemplo, la mayor funcionalidad que ofrecen los sistemas de
cajero automtico y los sistemas bancarios en lnea). O el usuario podra
hgura 18.3: El rea gris que rodea
ios sistemas de cuentas por cobrar
www.FreeLibros.org
372
EL MODELO AMBIENTAL
tratar de aumentar su mercado ofreciendo un mejor y ms rpido servic0

(por ejemplo,"todos nuestros pedidos se surten en menos de 24 horas, v
tenemos un elaborado sistema de rastreo de pedidos para saber dnete
se encuentra en todo momento).
La legislacin establecida por el gobierno federal, estatal o de la ciudad

La mayor parte de tales sistemas son de Informes, por ejemplo, que re^
portan el empleo (o desempleo) de trabajadores basndose en edad, se
xo, nacionalidad, etc. O podra tenerse que hacer un nuevo sistema para
considerar los cambios en las leyes sobre impuestos.
Deseo del usuario por minimizar gastos operativos de algn rea de sy

negocio. Esto era particularmente comn en ias compaas grandes en
los aos 60, y sucede con muchos negocios pequeos que estn instalan
do su primera computadora. La mayor parte de las organizaciones que
han tenido computadoras instaladas durante 10 aos o ms ya aprove
charon las oportunidades obvias de reducir el personal de oficina.
Deseo del usuario por lograr alguna ventaja estratgica para ia lnea d$
productos o rea de negocios que opera. Ei usuario intenta hacerlo orga
nizando y manejando informacin sobre el mercado para poder producir
artculos de manera ms oportuna y econmica. Un buen ejemplo de es
to son las lneas areas (al igual que muchas otras industrias reciente
mente desreglamentadas) donde mejor informacin acerca de tendencias
del mercado y preferencias de ios clientes pueden llevar a costos de pa
sajes e itinerarios de aerolneas ms eficientes.
El rea dentro de la frontera del sistema a veces se conoce como el dominio

de cambios. Por esto, simplemente queremos decir que todo lo que est dentro de
la frontera del sistema est sujeto a cambios (por ejemplo, reorganizacin y/o auto
matizacin), mientras que todo lo que est fuera se queda en su forma actual y no
es investigado por el analista.
Para ver dos ejemplos de fronteras de sistemas, examine los casos de estudio
de los apndices F y G. En el caso del Sistema de Informacin de YOURDON
Press (Apndice F), la frontera es un tanto mayor de lo que se esperara; incluye la
facturacin y el manejo de recibos que normalmente son parte del departamento de
contabilidad (y por tanto estaran fuera de la frontera); de manera similar, el contro
lador del elevador del Apndice G tiene una frontera un tanto menor que io desea
ble: se hubiera desarrollado un sistema muy distinto s los paneles de control del
elevador se consideraran parte dei ambiente. En ambos casos, las elecciones fue
ron arbitrarias.
www.FreeLibros.org
1gJ
H E R R A M IE N T A S U S A D A S P A R A D E F IN IR E L A M B IE N T E
El modelo del ambiente consta de tres componentes:

1.
Declaracin de propsitos >:
2.
Diagrama de contexto
3.
Lista de acontecimientos
Cada uno se discute a continuacin.

La declaracin de
propsitos
El primer componente del modelo ambiental es una declaracin textual breve y

dei propsito dei sistema, dirigida al nivel administrativo superior, la admi
n is tra c i n de los usuarios, y otros que no estn directamente involucrados con el de
sarrollo del sistema.
concisa
El siguiente es un ejemplo de una declaracin de propsitos tiplea:

El propsito dei Sistema de Procesamiento de Libros Ajax es manejar todos
ios detalles de los pedidos de libros de ios clientes, adems del envo, factura
cin y cobro retroactivo a clientes con facturas vencidas. La informacin acer
ca de los pedidos de libros debe estar disponible para otros sistemas, tales
como mercadeo, ventas y contabilidad.
La declaracin de propsitos puede constar de una, dos o varias frases. Sin
embargo, jams debe llegar a ms de un prrafo, ya que la intencin no es propor
cionar una descripcin completa y detallada dei sistema. Tal esfuerzo ira en contra
del objetivo: el propsito del resto del modelo ambiental y dei modelo de comporta
miento es dar todos los detalles.
Como resultado, la declaracin de propsitos ser deliberadamente vaga en
cuanto a muchos detalles. En el ejemplo anterior se podran hacer preguntas corno:
Exactamente qu tipo de informacin proporciona a contabilidad, ventas

y mercadeo el sistema de pedidos de libros?
Cmo determina el sistema de pedido de libros si un cliente tiene crdi

to? Lo determina el sistema mismo o por medio del departamento de
contabilidad?
Cmo se entera el sistema sobre nuevos libros que se han publicado y

estn disponibles para la venta?
www.FreeLibros.org
Estas preguntas detalladas slo pueden responderse viendo el modelo del
comportamiento que se discute en los Captulos 19 y 20.
374
EL MODELO AMBIENTAL
Aunque el documento de declaracin de propsitos no responde las pregum

detalladas sobre el comportamiento, generalmente basta con responder a una $6r:a
de preguntas de alto nivel:
Es responsable el sistema de pedido de libros de las actividades de n

mina? No; prcticamente cualquiera que lea lo anterior estar de acuerdo
en que la nmina queda fuera de la perspectiva del sistema y probable!
mente est incluida en el sistema de contabilidad.
Es responsable el sistema de pedido de libros de enviar facturas a | qs

clientes que piden libros? S; la declaracin de propsitos as lo afirma
Podra imaginarse esto como tema de debate entre el departamento <js
pedidos de libros y ei de contabilidad. Por ello es apropiado que se mero
cione en la declaracin de propsitos.
Es responsable el sistema de pedido de libros del control de inventarios

es decir, de determinar cundo volver a surtir libros que estn a punto de
acabarse? No. La declaracin de propsitos no hace tai afirmacin. Es
muy probable que el control de inventarios sea uno de muchos otros sis
temas (o departamentos) que usen la informacin sobre pedido de libros
que produce el sistema de pedido.
Muchos analistas sienten tambin que ia declaracin de propsitos debe resu

mir los beneficios tangibles y cuantificables que se logren con el nuevo sistema; por
ejemplo, ei propsito del sistema es reducir el tiempo que se requiere para procesar
un pedido, de tres das a uno. Aunque esto puede ser muy til en proyectos peque
os y muy definidos, no es fcil de lograr en proyectos ms grandes. En su lugar
suele requerirse un anlisis de costo-beneficio,
18.1.2
El diagram a de contexto
La siguiente parte dei modelo ambiental empieza a contestar algunas de las

preguntas que surgen a raz de la declaracin de propsitos. El diagrama de contex
to es un caso especial del diagrama de flujo de datos, en donde una sola burbuja re
presenta todo el sistema. La Figura 18.4 muestra un diagrama de contexto de un
sistema de pedido de libros. En los apndices F y G se proporcionan ejemplos de
diagramas de contexto para dos sistemas reales.
El diagrama de contexto enfatiza varias caractersticas importantes del siste
ma:
Las personas, organizaciones y sistemas con los que se comunica el sis

tema. Se conocen como terminadores.
www.FreeLibros.org
Los datos que el sistema recibe del mundo exterior y que deben procesar
se de alguna forma.
Los datos que el sistema produce y que se envan al mundo exterior.
Los almacenes de datos que el sistema comparte con los terminadores.

Estos almacenes de datos se crean fuera dei sistema para su uso, o bien
son creados en l y usados fuera.
La frontera entre el sistema y ei resto del mundo.
Las tcnicas para la construccin del diagrama de contexto se discuten en a

Seccin 18.2.
18.1.3
La Lista de acontecim ientos
La lista de acontecimientos es una lista narrativa de los estmulos que ocu

rren en el mundo exterior a los cuales el sistema debe responder. En la Figura 18.5
se muestra una lista de acontecimientos para el sistema de pedido de libros.
1.
2.
3.
4.
Un cliente hace un pedido. (F)

Un cliente cancela un pedido. (F)
La administracin pide un reporte de ventas. (T)
Liega un pedido de reimpresin de un libro a la bodega. (C)
Figura 18.5: Lista de a contecim ientos
Observe que cada acontecimiento se etiqueta como F, T o C. Con ello se

muestra si es de tipo de flujo, temporal, o de control. El orientado a flujos es el que
se asocia con un flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido
www.FreeLibros.org
376
EL MODELO AMBIENTAL
el acontecimiento cuando llega algn dato (o posiblemente varios). Como p0cr.

imaginarse, esto corresponder al flujo de datos en el diagrama de contexto.
Sin embargo, no todos los flujos de datos del diagrama de contexto necesaria,
mente son acontecimientos de tipo flujo. Considere, por ejemplo, el diagrama pe
contexto parcial que se muestra en la Figura 18.6.
Figura 18.6: Diagrama parcial de contexto
A primera vista, uno pudiera verse tentado a concluir que los flujos de datos A,
B y C son todos indicadores de acontecimientos separados y discretos. Sin embar
go, pudiera resultar que slo el flujo de datos A est asociado con un acontecimiento
(por ejemplo, al flujo de datos lo inicia el terminador). Para procesar un aconteci
miento el sistema explcitamente podra pedir entradas a otros terminadores a lo lar
go de los flujos de datos B y C para obtener alguna respuesta.
As que no necesariamente existe una correspondencia uno a uno entre los
flujos de datos del diagrama de contexto y los acontecimientos de la lista de aconte
cimientos. En general, cada flujo de datos es un acontecimiento (o, ms precisa
mente, la indicacin de que ha ocurrido), o bien es requerido por el sistema para
poder procesar un acontecimiento.
Adems de los acontecimientos de tipo flujo, un sistema puede tambin tener
acontecimientos temporales. Como su nombre implica, ios acontecimientos tempo
rales arrancan con la llegada de un momento dado en el tiempo. Algunos ejemplos
de acontecimientos temporales pudieran ser:
www.FreeLibros.org
A las 9:00 de la maana se requiere un reporte diario de todos los pedi

dos de libros.
Las facturas deben generarse a as 3:00 PM.
Se deben generar reportes administrativos una vez por hora.
Observe que los acontecimientos temporales no se inician con flujos de datos

de entrada; podra imaginarse que el sistema tiene un reloj interno con el cual puede
determinar ei paso del tiempo. Sin embargo, tenga en mente tambin que un acon
te c im ie n to temporal podrfa requerir que el sistema solicite entradas de uno o ms
term in ad ores. Por ello, podran asociarse uno o ms flujos de datos con un aconte
c im ie n to temporal, aunque los flujos de datos, en s, no representan el acontecimien
to mismo.
Los acontecimientos de control deben considerarse un caso especial del acon
temporal: un estmulo externo que ocurre en algn momento impredecidle. A diferencia de un acontecim iento tem poral normal, el acontecim iento de
control no se asocia con el paso regular del tiempo, por lo que el sistema no puede
anticiparlo utilizando un reloj interno. Y a diferencia de un acontecimiento de flujo
normal, el de control no indica su presencia con el arribo de datos. Como lo muestra
la Figura 18.7, un acontecimiento de control se asocia con un flujo de control en el
diagrama de contexto.
tecim iento
flujo de
control
Figura 18.7: Flujo de co n tro l asociado con un a contecim iento de control
El flujo de control puede considerarse como un flujo de datos binario: est en

cendido o apagado, y puede cambiar de un estado al otro en cualquier momento, se
alando as al sistem a que se necesita tom ar alguna accin inm ediata. Los
sistemas de informacin de negocios no suelen tener flujos de control en sus diagra
mas de contexto; ei Sistema de Informacin de YOURDON Press que se describe en
el Apndice F, por ejemplo, no tiene. Pero los flujos de control son bastante comu
nes en los sistemas de tiempo real; como ejemplo vea el diagrama de contexto dei
sistema de control del elevador en el Apndice G.
www.FreeLibros.org
378
EL MODELO AMBIENTAL
18.1.4
C om ponentes adicionales del m odelo am biental
En la mayor parte de los proyectos, la lista de acontecimientos, el diagrama tje

contexto y la declaracin de propsito bastan. Sin embargo, pueden ser tiles do
componentes adicionales, dependiendo de la naturaleza y complejidad del sistema-
d e fin e
todos los flujos y almacenes e x -
El diccionario de datos inicial, que

temos.
El modelo de entidad-relacin de los almacenes externos
Incluso un sistema mediano comnmente tendr unas cuantas docenas de flu

jos de datos de entrada y salida; un sistema grande pudiera tener literalmente cien
tos. Aunque estos flujos de datos finalmente se definirn con gran detalle en el
modelo de comportamiento (que se discute en el Captulo 20), podra ser til comen
zar la construccin del diccionario de datos ahora. Esto puede ser importante si las
interfaces entre el sistema y los diversos terminadores estn sujetas a cambios y a
negociacin; entre ms pronto se comience a definir formalmente estas interfaces
(definiendo la composicin y significado de los almacenes), ms pronto se podrn fi
nalizar.
De manera similar, se puede construir un diagrama de entidad-relacin de l o s
almacenes externos (si hay). Esto puede ayudar a dejar al descubierto las r e l a c i o
n e s entre almacenes que de otra manera no s e r a n evidentes hasta que s e d e s a r r o
l l a r a el modelo de comportamiento. Al concentrarse en estas relaciones en e s t a f a s e
temprana se tiene forma de volver a verificar las interacciones entre los terminadores (que tpicamente incluyen a los usuarios f i n a l e s del sistema) y ei sistema m i s m o .
18.2
CONSTRUCCION DEL MODELO AMBIENTAL
La discusin anterior probablemente hace que el modelo ambiental parezca

simple y directo: despus de todo, existe slo un proceso, unos cuantos flujos de da
tos y terminadores, una descripcin narrativa breve del propsito del sistema y una
lista de acontecimientos. A pesar de esto, a menudo resulta que el modelo ambien
tal requiere de una gran cantidad de trabajo; adems, usualmente se desarrolla co
mo una serie de refinamientos iterativos, con datos adicionales que se aaden y
retinan.
Una razn importante por la cual muchos refinamientos y revisiones suelen ser
necesarios es que normalmente una sola persona no puede comprender la perspec
tiva completa del sistema como se defini inicialmente. Si el proyecto involucra un
nuevo sistema que reemplazar a uno existente, es posible hablar con los usuarios
que actualmente llevan a cabo sus funciones. En cierto sentido, tienen la perspecti
va de quienes desde dentro ven las cosas hacia afuera, como lustra la Figura 18.8.
Sin embargo, incluso en este caso, los diversos usuarios individuales internos gene
ralmente slo estn familiarizados con una porcin, y sus diversas opiniones a veces
www.FreeLibros.org
gfitran en conflicto. Peor an, las entrevistas iniciales con la comunidad usuaria tal
yez omitan uno o ms usuarios importantes cuyas interacciones con los terminadoreS externos se deben modelar.1
Figura 18.8: La visi n del usuario del sistem a

Es importante dedicar una buena cantidad de tiempo y energa al modelo am
biental, pues a menudo es el punto focal de juntas y presentaciones importantes al
comienzo de la vida de un proyecto de desarrollo de sistemas. De hecho, a veces es
la nica parte del modelo global del sistema que muchos usuarios y administradores
de alto nivel llegarn a ver (los nicos con el dinero necesario para continuar finan
ciando el proyecto, y con el poder para cancelarlo). Despus de construido y apro
bado lo ver en los pizarrones de avisos, as que es importante que est correcto.
18.2.1
C onstruccin del diagram a de contexto
El diagrama de contexto, como hemos visto, consiste en terminadores, flujos

de datos y flujos de control, almacenes de datos y un solo proceso que representa a
todo el sistema. Se analizan uno por uno a continuacin.
La parte ms fcil del diagrama de contexto es el proceso; como hemos visto,
consiste en una sola burbuja. Ei nombre dentro del proceso suele ser el nombre del
sistema completo o un acrnimo convenido. En las Figuras 18.9(a) y (b) se mues
tran ejemplos.
1 Tales usuarios pudieran no ser im portantes en trm inos de je ra rq u a o rg a nizacionai; pueden con
siderarse como hum ildes oficin ista s, secretarias o adm in istra d o re s. No obstante, las funciones que
'ealtzan pudieran ser vitales, y ser crucial m odelar con pre cisin ias e n tradas que reciben dei mun
do exterior y ias salidas que m andan. La razn de que ei analista de sistem as a m enudo olvde ha
blarles a estas personas es muy sencilla: un usuario de nivel su p e rio r (es decir, el jefe) le dir al
analista con quin hablar. No m oleste a mi g e n te , le dir, estn todos m uy ocupados, p o r eso re
querimos el nuevo sistem a. Yo le dir todo lo que necesita saber sobre el siste m a . Com o se dis
cuti en el C aptulo 3, tal vez no haya form a dip lo m tica de e vita r esto, pero es crucial revisar el
modelo am biental con cuidado para asegurar que no fa lta nada.
www.FreeLibros.org
380
EL MODELO AMBIENTAL
Figura 18.9(a): Nombre tp ic o de proceso para un diagram a de contexto
Figura 18.9(b): O tro nom bre tp ic o de proceso

Observe que, en el caso extremo, ei nuevo sistema podra representar una or
ganizacin completa; en este caso, ei nombre del proceso tpicamente sera el de la
organizacin misma, como io muestra la Figura 18,9(c).2
Figura 18.9(c): Nom bre de proceso que representa una organizacin completa
Los terminadores, como hemos visto, se representan con rectngulos en el
diagrama de contexto. Se comunican directamente con el sistema a travs de flujos
2 Este es un e scenario poco probable para un proyecto de desarrollo de sistem as tpico, pero se da
m s y m s a m edida que se usan los diagram as de flu jo de datos y las otras herram ientas descritas
en este libro para co n stru ir m odelos de em presa. Esto se puede hacer sin pre te n d e r computarizar
to d a la em presa, sim plem ente para e n tender o que ya existe, sobre todo ios datos que la organiza
cin requiere para lle va r a cabo su propsito. Ei tem a de m odelos de em presa se discute en Infor
m atio n E n g in e e rin g fo r the P ra ctitio n e r, de W illiam Inm on (E nglew ood C liffs, N .J.: Prentice-Hall,
1987), as com o en S tra te gic Data B ase M odeling, de Jam es M artin (Englew ood C liffs, N .J.: Prenti
ce-H all, 1985).
www.FreeLibros.org
je datos o de control, como muestra la Figura 18.10(a), o a travs de almacenes ex

ternos, como se muestra en la Figura 18.10(b).
Figura 18.10(a): C om unicacin directa entre term inador y sistem a
Observe que los terminadores no se comunican directamente entre s, por lo

cual ei diagrama de contexto de la Figura 18.11 no es correcto. En realidad, los ter
minadores s se comunican entre s pero, dado que por definicin son externos al
sistema, la naturaleza y contenido de las interacciones termlnador-terminador son
irrelevantes para el sistema. Si durante la discusin con los usuarios encuentra que
es esencial saber cundo, por qu o cmo se comunican entre s, entonces los ter-
www.FreeLibros.org
Figura 18.10(b): Comunicacin a travs de un almacn externo
382
EL MODELO AMBIENTAL
Figura 18.11: Diagrama de contexto incorrecto
minadores son parte del sistema, y deben incluirse dentro de la burbuja de proceso
del diagrama de contexto.
Tres aclaraciones ms acerca de los terminadores:
1.
Algunos terminadores tienen un buen nmero de entradas y salidas. Para

evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador ms de una vez, como muestra la Figura 18.12(a). Note que los
terminadores duplicados se marcan con un asterisco; otra posibilidad es
representar los terminadores repetidos con una diagonal, como muestra
la Figura 18.12(b).
2.
Cuando el terminador es una persona individual, generalmente es preferi

ble indicar ei rol que desempea, ms que su identidad; as, la Figura
18.13(a) se prefiere a la Figura 18.13{b). Hay dos razones para ello: pri
mero, la persona que desempea el papel puede cambiar con el tiempo, y
es deseable que el diagrama de contexto permanezca estable y preciso
incluso si hay cambios de personal. Segundo, una misma persona puede
desempear varios papeles distintos en el sistema; en lugar de mostrar
un terminador etiquetado Juan Prez con varios flujos de entrada y sali
da no relacionados, es ms significativo mostrar ios diversos papeles que
Juan Prez desempea, cada uno como terminador separado.
3.
Dado que estamos interesados principalmente en desarrollar un modelo

esencial del sistema, es importante distinguir entre fuentes y manejadores
cuando se dibujan terminadores en el diagrama de contexto. Un manejador es un mecanismo, dispositivo, o medio fsico usado para transportar
www.FreeLibros.org
Figura 18.12(a): Term inadores dup lica d os en el diagram a de contexto
datos hacia dentro o fuera del sistema. Dado que a menudo dichos manejadores son familiares y visibles para los usuarios de la implantacin
actual de un sistema, existe la tendencia a mostrar al manejador, en lugar
de la verdadera fuente de los datos. Sin embargo, puesto que el nuevo
sistema generalmente tendr opcin de cambiar la tecnologa mediante ia
cual los datos se introducen y sacan del sistema, el manejador no debe
mostrarse. As, el diagrama de contexto de la Figura 18.14(a) se prefiere
al que se muestra en la Figura 18.14(b).
Como compromiso, sobre todo si el usuario insiste, se puede etiquetar un terminador para mostrar tanto la fuente verdadera como al manejador que introduce o
saca los datos dei sistema; esto se ilustra en la Figura 18.14(c).
Los flujos que aparecen en el diagrama de contexto modelan datos que entran
y salen del sistema, adems de las seales de control que recibe o genera. Los flu
jos de datos se incluyen en el diagrama de contexto si se ocupan para detectar un
acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan (co
mo datos) para producir una respuesta. Los flujos de datos tambin pueden apare
cer en el diagrama de contexto para ilustrar datos que estn siendo transportados
entre terminadores por el sistema. Finalmente, los flujos de datos se muestran en el
diagrama de contexto cuando el sistema produce datos para responder a un aconte
cimiento.
www.FreeLibros.org
384
EL MODELO AMBIENTAL
Como ya se ha hecho notar, e l diagrama de contexto de un modelo e s e n c i a l

evita (hasta donde sea p o s i b l e ) mostrar los manejadores cercanos a la i m p l a n t a c i n
que introducen y sacan datos de un sistema. Ms an, no se desea mostrar los
mensajes y medios especficos de coordinacin que el sistema y los t e r m i n a d o r e s
pasan entre s para indicar q u e estn listos para las entradas o salidas. Se desea
evitar diagramas de contexto como ei de la Figura 1 8 . 1 5 ( a ) pues incluye s u p o s i c i o nes sobre la implantacin que pueden cambiar drsticamente cuando se construye
el nuevo sistema.
Figura 18.12(b): Forma alternativa de m ostrar term inadores duplicados
ENCARGADO DE
ENVIOS
Figura 18.13(a): Forma preferente de m ostrar un term inador
FEDERICO ARANA
www.FreeLibros.org
Figura 18.13(b): Forma menos deseable de mostrar un terminador
Figura 18.14(a): Term inador que m uestra la verdadera fuente de los datos
SISTEMA DE
MENSAJERIA
FEDERAL EXPRESS
Figura 18.14(b): T erm inador que acta com o m anejador
CLIENTE. A TRAVES
DEL SISTEMA DE
MENSAJERIA
FEDERAL EXPRESS
www.FreeLibros.org
Figura 18.14(c): Terminador que combina ia fuente y el manejador
386
EL MODELO AMBIENTAL
En lugar de eso, debe dibujarse el diagrama de contexto bajo el supuesto de

que las entradas son causadas e iniciadas por los terminadores, y que las salidas
son causadas e iniciadas por el sistema. Al evitar mensajes extraos y entradas y
salidas orientadas a la implantacin, se modela slo el flujo neto de datos.
Sin embargo, habr ocasiones en las que un terminador no inicie las entradas
pues, aun con tecnologa perfecta, el terminador no sabe que el sistema requiere
sus entradas. Similarmente, hay ocasiones en las que el sistema no inicia la genera
cin de salidas, debido a que no sabe que el terminador las necesita o desea. En
ambos casos, el mensaje es una parte esencial del sistema, y debe mostrarse en el
diagrama de contexto; la Figura 18.15{b) tiene un ejemplo. A veces resulta conve
niente mostrar el mensaje y el correspondiente flujo de entrada o salida con un flujo
de dilogo (una flecha de dos cabezas), como muestra la Figura 18.15(c).3
18.2.2
C onstruccin de la lista de acontecim ientos
La ista de acontecimientos, como se vio, es un listado textual sencillo de los

acontecimientos del ambiente a los cuales debe responder el sistema. Al crear la
lista de acontecimientos se debe asegurar de distinguir entre un acontecimiento y un
fiujo relacionado con un acontecimiento. Por ejemplo, lo siguiente probablemente no
sea un acontecimiento:
3 N o e s necesario u s a r un flu jo d e d i lo g o , p e ro s v u e lv e m s le g ib le al d ia g ra m a d e con texto al

e m p a q u e ta r i a s e n tra d a s y s a lid a s a s o c ia d a s p a ra h a c e rla s v is ib le s d e in m e d ia to a l le c to r. Ade
m s , u tiliz a r u n a fle c h a p a ra m o s tra r el d i lo g o , en lu g a r de d o s s e p a ra d a s , lo g ra un d ia g ra m a de
c o n te x to m e n o s a tib o rra d o . E s to e s im p o rta n te en io s g ra n d e s s is te m a s , d o n d e p u d ie ra haber in
c lu s o c e n o m s d ife re n te s in te ra c c io n e s c o n te rm in a d o re s e x te rn o s .
www.FreeLibros.org
Figura 18.15(b): F lujos de dilogo para m ostrar m ensajes esenciales
www.FreeLibros.org
Figura 18.15(c): Forma alterna de mostrar flujos de dilogo
388
EL MODELO AMBIENTAL
El sistema recibe el pedido del cliente.

Ms bien, probablemente sea el flujo de datos de entrada mediante el cual el sstg
ma se da cuenta de que ha ocurrido el acontecimiento. Un nombre ms apropia^
para el acontecimiento sera:
El cliente hace un pedido.
Esto pudiera parecer un ejercicio de semntica, pero no lo es. SI describimos ei
acontecimiento desde el punto de vista del sistema (por ejemplo, desde dentro, viety
do hacia fuera), se podran identificar errneamente los flujos entrantes que no son
acontecimientos por s mismos, pero que se requieren para poder procesar algn
otro acontecimiento. Por ello, siempre se trata de describir los acontecimientos des
de el punto de vista del ambiente (es decir, desde fuera, viendo hacia dentro).
En la mayor parte de los casos, la manera ms fcil de identificar los aconteci
mientos relevantes para un sistema es visualizarlo en accin: examinar cada terminador y preguntar qu efecto pueden tener sus acciones sobre el sistema. Esto
usualmente se hace en conjunto con los usuarios del sistema desempeando el pa
pel de terminadores. Sin embargo, debe distinguirse cuidadosamente entre aconte
cimientos discretos que se han empaquetado accidentalmente como si fueran uno
solo; esto sucede a menudo con acontecimientos de tipo flujo. Debe examinarse el
acontecimiento candidato y preguntar si todas sus instancias involucran ios mismos
datos; si en algunas instancias estn presentes los datos, y ausentes en otras, po
dra en realidad haber dos acontecimientos distintos. Por ejemplo, si se ve de cerca
el acontecimiento el cliente hace un pedido, se encontrara que algunas Instancias
incluyen el dato identificacin del vendedor y otros no; y podra encontrarse que la
respuesta del sistema es diferente cuando participa un vendedor que cuando no.
Por ello, podra ser ms apropiado tener dos acontecimientos separados: ei cliente
hace un pedido y el vendedor tramita el pedido del cliente .
Adems, tenga en mente que la lista de acontecimientos debe incluir no slo
las interacciones normales entre ei sistema y sus terminadores sino tambin situa
ciones de falla. Dado que se est creando un modelo esencial, no hay que preocu
parse por fallas del sistema; pero se deben tomar en cuenta posibles fallas o errores
causadas por los terminadores. Como sealan Paul Ward y Stephen Mellar en
Structured Development for Real-Ti me Systems (Nueva York: YOURDON Press,
1985),
P u e s to que los term inadores e s t n p o r definicin fuera de las fro n
te r a s d e l in te n to d e c o n s tru c c i n d e s is te m a re p re s e n ta d o p o r el
m o d e lo , lo s re a liz a d o re s no p u e d e n m o d ific a r la tecn olog a d e lo s
te rm in a d o re s p a ra m e jo ra r su c o n fia b ilid a d . En lu g a r d e e llo , d e b e n
c o n s tru ir re s p u e s ta s p a ra los p ro b le m a s d e los te rm in a d o re s en el
m o d e lo e s e n c ia l d e l s is te m a . U n e n fo q u e til p a ra m o d e la r re s
puestas a lo s p ro b le m a s de te rm in a d o re s es c o n s tru ir u n a lis ta de
www.FreeLibros.org
a c o n te c im ie n to s n o rm a le s y lu e g o p re g u n ta r, p a ra c a d a a c o n te c i
m ie n to , N e c e s ita e l s is te m a re s p o n d e r s i e s te a c o n te c im ie n to d e
ja d e o c u rrir c o m o se e s p e ra ?
por ejemplo, nuestra lista de acontecimientos para ei Sistema de Pedido de Libros

Ajax (Figura 18.5) inclua un acontecimiento llamado el pedido de reimpresin de li
bro llega a la bodega. Pero qu tal si no lega a tiempo (por ejemplo, una semana
despus de la fecha prometida por el impresor)? Qu debera hacer el sistema?
pro b a b le m e n te se necesitara un acontecimiento adicional iniciado por el sistema
para hacer que se comunique con el impresor y localice el origen del retraso.
18.2.3
Qu se hace prim ero, el diagram a de con te xto o la lista de aconteci

m ientos?
Puede empezarse con la lista de acontecimientos o con el diagrama de con

texto. En realidad no importa mientras finalmente se produzcan ambos componentes del modelo ambiental y se revisen para asegurar que sean consistentes.
Podra encontrarse tambin hablando con personas enteradas de todo lo que
entra y sale del sistema; algunos usuarios pueden proporcionar esta Informacin, o
la! yez los programadores encargados del mantenimiento de la versin actual del
sistema puedan saber algo al respecto. Esto ofrecer las piezas dei diagrama de
contexto como punto de partida. Pueden discutirse entonces las transacciones que
ios usuarios mandan al sistema y la respuesta que esperan que d. Con ello se
puede crear una lista de acontecimientos a partir del diagrama de contexto.
Sin embargo, podra haber una situacin en ia que ei diagrama de contexto no
est disponible. Esto es muy comn, sobre todo al comienzo de algunos proyectos
de desarrollo de sistemas: tal vez no sea fcil identificar los terminadores de los di
versos flujos que entran y salen del sistema. En este caso suele ser ms prctico
empezar con un DER que muestre tos objetos y relaciones. Los acontecimientos
candidatos pueden encontrarse a continuacin buscando las actividades u operacio
nes que ocasionan que se creen o eliminen relaciones. La creacin de la lista de
acontecimientos puede llevar entonces al desarrollo del diagrama de contexto; esto
se ilustra en la Figura 18.16.
Por ejemplo, suponga que se han Identificado los objetos CLIENTE y LIBRO
en un sistema de publicaciones; el usuario podra tambin decir que existe una rela
cin pedidos entre CUENTE y LIBRO. Un acontecimiento probable, entonces, se
rla una accin que crea una instancia de la relacin pedidos; otro acontecimiento
sera una accin que elimine una instancia de una relacin. Esto llevara a identifi
car El cliente pide un libro y Ei cliente cancela su pedido del libro como aconteci
mientos en la lista de acontecimientos. No hace falta mucha investigacin para
darse cuenta de que cliente es un terminador para el sistema (mientras que libro
no lo es); se podra entonces comenzar por dibujar el diagrama de contexto.
www.FreeLibros.org
390
EL MODELO AMBIENTAL
Cuando se termine con ambos componentes del modelo ambiental ser pQs
ble confirmar o siguiente:
El sistema necesita cada flujo de entrada del diagrama de contexto para

reconocer que ha ocurrido un acontecimiento; debe necesitarlo para pro.
ducir una respuesta a un acontecimiento, o ambas cosas.
Cada flujo de salida debe ser respuesta a un acontecimiento.
Cada acontecimiento no temporal de la lista de acontecimientos debe te

ner entradas a partir de as cuales el sistema pueda detectarlo.
Cada acontecimiento debe producir salidas inmediatas como respuesta o

bien almacenar los datos que luego sern salidas (como respuesta o par,
te de una respuesta a algn otro acontecimiento), o debiera ocasionar un
www.FreeLibros.org
Figura 18.16: Creacin del diagrama de contexto a partir de un DER
cambio en el estado dei sistema (como indica el diagrama de transicin

de estados).
1gj
RESUMEN
La construccin de un modelo ambiental es lo primero y ms importante en la

construccin de un modelo completo de los requerimientos del usuario para un nuevo sistema. Hasta aqu parecera una tarea fcii; despus de todo, el diagrama de
contexto consiste slo en una sola burbuja, y la lista de acontecimientos parece una
simple lista de transacciones. Pero en un proyecto grande esto puede involucrar una
gran cantidad de trabajo: la burbuja nica dei diagrama de contexto puede interactuar con docenas de terminadores externos y tener ms de cien flujos de datos de
entrada y salida. La lista de acontecimientos constituye un gran esfuerzo en los
grandes sistemas; puede haber fcilmente cerca de cien acontecimientos que ei sis
tema tiene que manejar, y todos necesitan ser identificados. Adems, puede ser di
fcil encontrar una declaracin sencilla de por qu debe existir el sistema.
Una vez construido el modelo ambiental debe ser revisado cuidadosamente
por todos los representantes clave de los usuarios, adems dei equipo del proyecto.
Entonces se estar preparado para comenzar a construir el modelo del comporta
miento, es decir, el modelo del interior del sistema. Esto se discute en los Captulos
19 y 20.
1.
Cules son las tres cosas que define el modelo esencial?
2.
Qu tipo de acontecimientos debe modelar el modelo esencial?
3.
Cmo determina el analista la frontera entre el sistema y el ambiente?
4.
Cul es la consecuencia probable de que el analista escoja un alcance dema

siado pequeo para ei proyecto?
5.
Cul es la consecuencia probable de que el analista escoja un alcance dema

siado amplio para el proyecto?
6.
Qu factores deben tomarse en cuenta cuando se escoge el alcance de un

proyecto?
7.
Cmo afecta al alcance del proyecto ei deseo del usuario de obtener una ma
yor participacin en el mercado?
8.
Cmo afecta al alcance del proyecto la legislacin impuesta por los diversos
cuerpos gubernamentales?
www.FreeLibros.org
9.
Cmo afecta al alcance del proyecto el deseo del usuario de minimizar (o re

ducir) sus gastos operativos?
392
EL MODELO AMBIENTAL
10.
Cmo afecta al alcance del proyecto el deseo del usuario de obtener ventajas
estratgicas sobre la competencia?
11.
Proyecto de investigacin: Sobre un proyecto de su propia organizacin, qq

factor cree que afecte ms en la eleccin del alcance? Cree que el usuario
el analista y el equipo del proyecto estn conscientes y de acuerdo con ello?
12.
En general, cules cree que sean los posibles factores clave para los siste
mas que se desarrollen en los aos 90? Por ejemplo, ser ms importante
minimizar ios gastos operativos que ios cambios causados por la legislacin
gubernamental?
13.
Cules son los tres principales componentes del modelo ambiental?
14.
Aproximadamente de qu longitud debe ser un documento de declaracin de

propsitos?
15.
Cules cinco caractersticas de un sistema muestra un diagrama de contex

to?
16.
Cules son los componentes de un diagrama de contexto?
17.
Qu es una lista de acontecimientos?
18.
Cules son los tres tipos de acontecimientos que debe modelar un diagrama
de contexto?
19.
Qu relacin hay entre flujos y acontecimientos en el diagrama de contexto?
20.
Qu es un acontecimiento temporal?
21.
Qu componentes adicionales pueden encontrarse en un modelo ambiental

adems del diagrama de contexto, la lista de acontecimientos y la declaracin
de propsitos?
22.
Por qu suele ser necesario hacer muchas revisiones y refinamientos del mo

delo ambiental?
23.
Por qu es importante asegurar que el modelo ambiental est correcto?
24.
Qu tipo de nombre debiera ponerse dentro de una burbuja en un diagrama

de contexto?
25.
Qu es un modelo de empresa?
26.
Cmo se comunican los terminadores con ei sistema?
27.
Se comunican ios terminadores entre s en un modelo de sistema?

qu?
www.FreeLibros.org
Por
20
Bajo qu condiciones se dibujara un terminador ms de una vez en un dia

grama de contexto? Cmo se mostrara?
29
Si e! terminador es un individuo, cmo se mostrara en el diagrama de con

texto?
30.
Cmo puede estar seguro el analista de que ha identificado todos los termi
nadores en el diagrama de contexto?
31.
Qu es un manejador? Qu diferencia hay entre una fuente y un manejador?
32.
Por qu deberan las fuentes, y no tanto los manejadores, aparecer en un

diagrama de contexto?
33.
Qu debe hacer el analista si el usuario insiste en mostrar los manejadores

en un diagrama de contexto?
34.
Bajo qu condiciones se muestran los flujos en un DFD?
35.
Por qu en general no deben mostrarse los mensajes y la sincronizacin en

un diagrama de contexto?
36. Qu significa el trmino flujo neto de datos?

37. Bajo qu condiciones no inicia las entradas un terminador en un sistema?
38. Bajo qu condiciones el sistema no inicia las salidas al terminador?
39. Qu debe desarrollarse primero, el diagrama de contexto o la lista de aconte
cimientos? Por qu?
40.
Cules son las cuatro cosas que deben revisarse para asegurar que el mode
lo ambiental es correcto?
41. Qu tiene mal el siguiente diagrama de contexto?
EL
SISTEMA
www.FreeLibros.org
394
EL MODELO AMBIENTAL
42.
Qu tiene mal el diagrama de contexto siguiente?
43.
Qu tiene mai el diagrama de contexto siguiente?
44.
Qu tiene mal el diagrama de contexto siguiente?
LISTA DE ACONTECIMIENTOS
1. El cliente necesita una a

2. El vendedor necesita la factura
3. El vendedor hace un envo
4. El cliente hace un pedido
www.FreeLibros.org
CONSTRUCCION DE U
MODELO piHELII l1MAIB
AMIENTO
DE O
Las cosas siempre son mejores en sus comienzos.

Blaise Pascal, Lettres Provinciales
1656-1657, no. 4

1. Por qu es difcil un enfoque puramente
descendente del modelo de comportamiento.
2. Cmo desarrollar un modelo preliminar de
comportamiento usando la particin por
acontecimientos.
3. Cmo desarrollar el D E R inicial dei modelo
de datos.
E n el captulo a n t e r i o r v i m o s cmo d e s a r r o l l a r el modelo ambiental para u n

s i s t e m a . S i se estuviera trabajando en u n proyecto real ahora, s e habra terminado
e l diagrama de contexto, la l i s t a de acontecimientos y una declaracin de propsitos.
Adems, se debe haber comenzado a construir el d i c c i o n a r i o de datos, con por lo
m e n o s la d e f i n i c i n de los datos que representan interfaces e n t r e los terminadores
e x t e r n o s y e l sistema.
www.FreeLibros.org
395
396
CONSTRUCCION DE UN MODELO
Nuestra labor ahora es comenzar a construir el modelo de comportamiento dei

sistema, es decir, el modelo del comportamiento final que el sistema debe tener para
manejar con xito el ambiente. Esto involucrar el desarrollo de un diagrama cifiy.
jo de datos y un diagrama de entidad-relacin preliminares, adems de la elaboracin de las entradas iniciales del diccionario.
Bsicamente, este enfoque implica dibujar el borrador del diagrama de flujo efe
datos, con un proceso (burbuja) para la respuesta dei sistema ante cada acontecmiento que se identific en la lista de acontecimientos. A continuacin se dibujan al
macenes en el borrador del DFD para modelar los datos que deben recordarse entre
acontecimientos no sincronizados. Finalmente, se conectan los flujos de entrada y
salida apropiados a las burbujas y se compara el conjunto de diagramas de flujo efe
datos contra el diagrama de contexto para asegurar la consistencia.
Una vez hecho esto se procede a un proceso de limpieza, descrito en el Captulo 20, para producir un modelo bien organizado del proceso y un modelo de datos
para presentarlo al usuario final. Este enfoque se llam particin por acontecimien
tos en [McMenamin y Palmer, 1984],
Comenzamos por comparar este enfoque con el enfoque descendente clsico.
19.1
EL ENFOQUE CLASICO
El enfoque sugerido en este captulo es sustancialmente diferente del enfoque

descendente que se describe en textos clsicos aies como el de DeMarco [DeMarco, 1979], el de Gane [Gane y Sarson, 1979], y otros. El enfoque clsico supone
que ya se dibuj el diagrama de contexto, pero supone que se proceder directa
mente de la burbuja nica del diagrama de contexto a un DFD de nivel superior (co
nocido como figura 0), en donde cada burbuja representa un subsistema principal.
Cada burbuja de la figura O se parte a continuacin en figuras de nivel inferior, y ca
da burbuja de las figuras de nivel inferior se parte an ms, etc., hasta haber alcan
zado el nivel de una burbuja atmica que no requiera de mayor descomposicin.
Esto lo ilustra ia figura 19.1.
Aunque este enfoque descendente difiere dei que se presenta en este libro,
no me opongo a l ...si funciona. Sin embargo, tome en cuenta que muchos analis
tas encuentran los siguientes problemas cuando mientan seguir un enfoque des
cendente:
Parlisis dei anlisis. En muchos sistemas grandes y complejos, simple

mente no existe pista alguna que gue al analista para dibujar una figura O
apropiada desde el diagrama de contexto. Por ello, el analista se queda
sentado, viendo el diagrama de contexto, esperando la inspiracin divina,
o a alguien que le diga que ya no queda tiempo para el anlisis, y que ya
hace falta empezar a codificar.
www.FreeLibros.org
39?
El fenmeno de los seis analistas. En un sistema grande y complejo sue

le haber ms de un analista viendo el diagrama de contexto. Para dividir
ei trabajo en forma equitativa y no estorbarse unos a otros, arbitrariamen
te crean una figura 0 con una burbuja para cada analista. As, si hay seis
analistas, la figura 0 constar de seis burbujas. Desde luego, sta pudiera
no ser la particin ptima para el sistema. Qu ocurre, por ejemplo, si ai
mismo sistema lo especifican tres analistas? Q nueve? O uno?
Una particin fsica arbitrara. En muchos casos, un sistema nuevo se ba

sa en uno existente, o representa la computarizacin de una organizacin
existente. La particin de alto nivel del sistema actual (por ejemplo, las
unidades organizacionaes actuales o los sistemas de cmputo existen
tes) suele utilizarse como parmetro para ia particin del nuevo. As, si ei
sistema existente se representa con un Departamento de Compras y un
Departamento de Control de Calidad, el nuevo sistema tambin tendr un
Subsistema de Compras y un Subsistema de Control de Calidad aun
cuando tal vez no sean (y muchas veces no son) la mejor manera de par
tir el sistema (desde un punto de vista funcional).
www.FreeLibros.org
398
El enfoque que se describe en este captulo no es puramente descendente n

puramente ascendente. Es, en cierto sentido, un enfoque medio; despus de desarrollar el DFD inicial, se requiere alguna nivelacin ascendente, y luego podra ne
cesitarse alguna particin descendente.
19.2
IDENTIFICACION DE RESPUESTAS A ACONTECIMIENTOS

E! enfoque de particin por acontecimientos incluye los siguientes cuatro pg.
sos:
1.
Se dibuja una burbuja, o proceso, para cada acontecimiento de la lista.
2.
La burbuja se nombra describiendo la respuesta que el sistema debe dar

al acontecimiento asociado.
3.
Se dibujan las entradas y salidas apropiadas de tal forma que la burbuja

pueda dar la respuesta requerida, y se dibujan ios almacenes, como sea
apropiado, para la comunicacin entre burbujas.
4.
El borrador de DFD que resulta se compara con el diagrama de contexto

y la lista de acontecimientos para asegurar que est completo y sea con
sistente.
El primer paso es directo, de hecho casi mecnico en naturaleza. Si existen

25 acontecimientos en la lista, se deben dibujar 25 burbujas. Para tener una refe
rencia conveniente, numere cada burbuja para hacer juego con el acontecimiento
asociado: el acontecimiento 13 corresponde a la burbuja 13. (Ms adelante, como
veremos en el Captulo 20, se renumeran apropiadamente las burbujas).
El segundo paso tambin es directo y mecnico: a cada burbuja se le da un
nombre apropiado, basado en la respuesta requerida. Esto significa que se debe
examinar el acontecimiento y preguntar qu respuesta debe dar el sistema a este
acontecimiento? Recuerde, sin embargo, escoger nombres tan especficos como
sea posible. As, si ei acontecimiento es CLIENTE REALIZA PAGO, un nombre de
burbuja apropiado pudiera ser ACTUALIZAR CUENTAS POR COBRAR (si sa es la
nica respuesta del sistema), en lugar de PROCESAR PAGO DE CLIENTE (que na
da dice acerca de la naturaleza de la respuesta).
El tercer paso definitivamente no es mecnico, pero usualmente es bastante
directo. Para cada burbuja dibujada, identifique las entradas que requiere para efec
tuar su trabajo. Identifique las salidas (si hay) que cada una produce e identifique
los almacenes a os que que cada burbuja debe tener acceso. Esto normalmente se
hace entrevistando al usuario o usuarios apropiados y concentrndose en cada
acontecimiento y su burbuja asociada. Las preguntas son: Qu necesita esta bur
buja para hacer su trabajo? y Qu salidas genera?.
www.FreeLibros.org
399
En muchos casos el acontecimiento est determinado por el flujo; esto signifig qUe ei sistema detecta la ocurrencia de un acontecimiento por la llegada de algn
c, t0 de un terminador externo. Obviamente, esto significa que el flujo de datos
ropiado debe estar conectado al proceso requerido para responder a tal aconteci
miento. Pero, como muestran las figuras 1 9 .2 (a ) y (b), se pueden requerir entradas
adicionales (de otros terminadores, y posiblemente de almacenes de datos) para que
un proceso produzca su salida requerida.
Figura 19.2(a): Flujo de datos que seala la o cu rre n cia de un acontecim iento
www.FreeLibros.org
Figura 19.2(b): Entradas adicionales requeridas para producir una respue:
400
De manera similar, como parte de la respuesta dibuje las salidas adecuada*

producidas por el proceso. En muchos casos, esto implicar devolver salidas a lo?
terminadores fuera del sistema; sin embargo, puede tambin involucrar salidas q y
se envan a los almacenes de datos, para ser usadas como entradas de otros procg.
sos. Esto se ilustra en las figuras 19.3(a) y (b).
Figura 19.3(a): Salida enviada desde un proceso a un term inador
1
I.
Estos flujos no son

acontecimientos, pero
se requieren para
procesar el aconteci
miento asociado con^
el flujo X
www.FreeLibros.org
Figura 19.3(b): Salida enviada de un proceso a un
a lm a c n
401
Finalmente, el cuarto paso es una actividad de verificacin de consistencia, si

gilar a los pasos de balanceo del Captulo 14. Verifique cada entrada del diagrama
de contexto para ver si est asociada con alguna entrada de alguno de los procesos
del DFD preliminar; y verifique tambin que cada salida producida por algn proceso
en el DFD preliminar se enve a un almacn o sea una salida externa incluida en el
diagrama de contexto.
Existen dos casos especiales: (1) acontecimientos nicos que causan respues
tas mltiples y, (2) acontecimientos mltiples que causan la misma respuesta. En el
primer caso, un solo acontecimiento puede causar mltiples respuestas, cada una de
las cuales se modela con su propia burbuja en el DFD preliminar. Esto se ilustra en
la figura 19.4. Slo es apropiado si todas las respuestas usan el mismo flujo de da
tos de entrada, y slo si todas las respuestas son independientes entre s. Ninguna
salsda de alguna parte de la respuesta global debe ser requerida como entrada por
alguna otra parte de la respuesta global.
De manera inversa, habr situaciones ocasionales en las que un proceso se
asocia con ms de un acontecimiento; esto se ilustra en ia figura 19.5. Es vlido y
apropiado slo si la respuesta de la burbuja es idntica para los diversos aconteci
mientos, y sio si los datos de entrada y salida son idnticos para las diversas res
puestas a acontecimientos.
Figura 19.4: Mltiples respuestas del mismo acontecimiento
www.FreeLibros.org
402
p e d id o a p a g a r
Figura 19.5: M ltiples acontecim ientos con la misma respuesta
19.3
CONEXION DE LAS RESPUESTAS A ACONTECIMIENTOS
Observe que en los ejemplos anteriores ninguno de los procesos en el diagra

ma de flujo de datos preliminar est conectado con otro: las burbujas no se comuni
can directamente con otras. En vez de eso se comunican entre s a travs de otros
almacenes de datos.
Por qu? Simplemente porque las burbujas del DFD preliminar representan
respuestas a un acontecimiento, y los acontecimientos que ocurren en el ambiente
externo son, en ei caso general, no sincronizados. Es decir, no hay forma de garan
tizar que dos acontecimientos ocurrirn en el mismo instante, o con segundos de di
ferencia, o en algn otro perodo especificado de tiempo. Los acontecimientos
ocurren en el ambiente externo cuando ste desea que sucedan.
Y, dado que:
La respuesta a un acontecimiento puede requerir datos producidos por al

gn otro, y
No hay forma de saber cundo ocurrirn los acontecimientos, y
Debe suponerse, en un modelo esencial, que cada proceso realizar su

labor de manera infinitamente rpida, y
www.FreeLibros.org
Cada flujo de datos acta como conducto que puede transmitir datos con
rapidez infinita,
403
se sigue que la nica forma de sincronizar mltiples acontecimientos interdepenjientes es mediante un almacn. Ntese que ste es un almacn esencial; que se
necesita, no por retrasos asociados con la tecnologa imperfecta, sino por conside
raciones de tiempo en el ambiente.
As que no se tendr un diagrama de flujo de datos preliminar como el de la fi
gura 19.6(a); ya que los acontecimientos asociados no estn sincronizados, slo po
dra funcionar la figura 19.6(a) si hubiera escondido un almacn de datos diferido en
el tiempo en alguno de os procesos o en el flujo de datos mismo. Por ello, es la forma correcta de mostrar la comunicacin entre procesos es la figura 19.6(b).
Figura 19.8(a): Modelo no apropiado de la com unicacin retardada entre

procesos
19.4 DESARROLLO DEL MODELO INICIAL DE DATOS
Como hemos visto, el procedimiento de dibujar el DFD inicial implica el dibujo
de almacenes de datos entre procesos no sincronizados. En muchos casos su natu
raleza ser obvia, y los nombres pueden escogerse de la comprensin del tema del
proyecto.
Mientras tanto, sin embargo, alguien debera haber comenzado a trabajar en la
versin inicial dei diagrama de entidad-relacin como actividad independiente, en
paralelo con ei desarrollo del DFD inicial. Esto debe hacerse usando las tcnicas
del Captulo 12.
www.FreeLibros.org
404
pedido del cliente
PEDIDOS
Figura 19,8{b): M odelo apropiado de la com unicacin retardada entre

procesos
Como el DER y el DFD se estn desarrollando en paralelo, pueden usarse pa
ra revisarse entre s. Los almacenes que se definieron tentativamente en el DFD
preliminar pueden usarse para sugerir objetos en el DER preliminar; y los objetos
que se identificaron tentativamente en el DER preliminar pueden usarse para ayudar
a escoger almacenes apropiados en el DFD preliminar. Ningn modelo debe consi
derarse el dominante que controla al otro; cada uno es equivalente y puede propor
cionar asistencia invaluable ai otro.
Podra tambin encontrar que a lista de acontecimientos es tan til para crear
el DER inicial como para crear el DFD inicial. Suceder que los sustantivos de la lis
ta de acontecimientos sean objetos del DER; por ejemplo, s un acontecimiento es
Cliente hace pedido, inmediatamente se identificara cliente y pedido como obje
tos tentativos. Similarmente, se puede usar una lista de acontecimientos para verifi
car el DER inicial: todos los tipos de objetos del DER deben corresponder con
sustantivos de la lista de acontecimientos.
www.FreeLibros.org
19_5
405
RESUMEN
Lo ms importante a tomar en cuenta de este captulo es que an no se produun modeio de comportamiento listo para mostrarse al usuario. No est terminaj 0- no es bonito; no es lo suficientemente sencillo ni bien organizado como para
poderse entender en su totalidad. Puede ver un ejemplo de esto en el caso de estu
dio dei Apndice F.
cir
Entonces qu es? Cul es el objeto de realizar los pasos descritos en la

19.3? Simplemente es un comienzo, un marco de referencia sobre el cual
basar el desarrollo de la versin final del modelo esencial.
S e c c i n
No se preocupe en este momento por la organizacin del modelo d e comporta

miento, o su complejidad o claridad. Resista la tentacin de reorganizar, empaque
tar, descomponer o recomponer cualquiera de las burbujas del DFD preliminar. Lo
ynico que debe importarle en este momento es lo correcto del modelo: Tiene un
proceso para cada acontecimiento? Muestra las salidas y entradas necesarias para
cada acontecimiento? Muestra las conexiones necesarias entre acontecimientos?
Una vez establecido esto se puede comenzar a trabajar en la reorganizacin
dei modelo. Esto se discute con mayor detalle en el Captulo 20.
1 . Tom DeMarco, Structured Analysis and Systems Specification. Englewood

Cliffs, N.J.: Prentice-Hall, 1979,
2.
Chris Gane y Trish Sarson, Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1979.
3.
Steve McMenamin y John Palmer, Essentia Systems Analysis.

Nueva York:
1.
Qu es el modelo del comportamiento de un sistema? Cul es su propsito?
2.
Cules son ios tres principales componentes del modelo preliminar de com
portamiento?
3.
Cul es el enfoque clsico para la construccin de un modelo del comporta

miento? Por qu se caracteriza como un enfoque descendente?
4.
Cules son ios tres principales problemas que normalmente enfrentan los
analistas cuando tratan de seguir el enfoque descendente clsico al construir
un modelo del comportamiento de un sistema de informacin?
www.FreeLibros.org
406
5.
Por qu cree que algunos analistas sufran parlisis o bloqueo para escribir
cuando tratan de desarrollar el DFD de la figura 0 del diagrama de contexto?
6.
Por qu razn el modelo de comportamiento en algunos proyectos

una particin fsica arbitraria?
7.
Qu significa el trmino particin por acontecimientos?
8.
Cules son los cuatro pasos de la particin por acontecimientos?
9.
Si el analista ha descubierto 13 acontecimientos en un modelo ambiental

cuntos procesos (burbujas) debe haber en el primer borrador del modelo de
comportamiento?
10.
Qu tipo de numeracin se utiliza para las burbujas en el borrador de! DFD

del modelo de comportamiento?
11.
Qu parmetros se usan para nombrar las burbujas en el borrador del DFD

del modelo de comportamiento?
12.
Cmo debe determinar el analista las entradas, salidas y almacenes que ca

da burbuja requiere en el borrador del DFD?
13.
S un acontecimiento est determinado por el flujo, cuntos flujos de datos de

entrada debe recibir la burbuja que lo procesa?
14.
Cules son las reglas de consistencia que el analista debe seguir cuando di
buja si borrador del DFD del modelo de comportamiento?
15.
Cmo debe dibujarse el borrador del DFD para el caso de un acontecimiento

que produce mltiples respuestas?
16.
Bajo qu condiciones puede asociarse una sola burbuja del borrador del DFD
con ms de un acontecimiento?
17.
En el borrador del DFD, cmo se comunican las burbujas entre s? Es de

cir, cmo se convierten las salidas producidas por una burbuja en entradas pa
ra otra?
18.
Cmo muestra el borrador del DFD la sincronizacin de acontecimientos ml

tiples, interdependientes y no sincronizados?
19.
Qu debe desarrollarse primero: el borrador de! DFD o el borrador del mode

lo de datos (DER)? Por qu?
20.
Qu debe hacer el analista con el borrador del DFD y del DER despus de ter
minarlos?
exhibe
www.FreeLibros.org
407
Debe revisarse con el usuario el borrador del DFD cuando se ha terminado?

22
Qu tiene mal el siguiente borrador de DFD?
23.
Qu tiene mal el siguiente borrador de DFD?
c r d ito
a rtc u lo
d e v u e lto
L IS T A D E A C O N T E C IM IE N T O S (d e l m o d e lo a m b ie n ta l)
1. El c lie n te p id e un a rtc u lo
2. Ei c lie n te re g re s a un a rtc u lo
3. El c lie n te e fe c t a un pago
www.FreeLibros.org
COMPORTAMIENTO
D ennos as herram ientas y te rm inarem os el trabajo.
W inston C hurchill, tran sm isi n de radio, 1941
n este captulo se aprender:

1. Cmo nivelar hacia arriba un DFD inicial.
2. Cmo esconder ios almacenes locales de datos.
3. Cundo y cmo partir las burbujas iniciales del DFD
hacia abajo.
4. Cmo completar el diccionario de datos inicial.
5. Cmo completar las especificaciones del proceso.
6. Cmo completar el modelo de datos.
7. Cmo completar el diagrama de transicin de
estados.
t n el captulo anterior present la estrategia para el desarrollo de una ver

sin inicial dei modelo de comportamiento. Sin embargo, debe ser evidente que este
modelo no puede presentarse ai usuario para su verificacin. Por qu no? Princi
palmente, porque es demasiado complicado. Como se vio en el Captulo 19, el DFD
preliminar tendr un proceso para cada acontecimiento que se identific en el mode-
www.FreeLibros.org
TERMINADO DEL MODELO DE COMPORTAMIENTO 409
l0 ambiental; de aqu que pudiera tener hasta 40 o 50 burbujas, o posiblemente ms.

p@ manera similar, la versin inicial del DER probablemente sea demasiado tosca
co!0 para revisarla con los usuarios; como se discuti en el Captulo 12, se necesi
ta un refinamiento para eliminar los objetos innecesarios y/o aadir nuevos.
Existe un segundo problema con el modelo: consiste principalmente en grfic0s, con poco o ningn apoyo textual. Aunque el diagrama de flujo de datos y el diagrama de entidad-relacin son excelentes vehculos para presentar una visin global
del sistema al usuario, necesitan el apoyo de un diccionario de datos completo y un
juego completo de especificaciones de proceso.
20.1
TERMINADO DEL MODELO DEL PROCESO
20.1.1
Nivelacin de! DFD
Lo primero es reorganizar el DFD que se desarroll en el Captulo 19. Como

vimos, consiste en un solo nivel, con demasiadas burbujas. Por ello, se necesita una
nivelacin ascendente del DFD preliminar. Esto significa que se desea agrupar pro
cesos relacionados en agregados con significado, cada uno de los cuales represen
tar una burbuja de un diagrama de nivel superior. Esto se ilustra en la Figura 20.1.
Existen tres reglas que se debe tener en mente al hacer esto:
1.
Cada agrupacin de procesos deben involucrar respuestas relacionadas

cercanamente (recuerde que cada burbuja del DFD preliminar se nombra
acorde con la respuesta a un acontecimiento en la lista). Esto usualmen
te significa que los procesos manejan datos relacionados cercanamente.
2.
Busque la oportunidad de esconder o enterrar datos almacenados que

aparecen en el nivel inferior. Si ve un grupo de procesos en los DFD pre
liminares que se refieren a un almacn comn, y no hay otros procesos
en ei DFD prelim inar que se refieran a este almacn, entonces puede
crear una burbuja de nivel superior para esconderlo. Esto se ilustra en la
Figura 20.2 .
3.
Tenga en mente que la persona que ve sus DFD, sea un usuario u otro
analista, no querr ver demasiado a la vez. Por ello, cree agregados o
grupos del DFD preliminar que consistan en aproximadamente 7 ms o
menos 2 bloques de informacin, donde un proceso (y sus flujos relacio
nados) se consideren como un bloque.1
1 Este nm ero aparentem ente a rbitrario (de siete m s/m enos dos) es una regla para co n tro la r ia
complejidad en una va ried a d de situ a cio n es de so lu ci n de p roblem as. Se basa en !a obra de
George Miller, quien por prim era vez observ la dificu lta d de m anejar trozo s m ltiples de inform a
cin, en un trab a jo clsico titu la d o: "The M agical N um ber Seven, Plus M inus Two: Som e Lim its on
Our Capacity fo r Processing In form ation , publicado en P sych o lo g ica l Review, volum en 63 (1956)
PP. 81-97.
www.FreeLibros.org
410
TERMINADO DEL MODELO DE COMPORTAMIENTO
Desde fuego, esto significa que tai vez se necesiten varios intentos de nivela
cin ascendente. Por ejemplo, si se empezara con un DFD preliminar que tuviera
(por decir) 98 procesos y se organizara el diagrama en grupos de 7 burbujas (igno
rando, por simplicidad, los almacenes), entonces se creara un diagrama de nivel su
perior con 14 burbujas, cada una de las cuales representa una abstraccin de siete
de las de nivel inferior. Pero 14 burbujas son demasiadas para manejar y mostrar al
usuario a la vez; as que probablemente se crear (como muestra la Figura 20.3) un
diagrama de nivel superior con slo dos burbujas.
Observe que este ejemplo tiene nmeros completamente artificiales. No con
duzca la actividad de nivelacin procurando asegurar que cada diagrama tenga
exactamente siete burbujas. De hecho, las dos primeras reglas mencionadas ante
riormente: la agrupacin de datos en torno a datos comunes y la bsqueda de opor
tunidades para esconder almacenes locales, deben ser el parmetro principal para la
nivelacin ascendente, y no alguna regla aritmtica.
www.FreeLibros.org
PRELIMINAR
Figura 20.2: Cmo se esconde un almacn local en el nivel superior
Note tambin que podra requerirse nivelacin descendente. Es decir, posible

mente los procesos identificados en ei DFD resulten no ser procesos primitivos y re
quieran particiones descendentes en DFD de nivel inferior. Esto slo significa que
los procesos iniciales, cada uno de los cuales es responsable de producir la res
puesta a un acontecimiento, pudieran resultar demasiado complejos para ser descri
tos adecuadamente en una especificacin de proceso de una pgina. Muchas veces
esto se volver evidente tan pronto como vea el proceso con cuidado, o cuando pida
al usuario una explicacin de lo que la burbuja debe hacer. Si el usuario se pone a
pensar un momento, respira hondo y dice: Pues, es una larga historia, pero es algo
as como... ya tiene un fuerte indicio de que es muy probable que requiera dividir su
burbuja preliminar.
www.FreeLibros.org
412
*
FIGURAD
(d o s b u rb u ja s )
P rim e r re s u lta d o d e la n iv e la c i n
a s c e n d e n te
D F D p re lim in a r
(9 8 b u rb u ja s )
Figura 20.3: N ivelacin ascendente m ltip le de un DFD
En otros casos pudiera no ser evidente que la nivelacin descendente se re

quiera hasta que de hecho se intente escribir la especificacin del proceso; si en
cuentra que lleva tres pginas sobre la burbuja preliminar y que hay mucho ms qu
decir, de nuevo tiene un buen indicio de que se necesita la particin descendente.
www.FreeLibros.org
He aqu algunas reglas para llevar a cabo la nivelacin descendente:
En algunos casos es apropiado un enfoque de descomposicin funcional

pura. Es decir, si encuentra una burbuja de proceso que realiza una fun
cin compleja, trate de identificar subfunciones, cada una de las cuales
pueda ser hecha por una burbuja de nivel inferior. Por ejemplo, suponga
que hubo un proceso llamado Ajustar trayectoria del misil; podra ser la
burbuja responsable de manejar un acontecimiento temporal en un pro
yecto de gua de misiles en tiempo real. La funcin global de ajustar su
trayectoria puede descomponerse en varias subfunciones:
- Calcular variacin de la coordenada x
- Calcular variacin de la coordenada y
- Calcular variacin de la coordenada z
- Calcular nuevo factor de retardo atmosfrico.
- Calcular nueva velocidad del viento
- Calcular impulso en la coordenada x
- Calcular el impulso en la coordenada y
- etc.
En otros casos, los flujos de datos de entrada y salida proporcionarn la

mejor gua para la nivelacin descendente.Por ejemplo, suponga que se
tuviera una burbuja como la de la Figura 20.4 . Es probable que se pudie
ra crear un DFD de nivel inferior con la forma general que se muestra en
la Figura 20.5. Obviamente, podra requerirse ms de una burbuja para
www.FreeLibros.org
Figura 20.4: Nivelacin descendente de una burbuja compleja
414
la combinacin o agregado de datos individuales, pero la idea es la misma: que los datos sean la gua.
Tenga en mente al realizar esta actividad de nivelacin ascendente y deseendente, que el balanceo es importante. Es decir (como se discuti en el Capitulo 14)
debe asegurar que las entradas y salidas netas que se muestran para la burbuja de
alto nivel correspondan a las entradas y salidas netas que se muestran para el dia
grama de nivel inferior. Para un ejemplo de esta actividad de nivelacin ascendente
vea el caso de estudio del Sistema de Informacin de YOURDON Press en el Apn'
dice F. En este caso se comenz con un DFD preliminar que contena 40 burbujas;
se requiri un nivel de nivelacin ascendente, lo cual llev a un DFD de Figura 0 con
nueve burbujas.
Figura 20.5: El DFD de nivel in fe rio r
20.1.2
Cmo com pletar ei d iccio n a rio de datos
Al desarrollar el DFD preliminar en el Captulo 19, debi haberse comenzado a

desarrollar el diccioanro de datos; de hecho, es bastante comn empezar el diccio
nario de datos cuando se est desarrollando el diagrama de contexto. Sin embargo,
de ninguna manera estar completo an. Comnmente ser necesario llenar ia des
www.FreeLibros.org
cripcin del significado de cada dato; tambin sera apropiado dividir los datos complejos en elementos menores por claridad.
Al irse completando el diccionario de datos, tambin verifique que est com
pleto y sea consistente. Revise que el diccionario sea consistente internamente (es
decir, que ninguna parte contradiga a otra), que est balanceado con el diagrama de
flujo de datos por niveles, el diagrama de entidad-relacin y las especificaciones del
proceso.
20,1,3
Cmo com pletar
las especificacio nes
de proceso
Para cuando desarrolle el DFD preliminar, utilizando el enfoque de particin

por niveles del Captulo 19, es probable que no haya escrito especificaciones de proceso. Puede haber algunos cuantos casos en los que haya una especificacin de
proceso individual por algn inters en particular de parte suya o del usuario, pero
su principal preocupacin ser simplemente organizar el DFD mismo.
De hecho, suele ser mala idea dedicar tiempo a la escritura de las especifica
ciones del proceso antes de terminar el DFD preliminar, porque el desarrollo inicial
del DFD se ve sujeto a muchos cambios, correcciones y revisiones. Las burbujas
pueden aparecer, desaparecer, reacomodarse y cambiar de nombre. Cuando el
DFD preliminar empieza a estabilizarse, y cuando ha pasado la prueba de la nivela
cin ascendente (es decir, si la actividad no descubre fallas importantes en el mode
lo), entonces puede comenzar a escribir las especificaciones del proceso.
Esto a menudo ser un esfuerzo largo y consumir mucho tiempo, porque ca
da burbuja de nivel inferior en el conjunto de DFD requiere una especificacin de
proceso. Es posible que un grupo de dos o tres analistas dibujen unas cuantas do
cenas de DFD, pero puede ser necesario un mayor grupo de analistas para comple
tar todas las especificaciones de proceso a tiempo.
Al irse completando las especificaciones de proceso debem balancearse y
compararse con ei diccionario de datos y el DER, usando las reglas que se presen
taron en el Captulo 14.
20,2
TERMINADO DEL MODELO DE DATOS
Como sealamos en el Captulo 12, el DER se desarrolla de una manera simi

lar a la descrita para el DFD: se desarrolla un DER tosco, y luego se refina y se me
jora. Muchas de estas m ejoras se pueden hacer sim plem ente asignando o
atribuyendo datos a los tipos de objetos apropiados; esto usualmente ayudar a
identificar nuevos tipos de objetos o tipos innecesarios.
Sin embargo, tenga en mente que muchas veces el DER se desarrolla casi al
mismo tiempo que el DFD. Es muy comn encontrar a alguien (o un pequeo grupo)
dentro del mismo equipo que trabaja en el DER, mientras que otro (u otro grupo) tra
www.FreeLibros.org
416
baja en el DFD. O el equipo del proyecto desarrolla el DFD, mientras que el DER
desarrolla un grupo centralizado de administracin de datos de la organizacin j
proceso electrnico de datos. En todo caso, si el DER y el DFD se desarrollan apro
ximadamente al mismo tiempo, entonces los conocimientos que se obtienen del opri
(por ejemplo, la existencia de almacenes, flujos de datos, etc.) puede usarse para
retinar y revisar el DER.2
20.3
TERMINADO DEL DTE
Si su sistema tiene caractersticas de tiempo real, estar desarrollando un %

grama de transicin de estados adems del DFD y del diagrama de entidad-relacin
El conocimiento detallado del comportamiento del sistema le ayudar a retinar este
modelo. Como sealamos en el Captulo 13, examine ei diagrama de transicin de
estados inicial para encontrar los siguientes tipos comunes de errores:
Se han definido todos los estados?
Se puede llegar a todos los estados?
Se puede salir de todos los estados?
En cada estado, responde el sistema adecuadamente a todas las condi

ciones posibles?
20.4
RESUMEN
Hasta aqu, hemos llegado al final del modelo esencial. Si ha seguido todos
los pasos de los captulos 18, 19 y ste, debe tener un modelo completo, detallado,
formal y riguroso de todo lo que el sistema debe hacer para llenar los requisitos del
usuario. Contendr lo siguiente:
Lista de acontecimientos
Declaracin de propsitos
Conjunto completo de diagramas de flujo de datos por niveles
Diagrama de entidad-relacin completo y terminado
Conjunto completo de diagramas de transicin de estados
Diccionario de datos completo (para la fase de anlisis del proyecto)
www.FreeLibros.org
2 Idealm ente el m ism o g ru p o debiera de sa rro lla r los DER y DFD, trab a ja n d o en conjunto. Esto im
pide problem as de co m unicacin y tiende a a segurar que se les d igual nfasis a am bos modelos
D esafortunadam ente, rara vez sucede en la realidad.
Conjunto completo de especificaciones, con una para cada proceso de ni

vel inferior
Suponiendo que ha revisado los componentes de las especificaciones para

asegurarse que estn completos y sean consistentes, y suponiendo que el usuario
^ revisado y aprobado el documento, ya debe haber terminado. Puede ponerle un
jallo listn rojo al paquete y entregarlo al equipo de diseo/programacin cuya labor
ser construir e sistema. Luego, puede retirarse a la comodidad de su oficina hasta
qUe surja el siguiente proyecto.
Pero, espere. Falta un paso. Todo lo que se ha desarrollado en este modelo
supone la existencia de tecnologa perfecta, pero tambin supone que el
usuario no tendr restricciones de implantacin que imponerle al sistema. La tecno
loga perfecta es producto de nuestra imaginacin, pero podemos dejarle al equipo
de implantacin la decisin de cmo llegar a un compromiso razonable con la tecno
loga existente.
esencial
Suponer que el usuario ignorar todas las restricciones de implantacin es

tambin producto de nuestra imaginacin, y es algo que debemos tratar antes de en
tregar al equipo de implantacin la ltima versin de la especificacin. Esta activi
dad final, que debe hacerse con la colaboracin de usuarios, analistas y algunos
miembros del equipo de implantacin, es el desarrollo del modelo de implantacin
del usuario. Se discute en el siguiente captulo.
1.
Por qu no se puede presentar al usuario el primer borrador del modelo de

comportamiento?
2.
Est completo el borrador del modelo de comportamiento? Si no, qu ele

mentos le faltan?
3.
Qu significa la nivelacin ascendente en el contexto de este captulo?
4.
Qu criterios debe seguir el analista para agrupar burbujas en un DFD?
5.
Cules son las tres reglas que el analista debe tener en mente al ir nivelando
hacia arriba?
6.
Qu significado tiene el concepto de esconder datos almacenados en el con

texto de este captulo?
7.
Cuntos niveles de DFD de mayor nivel deben crearse del borrador de un

DFD? Existe alguna frmula matemtica para dar una aproximacin del n
mero de niveles que se requieren?
www.FreeLibros.org
8.
Bajo qu condiciones ser necesaria una nivelacin descendente en un

DFD?
418
9.
Es posible que el analista realice nivelaciones ascendente y descendente

el DFD? Porqu?
11
10.
Por qu tiene que completarse el diccionario de datos normalmente durante

esta etapa del desarrollo del modelo de comportamiento?
11.
Qu tipo de verificacin debe hacerse en el diccionario de datos durante este

perodo del proyecto?
12.
Por qu resulta ser mala idea que el analista invierta tiempo escribiendo espg.
cificaciones de proceso antes de completar el DFD preliminar? Bajo qu
condiciones pudiera tener sentido escribir por lo menos algunas especificacio
nes de proceso?
13.
Cules son los ocho componentes principales del modelo final de los requeri
mientos dei usuario?
www.FreeLibros.org
1]
EL IMQDEL
DE IMPLANTA i)
EL UPll!' /aE'
Se debe observar una sim plicidad espartana. Nada se har m eram ente
porque con trib u ye a la belleza, conveniencia, com odidad o prestigio.
De la O ficina d e i O ficia l de S eales en Jefe, E jrcito de lo s EUA,
2 9 de m ayo de 1945.

1. Cmo escoger la frontera de automatizacin del
sistema.
2. Cmo seleccionar dispositivos de entrada y salida
para el usuario.
3. Cmo desarrollar formatos de entrada y salida.
4. Cmo disear las formas para el sistema.
5. Cmo desarrollar codificacin para entradas del
sistema.
6. Cmo identificar as actividades de apoyo manual.
7. Cmo describir las restricciones operacionales del
sistema.
www.FreeLibros.org
419
420
EL MODELO DE IMPLANTACION DEL USUARIO
A l final del ltimo captulo habamos terminado el desarrollo del modelo

esencial de un sistema de informacin. Este modelo contiene una descripcin cg^.
pleta de lo que el sistema debe hacer para satisfacer al usuario. Especficamente, 9|
modelo esencial describe:
La poltica, o lgica, esencial de las funciones que se requiere realizar.
El contenido esencial de los datos que almacena el sistema, y que $e

mueven a travs de l.
El comportamiento esencial dependiente del tiempo que el sistema debe

exhibir para manejar seales e interrupciones del ambiente exterior.
En el mejor caso (desde el punto de vista del analista y el equipo de implanta

cin). con esta informacin sera suficiente para los diseadores y programadores:
simplemente se les dara el modeio esencial y se les permitira escoger el mejor
hardware, sistema operativo, sistema de administracin de bases de datos y lengua
je de programacin, dentro de las restricciones globales del proyecto en tiempo, di
nero y recursos humanos. Sin embargo, no es tan sencillo: en prcticamente todos
los proyectos de desarrollo de sistemas, ei usuario insistir en proporcionar alguna
informacin adicional.
Esta informacin adicional involucra cuestiones de implantacin que son sufi
cientemente importantes, es decir, tienen el suficiente impacto sobre la capacidad
del usuario para usar el sistema, que deben especificarse ya. El asunto de implanta
cin ms obvio de inters para e! usuario es la frontera de automatizacin, es decir,
cules partes del modelo esencial se van a implantar con la computadora y cules
se van a realizar manualmente por personal de la organizacin. Tal vez el analista
tenga su opinin al respecto, y el equipo diseador/programador la suya, pero obvia
mente es el usuario quien tiene la ltima palabra.
Similarmente, el formato de las entradas y salidas del sistema (a veces conoci
do como interfaz humana) es de enorme inters para el usuario. A menudo, incluso,
parece interesarle ms que las funciones del sistema. Desde que los sistemas de
cmputo empezaron a generar reportes en papel, los usuarios empezaron a preocu
parse por la organizacin y distribucin de la Informacin en el reporte. Dnde de
ben estar ios encabezados? Cmo organizar cada rengln para una lectura ms
fcil? Debe haber un resumen o subtotal al final de cada pgina o slo al final de
cada reporte? Etc.
Con el advenimiento de los sistemas en lnea en los aos 70, esta cuestin se
extendi para incluir el inters del usuario por el formato de las pantallas de entrada
en la terminal de video. Dnde deben aparecer los mensajes del sistema en la
pantalla? Qu tipo de mensajes de error deben aparecer? De qu color deben
ser? De qu manera se podr mover el usuario de una pantalla a otra?
www.FreeLibros.org
EL MODELO DE IMPLANTACION DEL USUARIO 421
(s/ls recientemente, varias opciones y posibilidades ms han aumentado la imde estas cuestiones de implantacin:
DOrtanca
Los usuarios finales a menudo tienen la oportunidad de usar computado

ras personales (PC) como parte de una red distribuida de computadoras
(por ejemplo, se les da una PC que se conecta con la computadora princi
pal de la organizacin). Esto lleva a una serie de preguntas: Qu partes
del modelo esencial se asignarn a la PC (bajo el control del usuario) y
qu partes a la computadora principal? Qu parte de los datos se asig
nar a la PC y cul a la principal? Qu formato tendrn las entradas
que el usuario proporciona a la PC? Qu actividades adicionales de
apoyo hay que proporcionar para asegurar que el usuario no dae inad
vertidamente los datos almacenados en la PC o en la computadora prin
cipal?
Los usuarios finales tienen cada vez ms oportunidades hoy en da de es

cribir sus propios programas en lenguajes de cuarta generacin tales co
mo FOCUS, NOMAD e IDEAL, en la com putadora principales o en
dBASE-IV y Rbase-5000 en una PC. En la medida en que llegan a involu
crarse con tales cuestiones de implantacin, necesitan especificar ios for
matos de entradas y salidas del sistema. O ms importante, decidir qu
partes del sistema se implantarn utilizando lenguajes de cuarta genera
cin y cules usando lenguajes convencionales de tercera generacin.1
En muchas situaciones actuales, el usuario y el analista podran hacer un

prototipo de porciones del sistema utilizando un lenguaje de cuarta gene
racin o un paquete de generacin de aplicaciones. El prototipo se hara
porque el usuario no est seguro respecto a la poltica detallada que tar
de o temprano tendr que convertirse en especificaciones del proceso en
el modelo esencial; pero ms a menudo la actividad de hacer prototipos
se dedica a la exploracin y experimentacin con formatos de entrada,
dilogos en lnea y dilogos de salida para pantallas o reportes.
En muchas aplicaciones de negocios, otra opcin para el usuario es la se

leccin y compra de un paquete de software, es decir, un producto ya
existente que puede comprarse o usarse bajo licencia. En este caso, las
mismas cuestiones de implantacin son de importancia para el usuario:
Qu parte de las funciones esenciales las implantar el paquete y cu
les tendr que hacer el usuario (o tendrn que ser implantadas por el de
1 Esto ilustra la necesidad de una buena com unicacin e n tre los usuarios y el equipo de Im planta
cin, adems de con los analistas de sistem as. Aunque los an a lista s pudieran e sta r bastante inte
resados en la u tiliz a c i n de le n g u a je s de c u a rta g e n e ra ci n , el e q u ip o de im p la n ta c i n puede
requerir investigar su desem peo. Los sistem as con grandes volm enes de e n tradas y salid a s pue
den encontrar que los lenguajes de cuarta generacin son dem asiado ineficientes. D iscutirem os
Sto ms a fondo en el ca p tulo 23.
www.FreeLibros.org
422
partamento de sistemas de informacin como sistema aparte)? A culgs

datos esenciales se les dar mantenimiento con el paquete y a cules p0.
el usuario? Cul ser la forma y secuencia de las entradas que requer
el sistema comprado, y si esto ser aceptable?2
Estas cuestiones deben tratarse como parte del modelo de implantacin ce
usuario, que se crea aumentando, revisando o hacindole anotaciones al modelo
esencial, como veremos en ias secciones siguientes de este captulo. Sin embargo
recomiendo siempre conservar una copia de! modelo esencial original intacto; esto
permitir explorar otros modelos de Implantacin en el futuro.
De manera general, el modelo de implantacin del usuario cubre los siguientes
cuatro puntos:
1.
Distribucin del modelo esencial entre personas y mquinas.
2.
Detalles de la interaccin humano-mquina.
3.
Actividades manuales que se podran requerir.
4.
Restricciones operativas que el usuario desea imponer al sistema.
Cada uno se discute con ms detalle a continuacin.

21.1
DETERMINACION DE LA FRONTERA DE AUTOMATIZACION
Recuerde que el modelo del sistema con el que estamos trabajando identifica
todas las actividades (funciones) y todos los datos esenciales. La cuestin ahora es:
Qu funciones y qu datos se manejarn manualmente, y cules se automatiza
rn? Aunque haya habido una eleccin tentativa preliminar de la frontera de auto
m atizacin durante el estudio de fa ctib ilid ad , no se debera considerar como
congelada. De hecho, a frontera de automatizacin es casi irrelevante en el modelo
esencial pues, aunque el usuario obviamente quiere que se desarrolle un sistema
automatizado, tambin necesita una declaracin bien hecha de los requerimientos
de las funciones y datos que queden justo fuera de la frontera de automatizacin.
Hay tres casos extremos que mencionaremos brevemente:
Ai usuario pudiera no importarle dnde est la frontera de automatizacin.

Es poco probable que esto suceda, pero es una posibilidad terica. Efecti
vamente, el usuario le est diciendo al equipo de implantacin, Ustedes
dganme s tiene sentido que ciertas porciones del sistema sean manua
les o automatizadas. Aparte del hecho de que normalmente el usuario
www.FreeLibros.org
2 Aqu se est haciendo una suposicin muy im portante: que el m odelo esencial debe desarrollarse
prim ero, antes de e valuar el paquete com ercial. M uchas organizaciones hacen ju sto lo contraro:
prim ero evalan el paquete y luego tratan de d e riva r un m odelo de los requerim ientos esenciales
usando las ca ra cte rsticas que ofrece.
se muestra preocupado, se espera que el analista produzca (como resul

tado adicional de su trabajo) un anlisis revisado de costo-beneficio del
proyecto completo. Esto usualmente requerir de por lo menos una deci
sin preliminar acerca de cules partes del modelo esencial se automati
zarn y cules sern manuales.
E usuario podra escoger un sistema totalmente automatizado. Esta es

una situacin ms comn, sobre todo si el sistema que se desarrolla es
reemplazo de uno actual y no se cambia la frontera de automatizacin.
As que las actividades manuales que el usuario realiza pudieran estar ya
fuera de ia frontera dei sistema, que se representan en el diagrama de
contexto por los terminadores con los que el sistema se comunica.
Ei usuario podra optar por un sistema completamente manual. Esta es

una opcin fuera de lo comn, sobre todo en esta era de automatizacin,
porque ei analista usualmente tiene inters en computarizar lo ms posi
ble. Sin embargo, puede suceder en situaciones donde ias intenciones
expresas del usuario sean no computarizar nada, sino simplemente reor
ganizar la forma en la que se desempean actualmente las actividades en
una organizacin.
Normalmente estas opciones extremas no ocurren; basndose en interaccio

nes entre el usuario, el analista y ei equipo de implantacin, se llegar a algn com
promiso. Es decir, se automatizar parte de las actividades del modelo esencial y
otras se identificarn como funciones manuales; de manera similar, algunos de los
datos esenciales se identifican como candidatos obvios para computarizacin (y de
esta forma quedan bajo el control de la administracin de sistemas de informacin),
y algunos se dejarn bajo el control del usuario. A menos de que ste tome una de
cisin inmediata y arbitraria al respecto, es bueno que las tres partes (el usuario, el
;rai:sta y el equipo de implantacin) exploren diversas opciones. Como ilustran las
figuras 21.1 (a), (b) y (c), pudiera haber diversas alternativas razonables para dibujar
la motera de automatizacin. Cada una tendr diferente costo (que el equipo de im
plantacin debe estimar, puesto que tiene conocimiento sobre las posibilidades de la
tecnologa de implantacin) y diferentes ramificaciones organizacionales en el rea
f%i usuario.
No es labor ni del analista ni del equipo de implantacin escoger la frontera de
automatizacin, sino responsabilidad del usuario, y este libro no proporciona reglas
P3ra determinar qu tipo de eleccin es la mejor, Pero ntese que el modelo esen
cial sirve como herramienta til para que el usuario y el equipo de implantacin ex
ploren diversas opciones. Una vez elegida la frontera de automatizacin, el analista
oucLera darse el lujo de pensar en eliminar procesos y datos manuales (es decir,
aquellas burbujas y almacenes que no se automatizarn). Pero esto generalmente
no es verdad. En el caso ms sencillo, se puede requerir regresar las actividades y
los datos manuales a los terminadores que rodean al sistema, como muestran las fi
suras 21,2(a) y (b).
www.FreeLibros.org
424
Figura 2 1 .1(b): Otra eleccin de frontera de autom atizacin
www.FreeLibros.org
Pero, en el caso general, el analista debe reconocer que incluso las activida
des manuales son parte del nuevo sistema. Por ello puede tener que escribir proce
dimientos para los usuarios de modo que sepan cmo llevar a cabo las funciones
requeridas, adems de proporcionar aiguna gua sobre ia organizacin de los alma

cenes que no se van a automatizar.3 Ntese que este aspecto del modelo de implan
tacin del usuario meramente requiere de anotaciones en el DFD y el DER para
.r.dloar las actividades manuales y las automatizadas.
Observe que una vez escogida la frontera de automatizacin pudiera ser mj pecante considerar algunas cuestiones ambientales: nivel de ruido, radiacin, ilumi
nacin, comodidad de la terminal de video y espacio de trabajo, etc. A menudo,el
nuevo sistema perturbar ei ambiente normal de trabajo del usuario (por ejemplo,
ocasionar que se coloque una terminal en el escritorio de un usuario, donde antes
jams hubo).4 O podra traer actividades de proceso de informacin a un ambiente
donde nunca las hubo antes (por ejemplo, el rea de produccin de una fbrica).
3 Los procedim ientos de! usuario para los procesos m anuales pueden basarse en la e specificacin
ce! proceso. De hecho, en el caso m s se ncillo la e sp e cifica ci n del proceso es el procedim iento
re usuario; sin em bargo, dado que las e sp e cifica cio ne s del proceso se e scribiero n cuidadosam ente
para evitar cu a lquier p rejuicio de im plantacin, tal vez sea necesario exp a nd irla s o re e scrib iria s pa
ra servir de g u a para ios usuarios.
4 Piense un m om ento en el tip o de problem as q ue pueden su rg ir ai sim plem ente poner una term inal
en el escritorio de un usuario. Prim ero, tal vez no quepa: p o siblem ente el u suario necesita todo el
espacio para otra s cosas que est haciendo. Segundo, puede se r que no haya su ficie n tes tom as de
corriente para la term inal de video, la im presora, el m odem y otro s p erifricos. T ercero, el escritorio
Podra tener la altura adecuada para leer y e scrib ir m s no para teclear. C uarto, la luz de la oficina
puede m olestar a tal grado que sea difcil leer la inform acin de la pantalla. Q uinto, el ruido del te
cleo del usuario en la term inal puede resultar m olesto a o tro s u suarios en la m ism a rea.
www.FreeLibros.org
426
www.FreeLibros.org
Figura 21.2(b): Las actividades manuales se han integrado a ios terminadores
p0r ello, es importante asegurarse haber estudiado estos factores humanos a fondo
antes de tomar la determinacin final respecto a la frontera. A veces el usuario tenj- bastante qu decir al respecto, pero si no ha tenido experiencia previa con siste
mas de informacin quiz no pueda predecir el tipo de problemas que surgirn. Pida
congojo a otros profesionales de sistemas que hayan desarrollado e instalado siste
mas similares en condiciones ambientales similares.
Finalmente, note que una vez que se ha escogido ia frontera de automatizacin, podra ser necesario aumentar ei modelo esencial para mostrar cmo se en
ciende y apaga el sistema; el modelo esencial muestra slo el comportamiento de
e s ta d o estable del sistema, y supone que ste ha estado trabajando desde siempre,
y que continuar trabajando para siempre. As, podra requerirse incluir procesos
adicionales (burbujas en el DFD), flujos de datos y almacenes que muestren las acti
vidades de inicio y apagado del sistema, o cual incluira reportes a la administracin
(o a los usuarios o al departamento de operaciones) sobre las caractersticas opera
cionales del sistema.
21.2
DETERMINACION DE LA INTERFAZ HUMANA
Probablemente ia actividad que consume ms tiempo, y que ms interese ai

usuario, es la especificacin de la interfaz humana. Esto involucra cuatro asuntos
relacionados:
1.
La eleccin de los dispositivos de entrada y salida (por ejemplo, termina

les de video, dispositivos de reconocimiento ptico de caracteres, tarjetas
perforadas, etc., para las entradas, y reportes en papel, despliegues en
pantalla o luces como salidas).
2.
El formato de todas las entradas que fluyen desde los terminadores hasta
el sistema.
3.
El formato de todas las salidas que fluyen desde el sistema hacia ios ter
minadores,
4.
La secuencia y los tiempos de entradas y salidas en un sistema en lnea.
21,2.1
D isp ositivo s de entrada y salida
La eleccin de los dispositivos de entrada y salida puede estar determinada

por los terminadores fuera del sistema; por ejemplo, si el sistema produce reportes
de salida para el gobierno, tal vez no haya otra opcin que producirlos en papel. Los
dispositivos que se usan tpicamente para proporcionar entradas al sistema5 inclu
yen los siguientes:
www.FreeLibros.org
5 Note que estam os discu tie n do las e ntradas p roporcionadas por el usuario. M uchos sistem as (so
bre todo los de tiem po real) deben m anejar dispositivos que p roporcionan entradas independientes
be los hum anos (por ejem plo, unidades de radar, reg istra d o re s de datos y seales de satlite).
428
Tarjetas perforadas. Solan ser la forma ms comn de entradas, pero v

rara vez se usan, excepto en algunos sistemas muy grandes de comput'*
cin por lotes. Una ventaja de la tarjeta perforada es que puede ser
zada como documento fuente por el usuario externo (por ejemplo, p ie ^
en los cheques que producen algunos sistemas de gobierno; son docy
mentos negociables, pero tambin se usan como entradas directas a Ur
sistema de cmputo). Las principales desventajas de las tarjetas son s!
tamao estorboso, su limitada capacidad de almacenamiento de datos 0'
hecho que slo pueden usarse una vez y la susceptibilidad a errores z*
operador.
Cinta magntica. Pudiera ser una forma apropiada de tener entradas es

otros sistemas; tambin puede ser un medio apropiado de entrada si
usuario dispone de un dispositivo de captura de datos de teclado a cin
La principal ventaja de este enfoque, desde luego, es que se puede alma
cenar un volumen mucho mayor de datos en una cinta que en una tarjeta
la desventaja es que los datos no se pueden manipular fcilmente una
vez que se graban en la cinta. La tarjeta, por otro lado, es ms primitiva
pero s permite al usuario la flexibilidad de reacomodarlas o de eliminar
algunas (tirndolas a la basura) antes de ingresarlas ai sistema.
Discos flexibles. Con el advenimiento de las computadoras personales a

comienzos de ios aos 80, los discos flexibles se volvieron una forma po
pular de medio de entradas. Los datos normalmente se registran en el
disco flexible por medio de una interaccin fuera de lnea con una compu
tadora personal (por fuera de lnea se entiende que la actividad no tiene
conexin con el sistema de informacin en desarrollo). Un disco flexible
tpico puede almacenar entre 360,000 y 1.2 millones de caracteres; esto
no es tanto como lo que almacena una cinta magntica, pero es adecua
do para muchas aplicaciones de mediano volumen.
Terminales y computadoras personales. Las terminales de video se han

vuelto una de las vas de entradas ms comunes durante los diez ltimos
aos, al bajar su costo de $3,000 dlares estadounidenses (o ms) a
$300 (o menos). Es importante distinguir entre terminales simples, que
no proporcionan ms que un teclado y pantalla; terminales inteligentes,
que ofrecen una variedad de facilidades de edicin local y capacidad de
almacenamiento local; y las computadoras personales, que tienen una ca
pacidad de almacenamiento local mucho mayor y todas las capacidades
computacionales de una computadora de tipo general. Las terminales in
teligentes y las PC vuelven posible que el usuario haga cambios y corrija
errores triviales de manera instantnea, en lugar del retraso de mandar
las entradas mediante lneas de telecomunicaciones a una computadora
principal; la capacidad de almacenamiento local hace posible que el usua-
www.FreeLibros.org
rio ingrese una gran cantidad de entradas aun cuando ei sistema compu
tacional no est operacional todo el tiempo.
Lectores pticos y lectores de cdigo de barras. Leen informacin impre

sa o codificada en varios tipos de documentos; particularmente ventajoso
para aplicaciones tales como cajas de supermercados, donde e! usuario
proporciona el cdigo del producto y otros datos relevantes sobre la com
pra. En la medida en que estos dispositivos leen los datos directamente,
se elimina la necesidad de teclearlos manualmente en una terminal. Al
gunos lectores pticos pueden leer documentos ordinarios mecanografia
dos, y algunos pueden leer docum entos m anuscritos. La principas
desventaja de este tipo de medio de entradas es su costo; otra desventa
ja es su tendencia a los errores.
Telfono. Para algunas aplicaciones, el telfono por tonos puede ser un

medio apropiado de ingreso de entradas.6 Esto es particularmente venta
joso para los sistemas que tratan con el pblico en general; pocos tienen
una terminal o una PC en su casa, pero aproximadamente el 98% de los
ciudadanos norteamericanos tienen al menos un telfono en casa. Dado
que el telfono slo proporciona entradas numricas, sus aplicaciones
son un tanto limitadas. Es conveniente para situaciones donde ei usuario
slo necesita proporcionar cosas tales como un nmero de cuenta, pero
no sera prctico para situaciones que requieran entradas textuales.
Voz. Finalmente, algunos sistemas pueden usar la voz humana como

medio de entrada. La tecnologa de entrada de voz de fines de os aos
80 es capaz de reconocer un vocabulario de unos cientos de palabras pa
ra un usuario individual, y debe reprogramarse para cada usuario nuevo.
Las ventajas son obvias; las desventajas, por el momento, son: 1) el cos
to del dispositivo, 2) su limitado vocabulario, 3) su tiempo de respuesta
lento y, 4) verdaderos problemas si la voz del usuario cambia de manera
significativa debido a un resfriado o alguna otra causa.
As como el usuario tiene opcin de medios distintos de ingreso de entradas

para el sistema, tambin hay varias posibilidades de medios para las salidas. Los
ms comnmente usados son los siguientes:
Salidas impresas. Es definitivamente la forma ms comn de salida para

los sistemas de cmputo actuales. Se pueden producir con una variedad
de dispositivos: impresoras de matriz de puntos (a menudo conectadas a
la terminal que se usa para la entrada), impresoras de lnea de alta velo-
8 Ntese que estam os haciendo d istin ci n entre ei uso del instrum ento te le f n ico (el telfono) y la
lnea de telecom unicaciones: m uchas te rm in a le s estn cone cta d a s por m odem a una lnea te le fn i
ca; pero aqu se habla del te l fo n o m ism o corno m edio de entrada.
www.FreeLibros.org
430
cidad, impresoras lser de alta velocidad, impresoras lser personales

impresoras personales de margarita, etc. La principal ventaja de las
das impresas es que constituye un documento permanente, y puede use,-,
se en una variedad de aplicaciones fuera del sistema. Las desventajas
de tos reportes impresos son su tamao estorboso, la probabilidad de
se impriman ms copias (o ms copias de la informacin) de lo que realmente se ocupa, y 1a, velocidad relativamente baja a la que se produce la
informacin.
Tarjetas perforadas. As como pueden servir de medio de entrada, tam

bin pueden servir para las salidas. Como se seal anteriormente, |as
tarjetas perforadas pueden usarse como documentos legales; como !o seala Marjorie Leeson en [Leeson, 1981], las tarjetas perforadas pueden
servir como documento que circula (es decir, que sale del sistema hacia l
un terminador externo y posteriormente se convierte en entrada para si i
sistema desde el mismo terminador). Pero, en general, son de tamao
estorboso y no pueden almacenar mucha informacin; por ello la ma
de los sistemas de informacin actuales no las utilizan.
Terminal. Los sistemas en lnea que usan terminales como medio d<. ;
trada tpicamente las usan tambin para las salidas. La ventaja de la ter* II
minal es que puede mostrar una gran cantidad de informacin a grar
velocidad; con las terminales modernas se puede desplegar de manera f
conveniente combinaciones de textos y grficos. La principal desventaja |
de la terminal es que no representa una salida material; la salida es tran
sitoria y se pierde cuando se muestra el siguiente desplegado.
Salida de voz. Para algunas aplicaciones, la voz es adecuada como me- |

dio de salida. Sucede donde el telfono se usa como medio de entrada I
(vase arriba); el mismo telfono puede usarse para llevar salida de voz
al usuario. Algunas terminales tambin estn equipadas con dispositivos
de salida de voz, pero no es muy comn. La principal ventaja del medio
de salida de voz es que se puede usar para comunicar mensajes relativa
mente breves en un medio (por ejemplo, una fbrica) donde posiblemente
el usuario no tenga oportunidad de leer salidas impresas.
|
Graficador. El graficador se usa normalmente para producir diagramas y

dibujos grandes y complejos (por ejemplo, dibujos y planos arquitectni
cos). Los dibujos dei tamao de una hoja normal de papel pueden produ
cirse actualmente con impresoras lser o de matriz de puntos, pero los
graficadores pueden producir salidas de un metro de ancho por varios de
largo. La desventaja de este medio de salida es su costo, su tamao y la
cantidad de tiempo que se requiere para producir las salidas.
www.FreeLibros.org
Cinta magntica o disco. Obviamente, as como se pueden usar para las

entradas, se pueden usar para las salidas. Esto normalmente es prctico
j
I
slo en casos en los que las salidas se van a mandar a otros sistemas de
cmputo (es decir, donde el terminador del sistema no es una persona, si
no una computadora).
21.2.2
COM. Acrnmo de las siglas en ingls de Microforma para Salidas de

Computadora. Las salidas COM normalmente se reservan para archivos
(por ejemplo, material de referencia voluminoso que seria demasiado caro
y estorboso producir como reportes impresos normales). Los rollos de mi
crofilm (que los bancos utilizan, por ejemplo, para guardar copias de che
ques cancelados) o las tarjetas de microfichas son ejemplos de esto.
Form atos de entrada y salida
Una vez escogidos los dispositivos de entrada y salida, ei siguiente paso es

determinar ios formatos de las entradas y salidas del sistema. En algunos casos, los
formatos pudieran no ser cuestin de negociacin, sino simplemente cuestin de que
si usuario informe a! analista de ia manera en la que las cosas tienen que ser. Es
asi sobre todo si el nuevo sistema debe comunicarse con otros sistemas o con per
sonas (o grupos) externos a la organizacin que construye el nuevo sistema. Las or
ganizaciones externas o los otros sistem as de cm puto externos pueden
proporcionar datos al sistema nuevo en un formato fsico prescrito que no se puede
cambiar. Igualmente, pueden requerir salidas del sistema con un formato tambin r
gidamente prescrito.
Si el dilogo humano-mquina no se ha definido por completo, qu hay an
por negociar? No la representacin interna de los datos dentro del sistema de cm
puto pues al usuario no le preocupa, ni debiera percatarse de esta informacin.
Tampoco cosas tales como los valores y lmites legales de los datos de entrada,
pues deberan haberse especificado como parte del modelo esencial. Sin embargo,
s es momento de negociar restricciones razonables de la implantacin sobre aspec
tos varios de los datos. A continuacin hay unos ejemplos:
El modelo esencial podra haber identificado el dato APELLIDO-DELCLIENTE. Como cuestin de poltica esencial, podra no haber lmite pa
ra la longitud (nmero de caracteres) de este dato. Despus de todo,
qu tiene de malo un apellido de 357 letras? Aunque no sucede fre
cuentemente, algunos miembros de la nobleza europea podran desear
demostrar su linaje incluyendo los nombres de todos sus antepasados an
cestrales en su apellido. Esto es interesante y pudiera tener algn signifi
cado histrico, pero el usuario y ei analista podran no obstante estar de
acuerdo en restringir APELLIDO-DEL-CLIENTE a 25 caracteres. Note,
por cierto, que esto requerir de un cambio en las especificaciones apro
piadas del proceso que maneja la entrada de APELLIDO-DEL-CLIENTE
para asegurar que sea vlido de acuerdo con esta restriccin de la im
plantacin.
www.FreeLibros.org
432
En un sistema de ingreso de pedidos, un PEDIDO-DE-CLIENTE podrfp

definirse como PEDIDO-DE-CLIENTE = NOMBRE + DOMICILIO + ART|!
CULO PEDIDO. En el modelo esencial, podra no haber razn para limita'el nmero de artculos diferentes que un cliente compra en un solo pe<jL
do. Desde la perspectiva de la implantacin del usuario, sin embargo
existen varias razones: 1) como actividad de apoyo manual (que se discy!
te ms adelante, en ia Seccin 21.3), el usuario puede desear que el em
pleado de ventas tome el pedido en una forma pre-impresa donde slo
caben, por ejemplo, 8 artculos distintos; 2) al usuario podra preocuparle
que el empleado de ventas cometa algn error si trata de manejar ms de
cierto nmero limitado de artculos en cada pedido; 3) al usuario podra
preocuparle que el prestar servicio a uno de sus clientes con 597 artculos distintos moleste a otros clientes que esperan servicio, etc. Por tanto
hay un buen nmero de razones vlidas para imponerle a este dato algu
na restriccin definida por el usuario.
Observe que las cuestiones de implantacin del usuario de este tipo involucran
sobre todo anotaciones extra en el diccionario de datos, adems de lgica adiciona!
(si se necesita) en las especificaciones del proceso que tratan con la validacin de
datos de entrada. Pero hay otro aspecto del dilogo humano-mquina que requiere
algo ms que anotaciones del diccionario de datos: la secuencia, sobre todo en un
sistema en lnea, que se puede modelar utilizando un diagrama de transicin de es
tados. La figura 21.3 muestra un ejemplo tpico de diagrama que se usa para mode
lar la secuencias en pantalla que ei usuario final utiliza para comunicarse con el
sistema.
www.FreeLibros.org
Figura 21.3: Diagrama de transicin de estados para modelar pantallas de video
Esto es til sobre todo para manejar preguntas como: Puedo regresar al men principal desde ia imagen de pantalla 12? Otras cuestiones de entrada/salida
aportantes son el acomodo fsico de los datos en la pantalla de video, la naturaleza
los mensajes si se comete un error de entrada; y el acomodo fsico de los datos
salida en la pantalla y los reportes. Con la gran gama de lenguajes de cuarta ge-acin, de herramientas para hacer prototipos y de computadoras personales que
existe actualmente, recomiendo dar al usuario oportunidad de jugar con diversas variantes de pantallas de entrada, desplegados de salida, etc.7 Una vez que el usuario
est de acuerdo, anexe al modelo esencial una copia de los desplegados en panta
lla, formatos de reportes y diagramas de transicin de estados apropiados, con refe
rencias apropiadas a los datos esenciales dei diccionario de datos.
Desde luego, en muchos casos el usuario no tendr mayores sugerencias,
pues no tiene experiencia previa trabajando con un sistema de cmputo: esto es un
tanto anlogo a alguien que ha vivido en un departamento toda su vida, pero ahora
quiere especificar los detalles de su primera casa de varios niveles, de diseo exclu
sivo. En el caso de sistemas de informacin computarizados, las siguientes regias
ayudarn a desarrollar una interfaz amable con el usuario en la mayor parte de los
casos:
1.
El sistema debe pedir entradas y producir salidas en forma consistente.

Esto es particularmente cierto para los sistemas en lnea donde el usuario
puede ingresar una o varias transacciones y/o recibir uno o ms desplie
gues distintos. Por ejemplo, suponga que ei sistema pide al usuario la fe
cha cuando se ingresa una transaccin; sera un desastre si un tipo de
transaccin requiere la fecha en la forma 12/23/87 mientras que otra la
requiere en la forma 87/12/23. Y sera un desastre si una parte del siste
ma requiere que el usuario especifique el estado como una clave de dos
caracteres (por ejemplo, NY para Nueva York), mientras que otra pide
que se deletree el estado. De manera similar, si una parte del sistema re
quiere que el usuario proporcione una clave de larga distancia cuando se
ingresa un nmero telefnico, entonces todas las dems deben solicitarla
cuando se ingresa el nmero de telfono.
2.
Pida informacin con una secuencia lgica. En muchos casos esto de

pende de la naturaleza de la aplicacin y requerir discusiones cuidado
sas con el usuario. Por ejemplo, suponga que se est desarrollando un
sistema de ingreso de pedidos, y se quiere que el usuario especifique el
nombre del cliente. Sea que la informacin se ingrese en tarjetas perfora
das o (lo que es ms probable) desde una terminal de video, tendr que
especificar la secuencia en la cual desea que se ingresen los componen-
www.FreeLibros.org
7 De hecho, puede requerir h erram ientas de in te lig e n cia a rtificia l de quinta generacin para e xperi
mentar con e n tradas en lenguaje natural, entradas de voz, salidas g rficas, etc.
L MODELO DE IMPLANTACION DEL USUARIO
tes de nombre de cliente . Una secuencia lgica sera pedirle al usuarjn

proporcionar ia informacin en la siguiente as:
ttulo (Sr./Srita./etc.)
nombre
inicial del segundo nombre
apellido
Pero ei usuario podra encontrar esto muy difcil. Suponga que se ha ob
tenido el nombre del cliente de alguna fuente externa, como un directorio
telefnico. En este caso, sera mucho ms conveniente teclear:
apellido
nombre
ttulo
De lo que s se puede estar seguros es que la siguiente secuencia sera
bastante impopular con el usuario:
nombre
ttulo
apellido
3.
Haga obvio al usuario ei tipo de error que ha cometido, y dnde. En mu

chos sistemas, el usuario proporciona al sistema mucha informacin por
cada evento o transaccin. Por ejemplo, en un sistema de ingreso de pe
didos, el usuario puede especificar el nombre del cliente, su domicilio y
nmero telefnico adems de informacin acerca de los artculos pedidos,
como descuentos, instrucciones de envo e impuestos sobre la venta. To
da esta informacin puede colocarse en una sola pantalla de informacin
de video antes de enviarla al sistema. Desde luego, el sistema podra en
tonces determinar que parte de, o todas, las entradas son errneas. Lo
importante es asegurar que el usuario entienda el tipo de error que se es
t cometiendo y dnde se localiza; no es aceptable que el sistema simple
mente suene una seal y despliegue ei mensaje ENTRADA INVALIDA.
Cada error (suponiendo que haya ms de uno) debe identificarse, con un
mensaje descriptivo, o bien (en el caso de un sistema en lnea) enfatizan-
www.FreeLibros.org
do o mostrando el dato errneo de acuerdo con algn cdigo de colores.

Dependiendo de la naturaleza del sistema y el nivel del usuario, podra
tambin ser importante desplegar un mensaje de explicacin; esto se dis
cute con mayor detalle en el inciso 5.
Distinga entre edicin de campos y ediciones de pantalla. En muchos ca
sos el sistema ser capaz de determinar si el dato proporcionado por el
usuario es o no correcto sin hacer referencia a otros datos. Por ejemplo,
si se teclea un cdigo de dos caracteres para un estado, se debera de
terminar inmediatamente si esos dos caracteres representan un estado
vlido, una provincia, etc. Pero si el usuario fuera a ingresar un cdigo
postal como dato Individual, hay slo una cantidad limitada de edicin en
el campo que se puede realizar sin necesidad de entradas adicionales; se
requiere tanto el cdigo postal como el cdigo del estado para determinar
si el cdigo postal debe ser de cinco dgitos, de nueve, o si debe ser un
cdigo postal de longitud seis. El sistema podra comparar el cdigo esta
tal y el postal para determinar si el postal est dentro del rango adecuado
(por ejemplo, si el cdigo estatal es NY entonces el postal debe empezar
con el dgito 1). La relacin entre los datos pudiera ser obvia para el ana
lista; sin embargo, requiere conocimientos detallados e ntimos de la apli
cacin que slo se pueden obtener del usuario.
Haga la edicin y la revisin de errores dependientes del usuario. Como
se indic anteriormente, suele ser buena dea que el sistema despliegue
un mensaje de explicacin cuando se detecta un error, pero slo si el
usuario no puede determinar por s mismo lo que hizo mal. Si tecle, por
ejemplo, un cdigo de tres dgitos, no es necesario que ei sistema des
pliegue un mensaje elaborado sobre de la longitud de los cdigos; sin em
bargo, s lo sera si el usuario teclea un cdigo de cinco dgitos y el
sistema espera uno de nueve. Note tambin que a) algunos usuarios son
ms conocedores que otros y pueden molestarse an ms rpido si tie
nen que ver largos y pomposos mensajes de error y, b) tras el uso repeti
tivo, incluso un novato se convierte en experto en algunas partes del
sistema. Por ello, es importante hacer que los mensajes de error sean
flexibles y, tal vez, que el usuario los pueda cambiar; lo ms fcil es com
binar mensajes cortos (que pueden consistir slo en enfatizar las entra
das errneas y sonar la alarma para atraer la atencin del usuario) y
mensajes largos (con texto explicativo y una referencia a alguna parte
apropiada del manual para el usuario). Vase tambin el inciso 7.
Permita que el usuario pueda (a) cancelar parte de la transaccin y, (b)
cancelarla toda. No es aconsejable suponer que el usuario siempre ter
minar de ingresar toda la transaccin sin que se interumpa. Con un sis
tema de cmputo por lotes esto no sucede: normalmente el sistema no ve
nada proveniente del usuario sino hasta haber manejado varias transac-
www.FreeLibros.org
436
ciones individuales.8 Pero para los sistemas en lnea es un asunto imp0r.

tante: el usuario puede haber ingresado el nombre y domicilio de un cler.
te antes de darse cuenta de que est trabajando con uno equivocado, p0r
lo que desea borrar todo y volver a empezar. O pudiera haber termina^
de ingresar la mayor parte de la informacin del cliente y luego se qa
cuenta de que escribi mal el nombre por lo que desea regresar a ese qa.
to y corregirlo sin perder todo el resto de la informacin que tecle.
7.
Proporcione un mecanismo de ayuda conveniente. Para los sistemas en

lnea es cada vez ms importante proporcionar al usuario un mecanismo
conveniente para obtener informacin sobre cmo usar el sistema. E n algunos casos, el mecanismo de ayuda simplemente proporciona una ex
plicacin si el usuario comete algn error; en otros puede usarse para
explicar los detalles de diversas rdenes o transacciones disponibles.
Existen muchas formas de realizar esto, y tanto el analista como el usua
rio deben investigar diversos ejemplos tpicos antes de tomar una de
cisin (la mayora de los paquetes de software disponibles para la IBM
PC y la Apple Macintosh tienen mecanismos de ayuda; se es un buen
inicio).
8.
Distinga entre sistemas guaidos por mens y sistemas dirigidos por rde
nes; s es apropiado, dle a escoger al usuario. Un sistema dirigido por
mens presenta una lista de opciones (o funciones, o transacciones, etc.j
alternativas; una vez que se escoge una, puede aparecer otro sub-menu,
que llevara a sub-mens de nivel inferior antes de que finalmente el sis
tema entre en accin. Un sistema dirigido por rdenes, por otro lado, es
pera que el usuario proporcione una directiva detallada (y a menudo
larga) indicando lo que quiere que el sistema haga por l. Los sistemas
dirigidos por mens se consideran ms amables con el usuario, porque
muestran todas las opciones disponibles; por tanto, un sistema dirigido
por mens se considera preferible para usuarios nuevos, o si debe interactuar con una gran variedad de usuarios de diferente preparacin y ni
vel de habilidad. Pero el usuario con experiencia lo considera tedioso,
porque muchas veces se requieren dos o tres interacciones diferentes (y
cada una toma un tiempo) antes de que el sistema finalmente se d por
enterado de lo que el usuario desea. Un usuario con experiencia general
mente prefiere un sistema dirigido por rdenes, para lograr lo que desea
lo ms rpidamente posible.
8 P e ro in c lu s o con un siste m a por lo te s , el u s u a rio p uede d a rs e c u e n ta q u e ha in g re s a d o datos por

e rro r a l s is te m a . C asi s ie m p re ser n e c e s a rio dare la p o s ib ilid a d d e d e s h a c e r o reg re sa r lo que me
ti . P e ro e s to d e b i d e s c u b rirs e durante la s e n tre v is ta s co n e i u s u a rio , y d e b ie ra s e r evidente ya en
e i D F D y la s e s p e c ific a c io n e s d e p ro c e s o p a ra e l s is te m a .
www.FreeLibros.org
9.
Si ei sistema est realizando un proceso largo, despliegue un mensaje al

usuario para que no crea que se detuvo. S el sistema tiene que llevar a
cabo clculos muy extensos, o si es probable que se retrase peridica
mente por el volumen de las entradas, es importante desplegar un men
saje apropiado al usuario; de otro modo, puede pensar que su terminal se
congel o se cay; que el sistema de cmputo fall, o que hubo una in
terrupcin en la corriente. Por lo menos, el sistema debe mostrar un
mensaje (por ejemplo, FAVOR DE ESPERAR - SE ESTA PROCESANDO)
a intervalos regulares. Sera mejor una serie de mensajes informando ai
usuario qu cantidad del trabajo se ha concluido y aproximadamente
cunto se tardar en completar todo.
10. Proporcione alternativas por omisin para las entradas estndar. En mu

chos casos, el sistema puede adivinar bastante certeramente el valor pro
bable de alguna entrada dada por el usuario; al proporcionar alternativas
por omisin se ahorra tiempo y actividad de tecleo al usuario. Este enfo
que es vlido para todo tipo de sistemas, pero sobre todo para los en l
nea, donde el usuario tal vez no sea un mecangrafo profesional. Un
ejemplo es la fecha: en muchas aplicaciones la fecha ms probable que el
usuario ingresar es la de hoy. O suponga que se est construyendo un
sistema de ingreso de pedidos, y ei usuario le dice que el 95% de ios
clientes viven en el rea local; entonces, cuando pida al usuario propor
cionar el nmero telefnico, el sistema debe suponer que la clave es la lo
cal, a menos de que se especifique lo contrario.
11. Aproveche el color y el sonido, pero no abuse. Las terminales modernas
tienen una variedad de colores y efectos de sonido que pueden ser tiles
para enfatizar diferentes tipos de entradas o para atraer la atencin del
usuario hacia aspectos importantes de la interfaz humana. Se podra uti
lizar el verde para todo el material que el sistema despliega; azul para to
das ias entradas proporcionadas por el usuario, y rojo para todos los
mensajes de error. Sin embargo, no abuse: muchos usuarios se molestan
si su pantalla parece rbol de Navidad. Lo mismo se aplica a los efectos
de sonido; una campana o alarma ocasional puede ser til, pero el usua
rio no quiere que la terminal produzca todos los efectos sonoros de la pe
lcula de La Guerra de ias Galaxias.
21,2.3
Diseo de las formas
El diseo de los formatos de entrada y salida de un sistema tradicionalmente

se conoce como diseo de formas, pues la mayor parte de los sistemas de los aos
SOy 70 requeran que el usuario codificara las entradas en formas de papel que lue
go se transcriban a tarjetas perforadas antes de ingresar al sistema de cmputo por
lotes. Pero Incluso en los sistemas en lnea actuales se requiere un poco de diseo
os formas; considere por ejemplo la situacin comn en la que las entradas del sis
www.FreeLibros.org
438
tema se originan en un cliente externo. El proporciona las entradas requeridas ||

nando la forma y envindola por correo a ios usuarios que nteractan con el siste
ma; la figura 21.4 muestra un ejemplo de una forma real. Se debe prestar atencin^
diseo de estas formas.
En ciertos casos, el analista puede recurrir a algn departamento interno de di
seo grfico o a un productor de formas externo para obtener ayuda; alternativametite, pudiera tener formas asociadas con el sistema existente que desee continuar
usando en el nuevo. Tambin habr muchas situaciones en las que el analista y sj
usuario diseen formas nuevas para un sistema nuevo. Aunque hay muchos estilos
diferentes para las formas, todas deben contener ia siguiente informacin bsica:
Ttulo, para distinguirla de cualquier otra. El ttulo usualmente se imprime

con letras grandes y resaltadas en la parte superior de la forma para qu6
el usuario sepa que es una forma de pedido, o bien una forma de repor
te de fallas.
Instrucciones, para decir ai usuario cmo poner la informacin necesaria

en la forma. Las instrucciones generales usualmente se colocan al princi
pio de la forma, cerca de la parte superior. Suelen colocarse las instruc
ciones especficas cerca, o bajo cada dato que se necesite escribir.
Cuerpo, es decir, ia parte principal de la forma, donde se ingresan los da

tos. Puede organizarse con un estilo abierto, o encajonado, o una combi
nacin de am bos. El e s tilo encajonado tpicam ente se usa para
informacin binaria (por ejemplo,"marque esta caja si desea que se aada
su nombre a nuestra lista de correo para anuncios de productos futu-os"!
o de formato fijo (por ejemplo, un nmero telefnico o cdigo postal). El
estilo abierto tpicamente se usa para informacin de longitud variable tal
como nombre o domicilio.
El decidir exactamente cmo debe distribuirse

y lo realizan mejor personas con experiencia en el
errores ms comunes del diseador novato es, por
ciente para la informacin requerida. Esto sucede
quieren informacin manuscrita.9
ia forma es un arte en s mismo

diseo de formas. Uno de los
ejemplo, no dejar espacio sufi
sobre todo con formas que re
Dependiendo de ia aplicacin, el analista puede disear formas individuales o

de especialidad. Las primeras suelen imprimirse en hojas sencillas y son adecuadas
para la gran mayora de las situaciones; con la disponibilidad de los sistemas de edi-
9 D e je p o r lo m e n o s un c e n tm e tro d e e s p a c io v e rtic a l p a ra c a d a re n g l n de in fo rm a c i n manuscrita

en una fo rm a . D e je c a s i un c e n tm e tro y a lg n m ltip lo d e m e d io c e n tm e tro p o r c a d a ln e a de In
fo rm a c i n m e c a n o g ra fia d a . A s e g re s e d e q u e el m e c a n g ra fo n o te n g a q u e re a lin e a r la mquina
c a d a v e z q u e p a s a a o tro re n g l n .
www.FreeLibros.org
1
soes
m.
crv uwrnacE
DESCaFTISN
SHip
rasa.
QFFSS
i i i
i i i
i i i
ORDERS
800/228-8910
Qood anywftem m U.S.
408/825-0465
MAIL ORDERS
PO BOX 911 Dsps.
[ATE
Cton
CP 938*2
i i I
I I l
I I I
O F O R D F.R
|
[ b l l
I I
I...L. l
I i I
I i I
susTcmi
SH1PPING/HANDUNG CHARCES
m s&e$r
(C&TOMOTtlKW'
Ts (Pisase Print)
lf stfp^tiaRifBS c ita re s calcisiated by aeight
To figure tits deSvify cftarge fe? suarder sppec
UPS Ground o r US ms, sistply asid tos sftippty
{) Sres% a t e tfegste
charge itssea n
f e each item orderet and add $3.00to tfie total.
ATr! lN
SHHW&MANDLING
Prf&ity smriss mh'm: $&\\ fe mm~

Osrfede Un BBtSissstsi UaM SMmk
| SBIP TO: (l difieren! fhan Bill To)

CUSOfeSR10NUMS(asi! BOSifsosmaiig\i
S3D0
TOTAL
If yoq reqwe deSvery ou& de tite continental Unit

ed States, pisase aod ofts of mesa specsal c te g e s
lo your orsfe mstead of u$ing t3 fabis at left.
Hzmii: cail f e duftjes.
Canasfe. ad 8%. SIS mnimum.
fora^n Qrzkrs: add 2!%. $35 ttinfe um
Apaymertts mus be in U.S. doflars.
Ubis: Foreign ordere sabjsct to FT rg^nctioas: cali
f e details.
lees Releas dass Rt guararses

rnseltisie srspsiS&ity;
pisas 6
3%m 6sitaste pradte
FgqiilOTem.
| METHOD OF PAYMENT
D E
DKT
ACCOUNT MO <Ofi CHASGE C W i
Figura 21.4: Ejemplo de una forma tpica
c i n d e escritorio y los programas d e diseo

d e n disear fcilmente sus propias formas.
de
fo rm a s ,
el usuario y el analista
pue
Las formas de especialidad son ms complejas y se crean con la ayuda de un

diseador de formas con experiencia (que normalmente se asocia con un productor
de formas). El ejemplo ms comn es una forma mltiple, que usa hojas de papel
carbn o papel especial de copia sin carbn. Los tipos de formas de especialidad
son:
www.FreeLibros.org
440
Formas empastadas en libros (por ejemplo, libros de pedidos de ventas)
Formas mltiples desprendiles, con un original y varias copias que Sg

pueden separar (por ejemplo, formas de cobro de tarjeta de crdito).
Formas continuas, que se llenan manualmente o por computadora.
Para correo: formas preimpresas insertas en un sobre, unidas como

una forma continua. La computadora puede entonces imprimir informa
cin estndar, tal como nombre y domicilio del cliente, que (por medio del
papel carbn) se imprime tanto en el sobre como en la carta que lleva
dentro.
Las formas de especialidad son, como se espera, mucho ms caras que las
sencillas; por lo que se debe tener cuidado de que no representen un costo impof.
tante del sistema. Las formas de especialidad deben producirse en cantidad razona
ble para mantener bajo el costo unitario: ei costo de imprimir 10,000 copias de una
forma de especialidad suele ser un 10% o 20% ms que el costo de imprimir 5000,
Se deben usar formas de tamao estndar para que la compaa impresora no tenga
que hacer recortes caros; la mayor parte de las formas estndar son de 8.5 por 11
o bien de 5.5" por 8.5.
21.2.4
C digos de entrada y salida
Como parte de la labor de especificar formatos de entrada y salida, el analista

muchas veces debe especificar cdigos, es decir, abreviaciones de la informacin
que sera difcil y tardado describir con detalle. Ejemplos de stos son los nmeros
del Seguro Social, cdigos postales, nmeros de ISBN para libros publicados y n
meros de identificacin de empleados que se asignan a las compaas en sus decla
raciones de impuestos.
Los ejemplos anteriores representan cdigos externos para la mayora de no
sotros; es decir, sin importar el tipo de sistema, tenemos que usar cdigos desarro
llados por el gobierno, C orreos y el Seguro Social. Pero a menudo existen
situaciones en las que se necesita designar cdigos nuevos asociados con el siste
ma mismo (por ejemplo, nmeros de cuenta de clientes, nmeros de refacciones,
nmeros de formas, cdigos de productos, cdigos de colores y nmeros de vuelos
de aerolneas). As como el diseo de formas es un arte, las tcnicas de codifica
cin son un rea especializada. Como se seala en [Gore y Stubbe, 1983], un mto
do de codificacin debe ser:
Expandible. Debe proporcionar espacio para entradas adicionales que pudieran reque
rirse.
Preciso. Debe id e n tifica r al artculo especfico.
Conciso. Debe se r breve pero describir adecuadamente al artculo.
www.FreeLibros.org
i
i
I
:
Conveniente. Debe ser fcil de co d ifica r y decodificar.
Con significado. Debe ser til para quienes io manejan. De ser posible debe indicar
algunas de las caractersticas del artculo.
Operable. Debe ser compatible con os mtodos p resentes y anticipados de proceso

de datos, manual o a mquina.
En algunos casos tal vez no sea necesario, deseable o prctico que el cdigo
(enga una relacin obvia con el artculo que describe. Un buen ejemplo es el nrrter0 de cliente, de cuenta o de empleado en muchos sistemas: el cdigo es simplemente un nmero escogido en secuencia. Sin embargo, tambin es comn que la
jcnica de codificacin reserve bloques de nmeros (o letras) para artculos dentro
de una categora comn; por ejemplo, un sistema de ingreso de pedidos puede usar
cuatro dgitos como nmero de producto, reservando los nmeros del 1 al 500 para
artculos estndar y del 501 al 999 para artculos especiales.
Es ms comn el cdigo de clasificacin, que usa grupos de dgitos (o letras)
dentro del cdigo para identificar clasificaciones mayores, intermedias o menores
dentro del artculo que se describe. Por ejemplo, para llamar a mi oficina en Lon
dres, marco los dgitos siguientes:
011-44-1-637-2182
Los primeros tres dgitos identifican ei nmero telefnico como internacional
(comparado con los correspondientes a llamadas dentro de los EUA.). Los siguien
tes dos son el cdigo de pas, siendo el 44 el cdigo del Reino Unido. El siguiente
dgito es el cdigo de Londres, anlogo al cdigo de zona de tres dgitos que se usa
en los EUA. Los siguientes tres representan un conmutador telefnico y a menudo
dan ai usuario astuto una buena idea del barrio de Londres en el que se localiza el
telfono. Y, finalmente, los ltimos cuatro identifican un telfono especfico.
Los cdigos alfabticos tambin se usan comnmente en sistemas de informa
cin. Muchos cdigos alfabticos son intentos mnemnicos, o auxilios de memoria,
que el usuario podr recordar fcilmente.10 Que el intento tenga xito o no depende
de la brevedad del cdigo (por ejemplo, dos dgitos en contraposicin con diez), de
la diversidad y disparidad de los datos mismos, y de la familiaridad del usuario con
10 Algunos cdigos alfabticos parecen ser todo lo contrario a m nem nicos; stos son ios que se
derivan de uno o ms a tributos dei dato. Un ejem plo es el cdigo que se encuentra en la etiqueta
postal de algunas revistas; el cdigo del subscriptor usualmente consta de una porcin dei apellido,
su domicilio, cdigo postai, fecha de vencim iento de la subscripcin y otros detalles. Como tai, cier
tamente puede no ser m nem nico: no hay m anera de que alguien recuerde un cdigo de 20 o 30
caracteres. Sin em bargo, una vez que se da el cdigo al sistema de cmputo se puede recuperar
el registro del su b scrip to r bastante rpido, io cuai puede ser m uy im portante para una base de da
tos de subscriptores de varios millones de registros. Para obtener ms inform acin acerca de estos
cdigos derivados, consulte ia forma GF20- 8093 de IBM, titulada Data P rocessing Techniques: Co-
www.FreeLibros.org
ing Methods.
442
stos. Por ejemplo, considere los cdigos de dos letras que se usan para dentifir
diferentes aerolneas; la mayora de os ciudadanos de los EUA inmediatamente r%
conoceran que AA representa a American Airlines, y que UA representa a Uniun
Airlines. Pero cuntos sabran que HW representa a Havasu Airlines y que AQ J
presenta a Aloha Airlines? Con los cdigos de tres letras hay mejor oportunidad d6
escoger cdigos mnemnicos, como o ilustran los cdigos que se usan para icfentif
car a aeropuertos. Casi todo mundo sabra que JFK quiere decir Aeropuerto John p
Kennedy de Nueva York, y que SFO es el aeropuerto de San Francisco. Pero aqyj
hay problemas a menos de que el usuario haya memorizado muchos cdigos q6
son todo menos mnemnicos (por ejemplo, ORD para OHare, en Chicago, y yy2
para el aeropuerto de Toronto).
Finalmente, algunos cdigos se autoverifican; es decir, contienen informacin
adicional (redundante) que puede usarse para verificar que se haya ingresado co
rrectamente. Un ejemplo comn de cdigo autoverificador es el que contiene un d
gito de verificacin, que usualmente se anexa ai final del cdigo numrico. Puede
calcularse en una variedad de formas, una de las cuaies se da a continuacin:
dgito-de-verificacin = 0
PARA cada dgito en el cdigo numrico
suma = dgito multiplicado por su nmero de posicin
d g ito v e rific a d o r = dgitoverificador + suma
FIN
HACER MIENTRAS haya ms de un dgito en dgito-de-verificacin
d g ito verificad o r = la suma de todos los dgitos en dgito-de-verificacin
FIN
Por ejemplo, si se tiene el cdigo numrico 9876, el dgito de verificacin se
calculara como (9*1) + (8*2) + (7*3) + (6*4), que resulta en 70. Sumando los dgitos
7 y 0 se obtiene un resultado final de 7 como dgito de verificacin. El objetivo no es
que el usuario haga todo el clculo, sino usar un cdigo que incluya un dgito de ve
rificacin (por ejemplo, 9876-7). Luego, cuando ei usuario ingresa el cdigo ai siste
ma, la computadora recalcula automticamente el dgito de verificacin esperado
(usando el algoritmo descrito anteriormente) y lo compara con el dgito de verifica
cin dado. Un error, usualmente significa que uno de los dgitos se transpuso cuan
do el usuario lo ingres.
21.3
IDENTIFICACION DE LAS ACTIVIDADES DE APOYO

MANUAL ADICIONAL
En el modelo esencial se supone la existencia de una tecnologa perfecta, que

significa, entre otras cosas, suponer que la tecnologa de implantacin nunca se
descompondr y nunca cometer un error. Los usuarios podran no estar dispuestos
a aceptar esto, y quin los culpara? Adems, el usuario podra decidir que ciertas
porciones del sistema automatizado esten bajo su propio control operacional (por
www.FreeLibros.org
grnplo una
0 una mimcomputadora para su area de trabajo) y preocuparse por

giles errores operacionales que su propio personal pudiera cometer. Adicionalênte. tal vez trabaje con datos financieros, en cuyo caso podran existir requisitos
1 aies (o requisitos impuestos por los auditores) para asegurar la integridad de las
ntradas, salidas y archivos del sistema. En la mayor parte de los casos, estas activdades de apoyo adicional se representarn por medio de nuevos procesos en el
ppp del modelo de comportamiento. En la figura 21.5 se muestra un ejemplo.
En general,
fectuosa
tenemos que preocupamos por la posibilidad de la tecnologa

en cuatro reas principales, como lo ilustra la figura 21.6.
de
ingreso de datos a l sistema. Si los datos de entrada se proporcionan por

medio de terminales de video conectadas con las computadoras principa
les usando lneas de telecomunicaciones, entonces es posible que algu
nas o todas las transacciones se pierdan o revuelvan. Lo mismo puede
suceder con casi cualquier tipo de entrada; por ejemplo, el operador de la
computadora podra dejar caer una o dos tarjetas, o uno de varios discos
flexibles podra no ser ledo por el sistema.
fee bse= en jna

PC controlada
/ REVISAR \
ERRORES \
\ EN LAS /
\ SALIDAS
F igura 2 1 .5 :
Verificacin manual
de erre i s
-
>\
Actividad de apoyo manual de revisin de errores
R e a liz a c i n de los clculos. Una vez ingresados los datos al sistema,

existe la remota posibilidad de que la computadora misma pudiera funcio
nar mal, y la posibilidad an mayor de que un error en los programas pu
diera producir un resultado incorrecto. Los errores de hardware pueden
ocurrir en un procesador individual o en ia interfaz entre varios en la con
figuracin del sistema.
www.FreeLibros.org
444
Almacenamiento a largo plazo de los datos. La mayor parte de los Si%.

mas guardan informacin durante iargos perodos en discos magnticos
cintas magnticas, discos flexibles, etc. Es posible que algunos (o tcxfc
estos datos se pierdan o destruyan debido a errores de hardware y/o Sc
ware. Los errores de hardware son problemas dei dispositivo mismo d
almacenamiento, o problemas de la conexin entre el procesador (CPU) y
el dispositivo. Los errores de software pueden ocurrir en los programas
de aplicacin desarrollados por el equipo del proyecto, o bien en el soft
ware de administracin de bases de datos comprado.
Salida de datos del sistema. Los problemas potenciales que se pueden

dar aqu son anlogos a los que se tienen con las entradas al sistema.
En algunos casos, las salidas deben transmitirse por lneas de telecomir
nicaciones, a menudo hacia la misma unidad de video que se us para
las entradas. En otros casos, las salidas se producen en cinta magntica
o en reportes en papel. En todos los casos es posible que se pierda in
formacin de salida o se altere incorrectamente como resultado de erro
res de hardware y/o software,
Qu debe hacerse al respecto de estas reas posibles de tecnologa defec

tuosa? Obviamente, depende en gran medida de 1) el nivel estimado de contabili
dad del hardware y software que se usa; 2) la naturaleza de la aplicacin del usuario
y, 3) los costos y cargos asociados con entradas o salidas defectuosas. Como es
obvio, esto amerita una discusin detallada entre el usuario, los analistas y el equipo
de implantacin; podra decidirse aadir cualquiera de lo siguiente ai modelo esen
cia! para vrselas con la tecnologa defectuosa:
Terminal de entrada
CPU 1
CPU 2
DISCO
Terminal de salida
www.FreeLibros.org
Figura 21.6: Posibles reas de tecnologa defectuosa
Entradas o salidas redundantes. En el caso ms extremo habra duplica

dos de las entradas desde dos fuentes distintas (por ejemplo, de dos
usuarios distintos ante dos terminales distintas). Adems, se pueden pro
ducir salidas duplicadas (por ejemplo, dos copias distintas de un reporte
de salida hechas con distintas impresoras). Este es un enfoque poco
usual, pero pudiera considerarse para aplicaciones extremadamente deli
cadas.
Tecnologa de procesador redundante. Los datos que el sistema mantie
ne pueden almacenarse, por duplicado, en dos discos o cintas diferentes.
Los clculos que se realizan podran hacerse, por duplicado, en dos pro
cesadores distintos. De hecho, podra requerirse incluso mayor redundan
cia: aunque un segundo procesador o disco perm ite que el sistema
contine si la primera unidad se descompone completamente, no protege
contra errores sutiles. Qu tal si el CPU 1 y el CPU 2 realizan el mismo
clculo (por ejemplo, el clculo de los intereses de una cuenta de aho
rros, o de la trayectoria de un misil para un viaje a la luna) y producen dis
tintos resultados? Cul est en lo correcto? En el caso extremo,
entonces, debe insistirse en procesadores por triplicado y almacenamien
to por triplicado, con una lgica de voto de mayora para determinar cu
les dos estn en lo co rrecto . Pero qu tal si las tres estn en
desacuerdo?
Redundancia interna. Una manera ms comn de manejar la tecnologa
defectuosa es mediante redundancia parcial. Por ejemplo, podra pedr
sele al empleado bancario que proporciona datos sobre depsitos en un
sistema bancario en lnea que d tanto el nmero de cuenta como el nom
bre de quien deposita. Aunque normalmente baste con identificar el re
gistro del cliente en el sistema, siempre cabe la posibilidad de que el
empleado lo ingrese incorrectamente, o que el nmero de cuenta se alte
re debido a algn error de telecomunicaciones, o a un error en la terminal
de video, o un error en el procesador. Alternativamente, el sistema po
dra requerir que el empleado ingresara slo el nmero de cuenta y verifi
cara si est correcto desplegando el nombre del cliente despus de
recuperar el registro.
Controles por ote (batch). Este enfoque se introdujo primeramente en
sistemas de cmputo por lotes en la segunda generacin, pero todava es
relevante en muchos de los sistemas actuales. Requiere que ei usuario
mantenga cuenta de las transacciones que ingresa al sistema, adems
del total acumulativo de los datos importantes en dichas transacciones.
En un sistema financiero, lo obvio sera contar la cantidad de cada tran
saccin. Mientras tanto, el sistema mantiene su propia cuenta al recibir
las transacciones; peridicamente, el sistema y el usuario comparan sus
cuentas para asegurar que no se ha perdido o alterado nada. Se puede
www.FreeLibros.org
446
usar el mismo enfoque con las salidas: el sistema puede mantener su pro.
pa cuenta del nmero de transacciones que ha dado como salidas, parg
luego compararlas con una cuenta manual proporcionada por el usuario
21.4
Verificaciones secuenciaes. Este enfoque se relaciona con el concepto

de controles por lote. El usuario asigna un nmero de secuencia q qe
transaccin a cada entrada, y el sistema verifica, al procesarlas, que es
tn en secuencia y que no se pierda ninguna transaccin. De manera similar, el sistema puede aadir un nmero de secuencia a cada salida que
produce, y el usuario verifica manualmente que no se hayan perdido.
ESPECIFICACION DE RESTRICCIONES OPERACIONALES
Finalmente, el equipo de implantacin tendr que decidir la combinacin de

hardware, sistema operativo, equipo de telecomunicaciones, lenguaje de programa
cin y estrategia de diseo para implantar mejor ios requerimientos. Pero esto ser
difcil de lograr sin alguna declaracin de restricciones operativas, que el modelo
esencial deliberadamente evita. Las cuestiones tpicas son:
Volumen de los datos. El usuario necesita especificar los volmenes de

transacciones de entrada y el tamao requerido de los almacenes de da
tos. Esto es importante sobre todo si hay variaciones importantes en los
volmenes de transacciones (por ejemplo, durante horas pico del da, o
pocas pico del ao). As, el usuario podra decir: normalmente procesa
mos 2,000 pedidos diarios, pero el voiumen salta a 4,000 pedidos diarios
durante el mes de diciembre. Adems, el usuario necesita estimar ei in
cremento de tasas de transaccin y requerimientos de almacenaje a lo
largo de la vida til estimada del sistema. Podra decir: el almacn de
INVENTARO debe poder manejar balances de 4,000 partes distintas
ahora, y esperamos estar manejando alrededor de 6,000 dentro de los
prximos 5 aos . En general, puede esperarse que la cantidad de datos
almacenados en un sistema de informacin aumente en aproximadamen
te un 10 por ciento anual.11
Tiempo de respuesta a las diversas entradas. Esto se puede plantear en

trminos absolutos, pero es ms realista hacerlo en trminos de probabili
dades: el 90 por ciento de todas las transacciones debe tener un tiempo de
respuesta menor a 2 segundos. En algunos casos, esto puede indicarse en
trminos de lmites de tiempo: el reporte XYZ debe producirse a ms tar
dar a las 8:00 cada maana, o todas las transacciones de depsitos de
ben procesarse antes de la media noche, diario, de modo que los clientes
puedan determinar su saldo desde sus sistemas bancarios caseros.
www.FreeLibros.org
11 Esta estim acin se basa en una encuesta de aproxim adam ente 500 instalaciones de cmputo de
ios EUA hecha por ientz y Sw anson en S oftw are M antenance M anagem ent (R eading, M ass.: Addison-W esiey, 1980).
Restricciones polticas sobre modalidades de implantacin. El usuario

pudiera, por motivos racionales o irracionales, especificar la marca de
hardware que se usar (o que se evitar), el lenguaje de programacin
(tiene que estar programado en Ada), los proveedores de telecomunica
ciones que se usarn, etc. Esto debe evitarse si fuera posible, pero espe
re por lo menos algunas presiones de este tipo. Note que es el
departamento de operaciones de la organizacin ei que puede imponer
las restricciones de implantacin; es decir, es probable que or algo por el
estilo de, bueno, este nuevo sistema parece bien, pero desde luego que
tiene que operar en la computadora principal de la corporacin, as que
asegrese de que no ocupe ms de 8 megabytes, y le asignaremos unos
discos.
Restricciones ambientales. El usuario que trabaja en el equipo de implan
tacin pudiera imponer restricciones de temperatura, humedad, interfe
rencia elctrica (RFI), consumo de energa, limitaciones de tamao, peso
o emisiones elctricas, vibracin, contaminacin, ruido, radiacin, y otras
restricciones ambientales. A veces no las mencionar explcitamente, s
lo supondr que el nuevo sistema operar de manera satisfactoria dentro
de su ambiente normal (por ejemplo, una refinera, una fbrica o una ofici
na). Por tanto, podra ser necesario documentar las caractersticas rele
vantes del am biente del usuario para b e n e ficio del equipo de
implantacin. O tai vez simplemente indique en el modelo de implanta
cin del usuario que ei sistema debe operar en el ambiente dei usuario, y
dejar que el equipo de implantacin deduzca por s mismo lo que eso
pueda significar.
Restricciones de seguridad y confabilidad. El usuario pudiera especificar
un tiempo promedio entre fallas (MTBF, por sus siglas en ingls), y tiem
po promedio necesario para la reparacin (MTTR) para el sistema. La
confabilidad requerida tambin puede expresarse en trminos de disponi
bilidad; por ejemplo, el usuario podra decir: No es costeable algo inferior
a un 99.5 por ciento de tiempo activo para este sistema.
Restricciones de seguridad. El usuario puede especificar una variedad de
restricciones enfocadas a minimizar ei uso no autorizado del sistema. Es
to puede incluir la consideracin de nmeros de cuenta y claves de acce
so (para que ios usuarios individuales tengan que identificarse). Tambin
puede Incluir mecanismos para evitar el acceso no autorizado a datos
confidenciales; algunos usuarios pueden tener permiso de leer registros
de varios almacenes, mientras que otros slo de modificar (o eliminar) da
tos existentes, y oros ms pudieran slo tener permiso de anexar regis
tros nuevos. El usuario podra solicitar mecanismos para evitar que
usuarios no autorizados realicen ciertas funciones en el sistema (por
ejemplo, no todo mundo debiera poder operar el sistema de nmina). Se
www.FreeLibros.org
448
podran imponer diversas medidas de seguridad a los datos que entran 0

salen del sistema; esto incluye, por ejemplo, la codificacin de datos
se transmiten por medio de lneas de telecomunicaciones.12 Y, por moti
vos de seguridad, se pudiera requerir que el sistema produzca un rastreo
de auditora: listado completo de todas las transacciones que ingresan al
sistema, las salidas que se producen, y tal vez incluso un registro de to.
das las modificaciones que se le hacen a los archivos.
21.5
RESUMEN
El modelo de implantacin del usuario a veces se describe como la zona fan

tasma entre el anlisis y el diseo estructurados. No lo puede hacer el analista so
lo, y es peligroso que l y el usuario lo desarrollen sin la participacin de los
diseadores y programadores que finalmente construirn el sistema. Aunque las
funciones, datos y comportamiento dependiente dei tiempo sean finalmente las ca
ractersticas ms importantes de un sistema de informacin, ia interfaz humana a
menudo es el rea que causa la mayor parte de las reacciones emocionales del
usuario. Formatos de entrada difciles, mensajes de error confusos y un tiempo da
respuesta lento pueden volver inaceptables para el usuario incluso las funciones
ms elegantes del sistema. Y tambin recurdese que las reatricciones de implanta
cin que el usuario impone (a menudo de manera inocente) pueden torpedear inclu
so al proyecto mejor administrado: tal vez simplemente no sea posible implantar el
sistema dentro de las restricciones sealadas por el usuario.
La labor de anlisis del sistema queda concluida una vez construido y revisado
el modelo de implantacin del usuario por usuarios, analistas y el grupo de disea
dores y programadores. Al llegar a este punto, suele ser necesario presentar ios re
sultados de la fase completa de anlisis del proyecto a la administracin, para
obtener la aprobacin de continuar con el diseo y la implantacin. La presentacin
debe incluir la informacin siguiente:
1.
El status actual del sistema existente (suponiendo que io haya).
2.
Los problemas (debilidades, funciones faltantes, etc.) que se identificaron

en ei sistema actual durante la encuesta inicial o ei estudio de factibilidad.
3.
Las soluciones alternativas que se identificaron.
4.
Una vista global del modelo esencial y el de implantacin del usuario, con
tanto detalle como la administracin requiera. Tpicamente, se presenta
el modelo de DFD de alto nivel y se proporcionan los componentes deta
llados para ser ledos con detenimiento posteriormente.
www.FreeLibros.org
12 La se guridad en as com putadoras es un tem a prim ordial por s m ism o y no se discute con deta
lle en e ste iibro. Para m s inform acin, consulte textos sobre seguridad y d e litos computacionales,
5.
Los costos y beneficios proyectados del nuevo sistema.13
6.
Las estimaciones de costo, programacin y recursos (horas de trabajo)

para las fases restantes dei proyecto.
7.
Las recomendaciones del equipo que realiza el proyecto o del analista.
Suponiendo que se d ia aprobacin de la administracin, el proyecto mismo

slo est comenzando: todava falta una gran cantidad de diseo, programacin y
prueba antes de que el usuario reciba finalmente el sistema que quera. Estas reas
se discuten en los siguientes captulos.
Marjorie Leeson, Systems Analysis and Design. Chicago: Science Research

Associates, 1981.
2,
Tom Gilb and Gerald Weinberg, Humanized input. Cambridge, Mass.: Winthrop
Publishers, 1977.
3,
James Martin, Design o f Man-Machine Dialogues. Englewood Ciiffs, N.J.:

4,
Marvin Gore and John Stubbe, Elements o f Systems Analysis, 3a edicin Dubuque, lowa: wiiliam C. Brown Co., 1983.
5,
Data Processing Techniques: Coding Methods, Forma GF20- 8093. White

Plains, N.Y.: IBM Technical Publications Department.
1.
Cules son las tres cosas principales que describe el modelo esencial de un
sistema?
2.
Por qu no suele ser suficiente ia informacin del modelo esencial para que
los diseadores y programadores comiencen a implantar el sistema?
3.
Qu informacin adicional necesita aadirse ai modelo esencial?
4.
Qu es un modelo de implantacin del usuario? Cules son sus principales

componentes?
5.
Cules son las dos cuestiones de implantacin principales que generalmente

preocupan mucho a los usuarios en un proyecto de un sistema de informa
cin?
www.FreeLibros.org
13 Los clculos de co sto-beneficio se discuten en el A pndice C.
450
6.
Defina el concepto de frontera de automatizacin de un sistema.

trmino o sinnimo puede usarse?
Qu otrQ
7.
Por qu se preocupan los usuarios por el formato de las entradas y salidas

de un sistema de informacin?
8.
D cuatro ejemplos de cuestiones de formato (que involucren entradas, sali

das, o ambas) que e! usuario desee especificar como parte del modelo de im
plantacin del usuario.
9.
D tres ejemplos de cuestiones de formato asociadas con los sistemas en l

nea que un usuario quisiera especificar como parte de modelo de implantacin
del usuario.
10.
Cmo afecta la introduccin de las computadoras personales e trabajo que

debe hacer el analista para desarrollar el modelo de implantacin del usuario?
11.
D tres ejemplos de preguntas que se necesite responder en el modelo de im

plantacin del usuario si va a haber computadoras personales controladas por
el usuario como parte de la implantacin del sistema.
12.
Cmo afecta la introduccin de lenguajes de cuarta generacin en muchas

organizaciones el trabajo que debe realizar el analista para desarrollar el mo
delo de implantacin del usuario?
13.
Cmo afecta el concepto de creacin de prototipos el desarrollo dei modelo

de implantacin del usuario en un proyecto tpico de desarrollo de sistemas?
14.
Cmo afecta la posible compra de paquetes de software comerciales el desa

rrollo del modelo de implantacin de usuario en un proyecto tpico de desarro
llo de sistemas?
15.
Qu error cometen muchas organizaciones al desarrollar el modelo esencial

en una situacin donde esperan usar un paquete de software comercial?
16.
Cules son los tres casos extremos qus pueden ocurrir cuando se est deter
minando la frontera de automatizacin en un sistema de informacin?
17.
Bajo qu condiciones es probable que ei usuario no se preocupe demasiado

acerca de dnde vaya a quedar la frontera de automatizacin en un proyecto
de desarrollo de sistemas? Qu tan probable cree que esto sea en una orga
nizacin tpica?
18.
Bajo qu condiciones es probable que el usuario se decida por un sisteme

completamente automatizado al estarse determinando la frontera de automati
zacin, con todas las funciones realizadas por la computadora y todos los da
tos almacenados en forma computarizada?
www.FreeLibros.org
19.
Bajo qu condiciones es probable que el usuario se decida por un sistema

completamente manual al estarse determinando la frontera de automatizacin?
Qu tan probable cree que sea?
20.
Cuntas fronteras alternas de automatizacin cree que deba explorar con los
usuarios el equipo que realiza el proyecto, antes de decidirse finalmente por
alguna? Justifique su respuesta.
2 1.
Desde el punto de vista del analista, qu sera lo ms sencillo que podra su

cedera a los procesos y datos que se hayan colocado fuera de la frontera de
automatizacin una vez determinada sta?
22. Qu es lo ms probable que tenga que hacer el analista con los procesos y
datos manuales despus de determinarse la frontera de automatizacin?
23. Cules son las tres cuestiones principales que se deben tratar cuando se de
fine la frontera de automatizacin en el modelo de implantacin del usuario?
24. Dnde debe documentar el analista los detalles de la mayora de las cuestio
nes de automatizacin que se discuten con el usuario?
25. D dos ejemplos de restricciones de implantacin posibles respecto a algn
dato que pueda determinarse como parte de la frontera de automatizacin.
26. Cmo puede usarse de manera efectiva el diagrama de transicin de estados
durante el desarrollo del modelo de implantacin de usuario?
27. Qu tipo de actividades de apoyo manual podra requerirse especificar du
rante el desarrollo del modelo de implantacin del usuario?
28. Cules son los cinco tipos principales de restricciones operacionales posibles
sobre un sistema que deben especificarse en el modelo de implantacin del
usuario?
29. Por qu es importante especificar en el modelo de implantacin del usuario el
volumen de datos que el sistema debe manejar?
30. D tres ejemplos de restricciones polticas que puedan imponerse a un siste
ma como parte del modelo de implantacin del usuario.
31. El cajero automtico de su banco es un sistema dirigido por menus o por r
denes? Cules son las ventajas y desventajas del enfoque tomado por el
sistema?
www.FreeLibros.org
PARTE SV: SEGUIMIENTO
Para diseos com pactos y ensam bles enredosos,

utilcese alguna fu e rza natural,
e xce p cionalm ente d e sarrollada y no convencional,
que produzca sensacin,
y continuam ente en m ovim iento.
De enorm e fu e rza y no conform ista,
sin co n sideracin dei fracaso.
Fuerza no restrin g id a que al d e sa rro lla rse rpido e xtingue su form a original.
A daptacin de un poem a de John Dryden,
A bsa/om a n d Achitophel, 1680.
En este capitulo ce aprender:

1. Los tres niveles del diseo de sistemas.
2. Los tres criterios principales para evaluar el diseo
de un sistema.
3. Cmo dibujar un diagrama de estructura.
4. Cmo usar el acoplamiento y la cohesin para
evaluar un diseo.
www.FreeLibros.org
452
PASANDO AL DISEO 453
U n a vez completado el modelo de implantacin del usuario concluye oficial

mente la labor de anlisis de sistemas. Ms all de ese punto, todo se vuelve cues
tin de implantacin. La parte visible de esta labor es la programacin y la prueba,
flue discutiremos en el Captulo 23. Sin embargo, la programacin debe ir precedida
p0r una actividad de nivel superior: el diseo.
Como analista, puede no sentir inters por los detalles del diseo de sistemas
o de programas; sin embargo, como se vio en el captulo anterior, la labor del analis,a y a del diseador no siempre se pueden separar. Sobre todo en el rea del model0 je im plantacin del usuario, el analista debe asegurarse de entender los
requerimientos del usuario, mientras que el diseador debe asegurar que dichos re
querimientos se puedan implantar de manera realista con la tecnologa computacio
nal actual. Por ello, es importante entender el proceso que enfrenta el diseador
c u a n d o el analista termina su labor.
Existe otra razn para tener inters en el diseo de sistemas: tal vez le toque
facerlo. Sobre todo en los sistemas pequeos y medianos, a menudo se espera que
el mismo individuo documente ios requerimientos del usuario y adems desarrolle el
diseo. Por ello, se puede esperar que decida sobre la mejor manera de asociar el
modelo de los requerimientos dei usuario en diferentes configuraciones de procesa
dores; tal vez tenga que decidir cmo implantar de la mejor manera el modelo lgico
de datos (que se document con los DER) con un sistema de administracin de ba
ses de datos; y tal vez tenga que decidir cmo asignar a las funciones del sistema
las distintas tareas dentro de cada procesador.
No es propsito de este libro discutir las actividades del diseo de sistemas
con gran detalle; esto lo logran mejor los textos dedicados al tema, tales como [Page-Jones, 1988], [Yourdon y Constantine, 1989], [Ward y Mellor, 1985], [Jackson,
1975], [Orr, 1977], y otros. Sin embargo, examinaremos brevemente las principales
etapas del diseo y algunos de los objetivos ms importantes que el diseador de
sistemas debe tratar de lograr. Dado que el diseo de sistemas y de programas son
de hecho materias en s, definitivamente examine las referencias que se dan al final
de este captulo si requiere ms informacin.
22.1
LAS ETAPAS DEL DISEO
La actividad de diseo involucra el desarrollo de una serie de modelos, de for

ma similar a la que ei analista desarrolla modelos durante la fase de anlisis de un
proyecto. Los modelos especficos de diseo y su relacin con los modelos de anli
sis que se discuten en este libro se ilustran en la figura 22.1.
Los modelos ms importantes para el diseador son el modelo de implantacin
de sistemas y el modelo de implantacin de programas. El modelo de implantacin
de sistemas se divide luego en un modelo del procesador, y uno de tareas.
www.FreeLibros.org
454
EL MODELO ESENCIAL
TAREAS
www.FreeLibros.org
Figura 22.1: Modelos de anlisis y de diseo
^ 1.1
El m odelo del procesador
La primera tarea que enfrenta el diseador de sistemas es decidir cmo asigarel modelo esencial (o para ser ms exactos, la parte automatizada del modelo de
^plantacin del usuario) a las piezas principales de hardware y software del siste
ma, En el nivel del modelo del procesador, e! diseador del sistema trata principaimeite de decidir cmo se asignar el modelo esencial a los distintos procesadores
(CPU) y cmo deben comunicarse entre s. Existe tpicamente una variedad de op
ciones:
El modelo esencial completo se le puede asignar a un solo procesador.

Esto se conoce como la solucin de computadora principal.
Cada burbuja de la figura 0 del DFD del modelo esencial se puede asig
nar a un procesador distinto (normalmente una mini o microcomputadora).1 Esto se conoce como la solucin distribuida.
Se puede escoger una combinacin de computadoras principales, minis y

micros para minimizar costos, maximizar confiabilidad o lograr algn otro
objetivo.
As como se deben asignar procesos a los componentes apropiados de hard

ware, los almacenes de datos se deben igualmente asignar. El diseador debe de
cidir si un almacn se realizar como base de datos en el procesador 1 o el 2. Dado
que la mayor parte de los almacenes se comparten entre muchos procesos, tam
bin debe decidir si se deben asignar copias del almacn a diferentes procesado
res. La actividad de asignar procesos y almacenes a los procesadores se ilustra en
la figura 22.2.
Observe que cualquier implantacin diferente a la de un solo procesador invo
lucrar algn mecanismo de comunicacin entre procesadores; lo que tradicional
mente hemos mostrado como flujos de datos ahora debe especificarse en trminos
fsicos. Algunas de las opciones disponibles al diseador del sistema para comuni
cacin de procesador a procesador son:
Conexin directa entre procesadores. Esto puede implantarse conectan

do los procesadores mediante un cable, un canal o una red local. Este ti
po de comunicacin generalmente permite que los datos se transmitan de
un procesador a otro a velocidades que van desde los 50,000 bits por se
gundo (abreviado como 50KB) a varios millones de bits por segundo.
1 Note que esto no es realista para algo que no sea un siste m a trivial, dada la te cn o lo g a de com
putadoras de fines de ios aos 80. Si un sistem a tu vie ra 500 burbujas de nivel in fe rio r en su DFD
de modelo esencial, sera rea lista co n sid e ra r la im plantacin del sistem a con 500 procesadores
separados? Esto cam biar para m ediados de los aos 90.
www.FreeLibros.org
456
PASANDO AL DISEO
Figura 22,2: A signacin de procesos y alm acenes a los procesadores
Enlace de telecomunicaciones entre procesadores. Esto es comn si los

procesadores estn separados fsicamente por algunos cientos de me
tros. Dependiendo de la naturaleza del enlace de telecomunicaciones, se
transmiten datos entre procesadores a velocidades que van desde 300
hasta 50,000 bits por segundo.
Enlace indirecto entre procesadores. Los datos pueden escribirse en cin

ta magntica, disco flexible, tarjetas perforadas o algn otro medio de al
macenamiento en un solo procesador y luego ser llevados fsicamente al
otro para ser empleados como entradas.
El ltimo caso es un tanto extremo, pero ilustra un punto importante: la comu

nicacin de procesador a procesador generalmente es mucho ms lenta que la co
municacin entre procesos (burbujas) dentro de un mismo procesador. Por tanto, el
diseador generalmente tratar de agrupar procesos y almacenes que tienen gran
volumen de comunicacin dentro del mismo procesador.
www.FreeLibros.org
Ei diseador debe tomar en cuenta varios factores al hacer estas asignacio

nes. Tpicamente, las cuestiones principales son:
Costo. Dependiendo de la naturaleza del sistema, pudiera ser o no ser

ms barata una implantacin de un solo procesador. Para algunas aplica
ciones, la solucin ms econmica puede ser un grupo de microcomputadoras de bajo costo; para otras sera ms prctico y econmico hacer la
implantacin en la computadora principal existente en la organizacin.2
Eficiencia. El diseador de sistemas generalmente se preocupa por el

tiempo de respuesta de los sistemas en lnea y por la longitud del ciclo
para los sistemas de cmputo por lote. Por tanto, debe escoger procesa
dores y dispositivos de almacenamiento de datos suficientemente rpidos
y poderosos para satisfacer los requerimientos de desempeo en el mo
delo de implantacin del usuario. En algunos casos puede escoger una
implantacin de mltiples procesadores para que las diferentes partes del
sistema se ejecuten de manera paralela, acelerando as el tiempo de res
puesta. Al mismo tiempo debe preocuparse por la ineficiencia de la co
municacin de procesador a procesador, como se discuti anteriormente.
Por ejemplo, suponga que el diseador ve que el sistema contiene una
funcin de edicin y una de proceso, como muestra la figura 22.3. Al po
ner cada funcin en un procesador aparte, sabe que se podr editar una
transaccin mientras simultneamente lleva a cabo el proceso de otra, me
jorando as la eficiencia global del sistema. Por otro lado, las transaccio
nes editadas se tendrn que mandar de un procesador a otro y esto puede
ser muy eficiente si se hace a travs de una conexin directa, o puede ser
muy ineficiente si la comunicacin se realiza mediante lneas de telecomu
nicacin lentas.
Seguridad. E! usuario final podra tener requerimientos de seguridad que

dicten que algunos (o todos) los procesadores y/o datos delicados se co
loquen en lugares protegidos. Estos requerimientos tambin dictaminan
la naturaleza (o la ausencia) de la comunicacin de procesador a proce
sador. Por ejemplo, el diseador podra estar impedido de transmitir da
tos de un procesador a otro mediante lneas telefnicas ordinarias si la
informacin es confidencial.
2 Tenga en m ente que existe un presupuesto para to d o el proyecto, que debi d e term in a rse com o
parte del p roceso de anlisis (ver el C aptulo 5). Por ello, el d ise a do r debe e sco g er el sistem a
ms eficiente que se ajuste al presupuesto. Sin em bargo, te n g a en m ente ei hecho de que los pre
supuestos pueden cam biar: los que se desarrollaron d u ra n te la fase de an lisis del p royecto fueron
slo estim aciones y pueden e sta r sujetas a revisin si el d ise a d o r m uestra que se necesita m s di
nero para lo g ra r una im plantacin aceptable.
www.FreeLibros.org
458
PASANDO AL DISEO
transaccin
mensaje
de error
Figura 22,3: C om unicacin de procesador a procesador
Confiabilidad. El usuario final tpicamente especifica los requerimientos

de confiabilidad para un nuevo sistema. Estos requerimientos pueden ex
presarse en trminos de tiempo promedio entre fallas (MTBF), tiempo pro
medio de reparacin (MTTR) o disponibilidad dei sistema.3 En todo caso,
esto podra tener influencia dramtica sobre el tipo de configuracin de
procesadores que se escoja. Podra decidirse separar los procesos en di
ferentes procesadores para que haya siempre una porcin del sistema
disponible, incluso si otras partes se vuelven inoperables por fallas de
hardware. Como alternativa, se puede decidir tener copias redundantes
de procesos y/o datos en mltiples procesadores, tal vez incluso con pro
cesadores extra que pueden usarse en caso de falla. Esto se muestra en
la figura 22.4; incluso si llega a fallar el procesador activo (lo cual es tal
vez ms probable an, dado que se trata de una computadora principal
grande y compleja), los procesadores individuales de edicin pueden con
tinuar operando, recolectando transacciones, editndolas y almacenndo
las para pro cesa rla s posteriorm ente .
De m anera sim ila r, si se
descompone uno de los procesadores de edicin, los dems pueden con
tinuar operando.
Restricciones polticas y operacionales. La configuracin de hardware

puede verse influenciada tambin por restricciones polticas impuestas di
rectamente por el usuario final, por otros niveles de administracin dentro
3 La d isp o n ib ilid a d del sistem a usualm ente se define com o el porcentaje de tiem po en ei que est
d isponible. Puede ca lcu la rse con base en el M TBF y el M TTR de la siguiente form a:
www.FreeLibros.org
D isponibilidad = M TBF / (M TBF + MTTR).
j
I
I
:
'
de la organizacin o por el departamento de operaciones a cargo del

mantenimiento y operacin de todos los sistemas de cmputo. Esto pue
de llevar a la eleccin de una configuracin especfica de hardware, o ex
cluir la eleccin de ciertos proveedores. De manera similar, se pueden
presentar restricciones ambientales (por ejemplo, temperatura, humedad,
exposicin a radiaciones, polvo/tierra, vibraciones), y esto puede tener
una influencia enorme sobre la configuracin de procesadores que se es
coja.
respuesta
Figura 22.4: Procesadores m ltiples para m ayor co n fiabilid ad

22.1.2
El m odelo de tareas
Una vez que se han asignado procesos y almacenes a los procesadores, el di

seador debe, procesador por procesador, asignar procesos y almacenes a las
tareas individuales de cada uno. La nocin de tarea es comn a casi cualquier mar
ca de hardware de computadora, aunque la terminologa difiera de un proveedor a
otro: algunos usan el trmino particin y otros punto de control. Sin importar el trmino, a figura 22.5 muestra cmo divide un procesador tpico su espacio de almacenamiento disponible en reas separadas, donde cada una se administra con un
sistema operativo central. El diseador generalmente tiene que aceptar el sistema
operativo del proveedor (aunque tal vez tenga posibilidad de escoger entre diversos
sistemas operativos para una computadora dada), pero s tiene la libertad de decidir
cules porciones del modelo esencial asignadas a dicho procesador deben asignar
se a tareas individuales dentro de ste.
www.FreeLibros.org
460
PASANDO AL DISEO
SISTEMA OPERATIVO
TAREA 1
TAREA 2
TAREA 3
Figura 22.5: O rganizacin de las tareas dentro de un procesador
Observe que los procesos dentro de un mismo procesador pueden tener nece
sidad de comunicarse mediante alguna forma de protocolo de comunicacin entre ta
reas. El mecanismo para hacerlo vara de un proveedor a otro, pero sucede de
manera casi universal que la comunicacin se realiza a travs del sistema operativo
del proveedor, como ilustra la figura 22.6. As como la transmisin de datos de un
procesador a otro es relativamente lenta e ineficiente, la comunicacin de datos (o
seales de controi) de una tarea a otra dentro del mismo procesador tambin es ine
ficiente. La comunicacin entre procesos en la misma tarea usualmente es ms efi
ciente. Por eso, el diseador generalmente trata de mantener los procesos cen
mayor volumen de comunicacin dentro de la misma tarea.
Dentro de un procesador individual, no siempre est claro si las actividades
ocurren de manera sicronizada o no; es decir, no siempre queda claro si est suce
diendo una cosa o muchas a la vez. Tpicamente, cada procesador individual slo
tiene un CPU, que puede estar ejecutando instrucciones para un proceso a la vez;
sin embargo, si un proceso est esperando entradas o salidas provenientes de un
dispositivo de almacenamiento (por ejemplo, disco, cinta, terminal de video, etc,), el
sistema operativo del procesador puede pasarle el control a otra tarea. Por tanto, I
diseador puede considerar cada tarea como una actividad independiente no sincro
nizada.
22.1,3
El m odelo de im plantacin de program as
Finalmente llegamos al nivel de una tarea individual; hasta aqu el diseador

ya logr completar dos niveles de asignacin de procesos y almacenamiento de da
tos. Dentro de una tarea individual, la computadora opera de una manera no sitiero-
www.FreeLibros.org
slo se puede llevar a cabo una actividad a la vez. El modelo ms comn de

de la actividad en una sola unidad sincronizada es el diagrama de es
tructura, que muestra la organizacin jerrquica de mdulos dentro de una tarea. La
figura 2 2 .7 muestra ios principales componentes de un diagrama de estructura.
izada:
org a n iz a c i n
^ ^ S I S T E M A OPERATIVO
mensaje p a ra ^
la tarea 3
*
/ mensaje de
' la tarea 1
TAREA 1
TAREA 2
TAREA 3
Figura 22.6: C om unicacin entre tareas dentro de un procesador
www.FreeLibros.org
Figura 22.7: Componentes de un diagrama de estructura
462
PASANDO AL DISEO
Debe leerse este pequeo diagrama de estructura de ia forma siguiente:
Ei mdulo A es el mdulo ejecutivo del nivel superior del sistema qUe

consta de los mdulos A y B. La razn por ia cual A se identifica como el
mdulo de nivel superior no es porque est topolgicamente por encima
del mdulo B, sino porque ningn otro mdulo lo llama. El mdulo B, p0r
otro lado, se llama subordinado del mdulo A, (El mdulo A es llamado Q
invocado por el sistema operativo de la computadora).
El mdulo A contiene una o ms instrucciones ejecutables, incluyendo

una llamada al mdulo B. Esta llamada puede hacerse como una declara
cin CALL en lenguaje FORTRAN. O una declaracin PERFORM o CALI
USING de COBOL. O simplemente invocando el nombre de B en otros
lenguajes. El diagrama de estructura evita deliberadamente describir
cuntas veces llama el mdulo A al B. Eso depende de la lgica interna
del programa dentro del mdulo A. Por tanto puede haber una instruccin
del siguiente tipo dentro del mdulo A:
SI comienza-guerra-nuclear
LLAMA Mdulo-B
EN O T R O C A S O
en cuyo caso el mdulo B pudiera no llamarse jams. Pero tambin puede

existir una instruccin del siguiente tipo en el mdulo A:
HACER MIENTRAS haya ms pedidos en el archivo
PEDIDOS
LLAMA Mdulo B
FIN
en cuyo caso el mdulo B puede llamarse miles de veces.
Cuando se llama al mdulo B, la ejecucin del mdulo A se suspende. El

mdulo B se empieza a ejecutar en su primera declaracin ejecutable.
Cuando termina, sale o regresa al mdulo A. El mdulo A contina enton
ces su ejecucin en el punto donde la suspendi.
El mdulo A puede o no pasar parmetros de entrada al mdulo B como

parte de la llamada, y el mdulo B puede regresar o no parmetros de sa
lida cuando regrese al mdulo A. En el ejemplo que se muestra en la fi
gura 22.7, el mdulo A pasa los parmetros X y Y al mdulo B, y ste le
regresa los parmetros P y Q. Las definiciones detalladas de X, Y, P y Q
normalmente se deben encontrar en un diccionario de datos. La mecni
ca de la transmisin de los parmentros vara de un lenguaje de progra
macin a otro.
www.FreeLibros.org
En la figura 22.8 se muestra un ejemplo de un diagrama de estructura comple!0 Note que contiene cuatro niveles de mdulos; esto normalmente representara
yn programa de alrededor de quinientas a mil instrucciones, suponiendo que cada
yidulo representa alrededor de cincuenta a cien.
M O D U LO
MODULO
C
M O D U LO
c a r c te r
M O DULO
D
c a r c te ^ O ^
c a r c te r
LE E R
CARACTER
E S C R IB IR
| CARACTER
\
\
. . 'V
LE E R
R E G IS T R O
EXTRAER
CARACTER
L ._ .
......................................
V
INSERTAR CA
RACTER EN
E L R E G IS T R O
E S C R IB IR
R E G IS T R O
Figura 22.8: Ejem plo de diagram a estructurado

Existe una pregunta obvia al llegar aqu: Cmo transforma el diseador un
modelo de red de procesos en el diagrama de flujo de datos en el modelo sincroniza
do representado por el diagrama de estructura? Varios textos sobre diseo de siste
mas, Incluyendo [Page-Jones, 1988] y [Yourdon y Constantine, 1989], discuten esta
cuestin con gran detalle. Como ilustra ia figura 22.9, hay una estrategia de recetas
para transformar el modelo de red de flujo de datos en un modelo de diagrama de
estructura sincronizado; de hecho, la estrategia generalmente se conoce como dise
o centrado en la transformacin. Esta es tan slo una de diversas estrategias para
convertir un modelo de red de flujo de datos en un modelo jerrquico sincronizado;
[Page-Jones, 1988], [Yourdon y Constantine, 1989] y [Ward y Mellor, 1985] discuten
varias estrategias de stas. Note que cada burbuja de proceso en el diagrama de
flujo de ia figura 22.9 se convierte en un mdulo en el diagrama de estructura deriva
4 Desde luego, un m dulo llam ado EXTRAER C A R AC TER no suena com o si requiriera de 50 a 100
instrucciones; tal vez requiera slo dos o tres en un lenguaje program acin de alto nivel tpico. En
un nivel de lenguaje cercano a la m quina, sin em bargo, tp ica m e n te se requeriran m uchas ms.
www.FreeLibros.org
464
PASANDO AL DISEO
do; sta es una situacin realista si los procesos son relativamente pequeos y s^
pies (por ejemplo, si la especificacin del proceso ocupa menos de una pgina de
lenguaje estructurado). Adems de! mdulo que realiza los procesos de flujo de datos, es evidente que el diagrama de estructura tambin contiene mdulos destinados
a coordinar y administrar la actividad global, y mdulos que se encargan de traer entradas al sistema y obtener salidas de l.
D ia g ra m a d e flu jo de
d a to s a b s tra c to
M O DULO
E JE C U T IV O
ti
OBTENER
U N A Y
' L
P R O D U C IR
UNA Q
PRODUCIR
O BTENER
U N A X
U N A R
D ia g ra m a de estructura derivada
www.FreeLibros.org
Figura 22.9: E strategia de diseo centrada en transform aciones
Otras estrategias de diseo utilizan el diagrama de entidad-relacin u otras

formas de diagramas de estructura de datos como punto de partida para obtener ei
diagram a de estructura apropiado; vase [Jackson, 1975] y [Orr, 1977] para ms in
form acin acerca de estas estrategias de diseo.
22.2
METAS Y OBJETIVOS DEL DISEO
Adems de lograr ios objetivos que se especifican en el modelo de implanta

cin del usuario, el diseador tambin se ocupa de la calidad global del diseo. La
capacidad que los programadores exhiban para implantar un sistema de alta calidad
y libre de errores depende en gran medida de ia naturaleza del diseo; de manera
similar, la capacidad de los programadors de mantenimiento para realizar cambios
eE1 el sistema despus de haberlo puesto en operacin depende de la calidad del di
seo.
El campo del diseo estructurado ofrece guias para ayuda al diseador a de
terminar los mdulos, y sus interconexiones, que mejor realizarn los requerimientos
especificados por el analista; todos libros que se ennumeran ai final de este captulo
detallan estas pautas. Las dos reglas ms importantes son las referentes al acopla
miento y ia cohesin; a continuacin se discuten stas y algunas otras reglas comu
nes.
Cohesin. Grado en el cual los componentes de un mdulo (tpicamente

las instrucciones individuales que conforman un mdulo) son necesarios y
suficientes para llevar a cabo una sola funcin bien definida. En la prcti
ca, esto significa que el diseador debe asegurarse de no fragmentar ios
procesos esenciales en mdulos, y tambin debe asegurarse de no juntar
procesos no relacionados (que se representan por burbujas en el DFD) en
mdulos sin sentido. Los mejores mdulos son aqullos que son funcionaimente cohesivos (es decir, mdulos en los cuales cada instruccin es
necesaria para poder llevar a cabo una sola tarea bien definida). Los pe
ores mdulos son los que son coincidentalmente cohesivos (es decir, cu
yos cuyas instrucciones no tienen una relacin significativa entre uno y
otro).5
Acoplamiento. Grado en el cual los mdulos se interconectan o se rela

cionan entre ellos. Entre ms fuerte sea el acopiamiento entre mdulos
en un sistema, ms difcil es implantarlo y mantenerlo, pues entonces se
necesitar un estudio cuidadoso para la modificacin o cambio y modifi
cacin de algn mdulo o mdulos. En la prctica, esto significa que ca
da mdulo debe tener interfases sencillas y limpias con otros, y que se
5 Algunos e je m p lo s de m d u lo s fu n cio n a lm a e n te c o h e s iv o s son C A LC U LA R -R A IZ -C U A D R A D A ,

C ALCU LAR-SALAR IO -N ETO y V A L ID A R -D O M IC IL IO -D E L -C LIE N T E . Un e je m p lo de uno co inci^dentalm ente cohesivo es F U N C IO N ES-M ISC ELA N EA S.
www.FreeLibros.org
466
PASANDO AL DISEO
debe compartir un nmero mnimo de datos entre-mdulos. Tambin sinnifica que un mdulo dado no debe modificar la lgica interna o los datos
de algn otro mdulo; lo que se conoce como una conexin patolgica
(La temida declaracin ALTER de COBOL es un buen ejemplo.)
Tamao del mdulo. De ser posible, cada mdulo debe ser lo suficiente
mente pequeo como para caber en una sola pgina (o para que pueda
desplegarse en una sola pantalla). Desde luego, a veces no es posible
determinar qu tan grande va a ser un mdulo hasta haberlo escrito, pero
las actividades iniciales de diseo a menudo darn al diseador una bue
na pista de que el mdulo va a ser grande y complejo. Si es as, debe
partirse en uno o ms niveles de submdulos. (En raras ocasiones, ios
diseadores crean mdulos que son triviales. Por ejemplo, mdulos que
consisten en slo dos o tres renglones de cdigo. En este caso, pueden
juntarse varios en un solo supermdulo mayor.)
Alcance del control. El nmero de subordinados inmediatos que un m

dulo administrador puede llamar se conoce como el alcance del control.
Un mdulo no debe poder llamar a ms de una media docena de mdulos
de nivel inferior. La razn es evitar la complejidad: si el mdulo tiene, di
gamos, 25 mdulos de nivel inferior, entonces probablemente contendr
tanta lgica compleja de programa (en la forma de declaraciones Si ani
dadas, o de iteraciones HACER-MIENTRAS anidadas, etc.) que nadie lo
podr entender. La solucin es introducir un nivel intermedio de mdulos
administradores, como hara un administrador de una organizacin huma
na si se ve en la necesidad de tratar de supervisar directamente a 25 su
bordinados inmediatos.6
Alcance del efecto/alcance del control. Esta regla sugiere que cualquier
mdulo afectado por el resultado de alguna decisin debe ser subordina
do (aunque no necesariamente un subordinado inmediato) del mdulo
que toma la decisin. Es un tanto anlogo a la regla de administracin
que dice que cualquier empleado afectado por los resultados de la deci
sin de algn administrador (es decir, dentro del alcance del efecto de la
decisin) debe estar dentro del alcance de control del administrador (es
decir trabajando entre la jerarqua de personas que se reportan con el ad
ministrador). Violar esta regia en un ambiente de diseo estructurado
usualmente lleva paso innecesario de banderas y condiciones (lo cual in
crementa el acopiamiento entre mdulos), la toma redundante de decisio
nes o (en el peor de los casos) conexiones patolgicas entre mdulos.
6 Existe una excepcin a esto conocida, com o centro de transacciones. Si el m dulo administrador
tom a una soia decisin para invocar a uno solo de sus subordinados, entonces su lgica probable
m ente es bastante sencilla. En este caso, no nos tenem os que preocupar acerca del alcance de
control.
www.FreeLibros.org
22i3
RESUMEN
Hay mucho ms que aprender acerca del diseo, pero con esta introduccin
jebe entenderse el proceso por el que pasa el diseador. Como hemos visto, el primer paso es hacer coincidir ei modelo esencial de los requerimientos del ususario
con una configuracin de procesadores. Luego, dentro de cada procesador, el dise
ador debe decidir cmo asignar procesos y datos a diferentes tareas. Finalmente,
eben organizarse los procesos dentro de cada tarea en una jerarqua de mdulos,
utilizando ei diagrama de estructura como herramienta.
Observe tambin que probablemente se tendrn que aadir procesos adiciona
les y reservas de datos a la implantacin del modelo para considerar las caractersti
cas especficas de la tecnologa de implantacin. Por ejemplo, pueden requerirse
procesos adicionales para revisin de errores, edicin y actividades de validacin
que no se mostraron en el modelo esencial; y para transportar flujos de datos entre
procesadores podran ser necesarios tambin otros procesos. Una vez logrado esto
puede comenzar la programacin. Los temas de programacin y prueba se discuten
en ei Captulo 23.
REFERENCIAS
1.
Meilir Page-Jones, The Practcal Guide to Structured Systems Design, 2# edi

cin, Englewood Cliffs, N.J.: Prentice-Hall, 1988.
2.
Edward Yourdon y Larry L. Constantine, Structured Design: Fundamentis of a

Discipline o f Computer Program and Systems Design. Englewood, N.J.: Prenti
ce-Hall, 1989.
3.
Paul Ward y Steve Mellor, Structured Development for Real-Time Systems, vo

lumen 3. Nueva York: YOURDON Press, 1986.
4.
Michael Jackson, Principies of Program Design. Nueva York: Academic Press,

1975.
5.
Ken Orr, Structured Systems Development. Nueva York: YOURDON Press,

1977.
1.
Qu actividad sigue al desarrollo del modelo de implantacin dei usuario en

un proyecto tpico del desarrollo de sistemas?
2.
Cules son las tres principales etapas del diseo en un proyecto tpico de de
sarrollo de sistemas? Qu modelos se desarrollan durante estas tres eta
pas?
www.FreeLibros.org
3.
Por qu son importantes los modelos durante la fase de diseo de un pro

yecto?
468
PASANDO AL DISEO
4.
Cal es el principal propsito del modelo del procesador durante la actividad

de diseo?
5.
D tres ejemplos de cmo pueden hacerse coincidir los procesos de un modalo esencial con los procesadores en un modelo de implantacin.
6.
Qu decisiones deben tomarse, durante la actividad de modelado del proce.

sador, sobre de ios almacenes de datos que se identificaron en el modelo
esencial?
7.
Enumere tres mtodos comunes para la comunicacin entre procesadores.
8.
Qu factores debe tomar en cuenta el diseador cuando escoge alguno de

estos tres mtodos? Cul de estos factores cree que sea el ms importante?
9.
Si est trabajando en un proyecto de desarrollo de sistemas donde la confiaba

lidad es prioritaria, cmo afectara esto su decisin acerca de la asignacin
de procesos y almacenes esenciales a diferentes procesadores ?
10.
D un ejemplo de cmo pueden las restricciones polticas influir en la asigna

cin de tareas y almacenes esenciales a diferentes procesadores.
11.
Qu es un modeio de tareas en el contexto de este captulo?

sus componentes?
12.
D tres sinnimos comunes de tarea.
13.
Bajo qu circunstancias pudieran estar operando diferentes tareas al mismo

tiempo?
14.
Proyecto de investigacin: Escoja una computadora y un sistema operativo

comunes. Describa cmo pueden comunicarse entre s las diferentes tareas
que operan bajo ei control del sistema operativo Cul es el sobrecosto tpico
(en trminos de tiempo de CPU, utilizacin de memoria y otros recursos impor
tantes de hardware) de dicha comunicacin entre tareas?
15.
D una definicin de modelo de implantacin de programa. Cules son sus

componentes?
16.
Cmo debe transformar el diseador un modelo esencial de DFD orientado a

redes no sincronizado, en un modelo jerrquico sincronizado?
17.
Bajo qu condiciones se convierte cada burbuja del modelo esencial en un

mdulo del modelo de implantacin de programa?
18.
Enumere dos estrategias comunes de diseo.

cada una.
Cules son
D una breve descripcin de
www.FreeLibros.org
Cul es el objetivo primario que trata de alcanzar el diseador cuando tradu

ce el modelo esencial a un modelo de implantacin?
Qu otros objetivos trata de alcanzar el diseador cuando crea un modelo de
implantacin?
www.FreeLibros.org
Es im posible diso cia r el lenguaje de la ciencia, o la ciencia del len

guaje, porque toda ciencia natural involucra siem pre tres cosas: la
secuencia de ios fe nm enos sobre los cuales se basa ia ciencia; los
conceptos ab stra cto s que traen dichos fenm enos a la m ente, y as
palabras con las cuales se expresan los conceptos. Para llam ar a
un concepto se necesita una palabra; para de scrib ir un fenm eno,
se necesita un concepto. Las tres cosas reflejan una sola realidad.
Antoine Laurent Lavoisier
Traite Eem entaire de Chim ie, 1789
Lo que tenem os que hacer es siem pre estar probando con cu riosi
dad nuevas o p iniones y corte ja n d o nuevas im presiones.
W alter Pater, E l Renacim iento, 1873

1. El papel del analista de sistemas en la programa
cin y la prueba.
2. Por qu es ventajoso el seguimiento rpido durante
la programacin y prueba.
3. Lo que el analista debe buscar al examinar un
programa.
4. Los principales tipos de prueba que se deben
realizar.
www.FreeLibros.org
470
PROGRAMACION Y PRUEBA 471
II
L a programacin y la prueba normalmente comienzan, como pudiera esperartermina ia actividad de diseo. La fase de programacin o implantacin
jjeun proyecto tpico involucra la escritura de instrucciones en COBOL, Pascal o al
gn otro lenguaje de programacin para implantar lo que el analista ha especificado
"jel diseador ha organizado en mdulos. La prueba, como el nombre implica, invo
lucra ejercitar el sistema para asegurar que produzca las salidas apropiadas y exhi
ba el comportamiento adecuado para una gama amplia de entradas.
sg cu a n d o
Por qu debiera interesarle esto como analista? Acaso no es verdad que

n0 estar Involucrado con el proyecto a estas alturas? No necesariamente. Por va
rias razones, la labor de los programadores y probadores puede influir en su trabajo;
y la forma en que usted organice su trabajo puede influir en el de ellos. La interreiacin entre el anlisis de sistemas y la programacin/prueba es el tema de este cap
tulo.
23.1
EL PAPEL DEL ANALISTA EN LA PROGRAMACION Y LA PRUEBA
En el caso extremo, el analista terminar su labor de especificacin del siste

ma y luego pasar algn tiempo con el equipo de diseo mientras se desarrolla el
modelo de implantacin del usuario y se llevan a cabo las primeras etapas del dise
o. Pero para cuando inicia la primera etapa de programacin, el analista puede ha
ber comenzado con otro proyecto. Hay algunas razones por las cuales usted, como
analista, puede requerir seguir involucrado en el proyecto al comenzar la actividad
de programacin:
Una razn sencilla. Usted es el lder del proyecto y est a cargo de los
programadores. Obviamente, no los puede abandonar. Estar involucra
do con el proyecto hasta la prueba final, la aceptacin y la entrega al
usuario final. Por ello, ser importante que sepa si ios programadores es
cribieron cdigo de alta calidad, y ser igualmente importante que sepa si
probaron de manera adecuada sus programas.
Otra razn sencilla. Usted es un analista jnior y su ttulo es de progra

mador/analista o analista/programador. Por ello, adems de desarrollar
las especificaciones del sistema, estar involucrado en la escritura de
programas.
Una razn ms interesante. Usted forma parte de un grupo que escribe

casos de prueba que se usarn para ejercitar los programas que los pro
gramadores escriben. En muchos proyectos, tal vez uno o ms usuarios
se le unan en esta actividad, partiendo de la teora de que los usuarios
son los ms aptos para pensar en casos excepcionales y poco usuales de
prueba. El desarrollo de datos de prueba puede empezar tan pronto como
se termina la especificacin (de hecho, incluso antes de haberla termina
do por completo); como lo dice Tom DeMarco, La especificacin es la
prueba del sistema . Dado que por lo pronto slo conoce el contenido l-
I)
www.FreeLibros.org
472
PROGRAMACION Y PRUEBA
gico de las entradas y salidas, probablemente tendr que esperar hasta

que el modelo de implantacin del usuario quede terminado antes de p0.
der determinar el formato fsico de dichas entradas y salidas. Tambin
ce sita r el m odelo de im plantacin del usuario para conocer |gs
restricciones operacionales (tiempo de respuesta, volmenes, etc.) qUg
se necesitan probar. Pero esta actividad fcilmente lo puede tener ocupado hasta el final del proyecto porque si los programas fallan con sus
casos de prueba, necesitar trabajar con los programadores para determi
nar si el caso de prueba est mal, o si es el cdigo de ellos.
23,2
Una razn menos obvia. Puede verse involucrado en el desarrollo de ma

nuales de usuario, preparacin de los usuarios o en la planeacin de |a
instalacin del nuevo sistema y conversin de datos desde el otro siste
ma. En la mayor parte de ios casos, esto puede llevarse a cabo de mane
ra paralela con la programacin y prueba del nuevo sistema. S iendo
usted el analista que estar involucrado con el proyecto desde el princi
pio, a menudo se le considerar el candidato ideal para este trabajo.
Una razn descorazonadora. Tal vez los programadores no comprendan

su especificacin. O su especificacin puede estar incompleta, ser incon
sistente, o ser contradictoria. Pero estas cosas suelen suceder, y puede
encontrarse con el hecho de que los programadores necesitan consultarlo
peridicamente para revisar y aclararar la especificacin cuando la tradu
cen a un lenguaje de programacin. Otra variante sera que le pidieran
cambiar la especificacin por ser demasiado difcil de implantar. En este
caso, desde luego, tendr que ser el mediador (adems de intrprete) en
tre los programadores y los dems analistas de sistemas.
Otras razones descorazonadoras. Puede ser que los usuarios hayan co

menzado a cambiar de opinin con respecto a los requerimientos, incluso
cuando los programadores estn im plantando los que decan querer.
Aparte del hecho de que algunos usuarios gustan de hacer esto por diver
sin, existen algunas buenas razones para ello; los usuarios viven en un
mundo dinmico y a menudo deben reaccionar a una poltica cambiante
que les impone la legislacin gubernamental, los requerimientos de sus
clientes o las condiciones generales del mercado. Por tanto, puede en
contrarse con que est cambiando la especificacin incluso cuando los
programadores ya estn implantando la especificacin, lo cual no har fe
liz a nadie, pero tiene que hacerse de todos modos. Esto se discute ms
a fondo en la seccin 23.4.
EL IMPACTO DEL ANALISIS, LA PROGRAMACION Y LA PRUEBA
SOBRE LA ESTRUCTURA ORGANIZACIONAL
www.FreeLibros.org
A lo largo de este libro ha sido evidente que el anlisis estructurado involucra
una progresin continua desde los aspectos de modelado de alto nivel (por ejemplo,
diagramas de flujo de datos de nivel superior) a aspectos de modelado de bajo nivel

como el desarrollo de especificaciones de proceso y el diccionario de datos completo
y detallado. De manera similar, el proceso de diseo involucra el desarrollo de mo
delos de diseo que van desde diagramas de estructura de alto nivel hasta formas
de nivel tan bajo como el pseudocdigo y los diagramas de flujo. La programacin
debe seguir este mismo patrn: se escriben programas para los mdulos ejecutivos
de alto nivel, y tarde o temprano se desarrollarn para los mdulos de bajo nivel que
llevan a cabo clculos detallados, validan datos de entrada, etc.
Lo que an no hemos discutido es la relacin que existe entre los niveles del
sistema y los niveles de la organizacin que construye el sistema. Pero probable
mente le habr dado la impresin, tras leer la mayor parte de este libro, que los que
ostentan el ttulo de analistas de sistemas son los que tienen la responsabilidad de
todo el trabajo de anlisis de sistemas; que quienes tienen el ttulo de diseadores
son responsables de la labor de diseo, y los que tienen el de programador sern
responsables de escribir los programas.
Pero existe un problema con este enfoque; de hecho, dos problemas relacio
nados. Primero, quienes tienen el ttulo de analistas usuaimente son personas rela
tivamente maduros, con varios aos de experiencia. A pesar de que generalmente
disfrutan la labor de dibujar diagramas de flujo de datos y diagramas de entidad-rela
cin, les resulta difcil emocionarse ante ia perspectiva de tener que escribir cientos
de especificaciones de proceso y definir miles de datos.
Y tambin est el otro lado del problema: si los analistas en jefe realizan esta
labor detallada, qu hacen los programadores? Su labor se vuelve casi mecnica,
y consiste bsicamente en traducir las especificaciones a COBOL o FORTRAN.
Cualquier creatividad que hayan pensado que su trabajo poda tener desaparece.1
Una solucin para este dilema aparente es permitir a esta gente madura hacer
todes las actividades de nivel superior del proyecto, y a los novatos jvenes todas
las actividades detalladas de nivel inferior. Esto significa, por ejemplo, que el perso
nal con experiencia (ios que tienen el ttulo de analista en jefe o algo igualmente im
presionante) no slo hara las actividades de alto nivel del anlisis (como el dibujo
de los diagramas de flujo de datos y otros) sino tambin las actividades de diseo de
alto nivel, e incluso llegar a escribir cdigo de alto nivel. Los novatos, mientras tan
1 En realidad, las cosas pudieran ser an peores o un poco m ejores. La peor situacin (desde el
punto de vista dei program ador) se ra que los program adores no se necesitaran en absoluto. SI la
especificacin del proceso se e scribe en un lenguaje lo su ficie n tem e n te form al, se puede com pilar
sin necesidad de intervencin hum ana. Esto ya est su ce d ie nd o en casos a isla d o s (por ejem plo,
especificaciones del proceso e scrita s en lenguaje Ada y luego com piladas directa m e n te ). Por otro
lado, existe la p osibilidad de que el program ador to d ava tenga m ucho trab a jo crea tivo que hacer si
si analista escribe la e sp e cificacin usando el enfoque de preco n d ici n /p ostco n d ici n que se discu
te en el C ap tulo 11. En este caso, el a n alista habr e sp e cifica d o las e n tradas y salid a s para cada
mdulo, pero dej al d iseador y, finalm ente, al program ador, la labor de d e term in a r el m ejor algo
ritmo.
www.FreeLibros.org
474
t o , estaran involucrados en el proyecto desde el p r i n c i p i o (o tan pronto como loa je

fes hayan completado ios aspectos de alto nivel del anlisis) y participaran en e l tra
bajo de escribir las especificaciones de procesos y mdulos, e n desarrollar e n t r a d a s
para el d i c c i o n a r i o de datos y escribir el cdigo para los mdulos de nivel inferior.
La ventaja para los programadores e s que les toca hacer el trabajo creativo de
escribir l a s especificaciones de proceso y tienen el placer de traducir sus p r o p g s
especificaciones a cdigo. Esto los i n v o l u c r a e n el proceso de anlisis de s i s t e m a s
en una etapa ms temprana d e su carrera que !o que hubiera sido posible de o t r a
manera. Tambin tiene la ventaja de mantener a la gente madura en contacto c o n l a
tecnologa, a l forzarlos a continuar realizando alguna labor de diseo y progra
macin.
No todos los a n a l i s t a s de sistemas maduros creen que esto es una buena
dea, aunque admitan que no disfrutan el t e n e r que escribir t o d a s las especificacio
nes detalladas de procesos como parte de su trabajo. De cualquier forma, cobra
fuerza l a idea de que si la labor de programacin es precedida p o r un anlisis deta
llado de sistem as dei tipo que se describe en este libro, se convertir en un trabajo
mecnico y de baja categora, que puede desaparecer por completo si se d e s a r r o l l a n
generadores inteligentes de cdigo que c o m p i l e n d i r e c t a m e n t e las especificaciones
d e proceso. Por tanto, se p u e d e esperar que las organizaciones cambien gradual
mente sus asignaciones de trabajo a lo largo de los siguientes cinco o diez aos e n
conformidad c o n las deas anteriores.
23.3
IMPLANTACION DESCENDENTE Y SEGUIMIENTO RAPIDO
P u e d e haber t e n i d o otra impresin al leer el material de este libro: que las a c t i

v i d a d e s de anlisis deben r e a l i z a r s e y com pletarse antes de que puedan c o m e n z a r
fas actividades de diseo y programacin. Aunque m u c h o s proyectos de hecho tra
bajan de esta manera, no es estrictamente necesario. El anlisis, diseo y progra
macin se pueden realizar de manera paralela.
E l concepto de desarrollo paralelo de la especificacin, el diseo y el c d i g o

de un s i s t e m a a veces se conoce como seguimiento rpido y en algunos l i b r o s se
conoce como implantacin descendente (vase por ejemplo,[Yourdon, 1988]). E s t o
no sucede nicamente en el campo de las computadoras. Se discuti ia idea breve
mente en el Captulo 5; revise el concepto de implantacin descendente como p a r t e
del ciclo de vida del desarrollo global del s i s t e m a que se discuti en ese captulo.
La industria de la construccin y muchas disciplinas ingenenles siguen e s t e
en muchos proyectos. Como muchos administradores de estos p r o y e c t o s
dicen: no hace falta conocer el nmero de chapas de las p u e r t a s de u n a construc
cin antes de construir los cimientos. En el caso del desarrollo de un sistema de in
formacin esto significa que los productos de alto nivel del anlisis de sistemas, es
decir, los documentos que constituyen el marco de referencia, tales como diagramas
de flujo d e datos, diagramas de entidad-relacin y d i a g r a m a s de transicin d e esta-
e n fo q u e
www.FreeLibros.org
jj0S pueden usarse como base para el diseo de alto nivel. Y ste puede usarse co^0 fundamento para escribir cdigo de alto nivel aun antes de haber terminado los
0 a lle s del anlisis de sistemas.
Existe una gran flexibilidad en este enfoque; se puede terminar el 80 por cienjo de la labor de anlisis antes de comenzar con el diseo y la programacin, o se
puede terminar slo el 10 por ciento. El plan de proyecto que requiere casi complejar el anlisis antes de comenzar el diseo usualmente se conoce como de enfoque
conservador; un pian de proyecto que requiera un traslape casi inmediato del anli
sis, el diseo y la programacin se conoce como de enfoque radical. Cada adminis
trador decide qu tan radical o conservador quiere que su proyecto sea, y puede
cambiar de opinin dinmicamente durante el proyecto.
Por qu considerara un administrador del proyecto seguir el enfoque radical?
Por qu podra alguien comenzar la labor de diseo y programacin antes de con
cluir la de anlisis? Existen muchas razones, de las cuales las ms importantes son
las siguientes :
Como la labor de anlisis, diseo y programacin se realiza de manera

concurrente, usualmente se tiene la oportunidad de acortar dramtica
mente el tiempo total necesario para un proyecto. En muchos entornos,
esto puede ser de crucial importancia, por ejemplo, en el caso de que un
sistema determinado deba concluirse de manera definitiva para cierta fe
cha.
La labor de desarrollo concurrente puede usarse como una forma de ha

cer el prototipo: permite al equipo del proyecto mostrar al usuario una ver
sin esqueltica dei sistem a antes de concluir la labor detallada de
anlisis. Esto puede evitar malos entendidos entre el usuario y el analis
ta, que pueden suceder incluso con una especificacin de estructura cui
dadosamente desarrollada.
El comenzar la labor de programacin pronto, suele evitar diversos pro

blemas referentes a la demanda de recursos, tales como tiempo de cm
puto, que de otra manera se convertiran en un obstculo. Por ejemplo, a
menudo el enfoque conservador requiere cantidades enormes de tiempo
de mquina durante las etapas finales de prueba y esto puede ser un
gran problema.
El que el proyecto decida seguir un enfoque conservador o uno radical va ms

all del alcance de este libro; algunos ambientes de proyecto pueden favorecer un
enfoque conservador y otros exigir un enfoque altamente radical. Lo principal de lo
que hay que estar conscientes es que el enfoque de anlisis estructurado descrito
en este libro no excluye ninguno de los dos enfoques, ni tampoco insiste en alguno
de eilos.
www.FreeLibros.org
476
23.4
PROGRAMACION Y LENGUAJES DE PROGRAMACION
Si an est involucrado en el proyecto durante la etapa de implantacin, debe

tener cuando menos una comprensin general de las tcnicas de programacin.
esta seccin discutiremos:
Cuatro generaciones de lenguajes de programacin
Asuntos importantes en la programacin
Cosas que debe buscar si examina la codificacin de los programadores
23.4.1
Las cuatro generaciones de lenguajes de program acin
Se ha estado escribiendo programas de computacin desde que se desarrollaron las computadoras de propsito general, hace 40 aos. Los programas se escri
ben con lenguajes de programacin de los cuales como ejemplos comunes tenernos
BASIC, COBOL y FORTRAN. Es conveniente agrupar los distintos lenguajes de pro
gramacin (existen cientos de lenguajes distintos que se utilizan en todo el mundo)
en cuatro generaciones distintas:
Lenguajes de primera generacin: fueron los lenguajes de mquina que

se usaron en ios aos 50; los programadores que intentaban que la com
putadora hiciera algo til codificaban sus instrucciones con unos y ceros
binarios. Existen ocasiones hoy en da en las que un sistema de cmputo
defectuoso produce pginas y pginas de dgitos; todava existen algunos
jvenes mal informados que creen que el lenguaje de mquina es la me
jor manera de jugar con las computadoras personales, pero el resto del
mundo dej de pensar en el lenguaje de mquina hace unos 25 aos.
Lenguajes de segunda generacin: son los sucesores del lenguaje de m

quina; generalmente se conocen como lenguajes de ensamble o ensam
bladores. Los lenguajes de segunda generacin son de bajo nivel en el
sentido de que ei programador tiene que escribir una declaracin por ca
da instruccin de mquina. Por ello, aunque conceptualmente puede
pensar en trminos de la declaracin X = Y + Z, tendra que traducir las
siguientes declaraciones al lenguaje ensamblador:
LIMPIAR ACUMULADOR
CARGAR Y AL ACUMULADOR
AADIR Z A LOS CONTENIDOS DEL ACUMULADOR
ALMACENAR ACUMULADOR EN X
Incluso este pequeo ejemplo muestra la principal desventaja del lengua
je ensamblador. En lugar de pensar en trminos del problema que quiere
resolver, el programador debe pensar en trminos de la mquina. Alrede
dor de 1960 se comenz a introducir lenguajes ms poderosos; muchos
www.FreeLibros.org
programadores sanos hace mucho abandonaron el lenguaje ensamblador.

Desafortunadamente, an existen algunas situaciones en las que se ne
cesitan. Muchas Involucran computadoras muy pequeas y de bajo poder
(que pueden fabricarse muy econmicamente y son lo suficientemente
pequeas como para caber, digamos, en un reloj digital), que no tienen la
capacidad de tolerar el volumen de trabajo asociado con los lenguajes de
mayor nivel.
Lenguajes de tercera generacin: son la norma actual; inciuyen BASIC,
COBOL, FORTRAN, Pasca!, C, Ada y muchos ms. Son de alto nivel en
el sentido de que una sola declaracin (tal como MOVE A TO B en CO
BOL) usualmente representa cinco o diez declaraciones de lenguaje en
samblador (y a veces hasta cien); son de alto nivel en un sentido ms
importante, porque permiten al programador expresar pensamientos en
una forma un tanto ms compatible con el rea del problema en el que
est trabajando. Sin embargo, son de bajo nivel en algunos aspectos im
portantes. Requieren que el programador est ntimamente involucrado
en la tediosa labor de dar formato a ios reportes de la computadora, al
igual que en la edicin y validacin de las entradas del programa. A me
nudo el programador piensa: este reporte debe tener el encabezado es
tndar en la parte superior de cada pgina, con ei nmero de pgina a la
derecha y la fecha en la izquierda, como todos los dems , pero puede te
ner que escribir 20 o 30 declaraciones de COBOL para lograrlo.
Los lenguajes de tercera generacin tambin se caracterizan como len
guajes guiados por procedimientos. Requieren que el programador pien
se con cuidado la secuencia de los clculos o procedimientos necesarios
para lograr alguna accin. En una aplicacin cientfica, por ejemplo, el
programador puede saber que quiere aadir ei arreglo A at arreglo B; sin
embargo, puede verse forzado a escribir ios pasos detallados del procedi
miento para cada uno de los elementos de los dos arreglos, en lugar de
simplemente decir, sumar estos dos arreglos sin tener que preocuparse
por los pasos del procedimiento.
Lenguajes de cuarta generacin: los lenguajes de cuarta generacin, o
4GLs, son la moda actual y muchos consultores de computacin los consi
deran el desarrollo ms importante en el campo de software en los ltimos
20 aos. Algunos han existido durante casi una dcada, pero slo se hi
cieron populares en los ltimos aos. Como ejemplos hay FOCUS, IDE
AL, MARK IV, RAMIS, MANTIS, MAPPER, dBASE-V Plus y Rbase-5000.
La mayor parte tienen caractersticas de programacin estructurada au
sentes en ios lenguajes de tercera generacin, pero incluyen otras. En io
particular, la m ayora de los detalles tediosos de program acin re
lacionados con introducir datos a la computadora (por medio de una ter
m inal) se ocultan al program ador; con una sola orden sen cilla , el
www.FreeLibros.org
478
programador puede especificar que ia computadora debe aceptar un tip0

especificado de datos desde el teclado, validarlo, y volver a almacenarlo
en un elemento de datos designado. La misma labor puede requerir iq 0
20 declaraciones en un lenguaje de programacin de tercera generacin
o de 100 a 200 en uno de segunda.
De manera similar, muchos detalles tediosos de programacin asociados
con la produccin de reportes de salida (por ejemplo, reportes de inven'
tario, cheques, facturas o un resumen de los pedidos del da) se manejan
automticamente por medio de lenguajes de cuarta generacin. Si la co
locacin precisa de la informacin en un reporte no es muy importante
(como a menudo suele suceder), el programador no tiene siquiera qys
especificarlo; de lo contrario, (como es el caso de un cheque producido
por computadora, donde el monto debe imprimirse en un lugar especifi
co), los detalles se especifican fcilmente con unas cuantas instrucciones
de 4GL.
23.4.2
C uestiones im portantes en program acin
Sin tomar en cuenta ei lenguaje de programacin que se use, hay cuestiones

comunes que todos los programadores enfrentan. Como analista, debe estar familia
rizado con ellas; las ms comunes se mencionan a continuacin:
Productividad: probablemente, la cuestin ms importante de la progra

macin actual sea la productividad: escribir ms software, ms rpida
mente. La principal razn de esto es la enorme cantidad de sistemas y
aplicaciones que siguen en espera en las grandes organizaciones: una or
ganizacin grande tpica tiene un retraso de entre cuatro y siete aos en
los nuevos trabajos por efectuar.2 Por ello, se deben alentar los lengua
jes y tcnicas de programacin que promueven la productividad; excep
tuando casos raros, la prod uctivida d se considera ms importante
actualmente que ia eficiencia.
Eficiencia: en algunas aplicaciones, la eficiencia sigue siendo de impor

tancia. Esto sucede en muchos sistemas de tiempo real, y puede darse
en otros tipos de sistemas que procesan grandes volmenes de datos
(por ejemplo, muchos de los sistemas que operan en las oficinas dei Se
guro Social, ai igual que otros sistemas enormes en bancos, reservacin
en aerolneas, compaas de bolsa y compaas de seguros). Para estas
aplicaciones, usualmente resulta importante m inim izar la cantidad de
tiempo de CPU requerido por ei programa; tambin puede ser importante
minimizar la utilizacin de memoria, ai igual que la de otros recursos co
www.FreeLibros.org
2 Esto no sig n ifica de cu a tro a siete aos de trabajo para una soia persona, sino ms bien de cuatro
a siete aos de trab a jo para toda la organizacin de d e sarrollo de sistem as de inform acin. Par
ms d e talle s vase [Yourdon, 1986].
mo el disco. Observe que la meta de eficiencia usualmente entra en con

flicto con otras metas discutidas en esta seccin: si se emplea mucho
tiempo en el desarrollo de un programa eficiente, es probable que sea
menos mantenible y menos transportable, y que tenga ms errores resi
duales sutiles, adems de que tal vez reduzca la productividad de a per
sona que escribi el programa.
Correccin: se podra argumentar que esto es lo ms importante. Des

pus de todo, si ei programa no funciona correctamente, no Importa qu
tan eficiente sea. Se prefieren lenguajes de programacin como Ada y
Pascal si la correccin es de importancia crtica (como, por ejemplo, si se
estuviera construyendo el sistema de la Guerra de las Galaxias, o el sis
tema de control para un reactor nuclear), porque son de tipos rgidos : se
requiere que el programador declare la naturaleza de sus variables (es
decir, si son enteros, de caracteres, de punto flotante, etc.) y el lenguaje
revisa todo cuidadosamente para evitar referencias ilegales a ios datos.
Portabilidad: en algunos ambientes esto es importante; el usuario puede

desear ejecutar el mismo sistema en varios tipos distintos de computado
ras. Algunos lenguajes de programacin son ms porttiles que otros;
irnicamente, esto es ms cierto en lenguajes de tercera generacin (C,
Pascal, FORTRAN, COBOL, etc.) que en los de cuarta. Sin embargo, no
existe un lenguaje universalmente porttil; siempre hay forma de que el
programador aproveche las caractersticas especiales de una computado
ra o un sistema operativo especficos. Por ello, adems del lenguaje de
programacin debemos preocuparnos por el estilo de programacin, si la
portabilidad es un factor importante.
Mantenibilidad: finalmente, debemos recordar que los sistemas viven du

rante mucho tiempo, por lo que el software debe mantenerse. El manteni
miento se discute con ms detalle en el Captulo 24.
23.4.3
Cosas de las que hay que tener cuidado
Como analista, puede tener la oportunidad de observar el trabajo que realizan

los programadores del proyecto; de hecho, puede que sea su supervisor. Como se
indic anteriormente, debe estar al tanto de que la productividad, la eficiencia, lo co
rrecto, la portabilidad y la mantenibilidad sean cuestiones de importancia. Pero c
mo se logran estas metas? Puede consultar otros textos, como [Yourdon, 1976] y
[Kernighan y Plauger, 1975], para ver discusiones detalladas acerca de tcnicas de
programacin; sin embargo, las siguientes son cuestiones clave en la programacin:
La programacin estructurada: Suponiendo que los programas se escri

ban en un lenguaje de tercera o cuarta generacin, debe seguirse un en
foque de programacin estructurada, en el que la lgica del programa (las
decisiones y ciclos) se organiza en combinaciones anidadas de construc-
www.FreeLibros.org
480
dones SI-ENTONCES-OTRO y HACER-MI ENTRAS. Casi todos ios tex

tos modernos de programacin ensean un enfoque estructurado; ySa
por ejemplo, [Wells, 1986], [Benton y Weekes, 1985], [Yourdon, Gane y
Sarson, 1976], y [Yourdon y Lister, 1977].
Mdulos pequeos: Es esencial que los programas se organicen en pe,

queos mdulos para que la lgica de programacin quepa en una sola
pgina de listado de programa. Es importante recordar que la complejidad
de un programa no aumenta linealmente con su tamao: un programa de
100 pasos casi siempre tendr ms del doble de complejidad que uno de
50. Como se vio en el Captulo 22, esto est principalmente bajo el con
trol del diseador; pero puede no tener posibilidad de determinar qu tan
grande ser un mdulo, sobre todo si no est familiarizado con el lengua
je de programacin que se usar en el proyecto. Por ello, el programador
puede tener que continuar la actividad de diseo, partiendo un mdulo en
submdulos de menor nivel, para que cada uno represente no ms da so
pasos de programacin.
Sencillez de estilo: Muchos textos de programacin, tales como [Yourdon,

1976] y [Kernighan y Plauger, 1975], tienen reglas detalladas para la es
critura de programas sencillos, es decir, programas que el programador
promedio puede entender y que se le pueden pasar ai programado- ds
mantenimiento; entre estas reglas se tiene la sugerencia de que el pro
gramador intente evitar declaraciones de programacin con expresiones
booleanas compuestas, como
SI A Y B O NO C Y D ENTONCES AADIR 3 A X
Es interesante notar que en los ltimos diez aos se han desarrollado diversos
modelos matemticos sobre la complejidad de los programas; uno de los ms popu
lares es el modelo de complejidad ciclomtica de McCabe [McCabe, 1976], que pro
porciona una medida cuantitativa de la complejidad intrnseca de un programa,3
Algunas organizaciones actualmente insisten en que todos los programas nuevos
deben pasar por un verificador de complejidad automatizado para asegurar que no
sean demasiado complejos.
23.5
PRUEBAS
Es probable que el proceso de probar ei sistema tome tanto como la mitad del
tiempo programado para su desarrollo, dependiendo de qu tan cuidadosamente se
hayan hecho las actividades iniciales de anlisis, diseo y programacin, incluso si
se hizo una labor perfecta de anlisis, diseo y programacin, se debe hacer algn
www.FreeLibros.org
3 Para ios lenguajes de te rce ra generacin com o CO BO L, la com plejidad ciclo m tica es aproxima
dam ente igual al nm ero de in stru ccio n e s SI del program a. Para ms inform acin vase [DeMarco,
1982],
gsfuerzo para verificar que no haya errores. Si, por otro lado, se hizo un trabajo im
perfecto (que suele ser el caso casi siempre), entonces la prueba se vuelve iterativa:
la primera tanda de pruebas muestra la presencia de errores, y las posteriores verifican si los programas corregidos funcionan correctamente.
Qu necesita saber acerca de las pruebas como analista del sistema? Esto
depender desde luego, de qu tan involucrado est en el proceso. En muchos ca
sos, el analista trabaja de manera cercana con ei usuario para desarrollar un conjun(0 eficaz y de gran alcance de casos de prueba basados en el modelo esencial y el
nodelo de implantacin del usuario. Este proceso de desarrollar casos de prueba
de aceptacin puede llevarse a cabo en paralelo con las actividades de implantacin
del diseo y de la programacin, para que, cuando ios programadores terminen de
escribir sus programas y de realizar sus propias pruebas locales, el equipo del ana
lista/usuario est listo con sus propios casos de prueba.
Adems de este concepto bsico (que la descripcin de los requerimientos del
usuario forme la base de los casos de prueba finales), debe estar familiarizado con
los diferentes tipos de prueba, ai igual que con algunos conceptos relacionados de
cerca con las pruebas, que se discuten a continuacin:
23.5.1
Tipos de prueba
A estas alturas tal vez piense que no existe ms que un tipo de prueba: qu
ms podra haber que el hecho de simplemente idear casos de prueba y luego revi
sar si el sistema trabaja correctamente?
Lo primero que hay que entender es que hay distintas estrategias de prueba;
las dos ms comunes se conocen como prueba ascendente y descendente. El enfo
que ascendente empieza por probar mdulos individuales pequeos separadamente;
esto a menudo se conoce como prueba de unidades, prueba de mdulos, o prueba
de programas. Luego, los mdulos Individuales se combinan para formar unidades
cada vez ms grandes que se probarn en masa; esto se conoce como prueba de
subsistemas. Finalmente, todos los componentes del sistema se combinan para pro
barse; esto se conoce como prueba dei sistema, y suele estar seguido de las prue
bas de aceptacin, donde se permite al usuario usar sus propios casos de prueba
para verificar que ei sistema est trabajando de manera correcta.
El enfoque de prueba descendente empieza con un esqueleto del sistema; es
decir, la estrategia de prueba supone que se han desarrollado los mdulos ejecutivos
de alto nivel de! sistema, pero que los de bajo nivel existen slo como mdulos va
cos.4 Dado que muchas de las funciones detalladas del sistema no se han implanta
do, las pruebas iniciales estn muy limitadas; el propsito es simplemente comenzar
www.FreeLibros.org
4 Un ejem plo de m dulo va co es uno que no p ro ce sa nada, sino que sim p le m e n te term ina luego
de ser llam ado. O tro ejem plo es un m dulo que d e vuelve los m ism os p a rm etros de salida inde
pendientemente de los p a rm etros de entrada que se ie pasaron cuando se llam . De esta form a,
482
a ejercitar las interfases entre ios subsistemas principales. Las pruebas siguientes
abarcan y tratan aspectos cada vez ms detallados del sistema. El enfoque descen
dente de prueba generalmente se considera preferible para muchos sistemas en la
actualidad; para ms detalles al respecto, vase [Yourdon, 1986].
Adems de estos conceptos bsicos, debera estar familiarizado con los si
guientes tipos de prueba:
Prueba funcional: Esta es la forma ms comn de prueba; su propsito

asegurar que el sistema realiza sus funciones normales de manera co
rrecta. As. los casos de prueba se desarrollan y se alimentan al sistma
las salidas (y los resultados de los archivos actualizados) se examinan
para ver si son correctos.
Prueba de recuperacin: Ei propsito de este tipo de prueba es asegurar

que el sistema pueda recuperarse adecuadamente de diversos tipos de
fallas. Esto es de particular importancia en ios sistemas en lnea gran
des, ai igual que en varios tipos de sistemas de tiempo real que controlan
dispositivos fsicos y/o procesos de fabricacin. Las pruebas de recupera
cin pueden requerir que el equipo que realiza el proyecto simule (o pro
voque) fa lla s de hardware, fallas de corriente, fa lla s en el sistema
operativo, etc.
Prueba de desempeo: El propsito de este tipo de prueba es asegurar

que el sistema pueda manejar el volumen de datos y transacciones de en
trada especificados en el modelo de implantacin del usuario, adems de
asegurar que tenga el tiempo de respuesta requerido. Esto puede reque
rir que el equipo que realiza el proyecto simule una gran red de termina
les en lnea, de manera que se pueda engaar al sistema para que crea
que est operando con una gran carga.
Existe un ltimo concepto del que debe estar al tanto: la nocin de prueba ex
haustiva. En el proyecto ideal, se generaran casos de prueba para cubrir cada en
trada posible y cada combinacin posible de situaciones que el sistema pudiera
enfrentar alguna vez; luego, se probara de manera exhaustiva para asegurar que su
comportamiento sea perfecto. Slo existe un problema con esto: no funciona. Ei n
mero de casos de prueba para un sistema grande y complejo tpico es tan increble
mente grande, a menudo del orden de 10' 100 casos de prueba distintos o ms, que
an si se pudiera realizar una prueba cada milsima de segundo tomara ms de la
edad del universo terminar todas las pruebas. Consecuentemente, nadie realiza
la prueba descendente inicial de un sistem a de nm ina puede co n sistir en m dulos vacos que le
pagan a todo m undo $100 a la sem ana, sin to m a r en cu e n ta su clasificacin salarial; el m dulo va
co de los clculos de im puestos tal vez siem pre deduzca $10 en im puestos a todos los cheques da
la nm ina. El objetivo de la prueba descendente inicial sim plem ente ser d e term in a r si el sistema
fu n cio na o no y si es en realidad capaz de g e nerar un co n ju n to fijo de cheques de $100.
www.FreeLibros.org
verdaderamente exhaustivas en algo que no sea un sistema trivial; cuando

^s, quienes desarrollan el sistema pueden aspirar a crear casos de prueba que
ejerciten (o cubran) un gran porcentaje de los diferentes caminos de decisin que
pueda tomar.5 Esto hace que sea an ms importante asegurar que el modelo de
los requerimientos del usuario y los diversos modelos de implantacin sean tan co
rrectos como se pueda.
p ru e b a s
Suponga que, por ejemplo, se quisiera desarrollar casos de prueba para una
de un sistema que calcula el salario neto de un empleado, como muestra la
figura 23.1. Suponga que el salario bruto se define en el diccionario de datos como
un entero (es decir, un salario expresado en cantidades enteras) que va desde 0 a
10,000. Entonces parecera que una prueba realmente exhaustiva consistira en e s
pecificar el salario neto correcto para cada u n a de las 10,000 cantidades posibles
de salario bruto. Es de suponerse que, si nuestro equipo de implantacin llevara a
cabo dichos 10,000 casos de prueba y verificara que de hecho s se produce el sala
rio neto, entonces se podra confiar en que el proceso estuviera operando correcta
mente.
porcin
Salario bruto
Figura 23.1: Una pequea p orcin de un sistem a

Pero, espere. Qu pasa con los valores potencialmente incorrectos de sala
rio bruto? Qu tal si el usuario proporciona un sa la rio b ruto negativo? Qu tal
si proporciona uno de 100,000? Dado que potencialmente existe un nmero infinito
de valores potenciales de salario b ru to ,6 y dado que no tenemos conocimiento del
comportamiento interno del programa que realiza la funcin CALCULAR SALARIO
NETO, nos enfrentamos a un nmero aparentemente infinito de casos de prueba. Si
se desarrollan al final de la fase de anlisis del proyecto, utilizando el diccionario de
datos y la especificacin del proceso, entonces no existe manera de saber cmo fun5.[Dunn, 1984] y [M yers, 1979] proporcionan discu sio n e s d e talladas acerca del alcance de las prue
bas.
6 En realidad, el nm ero de casos de prueba no es infinito, debido a la precisin lim itada de los n
meros que se alm acenan en la m em oria de ia com putadora. Si se alm acena com o entero, una com
putadora tp ica alm acenar com o m xim o el nm ero 232 o 264. Si se alm acena en punto flotante,
tal vez se pueda representar nm eros de tam ao 10'100 o m ayores, pero usualm ente s lo hay 8 o
9 dgitos sig nificativos de p recisin. Por tanto, esto no representa el in fin ito pero, no obstante, es
un nmero m uy grande.
www.FreeLibros.org
484
clonar finalmente el programa cuando el programador escriba el cdigo; por ello

nos vemos forzados a llevar a cabo una prueba de caja negra.
Si se conoce la lgica y estructura internas del programa (es decir, despus d8
que el programador escribi el cdigo), entonces se pueden basar los casos q6
prueba en la lgica del programa existente y realizar lo que se conoce como prueba
de caja de vidrio . Generalmente se puede demostrar, por ejemplo, que si el pro.
grama identifica de manera correcta un valor de salario bruto menor que cero, en
tonces identificar correctamente todos los valores negativos de salario bruto. En
general, debe poderse demostrar que el programa tendr un comportamiento consis
tente para varios niveles de salario bruto, reduciendo as el nmero requerido de ca
sos de prueba a un nmero manejable. Aunque esto no constituye una prueba
exhaustiva, es de suponerse que podramos lograr un nivel razonablemente alto de
confianza si se han desarrollado casos de prueba para todos los caminos significati
vos que el sistema puede tomar.
Pero, un momento. CALCULAR SALARIO NETO es tan slo un proceso, es
decir, una burbuja de entre cientos o incluso miles, en un sistema grande. Si se ne
cesitan, digamos, 1000 casos de prueba para verificar que CALCULAR SALARIO
NETO opera correctamente (en trminos de correccin funcional), entonces perfec
tamente se pueden necesitar 1000 pruebas para cada uno de los otros 1000 proce
sos del sistema. El nmero total de casos de prueba distintos podra ascender a
1000 * 1000= 1,000,000. Esto es conservador (y no toma en cuenta ia dimensin de
complejidad adicional causada por pruebas de entrada y salida, pruebas de recupe
racin, etc.).
As que debe admitirse desde un principio la imposibilidad de realizar pruebas
exhaustivas. Pero es posible, como se hizo notar anteriormente, escoger con cuida
do casos de prueba, para pasar por tantos caminos lgicos del sistema como sea
posible. Aun as, debemos estar preparados para un volumen grande, por no decir
enorme, de pruebas. Para realizar esto de manera efectiva, ei equipo que desarrolla
el sistema necesita tres cosas: planes de prueba, descripciones de pruebas y proce
dimientos de prueba. Un pian de prueba es exactamente io que parece: un docu
mento organizado que describe las actividades de prueba. Un documento de
pianeacin de pruebas tpico contendr la siguiente informacin:
Propsito de la prueba: cul es el objetivo de ia prueba, y qu parte def

sistema se est probando.
Localizacin y horario de la prueba: dnde y cundo se har.
Descripciones de ia prueba: descripcin de las entradas que se proporcio

narn al sistema, y las salidas y resultados que se anticipan. Usualmente
se darn descripciones de las entradas de prueba en ei formato de diccio
nario de datos que se discuti en el Captulo 10.
www.FreeLibros.org
[
|
23.5.2
Procedimientos de prueba: descripcin de cmo se deben preparar y presentar ios datos de prueba al sistema; cmo capturar los resultados de
salida, cmo analizar los resultados de las pruebas, y cualesquiera otros
procedimientos operacionaies que se deban observar.
Conceptos relacionados
Aunque la mayor parte de las organizaciones llevan a cabo pruebas de la ma

nera que se discuti, anteriormente, existen algunos conceptos relacionados que se
pueden usar para aumentar el proceso estndar de prueba, que incluyen:
Recorridos y revisiones (walkthroughs)
Inspecciones
Pruebas de correccin
Los recorridos y revisiones, que se discuten en el Apndice D, son una forma

de supervisin hecha por un grupo revisor de productos tcnicos; se usan amplia
mente en proceso de datos para revisar diagramas de flujo de datos (y otros produc
tos del anlisis de sistemas), diagramas de estructura (y otros productos del diseo),
adems de programas. Aunque esto es distinto a hacer pruebas, su objetivo es el
ii-no: descubrir posibles errores en el sistema.
Las inspecciones son similares a los recorridos, pero tienen un plan ms for
mal de puntos a examinar en el programa (o en ia especificacin, o en el diseo, de
pendiendo del tipo de inspeccin) antes de que se pueda aprobar. Por analoga,
considere lo que sucede cada ao cuando inspecciona su automvil: el mecnico tie
ne una lista especfica de puntos, como frenos, luces, emisiones dei escape, etc.,
que debe examinar antes de poner la calcomana en el auto.
Finalmente, existe un nmero limitado de casos donde se desarrollan pruebas
formales de correccin de un programa; este proceso es un tanto anlogo al proceso
de desarrollar las demostraciones de geometra que se estudiaron en la escuela.
Desafortunadamente, es extremadamente difcil y tardado desarrollar pruebas rigu
rosas de la correccin de un programa de computadora, y rara vez se ha hecho para
algo ms grande que que unos cuantos cientos de instrucciones. Sin embargo, por
lo menos un proyecto del gobierno de los EUA desarroll pruebas de este tipo, auxi
liado por computadora, para un sistema de alrededor de 10,000 Instrucciones; aun
que cost cerca de $500,000 dlares estadounidenses y tom 6 meses de trabajo,
puede justificarse para ciertos sistemas de alto riesgo o mxima seguridad. Para
ms acerca de esto, vea el Captulo 6 de [Dunn, 1984] o los reportes en [Elspas et
al, 1972] y [Dunlop y Basili, 1982].
www.FreeLibros.org
486
23.6
MANTENIMIENTO DE LA ESPECIFICACION DURANTE LA

PROGRAMACION: PRELUDIO AL CAPITULO 24
Como se mencion anteriormente, e s posible que la especificacin estructura,

da cambie durante el proceso de programacin. Esto puede suceder como r e s u l t a d o
de la estrategia de seguimiento rpido q u e se describi antes, o porque las e s p e c i f j .
caciones originales e s t a b a n mal, o simplemente porque l o s usuarios cambian d e o p j .
nin sobre s u s requerimientos. En cualquier caso, es una realidad, y r e s a l t a u n
punto importante: la especificacin del proceso no se puede considerar congelada
despus de concluida la fase de anlisis. Debe considerarse como un documento v i
v o que requerir mantenimiento continuo incluso antes de que el sistema mismo ha
ya entrado a la fase de mantenimiento. El Captulo 24 trata con mayor detalle e s t e
asunto.
23.7
QUE OCURRE DESPUES DE LAS PRUEBAS?
Tal vez piense que su labor termin cuando termina de probar el sistema. De
safortunadamente, queda an algo qu hacer, aunque ya no en su papel de analista.
Sin embargo, alguien (a menudo un grupo grande de personas) debe llevar a cabo
las actividades finales en un proyecto de desarrollo de sistemas:
Conversin
Instalacin
Capacitacin
La conversin es la tarea de traducir los archivos, formas y bases de datos ac

tuales del usuario al formato que el nuevo sistema requiere. En algunos casos ra
ros, esto puede ser una actividad no relevante, porque ya no hay datos. Sin
embargo, si el usuario est reemplazando un sistema actual por uno nuevo, es pro
bable que esto sea una tarea difcil y delicada. Se necesita desarrollar un plan de
conversin, de preferencia en cuanto se complete el modelo de implantacin del
usuario, para cubrir los siguientes puntos:
Si el usuario ya tiene datos existentes asociados con un sistema existen

te, probablemente querr usarlos hasta el ltimo momento posible antes
de pasarse al sistema nuevo. Por ello, es difcil considerar los datos exis
tentes como estticos.
Pudiera haber un volumen tan grande de datos existentes que sea im

prctico considerar convertirlo todo a la vez. Los archivos y registros po
dran tener que convertirse en form a increm ental. Esto obviamente
requiere de una pianeacin y coordinacin cuidadosa.
www.FreeLibros.org
La conversin debe llevarse a cabo de una manera automatizada; esto

slo se puede hacer si los archivos y datos actuales existen en alguna
forma automatizada. De ser as, debiera ser relativamente fcil escribir un
programa (o usar un paquete comercial existente) para traducir os archi

vos actuales al formato requerido por el sistema nuevo. Sin embargo, a
veces resulta difcil convertir los datos en forma automatizada, sobre todo
si los archivos existentes se tienen en distintas computadoras, en distin
tos formatos, etc. De hecho, desarrollar el software de conversin puede
resultar ser por s mismo un proyecto importante de desarrollo de siste
mas.
nudo
Los datos existentes pueden contener errores; de hecho, si se crearon y

mantuvieron manualmente, puede estar casi seguro de que habr errores.
Por ello, parte del proceso de conversin es la deteccin y correccin de
errores, que puede volver an ms difcil y tardado el proceso. Algunos
archivos y registros existentes pueden resultar ilegibles o incomprensi
bles; en otros casos, puede ser obvio que los datos existentes estn mal,
pero podra no ser claro cules son los valores correctos.
Adems de convertir archivos existentes, puede ser necesario convertir

programas y procedimientos existentes. En algunos casos, los progra
mas y procedimientos existentes pueden usarse en su forma actual; en
otros, se tendrn que desechar y reemplazar por completo.
La instalacin del nuevo sistema puede ser un asunto instantneo, pero a

es una tarea enorme. Usuaimente, se debe hacer io siguiente:
m e
A la instalacin del nuevo sistema debe precederle la preparacin de la

sede de ia computadora, usualmente con varios meses de anticipacin.
Esto implica construir o rentar un local de cmputo con la corriente, espa
cio, iluminacin y control ambiental (temperatura, humedad, polvo, electri
cidad esttica, etc.) apropiados. Esto muchas veces se hace en conjunto
con el proveedor de hardware o el departamento de operaciones de cm
puto de ia organizacin.
Se puede requerir la preparacin de la sede de! usuario tambin, sobre

todo en el caso de sistemas en lnea que tienen terminales e impresoras
en el rea de trabajo del usuario. En el caso sencillo, se pueden distribuir
las terminales al rea de trabajo del usuario justo antes de instalar el sis
tema; sin embargo, en algunos casos, puede requerirse construir un lugar
de trabajo totalmente nuevo (considere, por ejemplo, una terminal de re
servaciones de una aerolnea en un aeropuerto).
La instalacin del hardware, cuando el sistema requiere de su propia

computadora, usuaimente la efecta el proveedor. En ocasiones se invo
lucran varios proveedores, sobre todo para sistemas en lnea y de tiempo
real. En el caso de un sistema sencillo desarrollado para una computado
ra personal, la instalacin puede ser tan sencilla como sacar la computa
dora de su caja y conectarla.
www.FreeLibros.org
488
La instalacin del software, que involucra cargar todos los programas qUe
se escribieron para el nuevo sistema en ia o las computadoras adecua
das, y prepararlos para su operacin.
Tenga en mente que lo recin descrito supone que existe una sola instalacin
en una sola sede. Pero a menudo no es as; para un sistema grande y distribuido
pudiera haber una sola sede de computadoras central, y docenas o incluso cientos
de sedes de usuarios. Por ello, puede ser necesario instalar el sistema por etapas
con la visita de equipos de instalacin especialmente capacitados a cada sede d
usuarios de acuerdo con un programa preestablecido. En este caso, la instalacin y
cambio al nuevo sistema no puede ser inmediata, sino que debe irse haciendo gradualmente durante un periodo de das, semanas o incluso meses.
La capacitacin es la tarea final del equipo de desarrollo del sistema: la capa
citacin de los usuarios (obviamente), adems de la preparacin del personal de
operaciones, los programadores de mantenimiento y varios niveles de administra
cin. Se debe desarrollar un plan de capacitacin pronto, pues hay mucho trabajo
que hacer, y debe estar listo ai mismo tiempo (si es que no antes) de que el sistema
comience a operar. El plan de capacitacin debe considerar los siguientes aspectos:
Cmo se llevar a cabo? Muchos proyectos de desarrollo de sistemas

dependen de manuales para ei usuario y guas de referencia para propor
cionar a los usuarios documentos escritos. Sin embargo, podran conve
nir clases y seminarios en vivo, adems de plticas de orientacin para
administradores y personas que necesitan estar al tanto del sistema aun
que no interacten con l a diario. Con la tecnologa actual existe una
gran gama de opciones de medios didcticos: videocassettes o videodis
cos, enseanza por computadora, e incluso versiones de simulacro del
sistem a real para que los usuarios puedan ingresar transacciones y
aprender a interactuar con l.
En el caso extremo, la capacitacin puede consistir en opciones de ayuda
altamente elaboradas integradas al sistema mismo. Esto se est volvien
do cada vez ms popular con la proliferacin de las computadoras perso
nales, pero no es muy prctico para sistemas grandes con una comunidad
grande y diversificada de usuarios; por otro lado, se puede usar para au
mentar y reforzar otras formas de capacitacin.
Quin llevar a cabo la capacitacin? En algunos casos, los miembros

del equipo de desarrollo de sistemas participan en el proceso, sobre todo
dado que se supone que son los mejores expertos sobre cmo funciona el
sistema. Sin embargo, tenga en mente que el mejor programador (o ana
lista) no siempre es el mejor maestro; de hecho, quienes desarrollan el
sistema suelen comportarse de una manera muy defensiva si los usuarios
empiezan a hacer preguntas que consideran hostiles. Adems, estn (ca
si por definicin) terriblemente ocupados con el diseo, codificacin y
www.FreeLibros.org
prueba del sistema hasta ei ltimo momento. Los analistas podran tener
ms tiempo despus de terminar el modelo esencial y el modelo de im
plantacin dei usuario.
23.8
A quin se preparar y en qu horario? Obviamente, se necesita capaci

tar a los usuarios antes de que usen el sistema; por otro lado, no resulta
efectivo prepararlos seis meses antes de que puedan ver ei nuevo siste
ma. Por ello, la capacitacin debe hacerse en un tiempo relativamente
corto; pero esto, a su vez, a menudo interferir con el trabajo cotidiano
normal que los usuarios tratan de hacer. Por tanto, se debe negociar con
ellos un programa cuidadoso de actividades de capacitacin.
RESUMEN
Este captulo cubri una amplia gama de tpicos: programacin, pruebas, con
v e r s i n , instalacin y capacitacin. E l espacio disponible no nos p e r m i t e mostrarlos

d e manera detallada, pero el tratamiento breve que se proporciona debe dar a l a n a
l i s t a una visin general de estas actividades finales en el proyecto de desarrollo de
siste m a s.
Se encuentran detalles adicionales en las referencias al final de este ca
ptulo.
referencias
1.
Edward Yourdon, Managing the Systems Ufe Cycle, 2a edicin, Engiewood

Ciiffs, N.J.: Prentice Hall, 1988.
2.
Edward Yourdon, Nations at fisk. Nueva York: YOURDON Press, 1986.
3.
Edward Yourdon, Techniques of Program Structure and Design, 2a edicin,

Engiewood Ciiffs, N.J: Prentice- Hall, 1976.
4.
Brian Kernighan y P.J. Plauger, The Elemens of Programming Stye. Reading,

Mass.: Addison-Wesiey, 1975.
5.
Timothy Wells, S tructured Systems Developm ent in COBOL. Nueva York:

6.
Tim othy W ells, S tructured Systems D evelopm ent in BASIC. Nueva York:
7.
Tim othy W ells, S tructured Systems D evelopm ent in Pascal. Nueva York;
8.
Stan Benton y Leonard Weekes, Program It Rght: Structured Programming in

BASIC. Nueva York: YOURDON Press, 1985.
www.FreeLibros.org
9.
Edward Yourdon, Chris Gane y Trish Sarson, Learning to Program in Structu

red COBOL, Parte I. Nueva York: YOURDON Press, 1976.
490
10.
Edward Yourdon y Timothy Lister, Learning to Program n Structured COBQi

Parte II. Nueva York: YOURDON Press, 1977.
11.
Tom DeMarco, Controliing Software Projects. Nueva York: YOURDON PreSs

1982.
12.
Glenford Myers, The A rt o f Software Testing. Nueva York: Wiley, 1979.
13.
Tom McCabe, A Complexity Measure, IEEE Transaciions on Software Eng.

neering, Vol. SE-2, nmero 12 (diciembre de 1976), pp. 308-320.
14.
Edward Yourdon, Managing the Structured Techniques, 3a edicin,

15.
Robert Dunn, Software Defect Removal. Nueva York: McGraw-Hill, 1984.
16.
B. Elspas y otros, An Assessment of Techniques of Proving program Correctness, ACM Computing Surveys, Vol. 4 (junio de 1972), pp. 97-147.
17.
D. Dunlop y V. Basiii, A Gomparative Analysis of Functional Correctness,

ACM Computing Surveys, Vol. 14 (junio de 1982), pp. 229-244.
Nueva
1.
Qu actividades incian en un proyecto de desarrollo de sistemas despus de

que termina el diseo?
2.
Cules son las seis razones por las que el analista puede necesitar seguir in
volucrado con un proyecto durante las actividades de programacin y prueba?
3.
Si el analista es el jefe del proyecto, cree que sea importante que est fami
liarizado con las tcnicas de programacin y las estrategias de prueba? Por
qu?
4.
En su organizacin, se espera que los analistas participen en las actividades

de diseo y programacin? Cree que sea buena idea? Por qu?
5.
Por qu es probable que el analista se vea involucrado en el desarrollo de

datos de prueba para el sistema? Quin ms es probable que se vea involu
crado?
6.
Qu debe hacer el analista si ios programadores piden que se cambie la es

pecificacin del sistema durante a fase de programacin dei proyecto?
7.
Qu debe hacer el analista si los usuarios piden cambiar los requerimientos

del sistema despus de que ios programadores comenzaron a implantarlo?
Qu tan probable cree que sea una situacin como sta?
www.FreeLibros.org
Por qu es posible que un usuario quiera cambiar ios requerimientos del sis
tema despus de concluida la fase de anlisis?
Qu dificultades pueden esperarse si un analista experimentado debe hacer

toda la labor de anlisis de un proyecto?
1Q.
Qu tipo de reaccin negativa puede esperarse de los programadores en una

organizacin si los analistas realizan todas las actividades detalladas de espe
cificacin que se discuten a lo largo de este libro?
11.
Qu tipo de estructura organizaciona! podra tenerse para acomodar la com

binacin de personal experimentado/ personal nuevo y de actividades tcnicas
de alto/bajo nivel en un proyecto?
12.
Pueden automatizarse los aspectos de programacin si las actividades de

anlisis y diseo de sistemas se han realizado competamente y en detalle?
Por qu? Cree que esta situacin cambie durante los siguientes 5 a 10
aos?
13.
Es necesario completar todas las actividades de anlisis de sistemas antes

de comenzar con la labor de programacin? Por qu s o por qu no?
14.
Qu significa seguimiento rpido?
15. En qu otras industrias aparte de la de desarrollo de sistemas se efecta el

seguimiento rpido?
16.
Qu es un enfoque conservador para implantar un sistema? Qu es un en

foque radical?
17.
Cules son las tres principales razones por las que un administrador de pro
yecto pudiera adoptar un enfoque radical en la implantacin de sistemas?
18.
Por qu no puede considerarse congelada la especificacin de proceso al fi

nal de la fase de anlisis dei proyecto?
www.FreeLibros.org
H asta ahora, el pro fe sio n a l cla ve de la com putadora era alguien que poda
ap render lo su ficie n te acerca de las n e cesidades de las organizaciones com o
para exp re sa rla s en lenguaje de com putadora. En el futuro, a m edida que
nuestra sociedad se vu elva irre vo ca b le m e n te com putarizada, el profesional
clave ser alguien que pueda a p re n d e r lo suficiente acerca de sistem as com putarizados com o para exp re sa rlo s en lenguaje hum ano. Sin ese alguien, ha
brem os perdido el co n tro l de n uestra sociedad. Ese alguien es el ingeniero
en reversa . Los q ue m antienen el softw are son los ingenieros en reversa de
nue stra sociedad.
N icholas Z vegintzov, editor
Software Maintenance News
E n
este captulo se aprender:
1. Por qu es importante tener al da las

especificaciones.
2. Qu tipo de cambios se necesitan hacer a una
especificacin.
P a r a muchos analistas, ei proyecto termina cuando se termina ia especifica

cin estructurada y ei usuario la acepta. En ese momento se entrega ia especi
ficacin al equipo de implantacin constituido por los diseadores y program adores
que construirn un sistema a partir de la especificacin.
www.FreeLibros.org
492
MANTENIMIENTO DE LA ESPECIFICACION 493
Desde luego, algunos analistas siguen colaborando con el proyecto a lo largo

^ |as fases de diseo e implantacin. A veces el analista sirve de administrador del
proyecto, guiando y dirigiendo los esfuerzos del equipo de implantacin. A veces si
gue colaborando con la realizacin de anlisis, es decir, sirviendo como intermedia
rio entre ei usuario y ei equipo de implantacin. Tambin puede participar en el
desarrollo de manuales para el usuario, datos de prueba de aceptacin, pianeacin
de la instalacin y varias actividades complementarias que se hacen de manera con
currente con el proceso de implantacin.
Sin embargo, casi todos los analistas dejan el proyecto en cuanto se completa
desarrollo y se pone en operacin el nuevo sistema. Algunos programadores se
quedan para actividades de mantenimiento, pero cuando se termina la fase de desa
rrollo se termina la fiesta, y la mayora de los analistas, diseadores y programadores se transfieren a otros proyectos nuevos (y a menudo a compaas nuevas,
donde pueden percibir un salario mayor al actual).
el
Pero el trabajo hecho por el analista (todo el trabajo que se discuti a lo largo
de este libro) sigue siendo importante. As como los programas deben mantenerse
durante los 5, 10 o 20 aos de vida operacional del sistema, de igual manera debe
mantenerse su especificacin. O, por decirlo de otra manera, cambiarn diversos
aspectos de la implantacin del sistema durante su vida, y para cada uno de estos
cambios debe haber uno correspondiente en la especificacin.
Aunque el analista original pudiera no permanecer con el proyecto durante la
vida operacional de ste, es importante que deje un legado que se pueda mantener.
Este captulo discute el mantenimiento de la especificacin del sistema.
24.1
PO R Q U E ES IM P O R T A N T E
Hasta aqu podra estar un tanto confundido; despus de todo, piensa, es per
fectamente obvio que la especificacin del sistema puede actualizarse. Por qu no
hacerlo? Desafortunadamente, la historia del campo de desarrollo de sistemas su
giere algo distinto: a gran mayora, probablemente ms del 80 por ciento, de los sis
temas que estn en operacin actualmente no tienen una declaracin precisa y
actualizada de los requerimientos de usuario que realizan.
Este no es un fenmeno exclusivo del campo de la computacin. Cuntas
casas de cien aos de antigedad tienen documentos actualizados que describen la
instalacin elctrica, la tubera, la calefaccin u otros detalles arquitectnicos? La
verdad es que a menudo resulta ms fcil hacerle una correccin, mejora o cambio
rpido y sucio a un sistema existente, que empezar a cambiar el documento de los
requerimientos y luego propagar dicho cambio a! documento de diseo y la implanta
cin misma. Esto sucede sobre todo si se necesita hacer el cambio para arreglar un
www.FreeLibros.org
494
MANTENIMIENTO DE LA ESPECIFICACION
problema inmediato, presionante y urgente.1 Ya cambiaremos los documentos

tarde, dice el encargado de mantenimiento, pero primero tenemos que arreglar
problema mismo. La documentacin es lo ltimo que se quiere hacer, y muchas veces no se hace.
Los sistemas de informacin tienen una caracterstica importante en cuanto al
mantenimiento: duran ms quienes los desarrollan originalmente. Esto tambin se da
para las casas; ni el arquitecto ni el usuario final de una casa victoriana construida
en 1880 estn disponibles para consultarles hoy en da algo. Tambin sucede para
muchos sistemas de Informacin; despus de 10 o 20 aos, el sistema est siendo
empleado por usuarios de tercera generacin (de los cuales muchos no tienen dea
del por qu se desarroll para empezar) y est siendo mantenido por programadores
de mantenimiento de tercera generacin (de los cuales algunos ni idea tienen de por
qu quienes originalmente lo desarrollaron adoptaron esa estrategia de diseo en
particular).2 Esta es la razn por la cul Nicholas Zvegintzov describe a los progra
madores de mantenimiento como ingenieros en reversa de la sociedad .
Hay otra cosa importante sobre los sistemas de informacin: tienden a ser
complejos desde el principio, y se vuelven cada vez ms complejos al pasar aos de
mantenimiento. Si el sistema fuera sencillo (por ejemplo, unas 250 instrucciones de
Pascal), entonces se mantendra fcilmente an si no tuviera documentacin. Pero
un sistema tpico tiene por lo menos 100,000 instrucciones; muchos de los ms
grandes que se mantienen en la actualidad tienen ms de 500,000, y algunos tienen
ms de un milln de instrucciones. Ningn individuo puede entender la complejidad
de un sistema tal, sobre todo si 1) no estuvo involucrado en el desarrollo del sistema
original y, 2) no se documentaron los requerimientos y el diseo originales. Y sin
embargo eso es precisamente lo que pedimos de la mayora de los programadores
de mantenimiento.3
Existen docenas, si es que no cientos, de ejemplos de organizaciones con pro
blemas severos de mantenimiento del tipo descrito anteriormente. Casi cualquier or
ganizacin im portante que empez a com putarizarse hace 20 aos ahora se
enfrenta a sistemas de 20 aos de antigedad cuya implantacin es un misterio y,
peor an, cuyos requerimientos de usuario son un misterio.
1 U n a e n c u e s ta en [L ie n tz y S w a n s o n , 1 9 8 0 ] m o s tr q u e a p ro x im a d a m e n te un 9% d e to d o trabajo
d e m a n te n im ie n to c o n s is te e n re p a ra c io n e s de e m e rg e n c ia d e p ro g ra m a .
2 U n e s tu d io h e c h o p o r ei fa b ric a n te b rit n ic o de c o m p u ta d o ra s CL en los a o s 7 0 re v e l q u e a un
s is te m a tp ic o lo m a n tie n e n siete generaciones d e p ro g ra m a d o re s d e m a n te n im ie n to a n te s de ser
d e s e c h a d o fin a lm e n te . E s to s u g ie re q u e m u c h o d e lo q u e lla m a m o s p ro g ra m a c i n d e m antenim ien
to p o d ra d e s c rib irs e m s p re c is a m e n te c o m o a rq u e o lo g a .
3 U n o d e lo s e je m p lo s m s e x tre m o s d e un s is te m a g ra n d e y c o m p ie jo co n re q u e rim ie n to s conti
n u o s d e m a n te n im ie n to e s el p ro y e c to d e E s ta c i n E s p a c ia l q u e a c tu a lm e n te d e s a rro lla la NASA.
Su p ro p s ito e s c o lo n iz a r e in d u s tria liz a r la p o rc i n c e rc a n a d e l s is te m a s o la r. E s t program ado
p a ra d e n tro de 3 0 a o s , y re q u e rir m a n te n im ie n to p e rm a n e n te .
www.FreeLibros.org
La nica solucin a esta crisis en el futuro es mantener documentacin precisa

actualizada por la duracin del sistema mismo. Pero, cmo hacerlo?
i
l4 2
p r e r r e q u i s i t o s n e c e s a r io s
No se puede mantener actualizados un sistema y su documentacin asociada

a menos que sta sea precisa. Este es un punto de partida: debe asegurarse que
cuando un nueo sistema s ponga en operacin todos ios documentos relacionados
gstn completos y sean consistentes, actualizados y precisos.
A lo largo de este libro hemos discutido las caractersticas de un modelo preci
so de los requerimientos del usuario, adems de las reglas a seguir para asegurar
q U e el modelo del sistema sea completo e internamente consistente.
Para que pue
da mantenerse con xito, deben obligatoriamente seguirse estas reglas, y la persona
Independiente o grupo que lo haga debe certificar que los documentos sean precisos
antes de poner el sistema en operacin.
Adems de certificar que los documentos mismos sean precisos, debe asegu
rarse que exista un mecanismo para hacerles cambios posteriores. De nada servir
que la especificacin estructurada se haya inscrito en tablas de piedra como registro
permanente para generaciones futuras; la especificacin debe verse como un docu
mento viviente, sujeto a cambios continuos, aunque controlados.
24.3
COMO HAC ERLO
La primera y ms fundamental de las reglas para el mantenimiento de siste

mas es la siguiente: cualquier cambio propuesto al sistema operacional existente de
be, en todos ios casos, em pezar con un exam en de su im pacto sobre las
especificaciones o requerimientos del sistema. Esto debe hacerse en todos los ca
sos que se mencionan a continuacin, y con cualquier otro cambio propuesto al sis
tema:
El usuario decide que quisiera aadir una nueva funcin al sistema actual.
El usuario no est contento con la forma en la que se realiza alguna fun

cin actual y quiere cambiarla.
El usuario quiere un nuevo reporte de salida adems de los que ya tiene.
El usuario quiere modificar ei formato u organizacin de un reporte de sa

lida existente.
Los programadores de mantenimiento desean recodificar un mdulo para

hacerlo ms eficiente.
www.FreeLibros.org
El departamento de operaciones ha anunciado que planea mejorar los
sistemas de cmputo actuales de la organizacin y se necesitarn algu
nos cambios de programacin.
496
El usuario se queja de que el sistema produce salidas incorrectas para

ciertas combinaciones de entradas.
La organizacin de desarrollo de sistemas ha decidido que Ada se adopte

como nuevo lenguaje de programacin. Se hacen planes para convertir
todo el software existente a Ada.
Se requiere que ei sistema mande salidas a una nueva dependencia gu

bernamental, que no exista cuando se desarroll originalmente.
Cualquier cambio como stos debe ilustrarse, documentarse y ser verificado

con el usuario, haciendo ai modelo del sistema los cambios pertinentes. Esto usual
mente se hace llenando una forma conocida como solicitud de cambio dei sistema.
El cambio de mantenimiento puede involucrar alguno, o todos, los siguientes deta
lles:
Aadir terminadores nuevos al diagrama de contexto, o eliminar anterio

res. Los flujos de datos entre el sistema y sus terminadores podran aa
dirse, e lim in a rse o cam biarse.
Las funciones que previamente
desempeaban los terminadores podran efectuarse ahora dentro del sis
tema; de manera inversa, ciertas funciones que el sistema haca podran
considerarse ahora fuera de l y dentro de los dominios de un terminador.
Puede ser necesario aadir nuevos eventos a ia iista, o eliminar otros.
Si el cambio es substancial, puede modificarse la declaracin de propsi

tos en el modelo ambiental.
Los modelos de flujo de datos, modelos de entidad-relacin o modelos de

transicin de estados pueden requerir cambios.
Las especificaciones de proceso y el diccionario de datos pueden necesi

tar modificarse o retinarse.
Varios aspectos del modelo de implantacin del usuario pueden requerir

cambios que involucren la interfase humano-mquina o las restricciones
de implantacin que se refieren a! tiempo de respuesta, etc.
Ningn cambio de stos vendr gratis. Es posible que algunos sean mnimos
y slo requieran unos cuantos minutos de trabajo para ser incorporados, es decir,
slo tomara minutos hacer los cambios necesarios a ia especificacin y a ios pro
gramas existentes. Sin embargo, la persona o grupo que realiza los cambios tiene la
obligacin de escribir una declaracin de impacto: esto es, una declaracin precisa y
detallada de los cambios necesarios en la especificacin del sistema para poder im
plantar el cambio propuesto. Adems, debe existir una declaracin de impacto eco
nmico: es decir, una declaracin del costo del cambio y el beneficio que se estima
que traer. Es sobre todo importante si la actividad de mantenimiento cambiar ei
enfoque del sistema.
www.FreeLibros.org
Desde luego, habr algunos cambios que no causen impacto en la especifica

ron del sistema: una correccin de programacin para arreglar un error, un cambio
je codificacin para mejorar la legibilidad o ia eficiencia del sistema existente, o un
cambio del hardware o software existentes (compilador, sistema operativo, sistema
je administracin de bases de datos, etc.). Sin embargo, incluso en estos casos de
be generarse una declaracin de impacto econmico para que el usuario y la organizacn de desarrollo de sistemas entiendan los costos y beneficios asociados con
dicho cambio.
Cualquier cambio dei sistema comnmente resultar en un cambio del software y/o hardware; tambin puede resultar en el cambio de los manuales del usuario,
procedimientos de operacin y varios otros componentes dei sistema. Pero el docu
mento ms importante de actualizar es definitivamente la declaracin de requeri
mientos del usuario. Sin l, los cambios o modificaciones futuros se volvern cada
vez ms difciles de hacer: y el cambio a un sistema totalmente nuevo ser infinita
mente ms caro, tardado y doloroso de lo que debera.
No hay duda de que un analista veterano con 20 aos de experiencia vera es
ta peticin de especificacin de sistema actualizado con ojos enfermos. Despus de
todo, el proceso de anlisis y ia tarea de crear una especificacin precisa han sido
tan difciles durante tantos aos, que la idea de mantenerla permanentemente actua
lizada parece casi risible.
La respuesta es, a la larga, la automatizacin. Las estaciones de trabajo auto
matizadas de anlisis de sistemas del tipo descrito en el Apndice A estn disponi
bles a costos accesibles, y representan una dramtica mejora sobre la tecnologa
usada por la mayora de los analistas hoy, como los sistemas de procesamiento de
palabras representan una dramtica mejora sobre la mquina de escribir elctrica
de los aos 60. Hay planes ms ambiciosos para desarrollar ambientes de ingenie
ra de software integrados que abarquen todo y que sirvan de depsito central para
todos los documentos asociados con el desarrollo de un sistema. Sin embargo, tal
tecnologa avanzada probablemente no se desarrolle por completo hasta mediados
de los aos 90.
Sin embargo, queda mucho que hacer aun con la tecnologa disponible actual
mente. Simplemente no hay excusa para hacer cambios a un sistema existente sin
hacer el cambio correspondiente a su especificacin. Sin embargo, para que esto
funcione se requiere una administracin fuerte y disciplinada dentro de la organiza
cin.
24.4
R ES U M E N
Existe una cantidad creciente de libros sobre el tema del mantenimiento de

software, adems de por lo menos una sociedad profesional (ia Asociacin de Man
tenimiento de Software en los Estados Unidos) que se ocupa de cuestiones de man
tenimiento. El nfasis actual es sobre la administracin y refinamiento de programas
www.FreeLibros.org
498
existentes, aunque tambin hay algo sobre el uso de buenas tcnicas de diseo pgr~
crear programas mantenibles. La industria de desarrollo de sistemas est apeng
dndose cuenta de que nunca se podr tener software mantenibie sin especificado
nes mantenibles.
R E F E R E N C IA S
1.
Bennet Lientz y B. Swanson, Software Maintenance Management. Readinq

Mass.: Addison Wesiey, 1980.
2.
James Martin y Carma McCiure, Software Maintenance: The Problem and lt$
Solution. Englewood Cliffs, N.J.: Prentice-Hail, 1983.
3.
Girish Parikh, editor, Techniques of Program and Systems Maintenance. Ut>

coln, Neb,: Ethnotech, Inc., 1980.
4.
Carma McCiure, Managing Software Development and Maintenance. Nueva

York: Van Nostrand Reinhold, 1981.
5.
Robert Giass and R.A. Noiseux, Software Maintenance Guidebook. Englewood

6.
Ned Chapn, Software Maintenance with fourth-generaion Languages , ACM

Software Engineerng Notes, volumen 9, nmero 1, enero 1984, pp. 41-42.
7.
R.N. Britcher y J.J. Craig, Using Modern Design Practices to pgrade Aging
Software Systems, IEEE Software, volumen 3, nmero 3, mayo de 1986, pp.
16-24.
8.
Salah Bendifaliah y Walt Scacchi, Understanding Maintenance Work , IEEE

Transactions on Software Engineerng, volumen SE-13, nmero 3, marzo de
1987.
P R E G U N T A S Y E JE R C IC IO S
1.
Por qu es necesario mantener la especificacin del sistema incluso despus

de haberlo desarrollado por completo?
2.
Por qu suelen ios programadores de mantenimiento hacer cambios a un sis

tema operacionai sin actualizar ios documentos de especificacin asociados?
3.
Proyecto de Investigacin: Averige la edad promedio de ios sistemas que

operan en su organizacin. Algo an ms interesante: investigue cunto tiem
po ms se espera que continen operando antes de ser reemplazados.
4.
Proyecto de Investigacin: Averige cuntos de ios sistemas que actualmente

estn en operacin tienen especificaciones actualizadas. Estn al tanto de
estas estadsticas los analistas y usuarios de su organizacin?
www.FreeLibros.org
g_ Qu dificultades se ocasionan si un sistema lo usan usuarios y io mantienen

programadores que no estuvieron involucrados con su desarrollo original?
0
D seis ejemplos de los tipos de cambios que el usuario podra desear hacerle
a un sistema operacional.
7_ Por qu es posible que se hayan aadido terminadores nuevos al diagrama

de contexto durante el mantenimiento de un sistema?
8.
Por qu es posibie que se hayan aadido acontecimientos nuevos a la lista

durante ei mantenimiento del sistema?
g,
Bajo qu condiciones podra necesitar cambios la declaracin de propsitos

de un sistema durante su mantenimiento?
10.
11
Qu es una declaracin de impacto? Por qu es importante?

Por qu ha sido difcil mantener actualizados ios documentos dei anlisis de
sistemas (el modelo esencial del sistema) en la mayora de las organizacio
nes?
12. Qu tipo de desarrollo tecnolgico es probable que se requiera para asegurar

que los documentos del anlisis de sistemas se mantengan actualizados?
www.FreeLibros.org
EL FUTURO DEL
ANALISIS
ESTRUCTURADO
Todo intento de p re d e cir el fu tu ro con algn de talle parecer risible dentro de

algunos aos. E ste libro tiene un fin ms rea lista y, sin em bargo, ms am bi
cioso. No trata de de scrib ir e l futuro, sino de d e fin ir los lm ites dentro de los
cu ales deben e sta r los p o sib le s futuros. Si con sid e ra m o s el tie m p o que nos
queda p o r delante com o un p a s inexplorado y sin m apas, lo que intento ha
cer es e stu diar sus fron te ras y darm e una idea de su extensin. La g e o gra
fa d e talla da de su in te rio r debe seguir d e sconocida hasta que lleguem os a
eiia.
A rth u r C. C larke, P erfiles d e l futuro
lo largo de este libro hemos visto una evolucin de ideas y tcnicas en el

campo del anlisis de sistemas. Caben en tres periodos amplios:
1.
El anlisis de sistemas convencional, anterior a los aos 70, caracteriza

do por (si acaso) especificaciones tipo novela victoriana que eran difciles
de leer y entender, y casi imposibles de mantener.
2.
El anlisis estructurado clsico, de mediados de los aos 70, a mediados

de los 80, como se describe en [DeMarco, 1978], [Gane y Sarson, 1977] y
otros. Esto se caracteriz por primeras versiones de modelos grficos, y
nfasis en ei modelado de las implantaciones actuales de un sistema an
tes de modelar el nuevo.
3.
El anlisis estructurado moderno, como io describen este libro y otros re

cientes tales como [Ward y Mellor, 1985] y [McMenamin y Palmer, 1984].
Este captulo resume algunos de los cambios de principal importancia que su

cedieron desde la introduccin del anlisis estructurado clsico a fines de los aos
70, y su uso como punto de partida para la discusin de probables cambios en los si
guientes 5 a 10 aos.
www.FreeLibros.org
500
EL FUTURO DEL ANALISIS ESTRUCTURADO
501
QUE HA CAMBIADO
Diversos aspectos del anlisis estructurado han cambiado gradualmente a lo

de os ltimos 10 aos. Las principales reas de cambio incluyen lo siguiente:
Cambios de terminologa. Ahora podemos usar el trmino modelo am

biental para describir lo que sola llamarse simplemente diagrama de con
texto. Esto se debe a que el anlisis estructurado clsico no inclua una
lista de acontecimientos como parte del modelo formal del sistema. Ade
ms, ahora usamos ei trmino esencial en lugar de lgico para describir
un modelo que se concentra en lo que el sistema tiene que hacer, y el tr
mino de implantacin en lugar de fsico para describir un modelo que se
concentra en cmo se desarrollar el sistema. Estos obviamente son
cambios mnimos, pero ayudaron a reducir la confusin cuando se habla
con usuarios que se preguntan si lo opuesto a un sistema lgico es un
sistema ilgico.
Particin de acontecimientos. Uno de ios acontecimientos ms significati

vos del anlisis de sistemas, que se discuti en los Captulos 20 y 21, fue
el uso de una lista de acontecimientos para guiar e! desarrollo inicial del
modelo de comportamiento. Esto reemplaza a! enfoque de ia particin
estrictamente descendente dei diagrama de contexto en un diagrama de
flujo de datos de alto nivel (figura 0), y de ste en niveles inferiores, etc.
Aunque este enfoque descendente no est mal en sentido alguno, ha sido
difcil para muchos analistas: el enfoque de particin por acontecimientos,
que es un enfoque horizontal, ha mostrado ser de ms xito en muchos
proyectos de anlisis.
La desenfatizacin del modelado fsico actual. Como se seal en el Ca

ptulo 17, existe un buen nmero de razones por las cuales el analista se
pudiera sentir tentado a modelar la implantacin actual de un sistema.
Pero una y otra vez hemos encontrado que sta es una tentacin peligro
sa y que el analista pasa ms tiempo con esta actividad del que de hecho
amerita. Aunque no excluimos el modelo fsico actual, si tratamos de de
senfatizarlo y de evitarlo. El anlisis estructurado moderno enfatiza el de
sarrollo, tan pronto como sea posible, de un modelo esencial del sistema
nuevo.
Herramientas de modelado en tiempo reai. El anlisis estructurado clsi

co estaba destinado principalmente al desarrollo directo de sistemas de
negocios; no consideraba interrupciones, seales ni cuestiones de tiem
po. Sin embargo, muchos de los sistemas complejos actuales s incluyen
una variedad de cuestiones de tiempo real, y las herramientas de modela
do del anlisis se han extendido acorde con ello. Se han utilizado flujos y
procesos de control para aumentar los diagramas de flujo de datos, y se
www.FreeLibros.org
502
han introducido ios diagramas de transicin de estados como nueva he

rramienta para mostrar los requerimientos dependientes del tiempo de
sistema.
Integracin ms cercana del modelado de procesos y de datos. El anlj,

sis estructurado usaba diagramas de estructura de datos para modelar |gs
relaciones entre almacenes en el diagrama de flujo de datos. Sin embar
go, las relaciones a menudo se complicaban por la notacin, y la notacin
tenda a causar discusiones intensas y debates sobre el diseo e impiar,,
tacin de una base de datos fsica. El diagrama de entidad-relacin qu8
se presenta en este libro proporciona un modelo ms lgico o conceptual
de los datos requeridos por el sistema, y permite que las relaciones entre
entidades de datos se describan rigurosamente y con detalle. Adems
las reglas de balanceo que se discuten en el Captulo 14 aseguran queei
modelo de datos (que se documenta con DERs) sea completamente con
sistente y compatible con el modelo del proceso (que se documenta con
DFDs y especificaciones de proceso).
Es importante estar familiarizado con estos cambios, o podra encontrarse tra

bajando para una organizacin que an no ios ha incorporado a sus estndares;
cuando se estaba escribiendo este libro, muchas organizaciones grandes que visit
en los EUA todava estaban usando mtodos de desarrollo de sistemas que tenan
por lo menos 10 aos de antigedad.
25.2
ACONTECIMIENTOS FUTUROS EN EL ANALISIS ESTRUCTURADO
Nadie puede decir que conoce el futuro con detalle; cuando ms, como seala
Arthur C, Clarke en la introduccin de este captulo, se desea encontrar algn sea
lamiento del futuro. Los acontecimientos recientes sugieren un nmero de tenden
cias que probablem ente continen hasta bien adentrada ia siguiente dcada,
Incluyen io siguiente:
2 5 .2 .1
Mayor d ifu si n del
a n lis is d e
sistem as
Las computadoras, como todos lo sabemos, se estn convirtiendo en una par

te de la vida de todo mundo. Consecuentemente, encontramos que un segmento ca
da vez mayor de la sociedad est aprendiendo a usarlas y a hablar acerca de ellas;
de ms importancia an (en el contexto de este libro) es el hecho de que muchas
personas se estn familiarizando con el anlisis estructurado y otros aspectos de la
ingeniera de software. Sobre todo estoy interesado en el impacto futuro del anlisis
estructurado sobre tres grupos: los niveles superiores de administracin en nuestras
organizaciones gubernamentales y de negocios, los nios, y profesionales de ia
computacin en los pases del tercer mundo.
www.FreeLibros.org
503
En la mayor parte de las organizaciones grandes normalmente es el caso que

|0S niveles superiores de administracin estn formados por gente de ms de 40
aos, o de 50 o 60. Esto significa que recibieron su educacin y pasaron los aos
(ormativos de su carrera hace 20, 30 o incluso 40 aos. Las computadoras cierta
mente existan hace 20 aos (o incluso hace 30), pero no eran ampliamente accesi, yes y no eran parte de la tecnologa o la cultura con la que crecieron. Pero eso est
| ernpezando a cambiar; se comienza a ver niveles superiores de administracin que
i f)empezaron su carrera en la organizacin de proceso de datos o de sistemas de
inform acin1, o bien 2) empezaron su carrera en alguna otra parte de la organizacin
j (por ejemplo, ventas, contabilidad o manufactura) cuya operacin diaria se vio dra
mticamente afectada por la tecnologa de las computadoras. Esto significa que, co
mo analista, podr esperar que los niveles superiores de la administracin estn
cada vez ms conscientes de la importancia estratgica de los sistemas de proceso
de informacin de su organizacin, y que cada vez estarn ms interesados en ver
modelos de alto nivel de los sistemas nuevos importantes. Si trata de mostrar un
diagrama de flujo de datos al vicepresidente de su organizacin hoy en da, lo ms
probable es que no lo entendera, y tampoco entendera el por qu debiera enten
derlo. Dentro de los prximos 5 aos, creo que los niveles superiores de administra
cin empezarn a darse cuenta que es tan importante poder leer (y criticar) un
modelo de sistema como leer y criticar una hoja de balance o una declaracin de
prdidas y ganancias.
Los nios tambin se familiarizarn cada vez ms con el anlisis estructurado
los prximos aos. La programacin y diseo estructurados ya se estn ense
ando en el nivel de la preparatoria en algunas p a r t e s de los Estados Unidos. Ei
anlisis estructurado, que alguna vez fuera tema de seminarios de nivel de posgra
do, ahora se ensea en el tercer y cuarto aos de las licenciaturas en computacin y
de administracin, y pronto ser parte de una materia estndar de primer ao. La di
visin alguna vez fue tema avanzado y ahora se le ensea a ios nios pequeos; de
manera similar, el anlisis estructurado ser un tema que los nios aprendern d u
r a n t e su proceso educativo normal.
en
Se estima q u e un nio nacido en 1980 terminar la escuela secundaria hacia

fines de siglo habiendo escrito unos 10,000 renglones de cdigo; esto es, a grandes
r a s g o s , equivalente a 2 aos de experiencia de tiempo completo en programacin
p a r a ei programador adulto de hoy. Adems de esta experiencia en programacin,
s e p u e d e esperar que la generacin actual de nios tenga cada v e z ms experiencia
e n anlisis y diseo de sistemas. No toda esta generacin acabar escogiendo c o
m o carrera la d e analista o programador; de hecho, s l o u n a pequea parte escoge
1 Tres ejem plos de esto son John Reed, el actual presidente de Citcorp; R ichard C randall, je fe de
American A irlines, y Frank Lautenberg, a n terior presidente de ADR (la com paa de servicio s de n
mina) y actualm ente uno de los dos senadores del estado de Nueva Je rse y en ios EUA. Existen
tambin diversos ex-program adores y e x-analistas que son m iem bros del co n g re so de los Estados
www.FreeLibros.org
U n ao s.
504
r este camino. Pero el resto de los nios de hoy, ya sea que escojan ser contado
res, o ingenieros, agentes de ventas, maestros o polticos, formarn una comunidad
de usuarios inteligentes de sistemas de informacin; los usuarios sabrn mucho mfe
acerca de lo que se puede esperar de un analista y qu preguntarle. Al parecer, gran
parte de nuestro trabajo actual radica en la dificultad de tratar con usuarios ignoran
tes, y esto posiblemente ser superfiuo en un futuro.
Existe otro aspecto de la creciente difusin dei anlisis estructurado que debe
mencionarse: su impacto sobre la industria de software del tercer mundo. En la lti
ma dcada ia competencia internacional se volvi ms intensa en muchas industrias
manufactureras, y la industria estadounidense ha perdido terreno (o ido a la quiebra)
ai enfrentarse a las japonesas, coreanas, chinas o brasileas que ofrecen productos
de alta calidad a precios competitivos. El mismo fenmeno se est empezando a dar
en la industria de desarrollo de sistemas. Las tcnicas de ingeniera de software, In
cluyendo las tcnicas de anlisis estructurado que se discuten en este libro, pueden
ayudar a una organizacin competitiva a desarrollar sistemas con un grado de pro
ductividad diez veces mayor que la de muchas organizaciones norteamericanas y
con un nivel de calidad (expresado en trminos de tiempo medio entre fallas o nme
ro de errores) cien veces mayor que la de las industrias norteamericanas del mismo
tipo.2 Y dado que, en cada vez mayor grado, todos los productos y servicios depen
den de sistemas de informacin basados en computadora, esto tiene implicaciones
profundas para toda la industria estadounidense.
25.2.2
P roliferacin de herram ientas autom atizadas
A lo largo de este libro hemos mencionado la posibilidad de usar herramientas

basadas en estaciones de trabajo para automatizar diversos aspectos del anlisis
estructurado, sobre todo las actividades de creacin de modelos grficos de siste
mas y su revisin para verificar que estn completos y sean correctos.
El Apndice A describe las caractersticas de muchos paquetes de herramien

tas de este estilo disponibles en el mercado cerca de 1990, lo mismo que las carac
tersticas que es probable que incluyan durante los prximos aos. Lo importante es
que estos productos existen ahora y que se volvern cada vez ms poderosos du
rante la siguiente dcada.
Pero pocos analistas usan estas herramientas hoy. En 1987 se estimaba que
menos del 2 por ciento de los analistas de sistemas de Norteamrica y Europa ten
an acceso personal a una herramienta automatizada apropiada. Esto significa que la
organizacin tpica de desarrollo de sistemas tiene una o dos estaciones de trabajo
para el dibujo de diagramas de flujo de datos, diagramas de entidad-relacin, etc.
2 Para una discusin referente a esto vea D. T ajim a y T. M asubara, The C om puter Industry in Japan", Com puter, volum en 14, nm ero 5 (m ayo de 1981), pp. 89-96.
www.FreeLibros.org
505
II gstas estaciones pueden ser compartidas por toda la organizacin de cien o ms

II personas, pero m s a menudo las usa algn equipo de proyecto aislado que tuvo la
I syerte, tenacidad o visin para invertir en esta tecnologa.
Para 1990 se estima que aproximadamente un 10 por ciento de los analistas
I jg Norteamrica y Europa (y otras partes civilizadas del mundo tambin) tendrn
| sUS propias estaciones de trabajo personales. Y para mediados de los aos 90 es
I r32 onabe esperar que por lo menos un 50 por ciento de los analistas las tengan.
I cuando se haya alcanzado la masa crtica ser razonable argumentar que nuestro
I enfoque del anlisis de sistemas habr cambiado fundamentalmente, porque la ma| yora de ios analistas tendrn herramientas nuevas poderosas. Como analoga es
j interesante discutir las mejoras que se pueden lograr en el rea de la carpintera uti
lizando una sierra elctrica en lugar de una manual, pero el asunto no tiene caso si
slo el 1 por ciento de los carpinteros cuentan con electricidad. Y el poder de una
herramienta dada s afecta ia forma en la que trabajamos con el mundo que nos ro
dea; Craig Brod recalc este punto elocuentemente en una obra clsica titulada
Technostress ([Bro, 1984]):
Las herramientas siem pre han im p ulsad o grandes cam bios en las
sociedades hum anas. Las herramientas nos crean tanto como no
sotros a ellas. La lanza, por ejempio, co n trib u y con mucho ms
que simplemente extender ei alcance del cazador; cambi la fo rm a
de cam inar y el uso de sus brazos. Foment la mejor coordinacin
de manos y ojos; llev a organizaciones sociales para rastrear, m a
ta r y trae r presas grandes. Ampli la brecha entre el cazador inex
perto y el experto e hizo ms im portante el intercam bio de
informacin, a medida que las expediciones de caza se volvan ca
da ve z ms complejas. Hubo otros e fe c to s , menos obvios: los
cambios en la dieta de las sociedades cazadoras llevaron a com
partir ios alimentos y a la fo rm a ci n de nuevas relaciones sociales.
El valor de la artesana aument. La gente comenz a planear por
adelantado, almacenando armas para reusarlas luego. Todas estas
exigencias relacionadas con nuevas herramientas, a su vez, lleva
ron a un mayor desarrollo dei cerebro. La complejidad del cerebro
llev a nuevas herramientas, y stas hicieron q ue los cerebros an
ms co m p le jo s fueran una ventaja para la supervivencia de la es
pecie.
Parece evidente hasta aqu que la tecnologa de las herramientas automatiza

das continuar avanzando durante los prximos 10 aos. El paquete de herramien
tas del analista de mediados de los aos 90 tendr casi seguramente complejas
facilidades para revisin de errores, adems de la capacidad de generar cdigo e in
cluso sugerir (utilizando tcnicas de inteligencia artificial) posibilidades para reutilizar
cdigo de las bibliotecas de software.
25.2.3
El im pacto de ios desastres de m antenim iento
www.FreeLibros.org
En el Captulo anterior mencionamos al usuario del modelo deanlisis estruc
facilitar el mantenimiento y la modificacin desistemas.
Pero sta es
turado para
506
una cuestin que a menudo parece abstracta, filosfica, y polticam ente sin impor.
ta nd a durante la fase de desarrollo de un proyecto, donde ai parecer el nfasis con.
siste en entregar el sistema al usuario. Entregarle de preferencia un sistema que
opere y, con suerte, que sea el que ei usuario quera. Pero, s no fuera as, entoq.
oes cualquier sistema que aparentemente trabaje y satisfaga por lo menos algunos
de los requerimientos. La realidad poltica simple es que algunos administradores
de alto nivel en las organizaciones no aprecian an del todo la importancia del anli
sis estructurado y de los modelos rigurosos y formales de los sistemas. Incluso en
tre las filas del proceso electrnico de datos, el anlisis estructurado no goza de la
importancia que se adjudica a la necesidad poltica de entregar a tiempo al usuario
un sistema que opere (o que supuestamente lo haga).
Como suger anteriormente, la situacin cambiar al familiarizarse cada vez
ms la comunidad usuaria con la tecnologa de las computadoras, y al intensificarse
cada vez ms la competencia de ios pases del tercer mundo. Pero existe otro fen
meno que resaltar de manera dramtica la necesidad de ios modelos actualizados
de sistemas, mantenidos tan diligentemente como el cdigo fuente: ios desastres de
m antenim iento que ocasionen el colapso de los sistem as actuales.
En ei caso extremo, esto puede suceder debido a que un sistema existente,
grande, complejo y no documentado, aborte o se detenga completamente, sin que
nadie pueda determinar cmo arreglarlo. Pero esto es poco probable; es ms proba
ble que la causa de la falla se identifique y simplemente se excluya. Correr enton
ces ia voz de que: Ya no se puede ingresar una transaccin de tipo X25 ai sistema
porque causa problemas .
No, a causa ms probable de un gran desastre de mantenimiento ser la im
p osibilidad total de hacer alguna m odificacin necesaria y urgente a un sistema exis
tente. A veces una nueva legislacin o poltica de gobierno es la que obliga a tales
cambios, pero puede ser tambin que se requieran debido a cambios en

de negocios o a la situacin competitiva.
el ambiente
Ya muchas organizaciones enfrentan este problema; muchos de sus sistemas

que se disearon a fines de los aos 60 o comienzos de los 70 estn ai borde del
colapso, y un da s se colapsarn. Parte del problema est relacionado con la im
plantacin del sistema, es decir, un cdigo que se ha remendado tantas veces que
ya no es posible determinar con precisin cmo opera el sistema.
Pero el problema mayor, en mi opinin, es que

supone que deben hacer estos sistemas en realidad.
nadie sabe o recuerda qu se

Los programadores de mante
nimiento de la tercera generacin interactan con usuarios de tercera generacin pa
ra discutir posibles cambios a un sistema cuyos requerimientos originales son un
misterio para ambos. En este ambiente, es inevitable que los programadores de
mantenimiento tarde o temprano se rindan y se rehsen a realizar ms cambios.
www.FreeLibros.org
507
Cuando se enfrenta con un problema de este tipo, ia administracin probable

mente tendr una reaccin de reflejo:se formarn comits, se impondrn estndareS y se promulgarn nuevos procedimientos. As como se ha visto a jefes de
gobierno reaccionar ante problemas de desperdicios txicos, derrames de combusti
ble y otros, slo despus de que el desastre ocurre, pienso que muchos administra
dores de primer nivel de negocios y de gobierno reaccionarn al problema de los
inexistentes modelos de sistemas slo despus de que ocurra un problema impor
tantede mantenimiento.
25.2.4
El m atrim onio del an lisis estructurad o y
la inteligencia
a rtific ia l
En la actualidad se est dedicando mucha atencin a la inteligencia artificial

en los negocios, el gobierno y la industria compufacional: sistemas expertos, siste
mas de lenguaje natural, robtica y muchos campos relacionados. Aunque en un
tiempo se consideraba a la inteligencia artificial como un tema acadmico con poca
aplicacin prctica, y aunque se implantaba en hardware extico con lenguajes no
familiares de programacin tales como LISP y PROLOG, ahora se est convirtiendo
cada vez ms en un tpico de inters comn, sobre todo el rea de los sistemas ex
pertos, que pueden duplicar la conducta de expertos humanos en ciertos campos de
finidos precisamente.
Existen cada vez ms paquetes de software y textos de inteligencia artificial
basados en COBOL y PCs (vase por ejemplo [Taylor, 1985], [Derfler, 1985], [Webster, 1985], [Keller, 1986] y [Rose, 1985], Cada vez ms aplicacio
nes de inteligencia artificial se estn adentrando en el mundo de los negocios, desde
Diagnsticos mdicos hasta exploracin petrolera o evaluaciones de bolsa, o incluso
pianeacin de impuestos.3
para ambientes
Qu tiene esto que ver con el anlisis estructurado? La conexin entre inteli
gencia artificial y sistemas expertos funciona en ambos sentidos: el anlisis estructu
rado puede servir de auxiliar en el proceso de construccin de un sistema experto, y
istecnologa de los sistemas expertos puede servir de auxiliar en el proceso de rea
lizar el anlisis estructurado.
Cuando se construye un sistema experto, a menudo dominan tres aspectos: la
la representacin del conocimiento, y la mquina de infe
rencias que evala e interroga a la base de conocimientos. La interfase humanonquina puede involucrar entradas en lenguaje natural (ingls, francs, alemn,
ruerfase humano-mquina,
3 Una gran cantidad de trabajo artificial se realiza en hardware especializado utilizando lenguajes
de orogramacin especializados como Lisp y Prolog. Sin embargo, 1) la mayora de ias compaas
preferiran integrar sus aplicaciones de inteligencia artificial con las dems aplicaciones que ejecu
tan en su computadora principal estndar IBM; 2) la mayora de los programadores prefieren usar
lenguajes como CO BO L a lenguajes tan esotricos como Prolog y, 3) las aplicaciones de inteligen
cia artificial orientadas a los negocios tendrn que acceder a ia base de conocimientos, que ya
www.FreeLibros.org
existe en la com putadora principal.
508
etc.) y una combinacin de grficos, texto y sonido como salidas. La base de cono
cimientos puede expresarse por medio de una serie de reglas SI-ENTONCEs.
OTRO, o como una serie de marcos.4 La mquina de inferencias puede basarse en
un enfoque de encadenamiento progresivo o regresivo y puede implantarse en un
cascarn (shell) experto comercial.
Pero lo importante acerca de todo esto es que los componentes det sistema
experto se estn convirtiendo en slo parte de un sistema mayor, por ejemplo, un
sistema operacional que alimenta y actualiza una base de conocimientos o que usa
las salidas del componente dei sistema experto para realizar otras funciones del sis
tema. As, las herramientas de modelado dei anlisis estructurado pueden usarse
para ayudar a modelar el sistema global. Pero lo ms importante es que significa
que durante los prximos 5 a 10 aos, usted tendr que familiarizarse con ia tecno
loga de los sistemas expertos y artificiales para poder ser un analista con xito. El
libro de Keller ([Keiler, 1986]) es bueno para empezar, pues muestra muchas de las
interacciones entre el anlisis estructurado y los sistemas expertos.
En el sentido inverso, la inteligencia artificial puede coadyuvar al proceso del
anlisis estructurado actuando como tutor para guiar a un analista novato en los di
versos pasos y procesos descritos en este libro. Se puede uno imaginar fcilmente,
por ejemplo, a un asistente de analista haciendo una serie de preguntas al analista
humano y produciendo luego un diagrama de contexto propuesto o una lista de
acontecimientos. Piense: Puede recordar a estas alturas todas las reglas y guas a
seguir plasmadas en las ltimas cien pginas, ahora que ha llegado al final del libro?
Cree que las podr recordar dentro de un ao? No sera bueno tener un sistema
experto disponible en una PC que le recordara cmo dibujar los DFD, DER y DTE
balanceados?
Aunque todo esto suena muy bien, no debe preocuparse por la posibilidad de
que los sistemas expertos estn desplazando a los analistas humanos. Los investi
gadores en este campo sealan que todos los sistemas expertos con xito, que van
desde el diagnstico mdico hasta el anlisis de la bolsa, lo han tenido debido a que
se han concentrado en un campo muy limitado de dominio. Un analista con xito, por
lo contrario, realmente necesita ser experto en distintas reas: debe comprender la
tecnologa dei anlisis estructurado que se presenta en este libro; debe entender el
rea de aplicacin del usuario; debe saber mucho de contabilidad, para poder produ
cir clculos precisos de costo-beneficio; debe ser experto en comunicaciones y psi
cologa cognoscitiva, para que pueda comunicarse de manera efectiva con los
diseadores y programadores. Las estimaciones actuales (vase por ejemplo,
[Barstow, 1987]) son que los sistemas expertos podrn ayudar con ia labor del ana
lista de sistemas en sistemas sencillos para mediados de los aos 90, pero pasar
del final de este siglo antes de que la tecnologa de los sistemas expertos sea capaz
de realizar el anlisis de sistemas ms grandes.
www.FreeLibros.org
4 V er [K eller, 1986] para una de scrip ci n de los m arcos.
j 5 2.5
509
El im pacto de las nuevas generaciones de hardware

de las com putadoras
Las compaas particulares, universidades, organizaciones de investigacin y

gobiernos de todo el mundo estn gastando enormes sumas de dinero
; c0n el objeto de producir hardware dramticamente ms poderoso durante los si
mientes 10 15 aos. Una estimacin reciente, dada por Gordon Bell, de la Fundac5n Nacional de Ciencias de los Estados Unidos, en una pltica en la 1986 Fall
jointComputer Conference, es que la tecnologa dei hardware de las computadoras
mejorar en un factor de 10 dentro de ios prximos 5 aos; y luego en otro factor de
10 durante los 5 aos siguientes, y otro ms durante ios 5 siguientes. En la misma
conferencia, el fsico ganador del premio Nobel Ken Wilson hizo una prediccin an
optimista: un factor de mejora de 100 en ios prximos 5 aos, seguido de otro
factor de 100 en los siguientes 5, y nuevamente por otro de 100 en los siguientes 5.
por ello, dos cientficos importantes sugieren que dentro de los siguientes 10 o 15
aos podremos esperar que ei hardware sea entre 103 a 106 veces ms poderoso
que el de las computadoras de hoy.
j ^litares, y
Qu tiene esto que ver con el anlisis de sistemas? Simplemente esto: el

definir los requerimientos del usuario para un sistema de informacin tiene
que hacerse dentro del contexto de lo que el usuario y el analista creen p o s ib le lo
grarcon ia tecnologa disponible. Pero lo que creemos posible se basa en gran me
dida en lo que sabemos acerca de la tecnologa de las computadoras. Puede
argumentarse que la mayora de los usuarios finales y analistas ni siquiera empiezan
a hacer uso de la tecnologa de hardware existente, asi que, qu harn con una
tecnologa un milln de veces ms poderosa?
asjito de
Experiencias pasadas con otros avances tecnolgicos, por ejemplo en el cam

po de la comunicacin (desde seales de humo hasta telgrafo y telfono, etc.) y dei
transporte (desde caminar hasta el empleo de caballos, autos o aeroplanos, etc.) da
una pista; nuestra primera reaccin a la tecnologa radicalmente mejorada es conti
nuar haciendo lo mismo que hacamos antes, pero de una manera un poco ms fcil
y rpida (y ms econmica, en muchos casos). Slo ms tarde comenzamos a ver
aplicaciones enteramente nuevas para la nueva tecnologa.
Por ejemplo, considere ei campo del transporte, con el cual todos estamos fa
miliarizados. Aunque el transporte en avin es relativamente nuevo (comparado con
lahistoria de la raza humana), ha estado presente durante toda nuestra vida, y tiene
un impacto importante sobre nuestras suposiciones, tanto conscientes como incons
cientes, tanto explcitas como implcitas, acerca de la manera en que podemos vivir
nuestras vidas. Suponga que alguien le dijera maana, sin embargo, que existe un
tren subterrneo supersnico para llevarlo de la costa oriental a la costa occidental
de los Estados Unidos a velocidades de 5000 kilmetros por hora.5 Cmo afectara
www.FreeLibros.org
5 Esto no es ciencia-ficcin. En el M.I.T. se han hecho propuestas de ingeniera serias para un tren
supersnico.
510
esto a su vida de negocios? Y a su vida social? Qu cambios empezara a hacer

hoy si estuviera razonablemente seguro de que existir esta tecnologa avanzada
dentro de los siguientes 3 a 5 aos?
Y sta es precisamente la posicin en la que nos encontramos como analistas
para el resto de este siglo; cada vez que se nos d una tecnologa de computacin
dramticamente nueva, nuestra primera reaccin (y la reaccin de los usuarios fina
les tambin) ser reimplantar las aplicaciones existentes de una manera algo ms
eficiente. E l reto ser e n c o n tra r a p lic a c io n e s c o m p le ta m e n te nuevas, e s decir, uso$
de la te cn o lo g a de co m p u ta ci n , c o m p le ta m e n te n u e vo s y d ife re n te s a lo s que ac
tualmente se de sa rro lla n .
25.3
CONCLUSION
Es importante tener una perspectiva orientada al futuro al terminar de leer este

libro y comenzar a practicar el anlisis estructurado en el mundo real. Aunque el
modelado, la solucin iterativa de problemas, la particin descendente, y los dems
conceptos que se discuten en este libro casi seguramente sern vlidos para ei futu
ro previsible, muchos de los detalles (por ejemplo, la tecnologa disponible para apo
yar al anlisis estructurado, e incluso tcnicas tan especficas como la particin por
acontecimientos) pueden cambiar o ser reemplazadas.
No debe esperar que el material que aprendi en este libro sea constante, per
manente y ajeno al cambio. Como toda ciencia, y sobre todo como todos los dems
aspectos de la ciencia de la c o m p u ta c i n , el campo del anlisis de sistemas est
destinado a continuar cambiando, evolucionando y (con suerte) mejorando durante
el siguiente siglo y ms all. Para algunos, es impresionante darse cuenta que lami
tad de lo que se aprende en este campo tcnico ser obsoleto dentro de 5 aos.
Para otros, y espero que se incluir entre ellos, es una fuente de renovacin y emo
ciones constantes.
Y con esto llegamos al final del libro. Todava no es un analista veterano, pero
debiera tener bastantes herramientas y tcnicas para entrar a a profesin sin temor
de caer de bruces. Que disfrute la prctica del anlisis de sistemas de informacin
que beneficiarn a la sociedad. Y que regrese en menos de 5 aos para ver qu ha
cambiado. Caol
REFERENCIAS
1.
Tom DeMarco, S tru c tu re d A n a ly s is a n d S y s te m s S p e d fc a ti n . Englewood

2.
Chris Gane and Trish Sarson, S tru c tu re d S y s te m s A n a ly s is : Toois a n d Techni

ques. Englewood Cliffs, N.J.: Prentice-Hall, 1978.
www.FreeLibros.org
3.
Arthur C. Clarke, Profiles o f the F uture. Nueva York: Holt, Rinehart, and Winston, 1984.
511
4,
Jared Taylor, Lightyears Ahead of Paper, P C M a g a zin e , abril 16, 1985.
Frank Derfler, Expert-Ease Makes Its Own

1985.
g.
Robin Webster, M.1 Makes a
Robert E. Kelier, Expert Technology: D e v e lo p m e n t and A p p lic a tio n , Englewood

Cliffs, N.J.; YOURDON Press, 1986.
8.
Frank Rose, Into the H e a rt o f the M ind. Nueva York: Harper & Row, 1985.
9.
D.
Direct Hit,P C
Rules, P C
M a g a z in e , abril 16,
M a g a zin e , abril 16, 1985.
Barstow, Artificial Intelligence and Software Engineering, P ro c e e d in g s o f

the 9 th In te rn a tio n a l C o n fe re n c e on S o ftw a re E n g in e e rin g , Washington D.C.:
IEEE Computer Society Press, marzo de 1987.
10.
Paul Ward y Steve Mellor, S tru c tu re d D e v e lo p m e n t o f R e a l-T im e S y s te m s ,

Nueva York: YOURDON Press, 1986.
11.
Steve McMenamin y John Palmer, E s s e n tia S y s te m s A n a ly s is . Nueva York:

12.
Craig
Brod, T ech nostre ss.
Nueva York: John Wiley, 1984.
1. Cules son las tres
etapas en la evolucin
han dado a lo largo de los ltimos 20 aos?
del anlisis
de sistemas que se
2. Cules son los cinco principales cambios que se han dado en el campo del
anlisis durante los ltimos 10 aos?
3. Qu significan, en el
contexto
de este captulo, los trminos
lgico y fsico?
4. Qu es particin por acontecimientos? qu ha reemplazado en el campo

del anlisis?
5. Por qu se ha desenfatizado el modelado fsico actual en el anlisis de siste

mas?
6.
Qu
herramientas adicionales se han aadido ai campo dei anlisis de siste

mas para ayudar a modelar sistemas de tiempo real?
7.
Qu es un diagrama
campo del anlisis?
de estructura
de datos? A qu ha
reemplazado en el
www.FreeLibros.org
8. Cmo estn comenzando a afectar las computadoras a los trabajos y activi
dades de los administradores experimentados en las organizaciones?
512
9.
Por qu tendr impacto sobre los proyectos de desarrollo de sistemas en io

aos venideros la enseanza del anlisis estructurado a os nios?
10.
Por qu es probable que el anlisis de sistemas sea un factor en la compe

tencia internacional entre os EUA, Europa y muchos pases del Tercer Mun
do?
11.
Proyecto de investigacin: Qu porcentaje de los programadores y analistas

de sistemas en su organizacin tienen estaciones de trabajo con paquetes de
herramientas de anlisis?
12.
Por qu son importantes las herramientas automatizadas para el anlisis de

sistemas?
13.
Por qu afectarn al anlisis estructurado en un futuro los desastres de man

tenimiento?
14.
Qu relacin es probable que veamos entre la inteligencia artificial y

sis estructurado en un futuro?
15.
En qu porcentaje, o mltiplo, se espera que el hardware de

mejore en ios siguientes 10 o 15 aos?
16.
Por qu tendrn impacto sobre la manera en

temas las mejoras continuas en el hardware?
que se
realiza
el anli
las computadora
el anlisis
de sis
www.FreeLibros.org
APENDICES
El hom bre es un anim al que usa herram ientas... Sin ellas nada es, con
e llas lo es todo.
T hom as C arlyie
S a rto r R esartus, Libro 1, ca p tulo 4
A.1
LOS ANTECEDENTES DE LAS HERRAMIENTAS AUTOMATIZADAS
Una
emplace la
herramienta automatizada puede definirse como cualquier cosa que re

labor manual del programador, del analista de sistemas, o incluso del
usuario final que de alguna manera debe comunicar sus requerimientos a los profe
sionales de las computadoras. Por ello, hay muchas cosas que pudieran considerar
se como herramientas:
L e n g u a je s de p ro g ra m a c i n d e alto nivel, que van desde COBOL y Pascal

hasta los lenguajes actuales de cuarta generacin que permiten ai progra
mador usar instrucciones de alto nivel, parecidas al ingls, que se tradu
cen automticamente a las instrucciones primitivas de bajo nivel que
entiende la computadora.
L ista d o s de re fe re n cia , p ro g ra m a s e m b e lle c e d o re s de im p re s i n , y otros

programas de aplicacin que ofrecen al programador informacin adicio
nal esttica acerca de su programa.
H e rra m ie n ta s de prueba, de correccin d e errores, s im u la d o re s , etc., que

proporcionan al programador informacin acerca del comportamiento di
nmico de su programa mientras se e je cu ta . Las herramientas de mode
lado perm iten al program ador crear una gran variedad de casos de
www.FreeLibros.org
513
514 HERRAMIENTAS AUTOMATIZADAS
prueba para asegurar que e programa se pruebe efectivamente. Las herramientas de c o r re c c i n permiten rastrear errores cuando se sabe qUe
algo anda mal. Los simuladores proporcionan una representacin ms vi
s u a l y grfica de la ejecucin dei programa, por ejemplo, mostrndolo en
forma de diagrama de fiujo en u n a pantalla de video y simulando su com
p o rta m ie n to a la v e z que s e ejecuta, mostrando e! flujo de control a travs
del diagrama de fiujo.
Termnales de tiempo compartido que reemplazan a ios ambientes de de

batalla se lidi y gan hace 15 aos en la mayora
de software, pero es importante darse cuenta de
que una terminal de tiempo compartido es una herramienta. En los aos
60 y comienzos de los 70, los programadores tenan que escribir progra
mas, manualmente, en grandes cuadernos de codificacin; las instruccio
nes se perforaban en tarjetas (recuerda las tarjetas perforadas?) y luego
se metan a la computadora a media noche. Si algo andaba mal (porque
el programador escribi una instruccin sintcticamente incorrecta o por
que el operador encargado de la perforacin lo hizo mal), a la rr.aana si
guiente ie esperaba al program ador un reporte de error. Y el ciclo
volvera a comenzar. Todo eso desapareci para mediados de ios aos
70 en la mayora de las organizaciones: el programador teclea su progra
ma directamente en una terminal de tiempo compartido, que comparte
con cientos de programadores y/o usuarios finales ms. El programa se
revisa contra errores sintcticos en el acto, y se prueba y corrige en elac
to. Hoy es difcil imaginar cualquier otro ambiente. Pero esto se debe en
parte a que se pueden adquirir terminales simples por menos de 500 d
lares estadounidenses. Hace diez aos, el costo andaba por los 3,000 o
ms, y nadie estaba del todo seguro si el programador ameritaba una in
sarrollo por lote. Esta

de las organizaciones
versin as.
Computadoras personales que permiten el desarrollo de programas fuera

de lnea. Actualmente, se invierten 3.000 dlares estadounidenses en
una computadora personal. Las terminales simples son aceptables, pero
slo si la computadora personal a la cual estn conectadas proporciona
un tiempo de respuesta lo suficientemente rpido y consistente como para

permitir a los programadores trabajar productivamente. Muchos sistemas
simplemente no pueden; para la entrada ms trivial proporcionan una res
puesta en 5 segundos, y en 10 segundos a entradas ms significativas.
Una alternativa atractiva es una computadora personal dedicada, que el
programador puede usar para crear un programa y hacerle correcciones y
revisiones apropiadas utilizando un programa estndar de procesamiento
de palabras, para compilarlo y ver si existen errores de sintaxis que ia
computadora principal rechazara, y para realizar algunas pruebas fuera
de lnea.
www.FreeLibros.org
HERRAMIENTAS AUTOMATIZADAS 515
Paquetes de control de programas fuente que evitan que ei programador

haga cambios no autorizados a las versiones oficiales de un programa a
media noche. En un proyecto grande de programacin, una de as dificul
tades es la administracin de ia configuracin: asegurar que exista un
control firme sobre las diversas partes del sistema final. Cada programa
dor trabaja con su propia parte y puede requerir docenas de revisiones
antes de terminarla. Pero en dicha parte laboran docenas de programadores ms. La anarqua prevalece a menos de que todo mundo sepa cul
versin de cul parte se va a considerar como versin oficial. Un paquete
de control de cdigo fuente es como un bibliotecario automatizado: evita
el acceso no autorizado a documentos oficiales.
El anlisis de sistemas y herramientas automatizadas de diseo. Las he

rramientas descritas anteriormente se ocupan principalmente de la labor
de escribir programas (es decir, decidir las instrucciones de COBOL o de
FORTRAN requeridas para resolver un problema bien definido). Pero no
es en esto donde existe la principal dificultad en la construccin de un sis
tema de software. El verdadero problema aparece en las etapas tempra
nas del anlisis de sistemas (al tratar de determinar qu debe hacer el
sistema) y del diseo (al tratar de determinar cul debe ser su arquitectu
ra global). Comienzan a verse herramientas para ayudar a los analistas y
diseadores de sistemas.
La mayora de las herramientas descritas anteriormente han existido durante

los ltimos 10 o 15 aos, y muchas se usan ampliamente en las organizaciones de
proceso de informacin. Otras (las automatizadas) son muy nuevas y recin han
empezado a filtrarse en la industria de software a partir de 1987. Son estas herra
mientas, en mi opinin, las que tienen la posibilidad de salvar a ia industria de soft
ware de EUA.
Como hemos visto a lo largo de este libro, el anlisis exitoso de sistemas se
apoya fuertemente en modelos del sistema que se va a computarizar. Las herra
mientas de! analista y del diseador se ocupan principalmente del desarrollo eficaz
de dichos modelos; por ejemplo, ayudan al analista a construir diagramas grficos
que permiten al usuario final entender lo que el sistema har para l. Las herra
mientas automatizadas tambin permiten al analista y al diseador asegurarse que
el modelo est completo y sea preciso y consistente, de manera que los errores des
cubiertos durante la fase de programacin slo sean errores de programacin, y no
un reflejo de continuos malos entendidos entre el usuario fina! y el analista.1 Y, fi
nalmente, esas herramientas pueden ayudar al programador a traducir el modelo a
1 E sto e s im p o rta n te , p u e s s a b e m o s q u e e l 5 0 % d e lo s e rro re s d e un p ro y e c to tp ic o d e d e s a rro
llo de s is te m a s se d e b e n a m a lo s e n te n d id o s e n tre el u s u a rio fin a l y e l a n a lis ta ; u n 7 5 % d e l c o s to
de e lim in a rlo s e n un s is te m a o p e ra c io n a l s e a s o c ia con errores q u e s e o rig in a r o n en la fa s e de
www.FreeLibros.org
un programa que funcione. En el futuro podemos esperar que automaticen compfe.

tamente este proceso.
La industria de software ha estado hablando de herramientas de este tipo des
de hace 5 aos o ms; sin embargo no se hizo mucho al respecto. Esto se debi en
parte a que la tecnologa de la ingeniera de software no se haba filtrado an a la iiv
dustria, pero ms que nada era ms bien cuestin de economa. Como seal ante
riorm ente, no fue sino hasta m ediados de los aos 70 que la m ayora de |as
organizaciones de administracin de sistemas de informacin aceptaron la nocin de
que cada programador debe tener una terminal en su escritorio, y tom otros 5 aos
para que muchas las compraran y proporcionaran una computadora principal adicio
nal para el personal de desarrollo de sistemas. (Mientras tanto, dos tres programadores tenan que com partir una term inal, en form a sim ilar a ia de dos o tres
personas compartiendo el uso de una misma extensin telefnica en una oficina,2 y
el personal completo de desarrollo de sistemas tena que compartir la computadora
principal con cientos de usuarios finales que trataban de hacer trabajo til en sus ter
minales).
Mientras tanto, las computadoras personales y las estaciones de trabajo gra
dualmente comenzaban a aparecer en el mercado de os consumidores. A fines de
los aos 70 y principios de los 80, la mayora de los programadores ignoraban a las
mquinas, pues no eran muy poderosas desde el punto de vista de los estndares
de una computadora principal por la cual juzgaban el poder de una computadora.
Una estacin de trabajo de poder suficientemente grande, capaz de ayudar al analis
ta/diseador con sus modelos de ingeniera de software costara entre 50,000 y
100,000 dlares estadounidenses en el periodo de 1980 a 1981, y esto simplemente
se sala de las posibilidades de muchas organizaciones de administracin de siste
mas de informacin. Slo unas cuantas con proyectos y presupuestos enormes con
sideraban siquiera tal gasto; y entonces lo ms que se poda esperar era una
estacin de trabajo para un departamento entero de cientos de personas. Algunas
estaciones de trabajo se desarrollaron en compaas aeroespaciales, compaas
contratadas para el desarrollo de sistemas de defensa, y fabricantes de complejas
estaciones de trabajo de grficos, pero la comunidad de administracin de sistemas
de informacin ignoraba cuidadosamente el concepto.
Para 1983, las cosas empezaron a cambiar. Las poderosas computadoras
personales, con grficas de alta resolucin y capacidad de almacenamiento adecua
da haban cado por debajo de la barrera mgica de precio de 10,000 dlares esta
dounidenses3 Algunas eran estaciones de trabajo orientadas a la ingeniera.
2 En la o p in i n d e la m a y o ra d e lo s p ro g ra m a d o re s , e s c o m o d o s o tre s p e rs o n a s co m p a rtie n d o
m is m o c e p illo d e d ie n te s .
www.FreeLibros.org
3 L o s 1 0 ,0 0 0 d la re s e s ta d o u n id e n s e s s o n m g ic o s p u e s e s la c a n tid a d a p a rtir d e la c u a l se re
q u ie re a u to riz a c i n s u p e rio r p a ra h a c e r e l g a s to . U n a d m in is tra d o r d e p ro y e c to p u e d e v e r los bene
fic io s p r c tic o s d e u n a e s ta c i n d e tra b a jo p a ra in g e n ie ra d e s o ftw a re y a m e n u d o p u e d e proporcionar
fabricadas por compaas nuevas y agresivas tales como Apollo Computer y Sun
C om puter; algunas resultaron ser efmeras, como la computadora Lisa de Apple.
Sin embargo, la mayora resultaron ser configuraciones a la medida de las ne
cesidades de la Inmensamente popular computadora personal de IBM. Al proporcionar una arquitectura abierta, IBM hizo posible que cualquiera construyera una
configuracin especial para satisfacer sus propias necesidades. As, la industria de
herramientas de software poda construir una estacin de trabajo poderosa que con
sista de un chasis de PC IBM, una tarjeta grfica del proveedor A, memoria adicio
nal del proveedor B, y una pantalla de alta resolucin del proveedor C.
Esta capacidad de construir una estacin de trabajo poderosa con la etiqueta
IBM al frente es de importancia crucial en el mercado. La realidad poltica es que en
las organizaciones de negocios como bancos, agencias de seguros y agencias de
gobierno no militares, la computadora personal debe decir IBM al frente; esto es, de
safortunadamente, ms importante que la superioridad tecnolgica del hardware. A
las organizaciones cientficas e ingenieriies no les importa tanto la marca de la com
putadora que usan (aunque muchos preferiran que cualquier computadora personal
que compraran se pareciera a una VAX), y a las compaas norteamericanas contra
tadas para la construccin de sistemas de defensa no les importa qu tipo de com
putadora usen mientras su costo pueda incluirse en el presupuesto estipulado en el
contrato gubernamental.
Existen ahora varias docenas de computadoras en los Estados Unidos y en
Europa que construyen productos de software y hardware de estaciones de trabajo
para ayudar al analista y al diseador de sistemas. Una de las fuerzas impulsoras
de este tipo de compaas es la creencia de que en los siguientes 5 o 10 aos casi
cualquier empleado ejecutivo en ios Estados Unidos, y sobre todo cualquier progra
mador, analista, diseador y usuario final de sistemas de cmputo tendr una pode
rosa computadora personal en su escritorio. El poder del hardware estar ah; ahora
todo lo que necesitamos hacer es aumentar dicho poder con algunos dispositivos
adicionales y algn software poderoso.
La mayora de los productos pueden ejecutarse en computadoras personales
IBM, aunque algunos de los proveedores han escogido las computadoras Appie
Mclntosh o las ms poderosas VAX o Apollo. Casi todos los productos ofrecen al
usuario una paleta de imgenes (formas que pueden usarse para crear dibujos) y un
clculos d e c o s to -b e n e fic io realistas. P e ro si la decisin In v o lu c ra 2 0 ,0 0 0 d la re s , s e to m a r ai n i
vel de un a u xilia r de v ic e p re s id e n te q u e h a pasado sem anas trata n d o de m a n te n e rs e d e s p ie rto el
tiempo suficiente c o m o p a ra h a c e r a lg o til dentro d e ia o rganizacin. Form ar un com it, desarro
llar e s t n d a re s , h a r u n a e n c u e s ta de la in d u s tria y e s c rib ir n o ta s a d o c e n a s d e a u x ilia re s d e vi
cepresidente ig u a lm e n te s o m n o lie n to s . M ientras to d o e s te p ro c e s o d e to m a d e d e c is io n e s s u c e d e ,
el adm inistrador de l p ro y e c to s e e n c o g e d e h o m b ro s , tra ta d e o lv id a r q u e a lg u n a vez s iq u ie ra e n tre 8 la p ro p u e s ta y re g re s a a usar s u s t c n ic a s d e la e d a d d e p ie d ra d e c o n s tru c c i n d e s is te m a s .
Como p o d r n o ta r, s o y to ta lm e n te o b je tiv o y no e s to y e m o c io n a lm e n te in v o lu c ra d o d e ninguna ma
nera en lo re fe re n te a e s te te m a .
www.FreeLibros.org
ratn (mouse) con el cual seleccionar las imgenes. Esto le puede ser familiar $
ha utilizado programas de grficas como MacPaint y MacDraw en ia Macintosh o pq.
Draw o EGA-Paint en las tipo IBM. Sin embargo, ias herramientas automatizadas
de anlisis son mucho ms an: entienden el tema de los dibujos. Y, como veremos
a continuacin, tienen muchas caractersticas que no existen en programas de dibu
jo sencillos.
A.2.
CARACTERISTICAS IMPORTANTES DE LAS HERRAMIENTAS

AUTOMATIZADAS
Es fcil pensar en las herramientas automatizadas para analistas y diseado

res de sistemas como nada ms que productos de dibujo electrnico. Ciertamente
es verdad que ia capacidad grfica de estos productos es muy visible y sexy, pero
es slo una de las caractersticas importantes. Esas herramientas deben proporcio
nar las siguientes caractersticas para ser de uso significativo en el desarrollo de un
sistema complejo:
Manejo de grficas para mltiples tipos de modelos
Caractersticas de revisin de errores para asegurar la precisin de 1q$

modelos
Comparacin de modelos diferentes
Apoyo de ingeniera de software adicional
A.2.1
A poyo g rfico
Como hemos podido apreciar a lo largo de este libro, los modelos dei anlisis
estructurado se apoyan en diversas formas de informacin: texto, diccionarios de da
tos y diagramas grficos. Los textos y los diccionarios de datos pueden automatizar
se usando sistem as de procesam iento de palabras y com putadoras grandes
convencionales; es el apoyo grfico el que siempre ha faltado. El analista de siste
mas necesita una estacin de trabajo que le permita componer, revisar y almacenar
los siguientes tipos de diagramas:
Diagramas de flujo de datos (DFD)
Diagramas de Estructura (DE)
Diagramas de flujo (DF)
Diagramas de Entidad-Relacin (DER)
Diagramas de transicin de estados (DTE)
www.FreeLibros.org
As, la herramienta automatizada del analista le permitira crear el DFD que se
muestra en ia figura A.1(a).
R e p o rte de a n tig e d a d
d e fa c tu r a s
D a to s d e fa c tu ra s
Figura A. 1(a): DFD tp ic o
\ &<\ -4" j
www.FreeLibros.org
Figura A. 1(b): Pantalla tpica de estacin de trabajo del analista
La pantalla de video que ei analista ve al crear el diagrama se muestra en la f>

gura A,1(b).
Debo sealar que compuse este diagrama usando un programa sencillo de q.
bujo llamado MacDraw en la computadora Apple Macintosh que estoy usando para
escribir este libro.4 Me tom 15 minutos componer el diagrama y otros 30 segundos
copiarlo directamente al texto de este captulo. Pude haber dibujado ei diagrama a
mano en 3 minutos, y lo hubiera podido adherir a este captulo usando tijeras y cinta
en alrededor de 30 segundos. El beneficio del apoyo grfico claramente no radica er
el dibujo inicial del diagrama sino en la facilidad de modificacin.
En un proyecto tpico de desarrollo de sistemas, un diagrama como el de la f.
gura A.1 podra modificarse una docena de veces. De hecho, un analista de Tektro
nix me dijo que l y un usuario final modificaron un DFD como el de la figura A.l
ms de cien veces antes de quedar finalmente de acuerdo en que ya se trataba de
un modelo preciso de los requerimientos del usuario.5 Nadie cuerdo considerara
volver a dibujar un diagrama a mano cien veces; sin embargo, hacerle un pequeo
cambio a un diagrama en una pantalla de computadora suele tomar slo alrededor
de un minuto. Algunos resultados iniciales del grupo Hartford Insurance Group, que
tiene ms de 600 estaciones de trabajo instaladas, indican una mejora de hasta un
40 por ciento en la productividad tan slo debido al apoyo grfico automatizado (va
se [Crawford, 1985]),
Tambin debo recalcar que los programas de grficos para usos generales ta
les como MacDraw o MacPaint (para la Macintosh) o PC Draw o EGAPaint (para la
PC IBM) no son realmente apropiados para el ingeniero de software. Para construir
modelos formales de ingeniera de software debe decidirse primero qu imgenes o
smbolos grficos se permitirn. Luego deben definirse reglas para dictaminar las
propiedades de las imgenes y las conexiones legales entre ellas. La figura A.1, por
ejemplo, usa 4 imgenes asociadas con un DFD estndar: un crculo, un rectngulo,
una notacin para almacn de datos y una lnea que muestra el flujo de datos de un
lugar a otro. Sin embargo, MacDraw felizmente me hubiera permitido incluir tringu
los, hexgonos y cualquier otra representacin grfica en el diagrama. Y Macdraw
no sabe que una vez que un flujo de datos se ha conectado con un objeto, ambas
cosas deben tratarse de ah en adelante como un grupo o como un objeto compues-
4 La m ayora d e los q u e d e s a rro lla n s o ftw a re usan p ro d u c to s C A S E ejecutables e n computadoras

p e rs o n a le s IB M , p e ro los dia g ra m a s en e s te lib ro no p ro v ie n e n d e a ll. P a ra usarlos, tendra que
p o n e rm e a d e term in a r com o c o m b in a r lo s diagram as con el a rc h iv o d e te x to dei lib ro , q u e estoy es
crib ie nd o c o n u n a M a c in to s h .
5 O b v ia m e n te , fu e un diagram a m u c h o m s c o m p le jo q u e ei d e ia fig u ra A .1 . D e h e c h o , la mayora

de los d ia g ra m a s d e flu jo d e d a to s re a le s lo son ; tie n e n s ie te u o c h o burbujas, tres o c u a tro almace
nes d e d a to s , u n a d o c e n a o m s de flu jo s d e datos, y v a rio s te rm in a d o re s e x te m o s ..
www.FreeLibros.org
t0 6 En un nivel ms simple, tuve dificultades con ia creacin de burbujas (crculos)

mismo tamao, y tomaba una eternidad ponerle cabezas a las flechas.
^2.2
C aractersticas de revisin de errores
Aunque claramente se necesita de apoyo grfico, de ninguna manera basta

para justificar el gasto de comprar una estacin de trabajo computacionai de 10,000
dlares estadounidenses. La herramienta automatizada debe examinar el modelo
creado por el analista o diseador para asegurar que sea completo e internamente
consistente. La figura A.1, por ejemplo, puede analizarse de ia siguiente manera:
Estn conectadas todas las imgenes? Existen almacenes de datos li

bres o burbujas de proceso que floten alrededor del diagrama, sin salidas
ni entradas?
Tiene cada burbuja por lo menos una salida? Si no, se trata de un agu
jero negro sospechoso que se traga ios datos pero jams produce sali
das.
Se nombran todos los flujos de datos (las lneas con nombre que unen
cuadros y burbujas)? Existen todos los nombres en el diccionario de da
tos?
Tienen nombres nicos todos los procesos (burbujas)?
Se puede hacer una revisin similar de errores en los DE, DF, DER y DTE. Y
revisin de errores se puede extender a varios niveles de modelado. La figura
A.1, por ejemplo, podra ser un subsistema de bajo nivel representado por una soia
burbuja (burbuja nmero 1) en un sistema de contabilidad de mayor nivel, modelado
en la figura A.2.
ia
Las herramientas del analista deben asegurar que las entradas y salidas que
se muestran en la figura A.1 coincidan con las de la burbuja 1 en la figura A.2. Si no
coinciden, ei modelo no es consistente, y ser un infierno semanas (o meses) ms
tarde cuando alguien trate de traducirlo a COBOL, El mismo tipo de balanceo se
puede aplicar a varios modelos grficos ms que proporcionarn una visin descen
dente del sistema.
\ A,2.3
Com paracin de m odelos diferentes
La caracterstica ms importante de las herramientas de trabajo automatizadas

del analista/diseador es la posibilidad de verificar la consistencia de diversos tipos
de modelos de un sistema. Existen dos aspectos de esto: la comparacin de mode6 En re alidad , p u e d e d e c rs e le a M c D ra w q u e c ie rto s o b je to s d e l d ib u jo d e b e n a g ru p a rs e p a ra q u e se
Puedan m o v e r e n c o n ju n to ; p e ro e s to no g a ra n tiz a q u e e l re s u lta d o , tra s h a b e rlo s m o v id o , se ve a co
mo lo de sea. E x is te n p a q u e te s m s e la b o ra d o s , c o m o D e s ig n , d e M e ta S o ftw a re , y lo so n en e l se n
ado de c m o m a n e ja n los o b je to s y lo s c o n e c to re s . P e ro s in im p o rta r lo c o m p le jo q u e se a el p a q u e te ,
no sirve de g ra n c o s a s in las re g la s d e re v is i n de e rro re s q u e se d is c u te n en la S e c c i n A .1 .2.
www.FreeLibros.org
datos y no se muestran en el DFD, hay una inconsistencia. Como se discuti en el

Captulo 14, toda esta comparacin podra hacerse manualmente, pero es una labor
tediosa y propensa a errores en el mejor de los casos. Mis varios aos de experienca en ingeniera de software en ambientes tpicos de administracin de sistemas de
informacin me permiten decir con confianza (desafortunadamente) que no se har
'ânualmente, a pesar de las exhortaciones de los administradores del proyecto y
gS mejores intenciones de los tcnicos.
Adems de la verificacin de consistencia entre modelos en una fase de un
es importante comparar los modelos desarrollados durante diferentes fa
jes. Por ejemplo, los modelos desarrollados durante la fase de anlisis deben com
pararse con los desarrollados durante la fase de diseo. La comparacin debe
amostrar una correspondencia uno-a-uno entre ambos: cada requerimiento descrito
en el modelo de anlisis (es decir, en los DFD, DER, etc.) debe representarse en al
guna parte del modelo de diseo (es decir, os DE, etc.), y cada caracterstica des
crita en ei modelo de diseo debe corresponder con un requerimiento descrito en
alguna parte del modelo de anlisis. El problema ms comn, desde luego, es que
se pierde un requerimiento en ei modelo de anlisis y no aparece en ninguna parte
el modelo de diseo.
p ro y e c to ,
s o lic itu d
de
autorizacin
de pago
pago
/
PRO VEED O R ES|
^
\
Cuentas
por cobrar /
GERENCIA
reportes
pagos
Figura A.2: DFD de m ayor nivel
los diferentes en una fase de un proyecto, y la comparacin de diferentes modelos

en diferentes fases de un proyecto.
En la fase de anlisis de un proyecto, por ejemplo, el objetivo primario es deter
minar qu desea el usuario del sistema, con poca o ninguna referencia respecto a la
tecnologa computacional particular que se usar para implantar dichos requementos. Para esto se requieren DFD para recalcar la divisin de estos requerimientos
funciones separadas y la inferase entre ellas. Se necesitan DER para re c a lc a ^
objetos de datos almacenados en el sistema y sus relaciones.
se req
para recalcar los estados en los que puede encontrarse el sistema y su <somport*
miento dependiente del tiempo. Adems, se usa ei diccionario oe datos Para mante
ner una definicin de todos los datos del sistema y alguna forma de deacnpcic,
textual para definir la poltica formal de negocios de cada uncin de nivel inferi .
Esto se da sobre todo cuando el modelo de anlisis del sistema lo desarrolla

grupo de personas, y el de diseo (y la subsecuente codificacin y prueba) la rea
liza otro. En el caso ms extremo (que a menudo ocurre en proyectos gubernamen
tales), los dos grupos pueden trabajar para distintas compaas. De cualquier
manera, los dos grupos muchas veces representan distintos intereses y perspecti
vas, y pudiera ser que no se comuniquen bien entre s en ningn nivel. De aqu que
tal vez un requerimiento que el equipo de anlisis crea que estaba perfectamente
claro no lo pueda entender el equipo de diseo.
un
A veces el problema es todo lo contrario: el equipo de diseo decide introducir

caractersticas que ei usuario jams pidi y que jams se documentaron en el mode
lo de anlisis. Esto puede ocurrir de manera inocente, pero usualmente sucede
cuando alguien del equipo de diseo dice: Aunque no lo hayan pedido, apuesto a
que a los usuarios les encantar esto. O ei diseador veterano, algo cnico, dice:
Aunque los usuarios no hayan pedido hoy la caracterstica X, s por experiencias
pasadas que lo querrn la prxima semana. Es ms fcil ponerla ahora que esperar
a que la pidan. Si esto es o no razonable no viene al caso. Lo importante es que
esta discusin se ventile en lugar de permitir que el diseador tome una decisin
unilateral.
www.FreeLibros.org
De la misma manera, el modelo de diseo debe compararse con el cdigo
La clave es que iodos estos modelos deben ser consistentes entre s. S i j real. Nuevamente, debe haber una relacin de uno-a-uno entre los componentes del
DFD se refiere a un dato que no est en el diccionario de datos, a go an a i . ^ cdigo (la implantacin misma de os modelos de anlisis y diseo) y los componen
diccionario de datos define datos que no aparecen en ningn otro modelo a^go^ ^ tes del modelo de diseo.
mal Si el DFD muestra almacenes que no estn definidos en el DER, hay
consistencia; y si el DER muestra objetos que no estn definidos en el diccin
A .3
TECNOLOGIA FUTURA DE LAS HERRAMIENTAS AUTOMATIZADAS
Muchas de las caractersticas descritas anteriormente existen en ias herrg.

mientas de trabajo del analista/diseador que se encuentran actualmente en el mercado. Algunas de las caractersticas pueden implantarse en una manera un tanto
primitiva, pero los productos se estn mejorando cotidianamente. No obstante, to
dos los productos deben considerarse como herramientas de primera generacin;
presentan slo el com ienzo de una serie de logros que se obtendrn en lo
siguientes 5 a 10 aos.
j
1
l
j
Las fechas para las herramientas de desarrollo automatizadas de segunda o i

tercera generacin son un tanto confusas. Parte depende de los recursos de |gs j
compaas que las fabrican; parte del desarrollo continuo de tecnologa de hardware
que permitir ms poder en las estaciones de trabajo personales. Y mucho de ello
depende de la cuestin de transferencia de tecnologa. Las organizaciones grande
apenas comienzan a experimentar con una o dos estaciones de trabajo a mediados
de los aos 80, y tomar varios aos que se infiltre incluso la tecnologa de primers
generacin a la industria de desarrollo de software.
i
Sin embargo, tengo ia esperanza de que si en 1995 visita una organizacin

grande y profesional de administracin de sistemas de informacin encontrar que
todos los programadores (si an quedan programadores para entonces), ios anais-
tas, los usuarios finales y los administradores de proyecto tendrn una estacin de I
trabajo en su escritorio, entre 10 y 100 veces ms poderosa que las actuales. Pro
porcionar las siguientes caractersticas:
Redes para uso del proyecto
Manejo de metodologa de ingeniera de software a la medida
Control de documentos
Facilidades para administracin de proyectos
Estadsticas de productividad y mtrica de software
Revisin inicial para evitar complejidad excesiva
Simulacin y pruebas automatizadas
Pruebas de correccin auxiliadas por computadora
Generacin de cdigo
Apoyo con inteligencia artificial para cdigo reutiiizable
www.FreeLibros.org
Pizarrones del equipo del proyecto
.3,1
Redes para uso del proyecto
Las herramientas automatizadas son tiles incluso en proyectos pequeos de

uia sola persona; tambin lo es la ingeniera de software. Pero un proyecto pequepo tiene la ventaja de que el trabajo se puede hacer una y otra vez hasta que est
bien, de modo que el uso de modelos y herramientas formales no tiene mucho senti
do de urgencia.
Las herramientas automatizadas sern de mayor utilidad en un proyecto de
desarrollo de software grande, multimillonario, multianual y multipersonal. En pro
yectos de este tipo hay varios analistas (a veces una docena o ms), varios usuarios
finales (a menudo en distintos puntos geogrficos), y varios diseadores y programadores. En este tipo de ambiente, es importante no slo que el trabajo de cada ana
lista sea internamente consistente, sino tambin que el trabajo del analista A y el
analista B sean consistentes entre s.
Esto significa que debe existir un nivel de inteligencia por encima dei dei ana
lista o programador individual. Aunque existen muchas maneras de implantar esto,
una de las arquitecturas ms atractivas se muestra en la figura A.3. Muchos provee
dores de herramientas automatizadas tratan de proporcionar este tipo de redes, tpi
camente en minicomputadoras Wang o VAX.
La minicomputadora del proyecto debe tener suficiente capacidad de almace
namiento y poder de procesamiento como para realizar revisiones de consistencia
en todo el proyecto. Debe tambin tener suficiente poder para realizar funciones adi
cionales. Debe permitir a los programadores conectarse directamente a la computa
dora principal del sistema, para hacer pruebas y otros menesteres normales. Y es el
lugar obvio para la inteligencia asociada con muchas de las funciones descritas a
continuacin.
Aadir una minicomputadora as, con ei almacenamiento asociado en disco, ca
nales de comunicacin, etc., obviamente incrementa el costo del apoyo automatizado.
En dlares estadounidenses de 1985, el costo de una estacin independiente apro
piadamente configurada era de entre $8,000 y $15,000; con el hardware y software
para la minicomputadora del proyecto, el precio fcilmente se doblara. Vale la pena
pagarlo, pero probablemente no se pueda obtener del presupuesto de un solo ao pa
ra el personal de administracin de sistemas de informacin de una empresa grande;
costara millones de dlares para una organizacin con algunos cientos de personas
encargadas de desarrollo de sistemas. Debe reconocerse como parte de una inver
sin principal en el esfuerzo por lograr mayor productividad y profesionalismo.
A.3,2
Manejo de m etodologa de ingeniera de softw are a la medida
Las herramientas automatizadas normalmente manejan algunas formas espe

cficas de notacin y procedimientos de ingeniera de software. Los diagramas de
www.FreeLibros.org
este apndice, por ejemplo, adems de los anteriores en todo el libro, usan la notacin descrita en varios libros de texto de la editorial YOURDON. Pero, sorpresa, ya
rios productos CASE tambin manejan otras metodologas populares de ingeniera
de software, tales como la notacin de Gane/Sarson y la de Warnier/Orr. Varias
otras herramientas automatizadas de apoyo manejan ms de un tipo de metodologa
de ingeniera de software.
Estaciones de trabajo remotas

Figura A.3: H erram ienta autom atizada del analista/diseador para todo el
proyecto
Pero existe algo mucho ms importante que tan slo manejar la metodologa
dei proveedor A o B: la herramienta automatizada debe permitir una metodologa a
la medida. Las organizaciones de administracin de sistemas de informacin suelen
encontrar que ninguna de las metodologas populares de ingeniera de software pro
porciona una notacin adecuada o un conjunto adecuado de regias para el tipo pe
c uliar de sistem a que est desarrollan do. Tal vez, por ejem plo, desee usar
tringulos para recalcar entradas y salidas de marcianos y de exploradores del capi
tn Kirk de Viaje a las Estrellas (la mayora no nos tenemos que preocupar por ta
les entradas y salidas, por lo que jams se nos ha ocurrido pedir que haya tringulos
en nuestra herramienta automatizada). Y tal vez se haya decidido pasar el dictamen
de que ningn diagrama de flujo de datos tenga ms de 13 burbujas; otra organiza
cin puede decidir que ningn sistema tenga ms de tres niveles de diagramas de
flujo de datos, y as.
Claramente, este tipo de hechura a la medida debe permitirse, pues de lo con
trario la herramienta gradualmente se dejar de usar cuando los encargados de de
sarrollar el sistema encuentren que no satisface sus necesidades. Muchas de las
www.FreeLibros.org
herramientas automatizadas actuales no tienen esta caracterstica; casi todos los

II productos de segunda generacin tendrn esto, o desaparecern del mercado.
^ 3.3
C ontrol de docum entos
Como hemos visto, el anlisis estructurado se apoya en varios modelos gr

ficos formales, adems de material textual como diccionarios de datos y especifi
c a c i o n e s de proceso.
Las estaciones de tra ba jo autom atizan el desarrollo y
mantenimiento de estos documentos; sin embargo, permiten algo ms: ei control de
l0S mismos. Aunque esto parece fcil, es un concepto radical para muchas organi
zaciones de administracin de sistemas de informacin. Muchas slo han empezado
recientemente a controlar el cdigo fuente que se produce en ia fase de programa1 cin del proyecto.
Pero as como resulta desastroso permitir al programador hacer cambios pea un programa operacional a la media noche, tambin lo es de igual mane
ra permitirle hacrselos a un DFD o un EFtD a la mitad de la fase de anlisis de un
proyecto, a menos que dicho cambio haya sido autorizado y aprobado.
queitos
Para lograr que esto funcione debemos distinguir entre las bibliotecas privadas
que cada miembro del proyecto mantiene en su estacin de trabajo independiente, y
el archivo del proyecto que se mantiene en la minicomputadora del proyecto entero
que se muestra en la figura A.3. Es ei archivo del proyecto ei que se desea contro
lar. Cuando un analista o diseador indica que termin el modelo (o diagrama) y
que est listo para incorporarlo al archivo del proyecto, deja de ser el dueo unilate
ral del material.
A.3.4
A dm inistraci n del proyecto
E! control de documentos es un aspecto de otra caracterstica que la minicom

putadora del proyecto puede proporcionar; la administracin del proyecto. Ei admi
nistrador puede tener su propia estacin de trabajo y usar las funciones de la
minicomputadora para coordinar y supervisar las actividades de todo el equipo. Con
un apoyo de software apropiado, puede saber cuando el analista A termina el DFD
con el que estaba trabajando; puede darle a la minicomputadora instrucciones de
mandar un DFD al analista B para su revisin y comentarios; luego, puede asignar
ms trabajo al analista A. Puede usar todo este material para actualizar el calenda
rio y presupuesto del proyecto; y dado que la minicomputadora mantiene su propio
registro neutral de cundo comenz y cundo termin el DFD, es probable que ob
tenga datos ms precisos y sin prejuicios para las actividades de programacin del
proyecto. El administrador puede usar la funcin de correo electrnico que segura
mente proporciona la arquitectura de la figura A .3 para comunicarse con su perso
nal. Puede ser difcil proporcionar una estimacin clara del valor de dicha funcin,
pero ia mayora de los equipos de proyectos encontrarn que ya no pueden vivir sin
ella una vez que la tienen.
www.FreeLibros.org
A.3.5 E stadsticas de p ro d u ctivid a d y m trica de softw are

Como se mencion anteriormente, la minicomputadora dei proyecto pyecj
mantener su propio registro de ia fecha de comienzo y conclusin de cada parte de*
trabajo (el desarrollo de un DFD, su revisin, su auditora, etc.) que realiza el analis'
ta, el diseador o el programador. De esta manera pueden generarse medidas efe
productividad de manera casi invisible, lo cual con suerte disminuir el impacto cfe|
principio de incertidumbre de Heisenberg.7 Compare esto con si proyecto tpico ds
desarrollo de software actual, donde ios analistas y programadores pasan como una
hora a la semana registrando informacin acerca de cmo pasan su tiempo. Existe
una tendencia apenas disfrazada de llenar una forma para hacerla ver como ei jefe
quiere que se vea (aunque ios programadores sean tramposos y charlatanes, no es
tn fuera de contacto con ia realidad). Adems, si el proceso de registro lleva una
hora, entonces afecta ai trabajo mismo; esto es algo parecido a lo que un fsico lla
ma principio de incertidumbre de Heisenberg.
Casi cualquier otra mtrica de software que el equipo del proyecto decida pue
de llevarse con ayuda de la mincomputadora dei proyecto. As, el equipo puede de
cidir que es importante saber cuantos DFD se requieren para ei sistema, cuntos
elementos de datos, cuntas primitivas funcionales o cuntas revisiones se ocupa
ron antes de que finalmente fuera aceptado por el usuario. Esta informacin puede
ser til para proyectos futuros y para estimaciones de tamao y costo del proyecto.
A.3,6
R evisin in icia l para evitar com plejidad excesiva
Una de las mtricas ms tiles a la larga es la de la complejidad. Existen mo

delos matemticos de complejidad de programas que pueden usarse para predecir la
dificultad de probar y mantener un programa de computadora.8 Si los modelos ma
temticos se aplican automticamente a cada mdulo del programa en el sistema
que se est desarrollando, entonces los desarrolladores y el administrador del pro
yecto tendrn una rpida advertencia sobre las porciones potencialmente peligrosas
del sistema y as podrn explorar otros diseos.
A.3.7
S im ulacin y pruebas auxiliadas po r com putadora
Como se mencion anteriormente en este apndice, existen paquetes de prue

ba y animadores auxiliados por computadora que ofrecen al programador una repre7 A u n q u e e i p rin c ip io d e in c e rtid u m b re d e H e is e n b e rg u s u a lm e n te se a s o c ia co n e l c a m p o d e la fsi
c a c u n tic a , se a p lic a a q u ta m b i n : el p rin c ip io a firm a , s im p le m e n te , q u e e x is te n v a ria b le s que no
se p u e d e n m e d ir sin c a m b ia rla s . S un tra b a ja d o r tie n e q u e p a s a r el 10 p o r c ie n to d e su tie m p o mi
d ie n d o su p ro p io tra b a jo , e n to n c e s su p ro d u c tiv id a d d is m in u y e en p o r lo m e n o s un 10 p o r ciento, y
el h e c h o d e q u e e s c o n s c ie n te d e q u e se le e s t m id ie n d o (p u e s l m is m o lo e s t h a c ie n d o ) es pro
b a b le q u e a fe c te su c o m p o rta m ie n to .
www.FreeLibros.org
8 C o m o s e d is c u ti e n el C a p tu lo 2 3 , u n o d e los m o d e lo s m s p o p u la re s e s la m e d id a ciclom tica
d e c o m p le jid a d d e M c C a b e . P a ra m s a c e rc a d e s te y o tro s m o d e lo s , v e a la o b ra C ontrolling Soft
ware Projects d e T o m D e M a rc o (N u e v a Y o rk : Y O U R D O N P re s s , 19 8 2 ).
gentacin grfica de la ejecucin de su programa. No existe razn por la cual esta

inteligencia no pueda incorporarse a ia estacin de trabajo remota o a la minicompu
tadora del proyecto.
De hecho, casi todos los programas convencionales de apoyo que se mencionan ai principio de este apndice podran incorporarse a una herramienta automati
zada de trabajo. Al volverse ms poderosas las estaciones personales de trabajo,
deber ser posible que se produzca cdigo luego del proceso de modelado (si es
qUe no se puede generar automticamente), adems de compilar y probar. El pro
gramador tendr que mandar el programa a la mmcomputadora slo cuando est
terminado.
ft.3.8
Pruebas de correccin auxiliadas p or com putadora
Como se discuti en el Captulo 23, el campo de las pruebas de correccin au

xiliadas por computadora todavia no se ha desarrollado al grado de que el progra
mador y analista promedio lo puedan usar, pero existe un amplio espectro entre la
revisin informal de consistencia y las pruebas formales de correccin. Con las he
rramientas de apoyo automatizadas, gradualmente encontraremos que nos alejamos
cada vez ms de la revisin informal de consistencia para acercarnos a pruebas
completas y formales de correccin. Para lograr esto se ocupar un mayor nivel de
preparacin por parte del programador que el que se puede esperar hoy. Por tanto
no se debe esperar esta caracterstica en la mayora de las estaciones de trabajo
orientadas a negocios sino hasta dentro de otros 5 aos.
A.3.9
Generacin de cdigo
Una meta importante de muchos fabricantes de herramientas es la generacin

automtica de cdigo de COBOL o FORTRAN. As, nadie tendra que ver el cdigo,
como actualmente nadie ve los 1 y 0 binarios que son los que de hecho entiende la
computadora. En este contexto se estara tratando con especificaciones computables, desarrolladas por el usuario final y el analista.
Tal vez nunca se logre esto para todos los sistemas, ni se pueda insistir en el
nivel necesario de especificacin rigurosa y formal de iodos los usuarios finales. Pe
ro al recalcar cada vez ms as actividades de diseo y anlisis, fcilmente se puede
reducir la programacin a una simple tarea de oficinista. Aunque no se automatice
completamente, la pueden realizar oficinistas menores, en lugar de graduados de
Ciencias de la Computacin que cobran $40,000 dlares estadounidenses anuales.
A.3,10
Apoyo con inteligen cia a rtific ia l para c d ig o reutilizable
El concepto de cdigo reusable es an ms llamativo que el concepto de ge

neracin de cdigo automatizado. En la gran mayora de los proyectos (tanto orien
tados a negocios como a ciencia e ingeniera) la mayor parte del software que se
pretende desarrollar ya se ha hecho antes. El sistema nuevo de este ao es, de
www.FreeLibros.org
hecho, casi idntico a! del ao pasado, y no muy diferente al dei anterior. La mayo
ra de las primitivas funcionales de nivel inferior ya se han programado antes cien
tos de veces y existen gratis como rutinas de biblioteca proporcionadas como parte
del sistema operativo. Lo nico que distingue a! sistema de este ao como nico es
la combinacin particular de estas funciones previamente realizadas, o algn par
metro que se da al programa cuando se ejecuta. Por ejemplo, el sistema de nmi
na de este ao es bsicam ente el mismo que el del anterior, pero la tasa cje
impuestos cambi.
Esto sugiere que el analista (y an ms el diseador dei sistema) no debiera
ver cada proyecto como un gran experimento de exploracin cientfica, sino ms
bien como una cacera para ver cules mdulos ya existentes de biblioteca, subrutinas y programas se pueden conectar para satisfacer las necesidades del usuario.
Aqu es donde la inteligencia artificial sera til. Al correlacionar las caracters
ticas de una funcin identificada por el analista (por ejemplo, nmero de entradas, ti
po de salidas, especificaciones de transformacin o reglas que describen cmo se
convierten las entradas en salidas, etc.) con una biblioteca existente de funciones,
un sistema experto puede sugerir al diseador candidatos para implantar el sistema,
Y pudiera interactuar con el analista para mostrar que al hacerle algn pequeo
cambio a los requerimientos (es decir, al sacrificar un poco los requerimientos origi
nales dei usuario) se puede usar una funcin ya existente de la biblioteca.
A.3.11
Pizarrones del e q u ipo del proyecto
Algunos de los principales investigadores de los Estados Unidos (por ejemplo,

en laboratorios de investigacin tales como MCG en Austin, Texas) sienten que las
verdaderas mejoras a la productividad en ios aos 90 surgirn de los efectos sinergsticos de un equipo de proyecto, ms que de un individuo; esto se debe a que a
los grandes sistemas no los construyen individuos sino grupos de grupos de perso
nas (a menudo de compaas distintas). Muchos de ios conceptos descritos hasta
ahora se ocupan de ia mejora en la productividad de un trabajador individual, pero
la inteligencia de la minicomputadora del proyecto puede usarse para proporcionar
una visin global conveniente de todo un sistema a medida que crece y toma forma.
Este concepto de un pizarrn de proyecto se est implantando en MCC como
parte del proyecto Leonardo; debe proporcionar resultados fascinantes para fines de
la dcada. El grupo de investigacin est experimentando con la nocin de un piza
rrn comunal en ia forma de una pantalla del tamao de una pared. Tambin estn
investigando la idea de usar el olfato y el odo, adems del color, para aadir nuevas
dimensiones a los modelos grficos descritos en este libro. Si tiene xito, el proyecto
Leonardo ser la herramienta automatizada de tercera o cuarta generacin para ia
gente que desarrolle software a mediados de los aos 90.
www.FreeLibros.org
.4
CONCLUSION
Mi inclinacin y emocin por este aspecto del desarrollo de software es obvia;

no la puedo ocultar. No me disculpo por eilo. Verdaderamente siento que represen
ta ei nico mecanismo para ayudamos a estar ai da y alcanzar a las hordas de pro
gramadores en varios pases del mundo que acabaran con la mgica industria que
se ha creado en los ltimos 25 aos.
Algunos dirn que esta tecnologa es demasiado cara, que ningn programa
dor vale una inversin de 25,000 dlares estadounidenses. Tai vez as sea, pero da
do que ei hardware se est volviendo cada vez ms barato, los $25,000 de hoy
sern $10,000 maana, y $5,000 el ao prximo. Me parece bastante irnico que un
pas que invierte de $50,000 a $75,000 en equipo para sus campesinos y obreros no
quiera invertir unos cuantos miles de dlares para sus trabajadores de a informa
cin. Esta renuente aceptacin de la necesidad de invertir es el ltimo suspiro de la
Revolucin Industrial, es decir, ei ltimo suspiro de lo que Alvin Toffler llama la Se
gunda Ola.
Admito que una profesin de software dominada por estaciones de trabajo au
tomatizadas s presenta algunas preguntas serias: Vuelve obsoletos a los progra
madores? Destruir nuestra creatividad? Podemos darnos el lujo del gasto? Y
acaso garantiza que mejoraremos dramticamente nuestra capacidad de producir
software de alta calidad ms productivamente?
No existe nada mgico en las herramientas de software automatizadas; cual
quiera que tenga un poco de sentido comn puede responder a estas preguntas.
Las herramientas automatizadas seguramente no volvern obsoletos a los progra
madores a corto plazo ni a los de mantenimiento por 20 aos o ms. Mientras tanto,
ayudar a desenfatizar la programacin, lo cual continuar con la tendencia existen
te desde que se invent el primer lenguaje de programacin a fines de ios aos 50.
No amenaza ei trabajo de ningn programador; tenga en mente que hay un atraso
de siete aos de trabajo en el desarrollo de sistemas en la mayora de las organiza
ciones.
Acaso una estacin de trabajo automatizada destruir la creatividad de los
que desarrollan software? Para nada. Acaso los sistemas CAD/CAM (diseo auxilia
do por computadora) destruyen la capacidad de ia persona para disear un autom
vil o un aeroplano estticamente bello? No. Cien veces, no. Todo lo contrario. La
disponibilidad de herramientas de apoyo automatizado ayuda al programador y al
analista a concentrarse en la parte verdaderamente creativa de su trabajo, y pasar
menos tiempo preocupndose por las partes mundanas. Como la herramienta auto
matizada permite al analista pasar ms tiempo inventando ms modelos de los re
querimientos del usuario, lo vuelve ms creativo.
www.FreeLibros.org
Podemos darnos el lujo de pagar el costo de estas estaciones de trabajo? La
respuesta es simplemente: no podemos darnos el lujo de no usarlas. Con ellas se
tiene oportunidad de salvar ia industria de software de EDA; sin ellas, no hay espe
ranza. Para aquellos que quieren algo ms prctico, tengan en mente que el costo
de una estacin de trabajo compleja, suponiendo que se incluya el apoyo de la mipf.
computadora para todo el proyecto, es de alrededor de 25,000 dlares estadouni,
denses.9 Esto es ms o menos lo mismo que ei sueldo anual, en 1987, de un
programador tpico, con uno o dos aos de experiencia. Si se incluyen los costos
extra (seguros y pensiones), representa alrededor de seis meses del costo dei pro
gramador. Dado que fcilmente se puede justificar la amortizacin del costo d6|
hardware y software asociados durante tres aos, su costo es a grandes rasgos
igual al 15 por ciento del costo anual del programador. En otras palabras, si la pro
ductividad del programador aumenta en un 15 por ciento anual, entonces se paga
solo.
Pero, acaso la herramienta automatizada para el desarrollo de software ga
rantiza mejorar ia productividad en un factor de 10? Cualquiera que pueda plantear
esta pregunta en serio, sin duda an cree en los duendes. Acaso ir a misa todos
los domingos garantiza que se ir ai cielo? La estupidez, ia arrogancia, la pereza y
otras debilidades humanas siempre harn posible fallar a pesar de las mejores he
rramientas y apoyo. No hay manera de evitarlo. Pero si creemos en el poder de los
sistemas de informacin y ei apoyo automatizado para ios negocios y ia sociedad,
debemos creer en i para la profesin que construye sistemas para el resto de ia ra
za humana. No siempre debiera resultar cierto que los hijos del zapatero sean los
ltimos en tener zapatos.
REFERENCIAS
1.
Jack Crawford, conferencia en Wang Computer Company, 6 de mayo de 1985.
2.
James Martin, An Inform ation Systems Manifest. Engiewood Ciiffs, N.J.;

3.
Paul Ward y Steve Mellor, Structured Systems Development for Real-Time

Systems, volmenes 1-3. Nueva York: YOURDON Press, 1985.
4.
Meilir Page-Jones, The Practica! Guide to Structured Systems Design, 2- edi

cin, Nueva York: YOURDON Press, 1988.
5.

9 Se pueden co n se gu ir program as sen cillo s de dibujo por m enos de 100 dlares estadounidenses,
e incluso algunos m s e laborados a un co sto de s lo cie n to s de dlares. La e stacin de trabajo
m s eco n m ica , con las ca ra cte rstica s d e scrita s en la seccin A .2, co sta ba alrededor de $895 en
1987; estos p recios p ro bablem ente dism inuyan gradualm ente a lo largo de los sig u ie n te s aos. In
clu so una estacin de trab a jo cara s lo costaba alred e d o r de $8,000 en 1987.
www.FreeLibros.org
g_
Paul Ward, Systems Developm ent W ithout Pain. Nueva York: YOURDON
Press, 1984.
7.
Brian Dickinson, Developing Structured Systems. Nueva York: YOURDON

Press, 1980.
g,
Edward Yourdon, Managing ihe Systems Life Cycie, 2 edicin, Nueva York:
g,
Edward Yourdon y Larry Constantine, Structured Design, Englewood Cliffs,

N.J.: Prentice-Hall, 1979.
10.
David King, Current Practices in Software Engineerng. Nueva York: YOUR

DON Press, 1983.
11.
Tom DeMarco, Structured Analysis and Systems Specification. Englewood

Cliffs, N.J.:Prentice-Hall, 1979.
12.
Tom DeMarco, Concisa Notes on Software Engineerng. Nueva York: YOUR

DON Press, 1979.
13.
Chris Gane y Trish Sarson, Structured Systems Analysis and Design. Nueva
York: Improved Systems Technofogies, 1977.
14.
Ken Orr, Structured Systems Development. Nueva York: YOURDON Press,

1977.
www.FreeLibros.org
APENDICE
MACHON
B.1
INTRODUCCION
G o m o analista de sistemas, probablemente tendr que producir varias esti

maciones para el proyecto. De hecho, tal vez sea el nico responsable de producir
las en ocasiones; en otros casos, el administrador dei proyecto puede pedirle que fe
desarrolle las estimaciones.
Qu tipo de cosas necesitan estimarse en un proyecto de desarroilo de siste
mas? Esto vara de un proyecto a otro pero tpicamente lo principa! que se requiere
estimar es:
Recursos humanos. Cuntos programadores, analistas, diseadores de

bases de datos, expertos en telecomunicaciones, representantes de los
usuarios y otros tipos de personas se necesitan para el proyecto?
Tiempo. Cunto tardar el proyecto? Cunto tiempo se puede esperar

invertir en cada fase tpica dei proyecto (por ejemplo, la fase de anlisis,
la de diseo, ia de programacin, la de prueba, etc.)?
Programacin de personal. Adems de saber cuntas personas requiere

el proyecto, necesitamos saber cundo se requerirn. Si el proyecto re
quiere diez programadores, se necesitarn iodos al mismo tiempo?
Presupuesto. Cunto costar desarrollar el sistema? El costo principal

ser probablemente el de ios sueldos del personal de desarroilo, y esto
usualmente se puede calcular directamente una vez que se conocen los
recursos humanos y la programacin del personal. Desde luego, hay
otros costos asociados con un proyecto; se dan con detalle en el apndi
ce C.
Tenga en mente que generalmente tendr que hacer las estimaciones ms de

una vez. Suele hacerse un conjunto de estimaciones en las primeras etapas de un
www.FreeLibros.org
534
REGLAS DE ESTIMACION 535
proyecto (por ejemplo, durante el estudio de factibilidad), pero pueden requerirse

juchas veces, a medida que los usuarios y la administracin exploran las diferentes
posibilidades de combinaciones. Un ejemplo obvio de esto es el posible sacrificio de
funcionalidad a cambio de tiempo y viceversa (por ejemplo, el administrador del pro
yecto puede decir al usuario: Estoy prcticamente seguro de que podemos entre
garle el sistema para el 1a de enero si no metemos las funciones X, Y y Z .); otro
ejemplo es el de la relacin inversa entre personas y tiempo (por ejemplo, el usuario
puede decirle al administrador del proyecto, Si tuviera tres programadores ms,
podra terminar el proyecto a tiempo?). Podra tomar varias iteraciones que el
equipo del proyecto, la administracin y la comunidad usuaria lleguen a un acuerdo
ace ptab le .1
8.2
ESTIMACION DE LOS PELIGROS
Tenemos una gran cantidad de experiencia comn en el rea de ia estimacin;

piense tan slo en todas las situaciones en donde surgen preguntas del tipo de:
Cunto tiempo crees que tardemos en manejar hasta la casa de tu ta? Todos es
tamos familiarizados intuitivamente con el concepto de una estimacin optimista y
una pesimista. Pero la estimacin de un proyecto de desarrollo de sistemas es algo
diferente, pues 1) el enfoque dei trabajo es ms amplio y un tanto ms complejo y,
2) las consecuencias de un error en as estimaciones usualmente son ms severas
que las que surgen de llegar media hora tarde a la casa de la ta.2 Existen varios
problemas comunes de los que debe estar consciente antes de empezar a calcular
presupuestos, tiempos y requerimientos de recursos:
La diferencia entre estimar y negociar
La gran variedad de capacidad de los tcnicos
El peligro de estimar su propio trabajo
La falta de una base de datos de estimacin
La insistencia de la administracin en tener estimaciones detalladas y

prematuras.
La dificultad, comn a toda la industria, de medir la unidad de trabajo.
Estimaciones basadas en supuestos de tiempo extra sin sueldo
1 Tenga en c u e n ta ta m b i n q u e las e s tim a c io n e s c ie rta m e n te s e te n d r n q u e re v is a r d u ra n te el p ro

yecto al ir c a m b ia n d o las c irc u n s ta n c ia s . Lo s fa c to re s e x te rn o s (c o n d ic io n e s d e n e g o c io s , n u e v o s
com petidores, fu s io n e s , e tc .) p u e d e n o c a s io n a r q u e el u s u a rio c a m b ie d e o p in i n re s p e c to a la fu n
cionalidad re q u e rid a , io s g a s to s o la fe c h a de e n tre g a e s tip u la d a . Y ta c to re s in te rn o s (ta le s c o m o
cambios d e p e rs o n a l, d ific u lta d e s in e s p e ra d a s d e im p la n ta c i n , e tc .) ta m b i n p u e d e n o c a s io n a r el
cambio de p re s u p u e s to s y tie m p o s , u s u a im e n te d e m a n e ra d ra m tic a .
www.FreeLibros.org
2 Algunas ta s p u d ie ra n e s ta r v io le n ta m e n te en d e s a c u e rd o c o n e s to .
536
REGLAS DE ESTIMACION
Dependiendo de su puesto dentro del proyecto y de su influencia con ia admi

nistracin y los usuarios, puede tener la posibilidad de prevenir que algunos de estos
problemas se vuelvan ms serios. Pero incluso si es un analista muy abajo en el es
calafn, debe estar consciente de los problemas de estimacin, pues a fin de cuen
tas pueden determinar el xito o fracaso de su proyecto. Discutiremos cada uno de
estos problemas con ms detalle a continuacin.
B.2.1
La diferencia entre estim ar y negociar
A menudo existe una buena cantidad de negociacin al principio de un proyecto (y muchas veces a lo largo de toda la fase de su desarrollo). Esto es normal
pues la comunidad usuaria entiende poco acerca de la cantidad de trabajo que un
sistema de informacin complejo involucra, y por ello pedirn que les bajen la luna,
es decir, funcionalidad enorme en una cantidad absurdamente pequea de tiempo, y
a cambio de muy poco dinero. Mientras tanto, el administrador se enfrenta al proble
ma de personal y presupuesto limitado; por tanto, necesita trabajar con los usuarios
para ayudarles a ver ias posibles combinaciones.
Pero este proceso de negociacin, tan necesario y tan comn en proyectos de
desarrollo de sistemas, no debe confundirse con la estimacin. Lo que debe evitar
se son este tipo de conversaciones entre usuario y analista (o quien haga la estima
cin);
Usuario: Bien, cunto va tardar la construccin del sistema XYZ?
Analista: Bueno, parece que lo terminaremos para el 1 de abril.
Usuario: Eso no basta. Lo ocupamos para el 1a de enero .
sin disposicin de discutir otras combinaciones de funcionalidad o de recursos.3 Es
to a veces va seguido de llamados del usuario sobre ei sentido del deber, patriotis
mo, etc., del equipo dei proyecto, lo cual se discute como problema aparte en la
seccin B.1.8 .
En algunos casos, esta situacin simplemente refleja una falta de comprensin
por parte del usuario, que se puede corregir explicndole cuidadosamente las activi
dades involucradas en el desarrollo de un sistema. En otros casos, sin embargo, re
fleja el enfoque global del usuario, su paradigma de negocios, para tratar con
personas y organizaciones que le proporcionan productos y servicios. Para el usua-
3 Existe otro com prom iso, pero casi nadie habla de l e xplcitam ente: la calidad. M uchos adminis
tradores de proyecto tratan de lo g ra r m ilagros e n tregando el m aterial con la fu ncionalidad requerida
dentro dei lm ite de tiem po im puesto por el usuario y con los m enos que ptim os recursos existen
tes; pero el resultado inevitable ser un siste m a con m s errores, y que ser m enos mantenible de
lo que hubiera sido el caso de otra m anera.
www.FreeLibros.org
fio tpico, como se ver, la organizacin interna de procesamiento de datos no difiere

ûcho del vendedor externo; la negociacin, con el intento de recortar el precio o el
1 tl9rnpo de entrega en algunos meses, es algo muy natural. Y es algo razonable (des- jj0 este punto de vista) si la persona u organizacin que proporciona el servicio tiene
; ur) margen de ganancia que se puede recortar mediante buenas negociaciones.
Incluso en el caso de una organizacin de procesamiento de datos interna, la
negociacin (sin aceptar sacrificios en funcionalidad, recursos, presupuesto o tiem
po) puede ser razonable si las estimaciones incluyen un margen de error (conocido
tambin como factor de contingencia o de amortiguamiento) que el usuario considere
irrazonablemente grande. Pero si proporcion estimaciones cuidadosas y realistas,
y el usuario le regatea hasta reducirle el personal, el presupuesto y el tiempo, enton
ces su proyecto entra al rea de poltica pesada, para la cual las tcnicas y herra
mientas que se discuten en este libro probablemente no le ayuden mucho. Puede
ser que haya llegado ia hora de actualizar su currculum.
8.2.2
La gran variedad de capacidad de los tcn icos
Es comn estimar el trabajo a realizarse basndose en la capacidad promedio

por ejemplo, el programador o analista promedio, capaz de escribir 15 renglones de
cdigo o de dibujar cuatro burbujas de un DFD en un da promedio). Es importante
tener en mente que estudios realizados en el transcurso de los ltimos 20 aos han
mostrado una gran diferencia entre profesionales mediocres y aquellos con talento
en este campo.4 Si su proyecto tiene un grupo de superprogramadores, puede so
breestimar drsticamente la cantidad de tiempo y dinero necesarios para terminarlo.
De mayor preocupacin an es el hecho de que un equipo de gente mediocre puede
hacer que el proyecto salga del tiempo y del presupuesto programados por un gran
margen de diferencia.
Un problema importante en esta rea es que ei rendimiento mismo de la gente
con experiencia no necesariamente se correlaciona del todo con ia mayora de los
exmenes de aptitud. Por ello, debe basar sus estimaciones en la reputacin de ca
da persona, o su experiencia laboral previa, o bien debe suponer simplemente que
todos son de tipo promedio. Dado que la mayora de las organizaciones no guardan
registros cuidadosos y detallados sobre la productividad de cada miembro de un
equipo de desarrollo de sistemas, ser muy difcil obtener evidencia confiable. Lo
que le queda es hacer el mejor juicio posible y luego modificar las estimaciones, co
mo vaya siendo necesario, durante el transcurso del proyecto.
4 Uno de ios p rim eros indicadores de esto fue un trab a jo titu la d o: Exploratory Experim ental Studies
Concerning O nline and O ffline P rogram m ing Perform ance", de H. Sackm an, W .J. Erickson y E. E.
Grant, en el nm ero de enero de 1968 de C om m unications o f the ACM . Su estudio m ostr una va
cacin de 26:1 entre los m ejores y peores program adores, a los cu a le s se dio ia m ism a ta re a de
programacin. Esta variacin entre buenos y m alos program adores se ha ve rificad o m uchas veces
toante ios ltim os 20 aos.
www.FreeLibros.org
538
B.2.3
El p eligro de estim ar su p ro p io trabajo
Uno de los peores errores que puede cometer es e s t i m a r su propio t r a b a j o ;

casi tan malo como usar ia estimacin de una sola persona, puesto que el j u i c i o
esa persona p u e d e v e r s e afectado por varios factores.
8s
de
Si hace la estimacin de su propio trabajo, es probable que caiga presa de uno

o ms de los siguientes mitos:
Soy mejor que la mayora de los que me rodean aqu, y estoy seguro de
que puedo terminar el proyecto mucho ms rpido. Es muy comn s o
b r e e s t i m a r la capacidad propia. Cuando estima la de otra persona, t i e n d e
a ser conservador; cuando estima la propia, tiende a ser optimista.
S que el jefe ocupa esto rapidsimo, y de verdad lo quiero ayudar.

la mayora de los casos, este es un sentimiento altruista: es muy n a t u r a l
querer ayudar al xito de su jefe. Pero puede nublar su j u i c i o acerca d e l
tiempo requerido para terminar el proyecto. E n el peor de los casos, s e
hacen estimaciones optimistas en un intento de impresionar a su j e f e
(tenga en mente que l est haciendo lo mismo con su jefe, y el de ! ai
suyo, etc.) para lograr un aumento o ascenso. Si sabe lo que hace, y es
c a p a z de aceptar el riesgo, perfecto;5 pero tenga en cuenta que est ju
gando con fuego.
Estoy dispuesto a trabajar duro para concluir esto a tiem po. La dis
posicin de trabajar horas extras es admirable pero tambin es peligrosa,
como se sugiri anteriormente. Adems, tenga en mente que el compro
miso de d e d i c a r muchas horas a menudo se contrae en un momento de
gran emocin al principio dei proyecto; seis meses ms tarde, pudiera no
parecer tan buena idea.
He trabajado antes en sistemas como ste; esto es pan comido. Bueno,

tal vez, si de hecho ha trabajado en un proyecto exactamente igual a s t e
o muy parecido. Sin embargo, a! inicio d e l proyecto existe una tendencia
a ver similitudes superficiales con proyectos anteriores y suponer de ma
nera optimista que se podr terminar an ms rpido. Es probable q u e
encuentre q u e ei nuevo proyecto en realidad es muy diferente cuando vea
los detalles; y es p r o b a b l e q u e olvde todos l o s problemas que t u v o con e!
proyecto anterior.
5 Dios m ira encim a de m hom bro al e sta r escribiendo esto, y dice, No, no est p e rfe cto . Tal vez
est disp u e sto a to m a r el riesgo de no en tre g a r el proyecto en la fe ch a y presupuesto optimistas en
que los est prom etiendo, pero fa lla r probablem ente ponga en peligro m ucho m s que su carrera.
No es tico, profesional, ni in te ie ctua lm e n te honesto hacer estim a cio n e s o p tim ista m e n te irreales
cuando su je fe , los usuarios y toda la organizacin pudieran su frir prdidas co n siderables porque
no pudo e n tre g a r lo que prom eti.
www.FreeLibros.org
Por estos motivos, es muy importante que las estimaciones las haga otra per
sona y no el responsable del trabajo. Tambin es muy deseable que si no se tiene
una base de datos de estimacin (que se discute en la seccin B.1.4) o un paquete
0 estimacin computarizado (que se discute en ia seccin B.4), se obtengan esti
laciones de ms de una persona. Por lo menos obtenga las de tres personas; esto
(jar una estimacin del peor y del mejor de los casos, adems de una intermedia.
g 2.4
La falta de una base de datos de estim acin
Cuando uno se enfrenta con un nuevo proyecto le gustara poder usar estads
ticas de una docena de proyectos similares para producir estimaciones precisas. A l
gunas compaas consultoras y casas de software pueden hacerlo: cuando se les
pide estimar el tiempo y dinero necesarios para, digamos, un sistema de ingreso de
pedidos, pueden decir: Bueno, esto es casi igual a los ltimos 137 sistemas de in
greso de pedidos que hemos construido, as que debe tomar X meses-persona, Y
dlares y Z personas.
Incluso dentro de su propia organizacin, es posible que se hayan desarrolla
do 137 sistemas de ingreso de pedidos durante las ltimas dcadas. Pero esto no
significa necesariamente que ser fcil estimar el presupuesto o el tiempo necesa
rios para el 138; si no se guardaron registros precisos, en todo lo que se puede ba
sar es en chismes y rumores. En una organizacin tpica de proceso de datos, que
acta como organizacin de servicio interno, sin tener que preocuparse sobre cifras
de prdida/ganancia o consideraciones de flujo de efectivo, no existe un buen incen
tivo para guardar registros cuidadosos como stos.
Algunas organizaciones grandes de proceso de datos estn comenzando a
cambiar su actitud y desarrollan bases de datos que pueden usarse para generar es
timaciones ms precisas para proyectos futuros. Algunas compaas consultoras
que se han especializado en esta rea han desarrollado bases de datos de literal
mente miles de proyectos, que se usan para proporcionar parmetros en ios mode
los de estimacin computarizados que se discuten en la seccin B.4.
Mientras tanto, existe una buena probabilidad de que se enfrentar con una
estimacin nica en su gnero. Definitivamente debera buscar otros proyectos s i m i
l a r e s en su organizacin; pero est consciente de que puede estar en una s i t u a c i n
anloga a la del arquitecto a quien se le pregunt cunto tiempo tardara en construir
u n a casa subterrnea en un pantano.
B.2.5
La in siste ncia de la adm inistracin en estim aciones

prem aturas detalladas
Como regla general, es casi imposible producir estimaciones detalladas de

costos, tiempos y requerimientos para un proyecto hasta que se hayan realizado una
gran cantidad de anlisis y diseos detallados de sistemas. Despus de todo, c
mo le puede decir al usuario cunto costar un sistema si no sabe lo que se desea?
www.FreeLibros.org
540
No obstante, existe una gran presin, tanto por parte de los usuarios como por part6
de ia administracin, para producir una estimacin que ambas partes considerar
precisa y detallada, y adems en una etapa muy temprana del proyecto. P or
Simplemente porque necesitan tomar una decisin de proceder o no a la inversin
de tiempo, dinero y recursos humanos para construir el sistema.
Esta exigencia de una pronta estimacin es fcilmente entendile; lo nico qu@
no es realista es suponer que una estimacin temprana puede ser detallada y prsc,
sa. Resulta ms apropiado dar a la administracin una serie de estimaciones a lo
largo de todo el proyecto, cada cual ms precisa y detallada que la anterior. As, s
el equipo est desarrollando un sistema para una aplicacin con la que estn bas
tante familiarizados pueden proporcionar, por ejemplo, la siguiente serie de estima
ciones:
Al final de la encuesta o estudio de factibilidad: una estimacin que puede

variar en ms/menos un 50 por ciento. Es decir, ei equipo dei proyecto
puede decir a la administracin que ei sistema tardar un ao y costar
$200,000, ms/menos un 50 por ciento. La administracin debiera darse
cuenta con esto de que en realidad pueae tardarse 18 meses y costar
hasta 300,000 dlares estadounidenses.
Al final de la etapa de anlisis: una estimacin que puede variar en

ms/menos un 25 por ciento.
Al final de la fase de diseo: una estimacin revisada que puede variaren

ms/menos un 10 por ciento.
Al final de la fase de programacin (cuando an falta hacer las pruebas):

una estimacin finai que no deber variar en ms/menos un 5 por ciento.
B.2.6
La d ific u lta d , com n a toda la industria, de m edir

la unidad de trabajo.
Muchas industrias tienen formas estndar de medir la cantidad de trabajo de

un proyecto. Quien construye una casa, por ejemplo, puede medir !a unidad de tra
bajo en trminos del nmero de ladrillos a ser colocados, o del nmero de habitacio
nes a construir. Pero en el rea del desarrollo de sistemas no existe acuerdo sobre
la forma de medir la unidad de trabajo a realizar.
E! mtodo ms comn es medir el nmero de instrucciones, o lneas de cdi
go, que se debern escribir. As. en algunos proyectos, probablemente se haga re
ferencia a KLOC, que en ingls significa Kiio-ineas de cdigo. Pero existen muchos
problemas con esto:
www.FreeLibros.org
Cuentan como lnea de cdigo los comentarios en un programa de com

putadora?
Contamos slo el cdigo que se le entrega al usuario o tambin el que

se escribe para realizar pruebas, programas de utileras y otras activida
des de apoyo durante el proyecto? (Y, en mayor escala, contamos el
cdigo asociado con proyectos cancelados en un intento de medir la pro
ductividad de la empresa?)
Qu tal si el programador ha escrito ms de una instruccin en la misma

lnea de un listado de programa? Y qu con las instrucciones complejas
que requieren ms de una lnea?
Y, lo ms importante, cmo tratamos el hecho de que algunos programadores usen ms lneas de cdigo que otros para lograr la misma funcin?
Como se vio en la seccin B.1.2, esto puede variar bastante.
Como seala Capers Jones en su obra Programming Productivity [Jones,

1985]), los resultados de productividad reportados se pueden distorsionar en dos r
denes de magnitud usando diferentes formas de medir la unidad de trabajo; tal vez
sta sea la razn por la cual algunos programadores argumenten ser 10 o 100 veces
ms productivos que sus colegas. Debido a estos problemas, algunas organizacio
nes estn empezando a usar puntos de funcin como unidades de trabajo; esto co
rresponde a grandes rasgos a las burbujas atmicas de nivel inferior en un DFD.6
8.2.7
E stim aciones basadas en supo sicion e s de tiem po extra no pagado
Como se mencion anteriormente, los usuarios y los administradores de pro

yecto pueden reaccionar a los conflictos de tiempo sugiriendo, implcita o explcita
mente, que el equipo del proyecto invierta horas extra los fines de semana, se quede
sin vacaciones o por lo menos las posponga. Esto usualmente se ve acompaado
de apelaciones a su lealtad, profesionalismo, dedicacin, devocin, orgullo, honor y
patriotismo.
Le dejo la decisin respecto a si la voluntad de trabajar o no horas extras sea
cuestin de patriotismo. En algunas organizaciones este pudiera ser el caso: todos
los proyectos podran estar organizados de tal forma que slo tengan xito si el equi
po invierte 80 horas semanales de trabajo. Y algunos proyectos (por ejemplo, el
proyecto Apollo de la NASA, que llev al hombre a la luna por primera vez en 1969)
pueden ser tan emocionantes que todo mundo estar ms que contento de apuntar
se para las horas extras requeridas. Y no es algo fuera de lo comn encontrar que el
6 E. trm ino punto de fu n ci n lo in trodujo A.J. A lbrecht para d e scrib ir esto; vase M easuring Ap
plication D eveiopm ent P roductivity", P roceedings o f the J o in t S H A R E /G U ID E A p p lica tio n D evelop
ment S ym posium (C hicago: G U ID E In te rn a tio n al C orp., 1979). T om D eM arco u tiliza el trm ino
explosin de fu n ci n en una m anera m uy sim ilar; para m ayores d e talles vea su libro, C ontroiiing
Software P rojects (Nueva York: YOURDON Press, 1982). Tam bin vase ia obra de C apers Jones,
Programming P ro d u ctivity (N ueva York: Me G raw- Hill, 1986) para una discusin co m p le ta respecto
alas dificultades de m edir ia p roductividad y los m uchos fa cto re s que la afectan.
www.FreeLibros.org
542
proyecto que pareca estar bajo control se atrasa durante el ltimo mes, requiriendo
as unas cuantas semanas de trabajar hasta tarde y los fines de semana.
Pero recuerde que trabajar es como correr: puede correr a toda velocidad
unos 100 metros, pero no a lo largo de todo un maratn de 42 kilmetros. De mane
ra similar, puede trabajar das de 14 horas durante algunas semanas, pero no es
realista, en la mayora de los casos, suponer que puede trabajar das de 14 horas
durante un proyecto de tres aos. Las personas con pareja, hijos, u otros intereses
simplemente se rehusarn a continuar trabajando as despus de unos meses; efe
ser necesario, renunciarn y buscarn otro trabajo. La gente joven y soltera podra
estar ms dispuesta a dedicar al proyecto todo el tiempo que est despierta (al igUa|
que sus sueos), sobre todo si sienten que les ayudar a avanzar en su carrera o en
su conocimiento de la profesin.
Incluso si ios miembros del personal estn dispuestos a trabajar das de 14
horas, no hay garanta de que sean eficientes en su trabajo. Esto sucede sobre todo
si el trabajo en tiempo extra contina por varios meses: las horas extras a menudo
se vuelven no productivas, y usualmente se cometen ms errores cuando la gente
trabaja en un estado de nimo exhausto y presionado.
B.3
REGLAS PARA LA ESTIMACION
Existen cuatro reglas importantes cuando se desarrollan estimaciones de la

cantidad de trabajo a realizarse en un proyecto de desarrollo de sistemas:
1.
Haga las unidades de estimacin o ms pequeas posible.
2.
Hgalas lo ms independientes posible.
3.
Tenga en cuenta el factor de comunicacin.
4.
Distinga entre trabajo nuevo y prestado.
Esto se discute a continuacin.

B.3.1
Haga las unidades de estim acin lo ms pequeas posible
Esto debera ser una sugerencia obvia, pero no se le hace caso tan a menudo
como pudiera pensarse; tambin tiene algunas desventajas, como veremos. Pero,
en general, es mucho mejor estimar el presupuesto y el tiempo requerido para una
unidad de trabajo de una semana que para un milenio-hombre .7 Los proyectos
grandes tienen complejidades grandes; si intenta estimar la cantidad de trabajo, es
7 Un m ile n io -h o m b re son m il aos-hom bre de trabajo. Uso la palabra hom bre deliberadamente,
porque estoy convencido de que las m ujeres son dem asiado inteligentes com o para em plear estas
enorm es unidades. Este t rm in o lo su g iri originalm ente uno de los clientes de mi com paa, que
es una gran com paa e l ctrica de C alifornia.
www.FreeLibros.org
II casi seguro que cometer errores importantes. Es mejor basar sus estimaciones en
cantidades pequeas de trabajo.
j
I
|
j
|
j
Esto implica, desde luego, que ei proyecto global se ha reducido a unidades

pequeas de trabajo, lo cual normalmente suceder como resultado del anlisis, el
diseo y ia programacin estructurados; desafortunadamente, como se discuti en la
seccin B.1.5, puede requerirse una estimacin detallada del presupuesto y los requerimientos de recursos antes de hacer esto. No existe una solucin mgica para
e problema; lo que puede hacer es tratar de convencer a los administradores y
ysuarios de que una estimacin precisa y detallada requiere un esfuerzo inicial para
determinar las unidades de trabajo a realizarse.
Pero, qu tan pequeas deben ser las unidades de trabajo? Algunas organi| zacones las miden por mes; sin embargo, esto parece demasiado grande. En el
| |apso de un mes los proyectos pueden salir seriamente de control. Tal vez sea ms
) razonable medirlo en unidades de una semana; como me dijo una vez un administra
dor de proyecto veterano: Nunca se logra nada til en menos de una semana. Sin
embargo, tai vez la unidad ms comn de trabajo sea un da; esto se ajusta perfec
tamente a la manera en que organizamos nuestra vida de trabajo. Algunas organi
zaciones de hecho o miden en horas; aunque s existen muchas actividades que
toman una hora o menos (por ejemplo, definir un dato en el diccionario de datos),
parece una unidad demasiado microscpica como para trabajar con elia.
B.3.2
Hgalas tan independientes com o sea posible
Un problema que afecta a muchos intentos de estimar es la interaccin, o aco

plamiento, entre una parte dei trabajo y otra. Si un sistema se divide en porciones
con muchas interacciones, entonces la cantidad total de trabajo necesario para de
sarrollar el sistema ser mucho mayor que ia suma lineal de ia cantidad necesaria
para cada porcin. Si se hace algn cambio a la porcin 13, por ejemplo, el cambio
puede causar problemas en la porcin 14, y un cambio a la 14 podra resultar en
cambios a la 15, etc. El efecto de ola ha causado el caos en muchos proyectos.
La solucin es dividir el sistema en porciones pequeas e independientes que
se acoplan de manera holgada con otras. Esto requiere de una labor cuidadosa; se
discuti en el Captulo 20 como la principal justificacin de la agrupacin de burbujas
de bajo nivel en agregados de nivel superior dentro del modelo preliminar de com
portamiento. La nocin de independencia modular tambin es importante durante la
fase de diseo del proyecto; se analiz en el Captulo 22.
8.3,3
Tenga en cuenta el fa cto r de com unicacin
Incluso en un proyecto donde todos los mdulos son independientes entre s,

las personas tienen que comunicarse. Si un individuo va a realizar e! proyecto, en
tonces slo se requiere comunicacin con el usuario (y tal vez algunas discusiones
con la administracin). Pero un proyecto tpico tiene muchos analistas, diseadores,
www.FreeLibros.org
544
especialistas en bases de datos y programadores; o peor an, algunos de ellos pUe

den trabajar en distintas compaas o incluso hablar diferentes idiomas.
Por tanto, las estimaciones deben incluir tiempo para la comunicacin entre to
do el personal del proyecto. Esta comunicacin tomar la forma de reuniones, m6
moranda, conversaciones telefnicas, etc. Tenga tambin en cuenta que la cantidad
de comunicacin aumenta drsticamente al aumentar el tamao del equipo: el nme
ro de vas de comunicacin entre miembros dei equipo aumenta como el factoriald|
nmero de individuos.
B.3.4
D istinga entre trabajo nuevo y prestado
Si el equipo tiene suerte, podr usar el trabajo hecho en proyectos anteriores

Muchas veces esto se logra m ediante mdulos en una biblioteca de software
comn.8 Sin embargo, no debe suponer que los mdulos reusables vienen gratuita
mente; tomar tiempo 1) hallarlos, 2) investigar si realizan la funcin deseada y, g;
aprender io suficiente sobre ellos para poder entender cmo usarlos. Es ms apro
piado estimar que los mdulos prestados tomarn una fraccin (tai vez un 25 por
ciento, o tan poco como el 10 por ciento) del trabajo necesario oara desarrollarlos
desde un principio.
B.4
FORMULAS PARA LA ESTIMACION
Durante ios ltimos 20 aos la industria de desarrollo de sistemas ha invertido

una cantidad enorme de tiempo y esfuerzo en el desarrollo de modelos, o frmulas,
para predecir el tiempo, recursos y costos de un sistema. Algunos de estos modelos
se usan mucho actualmente; tal vez el ms conocido sea el modelo COCOMO, desa
rrollado por Barry Boehm en TRW.9 Pero como seala Tom DeMarco en ConiroSling
Software Projects,
No h a y m odelos de costos transportables. Si espera que alguien
m s d e sa rro lle un co n ju n to de frm ulas que pueda usar para prever
costos en su negocio, probablem ente espere para siem pre. Buena
parte de nuestra in d u stria concluy, al percatarse de esto, que el
m odelado de costos era irrelevante. C reo que esa fue una conclu
sin errnea. S se pueden usar m odelos de costos desarrollados
localm ente para m ejorar la precisin del proceso de prediccin, y si
la m ejora vale ei gasto de de sa rro lla rlo s, entonces el concepto es
viable.
8 Pero tam bin puede ser posible reu tilizar porciones de la parte de diseo de un m odelo de reque
rim ientos del usuario, o incluso porciones de un estudio de fa ctibilidad. Antes esto norm alm ente no
se haca porque ei m odelo de diseo, los m odelos de a n lisis y los estudios de fa ctib ilid a d no se do
cum entaban bien y jam s se m antenan. Ahora, con ia proliferacin de los productos de estacin de
trabajo para anlisis, del tipo que se discute en el apndice A, esto se est volviendo m s prctico.
www.FreeLibros.org
9 Para una discusin de talla da acerca de este m odelo vase la obra de Barry Boehm , Software & g in e e rin g E conom ics (Englew ood Cliffs. N.J.: P rentice-H all, 1981).
Sin embargo, es interesante ver algunas de las frmulas que se utilizan en

otras organizaciones; por lo menos le darn un punto de partida para desarrollar las
propias. Algunas manejan hasta 40 factores o parmetros; pero, como ver, algunas
usan slo uno.
0 ,4.1
Form ulas para estim ar el tiem po de trabajo
Tres frmulas comunes para estimar el esfuerzo (descrito en horas-persona)

se basan en lneas de cdigo. Walston y Flix desarrollaron un modelo en IBM (va
se [Walston y Flix, 1977]), basndose en observaciones de unos sesenta proyec
tos, que se expresa de la siguiente manera:
E = 5.2 * L0-91
donde E se midi en meses-persona, y L en miles de lneas de cdigo.
De manera similar, Baiiey y Basili desarrollaron una frmula basada en 19 pro
yectos; se expresa como
E = 3.4 + 0.72 * D
l J
ms o menos un 25 por ciento.
donde nuevamente se midi el esfuerzo en meses-persona, y DL en miles de

lneas de cdigo entregado; vase [Baiiey y Basil, 1983],
Finalmente, el modelo COCOMO de Barry Boehm tiene una frmula de esfuer
zo para tres tipos distintos de sistemas: sistemas orgnicos, semi-separados, e inte
grados:
E = 2.4 * KDSI1-95
(sistemas orgnicos)
E = 3.0 * KDSI1 12 (sistemas semi-separados)

E = 3.6 * KDSI1-2 (sistemas integrados)
donde KDSI representa kilo instrucciones fuente entregadas; vase [Boehm, 1981]
para ms detalles.
8.4.2
Frm ulas para estim ar tiem po
Una vez desarrollada la estimacin de cantidad de trabajo a realizar, pudiera

pensarse que es fcil estimar la cantidad de tiempo necesario para ei proyecto.
Despus de todo, si tiene un proyecto estimado en 10 meses-persona de trabajo, y
hay 5 personas disponibles, entonces terminar el proyecto debiera tomar dos meses.
Pero qu tal si slo hay disponibles 2? Tomar entonces 5 meses?
En general, io que interesa aqu son las relaciones entre tiempo y personas.
Muchos aos de experiencia dolorosa nos han enseado que esto no es sencillo: do
blar el nmero de personas que trabajan en el proyecto no necesariamente reduce a
la mitad la duracin. De hecho, Fred Brooks, el arquitecto del sistema operativo
www.FreeLibros.org
546
OS/360 original, acu la frase Aadir ms gente a un proyecto de software retrasa

do, slo lo retrasa ms. Existen dos razones para esto: 1) aadir ms personas au
menta la comunicacin necesaria entre miembros del equipo, lo cual reduce |a
productividad y, 2) hay trabajo indivisible en un proyecto que slo puede realizarlo
una persona, por lo que aadir ms no ayudar.
Aunque este es un concepto til, no dice especficamente cuntas personas
necesitar el proyecto ni cunto tiempo tomar. Esta rea tambin ha sido tema de
investigacin; Barry Boehm encontr, por ejemplo, que el tiempo necesario para un
proyecto se puede expresar mediante la siguiente frmula:
T = 2.5 * E0-33
donde E es el esfuerzo medido en meses-persona; vase [Boehm, 1981] para
mayores detalles.
Se han hecho tambin estudios de ia carga de personas ptima para un pro
yecto; las tres frmulas mejor conocidas se basan en el trabajo de Norden, Putnam y
Parr; vase [Norden, 1963], [Putnam y Ftzsimmons, 1979] y [Parr, 1980], Norden
fue el primero en encontrar que la contratacin de personal para un proyecto sigue
una curva como la que se muestra en la figura B.1.
Se conoce la grfica como una distribucin de Rayleigh, basada en la frmula
matemtica de la curva. Putnam proporciona una frmula para describir ei nmero
de personas necesarias para un proyecto en funcin del tiempo:
Personas (t) = 2K * a * t * exp(-at2)
as
O
O
N
<D
*40
0)
a>
T3
m
c
O
O
CL
www.FreeLibros.org
Figura B. 1: Contratacin tpica de personal para su proyecto
onde K es el esfuerzo total del proyecto (expresado en meses-persona), y a es un

factor de aceleracin que establece la pendiente inicial de la curva. (Note que k re
psenla el rea total bajo la curva.)
Parr [Parr, 1980] desarroll otro modelo; aunque la forma global es similar a la
ci la figura B.1, estima una mayor cantidad de personal en las etapas tempranas. Ei
m odelo de Parr se describe mediante la siguiente frmula.
Personas (t) = 1/4 sech^((at + c)/2)
0 . 5 . MODELOS DE ESTIMACION GOMPUTARIZADQS
La dea de utilizar frmulas con exponenciales y secantes hiperblicas proba
blemente no sea muy atractiva; puede estar seguro que muchos analistas veteranos
olvidaron hace mucho lo que es una secante hiperblica y no tienen ia menor idea
de cmo calcular una exponencial. Pero no es necesario recordar ninguna de las
frmulas, ni es necesario realizar a mano los clculos. Existen ahora muchos pa
quetes computarizados de estimacin de proyectos; la mayora son ejecutables en
PC, y usan el modelo COCOMO de Boehm, lo mismo que el modelo de Putnam des
crito anteriormente. Algunos incorporan tambin las grficas PERT y GANTT que se
discutieron en el Captulo 16.
Si est trabajando en algo que no sea un sistema trivial, definitivamente debie
ra Investigar tales paquetes. No slo hacen clculos sino tambin permiten jugar con
simulaciones de tipo qu-sucede-si para observar ei efecto de aadir personas al
proyecto, o de perderlas debido a enfermedad u otras calamidades.
REFERENCIAS
1.
Tom DEMarco, Controlling Software Projects. Nueva York: YOURDON Press,

1982.
2.
Barry Boehm, Software Engneering Economas. Englewood Ciiffs, N.J.: Prenti

ce-Hall, 1981.
3.
Workshop on Quantitative software Models for Reliability, Complexity, and

Cost: An Assessment of the State of the Art. IEEE, catlogo n TH0067-9. Nue
va York: Institute of Electrical and Electronics Engneers, 1979.
4.
Vctor Basili, Tutora! on Model and Metrcs for Software Management and Engineering. Nueva York: IEEE, 1980.
5.
C. E. Walston y C. P. Flix, A Method of Programming Measurement and Estimation, IBM Systems Journal, volumen 16, n 1 (enero de 1977), pp. 54-73.
Reimpreso en Wrtings of the Revolution, Edward Yourdon (editor). Nueva
York: YOURDON Press, 1982, pp. 389-408.
www.FreeLibros.org
548
6.
J.W. Bailey y V.R. Basili, A Meta-Model for Software Development and Re.
source Expenditures , Proceedings of the 5th International Conference on Software Engineering. Nueva York: institute of Electrical and Electronic Engineers
1983.
7.
P.V. Norden, Useful Tools for Project Management, Operations Research in

Research and Development. Nueva York: Wiley, 1963.
8.
Larry Putnam y A. Fitzsimmons, Estimating Software Costs , Datamation, sep

tiembre de 1979, pp. 89-98; octubre de 1979, pp. 171-178, noviembre de 1979
pp. 137-140.
9.
F.N. Parr, An Alternative to the Rayleigh Curve Modei for Software Develop
ment Effort", IEEE Transactions on Software Engineering, volumen SE-6, n
mero 3 (mayo de 1980), pp. 291-296.
10.
T. Capers Jones, Programming Productivity. Nueva York: McGraw-Hill, 1985.
www.FreeLibros.org
APENDICE
GALOU)LS DE
GST@/BENEF1G1
| c.1
INTRODUCCION
E s te apndice se dedica a las tcnicas de clculos de costo/beneficio, que

son una parte importante de todo anlisis de sistemas. El propsito, desde luego, es
| mostrar a los usuarios del nuevo sistema, al Igual que a otros grupos de administra| dores de la organizacin, que los beneficios que se espera obtener con el nuevo sisI tema superan a los costos esperados.
I
|
|
j
|
Como analista subordinado, pudiera ser que no se est involucrado para nada
en este intento, o se le podra dar la tarea de desarrollar un modelo de costo/benefico para una pequea porcin del sistema global. Incluso como analista en jefe a
cargo de todo el proyecto, pudiera ser que no est involucrado en los clculos de
costo/beneficio porque podran estar a cargo, por ejemplo, de un grupo de finanzas
separado.
O tal vez ni siquiera se haga. Muchas organizaciones desarrollan sistemas
simplemente para satisfacer requerimientos obligatorios de gobierno (por ejemplo,
sistemas de reporte para la oficina del trabajo, o nuevos sistemas para manejar la
cambiante legislacin de impuestos). Desde luego, incluso en estos casos, cuando
no existe beneficio derivadle del sistema (ms que el lujo de evitarse multas o poder
permanecer en el negocio), la administracin usualmente desea saber cul ser el
costo del sistema; pero esto se puede realizar como parte de las actividades de esti
macin que se discuten en el apndice B.
Existe otra razn por la cual puede no hacerse el estudio de costo/beneficio:
porque el usuario no lo quiera. As como un consumidor pudiera no tener manera de
justificar el costo de un Cadillac (es decir, lo mismo le hubiera servido un VW peque
o o incluso una bicicleta), muchos usuarios no pueden justificar el costo del nuevo
sistema que han pedido. A veces piden un nuevo sistema por las mismas razones
www.FreeLibros.org
549
550
C A LC U LO S DE COSTO/BENEFICIO
automvil c a r o : e s t a r a l a a l t u r a d e l o s Fulanito.t g sentir q u e e x i s t e l a n e c e s i d a d l e g t i m a d e u n nuevo s is

t e m a , p e r o r e c o n o c e r q u e t o d o s l o s beneficios s o n u n t a n t o i n t a n g i b l e s o e x t r e m a d a
m e n t e d i f c i l e s d e c u a n t i f i c a r ; e n u n m o m e n t o d a d o , p u e d e j u s t i f i c a r l a adquisicin
d e l n u e v o s i s t e m a a t r i b u y n d o l o a u n p r e s e n t i m i e n t o de q u e r e d i t u a r .
que
un
c o n s u m id o r c o m p r a
o tro s c a s o s
e l u s u a r io
C o m o
a n a lis t a ,
no
e s t
c o s t o /b e n e f ic io ; d e s p u s
s in ju s t i f i c a c i n
se
ha
he ch o
un
e s tu d io
que
s n d o se
se
en
r e a lm e n t e
dos
lo s
m s ).
te m a
r e fie r e
lo s
b e n e fic io s
io s c a s o s
muy
es
e n tu s ia s ta
v u e lv e
P e ro
e l p ro y e c to
lo s
s u s t it u id o
lo s
u s u a r io s v a n
m aana
de
que
d e s a r r o lla r
pues es
p r o b a b le
u n o ),
que
d ifu s o s
de
que
su
pesa r de
el
id e a
ser
y, d e
(o
si se
no
i n v e s t i g a r si
a s , s i e s
s u b e s tim a r o n
e s d e m a s ia d o
s u p e r i o r lo
del
razo
exa
q u ie n
p o rq u e
de
de
desea
que t o
ra z o n e s
h a a u t o r i z a d o e l s is
clculo
un
p ro y e c to
p ie n s a
p o r c ie n to s
e l u s u a r io
e n tu s ia s ta
h a c o n v e n c id o b a
p ro y e c to ,
c a rre ra ,
la f a lt a
v o lu b le s :
buena
e l p r o y e c t o e s v u ln e r a b le .
e l u s u a r io
r e a lic e
r a z o n a b le
p r e d ile c t o
de
hoy
de
se
m aana.
t ie n e
una
u n c lc u lo
m i c o n s e jo
e s t
es
c o m p u t a r iz a d o s ,
son
se
e l p ro y e c to
e n c o n tra r q u e
y v ie n e n : e l u s u a r io
p o r o tro
c o n s t r u ir lo
a d m in is t r a d o r
que
e m b a rg o ,
a y u d a r
puede
u s u a r io s
e s tu d io de
m uy
que
to ta lm e n te
p r o y e c to . A s q u e , s i n o e x is te
q u ie r e
del
a l re s p e c to
re c h a z a d o
p a ra
un
d e l u s u a r io , y s i l q u ie r e
la a d m in is t r a c i n
(p o rq u e
E n e l m e jo r d e lo s c a s o s ,
c o s t o /b e n e f ic io .
S in
son
e n c o n tra r
o p t im is t a s
estar
d eb en
in s is t ir e n
e s ta r c o n s c ie n te
a! p ro y e c to , p e ro
c lc u lo s
de
e l s is t e m a
c o s t o /b e n e f ic io
s i lo s
c o n s t r u ir e l s is t e m a
u s u a r io s
p o s ic i n
p r e r r o g a tiv a .
c o s to s ), d e b e
E n el peo r de
io
de
hay, o
en
d e to d o , e s
a lg u n a , e s s u
nable.2 S i n o l o
geradamente l o s
en
un
pue de
es
bu sca n d o
un
q u e a u t o r iz
v is i n
el
d e c o s t o /b e n e f ic io
m uy
s e n c illo :
e m p le o
p ro y e c to
m u y d ife r e n te
de
a ye r puede
antes
de
a l d a
que
ser
d e s e a b ilid a d del
(y e s e v id e n te
m a n te n g a
nuevo
la
su
q u e n a d ie
c u r r c u lu m ,
c o n c l u y a e l p ro
y e c to .
En
la s
s e c c io n e s
s ig u ie n te s
e x a m in a r e m o s
d iv e r s o s
a s p e c to s
de
lo s
c l c u lo s
d e c o s t o /b e n e f ic io :
Anlisis
de
A n lis is d e
c o s to s
b e n e fic io s
1 Esto se da sobre todo en algunas industrias altamente competitivas donde se desarrollan siste
mas de cmputo nuevos para ofrecer tipos adicionales de servicios para ei mercado (por ejemplo,
nuevos sistemas bancarios, sistemas de tarjeta de crdito y sistemas de viajero frecuente" de ae
rolneas). Por tanto, su usuario podra no justificar el costo de un sistema as con base en mritos
propios, pero puede sentir que tiene que desarrollarlo para mantenerse ai da con la competencia.
2 Como analista en jefe, est en posicin de saber esto de inmediato, desde luego. Pero para un
analista subordinado, que entr al proyecto despus de seis meses de iniciado puede no ser tan
evidente. Para ese punto el proyecto tiene vida propia y luchar por su existencia independiente
mente del usuario y de cualquier otro proceso racional de toma de decisiones.
www.FreeLibros.org
C A LC U LO S DE C O S T O /B E N E F IC IO 551
c2
C m o e x p r e s a r lo s a h o r r o s
A n lis is
de
ANALISIS DE COSTOS
El
pados
p r o p s ito
a s o c ia d o s
instalarlo,
(o d e
d e e s ta
con
5,2.1
operario
de
iu e g o , e s
e i c o s to
mantenerlo,
de
c a lc u la r to d o s
construirlo,
de
a d e m s
de
io s
io s
c o s to s
s in o t a m b i n
c o s to s
antici
el
e x tra s .
cosC ada
a c o n t in u a c i n .
El costo de construir el sistem a

E n e l a p n d ic e
po n e c e s a r i a
p a ra
Tenga p r e s e n t e
sino t a m b i n d e
que
En
ta m e n to
gam os,
n e c e s it a
la d e m s
la
in v o lu c r a d a
A d m in is t r a d o r e s
M ie m b r o s d e
C o n s u lt o r e s y p r o g r a m a d o r e s
de
d is tin ta s
150
v a r io s .
m ie m b r o s
lo s
casos, de
c a te g o r a s
c o n t a b ilid a d ) ;
decir,
con
de
la c a n t id a d
de
p e rs o n a s
de
analistas
e l d e s a r r o llo
que
se
d e t ie m
r e q u ie r e .
y p ro g ra m a d o re s ,
d e l s is t e m a :
u s u a r ia
b a jo c o n t r a to
d e l p e rs o n a l d e
de
se
e s to
la
a u d it o r a , d e c o n t r o l d e
a d m in is t r a c i n
p e rs o n a s
p ue de
c ie n to
p a ra
e x p re s a r
N u e v a m e n te ,
multiplicar
te n g a
que
c u b r ir
e l c o s to
e s to
se
pue de
pue de
incluidas
A s e g re s e d e to m a r e n c u e n ta
p r o b a b le m e n t e
por
e s t im a c i n
c a lid a d
o p e r a c io n e s .
m a y o ra
las
de
la c o m u n id a d
P o s ib le m e n te
de
c a n t id a d
c a lc u la r e i c o s t o
g e n te
e s , o a n u a le s .
a ; e s
la s t c n ic a s
s is t e m a
O fic in is ta s
ia
de
un
n o s lo
to d a
o de
medio
B d is c u tim o s
c o n s t r u ir
otros
a c t iv id a d , d e s d e
e i s is t e m a : n o s lo
un0 d e s t o s s e d is c u t e
por m
r ie s g o s
de
en
en
su
o b te n e r e i s a la r io
p ro y e c to
t r m in o s
lo s f a c t o r e s
ca d a
s a la r io
s e g u ro s ,
o b te n e r d e
ia
de
(o
c o s to s
e x tra s d e
por un
b e n e fic io s
pro
d e l d e p a r
p o r
su
h o ra ,
co m p a
fa c to r d e ,
e m p le a d o s
d i
y
d e l d e p a r
ta m e n to d e c o n t a b ilid a d .
T e n g a
presente
d is p o n ib le s e l c ie n
por c o n c e p to
de
t a m b i n
p o r c ie n to
que
dei
q u ie n e s
tiempo:
t r a b a ja n
en
e l p ro y e c to
n e c e s a r ia m e n te
e n fe r m e d a d e s , v a c a c io n e s ,
lic e n c ia s ,
se
e tc .
n o s ie m p r e
p e rd e r
S u
a lg o
de
c o m p a a
e s t n
t ie m p o
p o d ra
no
tener u n f a c t o r e s t n d a r a a p l i c a r a e s t e t i e m p o p e r d i d o ; d e ser a s , s u p o n g a p o r l o
menos u n f a c t o r e l 1 0 p o r c i e n t o . T a m p o c o e s t m u y l e j o s d e l o r e a l i s t a u n 2 0 p o r
ciento o u n 2 5 p o r c i e n t o . ( E s p o s i b l e q u e e s t o y a s e h a y a t o m a d o e n c u e n t a a l ha
cerse l a e s t i m a c i n d e r e c u r s o s q u e s e d e s c r i b e e n e l a p n d i c e B . ) R e v i s e p a r a
www.FreeLibros.org
a s e g u ra r q u e
dos v e c e s .
e l fa c to r d e
p r d id a
de
t ie m p o
no
se
h a ya
o m it id o
ni se
haya
a p lic a d o
552
C A LC U LO S DE C O S T O /B E N E F IC IO
En
de
m uchos
d e s a r r o llo .
re a
de
la s
p ro y e c to s
P uede
n u e va s
se r
d e b e r
que
lo s
m e to d o lo g a s
el
in c lu ir t a m b i n
m ie m b r o s
de
del
c o s to
e q u ip o
de
p re p a ra r ai
n e c e s it e n
d e s a r r o llo ,
lo s
el
y h a rd w a re
nu e vo s
personal
en e l
p re p a ra rs e
lenguajes
de
p ro g ra m a
equip0
es e l efe
t i e m p o d e c o m p u t a d o r a , t e r m i n a l e s o e s t a c i o n e s d e t r a b a j o y h e r r a m i e n t a s d e desar r o l i o ( e d i t o r e s , paquetes d e p r u e b a , e t c . ) que s e o c u p a n p a r a e l desarrollo d e l siste
ma. E n a l g u n o s c a s o s , las terminales y l a s h e r r a m i e n t a s p u e d e n e x i s t i r y a y pot
t a n t o el p r o y e c t o n o i n c u r r i r e n g a s t o s a d i c i o n a l e s ; e n c a s i t o d o s los c a s o s , sin em
bargo, e l p r o y e c t o t e n d r q u e incluir los c o s t o s d e l t i e m p o d e c o m p u t a d o r a . (Mote
q u e e s t o t a m b i n p u e d e i n c l u i r c o s t o s d e a l m a c e n a m i e n t o e n d i s c o y c o s t o s d e tele
comunicaciones, al i g u a l q u e c o s t o s d e p a p e l , f o r m a s y o t r o s m a t e r i a l e s e x t r a s . )
c i n o la s d iv e r s a s
comercial
q ue
A lg u n o s
que
no
h a b ilid a d e s s o b r e
se
e s t
proyectos
t r a b a ja b a n
p a ra
O tr o
nue vos
la
se
c o s to
que
d e s a r r o lla n
o r g a n iz a c i n
a n te s
que
hay
con
de
g e n te
a s o c ia d o s c o n
te n e r
nueva,
co m e n za r
el
en
es
el
c u e n ta
d e c ir , p e rs o n a s
p ro y e c to ,
p a ra
la
costos
d e r e c l u t a m i e n t o ( g a s t o s d e v i a j e p a r a l o s c a n d i d a t o s al t r a b a j o , p a g o s d e agencias
d e empleo, e t c . ) , a d e m s d e g a s t o s d e e m p l e a d o s a s o c i a d o s con l a p r e p a r a c i n ini
cial q u e debe t e n e r u n n u e v o e m p l e a d o . P u e d e s e r n e c e s a r i o incluir e l c o s t o d e es
pacio d e o f i c i n a , e s c r i t o r i o s , telfonos y o t r o t i p o d e e q u i p o p a r a e i personal n u e v o .
c u a l, s in
duda,
u san do.
s o ftw a re
n o e x is ta
e s p a c io
de
o f ic in a . P o r t a n t o
p u e d e te n e r q u e
in c lu ir
E n a l g u n o s p r o y e c t o s , t a m b i n s u r g e n g a s t o s d e v i a j e p o r v i s i t a s q u e se de
ben h a c e r a a l g u n a s e d e l e j a n a p a r a p o d e r entrevistar u s u a r i o s . O b v i a m e n t e , ste
no e s u n f a c t o r a t o m a r e n c u e n t a e n u n p r o y e c t o d o n d e t o d o s los u s u a r i o s e s t n lo
c a l i z a d o s en l a m i s m a z o n a g e o g r f i c a q u e el e q u i p o d e d e s a r r o l l o : p e r o e n proyec
tos c o n d i v e r s o s g r u p o s d e u s u a r i o s en d i f e r e n t e s l o c a l i d a d e s ( a v e c e s e n d i s t i n t o s
pases), e s t o p u e d e r e p r e s e n t a r u n g a s t o i m p o r t a n t e . P o r c i e r t o , a m e n u d o l a a d m i
n is tr a c i n
v ia je ;
en
s u p o n d r
p ro y e c to s
c g n it a s y m a lo s
La
que
to d a
r e a le s
la
in fo r m a c i n
suelen
r e q u e r ir s e
n e c e s a r ia
v ia je s
se
puede
s u b s e c u e n te s
re c a b a r e n
p a ra
u n s o lo
s o l u c i o n a r in
e n te n d id o s .3
A s , los c o s t o s d e d e s a r r o l l o d e u n s i s t e m a pueden ser v a r i a d o s y m l t i p l e s .

siguiente l i s t a r e s u m e la d i s c u s i n a n t e r i o r ; p u e d e n o s e r c o m p l e t a , p e r o cubre lo
p r in c ip a l:
Los
s a la r io s
g a s to s
e x tra
p a ra
to d o
e l p e r s o n a lr e la c io n a d o
con
e l p ro
y e c to .
C o s to s
d e c a p a c it a c i n
T ie m p o
C o s to s d e
d e c o m p u ta d o ra
r e c lu t a m ie n to
y h e r r a m ie n ta s
de
desarrollo
p a ra e l p e rs o n a l
d e l p e rs o n a l n u e v o
www.FreeLibros.org
3 Esto se puede minimizar a veces si su organizacin tiene extenso acceso a correo electrnico )
otras formas de comunicacin adems del telfono.
CALCULOS DE C O S T O /B E N E F IC IO 553
E s p a c io
G a s to s d e v ia je
* 2,2
d e o f ic in a y e q u ip o
p a ra
p a ra e l p e rs o n a l n u e v o
visitar
u s u a r io s
le ja n o s
El costo de instala r el sistem a
En u n p r o y e c t o s e n c i l l o , p u d i e r a s e r s u f i c i e n t e l l a m a r p o r t e l f o n o a l u s u a r i o y
decirle q u e s e t e r m i n d e d e s a r r o l l a r e l s i s t e m a ; p u e d e e n t r e g a r s e en u n d i s c o f l e x i
ble y d e j a r q u e l m i s m o l o i n s t a l e e n s u c o m p u t a d o r a p e r s o n a l .
io grande y c o m p l e j o , e l p r o c e s o d e i n s t a l a c i n
estos. E n t r e e l l o s t e n e m o s l o s s i g u i e n t e s :
G a s to s d e
c a p a c it a c i n
G a s to s d e
c o n v e r s i n
de base s
G a s to s
in s ta la c i n
comercial
G a s to s d e
a p r o b a c i n
G a s to s d e
e je c u c io n e s
G a s to s d e i e q u ip o
T p ic a m e n t e , t o d a
fa m ilia r iz a r s e c o n
el uso
m s
P e ro
d if c il
en
un
in c lu y e
p ro y e c m u ch o s
usuarios
de
de
es
de
d a to s
r e g la m e n ta r ia
paralelas
d e d e s a r r o llo
la c o m u n id a d
d e l s is t e m a .
d u ra n te
la
in s ta la c i n
usuaria n e c e s i t a r d e c i e r t a c a p a c i t a c i n p a r a
Puede r e q u e r i r s e t a m b i n c a p a c i t a c i n adicio
nal p a r a i o s u s u a r i o s s u p e r v i s o r e s y t a m b i n p a r a e l p e r s o n a l d e o p e r a c i o n e s y o t r o s
miembros e x t r a d e l p e r s o n a l . N o t e q u e e s t o s i g n i f i c a q u e t a m b i n d e b e i n c l u i r s e e l
costo de d e s a r r o l l a r c u r s o s d e p r e p a r a c i n p a r a l o s usuarios, ei c o s t o d e m a n u a l e s o
papelera d e l o s c u r s o s , y e l c o s t o d e l u g a r e s d e c a p a c i t a c i n p a r a l o s u s u a r i o s ( a u
las, e t c . ) . F i n a l m e n t e , n o o l v i d e e l c o s t o d e l tiempo d e l u s u a r i o d u r a n t e este p r o c e s o
de c a p a c i t a c i n ;
rios, o p u e d e
pueden
c a lc u la r s e
p e d ir le
en
c a lc u la r lo
t r m in o s
de lo s u s u a r i o s m i e n t r a s s t o s s e e s t n
L o s c o s to s d e c o n v e r s i n
lando un
s is t e m a
nuevo
p a ra
de
en
d e l c o s to
de
lo s
de
lo s
s a la r io s
sustitutos que
de
lo s
r e a liz a n
la
u su a
la b o r
p re p a ra n d o .
bases
el cual no
t r m in o s
d e d a to s
e x is te
pue den
p re c e d e n te .
ig n o r a r s e
P e ro
si
s i s e e s t insta
el s i s t e m a n u e v o
que n e c e s i t e in
r e e m p la z a a u n o a n t e r i o r , s e g u r a m e n t e e x i s t i r u n a b a s e d e d a t o s
corporarse. S i l a b a s e d e d a t o s e x i s t e n t e n o t i e n e f o r m a c o m p u t a r i z a d a ( p o r e j e m
plo, a r c h i v o s l l e n o s d e p a p e l e s ) , entonces h a b r u n g a s t o s u b s t a n c i a l a s o c i a d o c o n
el i n g r e s o d e d a t o s ; e s d e c i r , a l g u i e n ( o p o s i b l e m e n t e u n g r u p o g r a n d e d e p e r s o n a s )
probablemente s e t e n d r q u e s e n t a r f r e n t e a una t e r m i n a l a t e c l e a r t o d o s l o s d a t o s
relevantes p a r a el nuevo sistema. S l o s d a t o s e x i s t e n t e s y a e s t n c o m p u t a r i z a d o s ,
p u e d e h a b e r u n p e q u e o c o s t o p a r a t r a d u c i r m e c n i c a m e n t e e s o s a r c h i v o s a! n u e v o
formato.4
www.FreeLibros.org
f Existe un costo oculto del que debe estar consciente: durante ia conversin de la base de datos
anterior a la nueva, es inevitable que se e n cuentren errores. Esto sucede sobre todo, como se po-
55 4
L o s c o s to s d e
m a
vo.
incluye
Los
P a ra
b ie n t a le s
s is t e m a s ,
de
o p e ra d o re s
E s to
e m is io n e s
in g r e s o
s im p le m e n te
puede
de
d a r n
de
una
el
S i
lle n a d o
ia
de
en
in c lu ir c o s a s
la s
p a n ta lla s
fo rm a s ,
E l c o s to
ejecuciones
de
los
de
in s is t ir
q u e e l s is t e m a
en
c o s to s
riodo d e t i e m p o . E s t o
rio y otros g a s t o s r e
e s p e c if ic a c i n
r e a liz a r u n a
con
el
ia
que
de
c u e n ta
e n a lg u n a
no
t a m b i n
se
p a r a le lo
un
p r o c e d im ie n to
con
(con
e je c u c i n
b u r o c r t ic o
estimar e i costo de
proceso d e prueba, su esti
tip o s
d u p lic a c i n
ia
fo rm a s
p o d e rs e
m uchos
In v e s tig u e
d u ra r
le
va ya
a o lv id a r
Tpicamente,
lo
de
io s
e s ta r n
( y p o s ib le
g a s to s
le ja n a
una
de
loCa.
tales c o m o pruebas a m
d e video q u e usan los
o tra s
g u b e r n a m e n ta le s
h a b e r la s , t a m b i n
P a ra
use en
involucrar
cunto
s is t e m a
s u s s u e ld o s
sede
a n t e r io r s e
nue'
costos do
io s
de
deb e
en |a
in c lu ir s e
s is t e m a s , e l
usuario
algn pe
personal usua
lo e n c o n t r a r e n la
e l n u e v o d u ra n te
te m p o ra l d e
s u e rte
p a r a le la ; e s to
deb e
a y u d a r le a
a p r o p ia d a .
in s ta la c i n .
del
p a r a le lo , d e
la c io n a d o s .
e s t im a c i n
d e s a r r o llo
ad e m s
en
en
en
in s ta la c i n .
pue de
d e l s is t e m a )
A s e g re s e
p a r t ic ip a
de
un
es
deb e
manera b a s t a n t e precisa; s i p o r e l c o n t r a r i o involucra

macin p u e d e s e r m u c h o m s a p r o x i m a d a .
e s t im a c i n
s is f e
s o ftw a r e
de
lic e n c ia s
a u t o r id a d e s
a p r o b a c i n
de
y /o
estimacin
bue na
g a s to
pue de
r a d ia c i n
si el
ig n o r a r , s o b r e t o d o
f ija .
d iv e r s a s
ta m b i n
de
d a to s .
in v o lu c r a
de
d eb en
t e le c o m u n ic a c io n e s
un
hab er
p o r p a rte
o f e d e r a le s .
c o n tra
se
no
nue vo
le
g e n e r a lm e n te
r e g la m e n ta r ia ,
le s , e s t a t a le s
e q u ip o
p o d e r lo g r a r u n a c o t iz a c i n
a lg u n o s
a p r o b a c i n
que
nuevo,
p ro v e e d o re s
in s ta la c i n , y d e b e
comercial
in s ta la c i n
h a rd w a re
que
c o s to
t a m b i n
t ie m p o
v ia je s
el
d e l p e rs o n a l
p ro g ra m a d o re s
con
su
de
in s t a la c i n .
que
involucrados
d e s a r r o llo
a n a lis t a s
O b v ia m e n t e ,
e x tr a ) y b e n e fic io s a d ic io n a le s , d e b e
se
p u d ie r a n
r e q u e r ir p a r a
tomar
i n s t a l a r e l s is t e m a
d e l u s u a r io .
t e n g a p r e s e n t e q u e p a r a l o s s i s t e m a s g r a n d e s , l a I n s t a l a c i n no
golpe; p o r e j e m p l o , u n n u e v o s i s t e m a b a n c a r i o p u e d e i n s t a l a r s e e n una
s u c u r s a l tras o t r a , d u r a n t e u n p e r i o d o d e a l g u n o s meses. En g e n e r a l , e s t o significa
que e l c o s t o de i n s t a l a c i n d e ias s u c u r s a l e s iniciales ( o r e a s d e u s u a r i o s ) s e r m a
y o r q u e e l d e l a s s u b s e c u e n t e s , p o r q u e e l e q u i p o d e instalacin t e n d r c a d a vez ms
experiencia y ( c o n suerte) l o s p r o b l e m a s i n i c a l e s q u e p u d o h a b e r c o n e l sistemase
h a b r n e r r a d i c a d o tras las p r i m e r a s i n s t a l a c i o n e s .
P o r otro l a d o , s i e l proceso e
i n s t a l a c i n dura varios m e s e s ( o i n c l u s o a o s ) , d e b e t o m a r e n c u e n t a l a p o s i b il id a c
F in a lm e n t e ,
se
h a r
de
dr imaginar, si la base de datos existente es manual y las entradas se han hecho a mano; encon
trar datos fallantes, incompletos y datos obviamente incorrectos. Entre ms histricos sean ios
datos, ms errores es probable encontrar. Adems, la conversin misma puede dar lugar a) surgi
miento de errores, sobre todo si es un proceso manual. Por ello, es probable que exista un gasto
asociado con ia correccin de datos. Probablemente sea buena idea tomar una muestra al azares
la base de datos existente para estimar el nmero de errores que se encuentren; luego, hay que es
timar el costo de corregirlos (en ia mayora de los casos, las correcciones se tendrn que hacer ma
nualmente).
www.FreeLibros.org
dg c a m b i o
sistema y
de
la
p e r s o n a l:
p r e p a r a c i n
ijn n u e v o t r a b a j o
q 2.3
en
o tra
gente q u e h a
de l o s u s u a r i o s
parte.
la
a d q u ir id o
se
pue de
e x p e r ie n c ia
en
la
in s ta la c i n
a b u r r ir d e l p r o c e s o
del
y c a m b ia r s e
El costo del dinero

E l d in e r o
que
se
r e q u ie r e
p a r a d e s a r r o lla r e in s t a la r u n
s is t e m a
no se da
en
lo s
rboles; i a o r g a n i z a c i n t i e n e q u e p e d i r l o p r e s t a d o , o b i e n d e b e s a c a r s e d e s u s fon
dos actuales. P o r t a n t o , existe u n c o s t o a s o c i a d o c o n e l u s o d e l d i n e r o . D e p e n d i e n d o
je su o r g a n i z a c i n , se l e p u e d e p e d i r q u e exprese e s t o e n t r m i n o s d e c o s t o d e l d i ner0 prestado, o d e o s i n t e r e s e s q u e g a n a r a s i s e t u v i e r a i n v e r t i d o e n l u g a r de es
tarse u s a n d o p a r a e l p r o y e c t o .
Esta e s un r e a e n l a q u e d e b e r e c u r r i r al c o n s e j o d e l d e p a r t a m e n t o d e conta
bilidad. E i l o s t e n d r n c a s i s e g u r a m e n t e u n a r e g l a e s t n d a r a c e r c a d e c m o t r a t a r
tales c u e s t i o n e s , y e s i m p o r t a n t e q u e su p r o y e c t o u t i l i c e e l m i s m o enfoque.
C.2.4
Costos operacionaies
U na ve z
in s t a la d o
e l s is t e m a ,
lo. S i n e m b a r g o , e s t o t a m
ahorrar d i n e r o , d a d o q u e
tualmente t i e n e e l u s u a r i o
b i n
debe
es
de
(a
m enos
a l u s u a r io
s u p o n e rs e
que
C o s to s d e
C o s to s
C o s to s d e
p e rs o n a s
C o s to s d e
m a n t e n im ie n to
C o s to s d e f a c ilid a d e s
de
haya
( s u p o n ie n d o
que
no
es
se
b i n ), d e l e q u i p o
de
materiales
p a p e l, f o r m a s ,
(c o m o
p re s o ra , e t c . ) .
T e n g a
e l s e n t id o
p re s e n te
de
en
m s
a a d id o
la
c o n t in u a r o p e r n d o
que
el
e c o n m ic o
nuevo
que
s is t e m a
ac
el que
m a y o r f u n c io n a lid a d ) .
A lg u
son:
muy amplio.
haya
r e la c io n a d o s
d is c o s
se
costos de softw are
en
A b a rc a
c o m p ra d o
ta m b i n
que
terminales, a l g u n a s i m p r e s o r a s y
coticen c o s t o s d e r e f a c c i o n e s d e
Los
s e r
y m a te r ia le s y e q u ip o
te le c o m u n ic a c io n e s ,
c o n s u m ib le e n
d in e r o
re a
s o ftw a re
hardware
A q u e l t r m in o
c m p u to
c o s ta r
que
nos e j e m p l o s t p i c o s d e c o s t o s o p e r a c i o n a i e s
h a rd w a re
le
re p re s e n ta r u n
de
que
desd e
p e ro
t e r m in a le s ,
flexibles,
d e s g a s ta
ya,
p a rte
o
de
g a v e ta s
del
e l c o s to
ve a
la
e s t a c io n e s
p a ra
del
s e c c i n
discos,
de
equipo
C .2 .6
de
ta m
t r a b a jo ,
c in ta s
de
im
hardware s e p u e d e c o n s i d e r a r
reemplazarse. E s t o i n c l u y e
e q u i p o . A s e g r e s e d e q u e se
n e c e s it a
ta l v e z o t r o s t ip o s d e
m a n e ra a d e c u a d a .
e s ta
d is c u s i n
s ig n if ic a n
lo s
g a s to s
c o n t in u o s
de
www.FreeLibros.org
re n ta d e
s is t e m a s
tip o s d e s o f t w a r e
o p e r a t iv o s ,
que
p a q u e te s
se pue de
de
h a b e r re n ta d o d e
a lg n
de
base s
p ro v e e d o r.
de
d a to s
y o tro s
556
Los
costos de personas
in c lu y e n
a l p e r s o n a l d e o p e r a c i o n e s , p e r s o n a l d e a r
y o t c n ic o , p r o g r a m a d o r e s d e
in v o lu c r a d o s
c o t id ia n a
con
la
te , p r o b a b le m e n t e
m ar en
o p e r a c i n
te n g a
c o n s id e r a c i n
que
el
c o s to
de
io s
u s u a r io s
d ir e c ta m e r * '
anteriorrne-f
c o m o u n c o s t o a u m e n t a d o p a r a poder to'
g a s t o s e x t r a s d e la corporacin.
e x p re s a r e s to
s e g u r o s , b e n e fic io s y
C o m o
se
d is c u ti
mensual ( o a n u a l ) p r e v i s t o p a r
los c o s t o s n o s l o d e l m a n t e n j.
m i e n t o p r e v e n t i v o q u e p r o p o r c i o n a e i p r o v e e d o r , sino t a m b i n c o s t o e x t r a d e r e p a r a c i o n e s e n c a s o d e q u e s e descomponga e i e q u i p o . I n c l u y a t a m b i n costos de
m a n t e n i m i e n t o d e s o f t w a r e c o m e r c i a l , si s e n e c e s i t a ; e l c o n t r a t o d e m a n t e n i m i e n t o
q u e o f r e c e n l o s p r o v e e d o r e s u s u a l m e n t e incluye u n nmero t e i e f n i c o d e consulta
Los
ei
equipo
p a ra
costos de m antenim iento

de
a p o yo
c m p u to ;
t c n ic o ,
de
n u e v a s v e r s io n e s
A d em s, sus
de
su
a d e m s
sus
g a s ta n
m a n t e n im ie n to .
Si
m s
fu e rz o
la
el
en
p o r lo
p o r c ie n to
r e e m p la z a
t c n ic a s
(o
de
c o s to
r e d u c id o ) a
m u e s tra
el hecho
su
uno
p re s u p u e s to
a n t e r io r ,
e s fu e rz o
su po ne
m o d e rn a s
re p re s e n ta
d e l cosl
aplicacin. Puede
d e q u e m u c h a s orga
p r o c e s o d e d a t o s en
una
s o ftw a re
e s t im a c i n
de
de
una
e l a n t e r io r
e s p e c ie
10
de
q u e
se
15
que
s ta s .
aos
e s t im a c i n
el
nuevo
E s te
e s un
d e s a r r o ll
d e s o ftw a re
e f ic ie n t e s
de
estimar
m a n t e n im ie n to .
in g e n ie r a
t ie n e
puede
de
que
m o d e rn a s d e
m s
in c lu ir
de
e s t im a r lo s c o s t o s d e l n u e v o s is t e m a :
de
que
ya
lo
de
sistema actual
si el
m enos
c a n t id a d
r e la t iv a m e n te
d eb en
m e jo r a m ie n to
c o s to , c o m o
c o n s e rv a d o r,
u s a r
m a n e ra s d e
m is m a
p r o b a b le
g r a t u it a s
' j
del 50
s is t e m a
t c n ic a s
no
de
H a y v a r ia s
q u e r ir
in c lu ir
a c t u a liz a c io n e s
r e p a r a c i n
s e r u n f a c t o r im p o r t a n t e
nizaciones
de
e l c o s to
deb e
p a q u e te s .
c o s to s
p a ra
in c lu y e n
e s t im a c i n
de
re-
es-
usando
y q u e e l nuevo
E s to
es
poco
a n t i g e d a d , p e ro
d e l p e o r de
lo s ca so s,
respecto >
encon
trado que, p o r e j e m p l o , s u s c o s t o s d e m a n t e n i m i e n t o s e h a n r e d u c i d o en
u n f a c t o r d e c i n c o o m s g r a c i a s a l u s o c u i d a d o s o d e l a n l i s i s , diseo, y
p r o g r a m a c i n e s t r u c t u r a d o s . 5 I n v e s t i g u e o t r o s p r o y e c t o s s i m i l a r e s dentro
d e s u p r o p i a o r g a n i z a c i n p a r a v e r s i s e h a n l o g r a d o a h o r r o s d e e s t e tipo:
d e s e r a s , p u e d e s e r razonable e s p e r a r l o s e n s u p r o y e c t o .
S e a c a u t e lo
s o , s i n e m b a r g o , e n c u a n t o a l a t e n t a c i n d e m o s t r a r r e d u c c i o n e s consi
derables d e p e r s o n a l b a s a d a s e n l a i n s t a l a c i n d e su n u e v o sistema; rara
v e z s u c e d e , p o r l a s r a z o n e s q u e s e discuten e n l a s e c c i n C . 3 . 1 .
U na
e s t im a c i n
o p t im is t a
a l m a n t e n im ie n to
S i a c tu a lm e n te
no
c o m p a r a c i n
si d ese a
simistas),
(o
tra te
puede
d e l s is t e m a
de
se
e s t
b a s a rs e
a c tu a l.
utilizando
en
a lg n
e v ita r e s t im a c io n e s
d e te r m in a r
el
e l a h o rro
M uchas
c o s to
e s p e ra d o
o r g a n iz a c io n e s
sistema
que
d e m a s ia d o
p r o m e d io
de
han
pueda
s e r v ir
o p t im is t a s o
de
pe
para
www.FreeLibros.org
5 Para clculos detallados de estos ahorros, consulte el libro de Capers Jones, Programming Poductivity, (Nueva York: McGraw-HIll, 1985).
s is t e m a s
en
a lg u n a
m ie n t o
por
lnea
de
fu n c i n
deb en
su
U n
s im ila r e s
b a s a r
por
de
o r g a n iz a c i n .
(p o r
la s
e s t im a c io n e s
e s t im a c io n e s
de
E s to
e je m p lo ,
de
p o r a o , o c o s to s
p e ro
h a ce r
su
n o r m a liz a d a
c d ig o
a o ),
p e r m it ir le
de
d e n tro
u n id a d
c o s to s
de
r e a liz a d a s
en
se
m a n t e n i
p o r p u n to
e i a p n d ic e
a p r o p ia d a s
p a ra
p ro y e c to .
c o s to
f in a l q u e
es
deb e
e s t im a r s e
cu an do
se
el
c a lc u la
c o s to
o p e r a c io n a i d e i
las
mantenimiento del p r o v e e d o r y
e l personal u s u a r i o ) .
S i e l n u e v o s i s t e m a v a a o p e r a r en u n a c o m p u t a d o r a p r i n c i p a l
c e n t r a l i z a d a que y a e s t i n s t a l a d a , estos c o s t o s p u e d e n e s t a r incluidos e n e l c o s t o
global d e h a r d w a r e q u e s e d i s c u t i a n t e r i o r m e n t e . S i n e m b a r g o , s i e s t d e s a r r o l l a n
d o u n s i s t e m a completamente n u e v o q u e t e n d r s u p r o p i o l o c a l d e o p e r a c i o n e s , s t e
n u e v o s is t e m a
o f ic in a s
p a ra
el d e
( p o r e je m p lo , e l c u a r t o
o p e r a c io n e s , la g e n t e
de
c o m p u ta d o ra s y
de
im p o r ta n te .
El costo del fracaso

E x is te
o tro
n u e v o s is t e m a .
de
o c u l t a r lo
in fo r m a c i n
E x is te n
nos c a s o s ,
ms
g a s to
que
d e b e te n e r e n
E s c o n v e n ie n t e
le s , p e r o t i e n d e
mas
p la n ta f s ic a
e l p e rs o n a l d e
p u d ie r a s e r u n g a s t o
C.2.5
la
en
v a r ia s
en
la
c a te g o ra
se
en
un
a s p e c to
u n fu tu ro :
fo rm a s
e l s is t e m a
f a lla , m i e n t r a s q u e
que
de
q u e d a
c u e n ta : e l c o s to
s e p u lt a r e s to
c o n v e r t ir
su
de
de
p o s ib le s f a lla s
c o s to s
im p o r t a n t e
del
o p e ra c o n a de
lo s
siste
en
a lg u
c o n t a b ilid a d .
fa lla
de
s is t e m a s ,
to ta lm e n te
fu e ra
de
co m o
se
p o d r
o p e r a c i n
e n o tr o s , c o n t in a o p e r a n d o , p e r o
im a g in a r ;
h a s ta
qu e
u n a o v a r ia s d e
se
c o r r ig e
la
s u s s a lid a s s o n
algunas funciones pueden s e r i n o p e r a b l e s y e n o t r o s

puedan t e n e r a c c e s o a i s i s t e m a . T o d a s e s t a s f o r m a s
d e f a l l a t i e n e n un c o s t o a s o c i a d o : c o s t o s d e h a r d w a r e , c o s t o s d e s o f t w a r e , c o s t o s de
p e r s o n a l r e l a c i o n a d o c o n l a c o r r e c c i n d e l e r r o r , c o s t o s l e g a l e s e n e l c a s o d e que i a
in c o r r e c ta s .
puede
E n a lg u n o s c a s o s ,
ser que
lo s
fa lla d e l s i s t e m a
y
costos
C m o
g u n ta a
p r d id a s f in a n c ie r a s
p r d id a
e s t im a r s to ?
nuevo
de
S e ra
puede
in g e n u o
ig n o r a r lo
c o n s t r u ir s is t e m a s
o a n a lis t a s
que
te n e r,
u o tra s
p r d id a s
d e g a n a n c ia s o p r d id a d e
p o r c o m p le to
p e rfe c to s ; p o r o tro
laboran en
e l p ro y e c to
m ir a r n
si
lo
co m o
la m e n t a b le s ,
c lie n t e s .
pues
an
la d o , s i p r e
c u n t a s fallas prele acabara de d a r u n a
d e s e n ilid a d .
vez l o
sistema
T al
ia p o s ib le
la c a p a c id a d
e l s is t e m a
n u e va fo rm a
ll a s d e l
deb e
lo g r a d o
lo s
que
se
no
h a y a o c a s io n a d o
a s o c ia d o s c o n
no h e m o s
veen
u s u a r io s
m s
r e s p o n s a b le
a c tu a l,
s i e s t
que
puede
c o n s tru y e n d o
h a ce r
uno
es
n ue vo
1 ) e s tu d ia r
p a ra
la
r e la c i n
r e e m p la z a r lo
y,
de
fa
2)
ver
6 Esto supone, desde luego, que alguien de su organizacin est llevando un registro de estas co
sas. Una encuesta de casi 500 instalaciones de proceso de datos en los EUA conducida por Lientz
y Swanson en 1980 sugiere que aproximadamente un 50% de las organizaciones no llevaron un re
gistro de las tallas operacionales en sus sistemas; vase el libro Software Maintenance Manage
ment, de Lientz y Swanson, Reading Mass.: Addison Wesiey, 1980.
www.FreeLibros.org
558
l o s dems s i s t e m a s d e s u organizacin.6 As p u e d e
razonables s o b r e l a r e l a c i n d e f a l l a s q u e t e n d r e l sis
tema n u e v o . C o n s u e r t e , s u p r o y e c t o s e p o d r c o n s t r u i r c o n u n a c a n t i d a d substan
cialmente menor de e r r o r e s q u e l a d e l a c t u a l , o i n c l u s o q u e l a d e l s i s t e m a promedio
d e s u organizacin; d e hecho, i n t e n t e l o g r a r u n a m e j o r a d e l 1 0 p o r ciento si n o ms
ia
r e la c i n
fallas
de
h a c e r a lg u n a s
S i n o e x is te n
tema
a c tu a l d e
c i n
p a ra
el
d o c u m e n to
C .5 .
de
el que
de
g lo b a l
c o s to s
se
del
lo
pue de
cu an do
se
de
te n e r u n
lizarse
cu an do
de
se
g ra n
de
vea
e s te
la
en
su
s e c c i n
e l c u a l u n a f a lla te n d r a
no
s o ftw a re , a
el
ve a
sis
del
e s t im a
h e ch o
re s p e c to
a lc a n c e ,
p re o c u p a n
de
es p r o f e s i o n a l
pesar dei hecho
h a c e r lo
p o r el m om en
Software Reiability
lib r o
de
1 9 7 9 ).
e n o rm e
im p a c t o
la s
lo
en
su
v a r io s
com o
s o b re
io s
s ie n d o
de
un
lo s
c o s to s
in v e s t ig a r q u
de
la
de
puede
el
d e c la r a
n o a fe c ta
c o s to
de
e fe c tiv o
de
costo
al
o p e r a c i n
D e
d e c o m p ra
se
de
E l c o s to
c o n s id e r a n
de
a o s
m a n e ra
en
lu g a r d e
la o r g a n iz a c i n ,
g a s to s
d e s a r r o lla r s o f tw a r e
normalmente
o p e r a c i n
in v e n t a r s u
p r o p ia
f in a n c ie r o s
se
de
p o lt ic a
usan
c a p ita l,
( d e p e n d ie n d o
e x is t ir p e q u e a s v a r ia n te s e n
p a r m e tro s
una base
de
d u ra n te
su
en
c a p i t a l i z a n ; e s d e c ir ,
e s to
c a p ita liz a b ie
e i f lu jo
h a rd w a re
p e r io d o
in s ta la c i n
p ue den
se
A u nque
im p u e s to s
s o b re
d e s e m b o ls a r n
re c o n o c e r
e l m is m o .
im p u e s to s p r e v a le c ie n t e s ) .
no.
c o s to
se
lo s
O tro s
aos.
g a s to s s o b re
tre m e n d o
de
s is t e m a ,
e l c u a l o c u rre n .
de
algunos
c o m p ra s
la r g o
O b v ia m e n t e , a q u n o
de
el nuevo
p e r io d o
r e a liz a r
o c u rre n , a u n q u e
p o rta n te
en
de
io s
pue de
se
capita
c o n t a b iliz a n
e s ta re a .
Es im
seguir
d e c o n t a b ilid a d .
su
y su
r e g la
m a n e r a c o n s is te n te .
C.3
ANALISIS DE BENEFICIOS
Es
te
no
al
y c o m p le jo , e n
y
re s p e c to ,
d e c ir ,
el a o
un
e l c o s t o t o ta l s ig a
con
es
c la s if ic a c i n
im p a c to
r e p a rte
m e n to s d e
de
su
T p ic a m e n te ,
c i n
al
c o n s id e r a r
c o n f ia b ilid a d
in f o r m a c i n
d u ra n te
s is t e m a ,
p u e d e te n e r u n
los
g ra n d e
de
d e b e
in fo r m a c i n
d e s a s tr o s a s
a s o c ia d o s
la r g o
s im ila r , la d e c is i n
c o s to
m s
m o d e lo
p re s e n ta n ;
im p u e s to s
r e p a rte n
re n ta
m e n o s
confiabilidad d e l s o f t w a r e
s o b r e l a cual h a c e r u n a
la
base
D istinga entre costos de capital y costos de operacin
en
aun
lo
( R e a d in g , M a s s .: A d d is o n - W e s ie y ,
A lg u n o s
se
ias
de
m s
p a ra
una
p a ra
s is t e m a
n o te n e r u n
m a y o ra
c i n
un
tie n e
p o r
p o t e n c ia lm e n t e
o b te n e r
M y e rs
y no
r ie s g o s ;
la
C.2.6
ao
de
P a ra
G le n
d is p o n ib le s
e n to n c e s
a n lis is
a c e p ta b le
que
to .
e s ta d s tic a s
n u e vo ,
de
S i e s t
to d o s
organizacin,
su
c o n s e c u e n c ia s
m e n te
de
s u p o s ic io n e s
m ucho
m s
q u e c a lc u la r s u
a p n d ic e ,
puede
d if c il c a lc u la r
c o s to .
En
lo s
a lg u n o s
s e r im p o s ib le .
b e n e fic io s
de
casos, co m o
D e b id o
ta l
vez
un
se
que
nuevo sistema
m e n c io n
de
in fo r m a
a l p r in c ip io
e l s is t e m a
es
d e es
o b lig a to r io ,
www.FreeLibros.org
p o rq u e
e l u s u a r io
d e c id i
b e n e fic io s t a n g ib le s
no.
que
q u ie r e
e l s is t e m a
s in
im p o r t a r s i s e
pueden
id e n t if ic a r
El
m as.
in te n to
Los
de
c a lc u la r
u s u a r io s
tr 0 | o i n f o r m a c i n
s e s p r e g u n t a
re
c u n to
lo s
que
m u e s tra n
m s g ra n d e
u s u a r io s
m e d ir s e y c a l c u l a r s e
el c a s o p a r a
sistema c o n
de
m uchos
es
m a rc o s
c u n ta s
com o
o c a s io n a
c u a n tita t iv a .
de
p a ra to m a
de
ganancias
re p o rta r , e s
s e r
p r o b le
con-
m e jo r
d e c is io n e s , p e r o
proba
he
m a g n fic o ... D e
tienen
m ucha
c a b id a
n u m r ic a s d e c o s t o /b e n e f ic io .
un
id e n t if iq u e n
Si no
y a n a lis t a s ) , t r a t e
ta n to s
a c e rc a
m a g n fic o n o
c o m p a r a c io n e s
la b o r a l lle v a r a c a b o
m a n e ra
que
... s e n c illa m e n te , s q u e
hace r que
p ro y e c to s
el
e n tu s ia s ta m e n te
a h o rra r o
lo s e r , p e r o t r m i n o s
en h o ja s d e c lc u lo
va
d in e r o
P u e s ... m u c h o
cho, p r o b a b le m e n t e
P o r e llo , s u
tangibles
h a b la r n
m s o p o r t u n a o m e jo r e s
q u e c o n te s te n :
r a c o r r a l a r
b e n e fic io s
c lc u lo
de
b e n e fic io s
lo
de
pue de
c o s t o - b e n e f ic io
t a n g ib le s
lo g r a r ( lo
lo g r a r q u e
que
c u a l s u e le
c o m p a re n
se
puedan
su
ser
nuevo
c o n o c id o s .
A s , puede d e c i r a l u s u a r i o : S u
sistema n u e v o d e l q u e e s t a m o s h a b l a n d o y el
s is t e m a X .
C u l c o n s i d e r a r a m s importante? S i s l o s e p u d i e r a i m p l a n t a r u n o d e
ellos, c u l e s c o g e r a ? S u p o n i e n d o q u e e l s i s t e m a X t i e n e a l g u n o s beneficios t a n
g i b le s a s o c i a d o s , e s t o d e b i e r a d a r l e p o r lo m e n o s u n a m a n e r a b u r d a d e d e t e r m i n a r
el v a l o r a p r o x i m a d o d e l n u e v o s i s t e m a .
ponga q u e
En
a lg n
t u v ie r a
la s
o tro
con
b e n e fic io s
elegir
que
s e c c io n e s
e n tre
el
s ig u ie n te s , d is tin g u ir e m o s
e n tre
b e n e fic io s t c tic o s y
e s tra t
per
mite q u e l a o r g a n i z a c i n c o n t i n e r e a l i z a n d o l a m i s m a actividad d e n e g o c i o s , p e r o a
menor c o s t o (o m a y o r g a n a n c i a ) ; u n b e n e f i c i o e s t r a t g i c o e s e l q u e p e r m i t e comen
zara r e a l i z a r u n t i p o d e n e g o c i o t o t a l m e n t e n u e v o , o a h a c e r l o e n u n r e a t o t a l m e n t e
g ic o s d e
un
nuevo
nueva o c o n
C.3.1
s is t e m a .
E n
e s te
c o n te x to , u n
b e n e fic io
t c tic o
c lie n t e s n u e v o s .
Beneficios t ctico s
beneficios t c t i c o s s u e l e n a s o c i a r s e c o n r e d u c c i o n e s e n
d e oficina. A u n q u e e s t o no e s m s i c a p a r a los o d o s
r e a l i d a d . U n nuevo s i s t e m a d e i n f o r m a c i n puede p e r m i t i r
f u n c i n con l a m i t a d o m e n o s d e l n m e r o d e u s u a r i o s q u e
Los
n is tr a t iv o
es u n a
m is m a
te s .
E s to
c lc u lo s
se;
ven
o se
a c t iv id a d e s
una
g ra n
veces,
se
de
fo rz a d o s
to s ) m l t i p l e s
to m a
es aqu l qu e
deb e
de
que
de
r e a liz a r la s
cu a n d o
c a n t id a d
r e g is t r o
puede
t ie m p o
lo s
d a to s
u s u a r io s
a
m is m a s
m ano,
a c tu a lm e n te
cu a n d o
a c t iv id a d e s
h a c e rs e
re c u p e ra r
un a
lo s
vez
(o
con
d a to s ,
e l p e r s o n a l a d m i
de
lo s
que
se
r e g is t r a r
una
r e a lic e
o cu p aban
e s t n
p u d ie r a n
o fic in is t a s ,
se
r e a liz a n d o
c o m p u t a r iz a r -
los
m is m o s
c o m p u ta d o ra ;
siendo
que
la
a n
pue de
da
le s
h a c e rs e
r p id a m e n te p o r c o m p u t a d o r a .
A u nque
s te
sea
un
b e n e fic io
o b v io
del
nue vo
s is t e m a ,
te n g a
c u id a d o
de
no
sobreestimar e l e f e c t o . E n a l g u n o s c a s o s , h a b r m e n o s a h o r r o d e lo q u e p u e d e ha
ber e s t i m a d o ; l o s r e g l a m e n t o s d e l s i n d i c a t o y l a b o n d a d d e a l g u n o s a d m i n i s t r a d o r e s
intermedios d e l a o r g a n i z a c i n u s u a r i a p u e d e n e v i t a r e l d e s p i d o d e a l g u n o s d e e s o s
u s u a r i o s oficinistas. A d e m s , e s i g u a l m e n t e i m p o r t a n t e d a r s e c u e n t a q u e l o s niveles
superiores d e l a a d m i n i s t r a c i n s e i m p r e s i o n a n c a d a vez menos c o n e l a h o r r o d e
www.FreeLibros.org
560
C A LC U LO S DE COSTO/BENEFICiO
u n o o d o s o f ic in is t a s ; b u s c a n
mayores
b e n e fic io s
la
y m e jo r e s c o n
de
in tr o d u c c i n
n u e v o s is t e m a .
U n t ip o
p o d e r
t r a n s a c c io n e s
lle v a r
un
beneficio
de
p ro c e s a r
por se g u n d o
m e jo r f lu jo
cliente
mente,
en
n e ro .
P e ro ,
t c tic o
tr a n s a c c io n e s
e fe c tiv o
e l s e c re to
co m
de
no
m ucho
de
slo
que resulta efe

Poder m a n e j a r r r %
r e d u c i r c o s t o s d e oficina, s i n o que puede
o r g a n i z a c i n ( c o n v i r t i e n d o el p e d i d o del
m s
p e r m it e
e fe c tiv o
es
m s in te r e s a n te
n e g o c io s
p a ra
la
el a h o rro
r p id a m e n t e .
rpidamente, a c e l e r a n d o e i t i e m p o d e e n t r e g a , e t c . ) . N u e v a
r a d i c a en e n c u a n t i f i c a r e s t o y e x p r e s a r l o c o m o u n a cantidad en d i
o e j e m p l o , considere e l s i g u i e n t e dilogo e n t r e e l u s u a r i o y
m s
a n a lis t a :
Analista:
Bueno, cuntos pedidos diarios procesa?
Usuario:
B u eno,
Analista:
p ro c e s a m o s
un
do
de
la f a c t u r a
se
Por
que
a s ?
pedidos
1 0 ,0 0 0
re tra s o , a s q u e to m a
una
d ia r io s .
sem ana, en
hay
pedi
P e r o s ie m p r e
p r o m e d io
s u r tir e l
un cliente.
lo
le
m anda
no
se
al
c lie n t e ju n to
e s p e ra
que
con
e l c lie n t e
la
no es
m e rc a n c a
pag ue
h a s ta
h a b e r la
r e c ib id o , o n o ?
U s u a r io :
C ie r to .
A n a lis ta :
A s q u e
si p o d em o s
de c i n c o d a s
medio, c u a t r o
r e d u c i r la t a r d a n z a
uno,
d a s
o b te n d ra m o s
a n te s .
en
e i p ro c e s o
e l d in e r o
s i e i p e d id o
p r o m e d io
es de
pedidos d i a r i o s , e s o s i g n i f i c a q u e
hablando d e a l r e d e d o r d e $100G0,G0G d i a r i o s . E i t e n e r
t r a s m a n o s $10G00,000 cuatro d a s a n t e s d e l o q u e se
p ro c e s a m o s
1 0 ,0 0 0
a n te s , p o r c o n c e p to
U n
nuevo
s is t e m a
t a m b i n
de
puede
pedido
pro
$ 1 ,0 0 0 y
estamos
del
d e i c lie n t e ,
en
en
nues
e s p e ra b a
lo s p e d id o s d ia r io s , v a ld r a . . .
r e p o rta r a h o rro s
en
e q u ip o
de
c m p u t o ; ei
sistema a n t e r i o r p u e d e e s t a r f u n c i o n a n d o e n u n a c o m p u t a d o r a p r i n c i p a l c a r a , m ie n
t r a s que el n u e v o f u n c i o n a en una p e q u e a P C c o l o c a d a en e l e s c r i t o r i o d e l u s u a r i o .
U n c a m b i o a s n o s l o a h o r r a c o s t o s de h a r d w a r e , s i n o t a m b i n r e p r e s e n t a un aho
rro e n el r e a d e c o s t o s d e local, d e o p e r a d o r e s , e t c . Y si el n u e v o s i s t e m a r e d u c e
i a c a n t i d a d d e p a p e l y d e f o r m a s i m p r e s a s , t a m b i n a h debe reflejarse u n a h o r r o .
Asegrese de q u e sus clculos e n c u a n t o a e s t o e s t n completos; t e n g a e n cuenta
que
pueden
nas
de
r e q u e r ir s e
e s c r ib ir ,
m enos
a r c h iv e r o s ,
p o s ib le m e n te
m enos
m enos
lla m a d a s
e s p a c io
de
telefnicas
o f ic in a ,
e n tre
su
m enos
m q u i
los clientes, etc.

Los
c o s to s
de
mantenimiento del
nuevo
s is t e m a
t a m b i n
deben
p r o p o r c io n a r
www.FreeLibros.org
un
b e n e fic io , c o m o
de
h a rd w a re
m is m o
e q u ip o
deben
de
se
d is c u ti
r e d u c ir s e
c m p u to
que
en
(a
la
s e c c i n
m enos
ya
e s t
que
mantenimiento
e j e c u t a n d o s u n u e v o sistema e n el
e n la o r g a n i z a c i n ) , y l o s costos de
a n t e r io r .
e s t
in s ta la d o
Los
c o s to s
de
CALCULOS DE COSTO/BENEFICIO 561
de
s o ftw a re
es
de
s u p o n e rs e
que
s e r n
in fe r io r e s
lo s
del
s is t e m a
a c tu a l.
C.3.2
Beneficios estratgicos dei nuevo sistem a

En
de un
cada
nue vo
de a h o rra rs e
b ilid a d
de
vez
casos,
son
la
E x is te n
lo s
b e n e fic io s
o fic in is ta s
hace r
de
v a r io s e je m p lo s
I d e n t if ic a r o
nuevos
a tra e r
N o
c u a n ta s
o unas
in te re s a n te s
s lo s e t r a t a d e
r e a lm e n t e
estratgicos.
b e n e fic io s
u n o s c u a n to s
p e r m it ir le
a c tu a l.
s is t e m a
m s
s is t e m a
co sa s
h o ja s
b e n e fic io s
c lie n t e s
que
le
que
de
o tra
im p o r t a n t e s
o p o rtu n id a d
p a p e l, s in o
s e ra n
e s tr a t g ic o s
de
e
la
m a n e ra
de
la
p o s i
con
im p o s ib le s
ei
p o t e n c ia le s :
no
p o d ra
id e n t if i
c a r la o r g a n iz a c i n .
E n tra r
m e n te
n o e s ta b a n
nue vos
C a p tu ra r ,
m e rc a d o s
r e p r o d u c ir
p r e v ia m e n te
nue vos
p ro d u c to s
que
p r e v ia
d is p o n ib le s
s lo
d is tr ib u ir
te n a n
acceso
c o n o c im ie n t o s
una
dos
e x p e r ie n c ia
p e rs o n a s
d e n tro
de
lo s
ia
que
o r g a n i
z a c i n .
En
una
fo r m a c i n
e c o n o m a
c o m p e te n c ia
ia
fu n c io n a lid a d
b le ; e n
que
o tro s , p u e d e
t e n c ia le s
n u e vo s
s it u a c i n ,
tra te
m e rc a d o
ra
U na
de
t e r r it o r io ,
E s to
es
com o
m u y v a lio s o .
ei n u e vo
r e s u lt a r d e
a n t e r io r m e n t e
c u a n tific a r
e s te
s e r ia a c t u a l, u n
la
e v ita r
p r d id a
de
E n a lg u n o s c a s o s , e s to
s is t e m a ,
c a p a c id a d
la
p a re c e
que
b e n e f ic io
en
la
p a ra
no
del
in
p o r ia
e s ta b a
cual
S e a
a u m e n to
de
d is p o n i
id e n t if ic a r c lie n t e s
t r m in o s
de
g ra c ia s
e s p o s ib le
d e l s is t e m a
ig n o r a b a
s is t e m a
io s a c t u a le s
po
se a
la
c lie n t e s
y , d e a h , e n t r m in o s d e g a n a n c ia s .
fo rm a
c a p a c id a d
c o m p e t it iv a
r n u e v o s c lie n t e s
o fre c e
q u e
de
de
por
ta n
puede a tr a e
e s re a lm e n te
que
m s
d if c il d e
in f o r m a c i n
id e n t if ic a r
por
p o s ib le
b e n e fic io
que
te n d e n c ia s
e s t a c i n ,
no
p a tro n e s
p re fe r e n c ia s
por
c a s i c u a lq u ie r
en
e s tr a t g ic o
a n te r io r m e n t e
s is t e m a
es
se
(p o r
del
la c a p a c id a d
te n a .
e je m p lo ,
c lie n t e
a u to m a tiz a d o
del
s is te m a
E l e je m p lo
tp ic o
te n d e n c ia s
h a c ia c ie rto s
que
r e e m p la c e
de
pa
es
ia
v e n ta s
p ro d u c to s ).
a
uno
m a
y u s u a l m e n t e c u a l q u i e r s i s t e m a e n l n e a o d e t i e m p o r e a l p r e s e n t a t a l e s te n
d e n c ia s d e u n a m a n e r a m s o p o rtu n a q u e l a l o g r a d a c o n u n s i s t e m a p o r lo te s . De
n u a l;
m a n e ra
c i n d e
s im ila r ,
una
d e t a b la s
s a lid a s
c i n d e c u a r t a
no
puede
un
s is t e m a
m a n e ra
n u m r ic a s .
g e n e r a c i n
p e r m it ir c o n s u lt a s
U n a fo rm a
con
c a p a c id a d e s
m s e fe c tiv a
un
U n
que
uno
s is te m a
s is t e m a
g r f ic a s
a c tu a l q u e
de
p ue de
p ro d u z c a
c o n s t r u id o
in fo r m a c i n
in fo r m a
e n fo rm a
con
un
le n g u a je
de
de
base s
d a to s
de
p ro g ra m a
m o d e r
ad hoc.
nueva
de
b e n e fic io
que
se
lo g r
con
s is te m a s e x
s lo e s t a b a n a i
lo s
www.FreeLibros.org
p e r to s c o m e r c ia le s
a lc a n c e
de
e v a lu a tiv a ,
una
es
dos
d ia g n s t ic a
la d ifu s i n
de
p e rs o n a s .
o
de
ju ic io ,
E s te
y
el
que
c o n o c im ie n t o
e x p e rto
p r e v ia m e n te
es
posee
tp ic a m e n te
h u m a n o
que
de
n a t u r a le z a
esa
c a p a c id a d
562
u s u a lm e n t e
dad
del
se
c o n s id e r a
nue vo
s is t e m a
un
de
b ie n
v a lio s o
d u p lic a r
e s to
p a ra
la o r g a n iz a c i n ; d e a q u q u e
sea
un
b e n e fic io
cu yo
v a lo r
la c a p a c i
deb e
p o d e rs e
c a lc u la r .
E n
que
un
co m o
a lg u n a
e x p e rto
p a ra
la s
de
tra t g ic o
t c n ic a s
b e n e fic io
ia
v e z fu e
s lo d e
hum ano
d e n tro
d ia g n o s t ic a r la
ta fo rm a
de
que
ta n to
c a re m o s
de
in te iig e n c ia
de
de
p e t r le o ,
p e ro
p o d ra
ser an
m s
d ic h o
s is te m a
hum ano
e x te n d e r
la s
d e ju ic io
m e c n ic o
la
de
in c r e m
COMO EXPRESAR LOS COSTOS Y BENEFICIOS DEL SISTEMA

in c u r r ie r a
de
m a n e ra
r e p r e s e n t a r e l v a lo r d e l s is t e m a
com o
de
se
m e n c io n
a lg u n o s
c o m p ra
de
aos;
s i e i g a s to
r e p a rta
lo
lo
la r g o
de
c ie r t o
m a n e ra
com o
se
lo s
de
te n d r
p e ro d o
la
de
que
to d o s
d ife r e n c ia
io s
e n tre
u s u a lm e n t e
h a ce r en
c o n t a b ilid a d
un
de
en
p e r io d o
c o s to s
de
un
c o s to s
se
d e l s is t e m a ,
y
m o m e n to
en
E x is te n
P e ro ,
e l tra n s c u rs o
( p o r e je m p lo , u n a
ia o r g a n iz a c i n
d e v a r io s
y to
se n cillo
b e n e fic io s .
hacen
p u d ie r a n
d ic ta
aos.
d e m o s t r a r o s c o s t o s y b e n e fic io s q u e
t ie m p o .
es
el
in s ta n t n e a , s e r a
g a s to s
lle g a r a
p o lt ic a s
la r g o
A s , p r o b a b le m e n t e
m a
de
a n t e r io r m e n t e ,
h a r d w a r e ) , la s
qu e se
m in a r
in s ta n t n e a
o b s e rv a ra n
pla
uso
e n t a r la
p a ra
C. 4
Si se
u t iliz a
una
b e n e fic io
d u p lic a r lo
e x p e r ie n c ia
que
(e n
de
lo s b e n e f i c io s s e
f a lla s
c o n o c im ie n to
As,
el
O b v ia m e n t e , s e r a
e x p e rto
v a lio s o
p a ra tra ta r c o n
ia
de
t e n e r r e g la s
a lg n
p o r e je m p lo ) .
de
hum ano s
pue de
en
c r e c ie n d o , id e n t if i
extender
de
c a p a c id a d
dos
d ia g n s t ic o
s is t e m a
e x p e rto s
f a lla s
c o n tin a n
a r tific ia l
un
la o r g a n i z a c i n
causa
c a p t u r a r e l c o n o c im ie n t o
o tro s ;
de
c u a n to s
unos
p o s ib le
e x t r a c c i n
de
c a p a c id a d
c u a tro
m to d o s
d e l s is t e
co m u n e s
p a ra
h a c e r e s to ;
C ada
F lu jo
R e n d im ie n to s d e
T a sa
V a lo r n e to a c t u a l ( N P V )
u n o s e d is c u te
C.4.1
d e e fe c tiv o
in te r n a
de
(e n
in g l s , R O I)
(IR R )
r e n d im ie n to
a c o n t in u a c i n .
Flujo de efectivo
Y a s e a q u e e l s is t e m a
dan
in v e r s io n e s
m u e s tre
a lo s c o s t o s ) , la a d m in is t r a c i n
e s p e ra r u n
f lu jo
p o s itiv o ;
y e c to s
g ra n d e s q u e
puede
s e r m u y d is tin to
p a ra
a lg n
desea
o b v ia m e n te ,
se
p re o c u p a r n
la
no
m s
(g a n a n c ia s
se
a c e rc a
qu e
in v e r t ir
de
e s to
exce
a n te s
p a ra
de
p ro
e l flu jo d e e f e c t i v o d e l p r o y e c t o
o rig in a lm e n te s e r e p o r t c o m o p r d i
e je m p lo , e l e q u i p o d e i p r o y e c t o p u e d e g a s
p r o y e c to s c h ic o s .
al de
d a g a n a n c ia s o
s a b e r c u n to e fe c tiv o
in fo r m a c i n
N o te q u e
que
www.FreeLibros.org
d a s y p r d id a s
ta r $ 1 0 0 ,0 0 0
en
p a ra
ia o r g a n i z a c i n .
s u e ld o s
d u ra n te
un
P or
e s fu e rz o
de
u n a o e n e i d e s a r r o llo
d e s is t e m a s ;
p e ro
de
la s
un
le y e s
s o b re
p e r io d o
s lo $ 2 0 , 0 0 0
de,
en
d e fin itiv a m e n te
pueden
im p u e s to s
d ig a m o s ,
s u s fo rm a s
ya se
pueden
aos.
de
de
v is t a
la
im p u e s to s
e ro g a ro n .
D e
de
la s
p r d id a s
m a y o ra
de
lo s
e l c o s to
un
p a ra
a m o rtic e n
se
puede
a o , p e ro
un
p u n to
de
g a n a n c ia s
v is t a
lo s $ 1 0 0 , 0 0 0
de
ia
d e f lu jo
re p o rta r
m a n e r a s im ila r , lo s b e n e f ic io s
p a r e c e r m u y d is tin to s d e s d e
el p u n to
p e r m it ir q u e
A s ,
de
la r g o
de
en
e fe c tiv o
del nue vo
s is t e m a
que
e fe c tiv o
io
g a s to s
que
se
desde
r e p o rta n
H a c ie n d a .
En
la
uno a g re g a d o .
c i n u n a t a b l a
E l e s tu d io
com o
casos,
es
c o s to s
de
a p r o p ia d o
m o s tr a r
y b e n e fic io s
p u d ie r a
ta n to
un
f lu jo
p r o d u c ir p a r a
anu al
com o
la a d m in is t r a
la s ig u ie n t e :
Proyecciones del flu io de e f e c t iv o del provecto X

A o
A h o rro s
n e to
E f e c t iv o a g r e g a d o
C.4.2
A o
A o
T O T A L
1 0 ,0 0 0
5 0 ,0 0 0
1 0 0 ,0 0 0
1 6 0 ,0 0 0
5 0 ,0 0 0
3 0 ,0 0 0
2 0 ,0 0 0
1 0 ,0 0 0
1 1 0 ,0 0 0
-5 0 ,0 0 0
-2 0 ,0 0 0
3 0 ,0 0 0
9 0 ,0 0 0
5 0 ,0 0 0
-5 0 ,0 0 0
-7 0 ,0 0 0
-4 0 ,0 0 0
5 0 ,0 0 0
5 0 ,0 0 0
G a s to s
E f e c t iv o
A o 2
Rendim iento sobre inversiones

O tra
m a n e ra
de
e v a lu a r lo s
dimiento de ia inversin.
ces o
v a lo re s
en
m is m a s
c if r a s
que
c a ra
y que
que
lo g r
se
lu e g o
usan
lo
en
g a n a n c ia
de
p o r c e n ta je ,
t r m in o s
dei 4 5
p o r c ie n to .
v e n d i
b e n e fic io s
to d o
e l e je m p lo
una
do en
c o s to s
S u p o n g a , p o r e je m p lo , q u e
de
$ 5 0 ,0 0 0
e s to
de
d e l s is t e m a
in v ir t i
p o r $ 1 6 0 ,0 0 0 .
flu jo
s o b re
s ig n if ic a
de
un a
que
(N o te
e fe c tiv o
de
r e n d im ie n to
ren
c a lc u la r e i
que
en
b ie n e s
s ta s
a n t e r io r . )
in v e r s i n
su
es
$ 1 1 0 ,0 0 0
E s to
ra
la s
son
s ig n if i
$ 1 1 0 ,0 0 0 ; e x p re s a
de
la
in v e r s i n
fu e
sue na m e jo r q u e in v e r t ir d in e r o e n u n a c u e n ta d e a h o r r o s . P e r o , e s p e r e
e je m p lo a n t e r i o r , l a g a n a n c i a n o s e o b t u v o a l f i n a l de l p r i m e r a o ; d e h e c h o ,
t a r d c u a tro a o s .
A s q u e e s t o h a c e q u e e l r e n d i m i e n t o d e la in v e r s i n s e a a p r o x i
m a d a m e n te d e l 11 p o r c ie n t o a n u a l.
A u n e s t o re s u lta e n g a o s o , s i n e m b a r g o , p o r
que n o t o m a e n c u e n t a e i v a l o r a c t u a l d e l d in e r o f u t u r o .
E s to s e d is c u tir a
E s to
...e n
el
c o n t in u a c i n .
C.4.3
Valor actual neto

S i a lg u ie n
de
c u n to
n o lo s
le
d ie r a
$10 0
p u e d e c o m p ra r c o n
r e c ib ir
s in o
h a s ta
hoy,
e sa
d e n tro
s a b ra
cual
c a n t id a d .
de
un
es
P e ro
ao?
E s to
su
v a lo r :
c u n to
se
te n d ra
v a ld r n
cono ce
com o
una
$10 0
b ue na
si
id e a
sabe
que
e l v a lo r a c tu a l o
www.FreeLibros.org
el v a lo r d e s c o n ta d o .
m o la c a n t i d a d
que
E i v a lo r a c tu a l d e l d in e r o
t ie n e
que
in v e r t ir
hoy,
con
que
r e c ib ir
lo s
in te r e s e s
un f u t u r o s e
a c tu a le s , p a r a
en
d e f in e
co
p o d e r
lie -
564
CALCULOS DE COSTO/BENEFICIO
gar
la
c a n t id a d
e s p e c if ic a d a .
d e a p r o x im a d a m e n te
En
(q u e
g e n e r a l,
lla m a r e m o s
P =
A s ,
$ 9 5 .2 4 , c o n
si de se a m o s
F ), d e n tr o
F / <1 +
de
e l v a lo r
a c tu a l
de
lo s
$10 0
d e l p r x im o
ao
es
in t e r e s e s d e l 5 % .
c a lc u la r e l v a l o r
podem os
a c tu a l d e
n aos,
a lg u n a
c a n t id a d
u s a r la s ig u ie n t e
de
d in e r o
f r m u la :
i) n
don de
i e s e l in te r s .
pue de
c a lc u la r c o m o
el
A s , e n
s ig u e
e je m p lo
( s u p o n ie n d o
a n t e r io r , e l v a lo r a c t u a l d e
lo s
b e n e fic io s
se
u n in te r s d e l 5 % ) :
C lculos d e valor actual para el provecto X

1
A o
A h o rro s
V a lo r a c tu a l
C om o
c ie ro
dei
p ue de
d e b e m o s d a rn o s
n e ra
s lo
que
lo s
v a ld r
nal del se g u n d o
E s to
e n tre
el
p ro y e c to
5 0 ,0 0 0
1 0 0 ,0 0 0
1 6 0 ,0 0 0
9 ,0 7 0
4 3 ,1 9 2
8 2 ,2 7 0
1 3 4 ,5 3 2
es
hace
m s
re p re s e n ta
a
m enos
P a ra
im p r e s io n a n t e
se r an
m s
e l r e n d im ie n to
r e a lis ta s ,
que
hoy,
u n c o s to
d e fin ic i n
la
a c tu a l d e
m ucho
r e a lis ta .
lo s c o s t o s a f u t u r o s e d e b e n d e s c o n t a r d e
A s c o m o u n b e n e fic io d e $ 1 0 ,0 0 0 a l f in a l d e l
d e ia m i s m a m a n e r a u n g a s t o d e $ 1 0 , 0 0 0 q u e
c u e n ta
lle v a
nos
v a lo r
de
1 0 ,0 0 0
p e ro
ao
T O T A L
b e n e fic io s .
$ 9 ,0 7 0
A o
v e r, e s to
p ro y e c to ,
Ao 3
A o 2
lo s
m u e s tra , e s to
de
b e n e fic io s
lle v a r a
a c tu a l d e s o la m e n te
valor actual neto

y
de
a lo s s ig u ie n t e s
la
fin a n
e m b a rg o ,
m is m a
se g u n d o
se
hag a
m a
ao
a l fi
$ 9 ,0 7 0 .
un
e l v a lo r a c tu a l d e
s in
lo s
p r o y e c to : la
c o s to s .
d ife r e n c ia
P a ra
n u e s tro
c lc u lo s :
C lculos de va lo r actual neto del provecto X

A o
A h o rro s
ao 3
T O T A L
1 0 ,0 0 0
5 0 ,0 0 0
1 0 0 ,0 0 0
1 6 0 ,0 0 0
9 ,0 7 0
4 3 ,1 9 2
8 2 ,2 7 0
1 3 4 ,5 3 2
3 0 ,0 0 0
2 0 ,0 0 0
1 0 ,0 0 0
1 1 0 ,0 0 0
2 7 ,2 1 1
1 7 ,2 7 7
8 ,2 2 7
1 0 0 ,3 3 4
A o
A o
V a lo r a c tu a l d e
lo s b e n e f i c io s
G a s to s e n
e fe c tiv o
5 0 ,0 0 0
V a lo r a c tu a l d e
lo s c o s to s
4 7 ,6 1 9
V a lo r a c tu a l n e to
www.FreeLibros.org
a c u m u la tiv o
-4 7 ,6 1 9
-6 5 ,7 6 0
-3 9 ,8 4 5
3 4 ,1 9 8
3 4 ,1 9 8
C A LC U LO S DE C O S T O /B E N E F IC iO 565
A s ,
e l v a lo r n e to
r e c ib ir
a p e ra m o s
C.4.4
d e c ir ,
el
de 4 ao s es de
hoy
v a lo r
de
g a n a n c ia q u e
la
$ 3 4 ,1 9 8 .
interna de rendim iento
Tasa
La
es
a c t u a l d e l s is t e m a ,
d e l s is t e m a a l c a b o
tasa interna de rendim iento
e s a n lo g a
a l p o r c e n ta je
que
a n u n c ia n
lo s
ban
cos, l o s f o n d o s d e m e r c a d o y o t r a s in s titu c io n e s f i n a n c i e r a s a c e r c a d e s u s c u e n t a s
de a h o r r o y d e m s o p o r t u n i d a d e s d e i n v e r s i n . L a t a s a i n t e r n a d e r e n d i m i e n t o (IR R )
se d e f i n e c o m o l a t a s a d e i n t e r s q u e s e o c u p a ra p a r a g e n e r a r l o s a h o r r o s c a d a a o
(es d e c i r , l o s b e n e f i c i o s d e l s i s t e m a , q u e y a h e m o s i d e n t i f i c a d o ) d a d a u n a i n v e r s i n
jguai a l o s g a s t o s e n e f e c t i v o q u e h e m o s i d e n t i f i c a d o . E n e l e j e m p l o a n t e r i o r , p i e n s e
que s e i n v i r t i u n t o t a l d e $ 1 1 0 , 0 0 0 e n u n a c u e n ta i m a g i n a r i a d e a h o r r o s d u r a n t e u n
p e ro d o d e 4 a o s . L a p r e g u n t a e s :
Q u t a s a d e i n t e r s h a b r a q u e t e n e r p a r a r e ti
rar u n t o t a l d e $ 1 6 0 , 0 0 0 p a r a e l f i n a l d e l c u a r t o a o , sin dejar dinero en ei banco?
C o m p a ra n d o e s to c o n
n is tr a c i n p u e d e
S u p o n g a
ao
fu tu ro s s e
que
2,
1, e l a o
se
d e s c r ib e n
de
lo s
N com o
C 1 ,
C2,
in te r s
d e f r m u la
f u n c io n e s
d iv e r s id a d
de
p ro g ra m a s
P C
no, p i d a a y u d a
b e n e fic io s
de
In v e r s io n e s
..., C N .
fu tu ro s
A s , d e b e
s e n c illa
que
se
in v e r s i n .
lo g r a r n
t a m b i n
r e s o lv e r s e
que
de
B - ,/(1
se
pue da
c u a tro
d e
+ )1 +
B 2 / ( 1 + i) 2
la
al ca b o
que
lo s
s ig u ie n te
o e n c o m p u ta d o ra s
de
... +
del
g a s to s
f r m u la
B N / ( 1 + i) N
r e s o lv e r f c ilm e n te
fu n c io n e s .
IR R
S in
in t e g r a d a s ;
en
e m b a rg o ,
a d e m s,
e s p e c ia l p a r a e s t e t i p o
g ra n d e s .
Si n o t i e n e t a l e s
fin a n z a s o d e c o n t a b i l i d a d .
a p lic a c i n
a l d e p a rta m e n to
d iv e r s a s , la a d m i-
buena
hecho, una
B 1 , B 2 , ..., B N ; s u p o n g a
... + C N / ( 1 + i ) N
e s e l t ip o
de
s is te m a e s,
i:
ta o c o n u n a c a lc u la d o ra
ra s e s p e c ia liz a d a s c o n
basadas e n
de
u n a s e r v ille
hay
c a lc u la d o
e x is te
u n a
a n lis is
g ra n
fin a n c ie r o ,
h e r r a m ie n ta s
ia
m a
ANALISIS D E RIESGOS
C.5
C o m o
cabe u n
p a rte
a n lis is
debe h a c e rlo
c e rte z a
posibilidad
La
de
de
de
io s c lc u lo s
r ie s g o s
to d o s
se
lo g r a r n
Las
cosas
que
estim ados.
com o
la t a s a
C 1 /( 1 + ) + C 2 / ( 1 + i ) 2
no
p r im a r ia y o t r a s t a s a s d e
d e s c r ib e n
..., y e l a o
p o lin o m ia l p a r a
E s te
la t a s a
d e te r m in a r s i e l n u e v o
de
que
sean
i cosas s a lg a n
c fic a m e n te ,
m al
m odos.
lo s
de
La
ser
e s ta r
c o s t o - b e n e f ic io , d e b e
nuevo
s is t e m a .
ra z n
b e n e fic io s
pueden
de
S i
e s to
e s t im a d o s ,
m e jo r e s :
p e ro
la
es
d is p u e s to
que
no
ni q u e
se
r e s u lt a
de
no
le
lle v a r a
p id e u n o ,
podem os s u p o n e r c o n
in c u rrir e n l o s g a s t o s
m a y o r p re o c u p a c i n la
p e o re s .
d u ra n te e l
q u e rr n
s ig n ific a tiv a m e n te
fueran b a s t a n t e m
del
sa b e r
m a y o re s ,
d e s e a r
sa b e r
p ro y e c to ; y d e s e a r n
b a jo
qu
as com o
c o n d ic io n e s
la s
la s
sa b e r
io s
c o n d ic io n e s
c o n s e c u e n c ia s
cules
c o s to s
b a jo
pueden
e s t im a d o s
la s
c u a le s
de
que
la s
ir m a l. E s p e
p o d ra n
lo s
ser
b e n e fic io s
www.FreeLibros.org
e n o re s d e
lo e s t im a d o .
566
C A LC U LO S DE COSTO/BENEFICIO
C m o
b ilid a d e s ;
pueden
u s te d
lo s c o s t o s
le
to c a
m a y o re s
se r
id e n t if ic a r
lo s
de
lo e s t im a d o ?
r ie s g o s
H e
e s p e c f ic o s
a q u a l g u n a s p 0 s .
in h e r e n t e s
propio
su
p ro y e c to :
El v e n d e d o r
El
e q u ip o
o tro s
del
p ro y e c to
usad a
s o b re to d o
P o d ra
lis to
q u e b ra r.
p u d ie r a
p e rd e rs e
p a ra
su
p a ra
ja m s
si
s u fr ir
c a m b io
un
la
P ueden
e l p ro y e c to
se
h a b a
s in o
su
s u r g ir p r o b le m a s
p u d ie r a
e x tre m o ,
e n fe rm e d a d
por
h a s ta
e je m p lo ,
el 2
in s ta la c i n
p o lt ic o s
n o f u n c io n a r c o m o
de
el
s is t e m a
e n e ro ,
lo s
anun
p o d ra
c o n tra to
con
estar
no
r e g la m e n to s
siguiente 1 d e
el
h a s ta
o de
se
a n te s .
usado
o p o r tu n id a d ;
in s ta la c i n
b e rn a m e n ta le s im p id e n
p o d ra
p r o b le m a s .
L a te c n o lo g a
c i ,
d e l h a rd w a re
gu
e n e ro .
s in d ic a t o s , c o n tr a tis
ta s e x te rn o s , e tc .
Ei
e q u ip o
del
a p lic a c i n ,
ie v e n
que
p ro y e c to
o tra s
p o d ra
no
d e f ic ie n c ia s
a u n a p r o d u c t iv id a d
e c o n m ic a s o
C ir c u n s ta n c ia s
te n e r
c o n o c im ie n to
el
( p r e p a r a c i n
n e c e s a r io
e x p e r ie n c ia
d e la
in a d e c u a d a s )
m e n o r a la e s p e r a d a .
de
n e g o c io s
t u r b u le n ta s
p o d ra n
o b lig a r
c a n c e la r e l c o n t r a to .
P uede
s u r g ir u n a
que
o t r m it e s
D e
aqu
m a n e ra
a lg u n a s
s im ila r ,
lo s
de
g a s to s
o c u lto s , p o r e je m p lo , c o s t o s
el
s is te m a
e s t im a d o s
p o d ra n
n e c e s a r io s e n
b e n e fic io s
extras
a n t e r io r .
no
m a te r ia liz a r s e .
He
r a z o n e s p o s ib le s :
Los
u s u a r io s
m s
d iv e rs id a d
n o fu e ro n
d if c il d e
o p e r a c io n a le s
lo
de
p a r t ic u la r
im p o r t a n c ia
en
el
de
s e n t id o
P o d ra n
T al vez
no
p o d ra n
e s p e r a d o , lle v a n d o
una
o c u r r ir
d e m o ra s
b e n e fic io s
m a y o r p r o d u c t iv id a d
m e jo r a s
e l s is t e m a
lo s
e n c o n tra r
a
no
e s p e ra d a s
p ro d u z c a
m s
en
el
e
uso
del
sistema
(E sto es
nue vo
in te r r u p c io n e s .
d e l s is t e m a
se
h a b a n
p r e v is t o
d e l u s u a r io .)
ia
p a rtic ip a c i n
c lie n t e s , m s
en
p e d id o s ,
el
m s
mercado.
n e g o c io s
o m s r e n d im ie n to s .
El s is te m a
p o d ra
n o c o m p o r ta rs e
s a r t a n ta s t r a n s a c c io n e s
El
v a lo r d e
la
nue va
por
com o
segundo
in fo r m a c i n
se
e s p e r a ; p o r e je m p lo , n o p ro c e
com o
d is p o n ib le
s e e s p e ra b a .
g r a c ia s
al
s is te m a p o d ra
re
www.FreeLibros.org
s u lta r n o
te n e r b e n e fic io s ta n g ib le s .
C A LC U LO S DE COSTO/BENEFICIO 567
P a ra
tra ta r e s to s
escenario p o s i b l e , e l m
sea e s t o : n o t i e n e c a s o
in n e c e s a r ia m e n t e
aunque
n a d ie
r ie s g o s , a
e jo r y
e n g a a rs e
o p t im is t a s
e s p e ra
que
m in is tr a c i n e n t ie n d a c u a n
C o m o
c n s a b e
de
n o ta
f in a l
ia
r ie s g o s t c n ic o s
r e s u lt a
se r b ue na
S e r
m e jo r e n tr e
s m is m o y a
re s p e c to
m a la s s e
a c e rc a
m uchos m s
s it u a c i n
del
lo s
c o s to s
p o d ra n
a n lis is
de
u s te d
r ie s g o s :
es
con
D e
r e a lis ta
m a n e ra
im p o r t a n t e
veces
m uchas
E llo s
a
p r e c is o
s im ila r ,
q ue
la a d
cosas.
( p o r e je m p lo , u n a
c o m u n ic a r n ;
c o n s id e r a r e l p e o r
m s
b e n e fic io s .
o c u rra ,
p o n e r la s
in til a l s is t e m a ) .
lo s
d e a
administracin
la
del peo r caso
r ie s g o s q u e
su c o m p a a y o t r a , q u e v o l v e r
gos, y a m e n u d o n i s i q u i e r a s e
los
m enudo
e l e s p e ra d o .
u s te d
pue de
lo
la
a d m in is t r a -
p o t e n c ia l f u s i n
e v a lu a r d ic h o s
n e c e s ita n p a ra
e n tre
rie s
e v a lu a r
d e l p ro y e c to .
www.FreeLibros.org
APENDICE
D)
D.1
AUDITORIAS
INSPEOCJO
INTRODUCCION
E s te a p n d i c e p r o p o r c i o n a una
inspeccin ( Walkthrough). P u e d e
ficaciones q u e s e d e s a r r o l l a r o n d u r a n t e
v is i n
com o
b a rg o ,
p a ra
u s a r e s te
h a c e n , q u i n
p a r t ic ip a e n
D e spus
c io n a l.
w a rd
D os
de
D.2
t e r m in a r
(N u e v a
Y o rk :
es
y G e r a ld
una
t c n ic a
de
qu
a n lis is
es
una
c o n o c id a
l a s e s p e c i
in s p e c c i n ,
S in e m
por
qu
se
p r o c e d im ie n to s .
a p n d ic e
puede
n e c e s it a r
in fo r m a c i n
a d i
Structured Walkthroughs, 3 a e d i c i n , d e E d
N P r e s s , 1 9 8 5 ) y Technicai inspections and
W e in b e r g
( B o s t o n : L itt le , B r o w n ,
1 9 7 7 ).
que
ade m s
que
usa
se
de
la
r e v is i n
u s u a r io s ,
puedan
im p lic a
una
O b v ia m e n t e ,
e s ta
d e l p ro y e c to ,
e s t n
vez
ta l
u s u a lm e n t e
o tro s
de
d e s a r r o llo
de
s is t e m a s ,
es
de
la
la
e s t n
una
t r a b a ja n d o
p e rs o n a l d e
n o r m a le s , n o
organizacin
q u e rr
la
in s p e c
posibilidad
f a c t o r im p o r t a n t e
lo s
de
con
o p e r a c io n e s
en
in c lu y e
el que
E s to
usted,
y o tro s
e s t tra
a s u j e f e , a l je
la s
de
que
r e v is a r
e s t
d e t a lle s t c n ic o s
o fre c e r
e n ta le s
con
u s u a r ia .
o p o r tu n id a d
e s p e c if ic a c io n e s
in v o lu c r a d o s c o n
te n g a n
un
la s
que
a s p e c to s d e l p ro y e c to
c o n d ic io n e s
e m in e n te
m enos
no
a n a lis t a s
d is e a d o r e s ,
vicepresidente
g e n te
P e r o g e n e r a lm e n te
p o lt ic a
in d u s t r ia
diversos
en
in c lu y e n d o
gas
u s te d ,
in s p e c c i n , b a jo
d e l d e p a rta m e n to , o a !
de
la
p ro g ra m a d o re s ,
e s t a r in v o lu c r a d o s
b a ja n d o . P e ro
a s p e c to s
en
e l t r m in o
revisin de algn producto tcnico hecha por un grupo de colegas.
una
s ig n if ic a
La
son:
sabe r
son los
le e r e s t e
Y O U R D O
D a n ie l F r e e d m a n
C o m o
to
de
p o s ib le s
de
QUE ES UNA INSPECCION?
c i n
fe
de
e l p ro y e c to
n e c e s it a
e lla s , y c u le s
r e fe r e n c ia s
Y o u rd o n
Revews,
c o n c e p to
breve
g lo b a l
e n c o n t r a r t il h a c e r a u d it o r a s d e
que
s u g e r e n c ia s
r e v is io n e s d e a lto
diversos
t r a b a ja n d o .
lo s
cole
d e t a lla d a s ,
p o d e r.
Es
www.FreeLibros.org
n o s ig n if ic a
que
e s ta s
r e v is io n e s s e a n
m a la s
568
n i ir r e le v a n te s , s in o
s im p l e m e n t e que
A U D IT O R IA S E IN S P E C C IO N E S 569
diferentes
s0n
jg
la s
mitir el a c c e s o
interpondr l a
de
N o te
q ue
puede
d is c u te n
un
in s p e c c i n
la
en
e s te
a p n d ic e .
de
e s te
tip o
g ru p o
r e s u lt a r
se r
haber
d is tin to s
t ip o s
de
es
E l p e lig r o
que
e v a lu a c i n
un a
p e r
de
del
se
r e n d im ie n to
producto.
r e v is i n t c n ic a d e u n
I n s p e c c io n e s d e
a n lis is
d is e o
c d ig o
p ru e b a s
e l te m a
a n a lis t a s , j u n t o
de
e s te
lib r o
a n lis is .
de
con
de f l u j o d e d a t o s ,
dos, e n t r a d a s d e l
a u d it o r a s
o tra s
e s e l a n lis is
fin e s
P a ra
p e rs o n a s
in s p e c c io n e s
se
d ia g r a m a s
de
e n t id a d - r e la c i n ,
d ic c io n a r io
de
d a to s
de
s is t e m a s , n o s
en
un
p ro
c o n c e n tr a r e m o s
s ig n ific a
p r c t ic o s , e s t o
in te r e s a d a s ,
lo s p r o d u c t o s t c n i c o s d e s a r r o l l a d o s
re n e n
p a ra
d ia g r a m a s
e s p e c if ic a c io n e s
un
r e v is a r
de
de
que
g ru p o
t r a n s ic i n
p ro c e s o s ,
de
d ia g r a m a s
e s ta
to
de
es
d e c ir ,
p o r e l a n a lis t a .
POR QUE HACEMOS INSPECCIONES?
D .3
La
sea
se
tp ic o :
la s i n s p e c c i o n e s
dos
la
m s que
D ado que
en
que
p o lt ic a , o
una persona,
yecto
a u d it o r a s
la
ra z n
p r in c ip a l
p o s ib le .
cho m s
C o m o
b a ra to
se
es
e n c o n tra r
m e n c io n
e n c o n tra r y
de e s p e r a r h a s t a
que
e rro re s
ta n
a n te r io r m e n t e
e lim in a r
e l p ro d u c to
se
e rro re s
haya
r p id a
en
ta n
e s te
p ro n to
te rm in a d o
e c o n m ic a m e n te
lib r o ,
com o
se a
e n v ia d o
p o s ib le ,
la
com o
es
en
m u
lu g a r
s ig u ie n te
e ta p a
de d e s a r r o l l o .
E x is te n
p e rs o n a
que
o tra s
m a n e ra s
p ro d u c e
p a ra t r a t a r d e
h a c e r la s c o s a s .
do u n
de
d a to s
d o c u m e n to
com p utad ora ,
c o n o c e d o re s a
O tra
e n c o n tra r
D FD
p a ra
p a ra
de
p e rs o n a s
e n c o n tra r
en
no
es
h a lla r e r r o r e s
de
A;
m s
de
ya
sea
de
b a s ta n te
que
o
un
c o le g a s
en
c a ra
p r o p io s
se
la
m is m o
e x p e r ie n c ia
m a n e ra
e n c o n tra r s u s
g ru p o
e s t
el
de
e rro
le y e n
p ro g ra m a
de
in te r e s a d o s
r p id o .
e s t a c i n
a g ra n d e s
en
in s p e c c io n e s :
r e v is a r lo
tip o g r f ic o s ,
U n
usar una
s in ta x is
la s
y ao s
su ce d e
e rro re s
de
pue de
se r una
pueden
E s to
e n c o n tr a r lo s
e l a p n d ic e
D F D )
com n
s u e le
s u t r a b a jo .
e n c o n tra r e rro re s
s e d is c u te
un c o m p i l a d o r p a r a
e s to
a d e m s
un
e l s e n t id o
que
la s
e rro re s
e je m p lo ,
e n c o n tra r e rro re s .
m enudo pue den
m a n e ra
que
P e ro
e s tu d ie n
te x tu a l
un
(p o r
d ic ta n
M uchas ve ce s
im p o r ta r c u n to
ta d e l t i p o
de
p ro d u c to
e n c o n tr a r e rro re s .
cam po d e l p ro c e s o
re s , s i n
el
un
ra s g o s
de
t r a b a jo
p a ra
a n a lis
e s a n lo g o a
e s to
p ro g ra m a , e n
lu g a r d e
usar
r e v is a r a
www.FreeLibros.org
m a n o e i lis t a d o
p u e s to
trar.
s e la
P e ro
del
p a ra
as com o
p ro g ra m a .
S i t ie n e
id e n t if ic a r to d o s
io s
u n c o m p ila d o r n o
una
e s t a c i n
e rro re s
de
de
t r a b a jo
s in t a x is
e n c u e n tra to d o s
que
de
sea
lo s e r r o r e s
en
a n a lis t a ,
capaz
un
de
por su
encon
p ro g ra m a
de
570
A U D IT O R IA S E INSPECCIONES
c o m p u ta d o ra ,
c i n ) , d e
to d o s
la
io s
e rro re s
g u e s ie n d o
D e
p a ra
que
( p o r e je m p lo ,
la s
en
un
hecho, una de
pueda
p e rs o n a s
un
D F D
e n c u e n tr a
de
la s
la s c o s a s q u e
pue den
lo s
h a ce r m uy
de
de
b ie n .
m e c n ic a s
e s t ilo
A s ,
que
cuan do
S e e s c o g ie r o n
d ib u j
S e
La
e je c u
e n c o n tr a r
in s p e c c i n
e s t a c i n
s i
trabajo
algo
de
p ro d u c to s ; e s to
lo s
S e
de
r e v is o r e s
es
hum anos
exa
p la n te a r p r e g u n ta s c o m o ;
H a y d e m a s ia d a s b u r b u ja s e n e s te d ia g r a m a ?
de
m a n e ra
e l d ia g r a m a
r e a lm e n t e
t ie m p o
d is p o n ib le s .
una
lo s
de
de
n o p re te n d e
e s p e c if ic a c io n e s .
p r o b a b le
el
s o b re
a n a lis t a
es poco
c o m e n ta r
l g ic o s
e rro re s
d e t r a b a jo
m o d e lo s
t il p a r a
h a ce r es
pueden
e s t a c i n
c o n ju n to
u n c o m p le m e n to
a n a lis t a
m in a n
no
manera una
m is m a
s ig n if ic a t iv a io s n o m b r e s d e
de
m a n e r a e s t tic a ?
a g ru p a ro n
lo s
f lu jo s
de
d a to s
de
E s p r o b a b le
que
le a e l d ia g r a m a , o e s p r o b a b le
lo s p r o c e s o s ?
s e c o n fu n d a
m a n e ra
que
e l u s u a r io
d e b id o
s ig n if ic a t iv a
de
a l?
un
n iv e l
o tro ?
S e a g ru p a ro n
la s
fo r m a r b u r b u ja s d e
A d em s,
nes
s i n
con
un
p o r
n o v a to s
s o b re
g ru p o
el
a n lis is
que
m enos
con
o tro s
de
de
d e i e q u ip o
p u e s to
g u ro
e x is te n
e l e n fo q u e
la s
c o le g a s
una
c o n t in u a r s u
es
a
s is te m a s , o
lo s m i e m b r o s
(a
p a r t id a
p e lig ro
S c o n s id e r a
p o r a c i n )
puede
si
del de
E n
sus
e s to
in d iv id u o
m a n e ra
n o ta c i n
de
de
de
U n
para
in te lig e n te
la s org an izacio
de revi
p ro c e s o
e n se a r a
lle g a n
la in s p e c c i n
lo s
s o b re
m ie m b r o s
l a a p lic a c i n ,
d e flu jo
d ia g r a m a s
r e v is i n
in o p o r tu n a
lo s
se
D F D
o p o n e
el
es q ue
de
d a to s .
f a m ilia r iz a r s e
s e c o n v ie r te
d e l p ro d u c to r;
com o
ia
p ro d u c to r p u e d e
e l p ro c e s o d e
a lg u ie n
m s
Y
o
e n un se
deb e
poder
de
su
p r o p ie d a d
de
(y
es
p e rs o n a s .
h a b e r d is c u s io n e s
n o c i n
e s ta r d e a c u e r d o c o n los
u n a i n v a s i n d e s u p r i
n o c o m o un b i e n d e la c o r
no
in s p e c c i n
m o s tr a r lo s a o t r a s
c o le g a s , p u e d e
S i s u s e n t id o
v io le n t a s
c a p a c ita c i n y
d u ra n te
s e g u ro ,
d e l e s tilo
la
in s p e c c i n .
pue de
re ch a za r el
in s p e c c i n .
g e n e r a l,
ya
la
o b t ie n e n
y s e g u ro .
y v ie jo s ) d e t a lle s
n tim a m e n te ),
m enudo
s e r re n u e n te
e l p r o d u c to r
e q u ip o
n o r m a lm e n t e
a n t ig u o s
d e l g ru p o
in e s p e r a d a
de
v a c id a d .
c o n c e p to d e
m a n e ra
la b o r .
E l g ra n
lo s
s o b re
b e n e fic io s , y c o n s id e r a r q u e t o d o
d ifie r e
que
e x c e le n te
una
( a l ig u a l q u e
e l p ro d u c to
c o n tra
b e n e fic io s
in s p e c c io n e s : c a p a c it a c i n
de
to d o s
e le m e n ta le s d e
a c t iv id a d e s
n iv e l s u p e r io r ?
e s t
la s
a c e p ta d a
e n tie n d e
que
t ie n e n
o p e ra n d o ;
u n a fa lla
s e r ia
en
o
x ito
un
en
un
p ro y e c to
un e rr o r
en
a m b ie n te
tp ic o , e s to
su
t r a b a jo
donde
ia
s ig n if ic a
puede
n o c i n de
que
cada
p o n e r e n p e li
www.FreeLibros.org
g ro
el
tr a b a jo
x ito
es
de
to d o
el
m o tiv o v lid o
p ro y e c to ,
de
lo
cual
p r e o c u p a c i n
s ig n if ic a
p a ra
que
e l p o te n c ia l d e
lo s d e m s
e rro re s
m ie m b r o s d e l e q u ip o .
d e su
Para
[t s a c e r c a d e
ia n o c i n
g u lte e i c l s i c o
lib r o
(Nueva
U na
in s p e c c i n
de
un
se le o c u r r e
vencido d e
(o a l a s i g u
se
R e in h o ld ,
lla m a d o s
e q u ip o s
de
s in
e g o , con-
G e r a id
W e in b e r g
1 9 7 1 ).
ie n te
T m ese
c o n el
incom pletas
e ta p a
en
2)
D FD
en
nal d e l
con
e s te
caso
la s
cundo h a y
4 ),
que
es
5) o
en
ia s e r o
tr iu n fa n te
p ro n to
6 );
3 );
la
cer c a m
aveces
b io s , a
ra z n
in v e r t id o
en
la s
e ta p a s
m enos
ni e s o s ).
la e l i m i n a c i n
hecho de
de
e rro re s
Y , fin a lm e n te , s e
basta
c ie r t o
su
que
se
una
tra te
de
r e c o r d a r ia
en
ia
p a ra
se
la
es
c u n to
en
lo
E l p ro -
r e le v a n te
tra z a r
v a r ia s
una
del D F D
8)
d e l s is -
v e r s io n e s
v e r s i n
en
r e la
u n a e s t a c i n
e n tre g a r e l
c o n c lu y
te n e r
la
una
s in
de
c u n to
(e s
de
ta rd e .
a po yo
d e c ir ,
en
de
una
P r e c is a m e n te
a u to m a tiz a d o
a n a lis t a
e ta p a
que
se
que
e s t
p a ra
es
que
el
ha
in c lu s o
q u e re r
g ru e s o s
(e
d e m a s ia d o
t ie m p o
r e v is i n
pud o
lo
ha
a n te s .
la s p e r s o n a s
que
ta rd a
com o
e rro re s
lo s e r r o r e s
a ltr u is t a s
s ir v a
u s a r lo .
e l p ro d u c to
de
de
al
lo
e fe c tiv a
e l a n a lis t a t ie n e
t r a b a jo
c u e s ta
de
que
m a n e ra
f i
f in a l
a n te s
in s p e c c i n
d e m a s ia d o
de
D F D
ta re a
hace r de
que e l e q u ip o d e
si l o h u b ie ra v i s t o
p s ic o lo g a
de
hace r
el p ro d u c
ilu s t r a r e s to .
h a b e r d e d ic a d o
b sq ueda de
in d e p e n d ie n t e m e n t e
y;
c o r r e c c i n
s ie n d o
que
A ; 6 ) e lim in a r e r r o r e s
pue de
e s t a c i n
r p id a y e c o n m ic a
debe
se
a po yo
ego
3)
d e t a lle s
in s p e c c i n
de su
d e l p ro d u c to ,
m s
la
p r e f e r ib le
d e t r a b a jo ; 7 ) im p r im ir la v e r s i n
7) y 8)
de
p a ra
D F D ;
lo s
d e p e n d e r
e l p ro d u c to r p u e d e
p r o p io t ie m p o
g ra d o ,
e v ita r
d e m a s ia d o
T a m b i n ,
m a n e ra
s a ri: i n v i e r t e n
de
com o
a l c o n s u m id o r
p a ra
v ie jo s ; 4 ) d ib u ja r
que
p u e d a te n e r d ic h o
p a ra
un
in s p e c c i n
in s p e c c i n
d a to s
g r a f ic a d o r
de
g e n e r a l, e s
com o
el
con
a b s o lu t a m e n te
1 ) d is c u tir e l r e a
e l a p n d ic e
un
E n
de
s o b re s
en
d e m a s ia d o
2)
flu jo
e s t
d u ra n te
p o r p r im e r a v e z
e l a u t o r p u d o h a b e r e lim in a d o .
la e s t a c i n
1 ),
r p id o s e
p rin c ip a l
p ro d u c to r h a b r
que
m o m e n to
en que
s e r e n tre g a d o
n o ta n to
s o b re
o en
d is c u tid o
d is p o n ib le
p o r fin
p a ra
p e ro
p a p e l; 5 ) m e t e r
im p r e s o r a
que
lis t o
m e n t a lm e n t e
s e r v ille t a s
d e l t ip o
de
eopeiar c u a t r o d a s p a r a t e n e r a c c e s o a
com partiendo c o n o t r o s 2 7 a n a l i s t a s ? ) , y
La
c a s i c u a lq u ie r
e l m o m e n to
d e s a r r o llo ) .
it e r a c io n e s
v is u a liz a r
hace r una
q u ta n
de
d ia g r a m a
e x c la m a c i n
e ta p a s
en la s e t a p a s
te n g o , d e
una
una
en
y
p o s ib le ,
sea
u n a h o ja d e
a n a lis t a
con
un
en
e r r a m ie n ta
en
com o
v a r ia s
de t r a b a j o d e
taxis c o n l a h
En
en
lle n o d e e r r o r e s t r i v ia l e s
h a r
un
te r m in a d o
e l p ro c e s o
p ro n to
u s u a r io ;
t iv a m e n t e l i m p i a
a lg o
ca b o
e l m o m e n to
e s t
p o r e je m p lo
de
D F D
lle v a r a
h a s ta
e l p ro d u c to
o r tp ic a m e n te
| jefe j u n t o
j previsto.
pue de
a l p ro d u c to r,
qu e
to e s t i n c o m p l e t o
ber
lo s
p r o d u c to t c n ic o ; e s d e c ir d e s d e
uri a i n s p e c c i n t a n
de
to d o
CUANDO CONDUCIR UNA INSPECCION
ijesarroio
<iu
e q u ip o s , s o b r e
N o s tra n d
y o rk : V a n
p,4
de
The Psychology o f Computer Programming,
m is m a s
re v i-
qu e
d e o tr o , y s e n t ir n
d ig a n
s e r.
D e b id o
e s to
e llo
www.FreeLibros.org
lio s e l e s d e b e
se m o s t r a r u n
m o s tra r u n
p ro d u c to
in c o m p le t o
p r o d u c to t e r m in a d o , c o n g e la d o
y m a l h e c h o ; p e ro ta m p o c o
y p e rfe c to .
se
le s d e -
572
A U D IT O R IA S E IN S P E C C IO N E S
S i va
bueno
m o
da
n o e n c o n tr .
qu
D.5
S i,
n o e s t
q u e
a lg n
lo s re c i n
fo r m a lis m o
p e c c i n
su
t ie m p o
a lg o
ro le s
de
p a p e le s
d is tin ta s
U na
P e ro
o e s tru c tu ra
e s tru c tu r a d a .
en
hace n
d e s c r it o s .
e l c o n ju n to
de
de
h o ra
h a c ie n d o
ROLES E N UNA INSPECCION

M uchas
c i n
e s t
c o m e n ta r, e s
p r x im a v e z
en l a r e v i s i n d e l D F D d e un c o le g a , es
til a l e n c o n t r a r un e r r o r q u e e l p ro d u c to r misp o r o t r o l a d o , p a s a m e d ia h o r a v i e n d o u n p r o y e c t o s i n h a l l a r n a
n a t u r a l q u e v e a e l e s fu e rz o c o m o un d e s p e r d i c i o d e tie m p o y |a
t a n d is p u e s t o a p a r t ic ip a r en u n a in s p e c c i n .
in v e r t ir u n a
que
sa b e r
en
la
m uchos
que
s in
m a y o r f o r m a lis m o
que
e n c o n tr a d o
r e v is i n ; d e a q u i p r o v ie n e
c a r a c te r s tic a
fo r m a le s
han
en
e i t r m in o
p re p a ra
in t r o d u c ir
com n
ins
in s p e c c i n e s t r u c t u r a d a e s
q u e r e v i s a n . C a d a u n o j u e g a distintos
com n
ju e g a n
in s p e c c io n e s ;
c o n v ie n e
lo s
a lg u n o s
de
una
ca so s
uno
pue de
dese m pe ar
ms
u n p a p e i.
H e a q u a lg u n o s d e
El presentador.
p ro d u c to
chos
E s
la
hace, qu
e n to n c e s
s o s te n e r
El
p e rs o n a
que
1) e l p ro d u c to
p o r s s o lo
no
r o d u c t o r p u d ie r a
m a n e ra
de
que
s ie n te n
moderador.
el
si
p ue de
la v a r le
a
al g ru p o
de
cuan do
se
h ic ie r o n
p e rs o n a
no
c r p tic o u
p b lic o ,
que
que
o r g a n iz a
r e v is i n
su
lo
que
el
E n m u
A lg u n a s o r
p r o p io
p ro d u c to ,
que
se
p a ra
lo s
no
pueda
e x p lic a r lo y, 2j
s u t il (y , e s
in d u c i n d o le s
y c o m is i n
in s p e c c i n :
c re , e tc .
o s c u ro
m a n e ra
de
una
s ie m p r e .
p re s e n ta
e i p ro d u c to r p re s e n te
d e o m is i n
E s la
p ro d u c to r
e l c e re b ro
su
en
s e e n c u e n tra n
e x p lic a
se
s e r ta n
e s ta n d o
in o c e n t e )
d e s c u id o s y e r r o r e s
que
co m u n e s
c a s o s , e l p re s e n ta d o r e s e l p ro d u c to r, p e ro
g a n iz a c io n e s
ei p
se ,
ro le s
lo s
de
suponer
m is m o s
e rro re s ,
l m is m o c o m e t i .
y co n d u ce
la
r e u n i n .
S u p ro
m a n e ra o r d e n a d a y c o n s r u c f v a , p a r a e v i t a r s a l i d a s p o r i a t a n g e n t e e n la s d i s c u s i o n e s , a d e m s c e
c r t i c a s a l p re s e n ta d o r. P o r r a z o n e s o b v i a s , e x i s t e la te n ta c i n d e p e r m it ir
a l a d m i n i s t r a d o r d e l p r o y e c t o h a c e r e s t e p a p e l ; p e r o p o r l a s ra z o n e s d e s
c r i t a s a n t e r i o r m e n t e e n e s t e a p n d i c e , s u p r e s e n c i a e n el g r u p o a menudo
p s ito
es
c a m b ia
El
que
la d is c u s i n
e l to n o
de
secretario. E s
la
ia
r e v is i n .
de
la
a u d it o r a , d e
nes
e s t u v ie r o n
p re g u n ta s
q u i n
p re s e n te s
la s
de
de
to m a
A d em s
t c n ic a s
e n c o n tra ro n ,
r e v is i n
q u ie n
de
c o n t in e
de
una
n o ta
de
una
m a n e ra
e ra
en
e l p ro d u c to
ia
m uy
p o r e s c r it o
c o s a s t r iv ia le s ,
r e v is i n .
im p o r t a n c ia q u e
m ie m b r o s d e l g r u p o
de
de
lo s
com o
que
se
ia
e v e n to s
fe c h a
e s ta b a
E l s e c r e ta r io
hayan
d e m e jo r a
n e g a tiv a .
s u r g id o ,
Im p o rta n te s
realizacin
r e v i s a n d o , y q u i
to m a
lo s
m o d if ic a c i n
de
n o ta
e rro re s
de
que
q u e h ic ie ro n
las
se
ios
re v is i n .
www.FreeLibros.org
9
O rculo de m antenimiento. Es
el
la r g o
p la z o
un
r e v is o r c u y a
d e l p ro d u c to .
p r in c ip a l
p re o c u p a c i n es
s e preocupa
G e n e r a lm e n t e
de
que
m e n te
s te
b ie n
no
sea
d e m a s ia d o
d o c u m e n ta d o .
r e v is io n e s d e d is e o y d e
del
p ro y e c to
la
ja r
al
y /o
de
lo s
o tro s
En
en
e s ta
e s t
un
del
s u f ic ie n t e
o b v i o : a s e g u r a r la
que
a d o p ta ro n
p a p e l p r in c ip a l e s
e q u ip o )
s o b re
el
a c e p ta b le
la s
d e s is t e m a s .
g lo b a le s
su
lo
papel m ayor en
es
p e rs o n a
o c a s io n e s
ju z g a r
qu e
a s d e a n lis is
e s t n d a re s
m ie m b r o s
fin a lm e n te
si
el
el
p ro d u c to
el
a co n se
g ru p o
(e n
de
t r m in o s
a lo s e s t n d a r e s ) .
fin a le s r e s p e
re v is i n a
c o m e n t a r io s
pue den
a c t iv a m e n t e
D. 6
dos
(y
que
q u e ju e g u e
E l ro l d e
con
c a lid a d
a d h e s i n
la
E x is te n
p ro d u c to
p ro d u c to r
c o n tro l d e
c u e n ta q u e
c d ig o
verificador de estndares.
Ei
c o n s is te n c ia
id io s in c r tic o
E s p r o b a b le
c a m b ia r d e
e n e l p ro y e c to , re c u e rd e
in c lu ir lo
a e s to s r o le s :
c to
una
o tra .
en
p r im e r o ,
el
S e gundo, si
te n g a
u s u a r io
en
p a r t ic ip a
u n o d e e llo s .
PROCEDIMIENTOS DE REVISION
C o m o
c a r a c te r iz a n
mientos
1-
se
in d ic
un
p o r
v a ra n
lo s
la
2.
lo s
A s e g re s e
la s
uno
o dos
Si
r e v is a n
no
r e v is io n e s
p r o c e d im ie n to s
a o tra , p e ro
d e l g ru p o .
que
que
q u ie n e s
lle g u e
por
lo
a la a u
m enos u n o
que
d a s
la
a n te s
a u d it o r a
te n d r n
e x ito s a s
es
m a te r ia l a p r o p ia d o
sin
p ro g ra m a
de
o p o r tu n id a d
E s to s
u n a lis ta tp ic a :
d is tr ib u y a
se
se
procedi
u s u a lm e n t e
fo r m a le s .
siguiente
la
lo s
que
r e v is a n
U na
d it o r a
pueden
que
y se q u e d e n
s o b re
p o r lo
el
s u f ic ie n t e
e s tu d ia r e l
e s ta r ta n
s ie n te n
c a lla d o s d u r a n t e
al
p re s e n ta d o r q u e
m enudo
S o lic ite
hagan
se
hace
lite r a lm
d e ra d o r, q u ie n
u n o q u e s e a le
haga
a io s q u e
pue de
una
p r o y e c ta n d o
e n t e ei g r u p o
un e rro r o
que
ia
un
a n t i
p ro d u c to
el
o ta n
la a u d it o r a
a c e ta to s ,
hace
ia
E s to
v u e lta
u n t ie m p o
p e d ir le
b re v e
p e lig r o
c a re n te s
s in
en
in te r s
r a d ic a
de
se
a p o rta r n a d a .
E s
e tc .
r o ta fo lio s ,
e l s a l n , p id ie n d o
u n c o m e n t a r io
la
uno
p o s itiv o
n o rm a lm e n te lo h a c e
a to d o
ca d a
y s im p le m e n te
e m p le a n d o
r e v is i n
c o m e n t a r io
A q u
p r e s e n ta c i n
haga
es
p o r a d e la n t a d o
to d a
r e v is a n .
d e c id ir d a r
m enos
o cu p a d o s
e l t r a b a jo
d e d ic a d o
h a c e r lo
p ro d u c to .
no
P d a le
r e a lm e n t e
f c il d e
a p o rta n d o
n e g a tiv o
r e v is a n
hayan
m a n e ra
p o r e l p ro d u c to
A q u es donde
5.
a n t e r io r ,
r o le s
que
to
4.
de
a n t ic ip a c i n .
r e v is i n
3.
s e c c i n
r e v is i n
m ie m b r o s
c ip a c i n ,
con
la
d e u n a o r g a n iz a c i n
P ro g ra m e
a
en
c o n ju n to
a c e rc a
el
a
m o
cada
q u e l a s c u e s t i o n e s s e presenten p e r o n o s e resuelvan d u r a n t e
la a u d ito ra . E s t o s o b r e t o d o i m p o r t a s i s e d e t e c t a u n e r r o r n o t r i v i a l ; d e j e
q u e e l p r o d u c t o r s e l a s a r r e g l e p a r a r e s o l v e r l o en s u p r o p i o t i e m p o , e n l u
A s e g re s e
www.FreeLibros.org
g a r de
te
p e r m it ir q u e
p r o c e d im ie n to
s e d e s a r r o lle
t a m b i n
es
una
s e s i n
im p o r ta n te
n o e s tru c tu ra d a
c u a n d o
s u rg e n
de
id e a s .
E s
574
A U D IT O R IA S E IN S P E C C IO N E S
a c e rc a
lo s
d e l e s t ilo : e l p r o d u c t o r p u e d e
r e c o n s id e r e
la s u g e r e n c i a
6.
que
C u id e
p e ra r
de
que
una
H aga
una
e s t
e rro re s
en
g e n te
se
H em os
que
q u is i r a m o s
cho
la s
de
t r a b a jo
la
en
la
m e j o r q Ue
h a b le
q u ie n
a p a rte
con
h iz o
m s de
a lto
una
n iv e l d e
d is tr a e r ,
en
h o ra .
e x is te
un
g ra n
son:
r e v is i n
os
que
se
deb en
d e t a lle s d e
e rro re s
la s
o r g a n iz a c i n ,
v o to
L a s re c o m e n
el
n e c e s id a d
d e t a lle s
que
de
c o n f ia m o s
re
estilo,
h a y a he
re s p e c to
de
ia
la
p ro d u c
algunos
d e o tra
al
e l p ro d u c to r
asum en
puede
c o r r e g ir
e s t ilo , p e r o
D e p e n d ie n d o
p e rs o n a s
e s te
de sp u s
a p r o p ia d a s .
que
de
1) C re e m o s q u e
lo s c a m b io s a p r o p ia d o s s in
en
p e lig r o
p e le a .
hacen
ta n to s
es
ms
que la
puede
d u ra n te
io s r e s u lt a d o s d e la a u d it o r a .
r e v is o r e s
h a c e r o tra
N o se
c o n c e n tr a c i n
n a t u r a le z a
r e s p o n s a b ilid a d
s e r lim it a n te
lo s
u n a s u g e r e n c ia o p c io n a l h e c h a p o r
b ie n
del
de
re p re
revisan .
que
RESUMEN
el
A u n q u e
e n fo q u e
de
re p o rta d o
ia a u d it o r a
ie r a
h a c e r la s :
P o r o tro
r e d u c c io n e s
es
p e n s a rs e .
en
un p ro c e s o
U na
puede
la d o ,
d r a m tic a s
de
la s
to m a r
m uchas
s e n c illo
ra z o n e s
h a s ta
un
y d ir e c to
de
o
e s to
un
c u a n to
a l n m e ro
de
10
que
de
es
r e v is i n ,
e l a u m e n to
p o r c ie n to d el
la s
e rro re s
han
usado
que
quedan
que
a lg u n o s
d e te c ta rs e .
P o s ib le m e n te
la
ra z n m s
p r o g r a m a d o r e s y a n a lis t a s s ig u e n
jo
N o
un
e n c o n tra d o
fo rm a
se u s a t a n t o c o m o p u d
d e l tie m p o r e q u e r i d o p a r a
tie m p o to ta l d e l p r o y e c t o .
s in
lo s
m o d if ic a c io n e s
y
d e s a c u e rd o , y e s
(o q u e
b ie n t a i c o m o e s t , o 2) C r e e m
y q u e s e d e b e n a te n d e r a l g u n o s
no
han
b re v e .
a c e rc a d e
que
s e n t a r s im p le m e n te
D. 7
sea
h a s ta c o n v e r t ir s e
v o t a c i n
e s ta r e n
r e v is i n
m a n te n g a
q u e e l p ro d u c to r h a r
e q u ip o
la
e m p e z a r n
tp ic a s
v is i n , y
su
de
e i e s t ilo ) .
a u d it o r a
la
d e g e n e re
d a c io n e s
to
s o b re
h o ra ;
r e v is i n
7.
ia
de sp u s
de
d a to s
com o
m e n te
so; cada
r e v is i n
p r o p ie d a d
vez
p e r s o n a l,
P o r e llo , p r e f ie r e n
c u a lq u ie r c r t ic a
im p o r t a n t e
no
p o r g r u p o s d e c o le g a s
se
en
no
u s a r a u d it o r a s
a sus
lu g a r d e
de
dan
si d e se a n
sea
p r o g r a m a s y d i a g r a m a s d e f lu
c o n s id e r a r lo s
m o s tra r a o tro s s u
s u g e r e n c ia
m s o r g a n iz a c io n e s
de
c o n s id e r a n d o
t r a b a jo
com o
y se
un
oponen
b ie n
de
la
m a rc a d a
m e jo r a .
E s t e e s u n p u n t o d e v is ta p e l i g r o
c u e n ta d e q u e d e b e n re a liz a r a l g n t i p o d e
m e jo ra r l a c a lid a d d e l o s s i s t e m a s q u e pro
ducen.
www.FreeLibros.org
APENDICE
| E.1
INTRODUCCION
E s te
a p n d ic e
la f a s e
de
a n lis is
v is t a r
u s u a r io s ,
s is t e m a s d e
d is c u te
de
un
se
la s
entrevistas
de
d e s a r r o llo
a d m in is t r a d o r e s ,
a u d it o r e s ,
c m p u to
P or qu
p a ra
r e g ia s
p ro y e c to
e x is te n te s , y v a r io s t ip o s
hacen
e n c u e s ta s
d u ra n te
de
u s te d
r e a liz a r
d u ra n te
P r o b a b le m e n t e
que
m s de
el
que
s is t e m a s .
e n tre
m a n t ie n e n
lo s
p e rs o n a s .
a n lis is
de
s is t e m a s ?
Las
ra z o n e s
un
s is te m a
s o n la s s ig u ie n t e s :
N e c e s it a m o s
a c tu a l o
de
r e u n ir
lo s
in fo r m a c i n
r e q u e r im ie n to s
s o b re
el
del nuevo,
c o m p o r ta m ie n to
a
p a r t ir d e
la s
de
p e rs o n a s
que
lo
t ie n e n .
m ie n t o
del
d im ie n to
con
m s
E s te
in f o r m a c i n
pod er
r e u n id a
r e u n ir
r e a liz a r
in f o r m a c i n
A p n d ic e
lo
c u b re
que
a c tu a l o
p a ra
v e r if ic a r
s is t e m a
se
en
com o
de
lo s
a n a lis t a s
e n te n d im o s
a d q u iri m e d i a n t e e n
fo rm a i n d e p e n d i e n t e .
in f o r m a c i n
c lc u lo s
de
a c e rc a
del
t r e v is t a s
s is t e m a
c o s t o - b e n e f ic io
d e l
del nuevo.
(v e a
c o m p o rta
E s te
e n te n
a n t e r io r e s , ju n to
s is t e m a s
a c tu a le s
e l A p n d ic e
p a ra
a l re s p e c to ).
lo s
s ig u ie n te s
t p ic o s
r e fe re n te s
al p ro c e s o
de
la
e n tre
v is t a :
www.FreeLibros.org
T ip o s d e e n t r e v is t a
575
REGLAS DE E STIM A C IO N
576
P ro b le m a s
v is ta
R e g la s
E.2
de
fre n te ,
fo rm a d e
e n tre
o s m is m o s
lo s
ta
g e n e ra le s
de
lo s
que
hay
que
en la en tre
p re o c u p a rs e
p a r a h a c e r e n t r e v is t a s
TIPOS DE ENTREVISTAS
T a l v e z la
te
f u n d a m e n t a le s
u s te d
p ro y e c to s ) y
e n t r e v is t a d o r e s t o m a r
se
g ra b a r
una
que
a c e rc a d e
g ra b a d o ra s
T om e
ta m b i n
de
la
que
en
den
de
c lo g o s
qu e
es
con
p o s ib le
una
un
se
puede
un
lo s
en a l g u n a s
conoce c o m o J A D
D u ra n te
v is t a s
a c e le r a d o ,
ceso
c la v e
(q u e
el
( s ig la s
a n lis is
de
u s u a rio .
en
de
fr e n
v iv o ,
en
c o le g a s
a n a lis t a s
T p ic a m e n te ,
p e ro
no
h a r
h iz o
u n o de
de
a n lis is
u n d a
U s u a lm e n t e
p a ra
de
lle v a r
su
p id i n d o le s
nue vo
cabo
e x p e rto s
Y,
d e l s in d ic a t o .
de
de
d a to s
m a n e ra
D e s a r r o llo
p o r v a r io s
r e c o le c c i n
s is te m a s
en
la
s is t e
presen
la
en tre vista
psi
la
in d u s t r ia ,
p o r ltim o ,
(p o r
debe
e je m p lo ,
s is t e m a s
C o n ju n to
t r m in o s
de
se
e s p e c ia liz a d a
de
d a to s
te n e r
v id e o g r a
C o n s is t e
e l c u a l to d o s
en
p re p a ra d o
una
s o la
s u p e r v is a
m e jo r
c o m u n ic a c i n
se
usado, de
h a c e r e n tre
in f o r m a c i n ;
A p lic a c io n e s ) ,
m s.
en
re n e n
de
de
de
u n a s e m a n a ) p a ra d o c u m e n ta r
e s p e c ia lis t a
un a
e s c r it o ,
u n a e n t r e v is t a .
h a s ta
un
p ro m o v e r
com o
c a p tu ra
p o p u la r u n a
de
por
c o m p le m e n ta r c o n
p u d ie r a n
d e a d m in is tra c i n
in g l s
y de
fo rm a l
pue dan
in c lu s o
m e d io d e
e q u ip o ,
e n t r e v is t a
lo s
se
n e g o c ia d o r e s
p e rs o n a l
m e d ia d o r
g e n e r a l,
p a p e l p a s iv o ) , t a le s
se
de
e n t r e v is t a s
u s a r o tro
a o s 80
p u e d e d u ra r d e s d e
to s d e l
m o
a c e le r a d o
m s
( e n tr e v is ta d o s ) .
c u e s t io n a r io
(q u ie n e s
e s p e c ia lis t a s
d e l c o m p o r ta m ie n to
que
b a d o ra ) p a r a g r a b a r e l c o n te n id o d e
l p iz . M e n o s c o m n m e n t e , i a e n t r e v i s
fo rm a le s . D u r a n t e t o d o e s t e a p n d i c e ,
n a t u r a le z a
d e s c r ip c i n
la s
qu e
e l a n a lis t a ju e g a
e n c u e n ta
n o ta s
uno
q u e e l t ip o d e in f o r m a c i n o b t e n i d a d u r a n t e u n a e n t r e v is t a
p o r o t r o s m e d io s , p o r e j e m p l o , p i d i e n d o a l s u j e t o o sujetos
re s p o n d a n
e s c r it o
a lg u n o s
m ie n t r a s
to m a r
de
o b te n e rs e
un
m a . T a m b i n
s u je to s
papel y
de
la d e u n e n c u e n tr o
o e s te n g ra fo s .
c u e n ta
pue de
con
se a
a co m pa ado
m s
s e r
e n t r e v is t a
e n t r e v is t a
le
c ia
su
uno
n o ta s
s e c r e ta r ia
s u p o n d r
m s com n
e n t r e v is t a
( p o s ib le m e n t e
e n tre
en
lo s
ju n ta
lo s
se
d is e
pro
un
u s u a rio s
in te n s iv a
r e q u e r im ie n
ta j u n t a
io s a n a
y a c t a co
lis t a s
y los
u s u a rio s .
A u n q u e to d a s
y no
v a
se
d is c u tir n
e l e n fr e n ta m ie n to
E.3
e s ta s
v a r ia n te s
m s a fo n d o
uno
en
han
e s te
a u n o e n tre
A p n d ic e .
La
u n a n a lis t a y u n
hecho, son
e n t r e v is t a
m s com n
es
raras
toda
u s u a r io f in a l.
PROBLEMAS FUNDAMENTALES DE LOS QUE

HAY QUE PREOCUPARSE
www.FreeLibros.org
A
s e n c illo
p rim e ra v i s t a , p u d i e r a
d ire c to . D e s p u s d e
p a re c e r q u e
to d o , u s te d
ei p ro c e s o
es
de
u n a p e rs o n a
e n t r e v is t a r a
in te lig e n te
un
u s u a r i o es
y c a p a z de
co
R E G LA S DE E STIM A C IO N 577
m u n ic a r s e , y e l u s u a r io
sean
lo g r a r
p u e s to d e
el
la
m is m o
io
e s ta m b i n .
o b je t iv o :
u s u a rio
m e n te d e i
A m bos
tr a n s fe r ir
suya.
a la
son
D e h e c h o , e x i s t e n m uchos p r o b l e m a s q u e
d e a lta t e c n o l o g a , s e h a o b s e r v a d o q u e l o s
c ra n h a rd w a re n i s o f t w a r e s in o g e n t e w a r e .
siste m a s s e a p r e c i a n m s p o r l o r e g u l a r e n l a s i t u
el
a n a lis t a
com unes de
y e l u s u a r io
f c il,
d e b id o
e n c u e n tre
t ic a
dei
con
tra
lo s
pue den
n ue vo
s u r g ir .
p r o b le m a s
s is t e m a
en
e n tra n
de
m uchos
d if c ile s
a s u n to s
E s to s
a c i n
En
m s
p ro
el
en
c o n ta c to .
Los
p ro y e c
no
in v o lu
a n lis is
la e n t r e v is t a : e s
de
aqu do n
p r o b le m a s
m s
lo s s ig u ie n t e s :
del
de
la
q u e o f ic ia lm e n t e
r e s u lt a
d e s c o n o c id o
a la p e r s o n a
en
s o m e t id o a
que
p e rs o n a
no
s is t e m a ; t a m b i n
e l u s u a r io
e n t r e v is t a
c o rre c ta ,
un
o rg a n iz a c i n
p r o b le m a s
h a b la n d o c o n
u s u a r io ,
m ie n t o s
es
en
nad a
de
p e rd e r
re a lm e n te s
puede
m o m e n to
sa b e r
p o s ib le
que
q u e no e s t
e m e rg e n c ia s .
de
p o lt ic a ,
en
v e rd a d e ro s
o p o r tu n id a d
m a n e ja .
e s t tra ta n d o
d is p o n ib le
de
en
se
p o l
r e q u e r i
de
si
A un
Es
que
e s la e x p e r t a
lo s
la
lo s
e n c o n tr a r q u e
ei
m u c h a s p r e s io n e s y
h a b la r
e n cu en
h a c e r le
el que
la
e s t
H acer las preguntas equivocadas y obtener las respuestas equivocadas.

E i a n lis is
m a
de
de
s is t e m a s
t ie n e n
d is tin to
ju n to s
de
f c il
que
le h a g a
una
de
su
n in g u n o
se
p e rc a te
re s p e c to
m o d e la d o
lo s
g ra n
que
que
se
e llo .
m e d id a
en
le n g u a je
e i p r o b le m a
e n tre v is ta s
hayan
e n te n d id o ta n to
lo s
u s te d
ra z o n e s
no
c lu s o
a n ta g o n is ta
en
c u a le s
un a
un
com o
la s
C o m o
u s u a rio se
e n t r e v is t a
( in g l s ,
E s p o r e s to
p a ra
co n
r e q u e r i
s in
que
in f o r m a c i n
in f o r m a c i n ,
son
m a n e ra
se
co n
lib r o
s e g u im ie n t o
lo s
d ic h a
fo r
P o r e llo , e s
de
le
Las
e s te
a m b ig u o , a
la s
una
a n a lis t a s
d is tin to s
a c e rc a
p e rc a te .
en
lo s
p o r c o m p le to ,
m a le n tie n d a
se
m enudo
u s u a r io
c o m n h a b la d o
la s p r e g u n t a s
la s
p o r
el
C rear fricciones entre ambas partes.

e x is te n
que
D e M a rc o ,
p r io r id a d e s .
a l u s u a r io
dos
P e ro
m a le n tie n d a
e s v e rd a d e ro .
de
T om
u s u a rio s
Los
v a lo r e s
f c il
com n,
le n g u a je
e tc .), a s q u e
le
y que
e n te n d id o s .
un
es
de
p re s e n ta ro n
te
p ro g ra m a r
s te
Y
n in g u n o
m a lo s
d e c ir a
e x p e r ie n c ia , y a
r a z o n a b le
que
s in
e s to s
p r e g u n ta
de
g u s ta
p e r c e p c io n e s ,
s is t e m a ,
p r o p o r c io n a r u n
m in u ir
le
e x tra te r r e s tr e s .
v o c a b u la r io , d is tin ta
m ie n t o s
de
es, com o
e n tre
s u p o s ic io n e s ,
n u e v a m e n te
c u id a r s o n
un
Entrevistar a las personas equivocadas en el m om ento equivocado.

m uy
v e rd a d e ra m e n te
lo s q u e s e d e b e
de
r a c io n a le s y a m b o s
s o b re
C u l e s e l p r o b le m a ?
to s
de
p e rs o n a s
in fo r m a c i n
de
lle v a n
un
p o d e r d is
e s p a o l,
que
e s ta n
cabo
en
fra n c s ,
im p o r t a n
am bas
v e r if ic a r q u e
de
in t e n t o
p a rte s
re s p u e s ta s ,
v e re m o s
puede
un
en
s e n tir
a n a lis t a
la
S e c c i n
in c m o d o
de
s is t e m a s
E .6 ,
o
in
(p o r
www.FreeLibros.org
e je m p lo , p o r q u e
e s t
s ie n te
e s p e c if ic a n d o
m o le s t o
por
la
le v a
fo rm a
en
que
e l p r o p s ito
del nuevo
q u ita r su e m p l e o ) .
la q u e el u s u a r i o e s t
a
s is t e m a
e l a n a lis t a
que
e l a n a lis t a
pue de
r e s p o n d ie n d o
s e n t ir s e
578
REG LAS DE E S TIM A C IO N
p ue de
que
s e n t ir
e l u s u a r io
lo
e s t
in s u lt a n d o
do jo v e n e in e x p e r t o p a r a e s t a r d a n d o
to s d e l n u e v o s i s t e m a ) . E n c u a l q u i e r
l a s p a rte s , h a c i e n d o m s d i f c i l l a c o m
N o
rra n ;
e x is te
el
son
a lg u n a
r e s u lt a d o
ra c c io n e s
es
r e d u c ir la
p o s ib ilid a d
pender
de
n ic a .
E.4
Las
la s
e m b a rg o ,
de
de
que
s u r ja n
que
g a r a n t iz a r
e s to s
p e rs o n a s , y
s ig u ie n te s
ca d a
s u r g ir
u n ic a c i n .
e n tre
e s to s
y m e jo r a r c o n
caso, pueden
d e m a s ia
es
re q u e rim ie n
f r i c c i o n e s entre
lo s
p r o b le m a s ;
a p a rte
no
ocu
ta le s
inte
p r o b le m a s
cada
una
le
de
de
p ue den
eso
ayud ar a
s lo
q ue da
de
e n t r e v is t a .
s ig u ie n te s
A n te s
D e
de
c o m e n z a r,
o tro
E s to
Si no
y
r e q u ie r e
ha
se
p id a
la
que
p u b lic a d o
ayuda.
la s q u e s e
d e l s is t e m a
se
un
un
en
p a ra
hace r
una
exitosa
e n t r e v is t a
se
e n te re
to d o s ,
o r g a n ig r a m a
uno,
no
a s e g re s e
lo s
de
y c re a r
3,
q u i n
deb e
p r o b le m a s
e n tre
p o lt ic o s
e s t
r p id a
d ir
d is tin to s
t r a b a ja
a c t u a liz a d o ;
que
lo
en
e l c ic lo
la
p u e s to s .
o r g a n iz a
m enudo
la s
la s
pu
anual de
ve ce s
q u i n
se
r e fie r e
ni
e x is te n
s iq u ie r a
tre s
m enudo
n e c e s it a
a a lg n
de
u s u a r io s
u s u a r io
re s u lta
h a b la r ;
a s p e c to
a ll.
a p a re c e
n iv e le s
u s u a rio , el
el v e rd a d e ro
s u p e r v is o r .
con
que
a d m in is t r a d o r q u e
c o m p le ja :
lo s
cm o
o r g a n ig r a m a s .
m uchas
e je c u tiv o
m u e s tre
sepa
que
m s
o a lg n
que
que
a lg u ie n
m ucho
le
m s
C a p tu lo
g ra n d e
es
y con
q u ie n
e n t r a d a , i le
q u ie n
de
e l u s u a r io
T a m b i n
p r im e r o
qu e
de
Co
en
s u p e r v is o r
im p o r t a n t e
hablar
e llo s .
a p r o p ia d a
M a rta ,
un
p ro d u c e n
o f ic in is t a
el
e l t ie m p o
m a n e ra
o r g a n ig r a m a
s e r
o p e r a c io n a l,
de
la p e rs o n a
d is c u ti
c o n io d o s
p a rte
t ile s
Im p o rta n te
e n c u e n tr e
S i s e x is te
b lic a c io n e s e n
I n c lu s o
m uy
o b te n g a
c a m b ia n
un a
ser
p e r s o n a e q u iv o c a d a d e c o s a s e q u iv o c a d a s .
uno,
o c a s io n e s
es
m o d o , d e s p e r d ic ia r
e n o r m e s , a l h a b la r c o n
m o
pue den
D esarrolle un plan global de la entrevista
v is t a r .
c i n
Se
r e g la s
u s u a r io .
E.4.1
m g ic a
in te r a c c io n e s
s o b re
REGLAS PARA HACER ENTREVISTAS
con su
en
la s
S in
p r c tic a
la
m a n e ra
de
a l s u g e r ir q u e
con
Pues,
d ic e :
pue de
J o rg e
d ic e : P u e s ,
y yo
en
im p o r t a n te
la c o m b in a c i n
desd e
d e c ir c m o
y
en
e l re s to ...
m u ch o s
luego con
ca so s
c o rre c ta .
lu e g o ,
es. Y
e s te
con
J o rg e
m e
e llo s
en
e n c o n tr a r s e
p r o p o r c io n a
la
s e c u e n c ia
e n t r e v is t a n d o
to d o s
m is
d a to s
de
y o ... E n ta l c a s o r e s u l t a t i l h a b l a r
p u e d e e s ta r e n tre v is ta n d o a F rancisco,
t r a b a j a m o s j u n t o s en e s t o ; e l l a h a c e u n a
e n to n c e s
M a rta .
r e a lid a d , S u s a n a y y o
En
h a b la r
E s d e c ir , p u e d e
c a s o , o b v ia m e n te
s e ra
m s
t il h a b la r c o n
a m b o s a la
www.FreeLibros.org
vez.
c ia ,
ve ce s
p a r t ie n d o
u s u a r io s
pue de
ta n
m is m o s
d is tin g u ir q u
s lo
de
le d ir n
su
en
u s u a rio s
c o n o c im ie n t o
c u a n to
sepan
se
n e c e s it a
g e n e ra l
que
lo s
de
e n t r e v is t a r y e n
la
o r g a n iz a c i n ;
v a a e n t r e v is t a r .
qu
a
secuen
ve ce s
lo s
R EG LA S DE E STIM A C IO N 579
g.4.2
Asegrese de contar con aprobacin para hablar con ios usuarios

En
a lg u n a s
e n t r e v is t e
c a m e n te
alguna
rea
cundo.
p e lig r o s o
(u n
lo s u s u a r i o s
En
en
de
lo s
p r e v ia m e n te
lo s
sean
zo
que
de
lo s
de
c u a n to
poco
q u i n
u s u a l; e s
h a c ie n d o
p o lt i
s in
con
tie n e n
del
v e n d r
b ie n
de
e l p ro y e c to
m o tiv o s
a d m in is t r a d o r d e
a lg n
un
re p re s e n ta n te
de
d e s a r r o llo
le g t im o s
p a ra
de
s is
de
d e s e a r a p ro
e n t r e v is t a r :
no son
capa ces de
e s fu e rz o
e n t e n d e r o d e s c r i
lo s
ta n to
p od
e llo s
su s
la s
u s u a r io s
e n tr e v is ta s
P o r e llo , q u e r r n
que
de
de
la s
de
(o e n
n iv e l o p e r a c io n a l
c u a lq u ie r c a s o , re
n o a p ru e b e ).
lo s
I n te r f ie r a n
con
la s
la b o r e s
p r o g r a m a r la s .
p o r r e e m p la z a r a
p e n sa r que
s o b re
a lg u n o s
r e q u e r im ie n to s f a ls o s
que
u s u a rio s .
p re o c u p a rs e
un
Pueden
g ru p o )
c o m p u t a r iz a d o , c a u s a n d o
que
de
p re o c u p a rs e
P u eden
a lg u n o s u s u a r io s
p re o c u p a rs e
P u eden
u s u a r io s
re n e g a d o s , q u e d e n
n o r m a le s d e
es
lo s r e q u e r im ie n t o s d e l s is t e m a .
q u e r im ie n to s
a p ro b a c i n
e s ta
d iv is i n
se va ya
s e n t ir q u e
P u eden
e s to
u s u a ria
en
r e s tr ic c io n e s
g ra n d e
d e s ig n a d o , v in c u la d o
c u a lq u ie r c a s o ,
b ir b ie n
la
casos,
d e p a rta m e n to ,
P ueden
hay
p o r to d a
b a r, p o r a d e la n t a d o , a q u i n
no
in fo r m a le s
una
a n t e r io r .
la m a y o ra
u s u a r ia
tem as.
P e ro
an d a r
a p r o b a c i n
E n
se
p e r c ib a n
u s u a r io s
com o
hum ano s
e l c o m ie n
con
u n s is t e m a
d e s p id o s , e tc .
m is m o s
re q u e rim ie n to s d e l
r a n n o q u e r e r que
( lo s
a d m in is t r a d o r e s ) s a b e n
s is t e m a
u s te d
qu e
h a b le
c u a lq u ie r
con
o tra
u s u a r io s
m ucho
m s
p e rs o n a ).
P or
de
n iv e l o p e r a c io
n a l.
P uede
e x is tir a lg n
un
e l a d m in is t r a d o r p u e d e
s is te m a s .
A s ,
puede
e n tr e v is t a s , p e r o a l e v ita r la s
P o r to d a s
de su
e s ta s
r o c r tic a
p a r a n o ic a ,
significa,
que n e c e
s it a
quien
le
haya
c la n d e s t in a
fu e ra
h a b la r c o n
es
buena
la a p r o b a c i n
ser
puede
p o r c ie r t o , q u e
y su
no
m s
a lto
de
te n e r v e rd a d e ra
m a n d a r
un
m e n s a je
de
la
a d
d e s a r r o llo
o b je c i n
p o lt ic o
a l je f e
je fe .
ra z o n e s ,
m u c h o s c a s o s , b a s ta
n iv e l m u c h o
u s u a ria
de
d e l je fe
se
p o lt ic o , a
la o r g a n iz a c i n
sus
En
c o n f lic to
m in is t r a c i n , e n t r e
deb e
un
in d ic a d o
que
in c lu s o
e s ta r a l ta n to
u s u a r io
no
id e a
lo g r a r
la
a p r o b a c i n
v e r b a l ; s i la o r g a n i z a c i n
de
la
n e c e s it e
la
p o lt ic a
( t p ic a m e n te
e n t r e v is t a r .
un
P uede
p o r e s c r it o .
de
u s u a r io
d e se a r
p o r
a d e la n ta d o .
e s te r r ib le m e n t e
bu
E s to
t a m b i n
la o r g a n i z a c i n
s i s ie n te
de
n iv e l
o p e r a c io n a l)
p r o g r a m a r a lg u n a
r e u n i n
www.FreeLibros.org
sar
la
s o lic it u d
d e l lu g a r d e
sus
t r a b a jo ,
s u p e r io r e s
p a ra
p e ro
qu e
u s u a lm e n t e
suba
p o r to d a
r e s u lt a
la
m enos
ca de na
p e lig r o s o
je r r q u ic a
pa
de
la
580
R EG LA S DE E S TIM A C IO N
o rg a n iz a c i n ,
p a r a f in a lm e n te
u s u a r ia , p a r a
lu e g o d e s c e n d e r p o r t o d a e s a c a d e n a je r r q u ic a . 1
E.4.3
t ie m p o
P o r eso
que
lo s n iv e le s
s u p e r io r e s
Lo
p r in c ip a l d e
a ! u s u a r io
es
e s ta s u g e r e n c ia
y qu e
im p o r ta n te
p ue da
que
l ( o s u je fe )
p la n e e
h a c e r u s o e fe c tiv o d e
p r im e r o
que
hay
que
y se
se
es que
pueden
p re p a re
m s
lo
e s t
p re p a ra d o
s ig n if ic a
h o s t ilid a d
sus
p a ra
b ie n
h a c ia
to d o
1)
p o s ib le
con
qu itn
q u e e s t
desperdiciando.
e s t
a n t ic ip a c i n
p a ra
h a ce r es
a s e g u ra rs e
de
que
s i e l u s u a r io
m uy
e s t
e l c o n c e p to
de
la
no
2)
ocup ado,
e n t r e v is t a
que
vaya
h a c e r, o
a n d r s e la
a l u s u a r io
in d ic io d e
que
ha
que
c o n o z c a el te
e n otros,
e l u s u a r io
h a c e r p o r t e l f o n o ;
le d o
no
in te r e s a ,
3)
no
es
capa z
la
uno
r e a lid a d no
le
e l m a te r ia l q u e
le
o, 4) que
en
io s t p i
con
que
de
m an
s ie n te
e n te n d e r
p re g u n ta s .
A d em s:
fo rm a s
re n a
re p o rte s
a d e la n t a d o .
de
S i p re p a r
una
h o ra
to d a
la
in fo r m a c i n
r e la c io n a d o s
S i e x is te n
r io r , a s e g r e s e
o tro s
h a b e rlo s
sus
E s to
no
puede
d e d ic a r le
lo
s e a l
en
os)
p o r
m s
e n t r e v is t a
m e n te
p a ra
en
una
g r a m a r v a r ia s
la q u e s e
de
una
m s
h o ra .
e n c u e n tra
r e u n i d e
que
se
ocu p e
se
la
(s o b re to d o
s ig n if ic a
te m a r io
la
s i e s t n
que,
e l m is m o
r e s u lt a
p a ra
puede
e l a n te
e n tr e v is t a
lu e g o ,
lim it a d o ,
T a m b i n
u s u a r io
s is t e m a
s in o
t a m b i n
no se
c o n t e m p la n d o
d esd e
S i e x is te n
o b te n e r lo s por
p o d e r r e s t r in g ir la
s io
u n a re u n i n d e
d e s e a r r e t i r a r s e
e n t r e v is t a , a s u m ir s u
n e c e s it e
el nue vo
a n te s d e
no
puede
a
el
(c o m o
pueden
e n fo
d ia g r a m a s e x tra
d e b e r
o r g a n iz a r
c o n c e n tr n d o s e
s ig n if ic a r q u e
c u b r ir p o r
que
c o m p le to
deb e
ei
su
tp ic a
p ro
re a con
I n v o lu c r a d o .
G e n e r a lm e n t e ,
ser
d e s c r ib e n
pues
F in a lm e n t e , p r o g r a m e
re c o p il .
de
que u n a h o r a o d o s c a d a vez,
D ) la s p e r s o n a s g e n e r a l m e n t e
E s to
con
a n te s
p o r a d e la n t a d o , d e b e
e i A p n d ic e
q u e c u b r a un
p a rte p e q u e a
que
y e s tu d ia d o
im p o r t a n t e ,
c a r y c o n c e n tr a r c o m p le ta m e n t e
p o s ib le
d is c u s i n , g e n e r a lm e n te
d o c u m e n to s
o b te n id o
es
ade m s
la
con
p re g u n ta s
m enos.
u s u a r io
que
se
ia e n t r e v is t a .
la e n t r e v i s t a .
que
de
d c u e n ta
s e n t ir q u e
m a d e l a e n t r e v i s t a . E n a l g u n o s c a s o s e s to s e p u e d e
p u e d e s e r a p r o p i a d o e s c r i b i r u n a lis ta d e la s p r e g u n t a s
c o s que v a a a b o r d a r , o lo s D F D q u e q u ie r e r e v is a r , y m
o d o s d a s d e a n t i c i p a c i n . Si n o lo p u e d e h a c e r , e s u n
d,
o rg a n iza ci n
d e la
Planee la entrevista para usar de manera efectiva su tiem po

E l m o tiv o
d o le
se r p a sa da
d ib u ja r D F D , o
h a c e r c lc u lo s
de
s e g u im ie n t o
a
su
p a ra
e s c r it o r io
to d a
p a p e l d e a n a lis t a , y p o n e r s e
e s c r ib ir e n tr a d a s
c o s t o - b e n e f ic io ;
pue de
del
que
in fo rm a ci n
r e v is a r e l m a te r ia l
con
a tr a b a ja r .
d ic c io n a r io
s e r n e c e s a r io
ia
de
Puede
d a to s ; ta l vez
c o r r e l a c i o n a r ia in
1 T o d o e s to in v o lu c ra p o ltic a s o rg a n iz a tiv a s que re b a s a n e l a lc a n c e d e e s te libro. P a ra m a yor in

fo rm a c i n le a a lg u n o d e lo s te x to s e s t n d a r de a d m in is tra c i n y d e te o ra o rg a n iz a c io n a l, o consulte
el agradable lib ro de R obert B io c k , The P oitics o f Projects (N u e v a Y o rk : Y O U R D O N P re s s , 1981),
www.FreeLibros.org
R EG LA S DE E S T IM A C IO N 581
formacin
quier
q ue
obtuvo
con
f o r m a , lo s d a t o s d e
lo s
d a to s
de
o b te n id o s
entrevista
d ic h a
se
entrevistas, etc.
o tra s
cual
D e
m a n ip u la r n , d o c u m e n ta r n , a n a liz a r n
y se transformarn a una forma que posiblem ente e l usuario jam s haya visto antes.
p o r ello n e c e s i t a p r o g r a m a r u n a e n t r e v i s t a d e s e g u i m i e n t o p a r a v e r i f i c a r : 1 ) q u e n o
f , a y a e n t e n d i d o m a l l o que e l u s u a r i o l e dijo, 2 ) q u e s t e n o h a y a c a m b i a d o de o p i
n i n d e s d e l a entrevista2, y 3 ) que l e n t i e n d a l a n o t a c i n o r e p r e s e n t a c i n g r f i c a
je d i c h a i n f o r m a c i n .
,4.4
Use herram ientas autom atizadas cuando sea apropiado,

pero no abuse
D u r a n t e l a e n t r e v i s t a , p u e d e r e s u l t a r l e c o n v e n i e n t e usar h e r r a m i e n t a s d e pro
totipos, s o b r e t o d o s i s u p r o p s i t o e s d i s c u t i r e l p u n t o d e vista d e l u s u a r i o e n c u a n t o
a la i n t e r f a s e h u m a n o - m q u i n a . D e m a n e r a s i m i l a r , s i e s t r e v i s a n d o u n d i a g r a m a
de f l u j o d e d a t o s y d i s c u t i e n d o p o s i b l e s c a m b i o s , p u e d e r e s u l t a r l e c o n v e n i e n t e u s a r
una d e l a s h e r r a m i e n t a s C A S E q u e s e d i s c u t e n e n e l A p n d i c e A ,
R e c u e r d e , s in
e n t r e v is t a ,
hacer
no
e m b a rg o , q u e
e s t o r b a r le ;
c a m b io s
r p id a
lo s r e q u e r i m i e n t o s
del
deben
e l p r o p s ito
p e r m it ir
f c ilm e n te ;
u s u a r io
en
puede
e l a c to
de
d ic h a s
usted y
s e r le
y
al
t il
u s u a r io
p a ra
c o r r e g ir
de
fa cilita r
es
e x p lo r a r a lte r n a t iv a s
a n o t a r lo
que
in m e d ia t o
e n tie n d e
e rro re s
que
la
y
de
haya
p o d id o c o m e t e r .
S in
e m b a rg o ,
s i la
te c n o lo g a
necesita q u e e i u s u a r i o
vaya a o t r o e d i f i c i o , o a l
c o m o a lg o
m o le s t o .
s e le
que
p id e
f a m ilia r iz a d o
te r e r r o r e s ,
con
la
una
la
de
e s to rb a ,
su
de
deb e
a m b ie n te
en
e s to s
su
uso)
casos,
e n t r e v is t a ;
(o
es
de
pue de
que
la
herramienta
e n to n c e s
s e r
m o s tr a r
c a u s a r p r o b le m a s
de
la
t r a b a jo
se r que
la t e c n o l o g a d e
p o s ib le
s i la
lu e g o
e x c lu ir s e
n o rm a l
c o m p u ta d o ra s ), p u e d e
h e r r a m ie n ta ,
h e r r a m ie n ta ,
h e r r a m ie n t a s in
E.4.5
de
la
c u a rto
de
S i n o e s t f a m ilia r iz a d o c o n
lim it a d a
En c u a lq u ie r a
despus
use
con
s a lg a
un
sea
al
g ra n
vea
la
e s to rb o
u s u a r io
lo s
se
que
h e r r a m ie n ta
si
u s te d
le n t a , s u s c e p t i b le
a c o n s e ja b le
Si
e je m p lo ,
la s c o m p u t a d o r a s y
re c h a c e .
es
(p o r
p a ra
usar
la
no
de
e s t
co m e
ia entrevista.
h e r r a m ie n ta
r e s u lt a d o s
o b te n id o s
in n e c e s a r io s .
Trate de juzgar qu inform acin le interesa ms al usuario

S i t ie n e
que
d e s a r r o lla r
un
m o d e lo
c o m p le to
p a ra
a lg u n a
p o r c i n
de
I ma, t a r d e o t e m p r a n o t e n d r q u e d e t e r m i n a r e n t r a d a s , s a l i d a s , f u n c i o n e s ,
| ticas d e p e n d i e n t e s d e ! t i e m p o y m e m o r i a d e l s i s t e m a . E l o r d e n en e l c u a l
informacin r e a l m e n t e n o i m p o r t a m u c h o o , p o r l o m e n o s , p r o b a b l e m e n t e
le i m p o r t e
un
s is e -
c a ra c te rs o b te n g a
a
u s te d
la
no
m ucho.
2 Por q u razn p o d r el usuario c a m b ia r de o p in i n d e u n a e n tre v is ta a la sig u ie n te? N o rm a l

mente p o rq u e la e n tre v is ta h a c e q u e dirija su a te n c i n a a lg o que ta n s lo ha c o n s id e ra d o desde
tejos h a s ta a h o ra . Las p re g u n ta s d u ra n te la e ntrevista p u e d e n h a c e r q u e vea s u s re q u e rim ie n to s
en fo rm a d ife re n te .
www.FreeLibros.org
582
R EG LA S DE E S T IM A C IO N
P e ro
puede
im p o r t a r le
lo s
ni
re p o rte s
s iq u ie r a
O tro s
d a to s
se p a n
u s u a r io s
que
q u
de
tema
a lg n
que
e n tra d a s
e s ta r
se
m s
p e r m it ir le
d e s e a r n
co m e n za r
e l s is t e m a
p ro d u z c a
o cu p a n
p a ra
in t e r e s a d o s
(d e
p r o d u c ir
en
la s
e m p e z a r la e n t r e v is
por
la s
salidas,
hecho,
la s
s a lid a s
e n tra d a s
en
es
d e c ir
ser qu
puede
deseadas)
lo s
d e t a lle s de
de l o s <ja
lo q u e s e a , t r a t e de v i s u a l i z a r i o s requerimientos d e l sis
desde e l p u n t o d e v i s t a d e e l l o s , y t e n g a d i c h a p e r s p e c t i v a en
f u n c io n a l.
querrn
O tro s
h a b la r a c e r c a
d e lo s
d e t a lle s
a lm a c n . S e a
o m e jo r p o s ib le
m e n te c u a n d o
E.4.6
a l u s u a r io , y d e b e
u s u a r io s
q u ie r e n
pueden
una transform acin

to s
m ucho
Algunos
ta d o n d e l q u ie r a .
le s h a g a
la s p r e g u n t a s n e c e s a r ia s d u r a n t e
ia e n t r e v is t a .
Use un e s tilo apropiado de entrevista

C o m o
lo s e a la W illia m
(Davis,
D a v is
1 9 8 3 ):
L a a c titu d q u e sobre la e n tre v is ta tom e s e r d e te rm in a n te en el x i

to o fra c a s o . U n a e n tre v is ta no e s un c o n c u rs o . E v ite a ta q u e s ; e v i
te u so e x c e s iv o de vo ca b ulario t c n ic o ; h a g a u n a e n tre v is ta , no un
in te rro g a to rio . H a b le c o n la s p e rs o n a s , n o c o n tra e lla s , y h b le le s
p o n i n d o la s e n su m is m o n iv e l, no a rrib a o a b a jo . U n a e n tre v is ta
n o e s un ju ic io . Haga preguntas d e sondeo pero no interrogue. R e
c u e rd e q u e e l e n tre vista d o e s e l e x p e rto , y que u ste d e s el que b u s
c a r e s p u e s t a s . F in a lm e n te , h a g a lo q u e h a g a , e v ite a ta c a r la
c re d ib ilid a d d e la o tra p e rs o n a . N o d ig a : T a l p e rs o n a m e d ijo o tra
c o s a , o N o s a b e d e q u e st h a blando.
H a c e r p r e g u n ta s
dad
del
los p a r a
tiles:
entrevistado
lo g r a r la
in fo r m a c i n
R elaciones:
P d a le
y
de
con
o tra s
objeto
un
o tro s
de
a l u s u a r io
que
p a rte s
s io
le
es
f c il; d e p e n d ie n d o
pue de
e x p liq u e
un
d e s c u b r ir
m s
su
u n a fu n c i n
r e la c i n
lo
s o b re
a d e s c u b r ir in te r f a s e s
ja
e n e l D F D ) y r e la c io n e s f o r m a le s .
Puntos de vista alternativos:

d e o tro s
g n te le
o b je to
lo
en
Sondeo:
u s u a r io s s o b r e
qu e
o p in a
s u je fe
a l u s u a r io
P d a le
lo
que
a c e rc a
una
con
que
l o q u e s e e s t
h a b la n d o
e x p liq u e
d e c ir ,
a c e r
su
r e la c i n
una
b u r b u ja
Esto n o
d i s c u t i e n d o , sino
se
e s t
d e d a to s
de
una
b u rb u
que d e s c r i b a e l p u n t o d e
discutiendo. P o r e j e m p l o , p r e
una
b u r b u ja
u s u a r io
de
lo q u e
e n tre
esti
r e s u lt a r
e s t
al
se
de
pueden
e s t
(e s
p e r s o n a li
o tr a s f u n c io n e s .
( p o r e je m p lo , f lu jo s
e l D E R ; o p r e g n te le
P id a
que
la
v a r ie d a d
que
r e la c i n
c lie n t e ) , p d a le
t a m b i n
a o tra
e s t ilo s
S i e l u s u a r io
d e s c r ib ie n d o
explique
la
de
una
r e q u e r ir
a q u a lg u n o s
o b je to s ; s i e s t
a y u d a r
siempre
He
que
le
no
la
d ese ada.
d e i D F D ) , p d a le
v is t a
so nd eo
tema
d is c u tie n d o
ca
de
y ei
o p in a n
d e s c r ip c i n
del D F D , o
un
t ip o de
s u s s u b o r d in a d o s .
n a r r a tiv a
in fo r m a l d e
lo
que
le
www.FreeLibros.org
interesa
c o s to s
s a b e r.
de
P uede
e n v o .
d e c ir :
s i le
H b le m e
e s t
h a b la n d o
de
la
m a n e ra
a c e rc a
de
un
en
qu e
tipo
de
calcula
lo s
o b je to
del
R EG LA S DE E S T IM A C IO N 583
D E R ,
decirle:
puede
acerca de un
Dependencias:
d e a lg u n a
do
se
H b le m e
d e l c lie n t e .
Q u
sa b e
necesita
(o
P r e g u n te
o tra c o s a
d is c u te n
a l u s u a r io
p a ra s u
t ip o s
de
io
si
e x is te n c ia .
o b je to s
que
se
E s to
p o s ib le s
e s t
es
d is c u tie n d o
p a r t ic u la r m e n t e
r e la c io n e s
p o s ib le s
en u n s i s t e m a d e ingreso d e p e d i d o s ,
posible t e n e r u n p e d i d o ( s i e s o e s l o q u e
puede
a l u s u a r io
e s t
ese
si es
dep ende
t il c u a n
d e n tro
D E R . P o r e je m p lo ,
en
s a b e r)
c lie n t e ?
del
p r e g u n ta r
d is c u tie n d o
m o m e n to ) s in t e n e r c lie n t e .
Repeticin: Dgale
usuario i o q u e c r e e h a b e r l e o d o decir; u s e s u s p r o
de l a s d e y p d a l e que i o c o n f i r m e . A s , p u e d e
d e c i r ; A v e r s i le e n t e n d : cuando u n a p i e z a e n t r a a l s i s t e m a , s i e m p r e le
hace u n p r o c e s o y l e m a n d a u n m e n s a j e d e status a l d e p a r t a m e n t o d e a u
p ia s
p a la b r a s
en
al
lu g a r
d ito r a .
E.5
POSIBLES FORMAS DE RESISTENCIA A SER ENTREVISTADO

C o m o
u s u a r io s
para
se
se
que
a s e g u ra r
e n te ra d o d e
nes (y s u s
m e n c io n
opo ngan
su
e s ta r p re p a ra d o
id e a
de
m is m a
y la
haya
de
a p ro b a d o .
ha
lo
c o m p re n d e ,
p re p a ra d o
e n t r e v is t a
al
de
se
a n te m a n o
m n im o .
E s to
n o s e s a lg a d e l o b je t iv o , y
a u t o r id a d
A lg u n a s
d is c u lp e
io
pue de
g ra n
n m e ro
de
e s ta
p e rs o n a , y
p e lig r a , n i p a r a
e s ta r o
que
no
ms
u s u a r io
no
de
q ue
algunos
la s
ra z o n e s
una de
es
en
su
d e p a rta m e n to
objeciones
la s
re s p u e s ta
ello,
E s ta
b ie n
d esd e
es
p e ro
con
m s
io
m e nudo
fu n d a d a .
le
e s to
es
c o m u n iq u e
cual espera
lo
lu e g o ,
te r m in e c u a n d o
e s t
co m u
que
sea
que
le
que
la
r e d u c ir
la
p u n tu a l,
que
p r o m e ti .
una
A u n q u e
se
reaccin
le
p ue da
m uy
e m o
o c u r r ir
un
respuestas, r e c u e r d e q u e u s t e d n o es e l a d m i n i s t r a d o r d e
que n o tiene a u t o r i d a d p a r a a s e g u r a r l e q u e s u e m p l e o n o
p r e v e n i r l e d e que s .
P u e d e t r a t a r d e d e s l i n d a r la respon
sabilidad d i c i e n d o : N o t e n g o n a d a
t a n d o los r e q u e r i m i e n t o s d e l s i s t e m
el
de
La
p o r
p o s ib le ,
r e q u ie r e ,
Est amenazando mi empleo.

c io n a l,
el hech o
s ta
a continuacin:
r e s p u e s t a s ) s e c it a n
que
p a ra
e n t r e v is t a ;
Est ocupando demasiado de mi tiempo.

d ig a
una
a d m in is t r a d o r o a lg u ie n
la e n t r e v is t a
p o s ib le s
a n te s , d e b e
la
a c e p ta r
eso.
Lo
qu ve r con
a
v e r
por
o rd e n
co m o
e s to ; s lo
de
e s to y d o c u m e n
la a d m in is t r a c i n , p e r o
e l e x p e rto
en
e f ic ie n c ia c u y a
labor es a c o n s e j a r a l a a d m i n i s t r a c i n c m o eliminar s u e m p l e o m e d i a n t e
la c o m p u t a d o r a . L a solucin d e e s t e p r o b l e m a , s i s e p r e s e n t a , e s c o m u n i
c a r lo
lo s
o f ic ia l d e
n iv e le s
ellos,
en
s u p e r io r e s
p e rs o n a
de
la
o p o r e s c r it o
o b te n e r e l v e r e d ic to
s i e s p o s ib le .
www.FreeLibros.org
No conoce nuestro negocio, as que cmo propone decirnos io que ei

nuevo sistema debe ser? L a r e s p u e s t a a e s t o e s : T i e n e r a z n : p o r e s o
lo
e s to y
e n t r e v is t a n d o
p a ra
a v e r i g u a r lo
que
u s te d
o p in a
s o b re
lo s
re q u e -
584
R EG LA S DE E STIM A C IO N
r im ie n o s .
sugiera
p a rte ,
P or
v a r ia s
del
o tro
la d o ,
m a n e ra s
t r a b a jo
que
si
el
u s te d
es
mejorar
de
u s u a r io
hace
a n a lis t a
a s tu to ,
(particularmente
co sa s
a c tu a lm e n te
es
v ie ja
sea
in e v it a b le .
S in
tanto,
s i to d o
r e s u lt a d o
d e l s is t e m a ) ; p o r
e m b a rg o ,
lo
a d e cu a d o
ta i
vez
una
de
d@
siendo
l o m s h u m i l d e posible, y c o n s t a n t e m e n t e r e c o n o c e r l o e x p e r t o que e|
u s u a r i o e s e n s u r e a d e t r a b a j o , a l a vez q u e c o n t i n a p i d i n d o l e que
t e n g a l a amabilidad d e e x p l i c a r l e ( c o n t r i b u y e n d o d e e s t a m a n e r a a s u en
tendimiento) p o r q u n o funciona s u i d e a .
im p la n t a c i n
c o m e n t a r io
e ineficiente
un
la s
e s t e t ip o
e s c o n t in u a r
tratando de cambiar la forma en que hacem os las cosas aqu. Esta

d e l c o m e n t a r i o anterior. D e b e m o s t r a r l e q u e a u n q u e pro
ponga a l g u n o s c a m b i o s ( r a d i c a l e s ) e n l a implantacin d e s u s i s t e m a a c
t u a l , n o e s t t r a t a n d o d e c a m b i a r s u s c a r a c t e r s t i c a s esenciales, excepto
e n l a s r e a s e n l a s q u e e l l o s m i s m o s lo s o l i c i t a r o n .
Sin e m b a r g o , t e n g a
E s t
es
u n a v a r ia n te
en
m e n te
que
a lg u n a s
m a
a c tu a l
p o d ra n
con
o tro s
s is t e m a s
de
la s
te n e r
c a r a c te r s tic a s
que
c o n s e rv a rs e ,
e x te rn o s
requieren
que
de
la
im p la n t a c i n
p o rq u e
t ie n e
e n tra d a s
d e l s is t e
interfase
a lg u n a
s a lid a s
de
fo rm a
p r e d e f in id a .
No queremos este sistema.

q u ita n d o
c ie n d o
e l e m p le o .
ia
nue vo
s is t e m a .
c io n a i q u e
o p in e
La
que
E s ta
es
v e rd a d e ra
p o rq u e
el
una
v a r ia n te
re s p u e s ta
a d m in is tr a d o r
de
e s to
de
la
es
o s
q u e ja ;
que
M e
e s t
u s u a r io s
e s t
a h , h a
q u ie r e
el
asunto s u y o t r a t a r d e c o n v e n c e r a l u s u a r i o o p e r a q u e r e r e l sistema ( n o i m p o r t a l o g r a n d i o s o q u e usted
N o
d eb en
es
e s ); h a c e r e s to
es
a s u m ir la
r e s p o n s a b ilid a d
u s te d
m is m o , y no
le c o r r e s p o n d e .
Por qu est desperdiciando nuestro tiempo con esta entrevista?

bem os
to .
lo
que
P or qu
E s ta
co
no
o b ra ,
pon e
m anos
una q u e j a d i f c i l
que l o s u s u a r i o s
u s u a r io
no
solucin
d a s
c o m p e t e n t e , lo
es
de
tir a
q u e re m o s , y s i fu e ra
p o s ib le
un
re c o n o c e
s e g u id o s
P r e g n te le
C o n s r y a m e
una
fie r o , v e r d a d ?
u s u a r io
de
c a s ita
S in
le n g u a je s
puede
s e n t ir
h a b e r t e n id o
x ito
le
la
ia
analistas
hech o,
comenzar
c o n s t r u c c i n .
b ilid a d
lo s
e s te
con
de
u n a
una
vez
ver con
le n g u a je s
g ra n d e s
Sa
in m e d ia
sistema?".
el
el hech o
b s i
distintos; si
p r o b le m a s .
el
Una
a m p l a
d is p u e s to
d e c ir le
al
d u ra n te
la
a r q u ite c to ,
r e c m a r a s . S a b e a lo q u e m e r e
cuenta que c o n l a a m p l i a d i s p o n i
g e n e r a c i n y c o m p u t a d o r a s p e r s o n a le s , el
i s m o p u e d e c o n s t r u i r e l s i s t e m a ; t a l vez e l
b o n it a
h a b la n
a v e c in a n
e s ta ra
c u a rta
que
hace
de
analoga. P r e g n t e l e a l u s u a r i o s i l e p e r m i
a construir s u c a s a s i n d i s c u s i o n e s d e t a l l a
de
si
le
de
tre s
e m b a rg o , te n g a
de
tr a ta r , p o r q u e t ie n e q u e
es hace r una
a r q u ite c to
p la n o s ,
de
e n te n d e ra
p ro y e c to s
en
s e n c illo s
h o ja s
de
c lc u lo )
www.FreeLibros.org
haya
dad o
im p r e s i n
d e q u e to d o s
E s to p u e d e e x p lic a r e l p o r q u
de su
io s s is t e m a s s o n
im p a c ie n c ia c o n
f c ile s
u s te d .
de
h a c e r.
REGLAS DE E S T IM A C IO N 585
gj
OTROS PROBLEMAS DE LOS QUE HAY QUE CUIDARSE
L a s r e g l a s q u e se dieron a n t e r i o r m e n t e previenen s o b r e m u c h o s p r o b l e m a s
polticos a l o s que se p u e d e e n f r e n t a r d u r a n t e u n a e n t r e v i s t a , y las m u c h a s razones
por l a s c u a l e s un u s u a r i o p o d r a r e s i s t i r s e a s e r e n t r e v i s t a d o . P e r o a n q u e d a n al
gunos o t r o s p r o b l e m a s a l o s q u e s e d e b e a n t i c i p a r :
Una discusin que se enfoca ms a cuestiones de im plan ta ci n que a

cuestiones de requerimientos. E s t o s u e l e s u c e d e r c u a n d o e l u s u a r i o d i
c e : A s e s c o m o
ta n te
su
de
la
s is t e m a
ex-
g u s ta ra
c u a n to
a c tu a l; y
te c n o lo g a
de
la s
que
c o n s tru y e ra
e l u s u a r io
puede
p ie n s a
de
a n lis is d e s c r ib ir la s c a r a c t e r s t ic a s
que
sean
m o d e lo
de
ta n
im p o r ta n te s
im p la n t a c i n
m uchos
cam pos,
c ie n te
h a b la n d o
que
s ie n to
ia
c a ra
c u e n ta
hay
de
que
vez
en
d id a
que
tra ta
p r o b le m a
se
tra ta
el
de
de
de
la q u e ja
dn de
de
un
algo
con
un
M e
s n to m a ,
sntoma,
un
que
de
c o lo c a
u s u a r io
sea
e s t
la
s e d is c u te
con
d e t a lle
en
en
PC
es
r e s o lv e r
d e c ir ,
Lo
qu e
m e
del
se
p re s e n ta
no
del
s n to m a
al
m is m o
de
en
fie
darse
e s p e c ie
h a ce r
de
es
m is m o ,
su ce d e
Es
lu e g o
un a
o tra
m e
e m b a rg o ,
en
g ra n
d ia g r a m a
de
c o n te x to :
p r o b le m a
fu e ra
d e s a r r o llo
e l C a p tu lo
que
p r o b le m a
Lo
pa
e l p r o b le m a ?
a lg u n a
h a y
e n t r e v is t a
e l C a p tu lo 2 1 .
p r o b le m a q u e
sistemas. S i n
frontera e n e l
d e n tro
P o r t a n to , p o n g a e s p e c ia l a t e n c i n
to
un
p r o b le m a .
a n lis is
se
es
pue de
m d ic o .
v e rd a d e ro
la s e n t r e v is t a s d e
E s te
te n g a n
d is c u ti
p r o p ia
una
dei s i s t e m a , a
cabida d e n t r o
im p la n t a c i n
se
su
en
el
c a lle n t e .
se
e n c o n tra r
r e la c io n a d a
un
tarea
su
de l a s c o m p u t a d o r a s . I m a g i n e u n
diciendo: D o c t o r : m i p r o b l e m a c o n s i s t e
en
m d ic o
r e a lm e n t e
dep ende
el que
s lo
no
de
q ue
e s t
s i t ie n e
es
b a s
la implantacin
familiarizado c o n
de
ejemplo,
r e a lm e n t e
d e l u s u a r io
no
a su
de s u p o n e r q u e
bre, q u e indica
la
d e p ende
fro n te r a
d e l m o d e lo
de
s i e s t
a m b ie n ta l; e s
18.
El usuario podra no ser capaz de decir qu quiere que el sistema haga, o

podra cambiar de opinin. E s t e e s u n p r o b l e m a c o m n , y e l a n a l i s t a d e
be
e s ta r p re p a ra d o
m s
im p o r t a n t e
c o n s u lt e
que
R e c u e rd e
Confundir sntomas con problemas.

en
(p o r
un
p ro g ra m a d o r).
e l s is t e m a . .. . S u c e d e
trminos
en
s u c e d e r s i e l u s u a r io
c o m p u ta d o ra s
es
nos
m e
m enudo
el
p a ra
se
e n fr e n ta r lo .
v u e lv e
C a p tu lo
E n tre
e l p r o to tip o .
m s
P a ra
e x tre m o
m s
sea el
in f o r m a c i n
versas
p a rte s
C u a n d o
se
pone
a l a n a lis t a
c o n te n d ie n te s .
hayan
e s to ,
5.
Hay desacuerdo entre colegas, subordinados y administradores.

tu n a d a m e n te , e s to
p r o b le m a ,
s o b re
p u e s to
de
en
C o m o
a c u e rd o
el p a p e l d e
a n a lis ta
s o b re
no
D e s a fo r
n e g o c ia d o r e n t r e
p u e d e
a b d ic a r
lo q u e q u i e r e n ,
a s
re g re s e n
di
d e c ir
y d
reunir
www.FreeLibros.org
g a n m e lo .
las
p a rte s
E n
lu g a r d e
p a ra
e llo , d e b e
t r a b a ja r , p a r a
a c tu a r c o m o
lle g a r a
un
m e d ia d o r y t r a t a r d e
co n se n so .
D e s a fo rtu n a d a m e n
586
R EG LA S DE E S T IM A C IO N
te , e s to
este
E.7
in v o lu c r a
h a b ilid a d e s y
p r o c e d im ie n to s
que
re b a s a n
e l a lc a n c e d e
lib r o .
FORMAS ALTERNATIVAS DE RECOPILACION DE DATOS

Las
q u e r im ie n to s
de
no
son
la
u n s is t e m a .
fu e n t e s , p r o b a b le m e n t e
n ic a
D e
sean
m a n e ra
de
m s
r e c o p ila r in fo r m a c i n
m s
in fo r m a c i n
pueda
p r o d u c t iv a s s u s
e n t r e v is t a s .
E n tr e
h e c h o , e n tre
s o b re
i o s re
otras
las alternativas
r e u n ir d e
a la s e n t r e v is t a s t e n e m o s :
Puede
C uestionarios:
su
organizacin,
e n v ia r c u e s t io n a r io s
la s
p e rs o n a s
(u
por
s is t e m a , a lo s a d m in is t r a d o r e s q u e a p r o b a r o n
Presentaciones de proveedores.
re p u e d e n
sa.
E l p e d ir le s
s is t e m a
que
p u e d e
no
hagan
s lo
sino
t a m b i n
d e o tra
s o lu c i n ,
l n e a
de
n e g o c io s
c o n s t r u ir .
O r g a n ic e
de
m a n o s o b re
p r im e r a
u s u a r ia .
a s o c ia n
con
h u b ie r a n
B u sque
te n g a n
v is ita
C a p tu lo
to r ia
18,
e s to
u o b s o le t a .
m ilia r iz a r s e
con
S in
e m b a rg o ,
u s u a lm e n t e
N o
de
u s u a r io s
s o ftw a re
a p lic a c i n
la s
si
con
el
de
e llo s
de
el
h a rd w a
le
in t e r e
p a ra
de
o fre c e
su
una
d e f u n c io n e s y d a
d e s a p e r c ib id o s ,
que
s im ila r e s
in s ta la c i n
que
c a r a c te r s tic a s
pasa do
s is t e m a s
la
lo s
te n g a n
al
que
o b te n e r
la
m is
p re te n d e
in fo r m a c i n
la s c a r a c t e r s t ic a s y c a p a c id a d e s d e l s is t e m a .
in c lu ir
a n te s
de
en
de
p ro g ra m a s
m e n te
s is t e m a .
q u e
buen
de
se
d is c u ti
re d u n d a n te ,
p u n to
la o r g a
C o m o
in fo r m a c i n
se r un
procedimien
m a n u a le s ,
lis ta d o s
del
o b s ta n te , s u e le
e l te rre n o
re p o rte s ,
te n g a
implantacin actual
la
de
d e te r m in a r
Recoleccin de datos: Busque f o r m a s ,

tos e s c r i t o s , d e s p l i e g u e s d e p a n t a l l a s y
n iz a c i n
la
a s e a la r r e q u e r im ie n to s
qu e
una
m a n e ra
Visitas a otras instalaciones:

m a
p a ra
p r e s e n ta c i n
a y u d a r le
in te r a c t a n
e l p ro y e c to , y a o tro s .
p ro v e e d o re s
s is t e m a s
una
a lm a c e n a d o s q u e
buena
to s
Los
h a b e r d e s a r r o lla d o y a
e s c r it o
o r g a n iz a c io n e s ) q u e
de
r e a liz a r e n t r e v is t a s
en
se
el
c o n t r a d ic
p a r t id a
p a r a fa
p e r s o n a le s
c o n el
u s u a r io .
Investigacin externa:
cin
n u e v a , s o b re
m u n ic a r
su s
s o c ie d a d e s
de
E.8
la
S i e s t
c u a l e l u s u a r io
r e q u e r im ie n to s ,
p r o f e s io n a le s
(p o r
libros
r e v is t a s t c n ic a s ,
no
t ie n e
e n to n c e s
e je m p lo ,
d e te x to
un
s is t e m a
e x p e r ie n c ia
d e b e
ia
la
de
aplica
una
p a ra
b u s c a r
A C M ,
artculos
p a ra
p o d e r le c o
in fo r m a c i n
IE E E ,
la
de
D P M A ), o
in v e s tig a c i n .
RESUMEN
Las
h a b ilid a d e s
de
c o m u n ic a c i n ,
la
d ip lo m a c ia
o tra s
c u e s t io n e s
hum anas
www.FreeLibros.org
in v o lu c r a d a s
ne
que
id e a
en
la
a p re n d e r
a co m p a a r
e n t r e v is t a
con
la
no
p r c t ic a
u n v e te ra n o
son
o
f c ile s
la
de
e xp o n e r en
o b s e r v a c i n :
o b s e rv a r a lg u n a s
com o
un
lib r o .
analista
E s
a lg o
n o v a to ,
q u e t ie
es
buena
A d e m s , o b te n g a
re -
R E G LA S DE E S T IM A C IO N 587
su
t r o a lim e n t a c i n : p d a le
mo hace
sus
se u s a r n i o s r e s u l t a d o s
perdicio d e t i e m p o .
de
je fe
que
d e le s
su
in v e s tig u e
lo
que
r e tr o a lim e n t a c i n
p a ra
que
a
no
los
lo s
u s u a r io s
o p in a n
s o b re
u s u a r io s : d g a le s
p ie n s e n
que
to d o
fu e
p a ra
qu
un
des
1.
A b ra h a m
M otivation and Personality.
M a s lo w ,
N u e va
Y o rk :
H a rp e r
&
R ow ,
1954.
2.
C h a r le s
J.
Stewart
e d ic i n , D u b u q u e ,
3.
W illia m
S.
D a v is ,
C ash
lowa:
S te w a rt,
W illia m
Interviewing Principies and Practices,
C . B ro w n ,
Systems Analysis and Design: A Structured Approach.
d in g , M a s s .: A d d is o n
W e s le y ,
2a.
1978.
R ea-
1983.
www.FreeLibros.org
APENDICE
J r"
CASO BE ESTUDIO:
F.1
INTRODUCCION
N in g u n a
nos
un
e je m p lo
d is c u te n
da
en
e s te
sea
e s tu d io
d is c u s i n
q ue
lib r o .
ilu s t r e
la s d iv e r s a s
de
d e s is t e m a s
D e s a fo rtu n a d a m e n te , e s
c o m p le ta m e n t e
e s t e r iliz a d a
que
s o b r e a n lis is
lu s t r e
f ic t ic io , o
situacin
la
u n a a p lic a c i n
b ie n
r e a l.
sea
p r o b a b le
a lo s
c o m p le ta
s e ra
de
s in
e x c e s iv a m e n te
d if c il
e n c o n tra r
n e g o c io s c o m o a
me
se
caso de
p o r lo
m o d e la d o
q u e c a s i c u a lq u ie r
u n a v e r s i n
A d em s,
o r ie n ta d a ta n to
e s ta ra
y t c n ic a s
que
s im p lif ic a
ejemplo
un
la c ie n c ia .
d e e s t u d i o describe l o s r e q u e r i m i e n t o s d e c o m p u t a r i z a c i n de la s
de p r o c e s o de i n f o r m a c i n d e YOURDON P r e s s . P o r u n l a d o , e s m u y
caracterstico d e la a c t i v i d a d e d i t o r i a l r e a l v i g e n t e durante a l r e d e d o r d e 1 0 aos. D e
E s te
caso
a c t iv id a d e s
hecho, una de
p re
se
a s
hacen
v id a
de
lo s
P o r o tro
pues
m a c i n
se
Las
delo
de
s is t e m a s
ra z o n e s
m u ch o s
tienen
m o s tra r e n
e s te
r a c io n a le s
p ro y e c to s
que
la d o , Y O U R D O N
P r e n t ic e - H a ll la
han
h u b ie r a n
P re s s d e
D O N
por
d e
lid ia r c o n
caso
d e e s tu d io
( in c lu y e n d o
la
d e s a r r o llo
de
m uchos
d e t a lle s
es que
fo r m a c i n
n o s ie m
de
s is te m a s ) ,
com pa
que la
en la
d e s a g r a d a b le s
r e a l.
t ic io s ,
qu e
co sa s
iniciacin
la
m a y o ra
la s c o s a s q u e q u ie r o
la s
in c o r p o r a d o
s id o
lo s
fa s d e
siguientes
im p la n t a c i n
en
s e c c io n e s
se
a l a s f i l a s de los e j e m p l o s f ic
sus actividades d e p r o c e s o d e in f o r
P o r e l l o , e s t e caso d e e s t u d i o d e s c r i b e lo
p r o c e s o d e informacin d e Y O U R D O N
in c o r p o r
1986, y
s ta .1
h a b e r c o n t in u a d o c o m o
P r e s s , e l m o d e lo
de
P re s s y a
c o m p r
de
e d it o r ia l in d e p e n d ie n t e .
o fre c e n
una
b re v e
re s e a
a m b ie n ta l d e l s is t e m a , e l m o d e lo
de
de
la
o p e r a c i n
de
c o m p o r ta m ie n to
YOUR
y
el mo
d e l u s u a r io .
1 E n tre ta n to , la s a c tiv id a d e s d e p ro c e s a m ie n to d e in fo rm a c i n de P re n tic e -H a ll la s e s t asumiendo

su n u e v a c o m p a a m a triz , S im n & S c h u s te r. Y e s ta ltim a e s p a rte d e u n a e m p re s a a n mayor,
G u lf + W e s te rn , lo c u a l d e m u e s tra q u e io s s is te m a s c a s i s ie m p re so n p a rte d e s is te m a s m ayores.
www.FreeLibros.org
C A S O DE E ST U D IO : YO U R D O N P R E S S ,589
F.2
antecedentes
P a ra
de
e n te n d e r c m o
t ie m p o
e x is ta :
e x p lic a n d o
Y O U R D O N
aunque,
s in
Y O U R D O N
a o s
estos
el
lo s
b re
tener
s u e le
p a ra
la
en
o f ic ia le s
in c .
p a sa r un
d e n tro
e x is tid o
el
p a ra
e s ta d o
de
no
h u b ie r a
poco
la
Y O U R D O N
p io a p e lli d o .
cual
P re s s ;
lo g r a d o
de
m i
a s
a n a lis t a s
Los
de
p g in a s
p r o g r a m a c i n
en
el
fin a lm e n te
Structure and Design,
se
fo rm
un c o n s u l t o r a u t o e m
funcion realmente
de
en
im
p le a d o .
s in o
de
la
m a y o ra
de
ra m o s
dos
de
m ,
la
nos
q ue
q u ie n e s
c o m p a a ,
decidimos
d e c id im o s
n e c e s a r ia s ,
se m a n a s
p r im e r a
in fo r m
que
(y
esp o sa
d e m a s ia d o
nos
h a s ta
que
el
h a b a
al n o m b re
de
n o m b re
e s ta d o
de
a p ro b a d o
una
la
o tra
nicos
e l n o m b re
de
e s c o g im o s
n in g u n a o tra
c o m p a a
n o m b re
ya
compaa
r p id a m e n te
de
e x is te n te .
e ra
un
N ueva
b a m o s
p ro g ra m a
el
c o m p a a
no
S u p e r-
ju s to
d e s e m in a r io s s o b r e
se
p ro
nom
e l m e m b re te
p o r el
en
lo s
un
lo s
g u s t
d esp us, cu a n d o
s e r ie
no
e l n o m b re
P ro d u c
n o m b re
del
te n d ra : m i p ro
in c .
la
c o m p a a
v e te ra n o s
de
c o n v ir t ie r o n
p u b lic a d o
se
in
d u ra n te
e l re a
fu e ro n
d is e o
g ra n d e s
de
seminarios
s is t e m a s
en
lnea,
en
un
lib r o
p o r P r e n t ic e - H a ll e n
d e te x to :
so
d ir ig id a s
a g e n c ia s
seminarios eran d e u n a s 2 0 h o r a s d e c l a s e - p i z a r r n ,
d e n o t a s ; las n o t a s d e l s e m i n a r i o sobre t c n i c a s
n a m e n ta le s .
100
de
que
p e n sa r en
s o lic it u d e s
n u e s tra
a c t iv id a d e s
a c t iv id a d e s
L a c o m p a a
v e n ta ja s
la s c o m p a a s
e m p le a d o s
A s , n a c i Y O U R D O N
a va n za d a s
la s
r e a liz a n d o
p r im e r a s a c t iv id a d e s f u e
Inc.2 D e s e s p e r a d o s ,
razonablemente s e g u r o s q u e
p r im e r a s
b re t c n ic a s
de
e s ta d o
io s 7 0 .
la s
no
Finalmente
nos
p a re c a
de
de
P e lu d o s , I n c . , p e r o
h ic im o s
a n u n c io s
h a b a
se r
m is
A
y
A n im a le s
yo
lu g a r d e
m a y o ra
in v e s tig a m o s , e n c o n tr a m o s
cu a l e s t b a m o s
unas
h u b ie r a
c o r p o r a c i n
S u p e rm e rc a d o ,
Las
n e c e s a r io
1974.
documentos.
c o m p a a : s e
C uando
la
la
c o m p a a .
L td . , e
e s tru c tu ra d a ,
to s d e
es
c o r p o r a c i n
d e l c r e c im ie n to
qu e
in fo r m
e s ta b le c e r e l n o m b re . C o m o
a p o n e r a lg u n o s
n u e s tr a
la
Y O U R D O N
y c o m ie n z o s
d e d a to s ), u n a d e
d ir e c to r e s ,
p ro g ra m a d o re s ,
c i n
no
que
e n se a n za
p r c t ic o s ,
su ce d e r en
n u e s tro s
Y o rk , p a r a
P re s s ,
de
resultado
com o
de
corporacin
una
d e A lc a c h o fa s y O tr o s
en
in o c e n t e s , e n a b r il d e
a d e cuado
c a b ra
Inc.,
c la r o
m i c o n ta d o r m e
c o n s e jo s
p ro c e s o
a c c io n is t a s ,
e s t
lo s a o s 6 0
p o rq u e
pesar de
C o m o
P re s s ,
c o n s u lt a
a f in e s d e
p u e s to s o fr e c a
y e c to s d e
a m p lio
Y O U R D O N
in c . s e f o r m
de
1973
d a d e
S in
m s
goza.
d e p e n d ie n te s
a b r il d e
YOURDON
t r a b a ja b a
c o n te x to
in c .
Y O U R D O N
x ito d e i q u e
varios
el
g u b e r
acom pa ados
a va n za d a s
de
Techniques o f Program
1975.
2 C u a n d o lo in v e s tig a m o s , d e s c u b rim o s q u e S u p e rm a rk e t P ro d u c ts se e n c o n tra b a en a lg u n a p a rte

de ia p e rife ria d e la c iu d a d d e N u e v a Y o rk y q u e se o c u p a b a p rin c ip a lm e n te d e im p o rta r p l ta n o s de
G u a te m a la . N o v e a m o s q u te n a q u e v e r e s to con la s c o m p u ta d o ra s n i p o r q u n u e s tro n o m b re
haba d e in te rfe rir c o n e l p o b re S u p e rm a rk e t P ro d u c ts o rig in a l, p e ro o p ta m o s p o r e lu d ir el c h o q u e
con la b u ro c ra c ia .
www.FreeLibros.org
590
CASO DE ESTUDIO: YOURDON PRESS
D e b id o
n o ta s
c a n
en
a
un
de
com o
S in
lo s
de
de
lo s a o s 8 0 , y
p ro c e s o
de
d a to s
s o n a l t c n ic o
p ro y e c to s
de
C A S E ,
con
a p n d ic e
un
A.
E U A
de
de
a h o ra
N o
ya
p a q u e te
de
p re p a ra d o
de
o tro s
30
s is t e m a s
aos
80,
la
o tra s
de
en
unos
p a s e s .
T a m b i n
de
lo s
c o m p a a
in c . t e n a s u c u r s a le s
50
p a ra
que
c o m e n z a ro n
e n 8 c iu d a d e s ,
d e l p e r
analistas en
en
N o rte a
de
el
con alrededor
al
se
m e
c lie n t e s
in g r e s
d e i t ip o
lib r o s .
m ie m b r o s
p ro y e c to
c o m p a a s
des
de los
notas y,
la s a c t iv i d a d e s d s
2 5 0 ,0 0 0
de
p a re
se
la s
la v e n t a d e
to d o
m uchos
de
se
a lg u n o s
a p r o x im a d a m e n te
c o n s u lt o r e s , je fe s
de
ca b e za
ias
im p r im ir
ra s g o s
a d ic io n a le s
s o b re
a u m e n t
ha
de
g ra n d e s
o b s ta n te ,
c o p ia s
p r o f e s io n a l, y
lo s
in c . n e u r s io n e n
c o n c e n tra b a
son
de
1987, Y O U R D O N
que
q u e d a ra n
c o m p ra r
m s
d e s a r r o llo
m e d ia d o s
p ro d u c to
En
d e c o n s u lt o r a
la c o m p a a
E u ro p a .
p g in a s
d is tin to s
compaa
io s
io s s e m in a r io s , c o n v in o
a s
p r o v o c a c i n .
in c . s e
c u rs o s
la
en
im p o r t a n t e s
m r ic a
a s
p e d a n
e m b a rg o , Y O U R D O N
de
de
m e n o r
p a r a le lo , Y O U R D O N
c r e c e r la s a c t iv id a d e s
de
la
en
p a r t ic ip a n t e s
e n c u a d e r n a r la s ;
s e m in a r io s
n e g o c io
e n s e a n z a : e l n m e ro
d ia d o s
a lg u n a s
libro
d e i
p a r t ic ip a n t e s
ello,
n m e ro d e
m o d e ra d o
lib r o , a u n q u e
p r e n d ie r a n
por
gran
a!
v o lu m e n
m e rc a d o
d e s c r ib e
en
1 5 0 e m p le a d o s .
Y O U R D O N
P re s s
s u r g i
com o
u n a d iv is i n
de Y O U R D O N
in c . e n
1 9 7 6 , c o n la
Structured Design, d e Y o u r d o n y C o n s t a n t i n e ; Learning to

Program in Structured COBOL, d e Y o u r d o n , G a n e y S a r s o n ; y How To Manage
Structured Programming, d e Y o u r d o n . C o m o s u c e d i c o n m u c h a s o r g a n i z a c i o n e s
r e a l e s de n e g o c i o s , e s t o r e s u l t s i n m u c h a p l a n e a c i n o p e n s a m i e n t o o r g a n i z a d o :
p u b lic a c i n
lo s
lib r o s
de
tre s
p a re c a n
e s tru c tu ra d a s
que
lib r o s :
se r una
se
anza de Y O U R D O N
Los
IB M
tre s
S e le c t r ic
se
t e s d e lo s d a s d e
c o n s is ta
a
inc.
Las
v e n ta s
e x is te n c ia ,
E n
t e l f o n o
tu ra s
ta n
e ra n
P re s s
p a c io s d e
p o p u la r iz a r lo s
y v e n d ie n d o
en
c o n c e p to s
de
t c n ic a s
lo s s e m in a r i o s
de
ense
h o ja s
de
uno s
de
la
con
de
edicin
c u a n to s
lis ta
de
a yud a
8 .5
de
de
re p re s e n ta b a
una
m q u in a
p u lg a d a s ; to d o
e s c r it o r io f c il.
a n u n c io s
c lie n t e s
modestas;
de
11
de
en
lo s
hecho,
e s c r ib ir
fu e a n
L a p u b lic id a d e ra
Computerworld
s e m in a r io s
d u ra n te
una
s lo
de
e s to
lo s
p e q uea
de
d e co
Y O U R D O N
p r im e r o s
fr a c c i n
a o s de
de
lo s
in
a c tiv id a d e s
de
por
la c o m p a a .
e ra
p o r c o rre o ,
el
s is t e m a
m o d e s to
p e ro
m s
no
en
in d iv id u a lm e n t e
bod ega
en
d e t ip o s y
P re s s
m e c a n o g r a f ia b a n
em pacab an
de
p r o d u je r o n
ig u a lm e n t e
Y O U R D O N
c o n s e c u e n c ia ,
se
slo
in t e g r a n t e s
g r e s o s g lo b a le s d e
Y O U R D O N
se
a s e le c c i n
m u n ic a d o s
su
lib r o s
e n c u a d e rn a ro n
m o d e s ta , y
lo s
m a n e ra
desarrollando
in c .
p r im e r o s
y
b ue na
e s ta b a n
se
de
informacin
c o m p le ta m e n t e
a c e p ta b a n
p e d id o s
fo rm a s
de
m ano.
E l in v e n t a r io
e le g a n te s
del
fa c tu ra
mundo:
de
la s
m a n u a l.
de
con
o f ic in a s
to m a b a n
ta r je ta
c u a tro
se
p r im e r a s
S e
a lm a c e n a b a
en
e l p is o
crdito.
de
ta n to s ,
38
p e d id o s
o s
L a s fa c
p e d id o s
en
uno
de
la
de
se
lo s e s
s u c u rs a l de
www.FreeLibros.org
Y O U R D O N
M a n h a tta n .
in c .,
situada
en
el
1133
de
A ve n u e
o f th e
A m e r ic a s ,
con
v is t a
to d o
C A S O DE E STU D IO : YO U R D O N P R ESS 591
En
| {adora
|
el v e ra n o
^ s ta rd e , s e
ie
de
P D P - 1 1 /4 5
1976
un
lle g
la
a u to m a tiz a c i n ,
m is t e r io s o
a a d ie r o n
una
s is t e m a
m q u in a
en
o p e r a t iv o
de
ia
de
fo rm a
lla m a d o
una
U N IX .3
fo to c o m p o s ic i n , d o s
m in ic o m p u U nos
doce nas
m eses
de
t e r m i-
I p a l e s y el p a q u e t e T R O F F p a r a c r e a c i n d e t i p o s . E s t o i n m e d i a t a m e n t e f a c i l i t l a
I produccin d e l i b r o s d e t e x t o d e Y O U R D O N P r e s s y f i n a l m e n t e l l e v a l a a u t o m a t i z a i cn d e d i v e r s o s a s p e c t o s d e l n e g o c i o d e e n s e a n z a y a c t i v i d a d e s g e n e r a l e s d e c o n a b iiid a d
de
Y O U R D O N
in c .
P e ro
la s
a c t iv id a d e s
I p r e s s , es d e c i r , l a s q u e s e c o n s i d e r a r a n
i ron e n f o r m a m a n u a l d u r a n t e v a r i o s a o s
En
198 0
se
P re s s , u s a n d o
tema o p e r a t i v o
r io s
U N IX . E n tr e
p ro g ra m a s
p a ra p r o c e s o
d e s a r r o ll
te c o n f i a b l e s
del
S h e ll
de
de
e s to s
en
d a
t ie n e n
p o r e je m p lo , n o
se
al s i s t e m a , s i n o
que
p e d id o , q u e
se
C II, t e r m i n a d o
U n a
P re s s
d e
la
e ra
de
p o d a n
se
e n tre lo s
de
de
en
difcil.
s ie m p r e
que
la
p a re c a n
de
fo rm a
en
d if c ile s
de
ia
(q u e
s e n c illo s
r e p o r te s v a r io s
e le c tr n ic o
te n a n
p e d id o
fo rm a
de
de
d a to s
de
un
len
lim it a c io n e s ;
de sp u s
de
donde
re p o rte s y
c ie r t a s
U N IX
o p e r a c i n
de
se
de
p a ra
s im p le
c lie n t e s
d a b a
d ia r ia
que
en
de
Y O U R D O N
de
in g r e s a r lo
m o d if ic a r e l
te x to
en
A S
de
d u ra n te
fo rm a
un
de
P re s s ) c o n
de
Y O U R D O N
m o s tra ra
to d o s
lo s
p e r io d o .
Ei
in t e r a c c io n e s
lo s
r e g is t r o s
Y O U R D O N
in c .
Press y e l d e p a r t a m e n t o
s i n c r o n a . Esto s e complic m s
e ra
Y O U R D O N
e s ta r fu e ra
de
YOURDON
in c . e n
se
sis
va
razonablemen
f r a c c i o n a d a , c o m o l o s que
a c t u a liz a d a
crditos
ra z o n e s ,
p r e c io s
l n e a .
d e c la r a c i n
lib r o s
un
del
C
d e s a r r o lla r y
e s t n d a r d e
s u s e n v o s y s u fa c tu r a c i n
N u e v a Y o r k ; io s
de
T a m b i n
c o m p u ta d o ra
a c t iv id a d e s
diversas
p ro g ra m a s
d e e n v o
p ro c e s o
te x to s
e l d e p a rta m e n to
s u c u rs a l d e
y r e a liz a b a n
s u c u rs a l e n
d ic h a s
c o n s e rv a b a
P or
en
de
g e n e r a c i n .
una
de
c u a n to s
Y O U R D O N
p ro c e s o s
e l le n g u a je
h o ja s d e c lc u lo , g e n e r a d o r e s
e d ito r d e
ia
Y O U R D O N
p a ra
de
g r a d u a lm e n te
f c ile s
y e i p e r s o n a l a d m in is t r a t iv o
ig u a lm e n t e
de l i b r o s
m s
p r o d u c ir
r e c o n c ilia r
que
el h e c h o d e
el
a p lic a c io n e s
uno s
m o d if ic a r io s d e t a lle s
usab a
actividades
la s
f in a n c ie r o s
fu e ro n
u n c a r c t e r d e f in a l d e
ta re a
c lie n t e s
a a d ir
d e s a r r o lla d o
c u a rta
a lm a c e n a b a
con
p a ra
u s a ro n
acceso
de
de
in te r c o n e x i n
d e v e n t a s , e t iq u e ta s
h a b a n
en
lim it a d o
1985 se
U N IX
p e d id o s , p a g o s , d e v o l u c i o n e s
p ro c e s o
p ro g ra m a s
o p e ra r, s e
v e r hoy
lo s u s u a r i o s f i n a l e s
guajes
n m e ro
1980
de
in fo r m a c i n , s ig u ie -
m s.
c a r a c te r s tic a s d e
d e r d e n e s , r e p o rte s
c o n t a b ilid a d . A u n q u e
se p u e d e n
un
la s c o n v e n ie n t e s
o p e r a c io n a le s
un sistema de
com o
daban
en
L o n d re s te n a
e n fo rm a
lib r a s
su
p r o p io
in d e p e n d ie n t e
e s t e r lin a s
en
de
por
in v e n t a r io
a
lo s d e
lu g a r d e
en
la
d~
3 D esde lu e g o , U N IX n o e s ta n m is te rio s o a h o ra , p e ro a m e d ia d o s d e los a o s 7 0 d ifc ilm e n te a l

guien fu e ra d e B e ll L a b o ra to rie s y d e u n a s c u a n ta s u n iv e rs id a d e s lo h a b a n o d o m e n c io n a r. Ni yo
ni la m a y o ra d e m is c o le g a s d e Y O U R D O N te n a m o s ta l g ra d o d e p re c o g n ic i n . L e d e b im o s n u e s
tra d e cisi n -lo q u e m s ta rd e h u b im o s q u e a g ra d e c e r p ro fu n d a m e n te - a lo s a p re m io s d e l D r. J.
Plauger, q u e h a b a e n tra d o a n u e s tra e m p re s a p ro c e d e n te d e B e ll L a b s en 1975. P la u g e r e s a m
pliam ente c o n o c id o p o r los lib ro s q u e e s c rib i en c o la b o ra c i n c o n B ria n K e rn ig h a n , e n tre io s q u e
se cu e n ta n T h e E le m e n ts o f P ro g ra m m in g S ty le (E le m e n to s d e i e s tilo de p ro g ra m a c i n ) (R e a d in g ,
Mass.: A d is s o n -W e s le y , 1 9 7 3 ) y S o ftw a re T o o ls (H e rra m ie n ta s d e p ro g ra m a s y le n g u a je s ) (N u e v a
York: M c G ra w -H ill, 19 7 6 ).
www.FreeLibros.org
C A S O DE E STU D IO : YOURDON PRESS
592
la r e s
e ra n
vez
U na
p o r lo
g e n e ra l u n
a l tr im e s tr e ,
co n vo ca b a
la s
im p r e s a s
s a lid a s
dad,
La
o c a s io n e s
g e n te
se
P or
in ic ia l
te n a n
y fru s tr a n te s
ju n ta s
de
se
c o m p u ta d o ra
eso,
o b je to s
p a ra
nu e vo
en
se
de
la s
un
a o tro
e q u ip o
de
1986,
e ra
P re s s
s is t e m a .
c m p u to
c o m p o s ic i n
d iv is i n .
(y a
e v id e n te
Ib a
S in
se
a d q u ir ie r a
la o p e r a c i n
tic e -H a ll.
ponden a
P o r t a n t o , lo s
La
s e rie
in c .
de
su
in ic io
de
la
en
c re c e r
que
1984
nueva
el
de
m a n u a lm e n te
e ra u n a
N o
de
c o n t a b ili
r e c o n c ilia r
o b s c e n id a d e s
te n d ra
t a m b i n
s id o
com o
un
1974
1986,
p a ra
m e jo r
s is t e m a
lo s
la s dife
en
gra
a d je t iv o s ;
a c t iv id a d
la
h a s ta
una
lo
que
su s
la
de
lle v
sistema
p la n e a c i n
r e q u e r ir a n
no
m q u in a
s lo ca
d e f o to -
m e rc a d e o
d e s c r ib e n
s
se
o rg a n iz a c i n ,
e d ito r ia le s
de
a la f u s i n
de fe
grartds
m s
Pren
corres
con
a c o n t in u a c i n
Y O U R D O N
in fo r m a c i n
Y O U R D O N
P re s s
c o m p a a
p a ra
que
un
la
P re s s
h u b ie r a
in d e p e n d ie n t e .
de
m u e s tra
d e s a r r o lla r
com enz
e v id e n te
que
se
que
se
m o d e r n iz a r
s is t e m a
d iv is i n
e ra
a c t iv id a d e s
s e ra
n e g o c io
nuevo
qu e
c r e c e r la
p u b lic a c io n e s , y e s to f u e
o r g a n iz a c io n a l q u e s e
una
f in a n c ie r a s . $6
c o m p a ra b a n
d e l s a l n .
se
t a m b i n
la s
qu e
m o d e lo s d e
h u b ie r a n
en
s in o
d e c id i
de
o p e r a c i n
p la n e a c i n
E n tre
a a d i
qu e
su
c a m b io s
D esde
tru c tu ra
lo
s u c u r s a l n e o y o r q u in a 4
se
c o n t in u a r c r e c ie n d o ;
e m b a rg o ,
a d ic io n a l,
o b s o le t a )
F in a lm e n t e
c o n t in u a d o
la
in t e n t o
in s u lt o s ,
c a n t id a d e s s u b s t a n c ia le s p a r a c o n t in u a r h a c ie n d o
ra
de
d e c la r a c io n e s
p o r
en
P re s s
la d o
lo s
c u a le s
p r o d u c id a s
g r it a b a n
un
que
p re p a ra r
trim e s tre .
si Y O U R D O N
del
c a ro s
que
p or Y O U R D O N
e n o ja b a ;
la n z a b a n
d e s e a b le c a d a
c o m p le to
m s
se
la s p ro d u c id a s
con
re n c ia s .
ta ni
la r g a s
ta n to
cu a n d o
en
se
la f ig u r a
v o lv i
p ro d u c to s
de
t a m b i n
y
c o in c id i
e l r e s to
de
con
una
YOURDON
1 9 8 3 , l a c o m p a a t e n a la e s
F .1 .
un a
s o ftw a re ,
com o
m s
r e g io n a l,
m u e s tra
la
f ig u r a
F .2 .
Y
d u ra n te
e s te
p e r io d o , Y O U R D O N
r a o r g a n iz a c io n a l q u e s e
m u e s tra
en
la
P re s s
f ig u r a
g r a d u a lm e n te
d e s a r r o ll
la e s tru c tu
F .3 .
4 La c u e s ti n d e ios in v e n ta rio s s e p a ra d o s y de la s v e n ta s d e la s o fic in a s s e p a ra d a s se c e rn a ene!

h o riz o n te c o m o un p ro b le m a c a d a v e z m a y o r. En c a d a u n a d e las d iv e rs a s o fic in a s de YOURDON
se in s is ta en q u e n e c e s ita b a n te n e r un p e q u e o in v e n ta rio lo c a l p a ra d a r s e rv ic io a los cliente s que
las v is ita b a n y q u e q u e ra n a d q u irir un lib ro in m e d ia ta m e n te , en v e z d e e s p e ra r v a rio s d a s (o sema
n a s) a q u e se lo s e n v ia ra G a la c tic H e a d q u a rte rs . Y en ia o fic in a c a n a d ie n s e se re c la m a b a que ne
c e s ita b a n su p ro p ia e s tru c tu ra de p re c io s (e s to e s, p re c io s fo rm u la d o s en d la re s c a n a d ie n se s, en
v e z d e e s ta d o u n id e n s e s ) y su p ro p ia c a m p a a d e c o m e rc ia liz a c i n y p u b lic id a d p a ra a tra e r ai mer
c a d o c a n a d ie n s e de m a n e ra d ife re n te q u e a l d e E U A E n a lg u n o s c a s o s , la s o fic in a s le ja n a s simple
m e n te le d a b a n el lib ro a! c lie n te y le p e d a n a la o fic in a c e n tra l d e N u e v a Y o rk q u e generara la
fa c tu ra . E n o tro s c a s o s , el c lie n te p a g a b a e l lib ro en e l s itio m ism o y p e d a un c o m p ro b a n te . Las
v e n ta s d e la o fic in a d e L o n d re s d ie ro n c u e n ta d e a p ro x im a d a m e n te 10 p o r c ie n to d e l to ta l de ingre
s o s d e Y O U R D O N P re s s , m ie n tra s q u e la s v e n ta s d e la s o tra s o fic in a s d ie ro n c u e n ta d e m enos de:
1 p o r c ie n to d e i to ta l d e in g re s o s d e Y O U R D O N P re s s .
www.FreeLibros.org
C A S O D E ESTUDIO: Y O U R D O N P R ESS 593
Figura F.1: E structura organizacional de YOURDON Inc., 1974-1983
Figura F.2: E structura organizacional de
C o m o
Press s e
nal
una
e x is te
dos
una
bo d e g a
de
su
e le g a n te e s p a c io
en
una
s e p a r a c i n
c u a tro
r e o r g a n iz a c i n ,
del
b e lla
fs ic a
y q u ie n e s e m p a c a n
Los
tes
p a rte
m u d a ro n
de
s e c c i n
unos
lo s lib r o s y
g ru p o s
30
la s
de
o fic in a s
del
c e n tro
k il m e tr o s
lo s m a n d a n
p r in c ip a le s
d e n tro
de
in c .,1984-1986
Y O U R D O N
de
e n v o
que
o cu p a b a
de
Y o n k e rs ,
e n tre
q u ie n e s
de
Y O U R D O N
e l re s to
N u eva
del
p e rs o
Y o rk .
in g r e s a n
lo s
A s ,
p e d i
a lo s c lie n t e s .
Y O U R D O N
P re s s
te n a n
la s s ig u ie n
r e s p o n s a b ilid a d e s :
www.FreeLibros.org
Servicios adm inistrativos,
te r a c c io n e s
c o tid ia n a s
se
e n tre
h a c a n
re s p o n s a b le s
Y O U R D O N
P re s s
de
la
lo s
c lie n t e s .
m a y o ra
de
la s
in
P o r ta n to ,
594
C A SO DE ESTUDIO: YO U R D O N PR ESS
Figura F.3: E structura organizacionai de YOURDON Press
g ru p o
e s te
a c e p ta b a
d e v o lu c io n e s
e l e n v o
de
lib r o s
m o s e d is c u ti
con
fa c tu ra s ,
c lie n t e s ,
in te r a c t u a b a
P re s s ,
c i n
con
Y O U R D O N
y b o le t in e s
de
de
de
de
de
c o m e r c io , d e
lo g r a r
pagos,
d is c u ta
para
c o n ta b ilid a d , c o
la
bod ega
m a n d a r f o lle to s
de
p r o m o c i n
d is c u s io n e s c o n
te l f o n o
g ru p o
se
h a c a
p a rte
de
Y O U R D O N
E s ta
lo s a u t o r e s
d i v e r s o s li
r e v is t a s
lib r o s t c n ic o s d e c o m p u t a c i n ,
e s te
lo s
en
c o m p ra n
lib r o s .
p o r
de
a n u n c io s
Adquisiciones,
v e n ta s
p r o d u c ir c a t lo g o s
c o lo c a r
c lie n te s ,
nue vos
con
a n t e r io r m e n t e .
Ventas y mercadeo,
de
re c ib a
p ro d u c a
lo s
b ro s
p e d id o s ,
c r d it o
h a s ta
c a rg o
g ra n d e s
de
e l m o m e n to
nue vos
lle v a b a
de
c o m p u ta
a
lis ta s
c o r p o r a c io n e s
encontrar
P re s s
de
ca b o
la e n t r e g a
de
que
au to re s y
to d a s la s
d e l m a n u s c r i
t o f in a l.
Editorial,
b ro
g ru p o
p u b lic a d o .
c i n
con
E l g ru p o
io s
te n e rs e
D ebe
p e q u e a
im p r e s o r e s
en
de
R andom
ia e s c a la d e
d e c o n v e r t ir e l m a n u s c r it o
in v o lu c r a b a
p a ra
se
o b te n e r
h a c a
la
e d ic i n
p ro p u e s ta s
e n tre g a d o
s in o t a m b i n
p a ra
de
e n u n li
l a in t e r a c
la im p r e s i n
in ic ia l.
ilu s tra c io n e s
la s
y la
la p o r t a d a , a d e m s d e s u c o n t e n id o .
c u e n ta
c o m p a ra d a
P r e n t ic e - H a ll,
id e a d e
n o s o lo
e d ito r ia l t a m b i n
p r o d u c c i n
te
E s to
con
que
Y O U R D O N
H ouse.
D e
ta n
P re s s
b ie n
la s s ig u ie n t e s
e ra
u n a o p e r a c i n
c o n o c id a s
e s ta d s tic a s
co m o
se
r e la t iv a m e n
M c G r a w - H ill,
pue de
fo rm a r
una
la o p e r a c i n :
Y O U R D O N
P re s s
o fre c a
una
lis ta
de
a p ro x im a d a m e n te
50
li b r o s ; tp ic a
www.FreeLibros.org
m e n te s e a a d a n
a la li s t a d e 4 a 6 t t u lo s
n u e v o s a n u a lm e n t e .
C A SO DE E STU D IO : Y O U R D O N P R ESS 595
Los
lib r o s
e s ta b a n
re s , y e l g ru p o
to re s
de
p o t e n c ia le s ,
e x p re s a b a n
Y O U R D O N
E l p e d id o
m e n te
r e c ib a
un
A p a rte
de
m uy
s o lo
se
c ir , u n a
su
h a c a n
p e rs o n a
c o m p ra r a lg n
cheque o c o n
a s c e n d a
tre s
e ra n
la
e s c a la ,
fo rm a
Los
de
te n a n
lib r o ,
en
p e d id o s
c r d it o .
se
P a ra
p a g a rs e
de
500 0
lib r o s
hacen
o tra s
e l c o n c e p to
s e n ta n q u e
un
r a lm e n t e
re g re s a b a n
o c u rra
lo
d a s
de
de
m n e n
in d u s t r ia
la
un
ao
ben d e a n t e m a n o
de
de
la s
que
e l c lie n t e
d e v o lv e r
p a r t ir d e
ia s
una
la
Si
de
a u
in d iv id u o s
no
h a b a n
que
de
la
he
P re s s
fe c h a
de
p o rq u e
( lo
se
de
una
g ra n d e s .
Las
p e rs o n a
(e s d e
P re s s
c u a l e ra
m a y o re s ,
p a ra
ra ro ),
p e d id o s
se
deb e
in d iv id u a l o
su
lo
una
r e c ib a n
d in e r o .
por
in fe rio re s
s o b re
to d o
e s ta r
fa m i
c o r p o r a c i n
d a ado, g e n e
E s to
P o r o t r o la d o ,
lib r o s
de
d e l p e d id o ;
m uchas
lib ro y e v ita n
que
d e fa c tu ra s .
d e lo s
r e c ib o
o p e ra b a
m s
o en
p e d id o s
e le n v o .
la m it a d
lu e g o ,
vez
ca d a
e s t a d o u n id e n s e s
e m p r e s a , lo s
de
tp ic a
d esd e
in c ./ Y O U R D O N
n e c e s id a d e s , o
r e c ib a
h a s ta
d e c ie r t o
ra b a
e fe c tiv o
lo s
cual
$ 1 0 0 , lo
p e d id o s ,
e d ito r ia le s
c lie n te
un
d e v o lu c i n
p u b lic a c io n e s ,
la d e m a n d a
U S
p u b lic a c io n e s , ta m b i n
d e v o lu c io n e s .
p e d a n
de
a
a u to
200
a n u a lm e n t e .
Y O U R D O N
h a ce r en
p o lt ic a
n o s a t is f a c a s u s
de
p r iv ile g io
tra n s c u rs o
de
dado
desp us
del
gozaban
lib r o
2 0 0
p o r e s c r it o , p o r t e l f o n o
p o r a d e la n t a d o ;
c o m p r e n d e r e l n e g o c io
con
de
p e d id o s d ia r io s .
e m b a rg o , Y O U R D O N
lo
p o d a n
C o m o
50
Se c e le b
d la re s
lo s d e l i b r e r a s y d e c o m p a a s , p o r o g e n e r a l r e q u e r a n
liarizado
d o ce n a s
que
p e ro
A lg u n o s
m a y o re s .
5 0 ,0 0 0
la s o f ic i n a s
pagos
que
s in
que
lib r o s .
m s
lle g a r a
ta r je ta
un
c u a tro
lib r o ; o t r o s
p o r m e d io d e
que
d o s
e s c rib ir
por
con
p r o c e s a b a a p r o x im a d a m e n te
p e q uea
lib r o ) .
a 1 0 0 d la r e s
co n
p e d id o c o n v a lo r d e
s im ila r a
d e c ir ,
in t e r s
p r o m e d io
S e e n v ia b a n
m a n e ra
v e n ta s
P re s s
un
por
d e e s c r ib ir a lg o .
re p re s e n ta b a
de
e ra n
es
a lg n
c h o te r m in a d o
e s c r it o s
a d q u is ic i n
e s to
ve ce s
q u e d a rs e
es
un
en
b a s ta n te
lib r e ra s
la s
con
la s lib r e r a s
u n p e d id o
no
in v e n t a r io
ei
co
sa
que
no p u e d e n v e n d e r .
r.3
EL MODELO AMBIENTAL
F.3.1
La declaracin de prop sito s
cenar
so d e
El
p ro p s ito
la
in fo r m a c i n
p e d id o s ,
d e l S is te m a
n e c e s a r ia
fa c tu r a c i n ,
in v e n t a r io s y p r o d u c c i n
de
de
In f o r m a c i n
p a ra
g e n e r a c i n
re p o rte s
de
v e n d e r lib r o s
de
de
r e g a la s
Y O U R D O N
a
lo s
P re s s
c lie n te s .
d o c u m e n to s
(Y P IS )
E s to
es
in c lu y e
a lm a
in g re
d e
e n v o ,
c o n tro l
de
p o r d e re c h o s d e
a u to r y
re p o rte s
de
www.FreeLibros.org
c o n t a b ilid a d .
596
C A SO DE E ST U D IO : YO U R D O N PR ESS
F.3.2
El diagram a de contexto
10.
11 .
A D M IN IS T R A C IO N
12 .
C L IE N T E S
AUTO RES
d i lo g o c lie n te s
d i lo g o a d m in is tr a c i n
13.
d i lo g o ,m e rc a d e o
d i lo g o - a u to r
d i io g o c o n ta b ilid a j
d i lo g o bodega
M ERCADEO
BODEGAS
YPIS
14.
15.
C O N T A B IL ID A D
d i lo g o -v e n ta s
d i lo g o im p re n ta .
VENTAS
16.
d i lo g o ^
e d ito r
17.
IM P R E N T A S
E D IT O R E S
A G E N C IA S
D E C R E D IT O
18
Figura F.4: Diagrama de Contexto para el sistem a YPIS
19
20
F.3.3
La lista de acontecim ientos

La
La
lis ta
m a y o ra
p a rta m e n to
n u a c i n ;
de
a c o n te c im ie n to s
e s t n
de
d ir ig id o s
d e l s is t e m a
p o r f lu jo ,
lo s t e m p o r a le s s e
son
a un que
t e m p o r a le s .
m a rc a n
con
Y P IS
la
Los
2.
E l c lie n t e
3.
El
c lie n te
p id e
in fo r m a c i n
4.
El
c lie n t e
p id e
p e r m is o
5.
E l c lie n t e
p re g u n ta s o b r e
e l s ta tu s d e a lg n
6.
E l c lie n t e
p re g u n ta s o b re
el
7.
E l c lie n t e
r e q u ie r e
un
e n v a s u
de
en
lo s
40
que
a c o n te c im ie n to s .
in v o lu c ra n
al de
se
conti
lis t a n
22
23
u n a T lu e g o d e s u d e s c r ip c i n .
El
p id e
c o n s is te
m a y o ra
1.
c lie n t e
lib ro
21
( e s to t a m b i n
in c lu y e
p e d id o s
u r g e n t e s e s p e c ia le s ) .
24,
pago.
de
s o b re
a lg n lib ro
d e d e v o lv e r u n
s ta tu s
25.
( p r e c io , e tc .) .
lib r o .
26.
p e d id o .
d e a lg u n a fa c tu ra .
u n a d e c la ra c i n (m e n s u a l).
(T )
27.
28.
www.FreeLibros.org
8.
E l c lie n t e
p id e
un
9.
E l c lie n t e
dese a
r e c o r d a to r io
d e c r d it o .
29 .
un ch e q u e
de
r e e m b o ls o .
C A S O DE E STU D IO : YOURDON P R ESS 597
E l d e p a rta m e n to
d e c o n t a b ilid a d
r e q u ie r e
de
r e c ib o s
E i d e p a rta m e n to
requiere
de
re p o rte s d e v e n ta s
El
contabilidad
de
r e q u ie r e
( d ia r io s ) d e e f e c t iv o .
( d ia r io s ) .
(T)
(T)
un reporte (mensual) de ventas
de
n e ta s . (T )
de
r e q u ie r e
de
un
re p o rte
( tr im e s t r a l) d e
r e g a la s
p o r d e r e c h o s d e a u to r . (T )
r io .
de
r e q u ie r e
El d e p a r t a m e n t o d e c o n t a b i l i d a d requiere
nes s o b r e v e n t a s . (T)
L a a d m in is t r a c i n
La
d e
d a to s
( m e n s u a le s )
de
in v e n ta
de
comisio
(T )
f ija
un
nuevo
r e q u ie r e
l m it e
de
un
de
un
re p o rte
d e c r d it o
r e p o rte
p a ra
de
( m e n s u a l)
un
c lie n t e .
c u e n ta s
p o r
c o b ra r
v e n c id a s
( m e n s u a l) . (T )
L a im p r e n t a d a
u n a c o t iz a c i n
L a a d m in is t r a c i n
L a im p r e n t a
a u t o r iz a
n o t if ic a
de
p e d id o
u n p e d id o
la c a n t id a d
imprenta enva
fa c tu r a
por
La
s o lic it a
c o t iz a c i n
im p r e s i n
(o
de
r e im p r e s i n ) .
im p r e s i n .
exacta de
La
de
de
im p r e s o s y f e c h a
d e e n tre g a .
c o n c e p to
d e tr a b a jo
de
im p r e s i n .
de
u n p e d id o
de
im p r e s i n .
de
m e rc a d e o
p id e
e t iq u e ta s
de
e n v o
de
m e rc a d e o
r e q u ie r e
de
de
m e rc a d e o
n e c e s it a
una
fe c h a
(fe c h a
en
de
la
base
de
d a to s
de
c lie n t e s .
e s ta d s tic a s
s o b re
la s
v e n ta s
de
li
b ro s .
de
d is p o n ib ilid a d
de
nue vos
tt u lo s .
Los
e d ito r e s
a n u n c ia n
un
nuevo
t t u lo
la
que
e s t
lis t o
para impren
ta)
necesitan un
de autor. (T)
L o s a u to re s
chos
r e p o r te tr im e s tr a l d e
La b o d ega
n e c e s it a d a t o s d e e n v o
La b o d ega
r e c ib e
y e t iq u e ta s .
u t ilid a d e s
(T)
p o r c o n c e p to
de
d e re
www.FreeLibros.org
lib r o s d e
ia im p r e n t a .
598
C A S O DE E ST U D IO : Y O U R D O N PRESS
30.
La b o d ega
recibe devoluciones
31.
La
hace
32.
L a b o d e g a e n v a
33.
La bod ega
34.
Ei departamento
35.
U n v e n d e d o r in g r e s a
36.
37.
El
38.
E i a u t o r n o t if ic a
39.
E ! c lie n t e
40.
S e n e c e s it a
F.4
EL MODELO DE COMPORTAMIENTO
bod ega
cliente
F.4,1
C a da
un
de
elige
libro
un
un
m e rc a d e o
c a m b io
( m e n s u a l) .
s e h a a g o ta d o .
p e d id o
u n c a m b io
c lie n t e .
u n c lie n t e .
a d q u is ic io n e s
de
un
fs ic o
p e d id o
a n u n c ia q u e
n o t if ic a
uno
flujo
de
v u e lv e
d ia g r a m a
1 9 , s te
c lu s o
in v e n t a r io
un
lib r o s d e
a n u n c ia
d e p a rte
proyecto
el
de
un
un
nuevo
lib r o .
cliente.
un
d e c la r a q u e
de
est agotado.
lib r o
d e d o m ic ilio .
d e d o m ic ilio .
p a r t ic ip a r e n
e l p la n
e n v ia r fa c tu r a s
agencia.
de
a u n c lie n t e . (T )
El m odelo p re lim in ar de com portam iento: diagram as de flu jo de datos
grama
b ro
un
de
poco
lo s
Los
asociado.
p r c t ic o ,
e l t ip o
v a r ia s
40
d a to s
h o ja s
de
re p re s e n te
e je r c ic io
u n id a s .
d ia g r a m a s
se
rramientas
C A S E ,
la
es
que
D e jo
M ass.
m enos,
to d o
el
r e q u ie r e
con
la
A u nque
de
una
v e r s i n
para
de
e s te
tran
lo s a lm a c e n e s d e l D F D
con
lib r o .
la
la
de
40
de
F .3 .3
tie n e
im p r e s i n
d ia g r a m a s
C o m o se
h o ja
s e a l
en
pap el m uy
un dia
li
un s o lo
capitulo
d e un
en
el
g r a n d e , o in
a i le c to r .
del p a q u e t e Design, d e M e ta
un p a q u e t e c o m p l e t o d e he
d e i o s p a q u e t e s s e n c i l l o s de
2 .0
a y o ra
una
c o m p u ta d o ra
P a r a a c o p la r s e
n o ta c i n
s e c c i n
re p re s e n ta
de
us
la
c o n e c t a r lo s
e je r c ic io
no
en
lo g s t ic a
sistema.
elaborado que i a m
s e r ejecutable e n
m s
v e n ta ja
ia p r e p a r a c i n
lis ta d o s
lu e g o , la
e s to c o m o
d ib u ja r o n
In c ., C a m b r id g e ,
g r f ic a s , y t ie n e
D esde
p o r d e c i r lo
que
c o m p u e s to
es
S y s te m s
de
de
de
la f ig u r a
M a c i n t o s h , q u e se
programa Design,
al
mues
se
F .5 .
! NO M BR E DEL ALM AC EN
Figura F.5: N otacin para los alm acenes en el caso de e studio de

YOURDON Press
www.FreeLibros.org
Al
c a m b io s
d e b a jo
d ib u ja r
lo s
D F D
q u e v i q u e te n a
de
cada
D F D .
La
p r e lim in a r e s
que
to m
hace r en
razn
de
e s to
o tra s
n o ta
los
del m
de
p a rte s
e s e n f a t iz a r q u e
e rro re s
o d e lo ;
en
un
que
e n c o n tr
y los
estas
n o ta s s e
listan
p ro y e c to
re a l
el
ana
C A S O DE E ST U D IO : YO U R D O N P R ESS 599
lista
ra ra m e n te
s is t e m a , y
e n c u e n tr e n
m odelo
d ib u ja
lu e g o
e rro re s
h iz o
N o se
m o lla r e l m o d e l o
se
en
D F D
p e rfe c to
el
D FD
de
a i p r im e r in te n to ; d e s p u s
s e g u im ie n t o
que
se
e s t
con
e l u s u a r io ,
e x a m in a n d o
n in g n
in te n to d e
c re a r
un
d ic c io n a r io
p r e lim in a r d e l c o m p o r ta m ie n t o .
tra z a ro n
M uchos
g u ie n t e s .
un
en
de
es
p e n s a r s o b re
in e v it a b le
a lg u n a
el
que
se
p a rte
o tra
del
s is te m a .
del
del D F D
obvios.
de
de
e s p e c if ic a c io n e s d e
esos
c o n t in u a c i n
e rro re s
se
c re
se
un
p ro c e s o
m u e s tra n
c o n ju n to
de
d a to s o r g a n iz a d o
D e sp u s
p a ra
com o
de
de
al d e sa
c r e a r e l m o d e lo
d e te r m in a r s i e x is ta n
D F D
p o r n iv e le s
en
la s
y se
in ic ia l
e rro re s
p g in a s
s i
d e s a r r o ll
el
d ic c io n a r io d e d a t o s .
Acontecim iento 1: El c lie nte pide un libro
Notas
1.
T ra s
d ib u ja r
la
p r im e r a
v e r s i n
de
e s te
d ia g r a m a ,
re c o rd
que
lo s
p e d id o s
con
www.FreeLibros.org
ta r je ta
a lg n
de
c r d it o
l m it e
p r e f ija d o .
r e q u ie r e n
Y O U R D O N
P re s s
a u t o r iz a c i n
a c e p ta b a
s i la c a n t id a d
p e d id o s
p a g ados
s o b re p a s a
con
M as-
600
2.
C A SO DE E ST U D IO : YO U R D O N P R ESS
te rc a rd ,
V is a
quetado
com o
un
P e n sa r
la
3.
D E
T a m b i n
c a m b ia r e l l m it e
b o d e g a ; to d o s
C o m o
de
te s e n
d ib u j
ARCHIVOS,
el caso
la
de
de
e s te
que
un
se
N o
un
que
se
una
que
cliente
e l t e r m i n a d o r e t i
se
s e a lm a c e n a n
la
b o d ega
d a ).
O lv id
de
p e d i
in m e d ia t o
en
r e c ib e
lo s
a c o n te
1 6 ).
a
PEDIDOS.
de
s im p le m e n te
2 8 ),
un
un
e x c e p c i n
e n v a n
de
in c lu ir
re q u e ra
la
se
qy8
lmite-
hech o
( a c o n t e c im ie n to
u rg e n te s
c o p ia
que
se
m o d e lo
s ,
e t iq u e ta s
p e d id o s
g e n e r
s i s u r g ie r a
u rg e n
el
de
una
se
d e l v e n d e d o r),
N o
puede
d is p u ta
u n a lm a c n
en
una
s e necesita l a c o p i a de
r e g e n e r a r ) , p e r o l o s de
p e d id o
e l p e d id o .
qu e
de
o r ig in a l d e l c lie n t e
con
e l c lie n t e ,
(o ,
m s
en
caso
de
la s a u t o r id a d e s d e im p u e s t o s , e tc .
r e c ib ir u n
en
p a ra
necesidad
p o r e s c r it o
la f o r m a
e s e n c ia l ( d a d o
por
e s to
m e d i c u e n ta d e
d e l p e d id o
p o r t e l f o n o ,
pue de
m o s tra m o s
con
por uno, con
p e d id o s
c o r r e s p o n d ie n te s
D F D , t a m b i n
es
d o c u m e n to s
O b s e rv e
in t e r f a s e
e v id e n te
del
uno
e n v a n
lo s
a u d it o r a s o in v e s tig a c io n e s d e
5.
v o lv i
d e c r d it o
p e d id o s
a p a rte
p e d id o
en
la
in ic ia l d e l p r o g r a m a .
la f a c t u r a
fa c tu ra
ms
dem s
( n o r m a lm e n te
la v e r s i n
C u a n d o
c o p ia
lo s
a c o n te c im ie n to
e n v o
p o r e llo
C R E D IT O .
Observe q u e l o s p e d i d o s no se
dos u r g e n t e s . L o s d e t a l l e s d e
la
4.
cam po.
para
E x p re s s ;
m s sobre l a s i t u a c i n d e l c r d i t o h i z o o b v i o e l
cliente e n e l a l m a c n d e CLIENTES t e n d r a q u e
de
com o
c im ie n to
A m e r ic a n
A G E N C IA S
poco
d e f in ic i n
cr d ito
D F D
p e d id o
a n t e r io r ,
p o r c o r r e o , p o r t e l f o n o
p o rq u e
to d a s
s ta s
o en
son
p e rs o n a .
f u n c io n e s
de
tra n s p o r te .
6.
O b s e rv e
ta.
E n
que
in v e n t a r io
s u lta d o
e l s is t e m a
lu g a r d e
ha
eso,
b a ja d o
no
v u e lv e
r e p e t id a s
m s
a ll
d e l a c o n te c im ie n to
a u to m tic a m e n te
ve ce s
se
le
in fo r m a
d e l u m b r a l a c tu a l.
1 , a ! ig u a l q u e
com o
p e d ir lib r o s
la
E s to
impren
la
pue de
r e s u lt a d o
de
q u e un
o c u r r ir c o m o
d iv e r s o s
re
a c o n te
c im ie n to s m s .
7.
S e
pue den
de
eso
de
r e c ib ir p e d id o s d e
nue vos
c o m p a a s q u e c o n t in u a r n
se
te n d r
que
d e s c u e n to , e tc .
b u ja
1 y e l a lm a c n
c re a r u n
E s ta
es
nue vo
la
clientes
h a c ie n d o
r e g is t r o
ra z n
de
(s o b re to d o
n e g o c io s c o n
la
en
de
CLIENTES
f le c h a
de
lib r e r a s
Y O U R D O N
dos
con
la
ta s a
ca b e za s
nuevas
P re s s ).
Por
e s t n d a r
entre
la b u r
C L IE N T E S .
www.FreeLibros.org
C A S O DE E STU D IO : Y O U R D O N PRESS 601
Acontecimiento 2: El cliente enva su pago.
Notas:
1.
El pago
de
puede
c u le s
estn
pag ando; a
dan com o
2.
en
el
p r o p ie d a d
q u ie r a
no
de
gos
de
t iv o
no
c la r o
in c lu s o
fa c tu ra s
tip o
la
La
n o m b re
fa c tu ra
en
s u p o s ic i n
lib r e r a
X Y Z
nos
ya
el
v ie n e
s ie m p r e
id e n t if ic a n
se
q u e d a
la
p a g a ro n ;
p a g o . E s to
X Y Z
ia c iu d a d
de
in c lu s o
que
la
si
lla m a r n
de
B.
ia
c la r o
fa c tu r a
en
que
o c a s io n e s
s o b re
pue de
ia
se r que
Los
lla m a d a
m a n d a n d o
que
to
ser
c h e q u e c u a l
p ue de
d ir n
in v o lu c r a d a .
continuamos
nos
un
P re s s ,
c o m p a a
de
su ce d e
c iu d a d
S i lle g a
Y O U R D O N
u n a c a te g o r a
es
no
no
in e x is t e n t e s .
de d n de
almacenan
se
que
li b r e r a s : ia l i b r e r a
PQR
ia
p e ro
c lie n t e s
u n c o n g lo m e r a d o , P Q R , d e
a s e n ta d o .
re tra s a d a s
d is tin ta s ,
lo s
n m e ro s d e fa c tu ra
d e te r m in a r
e s te
ve ce s
id e n t if ic a n
C o r p o r a c i n
pod am o s
fa c tu ra s
A
de ca d e n a s de
de
la
tra ta .
ve ce s
que da
caso
diversas
se
r e fe r e n c ia
no
veces
do
c u b r ir
fa c tu ra s
pa
e fe c
fa c tu r a s
fa c tu ra
la
pag
P Q R .
3.
N o
existe
gu n o s
c lie n t e s
e n v o ;
de
g a ra n ta
p ag os
tra ta n
e s to
son
de
de
que
a lto s
e v ita r
u s u a lm e n t e
el pago
o
b a jo s
el pag o
da
com o
se a
por
del
p o r la c a n t id a d
una
p e q u e a
im p u e s to
r e s u lt a d o
e x a c ta
de
la f a c t u r a .
c a n t id a d
al
a z a r.
s o b re
p ag os
uno
la
o
v e n ta
d o s
lo s
d la r e s
A l
A lg u n o s
g a s to s
de
p o r a b a jo
lo c o r r e c t o .
www.FreeLibros.org
602
C A S O DE E ST U D IO : YO U R D O N PRESS
A contecim ien to 3: Ei clien te pide inform acin sobre un libro.
Notas:
1.
E l c lie n t e
do
se
e s p e ra
te n e r
en
p re g u n ta
e x is te n c ia
c o s a s ta le s
c ie r t o
com o
lib r o , o
e l p r e c io
e l p ro g ra m a
d e l lib r o ,
de
o cun
por
d e s c u e n to s
v o lu m e n .
www.FreeLibros.org
C A S O DE E STU D IO : Y O U R D O N P R ES S 603
Acontecimiento 4: El cliente pide perm iso de devolver un libro.
Motas:
1.
S e
su po ne
que
o s
c lie n t e s
deb en
a n t e s d e d e v o lv e r o s lib r o s .
2.
Los
lib r o s d e v u e lt o s
lle g a n
d e r o n o a la d e v o lu c i n
3.
O b s e rv e
que
una
o b t e n e r la
N o s ie m p r e
m s ta rd e
a p r o b a c i n
se
a u t o r iz a d a
de
Y O U R D O N
P re s s
hacen.
s o lic it a d a q u e
d e v o lu c i n
lo
a u t o r iz
t ie n e
qu e
30) y pueden
c o rre s p o n
a q u .
c o rre s p o n d e r c o n
e l p e d id o
o r ig in a l.
www.FreeLibros.org
604
C A SO DE E ST U D IO : Y O U R D O N PR ESS
A contecim iento 5: Ei clie nte pregunta sobre ei status de un pedido.
1.
P uede
lis ta
en
de
h a b e rs e
el e n v o d e l p e d i d o d e a l g n c l i e n t e
la bodega o porque n o h a y libros del ttulo
re tra s a d o
espera
en
e x is te n c ia .
E s te
r e tra s o
p o te n c ia l e s
el que
tp ic a m e n te
d e b id o
r e q u e r id o
lle v a
una
p r e g u n t a d e l c lie n t e .
2.
Si
el
decide
c lie n t e
3.
O tr a
p o s ib ilid a d
(p o rq u e
c in a
4.
Y O U R D O N
cho,
es
s te
se
P re s s
haya
la
la
p e r d id o
cliente.
oficina
en
h a b e r
el
se
r e c ib id o
c o rre o
tra ta
y v o lv e r a h a c e r e l p e d id o ) .
ra
por
la
o f ic in a
s e p a ra d o s ).
c a n c e la r
(o
de
ei
de
c e n tra l
P o r e llo ,
los
de
lib r o s
en
la
h a ya
se
tra ta
r e c ib id o
de
un
p ro c e s a d o
e n v ia d o
o tra
en
de
que
el
a g e n c ia
m is m a
p o r la
Y O U R D O N
n e c e s it a m o s
haya
p e d id o
D F D , m e d i c u e n ta
(e l e n v o
no
incluso
c r d it o
c lie n t e s
Press
en
p ue de
a lo s
e i p e d id o ,
com o
un
8 ).
el
c o rre o
p e d id o
de
la
o f i
d e Y O U R D O N ).
b o d ega
E s to
d e c id ir
c lie n t e
A l d e s a r r o lla r e s te
a ltu r a s
Y O U R D O N
e l c o rre o
pue de
que
e s ta s
q ue
en
o de
p o s ib le
al
e s
p e r d i
d e l c lie n t e
c a m in o
5.
se
c a n c e la r a
a p a rte
m a n e ra
e s te
no se
el
p e d id o ;
pedido,
de
han
Press
son
dos
a p a rte
e je m p lo ,
pue de
e n v ia d o
b o d e g a , y e l e n v o
a lm a c n
h e
que
tra n s p o rte )
(p o r
p u n to ,
de
p e ro
de
en
el
p e d ir
fa c tu ra s
la f a c t u
p a ra
la s f a c t u r a s ,
www.FreeLibros.org
y
u n a c o n te c im ie n to
te m p o r a l q u e o c a s io n e
e l e n v o
de
la s f a c t u r a s .
CASO DE E STU D IO : Y O U R D O N P R ESS 605
acontecimiento 6: El cliente pregunta acerca del status de una factura.
Notas:
1.
La
se
pregunta
cotiz e n
del
cliente
u o tro s a s p e c to s d e
2.
Si
e l c lie n t e
pue de
la f a c t u r a , o c o n
hace
P a ra
r a r la
e s te
un a
p r e g u n ta
a c o n te c im ie n to , s e
in fo r m a c i n
gunta-factura,
qu e v e r con
la t a s a
d e d e s c u e n to
e n v o , im p u e s to s
s o b re
que
la v e n t a
la f a c tu r a .
e t c ., la p a r t e d e l s is t e m a q u e
3.
t e n e r a lg o
lo s im p u e s t o s d e
s o b re
com o
lo
m s
to d o s
u n nm ero-factura
(num ero-factura e s u n
n e c e s it a
e l p e d id o ,
s e v e r
g e n e ra l s o b re
sus
p e d id o s ,
pagos,
m a n e ja e s e l a c o n te c im ie n t o 7 .
e n e l d ic c io n a r io
p a ra
p o d e r re c u p e
c o m p o n e n te
de
pre
d e d a to s .)
www.FreeLibros.org
606
C ASO DE E ST U D IO : Y O U R D O N P R ESS
A contecim ien to 7: El cliente requiere un estado de cuenta (mensual).
Notas:
1.
A i t r a b a ja r s o b r e
p e r m it ie r a
2.
D F D ,
d e s c u b r
s o lic it a r c r d it o
la
n e c e s id a d
que e s t e a c o n t e c i m i e n t o e s
generan r e g u l a r m e n t e , una vez al
O b s e rv e
se
e s te
a l c lie n t e
de
un
que
8 ),
te m p o r a l ( p o r e je m p lo ,
la s
d e c la r a c io n e s
m e s ).
www.FreeLibros.org
C A SO DE E ST U D IO : YO U R D O N PRESS 607
Acontecimiento 8: El cliente pide un recordatorio de crdito.
1.
S e
le
p u e d e o t o r g a r u n c r d it o
U n
error
en
se
le c o b r
E l
c lie n t e
m a lt r a t
p e d id o
mercanca
r e c ib i
r e c ib i
e rro r d e
E l c lie n t e
c u b r ir lo
se
o r ig in a l ( ta l v e z
le
razones
d is tin ta s :
d io e l d e s c u e n to
e q u iv o c a d o , o
m a l, e t c .)
la
menos
bodega.
r e c ib i , e n lu g a r d e q u e
p o r m uchas
(por
d a a d a
e je m p lo ,
la
o f ic in a
de
c o rre o s
lo s lib r o s ) .
E l c lie n t e
un
el
a u n c lie n t e
pag
en
a r tc u lo s
E n
le
exceso
( n o r m a lm e n te
e s te
de
lo s s o lic it a d o s
s u rta n
el
una
m s
e s to
s e r a
en
solicita c r d i t o
r e s t o del p e d i d o .
p u n to
fa c tu ra s
o b v io
en
su
a n t e r io r e s
c u a n to
p e d id o
p o r lo s
d e b id o
lib r o s
a ca b a
r e c ib ie r a
la
que
de
a
no
d e s
s ig u ie n te
www.FreeLibros.org
d e c la r a c i n ) .
608
CASO DE ESTUDIO: Y O U R D O N PRESS
H ubo
un
excesivo
r e tra s o
el
en
e n v o ,
a s que
e l c lie n t e
d e c id i
c a n c e la r
e l p e d id o .
2.
Lo
p r in c ip a l q u e
e s ta
b u r b u ja
t ie n e
que
h a ce r es
a c t u a liz a r e l s a ld o
de
c r d it o
d e l c lie n t e .
3.
N o o b s ta n te , o b s e rv e
m ie n t o
se
que
le
se
d ib u j
p ue da
que
p a ra
la
g e r e n c ia
m o s tra r
O b s e rv e
ta s s e
qu e
e s ta
m a n e ja n
deb e
a c t iv id a d
de
a u t o r iz a r e l c r d it o .
re s p u e s ta
r e s p o n d e r a l c lie n t e .
d e s o lic it u d e s d e a u t o r iz a c i n
4.
una
E s to
in m e d ia t a
e v ita
tener un
c r d it o , q u e s e r a
n a d a t ie n e
que
de
ve r con
la
E s te
a lm a c n
n e c e s a r io
a c o n te c i
g e r e n c ia ,
d e o tra
de
p a ra
p e n d ie n t e
m a n e ra .
lib r o s ; s
p o r s e p a ra d o .
A contecim ien to 9: Un clien te desea un cheque de reem bolso.
1.
E s to
e s t
e l c lie n t e
b ie n
lo
s i e l c lie n t e
a p lic a r
c h e q u e , p o rq u e
t ie n e
c o m p ra s
n o p la n e a
s a ld o
de
fu tu ra s .
c r d it o .
S in
c o m p ra s fu tu r a s o
En
la
m a y o ra
e m b a rg o , e n
p o r a lg u n a
de
o c a s io n e s
o tra
lo s c a s o s ,
dese a
un
ra z n .
www.FreeLibros.org
C A S O DE E ST U D IO : Y O U R D O N P R ES S 609
Acontecimiento 10: La contabilidad requiere recibos (diarios) de efectivo.
Acontecim iento 11: El departam ento de co n ta b ilid a d necesita reportes

(d iarios) de ventas.
www.FreeLibros.org
610
C A S O DE E STU D IO : Y O U R D O N P R ESS
Acontecimiento 12: El departamento de contabilidad necesita un reporte de

ventas netas (mensual).
www.FreeLibros.org
Acontecimiento 13: El departamento de contabilidad requiere un reporte

(trimestral) de regalas de autor.
Notas:
1.
te n e r a c c e s o
l a s d e l a u t o r p a r a
e l lib r o
a l a lm a c n
( e l m is m o
L IB R O S
p a ra
o b te n e r
la
ta s a
a u to r p u e d e te n e r d ife r e n te s
de
re g a
r e g a la s
p a ra
lib r o s d is tin to s ) .
2.
S e g u ro
3.
te n e r a c c e s o
N e c e s it a m o s t e n e r a c c e s o
la n to s
34) y
al
a lm a c n
A U T O R E S
p a ra
o b te n e r
el
n m e ro
de
S o c ia l, d o m ic ilio , e tc .
(q u e
pue den
a c t u a liz a r lo s
a l a lm a c n
h a b e rs e
p a ra
L IB R O S
g a r a n t iz a d o
r e f le ja r la s
p a ra
co m o
r e g a la s
d e t e r m in a r s i e x is te n
r e s u lt a d o
a c u m u la tiv a s
del
a de
a c tu a le s
qu e
se
de
n e g a tiv a s
si
la s
b e n a l a u to r.
4.
O b s e rv e
q u e la s
d e v o lu c io n e s d e
r e g a la s
lib r o s
de
p a ra
a lg n
un
p e r io d o
lib r o
d ad o
d a d o
pue den
e xce d e n
al
ser
n m e ro
de
lib r o s
p e d i
dos.
www.FreeLibros.org
5.
q u ie r e
e l a lm a c n
d e t a lle s
s o b re
27.
P E D ID O S
q u i n
p o rq u e
c o m p r
lo s
lib r o s .
N o
de
n e c e s it a m o s
e s to
en
re
el
612
Acontecimiento 14: Ei departamento de contabilidad requiere datos de

inventario (mensuales).
Notas:
1.
El
in v e n t a r io
se
a c t u a liz a
d o s , d e v o lu c io n e s , r e c ib o
2.
O b s e rv e
h a b e r
un
que
sido
este
in v e n t a r io f s ic o
p ro c e s a ro n
re p o rte
e n v ia d o s
p e ro
en
m u e s tra
p o r la s
hecho
q ue an
fo rm a
d e e n v o s
en
no
lib r o s
bod egas.
e l m is m o
no se
han
s in c r o n iz a d a
nue vos de
que
No
com o
la im p r e n t a
se
han
r e s u lt a d o
p e d id o ,
in s ta n te
d e b id o
de
p e d i
e in v e n t a r i o fs ic o .
los
p e ro
pueden
c o rre s p o n d e r
p e d id o s
no
con
q u e y a se
e n v ia d o .
www.FreeLibros.org
613
C A S O DE E ST U D IO : YO U R D O N P R ESS
Acontecimiento 15: El departamento de contabilidad requiere un reporte

(mensual) de comisiones sobre v e n t a s .
Notas:
1.
E s to
no
su po ne
ha
m s pag a y
2.
O b s e rv e
que
c ib e n , s in
sea s en
3.
E s te
se
lo s v e n d e d o r e s
Ig n o ra
t ie n e
m uchas
el
que
suceso
v e n ta s
no
se
s e r s o lic it a d a s , c o m o
p e r i d ic o s
m o d e lo ta m b i n
se
les
pag a
re a l d e
in v a lid a r la
factura
a s o c ia n
r e s u lt a d o
comisin a u n s i
una c o m i s i n si el
una
r e v e r tir
ei
cliente
c lie n t e
ja
a s o c ia d a .
con
de
un
v e n d e d o r in d iv id u a l; s e
c a m p a a s d ir e c ta s
re
p o r c o rre o ,
re
y r e v is t a s c o m p u t a c io n a le s , e tc .
supo ne
comisin, y q u e s t a
gerencia p u e d e cambiar l a
ta s a
la
que
pagado.
de
todos l o s v e n d e d o r e s se l e s p a g a l a misma
ia misma p a r a t o d o s los l i b r o s . S i n e m b a r g o ,
t a s a d e c o m i s i n c a d a vez q u e o c u r r e e s t e a c o n
que a
es
te c im ie n to .
4.
E l m o d e lo
ta m b i n
v e n d e d o re s ,
supo ne
p o rq u e
que
( s ie n d o
deb em o s
m o s t r a r lo s
v e n d e d o re s
detalles
p a r a n o ic o s
d e l p e d id o
tp ic o s )
no
c re e n
lo s
en
ia
c o m p u ta d o ra .
www.FreeLibros.org
614
CASO DE E ST U D IO : Y O U R D O N PRESS
Acontecimiento 16: La gerencia fija un nuevo lmite de crdito para un cliente.
Notas:
1.
L a g e r e n c ia
puede
v e r s id a d
m o tiv o s , d e
de
a
de
fa c tu ra s
ia
q u ie b r a
le s d e
p r e v ia s .
o
si
la
t a m b i n
crdito d e u n c l i e n t e p o r u n a d i
es l a t a r d a n z a e n l o s p a g o s
p o d r a h a c e r s e si el c l i e n t e h a do
que
c a m b ia d o
d e c id ir c a m b ia r e l
lo s
cuales
Sin e m b a r g o ,
gerencia s i e n t e
lmite
el m s
han
de
com n
la s
c o n d ic io n e s
g e n e ra
n e g o c io s .
www.FreeLibros.org
C A S O DE E STU D IO : YO U R D O N PRESS 615
Acontecimiento 17. El departamento de contabilidad requiere un reporte

(mensual) de cuentas por pagar retrasadas.
www.FreeLibros.org
61 6
C A S O DE E ST U D IO : YO U R D O N PR ESS
Acontecimiento 18: La imprenta ofrece una cotizacin para un pedido de

impresin (reimpresin).
Notas:
1
Observe
la
2.
que
C o m o
e l s is t e m a
c im ie n to .
s is t e m a
g e r e n c ia
no
(P o r o tro
p o n s a b ilid a d
la
el
no
p ro c e s a
la
c o t iz a c i n
de
la
im p r e n t a ;
s im p le m e n te
p a s a a la g e r e n c ia .
de
lo
p ro c e s a , n o
la d o ,
se
s e r v ir c o m o
de Y O U R D O N
p ue de
q ue da
el por qu
De
su ce d e
e l s is t e m a
e s te
s t ie n e
a c o n te
l a re s
imprentas
e x te rn a s y
c u a lq u ie r f o r m a , p r o p o r c io n a
c a p a c id a d
c o n d u c to , o
P re s s .)
c la r o
a rg u m e n ta r q u e
n te rfa s e , e n tr e
f u t u r a d e h a c e r p e d id o s a u t o m a tiz a d o s , b a s a d o s
en
lo s c r it e r io s
p re s e n te s .
www.FreeLibros.org
C A S O DE E STU D IO : YO U R D O N P R ES S 617
Acontecimiento 19: La gerencia autoriza un pedido de impresin.
www.FreeLibros.org
618
C A SO D E E ST U D IO : Y O U R D O N PR ESS
Acontecimiento 20: La imprenta inform a sobre la cantidad exacta de impresos

y la fecha de entrega.
Notas:
1.
f ic a d o
con
del
de
para
lib r o
p o d e r
e l a c o n te c im ie n to
14,
n e c e s it a
e s ta r
le
p e r m it e
p r im e r o - e n - e n tr a r - p r im e r o - e n - s a lir
2.
O b s e rv e
que
c o t iz a c i n
o
en
dficit de
p e d id o
la
de
ia
En
de
m o m e n to
la
c a n t id a d
im p r e s i n
im p r e s i n
e s te
supone que la
e s to
o r ig in a l.
203 7
de
(FIFO,
la
o r ig in a l e n
lib r o s ) .
in f o r m a c i n
c o p ia s
en
c o s to s
e s t a r a l c o r r ie n te
p o r s u s s ig la s
im p r e n ta
p r c t ic a ,
200 0
la
a l c o r r ie n te
no
h a r
im p r e n t a
un
de
1 o
un
T p ic a m e n te ,
p a r a c o t iz a r c a r g o s d e e n v o
e l p e d id o
E s to ,
d e l in v e n t a r io
en
m o d i
junto
e n f o rm a
in g l s ) .
substanciales a su
imprime e n e x c e s o
c i e n t o ( p o r e j e m p l o , un
r e s u l t a r e n r e a l i d a d en
c a m b io s
tp ic a m e n te
un
lib r o
la
s o b re
unitarios.
por
puede
im p r e n t a
t a m b i n
e s p e ra
h a s ta
y o tro s .
www.FreeLibros.org
C A S O DE E STU D IO : Y O U R D O N P R ES S 619
Acontecimiento 21: La imprenta enva la factura del trabajo de impresin
Notas:
1.
E s to
que
su po ne
m e n te .
la
g e r e n c ia
que
O b s e rv e
m a a la g e r e n c ia d e
i 2.
E s te
m o d e lo
p r e s i n .
: 3.
O b s e rv e
lib r o s
m a qu e
4.
E s to
se
O b s e rv e
la
que
fa c tu r a c i n
no
im p r e n t a . C o m o
ta m b i n
a lg u n a s
de
que
el
la f a c t u r a
un
se
h a b r
hace
la
im p r e n t a
in m e d ia t a
q u e s im p le m e n te
in fo r
en
s e p a ra d a
un
p e d id o
p a ra
de
cada
p e d id o
im p r e s i n
forma sincronizada
con
a p a r t e , la b o d e g a
a la
de
im
vez.
e l e n v o
informa
de
a l s is t e
im p r e n t a .
de
modificada
im p r e n t a s
la
e llo .
m o n to
de
c h e q u e , s in o
u n a fa c tu r a
s lo
lo s lib r o s d e
e n la e s t im a c i n
que
p ro d u c e
h a b r
su po ne que
r e c ib ie r o n
supone
m u e s tra
5.
que
p o r la
re s p o n d e r
no
la n e c e s id a d
supo ne
T a m b i n
Y P IS
la
fa c tu ra
es
in s is t e n
en
el
pago
el
m is m o
que
el
que
se
2 0 ).
p a r c ia l d e
fa c tu ra s ;
e s te
www.FreeLibros.org
m o d e lo
n o to m a
e n c u e n ta e s o .
62 0
C A S O DE ESTUDIO: YOURDON PRESS
Acontecimiento 22: La gerencia pide cotizacin de un pedido de impresin.
1.
O b s e rv e
que
d e r c o m p a ra r.
da
2.
una
u s u a lm e n t e
E s ta s
se manda
O b s e rv e
que
la s
se
se
s o lic it a n
r e c ib e n
la g e r e n c i a
im p r e n t a s
no
cotizaciones
re s p o n d e n
e m b a r g o , s u p o n e m o s q u e a lg n
a v a r ia s
c o m o a c o n te c im ie n to s
d a
con
im p r e n t a s
p a r a po
n o s in c r o n iz a d o s , y
ca
1 8 ).
una
c o t iz a c i n
de
i n m e d i a t o ; s in
lo h a r n .
www.FreeLibros.org
C A SO DE E STU D IO : YO U R D O N PRESS 621
Acontecimiento 23: Ei departamento de mercadeo pide etiquetas de envo de

la base de datos de clientes.
Event 24: M arketing needs s ta tis tic s on book sales
www.FreeLibros.org
622
Acontecimiento 25: El departamento de mercadeo necesita fecha de existencia

de nuevos ttulos.
www.FreeLibros.org
CASO DE ESTUDIO: YOURDON PRESS 623
Acontecimiento 26: Los editores anuncian un nuevo ttulo (fecha en ia que

estar listo para impresin).
Notas:
1.
A l h a c e r e s te
E s to
ra ra
m o d e l o , v i la
vez
d o m a ta r u n
2.
A u n q u e
e s te
lib r o
de
r e g is t r o
de
e lim in a r a lg n
d a
e d ita r lo
d e a u to r.
re a l y p a rte
y
lib r o s
el d e p a r t a m e n t o d e m e r c a d e o l l e g a
declarndolo a g o t a d o ( a c o n t e c i m i e n t o 3 6 ) .
n o s e c o n s id e r a
nad o
n e c e s id a d
s u c e d e , p e ro
e s t n
E s to s e
r e a lm e n t e c r e a
d e l s is t e m a
p o r e n v ia r lo
hace
en
el
un
d e c id ir c u a n
nuevo registro d e lib ro ( e l l i b r o

que l o s e d i t o r e s h a y a n t e r m i
m enos
im p r e s i n ) , t a m b i n
34.
de b e m o s
c re a r
un
www.FreeLibros.org
624
CASO DE E ST U D IO : YO U R D O N PRESS
Acontecimiento 27: Los autores necesitan un reporte trimestral de regalas.
Notas:
1.
Esto
es
s im ila r
a l a c o n te c im ie n to
13,
e x c e p to
que
el
re p o rte
se
m anda
a lo s
a u t o r e s y n o a c o n t a b ilid a d .
2.
O b s e rv e
da,
que
in c lu y e n d o
dad o.
una
o s a u to r e s
de
id e n t if ic a c i n
no se
les
d e
lo s
r e q u ie r e
c lie n t e s
v e r in fo r m a c i n
q u ie n e s
se
v e n d i
d e ta lla
un
lib r o
d a e s t a in f o r m a c i n .
www.FreeLibros.org
C A SO DE ESTUDIO: Y O U R D O N P R ESS 625
Acontecimiento 28: La bodega necesita datos de envo y etiquetas.
www.FreeLibros.org
626
C A S O DE ESTUDIO: YOURDON PRESS
Acontecimiento 29: La bodega recibe libros de la im prenta.
Notas:
1.
d e e n v o s parciales d e l a i m p r e n t a . E s t o
existe una d e m a n d a t r e m e n d a d e un l i b r o n u e v o
( o t a i v e z de u n a r e i m p r e s i n de u n o e x i s t e n t e ) , l a i m p r e n t a p u e d e apurar el
envo d e los p r i m e r o s c e n t e n a r e s de c o p i a s (tal v e z p o r v a aerea) y m a n d a r el
E s to
n o to m a
s su ce d e
re s to
2.
en cuenta
la p o s ib ilid a d
o c a s io n a lm e n te : s i
m s ta rd e .
Esto s u p o n e t a m b i n q u e i a c a n t i d a d r e c i b i d a
l a especificada e n e l a c o n t e c i m i e n t o 2 0 .
p o r la
b o d e g a
es
la
misma
que
www.FreeLibros.org
C A S O DE E ST U D IO : Y O U R D O N PRESS 627
Acontecimiento 30: La bodega recibe libros de un cliente.
Notas:
1.
E l s is t e m a
si no
han
c o rre o s
d eb en
2.
d a r in s tr u c c io n e s
a u t o r iz a d a s .
( o a la a g e n c ia
s e r d e v u e lt o s a i
Observe
d e c ir ,
puede
s id o
la
la
s ig n if ic a
d e tra n s p o rte
que
b od ega
que
trajo
la
de
rechazar
b od ega
la s
a v is a r
lo s lib r o s ) q u e
a
ia
e l o lo s
o f ic in a
de
p a q u e te s
remitente.
q u e en o c a s i o n e s
informacin que l a
p o n d e r a a lg n c lie n t e
E s to
es
im p o s ib le
b o d ega
d is tin g u ir q u i n
e n c u e n tr a
en
d e v o lv i
e i p a q u e te
lo s
pue de
lib r o s ;
no
es
c o rre s
c o n o c id o .
www.FreeLibros.org
628
C A S O DE E ST U D IO : YO U R D O N PRESS
A contecim iento 31: La bodega realiza un inventario fsico (m ensual).
www.FreeLibros.org
Acontecimiento 32: La bodega enva el pedido al cliente.
Nota:
1.
E s to s u p o n e
que
no
hay
e n v o s
p a r c ia le s d e
un
p e d id o
p a ra
u n c lie n t e .
www.FreeLibros.org
630
C A S O DE E STU D IO : YO U R D O N P R ESS
A contecim ien to 33: La bodega anuncia que no hay en existencia copias de un

lib ro dado.
Notas:
1.
O b s e rv e
qu e
no
p e d id o
2.
C o m o
que
haya
la
s it u a c i n
lle g a d o
in e s p e r a d a m e n te
r e s u lt a d o
ra s e r q u e
de
no se
p ro c e s a d o s , p e ro
la
de
una
no
lib r o
por
el
de
hubo
n o te n e r e n
m o m e n to
e s e e s p r o b le m a d e
en
e x is te n c ia
p r e v ia m e n te
g ra n d e ; o p o rq u e
s it u a c i n
s u rta n
te n e r u n
r e im p r e s i n
ro b o s
e n la
e x is te n c ia
p e d id o s
puede
p e d id a ;
o c u r r ir p o r
p o rq u e
bodega,
un
lib r o
hubo
dad o,
s u b s e c u e n te s q u e
un
e tc .
p u d ie
hayan
s id o
la b o d e g a e n c u e s t i n .
www.FreeLibros.org
C A SO DE E ST U D IO : YO U R D O N P R ES S 631
Acontecimiento 34: El departamento de adquisiciones anuncia un nuevo

proyecto de libro.
Notas:
1.
E s to
si
2.
m u e s tra q u e
e x is te
E s te
a u to r
un
e l a c o n te c im ie n to
a d e la n to
13 d e b e
le e r e l a lm a c n
L IB R O S
p a ra v e r
e x c e d e n te .
t a m b i n
c re a
un
nuevo
r e g is t r o
de
autor
si se
tr a ta
de
un
nuevo.
www.FreeLibros.org
63 2
C A S O DE ESTUDIO: YO U R D O N PR ESS
A contecim ien to 35: El vendedor hace un pedido de parte del cliente.
Notas:
1.
O b s e rv e
hace
que
s te
es
un ve n d e d o r en
ig u a l a l a c o n t e c im ie n t o
lu g a r d e
1 , e x c e p to
qu e
a q u e l p e d id o
u n c lie n t e .
www.FreeLibros.org
C A S O DE E S T U D IO : YO U R D O N P R ES S 633
Acontecimiento 36: El departamento de mercadeo declara agotado un libro.
Notas:
1.
E s to
2.
C u a n d o
que
En
se
la s
p a c io
3.
p uede lo g r a r d e m a n e r a e x t e
un l i b r o d e te rm in a d o . T a r d e o
se
da de
lo g r a
bod egas
lib r e e n s u
s it u a c io n e s
e x is te n c ia s
da
de
com o
se
r e a le s , a
d e l lib r o
d e s c u e n to
O b s e rv e
h a s ta
c la r a c i n
q ue
5.
que
que
en
hayan
es
se
p u n to .
de
e x c lu y e
la p r o p a g a n
b a ja r n
p e d id o s
e x is te n c ia s
hacen
fu tu ro s .
r e s ta n te s
d is p o s ic io n e s
P u d ie r a
e x is te n c ia s
lib r o
p r o d u c id o
tr im e s tr a l d e
que
la s
d e te n ie n d o
lo s p e d id o s
p a ra
a c e ro .
S e
supone
te n e r m s
es
p a ra
el
re s to
de
la s
p e r m it ir s e a l a u t o r o a a lg u n a t ie n
r e s ta n te s
p o r,
e lim in a r s e
de
d ig a m o s ,
$ 0 .1 0
d la
p o r c o p ia .
la b o d e g a t o d a v a
O b s e rv e
m enudo
e s te
c o m p r a r la s
e l r e g is t r o
se
a q u ,
m u e s tra
de
te m p ra n o
in v e n t a r io .
r e s e s t a d o u n id e n s e s
4.
se
d e s h a r n
s im p le m e n te
rn a
puede
no
lo s
r e g a la s .
re p o rte s
A d em s,
m e n s u a le s
p ue de
L IB R O S
de
h a b e r
p o r lo
una
lis ta
de
m enos
y
la
de
p e d id o s
n o h a y a e n v ia d o .
n e c e s a r io
in fo r m a r a
to d a s
la s
b o d e g a s
cu a n d o
o c u rre
e s te
a c o n te c im ie n to .
www.FreeLibros.org
6.
S u p o n e m o s
s i la s
ta r io
en
v e n ta s
re s u lta
p r e s i n .
e s te
han
p u n to
s id o
ta n
v ir t u a lm e n t e
que
no
le n ta s
e x is te n
com o
im p o s ib le
p e d id o s
p a ra
p e n d ie n t e s
c o n s id e r a r s a c a r
im a g in a r q u e
se
h a ra
un
con
el
la
lib r o
p e d id o
im p r e n t a :
de
de
in v e n
r e im
63 4
C A S O DE E S T U D IO : YO U R D O N P R ESS
A contecim iento 37: El clien te anuncia un cam bio de dom icilio .
A contecim ien to 38: Ei autor anuncia un cam bio de dom icilio .
www.FreeLibros.org
C A S O DE ESTUDIO: YO U R D O N P R ESS 635
Acontecimiento 39: El cliente elige escoger ei plan de la agencia.
1.
El
tr ia
p ia n
de
a g e n c ia
p u b lic ita r ia
te , e tc .).
p or un
Lo
c ie rto
de ca d a
lib r o
se
cono ce
usan
una
de
v a r ie d a d
e n v o
c a s i e x c lu s iv a m e n t e
n m e ro
nuevo
b a jo
p la n
de
que
la s
y a c u e rd a n
p u b liq u e Y O U R D O
lib r o s
de
n o m b re s
e s t n d a r , p la n
lib r e r a s .
a c e p ta r u n
N
H acen
c ie r t o
m s
de
un
en
a in d u s
p e d id o
p e d id o
n m e ro
de
v ig e n
in ic ia l
c o p ia s
P re s s .
www.FreeLibros.org
636
CASO DE ESTUDIO: YO U R D O N PRESS
A contecim ien to 40: Se requiere m andar facturas a un cliente.
www.FreeLibros.org
C A S O DE E ST U D IO : YOURDON PRESS 637
p.4.2
El m odelo fin a l del com portam iento: diagram as de flu jo de datos

E l m o d e lo
form e n
gram a d e
d e t a lle s
un
f ig u r a
de
e n la s l t i m a s p g i n a s s e tr a n s
n iv e la c i n a s c e n d e n t e p r o d u j o e l d ia
q u e s e m u e s t r a a c o n t in u a c i n ; e s t a n c o m p le jo qu e n o m o s t r lo s
la s e n t r a d a s y s a lid a s d e c a d a b u r b u ja . Las f ig u r a s s u b s e c u e n t e s
I n ic ia l d e l c o m p o r t a m ie n t o
c o n ju n to
1
to d a s
de
D F D
m u e stra n
lo s a c o n t e c i m i e n t o s
to ( e l 2 6 )
no
g u ra
1.
se
en
n iv e l
un
a d ic io n a l d e b id o
caso
de
p o r n iv e le s .
que
m a n e ra
(e l
se
La
a g ru p a ro n .
E n
un
a s c e n d e n te , y a p a re c e
a la c o m p le jid a d
m o s tra d o
1)
se
o cup
caso, un
com o
una
el
s o lo
a c o n te c im ie n
p ro c e s o
n iv e la c i n
de
la f i
d e s c e n d e n te
d e l p ro c e s o .
www.FreeLibros.org
638
C A SO DE E STU D IO : Y O U R D O N PRESS
Figura 0: El DFD de nivel su p e rio r

entradas-imprenta
entradas de
pedidos /
INVENTARIO
r.
r -
-'
salidas-imprenta
salidas de
pedidos sw
ÂDM INISTRAR';
, IMPRENTAS ;
.Vv
salidas-bodog
/ PROCESAR V " "

'
PEDIDOS ;
entradas-bodega
*
7.
,'INTERACTUAR
j
CON
BODEGAS
salidas mercadeo
/
v-
/ INTERACTUAR '
CON
. entradas(!r-r,,s Ar , r n
mercadeo
^
MERCADEO
/
/
\
\
/ V
' ' ^ ^
" - a
" "
^
T
/
I CREDITOS!
--
ARTICULOSPEDIDOS
DEVOLUCIONES! RE| q | L j ^ > ................................... /

._ S ; ' '
--;/
/. 5
/
/
DETALLES
'
/
' CREAR
\
EVOLUCION. /
<
\
/
REGISTRO DE|
/
LIBROS*
.*3: 7
PRODUCIR
REGISTROS DE \
CONTABILIDAD
1
r
-...... ~ ' A
AUTORES
*
TfK
iDIDOS* I
] ? '.......
___ _
: DINERO*
PAGOS*
Ls_
A /
LIBROS
;
NUEVOS/
'
\
>INTERACTUAR,
'
CON
/
\ AUTORES/
salidas-libros
nuevos
i "
' Jk.
\ entradas-libros
'-nuevos
\
salidas-autor
CLIENTES*
ARTICULOSINVENTARIO*
www.FreeLibros.org
C A S O DE E ST U D IO : YO U R D O N P R ES S 639
Figure 1:
Process orders
www.FreeLibros.org
640
C A SO DE E ST U D IO : YO U R D O N PRESS
Figura 1.1 Procesar pedidos
detalles-pedido
LIBROS
respuesta-pedido
respuesta-pedido,
1.1 1
detalles-pedido
vlido
EDITAR
DETALLES
PEDIDO
CLIENTES
1 . 1. 2'
J
VERIFICAR
LIBRO EN
"'/E X IS T E N C IA ,
detalles-pedido
-vlido + identificacin
-bodega
detalles-pedido
pregunta-crdito/
/ - v lid o + identificacin
respuesta agencia
1.1.3
bodega
\
-crdito
/
/ VERIFICAR AUTORIZACION
\ CREDITO >
\
detalles-pedido-vlido
+ identificacin-bodega
+ precio- total
1.1.5 \
/V E R IFIC A R N
INVENTARIO
BUSCANDO
REIMPRESION
aviso
inventaro ba
CLIENTES
respuesta-pedido
ARCHIVOS
www.FreeLibros.org
C A S O DE E ST U D IO : Y O U R D O N P R ESS 641
fig u r a
2: Administrar clientes
notificacin
Jente + nuevo
limite-crdito
respuesta-solicitud
devolucin
id e n tifica ci n -clie n te
+ p re g u n ta -sta tu spedido/respuestastatus-pedido
identificacin-bodega
nm ero-factura +
clave-status/nmero-factura
+ re spuesta-sta tus
www.FreeLibros.org
64 2
C A S O DE E ST U D IO : YO U R D O N PR ESS
Figura 3: P roducir reportes de contabilidad
CREDITOS*
VENTAS
reporte-comisiones
INVENTARIO /
www.FreeLibros.org
\
reporte-inventario
_
( ..... ARTICULOS
\
v
INVENTARIO
C A S O DE E S T U D IO : YO U R D O N PRESS 643
Figure 4: Manage printers
...
identificacin
identificacinimprenta +
imprenta +
U o tiz a c i n v cotizaaon-im prenta mprema
instrucconesidentificacinpedido-impresi m
imprenta +
. pedido-impresin
"4. r
{identificacin
-imprenta) +
clave-libro +
cantidad)
| solicitud| cotizacin
ACEPTAR
respuesta-pedido/
-impresin
C O TIZA C IO N
IM P R EN TA
/
\
H ACER
P ED ID O
\lMPRESION/
clave-libro + \
cantidad-sobre- ' " r "
pedido + fechaj
K , disponibilidad
J
clave-libro + cantidad-'
sobre-pedido + fechadisponibilidad
factura-imprenta
"^ a p ro b a d a
identificacin
-imprenta + pedidoimpresinmodificado
M O D IF IC A R
P ED ID O DE i ......
ÎM P R E S O N /
respuesta-pedido
impresin-modificado I
www.FreeLibros.org
644
Figura 6: Interactuar con m ercadeo
www.FreeLibros.org
CASO DE ESTUOSO: YO U R D O N P R ES S 645
aviso-envo
SdentifScacinbodega+nmero de
factura+fecha
www.FreeLibros.org
646
Figura 8: Interactuar con autores
www.FreeLibros.org
F.4.3
El diccionario de datos
E l d ic c io n a r io
de
d a to s
e s t
o r g a n iz a d o
de
la f o r m a
d e s c r it a
en
e l c a p tu lo
10.
Los t r m i n o s q u e s e a u t o d e f i n e n ( e s d e c i r l o s d a t o s c u y o s significados s o n l o sufi

cientemente c o n o c i d o s c o m o p a r a q u e n o s e r e q u i e r a u n a d e f i n i c i n e x p l c i t a ) c o n
t ie n e n
** c o m o
d e f in ic i n .
V e a , p o r e je m p lo , la d e f in ic i n
a d e la n t o
c a n t id a d
de
p a s y d e e s ta d o .
solicitada
d e d in e r o
r e g a la s p o r d e r e c h o s d e
com o
a d e la n t o d e
la s
a u to r*
u n id a d e s : d la r e s *
a - fe c h a
fe c h a e n
hizo
la q u e s e
**
una
apellido
a p e llid o
a p r o b a c i n - d e v o lu c i n - lib r o
re s p u e s ta a
s is t e m a
de
a r t c u lo - d e v o lu c i n
no
la b o d e g a
n o t if ic a a l
lo s li b r o s d e v u e lt o s *
e s t a u t o r iz a d a I E s ta
s p ro c e d e ]
in fo r m a c i n
t t u lo
cu an do
r e c ib ie r o n
{ E s t a d e v o lu c i n
d e v o lu c i n
fs ic o *
p e rs o n a *
u n c lie n t e
que se
inventario
el
s o b re
u n a o m s c o p ia s d e
q u e e l c lie n t e
d e se a
un
m is m o
d e v o lv e r *
c la v e - lib r o + c a n t id a d - a - d e v o lv e r
A R T IC U L O S -IN V E N T A R IO
{ a r t c u lo - in v e n t a r io }
a r t c u lo - in v e n t a r io
g ru p o
de
lib r o s , d e l m is m o t t u lo , lo c a liz a d o s e n
u n a s o la b o d e g a *
@clave-libro
b od ega
A R T IC U L O S -P E D ID O S
a r t c u lo - p e d id o
id e n t if ic a c i n -
+ c a n t id a d - in v e n t a r io
{ a r t c u lo - p e d id o }
n m e ro -fa c tu ra
c a n t id a d - p e d id a
a u to r
in f o r m a c i n
c la v e - lib r o
+ p r e c io - u n it a r io
almacenada
+
+ d e s c u e n to
a c e rc a d e
cada
@ id e n t if ic a c i n - a u to r + d e t a lle s - a u t o r +
a u to r*
balance-
regalas
A U T O R E S
{a u to r}
# -A U T O R IZ A C IO N -D E V O L U C IO N
www.FreeLibros.org
=
a lm a c n
g u e n te
que se
u sa
p a r a s e g u ir la
n m e r o a u t o r iz a d o
# - a u t o r iz a c i n - d e v o lu c i n
de
p is ta
d e l si
devolucin*
648 C A SO DE E STU D IO : YO U R D O N PR ESS
#-autorizacin-devoIucin
'n m e r o
s e c u e n c ia l q u e
c o n ju n to
e s p e c f ic o
de
se
usa
p a ra
id e n t if ic a r u n
lib r o s d e v u e lt o s
que se
h a y a n a u t o r iz a d o *
{ d g it o - n u m r ic o }
a u t o r iz a c i n - fa c t u r a - im p r e n ta
'r e s p u e s t a
de
u n a fa c tu ra
de
lu e g o
de
r e v is a r
im p r e n ta *
{ S I I N O ]
a v is o - e n v o
'a v is o
de
la b o d e g a
im p r e s i n
de
[ N o e x is te
'm e n s a je
cu an do se
r e c ib e
u n p e d id o d e
im p r e n ta *
ta l lib r o i S e
c la v e - lib r o
a v is o - in v e n t a r io - b a jo
la
r e c ib i
d e la im p r e n t a +
+ c a n t id a d - r e c ib id a ]
e n v ia d o
s is t e m a d e s c u b r e
d e te r m in a d o
a la a d m in is t r a c i n
cu a n d o
q u e e l in v e n t a r io t o ta l d e
h a d e s c e n d id o
p o r d e b a jo
de
el
u n lib r o
u n c ie r t o
n iv e l p r e s c r it o *
c la v e - lib r o
h o ra
c a n t id a d - a - d e v o lv e r
de
n m e ro
+ to ta l- e n - e x is t e n c ia
r e im p r im ir
d e c o p ia s d e
u n s o lo
d e s e a d e v o lv e r a c a m b io d e
lib r o
que
u n c lie n t e
c r d it o *
**
c a n t id a d - d e v u e lta
'c a n t id a d
d e v o lv i
d e c o p ia s d e
a una
un
lib r o q u e
un
c lie n t e
bodega*
**
c a n t id a d - d in e r o
c a n t id a d
d e d in e r o
re c a u d a d a
en
u n s o lo
pago*
'u n i d a d e s : d la r e s *
c a n t id a d - in v e n t a r io
'c u e n t a
s e t ie n e n
d e l n m e ro d e
en
una
s o la
del
lib r o s
m is m o t t u lo
que
bodega*
**
c a n t id a d - lib r o s - a - c r d it o
'n m e r o
d e c o p ia s
s o lic it a n d o
del
lib r o
p a ra
el cual se
e s t
c r d it o *
**
c a n t id a d - m o d ific a d a
'm o d if ic a c i n
im p r im ir
del
com o
nmero de
p a rte
de un
lib r o s
que
la im p r e n t a
p e d id o *
**
www.FreeLibros.org
c a n t id a d - p e d id a
n m e r o d e c o p ia s d e
un
lib r o q u e s e
p id ie r o n *
C A S O DE ESTUDIO: YO U R D O N PRESS 649
cantidad-recibida
nmero
d e c o p ia s d e
la im p r e n t a
com o
un
lib r o
r e s u lt a d o
que
de
se
r e c ib ie r o n
de
u n p e d id o d e
im p r e s i n *
**
cantidad-seleccionada
"nmero
copias
de
d e
u n s o lo
e s c o g e r p a r a s a t is f a c e r lo s
que se d e b e
un d a e n
lib r o
p e d id o s d e
una bod ega*
**
c a n t id a d - s o b r e - p e d id o
"n m e ro
d e c o p ia s d e
c o n fo rm a n
un
p e d id o
u n lib r o
a una
que
a c tu a lm e n te
im p r e n t a *
**
c a r c te r - a lfa b tic o
"u n a
c a r c te r a ifa n u m r ic o
"u n
le tr a d e l a lf a b e t o *
n m e ro , u n a
le tr a
[c a r c te r - a lf a b t ic o
o u n s ig n o
de
p u n tu a c i n *
I d g it o - n u m r ic o
I s ig n o -
p u n tu a c i n ]
cargos-envo
" c a n t id a d
c o b ra d a
c lie n t e . P u e d e
e je m p lo ,
c a rg o s
US
p o r e i e n v o
de
s e r u n a c a n t id a d
$ 1 .5 0 , o
pue de
un
lib r o
un
e s t n d a r, p o r
e s ta r b a s a d o
en
lo s
r e a le s d e t r a n s p o r t e *
" u n id a d e s : d la r e s ; e s c a la : 0 - 1 0 0 *
c la v e - lib r o
" c la v e
numrica
q u e
id e n t if ic a
a cada
lib r o *
1 { d g it o - n u m r ic o }
c lie n t e
"u n
cliente
de
Y O U R D O N
@ id e n t if ic a c i n - c lie n te
compaa)
P re s s *
--(nombre-
+ n o m b r e - c lie n te
s a id o - a c tu a i + lm it e - c r d it o
C U E N T E S
{ c lie n t e }
cdigo-ao
"los l t i m o s d o s
el a o a c t u a l es
c d ig o - p o s ta l
d g it o s
del
+ d o m ic ilio - c lie n te
+ n iv e l- p la n - a g e n c ia
ao
actual,
p.
ej.,
9 2 si
1992*
2 { d g it o
n u m r ic o } 2
" c d ig o
p o s ta l d e
E U A , d e C a n a d , o d e G ra n
B re ta a *
www.FreeLibros.org
c o t iz a c i n - im p r e n t a
" c o t iz a c i n
d a d a p o r una
im p r im ir c ie r t o
c la v e - lib r o
n m e ro
de
im p r e n ta , o f e r ta d e
lib r o s a u n c ie r t o
+ p r e c io - im p r e n t a
p r e c io *
650
c r d it o
c r d it o
d e b id o
in d iv id u a l
a a lg n
@nmero-factura
c lie n t e
lib r o
que
se
le o t o r g a a u n c lie n t e
p r o b le m a c o n
a lg n
p e d id o *
+ id e n t if ic a c i n -
+ fe c h a - c r d it o
+ c la v e -
+ c a n t id a d - lib r o s - a - c r d it o
m o n to - d e - c r d ito
C R E D IT O S
{ c r d it o }
c r d it o s - v e n t a
c r d it o s a s o c ia d o s c o n
p e ro d o
e s p e c f ic o
un
m is m o
un
lib r o d u r a n t e
d e t ie m p o *
c u e n ta - f s ic a
c u e n ta d e l n m e r o d e c o p ia s d e
que
s e e n c u e n tra d u ra n te
un
m is m o t t u lo
e l in v e n t a r io
fs ic o
d e una
bodega*
**
c u e n ta - in v e n ta r io
in fo r m a c i n
in v e n t a r io
acerca
que se
de
haya
u n a c u e n ta fs ic a
hecho
una
en
de
bod ega*
{ d e t a lle - in v e n t a r io } + a - fe c h a
d e s c u e n to
p o r c e n ta je
p e d id o
p r e c io
de
d e s c u e n to
qu e se
expresado
d e v o lu m e n ,
a p a g a r , e s d e c ir , u n
d e s c u e n to
10
s e e x p re s a ra c o m o
en
o to rg a
un
c o m o fr a c c i n
por
c ie n to
del
de
0 .9 0 *
e s c a la : 0 - 1 .0 0 *
d e t a lle - in v e n ta r io
c u e n ta d e
c la v e - lib r o
d e t a lle s - a u t o r
t t u lo
+ n o m b re
c d ig o
d e t a lle s - c lie n t e
p a ra
u n s o lo t t u lo *
+ c u e n ta - f s ic a
+ a p e llid o
+ d o m ic ilio
+ c iu d a d
p o s ta l + ( p a s ) + n m e r o t e le f n ic o
in fo r m a c i n
p r o p o r c io n a d a
c a m b ia r in fo r m a c i n
p o r e je m p lo , n u e v o
p o r u n c lie n t e
y a e x is te n te
domicilio
en su
p a ra
r e g is t r o
d e c lie n t e *
( n o m b r e - c lie n t e ) + ( n o m b r e - c o m p a a ) +
( d o m ic ilio -
c lie n t e )
d e t a lle s - d e v o lu c i n
{ a r t c u lo - d e v o lu c i n }
d e t a lle s - p a g o
in fo r m a c i n
fa c tu r a q u e
d e t a lla d a
s e e s t
re s p e c to
pagando*
un
a r tc u lo
o una
www.FreeLibros.org
{n m e ro -fa c tu ra } + m o n to -to ta l
C A SO DE E STU D IO : YOURDON PRESS 651
d e t a lle s - p e d id o
'd a t o s
que
se
m a n e ja n
p e d id o v lid o y s u
p a ra
la c o n s t r u c c i n
a lm a c e n a m ie n t o
id e n t if ic a c i n - c lie n te - p o s ib le
en
de
un
P E D ID O S *
{ a r t c u lo - p e d id o } + t a s a - im p u e s t o s v e n ta + c a rg o s -e n v o
+ t ip o - p a g o
( p a g o - d e - p e d id o ) + ( n m e r o - t a r je t a c r d it o ) + is t a - e s p e r a - O K
d e t a l e s - p e d id o - v lid o
* d a to s c o n
se
lo s c u a l e s
+ t ip o - p e d id o
c o n s t r u ir
p a r a s e r in g r e s a d o a l a lm a c n
id e n t if ic a c i n - c lie n te
im p u e s to s - v e n t a
de
un
p e d id o
v lid o
P E D ID O S *
+ { a r t c u lo - p e d id o } + t a s a -
+ c a rg o s -e n v o
+ t ip o - p a g o
( p a g o - d e - p e d id o ) + ( n m e r o - t a r je t a - c r d it o ) +
e s p e ra -O K
d e v o lu c i n
in fo r m a c i n
d e v o lv ie r o n
a c e rc a
y
que
f e c h a - d e v o lu c i n
de
un g ru p o
Y O U R D O N
+ c la v e - lib r o
c a n t id a d - d e v u e lta
D E V O L U C IO N E S
lis t a -
+ t ip o - p e d id o
de
lib r o s q u e s e
P re s s
h a a c e p ta d o *
+ v a lo r - d e v o lu c i n
{ d e v o lu c i n }
d e v o lu c i n - a u to r iz a d a
'in f o r m a c i n
Y O U R D O N
s o b re
P re s s
a lg n
haya
d e v u e lv a a c a m b io
d e v o lu c i n
g ru p o
de
a u t o r iz a d o
d e c r d it o *
lib r o s
que
que
u n c lie n t e
@ # - a u to r iz a c i n -
+ d e t a lle s - d e v o lu c i n
D E V O L U C IO N E S -A U T O R IZ A D A S
d e v o lu c io n e s - v e n t a s
{ d e v o lu c i n - a u to r iz a d a }
d e v o lu c io n e s p o r u n lib r o
p e ro d o
e s p e c f ic o
de
d e te r m in a d o
d u ra n te
un
t ie m p o *
dgito-numrico
*u n
D IN E R O
d in e r o
simple
vulgar
d g it o *
{ d in e r o }
in fo r m a c i n r e fe r e n te
@ fe c h a - d e l- d in e r o
a c h e q u e s , e fe c tiv o
identificacin-
u o tro s *
c lie n t e
{n m e ro -fa c tu ra } +
c a n t id a d - d in e r o
www.FreeLibros.org
652
C A S O DE E ST U D IO : Y O U R D O N PRESS
d o c u m e n to s -e n v o
lis ta d e s e le c c i n
m andan
y e t iq u e ta s d e e n v o
la b o d e g a
que
p a ra
s u f ic ie n t e s c o p ia s d e c a d a
del
d a , a d e m s d e
que
la b o d e g a
p a ra
puedan
que
se
s e le c c io n a r
l i b r o y e n v i a r lo s p e d id o s
u n a c o p ia d e c a d a
p e d id o
para
p u e d a s a b e r c u n t o s lib r o s e m p a c a r
c a d a c lie n t e *
{ id e n tific a c i n - b o d e g a
+ lis t a - d e - s e le c c io n e s +
{ e tiq u e ta - e n v o } + { p e d id o } }
d o m ic ilio - c lie n te
d o m ic ilio
d e c o b ro : a d n d e
m a n d a r la f a c t u r a d e l
c lie n t e *
d o m ic ilio + c iu d a d
c d ig o - p o s ta l +
d o m ic ilio - im p r e n ta
d o m ic ilio
la
en d on de
se
puede
localizar
a l d u e o de
im p r e n ta *
d o m ic ilio
e le c c i n - p la n - a g e n c ia
+ e s ta d o
(p a s )
+ c iu d a d
e le c c i n
a g e n c ia
+ e s ta d o + c d ig o - p o s ta l
d e l c lie n t e
s o b re
cual
n iv e l d e
p la n
de
a d o p ta r*
e s c a la : 0 - 4 *
e s ta d s tic a s - v e n ta
re p o rte
v e n ta s n e ta s d e
lib r o s
de
p a ra
m e rc a d e o
u n p e r io d o
s o b re
las
d e tie m p o
dado*
{ c la v e - lib r o + in g r e s o s - v e n ta
+ d e v o lu c io n e s - v e n t a s
+ c r d it o v e n t a }
provincia
e s ta d o
e s ta d o o
**
e t iq u e ta - e n v o
e t iq u e ta s d e e n v o
en
u n d o m ic ilio *
p a r a lo s p e d id o s d e l d a
a la
bodega*
n o m b r e - c lie n te
e tiq u e ta s - c o r r e o
+ d o m ic ilio - c lie n te
e t iq u e ta s d e e n v o
de
p r o d u c id a s
+ n m e r o - fa c tu r a
p o r e l d e p a rta m e n to
m e rc a d e o *
{ c lie n t e }
fa c tu ra
in fo r m a c i n
Y O U R D O N
c o n te n id a e n
u n a fa c tu r a
de
P re s s *
nmero-factura
d o m ic ilio - c lie n te
+ p e d id o
www.FreeLibros.org
F A C T U R A S
{ fa c tu r a }
CASO DE ESTUDIO: YOURDON FRESS 653
factura-imprenta
fa c tu r a
un
r e c ib id a
p e d id o d e
c la v e - lib r o
f a c tu r a - im p r e n t a - a p r o b a d a
de una
im p r e n t a
de
im p r e s i n *
+ m o n to -d e -fa c tu ra
imprenta
fa c tu ra d e
que
h a y a s id o a p r o b a d a
p o r la
a d m in is t r a c i n *
c la v e - lib r o + m o n t o - d e - f a c t u r a
f e c h a - c r d it o
fe c h a
en
la c u a l s e
f e c h a - d e v o lu c i n
fe c h a
en
ia q u e
en
se
o to rg
u n c r d it o *
devolvi
un
lo t e d e
lib r o s *
**
f e c h a - d is p o n ib ilid a d
fe c h a -e n v o
la q u e s e
e s p e ra
im p r e s i n
fe c h a
de
lib r o
fe c h a
la q u e
en
a lg n
q u e e l p e d id o
lle g u e
la b o d e g a
a una
e n v a
de
bodega*
u n p e d id o *
**
f e c h a - m o d if ic a d a
n u e v a fe c h a f ija d a
de
un
lo te d e
p o r la im p r e n t a
lib r o s q u e
e s t
p a ra
la e n tr e g a
im p r im ie n d o *
**
realiza
fe c h a -p a g o
fe c h a
en
la q u e
se
f e c h a - r e e m b o ls o
fe c h a e n
la q u e
s e a p ro b
un
pago*
e l r e e m b o ls o *
**
f e c h a - s a ld o - a c t u a l
fe c h a
en
a c tu a l
dei
la c u a l s e
p r o d u c c i n
c lie n t e
de su
h iz o
e l c m p u to
( u s u a lm e n te
e s ta d o
d e l b a la n c e
d u ra n te
la
d e c u e n ta )*
**
fe c h a -v e n ta
fecha
de sp u s de
r e p o rte
e s ta d s tic o
c r d it o s
**
id e n t if ic a c i n - a u t o r
la c u a l d e b e n
in c lu ir s e
d e v e n ta s to d o s
en
d e v o lu c io n e s *
d e c a d a a u to r d e Y O U R D O N
N o s e u t iliz a n
lo s n m e r o s d e
n o to d o s
a p e llid o
el
lo s p e d id o s ,
io s a u t o r e s s o n
+ n o m b re
S e g u ro
P re s s
S o c ia l p u e s
c iu d a d a n o s d e
lo s
E U A *
www.FreeLibros.org
654
id e n t if ic a c i n - b o d e g a
a lm a c e n a n
(N Y C
la s d iv e r s a s
b o d e g a s d o n d e se
Y O U R D O N
P re s s *
ILQN IDC ISEOI
Y O N K E R S
de
lib r o s d e
O T T A W A )
de
u n c lie n t e
de Y O U R D O N
P re s s ;
lo s c lie n t e s d e s c o n o c id o s o n o id e n t if ic a d o s s e
cono cen
lo
com o
re fe re n te
e fe c tiv o
[ { d g ito - n u m r ic o }
id e n t if ic a c i n - c lie n te - p o s ib le
in fo r m a c i n
ve z
hace
un
n o a p lic a d o , s o b r e
to d o en
a pag os*
I e fe c tiv o
s o b re
n o a p lic a d o ]
u n c lie n t e
cu an do
p o r p r im e r a
p e d id o *
{ id e n tific a c i n - c lie n te
+ (n o m b re -
ciente)
nuevo
+ ( n o m b r e - c o m p a a ) + d o m ic ilio -
c lie n t e }
id e n t if ic a c i n - im p r e n ta
c la v e
n ic a q u e
id e n t if ic a
la
im p r e n ta *
{ d g it o - n u m r ic o }
id e n t if ic a c i n - v e n d e d o r
de
un ve n d e d o r de Y O U R D O N
in c .
**
im p r e n ta
in fo r m a c i n
con
a c e rc a
de ca d a un a de
la s q u e Y O U R D O N
P r e s s tie n e
@ id e n t if ic a c i n - im p r e n t a
la s im p r e n t a s
tra to s *
n o m b re -
im p r e n t a + d o m ic ilio - im p r e n t a
IM P R E N T A S
{ im p r e n ta }
im p u e s to s - v e n t a
im p u e s t o s lo c a l y e s t a t a l a s o c ia d o s c o n
un
p e d id o *
in d ic a d o r - a g o ta d o
in d ic a d o r b in a r io
e x is te n c ia
s u b s e c u e n te s
[S I
in fo r m a c i n - d e v o lu c i n - iib r o
s o b re
p a ra q u e
se
si un
lib r o y a
re c h a c e n
n o s e tie n e
en
p e d id o s
( s i lo s h a y ) *
N O ]
in fo r m a c i n
a c e rc a
a lg n
haya
c lie n t e
d e u n g ru p o
d e v u e lt o
a la
de
lib r o s q u e
bodega*
( id e n tific a c i n - c lie n t e ) +
( n o m b r e - c lie n t e ) + { c la v e - lib r o
c a n t id a d - d e v u e lta } + # - a u t o r iz a c i n - d e v o lu c i n
www.FreeLibros.org
C A S O DE E ST U D IO : YOURDON P R ESS 655
in g r e s o s - v e n ta
in g r e s o s n e t o s d e
la s v e n t a s d e
d u ra n te
d e t ie m p o
un
p e r io d o
un
m is m o
lib r o
e s p e c f ic o *
in s t r u c c io n e s - d e v o lu c i n
in s t r u c c io n e s a la
lo te d e
lib r o s q u e
( N o e s
to d o s
instrucciones-pedidode-impresin
posible
m odos
b od ega
el
cliente
s o b re
id e n t if ic a r a l c lie n t e ; a c e p te
lo s li b r o s I E s t a d e v o lu c i n
de
libro I
a u t o r iz a d a ; f a v o r
r e g r e s a r la I
N o e x is te t a l
S e a u t o r iz a
in s tr u c io n e s d e
un
qu h a ce r con
un
h a y a d e v u e lt o *
la
de
n o e s t
d e v o lu c i n )
p a ra
r e im p r im ir
lib r o *
id e n t if ic a c i n - im p r e n ta + c la v e - lib r o
+ t ir a je
+ fe c h a -
d is p o n ib ilid a d
in v e n t a r io - to t a i- lib r o s
* n m e ro to ta l d e
lib r o s d e u n t t u lo
la s b o d e g a s d e Y O U R D O N
libro
'in f o r m a c i n
Y O U R D O N
dado,
en
to d a s
P re s s *
a lm a c e n a d a a c e r c a d e
un
lib r o d e
P re s s *
c la v e - lib r o
+ ttu lo
e n - e x is te n c ia +
+ id e n t if ic a c i n - a u to r + t o ta i-
cantidad-sobre-pedido
t a s a - r e g a l a s + in d ic a d o r - a g o t a d o
n iv e l- p a r a - r e o r d e n
B R O S
{ lib r o }
l m it e - c r d it o
'm onto d e l crdito q u e se l e d a r a u n c l i e n t e

pedidos q u e n o se p a g a n p o r a d e l a n t a d o *
' u n i d a d e s : d l a r e s ; escala: 1 - 1 0 , 0 0 0 *
lis ta - d e - s e le c c io n e s
in d ic a c i n
se deb e
del
p e d id o s d e u n
lis t a - e s p e r a - O K
n m e ro
e sco g e r en
bodega
lib r o
que
p a r a s a t i s f a c e r lo s
d a *
cantidad-seleccionada)
{ t tu lo - lib r o
'in d ic a c i n
de
a c tu a lm e n te
d e c o p ia s d e c a d a
una
p a ra
s i u n c lie n t e
no h a ya
h a r e l p e d id o
suficientes
aunque
lib r o s e n
e x is te n c ia *
[ S I N o ]
www.FreeLibros.org
656
C A SO DE E STU D IO : YO U R D O N PR ESS
m o n t o - d e - c o m is i n
m o n to d e
la c o m is i n
ve n d e d o r por ca d a
el
p ro c e s o
ie
que se
p e d id o
pag a a un
in d iv id u a l; s e c a lc u la e n
3 .6 *
w*
m o n to - d e - c r d ito
c a n t id a d
d e d in e r o
p o r la c u a l s e
da
c r d it o *
monto-de-crdito-solicitado
'c a n t id a d
d e d in e r o
s o lic it a d a
p a r a c r d it o *
'u n id a d e s : d la r e s *
m o n to -d e -fa c tu ra
c a n t id a d
fa c tu r a
d e d in e r o c o b r a d o
la
p o r u n a im p r e n t a e n
de
un
p e d id o
que
se
le
d e im p r e s i n *
m o n to - d e l- r e e m b o ls o
'c a n t id a d
d e d in e r o
deb e
r e e m b o ls a r a un
c lie n t e *
n iv e l- p ia n - a g e n c ia
'c d ig o
p a ra
e s c o g id o
Y O U R D O N
'escala:
n o m b re
in d ic a r e i n iv e l d e p e d id o s v ig e n t e s '
p o r e l c lie n t e
p a ra
lo s p r x im o s
lib r o s
de
P re s s *
0 -4 *
*e l n o m b re d e
u n a p e rs o n a *
**
n o m b r e - c lie n te
t t u lo
n o m b re -c o m p a a
n o m b re d e
+ n o m b re
+ a p e llid o
u n a c o m p a a
u o r g a n iz a c i n *
**
n o m b r e - im p r e n ta
n o m b re d e
la c o m p a a
n o m b re -v e n d e d o r
n o m b re d e
un ve n d e d o r de
im p r e s o r a *
Y O U R D O N
in c .*
**
n m e r o - fa c tu r a
n m e r o e x c lu s iv o a s ig n a d o a c a d a f a c tu r a ; u n
n m e ro
B+
n m e r o - ta r je ta - c r d it o
d e fa c tu r a
c d ig o - a o
'n m e r o
tpico
es
d e t a r je t a d e c r d it o
d e s e a c a r g a r la c u e n ta d e
ta r je ta *
B 8 8 -5 0 6 7 *
+ { d g it o - n u m r ic o }
un
dad o
por el
p e d id o d e
cliente
si
lib r o s a s u
www.FreeLibros.org
n m e r o - te le f n ic o
*un
pago
*p a g o
n m e r o t e le f n ic o *
realizado
de
un
p e d id o o p a r a
p a g a r u n a fa c tu ra *
( id e n tific a c i n - c lie n t e ) + fe c h a pago
+ d e t a lle s - p a g o
P A G O S
{pago}
p a g o - d e - p e d id o
*p a g o
que
e l c lie n t e
a d ju n ta
a s u p e d id o *
'" u n i d a d e s : d l a r e s *
p a s
*n o m b re d e
**
p e d id o
*u n
p e d id o
un
p a s , p o r e je m p lo , C a n a d *
d e a lg n
n m e ro -fa c tu ra
c lie n t e
lib r o
de
Y O U R D O N
P re s s *
+ id e n t if ic a c i n -
+ fe c h a - p e d id o
+ { a r t c u lo -
p e d id o } + c a r g o s - e n v o
v e n ta + fe c h a -e n v o
+ im p u e s to s -
( id e n tific a c i n - v e n d e d o r ) + t o ta l- d e l- p e d id o
P E D ID O S
p e d id o - im p r e s i n
{ p e d id o }
pedido
de
c la v e - lib r o
p e d id o - im p r e s i n - m o d ific a d o
im p r e s i n
m o d if ic a c i n
d e l p e d id o
im p r e n t a . U s u a lm e n t e
en la cantidad
c la v e - lib r o
qu e se
le d a a u n a im p r e n t a *
+ t ir a je
de
im p r e s i n
in v o lu c r a
de
c a m b io s
una
m e n o re s
imprim ir*
+ c a n t id a d - m o d ific a d a + f e c h a -
m o d if ic a d a
p r e c io - im p r e n t a
p r e c io
de
una
cotizacin
de
la im p r e n t a *
**
p r e c io - u n it a r io
p r e c io q u e
s e c o b r a p o r u n a c o p ia d e
Y O U R D O N
P r e s s e n u n p e d id o
que
puede
no
ser
un
lib r o d e
observe
el p r e c i o u n i t a r i o
se a n u n c i a *
in d iv id u a l;
e l m is m o q u e
e s t n d a r o e l d e v e n ta q u e
www.FreeLibros.org
65 8
C A SO DE E STU D IO : Y O U R D O N PR ESS
p r e g u n ta - c r d it o
s o lic it u d
d e a u t o r iz a c i n
d e c r d it o
S o lic itu d
p a ra
m o tiv o
de
un
p e d id o d e
lib r o s *
d e a u t o r iz a c i n +
n m e r o - ta r je ta - c r d it o
razn-crdito
a u n a a g e n c ia d e t a r je t a s
la c o m p r a
q u e t ie n e
+ t o t a l- d e l- p e d id o
e l c lie n t e
[ P a g o e x c e s iv o I r e tr a s o
p a r a s o lic it a r c r d it o *
e x c e s iv o I e n v o
in s u f ic ie n t e I lib r o s d a a d o s ]
r e e m b o ls o
in fo r m a c i n
a c e rc a d e
f e c h a - r e e m b o ls o
c lie n t e
R E E M B O LS O S
r e g a la s - a r tc u lo
un
r e e m b o ls o *
+ m o n t o - d e l- r e e m b o ls o
{ r e e m b o ls o }
u t ilid a d e s p o r d e r e c h o s d e a u t o r o b t e n id a s
v e n ta d e
u n a o m s c o p ia s d e l m is m o
la
por
lib r o e n
un
s o lo p e d id o *
r e p o r te - c o m is io n e s
r e p o rte
d e c o m is io n e s
p o r v e n ta s *
{ { id e n t if ic a c i n - v e n d e d o r +
n m e r o - fa c t u r a + m o n o - d e - c o m is i n }
+ t o ta l- c o m is i n }
re p o rte -c u e n ta s -p o r-c o b ra r
r e p o rte
d on de
p a ra e l d e p a rta m e n to
se
m u e s tra
e l b a la n c e
a c tu a l d e c a d a
c lie n t e *
{ id e n tific a c i n - c lie n te
r e p o r te - in v e n ta r io
re p o rte
p r o d u c id o
+ s a ld o - a c tu a l}
el
p a ra
de
c o n t a b ilid a d *
{ { id e n t if ic a c i n - b o d e g a
+ c la v e -
lib r o + c a n t id a d - in v e n t a r io } +
in v e n t a r io - to t a l- lib r o s }
re p o rte -re g a l a s -a u to r
re p o rte
p a r a lo s a u t o r e s
c o n c e p to
que
m u e s tra
p e r d id a s s o b r e v e n ta s , c r d it o s
cada
lib r o
r e g a la s
por
d e d e r e c h o s d e a u to r o b te n id a s o
d u ra n te
un
p e r io d o
d e tre s
de
m eses*
{ to t a l- c o p ia s + t o t a l- v e n ta s - lib r o + t o ta i- r e g a l a s -
libro}
www.FreeLibros.org
reporte-trimestral-regaias
re p o rte
m u e s tra
derechos
u n p e r io d o
de
m eses*
{ { id e n t if ic a c i n - c lie n t e
c lie n t e
+ n o m b re -
+ n m e ro -fa c tu ra
v e n t a s - a r t c u lo
re p o rte
+ r e g a la s - a r t c u lo } + t o ta l- c o p ia s
t o ta l- v e n ta s - lib r o
r e p o r te - v e n ta s - d ia r io
de
d e a u t o r o b t e n id a s p o r v e n ta s , c r d it o s y
d e v o lu c io n e s d e c a d a lib r o d u r a n t e
tre s
que
la s u t il id a d e s o p r d i d a s p o r c o n c e p t o
+ to ta l- r e g a l a s - lib r o }
q u e s e m a n d a d ia r ia m e n te
al
d e p a r t a m e n t o d e c o n t a b ilid a d *
{n m e ro -fa c tu ra
n o m b r e - c o m p a a
+ t o ta l- d e l- p e d id o }
+ t o ta l- v e n ta s - d ia r io
re p o rte -v e n ta s -m e n s u a l
reporte
d e l t o ta l d e v e n ta s , d e v o lu c io n e s y
o to rg a d o s e n
u n s o lo
crditos
m e s , e n v ia d o s a l
d e c o n t a b ilid a d *
to ta i- v e n ta s + t o ta l- d e v o lu c io n e s
t o ta l- c r d it o s
r e s p u e s ta - a d e la n to
respuesta
s o lic it a
[No
editor
ai
u n a d e la n t o
de
adquisiciones
de
r e g a la s p a r a
e x is te ta l a u t o r I N o
re s p u e s ta
una
[S i
d e a lg u n a a g e n c ia
s o lic it u d
de
a u to r*
e x is te ta l lib r o I
A d e la n to a p r o b a d o I A d e la n to
r e s p u e s t a - a g e n c ia - c r d it o
cu an do
un
n e g a d o ]
d e ta r je ta s
a u t o r iz a c i n
d e c r d it o
d e c a rg o *
N o ]
r e s p u e s t a - a u t o r iz a c i n a d e la n t o
re s p u e s ta
a d e la n t o
de
de
a la s o lic it u d
de
r e g a la s p o r d e r e c h o s d e
a u to r*
[ S
r e s p u e s t a - c a m b io - c lie n t e
N o ]
re s p u e s ta
de
u n c lie n t e c u a n d o
u n c a m b io
[ N o e x is te
ta l
n o t if ic a a l
sistema
domicilio, e t c , *
c lie n t e i C a m b io
de
a c e p ta d o ]
www.FreeLibros.org
660
C A SO DE E STU D IO : Y O U R D O N PR ESS
r e s p u e s t a - c r d it o
'r e s p u e s t a
a u n c lie n t e
que d ese a
un
r e c o r d a to r io
d e c r d it o *
[ N o e x is te t a l p e d id o
o to rg
p a ra e s te
c r d it o I N o s e
h iz o
c lie n t e i Y a s e
p a g o p a r a ta l n m e ro
d e f a c t u r a I E l c r d it o a p a r e c e r e n
el
e s ta d o
pag en
d e c u e n ta " I L a fa c tu r a
no se
s ig u ie n te
e x c e s o " I S e o t o r g a c r d it o
p o r e l m o n to to ta l d e l
p e d id o I C r d ito
in s u fic ie n te : + m o n to -
d e - c r d it o
C r d ito
p o r e n v o
p o r lib r o s d a a d o s : +
m o n to - d e - c r d ito ]
respuesta-de-existencias
'r e s p u e s t a
p id e n
la f e c h a
e n v o
de
en
la q u e
lib r o s d e
la
de
se
m e rc a d e o c u a n d o
te n d r e n
e x is te n c ia
un
im p r e n ta *
[ N o e x is t e ta l lib r o I N o
h a y e n v o
p e n d ie n t e I
F e c h a - d is p o n ib ilid a d ]
re s p u e s ta -e n v o
= 'mensaje
a v is o
N o se
re s p u e s ta -fa c tu ra
d e e rro r a
de que
la b o d e g a
e n v ia r o n
en
e l p e d id o
re s p u e s ta a s u
de
u n c lie n t e *
e n c u e n tr a e l p e d id o
'r e s p u e s t a
a la p r e g u n t a d e
u n c lie n t e
re fe re n te
u n a fa c tu ra *
[ n o e x is te
p e d id o
fe c h a - d e - p e d id o
con
ese
n m e ro d e fa c tu r a I
{ a r t c u lo s - p e d id o s } + c a r g o s - e n v o
im p u e s t o s -
v e n ta ]
r e s p u e s t a - fa c t u r a - im p r e n ta
'r e s p u e s t a
d e l s is t e m a a la im p r e n t a c u a n d o
u n a fa c tu r a d e
{ N o q u e d a n
respuesta-inventario-fsico
'm e n s a je
un
p e d id o s d e
d e l s is t e m a
[ N o e x is te
tal
r e c ib e
s ta '
e s te
lib r o ]
a una bod ega
que se
h a ya
b o d e g a I C la v e
en
re s p u e s ta a
hecho*
d e lib r o
ile g a l +
c la v e - lib r o ]
respuesta-libro-agotado
'r e s p u e s t a
s te
de
m e rc a d e o
in d ic a q u e d e b e c o n s id e r a r s e
q ue
un
cu an do
lib r o
e s t
f u e r a d e c a t lo g o *
[ N o e x i s t e t a l l i b r o I E l l i b r o e s t d e s c a t a l o g a d o ' ]
www.FreeLibros.org
C A SO DE E STU D IO : YO U R D O N P R ES S 661
respuesta-lm ite-crdito
re s p u e s ta
a la s
in s tr u c c io n e s d e
d e c a m b ia r e l l m it e
de
[ N o e x is te ta l c lie n t e
N u e v o
r e s p u e s t a - in f o r m a c i n - iib r o
l m it e
in fo r m a c i n
c r d it o
l m it e
de
u n c lie n t e *
d e c r d it o
ilegal I
d e c r d it o a p r o b a d o ]
a c e rc a
del
t t u lo , p r e c io , e tc ., d e
un
lib r o *
lib r o
r e s p u e s t a - n o - e n - e x is t e n c ia
m e n s a je
de que
e x is te n c ia
en
in d ic a c i n
en
[ N o e x is te
ta l lib r o I E r r o r : n o s e e n c u e n tr a
a r tc u lo
in v e n t a r io i M e n s a je
de
e x is te n c ia
r e s p u e s ta - p e d id o
e n respuesta a s u
determinado n o s e t i e n e
dicha b o d e g a *
a la b o d e g a
u n t t u lo
a l c lie n t e
p r e c io
de
lmite
a su
cu an do
la m e r c a n c a
p a g a d a I S o lic itu d
exced e
el
no
a c e p ta d o ]
re s p u e s ta
[El
de
e n e x is te n c ia
hace
u n p e d id o *
e x c e d e a la c a n t id a d
d e c r d it o
d e c r d it o
n e g a d a i
El
p e d id o
In s u fic ie n te s
p a r a s a t is f a c e r s u
lib r o s
p e d id o I N o e x is te
ta i c lie n t e I N o e x is te ta l lib r o I P o r c e n ta je
de
im p u e s to s o b r e
la v e n t a I C a r g o s
ile g a l
d e e n v o
le g a le s i P e d id o a c e p t a d o ]
r e s p u e s t a - p e d id o - im p r e s i n
r e s p u e s t a d e l s is t e m a
r e im p r e s i n
[No
re
tal
e x is te
im p r e s i n
de
s o b r e e i p e d id o
de
la a d m in is t r a c i n *
lib r o
T ir a je
ile g a l i P e d id o
de
a c e p ta d o ]
e u e s ta - p e d id o - im p r e s i n -
m o d if ic a d o
re s p u e s ta
d e l s is t e m a
m o d if ic a d o
de
[ N o
r e s p u e s t a - r e e m b o ls o
existe
la
cuan do
se
r e c ib e
un
p e d id o
im p r e n ta *
ta i lib r o
El
pedido
m o d if ic a d o
e s t c o rre c to ]
re s p u e s ta
a u n c lie n t e
que
d e im p r e s i n
ha solicitado
un
r e e m b o ls o *
[ N o e x is te
s a ld o
ta l
cliente I N o
hay
r e e m b o ls o
a c t u a l e s d e + s a ld o - a c t u a l I R e e m b o ls o
a p ro b a d o ]
www.FreeLibros.org
662
CASO DE E STU D IO : Y O U R D O N PRESS
r e s p u e s t a - s o lic it u d - d e v o lu c i n
re s p u e s ta
a u n c lie n t e
que de se a
d e v o lv e r u n
lib r o *
( N o
se encuentra
e n v ia r o n
hace
pedido I L o s l i b r o s s e
un a o I N o s e p u e d e n
libros I S e a p r u e b a l a d e v o l u c i n
d e v o lv e r t a n to s
+ F avo r de
e s te
m s de
id e n t if ic a r la d e v o lu c i n
p o r m e d io d e +
# - a u t o r iz a c i n - d e v o iu c i n )
r e s p u e s ta - s ta tu s - p e d id o
re s p u e s ta a
u n c lie n t e
de un
que
p e d id o
[ N o e x is te
p e d id o
fe c h a - p e d id o
s a ld o - a c tu a l
c a n t id a d
q u e p re g u n ta s o b re
s ta tu s
ha hecho*
p a r a ta l n m e r o
de f a c t u r a I
fecha-envo]
+ { a r t c u lo s - p e d id o s } +
d e d in e r o q u e
a c tu a lm e n te
d eb e
un
c lie n t e *
*A
LA
F E C H A
D E L S A LD O
A C T U A L*
u n id a d e s : d la r e s ; e s c a la : 1 - 1 0 ,0 0 0 *
s ig n o - p u n t u a c i n
una com a, un
p u n to , u n s ig n o
de
a d m ir a c i n , e tc .*
**
s o lic it u d - a d e la n t o - r e g a l a s
s o lic it u d
d e l e d ito r d e a d q u is ic io n e s p a r a q u e s e
o to rg u e
u n a d e la n t o
r e la c i n
un
de
u t ilid a d e s
a u n a u to r,
con
lib r o *
id e n t if ic a c i n - a u to r + c la v e - lib r o
+ a d e la n t o
m e n s a je
don de
s o lic it u d - a u t o r iz a c i n a d e la n t o
p a ra
a p r o b a c i n
c o n c e p to
un
de
de
u n a d e la n t o
de
d e re c h o s d e a u to r p a ra e i p ro y e c to de
lib r o *
s o lic it u d - c h e q u e - a d e la n to
s e s o l i c i t a la
u t ilid a d e s p o r
mensaje
e l q u e s e s o lic it a
+ a d e la n t o
e l p a g o d e l a d e la n t o
u t ilid a d e s p o r c o n c e p to d e d e r e c h o s d e
s o lic it u d - c h e q u e - r e e m b o ls o
m e n s a je
al
s o lic it a n d o
p a ra
departamento
que se
e x p id a
de
a u to r*
adelanto
contabilidad
de
un
en
a u t o r iz a d o
cheq ue de
r e e m b o ls o
u n c lie n t e *
F avo r de
c lie n t e
p a g a r
+ m o n to - d e l- r e e m b o ls o
www.FreeLibros.org
solicitud-clave-libro
'm e n s a je
a la a d m in is t r a c i n
a s ig n e c la v e
un
lib r o
F a v o r d e a s ig n a r c la v e
s o lic it u d - c r d it o
cliente
's o lic it u d
del
s o b re
p e d id o *
un
se
lib r o :
le o t o r g u e
c r d it o
lib r o s q u e e i
cliente
+ n m e ro -
+ c la v e - lib r o
ib r o s - a - c r d it o
que
p a r a e l s ig u ie n te
p a ra q u e s e
fa c tu r a
s o lic it a n d o
nuevo*
+ c a n t id a d -
+ r a z n - c r d it o
m o n t o - d e - c r d ito - s o iic ita d o

s o lic it u d - d e v o lu c i n
'in fo r m a c i n
de se a
s o b re
uno o m s
d e v o lv e r a c a m b io
de
c r d it o *
n m e r o - fa c t u r a + d e t a lle s - d e v o lu c i n
s o lic it u d - e t iq u e ta s
's o lic it u d
d e l d e p a rta m e n to
de
m e rc a d e o
p a ra
p r o d u c ir e t iq u e ta s d e e n v o
F avo r de
s o lic it u d - p r e c io - u n it a r io
's o lic it u d
p r o d u c ir e t iq u e ta s d e
d e l p r e c io
F avo r de
de
u n ita r io
de
e n v o
libro
un
nue vo
al
m e rc a d e o *
in d ic a r e l p r e c io
u n ita r io d e !
siguiente
lib r o :
s o lic it u d - r e e m b o ls o
's o lic it u d
ch eq ue
de
de
u n c lie n t e
r e e m b o ls o
p a ra q u e
le s e a e x p e d id o
un
p o r e l m o n to d e s u s a ld o
a c tu a l d e c r d it o *
s o lic it u d - t a s a - r e g a l a
'm e n s a je
don de
lib r o
de
r e e m b o ls o
d e a d q u is ic io n e s
s e s o l ic it a c o n o c e r la t a s a
de
en
r e g a la s d e
un
nuevo*
F avo r de
s o lic it u d - v e n t a
+ s o lic it u d
in d ic a r la t a s a d e
s ig u ie n te
lib r o :
's o lic it u d
d e l d e p a rta m e n to
p r o d u c ir u n r e p o r te
d e
r e g a la s
d e m e rc a d e o
ventas
p a ra to d o s
p e d id o s , c r d it o s y d e v o lu c io n e s q u e
de sp u s
de
la f e c h a
p a ra e l
p a ra
lo s
o c u r r ie r o n
e s p e c if ic a d a *
fe c h a -v e n ta
ta s a - c o m is i n
'p o r c e n t a je d e
c o m is i n
v e n d e d o r p o r la v e n t a d e
fraccin*
qu e se
lib r o s .
le p a g a a u n
S e e x p re s a c o m o
www.FreeLibros.org
'e s c a la : 0 - 0 . 2 5 *
664
C A SO DE E STU D IO : YOURDON PRESS
tasa-impuestos-venta
p o r c e n t a je d e lo s im p u e s t o s s o b r e
e x p re s a d o s c o m o
del 7 %
im p u e s to
u n a fr a c c i n
s e ra
la v e n t a ,
d e c im a l, p . e j., u n
0 .0 7 *
e s c a la : 0 .0 0 - 1 .0 0 *
ta s a -re g a a s
ta s a
de
la s
r e g a la s q u e
se
le p a g a n
a u n a u to r
por
u n lib r o , p . e j., 1 0 s ig n if ic a e l 1 0 % *
e s c a la : 5 - 2 5 *
tip o - p a g o
fo rm a
en que
e l c lie n t e
p a g a r s u
[ E f e c t iv o I C h e q u e I T a r je ta d e
p e d id o
de
lib r o s *
c r d it o I
M a n d a r la c u e n t a ]
t ip o - p e d id o
in d ic a c i n
d e s i u n p e d id o
se
hizo
p o r c o rre o , p o r
t e l f o n o , o p e r s o n a lm e n te *
[T e l fo n o I C o r r e o I E n p e r s o n a ]
t ir a je
c a n t id a d
d e c o p ia s d e
un
lib r o
a im p r im ir *
**
t t u lo
p r e f ijo q u e s e c o lo c a
a n te s
d e l n o m b re
de
una
p e rs o n a *
[ S r .
t t u lo - lib r o
t t u lo
I S r a . I Srta.
c o m p le to
de un
I D r. I P ro f. ]
lib r o d e Y O U R D O N
P re s s *
1 { c a r c te r a lfa n u m r ic o }
t o ta l- c o m is i n
t o ta l d e c o m is io n e s q u e s e
d u ra n te
e l p e ro d o d e
un
le p a g a n
un vendedor
m es, b a sa do en
todos
lib r o s q u e v e n d i . S e c a lc u la e n e l p r o c e s o
lo s
3 .6 *
**
t o ta l- c o p ia s
n m e r o to ta l d e c o p ia s v e n d id a s d e u n
lib r o , t o m a n d o
d u ra n te
**
t o ta l- c r d it o s
un
c a n t id a d
m is m o
e n c u e n t a d e v o lu c io n e s y c r d it o s ,
p e ro d o
to ta l d e
c lie n t e s d u r a n t e
d e tre s
m eses*
c r d it o s q u e
un
s e d a a to d o s
lo s
m es*
to ta l- d e l- p e d id o
c a n t id a d t o ta l d e d in e r o f a c tu r a d o
p o r u n p e d id o *
www.FreeLibros.org
t o ta l- d e v o lu c io n e s
'c a n t id a d
hayan
to ta l d e d in e r o
devuelto
d u ra n te
p o r lib r o s q u e
un
lo s c lie n t e s
m es*
t o ta l- e n - e x is t e n c ia
'n m e r o
de
q u e s e t ie n e
copias d e u n l i b r o d e Y O U R D O N P r e s s
en e x i s t e n c i a e n t o d a s l a s b o d e g a s *
e s c a la : 1 - 1 0 , 0 0 0 '
t o ta l- r e g a l a s - lib r o
't o t a l d e
r e g a la s o b t e n id a s
v e n t a , d e v o lu c i n
p e ro d o
d e tre s
( o p e r d i d a s ) p o r la
o c r d it o d e
un
un
m eses*
to ta l- v e n ta s
'c a n t id a d
to ta l d e
lo s p e d id o s e n
un
por
in g r e s o s
c o n c e p to
d e to d o s
m es*
to ta l- v e n ta s - d ia r io
'm o n t o
to ta l d e v e n ta s
nue vas
r e g is t r a d a s
d ia r ia m e n te *
'u n i d a d e s :
t o ta l- v e n ta s - lib r o
dlares*
't o t a l d e in g r e s o s o b t e n id o s
c u e n ta
u n p e ro d o
p o r la v e n t a d e
d e tre s
u n s o lo
m e s e s , to m a n d o
en
c r d it o s y d e v o lu c io n e s '
'u n i d a d e s : d l a r e s '
v a lo r - d e v o lu c i n
'v a l o r d e
un
lo te d e
lib r o s q u e
se
h a y a d e v u e lt o *
vend edor
@ id e n tific a c i n - v e n d e d o r + n o m b r e - v e n d e d o r
V E N D E D O R E S
{v e n d e d o r}
v e n t a s - a r t c u lo
'in g r e s o
m is m o
bruto p o r
en u n
lib r o
la v e n t a
s o lo
de
u n a o m s c o p ia s d e i
p e d id o '
www.FreeLibros.org
666
C ASO DE E STU D IO : Y O U R D O N PRESS
F.4.4
El diagram a de entidad-relacin
DINERO
consiste en
PAGO
se hizo para
ARTICULO-PEDIDO
consiste en
PEDIDO
se basa en
DEVOLUCION
se basa en
CREDITO
se hizo para
REEMBOLSO
consiste en
se almacena en
ARCHIVO
DETALLE-DEVOLUCION
CLIENTE
AUTOR
escribe
BODEGA
INVENTARIO
consiste en
ARTICULO-INVENTARIO
LIBRO
imprime
IMPRENTA
www.FreeLibros.org
F.4.5
Las Especificaciones del Proceso
PROCESO
1.1.1: EDITAR DETALLES DEL PEDIDO
COMIENZA
S i id e n tificaci n-clie nte -p osible = n u e v o
identifica ci n -clie n te = s i g u i e n t e i d e n t i f i c a c i n c lie n t e
d is p o n ib le
lm ite-crdito = l m i t e d e c r d i t o e s t n d a r
saldo-actual = 0
nivel-plan-agencia = 0
cliente = id e n tifica ci n-clie n te + nom bre-cliente + ( n o m b r e - c o m p a a ) +
d om icilio -clie n te + saldo-actual + m ite-crdito + nivel-planagencia
AADIR r e g i s t r o de cliente n u e v o a CLIENTES
OTRO
ENCONTRAR cliente e n CLIENTES c o n id e n tifica ci n -clie n te = id entificaci ncliente e n detalles-pedido
SI no se
e n c u e n tra
r e g is t r o
respuesta-pedido = N o existe t a l cliente

DESPLEGAR respuesta-pedido
SALIR
n o ta : e s to
s ig n if ic a q u e
n o s e s e g u ir
p ro c e s a n d o
e l p e d id o *
FIN__SI
MIENTRAS h a y a m s artculo-pedido e n d etalles-pedido
ENCONTRAR l i b r o e n LIBROS c o n cla ve -lib ro = ciave-libro
pedido
S i n o s e e n c u e n tra
en
artculo-
r e g is t r o
respuesta-pedido = N o e x i s t e t a l libro
SALIR
n o ta : e s to s ig n if ic a
que
n o s e s e g u ir
p ro c e s a n d o
e l p e d id o *
FINSI
FIN_MIENTRAS
S I tasa-im puestos-ventas e s t f u e r a d e r a n g o
respuesta-pedido = tasa d e i m p u e s t o s i n v l i d a
SALIR
n o ta : e s to
s ig n if ic a
que
no se
s e g u ir
FlfsLSI
S I cargos-envo e s t n f u e r a d e r a n g o
respuesta-pedido c a r g o s d e e n v o
SALIR
p ro c e s a n d o
e l p e d id o *
in v lid o s
www.FreeLibros.org
n o ta : e s to
n o s e s e g u ir
p ro c e s a n d o
e l p e d id o *
668
CASO DE E STU D IO : Y O U R D O N P R ESS
F l N SI
d e ta lle s -p e d id o -v lid o = id e n tific a c i n -c lie n te + {a rtcu lo - pedido) + tasa-im
puestos-ventas + cargos-envo + tipo-pago + (pago- pedido) + (nmerotarjeta-crdito) + pedido-atrasado-O K + tipo-pedido
DESPLEGAR ( a l p r o c e s o 1 . 1 .2) detalles-pedido-vlido
T E R M IN A
PROCESO 1.1.2:
VERIFICAR LIBRO EN EXISTENCIA
C O M IE N Z A
SI
pedido-atrasado-O K = S
DESPLEGAR ( a b u r b u j a
1 .1 .3 )
detalles-pedido-vlido +
Y O N K E R S
O T R O
SI
=en-persona
h a y a m s a rtculo-ped ido en detaiies-pedido-vlido
E N C O N T R A R a rtcu lo-inven tario e n A R T I C U L O S I N V E N T A R I O c o n clave -libro =
cla ve-lib ro e n detalles-pedidov l i d o y identificaci n-bodega =
e l lugar d o n d e s e hizo e l pedido e n p e r s o n a
L E E R r e g i s t r o a rtcu lo-inve n tario
S I can tida d -in ve n ta rio < cantidad-pedida
respuesta-pedido = N o h a y s u f i c i e n t e s l i b r o s p a r a
tip o - p e d id o
M IE N T R A S
s a t is f a c e r s u
p e d id o
S A L IR
n o ta : e s to
n o s e s e g u ir
p ro c e s a n d o
el
p e d id o *
FIN_SI
F !N _ M IE N T R A S
DESPLEGAR ( a b u r b u j a 1.1.4) detalles-pedido-vlido

+ id e ntificaci n-bodega ( d e l a b o d e g a e n el l u g a r
r e c ib i
donde
se
e l p e d id o )
O T R O
s u f ic e n e s - iib r o s
R E P IT E
H A S T A
= S i
que
ya no
haya
o s u f ic ie n t e s - lib r o s
o b s e rv e
que
e s to
bodegas
en
BODEGAS
= S I
s ig n if ic a q u e s e e x a m in a r
p o r lo m e n o s
una
bo d e g a
s u f ic ie n t e s - lib r o s
M IE N T R A S
haya
E N C O N T R A R
= S I
m s
a rticu lo -p ed ido
a r tc u lo - in v e n ta r io
en
detaiies-pedido-vlido
e n A R T IC U L O S -
I N V E N T A R I O con clave-libro = clavelib ro e n detaiies-pe dido-vlido y

identificaci n-bodega = identificacin-bodega
www.FreeLibros.org
a c tu a l d e
bod ega
d e l r e g is t r o
C A S O DE E ST U D IO : YO U R D O N PRESS 669
r e g i s t r o d e a rtcu lo-inve n tario

cantidad -in ventario < cantidad-pedida
su ficie n te s-lb ro s = NO
LE E R
S
F IN _ _ S i
FIN_MIENTRAS
FIN_REPITE
SI s u ficie n te s-lib ro s =NO
respuesta-pedido = N o
h a y s u f ic ie n t e s
lib r o s
p a r a s a t is f a c e r s u
p e d id o
O T R O
( a b u r b u j a 1 . 1 . 4 ) detalles-pedidov lido + ide ntificaci n-bodega d e l
D E S P LE G A R
r e g is t r o
de
bod ega
a c tu a l
F l N__S l
F IN
T E R M IN A
PROCESO 1.1.3:
VERIFICAR AUTORIZACION DE CREDITO
C O M IE N Z A
to ta l- p r e c io
= 0
REPITE HASTA q u e y a n o h a y a a rtculo-ped ido e n detalles-pedldo-vlido

SUMAR (cantidad-pedida * pre cio-un ita rio * descuento) a t o t a l - p r e c i o
FN_REPTE
MULTIPLICAR t o t a l - p r e c i o p o r (1 + tasa-im puestos-ventas)
SUMAR cargos-envo a t o t a l - p r e c i o
c r d i t o - O K = SI
C A S O tipo-pago d e
C A S O tipo-pago = E f e c t i v o o t i p o - p a g o = C H E Q U E
S I t o t a i - p r e c i o > pago-pedido
respuesta-pedido = P r e c i o d e c o m p r a e x c e d e a l a c a n t i d a d
p a g a d a
c r d it o - O K =
n o ta : e s to
p ro c e s a n d o
N o
e l p e d id o
en
n o s e s e g u ir
e s te
m o m e n to *
F IN _ S
C A S O
tipo-pago = T a r j e t a - c r d i t o
pregunta-crdito = S o l i c i t u d
D E S P LE G A R
( a a g e n c ia
d e a u t o r iz a c i n + t o ta l- p r e c io
d e ta r je ta s
d e c r d it o )
p r e g u n ta - c r d it o
( d e a g e n c i a d e c r d i t o ) respuesta-agencia-crdito
SI respuesta-agencia-crdito = N o
respuesta-pedido = S o l i c i t u d d e c r d i t o n e g a d a
A C E P T A R
www.FreeLibros.org
670
CASO DE E ST U D IO : Y O U R D O N P R ESS
c r d it o - O K
= N o
n o ta : e s to
s ig n if ic a
p ro c e s a n d o
que
e l p e d id o
en
n o s e s e g u ir
e s te
m o m e n to *
F IN _ S I
C A S O
tipo-pago
cuenta
clie nte e n CLIENTES c o n id e n tifica ci n c lie nte = id e n tifica ci n -clie n te e n detalies-pedido-vlido
LEER r e g i s t r o d e cliente
SI saldo-actual + t o t a l - p r e c i o > lm ite-crdito
respuesta-pedido = e l p e d i d o e x c e d e s u l m i t e d e c r d i t o
= E n v ia r la
E N C O N T R A R
c r d it o - O K
= N o
N o ta : e s t o s ig n if ic a
que
p ro c e s a n d o
m o m e n to *
en
e s te
n o s e s e g u ir
FIN_S1
F iN _ C A S Q
S I c r d it o - O K = s
D E S P LE G A R
( a b u r b u ja
to ta l- p r e c io
D E S P LE G A R
(a
b u r b u ja
1 .1 .4 ) d e t a lle s - p e d id o - v lid o
+ id e n t if ic a c i n - b o d e g a
1 .1 .5 ) d e t a lle s - p e d id o - v lid o
F IN _ S
T E R M IN A
PROCESO 1.1,4:
INGRESAR PEDIDO
C O M IE N Z A
MIENTRAS
artcu lo-pe d id o e n detalles-pedido-vlido

d e a rtculo -p e d ido a p a r t i r d e l s i g u i e n t e artculo-pedido
detalles-pedido-vlido
A A D I R r e g i s t r o d e a rtculo-ped ido a ARTICULOS-PEDIDOS
FINJVIIENTRAS
C R E A R r e g i s t r o d e pedido a p a r t i r d e detalies-pedido-vlido y id e n tifica ci n bodega
AADIR r e g i s t r o d e pedido a P E D I D O S
haya
C R E A R
C R E A R
A A D IR
r e g is t r o
d e fa c tu ra
r e g is t r o
SI tipo-pago =
C R E A R
A A D IR
C R E A R
A A D IR
m s
r e g is t r o
de
factura
a p a r t ir d e
a
en
d e t a lle s - p e d id o - v lid o
FACTURAS
E f e c t iv o o C h e q u e o T a r je ta d e c r d it o
r e g is t r o
r e g is t r o
r e g is t r o
r e g is t r o
d e d in e r o
de
de
de
a p a r t ir d e d e t a lle s - p e d id o - v lid o
d inero a DINERO
pago a p a r t i r d e d etalies-pedido-vlido
pago a PAGOS
www.FreeLibros.org
i f in _ s i
: A A D I R detalles-pedido-vlido a ARCHIVOS
respuesta-pedido = Pedido aceptado
: DESPLEGAR respuesta-pedido
TERMINA
PROCESO 1.1.5:
VERIFICAR INVENTARIO PARA REIMPRIMIR
C O M IE N Z A
a rtculo-ped ido en detalies-pedido-vlido

a rtculo -in ven ta rio e n A R T I C U L O S - I N V E N T A R I O c o n
clave-libro = c l a v e - l i b r o e n a rtculo -p e d ido y
identificacin-bodega d a d a c o m o e n t r a d a e n e s t e p r o c e s o
L E E R r e g i s t r o d e a rtculo -in ven ta rio
R E S T A R cantidad-pedida d e cantidad-inventario
* n o t a : e s t o p u d i e r a r e s u l t a r e n un inventario n e g a t i v o ;
M IE N T R A S
haya
m s
E N C O N T R A R
s im p le m e n te s ig n if ic a
p e d id o
h a s ta q u e
que
lle g u e
la b o d e g a
una
n o p o d r
s u r tir e l
r e im p r e s i n
r e g i s t r o d e a rtcu lo-inve n tario

ENCONTRAR lib ro e n LIBROS c o n clave -libro = clave-libro
artculo-ped ido
L E E R r e g i s t r o d e lib ro
RESTAR cantidad-pedida d e total-en-existencia
E S C R I B I R r e g i s t r o d e libro
Si total-en-existencia < um bral-repetir-pedido
a viso-inventa rio-bajo = cla ve-lib ro + TOTAL-ENEXISTENCA + t i e m p o d e r e i m p r i m i r
DESPLEGAR aviso-inventa rio-bajo
E S C R IB IR
F IN
en
SI
FINJV ENTRAS
TER M IN A
PROCESO
1 .2 :
P o r a h o r a , la
p ro c e s a r u n
PROCESAR PEDiDO DE VENDEDOR

p r o c e s a r un p e d i d o d e u n v e n d e d o r e s l a m i s m a q u e
normal d e u n c l i e n t e . V e a l a F i g u r a 1 . 1 p a r a m s d e t a l l e s
p o lt ic a p a r a
p e d id o
PROCESO 1.3:
p a ra
INSCRIBIR CLIENTE EN PLAN DE AGENCIA
P r e c o n d ic i n - 1 .
E x is te
u n cliente e n CLIENTES que a l que c o r r e s p o n d e

ide n tifica ci n -clie n te c o n nivel-plan-agencia = 0
y c o n eleccin-plan-agencia > 0
y eleccin-plan-agencia m e n o r o i g u a l q u e m x i m
nivel
d e a g e n c ia .
p o s t c o n d ic i n - 1 .
www.FreeLibros.org
nivel-plan-agencia
en
clie nte
se
hace
ig u a l
a eleccin-pian-agencia
672
C A SO DE E STU D IO : YO U R D O N P R ESS
PROCESO 1.4:
ENVIAR FACTURAS
C O M IE N Z A
m s factura
siguiente factura
A R factura
M IE N T R A S
haya
FACTURAS
en
LE E R
D E S P LE G
F IN _ M IE N T R A S
T E R M IN A
PROCESO 2.1:
PROCESAR PAGOS
C O M IE N Z A
SI identifica ci n -clie n te
E N C O N T R A R
cliente
SI no se
e s t
r e g is t r o
p re s e n te
en
CLIENTES
con
id e n tifica ci n -
c o r r e s p o n d ie n te
p u e d e e n c o n t r a r r e g is t r o
E S C R IB IR
detalles-pago
" E f e c t iv o
PAGOS
con
id e n tificaci n-cliente
n o a p lic a d o
O T R O
m onto-total a saldo-actual
r e g i s t r o a CLIENTES
I B I R detalles-pago a PAGOS
R E S T A R
E S C R IB IR
E S C R
O TR O
E S C R IB IR
E S C R IB IR
detalles-pago a PAGOS c o n id e n tifica ci n cliente = E f e c t i v o n o a p l i c a d o

f e c h a a c t u a l + ide ntifica ci n -clie n te +
detailes-pago a DINERO
F IN _ S I
T E R M IN A
PROCESO 2.2: PROPORCIONAR INFORMACION DE LIBROS

C O M IE N Z A
E N C O N T R A R
r e g is t r o
de
lib ro
en
LIBROS
con
ttu lo -iib ro
c o r r e s p o n d ie n te
respuesta-in form acin-iibro = c o n t e n i d o d e

D E S P L E G A R re spuesta-in form acin-libro
to d o
e l r e g is t r o
libro
T E R M IN A
P R O C E S O
2 .3 :
PROCESAR SOLICITUD DE DEVOLUCION
C O M IE N Z A
E N C O N T R A R
pedido e n PEDIDOS que c o r r e s p o n d a

factura e n solicitu d -d e vo lu ci n
S I n o s e e n c u e n tr a
con
nm ero-
e l r e g is t r o
respu esta -so licitu d-de volu cin = N o s e e n c u e n t r a

D E S P L E G A R respuesta-so iicitu d-de voiu cin
e s te
p e d id o
www.FreeLibros.org
O T R O
LE E R
r e g is t r o
de
pedido
S I fe c h a d e e n v o
es
hace
m s de
un ao
respuesta-d evolucin-libro =
e n v ia r o n
hace
m s de
lo s
lib r o s s e
un ao
DESPLEGAR respu esta -so licitu d-de volucin

O T R O
to d o -O K
= s
R E P IT E
H A S T A
qu e
no
haya
m s
a rtcu lo-devu elto
en
detalles-devolucin
a rtculo-ped ido e n ARTICULOS-PEDIDOS
nm ero-factura
e n s o licitu d -d e vo lu ci n y clavelib ro e n artculo-devu elto
E N C O N T R A R
q u e c o rre s p o n d a c o n
S I n o s e e n c u e n tra
D E S P LE G A R
to d o -O K
r e g is t r o
E s te
lib r o
n o fu e
p a r te d e l p e d id o
= n o
O T R O
LEER r e g i s t r o d e artculo-ped ido

SI cantidad-a-devolver e n artculodevuelto e s m s q u e l a m i t a d d e l a
cantidad-pedida e n artculo-pedido
respuesta-so licitud -d evo lu cin = N o
ta n to s
se
pueden
d e v o lv e r
lib r o s
DESPLEGAR respu esta-so licitud-devolucin

to d o -O K
= no
F IN _ S I
F IN
S i
F IN R E P IT E
S I to d o -O K
= s
# -autorizacin-devoiucin d e #AUTORIZACION-DEVOLUCION
respuesta-so licitu d-de volu ci n = D e v o l u c i n
LE E R
c o r re c ta + F a v o r d e
id e n t if ic a r d e v o lu c i n
+ #-autorizacn-devoIucin
D E S P L E G A R respue sta-so licitud -d evo lucin
E S C R I B I R d etalles-devolucin, #-autorzacind evoluci n a DEVOLUCIONES-AUTORIZADAS
S U M A R 1 a # -autorizacin-devolucin
E S C R I B I R #-autorizaci n-devolucin a #AUTORIZACION-DEVOLUCION
a c tu a l m e d ia n te
F IN
SI
F IN S i
www.FreeLibros.org
F IN _ S I
T E R M IN A
674
PROCESO 2.4: RESPONDER A PREGUNTA SOBRE STATUS DE PEDIDO

COMIENZA
ENCONTRAR pedido en PEDIDOS con nm ero-factura correspondiente
SI no se encuentra registro
respuesta-status-pedido = No existe pedido con tal nmero de factura
DESPLEGAR respuesta-status-pedido
OTRO
LEER registro de pedido en PEDIDOS con nm ero-factura correspondiente
respuesta-status-pedido = fecha-pedido + {artculospedidos} + fecha-envo
DESPLEGAR respuesta-status-pedido
FIN_Si
TERMINA
PROCESO 2.5: RESPONDER A PREGUNTA SOBRE FACTURA
COMIENZA
ENCONTRAR pedido en PEDIDOS con nm ero-factura correspondiente
respuesta factura = no existe pedido con tai nmero de factura
DESPLEGAR respuesta-factura
OTRO
LEER registro de pedido
respuesta-factura = fecha-pedido + {artculo-pedido} +
cargos-envo + im puestos-venta
DESPLEGAR respuesta-factura
Fi N Si
TERMINA
PROCESO 2.6: PRODUCIR RECORDATORIO DE CREDITO
COMIENZA
ENCONTRAR pedido en PEDIDOS con id e n tifica ci n-cliente
correspondiente y nm ero-factura que corresponda
con nm ero-factura en s o lic itu d -c r d ito
respuesta-crdito = No existe ta l pedido para este cliente
DESPLEGAR respuesta-crdito
OTRO
ENCONTRAR c r d ito en CREDITOS con nm ero-factura
que corresponda con nm ero-factura en
s o lic itu d -c r d ito
SI se encuentra registro
respuesta-crdito = Ei crdito ya se otorg
OTRO
CASO razn-crdito de
www.FreeLibros.org
CASO razn-crdito = EXCESO DE PAGO

ENCONTRAR pago en PAGOS co n nm erofactura que corresponda con
nm ero-factura en s o lic itu d -c r d ito
respuesta-crdito = No se hizo ningn pago
para tal nmero de factura
OTRO
LEER pago
ENCONTRAR pedido en PEDIDOS con
nm ero-factura = nmerofactura en s o lic itu d -c r d ito
SI m onto-total > total-de l-pe dido respuesta-crdito
= El crdito se mostrar en el siguiente saldo
OTRO
respuesta-crdito = No hubo
exceso en ei paqo de ia factura
FIN_SI
FIN_SI
CASO razn-crdito = Retraso excesivo
cr d ito = num ero-factura +
id en tifica ci n -clie n te + fecha-actual +
total-del-pedido
AADIR crdito a CREDITOS
respuesta-crdito = Crdito por cantidad total del pedido
CASO razn-crdito = Envo incompleto
SI total-pedid os > m onto-de-crd ito-solicitado
cr d ito = nm ero-factura +
ide ntifica ci n -clie n te + fecha-actual +
m on to-de-crd ito-solicitado
respuesta-crdito = Crdito por
envo incompleto: + m onto-de-crd ito-solicitado
OTRO
crdito= nm ero-factura + id e n tifica ci n -clie n te +
fecha actual + total-del-pe dido
envo incompleto: + total-del-pe dido
FIN_SI
AADIR crdito a CREDITOS
www.FreeLibros.org
676
CASO razn-crdito = libros daados

SI tota l-pe did o s > m onto-de-crdito-solicitado
crdito = nm ero-factura +
id e n tifica ci n -clie n te + fecha actual +
m o nto-de-crd ito-solicitado
libros daados: + m onto-de-crd ito-solicitado
OTRO
crdito = nm ero-factura +
+ ide ntifica ci n -clie n te + fechaactual + total-del-pedido
FIN_SI
AADIR crd ito a CREDITOS
FINLCASO
FIN_SI
FIN_SI
TERMINA
PROCESO 2.7: AVISAR A CONTABILIDAD DE LA NECESIDAD DE REEMBOLSO
COMIENZA
ENCONTRAR cliente en CLIENTES con ide ntifica ci n -clie n te que corresponda
con ide n tifica ci n -clie n te en solicitud-reem bo lso
so licitu d -re e m b o lso = no existe tal cliente
DESPLEGAR so licitu d-re em bo lso
OTRO
LEER registro de cliente
SI saldo-actual es mayor o igual a cero so licitud-reem bo lso
= No hay reembolso" + Saldo actual es + saldo-actual
DESPLEGAR so licitu d -re e m bo lso
OTRO
so licitu d -re e m b o lso = reembolso aprobado
s o iicitud-cheq ue-reem boiso = Favor de pagar +
id en tifica ci n -clie n te + saicto-actuai
DESPLEGAR solicitud -ree m bo lso
DESPLEGAR solicitud-cheq ue-reem bolso
ESCRIBIR cero en saido-actua! en registro de cliente
ESCRIBIR fecha actual + id e n tificaci n-cliente +
saido-actual a REEMBOLSOS
FIN SI
FIN_SI
TERMINA
www.FreeLibros.org
PROCESO 2.8: FIJAR NUEVO LIMITE DE CREDITO

COMIENZA
ENCONTRAR cliente en CLIENTES que corresponda con
id e n tifica ci n-clien te
respuesta-lm ite-crdito = No existe tal cliente
OTRO
SI nuevo-lm ite-crdito < 0
respuesta-lm ite-crdito = lmite de crdito invlido
DESPLEGAR respuesta-lm ite-crdito
OTRO
respuesta-lm ite-crdito = Nuevo lmite de crdito correcto
DESPLEGAR respuesta-lm ite-crdito
REEMPLAZAR lm ite-crdito por nuevo-lm ite-crdito
ESCRIBIR registro de cliente
FIN_Sf
FIN__SI
TERMINA
PROCESO 2.9: MODIFICAR DETALLES DE CLIENTES
COMIENZA
ENCONTRAR cliente en CLIENTES que corresponda con
id e n tificaci n-clie nte
respuesta-m od ificacin-cliente = No existe tal cliente
DESPLEGAR respuesta-m od ificacin-cliente
OTRO
REEMPLAZAR nom bre-cliente, nom bre-com paa, d o m icilio cliente con nom bre-cliente, nom bre-com paa,
d o m icilio -clie n te en detalles-clien te
respuesta-m od ificacin-cliente = modificacin aceptada
DESPLEGAR respuesta-m odificacin-ciiente
FIN Si
TERMINA
PROCESO 3.1: PRODUCIR RECIBOS DE EFECTIVO
COMIENZA
efectivo-recolectado = 0
MIENTRAS haya ms registros en DINERO
LEER siguiente registro de d inero
DESPLEGAR dinero
efectivo-recolectado = efectivo-recolectado + cantidad-dinero
www.FreeLibros.org
678
FiNJVIiENTRAS
inform e-efectivo = efectivo-recolectado
DESPLEGAR inform e-efectivo
TERMINA
PROCESO 3.2: PRODUCIR INFORME DE VENTAS DIARIO
COMIENZA
total-diario = 0
MIENTRAS haya ms pedido en PEDIDOS con fecha-pedido = fecha
actual
LEER siguiente pedido con fecha-pedido = fecha actual
SUMAR nm ero-factura, nom bre-cliente, nom bre-com paa,
pedido-total como nuevo rengln en inform e-ventas-diario
SUMAR to ta l-p ed id o s a total-diario
FINJVIIENTRAS
SUMAR total-diario como nuevo rengln en inform e-ventas-diario
DESPLEGAR inform e-ventas-d iario
PROCESO 3.3: PRODUCIR INFORME DE VENTAS MENSUAL
total-ventas = 0
total-devolu ciones = 0
to ta l-cr d ito s = 0
MIENTRAS haya ms pedido en PEDIDOS con fecha-pedido de este mes
SUMAR tota l-p ed id o s a total-ventas
FINJVIIENTRAS
MIENTRAS haya ms d e voluci n en DEVOLUCIONES con fechadevoluci n de este mes
SUMAR valor-d evo lu ci n a total-devoluciones
FINJVIIENTRAS
MIENTRAS haya ms cr d ito en CREDITOS con fecha-crdito de este mes
SUMAR m onto-de-crdito a to ta l-cr d ito s
FINJVIIENTRAS
inform e-ventas-m ensual = total-ventas, total-devoluciones, to ta l-cr d ito s
DESPLEGAR inform e-ventas-m ensual
TERMINA
PROCESO 3.4: PRODUCIR INFORME DE REGALIAS TRIMESTRAL
COMIENZA
MIENTRAS haya ms lib ro en LIBROS
total-libros = 0
total-ventas = 0
total-regalas = 0
LEER siguiente registro de lib ro
MIENTRAS haya ms pedido en PEDIDOS con fecha-pedido de este trimestre
www.FreeLibros.org
LEER siguiente registro de pedido

MIENTRAS haya ms a rtculo-pedido en ARTICULOSPEDIDOS con nm ero-factura que corresponda con nm ero-factura en
registro de pedido actual y cla ve-iib ro que corresponda con clave-libro en
registro de lib ro actual
LEER siguiente artculo-pedido
SUMAR cantidad-pedida a total-libros
esta-venta = cantidad-pedida * p re cio-un ita rio * descuento
SUMAR esta-venta a total-ventas
SUMAR (esta-venta * total-regalas) a totai-regalas
AADIR id e ntifica ci n-clien te, nom bre-cliente, nm ero-factura, estaventa, (esta-venta * totai-regalas) al siguiente rengln de
nform e-regalas-trim estrai
FiNJVll ENTRAS
FINJV1IENTRAS
MIENTRAS haya ms crd ito en CREDITOS con clave-libro que
corresponda con cla ve-lib ro en registro de lib ro actual y fecha-crdito de
este trimestre
LEER siguiente crdito
RESTAR cantid ad -lib ro s-a-cr dito de total-libros
RESTAR m onto-de-crdito de total-ventas
RESTAR (m onto-de-crdito * tasa-regalas) de total-regalas
AADIR id e n tifica ci n -clien te, nom bre-cliente, nm ero-factura,
m onto-de-crdito, (m onto-de-crdito * tasa-regalas) al siguiente
rengln de inform e-regala s-trim estra l
FINJVil ENTRAS
MIENTRAS haya ms d evoluci n en DEVOLUCIONES con clavelib ro que corresponda con cla ve -lib ro en registro de
lib ro actual y fecha-devolucin de este trimestre
LEER siguiente devoluci n
RESTAR cantidad-devuelta de total-libros
RESTAR vaior-devolu cin de total-ventas
RESTAR (valor-devolucin * tasa-regalas) de total- regalas
AADIR id e n tificaci n-clie nte , nom bre-cliente,
nm ero-factura, valor-d evo lu ci n, (valordevoluci n * tasa-regalas) al siguiente
rengln de inform e-trim estrai-regalas
F1N...MI ENTRAS
AADIR total-libros, total-ventas, total-regalas ai
siguiente rengln de inform e-regala s-trim estral
FINJVilENTRAS
DESPLEGAR inform e-regalas-trim estral
TERMINA
www.FreeLibros.org
680
PROCESO 3.5: PRODUCIR INFORME DE INVENTARIO

COMIENZA
REPITE HASTA que ya no haya lib ro en LIBROS
LEER siguiente lib ro en LIBROS
total-inventario = 0
REPITE hasta que no haya ms a rtculo -in ven tario en
ARTCULOS-INVENTARIO con clave-libro que corresponda con clave-libro
en lib ro
SUMAR cantida d -in ve nta rio a totai-inventario
SUMAR identificaci n-bodega, ciave-libro, cantidad- inventario
al siguiente rengln de reporte-inventario
FIN_REPITE
SUMAR total-inventario a! siguiente rengln de reporte-inventario
FN_REP!TE
TERMINA
PROCESO 3.6: PRODUCIR INFORME DE COMISION DE VENTAS
COMIENZA
MIENTRAS haya ms vendedor en VENDEDORES
LEER siguiente registro de vendedor
comisin-vendedor = 0
MIENTRAS haya ms pedido en PEDIDOS con identificaci n-vendedor
que corresponda con identifica ci n-ven de d or en vendedor
y con fecha-pedido de este mes
comisin = tasa-com isin * total-del-pedido
SUMAR comisin a comisin-vendedor
AADIR ide ntificaci n-vendedor, nm ero-factura,
comisin al siguiente rengln de reporte-com isin
FIN_MI ENTRAS
AADIR comisin-vendedor al siguiente rengln de reporte-com isin
FIN_MIENTRAS
TERMINA
PROCESO 3.7: PRODUCIR DECLARACIONES
COMIENZA
REPITE HASTA que ya no haya cliente en CLIENTES
saldo-nuevo = saldo-actual
MIENTRAS haya ms pedido en PEDIDOS con id e n tifica ci n cliente = ide n tifica ci n -clie n te en registro de cliente actual y fecha-pedido
posterior a fecha-saldo-actual
SUMAR to ta i-p e d id o s a saldo-nuevo
AADIR pedido a! siguiente rengln de declaracin
www.FreeLibros.org
FIN_MIENTRAS
MIENTRAS haya ms pago en PAGOS con id e n tifica ci n cliente = id e n tificaci n-clie nte en registro de cliente actual y fecha-pago
posterior a fecha-saido-actuai
LEER siguiente registro de pago
RESTAR total-del-pedido de saldo-nuevo
AADIR pago al siguiente rengln de declaracin
FIM.MIENTRAS
MIENTRAS haya ms reeem bolso en REEMBOLSOS con
Id e n tifica ci n -clie nte = id e ntifica ci n -clie n te en registro actual de cliente y
fecha-reem bolso posterior a fecha-saldo-actual
LEER siguiente registro de reem bolso
SUMAR m onto-del-reem bolso a saldo-nuevo
AADIR reem bolso al siguiente rengln de declaracin
FIN_MIENTRAS
MIENTRAS haya ms crd ito en CREDITOS con id e n tifica ci n -clie n te =
ide n tifica ci n -clie n te en registro de cliente actual y fecha-crdito posterior
a fecha-saldo-actual
LEER siguiente registro de crdito
RESTAR m onto-de-crdito de saldo-nuevo
AADIR crdito al siguiente rengln de declaracin
FiN_MIENTRAS
MIENTRAS haya ms d evoluci n en DEVOLUCIONES con
iden tifica ci n -clie n te = ide ntifica ci n -clie n te en registro de cliente actual y
fecha-devo lucin posterior a fecha-saldo-actual
LEER siguiente registro de devoluci n
RESTAR valor-d evo lu ci n de saldo-nuevo
AADIR pago al siguiente rengln de declaracin
FINJMIENTRAS
tADIR saldo-nuevo al siguiente rengln de declaracin
DESPLEGAR declaracin
HaOER fecha-saldo-actual en registro de pedido actual igual a fecha de hoy
HACER saldo-actual en registro de pedido actual igual a saldo-nuevo
FINJHEPITE
TERMINA
PROCESO 3.8: PRODUCIR REPORTE DE CUENTAS POR COBRAR
COMIENZA
REPITE HASTA que ya no haya cliente en CLIENTES
LEER siguiente registro de cliente
saldo-nuevo = saldo-actual
MIENTRAS haya ms pedido en PEDIDOS con id e n tifica ci n cliente = id e n tifica ci n -clien te en registro de cliente actual y fecha-pedido
posterior a fecha-saldo-actual
www.FreeLibros.org
682

SUMAR total-d el-pe d id o a saldo-nuevo
FIN .MIENTRAS
MIENTRAS haya ms pago en PAGOS con identificaci ncliente = ide n tifica ci n -clie n te en registro de cliente actual
y fecha-reem bolso posterior a fecha-saldo-actual
LEER siguiente registro de reem bolso
RESTAR m onto-del-reem bolso a saldo-nuevo
F IN J V il E N T R A S
MIENTRAS haya ms crd ito en CREDITOS con

ide n tifica ci n -clie n te = id e n tificaci n -clie nte en registro actual de cliente
fecha-crdito posterior a fecha-saldo-actual
LEER siguiente registro de crdito
RESTAR m onto-de-crdito de saldo-nuevo
AADIR crdito al siguiente rengln de declaracin
FINJMENTRAS
MIENTRAS haya ms d evoluci n en DEVOLUCIONES con
id e n tifica ci n -ciien te= id en tifica ci n -clie n te en registro de cliente actual
fecha-devolucin posterior a fecha-saldo-actual
LEER siguiente registro de devolucin
RESTAR valor-d evo lu ci n de saldo-nuevo
FIN_MIENTRAS
FINJREPITE
AADIR id e n tifica ci n -clie nte , saldo-nuevo al siguiente
rengln de informe-cuentas-por-pagar
DESPLEGAR reporte-cuentas-por-cobrar
TERMINA
PROCESO 4.1: ACEPTAR COTIZACION DE LA IMPRENTA
COMIENZA
ACEPTAR (de imprenta) iden tifica ci n -im p ren ta, cotizacin-im prenta
DESPLEGAR (a administracin) identificaci n-im prenta, cotizacin-im prenta
TERMINA
PROCESO 4.2: HACER PEDIDO DE IMPRESION
COMIENZA
ENCONTRAR lib ro en LIBROS con clave -libro q u e corresponda con
ciave -libro en instruccion es-p ed id o-im p re si n
respuesta-pedido-im presin = No existe ta i libro
DESPLEGAR respuesta-pedido-im presin
OTRO
SI tira je < 0
respuesta-pedido-im presin = Cantidad de im p re s i n invlida
www.FreeLibros.org
OTRO
respuesta-peddo-im presin = Pedido de impresin aceptado
HACER cantidad-sobre-pedido en lib ro igual a tiraje
HACER fecha-disp o nib ilid ad en lib ro igual a fechad isp o n ib ilid a d en instruccio ne s-p e dido-im presin
ESCRIBIR registro de lib ro
pedido-im presin = clave-lib ro + tira je
DESPLEGAR pedido-im presin, identificaci n -im p renta
FlfsLSl
FlfxtSl
t e r m in a
PROCESO 4.3: REVISAR PEDIDO DE LIBROS

COMIENZA
ENCONTRAR lib ro en LIBROS con ciave-lbro que corresponda con clave-fibro
en pedido -im pre sin-m odificado
respuesta-p edido-im presin-m odificado = No existe tal libro
DESPLEGAR respuesta-pedido-im presin-m odifcado
OTRO
LEER registro de lib ro
HACER cantidad-sobre-pedido igual a cantidad-m odificada
HACER fecha-disp o nib ilid ad igual a fecha-m odificada
ESCRIBIR registro de lib ro en LIBROS
respuesta-pedido-im presin-m odificado = Pedido de libros
revisado correcto
DESPLEGAR respuesta-p edido-im presin-m odificado
FIN_SI
TERMINA
PROCESO 4.4: PROCESAR FACTURA IMPRENTA
COMIENZA
ENCONTRAR lib ro en LIBROS con clave-libro que corresponda con
clave-libro en factura-im prenta
respuesta-factura-im prenta = No existen pedidos pendientes para este libro
DESPLEGAR respuesta-factura-im prenta
OTRO
DESPLEGAR factura-im prenta (a administracin para su aprobacin)
ACEPTAR autorizacin -factura-im prenta
SI autorizacin -factura-im prenta = NO
respuesta-factura-im prenta = Factura rechazada;
Favor de comunicarse con ia administracin para discutirlo
www.FreeLibros.org
684
OTRO
respuesta-factura-im prenta = Factura aceptada
factura-im prenta-aprobada = factura-im prenta
DESPLEGAR factura-im prenta-aprobada
F1N__SI
FIN SI
TERMINA
PROCESO 4.5: PEDIR COTIZACION IMPRENTA
COMIENZA
MIENTRAS haya ms im prenta en IMPRENTAS
LEER siguiente r e g i s t r o de im prenta
SI im prenta corresponde con alguna d e las identificaci n-im p renta en ia
entrada a este proceso so licitu d -co tiza ci n = clave-libro + {cantidad}
DESPLEGAR so licitu d -co tiza ci n
FIN _SI
FINJVIIENTRAS
TERMINA
PROCESO 5 : CREAR NUEVO REGISTRO DE LIBROS
COMIENZA
DESPLEGAR (para administracin) ttu lo -lib ro + so licitud-clave-lbro
ACEPTAR (de administracin) ciave-libro
DESPLEGAR (para adquisiciones) ttu lo -lib ro + solicitud-tasa- regalas
ACEPTAR (de adquisiciones) tasa-regalas
DESPLEGAR (para mercadeo) ttu lo -lib ro + so licitu d -p re cio -u n ita rio
ACEPTAR (de mercadeo) p recio-un ita rio
'
lib ro = ciave -lib ro + ttu lo -lib ro + ide n tifica ci n -a u to r + total-regalas
HACER total-en-existencia igual a cero
HACER fech a -d isp o n ib ilid a d igual a fecha-en-existencia
AADIR lib ro a LIBROS
TERMINA
PROCESO 6.1: PRODUCIR ETIQUETAS DE ENVIO
COMIENZA
ORDENAR CLIENTES por c digo-po stal en etiquetas-envo
DESPLEGAR etiquetas-envo
TERMINA
PROCESO 6.2: PRODUCIR ESTADISTICAS DE VENTAS
COMIENZA
REPITE hasta que n o haya ms lib ro en LIBROS
www.FreeLibros.org
Ingresos-venta = 0
devoluciones-ventas = 0
crditos-venta = 0
MIENTRAS h a y a ms pedido en PEDIDOS con fecha-pedido
posterior a fecha-venta
MIENTRAS haya ms artculo-pedido en el registro de
pedidos actual con cla ve-lib ro = cla ve -libro en registro actual de lib ro
LEER siguiente registro de artculo-pedido
SUMAR (cantidad-pedida * p re cio -u nita rio *
descuento) a ingresos-venta
FINJVIIENTRAS
FINJVIIENTRAS
MIENTRAS haya ms d evolucin en DEVOLUCIONES con fechadevoluci n posterior a fecha-venta y cia ve -lib ro = clave-libro en registro de
lib ro actual
SUMAR va lo r-de volu ci n a devoluciones-ventas
FINJVIIENTRAS
MIENTRAS haya ms crd ito en CREDITOS con fecha-crdito
posterior a fecha-venta y clave -libro = cia ve-lib ro en
registro de lib ro actual
SUMAR m onto-de-crdito a crditos-ventas
FINJVIIENTRAS
AADIR clave-libro, ingresos-venta, devoluciones-ventas, crditos-venta,
ai siguiente rengln de estadsticas-venta
FINJREPiTE
DESPLEGAR estadsticas-ventas
TERMINA
PROCESO 6.3: PRODUCIR FECHA DE EXISTENCIAS
COMIENZA
ENCONTRAR lib ro en LIBROS que corresponda con clave-libro
respuesa-de-existencias = No existe tal libro
DESPLEGAR respuesta-de-existencias
OTRO
SI fe ch a -d ispo n ib ilid ad = nulo
respuesta-de-existencas = No existen envos pendientes
OTRO respuesta-de-existencias = fe ch a -disp o nibilidad
DESPLEGAR respuesta-de-existencias
FIN_SI
FIN_SI
TERMINA
www.FreeLibros.org
686
PROCESO 6.4: ELIMINAR LIBRO

COMIENZA
Si no se encuentra registro
respuesta-libro-agotado = No existe tal libro
DESPLEGAR respuesta-libro-agotado
OTRO
HACER indicad o r-lib ro -a g o ta do igual a S
respuesta-libro-agotado = Ei libro se ha declarado agotado
DESPLEGAR respuesta-libro-agotado
FIN_SI
TERMINA
PROCESO 7.1: PRODUCIR DOCUMENTOS DE ENVIO
COMIENZA
REPITE HASTA que ya no haya bodega en BODEGAS
LEER siguiente registro de bodega
*nota: esta parte produce la lista de seleccin para la bodega*
REPITE HASTA que ya no haya lib ro en LIBROS
libros a seleccionar = 0
MIENTRAS haya ms pedido en PEDIDOS con fechapedido = techa de hoy y identificaci n-bodega que
corresponda con identificacin-bodega en registro actual de bodega
MIENTRAS haya ms artculo-ped ido con nm erofactura = nm ero-factura en registro de pedido
LEER siguiente registro de artculo-pedido
SUMAR cantidad-pedida a libros por seleccionar
FINJVIIENTRAS
FIN_MIENTRAS
AADIR ttu lo -lib ro , libros-por-seleccionar al siguiente
rengln de docum entos-envo
FiNJREPITE
*nota: esta parte produce las etiquetas de envo*
de hoy y identificacin-bodega = identificaci n-bodega en
registro de bodega actual
AADIR nom bre-cliente, d o m icilio -clie n te , nm ero-factura
a siguiente rengln de docum entos-envo
FINJVIIENTRAS
'nota: esta parte produce una copia del pedido original para la bodega*
www.FreeLibros.org

de hoy y identificacin-bodega = identificacin-bodega en
registro de bodega actual
AADIR id e n tifica ci n -clien te, fecha-pedido,
cargos-envo, im puesto-venta al siguiente
rengln de docum entos-envo
REPITE HASTA que ya no haya artculo -p ed ido en
ARTICULOS-PEDIDOS con nm ero-factura que
corresponda con nm ero-factura en registro actual de pedido
AADIR artculo-ped ido al siguiente rengln de
docum entos-envo
FiNREPITE
FINJVIIENTRAS
FIN_REPITE
TERMINA
PROCESO 7 . 2 : REGISTRAR ENVIOS DE IMPRENTA
COMIENZA
ENCONTRAR lib ro en LIBROS que corresponda con ttu lo -lib ro
n otificacin -e nvo = No existe ta i libro
DESPLEGAR no tificacin -e nvo
OTRO
n otificacin -e nvo = Recibido de la imprenta + clavelibro + cantidad-recibida
DESPLEGAR n otificacin -e nvo
SUMAR cantidad-recibida a total-en-existe ncia
HACER cantidad-sobre-pedido igual a cero
ESCRIBIR registro de lib ro en LIBROS
LEER artcu lo-in ve n tario en ARTICULOS-INVENTARIO con
identificacin-bodega = YONKERS y que corresponda con clave-libro
SUMAR cantidad-recibida a cantidad -in ventario
ESCRIBIR registro de a rtculo -in ven ta rio
FIN__SI
TERMINA
PROCESO 7.3: REGISTRAR DEVOLUCIONES DE LIBROS POR CLIENTES
COMIENZA
ENCONTRAR cliente en CLIENTES con id e n tifica ci n -clie n te que corresponda
con id e n tifica ci n -clien te en in form a ci n -d e vo lu ci n -lib ro o con
nom bre-cliente que corresponda con nom bre-cliente en
in fo rm a ci n-de vo lu ci n-lib ro
www.FreeLibros.org
688
in struccio ne s-d e volu cin = No se puede identificar
cliente; a c e p ta r libros de cualquier forma
DESPLEGAR in struccio ne s-d e volu cin
OTRO
ENCONTRAR devolucin-autorizada en DEVOLUCIONESAUTORIZADAS con #-autorizacin-devo!uciones que
corresponda con #-autorizacln-devoluciones en
in fo rm a cin -d e volu cin -libro
in stru ccio ne s-d e vo luci n = Esta devolucin no fue
a u to riz a d a ; favor de re g re s a rla
a p ro ba ci n -d evo iuci n-lib ro = Esta devolucin no
fue autorizada"
DESPLEGAR (para c lie n te ) a prob aci n-devolucin-libro
FIN SI
FIN SI
REPITE HASTA que ya no haya cla ve-libro en in fo rm acin-de volucin-libro
ENCONTRAR a rtcu lo -in ve n ta rio en ARTICULOS-INVENTARIO
que corresponda con identificacin-bodega y clave-iibro que
corresponda con cla ve-lib ro en in fo rm acin-de volucin-libro
in stru ccion e s-d e vo lu cin = No existe tal libro
OTRO
LEER registro de artculo -inve n ta rio
SUMAR cantidad-devuelta a cantidad-inventario
ESCRIBIR re g is tro de artculo -inve n ta rio
ENCONTRAR lib ro en LIBROS que corresponda con
id e n tific a c i n -lib ro
SUMAR cantidad-devuelta a total-en-existencia
FIN.SI
FINJREP1TE
AADIR in fo rm a ci n -d e vo lu ci n -lib ro a DEVOLUCIONES
FIN
PROCESO 7.4: REGISTRAR INVENTARIO FISICO
COMIENZA
ENCONTRAR bodega en BODEGAS que corresponda con
identificaci n-bodega
www.FreeLibros.org
respuesta-inventario-fsico = No e x is te tai b o d e g a
DESPLEGAR re spuesta-in ventario-fsico
OTRO
REPITE HASTA que y a no haya d etalles-pe dido en cuenta-inventario
ENCONTRAR a rtcu lo -in ven ta rio en ARTICULOSINVENTARIO que corresponda con
identificacin-bodega y clave-ibro
re spuesta-in ventario-fsico = clave de libro invlida
DESPLEGAR re spuesta-in ventario-fsico
OTRO
variacin = cantidad-inventario - cuenta-fsica
HACER cantidad -in ventario ig u a l a cuenta-sica
RESTAR variacin de total-en-existencia
MIENTRAS haya ms pedido en PEDIDOS con
fecha-pedido posterior a a-fecha y que corresponda
con identificaci n-bodega
MIENTRAS haya ms artcu lo-ped ido en
ARTICULOS-PEDIDOS con cla ve-libro =
clave -libro en d etalles-pe dido y nm erofactura = nm ero-factura en pedido
LEER a rtculo-pedido
RESTAR cantidad-pedida de cantidad-inventario
RESTAR cantidad-pedida de total-en-existencia
FiNJVIiENTRAS
FINJVIIENTRAS
ESCRIBIR registro de a rtcu lo-in ve n tario
ESCRIBIR registro de libro
FINJ3I
FIN^REPITE
Fl N Si
TERMINA
PROCESO 7.5: R E G IS T R A R E N V IO R E A L
COMIENZA
ENCONTRAR pedido en PEDIDOS que corresponda con nm ero-factura
SI no s e encuentra registro
respuesta-envo = No se puede encontrar tai pedido
DESPLEGAR respuesta-envo
www.FreeLibros.org
690
OTRO
FIJAR fecha-envo a fecha actual
ESCRIBIR registro de pedido
FIN_SI
TERMINA
PROCESO 7.6: RESPONDER A NO EN EXISTENCIAS
COMIENZA
ENCONTRAR lib ro en LIBROS que corresponda con ttulo-libro
respuesta-no-en-existencia = No existe tal libro
DESPLEGAR respuesta-no-en-existencia
OTRO
LEER registro de libro para recuperar ciave-libro
ENCONTRAR a rtcu lo -in ve n ta rio en ARTICULOS-INVENTARIO
que corresponda con identificaci n-bodega y con clave-fibro
SI no se encuentra el registro
respuesta-no-en-existencia = Error: no se puede
encontrar artculo del inventario
OTRO
LEER a rtcu lo -in ven ta rio
HACER cantida d -in ve n ta rio igual a cero
ESCRIBIR a rtculo -in ven ta rio
respuesta-no-en-existencia = Mensaje de no en existencia aceptado"
FIN_SI
Fl N__SI
TERMINA
PROCESO 8.1: PRODUCIR INFORME DE REGALIAS DE AUTOR
COMIENZA
MIENTRAS haya ms lib ro en LIBROS
total-libros = 0
total-ventas = 0
total-regalas = 0
LEER siguiente registro de lib ro
MIENTRAS haya ms pedido en PEDIDOS que corresponda con
fecha-pedido de este trimestre
MIENTRAS haya ms artculo-pedido en ARTICULOS-PEDIDOS con
nm ero-factura que corresponda con nm ero-factura en registro de
pedido actual y clave-lib ro que corresponda con clave-libro en registro
de lib ro actual
LEER siguiente a rtculo-pedido
SUMAR cantidad-pedida a total-libros
www.FreeLibros.org
esta-venta = cantidad-pedida * p re cio -u n ita rio * descuento

SUMAR esta-venta a total-ventas
SUMAR (esta-venta * tasa-regalas) a total-regalas
FINJMIENTRAS
FIN_MIENTRAS
MIENTRAS haya ms crdito en CREDITOS con cla ve-libro que corresponda
con clave-libro en registro libro actual y con fecha-crdito en este trimestre
LEER siguiente crdito
RESTAR cantidad -lib ro s-a -crd ito de totai-libros
RESTAR m onto-de-crdito de total-ventas
RESTAR (m onto-de-crdito * tasa-regaias) de total-regalas
FINJVl ENTRAS
MIENTRAS haya ms devolucin en DEVOLUCIONES con clavelib ro que corresponda con clave-libro en registro de
lib ro actual y fecha de devolucin en este trimestre
LEER siguiente d evolucin
RESTAR cantidad-devuelta de total-libros
RESTAR valor-devoiu cin de total-ventas
RESTAR (valor-devolucin * tasa-regalas) de total- regalas
FINjMIENTRAS
AADIR total-libros,total-ventas,total-regalas al
siguiente rengln de inform e-regaias-autor
FINJMIENTRAS
DESPLEGAR inform e-regalas-autor
TERMINA
PROCESO 8.2: AVISAR A CONTABILIDAD SOBRE ADELANTO DE REGALIAS
COMIENZA
ENCONTRAR autor en AUTORES con Ide ntifica ci n-autor que
corresponda con ide n tifica ci n -a u to r en s o iicitu d adelanto-regalas
respuesta-adelanto = No existe tal autor
DESPLEGAR respuesta-adelanto
OTRO
ENCONTRAR lib ro en LIBROS con cla ve -lib ro que
corresponda con clave-libro en solicitud-adelanto-regalas
respuesta-adelanto = No existe tal libro
OTRO
solicitud-auto rizacin-adelanto = solicitud-adeianto-regalas
DESPLEGAR (para administracin) so licitud-auto rizacin-adelanto
ACEPTAR (de la administracin) respuesta-autorizacin-adelanto
www.FreeLibros.org
692
C A SO DE ESTUDIO: YOURDON PRESS
SI respuesta-adelanto = Si
respuesta-adelanto = Adelanto aprobado
sollctud-cheq ue-adelanto = solicitud-adelanto-regalas
DESPLEGAR (para contabilidad) solicitud-cheque-adelanto
LEER registro de autor
SUMAR adelanto a saldo-regalas
ESCRIBIR registro de autor
OTRO
respuesta-adelanto = Adelanto negado
FIN SI
FIN__SI
FIN SI
TERMINA
PROCESO 8.3: C A M B IA R D E T A L L E S A U T O R
COMIENZA
ENCONTRAR autor en AUTORES con id e n tifica ci n -a u to r correspondiente
SI se encuentra registro
ESCRIBIR detalles-autor en autor
FIN SI
TERMINA
www.FreeLibros.org
APENDICE
G.1
IN T R O D U C C IO N
E s te apndice muestra ei modelo esencial para el controlador de un eleva

dor, Su propsito principal es usar los modelos del anlisis estructurado para siste
mas de tiempo real; se vern ejemplos de flujos de control, procesos de control y
diagramas de entidad-relacin que normalmente no se usaran en un sistema orien
tado a los negocios.
En la siguiente seccin se da una descripcin narrativa del problema. Ense
guida hay varios diagramas que conforman el modelo esencial, adems del dicciona
rio de datos y las especificaciones del proceso. Observe que la mayora de las
especificaciones de proceso usan el enfoque de precondicin/postcondicin que se
discute en el captulo 11.
El problema del elevador se us en un curso patrocinado por la seccin Was
hington, D.G., de la ACM en 1986. Los modelos que se proporcionan aqu original
mente los desarroll Dennis Stipe, ex-empleado de YOURDON, inc. Los diagramas
de flujo de datos y el diccionario de datos se hicieron con ayuda de una computado
ra Macintosh II con el software MacBubbles de StarSys, Inc.; los diagramas de tran
sicin de estados se hicieron con MacDraw.
Es importante que vea lo mucho que difieren los diagramas de este captulo de
los diagramas dei Apndice F, que se produjo con Design de Meta Software. Mac
Bubbles es un producto CASE especficamente hecho para el dibujo de diagramas
de flujo de datos (con capacidad de balancear diagramas padres e hijos, etc.). De
sign es un programa de dibujo de propsito ms general, orientado a objetos, que se
www.FreeLibros.org
693
694
C A SO DE E STU D IO :
puede usar para dibujar diagramas de flujo, diagramas de flujo de datos, o casi cual
quier otro diagrama de software. Desde un punto de vista esttico, los diagramas
que producen ambos son muy distintos; creo que los editores que produjeron este li
bro hubieran preferido un artista humano confiable a cualquiera de estos paquetes.
Como se mencion en el captulo 9, el estilo y formato de los diagramas de flujo de
datos puede ser una cuestin controvertida y delicada con muchos usuarios; cuando
compare los apndices F y G, ver por qu.
G .2
U N A D E S C R IP C IO N N A R R A T IV A
El requerimiento general es disear e implantar un programa para controlar y

programar el itinerario de cuatro elevadores en un edificio de 40 pisos. Los elevado
res se usarn para transportar personas de un piso a otro en forma convencional.
Eficiencia: El programa debe dar el itinerario de los elevadores de una mane
ra eficiente y razonable. Por ejemplo, si alguien llama a un elevador oprimiendo el
botn de bajar" en el cuarto piso, ei siguiente elevador que pase por el cuarto piso y
que vaya hacia abajo debe parar all para aceptar ai o los pasajeros. Por otro lado,
si un elevador no tiene pasajeros (es decir, no existen solicitudes de destino pen
dientes), debe estacionarse en el ltimo piso al que lleg, hasta que se vuelva a ocu
par. Un elevador no debe invertir su direccin de viaje hasta que hayan llegado a su
destino los pasajeros que desean viajar en la direccin en ese momento. (Como se
ver a continuacin, el programa en realidad no puede obtener informacin acerca
de los pasajeros de un elevador dado; sio se entera de que se oprimieron los boto
nes de destino para cada elevador. Por ejemplo, si algn pasajero travieso o psic
pata aborda el elevador en el primer piso y luego oprime los botones del cuarto,
quinto y vigsimo pisos, el programa har que el elevador viaje hasta stos y se de
tenga en cada uno de ellos. La computadora y su programa no tienen informacin
respecto a la entrada y salida de pasajeros de un elevador. Un elevador que est
lleno hasta su mxima capacidad no debe de responder a un nuevo llamado. (Existe
un sensor de peso para cada elevador. La computadora y su programa los pueden
interrogar).
Botn de destino: El interior de cada elevador tiene un tablero con 40 boto
nes, uno para cada piso, etiquetados con ios nmeros de los pisos (1 a 40). Estos
botones de destino se iluminan mediante seales enviadas a! tablero por la compu
tadora. Cuando un pasajero oprime un botn de destino que an no est iluminado,
los circuitos del tablero mandan una interrupcin a la computadora (hay una interrup
cin diferente para cada elevador). Cuando la computadora recibe una de estas in
terrupciones (vectoriales), su programa puede leer los registros de entrada de 8 bits
de memoria asignada apropiados (hay uno para cada interrupcin y, por tanto, uno
para cada elevador) que contiene ei nmero del piso correspondiente al botn de
destino que ocasion la interrupcin. Desde luego, los circuitos del tablero escriben
el nmero de piso indicado en el registro de entrada de 8 bits indicado que ocasiona
la interrupcin vectorial. (Como en esta aplicacin hay 40 pisos, slo se usarn los
www.FreeLibros.org
CASO DE ESTUDIO: 695
primeros 6 bits de cada registro de entrada para la implantacin; pero el hardware

podra servir para un edificio de hasta 256 pisos.)
Luces de botones de destino: Como se mencion antes, los botones de desti
no se pueden iluminar (por medio de focos atrs dei tablero). Cuando la rutina de in
terrupcin de servicio del programa recibe la interrupcin de un botn de destino,
debe mandar una seal al tablero indicado para que se ilumine el botn indicado.
Esta seal la enva el programa que carga el nmero del botn en el registro de sali
da apropiado (cada elevador tiene uno de estos registros). La iluminacin de un bo
tn indica al pasajero que el sistema ha tomado nota de su solicitud, y tambin evita
ms interrupciones debidas a que nuevamente se oprima (impacientemente?) el
botn. Cuando el controlador detiene el elevador en un piso, debe enviar una seal
a su tablero de destino para apagar el botn de destino de dicho piso.
Sensores de piso: Hay un interruptor de sensor de piso en cada piso para ca
da tiro de elevador. Cuando un elevador se acerca a 8 pulgadas de un piso, un en
grane cierra el interruptor y manda una interrupcin a la computadora (existe una
interrupcin diferente para cada juego de interruptores de cada tiro). Cuando la
computadora recibe una de estas interrupciones (vectoriales), su programa puede
leer el registro apropiado (existe uno para cada interrupcin, y por tanto uno para ca
da elevador) que contiene el nmero de piso correspondiente al sensor que caus la
interrupcin.
Luces de llegada: El interior de cada elevador tiene un tablero que contiene
un indicador iluminable para cada nmero de piso. Se localiza arriba de las puertas.
Su propsito es informar a los pasajeros el nmero del piso al que est Negando (y
en el cual es posible que se vaya a parar). El programa debe iluminar el indicador
de un piso cuando llega a l y apagarlo cuando lo deja o llega a otro. Esta seal ia
enva cargando el nmero del indicador de piso en el registro de salida apropiado
(hay uno para cada elevador).
Botn de llamada: En cada piso hay un tablero con boton(es) de llamada. A
excepcin de la planta baja (piso 1) y ei piso ms aito (piso 40) un piso tiene dos bo
tones, uno de SUBIR y uno de BAJAR. En la planta baja slo existe el de SUBIR, y
en la ms alta slo existe el de BAJAR. Por ello, en total hay 78 botones de llama
da: 39 de subida y 39 de bajada. Los pasajeros los pueden oprimir para llamar a un
elevador. (Desde luego, no pueden llamar a uno en particular. El programador de iti
nerario decide cul debe responder al llamado). Estos botones de llamada se pue
den ilum inar con seales enviadas de la com putadora al tablero. Cuando un
pasajero oprime un botn que an no est iluminado, los circuitos dei tablero envan
una interrupcin vectorial a la computadora (hay una interrupcin para botones de
BAJAR y otra para SUBIR). Cuando ia computadora recibe una de estas dos, su
programa lee el registro apropiado, que contiene el nmero de piso correspondiente
al botn de llamada que caus la interrupcin. Desde luego, los circuitos del tablero
escriben el nmero del piso en el registro apropiado cuando se causa la interrupcin
vectorial.
www.FreeLibros.org
696
Luces de los botones de llamada: Los botones de llamada se pueden iluminar

(por medio de focos detrs de los tableros). Cuando la rutina de interrupcin de ser
vicio por botn de llamada en el programa recibe una Interrupcin vectorial de SU
BIR o BAJAR, debe mandar una seal al tablero apropiado para iluminar el botn en
cuestin. El programa enva esta seal cargando el nmero del botn en el registro
apropiado, uno para los botones de SUBIR y otro para los de BAJAR. La iluminacin
de un botn informa al o los pasajeros que el sistema ha tomado nota de su solicitud
y tambin evita ms interrupciones causadas por oprimir repetidamente el botn.
Cuando el controlador detiene al elevador en un piso dado, manda una seal al ta
blero de botones de llamada de dicho piso para que se apague el botn en cuestin
(SUBIR o BAJAR).
Controles del motor del elevador (Arriba, Abajo, Parar): Existe una palabra de
control para cada motor. El bit 0 de esta palabra obliga ai elevador a subir, el bit 1 a
bajar, y el bit 2 a detenerse en ei piso cuyo interruptor sensor est cerrado. El me
canismo del elevador no obedecer a ninguna orden inapropiada o peligrosa. Si nin
gn interruptor sensor de piso est cerrado, el mecanismo ignora la seal de
detenerse hasta que alguno se cierre. El programa no tiene que preocuparse por
controlar las puertas de algn elevador, o de detenerlo exactamente en cierta posi
cin (home) respecto a un piso dado. El fabricante de los elevadores usa interrup
tores, relevadores, circuitos y seguros convencionales para dicho propsito, para
verificar su seguridad sin hacer caso de la computadora controladora. Por ejemplo,
si la computadora da una orden de detenerse a un elevador cuando ste est a 8
pulgadas de un piso (de manera que su interruptor de sensor de piso est cerrado),
el mecanismo convencional aprobado detiene y acomoda al elevador en dicho piso,
abre y mantiene sus puertas abiertas de manera apropiada y luego las cierra. Si la
computadora da alguna orden durante este perodo (por ejemplo, cuando la puerta
est abierta), el mecanismo del fabricante la ignora hasta que se cumplan las condi
ciones para el movimiento. (Por eso no es peligroso que la computadora d la orden
de subir o bajar cuando todava estn abiertas las puertas.) Una condicin para el
movimiento de un elevador es que su botn de detenerse no est oprimido. Cada
tablero de destino de un elevador contiene un botn de stos. No est vinculado
con la computadora. Su nico propsito es detener el elevador en algn piso, con la
puerta abierta, mientras est estacionado all. El interruptor rojo de emergencia de
tiene al elevador en el siguiente piso que pase sin considerar el itinerario de la com
putadora. Este interruptor puede tambin encender una alarma audible, y tampoco
tiene conexin con la computadora.
Mquina-destino: Todo esto se puede implantar en cualquier microcomputadora contempornea capaz de manejar esta aplicacin.
www.FreeLibros.org
C A S O DE E S T U D IO : 697
EL MODELO ESENCIAL
Modelo esencial de un elevador
www.FreeLibros.org
698
Diagrama de contexto expandido
www.FreeLibros.org
C A SO DE E ST U D IO : 699
La Lista de Acontecimientos
Un pasajero hace solicitud de llamada de subida.
Un pasajero hace solicitud de llamada de bajada.
El elevador llega al piso donde se le llam.
El elevador no est disponible para la solicitud dellamada.
El elevador llega a estar dosponible para la solicitud dellamada.
Un pasajero hace una solicitud de destino.
El elevador llega al destino solicitado.
El elevador llega a un piso.
El elevador deja dicho piso.
El elevador no se mueve (se descompone).
El elevador entra en servicio nuevamente.
El elevador se sobrecarga.
Se normaliza la carga del elevador.
www.FreeLibros.org
700
Figura 0: Programar itinerario y controlar al elevador

Modelo esencial dei elevador
www.FreeLibros.org
C A S O DE E STU D IO :
Figura 1: Almacenar y desplegar solicitud
www.FreeLibros.org
702
C A SO DE E ST U D IO :
Figura 1.1: Adm inistrar solicitud de llamada
www.FreeLibros.org
C A S O DE E STU D IO : 703
Habilitar Almacenar Solicitud de Llamada

Habilitar Desplegar Solicitud de Llamada
Llamada no usada
i
Solicitud de Llamada Ingresada
Piso Alcanzado
Seal de Solicitud de Llamada

Recibida
inicia Eliminar Llamadas

Cumplidas
Figura 1.1.1: Controlar solicitud de llamada
Habilitar Almacenar Solicitud de Llamada

H a b ilita r Desplegar Solicitud de Llamada
ir
Destino no usado
ii
Solicitud de Llamada Ingresada
Piso A lc a n z a d o
Seal de Solicitud de Llamada

Recibida
Inicia Eliminar Llamadas

Cumplidas
www.FreeLibros.org
Figura 1.2.1: Controlar solicitud de destino
Figura 1.2: Adm inistrar solicitud de destino
www.FreeLibros.org
Figura 2: Controlar el elevador
www.FreeLibros.org
706
CASO DE ESTUDIO:
Figura 2.1: Adm inistrar destino del elevador
www.FreeLibros.org
Destino no usado
t
Destinos Pendientes Recibidos

Habilita Determinar Direccin
Requerida
Habilita Administrar Llegada a
Piso
Habilita Determinar Destino Final
Destino Final Alcanzado

Deshabilita Determinar Direccin
requerida
Seal Clasificacin Destino
Completada
Deshabilita Administrar Llegada
a Piso
Deshabilita Determinar Destino
Final
i
Destinos Pendientes
Figura 2.1.1: Controlar destino
www.FreeLibros.org
CASO DE ESTUDIO:
>y
'X
* - - - . . Piso-a/c
p is o ^d e s e s tfo
va
'%
\\
|/
a
p
*
Q.
''? > , \%
1/
<n
?>Zv'
$>>
<'
v^5
e\evtL
' - ? V f' '
v,aiaf e
'e v a -C
V
2.2.1
'S ^ c0n V ' - - ' ' '
M
ove
a/? a ^ a d o
"*
over y - - " '
e le
ie vVa
ado
0r s
- * "''L h a s ta un
,0 ^ -* *
.^
V
iso a T^
**
V pP,sc>
v- V
V
\% '<V
s.^'-o
^\^-< \
V
/-\ i - - '
p ro g ra m a c i n -d e s tin o s
te
S itu a c i n d el
e le v a d o r
Figura 2.2: Adm inistrar llegada a piso
www.FreeLibros.org
Prepara control de subida

Prepara control de bajada
Fija control de alto
Habilita vigilancia de llegada a piso
Fija estacionar
Habilita almacenar status
ESTACIONADO
DESTINO-SUBIR
Prepara control de alto
Fija control de subida
Habilita vigilancia de
PROGRAMA
CION DESTINO
COMPLETADO
DESTINO-BAJAR
Fija estacionar
movimiento
tf

Prepara estacionar
Fija control de bajada
Habilita vigilancia de movimiento
BAJANDO
SUBIENDO
4 NO EW PISO
DESEADO
EN PISO
alcanzado
Inicia determinar
piso deseado
DESTINO SUBIR
PISO DESTINO
ALCANZADO

Fija control de subida
movimiento
Prepara bajar
Fija control de ato
PISO DESTINO
ALCANZADO
Fija alto
Deshabiiita
vigilancia de
movimiento
DESEADO
Sealar piso
Sealar piso
alcanzado
Inicia determinar
piso deseado
Prepara subir
i NO EN PISO
EN PISO
DESTINO BAJAR
Fija control de bajada
movimiento
Deshabilita
vigilancia de
movimiento
DETENIDO
MOVIMIENTO TIEMPO
TERMINADO
Sealar no en servicio
Sealar reprogramacin
EN PISO
Sealar
nuevamente en
servicio
SUBIR NO EN SERVICIO
EN PISO
Sealar
nuevamente en
servicio
MOVIMIENTO TIEMPO
TERMINADO
Sealar no en servicio
Sealar reprogramacin
BAJAR NO EN SERVICIO
Figura 2.2.1: Mover elevador hasta piso
www.FreeLibros.org
710
CASO DE ESTUDIO:
'
Figura 3: Programar itinerario
www.FreeLibros.org
S o lic itu d e s -
Figura 3.1: Adm inistrar programacin de llamadas
www.FreeLibros.org
712
CASO DE ESTUDIO:
Figura 3.1.2: Controlar programacin de llamadas
www.FreeLibros.org
xo.
e le v a d o r
Figura 3.2: Adm inistrar programacin de destinos
www.FreeLibros.org
714
CASO DE ESTUDIO:
V
No usado
A
n
PEDIDO-DESTINORECIBIDO
Inicia programar solicitud
de destino
Sealar programacin de
destinos pendiente
PISO ALCANZADO
Inicia actualizar programacin
de destinos
Figura 3.2.1: Controlar programacin de destinos
www.FreeLibros.org
DICCIONARIO DE DATOS
para
Sistem a de C o ntrol del Elevador
Pgina 1
apagado
NOTAS: "'E n tra d a Generada****

bajando
c o n tro l-a lto

NOTAS: seal para hardware
co n tro l-b a ja r
NOTAS: seal para el hardware

c o n tro l-s u b ir
NOTAS: '"E n tra d a Generada**"

d e stin o -b a ja r
NOTAS: seala que la direccin requerida es hacia abajo

d e s tin o -d ire cci n
NOTAS: [d e stino -su b ir

d e s tin o -b a ja r]
de stin o -p e n d ie n te = valores: [encendldolapagado]
NOTAS: indicacin de que un elevador tiene destinos subsecuentes

al piso actual
d e stin o s-p e n d ie n te s = [llamadas-pendientesldestino-
pendientelllamadas-pendientes + destinos-pendientes]
NOTAS:seala que existe una program acin de destinos
d e s tin o -s u b ir
NOTAS: "'E n tra d a G enerada***

de tenido

d ire cci n -b a ja r
NOTAS: "'E n tra d a G enerada****

d ire c c i n -s u b ir
NO TAS: '"E n tra d a G enerada*
eleva dor-n m e ro = valores: 1-4

eleva dor-se le ccion ad o
NOTAS: seala que se ha programado un elevador para una

solicitud de llamada
www.FreeLibros.org
e n cendido
NO TAS: '" E n t r a d a G e n e ra d a "*
en-piso
716
CASO DE ESTUDIO:
para
Sistema de C o n tro l del Elevador
Pgina 2
NOTAS: seala que el elevador ha llegado a cierto piso

estacionado
NOTAS: seal
estado = [estacionadolsubiendolbajandoldetenidolno-erv-servicio]
in d ica ci n -d e stin o = valores: 1-40
NOTAS: indicacin de nmeros de pisos en los que est

programado que un elevador se detenga
in d ica ci n -lla m a d a s = valores: 1-40
NOTAS: indicacin de nm eros de piso donde est programado

que se detenga un elevador
in d ica ci n -lle g a d a = valores: 1-40
NOTAS: indicacin de piso al que ha llegado

llam adas
NOTAS: '" E n tr a d a G en e ra da ""
llam adas-pendientes = valores: encendidolapagado]

n o -d isp o n ib le
NOTAS: seala que un elevador no est d isp o n ib le para satisfacer

una solicitud de llamada
n o -en -servicio
NOTAS: seala que un elevador no ha logrado responder a una

orden de m ovim iento
o rig e n -s o lic itu d = [llamadalpiso-destinolllamada + piso-destino]
pedido-destino-dado
NOTAS: seala que el pasajero ha ingresado una peticin de
destino
p e d id o -d e stin o -re cib id o
NOTAS: seala que ia peticin est lista para programarse

piso -actual = valores: 1-40
NOTAS: nm ero de piso donde actualmente se encuentra un
elevador
piso-deseado-aicanzado
NOTAS: seal
www.FreeLibros.org
p iso -d e s tin o = valores: 1-40
CASO CE ESTUDIO: 717
Pgina 3
para
Sistema de Control del Elevador
NOTAS: nmeros de pisos donde est programado que un
elevador se detenga
piso-elevador = valores: 1-40
p is o -n m e ro
= valores: 1-40
NOTAS: " E n tra d a Generada****

programacin-destino = @elevador-nm ero + {piso - destino} + o rige n -so licitu d +
destino-pendiente
program acin-destinos = {pro g ram a ci n -d e stin o } reprogramacin
NOTAS: seal de iniciar reprogram acin de llamadas a signadas a
elevador fu e ra de servicio
seal-control = control-subir + control-bajar + control - alto

sobrecarga
NOTAS: seal del hardware
solicitud = solicitudes-llamada + solicitudes-destino
solicitud-destino = @nmero-elevador + {nmero-piso}
solicitudes-destino = {so licitu d -d e stin o }
solicitud-llam ada = piso-elevador + [direccin-subirl direccin-bajarldireccin-subir +
direccin-bajar] + e levador-nm ero
solicitud-llamada-dada
NOTAS: seal
soiicitud-ilam ada-recibida
NOTAS: seal
solicitudes-llam adas = {solicitu d -lla m a d a}
solicitud-recibida = solicitud-llamada-recibida + pedido- destino-recibido
status = elevador-nmero + estado + piso-actual
statuses = {status}
subiendo
NOTAS: "Entrada Generada****
valores
NO TAS: " 'E n tr a d a G e n e ra d a "*
www.FreeLibros.org
718
E specificaciones de Proceso
1.1.2 ALMACENAR SOLICITUD DE LLAMADA
Precondicin
ocurre in greso-solicitud -ilam ada
Postcondicin
se almacena in greso-solicitud -llam ada
se produce ing reso-solicitud -llam ada
1.1.3 ELIMINAR LLAMADA COMPLETADA
Precondicin
Existe un elevador-nm ero en statuses que corresponde con
elevador-nm ero-asignado en so licitud-llam ada
y
Existe un piso-actual en statuses que corresponde con piso-nm ero

en solicitudes-llam ad a
Postcondicin
La entrada correspondiente en solicitud-llam ada es nula
1.1.4 DESPLEGAR SOLICITUD LLAMADA
Precondicin
Ninguna
Postcondicin
Se despliegan solicitudes-llam ad a
1.2.3 ELIMINAR DESTINOS COMPLETADOS
Precondicin
elevador-nm ero en so licitu d e s-d e stin o
y
Existe un piso-actual en statuses que corresponde con piso-actual

en so licitu d e s-d e stin o
Postcondicin
La entrada correspondiente en so licitu d e s-d e stin o es nula
1.2.4 DESPLEGAR SOLICITUD-DESTINO
Precondicin
Ninguna
Postcondicin
Se despliegan so licitu d e s-d e stin o
2.1.2
DETERMINAR DESTINO FINAL

Precondicin
elevador-nm ero en program acin-destinos
www.FreeLibros.org
Existe un piso-actual en statuses que corresponde con piso-destino

y program acin -destinos
y
el correspondiente destino-pe ndiente = apagado en program acindestinos

Postcondicin
Se produce d estino-final-alcanzado
2.1.3
DETERMINAR DIRECCION REQUERIDA

El trmino local correspond encia es un elevador-nm ero que corresponde
con program acin-destinos y elevador-nm ero en status
Precondicin 1
Existe correspondencia
y
Existe en program acin-destinos un piso-destino > piso-actual

en status
Postcondicin 1
Se produce d e stino -su b ir
Precondicin 2
Existe correspondencia
y
Existe en program acin -destinos un piso-destino < piso-actual

en sta tus
Postcondicin 2
Se produce d estino-bajar
2.2.2 VIGILAR LLEGADA A PISO
Precondicin 1
Ocurre piso
Postcondicin 1
Se elimina indicacin-llegada en piso anterior
y
se produce indicacin-llegada para piso correspondiente

y
se produce en-piso
y
se actualiza piso-actual en statuses

2.2.3 VIGILAR MOVIMIENTO DE ELEVADOR
Se lee piso-actual de statuses
Precondicin
Transcurren 10 segundos y piso-actuai no cambia
Postcondicin
Ocurre m ovim iento-tem po-term inado
www.FreeLibros.org
720
CASO DE ESTUDIO:
2.2.4 ALMACENAR STATUS

Precondicin
Se recibe seal de entrada
Postcondicin
Se actualiza estado en status
2.2.5 DETERMINAR PISO DESEADO
Precondicin
elevador-nm ero en statuses-destino
y
Existe un piso-actual correspondiente en statuses que corresponde

con piso -d estin o en program acin -destinos
Postcondicin
Se produce piso-deseado-aicanzado
3.1.1
PROGRAMAR LLAMADAS
COMIENZA
con solicitud-llam ada , status, y sobrecarga
MIENTRAS elevador-seleccionado no se haya sealado
Encontrar elevador ms cercano
Si elevador se est moviendo en la d ire ccin correcta o elevador
est estacionado
SI elevador no est sobrecargado
ingresar solicitu d -lla m a da por medio de elevador-nm ero
en cla stflca cl n-de stino
hacer o rig e n -so licitu d igual a llamada o llamada +
destino
FIN_SI
SI destino-pendiente = apagado
hacer destino-pendiente = encendido
FIN Si
sealar elevador-seleccionado
OTRO
encontrar elevador ms cercano
FIN__MIENTRAS
SI no se encuentra elevador
Sealar elevador no disponible
FIN_SI
TERMINA
3.1.3 ELIMINAR DESTINOS LLAMADOS

Precondicin
elevador-nm ero en program acin-destinos
www.FreeLibros.org
el c o rre s p o n d ie n te estado = n o-en-servicio en statuses

y
el correspondiente o rig e n -s o lic itu d = llamada en
program acin-destinos
P o s tc o n d ic i n
Las entradas correspondientes en p iso -d estin o son nulas

3.2.2 PROGRAMAR SOLICITUD-DESTINO
Precondicin
Ninguna
Postcondicin
program acin-destinos se actualiza con so licitu d e s-d e stin o que
corresponden con elevador-num ero
Hacer o rig e n -so licitu d = d estino o llam ada + destino
Si destino-pendiente = apagado
hacer destino-pe ndiente = apagado
FINSI
3.2.3 ACTUALIZAR PROGRAMACION DESTINOS
Precondicin 1
elevador-nm ero en program acin destinos
y
Existe un piso-actuai en statuses que corresponde con piso-destino

en program acin -destinos
Postcondicin 1
La correspondiente entrada en p iso-de stino es nula
Precondicin 2
misma c o n d ic i n que precondicin 1
y
no existe entrada correspondiente en piso-destino

Postcondicin 2
La entrada correspondiente en p iso -d estino es nula
y
se hace destino-pendiente = apagado
www.FreeLibros.org
I n d ic e
Acciones, estados, 294-95

ADABAS, sistema de administracin de bases de
datos, 221-22, 261-62
Administracin
interaccin entre el analista de sistemas y,
56-58
niveles de, 56-57
puntos ciave acerca de, 57-60
relacin entre proyectos de desarrollo de
sistemas y, 58-60
Administracin del proyecto, 527-28
automatizacin de, 349-51
comparadas con otras herramientas de
modelado de sistemas, 345-50
diagramas de GANTT, 344-46
diagramas PERT, 342-45
herramientas de modelado, 340-51
necesidad de modelos para la administracin,
341-43
pizarrones del equipo dei proyecto, 529-32
Agujeros negros, diagramas de flujo de datos
(DFD). 182-83
Alias, diccionario de datos, 219-20
Almacenado de datos a largo plazo, 433-44
Almacenes
almacn de implantacin, 169-72
almacenes de nicamente lectura, 183-86
almacenes de nicamente escritura, 83-86
almacenes esenciales, 402-4
asignacin de, 455
definicin de. 168-70
eleccin de nombres para, 177-80
flujo hacia, 173-75
interpretacin del flujo desde, 172-73
propsito de, 169-70
Almacenes de control, 75-77, 193-95
Almacenes de datos
asignacin de, 455
vase tambin Almacenes
Almacenes externos
comunicacin mediante, 381-82
modelo de entidad-relacin de, 378-79
Ambiente, sistemas en tiempo real, 28-29
Anlisis de beneficios, 557-62
beneficios estratgicos del nuevo sistema,
560-62
beneficios tcticos, 558-61
Anlisis de costos, 550-58
costo del dinero, 554-55
costo del fracaso, 556-58
costos de construccin de sistemas, 551-53
costos de instalacin de sistemas, 552-55
costos operativos, 554-57
distincin entre costos de capital y gasto,
557-58
expresin de costos y beneficios, 562-66
anlisis de riesgos, 565-67
flujo de efectivo, 562-63
rendimiento de una inversin, 563-64
lasa interna de rendimiento, 564-66
valor presente neto, 563-65
Anlisis de riesgos, 565-67
Anlisis de sistemas
estaciones de trabajo, 517-18
programacin, prueba y, 471 -74
roles de, 63-65
Anlisis estructurado, 136-48, 514-15
aplicaciones atrasadas, 118-26
auditoras, 484-85, 568-74
auditoras de anlisis, 569-74
clculos de costo/beneficio, 549-67
cambios en el anlisis estructurado clsico,
140-42
cambios pasados en, 500-3
caso de estudio de Yourdon Press, 588-685
ciclo de vida estructurado dei proyecto,
98-105
ciclo de vida dei proyecto, 86-116
www.FreeLibros.org
723
724 INDICE
ciclo de vida de prototipo, 87, 108-12

desarrollo de sistem as, 45-71, 117-35
diagram as de contexto, 374-75, 379-87
diagram as de entidad-relacin, 77-79, 142
221, 260-87, 361
diagram as de flujo de datos (DFD), 75-78,
157-210, 221, 361
diagram as de transicin de estados (DTE),
27, 80, 82, 142,195, 221, 288-304, 361
diccionario de datos (DD), 76, 211-26, 361
diseo de form as, 437-40
diseo de sistem as, 452-69
entrevistas, 575-87
especificaciones de proceso, 77-78, 221,
227-59, 361
flujos, 162-67
futuro, 500-12
hardw are, 509-10
impacto de los desastres de m antenim iento,
505-7
m atrim onio de la IA y el anlisis
estructurado, 507-8
m ayor conciencia dei anfisis de sistem as,
502-4
proliferacin de herram ientas
autom atizadas, 504-5
herram ientas autom atizadas, 142-44,
herram ientas de m odelado, 74-75, 149-56
interfaz hum ana, 427-42
impacto sobre la estructura de la
organizacin, 472-74
lista de acontecim ientos, 375-78,
386-91, 596-99, 699
m antenim iento de especificaciones, 492-512
modelado, 26, 73-85, 141
modelo am biental, 360, 373-91
modelo de im plantacin dei usuario, 27, 68,
328, 356, 419-51
modelo del com portam iento, 361, 395-418
modelo esencial, 352, 357-67, 419-21
m ovim iento hacia, 138-41
program acin, 470-80
prototipo, uso de, 144-46
prueba, 91-93, 472-74, 480-85
reglas de autom atizacin, 534-48
sistem as autom atizados, 17-37
surgim iento de herram ientas autom atizadas
de anlisis, 141-45
usuarios, 46-57
vase tam bin tpicos especficos

Aplicaciones atrasadas, 1 i 8-26
reduccin de, 119-25
retraso desconocido, 119-20
retrasos invisibles, 118-19
retraso visible, 118-19
Apoyo grfico, herram ientas autom atizadas,
518-2!
A uditores, 59-64
objetivo de, 61
problem as que surgen de trabajar con, 62-64
Auditoras, 484, 568-74
cundo llevar a cabo, 570-72
definicin de, 568-70
papeles en. 571-73
procedim ientos, 572-74
razn para llevar a cabo, 569-7 i
tipos de, 569-70
Auditoras de anlisis, 569-74
cundo hacerlas, 570-72
razones para hacerlas, 569-71
roles en, 571-73
Autom atizacin
como asunto de la adm inistracin del
proyecto, 349-51
de sistem as de proceso de inform acin, 17-18
Balanceo
de m odelos, 305-18
DD versus DFD y especificaciones de
procesos, 310-12
DER versus DFD y especificaciones de
proceso, 311-13
DFD versus DD, 308-9
DFD versus DTE, 313-14
DFD versus especificaciones de proceso,
308-10
especificaciones de proceso versus DFD y
DD, 309-11
C lculos de coso/beneficio, 549-67

anlisis de beneficios, 557-62
beneficios estratgicos de un nuevo
sistem a, 560-62
beneficios tcticos, 558-61
Cam bios de estado, 26, 80
www.FreeLibros.org
INDICE: 725
C aractersticas de correccin de errores,

herram ientas autom atizadas, 521
CASE (siglas en ingls de ingeniera de software
auxiliada por com putadora), 144
Caso de estudio de Yourdon Press,
antecedentes, 588-95
diagram a de entidad-relacin, 662
diccionario de datos (DD ), 647-62
escala de operacin, 595
especificaciones de proceso, 663-92
estructura organizacional de Yourdon Inc.,
592-94
grupos principales, 593
m odelo am biental, 595-98
declaracin de propsitos, 595
diagram a de contexto, 596
lista de acontecim ientos, 596-98
m odelo final del com portam iento, 637-46
diagram as de flujo de datos (DFD), 638-46
m odelo prelim inar dei com portam iento,
598-692
diagram as de flujo de datos (DFD),
599-636
Ciclo de vida clsico del proyecto, 89-90
im plantacin ascendente, 91-93
ciclo de vida de cascada, 91-93
correccin de errores, 91
prueba, 91 -93
progresin secuencial, 92-94
Ciclo de vida de cascada, 91-93
Ciclo de vida del proyecto, 86-116
ciclo de vida clsico del proyecto, 89-91
im plantacin ascendente, 91 -93
progresin secuencial, 92-94
cicio de vida de prototipo, 87, 108-12
ciclo de vida estructurado de! proyecto,
98-105
ciclo de vida sem iestructurado del proyecto,
87, 92-98
concepto de, 87-89
im plantacin descendente, 87, 105-8
objetivos, 88-89
C iclo de vida de prototipo, 87. 108-12
candidatos para, 109-12
definicin de, 108
softw are usado, 109
C iclo de vida estructurado del proyecto, 98-105
anlisis de sistem as, 10
conversin de bases de datos, 103-4
diseo, 101
encuesta, 98-99
generacin de pruebas de aceptacin, 102
im plantacin, 102
instalacin, 104
prueba de calidad, 102
resum en de, 103-5
Ciclo de vida sem iestructurado del proyecto, 87,
92-98
com parado con ei ciclo de vida clsico dei
proyecto, 95
C inta m agntica, 428, 430
Cdigos
cdigos alfabticos, 441-42
cdigos externos, 440
cdigo reutilizable, apoyo de IA para, 529
C digos de clasificacin, 441
C om plejidad excesiva, revisin tem prana contra,
528
Com portam iento dependiente del tiem po, 288-89
sistem as de tiem po real, 29
C om putadora Apollo, 517
C om putadora Sun, 517
Com putadoras personales (PC), 514, 516
C om putadoras VAX, 517, 525
Com putadoras W ang, 525
Cm putos, 443
Condiciones, estados, 294
C onfiabilidad
com o asunto de asignacin, 457-59
en el desarrollo de proyectos de sistem as,
125-28
errores de software, 125-28
restricciones, 446-47
C ontroles de grupo, 445-46
Control de calidad, ciclo de vida estructurado del
proyecto y, 103
C ontrol de docum entos, 527
Conversin, 486-87
de bases de datos, 103
costos de, 553
Correccin de errores, 514
ciclo de vida clsico del proyecto, 91
C ostos de capital, en contraposicin con gasto,
558
C ostos de construccin, sistem as, 551-52
C ostos de personas, 556
C ostos de planta fsica, 557
C uestionarios, 586
www.FreeLibros.org
726 INDICE
D atos elem entales, diccionario de datos (Dl>),

216
Datos opcionales, diccionario de datos (DD),
216-18
D ecisin de im plantacin, 27
D eclaracin de propsito
Yourdon Press, 594-95
D efiniciones, diccionario de datos,
DER, vase diagram as de entidad-relacin
D esarrollo, vase D esarrollo de sistem as
Departam ento de adm inistracin de sistem as de
inform acin (M IS), 58-60
D epartam ento de estndares
objetivo de, 61
problem as ai trabajar con, 62-64
D epartam ento de proceso de datos, 58-60
D epartam ento de pruebas de calidad
objetivo del, 61
problem as al trabajar con el. 62-64
D esarrollo de sistem as
asuntos im portantes de, 117-35
confiabilidad, 125-28
eficiencia, 129-30
m antenibilidad, 127-30
portabilidad, 129-30
productividad, 118-26
seguridad, 129-30
participantes en, 45-71
adm inistracin, 56-60
analista de sistem as, 63-65
auditores, 59-64
departam ento de estndares, 59-64
diseadores de sistem as, 64-65
personal de operaciones, 66-68
personal de control de calidad, 59-64
program adores, 64-67
usuarios,, 46-57
relacin entre la adm inistracin y, 58-60
DFD, vase D iagram as de flujo de datos
D iagram a de burbujas, vase D iagram as de flujo
de datos
D iagram a SADT, 331-34
D iagram as de Bachm an, 332-34
D iagram as de contexto
construccin de, 379-87
nom bre tpico de proceso para, 379-80
term inadores duplicados en, 382-83
D iagram as de entidad-relacin (DER), 77-81,

141-42, 221-22, 260-87, 360-61
balanceo contra el DFD y las
com ponentes de, 78-79, 262-71
indicadores de tipos asociativos de objetos,
268-71
relaciones, 264-68
tipos de objeto, 262-65
definicin de, 77-78
notacin de diccionario de datos para, 280-82
regias de construccin, 270-81
aadir tipos de objetos, 270-77
elim inar tipos de objetos, 276-81
variantes de, 331-35
Yourdon Press, 662
Diagram as de estructura de datos de DeM arco,
332-34, 334
D iagram as de Ferstl, 323-25, 326
Diagram as de flujo, 248-50, 320-26
crticas sobre, 248-49
diagram a de flujo clsico, 320-22
diagram a de flujo no estructurado, 322-23
notacin, 320-22
variantes de, 322-326
Diagram a de flujo de datos de alto nivel, 396
Diagram a de flujo de datos inicial, desarrollo de,
402-5
Diagram a de flujo de datos prelim inar, 395-96
Diagram a de flujo de trabajo, vase D iagram as de
flujo de datos
D iagram as/grficas, 246-47
D iagram as de anlisis de problem as (PAD),
323-25, 326, 326-28
com ponentes de, 326
D iagram as de entrada-proceso-saiida (1PO),
329-31
Diagram as de estructura, 79-82, 329-32, 460-61
mdulos, 7 9 - 8 1
Diagram as de estructura de datos de Jackson,
332-35
D iagram as de flujo de datos (DFD), 74-78,
157-210, 221-22, 360-61
cmo evitar com plejidad excesiva en, 180-81
com paracin con DER, 260
com ponentes de, 75-77, 159-77
alm acenes, 75-77, 168-75
flujos, 75-77, 161-69
procesos, 75-76, 159-62
www.FreeLibros.org
INDICE
term inadores, 75-77, 174-77

diagram as de flujo nivelados, 185-92
diccionario de datos (DD), 75-77
ejem plo de, 75
especificacin de proceso, 75-78
extensiones de, para sistem as de tiem po real,
193-95
modelo final del comportamiento, Yourdon
Press, 638-46
modelo preliminar del comportamiento,
nivelacin de, 409-15
nivelacin ascendente, 409-13, 415-16
nivelacin descendente, 409-14
problema del elevador, 700-14
reglas de consistencia, 182-86
relacin entre DTE y, 298-99
uso en lugar de diagram as PERT, 345-47
variaciones de,331-32
volviendo a dibujar el, 181-83
D iagram as de flujo de datos nivelados, 185-92
consistencia, 190-93
m ostrar alm acenes en diferentes niveles,
190-93
m ostrar niveles a los usuarios,
nm ero de niveles, 189-93
particin, 189-93
uso de, 190-93
D iagram as de flujo del sistem a, 326-29
D iagram as de Gane-Sarson, 331-32
D iagram as de Hamilton-Zeldin, 323-26
D iagram as de N assi-Shneiderm an, 249-52,
322-25
versus pseudocdigo, 251-52
D iagram as de transicin de estados (DTE), 26-27,
79-81, 81-82, 141-42, 194-95, 221-22, 288-304,
360-61
com parados con DER, 260
diagram as por partes, 294-97
notacin, 289-95
cam bios de estado, 291 -94
condiciones y acciones, 294-95
estados del sistema, 289-92
relacin con otros com ponentes del modelo,
299-300
relacin entre DFD y, 298-99
term inacin de, 415-17
D iagram as HIPO, 328-30
727
Diagramas IPO (siglas en ingls de

entrada-proceso-salida), 329-31
Diagramas PERT, 342-45
lista de actividades, 346-49
actividades de alto nivel, 348-50
Diagramas por partes, 294-97
D ilogo/interfaz hum ano-m quina, vase interfaz
hum ana
D iccionario de datos (DD), 75-77, 211-26, 360-61
aceptacin por el usuario, 219-22
balanceo de, 308-10, 313-14
versus DD, 308-9
versus DTE, 313-14
versus especificaciones de proceso, 308-10
entradas, 142-43
implantacin de, 221-23
im portancia de, 211-12
notacin, 214-20
alias, 219-20
datos elem entales, 216-17
datos opcionales, 216-18
definiciones, 215-16
esquemas de notacin, 214-15
iteracin, 218-19
necesidad de, 212-15
seleccin, 218-20
notacin de DER, 280-82
problem a del elevador, 715-17
terminacin de, 414-15
D iscos flexibles, 427-28
D iseadores de sistem as, 64-65
D iseo
ciclo de vida estructurado del proyecto, 101-2
vase tam bin Diseo de sistem as
D iseo de form as, 437-41
contenido de form as, 437-38
form as separables, 438-39
form as especiales, 438-41
costo de, 439-41
m ultiparte, 439-41
tipos de, 439-41
D iseo de sistem as. 452-69
acoplamiento, 465-66
alcance del efecto de/alcance de control,
465-67
cohesin, 465-66
etapas de, 453-65
www.FreeLibros.org
728 INDICE
m etas/objetivos, 463-67
modelo de implantacin del programa,
460-64
modelo del procesador, 455-59
modelo de tareas, 459-60
programacin/prueba, 470-91
reglas para, 465-67
tamao de los mdulos, 466
E ficiencia
como cuestin de asignacin, 456-58
como cuestin de programacin, 477-80
en el desarrollo de proyectos de sistem as, 130
EG A -Paint, 518, 520
Ejecucin en paralelo, costo de, 554-55
Encuesta, ciclo de vida estructurado del proyecto,
98-101
Enfoque de m odelado clsico, 353-58
falla de, 353-58
modelo lgico actual, 354-56
modelo lgico nuevo, 354
modelo fsico actual, 354
modelo fsico nuevo, 355
suposiciones acerca de, 356-57
Enfoque descendente
para el modelo de comportamiento, 396-97
fenmeno de los seis analistas, 397
parlisis del anlisis, 397
particin fsica arbitraria, 397
Entradas
aparatos de entrada, 427-29
cintas magnticas, 427
discos flexibles,"427
entrada de voz, 429
lectores pticos/lectores de cdigo de
barras, 429
tarjetas perforadas, 427
telfono, 429
termnales y computadoras personales
(PC), 427-29
entradas al sistema, 443
entradas redundantes, 445
tiem po de respuesta a, 446
Entradas, diccionario de datos (DD), 143 y ss.
Entrevistas, 575-86
formas alternas de recoleccin de datos,
586
problem as con, 576-78
razn para llevar a cabo, 575

reglas para llevar a cabo, 578-83
aprobacin para hablar con los usuarios,
578-80
estilos de entrevista 581-83
inform acin de inters para el usuario, 581
plan global, 578
problem as a prevenir, 585
resistencia, 582-84
uso de herram ientas autom atizadas, 581
uso efectivo del tiempo, 580-81
tipos de, 576
Equipo de desarrollo, costo durante la instalacin,
555
Errores, softw are, 125-28
Escribano, com o papel de auditora, 572
E specificaciones de funcin grficas, 139
Especificaciones de funcin m nim am ente
redundantes, 139
E specificaciones de funcin por partes, 139
E specificaciones de proceso, 77-78, 221, 227-59,
361
balanceo contra el DFD y DD, 309-11
diagram as de flujo 248-49
diagram as de Nassi-Shneiderman, 250-51
grficas/diagram as, 246-47
lenguaje estructurado, 231-39
lim itacin de la com plejidad de, 238-39
mantenimiento de, 486
pre/post condiciones, 239-44
problema del elevador, 718-21
requerim ientos de, 227-29
tablas de decisin, 244-46
terminacin de, 415-16
Estaciones de trabajo, costo de, 531 -32
Estado final del sistema, 293-294
Estado inicial del sistema, 293-294
Estados del sistema, 290-91
cam bios de estado, 292-94
Estimacin del programa de actividades, 534
Estim aciones detalladas prem aturas, 539-40
Flujos
Flujo de efectivo, 562-63
definicin de, 162
direccin de, 163
www.FreeLibros.org
INDICE
flujos convergentes, 63-66

flujos de dilogo, 163-66
flujos divergentes, 163-67
nom bre de, 162-63
Flujos de control, 75-77, 193-95
Flujos de datos, diagram as de contexto, 383-84
Flujos de dilogo, 385-87
Flujos divergentes, 163-67
Form as separables, 438-39
Form as especiales, 438-41
costo de, 439-41
form as m ultipane, 438-41
tipos de, 439-41
Form ato del sistema, 420-22
Frm ulas
de estim acin, 544-47
para estim ar el tiem po, 545-47
para estim ar el tiem po de trabajo, 544-46
Fracasos, costo de, 556-58
Frases
frases com puestas, 236-39
lenguaje estructurado, 233-35
Frontera de autom atizacin, 355-56
m odelo de im plantacin del usuario, 422-27
opciones extrem as, 422-23
seleccin de, 423-27
G eneracin espontnea de cdigo, 182-83

G eneracin de cdigo, 528-30
G eneracin de pruebas de aceptacin, ciclo de
vida estructurado del proyecto, ! 02-3
G raficador, 429-31
Grupo de adm inistracin de bases de datos
(DBA), 261-62
G rupo de adm inistracin ele datos (DA), 261-62
H ardware
costos de, 555-56
futuro de, 508-10
instalacin, 487-88
H erram ientas autom atizadas, 141-45, 513-33
580-82
caractersticas de, 517-23
apoyo grfico, 518-21
caractersticas de revisin de errores,
520-21
m odelos de revisin, 521-23
729
futuro de, 524-32

adm inistracin de proyectos, 527-28
cdigo reutilizable, apoyo por IA de,
529-30
com probante de que no hay errores,
auxiliado por com putadora, 528-29
control de docum entos. 525-28
estadsticas de productividad y m tricas de
software, 527-28
generacin de cdigo, 528-30
pizarrones del equipo dei proyecto, 529-32
pruebas y sim ulaciones auxiliadas por
com putadora, 528-29
redes para uso de todo el proyecto, 524-27
revisin tem prana contra com plejidad
excesiva, 528-29
software hecho a la medida
apoyo a m etodologa de ingeniera, 525-27
tipos de, 5 i 3-16
H erram ientas de m odelado, 73-75. 149-56
balanceo de, 3 0 5 -18
diagram as de entidad-relacin (DER), 260-87
diagram as de fiujo, 320-29
diagram as HIPO, 328-32
diagram as de transicin de estados (DTE),
288-304
diccionario de datos (DD), 211 -26
modelos grficos, 151-52
m odelos m nim am ente redundantes, 153-55
m odelos que se pueden dividir en forma
descendente, 151-54
m odelos transparentes, 154-55
para adm inistracin de proyectos, 340-51
H erram ientas de m odelado de tiem po real, 501-2
Im plantacin ascendente
ciclo de vida de cascada, 91-93
correccin de errores, 91 -92
prueba, 91-93
Im plantacin, ciclo de vida estructurado del
proyecto, 102-3
Im plantacin descendente,
ciclo de vida sem iestructurado del proyecto,
94-95
www.FreeLibros.org
730 INDICE
enfoque radical versus enfoque conservador,

104-9
Im plantacin descendente conservadora, 104-9
Im plantacin descendente radical, 104-9
Ingeniera de Software Auxiliada por
Com putadora (CA SE), 144-45
Inspecciones, 484-85
vase tam bin Auditoras
Instalacin
ciclo de vida estructurado del proyecto, 103-4
costo de, 552-55
del sistema, 487-89
software, 487-88
Inteligencia artificial
apoyo del cdigo reutilizable, 529-30
definicin de, 33-35
m atrim onio del anlisis estructurado y,
507-9
y costo del sistem a, 561-62
Interfaz amigable para el usuario
reglas para la, 433-38
vase tam bin, Interfaz hum ana
Interfaz humana, 26-27, 425-43
asuntos relacionados, 425-28
cdigos de entrada/salida, 439-43
cdigos alfabticos, 441-43
cdigos de clasificacin, 441-42
cdigos externos, 439-41
requerim ientos para, 439-42
contenido de formas, 437-38
form as especiales, 438-41
form as separables, 438-39
form atos de entrada/salida, 431-38
reglas para una interfaz am istosa para el
usuario, 433-38
unidades de entrada, 427-29
cinta m agntica, 427-28
discos flexibles, 427-28
entrada de voz, 428-29
lectores pticos/lectores de cdigo de
barras, 428-29
tarjetas perforadas, 427-28
telfono. 428-29
term inales y com putadoras personales
(PC), 427-29
unidades de salida
cinta niagntica/discos, 429-31
graficadora, 429-31
Microforma de salidas de com putadora

(COM), 431-32
salidas de voz, 429-31
salidas im presas, 429-31
tarjetas, perforadas, 429-31
terminales, 429-31
International Business M achines (IBM ), 516-17
Investigacin externa, 586-87
Iteracin, diccionario de datos, 218-19
J e r a r q u a sincronizada d e m dulos, 331-32
L ecto res de cdigo de barras, 428-29

Lectores pticos, 428-29
Lenguaje de program acin ADA, 121-22, 476-77
Lenguaje de program acin BASIC, 121-22,
475-76, 476-77
Lenguaje de program acin C, 109, 476-77
Lenguaje de program acin COBOL, 33-34,
121-22, 144-45, 246, 473-74, 475-76. 476-77
480-81, 513-14, 428-29
Lenguaje de program acin dBASE III, 121-22,
222-23, 421-22
Lenguaje de program acin FOCUS, 121-22
421-22, 477-79
Lenguaje de program acin FORTRAN, 121-22,
246, 473-74, 475-76, 476-77, 528-29
Lenguaje de program acin IDEAL, 421-22,
477-79
Lenguaje de program acin LISP, 34-37
Lenguaje de program acin MANTIS, 477-79
Lenguaje de program acin MAPPER, 121-22,
477-79
Lenguaje de program acin MARK V, 121-22.
477-79
Lenguaje de program acin NOMAD, 421 -22
Lenguaje de program acin Pascal, 121-22,
144-45, 476-77
Lenguaje de program acin PC-FOCUS. 121-22
Lenguaje de program acin PROLOG. 34-37
Lenguaje de program acin RAM IS. 477-79
Lenguaje estructurado, 230-40, 246
frases, 233-35
frases com puestas, 236-39
objetos, 231-34
verbos, 231-33
www.FreeLibros.org
INDICE
L enguaje narrativo, 247-49

enfoque dei anlisis estructurado por
particiones, 248-49
Lenguajes de program acin de alto nivel, 513-14
Lenguajes de program acin de cuarta generacin,
476-79
Lenguajes de program acin de prim era
generacin, 475-76
Lenguajes de program acin de segunda
generacin, 475-77
Lenguajes de program acin de tercera
generacin, 476-77
Lista de acontecim ientos
problem a del elevador, 699
Lotus 1-4, 29-30
M acD raw , 517-18, 520-21

M acPaint, 517-18,520-21
M antenibiiidad
como cuestin de program acin, 479-80
127-30
M antenim iento
costos de, 555-57
de especificaciones, 492-512
im portancia de, 493-95
prerequisitos necesarios, 494-96
reglas, 495-98
desastres, impacto de, 504-7
orculo de m antenim iento, com o papel de la
auditora, 572-73
program ador de m antenim iento, 66-67
M anuales para el usuario, 488-89
M esas de trabajo de diseo, 514-16
M icrosoft File, 222-23
M inicom putadora para todo el proyecto, 524-27
M odelado. 26-27. 73-85, 141-42
com portam iento dependiente del tiempo,
79-81
datos alm acenados, 77-81
estructura del program a, 79-82
funciones del sistema, 74-78
herram ientas, uso de, 73-75
relacin entre m odelos, 82-83
tipos de m odelos, 73-74
731
M odelado de datos, integracin de modfelado de

procesos y, 501-2, 599-600
M odelado de procesos, integracin de modelado
de datos y, 501-3
M odelo am biental, 360-61, 372-91
aspecto crtico del, 369-70
com ponentes del, 372-79
declaracin de propsitos, 372-75
diagram a de contexto, 374-75
diagram a de contexto, 379-87
diccionario de datos inicial, 378-79
factores de alcance del proyecto 370-73
modelo de entidad-relacin de alm acenes
externos, 378-79
M odelo de com portam iento, 360-61, 395-418
construccin del modelo prelim inar, 395-407
conexin de respuestas de
acontecim ientos, 402-4
enfoque clsico, 396-98
identificacin de respuestas de
acontecim ientos, 396-402
pasos de desarrollo, 402-5
term inado de, 408-18
diagram a de transicin de estado, 415-17
diccionario de datos (DD ), 414-15
modelo de datos, 415-16
nivelacin de un DFD, 409- 5
desarrollo descendente de, 396-98
M odelo de datos, com pletar ei, 415-16
M odelo de im plantacin, aspectos laicos de,
360-64
M odelo de im plantacin del program a, 460-65
M odelo de im plantacin del usuario, 27-28,
67-68, 326-28, 355-56, 419-451
cuestiones de seguim iento, 452-512
diseo de sistem as, 452-69
futuro del anlisis estructurado, 500-12
m antenim iento de la especificacin,
429-99
program acin/prueba, 470-91
especificacin de restricciones operacionales,
445-48
frontera de autom atizacin, 422-27
opciones extrem as, 422-23
www.FreeLibros.org
732 INDICE
seleccin de, 423-27

identificacin de actividades adicionales de
apoyo manual. 442-46
interfaz hum ana, 425-443
asuntos relacionados, 425-28
cdigo entrada/salida, 439-43
form atos de entrada/salida, 431-38
unidades de entrada/salida, 427-32
M odelo de procesador, 453-59
asuntos de asignacin, 456-59
M odelo de proceso, vase D iagram as de flujo de
datos
M odelo de tareas, 458-61
M odelo esencial, 352-53, 357-67, 419-21
com ponentes de, 360-61
detalles de im plantacin, 358-60
dificultades en la construccin, 358-60
problem a del elevador, 697-98
M odelo fsico actual, desenfatizacin de, 501-2
M odelo funcional, vase diagram as de flujo de
datos
M odelos, balanceo de, 305-18
M odelos de estim acin com putarizados, 547-48
M odelos grficos, 151-52
M odelos m nim am ente redundantes, 153-55
M odelos que se pueden dividir en forma
descendente, 151-54
M odelos transpatentes, 154-55
M dulos cohesivam ente funcionales, 465
M dulos pequeos, program as, 480-81
M icroform a de salidas de com putadora (COM ),
431-32
N egociacin, d ife re n c ia e n tre estim aci n y,

536-37
Nivelacin
diagram as de flujo de datos (DFD). 409-15
nivelacin ascendente, 409-13, 415-16
nivelacin descendente, 409-14
Nivelacin ascendente, DFD, 409-13
Nivelacin descendente, diagram as de flujo de
datos (DFD), 409-14
Nom bres de procesos, 379-81
Notacin
diagram as de flujo, 320-22
diagram as de transicin de estado (DTE)
cam bios de estado, 290-94

condiciones y acciones. 294-95
estados del sistema, 289-92
diccionario de datos (DD)
alias, 219-20
datos elem entales, 216-17
datos opcionales, 216-18
definiciones, 215-16
esquem as de notacin, 214-15
iteracin, 218-19
necesidad de, 212-15
seleccin, 218-20
O bjetos, lenguaje estructurado, 231-34
Paquete de so ftw a re de diseo (Meta System s

Inc.), 598-99
Paquetes de control de cdigo fuente, 514-15,
Particin de acontecim ientos, 142-43, 501-2
enfoque del modelo de com portam iento,
396-402
PC-Draw, 517-18, 520-21
Personal de operaciones, papel de. 66-68
PFS-File, 222-23
Portador de estndares, como papel de auditora,
572-73
Pre/post-condiciones, 239-44
Preparacin, 488-49
Preparacin de sedes de com putadora, 487-88
Prerrequistos, m antenim iento de
especificaciones, 494-96
Presentador, com o papel de auditora, 572-73
Presupuesto, estim acin de, 534-35
Problem a del elevador, 693-721
descripcin narrativa, 694-96
diccionario de datos (DD) 715-17
lista de acontecim ientos, 699
modelo esencial, 697, 698
Proceso de anlisis
modelo del com portam iento
construccin del. 395-96
term inado de, 408-18
modelo am biental, 368-94
modelo esencial, 352
www.FreeLibros.org
INDICE
m odelo de implantacin del usuario, 341-451

Procesos
ejem plo de, 159-61
eleccin de nom bres para, 159-61
definicin de. 159-61
nom bre de burbujas de proceso, 161-62
numeracin de, 179-81
Procesos de control, 75-77, 193-95
Procesos no etiquetados, 183-85
Productividad
com o asunto de program acin, 477-79
118-26
estadsticas, 527-28
Productos CASE, 525-27
Program acin, 470-81
asuntos importantes, 477-80
futuro de, 479-81
im pacto sobre la estructura organizacional,
472-74
lenguajes de program acin, 475-81
generaciones de, 475-79
papel del analista en, 471-73
seguimiento rpido e implantacin
descendente, 474-76
Program acin de personal, estim acin de, 534-35
Program acin estructurada, 479-80
Program a de hoja de clculo, 30
Program adores, 64-67
contacto con analistas, 65-67
programador de mantenimiento, 66-67
Programa Lightyear, 30-31, 34-35
Progresin secuencia!, ciclo de vida clsico del
proyecto, 92-94
Prototipos, 55-56
uso en anlisis estructurado de, 144-46
Prueba, 480-85
conceptos relacionados, 484-85
docum ento de plan de prueba, 481-83
descripciones, 484-85
localizacin, program acin, 483-84
propsito, 483-84
herram ientas de prueba, 513-14
im pacto sobre la organizacin estructural,
472-74
papel del analista de sistem as en, 471-73
733
prueba y simulacin auxiliadas por

computadora, 528-29
tipos de, 481-85
prueba de funcionam iento, 481-82
prueba de recuperacin, 482-83
prueba de rendim iento, 482-83
Prueba de funcionalidad, 481-82
Prueba de inexistencia de errores, 484-85
auxiliada por computadora, 528-29
Pruebas de funcionamiento, 482-83
Pruebas de recuperacin, 482-83
Pruebas y sim ulacin auxiliadas por
computadora, 528-29
R base-5000, 1121-22, 222-23, 421-422, 477-79

Recoleccin de datos, 586-87
Recoieccin de datos
formas de, 585-86
entrevistas, 575-87
Recursos hum anos, estim acin de, 534-35
Redundancia, 444-46
R edundancia interna, 445-46
Reestructuracin, de program as, 121-22
Reglas de consistencia, DFDs, 182-86
Reglas de estim acin, 534-548
cosas a ser estim adas, 534-35
factor de comunicacin, 542-45
frm ulas, 544-47
para estim ar el tiem po, 545-47
para estimar el tiempo de trabajo, 544-46
m odelos de estim acin computarizada,
547-48
peligros, 535-42
al estim ar su propio trabajo, 537-39
diferencia entre estim ar y negociar, 536-37
dificultad en la m edicin de la unidad de
trabajo, 539-40
estimaciones basadas en suposiciones
referentes a tiem po extra no pagado,
540-42
estim aciones detalladas prem aturas,
539-40
falta de bases de datos de estim acin,
538-39
gran diversidad en cuanto a habilidades
tcnicas, 537-38
unidades de estim acin, tam ao de, 541-44
www.FreeLibros.org
734 INDICE
unidades de trabajo, independencia de las,

542-44
Reglas de referencia, 488-89
Relaciones, diagram as de entidad-relacin (DER),
78-79
Rendim iento de una inversin, 563-64
R esistencia a la entrevista, 582-83
Respuestas de acontecim ientos, conexin de
402-4
Restricciones ambientales, 447
Restricciones operacionaies, como asunto de
asignacin, 459
R estricciones polticas, 447
como asunto de asignacin, 459
R etraso desconocido, 119
R etraso invisible, 119
R etraso visible, 119
Retrasos, vase aplicaciones retrasadas
Salida de voz, 430

Salidas
obtencin de salidas dei sistem a, 444
salidas redundantes, 445
unidades de salida
cinta m agntica/ disco, 430
graficadora, 430
Microformas de salidas de computadora
(COM ), 431
salidas de voz, 430
salidas im presas, 430
tarjetas perforadas, 430
terminales. 430
Salidas im presas, 430
Seguridad
com o asunto de asignacin, 458
en proyectos de desarrollo de sistem as, 130
restricciones, 446-47
Seleccin, diccionario de datos (DD), 219-20
Sim plicidad de estilo, program as, 480
Sim ulacin, auxiliada por com putadora, 529
Sim uladores, 514
Sistem a de adm inistracin de bases de datos
IDMS, 222, 261
Sistema de adm inistracin de bases de datos IMS,
222, 261
Sistema de adm inistracin de bases de datos
TOTAL, 222, 261
Sistemas
costos de construccin, 551-52

costos de instalacin, 553-54
costos de operacin, 557-58
definicin de, 10-14
entradas al sistem a, 443
salidas del sistem a, 444
similitudes entre, 11
sistem as autom atizados, 18-37
sistem as hechos por el hom bre, 17-18
sistemas naturales, 13-17
tipos de, 13-18
Sistem as autom atizados, 18-37
aplicaciones, 20
definicin de. 18
com ponentes com unes de, 19
sistem as basados en el conocimiento, 34-37
sistem as de apoyo a decisiones,
sistemas en lnea, 25-27
sistem as de tiem po real, 27-29
Sistemas basados en el conocim iento, 34-37
definicin de, 34
Sistem as CAD/CAM ,
Sistem as de apoyo a decisiones, 30-33
definicin de, 30
ejemplos de, 30-31
Sistemas en lnea, 25-27
cam bios de estado, 27
com parados con sistem as por lote, 25
definicin de, 25
uso de, 27
Sistemas de planeacin estratgica, 31-32
m odelos tpicos de 31-34
Sistemas de proceso de inform acin,
autom atizacin de, 18
Sistem as de tiem po real, 27-29, 288-89
ambiente, 28
anlisis estructurado y, 140-42
caractersticas de, 30
com portam iento dependiente del tiem po, 28
definicin de, 27
ejem plos de, 289
extensiones a diagramas de flujo de datos
(DFD) para, 194-95
tipos de, 27-28
Sistem as expertos, vase Sistem as basados en
conocim ientos
Sistemas hechos por el hombre, 17-18
com putarizacin de, 17-18
www.FreeLibros.org
INDICE
ejemplos de, 17
Sistemas naturales, 14-17
sistemas vivos, 14-17
interaccin de sistemas hechos por ei
hombre dentro de, 16-17
sistemas fsicos, 14
Sistemas operacionales, relacin entre, 31-34
Sistemas por lotes (batch), 25
Software
costo de 556
errores de, 125-26
instalacin, 487
mantenimiento, 128
mtrica, 528
Tablas de decisiones, 244-46

Tarjetas perforadas, 428, 430
Telfono, 429
Teora general de sistemas, 12, 37-40
Terminadores, 174-76
comunicacin entre el sistema y, 381
definicin de, 175
fuentes/manejadores, 382-83
proceso de comunicacin, 381-82
representacin grfica de, 175
terminadores duplicados en el diagrama de
contexto, 382
Terminadores duplicados, en ei diagrama de
contexto, 382
Terminales, 430
definicin de, 25
terminales de tiempo compartido, 514
y computadoras personales (PC), 428-29
Terminales de tiempo compartido, 514
Tiempo medio entre fallas (MTBF), 447
Tipos de objeto, DER, 78
735
Transportabilidad
como asunto de programacin, 479-80
en el desarrollo de proyectos de sistemas,
130
Usuarios, 46-56
caractersticas de, 54
clasificacin por categora de empleo, 48-54
usuarios de nivel ejecutivo, 51-52
usuarios operacionales, 48-49
usuarios supervisores, 5 0 -5 1
clasificacin por nivel de experiencia, 54-56
novatos presuntuosos, 56
usuarios amateurs, 54-55
usuarios con experiencia, 56
heterogeneidad de, 48
identificacin de, 47-48
preparacin de sedes,
Usuarios de nivel ejecutivo, 51
Usuarios operacionales, 49-50
Usuarios supervisores, 50-51
V alor neto actual, 563-65

Vendedores
costos de instalacin, 553-54
presentaciones por, 586
Verbos, lenguaje estructurado, 231
Verificacin de secuencia, 446
Vicepresidente, com o papel de a auditora, 572
Visitas, a otras instalaciones, 586
Volmenes de datos, especificacin de, 446
Vrtices infinitos, diagramas de flujo de datos
(DFD), 182
www.FreeLibros.org

Análisis Estructurado Moderno - Edward Yourdon

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Análisis Estructurado Moderno - Edward Yourdon

Hochgeladen von

Copyright:

Verfügbare Formate

www.FreeLibros.

M xico - Englewood C liffs - Londres - Sydney - Toronto

Raymundo Cruzado Gonzlez

EDW ARD YOURDON: A N A L I S I S ESTRUCTURADO M O D E R N O 1 /E

M ODERN STRUCTURED ANALYSIS

LAS HERRAMIENTAS DE MODELADO

T erm inado del m odelo de com portam iento 408

Lo que es valioso no es nuevo y o que es nuevo no es valioso.

de la dcada de los 70, Este libro analiza ios diagramas de entidad-relacin y de

negocios. Tambin pudieran ser novedosos ios diagramas de entidad-relacin para

El com ienzo y el fin a l de to d a actividad hum ana son desordenados: la co n s

En est captulo ce aprender:

B ie n . Aqu estamos al comienzo de un largo libro. La perspectiva de leer un

POR QUE ES INTERESANTE EL ANALISIS DE SISTEMAS?

Aun cuando no se vaya a dedicar a un empleo de oficina (es decir, si piensa

QUE HARA ESTE LIBRO POR USTED

Como ya habr adivinado, uno de los principales propsitos de este libro es

Y como dijo Sir Stanley Eddington [Eddington, 1987],

H em os e n co ntra d o una e xtra a h u e lla en las p la ya s de lo

Otro propsito de este libro es hacerle entender y apreciar que vivimos en un

ORGANIZACION DEL LIBRO

un sistema involucra el desarrollo de diversos tipos de modelos, el ltimo de los cua

as de las preguntas estn enfocadas a discusiones en clase; no hay respuestas co

Tom DeMarco. Structured Anaiysis and Systems Specification.

John Gal!, Systemantics.

Seymour Papert, Mindsiorms. New York: Basic Books, 1980.

Edward Yourdon, Natons at Risk.

New York: Quadrangle/The New York Times Book

Englewood Cliffs, N.J.: YOURDON Press,

Explique cmo puede serle til el anlisis de sistemas en su empleo o profe

Proyecto de investigacin: Cuntas personas hay empleadas como analistas

Proyecto de investigacin: Existe escasez de programadores y analistas de

Estara estudiando anlisis de sistemas si no tuviera la necesidad de hacerlo?

Por qu es probable que el anlisis de sistemas sea ms interesante que la

Qu cosas debe aprender un analista de sistemas aparte de las habilidades

Por qu pueden ser tiles para estudiar sistemas no computacionales las he

Finalm ente, pondrem os ai Sol m ism o en el centro dei U niverso. To

LA NATURALEZA DE LOS SISTEMAS 11

12 LA NATURALEZA DE LOS SISTEMAS

xima ventaja de un procesador, de un lenguaje de programacin y de un sistema ad

Un grupo de cuerpos que interactan bajo la influencia de

Un grupo de rganos del cuerpo que juntos llevan a cabo

Un grupo de fuerzas u objetos naturales <un ~ de ros>

d. Un grupo de aparatos o una organizacin que forma una red,

LA NATURALEZA DE LOS SISTEMAS 13

2. Juego organizado de doctrinas, ideas o principios, usualmente con

TIPOS COMUNES DE SISTEMAS

Como podemos ver de la definicin anterior, existen muchos tipos diferentes

La gran mayora de los sistemas no estn hechos por el hombre: existen en la

Sistemas estelares: galaxias, sistemas solares, etctera.

Sistemas geolgicos: ros, cordilleras, etctera.

Sistemas moleculares: organizaciones complejas de tomos.

Es interesante estudiar los sistemas fsicos pues, como humanos entrometidos

14 LA NATURALEZA DE LOS SISTEMAS

Los sistemas vivientes, desde luego, comprenden toda la gama de animales y

El reproductor, que es capaz de dar origen a otros sistemas similares a

La frontera, que mantiene unidos a los componentes que conforman el

El inyector, que transporta la materia-energa a travs de ia frontera dei

El distribuidor, que trae material desde el exterior del sistema y lo reparte

LA NATURALEZA DE LOS SISTEMAS 15

El convertidor, que cambia ciertos materiales que ingresan al sistema a

16 LA NATURALEZA DE LOS SISTEMAS

La memoria, que lleva a cabo la segunda etapa del proceso de aprendiza