Revisão de Técnicas Formais e de Software

Prévia do material em texto

AULA 11 - Revisões das técnicas 
Formais e de software
Apresentação
A tecnologia tem crescido cada vez mais e ocupado diversos espaços. Hoje, os sistemas 
computadorizados estão presentes em dispositivos pessoais, como relógios e celulares, e são 
utilizados dentro e fora de casa. Sistemas sofisticados são capazes de gerenciar e operar funções 
importantes, como linhas áreas e ferrovias. Mas você já refletiu sobre os erros comuns que ocorrem 
nesse âmbito? Afinal, os sistemas são feitos por seres humanos.
Todavia, alguns softwares considerados de risco, como o sistema de freios de um avião ou um 
sistema que realiza o tratamento em um paciente, não podem errar. É óbvio que criar um sistema 
sem erros é humanamente impossível, entretanto, pode-se reduzir ou corrigir falhas através da 
aplicação de técnicas formais.
Nesta Unidade de Aprendizagem, você vai analisar as técnicas 
formais e de software, classificando-as. Ainda, você aprenderá a ordenar as principais técnicas 
formais e de software.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Classificar as técnicas formais.•
Analizar as técnicas formais e de software.•
Ordenar as principais técnicas formais e de software.•
Infográfico
Uma revisão técnica formal é fundamental para a correção de falhas durante o processo de 
desevolvimento de software. Esse processo consiste em uma revisão minuciosa de todos os 
artefados do software ou de parte deles, a fim de encontrar possíveis falhas que precisam ser 
corrigidas.
Geralmente, o processo de revisão segue um fluxo específico. Acompanhe, no Infográfico a seguir, 
o fluxo da revisão técnica formal.
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/2d365df7-7b64-4bea-8449-ed11d977741f/11601f80-52fa-4447-9799-156bebc1714b.jpg
Conteúdo do Livro
Manter a qualidade é fundamental para qualquer projeto de software, ainda mais quanto se tratam 
de softwares de segurança crítica. Nesse caso, os erros são quase inadmissíveis, pois podem colocar 
muitas coisas importantes em risco. As revisões técnicas formais (RTF) são métodos de revisão de 
artefatos de software que ajudam a identificar erros e corrigi-los o mais rápido possível, evitando, 
assim, que um erro seja propagando por diversas fases do projeto e chegue até o cliente.
No capítulo Revisões das técnicas formais e de software, da obra Qualidade de software, você vai 
classificar as técnicas formais e analisar as técnicas formais e de software, além de ordenar as 
principais delas.
Boa leitura.
QUALIDADE DE 
SOFTWARE
Paulo Antonio Pasqual Júnior
Revisão das técnicas 
formais e de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Classificar as técnicas formais.
  Analisar as técnicas formais e de software.
  Ordenar as principais técnicas formais e de software.
