Confiabilidade de Software

Prévia do material em texto

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