MODELO AMBIENTAL

Además de determinar que pertenece al interior y al exterior del sistema, se necesita saber
que información entra al sistema desde el mundo exterior, y qué información sale del sistema.
Consta de las siguientes partes:

a. Declaración de propósitos Descripción textual, corta y concisa, del propósito general del
sistema, dirigida al nivel administrativo superior. Puede constar de 3 o 4 frases, pero nunca
debe superar 1 párrafo. Debe establecer claramente la frontera del sistema, a que otros
sistemas afecta, y puede incluir los beneficios que se esperan del nuevo sistema.

b. Lista de eventos Es una lista narrativa de los acontecimientos o estímulos que ocurren en
el mundo exterior y a los cuales debe dar respuesta el sistema. No confundir con flujos de
datos, describir desde fuera hacia dentro.

c. Diagrama de contexto DFD con 1 sola burbuja, debe enfatizar:  las personas,
organizaciones y sistemas con los que se comunica el sistema (terminadores). Se representan
con rectángulos. Los terminadores no se comunican entre sí.  los datos que el sistema recibe
del mundo exterior (entradas)  los datos que el sistema produce y que se envían al mundo
exterior (salidas)  los almacenes de datos externos que el sistema comparte con los
terminadores.  la frontera entre el sistema y el resto del mundo

Cuando se termine el modelo ambiental debe ser posible confirmar:  el sistema necesita cada
flujo de entrada para reconocer que ha ocurrido un evento, necesitarlo para producir una
respuesta, o ambos.  cada flujo de salida deber ser respuesta a un evento.  cada evento
debe producir salidas inmediatas como respuesta, o bien almacenar los datos que luego serán
salidas, o ocasionar un cambio de estado en el sistema (diagrama de transición de estados).

EJEMPLO

A los clientes habituales del Restaurant “comida rica” se le ofrece como servicio reservar mesa
para los días domingos. Cada cliente se da a conocer y si hay disponibilidad se realiza la reserva
y se le otorga un comprobante.

Modelo Ambiental

Declaración de Propósitos la empresa necesita gestionar las reservas de clientes para los días
domingos

Lista de Eventos un cliente reserva una mesa el administrador verifica datos clientes el
administrador busca disponibilidad de mesas el administrador realiza reserva de mesa el
sistema otorga comprobante al cliente
Diagrama de Contexto

LISTA DE EVENTOS.

Las primeras actividades de diseño de los sistemas, están especialmente influenciadas por la
naturaleza de los requerimientos y éstos incluyen principalmente descripciones en lenguaje
natural, representan una realidad dada e interpretada de diferentes maneras según sea la
visión y la capacidad de abstracción, de cada uno de los participantes del proyecto. En el caso
de que los requerimientos, fuesen realizados en forma oral o escrita en lenguaje natural, es
indispensable realizar un análisis profundo del texto para poder entender en detalle el o los
significados de todos los términos involucrados en el proyecto (libres de contradicciones e
incongruencias). Luego esta lista estructurada, en el diseño inicial, será la base para la
construcción de las entidades y sus relaciones; y que estarán representadas en los diagramas
de flujo de datos y en el modelo relacional de datos.

TÉCNICA PARA EL DISEÑO DE UNA LISTA DE EVENTOS

A continuación presentamos una lista de reglas empíricas que ayudarán a la construcción, en

forma estructurada, de la lista de eventos. . Elegir el nivel apropiado de abstracción para los
términos. Se debe preferir, la utilización de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las puede descifrar
fácilmente, porque se hace una clara imagen de ellas asociándolas a la realidad.

En cambio, las palabras abstractas designan conceptos o cualidades más difusos, y suelen
abarcar un número mayor de acepciones. El lector necesita más tiempo y esfuerzo para captar
su sentido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepción más apropiada, entre las diversas alternativas posibles.
Por ejemplo veamos los siguientes términos: El gerente del área de finanzas, es quien autoriza
las compras.

Es una oración demasiada ambigua. Su principal dificultad reside en el significado de compras.

Al tratarse de una palabra bastante genérica, entran en juego muchas acepciones

Compras se refiere a: Si se considera en función del tiempo, se refiere a: ¿compras

programadas, no programadas o ambas?. Si se evalúa en función del volumen, se refiere a:
¿grandes pedidos, a pedidos pequeños o ambos?. En función de su origen, involucra a: ¿las
importaciones o las de plaza local?. Y en función del bien: ¿en insumos y/o bienes de capital?.

