UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN AMBIENTE DE PRUEBAS PARA SOA. Informe de pasantía realizado en: IBM de Venezuela

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

Download "UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN AMBIENTE DE PRUEBAS PARA SOA. Informe de pasantía realizado en: IBM de Venezuela"

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN AMBIENTE DE PRUEBAS PARA SOA Informe de pasantía realizado en: IBM de Venezuela AUTOR: Yelimar del Valle Rebolledo Navas Carnet No TUTOR ACADÉMICO: Profesor Fernando Torre TUTOR INDUSTRIAL: Ing. Fátima Díaz Sartenejas, Febrero de 2008

2

3 RESUMEN RESUMEN Hoy en día, la Arquitectura Orientada a Servicios representa un paso en la evolución de los sistemas modulares. El ciclo de vida de SOA es: modelar, ensamblar, desplegar y gobernar. Cada una de esas fases engloba una serie de actividades. IBM cuenta con una gran cantidad de clientes que han adoptado este tipo de arquitectura, por lo cual, les ofrece las herramientas necesarias para llevar a cabo estos procesos. Este trabajo de pasantía, se enfoca específicamente en el proceso de pruebas realizado durante la fase de despliegue. Para ello, se implementó un ambiente de pruebas para aplicaciones en SOA con IBM Rational Tester for SOA Quality. El demo resultante será de utilidad para posteriores demostraciones y presentaciones de preventa del departamento de Software de IBM. El presente documento describe cada una de las fases de la ejecución del proyecto, basadas en RUP: inicio, elaboración, construcción y transición. Se plantea cómo se llevó a cabo la implementación del ambiente y cómo funcionaría para los clientes a través de diversas pruebas de carga y funcionales a archivos que contenían servicios web. II

4 AGRADECIMIENTOS AGRADECIMIENTOS Primero que nada, quisiera agradecer a mi mamá por su apoyo y palabras de aliento en todo momento. Siempre se mostró optimista, lo cual me contagiaba e impulsaba a seguir adelante. A mi padre y demás familiares que moldearon la persona que soy hoy y por lo cual, he podido llegar aquí. A mis amigos que me apoyaron y me alegraron mi transcurso en la universidad. A mi tutor académico por aceptar el reto de llevar mi tutoría y guiarme en el desarrollo del proyecto. Corrigió de la mejor manera lo plasmado en este informe. A mi tutora industrial por haberme dado la oportunidad de ingresar a IBM y realizar mi proyecto de pasantía. Además de haber estado pendiente del transcurso de ella, haberme integrado al equipo de Software y a la compañía. Al equipo de Software de IBM, el cual me facilitó el proceso de adaptación a la empresa y me ayudó en los momentos de dificultades. Por último pero no menos importante, a Dios por haberme dado fe en cada instante de mi vida e iluminado cuando más lo necesitaba. A TODOS, MUCHAS GRACIAS! III

5 INDICE ÍNDICE Resumen...II Agradecimientos... III Índice... IV Índice de figuras y tablas... VI Lista de simbolos y abreviaturas...vii Capítulo I. Introducción... 1 Capítulo II. Entorno Empresarial Descripción de IBM Misión Visión Valores IBM de Venezuela Estructura Organizativa de IBM de Venezuela Ubicación del pasante en IBM Venezuela... 7 Capítulo III. Planteamiento del Problema Antecedentes El Problema Objetivo General Objetivos Específicos... 9 Capítulo IV. Metodología De Desarrollo Aplicada Visión General del Proceso Descripción de las fases Capítulo V. Marco Teórico Arquitectura Orientada a Servicios (SOA) Pruebas de Software IBM Rational Performance Tester: IBM Rational Tester for SOA Quality: Capítulo VI. Desarrollo del Problema Fase de Inicio Visión del Proyecto Modelo Inicial de Casos de Uso Estudio Preliminar de Riesgos del Sistema Glosario Plan del Proyecto Fase de Elaboración Especificación del WSDL Arquitectura del software Fase de Construcción Introducir datos correctos en las operaciones Ingresar datos en las operaciones erróneos o incongruentes Añadiendo un punto de verificación de igualdad Añadiendo un datapool Con un datapool y un punto de verificación de igualdad IV

6 INDICE 3.6. Exportar los resultados de los schedules correspondientes a los WDSL: BlueBankFrontOffice y Eligibility Análisis General Fase de Transición Capítulo VII. Conclusiones y Recomendaciones Conclusiones Recomendaciones Bibliografía Apéndice I: Documento de Visión Apéndice II: Glosario Apéndice III: Lista de Riesgos Apéndice IV: Especificación de Casos de Uso Apéndice V: Plan de Desarrollo Apéndice VI: Manual de Instalación Apéndice VII: Manual del Usuario Apéndice VIII: Actividades Extras V

7 ÍNDICE DE FIGURAS Y TABLAS ÍNDICE DE FIGURAS Y TABLAS Figura 1: Estructura Organizativa de IBM... 5 Figura 2: Fases y disciplinas de RUP Figura 3: Ciclo de Vida de SOA Figura 4: Modelo de Arquitectura SOA Figura 5: Diagrama de Casos de Uso del Sistema Figura 6: test log del caso Figura 7: Resumen del caso Figura 8: Resultados del tiempo de respuesta del caso Figura 9: Tiempo de Respuesta vs Tiempo del caso Figura 10: Resumen del Tiempo de Respuesta vs Tiempo del caso Figura 11: Desempeño de acción del usuario del caso Figura 12: test log del caso Figura 13: Vista General del test log del caso Figura 14: WSProtocolData Figura 15: Resumen del caso Figura 16: Resultados del tiempo de respuesta del caso Figura 17: Detalles Tiempo de Respuesta vs. Tiempo del caso Figura 18: Resumen Tiempo de Respuesta vs Tiempo del caso Figura 19: Desempeño de acción del usuario del caso Figura 20: Asignación de datos a variables candidatas Figura 21: test log del caso Figura 22: Resumen del caso Figura 23: Resultados del tiempo de respuesta del caso Figura 24: Detalles Tiempo de Respuesta vs. Tiempo del caso Figura 25: Resumen del Tiempo de Respuesta vs. Tiempo del caso Figura 26: Desempeño de Acción del Usuario del caso Figura 27: Resumen del caso Figura 28: Resultados de Tiempo de Respuesta del caso Figura 29: Detalles del tiempo de respuesta vs. Tiempo del caso Figura 30: Resumen Tiempo de Respuesta vs Tiempo del caso Figura 31: Desempeño de Acción del Usuario del caso Tabla 1: Resumen de los Stakeholders Tabla 2: Resumen de los Usuarios Tabla 3: Plan del Proyecto Table 4: Requerimientos de Software y Hardware Table 5: Comparación de resultados entre los WSDL Tabla 6: Resultado promedio entre las corridas VI

8 LISTA DE SÍMBOLOS Y ABREVIATURAS LISTA DE SIMBOLOS Y ABREVIATURAS BPEL CSV ESB HTTP HTTPS IBM JMS JRE PoT QoS RPT RUP SOA SOAP SSA SWG TI UDDI UML URL USB VP WSDL WSE XML Business Process Execution Language Comma-Separated Values Enterprise Service Bus Hypertext Transfer Protocol Hypertext Transfer Protocol over Secure Socket Layer International Business Machines Java Message Service Java Runtime Environment Proof of Tecnology Quality of Service Rational Performance Tester Rational Unified Process Service Oriented Architecture Simple Object Access Protocol Spanish South America Software Group Tecnología de Información Universal Description Discovery and Integration Unified Modeling Language Uniform Resource Locator Universidad Simón Bolívar Verification Point Web Services Description Language Web Services Explorer Extensible Markup Language VII

9 CAPÍTULO I. INTRODUCCIÓN CAPÍTULO I. INTRODUCCIÓN La Arquitectura Orientada a Servicios - SOA - permite construir un sistema informático más ágil y fácilmente adaptable a las necesidades del cliente, reduciendo los tiempos de desarrollo y gracias a la reutilización de componentes existentes. Basándose en la experiencia con casi clientes de SOA, IBM ha aprendido que éstos entienden que SOA es una secuencia de pasos, un ciclo de vida: modelado, ensamblado, despliegue, gestión y gobierno. Un componente crítico en este enfoque es la gerencia de la calidad, para esto se utilizan métodos para probar ambientes de SOA. Las nuevas soluciones de pruebas de IBM Rational automatizan la prueba de los servicios web en la Arquitectura Orientada a Servicios. En este informe se presenta el resultado de un proyecto de planificación, diseño y desarrollo de un ambiente de pruebas, el cual funcionará como demo para promover la herramienta IBM Rational Tester for SOA entre los clientes. Este ambiente, no sólo incluye el software necesario para probar las aplicaciones en SOA, sino que también se elaboró scripts de prueba con diferentes elementos para analizarlos y ejemplificar los beneficios de la herramienta. El contenido del documento se compone de la siguiente manera: Capítulo II Entorno Empresarial: Se describe la empresa a fin de proveer una visión global del ambiente de trabajo. Capítulo III Planteamiento del Problema: Se presentan los antecedentes, el problema y los objetivos generales y específicos que buscan solucionar la situación. Capítulo IV Marco Metodológico: La metodología de desarrollo aplicada es RUP. Se detalla las fases y el producto de cada una de ellas. Capítulo V Marco Teórico: Se explica brevemente los conceptos con lo que se deben estar familiarizados para entender lo que se expone. Además, sirvió de base para la realización del proyecto. 1

10 CAPÍTULO I. INTRODUCCIÓN Capítulo VI Desarrollo del Problema: Se describe lo realizado y resultado de las fases de análisis, elaboración, construcción y transición del proyecto. Capítulo VII Conclusiones y Recomendaciones: Se expone los puntos más importantes deducidos y las observaciones para mejorar futuros trabajos. Para complementar todo lo presentado, se agregó una sección de apéndices, en donde se presenta artefactos generados a lo largo del desarrollo y se explica en mayor detalle ciertos aspectos del proyecto. 2

11 CAPÍTULO II. ENTORNO EMPRESARIAL CAPÍTULO II. ENTORNO EMPRESARIAL 1. Descripción de IBM Fundada en 1911 con el nombre de Computing-Tabulating-Recording Company (C-T-R). En 1924, C-T-R se convirtió en la Internacional Business Machines Corporation (IBM Co.). Entre 1910 y 1970, se dedicó a implementar desde máquinas tabuladoras de tarjetas perforadas, pasando por calculadoras del tamaño de un cuarto, hasta sistemas de computación centralizada para grandes compañías. IBM cambió la naturaleza de la contabilidad, el cálculo y los procesos al interior del trabajo clásico de oficina. En , se amplía la gama de productos IBM, de computadoras centrales a minicomputadores y computadoras personales. Las aplicaciones evolucionan más allá de soluciones para procesos internos de los negocios y se enfocan hacia la operación de departamentos y la productividad del personal. En la década de los noventa, con la aparición de Internet y los estándares abiertos, el modelo de computación en redes es adoptado y evoluciona. El término e-business es creado para describir cómo la computación en redes puede transformar el corazón de las funciones y transacciones de los negocios. Hoy en día, IBM es una de las compañías más grandes del mundo en tecnología de la información y la octava corporación a nivel mundial Misión Nos esforzamos por liderar en la creación, desarrollo y manufactura de las tecnologías más avanzadas de la industria. Por medio de soluciones y servicios a nivel mundial, traducimos estas avanzadas tecnologías en valor agregado para los negocios de nuestros clientes. 3

12 CAPÍTULO II. ENTORNO EMPRESARIAL 1.2. Visión IBM es reconocida por la energía y vitalidad de sus trabajadores, los cuales se encargan de crear oportunidades para sus clientes y así lograr potenciar sus negocios a través de la presencia regional y los conocimientos globales de servicios TI. Su estrategia se basa en On demand business, lo cual implica que las soluciones son de acuerdo a las necesidades del cliente (enfocadas en su negocio) Valores Dedicación al éxito de cada cliente: Los trabajadores de la compañía se apasionan por construir relaciones sólidas y duraderas con los clientes. Esta dedicación los estimula a hacer todavía mucho más por ellos. Innovación con mayor impacto para la compañía y el mundo: Los IBMístas se caracterizan por su pensamiento progresista. Creen en el progreso y en que la aplicación de la inteligencia, la razón y la ciencia puede mejorar los negocios, la sociedad y la condición humana. Confianza y responsabilidad personal en todas nuestras relaciones: Los IBMístas construyen activamente relaciones con todos los integrantes del negocio: clientes, asociados, comunidades, inversores y compañeros de trabajo. Edifican la confianza escuchando, manteniéndose fieles a su palabra y respetándola. 2. IBM de Venezuela Es la mayor compañía de tecnología de información del país. Se estableció hace 68 años y actualmente cuenta con un equipo de más de 400 empleados directos. Opera en toda Venezuela apoyando a la comunidad, la investigación, la comercialización y la industria. Además, posee autonomía financiera y de negocios, así como el soporte internacional de IBM. Forma parte de la región SSA (Spanish South America), la cual está conformada también por Argentina, Bolivia, Chile, Colombia, Ecuador, Paraguay, Perú, Uruguay. Esta región fue creada en enero de 2003 con el objetivo de funcionar como un único país, logrando ser la segunda región en importancia en Latinoamérica. 4

13 CAPÍTULO II. ENTORNO EMPRESARIAL 2.1. Estructura Organizativa de IBM de Venezuela El siguiente diagrama muestra la organización de la empresa desde un punto de vista global (Figura 1): Figura 1 Estructura Organizativa de IBM A continuación, se describe brevemente los componentes del diagrama: Clientes, sus Necesidades de Negocios y La Oferta IBM El cliente tiene una importancia clave en el negocio de la compañía. La estrategia adoptada por IBM, On demand business, integra los procesos de negocio, así como a sus asociados claves, proveedores y clientes, para buscar la solución que corresponde a lo que el cliente necesita. Ventas 5

14 CAPÍTULO II. ENTORNO EMPRESARIAL Este componente se divide en cuatro grandes sectores: Clusters, Small and Medium Business, Canales e IBM.com. Los clusters se refieren a los grandes clientes (esta descripción es confusa, no se entiende qué quieres decir). Small and Medium Business son clientes de menor envergadura que los clusters pero igual de importantes. Los Canales son los medios por los cuales se le puede llegar al cliente. Y por último, IBM.com se refiere al portal en Internet a través del cual se pueden procesar las ventas. IGF 1 IBM Global Financing o IGF se refiere al apoyo financiero que aporta IBM como parte de una estrategia general para la gestión de las Tecnologías de Información, que permite al cliente mantener la actualización tecnológica, reducir costos y minimizar los riesgos, al tiempo que preserva su habilidad para tomar decisiones de equipamiento flexibles a través del ciclo de vida de la tecnología. Brands Las ramas de negocios, brands, de IBM están agrupadas en Hardware, Software y Servicios. Hardware contiene las ventas de sistemas como servidores, de impresión, de almacenamiento; las soluciones para almacenes de cadena (sistemas para puntos de venta, kioscos y dispositivos periféricos) y División de Computadores Personales. Software se divide en: WebSphere, el cual integra aplicaciones e-business a través de múltiples plataformas usando tecnologías Web; Lotus, engloba aplicaciones para oficina y de colaboración; Tivoli, para administrar procesos, infraestructuras y operaciones IT; Data Management (DB2) manejo de base de datos relacionales; Rational, cuyos productos facilitan el desarrollo de softwares utilizando las mejores prácticas. Finalmente, se encuentra la rama de Servicios, la cual se clasifica en: Outsourcing Estratégico, que se refiere a delegar los procesos no esenciales del negocio a 1 Tomado de IBM Global Financing - 6

15 CAPÍTULO II. ENTORNO EMPRESARIAL Business Partners; los Servicios de Consultoría de Negocio, en cuanto a finanzas, recursos humanos, relación con el cliente; y los Servicios Integrados de Tecnología para los clientes. Soporte al Negocio Está compuesto por otros entes para así dar apoyo a los negocios de IBM. Estos componentes son: Comunicaciones, Marketing, Recursos Humanos, Legal, Contratos y Negociaciones, Operaciones y Finanzas Ubicación del pasante en IBM Venezuela El pasante está contratado directamente por la empresa y se encuentra en el departamento de Software, específicamente en Distribución y Ventas IBM bajo la brand de Rational, ubicado en el piso 6 de la torre IBM en la avenida Ernesto Blohm, Chuao, Caracas. 7

16 CAPÍTULO III. PLANTEAMIENTO DEL PROBLEMA CAPÍTULO III. PLANTEAMIENTO DEL PROBLEMA 1. Antecedentes SOA es un estilo de arquitectura que permite la creación y/o cambios de los procesos de negocio desde la perspectiva de TI, a través de la integración en servicios de las tareas repetidas, logrando su uso de forma independiente de las aplicaciones y plataformas a las que pertenecen. Los principales beneficios que se obtienen al adoptar una Arquitectura Orientada a Servicios son: incrementa la productividad, alcanza nuevas oportunidades de negocio, aumenta la flexibilidad y reduce los costos y riesgos. En la última década, este enfoque de arquitectura ha sido implantado en muchas empresas. Por ejemplo, IBM a nivel mundial trabaja aproximadamente con clientes que poseen SOA. En nuestro país, este auge también se ha hecho sentir, por lo tanto, IBM Venezuela no se podía quedar atrás. En la Unidad de Distribución de Ventas y Software, se empezó a concebir la idea de que los clientes pudieran observar cómo las herramientas de IBM apoyan un proceso de negocio a través de un demo. Además de contar con un ambiente, que les permitiera interactuar con los productos y sus propios procesos. De este modo, evaluarían si los softwares ofrecidos cumplen con sus necesidades. A mediados del año 2007, se implementó, como primera fase del proyecto, un proceso de negocio bancario con las herramientas de la brand de WebSphere que soportan aplicaciones en SOA. Para la fase de modelado, se tiene IBM WebSphere Business Modeler, la cual posee como principal función, modelar el servicio: identificarlo, especificarlo y realizarlo. La fase de ensamblado es apoyada por IBM WebSphere Integration Developer, una herramienta que permite diseñar y desarrollar servicios. IBM WebSphere Service Registry and Repository cubre la fase de despliegue, aunque sus características hacen posible que diferentes usuarios puedan usar esta herramienta durante todas las fases del ciclo de SOA. Por último, para la fase de gestión, IBM WebSphere Monitor, el cual cumple con administrar y monitorear el comportamiento del servicio a través del ciclo de vida de SOA. 8

17 CAPÍTULO III. PLANTEAMIENTO DEL PROBLEMA 2. El Problema Un componente crítico en el enfoque SOA es la gerencia de la calidad, para esto se utilizan métodos para probar estos ambientes. Es fundamental para complementar la fase de despliegue, pruebas de desempeño que garanticen el buen funcionamiento de los servicios para que puedan ser aprobados. Las nuevas soluciones de pruebas de IBM Rational automatizan la prueba de los servicios web en la Arquitectura Orientada a Servicios. Sin embargo, estas herramientas no han sido incluidas en la primera fase de las soluciones de IBM para SOA. 3. Objetivo General Diseñar e implementar un ambiente con la herramienta de pruebas para SOA, IBM Rational Tester for SOA Quality. Esta demo quedará como un aporte importante para posteriores demostraciones y presentaciones de preventa del producto. 4. Objetivos Específicos Para cumplir satisfactoriamente el objetivo general, se desglosó en actividades puntuales: Auto-estudio en general de los productos Rational. Auto-estudio específicamente en la disciplina de Pruebas del RUP (Rational Unified Process). Auto-estudio específicamente en la herramienta de pruebas para SOA: IBM Rational Tester for SOA Quality. Auto-estudio específicamente en la herramienta de pruebas: IBM Rational Performance Tester. Diseño del ambiente de pruebas para SOA con la herramienta RT4SOA. Implementación de un proceso de prueba con archivos WSDL en dicho ambiente: grabar script, editarlo con diferentes elementos, correrlo y generar los reportes. Analizar los informes obtenidos, determinar el comportamiento del servicio y los posibles cuellos de botella. 9

