UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO INFISE: ORIGEN DE TARJETAS DE CREDITO Y FRONT PAGE VECTOR SOFTWARE MÉXICO S DE RL DE CV INGENIERO EN

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del proyecto: INFISE: ORIGEN DE TARJETAS DE CREDITO Y FRONT PAGE Empresa: VECTOR SOFTWARE MÉXICO S DE RL DE CV Memoria que como parte de los requisitos para obtener el título de: INGENIERO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN Presenta: ERICK STEPHEN FLORES OLIVA Asesor de la UTEQ Asesor de la Organización Ing. Flor Adriana Monroy Ing. Eduardo González Joyanes Santiago de Querétaro, Qro. mayo del 2014

2 RESUMEN En este documento se encuentran plasmados los puntos a implementar para llegar al objetivo y meta de la empresa VECTOR SOFTWARE MÉXICO S DE RL DE CV, que es brindarle ganancias y mayor productividad a sus clientes, y para ello basan sus desarrollos en la calidad, la seguridad y el óptimo desempeño de los aplicativos solicitados para sus clientes, con lo cual VECTOR SOFTWARE MÉXICO S DE RL DE CV, logrará implantar su mercado laboral en México de forma tal que sus clientes queden totalmente satisfechos y regresen a solicitar más desarrollos, así podrá demostrar que es una empresa confiable. El aplicativo que compete a la creación del presente documento, es INFISE (gestión del impuesto tributario a la iglesia alemana) que el cliente ha solicitado; contiene sus respectivos servicios que requieren para tener el control sobre el impuesto religioso de los habitantes de Alemania, incrementan favorablemente la gestión de porcentajes declarados a la iglesia, esto beneficia tanto a su gobierno, al cliente final y los mismos habitantes, debido a que todos conocerán los porcentajes que han repartido a lo largo de su vida y sabrán tener mayor control al momento de declarar impuestos. Todo el desarrollo de INFISE se llevará a cabo con la tecnología emergente de BankSphere, y adicionalmente con todo lo que está contiene como framework, VECTOR SOFTWARE MÉXICO S DE RL DE CV se seguirá posicionando a un nivel de renombre mundial. (Palabras clave: BankSphere, INFISE, Vector, desarrollo, calidad) 2

3 SUMMARY The INFISE project is about management and creation of information related to capital tax that each person in Germany should do every year. Therefore the project s objective is to have a control on tax of each person and each couple that lives in Germany. The Software reads a Tax Unit ID and as a result, gives a complete list with all taxes which each person has paid in both old periods and new periods, all of them are registered in yearly periods. In this last quarter. I was able to finish the project on time, to be better working in teams, getting the acknowledgement from my boss and obtain a lot of knowledge over BankSphere, which is our development tool. In addition. I learned much about German culture and its social laws. In summary, this project was achieved on time and the client is satisfied with Vector Company, in fact the client qualifies the Software with incomparable quality and security. Erick Stephen Flores Oliva ITI-15 3

4 DEDICATORIAS A todos los aquí presentes, amigos, profesores, Ingenieros, familiares, por creer en mí y mostrarme su confianza y seguridad, por brindarme todo lo necesario para poder llegar a este momento, por sus enseñanzas teóricas, pero sobre todo por sus enseñanzas de vida. Familia y amigos gracias por ser parte importante de mí propio crecimiento personal y también profesional, por demostrar su cariño y gratitud en todo momento, aun en las situaciones más adversas de la carrera. Es a ustedes la dedicatoria de más de 15 años de constancia y estudio, los mismos que en su momento he llevado por buen camino y el día de hoy veo culminado, sin dejar a un lado los años, esfuerzos y derrotas que aún faltan. 4

5 AGRADECIMIENTOS Agradezco primeramente a Dios por haberme concedido la dicha de la vida y la oportunidad de cursar mis estudios profesionales en la Universidad Tecnológica de Querétaro, por permitirme llegar hasta el punto de recibir un título profesional como Ingeniero en Tecnologías de la Información. Además por prestarle vida a todos los seres queridos que me ayudaron a llegar a este momento. Sé que sin él yo no sería nada y sin él jamás podría hacer nada. Gracias al esfuerzo arduo de mis padres, Jorge Flores Ramírez e Irene Oliva Morales por su apoyo, por no dejarme sin los estudios debidos, además de sus grandes sacrificios para invertir en mi preparación. A su dedicación y atención hacia mi persona como estudiante y como hijo. Gracias por enseñarme el significado de responsabilidad ante las situaciones laborales, como adulto y a aprender de mis aciertos y errores. Puedo afirmarles que han cumplido con su responsabilidad como padres en forma completa. A mi hermana Stephanie Emily Villegas Oliva, que siempre me enseño la manera en que debo asimilar las situaciones adversas y a superar los momentos más difíciles. Asimismo le agradezco que en las circunstancias en las que más la necesitaba ella estuvo ahí para socorrerme. Sinceramente gracias por ser mi hermana ya que no hay otro ser al que pueda llamar hermano como lo puedo hacer contigo. 5

6 Le doy mi más grande y merecido reconocimiento a la persona que hizo en buena medida posible mi entrada a la UTEQ, el Ing. Claudio, ya que sin su apoyo, desde el punto de vista académico no habría conseguido un buen promedio y un lugar dentro de la Universidad. De la misma manera quiero reconocer a mis más grandes amigos, Luis Enrique Nieves Álvarez y Fabián Alí Ayala Beltrán, los cuales siempre han estado ahí para mí y yo para ellos, en cada momento de nuestra infancia, adolescencia y ahora en nuestra vida joven adulta, seguimos apoyándonos en cualquier circunstancia y acumulando experiencias juntos como amigos y hermanos. No puedo dejar de lado a una persona que estuvo a mi lado desde el momento que ingrese a la universidad y que se encuentra conmigo el último día de mis estudios, su nombre es Jazmín Rodríguez Rodríguez, es mi novia y desde que estuvimos juntos me ha apoyado siempre no solo en el ámbito personal, también me supo acompañar en estudios y ayudar en conocimientos que yo desconocía de la propia carrera y aún más, me ayudo incluso con consejos para el trabajo profesional fuera de la UTEQ. Por esto y mil cosas más le doy mis más sinceros agradecimientos de todo corazón. A manera de reconocimiento general, a cada compañero de Universidad, ya que sin ellos no hubiese podido superar cada reto escolar, fueron mi ayuda y apoyo incondicional. 6

7 Y como resultado hoy puedo decir que soy un Ingeniero en TI íntegro, con defectos que aun debo pulir y trabajar sobre ellos, a pesar de todo puedo afirmar sin temor a equivocarme, que todas las personas mencionadas anteriormente y los que no pude describir en detalle, fueron son y serán aquellos con los que sé que puedo confiar plenamente y los que me continuarán ofreciendo su mano a lo largo de mis estudios posteriores y en los aspectos de vida y profesionista. Erick Stephen Flores Oliva. 7

8 ÍNDICE RESUMEN... 2 SUMMARY... 3 DEDICATORIAS... 4 AGRADECIMIENTOS... 5 ÍNDICE... 8 I. INTRODUCCIÓN I.I Los principios de Vector I.II Misión I.III Valores I.IV Visión II. ANTECEDENTES III. JUSTIFICACIÓN IV. OBJETIVOS IV.I Objetivo General IV.II Objetivos Específicos V. ALCANCE VI. ANÁLISIS DE RIESGOS VI.I Uso de Cuestionarios VI.II Análisis de escenarios VI.III Esquema RBS o EDT VI.IV Análisis FODA VI.V Lluvia de ideas VI.VI Selección y omisión de riesgos VI.VII Tabla de Evaluación de Riesgos VI.VIII Tabla FMEA (Failure Mode and Effects Analysis) VI.IX Matriz de Respuesta al Riesgo

9 VII. FUNDAMENTACIÓN TEÓRICA VII.I Vector VII.II Santander VII.III Produban VII.IV Isban VII.V BankSphere, BKS VII.VI Vega VII.VII Rational Rose VII.VIII Vega Modeler VII.IX Mira VII.X Mira Lógico VII.XI Ciclo de vida del Software en Vector VII.XII COBOL VIII. PLAN DE ACTIVIDADES IX. RECURSOS MATERIALES Y HUMANOS IX.I Recursos Humanos IX.II Recursos Materiales X. DESARROLLO DEL PROYECTO X.I INFISE: Front Page y Origen de Tarjetas de Crédito X.II INFISE: ciclo de Vida de Software en Vector X.III INFISE: requerimientos esenciales del sistema X.IV INFISE: funcionalidades técnicas del sistema X.V Listado y detalle del historial de reparto de impuesto religioso por Tax Unit ID o número de persona X.VI Alta de un nuevo periodo para el reparto del porcentaje especial del impuesto religioso X.VII Modificación de un periodo para el reparto del porcentaje especial del impuesto religioso X.VIII Búsqueda del histórico de impuestos religiosos por Tax Unit ID

10 X.IX Búsqueda del Número de Persona asociados a una comunidad para el tratamiento de impuesto X.X Análisis y definición X.XI Modelo Lógico: maqueta navegable X.XII Construcción / MF INFISE X.XIII INFISE: Origen de Tarjetas de Crédito X.XIV INFISE: Front Page X.XV Despliegue / Qa Compliance (Certificación técnica) X.XVI Preproducción XI. RESULTADOS OBTENIDOS XII. CONCLUSIONES Y RECOMENDACIONES XIII. ANEXOS XIV. BIBLIOGRAFÍA 10

11 I. INTRODUCCIÓN Se realiza el proyecto INFISE (nueva tecnología / organización en Santander México), el cual consta de dos partes, la función de originar las tarjetas de crédito y construir desde la base una página visual funcional en Internet (Front Page) para el cliente de Santander y para el mismo corporativo bancario. Se trabaja dentro del ámbito de desarrollo de Software funcional. Por una parte contamos con el Origen de Tarjetas de Crédito, que se hará bajo el esquema de diseño de Software denominado MVC (Modelo, Vista y Controlador). Para fines de desarrollar el proyecto eficientemente se trabajará en un sector solamente, el cual corresponde a la parte de controlador, que es el modo de llegar a los datos y manipularlos según sea conveniente. Para efectos de una correcta nomenclatura dentro de la plataforma BankSphere, a la sección de Controlador se le llama Lógica de Negocio (LN) y a su vez ésta misma accede mediante llamadas al host de Grupo Santander usando elementos Transacción Operación (TRX) los cuales son programas desarrollados bajo el lenguaje de programación de COBOL, y hacen transacciones de datos corporativos para poder trabajar con ellos. Ya sea para buscar, dar de alta, eliminar, modificar o consultar un registro o varios registros. 11

12 La implementación de Front Page se verá figurada de manera visual mediante una aplicación de escritorio, para instalar en Grupo Santander (host), y por otra parte la plataforma Web (Front Page), que es para el cliente de Grupo Santander. Todo el desarrollo del sistema se lleva a cabo usando la plataforma denominada BankSphere, la herramienta corporativa del Grupo Santander para realizar aplicaciones bancarias. Dicha herramienta genera código J2EE aunque su filosofía es la realización de aplicaciones de manera visual limitando la programación a Javascript en páginas y Java en la parte servidor. Además realiza pequeñas piezas de código generadas por cada programador, es decir que el programador sólo se encargará de un módulo del proyecto y al final se reúnan en conjunto para implantar el proyecto final. La principal ventaja es que ahora los antiguos programas de 390 desarrollados en COBOL, tomarán un diseño visual atractivo al afiliado o cliente de Grupo Santander y adicionalmente la visión a largo plazo es unificar el diseño del banco Santander a nivel mundial, y así todo sea estandarizado e implique rendimiento al momento de desarrollar y dar mantenimiento de los aplicativos. 12

