Capitulo 18 - EL MODELO AMBIENTAL (Yourdon)

Para el analista, la labor ms difcil en la especificacin de un sistema es

a menudo determinar qu es parte del sistema y que n. Cualquier
sistema ser parte de un sistema an mayor.
El primer modelo importante que debe desarrollar el analista es uno que
defina las interfaces entre el sistema y el ambiente. Este modelo se
conoce como el modelo ambiental. Modela el exterior del sistema; el
modelo del interior del sistema, es conocido como modelo del
comportamiento.
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 crticamente importante definir qu informacin
entra al sistema desde el ambiente exterior, y qu informacin produce
como salida al ambiente externo.
Los sistemas son racionales y tienen propsito; especficamente,
producen salidas como respuesta a algn acontecimiento, o estmulo, en
el ambiente. As, otro aspecto crtico del modelo ambiental consiste en
identificar los acontecimientos que ocurren en el ambiente al cual debe
responder el sistema. No para todos los acontecimientos; ya que el
ambiente en su totalidad genera un nmero infinito de acontecimientos.
Slo a aquellos que (1) ocurren en el ambiente exterior y (2) requieren
una respuesta del sistema.

Figura 1: La frontera entre el sistema y el ambiente

La frontera entre un sistema y su ambiente, como ilustra la Figura 1, es
arbitraria. Puede haberse creado por algn decreto administrativo, como
resultado de alguna negociacin politica, o simplemente por accidente. Y
eso es algo que el analista de sistemas usualmente tiene oportunidad de
influenciar.
Generalmente el usuario tendr una buena idea de la frontera general
entre el sistema y el ambiente. Pero a menudo existe un rea gris que
est abierta a negociaciones, es decir, un rea sobre la cual el usuario
(1) no est seguro, (2) no haba pensado, (3) tena algunas ideas
preconcebidas que est dispuesto a reflexionar o, (4) todas las
anteriores.
Por ejemplo, el usuario podra pedirle al analista desarrollar un sistema
de cuentas por cobrar. Aunque esto pudiera representar una frontera
firme y bien definida entre el sistema (conocido como el sistema C/C) y
el ambiente, el analista ciertamente debiera considerar el rea gris de
cuentas por pagar, control de inventarios, manejo de efectivo,
facturacin y entrada de pedidos como perspectiva un tanto ms amplia
(figura 2)

Figura 2: El
rea gris
que rodea
a los
sistemas
de cuentas
por cobrar
Si
el
analista
escoge una
perspectiva demasiado pequea para un proyecto est condenado al
fracaso, pues el usuario puede haber identificado sin darse cuenta el
sntoma del problema en lugar de la causa del problema. Y si el analista
escoge una perspectiva demasiado amplia para el proyecto, est
condenado al fracaso, puesto que estar tratando con una situacin
poltica bastante ms compleja, y estar intentando desarrollar un
sistema demasiado grande bajo cualquier circunstancia. Adems,
pudiera estar tratando asuntos que no le imprtan al usuario o que no se
pueden cambiar en los absoluto. As que es importante 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 del proyecto como:

El deseo del usuario de lograr una cierta participacin en el mercado