18 CAPÍTULO III. PLANTEAMIENTO DEL PROBLEMA Apoyo y/o acompañamiento en pruebas de concepto de soluciones Rational que involucren los productos: El fin de este objetivo es conocer las necesidades de los clientes para probar sus aplicaciones, así como las inquietudes del manejo de la herramienta. Creación del Manual de Instalación de las herramientas necesarias para el ambiente de pruebas. Creación de un Manual de Usuario, que englobe el caso más general para realizar un script de prueba, editarlo, ejecutarlo y obtener los reportes. 10

19 CAPÍTULO IV. METODOLOGÍA DE DESARROLLO APLICADA CAPÍTULO IV. METODOLOGÍA DE DESARROLLO APLICADA La metodología seleccionada para el desarrollo de este proyecto es RUP (Rational Unified Process). Este marco de trabajo fue diseñado por la Corporación Rational Software, la cual es una división de IBM desde el año RUP es un proceso de ingeniería de software que provee lineamientos disciplinados para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de alta calidad de software que cumpla con las necesidades de los usuarios. Rational Unified Process es una guía efectiva para el uso del lenguaje de modelado UML (Unified Model Language), el cual es un Standard en las industrias que permite comunicar requerimientos, arquitecturas y diseños claramente. RUP se apoya en herramientas que automatizan grandes partes del proceso. Son usadas para crear y mantener diversos artefactos en particular, modelos del proceso de ingeniería de software: modelado visual, programación, pruebas, etc. Esta metodología describe seis mejores prácticas para los equipos de desarrollo de software: - Desarrollo iterativo - Manejo de requerimientos - Arquitectura basada en componentes - Modelado visual - Verificación de la calidad - Control de cambios 1 Visión General del Proceso El proceso puede ser descrito en dos dimensiones como se puede apreciar en la figura 2. 11

20 CAPÍTULO IV. METODOLOGÍA DE DESARROLLO APLICADA Figura 2 Fases y disciplinas de RUP El eje horizontal representa el tiempo y muestra los aspectos dinámicos del proceso. Está expresado en ciclos, fases, iteraciones y milestones. Las fases son Inicio, Elaboración, Construcción y Transición. El eje vertical representa los aspectos estáticos del proceso: cómo es descrito en términos de actividades, artefactos, trabajadores y marcos de trabajo. 2 Descripción de las fases RUP divide el proceso de desarrollo en ciclos. Cada ciclo está compuesto por las cuatro fases ya mencionadas. Cada fase tiene un propósito específico. Éstas deben ser concluidas con un milestone o hito bien definido. 12

21 CAPÍTULO IV. METODOLOGÍA DE DESARROLLO APLICADA Fase de Inicio Durante esta fase, se establece el caso de negocio para el sistema y se delimita el alcance del proyecto. Para ello, se debe identificar todas las entidades externas con las que el sistema va a interactuar (actores) y se define la naturaleza de esta interacción a alto nivel. Esto implica determinar los casos de uso y describir los más significantes. En cuanto al caso de negocio, debe incluir el criterio de éxito, evaluación de los riesgos, estimación de los recursos necesarios y un plan de proyecto con las fechas de los milestones a entregar. El hito resultante de esta fase son los objetivos del ciclo de vida. Fase de Elaboración El objetivo de esta fase es analizar el dominio del problema, establecer una arquitectura base sólida y el plan de desarrollo del proyecto, y eliminar los riesgos más críticos. La fase de elaboración es la más crítica de las cuatro. En ella, se debe asegurar que la arquitectura, los requerimientos y los planes son lo suficientemente estables para seguir adelante. De este modo, se puede predecir el costo de finalización del desarrollo y su agenda. Al final de esta fase se encuentra el segundo hito más importante del proyecto: la arquitectura del ciclo de vida. Fase de Construcción Durante esta fase, todos los componentes y las características de la aplicación son desarrollados, integrados y probados. Por ende, se puede decir que la fase de construcción es un proceso de manufactura donde se hace énfasis en la administración de recursos y el control de operaciones para optimizar costos, fechas y calidad. 13

22 CAPÍTULO IV. METODOLOGÍA DE DESARROLLO APLICADA La salida de esta fase es un producto listo para los usuarios, la cual consiste en el software integrado en la plataforma adecuada, el manual de usuario y una descripción de la versión realizada. Generalmente, esta versión se llama beta. El hito correspondiente a esta etapa es Capacidad Operacional. Fase de Transición El propósito de esta fase es traspasar el software desarrollado a la comunidad de usuarios. Una vez que el producto ha sido entregado al usuario, usualmente surgirán elementos que requerirán desarrollar nuevas versiones, corregir algunos problemas o culminar los detalles que fueron pospuestos. Las actividades que implican esta fase: - Entregar las pruebas betas para validar el producto con las expectativas del Cliente. - Ejecución paralela con sistemas antiguos. - Conversión de datos. - Entrenamiento de usuarios. - Distribuir el producto. El hito de esta fase es la liberación del producto. 14

23 CAPÍTULO V. MARCO TEÓRICO CAPÍTULO V. MARCO TEÓRICO 1. Arquitectura Orientada a Servicios (SOA) SOA es un enfoque de arquitectura tecnológica para el diseño de software que está basado en el negocio y que soporta la integración en servicios de aquellas tareas que son repetitivas y están relacionadas, permitiendo así su utilización independientemente de las aplicaciones y plataformas a las que pertenecen, proporcionando funcionalidad para apoyar los procesos horizontales del negocio. Esto permite que los servicios, construidos originalmente de una variedad de sistemas, funcionen e interactúen de manera uniforme, y además cuando los servicios se encuentran de forma individual dentro de las aplicaciones, permite a las empresas integrarlas y agruparlas de maneras diversas a fin de crear capacidades complemente nuevas. Los principales beneficios de aplicar SOA son: - Aumenta la flexibilidad. - Disminuye costos. - Reduce riesgos. - Incrementa los ingresos. - Permite nuevos productos. Hay varios grados de adopción de SOA, entre los cuales están: - Implementación de servicios individuales: en este caso, el negocio experimenta sobre una base limitada para crear nuevas implementaciones de servicios o también para tomar la lógica del negocio existente y adaptar las funciones como servicios dentro de SOA. - Integración de servicio: el negocio se compone de servicios a través de flujos de procesos o máquinas de estado que implementan procesos de negocios complejos. - Transformación de negocio bajo demanda: SOA transforma los procesos de negocio, y el negocio incluye las mejoras del proceso desde el dominio del mundo real al de TI y viceversa. 15

24 CAPÍTULO V. MARCO TEÓRICO Ciclo de vida: La implantación de SOA puede verse como un ciclo de vida en cuatro fases que en forma secuencial, cada una toma los resultados de la anterior hasta desplegarla en un ambiente de servicios integrados que pueden ser administrados tanto desde la perspectiva de las tecnologías de información como de negocios. Las cuatro fases del ciclo de vida SOA son: - Modelado: es el proceso de capturar el diseño del negocio desde el punto de vista de requerimientos y objetivos, para llevarlo a una especificación de negocio y metas creando un modelo codificado. Un modelo sofisticado permite ver los posibles escenarios que reflejan el número de instancias del proceso, contactos, el tráfico entrante, etc. Si no se logran los resultados esperados entonces se puede cambiar la definición del proceso para tratar de mejorar los resultados. Además, el modelo indicará métricas del negocio que son importantes para él. Estos indicadores son la entrada para el ensamblado de la aplicación y servirá de información para saber qué tan bien va el negocio. - Ensamblado: Es el proceso de comunicar el diseño de negocio con la organización TI ensamblar los artefactos del sistema de información que implementarán el diseño de negocio. El arquitecto empresarial junto con el analista de negocio pueden comenzar a convertir el diseño de negocio en un conjunto de definiciones de procesos de negocio y actividades. Durante esta actividad, se deberían buscar los inventarios existentes programas- para encontrar los componentes de aplicación que ya atienden las necesidades. Algunos encajarán perfectamente, mientras que otros deberán ser reelaborados. Estos componentes deben ser llevados a servicios para que puedan ser ensamblados en las aplicaciones compuestas. Es posible que algunos tengan una relación tan estrecha que no puedan ser reusables, en este caso, habría que reescribir estas funciones como nuevos servicios y migrar los procesos que dependen de estos viejos programas. Cualquier otro nuevo servicio requerido por el diseño de negocio deberá ser creado. El ensamblado final incluye aplicar un conjunto de políticas y condiciones para controlar cómo las aplicaciones van a operar en el ambiente de producción. Por ejemplo, pueden ser regulaciones del gobierno o características operacionales críticas como dependencia de recursos, control de integridad, entre otros. - Despliegue: Esta fase incluye una combinación de crear un ambiente de hosting para las aplicaciones. Esto implica resolver las dependencias de recursos, las condiciones 16

25 CAPÍTULO V. MARCO TEÓRICO operacionales, requerimientos de capacidad y restricciones de integridad y acceso. Se debe garantizar disponibilidad, integridad, eficiencia, confiabilidad y capacidad de servicio. - Gestión: Se refiere a mantener el ambiente operacional y las políticas expuestas en la fase de ensamblado. Incluyendo monitoreo de las peticiones de servicios y tiempo exacto de respuesta; mantener registro de problemas para detectar fallas, localizarlas, corregirlas y restaurar el estado operacional del sistema. Además, es necesario gestionar el modelo de negocio para medir el éxito de los objetivos propuestos en el diseño. El flujo del ciclo de vida no es enteramente lineal. Pueden surgir cambios que afecten la ejecución de una fase y deban ser tratados en otra. Software Skills & Support Figura 3 Ciclo de Vida de SOA Modelo de Arquitectura Lógico: La arquitectura lógica está compuesta por seis elementos que agrupan los servicios de acuerdo a su funcionalidad, y están apoyados por un Bus de Servicio Empresarial (ESB) que proporciona la interconectividad y por los elementos que soportan la estructura lógica. Ver figura 4. 17

26 CAPÍTULO V. MARCO TEÓRICO Los elementos de la arquitectura lógica son los siguientes: - Servicios de Interacción: Se trata de la presentación lógica de los componentes de diseño de negocio que soportan la interacción entre aplicaciones y los usuarios finales. - Servicios de Procesos: Incluye varias formas de lógica compositiva, siendo las más notables: flujos de procesos de negocio y máquinas de estado de negocio. Permite organizar y automatizar los procesos del negocio. - Servicios de Información: Contiene los datos del diseño de negocio. En un primer nivel, se encargan de proveer acceso a los datos persistentes del negocio. En otro nivel, los servicios de información tienen su propia sub-arquitectura para administrar el flujo de datos a través de la organización. Esto con la intención de manejar dos requerimientos importantes dentro del espacio de administración de información: composición y flujo de datos. El primero de ellos surge de la necesidad de representar la información de una forma que encaje con los servicios en el diseño de negocio. El segundo requerimiento se refiere al movimiento de información de una parte de la empresa a otra donde se necesite para satisfacer los requerimientos del ciclo de vida y flujo de datos. - Servicios Colaboradores: Capturan la semántica de la interoperabilidad colaboradora que tiene una representación directa en el diseño del negocio, permitiendo la conexión con los asociados de negocios. Por ejemplo, políticas y restricciones que otras empresas deben adaptar para trabajar con este negocio. Esto puede implicar la lógica de negocio de administrar cuáles colaboradores son seleccionados y cuáles tienen prioridad bajo ciertas circunstancias. - Servicios de Aplicación de Negocio: Son el corazón de la lógica de negocio. Estos componentes creados específicamente como servicios dentro del modelo de negocio representan los bloques de construcción básicos del diseño de negocio servicios que no pueden ser descompuestos pero que son útiles para formar los de más alto nivel. - Servicios de Acceso: Están dedicados a integrar aplicaciones y funciones en la arquitectura orientada a servicios. Se toman funciones y se proveen como servicios (en el caso que la función concuerda con los requerimientos semánticos del modelo 18

27 CAPÍTULO V. MARCO TEÓRICO de negocio en el cual será usada), o en casos más complejos, incrementar la lógica de la función para conocer mejor las necesidades del diseño de negocio. Elementos que soportan la arquitectura lógica: - El Bus de Servicio Empresarial (ESB): Es un colaborador silencioso en la arquitectura lógica SOA. Su presencia es transparente a los servicios de la aplicación. Un ESB es fundamental para simplificar la tarea de invocación de servicios, haciendo que el uso de éstos sea independiente de la ubicación y del transporte de las peticiones de servicio a través de la red. Según IBM, un bus de servicio empresarial es un patrón de arquitectura, cuyo principio es permitir la integración y unificación de múltiples instancias de bus de servicio para así reducir el acoplamiento. El modelo del bus sugiere que no hay un punto central de conectividad, sino que existe una fábrica, la cual permite la entrada a toda la red distribuida. Los servicios pueden ser registrados en esa fábrica y ser localizados desde cualquier punto de la red. El bus asume la responsabilidad de asociar los consumidores con los proveedores según la necesidad. - Servicios de Optimización e Innovación de Negocio: Representan las herramientas y estructuras de metadatos para codificar el diseño de negocio, incluyendo las políticas y objetivos. Ayuda a capturar, codificar, analizar y refinar de forma iterativa el diseño del negocio. Además, incluye herramientas que definen los indicadores claves de desempeño. - Servicios de Desarrollo: Contempla la suite entera de herramientas de arquitectura, desarrollo, composición visual, ensamblado, metodologías, debugging, repositorios y mecanismos de publicación necesarios para construir una aplicación basada en SOA. IBM las ha organizado en el framework Eclipse. - Gestión de Servicio IT: Representa el conjunto de herramientas de administración para monitorear los flujos de servicio, utilizar recursos, identificar cuellos de botellas, el logro de los objetivos y reforzar las políticas administrativas. - Servicios de infraestructura: Forman el corazón del ambiente de tecnología de información para hosting de aplicaciones SOA. Es a través de estos servicios que se puede construir un sistema confiable para proveer un eficiente uso de recursos, asegurar la integridad del ambiente operacional, balancear la carga de trabajos, 19

28 CAPÍTULO V. MARCO TEÓRICO realizar mantenimiento, acceso seguro para procesos y datos de negocio confidenciales, y simplificar la administración del sistema. Figura 4 Modelo de Arquitectura SOA 2. Pruebas de Software Es el conjunto de técnicas que permiten determinar la calidad de un producto. El objetivo es encontrar los posibles defectos que presente. Se dice que una prueba tiene éxito si descubre un defecto, y que fracasa si hay defectos pero no los identifica. Existen distintos tipos de pruebas tales como las de caja blanca, caja negra, de carga, de desempeño, de regresión y otras. En este apartado, se explicará las que se consideran pertinentes de acuerdo al proyecto: Pruebas de caja negra: son aquellas que se enfocan directamente en el exterior del módulo, sin importar el código. Son pruebas funcionales en las que se trata de encontrar fallas en las que éste no se atiene a su especificación. Se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. 20

29 CAPÍTULO V. MARCO TEÓRICO Este tipo de pruebas permiten detectar funcionamiento incorrecto o incompleto, problemas de rendimiento, errores de acceso, inicio y terminación. Pruebas de carga: se determina el número de usuarios que se desea intervengan a la vez en un/os camino/s crítico/s (o serie de funcionalidades mas importantes que necesitan mayor atención). Se van simulando incorporaciones graduales de usuarios (carga de 10 en 10 ó 20 en 20) que ejecutan el mismo camino. La herramienta indica la degradación que va sufriendo el sistema (en toda su estructura, servidores físicos, comunicaciones, bases de datos, sistemas operativos, servidores aplicaciones) hasta detectar el punto óptimo, comportamiento en el número de usuarios necesario, a qué nivel se cae el sistema, componentes críticos, etc. Pruebas de desempeño: son aquellas que determinan los tiempos de respuesta, el espacio que ocupa el módulo en disco o en memoria, el flujo de datos que genera a través de un canal de comunicaciones, etc. El entregable correspondiente a esta etapa es el plan de pruebas. Su propósito es especificar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas. La construcción de un buen plan de pruebas es la piedra angular y en consecuencia, el principal factor crítico de éxito para la puesta en práctica de un proceso de pruebas que permita entregar un producto de mayor nivel. 3. IBM Rational Performance Tester: IBM Rational Performance Tester, RPT, es una herramienta de prueba de desempeño y de carga multiusuario para validar la estabilidad de aplicaciones Web. Crea, ejecuta y analiza pruebas para verificar la confiabilidad de complejas aplicaciones e-business incluyendo Seibel, SAP y SOA. RPT ayuda a los equipos a localizar los cuellos de botellas del sistema antes del ensamblado de la aplicación para simplificar la creación, ejecución y análisis de resultados de las pruebas de desempeño multiusuarios. Las pruebas son grabaciones de la actividad de un usuario dentro de un explorador Web. Se puede crear una agrupación de datos para simular los diferentes 21

30 CAPÍTULO V. MARCO TEÓRICO tipos de usuarios en una prueba. Durante la ejecución de ésta, se generan reportes que resaltan los posibles problemas con las páginas webs, URLs y transacciones. Entre los principales se encuentran: De desempeño: Resume la validez de la corrida, los datos más significativos, muestra la tendencia de respuesta de las 10 páginas más lentas en la prueba y grafica el tiempo de respuesta de cada página para un intervalo específico. De elemento de página: Resume los datos de elementos de página más importantes para la ejecución. Las gráficas de este reporte muestran intervalos de tiempo, intentos, éxitos. De percentil: Muestra los tiempos de respuesta de los percentiles 95, 90 y 85 para todos los usuarios y todas las páginas en una corrida, al igual que para las 10 páginas más lentas. De puntos de verificación: Muestra el estatus de estos puntos en las pruebas. Este reporte es desplegado si las pruebas verifican títulos de páginas, el código de retorno para un elemento de página o el tamaño de estos. 4. IBM Rational Tester for SOA Quality: Automatiza la creación, ejecución y análisis de pruebas funcionales y de regresión para aplicaciones con arquitectura orientada a servicios (SOA). IBM Rational Tester for SOA Quality es un plug-in de IBM Rational Performance Tester, por lo tanto, se utilizan las mismas funcionalidades antes descritas. Entre las características más resaltantes se encuentran: Correlación de datos automatizada y pruebas data driven: Esto se refiere a que los scripts leen datos desde una fuente externa de almacenamiento en vez de usar valores fuertemente codificados en el script, lo cual hace que las pruebas sean más simples. Simplifica las pruebas de integración de servicios: Permite la creación de pruebas desde recursos de WebSphere Business Process Execution Language (WBPEL). Los WBPELs son lenguajes de modelado de proceso de negocio que son 22

