Introducción
Un sistema se puede definir como un grupo de elementos
interdependientes o que interactúan regularmente formando
un todo. Para la clasificación de estos existen dos
categorías básicas, las cuales son: Sistemas
naturales, que a su vez se dividen en sistemas físicos y
vivientes, y Sistemas hechos por el hombre, de los cuales existe
una gran diversidad de sistemas construidos, organizados y
mantenidos por humanos, tales como: sistemas sociales, sistemas
de transporte, sistemas de comunicación, sistemas de
manufactura, sistemas financieros, entre otros.
En la actualidad, la mayoría de estos sistemas
incluyen las computadoras, pero es importante señalar que
dichos sistemas estaban antes de que existieran las mismas; de
hecho, algunos sistemas continúan por completo sin
computarizar y podrían permanecer así durante
muchas décadas más. Otros contienen a la
computadora como componente, pero también incluyen uno o
más componentes no computarizados (o manuales).
Los sistemas automatizados son sistemas hechos por el
hombre que interactúan o son controlados por una o
más computadoras. Aunque hay diferentes tipos de sistemas
automatizados, todos tienden a tener componentes en común,
como hardware, software, etc.
Por otra parte, es importante saber que un sistema de
información no es más que un conjunto u
ordenación de elementos organizados para llevar a cabo
algún método, procedimiento o control mediante el
proceso de información.
El análisis y diseño de sistemas se basa
en examinar la situación de una empresa con el
propósito de mejorar con métodos y procedimientos
más adecuados.
Metodología de
análisis
Modelo Esencial
Es un modelo de lo que el sistema debe hacer para
satisfacer los requerimientos del usuario, diciendo lo
mínimo posible acerca de como se implanta.
Específicamente, esto significa que cuando el
analista habla con el usuario acerca de los requerimientos del
sistema, debe evitar describir implantaciones específicos
de procesos (burbujas en un diagrama de flujo de datos) en el
sistema; es decir, no debe mostrar las funciones del sistema que
están siendo realizadas por humanos o por sistemas de
cómputo existentes. Como lo ilustran las siguientes
figuras, ésta opción arbitraria de cómo
podría implantarse el sistema; pero esta decisión
debería retrasarse hasta que haya comenzado la actividad
de diseño.
Figura 1: Modelo que muestra como
hará su labor una función
Figura 2: Muestra un Modelo esencial
más apropiado de lo que la función del sistema debe
realizar sin importar su implantación final.
Lo mismo se da para los flujos y almacenes de datos: el
modelo esencial debe describir el contenido de los flujos o
almacenes de datos, sin describir el medio (por ejemplo, disco o
cinta) u organización física de los
datos.
El modelo esencial consiste en dos
componentes principales:
1.- Modelo ambiental
2.- Modelo de comportamiento
Es importante desarrollar el modelo esencial de un
sistema, pues muchos sistemas de información grandes
tienen una vida media de unos 10 a 20 años. Durante ese
período se puede esperar que el hardware mejore por lo
menos por un factor de mil.
1.- Modelo ambiental
Para el analista de sistemas, la labor más
difícil en la especificación de un sistema es a
menudo determinar qué es parte del sistema y qué
no.
Así, el primer modelo importante que se debe
desarrollar como analista es uno que no haga más que
definir las interfaces entre el sistema y el resto del universo,
es decir, el ambiente. Por razones obvias, este modelo se conoce
como el modelo ambiental. Por lo tanto, se necesita saber
qué información entra al sistema desde el ambiente
exterior, y qué información produce como salida al
ambiente externo.
Otro aspecto crítico del modelo ambiental
consiste en identificar los acontecimientos que ocurren en el
ambiente al cual debe responder el sistema. No para todos los
acontecimientos, ya que el ambiente en su totalidad genera un
número infinito de acontecimientos. Sólo importan
aquellos que ocurren en el ambiente exterior y los que requieren
una respuesta del sistema.
En un sistema grande se puede tomar en cuenta una
cantidad de factores cuando se están escogiendo las
perspectivas del proyecto. Entre los más importantes
están los siguientes:
El deseo del usuario de lograr cierta
participación en el mercado para el producto, o
incrementarla a más de su nivel actual. Esto se puede
hacer ofreciendo un nuevo producto o una mayor funcionalidad
de uno existente.La legislación establecida por el gobierno
federal, estatal, o de la ciudad. Por ejemplo tendría
que hacerse un nuevo sistema para considerar los cambios en
las leyes sobre impuestos.Deseo del usuario por minimizar gastos operativos de
alguna área de su negocio. La mayor parte de las
organizaciones que han tenido computadoras instaladas durante
10 años o más ya aprovecharon las oportunidades
obvias de reducir el personal de oficina.Deseo del usuario para lograr alguna ventaja
estratégica para la línea de productos o
áreas de negocios que opera. Un buen ejemplo de estos
son las líneas aéreas donde mejor
información acerca de tendencias del mercado y
preferencias de los clientes pueden llevar a costos de
pasajes e itinerarios de aerolíneas más
eficientes.
2.- Modelo de
comportamiento
Dentro del modelo de comportamiento se
involucrará el desarrollo de un diagrama de flujo de
datos.
Para explicar este modelo se utilizará el enfoque
de partición por acontecimiento, el cual incluye los
siguientes cuatro pasos:
1. Se dibuja una burbuja, o proceso, para cada
acontecimiento de la lista.2. La burbuja se nombra describiendo la
respuesta que el sistema debe dar al acontecimiento
asociado.3. Se dibujan las entradas y salidas apropiadas
de tal forma que la burbuja pueda dar la respuesta requerida,
y se dibujan los almacenes, como sea apropiado, para la
comunicación entre burbujas.4. El borrador de DFD que resulta se compara
con el diagrama de contexto y la lista de acontecimientos
para asegurar que está completo y sea
consistente.
El primer paso es directo y mecánico: si existen
25 acontecimientos en la lista, se deben dibujar 25
burbujas.
El segundo paso también es directo y
mecánico: a cada burbuja se le da un nombre apropiado,
basado en la respuesta requerida. Esto significa que se debe
examinar el acontecimiento y preguntar qué respuesta debe
dar el sistema a este Acontecimiento.
El tercer paso definitivamente no es mecánico,
pero usualmente es bastante directo: Para cada burbuja dibujada,
identifique las entradas que requiere para efectuar su trabajo.
Identifique las salidas que cada una produce e identifique los
almacenes a los que cada burbuja debe tener acceso. Esto
normalmente se hace entrevistando al usuario o usuarios
apropiados y concentrándose en cada acontecimiento y su
burbuja asociada. Las preguntas son: ¿Qué necesita
esta burbuja para hacer su trabajo? y ¿Qué salidas
genera?
En muchos casos el acontecimiento está
determinado por el flujo; esto significa que el sistema detecta
la ocurrencia de un acontecimiento por la llegada de algún
dato de un terminador externo, lo que quiere decir que se pueden
requerir entradas adicionales (de otros terminadores, y de
almacenes de datos) para que un proceso produzca su salida
requerida.
De manera similar, como parte de la respuesta dibuje las
salidas adecuadas producidas por el proceso. En muchos casos,
esto implicar devolver salidas a los terminadores fuera del
sistema; sin embargo, puede también involucrar salidas que
se envían a los almacenes de datos, para ser usadas como
entradas de otros procesos.
Los dos casos anteriores se ilustran en la
figura siguiente:
Figura 3: que muestra entradas y salidas
de un proceso
El cuarto paso es una actividad de verificación
de consistencia: Verifique cada entrada del diagrama de contexto
para ver si está conectada con alguna entrada de
alguno de los procesos del DFD preliminar, y verifique
también que cada salida producida por algún proceso
en el DFD preliminar se envíe a un almacén o sea
una salida externa incluida en el diagrama de
contexto.
Existen dos casos especiales, el primero de ellos son
los acontecimientos únicos que causan respuestas
múltiples y, el segundo caso comprende los acontecimientos
múltiples que causan la misma respuesta.
En el primer caso, un solo acontecimiento puede causar
múltiples respuestas, cada una de las cuales se modela con
su propia burbuja en el DFD preliminar. Sólo es apropiado
si todas las respuestas usan el mismo flujo de datos de entrada,
y sólo si todas las respuestas son independientes entre
sí.
De manera inversa, habrá situaciones
ocasionales en las que un proceso se asocia con más de un
acontecimiento. Es válido y apropiado sólo si la
respuesta de la burbuja es idéntica para los diversos
acontecimientos, y sólo si los datos de entrada y salida
son idénticos para las diversas respuestas a
acontecimientos.
Obsérvese que en los ejemplos anteriores ninguno
de los procesos en el diagrama de flujo de datos preliminar
está conectado con otro; las burbujas no se comunican
directamente con otras. En vez de eso se comunican entre
sí a través de otros almacenes de
datos.
Una vez hecho esto se procede a un proceso de limpieza,
el cual se describirá posteriormente, para producir un
modelo bien organizado del proceso y un modelo de datos para
presentarlo al usuario final. Este enfoque se llamó
partición por acontecimientos.
Diseño de
sistemas
Antes de entrar en materia es importante hacer
énfasis en cierto aspecto fundamental del Diseño de
Sistemas y es que la labor del analista y la del diseñador
no siempre se pueden separar debido a que, el analista debe
asegurarse de entender los requerimientos del usuario, mientras
que el diseñador debe asegurar que dichos requerimientos
se puedan implantar de manera realista con la tecnología
computacional actual.
Existe otra razón para tener interés en el
diseño de sistemas, sobre todo en los sistemas
pequeños y medianos, a menudo se espera que el mismo
individuo documente los requerimientos del usuario y
además desarrolle el diseño.
La actividad de diseño involucra el desarrollo de
una serie de modelos. Los modelos más importantes para el
diseñador son el modelo de implementación de
sistemas y el modelo de implementación de programas. El
modelo de implantación de sistemas se divide luego en un
modelo de procesador, y uno de tareas.
En el nivel del modelo del procesador, el
diseñador del sistema trata principalmente de decidir como
asignar el modelo esencial a los distintos procesadores (CPU) y
como deben comunicarse entre sí. Existe típicamente
una variedad de opciones:
El modelo esencial completo se le puede asignar a un
solo procesador (solución de computadora
principal).Cada burbuja de la figura 0 del DFD del modelo
esencial se puede asignar a un procesador distinto
(solución distribuida).Se pude escoger una combinación de
computadoras principales, minis y micros para minimizar
costos, maximizar confiabilidad o lograr algún otro
objetivo.
Así como se deben asignar procesos a los
componentes apropiados de hardware, los almacenes de datos se
deben igualmente asignar. El diseñador debe de decidir si
un almacén se realizará como base de datos en
el procesador 1 o el 2. Dado que la mayor parte de los almacenes
se comparten entre muchos procesos, también debe decidir
si se deben asignar copias del almacén a diferentes
procesadores.
En el nivel del modelo de tarea, el diseñador
debe, procesador por procesador, asignar procesos y almacenes a
las tareas individuales de cada uno. Los procesos dentro de un
mismo procesador pueden tener necesidad de comunicarse mediante
alguna forma de protocolo de comunicación entre tareas. El
mecanismo para hacerlo varía de un proveedor a otro, pero
casi siempre se realiza a través del sistema operativo del
proveedor.
En el modelo de implementación de programas se
llega al nivel de una tarea individual. Dentro de una tarea
individual, la computadora opera de una manera no sincronizada:
sólo se pueden llevar a cabo una actividad a la vez. El
modelo más común de organización de la
actividad en una sola unidad sincronizada es el diagrama de
estructura, que muestra la organización jerárquica
de módulos dentro de una tarea.
DIAGRAMAS DE FLUJO DE DATOS (DFD).
El diagrama de flujo de datos (DFD), es una herramienta
que permite visualizar un sistema como una red de procesos
funcionales, conectados entre sí por "conductos" y
"tanques de almacenamiento" de datos. Siendo éste, una de
las herramientas más comúnmente usadas, sobre todo
por sistemas operacionales en los cuales las funciones del
sistema son de gran importancia y son más complejos que
los datos que éste maneja.
Es importante tener en mente: que los DFD no sólo
se pueden utilizar para modelar sistemas de sistemas de proceso
de información, sino también como manera de modelar
organizaciones enteras, es decir, como una herramienta para la
planeación estratégica y de negocios.
Los componentes de un diagrama típico de flujo de
datos:
Proceso.
Flujo.
Almacén.
Terminador.
Proceso.
El primer componente del DFD se conoce como proceso. Los
sinónimos comunes son burbuja, función,
transformación. El proceso muestra una parte del sistema
que transforma entradas en salidas. El proceso se representa
gráficamente como un círculo, como se muestra en
figura 4.1.1(a). Algunos analistas prefieren usar un óvalo
o un rectángulo con esquinas redondeadas, como se muestra
en la figura 4.1.1 (b). Y otros prefieren usar un
rectángulo, como se muestra en la figura 4.1.1 (c). Las
diferencias entre estas tres formas son puramente
cosméticas, aunque obviamente es importante usar la misma
forma de manera consistente para representar todas las funciones
de un sistema.
Figuras 4.1.1 ( a) (b) (c)
En el proceso se nombra o describe con una sola palabra,
frase u oración sencilla. Un buen nombre para un proceso
generalmente consiste en una frase verbo-objeto tal como validar
entradas o calcular impuesto. En algunos casos, el proceso
contendrá el nombre de una persona o un grupo (por
ejemplo, un departamento o una división de una
organización), o de una computadora o un aparato
mecánico.
Flujo.
Un flujo se representa gráficamente por medio de
una flecha que entra o sale de un proceso; un ejemplo se muestra
en la figura 4.1.2. El flujo se usa para describir el movimiento
de bloques o paquetes de información de una parte del
sistema a otra.
Figura 4.1.2: Ejemplo de un
flujo.
En la mayoría de los sistemas que modele como
analista, los flujos realmente representan datos, es decir, bits,
caracteres, mensajes, números de punto flotante y los
diversos tipos de información con los que las computadoras
pueden tratar.
El flujo de la figura 4.1.2 tiene nombre. El nombre
representa el significado del paquete que se mueve a lo largo del
flujo. Un corolario de esto es que el flujo sólo lleva un
tipo de paquete, como lo indica su nombre.
Los flujos muestran también la dirección:
una cabeza de flecha en cualquier extremo (o posiblemente ambos)
del flujo indica si los datos (o el material) se está
moviendo hacia adentro o hacia fuera de un proceso (o ambas
cosas).
El flujo que se muestra en la figura 4.1.3 (a) por
ejemplo, indica claramente que el número se está
mandando hacia el proceso denominado Validar números
telefónicos, y el flujo denominado honorarios de entrega
de choferes de la figura 4.1.3 (b) claramente indica que es una
salida generada por el proceso Generar honorarios de entrega de
choferes. Los datos que se mueven a lo largo de dicho flujo
viajarán ya sea a otro proceso (como entrada) o a un
almacén o a un terminador.
El flujo de dos cabezas que se muestra en la figura
4.1.3 (c) es un diálogo, es decir, un empacado conveniente
de dos paquetes de datos (una pregunta y una respuesta) el mismo
flujo. En el caso de un diálogo, los paquetes de cada
extremo de la flecha deben nombrarse, como se ilustra en la
figura 4.1.3 (c).
Figuras 4.1.3: (a):Flujo de
entrada.
Figura 4.1.3 (b): Flujo de
salida.
Figura 4.1.3(c): Flujo de
diálogo.
Almacén.
El almacén se utiliza para modelar una
colección de paquetes de datos en reposo. Se denota por
dos líneas paralelas. De modo característico el
nombre que se utiliza para identificar al almacén es el
plural del que se utiliza para los paquetes que entran y salen
del almacén por medio de flujos.
Para el analista con conocimiento de proceso de datos es
tentador referirse a los almacenes como archivos o base de datos;
pero un almacén también pudiera consistir en datos
almacenados en tarjetas perforadas, microfilm, microfichas,
discos ópticos, etc. y un almacén también
puede ser un conjunto de fichas de papel en una caja de
cartón, nombres y domicilios en un directorio, diversos
archivos en un archivero, o varias formas no
computarizadas.
Aparte de la forma física que toma el
almacén, también existe la cuestión de su
propósito: ¿Existe el sistema por causa de un
requerimiento fundamental del usuario o por algún aspecto
conveniente de la realización del sistema? En el primer
caso, la base de datos existe como un área de
almacenamiento diferida en el tiempo, necesaria entre dos
procesos que ocurren en momentos diferentes.
Los almacenes se conectan por flujos a los procesos.
Así, el contexto en el que se muestra en un DFD es uno de
los siguientes (o ambos):
Un flujo desde un almacén.
Un flujo hacía un almacén.
Terminador
El terminador gráficamente se representa como un
rectángulo. Los terminadores representan entidades
externas con las cuales el sistema se comunica.
Comúnmente, puede ser una persona, o un grupo, por
ejemplo, una organización externa o una agencia
gubernamental, o un grupo o departamento que esté dentro
de la misma compañía u organización, pero
fuera del control del sistema que se está modelando. En
algunos casos, un terminador puede ser otro sistema, como
algún otro sistema computacional con el cual se comunica
éste.
Existen tres cosas importantes que debemos recordar
acerca de los terminadores:
Son externos al sistema que se está
modelando.Es evidente que ni el analista ni el
diseñador del sistema están en posibilidades de
cambiar los contenidos de un terminador o la manera en que
trabaja.Las relaciones que existan entre los terminadores no
se muestran en el modelo de DFD.
Caso Práctico (Ejercicio). Usando el
DFD
Una forma de comprender estas ideas sobre el
análisis de sistemas es explicando en forma detallada un
caso práctico de un sistema real. Nuestro caso de estudio
describe los requerimientos de computarización de las
actividades de proceso de información de YOURDON
Press.
Se abarcaran las siguientes secciones:
El modelo ambiental del sistema.
El modelo de comportamiento.
El modelo de implantación del
usuario.
El Modelo Ambiental.
La declaración de
propósitos.
El propósito del Sistema de Información de
YOURDON Press (YPIS) es almacenar la información necesaria
para vender libros a los clientes. Esto incluye ingreso de
pedidos, facturación, generación de documentos de
envío, control de inventarios y producción de
reportes de regalías por derechos de autor y reportes de
contabilidad.
La lista de acontecimientos.
La lista de acontecimientos del sistema YPIS consiste en
40 acontecimientos. La mayoría están dirigidos por
flujos, aunque la mayoría de los que involucran al
departamento de contabilidad son temporales. Los acontecimientos
se listan a continuación; los temporales se marcan con una
"T" luego de su descripción.
El cliente envía su pago.
El cliente pide información sobre
algún libro (precio, etc.).El cliente pide permiso de devolver un
libroEl cliente pregunta sobre el status de algún
pedido.El cliente pregunta sobre el status de alguna
factura.El cliente requiere de una declaración
(mensual). (T)El cliente pide un recordatorio de un
crédito.El cliente desea un cheque de reembolso.
El departamento de contabilidad requiere de recibos
(diarios) de efectivo. (T)El departamento de contabilidad requiere de reportes
de ventas (diarios). (T)El departamento de contabilidad requiere de un
reporte (mensual) de ventas netas.(T)El departamento de contabilidad requiere de un
reporte (trimestral) de regalías por derechos de
autor. (T)El departamento de contabilidad requiere de datos
(mensual) de inventario. (T)El departamento de contabilidad requiere de un
reporte (mensual) de comisiones sobre ventas. (T)La gerencia fija un nuevo límite de
crédito para un cliente.El departamento de contabilidad requiere un reporte
(mensual) de cuentas por pagar retrasadas.La imprenta da una cotización de pedido de
impresiónLa administración autoriza un pedido de
impresión.La imprenta notifica la cantidad exacta de impresos
y fechas de entrega.La imprenta envía factura por concepto de
trabajo de impresión.La administración solicita cotización
de un pedido de impresión.El departamento de mercadeo pide etiquetas de
envío de la base de datos de clientes.El departamento de mercadeo requiere de
estadísticas sobre las ventas de libros.El departamento de mercadeo necesita una fecha de
disponibilidad de nuevos títulos.Los editores anuncian un nuevo
título.Los autores necesitan un reporte trimestral de
utilidades por concepto de derechos de autor. (T)La bodega necesita datos de envío y
etiquetas. (T)La bodega recibe libros de la imprenta.
La bodega recibe devoluciones de libros de un
cliente.La bodega hace un inventario físico
(mensual).La bodega envía un pedido a un
cliente.La bodega anuncia que un libro se ha
agotado.El departamento de adquisiciones anuncia el proyecto
de un nuevo libro.Un vendedor ingresa un pedido de parte de un
cliente.El departamento de mercadeo declara que un libro
está agotado.El cliente notifica un cambio de
domicilio.El autor notifica un cambio de domicilio.
El cliente elige participar en el plan de
agencia.Se necesita enviar facturas a un cliente.
(T)
Modelo de Comportamiento.
El modelo preliminar de comportamiento: diagramas de
flujo de datos.
Cada uno de los 40 acontecimientos listados en la
sección del modelo ambiental tiene un diagrama de flujo de
datos asociado.
Al dibujar los DFD preliminares se tomó nota de
los errores que se encontraron y los cambios que se tenían
que hacer en otras partes del modelo; estas notas se listan
debajo de cada DFD. La razón de esto es enfatizar que en
un proyecto real el analista raramente dibuja un DFD perfecto al
primer intento; después de pensar sobre el sistema, y
luego de entrevistas de seguimiento con el usuario, es inevitable
que se encuentren errores en el DFD que se está examinando
o en alguna otra parte del modelo del sistema.
DIAGRAMAS DE LOS
ACONTECIMIENTOS:
Acontecimiento 1.
Acontecimiento 2:
Acontecimiento 3:
Acontecimiento 4:
Acontecimiento 5:
Acontecimiento 6:
Acontecimiento 7:
Acontecimiento 8:
Acontecimiento 9:
Acontecimiento 10:
Acontecimiento 11:
Acontecimiento 12:
Acontecimiento 13:
Acontecimiento 14:
Acontecimiento 15:
Acontecimiento 16:
Acontecimiento 17:
Acontecimiento 18:
Acontecimiento 19:
Acontecimiento 20:
Acontecimiento 21:
Acontecimiento 22:
Acontecimiento 23:
Acontecimiento 24:
Acontecimiento 25:
Acontecimiento 26:
Acontecimiento 27:
Acontecimiento 28:
Acontecimiento 29:
Acontecimiento 30:
Acontecimiento 31:
Acontecimiento 32:
Acontecimiento 33:
Acontecimiento 34:
Acontecimiento 35:
Acontecimiento 36:
Acontecimiento 37:
Acontecimiento 38:
Acontecimiento 39:
Acontecimiento 40
Modelo final del comportamiento: diagramas de flujo
de datos (DFD).
El modelo inicial del comportamiento mostrado en las
últimas páginas se transformó en un conjunto
de DFD por niveles. La nivelación ascendente produjo el
diagrama de figura 1 que se muestra a continuación. Las
figuras subsecuentes muestran los acontecimientos que se
agruparon. En un caso, un solo acontecimiento (el 26) no se
niveló de manera ascendente, y aparece como el proceso 5
de la figura 1. Y en un caso (el acontecimiento 1) se
ocupó una nivelación descendente adicional debido a
la complejidad del proceso.
Conclusiones
Una vez finalizado el presente trabajo de
investigación es posible concluir lo siguiente:
1. Los sistemas de información son
herramientas necesarias que permiten a las empresas obtener
ventajas competitivas mediante su implantación y uso
apoyando el máximo nivel de la
organización.2. Los sistemas de información
organizacionales, son indispensables para automatizar los
procesos operativos y para alcanzar la evolución hacia
fuentes importantes de información que sirven de base
para la toma de decisiones.3. La comprensión básica de los
sistemas de información facilita la captación o
entendimiento en cualquier otra área funcional de la
empresa.4. La cultura informática es de vital
importancia en las organizaciones, ya que sin ella seria
imposible construir un escenario que permita y de las
condiciones necesarias para que los sistemas de
información logren los objetivos citados
anteriormente.5. Ignorar la información o resistirse
al cambio de la misma representa un riesgo muy grande de
fracaso para una organización debido a las amenazas
del mercado y a la incapacidad de competir.
Bibliografía
Para realizar el presente trabajo de
investigación, se recolectó información de
las siguientes páginas electrónicas:
www.monografias.com
www.elprisma.com
http://sistemas.itlp.edu.mx/tutoriales/analisis/index.htm
Autor:
Balza, Leman
Gallardo, José
Gómez, Olga P.
Hernández,
Ritcelys
Marín, Ronny
Medina, Audreis
Enviado por:
Profesor:
MSc. Ing. Iván
Turmero
UNIVERSIDAD NACIONAL EXPERIMENTAL
POLITÉCNICA
"ANTONIO JOSÉ DE SUCRE"
VICE-RECTORADO PUERTO ORDAZ
DEPARTAMENTO DE INGENIERÍA
INDUSTRIAL
CÁTEDRA: SISTEMAS DE
INFORMACIÓN
Ciudad Guayana, Abril de 2007