Software (In)Tolerante a Falhas

Algo muito comum em nosso dia a dia, que talvez não receba a importância que deveria ter são as falhas (bugs) existentes em nossos softwares. Muito além de pequenas falhas, onde uma conversão é realizada errada ou uma exceção feia é exibida ao usuário, existem situações realmente preocupantes.

Naturalmente estamos acostumados a “pagar para ver”, ou então “implantar e rezar”, não é mesmo? Seja por testes manuais deficientes (que não levam em consideração o contexto e testam sempre o caminho feliz), a falta de testes unitários, de integração ou de UI. O fato é que não somos (não todos, boa parte de nós) acostumados a testar, pois a nossa autoconfiança normalmente é bem elevada, que junto com a arrogância, elevam os riscos de algo sair errado.

Com o decorrer do meu primeiro semestre de Ciências Aeronáuticas estou recebendo uma boa quantia de noções de gerenciamento e principalmente a prevenção de falhas. A aviação tem muito em comum com o desenvolvimento de software, pois, nada pode sair errado, visto que o preço a ser pago por um erro ou engano é normalmente bem caro. É claro que o software que produzimos não expõe a vida de ninguém ao perigo (ou expõe?), mas o prejuízo financeiro pode ser relativamente elevado.

Muito além de cuidar dos bugs existente é ter a preocupação em não criar novos bugs! De nada adianta resolver bugs e ficarmos felizes e satisfeitos com isto, se ao mesmo tempo, quando implementamos novas funcionalidades (evoluções), entregamos mais uma série de bugs novinhos em folha. Horas! Onde está satisfação e felicidade nisto? Sim, resolver bugs é desafiador e prazeroso, no entanto, em contra partida, seu cliente tem o desafio de driblar os bugs e trabalhar com “contornos” que às vezes soa vergonhoso para ambos os lados.

Na área da aviação, mais precisamente no estudo de Fatores Humanos, há dois modelos de “gerenciamento de falhas” que se encaixam em nosso dia a dia, o primeiro é o SHELL e o segundo Reason. Os modelos apresentam diferenças significativas quanto aos seus objetivos, no entanto, a essência é praticamente a mesma. Vamos entender sobre estes dois modelos em seguida.

O modelo Reason

Este modelo se encaixa muito bem em nosso ambiente, visto que este modelo trada diretamente de falhas. Neste modelo, uma consequência é gerada a partir de uma sequência de falhas que se alinham em uma cadeia de eventos e permitem uma “trajetória oportuna”. Neste modelo são abordados três aspectos: Falhas ativas, falhas latentes e ineficiência de barreiras defensivas. Vamos entender melhor em seguida.

Falhas Ativas

Considera-se falhas ativas determinadas ações (normalmente proveniente dos usuários) inseguras que causam consequências imediatas.

Falhas Latentes

Falhas latentes são elementos residentes no sistema que permite que falhas ativas ocorram, ou até mesmo, inviabilizam barreiras projetadas para evitar falhas. Normalmente estas falhas estão ligadas a decisões equivocadas (seja por parte do software, ou por parte do usuário). No caso desta falha ser causada por um usuário, é natural que o software o tenha levado até ela, ou seja, o software colocou o usuário num caminho que o levou até a falha.

Barreiras Defensivas

Barreiras defensivas são filtros e bloqueios que provem proteção ao software e seu resultado esperado. Tais barreiras visam evitar que usuários possam cometer falhas ativas, e caso ocorram, estas mesmas barreiras tem a finalidade de minimizar as consequências.

Em nosso ambiente

Analisando o modelo Reason podemos ter uma ideia de como vários fatores podem ser culpados por consequências indesejáveis. Isto é, o nosso próprio processo de desenvolvimento pode prover um ambiente arriscado e propício a falhas. Isto se dá de uma ponta a outra, da análise até a entrega/primeiros passos. Se houverem falhas no processo de análise, desenvolvimento, qualidade, entrega e até mesmo treinamento, certamente poderão haver consequências causadas por erros bobos/críticos que ninguém percebeu até chegar nas mãos dos seus clientes.

Linha defensiva

Um tópico significativamente importante do modelo Reason é tratar da capacidade que o software tem de prover uma linha defensiva e inviolável. Isto é, não permitir que o usuário possa causar falhas ativas por meio de falhas latentes. Se o seu software permite que um usuário grave um valor incorreto no banco de dados por exemplo, a barreira defensiva está deficiente, necessitando de uma maior atenção.

