Académique Documents
Professionnel Documents
Culture Documents
La red se define desarrollando una lista de todas las tareas asociadas con el pr
oyecto especfico, y una lista de secuenciamietos, que indica en qu
orden deben realizarse las tareas.
lo de proyectos informtico. Ambas
La Tcnica de Evaluacin y Revisin de Programas (Program Evaluamino Crtico y al diagr
ama de Gantt.
La Tcnica de Evaluacin y Revisin de Programas (Program Evaluation and Review Techn
ique-PERT) y el mtodo del Camino Crtico (Critical Path Method-CPM) son dos mtodos d
e planificacin temporal de proyectos que pueden aplicarse al desarrollo de proyec
tos informtico. Ambas tcnicas desarrollan una descripcin de la red de tareas del pr
oyecto, es decir, una representacin grfica o tabular de las tareas que deben reali
zarse desde el principio hasta el final del proyecto.
La red se define desarrollando una lista de todas las tareas asociadas con el pr
oyecto especfico, y una lista de secuenciamietos, que indica en qu
orden deben realizarse las tareas.
FIGURA 2.1. PERT Y CPM vez establecido el camino crtico, se lo utiliza para: cons
iderar alternativas, elaborar la lgica del plan y precisar las estimaciones de t
iempo de las actividades crticas, as como la influencia de limitaci ones y las pos
ibles soluciones de situaciones conflictivas
FIGURA 2.1. PERT Y CPM
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Definir las caractersticas fsicas de cada dato, como el tipo el dominio; la organi
zacin de cada archivo, como la definicin de las llaves principales, ndices, etc. (v
er 3. Base de datos, 3.1.2. llave primaria, 3.1.3 ndices de acceso).
Especificar los mdulos.
La especificacin de los mdulos, a travs de pseudo cdigo flujogramas u otros (ver.4.5
. Flujogramas).
umento no previsto del 60 %, en la emisin de rdenes de compra. Las fallas tambin p
ueden provenir de otros factores, como ser en el caso de que existan cambios en
las expectativas de los usuarios.
La Modificacin del programa; involucra algo ms que un simple cambio en el programa
; involucra un cambio estructural de una entidad Por ejemplo, un cambio en el nme
ro de dgitos del cdigo postal, o en el cdigo de zona telefnica. La diferencia con el
Mantenimiento es el grado de importancia
El Mejoramiento del sistema; es el agregado de capacidades que no f
INICIO DE UN PROYECTO NFORMTICO
En un entorno informtico estable, la decisin de iniciar un proyecto viene dada por
las necesidades de: mantenimiento, modificacin, mejoramiento, reemplazo o capaci
dad; encuadrndose as, el proyecto informtico, dentro de una categora de complejidad
mostrada en la figura 1.2:
El Mantenimiento del programa; es una consecuencia de una omisin realizada en la
etapa del diseo del sistema e involucra solucionar fallas menores del sistema,
que obligar a la realizacin de cambios en el programa; como por ejemplo el descuid
o de no considerar que puedan ocurrir en el sistema, ciertas condiciones extraor
dinarias; como sera el caso de un a
INICIO DE UN PROYECTO NFORMTICO
En un entorno informtico estable, la decisin de iniciar un proyecto viene dada por
las necesidades de: mantenimiento, modificacin, mejoramiento, reemplazo o capaci
dad; encuadrndose as, el proyecto informtico, dentro de una categora de complejidad
mostrada en la figura 1.2:
El Mantenimiento del programa; es una consecuencia de una omisin realizada en la
etapa del diseo del sistema e involucra solucionar fallas menores del sistema,
que obligar a la realizacin de cambios en el programa; como por ejemplo el descuid
o de no considerar que puedan ocurrir en el sistema, ciertas condiciones extraor
dinarias; como sera el caso de un aumento no previsto del 60 %, en la emisin de rd
enes de compra. Las fallas tambin pueden provenir de otros factores, como ser en
el caso de que existan cambios en las expectativas de los usuarios.
La Modificacin del programa; involucra algo ms que un simple cambio en el programa
; involucra un cambio estructural de una entidad Por ejemplo, un cambio en el nme
ro de dgitos del cdigo postal, o en el cdigo de zona telefnica. La diferencia con el
Mantenimiento es el grado de importancia
El Mejoramiento del sistema; es el agregado de capacidades que no formaron parte
del sistema de informacin original; por ejemplo cuando en una divisin se implemen
t un sistema de inventarios, este sistema no inclua un modulo para calcular la fut
ura demanda de bienes y partes. La inclusin de este sofisticado mdulo de clculo es
considerado un mejoramiento del sistema.
El Reemplazo del sistema; ocurre cuando los sistemas de informacin se tornan fsica
mente, tecnolgicamente o competitivamente obsoletos. Como es el caso de la utiliz
acin del lser, en el reconocimiento ptico de caracteres para la lectura del cdigo d
e barras, remplazando a la entrada por teclado.
La Nueva Capacidad del sistema; son sistemas de informacin para los cuales no es
necesario el uso de la automatizacin. Estn dados por la capacidad de poder mod
elizar la aplicabilidad de nuevos sistemas. Un
ejemplo de ello, es la aplicacin de los sistemas
expertos.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
FIGURA 3.1 Modelo relacional de una tabla
TIPOS DE ARCHIVO
Los archivos pueden clasificarse en cuatro tipos bsicos; que son: los archivos ma
estros, los archivos de transacciones, los archivos de control y los archivos d
e planeamiento. Esta clasificacin depender de la relacin lgica que tengan que tener
los datos, para dar apoyo a la actividad de la organizacin.
ARCHIVO MAESTRO
Un archivo maestro es un conjunto de registros que se refieren a algn aspecto imp
ortante de las actividades de una organizacin, como por ejemplo el archivo de VEN
DEDORES. Un archivo maestro tambin puede reflejar la historia de los eventos que
afectan a una entidad determinada, como es en el caso de un archivo HISTRICO DE V
ENTAS. Otros ejemplos son los archivos maestros de: PLAN DE CUENTAS; BANCOS, NMI
NA DEL PERSONAL, CLIENTES, VENDEDORES, PRODUCTOS, PROVEEDORES, COMPETIDORES.
ARCHIVO DE TRANSACCIONES.
Un archivo de transacciones es un archivo temporal que persigue bsicamente dos p
ropsitos; uno es el de acumular datos de eventos en el momento que ocurran, y el
segundo propsito es el de actualizar los archivos maestros para reflejar los resu
ltados de las transacciones actuales. En otras palabras, guardan informacin sobre
los eventos que afectan a la organizacin y sobre los cuales se calculan datos;
como es en el caso de los archivos de VENTAS, ORDENES DE PRODUCCIN o
PAGO DE
SALARIOS. Otros ejemplos de archivos de transacciones son los archivos de: REGIS
TROS CONTABLES, COSTOS, FACTURAS, PAGOS A RECIBIR, PROCESOS DE EXPORTACIN, CONSUL
TA DE CLIENTES, PEDIDOS DE CLIENTES Y PEDIDOS A PROVEEDORES.
ARCHIVOS DE CONTROL.
Los archivos de control contienen datos de los archivos maestros y de transaccio
nes, para permitir el anlisis del desempeo de la organizacin. Estos archivosgeneran
medidas de control de los negocios, como ser el VOLUMEN DE VENTA POR PRODUCTO,
VOLUMEN DE VENTA POR VENDEDOR, VOLUMEN DE VENTA POR CLIENTE, COMPRAS POR PROVEED
OR, COSTO DE REPOSICIN.
ARCHIVO DE PLANEAMIENTO.
Los archivos de planeamiento, contienen datos referentes a los niveles esperados
de los datos existentes en los archivos maestros y de transacciones; como por e
jemplo: PROGRAMA DE VENTAS, PROGRAMA DE COMPRAS, PROGRAMA DE PRODUCC
IN; PRESUPUESTO
FINANCIERO. Por lo tanto los datos existentes en un archivo de planeamiento pro
vienen de los archivos maestros, de transacciones, y de control.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Definir las caractersticas fsicas de cada dato, como el tipo el dominio; la organi
zacin de cada archivo, como la definicin de las llaves principales, ndices, etc. (v
er 3. Base de datos, 3.1.2. llave primaria, 3.1.3 ndices de acceso).
Especificar los mdulos.
La especificacin de los mdulos, a travs de pseudo cdigo flujogramas u otros (ver.4.5
. Flujogramas).
umento no previsto del 60 %, en la emisin de rdenes de compra. Las fallas tambin p
ueden provenir de otros factores, como ser en el caso de que existan cambios en
las expectativas de los usuarios.
La Modificacin del programa; involucra algo ms que un simple cambio en el programa
; involucra un cambio estructural de una entidad Por ejemplo, un cambio en el nme
ro de dgitos del cdigo postal, o en el cdigo de zona telefnica. La diferencia con el
Mantenimiento es el grado de importancia
El Mejoramiento del sistema; es el agregado de capacidades que no formaron parte
del sistema de informacin original; por ejemplo cuando en una divisin se implemen
t un sistema de inventarios, este sistema no inclua un modulo para calcular la fut
ura demanda de bienes y partes. La inclusin de este sofisticado mdulo de clculo es
considerado un mejoramiento del sistema.
El Reemplazo del sistema; ocurre cuando los sistemas de informacin se tornan fsica
mente, tecnolgicamente o competitivamente obsoletos. Como es el caso de la utiliz
acin del lser, en el reconocimiento ptico de caracteres p
La Nueva Capacidad del sistema; son sistemas de informacin para los cuales no es
necesario el uso de la automatizacin. Estn dados por la capacidad de poder mod
elizar la aplicabilidad de nuevos sistemas. Un
ejemplo de ello, es la aplicacin de los sistemas
expertos.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
En la introduccin del Libro describimos que en los Proyectos Informticos, desarrol
lados por profesionales de administracin en pequeas y medianas empresas, el profes
ional se encuentra con una gran dificultad en la utilizacin de las metodologas.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
ARCHIVO DE TRANSACCIONES.
Un archivo de transacciones es un archivo temporal que persigue bsicamente dos p
ropsitos; uno es el de acumular datos de eventos en el momento que ocurran, y el
segundo propsito es el de actualizar los archivos maestros para reflejar los resu
ltados de las transacciones actuales. En otras palabras, guardan informacin sobre
los eventos que afectan a la organizacin y sobre los cuales se calculan datos;
como es en el caso de los archivos de VENTAS, ORDENES DE PRODUCCIN o
PAGO DE
SALARIOS. Otros ejemplos de archivos de transacciones son los archivos de: REGIS
TROS CONTABLES, COSTOS, FACTURAS, PAGOS A RECIBIR, PROCESOS DE EXPORTACIN, CONSUL
TA DE CLIENTES, PEDIDOS DE CLIENTES Y PEDIDOS A PROVEEDORES.
ARCHIVOS DE CONTROL.
Los archivos de control contienen datos de los archivos maestros y de transaccio
nes, para permitir el anlisis del desempeo de la organizacin. Estos archivosgeneran
medidas de control de los negocios, como ser el VOLUMEN DE VENTA POR PRODUCTO,
VOLUMEN DE VENTA POR VENDEDOR, VOLUMEN DE VENTA POR CLIENTE, COMPRAS POR PROVEED
OR, COSTO DE REPOSICIN.
ARCHIVO DE PLANEAMIENTO.
Los archivos de planeamiento, contienen datos referentes a los niveles esperados
de los datos existentes en los archivos maestros y de transacciones; como por e
jemplo: PROGRAMA DE VENTAS, PROGRAMA DE COMPRAS, PROGRAMA DE PRODUCC
IN; PRESUPUESTO
FINANCIERO. Por lo tanto los datos existentes en un archivo de planeamiento pro
vienen de los archivos maestros, de transacciones, y de control.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
FIGURA 3.1 Modelo relacional de una tabla
TIPOS DE ARCHIVO
Los archivos pueden clasificarse en cuatro tipos bsicos; que son: los archivos ma
estros, los archivos de transacciones, los archivos de control y los archivos d
e planeamiento. Esta clasificacin depender de la relacin lgica que tengan que tener
los datos, para dar apoyo a la actividad de la organizacin.
ARCHIVO MAESTRO
Un archivo maestro es un conjunto de registros que se refieren a algn aspecto imp
ortante de las actividades de una organizacin, como por ejemplo el archivo de VEN
DEDORES. Un archivo maestro tambin puede reflejar la historia de los eventos que
afectan a una entidad determinada, como es en el caso de un archivo HISTRICO DE V
ENTAS. Otros ejemplos son los archivos maestros de: PLAN DE CUENTAS; BANCOS, NMI
NA DEL PERSONAL, CLIENTES, VENDEDORES, PRODUCTOS, PROVEEDORES, COMPETIDORES.
ARCHIVO DE TRANSACCIONES.
Un archivo de transacciones es un archivo temporal que persigue bsicamente dos p
ropsitos; uno es el de acumular datos de eventos en el momento que ocurran, y el
segundo propsito es el de actualizar los archivos maestros para reflejar los resu
ltados de las transacciones actuales. En otras palabras, guardan informacin sobre
los eventos que afectan a la organizacin y sobre los cuales se calculan datos;
como es en el caso de los archivos de VENTAS, ORDENES DE PRODUCCIN o
PAGO DE
SALARIOS. Otros ejemplos de archivos de transacciones son los archivos de: REGIS
TROS CONTABLES, COSTOS, FACTURAS, PAGOS A RECIBIR, PROCESOS DE EXPORTACIN, CONSUL
TA DE CLIENTES, PEDIDOS DE CLIENTES Y PEDIDOS A PROVEEDORES.
ARCHIVOS DE CONTROL.
Los archivos de control contienen datos de los archivos maestros y de transaccio
nes, para permitir el anlisis del desempeo de la organizacin. Estos archivosgeneran
medidas de control de los negocios, como ser el VOLUMEN DE VENTA POR PRODUCTO,
VOLUMEN DE VENTA POR VENDEDOR, VOLUMEN DE VENTA POR CLIENTE, COMPRAS POR PROVEED
OR, COSTO DE REPOSICIN.
ARCHIVO DE PLANEAMIENTO.
Los archivos de planeamiento, contienen datos referentes a los niveles esperados
de los datos existentes en los archivos maestros y de transacciones; como por e
jemplo: PROGRAMA DE VENTAS, PROGRAMA DE COMPRAS, PROGRAMA DE PRODUCC
IN; PRESUPUESTO
FINANCIERO. Por lo tanto los datos existentes en un archivo de planeamiento pro
vienen de los archivos maestros, de transacciones, y de control.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
La red se define desarrollando una lista de todas las tareas asociadas con el pr
oyecto especfico, y una lista de secuenciamietos, que indica en qu
orden deben realizarse las tareas.
lo de proyectos informtico. Ambas
La Tcnica de Evaluacin y Revisin de Programas (Program Evaluamino Crtico y al diagr
ama de Gantt.
La Tcnica de Evaluacin y Revisin de Programas (Program Evaluation and Review Techn
ique-PERT) y el mtodo del Camino Crtico (Critical Path Method-CPM) son dos mtodos d
e planificacin temporal de proyectos que pueden aplicarse al desarrollo de proyec
tos informtico. Ambas tcnicas desarrollan una descripcin de la red de tareas del pr
oyecto, es decir, una representacin grfica o tabular de las tareas que deben reali
zarse desde el principio hasta el final del proyecto.
La red se define desarrollando una lista de todas las tareas asociadas con el pr
oyecto especfico, y una lista de secuenciamietos, que indica en qu
orden deben realizarse las tareas.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
Figura 4.2.2. Simbolog a del DFD Metodo Yourdon
1. Las, Entidades externas, que pueden representar a una persona, a un grup
o de personas o, a un sistema; Un ejemplo respectivo para cara cada uno de ello
s sera Gerente Financiero, Clientes y un sistema de liquidacin de sueldos y jornal
es.
En s, las entidades externas, muestran a las entidades con las cuales el sistema
se comunica y por lo tanto no forman parte del sistema en estudios; pues lo que
ocurre en estas entidades no es de inters para el proyecto. Si as lo fuera, esto
est indicando que la frontera del sistema, es ms amplia de lo que se determin; y lo
s procesos involucrados en esta entidad, deben pasar a ser parte del sistema en
estudio.
Las entidades externas son consideradas tambin como Terminadores, pues representa
n el origen y el destino de los Flujos de datos para adentro y para fuera del si
stema.
Son representadas por medio de un cuadrado, que puede tener un sombreado en dos
de sus lados para otorgarle un relieve (ver figura 4.2.2). Y en el centro del c
uadrado se escribe el nombre de la entidad externa que est
siendo representada.
Cuando una entidad externa provee datos al sistema, debe existir un flujo de dat
os saliendo de la entidad y en direccin al sistema. Y cuando una entidad externa
recibe datos del sistema, debe existir un flujo de datos que viene del sistema y
termina en la entidad externa.
Las entidades externa pueden duplicarse, si fuese necesario darle claridad al di
seo y evitar largos vectores, que representan a los flujos de datos, o bien evita
r gran cantidad de entrecurzamientos de los mismos.
2.-Los flujos de datos son representados por vectores direccionados. Ellos son l
as conexiones entre los distintos elementos del sistema y los procesos; y repres
entan a la informacin que los procesos exigen como entrada y/o las informaciones
que ellos generan como salida. Los flujos pueden representar a una informacin com
puesta por un solo elemento como por ejemplo: precio, cantidad, Apellido; o bien
pueden representar a una informacin que contiene una estructura de elementos com
o por ejemplo: Orden de compra, Remito, Factura.
3.- Los procesos se pueden mostrar como burbujas, o como rectngulos con sus vrtice
s redondeados; segn sea la metodologa para modelar los procesos de Yourdon o la de
Gane & Sarson; en el diagrama ellos representan las diversas funciones indivi
duales que el sistema ejecuta; Estas funciones son las que transforman a las ent
radas en salidas. El proceso es nominado en funcin de la accin que realiza sin esp
ecificar el algoritmo utilizado para la transformacin. Este algoritmo debe ser de
tallado en el diccionario de datos (ver 4.3. Diccionario de datos) o esquematiza
do en un flujograma (ver 4.5. flujograma)
4.- Los archivos de datos son mostrados por dos lneas paralelas segn la metodologa
de Yourdon.; o como un rectngulo abierto por uno de sus lados en la metodologa de
Gane & Sarson. Ellos muestran la coleccin de datos que el sistema debe mantener e
n la memoria en un perodo de tiempo. Al terminar el diseo del sistema y la constru
ccin del mismo, los archivos sern las tablas que compongan la base de datos.
RESTRICCIONES DEL DFD.
Como regla general, en un DFD, loa tratamiento de errores y de excepciones no de
ben ser representados; a menos que estos sean muy relevantes para los usuarios d
el sistema. El DFD debe ser visto como una herramienta de planeamiento del siste
ma, y no como una especificacin detallada del sistema. Su finalidad es mostrar el
flujo normal de datos entre los principales elementos, y no los detalles de imp
lantacin del sistema.
Lo que queremos decir es que, el diagrama de flujo de datos ofrece una visin g
eneral y prctica de los principales componentes funcionales del sistema, pero no
provee detalles sobre esos componentes. Para mostrar los detalles de qu informacin
es procesada y cmo es transformada, precisamos de una herramienta de soporte de
modelizacin textual y una de ellas es el diccionario de datos (ver 4.3.el diccion
ario de datos).
El DFD Tampoco provee ninguna indicacin explcita de la secuencia del procesamiento
. El procesamiento o la secuencia puede estar implcitamente en el diagrama, pero
la representacin procedimental, de cuando inicia y finaliza cada proceso quedar ex
plcita en el flujograma.( ver 4.5. flujograma)
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
En la introduccin del Libro describimos que en los Proyectos Informticos, desarrol
lados por profesionales de administracin en pequeas y medianas empresas, el profes
ional se encuentra con una gran dificultad en la utilizacin de las metodologas.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
MATERIA, pero que precisa existir en el archivo PROFESOR para permitir la RELACIN
entre ambos. Note que en esta relacin, un PROFESOR puede dictar solamente una MA
TERIA, tal cual se observa en la figura 4.4.7.
Otra alternativa de relacionar a los archivos PROFESOR y MATERIA sera si admitimo
s que una materia solamente puede ser dictada por un profesor, esto significa qu
e debemos incluir la llave fornea "Nmero del profesor" en el archivo MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Definir las caractersticas fsicas de cada dato, como el tipo el dominio; la organi
zacin de cada archivo, como la definicin de las llaves principales, ndices, etc. (v
er 3. Base de datos, 3.1.2. llave primaria, 3.1.3 ndices de acceso).
Especificar los mdulos.
La especificacin de los mdulos, a travs de pseudo cdigo flujogramas u otros (ver.4.5
. Flujogramas).
umento no previsto del 60 %, en la emisin de rdenes de compra. Las fallas tambin p
ueden provenir de otros factores, como ser en el caso de que existan cambios en
las expectativas de los usuarios.
La Modificacin del programa; involucra algo ms que un simple cambio en el programa
; involucra un cambio estructural de una entidad Por ejemplo, un cambio en el nme
ro de dgitos del cdigo postal, o en el cdigo de zona telefnica. La diferencia con el
Mantenimiento es el grado de importancia
El Mejoramiento del sistema; es el agregado de capacidades que no f
INICIO DE UN PROYECTO NFORMTICO
En un entorno informtico estable, la decisin de iniciar un proyecto viene dada por
las necesidades de: mantenimiento, modificacin, mejoramiento, reemplazo o capaci
dad; encuadrndose as, el proyecto informtico, dentro de una categora de complejidad
mostrada en la figura 1.2:
El Mantenimiento del programa; es una consecuencia de una omisin realizada en la
etapa del diseo del sistema e involucra solucionar fallas menores del sistema,
que obligar a la realizacin de cambios en el programa; como por ejemplo el descuid
o de no considerar que puedan ocurrir en el sistema, ciertas condiciones extraor
dinarias; como sera el caso de un a
INICIO DE UN PROYECTO NFORMTICO
En un entorno informtico estable, la decisin de iniciar un proyecto viene dada por
las necesidades de: mantenimiento, modificacin, mejoramiento, reemplazo o capaci
dad; encuadrndose as, el proyecto informtico, dentro de una categora de complejidad
mostrada en la figura 1.2:
El Mantenimiento del programa; es una consecuencia de una omisin realizada en la
etapa del diseo del sistema e involucra solucionar fallas menores del sistema,
que obligar a la realizacin de cambios en el programa; como por ejemplo el descuid
o de no considerar que puedan ocurrir en el sistema, ciertas condiciones extraor
dinarias; como sera el caso de un aumento no previsto del 60 %, en la emisin de rd
enes de compra. Las fallas tambin pueden provenir de otros factores, como ser en
el caso de que existan cambios en las expectativas de los usuarios.
La Modificacin del programa; involucra algo ms que un simple cambio en el programa
; involucra un cambio estructural de una entidad Por ejemplo, un cambio en el nme
ro de dgitos del cdigo postal, o en el cdigo de zona telefnica. La diferencia con el
Mantenimiento es el grado de importancia
El Mejoramiento del sistema; es el agregado de capacidades que no formaron parte
del sistema de informacin original; por ejemplo cuando en una divisin se implemen
t un sistema de inventarios, este sistema no inclua un modulo para calcular la fut
ura demanda de bienes y partes. La inclusin de este sofisticado mdulo de clculo es
considerado un mejoramiento del sistema.
El Reemplazo del sistema; ocurre cuando los sistemas de informacin se tornan fsica
mente, tecnolgicamente o competitivamente obsoletos. Como es el caso de la utiliz
acin del lser, en el reconocimiento ptico de caracteres para la lectura del cdigo d
e barras, remplazando a la entrada por teclado.
La Nueva Capacidad del sistema; son sistemas de informacin para los cuales no es
necesario el uso de la automatizacin. Estn dados por la capacidad de poder mod
elizar la aplicabilidad de nuevos sistemas. Un
ejemplo de ello, es la aplicacin de los sistemas
expertos.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Definir las caractersticas fsicas de cada dato, como el tipo el dominio; la organi
zacin de cada archivo, como la definicin de las llaves principales, ndices, etc. (v
er 3. Base de datos, 3.1.2. llave primaria, 3.1.3 ndices de acceso).
Especificar los mdulos.
La especificacin de los mdulos, a travs de pseudo cdigo flujogramas u otros (ver.4.5
. Flujogramas).
umento no previsto del 60 %, en la emisin de rdenes de compra. Las fallas tambin p
ueden provenir de otros factores, como ser en el caso de que existan cambios en
las expectativas de los usuarios.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
FIGURA2,3. ANLISIS DE FLUJO DE FONDOS
CONSIDERACIONES EN UN PLAN ESTRATGICO INFORMTICO
Bien, nuevamente concentrando nuestra atencin en los proyectos informticos. Tenemo
s que en el proceso de planeamiento, de un sistema de informacin, se debe determi
nar:
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
Figura 4.2.2. Simbolog a del DFD Metodo Yourdon
1. Las, Entidades externas, que pueden representar a una persona, a un grup
o de personas o, a un sistema; Un ejemplo respectivo para cara cada uno de ello
s sera Gerente Financiero, Clientes y un sistema de liquidacin de sueldos y jornal
es.
En s, las entidades externas, muestran a las entidades con las cuales el sistema
se comunica y por lo tanto no forman parte del sistema en estudios; pues lo que
ocurre en estas entidades no es de inters para el proyecto. Si as lo fuera, esto
est indicando que la frontera del sistema, es ms amplia de lo que se determin; y lo
s procesos involucrados en esta entidad, deben pasar a ser parte del sistema en
estudio.
Las entidades externas son consideradas tambin como Terminadores, pues representa
n el origen y el destino de los Flujos de datos para adentro y para fuera del si
stema.
Son representadas por medio de un cuadrado, que puede tener un sombreado en dos
de sus lados para otorgarle un relieve (ver figura 4.2.2). Y en el centro del c
uadrado se escribe el nombre de la entidad externa que est
siendo representada.
Cuando una entidad externa provee datos al sistema, debe existir un flujo de dat
os saliendo de la entidad y en direccin al sistema. Y cuando una entidad externa
recibe datos del sistema, debe existir un flujo de datos que viene del sistema y
termina en la entidad externa.
Las entidades externa pueden duplicarse, si fuese necesario darle claridad al di
seo y evitar largos vectores, que representan a los flujos de datos, o bien evita
r gran cantidad de entrecurzamientos de los mismos.
2.-Los flujos de datos son representados por vectores direccionados. Ellos son l
as conexiones entre los distintos elementos del sistema y los procesos; y repres
entan a la informacin que los procesos exigen como entrada y/o las informaciones
que ellos generan como salida. Los flujos pueden representar a una informacin com
puesta por un solo elemento como por ejemplo: precio, cantidad, Apellido; o bien
pueden representar a una informacin que contiene una estructura de elementos com
o por ejemplo: Orden de compra, Remito, Factura.
3.- Los procesos se pueden mostrar como burbujas, o como rectngulos con sus vrtice
s redondeados; segn sea la metodologa para modelar los procesos de Yourdon o la de
Gane & Sarson; en el diagrama ellos representan las diversas funciones indivi
duales que el sistema ejecuta; Estas funciones son las que transforman a las ent
radas en salidas. El proceso es nominado en funcin de la accin que realiza sin esp
ecificar el algoritmo utilizado para la transformacin. Este algoritmo debe ser de
tallado en el diccionario de datos (ver 4.3. Diccionario de datos) o esquematiza
do en un flujograma (ver 4.5. flujograma)
4.- Los archivos de datos son mostrados por dos lneas paralelas segn la metodologa
de Yourdon.; o como un rectngulo abierto por uno de sus lados en la metodologa de
Gane & Sarson. Ellos muestran la coleccin de datos que el sistema debe mantener e
n la memoria en un perodo de tiempo. Al terminar el diseo del sistema y la constru
ccin del mismo, los archivos sern las tablas que compongan la base de datos.
RESTRICCIONES DEL DFD.
Como regla general, en un DFD, loa tratamiento de errores y de excepciones no de
ben ser representados; a menos que estos sean muy relevantes para los usuarios d
el sistema. El DFD debe ser visto como una herramienta de planeamiento del siste
ma, y no como una especificacin detallada del sistema. Su finalidad es mostrar el
flujo normal de datos entre los principales elementos, y no los detalles de imp
lantacin del sistema.
Lo que queremos decir es que, el diagrama de flujo de datos ofrece una visin g
eneral y prctica de los principales componentes funcionales del sistema, pero no
provee detalles sobre esos componentes. Para mostrar los detalles de qu informacin
es procesada y cmo es transformada, precisamos de una herramienta de soporte de
modelizacin textual y una de ellas es el diccionario de datos (ver 4.3.el diccion
ario de datos).
El DFD Tampoco provee ninguna indicacin explcita de la secuencia del procesamiento
. El procesamiento o la secuencia puede estar implcitamente en el diagrama, pero
la representacin procedimental, de cuando inicia y finaliza cada proceso quedar ex
plcita en el flujograma.( ver 4.5. flujograma)
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.8.Relacin uno varios cuando una materia es dictada por uno o varios pr
ofesores
En este caso, una materia puede ser dictada por uno o varios profesores (1,N),
pero un profesor solamente puede dictar una nica materia (1,1).
En el ejemplo ilustrado por la Fig. 4.4.9., muestra la relacin entre un PROFESOR
y varias MATERIAS, el atributo "Nmero del profesor" es la llave fornea de MATERIA.
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
para resolver la gran mayora de casos. Es por ello que definiremos a continuacin l
as tres primeras formas normales y discutiremos la manera de simplificar los arc
hivos de datos hasta la tercera forma normal. Se podra resumir a estas tres forma
s normales mas utilizadas, de la siguiente manera:
Eliminar campos repetitivos; Eliminar datos redundantes; Eliminar atributos no d
ependientes.
Adems la 1FN, 2FN y la 3FN son mecanismos para identificar entidades y relaciones
perdidas.
PRIMERA FORMA NORMAL (1FN).
Asegurar que todas las entidades son identificadas de forma nica por una combinac
in de atributos y/o relaciones.
Se refiere a cualquier archivo que posea un valor por campo; la relacin entre la
llave primaria de un archivo y cada uno de los otros campos debe ser de uno a un
o.
De una manera prctica, debemos eliminar grupos repetidos de datos, hasta que cada
dato tenga una llave primaria para cada ocurrencia.
El archivo de datos ejemplificado a continuacin no est normalizado; entre otras co
sas, hay mas de un valor o supermercado en cada campo de Negocio.
Producto Negocio
Arroz Coto, Disco, Carrefour, Jumbo
Poroto Coto, Macro, Carrefour, Jumbo
Harina Coto, Macro, Carrefour
Azcar Ta, Disco, Carrefour
Como puede percibirse, en el campo Negocio existen varios valores de datos (grup
os repetidos). A travs de este archivo podemos obtener la informacin de que existe
, por ejemplo, arroz en los supermercados Coto, Ta, Disco, Carrefour, Jumbo. Mien
tras tanto cmo podramos llegar a saber la cantidad existente de cada uno de los pro
ductos, en cada uno de los negocio?.
De acuerdo con la primera forma normal este archivo debe ser revisado para que s
ean eliminados los grupos repetidos, o sea, en el campo Negocio debe existir el
nombre de apenas un supermercado. Esto implicar, la creacin de un nmero mayor de fi
las o registros en el archivo. Pues deber haber una fila para cada producto en
cada negocio. A partir de esto, podremos fcilmente registrar la cantidad existent
e de cada producto en cada negocio.
Despus de la aplicacin de la primera regla de normalizacin, el archivo de datos de
los productos en Stock asume la siguiente estructura de datos:
Producto Negocio Telfono Cantidad Precio Total
ARROZ Coto 670-1158 200 10 2000
ARROZ Disco 923-3951 500 9 4500
ARROZ Carrefour 921-4802 700 11 7700
ARROZ Jumbo 342-6400 1000 8 8000
POROTO Coto 670-1158 300 13 3900
POROTO Macro 923-4377 500 12 6000
POROTO Carrefour 921-4802 200 14 2800
POROTO Jumbo 342-6400 400 8 3200
HARINA Coto 670-1158 400 8 3200
HARINA Macro 923-4377 600 9 5400
HARINA Carrefour 921-4802 100 7 700
AZUCAR Disco 923-3951 1100 4 4400
AZUCAR Carrefour 921-4802 900 5 4500
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
En la introduccin del Libro describimos que en los Proyectos Informticos, desarrol
lados por profesionales de administracin en pequeas y medianas empresas, el profes
ional se encuentra con una gran dificultad en la utilizacin de las metodologas.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
$ El dinero.
La herramienta principal para la planificacin de recursos es el presupuesto; y st
e se compone de la asignacin de responsabilidades para generar y utilizar el din
ero, y del calendario para hacerlo.
PLANIFICACIN FINANCIERA
Vimos que un proyecto involucra tareas y recursos; por lo tanto, en la planifica
cin son tan importantes las tareas como los recursos disponibles.
Al momento de asignar los recursos, debe tener en cuenta algunas consideraciones
como: la simultaneidad de tareas para un mismo recurso, la importancia de cada
tarea, si es una actividad crtica o no.
Lo importante es que una vez que fueron identificados los recursos para cada tar
ea, se deben realizar los siguientes anlisis:
De Costo;
De Beneficio; De Riesgo;
De Sensibilidad.
Es importante considerar que la utilidad de los modelos financieros, aumenta cua
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y de una gr
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs de lo
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran valor e
n el proceso de planificacin
Entre tantas condiciones comerciales, en la que se puede estimar la
sensibilidad, podemos citar:
La tasa de inters bancaria; El costo del dinero accionario; El ndice de inflacin.
001
002
003 Inca Tel
Infocad
Herrera Compusistem 4923-4803
4633-2520
4232-7711 Av. La Plata 365
Doblas 1578
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS
Cdigo proveedor Cdigo del artculo Precio
001
002
003
002
001 1.01.01
1.01.01
1.01.01
2.01.01
4.01.03 70,00
80,00
75,00
50
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el archivo de PROD
UCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el archivo PR
OVEEDORES y;
Datos sobre el origen de los productos (Entidad origen del producto), o sea
, los productos son provistos por cada proveedor y viceversa, almacenados en el
archivo de ORIGEN DEL PRODUCTO.
La informacin almacenada en cada uno de estos archivos se conoce con el nombre de
Entidad. Por lo tanto una entidad es cualquier persona, cosa o evento, real o i
maginario, de inters para la organizacin y acerca del cual se capturan, almacenan
o procesan datos.
Adems, cada uno de estos archivos est formado por un conjunto de registros que des
cribe, a travs de los atributos o datos (columna), cada entidad en l almacenado. U
n atributo es pues, cualquier detalle que sirve para identificar, clasificar, cu
antificar o expresar el estado de una entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, po
seen el mismo formato, o sea tienen el mismo conjunto de datos o atributos, iden
tificados por las columnas, que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenado
s en los campos de cada atributo; y cada registro debe contener el conjunto de
atributos necesarios, para describir completamente cada entidad sobre la cual un
a organizacin necesita almacenar y obtener informacin.
MODELOS CONCEPTUALES
Un modelo es una descripcin capaz de ser comunicada y que busca: Comunicar un cie
rto aspecto (visin),
de una parte de la realidad (sistema), con cierto grado de detalle (abstraccin),
conforme perseguido por alguien (autor del modelo), con el objetivo de servir a
los propsitos del usuario.
Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar u
n modelo mental que represente esta cosa, como as tambin las aciones que ella pued
e realizar o se pueden realizar sobre ella. Cuando el individuo verifica accione
s sobre este modelo l puede predecir las implicaciones que estas acciones tendrn s
obre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobr
e ellas, podremos describir el funcionamiento de un sistema, y esto debera ser el
propsito de todo modelo.
Los modelos pueden tener diferentes clases de estructuras; pero las clases ms com
unes son: la verbal, la simblica y la matemtica.
En los modelos verbales, las variables y sus relaciones se funden en forma de
prosa. El manual de procedimientos, el manual de organizacin o la Lista de evento
s, que describiremos prximamente (ver 4.2.1. la modelizacin de las funciones del s
istema), son ejemplos de modelos verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos repres
entan un puente til en el proceso de simbolizar un modelo verbal; por ejemplo,
sera muy conveniente que en un manual de organizacin se incluya un organigrama (e
squema para modelizar la estructura de la empresa). La mayora de los modelos s
imblicos se usan para aislar variables y sugerir las direcciones de las relacion
es, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y
el Modelo Relacional de Datos, pero pocos se disean para dar resultados numricos e
specficos. El mayor beneficio de los modelos simblicos est en la representacin grfica
de los hechos a travs de cuadros o nodos; y es as que el fenmeno se despoja de lo
que no es esencial, permitiendo al investigador (observador) entender el conjunt
o y seleccionar las relaciones a examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo lo
s flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carc
ter cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy ex
actos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de d
eterminar su valides; y estos tienen bsicamente dos formas de ser probados, una e
s la forma prospectiva (contra el desempeo futuro), y la otra es de forma es retr
ospectiva (contra el desempeo pasado); en ste ltimo caso, o sea si un modelo se pru
eba retrospectivamente, es de vital importancia que los periodos utilizados cubr
an las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospecti
va, el anlisis de su sensibilidad al error puede servir de base para evaluarlo. D
icho anlisis consiste en determinar cunto tienen que bajar los valores de las vari
ables del modelo para que los medios mejores especificados en dicho modelo teng
an un desempeo inferior al de un medio alternativo. Despus, utilizando el juicio s
obre la posibilidad de esta baja, se puede hacer una evaluacin parcial del modelo
.
Adems de su utilidad para evaluar medios; los modelos se pueden utilizar heurstica
mente, es decir, para facilitar el descubrimiento. Con frecuencia son
un medio efectivo para explorar la estructura asumida de una situacin determinada
, y para descubrir posibles cursos de accin que de otra manera se pasaran por alto
.
LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
LISTA DE EVENTOS.
Las primeras actividades de diseo de los sistemas (ver cap1.1 que es un PI y 1.2
inicio de un PI), estn especialmente influenciadas por la naturaleza de los reque
rimientos y stos incluyen principalmente descripciones en lenguaje natural, que s
egn lo visto en el tpico anterior (4.1.); representan una realidad dada e interpr
etada de diferentes maneras segn sea la visin y la capacidad de abstraccin, 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 anlisis profundo del texto par
a poder entender en detalle el o los significados de todos los trminos involucr
ados en el proyecto (libres de contradicciones e incongruencias). Luego esta lis
ta estructurada, en el diseo inicial, ser la base para la construccin de las entida
des y sus relaciones; y que estarn representadas en los diagramas de flujo de dat
os y en el modelo relacional de datos.
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
A continuacin presentamos una lista de reglas empricas que ayudarn a la construccin,
en forma estructurada, de la lista de eventos.
Elegir el nivel apropiado de abstraccin para los trminos.
Se debe preferir, la utilizacin de, palabras concretas a palabras abstractas. Las
palabras concretas se refieren a objetos o sujetos tangibles; el lector las pue
de descifrar fcilmente, porque se hace una clara imagen de ellas asocindolas
a la realidad. En cambio, las palabra
s abstractas designan conceptos o cualidades ms difusos, y suelen abarcar un nmero
mayor de acepciones. El lector necesita ms tiempo y esfuerzo para captar su sent
ido, pues no hay referentes reales. Por lo tanto es muy importante el escoger la
acepcin ms apropiada, entre las diversas alternat
ivas posibles. Por ejemplo veamos los siguient
es trminos: El gerente del rea de finanzas, es quien a
utoriza las compras. Es una oracin demasiada ambigua. Su principal dificulta
d reside en el significado de compras. Al tratarse de una palabra bastante genric
a, entran en juego muchas
acepciones
Compras se refiere a: Si se considera en funcin del tiempo, se refiere a: com
pras programadas, no programadas o ambas?. Si se evala en funcin del volumen, se r
efiere a:
grandes pedidos, a pedidos pequeos o ambos?. En funcin de su origen, involucra a: la
s importaciones o las de plaza local?. Y en funcin del bien:
en insumos y/o bienes de capital?.
Cul de estos trminos es el correcto?; si el resto del texto no ofrece la informacin
necesaria para sobre la alternativa correcta; solo queda la alternativa de hacer
una hiptesis de significado genrica. Lo que significa asumir un riesgo, que obvia
mente no debera existir.
Evitar el uso de casos en lugar de conceptos generales.
Es comn observar que los usuarios de los sistemas de informacin, adoptan trminos ms
especficos de los que verdaderamente son necesarios. Por ejemplo, el encargado de
almacenes dice: "necesito conocer a diario la cantidad en existencia de pastill
as de frenos", El trmino pastillas de frenos no describe un concepto, sino una i
nstancia o componente del concepto correcto, esto es, un componente. Por lo tant
o el trmino debera ser insumos.
Evitar las expresiones vagas o indirectas.
Al usar rodeos, se incurre en el riesgo de expresar el significado de los concep
tos en trminos de referencias implcitas a otros conceptos, en lugar de referencias
explcitas a los mismos conceptos. Por ejemplo cuando se dice: "mir el repuesto
en la cajonera", en vez de decir; "mir las cajoneras". La segunda oracin indica un
a clase especfica de entidad (cajonera), mientras que la primera se refiere a la
misma clase indicando una interrelacin con otra clase de entidad (repuesto). Es
as que la segunda oracin, "mir las cajoneras", permite una clara clasificacin de los
conceptos.
Elegir un estilo estandarizado de enunciado.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena y eficaz
. Idealmente, se debe buscar elaborar enunciados que respondan a algn estilo estnd
ar, en el caso de las descripciones de los datos, stas deben ser frases afirmativ
as, 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 elementos-llave pueden estar acompaados de otras palabras como artculos, a
djetivos, etc.; por ejemplo:
El encargado del sector ALMACENES verifica el PARTE DE RECEPCIN
con la SOLICITUD DE COMPRA
Generar la siguiente estructura-llave:
ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE COMPRA
Donde ALMACENES es el sujeto, verifica es el verbo, PARTE DE RECEPCIN es el objet
o y SOLICITUD DE COMPRA es el instrumento.
Considere que una frase puede estar incompleta; Por ejemplo: ALMACENES emite SOL
ICITUD DE COMPRA
En ella no hay complemento.
Tambin es importante que los enunciados que describen operaciones deben utilizar,
tanto como les sea posible, estructuras sintcticas no ambiguas (PRODUCTOS, en LI
STA DE PRODUCTOS o en STOCK), similares a las de los lenguajes de programacin, co
mo si, condicin, entonces, sino, cuando, hacer, accin. Por ejemplo: Si el monto es
menor a 100 aprueba el pedido, sino eleva el pedido a Gerencia Financiera.
Verificar los sinnimos y los homnimos.
Distintas personas pueden dar el mismo significado a diferentes cosas (sinnimo) o
diferentes significados con las mismas palabras (homnimos). En un procedimiento
de ventas pueden encontrarse los siguientes trminos: Cliente, comprador, usuario
, parroquiano, y referirse al mismo concepto (sinnimos) En el caso de que el mism
o trmino sea utilizado, en diferentes lugares, con significados diferentes es con
siderado pues un homnimo. Por ejemplo Para finanzas el cliente es quien compra un
producto, mientras que para Marketing el cliente, o potencial cliente, es el us
uario del producto.
Hacer explcitas las referencias entre trminos.
Se debe evitar cometer ambigedades; es decir: frases que puedan interpretarse de
dos o ms maneras distintas. Algunas ambigedades surgen al no especificar las refer
encias entre los trminos. La ambigedad puede provocar o un doble sentido o una inc
ertidumbre.
En el caso de: Recepcin firma remito.
Cul remito firma, el original o alguna copia.
O por ejemplo: El jefe de compras se rene con cada uno de los proveedores en su d
espacho.
En qu despacho se renen, en el de compras o en el de los proveedores.
O en el caso particular de nuestros archivos, si contamos con dos archivos PRODU
CTO Y STOCK y ambos cuentan con los mismos atributos: Cdigo del producto y Nombre
del producto y, STOCK se diferencia por contar adems con el atributo Saldo del p
roducto; Lo que ocurre es que, probablemente no sean dos entidades distintas sin
o una sola entidad: PRODUCTOS EN STOCK y que debera contener a los atributos de a
mbas (ver 4.4. diseo de relacin uno a uno).
Hacer un Diccionario de Datos.
Como veremos ms adelante (ver 4.3. el diccionario de datos), ir confeccionando el
diccionario de datos, es una buena manera de entender el significado de los trmi
nos y de eliminar las ambigedades de los requerimientos. Aunque, la confeccin del
diccionario de datos, demande bastante tiempo es fundamental su elaboracin y deja
r de lado esta herramienta, no se justifica en ningn caso. Recuerde que puede uti
lizar cualquier herramienta de ingeniera de software para su construccin.
EL DIAGRAMA DE FLUJO DE DATOS
El Diagrama de Flujo de Datos (DFD) es una herramienta de modelizacin que permite
describir, de un sistema, la transformacin de entradas en salidas; el DFD tambin
es conocido con el nombre de Modelo de Procesos de Negocios (BPM, B usiness Proc
ess Model).
El objetivo del DFD es:
1. Describir el contexto del sistema, determinando lo que ocurrir en cada un
a de las reas de la empresa, denominadas Entidades externas, que participen de es
te sistema;
2. Detallar los procesos a ser realizados;
3. Enumerar los archivos de datos necesarios, en cada proceso;
4. Definir los flujos de datos, que participen en el procedimiento.
En otras palabras, el DFD permite representar de forma completa el sistema de in
formacin, al relacionar los datos almacenados en los archivos de datos del sistem
a, con los procesos que transforman a estos dados.
Una de las principales caractersticas de este modelo es su simplicidad, y se debe
al hecho que son solamente cuatro los smbolos utilizados que representan a los e
lementos (entidades externas, archivos, procesos y flujos de informacin); con los
cuales se puede producir un esquema, que alcance el nivel de detalle requerido
por el proyectista; y ste pueda ser interpretado
por todas las personas involucradas en el proyecto, sin el requerimiento de un c
onocimiento previo de informtica.
TCNICA DE DISEO DEL DFD
En el diseo de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro smb
olos :
FIGURA 4.4.9. Relacin uno a varios, una materia es dictada nicamente por un profes
or.
En este caso un profesor puede dictar una o varias materias (1,N) pero una mater
ia puede ser dictada solamente por un profesor (1,1).
Diseo de la Relacin varios a varios.
Si analizamos los ejemplos anteriores, percibimos que la relacin ms correcta entr
e PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero s lo es var
ios a varios, o sea, un profesor puede dictar muchas materias y una materia pued
e ser dictada por muchos profesores.
Una relacin (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es
posible que tanto PROFESOR como MATERIA reciban llaves forneas. En este caso, nic
amente las llaves primarias de ambos objetos relacionados (N,N) debern ser identi
ficadas y, a continuacin, un "objeto de interseccin" deber ser creado. La llave pr
imaria del objeto de interseccin ser la combinacin o concatenacin de las llaves prim
arias de los dos objetos de origen.
En el ejemplo ilustrado por la figura 4.4.10, en que un PROFESOR dicta varias m
aterias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La nica
lnea de relacin (N,N) puede ser considerada como una combinacin de dos relaciones
(1,N), ambas con un objeto de interseccin.
REGLAS
DESCRIPCIN DE CONDICIONES VALORES DE CONDICIONES
DESCRIPCIN DE ACCIONES VALORES DE ACCIONES
Una metodologa para la creacin de las tablas es la siguiente
1 Definir e interpretar el problema (cuidado con las obviedades);
2 Poner por escrito en lenguaje narrativo el planteo del problema a fin de
su corroboracin
3 Distinguir y separar las condiciones de las acciones y agruparlas respec
tivamente
4 Crear la tabla de decisiones vaca, relacionando todas las condiciones y a
cciones en la columna izquierda y enumerando las combinaciones de condiciones en
lo alto de la tabla (reglas)
5 Registrar los valores de las condiciones y de las acciones.
6 Analizar los resultados obtenidos (deteccin de omisiones redundancias con
tradicciones o ambigedades)
7 Discutir los resultados con los usuarios
MODULOS DE UN SISTEMA
Un DFD precisa ser subdividido en diferentes partes, que llamaremos mdulos, conte
niendo cada una de ellos procedimientos manuales y/o automatizadas, a fin de que
el sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de s
er implementadas controladas y manejadas. Estos mdulos pueden ser: un programa, u
n procedimiento manual o automatizado, una relacin de operaciones o comandos, o u
na combinacin de estas tres.
Un mdulo siempre ser invocado como una unidad, y generalmente ser desde una opcin de
l men; y constituye una operacin o un procedimiento completo que el sistema debe e
jecutar.
Lo normal es que los mdulos estn relacionados con las entradas y salida de
los datos, actualizacin de archivos, procedimiento de clculo y otras operaciones e
specficas que el sistema deba efectuar. Como ejemplo de mdulos presentamos los sig
uientes:
Confeccin de una NOTA DE PEDIDO Modificacin del los datos del CLIENTE Dar de baja
a un PROVEEDOR
Grabar el Archivo HISTRICO DE VENAS. Clculo del SALARIO.
Grabar una copia de seguridad de los archivos.
Como la divisin de un sistema en mdulos, se debe realizar en funcin de las relacio
nes existentes entre los procedimientos y su contexto; La misma, debe tener su o
rigen en los procesos del DFD, y en las entidades y sus relaciones definidas en
el RDM.
Si fuese decidido que determinado proceso tendr apoyo automatizado, se debe anali
zar la posibilidad y la conveniencia de su implementacin por software.
Una regla prctica :
Un proceso es candidato a ser totalmente informatizado, si todo flujo de datos q
ue en l entra o sale, se encuentra en uno de estos tres casos.
1) se conecta a un repositorio o proceso ya definido para ser implementado
por software,
2) tiene su origen en una entidad externa y puede ser transferido directame
nte par procesamiento por software sin ningn procesamiento adicional no informati
zado de sus datos
3) tiene como destino una entidad externa y puede ser a l enviado directamen
te de la salida de software, sin ningn procesamiento adicional informatizado de s
us datos.
En caso de no ser posible implementar el proceso totalmente por software, el deb
e ser explotado y revalidado continuamente, hasta que sean completamente separad
os los procesos manuales de los procesos a ser implementados por software.
Por ltimo, luego de la definicin de los mdulos, se debe asignar un nombre a cada mdu
lo (que se corresponda con el proceso definido en el DFD) y disear la relacin entr
e los mdulos.
EL RBOL DE UN SISTEMA
Los mdulos ya definidos, guardan una relacin jerrquica entre s, o sea, existen nivel
es de procesos y operaciones que sern desempaados por el sistema, desde los mas am
plios hasta los mas especficos. Y sta jerarqua de mdulos es la que da origen al rbol
del sistema.
El rbol de sistema es un organigrama, que identifica a cada uno de los mdulos y la
jerarqua existente entre ellos. Una de las funciones principales del rbol es la d
e determinar la estructura de los mens de operaciones del sistema, pues cada mdulo
, segn su nivel, dar acceso o ejecutar una determinada operacin.
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
Habiendo ya definido los principales mdulos y tambin elaborado el rbol del sistema
y como cada uno de ellos est relacionado con el DFD y con el MRD, el desarrollo y
prueba de los mismos debe ser planificado.
Normalmente, se debe producir y revisar una especificacin escrita para cada mdulo.
Esta especificacin, debe contener toda la informacin necesaria para que se pueda
producir los cdigos o programas necesarios para cada uno de los mdulos.
La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo
claro de los formatos de entradas y de salidas de datos; pues la lgica del siste
ma, los archivos a ser accedidos ya fueron definidos en el DFD y el MRD.
Si los formularios e informes del sistema fuesen generados por un generador auto
mtico (Asistente automtico), quien programe debe saber qu campos o datos aparecern e
n cada formulario e informe, y adems podr utilizar el mismo generador de formulari
os para definir la posicin exacta de cada campo.
Y que esto se debe principalmente a las exigencias y esfuerzo adicional que requ
iere la elaboracin de los modelos y , a la gran cantidad de documentacin que es ne
cesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas
CASE; estas herramientas permitirn organizar y manejar la informacin de un proyec
to informtico. Permitindole a los participantes de un proyecto, que los sistemas
(especialmente los complejos), se tornen mas flexibles, mas comprensibles y adems
mejorar la comunicacin entre los participantes.
QU ES UNA HERRAMIENTA CASE
CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software E
ngineering; y en su traduccin al Espaol significa Ingeniera de Software Asistida po
r Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarca
r esa amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asis
tida por Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cual
es se hacen tiles a las personas comprender las capacidades de las computadoras,
por medio de programas, de procedimientos y su respectiva documentacin.
Concentrando nuestra atencin en el uso de estas herramientas, para el desarrollo
de proyectos informticos que tengan como objetivo la automatizacin de procedimient
os adiministrativos; podemos decir que:
Las herramientas CASE representan una forma que permite Modelar los Procesos de
Negocios de las empresas y desarrollar los Sistemas de Informacin Gerenciales.
En la Figura 1 se muestra un Diagrama de Flujo de Datos estructuradao, utilizand
o el mtodo de Yourdon para el Modelo del Proceso.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.
Figura 5.8 Informe del Chequeo del Balanceo entre los Niveles del DFD
A partir de sta descripcin conceptual, sobre las herramientas; podemos hacer notar
que las herramientas CASE sern un elemento muy importante, que le permitir al adm
inistrador de un proyecto informtico, llevar adelante un proyecto informtico de f
orma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Inform
acin se encuentra en continua evolucin y existe adems una gran variedad de proveedo
res y productos y cada uno de ellos con sus diferentes aplicaciones y especifica
ciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se ap
lique rigurosamente una metodologa de compra, que permita evaluar tanto al softwa
re como al proveedor del mismo (PERISS-2000).
Otro elemento importante conveniente de destacar, es que las herramientas CASE,
son eso: "HERRAMIENTAS", y que como tales permiten aumentar la productividad en
el desarrollo de un proyecto y como herramientas que son, deben ser aplicadas a
una metodologa determinada.
Nunca piense que ellas le solucionarn todos sus problemas o peor que eso, que ell
as en s mismas son una metodologa; su uso est restringido a la metodologa elegida pa
ra llevar adelante el anlisis y diseo del proyecto.