Informatización del proceso de transporte en el CITI

Transcripción

1 INSTITUTO SUPERIOR POLITÉCNICO JOSÉ ANTONIO ECHEVERRÍA FACULTAD DE INGENIERÍA INFORMÁTICA Complejo de Investigaciones Tecnológicas Integradas (CITI) Informatización del proceso de transporte en el CITI TRABAJO DE DIPLOMA Presentado por: Victor Lázaro Riviaux Tutor: Juan Carlos Gras González CUJAE, Junio del 2011 Ciudad de la Habana I

2 II

3 III

4 AGRADECIMIENTOS A mi tutor Juan Carlos Grass por transmitirme los conocimientos necesarios para el desarrollo de este trabajo y por ayudarme en todo lo que pudo. A todos los profesores que he tenido a lo largo de toda la carrera, en especial a la profesora Vanesa Dánae Muñoz por brindarme su apoyo incondicional siempre que lo necesite. A los profesores de mi grupo de trabajo, gracias por recibirme y ayudarme en todo lo que pudieron. A mis compañeros de aula por los ratos agradables que pasamos juntos y los que no fueron tan agradables, en especial a Darién Guilarte por su apoyo incondicional durante toda la carrera y a Dianelis Calzada por soportar mis pesadeces y ayudarme en todo lo que me hizo falta. A todas mis amistades de los demás grupos y otros años, en especial a Wendy de la Torre por brindarme su apoyo, además de cargar con el peso de mí documento de tesis. A todos mis amigos del barrio y viejos amigos del pre por siempre estar a mi lado cuando los necesité y compartir conmigo tanto las alegrías como los momentos de tristeza. En fin, a todos los que han sido parte de este trabajo, gracias. IV

5 Dedicatorias A mi madre por ser mi inspiración y mi razón de ser en esta vida, además de todo el esfuerzo que realizó para que llegara hasta aquí. A mis hermanos Jacqueline y Yolexis por haberme dado su apoyo y todo lo que estuvo a su alcance para que saliera adelante. A mis primos María y Yuliet por haberme ayudado en todo lo que estuvo a su alcance. A mis tías que siempre me dieron fuerza y todo lo necesario para lograr ser una mejor persona cada día. A mis amigos especiales, los que siempre estuvieron a mi lado, en especial a Yasmani, Darién, Lester, Oscar y Guevis, gracias por todo. A todos los que me quieren y pensaron siempre que este día iba a llegar. V

6 RESUMEN El presente trabajo se realiza en el Complejo de Investigaciones Tecnológicas Integradas (CITI), plataforma de colaboración MES-MININT. En la visión del Complejo se plantea ser un centro de referencia en la aplicabilidad de los resultados que se obtenga en el desarrollo de sistemas, tecnologías y aplicaciones integradas novedosas con impacto en la seguridad y el orden interior. Como estrategia de esta naciente organización y para cumplir lo antes planteado, se están informatizando los procesos del CITI, siendo uno de estos el de Transporte. Es por ello que en el presente trabajo se pretende realizar un sistema para la planificación de la Transportación en el CITI. Este sistema consiste en garantizar las transportaciones con seguridad de carga y del personal del mismo para satisfacer las necesidades de todos los proyectos y áreas de la organización. Además, con motivo de agilizar los procesos en la organización y aprovechar al máximo todas las actividades que se realizan en la entidad, se considera la gestión por procesos de negocio, permitiendo alinear las estrategias de la organización con los sistemas. Todo esto será posible con el uso indispensable de una herramienta BPM (predefinida BizAgi por estudios anteriores), donde los procesos de negocios referentes al transporte en la entidad pasarán por todas las fases que provee dicha herramienta. Además se utilizará la Arquitectura Orientada a Servicios (SOA por sus siglas en inglés), la cual permitirá que el sistema de transporte pueda intercambiar información con otras aplicaciones (sistemas legados de la entidad) a través de servicios disponibles en la red, así como la utilización de estos servicios para garantizar las tareas propias de los procesos de negocio. Esta combinación de BPM y SOA será la esencia fundamental del trabajo garantizando un mejor funcionamiento de la organización. Palabras Claves BPMS, SOA VI

7 Summary This work is realized in the Integrated Technology Research Complex (CITI), MES- MININT collaboration platform. The vision , turn raises to become this Complex in a reference center on the applicability of the results obtained in systems development, innovative technologies and integrated applications with high impact on security and internal order. As a strategy for this new organization and to meet as soon raised, are being computerized CITI processes, being one of them Transport. That s the reason, the present work aims to computerize the Transport Planning in the CITI. The system has like proposal guarantied all transportations of charge and personnel, satisfied need of the projects and areas of the organization. Besides, as result of agility processes in the organization and take advantage of all the activities that takes place in it, is considering the business process management, allowing aligning the organization strategies with systems. All of it can be possible if we use a BPM Systems (BizAgi default on studies before), where business process for transporting in the Complex will go through different phases of BPM tools. Also, can use the Service-Oriented Architecture (SOA), which allows the transport system can exchange information with other applications (legacy systems) across the network services available and the use of these services to support to the tasks of business processes. This combination BPM-SOA is the fundamental essence of the work to ensure a better functioning of the organization. Key Words BPM, SOA VII

8 ÍNDICE Introducción... 1 Capítulo Introducción Descripción de la entidad Objetivos estratégicos de la Organización Sistemas existentes para la gestión del transporte Gestión del Transporte en el CITI Procesos de Negocio Definiciones de proceso de negocio Gestión de Procesos de Negocio Fases del Ciclo de vida de BPM Descripción de las fases del ciclo de vida de BPM Estándares de BPM Business Process Modeling Notation XML Process Definition Language Business Process Execution Language Las Herramientas BPMS BizAgi como herramienta BPM para los procesos de negocio Fases de BizAgi Ventajas de las tecnologías BPM Arquitectura Orientada a Servicios Los Servicios Web como la base fundamental de SOA NET Framework para el desarrollo de los servicios web Visual Studio 2010 como entorno de desarrollo EntityFrameWork Windows CommunicationFoundation Oracle como gestor de base de datos Integración de BPM y SOA Conclusiones Capítulo 2: Modelo del Negocio Introducción Actores del negocio Trabajadores del negocio Diagrama de casos de usos del negocio Descripción de los Casos de uso del negocio. Diagramas de actividad por cada caso de uso CU: Solicitar Combustible CU: Solicitar Transporte CU: Elaborar Plan de Transportación Semanal CU: Solicitar Documentos de control de medios CU: Solicitar Plan de Mantenimiento Reglas del negocio a considerar Modelo de Objetos Conclusiones Capítulo 3. Modelación del sistema Introducción Requisitos funcionales Actores del sistema a automatizar Diagrama de casos de uso del sistema Identificación de los servicios en los Procesos de Negocio Definición de los requisitos no funcionales Descripción de los casos de uso del sistema Conclusiones Capítulo 4. Descripción de la solución propuesta Introducción Definición de la arquitectura Patrones de Diseño Patrones de Diseño Creacionales Patrones de Diseño Estructurales Mecanismos de Diseño Diagrama de clases de los servicios diseñados Diseño de la base de datos Procesos de negocio VIII

9 Refinamiento de los procesos de Negocio Definición de los datos de los procesos Creación de formularios Creación de reglas de negocio y eventos Asignación de participantes Mapeo de datos con los servicios Modelo de despliegue de la solución Validación de la solución a través del proceso Solicitar transporte Definición de indicadores del proceso Capítulo 5. Estudio de factibilidad Introducción Planificación basada en casos de uso Calcular los Puntos de Casos de Uso Calcular los Puntos de Casos de Usos Ajustados Calcular el Esfuerzo de desarrollo (E) Estimación del tiempo de desarrollo del proyecto Estimación del costo de desarrollo del proyecto Beneficios tangibles e intangibles Beneficios tangibles Beneficios intangibles Análisis de costos y beneficios Conclusiones Conclusiones Recomendaciones Referencias Bibliográficas Glosario de Términos Anexos IX

10 ÍNDICE DE FIGURAS Figura 1Cap.1. Representación de los elementos básicos de un proceso de negocio. [10]... 9 Figura 2Cap.1.Fases del ciclo de vida de BPM. [13] Figura 3Cap.1. Componentes de un proceso de negocio. [19] Figura 4Cap.1. Fases de BizAgi. [20] Figura 5Cap.1. Los Servicios Web en funcionamiento. [23] Figura 6Cap.1.Cliente de WCF y de servicios. [27] Figura 7 Cap.2.Diagrama de Casos de Uso del Negocio Figura 8 Cap.2.Diagrama de actividad del Caso de Uso Solicitar Combustible Figura 9 Cap.2. Diagrama de actividad del caso de uso Solicitar Transporte Figura 10 Cap.2.Diagrama de actividad del Caso de Uso Solicitar elaboración del Plan de Transportación Semanal Figura 11 Cap.2.Diagrama de actividad del Caso de Uso Solicitar Documentos de control de medios Figura 12 Cap.2.Diagrama de actividad del Caso de Uso Solicitar Plan de Mantenimiento Figura 13 Cap.2.Modelos de Objetos del Negocio Figura 14 Cap.3.Casos de Uso del Sistema del actor Jefe de Transporte Figura 15 Cap.3.Casos de Uso del Sistema del actor Secretaria Figura 16 Cap.3.Casos de Uso del Sistema del actor Jefe de Programa Figura 17 Cap.3.Modelo del Proceso de Negocio Solicitar Transporte Figura 18 Cap.3.Modelo del Proceso de Negocio Planificar Transporte Figura 19 Cap.3.Modelo del Proceso de Negocio Asignar Combustible Figura 20 Cap.3.Modelo del Proceso de Negocio Elaborar Plan de Mantenimiento Figura 21 Cap.3. Modelo del Proceso de Negocio Elaborar Ficha de los vehículos Figura 22 Cap.3.Modelo del Proceso de Negocio Solicitud de transporte imprevista Figura 23 Cap.4.Arquitectura de la solución propuesta Figura 24 Cap.4.Diagrama de clases de los servicios Figura 25 Cap.4.Modelo Lógico de los datos Figura 26 Cap.4.Modelo Físico de los datos Figura 27 Cap.4.Modelo refinado del Proceso de Negocio Solicitar Transporte Figura 28 Cap.4.Modelo del Proceso de Negocio Planificar Transporte Figura 29 Cap.4.Modelo del Proceso de Negocio Asignar Combustible Figura 30 Cap.4.Modelo del Proceso de Negocio Elaborar Plan de Mantenimiento Figura 31 Cap.4.Modelo del Proceso de Negocio Solicitud Imprevista Figura 32 Cap.4.Modelo del Proceso de Negocio Elaborar Ficha de Vehículo Figura 33 Cap.4. Modelo de Datos de los Procesos Figura 34 Cap.4. Eventos de la Actividad Figura 35 Cap.4. Asignación de responsabilidad al actor Secretaria Figura 36 Cap.4. Modelo de despliegue de la solución Figura 37 Cap.4. Solicitud realizada con éxito Figura 38 Cap.4. Formulario para llenar la Solicitud de Transporte Figura 39 Cap.4. Bandeja de entrada del Jefe de Programa Figura 41 Cap.4. Formulario para aprobar la Solicitud de Transporte X

11 ÍNDICE DE TABLAS Tabla 1Cap.2. Descripción de Actores del Negocio Tabla 2 Cap.2. Descripción de Trabajadores del Negocio Tabla 3 Cap.2. Descripción del Caso de Uso Solicitar Combustible Tabla 4 Cap.2. Descripción del Caso de Uso Solicitar Transporte Tabla 5 Cap.2. Descripción del Caso de Uso Elaborar Plan de transportación semanal Tabla 6 Cap.2. Descripción del Caso de Uso Solicitar Documentos de control de medios Tabla 7 Cap.2. Descripción del Caso de Uso Solicitar Plan de Mantenimiento Tabla 8 Cap.3. Descripción de Actores del sistema Tabla 9 Cap.3. Servicios identificados en el proceso Solicitar Transporte Tabla 10 Cap.3. Servicios identificados en el proceso Planificar Transporte Tabla 11 Cap.3. Servicios identificados en el proceso Asignar Combustible Tabla 12 Cap.3. Servicios identificados en el proceso Elaborar Plan de Mantenimiento Tabla 13 Cap.3. Servicios identificados en el proceso Elaborar Ficha de los vehículos Tabla 14 Cap.3. Servicios identificados en el proceso Solicitud de transporte imprevista Tabla 15 Cap.3. Descripción del Caso de Uso del sistema Gestionar Vehículos Tabla 16 Cap.3. Descripción del Caso de Uso del sistema Gestionar Choferes Tabla 17 Cap.3. Descripción del Caso de Uso del sistema Gestionar Parqueos Tabla 18 Cap.3. Descripción del Caso de Uso del sistema Gestionar Órganos Tabla 19 Cap.3. Descripción del Caso de Uso del sistema Gestionar Combustible Tabla 20 Cap.3. Descripción del Caso de Uso del sistema Elaborar Plan de Mantenimiento Tabla 21 Cap.3. Descripción del Caso de Uso del sistema Asignar Combustible Tabla 22 Cap.3. Descripción del Caso de Uso del sistema Elaborar Ficha de Vehículo Tabla 23 Cap.3. Descripción del Caso de Uso del sistema Elaborar Plan de Transporte Tabla 24 Cap.3. Descripción del Caso de Uso del sistema Registrar Solicitud Tabla 25 Cap.3. Descripción del Caso de Uso del sistema Aprobar Solicitud Tabla 26 Cap.4. Formularios utilizados en el sistema Tabla 27Cap.5. Factor de Peso de los Actores sin ajustar Tabla 28 Cap.5. Factor de Peso de los Casos de Uso sin ajustar Tabla 29 Cap.5. Factor de Complejidad Técnica Tabla 30 Cap.5. Factor de Ambiente Tabla 31 Cap.5. Estimación del esfuerzo Tabla 32 Cap.5. Resumen de valores estimados XI

12 INTRODUCCIÓN Introducción A través de una colaboración entre el Ministerio del Interior (MININT) y el Centro Universitario José Antonio Echevarría (CUJAE), además de otras entidades, surge el Complejo de Investigaciones Tecnológicas Integradas (CITI). El CITI tiene como visión ser una organización creativa, innovadora y un punto de referencia según la aplicabilidad de los resultados que obtenga en el desarrollo de tecnologías. Para proyectar esta visión, la dirección del CITI observó la importancia que tiene la gestión por procesos, estos hacen posible un mejor funcionamiento del mismo, los cuales son clasificados en estratégicos, claves y de apoyo. Este trabajo se centra en las actividades que se realizan en el proceso de transporte que es un proceso de apoyo, por lo que la informatización de la transportación de la entidad es una de las principales tareas que pretende lograr la institución para un mejor funcionamiento de la misma. SITUACION PROBLEMÁTICA Y PROBLEMA A RESOLVER. El proceso de transporte del CITI es un aspecto vital para que la entidad cumpla con la satisfacción del personal en cuanto a la transportación del mismo. A pesar del avance tecnológico hoy en día en la institución el encargado del transporte realiza sus funciones empleando los métodos tradicionales, es decir, trabajos manuales o mediante documentos, esto hace que su trabajo se torne más complicado, lento y disminuya la calidad de este servicio. Dada estas circunstancias se presenta la siguiente situación problemática: Existe información que se encuentra en formato duro lo que provoca que haya un posible deterioro y posibles pérdidas de la misma, además se dificulta la ubicación de una determinada información que necesiten los directivos, así como las distintas áreas de la entidad a la hora de tomar decisiones. Por otro lado no hay un seguimiento exhaustivo de documentos importantes a través de las distintas etapas de tramitación. También existe información que se encuentra digitalizada pero no automatizada, es decir, información que es manejada en formatos de office como Excel, documentos Word, entre otros, que trae consigo que no se logre una integración con otros sistemas externos y se dificulte la posibilidad de realizar análisis estadísticos que ayuden en la toma de decisiones. No es posible una correcta planificación, organización y control que garantice los flujos básicos de traslado de personal, entrega y recepción de mercancía, así como el servicio a 1

