LIBRO BLANCO | Noviembre de 2014

Virtualización de servicios para eliminar las limitaciones del desarrollo y las pruebas del software

Índice

ca.com/es2 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

Resumen ejecutivo 3

Sección 1: Creación de un entorno “vivo” 4simulación de sistemas dependientes en entornos de desarrollo y pruebas

Sección 2: Habilitación del desarrollo y la realización de pruebas en paralelo 5equipos de desarrollo y pruebas trabajando de forma simultánea

Sección 3: Manipulación de los datos de pruebas para dependencias fuera del alcance 6La ausencia de datos de capas inferiores ya no es un problema

Sección 4: Compatibilidad con plataformas y tecnologías heterogéneas 8creación de un entorno verdaderamente completo

Sección 5: Conclusión 10primeros pasos por el buen camino

resumen ejecutivo

ca.com/es3 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

RetoLa creciente complejidad de las aplicaciones, junto con unas organizaciones cada vez más dispersas geográficamente, significa que los equipos se enfrentan a una avalancha de cuellos de botella en sus esfuerzos por ofrecer resultados. algunos ejemplos de cuellos de botella o limitaciones incluyen el acceso a entornos de mainframe o de pruebas de erp, falta de datos de pruebas, acceso a sistemas de terceros y limitaciones de presupuestos. a menudo, las limitaciones las crean los equipos de desarrollo en paralelo que buscan acceder a los mismos entornos. con frecuencia, los equipos intentan copiar un entorno completo en un laboratorio de pruebas o bien optan por imitar sistemas eficaces codificando sus propias versiones para realizar pruebas. esto puede convertirse en una tarea costosa y que consume mucho tiempo.

Oportunidaden esencia, la virtualización de servicios (service virtualization, sv) consiste en convertir en producto la práctica de reproducir entornos de desarrollo y pruebas por imitación y completarlos con código auxiliar, con un nivel de realismo y contexto suficiente para acelerar el desarrollo, mientras que las pruebas se adelantan dentro del ciclo de vida. de esta forma, se pueden adelantar los procesos de integración y publicación, con un mejor nivel de calidad y menos riesgos.

Ventajasa continuación, se enumeran una serie de capacidades que su organización debe exigir a una solución de virtualización de servicios. estas permitirán que los equipos ampliados de la organización hagan llegar al mercado más rápidamente aplicaciones de alta calidad, con menores costes y riesgos. entre ellas, se incluyen las siguientes:

ofrece la posibilidad de trabajar en el desarrollo en un entorno más realista y “vivo”.

desarrollo de más calidad y pruebas de sistema/regresiones más eficaces.

posibilita el desarrollo y la realización de pruebas en paralelo.

reduce la duración de los ciclos, detecta los defectos con más antelación, permite utilizar los recursos de forma eficiente.

virtualiza los datos de pruebas para sistemas que se encuentren fuera del alcance.

configuración y desmontaje más veloces, más estabilidad para la automatización de las pruebas.

Hace posibles entornos de alto rendimiento. mejor nivel de realismo y mayor cantidad de pruebas de rendimiento a un coste infinitamente menor.

dado que el desarrollo y la puesta a prueba de aplicaciones no es una isla separada de las demás actividades, también es fundamental que las soluciones de virtualización de servicios proporcionen un sustrato “neutro” en lo que a proveedores y distribuidores respecta, que admita las herramientas preferidas empleadas por los equipos. La virtualización de servicios debe proporcionar entornos objetivo que funcionen junto con las soluciones que haya instaladas para controlar el ciclo de vida de las aplicaciones, como la gestión de pruebas, las funciones de gestión de defectos y seguimiento de problemas, así como con los productos de virtualización de laboratorios de pruebas y el hardware de vanguardia que haya presentes en el entorno.

ca.com/es4 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

Sección 1: Creación de un entorno “vivo”

