Denuevo

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
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.
Figura 1.2 Categoras de los sistemas de informacin
Segn Rusell Ackoff, la esencia de la sabidura es la preocupacin por el futuro; pero

no es, la misma preocupacin que tiene el adivino por el futuro, pues l solamente
intenta preverlo; el sabio intenta controlarlo.
La planificacin consiste en disear un futuro deseable y seleccionar o crear formas

de lograrlo, hasta donde sea posible.
Por lo tanto, al planificar se construye la secuencia de tareas con la lgica nece
saria, y la asignacin de recursos necesarios para alcanzar el objetivo del proye
cto en un tiempo ptimo.
La disponibilidad de recursos, hace que la secuencia de tareas pueda variar en
el tiempo; dependiendo de los recursos con que se dispongan. Por lo tanto, al m
omento de planificar, hay que considerar, las tareas y los recursos; con el mism
o grado de importancia.(ver. 1.1 que es un proyecto informtico).
MTODOS DE PLANIFICACIN TEMPORAL DE TAREAS
La planificacin temporal de un proyecto de software, no difiere mucho de la de c
ualquier otro esfuerzo de desarrollo multitarea. Adems, se pueden utilizar las tcn
icas y herramientas generales de planificacin temporal de proyectos para el desar
rollo de software, con pequeas modificaciones; entre ellas podemos citar a la tcni
ca de Evaluacin y Revisin de Programas, el mtodo del Camino Crtico y al diagrama 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.
En el mtodo PERT/CPM se coordinan todos los elementos de un proyecto en un plan m
aestro, mediante la creacin de un modelo lgico, para lograr el mejor tiempo y con
el mnimo costo.
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.
Se estiman luego los tiempos correspondientes; y para ello se debe:
1.-establecer, con la aplicacin de modelos estadsticos, las estimaciones de tiempo
, mas probables para cada una de las tareas;
2.- luego se calculan los lmites de tiempo que definen una amplitud temporal para
cada tarea (teniendo en cuenta los recursos disponibles), y por ltimo;
3.-se halla el camino crtico, o sea el conjunto de actividades, que determina la
duracin total del proyecto y que sus atrasos o adelantos originarn atrasos o adela
ntos de iguales unidades de tiempo en la duracin total del proyecto.
Una vez establecido el camino crtico, se lo utiliza para: considerar alternativas
, elaborar la lgica del plan y precisar las estimaciones de tiempo de las activi
dades crticas, as como la influencia de limitaci ones y las posibles soluciones de
situaciones conflictivas
FIGURA 2.1. PERT Y CPM
Otra herramienta de diseo es el Diagrama de Gantt; sta es una representacin grfica c
ronolgica, de las etapas componentes de un proyecto. Este grfico se sustenta en un
a estructura de barras horizontales, en las cuales la longitud es directamente
proporcional al tiempo requerido para su ejecucin. El objetivo de este grfico es e

l de planear un proyecto y verificar el cumplimiento.
A los efectos de su confeccin, se requiere determinar.
a)
Las tareas a desarrollar
b)
La relacin o dependencia entre las tareas
c)
El tiempo Planeado para la ejecucin de cada tarea
FIGURA2.2 Diagrama de GANTT.