13 INTRODUCCIÓN clientes y usuarios de la propia entidad. Las Solicitudes de transporte que realizan los trabadores del CITI se realizan a través de correos donde los datos de las solicitudes se almacenan en un formulario InfoPath y luego la secretaria del jefe de transporte debe almacenar esta solicitud formalmente en otro documento, para posteriormente enviárselas al jefe de transporte para su aprobación, lo que hace que este proceso sea más lento. Por otra parte no hay un mecanismo de persistencia de los datos que ayuden a realizar análisis estadísticos futuros. Además en ocasiones los datos de una determinada solicitud que se hace de manera imprevista, son mandados por escrito a la secretaria, la cual atiende la solicitud en ese momento sin tener en cuenta ninguna planificación de transporte, ni disponibilidad de los vehículos con los que cuenta la organización para cumplir con estas solicitudes ya que no se cuenta con un sistema que de soporte a estas actividades. No existe forma de monitorizar en qué estado se encuentran las solicitudes realizadas por los trabajadores en cuanto a las notificaciones que deben ser mandadas a los solicitantes, ya sean de rechazo o de cancelación. Dentro del proceso de transporte no hay una publicación de un plan de transporte donde se pueda ver las transportaciones que deben hacerse durante la semana de acuerdo a las solicitudes realizadas, por lo que hay pérdidas de información para el personal encargado de satisfacerlas que son los choferes de los vehículos que realizarán los recorridos solicitados. Dada esta situación problemática se identificó como problema a resolver cómo gestionar la explotación del transporte en el CITI de manera que se eleve la calidad del servicio prestado por el área en la entidad. OBJETO DE ESTUDIO El objeto de estudio se encuentra enmarcado en el funcionamiento del proceso de transporte en las organizaciones. CAMPO DE ACCIÓN Informatización del proceso de Trasporte en el CITI utilizando el enfoque BPM y la orientación a servicios. 2

14 INTRODUCCIÓN OBJETIVOS El objetivo general de este trabajo es informatizar el proceso de transporte en el CITI, de manera tal que se logre una integración con el resto de los sistemas existentes y la monitorización de los procesos de negocios. Para lograr este objetivo se identificaron los siguientes objetivos específicos: Definir una arquitectura para el desarrollo de la solución que permita cumplir con los siguientes aspectos: La integración con el resto de las aplicaciones existentes. La monitorización y control de los procesos de negocio. Desarrollar un sistema orientado a servicios para la gestión del transporte en el CITI. Diseñar y desplegar los procesos de negocio de transporte. Validar la solución propuesta. Para poder llevar a cabo los objetivos trazados se acometieron las siguientes tareas: Realizar entrevistas con el personal encargado del trasporte en la organización con vistas a capturar los requisitos funcionales. Identificar los procesos de negocios correspondientes a la gestión del transporte del CITI. Asimilar la suite BPM BizAgi para el despliegue de los procesos de negocio correspondientes al proceso de transporte de la organización. Desplegar los procesos de negocio identificados en el proceso de transporte, utilizando la suite BPM BizAgi. Identificar las tecnologías y herramientas existentes para el desarrollo de aplicaciones orientadas a servicios. Asimilar las tecnologías a utilizar para el desarrollo de los servicios web, tales como.net Framework y Oracle como gestor de Base de Datos. Realizar pruebas para la validación de la solución propuesta. 3

15 INTRODUCCIÓN VALOR PRÁCTICO Con la automatización del Proceso de Transporte en el CITI se lograun incremento en el número de actividades que se ejecutan en paralelo, y será posible la monitorización de los procesos de negocio. Las actividades que se llevan a cabo para realizar las solicitudes de transporte se realizarán de manera más sencilla, ya que el solicitante desde su computadora, sin necesidad de tener correo puede realizar su solicitud, y a su vez el jefe de transporte recibirla desde la suya y enviar una respuesta a los solicitantes, también el Jefe de transporte tendrá acceso a la información de las solicitudes que le llegan por parte de los distintos solicitantes en tiempo real, lo cual le facilitará la toma de decisiones con respecto a estas. Se gana en flexibilidad para la adaptación a cambios ya que con el uso del paradigma BPM se logra separar a los procesos de negocio de la gestión de software, permitiendo una reconfiguración rápida del sistema y reduciendo costos futuros de mantenimiento. Habrá una mayor interoperabilidad con sistemas externos lo que hace que se pueda acceder de manera sencilla a la información referente al transporte. Se logra una mayor escalabilidad ya que al hacer un repositorio de servicios web estos pueden ser reutilizados en aplicaciones futuras y aumenta la capacidad de mejoras en estas ya que se accede a los servicios sin necesidad de acceder a las aplicaciones. También se pueden emplear mecanismos de autenticación y autorización robustos en todos los servicios, y como éstos son independientes unos de otros, la estrategia de Service Oriented Architecture permite dotarse de un nivel de seguridad superior. 4

16 Capítulo 1 FUNDAMENTOS TEÓRICOS Capítulo 1: Fundamentos teóricos 1.1. Introducción En el presente capítulo se muestran aspectos teóricos que son necesarios tener en cuenta para lograr una mayor compresión del trabajo realizado. Se realiza una evaluación de la entidad para la cual va encaminado el trabajo, así como los objetivos estratégicos que persigue la organización. También se tratará en este capítulo los sistemas de transporte existentes y la importancia de crear un sistema de transporte para la entidad. Posteriormente se analizarán las herramientas y tecnologías que se emplearán para cumplir con los objetivos propuestos Descripción de la entidad El Complejo de Investigaciones Tecnológicas Integradas (CITI), es un proyecto coordinado entre el Centro Universitario José Antonio Echevarría (CUJAE), el Ministerio del Interior (MININT) y otras instituciones, vinculando las necesidades de superación científica de especialistas con las soluciones concretas y ágiles, mediante la ejecución de proyectos por grupos de trabajo flexibles. En el mismo se desarrollan tecnologías integradas de un amplio espectro de las ciencias técnicas, en interés de la seguridad y el orden interior. [1] Objetivos estratégicos de la Organización La misión del CITI es ser una organización de referencia en el desarrollo de proyectos investigativos y de desarrollo, así como un punto de referencia en la gestión del capital humano. Además tener elevados resultados en el desarrollo de sistemas, tecnologías y aplicaciones integradas novedosas con impacto en la seguridad y el orden interior. Para cumplir con esta misión el CITI cuenta con la integración de profesionales altamente calificados con estudiantes de talento. Para cumplir con estos requisitos se acometieron los siguientes objetivos [1]: 5

17 Capítulo 1 FUNDAMENTOS TEÓRICOS Aprovechar las potencialidades que ofrecen el MININT y la CUJAE y la integración de personal altamente calificado con personal joven para desarrollar proyectos de investigación de tecnologías de avanzada. Desarrollar proyectos de investigación efectivos aprovechando las condiciones de trabajo, atención al hombre adecuadas y un sistema de estimulación atractivo. Utilizar las potencialidades e integración de especialistas del MININT, la CUJAE y otras instituciones del país, en el aprovechamiento del equipamiento e información disponible en el centro, potenciando el desarrollo de tecnologías estables, probadas con tendencia a mantenerse en el futuro. Aprovechar el nivel científico del claustro para lograr la superación de los miembros de ambas instituciones hasta alcanzar altos niveles científicos y la introducción de resultados. Aprovechar las posibilidades de colaboración internacional de la CUJAE y del MININT para la formación del capital humano en la asimilación de sistemas, equipamiento de última generación e información científico técnica existente, vinculada con los proyectos de investigación de tecnologías de avanzada Sistemas existentes para la gestión del transporte Se han realizado estudios con el objetivo de identificar y analizar soluciones que de alguna manera estén relacionadas con el tema que ocupa este trabajo. Como resultado de esto se han encontrado, entre otros, los siguientes sistemas de transporte: Transcar, TranSys, el sistema de gestión del transporte (TMS) y JR-Software. De manera general estos sistemas presentan módulos importantes para la gestión del transporte, tales como: Clientes-Proveedores Tarjetas-Teléfonos-Rutas Control de Pallets(Gestión de Almacén) Liquidaciones (Tesorería) Multiusuario y Multiempresa Conductores-Vehículos Consumo de gasolina-multas-gastos e Ingresos 6

18 Capítulo 1 FUNDAMENTOS TEÓRICOS Como se puede observar estos sistemas presentan módulos importantes con respecto a la gestión de vehículos, choferes, viajes, entre otros, pero estos no cumplen con los requisitos específicos que necesita el sistema de transporte para la organización. En ninguno encontramos un proceso de solicitud de transporte de la manera en que el CITI lo necesita, tampoco en estos sistemas existe la funcionalidad para la asignación de combustible de los vehículos. Los recorridos de los viajes son fijos desde la empresa a la ubicación de los clientes, por lo que la planificación de las transportaciones se hacen a largo plazo, en el CITI la planificación debe ser semanalmente. Además no existe un seguimiento de los vehículos en cuanto a la cantidad de kilómetros recorridos para darle mantenimiento en un momento determinado. Por estas razones es necesario desarrollar un sistema de transporte que cumpla con los requisitos necesarios para la organización que ayude a planificar y organizar el trabajo del Jefe de Transporte, así como dotar a la entidad de un mejor funcionamiento mejorando la calidad de servicio en área de transporte Gestión del Transporte en el CITI El proceso de transporte en CITI actualmente cuenta con dos subprocesos fundamentales: Transportación y Transporte. El subproceso de Transportación consiste en todo lo referente a las transportaciones tanto de carga como de personal. Estas transportaciones se realizan de acuerdo a las solicitudes de transporte que realizan los trabajadores de la entidad, las que luego son mandadas a la secretaria del jefe de transporte para realizar el plan de transportación de cada semana. Las solicitudes que se planifican son aquellas que llegan los viernes de cada semana, aunque hay que destacar que llegan solicitudes de manera imprevista, las cuales son atendidas en el momento y luego son registradas formalmente en un documento. En el subproceso de Transporte es donde se realizan las actividades que tienen que ver con los vehículos con los que cuenta la organización para realizar las transportaciones. Es donde se realiza la asignación de combustible a dichos vehículos, una vez que estos han recorrido una cierta cantidad de kilómetros se les debe dar mantenimiento para saber cuántos kilómetros están listos estos vehículos para recorrer a partir de ese momento. Como parte de este subproceso además se generan documentos importantes sobre el control de los medios de transporte, así como la relación de los choferes con correspondientes vehículos. 7

19 Capítulo 1 FUNDAMENTOS TEÓRICOS 1.4. Procesos de Negocio Los procesos de negocio se encuentran implícitamente dentro de las actividades que llevan a cabo las organizaciones para cumplir con sus objetivos. Para las instituciones estos procesos en la mayoría de las veces, resultan ser poco comprensibles en cuanto a su funcionamiento interno, debido a que son difíciles de definir formalmente, lo que se torna complicado trabajar sobre ellos para mejorarlos. En la actualidad las organizaciones han encontrado la manera de mejorar estos procesos con el uso de aplicaciones dirigidas fundamentalmente a la gestión por procesos. [7] Definiciones de proceso de negocio Existen diversas definiciones sobre los procesos de negocio, a continuación se mostrarán algunas de estas: Conjunto estructurado de actividades diseñadas para producir una salida o lograr un objetivo, describen cómo es realizado el trabajo en la empresa, son observables, medibles, repetitivos y susceptibles de mejora.[7] Colección de actividades relacionadas, estructuradas una cadena de eventos- que producen un servicio específico o producto específico para un cliente en particular o para varios clientes. [8] Actividades o procedimientos que en conjunto cumplen un objetivo específico del negocio o metas de más largo alcance, en el contexto de una estructura organizacional definiendo roles funcionales y relaciones. [9] Llevando a cabo el análisis de estas definiciones se pude decirse que un proceso de negocio es un grupo de actividades lógicamente ordenadas con el objetivo de obtener resultados que aporten un valor a la organización, sus inversores o sus clientes cumpliendo con las políticas establecidas por dicha organización. 8

20 Capítulo 1 FUNDAMENTOS TEÓRICOS Figura 1Cap.1. Representación de los elementos básicos de un proceso de negocio. [10] El actor es el elemento encargado de realizar la actividad. Pueden ser individuos, grupos de personas o departamentos organizacionales. El objetivo de una actividad es una característica propia que indica el propósito de su existencia dentro del proceso de negocio al que pertenece. En general un recurso es todo aquello que es usado o afectado por las actividades. A menudo son considerados como entradas, salidas o resultados, o herramientas. [10] Según la consultora CSC los procesos de negocios pueden ser clasificados en: [10] Complejos: Involucran flujo de materiales, información y compromisos de negocio. Dinámicos. Responden a la demanda de clientes y condiciones cambiantes del mercado. Distribuidos y personalizados. A menudo avanzan a través de múltiples aplicaciones con diferentes plataformas tecnológicas dentro y entre negocios. Duración Prolongada. Un flujo de proceso puede durar meses, incluso años. A veces automatizados, aunque sea parcialmente. Las actividades rutinarias deberían ser llevadas a cabo por computadoras siempre y cuando sea posible, con el objetivo de ganar en agilidad y confiabilidad. Dependen de la inteligencia y juicio de las personas. Las personas llevan a cabo tareas no estructuradas difíciles de delegar a una computadora o que requieren interacción personal con clientes. Difíciles de visibilizar. En muchas empresas no se tiene conciencia explícita de los procesos, a menudo no están documentados pero si embebidos en la historia de la organización. 9

21 Capítulo 1 FUNDAMENTOS TEÓRICOS Gestión de Procesos de Negocio La Gestión de Procesos de Negocio (en inglés Business Process Management) constituye el más moderno y ambicioso esfuerzo de la técnica de software empresarial para abordar la automatización y optimización del funcionamiento de las empresas. Con la utilización de BPM las organizaciones pueden dotarse de una eficacia que les permita sobrevivir, prosperar y dar el adecuado servicio en el mundo actual de intensa competencia y constantes cambios. [11] Van der Aalst define la Gestión de Proceso de Negocios como: "Soporte de procesos de negocios usando métodos, técnicas y software para diseñar, representar, controlar y analizar los procesos operacionales de que involucran organizaciones, aplicaciones, documentos y otras fuentes de información".[12] Fases del Ciclo de vida de BPM La gestión de los procesos de negocio se lleva a cabo en las organizaciones siguiendo una línea de trabajo basada en una serie de etapas y actividades que se establecen dentro del ciclo de vida de BPM (Figura 3). Esto hace posible alcanzar de forma eficaz, todos los objetivos y beneficios perseguidos por BPM. Muchas han sido las propuestas sobre estas fases pero la mayoría coinciden con las que se muestran a continuación:[13] Figura 2Cap.1.Fases del ciclo de vida de BPM. [13] 10