¡Cuál de estos términos es el correcto?; si el resto del texto no ofrece la información necesaria
para sobre la alternativa correcta; solo queda la alternativa de hacer una hipótesis de
significado genérica. Lo que significa asumir un riesgo, que obviamente no debería existir.

. Evitar el uso de casos en lugar de conceptos generales. Es común observar que los usuarios
de los sistemas de información, adoptan términos más específicos de los que verdaderamente
son necesarios. Por ejemplo, el encargado de almacenes dice: "necesito conocer a diario la
cantidad en existencia de pastillas de frenos", El término pastillas de frenos no describe un
concepto, sino una instancia o componente del concepto correcto, esto es, un componente.
Por lo tanto el término debería ser insumos.

. Evitar las expresiones vagas o indirectas. Al usar rodeos, se incurre en el riesgo de expresar el
significado de los conceptos en términos de referencias implícitas a otros conceptos, en lugar
de referencias explícitas a los mismos conceptos. Por ejemplo cuando se dice: "mirá el
repuesto en la cajonera", en vez de decir; "mirá las cajoneras". La segunda oración indica una
clase específica de entidad (cajonera), mientras que la primera se refiere a la misma clase
indicando una interrelación con otra clase de entidad (repuesto). Es así que la segunda
oración, "mirá las cajoneras", permite una clara clasificación de los conceptos.

Elegir un estilo estandarizado de enunciado.

Lo que se busca con un modelo sintáctico es lograr una comunicación buena y eficaz.
Idealmente, se debe buscar elaborar enunciados que respondan a algún estilo estándar, en el
caso de las descripciones de los datos, éstas deben ser frases afirmativas, compuestas por
hasta cuatro elementos-llave, que son el <sujeto>, el <verbo>, el <objeto> y el
<complemento>, que pueden ser el instrumento o el modificador. Estos elementosllave
pueden estar acompañados de otras palabras como artículos, adjetivos, etc.; por ejemplo:

El encargado del sector ALMACENES verifica el PARTE DE RECEPCIÓN con la SOLICITUD DE

COMPRA

Generará la siguiente estructura-llave: ALMACENES verifica PARTE DE RECEPCIÓN con

SOLICITUD DE COMPRA

Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIÓN es el objeto y

SOLICITUD DE COMPRA es el instrumento.

Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOLICITUD
DE COMPRA
En ella no hay complemento.

También es importante que los enunciados que describen operaciones deben utilizar, tanto
como les sea posible, estructuras sintácticas no ambiguas (PRODUCTOS, en LISTA DE
PRODUCTOS o en STOCK), similares a las de los lenguajes de programación, como si, condición,
entonces, sino, cuando, hacer, acción. Por ejemplo: Si el monto es menor a 100 aprueba el
pedido, sino eleva el pedido a Gerencia Financiera.

Verificar los sinónimos y los homónimos. Distintas personas pueden dar el mismo significado a
diferentes cosas (sinónimo) o diferentes significados con las mismas palabras (homónimos). En
un procedimiento de ventas pueden encontrarse los siguientes términos: Cliente, comprador,
usuario, parroquiano, y referirse al mismo concepto (sinónimos) En el caso de que el mismo
término sea utilizado, en diferentes lugares, con significados diferentes es considerado pues
un homónimo. Por ejemplo Para finanzas el cliente es quien compra un producto, mientras
que para Marketing el cliente, o potencial cliente, es el usuario del producto.

. Hacer explícitas las referencias entre términos. Se debe evitar cometer ambigüedades; es
decir: frases que puedan interpretarse de dos o más maneras distintas. Algunas ambigüedades
surgen al no especificar las referencias entre los términos. La ambigüedad puede provocar o
un doble sentido o una incertidumbre.

En el caso de: Recepción firma remito. Cuál remito firma, el original o alguna copia.

O por ejemplo: El jefe de compras se reúne con cada uno de los proveedores en su despacho.
En qué despacho se reúnen, en el de compras o en el de los proveedores.

O en el caso particular de nuestros archivos, si contamos con dos archivos PRODUCTO Y STOCK
y ambos cuentan con los mismos atributos: Código del producto y Nombre del producto y,
STOCK se diferencia por contar además con el atributo Saldo del producto; Lo que ocurre es
que, probablemente no sean dos entidades distintas sino una sola entidad: PRODUCTOS EN
STOCK y que debería contener a los atributos de ambas.