La utilizacin de una herramienta automatizada de administracin de proyectos, como
es el caso de Microsoft Project, le otorgar una mayor eficacia en el control del
proyecto; tambin le permitir mantener una mejor comunicacin entre los participantes
del proyecto.
MTODOS PARA PLANIFICACIN DE RECURSOS
La planificacin de recursos pretende determinar qu recursos
sern
necesarios, cundo, cmo y dnde se obtendrn los que no estn disponibles y en qu forma s
rn generados o adquiridos.
Se debe tener en cuenta cinco tipos de recursos:
$ 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
ndo se los computariza. Esto facilitar una exploracin financiera rpida, y
an cantidad de medios alternativos y/o supuestos sobre el ambiente. A travs
s anlisis de riesgo y sensibilidad. dichas exploraciones alcanzarn un gran
n el proceso de planificacin
cua
de una gr
de lo
valor e
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:
Tambin se deben considerar, los recursos necesarios especficos de
Tecnologa de la Informacin:
Fsicos
Sistema Central (Microprocesador, Memoria principal)
Perifricos
(Unidades
de
entrada,
salida; Unidades de entrada/salida)
Comunicaciones (Modem, Repetidores, Hub)
lgicos
o
o
de
o
o
etos)
o
o
o
o
o
o
o
la
Unidades
Estructuras de almacenamiento (Base de datos relacional, orientada a obj

Monitores de comunicaciones
Lenguajes ( Pascal, Cobol, C++, SQL)
Mtodos de desarrollo ( Ciclo de Vida, Prototipo, Espiral)
Control de seguridad y calidad
humanos
Seleccin
Formacin
Incentivos
El conjunto unificado de informacin, resultante de nuestro proyecto informtico y,

que ser compartida por los diferentes usuarios de la organizacin, va a conformar l
a denominada Base de Datos.
La funcin bsica de una base de datos es permitir el almacenamiento y
de la informacin necesaria, para que las personas de la organizacin
decisiones. Es as que las Bases de Datos se tornan esenciales para la
ia de cualquier organizacin; pues los datos estructurados constituyen
bsico para todas las organizaciones.
la recuperacin
puedan tomar
supervivenc
un recurso
Dependiendo de la capacidad de almacenamiento y procesamiento del hardware, la o

rganizacin puede contar con una nica Base de Datos, o con mltiples Bases de Datos.
Es comn que en las pequeas y medianas empresas
por ello tengan que distribuir su informacin en
ignndole a cada una de ellas, informacin sobre
ejemplo sera el de contar con una base de datos
rmacin correspondiente al rea financiera, otra
el rea de ventas o el rea de produccin.
se cuente con microcomputadoras, y

un conjunto de Bases de Datos; as
cada rea especfica de la empresa. Un
para el almacenamiento de la info
para el rea de personal, una ms para
Mientras tanto las Grandes organizaciones poseen computadoras de gran porte, y e

s as que pueden almacenar toda la informacin necesaria, integrada, consistente y c
onsolidada, en una nica base de datos.
Independientemente de la Base de Datos que ser implementada,
sta
necesita de un Sistema de Gestin de Base de Datos (SGBD o DBMS). Los sistemas de

Gestin de Base de datos, son programas de software para la administracin de las Ba
ses de Datos; y en particular, para: almacenar, manipular y recuperar datos en u
na computadora. El SGBD tambin se encargar de la comunicacin entre el usuario y la
base de datos, proporcionndole al usuario, los medios necesarios para poder obten
er informacin, introducir nuevos datos y actualizar los ya existentes.
ESTRUCTURA DE UNA BASE DE DATOS.
Una Base de Datos est compuesta por un conjunto de tablas o archivos. Para una ma
yor comprensin podemos ejemplificar la siguiente Base de Datos de compras.
ARCHIVO DE PRODUCTOS
Cdigo artculo Descripcin del material
1.01.01
Unidad Cantidad
1.01.02
1.02.01
2.01.01
3.01.01
4.01.01
4.01.02
4.01.03 CD-ROM RW IDE
Disco rgido ATA 66
Disco Flexible de 3 1/2" 1,44 Mbytes
Sonido de 16 bit
Papel carta para impresora. Pentium II 200Mhz
Pentium III 500Mhz
Pentium III 800Mhz
Resma 100 hojas
Unidad Unidad Unidad
20
20
5
25
7
Unidad Unidad Caja de 10 Unidad

10
8
9
ARCHIVO DE PROVEEDORES
Cdigo proveedor
eedor
Nombre del proveedor
Telfono del proveedor Direccin del prov
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
001
Cdigo del artculo
Precio
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.
Figura 3.1.1. Flujo de informacin entre los distintos tipos de archivos

LLAVE PRIMARIA O IDENTIFICADORA.
Cada instancia de una entidad debe ser unvocamente identificable, de manera tal
que cada registro de la entidad debe estar separado y ser unvocamente identificab
le del resto de los registros de esa misma entidad; y quien permite esta identif
icacin es la llave primaria. La llave primaria, que generalmente se identificada
por medio de la letra @, puede ser un atributo o una combinacin de atributos.
En consecuencia en cada archivo solo podr existir un nico registro que posea un va
lor determinado para su llave primaria. En otras palabras no puede existir en un
archivo un registro que cuente con el mismo valor de otro registro en el campo
de la llave primaria; la llave primaria no puede tener valores repetidos para di
stintos registros.
La llave primaria debe permitirle a un Sistema de Gestin de Base de Datos (SGBD),
correctamente proyectado, generar un error si un usuario intenta incluir un nue
vo registro cuya llave primaria coincida con la de otro registro ya existente en
el archivo.
En el caso de la Base de Datos de compras, descripta anteriormente ( ver 3.1.Est
ructura de una Base de datos), las llaves primarias de cada archivo son:
ARCHIVO DE PRODUCTOS: @ Cdigo artculo ARCHIVO DE PROVEEDORES: @ Cdigo proveedor
ARCHIVO ORIGEN DE LOS PRODUCTOS: @(Cdigo proveedor + Cdigo producto).
INDICES DE ACCESO
Un ndice de acceso es un archivo auxiliar utilizado internamente por el SGDB para
acceder directamente a cada registro del archivo de datos. La operacin de indexa
cin, creada por el SGDB, ordena a los registros de un archivo de datos de acuerdo
con los campos utilizados como llave primaria e, incrementa sensiblemente la ve
locidad de ejecucin de algunas operaciones sobre el archivo de datos. Normalmente
para cada archivo de datos debe existir un ndice cuya llave de indexacin sea idnti
ca a su llave primaria. Este ndice es llamado ndice primario .
Tambin es posible crear ndices para un archivo de datos utilizando atributos (camp
os), o conjunto de atributos, diferentes de los de la llave primaria. Este tipo
de ndice, llamado ndice secundario, es utilizado para reducir el tiempo de localiz
acin de una determinada informacin dentro de un archivo o para clasificar los regi
stros del archivo de acuerdo con el orden necesario para la obtencin de la inform
acin deseada.
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
a de las reas de la empresa,
te sistema;
2.
Detallar los procesos
3.
Enumerar los archivos
4.
Definir los flujos de
del sistema, determinando lo que ocurrir en cada un

denominadas Entidades externas, que participen de es
a ser realizados;
de datos necesarios, en cada proceso;
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.1. Diagrama de Flujo de Datos.
RECOMENDACIONES PARA UN DFD.
1.
Los DFD son ms legibles, si las entidades
bordes del diagrama; de tal forma, que la frontera
ite dentro del contorno de las entidades externas
2.
Si los flujos de datos principales van del
derecho del diagrama, la lectura se har ms fcil
externas son diseadas sobre los

del sistema (o contexto) se s
lado izquierdo hacia el lado
y ms rpida.
3.
Las duplicaciones de smbolos deben ser mantenidas al mnimo, pero cuidando
de mantener un nmero aceptable de lneas de flujo de datos cruzndose unas con otras.
4.
Inicie la construccin del DFD por las entidades externas, a continuacin si
ga con las salidas que de ellas son originadas, juntamente con las entradas que
irn para ellas.
Al disear el primer borrador del DFD, piense en como el sistema funciona realment
e, cul es la entrada o proceso que inicia, y por ah comience el diseo.
Los primeros diseos de un DFD siempre tendrn la finalidad de borrador. El objetivo
es la identificacin de todos las entidades externas, procesos y archivos de dato
s que formarn parte del sistema, adems de incluir los flujos de datos entre ellos.
Prximas versiones mejorarn las definiciones y el diseo.
El orden ms lgico para disear un DFD es definir la entidad externa o proceso que ge
nera una entrada de datos, despus el proceso que trata esa entrada, y a continuac
in los archivos de datos que son utilizados para almacenarla y para garantizar el
funcionamiento de ese proceso y por ltimo definir las salidas que son generadas
por dicho proceso.
El primer borrador puede ser realizado en papel, pero los posteriores deben ser
realizados utilizando alguna herramienta de software automatizada (CASE) especfic
amente diseada para la modelizacin del sistema de informacin; estas herramientas cu
entan con un diccionario de datos, que almacenan los detalles del modelo lgico de
l sistema.
EL DICCIONARIO DE DATOS
Un anlisis del mbito de informacin estara incompleto si solo se considera el flujo
de la informacin. Cada flecha del diagrama de flujo de datos representa uno o var
ios elementos de informacin ( ver 4.2. la modelizacin de las funciones del sistem
a); cada archivo de datos es una coleccin de elementos de datos individuales; inc
luso puede que el contenido de una entidad externa requiera ser expandido antes
de que su significado pueda ser definido explcitamente. Por lo tanto, el analis
ta debe disponer de algn mtodo para representar el contenido de cada componente de
l modelo de flujo de datos.
Se ha propuesto el Diccionario de Datos como gramtica casi formal para describir
el contenido de los objetos definidos durante el anlisis estructurado.
Esta importante notacin ha sido definida de la siguiente marea:
El Diccionario de Datos es un listado organizado de todos los elementos de datos
que son pertinentes para el sistema, con definiciones precisas y rigurosas que
le permite al usuario y al proyectista del sistema tener una misma comprensin de
las entradas, de las salidas, de los componentes de los repositorios, y tambin d
e clculos intermedios.
CONTENIDO DEL DICCIONARIO DE DATOS
El Diccionario de datos debe contener la siguiente informacin:
Nombre: el nombre principal del elemento; del flujo de datos, del repositorio de
datos o de una entidad externa.
Alias: otros nombres usados para la entrada, dado que un mismo elemento puede se
r conocido por diferentes nombres.
Definicin: Exposicin clara y precisa de las caractersticas genricas y diferenciales
del objeto.
Descripcin: Explicar las diversas partes o circunstancias, que componen la defini
cin, de los objetos.
Dnde se usa/cmo se usa: Un listado de los procesos que usan un elemento de datos,
o del control de cmo lo usan.
Descripcin del contenido: El contenido es representado mediante una anotacin que s
e describe en la siguiente tabla.
Existen muchos esquemas de anotacin usados por los analistas de sistemas el que s
igue es uno de los mas usados
Smbolo
=
+
( )
{ }
Descripcin
Est compuesto de
Y
Opcional
(puede estar
Interaccin entre componentes
* *
Eleccin de una de las opciones

Comentario
presente
o ausente)
|
@
Separa opciones de alternativas en la construccin [ ]

Identificador campo llave
FIGURA 4.2 Diccionario de Datos - Descripcin
FIGURA 4.3 Diccionario de Datos - Estructura

FIGURA 4.4 Diccionario de Datos - Definicin de un elemento
LA MODELIZACIN DE DATOS ALMACENADOS EL MODELO RELACIONAL DE DATOS (RDM).
Todos los sistemas almacenan y usan informacin sobre el ambiente con el cual inte
ractan, algunas veces la informacin es mnima, pero en la mayora de los sistemas, es
bastante compleja. No solamente queremos saber, en detalle, qu informacin est conte
nida en cada archivo de datos, sino tambin que relaciones existen entre los archi
vos de datos. Este aspecto del sistema no est representado por el diagrama de flu
jo de datos; pero s est activamente representado por el Modelo Relacio
nal de
Datos
(Relational Data Model).
Como la anotacin de los repositorios de datos en el DFD dice muy poco acerca de l
os detalles de los datos, es necesario que a partir de este modelo, se requiera
una clara definicin de las entidades (archivos de datos) y de sus relaciones, q
ue conforman parte del proyecto y que por lo tanto son de especial inters para el
usuario. Estos datos y relaciones deben ser almacenados a travs de archivos que
posteriormente formarn la base de datos del sistema.
Por lo tanto, el objetivo de un RDM es el de ilustrar la estructura de los datos
del sistema, a travs de la identificacin de las entidades detectadas en el sistem
a y el diseo de sus relaciones.
El RDM posee dos importantes componentes, que son las Entidades y las Relaciones
:
1.
Entidades o Tipos de objetos: Son representadas por un cuadrado en el R
DM. Una Entidad representa a una coleccin o conjunto de objetos (cosas) del mundo
real, cuyos miembros disean un papel en el sistema que se est desarrollando. Las
Entidades pueden ser identificadas de forma nica y, ser descriptas a travs de uno
o mas hechos (Atributos). Como regla general, tomamos que, en cada archivo de da
tos definido por el DFD, se almacenan los datos que describen a las Entidades de
l sistema de informacin, o sea, a cada archivo de datos del DFD le corresponde un
a Entidad al RDM.
2.
Relaciones: Una relacin representa un conjunto de conexiones o asociacion
es entre las Entidades, interligadas por vectores al relacionamiento. Normalment
e, cada entidad que compone la base de datos de un sistema podr estar relacionada
con otras; por ejemplo, un cliente podr estar relacionado con varias ventas, una
venta con varios productos, un vendedor con varias ventas, y as sucesivame
nte en
cada uno de los procedimientos.
Por lo tanto, considerando que las entidades de una base de dados estn relacionad
as, y que a travs de esa relacin son generados informes, como por ejemplo: todos l
os productos vendidos a un cliente, es importante definir todas las relaciones e
ntre las entidades y su correspondiente tipo de relacin y que veremos a continua
cin.
TIPOS DE RELACIONES
El RDM muestra los tres tipos de relaciones posibles entre los archivos de datos
y los procesos de un DFD: uno a uno; uno a varios
y varios a
varios. Pero veamos cmo son cada una de estas relaciones:
Relacin uno a varios.
Es el tipo de relacin ms comn; y en este tipo de relacin, un registro de la Tabla A
puede tener muchos registros coincidentes en la Tabla B, pero un registro de la
Tabla B slo tiene un registro coincidente en la Tabla A.
Relacin varios a varios.
En una relacin varios a varios, un registro de la Tabla A puede tener muchos regi
stros coincidentes en la Tabla B y viceversa. Este tipo de relacin slo es posible
si se define una tercera tabla (denominada tabla de unin), cuya clave principal c
onsta de al menos dos campos; y que adems, estos campos, correspondan a las clave
s externas de las Tablas A y B.
Relacin uno a uno.
En una relacin uno a uno, cada registro de la Tabla A slo puede tener un registro
coincidente en la Tabla B y viceversa. Este tipo de relacin no es habitual, debid
o a que la mayora de la informacin relacionada de esta forma estara en una sola tab
la. Puede utilizar la relacin uno a uno para dividir una tabla con muchos campos,
para aislar parte de una tabla por razones de seguridad o para almacenar inform
acin que slo se aplica a un subconjunto de la tabla principal.
BENEFICIOS DEL RDM
Los principales beneficios en la utilizacin del RDM son:
1.
Da una visin de alto nivel de los archivos de datos involucrados en el si
stema.
2.
Ayuda a descubrir los elementos o las entidades que no
fue
ron
detectadas, al momento de disear y analizar el DFD.
3.
Simplifica la estructuracin de los datos.
4.
Facilita la definicin y el anlisis de las Llaves primarias de cada archivo
de datos; como as tambin sus llaves forneas, que son necesarias para establecer la
relacin entre las entidades, y que a travs de las cuales podrn ser procesados y co
nsultados los registros (ver 3.1.2.llave primaria o identificadora).
5.
Facilita la definicin y el anlisis del tipo de relacin existente entr
e
las entidades u objetos, que conformarn la base de datos:
uno a uno, en este caso se debe verificar que cada entidad sea nica o pude s
er formada por un conjunto de entidades de menor nivel. uno a varios,
varios a varios; en este caso se debe subdividir en dos relaciones del tipo uno
a varios. (ver diseo de la relacin uno a uno)
Todos estos beneficios hacen que el RDM sea fundamental para poder proyectar una
base de datos.
Despus de la construccin del RDM, tambin es necesario que sean incorporados al Dicc
ionario de Datos todos los datos que fueron definidos en este modelo y que sern a
lmacenados en cada archivo, y que posteriormente formarn la base de dados del sis
tema proyectado.
TECNICA DE DISEO DEL RDM.
Cada entidad es representada por un rectngulo,
La relacin entre las entidades es representada por una lnea uniendo a los rectngulo
s a relacionar,
El tipo de relacin es representada por un par de nmeros en la extremidad de la lne
a de relacin: 1 identifica una relacin con un nico registro y N identifica una rela
cin con muchos registros y 0 identifica la relacin con ningn registro,
La descripcin de la relacin debe ser hecha a lo largo de las lneas que ligan las en
tidades relacionadas.
En la Fig. 4.4.1. se representa la relacin entre dos entidades; la entidad PERSON
A y la entidad DEPARTAMENTO. El par de nmeros ( 1 , 1 ) indica que como mnimo una
( 1 ) PERSONA trabaja en un DEPARTAMENTO y como mximo una ( 1 ) PERSONA trabaja e
n un DEPARTAMENTO. Por otro lado, el par de nmeros ( 0 , N ) indica que en un DEP
ARTAMENTO pueden trabajar como mnimo ninguna ( 0 ) PERSONA y como mximo varias ( N
)
PERSONAS.
Por lo tanto, una PERSONA est relacionada a un DEPARTAMENTO (1,1) y un DEPARTAMEN
TO est relacionado a ninguna o varias PERSONAS (0,N)
FIGURA 4.4.1. Relacin entre entidades
En el ejemplo de la Fig. 4.4.2. cada VENTA involucra uno o mas (1,N) productos v
endidos; pero un PRODUCTO es parte de solamente una VENTA (1,1).
FIGURA 4.4.2. Propiedades de las entidades y las relaciones
En el ejemplo de la Fig. 4.4.3. cada PROVEEDOR puede suministrar uno o mas (1,N)
PRODUCTOS y cada PRODUCTO puede ser provisto por uno o mas (1,N) PROVEEDORES o
viceversa pues una relacin entre dos entidades puede ser leda en cualquiera de la
s dos direcciones.
FIGURA 4.4.3. Direccionalidad de las relaciones

Diseo de la Relacin uno a uno.
Al ser identificada una relacin uno a uno (1,1), se debe inicialmente verificar s
i los dos objetos relacionados son realmente distintos o pueden ser unidos en un
nico elemento.
Si cada elemento fue identificado con la misma llave primaria y si ambos se comp
lementan, hay una fuerte razn para unir a los dos elementos en uno solo. Por ejem
plo tenemos a las entidades PRODUCTO Y STOCK.
FIGURA 4.4.4. Relacin uno a uno
Como cada PRODUCTO es almacenado en STOCK, podemos considerar una nica entidad d
e PRODUCTOS EN STOCK, representada en la figura 4.4.5.
En este caso, las entidades PRODUCTO Y STOCK no son realmente distintas y por e
se motivo, debemos almacenarlas en un nico archivo de datos, pues el Saldo es ape
nas un atributo de cada PRODUCTO ( ver 4.4. Normalizacin).
FIGURA 4.4.5 Unin de dos entidades relacionadas uno a uno

Si los dos elementos fuesen realmente distintos, cada uno debera ser identificado
por una llave primaria que lo distinga de forma inequvoca de los dems. (ver 3.1.2
llave primaria o identificadora).
La relacin entre los dos objetos deber ser realizada a travs de una llave relacin, d
enominada llave fornea <FK> La llave fornea deber estar indicada en el objeto relac
ionado, como se ilustra en la figura 4.4.6. La llave fornea recibe este nombre po
rque, necesariamente ella, no es un atributo del elemento relacionado, pero s e
s la llave primaria del elemento al cual est se relaciona.
FIGURA 4.4.6.Llave fornea <FK>
En el caso de la relacin (1,1), representada en la figura 4.4.6, entre una MATERI
A y un PROFESOR que dicta una MATERIA; vemos al Cdigo de la materia como la llave
primaria de la entidad MATERIA; y la llave primaria Nmero de profesor de la enti
dad PROFESOR.
Si determinamos que un PROFESOR est relacionado a una MATERIA, precisamos pues de
una llave que haga la relacin entre las dos entidades; esta llave que como ya vi
mos se denomina llave fornea y es identificada con la sigla <FK>; y en nuestro ca
so quien cumple esta funcin es el Cdigo de la materia y debe ser archivada en la e
ntidad que describe al PROFESOR, y apunta a la MATERIA que l dicta, como se ilust
ra en la figura 4.4.8.
Por lo tanto, en el archivo PROFESOR, el dato "Cdigo de la materia" es un campo l
lave fornea (FK), significando que se trata de un dato del archivo
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.7 Llave fornea
Aunque estas dos soluciones sean posibles para la relacin entre PROFESOR y MATER
IA, ninguna de ellas est totalmente correcta. Una mejor solucin debe permitir qu
e un profesor pueda dictar varias materias o que una materia pueda ser dictada p
or varios profesores. O sea, la relacin entre PROFESSOR y MATERIA no es uno a uno
, sino por lo menos uno a varios (que se trata en el punto siguiente)
A continuacin se presentan cuatro preguntas, que sirven como ejemplo, para presen
tar el anlisis que debe ser hecho al proyectarse una relacin uno a uno:
La relacin siempre ser uno a uno?

Hay alguna posibilidad de que en el futuro ella pase a ser uno a varios?
De que forma se podr adaptar ante un posible cambio del sistema?
En qu archivo deber ser incluida la llave fornea para ser utilizada como apuntadora
de la relacin?
Diseo de la Relacin uno a varios.
La relacin uno a varios ocurre cuando una nica instancia de una entidad est relaci
onado con otras instancias de otra entidad. Como cada entidad posee un archivo d
e datos conteniendo sus atributos, la llave primaria de la "entidad uno" debe se
r una "llave fornea" en el archivo que describe a la "entidad muchos", pudiendo s
er parte de su llave primaria o no.
En el ejemplo ilustrado por la Fig. 4.4.8., mostrando la relacin entre una MATERI
A y varios PROFESORES, el atributo "Cdigo de la materia" es la llave fornea de PR
OFESOR.
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 4.4.10 Relacin varios a varios
Para determinar los datos que debern estar contenidos en los objetos de intersecc
in a ser creados debemos analizar la relacin (N,N) entre MATERIA Y PROFESOR hacien
do las siguientes preguntas.
Cul debe ser el objeto que posea una llave primaria que corresponda a la concatena
cin de un determinado "Cdigo de la materia" y de un determinado "Nmero de profesor"
?
Qu datos o atributos dependen exclusivamente de esta combinacin?
Qu datos pueden ser obtenidos si sabemos que estamos tratando con una determinada
MATERIA dictada por un determinado PROFESOR?.
Al tratar de responder estas preguntas verificamos que diferentes materias puede
n ser dictadas por diferentes profesores en diferentes horarios y aulas y, dife
rentes profesores dictan diferentes materias en determinadas aulas y en determi
nados horarios.
Por lo tanto; como una determinada materia puede ser dictada por diferentes prof
esores en diferentes aulas y en diferentes horarios, podemos crear un objeto de
interseccin denominado COMISIN. De esta forma, un determinado profesor podr dictar
varias materias, cada una en su respectiva
aula y horario; as como cada materia podr ser dictada por varios profesores, y par
a cada profesor habr una determinada aula y horario.
La figura 4.4.11. ilustra la relacin (N,N) entre MATERIA Y PROFESOR resuelta por
una relacin (1,N) entre MATERIA Y COMISIN y una relacin (1,N) entre PROFESOR Y COMI
SIN.
FIGURA 4.4.11 Relacin varios a varios solucionada
En este caso, la llave primaria de COMISIN es compuesta por dos llaves forneas. O
sea, para que una COMISIN sea identificada es preciso saber cual es la materia y
cual es el profesor. Como el "Cdigo de la materia" pertenece a la MATERIA y el "Nm
ero de profesor" pertenece a PROFESOR ambos son llaves forneas en COMISIN y concat
enadas forman su llave primaria, pues la identifican.
NORMALIZACIN.
El proceso de la construccin del Modelo Relacional de Datos (RDM), tiene como obj
etivo:
Percibir las cosas de significacin sobre lo que se necesita saber y mantener
la informacin. Esto es definir a las entidades y disearlas como un recuadro.
Aadir las relaciones de gestin, las cuales se han nombrado como asociaciones
significativas entre entidades. Esto es definir al conjunto de conexiones que li
gan a las entidades u objetos y son representadas por medio de vectores.
En cada entidad se listan los tipos de informacin que se podran
mantener o conocer. Esto es la definicin de cada uno de los atributos por los cua
les una entidad es conocida.
Se determina la forma en que cada aparicin de una entidad puede ser identifi
cada de forma nica. Esto es la definicin de uno o ms campos identificadores o llave
.
Por lo tanto la modelizacin (RDM) permite:
Minimizar la duplicacin de datos;
Proporcionar
la
flexibilidad
necesaria
para
soportar
requisitos funcionales y
Que el modelo se estructure sobre una amplia variedad de diseos alternativos
de bases de datos.
La mayor dificultad en este proceso es que se depende de la buena comprensin del
analista acerca de lo que realmente es una Entidad, un Atributo y una Relacin. Pa
ra evitar tal circunstancia es que se aplica el proceso de NORMALIZACIN.
Entonces denominamos NORMALIZACIN al proceso de simplificacin de archivos de datos
que componen una base de datos relacional (diseo eficaz de tablas); y que persig
ue como objetivo principal minimizar la duplicidad de informacin, prevenir incons
istencias, evitar redundancias, garantizar que no existan prdidas de informacin. E
n resumen son las tcnicas y algoritmos que ayudan, al proyectista de una base de
datos relacional, a construir relaciones normalizadas, segn sea el significado y
el contenido del universo a ser modelado, evitando, anomalas en el manejo de esto
s datos
El proceso de normalizacin consiste, bsicamente, en la aplicacin de un conjunto de
reglas para definir adecuadamente los datos o campos que compondrn los archivos d
e datos. Esas reglas buscan:
Minimizar redundancias;
Eliminar anomalas de actualizacin;
Proveer el mejor camino de acceso a cualquier dato; Asegurar resistencia a la ma
nutencin del modelo de datos;
Evitar datos no identificables a travs de una definicin rigurosa de identificadore
s y relaciones.
Fueron establecidos cinco tipos de archivos normalizados, denominados, en orden
creciente de simplicidad: primera forma normal (1FN), segunda forma normal (2FN)
, tercera forma normal (3FN), cuarta forma norma (4FN) y quinta forma normal(5FN
).
En general, las tres primeras reglas bsicas de normalizacin son suficientes
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
Poroto
Harina
Azcar
Coto, Disco, Carrefour, Jumbo

Coto, Macro, Carrefour, Jumbo
Coto, Macro, Carrefour
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
ARROZ Coto
670-1158
200
ARROZ Disco 923-3951
500
ARROZ Carrefour
921-4802
ARROZ Jumbo 342-6400
1000
POROTO Coto
670-1158
300
POROTO Macro 923-4377
500
POROTO Carrefour
921-4802
POROTO Jumbo 342-6400
400
HARINA Coto
670-1158
400
HARINA Macro 923-4377
600
HARINA Carrefour
921-4802
AZUCAR Disco 923-3951
1100
AZUCAR Carrefour
921-4802
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
12
6000
200
14
8
3200
8
3200
9
5400
100
7
4
4400
900
5
AZUCAR Ta
449-7448
1200
Precio Total
7700
2800
700
4500
3600
SEGUNDA FORMA NORMAL (2FN).

Eliminar atributos que dependen solamente de una parte del identificador nico
Si una entidad tiene un identificador nico compuesto de ms de un atributo y/o rel
acin, y si otro atributo depende slo de una de las partes de este identificador co
mpuesto, entonces el atributo, y la parte del identificador del que depende, deb
ern formar la base de una nueva entidad. La entidad nueva, se identifica por la
parte emigrada del identificador nico de la entidad original, y tiene una relacin
de uno a varios unida con la entidad original.
Para testear si un archivo de datos est en la segunda forma normal debemos hacer
inicialmente las siguientes preguntas:
Cul es el campo o conjunto de campos que constituye la llave primaria del arc
hivo?
un campo, preguntamos tambin:

Hay algn campo no-llave que dependa de apenas, de una parte de la llave prim
aria?
, por s solo no es suficiente para identificar inequvocamente un determinado regis

tro, pues varios registros poseen el mismo producto. Para obtener una llave pr
imaria exclusiva debemos concatenar producto con negocio, pues no hay ninguna ll
ave "Producto + Negocio" duplicado. En este caso, como la llave es concatenada,
debemos adems hacer la segunda pregunta para cada campo no-llave:
La cantidad depende apenas de una parte de la llave?
mo
el negocio para obtener la Cantidad.
El Precio depende apenas de una parte de la llave?
Producto como el Negocio para obtener el Precio.
El Telfono depende apenas de una parte de la llave?
tambin podr saber cual es su Telfono, independientemente del Producto; por lo tanto
, el archivo ejemplificado anteriormente no est en la segunda forma normal, pue
s l no pas por el test.
Cuando un archivo de datos no est en la segunda forma normal, la base de datos no
estar correcta por las siguientes razones:
El archivo de datos ocupar mas espacio en el disco del que ser necesario, pue
s el nmero de Telfonos se repite para cada Producto almacenado en el mismo archivo
;
Si un negocio cambia el nmero de Telfono, todos los registros de Productos pa
ra aquel Negocio deber tener el campo Telfono modificado;
Si ocurre algn problema con el proceso de actualizacin de datos, un mismo Neg
ocio podr aparecer con nmeros de Telfonos diferentes, dependiendo de cual registro
sea por el que se accede, o sea, la integridad de la base de datos estar perdida;
Cuando un negocio posee un nico Producto y su registro fuese eliminado (por
inexistencia en stock), tambin ser eliminado el Telfono del Negocio, pues podr no ex
istir otro lugar en la base de datos que lo almacene.
Para evitar estos problemas, el archivo anterior deber ser dividido en dos, como
se ilustra a continuacin:
Producto
Negocio
ARROZ Coto
200
ARROZ Disco 500
ARROZ Carrefour
ARROZ Jumbo 1000
POROTO Coto
300
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
POROTO
POROTO
POROTO
HARINA
HARINA
HARINA
AZUCAR
AZUCAR
AZUCAR
Negocio
Coto
12
6000
200
14
2800
8
3200
8
3200
9
5400
100
7
700
4
4400
900
5
4500
3
3600
Telfono
1176
670-1158
Macro 500
Carrefour
Jumbo 400
Coto
400
Macro 600
Carrefour
Disco 1100
Carrefour
Ta
1200
Direccin
Av. Del trabajo
Precio Total
7700
Disco Emilio Mitre 515

923-3951
Carrefour
Av. La Plata 2222
921-4802
Jumbo Av. Cruz 4897 342-6400
Macro Av. Rivadavia 4735
923-4377
Ta
Av. Rivadavia 7788
449-7448
Ahora los dos archivos estn en la segunda forma normal. El archivo de PRODUCTOS E
N STOCK est en la segunda forma normal porque los campos no-llave(Cantidad, Preci
o y Total) son dependientes de toda llave primaria concatenada Producto + Negoci
o y de nada ms.
El segundo archivo, NEGOCIOS, tambin est en la segunda forma
normal
porque l no posee una llave concatenada y, por lo tanto, una columna no - llave c
omo Direccin o Telfono naturalmente ser dependiente del nico campo llave, que es Neg
ocio.
Analizando desde otra perspectiva, es fcil percibir que el archivo anterior, a pe
sar de estar en la primera forma normal, contiene datos que describen dos cosas
distintas y que son por un lado PRODUCTOS y por el otro NEGOCIOS.
Como regla general es importante, que un archivo de datos en una base de datos d
ebe almacenar datos que describan apenas una entidad o evento. Por lo tanto, un
archivo de datos para estar en la segunda forma normal debe contener datos apena
s sobre un nico objeto de informacin o una nica clase de objetos. En nuestro ejem
plo, el primer archivo ahora contiene apenas datos sobre productos en stock y e
l segundo sobre negocios.
TERCERA FORMA NORMAL (3FN).
Eliminar los atributos dependientes de atributos que no son parte del identifica
dor nico.
Un archivo en la segunda forma normal tambin estar en la tercera forma normal si u
n campo no-llave depende de otro campo no-llave.
Para verificar si un archivo en la segunda forma normal tambin est en la tercera f
orma normal debemos preguntar: Algn campo no -llave es dependiente de cualquier ot
ro campo no-llave?
El archivo de los PRODUCTOS EN STOCK posee tres campos (o columnas) no-llave: Ca
ntidad, Precio y Total. Si sabemos la Cantidad y el Precio, sabremos el Total. P
or lo tanto, el campo "Total" es dependiente de dos campos no-llave, pues puede
ser obtenido a partir de la Cantidad multiplicada por el Precio.
Concluimos entonces, que el archivo de PRODUCTOS EN STOCK no est en la tercera
forma normal.
Si el campo "Total" fuese eliminado, el archivo de PRODUCTOS EN STOCK pasa a est
ar en la tercera forma normal, ocupando menos espacio en el disco, y sin prdida
de informacin.
Producto
ARROZ Coto
ARROZ
ARROZ
ARROZ
POROTO
Negocio Cantidad
200
10
Disco 500
Carrefour
Jumbo 1000
Coto
300
9
700
8
13
Precio
11
POROTO
POROTO
POROTO
HARINA
HARINA
HARINA
AZUCAR
AZUCAR
AZUCAR
Macro 500
Carrefour
Jumbo 400
Coto
400
Macro 600
Carrefour
Disco 1100
Carrefour
Ta
1200
12
200
8
8
9
100
4
900
3
14
7
5
FLUJOGRAMAS
Como se seal anteriormente, el DFD es una herramienta muy adecuada para modelizar
una red de procesos comunicantes asincrnicos. Es por eso que precisamos de otra h
erramienta para representar la lgica y la secuencia de un procedimiento.
El flujograma es la representacin grfica que muestra: el comienzo y el fin de un p
roceso de tratamiento de datos, y las operaciones de decisiones necesarias para
cumplirlo, en el orden secuencial correspondiente.
No hay duda de que de las herramientas tales como los flujogramas, son una
excelente forma grfica de describir fcilmente los detalles procedimentales.
El flujograma es la representacin grfica ms ampliamente usada para el diseo procedim
ental. Desgraciadamente, es tambin el mtodo del que ms se ha abusado.
Un flujograma es un grfico muy sencillo. Las tres construcciones de la programacin
estructurada se representan como en la figura 5.5. La secuencia se representa c
omo dos cuadros de procesamiento conectados por una lnea de control. La condicin,
tambin denominada IF -THEM-ELSE (si- entonces - sino), se dibujo como un rombo de
decisin que, si es verdad, hace que se realice el procesamiento de la parte the
m y, si es falso, pasa al procesamiento e la parte else.
Los flujogramas son usados principalmente para la documentacin fsica o las interfa
ces del hardware dentro de un sistema.
Un flujograma contiene dos tipos e elementos: Los bloques y las lneas.
Los bl
oques,Los bloques pueden representar accin o decisin.
Un bloque de accin representa una actividad: efectuar una operacin aritmtica entre
dos nmeros, convertir un valor en cero, etc. Su descripcin implica siempre aplicar
un verbo (hacer algo): sumar, transferir, borrar, etc.
Un bloque de decisin: es una forma de expresar una consulta acerca del cumplimien
to o no de una determinada condicin o alternativa. Segn sea la respuesta que se d a
dicha consulta (verdadero o falso) se seguirn diferentes caminos.
Las lneas de direccin o flechas que comunica los bloques y determinan el orde
n secuencial en que deben ser considerados.
FIGURA 5.5 FLUJOGRAMA

TABLAS DE DECISIN
Es una forma particular de matriz mediante la cual se representan las acciones a
tomar cuando se dan determinadas condiciones (variables relevantes).
Es una tcnica de aplicacin en el anlisis y diseo de sistema y procedimientos: presen

ta un modelo lgico de alternativas o conjunto de alternativas de forma completa y
fcil de captar y visualizar.
En su documentacin de los sistemas brinda la ventaja de evitar descripciones lite
rarias de compleja compresin. Y tambin como un medio de comunicacin e instrumento
de programacin elimina todas las ambigedades o falta de precisin que pueden surgir
de las descripciones literarias facilitando al programador la conversin de las co
ndiciones y decisiones a instrucciones aplicables a un computador.
Si hubiera N variables con valores binarios (verdadero / falso), entonces, habr 2
N reglas distintas; si hubiera 3 condiciones habr 8 normas.
Las tablas decisin estn divididas en cuatro cuadrantes que conforman el siguiente
esquema:
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);
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.
Figura 5.1 Modelo del Proceso de Negocio

En la Figura 2 se muestra la metodologa de J.Martin del Diagrama de Entidad Rel
acin, para realizar el Modelo de Datos
Figura 5.2 Modelo Relacional de Datos

Algunos de los componentes de las herramientas CASE p
ejemplo
de
ello,
es
la
aplicacin
de
los
sistemas
expertos.

Gantt.
el mnimo costo.
a)
b)
c)

del proyecto.
sern
$ El dinero.
De Costo;
De Sensibilidad.
cua
de una gr
de lo
valor e
la


nar:
Fsicos
Perifricos
(Unidades
de
entrada,
lgicos
o
o
de
o
o
etos)
o
o
o
o
o
o
o
la
Unidades

humanos
Seleccin
Formacin
Incentivos

la recuperacin
puedan tomar
supervivenc
un recurso



sta


1.01.01
Unidad Cantidad
1.01.02
1.02.01
2.01.01
3.01.01
4.01.01
4.01.02
Disco rgido ATA 66
Sonido de 16 bit
Pentium III 500Mhz
Pentium III 800Mhz
Resma 100 hojas

10
20
20
5
25
7
8
9
Cdigo proveedor
eedor
001
002
003
Inca Tel
Infocad
Herrera Compusistem
4923-4803
4633-2520
4232-7711
Av.
La
Plata 365
Doblas 1578
Av.
Rivadavia 3558

