Engenharia de Software, 8. edio.

Captulo 9 Slide 1
Especificao de Sistemas
Crticos
Prof. Mrcio Lopes Cornlio
Slides originais elaborados por Ian Sommerville
O autor permite o uso e a modificao dos slides para fins didticos
Engenharia de Software, 8. edio. Captulo 9 Slide 2
Requisitos de confiana
!
Requisitos funcionais: so gerados para
definir os recursos de verificao e de
recuperao de erros e proteo contra
falhas de sistema.
!
Requisitos no funcionais: so gerados para
definir a confiabilidade e a disponibilidade
necessria ao sistema.
!
Requisitos de excluso: so os que definem
os estados e as condies que no devem
surgir.
Engenharia de Software, 8. edio. Captulo 9 Slide 3
Especificao dirigida a riscos
!
A especificao de sistemas crticos deve
ser dirigida a riscos.
!
Essa abordagem foi amplamente usada em
sistemas crticos de segurana e de
proteo.
!
O objetivo do processo de especificao
compreender os riscos (segurana,
proteo, etc.) enfrentados pelo sistema e
definir requisitos que reduzam esses riscos.
Engenharia de Software, 8. edio. Captulo 9 Slide 4
Estgios da anlise baseada em riscos
!
Identificao de riscos
Identificar os riscos potenciais que podem surgir.
!
Anlise e classificao de riscos
Avaliar a severidade de cada risco.
!
Decomposio de riscos
Decompor os riscos para descobrir suas causas
potenciais de origem.
!
Avaliao de reduo de riscos
Definir como cada risco deve ser eliminado ou reduzido
quando o sistema projetado.
Engenharia de Software, 8. edio. Captulo 9 Slide 6
Identificao de riscos
!
Identificar os riscos enfrentados pelo sistema crtico.
!
Em sistemas crticos de segurana, os riscos so os
perigos que podem levar a acidentes.
!
Na identificao de riscos, voc deve identificar as
classes de risco e as posies dos riscos nessas
classes
!
Riscos relativos a software: falha de fornecimento
de servio ou falha de sistemas de monitorao
proteo


Engenharia de Software, 8. edio. Captulo 9 Slide 7
Riscos da bomba de insulina
!
Dose excessiva de insulina (falha de servio).
!
Dose insuficiente de insulina (falha de servio).
!
Falha de energia devido ao desgaste da bateria
(eltrico).
!
Interferncia eltrica com outros equipamentos
mdicos (eltrico)
!
Mau contato de sensor e atuador (fsico)
!
Partes do equipamento quebradas no corpo (fsico).
!
Infeco causada por introduo de equipamento
(biolgico).
!
Reao alrgica aos materiais ou insulina
(biolgico).
Engenharia de Software, 8. edio. Captulo 9 Slide 8
Anlise e classificao de riscos
!
O processo relacionado com o entendimento da
probabilidade de ocorrncia de um risco e as
conseqncias potenciais, se um acidente ou
incidente ocorrer.
!
Os riscos podem ser classificados como:
Intolervel. Nunca deve surgir ou resultar em um acidente.
To baixo quanto razoavelmente prtico (ALARP). Deve
minimizar a possibilidade de um risco dadas as restries como
custo e prazo.
Aceitvel. As conseqncas do risco so aceitveis, e custos
extras no devem ser incorridos para reduzir a probabilidade de
perigo.
Engenharia de Software, 8. edio. Captulo 9 Slide 11
Avaliao de riscos
!
Estima a probablidade e a severidade do
risco
!
Normalmente, no possvel fazer isso de
forma precisa e, assim, os valores relativos
so usados como improvvel, rara, muito
alta, etc.
!
O objetivo deve ser excluir os riscos cujas
ocorrncias so provveis, ou aqueles que
tm alta severidade.
Engenharia de Software, 8. edio. Captulo 9 Slide 13
Decomposio de riscos
!
Est relacionada com a descoberta das causas da
origem dos riscos em um sistema particular.
!
Essas tcnicas foram derivadas, principalmente, de
sistemas crticos de segurana, e podem ser:
Tcnicas indutivas bottom-up. Iniciam com uma falha de
sistema proposta e avaliam os perigos que poderiam
ocorrer a partir dessa falha;
Tcnicas dedutivas top-down. Iniciam com um perigo e
deduzem-se quais poderiam ser as causas.


