anteproyecto de gradorepository.udistrital.edu.co/bitstream/11349/4078/... · hermano juan camilo...
TRANSCRIPT
MODELO SOFTWARE PARA INTERCAMBIO ELECTRÓNICO DE TRABAJOSDE GRADO ENTRE INSTITUCIONES DE EDUCACIÓN SUPERIOR
DIEGO ALEJANDRO SIERRA ALEAN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMASBOGOTÁ D.C.
2016
MODELO SOFTWARE PARA INTERCAMBIO ELECTRÓNICO DE TRABAJOSDE GRADO ENTRE INSTITUCIONES DE EDUCACIÓN SUPERIOR
DIEGO ALEJANDRO SIERRA ALEAN
Proyecto de grado modalidad investigación
Director: JULIO BARÓN VELANDIAProfesor Facultad de Ingeniería
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMASBOGOTÁ D.C.
2016
Nota de aceptación
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
Director
_____________________________________
Jurado
Bogotá, Agosto de 2016
3
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.
A todos mi admiración, respeto y profundo agradecimiento.
4
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.1 BUSINESS-TO-BUSINESS 25
5
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.2 CARACTERÍSTICAS DEL ESTÁNDAR DE INTERCAMBIO ELECTRÓNICO 49
6
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
BIBLIOGRAFÍA 97
7
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
Tabla 17: Características Hardware Computador de usuario 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
Ilustración 18: Diagrama de despliegue 91
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).
Uno de los elementos principales de los modelos negocio a negocio son los
intercambios electrónicos, los cuales han sido importantes en el desarrollo
tecnológico desde su creación en 1970 (Feuerlicht, 2011, p. 1), por medio de ellos
es posible realizar estándares electrónicos que satisfagan la comunicación entre
los actores para lograr modelos negocio a negocio y negocio a cliente. Su
10
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).
Este documento presenta un modelo sotfware para realizar el proceso de
negociación e intercambio electrónico de trabajos de grado entre instituciones de
educación superior bajo estándares internacionales que permita a las
universidades crear, compartir y consultar las variables del negocio alojadas en
documentos-contrato que especifican los eventos para realizar las transacciones.
11
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.
Como caso representativo, a nivel de instituciones públicas, la Universidad
Nacional de Colombia para realizar el préstamo a personas externas de la
institución, solicita diligenciar un formato con el material a consultar el cual debe
ser enviado al correo electrónico del sistema SINAB (sistema nacional de
bibliotecas), la solicitud entra en vigencia cuando se presentan los formatos
diligenciados en el punto de atención ubicado en las instalaciones del claustro, allí
se verifican los documentos solicitados y se radica una carta de autorización para
la consulta del material. El proceso por parte de la universidad empieza por
constatar la existencia del convenio interuniversitario, si no existe, la junta directiva
evalúa la creación de un convenio con la institución a la que pertenece la persona
solicitante, empezando un proceso de negociación institucional que puede llegar a
durar dos meses dependiendo del caso (Sistema Nacional de Bibliotecas, p. 1).
12
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.
Como se presentó en los apartados anteriores, tanto en universidades públicas
como privadas, dentro del proceso de intercambio de trabajos de grado el usuario
debe realizar la solicitud de cada uno de los documentos que requiere consultar,
dado que todo el proceso se realiza manualmente y que el número de solicitudes
que se presentan es alto, el solicitante debe esperar largos periodos de tiempo
para su procesamiento y posterior respuesta. En todas las partes del proceso es
necesaria la asistencia a las instalaciones de la institución en los horarios de
atención definidos. Este no es un proceso al cual se tengan asignados un gran
número de recursos para su atención ya que este no se encuentra contemplado
en el ámbito misional de las instituciones.
13
1.2 FORMULACIÓN DEL PROBLEMA
¿ Cómo mejorar el proceso de intercambio de trabajos de grado entre instituciones
de educación superior de manera que pueda ser realizado de forma remota sin la
intervención de agentes humanos?
14
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.
• Desarrollar un prototipo software mediante metodologías de desarrollo por
componentes que permita evidenciar la interacción entre entidades para el
intercambio de trabajos de grado.
15
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
encuentran el modelo VALUE creado para el intercambio electrónico de
documentos en la industria japonesa, es enfocado a apoyar modelos de
intercambio negocio a negocio y optimizar el proceso de traspaso de la
información (Hayashi & Mizoguchi, 2003, p. 4). A nivel de instituciones de
educación se promueven convenios que permiten a los integrantes de las
comunidades educativas la aplicación del modelo para la consulta de
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.
Dentro de las principales investigaciones e innovaciones, existen varias que son
tomadas de los trabajos de grado ya que su requerimiento interno estimula la
capacidad de innovación basado en elementos y materiales ya existentes, en
donde el estudiante puede plasmar todo lo aprendido dentro del proceso
educativo, razón por la cual compartir estos conocimientos se vuelven una
16
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.
Los modelos de negocio electrónico permiten definir por medio de acuerdos y
perfiles las condiciones de uso del material requerido, con su implementación los
estudiantes pueden buscar la mejor alternativa sin necesidad de los procesos
largos y repetitivos que retrasan los tiempos estimados en los proyectos de
investigación.
17
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.
El estudio correlacional comprende la relación que existe entre los modelos de
negocio electrónico, los modelos de intercambio y consulta de trabajos de grado
de las instituciones de educación superior. Como resultado se obtiene la definición
18
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.
• Módulo de registro el cual tiene una arquitectura distribuida en tres o más
19
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.
Por ser un prototipo, se realizaron pruebas de funcionalidad con instituciones
simuladas ya que existen convenios en físico pero el despliegue de los
componentes en los servidores de las instituciones requiere adelantar procesos
técnicos en cada entidad, para lo cual es necesario procesos de aprobación y
adaptación tecnológica que demandan tiempo y voluntad administrativa para ser
20
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.
Otra de las limitaciones es el tamaño de la muestra de aplicación ya que se basa
en instituciones públicas de la ciudad de Bogotá dentro de las que se logró
21
obtener información, por lo tanto no se puede generalizar al conjunto de
universidades en el país.
22
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
Extensible Markup Language (XML) como base para enviar documentos y realizar
transacciones de negocio en estas se enmarcan las ventajas de usar perfiles y
23
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
Los negocios electrónicos han sido un gran avance en el mundo tecnológico. Las
implementaciones que se han logrado por medio de ellos han transcurrido desde
los intercambios virtuales hasta modelos de negocio bajo los cuales la interacción
humana es mínima (Feuerlicht, 2011, p. 3). El uso de los negocios electrónicos ha
llegado hasta el desarrollo de modelos que interactúan entre ellos para llegar a
acuerdos que beneficien a la industria por medio de la reducción de tiempos y
trámites para llegar a un acuerdo de negocio (Choi, Raghu, Vinze, & Dooley, 2009,
p. 1).
24
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.
• Una identificación única de cada una de las partes la cual permita realizar
un contrato legal por medio de acuerdos electrónicos.
25
• 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:
Tabla 1: Capas B2BTipos de documento Procesos Públicos Seguridad
Secuencia de intercambio
Empaquetado
Gestor de transporte
Transporte
Fuente: (Bussler, 2002, p. 3)
Adicional a las capas presentadas anteriormente se recomienda que las partes
definan modelos para las excepciones que se puedan presentar durante el
proceso, entre ellos la auditoría, la respuesta negativa de los servicios y manejo
26
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:
• Actor: Alguien o algo por fuera del sistema o del negocio que interactúa con
27
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.
• Transacción de negocio: Unidad lógica de negocio conducida por dos o
más partes que generan un suceso computable o una falla de estado.
28
• 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.
• Intercambio Electrónico de Datos (EDI): El intercambio electrónico de
datos se crea en 1970 y busca lograr realizar transacciones estructuradas
29
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
RossetaNet es una organización encargada, desde 1998, de realizar estándares
para modelos de negocio, en su estructura define componentes comunes para
lograr una buena interacción entre los actores del negocio, el producto de la
organización es un framework el cual basa su lógica en el intercambio de
información de empresas concretas, se plantea una transacción electrónica(Laura
Grande Pérez, pg. 2) la cual tiene dos tipos de problemáticas, la primera tiene que
ver con la información como tal, en la cual se define cómo está estructurada la
información, cuáles son los usos de esa información y el contenido de la misma; la
otra problemática es el intercambio que se hace de la información, es decir, las
relaciones entre los actores y cómo se realizan las transacciones de la información
30
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.
El framework de implementación especifica el transporte, enrutado y
empaquetamiento de los mensajes.
31
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).
• El tercer elemento, y al que más le ha dado soporte Microsoft, es el BizTalk
server el cual es un servidor de mensajería para mensajes XML enviados
por los frameworks de BizTalk y hacer las interacciones entre los actores
empresariales; este servidor está enfocado en tres objetivos, integrar
aplicaciones empresariales fácilmente, simplificar el manejo de las
32
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).
La estructura se basa en el lenguaje XML el cual es aceptado por diversos
editores y permite definir modelos con los cuales se pueden hacer tanto
abstracciones como especificaciones. El lenguaje permite, también, realizar meta
33
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.
En cuanto a la infraestructura y arquitectura de ebXML se tienen que definir cinco
conceptos y elementos importantes; el primero es generar un estándar en donde
se describan los principales procesos de negocio y los modelos de información y
mensajes de los mismos; el segundo elemento es un registro en el cual se
encuentra y se realiza el mantenimiento de los procesos de negocio por medio de
meta modelos que puedan ser reutilizados y compartidos; el tercer elemento es el
que más se define y es en el cual los participantes crean un soporte para
34
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
35
Fuente: (UN/CEFACT,OASIS, 2001b)
Ilustración 1: Infraestructura de ebXML
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 arquitectura presentada por el modelo B2B se ve implementada en el estándar
ebXML por medio de 6 capas que permiten el proceso: gestor de protocolos,
gestor de eventos, gestor de transporte, gestor de base de datos, transporte y
seguridad (Bussler, 2002, p. 4).
36
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.
La capa de seguridad se encarga de la funcionalidad para encriptar y desencriptar
documentos.
37
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 negocioCaracterísticas de cada
frameworkebXML RossetaNet BizTalk
Modelo abstracto denegocio
Basado en metamodelosque permite hacer unaespecificacióndependiendo el problema.
Modelo enfocado a lainteracción entreempresas concretasdesarrollando modelosque ayuden alintercambio.
Su enfoque está en laautomatización deprocesos de negocio, seven enfocados en lograrinteroperabilidad de lasempresas.
Definición de perfiles denegocio
Se definen mediante CPP. Se definen por medio delos PIP.
Perfiles de usuarioservidor.
Definición detransacciones de negocio
Se define mediante CPA Se definen pordiccionarios técnicos ydiccionarios de negocio
Incluido en los perfiles desoftware.
Enfoque del framework Modelar la informaciónque se va a intercambiary cómo se estructura deuna manera genérica
Lenguaje común para lagestión de procesos decomercio electrónico
Enfoque enautomatización denegocios B2B y procesosde negocio
38
Almacenamiento El almacenamiento se daen el Registry el cualtiene los elementoscomunes de los dosactores
Cada cliente tiene lasespecificaciones de losdocumentos ya que no seespecifica losdocumentos técnicos
Se enfoca en losservidores BFC1 loscuales guardan y realizanlas transacciones y seguardan los documentoscomunes.
Intercambio de mensajes El intercambio demensajes viene dado porun protocolo asociado aellos, se define en elBussinessPrecess
Los mensajes se realizanpor segmentos, los cualesse definenindependientes para cadacluster de datos.
Se realizan por medio delos servidores BFCquienes controlan el pasode documentos.
Nivel de abstracción delframework
Nivel alto de abstracción,permite realizar diversasimplementaciones ymodificaciones por mediode las normas ISO.
Nivel medio deabstracción, permitehacer los negociosenfocándose a latransacción de negociomás no a los elementostécnicos.
Es bajo el nivel deabstracción y enfocado aproductos específicos demicrosoft.
Fuente: El Autor
1 Bussiness Framework Compliant: Servidor compatible con BizTalk para el intercambio de mensajes.
39
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.
En cuanto a los estándares de negocio electrónico, se realiza la investigación con
los que se acoplen a las características encontradas en las instituciones para
poder realizar las negociaciones, además que presenten normas aprobadas sobre
la aplicación del modelo B2B, una definición sobre la contratación para el negocio
y la adaptabilidad web de las herramientas para poder simplificar la comunicación
entre entidades.
40
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
Dentro de la inducción se hizo una evaluación de las instituciones teniendo en
41
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
En la metodología RUP tenemos las cuatro fases, iniciación, elaboración,
construcción y transición acompañadas de sus flujos de trabajo. Para el proyecto
se adaptan estas fases en el desarrollo del prototipo; el modelado de negocio se
42
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.
• Elaboración: La fase de elaboración se dividió en dos hitos, el primero tuvo
en cuenta los resultados obtenidos de las primeras dos fases del modelo
científico con las investigaciones de las instituciones educativas y los
modelos de transacción electrónica. A partir de ellos se obtienen los
requerimientos funcionales y no funcionales de la aplicación (Generar CPP,
generar CPA, realizar acuerdos de negocio, etc), además, cuáles son los
principales casos de uso que estarán presentes en el prototipo.
43
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.
La metodología RUP estuvo acompañada por iterativo incremental en donde en
cada iteración se realizó una revisión de los procesos para asegurar una mejor
aproximación a la solución del problema real, además se acordaron puntos de
control en donde se verificó que tanto la información como el producto software
44
fueran acordes a los planes y requerimientos planteados en las primeras etapas.
Al terminar la etapa de experimentación de la hipótesis se realizaron pruebas en
donde se evidenció el producto software y su funcionalidad, además se realizaron
críticas y recomendaciones para trabajos futuros relacionados con el modelo.
45
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.
Dentro del procedimiento de intercambio es importante primero definir los
parámetros que son necesarios para cumplir el modelo de B2B. La primera
característica a tener en cuenta en el modelo es la identificación de las entidades,
esta debe contener la información principal de la entidad y se utiliza para permitir
conformar un contrato legal a través de acuerdos electrónicos. Se debe almacenar
46
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.
• Transacciones concurrentes: Número de transacciones que podrán realizar
47
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.
• Registro de transacciones realizadas por usuarios de otras instituciones
educativas.
48
• 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:
• Información básica de la institución: Se presenta la identificación de la
institución, la referencia de la institución, el rol que cumplirá la institución y
49
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.
• Fecha inicio y fin del acuerdo.
• Límite de invocación.
50
• 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.
Por último, la definición del árbitro se realiza mediante el servidor de registro el
cual se encarga de verificar a través de servicios: la comunicación a cada
institución educativa, las transacciones realizadas así como de guardar, mostrar y
cifrar todos los documentos del negocio.
51
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.
• Protocolos de cifrado que utiliza la institución.
52
• 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 rol de cada institución: La institución debe elegir un perfil que
complemente el rol de su función, por ejemplo, el rol de Comprador debe
buscar el rol de vendedor para complementar el negocio.
53
• 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.
• Perfiles de cada una de las instituciones educativas: Los perfiles de
colaboración de las dos instituciones educativas en el momento que se
54
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.
• Colaboración binaria: Especifica los detalles de la transacción incluyendo: el
rol de la institución que inicia el evento y el de la que lo termina, el estado
55
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.
Dentro de las funciones del árbitro está la de informar a los usuarios (estudiantes e
56
instituciones educativas) las transacciones realizadas por acuerdo, con el fin de
que cada institución tenga el control de los acuerdos realizados y cada estudiante
tenga la relación de sus transacciones con otras instituciones.
57
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.
Para realizar los requerimientos se tuvo en cuenta los pasos enunciados por
Roger Pressman (Roger S. Pressman, 2010, pp. 106–109), en el primero se
identificó los participantes del sistema partiendo del modelo planteado y los datos
recolectados por las instituciones educativas, identificando a las instituciones y
bibliotecas dentro de ellas como las principales fuentes de información para
realizar los escenarios.
58
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 prototipoID Requerimiento Tipo
RequerimientoClasificación
Requerimiento
R01 Validar usuarios otras instituciones educativas No funcional Obligatorio
R02 Registrar y validar la información de perfil de laInstitución educativa
Funcional Obligatorio
R03 Buscar Perfiles de otras institucioneseducativas
Funcional Obligatorio
R04 Actualizar perfiles propios que no estén enestado activo
Funcional Obligatorio
R05 Mostrar los perfiles de otras institucioneseducativas para comparar
Funcional Obligatorio
R06 Realizar la propuesta de un acuerdo con otrainstitución educativa
Funcional Obligatorio
R07 Crear los acuerdos aceptados por las dosinstituciones educativas
Funcional Obligatorio
R08 Mostrar los acuerdos activos de la institucióneducativa
Funcional Obligatorio
R09 Crear especificaciones de proceso Funcional Obligatorio
R10 Consultar la especificaciones de proceso de losacuerdos
Funcional Obligatorio
59
R11 Consultar transacciones realizadas por usuariosde 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 porestudiantes de otras instituciones educativas
Funcional Obligatorio
R15 Consultar disponibilidad de acuerdos Funcional Obligatorio
R16 Consultar usuarios registrados de otrainstitución educativa
Funcional Obligatorio
R17 Encriptar nombres de documentos y carpetas No Funcional Opcional
R18 Consultar el detalle de los documentosconsultados por cada institución educativa
Funcional Opcional
R19 Registrar las consultas realizadas por usuariosde diferentes instituciones educativas
Funcional Obligatorio
R20 Consultar usuario disponible de institucióneducativa
Funcional Obligatorio
R21 Inhabilitar usuarios de cada institucióneducativa
Funcional Obligatorio
R22 Mantener compatibilidad con navegadoresChrome y Mozilla Firefox
No Funcional Opcional
R23 Bloquear modificaciones sobre documentos enlos acuerdos activos
Funcional Obligatorio
R24 Brindar comentarios de ayuda para el llenadode los perfiles y acuerdos en la aplicación
No funcional Opcional
R25 Crear, cargar y modificar documentos denegocio en formato XML
No funcional Obligatorio
R26 Enviar correo de validación para el registro deusuarios
No funcional Opcional
Fuente: El Autor
Para el caso del análisis se tomaron en cuenta los requerimientos funcionales de
la aplicación, después de esto se realizó un cruce de requerimientos para obtener
la prioridad y dependencia de cada uno, esto con el fin de encontrar las
características principales del software y construir una lista que contemple los
casos más importantes para la negociación.
60
Con el fin de determinar el valor de dependencia y prioridad de cada requerimiento
se establecieron tres categorías con sus respectivos rangos los cuales se
relacionan en la Tabla 4.
Tabla 4: Rangos Dependencia/PrioridadPrioridad/Dependencia
Mayor que 5 Alto
Entre 4 y 5 Medio
Menor que 4 BajoFuente: El Autor
Dentro de la Tabla 5 se muestra la relación que determina la prioridad y
dependencia de cada requerimiento.
Tabla 5: Requerimientos vs Requerimientos
Requerimientos
Prioridad/Depedencia Dep
end
encia
R02
R03
R04
R05
R06
R07
R08
R09
R10
R11
R12
R13
R14
R15
R16
R18
R19
R20
R21
R23
R02
Registrar y validar la información de perfil de la institución educativa
0
R03
Buscar Perfiles de otras instituciones educativas
11
R04
Actualizar perfiles propios que no estén en estado activo
1 1 1 14
R05
Mostrar los perfiles de otras instituciones educativas para comparar
1 1 13
R06
Realizar la propuesta de un acuerdo con otra institución educativa
1 1 13
R07
Crear los acuerdos aceptados por las dos instituciones educativas
1 1 1 14
61
R08
Mostrar los acuerdos activos de la institución educativa
1 1 1 14
R09
Crear especificaciones de proceso
1 1 1 1 15
R10
Consultar la especificaciones de procesode los acuerdos
1 1 1 1 1 16
R11
Consultar transacciones realizadas por usuarios de la entidad
1 1 1 1 1 1 1 1 1 1 1 1 113
R12
Registrar estudiantes de la entidad educativa
1 1 13
R13
Modificar datos de usuarios de la aplicación
1 1 1 14
R14
Mostrar documentos consultados por estudiantesde otras instituciones educativas
1 1 1 1 1 1 1 1 1 1 1
11
R15
Consultar disponibilidad de acuerdos
1 1 1 1 1 16
R16
Consultar usuarios registrados de otra institución educativa
11
R18
Consultar el detalle de los documentos consultados por cada institución educativa
1 1 1 1 1
5
R19
registrar las consultas realizadas por usuarios de diferentes instituciones educativas
1 1 1 1 1
5
R20
consultar usuario disponible de otra institucióneducativa
1 1 13
R21
inhabilitar usuarios de cadainstitución educativa
1 1 1 14
R23
Boquear modificaciones sobre documentos en los acuerdos activos
1 1 1 1 15
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
Para realizar el análisis de los requerimientos obtenidos de la Tabla 4 se clasifican
62
con los rangos y categorías establecidos, de la que se obtiene la relación entre
dependencia y prioridad de cada uno de los requerimientos la cual está
representada en la Tabla 6.
Tabla 6: Prioridad/Dependencia RequerimientosCod. Requerimiento Prioridad Dependencia
R02 Registrar y validar la información de perfil de lainstitución educativa
Alto Bajo
R03 Buscar perfiles de otras instituciones educativas Alto Bajo
R04 Actualizar perfiles propios que no estén en estadoactivo
Bajo Medio
R05 Mostrar los perfiles de otras instituciones educativaspara comparar
Bajo Bajo
R06 Realizar la propuesta de un acuerdo con otra institucióneducativa
Alto Bajo
R07 Crear los acuerdos aceptados por las dos institucioneseducativas
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 losacuerdos
Bajo Alto
R11 Consultar transacciones realizadas por usuarios de laentidad
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 deotras instituciones educativas
Bajo Alto
R15 Consultar disponibilidad de acuerdos Medio Alto
R16 Consultar usuarios registrados de otra institucióneducativa
Medio Bajo
R18 Consultar el detalle de los documentos consultados porcada institución educativa
Bajo Medio
R19 Registrar las consultas realizadas por usuarios dediferentes instituciones educativas
Medio Medio
R20 Consultar usuario disponible de otra institucióneducativa
Alto Bajo
63
R21 Inhabilitar usuarios de cada institución educativa Bajo Medio
R23 Bloquear modificaciones sobre documentos en losacuerdos activos
Alto Medio
Fuente: El Autor.
Del análisis de los requerimientos se puede evidenciar que el requerimiento R02
(Registrar y validar la información de perfil de la institución educativa) es el de
mayor atención ya que presenta una mayor prioridad y menor dependencia de
todos, de este requerimiento dependerá el funcionamiento de gran parte de las
características del sistema. Se puede encontrar una relación entre el
requerimiento y el modelo, en donde el perfil de la institución educativa, es la base
para realizar las transacciones de negocio.
También se puede evidenciar que los requerimientos más importantes son los que
se relacionan con el proceso de negociación y que su prioridad y dependencia
varia con respecto a la evolución del negocio, a medida que la propuesta avanza
su prioridad es menor y es mayor su dependencia lo cual concuerda con las
características del modelo.
8.2 CASOS DE USO
Teniendo claros los conceptos adquiridos en el análisis de los requerimientos se
plantearon los escenarios de uso, los cuales tienen la función de materializar la
visión general de funciones y características del sistema. Se realiza la creación de
escenarios con actores para poder definirlos (Roger S. Pressman, 2010, p. 112).
8.2.1 ACTORES
Para la definición de los actores se toman en cuenta los usuarios claves del
64
sistema, los cuales actúan directamente en los escenarios y se definen actores
secundarios que serán de apoyo a los mismos (“IBM Knowledge Center,” 2013).
Para el caso de estudio, se identifica un usuario general especificados en dos
actores que tendrán acceso al sistema estos son la institución educativa y el
estudiante y serán apoyados por el administrador de la aplicación. Su definición
se puede ver en la Ilustración 2.
8.2.2 DIAGRAMA DE CASOS DE USO PRELIMINARES
Para la definición de los casos de uso primero se realizó una definición de casos
de uso preliminares que serán escenarios planteados para el sistema en los
cuales haya una interacción entre el usuario y el software y describan un conjunto
de pasos en el mismo (Roger S. Pressman, 2010, p. 132), estos fueron definidos
65
Ilustración 2: Actores del sistema
Fuente: El Autor
de acuerdo a los requerimientos del sistema y se plantearon en tres grupos de
acuerdo a su función, los cuales se pueden ver en la Ilustración 3, Ilustración 4 e
Ilustración 5.
Ilustración 4: Casos de Uso Perfiles
Fuente: El Autor
66
Ilustración 3: Caso de uso Usuarios
Fuente: El Autor
Ilustración 5: Casos de Uso Acuerdo
Fuente: El Autor.
8.2.3 DEPENDENCIA Y PRIORIDAD CASOS DE USO
Después de plantear los casos de uso preliminares se realizó la Tabla 7, en la cual
se cruzó los caso de uso versus caso de uso; su finalidad fue analizar la prioridad
y dependencia de cada uno y establecer la importancia que se le debe dar a cada
escenario.
Tabla 7: Caso de Uso vs Caso de UsoPrioridad/Dependencia D
epen
den
cia
ID Caso de uso CU
01
CU
02
CU
03C
U04
CU
05
CU
06
CU
07
CU
08
CU
09
CU
10
CU
11
CU
12
CU
13
CU
14
CU
15
CU
16
CU
17
CU
18
CU
19
CU
20
CU
21
CU
22
CU01 Registrar Perfil 1 1 2
CU02Actualizar Perfl
1 1 1 1 1 1 1 1 19
67
CU03Consultar Perfil 1 1 1 1 1 1
6
CU04Mostrar Perfiles
1 1 13
CU05Buscar Documento 1 1
2
CU06Cargar Documento
1 1 13
CU07Comparar Perfil
1 1 1 1 1 16
CU08Crear Acuerdo
1 1 1 1 1 1 1 1 1 1 111
CU09Solicitar Acuerdo
1 1 1 1 1 1 17
CU10Aceptar Acuerdo 1 1 1 1 1 1
6
CU11 Validar Perfiles 1 1 1 1 4
CU12Consultar EspecificaciónProceso
1 1 1 14
CU13Validar Acuerdo
1 12
CU14Crear Especificacion
1 1 1 14
CU15Consultar Acuerdo
1 1 13
CU16Realizar Transacciones
1 1 1 1 1 1 1 1 1 1 111
CU17Validar Documentos
1 1 1 1 15
CU18Registrar Transaccion
1 1 1 1 1 1 1 1 19
CU19Modificar Datos
1 12
CU20Registrar Usuario 1
1
CU21Validar Usuario
0
CU22Consultar Transacciones
1 1 1 1 1 1 1 18
Prioridad 8 0 9 8 9 10 6 8 2 1 6 2 7 1 6 1 2 2 2 7 11 0
Fuente: El Autor
68
En la Tabla 8 se relacionan los resultados; cada caso de uso preliminar con su
prioridad y dependencia.
Tabla 8: Dependencia Prioridad Casos de usoCod. Caso de Uso Prioridad Dependencia
CU01 Registrar Perfil Alto Bajo
CU02 Actualizar Perfl Bajo Alto
CU03 Consultar Perfil Alto Medio
CU04 MostrarPerfiles Alto Bajo
CU05 BuscarDocumento Alto Bajo
CU06 CargarDocumento Alto Bajo
CU07 CompararPerfil Medio Medio
CU08 CrearAcuerdo Alto Alto
CU09 SolicitarAcuerdo Bajo Medio
CU10 AceptarAcuerdo Bajo Medio
CU11 ValidarPerfiles Medio Bajo
CU12 ConsultarEspecificaciónProceso Bajo Bajo
CU13 ValidarAcuerdo Medio Bajo
CU14 CrearEspecificacion Bajo Bajo
CU15 ConsultarAcuerdo Medio Bajo
CU16 RealizarTransacciones Bajo Alto
CU17 ValidarDocumentos Bajo Medio
CU18 RegistrarTransaccion Bajo Alto
CU19 ModificarDatos Bajo Bajo
CU20 RegistrarUsuario Medio Bajo
CU21 ValidarUsuario Alto Bajo
CU22 ConsultarTransacciones Bajo Alto
Fuente: El Autor
Como resultado del análisis de los casos de uso preliminares, se puede observar
que responden a un patrón lo cual permite una agrupación para su definición
formal, esto con el fin de presentar un conjunto de casos puntuales que tienen los
actores dentro del sistema y facilitar el entendimiento de los escenarios y su
69
relación con los requerimientos funcionales del sistema.
8.2.4 CASOS DE USO CONSOLIDADOS
Los casos de uso consolidados permiten un entendimiento de escenarios críticos
del sistema o un conjunto de etapas que poseen excepciones (Roger S.
Pressman, 2010, p. 136). Para el sistema planteado se evaluaron los casos de uso
preliminares y se desarrollaron un conjunto de casos consolidados los cuales
abordan los posibles escenarios a los que se enfrentarán los actores del sistema.
La agrupación se realizó evaluando la tabla de prioridad y dependencia de cada
uno de los casos de uso y relacionando los requerimientos que cubre cada uno, la
Tabla 9 muestra los resultados de la agrupación y dentro de la Ilustración 6 se
relaciona cada caso de uso formal con su respectiva interacción con los actores
del sistema.
Tabla 9: Casos de Uso ConsolidadosCasos de uso Consolidados
CUP01 Gestionar Perfiles
CUP02 Realizar Solicitudes
CUP03 Elaborar Especificaciones de Proceso
CUP04 Gestionar Aprobaciones
CUP05 Realizar Transacciones Fuente: El Autor
70
Para cada caso de uso se presenta una definición extendida de cada uno
representando los actores relacionados, objetivos, precondiciones, escenarios,
postcondiciones, prioridades y frecuencia de uso con el fin de especificar a detalle
cada escenario planteado. La definición se presenta en la Tabla 10, Tabla 11, Tabla
12 y Tabla 13.
Tabla 10: Gestionar Perfiles CUP01Caso de uso Gestionar Perfiles CUP01
Actor Principal Institución Educativa
Actor Secundario
71
Ilustración 6: Diagrama de casos de uso Consolidados
Fuente: El Autor
Objetivo Crear y modificar Perfiles de la institución educativa
Precondiciones Ingresar al sistema y tener definidas los elementos del
perfil
Disparador La institución educativa decide crear un perfil para realizar
negociación
Escenario:
Actor Principal Sistema
1. Ingresa un identificador y un nombre
del perfil.
3. Ingresa la información de la entidad
(identificación de la institución,
referencia de la institución, rol que
tomará la institución en el negocio,
certificados de la institución).
4. Ingresa los canales de comunicación
y mensajes (protocolos de transporte,
tipos de mensaje, canales de
comunicación).
5. Ingresa el empaquetado y los
comentarios del perfil.
6. Solicitar guardar el perfil.
9. Seleccionar el perfil que quiere
2. Registrar el identificador y el nombre
del perfil.
7. Registrar la información, canales de
comunicación, mensajes, empaquetado
y comentarios del perfil y los asocia al
identificador y su nombre.
8. Presenta los perfiles disponibles de la
institución.
10. Cargar y presenta los datos del
72
modificar.
11. Registrar los cambios en el perfil.
perfil.
Excepciones * Si existe un acuerdo activo en el cual exista el perfil,
sólo se puede visualizar.
Postcondición * El sistema registra un nuevo perfil de la institución
educativa.
* El sistema registra los cambios realizados en el perfil.
Prioridad Alta
Frecuencia de uso Siempre que el usuario desee parametrizar perfiles para
realizar negociación electrónicaFuente: El Autor
Tabla 11: Realizar Solicitudes CUP02Caso de uso Realizar Solicitudes CUP02
Actor Principal Institución Educativa
Actor Secundario Administrador
Objetivo Comparar perfiles y realizar solicitudes de acuerdos a
instituciones educativas
Precondiciones * Tener un perfil registrado.
* El perfil registrado debe estar en estado activo.
Disparador La institución educativa desea realizar un acuerdo con
otra entidad.
Escenario:
Actor Principal Sistema
1. Seleccionar la institución educativa
para realizar el acuerdo.
3. Seleccionar el perfil de la institución
seleccionada con el que desea
2. Consultar y presenta los perfiles
registrados y activos de la institución
seleccionada.
73
comparar.
4. Seleccionar el perfil propio con el
cual realizar la comparación y solicitar
la comparación.
6. Registrar condiciones de la propuesta
de acuerdo (fecha de validez del
acuerdo, número de invocaciones,
intercambios simultáneos, comentarios).
7. Realiza la solicitud de acuerdo.
5. Consultar los perfiles y presenta los
datos para solicitar un acuerdo.
8. Generar el identificador del acuerdo y
añadir el estado propuesto.
9. Guardar los datos ingresados por el
actor e informar a la institución destino
sobre la propuesta recibida.
Excepciones
Postcondición El sistema registra el acuerdo y presenta la información
del acuerdo.
Prioridad Alta
Frecuencia de uso Siempre que la institución educativa desee realizar un
acuerdo con otra entidad educativa.Fuente: El Autor
Tabla 12: Elaborar Especificación de Proceso CUP03Caso de uso Elaborar especificación de proceso CUP03
Actor Principal Institución educativa
Actor Secundario
Objetivo Registrar los requisitos para realizar transacciones entre
las dos instituciones educativas.
Precondiciones * Tener un perfil activo registrado.
74
* Tener un acuerdo propuesto.
Disparador La institución educativa define los documentos, pasos y
requisitos necesarios para realizar cada transacción
Escenario:
Actor Principal Sistema
1. Registrar un identificador de la
especificación y un nombre.
3. Registrar los documentos necesarios
para la transacción.
4. Define el nombre de la transacción
de negocio, el nombre de la petición, el
documento que se requiere para enviar
la petición, la respuesta de la petición y
el documento relacionado a la
respuesta.
5. Registrar el estado inicial antes de
realizar la petición y el estado final en
donde quedará la transacción después
de la respuesta.
6. Definir cuál rol inicia la transacción y
cuál rol la debe responder.
7. Guardar la especificación de proceso.
2. Registrar el identificador y el nombre
de la especificación.
8. Registrar la información ingresada
por el actor de la especificación de
proceso y la asocia con el acuerdo.
9. Presentar las especificaciones
registradas del acuerdo.
Excepciones * La institución educativa puede modificar las
75
especificaciones de proceso de acuerdos que no se
encuentren activos
Postcondición La especificación de proceso queda registrada junto con la
asociación al acuerdo correspondiente y se presenta la
información almacenada.
Prioridad Alta
Frecuencia de uso Siempre que la institución educativa desee agregar
detalles de las transacciones a acuerdos propuestos.Fuente: El Autor
Tabla 13: Gestionar Aprobaciones CUP04Caso de uso Gestionar Aprobaciones CUP04
Actor Principal Institución Educativa
Actor Secundario Administrador
Objetivo Visualizar y aprobar acuerdos solicitados por otras
instituciones educativas
Precondiciones * Tener un perfil activo registrado.
* Tener solicitudes de acuerdos de otras instituciones.
* Tener registradas las especificaciones de proceso.
Disparador La institución educativa desea aprobar acuerdos con otra
entidad.
Escenario:
Actor principal Sistema
1. Seleccionar la solicitud realizada por
otra institución educativa.
3. Solicitar las especificaciones de
proceso propuestas.
2. Consultar y presentar los perfiles y
los datos del acuerdo propuesto.
4. Consultar y las especificaciones de
proceso asociadas al acuerdo
propuesto.
76
5. Cambiar estado de acuerdo a
aprobado.
6. Enviar aprobación de acuerdo. 7. Registra el cambio de estado y envía
la notificación de acuerdo activo a la
institución educativa que propuso el
mismo.
Excepciones * La institución educativa puede devolver el acuerdo con
cambios a la propuesta original.
* La institución educativa puede modificar las
especificaciones de proceso.
Postcondición * El sistema registra los cambios y lo deja en estado
activo.
Prioridad Alta
Frecuencia de uso Siempre que la institución educativa desee aprobar
acuerdos con otra institución educativaFuente: El Autor
Tabla 14: Realizar Transacciones CUP05Caso de uso Realizar Transacciones CUP05
Actor Principal Institución educativa(I), Estudiante(E)
Actor Secundario Administrador
Objetivo Realizar transacciones de trabajos de grado entre
instituciones educativas
Precondiciones * Debe existir un acuerdo entre la institución educativa a la
que pertenece el estudiante y la entidad a consultar
Disparador El estudiante solicita un trabajo de grado a una institución
educativa diferente a la que pertenece.
77
Escenario:
Actor Principal Sistema
1. E: Realizar el registro de la
información personal en el sistema
(correo electrónico, identificación,
entidad a la que pertenece, nombre de
usuario, contraseña).
3. E: Realizar la solicitud de intercambio
documento trabajo de grado.
6. E: Consultar los documentos
solicitados a cada institución educativa.
2. Validar usuario con la institución
educativa y guardar los datos
ingresados por el actor.
4. Validar el acuerdo con la institución
educativa a la cual pertenece el
estudiante.
5. Verificar la especificación de proceso:
• Validar documentos
transaccionales.
• Validar registro de usuario en
el sistema.
• Registrar la transacción
realizada.
• Registrar el número de
transacciones realizadas por la
entidad.
7. Presentar la relación de documentos
consultados con fecha de consulta y la
institución educativa la cual se consultó.
78
8. I: Consultar transacciones realizadas
por estudiantes en un acuerdo.
9. Presentar los estudiantes que
realizan transacciones y los
documentos que cada uno consultó con
la fecha de consulta.
Excepciones * La institución educativa puede consultar el detalle de las
transacciones realizadas por sus estudiantes.
* La institución educativa puede registrar estudiantes al
sistema.
Postcondición El sistema registra la transacción realizada y envía
confirmación a la institución educativa.
Prioridad Alta
Frecuencia de uso Siempre que el estudiante solicite un trabajo de grado.Fuente: El Autor
8.3 DIAGRAMA DE CLASES
El diagrama de clases es la representación de los objetos que manipula el
sistema; estos modelos incluyen clases, relaciones entre ellas, paquetes, atributos
y operaciones (“IBM Knowledge Center,” 2013). Para definir las clases se
estableció la sintáxis usada por el framework de desarrollo, dentro de la cual se
especifica que las clases deben empezar en mayúscula y la separación de
palabras con guión al piso y seguidos de la segunda palabra en minúscula. En el
79
diseño del modelado de clases para el prototipo se dividió en conjuntos de
paquetes agrupados por su funcionalidad. Los paquetes resultantes fueron:
• Modelos: Paquete en el cual se encuentran las operaciones (guardar,
cargar, consultar datos y objetos) que se comunican con la base de datos.
Las clases y sus relaciones se presentan en la Ilustración 7.
Ilustración 7: Paquete de Modelos
Fuente: El Autor
• Controladores: Paquete que se encarga de realizar operaciones sobre los
objeto de la aplicación y su interacción entre ellos, las clases pertenecientes
80
se encargan de cargar los modelos y las vistas de la aplicación y de enviar
mensajes a cada una de ellas. Este paquete se relaciona en la Ilustración 8.
Ilustración 8: Paquete de Controladores
Fuente: El Autor
• Usuario: El paquete de usuario contiene el conjunto de objetos de acceso
de datos relacionado con la información del usuario; este se representa en
la Ilustración 9.
81
Ilustración 9: Paquete de Usuario
Fuente: El Autor
• Negocio: El paquete de negocio representa los objetos de acceso de datos
de la gestión de intercambios, en el se encuentran los acuerdos, las
especificaciones de proceso, las transacciones de los usuarios y el registro
de transacciones realizadas por cada acuerdo de cada entidad. Este
paquete se puede observar en la Ilustración 10.
82
Ilustración 10: Paquete de negocio
Fuente: El Autor
• Acceso: Paquete que contiene los objetos de acceso de datos que
representan la seguridad del prototipo, su definición de página y los
permisos que posee cada usuario para acceder a los contenidos. Se puede
observar en la Ilustración 11.
83
Ilustración 11: Paquete de acceso
Fuente: El Autor
8.4 DIAGRAMA DE SECUENCIA
Los diagramas de secuencia indican la forma en que los eventos provocan
transiciones entre un objeto y otro. Estos diagramas son una visión de la
representación del modo en que los eventos causan el flujo de uno a otro como
función del tiempo; son una representación de los casos de uso (Roger S.
Pressman, 2010, p. 168).
Se realizó la construcción de los diagramas de secuencia basados en los casos de
uso formales, para cada uno de ellos se seleccionaron los objetos y su interacción,
el resultado son 5 diagramas de secuencia que representan las funcionalidades
más relevantes del prototipo y que llevan a la aplicación del modelo. Estos
diagramas se presentan en las siguientes ilustraciones:
84
Ilustración 12: Secuencia Gestionar Perfiles
Fuente: El Autor
85
Ilustración 13: Secuencia Realizar Solicitud de Acuerdo
Fuente: El Autor
86
Ilustración 14: Secuencia Gestionar Aprobaciones de Acuerdos
Fuente: El Autor
87
Ilustración 15: Secuencia Elaborar Especificaciones de Proceso.
Fuente: El Autor
88
Ilustración 16: Secuencia Realizar transacciones
Fuente: El Autor
8.5 DIAGRAMA DE COMPONENTES
Un componente se define como “una parte modular, desplegable, y sustituible del
sistema que incluye implantación y expone un conjunto de interfaces” (Roger S.
Pressman, 2010, p. 235). La visión realizada para el presente prototipo es
orientada a objetos ya que los componentes se integran de un conjunto de clases
que colaboran entre ellas y las interfaces que permiten la comunicación con otros
89
componentes.
Dentro de la Ilustración 17 se muestra el diseño por componentes logrado para el
presente prototipo y las interfaces que permiten la comunicación entre ellos.
Ilustración 17: Diagrama de componentes
Fuente: El Autor
Cabe resaltar que en el diagrama se observa con mayor facilidad la estructura del
sistema y el comportamiento que proporcionan los componentes a través de sus
interfaces.
8.6 DIAGRAMA DE DESPLIEGUE
El diagrama de despliegue muestra la configuración de los elementos de hadware
y los componentes que lo integran, además de las interfaces que permiten la
comunicación entre ellos (“Sparx Systems - Tutorial UML 2 - Diagrama de
90
Despliegue,” n.d.).
En la Ilustración 18 se muestra el diagrama de despliegue del prototipo.
Ilustración 18: Diagrama de despliegue
Fuente: El Autor
En el diagrama de despliegue se observan 4 nodos que se requieren para
desplegar el software:
• Servidor de base de datos: Para el servidor de base de datos las
características recomendadas del hardware se especifican en la Tabla 15
Tabla 15: Características Hardware Base de datosComponente Recomendado
Procesador Procesador a dos núcleos con una velocidad de 3 GHz o superior cada uno
RAM 2 Gigabytes(GB)
Disco Partición de disco con 150 GB de almacenamiento libres
Unidad de Backup Unidad USB 4.0
Red Conexión de 56 kbps o más rápida entre los nodos que se conecten a él.
Fuente: El Autor
91
• Servidor de registro y de la institución educativa: Las características
recomendadas para los servidores se especifican en la Tabla 16.
Tabla 16: Características Hardware ServidoresComponente Recomendado
Procesador Procesador a cuatro núcleos con una velocidad de 3 GHz o superior cada uno
RAM 6 Gigabytes(GB)
Disco Partición de disco con 1 Terabyte(TB) de almacenamiento libres
Unidad Unidad USB 4.0
Red Conexión de 56 kbps o más rápida entre los nodos que se conecten a el.
Fuente: El Autor
• Computador de usuario: Las características para el computador de usuario
se especifican en la Tabla 17.
Tabla 17: Características Hardware Computador de usuarioComponente Recomendado
Procesador Procesador a dos núcleos con una velocidad de 2 GHz o superior cada uno
RAM 4 Gigabytes(GB)
Disco Partición de disco con 100 GB de almacenamiento libres
Unidad Unidad USB 4.0
Red Conexión de 56 kbps o más rápida entre los nodos que se conecten a él.
Fuente: El Autor
92
7. CONCLUSIONES
El modelo presentado basa su estructura en un perfil público que identifica de
manera explícita los datos básicos y describe las características de infraestructura
disponibles de la institución educativa, permitiendo ubicar entidades compatibles
para realizar propuestas de acuerdo y reducir tiempos en la ejecución de la
negociación, ya que después de que los actores realizan los acuerdos pueden
ejecutarse a mayor velocidad al estar respaldados por módulos de software
interconectados por protocolos de telecomunicaciones.
Las propuestas de negocio y sus cambios se efectúan directamente en el servidor
árbitro por medio de mensajes y documentos-contrato que pueden ser consultados
por los actores reduciendo la necesidad de reuniones presenciales y permitiendo
la realización de acuerdos con entidades que pueden estar en lugares
distanciados sin necesidad de traslado de personal. Además se definen unos
parámetros generales para la realización de la negociación estableciendo un
estándar en donde las diferencias están centradas en los eventos y detalles
transaccionales que harán parte del acuerdo.
Para realizar la propuesta del modelo se realizó una investigación sobre los
principales modelos de negocio disponibles que tuvieran un estándar y fueran
válidos internacionalmente. Dentro del estudio se observó que RossetaNET y
Biztalk tienen características similares con las cuales se puede asociar el modelo ,
sin embargo, la implementación del estándar está enfocado a instituciones
educativas por lo cual se busca reducir costos. ebXML es un estándar abierto y
que cumple con las características de B2B por lo tanto se necesitan menos
93
recursos para utilizarlo; además posee documentos-contrato en donde se asegura
que los acuerdos se encuentren en términos internacionales de negocio y puedan
ser utilizados por diversas entidades dispersas a nivel geográfico. Otra de las
características es que se utilizan etiquetas XML las cuales son universales y
dentro de las cuales se definen los términos de los acuerdos, los eventos
transaccionales y los perfiles de negocio con base en las estructuras del estándar
de intercambio electrónico.
Dentro de las funciones del servidor árbitro están almacenar, validar y mostrar los
documentos-contrato, acuerdos realizados, perfiles de negocio, transacciones
realizadas y usuarios válidos de todas las instituciones educativas. Esto permite
una centralización de la información en un ente imparcial entre las partes, dentro
del cual, las instituciones pueden consultar las características y detalles de los
acuerdos realizados en cualquier momento; además permite también a los
estudiantes consultar las transacciones efectuadas con cada institución educativa.
El modelo reduce la interacción de agentes humanos en la ejecución del proceso
de intercambio de trabajos de grado ya que los eventos dentro de las
transacciones (el pedido, la solicitud, la aprobación y la validación de los
acuerdos), son realizados directamente entre el software de implementación de la
institución educativa y el servidor árbitro; este último está encargado de verificar y
asegurar la especificación de eventos acordada en el momento de la negociación,
los límites establecidos en el acuerdo y registrar las transacciones realizadas por
los estudiantes con cada entidad.
El proceso manual de intercambio de trabajos de grado implica una serie de
eventos presenciales dentro de los que se encuentra realizar el pedido (5 días),
94
esperar disponibilidad (de 20 a 30 días hábiles) y consultarlo directamente en el
claustro educativo (5 días) lo cual implica tiempos de hasta 2 meses sin contar con
las negociaciones que se tengan que realizar para lograr los acuerdos; el presente
modelo reduce los tiempos tanto de la negociación como de la ejecución del
intercambio ya que el proceso se realiza directamente entre el servidor árbitro y la
implementación de la institución educativa, con lo cual se pueden lograr tiempos
de menos de 2 segundos en realizar la transacción solicitada por el estudiante y
reduciendo la intervención de agentes humanos.
95
8. TRABAJO FUTURO
En este proyecto se realiza el modelo sobre documentos trabajo de grado por ser
elementos de producción intelectual equivalentes en el entorno educativo, sin
embargo, el modelo se podría ampliar hacía otros elementos producidos en las
entidades tales como artículos, publicaciones, revistas científicas y recursos de
aprendizaje brindándoles una equivalencia de tal manera que las entidades
puedan realizar consultas de diverso material educativo e investigativo.
Para trabajos futuros se podría realizar una implementación que cumpla con el
estándar de comunicación hacia el árbitro y que permita a las instituciones
educativas gestionar los trabajos de grado internamente. Este desarrollo puede
ser parametrizable de tal manera que cada entidad pueda adoptarlo como su
gestor de documentos.
Dentro del software del servidor árbitro se realizaron protocolos de cifrado en las
carpetas y documentos de negocio. Para trabajos futuros se podría mejorar la
seguridad de acceso al aplicativo y la seguridad de los mensajes en los servicios
de validación entre la implementación de las instituciones educativas y el servidor
árbitro.
96
BIBLIOGRAFÍA
Bussler, C. (2002). The Role of B2B Engines in B2B Integration Architectures.
SIGMOD Rec., 31(1), 67–72. http://doi.org/10.1145/507338.507351
Choi, B., Raghu, T. S., Vinze, A., & Dooley, K. J. (2009). Process Model for e-
Business Standards Development: A Case of ebXML Standards. IEEE
Transactions on Engineering Management, 56(3), 448–467.
http://doi.org/10.1109/TEM.2009.2013828
Deployment Framework for BizTalk (BTDF) - Documentation. (n.d.). Consultado
Febrero 18, 2014, de http://biztalkdeployment.codeplex.com/documentation
Dirección de Impuestos y Aduanas Nacionales de Colombia. (n.d.). Consultado
Junio 27, 2016, de
http://www.dian.gov.co/contenidos/servicios/rut_preguntasfrecuentes.html
Dogac, A., Tambag, Y., Pembecioglu, P., Pektas, S., Laleci, G., Kurt, G., … Kabak,
Y. (2002). An ebXML Infrastructure Implementation Through UDDI
Registries and RosettaNet PIPs. In Proceedings of the 2002 ACM SIGMOD
International Conference on Management of Data (pp. 512–523). New York,
NY, USA: ACM. http://doi.org/10.1145/564691.564750
D-U-N-S Number. (n.d.). Consultado Junio 27, 2016, de /duns-number.html
ebXML - Enabling A Global Electronic Market. (n.d.). Retrieved from
http://ebxml.org/specs/index.htm
Feuerlicht, G. (2011). E-business interoperability: Challenges and opportunities. In
2011 Proceedings of the International Conference on e-Business (ICE-B)
(pp. 1–6).
97
Hayashi, K., & Mizoguchi, R. (2003). Document Exchange Model for Augmenting
Added Value of B2B Collaboration. In Proceedings of the 5th International
Conference on Electronic Commerce (pp. 458–464). New York, NY, USA:
ACM. http://doi.org/10.1145/948005.948064
IBM Knowledge Center. (2013, January 1). [CT701]. Retrieved May 18, 2016, from
http://www.ibm.com/support/knowledgecenter/SSWSR9_11.0.0/com.ibm.pi
m.dev.doc/pim_tsk_arc_definingusecases.html?lang=es
Jianni, H. (2009). Application of E-Commerce System Based on ebXML. In Second
International Conference on Future Information Technology and
Management Engineering, 2009. FITME ’09 (pp. 613–616).
http://doi.org/10.1109/FITME.2009.160
Laura Grande Pérez. (n.d.). Revisión de los estándares ebXML, RossetaNet y
BizTalk para aplicaciones de comercio electrónico, 16.
Roger S. Pressman. (2010). Ingeniería de software. Un enfoque práctico (7ma
Edición). McGrawHill.
Sistema de Bibliotecas - Sistema de Bibliotecas. (n.d.). Consultado Marzo 10,
2014, de https://biblioteca.uniandes.edu.co/index.php?
option=com_content&view=article&id=197:pinterbibliouserexternos&catid=9:
servicios&lang=es
Sparx Systems - Tutorial UML 2 - Diagrama de Despliegue. (n.d.). Consultado
Mayo 24, 2016, de
http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagra
m.html
98
tesis de grado. (n.d.). Consultado febrero 11, 2014, de
http://es.scribd.com/doc/2280161/tesis-de-grado
Topolink, M., Pintar, D., & Matasic, I. (2003). Implementation of the ebXML registry
client for the ebXML registry services. In Proceedings of the 7th
International Conference on Telecommunications, 2003. Con 2003℡ (Vol. 2,
pp. 551–556 vol.2). http://doi.org/10.1109/CON .2003.176960℡
UN/CEFACT,OASIS. (2001). ebXML Requirements Specification. Version1.06, 43.
Unimedios. (n.d.). SNB01 - Búsqueda básica. Consultado Marzo 6, 2014, de
http://168.176.5.96/F/KFMALCXVXTRS9MKHFL2BYDFAUBQFDPD1KVPL
517UPHHYTGT5NU-10940?func=find-b-0&local_base=SNB01
Vrhoci, D., Jarmila, M., & Đelmiš, M. (2009). Collaboration-Protocol Profile and
Collaboration-Protocol Agreement in B2B transactions, 6.
Yan, Z., & Fong, S. (2007). A Model of B2B Negotiation Using Knowledge. In
Proceedings of the IEEE/WIC/ACM International Conference on Web
Intelligence (pp. 829–832). Washington, DC, USA: IEEE Computer Society.
http://doi.org/10.1109/WI.2007.119
99