Cdigo proveedor
001
Cdigo del artculo
Precio
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
UCTOS;
OVEEDORES y;

o procesan datos.
TIPOS DE ARCHIVO
ARCHIVO MAESTRO
PAGO
DE

COMPRAS,
PROGRAMA
DE
PRODUCC
IN;
PRESUPUESTO

stintos registros.
el archivo.
INDICES DE ACCESO
acin deseada.
obre el mundo real.
actos.
.
.
LISTA DE EVENTOS.
a
la
diversas
alternat
ivas
veamos los
siguient
es
a, entran en
juego
muchas
acepciones
Compras se
efiere a:
en
insumos y/o
bienes de
capital?.

conceptos.
ICITUD DE COMPRA
uario del producto.
ertidumbre.

espacho.
ess Model).
1.
te sistema;
2.
3.
4.

a ser realizados;

olos :
1.
es.
estudio.
stema.

ario de datos).
1.
2.

y ms rpida.
3.
4.
irn para ellas.
por dicho proceso.
l sistema.

del objeto.
Smbolo
=
+
( )
{ }
Descripcin
Est compuesto de
Y
Opcional
(puede estar
* *
|
@

Comentario
presente
o ausente)

nal de
Datos
:
1.
a Entidad al RDM.
2.
nte en
cin.
TIPOS DE RELACIONES
y varios a

Relacin uno a uno.
BENEFICIOS DEL RDM
1.
stema.
2.
fue
ron
3.
4.
5.
e
base de datos.
tema proyectado.
s a relacionar,

)
PERSONAS.
s dos direcciones.

nico elemento.

dad PROFESOR.
de la relacin?
OFESOR.
ofesores
or.
?

nados horarios.
SIN.
NORMALIZACIN.
etivo:
.
Proporcionar
la
flexibilidad
necesaria
para
soportar
de bases de datos.

s datos
s y relaciones.
).
ependientes.
perdidas.
o.
Producto
Negocio
Arroz Coto, Disco, Carrefour, Jumbo
Poroto Coto, Macro, Carrefour, Jumbo
Harina Coto, Macro, Carrefour
Azcar Ta, Disco, Carrefour

Producto
Negocio Telfono
ARROZ Coto
670-1158
200
500
ARROZ Carrefour
921-4802
1000
POROTO Coto
670-1158
300
500
POROTO Carrefour
921-4802
400
HARINA Coto
670-1158
400
600
HARINA Carrefour
921-4802
1100
AZUCAR Carrefour
921-4802
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
12
6000
200
14
8
3200
8
3200
9
5400
100
7
4
4400
900
5
AZUCAR Ta
449-7448
1200
Precio Total
7700
2800
700
4500
3600

hivo?

aria?

mo
;
Producto
Negocio
ARROZ Coto
200
ARROZ Disco 500
ARROZ Carrefour
ARROZ Jumbo 1000
POROTO Coto
300
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
Precio Total
7700
POROTO Macro 500

12
6000
POROTO Carrefour
200
14
2800
POROTO Jumbo 400
8
3200
HARINA Coto
400
8
3200
HARINA Macro 600
9
5400
HARINA Carrefour
100
7
700
AZUCAR Disco 1100
4
4400
AZUCAR Carrefour
900
5
4500
AZUCAR Ta
1200
3
3600
Negocio Direccin
Telfono
Coto
Av. Del trabajo 1176
670-1158
923-3951
Carrefour
Av. La Plata 2222
921-4802
Jumbo Av. Cruz 4897 342-6400
923-4377
Ta
Av. Rivadavia 7788
449-7448
o y de nada ms.
normal
ocio.
dor nico.
ro campo no-llave?
forma normal.
de informacin.
Producto
ARROZ Coto
ARROZ
ARROZ
ARROZ
POROTO
POROTO
POROTO
POROTO
HARINA
HARINA
HARINA
AZUCAR
AZUCAR
AZUCAR
Negocio Cantidad
200
10
Disco 500
Carrefour
Jumbo 1000
Coto
300
Macro 500
Carrefour
Jumbo 400
Coto
400
Macro 600
Carrefour
Disco 1100
Carrefour
Ta
1200
9
700
8
13
12
200
8
8
9
100
4
900
3
Precio
11
14
7
5
FLUJOGRAMAS
Los bl

