SISTEMA WEB DE INTEGRACIÓN DE LA BANCA PÚBLICA EN VENEZUELA, BANCO BICENTENARIO BANCO UNIVERSAL, C.A. OPERACIONES REGISTRADAS POR TAQUILLA.

Transcripción

1 SISTEMA WEB DE INTEGRACIÓN DE LA BANCA PÚBLICA EN VENEZUELA, BANCO BICENTENARIO BANCO UNIVERSAL, C.A. OPERACIONES REGISTRADAS POR TAQUILLA. Trabajo Presentado como requisito parcial para optar al Grado de Ingeniero de Sistemas. Alumna: Yamilet Ramírez C.I.: Celular: Carrera: Ingeniería de Sistemas 236 Centro Local Metropolitano. Tutores: Académico: MSc. Carmen Maldonado Empresarial: Lic. Liliana Serrano Caracas Marzo de

2 DEDICATORIA Le dedico este trabajo a mi madre y padre, por siempre estar allí. A mis compañeros porque siempre estuvieron presentes para apoyarme y animarme. A mis maestros Alejandro, Pírela y Juan, que me enseñaron el valor de la constancia y disciplina. Gracias a todos! Yamilet Ramírez 2

3 AGRADECIMIENTO A Dios por ser mi guía y estar conmigo en cada instante de mi vida, dándome amor, salud y Bendiciones. A mi esposo Humberto por su apoyo incondicional. A mis hijas Cinthia y Nicole, por ser mis dos más grandes inspiraciones y motivos de crecer. Los amo. consejos. A mi tutora Prof. Carmen Maldonado por su orientación, sabios y oportunos A mis padres y hermanos por confiar siempre en mí y estar allí a pesar de la distancia. compañía. A mis compañeros de trabajo Karina, Jesús y Kenny por brindarme su apoyo y A Banco Bicentenario Banco Universal, C.A, por brindarme las facilidades para desarrollar este proyecto. A todos mis más sinceros agradecimientos. 3

4 SISTEMA WEB DE INTEGRACIÓN DE LA BANCA PÚBLICA EN VENEZUELA, BANCO BICENTENARIO BANCO UNIVERSAL, C.A. OPERACIONES REGISTRADAS POR TAQUILLA. Autor: Yamilet Esther Ramírez de Robledo C.I: V Tutores: Académico: Carmen Maldonado C.I: Empresarial: Liliana Serrano C.I: Fecha: Septiembre de 2014 RESUMEN El presente proyecto consiste, en el desarrollo de un sistema que permita la integración de las operaciones de taquilla de la banca pública, esta propuesta surge de la necesidad que tiene el sistema bancario público de brindar un mejor servicio a todos sus clientes y a su vez llegar a todos los rincones del territorio nacional. En esta primera fase las instituciones financieras que participaran en este proceso son el Banco de Venezuela, Banco del Tesoro y Banco Bicentenario. Las operaciones que se realizaran a través de taquilla en este proceso de unificación serán: Deposito en Efectivo, Pago Tarjeta de Crédito en Efectivo y Depósitos Mixtos (incluye todas las anteriores). El proyecto se realizó con la metodología RUP (Rational Unified Process) y los lenguajes de programación C # y RPG. La aplicación corre en un servidor que contiene el sistema de taquilla, y el detalle del depósito está en el IBS (Sistema Integrado Bancario), que es el core bancario utilizado por la institución, donde incluyen las Aplicaciones de Branch.Net para las transacciones de taquilla. 4

5 LISTA DE TABLAS Tabla 1 Lista superintendentes de Bancos en Venezuela. 16 Tabla 2 Gantt Cronograma del proyecto. 22 Tabla 3 Esquema de trabajos y productos resultantes. 23 Tabla 4 Comparación del modelo de casos de uso con el modelo de análisis. 70 Tabla 5 Comparación entre el modelo de análisis y modelo de diseño 75 5

6 LISTA DE ILUSTRACIONES Figura 1 Historia de RUP 26 Figura 2 Los casos de uso integran el trabajo de Aplicación de la Metodología RUP para 27 el desarrollo rápido de aplicaciones basado en el estándar J2EE Figura 3 Evolución de la arquitectura del sistema. 28 Figura 4 Una iteración RUP. Tomado de Aplicación de la Metodología RUP para el 29 desarrollo rápido de aplicaciones basado en el estándar J2EE. Figura 5 Estructura de RUP. Tomado de Rational Unified Process RUP 30 Figura 6 Diagrama de Actor. Tomado de El lenguaje Unificado de Modelado 37 Figura 7 Diagrama de Casos de Uso. Tomado de El lenguaje Unificado de Desarrollo de 37 Software Figura 8 Diagrama de Casos de Uso. Tomado de El Proceso Unificado de Desarrollo de 38 Software. Figura 9 Tipos de clases. Tomado de Aplicación de la Metodología RUP para el 38 desarrollo rápido de aplicaciones basado en el estándar J2EE Figura 10 Comparación entre el modelo de análisis y el modelo de diseño. 41 Figura 11 Modelo de diseño como una jerarquía de subsistemas de diseño con clases de 41 diseño, realizaciones casos de uso-diseño e interfaces. Figura 12 Atributos claves y asociaciones de una clase de diseño. 43 Figura 13 Modelo de implementación como jerarquía de subsistemas de implementación 46 con componentes e interfaces. Figura 14 Modelado de pruebas 48 Figura 15 El modelo de casos de uso y su contenido 68 Figura 16 El actor 68 Figura 17 El caso de uso 69 Figura 18 Modelo de análisis como una jerarquía de paquetes de análisis con clases de análisis y realizaciones casos de uso. 70 6

7 Figura 19 Atributos esenciales y los estereotipos de un a clase de análisis. 72 Figura 20 Estereotipos de clases estándar de uso en el análisis 72 Figura 21 Modelo de diseño como una jerarquía de subsistemas de diseño con clases de 75 diseño, realizaciones casos de uso-diseño e interfaces. Figura 22 Atributos claves y asociaciones de una clase de diseño. 77 Figura 23 Modelo de implementación como una jerarquía de subsistemas e 80 implementación con componentes e interfaces. Figura 24 Modelo de pruebas 82 Figura 25 Modelo de contexto del negocio 85 Figura 26 Modelo de casos de uso asociado al sistema 87 Figura 27 Diagrama de colaboración del caso de uso solicitar transacción 100 Figura 28 Diagrama de colaboración del caso de uso verificar solicitud 101 Figura 29 Diagrama de colaboración del caso de uso autorizar solicitud 102 Figura 30 Diagrama de colaboración del caso de uso ejecutar soporte 103 Figura 31 Diagrama de colaboración del caso de uso completar servicio 104 Figura 32 Diagrama de colaboración del caso de uso conformar servicio 105 Figura 33 Diagrama de colaboración del caso de uso gestionar reverso 106 Figura 34 Diagrama de colaboración del caso de uso autorizar reverso 107 Figura 35 Diagrama de clase del caso de uso solicitar transacción 108 Figura 36 Diagrama de secuencia del caso de uso solicitar transacción 109 Figura 37 Diagrama de clase del caso de uso verificar solicitud 110 Figura 38 Diagrama de secuencia del caso de uso verificar solicitud 111 Figura 39 Diagrama de clase del caso de uso autorizar transacción 112 Figura 40 Diagrama de secuencia del caso de uso autorizar transacción 113 Figura 41 Diagrama de clase del caso de uso ejecutar transacción 114 Figura 42 Diagrama de secuencia del caso de uso ejecutar transacción 115 Figura 43 Diagrama de clase del caso de uso completar servicio 116 Figura 44 Diagrama de secuencia del caso de uso completar servicio 117 Figura 45 Diagrama de clase del caso de uso conformar solicitud 118 7

8 Figura 46 Diagrama de secuencia del caso de uso conformar solicitud 119 Figura 47 Diagrama de clase del caso de uso gestionar reverso 120 Figura 48 Diagrama de secuencia del caso de uso gestionar reverso 120 8

9 TABLA DE CONTENIDO DEDICATORIA 03 AGRADECIMIENTOS 04 RESUMEN 05 LISTA DE TABLAS 06 LISTA DE ILUSTRACIONES 07 INTRODUCCIÓN 09 CAPÍTULO I EL PROBLEMA 13 Descripción de la Empresa PLANTEAMIENTO Y FORMULACIÓN DEL PROBLEMA 13 OBJETIVOS DE LA INVESTIGACIÓN 18 Objetivo General 18 Objetivos Específicos 18 ALCANCE DEL PROYECTO 19 CAPÍTULO II 23 MARCO TEORICO 23 Antecedentes de la Investigación 24 Banco Bicentenario Banco Universal, C.A 24 Misión de Bicentenario Banco Universal, C.A 24 Visión de Bicentenario Banco Universal, C.A 25 CAPÍTULO III 63 MARCO METODOLOGICO 67 Disciplina Modelado del Negocio 67 Disciplina Requisitos 67 Disciplina Análisis 69 Disciplina Diseño 74 Disciplina Implementación 79 9

10 Disciplina Pruebas 82 CAPÍTULO IV 84 Desarrollo del Proyecto 84 Disciplina de Modelado de Negocio 84 Disciplina Requisitos 87 Disciplina Análisis 100 Disciplina Diseño 108 CONCLUSIONES 128 RECOMENDACIONES 130 REFERENCIAS BIBLIOGRAFICAS 131 ANEXOS

11 INTRODUCCIÓN La vida del hombre está llena de decisiones que deben tomarse cada día y en cada momento, para así resolver cualquier situación o problema. Estas se pueden presentar en diferentes contextos: a nivel laboral, familiar, sentimental, empresarial o en el momento de elegir un servicio o un producto. La toma de decisión es un proceso donde existe la selección entre dos o más alternativas, en el cual el hombre debe seleccionar de acuerdo al problema o situación que se le presente. Cuando se trata de la toma de decisiones, el consumidor puede adoptar diferentes conductas. El comportamiento del consumidor Se puede definir como la conducta o actuación que tiene una persona a la hora de comprar, adquirir, y utilizar un producto o un servicio. A partir de esta definición se busca: estudiar y analizar la forma en la que los individuos toman decisiones para gastar sus recursos (dinero, tiempo, esfuerzo), para así lograr satisfacer sus necesidades y deseos existentes. También busca: conocer cuáles son las variables o influencias que impulsan a los individuos a actuar de cierta forma frente a una marca, producto o servicio en específico. De acuerdo a lo expresado por el autor del estudio de los factores que influyen en la toma de decisión del cliente ante los servicios Bancarios. ( consultado Diciembre 2013). Los usuarios al momento de adquirir, o usar un servicio o un producto se ven influenciados por una diversidad de factores presentes en el individuo y en el entorno, donde éste interactúa cada día. El sexo, la edad, el estado civil, así como la condición económica, influyen fuertemente en el comportamiento del consumidor. De igual forma, aspectos psicológicos como el aprendizaje, la personalidad, la actitud, la motivación y la percepción afectan el proceso de toma de decisión del consumidor. Por otra parte, el entorno también influye en el comportamiento del consumidor, específicamente aspectos tales como la cultura, la subcultura, las clases sociales, la familia y los grupos de referencia. 11

12 El comportamiento del consumidor venezolano ha cambiado significativamente en los últimos años incidiendo en su compra, percepción y forma de adquirir los productos que requiere, y lo que es más importante, discriminando aquellos que le han originado necesidades artificiales. Hoy se detienen a meditar su compra, hacerla más racional, menos impulsiva, lo que con lleva a que la gerencia de mercados se detenga a evaluar los hábitos, costumbres, tradiciones de compra del actual consumidor. Estas evaluaciones o estudio de mercado no son de uso exclusivo de empresas que fabrican un producto en específico para comercializarlo; también recurren a éstos las empresas de servicios, que desean saber cuáles son los gustos, exigencias de sus usuarios y/o clientes para así diseñar estrategias que le permitan satisfacer sus necesidades y por ende tener un cliente satisfecho. Las instituciones financieras y específicamente las entidades bancarias no escapan de esta realidad. Buscan conocer sus clientes, sus gustos, necesidades, para así diseñar y ofrecerles productos/servicios que procuren su satisfacción y su preferencia. Las entidades bancarias, según Rojas (2011) Son un conjunto de instituciones que permiten el desarrollo de todas aquellas transacciones entre personas, empresas y organizaciones que impliquen el uso de dinero. Estas instituciones se encargan de ciertas actividades como recibir depósitos, realizar transacciones, conceder préstamos, cajas de seguridad, y otros servicios, como asesoramiento financiero. A través de los servicios que ofrece un banco tiene como finalidad de cubrir todas las necesidades del consumidor. El sistema bancario de Venezuela se caracteriza por estar dominado por la banca privada nacional, seguida de la banca pública o estatal, los cuales lograron un crecimiento importante a través de los diversos cambios experimentados, tras algunas fusiones y liquidaciones de entidades financieras en Venezuela. A finales del 2009 comienza un proceso de fusión entre los bancos de estrato grande y mediano de la banca venezolana, de 123 instituciones bancarias que existían en 1996 pasaron 12

13 a funcionar 58 en 2006, en donde destaca 38 procesos de fusiones. Algunos bancos como el Banco de Venezuela y el Banco Caracas son adquiridos por el Grupo Santander, que fusionaría el último en Banco de Venezuela; el Banco Provincial se hizo con el control del Banco Lara fusionándolo; el Banco Mercantil absorbió a Inter Bank; mientras que el Banco Unión se fusionaría con Caja Familia creando en 2001 Unibanca, este banco realizó la mayor campaña publicitaria jamás vista en Venezuela desde la fundación de la banca un año después sería adquirido por Banesco que era un banco mucho menor que Unibanca. Para el año 2009 surge la fusión de cinco (5) instituciones financieras: Bolívar Banco, Central Banco Universal, Banco Confederado, Banco Banorte y Banco de Fomento Regional Los Andes. Quienes pasaron a convertirse en Banco Bicentenario, Banco Universal, C.A. El 16 de Diciembre del 2009, por disposición del Presidente de la República Bolivariana de Venezuela, Sr. Hugo Rafael Chávez Frías, de conformidad con lo establecido en la Gaceta Oficial , de fecha 16 de Diciembre de 2009, según resolución N La Institución expresa, en su accionar diario, una propuesta progresista y humanista en el marco del Plan de Socialización de la Banca Pública, exponiendo al ser humano como factor primordial de la toma de decisiones en la gestión del Banco. En el presente Trabajo se expone el estudio que permitirá el desarrollo de un sistema de integración de la Banca Pública, que permita administrar y controlar operaciones de taquilla para Banco Bicentenario, Banco del Tesoro y Banco de Venezuela. Este proyecto estará liderizado y monitoreado por la Gerencia General de Calidad Integral adscrita a la V.P. Gestión Tecnológica y Procesos (Banco Bicentenario, Banco Universal, C.A). En donde se realizará la implementación de dicha propuesta. Aunado a lo anterior, el Banco Bicentenario, brinda una extensa red de servicios a todos sus clientes, con altísima calidad, y el uso de las tecnologías más avanzadas en materia 13

