Source: http://docplayer.es/2543191-Carlos-a-martinez-cesar-a-geronimo-william-a-aguirre.html
Timestamp: 2017-03-28 03:14:13+00:00

Document:
Carlos A. Martínez, César A. Gerónimo, William A. Aguirre - PDF
Download "Carlos A. Martínez, César A. Gerónimo, William A. Aguirre"
José Francisco Botella Arroyo
1 1 Diseño de solución para el proceso de intercambio de información de créditos para una institución bancaria de segundo piso 1 regida por la Ley de Bancos de El Salvador Carlos A. Martínez, César A. Gerónimo, William A. Aguirre En este trabajo se aborda como objeto de estudio el proceso de intercambio de información entre una institución financiera de segundo piso y las instituciones financieras intermediarias (IFI) 2, el cual está supervisado por la Superintendencia del Sistema Financiero (SSF) 3, y se documenta debidamente. A la vez, se describen algunos estándares de intercambio de información que apoyan el proceso en estudio, y se analiza toda la información recolectada (por medio de investigación bibliográfica y entrevistas) con la finalidad de proponer un diseño con mejoras que le agreguen confiabilidad, rapidez y seguridad a dicho proceso de intercambio de información, de forma tal que haga de esa información una herramienta para la toma de decisiones. Asimismo, se describe el presupuesto estimado de costos de implementación del proceso de intercambio de información con los componentes que forman el diseño de la solución propuesta. Índice de términos Banco de segundo piso, estándar de intercambio de datos, intercambio de información, estándar de intercambio de datos, regulación financiera de El Salvador. 1 Banco de segundo piso: Institución financiera que, mediante el mecanismo de redescuento, facilita recursos de crédito a través de intermediarios financieros autorizados [1]. 2 Institución financiera intermediaria: Es aquella institución financiera supervisada por la Superintendencia del Sistema Financiero que puede canalizar al mercado los recursos financieros, tales como bancos, financieras, arrendadoras, cajas rurales, cajas municipales, cooperativas [2]. 3 Superintendencia del Sistema Financiero: La Asamblea Legislativa aprobó, mediante Decreto Legislativo No. 592 de fecha 14 de enero 2011, la nueva Ley de Supervisión y Regulación del Sistema Financiero, marco legal que regirá a la Superintendencia del Sistema Financiero como ente supervisor único, que integra las atribuciones de las Superintendencias del Sistema Financiero, Pensiones y Valores. Tiene la responsabilidad de supervisar la actividad individual y consolidada de las instituciones integrantes del sistema: bancos, bancos cooperativos, seguros, sociedades de ahorro y crédito, valores, pensiones, conglomerados financieros, burós de créditos, las bolsas de productos, el régimen de riesgos profesionales del ISSS, entre otros, bajo un nuevo marco normativo. Dicho ente supervisor está integrado al Banco Central de Reserva, con personalidad jurídica y patrimonio propio, de duración indefinida, con autonomía administrativa y presupuestaria para el ejercicio de las atribuciones y deberes que le confiere la Ley [3]. E I. INTRODUCCIÓN L documento busca generar una propuesta de diseño para uno de los procesos más importantes de un banco de segundo piso: el intercambio de información que se lleva a cabo entre este y las instituciones intermediarias que otorgan créditos, información utilizada para llevar el control de las actividades financieras realizadas. Cabe mencionar que existe una ley en El Salvador que sustenta la existencia y operación del banco de segundo piso, de la cual se hace también una revisión para que el producto propuesto cumpla con la normativa que la ley establece. Además, se define cada uno de los componentes necesarios de la arquitectura lógica y física del diseño propuesto, sus funciones, operaciones y la manera en la que interactúan entre sí. También se investiga y se analiza la factibilidad de los estándares de intercambio de información utilizados en otros países y en entidades financieras multinacionales, tales como el XBLR y GEL-XML, de los cuales se hace mención y han servido de base para la generación de un estándar de formato para el intercambio de información de la entidad financiera de segundo piso. Se describen los niveles de capacidad, disponibilidad, continuidad y seguridad que se pueden lograr con el diseño propuesto, así como la norma que deben cumplir las instituciones financieras con las que se realiza el intercambio de información para que la solución funcione adecuadamente. Se presentan los diagramas de casos de uso en UML (Fig. 5) y diagramas del proceso de intercambio de información con las mejoras obtenidas (Fig.4) del análisis de la documentación recolectada mediante investigación, las entrevistas realizadas y la descripción del proceso actual (Fig. 1). Cabe señalar que se usa UML por ser una herramienta estándar para modelado de la operación de los diferentes actores de un sistema y se utiliza BPMN para diagramar el proceso del intercambio de información por ser un estándar de modelado de procesos de negocio. Ya que también se busca apoyar una futura implementación del diseño, se presenta el resultado del análisis de la2 2 tecnología con la que se cuenta y la tecnología que se requiere para llenar la brecha tecnológica. II. ANTECEDENTES A. Banco de segundo piso en El Salvador A través del artículo 101 de la Constitución de la República de El Salvador se determina que el Estado promoverá el desarrollo económico y social mediante el incremento de la producción, la productividad y la racional utilización de los recursos, y fomentará los diversos sectores de la producción; es por ello que, a través del decreto número 856 de 1994, en la Asamblea Legislativa de la República de El Salvador se emitió la Ley de Creación del Banco Multisectorial de Inversiones, que a través del decreto número 847 de 2011 se transformó en el Banco de Desarrollo de El Salvador (más adelante denominado El Banco, Entidad Bancaria o Institución Bancaria ). También, a iniciativa del presidente de la República por medio del ministro de Hacienda se creó la Ley del Sistema Financiero para Fomento al Desarrollo; en ella, en el artículo 4 literales b, c y q define sus operaciones como banco de segundo piso, es decir como una institución autorizada para otorgar créditos a través de las instituciones financieras intermediarias (IFI). Adicionalmente, la Ley detalla en su artículo 39 que las IFI están obligadas a cumplir con las normas que el Banco establezca. Dentro de estas normas se especifican los datos que deben enviar las IFI al Banco al momento realizar intercambio de información, así como su periodicidad. Tanto datos como períodos varían de acuerdo al proceso de negocio del Banco. La operación de los bancos del sistema financiero salvadoreño está regulada por la Ley de Bancos, la cual establece el marco legal a cumplir por las instituciones financieras dentro del sistema, normando diferentes aspectos como los nombres de las entidades, su organización, sus actividades financieras y comerciales, su escrituración social, registro de acciones, pago de utilidades y demás aspectos legales que hagan transparente y legal a cada institución bancaria. Dentro de la Ley de Bancos no se cuenta con un apartado que regule la forma, periodicidad y los datos que deben intercambiarse las instituciones financieras intermediarias al momento de obtener los fondos a través de un banco de segundo piso. Sin embargo, el artículo 59 menciona que cuando obtengan recursos del Banco Multisectorial de Inversiones o de otras fuentes de crédito, los bancos concederán préstamos guardando armonía con las condiciones de financiamiento establecidas por la fuente de que se trate. B. Descripción del problema Para el Banco, como parte del control de sus operaciones financieras, es importante conocer algunos detalles de los fondos otorgados a través de las IFI. Es por ello que debe tenerse claro el conjunto de pasos del proceso de intercambio de datos e identificar los puntos en que se puede apoyar a través de los sistemas de información, así como con un diseño tecnológico que agilice los procesos de negocio que hacen uso de los datos del intercambio. El proceso de intercambio actual se muestra en la Fig. 1, y conlleva los siguientes pasos: 1. Los datos son enviados por uno de los operadores de las instituciones financieras intermediarias (IFI) a través de correo electrónico al Banco. 2. Uno de los operadores del Banco recibe e identifica el tipo de datos para realizar su validación. Fig.1 Proceso de intercambio actual3 3 3. La validación de los datos se realiza en algunos casos de forma visual. Sin embargo, en su mayoría lo hacen los sistemas específicos por petición; es decir, de forma manual. 4. Si los datos recibidos cumplen con lo esperado, tanto en información como en formato, se envía un correo electrónico de éxito del proceso. En caso contrario, se envía correo electrónico a la IFI con sugerencias de corrección de la información. Actualmente, el Banco no cuenta con un proceso general que cubra las necesidades de intercambio de información que necesitan los procesos de negocios, únicamente cuenta con aplicaciones aisladas que tienen una funcionalidad similar. Ello nos indica que tampoco hay un formato de documento estándar de cómo se deben intercambiar los datos, por lo que la propuesta es crear un proceso genérico, el cual soporte toda la información que se necesita intercambiar mediante las adecuaciones necesarias, para crear un estándar que facilite la comprensión del mismo por parte de las instituciones financieras y facilite la adición de nuevos datos para otros procesos de negocios. III. MARCO TEÓRICO Se busca garantizar el éxito de la solución informática partiendo de un diseño robusto, flexible y altamente escalable. Es por esto que es oportuno colocar lo más importante de los pilares teóricos de las arquitecturas lógicas y físicas a ser utilizadas. Además, permite plasmar algunos patrones existentes y buenas prácticas comprobadas del desarrollo de aplicaciones empresariales. A. Arquitectura lógica La arquitectura lógica a utilizar está basada en una arquitectura orientada a servicios. Esta arquitectura permite una combinación desacoplada de servicios interoperables que pueden ser utilizados en muchas aplicaciones dentro de la empresa. En la Fig. 2 pueden observarse los componentes y las tecnologías que se utilizan, como por ejemplo el Bus de Servicios Empresariales [4], servicios web (Portal de Servicios y Solicitudes de Servicio SOAP), gestión de procesos de negocio (Control de Flujo), almacenamiento centralizado (Datos). A continuación, se describe de forma breve cada una de estas, así como otros componentes involucrados de forma indirecta. XML Es un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados, también es conocido como lenguaje de marcas [5]. Este marcado permite generar documentos estándares que se convierten en la interfaz de comunicación entre los procesos de negocio, así como permite que las aplicaciones traten los datos que reciben de forma correcta. Todos los documentos XML contienen un prólogo (o encabezado), un elemento raíz y un árbol. Este árbol está constituido por elementos anidados (que tienen una relación principal-secundario) y por elementos adyacentes. SOAP (Simple Object Access Protocol) Define un modelo para el uso de mensajes simples de petición y respuesta como protocolo básico comunicación. La mensajería SOAP es un mecanismo RPC 4 independiente de la plataforma, pero puede ser usado para el intercambio de cualquier tipo de información XML. WSDL (Web Services Description Language) Es un vocabulario XML que define las interfaces de software para los servicios web y organiza todos los detalles técnicos necesarios para la integración automática a nivel de programación. WSDL es a los servicios web como IDL 5 es a los objetos CORBA 6. UDDI (Universal Description, Discovery and Integration) Es un protocolo para publicar la información de los servicios web. Permite comprobar qué servicios web están disponibles. Servicios web Permiten generar una comunicación entre diferentes componentes a través de la red, independientemente de dónde se encuentren, del lenguaje en el que estén escritos y de la plataforma de computación en la que se ejecuten. La tecnología que permite su funcionalidad es SOAP para los mensajes, y UDDI y WSDL para la publicación. Son interfaces de software muy útiles que describen un conjunto de operaciones a través de mensajería XML estandarizada y HTTP como protocolo principal de comunicación [6] [7] [8]. La seguridad se puede obtener con los mismos métodos de los servidores web y por tanto se dispone de autenticación de usuarios y cifrado de información de forma transparente al programador, usando protocolos y técnicas como IPSec 7 o SSL 8, ampliamente conocidos y usados en el mundo web [9]. Gestión de Procesos de Negocio (BPM) Es una solución tecnológica que, a través de un marco de trabajo fiable y robusto, permite articular el modelo de gestión por procesos, con lo que da respuesta a las necesidades de diseñar, controlar y medir los procesos [10]. Bus de Servicios Empresariales (ESB) En [11] se define a los ESB como la siguiente generación de plataformas para la integración empresarial de aplicaciones. Es una afirmación cuya base teórica se encuentra en la implementación de interfaces estandarizadas, 4 Remote Procedure Call (RPC): Técnica para la comunicación entre procesos en una o más computadoras conectadas a una red. 5 Interface Definition Language (IDL): Ofrece la sintaxis necesaria para definir los procedimientos o métodos a invocar remotamente dentro de la computación distribuida. 6 Common Object Request Broker Architecture (CORBA): Permite que diversos componentes de software escritos en múltiples lenguajes de programación y que corren en diferentes computadoras puedan trabajar juntos. 7 Internet Protocol security (IPsec): Es un conjunto de protocolos orientados a la seguridad de las comunicaciones sobre el Protocolo de Internet (IP). Los protocolos de IPsec actúan en la capa de red, la capa 3 del modelo OSI. 8 Secure Sockets Layer (SSL): Es un protocolo criptográfico que proporciona comunicaciones seguras por una red. Habitualmente, solo el servidor garantiza su identidad mientras que el cliente se mantiene sin autenticar.4 4 gracias a la utilización de estándares abiertos, las cuales proveen comunicación, conectividad, transformación, portabilidad y seguridad. También es importante hacer notar que un ESB combina paradigmas como la Arquitectura Orientada a Servicios (SOA) y la Arquitectura Dirigida por Eventos (EDA), mas no los implementa en sí mismo, sino que suple las características necesarias para implementar dichas arquitecturas. Esto se debe a su naturaleza sincrónica de los servicios y asincrónica de los eventos [11]. Fig. 2 Arquitectura lógica Fig. 3 Arquitectura física5 5 Dentro de sus principales características, y de las cuales haremos uso, se encuentran [12] [13]: Transparencia de localización: con ello, los consumidores de los servicios no tienen la necesidad de conocer la localización del proveedor. Enrutamiento de mensajes: con base en el contenido, se selecciona dinámicamente el destino. Soporte a procesos de negocio: orquestación de servicios (WS-BPEL) y transacciones involucrando varios servicios. Transformaciones: agregación, filtros, traducciones y mapas de datos, protocolos. B. Arquitectura física La arquitectura física a utilizar es N-Niveles (N-Tier), plasmada en la Fig. 3, la cual facilita una mayor distribución de las capas lógicas o aplicaciones a nivel físico, además de la posibilidad de aumentar la capacidad de procesamiento y memoria a través de la agregación de más equipos donde sea necesario, así como la posibilidad de establecer un balanceo de carga para mejorar la eficiencia del sistema. Además, suele hacerse por razones de seguridad de redes, donde el servidor web se despliega en una red perimetral y accede al servidor de aplicaciones que está localizado en una subred diferente, separados probablemente por un cortafuego (firewall). También es común que exista un segundo firewall entre el nivel cliente y el nivel web. El principal problema de utilizar N-Niveles es la latencia de las comunicaciones remotas entre los diferentes niveles, por lo cual hay que tener presente que la adición de más niveles incrementa la complejidad de los despliegues y en ocasiones impacta sobre el rendimiento. Por lo anterior, es recomendado no añadir más niveles de los necesarios. Es así que, en la mayoría de los casos, se debe implantar todo el código de la solución en un solo servidor o nivel de servidores balanceados; sin embargo, algunos casos necesitan dividir funcionalidad en diferentes niveles de servidores a causa de restricciones de seguridad o requerimientos de escalabilidad. En estos, siempre es deseable elegir protocolos de comunicación optimizados para maximizar el rendimiento [14]. Las arquitecturas a ser utilizadas permiten un alto nivel de desacoplamiento de las partes del diseño de la aplicación, lo que permite modificar o extender la lógica de negocio sin tener que tocar todos los módulos o poder intercambiar uno de los sistemas externos, sean estas aplicaciones o equipos. C. Estándares de intercambio de información XBRL (Extensible Business Reporting Language) Creado en 1998 como resultado de la propuesta de Charles Hoffman, busca simplificar la automatización del intercambio digital de información financiera mediante el uso del lenguaje XML; y así poder generar y analizar reportes, sacar conclusiones y proyecciones que ayuden a las entidades a tomar decisiones para corto, mediano y largo plazo de forma más rápida ya que no existirán ni ambigüedades ni dudas sobre los conceptos expresados. La organización encargada de crear y actualizar las especificaciones del lenguaje se llama XBRL, y opera como organización sin ánimo de lucro; además, está conformada por más de 400 miembros, en quienes están representados tanto el sector público como el privado que la hacen el referente mundial por su utilización [15] [16]. GEL-XML Es un lenguaje estándar desarrollado a partir de 2009 por la República de Colombia para intercambiar información entre organizaciones, lo cual facilita el flujo de información y el entendimiento de diferentes aplicaciones del Gobierno en Línea. Se caracteriza por abordar la información que se intercambia desde un punto de vista conceptual y técnico, así como por mantener una estructura organizacional que lo administra [17] [18]. IV. DISEÑO PROPUESTO Se propone una solución que hace uso de estándares y que es lo suficientemente general para poder abarcar los requerimientos actuales y futuros de diferentes intercambios de información con las instituciones financieras intermediarias. Con ello se pretende evitar la inversión de tiempo y recurso en la generación de aplicaciones nuevas para tareas similares de los procesos de negocio. Además, se busca facilitar el mantenimiento, ya que la solución únicamente requerirá realizar adecuaciones para mantener sincronía con las reglas de negocio. La propuesta de diseño de la solución se enfoca en mejorar las etapas de entrega, validación de formato y datos, y finalmente la etapa de carga, de acuerdo al proceso de negocio al que pertenezca la información intercambiada. Adicionalmente, el punto de acceso a las diferentes cargas será siempre el mismo. En este sentido, no se trata de proponer una solución cerrada; al contrario, se estandariza para poder adicionar capas que puedan realizar funciones más específicas como, por ejemplo, implementar una aplicación web para la carga de archivos, utilizar el bus de servicios para captura de archivos vía FTP, etc. Estas capas adicionales no se contemplan en el diseño de solución porque quedan fuera de los alcances de la propuesta. Las siguientes secciones describen las etapas realizadas luego de analizar la documentación recolectada en la investigación, las entrevistas y el proceso actual para desarrollar la solución propuesta. A. Definición de un nuevo proceso de intercambio El proceso de intercambio propuesto se muestra en la Fig. 4, y conlleva los siguientes pasos: 1. Los datos de las instituciones financieras intermediarias (IFI) son entregados al Banco a través de un servicio web publicado para dicha actividad. 2. Se valida el formato de los datos recibidos de forma inmediata según el tipo de información esperada. De haber error en el formato se retorna un mensaje de error; caso contrario, se retorna un mensaje de formato correcto y se procede a validar la información.6 6 Fig. 4 Proceso de intercambio propuesto 3. La validación de la información se realiza por medio de los sistemas sin intervención de usuario. De haber error se envía correo electrónico, generado por el sistema, con sugerencias de corrección de la información; caso contrario, se envía un correo electrónico de éxito del proceso. Este es soportado por el diseño de solución para automatizar, optimizar y generalizar el intercambio de información de los créditos entre un banco de segundo piso y las instituciones intermediarias que otorgan dichos créditos. B. Determinación del escenario A continuación se listan y describen los casos de uso plasmados en la Fig. 5, requerimientos funcionales y no funcionales necesarios para diseñar la solución propuesta. Casos de uso En los casos de uso se describen las actividades y los procesos que deben ser ejecutados tanto por un usuario o sistema en su interacción con el proceso en estudio. CUR-1 Validación de formato CUR-2 Validación de información SISTEMA DE INTERCAMBIO DE INFORMACIÓN «uses» Validar Formato «uses» Validar Información IFI «uses» «uses» «uses» «uses» Enviar Mensajes «uses» Cargar Información El Banco Fig. 5 Diagrama UML del proceso de intercambio de información 7 7 CUR-3 Carga de datos CUR-4 Envío de mensajes Requerimientos Los requerimientos funcionales (RFR) muestran los detalles técnicos del sistema, mientras que los no funcionales (NF) describen las características externas al sistema para mejorar aspectos como el rendimiento, la seguridad y la experiencia de uso, que dan una sensación de agrado y comodidad al usuario. RFR-1 Validación de archivo XML RFR-2: Tratamiento de códigos de error RFR-3: Carga de información RFR-4: Envío de mensajes NF-1: Equipo recomendado para la implementación NF-2: Personal NF-3: Lenguaje de programación NF-4: Base de datos NF-5: Rapidez de las consultas NF-6: Entorno amigable y funcional NF-7: Características de la conexión NF-8: Capacidad de integración e interconexión con otras aplicaciones. Para profundizar en los detalles de los casos de uso y requerimientos, referirse al Apéndice A. C. Creación de la arquitectura lógica Para una mejor comprensión de cómo interactúan los casos de uso listados anteriormente dentro de la solución, referirse a la Fig. 6, la cual ilustra la arquitectura lógica que se describe a continuación: 1. La Aplicación X de la IFI consume el servicio web colocado como interfaz única de acceso a la solución para enviar los documentos aplicando el formato XML establecido para ello. Fig. 6 Arquitectura lógica8 8 2. El servicio web aplica la lógica de validación de formato utilizando archivos XSD. 3. Si la validación de estructura está correcta, se llama el servicio de Business Process Management (BPM) a través del Bus de Datos, el cual se encarga de realizar un flujo de validaciones generales, además de enviar un correo electrónico con el identificador de proceso generado. 4. Dentro del BPM se toma la decisión de cuál procedimiento se debe llamar para realizar la verificación de datos, la cual incluye tipos lógicos de datos y validaciones de reglas de negocio. 5. Se ejecuta la lógica de validación de datos. 6. Se envía el mensaje de éxito o error. Los componentes que integran la solución son los siguientes: Servicio web, utilizado como interfaz de acceso. BPM, utilizado como control de flujo. ESB, utilizado como canal de comunicación. Servicio web Para dar flexibilidad y estandarización a la solución se establece que la única interfaz de acceso al proceso de intercambio es vía servicio web. Este servicio web es el encargado de validar que el archivo a intercambiar sea un XML y tenga la estructura correcta para el tipo de archivo indicado. Utiliza el estándar dictado por la W3C para intercambio de archivos binarios y de gran tamaño, MTOM [19], mediante la API JAX-WS [20], que es parte del estándar de Java EE. El método que se publica en este servicio web tiene la siguiente definición: public String enviararchivo(string nombrearchivo, byte[] archivo) throws RemoteException, Exception El método enviararchivo recibe como parámetros: nombrearchivo: el nombre del archivo que se intercambia. archivo: los bytes del contenido del archivo. Con el nombre se identifica el tipo de documento que se está enviando y se utiliza para realizar la validación contra el archivo XSD. Para la validación de los esquemas de los archivos que contienen los datos a transferir es usado Java XML Validation API. Para ello se debe definir dentro del encabezado de los archivos XML los valores xmlns:xsi y xsi:nonamespaceschemalocation, los cuales corresponden al XMLSchema-Intance y URL donde se encuentra publicado el XSD respectivamente. Esta forma de validación dinámica da la flexibilidad para que el servicio web maneje cualquier nuevo XML que se desee cargar únicamente al publicar el XSD específico que hará la validación. Los servicios web, para poder ser ejecutados y estar disponibles, deben ser desplegados en un servidor de aplicaciones; en este caso, el Banco cuenta con Oracle WebLogic Application Server para realizar dicha actividad de despliegue. Además, el servicio web se debe registrar en el BUS de datos para estar visible para todas las aplicaciones de la entidad bancaria y para adicionar futuras capas de servicios. El mensaje de éxito o error puede ser uno de los tipificados en la Tabla 1. Tabla 1. Tabla de códigos de respuesta utilizados por los servicios web Código Descripción Uso 100 Error de conexión Se envía cuando la conexión no se logra establecer o se pierde. 101 Error de lectura Se envía cuando no se puede leer el archivo origen. 102 Error de escritura Se envía cuando no se puede escribir el archivo destino. 103 Error de formato Se envía cuando el formato del archivo XML no es el requerido. 104 Error de contenido Se envía cuando el archivo XML no contiene los tipos de dato esperados. 110 Conexión aceptada Se envía cuando la conexión inicial es satisfactoria. 111 Archivo recibido Se envía cuando el archivo XML se recibe satisfactoriamente. 112 Formato Se envía cuando el formato del válido 113 Contenido válido archivo XML es correcto. Se envía cuando el contenido del archivo XML contiene los tipos de dato esperados. 114 Escritura satisfactoria Se envía cuando la escritura del archivo destino es satisfactoria. 115 Lectura satisfactoria Se envía cuando la lectura del archivo origen es satisfactoria. 200 Desconocido Se envía cuando el resultado del proceso no puede ser identificado. Seguridad del servicio web La transferencia de información desde las IFI hasta el banco de segundo piso requiere de la utilización de los mejores métodos de protección con el objetivo de mantener integridad y confiabilidad de los datos, así como para evitar posibles plagios que pongan en riesgo tanto a las instituciones como a los usuarios del sistema financiero. Para cumplir con este requerimiento el presente diseño hace uso de las bondades ofrecidas por WebLogic [19]. Existen varios métodos para asegurar los servicios web; sin embargo, se propone el uso del certificado digital porque este método encripta el mensaje desde su origen hasta su destino, aunque en el medio se encuentren dispositivos intermediarios, ya sean estos enrutadores (routers), cortafuegos, etc. Los siguientes pasos son necesarios para obtener la seguridad que se busca en el proceso de intercambio de información: 1. Crear el certificado: el certificado X.509 se crea según la especificación de WS-Security [19], disponible en WebLogic, además del usuario que mapea el LDAP que autentica los usuarios. Es imprescindible que el certificado sea emitido por una9 9 entidad certificadora, aun cuando el certificado pueda ser autofirmado. 2. Configuración del servidor: se procede a configurar la carga del certificado en la consola de configuraciones de WebLogic al colocarlo dentro del grupo de certificados confiables, y se le indica a la pila de seguridad del servicio web que haga la propagación de la identidad cuando se le entrega la credencial o ficha X Configuración del servicio web: el servicio web debe especificar las políticas a utilizar por medio de una anotación en su archivo de configuración. 4. Configuración del cliente: el consumidor del servicio web debe especificar el parámetro que indica que política se está utilizando en el servicio web. Con lo anterior se encripta el mensaje entre el servicio web y el cliente, sin importar qué herramienta se use para crear el servicio web, ni cuántos intermediarios existan entre el servicio web y el cliente. Gestión de Procesos de Negocio (BPM) En el diseño propuesto se establece la utilización de BPM para dar la posibilidad de tener la flexibilidad de modificar el flujo que conlleva la carga de archivos XML. En este sentido, la herramienta a utilizar es Oracle Business Process Management, con la que también cuenta el Banco. Oracle BPM provee múltiples herramientas para desarrollar, dentro de los sistemas informáticos, los diferentes componentes de los procesos de negocios, entre ellos: Tareas humanas: para ellas provee una interfaz gráfica donde realizar autorizaciones o ingresar información adicional al proceso ejecutado. Reglas de negocio: se evalúan en tiempo real mediante los parámetros ingresados y realiza la toma de decisiones dentro del flujo del proceso. En el diseño propuesto únicamente se incluye la selección del procedimiento de base de datos que se invocará para realizar la validación de datos; esta selección se realiza mediante la utilización de Oracle Business Rules con el objetivo de adicionar dinámicamente nuevas cargas de archivos. Sin embargo, el banco podrá adicionar más validaciones dentro de los procesos de negocio, por ejemplo: validar si la empresa está en cierre contable, solicitar autorizaciones del personal gerencial, etc. Esto último, sin embargo, está fuera del alcance de esta propuesta. De la misma manera, se cuenta con un procedimiento almacenado genérico encargado de llamar dinámicamente el procedimiento almacenado que realiza la validación de datos para un archivo XML específico. Este procedimiento genérico tiene la siguiente definición: loadvalidator (idprocess as varchar 2, procedure as varchar2, blob xml ) as varchar2 El procedimiento almacenado recibe como parámetro: idproceso: identificador único de proceso generado por BPM. procedure: nombre del procedimiento encargado de realizar la validación de datos. blob: contiene los bytes que corresponden a la información del XML. Para realizar la carga dinámica se utiliza la sentencia de la base de datos execute immediate. Todos los procedimientos de validación de datos deben tener estas variables de entrada para estandarizar la llamada a dichos procedimientos. Recapitulando, los procesos de negocio iniciarán con la llegada de un mensaje a través del servicio web descrito en el literal C del Diseño Propuesto, y se utiliza reglas de negocios para seleccionar dinámicamente el nombre del procedimiento almacenado de base de datos que realiza la validación de datos. Con el nombre del procedimiento se realiza la llamada al procedimiento genérico. Bus de Servicios Empresariales (ESB) El diseño propuesto incluye un ESB, el cual es el canal de comunicación entre las diferentes aplicaciones y servicios, lo que ofrece una gran escalabilidad, autonomía de los servicios publicados y acceso inmediato entre aplicaciones. Se ha utilizado el ESB como intermediario de los siguientes puntos: Punto de acceso al servicio web que contiene el método enviararchivo, el cual permite que sea accesible desde cualquier punto de la empresa. Punto de acceso para el servicio de negocio en el cual se realiza la llamada a la validación de datos. Punto de acceso para el procedimiento que llama la validación de datos, directamente a la base de datos. Punto de acceso para el envío de los mensajes. Para el caso del Banco, se utiliza otra de las herramientas con las que cuenta, Oracle Service Bus, el cual implementa adaptadores para extender la funcionalidad y permitir la autonomía de cada uno de los servicios. Finalmente, las ventajas de tener una solución como la propuesta son que, por un lado, es altamente escalable, eficiente y flexible para realizar modificaciones de acuerdo a las necesidades de la entidad bancaria; y por el otro, la facilidad que brinda la solución para la adecuación de nuevas cargas, lo que estandariza en gran medida el proceso de carga de archivos. La adecuación necesaria para realizar nuevas cargas se resume en los siguientes pasos: 1. Crear archivo XSD, que realizará la validación de la estructura del nuevo archivo XML a cargar. 2. Agregar el nuevo nombre de archivo y el flujo necesario utilizando las reglas de negocio del BPM. 3. Generar un procedimiento almacenado dentro de la base de datos que realice la validación de los datos. Estándar de formato para el intercambio de información Una característica adicional que proporciona la solución propuesta es la posibilidad de generar y/o utilizar un estándar de formato para el intercambio de información de la entidad financiera de segundo piso, lo que se realiza a través de los archivos de esquema (XSD).10 10 Como parte de la investigación para realizar esta estandarización se analizaron los estándares internacionales descritos en el Marco Teórico, XBRL y GEL-XML. Estos han sido descartados ya que como resultado del análisis se ve la importancia que tiene el ser promovido, gestionado y actualizado por una entidad gubernamental local. En el caso de El Salvador debería existir un estándar similar y ser promovido por el Ministerio de Hacienda, la Superintendencia del Sistema Financiero y el Banco Central de Reserva de El Salvador, con el objetivo de que las finanzas del Estado y de las entidades financieras que ellos regulan manejen el mismo estándar para facilitar el intercambio de información entre dichos organismos. Por lo anterior, se decide realizar un estándar a la medida para la entidad bancaria como parte de la propuesta, tomando como base las buenas prácticas analizadas en los estándares mencionados, con el objetivo de que la entidad bancaria pueda utilizarlo para facilitar la generación de intercambios de información de sus nuevos procesos de negocio. Este estándar a la medida se encuentra documentado en el Apéndice B. D. Creación de la arquitectura física Como resultado del análisis de las entrevistas y documentación oficial de Oracle [18] se propone la arquitectura física detallada en la Fig. 16, la cual cumple el requerimiento no funcional NF-1 del Apéndice A. E. Definición del nivel de servicio El diseño propuesto busca cumplir con un alto nivel de servicio tanto para el cliente externo como para el interno, sea este persona o proceso de negocio. El nivel de servicio se definió en función de los niveles de capacidad, disponibilidad, continuidad y seguridad, los cuales se describen a continuación: Capacidad altamente escalable tanto en procesamiento como en almacenamiento de la información, los cuales se pueden extender casi ilimitadamente, así como también en la capacidad de crecimiento de la lógica del proceso de intercambio. Por ello, se estima un 100% de nivel de crecimiento. Disponibilidad basada en redundancia de componentes físicos de acceso (cortafuegos), procesamiento (clúster de servidores de aplicación) y almacenamiento (clúster de servidores de base de datos y almacenamiento centralizado). Por ello, se estima un 99.7% de nivel de disponibilidad. Continuidad del servicio apoyado no solo en la redundancia de componentes, sino en la reutilización y adecuación de los componentes lógicos descritos en el literal C del diseño propuesto, lo cual facilita la actualización del mismo sin necesidad de detener el servicio de intercambio y acceso a la información. Por ello, se estima un 99.5% de nivel de continuidad. Seguridad apoyada por equipos físicos, a través de reglas de conexión y clientes VPN en los cortafuegos, y por software, a través del encriptamiento de la información desde el punto de origen (IFI) hasta el punto de destino (Banco) durante todo el proceso de intercambio. Se estima un 99.99% de nivel de seguridad. De acuerdo a lo anterior, se considera un nivel de servicio muy bueno para uno de los procesos más importantes de una entidad bancaria de segundo piso. V. INVERSIÓN ESTIMADA EN INFRAESTRUCTURA Ya que también se busca apoyar una futura implementación del diseño propuesto en el Banco, se realizó el análisis de los componentes físicos, de software (licenciamiento) y soporte técnico con los que cuenta actualmente para así determinar qué productos se requiere comprar y/o contratarse para llenar la brecha tecnológica, de forma que se cumplan satisfactoriamente las expectativas de los clientes, ya sean internos o externos. Como punto de partida, la infraestructura con la que se cuenta es bastante madura. Se encontraron servidores de características recientes con plataformas Oracle SOA Suite y Oracle BPM instalada, servidor independiente para base de Fig. 16 Arquitectura física11 11 datos con instancias Oracle, redundancia de proveedor de acceso a Internet, equipos y software de seguridad. Sin embargo, es necesario fortalecer la infraestructura según se especifica en los requerimientos no funcionales (NF) descritos en el Apéndice A, y en el cuadro de inversión detallado en el Apéndice C para alcanzar los niveles de disponibilidad, capacidad, continuidad y seguridad esperados para uno de los procesos vitales de una institución bancaria de segundo piso. Los cambios propuestos a la infraestructura tecnológica que está involucrada directamente en el proceso de intercambio de información son: Un segundo equipo cortafuegos con funciones de enrutador y concentrador de redes privadas virtuales (VPN), con capacidad para 200 clientes simultáneos, para formar un arreglo que brinde alta disponibilidad a los clientes que realizan el envío de la información involucrada en el proceso diseñado. Un servidor para formar un arreglo con el servidor de base de datos existente, con capacidad de operar en balanceo de carga y que sea capaz de brindar servicio en alta disponibilidad. Con esta configuración se elimina el punto único de falla en el acceso a los datos. Dos licencias del producto Oracle empresarial con la característica de Real Aplicación Cluster (RAC) para ser utilizada en el arreglo de servidores descrito en el punto anterior. Los cambios propuestos a la infraestructura tecnológica alcanzarían una inversión aproximada de US$ 79, y brindará una disponibilidad aproximada de 99.7%, según se muestra en la tabla 6 del Apéndice C. Además, tras la investigación realizada acerca de los recursos disponibles para mejorar la infraestructura se encontró que han iniciado gestiones para un crecimiento y mejora de la tecnología existente en el centro de cómputo y en licenciamiento. Entre esta, se contempla la compra de los componentes que brindan una alta disponibilidad de la base de datos. Se estima que dentro del presupuesto del departamento encargado de infraestructura tecnológica se ha asignado el 75% del total para inversión en este rubro. Finalmente, los cambios a la infraestructura propuestos por el diseño sugieren la siguiente secuencia: 1. Fortalecimiento de la infraestructura de base de datos: Oracle Real Application Clusters (RAC). 2. Fortalecimiento de la infraestructura de redes y seguridad perimetral: VPN, Firewall, Certificado digital. VI. BENEFICIOS ESPERADOS El proceso propuesto para el intercambio de información entre las instituciones financieras y el banco de segundo piso incorpora las mejoras mostradas en la Tabla 2 y se describen como beneficios a corto y mediano plazo en los párrafos subsiguientes. Tabla 2. Tabla de mejoras más importantes incorporadas en el diseño propuesto. Características Sistema actual Diseño propuesto Validar archivos Manual y intercambiados automático Automático Respuestas del Manual y sistema automático Automático Seguridad Usuario y Firma digital con contraseña certificado X.509 KPI del sistema No se puede obtener Se puede obtener Alta disponibilidad de acceso al sistema No existe Se incorpora Alta disponibilidad de acceso a datos No existe Se incorpora Estandarización de documentos No existe Se incorpora Mejoras a corto plazo 1. Optimización del tiempo que toma la validación de los archivos intercambiados. Dicha validación será inmediatamente después de recibir el archivo XML. 2. Mejora significativa en el tiempo en que se notifica a las instituciones financieras acerca de errores contenidos en los archivos XML enviados. La notificación será inmediata, luego después de recibir el archivo XML. 3. La seguridad de la información que se intercambia mejorará con el uso del certificado digital propuesto por el diseño. Mejoras a largo plazo 1. Medición de la cantidad de errores y tipos de errores contenidos en los archivos XML. Con esto se mejorará a largo plazo la eficiencia del proceso, al tomar acciones encaminadas a evitar los errores más comunes. 2. La disponibilidad del proceso de intercambio de información mejorará con los cambios propuestos en la infraestructura que provee el servicio de acceso a los datos. 3. Confiabilidad en el proceso de intercambio de información. A medida que las instituciones financieras usen el sistema, se verán beneficiados con el reporte inmediato del resultado de la validación y/o carga de los archivo XML enviados. 4. Estandarización de documentos. Con el diseño propuesto para los documentos XML que contienen la información intercambiada, se obtiene una interfaz de comunicación estándar entre los procesos de negocio, lo que facilitará futuros diseños de otros procesos. VII. CONCLUSIONES A continuación, enlistamos las resoluciones que, a nuestro juicio, aportan el sentido a la investigación, al análisis y al diseño de la propuesta de solución para el problema de intercambio de información entre una entidad bancaria de12 12 segundo piso y las instituciones intermediarias. Con el estudio y análisis realizado a la Ley de Bancos de El Salvador y la Ley del Sistema Financiero para Fomento al Desarrollo se concluye que es necesario mantener un control de las operaciones de los créditos realizados por las IFI con los fondos del Banco, y que, además, es el Banco el que determina la mejor forma de realizar este control. Es aquí donde el diseño de la solución propuesta busca ser lo suficientemente robusta y flexible para suplir las necesidades provenientes del intercambio de información de créditos. Luego de realizar el proceso investigativo ya indicado, conocer el conjunto de etapas involucradas y normativas de ejecución del proceso de intercambio de información de un banco de segundo piso de El Salvador permite concluir que este proceso es de vital importancia, puesto que proporciona los insumos necesarios para muchos de sus procesos de negocio. Por ello, se propusieron mejoras en el proceso de intercambio de información que brindan a la entidad bancaria la oportunidad de agilizar los trámites del proceso y facilitar la ejecución del mismo. Para una mayor comprensión, estas mejoras se diagramaron en un BPMN. Después de investigar estándares internacionales para el intercambio de información financiera se concluye que existe una gama de posibilidades de las que el Banco podría hacer uso; lamentablemente, la implementación de estos estándares internacionales debería ser promovido, gestionado y actualizado localmente por el Gobierno de El Salvador con el objetivo de que todas las entidades financieras y bancarias manejen un mismo estándar, lo cual hasta la fecha de finalización de este trabajo no había sucedido. No obstante, como parte del diseño desarrollado, se elaboró un estándar que el Banco podrá utilizar para facilitar la comprensión del intercambio de información con las IFI. Debido a la naturaleza del problema y las extensas posibilidades que ofrece, y luego de revisar diversas arquitecturas de software existentes, se concluyó que la arquitectura orientada a servicios es la que mejor se adapta a las necesidades del proceso de intercambio de información; es por ello que se han utilizado algunos de sus componentes y buenas prácticas comprobadas para realizar el diseño propuesto. Con la creación del estudio de factibilidad técnico y financiero que enmarca los componentes tecnológicos por medio de un cuadro de costos de la tecnología necesaria, y teniendo en cuenta la infraestructura existente en el Banco, se concluye que es factible realizar la inversión para implementar el diseño de solución.13 13 REFERENCIAS [1] Banco de Comercio Exterior de Venezuela, [En línea]. Disponible en: [Consultado el 12 de noviembre de 2012]. [2] Corporación Financiera de Desarrollo S. A. de Perú, [En línea]. Disponible en: [Consultado el 12 de noviembre de 2012]. [3] Superintendencia del Sistema Financiero de El Salvador, [En línea]. Disponible en: =374&Itemid=68 [Consultado el 12 de noviembre de 2012]. [4] M. Keen, A. Acharya, S. Bishop, A. Hopkins, S. Milinski, C. Nott, R. Robinson, J. A. y. P. Verschueren and Patterns, Implementing an SOA Using an Enterprise Service Bus, IBM Corp., [5] J. Brochard, XML: Conceptos e implementación, Barcelona: Ediciones Software SL, [6] IBM developerworks, Introducción a SOA y servicios web [En línea]. Disponible en: ml [Consultado el 01 de diciembre de 2012]. [7] O. Zimmermann and F. Mueller, Web Services project roles, The team perspective, [En línea]. Disponible en: [Consultado el 01 de diciembre de 2012]. [8] G. Son, U. Zorrilla and J. Serrano, Introducción a.net con Visual Basic [9] J. F. Pérez, Taller de Seguridad en SOA, [10] Gestión por proceso de negocio Disponible en: [Consultado el 05 de enero de2013]. [11] J. H. Arias, ESB: Enterprise Services Bus (Novell), Bogotá, [12] N. Fernández, "Universidad Carlos III de Madrid", 06 junio [En línea]. Disponible en: [Consultado el 1 de diciembre de 2012]. [13] V. Muñoz, "Comunidad de Madrid del Área de Aplicaciones Especiales y Arquitectura de Software de ICM," 20 julio [En línea]. Disponible en: l/presentaciones/esb_for_introduccion.pdf [Consultado el 01 de diciembre de 2012]. [14] C. d. l. T. Llorente, U. Z. Castro, J. C. Nelson and M. Á. R. Barroso, Guía Arquitectura N-Capas Orientada al Dominio, España: Krasis Press, [15] C. Hoffman, What Is XBRL, UBmatrix, [16] Asociación XBRL España, "XBRL y el Anteproyecto de ley de Transparencia, acceso a la información pública y buen gobierno", CANAL XBRL, p. 1, [17] SOAP Message Transmission Optimization Mechanism [En línea] [Consultado el 04 de enero de 2013] [18] JAX-WS [En línea] [Consultado el 04 de enero de 2013 [19] Oracle Fusion Middleware [En línea]. Disponible en: tml [Consultado el 02 de enero de 2013]. [20] Oracle Fusion Middleware [En línea] Disponible en: [Consultado el 09 de enero de 2013].14 14 APÉNDICES Apéndice A Casos de Uso En los casos de uso se documentan las actividades y los procesos que pueden ser desarrollados por un usuario o sistema en su interacción con el proceso en estudio. Estos procesos han sido segmentados de acuerdo al tipo de función que desempeñarán en el software para facilitar su análisis y entendimiento en los siguientes pasos: Validación de formato Validación de información Carga de datos Envío de mensajes Usuarios Precondiciones Curso básico de eventos Caminos alternativos Condiciones posteriores Usuarios Precondiciones Curso básico de eventos Caminos alternativos Condiciones posteriores Usuarios Precondiciones Curso básico de eventos CUR-1: Validar formato Validación de formato requerido para el intercambio de información. El proceso de intercambio de información se apoya en el uso de XML y XSD para dar formato a los datos y validarlos respectivamente. Se requiere de un procedimiento para realizar la validación del formato del documento XML, lo que permitiría que el flujo continúe sin errores de formato o se descarte. Sistema de la entidad financiera intermediaria, usuarios del sistema. Poseer un acceso seguro al servicio web. 1. El sistema de la institución financiera le da formato al archivo XML que contiene los datos a enviar. 2. El sistema de la institución financiera intermediaria envía el archivo XML. 3. El servicio web recibe el archivo en formato XML. 4. El servicio web valida que los campos solicitados están contenidos en el archivo. 5. El servicio web devuelve el código correspondiente al resultado de recepción. 1. En el paso 3, si el servicio web no recibe completo el archivo XML, devuelve el código de error correspondiente y se cancela el proceso. 2. En el paso 4, si el archivo XML recibido no contiene los campos esperados, se devuelve el código de error correspondiente y se cancela el proceso. El archivo XML recibo está validado. CUR-2: Validar información Valida la información contenida en el archivo XML. Asegurar que la información contenida en el archivo XML recibido contiene los tipos de datos esperados. Sistema de la entidad financiera intermediaria, usuarios del sistema. El formato del archivo XML recibido ha sido validado. 1. El archivo XML se ingresa al validador XSD para asegurar que los campos y tipos de datos recibidos son los esperados. 2. El archivo es aceptado y se envía el correspondiente código de aceptación a sistema al cliente que envía el archivo. 1. En el paso 1, si el archivo XML no contiene los tipos de datos esperados, se envía el correspondiente código de error y se cancela el proceso. Los datos contenidos en el archivo XML han sido validados. CUR-3: Carga de información Se realiza la carga de la información recibida por el archivo XML. Cargar la información enviada por las instituciones financieras intermediarias. Sistema de la entidad financiera intermediaria, usuarios del sistema. La información contenida en el archivo XML posee los tipos de datos esperados. 1. Se recibe el archivo XML con formato y datos validados. 2. El sistema verifica que la información recibida en el archivo XML aún no existe en la base de datos. 3. Se carga la información recibida en el archivo XML.15 15 Caminos alternativos Condiciones posteriores Usuarios Precondiciones Curso básico de eventos Caminos alternativos Condiciones posteriores 4. El sistema devuelve el correspondiente código de aceptación. 1. En el paso 2, si la información contenida en el archivo XML ya ha sido cargada, se devuelve el correspondiente código de error y se cancela el proceso. La información recibida en el archivo XML ha sido cargada. CUR-4: Enviar mensaje Enviar mensajes de aceptación o error a las instituciones financieras intermediarias. Notificar de la finalización del proceso de recepción de información. Sistema de la entidad financiera intermediaria, usuarios del sistema. Haber recibido un archivo con información de las instituciones financieras intermediarias. 1. Un componente del sistema de procesamiento de información genera un código de error o aceptación en uno de los pasos requeridos para la carga de información. 2. Se le da formato al mensaje que será enviado. 3. Se envía el mensaje ya sea por SMTP o en la conexión al servicio web. 1. En el paso 3, si el envío del mensaje falla, se procede a reintentar. El mensaje ha sido enviado. Requerimientos funcionales Se describen los requerimientos que permiten al sistema realizar las operaciones necesarias para el cumplimiento de su objetivo, y se detalla cuál es la función que en cada paso se debe ejecutar. Requerimiento Referencias RFR-1: Validación de archivo XML Verificar que los campos definidos como requeridos para cada proceso sean incluidos en el archivo XML. Mantener la consistencia de la información y obtener todos aquellos datos que sean requeridos de forma obligatoria por la aplicación. Al ejecutar el proceso de intercambio de información se requiere que los campos obligatorios estén contenidos en el archivo XML y los datos tengan los tipos definidos en el archivo de validación XSD. Debe verificarse que la información escrita en aquellos campos definidos como obligatorios en cada proceso tenga al menos 1 carácter de longitud. CUR-1: Validar formato CUR-2: Validar información CUR-3: Cargar información Requerimiento Referencias RFR-2: Tratamiento de códigos de error Brindar el tratamiento adecuado a los códigos de error generados por el sistema de intercambio de información. Debido a que la operación del sistema no está exenta de errores se debe ejecutar un procedimiento efectivo de captura de las excepciones que ocurran e interpretarlas correctamente para notificar a los sistemas o usuarios involucrados acerca del resultado de las acciones solicitadas, con el objetivo de mantener la confiabilidad del proceso y la integridad de la información almacenada en la base de datos. Capturar las excepciones generadas por el sistema para crear los mensajes de error o aceptación que serán enviadas a los involucrados en el proceso de intercambio de información. CUR-1: Validar formato CUR-2: Validar información CUR-3: Cargar información CUR-4: Enviar mensajes Requerimiento RFR-3: Carga de información Cargar la información recibida en los archivos XML. El control de la información generada de la operación del banco de segundo piso por medio de las instituciones financieras intermediarias requiere de intercambio de información entre los involucrados con el objetivo de auditar y controlar el uso de los fondos provistos por el banco de segundo. La información enviada por las instituciones financieras que realizan transacciones con fondos del banco de segundo piso deben almacenarse en una base de datos con la finalidad de controlar y auditar16 16 Referencias Requerimiento Referencias RFR-3: Carga de información el uso de los fondos provistos por el banco de segundo piso. CUR-1: Validar formato CUR-2: Validar información CUR-3: Cargar información RFR-4: Envío de mensajes Enviar los mensajes necesarios para comunicar a los diferentes actores el resultado de su interacción con el sistema. Cuando un proceso llega a un punto donde se evalúan los resultados de su actividad en el sistema, se notifica a los actores, ya sean estos personas o sistemas. Dar formato a un mensaje de manera que pueda ser interpretado correctamente por el destinatario; el mensaje debe ser formateado para ser enviado por SMTP cuando es para una persona, y en formato de código de tres dígitos si es para un sistema. CUR-1: Validar formato CUR-2: Validar información CUR-3: Cargar información CUR-4: Enviar mensajes Requerimientos no funcionales Se describen aquellos requerimientos que no dependen del funcionamiento del sistema en sí, si no que se refieren a su rendimiento, al grado de satisfacción que pueden generar en el usuario y si este cumple o no con lo esperado. Describen, más que todo, el entorno donde el sistema funciona, por lo que abarcan factores externos al funcionamiento mismo de la aplicación internamente. Requerimientos Referencias Requerimientos Referencias NF-1: Equipo recomendado para la implementación Requerimientos mínimos para implementar el software. Si el hardware no es suficientemente capaz de soportar la carga de operación del software, los usuarios experimentarán problemas para entregar la información solicitada y el sistema no será efectivo. 1 clúster activo/activo de 3 servidores virtuales de dos procesadores QuadCore y 24 GB RAM para SOA Suite, BPM, Weblogic. 1 clúster activo/activo de 2 servidores Intel de dos procesadores QuadCore y 64GB RAM para procesamiento de la información enviada por las instituciones financieras intermediarias. SAN con 6TB, para almacenamiento de información enviada por las instituciones financieras intermediarias. 2 enlaces a internet de 10 Mbps en redundancia con diferentes proveedores para conexión a internet, que se usarán para establecer las conexiones VPN con las instituciones financieras intermediarias. 1 clúster de 2 cortafuegos/vpn para protección de la infraestructura de servidores que, además, harán la función de ruteo de la red local hacia el internet y concentrarán las VPN. Sistema operativo Linux 64Bits. No aplica. NF-2: Personal Personal necesario para realizar el proyecto. Si el personal no es suficiente e idóneo, el software podría no cumplir con los requerimientos de calidad y fallaría la implementación final del proyecto. 1 analista de requerimientos con perfil y experiencia suficiente para tomar los requerimientos. 2 diseñadores para crear el diseño del software a construir. 2 desarrolladores que crearán el código de los programas a construir. 1 gerente de proyecto. NF-1: Equipo recomendado para la implementación. NF-3: Lenguaje de programación Lenguaje a utilizar para la programación del proyecto.17 17 Requerimientos Referencias Requerimientos Referencias Requerimiento Referencias Requerimiento Referencias Requerimientos Referencias Requerimientos Referencias NF-3: Lenguaje de programación Si el lenguaje utilizado en la programación del sistema no es eficiente, el proyecto podría fallar debido a bajo rendimiento e insatisfacción de los usuarios. Se recomienda Java como lenguaje de programación, aunque su uso no es imprescindible. NF-1: Equipo recomendado para la implementación. NF-4: Base de datos Base de datos a utilizar para almacenar la información intercambiada con las instituciones financieras. Si la base de datos a utilizar en el proyecto no es funcional o económicamente factible, el proyecto podría fracasar debido a exceso de costos de soporte y licenciamiento. Se utilizará la base de datos Oracle 11G r2 Enterprise. NF-1: Equipo recomendado para la implementación. NF-5: Rapidez en las consultas Las búsquedas se deben realizar de una forma rápida para que no demoren en cargar la información. Si la búsqueda no es lo suficientemente rápida, los usuarios tendrán una mala percepción de la aplicación. Dotar de suficientes recursos a los servidores tales como un buen procesador, memoria RAM o incluso la capacidad y ancho de banda de la red para que no se perciba lentitud en las conexiones y transferencias de archivos. No disponible. NF-6: Entorno amigable y funcional Pantallas que permitan al usuario hacer un uso fácil de la aplicación. Las pantallas deben ser amigables y funcionales, con pasos simples a realizar por el usuario. Diseñar la aplicación con un entorno funcional y fácil de usar cuya presentación permita visualizar de manera ordenada los botones y ventanas para fácil acceso. No disponible. NF-7: Características de la conexión La conexión que se establezca debe ser segura. Deberá garantizarse en todo momento que las conexiones son seguras y que la transferencia de los archivos XML que contienen la información viaja por un canal seguro. No disponible. NF-1: Equipo recomendado para la implementación. NF-8: Capacidad de integración e interconexión con otras aplicaciones Utilizar un punto común de comunicación entre los componentes del sistema a través de un BUS. Garantizar una plataforma que permita aprovechar la reutilización de servicios, así como permitir la interconexión e integración con otras aplicaciones. Se utilizará Oracle SOA Suite. NF-1: Equipo recomendado para la implementación.18 18 Apéndice B Fig. 7 Detalle del archivo esperado Fig. 8 Lista de personas19 Fig. 9 Detalle de persona jurídica 1920 Fig. 10 Detalle de persona natural 2021 Fig. 11 Detalle común de persona, sea jurídica o natural 2122 22 Fig. 12 Lista de créditos Fig. 13 Detalle de crédito23 23 Fig. 14 Lista de garantías Fig. 15 Detalle de garantía24 24 Apéndice C A continuación se muestra el detalle de inversión necesaria para mejorar la infraestructura. Para más detalle referirse al Apéndice D. Tabla 3. Requerimientos para servidor de base de datos. Precio estimado US$ 14, (EUR 11,208.77). Equipo y función Componente Especificación Procesador Intel Xeon E5640 (2.66GHz/4-core/12MB/80W, DDR3-1066, HT, Turbo 1/1/2/2) Processor Memoria 32GB Nodo para base de datos Disco 2 HD 146GB para Sistema Operativo Tarjetas Fibra 2 Fibre Channel: Emulex o Qlogic Canal HBA Garantía y soporte 3 años 7X24 con 6 horas de tiempo de respuesta Tabla 4. Requerimientos para firewall/vpn. Precio estimado US$ 18, Equipo y función Componente Especificación Procesador Procesador de 4 núcleos Memoria 2 GB Características Nodo para router/firewall/vpn Garantía Traffic: o Two RJ-45 Ethernet o 10/100/1000/ Full or Half-Duplex (Auto-Negotiation) Management: n/a Fast Ethernet: IEEE 802.3u Compliant Gigabit Ethernet: IEEE 802.3z or IEEE 802.3ab compliant Console: One RJ-45 serial console port Funciones de VPN, IPSec/GRE/L2TP Compact flash port 250 IPSec Tunnels 3 años 7X24 con 4 horas de tiempo de respuesta Tabla 5. Requerimientos para licenciamiento para clúster de base de datos. Precio estimado US$ 46, Software/función Tipo de licencia Por procesador 2 Opciones de base de datos: Oracle Real Application Clusters(RAC) El total de la inversión estimada para mejorar el rendimiento de la infraestructura física que soporta el intercambio de información será de US$ 79, Con las especificaciones de cada uno de los nodos se estima un 99.7% de disponibilidad; asimismo, se considera que se posee soporte de los proveedores de hardware para reemplazo de partes o equipo dañado durante 3 años, con un tiempo máximo de respuesta de 6 horas. Tabla 6. Disponibilidad esperada Caída en minutos por Disponibilidad hora día semana año 99.7% ,577 25 25 Apéndice D Fig. 17 Cotización para arreglo (clúster) de servidores de base de datos Fig. 18 Cotización de Cisco Asa 5520 para arreglo (clúster) de firewall/vpn 26 Fig. 19 Cotización de licencia Oracle Real Application Clusters, para arreglo de base de datos. 26 Mostrar más
Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de Más detalles Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web
Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones Más detalles Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta
INTEROPERABILIDAD ESTÁNDARES APLICADOS EN COSTA RICA Ing. Marco Jiménez HA-2508 SEMINARIO DE TEMAS ARCHIVÍSTICOS 21-09-2010 Temas de la presentación Definiciones Interoperabilidad Sistema Importancia de Más detalles LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS
LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno Más detalles MARCANDO LA DIFERENCIA
MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores Más detalles 2524 Developing XML Web Services Using Microsoft ASP.NET
2524 Developing XML Web Services Using Microsoft ASP.NET Introducción La meta de este curso es de proveer a los estudiantes con el conocimiento y habilidades requeridas para desarrollar soluciones basadas Más detalles LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK
1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada Más detalles DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI
DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI Informe de Práctica Profesional de 4to Año, Ingeniería Informática Autor: Manuel Alejandro Aguilar Díaz Más detalles JAVA EE 5. Arquitectura, conceptos y ejemplos.
Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos Más detalles Herramientas de Software que posibilitan el BPM
Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño Más detalles SIGPRE Sistema de Gestión Presupuestaria
SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009 Más detalles SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO
SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3 Más detalles Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.
SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados Más detalles SOLUCIÓN SITUACIÓN ACTUAL
SITUACIÓN ACTUAL La necesidad de las organizaciones de ser más competitivas en un mercado dinámico ha generado estructuras organizacionales complejas y exigentes en términos de calidad y eficiencia. Sobre Más detalles WebServices bajo SOA. SOAagenda team Chile
WebServices bajo SOA SOAagenda team Chile 1 Conceptos Servicio SOA Una tarea de negocio repetitiva validar Crédito Cliente, que cumple estándares SOA WebService Funcionalidades disponibles vía Web, implementadas Más detalles Glosario Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano
Ministerio del Poder Popular para las Telecomunicaciones y la Informática Centro Nacional de Tecnologías de Información Glosario Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Más detalles SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características
SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario Más detalles VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA
VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA CONCEPTO VPN DEFINICIÓN, QUE SE PUEDE HACER CON UN VPN TIPOS DE VPN - ARQUITECTURA VPN ACCESO Más detalles Oracle Service Bus: Entorno de Desarrollo
Oracle Service Bus: Entorno de Desarrollo Mayo 2012 Versión 1.1 ÍNDICE 1. Introducción al Oracle Service Bus I. Conceptos II. Ventajas del OSB III. Arquitectura Mensajería adaptable Seguridad Unificada Más detalles Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de
Plataforma de Administración Electrónica de la Comunidad Autónoma de la Región de Murcia Director General de Informática Consejería de Economía y Hacienda Comunidad Autónoma de la Región de Murcia Jefe Más detalles Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com
Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad. Más detalles 5.1 Introducción a Servicios Web
5.1 Introducción a Servicios Web Introducción Continuando con el ejemplo de intercambio de información de películas... => Actualmente ya no es necesario implementar la solución sugerida a mano Se han estandarizado Más detalles Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms
Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura Más detalles Programa Agenda de Conectividad Estrategia de Gobierno en línea
Programa Agenda de Conectividad Estrategia de Gobierno en línea República de Colombia - Derechos Reservados Bogotá D.C, Marzo de 2010 PROGRAMA AGENDA DE CONECTIVIDAD ESTRATEGIA DE GOBIERNO EN LÍNEA GUÍA Más detalles Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red.
Funciones de servidor La familia Windows Server 2003 ofrece varias funciones de servidor. Para configurar una función de servidor, instale dicha función mediante el Asistente para configurar su servidor; Más detalles Propuesta de Implementación del Sistema de Banca Móvil para: Banca Universal.
www.roassystems.com.ve www.sistemasroas.com.ve Propuesta de Implementación del Sistema de Banca Móvil para: Banca Universal. Octubre del 2012. Este documento contiene información PROPRIETARIA y CONFIDENCIAL, Más detalles Acoplamiento e interoperabilidad
Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el Más detalles 1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.
ESB NORMATIVA DE DESARROLLO DE PROYECTOS Versión 1.0 Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Área de Aplicaciones Especiales y Arquitectura de Software Hoja de Control Título Normativa Más detalles SISTEMAS DE INFORMACIÓN III TEORÍA
Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué Más detalles CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización
Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia Más detalles Automatizador de Procesos
Automatizador de Procesos Más que un workflow, esta aplicación es un BPM (Business Process Management), una completa plataforma de automatización de procesos, diseñada para apoyar la transformación empresarial; Más detalles EXTENSIBLE BUSINESS REPORTING LANGUAGE : XBRL NOVIEMBRE 2015
DIPLOMADO NIIF PLENAS Y PYMES EXTENSIBLE BUSINESS REPORTING LANGUAGE : XBRL NOVIEMBRE 2015 Agenda Extensible Business Reporting Language 1. Qué es 2. Origen 3. En que consiste la propuesta XBRL 4. Ventajas Más detalles Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano
Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano Introducción Tecnológica Noviembre 2009 Agenda Visión del Proyecto Plataforma de Interoperabilidad Libre Orientada Más detalles CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización
Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización Más detalles SISTEMAS DE INFORMACIÓN DE LA ADMON PÚBLICA. Sistemas de Acceso. Sistemas. Sectoriales. Sistemas. Transversales
Interoperabilidad e Intranet Gubernamental II Taller de Trabajo Red GEALC Plataforma de Interoperabilidad: Lenguaje Común y Enrutador Transaccional Hugo Sin Triana Noviembre 9 de 2006 Director Técnico Más detalles Bases de Datos Especializadas
Bases de Datos Especializadas BASES DE DATOS ESPECIALIZADAS 1 Sesión No. 12 Nombre: DBMS y Tecnología Web Objetivo: Al término de la sesión, el alumno identificará la integración entre DBMS y la web. Contextualización Más detalles Ingeniería de Software en SOA
Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia Más detalles Tecnologías Grid Estándares grid
Tecnologías Grid Estándares grid Master en Sistemas y Servicios Informáticos para Internet Universidad de Oviedo Estándares grid Introducción Introducción Justificación El grid se construye a base de diversos Más detalles ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic
ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia Más detalles SMV. Superintendencia del Mercado de Valores
Anexo 1 Disposiciones complementarias al artículo 5 del Reglamento de Operaciones en Rueda de Bolsa de la Bolsa de Lima. (*) DISPOSICIÓN COMPLEMENTARIA AL ARTÍCULO 5 I. Para las operaciones al contado Más detalles Grado en Ingeniería del Software
Grado en Ingeniería del Software Descripción de los módulos o materias FUNDAMENTOS CIENTÍFICOS PARA LA INGENIERÍA Bases científicas necesarias para cualquier ingeniero informático: Física, Álgebra, Análisis Más detalles 2.1 Compuertas para Bases de Datos
1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación Más detalles MINISTERIO DE HACIENDA INSTRUCTIVO SAFI N 02/2010
INSTRUCTIVO SAFI N 02/2010 ASUNTO: NORMAS PARA EL FUNCIONAMIENTO DE LA ARQUITECTURA TECNOLÓGICA DE LOS SISTEMAS DE: ADMINISTRACIÓN FINANCIERA INTEGRADO (SAFI), INFORMACIÓN DE RECURSOS HUMANOS (SIRH) E Más detalles Consultoría en Arquitectura Empresarial, SOA y de Software
Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA Más detalles Cómo lograr una implementación exitosa de SOA?
Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas Más detalles NIVEL 1. INFRAESTRUCTURA DE REDES
NIVEL 1. INFRAESTRUCTURA DE REDES INFORMES@COMPUSUR.COM.MX WWW.COMPUSUR.COM.MX 1 Contenido NIVEL 1. INFRAESTRUCTURA DE REDES... 4 1.1.- FUNDAMENTOS DE WINDOWS SERVER 2008 Y APLICACIONES DE INFRAESTRUCTURA Más detalles Desarrollo y servicios web
Desarrollo y servicios web Luisa Fernanda Rincón Pérez 2014-2 Qué vimos la clase pasada? Introducción a Big Data Introducción a bases de datos NOSQL Características bases de datos NOSQL MongoDB como motor Más detalles MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA
MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA Aprobando mediante Resolución de Gerencia General N 052-2015 de fecha 26 Junio 2015 ELABORADO POR: APROBADO POR: 1 de 82 ÍNDICE 1 INTRODUCCIÓN... Más detalles Service Oriented Architecture
Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos Más detalles Capítulo I. Marco Teórico
1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende Más detalles MANUAL DE FUNCIONAMIENTO DEL SIP. Actualizado con las observaciones del CTSP en la 18ª Reunión.
MANUAL DE FUNCIONAMIENTO DEL SIP Actualizado con las observaciones del CTSP en la 18ª Reunión. A. FUNDAMENTO LEGAL B. OBJETO C. AMBITO DE APLICACIÓN D. RESPONSABILIDAD E. CARACTERÍSITICAS DEL SISTEMA I. Más detalles Historial de Revisiones
Página: 1 Especificación de Requerimientos de Software Plataforma Libre Orientada a Servicios para la Gestión de Trámites a través de Gobierno Electrónico (Actualización FASE I) Historial de Revisiones Más detalles Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales
Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi Más detalles 3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.
Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas Más detalles Tema 4. Diseño arquitectónico.
Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es Más detalles SUPLEMENTO EUROPASS AL DIPLOMA DE TÉCNICO SUPERIOR DE FORMACIÓN PROFESIONAL
SUPLEMENTO EUROPASS AL DIPLOMA DE TÉCNICO SUPERIOR DE FORMACIÓN PROFESIONAL DENOMINACIÓN DEL TÍTULO (ES) Técnico Superior en Administración de Sistemas Informáticos en Red TRADUCCIÓN DE LA DENOMINACION Más detalles Una puerta abierta al futuro
Una puerta abierta al futuro SOA E ITIL EN LA LEY DE ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS (LAECSP) por francisco javier antón Vique La publicación de la Ley de Acceso electrónico Más detalles Xaguar Soluciones PORTALES PORTALES
Xaguar Soluciones PORTALES PORTALES XAGUAR e-suite HABILITANDO PORTALES La implementación exitosa de integración de aplicaciones colaborativas e iniciativas SOA, BPM, ECM o de integración depende en gran Más detalles Nuevo Esquema de Emisión de Comprobantes Electrónicos
Nuevo Esquema de Emisión de Comprobantes Beneficios a los contribuyentes y a la sociedad Nuevo Esquema de Emisión de Comprobantes El Servicio de Rentas Internas pone a disposición de los sujetos pasivos Más detalles Proyecto Piloto. Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE
Proyecto Piloto Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE Contenido Punto de Partida Objetivos Solución Propuesta Como Trabajaremos Calendario de Alto Nivel Siguientes Pasos Más detalles Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.
Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias Más detalles ADMINISTRACIÓN ELECTRÓNICA EN EL AREA DE JUSTICIA.
ADMINISTRACIÓN ELECTRÓNICA EN EL AREA DE JUSTICIA. CASO PRÁCTICO REGISTRO DE CONTRATOS DE SEGUROS CON COBERTURA POR FALLECIMIENTO INDICE Negocio - Introducción - Proyecto Pionero - El Cliente - Valores Más detalles DATOS IDENTIFICATIVOS DEL MÓDULO FORMATIVO IMPLANTACIÓN DE APLICACIONES WEB EN ENTORNO INTERNET, INTRANET Y EXTRANET.
MÓDULO FORMATIVO DATOS IDENTIFICATIVOS DEL MÓDULO FORMATIVO IMPLANTACIÓN DE APLICACIONES WEB EN ENTORNO INTERNET, INTRANET Y EXTRANET. Duración 90 Código MF0493_3 Familia profesional INFORMÁTICA Y COMUNICACIONES Más detalles Modelado de Procesos de Negocio con BPMN Francisco Ruiz http://alarcos.inf
Modelado de Procesos de Negocio con BPMN Francisco Ruiz http://alarcos.inf alarcos.inf-cr.uclm.escr.uclm.es Universidad de Castilla-La Mancha Procesos de Negocio y su Tecnología Procesos de Negocio Un Más detalles Generalitat de Catalunya Departamento de Economía y Conocimiento Junta Consultiva de Contratación Administrativa
Informe 7/2015, de 23 de julio, de la de la Generalitat de Catalunya (Pleno) Asunto: Proyecto de orden por la cual se aprueba la aplicación del Tramitador Electrónico de Expedientes de Contratación (TEEC) Más detalles Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V
Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz Más detalles OBSERVACIONES AL PLIEGO DE CONDICIONES DEL PROCESO No. 03 DE 2015
Bogotá D.C., 19 de Marzo de 2015 Señores PROCURADURIA GENERAL DE LA NACIÓN administrativa@procuraduria.gov.co Ciudad Ref: OBSERVACIONES AL PLIEGO DE CONDICIONES DEL PROCESO No. 03 DE 2015 Respetados señores, Más detalles RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide
Introducción Objetivos del Curso Al finalizar este curso, debería estar capacitado para: Instalar, crear y administrar Oracle Database 11g Versión 2 Configurar la base de datos para una aplicación Utilizar Más detalles Universidad Nacional Autónoma de México Dirección de Sistemas Dirección General de Personal
Universidad Nacional Autónoma de México Dirección de Sistemas Dirección General de Personal Presenta: Mtro. Israel Ortega Cuevas para la Red Universitaria de Colaboración en Ingeniería de Software y Base Más detalles Comunicación Segura y Certificados
Página 1 de 7 Comunicación Segura y Certificados Este documento es propiedad de la Dirección General de Telecomunicaciones y Nuevas Tecnologías y se le ha establecido un nivel de seguridad acorde a la Más detalles SIGFE 2.0. Principales beneficios para la gestión, la operación y el control de los recursos públicos
SIGFE 2.0 Principales beneficios para la gestión, la operación y el control de los recursos públicos Andrés Alarcón Jefe Área Mantenimiento SIGFE 2.0 División de Tecnologías de la Información DIPRES SIGFE Más detalles INFORME Nº 021-2013-GTI INFORME TÉCNICO PREVIO DE EVALUACIÓN DE SOFTWARE
INFORME Nº 021-2013-GTI INFORME TÉCNICO PREVIO DE EVALUACIÓN DE SOFTWARE 1. Nombre del Área El área encargada de la evaluación técnica para la adquisición de una (01) licencia del software Check Point Más detalles WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8
WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina Más detalles Especificación WebService para:
Especificación WebService para: Bandeja de salida Carga masiva Consulta de reportes Bogotá, Diciembre 2010 Modelo Unico de Ingresos, Servicio y Control Automatizado Contenido Procedimiento y Especificación Más detalles Escuela de Ingeniería en Informática Empresarial SYLLABUS
Nombre módulo PROGRAMACIÓN Y TALLER DE INTERNET Nº créditos 10 ECTS ( 270 horas totales, 108 horas presenciales, 162 horas de trabajo autónomo) Nivel Requisitos Responsable(s) de la construcción del syllabus Más detalles SISTEMA UNIFICADO DE CONTROL EN TIEMPO REAL (SUCTR)
SISTEMA UNIFICADO DE CONTROL EN TIEMPO REAL (SUCTR) Sistema Unificado de Control en Tiempo Real - SUCTR: El sistema unificado de control en tiempo real, en adelante SUCTR, es un sistema de administración Más detalles SUPLEMENTO EUROPASS AL TÍTULO
SUPLEMENTO EUROPASS AL TÍTULO DENOMINACIÓN DEL TÍTULO Técnico Superior en Desarrollo de Aplicaciones Web -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Más detalles PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto
PORTAL DE INTEGRACIÓN DE BANCOS DE INFORMACIÓN DISPERSOS A TRAVÉS DE WEB SERVICES Autor: Ing. Walther Antonioli Ravetto Introducción: Sobre casi cualquier tema del quehacer humano que se aborde, existen Más detalles Guía Metodológica para el diseño de procesos de negocio
Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan Más detalles WebSphere Message Broker como Entreprise Service Bus
IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta Más detalles Integración al Servicio de la Empresa
Integración al Servicio de la Empresa Las Arquitecturas SOA permiten abordar los nuevos retos empresariales, ser más competitivos y disponer de sistemas de información integrados. Además, tecnologías como Más detalles FACTURA ELECTRÓNICA. Estándar de comunicaciones electrónicas
FACTURA ELECTRÓNICA Estándar de comunicaciones electrónicas CONTENIDO: 1. Comprobante Fiscal Digital a. Características b. Elementos que lo conforman c. Tipos de CFD 2. Factura Electrónica a. Beneficios Más detalles Single-Sign-On Índice de contenido
Single-Sign-On Índice de contenido Introducción...2 Que es Single Sign-On...2 Descripción del esquema y componentes...2 Kerberos...3 LDAP...5 Consideraciones de Seguridad...6 Alcances de la solución implementada...7 Más detalles Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores.
GLOSARIO Glosario Acoplamiento. Posibilidad que tiene un servicio de funcionar de forma autónoma. Se dice que un servicio o aplicación es bajamente acoplado cuando puede funcionar de forma independiente Más detalles Management(BPM) Gestión de Proceso de negocio con BPM. Universidad Inca Garcilaso de la Vega
Universidad Inca Garcilaso de la Vega CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO Business Process Business Process Management(BPM) Management(BPM) MSc. Daniel Alejandro Yucra Más detalles Gestión de la Seguridad Informática
Documento de Gestión de la Seguridad Informática Versión 01 ARCHIVO: ANEXO6_GESTION DE LA SEGURIDAD INFORMATICA Nº. PÁG: 1 / 6 CREADO: 11/11/a TABLA DE CONTENIDO 1. GESTIÓN DE SEGURIDAD INFORMÁTICA... Más detalles La integración de información. Presente y futuro de la empresa moderna

References: artículo 101
 artículo 4
 artículo 39
 artículo 59
 artículo 5
 ARTÍCULO 5
 Resolución