13 La empresa de nombre Vector, es una compañía 100% de capital español, cumple 11 años en el mercado como proveedor global de soluciones tecnológicas integrales desarrolladas a la medida de sus clientes. Ahora, como parte de su expansión internacional, ha abierto sus puertas en México y recibe el nombre de VECTOR SOFTWARE MÉXICO S DE RL DE CV. La compañía ha incrementado su actual composición accionarial con un equipo de profesionales de dilatada experiencia dentro del sector de la consultoría TI, para aportar el mayor valor a sus clientes y potenciar el crecimiento y la internacionalización. La prueba más fehaciente de éste hecho es la expansión tan repentina de manera internacional. El nuevo grupo inversor está liderado por Carlos Delgado Suárez, como nuevo consejero delegado de la compañía y Juan Manuel Rebollo Feria como director general. Somos una empresa que ofrece servicios integrales en tecnología e innovación en pleno crecimiento y desarrollo gracias a nuestra cercanía, flexibilidad y profesionalidad con nuestros clientes. Nuestro objetivo es seguir generando empleo y riqueza en España. Queremos afrontar importantes retos, implementar y diversificar los servicios, sectores y territorios, además de continuar con la internacionalización de la compañía. Señala el nuevo consejero delegado, Carlos Delgado Suárez. 13

14 En la actualidad, Vector cuenta con 6 centros de producción de software en España, situados en Madrid (Centro empresarial La Finca y Pozuelo) Albacete, Córdoba, Coruña, Vigo, y Sevilla; 4 en Latino América, en Brasil (Saõ Paulo y Campinas), Perú (Lima) y Chile; 1 en Andorra y otro en Inglaterra y están en proyecto próximas aperturas en México y EEUU (Boston). Su especialización en el outsourcing de aplicaciones es una de las ventajas que ofrecen para sus clientes, un servicio innovador en la gestión y que proporciona a las empresas excelencia operativa. En 2010 y 2011 se amplía la oferta de servicios de consultoría (tecnológica y de negocio) y soluciones (CRM, BI, ERP, infraestructuras) y se abren nuevos centros de producción y comerciales (A Coruña, Vigo, Sevilla) para dar cobertura a las necesidades de un mercado tecnológico en plena expansión. En 2008 se inaugura el centro de desarrollo de software en Córdoba dando respuesta a la creciente demanda de soluciones tecnológicas en Andalucía. En 2007 se pone en marcha el centro de producción en Albacete. Su contribución ha sido decisiva para estimular e impulsar el talento, y para desarrollar la industria del software en la zona con proyectos de alta innovación para clientes nacionales e internacionales. 14

15 En el año 2003 se abre un nuevo centro de producción en Madrid, dentro del Parque Empresarial La Finca de Pozuelo de Alarcón, con laboratorios especializados para cada tipo de tecnología. Vector nace en el año 2002 con un objetivo claro: construir una red de centros de producción de Software que acerque las soluciones tecnológicas más avanzadas a las empresas y administraciones públicas. El proyecto arrancó en Madrid (Villanueva de la Cañada) mediante un acuerdo con el Centro para el Desarrollo, Investigación y Aplicación de Nuevas Tecnologías (CEDIANT) de la Universidad Alfonso X "El Sabio" (UAX). Vector ha basado su crecimiento en cinco pilares fundamentales: calidad, compromiso, cercanía, conocimiento y competitividad. Se ofrece al cliente la infraestructura tecnológica necesaria para desarrollar sus aplicaciones, así como un equipo experto especializado en nuevas tecnologías. 15

16 I.I Los principios de Vector También se recogen la misión, la visión y los valores de la Compañía, siempre orientados a ofrecer soluciones y servicios globales basada en la innovación y el conocimiento tecnológico. Con un claro compromiso con la sociedad y el medioambiente. Por eso, la visión de Vector es consolidarse como empresa española referente mundial, generando un valor añadido a sus clientes, y entendiendo la importancia de gestionar el talento y cuidado del medio ambiente. I.II Misión Trabajar con entusiasmo en optimizar la aplicación de la tecnología al negocio de nuestros clientes, a través de la motivación y la especialización de nuestros profesionales, para ayudar al desarrollo sostenible del entorno social y económico donde se trabaja. La misión se alcanza: Proporcionando servicios y soluciones basadas en la Calidad, competitividad, cercanía, conocimiento y compromiso. Inspirando nuevos avances tecnológicos, vía especialización y sobretodo, la innovación. Creando valor y marcando la diferencia para nuestros clientes y empleados. 16

17 I.III Valores Representan la esencia y el libro de ruta de las acciones y comportamiento de Vector, y son: Liderazgo: Esforzarse en superarse día a día, dar lo mejor de nosotros. Trabajo en equipo: Potenciar el talento colectivo, multidisciplinar y multicultural. Fomentar la integración, la cohesión y la generosidad Integridad: Ser transparentes y generando sentimientos de absoluta confianza. Orientación al cliente: El cliente como parte esencial y colaborativa desde el inicio hasta el final de los proyectos Calidad: Búsqueda de la excelencia a través de la metodología implantada, ejecutando con la mayor eficiencia los procesos para ofrecer los mejores servicios y productos. Solidaridad: Estamos en un mundo global, queriendo tener un rol activo, participativo y constructivo: el crecer implica esfuerzo, se participa activamente en la sociedad con la Fundación Vector. Responsabilidad medioambiental: Las generaciones futuras tienen derecho a disfrutar de un planeta lleno de salud y vida sin contaminación. Por eso Vector apuesta por el cuidado del medio ambiente, mediante soluciones y proyectos sostenibles. 17

18 I.IV Visión Ser referente en el sector IT y avanzar hacia la excelencia operativa para ofrecer las soluciones más eficientes y rentables a nuestros clientes mediante: Personas y talento: Ser un buen lugar donde trabajar, donde las personas tengan ilusión para crecer día a día Estoy convencido de que la ilusión ayuda al éxito y ésta es la clave para ayudar a nuestros clientes a comprender que la inversión en tecnología es segura y asequible, que apostar por Vector es igual a un retorno medible de la inversión, en costes y tiempo. Carlos Delgado. Productos y servicios: Ofrecer una variada cartera de productos y servicios de calidad que se anticipen y satisfagan los deseos y necesidades de los clientes. Innovación continua: Nuestra meta es la innovación continua. Se aplica la creatividad y conocimiento tecnológico para desarrollar ideas y/o tecnologías diferenciales e innovadoras, que mejoren los procesos de negocios haciéndolos más eficientes y rentables Aceptar el compromiso de cumplir con los requisitos legales, los especificados por el cliente y otros que la organización suscriba en materia de Calidad y Medio Ambiente. 18

19 Dinamismo: Ser una organización eficaz y dinámica para maximizar el valor para los clientes y retorno de nuestros accionistas. Invertir en tecnología hace a las empresas más eficientes y rentables. Carlos Delgado Suarez Consejero Delegado ( 30 de enero del 2014) 19

20 II. ANTECEDENTES Dado que VECTOR SOFTWARE MÉXICO S DE RL DE CV, en principio es una compañía 100% de capital español, que ofrece servicios profesionales en todos los ámbitos relacionados con las tecnologías de la información con el fin de ayudar a sus clientes a alcanzar sus objetivos empresariales a través de la aplicación al negocio de dichas tecnologías, ahora está expandiéndose a sectores del continente Americano, en caso particular y que nos concierne, se implanta ahora en México. Es por ello que tiene una infinidad de nuevas posibilidades para generar empleo y llevar a cabo proyectos que se asignen por parte del sector bancario, por tal motivo el Grupo Santander ha solicitado a VECTOR SOFTWARE MÉXICO S DE RL DE CV y a su Gerente Eduardo González Joyanes, que realicen el proyecto INFISE, el cual en principio, generará tarjetas de crédito para sus clientes, en otras palabras, se ha de desarrollar todo el sistema virtual, código y el software funcional necesario para que el proyecto trabaje de la manera prevista. Todo mediante la herramienta BankSphere, propiedad de Isban y que desarrolla aplicaciones bancarias. 20

21 Usando la herramienta corporativa BankSphere, se generará el proyecto INFISE, para realizar el Origen de las Tarjetas de Crédito y la Front Page, como ya se ha mencionado anteriormente, no obstante cabe mencionar que se tendrán beneficios significativos para Grupo Santander y sus afiliados. Las ventajas del apartado, Origen de Tarjetas de Crédito, son la búsqueda de clientes usando la Lógica de Negocio de BankSphere mediante una Transacción de Operación (TRX) la cual efectuará el tratamiento de algunos datos de entrada usados para buscar a un cliente en específico, devolver como salida la información detallada y solicitada por Grupo Santander y así puedan darle el uso que ellos deseen. Los beneficios de la segunda parte del proyecto, la Front Page, son la unificación a largo plazo del diseño visual del banco Santander a nivel mundial, que resulte más atractiva a la vista para los clientes del banco y posea óptimo desempeño para su instalación y uso en el host de Santander. Sin dejar de lado que será más sencillo el mantenimiento de la Front Page en cualquier sector del mundo donde se encuentre el banco Santander, dicho de otra forma se estandarizará el formato. 21

22 La manera de hacerlo es que los programas basados en 390 hechos por el lenguaje COBOL, se migren en un formato visual atractivo mediante BankSphere, es decir, diferente de los colores monocromáticos y además sean interactivos para los usuarios finales. Las razones de usar la herramienta antes mencionada y no otros entornos de desarrollo de Software son la seguridad informática del código realizando versiones de producto y almacenándolo en un servidor de Isban, la calidad bajo la que se terminan los proyectos ya que es propiedad de Isban e IBM, al ser un entorno de desarrollo pensado a manera de módulos posibilita detectar y remover errores a temprano comienzo y por último está por encima de otros ambientes de Software sólo por el hecho de ser una innovación tecnológica de las TI y que mediante el uso de diagramas de estado resulta fácil identificar y manipular el ciclo de funcionamiento que tendrá el aplicativo. También se define dicho proyecto en razón del recurso humano, pues al abrir sus oficinas ahora en México, Vector requiere de personal capacitado para realizar los proyectos que se asignen, motivo por el cual que se han elegido a los primeros 30 empleados para arrancar con VECTOR SOFTWARE MÉXICO S DE RL DE CV. 22

23 El proyecto no sólo posee cualidades benéficas en relación a la plataforma de desarrollo, también se tienen ventajas en el proceso del proyecto, desde su concepción hasta la entrega final o puesta en marcha. Vector está certificado en los estándares de calidad con más prestigio en el mercado, ISO9001, ISO 20000, CMMI-DEV Nivel 3 e ISO

24 III. JUSTIFICACIÓN El proyecto INFISE, para originar las tarjetas de crédito y hacer la Front Page en relación a su desarrollo de Software, tiene innovación tecnológica en las Tecnologías de la Información debido a la plataforma a usar, ya que el sistema nunca antes se ha utilizado en México y además es propiedad de Isban y está ambientado sobre las plataformas de Eclipse, WebSphere y WAS que es propiedad de IBM, lo cual garantiza calidad en el desarrollo del sistema y seguridad en la información. Cabe destacar que en ambas partes del proyecto, la de Origen de Tarjetas de Crédito y la Front Page, se tendrá en cuenta que no se podrán dar muchos detalles del mismo por cuestiones de confidencialidad con la empresa Vector y el grupo financiero Santander. 24

