INSTITUTO POLITÉCNICO NACIONAL

Tamaño: px
Comenzar la demostración a partir de la página:

Download "INSTITUTO POLITÉCNICO NACIONAL"

Transcripción

1 INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN INTEGRACIÓN DE APLICACIONES CORPORATIVAS MEDIANTE WEB SERVICES T E S I S QUE PARA OBTENER EL GRADO DE: MAESTRO EN CIENCIAS EN INFORMÁTICA P R E S E N T A: JOB HERNÁNDEZ JOFFRE DIRECTOR DE TESIS: M. C. CARLOS GONZÁLEZ ESCAMILLA MÉXICO, D.F. 2008

2

3

4 Agradecimientos AGRADECIMIENTOS: A Dios: Por que aún para aquellos que niegan tu existencia siempre tienes un milagro, porque siempre he creído en la existencia de un ser que está más allá de mi entender y de la razón, porque mantienes mi fe viva en cualquier momento grato o triste de mi vida, sin olvidar nunca lo insignificante que soy ante tu grandeza. A mis padres: Rosa (Angelina), la única gran Mujer que me ha amado aún sin conocerme y antes de nacer, que ha cuidado de mi siempre y me ha enseñado desde mis primeros pasos a seguir por el camino del bien y por quien daría mi vida sin cuestionar nunca el por que. Gerardo, el hombre que me enseño que Dios está más allá de cualquier religión y quien me ha guiado siempre con rectitud, ética y una moral digna de un gran Hombre. A ustedes dos dedico todos y cada uno de mis logros y triunfos, inspirado siempre en su ejemplo de superación constante, sin olvidar la humildad y sencillez que los caracteriza y que los hace aún más grandes y valiosos para mí. A mis hermanos y mi cuñada: Elías, Ivonne y Ana con todo mi cariño y admiración por su apoyo y comprensión, porque siempre están en mis oraciones y en mis pensamientos para que la vida les sonría en todo momento, pero sobre todo por seguir siempre unidos como hermanos y como familia. A mis sobrinos: Erick, Hiromy y Kevin (mis otros hermanitos) por compartir conmigo estos momentos que espero los inspiren a seguir adelante en la vida, a luchar y lograr grandes sueños sin bajar nunca los brazos por difícil que perezca el largo y sinuoso camino. A mis amigos(as): Alberto (Betoman), mi camarada en esta travesía y por culpa de quien me enrole en ésta aventura llamada la maestría, misión cumplida al fin K. Yeni, porque en ti he encontrado una parte importante que llena muchos vacíos en mi vida y por que has logrado dar un giro radical a mi vida, cambiando por mucho todo lo que en un pasado no pensé sentir, con todo mi amor y mi cariño, gracias. Gisela por tu amistad y tu apoyo en momentos difíciles, por los buenos tiempos y experiencias compartidas, por las horas de conversación siempre amena y sincera, Que tengas suertecita y recuerda que: todo es insignificante, nada es tan preocupante. Felipe Figueroa, Miguel Hernández (Mike), Jorge García, Karla González, porque de alguna manera también fueron participes de ésta experiencia conmigo, animándome siempre a llegar al final de ésta etapa, a Ustedes mi más sincero agradecimiento por todo. A mi comisión revisora: Porque gracias a Ustedes, a sus enseñanzas, consejos, recomendaciones y demás, logran sembrar grandes cambios en la vida de nosotros sus alumnos, a Ustedes y con especial cariño a la profesora Emilia les doy las gracias por estos años de grandes enseñanzas. A Ustedes y a todos los que de manera directa o indirecta contribuyeron en el logro de este objetivo, que para mí significa una pequeña aportación de todos ustedes a enriquecer una vida llena de bendiciones y satisfacciones, muchas gracias. Âl tä y ÇtÄ? xä tåéü Öâx Üxv uxá? xá zâtä tä tåéü Öâx wtáê Paul McCartney (1969)

5 Índice General INTEGRACIÓN DE APLICACIONES CORPORATIVAS MEDIANTE WEB SERVICES. Índice General PÁGINA RESUMEN i SUMMARY iii INTRODUCCIÓN v CAPITULO 1 Contexto General 1 CAPITULO 2 Antecedentes, Organizaciones y sus experiencias Gobierno electrónico Clasificaciones de los servicios de gobierno en México según el nivel de madurez Experiencias e iniciativas nacionales Iniciativa del portal egobiernoméxico (eméxico) Principios del Gobierno Electrónico Estado actual del e-gobierno en México Normativas existentes para el gobierno electrónico Avances y logros significativos Retos y desafíos del e-gobierno en México Iniciativas principales para e-gobierno en México Experiencias internacionales Reach GovTalk AGLS Organizaciones Internacionales Otras experiencias de integración en México Experiencias ERP Telcel Oracle Experiencias ERP SAT PeopleSoft. 53 CAPITULO 3 Conceptos, tecnologías de Información y Servicios Web Conceptos Básicos Definición de pautas Definiciones y bases teóricas Pautas de servicios web para el e-gobierno Bases usadas para definir pautas Servicios Web Flujo documental Servicios Arquitectura Orientada a Servicios (SOA) Requerimientos de los Servicios en el e-gobierno Particularidades de los servicios en el e-gobierno Tecnologías en Servicios Web Extensible Markup Language (XML) Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) Universal Description, Discovery and Integration (UDDI) Modelos Arquitectónicos Arquitectura de Servicios Web como descripción de servicios Guías para el uso de Web Services en servicios. 86 UPIICSA - IPN

6 Índice General PÁGINA CAPITULO 4 Casos de estudio y de éxito usando Servicios Web Caso 1. Servicio de Administración Tributaria (Inscripción al RFC) del servicio Alternativa de solución Especificación de requerimientos de la solución Especificación de metadatos basados en requerimientos Reflexiones sobre el caso Caso 2: Sistema de Pago Centralizado de Nómina Federal del servicio Solución Desarrollada Especificación de requerimientos de la solución Especificación de metadatos basados en requerimientos Reflexiones sobre el caso Caso 3: Sistema de expedición de Pasaportes y/o Licencias del servicio Alternativa de solución Especificación de requerimientos de la solución Especificación de metadatos basados en requerimientos Reflexiones sobre el caso CAPITULO 5 Recomendaciones para desarrollo de Servicios Web Pasos recomendados 149 Conclusiones. 159 Relación de figuras. Relación de tablas. Glosario. Bibliografía. ANEXO A ANEXO B ANEXO C UPIICSA - IPN

7 Resumen Resumen En los últimos años hemos visto el surgimiento y desarrollo del comercio electrónico a través de Internet, el auge del modelo de negocios electrónicos llamado Business to Business (B2B siglas en inglés) y la transformación de los servicios electrónicos tanto en la iniciativa privada como en el Gobierno Federal de México y otros países de la región. Estos modelos y paradigmas han alcanzado una etapa de interacción estándar de gran madurez entre clientes y proveedores, esto es, comunicaciones simples entre usuarios y servicios que tienden a incrementar exponencialmente el número de operaciones diarias con el paso del tiempo. Con ello podemos mencionar a proveedores del sector privado como los bancos y las empresas que ofrecen servicios particulares como telefonía, televisión, Internet, bienes y productos de primera necesidad, por otra parte los servicios que ofrece el Gobierno Federal los cuales podemos denominarlos a final de cuentas, como una interacción simple entre clientes y proveedores (Ciudadanos y el Gobierno Federal o clientes y empresas privadas). En los próximos años se vislumbran varios desafíos, ante los que destaca la automatización e interoperabilidad de servicios que por las características gubernamentales o privadas, se desarrollan en ambientes heterogéneos y distribuidos de acuerdo a las necesidades y posibilidades tecnológicas, económicas y políticas de cada una de las organizaciones. Los servicios electrónicos en México se han visto impulsados por la definición de leyes y decretos, que entre otras cosas obligan a algunas empresas privadas y dependencias del Gobierno a poder visualizar, recibir y generar documentación electrónica en un formato estándar. Así mismo, les exige poder comunicarse, interactuar, intercambiar información y ser capaces de entregar servicios a los ciudadanos o clientes para facilitarles el acceso a recursos, productos y servicios propiamente dichos, muchos de los cuales son de acuerdo a su naturaleza altamente complejos. El cumplimiento de las metas fijadas, las exigencias vigentes y los plazos estipulados de los servicios electrónicos en México han sido cumplidos parcialmente hasta la fecha, basta con echar un vistazo al sector público, donde encontramos una gran cantidad de servicios que son candidatos ideales a ser automatizados. UPIICSA IPN i

8 Resumen Todo esto implica que un número importante de organizaciones privadas y de gobierno deberán desarrollar servicios que permitan ver procesos más transparentes, más fáciles de usar y que ayuden a los usuarios a vivir mejor, además de beneficiar a las organizaciones incrementando su productividad y ayudando a los miembros de las organizaciones a servir mejor. Ante este panorama, existen tecnologías que resultan notoriamente ventajosas, dado que ofrecen una gran capacidad para interoperar dado que son extensibles, están diseñadas para ambientes heterogéneos y entregan funcionalidades reutilizables por distintas fuentes, independientemente del contexto bajo el cuál se invoca a los servicios. Dado que las experiencias con ciertas tecnologías como los servicios web en el desarrollo de servicios electrónicos son aún escasas, y más en estos tiempos en que las tecnologías y comunicaciones a través de Internet son el futuro a explotar, las iniciativas pioneras son y serán muy relevantes. Esto nos indica que debido al alto número de servicios que hoy en día se desarrollan resulta clave contar con una propuesta, pautas y/o buenas prácticas que guíen tal actividad sobre todo para el sector público que de manera única sigue un mandato o estrategia integral. Por otro lado la iniciativa privada puede o no estar obligada a seguir regulaciones o estándares internacionales de calidad, pero si está obligada a incrementar el número de servicios ofrecidos a través de Internet, no debemos olvidar que las empresas privadas buscan con toda razón maximizar sus ganancias y su presencia en el mercado. Considerando lo anterior, y basándose en experiencias de análisis, diseño y desarrollo sobre casos de éxito particulares, este trabajo propone ideas, sugerencias y pautas técnicas para diseñar, desarrollar y planificar servicios web en el marco del desarrollo de servicios electrónicos en el Gobierno Federal. Para el sector privado (si así lo consideran útil las organizaciones privadas) se identifican los requerimientos principales de los servicios que entrega un proveedor, presentando guías sobre interoperabilidad usando servicios web y discutiendo el rol de la definición de metadatos y descripciones en los servicios. Como resultado de este trabajo se concluye que los servicios web satisfacen los requerimientos de los servicios en general para brindar servicios electrónicos, que resultan altamente superiores a las otras tecnologías existentes y que debido a su madurez, soporte y flexibilidad, son una excelente herramienta para desarrollar servicios tanto en la iniciativa privada como en el Gobierno Federal. UPIICSA IPN ii

9 Summary Summary In the last years we have seen the born and development of e-commerce, the Business to Business (B2B) model and a general transformation of electronic services in private industry around the world, one case is the Mexican Government beside other countries of the region. These models have accomplished the state of Interaction according with the maturity standard of the Electronic Services[chapter 2], it says, simple communications between clients and providers. In this way, we can do mention of some providers from the private industry like Banks and companies that offer services as telephony, television, communications and services of elementary needs. In a similar way, there are services that the government offers and which we can denominate at the end, as an interaction between clients and providers (citizens and government or clients and private companies). For the next years, we can see a lot of challenges, the principal goal is to get interoperability of applications that are available in different environments of govern and private organizations, the available services are developed at heterogeneous and distributed environments according with the needs of technology and economic or politic possibilities of them. The electronic services in México have been impulsed by the definition of laws and decrees that obligate private companies and govern dependencies to visualize, receive and generate electronic documentation in a standard format. In the same way, they are required to communicate, interact, interchange information, and to be capable of deliver services to the citizens or clients, the purpose is to make easier the access of resources, products and the own services, a lot of which are highly complex agree with their nature. The accomplished of the established goals, the current demands, and the estipulate times of the electronic services in México, have been accomplished partially up to now. This implies that an important number of private companies and govern dependencies, will should develop services to allow transparent processes, easy access to resources and services, help people to have a better live, etc. The benefits will be for organizations, rising productivity, generating competitive advantages, and helping to employees to serve in a better way, without forgetting to search solutions to operate in and between their institutions in the short and medium term. UPIICSA IPN iii

10 Summary At this panorama, there are technologies that emerge with a lot of advantages, because they deliver a high capability to interoperate, they re extensible, they re designed to heterogeneous environments, and deliver reusable functions by distinct sources, independently of the context under the services are invocated. Due to the experiences with the web services technology in development of electronic services are poor up to now, the pioneer initiatives are very relevant, and because of a high number of services that are developed now, it results important to have a framework, rules and good practices to guide this activity, overall for the public sector that follows an order or a unified strategy. Considering the upper text, and taking advantage of experiences with analysis, design and development over particular succeed cases, this work propose technical guides to design, develop and planning web services into the frame of development for electronic services. For Government requirements, is necessary to identify the main patterns of the services that deliver a provider, presenting guides over interoperability using web services, and discussing the roll of the definition of metadata and description of the services. This document includes experiences where the web services satisfy a lot of requirements that electronic services have, the reason is because they are over other available technologies and because of their maturity, support and flexibility, they are an excellent tool to develop services at private industry as in the Government. At the end of this work, it presents a development proposal of services for the case of government using web services that represents the experience and acquired knowledge during the work developed. As a result of this work, it presents a series of clauses that indicates benefits of web services, the requirements satisfied by the technology in order to offer electronic services, the advantages of them against other technologies thank to their maturity, support and flexibility and that web services are an excellent tool for development of services in a private or government context. UPIICSA IPN iv

11 Introducción Introducción Durante los últimos diez años, la Internet ha permitido comunicar e integrar diversas fuentes de información, ha provisto un conjunto de servicios que han intentado evolucionar a la par de las necesidades de la sociedad y el mercado sin conseguirlo del todo, ha provocado un crecimiento y desarrollo organizacional desmedido y desigual tanto en la iniciativa privada como en los gobiernos del mundo entero. Estas necesidades de información y comunicación se hacen presentes en un órgano tan importante para México como lo es el Gobierno y en general para todas las organizaciones que ofrecen servicios por la web, las cuales mediante iniciativas como la modernización del Estado y el impulso del llamado gobierno electrónico o egobierno (egovernment) buscan: Entregar una mejor calidad de servicios, disminuir los costos actuales, incrementar la productividad y agilizar los procesos y trámites vigentes. Hacer la vida más fácil para todos y mejorar la calidad de vida de aquellas personas para las cuales se desarrollan soluciones ha sido una prioridad en el desarrollo de tales proyectos. Se hace mucho énfasis en la política del gobierno de servir mejor a la gente a través de instituciones más transparentes, lo cual aplica también para aquellas organizaciones privadas que desean generar ventajas competitivas y generar más ganancias para sus accionistas, beneficiando por consiguiente a sus clientes. Para realizar tales tareas, el Gobierno ha utilizado diversas tecnologías y enfoques que han resultado en varios casos exitosos, sin embargo, en este trabajo se argumenta como el uso de la web y las tecnologías asociadas pueden ayudar a entregar un potencial mucho mayor y ofrecer facilidades de desarrollo al abordar esta tarea. Existen soluciones que no representan un gasto excesivo de recursos como puede ser la compra de un producto tecnológico de marca reconocida, o bien la implementación de un sistema de gestión lo bastante complejo como para no usarlo. En otros casos encontramos soluciones que pueden representar una ventaja competitiva con respecto a organizaciones que ofrecen servicios de la misma índole con un ahorro de recursos significativo, sirviendo de mejor manera a los usuarios finales de la organización. UPIICSA IPN v

12 Introducción Un ejemplo de los servicios que entrega el gobierno hoy en día es la posibilidad de realizar la declaración anual de impuestos, a través del portal del Servicio de Administración Tributaria (SAT). Este portal también permite realizar avisos al Registro Federal de Contribuyentes (RFC) sobre la situación y régimen fiscal de cada uno de los ciudadanos registrados en dicho padrón, así como participar en subastas de artículos incautados, consultar información sobre licitaciones del Gobierno Federal, realizar pagos electrónicos y otros más. En la figura 1, se muestran algunos los servicios que ofrece el SAT actualmente. Figura 1: Trámites realizados en el portal del SAT. Este trabajo busca contribuir a la definición de pautas técnicas, ideas y sugerencias que aporten un poco de ayuda en el desarrollo de servicios automatizados e ínteroperables, soluciones que traigan beneficios como la transparencia al requerir en menos cantidad la intervención de personas en un flujo de trabajo. Se busca además contribuir en el uso de menos papel, ya que al automatizar servicios vía Internet se facilita la realización de algunos trámites burocráticos que actualmente representan un desgaste económico, físico y emocional para los ciudadanos. Un ejemplo de la automatización más eficiente de este tipo de servicios podría ser que una vez capturada la información del contribuyente y que la información del mismo ha sido almacenada en una base de datos central del SAT, esta información pueda estar disponible (bajo ciertas reglas de seguridad) para cualquier dependencia o empresa en la que el contribuyente realice un trámite. UPIICSA IPN vi

13 Introducción En pocas palabras, que la información pudiera ser consultada por organismos públicos y privados, de acuerdo a ciertas reglas y normas de seguridad, haciendo la vida más fácil a todos los usuarios y clientes de las organizaciones. Un beneficio tangible sería que se pudieran realizar los trámites a través de la Web, y que las organizaciones intercambiaran la información necesaria electrónicamente sin solicitudes burocráticas a través de documentos (en papel), atentas notas, requerimientos, etcétera. Todo esto con un solo identificador que sería en el caso de nuestro país; el RFC o bien la Clave Única de Registro de Población (CURP). Para ello, algunos sistemas de información de las instituciones podrían comunicarse adecuadamente siguiendo un protocolo definido, dependiendo de la información y los niveles de seguridad que se dispongan para los datos a intercambiar (es decir, deberían poder interoperar). 1 La figura 2 muestra una idea de lo que se pretendería con la interoperación de la cual se habla. Portal de acceso único a sitios del gobierno Interacción con la iniciativa privada, agilizando tramites y servicios a los usuarios (ciudadanos) Figura 2: Uso de un solo portal para todos los trámites públicos y privados. 1 Cabe resaltar que no necesariamente todas las interacciones entre dependencias del Gobierno son automatizables ya sea por aspectos técnicos, legales, u otros. UPIICSA IPN vii