Engenharia de Software, 8. edio. Captulo 9 Slide 14
Anlise de rvore de defeitos
!
uma tcnica dedutiva top-down.
!
Coloca o risco ou perigo na raiz da rvore e
idenfica os estados de sistema que
poderiam levar a esse perigo.
!
Onde apropriado, ligar esses estados por
meio dos smbolos e ou ou.
!
A meta deve ser minimizar o nmero de
causas isoladas de falha de sistema.
Engenharia de Software, 8. edio. Captulo 9 Slide 16
Avaliao de reduo de riscos
!
O objetivo desse processo identificar
requisitos de confiana que especificam
como os riscos deveriam ser gerenciados e
assegurar que acidentes/incidentes no
ocorram.
!
Estratgias de reduo de riscos
Preveno de riscos;
Deteco e remoo de riscos;
Limitao de danos.
Engenharia de Software, 8. edio. Captulo 9 Slide 17
Uso estratgico
!
Em sistemas crticos, normalmente so
usadas uma mistura de estratgias.
!
Em um sistema de controle de planta
qumica, o sistema incluir sensores para
detectar e corrigir excesso de presso no
reator.
!
Contudo, incluir tambm um sistema de
proteo independente que abre uma
vlvula de alvio caso seja detectado algum
perigo de alta presso.
Engenharia de Software, 8. edio. Captulo 9 Slide 18
Riscos de software
Bomba de insulina
!
Erros de aritmtica
Um clculo causa overflow ou underflow do
valor de uma varivel;
Incluir talvez um tratador de exceo para cada
tipo de erro aritmtico.
!
Erros de algoritmo
Comparar a dose a ser liberada com a dose
anterior ou doses mximas seguras. Reduzir a
dose caso seja muito alta.


Engenharia de Software, 8. edio. Captulo 9 Slide 25
Especificao de proteo
!
Possui algumas semelhanas com a especificao de segurana
No possvel especificar os requisitos de proteo
quantitativamente;
Os requisitos so mais freqentemente do tipo no deve que
do tipo deve.
!
Diferenas
No h noo bem definida de um ciclo de vida de proteo
para gerenciamento; No h padres;
Ameaas genricas ao invs de perigos especficos de sistema;
Tecnologia madura de proteo (criptografia, etc.). Contudo,
existem problemas co sua transferncia para uso geral;
O domnio de um fornecedor nico (ex. Microsoft) significa que
um grande nmero de sistemas pode ser afetado pela falha de
proteo.
Engenharia de Software, 8. edio. Captulo 9 Slide 27
Estgios na especificao de
proteo
!
Identificao e avaliao de ativos
Os ativos (dados e programas) e seus nveis necessrios de
proteo so identificados. A proteo necessria depende do
valor do ativo, de tal modo que um arquivo com senhas
(digamos) tem mais valor que um conjunto de pginas Web
pblicas.
!
Anlise de ameaas e avaliao de riscos
Possveis ameaas de proteo so identificadas, e os riscos
associados a cada uma dessas ameaas so estimados.
!
Atribuio de ameaas
Ameaas identificadas so relacionadas aos ativos, de modo
que, para cada ativo identificado, exista uma lista de ameaas
associada.
Engenharia de Software, 8. edio. Captulo 9 Slide 28
Estgios na especificao de
proteo
!
Anlise de tecnologia
As tecnologias de proteo disponveis e sua
aplicabilidade em relao s ameaas
identificadas so avaliadas.
!
Especificao de requisitos de proteo
Os requisitos de proteo so especificados.
Quando apropriado, sero identificadas
explicitamente as tecnologias de proteo que
podem ser usadas para proteo contra
diferentes ameaas ao sistema.
Engenharia de Software, 8. edio. Captulo 9 Slide 29
Tipos de requisitos de proteo
!
Requisitos de identificao.
!
Requisitos de autenticao.
!
Requisitos de autorizao.
!
Requisitos de imunidade.
!
Requisitos de integridade.
!
Requisitos de deteco de intruso.
!
Requisitos de no rejeio.
!
Requisitos de privacidade.
!
Requsitos de auditoria de proteo.
!
Requisitos de proteo de manuteno de sistema.