25 IV. OBJETIVOS IV.I Objetivo General Implementar un sistema de búsqueda de clientes de Grupo Santander de manera estructurada y precisa, de forma que el dato en concreto que se requiera sea el que se arroje como resultado de la búsqueda y no genere más información que la estrictamente necesaria y solicitada, por ejemplo si se desea saber el nombre del mayor inversionista Español que resida y lógicamente invierta en México, logrando una eficiencia de búsqueda para el banco y un rendimiento que de ser afectado el sistema pueda darse soporte y mantenimiento inmediato y efectivo. Desarrollar la Front Page para el cliente final de Grupo Santander, para que cada usuario pueda hacer uso efectivo de su propia cuenta haciendo uso de una vista atractiva y altamente intuitiva con un esquema navegable y fluido, con lo cual no se generarán retrasos de tiempo de espera elevados y se obtendrán a largo plazo ganancias para el banco en el sentido de valor agregado de producto, por la parte comercial y de mercadotecnia atraerá a más personas a firmarse en Santander y se espera un ahorro considerable a largo plazo para el banco, debido a la unificación de colores, esquemas y diseños de sistemas y pantallas que desarrolle Vector para él, se llevará a cabo un mantenimiento posventa que presente un gasto mínimo para Santander. 25

26 IV.II Objetivos Específicos Origen de Tarjetas de Crédito Trabajar con BankSphere, la herramienta corporativa del Grupo Santander para realizar la búsqueda de clientes en el origen de las tarjetas de crédito, para este objetivo se ha de desarrollar e implementar la LN. Desarrollar dentro de la LN los componentes de negocio, Adaptador de Aplicaciones (AAL), Componente SQL, Componente Java y la Operación Interna (OI). Manipular y trabajar los datos que se han solicitado ofreciendo como resultado información concreta, precisa y filtrada para el usuario que lo ha pedido. Entregar al Team Leader el módulo específico que se designó a cada programador, probado, funcional y aprobado por los lineamientos de QA Técnico y QA Funcional y un reporte de lo realizado. 26

27 Front Page Realizar y generar código Java, J2EE y JavaScript para que al final se traduzcan en una aplicación visual para el cliente. Terminar a cabalidad los módulos de diseño de la Front Page usando las guías de estilo generadas por calidad. Migrar la estructura de 390 programada en COBOL a una interfaz con diseño atractivo y estandarizado, y navegación intuitiva para el usuario, programada en BankSphere. Implantar la Front Page en formato Web, es decir, que el usuario ingrese a ella por medio de Internet, y pueda generar y administrar su propia información si así lo decide. La información modificable no es información susceptible para el banco ni altera las cuentas bancarias. Entregar al Team Leader el módulo específico que se designó a cada programador, probado, funcional y aprobado por los lineamientos de QA Técnico y QA Funcional y un reporte de lo realizado. 27

28 V. ALCANCE El proyecto en el que se trabajará, es en la implantación de INFISE y el primer trabajo será en el proyecto de Origen de Tarjetas de Crédito y el segundo trabajo es la Front Page. El mismo que se llevará a cabo en el término de 4 meses, que comprende desde el mes de enero hasta el mes de abril del año El alcance del proyecto, en principio será la de crear la lógica de negocio de esa aplicación encapsulando las llamadas al host de Santander en operaciones de negocio BankSphere, y tras este trabajo la creación de la parte Front Page (páginas Web). Solo se realizan pruebas unitarias y previas a las certificadas, mismas que las realizan Produban, Isban y Mercury. Se realizan las pruebas unitarias dentro de VECTOR SOFTWARE MÉXICO S DE RL DE CV., para comprobar su correcta funcionalidad y al final del proyecto se harán pruebas de laboratorio dentro de VECTOR SOFTWARE MÉXICO S DE RL DE CV., para que así, por parte de la compañía, también se hayan probado antes de salir al mercado, y se hace esto a pesar de que los departamentos pertinentes de calidad, previamente mencionados, hagan las pruebas certificadas. 28

29 Aunque en la compañía VECTOR SOFTWARE MÉXICO S DE RL DE CV se implantó en el país México hace solamente 6 meses, es decir, en el mes de Septiembre de 2013 y que actualmente laboran 30 empleados, sólo 10 de ellos colaboraremos en conjunto para el Origen de Tarjetas de Crédito, con el apoyo oportuno de nuestro Gerente Eduardo González Joyanes y de dos Team Leader de proyecto el Ing. Raúl De Rojas Alonso y la Ing. Guadalupe Magaña Casas. Cada individuo hará una pieza del desarrollo que se le ha asignado y al final se juntarán las piezas para tener un todo. Es la misma filosofía de trabajo que se tiene con la plataforma BankSphere propiedad de Isban. En concreto se trabajará en el módulo de desarrollo desde el inicio de la LN que se encarga del tratamiento de datos y que da como resultado una salida en específico. También se crearán los componentes de negocio, Adaptador de Aplicaciones (AAL), Componente SQL, Componente Java y la Operación Interna (OI), todo esto en un lapso de 26 días. Se diseñará la Front Page navegable para el usuario final en un tiempo de 26 días, mismos que para la LN, implicando la generación de las Páginas Mira (JSP), con sus componentes visuales y funcionales BHTC los cuales ayudan a la navegación visual entre una página y otra. 29

30 La Front Page se realizará con la guía de estilo facilitada por calidad y por ende terminará estandarizada tal y como se espera. Entre otras actividades que se realizarán durante el transcurso temporal de 4 meses del proyecto, y son actividades paralelas a las nombradas anteriormente, en otras palabras, son actividades que se harán al mismo tiempo que las otras y son las siguientes: Remover inmediatamente los errores detectados mediante las pruebas unitarias dentro de Vector. Identificar las urgencias y la criticidad del cambio dentro del proyecto. Analizar los cambios que implican en el sistema, en los requerimientos ya existentes, los beneficios y riesgos. Estimar el esfuerzo, los costes y tiempos requeridos. Desarrollar e integrar el código con todas las garantías: control de versiones, integración continua, control de calidad y test unitarios. Entregar el módulo finalizado al Team Leader junto con un reporte pertinente acerca del módulo. Generar trazabilidad en el proyecto mediante el uso de la metodología de Vector. Eso significa que siempre se sabe qué ha fallado, cuándo, dónde y por qué, y por tanto es posible medir el impacto real de los cambios y errores en el proyecto. 30

31 VI. ANÁLISIS DE RIESGOS Es la manera en que se estructura la Gestión de Riesgos dentro del Proyecto INFISE. Los elementos y herramientas que han de ser aplicadas al proyecto, se plasman en la siguiente tabla descriptiva (Tabla 1): Plan de Gestión de Riesgos. Herramienta/Técnica Uso de Cuestionarios Análisis de Escenarios Esquema RBS o EDT Análisis FODA Lluvia de ideas Selección y Omisión de Riesgos Tabla de Evaluación de Riesgos Tabla FMEA Matriz de Respuesta al Riesgo Aplicable X X X X X X X X X Tabla 1. Plan de Gestión de Riesgos. 31

32 VI.I Uso de Cuestionarios Los requerimientos técnicos son estables? Los miembros del equipo y los involucrados del proyecto están al tanto de todo lo que se lleva a cabo? Los miembros del equipo de trabajo cuentan con las habilidades requeridas? La economía del país se encuentra dentro del rango aceptable? Los costos del equipo y objetos para la implementación del proyecto son estables? Se tiene una buena relación con el cliente? El plazo de finalización del proyecto es acorde en función a los entregables estipulados? El presupuesto es el necesario? El proyecto resulta factible? Se cuenta con plan de calidad? Se cuenta con una metodología de trabajo establecida y definida? Se reconoce cuál es la jerarquía dentro del equipo de trabajo? Existe una buena relación con los miembros del equipo de trabajo, con los proveedores y con el cliente? Existe una comunicación e incentivos eficientes dentro del equipo de trabajo? 32

33 Se cuenta con el uso de buenas prácticas? Se tiene al alcance algún registro histórico del proyecto o proyectos afines? Se cuenta con un plan de integración y motivación grupal? VI.II Análisis de escenarios 1) El peor de los casos es que el proyecto se cancele. 2) El presupuesto no sea el indicado. 3) El salario y/o apoyo económico a los empleados esté por debajo del salario mínimo del país. 4) El plazo que se otorga para la liberación del proyecto se acorte o prolongue. 5) El cliente desconfíe de la empresa. 6) Se presente un aumento del IVA. 7) Exista un cambio de administración o haya nuevas elecciones presidenciales. 8) Una auditoría resulte negativa. 9) Una evaluación de calidad sea negativa. 10) No se cuenten con estándares, procesos de calidad y buenas prácticas dentro de la empresa y del desarrollo del proyecto. 11) El equipo pueda trabajar mal. 33

34 12) Todos o la mayoría de los stakeholders enfermen o accidenten. 13) Que se requiera de la contratación de terceros para el proyecto. 14) El riesgo más grande se materialice y detenga o retrase el proyecto. 15) La ruta crítica no se cuide como es debido y ocasione problemas al proyecto. 16) Los directivos de área no cuenten con las habilidades requeridas y/o necesiten de capacitación. 17) Alta dirección no conozca el objetivo o dirija por mal camino a la empresa y al proyecto mismo. 18) No exista una comunicación eficiente dentro de la empresa y el proyecto. 19) No haya o se carezca de documentación. 20) La mayoría o todo el recurso material no se encuentre en existencia o deba ser solicitado al extranjero. 21) La mayoría o todo el recurso humano sea ineficiente. 22) Lograr que el cliente esté satisfecho con los servicios informáticos que VECTOR SOFTWARE MÉXICO S DE RL DE CV ofrece. 23) La seguridad informática debe resultar eficaz. 24) La transferencia de la intranet debe ser eficiente. 25) El contrato no cambiará. 26) Servicios adicionales no estipulados en el contrato se cobrarán por separado. 34

35 27) Auditoría Positiva. 28) Clima favorable. 29) Se cuente con una infraestructura resistente a catástrofes naturales. 30) Las licencias de Software para el trabajo deben ser legales. 31) La red VPN de comunicaciones de las oficinas internacionales debe estar en óptimas condiciones para un desempeño eficaz. 32) Las instalaciones de trabajo deben ser amplias y contar con sistema de clima interno, seguridad de ingreso, CCTV y sistemas contra incendios. 35

36 Proyecto de INFISE VI.III Esquema RBS o EDT Organizacional Clara Jerarquización Priorizaciones Externo Clima Subcontrataciones Proveedores Administrativo Presupuesto Planeación Técnico Requerimientos Tecnología Recurso Humano Comunicación Hábil Capacitaciones Recurso Material Existencia Eficiente Calidad Esquema 1. RBS / EDT. 36

37 VI.IV Análisis FODA Positivos Negativos Fortalezas: Origen Interno Comunicación eficiente Normas y estándares de calidad Metodologías de trabajo eficientes Capacitaciones Software legal e innovador Sistemas de seguridad Debilidades: Comunicación VPN inestable Tiempo Espacio físico de trabajo limitado Oportunidades: Origen Externo Contrato estable Buena comunicación con el cliente Servicios extras cobros adicionales Innovación tecnológica Empresa de renombre Susceptible a certificaciones Amenazas: Clima adverso Incremento del IVA Elecciones Presidenciales Cambios administrativos Tabla 2. Análisis FODA. 37

38 VI.V Lluvia de ideas La seguridad informática es un punto delicado. El cliente debe estar satisfecho con la optimización de los servicios de VECTOR SOFTWARE MÉXICO S DE RL DE CV. La transferencia de la intranet debe ser eficiente. El cableado estructurado debe estar bajo normas y estándares de calidad. El Software y plataforma de desarrollo debe estar licenciado. La compañía cuenta con capacitaciones de ser necesarias. El Gerente y el Team Leader poseen los conocimientos requeridos para el manejo de la plataforma y la adecuada resolución de problemas. 38

39 VI.VI Selección y omisión de riesgos Tabla de selección y omisión de riesgos Positivo Riesgo o Evento Negativo Seleccionado Omitido Proyecto cancelado Presupuesto errado X X Salario y/o apoyo económico bajo Tiempo de entrega de proyecto corto o aplazado X X El cliente desconfíe de la empresa X Aumento del IVA X Cambio de administración y elecciones presidenciales X Auditoría negativa Evaluación de calidad negativa X X No contar con estándares de calidad X Equipo de trabajo no funcional Stakeholders enfermen o accidenten X X Contratación de terceros X Riesgo más grande materializado X Ruta crítica descuidada X 39

40 Directivos sin conocimientos Alta dirección no conozca el proyecto en totalidad X X Comunicación nula dentro del proyecto X Carencia de documentación X Recurso material inexistente Recurso humano ineficiente X X Cliente satisfecho con la compañía X Buena seguridad informática Intranet eficiente X X El contrato no cambia Servicios adicionales se cobran por separado Auditoría positiva Clima favorable Infraestructura resistente a desastres naturales X X X X X Licencias de Software y plataforma legales X Red VPN de comunicaciones estable Instalaciones seguras y óptimo espacio de trabajo X X Tabla 3. Selección de Riesgos. 40

41 VI.VII Tabla de Evaluación de Riesgos Muy bajo Bajo Moderado Elevado Muy elevado Evento de Riesgo Probabilidad Impacto Dificultad de Detección Momento Salario y/o apoyo económico bajo Inicio Tiempo de entrega de proyecto corto o aplazado Desarrollo Aumento del IVA Inicio Auditoria negativa Desarrollo Evaluación de calidad negativa Desarrollo Equipo de trabajo no funcional Desarrollo Stakeholders enfermen o accidenten Desarrollo Riesgo más grande materializado Desarrollo Comunicación nula dentro del proyecto Desarrollo Recurso material inexistente Adquisición de Recursos Materiales 41

42 Recurso humano ineficiente Adquisición de Personal Cliente satisfecho con la compañía Fin El contrato no cambia Inicio Servicios adicionales se cobran por separado Desarrollo Auditoría positiva Desarrollo Clima favorable Desarrollo Infraestructura resistente a desastres naturales Inicio Red VPN de comunicaciones estable Instalaciones seguras y óptimo espacio de trabajo Inicio Inicio Tabla 4. Evaluación de Riesgos. 42

43 VI.VIII Tabla FMEA (Failure Mode and Effects Analysis) Impacto X Probabilidad X Detección = Valor del riesgo NOTA: 1 = Valor de riesgo bajo ; 125 = Valor de riesgo alto Muy bajo Bajo Moderado Elevado Muy elevado Evento de Riesgo Probabilidad Impacto Dificultad de Detección Valor del riesgo Salario y/o apoyo económico bajo Tiempo de entrega de proyecto corto o aplazado Aumento del IVA Auditoria negativa Evaluación de calidad negativa Equipo de trabajo no funcional Stakeholders enfermen o accidenten Riesgo más grande materializado Comunicación nula dentro del proyecto

44 Recurso material inexistente Recurso humano ineficiente Cliente satisfecho con la compañía El contrato no cambia Servicios adicionales se cobran por separado Auditoría positiva Clima favorable Infraestructura resistente a desastres naturales Red VPN de comunicaciones estable Instalaciones seguras y óptimo espacio de trabajo Tabla 5. Matriz FMEA. 44

45 VI.IX Matriz de Respuesta al Riesgo Se detalla el plan de contingencia para cada riesgo identificado: Evento de Riesgo Respuesta Plan de Contingencia Desencadenante Quién es el Responsable Salario y/o apoyo económico bajo Aceptar Tomar el dinero necesario de caja o contingencia, o rehacer contratos Economía actual del país y necesidades de la compañía Administrador, Gerente Tiempo de entrega de proyecto corto o aplazado Reducir Trabajar tiempo extra y fines de semana Enfermedad, clima adverso o retraso en proveedores. Empleados, Proveedores Aumento del IVA Aceptar Ajustar gastos y comprar más económico Deuda externa crezca Externo Auditoria negativa Reducir Cambiar forma de trabajo interno No se tengas procesos con calidad Alta dirección Evaluación de calidad negativa Distribuir Modificar la manera de trabajar No se cuenten con metodologías de trabajo Alta dirección, Gerente Equipo de trabajo no funcional Reducir Realizar juntas para unir al equipo No exista buena relación interna Líderes de equipo, Empleados Stakeholders enfermen o accidenten Distribuir Rolar actividades y otorgar seguros Mal cuidado por parte de los involucrados en cuanto a su Empleados, Externo 45

46 persona Riesgo más grande materializado Reducir Tomar más tiempo y atención en la ruta crítica No se tenga en cuenta la ruta crítica del proyecto Líderes de Equipo, Gerente Comunicación nula dentro del proyecto Reducir Actividades interpersonales externas con empleados Mala relación intrapersonal de los empleados Empleados Recurso material inexistente Reducir Buscar hasta 2 proveedores adicionales El atraso tecnológico del país Administrador Recurso humano ineficiente Reducir Ofrecer capacitaciones pertinentes o contrataciones Dificultad del sistema y/o ignorancia por parte del empleado Recursos humanos Cliente satisfecho con la compañía Aceptar Seguir laborando de la misma manera Un buen trabajo entregado Compañía El contrato no cambia Aceptar Seguir comunicándose de igual forma con el cliente Buena comunicación con el cliente compañía Alta dirección Servicios adicionales se cobran por separado Aceptar Rehacer el contrato con nuevas especificaciones Cliente con nuevos requerimientos y/o mala comunicación con el cliente Externo, Alta dirección Auditoría positiva Aceptar Continuar trabajando de la misma manera Buenas prácticas dentro de la compañía Externo, Compañía 46

47 Clima favorable Reducir Continuar trabajando eficazmente Contaminación global Externo Infraestructura resistente a desastres naturales Reducir Reubicar al personal al edificio del Tecnológico de Monterrey Contaminación global Externo Red VPN de comunicaciones estable Reducir Localizar mediante al Administrador de comunicaciones de Madrid, España Mala infraestructura y diseño de comunicaciones Administrador de comunicaciones Instalaciones seguras y óptimo espacio de trabajo Distribuir Reubicar al personal a un piso distinto del edificio Invex Sobrecontratación de personal Alta dirección, Gerente Tabla 6. Respuesta al Riesgo. 47

48 VII. FUNDAMENTACIÓN TEÓRICA Primeramente es necesario saber qué es Vector y qué es Santander, conocer hacia dónde se dirigen y por qué motivo existen dichas organizaciones, ya que son las dos empresas involucradas directamente con éste proyecto. VII.I Vector Vector como ya se ha mencionado antes, es una factoría de desarrollo de Software la cual realiza Software a medida de forma integral y que pueda ayudar a las empresas al mejor rendimiento y optimización de su producción. Vector nace con el fin de ayudar a todos los negocios que posean o requieran ayuda de las tecnologías de la información, entonces de esta forma Vector nace con la finalidad y tiene la visión de ser una empresa española de tecnologías de la información de referencia de calidad y nivel mundial. En resumen Vector es un outsourcing que implementa desarrollos y aplicativos de Software a clientes de diversas envergaduras con su consejero delegado Carlos Delgado Suárez, dicho esto, una de las grandes corporaciones a las cuales Vector les desarrolla aplicativos es el grupo financiero Santander. ( 25 de febrero del 2014) 48

49 VII.II Santander La historia del Grupo Financiero Santander tiene su origen más remoto en la creación del Banco de Londres, México y Sudamérica en el año de El 22 de septiembre de 1932 nace el Banco Mexicano. En 1941 surge la Sociedad Mexicana de Crédito Industrial, la que toma acciones de Banco Mexicano en Para 1958 se fusionan Banco Mexicano y el Banco Español, nacido para atender las necesidades de una amplia generación de empresarios españoles en México. Antes de ser Banco Español, tenía como nombre Banco Fiduciario. En 1970 el Banco de Londres y México se sumó a la Compañía General de Aceptaciones para que de la operación surgiera Banca Serfín y en 1992 se crea el Grupo Financiero Serfin luego de la compra que realizara Operadora de Bolsa de Banca Serfin. Transcurre el tiempo hasta que en 1979 se conforma Banco Mexicano Somex ya en calidad de banca múltiple que tuvo en su seno a 114 empresas industriales. Para el 11 de marzo de 1992 Banco Mexicano Somex es vendido al Grupo Inverméxico como parte del proceso de privatización bancaria, adquiriendo el nombre de Banco Mexicano. Un objetivo de Santander México es 49

50 la sustentabilidad, la cual es un eje central en torno al cual realizan todas las actividades que Santander tiene a su cargo. Es la 6ª mayor entidad financiera del mundo y 1ª de España y de la Zona Euro, también es la empresa más grande de España y la 29ª a nivel mundial cuya marca se estima en millones de dólares y con una capitalización bursátil de acciones de millones de dólares. Además posee millones de euros entre depósitos y pagarés. Cuenta con sucursales, 187 mil empleados, 102 millones de clientes y 3,3 millones de accionistas en todo el mundo. Su sede operativa, donde trabajan más de empleados, está en Boadilla del Monte, Madrid, en la ciudad financiera del Santander y su presidente es Emilio Botín. ( 25 de febrero del 2014) VII.III Produban Una compañía que toma la misma importancia dentro del proyecto INFISE, es Produban, en razón de ser un sector de alguna manera de calidad, debido a que revisan el rendimiento y el peso de las páginas que se desarrollen de los proyectos y éste no es la excepción. 50

51 Produban es una empresa tecnológica del Grupo Santander, especializada en el diseño y operación continua de Infraestructuras IT, ofreciendo un servicio integral a sus clientes en las siguientes áreas: Diseño y operación de centro de datos y su interconexión. Diseño y operación de infraestructura TI como servicio. Diseño y operación de plataforma TI como servicio. Procesos de gestión y monitorización. Gestión del riesgo tecnológico y continuidad de negocio. Gestión de puestos de usuario, movilidad y autoservicio. ( 25 de febrero del 2014) VII.IV Isban Ahora es turno de hablar sobre Isban, la cual es directamente responsable de la creación de la herramienta BankSphere, misma que se abordará más adelante. Ingeniería de Software Bancario (ISBAN) es la Compañía Global española especializada en el desarrollo y la implantación de Software Bancario, en este caso para Grupo Santander. 51

52 Isban desarrolla el software y proporciona los servicios de integración de sistemas, comunes a las distintas empresas del Grupo. Sus productos estrella son: Partenón es la plataforma de sistemas transaccionales integrados que permite conseguir una reducción sostenida de los costes de operación y mejorar la información de la relación que cada cliente tiene con el banco. BankSphere (abreviado como BKS), es un entorno gráfico de desarrollo bancario que establece una metodología para el desarrollo de aplicaciones bancarias. ( 25 de febrero del 2014) ( 25 de febrero del 2014) VII.V BankSphere, BKS BankSphere es un entorno de desarrollo de aplicaciones del Grupo Santander. Se trata de su plataforma principal en el caso de aplicaciones web. Las primeras versiones datan aproximadamente del año Incluye entre sus módulos una plataforma de desarrollo basada en Eclipse que pretende agilizar la puesta en producción de nuevo software bancario personalizado sin necesidad de bajar a nivel de código empleando interfaces visuales durante casi todo el proceso de construcción del sistema. 52

53 Una herramienta CASE que permite al Banco Santander evitar el uso de código para personalizar webs para las entidades que crea o compra. Consiste en un conjunto de herramientas usadas para dar soporte a la metodología de desarrollo e-business del Santander. Inicialmente basada en WAS, RAD y Windows Server, después se han usado dependencias tales como Eclipse, GlassFish y Linux. Está formado por cuatro módulos principales: Vega, Vega Modeler, Mira y Mira Lógico. VII.VI Vega Vega y su sincronizador con Rational Rose, permiten desarrollar el modelo físico a partir del fichero de exportación XML, que contiene el modelo lógico creado en Rational. Además, el sincronizador de Mira Lógico con Vega permite trasladar al modelo físico las páginas del prototipo de la aplicación diseñadas con la herramienta Mira Lógico. VII.VII Rational Rose En esta herramienta se diseña el modelo lógico de la aplicación, que debe generar un fichero de exportación XML que puede ser interpretado por el sincronizador de Vega para elaborar un primer acercamiento al modelo físico final. 53

54 VII.VIII Vega Modeler Usada para la fase de construcción, permite programar de forma gráfica la aplicación mediante el uso de diagramas de estado. Los estados son responsables de presentar páginas al usuario, de conectar con diversos sistemas, etc. Como se comentaba la construcción es gráfica, sin embargo en ciertos casos se programa directamente en Java o JavaScript. La metodología especifica los casos en que la programación directa en un lenguaje está permitida. VII.IX Mira Mira permite finalizar la construcción del prototipo creado en Mira Lógico, y que ha servido de base para el desarrollo del modelo físico en Vega. Los estados página, definidos en Vega, que se han sincronizado con las páginas del prototipo creado en Mira Lógico, da lugar a las páginas de.mira. VII.X Mira Lógico El ciclo de desarrollo de una aplicación e-business comienza con el diseño de un prototipo, utilizando la herramienta Mira Lógico con las especificaciones del cliente. La aplicación que se va a diseñar consta de dos páginas web. La primera debe mandar información al servidor mientras que la segunda debe recibirla. 54

55 Actualmente hay desplegadas más de 160 aplicaciones desarrolladas con Banksphere en los distintos bancos del Grupo Santander. La mayoría son aplicaciones usadas en oficinas y en las intranets del Grupo. Actualmente toda la arquitectura de call centers también está desarrollada en esta plataforma. ( 25 de febrero del 2014) VII.XI Ciclo de vida del Software en Vector Adicionalmente Vector posee su propio ciclo de vida el cual es muy bien detallado y se puede apreciar mejor en el siguiente esquema (Esquema 2): Esquema 2. Ciclo de vida de Software revisado tomado de Curso_Introduccion a BKS.pptx. 55

56 Tomando en cuenta el esquema anterior se comenzará a explicar en más detalle todo el proceso de desarrollo del proyecto INFISE. Primeramente se tomará en cuenta que Vector está certificado por múltiples estándares de calidad que han sido mencionados con anterioridad. Análisis Bien, como primera medida se inicia con la etapa de Análisis, la cual corresponde a generar un DDR (Documento de Definición de Requerimientos) el cual plasman las necesidades sin uso de lenguaje técnico que tiene el Grupo Santander para encomendarnos la tarea de realizar el proyecto INFISE, enseguida se hace el DDS (Documento de Definición de Software) el cual si contiene el lenguaje técnico, es decir, traducir el lenguaje común del DDR en lenguaje de programación. 56

57 Diseño Después se debe generar la Micro Arquitectura que sólo poseen los datos estrictamente necesarios para que el programa funcione y trabaje de la manera esperada. Los datos y la información extra tales como el funcionamiento interno del aplicativo, incluso las soluciones técnicas que se le encuentren al programa debido a posibles contratiempos de diseño, no se incluirán en la Micro Arquitectura. Este elemento se representa en un formato de Excel propiedad de Microsoft el cual indica cada dato corporativo a usar y para qué sirve dentro del proyecto. Acto seguido se lleva a cabo la fase de Diseño, la cual tiene el diseño de un LowFi, que no es otra cosa que el diseño preliminar no funcional ni navegable de la Front Page que nuestro cliente ha solicitado. Se muestra con una imagen plasmada en Power Point propiedad de Microsoft. Si resulta aceptable se procede inmediatamente a realizar el diseño de un HiFi que en este punto es un diseño más tangible, es navegable con datos falsos sencillamente para mostrar al cliente y para que el programador conozca qué hará y qué debe hacer el programa. 57

58 Luego se tiene el sector de Construcción que contiene el Modelo Lógico (ML) el cual tiene formalmente todos los datos primarios de la Micro Arquitectura y los datos de soluciones técnicas que se encontraron al realizar el programa, datos de entrada y de salida y la navegación. Se implementa mediante BankSphere en la vista de diseño Mira Constructor, el cual sirve para generar lo anterior en forma visual y textual. Construcción Al término de la fase de ML se procede con la sección de Modelo Físico (MF), misma que lleva el código funcional de la LN dentro de los Proyectos de Lógica de Negocio; la LN que sería el Controlador en MVC, tiene cuatro elementos de negocio, Adaptador de Aplicaciones (AAL), Componente SQL, Componente Java y la Operación Interna (OI). En cada uno se tiene código específico que hace que funcione internamente la aplicación en la forma esperada. Se hace con la vista Vega Modeler que efectúa la realización de los esquemas y diagramas de estados para implementar la aplicación en un nivel meramente funcional. Ahora ya entramos en la etapa de desarrollo de código en su totalidad. En la sección anterior tenemos el código interno funcional del aplicativo y aquí generaremos todo el código restante de todo el proyecto, páginas Mira (JSP s), Operaciones de Presentación (OP), Proyectos de Fachadas (Facade), 58

59 Proyectos de Escenario (ESCE), Proyectos de Ensamblado (ENS) y Proyectos de Bloque. Esta codificación se lleva a cabo en la vista Mira y la vista Vega. Implantación A este punto entramos a la Certificación, la cual toma los módulos de cada programador y dentro de Vector se hacen pruebas unitarias y enseguida si todo está correcto, se hacen pruebas integrales, dicho en términos vulgares, se juntan las partes que cada programador realizó y se monta en una máquina potente para revisar el funcionamiento del proyecto en su totalidad. Luego pasamos a Desplegar el proyecto total al cliente y que él pueda verlo, tocarlo y revisarlo por primera vez y si resulta que es lo que él pidió y lo que esperaba obtener se procede a la etapa final, Preproducción. En Preproducción, se despliega el proyecto final a calidad que otorga el visto bueno y de ser así ellos lo valoran y lo certifican y entonces se pasa a Producción con lo cual tendremos el final del proyecto hecho. Se hace mención de calidad hasta éste nivel, debido a que es la parte de calidad con mayor renombre, sin embargo, en todas las etapas o fases ya dichas existe una evaluación de calidad propia para cada etapa las cuales son efectuadas por QA Técnico y QA Funcional que se aplican simultáneamente. Si es aprobado cada nivel por ambos departamentos de calidad el flujo del 59

60 proyecto continúa sin más, de lo contrario se regresa a la fase reprobada y se rehace el trabajo hasta que exista el visto bueno por parte de calidad. Mantenimiento Por todo lo anteriormente mencionado, y como punto final a mencionar, Vector en su proceso de vida de desarrollos de proyectos debe pasar por varios niveles de inspección y de calidad, entre los cuales se encuentra Isban y Produban. El primero de éstos hace mención a la calidad en cuanto a código se refiere y a los estándares de diseño de las pantallas y aplicativos, que no haya código basura ni salga de las normas de calidad en las cuales Vector se encuentra institucionalizado. El segundo, Produban, revisa entre otras cosas, el peso de las páginas generadas y el peso del aplicativo en secciones y en su totalidad, todo debe encontrarse bajo los lineamientos que establecen los estándares de calidad a los que Vector se encuentra afiliado; que trabaje rápida y eficientemente y que sea ligero y funcional para cualquier computador y sobre todo para el Grupo Santander. 60

61 VII.XII COBOL 390 Qué es? El lenguaje COBOL (acrónimo de Common Business Oriented Language, Lenguaje Común Orientado a Negocios) fue creado en el año 1959 con el objetivo de crear un lenguaje de programación universal que pudiera ser usado en cualquier ordenador, ya que en los años 1960 existían numerosos modelos de ordenadores incompatibles entre sí, y que estuviera orientado principalmente a los negocios, es decir, a la llamada informática de gestión. Pese a que muchas personas creen que el lenguaje COBOL está en desuso, la realidad es que casi todos los sistemas que requieren gran capacidad de procesamiento por lotes (Batch), tanto las entidades bancarias como otras grandes empresas con sistemas mainframes utilizan COBOL. Esto permite garantizar la compatibilidad de los sistemas antiguos con los más modernos, así como tener la seguridad de que el lenguaje es perfectamente estable y probado. 61

62 Según un informe de Gartner Group de 2005, el 75% de los datos generados por negocios son procesados por programas creados en COBOL, y en otro informe de 1997 estima que el 80% de los millones de líneas de código existentes están creados en COBOL, escribiéndose millones de líneas nuevas de COBOL cada año. Con todo eso, hoy por hoy, la programación en COBOL es uno de los negocios más rentables del mundo de la informática. En el resto de aplicaciones el COBOL ha caído en desuso, reemplazado por lenguajes más modernos o versátiles. ( 30 de marzo del 2014) ( 30 de marzo del 2014) El compilador mejora la productividad del desarrollador y el rendimiento de aplicaciones COBOL. El compilador IBM COBOL para OS/390 & VM le permite simplificar las tareas comunes de programación y mejorar el rendimiento de las aplicaciones COBOL. Ofrece soporte de datos decimales de 31 dígitos y mejoras de rendimiento TRUNC (BIN). Las aplicaciones COBOL ya puede utilizar el entorno de informática de redes abierto, lo que convierte a COBOL en una herramienta de desarrollo de aplicaciones más potente. 62

63 COBOL para OS/390 & VM ofrece: La opción de compilador TRUNC(BIN): mejora el rendimiento de las operaciones en datos binarios que requieren truncamiento binario, en lugar de truncamiento COBOL estándar en descripciones de imágenes de base 10. Depuración de producción: admite entornos IBM MVS/TSO, IBM OS/390 UNIX e IBM CICS. Integración de coprocesadores IBM DB2: da soporte a sentencias SQL incorporadas y sentencias nativas COBOL en el programa fuente. OS/390 UNIX System Services: da soporte al desarrollo y la ejecución de aplicaciones en el entorno OS/390 UNIX System Services. Mayor productividad de los desarrolladores de aplicaciones: proporciona un conjunto de funciones intrínsecas y servicios de IBM Language Environment. ( 30 de marzo del 2014) Existen distintas versiones de cobol, pero el "COBOL II" es para trabajar en ambiente IMB/390, EN BATCH. Con este se programa igual que todos, sin embargo la forma de ejecutarse es (normalmente) a través de otro lenguaje de programación: JCL (job control languaje), que agrupa a varios procesos y los lleva a (un software especial) TSO para z/series IBM 390, para que finalmente se procese la información deseada. 63

64 Existe una excepción y es el COBOL CICS, el cual sirve para realizar operaciones en línea y las instrucciones son muy diferentes al resto. Aquí no existen definiciones de select y siguen las diferencias que son bastantes. De todas maneras, estos tipos de cobol (II y Cics) se utilizan normalmente en bancos y algunas empresas (telefónicas) que deben realizar miles y miles de transacciones simultáneamente, porque en definitiva el lenguaje COBOL es lo mejor que existe aún en el mercado. ( &forum=1, 30 de marzo del 2014). 64

