Analisis de Un Proyecto

NDICE
PROYECTO INFORMTICO
INTRODUCCIN
1 PROYECTO
1.1. QU ES UN PROYECTO INFORMTICO
1.2. INICIO DE UN PROYECTO NFORMTICO
2. PLANEAMIENTO DE UN PROYECTO INFORMTICO
2.1. MTODOS DE PLANIFICACIN TEMPORAL DE TAREAS
2.2. MTODOS PARA PLANIFICACIN DE RECURSOS
PLANIFICACIN FINANCIERA
2.3. CONSIDERACIONES EN UN PLAN ESTRATGICO INFORMTICO
3. BASE DE DATOS
3.1. ESTRUCTURA DE UNA BASE DE DATOS
3.1.1.TIPOS DE ARCHIVO
ARCHIVO MAESTRO
ARCHIVO DE TRANSACCIONES
ARCHIVOS DE CONTROL
ARCHIVO DE PLANEAMIENTO
3.1.2.LLAVE PRIMARIA O IDENTIFICADORA

3.1.3.INDICES DE ACCESO
4. HERRAMIENTAS DE ANLISIS
4.1. MODELOS CONCEPTUALES
4.2. LA MODELIZACIN DE LAS FUNCIONES DEL SISTEMA
4.2.1. LISTA DE EVENTOS
TCNICA PARA EL DISEO DE UNA LISTA DE EVENTOS
4.2.2. EL DIAGRAMA DE FLUJO DE DATOS

TCNICA DE DISEO DEL DFD
RESTRICCIONES DEL DFD
RECOMENDACIONES PARA UN DFD

4.3.EL DICCIONARIO DE DATOS
CONTENIDO DEL DICCIONARIO DE DATOS
4.4. LA MODELIZACIN DE DATOS ALMACENADOS
EL MODELO RELACIONAL DE DATOS (RDM)
TIPOS DE RELACIONES
BENEFICIOS DEL RDM
TECNICA DE DISEO DEL RDM
Diseo de la Relacin uno a uno
Diseo de la Relacin uno a varios
Diseo de la Relacin varios a varios
NORMALIZACIN
PRIMERA FORMA NORMAL (1FN)
SEGUNDA FORMA NORMAL (2FN)
TERCERA FORMA NORMAL (3FN)
4.5.FLUJOGRAMAS
4.6. TABLAS DE DECISIN
4.7. MODULOS DE UN SISTEMA
EL RBOL DE UN SISTEMA
ESPECIFICACIN DE LOS MDULOS DEL SISTEMA
5. HERRAMIENTAS CASE
QUE ES UNA HERRAMIENTA
COMO OPERA UNA HERRAMIENTA CASE
6. DESARROLLO
CARACTERSTICAS EN TODA METODOLOGA DE PROCESAMIENTO DE DATOS
6.1. METODOLOGA PARA EL DESARROLLO DE SISTEMAS
6.2. METODOLOGA ESTRUCTURADA SIMPLIFICADA
BIBLIOGRAFA
Introduccin
Los cambios tecnolgicos, producidos en los ltimos 10 aos, le han permitido a los
profesionales que actan en el rea de administracin tener acceso a una gran cantidad de
recursos informticos y en la actualidad estos recursos informticos son manejados por los
propios usuarios. Pues as como la tecnologa fue perfeccionando al automvil hasta hacer
innecesario al conductor profesional, la misma tecnologa va perfeccionando la interfaz entre
el usuario y el computador; de modo tal que los administradores al utilizar aplicaciones
informticas, para mejorar sus procedimientos de trabajo, ya no precisan de un especialista en
programacin.
Sin embargo, en la actualidad, se puede percibir que para aplicaciones simples y sin
sofisticaciones, a ser desarrolladas por ejemplo con procesadores de textos y planillas de
clculo, los usuarios pueden realizarlas sin mayores dificultades; pero estos mismos usuarios,
comienzan a tener serias dificultades cuando precisan aplicar recursos que apenas usan
eventualmente, o cuando interactan con sistemas que exigen un conocimiento ms
conceptual y especfico de computacin.
Es por ello que en proyectos administrativos desarrollados por profesionales de la
administracin en pequeas y medianas empresas, con la utilizacin de microcomputacin,
el profesional se encuentra con una gran dificultad en la utilizacin de metodologas para la
automatizacin de procedimientos administrativos. Especialmente debido: a las exigencias y al
esfuerzo adicional que requiere la elaboracin de modelos, a la gran cantidad
de documentacin necesaria y a la falta de dominio de mtodos.
Este trabajo busca presentar una metodologa, basada en tcnicas estructuradas simplificadas,
para el desarrollo de proyectos informticos de pequeo y mediano porte, y que tengan como
objetivo la automatizacin de tareas administrativas. Esta metodologa se encuentra apoyada en
el uso de herramientas de Ingeniera de Software Asistida por el Computador (Computer Aided
Software Engineering -CASE-).
Las herramientas y la metodologa, que aqu veremos, apoyan las etapas de anlisis del sistema,
anlisis de los requerimientos de los usuarios y diseo del software, siendo adecuadas para
proyectos que no requieran ms de dos o tres hombres por mes, coordinados por un
proyectista.
Con referencia a las tcnicas simplificadas, cabe aclarar que el trmino simplicidad de ninguna
manera puede confundirse o asociarse al de sencillo, tosco o burdo; una tcnica simplificada
significa que cuando un proyecto informtico se cumple satisfactoriamente y para ello se han
empleado en l: menor cantidad de personal, menor cantidad de recursos tcnicos y adems se
ha realizado en un tiempo menor, resulta pues un perfeccionamiento evidente del acto
informtico.
Puede decirse entonces que en informtica aplicada a administracin, simplificacin y
perfeccionamiento son la misma cosa, con la inteligencia necesaria para cumplimentar el
requisito fundamental de todo proyecto que es la solucin de un problema, o al menos el
mejoramiento de una situacin dada.

En otras palabras, llegar al final por el camino ms corto y sencillo significa, indudablemente,
un progreso; y cuando ante cualquier procedimiento se deja en el nimo del observador la
impresin de que el mismo ha sido fcil, es sin duda alguna, porque se ha efectuado con:
pulcritud, sencillez, tiempos bien reglados y con prescindencia de procedimientos redundantes y
recursos intiles; vale decir, se ha efectuado con una buena tcnica.
Partiendo de estos razonamientos y hechos de observacin, los conceptos de simplificacin y
orden riguroso, son inversos a los equipos de trabajo numerosos y al instrumentismo exagerado.
Sin llegar a la torpeza de desarrollar un proyecto absolutamente solo, puede decirse que en la
mayora de los proyectos informticos, aplicados a administracin, se pueden realizar muy bien
con un solo ayudante. El secreto estar en saber disponer de las herramientas necesarias,
seleccionarlas segn sea el problema a ser abordado, y desarrollar un buen plan para su uso.
Destaco tanto el aspecto de las tcnicas simplificadas, pues pienso en las distintas alternativas
que vivenciar un profesional; pues si al profesional le tocara desarrolla su actividad en un
medio mal provisto, sentir un gran alivio de poder hacerlo sin mayores recursos de personal y
herramientas. Si, por el contrario, tuviera que desempear su profesin en un medio mejor
dotado, tendr tiempo para rodearse de comodidades; que no siempre redundarn en beneficio
del usuario.
1 PROYECTO
Un
proyecto
es
esencialmente
un
conjunto
de actividades interrelacionadas, con un inicio y una finalizacin definida,
que utiliza recursos limitados para lograr un objetivo deseado.
Los dos elementos bsicos que incluye esta definicin son: las actividades y los recursos.
LAS ACTIVIDADES son las tareas que deben ejecutarse para llegar en conjunto a un fin
preestablecido (objetivo deseado); por ejemplo: recopilar informacin; realizar diagnsticos;
confeccionar un diseo global de un procedimiento, programar, escribir manuales de
procedimiento, etc. (ver 6.1. metodologa para el desarrollo de sistemas)
Un aspecto fundamental en todo proyecto es el orden en el cual se realizan las actividades. Y
para determinar la secuencia lgica de las actividades se debe establecer
el mtodo, el tiempo y el costo de cada operacin.
LOS RECURSOS son los elementos utilizados para poder realizar la ejecucin de cada una de
las tareas; como por ejemplo: hardware, programas de base (sistemas operativos), programas de
aplicacin, discos de almacenamiento, energa, servicios, inversiones de capital, personal,
informacin, dinero y tiempo (ver 2.3 consideraciones en un plan estratgico
informtico).
Entonces: El fin primario de desarrollar un proyecto debe ser producir un programa
calendario en el cual los recursos, siempre limitados, se asignen a cada una de
las actividades en forma econmicamente ptima.
Estas limitaciones en cuyo contexto se resuelve planear un proyecto pueden ser internas, por
ejemplo: computadoras disponibles, capacidad del personal, disposiciones presupuestarias, o
bien externas, como ser: fechas de entrega de cualquier tipo de recursos, factores climticos,
aprobaciones de organismos oficiales. En ambos casos las limitaciones deben tenerse
particularmente en cuenta al estimar los tiempos de cada actividad.
En cuanto al objetivo del proyecto, este puede ser sencillo y no demandar ni muchas tareas ni
demasiados recursos; o por el contrario, puede ser complejo y exigir mltiples actividades y una
gran cantidad de recursos para poder alcanzarlo.
Pero independientemente de su complejidad, caractersticamente todo proyecto rene la
mayora de los siguientes criterios:
1. Tener un principio y un fin

2. Tener un calendario definido de ejecucin
3. Plantearse de una sola vez
4. Constar de una sucesin de actividades o de fases
5. Agrupar personas en funcin de las necesidades especficas de cada
actividad
6. Contar con los recursos necesarios para desenvolver las actividades

Ahora piense por un instante en cada uno de los proyectos que se desarrollan en las
organizaciones, y ver que todos ellos tienen cometidos que deben cumplirse en un cierto plazo
de tiempo y que adems requieren de la concurrencia de otras personas.
Y es aqu donde empieza a tener relevancia la figura del administrador, en los proyectos a
realizarse en las organizaciones; incluidos los proyectos informticos.
Creo importante traer el pensamiento de Deming, quien seala y remarca muy claramente, al
presentar su teora de Calidad Total, que el administrador de un proyecto al planificar las
actividades, debe tener presente que los mejores esfuerzos constituyen un elemento esencial;
pero desgraciadamente, si estos esfuerzos se toman aisladamente sin una debida orientacin
basada en principios administrativos, stos esfuerzos pueden causar profundos daos.
La necesidad de la consistencia en los esfuerzos supone que si cada uno sabe lo que tiene que
hacer y, que si cada uno hiciese lo mejor que puede, el resultado sera la dispersin del
conocimiento y de los esfuerzos; por lo tanto, no hay nada que substituya al trabajo en equipo y
a los buenos lderes, para alcanzar una consistencia entre los esfuerzos y el conocimiento
necesario.
Algo importante a tener siempre presente es que: si el administrador realiza un buen trabajo en
la gestin del proyecto, su xito podr ser visto y verificado por los dems; en caso contrario,
naturalmente, el fracaso tambin estar a la vista de todo el mundo. La responsabilidad es muy
alta: alcanzar el objetivo o no. Pero la oportunidad de "demostrar la capacidad profesional", es
de las que no pueden dejarse pasa por alto.

Los administradores eficaces de proyectos, son los que logran que el trabajo se ejecute
a tiempo, dentro del presupuesto, y conforme a las normas de calidad especificadas.
1.1. QU ES UN PROYECTO INFORMTICO

De la definicin de proyectos, vista en el punto anterior, podemos aplicarla a los proyectos
informticos; y decir que: un proyecto informtico es un sistema de cursos de accin
simultneos y/o secuenciales que incluye personas, equipamientos de hardware, software y
comunicaciones, enfocados en obtener uno o ms resultados deseables sobre un sistema de
informacin.
En el captulo 6, presentaremos cules son las tareas y en qu secuencia deben realizarse
(Metodologa estructurada) para alcanzar el objetivo. Ahora vamos a describir los
distintos objetivos que caracterizan a un proyecto informtico.
El inicio de un proyecto informtico generalmente est dado en la solicitud de requerimientos
de los usuarios, y siendo que los diferentes sistemas de Informacin abordan los diferentes tipos
de problemas organizacionales; podemos clasificar a los Sistemas de Informacin segn sean
las aplicaciones que necesite cada usuario en: Sistemas de Transacciones, Sistemas de Soporte
para la toma de decisiones, y Sistemas Expertos.
FIGURA1.1 Clasificacin de los sistemas de informacin

Tambin una buena manera de abordar la estructura conceptual para los sistemas de
informacin, es desde los trabajos de Gorry y Scott Morton. En el que relacionan el trabajo
fundamental de Herbert.A.Simon sobre la decisin estructurada y no estructurada, con el
planeamiento estratgico, control gerencial y control operacional de Anthony.

Simon divide la toma de decisiones en tres fases: Inteligencia Diseo y Eleccin; en una
decisin estructurada, las tres fases son totalmente inteligibles y computables por el decisor
humano; por lo cual esa decisin es programable. En una decisin no estructurada no hay pleno
entendimiento de una o algunas de esas fases.
Henry C. Lucas tambin toma a dichos trabajos, para poder diferenciar los distintos tipos de
sistemas a fin de llegar a una implementacin exitosa, de sistemas de informacin
computarizados.
La siguiente tabla muestra la estructura conceptual de Gorry y Scott Morton.:
Control
operacional
Control Gerencial
Estructura Cuentas a Cobrar Anlisis