31 CAPÍTULO V. MARCO TEÓRICO ejecutables, con sólo importarlos al área de trabajo de RPT se puede comenzar a realizar las pruebas sobre los procesos. Soporta una extensa variedad de usuarios: útil para las pruebas de carga. Se puede crear, modificar y ejecutar pruebas funcionales o de desempeño: El editor de pruebas permite vistas tanto de alto nivel como de detalles específicos para estos tipos de prueba. 23

32 CAPÍTULO VI. DESARROLLO DEL PROBLEMA CAPÍTULO VI. DESARROLLO DEL PROBLEMA En este capítulo se describen los aspectos más importantes de cada una de las fases de la metodología seguida (RUP): Inicio, Elaboración, Construcción y Transición. Los entregables obtenidos en cada una de estas etapas se presentan en los apéndices de este documento. 1. Fase de Inicio Durante esta fase, se busca conocer el caso de negocio para el sistema, identificar los actores involucrados, los casos de uso a implementar, evaluar los riesgos, determinar el alcance del proyecto y posteriormente, ofrecer un plan de ejecución. La primera actividad fue el levantamiento de la información acerca de los temas involucrados en el proyecto. Se comenzó por una investigación relacionada con la Arquitectura Orientada a Servicios: qué es, cuáles son sus beneficios, ciclo de vida, modelo de arquitectura y los elementos que lo soportan. Paralelamente, se fue revisando la primera versión del demo elaborado en la unidad para relacionar la parte teórica con la práctica. Luego, se averiguó sobre la herramienta IBM Rational Tester for SOA Quality, determinando sus características y cómo éstas satisfacen la demanda del mercado. Además, se repasó los conceptos de prueba de software y los tipos de pruebas Visión del Proyecto Ya finalizadas de manera satisfactoria las actividades de levantamiento de información, se inició el proceso de identificación de requerimientos funcionales y no funcionales del ambiente de pruebas a realizar para así determinar el alcance del proyecto. Es importante resaltar que todo lo concerniente a esta etapa está detallado en el Apéndice I, Documento de Visión. Entrevistas directas a los stakeholders y a los posibles usuarios de la aplicación, en las cuales pudieron expresar sus inquietudes y necesidades, fueron la base de la identificación de los requerimientos. 24

33 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Resumen de los Stakeholders Nombre Descripción Responsabilidades Gerente de Gerente de Ventas Realiza las asignaciones del equipo Ventas Técnicas Técnicas del Grupo de técnico de Software. del Grupo de Software en Venezuela. Seguimiento del desarrollo del Software en Pertenece al proyecto. Venezuela departamento de Ventas y Distribución Aprueba requisitos y funcionalidades. de Software. Diseñador Pasante en la unidad de Ventas Técnicas del Grupo de Software Especialista TI Especialista TI, específicamente en la brand de Rational. Pertenece al departamento de Ventas y Distribución de Software Resumen de los usuarios Tabla 1: Resumen de los Stakeholders Diseñar un ambiente de pruebas con la herramienta IBM Rational Tester for SOA Quality para aplicaciones en SOA, el cual quedará como un aporte importante para posteriores demostraciones y presentaciones de preventa. Se especializa y mantiene actualizado de los softwares ofrecidos por IBM. Sirve de apoyo técnico a la Unidad de Ventas del SWG. Nombre Descripción Responsabilidades Especialista TI Especialista TI, específicamente en la brand de Rational. Pertenece al departamento de Ventas y Distribución de Software. Se especializa y mantiene actualizado de los softwares ofrecidos por IBM. Sirve de apoyo técnico a la Unidad de Ventas del SWG. Cliente Cualquier entidad que presente aplicaciones en SOA y necesite probarlas. Tabla 2: Resumen de los Usuarios Garantizar la eficiencia, seguridad y confianza de sus aplicaciones. Realizar las pruebas necesarias para asegurar que las aplicaciones cuentan con calidad de servicio (QoS) 25

34 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Dadas las necesidades expuestas y según las características analizadas del producto, se consideró que el aspecto más interesante para mostrar al cliente serán pruebas a archivos WSDL que no posean un cliente, es decir, que no disponen de interfaz gráfica Modelo Inicial de Casos de Uso Durante esta fase, se identificaron los principales casos de uso, los actores y la interacción entre ellos, a través de un diagrama de casos de uso UML Actores Especialista TI: Se encarga de ofrecerle al cliente, los beneficios de la herramienta. Cliente: Persona interesada en probar sus aplicaciones en SOA Casos de uso A continuación, se listarán los casos de uso principales. Para mayor detalle, consultar el apéndice IV, Especificación de Casos de Uso. Crear proyecto de prueba de desempeño. Importar WSDL al área de trabajo. Grabar la interacción con el Web Service. Editar la prueba. Añadir datapool (agrupación de datos) como elemento de prueba. Agregar punto de verificación como elemento de prueba. Ejecutar la prueba Revisar el reporte de la prueba. Crear un plan de prueba de desempeño (schedule). Ejecutar el plan Revisar los reportes generados Exportar los resultados a un archivo CSV. 26

35 CAPÍTULO VI. DESARROLLO DEL PROBLEMA 1.3. Estudio Preliminar de Riesgos del Sistema Se preparó un documento, donde se presenta las diferentes situaciones que pudieran poner en peligro la ejecución del proyecto. Para cada uno de ellos, se describe una tabla con los siguientes aspectos: Magnitud: Será expresado con un número del 1 al 10, donde 10 indica que es el más dañino para la ejecución del proyecto y 1 menos. Descripción: Una breve explicación de qué se trata el riesgo. Impactos: Se lista las consecuencias originadas en el proyecto. Indicador: Describe cómo monitorear y detectar que el riesgo ha ocurrido o está por suceder. Mitigación: Estrategia que debe ser llevada a cabo para minimizar la incidencia del riesgo. Plan de Contingencia: Curso de la acción a seguir en caso de que se materialice el riesgo. Este entregable se encuentra en el apéndice III Glosario Este documento contiene la terminología clave para el entender el dominio del proyecto. Fue creado al comienzo de esta fase, sin embargo, se mantuvo en constante actualización hasta la última ya que era necesario complementar las definiciones ya existentes o simplemente, agregar nuevos conceptos. Se hace referencia al apéndice II Plan del Proyecto Con la información recaudada, se estimó un plan de desarrollo de proyecto, el cual incluye cada una de las fases, el tiempo de dedicación aproximado y las actividades relacionadas. Fase Actividad Duración (Semanas) Inicio Búsqueda de información Cuatro (4) Documento de Visión 27

36 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Elaboración Construcción Transición Identificación Inicial de Casos de Uso Planificación de Riesgos Plan de Desarrollo Inicial Análisis del archivo a probar Actualización de los Casos de Uso Revisión de documentación Investigación de las herramientas y tecnologías a usar Descripción de la arquitectura del software Revisión de documentación Implementación del diseño Plan de pruebas Manual del Usuario Revisión de documentación Recomendaciones Presentación del prototipo Tabla 3: Plan del Proyecto Seis (6) Siete (7) Tres (3) Cabe destacar que durante todo el ciclo, se realizaron actividades administrativas del proyecto correspondientes a la gestión de requerimientos, planificación, seguimiento y control, aseguramiento de la calidad y gestión de configuración. Para mayor detalle, revisar el apéndice V, Plan de Desarrollo de Software. 2. Fase de Elaboración 2.1. Especificación del WSDL Para presentar una arquitectura sólida para el proyecto, es necesario contar con el archivo que se va a probar y así, asegurarse de que el diseño sea realista. El WSDL escogido está orientado a operaciones de banca. Esta decisión fue tomada para seguir la misma línea del demo existente en la unidad para presentar las herramientas de IBM que apoyan los procesos de negocio basados en SOA, el cual está dirigido a la banca. BlueBankFrontOffice.wsdl es el archivo que contiene el servicio que se probó. Basado en una SOA, fue desarrollado en el framework de IBM Rational Application Developer y sigue el 28

37 CAPÍTULO VI. DESARROLLO DEL PROBLEMA protocolo de transporte SOAP (Simple Object Access Protocol) para intercambiar los mensajes basados en XML entre redes de computadoras, normalmente usando http/https. La estructura de un documento WSDL es simplemente un conjunto de definiciones. La especificación viene dada por: Definiciones: Es la raíz de este tipo de archivo. Define el nombre del servicio web, y contiene todos los elementos descritos. Tipos: Describe todos los tipos de datos usados entre el cliente y el servidor. Mensaje: Describe un mensaje de una vía, si es una sola petición de mensaje o una sola respuesta de mensaje. Define el nombre del mensaje y contiene cero o más elementos del mensaje, los cuales pueden referirse para enviar parámetros o valores de retorno. Tipo de Puerto: Combina múltiples elementos de mensaje para formar una operación de una o dos vías. Asociación: Describe las especificaciones de cómo el servicio será implementado sobre la red. Servicio: Define la dirección para invocar el servicio especificado. Las operaciones que contiene este WSDL son: Crear cuenta: Consiste en abrir una nueva cuenta en el banco. Los datos solicitados son: Primer nombre, apellido, dirección de habitación, código postal, ciudad, estado y país. El valor de salida es el identificador de la cuenta que se acaba de crear. Este número es autogenerado por la operación. Depositar: Consigna una cantidad de dinero dada en una cuenta bancaria existente. Para esta operación, es necesario el identificador de la cuenta. Obtener balance: Dado el identificador de la cuenta bancaria, proporciona el dinero que posee el cliente. Obtener detalles de la cuenta: Retorna los datos de una cuenta existente, una vez suministrado el identificador de ella. Retiro: Retira la cantidad de dinero indicada por el cliente de su cuenta. Para ello, debe especificar el identificador de la cuenta. Encontrar cuenta: Dado el apellido del cliente, devuelve el identificador de la cuenta. 29

38 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Como archivo auxiliar, se tiene Eligibility.wsdl, el cual tiene como única operación determinar si la solicitud de crédito de un cliente debe ser aprobada o no Arquitectura del software Consiste en un conjunto de patrones que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información. Esto incluye tanto la organización lógica del sistema como la distribución física en la cual será implantada. Toda arquitectura debe describir ciertos aspectos del producto. Para entender de manera más comprensible estas características, se utilizan vistas. Cada una de ellas constituye una explicación parcial de una misma arquitectura y es deseable que existan cierto solapamiento ente ellas. Una vista es una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva (Kruchten, 1995). Para el diseño de este proyecto, se siguió el modelo de 4+1 vistas propuesto por Phillipe Kruchten. Las cuatro vistas principales son: lógica, procesos, física, despliegue. La otra vista que se muestra y traza en cada una de las anteriores y que está formada por las necesidades funcionales que cubre el sistema es la llamada vista de casos de uso. Cada vista es descrita usando su particular y más adecuada notación, siendo la más usual UML. Sin embargo, cabe destacar que este modelo es genérico, es decir, puede utilizarse cualquier método de diseño para describir las composiciones de las vistas Vista de Casos de Uso Las dos funcionalidades principales de esta vista son: Validar e ilustrar el diseño de la arquitectura en papel. Utilizar los casos de uso como punto de partida de las pruebas de un prototipo arquitectural. 30

39 CAPÍTULO VI. DESARROLLO DEL PROBLEMA A continuación, se presenta una breve descripción de los casos de uso identificados en este sistema: Crear proyecto de prueba de desempeño: Como primer paso, el usuario crea un proyecto indicando el nombre y donde estarán localizadas las carpetas fuentes. Crear prueba desde el Web Services Explorer: Este caso de uso, se realiza a través de un wizard. Aquí se indica el proyecto con el que se desea trabajar, el nombre de la prueba, se importa el WSDL al área de trabajo, el puerto por el que se desea realizar la grabación y se acepta la advertencia de privacidad que implica realizar este tipo de pruebas. Grabar la interacción con el Web Service: Se navegan las operaciones del servicio web, introduciendo los datos de entrada de cada uno de ellos. Esto se realiza gracias a la interfaz que ofrece el Web Services Explorer. Editar la prueba: Ya generado el script de prueba, se pueden reemplazar los valores de prueba grabados con otro tipo de datos o data dinámica. Además de puntos de verificación para comparar con los mensajes de retorno. Añadir datapool (agrupación de datos) como elemento de prueba: Se observan las variables candidatas (las de color verde) y se seleccionan para agregarle más datos. Importar datapool desde un archivo CSV: Una de las formas de consignar una agrupación de datos a una variable, es asignando una columna de datos de un archivo CSV. Agregar punto de verificación como elemento de prueba: La intención de este caso de uso es chequear el comportamiento de la aplicación durante la prueba. Se selecciona la operación, se le hace clic sobre el botón add y se elige el punto de verificación que conviene. Ejecutar la prueba: En la vista del navegador de prueba, se selecciona el script de prueba, botón derecho y hacer clic sobre correr como prueba de desempeño. Revisar el reporte de la prueba: En la vista Corridas de prueba de desempeño, darle clic a la prueba, botón derecho y seleccionar mostrar log de la prueba. Al generarse, se podrá revisar la pestaña General y Eventos. En esta última, se aprueba el veredicto obtenido (error, falla, inconcluso, aprobado). 31

40 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Crear un plan de prueba de desempeño (schedule): De la barra de herramientas, se selecciona el icono correspondiente a nuevo. Aparecerá un wizard con todas las opciones posibles, se elige Plan de prueba de desempeño. Se especifica el nombre y la ubicación. Editar el Schedule: Una vez creado el plan de prueba, se precederá a agregarle elementos como ciclos, usuarios y configurarlos. Agregar grupo: Por defecto, existe un grupo de usuarios. No obstante, se debe configurar las características asociadas como el número, porcentaje que representa. Para añadir otro grupo, se sombrea el nombre del plan, se le da al botón add o al botón derecho del ratón y se escoge la opción grupo. Añadir ciclo: Se elige un grupo de usuarios, se selecciona add y se escoge loop. Se especifican el número de iteraciones y si se desea controlar la tasa de éstas. Adjuntar archivo de prueba: Se selecciona el último elemento de la prueba, se presiona el botón add y se elige el script de la lista que se presenta. Agregar tiempo de espera (delay): Se elige el último elemento de la prueba, se hace clic sobre el botón add y se selecciona delay. Se configura el tiempo en las unidades deseadas. Ejecutar el plan: En la vista del navegador de prueba, se selecciona el archivo del plan de prueba, botón derecho y hacer clic sobre correr como plan de prueba de desempeño. Revisar los reportes generados: Luego de verificar que el estado de la corrida del plan de prueba es completo, se pueden observar los diferentes reportes y analizarlos. Revisar el resumen: Hacer clic sobre la pestaña resumen, donde se podrá observar tablas que ofrecen datos claves sobre las llamadas hechas y la corrida en general. Revisar los resultados del tiempo de respuesta: Presionar la pestaña correspondiente a este reporte, donde se podrá analizar un gráfico y datos sobre las páginas más lentas. Revisar el reporte de detalles de Tiempo de respuesta vs. Tiempo: Hacer clic sobre el respectivo tab, se mostrará un gráfico con el tiempo promedio de todos los retornos a través del tiempo y una tabla resumen. Revisar el reporte resumen del Tiempo de respuesta vs. Tiempo: Presionar la pestaña de este tipo de reporte, se presentará un gráfico y una tabla con el tiempo promedio de respuesta de cada operación. 32

41 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Revisar el reporte de rendimiento de acción de usuario: De igual forma, hacer clic sobre el tab correspondiente y evaluar el gráfico sobre la tasa de llamadas hecha por todos los usuarios virtuales asignados y la tabla sobre los completados y activos. Exportar resultados en un archivo CSV: Habiendo corrido el schedule, se exportarán los datos deseados en un CSV. Para mayor detalle, consultar el apéndice IV, Especificación de Casos de Uso. El siguiente diagrama representa los casos de uso del sistema: Figura 5 Diagrama de Casos de Uso del Sistema Vista Lógica 33

42 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Soporta el análisis y la especificación de los requisitos funcionales. En esta sección, se cubre las partes más importantes del análisis y diseño del sistema. La primera decisión es que el demo a elaborar estará contenido en una máquina virtual, de forma que el especialista TI pueda copiarlo fácilmente y si lo desea, instalarlo en tantas máquinas sea posible. Cabe destacar que esto implica es una simple descarga en las computadoras y no la reinstalación de todas las herramientas más los ejemplos de prueba realizados para el cliente. Esta imagen se encontrará en el mismo servidor en el que se trabajó la primera fase de la solución presentada por el grupo de software para las aplicaciones en SOA y así, seguir los lineamientos de la empresa en este tema. Para demostrar los beneficios de la herramienta, se prepararán archivos de prueba y posteriormente, se analizarán los reportes generados simulando un proceso que puede realizar un cliente de su servicio. Los casos principales a la hora de grabar la prueba serán: Introducir datos correctos en las operaciones: Este es el caso base del plan de pruebas a realizar con el servicio. Ingresar datos en las operaciones erróneos o incongruentes: El objetivo es evaluar la funcionalidad general del sistema, lo cual muchas veces es lo único que se prueba. Además, los reportes que generen este caso servirán de soporte para comparar con los que tengan más variaciones en la prueba. Suministrar información en las operaciones y añadir un punto de verificación de igualdad en getaccountdetails: Observar el comportamiento de la aplicación con este elemento de prueba. Completar la información de las operaciones y añadir un datapool en createaccount: Evaluar la influencia de la agrupación de datos asignada en los reportes generados. Introducir datos en todas las operaciones del servicio (incluso repetidos), añadir un datapool en la operación createaccount con información de todos los campos y un punto de verificación de igualdad en la operación getaccountdetails: La intención de este caso es utilizar los posibles elementos de prueba en un script para saber qué tan sustancioso es en comparación con los anteriores y si se pueden detectar otro tipo de fallas. 34

43 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Los planes de prueba de desempeño para estas pruebas contarán con las siguientes características: Usuarios: Treinta, compartidos en dos grupos con porcentaje de distribución, cincuenta. Ciclos: En el primer grupo, habrá uno sólo con diez iteraciones y la tasa de iteración una por segundo. En el segundo grupo, hay un ciclo dentro de otro; el primero es de diez iteraciones y el segundo, de cinco. Tiempo de Espera (delay): Se agregó en el segundo grupo entre el primero y segundo ciclo por cinco segundos. Estos casos serán implementados en BlueBankFrontOffice.wsdl. Sin embargo, en Elegibility.wsdl se creará un schedule con las características anteriores y en base a una prueba con un datapool y un VP. Con el objetivo de exportar los resultados de los dos planes de prueba bajo esas circunstancias y compararlos, ya que en una arquitectura en SOA habrá más de un servicio y puede ser necesario medirlos en conjunto Vista de Procesos En esta vista, se toma en cuenta aspectos de concurrencia y distribución, integridad del sistema y tolerancia a fallas. Incluyendo, además, la especificación de cuál hilo de ejecución ejecuta cada operación y cómo se comunican entre ellos. Para las pruebas de las operaciones del servicio es necesario pensar en la concurrencia de los usuarios, sin embargo, esto es controlado por la herramienta IBM Rational Performance Tester. Por lo tanto, en la implementación del proyecto no se tomará en cuenta la descomposición del sistema en hebras de control Vista de Despliegue Se desea definir los recursos y sus características que van a permitir que el proyecto sea implantado y así satisfacer los requerimientos no funcionales como disponibilidad del sistema, confiabilidad, desempeño. Las características recomendadas son: 35

44 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Sistema Operativo Windows 2000, Windows 2003, Windows XP Software - Windows 2000 con service pack 4 o mayor - Windows 2003 Standard Edition - Windows XP con service pack 2 o mayor Productos Microsoft Office (opcional): - Microsoft Word 2000, XP ó Microsoft Project 2000, XP ó Microsoft Excel 2000, XP ó 2003 Servidores de base de datos soportados: - IBM DB2 8.1, 8.2, Oracle 9.2, 10 - Microsoft SQL Server 2005 (SP1), 2000 (SP2, SP3, SP4), version 7 (SP4) -Microsoft Access versiones 2000, 2002 y 2003 Table 4: Requerimientos de Software y Hardware Hardware - Procesador: Intel Pentium 4 1.5GHz o compatible - Memoria: 1GB RAM mínimo (2GB RAM recomendado) - Espacio en disco: aproximadamente 4.5 GB Vista de Implementación Esta sección describe la estructura del modelo de implementación. Este proyecto presentó tres capas: De Presentación: En esta capa, se presentarán los componentes necesarios para permitir la interacción entre los usuarios y el ambiente de pruebas. El Web Services Explorer suministrado por IBM Rational Tester for SOA Quality provee la interfaz gráfica para trabajar con los WSDL y las demás interfaces vienen dadas por las vistas de IBM Rational Performance Tester basadas en Eclipse. Lógica: Ésta es la capa responsable de la manipulación de los datos y de ejecutar las operaciones ingresadas a través de la de presentación. La plataforma de esta capa es las herramientas nombradas en el punto anterior. Están desarrolladas mayormente en el lenguaje Java, por lo tanto, se debe tener instalado el Java Runtime Environment (JRE) para su funcionamiento, el cual será detectado automáticamente. Cabe destacar que el servidor que soportaba los servicios de los WSDL era el WebSphere Application Server. 36

45 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Datos: Es donde residen los datos. El manejador de base de datos que se encargará de recibir las solicitudes de almacenamiento o recuperación de información es DB2. 3. Fase de Construcción Durante esta fase, se describirá las instalaciones y configuraciones necesarias para desarrollar el proyecto. Se explicarán los casos de uso relacionados con los casos de prueba del demo, planteados en la vista lógica del plan de arquitectura y se analizarán los logs de prueba y los reportes generados por la ejecución de cada uno de los planes de prueba. Configuración del ambiente de desarrollo El ambiente de pruebas se implantó en una máquina virtual con los siguientes parámetros: Memoria: 908 MB Disco Duro Primario: 20 GB Disco Duro Secundario: 30 GB Sistema Operativo: Windows XP Professional El hardware utilizado es un servidor destinado a las demostraciones de SOA del E-Business Center, unidad donde se encuentran los servidores de la empresa. Las características que posee son: RAM: 3.25 GB Disco Duro Primario: 67.9 GB Disco Duro Secundario: 99.9 GB Sistema Operativo: Microsoft Server 2003 Enterprise Edition Service Pack 2. Tipo de Servidor: Blade Procesador: Intel Xeon CPU 2 GHz Cabe destacar que las herramientas de prueba también se instalaron en el Blade, ya que los clientes podrían ir hasta al EBC a probar sus aplicaciones y en el caso de que la máquina virtual haya sido removida, pueden hacerlo directamente sobre el servidor. Casos de Prueba y Análisis de los reportes 37

46 CAPÍTULO VI. DESARROLLO DEL PROBLEMA El caso de uso Crear proyecto de prueba de desempeño fue realizado una sola vez, ya que los scripts de prueba y los planes de prueba fueron asignados a ese proyecto. El nombre dado fue: bancariosoa. Para todos los casos se ejecutaron los siguientes casos de uso: Crear prueba desde el Web Services Explorer, Grabar la interacción con el Web Service, Ejecutar la prueba, Revisar el reporte de la prueba, Crear un plan de prueba de desempeño (schedule), Agregar grupo, Añadir ciclo, Adjuntar archivo de prueba, Agregar tiempo de espera (delay), Ejecutar el plan, Revisar los reportes generados, Revisar el resumen, Revisar los resultados del tiempo de respuesta, Revisar el tiempo de respuesta vs. Detalles de tiempo, Revisar el tiempo de respuesta vs. Resumen de tiempo, Revisar el rendimiento de acción de usuario Introducir datos correctos en las operaciones El nombre del script para este caso es WorkingWithAccount. Simplemente lo que se realizó en la parte de la grabación fue suministrar datos simples en todas las operaciones del servicio. Éste es el caso base. El reporte de ejecutar la prueba fue: Figura 6: test log del caso El veredicto es 100% aprobado, lo cual es coherente ya que ningún dato ingresado se salía de las especificaciones de los campos. Los reportes generados a partir del schedule son: 38

47 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Figura 7: Resumen del caso El promedio del tiempo de respuesta fue de ms y su desviación estándar fue de ms, es decir, que la mayor parte de los retornos se hicieron en un tiempo comprendido entre [0, ] ms. Todas las llamadas de intento al Web Service fueron exitosas. Figura 8: Resultados del tiempo de respuesta del caso

48 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Figura 9: Tiempo de Respuesta vs Tiempo del caso Figura 10: Resumen del Tiempo de Respuesta vs Tiempo del caso En los dos primeros reportes (Figuras 8 y 9), se puede observar que la operación con mayor tiempo de respuesta es la correspondiente a crear las cuentas bancarias (createaccount). Se puede deducir que es razonable ya que es la que contiene una mayor cantidad de datos. En cuanto al tercer reporte (Figura 10), el promedio de tiempo de respuesta de todas las llamadas es 40

49 CAPÍTULO VI. DESARROLLO DEL PROBLEMA mayor al principio de la corrida ya que ese el momento en que se están realizando las llamadas a la operación createaccount. El reporte de Desempeño de acción del usuario (Figura 11) muestra que hasta los 600 primeros segundos aproximadamente, todos los usuarios estaban activos; luego hubo un instante en el que ya siete de ellos habían completado sus llamadas y de ahí, en adelante, la carga de usuarios activos fue de quince hasta un segundo antes de terminar la ejecución del proceso que quedaban ocho. Al final, todos culminaron. Figura 11: Desempeño de acción del usuario del caso Ingresar datos en las operaciones erróneos o incongruentes El nombre de la prueba para este caso es WorkingWithAccount5. Simplemente lo que se realizó, en la parte de la grabación, fue suministrar datos que no correspondían a los campos de las operaciones del servicio. Durante la grabación de la prueba, se encontró las siguientes deficiencias: En createaccount, en los campos del nombre y apellido es posible ingresar sólo caracteres numéricos. En la operación withdraw, no indica un mensaje de error al ingresar una cantidad para retirar mayor a la que se encuentra en la cuenta. En las operaciones getbalance, getaccountdetails y withdraw, no identifica si las cuentas no existen. 41

50 CAPÍTULO VI. DESARROLLO DEL PROBLEMA El reporte de ejecutar la prueba fue: Figura 12: test log del caso Como se puede apreciar, el veredicto fue aprobado, lo cual indica que los errores funcionales durante la grabación no influyen en el estado de la corrida de la prueba. Para esta prueba no se realizó un schedule ya que el objetivo de este caso era evaluar el comportamiento de la herramienta y del WSDL ante errores funcionales Añadiendo un punto de verificación de igualdad El nombre del script de este caso de prueba es WorkingWithAccount4. El caso de uso Agregar punto de verificación como elemento de prueba fue realizado para este suceso. El punto de verificación de igualdad fue colocado en la operación getaccountdetails. Al ejecutar la prueba, el veredicto del reporte es que falla (Ver Figura 13). Figura 13: Vista General del test log del caso

51 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Para determinar el por qué de esta situación, es necesario aceptar el resultado del reporte y revisar los eventos. En este caso, la falla proviene del punto de verificación agregado. Para comparar el resultado esperado con el arrojado por la aplicación, se expande la pestaña del WSProtocolData y automáticamente, se muestran los valores que difieren (Figura 14). Figura 14: WSProtocolData Es comprensible que el identificador de la cuenta fuera distinto, ya que cada vez que se crea una cuenta se genera uno. Por lo tanto, no vendría a ser una falla, sino un detalle de la aplicación que faltaría por informar al usuario. De esta forma, el resultado hubiera sido aprobado. Los reportes generados a partir del schedule son: 43

52 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Figura 15: Resumen del caso El promedio del tiempo de respuesta por corrida fue de ms y su desviación estándar fue de ms, es decir, que la mayor parte de los retornos se hicieron en un tiempo comprendido entre [0, ] ms. El porcentaje de los puntos de verificación pasados fue cero por las razones ya dichas. Los intentos de llamada fueron 6,300; de los cuales 6,270 fueron exitosos, un 99.52%. Sigue siendo una buena aplicación. Figura 16: Resultados del tiempo de respuesta del caso

53 CAPÍTULO VI. DESARROLLO DEL PROBLEMA En la figura anterior, se observa que esta vez la operación createaccount no fue la que respondió en mayor tiempo, sino las correspondiente a retirar y encontrar cuenta. En findaccount, el valor de entrada es López. Para enriquecer la prueba se habían creado varias cuentas para este cliente, por lo tanto, se puede suponer que el tiempo de respuesta fue mayor ya que la búsqueda de datos se incrementó con respecto a la prueba anterior. En cuanto a withdraw, no se puede dar una explicación exacta de por qué en este caso tardó más. En la figura 17, se confirma la proposición anterior: withdraw sobresale con un promedio del tiempo de respuesta de ms y la repetición de llamadas de findaccount arroja un promedio de ms. Figura 17: Detalles Tiempo de Respuesta vs. Tiempo del caso El reporte Resumen del tiempo de respuesta vs tiempo es una extrapolación del reporte Detalles del tiempo de respuesta vs tiempo. Si se observa los primeros segundos de la corrida, hay un pico, el cual comparándolo con el reporte anterior corresponde a la operación de retiro. 45

54 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Figura 18: Resumen Tiempo de Respuesta vs Tiempo del caso El reporte de Desempeño de acción del usuario (Figura 19) muestra que hasta los 600 primeros segundos aproximadamente, todos los usuarios estaban activos; luego, hubo un instante en el que ya siete de ellos habían completado sus llamadas y en el próximo segundo eran veintidós los usuarios activos. De ahí, en adelante, la carga de usuarios activos fue de quince hasta segundos antes de terminar la ejecución del proceso, donde quedaban entre cuatro y ocho por completar. Al final, todos culminaron. Figura 19: Desempeño de acción del usuario del caso Añadiendo un datapool 46

55 CAPÍTULO VI. DESARROLLO DEL PROBLEMA El nombre del script de este caso de prueba es WorkingWithAccount3. Los casos de uso Añadir datapool (agrupación de datos) como elemento de prueba e Importar datapool desde un archivo CSV fueron realizados para este suceso. Las variables candidatas seleccionadas fueron los campos de la operación createaccount. El archivo CSV contaba con filas, luego de asignarlas, los campos se sombrearon de color verde oscuro (Ver Figura 20). Figura 20: Asignación de datos a variables candidatas Al ejecutar la prueba, el veredicto es aprobado (Ver figura 21). No hay variación con el caso 3.2.1, ya que los datos ingresados no contenían errores o incongruencias. Figura 21: test log del caso

56 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Los reportes generados a partir de la corrida del schedule: Figura 22: Resumen del caso El promedio del tiempo de respuesta por corrida fue de ms y su desviación estándar fue de ms, es decir, que la mayor parte de los retornos se hicieron en un tiempo comprendido entre [0, ] ms. Los intentos de llamada fueron 5,400; los cuales resultaron todos exitosos. Figura 23: Resultados del tiempo de respuesta del caso

57 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Figura 24: Detalles Tiempo de Respuesta vs. Tiempo del caso En los reportes anteriores (Ver Figura 23 y 24), se evidencia que la operación con mayor tiempo de respuesta fue getbalance, con un promedio de En el reporte Resumen del Tiempo de Respuesta vs. Tiempo (Figura 25), se observa que al comienzo de la ejecución existe un pico que comparándolo con la figura 24, se concluye que corresponde a la operación getbalance. Figura 25: Resumen del Tiempo de Respuesta vs. Tiempo del caso

58 CAPÍTULO VI. DESARROLLO DEL PROBLEMA El reporte de Desempeño de acción del usuario (Figura 26) muestra que hasta los 400 primeros segundos aproximadamente, todos los usuarios estaban activos; luego, hubo un instante en el que sólo uno de ellos había completado sus llamadas y de ahí, en adelante, la carga de usuarios activos fue de quince hasta un segundo antes de terminar la ejecución del proceso que quedaban ocho. Al final, todos los usuarios culminaron. Figura 26: Desempeño de Acción del Usuario del caso Con un datapool y un punto de verificación de igualdad El nombre del script de este caso de prueba es WorkingWithAccount2. Los casos de uso Añadir datapool (agrupación de datos) como elemento de prueba, Importar datapool desde un archivo CSV y Agregar punto de verificación como elemento de prueba fueron realizados para este suceso. El curso de estos casos de uso fueron los mismos que para el caso y Los reportes generados a partir de la ejecución del schedule son: El reporte Resumen (Ver figura 27), donde se muestra el promedio del tiempo de respuesta por corrida fue de ms y su desviación estándar fue de ms, es decir, que la mayor parte de los retornos se hicieron en un tiempo comprendido entre [0,40.923] ms. El porcentaje de los puntos de verificación pasados fue cero por las razones ya dichas. Los intentos de llamada fueron 13,500; los cuales fueron exitosos. 50

59 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Figura 27: Resumen del caso El reporte Resultados de Tiempo de Respuesta (Figura 28) indicó que las operaciones con mayor tiempo de respuesta fueron createaccount y getbalance, concordando el primer resultado con el caso Figura 28: Resultados de Tiempo de Respuesta del caso Las figuras 29 y 30 muestran que en los primeros 1,750 segundos, se registraron tres picos relevantes de las operaciones getbalance, deposit y getaccountdetails. No se evidencia una 51

60 CAPÍTULO VI. DESARROLLO DEL PROBLEMA desviación notoria de createaccount, a pesar de que posee un promedio de tiempo de respuesta elevado respecto a las demás. Figura 29: Detalles del tiempo de respuesta vs. Tiempo del caso Figura 30: Resumen Tiempo de Respuesta vs Tiempo del caso El reporte de Desempeño de acción del usuario (Figura 31) muestra que hasta los 1,500 primeros segundos aproximadamente, todos los usuarios estaban activos; luego, hubo un instante en el que ya cuatro de ellos habían completado sus llamadas y de ahí, en adelante, la carga de 52

61 CAPÍTULO VI. DESARROLLO DEL PROBLEMA usuarios activos fue de quince hasta segundos antes de terminar la ejecución del proceso, donde quedaban entre cuatro y trece por completar. Al final, todos culminaron. Figura 31: Desempeño de Acción del Usuario del caso Exportar los resultados de los schedules correspondientes a los WDSL: BlueBankFrontOffice y Eligibility Como se planteó en la fase de elaboración, se realizó una pequeña comparación entre las dos corridas. Los resultados fueron mostrados a través del tiempo, a continuación, se muestra la condensación de ellos: BlueBankFrontOffice Eligibility Tiempo promedio de respuesta para los retornos (ms) Tiempo mínimo de respuesta para los retornos (ms) 0 0 Porcentaje de VPs pasados Desviación Estándar del tiempo de respuesta para los retornos (ms) Total de VPs fallidos Total de VPs errados 0 13 Intento de llamadas 13,500 1,800 Éxitos de llamadas 13,500 1,769 Timeout de llamadas 0 31 Table 5: Comparación de resultados entre los WSDL 53

62 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Se puede observar que a pesar de que la prueba correspondiente al primer archivo contenía mayor cantidad de operaciones, el tiempo de respuesta fue menor. Todos los VPs del primer schedule fueron fallidos, ya que el valor esperado era el identificador de la cuenta creada al momento de la grabación, por lo tanto, se justifica el resultado. Los VPs errados del segundo archivo se pueden atribuir a una falta en la comunicación por parte del sistema, lo cual dado el porcentaje (1.444%) es irrelevante. En cuanto al número de llamadas, es comprensible que el de BlueBankFrontOffice sea mayor que el de Eligibility, dado que el primero tiene más operaciones Análisis General Comparando los promedios de tiempo de respuesta de las actividades que tardaron más entre los casos del archivo BlueBankFrontOffice, se obtiene que coinciden el caso de prueba base (createaccount) y sólo agrupación de datos (getbalance) con el del punto de verificación y datapool (createaccount y getbalance). Por lo tanto, se supone que las pruebas con puntos de verificación no influyen directamente en los tiempos, su función principal es comparar el valor esperado con el resultado. La prueba de sólo VP contenía un caso especial que eran los datos repetidos de una cuenta, por lo cual, findaccount resultó la más lenta. En cuanto, a withdraw se hace la suposición de que tardó por ser la siguiente operación después del VP, sin embargo, no se puede asegurar nada. Resumiendo, los tiempos promedios de las corridas de los schedules resultó: Tiempo Promedio de respuesta(ms) Caso Base Datos erróneos Sólo datapool Sólo VP Datapool y VP N/A Tabla 6: Resultado promedio entre las corridas 54

63 CAPÍTULO VI. DESARROLLO DEL PROBLEMA Se puede evidenciar que el hecho que contenga elementos de prueba, no implica que los tiempos sean mayores, al contrario. 4. Fase de Transición Ya culminada la fase de construcción, se realizaron ciertas actividades para la entrega final del software. Se elaboró y presentó un corto video a la unidad de Ventas y Distribución de Software, donde se muestra los principales casos de uso. Con esto, se buscaba que los especialistas TI conocieran la herramienta y sus beneficios. Además, se preparó un manual de instalación y un manual de usuario basándose en el caso de prueba Con un datapool y un punto de verificación de igualdad. Estos se pueden revisar en el apéndice VI y VII respectivamente. Además, se realizaron actividades externas al proyecto de pasantía, las cuales serán detalladas en el apéndice VIII. 55

64 CAPÍTULO VII. CONCLUSIONES Y RECOMENDACIONES CAPÍTULO VII. CONCLUSIONES Y RECOMENDACIONES 1. Conclusiones Se puede concluir que la fase de pruebas es vital en el ciclo de vida de SOA, ya que con ellas se puede asegurar la calidad de las aplicaciones. No se puede confiar en que la implementación es la adecuada y publicar los servicios web, saltándose este paso tan importante. Por lo tanto, probar las aplicaciones aún sin poseer una interfaz gráfica es una ventaja en el proceso. El ambiente de pruebas elaborado cumplirá con las principales necesidades de los clientes que posean sus aplicaciones en una SOA, ya que se pueden encontrar deficiencias tanto a nivel funcional como de desempeño, lo más temprano posible. Se puede resaltar que la herramienta IBM Rational Tester for SOA Quality posee las características idóneas para el cumplimiento de esta actividad. Entre las más resaltantes, se encuentran: Se pueden probar Web Services sin interfaz gráfica, gracias al Web Services Explorer, el cual codifica las especificaciones del WSDL y las representa como formularios. Se pueden generar reportes para evaluar el desempeño de los Web Services en situaciones de estrés, detectando posibles cuellos de botellas. Destacando los tiempos de respuestas de las operaciones, el número de intentos de llamadas realizadas, el número de éxitos en las llamadas, así como el comportamiento de los usuarios con respecto al tiempo. Es un producto intuitivo con una interfaz amigable. Cabe destacar que los errores funcionales de la aplicación pueden ser observados sólo durante la grabación de la prueba. Al ejecutarla, el reporte no reflejará este tipo de fallas. 56

65 CAPÍTULO VII. CONCLUSIONES Y RECOMENDACIONES En cuanto al servicio web utilizado, se puede concluir que presenta deficiencias en cuanto a chequeos lógicos que deberían hacerse en este tipo de operaciones bancarias: crear cuenta, depositar, retirar, obtener detalles de la cuenta, obtener balance y encontrar cuenta. Siendo las deficiencias más relevantes: No mostrar un mensaje de error cuando se retira mayor cantidad de dinero que la depositada. No identifica que una cuenta no existe al realizar las operaciones de depósito o retiro. Se pueden ingresar caracteres numéricos en los campos nombre y apellido de la operación crear cuenta. El desempeño de la prueba fue muy bueno, ya que en todos los casos, el éxito de las llamadas fue mayor al 98%. Además, el tiempo promedio de respuesta entre todos los schedules fue de ms, siendo el mayor de ms y el menor de ms. 2. Recomendaciones Se recomienda que para profundizar las pruebas funcionales de un servicio web se emplee una herramienta especialmente diseñada para ello. IBM cuenta con un producto que cumple con esta finalidad: IBM Rational Functional Tester. Sin embargo, esto irá de acuerdo a la preferencia del usuario. La herramienta facilita las pruebas de los servicios antes de que estos sean desplegados, pero una vez que están interactuando con otros servicios del negocio, no se puede verificar el acoplamiento o funcionamiento entre ellos. Por lo tanto, se aconseja que se incluya en este demo una herramienta que satisfaga este requerimiento. IBM Tivoli Composite Application Management (ITCAM) for SOA es una buena opción. 57

66 CAPÍTULO VII. CONCLUSIONES Y RECOMENDACIONES Se recomienda elaborar pruebas de tecnología con los clientes, con el fin de que se familiaricen con la herramienta y entiendan la importancia de la pruebas en una aplicación en SOA. En cuanto al servicio bancario empleado, se recomienda que se incluyan los mensajes de error para las fallas detectadas con la finalidad de mejorar la calidad del servicio. 58

67 BIBLIOGRAFÍA BIBLIOGRAFÍA Bryson, B. (2007, Mayo 15). Hello World: IBM RAtional Tester for SOA Quality. Recuperado de Cerami, Ethan. (2002) Web Service Essentials. O Reilly. Davis, C., et al. (Noviembre 2007) Using Rational Performance Tester Version 7. IBM. High, R., Kinder, S., & Graham, S. (Noviembre 2005) IBM's SOA Foundation. IBM. Holley, K., Palistrant, J., & Graham, S. (Marzo 2006) Effective SOA Governance. IBM. IBM. About IT Financing. Recuperado de IBM. Rational Performance Tester. Recuperado de IBM. Rational Tester for SOA Quality. Recuperado de Kelly, Michael. (2007, Marzo 27) Introduction to IBM Rational Tester for SOA Quality V7.0 and IBM Rational Performance Tester Extension for SOA Quality V7.0 Recuperado de Kroll, P. (2001) The Spirit of the RUP. IBM. 59

68 BIBLIOGRAFÍA Kruchten, Philippe. (2000) The Rational Unified Process: An Introduction. EEUU: Addison- Wesley. Larman, Craig. (2004) UML y Patrones. Prentice-Hall. Lupisella, J. & Lynch, M. (2007) IBM Rational Tester for SOA Quality. IBM. Pressman, Roger S. (2002) Ingeniería del Software: Un enfoque práctico. España: McGraw Hill/Interamericana de España, S.A.U. Probasco, L. (2001) The Ten Essentials of RUP. IBM. 60

69 APÉNDICE I APÉNDICE I: DOCUMENTO DE VISIÓN 61

70 APÉNDICE I Historial de Revisiones Fecha Versión Descripción Autor 11/10/ Versión preliminar como propuesta de desarrollo. Yelimar Rebolledo 18/12/ Actualización de los puntos 4 y 5 Yelimar Rebolledo 03/01/ Revisión general del documento Yelimar Rebolledo 62

71 APÉNDICE I Tabla de Contenidos 1 Introducción Propósito Alcance Definiciones, Acrónimos, y Abreviaciones Referencias 64 2 Posicionamiento Oportunidad de Negocio Sentencia que define el problema Sentencia que define la posición del Producto 66 3 Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios Resumen de Stakeholders Resumen de Usuarios Entorno de usuario Perfil de los Stakeholders Gerente de Ventas Técnicas del Grupo de Software en Venezuela Gerente de Rational en SSA Diseñador Perfiles de Usuario Especialista TI Cliente 69 4 Descripción Global del Producto Perspectiva del producto Resumen de características Suposiciones y dependencias Costo y precio 71 5 Características del Producto Creación de pruebas sin codificar: Edición de Pruebas: Añadir un datapool Agregar puntos de verificación Generación de Reportes Creación de pruebas desde BPEL Soporta los principales estándares de Servicios Web Restricciones 72 7 Precedencia y Prioridad 72 8 Otros Requisitos del Producto Estándares Aplicables Requisitos de Desempeño 72 9 Requisitos de Documentación Manual de Usuario Guías de Instalación, Configuración, y Fichero Léame 73 63

72 APÉNDICE I Visión 1. Introducción 1.1. Propósito El objetivo de este documento es presentar de una manera detallada aspectos de suma importancia para delimitar el alcance del proyecto, conocer las personas involucradas, las características de la aplicación y otros datos necesarios para su completo entendimiento. Los detalles de cómo el ambiente a desarrollar cumple con las necesidades solicitadas por la empresa serán detalladas en el Modelo de Casos de Uso del negocio y en las especificaciones suplementarias Alcance El alcance de este documento incluye la problemática que justifica el desarrollo del proyecto, así como la solución y el beneficio para la empresa. La identificación y perfil de los stakeholders y los usuarios que de alguna u otra manera tienen alguna influencia dentro del desarrollo. Además, las características principales del producto, incluyendo dependencias, suposiciones, características de instalación entre otras; las restricciones, las características de calidad asociadas con la herramienta, los requerimientos funcionales y no funcionales. Y por último, los niveles de documentación exigidos Definiciones, Acrónimos, y Abreviaciones Se hace referencia al Glosario y a la lista de acrónimos y abreviaciones Referencias Los documentos a los que se hace referencia son: - Glosario. - RUP (Rational Unified Process). - Diagrama de casos de uso. 2. Posicionamiento 2.1. Oportunidad de Negocio La Arquitectura Orientada a Servicios - SOA - permite construir un sistema informático más ágil y fácilmente adaptable a las necesidades del cliente, reduciendo los tiempos de desarrollo y gracias a la reutilización de componentes existentes. Basándose en la experiencia con casi clientes de SOA, IBM ha aprendido que éstos entienden que SOA es una secuencia de pasos, un ciclo de vida: modelado, ensamblado, despliegue, gestión y gobierno. En este proceso, no se puede ignorar la práctica de pruebas. Los servicios deben ser probados para garantizar seguridad y confiabilidad a los clientes. RPT y Rational Tester for SOA Quality ofrecen una amplia gama de funcionalidades para realizar las pruebas. Diseñar un modelo 64

73 APÉNDICE I de pruebas para este tipo de arquitectura, solventará los requerimientos no funcionales mencionados. Además, de contar con una serie de reportes que le permitirá analizar los problemas que se puedan presentar en los servicios del negocio Sentencia que define el problema El problema de afecta a El impacto asociado es una adecuada solución sería Probar, de manera efectiva y eficiente, las aplicaciones en SOA Los clientes de las aplicaciones y asociados Pérdida de tiempo en las actividades relacionadas con las pruebas Adquirir IBM Rational Tester for SOA Quality El problema de afecta a El impacto asociado es una adecuada solución sería Probar, de manera efectiva y eficiente, las aplicaciones en SOA, aún cuando no presenten una interfaz gráfica. Los clientes de las aplicaciones y asociados No realizar pruebas a los servicios, lo cual no garantizaría que son confiables. Adquirir IBM Rational Tester for SOA Quality y probarlos a través del Web Services Explorer El problema de afecta a El impacto asociado es una adecuada solución sería Contar con reportes que ayuden a detectar posibles fallas en las aplicaciones en SOA Los clientes de las aplicaciones y asociados Riesgo de un mal funcionamiento al desplegar las aplicaciones al cliente Generarlos con la herramienta IBM Rational Tester for SOA Quality 65

74 APÉNDICE I 2.3. Sentencia que define la posición del Producto Para Quienes IBM Rational Tester for SOA Quality Que Ingenieros de Pruebas, Desarrolladores, Analistas Necesitan probar y analizar las aplicaciones desarrolladas para SOA Es una herramienta de prueba Permite realizar pruebas sin codificar, generar reportes que muestran el tiempo de respuesta de los servicios y su comportamiento de acuerdo a la cantidad de usuarios 3. Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios Para garantizar un buen proceso de modelado de requerimientos, es importante identificar a todos los involucrados en el proyecto y sus necesidades. Esta sección muestra un perfil de los participantes y usuarios, destacando su rol y entorno Resumen de Stakeholders Nombre Descripción Responsabilidades Gerente de Gerente de Ventas Realiza las asignaciones del equipo Ventas Técnicas Técnicas del Grupo de técnico de Software. del Grupo de Software en Venezuela. Seguimiento del desarrollo del Software en Pertenece al proyecto. Venezuela departamento de Ventas y Distribución Aprueba requisitos y funcionalidades. de Software. Gerente de Gerente de Rational en Validar las actividades de la región. Rational en SSA SSA. Pertenece al Asignar las responsabilidades. departamento de Promover las herramientas de la brand Ventas y Distribución a los clientes. de Software. Diseñador Pasante en la unidad de Ventas Técnicas del Grupo de Software Diseñar un ambiente de pruebas con la herramienta IBM Rational Tester for SOA Quality para aplicaciones en SOA, el cual quedará como un aporte importante para posteriores demostraciones y presentaciones de preventa. 66

75 APÉNDICE I 3.2. Resumen de Usuarios Nombre Descripción Responsabilidades Especialista IT Especialista TI, específicamente en la brand de Rational. Pertenece al departamento de Ventas y Distribución de Software. Levantamiento y análisis de requerimientos. Gerencia de Configuración. Asegurar la calidad del software. Cliente Cualquier entidad que presente aplicaciones en SOA y necesite probarlas. Garantizar la eficiencia, seguridad y confianza de sus aplicaciones. Realizar las pruebas necesarias para asegurar que las aplicaciones cuentan con calidad de servicio (QoS) 3.3. Entorno de usuario El entorno de trabajo del usuario debe contar con las siguientes características: Sistema Operativo Windows 2000, Windows 2003, Windows XP Software - Windows 2000 con service pack 4 o mayor - Windows 2003 Standard Edition - Windows XP con service pack 2 o mayor Productos Microsoft Office (opcional): - Microsoft Word 2000, XP ó Microsoft Project 2000, XP ó Microsoft Excel 2000, XP ó 2003 Servidores de base de datos soportados: - IBM DB2 8.1, 8.2, Oracle 9.2, 10 - Microsoft SQL Server 2005 (SP1), 2000 (SP2, SP3, SP4), version 7 (SP4) Hardware - Procesador: Intel Pentium 4 1.5GHz o compatible - Memoria: 1GB RAM mínimo (2GB RAM recomendado) - Espacio en disco: aproximadamente 4.5 GB 67

76 APÉNDICE I -Microsoft Access versiones 2000, 2002 y Perfil de los Stakeholders Gerente de Ventas Técnicas del Grupo de Software en Venezuela Representante Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Comentarios María De Fátima Díaz Gerente de Ventas Técnicas del Grupo de Software en Venezuela. Pertenece al departamento de Ventas y Distribución de Software. Experto de Negocio y de Sistemas. Realiza las asignaciones del equipo técnico de Software. Seguimiento del desarrollo del proyecto. Aprueba requisitos y funcionalidades. Constatar que se cumplan los requerimientos a tiempo. Revisión de requerimientos, estructura de las actividades Ninguno Gerente de Rational en SSA Representante Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Comentarios José Ramón Peña Gerente de Rational en SSA. Pertenece al departamento de Ventas y Distribución de Software. Experto de Negocio y de Sistemas. Validar las actividades de la región. Asignar las responsabilidades. Promover las herramientas de la brand a los clientes. Constatar que se cumplan las actividades a tiempo. Aumento en la métrica del uso de herramientas de la brand de Rational. Revisión de actividades y las métricas relacionadas con la brand. Ninguno 68

77 APÉNDICE I Diseñador Representante Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Comentarios Yelimar Rebolledo Pasante de la USB en la unidad de Ventas Técnicas del SWG. Experto en Diseño. Diseñar un ambiente de pruebas con la herramienta IBM Rational Tester for SOA Quality para aplicaciones en SOA, el cual quedará como un aporte importante para posteriores demostraciones y presentaciones de preventa. Finalizar un ambiente de pruebas adecuado para las aplicaciones en SOA. Revisión de requerimientos, estructura del sistema, realización de pruebas con un proyecto modelo y posteriormente, análisis de los reportes generados. Ninguno 3.5. Perfiles de Usuario Especialista TI Representante Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Comentarios Yecsy Escalona Especialista TI, específicamente en la brand de Rational. Pertenece al departamento de Ventas y Distribución del SWG. Experto de Negocio y de Sistemas. Levantamiento y análisis de requerimientos. Gerencia de Configuración. Asegurar la calidad del software. Ninguno Cliente Representante Descripción Cualquier entidad que presente aplicaciones en SOA y necesite probarlas. 69

78 APÉNDICE I Tipo Usuario principal. Responsabilidades Garantizar la eficiencia, seguridad y confianza de sus aplicaciones. Realizar las pruebas necesarias para asegurar que las aplicaciones cuentan con calidad de servicio (Quality of Service: QoS) Criterio de Éxito Grado de participación Comentarios Aprueba el demo ofrecido y obtiene la herramienta IBM Rational Tester for SOA Quality Define los requerimientos. Utiliza el ambiente para realizar pruebas de sus aplicaciones. Ninguno 4. Descripción Global del Producto 4.1. Perspectiva del producto Este ambiente de pruebas está dirigido a cualquier empresa o persona que esté interesada en realizar pruebas de estrés o de carga a sus aplicaciones y generar reportes que muestren el desempeño general y de las operaciones más lentas, así como el estatus de los puntos de verificación. Este producto surge de la necesidad de dar a conocer a los clientes la herramienta, IBM Rational Tester for SOA Quality, como un apoyo para la fase de despliegue, donde uno de los principales objetivos es asegurar la calidad de los servicios Resumen de características A continuación se mostrará un listado con los beneficios que obtendrá el cliente a partir del producto: Beneficio del cliente Realizar scripts de prueba sin codificar Comparar resultados esperados con los obtenidos fácilmente Obtener reportes que servirán para detectar cuellos de botella o el comportamiento general de la aplicación Probar los beneficios descritos antes de adquirir la herramienta. Características que lo apoyan Cuenta con el Web Services Explorer, una interfaz que se personaliza de acuerdo a la lectura del WSDL. A través de los puntos de verificación Ofrece reportes de tiempo de respuesta general del servicio, el tiempo de respuesta de cada operación a través del tiempo, el desempeño de las operaciones más lentas, las llamadas exitosas y las fallidas. Una máquina virtual que contará con las herramientas necesarias para apoyar las pruebas. 70

79 APÉNDICE I 4.3. Suposiciones y dependencias Se supone que el cliente cuenta con aplicaciones en SOA y que desea probarlas para garantizar su calidad. No se necesita un conocimiento avanzado en programación, solamente poseer conceptos claros en cuanto a las prueba para poder grabar scripts confiables y analizar de manera eficiente los reportes. Las dependencias que pueden afectar este producto dependen de los requerimientos del cliente, por ejemplo, si desea cubrir otras fases del ciclo de SOA o si las pruebas que busca realizar son de otro tipo como caja blanca Costo y precio El costo asociado al producto es la remuneración que se le paga al pasante, ya que el hardware utilizado es proporcionado por IBM y el software es de licencia temporal. En cuanto al precio, este ambiente de pruebas no tiene precio alguno para ser usado por el cliente ya que la idea es que al realizar la presentación de preventa del software IBM Rational Tester for SOA Quality, se le ofrezca esta demo para revisar y utilizar la herramienta antes del proceso de compra. 5. Características del Producto 5.1. Creación de pruebas sin codificar: Gracias al Web Services Explorer (WSE), se puede contar con una interfaz para las aplicaciones que no poseen cliente. Los WSDL poseen una sintaxis como los XML, sólo que en vez de valores presenta los tipos de datos. De esta forma, es que el WSE reconoce los campos de entrada que serán evaluados para la prueba Edición de Pruebas: La herramienta presenta una gran cantidad de variantes para enriquecer las pruebas. Sin embargo, se hará referencia a las más relevantes: Añadir un datapool Al editar los scripts de prueba, se puede agregar una agrupación de datos a los campos candidatos (aparecerán en verde). Se puede hacer manualmente o importando columnas desde un archivo CSV Agregar puntos de verificación Para verificar el comportamiento esperado de la aplicación durante la prueba del servicio web, se puede añadir puntos de verificación después de un mensaje de retorno. En este caso, los resultados del mensaje de retorno son comparados con los datos esperados especificados en el elemento de prueba. Durante la corrida, estos puntos pueden producir estatus de Aprobado, Falla, Error o Inconcluso. 71

80 APÉNDICE I 5.3. Generación de Reportes Después de la ejecución de la prueba, automáticamente se generan gráficos y tablas con la información del tiempo de respuesta de sus operaciones, así como el comportamiento de los usuarios Creación de pruebas desde BPEL Automáticamente genera pruebas desde los procesos de negocio definidos usando el estándar BPEL desde un rango de posibilidades. Esta característica ayuda a probar procesos complejos y asegurar que todos los caminos relevantes sean examinados Soporta los principales estándares de Servicios Web. 6. Restricciones En principio, se pide que el producto sea implantado en un servidor de IBM. Las demás restricciones que se puedan presentar serán las definidas por el cliente. 7. Precedencia y Prioridad Para la realización del producto, principalmente, se debe contar con aplicaciones en SOA, específicamente, los WSDL ya que sin ellos no habría que probar. Luego, se debe crear el proyecto de prueba, grabar el script a través del Web Services Explorer, editarlo, correrlo, obtener los reportes, analizarlos y realizar las respectivas recomendaciones. En cuanto a las prioridades, la primera es grabar los scripts y editarlas de forma que sean pruebas robustas. La siguiente es ejecutarlos para poder analizar los reportes para encontrar posibles cuellos de botellas y mejorar el desempeño de la aplicación, el cual es el principal objetivo para asegurar la calidad de ésta. Otras acciones secundarias tienen orden de prioridad de acuerdo a las necesidades del cliente. 8. Otros Requisitos del Producto 8.1. Estándares Aplicables Soporta los estándares de Web Services tales como SOAP, HTTP(S), JMS, WS-Security, UDDI Requisitos de Desempeño Es necesario que el hardware utilizado cumpla con los requerimientos nombrados en el punto 3.3 para que el demo sea eficiente y las pruebas no se retarden, logrando ser un producto seguro y confiable al cliente. 72

