Programação está em tudo à nossa volta: isso pode ser um risco?

Em 10 de abril de 2014, quando o número de protocolo das ligações para o 911, emergência dos EUA, passou da casa dos milhões, o sistema entrou em pane. Durante seis horas, parte do território do país ficou sem receber chamadas. Foram horas para que alguém entendesse que só era preciso adicionar mais um dígito ao software.

Ao contrário de sistemas mecânicos, que têm sua segurança garantida pelo uso de peças confiáveis e "planos B" caso uma dessas peças quebre, um software não quebra exatamente. No caso do 911, ele fez exatamente o que deveria fazer. O problema é que ele foi programado para fazer algo errado, e não é qualquer um que pode consertar.

Software por toda parte

Esse problema está presente em mais lugares do que você imagina, mas não prestamos muita atenção a isso. Ou vai dizer que você se pergunta se o software do painel de controle do seu carro foi testado por modelos matemáticos todas as manhãs quando coloca a chave na ignição?

André Luiz Peron Martins Lanna sentiu na pele o receio de confiar num software quando seu filho nasceu, há quatro meses. O bebê chegou antes da hora e precisou de cuidados especiais comuns aos nascidos prematuramente. Engenheiro de software, quando Lanna viu pela primeira vez o filho respirando com auxílio de uma máquina, teve medo. "Quando ele estava ali, com o aparelho ajudando a inspirar e a expirar, a primeira coisa que eu pensei foi: que rigor foi usado nesse sistema?", relembra Lanna, que é professor da Faculdade do Gama da Universidade de Brasília (UnB).

O exemplo é apenas um dos vários que podemos elencar no dia a dia. Dá para programar uma lâmpada para acender quando você aperta um botão no celular, fazer o carro ligar sozinho apenas com um controle remoto, ligar a cafeteira de longe, enquanto você ainda está na cama? Sem falar, claro, em todos os dados e aplicativos armazenados no seu smartphone e computador. É programação por todo lado e na mão de muita gente.

A internet das coisas pode ser usada em tantos casos que permite até bizarrices, como as registradas na página Internet of Shit, que reúne no Twitter alguns absurdos.

Exageros à parte, a programação facilitou, aprimorou e tornou mais seguras muitas das atividades que fazemos no dia a dia, mas ela também está sujeita a erros. E um grande problema é que eles só podem ser consertados por quem entende de software. E isso pode nos levar a perder o controle sobre sistemas que antes eram mecânicos.

"Hoje em dia estamos fazendo com que tudo vá para um software. Um bom exemplo disso é a automação residencial", observa Fernando Kakugawa, doutor em sistemas distribuídos e professor dos cursos de computação da Universidade Anhembi Morumbi. "E os softwares são desenvolvidos a partir do conhecimento que o programador tem de um determinado problema. Mas é muita arrogância nossa falar que um programador consegue contemplar todas as perspectivas. Sempre alguma coisa vai escapar."

Errar é humano

O professor recorda do caso do bot racista e sexista da Microsoft em 2016. A empresa projetou um robô para interagir com a geração Z pelo Twitter. A ideia era que a inteligência artificial aprendesse com seus interlocutores e conversasse com eles de igual para igual.

Como o bot aprendia a partir das interações com humanos, ele aprendeu a ser racista, machista e xenófoba. Tay, como foi batizada, chegou a insultar uma usuária da rede com um palavrão e publicar mensagens que pareciam negar o Holocausto. "É um problema de recomendação, não um problema de software", diz Kakugawa. Não precisa nem dizer que a Microsoft rapidamente mudou de ideia e retirou Tay do ar (mas muita gente guardou prints, obviamente). Atualmente, o perfil está em modo privado.

Testar, testar e testar mais uma vez

Mas a inteligência artificial não gera só resultados ruins, como foi o caso da Tay. Ela pode ser uma grande aliada na melhoria dos softwares, ao ajudar a encontrar erros mais facilmente - apesar de não conseguir programar um sozinha. E nós, humanos, como podemos fazer a nossa parte na identificação de erros? Com testes, muitos testes.

Para prevenir com mais segurança esses erros, Lanna diz que é preciso fazer testes que tomam tempo e, consequentemente, custam dinheiro das empresas. "Em alguns casos é preciso fazer uma verificação formal para garantir que o software de fato faz aquilo que foi programado para fazer. Aí estou falando de verificação matemática mesmo."

Cada tipo de programa exigiria um nível de detalhamento diferente na verificação, dependendo das consequências que uma falha pode causar. Por exemplo: um erro que te impeça de publicar uma foto no Facebook seria menos grave do que um problema no código da máquina que controla a respiração de um bebê no hospital.