TABLAS DE DECISIN

esquema:
REGLAS
1

su corroboracin
3
tivamente
4
5
6
7

jecutar.
uientes:
a un PROVEEDOR
el RDM.
Una regla prctica :
1)
por software,
2)
zado de sus datos
3)
us datos.
e los mdulos.
del sistema.

cesaria.
r Computacin.


Algunos de los componentes de las herramientas CASE permiten:
Confeccionar la definicin de requerimientos de los usuarios, Mejorar el diseo de l
os sistemas,
Mejorar la eficiencia en la programacin (por su generacin automtica de cdigos),
Otorgar a la administracin un mejor soporte en la documentacin.
Para ello, y sin importar la arquitectura de la herramienta CASE, en general tal

es herramientas deben abarcar las siguientes propiedades:
Tener una interfaz grfica y textual, que le permita al usuario manejar los o
bjetos de diseo (Ver Figura 3).
Figura 5.3 Herramientas de edicin

Contar con un Diccionario de Datos, a fin de rastrear y controlar los objet
os diseados (Ver figura 4 y 5).
Figura 5.4 Diccionario de Datos Editor

Figura 5.5 Diccionario de Datos Estructura
Disponer de un conjunto de herramientas que permitan: chequear las reglas d
el diseo y analizar la lgica del diseo ( Ver figuras 6, 7 y 8).
Figura 5.6 Chequeo de Reglas
Figura 5.7 Informe del Chequeo de Reglas

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 administrador de un proyecto informtico debe buscar la mxima automatizacin de la

s tareas que realizarn cada uno de los profesionales involucrados en un proyecto
informtico. Es importante destacar que lo que buscamos no es solamente que en tod
o proyecto informtico se est dispuesto a automatizar tareas requeridas por los usu
arios; sino tambin la de automatizar las propias tareas del proyecto.
CARACTERSTICAS EN TODA METODOLOGA DE PROCESAMIENTO DE DATOS
A continuacin presentamos una lista de atributos, que se consideran mnima en todo
procesamiento de datos:
Automatizacin: Como venimos diciendo, se debe buscar la mxima automatizacin p
osible de todas las tareas desarrolladas por
los
profesionales involucrados en un proyecto informtico. Se debe evitar la programac
in manual; pues sta es lenta y propensa a errores, por lo tanto es ineficaz e ine
ficiente.
Velocidad: Tal lo visto en el primer captulo ( ver 1. Proyecto informtico, ta
reas y recursos) otro de los problemas principales, en el desarrollo de todo pro
yecto informtico, es el tiempo que involucra al mismo. Persiga altos niveles de p
roductividad, aplicando tcnicas y metodologas que le permitan alcanzar resultados
rpidamente.
Cambiabilidad. Cuando vimos las causas que dan inicio a un proyecto informti
co (ver 1.2. inicio de un proyecto informtico), describimos que existirn cambios e
n el contexto o en los procedimientos requeridos por los usuarios o bien pueden
producirse cambios en la tecnologa; que implicarn cambios en los programas y en l
os sistemas. Es por eso que se deben aplicar tcnicas y metodologas que permitan
realizar dichos cambios, sin que esto involucre un incremento significativo tant
o de los costos y como en el tiempo de implementacin de estos cambios.
Verificacin
de
condicin
correcta.
Confeccione
y
utilice
herramientas de anlisis, como el diccionario de datos ( ver 4.3 el diccionario de
datos), las tablas de decisin (ver 4.6. tablas de decisin
), la diagramacin lgica (ver 4.5. flujogramas), la lista de eventos ( ver 4.2.1. l
ista de eventos); para poder detectar automticamente todos los errores de sintaxi
s y de semntica interna. Si existen ambigedades, contradicciones, incongruencias,
la calidad del sistema se ver afectada, con todo lo que ello implica. Los errores
provocan ineficiencia ineficacia y baja productividad
Tcnicas que faciliten la comunicacin con los usuarios finales. Los usuarios d
eben desarrollar el conocimiento necesario para verificar cada etapa de evolucin
del proyecto. El usuario es quien ms sabe del sistema involucrado en el proyecto
. Adems los usuarios deben estar en condiciones de utilizar sus propios lenguajes
de consulta de actualizacin y de generadores de informacin; como: el Standard Que
ry Languaje (SQL) , el Query - By - Example (QBE), el Query - by - Diagram (QBD)
o el Grafphics Language for Database, entre otros. Por lo tanto se deben adopta
r lenguajes que permitan que la gerencia extraiga nueva informacin de las bases d
e datos, con la mxima prontitud posible.
Diseo estable de base de datos. La base de datos es el elemento
principal de toda automatizacin de tareas. Tal cual lo visto en el tpico de la mod
elizacin de datos almacenados ( ver 4.4. el modelo RDM) cuide las tcnicas y los mto
dos para la construccin de las tablas.
Modularidad. Los sistemas deben dividirse en mdulos fcilmente identificables
(ver 4.7. mdulos de un sistema). Debe ser factible efectuar cambios en forma loca
l dentro del mdulo. Todo efecto de cambio exterior al mdulo debe ser rigurosamente
rastreable.
Control de operabilidad mutua. Se necesita una tcnica formal y
rigurosa, para tener la seguridad de que el sistema y los mdulos desarrollados se

paradamente operan correctamente en conjunto ( ver 4.7. el rbol de un sistema).
Dialectos alternativos. Se debe disponer de herramientas de ingeniera de sof
tware(ver. 5 herramientas CASE) para conceptualizar, dibujar y disear sistemas, c
onectados en forma automtica con la representacin bsica. Estas herramientas deben f
uncionar en forma integrada, evitando puentes manuales que introducen errores. D
eben utilizar, en la media posible, sintaxis y grficos comunes.
Una propuesta interesante de destacar es la que propone Lucas H.C. Jr.. con el d
iseo creativo de sistemas, este modelo tiene bsicamente tres componentes:
1.
2.
3.
diseo controlado por el usuario

atencin especial a las interacciones con el usuario
evaluacin de la calidad de los sistemas segn el criterio del usuario
El diseo controlado por el usuario significa que el usuario est a cargo del esfuer
zo de disear
Esto crea un compromiso del usuario con el sistema aumentando la posibilidad de
ser utilizado
El usuario participa activamente durante el diseo y por lo tanto est mejor prepara
do para usar el sistema, en razn de su familiaridad con l.
El usuario est a cargo del diseo lgico o conceptual del sistema incluyendo las sali
das, las entradas y la lgica del procesamiento. El usuario en escribe ni contro
la programas estos pueden ser desarrollados con lenguajes de 4 generacin y ser co
ntrolados con herramientas CASE.
El usuario creativo se basa en el control del diseo por parte del usuario, atencin
especial a las interacciones de ste con el sistema y evaluacin de su calidad de a
cuerdo con el criterio del mismo usuario.
METODOLOGA PARA EL DESARROLLO DE SISTEMAS
A lo largo de este texto, buscamos mostrar que toda actividad debe estar basada
en una metodologa y en principio, cualquier metodologa es mejor que ninguna; Cua
lquier centro de desarrollo puede montar su metodologa, aunque esta alternativa i
mplica disponer del tiempo necesario para el desarrollo de la nueva metodologa; p
or lo tanto, lo ms prctico es seguir los mtodos que ya han demostrado su validez y
son de aplicacin universal; sepa utilizar el conocimiento cientfico, que
involucra tanto esfuerzo y
sacrificio.
Todas las metodologas; MERISE, YOURDON Y SSADM (structured Sydtem Analysis Design
Method ) y tantas otras, consideran el hecho informtico dividido en fases, cuyo
conjunto forma el ciclo de vida de un sistema informtico.
Todas tienen en comn la idea de descomposicin del hecho informtico en cuatro grande
s grupos
Anlisis
definicin del problema estudio de la situacin actual requisitos a considerar estud
io de factibilidad
Diseo lgico
anlisis funcional
definicin de datos y procesos modelizacin

Diseo fsico creacin de ficheros y tablas elaboracin de programas
Implementacin y control Formacin del usuario implantacin del sistema explotacin
del sistema Mantenimiento
Esta metodologa la podr encontrar en un amplio universo bibliogrfico,
nosotros nos concentraremos, como lo describimos en la introduccin de la obra en
las metodologas simplificadas.
METODOLOGA ESTRUCTURADA SIMPLIFICADA.
Todo proceso de desenvolvimiento de software usando metodologa Estructurada simpl
ificada est basado en la identificacin de los eventos a los que el sistema debe re
sponder.
La secuencia metodolgica es al siguiente:
Definir la lista de eventos
Desarrollar una lista de requerimientos en lenguaje natural segn lo descripto en
el punto 4.2.1.
Producir un diagrama de contexto
Modelizar la relacin del sistema con el contexto, determinando cuales son las rea
s de la empresa que participarn del sistema como fuentes de informacin (ver 4.2.2.
El diagrama de flujo de datos, objetivos).
Definir el modelo comportamental
Utilizamos el DFD como herramienta modeladora de la transformacin de las entradas
en salidas (ver 4.2.2. el diagrama de flujo de datos ).
Definir el modelo de datos
Modelizar la relacin de los repositorios de datos co n la tcnica del Modelo Relaci
onal de Datos. -RDM (ver 4.4. Modelizacin de datos almacenados).
Crear el modelo de implementacin del usuario
Definir los mdulos del sistema. En esta etapa son decididos los procesos a ser au
tomatizados; se somete a la evaluacin del usuario cada proceso del modelo comport
amental (ver 4.7. mdulos del sistema ).
Definir los requisitos de implementacin
Mientras son definidos los procesos a ser informatizados, se debe discutir y doc
umentar los requisitos de implementacin de esos procesos y del sistema de softwar
e como un todo: Desempeo, restricciones de costos, restricciones operacionales, c
onsideraciones sobre seguridad y auditora, tecnologa a ser empleada, modificacione
s en procedimientos manuales y en otros sistemas
informatizadas ya existentes.
Elaborar diagramas de estructura. (ver cap. 4 el rbol de un sistema)
Para cada proceso a ser automatizado, ser creado un diagrama de estructura. Las f
unciones de los diagramas son derivadas de los flujos de datos que entran y que
salen de los proceso, y de las transformaciones que generan los datos de salida
a partir de los datos de entrada.
Integrar los diagramas de Estructura.
Los diagramas de estructura deben ser integrados en programas, el agrupamiento d