Engenharia de Software, 8. edio. Captulo 9 Slide 31
Especificao de confiabilidade de
software
!
Confiabilidade de hardware
Qual probabilidade de um componente de hardware falhar
e quanto tempo levaria para reparar esse componente?
!
Confiabilidade de software
Qual a probabilidade que um componente de software
produzir uma sada incorreta? As falhas de software so
diferentes das falhas de hardware, pois o software no se
desgasta. Ele pode continuar em operao mesmo depois de
produzir um resulado incorreto.
!
Confiabilidade de operador
Qual a probabilidade de o operador de um sistema cometer
um erro?
Engenharia de Software, 8. edio. Captulo 9 Slide 32
Requisitos funcionais de
confiabilidade
!
Uma faixa predefinida de todos os valores que so
inseridos pelo operador ser definida, e o sistema
verificar se todas as entradas do operador esto
dentro desta faixa.
!
O sistema, quando iniciado, verificar todos os
discos por blocos defeituosos.
!
O sistema deve usar programao em N-verses
para implementar o sistema de controle de freios.
!
O si stema deve ser i mpl ementado em um
subconjunto seguro da linguagem Ada e verificado
usando a anlise esttica.
Engenharia de Software, 8. edio. Captulo 9 Slide 33
!
Mtricas de confiabilidade so unidades de
medio da confiabilidade do sistema.
!
A confiabilidade de sistema medida pela
contagem do nmero de falhas operacionais
e, quando apropriado, relacionando-o s
demandas feitas ao sistema e ao tempo em
que o sistema esteve operacional.
!
Um programa de medio a longo prazo
necessrio para avaliar a confiabilidade dos
sistemas crticos.
Mtricas de confiabilidade
Engenharia de Software, 8. edio. Captulo 9 Slide 34
Probabilidade de falha sob demanda
(POFOD)
!
a probabilidade que o sistema falhar quando
uma solicitao de servio for feita. til quando as
demandas de servios so intermitentes e,
relativamente, pouco freqentes.
!
apropriado para sistemas de proteo onde os
servios so demandados ocacionalmente, e onde
existem srias conseqncias caso o servio no
seja prestado.
!
relevante para muitos sistemas crticos de
segurana, com exceo dos componentes de
gerenciamento
Sistema de desligamento de emergncia em uma planta
qumica.
Engenharia de Software, 8. edio. Captulo 9 Slide 35
Taxa de ocorrncia de falhas
(ROCOF)
!
Reflete a taxa de ocorrncia de falhas no sistema.
!
Um ROCOF de 0.002 significa que 2 falhas so
provveis em cada 1000 unidades de tempo de
operao, por exemplo, 2 falhas por 1000 horas de
operao.
!
relevante para sistemas operacionas e sistemas
de processamento de transaes, onde o sistema
tem de processar um grande nmero de solicitaes
similares que so relativamente freqentes
Sistema de processamento de cartes de crdito e sistema de
reservas de vo.
Engenharia de Software, 8. edio. Captulo 9 Slide 36
Tempo mdio para falha
(MTTF)
!
a medida de tempo entre as falhas observadas do
sistema. a recproca do ROCOF para sistemas
estveis.
!
MTTF de 500 significa que o tempo mdio entre
falhas de 500 unidades de tempo.
!
Relevante para sistemas com transaes longas,
isto , onde o processamento de sistema leva um
longo temo. MTTF deve ser maior que o tempo de
transao
Sistemas de projeto auxiliado por computador, onde um
projetista trabalhar em um projeto por vrias horas e sistemas
de processamento de texto.


