Ing.

Inés Casanovas

Análisis de Sistemas
Guía de Estudio III
Análisis estructurado de sistemas

Ing. Inés Casanovas

Página 1 de 19
 Ing. Inés Casanovas

Técnicas y herramientas del análisis estructurado

Una técnica es un conjunto de procedimientos y recursos de los que se sirve una

determinada ciencia o un arte. En el caso de las técnicas de sistemas, hacemos referencia
al conjunto de procedimientos que prestan servicio al estudio y desarrollo de los sistemas
de información.

Los métodos que prestan servicio a las técnicas de sistemas, son modos de realizar
ordenadamente el conjunto de pasos que deben seguirse para obtener o alcanzar los
objetivos de cada una de aquéllas.

Por su parte, una herramienta es un recurso instrumental que, generalmente, presta ayuda
a la disciplina; como ejemplo, para la disciplina computación las herramientas son las
computadoras y/o software; para la disciplina de los sistemas de información, lo son las
metodologías y/o ciclos de vida; para la disciplina de los sistemas de información por
computadora, los productos CASE, etc.

Por lo dicho, entonces cuando nos refiramos a las técnicas, pensemos en procedimientos.
Cuando hablemos de herramientas, pensemos en los instrumentos para llevar adelante las
técnicas.

Un modelo es una representación de la realidad que nos permite:

ƒ Identificar y dar importancia a las propiedades importantes del sistema evitando que
lo no relevante nos distraiga.

ƒ Comunicarnos con los usuarios y otros miembros del equipo de desarrollo para
llegar a una visión lo mas unificada posible del sistema, sus objetivos y
funcionalidades.

La metodología estructurada creó la técnica de Diagrama de Flujo de Datos (DFD) para

modelizar procesos generando un modelo lógico que describe lo que hace el sistema
independientemente del diseño físico o tecnología que se usará y un modelo de datos
preliminar mediante el Diccionario de Datos (DD). El énfasis está puesto en el
procesamiento o la transformación de datos y su almacenamiento.

Su creador fue Edward Yourdon, en la decada del 80,

La metodología estructurada no cuenta con una normativa estandarizada, y es por ello que
encontraremos numerosos autores que proponen diferente sintaxis, pero la base
conceptual es similar a la planteada por Yourdon.

Página 2 de 19
 Ing. Inés Casanovas

Se utilizan solo cuatro símbolos:

SIMBOLOGIA GANE Y SIMBOLOGIA YOURDON/DEMARCO

SARSON/KENDALL…

PROCESO

FLUJO DE DATOS

ALMACENAMIENTO

ENTIDAD EXTERNA

Página 3 de 19
 Ing. Inés Casanovas

Un proceso es una actividad realizada como consecuencia de una o varias entradas de

datos y que produce uno o varios flujos de salida. Lo que debe quedar bien en claro que
deben entrar los datos suficientes para haber generado una determinada salida. Un
proceso se identifica numéricamente, pero esto no indica secuencia de ejecución. Lleva
además un texto que muestra su actividad bajo la forma de un verbo en infinitivo (Emitir
factura).

El movimiento de los datos es efectuado exclusivamente por los flujos, que pueden
transportar datos a/desde otro proceso, a/desde un almacenamiento, a/desde una entidad
externa mediante cualquier medio. Se los identifica con un nombre que represente el
conjunto de datos que transporte. No están permitidos nombres que asocien soportes
físicos (original, duplicado etc.) y en lo posible deben mostrar claramente los datos,
evitando nombres crípticos (AJ45) o generalizaciones (“datos”, “información”, “info” etc.)

Las entidades externas son aquellos agentes que no forman parte del sistema en estudio
excepto que le proveen datos o son receptores de ellos; se desconoce su comportamiento.
Se las identifica con una letra y el nombre representativo de la entidad (Cliente, Banco, etc.)

Un almacenamiento es un depósito de datos, computarizados o no. Se los identifica por un

número y un nombre que represente su contenido (Facturas, Proveedores etc.)

En un DFD los procesos pueden ejecutarse en forma simultánea, no hay secuenciamiento

como en las metodologías clásicas, ni tampoco bucles o ciclos iterativos

Los flujos transportan a veces gran cantidad de datos, cuya explicitación haría muy
engorrosa la lectura e interpretación del DFD, por eso llevan un rótulo que represente
claramente los datos que entran o salen (por ej.: Datos Personales, que estará integrado
por Nombre, Apellido, Dirección, TE y Nº de CUIT/CUIL) .