Simulación de sistemas dependientes en entornos de desarrollo y pruebasa medida que el desarrollo de aplicaciones tiende a adoptar enfoques con arquitecturas orientadas a servicios y compuestas por más elementos, se hace necesario que los equipos simulen una variedad mucho mayor de sistemas situados en sentido ascendente y descendente en su entorno de desarrollo y pruebas. La virtualización de servicios debe aplicarse en cualquier capa (o entre cualesquiera capas) donde existan dependencias, para conseguir un entorno lo más realista y “vivo” posible.

en el enfoque convencional, los equipos intentan avanzar con su propio desarrollo de componentes, completando con código auxiliar solamente el siguiente sistema en sentido descendente.

por ejemplo, si yo me dedicase a desarrollar una interfaz de usuario web, elaboraría un fragmento de código auxiliar que representaría un par de respuestas que previsiblemente recibiría de la capa situada inmediatamente por debajo (es decir, el servicio web). a continuación, los desarrolladores del servicio web podrían crear código auxiliar para representar las capas de esb subyacentes o tratar de imitar algunas solicitudes que los usuarios enviarían a través de la interfaz de usuario web. por desgracia, este proceso manual nunca es suficiente para encapsular los múltiples tipos de conexiones y datos que hay comprendidos dentro de las arquitecturas de software de empresa. además, si aún no hay una interfaz de usuario codificada, pueden no estar disponibles en absoluto, como se ve más abajo.

La alternativa es que, cuando los equipos trabajan con escenarios de datos reales y comportamientos también reales que se hayan capturado como servicios virtuales, se logra un nivel de productividad más alto, puesto que el entorno resultante es mucho más realista y está mejor actualizado que los conjuntos de códigos auxiliares, los cuales hay que codificar y mantener manualmente.

por lo tanto, la técnica fundamental que hace posibles los entornos realistas y “vivos” es la automatización de la creación de servicios virtuales y del mantenimiento de los datos. esto permite que los equipos de desarrollo sean mucho más productivos gracias a los entornos realistas de laboratorios virtuales, aunque la interfaz de usuario esté incompleta. al mismo tiempo, se requiere menos tiempo para crear o modificar los códigos auxiliares.

Sistema endesarrollo

Sistema endesarrollo

Entorno de virtualización de servicios realista:Antes y después

Códigoauxiliar 1

Códigoauxiliar 2

Especi�cacionesincorrectas

Especi�caciones Una reunión Comportamientocaptado real

Automatización

Servicios virtuales

Varias situacionesde datos reales

Datos demuestra

Solo 1escenario dedatos de 100

No disponible"Hay que esperar"

Pérdida de un 30-60 %de productividad

Ilustración A.

ca.com/es5 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

beneficios esperados:•capacidad para iniciar el desarrollo a pesar de que el sistema de interfaz no esté disponible

•reducción de la duración del ciclo para la ejecución de pruebas

•capacidad para mejorar la cobertura de las pruebas, gracias a la menor dependencia de los datos respecto a otras aplicaciones y al tiempo disponible para las pruebas

•mejora de las pruebas unitarias con un esfuerzo menor

•mejora de la calidad del código, gracias a la ampliación de la cobertura de las pruebas y de las pruebas de regresión

•capacidad para crear un simulador rápidamente, que requiere un esfuerzo menor de mantenimiento

Sección 2: Habilitación del desarrollo y la realización de pruebas en paralelo

Equipos de desarrollo y pruebas trabajando de forma simultáneaLa segunda capacidad fundamental de una solución de virtualización de servicios consiste en permitir que el desarrollo y las pruebas se efectúen en paralelo. cuando los equipos de desarrollo y pruebas trabajan simultáneamente, el ciclo de vida total del software alcanza un nuevo nivel de eficacia y eficiencia. Las soluciones nuevas se pueden implantar de forma muy ventajosa para la organización.

cuando el desarrollo y las pruebas trabajan en paralelo, los servicios virtuales actúan como elemento coordinador entre el sistema en desarrollo y el sistema en pruebas, de forma simbiótica. en el ejemplo que se muestra a continuación, se ve a un equipo que está desarrollando un servicio de gestión de pedidos (oms), mientras que el equipo de la parte superior está desarrollando y poniendo a prueba una aplicación de tienda electrónica.

Proceso de desarrollo en paralelo