22 Capítulo 1 FUNDAMENTOS TEÓRICOS Descripción de las fases del ciclo de vida de BPM Diseño: En esta fase se identifican los procesos actuales de la empresa, estableciéndose el alcance del proceso y el respectivo proyecto de diagramación. Luego se procede a la descripción del o los procesos objetos de reingeniería. Se crea el proceso ideal, desarrollando un conjunto de pruebas, y una vez lograda la aprobación y consenso de los responsables de llevar a cabo estas pruebas, se desarrolla un plan de acción para su implantación y puesta en servicio. [13][14][10] Modelado: Los procesos existentes son desarrollados, indicando quién, qué, cuándo y cómo deben ejecutarse las actividades diseñadas. La modelación o modelado dirige el esfuerzo BPM porque brinda un mapa que usuarios de negocio y especialistas de TI pueden entender. [13][14][10] Ejecución: Los nuevos procesos son llevados a cabo por personas, organizaciones, sistemas y otros procesos. Coexisten sistemas nuevos y legados, y el estado de la ejecución queda fuera de las tecnologías de implementación subyacentes. [13][14][10] Monitorización: Cada proceso de negocio debe ser medible para saber el grado de éxito y calidad con el que ha sido llevado a cabo; de esta forma, se pueden analizar los resultados de cada uno de los procesos para que puedan ser redefinidos y optimizados. [13][14][10] Optimización: Aquellos procesos que no han cumplido las expectativas deseadas, bien porque no poseen un conjunto coherente de tareas, o porque las necesidades han cambiado, son optimizados para que puedan mejorar su rendimiento y también el de la empresa. [13][14][10] Estándares de BPM Para cumplir con las actividades que se desarrollan durante el ciclo de vida BPM, han surgido algunos estándares como son Business Process Modeling Notation (BPMN), XML Process Definition Language (XPDL), Business Process Execution Language (BPEL), entre otros, de los cuales se muestran algunas de sus características a continuación. 11

23 Capítulo 1 FUNDAMENTOS TEÓRICOS Business Process Modeling Notation Business Process Modeling Notation (BPMN) es un estándar para modelar procesos de negocio. Fue creado con el propósito de proveer una notación legible y comprensible por todos los usuarios de un negocio, incluyendo analistas y desarrolladores técnicos encargados de implementar dichos procesos. [15] BPMN proporciona a los negocios la capacidad de entender sus procedimientos internos en una notación gráfica, facilitando a las organizaciones la habilidad para comunicar esos procedimientos de una manera estándar. [16] Los objetivos fundamentales de BPMN son: [16] Proveer una notación que sea fácilmente entendida por todos los usuarios, desde el analista de negocio, el desarrollador técnico, hasta un propio trabajador del negocio. Crear un puente estandarizado para el vacío existente entre el diseño del proceso de negocio y su implementación. Definir la notación y semántica de un Diagrama de Procesos de Negocio XML Process Definition Language XPDL es un lenguaje difundido por la WfMC (Workflow Management Coalition). XPDL forma parte de la primera interfaz, la cual da soporte a la definición y a la importación/exportación de procesos, con el objetivo de que, aunque se modele el proceso en una aplicación, este modelo pueda ser usado por otras aplicaciones de modelado y/o por otras aplicaciones que trabajen en el entorno de ejecución. [17] Business Process Execution Language BPEL, Business Process Execution Language es un lenguaje estándar de ejecución de procesos de negocio propuestos por OASIS para especificar interacción entre servicios web con la importación y exportación de información con el uso exclusivo de las interfaces de dichos servicios. Así las facilidades de mensajería de BPEL dependen del uso de 12

24 Capítulo 1 FUNDAMENTOS TEÓRICOS Lenguaje de Descripción de Servicios Web (WSDL según sus siglas en inglés) para describir mensajes entrantes y salientes. [18] Las Herramientas BPMS La tecnología que posibilita la implantación y adopción de BPM constituye una categoría nueva de sistemas de información denominados Business Process Mangement Systems (BPMS).Un BPMS incluye todos los módulos, capacidades técnicas y la infraestructura de apoyo integrado en un único entorno para realizar todas las funciones de la tecnología BPM. [19] Estas herramientas BPMS persiguen el objetivo de extraer los procesos de las diferentes aplicaciones de software y almacenarlos en un repositorio, las aplicaciones que apoyen estos procesos deberán acceder a este repositorio para consultarlos y trabajar sobre ellos, integrando la información de la organización a un nivel mucho más elevado. En la figura siguiente se muestran los principales componentes de un proceso de negocio. [19] Figura 3Cap.1. Componentes de un proceso de negocio. [19] 13

25 Capítulo 1 FUNDAMENTOS TEÓRICOS BizAgi como herramienta BPM para los procesos de negocio Luego de un estudio realizado en trabajos anteriores sobre las distintas herramientas BPMS como Intalio, Bonita y BizAgi, se llegó al acuerdo del empleo de la BPMS BizAgi para la introducción de tecnologías BPM en el centro. BizAgi es el ambiente de construcción con el cual se transforman los procesos de negocio diseñados en aplicaciones ejecutables sin necesidad de programación. Esta herramienta ofrece un conjunto de funcionalidades que permiten definir gráficamente el modelo asociado a un proceso de negocio (flujos, reglas de negocio, interfaz de usuario, entre otras.). Este modelo se almacena en una base de datos y es interpretado y ejecutado en producción por el BPM Server de BizAgi. [20] El siguiente gráfico muestra las fases de construcción del Modelo del Proceso utilizando BizAgi: Figura 4Cap.1. Fases de BizAgi. [20] Fases de BizAgi Las fases que soporta BizAgi son las siguientes [20]: Modelación del Proceso: El modelado del proceso es uno de los primeros pasos en la implementación con BizAgi. Esta etapa es fundamental debido a que la aplicación se 14

26 Capítulo 1 FUNDAMENTOS TEÓRICOS define basándose en el flujo del proceso que se haya modelado. El flujo de trabajo, conocido como una cadena de actividades, es la estructura fundamental del proyecto en donde las variables y elementos necesarios son incluidos de acuerdo con los requerimientos de la organización. BizAgi hace uso del lenguaje de BPMN para la diagramación y modelamiento de los procesos, el cual provee una notación común para que las personas relacionadas con los procesos puedan expresarlos gráficamente en una forma más clara, estandarizada y completa. Datos del Proceso: Una vez el proceso es modelado y de acuerdo con la estructura de datos definida en la fase de diseño de la metodología BizAgi, se crea el modelo relacional del proceso. El modelo relacional especifica las entidades y los atributos, y las relaciones que existen entre estos, permitiendo agrupar la información de una manera simple y lógica. BizAgi no sólo permite a las organizaciones modelar y entender el modelo entidad-relación rápidamente, sino que además garantiza la integración de la información en el contexto indicado del flujo para que el proceso pueda ejecutarse satisfactoriamente. Este modelo de datos permitirá la correcta administración de la información, el fácil modelamiento, flexibilidad en caso de cambios y rapidez en las consultas. Creación de Formularios: Una vez creado el modelo relacional del proceso y de acuerdo con las formas o pantallas definidas en la fase de diseño dentro de los pasos que propone BizAgi, se procede con la creación de los formularios, los cuáles serán visualizados en una aplicación web por el usuario final. Estos formularios o pantallas muestran la información del proceso (campos, tablas, vínculos, etc. que se complementan con validaciones o restricciones para acceder, modificar o completar la información), propiedades de apariencia y otras variables. Como resultado de este paso, el usuario final visualiza pantallas donde se solicita cierta información de acuerdo con la actividad que se está ejecutando durante el flujo del proceso o pantallas donde se consulta la información del negocio. Reglas de Negocio: Las organizaciones se rigen por ciertas políticas o normas, las cuales se derivan de las diferentes estrategias y objetivos de las empresas. Como resultado, existen restricciones, excepciones y una gran variedad de condiciones en las 15

27 Capítulo 1 FUNDAMENTOS TEÓRICOS diferentes actividades o tareas que conforman el proceso. BizAgi ofrece una herramienta gráfica para modelar con facilidad reglas de negocio, utilizando el concepto de Xpath como mecanismo para estandarizar el lenguaje de la herramienta y hacer que el manejo de reglas de negocio sea más intuitivo. El Xpath permite acceder a cualquier dato que esté en el modelo relacional del proceso sin necesidad de conocer lenguajes de programación. En BizAgi, las reglas de negocio están vinculadas al diagrama de flujo y se pueden modificar o consultar por cualquier persona que esté familiarizada con el proceso, lo que permite que en el futuro no se presenten inconvenientes en la adaptabilidad y escalabilidad de la herramienta. Asignación de Participantes: La Asignación de Recursos es un paso de gran importancia dentro del modelamiento de BizAgi. En este paso se configuran las condiciones para que usuarios con perfiles determinados realicen las actividades dentro del proceso, de acuerdo con las especificaciones definidas en la fase de diseño. En la configuración de los perfiles para las diversas condiciones de asignación que se pueden cumplir para una actividad se tienen en cuenta variables como habilidades, roles, cargos, ubicaciones, áreas, entre otras, que tienen las personas dentro de la organización. Como resultado de la configuración de las asignaciones, BizAgi asigna actividades inteligentemente a los diferentes miembros de la empresa. Esto identifica los usuarios que cumplen los perfiles definidos de acuerdo con las condiciones de asignación y aplica el método de asignación, generando actividades pendientes a los usuarios que queden como responsables. Integración: BizAgi como solución BPM entiende la necesidad inherente de que los procesos de negocio interactúen con otros sistemas existentes dentro de la organización, tales como sistemas CRM, ERP y legados, por lo cual utilizan la capa SOA para manejar información de sistemas externos dentro de un determinado proceso de negocio Ventajas de las tecnologías BPM Los BPMS deben reunir tres requerimientos fundamentales: Flexibilidad, Fiabilidad y Seguridad, pero además deben contar con otros como: capacidades de escalabilidad, alto 16

28 Capítulo 1 FUNDAMENTOS TEÓRICOS rendimiento, tolerancias a fallos y calidad de servicio. Cumpliendo la BPMS con esos requerimientos aportará las siguientes ventajas [21]: Mejor repartición del trabajo: Con la asignación de roles y usuarios se garantiza que en el proceso haya una colaboración del personal de manera continua. Mejor satisfacción para los clientes: Al agilizar los procesos de negocio se obtienen resultados para los clientes en menos tiempo. Rapidez y mayor agilidad en el trabajo: El uso de las tecnologías BPM aumenta el número de actividades que pueden ser ejecutadas en paralelo por una persona, lo que posibilita atender varios procesos a la vez sin necesidad de esperar por el término de uno para el comienzo de otro. Mayor flexibilidad para adaptación al cambio. Un BPMS separa el proceso de negocio de la gestión del software, permitiendo una reconfiguración rápida del proceso y reduciendo costos futuros de mantenimiento. Por otra parte, las aplicaciones tradicionales embeben los procesos de manera rígida dentro del código y las tablas de las bases de datos, haciendo que los cambios sean complejos y costosos. Permiten una integración global con otras aplicaciones de esta manera se comparte información entre estas aplicaciones de forma estrechamente integrada, mejorando la eficiencia de los procesos y su flexibilidad para el cambio. Uno de los elementos importantes en BPM es la integración con sistemas externos. La integración de sistemas de información representa un reto en las organizaciones. Orquestar de la mejor manera plataformas heterogéneas y aplicaciones empresariales construidas sobre diferentes tecnologías adiciona niveles de complejidad que, a la hora de la interacción coordinada entre diferentes actores, puede requerir esfuerzos considerables para alcanzar el éxito. No obstante, los mecanismos de integración evolucionan a la par con las técnicas de arquitectura de software que hacen posible interconectar varias aplicaciones, con esfuerzos cada vez más reducidos en cuanto a tiempos y cantidad de desarrollo requerido para lograrla. Un significativo avance es la aplicación del estilo de arquitectura SOA, donde las aplicaciones rompen su paradigma monolítico y exponen cierta parte de su funcionalidad como servicios para que otros sistemas puedan invocar en forma sencilla las funcionalidades expuestas [14]. 17

29 Capítulo 1 FUNDAMENTOS TEÓRICOS 1.5. Arquitectura Orientada a Servicios La Arquitectura Orientada a Servicios o SOA, es la vía para el desarrollo de aplicaciones y procesos de negocio cumpliendo con aspectos vitales tales como: reutilización, flexibilidad e integración. La esencia de la orientación a servicios es sustituir aquellas aplicaciones grandes y complejas por sencillos servicios web que junto a otros ya implementados se logre crear aplicaciones flexibles y una alta capacidad de adaptación a cambios. [22] SOA es definida como una propuesta de diseño para la integración de diferentes aplicaciones. Permite que estas aplicaciones intercambien información y participen en procesos de negocio, a través de servicios disponibles en la red, sin importar la plataforma o el lenguaje de programación en que fueron desarrolladas. [22] Es importante destacar que no es posible referirse a SOA sin mencionar lo que sustenta esta arquitectura, que son los servicios web, ya que a través de ellos es como se accede a la información que aportan otros sistemas Los Servicios Web como la base fundamental de SOA Uno de los retos fundamentales para las organizaciones en la actualidad es el hecho de no poseer integración entre las diferentes aplicaciones que apoyan el trabajo de estas instituciones. Por tal motivo el medio utilizado para este reto fue buscar una solución estándar que logre esta integración, es entonces que nacen los llamados servicios web basados en estándares Extensible Markup Language (XML). El consorcio W3C define los servicios web como software diseñado para soportar una interacción interoperable máquina a máquina sobre una red. Los servicios web suelen ser APIs web que pueden ser accedidas dentro de una red (principalmente internet) y son ejecutados en el sistema que los aloja. En el siguiente gráfico se muestra un ejemplo del intercambio de información entre aplicaciones de una agencia de viajes.[23] 18

30 Capítulo 1 FUNDAMENTOS TEÓRICOS Figura 5Cap.1. Los Servicios Web en funcionamiento. [23] En todo este proceso intervienen una serie de tecnologías estandarizadas que hacen posible la circulación de información. Una de las más significativas es el Protocolo Simple de Acceso a Objetos (SOAP según sus siglas en inglés). SOAP es un protocolo basado en XML, que permite el intercambio de mensajes entre aplicaciones y tiene la capacidad de transmitir información. Los datos pueden ser transmitidos a través de HTTP, HTTPS, SMTP, entre otros, especificando SOAP el formato de estos mensajes. [23] Otro estándar importante para el manejo de servicios esel Lenguaje de Descripción de servicios (WSDL por sus siglas en inglés), el cual contiene los detalles de transporte de mensajes y su contenido. En el WSDL podemos encontrar un determinado servicio que se esté invocando en eso momento, así como los métodos que facilita dicho servicio, además de los parámetros de entrada de cada uno de estos métodos. También podemos saber los tipos de datos que se están manejando, y la forma en que se debe acceder al servicio. [23] NET Framework para el desarrollo de los servicios web La plataforma de desarrollo.net podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web. Su propuesta es ofrecer una manera rápida y económica, a la vez que segura y robusta, de desarrollar aplicaciones permitiendo una integración más rápida y ágil entre empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo. El.NET 19

31 Capítulo 1 FUNDAMENTOS TEÓRICOS Framework contiene dos componentes principales: El Entorno Común de Ejecución para Lenguajes o Common Language Runtime (CLR) y la biblioteca de clases base o BCL. [24] Common Language Runtime (CLR): Este es el lenguaje insignia de.net Framework (marco de trabajo.net) y pretende reunir las ventajas de lenguajes como C, C++ y Visual Basic en uno solo. El CLR es el verdadero núcleo del framework de.net, entorno de ejecución en el que se cargan las aplicaciones desarrolladas en los distintos lenguajes, ampliando el conjunto de servicios del sistema operativo. [24] Biblioteca de Clases Base de.net (BCL): La Biblioteca de Clases Base (BCL por sus siglas en inglés) maneja la mayoría de las operaciones básicas que se encuentran involucradas en el desarrollo de aplicaciones, incluyendo entre otras: [24] Manejo de datos (ADO.NET) Transmisión y recepción de datos por distintos medios (XML, TCP/IP) Administración de componentes Web que corren tanto en el servidor como en el cliente (ASP.NET) Manejo y administración de excepciones Herramientas de seguridad e integración con la seguridad del sistema operativo Interacción con otras aplicaciones Generación de código Compilación de código Visual Studio 2010 como entorno de desarrollo Microsoft Visual Studio 2010 incluye herramientas que simplifican el proceso de desarrollo de aplicaciones. Los equipos de trabajo pueden utilizar características de colaboración avanzadas con el objetivo de alcanzar una mayor productividad y ahorro de costes. A continuación se muestran algunas de sus características que motivaron dicha elección. Desarrollo de bases de datos Visual Studio 2010 proporciona herramientas de implementación y administración de cambios que garantizan que la base de datos y la aplicación estén siempre sincronizadas. Compatibilidad con la plataforma de desarrollo 20