do
presupuestario
Ingreso de pedidos
costos proyectados
Control de
Inventarios
Planeamient
o Estratgico
Ubicacin de
depsitos y
fabricas
Presupuesto a corto plazo
SemiProgramacin de
estructura la Produccin
do
Administracin de /
fondos
Preparacin del
presupuesto
NoSistema PERT y
estructura - / de Costos
do
Ventas y Produccin
Anlisis de Varianza
presupuesto total
Planeamiento
de nuevos
productos
Fusiones y
Absorciones
Planeamiento
de
investigacin y
desarrollo
Los recursos mas frecuentemente utilizados que caracterizan a un sistema de informacin, son
los componentes de la Tecnologa de la Informacin ( TI ) como ser el uso de Hardware,
Software y Comunicaciones.
En cuanto a estos elementos de la Tecnologa de la Informacin, podemos considerar que ya han
llegado a un desarrollo ms que suficiente para la aplicacin en una operacin informtica. Lo
que nos lleva a que la gestin de un hecho informtico como un proyecto integral, tanto sea en
su entorno de diseo, como en su planificacin y control, definen una nueva etapa; una mayora
de edad en el tratamiento informtico.
Es as que hoy dada la evolucin en la Tecnologa de la Informacin, los proyectos de
aplicacin tpicamente administrativos, desarrollados principalmente en pequeas y medianas
empresas, y que desarrollan su planeamiento informtico basado en el uso de las
microcomputadoras; puedan ser administrados por un nico profesional
Es por todo esto que, los conceptos de Proyecto y de Metodologa de diseo que, hasta hace
poco tiempo, eran solamente aplicados a grandes emprendimientos; hoy tambin deben ser
aplicados a medianos y pequeos emprendimientos.
Considerando entonces, la importancia que la informtica tiene en los planes estratgicos de
cualquier empresa moderna; no solamente se debe tener en cuenta la evolucin de los recursos
de la tecnologa de la informacin, sino tambin las distintas metodologas para el desarrollo de
los sistemas de informacin.
As es que, el solo hecho de considerar a un asunto informtico como un proyecto al que se
asocian tcnicas y procedimientos de diseo, supone un paso importante.
1.2. INICIO DE UN PROYECTO NFORMTICO

Ya vimos una clasificacin (ver figura 1), que nos permite clarificar el origen de un proyecto
informtico, pero cmo podremos determinar la magnitud de un Proyecto informtico?.
En un entorno informtico estable, la decisin de iniciar un proyecto viene dada por las
necesidades de: mantenimiento, modificacin, mejoramiento, reemplazo o capacidad;
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 (ver 6.1. metodologa para el desarrollo de sistemas) e
involucra solucionar fallas menores del sistema, que obligar a la realizacin de cambios en el
programa; como por ejemplo el descuido de no considerar que puedan ocurrir en el sistema,
ciertas condiciones extraordinarias; como sera el caso de un aumento no previsto del 60 %, en
la emisin de rdenes 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 nmero 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 implement un sistema
de inventarios, este sistema no inclua un modulo para calcular la futura 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 fsicamente,
tecnolgicamente o competitivamente obsoletos. Como es el caso de la utilizacin del lser, en
el reconocimiento ptico de caracteres para la lectura del cdigo de 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 modelizar 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
2. PLANEAMIENTO DE UN PROYECTO INFORMTICO
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 necesaria, y la
asignacin de recursosnecesarios para alcanzar el objetivo del proyecto 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 momento de planificar, hay
que considerar, las tareas y los recursos; con el mismo grado de importancia.(ver. 1.1 que es
un proyecto informtico).
2.1. MTODOS DE PLANIFICACIN TEMPORAL DE TAREAS

La planificacin temporal de un proyecto de software, no difiere mucho de la de cualquier otro
esfuerzo de desarrollo multitarea. Adems, se pueden utilizar las tcnicas y herramientas
generales de planificacin temporal de proyectos para el desarrollo de software, con pequeas
modificaciones; entre ellas podemos citar a la tcnica 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
Technique-PERT) y el mtodo del Camino Crtico (Critical Path Method-CPM) son
dos mtodos de planificacin temporal de proyectos que pueden aplicarse al desarrollo de
proyectos informtico. Ambas tcnicas desarrollan una descripcin de la red de tareas del
proyecto, es decir, una representacin grfica o tabular de las tareas que deben realizarse desde
el principio hasta el final del proyecto.
En el mtodo PERT/CPM se coordinan todos los elementos de un proyecto en un plan maestro,
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 proyecto especfico,
y una lista de secuencia, 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 adelantos 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 actividades crticas, as como la
influencia de limitaciones y las posibles soluciones de situaciones conflictivas
3. BASE DE DATOS
El conjunto unificado de informacin, resultante de nuestro proyecto
informtico y, que ser compartida por los diferentes usuarios de la
organizacin, va a conformar la denominada Base de Datos.
La funcin bsica de una base de datos es permitir el almacenamiento y la recuperacin de la
informacin necesaria, para que las personas de la organizacin puedan tomar decisiones. Es as
que las Bases de Datos se tornan esenciales para la supervivencia de cualquier organizacin;
pues los datos estructurados constituyen un recurso bsico para todas las organizaciones.
Dependiendo de la capacidad de almacenamiento y procesamiento del hardware, la
organizacin puede contar con una nica Base de Datos, o con mltiples Bases de Datos.
Es comn que en las pequeas y medianas empresas se cuente con microcomputadoras, y por
ello tengan que distribuir su informacin en un conjunto de Bases de Datos; asignndole a cada
una de ellas, informacin sobre cada rea especfica de la empresa. Un ejemplo sera el de
contar con una base de datos para el almacenamiento de la informacin correspondiente al rea
financiera, otra para el rea de personal, una ms para el rea de ventas o el rea de produccin.
Mientras tanto las Grandes organizaciones poseen computadoras de gran porte, y es as que
pueden almacenar toda la informacin necesaria, integrada, consistente y consolidada, 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 Bases de Datos; y en particular, para:
almacenar, manipular y recuperar datos en una 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 obtener informacin, introducir nuevos datos y actualizar los ya
existentes.
3.1. ESTRUCTURA DE UNA BASE DE DATOS.

Una Base de Datos est compuesta por un conjunto de tablas o archivos. Para una mayor
comprensin podemos ejemplificar la siguiente Base de Datos de compras.
ARCHIVO DE PRODUCTOS
Cdigo
artculo
Descripcin del material
Unidad
Cantidad
1.01.01
CD-ROM RW IDE
Unidad
10
1.01.02
Disco rgido ATA 66
Unidad
20
1.02.01
Disco Flexible de 3 1/2" 1,44 Mbytes
Caja de 10
20
2.01.01
Sonido de 16 bit
Unidad
3.01.01
Papel carta para impresora.
Resma 100 hojas
25
4.01.01
Pentium II 200Mhz
Unidad
4.01.02
Pentium III 500Mhz
Unidad
4.01.03
Pentium III 800Mhz
Unidad
ARCHIVO DE PROVEEDORES
Cdigo
proveedor
Nombre del
proveedor
Telfono del
proveedor
Direccin del
proveedor
001
Inca Tel
4923-4803
Av. La Plata 365
002
Infocad
4633-2520
Doblas 1578
003
Herrera
Compusistem
4232-7711
Av. Rivadavia 3558
ARCHIVO DE ORIGEN DE LOS PRODUCTOS

Cdigo
proveedor
Cdigo del
artculo
Precio
001
1.01.01
70,00
002
1.01.01
80,00
003
1.01.01
75,00
002
2.01.01
50
001
4.01.03
450
Esta Base de Datos contiene informacin de tres Entidades:
Datos sobre productos (Entidad producto), almacenados en el

archivo de PRODUCTOS;
Datos sobre proveedores (Entidad proveedores), almacenados en el

archivo PROVEEDORES 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 imaginario, 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 describe, a
travs de los atributos o datos (columna), cada entidad en l almacenado. Un atributo es pues,
cualquier detalle que sirve para identificar, clasificar, cuantificar o expresar el estado de una
entidad.
Todos los registros de un archivo, identificados por las filas de cada tabla, poseen el mismo
formato, o sea tienen el mismo conjunto de datos o atributos, identificados por las columnas,
que describen a las entidades.
En otras palabras los registros estn formados por un conjunto de datos almacenados en los
campos de cada atributo; y cada registro debe contener el conjunto de atributos necesarios, para
describir completamente cada entidad sobre la cual una organizacin necesita almacenar y
obtener informacin.
FIGURA 3.1 Modelo relacional de una tabla
3.1.1.TIPOS DE ARCHIVO
Los archivos pueden clasificarse en cuatro tipos bsicos; que son: los archivos
maestros, los archivos de transacciones, los archivos de control y los archivos de
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 importante de las
actividades de una organizacin, como por ejemplo el archivo de VENDEDORES. 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 VENTAS. Otros ejemplos son los archivos
maestros de: PLAN DE CUENTAS; BANCOS, NMINA DEL PERSONAL, CLIENTES,
VENDEDORES, PRODUCTOS, PROVEEDORES, COMPETIDORES.
ARCHIVO DE TRANSACCIONES.
Un archivo de transacciones es un archivo temporal que persigue bsicamente dos propsitos;
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 resultados 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: REGISTROS CONTABLES, COSTOS, FACTURAS, PAGOS A RECIBIR,
PROCESOS DE EXPORTACIN, CONSULTA DE CLIENTES, PEDIDOS DE CLIENTES Y
PEDIDOS A PROVEEDORES.
ARCHIVOS DE CONTROL.
Los archivos de control contienen datos de los archivos maestros y de transacciones, para
permitir el anlisis del desempeo de la organizacin. Estos archivos generan 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
PROVEEDOR, 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 ejemplo: PROGRAMA DE
VENTAS, PROGRAMA DE COMPRAS, PROGRAMA DE PRODUCCIN; PRESUPUESTO
FINANCIERO. Por lo tanto los datos existentes en un archivo de planeamiento provienen de los
archivos maestros, de transacciones, y de control.
Figura 3.1.1. Flujo de informacin entre los distintos tipos de archivos
3.1.2. 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 identificable del resto de los
registros de esa misma entidad; y quien permite esta identificacin 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 valor
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 distintos 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 nuevo 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.Estructura 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).
3.1.3.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 indexacin, 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 velocidad 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 idntica a su llave primaria. Este ndice es llamado ndice primario.
Tambin es posible crear ndices para un archivo de datos utilizando atributos (campos), 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 localizacin de una determinada informacin
dentro de un archivo o para clasificar los registros del archivo de acuerdo con el orden necesario
para la obtencin de la informacin deseada.
4. HERRAMIENTAS DE ANLISIS
4.1. MODELOS CONCEPTUALES

Un modelo es una descripcin capaz de ser comunicada y que busca:
Comunicar un cierto 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 un modelo mental
que represente esta cosa, como as tambin las acciones que ella puede realizar o se pueden realizar
sobre ella. Cuando el individuo verifica acciones sobre este modelo l puede predecir las
implicaciones que estas acciones tendrn sobre el mundo real.
Segn Sowa, al relacionar las cosas entre s y al pensar de forma estructurara sobre 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 comunes 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 eventos, que describiremos prximamente
(ver 4.2.1. la modelizacin de las funciones del sistema), son ejemplos de modelos
verbales.
Los modelos simblicos generalmente son ms especficos que los verbales; Ellos representan 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 (esquema para modelizar la estructura de
la empresa). La mayora de los modelos simblicos se usan para aislar variables y sugerir las
direcciones de las relaciones, 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
especficos. 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 conjunto y seleccionar las relaciones a
examinar..
Algunos modelos pueden combinar componentes icnicos y anlogos; como por ejemplo
los flujogramas (ver 4.5. flujogramas), dichos diagramas por lo general tienen carcter
cualitativo pero pueden convertirse en modelos simblicos cuantitativos muy exactos.
Un punto muy importante de los modelos es el de saber como probarlos, a fin de determinar su
valides; y estos tienen bsicamente dos formas de ser probados, una es la forma prospectiva (contra
el desempeo futuro), y la otra es de forma es retrospectiva (contra el desempeo pasado); en ste
ltimo caso, o sea si un modelo se prueba retrospectivamente, es de vital importancia que los
periodos utilizados cubran las situaciones que tal vez se encurte en el futuro.
Cuando un modelo no se puede probar en forma prospectiva ni en forma retrospectiva, el anlisis de
5. HERRAMIENTAS CASE
En la introduccin del Libro describimos que en los Proyectos Informticos, desarrollados

por profesionales de administracin en pequeas y medianas empresas, el profesional 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 requiere la
elaboracin de los modelos y , a la gran cantidad de documentacin que es necesaria.
Para solucionar estos problemas se puede considerar la utilizacin de herramientas CASE; estas
herramientas permitirn organizar y manejar la informacin de un proyecto 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 Engineering;
y en su traduccin al Espaol significa Ingeniera de Software Asistida por Computacin.
El concepto de CASE es muy amplio; y una buena definicin genrica, que pueda abarcar esa
amplitud de conceptos, sera la de considerar a la Ingeniera de Software Asistida por
Computacin (CASE), como la aplicacin de mtodos y tcnicas a travs de las cuales 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 procedimientos administrativos;
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 estructurado, utilizando 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 Relacin, para
realizar el Modelo de Datos
Figura 5.2 Modelo Relacional de Datos

Algunos de los componentes de las herramientas CASE permiten:
Confeccionar la definicin de requerimientos de los usuarios,
Mejorar el diseo de los 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 tales herramientas
deben abarcar las siguientes propiedades:
Tener una interfaz grfica y textual, que le permita al usuario manejar los objetos de
diseo (Ver Figura 3).
Figura 5.3 Herramientas de edicin
Contar con un Diccionario de Datos, a fin de rastrear y controlar los objetos 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 del 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 administrador de un
proyecto informtico, llevar adelante un proyecto informtico de forma eficaz y eficiente.
Tambin es un hecho que estas mismas herramientas, como toda Tecnologa de la Informacin
se encuentra en continua evolucin y existe adems una gran variedad de proveedores y
productos y cada uno de ellos con sus diferentes aplicaciones y especificaciones.
Por ello recomendamos, que al momento de adquirir alguna herramienta CASE, se aplique
rigurosamente una metodologa de compra, que permita evaluar tanto al software 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 ellas en s
mismas son una metodologa; su uso est restringido a la metodologa elegida para llevar
adelante el anlisis y diseo del proyecto.
6. DESARROLLO
El administrador de un proyecto informtico debe buscar la mxima
automatizacin de las 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 todo proyecto informtico se est dispuesto
a automatizar tareas requeridas por los usuarios; 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 posible de todas las tareas desarrolladas por los
profesionales involucrados en un proyecto informtico. Se debe evitar la
programacin manual; pues sta es lenta y propensa a errores, por lo
tanto es ineficaz e ineficiente.
Velocidad: Tal lo visto en el primer captulo (ver 1. Proyecto

informtico, tareas y recursos) otro de los problemas principales, en el
desarrollo de todo proyecto informtico, es el tiempo que involucra al
mismo. Persiga altos niveles de productividad, aplicando tcnicas y
metodologas que le permitan alcanzar resultados rpidamente.
Cambiabilidad. Cuando vimos las causas que dan inicio a un proyecto
informtico (ver 1.2. inicio de un proyecto informtico), describimos que