14 bancaria, así como servicios crediticios, concatenados con las necesidades humanas y en sintonía indivisible con una estricta y sólida vigilancia a los depósitos de sus ahorristas. Su sede central está ubicada en Caracas, su radio de acción abarca todo el territorio venezolano a través de su amplia red de oficinas. Actualmente cuenta con 514 oficinas a nivel nacional, su actividad financiera tiene como principio fundamental la bancarización de los sectores más desprotegidos de la nación, incluyéndolos dentro del sector financiero venezolano, a través de su amplia gama de productos. Conscientes del interés de la Banca Pública en brindar un mejor servicio a todos sus clientes, el Ministerio de finanzas realizo el requerimiento del proyecto propuesto el cual busca la unificación de la Banca Pública en Venezuela. El mismo se realizará, durante el período de prácticas profesionales, en la Gerencia General de Calidad Integral adscrita a la V.P. de Gestión Tecnología y Procesos. Para la realización de este trabajo se tendrá como marco de referencia el desarrollo de un software en ambiente web, se contará con un Manejador de Base de Datos y un lenguaje de Programación Orientado a Objeto lo cual será de mucha utilidad para poner en práctica y afianzar los conocimientos adquiridos a lo largo de la carrera de Ingeniería de Sistemas. Se utilizará RUP ((Rational Unified Process o el Proceso Unificado de Desarrollo) como metodología a desarrollar, ya que esta nos permite garantizar la creación de un sistema que cumpla con los requisitos establecidos, debido a la aplicación de sus distintas fases o procesos que son adaptables, previsto para ser ajustado por los equipos de proyecto de las organizaciones y los equipos de desarrollo de software que seleccionarán los elementos apropiados para cubrir las distintas necesidades. 14

15 CAPÍTULO I EL PROBLEMA Descripción de la Empresa En este capítulo se procederá a describir la situación actual, a través del planteamiento del problema, realizando para ello, una explicación detallada de la situación actual que se presenta en el Banco Bicentenario Banco, C.A, para ubicarse en el contexto de la situación. Igualmente se presente el objetivo general del proyecto, los objetivos específicos que se deriven de dicho objetivo, así como el alcance del mismo. Planteamiento y Formulación del Problema Se ha demostrado que el sector financiero tiene un papel fundamental en el crecimiento económico de las naciones. De acuerdo con Goldsmith (1969), King y Levine (1993) y McKinnon (1973,1989), existe una relación entre la profundidad de los mercados financieros y el desarrollo económico. Este desarrollo se define como el proceso mediante el cual se introduce materia económica en la economía de una nación, y se transfiere una parte a otra (Kuznets, 1958), y tiene la finalidad de traducirse en mejoras en la calidad de vida de sus ciudadanos. Estas investigaciones apoyan el postulado de Schumpeter (1911), que describe que los servicios prestados por el sistema financiero influyen positivamente en el crecimiento económico. Sin embargo, Robinson (1952) sugiere que, en contraste a Schumpeter, es el desarrollo económico el que influye en el sistema financiero, argumentando que cuanta más actividad económica exista en una nación, tanto mayor será la demanda de productos y servicios del sector financiero. 15

16 Cada institución financiera que hace vida en una sociedad, en un país, bien sean públicas o privadas, tienen una misión que cumplir de acuerdo a lo que esta sociedad les requiere y demanda, para el beneficio de los ciudadanos que la conforman y el consecuente desarrollo personal, colectivo e institucional. Sin embargo estas instituciones con un particular rol que les corresponde, se unen para un fin común, o interactúan entre sí, esa misión particular y las posibilidades de cubrir las expectativas que sobre ellas tienen los ciudadanos se potencian más allá de una simple suma de voluntades. Para hacer esto posible las instituciones financieras deben estar sujetas ante el ente regulador, que es la Superintendencia de las Instituciones del Sector Bancario de Venezuela (SUDEBAN). Es el ente encargado de que los bancos e instituciones financieras con oficina en Venezuela cumplan las normas locales referidas para cada una de ellas. Se encuentra adscrito al Órgano Superior del Sistema Financiero Nacional, que a su vez depende del Ministerio del Poder Popular para las Finanzas. Entre las actividades y responsabilidades de la SUDEBAN se encuentran las siguientes: Autorizar, supervisar, inspeccionar, controlar y regular el ejercicio de la actividad que realizan las instituciones que conforman el sector bancario de Venezuela. Señalar la corrección de las fallas que se detecten en la ejecución de las actividades bancarias y sancionar las conductas desviadas al marco legal vigente. Las instituciones regidas actualmente por SUDEBAN, se muestran a Continuación: Banco de Venezuela Banesco BBVA Banco Provincial Banco Mercantil Bicentenario Banco Universal Banco Occidental de Descuento Banco Fondo Común Banco Exterior 16

17 Banco del Tesoro Banco Industrial de Venezuela Banco Nacional de Crédito Corp Banca (Venezuela) BanCaribe Venezolano de Crédito Banco Caroní Banco Agrícola de Venezuela Banco Sofitasa Banco Plaza Banco del Sur Citibank Venezuela 100% Banco Banco Activo Banplus Banco Espíritu Santo (Venezuela) Banco Internacional de Desarrollo Banco de Exportación y Comercio. Lista de Superintendentes de la SUDEBAN: (Galería de superintendentes SUDEBAN 2014). Consultado el 30 de mayo de Superintendentes de Bancos de Venezuela Superintendente (a) Período Carlos Rafael Silva Guillermo Pimentel Marco Lucy G Alfredo Masso Martinez Leopoldo Ramírez Jesús Tovar Villegas Juan Ramírez Giraud Victor Saúl Gutierrez Roger Urbina Marte

18 Tesalio Cadenas Berthier Francisco Debera Alejandro Cáribas Antonio Simancas 2002 Irving Ochoa Trino Alcides Díaz Maria Elena Fumero Mesa 2008 Edgar Hernández Mary Espinoza de Robles 2014 Tabla 1 Lista Superintendentes de Bancos de Venezuela Fuente: Elaboración propia En la actualidad el sistema de la Banca Pública en Venezuela se encuentra compuesto por las siguientes instituciones financieras: Banco Agrícola de Venezuela, C.A, Banco Universal. Banco de Venezuela, S.A, Banco Universal. Banco del Tesoro, C.A, Banco Universal. Banco Industrial de Venezuela, C.A, Banco Universal. Banco de la Fuerza Armada Nacional Bolivariana, C.A (BANFANB). Banco del Pueblo Soberano, C.A. Banco Bicentenario, C.A, Banco Universal. Para este proyecto se concibió en su primera fase trabajar con las siguientes instituciones del sector público: Banco de Venezuela, S.A, Banco Universal. Banco del Tesoro, C.A, Banco Universal. Banco Bicentenario, C.A, Banco Universal. Siendo estas tres (3) instituciones públicas las más grandes del país por su amplio alcance a nivel nacional, Banco de Venezuela 289 oficinas, Banco del Tesoro con 118 oficinas, Banco Bicentenario con 514 oficinas, lo que hace una suma total de 925 oficinas a nivel 18

19 nacional, que en esta primera fase se estarían integrando para prestar un mejor servicio. En la Actualidad el sistema de Banca Pública presenta dificultades para penetrar y alcanzar a todos los rincones del país, el volumen de usuarios por oficinas es muy elevado lo hace que el tiempo de espera de nuestros clientes en las oficinas tome mucho tiempo, no logrando de esta manera brindar la calidad de servicio que todos nuestros clientes merecen. Es por esta razón que el Ministerio de Finanzas, se vio en la urgente necesidad de buscar una solución a esta problemática y de esta manera surge el proyecto de Integración de la Banca Pública, esto con la finalidad, de que todos aquellos clientes que mantienen cuentas en cualquiera de estas tres (3) instituciones financieras ya mencionadas, puedan realizar sus operaciones y transacciones de taquilla desde cualquier oficina a nivel nacional en cualquiera de estas instituciones bancarias manteniendo los privilegios del Banco al cual se corresponde la cuenta del cliente. Esto quiere decir que el Banco que reciba la operación del cliente, indistintamente si no es cliente de la institución, mantendrá los mismos tiempos de respuesta que mantienen en el Banco tutor de la cuenta. Cada institución financiera asumirá un nivel de riesgo reputacional, legal y operacional, activando todos los niveles de seguridad con la finalidad de brindar con eficiencia, pronta respuesta al cliente. Logrando así, unificar las instituciones que conforman el Sistema Bancario Público nacional, mediante la optimización de los procesos internos de taquilla y la estandarización de la plataforma tecnológica que actualmente posee cada una de las Instituciones. Es por ello, que en este trabajo se plantea el diseño de un sistema, que una vez implementado permitirá mejorar los tiempos de respuestas del servicio de operaciones de taquilla en la Banca Pública de nuestro país. 19

20 OBJETIVOS DE LA INVESTIGACIÓN Objetivo General Diseñar e implementar un sistema web que ofrezca a los usuarios la integración de la Banca Pública, permitiéndoles realizar sus operaciones de taquilla desde cualquiera de estas instituciones financieras. Objetivos Específicos 1. Estudiar la Metodología Proceso Unificado de Desarrollo (RUP). 2. Detectar las necesidades institucionales en materia de servicios financieros para el seguimiento de actividades similares, a fin de indagar sobre posibles herramientas de control de gestión preexistentes que puedan ser aprovechables. 3. Diseñar un sistema a nivel conceptual y lógico. Para la integración de la banca pública. 4. Construir el sistema del software propuesto. 5. Realizar las pruebas respectivas al producto final. 20

21 Alcance del trabajo El alcance del trabajo cubrirá hasta la elaboración del diseño del sistema unificación de la Banca Pública, que servirá de esquema para la posterior implementación. Se realizará un sistema de manera flexible y estable que responda correctamente a futuros cambios que puedan ser soportados manteniendo la eficiencia y robustez del mismo. Se efectuarán las pruebas necesarias para avalar el correcto funcionamiento del sistema considerando todas las bondades que el mismo ofrecerá y de ser exitosas existe la posibilidad de considerar la segunda fase que incluya otras operaciones de taquilla. Siendo esta opción intangible ya que dependerá exclusivamente de la alta directiva dar estos lineamientos. En el marco metodológico se planea utilizar únicamente seis de los nueve flujos de trabajo que propone RUP, las razón principal es que la administración del proyecto sería realizada por el mismo Director del proyecto que realizará casi todos los roles; al prescindir de un equipo de trabajo y debido a la magnitud del proyecto se plantea que su administración será planificada y se respetaran los tiempos de respuestas de acuerdo al cronograma de actividades. Con respecto al flujo de configuración y control de cambios, su no inclusión en este proyecto se justifica con la misma razón. En el proyecto se realizaran todas las pruebas que se consideren necesarias para garantizar su perfecto funcionamiento, motivado que forma parte fundamental en la metodología que se ha sugerido para su desarrollo. Una vez culminado todo el proceso de validación de las pruebas con las otras dos (2) instituciones financieras, quedara de parte de la alta directiva salir a producción implementando el sistema en el sistema de Banca Pública. Por lo anteriormente planteado se tiene que el alcance metodológico queda definido por los siguientes flujos (distribuidos entre las cuatro (4) fases de RUP) (Ver Tabla N 1): a. Modelado del negocio. b. Requisitos. c. Análisis. 21

22 d. Diseño. e. Implantación. f. Pruebas. Su alcance geográfico es amplio a nivel nacional por la cantidad de agencias que tienen cada una de estas instituciones financieras, Banco de Venezuela con 289 oficinas, Banco del Tesoro con 118, Banco Bicentenario con 514 oficinas. Los que sumaría un total de 921 oficinas en todo el territorio nacional. Lo que tiene un alcance social de impacto ya que todos los clientes de cualquiera de estas tres (3) instituciones financieras pueden realizar sus operaciones indiferentemente sea este Banco el tutor de su cuenta. El esquema de conexión a utilizar será Metro-Ethernet, para la comunicación entre las tres (3) Instituciones Financieras. - 22

23 CAPÍTULO II MARCO TEÓRICO En este capítulo se presenta un resumen de algunas de las investigaciones que han sido realizadas anteriormente, y que guardan relación con el objetivo general y los objetivos específicos del proyecto. Del mismo modo se presentan todas las bases teóricas para el desarrollo de este estudio, que consiste en el uso de terminología y conceptos asociados o utilizados en el área de la Banca Pública, los cuales soportan el presente estudio. Por último, se presenta la reseña histórica del sistema financiero en Venezuela. Felipe (2003) realizo un estudio sobre la determinación de la plantilla de operaciones de la red de oficinas de una Institución Bancaria, para mejorar los niveles de atención al cliente. En donde se plantearon la necesidad de crear un modelo a seguir para la satisfacción del cliente, lo que busco fue reducir el tiempo de espera del cliente en las oficinas. Este estudio fue realizado en el Banco de Venezuela impactando a una red de oficinas de 269 a nivel nacional. También señala Felipe que cada una de las oficinas de la red, proporcione un servicio a su clientela en tres grandes áreas de atención al cliente, como lo son: servicio, venta y taquilla. Es fácil observar que de acuerdo a la investigación realizada y tomando en cuenta las sugerencias del autor de aquel informe, es necesario plantearse soluciones que aporten mejoras a la calidad del servicio, siendo esta uno de los factores más influyentes y determinantes para el rendimiento del Banco. 23

24 Banco Bicentenario Banco Universal C.A. Banco Bicentenario, es una institución financiera que forma parte de la Banca Pública nacional, nace para establecer un nuevo concepto de hacer banca, sentando las bases para la inclusión de todas y todos los venezolanos al sistema financiero nacional, en igualdad de condiciones. Fue creado de la fusión entre el Banco de Fomento Regional Los Andes y los bancos nacionalizados Bolívar Banco, Central Banco Universal, Banco Confederado y Banorte. Iniciando sus operaciones en diciembre del Refleja la nueva manera de hacer banca, con sentido socialista, que permita que aquellos venezolanos que no tiene acceso a los servicios de la banca tradicional, se sientan identificados con una institución con un fuerte sentido de responsabilidad e inclusión social. El Gobierno Bolivariano de Venezuela, reafirma y consolida el valor de nuestro gentilicio, con una institución que responde oportunamente a los requerimientos de un alto porcentaje de nuestra población, que no tiene acceso a los servicios bancarios. (Ver Figura 2) Organigrama de la V.P. de Gestión Tecnológica y Procesos. Misión de Banco Bicentenario Banco Universal, C.A Crear y desarrollar soluciones financieras y de valor a nuestros clientes y empleados a través de la entrega de productos y servicios adaptados a sus necesidades, garantizando el crecimiento y acceso de todas las personas a la banca. 24

25 Visión de Banco Bicentenario Banco Universal, C.A Será la institución bancaria de referencia nacional de mayor arraigo y prestigio, orientada al crecimiento de sus clientes y empleados, contribuyendo al desarrollo del país y el proyecto socialista, a través de la generación de bienestar y progreso. Rational Unified Process (RUP) Desde la crisis del software a finales de los años 60, que generó la creación del término ingeniería del software, se empezó a utilizar diferentes metodologías para el desarrollo exitoso de los programas necesarios para la industrias, empresas, gobiernos y en fin, para el usuario en general. Según Jacobson, Booch y Rumbaugh En la ingeniería del software el objetivo es construir un producto software o mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficiente de software de calidad. (p.xvi). Actualmente, muchas de estas metodologías se basan en los principios básicos que surgieron gracias a la ingeniería del software; estos nombrados en una manera muy general son: análisis, diseño, implantación y soporte. Estos principios juntos conforman lo que se conoce como el ciclo de vida de un sistema. La mayor parte de las metodologías lo utilizan con mayores o menores variaciones; tal es el caso de la metodología RUP (Rational Unified Process por sus siglas en ingles). Esta metodología data desde 1967 como el antecedente más importante, la cual se conoció como la Metodología Ericsson (Ericsson Approach) elaborada por Iván Jacobson. Luego entre loa años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory). Es en el año 1995 cuando Rational Software Corporation compra Objectory AB y posteriormente entre 1995 y 1997 se desarrolla Rational Objetory Process (ROP) tomando 25

26 como base Objetory 3.8 y del Enfoque Rational Approach) adoptando UML como lenguaje de modelado. Es en el año de 1995 cuando Rational Software Corporation compra Objectory AB y posteriormente entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) tomando como base Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado. Desde aquel entonces y con Grandy Booch, Ivan Jacobson y James Rumbaugh dirigiendo los cambios, Rational Software desarrolló e incorporó diversos elementos para mejorar y expandir ROP, enfatizándose en particular el flujo de trabajo conocido como modelado de negocio. Para el verano del 1998 liberan para el público en general, el Rational Unified Process. Figura 1: Historia de RUP. Tomado de APLICACIÓN DE LA METODOLOGIA RUP PARA EL DESARROLLO RÁPIDO DE APLICACIONES BASADO EN EL ESTÁNDAR J2EE por Rueda, J. (2006). (p.7). 26

27 RUP hace mención a tres características principales que la diferencian en gran medida de otras metodologías, estas son: Dirigidas por casos de uso: Los casos de uso son una técnica de obtención de requisitos en la cual se debe pensar más en términos de importancia para el usuario que en términos de las funciones que sería bueno contemplar, esto ayuda a garantizar que el producto obtenido al final del proceso presenta las utilidades que el usuario realmente desea. En este caso podríamos decir que la definición más acertada de un caso de Uso sería: un fragmento de funcionalidad del siatema que proporciona al usuario un valor agregado. Los casos de Uso representan los requisitos funcionales del sistema. Para la metodología RUP los casos de Uso no solo son una herramienta más para especificar los requisitos que el sistema debería tener. Ellos también guían su diseño, implementación y prueban como se puede observar en la figura 2. Los Casos de Uso constituyen un elemento integrador y una guía de trabajo. Requisitos Análisis & Diseño Implementación Casos de Uso integran el trabajo Capturar, definir y validar los casos de uso Realizar los casos de uso Pruebas Verificar que se satisfacen los casos de uso Figura 2: Los casos de Uso integran el trabajo. Tomado de APLICACIÓN DE LA METODOLOGIA RUP PARA EL DESARROLLO RÁPIDO DE APLICACIONES BASADO EN EL ESTÁNDAR J2EE por Rueda, J. (2006). (p. 9). 27

28 Centrada en la arquitectura: La arquitectura abarca los aspectos estáticos y dinámicos de mayor relevancia del sistema, se relaciona con la toma de decisiones que orienta en qué manera debe ser constituido el sistema y en qué orden. Aparte, la arquitectura debe tomar en cuenta los elementos de calidad del sistema, reutilización, rendimiento y capacidad de evolución, razón por la cual debe ser flexible, mientras que dure el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de base de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema. Para RUP, es importante destacar el establecimiento temprano de una buena arquitectura para evitar que en las fases de construcción y mantenimiento se necesiten realizar cambios muy bruscos o fuertes. A nivel de arquitectura, se tiene una estructura más robusta hacia las fases finales del proyecto. En las fases iniciales, la intención es consolidar la arquitectura a través de baselines y modificar posteriormente según lo exijan las necesidades del proyecto. (Ver figura 3.) Figura 3: Evolución de la arquitectura del sistema. Tomado de APLICACIÓN DE LA METODOLOGIA RUP PARA EL DESARROLLO RÁPIDO DE APLICACIONES BASADO EN EL ESTÁNDAR J2EE por Rueda, J. (2006). (p. 11). 28

29 Los procesos son iterativos e incrementales: en RUP, para cada fase se tiene una serie de flujos de trabajo que de acuerdo a la fase en que se encuentre arrojo determinados productos o artefactos. Estos flujos de trabajo se realizan en forma iterada para garantizar que al pasar a la siguiente fase se cumplieron con los objetivos propuestos en la fase anterior. La iteráctividad se logra principalmente a través de la división del trabajo en partes más pequeñas o mini proyectos, con esto, se consigue un equilibrio entre los casos de uso y la arquitectura, equilibrio que se mantiene por todo la duración del proyecto o en otras palabras, las iteraciones son la ejecución de los flujos de trabajo para desarrollar los mini proyectos. (Ver figura 4.) Requisitos Análisis Diseño Implementación Prueba e integración Una iteración Figura 4: Una iteración RUP. Tomado de APLICACIÓN DE LA METODOLOGIA RUP PARA EL DESARROLLO RÁPIDO DE APLICACIONES BASADO EN EL ESTÁNDAR J2EE por Rueda, J. (2006). (p. 13). Estas características mencionadas anteriormente se aplican a la metodología en general, sin embargo, esta metodología se puede describir de otra forma; RUP funciona en cuatro (4) fases que son inicio, elaboración, construcción y transición; y por cada fase ejecuta 29

30 los flujos de trabajo, los cuales se dividen en flujos de control de proceso: son modelado del negocio, requisitos, análisis y diseño, implementación, prueba, despliegue y flujos de control de apoyo: configuración y manejo del cambio, administración del proyecto, entorno. Describiéndolo en dos dimensiones o ejes (Ver figura 5): Eje horizontal: Se considera como el tiempo y grafica al eje de los aspectos dinámicos del proceso. Muestra las características del ciclo de vida del proceso expresándola como fases, iteraciones e hitos. Eje Vertical: Muestra los llamados aspectos estáticos del proceso y describe los mismos a través de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles. Figura 5: Estructura de RUP. Tomado de Rational Unified Process RUP. (p.8) 30

