Confiabilidade de Software

Apresentação em tema: "Confiabilidade de Software"— Transcrição da apresentação:

1 Confiabilidade de Software
Definições Modos de falha do Software Erros de especificação Projeto de sistemas de software Geração do código Estrutura do software e modulariedade Estilo de programação Tolerância a falhas Linguagens Sistemas de tempo real Confiabilidade dos dados Verificação do Software Circuitos Ocultos Teste de Software Interface entre Hardware e Software Conclusões

2 Confiabilidade de Software
1) Definições Atualmente existe a tendência da cada vez mais o software executar funções que eram delegadas ao hardware, além disto os custo dos microprocessadores diminuíram. Na maioria dos caso isso trás vantagem do ponto de vista da confiabilidade já que diminui-se a complexidade, tornando-se o hardware mais robusto, além disto, o software não falha da mesma forma que o hardware. Como os programas são uma série de comandos e caminhos lógicos a chance de erros é grande. A confiabilidade de software preocupa-se em minimizar os erros impondo uma disciplina de programação, verificação e testes.

3 Hardware Software Falhas podem ser causadas por deficiências no projeto, produção, uso e manutenção. Falhas são devido a erros de projeto. Falhas podem ser devido ao desgaste ou outro fenômeno. As vezes existem advertências antes da falha ocorrer. Não há desgastes. As falhas ocorrem sem advertências. Reparos podem ser feitos de forma a tornar o produto mais confiável. O único reparo é através do re projeto. Caso esse remova o erro, ter-se-a uma melhor confiabilidade. A confiabilidade como depende de burn-in e desgastes pode ser decrescente, constante ou crescente. Não há uma dependência com o tempo, mais sim com o esforço em detectar e corrigir erros. As falhas podem ser relacionadas com o tempo de operação. Não há uma relação temporal, falhas ocorrem quando caminhos com erros são executados. A confiabilidade está relacionada com fatores ambientais. Fatores ambientais não afetam a confiabilidade, só as entradas do programa. A confiabilidade pode ser predita conhecendo-se o projeto e fatores de uso. A confiabilidade não pode ser predita, depende apenas do fator humano no projeto. A confiabilidade pode as vezes ser melhorada por redundâncias. Redundância pode ser feita com programas distintos, feitos por diferentes equipes. Falhas obedecem a padrões previsíveis.Lista crítica de componentes e Pareto são técnicas. Falhas não são previsíveis, erros podem ocorrer aleatoriamente.

4 2) Modos de falha do Software
1) Erros de especificação A especificação do software deve cobrir todas as condições de entradas possíveis e requisitos de saídas, isto requer maiores cuidados do que uma especificação de hardware. A especificação deve ser consistente, sem conflitos de informação ou diferentes convenções em diferentes seções. A especificação deve descrever a estrutura a ser usada, os requisitos de teste e documentação necessários durante o desenvolvimento e teste, bem como requisitos básicos tais como linguagem de programação, entradas e saídas.

5 O fluxograma ao lado indica mostra um programa, onde a especificação inicial, pedia que fossem feitas três leituras, caso uma das leituras fosse >  10 unidades da média das outras duas leituras, a média das outras duas seria utilizada, caso contrária o valor a ser utilizado seria a média das três leituras. No entanto numericamente ao lado do fluxograma, indica-se uma situação prática que não estava prevista, no caso duas leituras apresentavam valores maiores do que  10 unidades.

6 2) Projeto de sistemas de software
Erros podem ocorrer como resultado de interpretação incorreta das especificações, lógica incompleta ou incorreta. Uma importante característica do sistema de software é a robustez, o termo é usado para descrever a capacidade do programa suportar condições de erro sem efeitos sérios, tais como ficar em loop ou travado. A robustez depende do projeto, já que é neste estágio que os caminhos a serem tomados pelo programa sob uma condição de erro são definidos.