e funciones puede ser hecho por proximidad temporal de utilizacin, rutinas On-Lin
e, mensual, anual, etc., o por cualquier otro tipo de afinidad, como por ejemplo
, en el caso de sistemas distribuido, el agrupamiento es hecho conforme al proce
sador en que sern ejecutadas las funciones. La estructura del software es complet
ada, incorporndose a l mdulos de apoyo operacional, como: mdulos de implementacin de
backups, mdulos de control, mdulos para la creacin y restauracin de ndices, mdulos pa
a alteracin de parmetros de operaciones, etc. estos mdulos sern incorporados al Diag
rama de estructura, donde el acceso a ellos fuese mas conveniente
Proyectar la interfaz con el usuario
La parte mas importante y mas compleja de la interfaz con el usuario ser desarrol
lada a partir de los flujos de datos de entrada y de salida de los procesos a se
r automatizados. Una nica interfaz puede ser generada para atender varios flujos
simultneamente. Las interfaces necesarias a los mdulos que implementan mens de sel
eccin y a los mdulos de apoyo operacional complementaran el proyecto de la interfa
z con el usuario.
Proyectar la base de datos fsica
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).
ermiten:
os sistemas,




ciones.

los
ficiente.

rpidamente.
Verificacin
de
condicin
correcta.
Confeccione
y
utilice
rastreable.
1.
2.
3.

zo de disear
ser utilizado

sacrificio.
s grupos
Anlisis
io de factibilidad
Diseo lgico
anlisis funcional
sponder.
el punto 4.2.1.


z con el usuario.

. 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.
ejemplo
de
ello,
es
la
aplicacin
de
los
sistemas
expertos.


Gantt.
el mnimo costo.
a)
b)
c)

del proyecto.
sern
$ El dinero.
De Costo;
De Sensibilidad.
cua
de una gr
de lo
valor e
la

nar:

Fsicos
Perifricos
(Unidades
de
entrada,
lgicos
o
o
de
o
o
etos)
o
o
o
o
o
o
o
la
Unidades

humanos
Seleccin
Formacin
Incentivos

la recuperacin
puedan tomar
supervivenc
un recurso



sta

1.01.01
Unidad Cantidad
1.01.02
1.02.01
2.01.01
3.01.01
4.01.01
4.01.02
Disco rgido ATA 66
Sonido de 16 bit
Pentium III 500Mhz
Pentium III 800Mhz
Resma 100 hojas

10
20
20
5
25
7
8
9
Cdigo proveedor
eedor
001
002
003
Inca Tel
Infocad
Herrera Compusistem
4923-4803
4633-2520
4232-7711
Av.
La
Plata 365
Doblas 1578
Av.
Rivadavia 3558

Cdigo proveedor
001
Cdigo del artculo
Precio
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
UCTOS;
OVEEDORES y;
o procesan datos.

TIPOS DE ARCHIVO
ARCHIVO MAESTRO
PAGO
DE
COMPRAS,
PROGRAMA
DE
PRODUCC
IN;
PRESUPUESTO

stintos registros.
el archivo.
INDICES DE ACCESO
acin deseada.
obre el mundo real.
actos.
.
.
LISTA DE EVENTOS.

a
la
diversas
alternat
ivas
veamos los
siguient
es
a, entran en
juego
muchas
acepciones
Compras se
efiere a:
en
insumos y/o
bienes de
capital?.

conceptos.
ICITUD DE COMPRA
uario del producto.
ertidumbre.
espacho.

ess Model).
1.
te sistema;
2.
3.
4.

a ser realizados;

olos :
1.
es.
estudio.
stema.

ario de datos).
1.
2.

y ms rpida.
3.
4.
irn para ellas.
por dicho proceso.
l sistema.

del objeto.
Smbolo
=
+
( )
{ }
Descripcin
Est compuesto de
Y
Opcional
(puede estar
* *
|
@

Comentario
presente
o ausente)


nal de
Datos
:
1.
a Entidad al RDM.
2.
nte en
cin.
TIPOS DE RELACIONES
y varios a
Relacin uno a uno.
BENEFICIOS DEL RDM
1.
stema.
2.
fue
ron
3.
4.
5.
e
base de datos.
tema proyectado.
s a relacionar,
)
PERSONAS.
s dos direcciones.

nico elemento.


dad PROFESOR.
de la relacin?
OFESOR.
ofesores
or.
?
nados horarios.
SIN.
NORMALIZACIN.
etivo:
.
Proporcionar
la
flexibilidad
necesaria
para
soportar
de bases de datos.
s datos

s y relaciones.
).
ependientes.
perdidas.
o.
Producto
Negocio
Producto
Negocio Telfono
ARROZ Coto
670-1158
200
500
ARROZ Carrefour
921-4802
1000
POROTO Coto
670-1158
300
500
POROTO Carrefour
921-4802
400
HARINA Coto
670-1158
400
600
HARINA Carrefour
921-4802
1100
AZUCAR Carrefour
921-4802
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
12
6000
200
14
8
3200
8
3200
9
5400
100
7
4
4400
900
5
AZUCAR Ta
449-7448
1200
Precio Total
7700
2800
700
4500
3600

hivo?

aria?

mo

;
Producto
Negocio
ARROZ Coto
200
ARROZ Disco 500
ARROZ Carrefour
ARROZ Jumbo 1000
POROTO Coto
300
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
Precio Total
7700
POROTO Macro 500

12
6000
POROTO Carrefour
200
14
2800
POROTO Jumbo 400
8
3200
HARINA Coto
400
8
3200
HARINA Macro 600
9
5400
HARINA Carrefour
100
7
700
AZUCAR Disco 1100
4
4400
AZUCAR Carrefour
900
5
4500
AZUCAR Ta
1200
3
3600
Negocio Direccin
Telfono
Coto
670-1158
923-3951
Carrefour
Av. La Plata 2222
921-4802
Jumbo Av. Cruz 4897 342-6400
923-4377
Ta
Av. Rivadavia 7788
449-7448
o y de nada ms.
normal
ocio.
dor nico.
ro campo no-llave?
forma normal.
de informacin.
Producto
ARROZ Coto
ARROZ
ARROZ
ARROZ
POROTO
POROTO
POROTO
POROTO
HARINA
HARINA
HARINA
AZUCAR
AZUCAR
AZUCAR
Negocio Cantidad
200
10
Disco 500
Carrefour
Jumbo 1000
Coto
300
Macro 500
Carrefour
Jumbo 400
Coto
400
Macro 600
Carrefour
Disco 1100
Carrefour
Ta
1200
9
700
8
13
12
200
8
8
9
100
4
900
3
Precio
11
14
7
5
FLUJOGRAMAS

Los bl

TABLAS DE DECISIN
esquema:
REGLAS
1

su corroboracin
3
tivamente
4
5
6
7

jecutar.
uientes:
a un PROVEEDOR
el RDM.
Una regla prctica :

1)
por software,
2)
zado de sus datos
3)
us datos.
e los mdulos.
del sistema.

cesaria.
r Computacin.


Algunos de los componentes de las herramientas CASE p

ejemplo
de
ello,
es
la
aplicacin
de
los
sistemas
expertos.

Gantt.

el mnimo costo.
a)
b)
c)

del proyecto.
sern
$ El dinero.
De Costo;
De Sensibilidad.
cua
de una gr
de lo
valor e
la

nar:
o
o
de
Fsicos
Perifricos
(Unidades
de
entrada,
la
Unidades
o
o
etos)
o
o
o
o

lgicos
o
o
o

humanos
Seleccin
Formacin
Incentivos

la recuperacin
puedan tomar
supervivenc
un recurso



sta

1.01.01
Unidad Cantidad
1.01.02
1.02.01
2.01.01
3.01.01
4.01.01
4.01.02
Disco rgido ATA 66
Sonido de 16 bit
Pentium III 500Mhz
Pentium III 800Mhz
Resma 100 hojas

10
20
20
5
25
7
8
9
Cdigo proveedor
eedor
001
002
003
Inca Tel
Infocad
Herrera Compusistem
4923-4803
4633-2520
4232-7711
Av.
La
Plata 365
Doblas 1578
Av.
Rivadavia 3558

Cdigo proveedor
001
Cdigo del artculo
Precio
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
UCTOS;
OVEEDORES y;
o procesan datos.

