Actualización 2023
Este artículo se escribió originalmente a finales de 2018. Ahora, en 2023, se informará más. Actualización de abril de 2023 en Computer Weekly
Lo que sabemos ahora es que hubo "algunos problemas", es decir, errores que afectaron a diferentes grupos de clientes de diferentes maneras. Les llevó al menos 7 meses resolverlos. Sólo podemos estimar el número total de errores, pero es probable que esté en el rango de 4 a 140. Sabemos esto porque hay al menos 4 escenarios de falla reportados y la cantidad más probable de errores que se pueden reparar en un sistema de producción de uso intensivo es aproximadamente 1 por día, independientemente del tamaño del equipo.
Costo de la evaluación de la calidad
Le costó a TSB £32,7 millones en compensación a los clientes, más una multa de £18,9 millones y podemos estimar alrededor de £3,2 millones de esfuerzo técnico y un impacto adicional en el personal de servicio al cliente de aproximadamente £52 millones (permitiendo 1 llamada a £10 por cliente). Luego está el costo de oportunidad de tener que resolver esto en lugar de hacer avanzar al banco. Y finalmente el banco habrá perdido algunos clientes por esto.
El coste total estimado parece superar los 100 millones de libras esterlinas. Lo que nos da un coste por defecto de alrededor de 1 millón de libras esterlinas por defecto no descubierto antes de su puesta en marcha.
¿Cómo se podría evitar?
Conocer el potencial de defectos de un proyecto de software puede informarle cuántos defectos necesita encontrar antes de estar listo para comenzar a funcionar. Es predecible. Utilizando diversas técnicas que giran en torno a conocer el tamaño funcional del software, los posibles defectos, las áreas de riesgo de defectos, las tasas de descubrimiento de defectos, la cobertura de las pruebas y más, podemos determinar qué tipos de pruebas se necesitarán y cuántas pruebas serán suficientes para lograr resultados satisfactorios. calidad. La cuestión es que esa terrible situación era a la vez predecible y evitable. También es interesante mirar la trayectoria de Carles Abarco en LinkedIn, en ninguna parte aparece la palabra calidad.
¿Qué es un escrutinio adecuado en 2023?
Sólo podemos adivinar las conversaciones que podría Han tomado lugar:
ejecutivo: "¿Has hecho suficientes pruebas?"
tecnología: “Sí, aquí están los cientos de pruebas que hicimos y todas pasaron”.
ejecutivo: "Bien, ¿estás seguro de que está bien empezar a funcionar?"
tecnología: "Seguro."
El fracaso era predecible y evitable. Probablemente solo habría tomado un par de meses encontrar y corregir esos errores antes de la migración; sin duda, todos desearían haber dedicado esos dos meses a resolver esos problemas. Me pregunto qué medidas TSB y Sabadell están empleando ahora para garantizar que este escenario no se repita?
Colin Hammond, abril de 2023
La noticia de que TSB muestra transacciones incorrectas en las cuentas de las personas es evidencia de que un proyecto de software salió mal debido a un trabajo de mala calidad. ¿Por qué ocurre esto y cómo se podría haber evitado? La causa raíz subyacente podría provenir de una variedad de posibilidades; en este artículo exploro algunas de las más probables y las lecciones que podemos aprender de ellas.
Sistemas heredados bajo presión
En el centro de la mayoría de los bancos y grandes instituciones financieras se encuentra un software que se escribió originalmente hace mucho tiempo y que ha demostrado ser muy confiable. A estos los llamamos sistemas heredados y, a medida que exigimos diferentes formas de acceder a nuestros datos bancarios, el código subyacente de estos sistemas heredados funciona de maneras que los desarrolladores originales nunca imaginaron o pretendieron, lo que puede generar errores poco frecuentes.
Mantenimiento de tecnologías heredadas
La mayoría de estos sistemas antiguos están escritos en tecnologías antiguas, como un lenguaje llamado COBOL. La mayoría de los desarrolladores de COBOL ya se han jubilado y hay muy pocos jóvenes entusiasmados por aprender estos lenguajes muertos. En consecuencia, hay una escasez de desarrolladores altamente cualificados para estos sistemas antiguos.
El riesgo conduce a la abstracción
Migrar sistemas heredados a tecnologías más nuevas es difícil y arriesgado. Planificar e implementar puede llevar años. El reemplazo de un sistema central puede ser tan potencialmente disruptivo que la gerencia evita hacerlo por completo. Una táctica para permitir que los bancos avancen ofreciendo nuevas funciones a los usuarios es envolver estos sistemas antiguos utilizando una técnica llamada Abstracción. Se los trata como una “caja negra” y no necesitamos preocuparnos por cómo funcionan, sólo debemos tener confianza en sus entradas y salidas. Esta técnica pospone la eventual necesidad de reemplazar estos sistemas.
Arquitectura y Complejidad
A medida que se crean nuevos productos bancarios, cada vez más sistemas dependientes “se cuelgan” del legado, creando una imagen cada vez más compleja de cómo se mueven los datos entre estos sistemas. Los sistemas demasiado complejos pueden ser la causa de muchos errores. Una buena arquitectura de TI ayudará a combatir o contener esta complejidad y el riesgo asociado.
Código evolucionado
Los sistemas que existen desde hace mucho tiempo a menudo han sido modificados por muchos programadores a lo largo de los años. A veces hay poca transferencia de conocimientos de un desarrollador a otro. El nuevo no entiende lo que hizo el último y se muestra reacio a cambiar el código existente, en caso de que lo rompa. Entonces, en lugar de eso, escribe un código nuevo para que se asiente junto al código anterior. Ambos conjuntos de códigos probablemente hagan lo mismo, pero lo que sucede cuando llega el próximo desarrollador es que no puede estar seguro de en qué código trabajar. Ésta es una de las formas en que puede acumularse la complejidad.
Las pruebas por sí solas no son suficientes para garantizar la calidad
Los estudios de miles de proyectos de TI nos proporcionan evidencia de que las pruebas por sí solas no garantizarán que se hayan encontrado todos los errores. De hecho, en el mejor de los casos, las pruebas rara vez encontrarán más de 85% de errores. Las pruebas deben complementarse con otras formas de técnicas de mejora de la calidad que puedan identificar errores potenciales incluso antes de comenzar las pruebas. Algunos de los más efectivos son el análisis estático y las revisiones formales que cubren los requisitos, la arquitectura, el diseño y el código.
Prueba que no hace lo que no debe
Supongamos que está realizando una transacción en su aplicación bancaria, se pierde la conexión y solo se envía la mitad de las instrucciones al banco. ¿Cómo maneja el sistema del banco media instrucción? Si ese sistema está conectado a un sistema heredado, ¿cómo maneja el sistema heredado una instrucción incompleta? Siempre que hacemos un cambio en el sistema, siempre probamos que el nuevo sistema haga lo que se supone que debe hacer. También debemos asegurarnos de que no haga lo que no debería, este tipo de pruebas tienden a pasarse por alto.
Horario comprimido
Sin duda, el trabajo que ha realizado TSB para migrar sistemas habrá pasado por pruebas exhaustivas. Sin embargo, con todos estos proyectos, el equipo habrá estado bajo cierta presión de tiempo para completar su trabajo en una fecha determinada. Una escala de tiempo comprimida es una de las causas más comunes de fracaso de un proyecto de TI.
Habilidades técnicas
La codificación es un trabajo creativo que requiere habilidad y experiencia. Por ejemplo, hay muchas formas de codificar el mismo resultado: un codificador puede lograr un conjunto de funciones en sólo una o dos líneas, otro puede tener que escribir cincuenta. En general, el código más compacto/conciso tiende a ser de mayor calidad. Las habilidades de los desarrolladores varían dramáticamente, compare un cantante que tiene un tono perfecto con otro que ni siquiera puede cantar una melodía, ambos se llaman a sí mismos "cantantes". Los desarrolladores de baja competencia pueden introducir más errores que correcciones o funcionalidades.
Presión empresarial por nuevos requisitos
La gerencia siempre está bajo presión para hacer crecer su negocio y, en algunos casos, puede perder de vista la importancia de sistemas estables y precisos cuando se encuentra bajo presión para ofrecer nuevas características y capacidades.
Errores no previstos, por lo que no se entendió el riesgo empresarial
Contrariamente a lo que mucha gente cree, los errores en el software se pueden predecir y medir. Usando métricas de software estándar es posible saber cuántos errores quedan en un sistema antes de entrar en funcionamiento. Si a los gerentes se les dice cuántos defectos pendientes aún no se han encontrado, es posible que no aprueben la decisión de poner en marcha. Es decepcionante ver que muy pocas personas utilizan estas métricas. Están (como COBOL) pasados de moda pero funcionan. Aportan una certeza considerable a una industria que se ha enamorado del "fallo rápido" y la "implementación rápida" en comparación con métricas comprobadas.
Conclusión
Hay muchas razones posibles para los recientes problemas de TSB, y sugiero algunas de ellas aquí. La verdad es que reemplazar los sistemas heredados es más que una simple responsabilidad de TI; en algunos casos es una cuestión de supervivencia total del negocio. Los clientes bancarios pueden ser tolerantes si su aplicación bancaria no está disponible durante unas horas, pero no aceptarán saldos incorrectos ni transacciones con graves retrasos. Esto socava la confianza y, sin confianza, los clientes bancarios se irán a otra parte. Colin Hammond es consultor de aseguramiento de proyectos de TI y autor de ScopeMaster, una herramienta para brindar certeza a los proyectos de TI.