Engenharia de Software, 8. edio. Captulo 9 Slide 37
Disponibilidade
(AVAL)
!
a medida da frao de tempo que o sistema est
disponvel para o uso.
!
Leva em conta o tempo de reparo e o de reincio.
!
Disponibilidade de 0.998 significa que o software
est disponvel para 998 das 1.000 unidades de
tempo.
!
relevante para sistemas non-stop e
processamento contnuo
Sistemas de comutao telefnica e sistemas de
sinalizao ferroviria.
Engenharia de Software, 8. edio. Captulo 9 Slide 39
!
O nvel necessrio de confiabilidade de sistema
deve ser expresso quantitativamente.
!
Confiabilidade um atributo dinmico do sistema
as especificaes de confiabilidade relacionadas ao
cdigo fonte so significativas.
No mais do que N defeitos/1000 linhas;
Isao til somente para uma anlise de processo de ps-
entrega, onde voc est tentando avaliar quo boas so
as suas tcnicas de desenvolvimento.
!
Uma mtrica de confiabilidade apropriada deve ser
escolhida para especificar a confiabilidade global do
sistema.
Especificao no funcional de
confiabilidade
Engenharia de Software, 8. edio. Captulo 9 Slide 40
Especificao de requisitos no
funcionais
!
As medies de confiabilidade NO levam
em conta as conseqncias das falhas.
!
Os defeitos transientes podem no ter
conseqncias reais, mas outros defeitos
podem causar perda ou corrupo de dados
e perda do servio de sistema, ou seja,
falhas
!
Pode ser necessrio identificar as classes de
falhas diferentes e usar diferentes mtricas
para cada uma delas.
Engenharia de Software, 8. edio. Captulo 9 Slide 41
Conseqncias de falhas
!
Ao especificar a confibilidade, no
somente o nmero de falhas de sistema que
importa, mas as conseqncias dessas
falhas.
!
Falhas que tm srias conseqncias so
claramente mais danosas que aquelas onde
o reparo e a recuperao so diretos.
!
Em alguns casos, portanto, especificaes
de confiabilidade diferentes para tipos
diferentes de falhas podem ser definidas.


Engenharia de Software, 8. edio. Captulo 9 Slide 43
!
Para cada subsistema, analise as conseqncias das
possveis falhas do sistema.
!
A partir da anlise de falhas do sistema, divida as
falhas em classes apropriadas.
!
Para cada classe de falha identificada, defina a
confiabilidade usando uma mtrica apropriada.
Mtricas diferentes podem ser usadas para requisitos
de confiabilidade diferentes.
!
Identificar requisitos funcionais de confiabilidade para
reduzir as chances de falhas crticas.
Passos para uma especificao de
confiabilidade
Engenharia de Software, 8. edio. Captulo 9 Slide 44
Sistema auto-atendimento de banco
(ATM)
!
Cada mquina na rede usada 300 vezes
por dia
!
O banco tem 1.000 mquinas
!
O tempo de vida da release do software de
2 anos
!
Cada mquina trata aproximadamente
100.000 transaes
!
Cerca de 300.000 transaes de banco de
dados no total por dia
Engenharia de Software, 8. edio. Captulo 9 Slide 46
Validao da especificao
!
impossvel validar empiricamente especificaes
de confiabilidade muito altas.
!
Nenhuma corrupo de banco de dados significa
POFOD menor do que 1 em 200 milhes.
!
Se uma transao leva 1 segundo, ento a
simulao de transaes de um dia leva 3,5 dias.
!
Levaria mais tempo que o tempo de vida do sistema
para test-lo pela confiabilidade.