81 APÉNDICE I 9. Requisitos de Documentación 9.1. Manual de Usuario El propósito del manual de usuario es orientarlo en el desarrollo de una prueba, abarcando los pasos más importantes. Se presentará de forma amigable y con un lenguaje adecuado al usuario final. Para mayor información, también se pueden consultar los tutoriales de las herramientas IBM Rational Performance Tester e IBM Rational Tester for SOA Quality Guías de Instalación, Configuración, y Fichero Léame Se ofrecerá un manual de instalación de las principales herramientas implicadas en la elaboración de la demo: Installation Manager, IBM Rational Performance Tester e IBM Rational Tester for SOA Quality. 73

82 APÉNDICE II APÉNDICE II: GLOSARIO 74

83 APÉNDICE II Historial de Revisiones Fecha Versión Descripción Autor 12/09/ Versión preliminar del glosario Yelimar Rebolledo 20/10/ Se agregaron conceptos Yelimar Rebolledo 25/11/ Se agregaron conceptos Yelimar Rebolledo 05/01/ Se agregaron conceptos Yelimar Rebolledo 75

84 APÉNDICE II Tabla de Contenidos 1. Introducción Propósito Alcance Definiciones 77 76

85 APÉNDICE II Glosario 1. Introducción 1.1. Propósito El objetivo de este documento es presentar el significado de los términos que puedan resultar desconocidos por el lector en el informe. Sirve como un apoyo al mejor entendimiento del presente trabajo Alcance Se presentan la lista de los términos con su definición en orden alfabético, abarcando todo el ciclo de vida del proyecto. 2. Definiciones Aplicación compuesta: Es un conjunto de servicios relacionados e integrados que soporta un proceso de negocio construido en SOA. Arquitectura Orientada a Servicios: Es un estilo de arquitectura para crear una arquitectura de Tecnología de Información Empresarial que explota los principios de orientación a servicio para alcanzar una relación más estrecha entre el negocio y los sistemas de información que lo soportan. BPEL: Lenguaje ejecutable de modelado de procesos basado en XML. Caso de Uso: es un instrumento para recopilar requerimientos, puede ser usada como estrategia de desarrollo o conduccion de proyectos de sistemas Composición de servicios: Proceso de negocio. Enterprise Service Bus: Punto de conexión entre todos los servicios de una arquitectura orientada a servicios. Framework: es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Hito: Es un elemento tangible (artefacto), que permite decidir si el trabajo realizado hasta el momento es el adecuado o no. Orientación de servicio: Es un modo de integrar el negocio como un conjunto de servicios ligados. Rational Unified Process (RUP): Es un proceso de ingeniería de sotfware. Provee una 77

86 APÉNDICE II disciplina para la asignación de tareas y responsabilidades dentro de una organización de desarrollo, su objetivo es asegurar la producción de un software de alta calidad que satisfaga las necesidades de los usuarios dentro de un tiempo predecible. Script: es un guión o conjunto de instrucciones. Permiten la automatización de tareas creando pequeñas utilidades. SOAP: Es un protocolo utilizado en arquitecturas SOA para transportar los mensajes basados en XML a través de las redes de la organización para mantener una comunicación entre los servicios Web. Stakeholder: Involucrado en el proceso de negocio que posee intereses directos o indirectos en el proyecto WSDL: Es un lenguaje basado en XML que es utilizado para describir los servicios Web. Con este lenguaje se crean documentos que especifican los datos de entrada, salida y una breve descripción de un servicio Web. Todos los servicios Web de una arquitectura SOA están descritos con documentos WSDL. XML: Es un lenguaje estándar diseñado para facilitar el intercambio de datos a través de distintos sistemas de información, particularmente Internet. XML es un estándar abierto y es una parte vital de las arquitecturas SOA. 78

87 APÉNDICE III APÉNDICE III: LISTA DE RIESGOS 79

88 APÉNDICE III Historial de Revisiones Fecha Versión Descripción Autor 12/10/ Lista Inicial de Riesgos Yelimar Rebolledo 80

89 APÉNDICE III Tabla de Contenidos 1. Introducción Propósito Alcance Definiciones, Acrónimos, y Abreviaciones Referencias Riesgos Falla en la planificación del desarrollo del proyecto Escaso manejo de las tecnologías o de las fuentes Insatisfacción del usuario con el producto final Cambio en los requerimientos El servidor en el que se encuentra el sistema falla La disponibilidad del hardware a utilizar se retrasa 84 81

90 APÉNDICE III Lista de Riesgos 1. Introducción 1.1. Propósito El objetivo de este documento es presentar la lista de situaciones que podrían afectar el desarrollo del producto Alcance El alcance de este documento incluye los posibles riesgos que se pueden presentar en cualquiera de las fases del proyecto. Para cada uno de ellos, se describe una tabla con los siguientes aspectos: Magnitud: Será expresado con un número del 1 al 10, donde 10 indica que es el más dañino para la ejecución del proyecto y 1 menos. Descripción: Una breve Impactos: Se lista las consecuencias originadas en el proyecto. Indicador: Describe cómo monitorear y detectar que el riesgo ha ocurrido o está por suceder. Mitigación: Estrategia que debe ser llevada a cabo para minimizar la incidencia del riesgo. Plan de Contingencia: Curso de la acción a seguir en caso de que se materialice el riesgo Definiciones, Acrónimos, y Abreviaciones Se hace referencia al Glosario y a la lista de acrónimos y abreviaciones Referencias Los documentos a los que se hace referencia son: - Glosario. - Documento de Visión. 82

91 APÉNDICE III 2. Riesgos 2.1. Falla en la planificación del desarrollo del proyecto MAGNITUD 7 DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN PLAN DE CONTINGENCIA El tiempo estimado para realizar las actividades de cada fase no fue realista. Se retrasa la culminación de las tareas. El tiempo es insuficiente para culminar con éxito las actividades. Evaluar conscientemente los tiempos que se estiman para cada actividad. Si es posible, dar uno o dos días de gracia en la planificación por si el tiempo no alcanza. Solicitar al jefe de proyecto, extender el tiempo de culminación del producto o reducir los requerimientos del producto. En el caso de que no sea aprobada la solicitud, trabajar horas extras Escaso manejo de las tecnologías o de las fuentes MAGNITUD 8 DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN PLAN DE CONTINGENCIA Los conocimientos adquiridos no son competentes para la realización del producto o el levantamiento de requerimientos no fue el adecuado. Retraso en el tiempo de ejecución de las actividades y baja calidad en el proyecto. Poca explicación del contenido de los requerimientos. Improvisación en la toma de decisiones para solucionar los problemas que se presentan. Documentarse durante todo el proceso. Proponer reuniones con los involucrados para verificar que se maneja la información adecuada. Solicitar ayuda del personal. Investigar. Preguntar en foros relacionados con el tema Insatisfacción del usuario con el producto final MAGNITUD 9 DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN El software no cumple con las necesidades del usuario. Pérdida del cliente al que se le presenta la herramienta. Referencias negativas del producto o simplemente, no fue de su agrado. Acordar reuniones para discutir lo que el usuario desea. 83

92 APÉNDICE III PLAN DE CONTINGENCIA Evaluar las opiniones del cliente para buscar una posible solución con otras herramientas, si es posible Cambio en los requerimientos MAGNITUD 5 DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN PLAN DE CONTINGENCIA Surge un ajuste en los requerimientos. Reestructuración de los tiempos y actividades. Usuario o stakeholder manifiesta el cambio al diseñador. Ninguno. Se debe estar abierto a los cambios que se puedan presentar durante el proyecto. Manejar el cambio. Planificar las actividades de acuerdo a éste y comunicarlo a los involucrados del proyecto El servidor en el que se encuentra el sistema falla MAGNITUD 10 DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN PLAN DE CONTINGENCIA Falla de hardware o software, donde se encuentra el producto. Retraso en el desarrollo del producto. Posible pérdida de trabajo realizado. El servidor no responde. Realizar un respaldo de lo que se lleva. Realizar el mantenimiento adecuado a la máquina. Implantar la herramienta en otra máquina La disponibilidad del hardware a utilizar se retrasa MAGNITUD 6 DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN PLAN DE CONTINGENCIA No se cuenta con los recursos para implantar el demo. Pérdida de tiempo. No se implanta el sistema en el tiempo estimado. Verificar al comienzo del desarrollo del proyecto que hay disposición del hardware. En el caso de que no haya, solicitarlo al personal correspondiente. Definir la infraestructura y presentar el manual de instalación al personal, en caso de que no se cuente con el equipo antes de finalizar la pasantía. 84

93 APÉNDICE IV APÉNDICE IV: ESPECIFICACIÓN DE CASOS DE USO 85

94 APÉNDICE IV Historial de Revisiones Fecha Versión Descripción Autor 08/09/ Especificación de los principales de casos de uso 10/10/ Especificación de los nuevos casos de uso determinados en la fase de elaboración 17/12/ Completar flujos de algunos casos de uso Yelimar Rebolledo Yelimar Rebolledo Yelimar Rebolledo 86

95 APÉNDICE IV Especificación de Casos de Uso A continuación, se presenta la descripción de cada caso de uso identificado y su flujo de eventos, tanto básico como alternativo. Además, el actor que lo realiza y la precondición y poscondición de su ocurrencia. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL Crear proyecto de prueba de desempeño Usuario Como primer paso, el usuario crea un proyecto indicando el nombre y donde estarán localizadas las carpetas fuentes. Ingresar al ambiente de pruebas. Abrir la herramienta RPT. Actor Sistema 1. El usuario va a File -> New 2. Se presenta el wizard de Creación de -> Performance Test Project Proyectos 3. Ingresa el nombre del 4. Se crea una carpeta con ese nombre proyecto donde se guardará todo lo relacionado a ese proyecto CURSO ALTERNO Actor Sistema (I) 4. El nombre ingresado ya existe. Aparece un mensaje indicando esto. POSCONDICIÓN El usuario creó una carpeta que contendrá el proyecto. FRECUENCIA OCURRENCIA DE Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Crear prueba desde el Web Services Explorer Usuario Se indica el proyecto con el que se desea trabajar, el nombre de la prueba, se importa el WSDL al área de trabajo, el puerto por el que se desea realizar la grabación y se acepta la advertencia de privacidad que implica realizar este tipo de pruebas. Haber creado un proyecto. CURSO NORMAL Actor Sistema 87

96 APÉNDICE IV 1. El usuario presiona el botón de grabación 3. Selecciona Web Service Recording using the Web Services Explorer 5. Selecciona el que desee, ingresa el nombre y presiona Next 7. Se selecciona el archivo deseado y se finaliza 2. Aparece el wizard de creación de nueva prueba desde grabación 4. Lista los posibles proyectos al que será asociado 6. Se muestran los WSDL que se encuentran en el área de trabajo 8. Se inicializa el script de prueba CURSO ALTERNO Actor Sistema (I) 6. El nombre ingresado ya existe. Aparece un mensaje indicando esto. CURSO ALTERNO (II) POSCONDICIÓN FRECUENCIA OCURRENCIA DE 7. No hay WSDL en el área de trabajo. Se importa el archivo y se finaliza. El usuario configuró lo necesario para crear un script desde el WSE. Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL Grabar la interacción con el Web Service Usuario Se navegan las operaciones del servicio web, introduciendo los datos de entrada de cada uno de ellos. Haber creado una prueba desde el WSE. Actor Sistema 1. El usuario elige la 2. Se provee una interfaz indicando los operación a probar en la campos de entrada sección de Acciones 4. Se procesan los datos y de haber un 3. El usuario ingresa los datos parámetro de salida asociado, se devuelve que desea y presiona Go CURSO ALTERNO Actor Sistema (I) 4. Los datos ingresados no cumplen con las especificaciones del tipo de campo. Se muestra un mensaje de error. POSCONDICIÓN El usuario grabó el script de prueba. 88

97 APÉNDICE IV FRECUENCIA OCURRENCIA DE Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA Editar la prueba Usuario Se pueden reemplazar los valores de prueba grabados con otro tipo de datos o data dinámica. Además de puntos de verificación para comparar con los mensajes de retorno. Haber grabado la interacción con el Web Service Actor Sistema 1. El usuario selecciona la 2. Si la operación contiene parámetros operación a editar en la de entrada, aparecerán del lado sección Test contents. derecho. 3. Elige exactamente lo que 4. Realiza la operación pertinente: desea modificar para la 4.1- Si selecciono una variable candidata de los parámetros de entrada, prueba. se inicia el caso de uso Añadir datapool (agrupación de datos) como elemento de prueba Si el valor que aparece debajo de la operación. Se inicia el caso de uso Agregar punto de verificación como elemento de prueba. Ninguna Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Añadir datapool (agrupación de datos) como elemento de prueba Usuario Se observan las variables candidatas (las de color verde) y se seleccionan para agregarle más datos. Haber iniciado el caso de uso Editar prueba CURSO NORMAL Actor Sistema 89

98 APÉNDICE IV POSCONDICIÓN FRECUENCIA DE OCURRENCIA 1. El usuario le da clic al botón de editar al lado de la variable candidata 3. El usuario hace clic derecho sobre el espacio en blanco 5. El usuario selecciona Substitute From! Datapool Variable. 7. Presiona el botón Add Column 9. Se selecciona el datapool deseado y se presiona Select 11. Se elige la que corresponde al valor de la variable 2. Aparece una ventana indicando el nombre y valor de la variable 4. Aparece un menú con las opciones 6. Se muestra una ventana para seleccionar la columna de la agrupación de datos 8. Se presenta la ventana con los datapool cargados en el área de trabajo 10. Se muestran todas las columnas de esa agrupación de datos 12. Ese grupo de datos queda asociado a la variable El usuario asignó una agrupación de datos a las variables deseadas Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Importar datapool desde un archivo CSV Usuario Una de las formas de consignar una agrupación de datos a una variable, es asignando una columna de datos de un archivo CSV. Se selección las variables para agregar un datapool CURSO NORMAL Actor Sistema 1. El usuario le da clic derecho 2. Aparece un menú desplegable sobre la prueba deseada. 3. Elige New! Datapool 4. Se presenta una ventana con los proyectos existentes y con el campo nombre 5. Verifica que el proyecto que 6. Se muestra una ventana con el se quiere esté sombreado e campo Description ingresa el nombre del 8. Aparece la ventana para importar el datapool archivo 7. El usuario ingresa la 10. Ese archivo queda almacenado en el descripción del datapool. área de trabajo de ese proyecto. Presiona Next para continuar. 9. Indica la ruta del CSV y le da a Finish CURSO ALTERNO Actor Sistema (I) 6. El nombre suministrado ya existe. Se retorna un mensaje de error. 90

99 APÉNDICE IV CURSO ALTERNO (II) POSCONDICIÓN FRECUENCIA OCURRENCIA DE 10. En la ruta especificada no se encuentra un archivo de tipo CSV. Aparece un mensaje de error. El usuario asignó una agrupación de datos a las variables deseadas con la ayuda de un archivo CSV Frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA Agregar punto de verificación como elemento de prueba Usuario La intención de este caso de uso es chequear el comportamiento de la aplicación durante la prueba. Haber iniciado el caso de uso Editar prueba Actor Sistema 1. En la vista Test Navigator, 2. En la sección Test Contents, hace doble clic en la prueba. aparecen las operaciones probadas y 3. Expande la operación a la sus valores retornados. que desea agregar un punto de 4. Aparece debajo de ella, el valor retornado. verificación. 6. Se presenta un menú desplegable. 5. Hacer clic al botón derecho 8. Queda registrado un punto de sobre él. verificación en esa operación. 7. Selecciona Add! Equal Verification Point. El usuario añadió un punto de verificación en la operación deseada Frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Ejecutar la prueba Usuario Se selecciona el script de prueba y se corre como una prueba de desempeño. Haber grabado la interacción con el Web Service CURSO NORMAL Actor Sistema 91

100 APÉNDICE IV POSCONDICIÓN FRECUENCIA DE OCURRENCIA 1. En la vista Test Navigator, hace clic del botón derecho sobre la prueba 3. Selecciona Run As! Performance Test El usuario corrió la prueba creada. Muy frecuente. 2. Aparece un menú desplegable. 4. Se corre la prueba. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Revisar el reporte de la prueba Usuario Se revisa el log de la prueba, observando el veredicto determinado: aprobado, falla, error, inconcluso. Además, se muestran la visión general y los eventos. Haber ejecutado la prueba CURSO NORMAL Actor Sistema 1. En la pestaña Performance 2. Aparece un menú desplegable. Test Runs, clic derecho sobre 4. Se mostrará la información general la prueba de la prueba, por ejemplo, el veredicto. 3. Selecciona Display Test 6. Se presenta el resultado de la prueba Log. 8. Se despliegan las operaciones 5. Presiona la pestaña de realizadas eventos. 7. Acepta el veredicto CURSO ALTERNO Actor Sistema (I) 9. El usuario puede darle clic a 8. Si la prueba falló, además de las operaciones, se indicará la pestaña WSProtocol dónde hubo un problema. Data 10. Aparece la comparación del valor esperado y el devuelto POSCONDICIÓN El usuario chequeó el reporte FRECUENCIA OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN DE Muy frecuente. Crear un plan de prueba de desempeño (schedule) Usuario Se especifica el nombre y la ubicación del plan Haber grabado la interacción con el Web Service CURSO NORMAL Actor Sistema 92

101 APÉNDICE IV 1. El usuario le da clic al botón derecho sobre el proyecto y selecciona New -> 3. Ingresa el nombre de la prueba 2. Se presenta el wizard de Creación de Proyectos 4. Se crea una carpeta con ese nombre donde se guardará todo lo relacionado a ese proyecto CURSO ALTERNO Actor Sistema (I) 4. El nombre ingresado ya existe. Aparece un mensaje indicando esto. POSCONDICIÓN El usuario configuró lo necesario para indicar el schedule FRECUENCIA OCURRENCIA DE Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN Editar el Schedule Usuario Una vez creado el plan de prueba, se precederá a agregarle elementos como ciclos, usuarios y configurarlos. Haber creado el plan de prueba de desempeño Actor 1. El usuario selecciona un elemento. 3. Selecciona el botón add. 5. Elige el que desea. Ninguna Muy frecuente. Agregar grupo Sistema 2. Se muestran del lado derecho, las opciones de configuración. 4. Aparecen los elementos que se pueden agregar a partir del seleccionado. 4. Realiza la operación pertinente: 4.1- Si selecciono grupo, se inicia el caso de uso Agregar grupo Si selecciono delay, se inicia el caso de uso Agregar delay Si selecciono ciclo, se inicia el caso de uso Añadir ciclo Si selecciono test, se inicia el caso de uso Adjuntar archivo de prueba. Usuario Por defecto, existe un grupo de usuarios. No obstante, se debe configurar las características asociadas como el número, porcentaje que representa. 93

102 APÉNDICE IV PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA Haber creado un plan de prueba de desempeño Actor Sistema 1. En la sección Schedule Contents, presionar el nombre del schedule. 3. En la sección Schedule Element Details, cambia el número de usuarios. 5. Selecciona el grupo de usuarios 1 en la sección Schedule Contents. Darle clic al botón Add y elegir Group. 7. Cambia los porcentajes de usuario de cada grupo para que sume 100% El usuario agregó un grupo en el schedule Frecuente. 2. Se mostrarán las propiedades del Schedule hasta el momento a la derecha. 4. Se registra el nuevo número de usuarios para la prueba 6. Se crea un nuevo grupo de usuarios en el plan de prueba de desempeño. 8. Se asocia los porcentajes a los grupos de usuarios. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL Añadir ciclo Usuario Se elige un grupo de usuarios, se especifican el número de iteraciones y si se desea controlar la tasa de éstas. Haber creado un plan de prueba de desempeño Actor Sistema 1. En la sección Schedule Contents, presionar el nombre del schedule. 3. Selecciona el grupo de usuarios 1 en la sección Schedule Contents. Darle clic al botón Add y elegir Loop. 5. Cambiar el número de iteraciones en la sección Schedule Element Details CURSO ALTERNO Actor 2. Se mostrarán las propiedades del Schedule hasta el momento a la derecha. 4. Se crea un ciclo en el plan de prueba de desempeño. 6. Se asocia el número de iteraciones ingresado al ciclo. Sistema 94

