Análise de Perigos MO828 – Eng. Software II Prof

Apresentação em tema: "Análise de Perigos MO828 – Eng. Software II Prof"— Transcrição da apresentação:

1 Análise de Perigos MO828 – Eng. Software II Prof
Análise de Perigos MO828 – Eng. Software II Prof.- Eliane Martins Aluna: Flávia Zaroni Camargo RA: 20489

2 SAFETY Sistema seguro é aquele que está livre de acidentes ou perdas;
Não é fácil alcançar total e completa segurança, procura-se chegar o mais perto possível ao ideal; Segurança é uma propriedade do sistema, e não uma propriedade dos componentes, portanto a análise de segurança considera todo o sistema e não simplesmente os componentes;

3 Safety e Tolerância a Falhas
Utilizando o conceito tradicional de segurança (safety), poderíamos tentar aumentar a confiabilidade do sistema e introduzir técnicas de tolerância a falhas ? Este conceito não funciona porque acidentes relacionados a sistemas quase nunca estão relacionados a falta de confiabilidade ou um problema por não estar satisfazendo a especificação;

4 Perigos (Hazard) Definição de Perigos (hazards), Leveson:
“Um estado ou um conjunto de condições do sistema que combinadas com outras condições do ambiente do sistema podem levar a um acidente.” Perigo é diferente de falha. Os perigos podem resultar em um acidente. Uma falha é uma não conformidade de uma função de um componente.

5 Análise Preliminar de Perigos (PHA)
Para alcançar a segurança, devemos começar com a identificação e a análise dos perigos; Esta análise deve ter início o mais cedo possível na fase de projeto, cedo o suficiente para afetar a especificação de requisitos; Uma vez que os perigos são identificados, passos podem ser tomados para eliminá-los, reduzir seus semelhantes,ou abrandar seus efeitos; Também algumas causas dos perigos podem ser identificadas e eliminadas ou controladas;

6 Análise Preliminar de Perigos
Usualmente é impossível antecipar todas as causas potenciais de perigos, obtendo mais informações sobre eles usualmente permite grande proteção a ser provida. Como parte de PHA podem ser produzidos partes de uma árvore de falhas para operações. Como cita um dos artigos o que fizeram com um sistema chamado TRACON (Terminal Radar Approach Control)

7 Técnicas para Identificar Perigos
Modelos usados para análise de perigos são chamados de caixa preta pois não mostram detalhes de implementação; Estes modelos mostram para cada estímulo do ambiente relevante, a transição de estado; procuram mostrar o modelo de comportamento externo do sistema; Estas informações são necessárias para carregar a máquina de estado da análise de perigos (SMHA);

8 Forward / Backward Em buscas “forward” (por indução) podemos procurar estados iniciais e rastrear avançando no tempo. O resultado é um conjunto de estados ou condições que representam os efeitos em iniciar o evento; Em buscas “backward” (por dedução) a análise começa com um evento final ou estado e identifica os eventos ou estados. Buscas “backward” são úteis em acidentes, investigações e também em se eliminando ou controlando os perigos durante o desenvolvimento do sistema, investigando potenciais acidentes depois que eles tenham ocorrido;

9 Análise de Perigos (SHA)
Utilizando a lista de perigos, alto nível de segurança no projeto pode ser identificado; A análise de perigos do sistema examina interfaces entre os sub-sistemas para avaliar a segurança do sistema trabalhando; Para determinar se e como o sistema pode estar nos estados de perigos; Eliminar perigos do projeto e se possível, ou controlá-los se não for possível eliminá-los; Identificar e resolver conflitos ente os objetivos do projeto e dos pontos de segurança do projeto;

10 Análise de Perigos A análise de perigos requer algum tipo de modelo do sistema, que pode ser uma especificação do sistema escrita de maneira informal ou formatada, ou um modelo matemático formal; Diferentes modelos permitem diferentes tipos de análises e para adicional rigor; Como exemplo, em um dos artigos foi utilizado o modelo caixa preta (blackbox).

11 Metodologia Safeware A metodologia de Safeware pode ser integrada em qualquer sistema e ambiente de desenvolvimento; Em experiências desenvolvidas por Leveson e seus alunos utilizaram um projeto experimental que utiliza novas linguagens e ferramentas chamado SpecTRM (Specification Tools and Requirement Methodology); O objetivo do SpecTRM é dar suporte ao projeto, implementação e evolução de sistemas complexos e críticos em segurança;

12 Referências Demonstration of a Safety Analysis on a Complex System
System Safety in Computer-Controlled Automotive Systems. Nancy G. Levenson Demonstration of a Safety Analysis on a Complex System The Safety Requirements Engineering Dilemma. Daniel M. Berry