Tienda electrónica

Servicio de gestión de pedidos

Capturar y actualizar conformea las especificaciones

Actualizar modelo medianteseguimiento de compilación nueva

Actualizar modelo medianteseguimiento de compilación nueva

Utilizar serviciosvirtuales o activossegún se precise

Evaluación Evaluación Evaluación

Ilustración B.

6 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

se captura un servicio virtual a partir del sistema oms existente, como back-end inicial para las pruebas de la tienda electrónica. a continuación, mientras continúan las pruebas, el equipo encargado de la tienda electrónica puede comunicar los requisitos inesperados o relativos a nuevas respuestas, en forma de solicitudes de servicios virtuales que llegan como comentarios y, en esencia, se convertirán en el siguiente conjunto de requisitos para desarrollar. Los ciclos de pruebas y desarrollo que tienen lugar en paralelo prosiguen su aceleración, ya que con cada nueva compilación se produce una iteración de las actualizaciones del modelo de servicio virtual, y los comentarios llegan cada vez más veloces.

una solución de desarrollo en paralelo que sea perfecta permite que los equipos ejecuten los componentes del software sobre los servicios activos donde están disponibles, son funcionalmente robustos y están sincronizados con los datos. en aquellos casos donde los equipos aún no dispongan de servicios que soporten correctamente el componente, pueden volver inmediatamente a los servicios virtuales. La capacidad de cambiar tan fácilmente y poder elegir un sistema en sentido descendente totalmente virtual y a través de servicios virtuales o elegir el sistema en vivo (sabiendo que siempre es posible dar marcha atrás si la compilación se bloquea o si hace falta un nuevo escenario de datos) es una característica muy importante para contar con una capacidad robusta de desarrollo en paralelo.

esa práctica de generar y actualizar entornos de laboratorio de software, ¿está en contacto con la realidad? en esencia, el paralelismo de la virtualización de servicios hace realidad lo que se esperaba del modelo de desarrollo ágil en los entornos de software complejos, gracias a que se coordinan con gran precisión los ciclos de pruebas y desarrollo con los objetivos de publicación de versiones del negocio, por medio de publicaciones iterativas rápidas y constantes.

beneficios esperados:• incremento gradual de la velocidad de los ciclos de pruebas y desarrollo

•auténtica capacidad de respuesta de las iteraciones con modelo ágil, con integración continua y coordinación de las compilaciones ajustándose a los resultados de las pruebas y los requisitos de la empresa

•menor carga de trabajo del control de versiones, con compatibilidad con aLm y las herramientas de gestión de desarrollo existentes, para que ganen en eficacia

•mayor tasa de aceptación y resolución de los problemas antes de pasar a la fase de producción

•obtención de puntos funcionales hasta un 60 % más rápido, con más calidad y precisión respecto a las especificaciones

Sección 3: Manipulación de los datos de pruebas para dependencias fuera del alcance

La ausencia de datos de capas inferiores ya no es un problemacada equipo que necesite aprovisionar un laboratorio para sus actividades dispone de sistemas y datos asociados que se consideran incluidos dentro del alcance, así como de otros que están fuera del alcance. un sistema incluido en el alcance es aquel donde se realiza un cambio en el desarrollo o sobre el cual se llevan a cabo pruebas directamente. un sistema situado fuera del alcance es aquel que resulta necesario para dar soporte a un sistema incluido en el alcance, pero no es un objeto sobre el que se efectúe el trabajo de desarrollo ni las pruebas. se considera que es una dependencia. es necesario, pero no es el objeto en el que se centran las actividades de desarrollo o de realización de pruebas.

en este escenario, tenemos a un equipo que está desarrollando y poniendo a prueba un motor de reservas. están intentando agregar los escenarios de datos introducidos por los usuarios y recibidos de capas inferiores, pero no disponen de una llave maestra que les abra todas las puertas.