O TAB entrou em contato com a Anvisa, responsável por aprovar (ou não) novos equipamentos, para entender como isso é feito hoje no país. Por meio de nota, a agência afirma que "é realizada uma inspeção para verificar se a empresa tem condições de importar, comercializar ou fabricar produtos para a saúde, pela qual é emitida a Autorização de Funcionamento (A.F.E)." Além disso, "adota uma abordagem baseada no risco, que consiste em desburocratizar os produtos na medida do menor risco."

Há diferentes resoluções para diferentes graus de risco dos aparelhos, podendo ser necessária ainda uma avaliação do Inmetro. Para a aprovação do software, a Anvisa tem um checklist, que pode ser conferido no fim desta reportagem.

Trabalho a quatro, seis, oito mãos

Outro ponto que fragiliza o desenvolvimento são as mudanças nas equipes. Programação já é algo bastante abstrato - o programador normalmente não vê, na prática, o resultado do que está fazendo em tempo real. Imagine então pegar um trabalho pela metade e tentar completar um código iniciado por outra pessoa?

Porém, o setor está sujeito à rotatividade na equipe como qualquer outro. "É muita inocência pensar que durante a vida inteira sempre a mesma pessoa vai gerenciar aquele software", observa Kakugawa.

Lanna explica que, nesses casos, precisa haver rigor na contratação e treinamento dos novos funcionários. "Imagine a rotatividade em uma equipe de desenvolvimento que trabalha na Boeing ou na Airbus. É preciso ter certos níveis de qualidade, e para isso existem processos e modelos de qualidade. Tudo depende do porte da organização", pondera.

Falando em Boeing, problemas no software dos simuladores de voo estão no centro da crise do 737 Max, aeronave envolvida em duas grandes tragédias que fizeram mais de 300 vítimas. De acordo com engenheiros da empresa, foram contratados programadores terceirizados para desenvolver o sistema a um preço mais baixo.

Em casos menos perigosos, como o desenvolvimento de aplicativos de redes sociais, por exemplo, estamos acostumados a ver inúmeras versões com correções. Os professores explicam que, muitas vezes, para dar agilidade ao processo, os apps vão ao ar sem muito rigor, e à medida que os usuários vão relatando erros, eles são consertados.

Isso gera linhas e mais linhas de novos códigos, criando um emaranhado ainda mais complexo para quem vai ter que mexer com o programa no futuro. Os sistemas ficaram tão complicados que fica impossível prever todas as falhas. "O problema não está na linguagem de programação", reforça Lanna.

Algumas empresas adotam uma abordagem chamada Agile com a intenção de facilitar o trabalho das equipes de desenvolvedores que mexem em um mesmo software. A ideia é focar na colaboração entre as várias pessoas envolvidas no processo e, em alguns casos, trabalhar na programação em blocos, que podem ser editados e corrigidos sem repercutir no resto do código.

Design thinking

Na tentativa de tornar esse trabalho abstrato mais concreto e seguro, a resposta não estaria na melhora das linguagens de programação, defendem os professores - apesar de reconhecerem que há tentativas de criar linguagens menos abstratas que dão conta de problemas específicos. O que precisa melhorar é a forma como lidamos com a tecnologia.

Um dos modelos que têm ajudado a melhorar o processo de construção de um software é o design thinking. Essa abordagem coloca a experiência do usuário como centro do desenvolvimento do produto, considerando o ponto de vista de todos os envolvidos na execução.

Mas como isso funciona na prática, em engenharia de software? "Hoje temos oficinas de uma semana, em que todo mundo discute o que tem que ser implementado, jogando luz nas demandas do usuário", relata Lanna. As reuniões contemplam todas as partes envolvidas no projeto, do desenvolvedor ao usuário final, para que todo mundo esteja em sintonia ao criar uma solução abstrata para uma necessidade real.

*Nota da Anvisa:
"Na avaliação do registro de software independente (SamD) são verificadas as informações mínimas para a segurança e eficácia nas indicações e finalidade de uso, incluindo: descrição do software (características gerais e ambiente de operação), princípios de funcionamento (algoritmos utilizados), arquitetura do software, arquitetura do hardware, plataforma operacional, público alvo, compatibilidade (interoperabilidade e comunicação) com outros produtos médicos incluindo outros softwares, características de segurança (controles de acessos e proteção - cibersegurança), requisitos de infraestrutura, testes de verificação (incluindo os critérios de sucesso ou falha, testes de integração e de sistema), anomalias ou bugs resolvidos e não resolvidos, gerenciamento de risco, advertências e precauções, eventos adversos, normas técnicas utilizadas no desenvolvimento, versões de manual, projeto e software."

Fique por dentro de comportamento e cultura seguindo o TAB no Instagram e tenha conteúdos extras sobre inovação, tecnologia e estilo de vida.