65 VIII. PLAN DE ACTIVIDADES Diagrama de Gantt, Tareas para ISB-ESTR-INFISE-ELAB-IMP_REL Número de tarea Nombre de tarea Duración Comienzo Fin 2 Análisis y definición 28 días jue 09/01/14 lun 17/02/14 6 Modelo Lógico 15 días mar 28/01/14 lun 17/02/14 15 Construcción 26 días mar 18/02/14 mar 25/03/14 16 MF INFISE 26 días mar 18/02/14 mar 25/03/14 22 Despliegue 17 días jue 20/03/14 vie 11/04/ Qa Compliance (Certificación técnica) Despliegue a Prepoducción 10 días vie 28/03/14 jue 10/04/14 1 día vie 11/04/14 vie 11/04/14 Tabla 7. Tareas de Plan de Actividades tomado del archivo VSF.ISB-ESTR- INFISE-ELAB-IMP_REL.PL-PLANIFICACION_ Diagrama de Gantt, Tareas para ISB-ESTR-INFISE-ELAB-IMP_REL Tarea Inicio Fin Días ISB-ESTR-INFISE-ELAB-IMP_REL jue 09/01/14 vie 11/04/14 67 Análisis y definición jue 09/01/14 lun 17/02/14 28 Modelo Lógico mar 28/01/14 lun 17/02/14 15 Construcción mar 18/02/14 mar 25/03/14 26 MF INFISE mar 18/02/14 mar 25/03/14 26 Despliegue jue 20/03/14 vie 11/04/14 17 Qa Compliance (Certificación técnica) vie 28/03/14 jue 10/04/14 10 Despliegue a Prepoducción vie 11/04/14 vie 11/04/14 1 Tabla 8. Gráfico de tareas de Gantt. Gráfico 65

66 IX. RECURSOS MATERIALES Y HUMANOS IX.I Recursos Humanos Los recursos humanos contratados para que el proyecto INFISE tuviera éxito han sido 14 miembros principales ampliamente capacitados para ejercer dicha labor, los cuales se nombran a continuación a manera de lista: Alta dirección: Representante de Vector en México, Francisco Javier Álvarez Merino Gerente: Eduardo González Joyanes Team Leader principal: Raúl De Rojas Alonso Team Leader secundario: Guadalupe Magaña Casas 9 Programadores Junior, con conocimientos en TI: o Erick Stephen Flores Oliva o Carlos Alfredo Caballero o Veronica Aidee Gonzalez Zamora o Angel Perez Hernandez o Carolina Garcia Alcantara o Juan Carlos Trejo Gutierrez o Elizabeth Trejo Serrano o Rosario Reyes Valencia o Edson Baruc Fuentes 66

67 Las habilidades y competencias que se requieren tener para laborar dentro de Vector y por ende, para ser capaces de desarrollar el proyecto INFISE, las poseemos cada uno de los programadores Junior antes mencionados y son las siguientes: Comunicación efectiva de manera interpersonal Conocimientos medios de JavaScript Conocimientos intermedios de Java Conocimientos básicos de Bases de Datos Facilidad de adaptación al cambio Apertura a nuevos aprendizajes Responsabilidad Puntualidad Honestidad Respeto Fomentar y generar ambientes de trabajo fraternos Compromiso al trabajo Interés en aprender temas diferentes a nuestra formación profesional Tomas de decisión Generador de soluciones Análisis de problemáticas y uso de lógica Ser extrovertido 67

68 Todos los recursos empleados que han sido mencionados en ésta lista, son meramente las personas directamente involucradas en el proyecto INFISE, el cual se desarrolla en el edificio Roble y Sequoia de Empresalia, cuya dirección es la siguiente: Empresalia Av. 5 de Febrero #1351 (antes campos vitro) Zona Industrial Benito Juárez, C.P Santiago de Querétaro, Qro. 68

69 IX.II Recursos Materiales En la siguiente tabla descriptiva (Tabla 8) se ordenan los recursos materiales utilizados para la ejecución del proyecto INFISE, los cuales fueron necesarios para poder llevar a cabo el buen término del proyecto: Recursos Materiales para INFISE Concepto Cantidad Descripción 12 monitores LCD 17 con cable VGA DELL Intel i5 arquitectura de 64 bits Computadoras de Escritorio: monitores, CPU s, mouse, teclado y cables de alimentación. 12 CPU s 8 MB en RAM 1 TB en HDD 3.10 GHz de procesador 7 puertos USB mouse Logitech Óptico 12 teclados Logitech 69

70 24 cables de alimentación Capacidad de conducir y soportar 110 Volts Escritorios 6 escritorios rectangulares Madera de Pino Multi-enchufes 4 multi-enchufes Blancos de 6 entradas con supresor de picos Oficinas acondicionadas: aire acondicionado, control de iluminación, sistemas de CCTV y control de incendios 2 oficinas: 1 en Roble y 1 en Sequoia Alrededor de 120 cuadrados internos por oficina Memorias USB Vector 12 memorias Amarillas con 4 GB de almacenamiento Internet Línea VPN dedicada Internet proporcionado por Iusacell Suministro eléctrico - Proporcionada por la CEA y distribuida por la CFE Sistema Operativo Licenciado 12 licencias Microsoft Windows 7 70

71 Ultimate BankSphere (BKS) 24 plataformas 12 plataformas de 32 bits y 12 plataformas de 64 bits Gestor de base de datos: SQuirreL SQL, DB2, DB Visualizer, DBeaver 48 gestores 4 gestores diferentes montados en las 12 computadoras Eclipse Helios Sr2 12 plugins Plugins y librerías de Eclipse Helios para usar código Java Oracle VM Virtual Box 12 licencias Virtual Box para realizar pruebas. VMWare Horizon View Client 12 licencias Virtual Box para realizar pruebas. VMWare Sphere Client 12 licencias Virtual Box para realizar pruebas. IBM Rational Application Developer 12 licencias Aplicativo para desarrollo corporativo. 71

72 Application Developer licencias Aplicativo para desarrollo corporativo. IPMsg 12 distribuciones Herramienta de comunicación interna. Tabla 9. Recursos Materiales para INFISE. 72

73 X. DESARROLLO DEL PROYECTO X.I INFISE: Front Page y Origen de Tarjetas de Crédito INFISE: solicitud de creación y desarrollo El desarrollo del proyecto INFISE, ha sido completado por parte de la factoría de Software Vector, ubicada en Empreslia, edificio Roble en la oficina 302. El cual ha sido posible gracias al Líder de Proyectos Raúl De Rojas Alonso y Guadalupe Magaña Casas y que ambos supervisaron el desempeño de nosotros, 10 programadores Junior. Entrando en materia propiamente del servicio solicitado, se tiene por encomienda la creación de INFISE por parte del régimen de impuestos religiosos en Alemania. Primeramente debemos centrarnos en los elementos directamente implicados para que este proyecto naciera y fuera puesto en marcha. Existe dentro de Grupo Bancario Santander una jerarquía organizacional y rangos que claramente determinan la posición y el estatus de los altos directivos. Es aquí donde comienza el nacimiento del servicio, en otras palabras surge la necesidad de crear un Software para dar solución a un problema, en nuestro caso es INFISE: Origen de Tarjetas de Crédito y la Front Page. 73

74 Entonces se tiene dentro de la jerarquía de Santander a la mesa directiva, la cual analiza las necesidades que sus clientes tengan e incluso sus propias necesidades dentro de la compañía (aplicativos de Back Office). En el caso de que sus clientes tengan una necesidad de algún servicio específico, las personas dentro de Santander encargadas de representar a los clientes externos, son los que envían la solicitud hacia Isban y hacia Vector. En el caso contrario que Santander necesite tener un aplicativo propio de Back Office (BO), se le solicita directamente a Isban y a Vector y así se puede omitir un paso adicional que implica el trato con un cliente y la representación del mismo. Para INFISE en particular es una aplicación BO. Ahora entramos en la explicación de la función que Isban tiene dentro de la petición de servicio de un cliente a Santander. Una vez la mesa directiva ha decidido que necesita una solución de Software para su problema y qué tipo de solución es, pasan a la etapa de planificación con Isban y analizan lo que tienen y lo que ocupan para satisfacer la necesidad. Deciden por cual vertiente encaminarse y si la mejor opción para el desarrollo de la aplicación es hacer uso de BankSphere, se asigna el proyecto a Vector, entonces Isban y algún representante de Santander entablan reuniones con Vector para asignar el servicio. 74

75 X.II INFISE: ciclo de Vida de Software en Vector Como información preliminar, es necesario conocer el nivel jerárquico que tiene Vector dentro de su instalación matriz, con la finalidad de comenzar a hablar sobre el desarrollo del proyecto INFISE y saber desde dónde parte todo y se puede apreciar en el siguiente organigrama (Esquema 3): Esquema 3. Organigrama de Vector tomado de 75

76 Esquema 4. Organigrama por departamentos de Vector tomado de Nosotros como programadores Junior encajamos en el departamento de Centro de Competencia Desarrollo, dirigido por el señor Rafael Conde y a su vez nos encontramos dentro del sector Dirección Internacional, encabezado por el señor Javier Álvarez, tal y como se ve en el esquema anterior (Esquema 4). 76

77 Es turno de entrar al ciclo de vida de Software en forma. Vector construye un PDP (Plan De Proyecto) que implica el uso de alguna herramienta para la planificación de las etapas del ciclo de vida del Software, comúnmente se lleva a cabo en Microsoft Project 2010, ya elaborado se ejecuta la sección de Construcción. En dicha etapa se tiene un DDR, el cual tiene plasmado lo que se pretende obtener como producto final descrito en términos cotidianos y un uso casi nulo de terminología técnica. Pasando de este análisis previo, se conoce si el aplicativo contemplará o no el uso de objetos visuales tales como los.jsp o mejor dicho en términos de BKS, objetos MIRA, en cuyo caso se genera un LowFi. Además se genera un DDS y una micro arquitectura, mismos que nos ayudarán para reconocer el proyecto haciendo uso de un lenguaje más técnico. En el DDS se traduce lo que existe en el DDR a un lenguaje más apropiado para que nuestra área de construcción y codificación, sea capaz de interpretarlo correctamente y consiga ejecutar la aplicación con calidad y en la forma que nos es solicitada. 77

78 En la micro arquitectura se contemplan los datos y las funcionalidades que son estrictamente necesarios para que el Software trabaje correctamente, es decir, si durante la construcción del mismo se encuentran ciertas soluciones técnicas no contempladas en la micro arquitectura para solventar un problema, éstas soluciones no se detallan en la micro arquitectura. Por otra parte el LowFi, es una presentación visual y plana en Microsoft Power Point 2010 de los colores y el diseño de las páginas MIRA y se registran citas textuales sobre cómo funcionan los botones de la navegabilidad entre los elementos visuales. Acto seguido se elabora el HiFi que son maquetas navegables ejecutables en cualquier navegador de Internet y se procede a mostrar tangiblemente la funcionalidad básica del sistema. Terminada la fase anterior ya se comienza con la codificación y estructuración del sistema usando BKS y al final de cada módulo desarrollado se deben realizar pruebas unitarias usando 2 herramientas, la primera de ellas se denomina Lanzadera de Aplicaciones y la segunda es el QAOnline. Ambas herramientas de calidad y de pruebas unitarias son propiedad de Santander y de Isban, por tal motivo no se podrán detallar a profundidad sus respectivas funcionalidades, no obstante se pueden mostrar algunas capturas y mencionar a grandes rasgos sus utilidades. 78

