Llegamos a ustedes gracias a:



Conversando con...

Alejandro Miralles, Gerente de Soluciones de Calidad HP Software

Las aplicaciones también tienen un ciclo de vida

[24/08/2011] Estamos acostumbrados a pensar en el ciclo de vida de un producto como aquellas etapas por las que pasan los dispositivos con los que tenemos una relación diaria. Una PC, por ejemplo, se aproxima a su retiro cuando su capacidad ya no basta para las tareas que desempeñamos; algo similar ocurre con las aplicaciones.

Estos productos no tangibles también pasan por un ciclo de vida que las empresas deben entender para poder administrarlo bien. Y es por ello que las empresas proveedoras se han ocupado de sistematizar el manejo de las distintas etapas por las que pasan las aplicaciones. Así, HP ha propuesto un ciclo de vida que transcurre por cuatro etapas: la planificación, que es el momento en el que el cliente evalúa sus objetivos; el desarrollo, cuando la empresa moderniza sus procesos actuales; la ejecución, cuando la aplicación desempeña sus funciones y recibe mantenimiento para su óptimo funcionamiento; y, finalmente, el retiro, cuando el ciclo termina y es necesario abrir paso a aplicaciones más modernas.
Todo este camino puede ser cubierto automatizadamente gracias a herramientas de Administración del Ciclo de Vida de la Aplicación (ALM, por sus siglas en inglés), y es precisamente de ello de lo que conversamos con Alejandro Miralles, Gerente de Soluciones de Calidad HP Software, cuando estuvo de paso por Lima hace unos días.
Alejandro Eseiza, gerente de Certificación TI de Telefónica Global Technology, y Alejandro Miralles, Gerente de Soluciones de Calidad HP Software.
Miralles nos presentó también a Alejandro Eseiza, gerente de Certificación TI de Telefónica Global Technology, que también estuvo de paso por Lima para presentar su caso a manera de caso de éxito de HP.
Con Miralles comenzamos hablando por lo general: por lo que podemos entender por ALM.
¿Por qué existe un ciclo de vida de un producto?
Miralles: En las áreas de servicios se ha buscado que los ciclos de vida de los productos se puedan replicar de alguna manera en los servicios. Hace cinco años se hablaba de salir de los trajes hechos a la medida en el mundo de los servicios o software, para ingresar a una forma de trabajo similar al de una empresa de manufactura. En ese contexto, uno puede reconocer muy bien el ciclo de vida de un producto que puede tocar, y lo que se ha buscado es que en el mundo de las aplicaciones y los servicios podamos también reconocer que existe una forma repetible de hacer el desarrollo de una aplicación que soporta un proceso de negocios.
Haciendo el símil con un producto tangible ¿se puede decir que las aplicaciones también se vuelven viejas?
Esto se va manifestando a través de los nuevos productos que va lanzando la competencia. Yo podría tener, por ejemplo, una aplicación que funcione en forma estable por mucho tiempo, y si alrededor no ocurre nada la aplicación podría seguir siendo válida e incluso moderna.
Pero como la tecnología va evolucionando me encuentro con que hay nuevas formas en que puedo ofrecer servicios a mis clientes; y si no lo tomo en cuenta, alguien más lo hará. En este caso, el envejecimiento pasa por una referencia, por un cambio tecnológico que va a ocurrir en el mercado. Ese cambio hace que me de cuenta que tengo que aumentar mis prestaciones, y cuando lo hago empiezo a darme cuenta que lo que tengo no me alcanza, no es suficiente, tengo que buscar los elementos para poder responder a esas necesidades y eso es lo que nosotros conocemos como el concepto de modernización de aplicaciones.
Las aplicaciones no envejecen porque cambien de color o porque no funcionen, sino porque el mercado evoluciona y uno tiene también que evolucionar.
Cuando uno se deshace de componentes tangibles como los servidores, por ejemplo, uno se preocupa de que no se vaya con ellos información importante. ¿Qué es lo que se tiene que tener en cuenta para poder cambiar una aplicación?
Hoy en día eso es uno de los stoppers para poder cambiar a aplicaciones superiores. Efectivamente, cuando dejo una aplicación debo asegurarme, en primer lugar, que lo nuevo que voy a usar cumpla con las prestaciones de lo que tenía.
Un gran desafío para la gente que hace migración de aplicaciones es el poder luchar contra 10 o 15 años de desarrollo de una aplicación antigua. Cuando construyo durante mucho tiempo una aplicación en una organización -es decir, funcionalidades muy particulares que esa organización necesita para trabajar- y quiero migrar a otra aplicación, me doy cuenta que en el periodo de seis meses o un año en el que voy a hacer la reconversión no voy a poder competir con todo lo que hice en 15 años.
Entonces lo primero que tengo que entender es cuáles son las funcionalidades críticas que esta aplicación debe tener para que el negocio siga funcionando. Lo segundo es que la información que he acumulado durante 15 años debo analizarla, y ver cuál debo dejar libre para la próxima aplicación y cuál debo dejar almacenada porque algún organismo regulador la pide, o cual debo desechar porque ya no me va a servir.
¿Es muy diferente si se tiene una aplicación hecha a la media que una empaquetada?
Desde el punto de vista del ciclo de vida no. Tal vez el desarrollo va a ser un poco más extenso, pero desde el punto de vista del ciclo de vida una aplicación in house o world class están sometidas a las mismas reglas. Y de hecho nuestras soluciones están ambientadas para soportar aplicaciones de ambos tipos.
En el caso de Telefónica, ¿cuál es la solución que implementó y con qué contaba antes?
Eseiza: Antes de estas herramientas lo que teníamos eran planillas Excel. Teníamos que buscar la mejora continua y llegar a producción con la mínima cantidad de defectos posible, y ello no se podía lograr con planillas de Excel. Con las herramientas de ALM, en cambio, uno puede empezar a cuantificar todos los problemas que se tienen en forma temprana antes de llegar a producción.
¿Cómo eligieron la solución que consideraron adecuada?
Hace cuatro años, cuando empezamos con el proceso de selección de las herramientas, básicamente lo que hicimos fue evaluar las herramientas de HP, la suite de herramientas de Rational -hoy IBM-, y un set de herramientas de otro proveedor.
Lo que buscábamos era herramientas de gobierno de la calidad del proceso de testing, de ejecuciones de performance, y por último de automatización de pruebas. Y obviamente que estas tres herramientas trabajen en forma conjunta.
Evaluamos las tres suites y la que más beneficios nos brindaban eran las herramientas de HP.
¿Cuáles fueron los mayores desafíos que se tuvieron que enfrentar durante la implementación?
En realidad, antes de la implementación el mayor desafío fue vender internamente la necesidad que teníamos de estas herramientas. Antes de asumir mi responsabilidad actual como gerente de testing me desempeñaba como gerente de producción, y como tal sabía lo que es sufrir cualquier cambio que pasara sin la correcta evaluación de calidad. Por ello, cuando pasé al área de calidad, deseaba que mi compañero, el nuevo gerente de producción, no sufriera los cambios en producción que yo había sufrido.
Pero ya una vez compradas las herramientas, el siguiente desafío fue administrar el cambio en la gente que trabajaba en el proceso de ciclo de vida del desarrollo. Las personas ya se encontraban acostumbradas a trabajar con planillas Excel, por lo que pasar a las nuevas herramientas -a pesar que éstas automatizaban su trabajo- fue una tarea que nos costó esfuerzo. Desde la implementación de las herramientas teníamos que cumplir con un proceso algo que antes no hacíamos porque no teníamos herramientas.
¿Se cumplieron con los plazos y los alcances que se habían determinado?
Las tres herramientas tuvieron ciclos diferentes. Habíamos definido que la herramienta de gobierno de testing debía implementarse en cuatro meses, pero el proyecto duró seis meses ya que, antes que nada, tuvimos que aprender a instalar las herramientas y capacitar a un grupo pequeño de referentes del área para aprender con las herramientas a definir nuestro proceso. Entonces, si bien nos llevó un poco más de tiempo este ciclo, cuando el resto de grupos se fue incorporando ya teníamos un proceso mejor definido.
En el caso de la automatización nos pasó algo similar. Empezamos a automatizar casos de prueba, pero como seleccionábamos los casos de prueba que más cambios tienen, en poco tiempo quedaban obsoletos. Entonces tuvimos que definir un proceso en el cual se revisaba en qué momento del ciclo de vida de un producto, debíamos cambiar esos casos de prueba para que puedan ser usados nuevamente en nuevos proyectos.
Y en el caso de la ejecución de performance prácticamente fue instantáneo. Tuvimos un cambio en producción que fue el cambio en la arquitectura del sistema; en principio íbamos a salir sin el análisis de performance, pero si hubiéramos salido sin ese análisis hubiéramos dejado a Movistar por un día sin operación. Si bien el proyecto se demoró, no tuvimos ningún impacto al momento de salir a producción.
¿Qué beneficios lograron?
En el caso de la ejecución de performance, que es lo último que comentaba, el hecho de automatizar distintos escenarios y poder ejecutarlos bajo distintas condiciones, lo que nos permite es evaluar distintas alternativas para definir cuál es la mejor arquitectura para llevar un cambio a producción.
La automatización de la prueba lo que te permite es no solo ganar tiempo al momento de hacer el testing de un proyecto, sino poder trabajar con ambientes más sanos, desde el punto de vista de que cuando hacemos la prueba ya tenemos ejecutadas un conjunto de pruebas que garantizan que el ambiente es el adecuado al momento de realizar el testing.
¿Se tuvo que calcular un ROI para poder vender la idea internamente?
Si, habíamos hecho un ROI, pero lo más importante fue demostrar cuáles eran las ventajas de saber la calidad de los desarrollos.
¿Desea agregar algo?
Miralles: Lo que estamos proveyendo al mercado como HP son un conjunto de soluciones para soportar el ciclo de vida de una aplicación desde la gestión de la demanda hasta el retiro, pasando por el desarrollo y el deployment. En ese contexto tenemos una suite de soluciones capaz de soportar ese ciclo end to end.
Con todo esto pretendemos ayudar a nuestros clientes a tener mayor control del riesgo de las aplicaciones que hoy día liberan para soportar su negocio.
Jose Antonio Trujillo, CIO Perú