MODELO SOFTWARE PARA INTERCAMBIO ELECTRÓNICO DE TRABAJOS DE GRADO ENTRE INSTITUCIONES DE EDUCACIÓN SUPERIOR
DIEGO ALEJANDRO SIERRA ALEAN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
MODELO SOFTWARE PARA INTERCAMBIO ELECTRÓNICO DE TRABAJOS DE GRADO ENTRE INSTITUCIONES DE EDUCACIÓN SUPERIOR
DIEGO ALEJANDRO SIERRA ALEAN
Proyecto de grado modalidad investigación
Director: JULIO BARÓN VELANDIA Profesor Facultad de Ingeniería
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C.
Nota de aceptación
_____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________
_____________________________________ Director
_____________________________________ Jurado
AGRADECIMIENTOS
En primer lugar agradezco a Dios por darme la oportunidad de estudiar esta carrera y brindarme fortaleza y sabiduría para superar todos los momentos difíciles que se presentaron en el transcurso del camino.
Mi más sincero agradecimiento a mi director de trabajo de grado, el ingeniero Julio Barón Velandia por su valiosa asesoría, paciencia, motivación y por brindar los conocimientos necesarios para la estructuración y desarrollo del presente proyecto. Al ingeniero Alejandro Daza Corredor por su apoyo y colaboración en la revisión y corrección del presente trabajo.
A mis padres Sonia Jeannette Alean Moreno y Juan Alejandro Sierra Melo por brindarme los consejos, la motivación y el apoyo constante e incondicional, a mi hermano Juan Camilo Sierra Alean por la confianza y ánimo durante toda la carrera. En este tiempo me han acompañado en todos los momentos y son el motor que me dio la fuerza necesaria para culminar esta etapa, sin ustedes este sueño no podría ser posible.
Por último quiero agradecer a la Universidad Distrital Francisco José de Caldas, Sistema Nacional de bibliotecas, Universidad Nacional de Colombia y la biblioteca de la Pontificia Universidad Javeriana quienes han aportado los elementos y la información para el desarrollo de este trabajo.
TABLA DE CONTENIDO
Pág.
INTRODUCCIÓN 10
1. PLANTEAMIENTO DEL PROBLEMA 12
1.1 DESCRIPCIÓN DEL PROBLEMA 12
1.2 FORMULACIÓN DEL PROBLEMA 14
2. OBJETIVOS DE LA INVESTIGACIÓN 15
2.1 OBJETIVO GENERAL 15
2.2 OBJETIVOS ESPECÍFICOS 15
3. JUSTIFICACIÓN 16
4. ALCANCES Y LIMITACIONES 18
4.1 ALCANCES 18
4.2 LIMITACIONES 20
5. MARCO REFERENCIAL 23
5.1 MARCO HISTÓRICO 23
5.2 NEGOCIOS ELECTRÓNICOS 24
5.2.2 TÉRMINOS COMUNES. 27
5.3 ESTÁNDARES DE NEGOCIO ELECTRÓNICO. 30
5.3.1 ROSSETANET 30
5.3.2 BIZTALK 32
5.3.3 E-BUSSINESS XML 33
5.3.4 ANÁLISIS DEL MARCO REFERENCIAL 38
6. METODOLOGÍA 40
6.1 TIPO DE ESTUDIO 40
6.2 PERIODO Y MUESTRA DE LA INVESTIGACIÓN 40
6.3 TÉCNICA METODOLÓGICA 41
6.3.1 ETAPA DE OBSERVACIÓN 41
6.3.2 ETAPA DE INDUCCIÓN 41
6.3.3 FORMULACIÓN DE LA HIPÓTESIS Y EXPERIMENTACIÓN 42
6.3.4 METODOLOGÍA DE INGENIERÍA DEL PROYECTO 42
7. DEFINICIÓN DEL MODELO 46
7.1 CARACTERÍSTICAS DEL PROCEDIMIENTO DE INTERCAMBIO 46
7.3 ESPECIFICACIONES DEL PROCESO DE INTERCAMBIO 52
8. ANÁLISIS, DISEÑO Y DESARROLLO DEL PROTOTIPO 58
8.1 REQUERIMIENTOS 58
8.2 CASOS DE USO 64
8.2.1 ACTORES 64
8.2.2 DIAGRAMA DE CASOS DE USO PRELIMINARES 65
8.2.3 DEPENDENCIA Y PRIORIDAD CASOS DE USO 67
8.2.4 CASOS DE USO CONSOLIDADOS 70
8.3 DIAGRAMA DE CLASES 79
8.4 DIAGRAMA DE SECUENCIA 84
8.5 DIAGRAMA DE COMPONENTES 89
8.6 DIAGRAMA DE DESPLIEGUE 90
7. CONCLUSIONES 93
8. TRABAJO FUTURO 96
LISTA DE TABLAS
Pág.
Tabla 1: Capas B2B 26
Tabla 2: Comparación frameworks de negocio 38
Tabla 3: Requerimientos de prototipo 59
Tabla 4: Rangos Dependencia/Prioridad 61
Tabla 5: Requerimientos vs Requerimientos 61
Tabla 6: Prioridad/Dependencia Requerimientos 63
Tabla 7: Caso de Uso vs Caso de Uso 67
Tabla 8: Dependencia Prioridad Casos de uso 69
Tabla 9: Casos de Uso Consolidados 70
Tabla 10: Gestionar Perfiles CUP01 71
Tabla 11: Realizar Solicitudes CUP02 73
Tabla 12: Elaborar Especificación de Proceso CUP03 74
Tabla 13: Gestionar Aprobaciones CUP04 76
Tabla 14: Realizar Transacciones CUP05 77
Tabla 15: Características Hardware Base de datos 91
Tabla 16: Características Hardware Servidores 92
LISTA DE FIGURAS
Pág.
Ilustración 1: Infraestructura de ebXML 35
Ilustración 2: Actores del sistema 65
Ilustración 3: Caso de uso Usuarios 66
Ilustración 4: Casos de Uso Perfiles 66
Ilustración 5: Casos de Uso Acuerdo 67
Ilustración 6: Diagrama de casos de uso Consolidados 71
Ilustración 7: Paquete de Modelos 80
Ilustración 8: Paquete de Controladores 81
Ilustración 9: Paquete de Usuario 82
Ilustración 10: Paquete de negocio 83
Ilustración 11: Paquete de acceso 84
Ilustración 12: Secuencia Gestionar Perfiles 85
Ilustración 13: Secuencia Realizar Solicitud de Acuerdo 86
Ilustración 14: Secuencia Gestionar Aprobaciones de Acuerdos 87
Ilustración 15: Secuencia Elaborar Especificaciones de Proceso. 88
Ilustración 16: Secuencia Realizar transacciones 89
Ilustración 17: Diagrama de componentes 90
INTRODUCCIÓN
Las TICs han servido para solucionar diversos campos de la vida cotidiana, desde software ajustado a los procesos de negocio de una empresa hasta los que controlan y sirven para dirigir diversas organizaciones.
Un caso particular de solución es la implementación de los negocios electrónicos, con los cuales se han logrado diversos desarrollos con nuevas tecnologías computacionales que permiten el intercambio de productos, ya sean físicos o virtuales, por medio de métodos y arquitecturas las cuales se enfocan en la relación negocio a negocio o negocio a cliente. Sus beneficios son diversos en cada implementación entre los que se destacan: la optimización del rendimiento en las transacciones, lograr reducir los costos en la implementación del sistema y una comunicación sin interrupciones entre los actores del negocio (Hayashi & Mizoguchi, 2003, p. 2). Paralelo a esto se han realizado modelos electrónicos que cumplen las funciones para implementar los flujos de trabajo necesarios para el proceso de negocio, entre ellos se encuentran estándares basados en normas internacionales que permiten controlar, regular y lograr la comunicación entre las partes del negocio llegando a acuerdos técnicos que detallan las funciones y roles de cada actor (Hayashi & Mizoguchi, 2003, p. 2).
aplicación ha reducido los tiempos de comunicación e implementación de modelos que permitan a las instituciones realizar colaboraciones entre ellas, además, durante su desarrollo se han complementado con modelos de seguridad en la comunicación que permiten que la privacidad, confiabilidad y propiedad de la información este asegurada (Jung, Sudhakar, Lee, & Koh, 2007, p. 3).
1. PLANTEAMIENTO DEL PROBLEMA
1.1 DESCRIPCIÓN DEL PROBLEMA
En las instituciones de educación superior ubicadas en Bogotá, Colombia, el proceso para solicitar proyectos de grado requiere la realización de un convenio interinstitucional en el cual se especifiquen las condiciones de préstamo y uso de la propiedad intelectual generada por cada centro educativo, posterior a su verificación se debe diligenciar un formato en el que se realiza la solicitud del recurso, es necesario adjuntar la aprobación de la institución educativa a la cual pertenece el solicitante y los motivos para los que se pide el medio de información, esta actividad se realiza mediante un formato que se diligencia manualmente y se radica en la entidad propietaria del elemento. Por último, la institución propietaria del material evalúa y decide las condiciones para realizar el préstamo.
A nivel de universidades privadas, el proceso para el préstamo de trabajos de grado es largo y comienza con la búsqueda del recurso en las bibliotecas de la universidad propietaria, el solicitante se debe acercar directamente al claustro académico y solicitar la búsqueda del documento, este proceso puede durar entre uno y cinco días hábiles según el caso (Unimedios, p. 1), posteriormente se verifica la vigencia del convenio interuniversitario, si la respuesta es positiva la institución universitaria propietaria pide una autorización a la institución del solicitante, en caso contrario, se procede a realizar el convenio por medio de una negociación entre las instituciones relacionadas. Por último, después de la notificación de aprobación del préstamo, el solicitante debe acercarse a la institución propietaria del documento y consultarlo dentro del claustro ya que no es permitido extraerlo del lugar.
1.2 FORMULACIÓN DEL PROBLEMA
2. OBJETIVOS DE LA INVESTIGACIÓN
2.1 OBJETIVO GENERAL
Diseñar un modelo software que permita el intercambio electrónico de documentos trabajos de grado aplicando procesos de negociación electrónica para facilitar su acceso y consulta.
2.2 OBJETIVOS ESPECÍFICOS
• Estudiar los modelos de negociación electrónica mediante revisión de estándares y especificaciones internacionales para definir el que mejor se adecue al intercambio de trabajos de grado.
• Determinar las condiciones para que las instituciones puedan realizar intercambio de documentos de grado mediante transacciones electrónicas para facilitar su acceso y consulta.
• Diseñar un modelo software que permita el intercambio de documentos de grado, bajo las especificaciones de negocios electrónicos con el fin de ser realizadas sin la operación permanente de agentes humanos.
3. JUSTIFICACIÓN
El impulso de las tecnologías de intercambio de datos por medio de redes han revolucionado la forma de realizar transacciones y generando modelos de negocio basados en intercambios virtuales. Entre las diversas implementaciones se publicaciones en bases de datos especializadas, permitiendo a las organizaciones participantes acceso a la información en menor tiempo y sin restricciones geográficas.
Los trabajos de grado son un componente importante de la producción intelectual de las instituciones educativas, su desarrollo se basa en proyectos que mejoran los métodos tradicionales o realizan una innovación a metodologías comúnmente utilizadas; en estos documentos se definen productos y servicios que, si pueden ser accedidos de manera ágil ayudarían a las empresas e industrias a mejorar diversos aspectos de su competitividad.
necesidad para las instituciones educativas ya que su consulta permite un avance científico y tecnológico en las diferentes áreas de conocimiento. No obstante, cada institución se especializa en una rama de conocimiento, razón por la cual se hace necesario realizar intercambios entre instituciones para que los estudiantes puedan consultar trabajos de grado de cualquier unidad académica respetando la propiedad intelectual de cada institución y así lograr mejorar los desarrollos y evitar que los estudiantes realicen proyectos iguales o similares a otros ya planteados, sin lograr un avance significativo en el desarrollo científico o tecnológico.
Existen diversos métodos para la conservación de la propiedad intelectual entre ellos se encuentran los modelos de negocio electrónico que complementan la teoría de negocio con las tecnologías computacionales, en ellos, el intercambio electrónico de datos se hace protagonista pues permite realizar comunicaciones y documentos que pueden ser accedidos desde cualquier elemento del entorno y que son capaces de controlar las variables acordadas. En este proceso es necesario automatizar y generalizar la forma de uso y acceso a los documentos por medio de estándares que se adapten a los modelos de negocio actuales y que permitan la difusión inmediata a todos los interesados.
4. ALCANCES Y LIMITACIONES
4.1 ALCANCES
El presente proyecto contempla la realización de un modelo de intercambio de trabajos de grado basados en una investigación de los principales modelos de negocio electrónico de datos. Dentro de la investigación se contempla realizar cuatro estudios: exploratorio, descriptivo, correlacional y explicativo.
El estudio exploratorio comprende la investigación del modelo de intercambio de trabajos de grado actual dentro de las instituciones de educación superior en Bogotá, y los principales estándares de negocio electrónico que pueden llegar a una implementación para construir la solución al problema. Como resultado se debe obtener: la identificación de los estándares y modelos de negocio electrónico, identificación del problema en instituciones de Bogotá y descripción de las principales propuestas y modelos de negocio determinando sus principales ventajas, desventajas y escenarios donde han sido aplicados.
El estudio descriptivo comprende la especificación detallada (descripción de las propiedades, características y rasgos importantes) del problema a nivel de universidades públicas. Como resultado se debe obtener los datos, actores involucrados así como la descripción de las dimensiones que tiene el intercambio de trabajos de grado y procedimiento requerido en la realización de acuerdos de colaboración a partir del estudio efectuado en tres instituciones públicas.
y prueba de la hipótesis analizando las características, procesos y condiciones del intercambio de trabajos de grado y la forma en que pueden ser adaptadas los procesos y funcionalidades de las propuestas de modelo de negocio electrónico.
El estudio explicativo toma como base el estudio correlacional y delimita las variables y características de factibilidad para definición del diseño y desarrollo del prototipo. Como resultado se obtienen: las vistas que describen el modelo de intercambio y su aplicación en las instituciones públicas, la definición de la arquitectura y el desarrollo de software modular que comprende los siguientes componentes:
• Gestor de perfiles el cual se divide en dos subcomponentes, el primero se encarga de la interpretación de etiquetas XML las cuales identifican la información de los perfiles de usuario y validan la misma mediante formularios web que permiten un manejo transparente de la construcción e identificación de etiquetas; el segundo subcomponente es el creador de perfiles de usuario en el cual, con la información planteada, se busca generar el perfil de la institución.
• Generador de acuerdos de negocio encargado de la generación de los acuerdos de negocio entre las partes involucradas. Este documento se genera automáticamente uniendo los perfiles de las instituciones. La interfaz de usuario permite la edición del documento a las instituciones participantes así como la validación y generación de la especificación en XML.
nodos, un árbitro que contiene las interfaces principales del registro que incluyen los perfiles de las entidades, acuerdos y documentos de negocio que pueden ser consultados según la configuración de permisos de usuario. Los otros nodos son clientes que pueden consultar, según la necesidad, los documentos del árbitro.
• Módulo de intercambio de servicios interinstitucionales, este modulo se encarga de presentar al usuario el modelo del negocio por medio de interfaces hacia la aplicación.
• Módulo de presentación de resultados de la consulta, presenta los documentos a la institución que solicite el servicio restringiendo la descarga y copia para mantener los derechos intelectuales del propietario, además se encarga de verificar los acuerdos de negocio y restringir el servicio cuando los acuerdos son terminados o interrumpidos.
4.2 LIMITACIONES
Por el enfoque en la funcionalidad del prototipo no se trabajan los protocolos de seguridad del mismo, contempla únicamente el proceso de negocio a nivel de intercambio de trabajos de grado.
ejecutados.
El servidor de registro se debe acceder mediante redes privadas ya que no se cuenta con un puerto de salida registrado para su implementación, por lo tanto la solución se realiza en redes sin dominio público registrado.
La información sobre los modelos de negocio electrónico se basa en publicaciones en revistas científicas y documentación de los estándares suministrados por sus creadores que se puedan encontrar en los sitios web oficiales de cada definición.
Las consultas sobre intercambios de trabajos de grado se realizan sobre documentos oficiales de las instituciones públicas de Bogotá a los cuales se puede obtener acceso mediante los sitios web de cada entidad y procedimientos publicados en internet por vivencias empíricas realizadas por estudiantes pertenecientes a estas instituciones; por lo tanto la solución está basada en los procedimientos consultados que puedan ser implementados por estas instituciones.
Los modelos de negocio electrónico requieren la elaboración de un perfil institucional, el cual debe ser establecido por la junta directiva de cada centro académico, por lo tanto se realiza la solución con modelos de perfiles que se acoplen al problema, estos son creados por el autor basado en la información suministrada y encontrada en los sitios web de cada institución educativa.
5. MARCO REFERENCIAL
5.1 MARCO HISTÓRICO
Según la investigación realizada por el instituto de investigación científica e industrial de la universidad de Osaka y la corporación UL Systems, la implementación de los estándares de negocio y su relación con el intercambio electrónico de datos han permitido realizar modelos que se adapten a las necesidades de realizar negocios de las entidades, brindando un valor agregado al intercambio de documentos de negocio en las transacciones entre empresas. Un ejemplo de ello es el proyecto VALUE realizado desde el año 2003 en donde se propone un modelo para que las empresas de la industria japonesa puedan realizar envío y recepción de documentos de negocio (Hayashi & Mizoguchi, 2003, p. 4).
La aplicación más importante del modelo VALUE es el proyecto de integración Kasumi, fue realizado por una cadena de supermercados la cual posee más de 1000 proveedores y consiste en brindar facilidades para negociar los productos, sus características, precio y descripción. El modelo presentó resultados favorables permitiendo a los proveedores registrar su producto y realizar un plan de mercadeo en el cual se incluían las características presentadas en los documentos enviados al supermercado (Hayashi & Mizoguchi, 2003, pp. 462–464).
Por parte de las instituciones educativas la universidad de Zagreb localizada en Croacia ha realizado investigaciones enfocadas en estándares que utilicen
acuerdos electrónicos ya que permiten resolver problemas de comunicación y permiten optimizar el tiempo para realizar negociaciones (Jianni, 2009, p. 614), otro de los beneficios presentados es la arquitectura presentada que se compone de un servidor de registro y un cliente los cuales fueron usados en el proyecto “Economía en red” promovido por ministerio de ciencia y tecnología de Croacia (Topolink, Pintar, & Matasic, 2003, p. 556).
Dentro de las investigaciones se puede encontrar un estándar predominante para realizar las transacciones negocio a negocio, e-Bussiness XML el cual se ha convertido en la primera opción para implementar las transacciones ya que permite la interacción y entendimiento de los documentos por su estructura y facilita la comunicación y el compartimiento de información entre las entidades mediante el desarrollo de un software que permite crear perfiles de entidades por medio de interfaz gráfica de usuario (Vrhoci, Jarmila, & Đelmiš, 2009, p. 6).
5.2 NEGOCIOS ELECTRÓNICOS
5.2.1 BUSINESS-TO-BUSINESS
El medio utilizado para realizar acuerdos de negocio electrónicos se produce en 1970, en donde se introdujo un modelo llamado Bussiness-to-bussiness (B2B) el cual hace referencia a las transacciones comerciales utilizando tecnología para enviar documentos como pedidos de compra o facturas. B2B ha impulsado la creación de transacciones electrónicas y de agrupaciones de empresas en portales que permiten a los interesados negociar en mejores condiciones. La particularidad más importante de B2B es que establece relaciones entre proveedores, mas no se introduce en el comercio proveedor-cliente final (Bussler, 2002, p. 6).
La arquitectura definida por B2B consiste en un conjunto de elementos que interactúan entre si. Para su funcionalidad se requiere que se implemente la siguiente funcionalidad (Bussler, 2002, p. 2):
• Definición de los eventos: Se definen como las acciones que se deben realizar para completar una transacción. Pueden ser ordenes de comprar, pedidos, solicitud del catalogo de productos, etc.
• Definición del protocolo para hacer visible a todas las partes: El protocolo usado para que las partes conozcan cada paso en las transacciones. Pueden ser mensajes de acknowledge que se respondan después de cada evento.
• Definición de la seguridad para el paso de mensajes. • Conexión de la red para las partes.
• Un contrato o acuerdo realizado por las partes que defina las reglas del negocio.
Para la aplicación de las características enunciadas anteriormente se requiere crear un conjunto de elementos en donde se encuentre la gestión del negocio. Estos elementos deben contener procesos para la validación y el envío de eventos entre las partes, para esto se debe definir un elemento que valide los tipos de documento enviados entre si y la semántica que tienen que tener cada uno de ellos. También se debe tener en cuenta un elemento que gestione la secuencia de las transacciones y le haga saber a cada parte en qué punto de la negociación se encuentra. El tercer elemento debe ser el empaquetado de los mensajes y el protocolo de transporte que se usará para su envío y recepción, y por último se debe definir un elemento que maneje la seguridad del negocio (Bussler, 2002, p. 4).
Los elementos se deben definir en capas e interacción entre ellas como lo muestra la siguiente tabla:
de los servicios endpoint.
Dentro de los beneficios de B2B se encuentran la rapidez y seguridad de las comunicaciones ya que existen estándares que regulan el movimiento de los documentos y sus protocolos de seguridad, integración directa de los datos de la transacción en los sistemas informáticos de la empresa, posibilidad de recibir mayor número de ofertas o demandas por la posibilidad de publicación de información en portales informáticos y una de las más importantes es la reducción de costos ya que permite realizar negocios sin la necesidad de visitas comerciales, procesos completos de negociación y tramites asociados al negocio (Yan & Fong, 2007, p. 5).
5.2.2 TÉRMINOS COMUNES.
Para lograr los estándares e implementar el modelo B2B, desde la salida del intercambio electrónico de datos, se ha buscado modelar los negocio de tal manera que se vuelva un proceso automatizado y sin la intervención de agentes humanos. Actualmente los estándares más importantes utilizan la integración del intercambio electrónico con las etiquetas XML para lograr acuerdos en menor tiempo y que utilicen perfiles y documentos en donde se validen las reglas del negocio, a su vez que todos los actores tengan acceso a la información del acuerdo (“Estándares de Negocio Electrónico,” Laura Grande Perez p. 15).
Dentro de los estándares actuales se han definido términos comunes que abarcan una gran parte de los modelos, dentro de estos términos se encuentran:
el mismo.
• Acuerdo: Planteamiento entre dos partes que especifican las condiciones sobre las cuales se hará un tratado (términos de compra, términos de pago, protocolos de colaboración, etc.).
• Negocio: Serie de procesos, con un propósito claramente entendido para cada uno, que envuelve a más de una organización, realizados a través del intercambio de información y dirigido hacia alguna meta común, extendiéndose en un periodo determinado de tiempo.
• Librería de negocio: Repositorio de especificaciones de procesos y objetos de negocio dentro de una industria, además de los documentos compartidos por un conjunto de industrias.
• Actividad de negocio: Usada para mostrar los procesos de negocio de una de las partes del mismo.
• Colaboración de negocio: Actividad conducida entre dos o más partes con el propósito de lograr una salida.
• Conocimiento de colaboración de negocio: Conocimiento que envuelve a una colaboración.
• Contexto de negocio: Define un contexto en el cual un negocio tiene que emplear la información de una entidad.
• Documento de negocio: Conjunto de componentes de información que son intercambiados como parte de una actividad de negocio.
• Esquema de especificación de procesos de negocio: Define el conjunto de elementos necesarios para especificar aspectos en el transcurso del negocio y los parámetros de configuración para manejar los sistemas asociados usados en la colaboración.
• Regla de negocio: Reglas, regulaciones y practicas para negocios.
• Compromiso: Obligación de realizar un evento económico en un punto en el futuro.
• Contrato económico: Subtipo de acuerdo entre dos tipos de socios que van a hacer intercambios económicos en el futuro.
• Evento económico: Transferencia de un recurso económico entre dos partes.
• Negocio electrónico: Término genérico que cubre la definición de información e intercambio de requerimientos dentro y entre dos empresas por medios electrónicos.
• Comercio electrónico: Realizar negocios electrónicos, esto incluye compartir estándares no estructurados o información estructurada de negocio por cualquier medio electrónico.
• Intercambio electrónico de datos: Intercambio automático de datos estructurados y predefinidos para negocios, esto incluye la información de dos o más organizaciones.
• Servicio de mensaje: Framework que habilita el intercambio interoperable y seguro de mensajes entre dos socios.
• Parte: Entidad como una compañía, departamento, organización, etcétera, que puede generar, recibir, enviar o modificar documentos.
• Especificación del proceso: La especificación del proceso debe ser usada cuando el software que compila el ebXML está especificado para ejecutar colaboraciones de negocio, se puede definir como una interface de servicio de negocio.
entre un sistema computación a otro.
5.3 ESTÁNDARES DE NEGOCIO ELECTRÓNICO.
Todos los frameworks para intercambio de datos electrónicos tienen su base en EDI el cual permite un intercambio electrónico para el envío de documentos normalizados entre los sistemas informáticos que participan en una relación comercial. Su lógica se basa en los documentos normalizados, ya que se tiene un lenguaje común que se puede integrar con los sistemas internos de gestión (Choi et al., 2009, p. 2).
Existen diversas aplicaciones de modelos de negocio electrónico que aplican el modelo B2B para realizar negociaciones, herramientas que se han creado para asegurar el envío de documentos entre las entidades, entre ellas están RossetaNet, BizTalk y ebXML.
5.3.1 ROSSETANET
entre ellos. RossetaNet se enfoca solamente en la interacción de la información mas no se enfoca en los detalles estructurales técnicos de la misma (cómo se envía, protocolos, aceptaciones, validaciones,etc.).
Las transacciones de RossetaNet son directamente entre los actores del negocio, para sus transacciones designa dos diccionarios, uno técnico y uno de negocio. El diccionario de negocio define los términos referentes a las transacciones entre los actores. El diccionario técnico define la descripción de los productos y los servicios de objetos de las transacciones (Dogac et al., 2002, p. 3).
Otro elemento del RossetaNet son los partner interface process (PIP) , aquellos definen los procesos de negocio que se dividide en 8 elementos o clusters los cuales describen las acciones entre los actores comerciales del proceso. Entre ellos se destacan (Feuerlicht, 2011, p. 4):
• Funcionalidades administrativas. • Socios, productos y servicios. • Información de producto. • Gestión de pedidos. • Gestión de almacenes. • Información de marketing. • Servicio y soporte.
• Fabricación.
5.3.2 BIZTALK
Microsoft también crea un producto para los fines de negocio, llamado BizTalk dividido en tres partes esenciales:
• Una parte web en donde se muestra el producto y tiene una interfaz para promocionar y vender el software; esta iniciativa actualmente ha implementado las nuevas tecnologías como Windows Azure para trabajar con integración y computación en la nube (Laura Grande Pérez, p. 20).
• La segunda parte es el framework de BizTalk en el cual, basado en XML se describen los formatos y las generalidades de los intercambios de información empresarial, este es el que se puede comparar con los frameworks anteriores ya que es el que lleva toda la documentación y las especificaciones de negocio. Este framework soporta integración de aplicaciones empresariales, automatización de procesos empresariales, modelado de procesos de negocio, comunicación negocio a negocio y agentes de mensajería. Todo este desarrollo se ha hecho mediante las versiones de Visual Studio («Deployment Framework for BizTalk (BTDF) – Documentation»,pg. 6).
soluciones y mejorar la interoperabilidad entre las empresas el primero tiene integración con soluciones propuestas de IBM y se puede desarrollar rápidamente los componentes (Laura Grande Pérez, p. 21).
5.3.3 E-BUSSINESS XML
En el año 2001 se crea una nueva herramienta abstracta para la realización de negocios por internet llamada “Electronic Business Extensible Markup Language(ebXML)”, la cual se crea con la función principal de eliminar documentos escritos en físico, reducir los costos y aprovechar la eficiencia de los productos EDI. A través de esta herramienta se simplifican los procesos de negocio para las empresas y para el intercambio de servicio entre ellas, para el uso del modelo B2B.
La construcción de este modelo fue propuesta y establecida por UN/CEFACT y la
OASIS en donde se trabajó de 15 a 18 meses (UN/CEFACT,OASIS, 2001, p. 7).
El objetivo con el que se realizó el proyecto fue dar a la comunidad un framework compatible con XML para crear un mercado simple global en el cual se hagan intercambio de negocios virtuales, esto incluiría interacciones entre aplicaciones, entre humano y aplicación y mejora los procesos de negocio implementados en el mercado electrónico simplificando los recursos y proporcionando una solución a los negocios globales (UN/CEFACT,OASIS, 2001).
modelos con los cuales se puedan generar, validar y desplegar los modelos y variables del negocio. Además permite realizar atributos a los objetos creados y definirle propiedades que pueden ser especificaciones del negocio.
El equipo de desarrollo del ebXML logró especificar su arquitectura bajo las normas ISO en las cuales se definen los estándares para la creación de los diferentes documentos que tienen que ver con las variables del negocio y definen las estructuras XML que debe llevar cada uno, las normas son («ebXML - Enabling A Global Electronic Market», pg 25) :
• ISO 15000-1: ebXML Collaborative Partner Profile Agreement • ISO 15000-2: ebXML Messaging Service Specification
• ISO 15000-3: ebXML Registry Information Model • ISO 15000-4: ebXML Registry Services Specification
• ISO 15000-5: ebXML Core Components Technical Specification, Version 2.01.
Estas especificaciones permiten definir los documentos, actores, y elementos que van a interactuar y los roles que cumple cada uno.
compartir su información de negocio, en ellos se tienen las interfaces de servicio y las principales configuraciones técnicas de transporte, seguridad y codificación de los protocolos; el cuarto elemento es un mecanismo usado para describir los acuerdos mutuos de las partes en el negocio, este tiene que ser un meta modelo que se pueda extraer de los perfiles de cada uno de los participantes; y por último, un estándar para el intercambio de mensajes que permita identificar los procesos de intercambio y así asegurar su confiabilidad, interoperabilidad y confianza en los modelos de negocio (Hayashi & Mizoguchi, 2003, p. 2).
Entrando en detalles, la infraestructura de ebXML se define por la Ilustración 1 en la cual se encuentran los pasos para realizar el negocio a un nivel abstracto, entre ellos hay varios elementos que destacar, todos ellos tienen que ver con los cinco
conceptos que se definieron en el párrafo anterior, el primero es el estándar de los procesos de negocio y modelos de información, lo podemos encontrar en los
businessScenarios y business Profiles dentro de los cuales se puede ver que pertenecen a meta modelos en donde se define el proceso de negocio. El segundo elemento es el registro (ebXML Registry) el cual se encarga de hacer el registro de los perfiles de las compañías y realizar la base de datos de los documentos de negocio que se construyen entre diferentes empresas (Topolink et al., 2003, p. 3). Dentro del tercer elemento se define el negocio y está compuesto por los perfiles, acuerdos y documentos de mensaje, los perfiles son elementos en los cuales se definen los protocolos y configuraciones que ofrece una compañía para poder interactuar con ella, los acuerdos son la definición del negocio que se hace entre dos compañías compatibles con los perfiles de los dos socios y documentos de mensaje son los que establecen la interacción entre las dos compañías dividas en los roles que tienen cada una en el proceso. El cuarto elemento será el conjunto de documentos hechos con meta modelos que se generen a partir del negocio, estos se podrán consultar en el registro. El último elemento es la interacción entre mensajes en él se define un estándar con los mensajes y viene definido en uno de los documentos de negocio (Jianni, 2009, p. 2).
En la Ilustración 1 se pueden observar los pasos para realizar el negocio en este elemento, cada número representa los elementos mencionados en el párrafo anterior y cómo es la interacción entre ellos.
La capa de gestor de protocolos es un componente que se encarga de ejecutar los protocolos definidos en los esquemas de aplicación de B2B; dentro de sí se encuentran dos elementos para hacer efectivo el proceso, el primero se encarga de la ejecución de procesos definidos por el acuerdo de negocio y el segundo se encarga de transportar los documentos de conocimiento por si alguna de las entidades los requiere (Bussler, 2002, p. 4).
El gestor de eventos se encarga de gestionar los documentos y su interacción en el negocio, este a la vez se divide en dos subcomponentes, el primero es el encargado de verificar los tipos de documento que se envían en el negocio, estos pueden llegar a ser desde una factura hasta una orden de compra y son requeridos por las entidades entre las que se ejecuta el proceso; y el segundo subcomponente se encarga de verificar la semántica de los documentos que son enviados y recibidos por las partes del negocio (Bussler, 2002, p. 4).
El gestor de transporte es el responsable de enviar y recibir los eventos y asegurar el empaquetado y los detalles de transporte de los mismos. A su vez va acompañado de la capa de transporte la cual se encarga de escoger el protocolo y los detalles sobre el canal de la comunicación de los eventos.
El gestor de base de datos se encarga de guardar los documentos y definiciones basados en la especificación de cada proceso de negociación, en el caso de ebXML se realizan en documentos XML.
5.3.4 ANÁLISIS DEL MARCO REFERENCIAL
En la Tabla 1 se relacionan las características principales de los frameworks que serán de utilidad para el desarrollo del proyecto, de la cual se selecciona el estándar de ebXML por poseer los siguientes elementos relevantes:
• Es un estándar que incluye las generalidades para realizar negocios electrónicos sin entrar al detalle, lo cual permite mayor versatilidad en su manejo.
• Posee un servidor de registro que realiza la verificación de los contratos y transacciones realizadas por las instituciones educativas dejando transparente la verificación y control.
• Tiene un nivel alto de abstracción lo cual permite adaptarlo para formular el modelo y generar características específicas del mismo.
Tabla 2: Comparación frameworks de negocio interoperabilidad de las empresas.
Definición de perfiles de negocio
Se definen mediante CPP. Se definen por medio de los PIP.
Perfiles de usuario servidor.
Definición de transacciones de negocio
Se define mediante CPA Se definen por diccionarios técnicos y diccionarios de negocio
Incluido en los perfiles de software.
Almacenamiento El almacenamiento se da especificaciones de los documentos ya que no se
Intercambio de mensajes El intercambio de mensajes viene dado por permite realizar diversas implementaciones y productos específicos de microsoft.
Fuente: El Autor
6. METODOLOGÍA 6.1 TIPO DE ESTUDIO
El tipo de estudio del proyecto es investigación y desarrollo tecnológico ya que se realiza la aplicación del método científico sobre los estándares de negocio electrónico actuales para proponer un modelo que permita facilitar la negociación entre las instituciones de educación superior para lograr el intercambio de objetos trabajo de grado entre ellas. Además se realiza el desarrollo de un prototipo basado en la metodología iterativo incremental y el proceso unificado de software para lograr demostrar la implementación del modelo y su funcionamiento.
6.2 PERIODO Y MUESTRA DE LA INVESTIGACIÓN
La investigación se realiza en Bogotá, Colombia, incluyendo a las principales universidades públicas de la ciudad y la generalidad de los casos de las universidades privadas. Se consultó al sistema nacional de bibliotecas y a los repositorios institucionales en la ciudad con el fin de encontrar los procedimientos necesarios para realizar la negociación de los convenios interinstitucionales para la consulta de trabajos de grado.
Este estudio se realiza entre los años 2015 y 2016.
6.3 TÉCNICA METODOLÓGICA
La técnica metodológica de este proyecto se basa en el método científico y el proceso unificado de Ingeniería de Software;
6.3.1 ETAPA DE OBSERVACIÓN
La aplicación de método científico comenzó con la etapa de observación de los intercambios de trabajo de grado entre instituciones de educación superior, esta observación se realizó sobre las universidades más representativas de Bogotá, tomando casos de universidades públicas y privadas. La observación incluye la generalización de los intercambios entre cada tipo de instituciones, además de verificar la existencia de convenios interuniversitarios que permitan este tipo de transacciones.
Como segundo aspecto se realiza un estudio de los principales métodos de negocios electrónicos que se puedan aplicar al modelo de intercambio, buscando evidenciar el cumplimiento de las características necesarias para la ejecución del proyecto aplicando estándares verificados en otras aplicaciones. El resultado de esta fase será un informe de las instituciones de educación superior y la documentación de la metodologías posibles para el intercambio electrónico de datos.
6.3.2 ETAPA DE INDUCCIÓN
cuenta características específicas y considerando las experiencias particulares para lograr una generalización de los problemas evidenciados en cada entidad. Se realizó una selección preliminar de los métodos de negocio electrónico más representativos y que sean acordes a los requerimientos del proyecto. El resultado de esta fase fue la elección de tres modelos de transacción electrónica y un documento en el cual se hable de las deficiencias en los modelos de intercambio en las instituciones de educación superior y una identificación clara del problema.
6.3.3 FORMULACIÓN DE LA HIPÓTESIS Y EXPERIMENTACIÓN
Para la formulación de la hipótesis se tuvo como objetivo el planteamiento de la solución al problema mediante los datos recolectados y la información que resultó de las fases anteriores. Al terminar la fase se definió la hipótesis, además se obtuvo el modelo de transacción electrónica y su especificación del proyecto.
A través de la experimentación se obtienen herramientas que harán efectivas el desarrollo del prototipo de software para el intercambio de trabajos de grado en instituciones de educación superior. En esta se ve reflejada la construcción del prototipo mediante la metodología RUP de Ingeniería de Software y en cada una de sus fases se encuentran implícitamente presentes las metodologías complementarias de Bases de Datos que son el diseño conceptual, el diseño lógico y el diseño físico.
6.3.4 METODOLOGÍA DE INGENIERÍA DEL PROYECTO
realizará en paralelo con las fases anteriores del método científico, con este proceso ya se tienen los datos diferenciados para la investigación y los datos necesarios para el desarrollo del software.
Para la construcción, la metodología especifica 4 fases dentro de las cuales estuvo contemplado el desarrollo del presente proyecto. dentro de ellas se definieron los hitos que componen la construcción del modelo, ellos se especifican a continuación:
• Iniciación: La fase de iniciación se efectuó en un hito en el cual se obtuvo la información para ejecutar el proyecto, primero se consultó el procedimiento necesario por cada institución educativa para el préstamo de trabajos de grado, de ello se logró identificar las características comunes entre las entidades para lograr el préstamo y los elementos necesarios para poder realizar el negocio. También se realizó una depuración de los estándares de negocio electrónico que utilizan el modelo B2B e implementan un acuerdo para la prestación de servicios. Esta depuración se obtuvo contrastando los elementos encontrados en las instituciones con los beneficios que trae cada estándar.
El segundo hito comprendió el análisis y diseño; se definieron los componentes que integran el proyecto basado en los modelos de negocio, además de la interacción que tendrá cada uno de ellos con el cliente final, de él se adquirieron los diagramas más representativos que ayudaron a la construcción del software y que plasmaron su funcionalidad, la interacción de actividades y secuencias que tiene el prototipo.
• Construcción: La fase de construcción contempló dos hitos para el desarrollo del prototipo en los cuales se aplicaron los modelos del análisis y diseño que permitieron la generación de las funcionalidades del aplicativo. El primer hito fue el desarrollo por componentes de cada uno de los principales casos de uso del aplicativo; una vez finalizados, se inicia el segundo hito con la integración de los componentes de la aplicación, el desarrollo de las funciones dependientes entre ellos y los detalles gráficos de usuario que permitían acceder a la funcionalidad.
• Transición: En esta fase se realizaron las pruebas y controles al producto final y se completaron las primeras listas de chequeo de las funcionalidades del mismo. Normalmente la implementación hace parte de esta etapa, pero debido a que este es un prototipo, tan solo se tendrán en cuenta los casos de uso establecidos en la etapa de Inicio. Se realizará la documentación del prototipo y se presentará un ejemplo del mismo.
fueran acordes a los planes y requerimientos planteados en las primeras etapas.
7. DEFINICIÓN DEL MODELO
Los estándares estudiados permiten realizar una especificación para la creación de un modelo que facilite el intercambio de trabajos de grado entre instituciones de educación superior, la motivación para su realización radica en la negociación entre las entidades y los beneficios que se pueden obtener con cada transacción.
El modelo se basa en la aplicación del estándar ebXML dentro del cual se logra una mejora en los procesos de negociación entre industrias ya que permite una especificación de las transacciones y de los productos, elementos que facilitan el acceso a la información de la empresa con que se quiere negociar (Yan & Fong, 2007, p. 4).
7.1 CARACTERÍSTICAS DEL PROCEDIMIENTO DE INTERCAMBIO
Para realizar el intercambio electrónico se deben definir una serie de características que permitan realizar un convenio legal entre dos entidades que realizarán el negocio. Para ello, diversos estándares implementan los parámetros básicos para realizar contratos válidos y con los cuales se tenga confianza sobre la inversión que se está realizando. Para ello el modelo propuesto se basa en la arquitectura de B2B para confirmar la validez del proceso y tener una base legal e histórica acerca de las transacciones que se realizarán.
en documentos que cumplan los siguientes parámetros:
• Identificación de la institución: Un registro que identifique la institución y facilite su búsqueda. Un ejemplo es el Sistema Universal de Numeración de datos (DUNS) (“D-U-N-S Number,” p. 1) o los registros que se utilizan en cada país para las empresas, en el caso Colombiano el Número de identificación tributaria (NIT) (“Dirección de Impuestos y Aduanas Nacionales de Colombia,”, p. 1).
• La referencia de la institución: Es un documento que presenta información relacionada con los objetivos, misión, visión y detalles de la institución, con el fin de que las entidades conozcan las particularidades de la compañía con la cual se realizará el negocio.
• Rol que cumplirá la institución: Se debe definir qué rol cumplirá la institución dentro del negocio. Una institución puede cumplir diversos roles en las transacciones (Comprador, Vendedor).
• Certificados: Son las normas de seguridad que se utilizarán o requerirá la institución durante las transacciones.
Como segunda característica para el modelo se debe definir un contrato o acuerdo realizado entre las partes que defina las reglas del negocio. Este contrato será un documento que deberá cumplir con los siguientes parámetros:
• Fechas de validez del acuerdo: Define el intervalo de tiempo especificando la fecha inicial y la fecha final del acuerdo.
• Límite de invocación: Número de transacciones que se realizarán por acuerdo.
los estudiantes en el mismo momento.
• Comentarios: Es una nota textual para describir elementos que acoten el documento.
Acompañando al contrato se debe definir la tercera característica que es la definición de los eventos, estos son acciones que deben realizar las partes para poder completar una transacción; un ejemplo de ellos son las órdenes de compra, los catálogos de producto, los pedidos, etc.
La cuarta característica que debe tener es la definición de la seguridad de los mensajes y los canales de comunicación que debe usar para transportar los documentos; esto se puede realizar por medio de protocolos que deben ser visibles e implementados por las partes.
Para poder realizar el modelo, además de las características mencionadas anteriormente, cada institución educativa debe realizar una implementación para gestionar los documentos, dentro de ella debe existir un modulo de comunicación con el árbitro, el cual será un actor principal dentro del modelo en el que se encuentra la información de: los contratos, las transacciones y el detalle de cada una de ellas. Las interfaces de comunicación con las que debe contar la implementación realizada por cada ente educativo, requiere cumplir los siguientes servicios:
• Consulta de usuarios registrados de otras instituciones al árbitro. • Consulta de contratos activos con otras instituciones educativas.
• Consulta de validez de acuerdos.
Dentro de las funciones del árbitro está el almacenamiento de los contratos, identificaciones y documentos relacionados, además debe tener una base única de usuarios por entidad que permita la validación desde cualquier institución. El árbitro controlará las transacciones y validaciones de los contratos y los límites que tiene cada uno. Cada institución debe informar los eventos realizados dentro de su implementación y debe solicitar la verificación de los contratos.
7.2 CARACTERÍSTICAS DEL ESTÁNDAR DE INTERCAMBIO ELECTRÓNICO
Para poder realizar el negocio electrónico entre las entidades, se utiliza un estándar que se adapte a la definición de la arquitectura B2B y que cumpla con las características del procedimiento anteriormente planteado.
Para la aplicación se utiliza el estándar ebXML ya que, además de cumplir las condiciones para implementación de la arquitectura de B2B, aplica el formato XML para los documentos del negocio lo cual facilita la lectura y escritura, identificando por etiquetas padres e hijos, las características de la arquitectura.
Para el cumplimiento de la característica de identificación del modelo, el estándar lo realiza por medio de perfiles de cada institución educativa; en ellos se identifican los datos básicos de la entidad y para su aplicación se dividen en tres grupos diferentes que forman el documento del perfil:
los certificados que se utilizarán en el negocio.
• Empaquetado: Contiene los canales de comunicación, los protocolos de transporte de mensajes aceptados por la entidad y el tipo de mensaje que se utiliza en el negocio.
• Comentarios: Incluye el empaquetado que utiliza la institución educativa para los mensajes y los comentarios del perfil.
La información que se registra en el perfil es la presentación de información y servicios que tendrá cada institución para poder realizar negocios electrónicos; esta permite que otras entidades puedan consultar y realizar propuestas de acuerdos. La información registrada es pública para todos los usuarios de la aplicación.
Una institución educativa puede tener varios perfiles con diversos roles a cumplir, y contar con diferentes perfiles para cada rol, esto brinda alternativas para realizar un acuerdo y amplía las posibles solicitudes desacoplando las dependencias de tecnología.
El cumplimiento de la característica de contratación, se realiza por medio del acuerdo, el cual es un documento-contrato que incluye: los perfiles de las instituciones y los parámetros necesarios para validar el negocio. El manejo de estos documentos se realiza por medio de estados del contrato (propuesto, aceptado, activo e inactivo), el documento además de los perfiles contiene:
• Estado.
• Intercambios simultáneos. • Comentarios.
Acompañando el contrato se tiene la gestión de los eventos, la cual se realiza por un documento llamado especificación de proceso que se compone de tres grupos de etiquetas:
• Documentos de negocio: Se especifica el documento que se utiliza en el evento (órdenes de compra, catálogo de productos, etc.) y su ubicación.
• Transacción de negocio: Se especifican los detalles del evento, los documentos se utilizan como petición y respuesta, los tiempos requeridos para ejecutar el evento y los mensajes de conocimiento para cada una de las partes.
• Colaboración Binaria: Se definen los roles involucrados en el evento, el estado antes y después de ejecutarlo así como las excepciones que se pueden presentar dentro del proceso.
Las características de seguridad y de transporte de mensajes son incluidas dentro de los perfiles y acuerdos en secciones especialmente dedicadas a ellos.
7.3 ESPECIFICACIONES DEL PROCESO DE INTERCAMBIO
Para realizar el proceso de intercambio, el presente modelo plantea un negocio entre empresas en el cual se especifique los detalles técnicos, alcance y eventos que se necesitan en la transacción de trabajos de grado con el fin que los documentos logren los conceptos para un acuerdo legal. El modelo se basa en que cada institución tenga su perfil el cual le permite realizar contratos legales de negociación electrónica, todo aplicando el modelo de B2B al proceso.
El primer elemento que se debe definir en el proceso de intercambio es el árbitro, es el encargado de guardar todos los documentos relacionados a los acuerdos y transacciones, realizar la validación y aprobación de usuarios y contener una base única de estudiantes de todas las entidades educativas registradas. El árbitro debe ser independiente de las instituciones que utilicen el modelo y le permite a todos los actores del negocio la consulta de los documentos relacionados a sus acuerdos.
Para lograr realizar la transacción, cada institución educativa debe registrar la identificación única; este procedimiento requiere que cada entidad diligencie los datos básicos y específicos de la infraestructura con la que cuenta. Para la definición del documento del perfil, la institución realiza reuniones internas en donde se definen las características que serán aceptadas en los contratos que pueda realizar. Entre la información que debe ser especificada está:
• Identificación de la institución. • Rol de la institución.
• Canales de comunicación.
• Protocolos de mensaje aceptados por la institución. • Empaquetado de los mensajes.
Aprobada la especificación de las características de las condiciones para la ejecución de contratos, la institución efectúa el registro en el árbitro mediante un documento denominado Perfil de Colaboración.
Una institución educativa puede tener diversos perfiles de colaboración, cada uno de ellos con diferentes escenarios técnicos que permitan a otras instituciones educativas seleccionar el más adecuado a sus condiciones o necesidades, por lo tanto, entre más perfiles tenga una institución, mayores posibilidades de realizar acuerdos tendrá.
Para poder aplicar el perfil de colaboración, la institución educativa debe contar con un repositorio en el cual se encuentren los trabajos de grados, acorde a los protocolos y detalles presentados en el perfil, esta implementación se comunica con el servidor árbitro para las transacciones de negocio.
Una vez creados los perfiles de colaboración de las entidades, empieza el proceso para realizar un acuerdo, en primer lugar, una institución educativa debe buscar su contraparte y comparar los perfiles de colaboración para identificar cual se acomoda a su modelo de negocio, para realizarlo debe tener en cuenta:
• El cifrado de uso de mensajes: Se debe buscar una entidad que acepte los protocolos de cifrado que la institución posee para realizar el acuerdo.
• Los protocolos de transporte y empaquetado de mensajes: Es importante que las dos instituciones cuenten y tengan habilitados los mismos protocolos o que sean compatibles.
En el momento que ya se encuentre el perfil de colaboración compatible se procede a realizar una petición de negocio, la cual se compone de dos partes importantes el acuerdo de negocio y la especificación de proceso.
El acuerdo de negocio es un documento-contrato que contiene la información principal sobre el negocio, sobre él se verifica la validez del acuerdo, los tiempos de ejecución y las transacciones válidas; el documento de acuerdo puede ser modificado por las partes mientras no esté activo, una vez lleguen a un consenso se aprueba por las dos partes. El documento aprobado debe contener la siguiente información:
• Fechas de validez del acuerdo: El negocio tendrá vigencia dentro de estas fechas y después quedará inactivo.
• Número de transacciones permitidas: Número de transacciones que se podrán realizar dentro de las fechas de validez del acuerdo.
• Intercambios simultáneos: Número de intercambios que los usuarios podrán realizar al mismo tiempo.
• Comentarios del acuerdo: Anotaciones que se realizan por cada una de las partes acotando el alcance y las características del acuerdo.
aprueba el acuerdo.
• Estado del acuerdo: Permite determinar qué institución tiene la siguiente acción de modificación sobre el acuerdo y las condiciones para establecer si el acuerdo está activo, propuesto, devuelto por cambios, rechazado o inactivo.
La especificación de negocio, como segundo componente, está constituido por un conjunto de documentos que detallan los eventos del proceso de transacción, por ejemplo, una institución define la transacción con 4 eventos para intercambiar un trabajo de grado: Petición de catálogo de trabajos de grado en donde la institución envía los documentos disponibles para consulta, orden de compra de la contraparte en donde se envía el documento a consultar y el número de copias, aprobación de la compra que implica el envío del documento solicitado y factura del envío del trabajo de grado el cual es un soporte que describe las características de la transacción efectuada. Cada evento debe ser definido en un archivo conformado por:
• Documento de transacción: Contiene la información del evento, en el caso del ejemplo: el catálogo de productos, la orden de compra, la factura.
• Transacción de negocio: Especifica los detalles del evento como los documentos de transacción y el tiempo máximo de petición y respuesta para cada petición. En el caso del ejemplo, se especifica que cuando la institución realice la petición del catálogo de productos por medio de un documento HTML, la contraparte le responde con el catálogo en formato de texto plano en un tiempo determinado.
de la transacción antes de realizar el evento, la transacción de negocio, los estados cuando finalice el evento correctamente o cuando tiene alguna excepción.
Después que la institución realice la propuesta, la contraparte recibirá una notificación del negocio y tendrá que evaluar y responder con la aprobación, modificación o rechazo. En el caso de aprobación, el negocio entra en vigencia dentro de las fechas estipuladas en el acuerdo y ninguna institución puede modificar las condiciones definidas en el acuerdo dentro de los términos del negocio.
El estudiante se debe registrar en el árbitro con validación previa de la institución educativa a la cual pertenece; una vez registrado el estudiante, podrá realizar transacciones, consultar los documentos solicitados y los acuerdos vigentes de la entidad en la que está inscrito.
Para poder realizar la transacción, el estudiante debe entrar a la implementación de la institución educativa de la cual quiere obtener el trabajo de grado e iniciar sesión con el usuario registrado en el árbitro, la institución educativa consulta con la base única de usuarios la validez del estudiante y que exista un acuerdo activo con la institución educativa. Una vez validado le presenta el catálogo de documentos para que pueda solicitar uno de ellos; una vez solicitado se producen los eventos descritos en la especificación de proceso, la institución debe notificar el inicio y fin del evento al árbitro. Una vez el estudiante obtiene el documento la institución registra el intercambio ante el servidor de registro.
8. ANÁLISIS, DISEÑO Y DESARROLLO DEL PROTOTIPO
En esta sección se realiza la presentación del análisis, diseño y desarrollo del prototipo que aplica el modelo presentado en el capitulo anterior. Inicialmente se realizó un planteamiento de los requerimientos del prototipo (funcionales, no funcionales) basados en las características del modelo.
A partir del estudio de los requerimientos se obtienen los casos de uso del proyecto para poder realizar las representaciones en Lenguaje Unificado de Modelado (UML) y se presentan los diagramas que permiten establecer la interacción y comportamiento del sistema frente a los actores principales que utilizarán el software.
8.1 REQUERIMIENTOS
La primera etapa de desarrollo de software se basa en la producción de requerimientos, su planteamiento fue realizado para satisfacer las características del modelo de negociación electrónica, iniciando con el planteamiento del negocio y finalizando con las transacciones que pueden realizar los estudiantes con otras instituciones educativas.
Como segunda etapa se realizó el reconocimiento de múltiples puntos de vista por medio de las consultas al sistema nacional de bibliotecas, bibliotecas de universidades públicas y privadas sobre el proceso (“Sistema de Bibliotecas -Sistema de Bibliotecas,” n.d.), con esto se llegó a un conjunto de características que debe tener el sistema a partir de la colaboración prestada y la información proporcionada para sus procesos de solicitud.
Durante el planteamiento se obtuvo una compilación de las características del sistema y se realizó la clasificación en requerimientos funcionales y no funcionales. En la Tabla 3 se relacionan los requerimientos del prototipo con su tipo y clasificación.
Tabla 3: Requerimientos de prototipo
ID Requerimiento Tipo
Requerimiento RequerimientoClasificación
R01 Validar usuarios otras instituciones educativas No funcional Obligatorio R02 Registrar y validar la información de perfil de la
Institución educativa Funcional Obligatorio R03 Buscar Perfiles de otras instituciones
educativas
Funcional Obligatorio
R04 Actualizar perfiles propios que no estén en
estado activo Funcional Obligatorio
R05 Mostrar los perfiles de otras instituciones
educativas para comparar Funcional Obligatorio R06 Realizar la propuesta de un acuerdo con otra
institución educativa Funcional Obligatorio R07 Crear los acuerdos aceptados por las dos
instituciones educativas Funcional Obligatorio R08 Mostrar los acuerdos activos de la institución
educativa
Funcional Obligatorio
R09 Crear especificaciones de proceso Funcional Obligatorio R10 Consultar la especificaciones de proceso de los
R11 Consultar transacciones realizadas por usuarios
de la entidad Funcional Obligatorio
R12 Registrar estudiantes de la entidad educativa Funcional Obligatorio R13 Modificar datos de usuarios de la aplicación Funcional Obligatorio R14 Mostrar documentos consultados por
estudiantes de otras instituciones educativas Funcional Obligatorio R15 Consultar disponibilidad de acuerdos Funcional Obligatorio R16 Consultar usuarios registrados de otra
institución educativa Funcional Obligatorio R17 Encriptar nombres de documentos y carpetas No Funcional Opcional R18 Consultar el detalle de los documentos
consultados por cada institución educativa Funcional Opcional R19 Registrar las consultas realizadas por usuarios
de diferentes instituciones educativas
Funcional Obligatorio
R20 Consultar usuario disponible de institución
educativa Funcional Obligatorio
R21 Inhabilitar usuarios de cada institución
educativa Funcional Obligatorio
R22 Mantener compatibilidad con navegadores
Chrome y Mozilla Firefox No Funcional Opcional R23 Bloquear modificaciones sobre documentos en
los acuerdos activos Funcional Obligatorio R24 Brindar comentarios de ayuda para el llenado
de los perfiles y acuerdos en la aplicación
No funcional Opcional
R25 Crear, cargar y modificar documentos de negocio en formato XML
No funcional Obligatorio
R26 Enviar correo de validación para el registro de
usuarios No funcional Opcional
Fuente: El Autor
Con el fin de determinar el valor de dependencia y prioridad de cada requerimiento
02 Registrar y validar la información de perfil de la institución educativa
04 Actualizar perfiles propios que no estén en estado activo
1 1 1 1 4
R
05 Mostrar los perfiles de otras instituciones educativas para comparar
1 1 1 3
R
06 Realizar la propuesta de un acuerdo con otra institución educativa
1 1 1 3
R
07 Crear los acuerdos aceptados por las dos instituciones educativas
R
08 Mostrar los acuerdos activos de la institución educativa
10 Consultar la especificaciones de proceso
de los acuerdos 1 1 1 1 1 1
6
R
11 Consultar transacciones realizadas por usuarios de
la entidad 1 1 1 1 1 1 1 1 1 1 1 1 1
14 Mostrar documentos consultados por estudiantes de otras instituciones
16 Consultar usuarios registrados de otra
institución educativa 1
20 consultar usuario disponible de otra institución
educativa 1 1 1
23 Boquear modificaciones sobre documentos en los
acuerdos activos 1 1 1 1 1
5
Prioridad Requerimientos 17 6 0 3 6 7 2 3 3 2 7 2 1 5 4 3 4 6 3 6
Fuente: El Autor
con los rangos y categorías establecidos, de la que se obtiene la relación entre
R03 Buscar perfiles de otras instituciones educativas Alto Bajo R04 Actualizar perfiles propios que no estén en estado
activo Bajo Medio
R05 Mostrar los perfiles de otras instituciones educativas
para comparar Bajo Bajo
R06 Realizar la propuesta de un acuerdo con otra institución educativa
Alto Bajo
R07 Crear los acuerdos aceptados por las dos instituciones
educativas Alto Medio
R08 Mostrar los acuerdos activos de la institución educativa Bajo Medio R09 Crear especificaciones de proceso Bajo Medio R10 Consultar la especificaciones de proceso de los
acuerdos Bajo Alto
R11 Consultar transacciones realizadas por usuarios de la
entidad Bajo Alto
R12 Registrar estudiantes de la entidad educativa Alto Bajo R13 Modificar datos de usuarios de la aplicación Bajo Medio R14 Mostrar documentos consultados por estudiantes de
otras instituciones educativas Bajo Alto
R15 Consultar disponibilidad de acuerdos Medio Alto R16 Consultar usuarios registrados de otra institución
educativa
Medio Bajo
R18 Consultar el detalle de los documentos consultados por
cada institución educativa Bajo Medio
R19 Registrar las consultas realizadas por usuarios de
diferentes instituciones educativas Medio Medio R20 Consultar usuario disponible de otra institución
