Sistemas Críticos, Confiabilidade e Prototipação de Software: resumo

Introdução aos Sistemas Críticos

A familiarização com a falha de sistema é essencial, pois sistemas podem entrar em colapso sem um motivo aparente. Tais falhas podem causar danos significativos, o que nos leva a tomar medidas para contornar a falta de confiança, como o uso de backups.

• Quanto maior o grau de confiança, maior o custo.
• Quanto maior a confiança, menor o desempenho (devido à verificação de estados e recuperação de falhas).
• A confiança, às vezes, é mais importante que o desempenho.

Definição de Sistemas Críticos

Um sistema é considerado crítico quando uma falha pode causar:

• Perdas econômicas;
• Danos físicos ou ambientais;
• Riscos à vida humana.

Nesses sistemas, o custo de uma falha é grande ou irreparável, tornando a confiança o requisito mais importante.

Tipos de Sistemas Críticos

• Segurança: Envolve ferimentos, riscos à vida humana e danos ambientais.
• Missão: Quando o objetivo principal não é atingido (ex: controle de aeronaves).
• Negócios: Resulta no fracasso dos negócios que utilizam o sistema (ex: sistema bancário).

Componentes Sujeitos a Falha

• Hardware: Erros de fabricação, fim da vida útil ou erro de especificação no projeto.
• Software: Enganos ou erros de implementação.
• Humanos: Má operação do sistema.

Disponibilidade e Confiabilidade

Disponibilidade: É a probabilidade de um sistema, em um determinado instante, estar operacional e capaz de fornecer os serviços requeridos.

Confiabilidade: É a probabilidade de operação livre de falhas durante um tempo especificado, em um dado ambiente, para um propósito específico.

Exemplo Comparativo:

• Sistema A: Falha uma vez por ano, mas demora 3 dias para reiniciar. (Mais confiável).
• Sistema B: Falha uma vez por mês, mas demora 10 minutos para reiniciar. (Mais disponível).

A confiabilidade é relativa e depende do contexto (ex: carro a 100 km/h vs. uso de um S.O.). Técnicas para melhorá-la incluem evitar defeitos no desenvolvimento, detectar erros em testes e implementar tolerância a defeitos.

Segurança e Proteção

Segurança (Safety)

Reflete a capacidade do sistema operar de forma normal e anormal sem oferecer ameaças às pessoas ou ao ambiente.

• Segurança Primária: A disfunção do software afeta diretamente.
• Segurança Secundária: A disfunção afeta indiretamente (ex: programas de cálculos de engenharia).

Proteção (Security)

Capacidade do sistema se proteger contra invasão acidental ou deliberada. Danos incluem interrupção de serviço, corrupção de dados e revelação de informações confidenciais.

Requisitos de Confiança

• Requisitos funcionais: Definem recursos de verificação, recuperação e proteção.
• Requisitos não funcionais: Definem a confiabilidade e disponibilidade necessária.
• Requisitos de exclusão: Definem estados e condições que não devem surgir.

Especificação Dirigida a Riscos

O objetivo é compreender os riscos e definir requisitos que os reduzam. Os estágios são:

1. Identificação de riscos: Identificar riscos potenciais.
2. Análise e classificação: Avaliar a severidade.
3. Decomposição: Descobrir as causas originais.
4. Avaliação de redução: Definir como eliminar ou reduzir o risco.

Riscos da Bomba de Insulina

• Dose excessiva ou insuficiente de insulina.
• Falha de energia (bateria).
• Interferência elétrica ou mau contato.
• Infecção ou reação alérgica.

Classificação de Riscos

• Intolerável: Nunca deve resultar em acidente.
• ALARP (As Low As Reasonably Practical): Minimizar riscos considerando custo e prazo.
• Aceitável: Consequências aceitáveis sem custos extras de redução.

Aceitabilidade Social e Avaliação

A aceitabilidade é subjetiva e determinada por fatores humanos, sociais e políticos. A sociedade torna-se menos propensa a aceitar riscos com o tempo. A avaliação estima a probabilidade e severidade (improvável, rara, alta, etc.).

Decomposição de Riscos

• Técnicas indutivas (bottom-up): Partem de uma falha para avaliar perigos.
• Técnicas dedutivas (top-down): Partem de um perigo para deduzir causas (ex: Análise de Árvore de Defeitos).

Estratégias de Redução de Riscos

• Prevenção de riscos.
• Detecção e remoção.
• Limitação de danos.

Em sistemas críticos, utiliza-se uma mistura de estratégias, como sensores de detecção e sistemas de proteção independentes.

Riscos de Software na Bomba de Insulina:

• Erros de aritmética: Overflow ou underflow (usar tratadores de exceção).
• Erros de algoritmo: Comparar doses com limites seguros.

Normas e Ciclo de Vida

A IEC 61508 é um padrão internacional para gerenciamento de segurança em sistemas de proteção. A segurança é uma propriedade emergente do sistema como um todo.

Requisitos de Segurança

• Funcionais: Como o sistema fornece proteção.
• Integridade: Confiabilidade do sistema de proteção (níveis 1 a 4).

Especificação de Proteção

Diferente da segurança, não possui ciclo de vida ou padrões tão definidos. Foca em ativos e ameaças genéricas usando tecnologias como criptografia.

Estágios da Especificação de Proteção

1. Identificação e avaliação de ativos.
2. Análise de ameaças e riscos.
3. Atribuição de ameaças aos ativos.
4. Análise de tecnologia disponível.
5. Especificação de requisitos (identificação, autenticação, autorização, privacidade, etc.).

Confiabilidade de Software

• Hardware: Probabilidade de falha física e tempo de reparo.
• Software: Probabilidade de saída incorreta (não se desgasta).
• Operador: Probabilidade de erro humano.

Métricas de Confiabilidade

• POFOD (Probabilidade de Falha sob Demanda): Útil para sistemas de proteção intermitentes.
• ROCOF (Taxa de Ocorrência de Falhas): Relevante para sistemas de processamento contínuo.
• MTTF (Tempo Médio para Falha): Importante para transações longas.
• AVAIL (Disponibilidade): Fração de tempo que o sistema está disponível.

Passos para Especificação

1. Analisar consequências de falhas por subsistema.
2. Dividir falhas em classes.
3. Definir métricas de confiabilidade para cada classe.
4. Identificar requisitos funcionais para reduzir falhas críticas.

Exemplo: Sistema de Caixa Eletrônico (ATM)

A validação empírica de confiabilidade muito alta é quase impossível, pois o tempo de teste superaria o tempo de vida do sistema.

Arquitetura de Software

A arquitetura é o framework fundamental. Decisões incluem tipo de aplicação, distribuição e estilos. Atributos principais:

• Desempenho: Minimizar comunicações.
• Proteção: Arquitetura em camadas.
• Segurança: Isolar componentes críticos.
• Disponibilidade: Redundância.
• Manutenção: Baixa granularidade.

Prototipação de Software

A prototipação é uma abordagem evolutiva para validar requisitos através de versões iniciais (protótipos). Ajuda na redução de riscos e na compreensão das necessidades dos usuários.

Benefícios e Tipos

• Prototipação Evolucionária: O protótipo é refinado até se tornar o sistema final.
• Prototipação Descartável: Usada para validar requisitos e depois jogada fora.

Vantagens: Melhoria na facilidade de uso, qualidade do projeto e redução de esforço. Problemas: Dificuldades de gerenciamento, manutenção e questões contratuais.

Técnicas de Prototipação Rápida

• Linguagens dinâmicas de alto nível.
• Programação de banco de dados.
• Reuso de componentes e frameworks (Visual Basic, JavaBeans).

Metodologias Ágeis

O desenvolvimento ad-hoc produz resultados ruins em sistemas grandes. Enquanto a engenharia tradicional foca em projetar antes de construir, as metodologias ágeis buscam flexibilidade para alterar o software conforme a necessidade.

Pontos-Chave

• A análise de riscos é a base para requisitos de confiabilidade.
• Métricas como POFOD, ROCOF, MTTF e AVAIL definem a confiabilidade quantitativamente.
• A prototipação é essencial para interfaces e validação rápida.
• Arquiteturas bem definidas suportam atributos como segurança e disponibilidade.