Engenharia de software é uma disciplina que aplica o desenvolvimento de software em uma abordagem sistemática. É a aplicação de teorias, métodos e ferramentas para planejar a construção de um sistema que compreende as especificações eficientemente, com ótimo custo-benefício e qualidade de software garantida. A temática se mostra ainda mais importante ao evitar perdas financeiras ou humanas. Desde o início da computação, existem diversos casos de catástrofes causadas por problemas de software, como o Mars Climate Orbiter. Porém, isso não acabou com o avançar dos anos e casos recentes como o Boeing 737 Max e o Knight Capital ainda ocorrem.
US$ 327,6 milhões para a NASA
Uma nave espacial perdida devido a um erro de métrica matemática
Em setembro de 1999, quase depois de 10 meses de viagem para Marte, o Mars Climate Orbiter queimou e quebrou em pedaços. Uma comitê de revisão da NASA descobriu que o problema estava em um software que controlava os propulsores do orbitador. O sistema calculava a força que os propulsores deveria exercer em libras de força, mas uma outra parte do código que lia esse dado, assumia que estava na unidade métrica newtons por metro quadrado.
Como aconteceu
Durante a fase de projeto, os engenheiros de propulsão em Lockheed Martin no Colorado expressaram força em libras. Porém, era uma prática padrão converter para unidade métricas para missões espaciais. Engenheiros da NASA’s Jet Propulsion Lab assumiram que essa conversão tinha sido feita.
Esse acidente de navegação empurrou a sonda perigosamente perto da atmosfera do planeta, onde acabou queimando e se quebrando em pedaços, matando a missão no dia que os engenheiros esperavam celebrar a entrada na órbita de Marte.
O que poderia ter salvado o dia
O erro inicial foi cometido pela empreiteira Lockheed Martin Astronautics no Colorado, o qual, como o restante da indústria de lançamentos estado unidense, usava medidas inglesas. O contratado, por acordo, deveria converter as medidas em métricas.
Seguindo as boas práticas de engenharia de software, com padronização e gerenciamento de requisitos, a NASA poderia ter evitado essa grande perda financeira.
US$18 bilhões para a Boeing e 346 vidas
Duas quedas de avião devido à confiança do software em um único sensor
Um Boeing 737 MAX 8 da companhia indonésia Lion Air, no dia 29 de outubro de 2018, com 189 pessoas a bordo caiu no mar de Java 13 minutos após a decolagem do aeroporto de Jacarta. Um sensor da velocidade da aeronave ajustado incorretamente teria sido a causa da catástrofe.
Outro acidente fatal ocorreu em 10 de março do ano seguinte na Etiópia. Um avião da Ethiopian Airlines de mesmo modelo, caiu 6 minutos após decolar de Addis Abeba. Todas as 157 pessoas a bordo do avião da companhia aérea etíope morreram no acidente.
Em razão dessas catástrofes, a Agência Europeia para a Segurança da Aviação suspendeu todos os voos do Boeing 737 MAX na Europa. Após a União Europeia, também o Brasil, o México, a Rússia, a China e vários outros países decidiram banir temporariamente os voos de aeronaves desse modelo.
Como aconteceu
Em um voo normal, um Boeing 737 deve voar dentro de um chamado ângulo de ataque de alguns graus. Os aviões precisam ficar dentro de um determinado intervalo, efetivamente uma zoa segura para o voo.
O 737 Max possui motores maiores colocados mais altos no avião, criando aerodinâmica que pode empurrar o nariz para cima em algumas condições. Se o ângulo de ataque se tornar muito íngreme, o avião poderá cair.
A Boeing desenvolveu um sistema chamado MCAS que usa estabilizadores na cauda para empurrar o nariz para baixo e ajudar a evitar o avião cair. O sistema confia apenas em um dos dois sensores que medem o ângulo de ataque, o que segundo Bjorn Fehrm, um engenheiro aeronáutico, não é um bom sistema de engenharia: “Foi aí que eles estragaram tudo.”
Acredita-se que um sensor de ângulo de ataque tenha fornecido dados defeituosos nos acidentes mortais da Ethiopian Airlines e da Lion Air. Nesse segundo, um sensor mostrou que o avião estava apontado pelo menos 20 graus mais alto que o outro. O sistema automatizado respondeu empurrando o nariz do avião para baixo, o que era pra ser um ângulo mais seguro, mas isso na verdade levou o avião a um ângulo potencialmente perigoso.
Em 16 de maio de 2019, a Boeing anunciou que concluiu a atualização de software do modelo 737 MAX. Assegurou também que finalizou os testes correspondentes, incluindo 207 voos e mais de 360 horas no ar, durante os preparativos para que as aeronaves possam voltar a voar. Essa ação pode ser classificada como uma gestão de riscos reativa pela engenharia de software.
O que poderia ter salvado o dia
Afim de evitar catástrofes com perdas humanas e financeiras, a empresa aeronáutica deveria adotar sempre a estratégia proativa, na qual a gestão de riscos é iniciada muito antes de que o trabalho comece. No caso do sistema MCAS, simplesmente considerar os dois sensores de ângulo de ataque – que já se encontravam instalados no avião – tonaria o voo mais seguro.
Assim, sem nenhum gasto com mudanças nos aviões e poucas alterações no software, dois acidentes fatais poderiam ter sido evitados. A gestão de riscos para resolver ou minimizar as possibilidades de um problema pode ser utilizada em basicamente todo e qualquer projeto, não sendo um área exclusiva da engenharia de software.
US$440 milhões para a Knight Capital
Como levar uma empresa à falência em 45 minutos
Em 1 de agosto de 2012, a Knight Capital Group LLC, uma das principais formadoras de mercado financeiro, sofreu um grande fracasso na operação de seu sistema de roteamento automatizado para pedidos de ações dos EUA. Causou uma grande interrupção no mercado de ações, levando a uma grande perda comercial para a empresa.
Como aconteceu
O incidente aconteceu depois que um técnico esqueceu de copiar o novo código do Programa de Liquidez de Varejo (RLP) para um dos oito servidores de computador Sistema de roteamento inteligente de acesso ao mercado (SMARS), que era o sistema de roteamento automatizado da Knight para pedidos de ações.
O código RLP reformulou um sinalizador usado anteriormente para ativar a função antiga conhecida como “Power Peg”. O Power Peg foi projetado para aumentar e diminuir os preços das ações, a fim de verificar o comportamento dos algoritmos de negociação em um ambiente controlado. Portanto, os pedidos enviados com o sinalizador redirecionado para o oitavo servidor acionaram o código defeituoso do Power Peg ainda presente nesse servidor.
A Knight Capital sofreu uma perda antes de impostos de US $ 440 milhões. Isso causou o colapso do preço das ações da Knight Capital, enviando ações mais baixas em mais de 70% antes do anúncio. A natureza da atividade comercial incomum da Knight Capital foi descrita como uma “quebra de tecnologia”.
O que poderia ter salvado o dia
Em softwares complexos, implantações são muito comuns. Knight poderia ter evitado a falha e minimizado o dano com uma variedade de controles de DevOps. Outra boa opção seria uma re-arquitetura do sistema SMARS para usar contêineres Docker e um sistema de orquestração como Kubernetes para garantir automaticamente a versão mais atual do software implementada com o benefício adicional de escalabilidade.
Os gerentes de projeto de TI e o CIO da Knight deveriam ter adiado o cronograma de entrega hiper-agressivo e contestado seus líderes de negócios com um cronograma alternativo. Trinta dias para implementar, testar e implantar grandes mudanças em um sistema de negociação algorítmica usado para fazer com que os mercados valham bilhões de dólares diariamente são impulsivos, ingênuos e imprudentes.
