Confiabilidade de Software

Prévia do material em texto

<p>QUALIDADE DE</p><p>SOFTWARE</p><p>Ramiro Córdova Júnior</p><p>Confiabilidade de software</p><p>Objetivos de aprendizagem</p><p>Ao final deste texto, você deve apresentar os seguintes aprendizados:</p><p> Conceituar confiabilidade de software.</p><p> Descrever a dimensão confiança de software.</p><p> Aplicar os níveis de confiança de software.</p><p>Introdução</p><p>Pode-se dizer que o ciclo completo de vida de um sistema compreende</p><p>duas fases importantes: o desenvolvimento do sistema e sua operação. A</p><p>confiabilidade de software se refere ao desenvolvimento de um software</p><p>confiável, ou seja, seus conceitos são tratados amplamente na fase de</p><p>desenvolvimento.</p><p>Neste capítulo, você terá a oportunidade de estudar os conceitos que</p><p>permeiam a confiabilidade de software, principalmente no que se refere</p><p>às dimensões de confiança de software.</p><p>Confiabilidade de software</p><p>O software deve estar disponível sempre que necessário, bem como operar</p><p>adequadamente, com segurança e confi abilidade, sem quaisquer efeitos co-</p><p>laterais adversos ou preocupações de segurança. É essencial que o software</p><p>utilizado em sistemas críticos seja confi ável, pois a consequência de uma</p><p>falha (por exemplo, a falha em uma usina nuclear) pode resultar em um dano</p><p>massivo, que poderá signifi car a perda de vidas.</p><p>De acordo com o ANSI (1991), a confiabilidade de software é definida como</p><p>a probabilidade de um software operar sem falhas por um período de tempo</p><p>específico em um ambiente específico. Embora a confiabilidade de software</p><p>seja definida como uma função probabilística e venha a sugerir uma noção de</p><p>tempo, devemos observar que, diferentemente da confiabilidade de hardware</p><p>tradicional, a confiabilidade de software não é uma função direta do tempo.</p><p>Peças eletrônicas e mecânicas podem se tornar “velhas” e desgastadas com o</p><p>tempo e o uso, mas o software não enferruja ou se desgasta durante seu ciclo</p><p>de vida. O software não será alterado com o tempo, a menos que seja alterado</p><p>ou atualizado intencionalmente.</p><p>Costumava-se acreditar que o software nunca se danificava. Intuitivamente,</p><p>ao contrário de peças mecânicas, como parafusos, alavancas ou peças ele-</p><p>trônicas, como transistores e capacitores, o software permanecerá no mesmo</p><p>estado, a menos que haja problemas no hardware que alterem o conteúdo do</p><p>armazenamento ou o caminho dos dados. O software não envelhece, enfer-</p><p>ruja, desgasta, deforma ou racha. Além disso, o software não tem forma, cor,</p><p>material ou massa, mas tem um papel crucial no funcionamento dos sistemas.</p><p>A confiabilidade do software é um atributo importante para a qualidade</p><p>do software, juntamente com a funcionalidade, a usabilidade, o desempenho,</p><p>a capacidade de manutenção, a instalabilidade e a capacidade de manutenção</p><p>e documentação. A confiabilidade é difícil de atingir, porque a complexidade</p><p>do software tende a ser alta. Embora em qualquer sistema com alto grau de</p><p>complexidade seja difícil alcançar certo nível de confiabilidade, os desen-</p><p>volvedores de sistemas tendem a empurrar a complexidade para a camada de</p><p>software. Como exemplos de tendências nesse sentido, temos que:</p><p> as aeronaves de última geração terão mais de um milhão de linhas de</p><p>código-fonte de software a bordo;</p><p> os sistemas de controle de tráfego aéreo da próxima geração conterão</p><p>entre um e dois milhões de linhas;</p><p> a próxima estação espacial internacional terá mais de dois milhões de</p><p>linhas a bordo e mais de dez milhões de linhas de software de suporte</p><p>terrestre;</p><p> vários sistemas de defesa críticos terão mais de cinco milhões de linhas</p><p>de software.</p><p>Embora a complexidade do software esteja inversamente relacionada à</p><p>confiabilidade do software, ela está diretamente relacionada a outros fato-</p><p>res importantes na qualidade do software, especialmente funcionalidade e</p><p>capacidade. A ênfase nesses recursos tende a adicionar mais complexidade</p><p>ao software.</p><p>As falhas de software ocorrem devido a erros, ambiguidades, descuidos ou</p><p>interpretações errôneas da especificação do software, descuido ou incompe-</p><p>tência ao escrever o código, testes inadequados, uso incorreto ou inesperado</p><p>do software, ou outros problemas não previstos. É comum fazer uma analogia</p><p>Confiabilidade de software2</p><p>entre confiabilidade de software e confiabilidade de hardware, mas software</p><p>e hardware têm características básicas que os tornam diferentes quanto aos</p><p>mecanismos de falha. As falhas de hardware são principalmente falhas físicas,</p><p>enquanto as falhas de software são falhas de projeto, que são mais difíceis</p><p>de se detectar, classificar e corrigir. As falhas de projeto estão intimamente</p><p>relacionadas a fatores humanos diversos e às fases do projeto mais complexas,</p><p>conforme Lyu (1995).</p><p>Com o passar do tempo, o hardware exibe as características de falha</p><p>mostradas na Figura 1, conhecidas como a curva da banheira. Nessa curva, é</p><p>possível identificar o período de vida útil do hardware ao longo do tempo. Já</p><p>a confiabilidade do software não possui as mesmas características; uma curva</p><p>de software possível é apresentada na Figura 2, se projetarmos a confiabilidade</p><p>do software nos mesmos eixos.</p><p>Existem duas grandes diferenças entre as curvas de hardware e software.</p><p>Uma diferença é que, na última fase, o software não tem uma taxa de falhas</p><p>crescente, como acontece com o hardware. Nessa fase, o software está se</p><p>aproximando da obsolescência, e não fazem sentido quaisquer atualizações</p><p>ou alterações no software. Portanto, a taxa de falha não será alterada. A</p><p>segunda diferença é que, na fase da vida útil, o software sofrerá um aumento</p><p>drástico na taxa de falhas cada vez que uma atualização for feita. A taxa de</p><p>falha é desativada gradualmente, em parte devido aos defeitos encontrados e</p><p>corrigidos após as atualizações.</p><p>Figura 1. Taxa de falhas de hardware ao longo do tempo.</p><p>Fonte: Adaptada de Ribeiro (2011, documento on-line).</p><p>Tempo</p><p>Vida útil</p><p>Falhas</p><p>prematuras</p><p>Fim da</p><p>vida útil</p><p>Ta</p><p>xa</p><p>d</p><p>e</p><p>fa</p><p>lh</p><p>a</p><p>3Confiabilidade de software</p><p>Figura 2. Taxa de falhas de software ao longo do tempo.</p><p>Fonte: Adaptada de Hartz e Walker (1996).</p><p>Tempo</p><p>Ta</p><p>xa</p><p>d</p><p>e</p><p>fa</p><p>lh</p><p>a</p><p>λ</p><p>Testes Vida útil Obsolência</p><p>U</p><p>pg</p><p>ra</p><p>de</p><p>U</p><p>pg</p><p>ra</p><p>de</p><p>U</p><p>pg</p><p>ra</p><p>de</p><p>Segundo Avizienis, Laprie e Randell (2001), são três os fatores que afetam</p><p>a confiabilidade de sistemas:</p><p>1. falta;</p><p>2. erro;</p><p>3. falha.</p><p>A falta é conhecida como defeito ou bug e é considerada em estado dor-</p><p>mente até a sua ocorrência. Um exemplo comum de falta é a declaração de</p><p>uma variável como tipo incorreto; nesse caso, a falta só ocorrerá quando essa</p><p>variável for acessada. A falta pode ser a causa de um erro, que é um estado</p><p>interno do sistema que causará uma falha perceptível de alguma forma. A</p><p>falha ocorre quando é entregue um resultado diferente do esperado. A Figura</p><p>3 apresenta a cadeia fundamental da dependabilidade, que é definida pela</p><p>relação entre falta, erro e falha.</p><p>Figura 3. Cadeia fundamental da dependabilidade.</p><p>Fonte: Adaptada de Avizienis, Laprie e Randell (2001).</p><p>... ...Falta</p><p>Ativação</p><p>Erro</p><p>Propagação</p><p>Falha</p><p>Causação</p><p>Falta</p><p>Confiabilidade de software4</p><p>Dimensão confiança</p><p>A confi ança em um sistema de computador está relacionada com o quanto o</p><p>usuário acredita no funcionamento de um sistema, baseado no que espera em</p><p>termos de comportamento do mesmo. O grau de confi ança pode ser expresso</p><p>como sendo “não confi ável”, “muito confi ável” e “ultra confi ável”, conforme</p><p>aponta Sommerville (2008).</p><p>No contexto de confiança de software, existem quatro principais dimensões</p><p>relacionadas com a dependabilidade:</p><p>1. disponibilidade;</p><p>2. confiabilidade;</p><p>3. segurança;</p><p>4. proteção.</p><p>A dimensão disponibilidade se refere à probabilidade de o sistema estar em</p><p>funcionamento, entregando os serviços conforme as solicitações dos usuários.</p><p>Em um sistema que possui sua disponibilidade semanal definida como sendo</p><p>0,999, significa que, durante uma semana, o mesmo estará em perfeito fun-</p><p>cionamento durante 99,9% do tempo. A disponibilidade de um sistema deve</p><p>ser estabelecida conforme o ambiente de utilização e suas finalidades, pois</p><p>quando é mensurada para um determinado cenário, é precipitado acreditar que,</p><p>em um cenário com características diferentes, a disponibilidade será idêntica.</p><p>A confiabilidade está diretamente relacionada com a disponibilidade;</p><p>porém, é importante definir qual é a prioridade para o desenvolvimento de um</p><p>sistema. A confiabilidade se refere à probabilidade de entrega dos resultados de</p><p>um sistema tal qual sua especificação. No que diz respeito à confiabilidade, é</p><p>de extrema importância a exatidão na definição, pois, no caso de especificações</p><p>incorretas ou incompletas, os desenvolvedores terão dificuldades, pelo fato</p><p>de não serem especialistas no domínio do sistema.</p><p>Essas duas dimensões podem ser expressas em termos quantitativos. Em</p><p>algumas situações, é possível colocar a disponibilidade de um sistema junta-</p><p>mente com a confiabilidade, pois, quando um sistema não está disponível, por</p><p>exemplo, ele também não está fornecendo os serviços especificados. Porém, é</p><p>possível haver sistemas com baixa confiabilidade, mas disponíveis. Contanto</p><p>que as falhas de sistema sejam rapidamente reparadas e não causem danos</p><p>aos dados, a baixa confiabilidade pode não ser um problema em alguns casos.</p><p>A dimensão segurança reflete a habilidade do sistema em operar nor-</p><p>malmente ou não, sem o perigo de causar grandes prejuízos gerados por</p><p>5Confiabilidade de software</p><p>falhas catastróficas a pessoas ou ambientes. É extremamente importante que</p><p>a segurança de software seja considerada, pois cada vez mais os sistemas</p><p>incorporam controles baseados em software. A segurança deve assegurar que</p><p>não ocorram acidentes e que as consequências catastróficas sejam minimizadas.</p><p>Esses objetivos podem ser alcançados de três maneiras:</p><p>1. Prevenção de perigos: fundamenta-se na concepção do sistema baseado</p><p>na minimização de riscos.</p><p>2. Detecção e remoção de perigos: a concepção do sistema tem como</p><p>premissas a detecção e a remoção dos perigos antes da ocorrência.</p><p>3. Limitação de danos: os sistemas devem incluir recursos de proteção</p><p>que minimizem os danos quando os mesmos surgirem.</p><p>A dimensão de proteção se refere à realização de análises do sistema, no</p><p>sentido de definir se o mesmo pode resistir às tentativas de intrusões, aciden-</p><p>tais ou deliberadas. Em alguns casos, esta é a dimensão mais importante da</p><p>confiança de um sistema, como sistemas militares, de comércio eletrônico e</p><p>de transações bancárias.</p><p>No que diz respeito a custos, os mesmos tendem a aumentar de maneira</p><p>exponencial conforme o nível de confiança que se deseja alcançar. Isso ocorre</p><p>devido ao uso de técnicas de desenvolvimento mais caras, além de o preço</p><p>de hardware confiável também ser mais elevado. Além disso, a necessidade</p><p>de realizar testes de validação para os clientes e órgãos reguladores também</p><p>gera uma elevação nos custos, conforme Gama (2014). A Figura 4 apresenta</p><p>a relação entre custo e confiança.</p><p>Confiabilidade de software6</p><p>Figura 4. Curva que representa o custo em função do nível de confiança.</p><p>Fonte: Sommerville (2008).</p><p>Cu</p><p>st</p><p>o</p><p>Confiança</p><p>Baixa Média Alta Muito</p><p>alta</p><p>Super</p><p>alta</p><p>Além das quatro principais propriedades da dimensão confiança que já</p><p>foram apresentadas, outras também podem ser definidas conforme mostrado</p><p>a seguir.</p><p> Reparabilidade: essa propriedade se refere à minimização de inter-</p><p>rupções causadas por falhas no sistema. Quando se tem acesso ao</p><p>código-fonte de um sistema, é possível melhorar essa propriedade, pois</p><p>será possível realizar as alterações necessárias.</p><p> Manutenibilidade: refere-se à capacidade de realização de alterações no</p><p>sistema, conforme os requisitos demandados pelos usuários. Ou seja,</p><p>é a capacidade de realizar atualizações sem a ocorrência de erros e de</p><p>modo que seja viável, do ponto de vista econômico.</p><p> Capacidade de sobrevivência: principalmente nos sistemas para internet,</p><p>esta é uma propriedade importante, pois se refere à capacidade de um</p><p>sistema se manter em funcionamento durante um ataque, mesmo que</p><p>seja sem todas as funcionalidades.</p><p> Tolerância a erros: essa propriedade se refere à capacidade do sistema</p><p>em evitar falhas oriundas de entradas erradas realizadas por usuários.</p><p>Esses erros devem ser detectados e corrigidos ou informados.</p><p>7Confiabilidade de software</p><p>A especificação de confiabilidade de um sistema pode ser definida como</p><p>um atributo mensurável, ou seja, pode ser acompanhada periodicamente por</p><p>meio de medições relacionadas ao comportamento do sistema ao longo do</p><p>tempo. Por exemplo, uma especificação de sistema pode ser a quantidade de</p><p>reinicializações durante uma semana. Caso seja definido, nesse caso, que a</p><p>quantidade de reinicializações seja duas vezes (no máximo) em uma semana,</p><p>basta monitorar o sistema para verificar se a especificação está sendo cumprida.</p><p>Caso não seja, é necessário avaliar a viabilidade de modificações no sistema,</p><p>a fim de garantir a especificação de confiabilidade.</p><p>Os requisitos de funcionalidade podem ser de dois tipos: funcionais e não</p><p>funcionais. Os requisitos não funcionais são quantitativos e definem a quan-</p><p>tidade de falhas aceitável ou o número de paradas permitido. Já os requisitos</p><p>funcionais se referem aos defeitos toleráveis do sistema, garantindo que os</p><p>mesmos não se tornem falhas.</p><p>Existem três métricas de confiabilidade utilizadas:</p><p>1. POFOD (probability of failure on demand): essa métrica especifica a</p><p>confiabilidade a partir da probabilidade de falha sob demanda. É mais</p><p>indicada para casos em que uma falha sob demanda possa causar uma</p><p>falha geral do sistema.</p><p>2. ROCOF (rate of occurrence of failures): é a taxa de ocorrência de</p><p>falhas em um determinado período. Essa métrica é mais indicada para</p><p>situações em que existem demandas regulares no sistema.</p><p>3. AVAIL (availability): essa métrica se refere à probabilidade de o sistema</p><p>operar com o surgimento de demandas.</p><p>A utilização da redundância e diversidade de hardware, de processos de</p><p>software e de sistemas de software é essencial para o desenvolvimento de</p><p>sistemas confiáveis. As arquiteturas de sistemas confiáveis podem ser de</p><p>diferentes estilos, como sistemas de proteção, arquiteturas de automonitora-</p><p>mento, programação multiversão e diversidade de software.</p><p>A arquitetura de sistemas de proteção é baseada no monitoramento do</p><p>ambiente de modo independente. Conforme as observações dos sensores,</p><p>o sistema de proteção pode ser ativado para um determinado processo ou</p><p>equipamento. Um bom exemplo é um sistema de controle de tráfego de trens,</p><p>que, ao detectar que o trem cruzou por um sinal vermelho, ativa o processo</p><p>de desaceleração do trem.</p><p>As arquiteturas de sistemas de automonitoramento, como o próprio nome</p><p>diz, funcionam com o próprio sistema realizando monitoramento baseado em</p><p>Confiabilidade de software8</p><p>cálculos. Caso seja detectada alguma falha, o próprio sistema deve realizar</p><p>alguma ação de solução. Esse tipo de arquitetura é indicado para sistemas</p><p>em que a confiabilidade é mais importante do que a disponibilidade. Como</p><p>exemplo, pode-se citar um sistema de tratamento e diagnóstico médico, em que</p><p>uma resposta incorreta pode levar a um diagnóstico ou tratamento inadequado.</p><p>As arquiteturas de sistema baseadas em programação multiversão (N-</p><p>-version) utilizam como estratégia o desenvolvimento realizado por várias</p><p>equipes. As diferentes versões do sistema geradas são executadas separada-</p><p>mente, em computadores diferentes. As saídas são comparadas e, quando forem</p><p>inconsistentes, são rejeitadas. Nesse caso, outras versões do sistema deverão</p><p>estar disponíveis, a fim de encontrar duas versões com resultados consistentes.</p><p>Todas as arquiteturas citadas anteriormente são baseadas na diversidade de</p><p>software, ou seja, em processos de implementação independentes. Estes têm</p><p>como base o fato de que os erros não serão comuns; sendo assim, os sistemas</p><p>não falharão ao mesmo tempo e da mesma forma.</p><p>Aplicação da dimensão confiança</p><p>Para que seja aplicada a dimensão confi ança no contexto de desenvolvimento</p><p>de sistemas, vamos utilizar como</p><p>exemplo o sistema de controle da bomba de</p><p>insulina, apresentado por Sommerville (2008). A bomba de insulina é utilizada</p><p>por diabéticos para medir a glicose do sangue, utilizando um microssensor</p><p>que calcula a dose necessária para a metabolização da glicose. A Figura 5</p><p>apresenta o modelo de fl uxo de dados para um sistema como este.</p><p>Figura 5. Fluxo de dados do sistema da bomba de insulina.</p><p>Fonte: Adaptada de Gama (2014, documento on-line).</p><p>Sangue Sensor de</p><p>açúcar no</p><p>sangue</p><p>Parâmetros</p><p>de sangue Nível de açúcar</p><p>no sangue</p><p>Análise</p><p>do açúcar</p><p>no sangue</p><p>Controlador</p><p>de liberação</p><p>de insulina</p><p>Cálculo de</p><p>insulina</p><p>necessária</p><p>Insulina</p><p>necessária</p><p>Comandos</p><p>de controle</p><p>de bombaInsulina</p><p>Bomba de</p><p>insulina</p><p>9Confiabilidade de software</p><p>Nesse contexto, os requisitos de confiança do sistema são:</p><p> a disponibilidade do sistema consiste na liberação de insulina sempre</p><p>que for requisitada;</p><p> é imprescindível a confiança na quantidade liberada de insulina pelo</p><p>sistema;</p><p> não poderão ser liberadas doses excessivas de insulina pelo sistema.</p><p>Do ponto de vista das quatro principais propriedades da dimensão con-</p><p>fiança, deve-se ter:</p><p>1. Disponibilidade: o sistema deve funcionar sempre que for solicitado,</p><p>conforme os horários e rotinas dos hospitais que realizam o tratamento</p><p>por meio do sistema.</p><p>2. Confiabilidade: o sistema deve fornecer sempre as doses corretas de</p><p>insulina, conforme as especificações definidas no projeto do sistema.</p><p>3. Segurança: o sistema não poderá liberar doses inadequadas de insulina,</p><p>pois isso é uma potencial ameaça de vida.</p><p>4. Proteção: o sistema deve garantir que não ocorra uma programação</p><p>indevida do sistema; como esse sistema não opera em rede, não é alvo</p><p>de ataques de hackers.</p><p>Para esse sistema de controle da bomba de insulina, as dimensões confia-</p><p>bilidade, disponibilidade e segurança são as mais importantes, pois, sempre</p><p>que o sistema for requisitado, deverá estar em funcionamento. A adminis-</p><p>tração das doses de insulina deve ser precisa, a fim de evitar problemas que</p><p>podem até deixar um paciente em estado de coma. A proteção também deve</p><p>ser considerada, pois, caso o sistema venha a ser sabotado, isso se dará via</p><p>acesso físico ao equipamento — por exemplo, com o desligamento de algum</p><p>cabo. Nesse caso, os sensores do sistema devem parar imediatamente o seu</p><p>funcionamento, a fim de evitar que sejam administradas doses erradas de</p><p>insulina ou que ocorra alguma outra anomalia.</p><p>Do ponto de vista da reparabilidade e manutenibilidade, o sistema da bomba</p><p>de insulina deverá permitir que sejam realizadas atualizações no sistema,</p><p>com o objetivo de restringir a possibilidade de falhas que possam vir a causar</p><p>interrupções. Essas atualizações podem ser demandadas pelos especialistas</p><p>ou pelos desenvolvedores, caso eles detectem uma possibilidade de melhoria</p><p>na performance do sistema ou uma correção de falhas.</p><p>Confiabilidade de software10</p><p>No que se refere à capacidade de sobrevivência do sistema de bomba de</p><p>insulina, como o mesmo não funciona conectado à internet ou à rede local,</p><p>esta acaba sendo uma propriedade irrelevante. Já a propriedade de tolerância</p><p>a erros deve garantir que, caso ocorram entradas fora de contexto, como doses</p><p>de insulina não convencionais nos tratamentos, sejam gerados alarmes que</p><p>possam corrigir ou informar o operador do sistema.</p><p>Pode-se considerar esse software para controle da bomba de insulina como</p><p>um sistema crítico de segurança primária, pois a ocorrência de falhas pode</p><p>causar danos significativos aos usuários. Em um sistema crítico, é impres-</p><p>cindível que todos os perigos envolvidos com a utilização do sistema sejam</p><p>conhecidos e sejam contemplados na especificação de confiabilidade. Com</p><p>base nos perigos elencados para o desenvolvimento de sistemas críticos de</p><p>segurança, como o da bomba de insulina, são desenvolvidos sistemas capazes</p><p>de monitorar as condições perigosas que podem causar falhas.</p><p>ANSI/IEEE. STD-729. Standard glossary of software engineering terminology. New Jersey:</p><p>ANSI/IEEE, 1991.</p><p>AVIZIENIS, A.; LAPRIE, J.; RANDELL, B. Fundamental concepts of dependability. Newcastle</p><p>upon Tyne: University of Newcastle upon Tyne, 2001.</p><p>GAMA, K. Sistemas críticos. Recife: Universidade Federal de Pernambuco, 2014. Dis-</p><p>ponível em: <http://www.cin.ufpe.br/~kiev/IF682/03_SistemasCriticos.pdf>. Acesso</p><p>em: 4 fev. 2019.</p><p>HARTZ, M.; WALKER, E. Introduction to software reliability: a state of the art review. [S.l.]:</p><p>The Center, 1996.</p><p>LYU, M. R. Handbook of software reliability engineering. New York: McGraw-Hill, 1995.</p><p>RIBEIRO, R. A. Planejamento e controle. 2011. Disponível em: <https://pcmusina.wordpress.</p><p>com/category/planejamento-e-controle/>. Acesso em: 4 fev. 2019.</p><p>SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Prentice Hall, 2008.</p><p>11Confiabilidade de software</p><p>Conteúdo:</p>