Introdução
Entregar para o cliente um produto de qualidade é fundamental para 
qualquer desenvolvedor ou empresa de desenvolvimento de software. 
Existem muitas formas de buscar a qualidade durante todas as fases da 
produção de um software.
Encontrar erros precocemente é fundamental para que, no fim, o 
produto possa ser entregue ao cliente com o mínimo de falhas possíveis, 
além, é claro, de minimizar os custos de correção de defeitos. As técnicas 
de revisão formal (RTF) consistem em metodologias que reservam certo 
formalismo e que, por seu rigor, ajudam na detecção de erros que possam 
se transformar em defeitos.
Neste capítulo, você vai classificar, analisar e ordenar as principais 
técnicas formais. 
Por que a revisão é importante?
As técnicas formais são recursos de revisão de software que utilizam uma 
série de metodologias de verifi cação, geralmente baseadas em regras rígidas. 
Esses métodos contribuem signifi cativamente para a identifi cação de possíveis 
falhas de sistemas. 
À primeira vista, a revisão técnica formal (RTF) pode parecer uma parte 
da fase de testes, uma vez que, por meio dela, são encontradas as falhas no 
software. Contudo, a revisão técnica vem muito antes da fase de testes. Ela 
pode ser realizada para cada artefato do software construído. Se a RTF fosse 
realizada durante a fase de testes do software, significaria que o produto já 
estaria pronto, e, nesse caso, todas as falhas de cada artefato já teriam se 
transformado em defeitos. Imagine fazer a RTF de um sistema extremamente 
complexo apenas no final do processo de desenvolvimento?
Apesar de ser uma forma importante de manter a qualidade de um produto 
de software, esses métodos não são muito utilizados, na prática, para qualquer 
software, pois são processos lentos, caros e que demandam muita energia 
para sua execução.
Sommerville (2007) explica que, apesar de essas técnicas serem extrema-
mente onerosas e se tornarem infinitamente mais complexas à medida que 
o tamanho e a complexidade do software aumentam, elas são fundamentais 
para sistemas críticos. 
Um sistema crítico é aquele que não pode apresentar falhas, pois falhas em 
certos sistemas podem acarretar danos graves e até a perda de vidas, conforme 
Sommerville (2007). Imagine, por exemplo, um software que controla trens 
em uma ferrovia. Esse software não pode falhar ao verificar se outro trem 
está vindo. Assim, o autor aponta que a confiança é um atributo fundamental 
desse tipo de sistema. 
O autor define esses sistemas críticos em três categorias:
  Sistema crítico de segurança, que se refere aos sistemas que podem 
resultar em perda de vidas humanas ou dano ambiental.
  Sistema crítico de missão, que se refere a sistemas que podem levar à 
falha em relação a metas, como o sistema de navegação de aeronaves.
  Sistema crítico de negócios, que se refere a sistemas que, ao falharem, 