El detalle de composición de todos los flujos del diagrama así como los datos guardados en
cada almacenamiento estará en el Diccionario de Datos, herramienta imprescindible para el
diseño, codificación y mantenimiento del sistema. De esta manera, cuando se piense en
modificar el formato de un dato, se puede encontrar rápidamente en qué procesos es usado
y cual sería el impacto del cambio.

Página 4 de 19
 Ing. Inés Casanovas

4 Proceso Pago Flujo de Datos

Emitir
recibo

Al fin del día Flujo de Control o temporal

Al alcanzar el
punto de pedido

Almacenamiento de Datos
2 PROVEEDORES

El modelo de Yourdon se compone de un modelo esencial y un modelo de implementación,

basados en un enfoque descendente (top-down) en sintonía con el pensamiento sistémico.

El primero de los modelos se construye durante la etapa de análisis, mientras que el

segundo, que atiende más los aspectos físicos, se desarrolla en la etapa de diseño.

El modelo esencial
El modelo esencial se compone de dos niveles que buscan especificar el “que” debe hacer
el sistema y no el “como” (de lo que se ocupará el modelo de implantación): el modelo de
ambiente, y el modelo de comportamiento del sistema en estudio.

Modelo de ambiente

A su vez, el modelo de ambiente utiliza un diagrama de contexto y una lista de eventos,

mientras que el modelo de comportamiento despliega el modelo funcional mediante niveles
de detalle top-down o descendente (de lo general a lo particular).

El proceso de modelización arranca a partir de la identificación de requerimientos o

requisitos demandados por el usuario, respecto al sistema a implementar. Se clasifican en:

ƒ requerimientos funcionales: características requeridas para que el sistema cumpla la

operatoria definida por el cliente/usuario

Página 5 de 19
 Ing. Inés Casanovas

ƒ requerimientos no funcionales: características del sistema que señalan restricciones,

diseño estético, desempeño, seguridad etc.

Los requerimientos se transformarán en los objetivos del sistema que necesariamente

deben ser claros, medibles, alcanzables, compartidos y consensuados, alineados con la
estrategia del negocio en particular y de la organización en un todo global.

Ellos definirán en forma mas o menos preliminar la lista de eventos del sistema que son los
acontecimientos que el sistema debe reconocer como estímulos y a los cuales debe
responder con una acción.

Estos eventos se relacionan con flujos desde o hacia entidades externas, por ejemplo.: un
cliente realiza un pedido, pero también pueden ser temporales (su ejecución es
consecuencia de un momento determinado en el tiempo), por ejemplo, al fin del día se
genera un reporte de ventas realizadas, o de control (su ejecución es consecuencia de una
situación contemplada por el sistema) por ejemplo, al llegar al valor de stock mínimo de un
producto se dispara una solicitud de abastecimiento.

Una vez definidos los requerimientos, se construye la lista de eventos, identificando su tipo
y los estímulos y respuestas.

Es una lista narrativa de los estímulos que ocurren en el mundo exterior a lo cuales el
sistema debe responder. Hay tres tipos de acontecimientos o de eventos:

ƒ Acontecimientos Orientados a Flujos: se asocia a un flujo de datos. Son aquellos en los

que el sistema se da cuenta de que ha ocurrido algo y contesta a ese evento.

ƒ Acontecimientos Temporales: estos eventos arrancan con la llegada de un momento

dado en el tiempo. No se inician con flujos de datos de entrada; se puede imaginar que el
sistema tiene un reloj interno con el cual puede determinar el paso del tiempo.

ƒ Acontecimientos Orientados a Control: deben considerarse como un caso especial de

los acontecimientos temporales. A diferencia del un acontecimiento temporal normal, no se
asocia con el paso regular del tiempo, por lo que el sistema no puede anticiparlo utilizando
un reloj interno. Y, a diferencia de un acontecimiento de flujo normal, el de control no indica
su presencia con la llegada de datos. Se asocia con un flujo de control (o flujo binario). Son
bastantes comunes en sistemas de tiempo real.

Para su construcción se debe tener una idea clara de:

Página 6 de 19
 Ing. Inés Casanovas

ƒ Las entradas y salidas de información y su procedencia, eliminando toda referencia al

entorno físico.