existirn cambios en 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 los sistemas. Es por eso que
se deben aplicar tcnicas y metodologas que permitan realizar dichos
cambios, sin que esto involucre un incremento significativo tanto 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. lista de eventos); para poder detectar
automticamente todos los errores de sintaxis 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 deben 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 Query
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 adoptar lenguajes que permitan que la gerencia extraiga nueva
informacin de las bases de 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 modelizacin de datos almacenados (ver 4.4. el modelo RDM)
cuide las tcnicas y los mtodos 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 local 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 separadamente operan correctamente en conjunto (ver
4.7. el rbol de un sistema).
Dialectos alternativos. Se debe disponer de herramientas de

ingeniera de software(ver. 5 herramientas CASE) para conceptualizar,
dibujar y disear sistemas, conectados en forma automtica con la
representacin bsica. Estas herramientas deben funcionar en forma
integrada, evitando puentes manuales que introducen errores. Deben
utilizar, en la media posible, sintaxis y grficos comunes.

Una propuesta interesante de destacar es la que propone Lucas H.C. Jr.. con el diseo creativo de
sistemas, este modelo tiene bsicamente tres componentes:
1. diseo controlado por el usuario

2. atencin especial a las interacciones con el usuario
3. 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 esfuerzo 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 preparado 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 salidas, las
entradas y la lgica del procesamiento. El usuario en escribe ni controla programas estos pueden ser
desarrollados con lenguajes de 4 generacin y ser controlados 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 acuerdo con el criterio del mismo
usuario.
6.1. 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; Cualquier centro de desarrollo puede
montar su metodologa, aunque esta alternativa implica disponer del tiempo necesario para el
desarrollo de la nueva metodologa; por 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 grandes grupos
Anlisis
definicin del problema

estudio de la situacin actual
requisitos a considerar
estudio 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.
6.2. METODOLOGA ESTRUCTURADA SIMPLIFICADA.

Todo proceso de desenvolvimiento de software usando metodologa Estructurada simplificada est
basado en la identificacin de los eventos a los que el sistema debe responder.
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 reas 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 con la tcnica del Modelo Relacional 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 automatizados; se
somete a la evaluacin del usuario cada proceso del modelo comportamental (ver 4.7. mdulos
del sistema).
Definir los requisitos de implementacin
Mientras son definidos los procesos a ser informatizados, se debe discutir y documentar los
requisitos de implementacin de esos procesos y del sistema de software como un todo: Desempeo,
restricciones de costos, restricciones operacionales, consideraciones sobre seguridad y auditora,
tecnologa a ser empleada, modificaciones 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 funciones 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 de funciones

puede ser hecho por proximidad temporal de utilizacin, rutinas On-Line, mensual, anual, etc., o por
cualquier otro tipo de afinidad, como por ejemplo, en el caso de sistemas distribuidos, el
agrupamiento es hecho conforme al procesador en que sern ejecutadas las funciones. La estructura
del software es completada, 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 para alteracin de parmetros de operaciones, etc. estos mdulos sern
incorporados al Diagrama 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 desarrollada a partir de
los flujos de datos de entrada y de salida de los procesos a ser automatizados. Una nica interfaz
puede ser generada para atender varios flujos simultneamente. Las interfaces necesarias a los
mdulos que implementan mens de seleccin y a los mdulos de apoyo operacional
complementaran el proyecto de la interfaz con el usuario.
Proyectar la base de datos fsica
Definir las caractersticas fsicas de cada dato, como el tipo el dominio; la organizacin de cada
archivo, como la definicin de las llaves principales, ndices, etc. (ver 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).
Ejercicios de Diagrama de Flujo de Datos

Cada ejercicio cuenta con una Lista de Eventos, y un Diagrama de
Flujo de Datos.
En la Lista de Eventos se detallan algunos de los elementos principales
de las tablas involucradas en el proceso; y con la letra @ se identifica a
los posibles campos indexadores.
Tambin en la Lista de eventos se detalla, entre parntesis, a las copias
de los formularios con soporte papel; esta identificacin es importante si
realiza otro tipo de diseo de proceso, tal el caso del Cursograma.
Procedimiento de Compras
COMPRAS NORMALES
Lista de Eventos
ETAPAS BSICAS
SOLICITUD DE COMPRA
SELECCIN DEL PROVEEDOR
DECISIN DE COMPRA
RECEPCIN DE LA COMPRA
ALMACENAJE DE LA MERCADERA
REGISTRACIN
1 SOLICITUD DE COMPRA
1.1. ALMACENES controla el SOTCK y detecta necesidad.
@ Punto
Ingreso pendiente (Nota de pedido solicitada y no entregada)
Entregas parciales.
de pedido
1.2. ALMACENES emite SOLICITUD DE COMPRA (original y duplicado).
Producto
Cantidad
Calidad requerida.
1.3. ALMACENES enva SOLICITUD DE COMPRA (original) a COMPRAS.
1.4.
ALMACENES
COMPRA (duplicado),
archiva
(transitoriamente) SOLICITUD
DE
Orden @ Cronolgico (a la espera de la llegada del material 5.1.).

1.5. ALMACENES registra en STOCK.
Ingreso pendiente
1.6. ALMACENES controla
COMPRAS (duplicado)
archivo
(transitorio) SOLICITUDES
@ Fecha de entrega (para controlar los retrasos).

1.6.1. Si existe retraso en la entrega ALMACENES avisa a COMPRAS.
2. SELECCIN DEL PROVEEDOR

2.1. COMPRAS consulta ORIGEN DEL PRODUCTO.
@ Cdigo del producto
DE
@ Cdigo del proveedor

2.2. COMPRAS consulta PROVEEDORES.
2.3. COMPRAS emite PEDIDO DE COTIZACIN (duplicado).
2.4.
COMPRAS
archiva
(transitoriamente) SOLICITUD
COMPRA y PEDIDO DE COTIZACIN (duplicado) adjuntadas
DE
Orden @ Cronolgico (de PEDIDO DE COTIZACIN).

2.5. COMPRAS enva PEDIDO DE COTIZACIN (original) al PROVEEDOR.
3. DECISIN DE COMPRA
3.1. COMPRAS recibe las COTIZACIONES de los PROVEEDORES.
3.2.
COMPRAS
controla
las COTIZACIONES con MANUAL
ANTECEDENETES DE COMPRAS
Reputacin global del proveedor
Trminos financieros
Flexibilidad del proveedor para ajustarse a las necesidades de su empresa
Experiencia con el proveedor en situaciones anlogas
Servicio tcnico ofrecido
Confiabilidad en el vendedor
Conveniencia en colocar la orden
Datos sobre la confiabilidad del producto
Precio
Especificaciones tcnicas
Facilidad de operacin o de uso
Preferencias del usuario principal del producto
Entrenamiento ofrecido por el proveedor
DE
Tiempo de entrenamiento requerido
Confiabilidad en los datos de envo prometidos
Facilidad en el mantenimiento.
Servicio de ventas esperado despus de la fecha de compra.

3.3. COMPRAS emite ORDEN DE COMPRA (por triplicado).
3.4. COMPRAS enva ORDEN DE COMPRA (original) al PROVEEDOR.
3.5. COMPRAS adjunta y constituye LEGAJO DE TRAMITACIN DE
COMPRA:
ORDEN DE COMPRA (duplicado),
SOLICITUD DE COMPRA (original),
PEDIDO DE COTIZACIN (duplicado)y
COTIZACIN (original);
3.6. COMPRAS archiva (provisoriamente) LEGAJO DE TRAMITACIN DE
COMPRA.
Se archiva definitivamente cuando se @ cumple la entrega con copia
del REMITO o PARTE DE RECEPCIN (ver 4.12).
3.7. COMPRAS enva ORDEN DE COMPRA (triplicado) a RECEPCIN, Sin
precio.
4. RECEPCIN DE LA MERCADERA
4.1. RECEPCIN controla (la mercadera recibida) REMITO (duplicado)
con ORDEN DE COMPRA (triplicado)
4.2. RECEPCIN firma REMITO (original).
4.3. RECEPCIN devuelve REMITO (original) al PROVEEDOR.
4.4. RECEPCIN emite PARTE DE RECEPCIN (por triplicado)
Nmero de parte de recepcin
Nmero de orden de compra
@ Nombre del proveedor
Direccin del proveedor
Fecha de recepcin
@ Mercadera recibida
Unidad de medida
Cantidad
Nombre del producto
Cdigo del producto
Precio
Conformidad de recepcin.
4.5. RECEPCIN enva PARTE DE RECEPCIN
a COMPRAS (original).
a ALMACENES (duplicado y triplicado).

4.6. ALMACENES controla (con mercadera).
4.7. ALMACENES conforma PARTE DE RECEPCIN (triplicado).
4.8. ALMACENES enva PARTE DE RECEPCIN (triplicado) a RECEPCIN.
4.9. RECEPCIN adjunta PARTE DE RECEPCIN (triplicado) a ORDEN DE
COMPRA y archiva (definitivamente).
4.10. RECEPCIN Conforma REMITO (duplicado).
4.11. RECEPCIN enva REMITO (duplicado) a CUENTAS A PAGAR.
4.12. COMPRAS verifica PARTE DE RECEPCIN (original) con LEGAJO DE
TRAMITACIN DE COMPRA (en archivo provisorio).
4.13. COMPRAS Conforma LEGAJO DE TRAMITACIN DE COMPRA.
4.14. COMPRAS archiva (definitivamente) LEGAJO DE TRAMITACIN DE
COMPRA.
4.15. COMPRAS destruye PARTE DE RECEPCIN (original).
5. ALMACENAJE DE LA MERCADERA
5.1. ALMACENES verifica PARTE DE RECEPCIN con SOLICITUD DE
COMPRA
5.1.1. Si no hay coincidencia comunica a COMPRAS.
5.2. ALMACENES retira del archivo (transitorio)SOLICITUD DE COMPRA.
5.3. ALMACENES destruye SOLICITUD DE COMPRA
5.4. ALMACENES actualiza archivo de STOCK en base al PARTE DE
RECEPCIN.
5.4.1. Anula anotacin En trmite de reposicin
5.4.2. Da Ingreso
5.5. ALMACENES archiva (definitivamente) PARTE DE RECEPCIN.
Diagrama de Flujo de Datos

Nivel 1 - Compras Normales
Nivel 2 - 1 SOLICITUD DE COMPRA
Nivel 2 - SELECCIN DEL PROVEEDOR
Nivel
2
- DECISIN DE
COMPRA
Nivel 2 - RECEPCIN DE LA MERCADERA
Nivel
2
- ALMACENAJ
E
DE
MERCADERA
LA
Procedimiento de Ventas
VENTAS EN CUENTA CORRIENTE

ETAPAS BSICAS
1. FORMULAR EL PEDIDO
2. APROBACIN DEL PEDIDO
3. DESPACHAR LA MERCADERA
4. FACTURAR
5. REGISTRAR
1.FORMULAR EL PEDIDO
1.1. El CLIENTE realiza una SOLICITUD DE MERCADERA.
1.2. El VENDEDOR confecciona NOTA DE PEDIDO (4 ejemplares)
Datos del CLIENTE
Nombre del Cliente
Nmero de Cuenta Corriente
Domicilio de entrega
Datos del PRODUCTO
Descripcin del producto
Cdigo del Producto
Cantidad solicitada
Datos del VENDEDOR
Nombre del Vendedor
Cdigo del Vendedor ( Cdigo de empleado).

1.3. El VENDEDOR valoriza la NOTA DE PEDIDO (Forma de pago; la puede
realizar CUENTA CORRIENTE)
LISTA DE PRECIO
BONIFICACIONES
CARGOS(Por embalajes, transportes u otros)
Plazo de entrega.
1.4. El VENDEDOR enva NOTA DE PEDIDO
A VENTAS(original y triplicado)
Al CLIENTE(duplicado)
Al ARCHIVO, para control del VENDEDOR (cuadruplicado).

1.5. VENTAS controla la valorizacin (del paso 1.3.).
1.6. VENTAS inicia la NOTA DE PEDIDO (original y triplicado).
1.7. VENTAS enva NOTA DE PEDIDO
A CUENTA CORRIENTE (original)
Al ARCHIVO (triplicado).
1.8. VENTAS confecciona estadsticas en base a archivado NOTA DE
PEDIDO (triplicado).
2.1. CUENTA CORRIENTE controla @ Lmite de crdito.

2.1.1. La suma del: Valor total + Saldo de deuda del CLIENTE + Notas de
pedido aprobadas no debitadas; deben ser menor al Lmite de crdito
acordado.
Si se cumple la ecuacin anterior
2.2. CUENTA CORRIENTE aprueba NOTA DE PEDIDO
2.2.1. CUENTA CORRIENTE registra la aprobacin en el Total de notas de
pedido aprobadas y no debitadas de cada CLIENTE.
2.2.2. Se inscribe en la NOTA DE PEDIDO la Aprobacin.
2.2.3. CUENTA CORRIENTE enva NOTA DE PEDIDO a ALMACENES.
Si no se cumple la ecuacin anterior
2.3. CUENTA CORRIENTE no aprueba la NOTA DE PEDIDO
2.3.1. CUENTA CORRIENTE inscribe en la NOTA DE PEDIDO
Importe de la Deuda actual
Importe de las Notas de pedido aprobadas y no contabilizadas.