79 La Lanzadera de Aplicaciones, usada comúnmente para probar y comprobar el correcto desempeño de la Lógica de Negocio, llámese Componente SQL o JAVA, llámese OI e incluso Acciones Genéricas Java. De tal forma que sabremos si la LN funciona adecuadamente y la codificación es correcta para QA (todo el departamento de revisión de calidad). Dicha herramienta es una dirección URL que se cuelga de cualquier navegador de Internet. QAOnline es una ruta URL al igual que la Lanzadera, sin embargo su función tiene un cometido mucho más concreto y más robusto. Se comprime en un.zip los objetos visuales MIRA que contienen código JavaScript y en un segundo.zip se incluyen los códigos Java que hayamos generado durante el proceso de desarrollo. Entonces se ingresa a la URL y se cargan ambos elementos, se procede a ejecutar el análisis automático de calidad y se arroja un resultado, independientemente si es una respuesta aprobatoria o de rechazo. Por tanto se puede asumir que si el resultado de la evaluación es exitosa se tiene asegurado en un 100% que pasará la revisión física de QA. Y en el sentido de robustez es referido a que se pueden colgar más de un proyecto por vez, de ese modo cada programador puede evaluar su sección paralelamente y puede revisar un componente visual con su respectivo código interno o más de uno. 79

80 Al final se integra y se despliega el proyecto en su totalidad, se aprueba el proyecto por parte del cliente y de calidad y pasa a ser objeto de propiedad del área de Preproducción. En éste punto puede haber un feedback el cual nos solicitará una corrección de alguna función que no cumpla con los requerimientos del cliente y se procede a realizar todos los pasos anteriormente descritos. En caso contrario que todo resulte positivo, Preproducción lanza el Software a Producción y es liberado para que sea totalmente funcional para el cliente final, sea de BO o no. Ahora ya conociendo éstas etapas y fases de ciclo de vida de Software, se hablará del aplicativo INFISE, mismo que contempla las funciones de Origen de Tarjetas de Crédito y la Front Page. X.III INFISE: requerimientos esenciales del sistema Como requerimiento se tiene que el Sistema debe identificar, manipular, administrar y generar un Tax Unit ID de cada persona que habita en Alemania y además saber la correspondencia de dicha Tax Unit ID. Ahora bien un Tax Unit ID es un identificador único e inequívoco que cada persona posee en Alemania desde que nace hasta que muere, el cual para el caso concreto de éste proyecto, servirá como referencia para determinar la contribución tributaria anual a la Iglesia, en términos económicos. 80

81 Pero, y qué pasa si la persona se casa con otra? En ese sentido ya no se le registra como una persona que paga tributo monetario de forma individual, sino que el Tax Unit ID del hombre y la mujer se unen para formar uno nuevo, con el cual se les reconocerá como una sola entidad y no dos tal y como figura la siguiente imagen (Esquema 5): Esquema 5. Tax Unit ID de comunidades en Alemania registrados en Santander DDS MTBK FIS INTERF SEB - V00R00F000 Mantenimiento de entidades asociadas a interfaz V

82 De manera adicional se tiene que si la persona es física o jurídica, prevalecerá el tipo de cuenta o afiliación que tenga el hombre y así la mujer pasa a ser referenciada con el mismo tipo de cuenta. Tomando lo anterior en consideración, se pensó en las leyes germánicas y se realizó cierta investigación social y legal para determinar la respuesta a la siguiente pregunta, qué pasa con el matrimonio homosexual? Bien en Alemania no está permitido este formato de matrimonio oficialmente ni legalmente. Aunado a esta situación al momento de realizar el cálculo de presentar el impuesto anual a la iglesia, sólo será modificable la fecha y el porcentaje monetario del hombre y el de la mujer se calculará automáticamente. En síntesis y como ya se mencionó previamente el impuesto religioso en Alemania se presenta de forma anual y puede ser de manera individual o por matrimonio, de ahora en más se le llamará comunidad. 82

83 Pues bien, las normas que rigen el país y que por tanto tienen influencia en el proyecto son las siguientes: 1) No se permiten los matrimonios homosexuales 2) El tipo de cuenta que posea el hombre es el tipo de cuenta que prevalecerá en la comunidad 3) Los campos de fecha y porcentaje de impuesto serán modificables solamente en el hombre y esos mismos campos se autogeneraran en el apartado de la mujer Con esto no sólo estamos hablando de un proyecto técnico sino que además nos adentramos en otras cuestiones tales como, sociedad, leyes, administración de impuestos e incluso las jerarquías que existen dentro de las comunidades afectivas. X.IV INFISE: funcionalidades técnicas del sistema A este nivel tocamos más a detalle y concienzudamente la funcionalidad propia y como se llevó a cabo el desarrollo de la aplicación INFISE, impuesto religioso en Alemania. De aquí en adelante se detallan las funcionalidades de manera explícita del sistema, no obstante se conserva el derecho de privacidad bancaria y de framework de BKS propiedad de Vector. 83

84 Se desea el mantenimiento del histórico del porcentaje especial del impuesto religioso, para lo cual se debe facilitar el medio para la creación y modificación del porcentaje especial religioso para matrimonios (comunidades), para el periodo que se determine. Para conocer el histórico de las comunidades y personas se necesitan de los siguientes elementos funcionales: a) El Tax Unit ID es el identificador que se obtiene al haber un matrimonio legalmente registrado b) El Número de Persona, es el identificador único e inequívoco que cada individuo en forma singular tiene asignado X.V Listado y detalle del historial de reparto de impuesto religioso por Tax Unit ID o número de persona Se habilitará la posibilidad de buscar el historial de reparto para diferentes periodos de los miembros que forman un Tax Unit ID. Se partirá de un Tax Unit ID o un número de persona determinado. En el caso de Tax Unit ID, se comprobará que se trata de un matrimonio con solicitudes activas y se mostrará el historial del reparto en los periodos que existan, se recuperaran los datos de las personas, sus religiones y el histórico de reparto del impuesto religioso. Dicho de otra forma el Tax Unit ID aplica sólo para búsqueda de comunidades no de individuos. 84

85 En el caso de iniciar el proceso por Número de Persona, se localizará el identificador que coincida con el Número de Persona introducido, y así desglosar el historial en el que participa el individuo como miembro de un matrimonio. X.VI Alta de un nuevo periodo para el reparto del porcentaje especial del impuesto religioso Se habilitará la posibilidad para los miembros de un Tax Unit ID la creación de un nuevo periodo activo o sucursal, con repartos en el porcentaje del impuesto religioso variables. Se validarán los posibles solapamientos con periodos ya creados resolviéndose de las siguientes formas: a) Alta sucursal: Si hay solapamiento se cierra el periodo activo con fecha del año en curso y se creará un nuevo periodo con fecha de inicio el año en curso + 1, y fecha fin la que se determine por pantalla. La modificación funcionaría de igual forma. b) En caso de BO, no podrá dar altas. 85

86 X.VII Modificación de un periodo para el reparto del porcentaje especial del impuesto religioso Para un periodo existente y un reparto de impuesto religioso de un Tax Unit ID determinado, se presentará la opción de modificar esos repartos y las fechas desde y hasta. En cuanto a las validaciones y opciones de modificación de las fechas se dará los siguientes casos: a) En caso de sucursal: si se produce solapamiento se informará al usuario de esta situación y cancelará de forma automática por el sistema el periodo existente y se creará un nuevo periodo. En caso de un periodo cerrado no se podrá modificar. b) En caso de BO: si se produce solapamiento con un periodo existente no se permite la modificación. Se informará al usuario de esta situación y de la necesidad de terminar el periodo existente antes de hacer esta modificación. En caso de un periodo ya cerrado, se permitirá únicamente cambiar los porcentajes de reparto. 86

87 X.VIII Búsqueda del histórico de impuestos religiosos por Tax Unit ID Para un Tax Unit ID se localizan las personas incluidas en el, sus solicitudes de impuesto religioso y los datos de % especiales de reparto de impuesto religioso. Para obtener los integrantes del Tax Unit ID y sus solicitudes de impuesto religioso se utilizarán rutinas de Fiscal Producto, situación legal alemana. Para obtener la información histórica del reparto de impuesto religioso se accederá a una entidad externa. X.IX Búsqueda del Número de Persona asociados a una comunidad para el tratamiento de impuesto A partir del código de persona se localizan sus características, a cuántos matrimonios ha estado relacionado y las características del impuesto religioso por cada comunidad a la que la persona se ha visto envuelta. En todas las funciones se trabaja una parte del Origen de Tarjetas de Crédito ya que contempla los porcentajes de impuestos retirados desde la cuenta bancaria de cada persona que vive en Alemania y que se encuentre registrado en el sistema legal. 87

88 Estas son las funciones que deben cumplir de forma óptima el sistema designado. Ya explicado lo anterior es posible estructurar un diagrama (Esquema 6) que represente los detalles de las funcionalidades del sistema y adicionalmente capturas de imágenes detalladas de los datos que deben mostrarse en pantalla: Esquema 6. Funcionalidades de INFISE. 88

89 Habiendo analizado las funcionalidades que solicita el cliente para el sistema completo se procede a abordar la sección o el módulo que se me asignó y se delimitan en la tabla: Tabla 8. Gráfico de tareas de Gantt de la página número 65. X.X Análisis y definición Se recibe el DDS y se analiza a conciencia lo que el cliente ha solicitado, entonces se elabora la micro arquitectura en base al DDS y solamente se plasmarán aquellos datos, variables y funciones que sean las explícitamente necesarias para que la aplicación trabaje en forma. En éste momento se determinan las tareas que cada programador llevará a cabo, en caso particular mi deber es la función de listado con su respectivo detalle de INFISE. Se obtiene el modelo de datos relacional, comúnmente nos otorgan una URL con la cual usaremos llamadas a dependencias externas y usar una base de datos ya existente dentro del banco. X.XI Modelo Lógico: maqueta navegable Siguiendo el ciclo de vida de Software de Vector hemos de elaborar el ML del aplicativo, el cual se desarrolla dentro de BKS usando Vega Modeler y se entrega a calidad. Aprobado en este punto cada individuo genera el ML de su respectiva funcionalidad, yo he elaborado el ML de Listado con su detalle y se entrega a calidad y resulta aprobado. 89

90 El cliente requiere en este nivel un avance de su sistema y es por ello que se facilita una maqueta navegable y que no es funcional a nivel de realizar consultas y ediciones, es únicamente la transición entre las deferentes vistas y que se carga desde un navegador Web. A continuación se declaran las imágenes del prototipo navegable de INFISE y la forma de introducir la URL, en este caso usando IE 9: Esquema 7. Pantalla inicial de INFISE en maqueta navegable. 90

91 Esquema 8. Pantalla de búsqueda INFISE en maqueta navegable. En las capturas anteriores, (Esquema 7 y Esquema 8), notamos que los datos de búsqueda usados como ejemplos se conservan aún después de dar clic a buscar. En forma conjunta observamos que el listado que he diseñado, arroja datos en función del Tax Unit ID o del Número de Persona introducido, y dichos datos son el detalle resumido de cada persona registrada en Alemania. 91

92 Esquema 9. Pantalla Listado y detalle de INFISE en maqueta navegable. 92

93 Esquema 10. Pantalla selección Listado y detalle de INFISE en maqueta navegable. En los esquemas previos, (Esquema 9 y Esquema 10), al seleccionar un registro se mantiene seleccionado con un fondo de color naranja claro y por ende se habilita el botón de edición, cuando anteriormente se encontraba inhabilitado para el usuario. 93

94 Retomando el tema del color de selección, se nota que todos los colores son establecidos por norma para que se distinga que el aplicativo pertenece a Santander, esto se puede apreciar en el Scroll Bar y en los fondos de los contenedores de la tabla y el tamaño y formato de la fuente también se encuentra pre establecido por normas. Esquema 11. Pantalla modificación de INFISE en maqueta navegable. 94

95 Al momento se avanzar a Edit, te llevará al detalle completo de la persona empotrado en la sección de Modificar, funcionalidad ajena a mi tarea y la misma se aprecia en el esquema anterior (Esquema 11). En esta parte es cuando podemos modificar el porcentaje del impuesto religioso y las fechas de registros anuales. Todo se calcula en automático haciendo uso de codificación Java y JavaScript. Esquema 12. Pantalla aceptación de modificación INFISE en maqueta navegable. 95

