Abordagens atuais sobre modelagem em confiabilide de software

Mohanta, Vinod e Mall (2011) propõem um modelo para categorizar diferentes tipos de falhas que podem ocorrer nos componentes que compõem o produto de

software. Segundo os autores, as falhas podem ser classificadas em falhas de

requisitos, falhas de projeto, falhas de programação e rastreabilidade. As falhas de requisitos podem ocorrer devido a erros humanos, falta de compreensão das funcionalidades do sistema, um mal-entendido entre o analista e o cliente.

Segundo estes mesmos autores, alguns exemplos de falhas de requisitos seriam a falta de especificação funcional, o que acontece quando os analistas de sistema falham em especificar ou documentar um requisito funcional, e a especificação incorreta de requisitos, o que acontece quando um analista de sistema, incorretamente, especifica ou documenta uma funcionalidade de um sistema.

Conforme descrito no parágrafo anterior, uma falha na especificação funcional de qualquer dos softwares utilizados no processo de fabricação de motores pode ter consequências sérias e causar uma falha de montagem que pode não ser detectada por camadas preventivas e reativas presentes no sistema, o que pode levar à falha

operacional de um motor com sérias consequências para todas as partes envolvidas. Portanto, a correta especificação de um software é fundamental para garantir a sua confiabilidade.

As falhas de projeto são fatores intimamente relacionados ao ser humano e ao processo de projetar o software. Mohanta, Vinod e Mall (2011) afirmam que falhas de programação podem ser classificadas em falhas estruturais e falhas de algorítmos. Falhas estruturais são aquelas que um programador comete, devido ao tamanho, estrutura e complexidade do programa.

Os mesmos autores explicam que falhas computacionais incluem as falhas que ocorrem devido à conversão incorreta de representação de dados. Alguns exemplos de falhas de computação seriam o armazenamento de valores em variáveis que excedem o maior valor que as variáveis podem armazenar. Falhas lógicas ocorrem devido à utilização incorreta dos operadores de lógica em um programa. Exemplos de falhas lógicas seriam a omissão de parênteses em uma expressão aritmética, inserção de parênteses em um lugar errado e o uso inadequado dos operadores lógicos em uma construção de decisão. Falhas de inicialização são causadas devido à inadequada inicialização de variáveis.

Falhas de algorítmos surgem devido ao uso de um algoritmo incorreto ou uma compreensão incorreta do problema para o qual o algoritmo é projetado. Um exemplo de falha de algoritmo seria a seleção do algoritmo inadequado, implementação de um algoritmo de qualidade inferior, que resulta em desempenho insatisfatório do programa. Falhas de rastreabilidade ocorrem quando um programador, ao desenvolver um software, interpreta a especificação de requisitos ou design de forma incorreta.

Levando em conta os fatores descritos acima por Mohanta, Vinod e Mall (2011) e analisando a criticidade dos softwares utilizados no processo de fabricação de motores, fica evidente que a qualidade do fornecedor do software é fator decisivo e que a validação e teste do software assume um papel relevante na previsão de confiabilidade do mesmo e que este dados de teste devem ser obtidos antes de colocar o software em operação, pois uma falha em operação será crítica para a segurança global do sistema.

Alho e Mattila (2012) afirmam que falhas de software passaram a ser a fonte mais comum de paralisações de sistemas computadorizados no século passado e que sistemas de controle modernos possuem funcionalidades implementadas com

software. Falhas de software, portanto, apresentam uma grande ameaça para os

sistemas essenciais à segurança. A especificação de requisitos de software tem um papel importante na segurança e confiabilidade de sistemas. A incorreta especificação de um software é a maior fonte de defeitos de alta qualidade.

Sistemas que utilizam software são geralmente complexos, o que torna um

software confiável muito caro. Alho e Mattila (2012) afirmam que o desenvolvimento

frequentemente inclui avaliações de risco, procedimentos de verificação e validação. Como sempre, o uso de uma determinada técnica ou técnicas não é a prova de qualidade de software e, mesmo certificados, os sistemas falham. Em softwares de sistemas de alta qualidade a falha de especificação é a fonte mais frequente de defeitos. Estes defeitos podem ser devidos a erros e alterações em requisitos. Erros e alterações podem ser geralmente descobertas e gerenciadas com ferramentas e inspeções (validação de requisitos), mas a falta de requisitos pode ser consideravelmente mais difícil de detectar.

Conforme descrito por Alho e Mattila (2012) nos parágrafos anteriores e considerando a grande quantidade de softwares diferentes utilizados no processo de fabricação de um motor, fica claro que a especificação correta de um software é de vital importância e deve ser feita por especialistas que entendam bem as funcionalidades e as restrições de um processo produtivo específico utilizado na fabricação de motores. Igualmente importante é a documentação e o registro de detalhes dos requisitos de segurança.

Tyagi e Sharma (2012) afirmam que, para garantir segurança de sistemas que utilizam software, deve-se especificar os requisitos de sistema (que inclui os requisitos de segurança do sistema), conduzir análises de risco de software, definir as restrições de hardware. Para definir adequadamente a confiabilidade e requisitos de tolerância de falha para um sistema, diversos aspectos do software devem ser documentados, incluindo atributos de qualidade pretendidos, modos de operação e falha.

Segundo estes mesmos autores, estudos de confiabilidade de software são cruciais para a estimativa de falhas de campo de software. Quando a confiabilidade é confirmada, aplicações mais confiáveis de software podem ser criadas. A

confiabilidade de aplicativos de software é definida como: 1 - a probabilidade de um dado sistema desempenhar a sua função adequadamente durante um período especificado de tempo sob o funcionamento e condições esperadas; 2 - a probabilidade de que o software irá operar livre de falhas em um ambiente fixo por um intervalo fixo de tempo.

O Apêndice F mostra uma representação geral de toda a cadeia de causas de falhas. Neste cadeia estão representadas algumas falhas na cadeia de eventos que podem ser originadas por falha de software e que podem levar à falha do evento de topo. Neste exemplo, oitenta e um fatores diferentes podem influenciar vinte e sete eventos intermediários que, por sua vez, podem influenciar três eventos intermediários, três camadas de proteção e três camadas reativas.