32 Capítulo 1 FUNDAMENTOS TEÓRICOS Crea soluciones nuevas para el mejoramiento de las aplicaciones ya existentes, además permite hacerlas en una gran variedad de plataformas, entre las que se incluyen Windows, Windows Server, Web, Office y SharePoint, todo en un único entorno de desarrollo integrado EntityFrameWork El Entity Framework es un set de tecnologías en ADO.NET que ayuda a rellenar el espacio entre el desarrollo orientado a objetos y bases de datos. Los resultados son devueltos como objetos, y a diferencia de otras opciones de acceso de datos, el desarrollador no tiene que perder tiempo sacando en claro filas y columnas en los resultados devueltos justamente para crear los objetos, sino que desde que los resultados son devueltos como los objetos, este trabajo está automáticamente hecho.[26] Uno de los componentes más importantes de EntityFrameWork es el Entity Data Model que no equivale al modelo de la base de datos, sino que describe la estructura de los objetos del negocio en cuestión. Este componente permite a partir de una base de datos generar un modelo conceptual para trabajar orientado a objetos, es decir, ya no es necesario hacer clases que simulen el comportamiento de la base de datos. Además permite realizar el proceso a la inversa, es decir, a partir de un modelo conceptual generar la base dato correspondiente. [26] Windows Communication Foundation Windows Communication Foundation (WCF) también conocido como Índigo, es la plataforma para la creación de servicios distribuidos que, en su primera versión incorpora el Framework 3.0 de.net.wcf fue creado con el fin de permitir una programación rápida de sistemas distribuidos y el desarrollo de aplicaciones basadas en arquitecturas orientadas a servicios. Simplifica el desarrollo de aplicaciones conectadas a través de un nuevo modelo de programación orientada a servicios.wcf admite muchos estilos de desarrollo de aplicaciones distribuidas, proporcionando una arquitectura en capas. [27] 21

33 Capítulo 1 FUNDAMENTOS TEÓRICOS Figura 6Cap.1.Cliente de WCF y de servicios. [27] La figura muestra una vista de un cliente de WCF y de servicios. Los dos interactúan utilizando SOAP Oracle como gestor de base de datos Oracle por su estabilidad, escalabilidad y su capacidad de operar en una gran cantidad de sistemas operativos, es considerado uno de los gestores de base de datos más completos hoy en día. Es un gestor con una alta eficiencia en cuanto a la concurrencia de múltiples usuarios. [29] Oracle es un gestor de base de datos, donde los datos se encuentran almacenados y accesibles según el formato de tablas relacionales. Una tabla relacional tiene un nombre y unas columnas, su definición. Los datos están almacenados en las filas. Las tablas pueden estar relacionadas con otras. Entre sus características principales se encuentran las siguientes [30]: Ayuda a analizar datos y efectuar recomendaciones concernientes a mejorar el rendimiento y la eficiencia en el manejo de aquellos datos que se encuentran almacenados. Apoya en el diseño y optimización de modelos de datos. Asistir a los desarrolladores con sus conocimientos de SQL y de construcción de procedimientos almacenados y triggers, entre otros. Apoya en la definición de estándares de diseño y nomenclatura de objetos. La utilización de Oracle como gestor de base de datos constituye un requisito no funcional de la organización, ya que el CITI impone el desarrollo de sus sistemas utilizando este gestor. 22

34 Capítulo 1 FUNDAMENTOS TEÓRICOS 1.6. Integración de BPM y SOA SOA es una arquitectura esencial que brinda mayor flexibilidad a la infraestructura de las empresas, además proporciona la plataforma que funciona como puente entre los procesos de negocio y los sistemas heredados. Para el nivel de procesos de negocio, SOA provee las interfaces que soportan la ejecución de las tareas de procesos de negocio. Por su parte la estrategia de BPM se centra en las actividades de la empresa con el fin de vigilar su óptima ejecución. De esta manera, SOA y BPM son la perfecta combinación, puesto que la primera permite ligar los sistemas de las empresas y nivelar de manera coherente los estándares necesarios, mientras que la segunda coloca de manera adecuada cada pieza involucrada en los procesos. [31] SOA facilita la tarea de conectar los procesos del negocio a los sistemas subyacentes, ahorrando en tiempo y en recursos tecnológicos, mientras que BPM puede ayudar a perfeccionar dichos procesos y es capaz de guiar a los sistemas para lograr lo que se necesita. [31] 1.7. Conclusiones En el capítulo que concluye se analizaron los objetivos estratégicos del CITI como una organización de referencia con respecto al campo tecnológico. Se vio la importancia que tiene desarrollar el sistema de transporte debido a que los sistemas encontrados no cumplen con las necesidades de la organización. Se evidenció la importancia que tiene el uso de la tecnología BPM, mostrando las ventajas del uso de este paradigma en el desarrollo de procesos. Además se mostró la relevancia que tiene utilizar una capa SOA para ganar en interoperabilidad y flexibilidad ante los cambios del negocio. 23

35 Capítulo 2 MODELACIÓN DEL NEGOCIO Capítulo 2: Modelo del Negocio 2.1. Introducción En este capítulo es donde se hará la modelación de los procesos de negocio que se llevan a cabo en la gestión del transporte en la organización. Primeramente se identificaran los actores y trabajadores que intervienen en este, se muestra el diagrama de casos de uso y los diferentes diagramas de actividades por cada caso de uso. Finalmente se identifican las entidades del negocio en un modelo de objetos Actores del negocio Tabla 1Cap.2. Descripción de Actores del Negocio Actor del negocio Descripción Jefe de Proyecto Representa al encargado de realizar las solicitudes de transporte de su proyecto. Jefe de Logística Es el encargado del área de logística del CITI y es quien necesita tener un control sostenido sobre los medios de transporte en la organización. Chofer Es el encargado de una vez confeccionado el plan semanal de transportación de recoger su respectiva hoja de ruta y realizar la transportación correspondiente a los viajes que le fueron asignados. También debe recoger sus bonos de asignación de combustible cada mes. 24

36 Capítulo 2 MODELACIÓN DEL NEGOCIO 2.3. Trabajadores del negocio Tabla 2 Cap.2. Descripción de Trabajadores del Negocio Trabajador del negocio Descripción Jefe de Transporte Este trabajador es el encargado de llevar a cabo toda la gestión del transporte en general, la planificación de los viajes tanto de personal como de cargas, además es quien elabora todos los documentos. Secretaria de transporte Es la encargada de planificar todas las solicitudes realizadas por los jefes de proyecto. Jefe de Programa Es el encargado de aprobar las solicitudes realizadas por el jefe de proyecto de su programa. 25

37 Capítulo 2 MODELACIÓN DEL NEGOCIO 2.4. Diagrama de casos de usos del negocio Figura 7 Cap.2.Diagrama de Casos de Uso del Negocio 2.5. Descripción de los Casos de uso del negocio. Diagramas de actividad por cada caso de uso CU: Solicitar Combustible Tabla 3 Cap.2. Descripción del Caso de Uso Solicitar Combustible Nombre del caso de uso Solicitar Combustible Actores Chofer Resumen Este caso de uso comienza cuando un chofer de la organización, al entrar un nuevo mes, le solicita al jefe de transporte el combustible mensual; el jefe de transporte le solicitará el odómetro del mes anterior y le asignará los 26

38 Capítulo 2 MODELACIÓN DEL NEGOCIO bonos de asignación de combustible al chofer. Precondiciones Antes de comenzar este caso de uso se debe tener el control del combustible con el que cuenta la entidad para el año. Poscondiciones Requisitos especiales El chofer debe presentar siempre el odómetro, de lo contrario no se le hará la asignación de combustible. Figura 8 Cap.2.Diagrama de actividad del Caso de Uso Solicitar Combustible 27

39 Capítulo 2 MODELACIÓN DEL NEGOCIO CU: Solicitar Transporte Tabla 4 Cap.2. Descripción del Caso de Uso Solicitar Transporte Nombre del caso de uso Solicitar Transporte Actores Trabajador del CITI Resumen Este caso comienza cuando algún trabajador del CITI desea realizar una solicitud de transporte, el usuario llena la planilla con todos los datos para hacer la solicitud, esta solicitud es enviada luego al jefe de programa. Precondiciones Poscondiciones Requisitos especiales La solicitud debe realizarse antes de los jueves de cada semana para poder elaborar la planificación semanal. 28

40 Capítulo 2 MODELACIÓN DEL NEGOCIO Figura 9 Cap.2. Diagrama de actividad del caso de uso Solicitar Transporte CU: Elaborar Plan de Transportación Semanal Tabla 5 Cap.2. Descripción del Caso de Uso Elaborar Plan de transportación semanal Nombre del caso de uso Elaborar Plan de transportación semanal Actores Jefe de Transporte Resumen Este caso comienza cuando la Secretaria de Transporte recibe todas las solicitudes realizadas y elabora el plan de transportación para la próxima semana. 29

41 Capítulo 2 MODELACIÓN DEL NEGOCIO Precondiciones Antes de comenzar este caso de uso deben estar almacenadas todas las solicitudes realizadas con sus viajes respectivos. Poscondiciones Cuando este proceso termina la secretaria de transporte debe publicar el plan de transportación. Requisitos especiales Figura 10 Cap.2.Diagrama de actividad del Caso de Uso Solicitar elaboración del Plan de Transportación Semanal 30

42 Capítulo 2 MODELACIÓN DEL NEGOCIO CU: Solicitar Documentos de control de medios Tabla 6 Cap.2. Descripción del Caso de Uso Solicitar Documentos de control de medios Nombre del caso de uso Solicitar Documentos de control de medios Actores Jefe de Logística Resumen Este caso de uso comienza cuando el jefe de logística le pide al jefe de transporte los documentos necesarios para tener el control de los medios de transporte para tomar decisiones. El jefe de transporte realizará la ficha de cada uno de los vehículos para obtener sus datos (que incluyen los datos de choferes y los del parqueo), archivando dichas fichas en un registro de fichas de vehículos. Precondiciones Antes de comenzar este caso de uso debe estar almacenada toda la información necesaria, como son los vehículos con sus choferes. Poscondiciones Requisitos especiales 31

43 Capítulo 2 MODELACIÓN DEL NEGOCIO Figura 11 Cap.2.Diagrama de actividad del Caso de Uso Solicitar Documentos de control de medios CU: Solicitar Plan de Mantenimiento Tabla 7 Cap.2. Descripción del Caso de Uso Solicitar Plan de Mantenimiento Nombre del caso de uso Solicitar Plan de Mantenimiento Actores Jefe de Logística Resumen Este caso de uso comienza cuando el jefe de logística le solicita al jefe de transporte el plan de mantenimiento anual de todos los vehículos de la organización, el jefe de transporte elaborara dicho plan y luego se lo enviará al jefe de logística para su aprobación, en caso de rechazar dicho plan se lo devolverá al jefe de transporte para su 32

44 Capítulo 2 MODELACIÓN DEL NEGOCIO reelaboración. Precondiciones Antes de comenzar este caso de uso debe estar almacenada toda la información sobre los vehículos que necesitan mantenimiento. Poscondiciones Requisitos especiales Figura 12 Cap.2.Diagrama de actividad del Caso de Uso Solicitar Plan de Mantenimiento 33

45 Capítulo 2 MODELACIÓN DEL NEGOCIO 2.6. Reglas del negocio a considerar Elaborar Plan de Transportación Semanal Siempre se debe cumplir que para la elaboración del Plan de Transportación Semanal, tanto de carga como de pasajeros, debe ser elaborado por el Jefe de Transporte a partir de las solicitudes de transportación recibidas hasta las 11:00 horas del viernes anterior a la semana en cuestión. El caso de uso solicitar combustible cumplirá correctamente el flujo básico si y solo si el chofer le entrega al jefe de transporte el odómetro del mes anterior, de lo contrario no se le asigna combustible a ese chofer. El plan de mantenimiento se elaborara si al menos existe un vehículo que necesite mantenimiento, de lo contrario no es necesario realizar dicho plan. 34

46 2.7. Modelo de Objetos Capítulo 2 MODELACIÓN DEL NEGOCIO Figura 13 Cap.2.Modelos de Objetos del Negocio 35

47 2.8. Conclusiones Capítulo 2 MODELACIÓN DEL NEGOCIO En este capítulo, con la utilización de las técnicas de modelado del negocio, se identificaron los actores y trabajadores del negocio; se describieron los principales casos de uso del negocio para la gestión del transporte; se presentaron los diagramas de actividades de los casos de uso; y finalmente se mostraron las entidades identificadas en un modelo de objetos. Luego de finalizado este capítulo se tiene un mejor entendimiento del funcionamiento del proceso de transporte dentro del CITI. 36

48 Capítulo 3 MODELACIÓN DEL SISTEMA Capítulo 3. Modelación del sistema 3.1. Introducción En el presente capitulo se exponen los requisitos funcionales con los que debe cumplir el sistema, identificándose los actores y casos de uso del sistema. Además se identifican las actividades automáticas en los procesos de negocio modelados, las cuales son integradas con servicios web. También se definen y explican los requisitos no funcionales del sistema y se describen los casos de uso del sistema a automatizar Requisitos funcionales A continuación se exponen los principales requisitos que el sistema debe cumplir: Autenticar Usuario. Asignar roles de usuario. Administrar usuarios del sistema. Gestionar entidades (Vehículos, Choferes, Órganos, Parqueos, Combustible). Gestionar Solicitudes de transporte. Elaborar planificación de las transportaciones. Elaborar Plan de mantenimiento de los vehículos. Asignar combustible. Elaborar Ficha de los vehículos. Generar reporte de solicitudes imprevistas. Generar reporte sobre las áreas que solicitan más transporte Actores del sistema a automatizar Tabla 8 Cap.3. Descripción de Actores del sistema Nombre del Actor Descripción Jefe de Transporte Es el encargado de registrar en el sistema todos los documentos que se generan con las actividades que se realizan en el área de transporte, tales como: 37

49 Capítulo 3 MODELACIÓN DEL SISTEMA Fichas de los vehículos, Modelo de Asignación de combustible, Plan de Mantenimiento, entre otros. Secretaria de transporte Es la encargada de planificar todas las solicitudes realizadas por los jefes de proyecto y luego registrarlas en el sistema. Además es la encargada de generar el documento que contiene la planificación del transporte de cada semana. Jefe de Programa Es el encargado de aprobar las solicitudes realizadas por el jefe de proyecto de su programa y mandar las notificaciones a los solicitantes Diagrama de casos de uso del sistema A continuación se muestran los diagramas de casos de uso del sistema divididos por actores de sistema. Estos casos de uso representan los servicios a diseñar para dar soporte a las tareas automáticas de los procesos de negocio modelados en la herramienta BPM. Se resaltó en color verde los casos de uso que se obtuvieron posteriormente en el refinamiento de los procesos de negocio. 38

