La elaboración de Prototipos es el proceso de desarrollo de un sistema no funcional

rápido y barato para demostración y evaluación, de manera que los usuarios puedan
determinar mejor sus requerimientos de información. Proporcionando una retroalimentación
temprana por parte de los usuarios acerca del Sistema. Por esto los Prototipos son útiles
para comunicar, discutir y definir ideas entre los diseñadores y las partes responsables.

Reacciones iniciales del usuario

Son recopiladas por medio de observaciones, entrevista y formas de

retroalimentación, diseñadas para recoger la opinión de cada persona acerca del prototipo
cuando interactúa con él. Por medio de estas reacciones el analista descubre muchas
perspectivas en el prototipo incluyendo el agrado que tenga el usuario al sistema.

Enfoque a los prototipos

El paradigma de creación de prototipos puede ser cerrado o abierto. Al enfoque

cerrado se denomina a menudo prototipo desechable. Este prototipo sirve como una basta
demostración de los requisitos. Después se desecha y se hace una ingeniería de software
con un paradigma diferente. Un enfoque abierto denominado prototipo evolutivo, emplea el
prototipo como primera evaluación del sistema terminado

Desarrollo De Un Prototipo

Cuando haya que decidir si hay que incluir la elaboración de prototipos como parte
del ciclo de vida de desarrollo de sistemas, el analista necesita considerar cuál tipo de
problema esta siendo resuelto y en qué forma el sistema presenta la solución.

Lineamientos para el desarrollo de un prototipo.

1. Trabajar en módulos manejables.

2. Construir el prototipo rápidamente.
3. Modificar el prototipo en interacción sucesiva.
4. Enfatizar la interfaz del usuario.
http://5tosemestreinganalisisdesistemas.blogspot.com/p/desarrollos-y-prototipos.html

JONATHAN GARCÍA 2014

 PROTOTIPOS INFORMATICOS

El desarrollo orientado a prototipos

Definición de un prototipo en software: “…es un modelo del comportamiento del sistema que puede ser

usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos… Un

prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características

del sistema final o parte de ellas”

Modelo o maqueta del sistema que se construye para comprender mejor el problema y sus posibles

soluciones:

 Evaluar mejor los requisitos.

 Probar opciones de diseño.

Características de los prototipos

 Funcionalidad limitada.
 Poca fiabilidad.
 Características de funcionalidad pobres.
 Alto grado de participación del usuario el cual evalúa los prototipos, propone mejoras y detalla
requisitos.
 Alto grado de participación del analista de sistemas, ya que en muchos casos los usuarios no
pueden indicar los requisitos sin tener experiencia con el sistema.
 El prototipo da mayor conocimiento al usuario y analistas ayudando a que el usuario aprenda a
utilizar el sistema.

Uso de prototipo

Se presenta al cliente un prototipo para su experimentación.

 Ayuda al cliente a establecer claramente los requisitos.

Ayuda a los desarrolladores a:

 Validar corrección de la especificación.

 Aprender sobre problemas que se presentarán durante el diseño e implementación del sistema.
 Mejorar el producto.
 Examinar viabilidad y utilidad de la aplicación.

Tipos de prototipos.

Prototipado de interfaz de usuario: modelos de pantallas.

Prototipado funcional (operacional): implementa algunas funciones, y a medida que se comprueba que

son las apropiadas, se corrigen, refinan, y se añaden otras.

Modelos de rendimiento: evalúan el rendimiento de una aplicación crítica (no sirven al análisis de

requisitos).

Rápido o desechable:

 Sirve al análisis y validación de los requisitos.

 Después se redacta la especificación del sistema y se desecha el prototipo.
 La aplicación se desarrolla siguiendo un paradigma diferente.
 Problema: cuando el prototipo no se desecha, y termina convirtiéndose en el sistema final.

Evolutivos:

 Comienza con un sistema relativamente simple que implementa los requisitos más importantes o
mejor conocidos.
 El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos.
 Finalmente, se convierte en el sistema requerido.
 Actualmente se usa en el desarrollo de sitios Webs y en aplicaciones de comercio electrónico.

Vertical
  Desarrolla completamente alguna de las funciones.

Horizontal

 Desarrolla parcialmente todas las funciones.