2.3.2. CUENTA
a CRDITOS.
CORRIENTE
enva NOTA
DE
PEDIDO no
aprobada
2.3.3. CRDITOS consulta Lmite de crdito del CLIENTE.

2.3.4. CRDITOS decide si aprueba
2.3.4.1. CRDITOS no aprueba la venta
2.3.4.1.1. CRDITOS enva NOTA DE PEDIDO a VENTAS
2.3.4.1.2. VENTAS registra el Rechazo
2.3.4.1.3. VENTAS comunica al CLIENTE
2.3.4.2. CRDITOS aprueba la venta
2.3.4.2.1. CRDITOS Inicia la sobre la NOTA DE PEDIDO
2.3.4.2.2. CRDITOS enva NOTA DE PEDIDO a CUENTA CORRIENTE
2.3.4.2.3. CUENTA CORRIENTE registra el pedido aprobado en Total de
notas de pedido aprobadas y no debitadas de cada CLIENTE ( paso 2.2.1.).
2.4.
ALMACENES
con EXISTENCIAS.
controla NOTA
DE
PEDIDO (original)
? Si hay EXISTENCIAS para cumplir el pedido

2.4.1. ALMACENES emite REMITO ( 5 ejemplares)
2.4.2. ALMACENES enva REMITO (5 ejemplares) a DESPACHO
2.4.3. ALMACENES archiva (definitivamente) NOTA DE PEDIDO.
2.4.4. ALMACENES descarga de EXISTENCIAS.
Si no hay EXISTENCIAS para cumplir el pedido.
2.4.5. ALMACENES
circunstancia
anota
en
2.4.6. ALMACENES
CORRIENTE
enva NOTA
la NOTA
DE
DE
PEDIDO (original)
PEDIDO (original)
tal
CUENTA
2.4.7. CUENTA CORRIENTE con la NOTA DE PEDIDO (original) descarga

del archivo del CLIENTE, la inscripcin Nota de pedido aprobada y no
contabilizada.
2.4.8. CUENTA CORRIENTE enva NOTA DE PEDIDO (original) a VENTAS
2.4.9. VENTAS toma conocimiento
2.4.10. VENTAS avisa al CLIENTE.
3. DESPACHO DE LA MERCADERA.
3.1. DESPACHO controla REMITO.
3.2. DESPACHO conforma REMITO (cuadruplicado).
3.3. DESPACHO enva REMITO (cuadruplicado) a ALMACENES.
3.4. DESPACHO organiza la entrega
3.4.1. DESPACHO emite HOJA DE RUTA (Original y 2 copias)
Datos del Cliente
Nmero de REMITO
Cantidad de bultos por REMITO
Nombre del repartidor (Ordenada por REPARTIDOR).

3.5. DESPACHO entrega al REPARTIDOR
HOJA DE RUTA (original y duplicado)
REMITO (original y duplicado).

3.6. REPARTIDOR controla
3.6.1. Nmeros de REMITO en HOJA DE RUTA
3.6.2. Bultos o paquetes con REMITO.
3.7. REPARTIDOR firma HOJA DE RUTA (triplicado)
3.8. DESPACHO archiva (transitoriamente)
HOJA DE RUTA (triplicado)
REMITO (quintuplicado y triplicado).

3.9. REPARTIDOR entrega mercadera al CLIENTE.
3.10. CLIENTE firma REMITO (original).
3.11. REPARTIDOR entrega REMITO (duplicado) al CLIENTE.
3.12. REPARTIDOR anota observaciones en HOJA DE RUTA (si las hay).
3.13. REPARTIDOR entrega en DESPACHO
REMITO (original)

3.14. DESPACHO controla entrega
3.14.1. Si fue todo entregado (todos los REMITOS firmados por los
CLIENTES)
3.14.1.1. DESPACHO devuelve HOJA DE RUTA (duplicado) al REPARTIDOR
3.14.1.2. REPARTIDOR archiva HOJA DE RUTA (duplicado)
3.14.2. Si una entrega no fue realizada

3.14.2.1. Se excluye de la HOJA DE RUTA
3.14.2.2. DESPACHO archiva transitoriamente el REMITO
3.14.2.3. DESPACHO lo incluye en la HOJA DE RUTA del da siguiente.
3.15. DESPACHO enva REMITOS de entregas efectuadas y HOJAS DE
RUTA (original) a CONTABILIDAD ALMACENES
3.16.
CONTABILIDAD
ALMACENES
RUTA con REMITOS entregados.
controla HOJA
DE
3.17. CONTABILIDAD ALMACENES enva HOJA DE RUTA (original) a

DESPACHO.
3.18. DESPACHO archiva (definitivamente) HOJA DE RUTA (original).
3.19. DESPACHO enva REMITO (triplicado ) a FACTURACIN.
3.20. DESPACHO enva REMITO (quintuplicado) a VENTAS.
3.21.
VENTAS
adjunta REMITO (quintuplicado)
PEDIDO (archivada).
a NOTA
DE
4. FACTURACIN
4.1. FACTURACIN valoriza REMITO (consulta LISTA DE PRECIO).
4.2.
FACTURACIN
controla
si
existe
alguna BONIFICACIN
ESPECIAL (comunicada por documento) a ser incluida.
4.3. FACTURACIN emite FACTURA (triplicado).
4.4. FACTURACIN controla REMITO y FACTURA
Suma nmero de artculo
Suma cantidad.
4.5. FACTURACIN, finalizada la emisin, calcula el Total de importes
facturados.
4.6. FACTURACIN comunica Total de importe facturado a CONTADURA.
4.7. VENTAS emite un TOTAL DE
los REMITOS (quintuplicado) recibidos.
NOTAS
DE
PEDIDO;
de
4.8. VENTAS comunica TOTAL NOTAS DE PEDIDO a CONTADURA.

4.9. CONTADURA controla Total de importe facturado y TOTAL NOTAS DE
PEDIDO.
4.10. CONTADURA
PEDIDO.
archiva
Total
facturacin
y TOTAL
NOTAS
DE
4.11. CONTADURA comunica resultado de la verificacin a FACTURACIN.

4.12.
FACTURACIN
recibido
enva FACTURA (original) al CLIENTE.
resultado
de
verificacin
4.13. FACTURACIN enva FACTURA (duplicado) a CUENTA CORRIENTE.

4.14. FACTURACIN enva FACTURA (triplicado) a COBRANZAS.
4.15. COBRANZAS archiva (transitoriamente) FACTURA (triplicado). Para
posterior cobro.
4.16. FACTURACIN archiva REMITO.
5. REGISTRACIN
5.1. CONTABILIDAD ALMACENES valoriza (al costo) el REMITO (original).
5.2. CONTABILIDAD ALMACENES acredita en las sub cuentas afectadas.
5.3. CONTABILIDAD ALMACENES totaliza valores acreditas.
5.4. CONTABILIDAD ALMACENES verifica Total nmero de artculo y Total
cantidad del REMITO con Total registrado.
5.5.
CONTABILIDAD
ALMACENES notifica
DETALLE
REGISTRACIONES (MINUTA CONTABLE) a CONTADURA.
DE
5.6. CONTABILIDAD ALMACENES archiva REMITO.

5.7. CUENTA CORRIENTE, con la FACTURACIN (duplicado), debita en la
subcuenta del CLIENTE.
5.8. CUENTA CORRIENTE, descarga de la subcuenta CLIENTE, importe de
pedidos aprobados y no contabilizados.
5.9. CUENTA CORRIENTE, totaliza registros.
5.10. CUENTA CORRIENTE, informa detalles de los registros (MINUTA
CONTABLE) a CONTADURA.
5.11. CUENTA CORRIENTE archiva FACTURA (duplicado).

5.12.
CONTADURA
con
las MINUTAS
CONTABLES recibidas
de
CONTABILIDAD ALMACENES controla la MINUTA CONTABLE de CUENTA
CORRIENTE con el Importe facturado.
5.13. CONTADURA en base
en CONTABILIDAD GENERAL.
las MINUTAS
CONTABLES registra
5.14. CONTADURA archiva las MINUTAS CONTABLES.

Nivel 1 VENTAS
EN CUENTA CORRIENTE
Nivel 2 - 1 FORMULAR EL PEDIDO
Nivel
2
-2
.
APROB
DEL
ACIN
PEDIDO
Nivel 2 - 3. DESPACHAR LA MERCADERA
Nivel 2 -
4. FACTURAR
Nivel 2 - 5. REGISTRAR
Procedimiento de Ventas
VENTAS EN CUENTA
CORRIENTE
ETAPAS
BSICAS
1. FORMU
LAR EL PEDIDO
2. APROB
ACIN DEL PEDIDO
3. DESPACHA
R LA MERCADERA
4. FACTURAR
5. REGISTRAR
1.FORMULAR EL PEDIDO
1.1. El CLIENTE realiza una SOLICITUD DE MERCADERA.
1.2.
El
VENDEDOR
PEDIDO (4 ejemplares)
Datos
del CLIENTE
Nombre del
Cliente
Nmero de Cuenta Corriente
confecciona NOTA
DE
Datos del PRODUCTO
Descripcin del producto
Cdigo del Producto
Cantidad solicitada
Datos del VENDEDOR
Nombre del Vendedor
Cdigo del Vendedor ( Cdigo de empleado).

1.3. El VENDEDOR valoriza la NOTA DE PEDIDO (Forma de pago; la puede
realizar CUENTA CORRIENTE)
LISTA DE PRECIO
BONIFICACIONES
CARGOS(Por embalajes, transportes u otros)
Plazo de entrega.
1.4. El VENDEDOR enva NOTA DE PEDIDO
A VENTAS(original y triplicado)
Al CLIENTE(duplicado)
Al ARCHIVO, para control del VENDEDOR (cuadruplicado).

1.5. VENTAS controla la valorizacin (del paso 1.3.).
1.6. VENTAS iniciala NOTA DE PEDIDO (original y triplicado).
1.7. VENTAS enva NOTA DE PEDIDO
A CUENTA CORRIENTE (original)
Al ARCHIVO (triplicado).
1.8. VENTAS confecciona estadsticas en base a archivado NOTA DE
PEDIDO (triplicado).

2.1. CUENTA CORRIENTE controla @ Lmite de crdito.
2.1.1. La suma del: Valor total + Saldo de deuda del CLIENTE + Notas de
pedido aprobadas no debitadas; deben ser menor al Lmite de crdito
acordado.
Si se cumple la ecuacin anterior
2.2. CUENTA CORRIENTE aprueba NOTA DE PEDIDO
2.2.1. CUENTA CORRIENTE registra la aprobacin en el Total de notas de
pedido aprobadas y no debitadas de cada CLIENTE.
2.2.2. Se inscribe en la NOTA DE PEDIDO la Aprobacin.
2.2.3. CUENTA CORRIENTE enva NOTA DE PEDIDO a ALMACENES.
Si no se cumple la ecuacin anterior
2.3. CUENTA CORRIENTE no aprueba la NOTA DE PEDIDO
2.3.1. CUENTA CORRIENTE inscribe en la NOTA DE PEDIDO
Importe de la Deuda actual
Importe de las Notas de pedido aprobadas y no contabilizadas.

2.3.2. CUENTA
a CRDITOS.
CORRIENTE
enva NOTA
DE
PEDIDO no
aprobada
2.3.3. CRDITOS consulta Lmite de crdito del CLIENTE.

2.3.4. CRDITOS decide si aprueba
2.3.4.1. CRDITOS no aprueba la venta
2.3.4.1.1. CRDITOS enva NOTA DE PEDIDO a VENTAS
2.3.4.1.2. VENTAS registra el Rechazo
2.3.4.1.3. VENTAS comunica al CLIENTE
2.3.4.2. CRDITOS aprueba la venta
2.3.4.2.1. CRDITOS Iniciala sobre la NOTA DE PEDIDO
2.3.4.2.2. CRDITOS enva NOTA DE PEDIDO a CUENTA CORRIENTE
2.3.4.2.3. CUENTA CORRIENTE registra el pedido aprobado en Total de

notas de pedido aprobadas y no debitadas de cada CLIENTE ( paso 2.2.1.).
2.4.
ALMACENES
con EXISTENCIAS.
controla NOTA
DE
PEDIDO (original)
? Si hay EXISTENCIAS para cumplir el pedido

2.4.1. ALMACENES emite REMITO ( 5 ejemplares)
2.4.2. ALMACENES enva REMITO (5 ejemplares) a DESPACHO
2.4.3. ALMACENES archiva (definitivamente) NOTA DE PEDIDO.
2.4.4. ALMACENES descarga de EXISTENCIAS.
Si no hay EXISTENCIAS para cumplir el pedido.
2.4.5. ALMACENES
circunstancia
anota
en
2.4.6. ALMACENES
CORRIENTE
enva NOTA
la NOTA
DE
DE
PEDIDO (original)
PEDIDO (original)
tal
CUENTA
2.4.7. CUENTA CORRIENTE con la NOTA DE PEDIDO (original) descarga

del archivo del CLIENTE, la inscripcin Nota de pedido aprobada y no
contabilizada.
2.4.8. CUENTA CORRIENTE enva NOTA DE PEDIDO (original) a VENTAS
2.4.9. VENTAS toma conocimiento
2.4.10. VENTAS avisa al CLIENTE.
3. DESPACHO DE LA MERCADERA.
3.1. DESPACHO controla REMITO.
3.2. DESPACHO conforma REMITO (cuadruplicado).
3.3. DESPACHO enva REMITO (cuadruplicado) a ALMACENES.
3.4. DESPACHO organiza la entrega
3.4.1. DESPACHO emite HOJA DE RUTA (Original y 2 copias)
Datos del Cliente
Nmero de REMITO
Cantidad de bultos por REMITO
Nombre del repartidor (Ordenada por REPARTIDOR).

3.5. DESPACHO entrega al REPARTIDOR
REMITO (original y duplicado).

3.6. REPARTIDOR controla
3.6.1. Nmeros de REMITO en HOJA DE RUTA
3.6.2. Bultos o paquetes con REMITO.
3.7. REPARTIDOR firma HOJA DE RUTA (triplicado)
3.8. DESPACHO archiva (transitoriamente)
HOJA DE RUTA (triplicado)
REMITO (quintuplicado y triplicado).

3.9. REPARTIDOR entrega mercadera al CLIENTE.
3.10. CLIENTE firma REMITO (original).
3.11. REPARTIDOR entrega REMITO (duplicado) al CLIENTE.
3.12. REPARTIDOR anota observaciones en HOJA DE RUTA (si las hay).
3.13. REPARTIDOR entrega en DESPACHO
REMITO (original)

3.14. DESPACHO controla entrega
3.14.1. Si fue todo entregado (todos los REMITOS firmados por los
CLIENTES)
3.14.1.1. DESPACHO devuelve HOJA DE RUTA (duplicado) al REPARTIDOR
3.14.1.2. REPARTIDOR archiva HOJA DE RUTA (duplicado)

3.14.2. Si una entrega no fue realizada
3.14.2.1. Se excluye de la HOJA DE RUTA
3.14.2.2. DESPACHO archiva transitoriamente el REMITO
3.14.2.3. DESPACHO lo incluye en la HOJA DE RUTA del da siguiente.
3.15. DESPACHO enva REMITOS de entregas efectuadas y HOJAS DE
RUTA (original) a CONTABILIDAD ALMACENES
3.16.
CONTABILIDAD
ALMACENES
RUTA con REMITOS entregados.
controla HOJA
DE
3.17. CONTABILIDAD ALMACENES enva HOJA DE RUTA (original) a

DESPACHO.
3.18. DESPACHO archiva (definitivamente) HOJA DE RUTA (original).
3.19. DESPACHO enva REMITO (triplicado ) a FACTURACIN.
3.20. DESPACHO enva REMITO (quintuplicado) a VENTAS.
3.21.
VENTAS
adjunta REMITO (quintuplicado)
PEDIDO (archivada).
a NOTA
DE
4. FACTURACIN
4.1. FACTURACIN valoriza REMITO (consulta LISTA DE PRECIO).
4.2.
FACTURACIN
controla
si
existe
alguna BONIFICACIN
ESPECIAL (comunicada por documento) a ser incluida.
4.3. FACTURACIN emite FACTURA (triplicado).
4.4. FACTURACIN controla REMITO y FACTURA
Suma nmero de artculo
Suma cantidad.
4.5. FACTURACIN, finalizada la emisin, calcula el Total de importes
facturados.
4.6. FACTURACIN comunica Total de importe facturado a CONTADURA.
4.7. VENTAS emite un TOTAL DE

los REMITOS (quintuplicado) recibidos.
NOTAS
DE
PEDIDO;
de
4.8. VENTAS comunica TOTAL NOTAS DE PEDIDO a CONTADURA.

4.9. CONTADURA controla Total de importe facturado y TOTAL NOTAS DE
PEDIDO.
4.10. CONTADURA
PEDIDO.
archiva
Total
facturacin
y TOTAL
NOTAS
DE
4.11. CONTADURA comunica resultado de la verificacin a FACTURACIN.

4.12.
FACTURACIN
recibido
enva FACTURA (original) al CLIENTE.
resultado
de
verificacin
4.13. FACTURACIN enva FACTURA (duplicado) a CUENTA CORRIENTE.

4.14. FACTURACIN enva FACTURA (triplicado) a COBRANZAS.
4.15. COBRANZAS archiva (transitoriamente) FACTURA (triplicado). Para
posterior cobro.
4.16. FACTURACIN archiva REMITO.
5. REGISTRACIN
5.1. CONTABILIDAD ALMACENES valoriza (al costo) el REMITO (original).
5.2. CONTABILIDAD ALMACENES acredita en las sub cuentas afectadas.
5.3. CONTABILIDAD ALMACENES totaliza valores acreditas.
5.4. CONTABILIDAD ALMACENES verifica Total nmero de artculo y Total
cantidad del REMITO con Total registrado.
5.5.
CONTABILIDAD
ALMACENES notifica
DETALLE
REGISTRACIONES (MINUTA CONTABLE) a CONTADURA.
DE
5.6. CONTABILIDAD ALMACENES archiva REMITO.

5.7. CUENTA CORRIENTE, con la FACTURACIN (duplicado), debita en la
subcuenta del CLIENTE.
5.8. CUENTA CORRIENTE, descarga de la subcuenta CLIENTE, importe de
pedidos aprobados y no contabilizados.
5.9. CUENTA CORRIENTE, totaliza registros.
5.10. CUENTA CORRIENTE, informa detalles de los registros (MINUTA

CONTABLE) a CONTADURA.
5.11. CUENTA CORRIENTE archiva FACTURA (duplicado).
5.12.
CONTADURA
con
las MINUTAS
CONTABLES recibidas
de
CONTABILIDAD ALMACENES controla la MINUTA CONTABLE de CUENTA
CORRIENTE con el Importe facturado.
5.13. CONTADURA en base
en CONTABILIDAD GENERAL.
las MINUTAS
CONTABLES registra
5.14. CONTADURA archiva las MINUTAS CONTABLES.

Nivel 1 VENTAS
EN CUENTA CORRIENTE
Nivel 2 - 1 FORMULAR EL PEDIDO
Nivel 2
- 2. APR
OBACIN DEL PEDIDO
Nivel 2
- 3. DESPACHA
R
LA MERCADERA
Nivel 2 -
4. FACTURAR
Nivel 2 - 5. REGISTRAR
Procedimiento
de Pagos
PAGO
ETAPAS BSICAS
A PROVEEDORES
CONTROL
DE
LA FACTURA DEL PROVEEDOR

AUTORIZACION DE PAGO
PAGO
CONTABILIZACIN
CONTROL
DEL
RECIBO
1.
CONTROL
DE
LA
FACTURA DEL PROVEEDOR
1.1. El PROVEEDOR enva la FACTURA a CUENTAS A PAGAR.

1.2. CUENTAS A PAGAR CONTROLA
1.2.1. Que fue un pedido realizado por la empresa; lo verifica con
la ORDEN DE COMPRA que tiene en archivo transitorio.
1.2.2. Los importes los controla con la ORDEN DE COMPRA o con
la COTIZACIN DEL PROVEEDOR.
1.2.3. Bonificaciones
COMPRA.
Descuentos
estipulados;
con
la ORDEN
1.2.4. Que la mercadera fue recibida (En conformidad

observaciones ); lo verifica con REMITO firmado por RECEPCIN.
DE
con
1.2.5. Totales de la FACTURA con el clculo aritmtico.
2. AUTORIZACIN DE PAGO
2.1. CUENTAS A PAGAR enva;
2.1.1. REMITO (duplicado), FACTURA (original), ORDEN
PAGO original); a la Segunda Firma.
DE
2.1.2. ORDEN DE PAGO (duplicado y triplicado) a TESORERA.

2.1.3. ORDEN DE PAGO (cuadruplicado) al archivo transitorio.
2.2.
CUENTAS
A
PAGAR
controla
con ORDEN
DE
PAGAO (cuadruplicado) ORDENES DE PAGO emitidas y no satisfechas.
3. PAGO
3.1. TESORERA en base a la ORDEN DE PAGO, emite el CHEQUE.
3.2. TESORERA, anota en ORDEN DE PAGO (triplicado).
Banco Girado.
3.3. TESORERA firma el CHEQUE.
3.4. TESORERA enva
3.4.1. CHEQUE y ORDEN DE PAGO (duplicado) a la SEGUNDA FIRMA.
3.4.2. ORDEN DE PAGO (triplicado) al archivo transitorio.

3.5. SEGUNDA FIRMA verifica los componentes bsicos de pago; REMITO,
FACTURA, ORDEN DE PAGO, LEGAJO DE COMPRA.
3.6. SEGUNDA FIRMA anula COMPONENTES BSICOS DE PAGO con:
Pagado
Fecha
Nmero de cheque
Iniciala.
3.7. SEGUNDA FIRMA; firma EL CHEQUE.
3.8. SEGUNDA FIRMA enva
ODEN DE PAGO (duplicado) a TESORERA
FACTURA; REMITO a CONTADURA
CHEQUE; ORDEN DE PAGO (original) a SECRETARA DE GERENCIA.

3.9. TESORERA archiva (definitivamente) ORDEN DE PAGO (duplicado).
3.10. TESORERA
PAGO ( triplicado).
enva
CUENTAS
PAGAR
la ORDEN
DE
3.11. CUENTAS A PAGAR destruye ORDEN DE PAGO (cuadruplicado) y

demora (pendiente) el LEGAJO.
3.12. SECRETARA DE SEGUNDA FIRMA enva CHEQUE al PROVEEDOR.
3.13. SECRETARA DE SEGUNDA
PAGO (original), CHEQUE Enviado.
FIRMA
anota
en ORDEN
DE
3.14. SECRETARA DE SEGUNDA FIRMA enva ORDEN DE PAGO (original)

a CUENTAS A PAGAR.
4. CONTABILIZACIN
4.1. CUENTAS A PAGAR en base a ORDEN DE PAGO (original), debita el
Importe de la CUENTA DEL PROVEEDOR.
4.2. CUENTAS A PAGAR al final del da, controla las registraciones.

4.3. CUENTAS A PAGAR, confecciona MINUTA CONTABLE por los dbitos.
4.4. CUENTAS A PAGAR enva MINUTA CONTABLE a CONTADURA.
4.5. CUENTAS A PAGAR archiva ORDEN DE PAGO(original).
5. CONTROL DEL RECIBO

5.1. CUENTAS A PAGAR obtiene RECIBO DEL PROVEEDOR.
5.2. CUENTAS A PAGAR controla pago.
5.3. CUENTAS A PAGAR archiva RECIBO.
Nivel 1 - PAGO
A PROVEEDORES
Nivel 2 - 1 CONTROL DE LA
FACTURA DEL PROVEEDOR
Nivel 2 - 2 AUTORIZACION DE PAGO
Nivel
2-3
PAGO
Nivel 2 - 4 CONTABILIZACIN
Nivel 2 - 5
CONTROL DEL RECIBO
Procedimiento de Cobranzas
COBRANZAS POR COBRADORES

ETAPAS
1.
DETERMINAR
2.
PREPARAR
BSICAS
3.
EL COBRO
REALIZAR EL COBRO
4.
5.
EL COBRO
RENDICIN DE LA COBRANZA
REGISTRACIN DE
LA COBRANZA
1. DETERMINAR EL COBRO
1.1. COBRANZAS recibe DOCUMENTOS A COBRAR.

1.2. COBRANZAS registra en REGISTRO DE VENCIMIENTOS.
@ Fecha de vencimiento
Nmero de documento
1.1.
COBRANZAS
archiva DOCUM
ENTOS
A
COBRAR.
1.2. COBRANZAS recibe

COBRO (duplicado).
(de
FACTURACIN)
FACTURAS PENDIENTES DE
1.3. COBRANZAS archiva (transitoriamente) FACTURAS PENDIENTES DE

COBRO.
1.4. COBRANZAS consulta, si est en condicin de ser cobrada
REGISTRO DE VENCIMIENTOS
FACTURAS PENDIENTES DE COBRO
2. PREPARAR EL COBRO
2.1. COBRANZAS seleccionas, si est en condiciones de ser cobrada.
DOCUMENTOS A COBRAR

2.2. COBRANZAS clasifica por zona de cobro.
DOCUMENTOS A COBRAR

2.3. COBRANZAS confecciona LISTADO DE COBRANZAS (original y una
copia) [Detalle de valores entregados al cobro]
Nmero de documento
Tipo de documento
Nombre del deudor
@ Domicilio de cobro del deudor
Tipo de crdito
Importe
@ Nombre del cobrador
Fecha
2.4. COBRANZAS entrega LISTADO DE COBRANZAS (original y duplicado)

al COBRADOR.
2.5. COBRANZAS entrega valores al COBRADOR.
DOCUMENTOS A COBRAR

2.6. COBRADOR controla valores con LISTADO DE COBRANZAS
2.7. COBRADOR FRIMA LISTADO DE COBRANZAS (duplicado).
2.8. COBRADOR
COBRANZAS.
entrega LISTADO
2.9.
COBRANZAS
archiva
COBRANZAS (duplicado).
DE
COBRANZAS (duplicado)
(transitoriamente) LISTADO
en
DE
3. REALIZAR EL COBRO
3.1. COBRADOR recibe importe del DEUDOR [CLIENTE].
3.2.Si el pago es efectuado totalmente.
3.2.1. COBRADOR emite RECIBO DE COBRO (Original y tres copias).
3.2.2. COBRADOR entrega al DEUDOR.
DOCUMENTOS A COBRAR Y/O FACTURAS PENDIENTES DE COBRO
RECIBO DE COBRO (Original).

3.2.3. COBRADOR entrega
RECIBO DE COBRO (duplicado) a CAJA.
RECIBO DE COBRO (triplicado y cuadruplicado) a COBRANZAS

3.3. Si el pago es con un pagar.
3.3.1. COBRADOR confecciona RECIBO DE COBRO (Original y dos copias).
DOCUMENTOS A COBRAR Y/O FACTURAS PENDIENTES DE COBRO
RECIBO DE COBRO (Original).

3.3.3. COBRADOR entrega a COBRANZAS
RECIBO DE COBRO (duplicado y triplicado)[con uno documenta la Cta. Cte. con el otro la Deuda
documentada]
3.4. Si el pago es parcial.
3.4.1. COBRADOR confecciona RECIBO DE COBRO PROVISORIO (original
y tres copias)
RECIBO DE COBRO PROVISORIO (original)
DOCUMENTOS A COBRAR
3.4.3. COBRADOR entrega
RECIBO DE COBRO PROVISORIO (duplicado) a CAJA.
RECIBO DE COBRO PROVISORIO (triplicado y cuadruplicado) a COBRANZAS.