50 Capítulo 3 MODELACIÓN DEL SISTEMA Figura 14 Cap.3.Casos de Uso del Sistema del actor Jefe de Transporte Figura 15 Cap.3.Casos de Uso del Sistema del actor Secretaria 39

51 Capítulo 3 MODELACIÓN DEL SISTEMA Figura 16 Cap.3.Casos de Uso del Sistema del actor Jefe de Programa 3.5. Identificación de los servicios en los Procesos de Negocio A continuación se muestran los diagramas de flujos de los procesos de negocio modelados en la herramienta BPM seleccionada, donde se describen los servicios web necesarios para llevar a cabo la ejecución de los procesos. Los servicios se identifican por el color azul, además se describen otros servicios que no se reflejan en los modelos pero también cumplen un papel importante dentro del sistema (Servicios Útiles). Proceso de Negocio: Solicitar Transporte Figura 17 Cap.3.Modelo del Proceso de Negocio Solicitar Transporte 40

52 Capítulo 3 MODELACIÓN DEL SISTEMA Tabla 9 Cap.3. Servicios identificados en el proceso Solicitar Transporte Proceso: Solicitar Transporte Descripción: Este proceso de negocio se inicia cuando el jefe de un determinado proyecto necesita hacer una solicitud de transporte tanto para trasladar personas o una determinada carga. Actividades de servicios Actividad: Obtener cargo del Solicitante Funcionalidad: Obtener cargo del Solicitante Descripción: Este servicio es utilizado para obtener el cargo del solicitante a partir de su correo. Actividad: Obtener Área Funcionalidad: Obtener el Área del solicitante. Descripción: Este servicio es utilizado para obtener el área del solicitante a partir de su correo. Actividad: Registrar Solicitud. Funcionalidad: Registrar la solicitud de transporte realizada en el sistema. Descripción: Este servicio es utilizado para que el jefe del solicitante, una vez que apruebe la solicitud de transporte, la registre en el sistema. Servicios Útiles 41

53 Capítulo 3 MODELACIÓN DEL SISTEMA Servicio: Registrar Viajes Funcionalidad: Registrar los viajes de una solicitud. Descripción: Este servicio es utilizado para queden registrados los viajes de una solicitud hecha. Servicio: Obtener Empleado Funcionalidad: Obtener el empleado que realizó la solicitud. Descripción: Este servicio es utilizado cuando se realiza la solicitud de transporte, a través del correo del solicitante se obtiene el empleado que realizó la solicitud, de manera tal que cuando se listen las solicitudes se tenga conocimiento de los datos de los distintos solicitantes. 42

54 Capítulo 3 MODELACIÓN DEL SISTEMA Proceso de Negocio: Planificar Transporte Figura 18 Cap.3.Modelo del Proceso de Negocio Planificar Transporte Tabla 10 Cap.3. Servicios identificados en el proceso Planificar Transporte Proceso: Planificar Transporte Descripción: Este Proceso de negocio se activa todos los jueves de cada semana con el objetivo de planificar las transportaciones de la próxima semana una vez que se hayan realizado todas las solicitudes de transporte. Actividades de servicios Actividad: Obtener Solicitudes Funcionalidad: Obtener todas las solicitudes Descripción: Este servicio es utilizado para listar todas las solicitudes que se hayan 43

55 Capítulo 3 MODELACIÓN DEL SISTEMA realizadas. realizado y hayan sido aprobadas y registradas en el sistema. Actividad: Registrar Plan de Transporte Funcionalidad: Registrar la planificación de transporte. Descripción: Este servicio es utilizado para una vez confeccionado el Plan de Transportación Semanal, quede registrado en el sistema. Servicios Útiles Servicio: Obtener Viajes Funcionalidad: Obtener los viajes de las solicitudes. Descripción: Este servicio es utilizado para listar todos los viajes de las solicitudes realizadas. Proceso de Negocio: Asignar Combustible 44

56 Capítulo 3 MODELACIÓN DEL SISTEMA Figura 19 Cap.3.Modelo del Proceso de Negocio Asignar Combustible Tabla 11 Cap.3. Servicios identificados en el proceso Asignar Combustible Proceso: Asignar Combustible Descripción: Este Proceso de negocio se inicia cuando el jefe de transporte debe asignarle combustible al chofer de un vehículo determinado. Actividades de servicios Actividad: Obtener Listado de Vehículos Funcionalidad: Obtener todos los vehículos. Descripción: Este servicio es utilizado para listar todos los vehículos con los que cuenta la entidad y el jefe de transporte asigna el combustible al vehículo seleccionado. Actividad: Registrar Funcionalidad: Registrar la Descripción: Este servicio es 45

57 Capítulo 3 MODELACIÓN DEL SISTEMA Modelo de Asignación asignación de combustible realizada. utilizado para una vez que se la haya hecho la asignación de combustible a un vehículo determinado esta información quede registrada en el sistema. Servicios Útiles Servicio: Obtener Modelo de Asignación Funcionalidad: Obtener Modelo de Asignación. Descripción: Este servicio es utilizado cuando una vez que el jefe de transporte seleccione un vehículo para asignarle combustible, se obtenga el modelo de asignación de dicho vehículo. Proceso de Negocio: Elaborar Plan de Mantenimiento 46

58 Capítulo 3 MODELACIÓN DEL SISTEMA Figura 20 Cap.3.Modelo del Proceso de Negocio Elaborar Plan de Mantenimiento Tabla 12 Cap.3. Servicios identificados en el proceso Elaborar Plan de Mantenimiento Proceso: Elaborar Plan de Mantenimiento Descripción: Este proceso de negocio se inicia cuando de acuerdo a la cantidad de kilómetros recorridos por los vehículos, según normas establecidas por el jefe de transporte se realiza la planificación del mantenimiento de estos vehículos para establecer los kilómetros a recorrer a partir de ese mantenimiento según el estado en que se encuentre este vehículo. Actividades de servicios Actividad: Obtener Listado de Vehículos Funcionalidad: Obtener todas los vehículos. Descripción: Este servicio es utilizado para listar todos los vehículos con los que cuenta la 47

59 Capítulo 3 MODELACIÓN DEL SISTEMA entidad y el jefe de transporte asigna el combustible al vehículo del chofer que solicite combustible para el mes en cuestión. Actividad: Registrar Plan Funcionalidad: Registrar el plan de mantenimiento realizado. Descripción: Este servicio es utilizado cuando una vez llenar los datos del nuevo plan de mantenimiento esta información quede registrada en el sistema. Servicios Útiles Servicio: Obtener Listado de Vehículos Funcionalidad: Listado de Vehículos. Obtener Descripción: Este servicio es utilizado dentro del servicio: Obtener Vehículos para mantenimiento con el objetivo de buscar por toda la lista de vehículos de la entidad los que necesitan el mantenimiento. Proceso de Negocio: Elaborar Ficha de los vehículos 48

60 Capítulo 3 MODELACIÓN DEL SISTEMA Figura 21 Cap.3. Modelo del Proceso de Negocio Elaborar Ficha de los vehículos Tabla 13 Cap.3. Servicios identificados en el proceso Elaborar Ficha de los vehículos Proceso: Elaborar Ficha de los Vehículos Descripción: Este proceso se inicia cuando el jefe de transporte realiza el control sobre los medios de transporte y la relación de los choferes con el vehículo que tienen asignado cada uno de ellos. Estas fichas de vehículos son entregadas al jefe de logística. Actividades de servicios Actividad: Obtener choferes Funcionalidad: Obtener todos los choferes. Descripción: Este servicio es utilizado para obtener el listado de choferes de la entidad. Actividad: Obtener Vehículo. Funcionalidad: Obtener el vehículo que tiene asignado un chofer determinado. Descripción: Este servicio es utilizado para una vez escogido el chofer para realizar la ficha, se obtiene el vehículo que tiene asignado para completar los datos de la misma. 49

61 Capítulo 3 MODELACIÓN DEL SISTEMA Actividad: Obtener Parqueo Funcionalidad: Obtener el parqueo al cual pertenece el vehículo. Descripción: Obtener el parqueo al cual pertenece el vehículo para completar datos de la ficha. Actividad: Obtener Órgano Funcionalidad: Obtener el órgano al cual pertenece el vehículo. Descripción: Obtener el órgano al cual pertenece el vehículo para completar datos de la ficha. Actividad: Obtener Modelo de Asignación. Funcionalidad: Obtener Modelo de Asignación de un vehículo determinado. Obtener Modelo de Asignación de un vehículo determinado para completar datos de la ficha. Servicios Útiles Servicio: Obtener Listado de Empleados Funcionalidad: Obtener todos los empleados. Descripción: Este servicio es utilizado para obtener todos los empleados e identificar de ellos cuales son los choferes. 50

62 Capítulo 3 MODELACIÓN DEL SISTEMA Proceso de Negocio: Solicitud de transporte imprevista Figura 22 Cap.3.Modelo del Proceso de Negocio Solicitud de transporte imprevista Tabla 14 Cap.3. Servicios identificados en el proceso Solicitud de transporte imprevista Proceso: Solicitud de transporte imprevista Descripción: Este proceso se inicia cuando un solicitante realiza una solicitud de transporte fuera de la planificación y es enviada directamente a la secretaria de transporte para satisfacer dicha solicitud. Actividades de servicios Actividad: Obtener Funcionalidad: Obtener Descripción: Este servicio es utilizado para obtener el cargo 51

63 Capítulo 3 MODELACIÓN DEL SISTEMA cargo del Solicitante cargo del Solicitante. del solicitante a partir de su correo. Actividad: Obtener Área Funcionalidad: Obtener el Área del solicitante. Descripción: Este servicio es utilizado para obtener el área a la cual pertenece el solicitante a partir de su correo. Actividad: Registrar Solicitud Funcionalidad: Registrar la solicitud realizada. Descripción: Este servicio es utilizado para registrar la solicitud realizada directamente en el sistema. Servicios Útiles Servicio: Registrar Viajes Funcionalidad: Registrar los viajes de la solicitud realizada. Descripción: Este servicio es utilizado cuando se re registra una determinada solicitud, deben quedar registrados los viajes de la misma Definición de los requisitos no funcionales Apariencia de la interfaz de usuario: Los formularios de la aplicación deben ser diseñados de forma sencilla y amigable, de manera que sea fácil de manipularlo por los usuarios. Seguridad: La información del sistema de transporte debe estar protegida contra acceso no autorizado, como también cada usuario debe tener un nivel de privilegio en la aplicación, de manera tal que solo se la muestren las tareas y los datos a los cuales tenga acceso. 52

64 Capítulo 3 MODELACIÓN DEL SISTEMA Ayuda: Debe existir un manual de usuario para una mejor comprensión y uso de las funcionalidades del sistema, elevando de esta manera el nivel de usabilidad del mismo. Software: Cliente: En las computadoras de los usuarios es necesario tener un navegador Web para que los clientes puedan navegar a través del portal del CITI, instalando un sistema operativo cualquiera. Servidor: La aplicación correrá sobre un servidor con la herramienta BPM BizAgi instalada. Hardware: El servidor para instalar BizAgi de contar con las siguientes características: Procesador: Core 2 of 1.66GHz - procesador compatible o superior RAM: 2GB o superior Disco Duro: 1GB de espacio libre (unidad C:\) Pantalla: 1024 x 768 o mayor resolución 3.7. Descripción de los casos de uso del sistema Tabla 15 Cap.3. Descripción del Caso de Uso del sistema Gestionar Vehículos Nombre del caso de uso Gestionar Vehículos Actores Jefe de Transporte Propósito Manipular los vehículos con los que cuenta la organización, ya sea mediante inserciones, modificaciones o eliminaciones. Resumen Este caso de uso se inicia en el caso que sea necesario gestionar algún vehículo. 53

65 Capítulo 3 MODELACIÓN DEL SISTEMA CU Asociados Precondiciones El jefe de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar un vehículo insertado, eliminado o modificado en el sistema. Tabla 16 Cap.3. Descripción del Caso de Uso del sistema Gestionar Choferes Nombre del caso de uso Gestionar Choferes Actores Jefe de Transporte Propósito Manipular los choferes, ya sea mediante inserciones, modificaciones o eliminaciones. Resumen Este caso de uso se inicia en el caso que sea necesario gestionar algún chofer. CU Asociados Precondiciones El jefe de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar un chofer insertado, eliminado o modificado en el sistema. 54

66 Capítulo 3 MODELACIÓN DEL SISTEMA Tabla 17 Cap.3. Descripción del Caso de Uso del sistema Gestionar Parqueos Nombre del caso de uso Gestionar Parqueos Actores Jefe de Transporte Propósito Manipular los parqueos a los cuales pertenecen los vehículos de la entidad, ya sea mediante inserciones, modificaciones o eliminaciones. Resumen Este caso de uso se inicia en el caso que sea necesario gestionar algún parqueo. CU Asociados Precondiciones El jefe de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar un parqueo insertado, eliminado o modificado en el sistema. Tabla 18 Cap.3. Descripción del Caso de Uso del sistema Gestionar Órganos Nombre del caso de uso Gestionar Órganos Actores Jefe de Transporte Propósito Manipular los órganos a los cuales pertenecen los vehículos de la entidad, ya sea mediante inserciones, modificaciones o eliminaciones. 55

67 Capítulo 3 MODELACIÓN DEL SISTEMA Resumen Este caso de uso se inicia en el caso que sea necesario gestionar algún parqueo. CU Asociados Precondiciones El jefe de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar un órgano insertado, eliminado o modificado en el sistema. Tabla 19 Cap.3. Descripción del Caso de Uso del sistema Gestionar Combustible Nombre del caso de uso Gestionar Combustible Actores Jefe de Transporte Propósito Manipular los tipos de combustible que utilizan los vehículos de la entidad, ya sea mediante inserciones, modificaciones o eliminaciones. Resumen Este caso de uso se inicia en el caso que sea necesario gestionar algún tipo de combustible. CU Asociados Precondiciones El jefe de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar un tipo de combustible insertado, eliminado o modificado en el sistema. 56

68 Capítulo 3 MODELACIÓN DEL SISTEMA Tabla 20 Cap.3. Descripción del Caso de Uso del sistema Elaborar Plan de Mantenimiento Nombre del caso de uso Elaborar Plan de Mantenimiento Actores Jefe de Transporte Propósito Planificar el mantenimiento de los vehículos que lo requieren de acuerdo a la cantidad de kilometro que hayan recorrido. Resumen Este caso de uso se inicia cuando hay una serie de vehículos que recorrido una cierta cantidad de kilómetros establecidos, para saber esta información debe haberse iniciado el CU: Registrar Modelo de Asignación de combustible. CU Asociados Asignar Combustible(include) Obtener Listado de vehículos para Mantenimiento(include) Precondiciones El jefe de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar almacenado el plan de mantenimiento en el sistema. Tabla 21 Cap.3. Descripción del Caso de Uso del sistema Asignar Combustible Nombre del caso de uso Asignar Combustible Actores Jefe de Transporte 57

69 Capítulo 3 MODELACIÓN DEL SISTEMA Propósito Realizar la asignación mensual de combustible a los vehículos de la entidad. Resumen Este caso de uso se inicia cuando al comienzo del mes los choferes buscan los bonos de combustible que el jefe de transporte les entregará de acuerdo con la cantidad de combustible que disponga. CU Asociados Obtener Asignación del vehículo Precondiciones El jefe de transporte se ha autenticado en el sistema y el sistema debe brindar información sobre el estado de asignación del vehículo que se le realizara la asignación. Poscondiciones Al terminar el proceso debe quedar almacenado el modelo de asignación de combustible del vehículo asignado. Tabla 22 Cap.3. Descripción del Caso de Uso del sistema Elaborar Ficha de Vehículo Nombre del caso de uso Elaborar Ficha de Vehículo Actores Jefe de Transporte Propósito Tener un control sobre los choferes de la entidad en relación con el vehículo que tiene asignado cada uno de estos choferes. Resumen Este caso de uso comienza cuando el Jefe de Logística le solicita al Jefe de Transporte los documentos de control de 58