Herramientas de prototipado.

 Lenguajes dinámicos de alto nivel.

 Lenguajes de cuarta generación (4GLs) (programación de BBDD).
 Ensamblaje de componentes y aplicaciones.

Lenguajes Dinámicos de alto nivel.

Muy usados:

 Smalltalk (basado en objetos, sistemas interactivos)

 Java (basado en objetos, sistemas interactivos)
 Prolog (lógico, procesamiento simbólico)
 LISP (basado en listas, procesamiento simbólico)

Elección del lenguaje:

 ¿Cuál es el dominio de aplicación?

 ¿Cuál es la interacción de usuario requerida?
 (Java, Smalltalk se integran bien con las interfaces Web.)
 ¿Cuál es el entorno proporcionado para el lenguaje?

Lenguajes de 4ª Generación.
  La mayoría de aplicaciones de gestión son interactivas e implican la manipulación de una BD y la
producción de salidas que involucran organizar y dar formato a esos datos.
 4GL: lenguaje de programación de BBDD (y su entorno de desarrollo), que contiene conocimiento
de la BD y operaciones para manipulación de la misma.
 4GL: lenguaje no Procedimental.
 Reducen claramente los costos del desarrollo.
 Muy usados en prototipado evolutivo.
 Muchos 4GLs permiten el desarrollo de interfaces de
 BBDD basadas en navegadores Web.
 Generan SQL.
 Menos eficientes que los lenguajes de programación convencionales.
 Reducen claramente los costos del desarrollo.

Ensamblaje de componentes y aplicaciones.

El desarrollo de prototipos con reutilización comprende dos niveles:

1. El nivel de aplicación, en el que una aplicación completa se integra con el prototipo

 P.ej., si el prototipo requiere procesamiento de textos, se puede integrar un sistema estándar de

procesamiento de textos (MS Office).

B. El nivel de componente, en el que los componentes se integran en un marco de trabajo estándar.

 Visual Basic, TCL/TK, Python, Perl…

– Lenguajes de alto nivel sin tipos, con kits de herramientas gráficas.

– Desarrollo rápido de aplicaciones pequeñas y relativamente sencillas, construidas por una persona o

conjunto de personas.

– No existe una arquitectura explícita del sistema.

  CORBA, DCOM, JavaBeans

– Junto con un marco arquitectónico, es más apropiado para sistemas grandes.

Prototipos de Interface de Usuario.

Las descripciones textuales y los diagramas no son suficientemente buenos para expresar los requisitos de

la interfaz.

La construcción de prototipos evolutivos con la participación del usuario final es la forma más sensata de

desarrollar una interfaz.

Los usuarios deben estar implicados en la evaluación y evolución del prototipo.

Herramientas:

 Generadores de interfaz (4GLs, Visual Basic, etc.).

 EDITORES DE PÁGINAS WEB
 Herramientas CASE.

– Formularios, pantallas, generación de código…

 Bocetos en papel.
 Aplicaciones de dibujo

– Harward Graphics, etc.

 MS PowerPoint.
 Etc.

FASES

Las fases que comprende el método de desarrollo orientado a prototipos serían:

 Investigación preliminar. Las metas principales de esta fase son: determinar el problema y su
ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro
lado, identificar una idea general de la solución para realizar un estudio de factibilidad que
determine la factibilidad de una solución software.
  Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los
requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa
es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los
requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo
esta etapa será revisada con más detalle luego de esta descripción.

 Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el diseño

detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la
organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos
etapas: por un lado, la producción de una documentación de diseño que especifica y describe la
estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como
segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del
software.

 Programación y prueba. Es donde los cambios identificados en el diseño técnico son

implementados y probados para asegurar la corrección y completitud de los mismos con respecto a
los requerimientos.

 Operación y mantención. La instalación del sistema en ambiente de explotación, en este caso,

resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al
hacer las pruebas de prototipos. Además, la mantención también debería ser una fase menos
importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los
requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se
requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo
conjunto de requerimientos.

La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso

que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La

definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:

 Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño básico

para el prototipo inicial.

 Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador

debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la
interface del usuario.
  Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los
requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en
concordancia con la definición de requerimientos del sistema. Si los usuarios identifican fallas en el
prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente
evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos
del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos
separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase
se decide si el prototipo es aceptado o modificado.

 Modificación. Esto ocurre cuando la definición de requerimientos del sistema es alterada en la

sub−fase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los
comentarios hechos por los usuarios.

 Término. Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de
acuerdo en relación a aspectos de calidad y de representación del sistema.

En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificación

de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya

que permite entregar al usuario lo que sería una visión la solución final en etapas tempranas del desarrollo,

reduciendo tempranamente los costos de especificaciones erróneas.

 Modelo de desarrollo Orientado a Prototipos

Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por:

 Reducción de la incertidumbre y del riesgo

 Reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema,
 Mejoras en la administración de proyectos
 Mejoras en la comunicación entre desarrolladores y clientes, etc.

Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, también

presenta desventajas como:

 La dependencia de las herramientas de software para el éxito ya que la necesidad de disminución

de incertidumbre depende de las iteraciones del prototipo, entre más iteraciones exista mejor y esto
último se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente
de las mismas.
  También, no es posible aplicar la metodología a todos los proyectos de software y, finalmente, la
mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir con el
sistema terminado.
 No se puede desconocer que la fase de definición de requerimientos se ha perfeccionado en dos
aspectos importantes: primero se ha aproximado las visiones del usuario y el desarrollador, lo cual
representa el beneficio de establecer una base común de comunicación; también, el hacer explícita
la posibilidad de iterar sobre estos dominios permitiría que la convergencia de los mismos sea una
posibilidad cierta.

Un escenario para la construcción de

prototipos

Todos los proyectos de ingeniería de software comienzan con una petición del cliente. La petición puede

estar en la forma de una memoria que describe un problema, un informe que define un conjunto de

objetivos comerciales o del producto, una petición de propuesta formal de una agencia o compañía exterior,

o una especificación del sistema que ha asignado una función y comportamiento al software, como un

elemento de un sistema mayor basado en computadora. Suponiendo que existe una petición para un

programa de una de las formas dichas anteriormente, para construir un prototipo del software se aplican los

siguientes pasos:

PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato

para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos,

es esencial que:

1) el cliente participe en la evaluación y refinamiento del prototipo, y

2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la

naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo.

PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los

requerimientos. Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar

los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La

aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis

de requerimientos.

PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de

especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la
construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la

arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental

detallado.

PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de

software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales

bloques construidos raramente existen. Incluso si la implementación de un prototipo que funcione es

impracticable, es escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones

interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la

interacción hombre-maquina usando una serie de hojas de historia.

PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual “conduce la prueba” de la

aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí

donde el cliente puede examinar una representación implementada de los requerimientos del programa,

sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.

PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o

hasta que el prototipo haya evolucionado hacia un sistema de producción. El paradigma de construcción del

prototipo puede ser conducido con uno o dos objetivos en mente:

1) El propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego

ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de

programación, o

2) El propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al

desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y amos crean

problemas.

Para poder realizar el prototipado debemos aplicar una técnica de captura de requerimientos que es una

herramienta que ayuda al proceso de abstracción de las características de un sistema. La captura de

requerimientos se hace a través de un proceso específicamente mental, el cual es el analista quien tiene la

capacidad para discernir sobre los detalles que interesan en realidad al sistema, valiéndose generalmente de

experiencias pasadas.

La identificación de actores y use case en un sistema se hace para:

 Delimitar el sistema de su ambiente externo.

  De qué y quién actuará con el sistema y que funcionalidad es la que se espera de él.
 Capturar y definir un glosario de términos.
 Además es necesario que nosotros como analistas utilicemos una herramienta propia para realizar
cada uno de los pasos antes mencionados.

EJEMPLO:
Prototipo informático para la
evaluación de la calidad de la
educación superior
Definición del Problema:

Las universidades necesitan desarrollar procesos de evaluación institucional de desempeño, que conllevan a

la revisión de sus estructuras funcionales y al conocimiento diagnóstico de la situación actual con el fin de

incrementar los niveles de eficacia, eficiencia y efectividad de la gestión universitaria.

Es necesario fomentar procesos de evaluación en función de optimizar el uso de los recursos humanos,