96 La pantalla de Alta de usuario o comunidades, es la misma que la de modificar, con la diferencia que todos los campos son editables para dar de alta y también tiene su ventana pop-up de confirmación de alta, tal y como se ve en la anterior captura (Esquema 12). Si se selecciona el botón de guardado, nos abrirá como pop-up una ventana de confirmación con la cual estamos convencidos de almacenar la modificación o bien daremos clic a cancelar para regresar a modificar en caso que no estemos seguros de la acción. Esquema 13. Pantalla Listado y detalle inicial de INFISE en maqueta navegable. 96

97 Si se da clic a Ok, te regresará a la pantalla inicial de búsqueda para realizar más búsquedas o una nueva búsqueda con el mismo Tax Unit ID o Número de Persona (Esquema 13). Como se puede apreciar en cada una las capturas anteriores, la URL se designa dependiendo del lugar donde se haya almacenado la maqueta navegable y la foto captura a continuación lo demuestra (Esquema 14): Esquema 14. URL de maqueta navegable INFISE. X.XII Construcción / MF INFISE Después de 28 días de diseñado, que comprendieron del día jueves 09/01/14 al día lunes 17/02/14, hemos de continuar al proceso de desarrollo o construcción del sistema, en mi caso a la elaboración del Listado y detalle. Como dato adicional las páginas.jsp o MIRA ya se entregan por parte de los jefes de proyectos Raúl De Rojas Alonso y Guadalupe Magaña Casas. 97

98 Primeramente se requiere conocer la manera de atacar el problema en cuestión. Se tiene el patrón de diseño MVC en la programación tradicional, en BKS se sigue el patrón Multi y Multi-Específico, en términos de estructuración sigue la misma corriente que el MVC, mismo que ya se explicó en el apartado de Fundamentación Teórica en la página 39 de ésta memoria técnica. En la siguiente imagen (Esquema 15) observamos el panorama general de cómo atacar el problema de listado y detalle usando el BKS Platform: Escenario Aplicación Operación Esquema 15. Tratamiento de servicios en BKS tomado de Curso_Introduccion a BKS.pptx.. 98

99 Como se ve es la operación con la que se inicia el tratamiento del problema o función (Operación) en cuestión y representa a toda la Lógica de Negocio (LN). En las siguientes transparencias veremos cómo se interactúa dentro de la LN las diferentes secciones del Controlador, siguiendo la línea de trabajo del patrón MVC. Pero esto no dice mucho así que procedemos a explicar cómo trabaja toda la LN en su totalidad y sus funciones dentro del Controlador y también cómo funciona la plataforma de BankSphere a modo gráfico (Esquema 16): ESCE ENS BLOQUE Esquema 16. Interacción BKS tomado de Curso_Introduccion a BKS.pptx. 99

100 BankSphere es un sistema que programa por capas o niveles todas sus aplicaciones, se tiene la LP, Fachada, LN, Bloque, el ESCE y el ENS, que trabaja siguiendo el formato MVC (Esquema 17). En el caso del esquema anterior (Esquema 19) la LP, ESCE y el ENS abarca la Vista, la Fachada sería el Modelo y la LN y el Bloque sería el Controlador. LP Facade AAL OI Esquema 17. Trabajo interno BKS tomado de Curso_Introduccion a BKS.pptx. 100

101 Se entiende en terminología BKS que se inicia con la Lógica de Presentación (LP) o la Vista en MVC, que entra a llamar a la Fachada (Facade) y ésta a su vez llama a un Adaptador de Aplicaciones (AAL) y éste elemento controla las llamadas a las diferentes OI s (Operaciones Internas) del Negocio, tal y como se aprecia en la siguiente figura (Esquema 18): OI AAL OI Esquema 18. Trabajo interno AAL tomado de Curso_Introduccion a BKS.pptx. 101

102 Aquí se explica cómo el AAL puede entrar y llamar a una OI o bien salir y evocar a otra OI que se encuentre dentro de la misma aplicación. Pero y qué pasa si se quiere llamar a una OI que pertenezca a otra aplicación? El AAL llama a otra Fachada y esa Fachada a otro AAL diferente y a otra OI (Esquema 19): OI Facade AAL OI Esquema 19. Trabajo interno BKS tomado de Curso_Introduccion a BKS.pptx. Para resumir, podemos concebir con un sencillo ejemplo cómo trabaja a grandes rasgos BKS. Usaremos el ejemplo de un edificio y sus características. Imaginemos un edifico que se encuentra en la vialidad, pasan personas por fuera y todo mundo puede verlo, a esto le llamamos la LP, una persona se acerca al edificio y desde fuera hay un telefonillo o intercomunicador. Llama al telefonillo y solicita saber qué hay dentro de la habitación más alta del edificio, se le denominará la Fachada. 102

103 Dentro, la llamada la recibe otra persona que servirá como el AAL y se dirige al elevador interno y busca dentro de la planta superior la habitación que el usuario inicial, LP, ha solicitado. El AAL encuentra la habitación en cuestión y llama a la puerta, se abre y dentro esta una tercer persona, la llamaremos OI, ésta persona le dará la respuesta a la solicitud que hizo desde fuera la LP y el AAL se encargará de tomar la respuesta, regresar a la planta inferior y decirle por el comunicador a la LP la respuesta. La LP toma su respuesta y puede dirigirse a otro edificio o Fachada y realizar exactamente la misma acción. Así es como trabaja BKS a grandes rasgos. X.XIII INFISE: Origen de Tarjetas de Crédito Luego de observar las imágenes previas y analizar el ejemplo, se puede explicar mejor el tratamiento de la funcionalidad Listado y detalle. Se inicia desde crear el elemento más esencial y que no necesita de otras para trabajar, en BKS se llama Interfaz de Fachada (IF) en la misma se crean los métodos necesarios y que ya vienen definidos en la micro arquitectura. 103

104 Mientras se elaboraba la Fachada del Origen de Tarjetas de Crédito, necesitaba otros recursos técnicos diferentes a los que venían registrados en la Micro arquitectura, por tanto requería tener métodos nuevos que hacían funciones internas dentro de las funciones generales para obtener el listado y presentarlo con su detalle en formato de paginación. A estas necesidades se les conocen como Recursos Técnicos, y de ser sumamente esenciales se debe informar al jefe de equipo de este hecho y justificarse. En mi caso particular necesitaba un método adicional que contendría datos internos para paginar el resultado de la búsqueda y presentarlo con agrupaciones de 10 en 10 registros. Necesitaba dos datos solamente y aun así debía justificarlo a mis jefes de proyecto y ellos a su vez lo justificaban ante calidad. Acto seguido se generan las Operaciones Internas (OI s) y el Adaptador de Aplicaciones (AAL) junto con los componentes de negocio Componentes SQL dónde encontramos las sentencias SQL tales como select o insert, y Componentes JAVA y acciones Java, es acá donde se ejecuta todo el código Java. Todo lo mencionado se le llama, elaborar la Lógica de Negocio (LN). 104

105 De la misma forma que la anterior debía tener ciertos recursos técnicos al momento de ejecutar mi código Java y mis queries SQL, ya que para paginar necesitaba almacenar en variables genéricas los dos datos que adicioné con anterioridad en la fachada, y las variables que utilicé son de uso sumamente especial por calidad, ya que estas variables almacenan cualquier tipo de dato que le asignes y no es necesario que especifiques el tipo de dato sea string o integer, consume lo que sea. Enseguida se debe probar de forma unitaria la LN de Listado y detalle, se prueba con la Lanzadera de Aplicaciones misma que viene definida desde el banco y sólo se debe colocar el nombre de la funcionalidad que estamos trabajando, por ejemplo: INFSE_ESCE. Y la URL es la siguiente: En las siguientes capturas de pantalla (Esquema 20 y Esquema 21) observamos la pantalla inicial de la Lanzadera y por efectos de privacidad no se puede mostrar el contenido más allá de la aplicación: Esquema 20. Lanzadera de Aplicaciones Vector/BKS. 105

106 Esquema 21. Pantalla inicial de Lanzadera de Aplicaciones Vector/BKS. La funcionalidad de la Lanzadera es para realizar pruebas unitarias de toda la LN que desarrollamos, solo se evalúa si la parte de Negocio funciona o no. Acá se ve reflejado como advertencia del uso del recurso técnico que usé para el código Java, no obstante pasó la evaluación. Como vemos el Origen de Tarjetas de Crédito sigue presente como una parte aplicable en la función de Listado y detalle, ya que conocemos a las personas que se encuentran afiliadas al sistema legal y financiero Santander, y a todas aquellas que tienen una cuenta bancaria y un tipo de pago para impuestos religiosos usando sus propias tarjetas de crédito. 106

107 X.XIV INFISE: Front Page Entonces ya como parte final, sencillamente tenemos que trabajar en la fase de Construcción en relación a los objetos MIRA, que en la programación convencional resultaría en la Vista. Es en este límite donde emplearemos el uso de JavaScript, el cuál hará posible que el usuario pueda visualizar de forma clara y atractiva el aplicativo y pueda interactuar con el sin tocar la LN. Como ya se ha dicho la Front Page no es más que el aplicativo trabajando en forma Web y que por debajo es una funcionalidad de 390. Las páginas MIRA deben representar las mismas casillas y la misma estructura de llenado que el programa desarrollado en COBOL, es decir para el listado se debía ingresar un Tax Unit ID y en otra pantalla el Número de Persona, en cambio en BKS debía tener una sola pantalla que mostrara en una línea la opción de Tax Unit ID o de Número de Persona sin tener que cambiar de pantalla. Como esta función todas las demás debían hacerse igual economizando recursos y haciendo la vista más atractiva y colorida para el usuario además de intuitiva. 107

108 Para este punto de la Front Page no necesite de recursos técnicos así que el proceso de estructuración fue un tanto más sencillo. Para conocer qué estructura y que formas debían tener las páginas MIRA se me facilitó un manual dónde venían capturas de las páginas desarrolladas en COBOL, de ésta forma pude conocer la estructura básica que debía elaborar. Al tener un listado debía insertar dentro de la misma página inicial de búsqueda una tabla que almacenaría los datos ingresados con su respectivo detalle general. Es por ello que la dificultad en interpretación y trasladarlo a lenguaje BKS era ciertamente elevada. Las páginas que realicé pesaban menos de los 40 KB aun cuando estas incluían componentes visuales como las tablas y botones, los colores por norma y demás adiciones como el código JavaScript, así pasó calidad de forma rápida y no tuve mayor complicación en esto. Por privacidad no puedo detallar más cosas de las páginas visuales ni tampoco del código o dar capturas de pantalla. Después de haber codificado y estructurado el Listado y detalle se debe ensayar una prueba unitaria de la Lógica de Presentación (LP) que desarrollé y dicha prueba ya tiene incrustada la aprobación de QA. Al igual que la LN, la LP se monta sobre una URL en algún navegador de preferencia, y se introducen los paquetes que yo como programador, he desarrollado, entonces se da clic a evaluar y el programa te calificará el código y la funcionalidad en sí mismas. 108

109 Te pintará como resultado una señal verde si todo esta correcto y es aprobado, en caso opuesto si resulta en desaprobación por QA, el sistema te arrojará una cruz roja seguida de un informe completo y detallado de los errores que tenga mi código y mis estructuras. La imagen que sigue (Esquema 22) es de la herramienta QAOnline y la URL que muestra dicha herramienta de calidad también se facilita a continuación: Esquema 22. QAOnline Vector/BKS pantalla de informe general. 109