Quando um erro em sistema SCADA pode ser considerado defeito, falha ou bug? 

O Brasil está entre os países que mais se preocupam com a qualidade na indústria. Por isso, há cerca de sessenta anos, o país implementou a entidade responsável por representar esse movimento de qualidade: a ABNT (Associação Brasileira de Normas e Técnicas). Foi neste período, também, que nasceu a ISO (international Standardization Organization). 

Quando falamos sobre qualidade, adentramos um campo fértil e muito vasto, que pode ser observado e discutido não apenas na fabricação de produtos, mas também na forma de consumo. 

Se estreitarmos o tema sob a perspectiva de software, veremos que entre as tantas técnicas e ferramentas disponíveis para apoiar os desenvolvedores, há soluções específicas que são capazes de agilizar tarefas e aplicar metodologias que facilitam o trabalho e análise de profissionais ligados à tecnologia, principalmente na busca por falhas potenciais. 

O processo de desenvolvimento de uma aplicação começa muito antes da escrita da primeira linha de código, indicando que a qualidade começa já no planejamento e termina depois da entrega, quando o sistema é constantemente monitorado a plena carga.

“Nas aplicações SCADA desenvolvidas pelo nosso time, a identificação de problemas potenciais que podem, de alguma forma, impactar nas etapas de desenvolvimento, começa no processo de análise de requisitos. Quanto mais detalhada é esta análise, maiores são as chances de mitigar a origem de possíveis erros, defeitos, falhas e bugs”, afirma Vanessa Rech, Analista de Requisitos da SCADAHUB.

Mas então, quando um sistema trava ou deixa de funcionar, seja repentinamente ou momentaneamente, como saber se você terá que lidar com um bug, um defeito ou uma falha? 

Por mais que façamos uma associação entre estes conceitos, imaginando que são parecidos,  defeito –  falha e erro não são sinônimos e devem ser avaliados de maneira distinta. 

Para diferenciar esses 3 conceitos, vamos tomar como exemplo principal um sistema meteorológico em uma região isolada do Brasil, que necessita transmitir dados de hora em hora para alimentar um servidor que fica a quilômetros de distância.  Acompanhe:

Defeito

O defeito é caracterizado como uma imperfeição de um produto. É como se o defeito fizesse parte deste produto e, em geral, está ligado a algo implementado no código de maneira incorreta.

De acordo com Ian Sommerville, autor britânico referência no assunto, defeito é uma característica de um sistema de software que pode levar a um erro de sistema. Um exemplo clássico de defeito é a inclusão de um código para adicionar uma hora à hora da última transmissão, sem verificar se já passou das 23h, de acordo com nosso exemplo.

Falha

Falha é o resultado errado provocado por um defeito ou condição inesperada.
Os defeitos podem existir, mas nem sempre são visíveis. Falhas também podem ocorrer por fatores externos ao programa, como corrupção de bases de dados ou invasões de memória por outros programas. 

Para exemplificar, imagine que o operador de uma empilhadeira, no momento de içar os garfos para coletar uma carga, perceba que a máquina não está respondendo a esse comando. Podemos dizer que uma das funções da empilhadeira, nesse momento, falhou.  Portanto, temos a apresentação de uma falha.

Ainda no mesmo exemplo, caso o operador tente ligar a empilhadeira e não consiga, temos também a apresentação de uma falha, porém, de caráter mais crítico, pois nesse caso, nenhuma das funções pode ser desempenhada.

As falhas que provocam uma sensação de urgência e demandam atenção quase que instantaneamente, provavelmente são aquelas que o programa trava. 

Mas, é importante ressaltar que toda falha potencial pode ser perigosa, mesmo que o programa não seja paralisado. 

De acordo com um estudo de engenharia de software divulgado pela Universidade Federal de Minas Gerais, a falha de um sistema é um evento que ocorre em algum momento em que o sistema não fornece um serviço como esperado por seus usuários. Por exemplo, nenhum dado meteorológico é transmitido porque a hora é inválida. 

Bug

A palavra “bug” tem origem inglesa e, em português, significa “inseto”. Ela é utilizada quando erros ocorrem no funcionamento de um software ou hardware e podem resultar em comportamentos inesperados, como um resultado errado ou performance indesejada.

Na maioria dos casos, as falhas acontecem no próprio código-fonte e podem ser causadas, entre outras razões, por um framework, um sistema operacional ou um compilador. 

