Despues de una intensa jornada de trabajo con DDA (Dider Dupuy d'Angeac, el consultor que nos fabrica MULBRI) me parece oportuno de hacer una balance de la situacion, de mirar hacia el futuro, y de proponer un plan tentativo integrando las propuestas de colaboracion que nos ofrecerion Julian por la Universidad de Buenos Aires y la red argentina UUCP, y Tadao por la red Brasilenha RNP. Por fabor, DDA rectifica las omisiones o erores que provablamente existen en ese documento.

Un saludo a todos,

Daniel

PS

En un proximo mensaje mando unos recortes de dos documentaciones que fueron escrita al principio de MULBRI. El documento es bastante largo (19 paginas), asi es que los que lo conoscen pueden descartarlo.

I HISTORICO

I.I Razones historicas

El concepto nacio en Union Latina al pricipio del proyecto REDALC (en 1988) con la idea de matar 3 pajaros con un solo tiro, por orden de prioridad inicial:

1) resolver problemas de comunicacion internos en la UL utilizando una mensajeria basada en las redes de investigacion.

Hay que recordar que la UL presenta una configuracion muy tipica en torno a comunicacion:
-En total, algunas decenas de funcionarios distribuidos en mas de 10 oficinas dispersas entre Europa latina y America latina, -un presupuesto relativamente bajo para la gestion (no se puede utilizar el telefono cada vez que se necesita hablar con un colega),
-un nivel de informatica corecto (PC's), -un crecimiento fuerte, y, por supuesto, -actividades de investigacion (o ligadas al mundo de la investigacion).

Porque MULBRI?

1.1) Porque la formacion al uso del interfase nativo

2) Para adquirir una experimentacion en tamanho real del uso de las redes en vista del futuro estudio REDALC asumiendo que el caso de la UL no era tan diferente estructuralmente que el de un laboratorio de investigacion con antenas en varios lugares.

Porque MULBRI?

2.1) Porque en muchos paises hay que utilizar una red de datos costosa para llegar a un nodo de EARN o BITNET, y que entonces era preferable deportar el maximo del proceso en el PC y permitir la compactacion, para bajar sensiblemente la factura.

2.2) Porque la solucion de archivaje en el nodo no era conveniente para un consultor en constante viaje que necesita mobilizar rapidamente sus datos, documentos y mensajes.

3) A mas largo plazo, para poner en perspectiva el desarollo de un prototipo de interfase usuario de alto nivel deportado en PC, con el objetivo de definir un programa capaz de ofrecer a la region ALC lo que falta en las otras regiones. La idea es de integrar ese trabajo al estudio REDALC de tal manera a integrar el desarollo industrial de ese programa al presupuesto del proyecto.

Porque MULBRI?

Para desarollar un metodo de experimentacion rapido y paralelo al estudio de factibilidad REDALC.

I.II Desarrollos

VERSION I, 6/89

La primera version fue basada en el entorno informatico del nodo EARN que nos aloja, el del CNUSC en Montpellier: nodo IBM/VM con acceso remoto via TRANSPAC a traves del programa SIMPC version XXXX, y del entorno de trabajo de la UL: PC bajo DOS. Todavia MULBRI funciona solamente en ese entorno.

La primera version fue fabricada por Daniel Pimienta a partir de la implementacion (utilizando un mecano de programas existentes y una particion de directorios) de un diseno sencillo que distingua los usuarios siguientes: -Internos Union Latina: los funcionarios de la organizacio, con la distincion de los usuarios "local" (los que comparten el mismo nodo y que necesitan comunicar entre se). Dentro de los usuarios internos aparecio tambien el concepto de operador de grupo de Usuario encargado de la comunicacion para un grupo. -Usuarios redes de investigacion: el mundo "normal" de las redes, que no utiliza MULBRI (el acceso a ese grupo es reservado a los investigadores de la UL).

Desde su principio MULBRI separa dos tipos de comunicacion:

-dentro del mundo MULBRI, con funciones avanzadas de

comunicacion

mensajes con accentos, documentos o hojas de calculo compactados, cartas encryptadas con llave, archivage implicito por destinacion, administracion de los usuarios facilitada, y mas que todo estructuracion de la comunicacion para permitir un control logico y fiable del flujo.

La baja calidad del interfase usuario de esta version se noto rapidamente al mismo tiempo que nuestras limitaciones en personal para seguir un desarollo. Asi se decidio contratar DDA para confecionar algo mas serio (despues de una mala experiencia con otra persona).

Se redactaron dos documentos: -"El uso del complejo "EARN/TELENET", 9/89: documento de 18 paginas destinado a brindar los conceptos basicos a usuarios sin experiencia de telecomunicacion y a demistificar el uso de redes. Ademas el documento aborda consideraciones economica en el uso de diferente metodos de comunicacion. -"MULBRI", 11/89; un docummento de 19 paginas conteniendo elementos de disenhos (formato de los mensajes, flujo de los mensajes, interfases) y consejo de buen uso a los usuarios.