31 En relación al eje horizontal, el cual se menciono anteriormente representa al tiempo distribuido por fases, se puede ver desde la siguiente perspectiva, desglosando y refiriendo a cada fase como productos independientes: 1. Fase de inicio o Conceptualización: En esta primera fase se debe realizar una completa descripción tanto del negocio como tal del proyecto a partir de una idea de desarrollo. Para determinar la visión del proyecto. Define el ámbito y objetivos del proyecto. Se desarrolla una descripción del producto final a partir de una buena idea. Se define la funcionalidad y capacidades del producto. Esta fase responde a las siguientes preguntas: Cuáles son las principales funciones del sistema para los usuarios más importantes? Cómo podría ser la arquitectura del sistema? Cuál es el plan de proyecto, y cuánto costará desarrollar el producto? 2. Fase de elaboración: Tanto la funcionalidad como el dominio del problema se estudian en profundidad. Se define una arquitectura básica. Se planifica el proyecto considerando recursos disponibles. Se especifica en detalle la mayoría de los casos de uso del producto. 3. Fase de construcción: El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación. Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura). Gran parte del trabajo es programación y pruebas. 31

32 Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con la documentación. La arquitectura básica es refinada de manera incremental hasta convertirse en el sistema completo. 4. Fase de transición: Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de marketing, empaquetado atractivo, instalación, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior. Estas tareas se realizan también en iteraciones. Cada paso con las cuatro fases produce una generación o versión del software. Luego el producto se desarrollará nuevamente repitiendo la misma secuencia las fases de concepción, elaboración, construcción y transición, pero con diversos énfasis cada fase. Se observa también en la figura 5 que de acuerdo a la fase en que se encuentre, varia el esfuerzo dedicado a cada flujo de trabajo; por ejemplo, el esfuerzo dedicado a los flujos de modelado del negocio y requisitos tiende a ser mayor en las fases de inicio y elaboración que en las fases de construcción y transición, de igual manera los flujos concernientes a implementación, prueba y despliegue cobran mayor esfuerzo y dedicación hacia las fases finales, aunque no se encuentran limitadas en el inicio del proyecto. Otro punto a favor de RUP es la adaptabilidad que presenta, puesto que sirve igual tanto para proyectos grandes como para proyectos de mediana y pequeña envergadura. En la adaptabilidad de RUP para la creación de software eficientes y de calidad que sean de mediana y pequeña envergadura, no es necesario considerar todos los flujos de trabajo, sino más bien aquellos principales que permitan el desarrollo del proyecto con éxito. 32

33 Según Rueda (2006) las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo (p.41). Las primarias son las requeridas para realizar un proyecto de software, aunque en proyectos pequeños se pueden omitir algunas. Las disciplinas primarias son: Modelado del Negocio, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Despliegue. Las de apoyo son: las que sirven de soporte a las primarias y especifican otras características en la realización de un proyecto de software; entre estas se tienen: Entorno, Gestión del Proyecto, Gestión de Conción y Cambios. Las disciplinas o flujos de trabajo de RUP se pueden describir de la siguiente manera: 1. Modelado del negocio: Esta disciplina tiene como objetivos comprender la estructura y la dinámica de la organización, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de Casos de Uso del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada caso de uso del Negocio con los Trabajadores, además utilizan los Diagramas de Actividad y de Clases. 2. Requerimientos: Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el Modelo de Casos de Uso para modelar el Sistema que comprenden los Casos de Uso, Actores y Relaciones, además utiliza los diagramas de Estados de cada caso de uso y las especificaciones suplementarias. 3. Análisis y diseño: Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación, al decir análisis se refiere a transformar casos de uso en clases, y al decir diseño se refiere a refinar el 33