La solución más obvia es la práctica habitual en los sistemas de gestión de datos de prueba: importar datos directamente desde los sistemas incluidos en el alcance, y generar código auxiliar o imitar los sistemas situados fuera del alcance, tratando de escribir el código e importar un par de líneas de datos. estas representarán las respuestas que previsiblemente facilitarán las dependencias situadas fuera del alcance. estos fragmentos de código auxiliar son delicados por naturaleza y los desarrolladores adoptan el método más conveniente para simular los escenarios de respuestas o funcionalidades básicas que esperan encontrarse. sin embargo, dado que el software distribuido actual es cada vez más complejo, el esfuerzo que requiere elaborar y mantener dichos fragmentos de código auxiliar se ha vuelto demasiado costoso.

ca.com/es

7 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

¿son datos reales o virtuales?Lo que necesitamos es un método para simular cómo actúan los sistemas fuera del alcance con inteligencia suficiente para que el sistema situado dentro del alcance crea que se está comunicando con el sistema en vivo, aunque en realidad no sea así.

La virtualización de servicios aborda esto haciendo que todos los datos que faltaban por estar situados más allá del alcance del sistema ya no sean un problema, ya que automatiza la captura de los escenarios relevantes situados en sentido descendente y fuera del alcance.

Herramientade gestión

de datos deprueba

Datos deentrada

Motor dereservas

Oracle

SQL Operaciones SaaS

CRS GDS

GDS SAPFF

Datos fuera de alcance no cubiertos por el sistema de gestión de datos de prueba

Datos deentrada

Motor dereservas

Oracle

SQL Operaciones SaaS

CRS GDS

GDS SAPFF

Virtualizar datos de pruebas fuera del alcance

Ilustración C.

Ilustración D.

ca.com/es

ca.com/es8 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

el ejemplo del estado final del sistema de gestión de datos de prueba virtualizado que vemos aquí incluso parece demasiado sencillo. pero así es realmente como interactúa el proceso de realización de pruebas con las dependencias externas o situadas fuera del alcance. Los modelos virtuales permiten que todos los equipos puedan acceder bajo demanda a los conjuntos de datos que sean relevantes para los sistemas puestos a prueba. esos datos cubrirán un espectro de escenarios de datos válidos casi infinitos para dar soporte a las necesidades de pruebas de regresión y de rendimiento de gran volumen.

Las capacidades de la virtualización de servicios deben incluir mecanismos para incorporar al entorno de desarrollo y laboratorio de pruebas todos los sistemas necesarios. se incluyen aquí el aprovisionamiento de datos de los sistemas situados fuera del alcance y el mantenimiento de los datos de transacciones con estado cuando haya flujos de trabajo sostenidos que las hagan pasar por distintos sistemas. por ejemplo, simular que cambian valores como fechas o totales acumulados en una transacción a largo plazo, para que estos tipos de flujos de trabajo complejos se puedan validar con el nivel de detalle preciso.

beneficios esperados:•eliminación de los retrasos debidos a la carencia de datos actuales o la imposibilidad de acceder a sistemas fuera del

alcance

•disponibilidad de escenarios de pruebas válidos, 24 horas al día y 7 días a la semana, para varios equipos de desarrollo y pruebas

•ausencia de conflictos sobre los datos de prueba o la invalidación de las actividades de otros equipos al sobrescribir o modificar datos en los sistemas

• impacto mínimo o inexistente sobre los sistemas activos esenciales

•soporte para las transacciones “con estado”, que permite la compatibilidad con procesos complejos que atraviesan varias capas de tecnología y necesitan mantener valores específicos, como fechas, id de clientes, etc.

•reducción del tiempo necesario para las configuraciones y reinicios de datos hasta en un 90 %, recortando la duración total de los ciclos de vida de pruebas en un 40-60 %

Sección 4: Compatibilidad con plataformas y tecnologías heterogéneas

Creación de un entorno verdaderamente completoHace poco visité al equipo encargado de la arquitectura de uno de los mayores bancos mundiales. allí, escuché una estadística sorprendente. un caballero anunció que su sistema de gestión de activos de hardware indica que el banco tiene dentro más servidores implementados que empleados a sueldo. cada equipo de proyecto justifica los gastos de sus propias actividades de desarrollo, de la realización de pruebas, de la preproducción y del hardware de producción. casi todas las aplicaciones que se utilizan actualmente en el banco tienen a su espalda, como mínimo, estos cuatro entornos. aunque en muchos casos, transcurren meses e incluso años entre las distintas publicaciones por el mantenimiento o los cambios en dichas aplicaciones.