7 3) Geração do código O código é a primeira fonte de erros, já que envolve uma grande quantidade de instruções de comando. Erros típicos podem ser: Erros de grafia das instruções; Número incorreto de valores; Omissão de símbolos, por exemplo parênteses; Expressões que podem tornar-se indeterminadas, tal como divisão por um valor que possa tornar-se zero.

8 3) Estrutura do software e modulariedade
A programação modular divide os requisitos do programa em requisitos menores, que podem ser separadamente especificados, escritos e testados. A programação modular torna os programas fáceis de entender (importante para reduzir erros), reduz a abrangência dos erros e facilita a tarefa de verificação. Os módulos podem ser escritos e testados rapidamente, reduzindo a probabilidade de muitas mudanças posteriores do programa. Na especificação de cada módulo deve-se estabelecer as inter relações com as outras partes do sistema. Todas as entradas e saídas devem ser especificadas. Todo este trabalho de especificação trará retornos no desenvolvimento do programa, reduzindo o tempo de escrita, correções de erros e resultando em um programa fácil de entender e modificar. Uma boa mantenabilidade garante que as modificações da lógica e das especificações sejam implementadas sem problemas.

9

10 4) Estilo de programação
Obviamente um estilo de programação disciplinado tem uma grande influência na confiabilidade e mantenabilidade do software. 5) Tolerância a falhas Programas devem ser escritos de forma que erros não causem problemas sérios ou a completa falha do sistema. O programa deve ser capaz de encontrar o seu caminho para fora de uma condição de erro, e indicar a fonte do erro. Isto pode ser atingido programando testes internos, ou verificações dos ciclos de tempo com reset e indicação do erro caso as condições não sejam atingidas. Quando a segurança é um fator relevante, é importante que o programa acione condições de segurança quando um erro ocorre. Por exemplo, o processador pode ser programado para acionar condições de segurança e indicar um problema, caso não sejam geradas saídas em dois ciclos sucessivos de programa, ou caso o valor mude mais do que um valor pré determinado.

11 A tolerância a falhas também pode ser feita por redundâncias do software. Para sistemas de alta segurança, programas codificados separadamente podem ser arranjados para rodar simultaneamente em controladores separados mais conectados, ou por divisão de tempo em um mesmo controlador. Uma rotina de votação ou seleção pode ser usada para selecionar a saída a ser usada. A lógica desse procedimento é que programas codificados separadamente são muito improváveis de conter os mesmos erros, logicamente que isto não protege contra erros de especificação. A redundância também pode ser implementada no mesmo software, de forma que saídas críticas sejam verificadas por uma rotina e caso não estejam em condições adequadas, por uma outra rotina diferente.

12

13 Essas técnicas de software podem ser usadas para proteção contra falhas de hardware, tais como falhas de um sensor que prove uma entrada para um programa. Por exemplo a falha de um termostato, de não enviar um sinal para desconectar uma fonte de calor, pode ser contornada por software, que não manterá a fonte ativada por um tempo maior do que foi determinado, independente da saída do termostato. Esse tipo de facilidade pode ser melhor atendida por software, do que por hardware, sem custos extras de materiais. A possibilidade de aumentar a confiabilidade e segurança de softwares de controle de sistemas deve sempre ser analisada nas especificações na fase de projeto.

14 6) Linguagens A seleção da linguagem de computação a ser usada pode afetar a confiabilidade do software. Basicamente há dois tipos de linguagens: Programação em linguagem assembler; Programação em linguagem de alto nível. Programas em assembler são rápidos e requerem menos memória, desta forma são indicados para sistemas em tempo real. Contudo, programas assembler são mais difíceis de verificar e modificar. Programas em assembler e código de máquina são específicos para um processador. Linguagens de alto nível são independentes do processador, trabalham em conjunto com um compilador que a converte para um determinado processador. São mais fáceis de verificar e modificar, contudo consomem mais memória e são executados mais vagarosamente.