103 APÉNDICE IV (I) POSCONDICIÓN FRECUENCIA DE OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA 7. Si se quiere controlar la tasa de iteraciones, marcar esa opción. 9. Configurar la medida de tiempo y el tiempo de espera entre ellas. El usuario inició sesión en el sistema PAL. Muy frecuente. Agregar tiempo de espera (delay) Usuario 8. Se habilitarán las opciones correspondientes a la tasa de iteraciones. 9. Se configuran estas medidas a las iteraciones del ciclo. Se elige el último elemento de la prueba y se le asigna un retraso para ese momento Haber creado un plan de prueba de desempeño Actor Sistema 1. En la sección Schedule Contents, presionar el nombre del schedule. 3. Selecciona el último elemento en la sección Schedule Contents. Darle clic al botón Add y elegir Delay. 5. Especifica la medida de tiempo y la cantidad en la sección Schedule Element Details 2. Se mostrarán las propiedades del Schedule hasta el momento a la derecha. 4. Se crea un tiempo de espera en el plan de prueba de desempeño. 6. Se asocia el tiempo de espera en ese momento. El usuario agregó un tiempo adicional en un elemento del schedule. Frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Adjuntar archivo de prueba Usuario Se selecciona el último elemento de la prueba y se le asigna el script de la lista que se presenta. Haber creado un plan de prueba de desempeño CURSO NORMAL Actor Sistema 95

104 APÉNDICE IV POSCONDICIÓN FRECUENCIA DE OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA 1. En la sección Schedule Contents, presionar el nombre del schedule. 3. Selecciona el último elemento en la sección Schedule Contents. Darle clic al botón Add y elegir Test. 5. Elige la prueba deseada El usuario adjuntó un script al schedule Muy frecuente. Revisar los reportes generados Usuario 2. Se mostrarán las propiedades del Schedule hasta el momento a la derecha. 4. Aparece una ventana especificando las pruebas existentes. 6. Se asocia una prueba al schedule. Luego de verificar que el estado de la corrida del plan de prueba es completo, se pueden observar los diferentes reportes y analizarlos. Haber ejecutado un plan de prueba de desempeño Actor 1. El usuario presiona una de las pestañas de los reportes. Sistema 2. Si hizo clic sobre la pestaña: 2.1- Resumen, se inicia el caso de uso Revisar el resumen Resumen Tiempo de respuesta vs. Tiempo, se inicia el caso de uso Revisar el reporte resumen del Tiempo de respuesta vs. Tiempo Tiempo de Respuesta, se inicia el caso de uso Revisar el reporte de los tiempos de respuesta Detalles de Tiempo de respuesta vs. Tiempo, se inicia el caso de uso Revisar el reporte de los detalles de Tiempo de Respuesta vs Tiempo Rendimiento de acción de usuario, se inicia el caso de uso Revisar el reporte Rendimiento de acción de usuario. El usuario revisó los reportes generados por la corrida del plan Muy frecuente. 96

105 APÉNDICE IV CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL Revisar el resumen Usuario Se podrá observar tablas que ofrecen datos claves sobre las llamadas hechas y la corrida en general. Haber iniciado el caso de uso Revisar los reportes generados Actor 1. Hace clic sobre la pestaña Resumen Sistema 2. Muestra las tablas de resultados de la prueba POSCONDICIÓN FRECUENCIA DE OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL El usuario revisó el resumen generado por la corrida del plan Muy frecuente. Revisar el reporte de los resultados del tiempo de respuesta Usuario Se podrá analizar un gráfico y datos sobre las páginas más lentas. Haber iniciado el caso de uso Revisar los reportes generados Actor 1. Hace clic sobre la pestaña Tiempo de Respuesta Sistema 2. Muestra los gráficos y tabla resumen en cuanto a los tiempos de respuestas de las operaciones durante la prueba. POSCONDICIÓN FRECUENCIA DE OCURRENCIA El usuario revisó el reporte de los resultados del tiempo de respuesta generados por la corrida del plan Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Revisar el reporte de detalles del Tiempo de respuesta vs. de tiempo Usuario Se mostrará un gráfico con el tiempo promedio de todos los retornos a través del tiempo y una tabla resumen. Haber iniciado el caso de uso Revisar los reportes generados CURSO NORMAL Actor Sistema 97

106 APÉNDICE IV 1. Hace clic sobre la pestaña Detalles Tiempo de Respuesta vs Tiempo 2. Muestra los gráficos y tabla resumen en cuanto a los tiempos de respuestas de las operaciones en el transcurso del tiempo durante la prueba. POSCONDICIÓN FRECUENCIA DE OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL El usuario revisó el reporte de detalles de Tiempo de respuesta vs. Tiempo generado por la corrida del plan Muy frecuente. Revisar el reporte resumen del Tiempo de respuesta vs. Tiempo Usuario Se presentará un gráfico y una tabla con el tiempo promedio de respuesta de cada operación. Haber iniciado el caso de uso Revisar los reportes generados Actor Sistema 1. Hace clic sobre la pestaña Resumen de Tiempo de Respuesta vs Tiempo 2. Muestra los gráficos y tabla resumen en cuanto a los tiempos de respuestas de las operaciones más lentas durante la prueba. POSCONDICIÓN FRECUENCIA DE OCURRENCIA El usuario revisó el reporte resumen del Tiempo de respuesta vs. Tiempo generado por la corrida del plan Muy frecuente. CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN Revisar el reporte Rendimiento de acción de usuario Usuario Se presentará un gráfico sobre la tasa de llamadas hecha por todos los usuarios virtuales asignados y la tabla sobre los completados y activos. Haber iniciado el caso de uso Revisar los reportes generados CURSO NORMAL Actor Sistema 98

107 APÉNDICE IV 1. Hace clic sobre la pestaña Rendimiento de acción de usuario 2. Muestra los gráficos y tabla resumen en cuanto a la carga de los usuarios en el transcurso del tiempo durante la prueba. POSCONDICIÓN FRECUENCIA DE OCURRENCIA CASO DE USO ACTOR DESCRIPCIÓN PRECONDICIÓN CURSO NORMAL POSCONDICIÓN FRECUENCIA DE OCURRENCIA El usuario revisó el reporte Rendimiento de acción de usuario generado por la corrida del plan Muy frecuente. Exportar Resultados a un archivo CSV Usuario Se exportarán los resultados deseados a un CSV. Ejecutar un archivo o plan de prueba. Actor Sistema 1. El usuario va a File -> Export 3. Expande Test y selecciona Performance Test Run Statistics 5. Ingresa el nombre deseado o indica la ruta del CSV existente 7. Selecciona la ejecución que quiere 9. Elige los de preferencia Se creó un archivo CSV con los datos indicados. Frecuente. 2. Se presenta el wizard de Exportación 4. Aparece una ventana en la cual se indicara el nombre del archivo 6. Se listan las corridas presentes en el área de trabajo de la herramienta 8. Se muestran las opciones de datos que se pueden exportar al archivo 10. Se crea un archivo CSV con los datos de la corrida que el usuario seleccionó 99

108 APÉNDICE VI APÉNDICE V: PLAN DE DESARROLLO 100

109 APÉNDICE VI Historial de Revisiones Fecha Versión Descripción Autor 20/09/ Versión Preliminar del Plan de Desarrollo de Software Yelimar Rebolledo 101

110 APÉNDICE VI Tabla de Contenidos 1. Introducción Propósito Alcance Definiciones, Acrónimos, y Abreviaciones Referencias Vista General del Proyecto Propósito, Alcance y Objetivos Entregables del proyecto Evolución del Plan de Desarrollo del Software Organización del Proyecto Participantes en el Proyecto Roles y Responsabilidades Gestión del Proceso Estimaciones del Proyecto Plan del Proyecto Plan de las Fases Calendario del Proyecto Seguimiento y Control del Proyecto Error! Bookmark not defined. 102

111 APÉNDICE VI Plan de Desarrollo del Software 1. Introducción 1.1. Propósito El objetivo de este documento es presentar específicamente los detalles de la planificación a seguir para llevar a cabo el proyecto. Se tomarán en cuenta las características, el alcance, los objetivos, los entregables y los involucrados Alcance Este documento se limita a la descripción y análisis de distintos aspectos para la realización del ambiente de pruebas para aplicaciones basadas en SOA Definiciones, Acrónimos, y Abreviaciones Se hace referencia al Glosario y a la lista de acrónimos y abreviaciones Referencias Los documentos a los que se hace referencia son: - Glosario. - Especificación de Casos de Uso. - Documento de Visión. - Lista de Riesgos. 2. Vista General del Proyecto 2.1. Propósito, Alcance y Objetivos El resultado de este proyecto es un ambiente de pruebas dirigido a cualquier empresa o persona que esté interesada en realizar pruebas de estrés o de carga a sus aplicaciones realizadas en una arquitectura orientada a servicios. Además, de generar de reportes que muestren el desempeño general y especifico de las operaciones del servicio web. Los especialistas TI del departamento de software de la empresa podrán presentar este producto, el cual estará basado en la herramienta IBM Rational Tester for SOA Quality. De igual forma, se busca que el cliente puede probar sus aplicaciones directamente en este ambiente. El alcance está limitado a la entrega del demo y de la documentación necesaria para soportar su entendimiento. El desarrollo del proyecto se hará a través de la metodología Rational Unified Process (RUP). 103

112 APÉNDICE VI 2.2. Suposiciones y Restricciones El proyecto deberá ser completado en un lapso de cinco meses. La herramienta de prueba a utilizar debe ser IBM Rational Tester for SOA Quality. Será realizado por una sola persona Entregables del proyecto Los documentos a ser entregados están basados en la metodología planteada. Estos serán revisados y complementados en cada etapa del desarrollo: Visión Glosario Especificación de Casos de Uso Lista de Riesgos Plan de Desarrollo del Software Manual del Usuario Manual de Instalación 2.4. Evolución del Plan de Desarrollo del Software El Plan de Desarrollo del Software se revisará y actualizará en cada una de las fases del proyecto. 3. Organización del Proyecto 3.1. Participantes en el Proyecto El proyecto será llevado a cabo en la unidad de Ventas y Distribución del departamento de Software de IBM Venezuela. Los principales involucrados dentro del grupo de desarrollo son: Gerente de Proyecto: Representado por la Gerente de Ventas Técnicas del Grupo de Software en Venezuela. Especialista TI: Específicamente en la brand de Rational. Diseñador: Pasante de la USB Roles y Responsabilidades Rol Gerente de Proyecto Especialista TI Diseñador Responsabilidades Seguimiento del desarrollo del proyecto. Aprueba requisitos y funcionalidades. Levantamiento y análisis de requerimientos. Seguimiento del desarrollo del proyecto. Diseñar un ambiente de pruebas con la herramienta IBM Rational Tester for SOA Quality para aplicaciones en SOA, el cual quedará como un aporte importante para posteriores demostraciones y presentaciones de preventa. 104

113 APÉNDICE VI 4. Gestión del Proceso 4.1. Estimaciones del Proyecto El tiempo estimado de la realización del proyecto es de 20 semanas Plan del Proyecto Plan de las Fases El desarrollo del proyecto consta de cuatro fases. A continuación, se presenta el nombre, tiempo estimado representado en semanas y el número de iteraciones de cada una de ellas: Fase Duración (Semanas) Iteraciones Inicio Cuatro (4) 1 Diseño Seis (6) 1 Construcción Siete (7) 2 Transición Tres (3) 1 La fase de inicio culmina una vez se tengan los siguientes entregables: Planificación Inicial Documento de Visión Lista de Riesgos Especificación de los casos de uso iniciales Plan de Desarrollo inicial Glosario La fase de Elaboración será culminada cuando los siguientes entregables sean completados: Arquitectura Inicial -Vista lógica -Vista de Despliegue -Vista de Implantación -Vista de Casos de Uso La fase de Construcción culminará con la entrega de: Resultados de pruebas funcionales Análisis de los reportes generados La fase de Transición culminará con la entrega de toda la documentación más los manuales de instalación y del usuario. Además, del prototipo del ambiente de pruebas. 105

114 APÉNDICE VI Calendario del Proyecto Fase Inicio Elaboración Construcción Transición Actividad Duración (Días) Fecha de Inicio Fecha de Culminación Búsqueda de información 8 06/08/07 15/08/07 Documento de Visión 5 16/08/07 22/08/07 Identificación Inicial de Casos de 3 23/08/07 27/08/07 Uso Planificación de Riesgos 2 28/08/07 29/08/07 Plan de Desarrollo Inicial 2 30/08/07 31/08/07 Búsqueda y Análisis del archivo a 03/09/07 07/09/07 5 probar Actualización de los Casos de Uso 3 10/09/07 12/09/07 Revisión de documentación 3 13/09/07 17/09/07 Investigación de las herramientas 18/09/07 01/10/07 10 y tecnologías a usar Descripción de la arquitectura del 02/10/07 11/10/07 8 software Implementación del diseño 18 15/10/07 07/11/07 Análisis de resultados 10 08/11/07 21/11/07 Revisión de documentación 7 23/11/07 03/12/07 Manual del Usuario 3 04/12/07 06/12/07 Manual de Instalación 3 07/12/07 11/12/07 Revisión de documentación 7 13/12/07 20/12/07 Recomendaciones 1 21/12/07 21/12/07 Presentación del prototipo 1 A decidir con la gerente Cabe destacar que durante todo el ciclo, se realizaron actividades administrativas del proyecto correspondientes a la gestión de requerimientos, planificación, seguimiento y control, aseguramiento de la calidad y gestión de configuración 106

115 APÉNDICE VI APÉNDICE VI: MANUAL DE INSTALACIÓN 107

116 APÉNDICE VI Historial de Revisiones Fecha Versión Descripción Autor 23/09/ Versión preliminar del manual de instalación 10/01/ Se agregó el propósito del documento y se corrigieron detalles de redacción Yelimar Rebolledo Yelimar Rebolledo 108

117 APÉNDICE VI Manual de Instalación Este manual tiene como propósito describir los requerimientos necesarios para el buen desempeño de las herramientas y los pasos de instalación de cada una de ellas. Las herramientas son Installation Manager, IBM Rational Performance Tester e IBM Rational Tester for SOA Quality. Para la instalación de esta última es necesario que ya se haya llevado a cabo la de RPT y para poder instalar ésta se debe haber realizado la de Installation Manager. Por ello, se muestran los pasos de forma secuencial y es importante seguir ese orden. Requerimientos: Los requerimientos, en cuanto al hardware y software, se muestran a continuación: Sistema Operativo Windows 2000, Windows 2003, Windows XP Software - Windows 2000 con service pack 4 o mayor - Windows 2003 Standard Edition - Windows XP con service pack 2 o mayor Productos Microsoft Office (opcional): - Microsoft Word 2000, XP ó Microsoft Project 2000, XP ó Microsoft Excel 2000, XP ó 2003 Servidores de base de datos soportados: - IBM DB2 8.1, 8.2, Oracle 9.2, 10 - Microsoft SQL Server 2005 (SP1), 2000 (SP2, SP3, SP4), version 7 (SP4) -Microsoft Access versiones 2000, 2002 y 2003 Hardware - Procesador: Intel Pentium 4 1.5GHz o compatible - Memoria: 1GB RAM mínimo (2GB RAM recomendado) - Espacio en disco: aproximadamente 4.5 GB 109

118 APÉNDICE VI Pasos de Instalación para: - Installation Manager: 1. Al darle doble clic al instalador, aparecerá la pantalla de inicio del wizard de instalación del producto. Haga clic en Next: 2. Aparecerán las condiciones del acuerdo de licencia de software. Si está de acuerdo, elija la opción I accept the terms in the license agreement y haga clic en Next: 110

119 APÉNDICE VI 3. A continuación, se indicará la ruta por default, donde se instalarán los componentes. Si desea cambiarla, haga clic en Browse y seleccione la de su preferencia. Presione Next: 4. La instalación está lista para iniciarse. Presione Install: 111

120 APÉNDICE VI 5. Se mostrará el status de la instalación: 6. Se mostrará un mensaje de éxito. Clic Finish: 112

121 APÉNDICE VI - IBM Rational Performance Tester: 1. Al darle doble clic al instalador, aparecerá la pantalla de inicio del wizard de instalación del producto. Haga clic en Install IBM Rational Performance Tester (Includes Agent): 2. La instalación se realizará a través del IBM Installation Manager. Se mostrarán los paquetes que se instalarán, verifique que estén marcados. Haga clic en Next: 113

122 APÉNDICE VI 3. Aparecerán las condiciones del acuerdo de licencia de software. Elija la opción I accept the terms in the license agreement y haga clic en Next: 4. A continuación, se indicará la ruta por default del directorio de recursos compartidos. Si desea cambiarla, haga clic en Browse y seleccione la de su preferencia. Presione Next 114

123 APÉNDICE VI 5. Se mostrará la ruta por default, en la que se instalarán los componentes. Si desea cambiarla, haga clic en Browse y seleccione la de su preferencia. Presione Next: 6. Si desea que los paquetes se instalen como una extensión de una versión de Eclipse existente, marque la opción Extend an existing Eclipse y elija la ruta. Haga clic en Next: 115

124 APÉNDICE VI 7. Se mostrarán los idiomas en los que está disponible el producto. Escoja el de su preferencia. Déle clic en Next: 8. Se indicarán las características a instalar, verifique que estén seleccionadas las de IBM Rational Performance Tester. Presione Next: 116

125 APÉNDICE VI 9. Se mostrarán los tipos de instalación de IBM Rational Agent Controller. Por default, aparecerá marcada la opción Typical installation (for default settings). Haga clic en Next: 10. La instalación está lista para iniciarse. Haga clic en Install: 117

126 APÉNDICE VI 11. Se mostrará el status de la instalación. 12. Se pedirá la información del disco 2. Presione Browse y busque la ruta. Haga clic en Ok: 118

127 APÉNDICE VI 13. Se pedirá la información del disco 3. Presione Browse y busque la ruta. Haga clic en Ok: 14. Se mostrará un mensaje de éxito. Clic Finish: 119

128 APÉNDICE VI 15. Para instalar IBM Rational Tester for SOA, es necesario actualizar la versión. Para ello, abra IBM Installation Manager y presione Update Packages: 16. Aparecerá el grupo de Actualización de paquetes para buscar actualizaciones. Verifique que IBM Rational Performance Tester esté seleccionado. Haga clic en Next: 17. Se indicará el status de la búsqueda. 120

129 APÉNDICE VI 18. Se mostrarán las actualizaciones encontradas. Verifique que aparezca Version Haga clic en Next: 121

130 APÉNDICE VI 19. Aparecerán las condiciones del acuerdo de licencia de software. Elija la opción I accept the terms in the license agreement y haga clic en Next 20. La actualización está lista para iniciarse. Haga clic en Update: 21. Se mostrará el status de la instalación. 122