3.4.4. COBRADOR registra en LISTADO DE COBRANZAS.
Nro. de recibo
La cobranza
4. RENDICIN DE LA COBRANZA.
4.1. COBRADOR indica los valores percibidos a CAJA
Dinero
Cheque.
4.2. COBRADOR entrega a CAJA
LISTADO DE COBRANZAS.
RECIBO DE COBRO(duplicado)
RECIBO DE COBRO PROVISORIO (duplicado)

4.3. CAJERO controla
LISTADO DE COBRANZAS
RECIBO DE COBRO (duplicado)
RECIBO DE COBRO PROVISORIO (duplicado)
Valores
RECIBO(duplicado)=Valores + CHEQUE =LISTADO DE COBRANZAS.

4.4. CAJERO firma LISTADO DE COBRANZAS
4.5. CAJERO entrega LISTADO DE COBRANZAS al COBRADOR
4.6.
CAJERO
COBRANZAS
actualiza PLANILLA
DE
CAJA con LISTADO
DE
4.7. CAJERO archiva RECIBO DE COBRO(duplicado).

4.8. COBRADOR entrega a COBRANZAS
DOCUMENTOS PERCIBIDOS
VALORES NO PERCIBIDOS
(Estos datos forman parte de la lista de cobranzas)
4.9. COBRADOR entrega a COBRANZAS.
LISTADO DE COBRANZAS
RECIBO DE COBRO (triplicado y cuadruplicado).
RECIBO DE COBRO PROVISORIO (triplicado y cuadruplicado).
DOCUMENTOS A COBRAR (percibidos)
DOCUMENTOS A COBRAR (no cobrados).
FACTURAS (no cobradas)

4.10. COBRANZAS controla LISTADO DE COBRANZAS.
Valores efectivos, cheques + Pagar de cliente + Factura y Documentos no cobrados = Importe total
del Listado de Cobranzas.
4.11. COBRANZAS entrega LISTADO DE COBRANZAS (duplicado) al
COBRADOR.
4.12.
COBRANZAS
actualiza, REGISTRO
los DOCUMENTOS A COBRAR.
DE
VENCIMIENTOS con
4.13. COBRANZAS archiva
LISTADO DE COBRANZAS (original)
DOCUMENTOS A COBRAR
FACTURAS (no cobradas)

4.14. COBRANZAS enva a CUENTA CORRIENTE.
RECIBOS DE COBRO (triplicados y cuadruplicados)
RECIBO DE COBRO PROVISORIO (triplicados y cuadruplicados)
5. REGISTRACIN DE LA COBRANZA.
5.1. CUENTA CORRIENTE con RECIBO (triplicado y cuadruplicado). acredita
DEUDORES VARIOS
DOCUMENTOS A COBRAR
5.2. CUENTA CORRIENTE totaliza Dbitos y Crditos.
5.3. CUENTA CORRIENTE confecciona MINUTA CONTABLE.
5.4. CUENTA CORRIENTE enva MINUTA CONTABLE A CONTADURA.
5.5. TESORERA enva MINUTA CONTABLE a CONTADURA.
5.6. CONTADURA controla MINUTA CONTABLE
5.7. CONTADURA registra.
Confeccione el correspondiente Diagrama de Flujo de Datos !
En cada ejercicio encontrar:

1- El Procedimiento al que se refiere el ejercicio.
2- La Operacin a automatizar
3- Los Algoritmos que resuelven la operacin
4- El Diseo de los Archivos que se precisan
5- El Diseo del Modoelo Relacional de Datos
6- Los Mdulos para cada Operacin
7- El rbol del Sistema que integra a los mdulos
8- La Base de Datos final en Access
01
02
03
04
Ejercitacin
08
09
10
11
12
13
14
15
16
17
18
1 Procedimiento
Anlisis de costo de la produccin
Operaciones
06
07
EJERCICIO N:1
2.
05
Emitir los informes:
1.
Costo de cada pedido
2.
Costo de todos los pedidos
3.
Costo unitario promedio
Para ello se debe calcular:
1.
El Costo de cada pedido
2.
El Costo de todos los pedidos
3.
El Costo unitario promedio
Algoritmos
COSTO DEL PEDIDO:

Agrupar por Nmero de pedido
Costo del pedido = Cantidad pedida x Costo unitario.
COSTO DE TODOS LOS PEDIDOS:
Costo de todos los pedidos = suma(Cantidad pedida x Costo unitario).
COSTO UNITARIO PROMEDIO:
Suma (Cantidad pedida).
Costo unitario promedio = Costo de todos los pedidos/ suma(Cantidad pedida)
Diseo de los Archivos
MAESTRO:
MATERIALES(Nmero de artculo, Descripcin del material, Costo unitario, Existencia)
TRANSACCIONES:
PEDIDO DE MATERIALES(Nmero de pedido, Nmero de artculo, Cantidad pedida)
Diseo del modelo relacional de datos
MDULOS
ARBOL DEL SISTEMA
BASE DE DATOS: 01.mdb
EJERCICIO N:2
1 Procedimiento
Actualizar archivo STOCK
2.
Operaciones
1.
Actualizar el campo Cantidad en existencia del archivo STOCK con la

informacin contenida en el archivo RESUMEN DE VENTAS.
2.
Generar un informe con la totalidad de datos del

archivo STOCK (ACTUALIZADO)
3.
3
Generar un informe del Importe total de las ventas.
Algoritmos
Cantidad en existencia = Cantidad en existencia - Cantidad vendida

Importe total de ventas = suma(Precio unitario x Cantidad vendida)
ARCHIVO MAESTRO:
STOCK(Nmero de artculo, Descripcin, Precio unitario, Cantidad en existencia).
ARCHIVO DE TRANSACCIONES:
RESUMEN DE VENTAS(Nmero de venta, Nmero de artculo, Cantidad vendida).
MDULOS
RBOL DEL SISTEMA
EJERCICIO N:3
1 Procedimiento
Actualizacin y control de Existencias
Operaciones
Actualizar:
Las Unidades en existencia del archivo EXISTENCIAS en base al archivo de NOVEDADES.
Seleccionar los registros de EXISTENCIAS:
Con movimientos;
que incrementaron su Cantidad;
que disminuyeron su Cantidad.
Imprimir:
El archivo EXISTENCIAS (actualizado);

un informe del archivo EXISTENCIAS de los registros que tuvieron movimiento;
un informe de Unidades en existencia que han aumentado su saldo;
un informe de Unidades en existencia que han disminuido su saldo.
Algoritmos
Si Movimiento = Ingreso, entonces: Unidades en existencia = Unidades en existencia + Cantidad

Si Movimiento = Egreso, entonces: Unidades en existencia = Unidades en existencia - Cantidad
ARCHIVO MAESTRO:
EXISTENCIAS(Cdigo de repuesto, Descripcin, Nmero de depsito, Nmero de estante, Costo unitario,
Unidades en existencia)
NOVEDADES(Nmero de operacin, Cdigo de repuesto, Cantidad, Movimiento).
Dominio:
Movimiento = {Ingreso, Egreso}
Mdulos
rbol del sistema
EJERCICIO N:4
1 Procedimiento
Actualizacin y control de existencias
2.
Operaciones
Actualizar el archivo PRODUCTOS, segn los datos provenientes del

archivo NOVEDADES DE PRODUCTOS:
La Cantidad en existencia;
El Costo unitario (precio promedio ponderado).
Calcular:
La Cantidad total de productos ingresados, detallados por Cdigo del producto;

El Promedio general de costo por unidad.
Imprimir:
La Cantidad total de productos ingresados, detallados por Cdigo del producto

El Promedio general de costo por unidad.
Algoritmos
Existencia valorizada:
Si Movimiento = Ingreso entonces: Cantidad en existencia = Cantidad en existencia + Cantidad

Costo unitario = (Cantidad en existencia x Costo unitario + Cantidad x Precio de ingreso) / (Cantidad en
existencia + Cantidad)
Promedio general de costo por unidad = suma(Costo unitario x Cantidad en existencia) / suma(Cantidad en
existencia)
ARCHIVO MAESTRO:
PRODUCTOS(Cdigo del producto, Denominacin, Costo unitario, Cantidad en existencia)
NOVEDADES DE PRODUCTOS(Nmero de operacin, Cdigo del producto, Movimiento, Cantidad,
Precio de ingreso)
Dominios:
Movimiento = {Ingreso, Egreso}
Mdulos
rbol del sistema
EJERCICIO N:5
1 Procedimiento
Liquidacin de jornales.
2.
Operaciones
Calcular.
Importe bruto.
Aporte del personal.
Aporte patronal.
Importe neto.
Totalizar.
Acumulado de: Importe bruto, Aporte del personal, Aporte patronal , e Importe neto.
Confeccionar un formulario para recibos.
Imprimir un informe de totales.
Algoritmos
Importe bruto = Cantidad de horas trabajadas x Valor hora

Aporte del personal = Importe bruto x 10%
Aporte patronal = Importe bruto x 20%
Importe neto = Importe bruto - Aporte del personal.
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora).
NOVEDADES (Id nmero de operacin, Nmero de legajo, Cantidad de horas trabajadas)
Mdulos
rbol del sistema
EJERCICIO N:6
1 Procedimiento
Liquidar jornales
2.
Operaciones
Calcular:
Total bruto de la liquidacin

Total neto de la liquidacin
Totales de los aportes patronales
Totales de los aportes personales.
Imprimir:
Recibos
Informe el total de aportes personales y patronales
Algoritmos
Bonificacin por antigedad = 10$ x Aos de antigedad

Importe bruto = (Cantidad de horas trabajadas x Valor hora) + Bonificacin por antigedad
Aporte del personal = Importe bruto de cada liquidacin x 10%
Aporte patronal = Importe bruto de cada liquidacin x 20%
Si Estado civil = casado, entonces: Asignacin por cnyuge = 10 $
Asignacin por hijo = 16$ x Cantidad de hijos
Importe neto = Importe bruto - Aporte del personal + Asignacin por cnyuge + Asignacin por hijo.
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora, Cantidad de hijos, Estado civil, Aos de
antigedad)
Dominio:
Estado civil ={casado, soltero}
Mdulos
rbol del sistema

EJERCICIO N:7
1 Procedimiento:
Liquidar jornales
2.
Operaciones
Calcular

Totales de los aportes personales
Actualizar la acumulacin, del Acumulado importe bruto para aguinaldo, para

el clculo del sueldo anual complementario
Imprimir recibos
Algoritmos
Importe bruto = Cantidad de horas trabajadas x Valor hora

Acumulado sueldo anual complementario = Importe bruto
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora, Acumulado importe bruto para aguinaldo)
Mdulos
rbol del sistema

EJERCICIO N:8
1 Procedimiento:
Liquidar jornales
Operaciones
Calcular:

Actualizar la acumulacin, del Acumulado importe bruto para aguinaldo, para

Imprimir recibos
Algoritmos
Bonificacin por antigedad = Aos de antigedad*10$

Importe bruto = Cantidad de horas trabajadas x Valor hora + Bonificacin por antigedad
Si Estado Civil = casado, entonces: Asignacin por cnyuge = 10$
Importe neto = importe bruto - Aporte del personal + Asignacin por cnyuge + Asignacin por hijo.
Sueldo anual complementario = Cantidad de horas trabajadas x Valor hora = Importe bruto
ARCHIVO MAESTRO:
PERSONAL = (Nmero de legajo, Apellido y nombre, Valor hora, Acumulado importe bruto para aguinaldo,
Cantidad de hijos, Estado Civil, Aos de antigedad)
Dominio:
Estado civil = { casado , soltero}

Mdulos
rbol del sistema
EJERCICIO N:9
1 Procedimiento:
Liquidar jornales
Operaciones
Calcular:

Imprimir recibos
Algoritmos
Importe bruto = Cantidad de horas trabajadas x Valor hora x Cdigo de hora

( un mismo legajo puede incluir horas trabajadas normales y distintos tipos de horas extras)
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora).
NOVEDADES (Id nmero de operacin, Nmero de legajo, Cantidad de horas trabajadas, Cdigo de hora)
Dominio:
Cdigo de hora = {1=Valor hora, 2= Valor hora x 0,5, 3= Valor

hora x 2}
Mdulos
rbol del sistema

EJERCICIO N:10
1 Procedimiento:
Liquidar jornales
Operaciones
Calcular:

Imprimir recibos
Algoritmos
Bonificacin por antigedad = Aos de antigedad x 10$

Importe bruto = (Cantidad de horas trabajadas x Valor hora x Cdigo de la hora)+ Bonificacin por
antigedad
Importe neto = Importe bruto - Aporte del personal + Asignacin por cnyuge + Asignacin por hijo.
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora, Cantidad de hijos, Estado Civil, Aos de
antigedad).
Dominio:
Estado civil = {casado , soltero}
Mdulos
rbol del sistema
EJERCICIO N:11
1 Procedimiento:
Liquidar jornales
Operaciones
Calcular:

Actualizar la acumulacin, del Acumulado importe bruto para aguinaldo, para el

clculo del sueldo anual complementario
Imprimir recibos
Algoritmos
Bonificacin por antigedad = Aos de antigedad x 10

Jornal = (Cantidad de horas trabajadas x Valor hora x Cdigo de la hora)
Importe bruto = Jornal + Bonificacin por antigedad
Asignacin por hijo =16$ x Cantidad de hijos
Importe neto = Importe bruto + Asignacin por cnyuge + Asignacin por hijo- Aporte del personal.
Sueldo anual complementario = (Cantidad de horas trabajadas x Valor hora x Cdigo de la hora) (Jornal)
Cdigo de la hora ={1=Valor hora; 2=Valor hora x 1,5 ; 3=Valor hora x 2}
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora, Acumulado importe bruto para aguinaldo,
Cantidad de hijos, Estado Civil, Aos de antigedad)
Dominio:
Estado civil = {casado , soltero}
Dominio:
Cdigo de hora = {1; 2; 3 }
Mdulos
rbol del sistema

EJERCICIO N:12
1 Procedimiento:
Liquidar jornales
Operaciones
Calcular:

Actualizar la acumulacin, del , Acumulado importe bruto para aguinaldo, para

Imprimir recibos
Algoritmos
Importe bruto = (Cantidad de horas trabajadas x Valor hora x Cdigo de la hora)

Sueldo anual complementario = Cantidad de horas trabajadas x Valor hora x Cdigo de la hora
Cdigo de la hora ={1=Valor hora; 2=Valor hora x 1,5 ; 3=Valor hora x 2}
ARCHIVO MAESTRO:
PERSONAL (Nmero de legajo, Apellido y nombre, Valor hora, Acumulado importe bruto para aguinaldo)
Dominio:
Cdigo de la hora ={1; 2; 3}
Mdulos
rbol del sistema
EJERCICIO N:13
1 Procedimiento
Consulta al padrn de empleados
Operaciones
Contar registros de EMPLEADOS
Imprimir la cantidad total de empleados registrados
Consultar el ltimo domicilio informado por cada empleado
Consultar el nivel de estudios alcanzado por cada empleado
Para ello cuenta con tres archivos clasificados por nmero de documento de identidad. Los tres archivos son
completos, es decir que los datos de cada empleado se encuentran en los tres archivos.
Diseo de los archivos
MAESTRO:
PERSONAL(Nmero de documento, Apellido y nombre)
TRANSACCIONES:
DOMICILIOS(Nmero de documento, Fecha de informe, Calle, Nmero, Piso, Departamento, Cdigo
postal)
ESTUDIOS(Nmero de documento, Nivel de estudio, Fecha del ttulo)
Mdulos
rbol del sistema

EJERCICIO N:14
1 Procedimiento
Consulta al padrn de empleados
Operaciones
Listar un padrn con los datos de los empleados.
Imprimir, cuntos empleados se tienen registrados.
Para ello cuenta con tres archivos: EMPLEADOS, DOMICILIOS Y ESTUDIOS. Clasificados por nmero de
documento de identidad.
Los archivos de EMPLEADOS Y DOMICILIOS son completos, es decir que los datos de cada empleado se
encuentran en los dos archivos.
El archivo ESTUDIOS puede contener datos faltantes en el campo Nivel de estudio.
Este ltimo punto implica que el campo puede contener valores nulos; para identificar los valores nulos, se
definir la propiedad del campo como longitud cero, y en el formato del campo se le asignar la leyenda: "NO
ENTREG TTULO"
Diseo de los registros
ARCHIVO MAESTRO:
PERSONAL(Nmero de documento, Apellido y nombre)
ARCHIVOS DE TRANSACCIONES:
DOMICILIOS(Nmero de documento, Fecha de informe, Calle, Nmero, Piso, Departamento, Cdigo
postal)
ESTUDIOS(Nmero de documento, Fecha del ttulo, Nivel de estudio)
Mdulos
rbol del sistema
EJERCICIO N:15
1 Procedimiento
Actualizacin y control de existencias:
2.
Operaciones
Calcular
Stock a valor de mercado

Costo de la mercadera
Utilidad
Importe total de ventas
Actualizar su archivo de stock
Emitir un listado de stock actualizado; respecto a los artculos que se realizaron

ventas; se imprimir:
la existencia actualizada, valorizada al precio de venta,

costo de la mercadera, y
la diferencia entre ambas.
Imprimir el Importe Total correspondiente a las ventas realizadas.
Algoritmos
Stock a valor de mercado = Cantidad en existencia x Precio unitario

Costo de la mercadera = Cantidad en existencia x Costo unitario
Utilidad = Costo de la mercadera - Existencia actualizada
Importe total de ventas = suma(Cantidad vendida x Precio unitario)
Todos los archivos contienen un registro por cada artculo, y estn clasificados por nmero de artculo en
forma secuencial ascendente.
MAESTRO:
STOCK (Nmero de artculo, Descripcin, Precio unitario, Cantidad en existencia, Costo unitario)
TRANSACCIONES:
DETALLE DE VENTAS (Nmero de venta, Nmero de artculo, Cantidad vendida)
COSTO POR ARTCULO (Nmero de artculo, Costo unitario)
Mdulos
rbol del sistema

EJERCICIO N:16
1 Procedimiento
Control de la produccin
Operaciones
Se desea:
Listar diariamente:
los partes de produccin de los distintos productos finales que elabora
Calcular:
El Costo total por producto,

El Costo de la orden y
El Costo total de la produccin del da.
Para ello cuenta con datos almacenados en los archivos cuyo detalle de contenido se muestra ms abajo. Los
registros de los archivos PARTES DE PRODUCCIN y el maestro de PRODUCTOS se encuentran
ordenados por nmero de producto.
Algoritmos
Costo total = Suma(Costo unitario x Cantidad elaborada) de cada Nmero de producto

Costo de la orden = Suma(Costo unitario x Cantidad elaborada) de todos los Nmeros de productos
Costo total de la produccin del da = Suma (Costo de la orden) de todas las rdenes de un mismo da.
MAESTROS:
PRODUCTOS(Nmero de producto, Descripcin, Costo unitario)
SUPERVISORES(Nmero de supervisor, Apellido y nombre)
TRANSACCIONES:
PARTES DE PRODUCCIN (Nmero de parte, Nmero de producto, Nmero de supervisor, Cantidad
elaborada)
Mdulos
rbol del sistema

EJERCICIO N:17
1 Procedimiento
Actualizacin de stock y control de la produccin.
Operaciones
Se desea:
Calcular:
Costo de cada orden,

Costo total por producto utilizado y
Costo de la produccin del da.
Actualizar el archivo maestro de PRODUCTOS con la cantidad producida

indicada en el archivo de PARTE DE PRODUCCIN.
Listar diariamente los PARTES DE PRODUCCIN de los distintos productos

finales que elabora
Algoritmos
Para el Costo de cada orden: Primero agrupar por nmero de orden; segundo Suma(Costo unitario standard x
Cantidad elaborada)
Para el Costo total por producto: Primero agrupar por nmero de producto; segundo Suma(Costo unitario
standard x Cantidad elaborada])
Para el Costo de la produccin del da: Primero agrupar por fecha; segundo Suma(Cantidad elaborada x Costo
unitario standard])
Actualizar el archivo maestro de PRODUCTOS = Cantidad - Cantidad elaborada
TRANSACCIONES:
PARTES DE PRODUCCIN (Fecha, Nmero de parte ,Nmero de producto, Nmero de supervisor,
Cantidad elaborada)
MAESTROS:
PRODUCTOS (Nmero de producto, Descripcin, Costo unitario standard, Cantidad)
SUPERVISORES (Nmero de supervisor, Apellido y nombre)
Mdulos
rbol del sistema

EJERCICIO N:18
1 Procedimiento
Facturacin.
Operaciones
Emitir su facturacin por computadora.
El departamento de contabilidad de la empresa necesita conocer, adems de la

emisin de la facturacin, el importe de la facturacin total de cada proceso.
Actualizar archivo SOTCK.
Algoritmos
Para emitir la factura: Precio total = Cantidad x Precio unitario

Para la facturacin total de cada proceso: Suma precio total = suma ( Cantidad x Precio unitario)
Para actualizar SOTCK: Saldo = Saldo - Cantidad
MAESTROS:
CLIENTES(Cdigo de cliente, Apellido y nombre, Domicilio)
ARTCULOS(Cdigo de artculo, Descripcin, Saldo, Precio unitario)
TRANSACCIONES:
VENTAS(Nmero de venta, Cdigo de cliente, Cdigo de artculo, Cantidad, Fecha de venta)
Mdulos
rbol del sistema
En cada ejercicio encontrar:

1
Un enunciado
Una tabla de Datos
Un Diagrama de Flujo
Un Hipervnculo a un archivo de planilla electrnica Excel
conteniendo la automatizacin del problema.
Simbologa Norma IRAM 36002:
Bloque de Decisin
Bloque de Accin
Lneas de Direccin
Comienzo o fin
Entrada/Salida
Diskette
Disco magntico
Cinta magntica
Papel Impreso
Conector dentro de la
pgina
Teclado
Pantalla
Ejercicios:
01
09
02
10
03
11
04
12
05
13
06
14
07
15
08
16
EJERCICIO 1-01
Operacin de suma.
Se dispone de un archivo en planilla electrnica con
datos de productos, cuyo diseo se muestra a
continuacin.
Existe un registro ( fila ) por cada lnea de producto.
El ltimo registro no contiene informacin vlida y
posee la seal /* en el campo "A".
CODIGODE
CODIGODE
CANTIDAD
PRECIODE
LINEA
COLOR
EXISTENCIA
VENTA
10
10
15
20
El significado de los campos ( columnas ) es el

siguiente
:
Campo "A" : cdigo de lnea de producto
Campo
"B":
cdigo
color
:
cdigo
"1":
blanco
cdigo
"2":
rojo
cdigo
"3":
azul
cdigo
"4":
otro
Campo
"C":
cantidad
en
existencia
Campo "D": precio de venta
Se desea obtener un listado que indique el total de
unidades existentes en el archivo (de todos los
productos) y el total de lneas de productos en el
archivo (cantidad de cdigos de productos).
EJERCICIO 1-02
Operaciones
de
multiplicacin
y
suma
Con el mismo archivo del ejercicio 1-01 se desea
obtener el importe total inmovilizado por mantener la
existencia de productos registrada en el archivo.
EJERCICIO 1-03
Operacin de suma y decisin con el archivo cuyo contenido se muestra en este

ejercicio, se desea obtener e imprimir la cantidad de lneas de productos de color
blanco y la cantidad de unidades de los productos de color rojo.
El diseo de los registros del archivo es el indicado para el ejercicio 1-01 .
cuando aqu se pide cantidad de lneas de productos de color blanco se refiere a
los datos registrados en el campo "B" de los registros del archivo.
REGISTRO
LINEA
COLOR
EXISTENCIA
PCIODEVTA
10
10
15
20
10
20
EJERCICIO 1-04
Operacin de multiplicacin , suma y decisin.
Con el archivo que se muestra en este ejercicio , cuyos
registros tienen el mismo diseo de campos indicado
en el ejercicio 1-01, se desea obtener: el importe
promedio inmovilizado de todas las lneas de productos
( a precio de venta), la cantidad de lneas de productos
en el archivo y la cantidad de lneas de productos cuyo
importe supere los $50.
En el archivo cada registro (fila) equivale a una lnea
de producto, o sea que existen tantas lneas de
productos como registros vlidos son ledos.
LINEA
COLOR
EXISTENCIA
PCIODEVTA
15
20
10
10
EJERCICIO 1En una Oficina de personal se dispone de un archivo en el que consta, para cada
empleado y en una fila por da laborable, una serie de datos relativos a ausencias y
toros conceptos sobre comportamiento del personal.
En uno de los campos (columnas) de los registros (filas), que se identifica como
campo W, se encuentra una letra "A" cuando el empleado a quien se refiere ese
registro ha estado "ausente" el da indicado en el mismo. No figura ningn dato en ese
campo, cuando no se registra ausencia.
Por poltica de administracin de personal, el gerente del rea aplica una suspensin
al empleado que incurre en cinco ausencias consecutivas.
Se ha previsto utilizar un sistema de informacin para la deteccin de esta

circunstancia.
En consecuencia, debe realizarse previamente un diagrama de lgica a travs del cual,
una vez programado, se puede detectar si en la corrida del programa respectivo se
presentan cinco registros consecutivos con cdigo "A" en el campo W.
Se efecta una corrida mensual para cada uno de los empleados en cada corrida o
proceso se incluyen registros de un solo empleado; o sea que habr tantas corridas
como empleados. Los registros ingresan a la lectura ordenados cronolgicamente,
dentro del lote correspondiente a cada empleado. el proceso finalizar por ltimo
registro, identificada /*, o bien al detectarse la presencia de los cinco registros
consecutivos con registracin de ausencia. En esta ltimo caso, se imprimir una
leyenda declarativa de la situacin.
ORDENDE
CAMPO
CAMPO
SECUENCIA
NRO.DE
LECTURA
EMPLEADO
1002
1002
1002
1002
1002
1002
1002
1002
1002
1002
EJERCICIO 1-06
Continuando con el planteo presentado en el ejercicio 1-05 , por poltica de
administracin del personal tambin se aplica una suspencin a aquellos empleados
que tengan un mnimo de seis ausencia en el mes, aunque stas no sean
consecutivas.
Igual que en el caso anterior se efectuar una corrida para cada empleado y la corrida
ser mensual.
Deber disearse el diagrama de lgica que servir de base para la codificacin del
programa respectivo. Se aclara que esta corrida es independiente de la identificada en
el ejercicio 1-05.
ORDENDE
CAMPO
SECUENCIA
NRO.DE
LECTURA
EMPLEADO
1002
1002
1002
1002
1002
1002
1002
1002
CAMPO
EJERCICIO 1-07
Se posee una secuencia de 200 nmeros de cinco cifras cada uno, en cada fila y hay
un nmero en cada columna.
Se desea que sean impresos solamente aquellos nmeros capicas (aquellos que son
iguales tanto si se los lee de izquierda a derecha o viceversa).
ORDENDE
ARCHIVODEENTRADA
DELCTURA
SECUENCIA
200
EJERCICIO 1-08
Se posee un lote de 100 registros que contienen en cada campo un valor numrico.
Se desea detectar e imprimir todos aquellos valores numricos positivos.
campo"N"
1
5
0
2
6
9
EJERCICIO 1-09
Realizar un diagrama de lgica para obtener e imprimir la sumatoria de los nmeros
naturales consecutivos comprendidos entre 1 y 10.(por tratarse de una suma de
nmeros consecutivos entre dos nmeros dados, no se requiere lectura de un archivo
de entrada).
secuencia
1
2
3
4
5
6
7
8
9
10
EJERCICIO 1-10
Dada una tabla de 700 filas, las cules tienen en una columna un valor numrico se
desea calcular e imprimir el promedio de dichos valores.
ORDENDE
CAMPO
LECTURA
"N"
1050
260
590
710
620
180
EJERCICIO 1-11
La empresa JCA . S.A. ha solicitado se listen datos del archivo de cuentas corrientes
de sus clientes.
Para ello se cuenta con un archivo en disquete en el que se ha grabado un movimiento
en cada registro.
El diseo de los registros es el siguiente:
Campo A ; nmero de cuenta
Campo B : Cdigo de movimiento
0 saldo
1 crdito
2 dbito
Campo C: Importe
El ltimo registro contiene un "9" en campo B.
SECUENCIA
NUMERODE
CODIGODE
LECTURA
CUENTA
MOVIMNTO
IMPORTE
201
1000
201
400
202
200
202
100
202
50
203
600
204
800
204
300
EJERCICIO 1-12
Una empresa desea llevar el control de los gastos en que incurren los dependientes del
departamento Ventas.
Para ello, por cada gasto en que se incurre un comprobante cuyos datos son luego
grabados en un disquete.
Cada registro del disquete contiene : nmero de vendedor. cdigo de gasto, importe.
Se deber imprimir por final de archivo 8 identificado con un 9 en campo b) el total de
los gastos por tipo.
Diseo de cada registro:
campo A : numero de vendedor
Campo B : cdigo del gasto
01 gasto de movilidad
02 gasto de representacin
03 vale de combustible
LECTURA
300
500
200
700
400
600
100
12
100
15
200
10
EJERCICIO 1-13
En una Universidad Privada se dictan las carreras de Contador Pblico (CP) y de

Licenciado en Administracin(LA).
De acuerdo al plan de estudios, durante el primer ao se dicta el llamado "curso
introductorio", que habilita a quien lo aprueba, a ingresar en algunas de las carreras
mencionadas(CP,, L o en ambas a la vez).
La Universidad, por razones de planificacin administrativa y docente intenta conocer
una proyeccin del deseo de sus estudiantes de primer ao respecto a la orientacin
que seguirn al ingresar al segundo ao.
Para ello encarg a su asesor que formular una encuesta sobre este tema y que sobre
la base de las respuestas, elaborara un informe que permitiera conocer las siguientes
conclusiones:
1
Total
de
estudiantes
consultados
2
Porcentaje
de
estudiantes
que
proyectan
seguir
CP
3
Porcentaje
de
estudiantes
que
proyectan
seguir
LA.
4
Porcentaje
de
estudiantes
que
proyectan
seguir
CP
Y
LA.
5 Porcentaje de estudiantes que proyectan seguir CP y que no aceptarn pasar a la
carrera LA.
6 Porcentaje de estudiantes que proyectan seguir LA y que no aceptarn pasar a la

carrera CP
7 Porcentaje de estudiantes que no proyectan seguir ni la carrera de CP ni la de LA por

no resultarles satisfactoria la enseanza recibida en el curso introductorio.
Para poder procesar electrnicamente la respuesta obtenida en la consulta, se ha
logrado grabar la misma en un disquete, donde cada registro contiene datos
referentes a la respuesta de cada estudiante consultado.
Estas respuestas se expresan en los registros de la siguiente forma: cada registro
contiene dos campos : A Y B .
Los campos A y B pueden tener grabados los siguientes cdigos, cuyo significado se
indica en cada caso:
CAMPO A: cdigo S (indica que pretende seguir CP)
Cdigo N( indica que no pretende seguir CP)
CAMPO B: Cdigo S (indica que pretende seguir LA)
Cdigo N (indica que no pretende seguir LA)
EJERCICIO 1-14
No se dispone de ningn archivo de entrada de datos.
Sin embargo se desea acumular los valores de los N primeros nmeros naturales e
imprimir el resultado.
En esta caso, el valor de N debe ser introducido en el proceso cada vez que ste se
ejecute.
N=
20
EJERCICIO 1-15
No se dispone de ningn archivo de datos.
Pero se desea formular un algoritmo para determinar el resultado de multiplicar entre
s los N primeros nmeros naturales e imprimir el mismo.
En esta caso el valor de N debe ser introducido en el proceso en cada ocasin en que
ste se ejecute.
N=
EJERCICIO 1-16
En el departamento de Control de Calidad de una empresa elaboradora de materiales

de alta precisin se efectan peridicas pruebas de verificacin de la exactitud de las
medidas de las piezas elaboradas, a efectos de detectar y rechazar aquellas que no
observan estrictamente las dimensiones exigidas segn planos.
A tal efecto, una delicada maquinaria mide el calibre y la longitud de cada una de las
piezas elaboradas y mantiene grabada esa informacin en un soporte magntico
adecuado.
El diseo de los registros es el siguiente:
Campo A Nro. de pieza
Campo B: Calibre (en mm)
Campo C: Longitud (en mm)

Son admitidas aquellas piezas cuyo calibre no sea inferior a 2 mm, y cuya longitud no
supera los 60 mm.
Se debe elaborar un diagrama para luego confeccionar un programa que permita
determinar e imprimir la cantidad de piezas registradas cuyo calibre sea inferior a los
2 mm, y por separado, la cantidad de piezas cuya longitud supera los 60 mm. el final
de archivo se detecta al leer FF en el campo C (longitud) del ltimo registro grabado.
RENGLON
2,00
61
1,99
59
1,98
58
2,01
60
2,00
61
2,02
62
2,00
58
1,99
61
10
FF
BIBLIOGRAFA
Ackoff Rusell L.; Planejamento empresarial, Livros tcnicos e cientficos editora.
Ackoff Rusell, Vergara Finnel E., Gharajedaghi J. , Gua para controlar el futuro de la
empresa, Limusa
Allen Pau C., Tcnicas estructuradas efectivas, El Ateneo Buenos Aires 1996.
Batini Carlos, Stefano Ceri y Shamkent B. Nabathe, Diseo conceptual de bases de datos,
Addison-Weslwy/Diaz de Santos, 1994.
CASE IN THE 90,Comunication of de ACM, vol 35 N 4 april 1992
CASTELLANI Mrcia Reiff Aspectos Crticos Na Implentao De Ferramentas Case

Caderno De Pesquisas Em Administrao, So Paulo, V.1 , N 1, 2 Sem./1995
Deming , Total Quality
Diaz, Alberto, Descripcin de operaciones tpicas de una Empresa, Editorial Club de

estudio, Buenos Aires Fascculo 2.
Edit Grassini Lino de Campos, Judith Pavn, Paulo S. Cugnasca; Anlise Comparativa de
Ferramentas Grficas de Manipulaao de Banco de Dados; 2da. Jornada USP-SUCESU-SP
de informtica e telecomunicacoes. Mayo 1994
Gorry, G.A. y Scott Morton, M:S:, A framework for management information systems, in
Management Review, otoo 1971.
Henry C. Lucas Jr., Sloan Management Review, invierno 1978, The evolution of an
information system: from key-man to every person.
Hertz, David B.;"Risk Anaysis in Capital Investiment", harvard Business Review 42 (1):
95:106.1964
ISO 9004, 5.3.3 Quality plans 1987
Gary L. Lilien y Philip Kotler, Marketing decision Making A Model-Building Approach.

Harper & row Publishers, inc., segunda edicin1992
Lardent A.,Gomez Echarren Manuel A., Loro Alberto; Tcnicas de Organizacin Sistemas
y Mtodos, Club de estudio 1984.
Lardent Alberto, Diagramacin lgica, Club de estdio, 1987.
Lucas H., The evolution of an infromation system: from key-man to every person., Sloan
Managemente Review.
Martin James, Sistemas de Informacin, El Ateneo.
Martin Merle P.; Busness Information System, secon edittion; Pretince Hall 1.995.
Martin, J. Conceptual Strucutres: Information Processing in Mind and Machine. Addison

Wesley, California 1984.
NOVELLI FILHO, Aristides; GRIGAS VARELLA FERREIRA, Mara A.; Case e

Metodologa para Projetos de pequeno porte ; 2 jornada USP-SUCESU-SP de informtica
e telecomunicaoes 1994 Pg56.
Parro Nereo Roberto, Administracin de Empresas, T III, pg. 289.
Pereira,F.C.N.&Warren, D.H.D Definite Clause Grammanrs for Language Analsis-A

Surveyof the Formalism and a Comparison with Augmented Transition Networks".
Artificial Intelligence 13,231-278.
PERISS Marcelo Claudio, APLICACIN TRIBUTARIA, INFORMATE, Modelo para la

Compra de Software de Aplicacin, la Importancia de Saber Evaluar al Software de
Aplicacin y a los Proveedores, Disponible en Internet
<http://www.aplicacion.com.ar/revista>
Pressman Roger S. Ingeniera del Software McGraw-Hill.
Randolph Alan W., Posner Barry Z. Grijalbo 1991
Richard Barker, el modelo entidad - relacin CASE * METHOD, Addison - Wsley / Diaz
de santos 1994.
Senn, James A., Anlisis y diseo de sistemas de informacin, McGraw-hill, 1992,segunda

edicin.
Fred L luconi , Thomas W. Malone, Michaels s. Scott Morton, Sistemas expertos: el

prximo desafo para los gerentes, Administracin de empresas.
Tecnologa CASE, Cuaderno de SADIO, serie Informtica N 9 noviembre de 1993.,

Comunication of de ACM, case IN THE 90.
Torn Juan P., Proyectos informticos, Parainfo 1994.
Vidal, Antonio Geraldo, , Introduccin al proyecto y desenvolvimiento de sistemas de

Informacin FEA, USP, 1998.
Yourdon E., Anlise Estruturada Moderna, Editora Campus 1990.
Zwicker Ronaldo, Aprendizagem e Uso de Sistemas. Anais do XXIV Congreso Nacional de

Informtica, Sao Paulo, 1991.
Ficha
Datos de la Ficha
Ttulo: Proyecto Informtico Una Metodologas Simplificada
Autor: Marcelo Claudio Periss
Tema: Sistemas de Informacin
Tema: Computacin
Abstract: Se presenta una metodologa estructurada simplificada,
para la automatizacin de procedimientos administrativos.

Esta metodologa puede ser llevada adelante en proyectos
de pequeo y mediano porte, por un grupo de dos a cuatro
personas.
Colaborad
ores:
Fecha: febrero del 2001
Formato: HTML
Identificad
ISBN: 987-43-2947-5
or:
Fuente: Tcnia Administrativa
Idioma: Espaol
Relacin:
Cobertura:
URL:

Analisis de Un Proyecto

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis de Un Proyecto

Enviado por

Direitos autorais:

Formatos disponíveis

NDICE

3.1.2.LLAVE PRIMARIA O IDENTIFICADORA

4.2.2. EL DIAGRAMA DE FLUJO DE DATOS

RECOMENDACIONES PARA UN DFD

mejoramiento de una situacin dada.

1. Tener un principio y un fin

6. Contar con los recursos necesarios para desenvolver las actividades

de las que no pueden dejarse pasa por alto.

1.1. QU ES UN PROYECTO INFORMTICO

FIGURA1.1 Clasificacin de los sistemas de informacin

planeamiento estratgico, control gerencial y control operacional de Anthony.

La siguiente tabla muestra la estructura conceptual de Gorry y Scott Morton.:

Estructura Cuentas a Cobrar Anlisis

Presupuesto a corto plazo

1.2. INICIO DE UN PROYECTO NFORMTICO

Figura 1.2 Categoras de los sistemas de informacin

2. PLANEAMIENTO DE UN PROYECTO INFORMTICO

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

2.1. MTODOS DE PLANIFICACIN TEMPORAL DE TAREAS

3.1. ESTRUCTURA DE UNA BASE DE DATOS.

Descripcin del material

Disco rgido ATA 66

Disco Flexible de 3 1/2" 1,44 Mbytes

Papel carta para impresora.

Resma 100 hojas

Pentium III 500Mhz

Pentium III 800Mhz

Av. La Plata 365

Av. Rivadavia 3558

ARCHIVO DE ORIGEN DE LOS PRODUCTOS

Esta Base de Datos contiene informacin de tres Entidades:

Datos sobre productos (Entidad producto), almacenados en el

Datos sobre proveedores (Entidad proveedores), almacenados en el

Datos sobre el origen de los productos (Entidad origen del producto),

FIGURA 3.1 Modelo relacional de una tabla

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

3.1.2. LLAVE PRIMARIA O IDENTIFICADORA.

ARCHIVO DE PRODUCTOS: @ Cdigo artculo

ARCHIVO DE PROVEEDORES: @ Cdigo proveedor

ARCHIVO ORIGEN DE LOS PRODUCTOS: @(Cdigo proveedor +

llave primaria e, incrementa sensiblemente la velocidad de ejecucin de algunas operaciones

4.1. MODELOS CONCEPTUALES

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

QU ES UNA HERRAMIENTA CASE

Figura 5.1 Modelo del Proceso de Negocio

Figura 5.2 Modelo Relacional de Datos

Confeccionar la definicin de requerimientos de los usuarios,

Mejorar el diseo de los sistemas,

Mejorar la eficiencia en la programacin (por su generacin automtica de cdigos),

Otorgar a la administracin un mejor soporte en la documentacin.

Figura 5.3 Herramientas de edicin

Figura 5.4 Diccionario de Datos Editor

Figura 5.5 Diccionario de Datos Estructura

Figura 5.6 Chequeo de Reglas

Figura 5.7 Informe del Chequeo de Reglas

Automatizacin: Como venimos diciendo, se debe buscar la mxima

Velocidad: Tal lo visto en el primer captulo (ver 1. Proyecto

Cambiabilidad. Cuando vimos las causas que dan inicio a un proyecto

informtico (ver 1.2. inicio de un proyecto informtico), describimos que

Verificacin de condicin correcta. Confeccione y utilice

Tcnicas que faciliten la comunicacin con los usuarios finales.

Diseo estable de base de datos. La base de datos es el elemento

Modularidad. Los sistemas deben dividirse en mdulos fcilmente

Control de operabilidad mutua. Se necesita una tcnica formal y