Lo irónico es que el desafío más difícil que afronta la mayoría de los entornos de preproducción estriba en que nunca son el sistema completo. un equipo de proyecto puede adquirir cualquier cantidad de servidores y utilizarlos para replicar parte del hardware o de los componentes sobre las máquinas virtuales a las que pueda acceder. pero aunque todos los equipos se encargasen de asignar su propio presupuesto de hardware, seguirían empleando meses y meses del ciclo de desarrollo esperando a disponer de acceso y accediendo de forma ineficaz a recursos de sistemas compartidos.

en los entornos de las ti de empresa, lo más común son los sistemas heterogéneos. por lo tanto, debería aplicarse la virtualización de servicios para virtualizar todas las dependencias que puedan afectar al sistema sometido a pruebas (sut). aquí se incluye el tráfico web (Http), los servicios web (soap/XmL), las capas de integración y esb (Jms, etc.), así como la simulación de transacciones y conexiones con los mainframes (cics, corba, etc.), las bases de datos (Jdbc, etc.) y los servicios de terceros que haya subyacentes.

ca.com/es9 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

dado que todos los puntos de conexión de la arquitectura del software representan un potencial punto de cambio y presentan un riesgo de sufrir errores, es esencial que la virtualización de servicios proporcione un método mejor para que los equipos puedan “virtualizar todo lo demás”, con lo que se aislarían de las dependencias respecto a estos componentes heterogéneos.

Hay cientos de laboratorios de preproducción que, por medio de la virtualización de servicios, se congregan y fusionan en una única infraestructura, mucho más sencilla de gestionar, con aprovisionamiento basado en software bajo demanda para cualquiera de los entornos que sean necesarios. Los proyectos que no estén sufriendo cambios ya no consumirán energía, ni generarán calor ni ocuparán espacio físico. se capturan y eliminan las dependencias. en lugar de necesitar acceso al sistema activo para la partición del mainframe, el equipo puede aprovisionar un servicio virtual del sistema de gestión de información del cliente, trabajando bajo demanda.

beneficios esperados:•prestación de servicios más rápida, gracias a que todos los equipos de desarrollo y pruebas tienen acceso a entornos

de laboratorio aislados 24 horas al día, 7 días a la semana

•reducción del coste de la infraestructura de preproducción convencional, que comporta un ahorro potencial de más de 20 millones de dólares anuales para empresas de gran tamaño

•eliminación de las tarifas y los costes del servicio por acceder a sistemas remotos

•posibilidad de que los equipos adelanten las pruebas, y creen compilaciones de calidad con respecto a la integración de sistemas y el desarrollo de componentes mucho antes de las actividades de puesta a prueba de la aceptación de los usuarios convencionales. reducción del tiempo necesario para las configuraciones y reinicios de datos hasta en un 90 %, recortando la duración total de los ciclos de vida de pruebas en un 40-60 %

Hay que tener en cuenta también que la heterogeneidad no solo afecta a los activos que se virtualizan, sino también a las herramientas del nivel de procesamiento que los equipos utilizan para colaborar. es esencial que las soluciones de virtualización de servicios proporcionen un sustrato “neutro” a los proveedores para las herramientas que los equipos prefieran y utilicen. La virtualización de servicios debe proporcionar entornos objetivo que funcionen junto con las soluciones que haya instaladas para controlar el ciclo de vida de las aplicaciones, como la gestión de pruebas, las funciones de gestión de defectos y seguimiento de problemas, así como la gestión de los datos de pruebas, los productos de virtualización de laboratorios de pruebas y el hardware de vanguardia que haya presentes en el entorno.

MAINFRAME DATOS HEREDADO EXTERNO

ESB

(SUT)

(SUT)Sistema en

pruebas

Sistema enpruebas

Ilustración E.

10 | Libro bLaNco: capacidades cLave de uNa soLucióN de virtuaLizacióN de servicios