70 Capítulo 3 MODELACIÓN DEL SISTEMA los medios de transporte. CU Asociados Obtener Listado de Vehículos(include) Obtener Listado de Choferes(include) Precondiciones El jefe de transporte se ha autenticado en el sistema y el sistema debe generar todos los vehículos de la entidad y todos los choferes de la misma. Poscondiciones Al terminar el proceso debe generarse la información sobre el control de los medios de transporte y almacenada en el sistema dicha información. Tabla 23 Cap.3. Descripción del Caso de Uso del sistema Elaborar Plan de Transporte Nombre del caso de uso Elaborar Plan de Transporte Actores Secretaria de Transporte Propósito Planificar las transportaciones semanales del personal que trabaja en el CITI. Resumen Este caso de uso se inicia todos los jueves de cada semana, de acuerdo con las solicitudes realizadas por los trabajadores la secretaria de transporte planificara los viajes de estas solicitudes para la próxima semana. 59

71 Capítulo 3 MODELACIÓN DEL SISTEMA CU Asociados Obtener Listado de Solicitudes(include) Obtener Viajes de las Solicitudes(include) Precondiciones La secretaria de transporte se ha autenticado en el sistema y el sistema ha generado todas las solicitudes realizadas. Poscondiciones Al terminar el proceso debe quedar almacenado el plan de transporte realizado. Tabla 24 Cap.3. Descripción del Caso de Uso del sistema Registrar Solicitud Nombre del caso de uso Registrar Solicitud Actores Jefe de Programa Propósito Registrar en el sistema la solicitud realiza para posteriormente quede en la planificación de transporte. Resumen Este caso de uso se inicia cuando una vez que el trabajador haya solicitado transporte, la jefa del programa del proyecto una vez que haya aprobado la solicitud debe registrar la misma. CU Asociados Precondiciones La secretaria de transporte se ha autenticado en el sistema. 60

72 Capítulo 3 MODELACIÓN DEL SISTEMA Poscondiciones Al terminar el proceso debe quedar almacenado el plan de transporte realizado. Tabla 25 Cap.3. Descripción del Caso de Uso del sistema Aprobar Solicitud Nombre del caso de uso Aprobar Solicitud Actores Jefe de Programa Propósito Aprobar la solicitud realizada por algún jefe de proyecto. Resumen Este caso e uso se inicia cuando una vez que un jefe de proyecto haya solicitado transporte, esta solicitud debe ser enviada al jefe del programa al cual pertenece el solicitante para que la apruebe. CU Asociados Solicitar Transporte(include) Precondiciones La secretaria de transporte se ha autenticado en el sistema. Poscondiciones Al terminar el proceso debe quedar almacenado el plan de transporte realizado Conclusiones En este capítulo se identificaron los actores que interactúan con el sistema, así como los diagramas de casos de uso del sistema de cada uno de estos actores. Se identificaron también los servicios que darán soporte a las tareas automáticas de los procesos de 61

73 Capítulo 3 MODELACIÓN DEL SISTEMA negocio modelados. Además quedaron definidos los requisitos funcionales y no funcionales con los que debe cumplir el sistema. 62

74 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Capítulo 4. Descripción de la solución propuesta 4.1. Introducción En este capítulo se describe la arquitectura organizacional donde se despliega el sistema de transporte, además se exponen los patrones y mecanismos de diseño utilizados para el desarrollo de la solución. También se muestran los servicios realizados en forma de diagrama, así como los modelos lógico y físico del diseño de la base de datos. Se hace un refinamiento de los procesos de negocio, quedando listos para ejecutarlos en la herramienta BPM seleccionada, mostrando para esto, las distintas fases por donde deben pasar los procesos de negocio en dicha herramienta. Por último se expone el modelo de despliegue de la solución propuesta y se hace la validación de dicha solución a través del proceso Solicitar Transporte, describiendo también algunos indicadores del resultado de la ejecución de este proceso Definición de la arquitectura La Arquitectura Orientada a Servicios es la propuesta utilizada para dar soporte a los Procesos de Negocio del sistema de transporte, garantizando no solo automatizar las tareas de los procesos sino también la integración con sistemas externos. Estos servicios fueron implementados en el IDE Visual Studio 2010 utilizando la tecnología Windows Communication Foundation (WFC), la cual posibilita el desarrollo de servicios distribuidos de manera sencilla. El autor Thomas Erl propone una arquitectura para ambientes SOA basadas en tres capas fundamentales: [32] Capa de Aplicaciones Capa de Servicios: Está compuesta por tres capas de servicios: Capa de servicios de aplicación Capa de servicios de negocio Capa de servicios de orquestación Capa de Procesos de Negocio 63

75 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Se tomó en consideración esta propuesta y se adaptó según las características y necesidades del entorno empresarial, quedando de la siguiente manera: Figura 23 Cap.4.Arquitectura de la solución propuesta Capa de Presentación: Esta capa maneja el contexto de los usuarios que interactúan con el sistema y les permite ejecutar los procesos de negocio. Capa de Procesos de Negocio: Esta capa contiene un repositorio con los procesos de negocio identificados. Capa de servicios: La capa de servicios contiene los servicios web que implementan la lógica de la aplicación exponiendo las funcionalidades del sistema, tanto para dar soporte a las tareas de servicio de los procesos, como para el consumo de otras aplicaciones. Capa de Transporte de datos: Es la encargada de manejar e integrar la información entre los diferentes sistemas legados de la entidad. Se emplea la tecnología Entity 64

76 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Framework para extraer la información de las bases de datos de los sistemas legados. Aunque esta tecnología es concebida para su empleo en ambientes.net, en esencia el gestor Microsoft SQL Server, también trae soporte para otros gestores de base de datos como Oracle, que es el empleado en la solución. Capa de Aplicaciones: Es la capa donde se encuentran las aplicaciones o sistemas legados con las que cuenta la entidad para la gestión de su información Patrones de Diseño Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. Estos brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. [33] Existen varios patrones de diseño, los cuales se clasifican como se muestra a continuación [33]: Patrones Creacionales: Inicialización y configuración de objetos. Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos y se agrupan, para formar estructuras más grandes. Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos. A continuación se mencionan los patrones de diseño que se tuvieron en cuenta a la hora de diseñar el sistema Patrones de Diseño Creacionales Singlenton (Instancia única): Este patrón está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto. Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella. El patrón singlenton se implementa creando dentro de una clase un método que crea una instancia del objeto sólo si todavía no existe alguna. Para asegurar 65

77 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA que la clase no puede ser instanciada nuevamente se regula el alcance del constructor (con atributos como protegido o privado). [34] En el sistema este patrón es utilizado en la capa de transporte de datos con el objetivo de instanciar el modelo de clases que se obtiene a partir del modelo de datos del sistema, de manera tal que sea global el acceso a este modelo Patrones de Diseño Estructurales Los patrones de diseño estructurales son los que se ocupan de cómo clases y objetos se agrupan, para formar estructuras más grandes. [34] Facade (Fachada): Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar. [34] Este patrón es utilizado en la capa de servicios, con el objetivo de poder acceder a las interfaces de los servicios sin importar como están implementados por detrás Mecanismos de Diseño Seguridad La seguridad en los sistemas es un mecanismo de diseño utilizado para garantizar el control de acceso o de comunicación de una manera segura. Además de controlar el acceso de los usuarios a la información del sistema a través de diferentes roles. Tanto para los servicios como para los procesos de negocio es garantiza la seguridad que brinda la autenticación de Windows sobre el dominio. Acceso a datos El mecanismo Acceso a los Datos es el encargado de permitir el acceso a la Base de Datos, garantizando la persistencia de la información. El acceso a los datos se efectúa de acuerdo a los marcos de trabajo de EntityFrameWork. 66

78 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA 4.5. Diagrama de clases de los servicios diseñados En este epígrafe se muestra una vista de las clases que se diseñaron para el desarrollo de los servicios, así como los métodos definidos en cada una de estas clases. Figura 24 Cap.4.Diagrama de clases de los servicios 4.6. Diseño de la base de datos En este epígrafe se muestra una vista de las clases modeladas y el diagrama de entidad relación que se obtiene a partir de este modelo, estas clases se encuentran en la capa de aplicaciones de la arquitectura. 67

79 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Modelo lógico de los datos Figura 25 Cap.4.Modelo Lógico de los datos 68

80 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Modelo físico de los datos 69

81 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Figura 26 Cap.4.Modelo Físico de los datos 70

82 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA 4.7. Procesos de negocio En este epígrafe se llevan a cabo las fases por las que se debe pasar al trabajar con la suite BPM BizAgi. Se muestran los modelos de proceso refinados y listos para ser ejecutados, así como las fases de modelo de datos, ceración de formularios, reglas de negocio, definición de los participantes de los procesos y la validación de la solución a través de uno de los procesos de negocio. Estos procesos se ubican en la capa de procesos de negocio de la arquitectura Refinamiento de los procesos de Negocio A continuación se muestran los procesos de negocio modelados en BizAgi, estos procesos de negocio son refinados a partir de su identificación y modelado en capítulos anteriores. También a raíz de esta actividad se identificaron otros servicios que jugaban un papel importante en aras de garantizar una satisfactoria ejecución de los procesos. PN: Solicitar Transporte Figura 27 Cap.4.Modelo refinado del Proceso de Negocio Solicitar Transporte 71

83 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA PN: Planificar Transporte Figura 28 Cap.4.Modelo del Proceso de Negocio Planificar Transporte PN: Asignar Combustible Figura 29 Cap.4.Modelo del Proceso de Negocio Asignar Combustible 72

84 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA PN: Elaborar Plan de Mantenimiento Figura 30 Cap.4.Modelo del Proceso de Negocio Elaborar Plan de Mantenimiento PN: Solicitud Imprevista 73

85 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Figura 31 Cap.4.Modelo del Proceso de Negocio Solicitud Imprevista PN: Elaborar Ficha de Vehículo Figura 32 Cap.4.Modelo del Proceso de Negocio Elaborar Ficha de Vehículo Definición de los datos de los procesos A continuación se presenta el diagrama con los datos que quedaron definidos en BizAgi para poder llevar a cabo los procesos de negocio para que perdure la información manejada en cada instancia de un proceso. Esta base datos es propia de la Suite para el manejo de la información que se maneja durante la ejecución de los procesos de negocio. 74

86 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA En el diagrama se presentan las entidades que agrupan el contenido de toda la información manejada en el proceso. BizAgi además cuenta con entidades propias del sistema como la entidad WFUSER para manejar la información de los usuarios. Figura 33 Cap.4. Modelo de Datos de los Procesos Creación de formularios BizAgi brinda los recursos necesarios para realizar la creación de formularios con los cuales interactúan los usuarios finales de manera sencilla y a partir de las tereas que quedaron definidas de tipo usuario en la modelación de los procesos de negocio. La información que se maneja en los formularios, tanto la que llena el usuario como la que muestra el sistema, es a partir de los atributos de las entidades definidas en los datos de los procesos. A continuación se presentaran los formularios correspondientes a los procesos de negocio del sistema de transporte: 75

87 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Proceso: PN Solicitar Transporte Tabla 26 Cap.4. Formularios utilizados en el sistema Formulario Descripción frm_llenar_solicitud_de_transporte En este formulario se maneja la información que el usuario debe llenar para realizar la solicitud de transporte, se le muestran al usuario sus datos personales y debe llenar los datos de los viajes que necesita. frm_aprobar_solicitud_de_transporte En este formulario se muestran los datos de la solicitud de transporte realizada, mostrando como datos adicionales los campos necesarios para la aprobación de dicha solicitud. PN Planificar transporte: frm_planificar Transporte En este formulario se le muestra al usuario los datos de las solicitudes realizadas, además de los viajes de cada una de estas solicitudes. frm_guardar_en_office_word En este formulario es donde se genera el documento con los datos de la planificación de transporte. frm_notificación_de_error En este formulario se le muestra al usuario los detalles de un error ocurrido en el 76

88 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA sistema. PN Asignar Combustible: frm_seleccionar_vehiculo_a_asignar En este formulario se le muestra al usuario un listado de todos los vehículos de la entidad, para escoger en ese listado el vehículo que se le realizará la asignación de combustible. frm_verificar_asiganacion En este formulario se le muestra al usuario los datos de la asignación realizada, con el objetivo de corregir cualquier error que haya cometido. frm_notificacion_de_error En este formulario se le muestra al usuario los detalles de un error ocurrido en el sistema. PN Solicitud de Transporte Imprevista: frm_registrar_solicitud Imprevista En este formulario se maneja la información que el usuario debe llenar para realizar la solicitud de transporte, se le muestran al usuario sus datos personales y debe llenar los datos de los viajes que necesita. frm_notificación_de_error En este formulario se le muestra al usuario los detalles de un error ocurrido en el sistema. 77

89 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA PN Realizar Plan de Mantenimiento: frm_elaborar_plan_de_mantenimiento En este formulario se muestra un listado de los vehículos que necesitan mantenimiento, y los datos que debe llenar el usuario con respecto al plan de mantenimiento. frm_aprobar_plan_de_mantenimiento En este formulario se muestran los datos del mantenimiento realizado, agregando los campos necesarios para la aprobación de este plan. frm_registrar_plan_de_mantenimiento En este formulario se muestran los datos del mantenimiento realizado, agregando los campos necesarios para la aprobación de este plan llenos. frm_guardar_en_office_word En este formulario es donde se genera el documento con los datos del plan de mantenimiento. PN Elaborar Ficha de Vehículo: frm_seleccionar_vehiculo_para_la_ficha En este formulario se muestra un listado con los vehículos de la entidad, para que el usuario escoja los vehículos para elaborar su ficha. frm_verificar_datos_del_chofer_y_el_vehiculo En este formulario se muestran los datos del chofer que tiene asignado el vehículo seleccionado en el listado, además de los 78

90 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA datos del mismo. frm_elaborar_ficha_de_vehiculo En este formulario se muestran los datos del vehículo con su chofer; además se adicionan otros datos necesarios para completar la elaboración de la ficha Creación de reglas de negocio y eventos En esta fase se establecen las políticas a seguir durante la ejecución de los procesos. Para lograr esto BizAgi brinda la posibilidad de crear reglas de negocio a partir de valores que tomen los atributos del modelo de datos. Para algunos de los procesos modelados se identifican una serie de reglas de negocio que guían el flujo de actividades de cada uno de estos procesos: PN Solicitar Transporte: Compuerta Solicitud Aprobada? Regla: Si el jefe del programa al cual pertenece el trabajador aprueba la solicitud realizada por este, dicha solicitud quedara registrada en el sistema, de lo contrario el jefe de programa mandara una notificación por correo al solicitante con los motivos del rechazo. PN Realizar Plan de Mantenimiento: Compuerta Plan Aprobado? Regla: Una vez que el jefe de transporte haya realizado el plan de mantenimiento, debe enviárselo al jefe de logística para su aprobación, en caso de que este lo apruebe el jefe de transporte lo registra en el sistema, de no ser así el jefe de logística le envía una notificación al jefe de transporte con los motivos del rechazo y pidiéndole que realice nuevamente el plan. También BizAgi permite crear acciones en las actividades conocidas como eventos. Estos eventos pueden ejecutarse al entrar en una actividad, al salvar o al salir de la misma. En 79