ƒ Las funciones ejecutadas por el sistema, eliminando toda referencia a personas

individuales.

El modelo obtenido es una descripción lógica o conceptual del sistema, sin distinguir entre
funciones que se realizarán de forma manual o automatizada.

En la mayor parte de los casos, la mejor manera de identificar los acontecimientos para un
sistema es visualizarlo en acción: examinar cada agente externo y preguntar qué
interacción tiene con el sistema.

EJEMPLO

EVENTO ENTIDAD FUNCION/ ENTRADA/ TIPO SALIDA/

DE
PROCESO ESTIMULO RESPUEST
EVEN
A
TO

El cliente Cliente Actualizar Pago E Recibo

realiza un estado de la
pago cuenta

El cliente Cliente Ingresar Pedido E Nota de

realiza un pedidos Pedido
pedido

Al fin del Generar T Reporte

día se listado de de ventas
emite un ventas del por
listado de día producto
ventas
realizadas
ordenado
por
producto

EVENTO: Se indica el evento que desencadena la acción del sistema.

Página 7 de 19
 Ing. Inés Casanovas

PROCESO/FUNCION: Se indica el proceso del sistema que se ocupa de ese evento.

ENTRADA/ESTIMULIO: Se indica los datos que llegan al proceso.

SALIDA/RESPUESTA: Se indica los datos que salen del proceso como resultado de su
ejecución-respuesta al evento.

TIPO: Si es de tipo Externo (E) o de tipo temporal (T)

El diagrama de contexto provee una visión general del sistema respecto a su interacción
con el ambiente donde funcionará, modelizando sus límites, los estímulos que recibe y lo
que vuelca a ese ambiente en respuesta a ese evento (datos entrantes e información
saliente del sistema):

ƒ Aquellos agentes externos que se comunican con el sistema, que a veces se conocen
como terminadores.

ƒ Los datos que el sistema recibe del exterior y que se deben procesar de alguna forma.

ƒ Los datos producidos por el sistema y que se mandan al mundo exterior.

ƒ La frontera entre el sistema y el resto del mundo.

El cabal entendimiento del problema a solucionar es definitorio en la buena definición de los

límites del sistema, o sea que comprenderá y que se dejará afuera.

En este diagrama solo se grafica una única burbuja representativa del sistema como caja
negra, las entidades externas, y los flujos de datos que el sistema recibe de las entidades
externas y los que él les envía. Esa burbuja se identifica con el nombre del sistema, ya que
todavía se desconocen los procesos que lleva a cabo.

Una vez se ha obtenido la lista de eventos y el Diagrama de Contexto, deben revisarse para
comprobar que son consistentes, es decir, se debe confirmar:

ƒ El sistema necesita cada flujo de entrada del Diagrama de Contexto para reconocer que
ha ocurrido un acontecimiento; debe necesitarlo para producir una respuesta a un
acontecimiento, o ambas cosas.

ƒ Cada flujo de salida debe ser respuesta a un acontecimiento.

Página 8 de 19
 Ing. Inés Casanovas

ƒ Cada acontecimiento no temporal de la lista de acontecimientos debe tener entradas a

partir de las cuales el sistema pueda detectarlo.

ƒ Cada acontecimiento debe producir salidas inmediatas como respuesta o bien

almacenar los datos que luego serán salidas.

Modelo de comportamiento

Requiere para su modelización la construcción del DFD (Diagrama de Flujo de Datos) a

partir de un nivel 1 (integrador del sistema) hasta los niveles de desglose necesarios de
acuerdo a la complejidad de cada proceso a analizar y las Especificaciones de Proceso
(pseudo código, tablas de decisión) que brindarán el modelo de procesos por un lado, y
el DD (Diccionario de Datos) y el DER (diagrama Entidad-Relación) preliminar, que
conforman el modelo de datos.

Modelo de procesos

Deben identificarse los grandes procesos funcionales (módulos) del sistema, que
conformarán el nivel 1, y luego desglosarlos en subprocesos. Se determinan los
almacenamientos necesarios de datos y los flujos de entrada y salida de esos procesos
desde o hacia entidades externas, y desde o hacia almacenamientos. No está permitida la
conexión de procesos en este nivel, ya que esto implicaría acoplamiento y dependencia
entre ellos. Todo el esquema de DFD´s adopta una estructura jerárquica por niveles, desde
lo más general a lo más detallado.