Os bugs são um problema maior quando se tornam porta de entrada para crimes cibernéticos.

Ainda segundo o escritor Sommerville, quando analisamos pela perspectiva de Engenharia de Software, os bugs são um estado errôneo que podem levar a um comportamento inesperado do sistema por parte de seus usuários. Em nosso exemplo: o valor do tempo de transmissão é definido incorretamente (a 24.XX em vez de 00.XX) quando o código com defeito é executado. 

A correta diferenciação entre defeitos, falhas e bugs possibilita identificar melhor a abordagem complementar, que deve ser utilizada para aumentar a confiabilidade de um sistema.  Para isso indicamos:

  • Prevenção: é um conjunto de técnicas de desenvolvimento utilizada para evitar erros na etapas de projeto e programação, a fim de mitigar a inserção de defeitos de sistema devido a erros humanos e/ou enganos; 
  • Detecção e remoção: são técnicas focadas na verificação e validação para aumentar as chances de detecção e remoção de defeitos antes de o sistema ser usado, como por exemplo testes e depuração sistemáticos. 
  • Tratamento:  inclui a utilização de técnicas, como a redundância de sistemas, para assegurar que possíveis erros não detectados sejam impedidos de causar erros de sistemas, Consequentemente, estes erros de sistema não resultarão em falhas de sistema.

A SCADAHUB, por ser essencialmente uma empresa de software, preocupa-se em utilizar as melhores práticas para a validação das suas aplicações SCADA, efetuando testes de desenvolvimento, sistema e aceitação. 

Nos testes de desenvolvimento, cada componente do sistema é testado de forma independente pela pessoa que o desenvolveu. Os componentes podem ser entidades simples, como funções e classes de objetos, ou podem ser agrupamentos coerentes dessas entidades. Essencialmente, os testes têm como objetivo descobrir bugs no software.

Nos testes de sistema, todos os componentes testados são integrados para criar um organismo completo. Esse processo se preocupa em encontrar os erros resultantes das interações inesperadas entre componentes e problemas de interface do componente. Além disso, também ajuda a validar que o sistema satisfaz seus requisitos funcionais e não funcionais.

Nos testes de aceitação, o sistema é testado com dados fornecidos pelo cliente e não com dados advindos de testes simulados. Através desta atividade é possível identificar problemas, erros ou omissões na definição dos requisitos do sistema, onde os recursos estejam em desacordo às necessidades do usuário. Muitas vezes, esse é o estágio final do processo de testes. 

CASE SCADAHUB 

“É muito comum clientes procurarem a SCADAHUB para atuarmos em aplicações Elipse E3, Elipse Power ou Elipse EPM já existentes, para correções de erros ou falhas na execução de projetos, bugs e defeitos recorrentes que interferem na operação continuada de sistemas, ou ainda para modificar aplicações com problemas de performance”, afirma Gerson Garbelotto – Coordenador de Desenvolvimento SCADAHUB.

Casos assim acontecem com certa frequência. Clientes nos contratam para otimizar sua aplicação SCADA e PIMS quando detecta problemas na geração de relatórios, travamentos, consumo exagerado de memória do servidor e armazenamento de dados históricos mal dimensionados. Tayná Serpa, nossa Analista de Desenvolvimento e Programadora Certificada Elipse EPM, trabalhou em alguns projetos que apresentaram problemas como estes e acredita que, em boa parte, isso acontece porque as aplicações são configuradas por profissionais com bom background em Data Warehouse, porém sem muita experiência na plataforma.

“Trabalhei em um projeto que contava com mais de 900 variáveis que eram aquisitadas, cada uma delas, através de uma consulta ao Banco de Dados SQL Server, sendo que poderiam ser aquisitadas diretamente da aplicação Elipse Power, com grande otimização de performance e menos gastos de processamento e memória. Ao final deste projeto, foi possível reduzir para apenas 6 consultas que realmente necessitavam de busca no banco de dados”, conta Tayná.

Caso você tenha uma aplicação com problemas, entre em contato com o nosso time, a SCADAHUB pode ajudar.

—————-

Gostou do nosso conteúdo!? 
Então, não deixe de curtir, compartilhar e deixar o seu comentário! 

Colaboração e edição: Gabriel Devenz – Analista de Desenvolvimento SCADAHUB

Deixe um comentário

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