91 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA el siguiente ejemplo se muestra un evento de expresión para asignar la fecha actual de la solicitud y el id del creador del caso Solicitar transporte. Figura 34 Cap.4. Eventos de la Actividad Asignación de participantes BizAgi brinda la posibilidad de establecer roles de usuarios para los distintos participantes dentro de uno o varios procesos de negocio, esto se hace a través de la asignación de responsabilidades en las tareas de usuario de los procesos. Para asignar un responsable a cada tarea la herramienta BPM se basa en una serie de propiedades tales como: Id Usuario, Roles, Aéreas, Cargos, entre otras. Los participantes asignados para las distintas tareas de los procesos se muestran a continuación: PN: Solicitar Transporte Jefe de Proyecto (Actividad-> Llenar solicitud de transporte) 80

92 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Jefe de Programa (Actividad->Aprobar solicitud de transporte) PN: Planificar Transporte Secretaria de Transporte (Actividad->Realizar Planificación de Transporte) PN: Asignar Combustible Jefe de Transporte (Actividad->Seleccionar vehículo a asignar\verificar Modelo de Asignación) PN: Realizar Plan de Mantenimiento Jefe de Transporte (Actividad->Elaborar Plan de Mantenimiento\Registrar Plan de Mantenimiento) Jefe de Logística (Actividad->Aprobar Plan de Mantenimiento) PN: Solicitud de Transporte Imprevista Jefe de Proyecto (Actividad->Llenar solicitud de transporte) Secretaria de Transporte (Actividad->Registrar Solicitud Imprevista) El siguiente ejemplo muestra cómo se realiza la asignación de responsabilidades con BizAgi, en este caso se asigna la responsabilidad a la secretaria de transporte de planificar las solicitudes: 81

93 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Figura 35 Cap.4. Asignación de responsabilidad al actor Secretaria Mapeo de datos con los servicios Una de las fases más importantes de la suite BPM es la integración con los servicios identificados en cada uno de los procesos de negocio previamente ilustrados. BizAgi, a través de las tareas de tipo automáticas resaltadas en el capítulo anterior, permite enlazar actividades con las funcionalidades que brindan los servicios diseñados. En este caso la tarea que se muestra es la tarea automática Obtener Solicitudes del proceso Planificar Transporte (Ver Anexo 1) Modelo de despliegue de la solución En este epígrafe se explican los nodos físicos que intervienen en la arquitectura, mostrando además las conexiones entre estos. La vista del despliegue del sistema se muestra en la Figura 36. Descripción de los Nodos Nodo: PC Cliente Propósito: Este nodo representa un ordenador de la organización, es donde los usuarios podrán acceder al sistema a través del Portal Coorporativo del CITI, utilizando las 82

94 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA funcionalidades que brinda el mismo. Este ordenador solo debe contar con un navegador web, sin importar el sistema operativo. Nodo: Servidor de BizAgi Propósito: Este nodo representa un servidor que contiene el repositorio de procesos de negocio desarrollados por el sistema en cuestión y otros sistemas externos. Software: Para 32 bits: Windows Server 2003 SP1 Windows XP Professional SP3 Figura 36 Cap.4. Modelo de despliegue de la solución Para 32 o 64 bits: 83

95 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Windows Server 2008 Windows Vista Ediciones Ultimate, Business, Enterprise Editions o Home Premium Windows 7 Ediciones Ultímate, Enterprise, Professional o Home Premium Navegador: Internet Explorer 7 o superior FireFox 3.5 Gestor de Base de Datos SQL: Microsoft SQL Server 2005 SP2 o superior Microsoft SQL Server 2008 SP1 o superior Microsoft SQL Server 2008 R2 En caso de no tener ninguno de estos instalados, el asistente de instalación de BizAgi da la alternativa de instalar SQL Server Express 2005 SP2. Otros requisitos: IIS Internet Information Service 5.0 o superior (en BizAgi Studio hay una opción para usar ASP.NET Development Server únicamente para ambiente de Desarrollo), además de que solo sirve para ver el portal desde el localhost. Hardware: Procesador: Core 2 of 1.66GHz - procesador compatible o superior RAM: 2GB o superior Disco Duro: 1GB de espacio libre (unidad C:\) para la instalación, aunque deben haber como mínimo 20Gb libres para la ejecución de los procesos de negocio. Pantalla: 1024 x 768 o mayor resolución 84

96 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Nodo: Servidor Web Propósito: Este nodo representa un servidor que contiene todas las funcionalidades y los servicios no solo del sistema de transporte, sino también las de otros sistemas que se están desarrollando. Software: Puede tener cualquiera de los siguientes sistemas operativos Windows XP Windows Vista con Service Pack 2 Windows 7 Windows Server 2003 SP2 Windows Server 2003 R2 Windows Server 2008 SP2 Windows Server 2008 R2 Hardware: Los requerimientos mínimos son: Pentium 300 MHz - RAM 128M Espacio en el disco duro de 1,5 G Resolución de monitor 800x600 Lectora de CD-ROM para el CD de instalación Nodo: Servidor de Base de datos Propósito: Almacenar todos los datos de los sistemas que se están desarrollando incluyendo la del sistema de transporte, el gestor de base de datos instalado en este servidor es Oracle. Software: Sistema Operativo Windows 98/98SE/2000/XP\Vista Hardware: 85

97 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Procesador Intel Pentium 3.0 GHz o superior Disco duro de 80Gbo superior RAM 2Gb o superior 4.9. Validación de la solución a través del proceso Solicitar transporte Una vez terminado el refinamiento de los procesos de negocio se puede llevar a cabo la integración de estos con los servicios web desarrollados, garantizando a través de los servicios, toda la lógica del negocio embebida en el sistema. Al ejecutar una instancia de un proceso se generan un conjunto de tareas visibles a los usuarios responsables de atenderlas. Estas tareas se agrupan en una bandeja de entrada en la sesión correspondiente del usuario. De este modo el responsable puede ver el flujo, así como el estado en que se encuentra el mismo en tiempo real. A continuación se muestran los pasos de ejecución de una instancia del proceso de negocio Solicitar Transporte. Cuando el nuevo caso es instanciado por algún trabajador que solicite transporte se le muestra la tarea Llenar Solicitud de Transporte como se muestra en la Figura38. Cuando se inicia el flujo del proceso se ejecutan las dos primeras actividades que son tareas de servicio descritas en el capítulo anterior (ver Capítulo 3, Epígrafe 3.5). De la ejecución de estas tareas se obtienen los datos del solicitante, estos datos pueden ser obtenidos tanto de la base de datos del ETES, como de la base de datos de los inducidos, en dependencia del correo de dicho solicitante. Luego el solicitante llena los datos requeridos para realizar la solicitud y se le indica el término satisfactorio de la tarea realizada como se indica en la Figura

98 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Figura 37 Cap.4. Solicitud realizada con éxito 87

99 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Figura 38 Cap.4. Formulario para llenar la Solicitud de Transporte Luego se pasa a la actividad Aprobar Solicitud de Transporte que como se ve en la figura anterior, la responsable de realizar esta actividad es el jefe de programa del proyecto al cual pertenece el solicitante. Esta terea se muestra en la sesión del usuario encargado de la aprobación de la solicitud como se muestra en la figura siguiente: Figura 39 Cap.4. Bandeja de entrada del Jefe de Programa 88

100 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA Una vez que el usuario entre a realizar esta actividad se le muestran los datos de la solicitud realizada, como se muestra en la Figura 41.Una vez que el usuario apruebe la solicitud automáticamente se envía una notificación de aprobación al solicitante ejecutando la actividad Notificar Aprobación. Por último se ejecuta la tarea automática Registrar Solicitud descrita en el capítulo anterior (ver Capítulo 3, Epígrafe 3.5), donde la solicitud realizada es insertada en las tablas de la base de datos del sistema de transporte introducida en la base de datos de los inducidos. Figura 40 Cap.4. Formulario para aprobar la Solicitud de Transporte Definición de indicadores del proceso En este epígrafe se describen los indicadores que la herramienta BizAgi permite crear para lograr la monitorización de los procesos de negocio, lo cual nos da una medida de cómo está funcionando un proceso, definiendo para ello variables llamadas dimensiones. Las dimensiones se crean a partir de las entidades del proceso que son de tipo sistema, con atributos de tipo Booleany con entidades paranéfricas. Otra característica importante, en estas variables, es que se pueden monitorear durante la ejecución del proceso o a 89

101 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA través de un registro histórico del mismo. Las dimensiones creadas para monitorizar el proceso Solicitar Transporte se muestran en el Anexo 1. Para este caso las dimensiones creadas son las siguientes: Dimensión: Solicitud Aprobada Esta dimensión se utiliza para saber cuántas solicitudes han sido aprobadas en todas las instancias que han sido creadas del proceso, para usar esta dimensión se debe hacer un filtro (Ver Anexo 2). Dimensión: Solicitante Esta dimensión se utiliza para saber cuáles han sido los solicitantes que han realizado solicitudes de transporte y en qué estado se encuentra esta tarea en cada uno de ellos, así como la cantidad de casos que han iniciado y cuáles de estos han finalizados (Ver Anexos 4). Dimensión: Jefe Solicitante Esta dimensión se utiliza para saber el estado de los jefes de los solicitantes con respecto a la tarea de aprobación de las solicitudes, además podemos ver la cantidad de solicitudes aprobadas por un determinado JefeSolictante (Ver anexos 3 y 5) Conclusiones En este capítulo se llevó a cabo el análisis de la propuesta de arquitectura concebida en el centro para desarrollar el sistema de transporte, considerando la arquitectura que propone Thomas Erl para ambientes SOA. Se explicaron los diferentes patrones de diseño existentes, resaltando aquellos que fueron utilizados, así como los distintos mecanismos empleados para la seguridad y el acceso a los datos del sistema. Se mostró un diagrama con las clases que se diseñaron para implementar los servicios, mostrando también el esquema de la base de datos a través de los modelos físico y lógico de la misma. Se explicaron cada una de las fases por las que deben pasar los procesos de negocio para poder ser ejecutados. Se mostró la distribución física de la aplicación, exponiendo los requisitos que deben cumplir cada uno de los nodos de la distribución. Se 90

102 Capítulo 4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA realizó la validación de la solución propuesta a través de uno de los procesos modelados en el desarrollo del sistema y finalmente se definieron algunos indicadores que hacen posible el monitoreo de los procesos de negocio. 91

103 Capítulo 5 ESTUDIO DE FACTIBILIDAD Capítulo 5. Estudio de factibilidad 5.1. Introducción En este capítulo se realiza un estudio de la factibilidad para el desarrollo del sistema, estimando para ello el tiempo en horas necesario para la construcción del mismo, utilizando para esto el método de estimación basado en el análisis por Puntos de Casos de Uso. Además se exponen los costos que traerá la realización del sistema, así como los beneficios tangibles e intangibles, con el objetivo de determinar si es o no factible la implantación del mismo en la entidad Planificación basada en casos de uso La estimación mediante el método puntos de casos de uso consiste en determinar el tiempo de desarrollo de un proyecto mediante la asignación de pesos a los factores que influyen en este tiempo, de esta manera se contabiliza el tiempo total del proyecto a partir de dichos factores Calcular los Puntos de Casos de Uso PCU = FPA + FPCU PCU: Puntos de Casos de Uso FPA: Factor de Peso de los Actores FPCU: Factor de Peso de los CU Para calcular FPA (Este valor se calcula mediante un análisis de la cantidad de actores presentes en el sistema y la complejidad de cada uno de ellos): Tabla 27Cap.5. Factor de Peso de los Actores sin ajustar Nombre del Actor Tipo de Actor Factor de Peso Jefe de Transporte Complejo 3 Secretaria de transporte Complejo 3 92

104 Capítulo 5 ESTUDIO DE FACTIBILIDAD Jefe de Programa Complejo 3 FPA = 3*3 = 9 Para calcular FPCU (Este valor se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos). FPCU Tabla 28 Cap.5. Factor de Peso de los Casos de Uso sin ajustar Caso de Uso Tipo de Caso de Uso Factor de Peso Gestionar Vehículos Complejo 15 Gestionar Choferes Complejo 15 Gestionar Parqueos Medio 10 Gestionar Combustible Medio 10 Gestionar Órganos Medio 10 Elaborar Plan de Mantenimiento Simple 5 Elaborar Ficha de Vehículo Complejo 15 Elaborar Plan de Transporte Medio 10 Registrar Solicitud Simple 5 93

105 Capítulo 5 ESTUDIO DE FACTIBILIDAD Aprobar Solicitud Simple 5 Registrar Plan de Mantenimiento Simple 5 Registrar Plan de Transporte Simple 5 Registrar Modelo de Asignación Simple 5 Registrar Solicitud de Transporte Imprevista Simple 5 Generar reporte de Solicitudes Imprevistas Simple 5 Generar reporte de Aéreas que más solicitan transporte Simple 5 Generar reporte de la cantidad de solicitudes que se realizan semanalmente Simple 5 Generar reporte de estado de los medios Simple 5 Generar reporte de vehículos con mantenimiento realizado Simple 5 Cantidad de casos de uso de tipo complejo = 3 Cantidad de casos de uso de tipo medio = 4 Cantidad de casos de uso de tipo simple = 12 FPCU = 12* * * 15 = =

106 Sustituyendo valores: Capítulo 5 ESTUDIO DE FACTIBILIDAD PCU = = Calcular los Puntos de Casos de Usos Ajustados PCUA = PCU * FCT * FA PCUA: Puntos de Casos de Usos Ajustados FCT: Factor de Complejidad Técnica FA: Factor Ambiente Calculando FCT Para calcular FCT (Este coeficiente se calcula mediante la cuantificación de un conjunto de factores que determinan la complejidad técnica del sistema). Tabla 29 Cap.5. Factor de Complejidad Técnica Factor Descripción Peso Valor Comentario T1 Sistema distribuido 2 0 El sistema es centrado. T2 Tiempo de respuesta 1 3 El sistema debe tener un tiempo de respuesta elevado. T3 Eficiencia del usuario final 1 2 El usuario final es poco eficiente. T4 Procesamiento interno complejo 1 2 Existen algunos métodos complejos. T5 Reusabilidad 1 5 Se sigue el camino de 95

107 Capítulo 5 ESTUDIO DE FACTIBILIDAD la reutilización. T6 Fácil instalación 1 0 El sistema no debe ser instalado, los usuarios finales lo utilizaran a través del portal del CITI. T7 Fácil uso El sistema debe ser de fácil uso para que los usuarios finales puedan asimilar con rapidez la aplicación y les sea más fácil operar sobre este. T8 Portabilidad 2 5 El sistema se podrá ejecutar sobre cualquier plataforma. T9 Fácil de cambio 1 4 El sistema debe poseer gran facilidad de mantenimiento y adaptabilidad a los cambios. T10 Concurrencia 1 5 El sistema posee una concurrencia elevada. T11 Seguridad 1 5 El sistema requiere un elevado nivel de 96

108 Capítulo 5 ESTUDIO DE FACTIBILIDAD seguridad por el carácter sensible de la información que trata. T12 Acceso directo a terceras partes 1 0 El sistema no es de libre acceso para terceras partes. T13 Facilidad de entrenamiento a usuarios 1 2 El sistema posee facilidades de uso, por lo que requiere poco entrenamiento para los usuarios finales. FCT = * Σ (Pesoi * Valor asignadoi) FCT = *(40.5) = Para calcular FA (este cálculo se basa en las habilidades y entrenamiento del grupo de desarrollo.se trata de un conjunto de factores que se cuantifican con valores de 0 a 5). Tabla 30 Cap.5. Factor de Ambiente Factor Descripción Peso Valor Comentario E1 Familiaridad con el modelo del proyecto Se está muy familiarizado con el modelo del proyecto. E2 Experiencia en la aplicación No hay mucho conocimiento sobre este sistema. 97