131 APÉNDICE VI 22. Se mostrará un mensaje de éxito. Clic Finish: - IBM Rational Tester for SOA Quality 123

132 APÉNDICE VI 1. Al hacer doble clic en el instalador, aparecerá la pantalla de inicio del wizard de instalación del producto. Haga clic en Install IBM Tester for SOA Quality v La instalación se realizará a través del IBM Installation Manager. Se mostrará los paquetes que se instalarán, verifique que estén marcados. Haga clic en Next: 3. Aparecerán las condiciones del acuerdo de licencia de software. Elija la opción I accept the terms in the license agreement y haga clic en Next: 124

133 APÉNDICE VI 4. Se mostrará la ruta por default donde se instalarán los componentes. Presione Next: 5. Se indicarán las características a instalar, verifique que esté seleccionada IBM Rational Tester for SOA Quality. Presione Next: 125

134 APÉNDICE VI 6. La instalación está lista para iniciarse. Haga clic en Install: 7. Se mostrará el status de la instalación. 126

135 APÉNDICE VI 8. Se mostrará un mensaje de éxito. Clic Finish: 127

136 APÉNDICE VII APÉNDICE VII: MANUAL DEL USUARIO 128

137 APÉNDICE VII Historial de Revisiones Fecha Versión Descripción Autor 17/12/ Versión preliminar del manual del usuario Yelimar Rebolledo 07/01/ Se agregaron imágenes al manual Yelimar Rebolledo 129

138 APÉNDICE VII Manual del Usuario El propósito de este documento es ofrecer una orientación de las principales funcionalidades de la herramienta IBM Rational Tester for SOA Quality. Está orientado a los Especialistas TI y a los clientes. 1. Crear un nuevo proyecto de prueba de desempeño Al abrir la herramienta, seleccionar File -> New -> Performance Test Project En el campo Project Name, colocar el nombre deseado y hacer clic en Finísh 2. Crear Nueva Prueba desde Grabación Seleccionar Web Service Recording using the Web Services Explorer, luego, darle clic al botón Next 130

139 APÉNDICE VII Seleccionar el proyecto y en el campo Test file name, el nombre que se quiera. Hacer clic en Next. Hacer clic en el botón Import para importar el WSDL. 131

140 APÉNDICE VII En la ventana que aparezca, en el campo From Directory, presione el botón Browse, seleccione el directorio deseado y déle clic en OK. Se mostrarán los WSDL, elija el que necesite. En el campo Into Folder, ingrese el proyecto con el que asociará el archivo. Configure las opciones que prefiera. Haga clic en Finish. Acepte los valores por defecto de Port and Timeout y presione Next. 132

141 APÉNDICE VII Seleccione I Accept en la ventana de advertencia y déle clic en Finish. 3. Grabar interacción con el Web Service Maximizar la ventana del Web Services Explorer, haciendo doble clic en la pestaña correspondiente. 133

142 APÉNDICE VII Seleccionar la operación a probar en la ventana de acciones, sección Operaciones. Ingresar la información según el campo. Presionar Go. Si se desea, repetir los pasos anteriores para evaluar las otras operaciones. Al terminar, minimizar el explorador haciendo doble clic en la pestaña del explorador. Hacer clic en el botón de stop, ubicado en la parte inferior a mano derecha de RPT. 134

143 APÉNDICE VII 4. Añadir un punto de verificación a una prueba existente En la vista Test Navigator, hacer doble clic en la prueba. En la sección Test Contents, expandir la operación a la que se le añadirá el punto de verificación. Seleccionar el valor que aparecerá debajo. 135

144 APÉNDICE VII Hacer clic al botón derecho, seleccionar Add! Equal Verification Point. Presionar el botón de guardar en la barra de herramientas. 5. Importar un Datapool desde un archivo CSV En la vista Test Navigator, hacer clic en el botón derecho de la prueba y seleccionar New! Datapool En la ventana que aparecerá, en el campo Name colocar el nombre para la agrupación de datos. Presionar Next. 136

145 APÉNDICE VII En el campo de la descripción, llenarlo con la información deseada. Hacer clic en Next. En CSV File, ingresar la ruta donde se encuentra el archivo. Se puede realizar a través del 137

146 APÉNDICE VII botón Browse, explorando las carpetas. Configurar las opciones adecuadas. Darle clic a Finish. 6. Añadir un Datapool a una prueba En la vista Test Navigator, hacer doble clic en la prueba. En la sección Test Elements Details de la pestaña Overview, expandir la operación a la que se le añadirá la agrupación de datos. Elegir uno de los valores resaltados, luego, hacer clic en la columna Value y presionar el botón para editar. En la ventana de editar, darle clic en el botón derecho al espacio en blanco, luego, seleccionar Substitute From! Datapool Variable. Presionar el botón Add Datapool. 138

147 APÉNDICE VII En la ventana para importar el datapool, seleccionarlo y presionar el botón Select. Seleccionar la columna a emplear, es decir, la que concuerda con el campo seleccionado anteriormente. Darle clic al botón Use column. 139

148 APÉNDICE VII Presionar Ok en la ventana de edición. Presionar el botón de guardar en la barra de herramientas. 7. Ejecutar una prueba y revisar el reporte En la vista Test Navigator, hacer clic del botón derecho sobre la prueba y seleccionar Run As!Performance Test 140

149 APÉNDICE VII Esperar hasta que el estatus de la prueba sea Completo. En la pestaña Performance Test Runs, clic derecho sobre la prueba y seleccionar Display Test Log. Se mostrará la información general de la prueba, por ejemplo, el veredicto. Presionar la pestaña de eventos. 141

150 APÉNDICE VII Hacer clic sobre el botón Select the verdict type to navigate. Seleccionar el estado de la prueba para aprobar el resultado. 8. Crear el plan de prueba de desempeño y configurar las características principales Seleccionar File! New! Performance Schedule. 142

151 APÉNDICE VII Elegir el proyecto al que será asignado. Ingresar el nombre. Hacer clic en Finish. En la sección Schedule Element Details, cambiar el número de usuarios. 143

152 APÉNDICE VII Seleccionar el grupo de usuarios 1 en la sección Schedule Contents. Darle clic al botón Add y elegir Loop. Cambiar el número de iteraciones en la sección Schedule Element Details. Si se quiere controlar la tasa de iteraciones, marcar esa opción. Se podrá configurar la medida de tiempo y el tiempo de espera entre ellas. 144

153 APÉNDICE VII Para agregar la prueba, darle clic al ciclo en la sección Schedule Contents. Luego, presionar Add! Test. Seleccionar la prueba deseada y hacer clic en Ok. Presionar el botón de guardar en la barra de herramientas. 9. Ejecutar el schedule y revisar los reportes En la vista Test Navigator, hacer clic del botón derecho sobre la prueba y seleccionar Run As!Performance Schedule 145

154 APÉNDICE VII Esperar hasta que el estatus sea Completo. En la parte inferior del gráfico, aparecen las pestañas correspondientes a los otros reportes. Para ver cualquiera de ellos, sólo hay que hacer clic sobre la deseada. 10. Exportar los resultados a un archivo CSV Ir a File! Export. 146

155 APÉNDICE VII Expandir Test y seleccionar Performance test run statistics. Presionar Next. 147

156 APÉNDICE VII Ingresar el nombre que se desea para el archivo o la ruta de un CSV existente. Por defecto, la ubicación del archivo es el workspace de la herramienta. Presionar Next. Elegir la corrida de la cual se quiere exportar los resultados. Presionar Next. 148

157 APÉNDICE VII Seleccionar las estadísticas que se quieren incluir en el archivo a exportar. Presionar Finish. 149

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

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

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

Más detalles

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

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

Más detalles

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

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

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

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

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

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

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

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

Glosario Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano

Glosario Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano Ministerio del Poder Popular para las Telecomunicaciones y la Informática Centro Nacional de Tecnologías de Información Glosario Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado

Más detalles

La aplicación práctica en el mundo empresarial de los estándares Web

La aplicación práctica en el mundo empresarial de los estándares Web La aplicación práctica en el mundo empresarial de los estándares Web El problema de la integración inter/intra empresas y la familia "XML" Enrique Bertrand XML Business Integration, Regional Director Software

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

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

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

SISTEMA DE ADMINISTRACIÓN DE CONSULTORÍA (SIAC)

SISTEMA DE ADMINISTRACIÓN DE CONSULTORÍA (SIAC) SISTEMA DE ADMINISTRACIÓN DE CONSULTORÍA (SIAC) Ing. Marianella Arrieche Gerente de Calidad y Consultoría Ing. Carlos Perkinson Director Caracas, Abril 2010 AMAZING GLOBAL DE VENEZUELA Como implantador

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Consideraciones para implementaciones BPM y EDA

Consideraciones para implementaciones BPM y EDA Consideraciones para implementaciones BPM y EDA Jesús Buriticá IBM Software Group Brand Architect jburitic@ve.ibm.com Agenda Manejando los conceptos sobre BPM y EDA Abordar una iniciativa BPM/EDA Algunos

Más detalles

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

Más detalles

IBM Rational Asset Manager

IBM Rational Asset Manager Inteligencia comercial para sus activos de software IBM Rational Asset Manager Aspectos destacados Acelera la prestación de servicios y mejora la dirección general interna del ciclo de vida SOA Acorta

Más detalles

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

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

Más detalles

MARCANDO LA DIFERENCIA

MARCANDO LA DIFERENCIA MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores

Más detalles

Gestión de calidad a lo largo del ciclo de vida de productos y aplicaciones

Gestión de calidad a lo largo del ciclo de vida de productos y aplicaciones IBM Software Gestión de ciclo de vida de productos y aplicaciones Junio 2011 Gestión de calidad a lo largo del ciclo de vida de productos y aplicaciones Soluciones IBM para un planeta más inteligente 2

Más detalles

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

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

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA

12 JUNIO 2014. Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 Rev.3: 05 Marzo 2015. 1 de 76. BN-MOF-2400-10-05 Rev.3 MOF DEPARTAMENTO DE INFORMÁTICA Rev.1: 07 Agosto 2014 Rev.2: 06 Octubre 2014 : 05 Marzo 2015 MANUAL DE ORGANIZACIÓN Y FUNCIONES DEPARTAMENTO DE INFORMÁTICA Aprobado mediante Resolución de Gerencia General EF/92.2000 N 020-2014, de fecha

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

Más detalles

Consultoría en Arquitectura Empresarial, SOA y de Software

Consultoría en Arquitectura Empresarial, SOA y de Software Consultoría en Arquitectura Empresarial, SOA y de Software Dentro de su propuesta de servicios de consultoría, HEINSOHN ofrece consultoría en planeación de tecnologías de información, donde se define a

Más detalles

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

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

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

Más detalles

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran:

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran: Desarrollo de aplicaciones y servicios web Cinxgler Mariaca Minda Cinxgler@udistrital.edu.co Presidente Capítulo de Computadores Rama IEEE Universidad Distrital Francisco José de Caldas Resumen: Este articulo

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

El desarrollo de aplicaciones

El desarrollo de aplicaciones e d i t o r i a l Entendiendo el desarrollo de los sistemas SOA María Consuelo Franky R. El desarrollo de aplicaciones orientadas y basadas en servicios, como estilo de arquitectura, emergió sobre la arena

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

Más detalles

Oracle Application Server 10g

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

Más detalles

Sistema de Gestión de Arquitectura Empresarial para la Banca

Sistema de Gestión de Arquitectura Empresarial para la Banca 2015 Sistema de Gestión de Arquitectura Empresarial para la Banca El manual refleja las bondades, alcances y funcionalidad del sistema. Se describe su alineación con los principales framework del mercado

Más detalles

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

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

Más detalles

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert con fecha 30 de noviembre de 2010 IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert Índice 1 Información general 2 Fecha de disponibilidad

Más detalles

Mantenimiento de usuarios y grupos Gestión de políticas y estándares Administración de aplicaciones Gestión de servidores Soporte técnico

Mantenimiento de usuarios y grupos Gestión de políticas y estándares Administración de aplicaciones Gestión de servidores Soporte técnico Somos una compañía del área de tecnología informática. Es nuestro objetivo el transformar ideas y necesidades en soluciones tecnológicas y negocios apropiados en beneficio de usted, nuestro cliente. Le

Más detalles

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT)

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT) CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO 6.1. Estructura Detallada del Trabajo (EDT) Un EDT es la agrupación orientada a entregables de los elementos del proyecto que organiza y define el total de los

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

Una puerta abierta al futuro

Una puerta abierta al futuro Una puerta abierta al futuro SOA E ITIL EN LA LEY DE ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS (LAECSP) por francisco javier antón Vique La publicación de la Ley de Acceso electrónico

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM Metodología BPM:RAD - Rapid Analysis & Design Capítulo extraído de El Libro del BPM 2011 Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Más detalles

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación Trabajo Final de Graduación para optar por el título Bachiller en Ingeniería en Computación Migración del Módulo de Inventario del Sistema Business Advance Víctor Guzmán Alfaro Carrera Ingeniería en Computación

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

WebServices bajo SOA. SOAagenda team Chile

WebServices bajo SOA. SOAagenda team Chile WebServices bajo SOA SOAagenda team Chile 1 Conceptos Servicio SOA Una tarea de negocio repetitiva validar Crédito Cliente, que cumple estándares SOA WebService Funcionalidades disponibles vía Web, implementadas

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar 1 Definir el problema/oportunidad Definir problema de negocio o la oportunidad de mejora utilizando el pensamiento sistémico. Mapa Conceptual Desarrollar soluciones alternativas Seleccionar la solución

Más detalles

Servicios de Mantenimiento y Soporte Técnico de IBM. Un enfoque innovador del mantenimiento y soporte técnico

Servicios de Mantenimiento y Soporte Técnico de IBM. Un enfoque innovador del mantenimiento y soporte técnico IBM Global Technology Services Mantenimiento y Soporte Técnico Servicios de Mantenimiento y Soporte Técnico de IBM Un enfoque innovador del mantenimiento y soporte técnico 2 Servicios de Mantenimiento

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

SUPLEMENTO EUROPASS AL TÍTULO

SUPLEMENTO EUROPASS AL TÍTULO SUPLEMENTO EUROPASS AL TÍTULO DENOMINACIÓN DEL TÍTULO Técnico Superior en Desarrollo de Aplicaciones Web --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Más detalles

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA)

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA) Espiñeira, Sheldon y Asociados * No. 12-2009 *connectedthinking Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción

Más detalles

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

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

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Setiembre 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN...1 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP...2 2.1 WORKFLOWS ESENCIALES DEL RUP...2

Más detalles

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 El problema: las aplicaciones tradicionales no le proveen la agilidad necesaria

Más detalles

UNIVERSIDAD SIMÓN BOLÍVAR

UNIVERSIDAD SIMÓN BOLÍVAR UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA EN COMPUTACIÓN DESARROLLO DE PROCESO DE SOLICITUD DE TARJETAS DE CRÉDITO MEDIANTE ARQUITECTURA SOA-BPM Por: Luis

Más detalles

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

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

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

Universidad Autónoma Metropolitana

Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Unidad Azcapotzalco División de Ciencias Básicas e Ingeniería Licenciatura en Ingeniería en Computación Propuesta de Proyecto Terminal Composición de servicios web para

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Caso de Desarrollo Universidad Técnica del

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN CAPÍTULO V PROPUESTA DE LA SOLUCIÓN 5.1 Introducción En los últimos tres años la entidad financiera ha venido sufriendo cambios que le han permitido crecer y pasar de ser una Sociedad Financiera a un Banco

Más detalles

SOA Governance. (Administración SOA) Luis Alberto Espinoza Bustamante

SOA Governance. (Administración SOA) Luis Alberto Espinoza Bustamante SOA Governance (Administración SOA) Luis Alberto Espinoza Bustamante 1 Agenda SOA Governance Algunas Problemas por Falta de Governance Quien: SOA Office (y Centro Competencia SOA) Que: Plan Inicial Como:

Más detalles

www.sis-monterrey.com

www.sis-monterrey.com www.sis-monterrey.com Antecedentes 4 SIS Organización SIS Monterrey Índice SIS Monterrey 5 Misión Visión Valores Factores de Diferenciación 6 Especialización en Negocios Factor Humano Confianza Oferta

Más detalles

Indice. www.soaction.com.mx. Antecedentes 2 SIS Organización SIS SOAction. SIS SOAction 3 Misión Visión Valores

Indice. www.soaction.com.mx. Antecedentes 2 SIS Organización SIS SOAction. SIS SOAction 3 Misión Visión Valores Indice Antecedentes 2 SIS Organización SIS SOAction SIS SOAction 3 Misión Visión Valores Factores de Diferenciación 4 Especialización en Negocios Factor Humano Confianza Oferta a la Vanguardia Tecnológica

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Orientación sobre el concepto y uso del Enfoque basado en procesos para los sistemas de gestión

Orientación sobre el concepto y uso del Enfoque basado en procesos para los sistemas de gestión Orientación sobre el concepto y uso del Enfoque basado en procesos para los sistemas de gestión Documento: ISO/TC 176/SC 2/N 544R2 Diciembre 2003 ISO 2003 Traducción aprobada el 2004-04-27 Prólogo de la

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

CAPÍTULO IV COMPARACIÓN DE LAS DOS PRINCIPALES HERRAMIENTAS ALM.

CAPÍTULO IV COMPARACIÓN DE LAS DOS PRINCIPALES HERRAMIENTAS ALM. CAPÍTULO IV COMPARACIÓN DE LAS DOS PRINCIPALES HERRAMIENTAS ALM. 4.1. ANÁLISIS COMPARATIVO DE LAS DOS HERRAMIENTAS ALM. Existen muchos factores que se debe tomar en cuenta al momento de elegir entre herramientas

Más detalles

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2005 1.0 Versión preliminar Horacio Nova 25/08/2005 1.0 Versión

Más detalles

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB]

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

IT Performance Management. Resumen Ejecutivo. IT Performance Management

IT Performance Management. Resumen Ejecutivo. IT Performance Management * IT Performance Management Resumen Ejecutivo Soluciones probadas para optimizar el desempeño de la organización de TI 1. IT Performance Management (ITPM) es...... la planeación, alineación y gobernabilidad

Más detalles

IBM InfoSphere Foundation Tools permite ofrecer información de confianza

IBM InfoSphere Foundation Tools permite ofrecer información de confianza ZP06-0517, con fecha 15 de diciembre del 2009 IBM InfoSphere Foundation Tools permite ofrecer información de confianza Índice 1 Visión general 2 Fecha de comercialización prevista 2 Requisitos previos

Más detalles

Catálogo de Servicios

Catálogo de Servicios Catálogo de Servicios Fecha: 14 de mayo de 2013 Índice 1 Presentación... 3 2 Servicios de Consultoría SQL Server... 4 2.1 Monitorización servidores SQL Server... 4 2.2 DBA Remoto... 5 2.3 Consolidación

Más detalles

Soluciones Tecnológicas

Soluciones Tecnológicas Soluciones Tecnológicas NOSOTROS Creamos IC en 1985 a fin de proveer a nuestros Clientes soluciones apropiadas y escalables en Consultoría de Negocios y en Tecnologías Informáticas. Durante más de dos

Más detalles

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio BPM Business Process Management Gestión de Procesos de Negocio Palabras Clave: BPM, Business Process Management, Workflow, Gestión de Procesos de Negocio, Reingeniería de Procesos, Optimización de Procesos,

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

Más detalles

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

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

Más detalles