VERSION 2

Fue la replica exacta del disenho inicial y de las funciones, pero con interfases de buena calidad y con una programacion ad hoc. Desde ese nivel, MULBRI comenzo a ofrecer las tecnicas la mas avanzadas de programas en PC ("pop up windows", ayudas contextual). DDA se dio el gusto de fabricar su propio lenguaje "a motor de inferencia" que hacia, siguiendo una programacion descriptiva, ejecutar rutinas escritas en languaje PASCAL. Utilizando el interface SIMPC, MULBRI arrancaba proceduras escritas en el languaje de SIMPC para la transferencia de los mensajes entre el nodo y el PC. Y, dentro del nodo, se arracanban rutinas escritas en REXX bajo VM. MULBRI presentaba desde este nuevo principio una tecnica de compactacion recursiva para automatizar y facilitar el proceso de instalacion.

VERSION 3

El objetivo es de llegar, con el final de esa version, a un nivel donde todas las funcionalides importantes estan satisfechas para el uso interno, y a un nivel de funcion por lo menos igual a EARN por el uso externo a la UL. Hubieron 3 sub-versiones ya, que hizieron un salto funcional importante (3.11 a 3.13 la actual). Las versiones 3 ubiquan MULBRI a un nivel de programa profesional y se puede pensar ahora a extender su uso. El problema crucial del archivaje de los mensajes fue tratado con la version 3, y una seria de funciones de manipulacion de mensajes fuzeron introducidas (copiar, reenviar, importar, exportar). Para lograr eso, DDA tuvo que extender el disenho inicial, manteniendo el control de flujo de manera explicita en bloques de control.

I.III Modo de desarrollo

La originalidad del modo de desarollo es que los propios usuarios expresan sus quejas o requisitos al fabricante quien resolve los problemas urgentes, mandando, por el mismo sistema de comunicacion MULBRI, las soluciones que auto modifican el programa. Ademas se consignan los requisitos para decidir, en reuniones frecuentes, el contenido de la proxima version. Va sin decir que la opinion de los usuarios finales es clave en el proceso.

II MULBRI EN LA ACTUALIDAD

II.I Nivel de calidad

Si bien es que el modo de desarollo aporta los problemas normales de un prototipo (problemas nuevos a cada version que se arreglan poco a poco), el metodo nos permitio llegar a un nivel funcional ya bastante operacional y que reflete los deseos de usuarios non neceseriamente informaticos o especialistas de redes. Desde la version 3.1 MULBRI se planteo como una herramienta brindando los frutos esperados de la inversion para el uso interno. La version actual tiene un nivel funcional bastante impresionante en termino al uso interno, y bien operacional en termino de uso hacia el mundo de las redes. La experiencia del uso del nivel 3 de MULBRI desde varios meses permite ya entrever la version final del nivel 3, resolviendo problemas importantes de coherencia semantica de los MENU, utilizando el multi-linguismo, y afinando el nivel de detalle del propio interfase usuario. Los problemas ya son menos frecuentes, y donde las condiciones de communicacion son suficiente, el uso ya es natural y fluide. La extencion se hace con facilidad en el plan humano (los nuevos usuarios "entran" en el sistema sin problema) y los sindromes de rechazo (frecuente frente a tecnologias avanzadas en el mundo de la oficina, no se han manifestado).

Hemos tenido experiencias de uso de "burotica-fiction" de la valor importante que representaba el envio de documentos. En un caso de gestion administrativa urgente entre Santo-Domingo y Paris via Martinica, donde documentos redactados por un "staff" en un lugar, estaban corregidos por una secretaria en otro lugar, chequeado por el firmante en otro lugar, reenviado para ultima correcion al redactador y luego mandado en un tercero lugar para impresion sobre papel prefirmado y remite. Un exercisio de estilo que permitio arreglar en 1 dia un proceso que hubiera tomado semanas por correo y que hubiera sido imposible sin MULBRI.

II.II Cifras de uso

En la actualidad existen 7 "agencias MULBRI" operacionales (con el uso del nodo del CNUSC), y un trafico quotidiano superior a 15 mensajes o documentos internos. Los dos usuarios los mas goloso del programa son, Silvia Quenan, la operadora de la agencia Arago de la Union Latina (quien gestiona unos 15 usuarios finales) y Daniel Pimienta quien ademas de intercambiar una medida de 4 mensajes diarios con sus coleguas de Union Latina mantiene un intercambio de 6 mensajes diarios con sus coleguas del mundo de la investigacion. A ese nivel el numero de mensajes archivados en su PC pasa los 1000. Las dificultades actuales de extension ya no estan del hecho de MULBRI, sino del inevitable problema de aplicacion a entornos diferentes (agencias con nodo USENET, agencias con nodo BITNET sin SIMPC, etc...).

III FUTURO DE MULBRI

Hay 5 axis de desarollo del prototipo:

