Falha de TI do TSB – uma lição para outros

A notícia do TSB mostrando transações incorretas nas contas das pessoas é evidência de um projeto de software que deu errado devido a um trabalho de má qualidade. Por que isso acontece e como poderia ter sido evitado? A causa raiz subjacente pode vir de uma série de possibilidades. Neste artigo, exploro algumas das mais prováveis e as lições que podemos aprender com elas.

Sistemas legados sob pressão

No centro da maioria dos bancos e grandes instituições financeiras está um software que foi originalmente escrito há muito tempo e que provou ser muito confiável. Chamamos isso de sistemas legados e, à medida que exigimos diferentes formas de acessar nossos dados bancários, o código subjacente desses sistemas legados funciona de maneiras que os desenvolvedores originais nunca imaginaram ou pretendiam, o que pode levar a bugs pouco frequentes.

Manutenção de tecnologias legadas

A maioria desses sistemas antigos é escrita em tecnologias antigas, como uma linguagem chamada COBOL. A maioria dos desenvolvedores COBOL já se aposentou e há muito poucos jovens entusiasmados em aprender essas línguas mortas. Consequentemente, há uma escassez de desenvolvedores altamente qualificados para estes sistemas antigos.

Risco leva à abstração

A migração de sistemas legados para tecnologias mais recentes é difícil e arriscada. Pode levar anos para planejar e implementar. A substituição de um sistema central pode ser tão potencialmente perturbadora que a administração evita fazê-lo completamente. Uma tática para permitir que os bancos avancem oferecendo novas funções aos usuários é envolver esses sistemas antigos usando uma técnica chamada Abstração. Eles são tratados como uma “caixa negra” e não precisamos de nos preocupar com a forma como funcionam, apenas precisamos de ter confiança nas suas entradas e saídas. Esta técnica adia a eventual necessidade de substituição destes sistemas.

Arquitetura e Complexidade

À medida que novos produtos bancários são criados, cada vez mais sistemas dependentes “penduram” o legado, criando uma imagem cada vez mais complexa de como os dados se movem entre estes sistemas. Sistemas excessivamente complexos podem ser a causa de muitos bugs. Uma boa arquitetura de TI ajudará a combater ou conter essa complexidade e os riscos associados.

Código evoluído

Sistemas que já existem há muito tempo foram frequentemente modificados por muitos programadores ao longo dos anos. Às vezes, há pouca transferência de conhecimento de um desenvolvedor para outro. O novo cara não entende o que o último fez e está relutante em alterar o código existente, caso ele o quebre. Então, em vez disso, ele escreve um novo código para ficar ao lado do código antigo. Ambos os conjuntos de código provavelmente fazem a mesma coisa, mas o que acontece quando o próximo desenvolvedor aparece é que ele não tem certeza em qual código trabalhar. Essa é uma das maneiras pelas quais a complexidade pode aumentar.

Testar por si só não é suficiente para garantir a qualidade

Estudos de milhares de projetos de TI nos fornecem evidências de que os testes por si só não garantirão que todos os bugs foram encontrados. Na verdade, na melhor das hipóteses, os testes raramente encontrarão mais de 85% de bugs. Os testes precisam ser complementados por outras formas de técnicas de melhoria de qualidade que possam identificar possíveis bugs antes mesmo de você iniciar os testes. Algumas das mais eficazes são a análise estática e as revisões formais que abrangem requisitos, arquitetura, design e código.

Teste se não faz o que não deveria

Suponha que você esteja fazendo uma transação no seu aplicativo bancário, a conexão é perdida e apenas metade da instrução é enviada ao banco. Como o sistema do banco lida com meia instrução? Se esse sistema estiver conectado a um sistema legado, como o sistema legado lida com uma instrução incompleta? Sempre que fazemos uma mudança no sistema, sempre testamos se o novo sistema faz o que deveria fazer. Devemos também garantir que ele não faça o que não deveria, pois esse tipo de teste tende a ser esquecido.

Horário compactado

Sem dúvida, o trabalho realizado pelo TSB para migrar sistemas terá passado por testes extensivos. Porém, com todos esses projetos, a equipe estará sob alguma pressão de tempo para concluir seu trabalho em uma data específica. Uma escala de tempo compactada é uma das causas mais comuns de falha em projetos de TI.

Habilidades técnicas

Codificar é um trabalho criativo que exige habilidade e experiência. Por exemplo, existem muitas maneiras de codificar o mesmo resultado: um codificador pode obter um conjunto de funcionalidades em apenas uma ou duas linhas, outro pode ter que escrever cinquenta. No geral, um código mais compacto/conciso tende a ser de maior qualidade. As habilidades do desenvolvedor variam dramaticamente, compare um cantor que tem um tom perfeito com outro que não consegue nem cantar, ambos se autodenominam “cantores”. Desenvolvedores de baixa competência podem introduzir mais bugs do que correções ou funcionalidades.

Pressão empresarial por novos requisitos

A gestão está sempre sob pressão para expandir os seus negócios e, em alguns casos, pode perder de vista a importância de sistemas estáveis e precisos quando está sob pressão para fornecer novos recursos e capacidades.

Bugs não previstos, portanto o risco do negócio não foi compreendido

Ao contrário do que muitas pessoas acreditam, bugs em software podem ser previstos e medidos. Usando métricas de software padrão, é possível saber quantos bugs ainda existem em um sistema antes de colocá-lo no ar. Se os gestores forem informados de quantos defeitos pendentes ainda não foram encontrados, eles poderão não aprovar a decisão de entrar em operação. É decepcionante ver que poucas pessoas usam essas métricas. Eles estão (como o COBOL) fora de moda, mas funcionam. Eles trazem uma certeza considerável para um setor que se apaixonou pela “falha rápida” e pela “implantação rápida” com base em métricas comprovadas.

Conclusão

Existem muitas razões possíveis para os recentes problemas do TSB, e sugiro algumas delas aqui. A verdade é que substituir sistemas legados é mais do que uma responsabilidade da TI, em alguns casos é uma questão de toda a sobrevivência do negócio. Os clientes bancários podem ser tolerantes se o seu aplicativo bancário ficar indisponível por algumas horas, mas não aceitarão saldos incorretos ou transações muito atrasadas. Isto mina a confiança e, sem confiança, os clientes bancários irão para outro lugar. Colin Hammond é consultor de garantia de projetos de TI e autor do ScopeMaster, uma ferramenta para trazer certeza aos projetos de TI.