Nivel 0

b
mm

qq a
Sistema X

nn

pp

Página 9 de 19
 Ing. Inés Casanovas

Nivel 1

b
mm a

1
aaar
qq
Almacenamiento 1

pp Almacenamiento2
3
iiir

2
eeer

nn

Nivel 2 del proceso 1: aaar

Página 10 de 19
 Ing. Inés Casanovas

b
mm

1.1
mmmr
Almacenamiento 1

c pp

1.2
nnnr

Para su construcción deben tenerse en cuenta algunas reglas de trazado y conexión.

ƒ Todo proceso debe tener entrada y salida de datos. Una entrada de datos igual a la
salida carece de sentido (el proceso no realiza ninguna transformación)

ƒ No puede haber conexiones entre entidades externas, ya que ese intercambio de

datos no involucra al sistema.

ƒ No puede haber conexiones entre almacenamientos ya que conceptualmente son

datos estáticos y cualquier operación de transferencia, lectura o escritura requiere
de un proceso.

ƒ No puede haber conexiones entre entidades externas y almacenamientos del

sistema, ya que esto implicaría un acceso al repositorio de datos del sistema y la
consecuente cuestión de seguridad y confidencialidad. Es necesario un proceso
intermedio que valide el permiso de acceso y los datos transferidos.

ƒ Los datos de entrada a un proceso deben ser los necesarios y suficientes para
ejecutar el proceso de transformación.

Página 11 de 19
 Ing. Inés Casanovas

ƒ Los datos de entrada a un almacenamiento (escritura) deben estar definidos como

atributos del mismo en el Diccionario de Datos.

ƒ No existen reglas acerca del número de niveles que debe obtenerse. Dependerá de
la complejidad del sistema.

ƒ Algunas partes del sistema pueden ser más complejas que otras y pueden requerir
diferentes niveles de descomposición.

ƒ Para asegurarse que un DFD es consistente con su DFD de nivel superior, los flujos
de datos que entran y salen de una burbuja en un nivel dado, deben corresponder
con los que entran y salen del nivel inmediato inferior que lo describe.

ƒ Todos los almacenamientos se debe mostrar en el nivel 1 donde primeramente sirva

de interfaz entre dos o más procesos; luego, aparecen de nuevo en cada diagrama
de nivel inferior donde sean utilizados y describan más a fondo dichos procesos.

Se debe refinar los DFD constantemente. El diseño de un DFD es un proceso iterativo, por
lo que habrá que hacer revisiones y modificaciones periódicas hasta obtener la versión
definitiva. Es importante dedicar tiempo a esta labor ya que los posibles errores
introducidos en un DFD será errores de análisis que se arrastrarán a lo largo de las
siguientes fases del ciclo de vida del sistema.

Modelo de datos

La modelización de los datos procesados por un Sistema de información se realiza en

diferentes niveles consecutivos de abstracción:

ƒ Nivel Conceptual: a este nivel se realiza una formalización de los datos almacenados
en el sistema (los de los almacenes del DFD) mediante una descripción de las entidades
(objetos materiales o inmateriales del sistema), los atributos (propiedades) de estas
entidades y las posibles relaciones entre ellas. Este modelo se realiza durante la fase de
análisis del sistema mediante el Diccionario de Datos (DD)

Página 12 de 19
 Ing. Inés Casanovas

ƒ Nivel Lógico: A continuación se genera un modelo lógico de registros (Diagrama

Entidad-Relación) que representa la estructura de los datos (a nivel de registros lógicos)
en dicho sistema. Este modelo se realiza durante la ultima fase de analisis y se refina en la
fase de diseño del sistema completandolo con información adicional sobre el volumen de
los datos y la forma de acceso a los mismos.

ƒ Nivel Físico: a este nivel se debe determinar cómo se organiza físicamente el

almacenamiento de los datos en archivos o tablas dependiendo de la Base de Datos que
se utilice. Implica procesos de normalización de sus tablas.

El Diccionario de datos documenta en detalle los datos elementales que fluyen en un DFD
a través de los flujos de datos y los almacenamientos. Todos los flujos de datos, estructura
de datos, datos elementales y almacenamientos, por separado, estarán ordenados
alfabéticamente (de ahí el nombre). Es importante para validar la integridad del los DFD´s
siendo crucial a la hora de modificaciones o mantenimiento del sistema ya que ofrecen una
referencia cruzada de donde se utilizan sus componentes, evitando los efectos imprevistos
de cambios. Para cada uno de ellos se identificarán:

Almacenamientos: nombre identificador, datos o estructura de datos que lo componen,

procesos que acceden al mismo, ya sea para lectura o escritura.

Flujos de datos: nombre identificador, datos o estructura de datos que lo componen.

Origen/es y destino/s del flujo (de qué proceso a qué proceso, o desde/hacia qué entidad o
desde/hacia qué almacenamiento se mueve ese conjunto de datos)

Estructura de datos: nombre identificador, datos que la componen y detalles estructurales

utilizando la siguiente simbología:

– = contiene

– + y

– ( / ) alternativa

– [] opcional

– {} repetición

Ejemplo: Empleado = legajo + (DNI/CI) + nombre + domicilio + fecha de ingreso + [e-mail]

+ {nro teléfono}

Página 13 de 19
 Ing. Inés Casanovas

Datos elementales: nombre del elemento, descripción, origen (entrada desde teclado o
calculado en un proceso), caracteristicas (longitud, tipo, formato, validaciones, valores
predeterminados etc.)

En las primeras fases del análisis se construye un Diccionario de Datos preliminardonde

probablemente los datos elementales principalmente no puedan ser descriptos en su
totalidad, ya que todavía no se cuenta con información totalmente validada por usuario.

De esta forma, el Diccionario de datos evolutivo (siempre que se mantenga rigurosamente

actualizado) permite monitorear y realizar modificaciones a los datos con conocimiento del
impacto que tal modificación produciría sin rastrear por todas las rutinas de código.

BALANCEO DEL DFD Y EL DD

Cada flujo de datos y cada almacén de datos deben estar definidos en el diccionario de
datos. Si falta la definición en el diccionario, el flujo o almacén se considera "indefinido".

Cada dato y cada almacén definido en el diccionario de datos, deben aparecer en alguna
parte del DFD. Si no aparece dicho dato o almacén, es algo definido pero que no se utiliza
en el sistema.

En la medida que se impusieron las bases de datos relacionales, se hizo necesario la

inclusión de un modelo conceptual de datos más involucrado con el modelo lógico de estos
repositorios de datos, globales y corporativos, que funciona mediante relaciones entre los
atributos de los registros almacenados.

Este es el Diagrama Entidad-Relación (DER) que representa los datos del sistema como
una red de almacenamientos conectados por relaciones.

Diagrama Entidad-Relación (DER)

Los símbolos que se utilizan en este diagrama son;

ƒ Rectángulo: Entidad, conjunto de datos que identifica a través de sus atributos a un

Almacenamiento de Datos.

ƒ Rombo con nombre: Relación que conectan instancias entre entidades

Página 14 de 19
 Ing. Inés Casanovas

Una entidad asociativa es una representación de una relacion de la que se desea

mantener información. Por ejemplo: la entidad Cliente y la entidad Producto se relacionan
mediante una compra

CLIENTE PRODUCTO
compra

Con este modelo la compra es solo una relación, pero si se quisieran guardar datos
específicos, fecha por ejemplo, resulta claro que no es un atributo ni de Cliente ni de
Producto. En realidad, fecha es un atributo de Compra. Entonces debe modificarse el
modelo recurriendo a una asociación:

CLIENTE PRODUCTO

COMPRA

El rombo de relación queda vacío (sin nombre) porque el indicador de la relación pasó a ser
una entidad asociativa. Las entidades Cliente y Producto existen con independencia de
una compra, en cambio la existencia de la entidad Compra depende de aquellas.

Las entidades admiten una jerarquización en Supertipo y Subtipo. Por ejemplo, el

Supertipo EMPLEADO puede admitir dos subtipos: DE PLANTA y CONTRATADO. Se
indica mediante una línea atravesada en la conexión y un rombo de relación sin nombre.

Página 15 de 19
 Ing. Inés Casanovas

EMPLEADO

DE PLANTA CONTRATADO

Una relación está condicionada por las entidades que relaciona. Tiene asociada una
dimensión o número de entidades que relaciona, pudiendo ser 1, 2, .... Para una relación
binaria entre una entidad A y otra B, pueden darse de tres casos:

ƒ uno a uno (1-1): en la cual una ocurrencia de A no está en relación más que con una
ocurrencia de B y, cada ocurrencia de B no está en relación más que con una
ocurrencia de A.