podem acarretar em perdas financeiras e fracasso em negócios. 
Sommerville (2007) exemplifica esse tipo de situação com um acidente 
envolvendo um avião em processo de pouso. Na ocasião, o sistema de freio 
não foi ativado no momento necessário, porque o software entendeu que o 
avião ainda não havia pousado. Isso acarretou na colisão do avião com um 
prédio e em dezenas de mortos e feridos. De acordo com o autor, uma inves-
tigação apontou que o software se comportou exatamente como ele havia sido 
programado para fazer, ou seja, o emprego dos testes não foi suficiente para 
identificar e corrigir o erro do sistema.
Outro exemplo de software de risco seria um sistema que controlasse todos 
os carros no trânsito. Nós já sabemos que, muito em breve, os carros poderão 
Revisão das técnicas formais e de software2
andar sozinhos nas ruas, desviar de outros, traçar percursos, reconhecer a 
sinalização e evitar muitos acidentes. Também sabemos que esses sistemas 
já existem, mas ainda precisam evoluir para que esse sonho se materialize. 
Agora, a pergunta é: esse tipo de sistema está totalmente livre de falhas? É 
óbvio que a probabilidade de um sistema falhar e causar uma colisão é muito 
menor do que a probabilidade de um motorista se atrapalhar e colidir o carro 
com outro. Para um sistema como esse ser eficaz, ele necessitará de muita 
qualidade, e o emprego de técnicas formais será fundamental para a redução 
das possibilidades de erros. 
Existem métodos formais para praticamente todas as fases do software, 
desde o início do processo de concepção. As técnicas formais de revisão são 
recursos que podem ser aplicados aos softwares após certa fase do desenvol-
vimento, uma vez que se busca encontrar possíveis erros no desenvolvimento 
do software.
O processo de revisão de um software pode ser feito de muitas maneiras. 
Imagine que dois amigos iniciaram um software para ajudar no controle do 
estoque do negócio e desenvolveram um sistema sem nenhum tipo de norma. 
Ao final, o sistema faz basicamente o que eles precisavam, mas é provável que 
a quantidade de erros seja enorme. Para ajudar em um processode revisão, 
eles podem fazer testes junto com clientes, ou pedir a ajuda para outros colegas 
programadores tentarem encontrar erros. Esse processo seria, então, uma 
abordagem informal. Fazer a revisão de maneira informal é bastante simples 
e não exige métodos rígidos para a verificação de possíveis erros.
Ao contrário desse exemplo, os métodos de revisão formal exigem conhe-
cimento e rigidez durante o processo de revisão. Existe uma série de formas de 
realizar a RTF; dentre as mais comuns, podemos citar: walkthrough, peer review 
e inspeção. Na próxima seção deste capítulo, detalharemos cada uma delas. 
Análise das técnicas formais
Qualquer tipo de revisão, seja ela formal ou não, é fundamental para o reco-
nhecimento de falhas que podem se tornar defeitos após a entrega do produto. 
Descobrir erros precocemente assegura que o sistema possa ser corrigido o 
mais rápido possível, garantindo um baixo custo, tanto fi nanceiro quanto 
temporal, para a correção do produto. Pressman e Maxin (2016) ressaltam 
que a não descoberta e correção no início do processo acarreta em levar 
esses erros para outras etapas, e isso, geralmente, amplia a falha, o que vai 
tornando o problema cada vez mais difícil de encontrar e mais complexo para 
3Revisão das técnicas formais e de software
solucionar. O autor ressalta que a empresa precisa investir tempo e dinheiro; 
caso não invista, terá de fazer um investimento muito maior para a correção 
de problemas muito mais graves após a entrega do produto. 
Uma grande questão no âmbito da revisão do produto de software é o 
tempo. De acordo com Pressman e Maxin (2016), muitas empresas consideram 
não ter o tempo necessário para a realização de um processo minucioso de 
revisão, o que acarreta na entrega de um software com muitos erros. Essa 
postura faz com que o custo em tempo para manutenção e correção de erros 
seja muito maior do que se fosse utilizada uma metodologia de revisão do 
software durante o processo de desenvolvimento do produto. 
Sommerville (2007) explica que não encontrar um erro a tempo acarreta 
em um efeito cascata, que levará à ampliação do erro, transformando-o, mais 
tarde, em um defeito. Ou seja, a correção de falhas em cada artefato de software 
revisado garante que esses erros não sejam maximizados e transformados em 
defeitos, que demandariam muito mais energia para a correção. 
Apesar de haver uma relutância na aplicação de métodos de revisão formal 
para encontrar e minimizar erros, a Figura 1 mostra que, no final do processo, 
o custo de tempo em projetos que não possuíam processos de revisão é muito 
maior do que naqueles que aplicaram a RTF. Isso significa que, à primeira 
vista, pode parecer que aplicar uma revisão seja algo banal e um desperdício 
de tempo e, consequentemente, de dinheiro, mas, no médio prazo, esse custo 
é totalmente maximizado, se comparado a projetos que não aplicaram RTF.
Figura 1. Custo de tempo relacionado à aplicação ou não da revisão técnica formal.
Fonte: Pressman e Maxin (2016 , 437).
Esforço
Tempo
Sem a realização
de inspeções
Com a realização
de inspeções
Entrega
TesteCódigoProjeto
Requisitos
Planejamento
Revisão das técnicas formais e de software4
Na seção anterior, exemplificamos o teste informal de software ao apre-
sentar uma situação hipotética em que dois amigos tentam encontrar erros no 
sistema sem nenhum tipo de norma ou regra. Uma abordagem formal significa 
que é necessário o uso de formalidade para encontrar o erro. Essas metodo-
logias pressupõem, portanto, um certo rigor, que não está presente em uma 
revisão não formal. A seguir, apresentamos algumas possibilidades de RTF.
Walkthrough
Walkthrough é uma técnica bastante comum de revisão, em que é executado 
passo a passo um procedimento ou programa com vistas a encontrar erros. 
Nesse processo, um testador disponibilizará um conjunto de casos, e os in-
tegrantes da equipe de revisão buscarão simular a execução de um artefato. 
O tempo de duração desse procedimento é de aproximadamente duas horas, 
envolvendo equipes pequenas, normalmente de três a cinco pessoas. 
Peer review
Peer review ou revisão em pares consiste em um método de revisão em que 
dois programadores são responsáveis por revisar o código um do outro, de 
forma que essa revisão possa apontar inconsistências. Esse método é bastante 
utilizado e relativamente fácil de ser aplicado. As regras desse método de 
revisão podem ser estipuladas pela própria equipe de revisão, ou pela dupla 
responsável pela revisão do artefato. 
De maneira geral, um dos integrantes da dupla é responsável por programar, 
enquanto o outro fica responsável pela revisão. A cada ciclo, previamente 
definido, invertem-se os papéis, para que ambos possam tanto programar 
como revisar o código do colega. É importante ressaltar que o formalismo da 
revisão se caracteriza pelas normas que serão previamente definidas dentro 
do processo de revisão. Ou seja, uma revisão em pares, se for realizada sem 
nenhum tipo de formalismo, pode não caracterizar uma RTF. 
Inspeção
A inspeção é um tipo de RTF que envolve a revisão em equipe de um determi-
nado artefato. Geralmente, uma inspeção se baseia na distribuição do artefato 
analisado ou de parte dele para equipes distintas, seguida de reuniões de 
revisão em que são mencionados os erros encontrados para o autor do artefato. 
5Revisão das técnicas formais e de software
Nessa situação, o autor geralmente fi ca responsável pela correção dos erros 
encontrados. Em detalhes, a inspeção pode apresentar as seguintes etapas: 
1. Planejamento.
2. Apresentação.
3. Preparação.
4. Reunião de revisão.
5. Retrabalho.
6. Análise final do moderador.
Pressman e Maxin (2016) ressaltam que o momento da reunião de revisão 
precisa ser muito bem planejado e que é importante deixar claro que a revisão 
é do artefato, e não do programador. Algumas situações durante o processo 
de revisão podem afetar os egos dos participantes; por esse motivo, é sempre 
importante deixar esse processo o mais neutro possível, para que não haja 
problemas futuros na equipe. 
Esse tipo de revisão pode ser aplicado a todos os artefatos do software, 
desde a fase de requisitos. A Figura 2 detalha esse processo de inspeção. 
Figura 2. Inspeções de software.
Fonte: Adaptada de Ackerman, Buchwald, Lewski (1989).
Requisitos Projeto de
alto-nível
Projeto
detalhado Código Execução
dos testes
= Inspeção
Plano de
testes
Caso de
testes
Como podemos perceber, o processo de inspeção pode ser realizado após 
cada fase do processo de desenvolvimento de software, inclusive após a de-
finição do modelo de requisitos. É importante ressaltar que, quanto antes um 
erro for encontrado e corrigido, menor será o custo para o reparo. 
Após ser aplicado qualquer um dos processos de revisão, a equipe poderá 
levantar dados que poderão ser úteis para dar indicativos sobre a qualidade dos 
artefatos e, inclusive, para supor a situação de outros artefatos não analisados, 
baseando-se no que foi descoberto acerca dos artefatos analisados. A exemplo 
Revisão das técnicas formais e de software6
disso, temos o cálculo da densidade de erros. A seguir, detalhamos essa forma 
de complementar a RTF. 
Encontrando a densidade de erros
Independentemente da metodologia de revisão, encontrar a densidade de 
erros de um projeto pode ser importante. Existe uma série de métricas que, 
segundo Pressman e Maxin (2016), podem ser usadas para nos dar indicativos 
importantes acerca do software que está em processo de revisão. O Quadro 
1 especifi ca essas métricas. 
 Fonte: Adaptado de Pressman e Maxin (2016). 
Métrica Definição
Esforço de preparação, E
p
Esforço (em pessoas/hora) exigido 
para revisar um artefato antes 
da reunião de revisão.
Esforço de avaliação, E
a
Esforço (em pessoas/hora) que é 
despendido durante a revisão em si.
Esforço de reformulação, E
r
Esforço (em pessoas/hora) 
dedicado à correção dos erros 
revelados durante a revisão.
Tamanho do artefato 
de software, TAS
Uma medidado tamanho do artefato de 
software que foi revisto (por exemplo, o 
número de modelos UML — do inglês 
unified modeling language, ou linguagem 
de modelagem unificada —, o número 
de páginas de documento, ou, então, 
o número de linhas de código).
Erros secundários 
encontrados, Err
sec
O número de erros encontrados que 
podem ser classificados como secundários 
(exigindo menos para serem corrigidos 
do que algum esforço pré-especificado).
Erros graves 
encontrados, Err
graves
O número de erros encontrados que 
podem ser classificados como graves 
(exigindo mais para serem corrigidos do 
que algum esforço pré-especificado).
 Quadro 1. Métricas de revisão 
7Revisão das técnicas formais e de software
Estimar a densidade de erros em um projeto é importante para que se possa 
ter uma ideia de quantos erros serão encontrados em outros artefatos de um 
projeto, ou mesmo para poder estimar, de forma induzida, a possibilidade de 
erros que poderão ser encontrados em um novo projeto. A densidade de erros 
é calculada da seguinte forma: 
Densidade de Erros = Err
tot
 / TAS
Onde: Err
tot
 = Err
sec
 + Err
graves
Suponha o seguinte caso: um modelo de requisitos contém 14 erros secundários e 
dois erros graves distribuídos em 20 diagramas UML e 35 páginas. Qual é a densidade 
de erros por diagrama UML e por página?
Nesse caso, temos: 
Err
tot 
= 14 + 2 = 16
Densidade de erros por diagrama UML = 16/20 = 0,8
Densidade de erros por página = 16/35 = 0,46
Quando utilizar as revisões técnicas formais?
Podemos dizer que, no âmbito das técnicas formais de revisão, algumas apre-
sentam mais formalidade do que outras. Se fossemos estipular uma ordem 
para os métodos de revisão apresentados na seção anterior, podemos defi nir a 
peer review como a menos formal, seguida da revisão walkthrough; por fi m, 
a técnica de inspeção seria o mais formal dos métodos. 
Podemos traduzir a formalidade como o rigor que esses métodos trazem. 
Para entender melhor, pense que um método de revisão em pares pode ser feito 
de maneira aleatória, sem nenhum tipo de regra. Um colega revisa o código de 
outro e aponta deliberadamente os erros dos sistemas. Esse tipo de processo 
é um processo de revisão, mas não formal. Se o mesmo colega executar um 
processo de revisão sistematicamente definido e com procedimentos especí-
ficos, seguindo uma metodologia rígida, podemos dizer que ele aplicou uma 
revisão com certa formalidade. 
Revisão das técnicas formais e de software8
As técnicas de revisão formal são fundamentais para diminuir a possibili-
dade de defeitos no software. Como já mencionado, em especial em software 
críticos, elas são fundamentais para evitar falhas que venham a causar sérios 
danos às pessoas ou à sociedade. 
Escolher a melhor técnica de revisão dependerá dos recursos disponíveis e 
da natureza do software que está sendo desenvolvido. Um software de gestão 
empresarial certamente não demandará as mesmas necessidades de revisão se 
comparado à um software de gerenciamento de linhas ferroviárias. 
A escolha do método normalmente está relacionada ao tempo e ao orça-
mento disponível para a execução. O método de peer review pode ser executado 
rapidamente por uma dupla de programadores, sem que seja necessário deman-
dar tanto tempo, se comparado a um método de inspeção. Contudo, é sabido 
que a inspeção, por ser um método mais rígido, apresenta melhores chances 
de identificar uma quantidade superior de erros do que os outros métodos. 
O método de revisão walkthrough também exige menos tempo e possui 
menos formalidade do que as inspeções. O que determinará o melhor método 
para revisão será, certamente, a disponibilidade temporal e financeira da equipe 
para buscar uma maior qualidade, do ponto de vista do desenvolvimento do 
software. 
Revisão por amostragem
Conforme detalhamos anteriormente, o tempo e o custo são fatores críticos no 
decorrer do projeto e do desenvolvimento de um software. Muitas vezes, não 
é possível realizar a RTF para todos os artefatos do software. O problema é 
que, no caso dos softwares críticos, a revisão é imprescindível e não pode ser 
simplesmente descartada por falta de tempo ou recursos fi nanceiros. 
Nesse sentido, temos uma alternativa que pode ser benéfica em um con-
texto em que o software precisa de revisão, mas a equipe de desenvolvimento 
não possui o tempo e os recursos necessários. Essa alternativa consiste em 
estimar por amostragem a quantidade de erros em uma parte de um artefato. 
Essa estimativa pode servir como elemento para a indução dos erros no arte-
fato completo; ou, ainda, uma amostra de vários artefatos poderia indicar a 
quantidade de erros em todo o projeto. 
Basicamente, a indução é uma metodologia de pesquisa em que se ana-
lisa uma amostra significativa, encontra-se um padrão e aplica-se uma 
generalização. 
9Revisão das técnicas formais e de software
Para você entender melhor a revisão por amostragem, pense em casos em que é 
utilizado o princípio da indução para se chegar a um possível resultado. Na nossa vida, 
podemos ver exemplos de amostragem em várias situações. Um exemplo é a maneira 
como são feitas as pesquisas eleitorais. Em linhas gerais, um número relativamente 
significativo de pessoas é entrevistado — são, geralmente, pessoas de várias regiões 
que dizem em quem elas pretendem votar. Após a tabulação desses resultados, é 
feita uma estimativa de quem poderia ganhar as eleições. Esse raciocínio se baseia 
no princípio da indução: se a maioria das pessoas vai votar em um candidato X, é 
possível que todas as outras também votem, o que caracteriza um raciocínio indutivo. 
O grande problema da indução é que ela pode revelar uma realidade distinta 
do real, se a amostra não for significativa. Ou seja, quanto maior for a amostra, 
melhores são as chances de a indução estar correta. 
Vamos considerar o seguinte exemplo: uma equipe de desenvolvimento pre-
cisa revisar um artefato em um tempo ligeiramente curto e terá a possibilidade 
de revisar no máximo ¼ (25%) do artefato. Para ganhar tempo, a equipe optou 
por revisar apenas 20%, encontrando 15 erros secundários e 2 erros graves. 
Qual é a probabilidade de erros que poderão ser encontrados no artefato todo? 
A revisão por amostragem é uma possibilidade, mas ela nos dá um indicativo da 
quantidade total de erros de um artefato ou projeto de software. É importante sempre 
considerar que a indução pode não ser real, principalmente se a amostra não for 
significativa. 
Considerando-se que 20% representa 1/5 do artefato, temos: 15 × 5 + 2 × 5 
= 85. Dessa forma, podemos estimar que o artefato todo terá aproximadamente 
85 erros. É importante ressaltar que a análise por amostragem nos dá indícios 
da quantidade de erros, mas não garante uma informação totalmente confiável. 
Para se ter um resultado muito confiável, é necessário que a amostra seja 
bastante significativa. Aplicar revisões por amostragem é uma possibilidade 
Revisão das técnicas formais e de software10
em um cenário em que não se possuem todos os recursos necessários para 
a revisão completa e que envolve um software que não pode simplesmente 
não ser revisado. 
A revisão por amostragem se encaixa nos métodos de RTF mencionados 
anteriormente. A questão, nesse caso, é que apenas uma parte do software ou 
do artefato é revisada, com as mesmas técnicas e rigidez dos métodos de RTF. 
ACKERMAN, A., BUCHWALD, L., LEWSKI, F. Software inspections: an effective verification 
process. IEEE Software, v. 6, n. 3, p. 31–37, jun. 1989.
PRESSMAN, R. S.; MAXIN, B. R. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: AMGH, 2016. 
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Addison Wesley, 2007.
Leitura recomendada
REZENDE, D. A. Engenharia de software e sistemas de informação. Rio de Janeiro: Bras-
port, 2005. 
11Revisão das técnicas formais e de software
 
Dica do Professor
O tempo é um grande empecilho no desenvolvimento de software. Geralmente, os analistas desistemas e os desenvoldedores precisam de muito mais tempo para concluir um projeto de 
software.
Nesse contexto, está o processo de revisão, que, embora ocupe muito tempo, pode economizá-lo, 
poupando, ainda, dinheiro ao final do processo, quando as falhas já se caracterizaram como 
defeitos.
Acompanhe, nesta Dica do Professor, um pouco mais sobre o RTF.
Aponte a 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/22da67d8e116034eb3ba24bd29edd81f
Exercícios
1) Geralmente, as revisões técnicas formais são métodos que buscam encontrar falhas na 
qualidade do software, mas são extremamente demoradas e caras. Em que tipo de software o 
uso de métodos formais é indispensável?
A) A revisão técnica formal é útil para todos os tipos de sistemas, principalmente em softwares 
de gestão, uma vez que garante a redução de possíveis defeitos que poderão acarretar em 
prejuízos.
B) A revisão técnica formal é útil para minimizar os defeitos de um software, sendo facilmente 
aplicada durante a fase de testes. A RTF é indicada a todos os artefatos do software, sendo 
indispensável aos sistemas web.
C) A revisão técnica formal é indispensável em sistemas de gestão empresarial, pois esse tipo de 
software pode colocar pessoas em risco. A RTF é indicada para qualquer software que precise 
de qualidade.
D) A revisão técnica formal é recomendada para sistemas de monitoramento de segurança, pois 
garante que haja menor probabilidade de falhas. Dessa forma, esse tipo de revisão é 
frequentemente utilizado nesses casos para minimizar a possiblidade de falhas durante a fase 
de testes.
E) A revisão técnica formal é indispensável em sistema de segurança crítica, pois esse tipo de 
software não deve apresentar falhas, uma vez que esses sistemas envolvem impactos na 
segurança de pessoas, negócios ou meio ambiente.
 •