15 7) Sistemas de tempo real
Como linguagens de alto nível trabalham com um compilador, a confiabilidade do compilador afeta a confiabilidade do sistema. Compiladores desenvolvidos para novos processadores, algumas vezes causam problemas nos primeiros anos até os erros serem corrigidos. 7) Sistemas de tempo real Os sistemas de tempo real são aqueles em que o software opera de acordo com a velocidade das entradas e saídas. É essencial em tais sistemas, que o controlador do processo esteja pronto para acessar as entradas e completar as tarefas no tempo certo. Erros de timing são comuns, particularmente durante o desenvolvimento. Erros de timing são difíceis de detectar, principalmente por inspeção do código. Analisadores lógicos podem indicar falhas do hardware ou interfaces.

16 8) Confiabilidade dos dados
Há duas fontes de degradação de dados: Processamento em tempo errado, de forma que erros são gerados. Caso os dados cheguem a uma velocidade maior que o processador possa processar; Os dados podem ser corrompidos na transmissão ou na memória, onde os bits podem ser perdidos ou invertidos. Ruídos na transmissão, interferência eletromagnética e defeitos na memória podem corromper dados. Sistemas para prevenir estas falhas envolvem teorias de filas e estrutura de dados. Uma forma de redundância é repetir e capturar o mesmo dado duas vezes, comparando-o com o anterior. Códigos de detecção de erros de transmissão ou defeitos de memória são empregados, o mais simples é bit o de paridade, códigos mais elaborados como Hamming e BCH protegem contra uma quantidade maior de erros.

17 9) Verificação do Software
Poucos programas funcionam da primeira vez que são testados. O processo de verificação pode ser facilitado caso o programa tenha sido feito de forma estruturada, economizando precioso tempo de verificação. 10) Circuitos Ocultos O programa deve ser reduzido para um set de padrões topológicos, esta tarefa pode ser feita por computador. A maioria dos problemas são causados por instruções tais como GOTO ou IF THEN ELSE.

18 Circuitos ocultos causam com que: 1) Uma saída errada seja gerada; 2) Inibição indesejada de uma saída ou entrada; 3) Saída errada gerada por falha de timing; 4) Mensagem incorreta reporta o estado do sistema

19 11) Teste de Software Algumas características não são fáceis de serem testadas, tais como timing, condições de overflow e interfaces. Há limites para os testes de software, não é praticável testar exaustivamente um programa complexo, contudo o teste deve cobrir a operação sob os ambientes mais prováveis. Uma vez testado os módulos individualmente, faz-se os testes de integração que devem provar a adequação do sistema às especificações com a união dos diversos módulos. Testes de validação cobrem o ambiente real do sistema, conectado com os dispositivos de entrada e saída. Para detectar o maior número de erros, os planos de ensaios devem: Operar nas condições extremas (timing, valores máximos e mínimos das entradas, taxa de mudanças, utilização da memória); Faixas da entrada e seqüência; Tolerância a falhas (recuperação de erros).

20 12) Interface entre Hardware e Software
Muitas vezes é difícil diagnosticar se a falha é do software ou do hardware. Erros de timing devido a falhas de dispositivos, ou erros de software podem levar a essa situação.O projeto do software pode minimizar essas possibilidades, como prover diagnóstico automático e indicações de falhas. Falhas de firmware podem levar o sistema a falhar só em determinadas situações, tais falhas podem ser intermitentes. Redundâncias podem prevenir falhas de memórias dinâmicas, tal como escrita dobrada, no entanto o programa deve ser escrito de forma a armazenar e acessar a memória redundante, de forma que o programa torna-se mais complexo.

21 13) Conclusões Os elementos essenciais no desenvolvimento de um projeto de software confiável são: Especifique os requisitos completamente e em detalhes; Assegure-se que todos compreendam as especificações; Verifique as especificações, pergunte “o que acontece se....”; Projete um programa estruturado e especifique cada módulo completamente; Verifique o projeto e especificações dos módulos, comparando com as especificações do sistema; Verifique erros do programa, linha a linha; Planeje módulos e sistemas de teste cobrindo importantes combinações de entradas, particularmente valores extremos; Faça uma completa documentação de notas do desenvolvimento, testes, verificações, erros e mudanças do programa.