109 Capítulo 5 ESTUDIO DE FACTIBILIDAD E3 Experiencia orientada objetos a 1 4 Se tiene buen conocimiento sobre las aplicaciones orientada a objeto. E4 Capacidad del analista El analista tiene buena capacidad para cumplir con los requerimientos del proyecto. E5 Motivación 1 5 Se siente una gran motivación por el sistema. E6 Estabilidad de los requerimientos 2 3 Los requerimientos serán poco estables. E7 Personal media jornada -1 3 Se trabaja el tiempo establecido en la jornada laboral. E8 Dificultad del lenguaje de programación -1 2 Se utilizara el lenguaje C# que no tiene mucha dificultad. FA = * Σ (Peso i * Valor asignado i ) FA = *20 = 0.8 PCUA = PCU * FCT * FA Sustituyendo valores: PCUA = 154* 1.005* 0.8 =

110 Capítulo 5 ESTUDIO DE FACTIBILIDAD Calcular el Esfuerzo de desarrollo E = PCUA * FC E: Esfuerzo estimado en horas-hombre. PCUA: Puntos de Casos de Uso ajustados. FC: Factor de conversión. De E1 a E6 por debajo del valor medio (3) hay 1. Entre E7 y E8 por encima del valor medio (3) hay 0. Entonces FC es 20 horashombre/punto de Casos de Uso. FC = 20 H/H E = * 20 Horas-Hombre E = Horas-Hombre Tabla 31 Cap.5. Estimación del esfuerzo Actividad Porcentaje Horas-Hombre Análisis 10% Diseño 30% Implementación 30% Pruebas 20% Sobrecarga(Otras actividades) 10%

111 Capítulo 5 ESTUDIO DE FACTIBILIDAD Total 100% Estimación del tiempo de desarrollo del proyecto TDes= E (total) / CH TDes: Tiempo de desarrollado del proyecto. E (total): Esfuerzo total. CH: Cantidad de hombres que desarrollan el proyecto. La cantidad de hombres que desarrollan el proyecto (CH) es 1 TDes = horas Horas trabajadas diariamente por hombres: 8 Por tanto: / 8 = 310 días laborables Días laborable que tiene un mes aproximadamente: 20 Por tanto: 310 / 20 = 15 meses Estimación del costo de desarrollo del proyecto C (total) = E (total) x Th (media) CH: cantidad de hombres. Th (media): Tarifa Horaria Media. Salario Promedio = $ Th (media) = $ hombre /160horas. (Cantidad de horas trabajadas en el mes) Th (media) = $2.18/horas hombre. C (total) = horas-hombre x ($2.18/horas-hombre). 100

112 C (total) = $ Capítulo 5 ESTUDIO DE FACTIBILIDAD En la siguiente tabla se resumen las variables fundamentales a analizar con sus respectivos valores estimados: Tabla 32 Cap.5. Resumen de valores estimados Variable Valor Tiempo de desarrollo(tdes) Cantidad de hombres 1hombre Salario medio $350 Costo $ Beneficios tangibles e intangibles Beneficios tangibles El sistema de transporte del CITI no es un producto con fines comerciales. Su principal objetivo es resolver los problemas que existen con los procesos involucrados en la gestión de información de las actividades referentes a la transportación del personal y mantenimiento de los medios de transporte de la entidad. La realización de este sistema trae consigo varios beneficios tangibles para el CITI en lo que a transporte se refiere, ya que el mismo será una herramienta de uso cotidiano con un alto grado de funcionalidad, usabilidad y seguridad, además de ser flexible para permitir la incorporación de nuevas modificaciones y actualizaciones de la información que en él se procesa. Con la monitorización e los procesos de negocio se logra mejorar la toma de decisiones en el centro, permitiendo la entrega sin errores y de manera sencilla los reportes con análisis estadísticos precisos y rápidos que dan una medida de cómo 101

113 Capítulo 5 ESTUDIO DE FACTIBILIDAD están funcionando los procesos de negocio automatizados por el sistema. Se logra el almacenamiento y concentración de la información de una manera más segura y organizada, pudiendo tener registros históricos de la información si necesidad de grandes volúmenes de papeles. El costo que requiere el desarrollo del proyecto es de $ en MN Beneficios intangibles A través del uso de esta aplicación se pueden obtener los siguientes beneficios intangibles para la organización: Se garantiza acceder de manera sencilla a la información actualizada. La utilización de un gestor de base de datos que garantiza velocidad en el procesamiento, seguridad y protección de los datos. Se reducen considerablemente los errores en datos que se almacenan. Control exhaustivo y seguimiento de los documentos más importantes que se generan en el área de transporte. 5.4 Análisis de costos y beneficios Durante la realización del sistema no se hizo necesario incurrir en gastos adicionales en cuanto a compra de equipos, ya que la entidad ya contaba con los recursos necesarios para esto, así como la contratación de especialistas para la elaboración del mismo, debido a que la realización del sistema la realiza un estudiante de la propia entidad, teniéndose en cuenta solo el gasto por alimentación, el cual es una mínima afectación para el centro. Teniendo en cuenta los cálculos obtenidos en el análisis de factibilidad, donde se obtuvo un tiempo para el desarrollo del sistema de 13 meses aproximadamente, incurriendo en un costo de $5398.6, se pude decir que el sistema es factible. 102

114 Capítulo 5 ESTUDIO DE FACTIBILIDAD 5.5. Conclusiones En este capítulo se utilizó para la estimación del esfuerzo necesario para el desarrollo del sistema el método de estimación por Puntos de Casos de Uso, el cual resulta muy efectivo a la hora de realizar esta actividad. Este método de aproximación nos da una idea e cuanto se debe demorar la realización del sistema, obteniendo además el costo en el que se incurriría con el desarrollo del mismo. También se expusieron los beneficios tangibles e intangibles que lograr la entidad con la implantación de dicho sistema. 103

115 CONCLUSIONES Conclusiones Con la realización de este trabajo se cumplieron los objetivos propuestos, logrando hacer una primera versión del sistema de transporte en el CITI. Con la informatización de este sistema se logró comprender el funcionamiento del proceso de transporte en la organización, para lo cual se definió una arquitectura de solución basada fundamentalmente en el uso del paradigma BPM y la Arquitectura Orientada a Servicios, exponiendo las ventajas que aportan ambas en desarrollo de aplicaciones. Esta solución permite cumplir con uno de los objetivos más importantes del trabajo: la integración del sistema realizado con otros sistemas existentes y la monitorización de los procesos de negocio. Para cumplir con este objetivo se identificaron y analizaron las tecnologías y herramientas existentes para el desarrollo de aplicaciones orientadas a servicios, los cuales fueron diseñados e implementados conteniendo un conjunto de funcionalidades que garantizan integración, flexibilidad y una alta capacidad para adaptarse al los cambios constantes que ocurren en los procesos de negocio, lo cual dota a la entidad de una mejor calidad en el funcionamiento de la misma. Además con la asimilación de la suite BPM seleccionada, se pudo realizar el despliegue y la ejecución de los procesos de negocio referentes al transporte en el centro, garantizando de esta manera una monitorización de estos, dando una medida de cuáles deben ser optimizados en caso de no cumplir con las expectativas deseadas. También se logró hacer la validación de la solución propuesta de los procesos y la manera en que se llevan a cabo las tareas. Finalmente se realizo un análisis de factibilidad para saber en qué medida era o no factible la realización del sistema, basando este análisis en aspectos importantes a tener en cuenta, como el tiempo necesario para la realización del sistema y el costo que se incurre realizando esta operación. 104

116 RECOMENDACIONES Recomendaciones Continuar en la implementación del sistema de transporte, adicionando nuevas funcionalidades asociadas a las actividades que se llevan a cabo en esta área de la entidad. Seguir profundizando en el estudio de las herramientas BPMS con el objetivo de mejorar la aplicación, sobre todo en la apariencia de los formularios con los que interactúan los usuarios. Optimizar el proceso de negocio Solicitar Transporte, incluyendo en este la planificación de las solicitudes de acurdo con la disponibilidad que se tenga con respecto a los vehículos con los que cuenta el centro para satisfacer los viajes contenidos en las solicitudes. Adicionarle a la arquitectura propuesta el empleo de un Bus de Servicios empresariales (ESB) para gestionar el intercambio de mensajes entre aplicaciones, el cual aporta un valor esencial para la satisfactoria integración de una Arquitectura Orientada a Servicios. 105

117 Referencias Bibliográficas REFERENCIAS BIBLIOGRáFICAS [1] Plan Estratégico del CITI, [2] Transcar, Software para la Gestión del Transporte, disponible en: consultado el 24/01/2011. [3] TranSys, Software para la Gestión de Transporte disponible en: _TranSys_.html, consultado el 24/01/2011. [4] TMS, Sistema de Gestión de Transporte TMS, disponible en: logistics.com/index.php/es/fichas-tecnicas/sistemas-de-informacion-logistica-y-supply- chain/sistema-de-gestion-de-transporte-tms.html, consultado el 22/01/2011. [5] JR-Software, Sistema para el Transporte de Carga, disponible en: consultado el 22/01/2011. [6] Rodríguez, Rolando. La Gestión de los Procesos de Negocio en las Empresas de Telecomunicaciones. ETECSA. Mayo de [7] Rolón, Elvira; Ferreira, Mateus. Marco de Trabajo para la Gestión en el Modelado de Procesos de Negocio. Universidad Autónoma de Tamaulipas-FIANS. Noviembre de [8] Alarcos. Tecnología para la Gestión de Procesos de Negocio. Universidad de Castilla-La Mancha. Noviembre de [9] Procesos de Negocio, Workflow Management Coalition, Febrero de [10] Barros, Oscar (1994) - Reingeniería de Procesos de negocio, Editorial Dolmen, Chile, [11] ISPJAE. Gestión de Procesos de Negocio. Introducción a la Gestión de Procesos de Negocio [12] Van der Aalst, Tom, La minería de Procesos y el futuro de BPM. Abril de [13] Catchpole, Lawrence. Model Your Enterprise: Enabling True Business Process Management through End-to-End Enterprise Modeling. Agosto de [14] Berrocal, Javier; García, José Manuel; Murillo, Juan Manuel. Hacia una gestión del proceso software dirigida por Procesos de Negocio. Universidad de Extremadura. Julio de

118 REFERENCIAS BIBLIOGRáFICAS [15] Object Management Group. Business Process Model and Notation (BPMN).Enero de [16] Alarcos. Tecnología para la Gestión de Procesos de Negocio. Universidad de Castilla-La Mancha. Noviembre de [17] Pérez, Juan Diego. Notaciones y lenguajes de procesos. Una visión global. Universidad de Sevilla. Junio de [18] Ouyang, Chun ; van der Aalst, Wil.Translating BPMN to BPEL. Queensland University of Technology.Febrero de [19] Garimella, Kiran; Lees, Michael y Bruce Williams: Introducción a BPM para Dummies Ed: Wiley Publishing, Inc., Estados Unidos, [20] BizAgi reconocido como CoolVendor en el reporte de CoolVendors de BPM 2010 de Gartner. BizAgi, 9/04/2010, disponible en: ng=es, consultado el 15/04/2011. [21] Díaz, Juan Carlos; otros autores. Business Process Management. El negocio en el centro de los sistemas. Atos Origin, Madrid, [22] Web Services Architecture. The World Wide Web Consortium, 11/2/ (2/10/2009). [23] Newcomer, Eric; Lomow, Greg. Understanding SOA with Web Services. Addison Wesley Professional, Maryland, [24] Información general y conceptual sobre.net Framework. Microsoft Corporation, 2007, disponible en: consultado el 23/04/2011. [25] Microsoft Visual Studio 2010, disponible en: consultado el 05/05/2011. [26] Klein Scott.Pro Entity Framework 4.0.El futuro del acceso de datos en la programación.net, disponible en: consultado el 12/04/2011. [27] Chappell, David. Introducing Windows Communication Foundation in.net Framework 4.Chappell & Associates, Abril de 2009, disponible en: 107

119 REFERENCIAS BIBLIOGRáFICAS 74F1790D4963/Introducing_WCF_in_NET_Framework_4.pdf, consultado el 11/02/2011 [28] El papel de un bus de servicios empresariales (ESB) en una SOA. TIBCO Software, 2006, disponible en: un%20bus%20de%20servicios%20empresariales%20(esb)%20en%20una%20soa.pdf, consultado el 7/01/2011. [29] Oracle. Oracle Database Documentation Library 10g Release.Introduction to the Oracle Database, [30] Taboada, Roberto.Oracle, disponible en: consultado el 18/02/2011. [31] Rosen, Mike; Lublinsky, Boris; Smith, Kevin; Balcer, Marc. Applied SOA.Service-Oriented Architecture and Design Strategies.Wiley Publishing, Inc., Indianapolis, Indiana, [32] Erl, T., Service-Oriented Architecture: Concepts, Technology, and Design. 2005: Prentice Hall PTR. [33] Gracia, J. Que son los patrones de diseño, disponible en: consultado el 25/03/2011. [34] Patrones en.net Introducción al tema de Patrones, con implementaciones en.net, disponible en: consultado el 13/06/

120 Glosario de Términos GLOSARIO DE TéRMINOS Instancia de proceso: Ejecución de un flujo de proceso para valores y momentos específicos. WfMC: Workflow Management Coalition es una comunidad que integra un grupo de organizaciones que se encargan del desarrollo de estándares web. Multiusuario: Se refiere al sistema que puede ser accedido por múltiples usuarios. Multiempresa: Se refiere al sistema que permite manejar los datos de varias empresas, lo que garantiza el control sobre sus clientes. Consultora CSC: Consultoría especializada en software de gestión empresarial, asesoría de dirección y reingeniería de negocio. Xpath: XML Path Language es un lenguaje que permite construir expresiones que recorren y procesan un documento XML. ADO.NET: Es un conjunto de clases que exponen servicios de acceso a datos para el programador, además de ofrecer una abundancia de componentes para la creación de aplicaciones de uso compartido de datos distribuidas. Transporte: El Transporte o Transportación es una actividad del sector terciario, entendida como el desplazamiento de objetos o personas (contenido) de un lugar (punto de origen) a otro (punto de destino) en un vehículo (medio o sistema de transporte) que utiliza una determinada infraestructura (red de transporte). CRM: Siglas en inglés de Customer Relationship Management (en castellano Administración de la Relación con los Clientes). Se trata de una estrategia de negocios enfocada en el cliente y sus necesidades. ERP: Los sistemas de planificación de recursos de la empresa (en inglés ERP, Enterprise resource planning) son sistemas de gestión de información que integran y automatizan muchas de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa. 109

121 GLOSARIO DE TéRMINOS Plataformas heterogéneas: Son aquella que a pesar de tener características físicas distintas entre sí, los sistemas hechos en estas plataformas se pueden comunicar utilizando medios comunes. HTTP: HyperText Transfer Protocol o protocolo de transferencia de hipertexto es el protocolo usado en cada transacción de contenido de páginas web de la World Wide Web. HTTPS: El protocolo de Transferencia de Hiper-Texto (HTTPS) es la versión segura del http que permite realizar transacciones de forma segura. SMTP: Simple Mail Transfer Protocol conocido en español como Protocolo Simple de Transferencia de Correo, es un protocolo de red basado en texto, utilizado para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos. 110

122 anexos Anexos 1. Dimensiones creadas para el análisis. 2. Estado de la cantidad de solicitudes que han sido aprobadas. 111

123 anexos 3. Cantidad de solicitudes que han sido aprobadas por un JefeSolictante en específico. 4. Estado de las tareas de realizar solicitud de un Solicitante específico. 112

124 anexos 5. Estado en que se encuentra la tarea aprobar solicitud de un JefeSolictante en específico. 113