para el producto, o incrementarla a ms de su nivel actual. Esto
puede hacerse ofreciendo un nuevo producto o una mayor
funcionalidad de uno existente (por ejemplo, la mayor funcionalidad
que ofrecen los sistemas de cajero automtico y los sistemas
bancarios en lnea). O el usuario podra tratar de aumentar su
mercado ofreciendo un mejor y ms rpido servicio (por ejemplo,
todos nuestros pedidos se surten en menos de 24 horas, y tenemos
un elaborado sistema de rastreo de pedidos para saber dnde 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 reportan el empleo (o desempleo) de trabajadores
basndose en edad, sexo, nacionalidad, etc. O podra ser de
impuestos.
Deseo del usuario por minimizar gastos operativos de algn rea de
su negocio.
Deseo del usuario por lograr alguna ventaja estratgica para la
lnea de productos o rea de negocios que opera. Organizando y
manejando informacin sobre el mercado para poder producir
artculos de manera ms aoportuna y econmica. Un buen ejemplo
de esto son las lneas ereas donde mejor informacin acerca de
tendencias del mercado y preferencias de los clientes pueden llevar a
costos de pasajes e itinerarios ms eficientes.

El rea dentro de la frontera del sistema se conoce como el dominio de

cambios. Todo lo que est dentro de la frontera del sistema est sujeto a
cambios (por ejemplo, reorganizacin y/o automatizacin), mientras que
todo lo que est fuera se queda e su forma actual y no es investigado
por el analista.
Herramientas usadas para definir el ambiente
El modelo del ambiente consta de tres componentes:
1) La declaracin de propsitos
Es una declaracin textual breve y concisa del propsito del sistema,
dirigida al nivel administrativo superior, la administracin de los
usuarios, y otros que no estn directamente involucrados con el
desarrollo del sistema.
Ejemplo: El propsito del Sistema de Procesamiento de Libros Ajax es
manejar todos los detalles de los pedidos de libros de los clientes,
adems del envo, facturacin y cobro retroactivo a clientes con facturas
vencidas. La informacin acerca 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.
Jams debe llegar a ms de un prrafo, ya que la intencin no es
proporcionar una descripcin completa y detallada del sistema: el
propsito del resto del modelo ambiental y del modelo de
comportamiento es dar todos los detalles.
La declaracin de propsitos ser deliberadamente vaga en cuanto a
muchos detalles. Se podra preguntar:
- Exactamente qu tipo de informacin proporciona a contabilidad,
ventas y mercadeo el sistema de pedido de libros?
- Cmo determina el sistema de pedido de libros si un cliente tiene
crdito? Lo determina el sistema mismo o por medio del
departamenteo de contabilidad?
Estas preguntas detalladas slo pueden responderse viendo el modelo
del comportamiento.
Aunque el documento de declaracin de propsitos no responde las
preguntas detalladas sobre el comportamiento, generalmente basta con
responder a una serie de preguntas de alto nivel. Por ejemplo:
- Es responsable el sistema de pedido de libros de las actividades de
nmina? No; la nmina queda fuera de la perspectiva del sistema y
probablemente est incluida en el sistema de contabilidad.
- Es responsable el sistema de pedido de libros de enviar facturas a los
clientes que piden libros? S; la declaracin de propsitos as lo afirma.
- 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 tal
afirmacin.
Muchos analistas sienten tambin que la declaracin de propsitos debe
resumir los beneficios tangibles y cuantificables que se logren con el
nuevo sistema.
2) El diagrama de contexto
Es un caso especial del diagrama de flujo de datos, en donde una sola
burbuja representa todo el sistema. La Figura 3 muestra un diagrama de
contexto de un sistema de pedido de libros.

Figura 3 Diagrma de Contexto

El diagrama de contexto enfatiza varias caractersticas importantes del
sistema:
- Las personas, organizaciones y sistemas con los que se comunica el
sistema. Se conocen como terminadores.
- Los datos que el sistema recibe del mundo exterior y que deben
procesarse 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 del sistema para
su uso, o bien son creados en l y usados fuera.
- La frontera entre el sistema y el resto del ambiente.
3) La Lista de acontecimientos
Es una lista narrativa de los estmulos que ocurren en el mundo
exterior a los cuales el sistema debe responder. Por ejemplo, para el
sistema de pedido de libros:
1. Un cliente hace un pedido. (F)
2. Un cliente cancela un pedido. (F)
3. La administracin pide un reporte de ventas. (T)
4. Llega un pedido de reimpresin de un libro a la bodega. (C)
El acontecimiento puede ser 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 el acontecimiento cuando llega
algn dato (o varios). Esto corresponder al flujo de datos en el
diagrama de contexto.
No necesariamente existe una correspondencia uno a uno entre los
flujos de datos del diagrama de contexto y los acontecimientos de la
lista de acontecimientos. En general, cada flujo de datos es un
acontecimiento (o, ms precisamente, la indicacin de que ha ocurrido),
o bien es requerido por el sistema para poder procesar un
acontecimiento.
Los acontecimientos temporales arrancan con la llegada de un
momento dado en el tiempo. Algunos ejemplos:

- A las 9:00 de la maana se requiere un reporte diario de todos los

pedidos de libros.
- Las facturas deben generarse a las 3:00 PM.
- Se deben generar reportes administrativos una vez por hora.
Los acontecimientos temporales no se inician con flujos de datos de
entrada. Pero un acontecimiento temporal podra requerir que el sistema
solicite entradas de uno o ms terminadores. Por ello, podran asociarse
uno o ms flujos de datos con un acontecimiento temporal, aunque los
flujos de datos, en s, no representan el acontecimiento mismo.
Los acontecimientos de control deben considerarse un caso especial
del acontecimiento temporal: un estmulo externo que ocurre en algn
momento impredecible. A diferencia de un acontecimiento temporal
normal, el acontecimiento 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 los muestra
la Figura 4, un acontecimiento de control se asocia con un flujo de
control en el diagrama de contexto.

Figura 4: Flujo de control asociado con un acontecimiento de

control
El flujo de control puede considerarse como un flujo de datos binario:
est encendido o apagado, y puede cambiar de un estado al otro en
cualquier momento, sealando as al sistema que se necesita tomar
alguna accin inmediata.
Componentes adicionales del modelo ambiental
Pueden ser tiles dos componentes adicionales, dependiendo de la
naturaleza y complejidad del sistema:
- El diccionario de datos inicial, que define todos los flujos y almacenes
externos.
- El modelo de entidad relacin de los almacenes externos
Aunque estos flujos de datos finalmente se definirn con gran detalle en
el modelo de comportamiento, podra ser til comenzar con la
construccin del diccionario de datos. 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 finalizar.
De manera similar, se puede construir un diagrama de entidad relacin
de los almacenes externos (si hay). Esto puede ayudar a dejar al
descubierto las relaciones entre almacenes que de otra manera no
seran evidentes hasta que se desarrollara el modelo de
comportamiento.
Construccin del modelo ambiental

En el modelo ambiental existe slo un proceso, unos cuantos flujos de

datos y terminadores, una descripcin narrativa brece del propsito del
sistema y una lista de acontecimientos. A pesar de esto, a menudo el
modelo ambiental requiere gran trabajo y una serie de refinamientos
iterativos.
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 perspectiva de quienes
desde dentro ven las cosas hacia fuera. Sin embargo, incluso en este
caso, los diversos usuarios individuales internos generalmente slo
estn familiarizados con una porcin, y sus diversas opiniones a veces
entran en conflicto. Peor an, tal vez se omitan uno o ms usuarios
importantes cuyas interacciones con los terminadores externos se deben
modelar.
Es importante dedicar una buena cantidad de tiempo y energa al
modelo ambiental, pues a menudo 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 contiuar
financiando el proyecto, y con el poder para cancelarlo).
Construccin del diagrama de contexto
El diagrama de contexto consiste en terminadores, flujos de datos y
flujos de control, almacenes de datos y un solo proceso que representa a
todo el sistema.
El proceso consiste en una sola burbuja. El nombre dentro del proceso
suele ser el nombre del sistema completo o un acrnimo convenido. En
las Figuras 5(a) y (b) se muestran ejemplos.

Figura 5(a): Nombre tpico de proceso para un diagrama de contexto

Figurqa 5(b): Otro nombre tpico de proceso

El nuevo sistema podra representar una organizacin completa; en este
cado, el nombre del proceso tpicamente sera el de la organizacin
misma, como lo muestra la Figura 5(c).

Figura 5 (c): Nombre de proceso que representa una organizacin

completa
Los terminadores se representan con rectngulos en el diagrama de
contexto. Se comunican directamente con el sistema a travs de flujos
de datos o de control, como muestra la Figura 6 (a), o a travs de
almacenes externos, como se muestra en la Figura 6 (b).
Los terminadores no se comunican directamente entre s. En realidad,
los terminadores s se comunican entre s pero, dado que por definicin

son externos al sistema, la naturaleza y contenido de las interacciones

terminador 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, entoncer los terminadores son parte
del sistema, y deben incluirse dentro de la burbuja de proceso del
diagrama de contexto.

Figura 6 (a): Comunicacin directa entre terminador y sistema

Figura 6 (b): Comunicacin a traves de un almacn externo

Tres aclaraciones ms acerca de los terminadores:
1. Algunos terminadores tienen un buen nmero de entradas y salidas.
Conviene dibujar el terminador ms de una vez, como muestra la Figura
7. Note que los terminadores duplicados se marcan con un asterisco;
otra posibilidad es representar los terminadores repetidos con una
diagonal.

Figura 7: Terminadores duplicados en el diagrama de contexto

2. Cuando el terminador es una persona individual, generalmente es
preferible indicar el rol que desempea, ms que su identidad; as, la
Figura 8(a) se prefiere a la Figura 8 (b). 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. Adems, una misma persona puede desempear varios
papeles distintos en el sistema. Por ejemplo: en lugar de mostrar un
terminador etiquetado Juan Prez con varios flujos de entrada y salida

no relacionados, es ms significativo mostrar los diversos papeles que

Juan Prez desempea, cada uno como terminador separado.

Figura 8 (a): Forma preferente de mostrar un terminador

Figura 8 (b): Forma menos deseable de mostrar un terminador

3. 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 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 el
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 la cual los datos se introducen y sacan del sistema,
el manejador no debe mostrarse. As, el diagrama de contexto de la
Figura 9 (a) se prefiere al que se muestra en la Figura 9 (b).

Figura 9(a): Terminador que muestra la verdadera fuente de los datos

Figura 9 (b): Terminador que acta como manejador

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 flujos 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 (como datos) para producir una
respuesta. Los flujos de datos tambin pueden aparecer 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 acontecimiento.
No se muestran los mensajes y medios especficos de coordinacin que
el sistema y los terminadores pasan entre s para indicar que estn listos
para las entradas o salidas, como en la Figura 10 (a). Se desea evitar
suposiciones sobre la implantacin que pueden cambiar cuando se
construye el nuevo sistema.

Figura 10 (a): Diagrama de contexto con mensajes innecesarios

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 la que
el sistema no inicia la generacin 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 10 (b) tiene un ejemplo. A veces resulta conveniente
mostrar el mensaje y el correspondiente flujo de entrada y salida con un
flujo de dilogo (una flecha de dos cabezas), como muestra la Figura 10
(c).

Figura 10 (b): Flujos de dilogo para mostrar mensajes esenciales

Figura 10 (c): Forma alterna de mostrar flujos de dilogo

Construccin de la lista de acontecimientos
La lista de acontecimientos 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 flujo relacionado con un acontecimiento. Por
ejemplo, lo siguiente no es un acontecimiento:
El sistema recibe el pedido del cliente
Ms bien, probablemente sea el flujo de datos de entrada mediante el
cual el sistema se da cuenta de que ha ocurrido el acontecimiento. Un
nombre ms apropiado para el acontecimiento sera:

El cliente hace un pedido

Si describimos el acontecimiento desde el punto de vista del sistema
(por ejemplo, desde dentro, viendo 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 desde el punto de vista del ambiente (es decir, desde
fuera, viendo hacia adentro).
La manera ms fcil de identificar los acontecimientos relevantes para
un sistema es 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 papel de
terminadores. Debe distinguirse entre acontecimientos 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
los mismos datos; si en algunas instancias estn presentes los datos, y
ausentes en otras, podra en realidad haber dos acontecimientos
distintos.
La lista de acontecimientos debe incluir no slo las interacciones
normales entre el sistema y sus terminadores sino tambin situaciones
de falla. Dado que se est creando un modelo esencial, no hay que
preocuparse por fallas del sistema; pero se deben tomar en cuenta
posibles fallas o errores causados por los terminadores. Se deben
construir respuestas para los problemas de los terminadores en el
modelo esencial del sistema.

Qu se hace primero, el diagrama de contexto o la lista de

acontecimientos?
Puede empezarse con la lista de acontecimientos o con el diagrama de
contexto. En realidad no importa mientras finalmente se produzcan
ambos componentes de modelo ambiental y revisen para asegurar que
sean consistentes.
Hablando con personas enteradas de todo lo que entra y sale del
sistema se podr tomar el diagrama de contexto como punto de partida.
Pueden discutirse entonces las transacciones que los 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 la que el diagrama de
contexto no est disponible: tal vez no sea fcil identificar los
terminadores de los diversos flujos que entran y salen del sistema. En
este caso suele ser ms prctico empezar con un DER que muestre los
objetos y relaciones. Los acontecimientos candidatos pueden
encontrarse a continuacin buscando las actividades u operaciones que
ocasionan que se creee 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 11.

Figura 11: Creacin del diagrama de contexto a partir de un DER

Cuando se termine con ambos componentes del modelo ambiental ser
posible confirmar lo siguiente:
- El sistema necesita cada flujo de entrada del diagrama de contexto
para reconocer que ha ocurrido un acontecimiento; debe necesitarlo
para producir 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
tener entradas a partir de las 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
parte de una respuesta a algn otro acontecimiento), o debiera
ocasionar un cambio en el estado del sistema.