ƒ uno a muchos (1-n): en la cual una ocurrencia de A está en relación con una o muchas
ocurrencias de B y, cada ocurrencia de B no está en relación más que con una
ocurrencia de A.

ƒ muchos a muchos (n-n): en la cual una ocurrencia de A está en relación con una o
muchas ocurrencias de B y, cada ocurrencia de B está en relación con una o muchas
ocurrencia de A.

La modalidad es el número mínimo de veces que una ocurrencia de una entidad está
implicada en una ocurrencia de la relación.

La cardinalidad es el número máximo de veces que una ocurrencia de una entidad está
implicada en una ocurrencia de la relación.

El valor 0 indica que no participa en la relación o lo que es lo mismo, que una ocurrencia de
una entidad puede existir sin estar implicada en ninguna ocurrencia de la relación. El valor 1
indica que participa en la relación con una sola ocurrencia, o lo que es lo mismo, que no
puede estar implicada más que en un máximo de una ocurrencia de la relación. El valor n
que participa con muchas ocurrencias o lo que es lo mismo, que puede estar implicada en n
ocurrencias de la relación.

Página 16 de 19
 Ing. Inés Casanovas

Determinación de la frontera de automatización

En este momento del análisis, se está trabajando con todas las actividades (funciones y
procesos) del sistema y, con los datos esenciales. Tendremos que plantearnos qué
funciones y qué datos deben ser manejados manualmente y cuáles deben ser
automatizados. Podemos encontrarnos tres casos:

ƒ Al usuario no le importa la frontera de automatización, cuáles son los límites entre parte
manual y parte automática. Esta situación es poco probable.

ƒ El usuario podría escoger un sistema totalmente automatizado. Esta situación suele ser
habitual si el sistema está siendo reemplazado por uno más moderno y no se cambia la
frontera de automatización, por lo que las actividades manuales ya se representan en el
Diagrama de contexto como agentes externos al sistema.

ƒ El usuario se decide por un sistema completamente manual, opción muy anormal. Se

puede dar en situaciones en las que se pretenda reorganizar la forma en la que se
desempeñan as actividades en una organización.

Lo habitual es que se automatizará parte de las actividades del sistema y, se dejarán como
manuales otras. Suele ser aconsejable que el usuario y el analista exploren varias
soluciones. Cada solución posible tendrá un coste que habrá que determinar y, diferentes
ramificaciones organizacionales. Esto corresponde a la fase de Estudio de Factibilidad de
alternativas.

HERRAMIENTAS CASE

Debido a las características específicas del ciclo de vida y, sobre todo, debido a la gran
cantidad de información que se debe generar en cada etapa, comienzan a introducirse
herramientas y entornos automatizados de producción, organización, edición y gestión de
dicha información, que facilitan, o en muchos casos posibilitan el uso de metodologías
formales de forma cómoda y eficiente. Por tanto, la tecnología CASE sustituye el papel y el
lápiz por el ordenador para hacer del desarrollo del software un proceso más productivo. El
objetivo fundamental del CASE es proporcionar un conjunto de herramientas que
automaticen los trabajos de desarrollo y mantenimiento del software. Algunas de las
facilidades ofrecidas por este tipo de herramientas son:

ƒ Soporte a la gestión para aumentar el control y la coordinación por parte de la dirección.

ƒ Diseño de diagramas estructurados y creación de especificaciones gráficas.

Página 17 de 19
 Ing. Inés Casanovas

ƒ Centralización de la información del sistema en un diccionario en el que se pueden

almacenar, obtener informes y consultar.

ƒ Verificación de la consistencia y la corrección de las especificaciones del sistema.

ƒ Mantenimiento: re-documentación, reestructuración y análisis del sistema diseñado.

ƒ Eliminar errores fácilmente.

Bibliografía
Yourdon E. (1989) Análisis estructurado moderno. Mc. GRaw Hill

Kendall y Kendall. (2005) Análisis y Diseño de Sistemas, Prentice Hall

Whitten J. et al (1996) Análisis de Sistemas y Métodos de Diseño, Irwin

Casanovas I. y Tomassino C. (2001) El proyecto Informático. Ed. Iara. Bs.As.

http://www.canalvisualbasic.net

Página 18 de 19
Ing. Inés Casanovas

Página 19 de 19