TIPOS DE ARCHIVO
ARCHIVO MAESTRO
PAGO
DE
COMPRAS,
PROGRAMA
DE
PRODUCC
IN;
PRESUPUESTO

stintos registros.
el archivo.
INDICES DE ACCESO
acin deseada.
obre el mundo real.

actos.
.
.
LISTA DE EVENTOS.

a
la
diversas
alternat
ivas
veamos los
siguient
es
a, entran en
juego
muchas
acepciones
Compras se
efiere a:
en
insumos y/o
bienes de
capital?.
conceptos.
Lo que se busca con un modelo sintctico es lograr una comunicacin buena
y eficaz
ICITUD DE COMPRA
uario del producto.
ertidumbre.
espacho.

ess Model).
1.
te sistema;
2.
3.
4.

a ser realizados;

olos :
1.
es.
estudio.
stema.
ario de datos).

1.
2.

y ms rpida.
3.
4.
irn para ellas.
por dicho proceso.
l sistema.

del objeto.
Smbolo
=
+
( )
{ }
Descripcin
Est compuesto de
Y
Opcional
(puede estar
* *
|
@

Comentario
presente
o ausente)

nal de
Datos
:
1.
a Entidad al RDM.
2.
nte en
cin.
TIPOS DE RELACIONES
y varios a
Relacin uno a uno.
BENEFICIOS DEL RDM
1.
stema.
2.
fue
ron
3.
4.
5.
e
base de datos.
tema proyectado.
s a relacionar,
)
PERSONAS.
s dos direcciones.

nico elemento.


dad PROFESOR.
de la relacin?
OFESOR.
ofesores

or.
?
nados horarios.
SIN.
NORMALIZACIN.
etivo:
.
Proporcionar
la
flexibilidad
necesaria
para
soportar
de bases de datos.
s datos

s y relaciones.
).
ependientes.
perdidas.
o.
Producto
Negocio
Producto
ARROZ Coto
Negocio Telfono
670-1158
200
Cantidad
10
2000
Precio Total
ARROZ
ARROZ
ARROZ
POROTO
POROTO
POROTO
POROTO
HARINA
HARINA
HARINA
AZUCAR
AZUCAR
Disco 923-3951
500
Carrefour
921-4802
Jumbo 342-6400
1000
Coto
670-1158
300
Macro 923-4377
500
Carrefour
921-4802
Jumbo 342-6400
400
Coto
670-1158
400
Macro 923-4377
600
Carrefour
921-4802
Disco 923-3951
1100
Carrefour
921-4802
AZUCAR Ta
449-7448
1200
9
700
8
13
12
200
8
8
9
100
4
900
4500
11
8000
3900
6000
14
3200
3200
5400
7
4400
5
3600
7700
2800
700
4500

hivo?

aria?

mo

;
Producto
Negocio
ARROZ Coto
200
ARROZ Disco 500
ARROZ Carrefour
ARROZ Jumbo 1000
POROTO Coto
300
Cantidad
10
2000
9
4500
700
11
8
8000
13
3900
Precio Total
7700
POROTO Macro 500

12
6000
POROTO Carrefour
200
14
2800
POROTO Jumbo 400
8
3200
HARINA Coto
400
8
3200
HARINA Macro 600
9
5400
HARINA Carrefour
100
7
700
AZUCAR Disco 1100
4
4400
AZUCAR Carrefour
900
5
4500
AZUCAR Ta
1200
3
3600
Negocio Direccin
Telfono
Coto
670-1158
923-3951
Carrefour
Av. La Plata 2222
921-4802
Jumbo Av. Cruz 4897 342-6400
923-4377
Ta
Av. Rivadavia 7788
449-7448
o y de nada ms.
normal
ocio.
dor nico.
ro campo no-llave?
forma normal.
de informacin.
Producto
ARROZ Coto
ARROZ
ARROZ
ARROZ
POROTO
POROTO
POROTO
POROTO
HARINA
HARINA
HARINA
AZUCAR
AZUCAR
AZUCAR
Negocio Cantidad
200
10
Disco 500
Carrefour
Jumbo 1000
Coto
300
Macro 500
Carrefour
Jumbo 400
Coto
400
Macro 600
Carrefour
Disco 1100
Carrefour
Ta
1200
9
700
8
13
12
200
8
8
9
100
4
900
3
Precio
11
14
7
5
FLUJOGRAMAS

Los bl

TABLAS DE DECISIN
esquema:
REGLAS

su corroboracin
3
tivamente
4
5
6
7

jecutar.
uientes:
a un PROVEEDOR
el RDM.
Una regla prctica :
1)
por software,
2)
zado de sus datos
3)
us datos.
e los mdulos.
del sistema.

cesaria.

r Computacin.


Algunos de los componentes de las herramientas CASE permiten:
os sistemas,



ciones.


los
ficiente.
rpidamente.
Verificacin
de
condicin
correcta.
Confeccione
y
utilice
rastreable.
1.
2.
3.

zo de disear
ser utilizado
sacrificio.
s grupos
Anlisis
io de factibilidad
Diseo lgico
anlisis funcional
sponder.

el punto 4.2.1.

z con el usuario.
. Flujogramas).
ermiten:
os sistemas,



ciones.

los
ficiente.
rpidamente.
Verificacin
de
condicin
correcta.
Confeccione
y
utilice

rastreable.
1.
2.
3.

zo de disear
ser utilizado

sacrificio.
s grupos
Anlisis
io de factibilidad
Diseo lgico
anlisis funcional
sponder.
el punto 4.2.1.


z con el usuario.
. Flujogramas).

Denuevo

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Denuevo

Încărcat de

Drepturi de autor:

Formate disponibile

INICIO DE UN PROYECTO NFORMTICO

En un entorno informtico estable, la decisin de iniciar un proyecto viene dada por

Segn Rusell Ackoff, la esencia de la sabidura es la preocupacin por el futuro; pero

La planificacin consiste en disear un futuro deseable y seleccionar o crear formas

proporcional al tiempo requerido para su ejecucin. El objetivo de este grfico es e

Las tareas a desarrollar

La relacin o dependencia entre las tareas

El tiempo Planeado para la ejecucin de cada tarea

FIGURA2.2 Diagrama de GANTT.

Entre tantas condiciones comerciales, en la que se puede estimar

sensibilidad, podemos citar:

Estructuras de almacenamiento (Base de datos relacional, orientada a obj

El conjunto unificado de informacin, resultante de nuestro proyecto informtico y,

Dependiendo de la capacidad de almacenamiento y procesamiento del hardware, la o

se cuente con microcomputadoras, y

Mientras tanto las Grandes organizaciones poseen computadoras de gran porte, y e

necesita de un Sistema de Gestin de Base de Datos (SGBD o DBMS). Los sistemas de

Unidad Unidad Caja de 10 Unidad

Nombre del proveedor

Telfono del proveedor Direccin del prov

ARCHIVO DE ORIGEN DE LOS PRODUCTOS

Cdigo del artculo

Los archivos de control contienen datos de los archivos maestros y de transaccio

Figura 3.1.1. Flujo de informacin entre los distintos tipos de archivos

Evitar el uso de casos en lugar de conceptos generales.

Hacer explcitas las referencias entre trminos.

del sistema, determinando lo que ocurrir en cada un

En otras palabras, el DFD permite representar de forma completa el sistema de in

onocimiento previo de informtica.

externas son diseadas sobre los

Eleccin de una de las opciones

Separa opciones de alternativas en la construccin [ ]

FIGURA 4.2 Diccionario de Datos - Descripcin

FIGURA 4.3 Diccionario de Datos - Estructura

FIGURA 4.4.3. Direccionalidad de las relaciones

FIGURA 4.4.5 Unin de dos entidades relacionadas uno a uno

La relacin siempre ser uno a uno?

Coto, Disco, Carrefour, Jumbo

SEGUNDA FORMA NORMAL (2FN).

un campo, preguntamos tambin:

, por s solo no es suficiente para identificar inequvocamente un determinado regis

Disco Emilio Mitre 515

FIGURA 5.5 FLUJOGRAMA

Es una tcnica de aplicacin en el anlisis y diseo de sistema y procedimientos: presen

Definir e interpretar el problema (cuidado con las obviedades);

Poner por escrito en lenguaje narrativo el planteo del problema a fin de

Registrar los valores de las condiciones y de las acciones.

Discutir los resultados con los usuarios

La especificacin de los mdulos se realizar hasta el punto en que se tenga un modelo

En la introduccin del Libro describimos que en los Proyectos Informticos, desarrol

Figura 5.1 Modelo del Proceso de Negocio

Figura 5.2 Modelo Relacional de Datos

Segn Rusell Ackoff, la esencia de la sabidura es la preocupacin por el futuro; pero

Las tareas a desarrollar

La relacin o dependencia entre las tareas

El tiempo Planeado para la ejecucin de cada tarea

FIGURA2.2 Diagrama de GANTT.

Entre tantas condiciones comerciales, en la que se puede estimar

sensibilidad, podemos citar:

CONSIDERACIONES EN UN PLAN ESTRATGICO INFORMTICO

Estructuras de almacenamiento (Base de datos relacional, orientada a obj

El conjunto unificado de informacin, resultante de nuestro proyecto informtico y,

Dependiendo de la capacidad de almacenamiento y procesamiento del hardware, la o

se cuente con microcomputadoras, y