Experiencia 2: Caso de Éxito
Cambio en el modelo de Gestión del Ciclo de Vida de aplicaciones bancarias
Partiendo de un sistema de Gestión de Ciclo de Vida Ad hoc del cliente, se realizó con éxito la integración del nuevo modelo elegido por la entidad, para la Gestión del Ciclo de Vida y Control de Versiones del Software.
El día a día de las entidades financieras, desvió la visión y objetivos marcados por negocio (disponer de un software único para todas las entidades). Ello conllevó al incremento de costes de desarrollo, hecho que contradecía los objetivos fundacionales de la organización.
Se evaluó el estado y se propuso un plan de acción para la recuperación efectiva del modelo inicial de Gestión de Configuración esperado por la organización.
Como apoyo al repositorio de las herramientas vigentes, se creó un modelo de gestión específico con visión de Software Único, que consiguió cumplir con los objetivos marcado por la organización y proveer a las entidades financieras del modelo de gestión que esperaban.
ESCENARIO DE PARTIDA
El cliente contaba con una reconocida herramienta de mercado, la cual estaba mal configurada, por falta de conocimiento del personal técnico de soporte encargado de su mantenimiento.
Fueron rediseñados, erróneamente, procesos y procedimientos específicos de control de la herramienta, debido al desconocimiento de las distintas características y funcionalidades que proporcionaba el fabricante del software. Este hecho, tuvo como consecuencia, la incorporación al modelo de Gestión de Configuración y Ciclo de Vida del software, de múltiples desarrollos Ad Hoc apoyados en distintos lenguajes de programación, herramientas y procedimientos, que intentaban cubrir estas funcionalidades.
El repositorio del Software estaba desnivelado, es decir, no existía correspondencia con el software existente en Producción y sus distintas versiones almacenadas, debido a acciones manuales efectuadas a lo largo del tiempo.
El despliegue del software en los entornos, no se realizaba cuando se solicitaba y no se notificaban los cambios de estado (fallida o implementada) en la herramienta y al usuario, tras una implantación del Software. No existía una marcha atrás (roll back) automática en Producción en caso de resultados no esperados, el software se reimplantaba desde el nivel más bajo del Ciclo de Vida.
Los entornos de pruebas estaban en desuso por mala configuración de su arquitectura.
ESCENARIO FINAL
Nuestro personal técnico, elaboró un plan de proyecto por fases, identificando los elementos críticos que debían ser rápidamente abordados.
Como primer punto a resolver, se planteó la resolución de incidentes en la herramienta debidos a mala configuración. Fue rediseñada y modelada según los estándares del fabricante y ajustada a las necesidades del cliente. Se permitió de este modo, el acceso a todas las funcionalidades que aportaba, se restablecieron los mecanismos de comunicación de cambio de estado esperado por los usuarios.
Como apoyo al repositorio con el que contaba la herramienta, y que de forma estándar no cubría la funcionalidad que el cliente requería (software único para la distintas entidades que gestionaba), se creó una aplicación, con apoyo en DB2 y en los metadatos propios del producto, desde donde se proporcionó al usuario la funcionalidad requerida. Como adición a esta aplicación, se rediseñaron mecanismos en la herramienta, para el control de versiones efectiva en el nuevo modelo. Se automatizaron todos los procedimientos necesarios para el control del software.
Los entornos de Test fueron re abastecidos y homologados con el software necesario para la ejecución de las pruebas de usuario y su uso fue estandarizado en la organización.
La marcha atrás automática en Producción (Roll Back) fue implementada con éxito.