O trabalho a ser empregado na construção de barreiras normalmente é cansativo, porém, compensatório. Quando dedicamos tempo a realizar tratamentos de possíveis falhas/erros, além de estarmos evitando que novos bugs surjam, estamos nos forçando a conhecer o processo e seu contexto, visto que, para impor barreiras é necessário conhecer a regra de negócio empregada, o que pode, o que não pode e o real objetivo de uma ação.

Outra vantagem de termos linhas defensivas bem construídas é a capacidade do software se manter em pé e consistente após uma falha não prevista, ou seja, o software tem a capacidade de minimizar as consequências (até mesmo eliminar) causadas por uma falha. Neste caso, temos a nossa maior preocupação: Não permitir que dados inconsistentes atinjam os bancos de dados, pois, caso isto ocorra, podem comprometer outros processos que dependam de tais dados, o que provoca consequências exponenciais.

Para facilitar a construção de barreiras defensivas aqui vai uma dica: Construa testes unitários e de integração! Nada de fazer testes em caminhos seguros, muito além, os testes têm que garantir que caminhos obscuros não causem falhas. Você deve ter o seguinte pensamento: “Em que cenário esta implementação falha?”. A partir deste pensamento, formule os cenários e construa os testes necessários. Feliz do desenvolvedor que descobre falhas por meio de testes unitários ou de integração antes da solução chegar aos clientes, garanto que é mais prazeroso que resolver bugs (risos).

O modelo SHELL

O modelo SHELL (S: Software, H: Hardware, E: Enviroment (Ambiente), L: Liveware (elemento humano, usuários) trata em sua essência o elemento humano, onde são consideradas as necessidades físicas, tolerância ambienta, quantidade e características dos estímulos, capacidade de percepção dos estímulos, processamento das informações, processo decisório e ação desejada.

Em se tratando de software, este modelo prega que o software tem que ser adaptado à realidade do usuário e não o inverso. Isto porque naturalmente os usuários querem utilizar e extrair dados úteis do software e não participar de cursos semanais sobre como utilizar seu software.

Neste modelo, o software tem que ser capaz de ser compreendido pelo usuário, sem a necessidade de auxílio externo (replicadores, suporte técnicos, etc.). E para que isto exista, é necessário levar em consideração alguns pontos importantes:

  • Software deve ser fluído e de fácil manuseio;
  • Controles elementos autoexplicativos (ícones e nomenclaturas claras);
  • Mensagens de erro/alerta/orientativas claras e intuitivas;
  • Comunicação software-usuário objetiva e orientativa, sem termos técnicos que amedrontam e impõe barreiras ao entendimento do usuário;
  • Documentação abrangente e de fácil entendimento;
  • Padrões de interface, onde qualquer parte do sistema oferece a mesma facilidade de uso, assim como o mesmo padrão de interface (botões, telas, grades, etc);
  • O software deve prover um ambiente amigável, fluído, lógico e entendível aos usuários, isto evita problemas causados por má interpretação, que alinhados com linhas defensivas deficientes, oferecem grandes riscos aos processos implantados.

Também é necessário que o software e suas partes estejam devidamente documentadas, seja para os usuários terem o total entendimento do funcionamento, ou até mesmo para que o suporte técnico possa oferecer uma orientação clara e correta, sem a possibilidade de equívocos. Além da documentação bem desenvolvida, é necessário que o software se comunique com o usuário de forma clara e objetiva, sem muitos termos técnicos, algo como uma conversa. Assim, quando o software passar por uma dificuldade ou necessitar de uma ação, o usuário entenderá o que lhe é informado/solicitado podendo tomar decisões conscientes sem a possibilidade de uma má interpretação e uma possível ação insegura.

Conclusão

Assim como nos sentimos à vontade utilizando nossas IDE’s de desenvolvimento, aplicativos que facilitam nossas vidas e sistemas operacionais que nos provem estas possibilidades, também devemos prover esta sensação aos nossos clientes, o que torna o dia a dia mais fácil para que além de fazerem um bom trabalho com nossos softwares em mãos, indiquem-no a outros (e pode ter certeza que isto acontece). E por fim, os nossos softwares devem prover a sensação de segurança, resistência e eficiência, afim de proporcionar uma ótima experiência e garantir a satisfação de nossos clientes.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.