*Funcionalidades en uso interno: -Estabilizacion del programa (coherencia logica y semantica de los menu, rellenar los menu de ayuda, traduccion en frances, portugues y italiano, redaccion de documentos para usuarios, para operadores, y para programadores), -confeccion de una version de demonstracion adaptada al mundo de la investigacion,
-automatizacion del proceso de personalizacion de las proceduras de conexion, version para aliviar el usuario en entorno de comunicacion dificil ("scheduler" de noche, chequeo finos de la comunicacion, rescheduleo en caso de problema). -version adaptada al uso de redes locales donde cada usuario final es identificado como destinacion y el proceso de operadora se hace de manera automatica.

*Funcionalidades en el uso hacia el mundo de la investigacion:
-nivelacion funcional hacia EARN (tener por lo meno el mismo nivel funcional que el que ofrece EARN), -rationalizacion de los flujos de mensajes (el caso de la lista de distribucion sin hacer varios envios del PC al nodo) -extencion funcional (acceso a banco de datos y gestion de conferencia).

*Soporte de entornos diferentes:

-por el terminal, ademas de PC/DOS: APPLE, PC/UNIX. -por el programa de comunicacion, ademas de SIMPC: un programa ad-hoc(?), UUPC (?), un programa existante con emulacion mas natural (?), TCP-IP (?).
-por el entorno del nodo: version UUCP, version BITNET/DEC.

*Aspetos normativos: integracion de los conceptos X400,

*Aspetos usuarios: integracion de conceptos de comunicacion estructurada (como Coordinador), funciones de burotica (agenda, organizacion de reunion, guias telefonicas...).

La trampa en la cual no podemos caer con un prototipo es de pretender hacer un desarrollo industrial en varios entornos: los costos de produccion se estuvieran multiplicandose en factores del orden de magnitud de 10 a 100! Tambien tenemos que poner mucho pragmatismo en nuestras seleccion: -evitar problemas de compatibilidad en permitiendo solamente desarrollos complementarios bajo interfases estrictamente definidos,
-concentrase en soluciones que corresponden a problemas de la region y que demuenstran algo en el tiempo del estudio (que se termina antes del final del anho), -adquirir experencia en entorno que son o van a ser importante, -no perder de vista el objetivo global de REDALC de tal manera a integrar de manera convenable el resultado en el documento de proyecto.

El estado de nuestras reflexiones, luego de la reunion con

-Primzero MULBRI se consolida para terminar la version 3.

-Luego, el proceso se orienta mas a la problematica REDALC

-Se trata de desarollar entornos en nodos diferente para capitalizar en la parte la mas gruesa del programa (la que esta en el PC), eso implica:
*Dejar el entorno APPLE por el momento (a lo menos que alguien se proponga) y el entorno PC/UNIX,
*focalizar los entornos UUCP, TCP-IP, X400.

IV PLAN DE DESARROLLO DE MULBRI (TENTATIVO)

1/5/91     6     7     8     9     10    11     12   1/92  2/92 

=================================================================
     ^     ^     ^     ^     ^      ^     ^      ^    ^    ^    ^
     a     b     c     d     e      f     g      h    i    j    k

Definicion de la version 3 pre final:

-integracion de las nuevas definiciones de los menu, -introduccion del concepto de confirmacion en acciones, -archivaje abierto (distinccion version operador y version usuario final),
-amelioracion de las proceduras SIM, resolucion del problema del usurario en viaje, scheduler de conexion, -amelioracion de la presentacion, soporte de "mouse",

V ELEMENTOS DEL DISENHO DE MULBRI

En prealable a la documentacion para programadores que nos va preparar DDA esta capitulo ubiqua una seria minima de clave para entender el programa y sus interfases.

V.I Interfases

VMCDE: procedura que se ejecuta en el nodo que coordona los diferente procesos que se ejecuta en el nodo.

FORSIMPC: proceduras de SIMPC que se ejecuta en el nodo para la transferencia de archivos (ver documentacion SIMPC).

RECIBxx.DWN: archivo de control de recepcion (xx para UL, LO o RI).

MANDAR.RES: archivo de control de envio

xxxx.NAM : Archivos de definicion de los destinatarios de

V.II Funciones

EXLDR: Cargador de programa
MENCTL: Controldor de comando y de menu,

V.III Archivos de control

MULBRI.GLO

mantiene el entorno (se puede borrar en caso de problema),

*.HLP: ayudas contextuales (las dos ultimas letras indican el idioma),
*.LAB: contenidos de los menus
*.MNU: acciones asociadas con los menu (paralelo a LAB), *.LST: archivos de configuracion por la mayoria, los siguientes son archivos de control de flujo: ARCHIV, LISTO, PREPAMA, RECIB, RECVM.

V.IV Codigos de control

A= Accion inmediata de una funcion interna, M= Cargar el menu,
C= Ejecutar el comando DOS,
P= Ejecutar el programa .EXE o .COM, F= Ejecuta la macro definida,
D= Define una macro,

@= variable usuario,
%= variable interna.