34 análisis para poder implementar los diagramas de clases de análisis de cada caso de uso, los diagramas de colaboración de cada caso de uso, el de clases de diseño de cada caso uso, el de secuencia de diseño de caso de uso, el de estados de las clases, el modelo de despliegue de la arquitectura. 4. Implementación: Esta disciplina tiene como objetivos implementar las clases de diseño como componentes (ejemplo el fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementación, conjuntamente los Diagramas de Componentes para comprender cómo se organizan los Componentes y dependen unos de otros. 5. Pruebas: Esta disciplina tiene como objetivos verificar la integración de los componentes (prueba de integración), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribución. 6. Despliegue: Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente, proceder a su entrega y recepción por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como la tarea de enseñar al usuario. 7. Configuración y gestión de cambios: Es esencial para controlar el número de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se había arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: 34

35 Actualización simultánea: Es la actualización de algo elaborado con anterioridad, sin saber que alguien más lo está actualizando. Notificación limitada: Al realizar alguna modificación, no se deja información sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones múltiples: No saber con exactitud, cual es la última versión, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones. Actualización simultánea: Es la actualización de algo elaborado con anterioridad, sin saber que alguien más lo está actualizando. Notificación limitada: Al realizar alguna modificación, no se deja información sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones múltiples: No saber con exactitud, cual es la última versión, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones. 8. Administración del proyecto: Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con éxito (los que pagan el dinero) y los usuarios. Con la Gestión del Proyecto se logra una mejoría en el manejo de una entrega exitoso de software. En resumen su propósito consiste en proveer pautas para: Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo. 9. Entorno: Esta disciplina se enfoca sobre las actividades necesarias para dar soporte al proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto. Su propósito es proveer a la organización que desarrollará el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software. 35

36 Unified Modeling Languaje (UML) UML es el lenguaje unificado de modelado, creado a partir de la unificación de por lo menos unos veinte lenguajes ya estándares y las metodologías para la programación orientada a objetos que ya poseían sus tres fundadores, J. Rumbaugh, G. Booch e I. Jacobson; originando así este nuevo lenguaje (ya un estándar establecido) que es Unified Modeling Languaje. La principal razón del UML es la de modelar en forma clara, sencilla y precisa, situaciones del mundo real, para que con ayuda de sus múltiples y variadas técnicas generen modelos que sean entendibles para los usuario y clientes tanto como para los desarrolladores y todos aquellos del equipo de producción de software. Así lo comentan Rumbaugh, Booch y Jacbson (2000): Un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para capturar decisiones y conocimientos sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener, y controlar la información sobre tales sistemas (p. 3). Los mejores beneficios de UML son mencionados en el párrafo anterior por el autor, sin embargo, no mencionan algunas de sus herramientas más útiles en este proyecto como lo son: los diagramas de actores, diagramas de caso de uso, diagramas de clases, diagramas de colaboración (también llamados diagramas de comunicación), diagramas de secuencia, diagramas de despliegue, diagramas de estado, diagramas de objetos, diagramas de componentes, diagramas de actividades. 36

37 En UML, la parte grafica es esencial, debido a que facilita el claro entendimiento entre analistas, desarrolladores y usuarios del sistema a crear. Por esta razón es imposible excluir de esta reseña los debidos diagramas con sus referencias escritas: Los diagramas de actores muestran cada usuario del sistema como un actor, representado por un monigote, como se puede apreciar en la figura 6. Vendedor Figura 6: Diagrama de Actor. Tomado de El lenguaje Unificado de Modelado. Manual de Referencia por Jacobson, I., Booch G y Rumbaugh J. (2000). (p.24) El caso de uso representa un conjunto de secuencia de acciones que ejecuta el sistema y que producen un resultado apreciable para un actor en particular. Representa una funcionalidad que ofrece un resultado de valor para los actores. El caso de uso se representa de la siguiente manera. (Figura 7 y 8). Sacar Dinero Figura 7: Diagrama de casos de uso. Tomado de El lenguaje Unificado de Desarrollo de Software por Jacobson, I., Booch G y Rumbaugh J. (2000). (p.129) 37

38 Sacar Dinero Depositar Dinero Transferencia entre Cuentas Figura 8: Diagrama de casos de uso. Tomado de El Proceso Unificado de Desarrollo de Software por Jacobson, I., Booch G y Rumbaugh J. (2000). (p.39) El diagrama de clases extrae de acuerdo a varias técnicas, las clases del sistema, debidamente categorizadas de acuerdo a interfaz (también llamada de borde ó de frontera), entidad y control; siendo la primera de esta categoría el tipo de clase que se encarga de interactuar con el usuario, el usuario, el segundo tipo de clase almacena información mientras que el tercero se encarga de realizar cálculos y operaciones. Estos tres estereotipos están estandarizados en UML y se usan para apoyar a los desarrolladores para diferenciar el ámbito de las diferentes clases. Cada estereotipo tiene su propio símbolo (Ver Figura 9 ). Figura 9: Tipos de clases. Tomado de APLICACIÓN DE LA METODOLOGÍA RUP PARA EL DESARROLLO RÁPIDO DE APLICACIONES BASADO EN EL ESTÁNDAR J2EE por Rueda, J. (2006). (p.37) 38

39 Gracias a los diagramas de estado es posible marcar los comportamientos que tienen los sistemas software, es decir, se define como serán los estados del software, a donde ir según cada opción que tendrá desde el inicio hasta el final. Los diagramas de actividad muestran, una vista al sistema desde una perspectiva dinámica; en pocas palabras muestran el flujo de acciones de actividad. Un diagrama de interacción grafica a través de varios símbolos pertenecientes a una notación especial, una colección de objetos con sus respectivas relaciones considerando los mensajes que entre ellos puedan surgir. Este diagrama trata la vista dinámica del sistema; dos ejemplos de diagramas de interacción son los diagramas de colaboración y los diagramas de secuencia. El diagrama de componentes se refiere más a la vista estática del sistema; muestra una serie de componentes (unidades físicas de implementación que pueden operar entre sí gracias a interfaces de modo que puedan ser remplazadas en algún momento por otro componente que cumpla la misma función) que interactúan entre sí por medio de diversas relaciones. Con el diagrama de colaboración se pretende graficar la comunicación que tienen entre si los distintos componentes de un sistema. Dicho de otra forma, modela una operación incluyendo el orden secuencial en que esta debe realizarse y los mensajes que se transmiten entre las clases u objetos que existan en la operación. El diagrama de secuencia muestra la misma información que el diagrama de colaboración pero desde una perspectiva menos estructural. Con este diagrama las secuencias en el tiempo se pueden apreciar de una forma más clara que con un diagrama de colaboración. Acá el ordenamiento de los componentes del diagrama se realiza en forma vertical y descendente desde el inicio de la operación hasta su final. Con los diagramas de despliegue se presentan los nodos del sistema y sus componentes, o lo cual es igual, es un diagrama que modela todo el hardware utilizados en las implementaciones de un sistema software y las relaciones entre estos. 39

40 Disciplina Diseño El propósito fundamental de esta etapa es crear el modelo de diseño tomando como entrada principal el modelo de análisis, adaptándolo al entorno de implementación, para que funcione como esquema para la implementación. Los principales propósitos del diseño son: Definir una entrada apropiada y un punto de partida para actividades de implementación subsiguientes, capturando los requisitos o subsistemas individuales, interfaces y clases. Comprender en profundidad los aspectos asociados a los requisitos no funcionales y restricciones relacionadas con los lenguajes de programación, sistemas operativos, manejadores de bases de datos, tecnología asociadas a interfaz de usuario distribución y concurrencia, etc. Dividir los trabajos de implementación en componentes más manejables, para que puedan ser desarrollados independientemente por varios equipos de desarrollo, tomando en cuenta el tema de la concurrencia. El resultado del análisis, es decir el modelo de análisis, es el insumo esencial en la etapa de diseño, tal como se muestra en el siguiente cuadro resumen (Ver figura 10). 40

41 Figura 10: Comparación entre el modelo de análisis y el modelo de diseño, por Jacobson (2004). Modelo de diseño El modelo de diseño se representa a través de un modelo de objetos que describe la realización física de los casos de uso, considerando principalmente cómo los requisitos funcionales y no funcionales impactan el sistema a considerar. El modelo de diseño se define mediante una jerarquía como se muestra a continuación (Ver Figura 11) : Figura 11: Modelo de diseño como una jerarquía de subsistemas de diseño con clases de diseño, realizaciones casos de uso-diseño e interfaces, por Jacobson (2004) 41

42 El modelo de diseño se representa por un sistema de diseño, que denota el subsistema de mayor nivel del modelo. Se pueden usar otros subsistemas, para organizar el modelo de diseño en porciones más manejables. Los subsistemas de diseño y clases de diseño representan abstracciones del subsistema y componentes de la implementación del sistema. Los casos de uso son realizados por las clases de diseño y sus objetos y se representan por colaboraciones en el modelo de diseño, describiendo cómo se realiza un caso de uso en términos de interacción entre objetos de diseño. Clase del diseño: La clase de diseño representa una abstracción de una clase o construcción similar en la implementación del sistema que posee las siguientes características: El lenguaje usado para especificar la clase de diseño es similar al lenguaje de programación, por lo que las operaciones, parámetros, atributos, tipos y demás son presentadas utilizando la sintaxis del lenguaje de programación elegido. El alcance y visibilidad de los atributos y las operaciones de una clase de diseño con frecuencia es presentada. Las relaciones de aquellas clases de diseño implicadas con otras clases, con frecuencia tienen un significado directo cuando es implementada. Algunas clases de diseño podrán diferir para las subsiguientes actividades de implementación el manejo de algunos requisitos, presentándolos como requisitos de implementación dela clase. Una clase de diseño a menudo se presenta como un estereotipo sin costuras que se corresponde con una construcción en el lenguaje de programación elegido. Una clase de diseño puede realizar y proporcionar interfaces en el lenguaje de programación. Puede activarse, implicando que objetos de la clase mantengan su propio hilo de control y se ejecutan en concurrencia con otros objetos activos. 42

43 Figura 12: Atributos claves y asociaciones de una clase de diseño, por Jacobson (2004). (p.210) Realización de caso de uso-diseño La realización de caso de uso-diseño es definida por Jacobson y otros (2004) como una colaboración en el modelo de diseño que describe cómo se realiza un caso de uso específico, y cómo se ejecuta, en términos de clases de diseño y objetos (p. 210). Una realización de caso de uso-diseño ofrece una conexión directa a una realización de caso de uso-análisis del modelo de análisis. Una realización de caso de uso-diseño está conformada por una descripción del flujo de eventos, diagramas de clases que muestran sus clases de diseño participantes, y diagramas de interacción que muestran la realización de un escenario concreto de un caso de uso en términos de interacción entre objetos del diseño. Diagramas de clases Los diagramas de clases representan las clases de diseño y sus objetos, y si existiese, también los subsistemas que contienen las clases de diseño. Los diagramas de clases pueden mostrar algunas operaciones, atributos y asociaciones sobre una clase en particular, las cuales son relevantes para una realización de caso de uso. Los diagramas de clases ayudan a coordinar todos los requisitos de diferentes realizaciones de 43

44 casos de uso, y guardan la pista de los elementos que intervienen en una realización del caso de uso. Diagramas de interacción Los diagramas de interacción muestran la secuencia de acciones de un caso de uso cuando un actor invoca el caso de uso a través del envío de algún tipo de mensaje al sistema, luego internamente en el sistema algún objeto de diseño recibe el mensaje del actor, y este objeto de diseño a su vez llama a algún otro objeto, para que de esta manera interactúen para realizar y llevar a cabo el caso de uso. En el diseño, se prefiere representar lo anterior a través de diagramas de secuencia ya que el foco de atención es encontrar secuencia de interacciones detalladas y ordenadas en el tiempo. Los diagramas de secuencia muestran las interacciones entre objetos mediante la transferencia de mensajes entre objetos o subsistemas. El nombre del mensaje deberá indicar una operación del objeto que recibe la invocación o de una interfaz que el objeto proporciona. Flujo de sucesos-diseño El flujo de sucesos-diseño es una descripción textual que explica y complementa a los diagramas de realización de casos de uso y los diagramas de interacción. El texto se redacta en función de los objetos que interactúan para llevar a cabo el caso de uso, o en función de los subsistemas que participan en él. En las descripciones se debe evitar mencionar los atributos, operaciones y asociaciones de los objetos, ya que dificultaría el mantenimiento de dichas descripciones dado que estos elementos cambian con frecuencia. 44

45 Requisitos de implementación Los requisitos de implementación corresponden a una descripción textual que recoge los requisitos, tales como los requisitos no funcionales, sobre una realización de un caso de uso. Se refiere a requisitos que se capturan sólo en esta fase, pero que será mejor tratar en la implementación. Subsistema de diseño Los subsistemas de diseño representan una forma de organizar los artefactos del modelo de diseño en piezas más manejables. Puede estar conformado por clases de diseño, realizaciones de casos de uso, interfaces y otros subsistemas. Los contenidos de los subsistemas deben estar fuertemente asociados, y que sus dependencias entre unos y otros, o entre sus interfaces deberán ser mínimas. Disciplina Implementación La implementación comienza con el resultado del diseño donde se implementa el sistema en términos de componentes, como archivos de código fuente, scripts, archivos binarios, archivos ejecutables y similares. El propósito fundamental de esta etapa es desarrollar la arquitectura y el sistema como un todo. Los principales propósitos específicos de la implementación son: Distribuir el sistema asignado componentes ejecutables a nodos en el diagrama de despliegue. Implementar las clases que se identificaron durante el diseño, como componentes de fichero que contienen código fuente. Esto incluye también la implementación de los subsistemas encontrados en el diseño. 45

46 Planificar las integraciones de sistema necesarias en cada iteración, siguiendo un enfoque incremental, implementando el sistema en una sucesión de pasos pequeños y manejables. Probar los componentes individualmente, y luego integrarlos compilándolos y enlazándolos en uno o más ejecutables, antes de llevar a cabo las comprobaciones de sistema. Modelo de implementación El modelo de implementación describe cómo los elementos del modelo de diseño, como por ejemplo las clases, se implementan en términos de componentes, como archivos de código fuente, ejecutables, etc. El modelo de implementación se define mediante una jerarquía como se muestra a continuación (Ver figura 13). Figura 13: Modelo de implementación como jerarquía de subsistemas de implementación con componentes e interfaces, por Jacobson (2004). (p.210) 46

47 El modelo de implementación se representa a través de un sistema de implementación, que denota el subsistema de mayor nivel del modelo. Se pueden usar otros subsistemas, para organizar el modelo de implementación en porciones más manejables. Componente El componente es el empaquetamiento físico de los elementos de un modelo, conformado por las clases en el modelo de diseño. Algunos estereotipos estándar de componentes son: ejecutables, archivos, librerías, tablas y documentos. Subsistema de implementación Los subsistemas de implementación se utilizan para organizar los artefactos del modelo de implementación en porciones más manejables. Puede estar formado por componentes, interfaces y de forma recursiva de otros subsistemas. El subsistema de implementación se manifiesta a través de un empaquetamiento asociado al entorno de implementación, tales como: un proyecto, un directorio, un paquete. Interfaz Las interfaces se utilizan para en el modelo de implementación para especificar las operaciones implementadas por componentes y subsistemas de implementación. Un componente que implementa y proporciona una interfaz debe implementar adecuadamente todas las operaciones definidas por la interfaz. Del mismo modo, un subsistema de implementación que proporciona una interfaz contiene componentes que proporcionan la interfaz o recursivamente otros subsistemas que proporción en la interfaz. 47

48 Disciplina Pruebas En las pruebas se verifica el resultado de la implementación, probando cada construcción, tanto intermedias como versiones finales, del sistema a ser puesto en producción y entregado a terceros. Los objetivos de las pruebas son: Planificar las pruebas necesarias en cada ciclo o iteración, incluyendo pruebas de integración y pruebas del sistema. Diseñar e implementar las pruebas a través de la definición de casos de prueba que describan qué probar, incluyendo procedimientos de prueba que indiquen cómo realizar las pruebas. Realizar las diferentes pruebas y manejar los resultados de cada prueba de forma sistemática, para que en aquellas construcciones que se detecten defectos sean arreglados y probados nuevamente. Modelo de pruebas El modelo de pruebas describe primordialmente cómo se prueban los componentes ejecutables del modelo de implementación con pruebas de integración y de sistemas. El modelo de pruebas se muestra a continuación: Figura 14: Modelo de pruebas, por Jacobson (2004). 48

49 El modelo de pruebas se define como una colección de casos de prueba, procedimientos de prueba y componentes de prueba. Casos de prueba El caso de prueba específica la forma de probar el sistema, incluyendo la entrada con la que se ha de probar y las condiciones que deben cumplirse para realizar la prueba. Procedimiento de prueba Un procedimiento de prueba detalla cómo realizar uno o varios casos de prueba o fragmentos de éstos. Puede ser una instrucción para un individuo sobre cómo ha de realizar un caso de prueba de forma manual, o puede ser una especificación de cómo interactuar con una herramienta automatizada de prueba. Componente de prueba Un componente de prueba automatiza uno o varios procedimientos de prueba o parte de ellos. Pueden ser desarrollados usando algún lenguaje de programación o pueden ser generados con una herramienta automatizada de pruebas. Plan de prueba El plan de prueba describe las estrategias, recursos y planificación de la prueba. Incluye la definición del tipo de pruebas a realizar para cada ciclo o iteración y sus objetivos. Defecto La anomalía del sistema define lo que es un defecto. Puede ser un síntoma de una falla del software o un problema descubierto en una revisión. 49

50 El defecto debe ser registrado y/o documentado, para que luego los desarrolladores lo controlen y lo resuelvan. Evaluación de prueba La evaluación de los resultados de los esfuerzos de la prueba, tales como la cobertura del caso de prueba, la cobertura de código y el estado de los defectos, conforman la evaluación de prueba. Otras Herramientas de Modelado Dentro de todo proyecto es posible encontrar debido a diversos factores que se tomen herramientas de otras metodologías para complementar ideas, procesos, técnicas o inclusive realizar trabajos adicionales a los que plantea la metodología que se utiliza, por esta razón se describen algunas técnicas adicionales a los diagramas contemplados en UML, estos son: Matriz de asociaciones: una matriz se puede definir como una forma de relacionar un número m de filas con un número n de columnas de modo que se obtienen dos perspectivas en cada relación m x n; en el caso particular de las matrices de asociaciones se describe la relación existente entre dos elementos (sean medidas, objetos, valores, etc.) de un sistema de modelado. Diagrama Entidad-Relación (E-R): Se utiliza para mostrar las distintas asociaciones que surge entre los objetos o entidades de datos de un modelado determinado. Estos presentan generalmente un orden y cardinalidad, o lo que es igual, el número mínimo y máximo de presencias de una entidad frente a otra. 50

51 Esta investigación está basada en los conceptos básicos de la Banca Pública en Venezuela, los cuales deben estar orientados a brindar un servicio de calidad a todos sus usuarios. Es por esta razón que se requiere establecer la unificación de la Banca Pública, esta surge en vista de la necesidad que tiene el sistema bancario público de brindar un mejor servicio a todos sus clientes y a su vez llegar a todas partes del territorio nacional, con la unión de estas tres (3) instituciones financieras. Se propone desarrollar y realizar las adecuaciones tecnológicas necesarias, Tomando en consideración la aplicación de una solución que permita una rápida implementación a un bajo costo, con la utilización de un WebService en cada una de las instituciones financieras, para efectuar una transferencia de información encriptada sobre un canal seguro, el mismo proveerá de un mecanismo de transferencia de datos que facilitara futuros desarrollos adicionales en caso que sean necesarios, cada institución financiera permitirá implantar una solución de bajo impacto tecnológico. De esta manera se obtendrá lo siguiente: La plataforma tecnológica bancaria utilizada en la institución es el WebService, el cual sirven para intercambiar datos entre aplicaciones y será capaz de convertir la información recibida en una ráfaga de datos, en el caso de IBS (Sistema interno del Banco para taquilla), o en una estructura de datos en el caso de otro Core Bancario (Sistema Interno de cada Banco). Se debe enviar una respuesta con el resultado de la operación, con la finalidad de validar la operación del cliente. El sistema permitirá realizar las siguientes operaciones de taquilla: Deposito En Efectivo. Pago Tarjeta de Crédito En Efectivo. 51

52 El sistema establecerá mecanismos de control y seguimiento por parte del personal autorizado, cada institución financiera respetará sus políticas internas, adecuándose cada una al resto de la Banca Pública. De igual manera, los ajustes y cambios serán realizados con un trabajo en equipo por parte de todas las instituciones financieras involucradas. Con el fin de acoplarse a la unificación de todas las transacciones de taquilla. Para llevar a cabo esta propuesta, se establecerá un segmento de Red que será compartido por todos los bancos. Los enlaces se deben conectar a un Router de Borde y para proteger la información de cada institución financiera y se debe emplear un Firewall. En vista que se está manejando información sensible y confidencial. El sistema propuesto aportará los siguientes beneficios: La Banca pública unificará las transacciones de depósitos y transferencias por Internet vía WebService. En base a las necesidades del sistema financiero público, el mismo permitirá que los flujos definidos sean modificados, logrando de esta manera realizar cambios cuando sea requerido. Altos criterios de seguridad, eficiencia y robustez, tanto en la infraestructura de datos como en la arquitectura. En este momento la Banca Pública en Venezuela, presenta una gran demanda de clientes a nivel nacional en todos sus servicios y productos. Siendo el de las operaciones de taquilla uno de los más solicitados. Los usuarios al momento de adquirir o usar un servicio o un producto se ven influenciados por una diversidad de factores presentes en el individuo y en el entorno donde 52

53 esté interactúa cada día. El sexo, la edad, el estado civil, así como la condición económica ejercen fuertes incidencias en el comportamiento del consumidor. Estas evaluaciones o estudio o estudio de mercado no son de uso exclusivo de empresas que fabrican un producto en específico para comercializarlo; también recurren a éstos las empresas de servicios, que desean saber cuáles son los gustos, exigencias de sus usuarios y/0 clientes para así diseñar estrategias que le permitan satisfacer sus necesidades y por ende tener un cliente satisfecho. Las instituciones financieras y específicamente las entidades bancarias no escapan de esta realidad. Buscan conocer a sus clientes, gustos, necesidades, para así diseñar y ofrecerles productos/servicios que procuren su satisfacción y su preferencia. Las entidades bancarias permiten el desarrollo de todas aquellas transacciones entre personas, empresas y organizaciones que impliquen el uso de dinero. Como institución financiera se encargan de recibir depósitos, pagos, realizar transacciones, conceder préstamos, llevar fideicomisos, cajas de seguridad entre otros servicios, como asesoramiento financiero. A través de los servicios que ofrece un banco tiene como finalidad el cubrir todas las necesidades del cliente. ( consultado mayo 2014.) En Venezuela, existe diversidad de entidades bancarias, tanto públicas como privadas, entre los cuales los clientes pueden seleccionar para realizar sus operaciones financieras. De esta diversidad de entidades bancarias, el cliente debe evaluar y seleccionar aquella que le ofrezca más ventajas o beneficios. En otras palabras, el usuario debe tomar la decisión de seleccionar la entidad bancaria que mejor satisface sus exigencias y necesidades. Los clientes o usuarios de servicios bancarios hoy en día tienen mucha información sobre las instituciones bancarias a la cual están, afiliados y que por tanto le ofrecen y prestan distintos servicios; estos conocimientos se han incrementado a consecuencia de las distintas medidas bancarias que han surgido en los últimos tiempos y las que han llevado al cliente a 53

54 estar informado sobre la actualidad bancaria nacional. De igual manera poseen diferentes inquietudes y preguntas o incógnitas que le permiten analizar la información y de esta manera evaluar desde su perspectiva la actualidad bancaria que los rodea y la manera que están les afectan, bien sea de una manera positiva o negativa, sus vidas y patrimonio. De acuerdo a estos factores y la variedad de instituciones bancarias que existen en a lo largo del territorio nacional, los productos/servicios que ofrezcan, la tradición o la sugerencia de amigos pudiesen incidir en la toma de decisión de una persona al momento de elegir servicios financieros. De allí el intereses de aplicar instrumentos de medición de calidad de servicio, a través de encuestas vía telefónica, en estos dos (2) últimos meses. Se entiende por indicador el instrumento de medición de las variables asociadas a las metas. Los indicadores pueden ser cualitativos o cuantitativos, la expresión cuantitativa muestra el desempeño de toda una organización o una de sus partes, cuya magnitud al ser comparada con algún nivel de referencia, puede estar señalando una desviación sobre la cual se tomarán acciones correctivas o preventivas según el caso, Lezama (2009). Base Teóricas A continuación se presentan un conjunto de conceptos o términos que tienen relación con el presente estudio o que los términos que tienen relación con el presente estudio o que lo sustentan. En general, para el desarrollo del proyecto se aplicaron terminologías y conceptos utilizados en las actividades de las operaciones de taquilla. Referente Metodológico Según el diccionario de la Real Academia Española, julio 2010, metodología se define como: Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal. 54

55 La metodología es la etapa específica que procede de una posición teórica y epistemológica y que da pie a la selección de técnicas concretas de investigación (Alonso, 1977, p. 47). Una metodología se refiere entonces, al conjunto de pasos a seguir de manera organizada que ayuda al mejor desenvolvimiento de la investigación de un trabajo a desarrollar. Tipo de Investigación Existen dos tipos principales de proyectos de investigación, los de campo o los de laboratorio, el que se desarrollará es netamente de campo del tipo proyecto factible o viable. El mismo consiste en una proposición sustentada de un modelo operativo factible, orientado a resolver un problema planteado o satisfacer las necesidades organizacionales. Metodología En atención a la modalidad previamente definida, se realizarán tres grandes fases en el estudio a fin de cumplir con los requisitos involucrados en este tipo de proyecto: Primera Fase: en la que se desarrollará un diagnóstico de la situación existente en la realidad objeto de estudio a través del marco teórico, entrevistas y observación directa realizada al personal de agencias y taquilla. Segunda Fase: en la cual, atendiendo a los resultados del diagnóstico, se formulará un conjunto de propuestas adecuadas al diseño de los indicadores que servirán de base para la medición del tiempo de gestión de cada proceso de operación de taquilla. Por parte del personal de tecnología y su desempeño de forma grupal. Tercera Fase: en la que se aplicará la metodología RUP (Rational Unified Process) con la finalidad de producir un software que cumpla con los requerimientos, planificación y presupuesto establecido. 55

56 La metodología RUP (Proceso Unificado de Desarrollo Software), consiste en realizar un conjunto de actividades que son necesarias para transformar los requisitos de un usuario en un sistema software, se diferencia de las demás ya que se caracteriza por estar dirigida por casos de uso, centrado en la arquitectura y es considerada de tipo iterativo e incremental lo cual es beneficiosa ya que acepta redefinir los aspectos concretados inicialmente en el proyecto que puedan afectar otras fases del mismo. La metodología RUP se divide en cuatro fases según indica Jacobson, Booch y Rumbaugh (2000) Inicio (Define el alcance del proyecto) Elaboración (definición, análisis, diseño) Construcción (implementación) Transición (fin del proyecto y puesta en producción) Para RUP, es importante destacar el establecimiento temprano de una buena arquitectura para evitar que en las fases de construcción y mantenimiento tenga cambios muy bruscos o fuertes, es por esto lo importante de aplicar una adecuada Ingeniería del Software. Los productos o artefactos a obtener por cada flujo de trabajo se referencia a continuación (es importante destacar que el esfuerzo que se lleva a cabo en cada flujo de trabajo depende en la fase en la cual se encuentre, en el caso de la fase de inicio se tendrá mayor esfuerzo hacia los flujos de requisitos y análisis que en los de diseño y pruebas). 56

57 Ingeniería del Software Según Zelkovitz (1978) (citado por Wikipedia en su sitio web), ingeniería del software es el estudio de lo principios y metodologías para el desarrollo y mantenimiento de sistemas software. Se puede ratificar que la ingeniería del software no es más que, el uso de distintas técnicas, métodos y herramientas para analizar, diseñar, elaborar, implantar y mantener cualquier sistema que sea tipo software, en forma ordenada y eficiente. La ingeniería del software surge como una respuesta para el problema que se desarrolla en los años 60, gracias a la crisis del software; en ese momento se tenía que el desarrollo de hardware mejoro la calidad y bajo los costos en gran medida, pero se seguían sintiendo muchos inconvenientes en relación al desarrollo de software y los clientes que tenían el requerimiento de un software que los ayudara en sus empresas. Los principales problemas que se presentaron en ese momento fueron la imprecisión en la planificación de los proyectos y en las estimaciones de costos, la baja calidad del producto software resultante (en algunos casos el sistema nuevo no llenaba las expectativas mínimas esperadas, y por ultimo pero no menos importante, se encontraba una gran dificultad en la realización de mantenimiento a los programas. Programación Orientada a Objetos (POO) Grady Booch (citada por Joyanes Aguilar, 2003) define la Programación Orientada a Objetos como: Un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada una de los cuales representa una instancia de alguna clase, y cuyas clases son todas miembros de una jerarquía de clases unidas mediante relaciones de herencia. (p. 576). 57

58 La programación orientada a objetos es una extensión natural de la actual tecnología de programación y representa un enfoque nuevo y distinto al tradicional. Al igual que cualquier otro programa, el diseño de un programa orientado a objeto es único en el sentido de que se organiza en función de los objetos que manipulará. De hecho probablemente la parte más difícil de la creación del software orientado a objetos es identificar las clases necesarias y el modo en que interactúan entre sí. Lenguaje de Programación C# El lenguaje de programación C# fue creado por el danés Anders Hejlsberg que diseño también los lenguajes Turbo Pascal y Delphi. El C# (pronunciado en inglés C sharp o en español C sostenido ) es un lenguaje de programación orientado a objetos. Con este nuevo lenguaje se quiso mejorar con respecto de los dos lenguajes anteriores de los que deriva el C, y el C++. Es sencillo, moderno, proporciona seguridad de tipos y está orientado a objetos. El código creado mediante C# se compila como código administrado. Estos servicios incluyen interoperabilidad entre lenguajes, recolección de elementos no utilizados, mejora de la seguridad y mayor compatibilidad entre versiones. A pesar que el lenguaje C# forma parte de la plataforma.net, que es una interfaz de programación de aplicaciones. C# es un lenguaje independiente que originariamente se creó para producir programas sobre esta plataforma.net. Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma.net, similar al de Java, aunque incluye mejoras derivadas de otros lenguajes. El nombre C Sharp fue inspirado por la notación musical, donde '#' (sostenido, en inglés sharp) indica que la nota (C es la nota do en inglés) es un semitono más alta, sugiriendo que C# es superior a C/C++. Además, el signo '#' se compone de cuatro signos '+' pegados 1. 58

59 Las principales características de este lenguaje de programación son: C# es un lenguaje de programación simple pero eficaz, diseñado para escribir aplicaciones empresariales. El lenguaje C# es una evolución de los lenguajes C y C++. Utiliza muchas de las características de C++ en las áreas de instrucciones, expresiones y operadores. C# presenta considerables mejoras e innovaciones en áreas como seguridad de tipos, control de versiones, eventos y recolección de elementos no utilizados (liberación de memoria). C# proporciona acceso a los tipos de API más comunes:.net Framework, COM, Automatización y estilo C. Asimismo, admite el modo unsafe, en el que se pueden utilizar punteros para manipular memoria que no se encuentra bajo el control del recolector de elementos no utilizados. Lenguaje de Programación RPG Ha sido actualizado en diversas ocasiones, dando origen a las diferentes versiones del lenguaje. Una de las últimas actualizaciones que se ha realizado hasta la fecha es el RPG/IV en 1995, disponible con los ordenadores IBM de la familia AS/400. Posteriormente, en 2001, y con la aparición de la versión 5 del OS/400, surgió una nueva modificación sobre el lenguaje, soportándose a partir de ese momento la programación en formato libre. Así mismo, se desarrollan las funciones incorporadas que sustituyen a muchos de los antiguos indicadores y códigos de operación. Todas estas incorporaciones permiten que el RPG se convierta en un lenguaje mucho más legible, claro, flexible y moderno. Entre sus principales características podemos destacar las siguientes: 1. Orientado a la producción de informes. 2. Realiza cálculos fácilmente. 59

60 3. Emplea hojas de codificación diferentes para la descripción de ficheros, entrada de datos, salida de resultados. Esquema de Conexión Metro Ethernet. La Red Metro Ethernet, es una arquitectura tecnológica destinada a suministrar servicios de conectividad MAN/WAN de nivel 2, a través de UNIs Ethernet. Estas redes denominadas "multiservicio", soportan una amplia gama de servicios, aplicaciones, contando con mecanismos donde se incluye soporte a tráfico "RTP" (tiempo real), como puede ser Telefonía IP y Video IP, este tipo de tráfico resulta especialmente sensible a retardo y al jitter (señal de ruido no deseada). La utilización de las líneas de cobre (MAN BUCLE), garantiza el despliegue de un punto de red ethernet, en cualquier punto del casco urbano, soportando el 100% de los servicios demandados por los proyectos de Smart City. Las redes Metro Ethernet, están soportadas principalmente por medios de transmisión guiados, como son el cobre (MAN BUCLE) y la fibra óptica, existiendo también soluciones de radio licenciada, los caudales proporcionados son de 10 Mbit/s, 20 Mbit/s, 34 Mbit/s, 100 Mbit/s, 1 Gbit/s y 10 Gbit/s. La tecnología de agregación de múltiples pares de cobre, (MAN BUCLE), permite la entrega de entre 10 Mbit/s, 20 Mbit/s, 34 Mbit/s y 100 Mbit/s, mediante la transmisión simultánea de múltiples líneas de cobre, además esta técnica cuenta con muy alta disponibilidad ya que imposible la rotura de todas las líneas de cobre y en caso de rotura parcial el enlace sigue transmitiendo y reduce el ancho de banda de forma proporcional. La fibra óptica y el cobre, se complementan de forma ideal en el ámbito metropolitano, ofreciendo cobertura total a cualquier servicio, a desplegar. Los beneficios que Metro Ethernet ofrece son: 60

61 Presencia y capilaridad prácticamente "universal" en el ámbito metropolitano, en especial gracias a la disponibilidad de las líneas de cobre, con cobertura universal en el ámbito del urbano. Muy alta fiabilidad, ya que los enlaces de cobre certificados Metro Ethernet, están constituidos por múltiples pares de en líneas de cobre (MAN BUCLE) y los enlaces de Fibra Óptica, se configuran mediante Spanning tree (activo-pasivo) o LACP (caudal Agregado). Fácil uso: Interconectando con Ethernet se simplifica las operaciones de red, administración, manejo y actualización. Economía: los servicios Ethernet reducen el capital de suscripción y operación de tres formas: Amplio uso: Se emplean interfaces Ethernet que son la más difundidas para las soluciones de Networking. Bajo costo: Los servicios Ethernet ofrecen un bajo costo en la administración, operación y funcionamiento de la red. Ancho de banda: Los servicios Ethernet permiten a los usuarios acceder a conexiones de banda ancha a menor costo. Flexibilidad: Las redes de conectividad mediante Ethernet permiten modificar y manipular de una manera más dinámica, versátil y eficiente, el ancho de banda y la cantidad de usuarios en corto tiempo. El modelo básico de los servicios Metro Ethernet, está compuesto por una Red switcheada MEN (Metro Ethernet Network), ofrecida por el proveedor de servicios. Que para el caso de Banco Bicentenario Banco Universal, C.A, es CANTV. Operaciones de Taquilla Branch.Net Dentro de los proyectos de automatización y mejoras tecnológicas del Banco Bicentenario Banco Universal C.A., se implementó el Sistema de taquilla IBS-Branch.Net con el fin de contar con sistemas que brinden mayor rapidez y confianza en las operaciones de 61

62 taquilla de la red de oficinas. Esta aplicación de taquilla es la que permite realizar el proceso de todas las operaciones realizadas por el operador a través de nuestros clientes. Cada uno de los usuario para ingresar al sistema tienen un perfil asignado, estos son genéricos y poseen una nomenclatura específica que indica el nivel de acceso, cargo de cada uno de los usuarios del sistema, numero de oficina más un correlativo. 62

63 CAPITULO III MARCO METODOLÓGICO En este capítulo se describe la metodología utilizada para el desarrollo del proyecto. Las metodologías y estándares utilizados en el desarrollo de software que proporcionaron la guía para poder conocer todo el camino recorrido desde antes de empezar la implementación, con lo cual se asegura la calidad del producto final; así como también, el cumplimiento en la entrega del mismo en un tiempo estipulado. La metodología RUP, de Jacobson y otros (2004), basada en el Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML), proporcionó todas las bases para llevar al éxito la elaboración del software. Igualmente se presenta la estrategia metodológica que se establece para el logro de los objetivos del proyecto. Según la Enciclopedia Básica Nauta, una posible definición de la palabra metodología pudiese ser ciencia fil, que estudia los métodos científicos (p. 524). Es importante señalar que cuando se está creando un software se debe considerar una metodología robusta y que garantice un software eficiente, considerando los requisitos exigidos para su funcionamiento. La propuesta para la realización del módulo de Banca Pública se realiza con una adaptación de la metodología RUP ( Rational Unified Process), pero utilizando los flujos de trabajo fundamentales que puedan garantizar el éxito del proyecto. De acuerdo al requerimiento no es necesario aplicar todos los pasos de la metodología, razón que lleva a la reflexión de cuáles son los flujos de trabajo principales para la consecución del objetivo; respondiendo a esta reflexión se considera que los flujos que se deben utilizar son los siguientes: modelado de negocio, requisitos, análisis, diseño y pruebas. 63

64 Los productos o artefactos a obtener por cada flujo de trabajo se referencian a continuación (es importante destacar que el esfuerzo que se lleva a cabo en cada flujo de trabajo depende de la fase en la cual se encuentre, por ejemplo, en la fase inicio se tendrá mayor esfuerzo hacia los flujos de requisitos y análisis que en diseño y prueba). 64

65 Esquema de trabajo y productos resultantes Flujo de Trabajo Actividades a Desarrollar Herramientas (UML) Productos Modelado del Negocio (Obtención de los límites del problema y la información básica para comenzar el modelaje del sistema). Entrevistar a Clientes Internos / Externos y Personal de Oficinas. Estudiando la estructura y la dinámica de la organización y analizando los problemas actuales e identificando posibles mejoras. Se estudian los procesos de negocio asociados al soporte de usuarios. Diagrama de Clases Información general sobre las operaciones de taquilla y planillas utilizadas. Modelo del dominio Requisitos (Un modelo del sistema a desarrollar que cumpla con los requisitos exigidos y sea entendible tanto para el equipo de desarrollo como para los usuarios). Estableciendo lo que el sistema debe hacer (requerimientos funcionales), definiendo los límites del sistema y la interfaz de usuario. Definir los procesos del sistema y los casos de uso a través de diagramas UML. Definir las relaciones entre actores y casos de uso. Detallar los casos de uso. Estructurar el modelo de caso de uso. Diagrama de actores. Diagrama de casos de uso. Matriz de asociación (actores casos de uso). Enunciado inicial. Actores. Modelos de casos de uso. Detallar los Casos de Uso. Descripción de la arquitectura (Vista de los casos de uso). Análisis (Un modelo del sistema que exprese en términos de clases sus interrelaciones los requisitos obtenidos en el flujo anterior). Se estructuran los requisitos de manera que faciliten su comprensión, su preparación, su modificación y su mantenimiento. Se Identifican posibles mejoras, estudiando los procesos de negocio, asociados al soporte de las operaciones de taquilla. Identificar y categorizar las clases del sistema. Analizar los casos de uso definidos anteriormente a través de las relaciones de los casos de uso. Realizar una descripción detallada e integrada de las clases de análisis. Definir el comportamiento del sistema. Diagrama de estado inicial. Diagrama de clases. Escenarios, diagramas de colaboración. Diagrama de clases inicial, Clases del análisis. Realización de los casos de uso. Modelo de análisis y descripción de la arquitectura (análisis). 65

66 Diseño (El modelo de diseño con clases bien categorizadas y definidas para ser interpretadas por los lenguajes de programación C# y RPG. Modelar el sistema software a través de diagramas UML. Evaluar las clases de análisis para obtener las principales clases de diseño. Desarrollar la interfaz del sistema. Diagrama de clases. Diagrama de Actividad. Diagrama de Entidad- Relación Clases de diseño, realización de los casos de uso-diseño. Modelo de diseño y descripción de la arquitectura (diseño). Desarrollo de la interfaz. Modelo entidad-relación. Implementación (El producto software como tal). Construcción del sistema software en lenguaje de programación incluyendo los principios de rentabilidad y agrupación de clases. C#, RPG, Metro- Ethernet. Construcción del sistema software. Pruebas (Un producto software depurado y listo para su uso). Realizar pruebas a los componentes terminados Requerimientos de ajustes del sistema en caso de ser necesario. Validación por parte de los usuarios del Sistema. Pruebas de componentes. Tabla 3 Esquema de trabajos y productos resultantes 66

67 Modelado del Negocio El objetivo de esta disciplina es comprender la estructura y la dinámica de la organización, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. En este flujo de trabajo se define el Modelo de Casos de Uso del Negocio o Modelo de Contexto del Negocio para describir los procesos del negocio y los clientes, de forma tal de obtener la visión general del negocio, identificando las posibles fallas o los aspectos a mejorar del proceso actual. Disciplina Requisitos El mayor esfuerzo en la fase de requisitos es desarrollar un modelo del sistema que se va a construir, y el uso de los casos de uso, en conjunto con los actores y las relaciones son una buena forma de crear ese modelo. Modelo de casos de uso: Para plasmar o capturar los requerimientos funcionales del sistema, la metodología del Proceso Unificado de Desarrollo de Software recomienda utilizar el modelo de casos de uso, para representar los requisitos de una manera adecuada y comprensible para los usuarios, clientes y desarrolladores. Un modelo de casos de de uso es un modelo del sistema que contiene actores, casos de usos y sus relaciones (Jacobson y otros, 2004, p. 127). 67

68 Figura 15. El modelo de casos de uso y su contenido. Fuente: Jacobson y otros (2004). Actor: Un actor representa un tipo de usuario del sistema, que suele corresponderse con un trabajador del negocio o también puede ser otro sistema. El actor se representa de la siguiente manera: Figura 16. El actor Coordinador de Sistemas. Fuente: Jacobson y otros (2004). Un actor representa un papel por cada caso de uso donde él colabora. Cuando un usuario en particular (que puede ser un humano u otro sistema) interactúa con el sistema, la instancia correspondiente del actor está desarrollando ese papel. 68

69 Caso de uso: El caso de uso representa un conjunto de secuencia de acciones que ejecuta el sistema y que producen un resultado apreciable para un actor en particular. Representa una funcionalidad que ofrece un resultado de valor para los actores. El caso de uso se representa de la siguiente manera: Figura 17. El caso de uso Solicitar Soporte. Fuente: Jacobson y otros (2004). Relaciones: La interacción entre los actores y los casos de usos en el modelo de casos de uso se representa a través de relaciones, que son líneas que van desde el actor hasta los casos de uso. Disciplina Análisis El propósito fundamental de esta etapa es analizar los requisitos con mayor profundidad, con la ventaja de que se permite utilizar el lenguaje de los desarrolladores para describir los resultados. El Proceso Unificado de Desarrollo de Software, recomienda utilizar el modelo de análisis para apoyar esta etapa. Modelo de análisis El modelo de análisis ayuda a refinar y estructurar los requisitos y permite razonar sobre aspectos internos del sistema. Existe una trazabilidad directa entre los casos de uso del 69

70 modelo de casos de uso y realizaciones de casos de uso en el modelo de análisis. A continuación se muestra una tabla resumen con dicha comparación. Tabla 4. Comparación del modelo de casos de uso con el modelo de análisis El modelo de análisis se define mediante una jerarquía como se muestra a continuación: Figura 18. Modelo de análisis como una jerarquía de paquetes de análisis con clases de análisis y realizaciones casos de uso. Fuente: Jacobson y otros (2004). 70

71 El modelo de análisis está plasmado a través de un sistema de análisis que representa el paquete de mayor nivel del modelo. Mediante otros paquetes de análisis se puede organizar el modelo de análisis en partes más manejables como abstracciones de subsistemas. Las clases de análisis representan abstracciones de clases y subsistemas del diseño. En el modelo de análisis, los casos de uso se describen mediante clases de análisis y sus objetos que se denominan realización de caso de uso análisis. La realización de un caso de uso representa una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso específico. Clases de análisis Las clases de análisis representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema que posee las siguientes características: Se centra en los requisitos funcionales y deja a un lado los no funcionales. Esto hace que una clase de análisis sea más evidente en el contexto del dominio del problema. Su comportamiento se define mediante responsabilidades de nivel más alto y menos formal. Define atributos de nivel muy alto. Participa en relaciones de modelo conceptual. Encaja en uno de tres estereotipos básicos: o Clase de interfaz o Clase de control o Clase de entidad 71

72 Figura 19. Atributos esenciales y los estereotipos de una clase de análisis. Fuente: Jacobson y otros (2004). Estos tres estereotipos están estandarizados en UML y se usan para apoyar a los desarrolladores para diferenciar el ámbito de las diferentes clases. Cada estereotipo tiene su propio símbolo, como se muestra a continuación. Figura 20. Estereotipos de clases estándar de uso en el análisis. Fuente: Jacobson y Otros (2004). Clase de interfaz: modela la interacción entre el sistema y sus actores. Implica recibir y/o mostrar información y peticiones de y hacia los usuarios y los sistemas externos. Representan ventanas, formularios, paneles, interfaces de comunicación, etc. Cada clase de interfaz debería asociarse con al menos un actor y viceversa. 72

73 Clase de entidad: modela información que posee una vida larga y que a menudo es persistente. Se derivan de las clases de entidad del negocio, pero se diferencias de éstas, porque representan objetos manejados por el sistema y las clases de entidad de negocio representan objetos presentes en el negocio. Clase de control: representan coordinación, secuencia, transacciones, y control de otros objetos. Con frecuencia se usan para encapsular el control de un caso de uso en concreto. Los aspectos dinámicos y delegaciones a otras clases del sistema se modelan con estas clases. Realización de caso de uso-análisis Con respecto a la realización de caso de uso-análisis Jacobson y otros (2004) lo definen como una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis y de sus objetos del análisis en interacción (p. 177). Una realización de caso de uso normalmente está conformada por la descripción textual del flujo de sucesos, diagramas de clases con las clases de análisis participantes y diagramas de interacción que muestran la realización de un flujo o escenario específico del caso de uso en términos de interacciones de objetos del análisis. Se centra en los requisitos funcionales, y por ello se puede posponer el tratar con los requisitos no funcionales hasta el diseño e implementación, que en la realización se denominan requisitos especiales. Diagramas de colaboración en el análisis En la fase de análisis, se opta por mostrar la secuencia de acciones de un caso de uso a través de diagramas colaboración, ya que el objetivo principal es identificar requisitos y responsabilidades sobre los objetos. En los diagramas de colaboración se muestran las interacciones entre 73

74 objetos a través de enlaces entre ellos y agregando mensajes a esos enlaces. Por lo tanto, el nombre del mensaje debería denotar el propósito del objeto que invoca en la interacción con el objeto invocado. Disciplina Diseño El propósito fundamental de esta etapa es crear el modelo de diseño tomando como entrada principal el modelo de análisis, adaptándolo al entorno de implementación, para que funcione como esquema para la implementación. Los principales propósitos del diseño son: Definir una entrada apropiada y un punto de partida para actividades de implementación subsiguientes, capturando los requisitos o subsistemas individuales, interfaces y clases. Comprender en profundidad los aspectos asociados a los requisitos no funcionales y restricciones relacionadas con los lenguajes de programación, sistemas operativos, manejadores de bases de datos, tecnología asociadas a interfaz de usuario distribución y concurrencia, etc. Dividir los trabajos de implementación en componentes más manejables, para que puedan ser desarrollados independientemente por varios equipos de desarrollo, tomando en cuenta el tema de la concurrencia. El resultado del análisis, es decir el modelo de análisis, es el insumo esencial en la etapa de diseño, tal como se muestra en el siguiente cuadro resumen: 74

75 Tabla 5. Comparación entre el modelo de análisis y el modelo de diseño. Modelo de diseño El modelo de diseño se representa a través de un modelo de objetos que describe la realización física de los casos de uso, considerando principalmente cómo los requisitos funcionales y no funcionales impactan el sistema a considerar. El modelo de diseño se define mediante una jerarquía como se muestra a continuación: Figura 21. Modelo de diseño como una jerarquía de subsistemas de diseño con clases de diseño, realizaciones casos de uso-diseño e interfaces. Fuente: Jacobson y otros (2004). 75

76 El modelo de diseño se representa por un sistema de diseño, que denota el subsistema de mayor nivel del modelo. Se pueden usar otros subsistemas, para organizar el modelo de diseño en porciones más manejables. Los subsistemas de diseño y clases de diseño representan abstracciones del subsistema y componentes de la implementación del sistema. Los casos de uso son realizados por las clases de diseño y sus objetos y se representan por colaboraciones en el modelo de diseño, describiendo cómo se realiza un caso de uso en términos de interacción entre objetos de diseño. Clase del diseño La clase de diseño representa una abstracción de una clase o construcción similar en la implementación del sistema que posee las siguientes características: El lenguaje usado para especificar la clase de diseño es similar al lenguaje de programación, por lo que las operaciones, parámetros, atributos, tipos y demás son presentadas utilizando la sintaxis del lenguaje de programación elegido. El alcance y visibilidad de los atributos y las operaciones de una clase de diseño con frecuencia es presentada. Las relaciones de aquellas clases de diseño implicadas con otras clases, con frecuencia tienen un significado directo cuando es implementada. Algunas clases de diseño podrán diferir para las subsiguientes actividades de implementación el manejo de algunos requisitos, presentándolos como requisitos de implementación dela clase. Una clase de diseño a menudo se presenta como un estereotipo sin costuras que se corresponde con una construcción en el lenguaje de programación elegido. Una clase de diseño puede realizar y proporcionar interfaces en el lenguaje de programación. 76

77 Puede activarse, implicando que objetos de la clase mantengan su propio hilo de control y se ejecutan en concurrencia con otros objetos activos. Figura 22. Atributos claves y asociaciones de una clase de diseño. Fuente: Jacobson y otros (2004). Realización de caso de uso-diseño La realización de caso de uso-diseño es definida por Jacobson y otros (2004) como una colaboración en el modelo de diseño que describe cómo se realiza un caso de uso específico, y cómo se ejecuta, en términos de clases de diseño y objetos (p. 210). Una realización de caso de uso-diseño ofrece una conexión directa a una realización de caso de uso-análisis del modelo de análisis. Una realización de caso de uso-diseño está conformada por una descripción del flujo de eventos, diagramas de clases que muestran sus clases de diseño participantes, y diagramas de interacción que muestran la realización de un escenario concreto de un caso de uso en términos de interacción entre objetos del diseño. Diagramas de clases Los diagramas de clases representan las clases de diseño y sus objetos, y si existiese, también los subsistemas que contienen las clases de diseño. Los diagramas de clases pueden mostrar algunas operaciones, atributos y asociaciones sobre una clase en particular, las cuales son relevantes para una realización de caso de uso. Los diagramas de clases ayudan a coordinar todos los requisitos de diferentes realizaciones de 77

78 casos de uso, y guardan la pista de los elementos que intervienen en una realización del caso de uso. Diagramas de interacción Los diagramas de interacción muestran la secuencia de acciones de un caso de uso cuando un actor invoca el caso de uso a través del envío de algún tipo de mensaje al sistema, luego internamente en el sistema algún objeto de diseño recibe el mensaje del actor, y este objeto de diseño a su vez llama a algún otro objeto, para que de esta manera interactúen para realizar y llevar a cabo el caso de uso. En el diseño, se prefiere representar lo anterior a través de diagramas de secuencia ya que el foco de atención es encontrar secuencia de interacciones detalladas y ordenadas en el tiempo. Los diagramas de secuencia muestran las interacciones entre objetos mediante la transferencia de mensajes entre objetos o subsistemas. El nombre del mensaje deberá indicar una operación del objeto que recibe la invocación o de una interfaz que el objeto proporciona. Flujo de sucesos-diseño El flujo de sucesos-diseño es una descripción textual que explica y complementa a los diagramas de realización de casos de uso y los diagramas de interacción. El texto se redacta en función de los objetos que interactúan para llevar a cabo el caso de uso, o en función de los subsistemas que participan en él. En las descripciones se debe evitar mencionar los atributos, operaciones y asociaciones de los objetos, ya que dificultaría el mantenimiento de dichas descripciones dado que estos elementos cambian con frecuencia. Requisitos de implementación Los requisitos de implementación corresponden a una descripción textual que recoge los requisitos, tales como los requisitos no funcionales, sobre una realización de un 78

79 caso de uso. Se refiere a requisitos que se capturan sólo en esta fase, pero que será mejor tratar en la implementación. Subsistema de diseño Los subsistemas de diseño representan una forma de organizar los artefactos del modelo de diseño en piezas más manejables. Puede estar conformado por clases de diseño, realizaciones de casos de uso, interfaces y otros subsistemas. Los contenidos de los subsistemas deben estar fuertemente asociados, y que sus dependencias entre unos y otros, o entre sus interfaces deberán ser mínimas. Disciplina Implementación La implementación comienza con el resultado del diseño donde se implementa el sistema en términos de componentes, como archivos de código fuente, scripts, archivos binarios, archivos ejecutables y similares. El propósito fundamental de esta etapa es desarrollar la arquitectura y el sistema como un todo. Los principales propósitos específicos de la implementación son: Distribuir el sistema asignado componentes ejecutables a nodos en el diagrama de despliegue. Implementar las clases que se identificaron durante el diseño, como componentes de fichero que contienen código fuente. Esto incluye también la implementación de los subsistemas encontrados en el diseño. Planificar las integraciones de sistema necesarias en cada iteración, siguiendo un enfoque incremental, implementando el sistema en una sucesión de pasos pequeños y manejables. Probar los componentes individualmente, y luego integrarlos compilándolos y enlazándolos en uno o más ejecutables, antes de llevar a cabo las comprobaciones de sistema. 79

80 Modelo de implementación El modelo de implementación describe cómo los elementos del modelo de diseño, como por ejemplo las clases, se implementan en términos de componentes, como archivos de código fuente, ejecutables, etc. El modelo de implementación se define mediante una jerarquía como se muestra a continuación: Figura 23. Modelo de implementación como una jerarquía de subsistemas e implementación con componentes e interfaces. Fuente: Jacobson y otros (2004). El modelo de implementación se representa a través de un sistema de implementación, que denota el subsistema de mayor nivel del modelo. Se pueden usar otros subsistemas, para organizar el modelo de implementación en porciones más manejables. Componente 80

81 El componente es el empaquetamiento físico de los elementos de un modelo, conformado por las clases en el modelo de diseño. Algunos estéreo tipos estándar de componentes son: ejecutables, archivos, librerías, tablas y documentos. Subsistema de implementación Los subsistemas de implementación se utilizan para organizar los artefactos del modelo de implementación en porciones más manejables. Puede estar formado por componentes, interfaces y de forma recursiva de otros subsistemas. El subsistema de implementación se manifiesta a través de un empaquetamiento asociado al entorno de implementación, tales como: un proyecto, un directorio, un paquete. Interfaz Las interfaces se utilizan para en el modelo de implementación para especificar las operaciones implementadas por componentes y subsistemas de implementación. Un componente que implementa y proporciona una interfaz debe implementar adecuadamente todas las operaciones definidas por la interfaz. Del mismo modo, un subsistema de implementación que proporciona una interfaz contiene componentes que proporcionan la interfaz o recursivamente otros subsistemas que proporcionen la interfaz. Disciplina Pruebas En las pruebas se verifica el resultado de la implementación, probando cada construcción, tanto intermedias como versiones finales, del sistema a ser puesto en producción y entregado a terceros. Los objetivos de las pruebas son: Planificar las pruebas necesarias en cada ciclo o iteración, incluyendo pruebas de integración y pruebas del sistema. 81

82 Diseñar e implementar las pruebas a través de la definición de casos de prueba que describan qué probar, incluyendo procedimientos de prueba que indiquen cómo realizar las pruebas. Realizar las diferentes pruebas y manejar los resultados de cada prueba de forma sistemática, para que en aquellas construcciones que se detecten defectos sean arreglados y probados nuevamente. Modelo de pruebas El modelo de pruebas describe primordialmente cómo se prueban los componentes ejecutables del modelo de implementación con pruebas de integración y de sistemas. El modelo de pruebas se muestra a continuación: Figura 24. Modelo de pruebas. Fuente: Jacobson y otros (2004). El modelo de pruebas se define como una colección de casos de prueba, procedimientos de prueba y componentes de prueba. Casos de prueba El caso de prueba específica la forma de probar el sistema, incluyendo la entrada con la que se ha de probar y las condiciones que deben cumplirse para realizar la prueba. 82

83 Procedimiento de prueba Un procedimiento de prueba detalla cómo realizar uno o varios casos de prueba o fragmentos de éstos. Puede ser una instrucción para un individuo sobre cómo ha de realizar un caso de prueba de forma manual, o puede ser una especificación de cómo interactuar con una herramienta automatizada de prueba. Componente de prueba Un componente de prueba automatiza uno o varios procedimientos de prueba o parte de ellos. Pueden ser desarrollados usando algún lenguaje de programación o pueden ser generados con una herramienta automatizada de pruebas. Plan de prueba El plan de prueba describe las estrategias, recursos y planificación de la prueba. Incluye la definición del tipo de pruebas a realizar para cada ciclo o iteración y sus objetivos. Defecto La anomalía del sistema define lo que es un defecto. Puede ser un síntoma de una falla del software o un problema descubierto en una revisión. El defecto debe ser registrado y/o documentado, para que luego los desarrolladores lo controlen y lo resuelvan. Evaluación de prueba La evaluación de los resultados de los esfuerzos de la prueba, tales como la cobertura del caso de prueba, la cobertura de código y el estado de los defectos, conforman la evaluación de prueba. 83

84 CAPÍTULO IV DESARROLLO DEL PROYECTO En esta sección se presenta el desarrollo del proyecto, según la metodología especificada en el cuadro 1 del capítulo anterior. Se procede a presentar las diferentes disciplinas o flujos de trabajo que cubrió el proyecto siguiendo la metodología, como son: la conceptualización del sistema a través del diagrama de contexto, la captura de los requisitos funcionales plasmados en el modelo de casos de uso, luego la fase del análisis, que utilizó el modelo de análisis derivado del modelo de casos de uso y el diseño, a través del modelo de diseño, que se derivó del modelo de análisis. Todo enmarcado dentro de la terminología y conceptos ofrecidos por la metodología RUP y el Lenguaje Unificado de Modelado(UML). Disciplina Modelado del Negocio Para la captura de los requisitos de una manera eficaz, se aplicó un conjunto de técnicas que ayudaron a obtener una verdadera visión del contexto del sistema. Para ello, se realizaron observaciones directas del sistema actual y se aplicaron entrevistas, tanto al personal del departamento de informática, como al personal de otros departamentos, como fueron los del departamento de Contabilidad, Compensación y Oficina Bancaria (Principal) de la institución objeto de este estudio; todo ello con la finalidad de identificar las funcionalidades que debería tener el sistema a desarrollar. Las observaciones consistieron en verificar el recorrido de una operación de taquilla, desde que la misma es generada por algún cliente que solicite el servicio, pasando por los procesos de revisión, autorización, ejecución, finalización y conformación de la solicitud. Las entrevistas se basaron en realizar preguntas de contexto libre que permitieron obtener un entendimiento de lo que debería realizar el sistema. 84

85 Modelo de contexto del negocio En base a las técnicas utilizadas, y siguiendo las recomendaciones del Proceso Unificado para comprender los procesos del negocio del sistema se elaboró el Siguiente modelo del negocio: Solicitante de la Transacción Cajero Sistema Integración de la Banca Pública. Solicitante de la Transacción Cajero Supervisor Afectación de Cuenta financiera asociada a la cuenta acreditada. Supervisor Cliente Solicitud Figura 25. Modelo de contexto del negocio. Fuente: Autor. 85

86 Los tipos de usuario que interactúan con el sistema son: 1. El Solicitante de la Transacción: quien solicita el depósito y/o pago de tarjeta de crédito al Banco de Venezuela o Banco del Tesoro. 2. Cajero: encargado de ejecutar la transacción solicitada por el cliente. 3. El Supervisor: encargado de verificar, y autorizar la solicitud del cliente. Cada uno de estos tipos de usuario representa un actor. A través del siguiente flujo de trabajo, Requisitos, se presenta el modelo de casos de uso, que detalla los requisitos funcionales del sistema y la interacción con los diferentes actores o componentes externos, bien sea, que proveen insumos al sistema o reciben productos del mismo. Disciplina Requisitos Esta disciplina o flujo de trabajo permite comprender los procesos del negocio, asociados a las operaciones de taquilla de Banca Pública, establecer lo que el sistema debe hacer y definir los límites del mismo. Para ello se presenta el modelo de caso de usos del sistema, que comprende los casos de uso, actores y relaciones. Modelo de casos de uso del sistema A través del modelo de casos de uso se detallan los requisitos funcionales del sistema, mediante una descripción general, una descripción breve y una descripción detallada de cada caso de uso. 86

87 Figura 26. Modelo de casos de uso asociado al sistema. Fuente: Autor. Descripción general del modelo de casos de uso La descripción general del modelo de casos de uso del Sistema de Integración de la Banca Pública es la siguiente: 87

88 El Solicitante de la Transacción invoca el caso de uso Solicitud de Transacción para realizar una operación de taquilla. Asociado a la oficina, contabilidad, cámara de compensación y el departamento de Sistemas. Después que la solicitud de Transacción, ha sido ejecutada y completado la operación de Taquilla por el Cajero, el Solicitante de la Transacción activa el caso de uso Conformar servicio con impresión de comprobante para verificar y confirmar los resultados del servicio de la transacción que solicitó. Por medio del caso de uso Verificar Transacción, el Supervisor de la Oficina busca el tipo de transacción (Banca Pública), verifica Banco Destino clasifica y prioriza según sus características. Luego, activa el caso de uso Autoriza Carga de Transacción en el Sistema para que el cajero continúe con la transacción. Luego que el Cajero ha cargado el servicio de transacción y después que el Solicitante de la Transacción ha conformado el servicio con impresión del comprobante, el Supervisor de la Oficina activa el caso de uso Autoriza Carga de Transacción en el Sistema. Si por el contrario existe un error de carga en el monto, se activa el caso de uso Gestionar Reverso de ser el Caso para monitorear la Transacción abierta del servicio de transacción y para cerrar la solicitud de transacción completada y conformada. Por otra parte, el Cajero activa el caso de uso Procede a Ejecutar Operación de Taquilla para ejecutar el servicio de transacción de la solicitud. Luego, una vez finalizado el servicio activa el caso de uso Completar la Operación de Taquilla para completar la solicitud de transacción y participar al Solicitante de la Transacción para que conforme el servicio con impresión del comprobante. Por otra parte, el Cajero activa el caso de uso Procede a Ejecutar Operación de Taquilla para ejecutar el servicio de transacción de la solicitud. Luego, una vez finalizado el servicio de transacción activa el caso de uso Completar la Operación de Taquilla para completar la solicitud de transacción y participar al Solicitante de la Transacción para que conforme el resultado del servicio con la impresión del comprobante. 88

89 Para Autorizar los reverso de las transacciones, el Supervisor de la Oficina y el Cajero, invocan el caso de uso Autorizar Reversos de ser el caso para autorizar, validar y completar la transacción. Descripción breve de cada caso de uso Una descripción breve y el paso a paso inicial de cada caso de uso, es el siguiente: Solicitar Transacción: El Solicitante de la Transacción activa este caso de uso una vez que detecta que tiene la necesidad de solicitar el servicio asociada a la red de oficinas del Banco Bicentenario Banco universal, C.A. Los pasos asociados son: El Solicitante de la transacción detecta la necesidad del servicio, bien sea para realizar un depósito o pago a su tarjeta de crédito asociado a la Oficina del Banco. El Solicitante de la Transacción realiza la solicitud del servicio. Verificar Solicitud: El Supervisor de la Oficina invoca este caso de uso para verificar el origen y la factibilidad de la solicitud de la transacción y el caso de uso clasifica la solicitud según sus características. El Supervisor de la Oficina verifica el origen de la solicitud de la transacción recibida y evalúa si procede la ejecución de la misma. El Supervisor de la Oficina evalúa la factibilidad de realizar el servicio solicitado por el cliente. El Supervisor de la Oficina verifica el tipo de solicitud y da prioridad a la misma para que aplique de acuerdo a las políticas de las otras instituciones financieras. El Supervisor de la Oficina clasifica en el sistema según el tipo de transacción, y autoriza carga de solicitud en el sistema. 89

90 Autoriza carga de Transacción en el Sistema: El Coordinador de Sistemas activa este caso de uso para asignar la solicitud al analista, según la clasificación de la solicitud y la carga de trabajo actual de cada analista y el caso de uso actualiza la solicitud de soporte a estatus a Asignada. El Supervisor de la Oficina revisa la clasificación de la solicitud de la Transacción. El Supervisor de la Oficina verifica la carga de la transacción actual de cada cajero, según las solicitudes procesadas que tiene cada cajero. El Supervisor de la Oficina verifica la solicitud de transacción procesada por el cajero, de acuerdo al tipo de transacción y emite un reporte diario para el cuadre y control interno de la oficina. Procede a Ejecutar Operación en Taquilla: El Cajero de la Oficina activa este caso de uso para cargar la solicitud de transacción que le fue solicitada y procede a ejecutar el servicio asociado a la solicitud. El caso de uso actualiza la solicitud de transacción emitiendo la ráfaga de resultado. El Cajero de la Oficina recibe y carga la solicitud de transacción. El Cajero de la Oficina verifica en el sistema y procesa la solicitud de transacción. El Cajero de la Oficina ejecuta el servicio solicitado por el cliente. Completar Servicio: A través de este caso de uso el Cajero de la Oficina le participa al Solicitante de la Transacción que el servicio fue completado. El caso de uso actualiza la solicitud de transacción a estatus a Procesado. El Cajero de la Oficina finaliza con la solicitud de la transacción realizada por el cliente. El Cajero de la Oficina participa al Solicitante de la Transacción que el servicio asociado a la solicitud de servicio fue completado. 90

91 Conformar Servicio: Por medio de este caso de uso, el Solicitante de la transacción verifica los resultados del servicio que solicitó (una vez que el servicio es completado en el caso de uso Completar Servicio ). El caso de uso actualiza la solicitud de Transacción a estatus a procesado. El Solicitante de la Transacción verifica el resultado del servicio solicitado El Solicitante de la Transacción conforma el resultado del servicio solicitado. El Solicitante de la transacción recibe su comprobante impreso, con la ráfaga que identifica la solicitud que realizo con la fecha, hora, monto y Banco tutor de la cuenta. Gestionar Reverso: El Supervisor de la Oficina invoca este caso de uso para gestionar el reverso de la solicitud de transacción del servicio solicitado por el cliente y para cerrar aquellas solicitudes que de alguna manera no fueron debidamente completadas y conformadas por el Solicitante de la transacción (en el caso de uso Conformar Servicio ), y el caso de uso actualiza la solicitud de solicitud de transacción a estatus Procesado. El Supervisor de la Oficina monitorea la gestión de solicitud de transacción del servicio. El Supervisor de la Oficina cierra la solicitud completada y conformada por el Solicitante de Soporte. El Coordinador de Sistemas actualiza en el sistema el estatus de la solicitud a Cerrada. El Coordinador de Sistemas emite desde el sistema los reportes, resumidos y/o detallados, de las solicitudes atendidas, clasificadas por analista, por tipo de solicitud, por prioridad, dentro de un periodo de tiempo específico. Gestionar Usuarios: Por medio de este caso de uso, el Supervisor de la Oficina y/o Cajero de la Oficina autoriza y ejecuta el reverso en el sistema. 91

92 El Supervisor de la Oficina verifica los datos del reverso para autorizar. El Supervisor de la Oficina ingresa al sistema y autoriza el reverso. El Supervisor de la Oficina verifica que el reverso se completo correctamente. Descripción detallada de cada caso de uso La finalidad principal de detallar cada caso de uso es describir su flujo de sucesos en detalle, incluyendo cómo se inicia, finaliza e interactúan con los actores. Solicitud de Transacción: Precondición: Al Solicitante de la Transacción se le debe haber presentado la necesidad de realizar un depósito y/o honrar el pago de su tarjeta de crédito tanto del Banco Bicentenario, Banco del Tesoro o Banco de Venezuela, requerimiento asociado a la Vicepresidencia de Sistemas, V.P de Operaciones, V.P de Banca Comercial. Flujo de sucesos Camino básico 1. El Solicitante de la Transacción invoca al caso de uso para realizar la solicitud de transacción. El sistema solicita la información básica para identificar la solicitud, como el nombre del solicitante (depositante), número de cuenta, número de tarjeta de crédito, Banco tutor de la cuenta. Un Solicitante de la Transacción puede depositar a una cuenta o tarjeta de crédito de otro cliente sin que el mismo un solicitante diferente al propio dueño de la cuenta o tarjeta de crédito. 2. Una vez que el Solicitante de la transacción indica la información completa a ser ingresada en el sistema, el mismo genera un número de identificación único asociado a esta solicitud (ráfaga), en el caso de un deposito a tarjeta de crédito antes del nombre del titular imprime un código de verificación del Banco, fecha, hora y código de oficina en donde se realizó el deposito. En el caso de un depósito de cuenta 92

93 imprime nombre del titular, cedula de identidad, fecha, hora y código de oficina en donde se realizó el depósito. Caminos alternativos 4. En el paso 1, si el Solicitante de la Transacción decide abandonar el ingreso de la solicitud de la transacción, bien sea porque él mismo detectó un problema por falta de datos y decide realizar la solicitud en otro momento, el cajero puede salir del sistema y no registrar ninguna solicitud. 5. En el paso 2, si el Solicitante de la Transacción no indica la información completa solicitada en el paso 1, el sistema no generará el número de identificación único hasta tanto no complete la información solicitada. Post-condición: La instancia del caso de uso termina cuando el sistema genera el número de identificación único para la solicitud de la transacción o cuando no se genera ninguna solicitud, porque el Solicitante de la Transacción decide abandonar el servicio y no realiza la solicitud de la transacción. Verificar Solicitud: Precondición: El Solicitante de la Transacción debe haber proporcionado toda la información para procesar el depósito en cuenta o depósito de tarjeta de crédito, para ser registrado en sistema del banco una nueva transacción. Flujo de sucesos Camino básico 1. El Supervisor de la Oficina invoca al caso de uso para buscar en el sistema la nueva solicitud de transacción y verifica los datos del cliente, a través del nombre del solicitante y cedula de identidad. 93

94 2. El Supervisor de la Oficina revisa los datos del depósito monto y banco tutor de la cuenta y evalúa si procede la autorización y la ejecución de la misma respetando montos y tiempos de respuestas de cada banco tutor. 3. El Supervisor de la Oficina autoriza la solicitud de transacción en el sistema de acuerdo al tipo de servicio depósito a cuenta o tarjeta de crédito. En ambos casos es inmediata por los acuerdo en los tiempos de respuestas. 4. El Supervisor de la Oficina autoriza en el Sistemas y el estatus de la solicitud de transacción pasa a Autorizada. Caminos alternativos 5. En el paso 1, si no existe ninguna solicitud de transacción nueva, el Supervisor de la oficina puede abandonar el sistema. 6. En el paso 1, si existe más de una solicitud de transacción nueva, el Supervisor de la Oficina revisa y verifica la misma. Post-condición: La instancia del caso de uso termina cuando se autoriza la solicitud de transacción, o cuando no se autoriza la solicitud de transacciones, porque no existe ninguna solicitud nueva. Autoriza carga de Transacción en el Sistema: Precondición: El Supervisor de la Oficina ha revisado y verificado la solicitud de transacción. Ahora procede a autorizar la solicitud. Flujo de sucesos Camino básico 1. El Supervisor de la Oficina invoca al caso de uso para buscar en el sistema la solicitud de transacción nueva, verifica y prioriza por tipo de transacción. 94

95 2. El Supervisor de la Oficina revisa la carga actual de la transacción de los cajeros en el sistema. Para ello ubica en el sistema el total de transacciones nuevas por cada cajero. 3. El Supervisor de la Oficina decide autorizar la solicitud de transacción a los cajeros de la oficina que son quienes cargan la transacción en el sistema. 4. El Supervisor de la Oficina actualiza el estatus de la solicitud de transacción en el sistema a Autorizado y el sistema actualiza el campo de taquilla y cajero que ejecutara en el sistema la solicitud del cliente. 5. La prioridad de la solicitud de transacción es inmediata, el Supervisor de la Oficina autoriza, y el cajero visualiza en el sistema el estatus de la transacción en el sistema, para que ejecute de inmediato el caso de uso Procede a ejecutar operación de taquilla. Caminos alternativos 6. En el paso 1, si no existe ninguna solicitud de transacción nueva, el Supervisor de la Oficina puede abandonar el sistema. 7. En el paso 1, si existe más de una solicitud de soporte de transacción nueva, el Supervisor de la Oficina, las selecciona y verifica de acuerdo al monto, titular, cedula de identidad y banco tutor. Post-condición: La instancia del caso de uso termina cuando se autoriza la solicitud de la transacción a Autorizar carga de transacción en el Sistema. Ejecutar Soporte: Precondición: El Supervisor de la Oficina verifica, revisa y autoriza la solicitud de la transacción del Cajero de la Oficina. Ahora el Cajero de la Oficina procede a ejecutar la operación de taquilla. 95

96 Flujo de sucesos Camino básico 1. El Cajero de la Oficina invoca al caso de uso para buscar en el sistema la solicitud de la transacción con estatus Autorizada y donde el responsable de ejecución este asignado al número de taquilla y a su nombre. 2. El Cajero de la Oficina ejecuta el servicio solicitado. 3. El Cajero de la Oficina actualiza en el sistema el estatus de la solicitud y la misma está en proceso. Caminos alternativos 4. En el paso 1, si existe una solicitud de transacción con estatus autorizada, el Cajero de la oficina procesa la solicitud. Post-condición: La instancia del caso de uso termina cuando se actualiza la solicitud de la transacción a estatus en proceso. Completar Servicio: Precondición: El Cajero de la Oficina ha iniciado la ejecución del servicio de solicitud de la transacción. Ahora procede a completar el servicio del cliente. Flujo de sucesos Camino básico 1. El Cajero de la Oficina invoca al caso de uso culminar en el sistema el número de la solicitud de la transacción con estatus en proceso. 2. El Cajero de la Oficina actualiza en el sistema el estatus de la solicitud a Completada y el sistema registra la fecha, hora actual, número de comprobante. 96

97 3. El Cajero de la Oficina participa al Solicitante de la Transacción que el servicio asociado a la solicitud de transacción fue completado, para que ejecute de inmediato el caso de uso Conformar Servicio con Impresión del Comprobante. Camino alternativo 4. En el paso 2, El Cajero de la Oficina procede a emitir detalle de la transacción. Post-condición: La instancia del caso de uso termina cuando se actualiza la solicitud de la transacción a Completar la Operación de Taquilla. Conformar Servicio: Precondición: El Cajero de la Oficina ha ejecutado y completado la solicitud de transacción y le ha participada al cliente que es el Solicitante del Servicio. Que puede verificar el resultado del servicio ya conformado. Otra condición, es que el Solicitante de la transacción haya decidido cancelar una solicitud de transacción, dado que no tienen todos los datos completos para realizar dicho solicitud. Flujo de sucesos Camino básico 1. El Solicitante de la Transacción invoca al caso de uso para verificar los resultados del servicio que solicitó. 2. El Solicitante de la Transacción conforma el resultado del servicio solicitado. 3. El Solicitante de la Transacción ubica en el sistema la solicitud asociada al servicio de solicitud de la transacción y actualiza el estatus de la solicitud a Conformada. El estatus anterior de la solicitud debe ser Completada, lo cual indica que se ejecutó el servicio completo. Camino alternativo 97

98 4. En el paso 2, si el Solicitante de la Transacción no está conforme con el resultado del servicio, lo comunica de inmediato al Cajero y le participa de la situación para que no ejecute el paso número 3. El Cajero deberá elevar de inmediato la solicitud al Supervisor de la Oficina y realizar las acciones correctivas necesarias para que el Solicitante de la transacción conforme el resultado del comprobante. Post-condición: La instancia del caso de uso termina cuando se actualiza la solicitud de la transacción a Conformada, cuando no se actualiza la solicitud de la transacción, porque el Solicitante de Transacción no está conforme con el resultado del servicio se procede a cancelar la solicitud del cliente. Gestionar el Reverso: Precondición: Que existan solicitudes de transacción conforme, es decir, en estatus Completada, Conformada. Ahora el Supervisor de la Oficina procede a evaluar y hacer seguimiento a estas solicitudes con el banco tutor de la cuenta. Flujo de sucesos Camino básico 1. El Supervisor de la Oficina invoca al caso de uso para buscar en el sistema la solicitud de transacción a reversar, es decir con estatus Conformada, pero que debe ser reversada por error en monto. 2. El Supervisor de la Oficina actualiza en el sistema el estatus de la solicitud a Reversada si la solicitud está conformada por el Solicitante de la Transacción (está en estatus Conformada ). 3. El Supervisor de la Oficina emite desde el sistema el reporte, de las solicitudes reversadas. 98

99 Caminos alternativos 4. En el paso 1, si no existe ninguna solicitud de transacción a reversar, es decir en estatus de reverso, el Supervisor de la Oficina puede abandonar el sistema. 5. En el paso 2, si existe más de una solicitud de transacción con estatus de reverso, el Supervisor de la Oficina podrá gestionar todas esas solicitudes. Post-condición: La instancia del caso de uso termina cuando se actualiza la solicitud de transacción a reversado, o cuando no se actualiza la solicitud de transacción, porque no existe ninguna solicitud de reverso. Autorizar Reverso: Precondición: Que exista una solicitud para reversar de un cliente solicitante de la transacción para autorizarlo en el sistema. Ahora el Supervisor de la Oficina y el cajero de la oficina procede a realizar el reverso. Flujo de sucesos Camino básico 1. El Cajero de la Oficina y el Supervisor de la Oficina invocan al caso de uso para ingresar en el sistema y reversar la transacción. 2. El sistema comprueba la solicitud de la transacción. El sistema solicita la previa autorización al Supervisor de la Oficina para que el cajero proceda a realizar el reverso en el sistema. Caminos alternativos 3. En el paso 1, El Supervisor de la Oficina y Cajero, pueden ingresar al sistema para autorizar y procesar el reverso de la transacción, y en el paso 2 sólo se puede reversar la transacción solo si está autorizado el reverso por el Supervisor de la 99

100 oficina, el sistema verifica que la transacción de reverso este autorizado para que el cajero proceda al reverso. Post-condición: La instancia del caso de uso termina cuando se realiza el reverso. Disciplina Análisis Para analizar los requisitos con mayor profundidad, estructurarlos de manera que faciliten su comprensión, mantenimiento e identificar posible mejoras al sistema, se presenta el modelo de análisis del sistema para esbozar la funcionalidad del sistema, y que pueda considerarse como la primera aproximación al modelo de diseño. Tal como lo menciona la metodología RUP, para la disciplina de análisis se recomienda utilizar diagramas de colaboración, dado que el objetivo principal es identificar requisitos y responsabilidades sobre los objetos. Los diagramas de colaboración y flujos de sucesos-análisis representan a su vez el modelo de análisis del sistema. Diagramas de colaboración y flujos de sucesos-análisis asociados al Sistema A través de los siguientes diagramas de colaboración y descripción del flujo de sucesosanálisis, se muestra y se explica la realización de cada uno de los casos de uso del modelo de casos de uso del Sistema Automatizado de Soporte y Atención al Usuario presentando en el punto anterior de Captura de Requisitos como Casos de Uso. Diagrama de colaboración del caso de uso Solicitar Transacción Figura 27. Diagrama de colaboración del caso de uso Solicitar Transacción. Fuente: Autor 100

101 Flujo de sucesos-análisis: El Solicitante de la Transacción llega a la taquilla y realiza la entrega de los datos básicos asociada a la solicitud de servicio (1, 2). La Solicitud de datos básicos obliga a ingresar los datos mínimos necesarios en el sistema de Banca Pública, luego utiliza Ingresar solicitud para validar y procesar la transacción y generar la solicitud en el sistema (2, 3, 4). El objeto Ingresar solicitud utiliza una secuencia de pasos que permitan al sistema realizar una validación de los datos del cliente con el Banco Tutor. En donde estarán reflejados los datos del titular, fecha, hora, monto y cuenta tutora de la solicitud (3). A través del Sistema de Banca Pública se muestran tanto los datos de la solicitud de la transacción que ingresó el cajero como los datos generados por el sistema (4,5). Diagrama de colaboración del caso de uso Verificar Solicitud: Figura 28. Diagrama de colaboración de caso de uso Verificar Solicitud. Fuente: Autor. 101

102 Flujo de sucesos-análisis: El Supervisor de Oficina utiliza el sistema para buscar la solicitud para consultar nuevas solicitudes de transacción, es decir aquellas solicitudes con estatus Nueva, para ello, ingresa al criterio de Banca Pública (1). A través del sistema verifica si existen solicitudes que cumplan con la condición de nuevas solicitudes de transacción para Banca Pública. A continuación permite que el Supervisor de Oficina complete el proceso verificando los campos: nombre del cliente, cedula de identidad, monto y Banco Tutor de la cuenta, prioridad de la solicitud, y le permite cambiar el estatus a Autorizada (2). El objeto Realizar Verificación a la solicitud donde consulta la fecha y hora actual del sistema y se procede a realizar la autorización (3, 4). A través del objeto Visualización de la solicitud de transacción se muestra la misma ya verificada incluyendo la fecha de autorización de la solicitud (5, 6). Diagrama de colaboración del caso de uso Autorizar Carga de Transacción en el Sistema: Figura 29. Diagrama de colaboración del caso de uso Autorizar Solicitud. Fuente: Autor. 102

103 Flujo de sucesos-análisis: El Supervisor de la Oficina utiliza el sistema para buscar de solicitud a fin de consultar solicitudes de transacción cargadas el sistema, es decir aquellas solicitudes con todos los datos básicos cargados, para ello, ingresa en el criterio de Banca Pública buscando las solicitudes nuevas cargada (1). A través de esta consulta se verifica en sistema de banca Pública si existen Solicitudes que cumplan la condición cargada, las muestra en el orden que han sido cargada por taquilla y es decir en orden cronológico, colocando en primer lugar la solicitud con mayor prioridad y/o antigüedad. A continuación permite que el supervisor de oficina autorice la solicitud, completando el campo: Cajero de Oficina ingresa y le permite verificar el campo estatus a Autorizada (2). El objeto Autorizar solicitud consulta la fecha y hora actual del sistema y procede a procesar la transacción (3, 4). A través del objeto Visualizador de solicitud de transacción se muestra la solicitud procesada incluyendo el cajero y la fecha de ingreso de la solicitud en el sistema (5, 6). Diagrama de colaboración del caso de uso Procede a Ejecutar Operación de Taquilla: Figura 30. Diagrama de colaboración del caso de uso Ejecutar Soporte. Fuente: Autor. 103

104 Flujo de sucesos-análisis: El cajero a través del sistema busca la Solicitud de transacción con estatus Autorizada en vista que es el responsable de la ejecución de dicha solicitud (1). El cajero espera respuesta en línea por parte del Banco tutor de la cuenta validando los datos del cliente. Para proceder a ejecutar operación de taquilla (2). A través del objeto Ejecutar solicitud se consulta la fecha y hora actual del sistema y se la asigna a la fecha de solicitud del servicio y se procede registrar los datos en el sistema (3,4). A través del objeto consulta de solicitud se muestra la solicitud en ejecución, incluyendo la fecha de inicio de la ejecución de la misma (5,6). Diagrama de colaboración del caso de uso Completa la Operación de Taquilla: Figura 31. Diagrama de colaboración del caso de uso Completar Servicio. Fuente: Autor. Flujo de sucesos-análisis: El Cajero de la Oficina procede a completar la solicitud, actualizado en el sistema el estatus de la solicitud a Completada. A través del objeto Completar solicitud se consulta la fecha y hora actual 104

105 del sistema y se la asigna a la fecha de finalización de la solicitud y procede a registrar en el sistema (3, 4). A través del objeto consulta de solicitud se muestra la solicitud completada, la incluyendo la fecha de finalización de la solicitud y el detalle de la transacción (5,6). Diagrama de colaboración del caso de uso Conformar Servicio: Figura 32. Diagrama de colaboración del caso de uso Conformar Servicio. Fuente: Autor. Flujo de sucesos-análisis: El Solicitante de la transacción debe conformar la solicitud de transacción ejecutada y activa el objeto verifica solicitud. El Solicitante de la transacción verifica su solicitud con la información especificando por el mismo solicitante (1). A través de verifica solicitud se evidencia la información de la solicitud de transacción con su nuevo estatus a Conformada (2). El objeto Conformación solicitud consulta la fecha y hora actual del sistema y se la asigna a la fecha de conformación de la solicitud y procede a registrar la ráfaga en sistema (3,4). 105

106 A través del objeto Consulta de solicitud se muestra la solicitud conformada incluyendo la fecha y hora de su conformación (5,6). Diagrama de colaboración del caso de uso Gestionar Reverso: Figura 33. Diagrama de colaboración del caso de uso Gestionar Reverso. Fuente: Autor. Flujo de sucesos-análisis: El Supervisor de la Oficina utiliza el objeto Consultar solicitud con la finalidad de identificar al cliente para gestionar solicitud el reverso relacionado con la solicitud de la transacción ya existente. Cuando el Supervisor de la oficina ingresa para gestionar el reverso: Ingresa al sistema por Consultar solicitud, y podrá encontrar la solicitud de transacción pertenece al cliente (1). que A través del objeto Gestión de reversos se verifica en sistema que la identificación de la solicitud de transacción existente, sea la correcta y se procede a realizar la gestión, con fecha de la transacción y hora actual del sistema (2,3). A través del objeto Consultar solicitud se muestra la solicitud modificada, incluyendo la fecha y hora de creación de la transacción (4, 5). 106

107 Diagrama de colaboración del caso de uso Autorizar reverso: Figura 34. Diagrama de colaboración del caso de uso Autorizar Reverso. Fuente: Autor. Flujo de sucesos-análisis: El Supervisor de la Oficina y/o el Cajero de la Oficina utiliza el objeto Consultar solicitud con la finalidad de identificar al cliente para autorizar solicitud del reverso relacionado con la solicitud de la transacción ya existente. Cuando el Supervisor de la oficina ingresa para autorizar el reverso: Ingresa al sistema por Consultar solicitud, y podrá encontrar la solicitud de transacción pertenece al cliente que espera por autorización (1). que A través del objeto solicita autorización se valida en sistema que la identificación de la solicitud de transacción existente, sea la correcta y se procede a realizar la autorización, la cual se registrará con fecha de la transacción y hora actual del sistema (2,3). El Cajero de la Oficina ingresa a través del objeto Consultar solicitud y el sistema muestra la solicitud ya autorizada, incluyendo la fecha y hora de la autorización del reverso (4, 5). 107

108 Disciplina Diseño En este flujo de trabajo se refina el análisis para poder implementar los diagramas de Colaboración de análisis de cada caso de uso y se da forma al sistema, tratando en lo posible de mantener la estructura definida en el modelo de análisis. El modelo de diseño del sistema representa una entrada apropiada y un punto de partida para las actividades de implementación del sistema. Según la metodología RUP, para el diseño de un caso de uso se utilizan diagramas de clases, donde se identifican las clases de diseño y los subsistemas del caso de uso; Diagramas de secuencia para distribuir el comportamiento del caso de uso entre los objetos del diseño que interactúan; se definen los requisitos para las operaciones de las clases de diseño, se capturan los requisitos de implementación del caso de uso y se muestran las interfaces. Todo lo anterior representa el modelo físico o de diseño del sistema. Diseño de los casos de uso asociados al Sistema A través de los siguientes diagramas de clases, diagramas de secuencias y descripción del flujo de sucesos-diseño, se identifican las clases de diseño y se describen las interacciones entre los objetos de diseño de la realización de cada uno de los casos de uso del modelo de análisis del Sistema de Integración de la Banca Pública, presentando en el punto anterior de Análisis. Diagrama de clase del caso de uso Solicitar Transacción: Figura 35. Diagrama de clases del caso de uso Solicitar Transacción. Fuente: Autor. 108

109 A continuación se muestra el diagrama de secuencia asociado con este diagrama de clases, que detalla la secuencia de interacciones detalladas del caso de uso Solicitar Transacción. Diagrama de secuencia del caso de uso Solicitar Transacción: Figura 36. Diagrama de secuencia del caso de uso Solicitar Transacción. Fuente: Autor. Flujo de sucesos-diseño: El Solicitante de la transacción solicita el servicio mediante la taquilla de la oficina, el cajero de la oficina ingresa al sistema, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del mismo, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Solicitante. El Solicitante de la transacción entrega los datos correspondiente a su solicitud de transacción mediante la taquilla, para ello se ingresa el campo requerido banca pública que corresponde a la descripción de la solicitud, y se procede a ingresar los datos en los campos tipo de solicitud 109

110 si es pago de tarjeta de crédito o deposito en efectivo, número de cuenta, cédula de identidad, monto en Bolívares. A través de Procesamiento de solicitudes se comprueba los datos ingresados y se registra la nueva solicitud, generando un número de identificación para esta solicitud que corresponde a la identificación única de cada solicitud de transacción lo que se denomina ráfaga de transacción. Se completan los siguientes campos internos de la solicitud: Fecha de creación: con la fecha y hora del servidor. Creado por: con la identificación del cajero y supervisor responsables de la carga de la transacción. Diagrama de clase del caso de uso Verificar Solicitud: Figura 37. Diagrama de clases del caso de uso Verificar Transacción. Fuente: Autor. 110

111 Diagrama de secuencia del caso de uso Verificar Transacción: Figura 38. Diagrama de secuencia del caso de uso Verificar Transacción. Fuente: Autor. Flujo de sucesos-diseño: El Supervisor de Oficina utiliza el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del mismo, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Administrador. El Supervisor de Oficina consulta una solicitud de transacción mediante la pantalla verificación de solicitud, para ello ingresa al menos uno de los siguientes criterios de búsqueda: Número de cédula: ingresa el número de identificación del cliente. Estatus de la solicitud: ingresa el estatus Nueva. Solicitada por: ingresa el nombre del cliente solicitante. Creada desde: ingresa el rango predeterminado de fecha de creación de la solicitud (hoy, ayer, hace una semana, hace un mes, hace 6 meses). Actualización de solicitud comprueba las solicitudes que están en estatus Nueva, y que además cumplan el criterio de búsqueda ingresado por el supervisor y procede a mostrarlas. 111

112 El Supervisor de Oficina, según sea el caso, procede de la siguiente manera: 1. Selecciona la solicitud a verificar mediante verificación de solicitud y procede a cambiar los siguientes campos: Estatus a verificada, una vez que el banco tutor de la cuenta valida los datos del cliente. Tipo de transacción: Según la descripción suministrada por el solicitante y el tipo de transacción a realizar. A través de Autorización de solicitud se pasa esta solicitud a Gestión de solicitudes que finalmente actualiza el estatus y el resto de los campos de la solicitud y completa los siguientes campos internos de la solicitud: Fecha de revisión: con la fecha y hora del servidor. Revisada por: con la identificación del usuario que está conectado, que en este caso corresponde al Supervisor. Diagrama de clase del caso de uso Autorizar Solicitud: Figura 39. Diagrama de clases del caso de uso Autorizar Transacción. Fuente: Autor. 112

113 Diagrama de secuencia del caso de uso Autorizar Solicitud: Figura 40. Diagrama de secuencia del caso de uso Autorizar Solicitud. Fuente: Autor. Flujo de sucesos-diseño: El Supervisor de Oficina utiliza el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del usuario, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Administrador. El Supervisor de Oficina consulta una solicitud de transacción mediante la pantalla Actualización de solicitud, para ello ingresa al menos uno de los siguientes criterios de búsqueda: Número de cédula: ingresa el número de identificación del cliente. Estatus de la solicitud: ingresa el estatus Verificada. Solicitada por: ingresa el nombre del cliente solicitante. Creada desde: ingresa el rango predeterminado de fecha de creación de la solicitud (hoy, ayer, hace una semana, hace un mes, hace 6 meses). 113

114 Actualización de solicitud comprueba las solicitudes que están en estatus Verificada, y que además cumplan el criterio de búsqueda ingresado por el Supervisor y procede a mostrarlas. El Supervisor de Oficina, según sea el caso, puede proceder de la siguiente manera: 1. Selecciona la solicitud a autorizar mediante Actualización de solicitud y procede a cambiar los siguientes campos: Estatus a Autorizada. 2. A través de Actualización de solicitud se pasa esta solicitud a Gestión de solicitudes que finalmente actualiza el estatus y el resto de los campos de la solicitud y completa los siguientes campos internos de la solicitud: Fecha de autorización: con la fecha y hora del servidor. Autorizada por: con la identificación del usuario que está conectado, que en este caso corresponde al Supervisor de Oficina. Diagrama de clase del caso de uso Ejecutar Transacción: Figura 41. Diagrama de clases del caso de uso Ejecutar Transacción. Fuente: Autor. 114

115 Diagrama de secuencia del caso de uso Ejecutar Transacción: Figura 42. Diagrama de secuencia del caso de uso Ejecutar Transacción. Fuente: Autor. Flujo de sucesos-diseño: El Cajero de Oficina utiliza el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del usuario, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Cajero. El Cajero de Oficina consulta una solicitud de transacción mediante la pantalla Actualización de solicitud, para ello ingresa al menos uno de los siguientes criterios de búsqueda: Número de cédula: ingresa el número de identificación del cliente. Estatus de la solicitud: ingresa el estatus Autorizada. Solicitada por: ingresa el nombre del cliente solicitante. Creada desde: ingresa el rango predeterminado de fecha de creación de la solicitud (hoy, ayer, hace una semana, hace un mes, hace 6 meses). 115

116 Actualización de solicitud comprueba las solicitudes que están en estatus Autorizada, donde se reflejaran las transacciones realizadas con el usuario del Cajero y que además cumplan el criterio de búsqueda ingresado por el Cajero de Oficina y procede a mostrarlas. El Cajero de oficina, según sea el caso, procede de la siguiente manera: 1. Selecciona la solicitud a ejecutar mediante Actualización de solicitud y procede a cambiar los siguientes campos: Estatus a En Proceso 2. A través de Actualización de solicitud se pasa esta solicitud para ejecutar la solicitud que finalmente actualiza el estatus y el resto de los campos de la solicitud y completa los siguientes campos internos de la solicitud: Estatus a En Proceso. Fecha de ejecución: con la fecha y hora del servidor. Diagrama de clase del caso de uso Completar Servicio: Figura 43. Diagrama de clases del caso de uso Completar Servicio. Fuente: Autor. 116

117 Diagrama de secuencia del caso de uso Completar Servicio: Figura 44. Diagrama de secuencia del caso de uso Completar Servicio. Fuente: Autor. Flujo de sucesos-diseño: El Cajero de Oficina utiliza el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del usuario, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Cajero. El Cajero de Oficina consulta una solicitud de transacción mediante la pantalla Actualización de solicitud, para ello ingresa al menos uno de los siguientes criterios de búsqueda: Número de cédula: ingresa el número de identificación del cliente. Estatus de la solicitud: ingresa el estatus Autorizada. Solicitada por: ingresa el nombre del cliente solicitante. 117

118 Creada desde: ingresa el rango predeterminado de fecha de creación de la solicitud (hoy, ayer, hace una semana, hace un mes, hace 6 meses). Actualización de solicitud comprueba las solicitudes que están en estatus Autorizada, donde se reflejaran las transacciones realizadas con el usuario del Cajero y que además cumplan el criterio de búsqueda ingresado por el Cajero de Oficina y procede a mostrarlas. El Cajero de oficina, según sea el caso, procede de la siguiente manera: Selecciona la solicitud a completar mediante Actualización de solicitud y procede a cambiar los siguientes campos: Estatus a Completada A través de Actualización de solicitud se pasa esta solicitud para completar la solicitud que finalmente actualiza el estatus y el resto de los campos de la solicitud y completa los siguientes campos internos de la solicitud: Fecha de finalización: con la fecha y hora del servidor. Finalizada por: con la identificación del usuario que está conectado, que en este caso corresponde al Cajero de Oficina. Diagrama de clase del caso de uso Conformar Servicio: Figura 45. Diagrama de clases del caso de uso conformar servicio. Fuente: Autor. 118

119 Diagrama de secuencia del caso de uso Conformar Servicio: Figura 46. Diagrama de secuencia del caso de uso Conformar Solicitud. Fuente: Autor. Flujo de sucesos-diseño: El Cajero de Oficina utiliza el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del usuario, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Cajero. Para conformar la solicitud: El Solicitante de la Transacción verifica la solicitud de transacción mediante el comprobante impreso, en donde se estará reflejado los siguientes criterios: Número de solicitud: número de identificación de la solicitud de transacción. Fecha de solicitud: con la fecha y hora del servidor. Solicitada por: refleja el nombre del cliente solicitante. Monto de la transacción: refleja el monto de la transacción Tipo de requerimiento: refleja el tipo de transacción completada. 119

120 Diagrama de clase del caso de uso Gestionar Reverso: Figura 47. Diagrama de clases del caso de uso Gestionar Reverso. Fuente: Autor. A continuación se muestra el diagrama de secuencia asociado con este diagrama de clases, donde se detalla la secuencia de interacciones detalladas del caso de uso Gestionar Reverso. Diagrama de secuencia del caso de uso Gestionar Reverso: Figura 48. Diagrama de secuencia del caso de uso Gestionar Reverso. Fuente: Autor. 120

121 Flujo de sucesos-diseño: El Supervisor de Oficina utiliza el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del usuario, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Administrador. Para gestionar reversos: El Supervisor de Oficina consulta una solicitud de transacción mediante la pantalla Actualización de solicitud, para ello ingresa al menos uno de los siguientes criterios de búsqueda: Número de cédula: ingresa el número de identificación del cliente. Estatus de la solicitud: ingresa el estatus Verificada. Solicitada por: ingresa el nombre del cliente solicitante. Creada desde: ingresa el rango predeterminado de fecha de creación de la solicitud (hoy, ayer, hace una semana, hace un mes, hace 6 meses). Actualización de solicitud comprueba las solicitudes que están en estatus Conformada, y que además cumplan el criterio de búsqueda ingresado por el Supervisor y procede a mostrarlas. El Supervisor de Oficina selecciona la solicitud a reversar mediante Actualización de solicitud y procede a cambiar los siguientes campos: Estatus a Reversada. Comentarios: Puede agregar comentarios u observaciones asociados a la actividad y/o motivo del reverso realizado. 121

122 Diagrama de clase del caso de uso Autorizar Reverso: Figura 49. Diagrama de clases del caso de uso Autorizar Reverso. Fuente: Autor. A continuación se muestra el diagrama de secuencia asociado con este diagrama de clases, donde se detalla la secuencia de interacciones detalladas del caso de uso Autorizar Reversos. Diagrama de secuencia del caso de uso Autorizar Reverso: Figura 50. Diagrama de secuencia del caso de uso Autorizar Reverso. Fuente: Autor. 122

123 Flujo de sucesos-diseño: El Supervisor de Oficina y/o Cajero de Oficina utilizan el sistema mediante la opción de Banca Pública, para introducir su identificación de usuario y su contraseña. El proceso Autentificación de usuarios comprueba la existencia del usuario, la coincidencia de la contraseña con el registro de usuario, que el estatus del usuario sea activo y verifica que el tipo de usuario corresponda con el tipo Administrador Supervisor de Oficina y tipo Cajero respectivamente. El Supervisor de Oficina consulta una solicitud de transacción mediante la pantalla Actualización de solicitud, para ello ingresa al menos uno de los siguientes criterios de búsqueda: Número de cédula: ingresa el número de identificación del cliente. Estatus de la solicitud: ingresa el estatus Solicitud Reversada. Solicitada por: ingresa el nombre del cliente solicitante. Creada desde: ingresa el rango predeterminado de fecha de creación de la solicitud (hoy, ayer, hace una semana, hace un mes, hace 6 meses). Actualización de solicitud comprueba las solicitudes que están en estatus Solicitud Reversada, y que además cumplan el criterio de búsqueda ingresado por el Supervisor y procede a mostrarlas. El Supervisor de Oficina, según sea el caso, puede proceder de la siguiente manera: Selecciona la solicitud a autorizar mediante Actualización de solicitud y procede a cambiar los siguientes campos: Estatus a Reverso Autorizada. A través de Actualización de solicitud se pasa esta solicitud a Gestión de solicitudes que finalmente el Cajero de Oficina actualiza el estatus y el resto de los campos de la solicitud, completando de esta manera la solicitud de transacción realizada por el cliente. 123

124 Clases de diseño asociadas a las realizaciones de los casos de usos del Sistema. A continuación se presentan el diseño de las clases, presentando los aspectos asociados a cada una: Operaciones, atributos, los estados y requisitos primordiales de la transacción. Solicitud: contiene las solicitudes de transacción. Operaciones: Crear solicitud(): Crea un registro de solicitud de transacción. Actualizar status(): Actualiza el status de la solicitud de acuerdo al proceso que previamente lo invoca. buscar solicitud(): Busca los registros de solicitudes, de acuerdo al criterio de selección ingresado previamente por el usuario. Atributos: idsolicitud Entero(11) NO NULO AUTO_INCREMENTO status_solicitud caracter(20) NO NULO tipo_solicitud caracter(50) solicitado_por caracter(20) creado_por caracter(20) fe_creacion fechahora modificado_por caracter(20) fe_modificacion fechahora detalle text PRIMARY KEY (idsolicitud) Requisitos de la solicitud de transacción: Los valores para el campo status_solicitud son: Nueva Verificada Autorizada En Proceso Completada Conformada Reversada 124

125 Los campos solicitado_por, creado_por y modificado_por sólo pueden contener: Un valor del campo user_name de la tabla usuario. El formato de los campos fe_creacion y fe_modificaciónes: En la base de datos: YYYY-MM-DD HH:MI:SS Mostrar en pantalla: DD-MM-YYYY HH:MI:SS Estados El siguiente diagrama de estados muestra la secuencia de estatus válida para la solicitud de transacción: Figura 51. Diagrama de estados para la clase Solicitud de transacción. Fuente: Autor. 125

126 Usuario: usuarios del sistema de soporte a usuarios. Operaciones: obtener acceso(): Consulta los datos de contraseña, status y tipo de usuario de la identificación de usuario que se conecta. Atributos: idusuario entero (11) NO NULO AUTO_INCREMENTO user_name caracter(20) NO NULO nombre caracter(100) status caracter(1) DEFECTO 'A' passwd caracter(50) oficina caracter(15) tipo_usuario caracter(1) DEFECTO 'U Requisitos de la solicitud de transacción: Campo user_name debe ser único El campo pasword debe ser guardado en formato encriptado. Los valores para el campo status son: A: Activo I: Inactivo Los valores tipo_usuario son A: Cajero U: Supervisor de Oficina Estados Status: Activo > Inactivo -> Activo tipo_usuario: Cajero > Supervisor -> Cajero Interfaces de usuario asociadas a la Clases de diseño A continuación se presentan las interfaces de usuarios asociadas a las clases de diseño Solicitud de transacción. 126

127 Interfaz de la clase de diseño Solicitud de Transacción: Ingreso de Solicitudes Figura 52. Interfaz de la clase de diseño Solicitud de transacción. Fuente: Autor Interfaz de usuario de la clase de autorización de transacción: Figura 53. Interfaz de la clase de diseño Autorización de transacción. Fuente: Autor 127