tecnológicos y financieros disponibles en la institución a objeto de lograr un desarrollo más armónico y

planificado, en atención a una estricta observación de su misión. Bajo esta perspectiva se ofrece una

propuesta de Prototipo Informático para la Evaluación de la Calidad de la Educación Superior, cuyos

objetivos, entre otros, son: fomentar e incentivar la cultura de evaluación de la calidad universitaria; diseñar

indicadores de gestión universitaria para dicho sistema de información, para cada uno de los ámbitos:

académico, investigación, extensión y administrativo. Para el desarrollo, se aplicarán las herramientas y

técnicas para levantar los requerimientos de usuario, y producir las salidas que satisfagan las necesidades de

información y el acceso en forma integrada a la misma; respecto a los diferentes niveles de la pirámide

organizacional, accesibilidad a indicadores de gestión de calidad universitaria a través de módulos

interdependientes; esto es, cada nivel con su vista de usuario en la base de datos. Se aplica la metodología

modular de sistemas, el enfoque de arriba hacia abajo y el diseño de base de datos relacional.

El prototipo está diseñado bajo una interfaz gráfica para interactuar con el usuario a través de botones

programables y la navegación del sistema se realizará a través de pantallas tipo ventanas

 Modelo sistémico para la elaboración del prototipo informático de evaluación de la calidad

en educación superior
El modelo sistémico, se basa en las fórmulas más convencionales de la teoría de sistemas, considerando

entradas, transferencias y salidas.

Será el utilizado para el prototipo informático propuesto, ya que ofrece todas las bondades de la metodología

de sistemas.

En el modelo de evaluación propuesto para el prototipo de evaluación de la calidad universitaria, se perfilan

tres bloques, como lo muestra la gráfica siguiente:

 Entrada: estaría constituida por las inversiones, tanto en recursos materiales como humanos. En
otras palabras: salas, talleres, bibliotecas, laboratorios con todos sus implementos; además de
estudiantes, profesores y personal administrativo.
 Procesos: estarían compuestos justamente por todas las interacciones que tienen lugar en la
institución y que permiten que ésta pueda cumplir los compromisos adquiridos con la sociedad, en
cuanto a conocimiento creados, profesionales formados y servicios entregados a la comunidad. Esto
incluye todos los procedimientos de administración universitaria y gestión financiera de la
organización.
 Salida o productos: corresponde a los logros organizacionales en docencia, investigación y
extensión. Serían aspectos del resultado, la cantidad de graduados por cohorte, los proyectos de
investigación realizados, las publicaciones de los mismos y el número de académicos perfeccionados
en un periodo determinado.

En síntesis, el modelo sistémico presenta para estos propósitos una gran ventaja, pues ayuda a agrupar de

manera ordenada los componentes institucionales y facilita la comprensión de la relación que existe entre los

mismos.

Propuesta para sistematizar la información en el prototipo de evaluación de la calidad de las instituciones de

educación superior

Para sistematizar la información se utilizarán las seis dimensiones del modelo de CINDA que, como se ha

dicho, permite hacer una revisión bastante completa y coherente en los siguientes aspectos: académicos en

general, en la función docente, de investigación y creación, de extensión y servicios, y de gestión

administrativa.

De acuerdo con ello, se ha planteado la matriz modelo CINDA de información para cada uno de los tres

aspectos, que incluye los problemas de calidad a resolver, las propuestas de solución y las sugerencias

estratégicas.
 Matriz modelo CINDA

Dicha matriz se aplicará para cada uno de los aspectos a evaluar respecto a la calidad universitaria, entre los

que tenemos:

 Función Docente
 Aspectos Generales Académicos
 Función Investigación
 Función Extensión
 Gestión Administrativo-académica

 Metodología para el desarrollo del prototipo de evaluación de la calidad universitaria

Para el desarrollo del prototipo informático para la evaluación de la calidad de la educación superior, se

aplicarán los instrumentos y técnicas para levantar los requerimientos de usuario, y producir las salidas que

satisfagan las necesidades de información y el acceso en forma integrada a la misma, respecto a los

diferentes niveles de la pirámide organizacional; esto es, nivel estratégico, nivel táctico y nivel operativo,