14 Introducción Con base en esto, la definición de pautas técnicas se centrará en la especificación de los requerimientos descripciones y metadatos necesarios para poder interoperar y automatizar la comunicación de servicios al interior y entre las dependencias del Gobierno Federal que así lo permitan de acuerdo a sus lineamientos y reglamentos. Estas pautas bien pueden ser aplicadas, según sea el caso, a otras organizaciones de gobiernos locales o bien privadas, usando la o las tecnologías que se describen más adelante en éste trabajo. Para ello se usará un enfoque basado en el Modelo de Arquitectura Orientada a Servicios [ws-arch, Web services architecture description, W3C, implementada mediante la tecnología de servicios web, de la cual se estudiarán también sus características, madurez, ventajas y limitantes. Las Pautas de este trabajo son de carácter general y no representan una definición exhaustiva que calce para todos los posibles problemas, pero se intenta que los casos de éxito presentados aquí sirvan como guía o base para el desarrollo de propuestas más formales. Definiciones de tecnologías e implementaciones específicas para algún problema particular quedan fuera del alcance de este documento, sin embargo, se utilizan ejemplos y casos de éxito reales para ilustrar los conceptos explicados y la intención del presente trabajo. El trabajo está ordenado de la siguiente manera: En el capítulo 1 se describe el problema a analizar junto con sus causas. Se conocerán sus antecedentes, justificación y se hará una definición precisa del problema además de presentar la justificación y objetivos del trabajo. En el capítulo 2 se describen algunos casos de integración de aplicaciones corporativas, en los cuales se han podido observar intentos por conseguir una integración de los sistemas vitales de las organizaciones aquí tratadas y en cuyos casos las experiencias no han sido del todo exitosas. Por tal razón se ha motivado la definición del presente trabajo para identificar el problema y definir una propuesta de solución a tal necesidad de integración aplicativa. El capítulo 3 hace una descripción de los conceptos y las tecnologías de la información que se utilizan para desarrollar la solución al problema de integración aplicativa. Se describe además las características de las tecnologías que ofrecen mayores ventajas y se plantea la base para el desarrollo de una propuesta de solución. UPIICSA IPN viii

15 Introducción El capítulo 4 hace referencia a los casos de éxito que se utilizaron como referencia para el desarrollo del presente trabajo y para la definición de la propuesta de solución presentada en el capítulo 5. Este capítulo presenta la pauta para la definición de los pasos a seguir durante el desarrollo de una solución que implemente servicios web, identificando aspectos comunes en cada uno de los casos que se estudiaron. El capítulo 5 presenta a manera de pasos, lo que este trabajo arroja como producto final: una propuesta para el desarrollo de aplicaciones que lleven a la integración de aplicaciones corporativas, tomando como base la experiencia de los casos de éxito presentados aquí y desarrollados por el autor de este documento en organizaciones tanto privadas como de gobierno, desarrollando sistemas computacionales e implementando soluciones de integración aplicativa. La última sección de este trabajo, resume a manera de conclusiones, las experiencias, resultados, beneficios, desventajas, fortalezas, debilidades y demás valores encontrados a lo largo del desarrollo de este documento. Finalmente se comenta una recomendación final, para aquellas organizaciones que buscan generar y alcanzar ventajas competitivas, ganancias, beneficios, y demás objetivos (dependiendo de su naturaleza y ramo 2 ). Es importante resaltar que la mayor parte de la bibliografía a la que se hace referencia en este documento se encuentra encerrada entre corchetes [ ], la razón se debe a que por cuestiones de presentación y espacio, se utiliza una abreviatura que se detalla al final del documento en la sección correspondiente, cualquiera de las referencias puede ser consultada ya sea en línea o en el respectivo libro, texto, archivo PDF, tesis, o lo que corresponda. 2 Entendiendo por naturaleza y ramo si se trata de una organización de gobierno, privada, con fines de lucro, paraestatal, etcétera. UPIICSA IPN ix

16 Capítulo 1 Contexto General En el presente capítulo se describirá el problema a analizar junto con sus causas. Se conocerán sus antecedentes, justificación y se hará una definición precisa del problema UPIICSA - IPN Página - 1 -

17 Capítulo 1 Contexto General Integración de aplicaciones corporativas mediante Web Services. Por este término se deberá entender y comprender el contexto bajo el cual las aplicaciones informáticas de cualquier organización realizarán un intercambio de información de manera automática, segura y confiable dentro de un flujo de trabajo bien definido. El propósito será facilitar y agilizar los procesos vitales dentro de las empresas u organizaciones y entregar respuestas más fiables en el corto tiempo considerando la importancia de los grandes beneficios tanto para usuarios como para proveedores de servicios. A lo largo de la historia del desarrollo de Software, se ha buscado un producto que solucione la administración de recursos en el interior de las empresas y organizaciones del mundo entero. De este modo han aparecido productos que facilitan el proceso administrativo 3, la toma de decisiones 4, la administración de recursos humanos 5 y otras actividades más que involucran los procesos de una organización. Como consecuencia de estos esfuerzos, hemos visto la aparición de términos y productos como los ERP s (Enterprise Resource Planning), GRP s (Government Resource Planning), CRM (Customer Resource Mannagement), WorkFlow s 6 y muchos otros productos que pretenden resolver el problema de la integración de todos los sistemas de información en una gran aplicación corporativa. Después de la aparición de los sistemas de información, se ha tratado de resolver el problema de unificar los sistemas en una sola aplicación corporativa. Uno de los tantos problemas ha sido la ausencia o poca promoción de guías, estándares y lineamientos para el desarrollo de las soluciones, además de que no se tiene la cultura de fijar objetivos para desarrollar aplicaciones integrales desde un inicio. La constante aparición de lenguajes de programación, plataformas, contextos, paradigmas y necesidades de negocio propias de cada empresa, han propiciado la aparición de muchos intentos por resolver el problema de la integración, en este contexto los servicios web han aparecido como uno de esos intentos que buscan resolver esos errores 3, 4, 5 Conceptos de planeación estratégica que se resuelven con los productos de Planeación y administración de Recursos de una Empresa. UPIICSA - IPN Página - 2 -

18 Los procesos que se realizan al interior de una organización requieren de un tratamiento sistemático que se resume en definir un flujo de entradas y salidas, el modelado de estos procesos y actividades es conocido como un flujo de trabajo (workflow 6 ). Las tecnologías web (y en específico los servicios web) nacieron como una consecuencia y como una propuesta para solventar las necesidades de interoperabilidad en aplicaciones distribuidas, construidas sobre diversas plataformas y diversos lenguajes. La madurez de las tecnologías y el uso de estándares abiertos como los son los servicios web permite actualmente comunicar sistemas que parecían incompatibles entre si por las plataformas y lenguajes que las soportaban, a la par de este crecimiento de las tecnologías se enriquecen los servicios e información disponibles mediante la interacción de múltiples agentes en la Web. El propósito principal de estas tecnologías de integración es hacer más fácil la operación interna de las organizaciones que mejoran su operación considerablemente al no requerir rehacer su extensa gama de aplicaciones, reduciendo en gran medida costos y tiempos de operación e incrementando productividad y mayor extensión de servicios. A pesar de que el tema de la interoperabilidad ha madurado bastante, aún no existen guías claras ni documentación formal para saber cuando conviene aprovechar las bondades de los servicios web (u otras tecnologías), sin embargo si es posible identificar casos de éxito con características comunes para las distintas realidades y problemáticas que se presentan en un proceso de integración de aplicaciones. Por otra parte, de la misma forma en que hoy día el gobierno impulsa una política de estandarización de sitios web gubernamentales [egobiernoméxico], procesos de transparencia al interior de las dependencias, el lema servir mejor a la gente para vivir mejor, también se hacen necesarias definiciones en otros aspectos de diseño más complejos y críticos como lo son los servicios web y las tecnologías afines. 6 Workflow escrito como una sola palabra en inglés y traducido como Flujo de trabajo, es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le da seguimiento al cumplimiento de las tareas. Generalmente los problemas de flujo de trabajo se modelan con redes de Petri. UPIICSA - IPN Página - 3 -

19 Estas necesidades de especificación se hacen más evidentes tomando el ejemplo de los sitios web del Gobierno de México, creados antes de las políticas de calidad de los gobiernos a consecuencia de la globalización y la difusión de los medios electrónicos [egobiernoméxico]. Una vez construidos estos sistemas no resulta tan simple modificarlos de manera que cumplan el nuevo estándar o las nuevas políticas de calidad y de servicio público. Haciendo un paralelo con los servicios web - una tecnología más compleja - la carencia de una pronta especificación podría llevar a una gran variedad de diseños, arquitecturas, metadatos, plataformas y otros conceptos incompatibles entre sí, que a la larga harían más complejo solucionar el tema que los servicios web deben resolver, la interoperabilidad en la web. El porqué se debe considerar a los servicios web se debe a que conlleva un sin fin de beneficios que ayudan a cualquier organización que los implementa a servir mejor a la gente y a crear mejores productos y servicios, permiten ver la ansiada descentralización de servicios y acceso a más gente desde cualquier punto con acceso a la red o Internet, necesidades que pueden ser cubiertas usando esta tecnología para conectar a las ya existentes. Además, se debe considerar el creciente volumen de información manejado en los servicios que ofrece el gobierno, la complejidad de las interacciones entre dependencias y las horas hombre necesarias para darles cauce. No sólo es un tema de costos económicos sino que también de tiempo perdido por los ciudadanos (clientes o usuarios) que requieren de mejores servicios y servidores (funcionarios), más aun si hablamos de empresas privadas naturalmente repercute en las ganancias y expectativas de crecimiento. Un ejemplo de lo anterior lo podemos visualizar en las recientes reformas a las leyes de acceso a la información y transparencia en el gobierno, así como la prestación de servicios del gobierno por Internet. Un caso tangible de esto es el de la Ley Federal de Transparencia y Acceso a la Información Pública Gubernamental (LFTAIPG) del Instituto Federal de Acceso a la Información (IFAI), así como el Sistema de Solicitudes de Información (SISI, UPIICSA - IPN Página - 4 -

20 Con ejemplos así vemos que es posible ofrecer servicios ante la necesidad de una solución automatizada que ínteropere entre sistemas heterogéneos de distintas dependencias del gobierno para la solicitud de servicios y trámites gubernamentales como pueden ser las declaraciones de impuestos o patrimoniales. Finalmente cabe recalcar que existen algunas particularidades que caracterizan al gobierno comparado con otras instituciones, que hacen más trascendentes la entrega de servicios de manera efectiva y eficiente sin olvidar el principio de TRANSPARENCIA y de SERVIR MEJOR A LA GENTE. Una de esas particularidades radica en la importancia del Servicio Público Federal (SPF) y la posibilidad de agilizar trámites que en el pasado o incluso hoy requieren de días, semanas e incluso meses para poder tener acceso a los servicios del gobierno. Además podemos mencionar las facultades y deberes de fiscalización, el manejo de información pública o bien confidencial, las dependencias y relaciones entre documentos, trámites y dependencias, y la entrega de servicios que resultan obligatorios o bien como derechos para los ciudadanos (por ejemplo, el pago de contribuciones, el derecho a los servicios de salud, educación, seguridad, migración, etc). Nuevamente tomando un ejemplo de la iniciativa privada, podemos considerar a los bancos que interactúan hoy día a través de sus portales en Internet con un número mayor de usuarios (clientes). En los últimos años se ha identificado que la mayoría de las empresas han tenido un crecimiento exponencial en la infraestructura informática con la que cuentan, lo cual ha provocado que la mayoría de estas empresas deseen fervientemente unificar el crecimiento de dicha plataforma informática hacia una misma dirección, en el sentido de que exista un sólo canal de entradas y una sola brecha de salidas. Una plataforma informática integral se puede conceptualizar al interior como una caja negra (figura 3) en la cuál no importa lo que contenga dentro, ni la operación que realice sino lo que reciba a la entrada y lo que ofrezca a la salida. UPIICSA - IPN Página - 5 -

21 Entradas de diversas fuentes Conjunto de aplicaciones corporativas que procesan las entradas y entregan salidas en respuesta a la demanda Salidas con un mismo formato Figura 3. Conceptualización de un conjunto de aplicaciones como una caja negra Sin embargo, esta filosofía resulta complicada de entender cuando existe al interior de esta caja negra un conjunto diverso de plataformas (UNIX, Windows, Solaris) y de lenguajes de programación (Java, Microsoft.Net, Delphi, C, Visual Basic, etcétera), los cuales resuelven la operación de la organización, pero que a la vez requieren y dependen de la información que entregan a la salida las demás aplicaciones o entidades. El problema general radica como ya se menciono anteriormente, en que la solución inicial no se pensó como una sola unidad sino como un conjunto de soluciones a la medida en el momento de que cada una de las necesidades apareció. Particularmente el problema a resolver es la complejidad de lograr que todas esas aplicaciones interactúen entre sí, sin la necesidad de procesos manuales que trasladen la información de salida de un proceso o aplicación a la entrada de otro que realiza otro tratamiento de dicha información. Podemos imaginar un proceso general sincronizado (figura 4), normalmente serializado y lento debido a la intervención de los procesos manuales realizados por personas que requieren validar las entradas y salidas de dichos procesos o aplicaciones. Tal vez la solución más razonable sería rehacer todos los procesos o aplicaciones en una sola aplicación, sin embargo esto puede resultar más costoso en cuanto al tiempo para lograrlo, debido al análisis que requiere la solución integral más el tiempo de desarrollo e implantación necesarios para ello (ciclo de vida del desarrollo de software). UPIICSA - IPN Página - 6 -

22 Sistema de Planeación Sistema de Compras y Ventas Sistema de R. H. Sistema de Atención Informática Sistema de procesos corporativos Figura 4. Interacción manual entre aplicaciones de una misma organización. La manipulación de la información para llevarla de un proceso (o sistema) a otro, requiere de tareas programadas manualmente y que no siempre resultan ser confiables debido a la propia intervención de la mano de las personas. La sustitución de estos procesos manuales por procesos automatizados o interfaces (figura 5) que agilicen el intercambio de la información, es un paradigma generalizado que se presenta actualmente en la mayoría de las organizaciones. Hoy en día la mayoría de las organizaciones invierten fuertes cantidades de dinero y esfuerzos exagerados para lograr la integración de aplicaciones en una metaplicación corporativa, la cuál permita definir una mejor planeación, ayudar a la toma de decisiones en menor tiempo y generar ventajas competitivas, por consecuencia esto les redituará en mejoras económicas y una mejor respuesta hacia sus clientes o usuarios. UPIICSA - IPN Página - 7 -

23 Sistema de Planeación & Sistema de Compras y Ventas & & Sistema de R. H. & & & Sistema de Atención Informática & Sistema de procesos corporativos & - Intefaz o aplicación que sirve de intermediaria para automatizar el proceso de intercambio de información - Documentos electrónicos (estructura, protocolo, estándar para intercambio de información entre aplicaciones). Figura 5. Interacción automatizada entre aplicaciones de la organización. En la mayoría de las empresas y organizaciones privadas o de gobierno podemos encontrar procesos de información bien definidos, algunos con un alto nivel de madurez por el tiempo que han sido aplicados y mejorados. Sin embargo, el común denominador en todos ellos es la interacción de la mano del hombre (usuarios) para intercambiar información entre los distintos actores. Esa intervención de los usuarios (figura 6) genera una serie de factores que retrasan el flujo de información desde la entrada hasta la salida. Factores como la inspección visual, la clasificación de documentos o datos extraídos, la generación de reportes y otros más que consumen un lapso de tiempo que puede ser disminuido o incluso eliminado en algunos casos. Otro factor que aparece derivado de los procesos de una inspección o clasificación manual, es el número de errores agregados por una mala validación manual de la información que se acarrea o se multiplica a lo largo del flujo desde la entrada hasta la salida. UPIICSA - IPN Página - 8 -

24 Estos factores o problemas son en la mayoría de los casos revocables, la tarea es encontrar un proceso automatizado (figura 7) que reemplace esas intervenciones manuales que provocan toda esa serie de errores y retrasos. La manera de solucionarlos requiere de un alto conocimiento del negocio (flujo de información) así como un minucioso análisis de los procesos manuales y validaciones que se realizan al pasar de una aplicación a otra, la definición de interfaces automatizadas para estos problemas no es una tarea fácil. Es necesario considerar que muchas veces esos procesos o validaciones se realizan a criterio personal de los actores dentro del flujo, pero es posible ponderar la mayor cantidad de esos criterios a modo de minimizar la intervención del criterio personal y manipulación de la información. Proc. A Proc. B Proceso/validación Manual Figura 6. Proceso/Validación Manual Proc. A Proc. B Figura 7. Proceso/Validación Automatizado Proceso/validación Automatizado El objetivo principal de este trabajo es ofrecer una alternativa de solución al problema de integración de aplicaciones corporativas (guía basada en casos de éxito), para reducir los costos y desventajas de los procesos manuales que disminuyen la competitividad, la productividad y merman la capacidad de respuesta al interior de las organizaciones que cuentan con una gran diversidad de aplicaciones y de plataformas. UPIICSA - IPN Página - 9 -

25 El objetivo mencionado anteriormente para este trabajo, puede ser descompuesto en los siguientes objetivos específicos: Definir requerimientos para lograr interoperabilidad dentro de una organización y entre dependencias (interoperabilidad vertical y horizontal respectivamente). Caracterizar el concepto de servicio, analizar la entrega de servicios, su contexto dentro del e-gobierno, su relación con sistemas existentes y revisar la arquitectura orientada a servicios. Conocer el rol que juegan las descripciones (metadatos) de recursos en la entrega de servicios y analizar como ellos pueden ayudar a la interoperabilidad y automatización de los servicios. Presentar características, problemas y ventajas del uso de la tecnología de servicios web para la entrega de servicios tomando en cuenta el modelo de e-gobierno. Revisar casos de éxito que ejemplifiquen el uso y necesidad de las descripciones de las pautas técnicas. Dar un primer impulso hacia la estandarización y profesionalización del desarrollo de servicios en el e-gobierno en México a fin de poder comparar, compartir, y replicar esta experiencia entre las empresas privadas y de gobierno. Comentar las ventajas de implementar soluciones de integración para aplicaciones corporativas mediante servicios web, dentro de los cuales se incluyen los objetivos del Gobierno Federal como el de transparencia, servir mejor a la gente, mejorar la calidad de los servicios que ofrece el gobierno, generar ventajas competitivas e incrementar la productividad. Para el desarrollo del presente trabajo, se hará uso de los recursos obtenidos a lo largo de la experiencia profesional propia del tesista en la iniciativa privada, así como material recaudado de Internet, fragmentos de documentos de dependencias de gobierno bajo autorización expresa y oral por parte de los jefes inmediatos del tesista en cada dependencia, el uso de dichos documentos es sólo como material de consulta para ejemplificar la solución que se pretende. Como se ha comentado hasta aquí, existe un interés muy grande por parte de las organizaciones para identificar su problemática de integración y solventarla de algún modo tratando de agilizar sus procesos de información. Uno de los problemas principales es que no existe una estandarización de dichos procesos ni de la forma de operarlos, la hipótesis que surge en este contexto es que existe una preocupación más grande por la compra de productos costosos que solucionen el problema y no por analizar primero su situación actual. UPIICSA - IPN Página

26 Lo primero que debería hacerse es un análisis de cual se deriven las problemáticas y sus necesidades, además de que se pierde de vista algo muy importante que es el ofrecer mejores servicios y de ser más competitivos incrementando la productividad o bien sirviendo de mejor manera, dependiendo del contexto público o privado. Los productos que ofrecen los grandes proveedores de software prometen solucionar muchos de los problemas comentados anteriormente, sin embargo, al final todos terminan siendo un producto que cubre solamente el 10 ó 20 por ciento de la problemática a resolver, sobre todo cuando no se ha hecho el análisis pertinente de las necesidades en contraparte con las ventajes que ofrecen dichos productos, por consecuencia esto hace más difícil la operación al interior de las organizaciones. [Ramiro Rodríguez 2003, Tesis ERP en la administración de proyectos de construcción ITESM Cd. México]. El porcentaje restante termina siendo un desarrollo nuevo o a la medida por parte del proveedor debido a que el negocio de la organización así lo requiere por su complejidad, por su situación fiscal, organizacional u otras razones. En algunos casos la implementación de un ERP, GRP, CRM, o cualquier otro modelo para la planeación de recursos y administración de procesos, terminan siendo una solución que consume dinero en exceso, tiempo y esfuerzos exponenciales, debido a que la implementación de dicho sistema no siempre es lo que el proveedor promete. La obtención de una metaplicación corporativa eficiente y funcional, depende más de la correcta obtención de un grupo de personas con experiencia suficiente en el negocio para sacar adelante un proyecto, y no de un producto que prometa cubrir el mayor porcentaje posible de la operación. -Tal como lo dice Ramiro Rodríguez (2003) en su tesis "ERP en la administración de proyectos de construcción Biblioteca Digital ITESM [on-line database]. - menciona la importancia de que, para implementar un sistema ERP debe formarse un equipo con las personas de mayor experiencia en sus áreas, generalmente se menciona que "sí las compañías pueden operar el negocio como siempre, sin la gente que ellos han puesto en los equipos de implantación, entonces se ha seleccionado al personal equivocado para el proyecto ERP". UPIICSA - IPN Página

27 El equipo debe incluir gente técnica (que sabe como trabajar con el sistema ERP) y gente de negocios que entiende como opera la compañía, como se representa en la figura 8, aunque se debe reconocer que de ambos es mas importante el personal experto en el negocio. CONOCIMIENTO DEL SISTEMA ERP CONOCIMIENTO DETALLADO SOBRE EL PROCESO DE NEGOCIO + = ÉXITO DEL PROYECTO Figura 8. Éxito de un proyecto ERP. Como se puede inferir, a final de cuentas la solución termina siendo una reingeniería de los procesos internos. Donde lo más conveniente es realizar un esfuerzo interno para realizar el análisis pertinente, en lugar de promover un producto que nos implique más esfuerzo innecesario y un gasto excesivo en todos los aspectos, ya que terminan duplicándose las cosas al operar dos sistemas en paralelo (el anterior y el nuevo ERP) por un largo tiempo que normalmente no llega a cumplir con el objetivo fijado. UPIICSA - IPN Página

28 Capítulo 2 Antecedentes, Organizaciones y sus experiencias En este capítulo se habla de las experiencias que han tenido las organizaciones en México (Gobierno Federal), en el mundo y en algunas empresas de la iniciativa privada. Así también, se exponen sus ventajas y desventajas experimentadas en la implementación de soluciones que resuelvan el problema de la integración de aplicaciones. UPIICSA - IPN Página

29 2. Antecedentes, Organizaciones y sus experiencias. 2.1 Gobierno electrónico El concepto de gobierno electrónico, e-gobierno (o e-government por su denominación en inglés) fue acuñado como: una forma de describir el quehacer del Gobierno, apoyado por las nuevas tecnologías de información y comunicación (TIC), a fin de cumplir con sus funciones eficiente y efectivamente [e-gov-roadmap] Clasificación de los servicios de gobierno en México según el nivel de madurez La madurez del desarrollo del e-gobierno se ha intentado revisar y medir mediante la definición de sus etapas a través de trabajos realizados por parte de Universidades como el Tecnológico de Monterrey campus Monterrey, la Universidad Nacional Autónoma de México (UNAM) a través de estudios por parte del Instituto de Investigaciones en Matemáticas Aplicadas y en Sistemas IIMAS, catedráticos de la Universidad Iberoamericana (UIA) en colaboración con el IIMAS y otros más, hablando del caso de nuestro país se ha hecho el análisis desde el estado más primitivo al más evolucionado. Esto permite comparar el estado y evolución del gobierno electrónico en México con los avances en otros países de la región y del primer mundo, además de poder definir una guía de desarrollo con una propuesta de metodología más estandarizada. Para ello, a continuación se presentan las etapas del enfoque evolutivo [Gil-Garcia Et Luna-Reyes, 2003, Sahelin, 2003] Inicial: Antes de definir cualquier etapa, podemos mencionar un estado inicial que representa el estado en el que no existe comunicación electrónica (como servicios) hacia el exterior (ciudadanos u otros agentes del estado), pero sí sistemas de información internos que pueden o no comunicarse. A partir de esta base de infraestructura podemos mencionar las siguientes etapas del enfoque evolutivo. UPIICSA - IPN Página

30 Las 6 etapas definidas son: 1. Presencia. Esta primera etapa se enfoca en clasificar y organizar información a través de páginas web y garantizar la presencia de la dependencia gubernamental en Internet (o bien de la compañía privada). La mayoría de las iniciativas gubernamentales comienzan en esta fase, sin embargo, su utilidad es limitada ya que carece de motores de búsqueda que facilitarían la tarea de encontrar datos. No se encuentra dividida por segmentos ni tipos de usuarios, los sitios web pueden contener información básica que permitiría contactar a los funcionarios por teléfono o tener acceso a ellos en sus oficinas en ciertos horarios pero no se puede realizar ninguna interacción mediante Internet. 2. Información. Esta etapa engloba una gran cantidad de sitios gubernamentales, pues permite el acceso de numerosas organizaciones públicas y privadas. Un portal de este tipo sirve como página inicial o como plataforma de despegue para tener acceso a otras páginas útiles donde se pueda localizar información de distintos departamentos, direcciones o dependencias del gobierno. En esta etapa los usuarios pueden encontrar información más actualizada y especializada, además cuenta con motores de búsqueda internos y/o externos. 3. Interacción. Existe mucha interacción entre los ciudadanos y los departamentos gubernamentales, es posible que los usuarios encuentren información que resuelva sus necesidades e intereses. En algunos casos los sitios web utilizan contraseñas para proteger los datos o la identidad de sus usuarios y de esta forma brindan garantías a la información personalizada y a la protección de documentos. En esta etapa se puede tener acceso a leyes, publicaciones gubernamentales y reportes que se pueden obtener directamente de los sitios y transmitirse a sus computadoras personales para ser revisados posteriormente sin necesidad de conexión. Finalmente en esta etapa ya se encuentran los motores de búsqueda y la suscripción electrónica a noticias relacionadas con el sitio gubernamental. Se cuenta con correos electrónicos de funcionarios y servidores públicos, lo que facilita la interacción entre gobierno y ciudadanos. 4. Transacción (Interacción en dos vías). En este punto las páginas gubernamentales utilizan el potencial de Internet para proveer servicios públicos y no únicamente brindar información del gobierno. Los ciudadanos pueden realizar transacciones seguras, confiables y rápidas a través de Internet. UPIICSA - IPN Página

31 Se pueden obtener líneas de captura para pago de servicios o impuesto en bancos; renovar permisos y licencias, tramitar pasaportes, consultar saldos, obtener citas para trámites, entre otros ejemplos. Como ventaja de esta etapa se permite personalizar las funciones según el tipo de usuario y garantizar que la organización del sitio ayude a resolver necesidades, las cuales pueden ser de información o contacto con el gobierno de acuerdo con las características específicas de cada ciudadano (caso del IMSS, ISSSTE y SAT). 5. Integración ó Integración Vertical Interna ( Transformación ). Esta es una de las etapas más avanzadas: el portal brinda múltiples servicios mediante una ventanilla única integral. Los ciudadanos pueden acceder a todos los servicios de diferentes dependencias gubernamentales o niveles de gobierno, sin preocuparse con qué departamento u organismo interactúan. En esta atmósfera virtual, las fronteras entre departamentos, direcciones y subdirecciones no son visibles a los ojos de los ciudadanos. El gobierno les ofrece servicios en línea de acuerdo con las necesidades, funciones y jurisdicción que tenga cada ciudadano para ofrecer servicios públicos de manera rápida y eficaz (para este caso la página de presidencia.gob.mx y de e-gobméxico.gob.mx, son candidatas a ocupar próximamente este nivel de madurez, en principio por lo que representan para el gobierno y en segunda por que pueden convertirse en los sitios de mayor demanda pública, dados los servicios que deberán ofrecer) pero para ello, habrá que trabajar arduamente para integrarlas a dicho nivel o etapa de madurez. En esta fase el sitio web es transaccional, la interacción es personalizada (decisión, entrega y eventualmente pago). 6. Participación Política. Esta es la última etapa y probablemente la más avanzada del enfoque evolutivo, supone que el ciudadano no sólo interactúa con el gobierno sino que participa activamente en la toma de decisiones gubernamentales. Aquí ya es posible que los ciudadanos opinen sobre proyectos de ley o políticas públicas. De igual forma, puede existir el voto electrónico sobre asuntos públicos u otras formas de participación a través de los sitios gubernamentales, la página del IFE (Instituto Federal Electoral), es evidentemente candidata por la función que desempeña y está obligada a llegar a este nivel de madurez. UPIICSA - IPN Página

32 Con el objetivo de llevar a cabo la medición de los portales, estas seis etapas no son necesariamente consecutivas y de hecho pueden considerarse como componentes diferentes, aunque interrelacionados. Es decir, un portal que provee buena información, que permite la interacción entre gobiernociudadano, que tiene la capacidad de proveer servicios en línea, que presenta un alto grado de integración y que promueve la participación política de la ciudadanía es un portal altamente funcional. Sin embargo, no es necesario que un portal tenga todas las características relativas a cada uno de los componentes. La siguiente etapa de este estudio consiste en revisar los portales y asignarles un puntaje. Para ello debe tenerse presente que cada indicador contiene uno o más reactivos (ver Tabla 1). La ponderación que se haga de cada uno de los reactivos dará el puntaje final de cada indicador, cuyo máximo es un punto. Por otra parte, el puntaje para cada indicador es un porcentaje del total de indicadores que se encontraron en cada portal seis en este caso. Una vez calculados los puntos obtenidos por cada indicador, se suman y dividen entre seis (normalización); así se obtiene un promedio denominado puntaje total que mide la funcionalidad del portal. Los portales con mayor madurez tendrán un puntaje máximo de 1 punto. UPIICSA - IPN Página

33 Indicadores Reactivos (Sofisticaciones Tecnológicas y Organizacionales Adicionales) Presencia Información Interacción Transacción Integración Participación Política Información limitada por el gobierno. Pocas páginas web hechas por simples agencias. Información estática acerca de la estructura y servicios del gobierno. Número mayor de páginas web. Portal estatal que contiene ligas a la mayoría de los estados del país. Información más dinámica (actualizaciones frecuentes). Las formas (leyes, reglamentos, documentos) se pueden descargar. Comunicación de doble banda a través del correo electrónico. Uso de máquinas y programas de búsqueda. Uso de chats, foros y otras formas interactivas de comunicación (relacionadas con el servicio). Posibilidad de configurar (archivo de ciudadanía, uso de contraseñas). Servicios en línea (seguros), incluyendo pagos electrónicos (tarjetas de crédito y líneas de captura). Más configurabilidad (uso de contraseñas, firma electrónica, etc.). Portal organizado acorde a las necesidades de las personas en lugar de las estructuras gubernamentales. Portal de servicio con un punto único de salida (agencias múltiples, misma función, diferentes niveles de gobierno). Participación de decisiones gubernamentales, voto electrónico, encuestas en línea. Fuente: Traducido por [Sandoval Almazán] y [Gil-García], TABLA 1. EVOLUCIÓN DE LAS APROXIMACIONES A LA EVALUACIÓN DEL GOBIERNO ELECTRÓNICO. Aunque este estudio tiene limitaciones que vale la pena considerar, representa un primer acercamiento a la funcionalidad de los portales del sector público en México. El estudio presentado sólo evalúa la funcionalidad de los portales en términos de los seis componentes mencionados: (1) Presencia, (2) Información, (3) Interacción, (4) Transacción, (5) Integración, y (6) Participación. Los resultados podrían cambiar de forma radical si se incluyen otros aspectos específicos como calidad de la interfaz, sofisticación técnica del portal, rapidez en el despliegue de la información, UPIICSA - IPN Página

34 disponibilidad del contenido en varios idiomas, número de usuarios beneficiados por mes, entre otros. Es por ello que es necesario que las evaluaciones en el futuro sean muy claras en su método y mencionen explícitamente qué aspectos son considerados y de qué forma es construido el índice de funcionalidad o puntaje total. Como puede verse, es necesario desarrollar una evaluación más integral que considere aspectos cuantitativos y cualitativos, que reconozca innovaciones de los portales y que considere las necesidades y características de los ciudadanos, a final de cuentas se trata de servir mejor y de ofrecer servicios más fáciles de usar. Tal evaluación mejorará la calidad de los portales estatales, sirviendo de guía y proporcionando ideas útiles que puedan ser retomadas por los responsables del contenido en cada entidad, sin embargo, es una buena referencia para saber en donde estamos parados como país en el marco de los que se denomina un buen portal de e-gobierno. 2.2 Experiencias e iniciativas nacionales Iniciativa del portal egobiernoméxico (eméxico) Antecedentes En su toma de posesión el 1 de diciembre del año 2000, el entonces presidente de la República Vicente Fox Quesada, anunció el lanzamiento del Sistema Nacional e-méxico a fin de integrar los esfuerzos de diversas dependencias y entidades de la Administración Pública, así como de los operadores de redes de telecomunicaciones entre otros actores, un proyecto de conectividad nacional que incorporara tecnologías de vanguardia y contenidos en línea, particularmente los de impacto social para México quedando este programa bajo la coordinación de la Secretaría de Comunicaciones y Transportes [Fuente: SEDESOL, En la información que muestra la página de la Secretaría de Desarrollo Social (SEDESOL), se muestran los principios que rigen en un principio las bases del egobierno (e-government por su denominación en inglés) en México, con la puesta en marcha del sistema eméxico cuyo objetivo se plasmaba como el de reducir la brecha digital existente entre diferentes sectores de la población del país e integrarlas a la Sociedad de la Información. UPIICSA - IPN Página

35 A la vez se anunciaba que su diseño debía responder a la necesidad de comunicaciones, mediante el uso de las carreteras de información, lo cual permitiría a la población tener acceso a numerosas oportunidades de desarrollo individual y colectivo, la integración de los individuos y grupos de la sociedad, el fortalecimiento de la democracia y la participación ciudadana, el incremento del conocimiento, la capacitación y la competitividad y una mejora en oportunidades de desarrollo y calidad de vida. El Sistema Nacional e-méxico definió tres ejes principales para su desarrollo. Se resaltaba que estos ejes debían mantenerse coordinados como un todo, aún cuando sus características se manejarán independientemente para efectos de ejecución. Los ejes rectores serían: Conectividad, Contenidos y Sistemas. La Conectividad se refiere a la oferta de servicios integrales de comunicación, capaces de llevar Internet a las Poblaciones del país, inicialmente a través de la creación de los Centros Comunitarios Digitales (CCD's), principales vehículos que permitirían enlazar a las diversas localidades que los integraran. Los Contenidos serían parte indispensable para el Sistema, puesto que la conectividad que se ofreciera debería utilizarse para la distribución y acceso de todo tipo de contenido digital que ofreciera a la población: datos, información, conocimientos y servicios que se tradujeran en un beneficio manifiesto en su desarrollo. Dentro de los contenidos destacaban entre otros temas de importancia: Educación, Salud, Economía, Gobierno, Ciencia y Tecnología. Estos temas son evidentemente una parte medular de los servicios de cualquier organización gubernamental o privada. A través de los Sistemas de programación computacional se integrarían los contenidos con sus aplicaciones. La conectividad y el acceso se harían disponibles para el público en general a través del uso de sistemas y tecnologías de información, bases de datos y otros avances tecnológicos afines. UPIICSA - IPN Página

36 Quiénes participan en e-méxico? Para comenzar con la implementación del sistema eméxico se integraron grupos de trabajo en conjunto con las dependencias involucradas a nivel federal como son la Secretaría de Educación Pública (SEP), la Secretaría de Salud (SSA), la Secretaría de Desarrollo Social (SEDESOL), el Instituto Nacional para el Federalismo y Desarrollo Municipal (INAFED) de la Secretaría de Gobernación (SEGOB) y el Instituto Nacional para la Educación de los Adultos (INEA), coordinados con la Secretaría de Comunicaciones y Transportes (SCT). Entre junio y julio del 2002 se firmaron los convenios de colaboración intersecretarial entre la SCT y cada una de las dependencias señaladas en el párrafo anterior, para establecer los compromisos de las partes para lograr los objetivos establecidos para la conectividad. Asimismo, el 15 de julio del 2002 se firmó la Declaratoria de Conectividad para el Sistema Nacional e-méxico, haciendo pública la formalización de la firma de los Convenios Intersecretariales para la conectividad e- México, dentro de la cual se instalarían y operarían los Centros Comunitarios Digitales e-méxico (CCDs e-méxico). Esta Declaratoria fue suscrita por el entonces Presidente de México, Vicente Fox Quesada, como testigo de honor, y por los Secretarios de las Dependencias involucradas en la conectividad. El 1º de octubre de 2002 se publicaron las bases de licitación para la contratación de los servicios de conectividad satelital cuyo ganador fue la empresa Internet Directo, S.A. de C.V., concesionario de la red pública de telecomunicaciones, para lo cual se firmó el contrato respectivo el 18 de diciembre de 2002 y con ello se iniciaron los trabajos de instalación de la referida red satelital Principios del Gobierno electrónico Junto con el nacimiento del gobierno electrónico, se definieron un conjunto de principios y objetivos que rigen tal iniciativa: [eméxico, Misión del e-gobierno Aprovechar el potencial de las tecnologías de la información en un proceso integral de innovación continua para prestar servicios de calidad con vocación social. UPIICSA - IPN Página

37 Visión del e-gobierno Ser un gobierno de clase mundial que hace uso intensivo de las tecnologías de la información y comunicaciones para ofrecer los servicios de alto impacto en la sociedad mexicana. Objetivos Incrementar la eficiencia, efectividad, rendimiento y productividad de los macro-procesos. Mejorar la calidad de los servicios públicos. Mejorar el acceso a la información pública. Incrementar la participación ciudadana. Mejorar la accesibilidad de los servicios, entregándolos por medios electrónicos. Reducción de costos. Mayor captación de Ingresos. Rendición de cuentas a los ciudadanos. Figura 9. Estructura del egobierno México (política del Buen Gobierno) [SFP-Unidad de Gobierno Electrónico y Políticas de Tecnologías de la Información] UPIICSA - IPN Página

38 Como lo muestra la figura 9 se definió una estructura de egobierno que la cuál incorpora a la Secretaria de Comunicaciones como principal actor y al Consejo Nacional de Ciencia y Tecnología para encabezar las tareas de investigación y aplicación de TI, las cuales deberán estar coordinadas y apegadas a los lineamientos de la Oficina del C. Presidente de la República. Los proyectos de e-gobierno habrán de integrar las siguientes características: Abiertos y penetrantes: Habrán de contar con servicios basados en estándares de Internet y el conocimiento de la sociedad habrá de ser incluida en su totalidad. Orientada al ciudadano: Poner al ciudadano en el centro del pensamiento, con sistemas que provean calidad y servicios personalizados en donde exista valor agregado en dichos servicios. Integrar los servicios del gobierno en los procesos de negocios, las agencias y las jurisdicciones para que dichos servicios aparezcan en línea como un sistema completamente integrado. Fomentar las asociaciones público - privadas. Asegurar el acceso a todos los ciudadanos a las prestaciones disponibles en forma electrónica, considerando las dimensiones social (quién accede), geográfica (dónde accede) y temporal (cuándo accede). Que el beneficio obtenido por el ciudadano respecto a la forma presencial de acceder a las prestaciones sea mayor. Garantizar y disponer de mecanismos adecuados para asegurar privacidad y seguridad en el uso, acceso y transacción de información. Descentralizar la administración, mantenimiento y actualización de las TIC a cargo de los servicios públicos, asegurando interoperabilidad entre ellos. Debido a la naturaleza de estos principios y a las tecnologías disponibles en el país [eméxico], la web ha comenzado a ser uno de los medios más importantes que permiten un eficaz y eficiente acceso a los servicios por parte de los ciudadanos y otras dependencias del Gobierno. Un claro ejemplo de esto, son los servicios e información en línea entregados en el portal de TrámitaNet o la misma Secretaría de Gobernación [traminanet]. UPIICSA - IPN Página

39 La figura 10 muestra el esquema de integración de las aplicaciones de una organización que interactúan con las de otras dependencias del gobierno federal a través de conexiones de Red Privada Virtual (VPN por sus siglas en inglés). Este tipo de enlaces son más seguros al no estar disponibles de manera pública sino a través de un enlace virtual de manera privada. Figura 10. Esquema de integración de aplicaciones entre Secretarias de Estado (Portal único) Fuente: [SFP-Unidad de Gobierno Electrónico y Políticas de Tecnologías de la Información] Estado actual del e-gobierno en México A pesar de que existen servicios en línea o al menos se tiene información sobre ellos, el uso de los servicios en la web aún es bajo, por desconocimiento, por la poca difusión que se les da, por la falta de medios para acceder a ellos (Internet) y otras razones de índole cultural, esto basado en la comparación con los servicios disponibles sólo en oficinas (hablando de departamentos al interior de una misma organización). Por otro lado no podemos olvidar los importantes avances en la entrega de servicios por parte de dependencias como el Servicio de Administración Tributaria (SAT), la tesorería del Distrito Federal, el Instituto Nacional de Fomento a la Vivienda para los Trabajadores (INFONAVIT), la Secretaría UPIICSA - IPN Página

40 de Gobernación, el portal el Instituto Mexicano del Seguro Social (IMSS), entre otros, cabe resaltar que aún existen muchos casos donde las interacciones son manuales, no existe interoperabilidad vertical u horizontal, ni el uso de las TIC acorde a las necesidades actuales. Un claro ejemplo de la falta de interoperabilidad entre organismos gubernamentales, son los servicios ofrecidos en dependencias como los gobiernos Municipales, clínicas y hospitales del sector salud. Definir la mejor forma de incluir en el mediano plazo a estas dependencias en el desarrollo integral del gobierno electrónico, resulta ser un importante desafío para el actual y los futuros gobiernos federales. Es importante destacar que el nivel de desarrollo de los servicios es un estimado 7 al momento de la recolección de la información, se obtuvo a partir de estudios realizados por empresas privadas que colaboran con proveedores como Oracle y PeopleSoft, así como universidades y centros de investigación como la UNAM y el Tec de Monterrey campus Monterrey que cuentan con buena reputación en el estudio de gobierno electrónico. Sin embargo, existen varios proyectos al interior de las dependencias que buscan cumplir con los objetivos del bueno gobierno, haciendo énfasis en automatizar los procesos internos y reducir el número de operaciones manuales para brindar un mejor servicio a la población. Utilizando el enfoque evolutivo mencionando anteriormente, en enero del 2006 se visitaron y evaluaron los portales de los 31 estados y el Distrito Federal por parte de un grupo de investigadores que se dieron a la tarea de hacer una evaluación del estado del egobierno en México [Sandoval 2006, Política Digital]. Este grupo utilizó el estudio del enfoque evolutivo y como lo marca dicho enfoque, para cada afirmación se asignó el valor de un punto y el puntaje para cada componente fue calculado como el porcentaje de reactivos (afirmaciones) que se encontraron en cada portal. 7 Estimado al mes de Diciembre de UPIICSA - IPN Página

41 Una vez calculados los porcentajes para cada componente, se sumaron y dividieron entre 5 (número de componentes que se tomaron en cuenta en ese estudio), obteniéndose un promedio que se denomina Puntaje total. Para finalizar, tomando el puntaje total, se asignaron lugares a los 32 estados del país. La Tabla 2 presenta los puntajes totales por entidad y por componente para los portales estatales. TABLA 2. Estados con los mejores puntajes totales. Como se puede observar el mayor porcentaje en el componente Información fue 100%, lo que equivale a haber presentado 5 de las 5 características evaluadas para este componente. Únicamente Morelos obtuvo el puntaje más alto en cuanto a información, pero la gran mayoría obtuvieron 85.71%, lo que equivale a 4 de las 5 características evaluadas. Tamaulipas y Nayarit obtienen cero puntos ya que se centran más en la interacción. Los estados de Quintana Roo, UPIICSA - IPN Página

42 Coahuila, Durango y Guerrero que figuran en las últimas posiciones carecen de un diseño enfocado a la información pues sus portales están mayormente integrados a otras páginas gubernamentales internas y no a un portal diseñado con un propósito informativo. En el caso del componente Interacción, los estados de Sonora, Chiapas, Estado de México y Tamaulipas alcanzaron el mayor porcentaje con 57.14%, lo cuál indica que han logrado implementar mecanismos que permiten buena comunicación con sus ciudadanos. La mayoría de las entidades tienen un porcentaje mayor a la media de 34.82, sólo nueve entidades están por debajo de ésta. Sin embargo, es necesario impulsar más la interacción entre el gobierno y los ciudadanos. En cuanto al componente Transacción, debe destacarse que sólo 13 de las 32 entidades ya realizan transacciones en línea (este estudio se realizó en los primeros días de enero del 2006). En estos estados, ya sea de forma parcial o completa, se puede obtener algún servicio gubernamental en Internet. En este rubro se evalúa el trámite completo, es decir sin necesidad de acudir a ninguna oficina pública o llamar por teléfono. Nuevo León fue el estado con mejor servicio de trámites completos en línea. El componente Integración tiene una composición distinta de los anteriores indicadores, pues muestra el grado de vinculación entre las distintas dependencias con el portal. El estado de Nuevo León presenta el puntaje más alto con 55.56%, lo que representa 5 de las nueve características evaluadas para este componente. Le siguen Sonora, Hidalgo, Yucatán, Zacatecas y Tamaulipas que cuentan también con portales relativamente integrados, al menos de forma virtual. El resto de los estados tienen puntajes relativamente bajos (de a 11.11) y el promedio general es 30.21%. Finalmente, el componente Participación Política es incipiente. La mayoría de las entidades carecen de esfuerzos que impulsen la participación de sus ciudadanos a través de sus sitios web, mientras aquellos que lo tienen es apenas un esfuerzo inicial (obteniendo solo 1 de 4 puntos potenciales para este componente). No obstante, el resto de los indicadores permite ubicarlos en determinado lugar de la lista. Es importante destacar que la diferenciación regional no es tan marcada como pudiera esperarse. Hay seis estados del norte del país en los primeros lugares del índice: Nuevo León, Sonora, Baja California Norte, Tamaulipas, Sinaloa y Zacatecas; seis estados del centro: Morelos, Michoacán, Hidalgo, Estado de México, Aguascalientes y San Luís Potosí; Jalisco, de occidente; y Yucatán y Chiapas, del sur. Existe una tendencia de los estados norteños a tener mejores páginas web, pero UPIICSA - IPN Página

43 los estados del Centro y Sur realizan importantes esfuerzos que son muy comparables a los del norte. Por otra parte, el promedio global de los estados en todos sus rubros es de puntos. 12 entidades se encuentran por debajo de esta media y 20 de ellas están por arriba del promedio. Lo cual parece indicar que existen importantes diferencias entre estados con portales altamente funcionales y estados que están comenzando a desarrollar este tipo de presencia electrónica. Por último, el puntaje total combina las fortalezas de los estados en los distintos componentes. Entre mayor avance tenga en uno o varios de los componentes la entidad adquiere mayor puntaje, que la coloca en una mejor posición que el resto. Aunque los componentes o etapas no son necesariamente consecutivos, como hemos mencionado, si se complementan y dan como resultado portales con mayor funcionalidad y más útiles para los ciudadanos, las empresas y otras entidades que interactúan de forma cotidiana con los gobiernos estatales [Sandoval 2006, Política Digital]. En resumen, tal y como indica el artículo de Sandoval Almazán [Sandoval 2006, Política Digital]. -falta mucho por indagar sobre este tema, y coincide ampliamente con otros artículos (como Mercado Arceo, La TI automatiza al gobierno, 27/11/2006, InfoWorld) en que es necesario desarrollar una evaluación más integral que considere aspectos cuantitativos y cualitativos, además que reconozca innovaciones de los portales y que considere las necesidades y características de los ciudadanos. De la misma forma, esta evaluación debe ayudar a mejorar la calidad de los portales estatales, sirviendo de guía y proporcionando ideas útiles que puedan ser retomadas por los responsables de los portales en cada entidad. Según José Luís Torres, director Comercial del Sector Público, Salud y Educación de Oracle en México y Centroamérica, vamos un poco adelante de la mitad de las cinco etapas anteriores, estamos culminando la transaccionalidad, las primeras etapas están al 100% de acuerdo al estudio realizado en 2005 de e-government que hizo Naciones Unidas, México está posicionado en el lugar número 9 en la transformación y madurez de gobierno electrónico, y ellos nos colocan prácticamente en la etapa tres de interacción, en la cual estamos al 88% y en la parte transaccional estamos en un 46%. Jose Luís Torres, consideró que para llegar a la etapa de integración o conectividad nos falta mucho, lo ideal sería estar en la Ciudad de México y pagar el catastro de alguna propiedad en algún otro Estado de la República, para allá estamos avanzando, no obstante el problema no es UPIICSA - IPN Página

44 tecnológico sino político para que haya la apertura y acuerdos entre las diferentes entidades, pues dada su autonomía esto es todavía prohibitivo en nuestro país. [InfoWorld-Mercado Arceo] De acuerdo con el Índice Global de Preparación para el Gobierno Electrónico ; México está situado en el lugar 31 de la Clasificación General, con un índice de Los tres países líderes son Estados Unidos (0.9058), Dinamarca (0.9058) y Suecia (0.8983), seguidos del Reino Unido (0.8777). El desempeño relativo de la región durante 2005 fue mixto, con solo cinco países que fueron capaces de mejorar su posición. Chile (22) mantuvo su posición de liderazgo regional con , Brasil con y Argentina con Como es de imaginar, en términos de promedios regionales los países de Norte América lideran con , seguidos de Europa con ; luego Asia Sur y Oriente con ; luego América Central y del Sur con ; luego Asia Occidental con ; luego el Caribe con ; luego Asia Sur y Central con ; luego Oceanía con y finalmente África con Siendo el promedio mundial de en el Es interesante notar que de la región, solo México y Chile se encuentran sobre el promedio de los países europeos y bastante por sobre el promedio de la región. México se encontraba en el lugar 30 durante 2003 y 2004, cayendo al lugar 31 en Los países con mayores avances son Corea (del 13 al 5 lugar entre 2003 y 2005); Singapur (del 12 al 7 lugar entre 2003 y 2005) y; Malta (del 27 al 21 lugar entre 2003 y 2005), estas posiciones, se pueden apreciar en la Tabla 3. Lugar País Índice 1 Estados Unidos Dinamarca Suecia Reino Unido Republica de Corea Australia Singapur Canadá Finlandia Noruega Alemania Holanda Nueva Zelanda Japón Islandia UPIICSA - IPN Página

45 16 Austria Suiza Bélgica Estonia Irlanda Malta Chile Francia Israel Italia Eslovenia Hungría Luxemburgo Republica Checa Portugal México Letonia Brasil Argentina Grecia Eslovaquia Chipre Polonia España Lituania Filipinas Emiratos Árabes Unidos Malasia Rumania Bulgaria Tailandia Croacia Ucrania Uruguay Federación Rusa TABLA 3. Clasificación a nivel mundial, fuente: Índice Global de Preparación para el Gobierno Electrónico de la ONU La comparación de las posiciones obtenidas en los reportes del 2006, 2005 y 2004 para América Latina y El Caribe, es la que se muestra en la siguiente tabla (tabla 4). En ella es relevante apreciar que la comparación entre los reportes del 2004 y 2006, solo Chile y el El Salvador han logrado avanzar, ambos en 3 posiciones. México en este mismo período retrocedió en 11 lugares y Brasil en 13. Muy impactantes resultan el caso de República Dominicana, Paraguay y Argentina que cayeron 32, 22 y 21 lugares respectivamente. UPIICSA - IPN Página

46 País Posición Variación Variación a a 2005 Chile Brasil Jamaica México El Salvador Colombia Uruguay Panamá Costa Rica Argentina Venezuela Perú República Dom Guatemala Honduras Ecuador Bolivia Nicaragua Paraguay TABLA 4. Comparación de las posiciones obtenidas en los reportes del 2006, 2005 y 2004 para América Latina y El Caribe. Fuente: Informes del Global Information Technology Report de años anteriores. A partir de la revisión de los principios del egobierno, la administración del entonces presidente de la republica Vicente Fox Quesada, implementó un plan de seguimiento para el desarrollo de las tecnologías del gobierno electrónico al interior de todas y cada una de las dependencias, el plan denominado Agenda del Buen Gobierno fue apoyado por el premio INNOVA cuyo objetivo era incentivar y motivar a las dependencias de gobierno a implementar lo mejor de los proyectos tecnológicos e innovadores en materia de gobierno electrónico. A su vez, se designó a un comité (figura 11) que se encargaría de planear la interoperabilidad de las distintas dependencias de gobierno, quedando plasmado todo ese conjunto de ideas e iniciativas en un documento cuyos puntos importantes a cubrir eran: UPIICSA - IPN Página

47 Lineamientos técnicos y administrativos. Programa de expansión de servicios. Convenios por Áreas Jurídicas de participantes. Etapa de instalación y pruebas. Figura 11. Comité de Interoperabilidad Fuente: SFP- Unidad de Gobierno Electrónico y Políticas de Tecnologías de la Información Durante la administración del gobierno pasado, se logró incrementar en gran medida el uso de los servicios electrónicos disponibles en Internet, gracias a la promoción que continuamente se hizo en medios de comunicación para promover el uso de servicios automatizados. Entre los más utilizados podemos ver los del portal de INFONAVIT, los portales del gobierno del Distrito Federal para el pago de servicios y de otros estados como Nuevo León y el Estado de México, cuyos portales cuentan actualmente con una gran cantidad de servicios disponibles. La figura 12 muestra el crecimiento en el uso de Internet en nuestro país en parte debido al incremento de servicios disponibles en la red. UPIICSA - IPN Página

48 Figura 12. Número de usuarios de Internet en México Fuente: Secretaria de Comunicaciones y Transportes SCT Normativas existentes para el gobierno electrónico Como parte del proyecto de gobierno electrónico, se decidió crear un organismo que administrara las normas y reglamentaciones de las nuevas tendencias administrativas en materia de gobierno electrónico, de esta forma surgió la Normateca. La Normateca Federal se sustenta en el Acuerdo para la difusión y transparencia del marco normativo interno de la gestión gubernamental, emitida en conjunto por la Secretaria de Hacienda y Crédito Público y la Secretaría de la Función Pública; su publicación se llevó a cabo el 6 de diciembre del 2002 en el Diario Oficial de la Federación. Las disposiciones que se pueden encontrar en la Normateca Federal, son aquellas de aplicación general que rigen la operación y funcionamiento de las dependencias y entidades del Gobierno Federal. Las disposiciones del Gobierno Federal se encuentran organizadas por materias y estas son: las referentes al Servicio Profesional de Carrera, Recursos Humanos, Presupuestales, las de Adquisiciones y Arrendamientos; Obra Pública, Transparencia y Bienes muebles. Actualmente las leyes mexicanas no han logrado rebasar la barrera de los problemas políticos y disputas por el poder, sin embargo, se ha logrado plasmar un plan de trabajo que contempla normar la mayor parte de los procesos administrativos y de los servicios que se ofrecen a la población en general. De esta manera, se ha podido llevar a cabo una diversificación de canales que aunque no están 100% normadas o legisladas, se han llevado al plano del modelo de gobierno electrónico, como ejemplo, podemos mencionar algunos de los servicios que más renombre han tenido en los últimos años: UPIICSA - IPN Página

49 Obtención de la CURP (Clave Única de Registro de Población). Realización de citas con el SAT (Servicio de Administración Tributaria). Consultar seguimiento en Chambanet (portal de bolsa de trabajo del gobierno). Consultar seguimiento en trabajaen.gob.mx, bolsa de trabajo para el Servicio Profesional de Carrera (SPC). Seguimiento a licitaciones en Compranet. Avisar fallas de luz. Seguimiento de solicitudes de información en el IFAI (Instituto Federal de Acceso a la Información). Citas con el ISSSTE (Instituto de Seguridad y Servicios Sociales de los Trabajadores del Estado). Consulta de calificaciones (SEP Secretaría de Educación Pública). Becas de la Secretaría de Relaciones Exteriores. Becas Crédito CONACYT (Consejo Nacional de Ciencia y Tecnología). Directorio de Librerías EDUCAL Avances y logros significativos Aún y con todos los problemas de una labor tan complicada, innovadora y transversal, México ha logrado una serie de avances muy significativos. Entre los más destacados se encuentran los siguientes: Centros Comunitarios Digitales: Para brindar mayor acceso a las comunidades rurales remotas, la Secretaría de Comunicaciones y Transportes por medio del programa eméxico, ha logrado abrir cerca de 10,000 puntos de acceso a Internet en centros comunitarios unidos por la red satelital. Portal Ciudadano del Gobierno Federal: el Gobierno Federal reúne en un solo portal todos los servicios y páginas web de las dependencias federales del gobierno con información para los ciudadanos y contenidos orientados al tipo de usuario (jóvenes, agricultores, migrantes, adultos de la tercera edad, discapacitados, empresarios, etc.). así como Transparencia y acceso a la información: Por medio de un sistema desarrollado de manera conjunta entre el Instituto Federal de Acceso a la Información Pública (IFAI ) y la Secretaría de la Función Pública (SFP- los ciudadanos pueden solicitar cualquier información pública en posesión del Gobierno Federal en cualquier momento y en cualquier lugar. El marco legal permite un uso eficiente UPIICSA - IPN Página

50 del sistema y obliga a los funcionarios a rendir cuentas a los ciudadanos y a fomentar la confianza en las instituciones públicas. Licitaciones electrónicas: Desde el año de 1996, México ha usado exitosamente el sistema en línea COMPRANET (www.compranet.gob.mx) para publicar licitaciones, licitar y administrar las contrataciones del sector público. Más de la mitad de las compras públicas del Gobierno Federal se hacen a través de COMPRANET, y el sistema ha sido actualizado recientemente. Servicios de salud: El Instituto Mexicano del Seguro Social (IMSS es una de las organizaciones públicas más avanzadas en materia de e-gobierno en México. Gran parte de sus procesos internos han sido redimensionados y reestructurados por medio del uso estratégico de TICs, los registros de sus pacientes están todos en bases de datos en línea que permiten a los médicos hacer comparaciones inmediatas de casos similares y tener un acceso inmediato al historial médico de un paciente; el sistema de rendición de cuentas de las compras del IMSS y el registro en línea de los almacenes médicos permiten un uso eficiente de los recursos de salud para los ciudadanos. Créditos financieros y servicios crediticios: Tanto Nacional Financiera como el Instituto Nacional para el Fomento a la Vivienda de los Trabajadores (INFONAVIT han revolucionado sus sistemas de administración y de aprobación de créditos para particulares y empresas, lo cual ha resultado en una explosión de créditos apoyado por la baja en las tasas de interés y el mejor tiempo de procesamiento de los créditos a particulares. Administración tributaria: El Servicio de Administración Tributaria (SATwww.sat.gob.mx) y la Secretaría de Hacienda y Crédito Público (SHCP han modernizado los sistemas impositivos fiscales y han recortado los procesos y tiempos para hacer declaraciones patrimoniales y fiscales en línea. Tramites y procesos administrativos: Han existido avances significativos en el Sistema de Apertura Rápida de Empresas (SARE), que gestiona la Secretaría de Economía y del Registro Único de Personas Acreditadas (RUPA) a cargo de la Secretaría de la Función Pública, la Secretaría de Hacienda y Crédito Público y la Secretaría de Economía. Por medio de ese sistema y este registro se hacen más eficientes los procesos y trámites para abrir y registrar un negocio y se evita la duplicación y replicación de funciones, atribuciones y tareas entre órganos públicos con competencias similares. Otros servicios informativos en línea como TRAMITANET (www.tramitanet.gob.mx), DECLARANET (www.declaranet.gob.mx), y el Orden Jurídico Nacional publican información detallada para ayudar a los ciudadanos en sus trámites. UPIICSA - IPN Página

51 2.2.6 Retos y desafíos del e-gobierno en México A pesar de estos avances, México enfrenta grandes retos en materia de e-gobierno para el futuro, entre los cuales se pueden destacar: La brecha digital: El mayor rezago y el reto más desafiante en México sigue siendo la brecha digital. Según la Asociación Mexicana de Internet, 17 millones de mexicanos tienen acceso a la red de redes. Pocos ciudadanos tienen acceso a Internet y a los servicios en línea, la alfabetización digital es mínima y sufre de brechas generacionales, socioeconómicas y de género, el gobierno digital no ha logrado penetrar en todos los hogares mexicanos. Los beneficios de la modernización y del gobierno electrónico sólo han impactado a la mayoría de los ciudadanos indirectamente (es decir, reducción de costos globales de operación del Estado) y los beneficios directos sólo han llegado en general a una población con acceso, con mayor nivel de educación y en su gran mayoría urbana. El parámetro de impacto y de éxito de cualquier política pública destinada a la provisión de servicios electrónicos es la brecha digital, y gran parte de los esfuerzos de cualquier administración deberá de orientarse a reducirla. Asimismo, la población reducida de usuarios no debería de ninguna manera constituir una condicionante para enfocar los esfuerzos en los procesos internos del gobierno; al contrario, el e-gobierno es un asunto de los ciudadanos para los ciudadanos y deberá de enfocarse a ellos. Marco Legal: La incertidumbre jurídica, los vacíos legales, la inseguridad patrimonial y la tramitología afectan la competitividad y el desempeño de las políticas informáticas y el e- Gobierno, especialmente cuando éstas se vinculan con la necesaria participación de la iniciativa privada. A ello habría que sumar los rubros de protección al consumidor para compras en línea, la lucha contra delitos electrónicos como fraude o pornografía infantil y de protección, confidencialidad y seguridad de datos personales. Asimismo, la normatividad legal para el buen desempeño gubernamental no depende sólo del Ejecutivo Federal sino también de las reformas legales que deben realizar los Estados de la República. No existe en este rubro una visión conjunta de los tres órdenes de gobierno. Las leyes que regulan las inversiones multianuales y la licitación, el arrendamiento y las compras del sector público también podrían beneficiarse de cambios que les permitan hacer un uso aún más eficiente de los recursos del Estado para cumplir con sus funciones. Integración del gobierno y colaboración entre dependencias: México es un país que ha promovido fuertemente la innovación de sus dependencias gubernamentales, que ha creado incentivos al reconocer a quienes desarrollen soluciones propias e innovadoras por medio de reconocimientos presidenciales (tales como los Premios Innova), además de un UPIICSA - IPN Página

52 sistema de evaluación y de gestión que favorece la negociación de metas individuales entre el Presidente y sus Secretarios y premia la obtención de metas previamente negociadas. Esta orientación a resultados es lo que ha impulsado las acciones del Gobierno Federal y ha permitido también ver resultados concretos de manera inmediata. Sin embargo, también ha llevado el costo oculto de promover el trabajo individual y la competencia entre Secretarías, lo cual va en contra del objetivo último del gobierno electrónico: crear un gobierno amigable con una ventanilla única, integrado y a disposición del ciudadano. Dada la falta de un programa en esta dirección y de incentivos para promover proyectos de integración y de colaboración, los casos de integración gubernamental y de colaboración son excepcionales. Aunado a este reto de colaboración entre entidades del Gobierno Federal se encuentra el mayor reto de colaboración entre distintos niveles de gobierno: el panorama municipal es sumamente diverso y el universo es muy vasto. Uno de los grandes retos en materia de e-gobierno en México es integrar al Gobierno en su totalidad con una misma arquitectura armonizada, desarrollar incentivos para fomentar la colaboración e institucionalizarla como práctica en la gestión y diseño de proyectos y constituirse como una herramienta capaz de unir todos los esfuerzos de los actores involucrados en el gobierno electrónico. Desarrollo de indicadores de evaluación y monitoreo: Otro gran reto es el de desarrollar indicadores para medir el desempeño del e-gobierno y para así justificar inversiones, rendir cuentas a los ciudadanos, y tomar mejores decisiones con base en un conocimiento detallado del terreno donde opera el gobierno electrónico. Existen pocos indicadores efectivos a nivel mundial y las prácticas internacionales aún no han explorado lo suficiente este campo para prestar lecciones al gobierno de México. Sin embargo, este tema operativo no debe dejarse de lado debido a que fortalece la justificación de inversiones por medio de casos de negocio sólidos, permite una operación más fluida con el Congreso para la autorización de presupuestos al simplificar el caso de una inversión para demostrar claramente sus resultados y permite también evaluar el desempeño de un proyecto o una iniciativa. Habilidades y capacitación de funcionarios públicos: México ha hecho algunos avances en materia de capacitación de funcionarios públicos en el desarrollo de capacidades técnicas para el uso de las TIC. Sin embargo, el desarrollo y la implementación de proyectos estratégicos de e-gobierno requiere más que el conocimiento básico de la tecnología, también requiere de una formación sólida en los conceptos de la administración pública, el marco legal, la negociación política de objetivos y presupuestos, la gestión financiera y las atribuciones operativas de unidad administrativa. UPIICSA - IPN Página

53 Entre más funcionarios conozcan los riesgos, los costos, las oportunidades y el potencial del gobierno electrónico, mejor estarán adaptados para desarrollar proyectos propios que tomen en cuenta el funcionamiento integral de una administración pública. Desarrollo de contenidos y participación ciudadana: A pesar de que gran parte del esfuerzo del gobierno se ha enfocado en la creación de puntos de acceso para que los servicios de e-gobierno lleguen a los ciudadanos, poco se ha hecho para involucrar a los ciudadanos en el diseño de contenidos, el acomodo de los servicios y la perfilación de los procesos en los cuales participan. El argumento del gobierno ha sido que los servicios han sido agrupados bajo un rubro o perfil de ciudadano (p. ej. estudiantes ). Pero una cosa es agrupar servicios y otra cosa es adaptar y reestructurar el servicio para responder a las necesidades de un grupo en particular. Asimismo, la participación de los ciudadanos en el diseño de políticas públicas puede ser potenciada de manera considerable por el uso de TICs. Sin embargo, el gobierno de México no ha hecho más que digitalizar las herramientas tradicionales de participación ciudadana (como enviar una queja o sugerencia por correo electrónico), cuando en realidad se podrían estar haciendo avances enormes en involucrar a los ciudadanos en los procesos de toma de decisiones públicas, el diseño de políticas públicas, y los modelos de retroalimentación del gobierno. Todavía hay mucho camino que recorrer, y entre más se involucre a los ciudadanos en el uso del e-gobierno para proveerles soluciones, mayor será su adherencia y su aprendizaje de esta herramienta. Definición de metadatos y esquemas: Un claro desafío, es que el orquestador de todo el proyecto de e-gobierno, pueda coordinar y centralizar el gran volumen de metadatos y esquemas, que se comenzará a definir independientemente en cada dependencia, la lógica indicaría que si una dependencia o Secretaría crea nuevos tipos de dato, metadatos o esquemas, esta definición puede convertirse en la oficial y estándar, para el uso de todas las demás dependencias del Gobierno 8. Esto resulta poco recomendable, ya que al no analizar el problema global, ni al especificar tipos de datos, metadatos y esquemas básicos, se dificulta la reutilización y un buen modelamiento de los datos. 8 La independencia de definición de esquemas y metadatos por cada dependencia sólo es válida cuando no exista una definición previa o la nueva sea incompatible con anteriores. UPIICSA - IPN Página

54 El hecho de que metadatos y esquemas se definan después de tener aplicaciones funcionando y no antes como ocurre en experiencias internacionales como GovTalk [govtalk], deja abierta la pregunta de si éste camino dará los resultados esperados [normaxml]. Definición formal de servicios: Para automatizar el diseño, creación, acceso, consulta y negociación de servicios en el e-government, ellos deben tener una especificación formal. A pesar de que para los servicios web existe un lenguaje de descripción de servicios (WSDL), no todos los servicios que entregan las organizaciones gubernamentales usan o usarán esta tecnología para proveerlos. Tampoco WSDL por sí solo especifica todo lo necesario para definir completamente un servicio web para el uso posterior de esta información. Qué funciones básicas deben de tener los servicios, qué metadatos y descripciones deben caracterizarlos, qué guías para la creación de interfaces y mensajes son necesarias, y que funcionalidad entrega el servicio (con el propósito de no repetir servicios)? Son definiciones que deben ser explicitadas para aprovechar de mejor manera el potencial de los servicios web. A pesar que esta tarea no es indispensable para un uso funcional de los Servicios, esto sí limita su potencial y dificulta su administración y gestión. Por lo tanto, este problema debería ser abordado primero definiendo guías para la creación, definición y desarrollo de servicios para el e-gobierno, para luego aplicarlo a los servicios disponibles y a la creación de los futuros. Sistema de autenticación de usuarios para ciudadanos y SSO (Single Sign On): Hoy en día existen servicios como el pago de impuestos que pueden realizarse en línea ingresando con un usuario y clave entregada por la dependencia responsable del servicio, lo cuál es un avance hacia la identificación de usuarios recurrentes a los mismos servicios en común que pueden ser agrupados en un solo portal y accedidos a través de un SSO. Single Sign On (SSO por sus siglas en inglés) es procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación, es decir, sólo una vez se registran los datos y se tiene acceso a una o varias aplicaciones. El desafío en el mediano plazo es tener una interfaz común de autenticación a todos los servicios y en el corto plazo una forma de autenticarse ante cada organismo de gobierno de la misma forma. UPIICSA - IPN Página

55 Este trabajo ha identificado al menos las siguientes preguntas que deben abordarse para definir un esquema de autenticación completo y exitoso. o Qué tipos de autenticación estarán disponibles (usuario y clave, token, otro)? o Cual será la validez legal que tendrán los distintos tipos de autenticación en los servicios? o Se debe usar una o varias claves? Por ejemplo si se usa una clave por servicio y se quiere permitir un esquema de SSO, se pueden definir claves maestras. o Que institución tiene la autoridad para autenticar? o Existirá la posibilidad de que los ciudadanos puedan personalizar los servicios que quieren utilizar mediante autenticación con su usuario y clave y cuales no? o Se permitirá que agentes de otros sistemas fuera del gobierno, como los bancos puedan usar los servicios de autentificación del gobierno y viceversa? Coordinación en la definición de servicios por parte de dependencias de Gobierno: Se debe procurar no repetir servicios y asegurar que los existentes no se contradigan en su funcionamiento o sean inconsistentes. Este desafío tiene la misma vigencia que el de la definición de metadatos y esquemas, en el sentido que se deben definir herramientas y mecanismos para administrar la existencia, definición de funcionalidades y uso de los servicios. Una posible solución a este problema puede ser el uso de un UDDI semántico (directorio semántico de servicios web) como el presentado en [frez-ws-admin]. Depósitos: El uso de depósitos que mantengan datos sobre ciudadanos ya sean públicos, reservados o privados, datos sobre los procedimientos mismos del gobierno, comunicaciones entre dependencias, u otros deben definir: a) Propiedad/Autoridad: Si cada dependencia tiene acceso y administra sólo sus propios depósitos: o Quién tiene la autoridad de generar datos y resúmenes? o Quién se ocupa de la corrección y actualización de información y de que se propague a quienes corresponda? o Si una dependencia obtiene información de otras, Tiene ella la autoridad para presentar tal información frente a terceras personas (dependencias u organismos) como la fuente? (delegación de autoridad). Ejemplo: Secretaría de Salud al obtener consolidados de nacimientos y defunciones en Hospitales, y Secretaría de Hacienda al hacer el seguimiento de documentos y requisiciones de presupuesto. UPIICSA - IPN Página

56 b) Centralización/distribución: Por temas de eficiencia, facilidad para actualización de información, disponibilidad, entre otras: o Qué tipo de información debería centralizarse? Los datos de los procesos o ciudadanos, la descripción formal de servicios, información para autenticación? o Si alguna dependencia necesita información confidencial obtenida por otras dependencias, Cuál es la mejor arquitectura en cuestiones de seguridad? Es escalable esta opción? o Es mejor mantener los depósitos en cada dependencia y crear los canales de comunicación entre ellas, o crear BD centralizadas? Es escalable la solución? Mantenibilidad de estándares: Las leyes existentes y aquellas que puedan crearse con el fin de tener una normatividad en el e-gobierno en México pueden requerir modificaciones, por ejemplo las normas de seguridad o exigencias sobre el documento electrónico, la firma electrónica avanzada, las transacciones de información segura, etc. Crear, mantener y actualizar estas definiciones y hacerlas compatibles con las existentes requiere un esfuerzo del Gobierno y demás entidades relacionados [normaxml]. Migración de Información: Debido a la existencia de sistemas computacionales que no usan XML y debido a toda la documentación existente sólo en papel, se requiere una forma de migrar esa información [normaxml]. Esta migración ya está en proceso mediante la digitalización de algunos documentos, sin embargo, no todas las migraciones involucran pasar a un formato XML sino que algunas corresponden a la obtención de imágenes digitales de los documentos. Los desafíos consisten en: o Comenzar a generar pronto la información en formato XML para no tener que seguir migrando cada vez mayores cantidades de información. o Hacer interoperar la información migrada con los servicios que se entregan o desarrollarán en el futuro. Por ejemplo, agregando metadatos como un identificador del folio y el trámite asociado a documentos digitalizados como imágenes. o Crear transformaciones sobre los depósitos de datos ya existentes para generar documentos en XML (paso del modelo relacional, orientado a objetos, u otro, a documentos en XML). UPIICSA - IPN Página

57 Sumar al esfuerzo del e-gobierno a todas las dependencias del Estado: Hacer partícipes a todas las instituciones gubernamentales en el e-gobierno, involucra la consideración de todas ellas para el rediseño de procesos, entrega de servicios y comunicación de información. Para el caso de las instituciones con menos recursos o que no cuenten con la tecnología adecuada tales como Municipios, Hospitales o Universidades, se debe elegir un modelo donde a estas entidades también se les incorpore al mundo del e-gobierno. La definición de arquitectura, plataforma, software de aplicación, flujos documentales, tecnologías, guías para desarrollo de servicios, metadatos y esquemas, deben ser especificadas para reutilizar el conocimiento adquirido (replicar soluciones) y agilizar el desarrollo del e-gobierno. Para esto, se deben realizar experiencias exitosas que dicten las pautas de desarrollo, para lo cual los planes pilotos acotados que no tengan un alto riesgo debido a las dimensiones del proyecto resultan una buena alternativa. Como siguientes pasos en el desarrollo del e-gobierno en México, se propone la experimentación mediante planes piloto o proyectos de mediana envergadura por encima del desarrollo de soluciones globales. Esto se fundamenta en los siguientes puntos: o A pesar de que existen desarrollos exitosos en otros países, no hay una gran madurez en experiencias internacionales a manera de apoyar el desarrollo en México. o Un proyecto de gran envergadura involucra la coordinación de muchas instituciones que agrega un factor de incertidumbre y complejidad, que podría ser postergado luego de que se abordaran problemas anteriores como interoperabilidad, estandarización de tipos de datos, entre otros. o Durante el desarrollo de la solución se deben especificar un número no despreciable de nuevas definiciones como esquemas XML, API de servicios y metadatos. En México no existe mucha experiencia al respecto y no es claro que este desarrollo pueda ser llevado a cabo en los plazos estipulados. o Los puntos anteriores representan factores de incertidumbre que según la experiencia de la Ingeniería de Software requieren ser disminuidos o eliminados, antes de continuar con iniciativas tan complejas como lo es la implantación del e- Gobierno. UPIICSA - IPN Página

58 2.2.7 Iniciativas principales para e-gobierno en México. El proyecto de e-gobierno y de Innovación Gubernamental de la anterior administración (sexenio de Vicente Fox) y por consiguiente de la administración actual, puede correr el riesgo de seguir un ciclo de concepción, nacimiento, desarrollo y muerte. Existen varias dependencias que han sido exitosas en materias de e-gobierno tales como: el Servicio de Administración Tributaria (SAT), el Instituto Mexicano del Seguro Social (IMSS), la Secretaría de Relaciones Exteriores (SER), Nacional Financiera (NAFINSA), el Banco de Comercio Exterior (BCE), el Instituto de Fomento Nacional a la Vivienda de los Trabajadores (INFONAVIT) y la Secretaría de la Función Pública (SFP), por mencionar los casos más conocidos del ámbito Federal y sin tomar en cuenta el amplio éxito que han tenido algunas administraciones estatales y municipales, sin embargo, su consolidación y trascendencia más allá de los periodos presidenciales no está exenta de riesgos si se toma en cuenta la dinámica sexenal de siempre que termina enterrando proyectos al final de cada sexenio. El 9 de diciembre de 2005 se publicó en el Diario Oficial de la Federación el Acuerdo Intersecretarial para el Desarrollo del Gobierno Electrónico, cuya aspiración era establecer un marco de gobernabilidad para las TIC en el Gobierno Federal. El acuerdo instaló un Comité Intersecretarial compuesto por los secretarios de Estado de la Administración Pública Federal (APF) de ese momento, y los comprometió a nombrar un responsable del gobierno electrónico en sus respectivas Secretarías. Estos a su vez pasarían a integrar un Consejo Técnico, que se encargaría de normar las políticas relacionadas con el gobierno electrónico. Sin embargo, es posible encontrar algunas dificultades de este acuerdo, pues al no tratarse de una ley federal ni de un decreto presidencial, se considera insuficiente para continuar en operaciones una vez terminado el sexenio. Dado que el acuerdo comenzó a operar hacia finales del primer trimestre del 2006 es posible pensar que el siguiente sexenio no pueda consolidar y legitimar sus operaciones. UPIICSA - IPN Página

59 2.3 Experiencias internacionales Según estudios internacionales [ONU 2005, 2004] y [accenture2004], existen países tales como Estados Unidos, Australia, Canadá y Reino Unido, que muestran un buen índice en la efectividad y eficiencia de sus políticas de e-gobierno, alcanzando buenas calificaciones dentro de los niveles de madurez del gobierno electrónico. Para el caso de los Estados Unidos, Darrell West (2005,2006) ha seguido con detalle la evolución de los portales gubernamentales, publicando anualmente un análisis de sitios web federales, estatales y locales. Estos reportes no solo contienen las evaluaciones de los sitios de acuerdo a diferentes variables de interés sino que describen cómo han cambiado y qué tipo de mejorías se han llevado a cabo en el año inmediato anterior. Este esfuerzo anual ha permitido a los desarrolladores y a quienes toman las decisiones de contenidos de los sitios web gubernamentales que puedan comparar sus resultados, competir entre ellos y mejorar a través de una medición imparcial, neutra y lo más objetiva y científica posible. Lamentablemente en México no ha existido hasta el momento un esfuerzo similar. A pesar de los avances del e-gobierno en algunos países, existe un bajo nivel de coordinación transversal entre las distintas dependencias de gobierno. Esto resalta la importancia de la definición de estándares y especificaciones, que entreguen interoperabilidad y flexibilidad suficiente para comunicar sistemas que fueron desarrollados bajo distintas definiciones. Estudios análogos, pero enfocados desde el punto de vista técnico para el e-gobierno, son escasos. A continuación se nombran algunas de las experiencias internacionales más destacadas en el tema Reach Reach es una institución del gobierno de Irlanda, creada para desarrollar una estrategia capaz de integrar los servicios públicos, y un framework para el gobierno electrónico [reach]. Para ello Reach ha diseñado e implementando (parcialmente en algunos casos), un conjunto de iniciativas en pro de la interoperabilidad y automatización, entre las cuales se encuentran: Interoperability Framework: Define un marco de trabajo (framework) de interoperabilidad que considera entre los tipos de interoperabilidad la semántica, tipos de datos, etcétera. UPIICSA - IPN Página

60 Inter-Agency Messaging Service (IAMS): El IAMS es un servicio de mensajería donde sistemas intermediarios o también llamados brokers, intercambian mensajes con información de los ciudadanos entre dependencias del Estado. El IAMS ha logrado interoperabilidad y automatización entre distintas dependencias y permite el uso de mensajería a ciudadanos. Lamentablemente su debilidad radica en el uso de protocolos cerrados (y no todos estándares) para el intercambio de información, con una consecuente falta de extensibilidad e interoperabilidad. Service Integration & Interoperability: Por un lado Reach ha desarrollado un conjunto de buenas prácticas para desarrollar servicios que puedan ser integrados concentrado en la iniciativa llamada Reach Interoperability Guides (RIGS), definiendo recomendaciones para creación y manejo de documentos XML, estructura de los mensajes a enviar entre otras. Por el otro lado existe un portal para el ciudadano con un conjunto de servicios a su disposición organizados según categoría llamado Service Index. Esta iniciativa se asemeja a la de TrámitaNET y eméxico en nuestro país [tramitanet]. Public Service Broker (PSB): 9 Es un sistema que hace las funciones de intermediario entre las dependencias del gobierno y entre ellas y los ciudadanos, permitiendo llamar de manera estándar a los servicios públicos. El PSB es también la definición de una arquitectura e infraestructura para integrar tales servicios. El PSB consta de 3 componentes principales: Una interfaz de usuario como portal con acceso a información y servicios. Un middleware que permite la integración de servicios, basado en XML y servicios web. Una capa que ejecuta los servicios al interior de cada dependencia y se comunica con el broker. 9 Basado en experiencias existentes hasta Mayo del 2005, Irlanda. UPIICSA - IPN Página

61 2.3.2 GovTalk Una de las experiencias internacionales más desarrolladas conceptualmente y referente al e- Gobierno, es la llamada GovTalk [gov-talk] perteneciente al Gobierno del Reino Unido. El trabajo de GovTalk se basa en la definición de un framework (marco de trabajo) para interoperabilidad llamado Interoperability Framework for e-government (e-gif de ahora en adelante). El e-gif define políticas técnicas y requisitos para alcanzar la interoperabilidad y coherencia entre sistemas del sector público. Entrega un framework de los estándares recomendados para el intercambio de información en el gobierno. La arquitectura del e-gif se puede ver en la Figura 13 y a continuación se realiza una breve descripción de sus componentes. Figura 13: Arquitectura e-gif. Figura tomada de GovTalk [e-gif, Metadatos en el e-gif (e-gms, GCL): El Government Metadata Standard (e-gms) [e-gms] se puede ver como una extensión a Dublín Core [dublin-core], que define un conjunto de metadatos y esquemas básicos que sirven de base para los servicios a desarrollar. Cada servicio particular puede agregar nuevas restricciones o quitar las que no apliquen. Por su parte el Government Category List (GCL) define una lista de categorías (valores) para cada elemento en el e-gms. Government Data Standard Catalogue (GDSC): Especifica los tipos y convenciones básicas para los datos comunes a usar en todas las dependencias del estado, usando esquemas XML. Por ejemplo para en el caso de México se establece que uno de los estándares para el CURP es, que debe ser una cadena (String) de 15 caracteres conteniendo números y letras con restricciones de negocio (nomenclatura) y que describan de manera única el registro de cada uno de los habitantes del país. UPIICSA - IPN Página

62 Schemas: Define buenas prácticas y guías para esquemas XML junto con casos de estudio para la creación de esquemas. Cabe recalcar que la especificación de datos, servicios etc. Se hace a través de esquemas XML por lo que este componente de la arquitectura es esencial. Technical Standards Catalogue (TSC): El Catalogo de Técnicas Estándar es una definición de tecnologías específicas sobre las cuales se recomienda se creen los servicios y definiciones que harán posible la interoperabilidad en el e-gobierno, el catalogo contiene las políticas técnicas del marco de trabajo para la interoperabilidad (e-gif), tablas de especificaciones, un glosario y una lista de abreviaturas. Por ejemplo se menciona que para la descripción de servicios web se recomienda usar WSDL. E-Services Development Framework (e-sdf): Este resulta el componente más interesante para el modelo británico, ya que provee una metodología para utilizar especificaciones y estándares de interoperabilidad de servicios electrónicos y para el intercambio de datos y mensajes en servicios automáticamente en el sector público. Para ello el e-sdf define un conjunto de componentes entre los cuales están el Modelo de referencia para mensajes de gobierno, Government Message Reference Model (GMRM) que define un modelo de datos para los mensajes a ser intercambiados entre servicios y el Modelo para información común de gobierno, Government Common Information Model (GCIM) que define un modelo de datos para especificar las actividades que forman la lógica de un servicio compuesto de varias interacciones. Finalmente, el e-sdf define además un marco de trabajo (framework) para el desarrollo de servicios 10 (ver Figura 14) donde se nota como usa al GCIM, GMRM y los otros componentes para definir formalmente un servicio y llegar desde la descripción lógica del mismo, hasta una especificación de los mensajes y datos usando esquemas XML. 10 El Framework de desarrollo se puede ver como una adaptación del Rational Unified Process (RUP). UPIICSA - IPN Página

63 Figura 14: Framework del e-sdf para desarrollo de nuevos Servicios. Figura tomada de GovTalk [egif, AGLS El Australian Government Locator Service (AGLS) Metadata Standard [agls-35, del gobierno de Australia, busca etiquetar los recursos (como los servicios) con metadatos, para que las personas puedan encontrarlos de manera efectiva y eficiente, es decir, apunta a la interacción persona-máquina. Para ello define un conjunto de 19 elementos descriptivos que utilizan las dependencias gubernamentales australianas basadas en el estándar Dublin Core [Dublín-core]. Además entrega guías para decidir si un recurso necesita o no metadatos, define los procesos y etapas que se deben seguir para crear vocabularios y esquemas XML UPIICSA - IPN Página

64 2.3.4 Organizaciones internacionales W3C (WWW Consortium) El Consorcio World Wide Web (W3C) es un consorcio internacional donde las organizaciones miembro, personal de tiempo completo y el público en general, trabajan conjuntamente para desarrollar estándares Web. La misión del W3C es: Guiar la Web hacia su máximo potencial a través del desarrollo de protocolos y pautas que aseguren el crecimiento futuro de la Web. El W3C desarrolla Estándares Web y Pautas El W3C trata de alcanzar su objetivo principalmente a través de la creación de Estándares Web y Pautas. Desde 1994, el W3C ha publicado más de ciento diez estándares, denominados Recomendaciones del W3C. El W3C también está involucrado en tareas de educación y difusión, y en el desarrollo de software, sirviendo a su vez como foro abierto de discusión sobre la Web. Para que la Web alcance su máximo potencial, las tecnologías Web más importantes deben ser compatibles entre sí y permitir que cualquier hardware y software, utilizado para acceder a la Web, funcione conjuntamente. El W3C hace referencia a este objetivo como "interoperabilidad Web". Al publicar estándares abiertos (no propietarios) para lenguajes Web y protocolos, el W3C trata de evitar la fragmentación del mercado y, por lo tanto, la fragmentación de la Web. El W3C es un Consorcio Internacional Diferentes organizaciones, procedentes de diversos puntos del mundo y de campos muy diferentes, forman parte del W3C con intención de participar en un foro neutral para la creación de estándares Web. Los miembros del W3C y un grupo de expertos técnicos, han hecho posible que el W3C sea reconocido a nivel internacional por su contribución en el desarrollo de la Web. Los Miembros del W3C (testimonios), el personal y los expertos invitados trabajan juntos para diseñar tecnologías, con el objetivo de asegurar que la Web continuará creciendo en el futuro, adaptándose a la creciente diversidad de personas, hardware y software. Entre las iniciativas globales del W3C se encuentra la de mantener sus asociaciones con organizaciones nacionales, regionales e internacionales en todo el mundo. Estos contactos ayudan al W3C a establecer una cultura de participación global en el desarrollo de la World Wide Web. El W3C ha establecido una colaboración especialmente estrecha con otras UPIICSA - IPN Página

65 organizaciones que están desarrollando estándares para la Web o para Internet con intención de facilitar el progreso. El documento sobre Participación Mundial en el Consorcio World Wide Web resume los esfuerzos del W3C por ampliar su impacto internacional; para obtener más información visite la página principal de relaciones internacionales. OASIS OASIS es uno de los consorcios que produce más especificaciones relacionadas con servicios web. Los temas de las especificaciones tratan temas de seguridad, entrega confiable de mensajes, notificación, descubrimiento e invocación y modelado de procesos de negocio. OASIS también apuesta a la adopción de estándares y creación de patrones y guías con mejores prácticas, enfocados a las necesidades particulares del e-government. Algunos temas en este ámbito son: interoperabilidad semántica, flujos de trabajo (workflows), servicios web, junto con los otros estándares de OASIS. A pesar de que las guías en temas de e-gobierno están en constante actualización, las otras especificaciones técnicas que ofrecen, resultan importantes debido a su madurez y alto soporte por parte de la industria. 2.4 Otras experiencias de integración en México. Existen otras organizaciones que no abordan explícitamente el problema del e-gobierno, pero si tecnologías o estándares que lo impulsan. Entre ellas están la W3C (World Wide Web Consortium) que se menciono anteriormente y la WS-I (Web Services Interoperability Organization, Por un lado la W3C desarrolla recomendaciones Web y guías, entre las cuales se encuentran XML, XML Schema, SOAP, WSDL y modelos sobre la arquitectura Web. Por su parte, la WS-I crea, promueve y soporta protocolos genéricos para el intercambio de mensajes de manera interoperable usando servicios web. Además desarrolla guías y prácticas recomendadas, para implementar servicios web interoperables. UPIICSA - IPN Página

66 2.4.1 Experiencias ERP Telcel Oracle. Radio Móvil DIPSA -Telcel, una empresa de telefonía celular líder en el mercado de dicho ramo, realizó a principios del año 2002 una serie de acciones con el propósito de colocar a la empresa en la cúspide de las comunicaciones por vía celular, la entrada en México de la tecnología GSM para celulares de 3ª generación provocó que la empresa buscara posicionarse como la primera en incorporar celulares con cámara fotográfica, transmisión de datos, voz y multimedia, iniciando así una gran campaña con la promoción de la nueva generación de celulares GSM. Al interior de la organización, esto derivo en que se redefinieran estructuras organizacionales y que las distintas áreas entraran en un proceso de mejora continua, con la incorporación de la planeación estratégica y de la filosofía de la certificación ISO-9000, se definieron los pasos a seguir para entrar todos en un proceso de mejora continua. En los meses subsecuentes se definió una Misión, Visión, Metas y Objetivos en todos los niveles organizacionales, que motivaron a toda la empresa a realizar procesos de calidad y buscar la certificación ISO-9000 para poder tener un respaldo de su nueva política de calidad y posicionarse mejor en el mercado. En este contexto de entrar en un proceso de mejora continua, se tomó la decisión de reemplazar los sistemas obsoletos o que en su momento representaban un dolor de cabeza, por el mantenimiento que requerían y por la serie de problemas que traían arrastrando de tiempo atrás. Dentro de los sistemas que se tomó la decisión de renovar se encontraba el sistema de NOMINA, el cuál era un desarrollo hecho por un proveedor externo que en su momento implemento dicho sistema en una plataforma UNIX, trabajando con Informix y lenguaje 4GL para las pantallas y la operación. Se lanzó así un concurso para la compra de un ERP el cuál dentro de sus módulos contemplara la administración de todos los módulos que comprendía la nómina a su alrededor; después de varios meses de presentaciones con distintos proveedores (ORACLE, PeopleSoft, Meta4, SAP, Unisys, entre otros), el comité tomó una decisión y la ganadora fue PeopleSoft, sin embargo por razones de mercadotecnia y debido a la compra de ORACLE de la mayoría de las acciones de PeopleSoft, se decidió cambiar de última hora a ORACLE. En un principio, el proveedor prometió cubrir un 80% de la operación de nómina, incluyendo la administración de reclutamiento de personal, capacitación, administración de parque vehicular, directorio activo de la empresa y 6 módulos más que tenían que ver con la administración de los UPIICSA - IPN Página

67 recursos humanos y empresariales, además de que en un plazo de 6 meses el sistema estaría implementado a un 90% gracias a que su producto era totalmente adaptable, modificando pocos módulos y en poco tiempo. La implementación dio inicio a mediados del mes de Julio de 2004 con la promesa de que entraría en producción a principios del siguiente año, sin embargo, al poco tiempo se comenzaron a aplazar fechas debido a que los propios consultores de ORACLE determinaron que no eran factibles sus fechas de entrega por la complejidad del negocio, la poca adaptación del sistema al entorno de las demás áreas que pretendía cubrir, sumando además la poca experiencia de algunos consultores en la implementación de ERP s y su desconocimiento del negocio por completo. La compra del equipo fue un gasto que pareció ser un gasto excesivo dado que la aplicación requería de una infraestructura bastante robusta que no alcanzaba a cubrir la empresa con los recursos que tenía. De los puntos que se encontraron al corte de diciembre de 2006, se pudo resumir que el producto no cubría más de un 30% del negocio de la empresa, a consecuencia principalmente de los siguientes motivos: El producto resulta ser muy complejo de entender y usar. El producto requiere cambios en la organización de la compañía y procesos para su instalación. La capacitación sobre el uso del producto resulta ser muy pobre para el usuario. La operación se volvió más lenta en comparación con el producto anterior (Informix 4GL). Por otro lado se encontraron algunas ventajas como: Se tiene un solo sistema para el manejo de muchos procesos organizacionales. Se integran las funciones de varias aplicaciones. Reduce los costos de la gerencia Esto no ha sido suficiente para el comité evaluador de la implementación que aún a fechas del presente trabajo siguen en estatus de espera para poder pasar a un ambiente de producción. Para arreglar estos problemas, las compañías a menudo pierden de vista el hecho de que los sistemas o paquetes ERP no son más que unas representaciones genéricas de las formas típicas de hacer negocio en las empresas. Mientras que la mayoría de los paquetes son exhaustivamente integrales, cada industria tiene sus características que lo hacen único. Esto demuestra un poco lo que se presento hacia el final del primer capítulo de este trabajo de tesis, donde se menciona y se grafica en la figura 8 lo que se requiere para el éxito de un proyecto UPIICSA - IPN Página

68 ERP, conocimiento del sistema de ERP(que no se tuvo en este caso) y conocimiento detallado sobre el proceso de negocio (el cuál no se presento por parte de los consultores de Oracle). Si bien es posible rescatar que algunos de los procesos del área de Recursos Humanos se salvan de la mala implementación del sistema ERP, también es importante mencionar que en el proceso de adaptación, se hicieron trabajos de integración de otros sistemas (desarrollo de interfaces) para poder solventar el problema que no pudo resolver el sistema ERP. El desarrollo de dichas interfaces no requirió de mucha inversión, dado que la mayoría de ellas se hicieron bajo el esquema de software libre de licenciamiento, con tecnologías como CORBA, COM y servicios web. Un caso en particular de las interfaces desarrolladas con servicios web, fue la del área de sistemas corporativos que requirió de un servicio que al invocarse devolviera los datos principales de un empleado tales como: número de empleado, nombre, puesto, sueldo mensual y antigüedad para realizar procesos administrativos y organizacionales de la empresa. En el caso particular de esta empresa privada, podemos ver que no siempre la implementación de un sistema ERP resuelve todas las necesidades de integración de aplicaciones, independientemente de las razones por las cuales no se tuvo éxito, cabe destacar el uso de otras tecnologías que cubren en gran medida los requerimientos de integración de aplicaciones, a un menor costo y con menos infraestructura de la que se pretende para un sistema tan complejo como un ERP Experiencias ERP SAT PeopleSoft A principios del año 2005, el Servicio de Administración Tributaria (SAT) comenzó la reestructuración de su plataforma tecnológica motivada por la implementación de las nuevas políticas del gobierno electrónico y el ahorro de papel del entonces presidente Vicente Fox Quesada. Así pues, se dio inicio al proyecto PLATAFORMA tecnológica para implementar un portal único y más ágil para la administración tributaría, el cuál permitiría recaudar una mayor cantidad de impuestos, al ser más flexible y más rápida en respuesta que una administración local. Para tal proyecto, se lanzó la licitación para que fuera desarrollada la solución por un proveedor que tuviera la capacidad de cubrir la mayor cantidad de negocio que tenía en ese momento la dependencia. Finalmente el ganador resultó ser el ERP de la empresa PeopleSoft, que inicio de inmediato sus actividades para poder llevar a cabo una pronta implementación comenzando a interactuar con las áreas de negocio (Soluciones de Negocio y Asistencia al Contribuyente) de la UPIICSA - IPN Página

69 propia dependencia. En poco tiempo comenzaron a aparecer una gran cantidad de proveedores para poder sacar adelante la SOLUCION INTEGRAL SAT, entre ellos, Jack Be México, Oracle, Hewlett Packard, Documentum y otros más que en su momento intervinieron para el desarrollo del producto. Al poco tiempo, se definieron grupos de trabajo para interactuar de mejor forma entre la dependencia y el proveedor, sin embargo, el proceso de integración no llevo un adecuado control, lo cual derivó en una serie de retrasos por parte de los proveedores al argumentar que el negocio era difícil de implementar de la misma forma a como ya estaba solucionado, dado que las herramientas de desarrollo que se promovieron no tuvieron la adecuada medición del alcance que tenían para solventar la operación tan robusta de la tecnología anterior. Con estos inconvenientes, se optó por retrasar el proyecto y solventar la recaudación de impuestos para los años 2006 y 2007 con las tecnologías y metodologías tradicionales, las cuales contaban con un rendimiento comprobado en los ejercicios anteriores, sin embargo, se reanalizó la situación que provocó el retraso en la salida de la SOLUCION INTEGRAL llegando a la conclusión de que la mejor solución sería aquella que interactuara entre la robustez de la tecnología anterior y la flexibilidad de las nuevas propuestas, es decir el desarrollo de interfaces. Con este nuevo análisis de la situación se optó por la inclusión de servicios web para la interacción entre dichas plataformas (la actual y la nueva) a fin de soportar una operación de gran tamaño, sin dejar de lado la nueva propuesta de un portal único Nuevamente la intención de citar el caso de un sistema de ERP que no prospero ahora en el sector público, es citar el uso de tecnologías alternas que implican un menor gasto en recursos y un aprovechamiento más óptimo de la infraestructura con la que cuentan las organizaciones. Esto nos lleva de nuevo a ver que las soluciones alternas a los grandes productos para la integración de aplicaciones, vuelven a ser tecnologías abiertas como los servicios web y desarrollos hechos en casa (internamente hablando de la organización), que son mejor implementados por el personal con experiencia y conocimiento del negocio. Dejando de lado las razones por las cuales pueda fallar o no la implementación de un ERP u otro producto comercial de alto costo, es posible ver que existen tecnologías alternas que han tenido éxito en la solución de problemas muy particulares como el de la integración de aplicaciones, uno de estos caminos alternos que han tenido éxito y gran aceptación es el uso de los servicios web. UPIICSA - IPN Página

70 Capítulo 3 Conceptos, Tecnologías de Información y Servicios Web Este capítulo presenta las bases teóricas de las tecnologías usadas para resolver el problema de la integración de aplicaciones, menciona los aspectos a tomar en cuenta para determinar el uso o no de servicios web, y los conceptos necesarios para entender el contexto bajo el cuál se puede trabajar una solución basada en tecnologías alternas. UPIICSA - IPN Página

71 3 Conceptos, Tecnologías de Información y Servicios Web. 3.1 Conceptos Básicos El término Gobierno electrónico nace en la década de los 90 como una manera de describir el quehacer del gobierno apoyado por las nuevas Tecnologías de Información y Comunicación (TIC) en pro del incremento de la eficiencia y efectividad de las funciones gubernamentales Es necesario enfatizar que la finalidad del gobierno electrónico, no es tecnologizar los procesos existentes tal cual están hoy sino replantear los procesos y servicios del gobierno, con el fin de mejorarlos y ponerlos al servicio del desarrollo de una nueva sociedad de la información. Para mejorar la eficiencia y efectividad de los servicios que brinda el Estado, resulta importante automatizar los procesos internos, las relaciones entre ellos y los procesos externos. El concepto de automatización, se define como la acción de automatizar una actividad por parte de un sistema que se regula por sí mismo, eliminando la intervención de agentes externos que constituyen la principal razón de errores en un proceso, como puede ser la intervención de la mano del hombre. Automatizar. Aplicar a una industria máquinas o procedimientos automáticos [Diccionario de la lengua española]. Para la definición de servicio podemos mencionar algunas fuentes para comprender mejor el enfoque en el ámbito de los sistemas de información. En economía y mercadotecnia (marketing) un servicio es el equivalente no material de un bien. La prestación de un servicio no resulta en posesión y así es como un servicio se diferencia de proveer un bien físico. El servicio se define como un bien útil que presentan algunos establecimientos a cambio de un costo. [INEGI. Recorrido por México, Servicio, es el resultado generado por actividades en la interfaz entre el proveedor y el cliente y por actividades internas del proveedor, con el fin de responder a las necesidades del cliente [ISO-8402]. UPIICSA - IPN Página

72 Entre las características propias de un servicio que permiten diferenciarlo de un producto está la intangibilidad (es decir que un servicio no puede verse, probarse, sentirse, oírse ni olerse antes de la compra), la heterogeneidad (dos servicios similares nunca serán idénticos o iguales), la inseparabilidad (la producción y el consumo son parcial o totalmente simultáneos), la perecibilidad (un servicio no se puede almacenar) y la ausencia de propiedad (los compradores de un servicio adquieren el derecho a recibir una prestación, uso, acceso o arriendo de algo, pero no la propiedad del mismo). De esta manera la automatización de servicios implica que los procesos que componen el servicio sean realizados de manera automática, sin la interacción de agentes externos para minimizar el número de errores y tratar de que el servicio esté disponible la mayor parte del tiempo. Es importante notar que para que exista la automatización de servicios en el Estado, es vital la interoperabilidad de los sistemas heterogéneos (sistemas con diferencias tecnológicas y propósitos variados) con que cuenta cada dependencia. Así resulta necesario definir formalmente el concepto de Interoperabilidad. En el ámbito computacional, la interoperabilidad se asocia con la capacidad de comunicar sistemas de manera que intercambien y compartan datos e información [e-gif]. Sin embargo, la interoperabilidad computacional no es la única existente. A partir del ejemplo introductorio de la tesis se puede ver que para que el SAT, o cualquier otra dependencia de gobierno puedan comunicarse con las demás entidades, deben existir acuerdos previos desde los puntos de vista de la voluntad política, legal y gubernamental entre otros. Ello también forma parte de la interoperabilidad necesaria para el éxito del servicio. Una clara muestra de los pasos que se han dado en la actualidad para apoyar la definición eficaz de protocolos, guías e implementación de aplicaciones interoperables, es la existencia de un conjunto de organizaciones interesadas en promover la interoperabilidad. Algunas de estas organizaciones son la Web Services Interoperability Organization (WS-I) [ws-i] (interoperabilidad técnica) y la Organization for the Advancement of Structured Information Standards (OASIS) [oasis] (interoperabilidad semántica y organizacional) que se mencionaron anteriormente en este documento. UPIICSA - IPN Página

73 Una de las tecnologías de mayor auge que ha prometido ser quien brinde la mayor interoperabilidad, es la de los servicios web. NOTA: El titulo de este trabajo hace uso del término Web Services por que así es conocida la tecnología de origen, sin embargo, para mayor entendimiento en el idioma español, se usará en la mayor parte de la redacción la traducción al castellano como Servicios Web. Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Las aplicaciones de software desarrolladas en lenguajes de programación diferentes y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de computadoras locales o bien a través de Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Los servicios web permiten tanto la ejecución de servicios simples, como la composición de ellos para obtener aplicaciones más complejas y de mayor valor. Esta tecnología está inmersa en el modelo de Arquitectura Orientada a Servicios (SOA por sus siglas en inglés), que se basa en la idea de encapsular la lógica de las aplicaciones dentro de servicios que interactúan mediante un protocolo de comunicación estándar. La comunicación entre servicios usa además el envío de mensajes en formato estándar [soa-erl], como lo muestra la figura 15, existe un intercambio de mensajes entre un proveedor y un cliente a través de un intermediario (servicio web) que sirve como punto de enlace entre las dos entidades. SOA Proveedor (Servidor) Información en General. BD, Archivos. Recibe Solicitud Envía Respuesta Intermediario (Web Services) Solicita servicio Recibe servicio Cliente App Java App.NET App B.D. Figura 15: Modelo de funcionamiento de SOA. La forma en que los servicios web realizan ésta comunicación entre aplicaciones no es nada sencilla ni trivial, aún cuando su flexibilidad permite manejar una variada lista de protocolos de red como FTP, HTTP, HTTPS, SMTP, etc. UPIICSA - IPN Página

74 Para cada servicio, ya sea en el gobierno o en aplicaciones empresariales, existe una definición formal del proceso que ellos encierran, que especifica la lógica del servicio. Éste sólo será exitoso si es coordinado apropiadamente. [ws-choreography] La coreografía de documentos [Eduardo René Rodríguez, Upiicsa, se refiere a la secuencia de intercambio de documentos y es la forma en como se responde a un documento recibido utilizando otro documento como respuesta. El documento incluye información acerca de los puntos terminales, esta información puede incluir: Las URLs a las que van dirigidos los mensajes que han sido enviados y, Las reglas del otro punto Terminal como los certificados digitales que serán usados para asegurar los mensajes. El proceso de intercambio de documentos puede darse de dos formas: a) De forma directa.- Envío del documento y la respuesta a éste, como otro documento o como confirmación de recepción (acuse de recibo). b) Como proceso de negociación: Se intercambia una serie de documentos en los que se solicitan productos o servicios y se responde con propuestas para cubrirlos hasta llegar a un acuerdo. Para asegurar el intercambio de documentos se deben asegurar garantías durante el proceso transaccional, estas garantías se asemejan mucho a las que se presentan para un mecanismo de seguridad de la información y son: Integridad, Autenticidad, Privacidad y No Repudio. La integridad asegura que los documentos no sufran alteración física del contenido durante el proceso de intercambio. La autenticidad garantiza que la identidad del remitente del documento sea determinada con precisión. La privacidad significa que los canales de comunicación por los cuales viajan los documentos, sean aislados de fuentes externas mediante protocolos de encripción de datos como SSL (Secure Socket Layer). El No Repudio, da certeza de que los participantes de una transacción no puedan negar el origen o existencia de un documento creado por ellos mismos. También es necesario que el modelo de intercambio de documentos establezca reglas y mecanismos a seguir para la resolución de problemas y condiciones de error que se presentan durante el proceso de intercambio. UPIICSA - IPN Página

75 Los errores que se pueden presentar pueden ser genéricamente de cuatro tipos: a) De transporte cuando el documento no alcanza el destino o bien se corrompe en el camino. b) En el documento, cuando el documento no coincide con las definiciones de DTD o en su esquema semántico que se definió para dicho documento. c) De procesamiento, cuando el documento no puede procesarse con éxito por problemas en el equipo que lo recibe, ya sea por hardware o software. d) De proceso de negocio, cuando semánticamente el documento es correcto pero no puede ser procesado por algún motivo del propio negocio (validaciones de negocio). La información de las reglas de negociación puede estar definida dentro de la misma especificación de los servicios web, por ejemplo dentro del archivo WSDL (Web Service Description Languages), la cual describe las reglas de comunicación y envió de mensajes entre uno y otro servicio. Si se desea lograr una automatización del proceso, se deben definir formas de comunicar y hacer interoperar las distintas dependencias del gobierno a manera de permitir el flujo de información (documentos) de una institución a otra. Este flujo se define por los mensajes intercambiados, estado del proceso, documentos y los agentes que manejan estos documentos. Esto representa lo que se conoce como un flujo documental entre entidades conocidas (es decir que tienen un protocolo de comunicación establecido entre ellas). La definición del flujo documental, es clave en la definición de los servicios web para el gobierno electrónico, ya que ella representa la médula espinal del proceso que se quiere modernizar mediante la incorporación de TICs en el gobierno. De esta manera, la definición y descripción del flujo de trabajo de los servicios web debe especificar completamente tales flujos documentales, para definir los protocolos a usar en el intercambio de documentos de una dependencia a otra. Hasta este punto es importante diferenciar entre un flujo de trabajo que define la forma y el orden en que se realizan los procesos, y el flujo documental que se refiere al intercambio de información en un formato explicito como puede ser un mensaje XML vía HTTP, FTP, SMTP, etcétera. UPIICSA - IPN Página

76 Por otra parte debemos entender otros conceptos que son importantes dentro de los temas relacionados a las tecnologías web utilizadas para el desarrollo de servicios web. Ahora podemos entonces definir que un recurso representa cualquier objeto que tiene una identidad. Algunos ejemplos de recursos son: servicios, agentes, documentos, imágenes, entre otros. Un recurso web por su parte, es un recurso identificado por una URI [glosario], al que se puede acceder mediante el protocolo HTTP [glosario]. Para describir todos estos recursos se usan metadatos, es decir, datos que describen datos, los cuales permiten estructurar la información, en particular los metadatos abarcan desde los primitivos tags o etiquetas intrínsecas de los recursos, hasta los metadatos de alto nivel que describen el contenido de otros datos para diferenciarlos de los demás. Dentro de los metadatos más primitivos están por ejemplo la sección del título de una página HTML, o la etiqueta para marcar el encabezado de un capítulo. Esta forma de marcado básica es fundamental para que cada recurso exista, pueda ser entendido y procesado. Por su parte los metadatos de alto nivel, surgen luego de que los metadatos más básicos ya han sido definidos y entregan una documentación y clasificación, la cuál permite no sólo especificar un recurso de mejor manera sino además diferenciarlo de los otros. Aplicaciones típicas de los metadatos de alto nivel son: uso para clasificaciones jerárquicas, definición de tesauros y taxonomías. En el campo de las Ciencias de la Información, un tesauro es una lista que contiene los "términos" empleados para representar los conceptos, temas o contenidos de los documentos, con miras a efectuar una normalización terminológica que permita mejorar el canal de acceso y comunicación entre los usuarios y las Unidades de Información (Entiéndase unidad de información como: biblioteca, archivo o centros de Documentación). Aunque en la práctica tradicional se habla de uniterminos, en la actualidad se han efectuado grandes variaciones dando incorporación a términos o descriptores compuestos, es decir, descriptores que se componen de dos o más palabras. UPIICSA - IPN Página

77 <html> <title> Metadatos de HTML </title> <form> El cuerpo de un documento HTML para ejemplificar el uso de etiquetas para describir datos </form> </html> Ejemplo del uso de etiquetas o metadatos, para describir datos de un documento HTML. De igual forma podemos ver el ejemplo de un documento XML: <persona> <nombre> Job </nombre> <apellido paterno>hernández</apellido paterno> <apellido materno>joffre</apellido materno> <edad> 26 </edad> </persona> Ejemplo del uso de etiquetas o metadatos, para describir datos de un documento en formato estándar de XML. UPIICSA - IPN Página

78 3.2 Definición de pautas. A continuación se presentan las definiciones necesarias para entender la manera en que funcionan las tecnologías utilizadas, primero se mencionan algunos principios básicos que rigen el desarrollo de servicios, se describen brevemente las tecnologías sobre servicios usando servicios web en el e-gobierno, y finalmente se explica la forma de atacar los problemas relacionados con la interacción aplicativa Definiciones y bases teóricas. Las siguientes definiciones representan los principios básicos de este trabajo y permitirán entender las acciones de comunicar, interoperar y automatizar los servicios para el Gobierno electrónico. Principios 1) Unidad de información: Una unidad o token de información para los servicios web en el e- Government, se define como un documento XML. 2) Descripciones: Las descripciones (metadatos, ontologías [glosario], propiedades, restricciones, protocolos, etc.) de los recursos en la web, se especifican mediante unidades de información (es decir, documentos con el formato de XML). 3) Comunicación: La comunicación entre sistemas heterogéneos en la web se hace mediante el intercambio de mensajes. Los mensajes corresponden a documentos XML, que contienen información y descripciones de los recursos. 4) Interoperabilidad y automatización: Para automatizar los servicios se requiere que ellos interoperen. Para interoperar, los sistemas se deben comunicar cumpliendo los protocolos y definiciones presentes en las descripciones de los recursos web en juego. Para abordar este cuarto principio especificado en las Definiciones y Bases Teóricas (interoperabilidad y automatización), se debe precisar que existen al menos 2 tipos de interacciones en el marco de los servicios web: máquina-máquina y persona-máquina. Interacción máquina- máquina: Este tipo de interacción se basa en la descripción de los recursos existentes en la web, de manera que ellos puedan ser invocados, relacionados y obtenidos de manera automática por algún sistema. Ejemplos de descripciones que se UPIICSA - IPN Página

79 ocupen de la interacción máquina-máquina son la definición de WSDL [wsdl], protocolos de comunicación, entre otros. Cabe recalcar que este tipo de interacción e interoperabilidad es posible gracias a XML, que entrega un formato estándar para el intercambio de información (documentos). Interacción persona- máquina: En el ámbito de los servicios web, las máquinas se pueden comunicar mediante la definición de protocolos de comunicación, identificadores únicos de recursos, etc. Sin embargo, estos parámetros resultan poco convenientes para las personas, por lo que se necesita una interfaz entre los mundos de personas y máquinas. Tal interfaz es posible gracias a descripciones que vienen dadas por ejemplo con aplicaciones como UDDI [uddi] o la clasificación de los servicios según taxonomías. Un claro ejemplo de esto es el diccionario de metadatos de AGLS [agls-35], que permite a los usuarios buscar, relacionar e invocar, los servicios disponibles gracias a las clasificaciones definidas. Otro concepto importante es una hoja blanca sobre el sito UDDI que utiliza la noción de las maquinas de búsqueda web para ayudar a entender lo que es UDDI. Las máquinas de búsqueda necesitan ser pobladas con URLs y con las palabras clave para permitir que se pueda buscar información cuando se visite una máquina de búsqueda en particular. El resultado de buscar en una máquina de búsqueda de sitios web es una lista de URLs. Algunas de estás pueden ser relevantes para lo que se está buscando, pero otras pueden no serlo. En una forma similar, los operadores UDDI (tales como Hewlett-Packard HP, IBM, SAP, y Microsoft) proveen de un sitio web para que un usuario registre su negocio, servicio, y direcciones de servicio. Se puede también tener aplicaciones registradas por si mismas a través del Protocolo de Acceso Simple a Objetos SOAP (Simple Object Access Protocol) mensajes SOAP / XML. IBM, SAP, HP, y Microsoft han lanzado un Registro de Negocios UDDI o UBR (UDDI Business Registry), el cual es una implementación de la especificación UDDI. También es importante mencionar que a pesar de que las pautas técnicas de esta tesis están orientadas a las descripciones para la interacción máquina-máquina, se considera la interacción persona-máquina. UPIICSA - IPN Página

80 3.2.2 Pautas de servicios web para el e-gobierno. Tomando como marco la escala de medición de madurez del gobierno electrónico que se presenta en la sección 2.1.1, como parte de esta tesis, se definen las llamadas pautas técnicas de servicios usando servicios web, orientadas a un Gobierno Electrónico Unificado (Pautas de ahora en adelante). Estas pautas definen los requerimientos de los servicios en el e-gobierno, presentan las ventajas del uso de la tecnología de servicios web en este contexto, muestran ejemplos mediante casos de éxito haciendo uso de servicios web y finalmente entregan descripciones y metadatos que permiten satisfacer los requerimientos de los servicios. Esto será la base para desarrollar los servicios web y hacer posible la interoperabilidad y automatización que se busca en pro de un gobierno electrónico unificado, llevando así a los servicios web hasta su máximo potencial. Las pautas son presentadas a lo largo de este trabajo, a través de ejemplos particulares, que exponen conceptos y necesidades del e-gobierno. En el capítulo 5, las pautas son estructuradas como la definición de una sugerencia para el desarrollo de servicios en el gobierno electrónico usando servicios web Bases usadas para definir pautas Para la definición de las pautas, primero se estudió conceptualmente el problema del e-gobierno, que incluye: motivación, requerimientos que se busca satisfacer, particularidades del problema comparado con otros, normativas, iniciativas nacionales e internacionales y la estrategia planificada para su desarrollo. Una vez comprendido el problema, se hizo un acercamiento a las necesidades concretas del e- Gobierno, acudiendo y estudiando a instituciones relacionadas con el gobierno y los servicios que ellas entregan. Algunas de las instituciones estudiadas fueron: Servicio de Administración Tributaria (SAT), Secretaria de Hacienda y Crédito Público (SHCP), Subsecretaria de Egresos, Oficialía Mayor, Secretaría de Desarrollo Social, Banco de México y Secretaria de Gobernación (SEGOB). UPIICSA - IPN Página

81 De estas instituciones se escogieron algunos casos de éxito con ejemplos muy particulares y acotados, para poder desarrollarlos a lo largo del trabajo. Paralelamente a lo anterior - luego de una familiarización con la tecnología de servicios web se estudió más a fondo tal tecnología desde el punto de vista de las descripciones, protocolos provistos, guías y especificaciones. Eso permitió conocer cómo era posible satisfacer las necesidades de los servicios del e-gobierno usando servicios web, así como las ventajas y limitantes de esta tecnología. Luego, progresivamente se desarrollaron los casos de éxito escogidos, describiendo formalmente sus aspectos, para lo cual se usaron metodologías y técnicas de desarrollo tomadas de la Ingeniería de Software y UML entre ellas. A medida que se desarrollaron los casos de éxito, se descubrieron problemas, patrones comunes y conceptos involucrados en la entrega de servicios y sus relaciones, lo que llevó a la definición del marco en que se encuentran los servicios en el e-gobierno y el contexto en que hacen su entrada los servicios web para solucionar el problema. El objetivo de presentar los casos de éxito, es el de impulsar el desarrollo de soluciones alternas a la compra de productos que muchas veces no cumplen con las expectativas creadas por los propios consultores. El desarrollar servicios web al interior de las dependencias es un aliciente a demostrar que no es necesario gastar grandes cantidades de dinero para actualizar la infraestructura actual de una organización, e impulsar a la vez la expansión de una infraestructura gubernamental que permita ofrecer mayores beneficios, mejores resultados, un mejor uso de los recursos del gobierno y sobre todo impulsar la imagen de las instituciones como organismos más transparentes y menos burocráticos. Para esto, lo único realmente necesario es que las autoridades tengan la disposición para apoyar el proyecto y permitir que la gente especializada en el negocio se involucre en el desarrollo de nuevas soluciones con tecnología innovadora. Si se logra hacer que todas las dependencias interactúen por lo menos con una aplicación en común, se podrá demostrar que es posible hacer una integración aplicativa de todo el Gobierno Federal. UPIICSA - IPN Página

82 3.3 Servicios Web Para desarrollar servicios para el e-gobierno efectivamente, se debe conocer la definición, estructura y finalidad de los servicios. Las siguientes secciones entregan una visión general de estas características y muestran el marco donde se insertan las pautas desde lo más general (flujo documental), hasta lo más particular (requerimientos e implementación de los servicios) Flujo Documental Un flujo de trabajo es la automatización de un proceso de negocio en parte o su totalidad, durante el cual, los documentos, la información y tareas, son pasados de un participante a otro, siguiendo un conjunto predefinido de reglas [workflow-e-gov]. Dentro del flujo de trabajo, es necesario definir un flujo documental que deberá especificar las reglas para el intercambio de unidades de información (documentos XML), estos documentos que contienen metadatos, deben estar respaldados por un esquema o plantilla que defina las propiedades de dichos documentos y las particularidades de cada uno de las unidades a transmitir. En Ingeniería de Software, se dice que un proceso de negocio es un conjunto de una o más tareas interconectadas, las cuales colectivamente realizan o cumplen un objetivo de negocio, normalmente dentro del contexto de una estructura organizacional que define roles funcionales y sus relaciones [Shari Lawrence Pfleeger, Ingeniería de Software teoría y práctica]. La importancia que tiene el concepto de flujo documental para este trabajo, es que al modelar la lógica de negocio (documentos, tareas, flujos de información y responsables), se obtiene una definición formal de los procedimientos o trámites que forman la organización. Esta definición formal de los trámites permitirá hacer vistas del procedimiento existente y entregar servicios que creen, actualicen, modifiquen o lean instancias de estos procesos. UPIICSA - IPN Página

83 Por ejemplo, dado el flujo documental de las declaraciones del Servicio de Administración Tributaria (SAT), sería posible hacer una vista sobre tal flujo que entregará todas aquellas incidencias que cumplen con estar en un estado al corriente. De esas incidencias, se puede conocer una lista de los contribuyentes que están al corriente en sus pagos y declaraciones, lo que permitiría entregar un servicio de certificado de contribuyente cumplido invocado, por ejemplo, por el Buró de Crédito o la Comisión Nacional Bancaria y de Valores, para el otorgamiento de créditos y financiamientos tanto a personas físicas como morales Servicios Un servicio se define como un recurso que provee valor regularmente intangible (por ejemplo la información) al cliente del servicio. Más específicamente, un servicio es un recurso abstracto que representa la capacidad de ejecutar tareas que representan una funcionalidad coherente desde el punto de vista de quienes proveen y solicitan el servicio. Para poder ser usado, un servicio debe ser entregado por un proveedor de servicios [ws-arch]. Otra característica clave de los servicios, es que ellos representan una funcionalidad bien definida, que es autocontenida y que no depende del contexto o estado de otros servicios. Para el caso de los ciudadanos, los servicios en el e-gobierno representan una vista del mundo más directa, relacionada con la manera sobre como interactuar con el gobierno. Es por ello, que esta vista debe ser abstraída del proceso interno o implementación [describingservices-nzgls]. Tal como un servicio puede ser abstraído como una vista de un flujo documental, éste también puede ser abstraído como una vista lógica de aplicaciones, bases de datos, entre otras. De esta manera, un servicio está definido según lo que hace, típicamente llevando consigo una operación a nivel de la lógica del negocio. Como se mencionó anteriormente, un servicio es un recurso que representa la capacidad de ejecutar una tarea, pero los servicios pensados por si solos como una funcionalidad entregada, no son suficientes. Para aplicaciones que usan a los servicios como recursos, se necesita además de descripciones, metadatos, ontologías y definiciones para encontrarlos, clasificarlos, compararlos y componerlos. UPIICSA - IPN Página

84 Por el mismo razonamiento, pero pensando en la lógica del servicio se deben describir cada uno de los componentes del servicio (mensajes, agentes, documentos) y la interfaz con que se le conoce (operaciones y semántica del servicio). Se resalta que para el caso de las Arquitecturas Orientadas a Servicios que se basan en el uso de servicios, las descripciones de éstos también resultan ser clave (ver sección 3.4). Una forma particular de implementar servicios para el e-government, es el uso de la tecnología de servicios web, que basada en estándares de la web promete entregar una alta interoperabilidad y flexibilidad para desarrollar servicios. En la sección 3.6 (Tecnologías en servicios web) se analiza en detalle la tecnología, sus ventajas y, por supuesto, las descripciones que son necesarias para la implementación de servicios. 3.4 Arquitectura Orientada a Servicios (SOA) Una Arquitectura Orientada a Servicios (SOA por sus siglas en inglés), es una forma de arquitectura de sistemas distribuidos, que define el uso de servicios para satisfacer los requerimientos de agentes. Una SOA se caracteriza por cumplir con las siguientes propiedades [wsarch]: Vista lógica: Los servicios son una vista lógica de aplicaciones, bases de datos, u otros, definidos con base en lo que hacen, típicamente llevando consigo una operación a nivel de la lógica de negocio. Orientada a mensajes: La definición formal de un servicio, se hace en base a los mensajes que intercambian los agentes proveedores y consumidores. Orientado a descripciones: Un servicio es descrito por sus metadatos procesables automáticamente. En la descripción sólo la información importante para usar el servicio debe ser incluida. Granularidad: Los servicios tienden a usar pocas operaciones, con mensajes complejos y largos (esto no es obligatorio) Orientado a redes: Los servicios tienden a ser orientados para ser usados en la red. Independencia de las plataformas: Los mensajes enviados y recibidos se encuentran en formato estándar (XML es el ejemplo más claro). UPIICSA - IPN Página

85 3.5 Requerimientos de los servicios en el e-gobierno Qué deberían cumplir los servicios desarrollados en el e-gobierno? A continuación se abordan los requerimientos mínimos que deberían cumplir los servicios en el e- Gobierno. Esto se basa en los aspectos mencionados en el capítulo 2 Organizaciones, e-gobierno y sus experiencias, además de la naturaleza de los servicios que son la cara visible del gobierno. El problema no consta sólo en entregar servicios sino en resolver como deben ser construidos y definidos de mejor manera, como hacerlos interoperar, como administrar y gestionar un gran número de servicios, como definir, reutilizar y modularizar componentes, tipos de datos, documentos y esquemas. Como abordar temas de privacidad en una dependencia o entre dependencias, entre otros. A continuación se lista un conjunto de requerimientos sobre el desarrollo de servicios para el e- Gobierno que corresponden a las necesidades identificadas que debería satisfacer una solución al respecto. Automatización de Servicios (automatizar el proceso) Para que los servicios web sean automatizados se debe entregar una mayor expresividad y significado a los metadatos que los describen mediante el uso de ontologías, definición de conceptos, restricciones, propiedades y relaciones para describir un área de conocimiento y realizar inferencias, facilitando así la automatización [herman-ws]. Es por ello, que para el caso de los servicios web, existen lenguajes como DAML-S [daml] y OWL-S [owl-s], que permiten definir ontologías para los servicios. Interoperabilidad La interoperabilidad resulta clave para la composición, invocación y automatización de los servicios, debido a la heterogeneidad existente de plataformas, sistemas y aplicaciones. Para hablar de una interoperabilidad completa y efectiva, se hace necesaria la definición de un framework 11 de Interoperabilidad. 11 La definición de framework(marco de trabajo) usada aquí es: Estructura extensible para describir conceptos, tecnologías y métodos necesarios para los procesos de diseño y construcción de un producto. UPIICSA - IPN Página

86 Este framework se define como el conjunto de estándares, guías de trabajo y protocolos que describen la forma en que los sistemas han acordado(o deberían acordar) interactuar entre sí. [e-gif]. Algunos de los tipos de Interoperabilidad más relevantes se definen a continuación, de los cuales la organizacional, semántica y técnica están basadas en [e-gif]: Interoperabilidad organizacional: Esta interoperabilidad tiene que ver con la definición del negocio y procesos que lo hacen posible, donde las organizaciones que tienen diferentes definiciones y estructuras de negocio, requieren interactuar. Interoperabilidad semántica: Se ocupa de que el significado y el manejo que se le da a la información entre las distintas partes, sea consistente, preciso y bien definido, mediante el uso de esquemas, modelos de datos o clases. La interoperabilidad semántica puede ser analizada a nivel de interacción máquina-máquina o persona-máquina. Interoperabilidad técnica: Este tipo de interoperabilidad tiene relación con las definiciones técnicas que permiten comunicar sistemas computacionales a nivel de redes, middleware, datos, seguridad, entre otras. Esta interoperabilidad es posible gracias a la posibilidad de intercambio de información de manera estándar que provee XML. Interoperabilidad política: Se refiere a la voluntad política de apoyo a la interacción entre las partes, como forma de obtener mayor provecho para cada una de ellas. Interoperabilidad legal: La factibilidad de ciertos tipos de interacciones tecnológicas, organizacionales, entre otras, se ven impedidas o limitadas por acuerdos o definiciones legales. Por este motivo se debe tener especial cuidado con la Interoperabilidad legal donde por ejemplo, la utilización de ciertos estándares de seguridad a nivel técnico pueden ser obligatorios o restringidos por la ley, dependiendo de las leyes que se establecen sobre todo para los documentos rubricados o firmados digitalmente. Todo esto muestra que ciertos tipos de interoperabilidad deben ser resueltos, o al menos identificados antes que otros. Esta tesis se enfoca en la Interoperabilidad de carácter técnico y semántico, sin embargo, también se recalca la gran importancia de considerar los otros tipos de interoperabilidad. UPIICSA - IPN Página

87 Definición previa de servicios y sus operaciones Una de las primeras preguntas que se debe hacer para comenzar con la definición de servicios, es el análisis sobre qué servicios entregan un mayor impacto y valor a las dependencias y ciudadanos? En este proceso se debe analizar la complejidad del servicio, frecuencia de uso, dependencia de otros servicios y/o dependencias. A pesar de que la definición de un workflow, donde se especifique formalmente todo el proceso en una dependencia o secretaría sería ideal, existen casos donde ello no es posible ni óptimo. Es el caso de Municipios de escasos recursos donde resulta de mayor utilidad tener un servicio particular, que invertir tiempo y dinero definiendo todo el proceso. Una definición previa de los servicios, permitirá invocar y componer servicios, además de procesar e inferir sobre sus descripciones. Todo esto ayudará a una verdadera automatización de los procesos. Una definición más exhaustiva sobre una propuesta para desarrollar servicios, se presenta en los capítulos 4 y 5. Permitir descubrimiento, consulta e invocación Para el caso en que se cuente con un gran número de servicios disponibles a lo largo de las distintas dependencias del Gobierno, surge la necesidad de buscar servicios más convenientes. Esta búsqueda sería al menos por parte de: El Ciudadano (usuario) que realiza trámites y requiere saber dónde? y cómo? usar los servicios finales disponibles, ya sea a través de una ventanilla única adaptada a sus necesidades particulares, o a través del sitio web de alguna dependencia de gobierno (organización). Empresas u otras dependencias de gobierno que necesitan buscar servicios finales, intermedios o básicos comunes (por ejemplo validación del RFC de una persona). Este descubrimiento requiere mucho más que metadatos que indiquen algunas clasificaciones del servicio, según la dependencia que lo entrega o dentro de que área de negocios se encuentra. Si se busca una automatización real, se deben definir formalmente las capacidades y restricciones de los servicios, su semántica, funcionalidad, metadatos que permitan conocer quien es el responsable de él y como debe ser llamado. UPIICSA - IPN Página

88 Definiciones como éstas, permitirán inferencias más avanzadas que las actuales, como analizar qué servicios se pueden componer con otros, cuales de los servicios existentes cumplen mejor una política de privacidad o estándares de seguridad, entre otros. Administración de descripciones Como se ha mencionado, la descripción de los recursos permite recuperarlos, relacionarlos e inferir nuevas definiciones. Algunas de estas descripciones son la definición de capacidades de un recurso o la clasificación según alguna taxonomía. Para el manejo de descripciones con volúmenes de información como los que maneja el gobierno, se debe contar con herramientas que permitan: la creación, almacenamiento, consulta, asignación (relacionar objetos) y administración de descripciones y recursos. Estas herramientas van desde el rango de editores de documentos que permitan visualizar, firmar y validar documentos, hasta las que permitan administrar los esquemas de los documentos de gobierno, para evitar duplicidad o incompatibilidad de definiciones y permitir reutilización, así como mecanismos de cifrado (encriptación) y firma electrónica, para asegurar la autenticidad de la información [agls-35]. Administración y gestión de Servicios Una vez que los servicios han sido desarrollados y pueden ser invocados por los clientes, surge la necesidad de responder a preguntas como: cuál es la frecuencia con que se usa?, quién lo utiliza? o cuál es el desempeño del servicio? Por ejemplo, algunas preguntas interesantes de responder pueden ser: cuál es el precio promedio del servicio de renovación de pasaportes o licencias?, saber si existe un servicio que permita validar un domicilio o conocer la variación porcentual en el uso del servicio de la declaración de impuestos en línea, o bien que pudiera existir un servicio que agilice el tramite para la jubilación de los trabajadores del estado. Tal como se ha mencionado, para ello se requieren herramientas acordes que basadas en las descripciones de los servicios y en los resultados de su funcionamiento permitan: recolectar información para tomar decisiones de futuros desarrollos, crear o modificar la definición de los servicios, medir el nivel de madurez de los servicios entregados y evaluar el impacto de los servicios. UPIICSA - IPN Página

89 Mecanismos de autenticación El acceso a los servicios en línea plantea el desafío de asegurar un acceso confiable y seguro para dependencias, empresas y ciudadanos. Mantener la privacidad de la información de los usuarios y asegurar la identidad de quien realiza la operación, son temas que requieren de la definición de un mecanismo de autenticación (firma electrónica y cifrado de la información). La complejidad de este mecanismo dependerá del tipo de operaciones a realizar y éste debería ser acorde con la posibilidad de usar la autenticación y delegación de permisos, o Single Sign On (SSO) u otros mecanismos. La validez y los límites legales de los mecanismos de autentificación también deben ser abordados. Escalabilidad y extensibilidad La definición de servicios debe permitir extender los dominios de aplicación existentes ya sea en el ámbito del negocio, en temas de seguridad o metadatos. Es por ello que la extensibilidad de las especificaciones que definen estos aspectos resulta clave. Además se debe permitir la inclusión de definiciones en nuevos ámbitos que aparezcan según sea necesario. Además de lo anterior, se debe permitir escalabilidad en el número de recursos e invocaciones, descripción de recursos y complejidad de los servicios [wsa-req]. Para ello se deben utilizar las herramientas correspondientes que permitan administrarlos de manera adecuada (editores XML, administradores de metadatos, visualización de workflow). Seguridad La entrega de servicios involucra la interacción entre agentes de distintas dependencias y el intercambio de mensajes con información. Para que tal interacción ocurra en un ambiente seguro se necesita que cierta información sea tratada en forma confidencial, que se pueda asegurar la integridad de los datos durante su transmisión, que se deba autenticar la identidad de agentes, que se definan roles y el acceso a recursos. La seguridad no sólo abarca temas de transmisión de información sino también políticas, respaldo físico de datos, definición de medidas de contingencia, entre otras. Debido al enfoque de este documento se hará hincapié sólo en lo correspondiente a seguridad en servicios web y los estándares y definiciones existentes, que entregan soluciones a algunos de estos problemas. UPIICSA - IPN Página

90 Plataforma, arquitectura y componentes Para entregar servicios que forman parte de una sola dependencia como aquellos que requieren interactuar con agentes de otras dependencias, se debe contar con una plataforma y arquitectura que soporte las soluciones entregadas por los servicios, que puedan leer las definiciones y especificaciones definidas y basadas en ella permitan el funcionamiento de la lógica del servicio. Por ejemplo, dada la definición de permisos de acceso a recursos, la identidad y política de privacidad de un cliente, tal arquitectura debería decidir si un usuario puede acceder a un recurso. Además debe encargarse de temas como la transmisión de mensajes, asegurar su entrega, definir colas de mensajes, etc. También deben especificarse que componentes existirán como parte de la arquitectura, como workflow, repositorio de permisos, autenticación u otros y cuales serán sus dependencias y relaciones. La plataforma que sea definida puede ser común a varias dependencias (asociando por sectores a las dependencias del gobierno) o particular a alguna de ellas. Temas de escalabilidad, reutilización, disponibilidad, seguridad y complejidad, son algunos de los factores a considerar para analizar que alternativa es más eficiente y eficaz Particularidades de los servicios en el e-gobierno. Qué diferencía los servicios del Gobierno con los de una empresa cualquiera? Tal como se mencionó, el concepto del e-gobierno fue definido como: una forma de describir el quehacer del gobierno, apoyado por las nuevas tecnologías de información y comunicación (TIC), a fin de cumplir con sus funciones eficiente y efectivamente. A priori, esta definición no hace referencia a ninguna particularidad que pudieran tener las necesidades del gobierno, lo que lleva a cuestionar la verdadera necesidad del estudio y trabajo sobre el e-gobierno como tal. Primero hay que aclarar que el nacimiento del e-gobierno nunca supuso el uso de nuevas y revolucionarias tecnologías que fueran de uso exclusivo de éste, o que no se pudiera reutilizar todo el conocimiento en desarrollo de servicios, aplicaciones y modelado de información obtenido en otras áreas para usarlo en el gobierno. UPIICSA - IPN Página

91 Por el contrario, para cumplir efectiva y eficientemente con el quehacer del gobierno que resulta de una administración de recursos, entrega de servicios de alta complejidad y manejo de grandes volúmenes de información, se requiere reutilizar lo mejor del conocimiento actual. Aclarado este punto la pregunta anterior sigue en pie, Qué diferencía a los servicios y necesidades del e-gobierno con los de una empresa cualquiera? Como primer punto, el enfoque social que tiene el gobierno comparado con el interés privado que apunta hacia lo económico, define estrategias de desarrollo, prioridades y valores a los proyectos, de una manera absolutamente distinta. De aquí, por ejemplo, el gobierno puede priorizar un proyecto que implique beneficiar a un gran número de ciudadanos, para lo cual necesitará un gran poder en infraestructura y alta complejidad de desarrollo, pero no involucrará grandes ganancias económicas. Por otro lado, una empresa podría preferir un proyecto de bajo impacto en el número de usuarios pero de alto valor por los montos en juego y el respectivo beneficio económico. Sin embargo, se podría argumentar que estos no son requerimientos técnicamente distintos, por lo cual la pregunta inicial podría convertirse en la siguiente: Qué diferencias técnicas existen entre los servicios del gobierno y empresas cualesquiera, que hace necesario su estudio y no permiten simplemente replicar las soluciones existentes? Primero se puede decir que el volumen de documentos, transacciones e interacciones que maneja el gobierno es mucho mayor al de las empresas. No obstante, se puede argumentar que siempre es posible hallar una empresa lo suficientemente grande para que esto resulte comparable. Por último, cabe recalcar que dadas las realidades de cada gobierno en particular y los puntos anteriormente planteados, aún no existe evidencia que demuestre si todas las instituciones que forman parte del gobierno serán capaces de entregar los servicios que se requiere, si será mejor entregar autonomía de definición de servicios a cada institución, entre otros temas. Es por ello que el estudio y análisis de la problemática del e-gobierno resulta necesaria y fundamental. El poder ofrecer a la población un portal que permita el acceso a la mayor parte de los servicios a través de la web, es el principal objetivo de una arquitectura diseñada y basada en el uso de tecnologías abiertas 12, que permitan la comunicación entre dependencias y organismos públicos y privados para mejorar la calidad de vida de los ciudadanos 12 Este punto además hace notar la utilidad de la tecnología de Servicios Web para solucionar el problema. UPIICSA - IPN Página

92 Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican. Una posible definición, sería hablar de ellos como un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí (mensajes) con el objetivo de ofrecer servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web [fuente: W3C Los servicios web pueden realizar operaciones por si mismos, e incorporar otros servicios web (composición de servicios). Esto permite completar y automatizar transacciones complejas y de alto nivel. [frez-ws-admin]. Los servicios web son por definición recursos web [ws-arch], y como tales están identificados por una URI (Uniform Resource Identifier, identificador uniforme de recurso, definido en RFC 2396). Una URI es una cadena corta de caracteres que identifica inequívocamente un recurso (servicio, página, documento, dirección de correo electrónico, enciclopedia, etc). Normalmente estos recursos son accesibles en una red o sistema, son alcanzables usando los protocolos de la web y además tienen el potencial de contar con descripciones (metadatos), para encontrarlos, clasificarlos, compararlos, componerlos e inferir propiedades sobre ellos. Como se mencionó en el capítulo 2, el gobierno electrónico tiene la necesidad de entregar servicios (recursos) independientes del tipo de interacción, lo que convierte a los servicios web en un excelente candidato debido a su naturaleza de recurso web, que lo hace independiente del contexto que lo rodea. 3.6 Tecnologías en Servicios Web Los servicios web están definidos, esencialmente por tres tecnologías, construidas sobre los protocolos y estándares de la Web Extensible Markup Language (XML) XML (extensible Markup Langauge, Lenguaje de Etiquetado Extensible) es un lenguaje de etiquetado muy simple pero a la vez muy estricto, juega un papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje muy similar a HTML pero su función principal es UPIICSA - IPN Página

93 describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de datos a través de diferentes aplicaciones. Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más frecuentes por parte de los usuarios. XML sirve para estructurar, almacenar e intercambiar información [fuente: W3C, Entre las tecnologías XML disponibles se pueden destacar: XSL (extensible Stylesheet Language): Lenguaje Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar cómo debería estar estructurado el contenido, cómo debería ser diseñado el contenido de origen y cómo debería ser paginado en un medio de presentación como puede ser una ventana de un navegador web o un dispositivo móvil, o un conjunto de páginas de un catálogo, informe o libro. Xpath (XML Path): Lenguaje de Rutas XML, es un lenguaje para acceder a partes de un documento XML. XLink (XML Link): Lenguaje de Enlace XML, es un lenguaje que permite insertar elementos en documentos XML para crear enlaces entre recursos XML. XPointer(XML Pointer): Lenguaje de Direccionamiento XML, es un lenguaje que permite el acceso a la estructura interna de un documento XML, esto es, a sus elementos, atributos y contenido. XQL (XML Query Language): Lenguaje de Consulta XML, es un lenguaje que facilita la extracción de datos desde documentos XML. Ofrece la posibilidad de realizar consultas flexibles para extraer datos de documentos XML en la Web. <?xml version="1.0" encoding="iso "?> <libro> <titulo></titulo> <capitulo> <titulo></titulo> <seccion> <titulo></titulo> </seccion> </capitulo> </libro> Ejemplo de un documento XML UPIICSA - IPN Página

94 3.6.2 Simple Object Access Protocol (SOAP) SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos en formato XML. SOAP fue creado por Microsoft, IBM y otros corporativos, está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en el desarrollo de servicios web. SOAP entrega una definición basada en el estándar XML, que permite intercambiar información estructurada (metadatos) entre distintos puntos de la red en un ambiente distribuido descentralizado. Especificaciones que extienden de SOAP, permiten hacerse cargo de aspectos como: correlación de mensajes o envío de mensajes a través de nodos intermediarios (proxy, firewall), [fuente W3C SOAP v 1.2, Después de que algún usuario ha buscado la descripción WSDL (Web Service Description Language) de un servicio web en la red utilizando UDDI (Universal Description, Discovery, and Integration), este puede llamar a una o más operaciones en su servicio web usando SOAP. SOAP es un protocolo basado en texto que utiliza el formato de codificación de datos de XML y de los protocolos HTTP/SMTP para transportar mensajes. SOAP es independiente del lenguaje de programación usado y/o de la plataforma sobre la cual está corriendo la aplicación. XML es crucial para el intercambio de mensajes de información porque es un lenguaje de marcado de texto fácil de extender, tiene un soporte considerable en la industria y es bien sabido que es un lenguaje utilizado para la descripción de metadatos. El uso de HTTP (y otros como SMTP, FTP y HTTPS) como protocolo de transporte permite la navegación a través de firewalls usando el puerto 80. HTTP es también el protocolo de transporte más común y más usado en Internet. SOAP ha sido ampliamente aceptado por los más grandes vendedores de plataformas (plataform vendors) de los negocios electrónicos (ebusiness). El estándar SOAP es ahora administrado por W3C y la especificación en su versión 1.2 consiste de dos partes y una premisa (primer): o Parte 0: Premisa (Primer)- Proveer un tutorial sobre las características de SOAP. o Parte 1: Marco de Mensajes (Message Framework) - Describe la envoltura de SOAP y el marco de la capa (binding) de transporte. o Parte 2: Adjuntos: Describe adjuntos para la envoltura y marco de encapsulamiento (envelope and binding framework). UPIICSA - IPN Página

95 3.6.3 Web Services Description Language (WSDL) El Lenguaje de de un Servicio Web (WSDL), es una especificación basada en el estándar XML, pensada para describir servicios disponibles, y los mensajes que ellos utilizan para comunicarse a través de un conjunto de nodos en la red. [fuente:w3c, WSDL, Para que un negocio descubra un servicio y pueda usarlo, el software de servicio web necesita entender la sintaxis de la llamada y la estructura semántica, esto para poder realizar una llamada y descubrir los servicios disponibles. La especificación del lenguaje de descripción de un servicio web define a WSDL con un formato XML para describir servicios de red como un conjunto de puntos terminales que operan sobre mensajes que contienen documentación ya sea orientada a documento (document-oriented) u orientada a procedimiento (procedure-oriented). WSDL complementa a UDDI proporcionando una manera uniforme de describir las capas de interfase y de protocolo de los servicios web. La especificación WSDL también describe los siguientes elementos que un documento WSDL utiliza en la definición de servicios de red: o o o o o o o Tipos (Types) Un contenedor para las definiciones de tipos de datos que utiliza un tipo de sistema (como puede ser XSD). Mensaje (Message) Una abstracción, definición tipeada (tipo) de los datos que están siendo comunicados. Operación (Operation) - Una descripción abstracta de una acción soportada por el servicio. Tipo de Puerto (Port Type) - Un juego abstracto de operaciones soportadas por uno o más puntos terminales. Enlazado (Binding) - Un protocolo concreto y especificación para el formato de datos para un tipo de puerto en particular. Puerto (Port) Un punto Terminal aislado que está definido como una combinación de una capa y una dirección de red. Servicio (Service) Una colección de puntos terminales relacionados. UPIICSA - IPN Página

96 Figura 16. Tecnologías en Servicios Web. Figura tomada de W3C [web-design, A pesar de que se puede considerar a los formularios web o script CGI, como servicios web, en este documento, el término servicio web es usado para referirse a aquellas aplicaciones que usan al menos las tecnologías XML, SOAP y WSDL. Existe una amplia lista de tecnologías que complementan a XML, SOAP y WSDL, según el dominio y necesidades de las aplicaciones. Entre tales tecnologías están: tecnologías de seguridad, de definición de transacciones y de entrega confiable. Las tecnologías base más sus complementos, definen el modelo de capas levemente acoplado de los servicios web, que se muestra en la Figura 16. Este modelo de capas, resulta altamente extensible debido a la propia extensibilidad de las tecnologías bases que lo conforman, y por ello permite la definición de nuevas tecnologías de capas de más alto nivel, que especifiquen temas como coordinación de servicios, reglas de negocio particulares a algún dominio, seguridad y administración de servicios Universal Description, Discovery and Integration UDDI. La, Descubrimiento e Integración Universal UDDI (Universal Description, Discovery, and Integration) es una especificación que permite a los proveedores registrar sus servicios web y a los requisitantes encontrar los servicios web disponibles en la red y necesarios para satisfacer sus requerimientos. La especificación y varias páginas sobre el estándar UDDI están disponibles en el sitio web UPIICSA - IPN Página

97 Una forma de entender como funciona UDDI es haciendo uso del concepto de máquinas de búsqueda. Las máquinas de búsqueda necesitan ser pobladas con URLs (Uniform Resource Identifier - Identificador Uniforme de Recurso) y con las palabras clave para permitir que se pueda buscar información cuando se visite una máquina de búsqueda en particular. El resultado de buscar en una máquina de este tipo, es una lista de URLs. Algunas de estás pueden ser relevantes para lo que se está buscando, pero otras pueden no serlo. En una forma similar, los operadores de UDDI (tales como Hewlett-Packard HP, IBM, SAP y Microsoft) proveen de un sitio web para que un usuario registre su negocio, servicio y direcciones de servicio. Se puede también tener aplicaciones registradas por si mismas a través del Protocolo de Acceso Simple a Objetos SOAP (Simple Object Access Protocol), mensajes SOAP / XML. IBM, SAP, HP, y Microsoft han lanzado un Registro de Negocios UDDI o UBR (UDDI Business Registry), el cual es una implementación de la especificación UDDI. UDDI dirige los sistemas buscando servicios confiables para la documentación que describe esos servicios web. Soporta el estándar de búsqueda de páginas blancas de negocio, páginas amarillas para búsqueda por tema y páginas verdes para la búsqueda de tipos de servicio, es decir, las páginas verdes de búsqueda que permiten a un desarrollador encontrar los servicios que coinciden con un tipo de servicio en particular. Los clientes que acceden a un registro UDDI para localizar o buscar información o servicios también utilizan mensajería SOAP (típicamente XML/HTTP). No obstante en la literatura se ha difundido la Universal Description Discovery and Integration Standard (UDDI) como parte de la tecnología de servicios web, aunque ésta no pertenece al núcleo esencial de los servicios web sino que más bien resulta ser una aplicación que permite la descripción y búsqueda de los servicios disponibles. Por este motivo UDDI no es tratado aquí a detalle ya que no representa parte esencial como componente de la tecnología pero podría implementarse como una solución más robusta para la interacción entre aplicaciones de organizaciones públicas y privadas o cualquier combinación de ellas. Es clave resaltar que las descripciones resultantes de los servicios web formadas por las capas bases y las de más alto nivel, dependen del modelo arquitectónico usado para observar la realidad [ws-design, Es por ello, que a continuación se presentan los modelos arquitectónicos más relevantes. UPIICSA - IPN Página

98 3.7 Modelos arquitectónicos Existen varios modelos que permiten representar la arquitectura que involucran los servicios web, es decir: sus componentes o conceptos, y las relaciones que hay entre ellos, desde distintos puntos de vista, para así explicar un tema importante [ws-design][ws-arch]. Los 2 modelos arquitectónicos más importantes propuestos por la W3C son [ws-arch, Modelo Orientado a Mensajes (MOM): Este modelo se enfoca en los mensajes intercambiados entre los distintos agentes en la web y su procesamiento. El MOM se ocupa de describir la estructura y transporte de mensajes sin definir el significado ni la razón de por que están siendo enviados mensajes. Figura 17: Modelo arquitectónico orientado a mensajes. Figura tomada de [ws-design, UPIICSA - IPN Página

99 Los diagramas definidos con una simbología estándar y universal se pueden considerar como un modelo [ws-design, los conceptos y relaciones claves en este modelo (ver Figura 17) incluyen los mensajes y su estructura, los agentes que los envían y procesan, la dirección donde se encuentran destinatario y recipiente, la correlación de los mensajes, la forma de transportar tales mensajes, entre otros. Modelo Orientado a Servicios (SOM): Este modelo se enfoca en el servicio entregado por un agente proveedor hacia uno que lo solicita y se compone de un conjunto de acciones a realizar para cumplir con tal servicio. A pesar que el SOM se basa en el MOM, el modelo orientado a servicios se ocupa primordialmente de las acciones que involucra el servicio y no de los mensajes intercambiados. Figura 18: Modelo arquitectónico orientado a servicios. Figura tomada de [ws-design, UPIICSA - IPN Página

100 Los conceptos y relaciones claves en este modelo (ver Figura 18) son que el servicio es realizado por un agente y usado por otro, los servicios son llevados a cabo gracias al intercambio de mensajes entre agentes y a que la semántica de los servicios y las interfaces que éstos proveen son definidas con metadatos. El modelo orientado a servicios es el más complejo de todos y se debe a que modela casi completamente el mundo real, esto es: La definición de la semántica de los servicios, la pertenencia de los servicios a propietarios, los mensajes intercambiados, la definición de tareas y acciones junto con su objetivo asociado. 3.8 Arquitectura de Servicios Web como descripción de servicios La arquitectura de referencia entregada por la W3C [ws-arch, /], identifica los componentes funcionales (mensajes, servicios, agentes), define las relaciones entre ellas y establece un conjunto de restricciones sobre los componentes y sus relaciones. Según Tim Berners Lee [ws-design, el trabajo referente a esta arquitectura de servicios web puede ser dividido en dos partes: la descripción de servicios y los protocolos de ejecución de los servicios. El énfasis de este trabajo está en la descripción de servicios. La descripción de los servicios viene detallada por el modelo orientado a servicios (SOM) junto con el modelo orientado a mensajes (MOM), los cuales permiten definir los agentes participantes, la descripción del servicio, la estructura de mensajes, entre otros. La gran importancia que tiene la descripción de los servicios queda descrita por SOA (ver sección 3.4). Es por ello que resultan útiles algunas consideraciones sobre la descripción de los servicios web y por supuesto, de todos los recursos web: Existen metadatos que son intrínsecos y otros extrínsecos a los recursos. Por ejemplo los documentos cuentan con una estructura de capítulos, secciones y párrafo, que forma parte de los metadatos propios del recurso. También existen otros metadatos tales como fecha de creación, autores y clasificación relacionados al recurso que no son indispensables para comprender su contenido. De esta manera dependiendo de la naturaleza y uso de los recursos, puede convenir incrustar los UPIICSA - IPN Página

101 metadatos como parte de los recursos o manejarlos por separado. Si se decide incrustar los metadatos hay que notar que no todos los recursos aceptan metadatos incrustados, que puede resultar difícil administrar las actualizaciones de metadatos sobre los recursos. Por su parte los metadatos extrínsecos entregan más flexibilidad de mantenimiento y edición, resultan cómodos de administrar sobre todo si los recursos son de gran tamaño (videos, imágenes, expedientes) ya que los metadatos usan poco espacio en general, pero esto requiere tener depósitos o herramientas distintas para manejar recursos y otra para metadatos [metadata-guide, ]. Debido a que la descripción de recursos no sólo entrega herramientas a los ciudadanos para entender e interactuar con el gobierno, sino que también al mismo gobierno para analizar y gestionar su actividad, se deben definir metadatos que consideren la información administrativa que se requiere sobre los recursos. Esto permitirá contestar preguntas que ayuden a mejorar la gestión de las funciones gubernamentales, lo cual resulta ser uno de los principios bases del e-gobierno. 3.9 Guías para el uso de servicios web en servicios Hasta aquí, este trabajo ha expuesto las necesidades de contar con servicios que permitan la interacción entre dependencias para agilizar el desempeño de las actividades del gobierno y organizaciones privadas (e-gobierno), las formas en que se organiza su quehacer y la visión abstracta del mundo para ciudadanos, empresas y otras dependencias de este quehacer, que resultan ser los servicios. Estos servicios los entregan los proveedores (dependencias de gobierno o empresas) basándose en aplicaciones, bases de datos o flujos documentales y procesos de información bien definidos. En este capítulo, se ha presentado una breve mirada sobre lo que es la tecnología de servicios web. Ellos entregan una forma de implementar los servicios y en el resto del trabajo se presentan algunas razones, guías, ejemplos, de por qué esta tecnología resulta adecuada para las necesidades de INTEGRACIÓN DE APLICACIONES ORGANIZACIONALES por sobre otras tecnologías, en qué circunstancias es más conveniente de utilizar y qué problemas o desventajas puede traer consigo su uso. A pesar de que existen otras tecnologías para computación distribuida, que permiten la comunicación de sistemas en la red, tales como CORBA, COM+ o Java RMI, en comparación con UPIICSA - IPN Página

102 los servicios web ellas resultan limitadas, más caras o menos flexibles [orth-ws-framework, Günter, Orth. The Web Services Framework]. Algunos de los problemas de tales tecnologías (CORBA, COM+, Java RMI) son: Su alta complejidad y alta inversión necesaria en arquitectura, licencias y soporte. Su funcionalidad está limitada a ciertos tipos de plataforma, lo que dificulta la interoperabilidad entre sistemas heterogéneos. Utilizan protocolos cerrados, distintos formatos para mensajes y representación de datos. Existe la dependencia de un proveedor, Microsoft, Sun, IBM, CORBA, etc. Es por que ello que el uso de la web con protocolos abiertos altamente extendidos como HTTP, TCP-IP, SMTP, HTTPS, etc., formatos de mensajes y estructuras de datos basados en el estándar XML, hacen a los servicios web una excelente alternativa para alcanzar comunicación e interoperabilidad de sistemas heterogéneos [orth-ws-framework]. Esto último no implica que los servicios web sean el reemplazo obligado de otras tecnologías de computación distribuida sino un valioso componente complementario que permite interoperabilidad entre ellas y facilita la automatización. Algunas guías sobre cuándo es conveniente usar servicios web y la arquitectura SOA se presentan en los siguientes párrafos. Otras guías al respecto pueden encontrarse en el capítulo 13 de [soaerl, Erl, Tomas]. Cuándo es conveniente usar web services? Cuando los componentes de sistemas distribuidos corren sobre distintas plataformas y productos. Actualmente existen especificaciones para servicios web que permiten asegurar la confiabilidad de entrega y que los mensajes enviados no sean modificados en su trayecto, por lo que el aspecto de la velocidad en Internet puede solucionarse usando estas especificaciones y una aplicación apropiada o interface (middleware). Sobre la velocidad de transmisión, a pesar del tamaño extra que se paga por la codificación de XML, existen soluciones como la compresión de XML o el caché de respuestas 13 que pueden mejorar la velocidad. Obviamente se necesita de más procesamiento de la información enviada, por ejemplo para la encripción se debe pagar el precio que involucra esta nueva operación. UPIICSA - IPN Página

103 Cuando los componentes de sistemas distribuidos corren sobre distintas plataformas y productos. Gracias a la Interoperabilidad que entregan los servicios web y al gran soporte de la industria de los protocolos asociados, de componentes de cualquier plataforma mediante una simple llamada sobre HTTP estructurando su información con XML, puede comunicarse con cualquier otra usando la tecnología de servicios web [ws-arch, W3C Así esta heterogeneidad de plataformas cuenta con un mecanismo de más alto nivel para hacer conversar sus componentes, sin necesidad de modificar su lógica interna ni estructura propia de cada plataforma. Cabe recalcar que la utilidad de los servicios web en este caso, se ve cuando existe una necesidad de comunicar estos componentes en sistemas heterogéneos (sobre todo en el caso que se deban entregar funcionalidades como servicios). Otra razón se aprecia cuando los distintos componentes no tienen acceso ni control sobre los otros (casos en que distintos componentes están en diferentes dependencias). Si los componentes se encuentran bajo el dominio de una misma unidad organizacional, puede resultar más conveniente (aunque menos modular) no entregar funcionalidades como servicios sino que por ejemplo, otorgar acceso directo a un depósito de datos que utilice un componente mediante el uso de conectores especiales, Host to Host o Point to Point, sockets, etc. Esto a su vez puede entregar más velocidad a la operación pero perjudica la modularidad y el encapsulamiento. 13 Algunas de las propuestas para mejorar velocidades de transmisión son XOP (XML binary Optimizad Packaging) y XML Binary Characterization. UPIICSA - IPN Página

104 Cuando existe una aplicación que necesita dejarse accesible en la red y puede ser encapsulada como un servicio. No sólo una aplicación puede requerir ser accesible en la red sino que como ya se ha mencionado, también puede ser información de un depósito de datos o flujo documental [ws-arch, W3C La utilidad de esta opción, es que no es necesario cambiar la lógica interna de la aplicación para entregar el servicio sino que basta con crear un front-end que internamente llame a la aplicación y externamente haga visible el resultado, mediante la definición de una forma de llamado y una estructura para la información retornada (usando SOAP). Cuando existe un alto número de servicios que son reutilizados por distintas fuentes. Si las aplicaciones se pueden descomponer en partes independientes que se comunican entre ellas, o utilizan funcionalidades comunes que pueden ser presentadas como servicios, se puede alcanzar una alta modularidad y reutilización naturalmente. Un punto interesante es que las fuentes que entregan los servicios se pueden encontrar distribuidas y corriendo sobre distintas plataformas. Ejemplos de ello es contar con componentes para autenticación, registro de operaciones, validación de datos o filtro de mensajes. Cuando se requiere de descripciones formales. Gracias a que WSDL forma parte de la tecnología de servicios web, inmediatamente se cuenta con una definición formal de los servicios y sus interfaces. Esto no sólo permite tener documentados y estandarizados los servicios que entrega una unidad o dependencia sino que también permite la clasificación, búsqueda, comparación e inferencia, basados en las definiciones de estos servicios. Todas estas acciones abren un nuevo mundo en cuanto a la automatización de procesos y la organización y representación formal del conocimiento, pueden entregar un mayor valor final a los usuarios de los servicios, más que su mera funcionalidad. UPIICSA - IPN Página

105 Cuando se requiere una alta accesibilidad. Debido al alto soporte de los protocolos de la web y a la gran adopción de sus tecnologías, el uso de servicios web permite una alta accesibilidad a sus recursos. Además se debe tomar en cuenta en el caso particular de México su geografía, la cual dificulta muchas veces la comunicación, pero gracias a protocolos maduros, extendidos y soportados de la Web es viable y posible. Cuándo no conviene usar servicios web o la arquitectura SOA? : Cuando se requiere una alta velocidad y se puede pagar el precio de contar con sistemas acoplados. En muchas aplicaciones, existen servicios críticos que exigen el más alto desempeño posible. Ellas van desde juegos multi-jugador en línea, hasta aplicaciones en comercio electrónico (e-commerce). En aquellos casos donde un servidor suele recibir cientos de miles de requerimientos por segundo, la rapidez de respuesta y el procesamiento son claves para brindar un buen o mal servicio, el acoplamiento entre componentes y uso de formatos de datos no estándares pero muy livianos, resulta ser una decisión de diseño más ventajosa. Para tales casos la comunicación de los distintos componentes con servicios web, ya sea por el uso de XML o llamadas HTTP, no asegura la rapidez y confiabilidad necesaria en tales operaciones, por lo que esta tecnología no resulta ser la más conveniente. Basándose en la posibilidad de que como en otras tecnologías los servicios web mejoren en temas de desempeño usando compresión, abreviaciones o caché, además de la aparición de mejores bibliotecas que implementen los servicios web y el mejoramiento del hardware de procesamiento, habrá que evaluar en el futuro si la velocidad resultante es suficiente para este tipo de aplicaciones. Cuando no se quiere dejar disponibles los servicios a través de la Web. Cuando la comunicación de componentes no ocurre a través de la web sino al interior de una organización (intranet), soluciones como la mensajería pueden resultar más ventajosas, ya sea por desempeño o por contar con una API con funciones para integración de aplicaciones, entre otras razones. UPIICSA - IPN Página

106 Cuando algún aspecto de los Servicios Web no alcanza el consenso ni madurez necesarios. Actualmente a pesar de que la tecnología de los servicios web está altamente soportada y aceptada, algunos aspectos como la seguridad se encuentran aún en proceso de mejora y es por ello que ciertas especificaciones podrían no tener la madurez, acuerdo, ni soporte necesario para cumplir con todos los requerimientos de algunas aplicaciones. Un tema que requiere un mayor estudio y profundización, tiene que ver con la posible ventaja o desventaja que puede resultar del uso de servicios web con respecto a los costos. A pesar de que según [orth-ws-framework, Günter, Orth. The Web Services Framework] otras tecnologías como CORBA, RMI o COM+ resultan limitadas, más caras y menos flexibles que los servicios web, ello no representa un estudio acabado, tan actualizado, ni considera evaluaciones como la de Total Cost of Ownership (TCO). El TCO calcula el costo total que implica la introducción de una solución dada, lo que incluye infraestructura, desarrollo, mantenimiento y operación. Durante el desarrollo de este trabajo 14 no se encontró un buen estudio al respecto que avale si en temas de costos, el uso de servicios web es comparativamente mejor que otras soluciones. Sin embargo, existe la posibilidad de cuantificar el costo considerando varios aspectos que se involucran en el desarrollo de una solución, haciendo un estudio de las herramientas utilizadas durante el análisis, diseño, desarrollo e implementación (ciclo de vida del desarrollo de software). Tales herramientas pueden ser los mismos planes de trabajo, el análisis y cuantificación de las horas-hombre invertidas, facturación de productos de software y hardware, evaluación de costos de infraestructura y licencias, etc. Este análisis de costos comprende más una actividad de la Ingeniería de Software y sería un tema de tesis completo y muy extenso, pero lo que es importante resaltar en el aspecto económico y tecnológico, es que los servicios web son un grupo de tecnologías y protocolos de uso libre, soportados por organismos de fama y reconocimiento tecnológico y mundial, flexibles en su implementación puesto que no dependen de una tecnología o plataforma en especifico y que en muchas organizaciones han ofrecido grandes ventajas y excelentes resultados como lo muestra a continuación el capitulo 4 de este trabajo. 14 Agosto Junio UPIICSA - IPN Página

107 Capítulo 4 Casos de estudio y de éxito usando Servicios Web Este capítulo se enfoca en la presentación de casos de éxito usando web services, así como propuestas para desarrollar soluciones basadas en el uso de la tecnología de los propios servicios web. Se presentan a groso modo la función de estos servicios y los requerimientos que se tomaron en cuenta para su análisis, diseño e implementación, aclarando que no se presenta una documentación completa de cada uno de los casos, dado que este documento se extendería demasiado. UPIICSA - IPN Página

108 4 Casos de estudio y de éxito usando Servicios Web. A continuación se presentan 3 casos del uso de servicios web con distintos tipos de participantes, interoperabilidad, comunicación e información. Los tres casos difieren en el uso que se le puede dar a los servicios web para solucionar el problema. El tomar casos de estudio o de éxito en diferentes ámbitos, busca obtener un conjunto de necesidades, descripciones y definiciones que sean útiles para atacar la mayoría de los dominios de la aplicación, aunque este proceso dificulta el hecho de encontrar patrones comunes, debido a la naturaleza de cada uno de los problemas que se afrontan. Para los casos 1 y 2 se define a groso modo el conjunto de requerimientos del problema para luego identificar las descripciones (metadatos) que son necesarios para resolver tales requerimientos. Para un desarrollo más breve, los metadatos que se repiten en los distintos casos sólo son nombrados en su primera ocurrencia. En cada caso se identifican tecnologías, estándares y propuestas que implementan o describen como resolver el problema. Además, se ofrecen referencias a descripciones que entregan más detalles pero que quedan fuera del alcance de este trabajo por cuestiones de tiempo y tamaño de este documento. Los requerimientos han sido clasificados según el estándar de la ESA [estándar-esa, Engineering Standard. European Spacial Agency] en funcionales, de verificación, seguridad, etc. Los metadatos correspondientes a los requerimientos de los servicios, han sido clasificados según los 6 componentes más recurrentes identificados en todos los servicios analizados (ver Tabla 5). Para el caso 3 se presenta un enfoque complementario a los Casos 1 y 2, presentando decisiones de diseño, problemas, pasos y propuestas basados en la experiencia obtenida en el desarrollo de servicios web para la Secretaría de Hacienda y Crédito Público por parte del tesista. Cabe resaltar que el tema de seguridad se trata aquí con ejemplos que no incluyen el estándar WS-Security, dado que su madurez sólo cubre una pequeña parte de los mensajes SOAP y la inclusión de otros mecanismos de seguridad, que no son exclusivos del estándar. UPIICSA - IPN Página

109 Algunos de los mecanismos como la autenticación, el uso de certificados digitales, canales de comunicación cifrados, análisis de vulnerabilidad de equipos (ataque de puertos en servidores) si son tratados aquí y algunos forman parte del estándar WS-Security. Herramientas como BEPEL de Oracle proporcionan flexibilidad para integrar en el modelado de soluciones algunos de los mecanismos de seguridad mencionados anteriormente, sin mencionar que forman parte de la familia de estándares para el desarrollo de servicios web. Componente Calidad de Servicio (QoS). Administración de Recursos. Autentificación y Validación. Seguridad. Flujo Documental. de Recursos. Antes de llamar a un servicio, el cliente y proveedor deben negociar variables como el uso de compresión, tipo de protocolo, encriptación, tamaño de archivos o número de caracteres por campo, etc. Quién es dueño de los recursos debe caracterizarlos, permitir su búsqueda, invocación, edición, coordinación, etc. Dados los volúmenes de los recursos, son necesarias herramientas que permitan su fácil administración. Las personas, sistemas, servicios, mensajes, etc. deben autenticar su identidad y/o correctitud para ejecutar una acción o ser considerados válidos. Se debe asegurar el envío, recepción, privacidad, integridad, etc. de los recursos. Para ello se pueden requerir operaciones sobre ellos, definición de restricciones, algoritmos y herramientas que implementen seguridad, etc. El flujo de documentos, coordinación de invocación de servicios, etc. Debe ser definido no sólo dentro del flujo de una institución del Gobierno sino como la visión de un flujo que atraviesa varias dependencias y sistemas. Los recursos deben estar caracterizados formalmente para poder buscar, acceder, inferir, etc. sobre ellos. Para ello deben existir operaciones comunes que permitan acceder a sus descripciones y entregar servicios sobre los mismos recursos. Ejemplo: validar políticas de privacidad de un cliente contra las que define un servicio. Tabla 5: Clasificación de metadatos en los servicios en el e-gobierno. Los casos presentados en este capítulo no contemplan a fondo un análisis ni la documentación completa de la solución, dado que el objetivo es enfocarse en la identificación de requerimientos y la solución que pueda solventarlos mediante el uso de servicios web, identificando los beneficios que pueda tener el uso de ésta tecnología. Por tal razón se utilizan los modelos MOM y SOM (figuras 17 y 18 respectivamente) del capítulo 3 de este trabajo, para plasmar el modelo de una solución que resuelva la interacción y relaciones entre agentes que intervienen en la entrega de uno o más servicios. Un modelado más a detalle puede realizarse con herramientas como UML, BPEL, u otros que detallen en más niveles las interacciones entre éstos agentes y sus relaciones, así como los mensajes que deben intercambiarse a un nivel más bajo. Sin embargo, este documento no tiene por objeto hacer un análisis profundo, ni un modelado de los casos hasta sus niveles más bajos, puesto que hacerlo representa un documento muy extenso y no es el objetivo primordial de este trabajo. UPIICSA - IPN Página

110 4.1 CASO 1. Servicio de Administración Tributaría (Inscripción al RFC). El Servicio de Administración Tributaria (SAT), encargado de realizar la recaudación de impuestos a nivel federal, cuenta con una gran variedad de sistemas para llevar a cabo su función. Su arquitectura se compone de aplicaciones en lenguajes muy diversos y de sistemas operativos incompatibles entre sí, soportando una operación muy importante para el gobierno federal debido a su relevancia para la economía del país del Servicio Para que un contribuyente pueda acceder a los servicios del Servicio de Administración Tributaria (SAT de ahora en adelante), se requiere que primero cuente con su Registro Federal de Contribuyentes (RFC en adelante) y una identificación electrónica. (Clave de Identificación Electrónica Confidencial CIEC, o bien la Firma Electrónica Avanzada FEA también llamada FIEL por el acrónimo de Firma Electrónica). Una vez que esto ocurre, el contribuyente debe acudir por la vía tradicional a una administración local del SAT para poder realizar el pago de sus contribuciones o bien realizar dicha operación a través de Internet en el portal de la dependencia. En esta tarea intervienen obviamente los gobiernos estatales, el gobierno federal, los ciudadanos y los organismos que se encargan de la administración de los recursos financieros de la federación como son la Secretaría de Hacienda y Crédito Público, la Tesorería de la Federación, el Banco de México, etcétera, además de las administraciones locales que se encargan de brindar servicios a los ciudadanos para facilitarles los medios para el pago de impuestos. Este proceso es vital y por ende debe de ser un servicio optimizado de la mejor manera debido a su importancia y volumen de usuarios a los que se les brinda el servicio. La recaudación de impuestos debe ser un servicio fácil de usar para propiciar una mayor recaudación, dado que entre más complicado sea el pago de impuestos la recaudación tiende a ser un dolor de cabeza para los contribuyentes y por consecuencia una tarea en desuso. Por otra parte se beneficia enormemente a la economía del gobierno federal, quien al contar con un sistema de recaudación fácil, flexible, entendible y sobre todo ampliamente usado por los contribuyentes, propicia una mayor recaudación de dinero disponible para el presupuesto y todos los gastos del erario federal. UPIICSA - IPN Página

111 Para el caso de las transacciones electrónicas (pago de impuestos por medios electrónicos como Internet), se requiere de la expedición de certificados y llaves publicas (mecanismos de la FEA), éste mecanismo busca asegurar que un contribuyente realice su declaración a través de un documento firmado electrónicamente con su FEA que brinde integridad, autenticidad, no repudio de origen y confidencialidad a su declaración electrónica. El servicio de Registro Federal de Contribuyentes (RFC), consiste en que una persona física o moral puede llevar a cabo el registro de su clave para el pago de impuestos y que además sirve para otros trámites que normalmente requieren de un identificador para cada persona, esto se hace mediante la entrega de un documento llamado Cédula Fiscal, que contiene cierta información para identificación de la persona (física o moral). Hoy en día para que una persona pueda acceder a los servicios que ofrece el SAT se requiere que cuente con su RFC, para lo cual se le piden ciertos documentos que se utilizan a lo largo de la vida de un mexicano para identificación oficial y personal como pueden ser: Acta de nacimiento Identificación oficial: o Credencial para votar del Instituto Federal Electoral (IFE en adelante). o Cartilla del Servicio Militar (para el caso de los hombres, opcional para mujeres). o Pasaporte o Cédula Profesional Comprobante de domicilio. (En el caso de las personas morales, el domicilio de la empresa que representan). Formato de pago. Clave Única de Registro Poblacional (CURP) Una vez obtenido el documento de RFC, la persona puede realizar varios trámites y solicitar servicios tanto públicos como privados y obtendrá el beneficio de contar con una identidad fiscal sin duplicidades. UPIICSA - IPN Página

112 Trámites y/o servicios que requieren de este servicio: 1) Trámite 1: Inscripción al Registro Federal de Contribuyentes: El primer trámite que debe realizar una persona Física 15 o bien Moral 16, es el registro de su razón social (RFC) para poder ser identificado fiscalmente. Los documentos que debe presentar ante la administración local del SAT son los mencionados en el inicio de este apartado (4.1.1). Respuesta de confirmación CURP (3) Validación de identificación IFE y Domicilio (4) Validación de CURP y Acta de Nacimiento en Segob (2) Confirmación de datos del IFE (5) Solicitud de inscripción al RFC con documentos (1) Cédula RFC y tarjeta tributaria (6) RFC física Figura 19: Trámite para solicitud de Registro al RFC, validación de documentos. 15 Persona física es un individuo (nombre y apellidos) con capacidad para contraer obligaciones y ejercer derechos. 16 Persona moral es una agrupación de personas que se unen con un fin determinado, por ejemplo, una sociedad mercantil, una asociación civil, sociedades anónimas, etc. UPIICSA - IPN Página

113 Para el caso de la figura 19 se toma uno de los casos 17 en el que el contribuyente presenta como identificación la credencial para votar con fotografía expedida por el Instituto Federal Electoral (IFE), el acta de nacimiento y su CURP, de este modo el SAT debe realizar la validación de dicha documentación. 2) Trámite 2: Solicitud de Facturas para deducción de impuestos: La deducción de impuestos se hace a través de las declaraciones presentado los importes del Impuesto al Valor Agregado (IVA) y del impuesto sobre la Renta (ISR), ambos requieren que una factura contenga el desglose de ambos impuestos relacionados al contribuyente y su RFC, así como la fecha. Estos documentos sirven para respaldar las deducciones de impuestos al momento de realizar una declaración mensual o anual, según corresponda el régimen del contribuyente (persona física o moral). 3) Trámite 3: Impresión de Facturas o Recibos de Honorarios: Para la impresión de las facturas de los contribuyentes, las imprentas deben solicitar al SAT un folio de autorización para la impresión de recibos de honorarios y facturas a fin de que la cédula fiscal aparezca en dichos documentos, los cuales servirán de igual forma para la declaración y deducción de impuestos. La figura 20 ilustra el proceso para estos dos últimos trámites que podemos ver claramente cuál es la relación que se tiene con el pago de impuestos y la declaración de los mismos, es claro que estos dos trámites pueden ser aún más sencillos si pudieran automatizarse las interacciones manuales entre una entidad y otra, recientemente se ha promovido mucho la idea de contar con un sistema de facturas electrónicas, que minimicen el uso de papel y la falsificación de documentos fiscales. 17 Los otros casos que podrían validarse, son cuando se presenta la cartilla del Servicio Militar, la cédula profesional o el pasaporte en lugar de la credencial IFE, en cuyos casos se validaría con la dependencia que expidió dichos documentos (SEDENA, SEP o SRE respectivamente). UPIICSA - IPN Página

114 Solicitud de folio de control (Internet) para Impresión de facturas o recibos con RFC (2) Envío de declaración Folio para impresión (3) Imprenta (RFC) f2 Declaración de impuestos retenidos (5) Acuse de recibo de Declaración. Solicitud de Impresión de facturas o recibos (1) Facturación de productos o servicios brindados (4a) Facturación de productos o servicios brindados (4b) RFC f1 Comercios Terceras personas (físicas o morales) Figura 20: Trámites de impresión de facturas y/o recibos, y facturación de productos y servicios. 4) Trámite 4: Trámites bancarios; Los bancos y comercios normalmente utilizan sistemas informáticos validando el RFC de sus clientes para poder identificarlos más fácilmente, por una parte los bancos pueden obtener fácilmente las referencias bancarias y fiscales de una persona a través de este dato, y por otro lado los comercios pueden hacer uso del RFC para el otorgamiento de créditos, expedición de facturas, retención de impuestos y otros servicios que deriven de su propia actividad comercial. Algunos de los trámites bancarios que más tiempo requieren son la otorgación de créditos, debido que a se solicita una investigación en Buró de Crédito (Comisión Nacional Bancaria) por parte de los bancos, para validar que el RFC no esté publicado en la lista de deudores de la banca comercial o defraudadores. UPIICSA - IPN Página

115 Dicha investigación tiene un costo para el cliente el cual debe esperar uno o varios días para poder saber si es o no digno de crédito, sin embargo la publicación de su información puede ser consultada fácilmente a través de la página del Buró de Crédito en Internet (http://www.burodecredito.com.mx). Algunas de estas publicaciones representan una violación a la ley del Secreto Bancario 18 la cual debe también reformarse a fin de poder facilitar la automatización de dichos trámites. Solicitud de crédito (Hipotecario, mercantil, empresarial, etc) Banco Revisión de Estado Fiscal del RFC del solicitante. Otorgamiento o Rechazo de solicitud de crédito. RFC f2 Revisión de datos del RFC en el Buró de Crédito de la Banca Comercial. Solicitud de crédito (Hipotecario, mercantil, empresarial, etc) Envío de datos validados por la SHCP al Banco. Buró de Crédito (Banca Comercial) Figura 21: Solicitud de créditos y validaciones contra SHCP y Buró de Crédito. Como se muestra en la figura 21, actualmente el trámite requiere todavía de papeles y de autorizaciones que representan tiempo dinero y papeles, los cuales se pueden ahorrar o disminuir con el simple hecho de poder disponer de cada uno de estos servicios de manera electrónica. Dada la naturaleza de los servicios que hacen uso del RFC y de las múltiples organizaciones que lo pueden requerir para entregar un servicio, se define una solución general que se ajusta a cualquier institución que requiera saber o validar la información que una persona está presentando. 18 El Secreto Bancario es la ley que establece que la información financiera de las personas no debe ser pública ni accedida si no es bajo una orden judicial de investigación financiera. UPIICSA - IPN Página

116 El servicio para obtener y hacer uso del RFC (con fines de identificación y aspectos fiscales) puede ser ofrecido por el SAT e interactuar con otras dependencias de las siguientes formas: Servicio 1: Entregar un servicio web que devuelva un certificado digital que pueda ser impreso (como sustituto de la cédula fiscal) y que tenga validez oficial con las medidas de seguridad debidas, las validaciones de la documentación presentada para obtener dicho documento, pueden hacerse de manera electrónica a través de servicios web con otras dependencias como SEGOB y el IFE. Servicio 2: Entregar un servicio web de validación, que dado un RFC de un contribuyente, más parámetros de certificado requerido (año, periodo, finalidad del certificado, etc) permita certificar si un contribuyente está al corriente en impuestos, o es digno de crédito dependiendo de su situación fiscal y legal. Servicio 3: Entregar un servicio web que reciba parámetros del certificado requerido, y entregue una lista de todos los contribuyentes regulares que cumplen con tales parámetros. Los servicios descritos no resultan redundantes dados los requerimientos de todos los trámites que usan éste servicio, donde por ley algunos de ellos deben contar con el certificado en papel (dependencias de gobierno) y otros podrían manejarlo electrónicamente (empresas privadas) Alternativa de solución. Se tomará sólo el ejemplo del trámite 4 de la solicitud de un trámite bancario. La alternativa de solución por parte del tesista se grafica en la figura 22. WS Aceptación o rechazo del crédito otorgado IFE, RFC, FIEL Validación de IFE, RFC y domicilios de Solicitante y Fiador Solicitante Resultado de la Validación (OK / Neg) WS Fiador IFE, RFC, FIEL Formulario web Banco BANCO WS Validación de RFC, situación y domicilio fiscal, FIEL de Solicitante y Fiador Envió de respuesta y condiciones del crédito en base a validaciones (IFE, SAT) Resultado de la Validación (OK / Neg) Figura 22: Solicitud de crédito bancario, validando contra IFE y SHCP. WS UPIICSA - IPN Página

117 4.1.3 Especificación de Requerimientos de la solución. Requerimientos funcionales. RF101 Ingresar información del Contribuyente (RFC) y sus referencias personales. El contribuyente ingresa sus datos en el formulario de la institución bancaria, usando un formulario web provisto por el Banco. RF102 Validación de RFC y referencias personales. El contribuyente y sus referencias personales (personas físicas que conocen al contribuyente) deben ingresar información que autentique su identidad. Esta autenticación debe ser válida para firmar el documento que posteriormente enviarán a través de un portal proporcionado para tal fin por la institución bancaria. RF103 Negociación de petición a servicio entre cliente y proveedor. Se negocian los protocolos a usar entre los equipos del cliente y del proveedor del servicio, capacidades disponibles, a través de un enlace desde el equipo cliente hasta el servidor por un canal seguro (uso de SSL, Secure Socket Layer) RF104 Comentario Banco envía listado de referencias a validación con SAT e IFE etc. El Banco valida la información que está siendo capturada electrónicamente. El envío de un gran listado de referencias puede necesitar el envío de varios mensajes para una sola operación. RF105 Comentario Dependencias verifican datos de las referencias. Las dependencias IFE, SAT, SHCP, SEGOB, etc solicitan el certificado del RFC tanto del solicitante de crédito así como de las referencias personales del contribuyente. Recordemos que en el caso de las empresas privadas podría ser opcional el uso de documentos impresos en papel. RF106 Comentario Institución Bancaria solicita resolución de información requerida. El Banco llama a un servicio en cada dependencia que contiene la información requerida para validar los datos del solicitante así como sus referencias y estados fiscales. Este proceso podría repetirse cuantas veces sea necesario para asegurar que los datos de las referencias y el solicitante están en orden. RF107 Comentario Dependencias envían respuesta al banco incluyendo información requerida. La dependencia entrega la lista de solicitudes de información validadas para los bancos que soliciten información de clientes (RFC) El envío de un gran listado de resoluciones puede necesitar el envío de varios mensajes para una sola operación. RF108 El cliente del banco solicita la resolución de su crédito por Internet. El cliente invoca un servicio en el banco para obtener la resolución del otorgamiento de su crédito. UPIICSA - IPN Página

118 RF109 Comentario El banco confirma información y envía documentación para firma de contrato con el cliente. El banco confirma información referente al cliente y envía documentación para aceptación del crédito que puede ser firmado electrónicamente por el cliente. En caso de no ser digno de contrato, solamente se le avisa mediante correo al cliente el motivo de rechazo. RF110 Negociación sobre las condiciones del crédito. Una vez aceptado el crédito, se negocia la cantidad y condiciones, así como la forma de depósito y pago de manera electrónica a través del portal web de la institución bancaria. RF111 Comentario Cancelación de la operación por error. En caso de recibir algún mensaje de error por algún servicio se debe terminar la operación y restablecer el estado consistente anterior, para permitir posteriormente una operación de reintento. El cobro por comisión puede o no aplicar dependiendo del banco y de los términos que indique en su portal. RF112 Confirmación de éxito de la operación. Cada término de una operación debe contar con un mensaje que indique el éxito o algún posible problema encontrado luego de ejecutar la operación. Requerimientos de Verificaciones RV201 Comentario Validar envío y recepción de datos y resolución. Para cada mensaje que involucra el envío de datos del RFC y la resolución, se debe obtener una confirmación (con mensaje de regreso) de que el mensaje fue realmente enviado y recibido Un acuse de recibo con firma digital del destinatario y folio que ampare la recepción es requerido. RV202 Identificación y validación de personas (RFC). El contribuyente y sus referencias deben autenticar su identidad, de modo que el envío del RFC sea válido como si hubieran firmado tal información con rubrica. RV203 Identificación de sistemas computacionales (o sistemas de información). Las empresas (bancos y dependencias de gobierno), deben identificar su participación en los flujos de información enviados. RV204 Validación de mensajes y documentos recibidos. Las instituciones deben validar que los datos no hayan sido alterados y que efectivamente fueron enviados por quienes dicen ser. RV205 Validación de lógica de negocios. Se deben validar que las fechas de certificado sean válidas, tipos de datos y flujo de mensaje corresponden a la API y se debe probar que las operaciones que se hicieron realmente se hicieron (auditabilidad). UPIICSA - IPN Página

119 RV206 Validación de compatibilidad de definiciones de políticas de privacidad El cliente debe validar sobre la descripción del servicio que sean compatibles las políticas de privacidad (revisión de las leyes). RV207 Validación de capacidades del servicio El cliente debe verificar que el servicio que llamará soporta las capacidades que el requiere entre ellas encriptación, compresión, codificación de caracteres, no repudio, etc. RV208 Validación de precondiciones y post-condiciones del servicio. Antes de invocar el servicio, el cliente y el servidor deben cumplir las precondiciones descritas en la descripción formal del servicio. Análogo para verificación de post-condiciones. Requerimientos de Seguridad RS301 La información enviada, recibida y la comunicación entre los sistemas deben ser confiables. Antes de invocar el servicio, el cliente y el servidor deben cumplir las precondiciones descritas en la descripción formal del servicio. Análogo para la verificación de post-condiciones. Comentario Actualmente con los sistemas que cuenta Banco de México (IES) 19 para la autenticación de usuarios es suficiente para la implementación de seguridad en transacciones seguras. RS302 Interacción entre agentes requieren autenticación. Todo agente que interactúe en un servicio cuya invocación requiere conocer la identidad del cliente o proveedor, debe autenticar las partes en la llamada del servicio o asegurar que el agente ya fue autenticado previamente. RS303 Manejar sesiones de servicio. Para autenticar interacciones que se encuentren dentro de un flujo de más de una operación, se debe manejar sesiones en los servicios. RS304 Políticas de privacidad. Al inicio del servicio debe acordarse la aceptación de las políticas de privacidad sobre el uso de infraestructura e información por parte del cliente y el proveedor. RS305 Comentario Privacidad de la información transmitida La información puede requerir no ser conocida por terceros. El uso de algoritmos de encripción y firmado de la información es necesario. 19 IES; es la Infraestructura Extendida de Seguridad que implementa Banco de México para las transferencias electrónicas con el sistema SPEI (Sistema de Pagos Electrónicos Interbancarios), el esquema general de esta arquitectura se presenta en la sección de anexos UPIICSA - IPN Página

120 Requerimientos de Restricciones RRS401 Tiempos de invocación a operaciones. Cada operación debe cumplir con tiempos definidos como máximo para la transacción, time-out de llamado HTTP si corresponde, etc. Requerimientos de Interfaces RI501 RI502 La interfaz de comunicación entre agentes en cada dependencia es mediante servicios web. Se debe cumplir con la API de invocación definida para el servicio. El ingreso de datos del cliente (RFC) y sus referencias se hace en el banco. El formulario web que brinda el banco es la interfaz de envío del RFC. Requerimientos Operacionales RO601 Comentario RO602 RO603 RO604 RO605 El banco registra folio del servicio solicitado o verificaciones solicitadas. El banco almacena un registro de las operaciones solicitadas para dar seguimiento además de implementar no repudio y auditabilidad. Esto por ejemplo puede ser útil para aclaraciones y para llevar un conteo en caso de que se cobre por transacción excedente, además de confirmar la ocurrencia. Uso de identificador de sesión. Para operaciones como envío de muchos RFC se puede usar identificador de sesión para asegurar qué mensajes corresponden a una misma operación. Banco y dependencias registran operaciones. Los bancos y las dependencias registran la información de las operaciones realizadas (seguimiento y auditabilidad). Uso de transacciones. Cuando se ejecuta un conjunto de operaciones que corresponden a una operación atómica, se deben usar transacciones. Composición de servicios. Las interacciones entre servicios que juntas forman un solo proceso, deben ser especificadas formalmente (Se debe conocer el flujo de un trámite). Requerimientos de Recursos RR701 Comentario RR702 Comentario Acceso a características de un recurso. Debe existir una forma de conocer el estado, identidad y características generales y específicas de un recurso web, particularmente de un servicio web. Por ejemplo validar el flujo completo para un trámite que invoca a varios servicios. Registro y administración de recursos. Para consulta, edición de descripciones, acceso, etcétera de recursos, debe existir una interfaz común de administración. Para el caso de servicios puede ser una aplicación tipo UDDI mejorada, para documentos una herramienta para administrar visualización, metadatos, etc. UPIICSA - IPN Página

121 4.1.4 Especificación de metadatos basados en requerimientos. A continuación se listan los metadatos necesarios para cumplir con los requerimientos presentados anteriormente. Ellos están agrupados según los tipos de requerimientos presentados en la tabla 5 al inicio de este capítulo. CALIDAD DEL SERVICIO (QOS) MD100 Soporte WS Comentario MD101 Soporte WS Resumen condiciones del servicio acordadas. El servidor y el cliente se envían un resumen firmado que resume y certifica las condiciones acordadas del servicio. SOAP, Firma electrónica [firma electrónica], XML-Signature [xml-sig]. Para una lista más exhaustiva de las capacidades y restricciones que pueden ser definidas para un servicio, revisar [ws-cc-workshop]. Negociación de condiciones de servicio. El cliente envía sus preferencias para ejecución del servicio (uso de compresión, encriptación, archivos adjuntos, codificación, etc) al estilo de la negociación HTTP [rfc-http], y el proveedor retorna las capacidades soportadas y las restricciones que valdrán para la integración. Uso de protocolo HTTP para la negociación, describir políticas con WS-Policy [wspolicy], DAMLS [daml] o OWL-S [owl-s], e implementar metaservicio para la negociación. ADMINISTRACIÓN DE RECURSOS MD102 Soporte WS MD103 Soporte WS Propiedades de operaciones. Para las operaciones del flujo documental se deben almacenar propiedades de los flujos tales como el timestamping (huella de tiempo), agente que lo solicitó, identificador de operación asociado, resultado de la operación. SOAP [soap], WS-Choreography [ws-choreography], BPEL4WS [bpel4ws] Registrar operaciones realizadas. Producto del llamado a las operaciones dentro del flujo documental, se debe registrar las operaciones realizadas, agentes involucrados, mensajes, datos, etc. para su posterior administración. Depósitos en general, aunque para almacenar documentos XML se debe considerar el uso de una base de datos XML nativa, relacional, estrategias de transformación de datos, etc. AUTENTICACIÓN Y VALIDACIÓN MD104 Soporte WS Identificación para autenticarse ante sistema. Identificador único de un agente (persona, sistema, etc.) que se autentican ante otro agente. WS-Federation [ws-federation], WS-Security [ws-security], Firma electrónica [firma electrónica], SAML [saml] UPIICSA - IPN Página

122 MD105 Soporte WS MD106 Soporte WS MD107 Soporte WS Comentario Validación de mensajes enviados y recibidos. Los mensajes que intercambian el cliente y proveedor, deben estar descritos en el servicio, y cumplir con la estructura definida. XML Schema [xml-schema], SOAP [soap], WSDL [wsdl]. Alcances de la autenticación. Un servicio puede utilizar identificadores de sesión para mantener autenticado a algún agente por un tiempo dado o hasta que ocurra algún evento. Además un servicio puede delegar su autenticación a otro servicio siempre que las políticas lo permitan. WS-Federation [ws-federation], WS-Security [ws-security], SAML [saml], Cookies. Validación de precondiciones y postcondiciones. El servicio debe validar contra la definición formal de las precondiciones y postcondiciones que la invocación es válida, basado en aserciones. BPEL4WS [bpel4ws], SAML [saml] Las precondiciones y postcondiciones son parte de la descripción del servicio. SEGURIDAD MD108 Soporte WS Comentario MD109 Soporte WS MD110 Soporte WS No repudio. Identificador que permite implementar no repudio (el usuario ya debe estar autenticado), registrando las operaciones, agentes involucrados. WS-Security [ws-security], XML Signature [xml-sig] Este identificador se puede obtener en el resumen de las condiciones del servicio acordadas. Entrega confiable Los mensajes que intercambian el cliente y el proveedor deben ser realmente entregados, se debe asegurar su integridad y privacidad. WS-Security [ws-security], XML-Encryption [xml-encryption], XML-signature [xmlsig], WS-Reliability [ws-reliability] Procesamiento en los nodos. Se pueden definir instrucciones de procesamiento, que indiquen que nodos deberían procesar los mensajes y de que forma. SOAP headers [soap], WS-Addressing [ws-addressing] UPIICSA - IPN Página

123 FLUJO DOCUMENTAL MD111 Soporte WS Comentario MD112 Soporte WS Comentario Definición formal del flujo documental. Para cada flujo de información entre agentes se deben especificar los mensajes, agentes participantes, transacciones, etc. XML Schema [xml-schema], SOAP [soap], WSDL [wsdl], WS-Choreography [wschoreography], WS-Coordination [ws-coordination], BPEL4WS [bpel4ws]. Para revisar un modelo de datos con los metadatos ver [ws-choreography]. Resultado de operaciones. Para cada flujo invocado se debe conocer el resultado de la operación. Se necesita un mensaje de respuesta de operación que contenga el código de retorno, descripción de la semántica del código. Además se debe entregar un resumen de la operación realizada, sea exitosa o no. HTTP [rfc-http], SOAP [soap], WSDL [wsdl]. La definición del flujo documental debe considerar las acciones a tomar y los responsables de ejecutarlas, en caso de retorno de algún código de error. DESCRIPCIÓN DE RECURSOS (comunes, servicios, documentos) MD113 Soporte WS Comentario MD114 Soporte WS MD115 Soporte WS Comentario Estructura de documentos. Se debe definir la estructura de los documentos intercambiados. XML Schema [xml-schema] Se necesitan herramientas para administrar esquemas centralizadamente en el Gobierno (capítulo de desafíos). de políticas del cliente y del servicio. El cliente y el proveedor deben describir las políticas que los rigen, a modo de poder automatizar el proceso de negociación y validar la compatibilidad de sus políticas. WS-Policy [ws-policy], DAMLS [daml], OWL [owl-s] de capacidades y restricciones de servicios. Cada servicio describe formalmente sus restricciones y capacidades soportadas, por ejemplo archivos adjuntos, compresión, o restricciones como fechas en que el servicio se encuentra disponible, límite de conexiones, etc. WS-Policy [ws-policy], DAMLS [daml], OWL [owl-s] Para una lista más exhaustiva de las capacidades y restricciones que pueden ser definidas para un servicio, revisar [ws-cc-workshop] Reflexiones sobre el caso 1 Problemas y necesidades encontradas Cuando los recursos generados por una institución bancaria son enviados a alguna dependencia de gobierno a través de un intermediario, se debe asegurar confidencialidad y la integridad de la información. Este tipo de procesos suceden cuando las dependencias de gobierno involucradas en el flujo envían la resolución al banco. UPIICSA - IPN Página

124 La transmisión de grandes volúmenes de información en servicios no es un tema resuelto. Más allá de usar el estándar HTTP, FTP, etc. y compresión, debemos considerar en el diseño algunos cuestionamientos como es: Conviene definir transacciones (operaciones atómicas) que llamen varias veces a un servicio o bien usar archivos adjuntos? Se debe usar un lenguaje para la definición formal de las capacidades, restricciones, precondiciones, post-condiciones, políticas de privacidad, seguridad, etcétera sobre los servicios. Idealmente este lenguaje debe ser computable y proveer inferencia. Ver [wsccworkshop] para profundizar sobre capacidades y restricciones, para definición de políticas ver [ws-policy], [ws-cc-workshop], para ahondar en temas de precondiciones y postcondiciones ver [daml], [saml]. Algunos servicios pueden requerir ser síncronos o asíncronos. En el caso que el banco envía los RFC para obtener la resolución, el tiempo necesario para recibir la resolución puede variar y ser muy grande. Es por ello que se puede definir un servicio asíncrono que retorne la resolución o se puede definir un servicio en la dependencia de gobierno (SAT por ejemplo), que retorna la resolución cuando es llamado. Esto último tiene la desventaja que requiere ser manualmente llamado pero simplifica los tipos de interacciones. Componentes o metadatos recurrentes Se necesita describir la comunicación de aplicaciones, repositorios, etcétera que permita modelar la lógica del negocio, la cuál incluye transacciones, flujos condicionales, y más. La idea es coordinar el uso de servicios web y otro tipo de tecnologías. Algunas tecnologías que soportan estos requerimientos son: BPEL4WS [bpel4ws], WSChoreography [wschoreography] y WS-Coordination [ws-coordination]. La autentificación de agentes (sistemas computacionales, personas, instituciones), es una componente clave en toda interacción que requiere identificar a quien solicita y provee el servicio. En el Caso 1, se puede requerir autenticar durante un flujo particular, mantener vigente el estado autenticado de un agente o revocar la autentificación. Para ello se pueden usar aserciones que indiquen el estado de autentificación de un agente (ver [saml] para ahondar en el uso de aserciones en servicios web.) Para acordar las condiciones de invocación de un servicio se requiere un protocolo de negociación de capacidades, restricciones, precondiciones, post-condiciones, políticas de UPIICSA - IPN Página

125 privacidad, seguridad, etcétera, entre el servicio y el cliente de manera similar a lo que hace HTTP 1.1 hoy en día [rfc-http]. Se deben especificar y verificar las operaciones y acuerdos que se realizaron y tomaron, usando resúmenes de transacciones, operaciones, resultado de llamado a servicios, registro de operaciones, etc. Es decir, se necesitan metadatos para comunicar resultado de operaciones y acuerdos y una manera de almacenarlos. Se debe contar con descripciones de los recursos que interviene en los servicios, ya sean documentos, imágenes o los mismos servicios. Estas descripciones van desde los metadatos intrínsecos al recurso (por ejemplo estructura interna de un documento) hasta descripciones que definan las políticas de acceso que lo rigen. Aprendizaje y conclusiones A pesar de que el proceso del caso 1 es uno solo, existen distintos estados por los que pasa en diferentes instituciones. Además, cada institución mantiene privadas las definiciones de su lógica interna, modelos de datos, etcétera por lo cual no se puede acceder a tal información desde otra institución. Es por ello que se debe coordinar la definición del proceso completo y las interacciones de los servicios web como un flujo documental de vistas sobre otros flujos documentales. Debido a los distintos tipos de trámites, la naturaleza de ellos y sus instituciones, para un mismo servicio se debe proveer distintas operaciones de invocación. Por temas de rendimiento, reutilización, legales, etcétera, en el caso 1 puede ser necesario crear los servicios: Servicio 1, Servicio 2 o Servicio 3. Para definir cuales serán las operaciones que debe definir un servicio, se debe analizar cuales son sus potenciales usos (en otros trámites), que requerimientos tienen esos trámites y cuál es el costo-beneficio de elegir cada uno. La integración de los privados en el e-gobierno resulta altamente beneficiosa, ya que son parte activa de una gran cantidad de servicios que entrega el gobierno. Para la integración de instituciones privadas en el e-gobierno se deben incluir mecanismos de autenticación que permita que sus servicios sean usados seguramente desde los servicios del gobierno o viceversa. Un ejemplo de ello puede ser el pago de un servicio cargándolo a la cuenta corriente del cliente de algún banco. UPIICSA - IPN Página

126 Para ejecutar exitosamente un servicio se debe verificar el cumplimiento de todas las condiciones que define el cliente y proveedor de servicios, disponibilidad y estado del servicio antes de la invocación, el cumplimiento del contrato en tiempo de ejecución y el resultado al finalizar el servicio. Es decir, se deben validar todas las acciones y sus condiciones. Para ello se deben describir formalmente todas estas características de los recursos. Las descripciones de un servicio no tienen que estar necesariamente disponibles como simples documentos, sino que también mediante la definición de servicios que entregan información sobre el servicio, es decir, metaservicios. Así los metaservicios (servicios sobre servicios) pueden usarse para entregar una API estándar de administración de recursos. Dados los volúmenes, complejidad de modelo de datos, mantenimiento de metadatos, etcétera de los recursos que maneja el gobierno en los servicios que entrega, se necesita de herramientas para administración de recursos. Esta es una clara muestra del ofrecimiento de mejores servicios, que aún cuando se ha avanzado mucho en la entrega de un servicio para la recaudación de impuestos más amigable y fácil de usar, se puede mejorar aún más para incrementar la productividad de la propia dependencia encargada de recaudar el dinero para el gasto público. Es cierto que a nadie nos gusta pagar impuestos, pero también es cierto que si TODOS contribuyéramos de manera proporcional, la recaudación de impuestos sería más sencilla y menos costosa, sin embargo el objetivo es tratar de mejorar los servicios para que más gente contribuya y el peso de pagar impuestos recaiga sobre más personas para conseguir las metas de vivir mejor y servir mejor. 4.2 Caso 2: Sistema de Pago Centralizado de Nómina Federal. La Secretaria de Hacienda y Crédito Público (SHCP, Hacienda de ahora en adelante), se compone de varios suborganismos que interactúan entre sí para poder llevar a cabo la administración de los recursos recabados por el SAT a través de impuestos, a la vez que orquesta la erogación de presupuestos para el manejo de la economía del país. UPIICSA - IPN Página

127 Algunos de los organismos que interactúan con Hacienda son la Tesorería de la Federación (TESOFE), las Subsecretarias de Egresos y de Ingresos, el Banco de México, el Banco Mundial, la Oficialía Mayor etc. La secretaria de Hacienda en conjunto con algunos de estos organismos mencionados, se encargan de proporcionar los recursos económicos a las demás dependencias de gobierno de acuerdo al presupuesto otorgado a cada una en el presupuesto anual, el cuál se emite a finales de cada año. El pago de nóminas es una actividad que involucra una gran cantidad de procesos, tanto en las dependencias como en el resto de los organismos e instituciones que participan en el flujo para el pago de una quincena a los trabajadores del Estado. En este caso se plantea una solución que se implementa por el tesista en los tiempos en que se desarrolla este trabajo de tesis, esta solución realiza el pago de nóminas a nivel federal a través del sistema SPEI (Sistema de Pagos Electrónicos Interbancarios) de Banco de México y del SIAFF (Sistema Integral de Administración de Fondos Federales) de la SHCP, queda pendiente la parte de automatizar la apertura de cuentas en las instituciones bancarias del Servicio El proceso de generación de pago de nóminas es propio de cada una de las dependencias de gobierno, el cálculo y la forma en que se lleva el control de incidencias por empleado es propio de cada una de las aplicaciones de las dependencias, dado que varían en conceptos y prestaciones. Una vez que las dependencias realizan el cálculo de su nómina se solicita a la Secretaria de Hacienda que se asigne el presupuesto para el pago de dicha nómina (movimiento quincenal), después se solicita a través de una Cuenta por Liquidar Corriente (CLC) en el sistema SIAFF, la cantidad a depositar en el banco con el cual tiene convenio la dependencia para el depósito de nómina de sus empleados, la Secretaria de Hacienda por su parte debe validar que la CLC corresponda con el presupuesto asignado, para posteriormente retirar de la cuenta de la TESOFE la cantidad indicada y depositar al banco correspondiente para el pago de la nómina de la dependencia. El banco por su parte realiza la distribución del pago hacia los cuentahabientes (empleados) de acuerdo con el archivo de nómina que fue proporcionado por la dependencia. UPIICSA - IPN Página

128 SIAFF SHCP TESOFE CLC VPN $$$ Dependencias (SEP, SEGOB, SCT, etc) Archivo firmado y ensobretado Banco $ $ $ Figura 23: Mecanismo semiautomático para pago de Nómina Federal Este proceso en algunos momentos manual, representa un desfase en los tiempos de pago de nóminas federales, ya que el proceso se debe realizar de 3 a 5 días anticipadamente debido a que los procesos de validación dependen de un visto bueno (no automatizado) y que representa un gasto innecesario, casos como este se presentan de igual forma en la iniciativa privada. Para el caso de los depósitos y transferencias electrónicas, actualmente ya se cuenta con los pagos electrónicos y las transferencias electrónicas entre instituciones de la Banca Comercial. El Banco de México actualmente ofrece el servicio de SPEI (Sistema de Pagos Electrónicos Interbancarios), que permite realizar pagos entre bancos de manera segura, fácil y confiable, debido a que implementa mecanismos de seguridad altamente confiables y probados. El servicio de pago de nóminas de los bancos, es un convenio por el cual la dependencia utiliza las facilidades de algún banco para poder realizar el depósito de nómina a los empleados, sin embargo esto obliga a que los empleados tengan que usar forzosamente los servicios de dicho banco para poder disponer de su dinero. Para que una persona (empleado) pueda acceder a los servicios que ofrece el banco debe realizar el trámite de solicitar una cuenta de nómina en el banco y posteriormente proporcionar a la dependencia el número de cuenta a fin de que se deposite el pago quincenal de su nómina. UPIICSA - IPN Página

129 Una vez que se tiene la cuenta, el empleado debe solicitar a su banco la activación de los servicios que desea utilizar (a través del portal web o por la vía telefónica). Para realizar dicho trámite se requiere contar con los siguientes datos: Identificación oficial con fotografía. Comprobante de domicilio. Solicitud de apertura de cuenta. Una vez obtenida la cuenta la persona puede comenzar a recibir sus pagos de nómina en dicha cuenta, solicitar los servicios que ofrece el banco y obtener los beneficios de manejar su dinero sin peligro de perdida física dado que la mayoría de los movimientos serán de manera electrónica. Trámites y/o servicios que requieren de este servicio: Trámite 1: Solicitud de apertura de cuenta: El primer trámite que debe realizar una persona para poder recibir depósitos de nómina es solicitar la apertura de su cuenta en el banco con el cual tenga convenio la dependencia, debiendo presentar identificación, comprobante de domicilio y su solicitud de apertura de cuenta. Banco Empleado del Banco $$ Documentos $$ Cuenta 1 Empleado 3 Dependencia Cuenta Figura 24: Trámite para solicitud de Cuenta de nómina para depósitos de la dependencia. UPIICSA - IPN Página

130 Trámite 2: Servicio de pago de nóminas federales: Tal y como se mostró en la figura 23 de este capítulo, el pago de la nómina federal se lleva a cabo mediante un proceso semiautomático, que comienza con el envío del archivo de nómina de la dependencia hacia el sistema SIAFF de SHCP el cuál realiza entre otras validaciones, que el presupuesto solicitado corresponda con el asignado de acuerdo a las plazas presupuestadas, que la cuenta de la cual se va a retirar el dinero tenga fondos suficientes para la transferencia al banco, etc. Y finalmente, la Tesofe realiza la transferencia al banco que realiza la dispersión de los pagos hacia los empleados. Tramite 3: Solicitud de reintegro de pagos no efectuados por el banco: Dado que los movimientos de personal no son identificados inmediatamente en las dependencias, en parte debido al desfasamiento del pago, se presenta el caso en que el pago no puede ser efectuado al empleado debido a que la cuenta ya no existe, o a que hubo incidencias que no se afectaron en el periodo, se retrasaron movimientos de personal, etcétera por ello, la dependencia debe exigir el regreso del dinero que no fue depositado a través de la TESOFE, que realiza mediante un documento la solicitud de devolución de saldos pendientes de liquidar al banco, dicho proceso normalmente lleva implícito un procedimiento burocrático que retarda el regreso de dichos pagos, que mientras tanto genera intereses a favor del banco. Como se muestra en las figuras 23 y 24, estos trámites requieren todavía de papeles y de autorizaciones que representan tiempo y dinero, factores que son muy importantes cuando se habla de reducción de costos en los recursos del Estado. Con base en todos los servicios que requieren del uso de los bancos para el pago de nóminas, se propuso una solución general por parte de las áreas de tecnologías de SHCP y de Banco de México que abarca la mayoría de los trámites y servicios que se necesitan para poder automatizar los procesos para dicha actividad. El servicio para poder realizar los depósitos de nómina e interactuar con las dependencias e instituciones que se involucran en el proceso debe cumplir con los siguientes servicios generales: Servicio 1: Entregar un servicio web que devuelva un certificado digital a las dependencias, para que puedan enviar sus archivos de nómina firmados y ensobretados de manera segura a través de la VPN (Virtual Private Network, Red Privada Virtual) de la secretaria de Hacienda. Servicio 2: Entregar un servicio web de solicitud de cuenta de nómina en el banco para poder obtener los servicios de la institución financiera y poder proporcionar el número de cuenta a la dependencia y poder obtener ya los depósitos de nómina. UPIICSA - IPN Página

131 Servicio 3: Brindar un servicio web a la entrada del sistema SIAFF para procesar los archivos que llegan de las dependencias, procesarlos, validarlos y posteriormente otro servicio web que realice la transferencia hacia Banco de México para que a través del sistema SPEI pueda realizar la dispersión de pagos hacia los bancos (sin importar de que banco se trate). Estos servicios se complementan para automatizar todo el proceso de pago de nóminas desde el cálculo, los pagos electrónicos que se disparan desde las dependencias, hasta la dispersión de pagos por parte del Banco de México Solución Desarrollada. La solución resulta de la propuesta hecha para la SHCP haciendo uso de tecnologías disponibles también en Banco de México y usando estándares J2EE, dicha solución se presenta en la figura 25. Monitoreo web de pagos Servicio Web Procesamiento y validaciones SIAFF Envío de pagos a SPEI SPEI (BANXICO) Envío de archivos seguros SIAFF (SHCP) Dispersión de pagos hacia Bancos Solicitud de apertura de cuenta por ServicioWeb Dependencias (SEP, SCT, PGR, $$ deposito en cuentas de empleados $$ deposito en cuentas de empleados $$ deposito en cuentas de empleados Envío de cuenta de depósito vía Servicio Web Indica el uso de un Servicio Web. Figura 25: Propuesta de solución para el pago de nóminas usando servicios web para automatizar el proceso. UPIICSA - IPN Página

132 4.2.3 Especificación de Requerimientos de la solución. Requerimientos funcionales. RF101 Ingresar información del empleado para solicitud de cuenta en banco. El empleado captura su información en el formulario web del banco con alguna firma electrónica para validar su información RF102 Validación de información y su certificado. El empleado debe ingresar información que autentique su identidad. Esta autenticación debe ser válida como para firmar el documento de contrato que posteriormente enviará el banco para cerrar el proceso de apertura de cuenta. RF103 Negociaciones de comunicación cliente-servidor (empleado-banco). El servicio web debe ser capaz de iniciar las validaciones de ancho de banda y privacidad del canal de comunicaciones. RF104 Comentario El banco envía al usuario (empleado) su número de cuenta. El banco valida la información del certificado y del solicitante para realizar apertura de cuenta en la base de datos del banco El envío de muchas peticiones o solicitudes puede requerir el envío de muchos mensajes para la operación. RF105 Comentario El empleado envía su información y número de cuenta a la dependencia. La dependencia recibe a través de un servicio web el número de cuenta del empleado junto con el certificado que le identifique para validar en su sistema de RH los datos del empleado. Para algunos casos la ley podría exigir que exista una rúbrica, sin embargo aquí se propone el uso de certificados y firmas digitales. RF106 Comentario Dependencia realiza proceso de pago de nómina interno. La dependencia realiza sus movimientos de corte para comenzar el cálculo de la nómina quincenal, procesando las nuevas cuentas que llegan por el servicio web. El proceso puede repetirse varias veces a lo largo del cierre de nómina, esto con el fin de poder realizar el cálculo de todas las incidencias y de validar los certificados que lleguen como parte de una nueva petición de cuenta de nómina. RF107 Comentario Dependencia obtiene el archivo de nómina para envío a SIAFF (SHCP). La dependencia termina su cálculo de nómina y obtiene un archivo que contiene la información del pago de nómina quincenal, se le aplican mecanismos de seguridad (firmado y ensobretado) y se envía al SIAFF a través de la VPN. El envío de un gran número de archivos puede requerir una infraestructura con un canal de ancho de bando amplio para la rápida transferencia de archivos, además de un medio seguro como un canal seguro o cifrado con SSL( o bien una VPN) RF108 El SIAFF procesa archivos que lleguen de las dependencias a través del WS. El sistema SIAFF a través de un servicio web que este escuchando peticiones, será capaz de procesar dichos archivos una vez que los recupere en claro (verificación de firma y desensobretado). UPIICSA - IPN Página

133 RF109 Comentario Una vez validado y procesado el archivo de nómina se envía hacia SPEI. Una vez que el SIAFF ha validado totalmente el archivo con todas sus dependencias (cuentas, presupuesto, aprobaciones, etc) se le aplican mecanismos de seguridad para el envío hacia Banco de México (SPEI) En caso de no concluir satisfactoriamente el proceso de validación, se comunica a la dependencia si el archivo fue rechazado y las causas. RF110 Recepción de archivos en Banco de México con SPEI. El Banco de México recibe peticiones para procesamiento de archivos a través de un servicio web que recupera los archivos en claro (verificación de firma y desensobretado) y procede a realizar validaciones previas al envío. RF111 Comentario Dispersión de pagos hacia los bancos con SPEI. Una vez validado el archivo, se envía un acuse de recibo a SIAFF para indicar que se procederá a realizar la dispersión de pagos hacia las cuentas de los empleados en los bancos correspondientes. En caso de que el archivo contenga errores, se procede a regresar el archivo y en el acuse de recibo se indican los motivos de rechazo. RF112 Confirmación de depósitos en cuentas de empleados. El monitoreo de los pagos se puede hacer directamente desde la dependencia hacia Banco de México, a través del portal APL-SPEI que sirve para el monitoreo de los pagos enviados hacia Banco de México. Requerimientos de Verificaciones RV201 Comentario Validar envío y acuse de recibo para solicitud de apertura de cuenta Para cada transacción entre cliente y servidor, se debe enviar un acuse de recibo y confirmación sobre la apertura de la cuenta en banco. Un acuse de recibo con firma digital del destinatario y folio es lo recomendable. RV202 Comentario Verificación de datos de cuenta habiente por parte del banco. El Banco deberá realizar las validaciones correspondientes de la información enviada por el empleado, corroborando dicha información con las dependencias que implique (IFE, SEDENA, ARA, etc). Lo mejor es que estas validaciones se realicen vía un servicio web por cada una de las dependencias involucradas en el flujo y validación de datos. RV203 Identificar infraestructuras de cada una de las instituciones involucradas. Cada una de las dependencias y de los bancos debe realizar una revisión a su infraestructura tecnológica a fin de soportar la operación del flujo completo. RV204 Validación de cuentas y datos recibidos. Las dependencias deberán poder corroborar con los bancos a través de servicios web la existencia de las cuentas y la disponibilidad para recibir transferencias electrónicas. UPIICSA - IPN Página

134 RV205 Validaciones de reglas de Negocio. Es importante validar que los datos de cada empleado correspondan con los documentos electrónicos que se utilizan en el flujo, se debe validar que las fechas de certificado sean aún vigentes, que los tipos de datos y flujo de mensaje corresponden a las especificaciones para cada interfaz o bien para cada aplicación, y se debe probar que las operaciones que se realizaron, realmente se llevaron a cabo (auditabilidad). RV206 Definir las políticas de seguridad a seguir y a implementar en su caso. Tantos los clientes como los servicios involucrados deben validar que los mecanismos de seguridad implementados a lo largo del flujo corresponden de principio a fin con la política de seguridad definida para todo el proceso. RV207 Validación de capacidades y disponibilidad de los servicios. Los clientes que se encuentren a lo largo del flujo deben validar que los servicios que usarán, cuenten con la capacidad y disponibilidad necesarios para poder soportar la operación con grandes cantidades de transacciones, además de soportar los mecanismos de seguridad como encriptación, compresión, codificación de caracteres, no repudio, etc. RV208 Validación de condiciones previas y finales de los servicios. Los clientes deben de validar que antes de invocar el servicio se cumplan las condiciones necesarias para la operación, esto se puede consultar fácilmente en la definición del servicio, de igual forma esto es análogo para verificación de las condiciones finales del servicio. Requerimientos de Seguridad RS301 Comentario La información enviada, recibida y la comunicación entre los sistemas deben ser confiables, utilizando mecanismos y medios seguros. Antes de invocar los servicios los clientes deben asegurarse de cumplir con las especificaciones de seguridad de los servicios, como pueden ser el uso de encripción, firmas digitales, canales de comunicación cifrados, uso de VPN, etc. La comunicación entre Banco de México y la SHCP actualmente dispone de una VPN con canales de comunicación cifrados y uso de la arquitectura IES de Banco de México para la transferencia de archivos de pagos. RS302 Autenticar a cada una de las entidades involucradas en el flujo. Toda entidad que tenga interacción con un servicio del flujo, deberá requerir la autenticación del cliente que está solicitando para acceder al servicio que usará. RS303 Convenios y políticas de seguridad y privacidad. Cada una de las partes involucradas (cliente y servidor) deberán aceptar y cumplir los convenios y políticas de seguridad y privacidad a fin de ser coherentes con el flujo y no sufrir desviaciones. RS304 Confidencialidad de información que es transmitida. La información que se transmite no debe ni puede ser conocida por terceros no involucrados en el flujo. UPIICSA - IPN Página

135 RS305 Comentario Realizar análisis de vulnerabilidad de equipos, escaneo de puertos que no utilizan las aplicaciones. Antes de publicar un servicio en Internet o en cualquier red, se requiere determinar que puertos no son utilizados por las aplicaciones que interactúan a fin de reducir la vulnerabilidad de un equipo ante un ataque de penetración (PEN- TEST, Penetretion Test Prueba de penetración). Los puertos que son utilizados normalmente por los hackers, deben ser cerrados o bien filtrados a través de un firewall. Requerimientos de Restricciones RRS401 Tiempos de invocación a operaciones y tamaño de archivos a transferir. Las operaciones que se realicen deben conocer los tiempos y tamaños límite de operaciones y transferencia de archivos, a fin de cumplir con tiempos definidos como máximo para la transacción, time-out de llamado HTTP o de SFTP. Requerimientos de Interfaces RI501 RI502 La interfaz de comunicación entre instancias en cada dependencia es mediante servicios web. Se debe cumplir con la API de invocación definida para el servicio. El ingreso de datos del empleado se hace en el banco y en la dependencia. El formulario web que brinda el banco es la interfaz de envío de solicitud de apertura de cuenta, además del portal para seguimiento de pagos de SPEI en Banco de México. Requerimientos Operacionales RO601 Comentario RO602 RO603 RO604 El banco guarda registro de la solicitud de apertura de cuenta. El banco almacena un registro de la operación solicitada por el empleado para dar seguimiento posteriormente a quejas o inconformidades Esto es necesario, en caso de que la dependencia requiera validar información sobre la cuenta aperturada por el empleado (cliente). Uso de sesiones para identificar cada operación. Si por alguna razón la operación de solicitud de apertura no fuera exitosa, se deben guardar en sesión los datos del usuario (empleado) que está solicitando el servicio. Banco y dependencias guardan información y registro de la apertura Los bancos y las dependencias guardan registro e historial de las transacciones sobre la cuenta para aclaraciones. Uso de operaciones en volumen y transacciones. Las operaciones que llevan a cabo un gran número de operaciones o volumen muy grande, es recomendable que utilicen transacciones para operaciones atómicas. UPIICSA - IPN Página

136 Requerimientos de Recursos RR701 Comentario Disponibilidad y acceso a las propiedades de un recurso. Sobre todo para el monitoreo de los pagos, debe existir una forma de conocer el estado, identidad y características generales y especificas de un recurso web, particularmente de un servicio web. Esto por ejemplo podría permitir validar el flujo completo definido para un trámite que invoca a varios servicios, como lo es el APL-SPEI para monitoreo de los pagos en Banco de México RR702 Administración de los servicios y sus recursos. Cuando se desea consultar, editar características y acceder a recursos, se requiere contar con interfaces que permitan conocer esta información de manera segura, a fin de tener un control sobre el flujo y los estados de la información, es decir la administración de la información y su auditabilidad Especificación de metadatos basados en Requerimientos. Nuevamente se listan los metadatos necesarios para cumplir con los requerimientos presentados anteriormente para este caso. Se toma como referencia la tabla 5 al inicio de este capítulo para poder agruparlos de acuerdo a su naturaleza. CALIDAD DEL SERVICIO (QoS) MD100 Soporte WS MD101 Soporte WS MD102 Soporte WS Concentrado de condiciones acordadas. Para cada transacción, el servidor y el cliente se envían un acuse de recibo firmado que resume y certifica las condiciones acordadas del servicio SOAP, Firma electrónica[firma electrónica], XML-Signature [xml-sig] Definición de capacidades para brindar servicio. Los proveedores de servicios deben asegurar que la disponibilidad y rendimiento del servicio que ofrecen, no afectará en ningún momento la operación del proceso ni la interrupción del flujo. Uso de protocolo HTTP para la negociación, uso de SFTP (ftp seguro) para transferencias de archivos, canales de comunicaciones con ancho de banda suficiente y seguro, describir políticas con WS-Policy [ws-policy], DAMLS [daml] o OWL-S [owl-s] e implementar metaservicio para la negociación. Monitoreo del flujo. Para las operaciones del flujo documental se debe poder auditar en cualquier momento el estatus de la transacción, disponiendo de una interfaz que permita conocer al empleado y a la dependencia en que momento se encuentra la transacción. SOAP [soap], WS-Choreography [ws-choreography], BPEL4WS [bpel4ws] UPIICSA - IPN Página

137 ADMINISTRACIÓN DE RECURSOS MD103 Soporte WS Mantener Registro de las operaciones realizadas. Producto del llamado a las operaciones dentro del flujo documental, se deben registrar las operaciones realizadas, agentes involucrados, mensajes, datos, etc. para su posterior administración Repositorios en general, aunque para almacenar documentos XML se debe considerar el uso de una base de datos XML nativa, relacional, estrategias de transformación de datos, etc. AUTENTICACIÓN Y VALIDACIÓN MD104 Soporte WS MD105 Soporte WS MD106 Soporte WS MD107 Soporte WS Comentario Identificación para autenticarse ante sistema. Identificador único de un agente (persona, sistema, etc.) que se autentican ante otro agente. WS-Federation [ws-federation], WS-Security [ws-security], Firma electrónica [firma electrónica], SAML [saml] Validación de mensajes enviados y recibidos. Los mensajes que intercambian el cliente y proveedor deben estar descritos en el servicio y cumplir con la estructura definida XML Schema [xml-schema], SOAP [soap], WSDL [wsdl]. Alcances de la autenticación. Un servicio puede utilizar identificadores de sesión para mantener autenticado a algún agente por un tiempo dado, o hasta que ocurra algún evento. También es posible que un servicio pueda delegar su autenticación a otro servicio, siempre que las políticas lo permitan. WS-Federation [ws-federation], WS-Security [ws-security], SAML [saml], Cookies. Validación de precondiciones y postcondiciones. El servicio debe validar contra la definición formal de las precondiciones y postcondiciones que la invocación es válida, basado en aserciones. BPEL4WS [bpel4ws], SAML [saml] Las precondiciones y postcondiciones son parte de la descripción del servicio. SEGURIDAD MD108 Soporte WS Comentario MD109 Soporte WS No repudio. El uso de certificados es un medio identificador que permite implementar no repudio (usuario ya debe estar autenticado), registrando las operaciones, agentes, involucrados. WS-Security [ws-security], XML Signature [xml-sig] Este identificador se puede obtener en el resumen de las condiciones del servicio acordadas. Entrega confiable. Tanto los archivos como los mensajes que intercambian el cliente y proveedor deben ser realmente entregados, se debe asegurar su integridad y privacidad. WS-Security [ws-security], XML-Encryption [xml-encryption], XML-signature [xmlsig], WS-Reliability [ws-reliability] UPIICSA - IPN Página

138 FLUJO DOCUMENTAL MD110 Soporte WS MD111 Soporte WS Comentario Definición formal del flujo documental. Para cada flujo de información entre agentes se deben especificar los archivos, mensajes, agentes participantes, transacciones, cerificados a utilizar, mecanismos de seguridad, etc. XML Schema [xml-schema], SOAP [soap], WSDL [wsdl], WS-Choreography [wschoreography], WS-Coordination [ws-coordination], BPEL4WS [bpel4ws]. Resultado de operaciones. Cada invocación del flujo debe conocer el resultado de la operación. Si es necesario, se puede implementar un mensaje de respuesta (acuse de recibo o aviso de transacción exitosa), es necesario tener un código de retorno o código de error según sea el caso, descripción de la semántica del código. Además se debe entregar un resumen de la operación realizada, sea exitosa o no. Http [rfc-http], SOAP [soap], WSDL [wsdl]. La definición del flujo documental debe considerar las acciones a tomar y los responsables de ejecutarlas en caso de retorno de algún código de error. DESCRIPCIÓN DE RECURSOS MD112 Soporte WS Comentario MD113 Soporte WS Comentario MD114 Soporte WS MD115 Soporte WS Layout de formularios. Se debe definir el layout para los documentos que se vayan a capturar en los formularios web de las entidades involucradas en el flujo. XML Schema [xml-schema] Definir políticas para la solicitud de datos y la manera en como se van a validar dichos datos mediante servicios web en otras dependencias. Estructura de archivos y documentos. Se deberá definir el layout para los archivos y la estructura de los documentos intercambiados durante el proceso. XML Schema [xml-schema] Se necesitan herramientas para administrar esquemas centralizadamente en el gobierno (capítulo de desafíos). de políticas del cliente y del servicio. El cliente y proveedor deben describir las políticas que los rigen a modo de poder automatizar el proceso de negociación y validar la compatibilidad de sus políticas (Legislación para dichas políticas). WS-Policy [ws-policy], DAMLS [daml], OWL [owl-s] de capacidades y restricciones de servicios. Cada servicio describe formalmente sus restricciones y capacidades soportadas, por ejemplo archivos adjuntos, compresión o restricciones como fechas en que el servicio se encuentra disponible, límite de conexiones, etc. WS-Policy [ws-policy], DAMLS [daml], OWL [owl-s] UPIICSA - IPN Página

139 4.2.5 Reflexiones sobre el caso 2 Problemas y Necesidades Encontrados Cuando se realiza el envío de información hacia el banco para la solicitud de apertura de cuenta, así como el envío de la información de nómina desde la dependencia hasta su destino final que es la cuenta del empleado, se debe asegurar mediante mecanismos de seguridad como el firmado y cifrado de la información (mensaje) o bien mediante el cifrado del canal (mediante SSL, Secure Socket Layer), que la información viaja de modo confidencial asegurando integridad y no repudio de la información. De igual forma para la transmisión de grandes volúmenes de archivos desde las dependencias hacia el sistema SIAFF de SHCP puede requerir de un ancho de banda suficientemente grande, aun cuando se utilice compresión y SFTP, es por esto que se requiere que los archivos firmados y ensobretados tengan un nivel de compresión bastante alto. La definición de reglas de transferencia y de comunicación entre aplicaciones debe de ser lo bastante flexible como para soportar cambios constantes en la definición de las mismas, debido a que constantemente se sufren cambios por decretos o por leyes aprobadas que modifican el flujo y las condiciones de la información. Componentes o Metadatos Recurrentes Será necesario definir específicamente los tipos de comunicación, anchos de banda, certificados para cifrado de canal de comunicaciones, espacio necesario en bases de datos para el almacenamiento de las transacciones y su histórico, a fin de que el modelo de datos y de la lógica de negocio sea más fácil de definir, lo cual ayudara a la implementación de los servicios web y otras tecnologías que resolverán el problema de la comunicación entre aplicaciones de distinta fabricación, ver WS-Choreography[wschoreography] y WS-Coordination [ws-coordination] Puede requerirse que durante el flujo de los documentos sea necesario realizar la autenticación de las entidades que estén participando en una transacción, esto puede ser a nivel de persona, de sistema, de institución o bien de documento, debido a que la información que se maneja a lo largo de la operación es confidencial y puede requerir en cualquier momento revisar el estado de autenticación. UPIICSA - IPN Página

140 De igual forma que en el caso 1, puede presentarse que se requiera acordar las condiciones de invocación de un servicio, dado que de igual forma se requiere un protocolo de negociación de capacidades, restricciones, condiciones previas, condiciones finales, políticas de privacidad, seguridad, etcétera, entre el servicio y el cliente de manera similar a lo que hace HTTP 1.1 hoy en día [rfc-http]. Dada la naturaleza de la operación del flujo puede que se necesiten metadatos para comunicar resultado de operaciones y acuerdos y una manera de almacenarlos, con el propósito de dar auditabilidad al proceso y asegurar la información de los empleados y que pueda ser consultada en cualquier momento a través de una herramienta de monitoreo (APL-SPEI por ejemplo). Es necesario contar con datos que describan los recursos que participan a lo largo de la invocación de un servicio, los recursos pueden ser archivos transferidos, documentos, imágenes, etc. Esta información o metadatos de los recursos pueden ser por ejemplo el layout del archivo transferido, la estructura del documento enviado, el tamaño de una imagen, o incluso datos del mismo servicio web que se está invocando. Aprendizaje y conclusiones La definición general de este caso 2 implica por definición de proyectos que en el caso en que intervienen 2 o más entidades en un flujo, es necesario definir un líder de proyecto general, a la vez que se define uno para cada etapa del flujo. Como es de esperarse, cada una de las entidades involucradas debe asegurar la privacidad de la información en su entorno y sus dominios, a la vez que su lógica de negocio debe ser compatible con el resto de la operación de las otras interfaces o bien de las propias aplicaciones a fin de mantener una ecuanimidad, sobre todo al momento de utilizar Reglas de Negocio compartidas. Las interacciones entre servicios web deben ser coordinadas explícitamente con la definición de documentos que permitan que el flujo sea el mismo a través de cada una de las dependencias por las cuales pasa el proceso. Dada la importancia de la operación (nómina federal), es necesario definir planes alternativos de operación, previendo la caída de alguno de los puntos del flujo dado que nada es seguro en esta vida, es necesario definir un plan de contingencia en cada uno de los puntos críticos de la operación y de igual forma al interior de cada una de las dependencias. UPIICSA - IPN Página

141 Soluciones como ésta, resuelven de manera satisfactoria el problema de retrasos por validaciones manuales, además de que implican un ahorro enorme en el uso de tecnologías que proveen en algunas ocasiones instituciones bancarias como CECOBAN (Centro de Control Bancario) y que suelen ser soluciones a la medida para una sola aplicación, cerrando la puerta a flujos parecidos de otras dependencias, en el caso del Gobierno Federal, encontramos muchas veces que las aplicaciones no suelen ser pensadas para grandes cantidades sino que se casan con la solución para un solo flujo. Una correcta definición del problema y un análisis completo de la infraestructura de cada dependencia o institución que se involucra en el desarrollo de una solución, son altamente importantes al momento de definir el flujo de operación y de documentos, ya que amplia el panorama de la solución y determina las expectativas esperadas al final de la solución, que posteriormente se puede convertir en un ahorro al momento de implementar la solución completa, estos aspectos no se incluyen en este documento debido a que la extensión del mismo se incrementaría mucho más. Los grandes impedimentos para este tipo de soluciones no suelen ser las tecnologías sino por el contrario las leyes que no dan validez jurídica ni moral al uso de medios electrónicos como lo es este caso 2, dado que en algunos instantes es necesario definir antes la Ley o Decreto que determine que no existirá ningún impedimento para el desarrollo de la solución, esto es posible si se siguen los caminos adecuados para su formalización legal ante las autoridades, pero eso significa generar acuerdos a niveles de alto mando. Este es un caso más donde podemos hablar de un proceso de transparencia, al disminuir en gran medida la intervención de procesos manuales, ya que una de las principales problemáticas presentadas era el pago de nóminas a trabajadores que no existían, las validaciones que se hacen ahora en la SHCP, han disminuido en gran cantidad el número de plazas inexistentes que recibían quincena tras quincena su pago sin siquiera saber quién era el titular de dicha plaza. Otro factor importante a destacar aquí, es el uso de tecnologías propias del gobierno federal y el ahorro de recursos al ya no depender directamente de los bancos para el pago de nóminas, por otro lado el pago ahora se hace a través del Banco de México que dispersa el depósito hacia las cuenta de los trabajadores, previamente validados en SHCP. UPIICSA - IPN Página

142 4.3 Caso 3: Sistema de Expedición de Pasaportes y/o Licencias. Desde noviembre del 2004 los habitantes del Distrito Federal pueden realizar el pago de derechos de pasaportes a través de Internet. La Secretaría de Relaciones Exteriores (SRE) puso en práctica el programa que forma parte del Plan de Desarrollo del Gobierno Federal, de igual forma se implementaron mecanismos para agilizar el trámite de solicitud de licencias en el gobierno del Distrito Federal a través de Internet. Dicho mecanismo permite realizar los pagos de manera fácil y ágil ya que se puede realizar desde la página de Internet de los bancos con los cuales se tiene convenio. El sistema permite de manera sencilla el llenado de formatos de tal suerte que los datos solicitados como: Tiempo por el que va a requerir el pasaporte Costo se llenan de manera automática, posteriormente se debe cubrir el importe correspondiente a través de los medios electrónicos accesando a la página del banco en el cual se tenga una cuenta para fondear el pago. El cobro del servicio puede hacerse con cargo a su chequera, tarjeta de crédito o débito. Cada año dos millones 400 mil personas solicitan un pasaporte [sre] 20, y más de 900 mil solicitan licencias de manejo [setravi] 21, de ahí la importancia de agilizar dichos trámites vía Internet. Actualmente el Estado de México ha realizado grandes esfuerzos en materia de gobierno electrónico, ofreciendo cada vez más servicios a través de su portal web, disminuyendo la cantidad de filas en las sucursales de la tesorería del estado y agilizando muchos de los trámites que eran tardados y tediosos para la mayoría de la gente. Nuevamente este caso es una solución alterna propuesta por el tesista para agilizar uno de tantos trámites que pueden ser atendidos ofreciendo un servicio a través de medios electrónicos, la propuesta genérica no especifica la tecnología para desarrollar los servicios web (J2EE,.NET, PHP, etc.) dado que la misma tecnología no está amarrada a un diseño en especifico ni a una plataforma o lenguaje en particular. [sre] 20 - Fuente Secretaria de Relaciones Exteriores SRE [setravi] 21 Fuente Secretaria de Transporte y Vialidad UPIICSA - IPN Página

143 4.3.1 del Servicio La solicitud de un pasaporte o bien de la licencia de manejo, son trámites que ocupan la mayoría de las personas mayores de edad, sin embargo, no podemos dejar de lado los trámites para otros casos como: Menores de edad ( pasaportes y licencias) Adultos de la tercera edad ( pasaportes y licencias ) Discapacitados ( pasaportes y licencias ) Transportistas ( pasaportes y licencias ) Sin importar la edad, los trámites pueden realizarse de acuerdo a las validaciones que para cada uno corresponda. Para éste caso se considera el proceso de solicitud de pasaportes, asumiendo que el caso de las licencias puede resolverse de la misma manera ofreciendo así una solución equivalente a la del pasaporte. El trámite y los requisitos que deben cumplir los mexicanos mayores de edad para obtener un pasaporte ordinario mexicano son los siguientes: Acudir personalmente a una Delegación de la SRE u Oficina de Enlace: La expedición de pasaporte es un trámite personal por lo que no puede llevarse a cabo por medio de un representante legal o gestor, debiendo comparecer el interesado en cualquiera de las Delegaciones u Oficinas de Enlace. El siguiente paso es llenar la solicitud con tinta negra y letra de molde, ésta solicitud es llamada; formato de Solicitud de Pasaporte Ordinario Mexicano (OP5) [figura 26]. Figura 26: Solicitud de pasaporte ordinario mexicano [OP-5]. UPIICSA - IPN Página

ERP s Universitarios: soluciones, experiencias y tendencias. CrueTIC Universidad de La Rioja

ERP s Universitarios: soluciones, experiencias y tendencias. CrueTIC Universidad de La Rioja ERP s Universitarios: soluciones, experiencias y tendencias CrueTIC Universidad de La Rioja Qué es un ERP? Sistema de planificación de recursos empresariales (ERP, Enterprise Resource Planning). Permiten

Más detalles

Universidad de Guadalajara

Universidad de Guadalajara Universidad de Guadalajara Centro Universitario de Ciencias Económico-Administrativas Maestría en Tecnologías de Información Ante-proyecto de Tésis Selection of a lightweight virtualization framework to

Más detalles

La idea central de e-business es hacer que los beneficios de la tecnología e Internet sirvan para facilitar las actividades de la empresa.

La idea central de e-business es hacer que los beneficios de la tecnología e Internet sirvan para facilitar las actividades de la empresa. Negocios electrónicos (e-business) Para entender lo que es el e-business es necesario comprender claramente los conceptos que se acaban de plantear, ya que es una respuesta más sofisticada de las empresas

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

Bases de Datos Especializadas

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

Service Oriented Architecture

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

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

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

PROGRAMA DEL DIPLOMADO DE PROCESO BENCHMARKING. TEMA 9. IMPLEMENTACION LA ADMINISTRACIÓN DE LA RELACIÓN CON EL CLIENTE (CRM).

PROGRAMA DEL DIPLOMADO DE PROCESO BENCHMARKING. TEMA 9. IMPLEMENTACION LA ADMINISTRACIÓN DE LA RELACIÓN CON EL CLIENTE (CRM). PROGRAMA DEL DIPLOMADO DE PROCESO BENCHMARKING. TEMA 9. IMPLEMENTACION LA ADMINISTRACIÓN DE LA RELACIÓN CON EL CLIENTE (CRM). Objetivo: Al finalizar la unidad el alumno conocerá el proceso de desarrollo

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.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

TITULO SERVICIOS DE CONSULTORIA INTEGRAL (RECURSOS HUMANOS, MARKETING Y TECNOLOGIA) A PEQUEÑAS Y MEDIANAS EMPRESAS VÍA INTERNET PARA S.C.I. CIA.

TITULO SERVICIOS DE CONSULTORIA INTEGRAL (RECURSOS HUMANOS, MARKETING Y TECNOLOGIA) A PEQUEÑAS Y MEDIANAS EMPRESAS VÍA INTERNET PARA S.C.I. CIA. TITULO SERVICIOS DE CONSULTORIA INTEGRAL (RECURSOS HUMANOS, MARKETING Y TECNOLOGIA) A PEQUEÑAS Y MEDIANAS EMPRESAS VÍA INTERNET PARA S.C.I. CIA. Ltda AUTORES Yandres García Charcopa 1 Nadia Luna Eras 2

Más detalles

INTEROPERABILIDAD ESTÁNDARES APLICADOS EN COSTA RICA

INTEROPERABILIDAD ESTÁNDARES APLICADOS EN COSTA RICA 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

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

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

Estándares y Protocolos de IABIN

Estándares y Protocolos de IABIN La arquitectura del sistema adoptada por IABIN se basa en la amplia flexibilidad y soporte de los sistemas desarrollados con base en el web, y tiene una inherente capacidad de soportar los requerimientos

Más detalles

Curso 5007437. Capítulo 4: Arquitectura Orientada a Servicios. Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007

Curso 5007437. Capítulo 4: Arquitectura Orientada a Servicios. Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Capítulo 4: Arquitectura Orientada a Servicios Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es

Más detalles

El Documento, factor clave en las relaciones con el ciudadano

El Documento, factor clave en las relaciones con el ciudadano El Documento, factor clave en las relaciones con el ciudadano Javier Ontiveros Country Manager Xerox Global Services I. INTRODUCCIÓN El término Cliente fue acuñado por primera vez a comienzos del siglo

Más detalles

Integración de Aplicaciones de Negocio ÍNDICE: Presentación Integración de Aplicaciones de Negocio 01 Infraestructura Tecnológica de Integración 02 Servicios Web 03 Tecnología de portal 04 Arquitectura

Más detalles

Título del Proyecto: Sistema Web de gestión de facturas electrónicas.

Título del Proyecto: Sistema Web de gestión de facturas electrónicas. Resumen Título del Proyecto: Sistema Web de gestión de facturas electrónicas. Autor: Jose Luis Saenz Soria. Director: Manuel Rojas Guerrero. Resumen En la última década se han producido muchos avances

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

La Administración electrónica en la Unión Europea

La Administración electrónica en la Unión Europea La Administración electrónica en la Unión Europea Raquel Gómez Díaz Yolanda Martín González Universidad de Salamanca (España) Resumen Las tecnologías de la información y la comunicación ofrecen amplias

Más detalles

ES UNA SOLUCIÓN DE GESTIÓN DE PROCESOS COMERCIALES DE CÓDIGO ABIERTO LA CORRECTA PARA USTED?

ES UNA SOLUCIÓN DE GESTIÓN DE PROCESOS COMERCIALES DE CÓDIGO ABIERTO LA CORRECTA PARA USTED? INFORME TÉCNICO ES UNA SOLUCIÓN DE GESTIÓN DE PROCESOS COMERCIALES DE CÓDIGO ABIERTO LA CORRECTA PARA USTED? RESUMEN EJECUTIVO COMPANIES AROUND THE WORLD TRUST OPEN SOURCE 90% of Fortune 500 companies

Más detalles

RESUMEN DE TRABAJO DE GRADO

RESUMEN DE TRABAJO DE GRADO RESUMEN DE TRABAJO DE GRADO Universidad Nueva Esparta. Facultad de Ciencias de la Informática. Escuela de Computación. Autores: Barrios M. Cesar E, Céspedes Nelson Tutor: Gabriel Méndez Titulo: Implantación

Más detalles

TECNOLÓGICAS EMPRESAS

TECNOLÓGICAS EMPRESAS SOLUCIONES TECNOLÓGICAS INTEGRALES PARA LAS EMPRESAS Por: Ivonne Rodríguez CONTENIDO 1. Problemas actuales en las empresas 2. Bussines Intelligence 3. Capa: Data Warehouse 4. Capa: BI en el campo empresarial

Más detalles

UNIVERSIDAD VERACRUZANA

UNIVERSIDAD VERACRUZANA UNIVERSIDAD VERACRUZANA FACULTAD DE INGENIERÍA EN ELECTRÓNICA Y COMUNICACIONES MONOGRAFÍA QUE PARA OBTENER EL TITULO DE: INGENIERO EN ELECTRÓNICA Y COMUNICACIONES PRESENTAN DIRECTOR DEL TRABAJO RECEPCIONAL:

Más detalles

ADAPTACIÓN DE REAL TIME WORKSHOP AL SISTEMA OPERATIVO LINUX

ADAPTACIÓN DE REAL TIME WORKSHOP AL SISTEMA OPERATIVO LINUX ADAPTACIÓN DE REAL TIME WORKSHOP AL SISTEMA OPERATIVO LINUX Autor: Tomás Murillo, Fernando. Director: Muñoz Frías, José Daniel. Coordinador: Contreras Bárcena, David Entidad Colaboradora: ICAI Universidad

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes

Más detalles

Administración de la calidad del software.

Administración de la calidad del software. UNIVERSIDAD IBEROAMERICANA ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL POR DECRETO PRESIDENCIAL DEL 3 DE ABRIL DE 1981 ADMINISTRACIÓN DE LA CALIDAD DEL SOFTWARE UNA NUEVA FORMA DE TRABAJAR TESIS Que

Más detalles

Soluciones Informáticas para gestionar su empresa Presentación de empresa la Compañía La Compañía NEO GRUP Management, es un proyecto definido y creado para proporcionar a nuestros clientes, trabajando

Más detalles

DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA RESUMEN DEL PROYECTO

DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA RESUMEN DEL PROYECTO I DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA Autor: Juárez Montojo, Javier. Director: Rodríguez Mondéjar, José Antonio. Entidad Colaboradora: ICAI-Universidad Pontificia Comillas RESUMEN

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN)

COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN) COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA 1 Ismael Armando Zúñiga Félix y 2 Luicyana Pérez Figueroa 1,2 División de Estudios de Posgrado e Investigación (DEPI), Instituto

Más detalles

Service Oriented Architecture

Service Oriented Architecture 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

puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales?

puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? RESUMEN DE LA SOLUCIÓN Service Operations Management puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? agility made possible (SOM) de CA Technologies es una solución

Más detalles

Tema: Administración de Tecnologías de Información

Tema: Administración de Tecnologías de Información Área Académica: Lic. en Sistemas Computacionales Tema: Administración de Tecnologías de Información Profesor: Dr. Alejandro Fuentes Penna Periodo: Enero Junio 2014 Tema: Impacto de las TIC en la Organización

Más detalles

13. EL LEAD TIME EN EL DESARROLLO DE PRODUCTOS SOFTWARE

13. EL LEAD TIME EN EL DESARROLLO DE PRODUCTOS SOFTWARE 13. EL LEAD TIME EN EL DESARROLLO DE PRODUCTOS SOFTWARE Jaime Alberto Sánchez Velásquez Ana Lucía Pérez * RESUMEN En los últimos años, el aumento de las compañías desarrolladoras de software en Colombia

Más detalles

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web.

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web. Microsoft Office SharePoint Server 2007 es un conjunto integrado de características de servidor que puede contribuir a mejorar la eficacia organizativa al ofrecer completas funciones de administración

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia 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

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

ESCUELA SUPERIOR POLITÉCNICA DEL LITORAL Facultad de Ingeniera en Electricidad y Computación. Tema:

ESCUELA SUPERIOR POLITÉCNICA DEL LITORAL Facultad de Ingeniera en Electricidad y Computación. Tema: ESCUELA SUPERIOR POLITÉCNICA DEL LITORAL Facultad de Ingeniera en Electricidad y Computación Tema: SISTEMA DE PRESUPUESTO DE MATERIALES Y MANO DE OBRA ELECTRICA SIPREME Freddy Roddy Briones Ruiz 1, Glenda

Más detalles

PLANIFICACIÓN ESTRATÉGICA DE TECNOLOGÍAS DE LA INFORMACIÓN PARA LA EMPRESA POLITEX S.A.

PLANIFICACIÓN ESTRATÉGICA DE TECNOLOGÍAS DE LA INFORMACIÓN PARA LA EMPRESA POLITEX S.A. PLANIFICACIÓN ESTRATÉGICA DE TECNOLOGÍAS DE LA INFORMACIÓN PARA LA EMPRESA POLITEX S.A. AUTOR Carlos Alberto Lima Ayala 1, Diego Miguel Marcillo Parra 2, Tatiana Marisol Gualotuña Alvarez 3 1 Departamento

Más detalles

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK 1 LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK Miguel Angel Abellán Juliá Gerente de Soluciones para Administraciones Públicas. Hewlett-Packard Española,

Más detalles

Capítulo I. Marco Teórico

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

Gestión n de Procesos y Tecnologías BPM en Banca y Seguros

Gestión n de Procesos y Tecnologías BPM en Banca y Seguros Gestión n de Procesos y Tecnologías BPM en Banca y Seguros Renato de Laurentiis Director Ejecutivo Club BPM España a y Latinoamérica renato@club-bpm.com bpm.com Madrid, 21 de junio 2011 Misión La misión

Más detalles

Transformación de grandes cantidades de datos en valiosa estrategia Business Intelligence

Transformación de grandes cantidades de datos en valiosa estrategia Business Intelligence MICROSOFT SQL SERVER 2000 SOLUCIÓN C SPAR Handels AG Transformación de grandes cantidades de datos en valiosa estrategia Business Intelligence Publicado: Mayo de 2001 SPAR es un minorista líder europeo

Más detalles

Relationship Management)

Relationship Management) C R M (CustomerRelationshipManagement) por Ing. Paul Ochoa En las décadas de los ochenta e inicios de los noventa las empresas de clase mundial formulaban estrategias orientadas al producto, es decir la

Más detalles

Metodología para desarrollar materiales electrónicos educativos para el aprendizaje a distancia autónomo

Metodología para desarrollar materiales electrónicos educativos para el aprendizaje a distancia autónomo Metodología para desarrollar materiales electrónicos educativos para el aprendizaje a distancia autónomo P. Gómez*, F. Vázquez* y J. Rodas** *Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias

Más detalles

Big Data y Manejo de Datos Maestros

Big Data y Manejo de Datos Maestros Objetivos 1.- El alumno identificará el contexto, la problemática y utilizará diversas herramientas de Manejo de Datos Maestros. Esto permitirá formarse un criterio sobre cómo implementar un proyecto de

Más detalles

Karina Ocaña Izquierdo

Karina Ocaña Izquierdo Estudié Ingeniería en Sistemas Computacionales (1997) y una Maestría en Ingeniería de Cómputo con especialidad en Sistemas Digitales (2000), ambas en el Instituto Politécnico Nacional (México). En el 2003,

Más detalles

... omunicación ... Ramón Querejazu. Director de Selftising. Comunicación

... omunicación ... Ramón Querejazu. Director de Selftising. Comunicación ... Comunicación... Ramón Querejazu Director de Selftising omunicación ... La aldea global del siglo XXI... Ramón Querejazu Director de Selftising Existen multitud de descripciones acerca de la Comunicación.

Más detalles

PIDE. Presentación. Proyecto Plataforma de Interoperabilidad del Estado. Preparado por: Equipo de Proyecto PIDE

PIDE. Presentación. Proyecto Plataforma de Interoperabilidad del Estado. Preparado por: Equipo de Proyecto PIDE PIDE Proyecto Plataforma de Interoperabilidad del Estado Presentación Preparado por: Equipo de Proyecto PIDE Contenido Introducción Objetivos del Estado Servicios al Ciudadano Situación Actual LA PIDE

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Este proyecto tiene como finalidad la creación de una aplicación para la gestión y explotación de los teléfonos de los empleados de una gran compañía.

Este proyecto tiene como finalidad la creación de una aplicación para la gestión y explotación de los teléfonos de los empleados de una gran compañía. SISTEMA DE GESTIÓN DE MÓVILES Autor: Holgado Oca, Luis Miguel. Director: Mañueco, MªLuisa. Entidad Colaboradora: Eli & Lilly Company. RESUMEN DEL PROYECTO Este proyecto tiene como finalidad la creación

Más detalles

Arquitectura Empresarial como Práctica para Mantener la Estabilidad de los Sistemas de una Organización

Arquitectura Empresarial como Práctica para Mantener la Estabilidad de los Sistemas de una Organización Arquitectura Empresarial como Práctica para Mantener la Estabilidad de los Sistemas de una Organización Eloísa Itzé Hernández Santuario* Resumen En las condiciones actuales en las que operan las empresas,

Más detalles

TIC y modernización de la Justicia

TIC y modernización de la Justicia TIC y modernización de la Justicia itil aplicado al cau de la administración de justicia por juan emilio ayuso Si buscas resultados distintos, no hagas siempre lo mismo Albert Einstein La modernización

Más detalles

UNIDAD ACADÉMICA CIENCIAS DE LA EDUCACION Y DE LA COMUNICACIÓN

UNIDAD ACADÉMICA CIENCIAS DE LA EDUCACION Y DE LA COMUNICACIÓN UNIDAD ACADÉMICA CIENCIAS DE LA EDUCACION Y DE LA COMUNICACIÓN PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE LICENCIADA EN CIENCIAS DE LA COMUNICACIÓN SOCIAL MENCIÓN: PERIODISMO TEMA: DISEÑO DE UN PERIÓDICO

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Tecnología de Gestión y Comunicación - TGC

Tecnología de Gestión y Comunicación - TGC Mayores necesidades y retos tecnológicos de las empresas: Necesidad de integrar datos de múltiples aplicaciones de negocios o fuentes de datos. La falta de una completa visibilidad de las finanzas y operaciones

Más detalles

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Título Área específica de la publicación 2 Implementación de Procesos Business Process Management BPM Services

Más detalles

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS UNIDAD DE POSTGRADO DE INGENIERÍA DE SISTEMAS E INFORMATICA

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS UNIDAD DE POSTGRADO DE INGENIERÍA DE SISTEMAS E INFORMATICA UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS UNIDAD DE POSTGRADO DE INGENIERÍA DE SISTEMAS E INFORMATICA DISEÑO E IMPLEMENTACIÓN DE UNA OFICINA DE GESTION DE PROYECTOS PARA LA POSITIVA SEGUROS Informe Profesional

Más detalles

Mestrado em Tecnologia da Informação. Gestão de Projetos de TI

Mestrado em Tecnologia da Informação. Gestão de Projetos de TI Mestrado em Tecnologia da Informação Gestão de Projetos de TI Proyecto Proyecto se refiere a todas las acciones que deben realizarse para cumplir con una necesidad definida dentro de los plazos. Así, ya

Más detalles

La Inteligencia Operacional permite maximizar y resolver los principales retos de las Operadoras de Comunicaciones en el área de Experiencia Cliente

La Inteligencia Operacional permite maximizar y resolver los principales retos de las Operadoras de Comunicaciones en el área de Experiencia Cliente La Inteligencia Operacional permite maximizar y resolver los principales retos de las Operadoras de Comunicaciones en el área de Experiencia Cliente o Customer Experience > 1 Indice 1 Resumen Ejecutivo

Más detalles

CAPÍTULO II MARCO TEÓRICO

CAPÍTULO II MARCO TEÓRICO CAPÍTULO II 2.1 Introducción: MARCO TEÓRICO Una vez realizado el análisis de la empresa Traveo Entretenimiento, se detectaron varios problemas en el área de ventas, para después seleccionar uno de ellos

Más detalles

Más veloz, económica y segura: Mejora de la agilidad, el coste de explotación y la seguridad con la planificación de tareas sin agente

Más veloz, económica y segura: Mejora de la agilidad, el coste de explotación y la seguridad con la planificación de tareas sin agente Más veloz, económica y segura: Mejora de la agilidad, el coste de explotación y la seguridad con la planificación de tareas sin agente Informe preparado para BMC Software Agosto de 2006 Resumen ejecutivo

Más detalles

... ntegración. y sociedad ... Miguel Dorronsoro. Director de Fashion Fruit. Integración

... ntegración. y sociedad ... Miguel Dorronsoro. Director de Fashion Fruit. Integración ... Integración y sociedad... Miguel Dorronsoro Director de Fashion Fruit ntegración ... Integración y sociedad... Miguel Dorronsoro Director de Fashion Fruit El término integración está presente en nuestro

Más detalles

Informática de Gestión. La Informática en la Empresa

Informática de Gestión. La Informática en la Empresa Informática de Gestión La Informática en la Empresa Agenda Introducción Modelos de Evolución Aplicaciones Específicas Pasado Presente y Futuro Resumen Introducción Software Empresarial Aplicaciones horizontales:

Más detalles

ERP Crecimiento Planificado de Sistemas de Información

ERP Crecimiento Planificado de Sistemas de Información ERP Crecimiento Planificado de Sistemas de Información INTRODUCCIÓN En el marco de competencia actual y con los retos que implican una economía global, es necesario que las empresas vean en los sistemas

Más detalles

El dominio de herramientas de tecnologías de información para los alumnos de nuevo ingreso

El dominio de herramientas de tecnologías de información para los alumnos de nuevo ingreso NÚMERO 39, SEPTIEMBRE-DICIEMBRE 2007 45 El dominio de herramientas de tecnologías de información para los alumnos de nuevo ingreso DE LA UNIVERSIDAD AUTÓNOMA DE AGUASCALIENTES M.C. Francisco Javier Pinales

Más detalles

Modelo Integral del Esquema de Interoperabilidad de la Administración Pública Federal

Modelo Integral del Esquema de Interoperabilidad de la Administración Pública Federal Modelo Integral del Esquema de Interoperabilidad de la Administración Pública Federal Febrero de 2013 1de 20 CONTENIDO 1. Análisis de mejores prácticas 2. Modelo integral de Interoperabilidad (Visión Nacional)

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos 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

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

PERFIL DEL INGENIERO DE SISTEMAS FUSM

PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS DE LA FUSM El perfil del Ingeniero de Sistemas presencial de la Fundación Universitaria San Martín, Bogotá, está en capacidad de modelar

Más detalles

Aproveche al máximo su tecnología y minimice los costes. Servicios de Outsourcing Avanade

Aproveche al máximo su tecnología y minimice los costes. Servicios de Outsourcing Avanade Aproveche al máximo su tecnología y minimice los costes Servicios de Outsourcing Avanade Haga más con menos Reducir costes al tiempo que se aumenta la productividad. Ampliar el alcance de la tecnología

Más detalles

PROCESO DE DESARROLLO ORGANIZACIONAL MINISTERIO DE SALUD DE COSTA RICA

PROCESO DE DESARROLLO ORGANIZACIONAL MINISTERIO DE SALUD DE COSTA RICA PROCESO DE DESARROLLO ORGANIZACIONAL MINISTERIO DE SALUD DE COSTA RICA Evaluación del Enfoque al Cliente del Sitio Web ACOMPAÑAMIENTO EN LA IMPLEMENTACIÓN DEL CAMBIO ORGANIZACIONAL DEL MINISTERIO DE SALUD

Más detalles

POR ANDRÉS FELIPE ECHAVARRÍA RAMIREZ

POR ANDRÉS FELIPE ECHAVARRÍA RAMIREZ SERVICIOS Y RECURSOS DE INFORMACIÓN SYRI PROPUESTA EN EVOLUCIÓN DE UN MODELO DE GESTIÓN DE SERVICIOS DE INFORMACIÓN EN LAS UNIVERSIDADES BASADO EN TIC S POR ANDRÉS FELIPE ECHAVARRÍA RAMIREZ SERVICIOS Y

Más detalles

Servidores Donantonio

Servidores Donantonio Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 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

Compucad: Consolidar la información para alinear los objetivos del negocio

Compucad: Consolidar la información para alinear los objetivos del negocio Historia de Éxito Servicios Profesionales Compucad SAP Estudio de la Transformación del Negocio Productos de consumo masivo J. Macêdo Compucad: Consolidar la información para alinear los objetivos del

Más detalles

Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes

Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes Rodolfo Villarroel Acevedo 1* 1 Pontificia Universidad Católica de Valparaíso. Avenida Brasil 2241,

Más detalles

Cómo podemos ayudar a cumplir esas expectativas?

Cómo podemos ayudar a cumplir esas expectativas? Cómo podemos ayudar a cumplir esas expectativas? Somos los únicos con un enfoque completo Ocio Interactivo Búsqueda / Publicidad Móvil Traditional IT y Cloud Desktop Avanzado Aspiramos a ser socios tecnológicos

Más detalles

Sistema de Preregistro Orientado al Postulante

Sistema de Preregistro Orientado al Postulante Sistema de Preregistro Orientado al Postulante Universidad Pedagógica Nacional La Universidad Pedagógica Nacional es una institución pública de educación superior, con carácter de Órgano Desconcentrado

Más detalles

A.2.2. Arquitectura de sistemas

A.2.2. Arquitectura de sistemas A.2.2. Arquitectura de sistemas La arquitectura de sistemas va más allá de los equipos y el software, incluidos los componentes y los factores adicionales que forman parte del proceso de diseño de SyTI.

Más detalles

En los últimos años, de forma predominante

En los últimos años, de forma predominante El papel de los proveedores TIC en los procesos de innovación en la Administración Pública De meros suministradores a auténticos socios tecnológicos y de negocio Los proveedores pueden y deben jugar un

Más detalles

1. Conformar el Sistema Integral de información sustantiva y de gestión de la Comisión Nacional de los Derechos Humanos.

1. Conformar el Sistema Integral de información sustantiva y de gestión de la Comisión Nacional de los Derechos Humanos. XIII. DIRECCIÓN GENERAL DE INFORMACIÓN AUTOMATIZADA La Dirección General de Información Automatizada fue creada por Acuerdo del Consejo Consultivo de la Comisión Nacional, en sesión celebrada el 14 de

Más detalles

El Negocio electrónico y la inteligencia empresarial. Teléfono: 271 6666 / 33 1953. Fax: 33 6123. Correo electrónico: juan_carlos@softel.

El Negocio electrónico y la inteligencia empresarial. Teléfono: 271 6666 / 33 1953. Fax: 33 6123. Correo electrónico: juan_carlos@softel. El Negocio electrónico y la inteligencia empresarial Autor principal y ponente: Juan Carlos Carro Cartaya. Gerencia GESTUR, Empresa Softel. Dirección: Calle 194 y 7ma, Siboney, Playa, Ciudad Habana. Cuba.

Más detalles

Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16

Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) Los nuevos escenarios de programación con SAP Netweaver (serie de varios

Más detalles

Presentación Comercial IXAYA Crédito

Presentación Comercial IXAYA Crédito Presentación Comercial IXAYA Crédito Versión: 2.0.1 Fecha: 21/04/2014 Elaboró: División Consultoría Contenido 1. Descripción de la solución....3 1.1. Beneficios....4 1.2. Modelo operativo....5 1.3. Arquitectura

Más detalles

GOBIERNO ELECTRONICO OPEN SOURCE

GOBIERNO ELECTRONICO OPEN SOURCE OPEN SOURCE Rodolfo BARZOLA V. Solutions Architec Conceptos Generales: Evaluación y Respuesta Los gobiernos y sus instituciones tienen que responder a una ciudadanía más consciente e informada. Los gobiernos,

Más detalles

EPTISA TI. Introducción. 1. Definición del proyecto empresarial

EPTISA TI. Introducción. 1. Definición del proyecto empresarial 151 EPTISA TI Introducción Eptisa Tecnologías de la Información (Eptisa TI) es una empresa del Grupo Eptisa con el 100% de capital español. Eptisa cuenta con más de 50 años aportando soluciones en los

Más detalles

IMPORTANCIA ACADÉMICA APLICADA EN EL CAMPO LABORAL

IMPORTANCIA ACADÉMICA APLICADA EN EL CAMPO LABORAL IMPORTANCIA ACADÉMICA APLICADA EN EL CAMPO LABORAL Por Br. Jorge Alfonso Díaz, jorgealfidi@gmail.com RESUMEN Este articulo trata sobre la importancia de los estudios académicos en el campo laboral, ya

Más detalles

agility made possible

agility made possible RESUMEN SOBRE LA SOLUCIÓN Utilidad ConfigXpress en CA IdentityMinder Puede mi solución de administración de identidades adaptarse rápidamente a los cambiantes requisitos y procesos de negocios? agility

Más detalles

Tecnología ERP de Infor para IBM System I

Tecnología ERP de Infor para IBM System I Tecnología ERP de Infor para IBM System I Asegure el futuro de su Sistema ERP Usted puede confiar en su sistema IBM System i (antes i Series o AS400) para ejecutar con facilidad, seguridad y flexibilidad

Más detalles

GUIDE FOR ORGANIZATIONAL BEHAVIOR A LEADING AGENT OF CHANGE

GUIDE FOR ORGANIZATIONAL BEHAVIOR A LEADING AGENT OF CHANGE GUIDE FOR ORGANIZATIONAL BEHAVIOR A LEADING AGENT OF CHANGE GUÍA PARA EL COMPORTAMIENTO ORGANIZACIONAL DE UN AGENTE LÍDER DE CAMBIO Domingo Alarcón Ortiz (1) Universidad Nacional Autónoma de México ABSTRACT

Más detalles

2524 Developing XML Web Services Using Microsoft ASP.NET

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

F A B R I C I O M U Ñ O Z S. T E N I E N T E T É C N I C O D E A V I A C I Ó N

F A B R I C I O M U Ñ O Z S. T E N I E N T E T É C N I C O D E A V I A C I Ó N PROPUESTA DE IMPLEMENTACIÓN DE UNA METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS ORIENTADOS A SERVICIOS EN EL DEPARTAMENTO DE DESARROLLO DE SISTEMAS DE LA DIRECCIÓN DE SISTEMAS DE INFORMACIÓN Y COMUNICACIONES

Más detalles

Qué ofrece Autentia Real Business Solutions S.L?

Qué ofrece Autentia Real Business Solutions S.L? Avenida de Castilla,1 - Edificio Best Point - Oficina 21B 28830 San Fernando de Henares (Madrid) tel./fax: +34 91 675 33 06 info@autentia.com - www.autentia.com Qué ofrece Autentia Real Business Solutions

Más detalles

Oracle Application Server 10g

Oracle Application Server 10g Oracle Application Server Oracle Application Server 10g La plataforma de aplicaciones más completa e integrada del mercado Puntos a comparar Lo más importante antes de realizar un análisis comparativo

Más detalles

UNIVERSIDAD TÉCNICA DE AMBATO Facultad de Contabilidad y Auditoria Carrera de Contabilidad y Auditoria

UNIVERSIDAD TÉCNICA DE AMBATO Facultad de Contabilidad y Auditoria Carrera de Contabilidad y Auditoria UNIVERSIDAD TÉCNICA DE AMBATO Facultad de Contabilidad y Auditoria Carrera de Contabilidad y Auditoria PRINCIPALES APLICACIONES, VENTAJAS Y DESVENTAJAS DEL COMERCIO ELECTRÓNICO MÓDULO OPTATIVO e bussines

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

Universia Business Review ISSN: 1698-5117 ubr@universia.net Portal Universia S.A. España

Universia Business Review ISSN: 1698-5117 ubr@universia.net Portal Universia S.A. España Universia Business Review ISSN: 1698-5117 ubr@universia.net Portal Universia S.A. España Fernández Casado, Diego El director de sistemas, como impulsor de la innovación en la empresa Universia Business

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles