Livro-Texto - Unidade II

Prévia do material em texto

78
Unidade II
Unidade II
Como futuros profissionais de tecnologia da informação, é essencial compreender profundamente 
conceitos como gerenciamento de defeitos e rastreabilidade, pois eles desempenham um papel 
fundamental na qualidade e no sucesso dos projetos de software.
O gerenciamento de defeitos, também conhecido como gestão de bugs ou falhas, é o processo de 
identificar, registrar, priorizar, corrigir e acompanhar defeitos encontrados em um software durante seu 
ciclo de vida. Defeitos, ou bugs, podem ser qualquer desvio ou inadequação em relação aos requisitos 
estabelecidos, ou ao comportamento esperado do software. Eles podem variar de erros simples de 
digitação até problemas complexos que comprometem a funcionalidade do sistema.
Por outro lado, a rastreabilidade é a capacidade de documentar e acompanhar a origem, a evolução 
e o destino de cada requisito, componente ou mudança em um sistema de software. Ela possibilita 
entender como e por que certas funcionalidades foram implementadas, fornecendo um contexto valioso 
para o gerenciamento de defeitos. A rastreabilidade ajuda a garantir que todas as partes interessadas 
compreendam as inter-relações entre os diferentes elementos do sistema, fornecendo uma base sólida 
para tomadas de decisão informadas ao longo do ciclo de vida do software.
Ao integrar o gerenciamento de defeitos com a rastreabilidade, é possível criar um ambiente mais 
eficaz para identificar, analisar e resolver problemas de software. Isso não apenas melhora a qualidade 
do produto final, mas também aumenta a transparência, a colaboração e a eficiência dentro da equipe 
de desenvolvimento.
A seguir, serão exploradas as práticas mais adequadas, além de ferramentas e técnicas para o 
gerenciamento de defeitos e rastreabilidade. Você aprenderá a identificar e priorizar problemas, a 
documentar e acompanhar alterações, e a utilizar ferramentas específicas para otimizar esses processos.
5 GERENCIAMENTO DE DEFEITOS E RASTREABILIDADE
O gerenciamento de defeitos e a rastreabilidade são componentes cruciais na garantia da qualidade 
de software, pois ajudam a identificar e corrigir falhas mais rapidamente, além de contribuírem para 
o aperfeiçoamento contínuo dos processos de desenvolvimento. O gerenciamento eficaz de defeitos 
começa com a identificação precisa e o registro detalhado de cada falha encontrada durante os testes 
ou no uso do software.
A identificação e o registro de defeitos possibilitam às equipes que classifiquem os problemas com 
base em sua gravidade, urgência e impacto no usuário final. Isso facilita a priorização das correções e 
ajuda a garantir que recursos críticos sejam alocados aos problemas mais significativos. Além disso, um 
registro detalhado dos defeitos fornece uma base valiosa para análises futuras, propiciando às equipes 
o entendimento claro das causas raízes dos problemas recorrentes.
79
QUALIDADE DE SOFTWARE
A análise de causa raiz é outro aspecto fundamental do gerenciamento de defeitos, pois ao entender 
por que um erro ocorreu, a equipe pode implementar medidas preventivas para evitar que problemas 
semelhantes surjam no futuro. Essa rotina envolve desde pequenas alterações no código até revisões 
abrangentes nos processos de desenvolvimento.
Além disso, a rastreabilidade desempenha um papel vital na garantia da qualidade do software. 
A capacidade de rastrear cada requisito através das fases de desenvolvimento até sua implementação 
final ajuda a garantir que todos os objetivos do projeto sejam atendidos. Ela também facilita a verificação 
da conformidade com padrões regulatórios e normas industriais, o que é especialmente importante em 
setores como saúde e finanças.
Um exemplo real da importância do gerenciamento eficaz de defeitos pode ser visto na indústria 
automotiva, na qual falhas no software podem ter consequências graves. Em 2014, uma grande 
fabricante precisou fazer recall de milhões de veículos por causa de um problema no software do sistema 
de ignição. Uma gestão mais rigorosa dos defeitos poderia ter identificado esse problema antes que os 
carros fossem entregues aos consumidores.
O gerenciamento eficaz dos defeitos e uma sólida estratégia de rastreabilidade são essenciais para 
manter altos padrões de qualidade em projetos de software, ajudando a mitigar riscos, o que contribui 
para o desenvolvimento contínuo da equipe e melhoria dos processos de construção e qualidade 
de software.
5.1 Identificação e registro de defeitos
A identificação e o registro de defeitos são etapas fundamentais no processo de garantia 
da qualidade do software, atuando como a primeira linha de defesa contra falhas que podem 
comprometer a funcionalidade, a segurança e a satisfação do usuário final. São práticas que facilitam 
a detecção precoce de problemas, além de estabelecerem uma base sólida para análises futuras e 
correções eficazes.
Para iniciar, a identificação de defeitos requer uma combinação de testes automatizados e manuais, 
onde ferramentas avançadas e a experiência dos profissionais trabalham juntas para descobrir falhas. 
Uma vez identificado um defeito, é crucial registrar todos os detalhes relevantes sobre ele, o que inclui 
informações como o ambiente em que foi encontrado, passos para reproduzi-lo, gravidade do problema, 
e qualquer outra observação que possa auxiliar na resolução deste.
O registro detalhado dos defeitos é muito importante. Primeiramente, porque ele possibilita uma 
comunicação clara entre as equipes de desenvolvimento e teste sobre o problema encontrado. Além 
disso, um histórico bem documentado dos defeitos ajuda na priorização das correções com base 
na gravidade e no impacto no usuário final. Esse registro também é essencial para realizar análises 
profundas de causa raiz, viabilizando o entendimento das vulnerabilidades em seus processos ou 
código para as equipes.
80
Unidade II
Um exemplo prático da importância desse processo pode ser observado em plataformas online 
de grande escala. Quando um bug crítico foi identificado em uma rede social popular, afetando a 
privacidade dos usuários, a rápida identificação e documentação detalhada do problema garantiram 
à equipe técnica a resolução rápida da questão, impedindo que ela escalasse para um incidente maior.
Veja a seguir um exemplo de documento que pode ser utilizado para registrar e catalogar os defeitos 
encontrados durante os testes:
Relatório de registro de defeitos de software
Projeto: Sistema de gerenciamento de biblioteca
Data: 07/04/2023
Identificação do defeito: D0001
Descrição: ao tentar adicionar um novo livro ao catálogo, o sistema exibe uma mensagem de erro e 
não salva as informações do livro.
Prioridade: alta
Severidade: crítica
Ambiente de teste:
— Sistema operacional: Windows 10
— Navegador: Google Chrome versão 100.0.0
Passos para reproduzir o defeito:
— Acesse a página de administração do catálogo de livros.
— Clique no botão “Adicionar livro”.
— Preencha os campos obrigatórios do formulário de adição de livro.
— Clique no botão “Salvar”.
Resultado esperado: o sistema deve adicionar o livro ao catálogo e exibir uma mensagem de 
confirmação de sucesso.
Resultado observado: o sistema exibe uma mensagem de erro “Erro ao salvar as informações do livro. 
Tente novamente mais tarde.” e não salva as informações do livro.
Captura de tela: (inserir link ou anexar imagem, se aplicável)
Observações adicionais:
— O problema foi replicado em diferentes navegadores e ambientes de teste.
— Ocorreu em todas as tentativas de cadastro de um novo livro no catálogo.
Figura 17 – Relatório de defeitos do software
Esse é um exemplo básico de como um relatório de registro de defeitos de software pode ser 
estruturado. Ele fornece dados detalhados sobre o defeito encontrado, como a descrição, prioridade, 
severidade, ambiente de teste, passos para reproduzir, resultado esperado e resultado observado. Isso 
ajuda os desenvolvedores a entenderem o problema e a trabalharem em sua resolução de forma eficaz.
Como resultado,uma abordagem sistemática para a identificação e o registro de defeitos não 
apenas melhora significativamente a qualidade do software, mas também fortalece a confiança dos 
usuários finais nos produtos desenvolvidos. Ao adotar práticas rigorosas nessa área, as organizações 
podem evitar retrabalho desnecessário e garantir que seus produtos atendam ou superem 
as expectativas dos clientes.
81
QUALIDADE DE SOFTWARE
5.2 Análise de causa raiz e resolução
A análise de causa raiz é um processo crítico na engenharia de software, especialmente quando 
se trata de garantir a qualidade e a confiabilidade dos sistemas. Esse processo envolve investigar 
profundamente os defeitos identificados para descobrir as razões fundamentais que os causaram. 
Ao entender essas causas subjacentes, as equipes podem implementar soluções duradouras que resolvam 
o problema atual, bem como previnam sua recorrência no futuro.
Uma abordagem eficaz para a análise de causa raiz começa com a coleta e a revisão detalhada das 
informações sobre o defeito. Assim, é preciso saber como ele foi descoberto; em quais condições ele 
ocorre; e se houve qualquer tentativa anterior de correção. Ferramentas como diagramas de Ishikawa 
e o método dos 5 porquês são frequentemente utilizados para facilitar essa investigação, ajudando a 
mapear todas as possíveis origens do problema.
 Observação
O diagrama de Ishikawa, também conhecido como diagrama de espinha 
de peixe ou diagrama de causa e efeito, por exemplo, é uma ferramenta visual 
utilizada para encontrar e organizar as possíveis causas de um problema ou 
efeito específico. Ele foi nomeado em homenagem ao engenheiro japonês 
Kaoru Ishikawa, que o popularizou na década de 1960 como um método 
para melhorar a qualidade dos processos industriais.
Ainda muito utilizado, o diagrama é estruturado visualmente como uma espinha de peixe, com as 
espinhas representando o problema ou o efeito a ser analisado, e as espinhas laterais representando 
as categorias principais de causas que podem contribuir para esse problema. Normalmente, elementos 
como pessoas, processos, materiais, máquinas, ambiente e métodos estão incluídos nas categorias.
Causa Causa Causa
Causa Causa Causa
Causa Causa Causa
Causa Causa Causa
Efeito
Máquinas Materiais Mão de obra
Meio ambiente Métricas Método
Figura 18 – Diagrama de Ishikawa
Disponível em: https://tinyurl.com/2m63uh7x. Acesso em: 3 jun. 2024.
82
Unidade II
Para conseguir utilizar essa ferramenta, é necessário seguir alguns passos.
Comece identificando a consequência ou o problema que deve ser analisado. Por exemplo, o 
problema pode ser “Atrasos na entrega de software em produção”, se você está lidando com atrasos 
na produção.
Em seguida, encontre as categorias amplas que podem estar relacionadas ao problema. Pessoas, 
processos, materiais, máquinas, ambiente e métodos estão entre as categorias comuns.
Na parte superior da folha, desenhe um eixo horizontal que represente o problema ou o efeito. Isso 
representa o “corpo do peixe”. As espinhas são representadas por linhas diagonais que começam no eixo 
principal. A estrutura que forma essas linhas é semelhante a uma espinha de peixe.
Ao longo das linhas diagonais, crie espinhas laterais que representem as categorias principais de 
causas. Para listar todas as causas potenciais dentro de cada categoria, faça uma reunião com a equipe. 
Anote essas causas como “espinhas secundárias” associadas às espinhas laterais.
Após listar as causas, discuta e analise cada uma para determinar o grau de importância delas e como 
afetam o problema. Priorize os fatores mais importantes, pensando em como eles podem contribuir para 
o problema e como podem afetar a resolução.
Depois de dar prioridade às causas, procure as principais causas subjacentes do problema. Isso pode 
exigir investigação e análise adicional. Após encontrar as causas primárias, crie soluções para cada uma 
delas. Implemente as soluções e verifique os resultados para garantir que os problemas estão sendo 
resolvidos de forma eficaz.
Continue observando e avaliando os resultados ao longo do tempo após a implementação das 
soluções. Para evitar que o problema volte a surgir, siga o processo de melhoria contínua e faça os 
ajustes necessários. Esses passos fornecem uma estrutura detalhada para a elaboração e execução 
de um diagrama de Ishikawa, o que garante uma análise completa das causas de um problema e a 
implementação de soluções para resolvê-lo.
Já a ferramenta dos 5 porquês consiste em chegar à raiz do problema com a repetição da pergunta 
“por quê?”. Para a identificação da causa, o método exige interatividade e investigação, a fim de que seja 
encontrado o que realmente causou o problema.
A abordagem dos 5 porquês é uma ferramenta simples, mas poderosa e é utilizada na área de 
resolução de problemas e qualidade. Foi criada pela Toyota como parte do TPS, e seu objetivo é investigar 
as causas primárias de um problema ao fazer perguntas sucessivas sobre por que algo aconteceu.
83
QUALIDADE DE SOFTWARE
Ao encontrar o motivo da adversidade, é possível tomar ações eficientes que eliminem o problema, 
evitando o investimento em ações ineficientes que custem caro ao cliente. Veja o exemplo a seguir:
Quadro 3 – Abordagem dos 5 porquês
Problema: um artigo não foi entregue no prazo
1) Por quê?
Porque o responsável não conseguiu escrever.
2) Por quê?
Porque existia outras demandas como prioridade.
3) Por quê?
Porque surgiram demandas de urgência.
4) Por quê?
Porque o colaborador era o único que conseguia resolver.
5) Por quê?
Porque a equipe é reduzida e surgiram muitas demandas, atrasando a entrega do artigo.
Contramedida: contratar um novo funcionário para auxiliar com as demandas.
Após identificar as causas fundamentais, o próximo passo é desenvolver uma estratégia de resolução, 
o que pode envolver correções no código, mudanças nos processos de desenvolvimento ou até mesmo 
ajustes na infraestrutura. É crucial que essas soluções sejam implementadas com uma visão holística do 
sistema a fim de evitar medidas paliativas, que possam gerar novos problemas no futuro.
Um exemplo notável da importância da análise de causa raiz pode ser visto no caso da falha do 
lançamento do foguete Ariane 5 em 1996.
A investigação revelou que o acidente foi causado por um erro de software relacionado à 
conversão entre tipos numéricos diferentes. Esse incidente reforça como uma pequena falha 
pode levar a consequências desastrosas e destaca a necessidade de uma análise meticulosa para 
identificar e corrigir as verdadeiras causas dos defeitos.
A combinação da técnica dos 5 porquês com o diagrama de Ishikawa viabiliza uma análise 
mais profunda e abrangente das causas de um problema, o que ajuda a encontrar a causa raiz 
subjacente do problema para criar soluções eficazes. É um método sistemático e eficiente que 
resolve problemas em várias áreas e setores.
Por fim, a análise de causa raiz é essencial para a melhoria contínua da qualidade do software. 
As equipes podem construir sistemas mais fortes e confiáveis ao identificar e resolver os problemas 
por meio de uma abordagem sistemática e rigorosa. Isso aumenta a satisfação do usuário final e 
reduz os custos de manutenção corretiva.
84
Unidade II
 Saiba mais
Para aprofundar seu conhecimento na área de engenharia de software, 
seguem algumas sugestões de leitura:
LEÃO, T. Diagrama de Ishikawa: o que é, como funciona e como fazer. Nomus 
Meu Blog Industrial, 2024. Disponível em: https://tinyurl.com/yx7uh4pd. Acesso 
em: 1º jul. 2024.
RAMOS, D. Causa raiz das não conformidades: boas práticas para análise e 
identificação. Blog da Qualidade, 2019. Disponível em: https://tinyurl.com/zjsky55j. 
Acesso em: 1º jul. 2024.
 
5.3 Rastreabilidade de requisitos
A rastreabilidade de requisitos é uma prática essencial no desenvolvimento de software que visa 
acompanhar e documentar a vida útil dos requisitos desde sua concepção até sua implementação e 
manutenção. Essa prática possibilita compreendercomo cada requisito está relacionado aos outros 
e como cada um deles influencia o projeto como um todo. Logo a seguir está um detalhamento.
Imagine um projeto de desenvolvimento de software em que os requisitos são coletados inicialmente 
a partir de diversas fontes, como reuniões com clientes, documentação de negócios e feedback de 
stakeholders. Esses requisitos são então documentados e priorizados para orientar o trabalho da equipe 
de desenvolvimento.
A rastreabilidade de requisitos começa no momento em que eles são coletados e documentados, 
assim cada requisito é atribuído a um identificador exclusivo e é registrado em um repositório 
de requisitos. Esse repositório serve como uma fonte centralizada de informações sobre todos os 
requisitos do projeto.
Veja na figura 19 um exemplo de documento de rastreabilidade de requisito versus casos de testes.
85
QUALIDADE DE SOFTWARE
Documento de rastreabilidade de requisitos
Projeto: Sistema de gerenciamento de biblioteca
Data: 07/04/2024
Objetivo: este documento visa rastrear os requisitos do sistema de gerenciamento de biblioteca 
desde sua origem até sua implementação final.
Requisitos do sistema:
ID do requisito Descrição 
do requisito Origem Status da 
implementação
RQ001
O sistema deve 
permitir o cadastro 
de usuários
Documento de 
especificação 
de requisitos
Implementado
RQ002
O sistema deve 
permitir o cadastro 
de livros
Documento de 
especificação 
de requisitos
Implementado
RQ003
O sistema deve 
permitir o 
empréstimo de livros
Documento de 
especificação 
de requisitos
Em desenvolvimento
RQ004
O sistema deve 
permitir a devolução 
de livros
Documento de 
especificação 
de requisitos
Pendente
Mapeamento de requisitos para casos de uso:
ID do requisito Caso de uso associado
RQ001 UC001 – Cadastro de usuário
RQ002 UC002 – Cadastro de livro
RQ003 UC003 – Empréstimo de livro
RQ004 UC004 – Devolução de livro
Mapeamento de casos de uso para testes:
Caso de uso Casos de teste associados
UC001 – Cadastro de usuário CT001 – Teste de cadastro de usuário
UC002 – Cadastro de livro CT002 – Teste de cadastro de livro
UC003 - Empréstimo de livro CT003 – Teste de empréstimo de livro
UC004 - Devolução de livro CT004 – Teste de devolução de livro
Observações adicionais:
– O documento de especificação de requisitos contém os requisitos detalhados do sistema, incluindo 
descrições, prioridades e critérios de aceitação. 
– Os casos de uso são derivados dos requisitos e descrevem as interações do usuário com o sistema.
– Os casos de teste são desenvolvidos com base nos casos de uso e são utilizados para validar se o 
sistema atende aos requisitos especificados.
Figura 19 – Rastreabilidade de requisitos
O exemplo de documento de rastreabilidade de requisitos mostra como os requisitos do sistema 
são mapeados para casos de uso e de teste, podendo mudar de empresa para empresa o seu conteúdo. 
Ele facilita o acompanhamento do progresso do projeto e garante que todos os requisitos sejam 
adequadamente implementados e testados. É trabalho do engenheiro de qualidade de software deixar 
esse documento sempre atualizado e coerente com a versão corrente do software.
86
Unidade II
Ao longo do desenvolvimento, a rastreabilidade de requisitos ajuda a garantir que todos os requisitos 
sejam atendidos e implementados corretamente. Cada requisito é rastreado através das diferentes fases 
do ciclo de vida do desenvolvimento, desde a análise e design até a implementação e teste.
Durante a análise e o design, os requisitos são decompostos em componentes menores e mais 
detalhados, como casos de uso, fluxos de trabalho e especificações técnicas. A rastreabilidade de 
requisitos possibilita entender como esses componentes estão relacionados aos requisitos originais e 
como eles contribuem para a realização desses requisitos.
Durante a implementação, os desenvolvedores podem fazer referência aos requisitos originais ao 
escrever o código e criar funcionalidades. A rastreabilidade de requisitos ajuda a garantir que todos 
os requisitos sejam abordados e que nenhuma funcionalidade seja desenvolvida sem uma justificativa 
clara baseada nos requisitos do projeto.
Durante os testes, os casos de teste são criados com base nos requisitos originais para verificar se 
todas as funcionalidades atendem às expectativas dos usuários. A rastreabilidade de requisitos permite 
vincular os casos de teste aos requisitos correspondentes e garantir uma cobertura abrangente dos 
requisitos durante o teste.
Além disso, a rastreabilidade de requisitos é útil durante a manutenção do software, pois propicia 
entender como as mudanças em um requisito afetam outros requisitos e componentes do sistema. 
Dessa forma, consegue-se avaliar o impacto de uma alteração antes de implementá-la e garantir que 
todas as partes afetadas sejam atualizadas adequadamente.
Tendo isso em mente, é possível dizer que a rastreabilidade de requisitos é uma prática importante 
no desenvolvimento de software, pois ajuda a garantir que todos os requisitos sejam atendidos e que 
o software atenda às necessidades e às expectativas dos usuários finais. Em todas as fases do ciclo de 
vida do desenvolvimento, as equipes de desenvolvimento podem garantir a integridade, consistência e 
qualidade do software ao registrar e acompanhar a vida útil dos requisitos.
6 MÉTRICAS E GERENCIAMENTO DA QUALIDADE DE SOFTWARE
O gerenciamento da qualidade de software é um pilar fundamental para o sucesso de qualquer 
projeto de desenvolvimento. A implementação de métricas específicas possibilita a avaliação da 
eficiência e eficácia dos processos, bem como a identificação de áreas que necessitam de melhorias. 
Nesse contexto, duas métricas se destacam: COCOMO e ponto de função.
O COCOMO (Constructive Cost Model, em português Modelo Construtivo de Custo) é uma métrica 
projetada para estimar custo, esforço e tempo necessários para o desenvolvimento de um software. Ele 
é baseado em modelos matemáticos que consideram diversas variáveis, como tamanho do software, 
complexidade, experiência da equipe e capacidades das ferramentas utilizadas. Um exemplo prático da 
aplicação do COCOMO pode ser observado em grandes projetos corporativos, uma vez que a precisão na 
estimativa dos recursos é crucial para o planejamento financeiro e alocação adequada da equipe.
87
QUALIDADE DE SOFTWARE
Por outro lado, a métrica ponto de função foca na funcionalidade entregue pelo software ao 
usuário final. Ela mede as funcionalidades com base na perspectiva do usuário, considerando entradas, 
saídas, consultas, arquivos internos e interfaces externas. Essa abordagem é particularmente útil em 
projetos nos quais a entrega de valor ao cliente é prioritária. Empresas que adotam metodologias ágeis, 
frequentemente, utilizam pontos de função para mensurar progresso e produtividade, adaptando-se 
rapidamente às mudanças sem perder o foco na qualidade.
A integração dessas métricas no ciclo de vida do desenvolvimento de software auxilia 
significativamente no gerenciamento da qualidade. Elas fornecem dados quantitativos que podem ser 
analisados para tomar decisões informadas sobre ajustes nos processos ou na alocação de recursos. 
Além disso, contribuem para uma comunicação mais efetiva entre as equipes técnicas e os stakeholders, 
alinhando expectativas e facilitando o entendimento mútuo dos objetivos do projeto.
Por fim, as métricas de ponto de função e COCOMO são instrumentos valiosos para o gerenciamento 
da qualidade do software. Além de aumentar a precisão das estimativas e do planejamento, sua aplicação 
cria uma cultura na organização que incentiva a melhoria contínua de processos e produtos.
6.1 Estratégias para identificação e gestão da eficiência de defeitos
A identificação e a gestão da eficiência de defeitos são componentes críticos no ciclo de vida do 
desenvolvimento de software, exigindo estratégias robustas para garantir a qualidade e a satisfação 
do usuário final. Uma abordagem eficaz envolve várias etapas,desde a detecção precoce até a análise 
pós-correção, passando por uma série de práticas que visam minimizar o impacto dos defeitos no 
produto final.
Uma das primeiras estratégias, mas não a única, é a implementação de revisões de código e inspeções 
formais. Essa prática possibilita às equipes que identifiquem problemas potenciais de forma antecipada. 
Empresas líderes no setor de tecnologia, como Google e Microsoft, adotam rigorosos processos de 
revisão de código para assegurar que apenas o código da mais alta qualidade seja integrado aos seus 
produtos. A utilização de ferramentas como os casos de testes pode auxiliar fortemente nesse trabalho, 
pois os critérios de aceitação devem estar claros para cada requisito do projeto, e isso por natureza já 
consta no documento de casos de testes.
Isso proporciona uma base sólida para a identificação e categorização de defeitos de forma consistente 
durante o teste. A ênfase na prevenção de defeitos, desde o início do desenvolvimento, é crucial, pois 
incentiva práticas como as de revisões de código, de integração contínua e de desenvolvimento orientado 
a testes para identificação e correção de defeitos o mais cedo possível no processo.
A implementação de testes automatizados e o uso de ferramentas de rastreamento de defeitos 
facilitam a gestão eficiente dos defeitos ao longo do ciclo de vida do projeto, propiciando à equipe 
que registre, priorize e acompanhe o status dos defeitos para garantir que sejam tratados de forma 
oportuna e eficaz.
88
Unidade II
 Observação
A implementação de testes automatizados também desempenha um 
papel fundamental na identificação precoce de defeitos, pois possibilita 
a criação de uma suíte abrangente de testes para verificar continuamente a 
integridade do software e para detectar problemas rapidamente.
 
A análise regular das tendências de defeitos e métricas de qualidade é essencial para fornecer 
insights valiosos sobre padrões de defeitos e áreas problemáticas, incentivando para que a equipe tome 
medidas proativas a fim de melhorar a eficiência geral do processo de desenvolvimento. Além disso, é 
importante priorizar e resolver rapidamente os defeitos críticos que têm um impacto significativo na 
funcionalidade ou segurança do sistema, implementando um processo eficiente de triagem de defeitos 
para garantir uma resolução oportuna e eficaz dos problemas mais urgentes.
Ao adotar essas estratégias de identificação e gestão de defeitos de forma abrangente, é possível 
capacitar os alunos a implementar práticas eficazes de garantia de qualidade em seus próprios projetos 
de software.
Por último, é necessário promover uma cultura organizacional que priorize a aprendizagem com 
base em erros para melhorar continuamente os processos e os produtos da organização. As falhas 
podem mudar drasticamente a maneira como as equipes lidam com desafios técnicos, criando um 
ambiente onde a qualidade e a inovação caminham lado a lado.
6.2 Métrica: COCOMO
Como vimos, COCOMO é uma métrica amplamente reconhecida e utilizada para a estimativa de 
esforço, tempo e custo necessários para o desenvolvimento de software. Desenvolvido inicialmente 
por Barry Boehm, em 1981, ele evoluiu ao longo dos anos, adaptando-se às mudanças tecnológicas e 
metodológicas no campo do desenvolvimento de software. Assim, a essência do COCOMO reside em sua 
capacidade de fornecer estimativas baseadas em parâmetros históricos de projetos anteriores, ajustados 
por fatores específicos do projeto atual.
Existem três versões principais do modelo COCOMO: básico, intermediário e detalhado. O modelo 
básico oferece, de forma rápida, uma visão geral, utilizando poucas variáveis para calcular uma 
estimativa aproximada. Já o modelo intermediário introduz mais variáveis relacionadas às características 
do software e ao ambiente de desenvolvimento, possibilitando uma estimativa mais precisa. Por fim, o 
modelo detalhado leva em consideração aspectos ainda mais granulares, incluindo atributos específicos 
das fases do projeto e tarefas individuais.
Suponha que será necessário desenvolver um aplicativo móvel simples, mas que contenha 5000  linhas 
de código, de baixa complexidade e que a equipe possui experiência mediana no desenvolvimento desse 
tipo de aplicativo. Além disso, todas as ferramentas e processos que a equipe tem são bons para a 
construção desse aplicativo.
89
QUALIDADE DE SOFTWARE
Tendo esses parâmetros descritos, siga para estimar os custos usando o COCOMO.
Para calcular o esforço em pessoa-mês (PM), use a fórmula do COCOMO básico com base nos 
parâmetros fornecidos. A fórmula fundamental é:
PM = Ax (KLOC)B
Onde:
Parâmetros A e B são específicos para o tipo de projeto e estão disponíveis nas tabelas do COCOMO.
O tamanho estimado do software em milhares de linhas de código é KLOC.
Suponha que os valores de A e B sejam 2,8 e 1,20 para um projeto de software de baixa complexidade, 
com uma equipe de desenvolvimento experiente e boas ferramentas e processos. Portanto, substituindo 
os valores, tem-se:
PM = 2,8 × (5)1,20
PM = 2,8 × 7,543
PM ≈ 21,15 pessoa-mês
Agora, sabendo o esforço necessário em pessoa-mês, você já pode estimar o tempo de desenvolvimento e 
o custo total do projeto. Suponha que a equipe trabalhe em média 160 horas por mês e o custo médio 
por pessoa seja de $ 5.000 por mês.
Tempo de desenvolvimento = PM meses.
 160
Custo total do projeto = PM × 5.000 dólares.
Logo:
Tempo de desenvolvimento ≈ 21,15 meses ≈ 0,13 mês (ou cerca de 4 dias).
 160
Custo total do projeto ≈ 21,15 × $ 5.000 ≈ $ 105.750.
Esse é um exemplo simples de como você pode usar o COCOMO para estimar os custos associados 
ao desenvolvimento de um projeto de software.
90
Unidade II
Um dos grandes desafios na aplicação do COCOMO é a calibração correta dos seus coeficientes para 
refletir as peculiaridades da equipe de desenvolvimento, das tecnologias empregadas e das práticas 
organizacionais. Empresas que conseguem ajustar adequadamente os parâmetros do COCOMO podem 
obter estimativas muito precisas, facilitando a gestão eficaz dos recursos e a tomada de decisões 
estratégicas sobre o escopo e o cronograma dos projetos.
Além disso, a aplicabilidade universal do COCOMO torna-o uma ferramenta valiosa tanto para gerentes 
de projeto experientes como para startups e empresas emergentes no cenário tecnológico. Ao adotá-lo 
no planejamento e execução de projetos de software, como parte integrante da cultura organizacional, 
as empresas podem melhorar significativamente suas chances de sucesso comercial e técnico.
Por fim, embora algumas críticas indiquem que a calibração adequada dos modelos mais sofisticados 
pode ser difícil, ou que os parâmetros precisam ser atualizados constantemente, devido às novas 
tecnologias, não se pode negar o valor inestimável que o COCOMO oferece como ferramenta preditiva 
no campo do desenvolvimento de software.
 Saiba mais
Para aprofundar seus conhecimentos sobre o modelo COCOMO e suas 
aplicações práticas no desenvolvimento de software, seguem algumas 
sugestões de leitura:
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem 
profissional. 7. ed. Porto Alegre: AMGH, 2011.
Este livro aborda vários tópicos relacionados à engenharia de software, 
incluindo modelos de estimativa de esforço como o COCOMO.
 
6.3 Ponto de função
A métrica de ponto de função (function point, em inglês) é uma técnica de medição usada na 
engenharia de software para quantificar o tamanho funcional de um sistema de software, com base 
nas funcionalidades fornecidas aos usuários finais. Desenvolvida por Allan Albrecht, na IBM, na década 
de 1970, a métrica de ponto de função se tornou uma ferramenta valiosa para estimar o tamanho e a 
complexidade de um projeto de desenvolvimento de software.
A ideia principal por trás da métrica de ponto de função é medir a funcionalidade entregue pelo 
software, em vez de medir diretamente o tamanho do código, ou o número de linhas de código. Isso 
significaque a métrica de ponto de função se concentra nas características do sistema que são visíveis 
aos usuários finais e que agregam valor ao negócio.
91
QUALIDADE DE SOFTWARE
Para calcular os pontos de função, são identificadas as diferentes funcionalidades do sistema, como 
entradas de dados, consultas ao banco de dados, interfaces com o usuário e relatórios gerados pelo 
sistema. Cada funcionalidade é classificada com base em sua complexidade e a ela é atribuída uma 
pontuação em pontos de função. Essas pontuações são então somadas para obter o tamanho total do 
sistema em pontos de função.
Abstração orientada a dados
Documentação 
do software
Aplicação
Outras 
aplicações
Dados 
internos (ALIs)
Dados 
externos 
(AIEs)
Pontos de função 
(números)
Transações 
(EEs, CEs, SEs)
Identificação dos itens da APF
Mapeando em números
Usuários
Figura 20 – Elementos para contagem do ponto de função
Disponível em: https://tinyurl.com/yc4pm7xe. Acesso em: 3 jun. 2024.
 Lembrete
A unidade de medida de software ponto de função (PF) foi definida 
em 1977, por Allan Albrecht, na IBM, e é reconhecida pela ISO/IEC 20926 
para estimar o tamanho de um sistema de informação com base na 
funcionalidade percebida pelo usuário do sistema, independentemente da 
tecnologia usada para implementá-lo.
 
O cálculo dos pontos de função envolve várias etapas e é importante seguir um processo sistemático 
para garantir precisão. A seguir apresentamos uma abordagem básica para calcular os pontos de função.
Identificação das funções do sistema
O primeiro passo é identificar as diferentes funcionalidades que o sistema deve fornecer aos usuários 
finais. Isso inclui todas as entradas de dados, consultas, relatórios e interfaces com o usuário.
92
Unidade II
Classificação das funções
Cada função identificada é classificada com base em sua complexidade. Desse modo, existem três 
tipos de funções: entradas externas (EE), saídas externas (SE) e consultas externas (CE). A classificação 
das funções é baseada em critérios como o número de campos de entrada ou saída, o número de 
arquivos lógicos acessados e a complexidade da lógica de processamento.
Atribuição de pontos de função
A cada função classificada é atribuída uma pontuação em pontos de função, com base em uma 
tabela de valores padrão. Por exemplo, uma entrada externa (EE) simples vale três pontos de função, 
enquanto uma mais complexa vale seis pontos de função. As pontuações são determinadas com base 
em estimativas de esforço necessárias para implementar cada função.
Somatório dos pontos de função
Uma vez que todas as funções tenham sido classificadas e pontuadas, as pontuações são somadas 
para obter o tamanho total do sistema em pontos de função.
Ajustes por fatores de influência
Após o cálculo inicial dos pontos de função, podem ser aplicados ajustes para levar em consideração 
fatores de influência adicionais, como a complexidade da arquitetura do sistema, a experiência da equipe 
de desenvolvimento ou a qualidade dos requisitos.
Esses ajustes são aplicados multiplicando os pontos de função brutos por um fator de ajuste 
específico para cada fator de influência.
Cálculo final dos pontos de função
Os pontos de função ajustados são calculados a partir da soma dos pontos de função brutos e dos 
ajustes por fatores de influência. Para demonstrar, segue uma aplicação do ponto de função.
Imagine que você é o encarregado de desenvolver um sistema de gerenciamento de biblioteca 
para uma biblioteca local. Você começa identificando as principais funcionalidades que o sistema deve 
fornecer aos usuários finais, como permitir que os bibliotecários cadastrem novos livros, consultem 
livros existentes, registrem empréstimos e gerem relatórios sobre os livros disponíveis.
Para cada uma dessas funcionalidades, é necessário avaliar a complexidade envolvida. Por exemplo, o 
cadastro de um novo livro pode ser relativamente simples, enquanto a geração de relatórios talvez exija 
mais trabalho e lógica de processamento. Com base nessa avaliação, você classifica cada funcionalidade 
como de complexidade baixa, média ou alta.
93
QUALIDADE DE SOFTWARE
Agora, é hora de atribuir pontos de função a cada funcionalidade com base em uma tabela de valores 
padrão. Por exemplo, o cadastro de um novo livro vale seis pontos de função, enquanto a consulta de 
um livro existente vale três pontos. Esses valores são determinados a partir de estimativas de esforço 
necessárias para implementar cada funcionalidade.
Depois de atribuir pontos de função a todas as funcionalidades, você os somará para obter o tamanho 
total do sistema em pontos de função. Nesse caso, o sistema de gerenciamento de biblioteca tem um total 
de 27 pontos de função.
Nessa etapa, é necessário fazer ajustes adicionais para levar em consideração fatores como a 
complexidade da arquitetura do sistema ou a experiência da equipe de desenvolvimento. Por exemplo, 
você decide aplicar um ajuste de mais 10% para a complexidade da arquitetura do sistema, resultando, 
assim, em 30 pontos de função ajustados.
Esses 30 pontos de função representam a estimativa do tamanho e a complexidade funcional do 
sistema de gerenciamento de biblioteca, o que vai ajudar você a ter uma ideia do esforço necessário para 
desenvolver e manter o software. Essa medida é valiosa para o planejamento de recursos, estimativas de 
custo e prazos de entrega do projeto.
Suponha que você está estimando o tamanho funcional de um sistema de gerenciamento de 
biblioteca com as seguintes funcionalidades: cadastro de livros, cadastro de usuários, empréstimo 
de livros, devolução de livros, geração de relatórios de empréstimos, e busca de livros no catálogo.
Para calcular o ponto de função, usaremos os seguintes passos:
• Identificar tipos de função e contar suas ocorrências.
— Funções de entrada de dados (EEs): cadastro de livros, cadastro de usuários.
— Funções de saída de dados (SEs): empréstimo de livros, devolução de livros, geração de 
relatórios de empréstimos.
— Funções de consulta (CEs): busca de livros no catálogo.
• Atribuir pontos de função não ajustados (PFNA).
— EEs: 4 pontos cada.
— SEs: 5 pontos cada.
— CEs: 4 pontos cada.
Total de PFNA = (2 x 4) + (3 x 5) + (1 x 4) = 8 + 15 + 4 = 27 PFNA
94
Unidade II
• Identificar fatores de ajuste.
— Complexidade: avaliar cada função (baixa, média, alta) com base em fatores como volumes de 
dados, complexidade de processamento, entre outros.
— Ajustar os PFNA com base na complexidade de cada função.
• Calcular pontos de função ajustados (PFA).
PFNA x fator de ajuste = PFA (para exemplificar, foi considerado apenas 10% como fator de ajuste)
27 + (27 x 10%)
• Somar os PFA.
Total de PFA = soma de todos os PFA de cada função.
Total de PFA = 30 PFA
É importante notar que o cálculo dos pontos de função é uma estimativa e pode variar dependendo 
da precisão das estimativas de esforço e da complexidade das funções. No entanto, quando realizado 
com cuidado e baseado em dados reais – sempre que possível –, ele fornece uma medida útil do tamanho 
e da complexidade funcional de um sistema de software.
Uma vez conhecendo a quantidade de pontos de função de um sistema de software, facilmente você 
poderá calcular a quantidade de horas que se leva para resolver cada ponto de função. A quantidade 
de horas pode variar de 8 horas a 20 horas por ponto de função, a variação dependerá mais do 
histórico da empresa.
A métrica de ponto de função oferece várias vantagens sobre outras técnicas de medição de tamanho 
de software. Por ser baseada na funcionalidade fornecida aos usuários finais, ela é independente da 
linguagem de programação ou da tecnologia utilizada no desenvolvimento do software. Além disso, 
como se concentra nas funcionalidades do sistema, pode ser usada para comparar a produtividade entre 
projetos e equipes diferentes, fornecendo uma base mais objetiva para estimativas de custo, prazo e 
esforço de desenvolvimento.
Entretanto, a métrica de ponto de função tambémtem suas limitações e desafios. A determinação 
precisa dos pontos de função é subjetiva e requer um entendimento detalhado dos requisitos do sistema. 
Além disso, ela não leva em consideração a qualidade do software ou a eficiência do código, o que 
significa que dois sistemas com o mesmo tamanho em pontos de função podem ter níveis diferentes de 
complexidade técnica.
A métrica de ponto de função é uma técnica útil para medir o tamanho e a complexidade funcional 
de um sistema de software, bem como para fornecer uma base objetiva para estimativas de custo, 
95
QUALIDADE DE SOFTWARE
prazo e esforço de desenvolvimento. Embora tenha algumas desvantagens, ela ajuda as organizações a 
melhorar a gestão de seus projetos de desenvolvimento de software e a fazer escolhas mais inteligentes 
sobre planejamento e alocação de recursos.
 Saiba mais
O cálculo de ponto de função é uma técnica utilizada por grandes empresas 
e conhecê-la poderá ser um diferencial no momento da contratação. Para 
entender melhor sobre o assunto, consulte:
SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO). Roteiro 
Serpro de contagem de pontos de função e estimativas. 2014. Disponível em: 
https://tinyurl.com/yc4pm7xe. Acesso em: 28 maio 2024.
VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de pontos de função. 
12. ed. São Paulo: Érica, 2012.
 
6.4 Tempo médio entre falhas (MTBF)
O tempo médio entre falhas (MTBF, do inglês Mean Time Between Failures) é um indicador fundamental 
na área de manutenção e confiabilidade de sistemas, sendo utilizado para avaliar a confiabilidade de 
equipamentos, componentes ou sistemas em geral.
O cálculo do MTBF foi desenvolvido por engenheiros e cientistas, com a finalidade de avaliar a 
confiabilidade de sistemas e equipamentos. Não há um único inventor ou criador específico do cálculo 
do MTBF, pois ele é o resultado de décadas de pesquisa e desenvolvimento na área de confiabilidade 
e manutenção. A teoria por trás do cálculo do MTBF está baseada em estatística e probabilidade, e 
foi desenvolvida por diversos pesquisadores e profissionais ao longo do tempo. A ideia de utilizar o 
MTBF como uma métrica para avaliar a confiabilidade de sistemas e equipamentos surgiu na década 
de 1950, com o advento da teoria da confiabilidade e da manutenção preventiva.
O MTBF é aplicado no desenvolvimento de software para avaliar a sua confiabilidade e prever o 
tempo médio entre falhas. Nesse contexto, ele é utilizado para estimar o tempo médio que um software 
pode operar sem falhas.
Para o cálculo do MTBF, é necessário considerar o tempo total de operação do equipamento ou 
do sistema e o número de falhas que ocorreram durante esse período. Ele é realizado pela fórmula: 
MTBF = (tempo total de operação – tempo de manutenção) / número de falhas, onde:
• o tempo total de operação é o período em que o sistema esteve em funcionamento, no caso de 
um sistema de produção, ou o tempo de desenvolvimento da release para ser entregue ao cliente;
96
Unidade II
• o tempo de manutenção é o tempo em que o sistema ficou inativo em produção devido a reparos 
ou falhas ou, no caso de desenvolvimento, pode ser o tempo que uma funcionalidade demorou 
para ser ajustada depois que o erro foi detectado pelo time de testes;
• o número de falhas corresponde à quantidade de vezes que o sistema falhou durante o período de 
operação, no caso de produção, ou a quantidade de itens retornados para desenvolvimento depois 
de uma rodada de testes.
Veja um exemplo: se um software operou por 525.600 minutos (aproximadamente um ano) e teve 
6 falhas durante esse período com um tempo total de manutenção de 170 minutos, o MTBF seria 
calculado como:
MTBF = (525600 – 170) / 6
MTBF = 87571,67 min.
Resultando em aproximadamente 60 dias entre falhas.
O cálculo do MTBF é aplicado no desenvolvimento de software como uma métrica para avaliar a 
sua confiabilidade, prever o tempo médio entre falhas e auxiliar na tomada de decisões para melhorar 
a qualidade e a confiabilidade do produto final.
6.5 Métricas de usabilidade
A usabilidade de software é a medida na qual os usuários podem interagir com um sistema de 
software. Portanto, a métrica de usabilidade é uma técnica para avaliar e medir essa qualidade.
Pode-se aplicar uma variedade de métricas de usabilidade a um sistema de software, cada uma 
das quais se concentra em aspectos específicos da experiência do usuário. Algumas das métricas 
mais usadas são discutidas a seguir.
Métricas de facilidade de uso
Uma das métricas mais importantes para avaliar a usabilidade do software é a facilidade de uso, 
que pode ser definida como “a facilidade com que um produto pode ser utilizado para alcançar 
objetivos específicos por usuários específicos, em um contexto específico de uso” (ISO 9241-11). 
Essa definição enfatiza que o contexto do usuário deve ser levado em consideração ao avaliar a 
facilidade de uso de um software.
É fundamental que a interface seja fácil de usar. Segundo Jakob Nielsen (1993), um renomado 
especialista em usabilidade, a interface do usuário deve antecipar as necessidades dos usuários e 
garantir que as opções sejam visíveis, acessíveis e compreensíveis. As interfaces do usuário de alta 
qualidade – a ajuda e a satisfação do usuário – diminuem os erros.
97
QUALIDADE DE SOFTWARE
Além disso, é fundamental que os controles sejam fáceis de entender para o usuário usar o 
software. Norman (2013) alega ser essencial que os controles sejam intuitivos, de fácil localização e 
compreensão para os usuários. Portanto, é fundamental fornecer ao usuário um feedback imediato 
para que ele fique atualizado e possa corrigir rapidamente os erros.
A consistência do design é um componente crucial da facilidade de uso. A consistência é uma 
das características mais poderosas de uma interface do usuário eficaz, de acordo com Steve Krug, 
autor de Não me faça pensar (2001). Quando se descobre que as coisas funcionam da mesma 
maneira, não é necessário gastar tempo ou esforço para descobrir como funcionam.
Finalmente, é essencial que o software seja fácil de usar para que os usuários comecem 
rapidamente. A implementação de guias de ajuda contextuais e tutoriais interativos pode ser um 
exemplo disso.
Em resumo, uma experiência de usuário positiva com o software depende da facilidade de uso. 
Um software que seja verdadeiramente fácil de usar e atenda às necessidades dos usuários deve 
ter uma interface intuitiva, controles claros, design consistente e facilidade de aprendizado.
Métricas de eficiência
A eficiência de software é uma medida que avalia a rapidez e a precisão com que um sistema de 
software executa suas funções, tarefas ou processos com poucos recursos, tais como tempo, memória 
e processamento.
O tempo de resposta, que é aquele que o sistema leva para responder a uma solicitação do usuário, 
trata-se de uma métrica comum para avaliar a eficiência de um software. Os usuários esperam uma 
resposta rápida, então qualquer atraso pode causar insatisfação e frustração.
A métrica de consumo de recursos mede quantos recursos um software usa durante sua execução, 
tais como memória, processamento e largura de banda de rede. De acordo com Tanenbaum (2016), 
é fundamental projetar software de forma a minimizar o consumo de recursos, assegurando que o 
sistema funcione de maneira suave e responsiva.
A escalabilidade é a métrica que mede a capacidade de um sistema de suportar uma carga de 
trabalho maior com o mesmo desempenho. Esse tipo de métrica está associada aos resultados de testes 
não funcionais realizados no sistema.
A eficiência de software é uma medida importante que avalia a rapidez e a precisão com que 
um sistema de software executa suas funções, tarefas ou processos a partir de recursos limitados. O 
desempenho responsivo, o uso eficiente de recursos e a escalabilidade do software dependem de uma 
abordagem eficaz.
98
Unidade II
 Saiba mais
Para aprender mais sobre as métricas de eficiência, acesse as 
seguintes leituras:
DIAS,R. Métricas para avaliação de sistemas de informação. Revista 
Eletrônica de Sistemas de Informação, v. 1, n. 1, 2002. Disponível em: 
https://tinyurl.com/3wrz246v. Acesso em: 4 jun. 2024.
GUIMARÃES, W. Métricas em testes de usabilidade, como usá-las 
para melhorar o seu produto. UX CollectiveBR, 2019. Disponível em: 
https://tinyurl.com/5n6ab3xj. Acesso em: 4 jun. 2024.
NUNES, A. As principais métricas para avaliar a usabilidade de uma 
interface. UX CollectiveBR, 2020. Disponível em: https://tinyurl.com/3p325ty4. 
Acesso em: 4 jun. 2024.
VIRGENS, G. B. D. Extração de métricas de usabilidade a partir de protótipos 
de fidelidade mista. 2010. Dissertação (Mestrado em Ciência da Computação) – 
Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre, 2010. 
Disponível em: https://tinyurl.com/mrk4dj7k. Acesso em: 4 jun. 2024.
6.6 Métricas de manutenibilidade
A manutenibilidade de um software mede a facilidade com que um sistema de software pode ser 
modificado, corrigido e adaptado ao longo do tempo, mantendo sua qualidade e desempenho. Há, 
portanto, diferentes tipos de métricas de manutenibilidade:
• Complexidade ciclomática: mede a complexidade do fluxo de controle do software, sendo um 
indicador da dificuldade de compreender e manter o código.
• Índice de manutenibilidade: mede a facilidade de manutenção do software, considerando a 
complexidade do código, a quantidade de comentários e a estrutura do programa.
• Métricas de Chidamber e Kemerer: avaliam a manutenibilidade de software orientado a objetos, 
considerando aspectos como o número de classes, métodos e heranças.
As métricas de manutenibilidade são importantes para a avaliação da qualidade do software, 
especialmente em sistemas de informação. Elas são usadas para identificar trechos de código que 
precisam ser refatorados, para avaliar a qualidade do código antes de sua implantação e para controlar 
os custos de manutenção ao longo do tempo.
99
QUALIDADE DE SOFTWARE
Indicadores quantitativos que avaliam a facilidade de manutenção e modificação de software no 
decorrer de um período são conhecidos como métricas de manutenibilidade. Assim, existem vários tipos 
que podem ser usadas para avaliar a qualidade do software em sistemas de informação.
 Lembrete
As métricas de manutenibilidade são essenciais para controlar os 
custos de manutenção e avaliar a qualidade do software. Dentre elas, 
estão: complexidade ciclomática; índice de manutenibilidade; e métricas 
de Chidamber e Kemerer.
 Saiba mais
Para se aprofundar mais nesse assunto, seguem algumas sugestões 
de leitura:
BATISTA, C. F. A. Métricas de segurança de software. 2007. Dissertação 
(Mestrado em Informática) – Pontifícia Universidade Católica do Rio de 
Janeiro, Rio de Janeiro, 2007. Disponível em: https://tinyurl.com/3rt6jzbm. 
Acesso em: 4 jun. 2024.
FERREIRA, B. N.; ARAKAKI, J. Métricas de manutebilidade apoiando a Refatoração. 
Academia Edu, [s.d.]. Disponível em: https://tinyurl.com/2ejypmmk. Acesso em: 
4 jun. 2024.
SOUZA, T. B. A. Um modelo para avaliação da manutenibilidade de 
código-fonte orientado a objeto. 2005. TCC (Trabalho de graduação em 
Engenharia de Software) – Universidade Federal de Pernambuco, Recife, 
2005. Disponível em: https://tinyurl.com/26zj4fhv. Acesso em: 4 jun. 2024.
 
100
Unidade II
 Resumo
O gerenciamento de defeitos envolve as etapas de identificação, registro, 
correção e verificação de problemas no código ou no comportamento do 
software, ou seja, é uma parte essencial do ciclo de vida do desenvolvimento 
de software. Um defeito de software é qualquer desvio do comportamento 
esperado que leva a falhas ou mau funcionamento do sistema.
A identificação é feita por testes manuais ou automatizados, ou ainda 
relatada pelos usuários finais. Os defeitos, então, são registrados em um 
sistema de rastreamento de defeitos, quando encontrados. Esse sistema 
compila informações como a descrição do problema, a gravidade e a 
prioridade dele e as etapas necessárias para reproduzi-lo.
Após o registro, os defeitos são priorizados com base em sua gravidade 
e impacto no software. Defeitos críticos que afetam a funcionalidade 
principal do sistema são, geralmente, priorizados. Em seguida, a equipe de 
desenvolvimento trabalha na correção do defeito, elaborando uma solução 
e implementando-a no código-fonte.
Depois da correção, verifica-se a falha novamente para garantir que 
o problema foi resolvido. Isso geralmente envolve testes adicionais para 
confirmar se o defeito não está mais presente e se a funcionalidade afetada 
está funcionando conforme o esperado. Por fim, o defeito é fechado no 
sistema de rastreamento após a confirmação de que foi corrigido e foi 
gerada uma documentação adequada sobre o evento.
O gerenciamento de defeitos é fundamental para melhorar a qualidade 
do software, garantindo que problemas sejam identificados e corrigidos 
antes que impactem os usuários finais. Além disso, tal abordagem ajuda a 
reduzir custos de manutenção em longo prazo, evitando a acumulação de 
defeitos não resolvidos.
Para contribuir no momento de identificação e nos levantamentos dos 
custos do projeto de software, as métricas quantitativas como o COCOMO 
e a análise de ponto de função auxiliam na avaliação de diversos aspectos 
do software, desde sua produtividade e qualidade do código até seu 
desempenho, usabilidade, manutenibilidade e segurança.
101
QUALIDADE DE SOFTWARE
As métricas de qualidade do código se concentram na estrutura e 
legibilidade do código-fonte, ajudando a identificar áreas problemáticas 
que podem impactar a manutenibilidade e a escalabilidade do software, 
incluindo métricas como a complexidade ciclomática, a taxa de cobertura 
de código nos testes e a conformidade com padrões de codificação.
As métricas de desempenho, por outro lado, avaliam a performance do 
software em termos de tempo de resposta, disponibilidade e confiabilidade. 
Desse modo, há as métricas de tempo médio entre falhas (MTBF) e de taxa 
de falhas por unidade de tempo.
Já as métricas de usabilidade medem a facilidade de uso e a satisfação 
do usuário com o software, incluindo métricas como tempo médio para 
aprender a usá-lo, a taxa de conclusão de tarefas e as pesquisas de 
satisfação do usuário.
As métricas de manutenibilidade avaliam a facilidade de manutenção 
e evolução do software ao longo do tempo. Para isso, usam-se métricas de 
facilidade de compreensão do código e de tempo médio para fazer uma 
mudança no código.
Ao utilizar métricas da qualidade de software, é importante selecionar as 
métricas apropriadas com base nas necessidades específicas do projeto e da 
organização e, assim, interpretar os resultados com cuidado, considerando 
o contexto do software e dos usuários finais.
102
Unidade II
 Exercícios
Questão 1. (FGV 2022, adaptada) A gestão da qualidade é tarefa de fundamental importância no 
contexto econômico atual, podendo ser considerada um diferencial competitivo para as organizações. 
Devido a essa relevância, alguns estudiosos preocuparam-se em desenvolver ferramentas para auxiliar 
os gestores nesse processo, sendo o Diagrama de Ishikawa um de seus exemplos.
Nesse contexto, assinale a alternativa que descreve a ferramenta conhecida como Diagrama 
de Ishikawa.
A) Ciclo iterativo que percorre fases de planejamento, execução, checagem e correção, visando à 
melhoria contínua.
B) Representação esquematizada de modelo de processos sequenciais a serem executados 
na organização.
C) Modelo estatístico que permite identificar correlações entre variáveis independentes.
D) Gráfico que sistematiza possíveis razões de determinado problema, auxiliando a identificar 
relações de causa e efeito.
E) Tabela que analisa aspectos específicos de problemas e calcula a média ponderada para selecionar 
o prioritário.
Resposta correta: alternativa D.
Análise da questão
O Diagrama de Ishikawa é uma ferramenta visual utilizada para encontrar e organizar as possíveis 
causas de um problema ou de um efeitoespecífico. Esse diagrama é estruturado visualmente como 
uma espinha de peixe, com o ramo principal representando o problema ou o efeito a ser analisado, 
e os ramos laterais representando as categorias principais de causas que podem contribuir para esse 
problema. Normalmente, elementos como pessoas, processos, materiais, máquinas, ambiente e métodos 
estão incluídos nas categorias.
Desse modo, o Diagrama de Ishikawa pode ser definido como um gráfico que sistematiza possíveis 
razões de determinado problema, auxiliando na identificação de relações de causa e efeito.
103
QUALIDADE DE SOFTWARE
Questão 2. (UFG 2024, adaptada) A análise de pontos de função (APF) é amplamente utilizada para 
estimar o esforço de desenvolvimento, para avaliar a produtividade e fornecer uma base objetiva para a 
negociação de contratos de desenvolvimento de software. Qual é a principal métrica medida na análise 
de ponto de função?
A) Quantidade de linhas de código-fonte.
B) Complexidade ciclomática.
C) Tamanho funcional.
D) Tamanho do código binário.
E) Quantidade de instruções assembly.
Resposta correta: alternativa C.
Análise da questão
O intuito da métrica de ponto de função é medir a funcionalidade entregue pelo software, ao invés 
de medir o tamanho do código-fonte. Desse modo, a métrica de ponto de função concentra-se nas 
características do sistema que são visíveis aos usuários finais e que agregam valor ao negócio.
Para calcularmos os pontos de função, identificamos as diferentes funcionalidades do sistema, 
como entradas de dados, consultas ao banco de dados, interfaces com o usuário e relatórios gerados. 
Classificamos cada funcionalidade com base em sua complexidade e atribuímos uma pontuação. Depois, 
somamos essas pontuações para obter o tamanho funcional do sistema.