accesibilidad a indicadores de gestión de calidad universitaria a través de módulos interdependientes, es

decir, cada nivel con su vista de usuario en la base de datos.

Se aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el diseño de base de datos

relacional.

Diseño de arriba hacia abajo (top-down)

Se selecciona el diseño de arriba hacia abajo, “por la facilidad de visualizar una gran imagen del sistema y

luego explotarla en partes o subsistemas más pequeños. El diseño de arriba hacia abajo permite que el

analista de sistemas piense acerca de las interrelaciones e interdependencias de los subsistemas. Este

enfoque también proporciona el énfasis deseado sobre la sinergia o las interfaces que requieren los sistemas
y subsistemas. Las ventajas de usar este enfoque para el diseño de sistemas incluyen el evitar el caos de

diseñar un sistema todo a la vez. El tratar de tener todos los subsistemas en su lugar y funcionando a la vez

es aceptar que se va a fallar”.

Enfoque modular para el desarrollo de sistemas

Una vez que ha sido tomado el enfoque de diseño de arriba hacia abajo, el enfoque modular es útil en la

programación. Este enfoque involucra la división de la programación en partes o módulos lógicos y

manejables. Este enfoque de programación se ajusta bien con el diseño de arriba hacia abajo, debido a que

enfatiza las interfaces entre módulos. En el prototipo se aplica la metodología modular de sistemas para

desarrollar los módulos: Función Docente, Función Investigación, Aspectos Generales Académicos, Función

Extensión, Gestión Administrativo-académica.

Diseño de base de datos relacional

Se selecciona el modelo relacional de base de datos, por ser el óptimo en comparación con los modelos de

base de datos jerárquicos y el de redes. Otra ventaja de este modelo es la portabilidad, ya que la mayoría de

los paquetes de manejo de base de datos para computadores personales usan el enfoque “relacional”. En

este modelo los datos se organizan en “tablas” en las cuales una fila equivale a un registro.

Conceptualmente la tabla de la base de datos es lo mismo que un archivo. Una o más tablas constituyen una

base de datos relacional. La base de datos relacional se refiere a una serie de tablas y a las relaciones entre

ellas. El sistema tendrá capacidad, entre otras cosas, para:

1. Crear y mantener la base de datos: esto es agregar, eliminar y modificar tablas.

2. Extraer y presentar información que cumpla ciertas condiciones.
3. Hacer consultas (por ejemplo: “¿Cuál es el promedio de notas de los alumnos por carrera y por
universidad? ¿Cuál es la matricula por área de conocimiento? ¿Cuál es la rotación matricular?”,
etc.).
4. Ordenar los registros (tablas), según el campo clave.
5. Generar informes adecuados para el usuario. (Por ejemplo: una universidad generará el reporte de
gestión periódicamente, según sea el caso o el “Reporte financiero” puede ser semestral o anual,
etc.).

Modelo entidad relación

Se generarán una serie de entidades y relaciones “uno a muchos”, a las cuales se le aplicará la técnica de

normalización de tablas, incluso la tercera forma normal 3FN y 4FN, de ser necesario. Entre las entidades

tenemos: Universidad, Alumnos, Profesor, Organismos reguladores, Proveedores, Productos, Oferta

académica laboral, Egresados, etc.

Diseño de la interfaz gráfica del prototipo

Para el desarrollo del prototipo informático para la evaluación de la calidad de la educación superior, se

deben aplicar instrumentos y técnicas para levantar los requerimientos de usuario, y producir las salidas que

satisfagan las necesidades de información y el acceso en forma integrada a la misma, respecto a los

diferentes niveles de la pirámide organizacional; esto es nivel estratégico, nivel táctico y nivel operativo,

accesibilidad a indicadores de gestión de calidad universitaria a través de módulos interdependientes; esto

es, cada nivel con su vista de usuario en la base de datos.

El prototipo está diseñado bajo una interfaz gráfica para interactuar con el usuario a través de botones

programables y la navegación del sistema se realizará a través de pantallas tipo ventanas.

ING. DE SISTEMAS UNL. 2009

LEYDI REYES http://www.2shared.com/fadmin/6705520/64f99307/EXPOSICION.ppt.html“