ca technologies (NasdaQ: ca) crea software que impulsa la transformación de las empresas y les permite aprovechar las oportunidades de la economía de las aplicaciones. el software se encuentra en el corazón de cada negocio, en todos los sectores. desde la planificación hasta la gestión y la seguridad, pasando por el desarrollo, ca trabaja con empresas de todo el mundo para cambiar la forma en que vivimos, realizamos transacciones y nos comunicamos, ya sea a través de la nube pública, la nube privada, las plataformas móviles, los entornos de mainframe o los entornos distribuidos. más información en ca.com/es.

Comuníquese con CA Technologies en ca.com/es.

copyright © 2014 ca. todos los derechos reservados. todas las marcas y nombres comerciales, logotipos y marcas de servicios a los que se hace referencia en este documento pertenecen a sus respectivas empresas. el propósito de este documento es meramente informativo y ca no se responsabiliza de la precisión e integridad de la información en él contenida. en la medida de lo permitido por la ley vigente, ca proporciona esta documentación “tal cual”, sin garantía de ningún tipo, incluidas, a título enunciativo y no taxativo, las garantías implícitas de comerciabilidad, adecuación a un fin específico o no incumplimiento. ca no responderá en ningún caso de las pérdidas o daños, directos o indirectos, que se deriven del uso de esta documentación, incluidas, a título enunciativo y no taxativo, la pérdida de beneficios, la interrupción de la actividad empresarial, la pérdida del fondo de comercio o la fuga de datos, incluso cuando ca hubiera podido ser advertida con antelación y expresamente de la posibilidad de dichos daños. cs200-94676_1114

Sección 5: Conclusión

Primeros pasos por el buen caminopiense cuántas veces ha ido junto al responsable de las pruebas o del desarrollo para plantearle la siguiente pregunta: “¿por qué no se entregó el proyecto en la fecha que se había anunciado?”. La respuesta es que el retraso se debe siempre a otros equipos, sus promesas incumplidas y las dificultades que no lograron superar. He aquí algunos ejemplos con los que hemos estado relacionados y que yo mismo he vivido en primera persona:

•“claro, pero es que se suponía que nosotros recibiríamos la compilación del nuevo sistema de gestión de pedidos el mes pasado y resulta que llegó la semana pasada”.

•o también: “es verdad, pero cada compilación nueva del sistema de gestión de pedidos traía novedades que hacían falta, si bien también destrozaba otros componentes que ya teníamos funcionando bien”.

•otra más: “es cierto, pero el código auxiliar que me facilitó el otro equipo para la gestión de pedidos solamente tiene un perfil de cliente, así que no puedo crear ni probar ninguno de los demás escenarios que hacen falta a toda costa para finalizar el proyecto”.

al final, no podemos finalizar nuestro trabajo hasta que los demás compañeros acaben con el suyo, del cual dependemos. “sí, pero es que...”. cada equipo asociado a una aplicación compuesta debe disponer de libertad para crearla en su propio laboratorio a partir de la infraestructura, trabajando bajo demanda. es inevitable que se generen dependencias en el seno del equipo. de ahí que las capacidades de virtualización de servicios sean fundamentales. cada equipo tiene libertad para tomar las especificaciones de sus dependencias descendentes correspondientes y crear el estado final objetivo que se prevé para dichas dependencias, incluso antes de que sea necesario contar con la primera versión de estas.

La virtualización de servicios proporciona una plataforma esencial para el desarrollo y la puesta a prueba del software para empresas. a la hora de planificar una estrategia para implantar la virtualización de servicios, hay muchos más detalles que considerar, especialmente desde la vertiente organizativa. ¿Quiénes contribuyen a la solución y quiénes consumen sus servicios? ¿Quién es el propietario y gestiona los servicios virtuales dentro de la organización extensa de equipos y socios? para equilibrar correctamente el enfoque de la virtualización de servicios será preciso tener en cuenta no solo los detalles técnicos, sino también los aspectos operativos que puedan garantizar del mejor modo que el sistema sea adoptado de forma generalizada y arroje buenos resultados.