2) Os métodos de revisão técnica formal (RTF) são fundamentais para minimizar defeitos 
futuros em um software. Qual a relação entre a revisão e o custo do produto?
A) As RTF são úteis para corrigir erros do software enquanto o produto ainda se encontra em 
desenvolvimento, o que diminui o custo de reparo.
B) As RTF são úteis para corrigir erros de artefatos ao final do processo de desenvolvimento. 
Dessa forma, quanto maior for a revisão, maior será o custo para correção de erros.
C) Existe uma relação diretamente proporcional entre o custo do software e as RTF, já que, 
quanto maior o custo para a aplicação das RTF, maior será o valor do produto.
D) As RTF são úteis para corrigir erros, minimizando a possiblidade de propagação destes no 
decorrer do desenvolvimento. Todavia, não há relação entre as RTF e o custo do produto.
E) As RTF ajudam a aumentar o custo do produto, visto que demandam uma equipe maior para 
executá-las, garantindo a qualidade do produto final.
3) Há uma série de técnicas de revisão, formais e informais, para minimizar os erros de um 
produto de software. Cada uma delas pode ser usada em determinados contextos. Qual das 
alternativas explicita um cenário próximo do real a respeito do uso de inspeções e de pair 
review? 
A) Uma empresa está trabalhando com tempo limitado em um software. Por esse motivo, optou 
por utilizar pair review e inspeções em todos os artefatos disponíveis, para que, assim, garanta 
a qualidade do produto final, apesar da limitação de tempo.
B) Uma empresa está trabalhando em um software que necessita de revisões, dispondo de 
tempo e equipe limitados. Para os artefatos mais críticos, a empresa utilizará a técnica de 
inspeções e, para os menos críticos, a pair review.
C) Uma empresa está trabalhando em um projeto que necessita de revisões apenas em parte. 
Como ela não dispõe de tempo e equipe suficientes, optou por utilizar inspeções para os 
artefatos menos críticos e pair review para os mais críticos.
D) Uma empresa está trabalhando em um software que necessita de revisões, não dispondo de 
tempo e equipe necessários para a execução destas. Por esse motivo, a empresa optou por 
utilizar inspeções em todos os artefatos e não usar pair review.
E) Uma empresa está trabalhando no desenvolvimento de um software que necessita de 
revisões, mas, apesar de ter tempo, não dispõe de recursos financeiros para a RTF. Assim, 
optou por revisar todos os artefatos através de inspeções e parte deles usando pair review.
4) Avaliar a densidade de erros de um artefato é uma das métricas importantes para a revisão 
técnica formal. Nesse sentido, considere que um certo artefato de software apresentou 25 
erros secundários e 5 erros graves, em 10 diagramas UML e 23 páginas. Qual é a densidade 
de erros desse artefato?
A) 3 erros por diagrama UML e 1,3 erros por página.
B) 5 erros por diagrama UML e 2,2 erros por página.
C) 2,3 erros por diagrama UML e 3 erros por página.
D) 0,2 erros por diagrama UML e 0,3 erros por página.
E) 2,5 erros por diagrama UML e 2,2 erros por página. 
5) O tempo é sempre um problema para o desenvolvimento de software e, muitas vezes, por 
esse motivo, as RTF são deixadas de lado. Nesse contexto, aplicar revisões por amostragem 
pode ser uma solução. Considerando um artefato de software que apresentou 4 erros em 
uma amostra que corresponde a 1/6 do artefato, qual a quantidade esperada de erros?
A) A quantidade esperada de erros no artefato é de, aproximadamente, 24,99 erros.
B) A quantidade esperada de erros no artefato é de, aproximadamente, 24,00 erros.
C) A quantidade esperada de erros no artefato é de, aproximadamente, 20,00 erros.
D) A quantidade esperada de erros no artefato é de, aproximadamente, 24,03 erros.
E) A quantidade esperada de erros no artefato é de, aproximadamente, 20,01 erros.
Na prática
O processo de revisão é indispensável para a qualidade de software, seja ela formal ou não, 
devendo esse processo ser privilegiado, mesmo que o tempo seja curto, para que, no futuro, os 
custos com o conserto de defeitos não sejam muito maiores do que os custos para a correção de 
falhas. No caso dos sistemas críticos, aplicar um método de revisão formal é fundamental para que 
o sistema não apresente, futuramente, erros que possam, inclusive, passar pela fase de teste, 
colocando pessoas em risco.
Acompanhe, Na Prática, uma situação em que se considera a RTF para a solução de um problema.
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/0b565554-769a-4905-9752-63f64c18832f/a972b7f0-94a1-475c-9bec-feb32c738bb5.png
Saiba mais
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
Inspeções de requisitos de software em desenvolvimento 
incremental: uma experiência prática
Este artigo aborda uma experiência prática utilizando inspeções para a melhora da qualidade dos 
artefatos de software.
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: uma abordagem profissional
Leia o capítulo Técnicas de revisão, do livro Engenharia de Software:, e saiba mais sobre as diversas 
técnicas de revisão.
Conteúdo interativo disponível na plataforma de ensino!
Engenharia de Software: uma abordagem profissional.
Saiba mais sobre outros princípios de qualidade através da leitura do capítulo Conceitos de 
qualidade, do livro Engenharia de Software: uma abordagem profissional.
Conteúdo interativo disponível na plataforma de ensino!
https://www.researchgate.net/publication/255730159_Inspecoes_de_Requisitos_de_Software_em_Desenvolvimento_Incremental_Uma_Experiencia_Pratica